Advanced programming languages
matt.might.net
matt.might.net
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.
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.
What about aleph?
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.
https://developer.mozilla.org/en/JavaScript/Reference/Statem...
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.
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.
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?
Add Mozart/Oz to the mix for good measure.
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 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?
Haven't done any Haskell coding, but I just seriously doubt that in any language.
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.
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 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.
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.
I guess I have a broader definition of bug than the author.