Just the mention of Scheme, my favorite programming language, makes me get irritated when I think about the thousand or fifteen hundred lines of JavaScript I've written in the last couple weeks. I'm basically writing Scheme using C syntax, and the anonymous functions as arguments to functions which are called by anonymous functions that are themselves arguments to functions really start to get confusing, in large part because the mixing of parentheses and curly brackets and the semicolons and all the things that are supposed to be the sane alternative to all those sets of parantheses. Oh, and let's not even mention the way JavaScript doesn't do block scoping the way C++ does, and let's not even think about how closures interact with mutation—which almost guarantees that code with for loops and closures will have bugs in it.
And the sad thing is, I don't mind writing JavaScript. Relatively speaking, I love JavaScript. Now, if a framework-platform like Node.js existed for Clojure, now, that would be a different story. Except that I'd then constantly have to do mental context switches whenever I jumped from client to server code.
Thanks; I just checked it out and while it has some nice features, it doesn't do all that much to compact my already-dense JS. Additionally, the added complexity it introduces to the development process negates some of its charm, as does the extra cognitive load of playing human backtracking parser whenever I have to think about what function applications require parens and which don't. (This is all IMO, so while I think I've accurately portrayed CoffeeScript, YMMV, so people should check it for themselves.)
> function applications require parens and which don't.
Yes. An understanding of JS is definitely necessary when developing with CoffeeScript. The ambiguity that the parser allows sometimes leads to code generation that isn't at all what you intended. I sometimes find myself going into the JS output to make sure the compiler did what I intended.
Annoying, but at least for me, the benefits of cleanliness and things like list comprehensions and Python-esque list semantics makes it worthwhile.
I was really surprised when I got to college and the only languages people cared about were C++ and Java. Ok, you'll also find some C#, Python, and Ruby, but nobody has heard of any of these "advanced" languages. The only thing they care about are the number of job opportunities they can get. I sometimes try to advocate for Haskell, or Scheme, or even Prolog. The response is usually "Pascal?" It's sad that these students never wonder if there's a better language, or a more fun language, or anything other than Java. It's a desert out here.
I've been reading some blog posts here http://existentialtype.wordpress.com/ about the curriculum at Carnegie Mellon and I've been very impressed. I can't believe they're phasing out object-oriented programming! Here the faculty seem to think object-oriented is the only way. Actually I can't think of any functional programming we've been introduced to. (Or any other paradigm for that matter)
o_O I don't know about you guys, but our CS affiliation requirement includes at least one semester of Functional Programming (using ML rather than Haskell, I know for sure that CMU (ML) and Berkeley (Scheme/ML) have similar requirements too). Java's seen as the bane of the world over here, especially since none of our professors are convinced that OO is more than just a little bit of syntax sugar coated over some generic imperative language (and as far as I can tell, I'm starting to agree with them).
AFAIK it is pretty common for most universities in Germany to start CS programs with either (S)ML, OCaml, Haskell or any combination of these depending upon the individual preferences of the responsible chair.
Java is (was?) pretty common for introductory OO classes. Advanced OO classes (outside of a "Software Engineering" context) though often introduce Eiffel, Smalltalk, Python, C++ and C# as well.
Depending upon your particular choice of courses, specialization etc., being exposed to Lisp, Prolog, Perl, C and R isn't uncommon either and from what I heard Scala is also starting to appear as a teaching language.
From what I heard the curriculum in France, Swiss, Austria and Denmark is very similar. So I am a bit surprised of the notion that there are universities out there where you can get a CS degree without being exposed to some functional programming.
The university I went to covered Java and x86 assembly in first year. Haskell, Prolog, MIPS assembly and more Java (for algorithms and data structures) in second year. C++(C with classes really) and yet more Java in third. Fourth year languages depended on optional courses, I did some SR[1] for concurrent programming course and matlab for DSP.
Besides x86 and Java, the other languages we covered weren't in terribly high detail, but enough to get a taster for whats out there. I would have liked more focus on a pure functional language, Haskell in our case, but overall we covered quite a lot of great material.
Most people (besides a handful of people like me who like non-mainstream languages) didn't really care much for anything but Java though, sadly.
If he thinks that Smalltalk is a "alternate yet fully capable universe that branched off from mainstream computing long ago" then I'm not sure I want to know what he thinks about selflanguage.org ...
But seriously, his four 'advanced programming languages' seem to be all in the functional space. That's great, but I'd recommend looking outside that as well. Maybe Haskell, Pharo, Factor and Erlang?
He's pretty weak on APLs and constraint/logic programming, too. Nothing against Matt Might, though (he's got plenty of other excellent posts!), any post like that is inherently incomplete.
+1 for Mozart/Oz. It's a great language for exploring the various paradigms of programming. Working through "Concepts, Techniques and and Models of Computer Programming" (http://www.info.ucl.ac.be/~pvr/book.html) with Mozart/Oz gives a great tour of programming techniques and manages to stay in one language for the whole journey.
Though, in fairness, Erlang has a completely different emphasis than most other functional languages - instead of provability, experimenting with type systems, or state-phobia, my understanding is that it was pretty much engineered for making stable systems, and everything else is a secondary concern. (It was also put together by a telecom, rather than academics or hobbyists).
It is kind of interesting that unlike many of the "exotic" languages in the list Erlang has arrived where it is from another direction -- from practical necessities of telecom platforms. But interestingly it has arrived at similar results as many academic functional languages. So for example, all base data structures are immutable and variables are single assignment only. Now someone coming from C(++) or Java will hate that, but that is needed in order to provide stability and a consistent view into the data structures in a concurrent environment. So "fixing" it and making data structures mutable would break that.
Then I like how you said 'statephobia'. In case of Erlang they saw the practical difficulty with having one single mutable state across a large distributed system so applied the 'actor-based concurrency model'. Perhaps other, more academic languages, decided to cure their statephobia because of some aesthetic desire, maybe they wanted the functions to look more like math functions, but they both declared war on spreading mutable state, even though they started from different ends of the spectrum.
When talking about the design philosophy of Erlang, it helps to remember that it was originally implemented atop Prolog, so some of those choices may not have been intentional.
I was giving my four suggestions to show how the author could have chosen more variety; eg functional, oo, concatenative and distributed/actor. Mercury/Oz mentioned by Mahmud below is another great idea, they don't get nearly enough love.
Shouldn't an article on "advanced programming languages" include at least one dependently typed language? I mean, I'm pretty slow and halting in Haskell and Erlang, but with ATS and Coq I don't even know where to start.
"In Haskell, programmers not yet well versed in functional program design may find they repeatedly code themselves into a corner, where they don't have access to the monad that they need. The MLs keep the side effects "escape hatch" open to patch over incomplete design, which prevents projects from coming to a sudden, unexpected "refactor-or-abort" decision point."
When I was a beginner, I did this a lot. In fact, I still do it occasionally.
It is very impressive by the standards of relatively unpopular languages. Also the documentation is really good. But if Racket's libraries are immense, what is Ruby's and Rails'? Mega gargantuan?
I went to the U of U for a time, and I wish I would've encountered Matt Might while I was there (it looks like our only overlap would've been Spring 2009, though). Somehow I wasn't able to effectively communicate with my advisor and/or figure out which classes on the schedule were actually cool.
In my experience writing code in Haskell, you spend about 95% of your time debugging type errors and 5% of your time debugging actual bugs. The good thing about the former is that it's effectively the compiler finding the bugs for you.
Haskell is the only language I've used (obviously, not the only one in existence) where I am not surprised when a large program works correctly on the first successful compilation.
Disclaimer: Haskell is not my main language, I'm mainly a C programmer.
jbooth, if you try Haskell out you'll be very surprised. It's often true - it's just that it takes a lot more work to get a Haskell program to compile.
You're right - I should have been more critical of the comment, rather than making it personal.
I agree with the sentiment that often, "once it compiles, it's correct", but people don't stress what Matt Might does enough: "In fact, experienced programmers become adept at encoding correctness constraints directly into the Haskell type system." If you just write Haskell (OCaml, etc.) like you would Python, it's not going to make much difference - it's all about representing higher-level assumptions at the type level, and many people new to H-M languages don't know how to do that effectively.
* String processing (if you want to tell me how a type system prevents string processing bugs, I'd love to hear it)
There's no such thing as a magic bullet, and the claim is way overstated. It might be less prone to bugs than loosely typed systems, that's something I'd have no problem believing. I'm a fan of strong typing myself.
And the sad thing is, I don't mind writing JavaScript. Relatively speaking, I love JavaScript. Now, if a framework-platform like Node.js existed for Clojure, now, that would be a different story. Except that I'd then constantly have to do mental context switches whenever I jumped from client to server code.
There is no rest for the wicked, I suppose.