That's good to know. For 23+ years I've used MUMPS, which has no defined types for variables. Of course, that may be offset by the fact that MUMPS only has 1 type -- string -- with the caveat that when the strings represent numbers (or not) numeric operations can be run on them.
Mumps Interpreter V11.0 Fri Jun 08 11:19:45 2012
> s a="345"
> w a+1,!
346
> s a=" 123" ; With a space at the front, it does not qualify
> w a+1,! ; as a number and defaults to 0
124
>
arc> (profiler (repeat 5 (tokens (rand-string 1000) #\0)))
Message : Unhandled exception on thread#0: can't compare rand-string with rand-string
At instruction (invocation:[free:rainbow-profile-report->[builtin:rainbow-profile-report]])
(fn nil (html-prof ((rainbow-profile-report) 'invocation-profile)))
[builtin:protect]
Java stack : rainbow.ArcError: Unhandled exception on thread#0: can't compare rand-string with rand-string
At instruction (invocation:[free:rainbow-profile-report->[builtin:rainbow-profile-report]])
(fn nil (html-prof ((rainbow-profile-report) 'invocation-profile)))
[builtin:protect]
at rainbow.vm.VM.thread(VM.java:72)
at rainbow.Console.compileAndEval(Console.java:193)
at rainbow.Console.interpret(Console.java:127)
at rainbow.Console.repl(Console.java:117)
at rainbow.Console.main(Console.java:59)
Caused by: rainbow.ArcError: can't compare rand-string with rand-string
at rainbow.functions.rainbow.RainbowProfileReport$FunctionProfileComparator.compare(RainbowProfileReport.java:90)
at rainbow.functions.rainbow.RainbowProfileReport$FunctionProfileComparator.compare(RainbowProfileReport.java:80)
at java.util.TreeMap.compare(TreeMap.java:1188)
at java.util.TreeMap.put(TreeMap.java:531)
at java.util.TreeSet.add(TreeSet.java:255)
at rainbow.functions.rainbow.RainbowProfileReport.createInvocationReport(RainbowProfileReport.java:60)
at rainbow.functions.rainbow.RainbowProfileReport.createReport(RainbowProfileReport.java:36)
at rainbow.functions.rainbow.RainbowProfileReport.report(RainbowProfileReport.java:31)
at rainbow.functions.rainbow.RainbowProfileReport.invokef(RainbowProfileReport.java:22)
at rainbow.vm.instructions.invoke.optimise.Invoke_free.operate(Invoke_free.java:22)
at rainbow.vm.VM.loop(VM.java:91)
at rainbow.vm.VM.thread(VM.java:58)
... 4 more
arc>
I'd look at your PATH and JAVA_HOME environment variables. If they refer to a JRE directory, change that to the JDK directory. Then start a new shell and see if "java -version" has changed.
In the meantime, if you manually invoke the full path to your JDK's java.exe with the -version option, you can see if that one's even a server VM to begin with. :-p If it isn't, maybe try "C:\...\java.exe -server -version" to be sure.
Oh, now that we're talking about it, I seem to remember there's some kind of issue where Jarc allows regular function calls on symbols but 'apply on a symbol doesn't work. So how about (apply 'getTime (list:new java.util.Date))?
I guess there's an issue here because getTime is not a "regular" arc function, but a Java method and the mapping from names to methods is not "hooked" in map implementation (I guess :) ...
Anyway the following works:
Jarc> (map (fn (_) (getTime _)) (list (new java.util.Date)))
I find many of the interactive features to be over-engineered and/or under-documented. I've never been able to use the condition system to do anything useful. It's not apparent what compiler errors are recoverable and how to recover from them.
I dislike its package management. But this is a general criticism of most languages -- no matter how late-bound the language, there's a consistent temptation toward early binding for performance reasons (see the latter half of http://arclanguage.org/item?id=15587, ie footnote 1. Also http://arclanguage.org/item?id=12057)
Bottomline: while lispers like to say the world hasn't fully understood the power of 70's lisp, it's equally true that Common Lisp is stuck in the 70's and hasn't benefited from ergonomic advances of the past 20 years. It still uses UPPERCASE. These issues are certainly minor compared to having macros. But they carry some weight.
I liked the fact that you included easy graphics in your language. That is a way to immediately involve the student in a medium that they presumably already like and are acquainted with.
It reminds me of Logo, which was also targeted at youth, and included graphics primitives. I used it myself to create some drawings to help us hang pictures :=)
I wonder about some of your choices. The Goto in 1 example reminds me of spaghetti coding, and probably some of the early programs I wrote. Logo, on the other hand (http://en.wikipedia.org/wiki/Logo_%28programming_language%29), included other branching commands which lend to better programming practices. It also included parameter passing, etc. Might be good to take a look. Children are capable of amazing things.
I decided when writing Kalimat to enable a teacher - if they so choose - to remove all sorts of abstraction and write code that resembles how it's going to run. When dealing with a child I think learning to code is more important than learning to code well, and removing all obstacles for that is a good design choice.
This way, the student can go directly into writing interesting programs using only if/goto/expressions. Later they can learn more disciplined forms like procedures or OOP, also included.
But I don't want to impose my ideas on users; if the teacher disagrees with me, they can completely ignore goto and use other control structures!
