> There's no such thing as a good language-- there are only languages that are good for a certain purpose.
By that logic, nothing is ever good, as nothing is good for all purposes. Besides, I've said multiple times that there's nothing wrong with having multiple languages for different purposes. Why do you want me to repeat myself?
> Even if you (or a committee of people) managed to identify a set of "perfect" programming languages for 2010, in a few years, they wouldn't be perfect any more. The problems that are most important change over time. In the early nineties, concurrency often seemed like a minor issue, since almost everyone was using single-processor computers. In contrast, good runtime performance was extremely important back then. Nowadays, it doesn't matter as much for many applications. Those are just two examples-- there are literally hundreds of trends in computer architecture and design that are changing things over time.
So, what specific issue does the crack language address? If it has innovative constructs for concurrent applications, great! If it's really great for building a certain type of application, wonderful! But when I saw the slides, I didn't see anything remotely innovative.
> Theorists often feel like there hasn't been very much progress in programming languages since Lisp, since Lisp originated so many of the concepts used by later languages. But from a practical perspective, there has been. You can build a website using Ruby faster than you could with C++. You can write business applications better in Java than you could in COBOL. And so on.
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.
Posted Dec 31, 2010 19:49 UTC (Fri) by cmccabe (guest, #60281)
[Link]
> So, what specific issue does the crack language address? If it has
> innovative constructs for concurrent applications, great! If it's really
> great for building a certain type of application, wonderful! But when I
> saw the slides, I didn't see anything remotely innovative.
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.