Advanced programming languages(matt.might.net)
matt.might.net
Advanced programming languages
http://matt.might.net/articles/best-programming-languages/
40 comments
>Now, if a framework-platform like Node.js existed for Clojure, now, that would be a different story.
What about aleph?
http://github.com/ztellman/aleph
What about aleph?
http://github.com/ztellman/aleph
There's also Saturnine, https://github.com/texodus/saturnine though I haven't tried it yet.
The guys at INRIA (you may know them from Bigloo or OCaml) have a scheme to javascript compiler that works quite well. HOP is made with that.
This short paper: http://www-sop.inria.fr/indes/scheme2js/files/icfp2006.pdf elaborates on Scheme to JS compilation and goes beyond. You can actually generate all the HTML in Scheme as well (as done in HOP).
If you download HOP's sources, it's there.
This short paper: http://www-sop.inria.fr/indes/scheme2js/files/icfp2006.pdf elaborates on Scheme to JS compilation and goes beyond. You can actually generate all the HTML in Scheme as well (as done in HOP).
If you download HOP's sources, it's there.
Sibilant is Lisp lipstick for JavaScript.
https://github.com/jbr/sibilant
https://github.com/jbr/sibilant
Block scoping is part of ES5 using let
https://developer.mozilla.org/en/JavaScript/Reference/Statem...
https://developer.mozilla.org/en/JavaScript/Reference/Statem...
Have you heard of CoffeeScript? It makes writing JS a much, much more pleasant experience.
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.
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 guess it really depends on what college. At my school, which tends towards the theoretical, Scheme, SML and Prolog are part of the core curriculum.
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.
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.
[1] http://en.wikipedia.org/wiki/SR_(programming_language)
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.
[1] http://en.wikipedia.org/wiki/SR_(programming_language)
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?
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.
Wow, thanks for the tipoff on Pharo, that's really neat. I'll have to keep an eye on that one!
SECONDED!
Add Mozart/Oz to the mix for good measure.
Add Mozart/Oz to the mix for good measure.
+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.
Or AliceML, its Hindley–Milner typed cousin.
He does mentions Haskell. Pharo is Smalltalk. Erlang is functional.
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.
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.
When I was a beginner, I did this a lot. In fact, I still do it occasionally.
... the Racket library is immense...
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?
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.
Stopped reading at "once a program compiles [in haskell], it's almost certainly correct".
Haven't done any Haskell coding, but I just seriously doubt that in any language.
Haven't done any Haskell coding, but I just seriously doubt that in any language.
It's far closer to true than you'd think.
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.
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.
How's stopping reading at the first thing that challenges your assumptions working for you?
Please be nice.
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.
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.
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.
* Bugs in the spec
* Bugs in underlying system calls
* I/O error handling
* 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.
* Bugs in underlying system calls
* I/O error handling
* 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.
It's true. Even for beginners it's ridiculously hard to compile buggy programs.
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.