Yay! A new scripting language!

The specific issue Crack was meant to address was to create a "scripting" language that could easily be compiled to native bytecode. I don't have an immediate use for it, but maybe someone else will find it interesting.

> Cobol was already outdated when Java appeared. Therefore the question is
> not whether Java was an advance over Cobol, but whether it was an advance
> over what the state of the art was when it appeared. Smalltalk, Lisp, Self
> and others had been around for a long time then, and OCaml first appeared
> only a year later (and unlike Java it ran at decent speeds even back
> then). If anything, Java was a step backwards.

Smalltalk evolved into Ruby by assimilating the good ideas from Perl. It was a big improvement.

OCaml is actually a dialect of Standard ML, a language that was developed during the 1980s. The relationship between Standard ML and OCaml is kind of similar to the relationship between K&R C and ANSI C. Standard ML is older than Java, not newer.

I wrote a compiler in Standard ML for a class. There were certain things that could be expressed very elegantly. Anything that was an operation on a tree usually came out looking very nice. A lot of other algorithms didn't translate so well.

Standard ML has implicit typing, which means that you don't have to specify the type of parameters to, and return values from, functions. This is all very neat and elegant. However, in practice, it means that you can make a change at point A in your program, another change at point B, and get a type error at point C, which you then have to figure out. Also, when you look at code from other people, you have to try to figure out their intentions without having explicit type annotations.

The syntax of the language is very minimalistic. Unlike in Lisp, you are encouraged to omit parentheses in a lot of places. Over time, I learned that this was a bad idea, because it made the compiler's very difficult job even harder. The compiler errors I got in Standard ML were consistently incomprehensible-- yes, worse than C++ template errors. Part of this is no doubt due to lack of funding, but they have had 25+ years to get it right. I suspect that the complexity of the type system makes good error messages very hard to achieve. Adding explicit type annotations and parentheses can help a little bit.

I favor languages that have the flexibility to be used in a functional style, but that don't force this on you all the time. Your preferences may be different. But claiming that obscure academic languages are "state of the art" and blasting people for not using them probably won't help your cause.