The best CS course I took was "Designing Functional Programs", an introductory course at Waterloo.
Haskell is used as the pseudo-code for lectures while assignments are written in Racket.
The course was great because the professor (PR) was:
1- Passionate
2- Knowledgeable
3- A kind person
I have found Racket to be a very effective way to make students (most of them have either no CS background or only have played around with imperative/OOP languages) more comfortable with functional programming.
The best memory I have was during the first lecture. After all the administrative fluff, the prof open his pdf and the first slide reads: "Induction"
I remember thinking "Is this a maths or a CS course?"
The second slide defined the set of natural numbers. As the prof start explaining the syntax and its meaning, I slowly start to realize the beauty of those few words:
Data Nat = Z | S Nat
where Z represent 0 and S the successor function.
We define the data type "Nat" to be either zero or the successor function applied to a "Nat".
It was my "ahah" moment. I was mind-blown by the language's clear syntax and immensely powerful semantics. (This is Haskell not Scheme/Racket).
We would later be introduced to lambda calculus (untyped vs typed), infinite data structures, interpreters etc... It was glorious... What a great professor.
The only "downside" to this is that Racket/Scheme isn't very much used outside of Academia. Which is clearly a shame given its incredible built-in features and elegant LISP-like syntax.
Should anyone have insights/opinions on why Racket/Scheme aren't more used, please feel free to share them with us!
> Should anyone have insights/opinions on why Racket/Scheme aren't more used, please feel free to share them with us!
Well, I'm not sure what happened to Arc, but I thought that was based off of plt-scheme/racket -- but never ported to recent releases. Which is a shame because racket has certainly improved a lot (possibly not in ways that matter for Arc).
Does anyone know why/what the status is there?
Additionally, while some(?) older(?) versions of hn is open source[1], being based off a dead(?) dialect of an outdated(?) scheme didn't really help.
Other than that, running a really popular niche web site/forum in production should make Arc interesting, which in turn should make racket interesting. But that apparently didn't happen.
Anyone know what hn currently runs (the stack - is it essentially an updated version of[1] -- or something entirely different)?
Other than that recent example of not becoming popular, I think that the focus on education has lead a lot of people to miss how good racket actually is, out of the box.
It does seem to me to have some of the same challenges as other lisps when it comes to deployment -- it's not all that easy to see how to easily tag something for release, run it through CI and deploy it with some predictable success. Not really any technical limitation, more that it's just not obvious. And wasn't something that was highlighted by racket before, at least.
Thank you for the reminder -- I had found that at some point, the forgot about it. For other's wondering, a version of hn lives in the lib-folder (news.arc).
Racket has an enormous standard library. I'm not gonna dare wave numbers around compared to Python, and I'm sure Java beats the both of them, but it's not small.
"Not enough libraries" is usually not a complaint about the standard library but about "if I need to do $SLIGHTLY_WEIRD_PROTOCOL, will I have to write it from scratch?" Racket has made strides on this in recent years but still lags far behind Python or the JVM.
The last time I counted, I think there were more packages between PLaneT and pkgs.racket-lang.org than Chicken eggs. Also, Chicken relies on eggs to provide a lot of things that the Racket standard library contains.
Note that Racket now have several distributions. The minimal distribution intended for servers is less than 10MB (then install the libraries you need).
The first mainstream computer programs were written in imperative (think assembly goto, etc), and became the defacto standard. As new programmers entered, many were taught by older programmers, so they would most likely learn imperative programming. Since it is arguably harder to learn functional programming after imperative programming, (rather than learning functional programming right away), the imperative cycle continued, and here we are today.
I also attended Waterloo CS, and I am really grateful to have been exposed to Racket. I am actually using Racket for my upper year courses as well, which is awesome.
Language popularity generally follows adoption of some key library or framework from that language.
Python is probably an exception there because it got popular despite the lack of a clear reason (I would argue it was there to fill the vacuum left by Perl). But Rails is what brought Ruby into the mainstream, and C was brought to the mainstream by Unix, and JavaScript was brought to the mainstream by Netscape, and so on.
Lisp never became mainstream because nobody ever wrote a killer app/library/framework/OS in that language. The most popular flavor of Lisp today, Clojure, managed to carve a niche for itself because its community is so practical-minded and has been working on very practical stuff like Om, Storm, Reagent, etc. Hopefully they will find their own killer app one day.
Emacs brought Lisp mainstream, and Emacs Lisp at its heyday was arguably more popular than Clojure is now. The problem is that Emacs was the dominant text editor c. 1990, when the software world was much smaller than it is now, and has since been eclipsed by IDEs, GUI editors, etc.
AutoCAD brought Lisp mainstream for mechanical engineers, architects, and so many other 'rocket scientists' that I believe Emacs pales in comparison.
I was programming AutoLisp (automatic correction of trace and drill patterns for PCBs) on the machine which wasn't even able to build a decent Emacs in reasonable amount of time (PC AT/286 12Mhz with 2MB memory :-)). I was able to build myself an Emacs only after I got upgraded to 386SX 16Mhz with the whopping 4MB of RAM.
There was a period when Lisp was pretty large in industry as well, especially at places like BBN and NASA. Depends on how you measure, of course; those kinds of places don't do things that have a lot of end users, but the projects are large measured in dollar terms.
That's right. But I think it's going through a little renaissance. Emacs 21-24 has happened in a remarkably short time. With the Internet, many programmers are looking for better paradigms and find Lisp & functional programming.
I'm curious what you mean by "the vacuum left by Perl". I certainly have little love for Perl, but you say that as if Perl went away or something. I don't think it did? Was there a large herd of perl programmers that just all went "Oh, bollocks, this perl6 thing is never going to arrive -- every day, my code just works, isn't broken by an update to the language. Time to move on!" ? Because that doesn't really make much sense.
I am no historian, but back in the 90s Perl was filling the niche of "the duct tape of the Internet" and systems administration language. I used it.
I think three things contributed to its downfall:
1) Perl 6
2) the huge inflow of people into Unix who were not keen on Perl's ultra-Unixy wackiness (let's borrow from bash, awk, regexps and everything under the sun! - fun but not exactly welcoming to require newcomers to learn the entire cultural history of Unix to learn your language)
3) the fact that sysadmin work was quickly graduating from writing scripts that send angry emails when users fill their 20MB home directory quota into managing serious, distributed system that serve as crucial infrastructure, for which the non-wackiness of Python was a better cultural fit (particularly when the role of developer and sysadmin started to merge)
It's not so much that people started rewriting their Perl scripts, it's more like the newcomers who weren't doing Perl soon outnumbered those who were.
Re 2) I think that's not just "unix wackiness", but plain wackiness. But as I said, I never did like perl much -- even if I do like awk/sed/grep/sh.
Perhaps one other factor is the rise of GNU/Linux and death of Unix. Linux might still be the world's most "self-incompatible" operating system -- but it's a lot more coherent than a mix of various flavours of Unix/Solaris/BSD etc.
Shell scripting makes more sense if you can assume a certain lower common denominator of GNU sed/grep/awk and posix and/or bash. Along with more or less consistent file system layout, location/availability of special files etc.
Add to that the rise of XML, then json, and perls built in regular expressions doesn't set it so far apart any more -- you'll need a library/tool for parsing/serializing anyway.
Still think it a bit odd to call it the "vacuum left by perl" -- it's probably more the flood created by python/ruby/newcomers...
For me it is not a book that teaches Racket though - and not a book to pick up web dev in Racket though.
If there was tutorials on how to do Sinatra, Express or Flask style web apps/apis I think people who use those types of frameworks would find it more accessible. And there are a lot of those type of people.
I saw this and it made me very happy. I was going to mention it in my original comment but I couldn't remember the link. I'm going to put this in my "tutorial TODO" list, it looks like a lot of fun! Thanks :)
Given how passionately John Carmack posts about Racket development in his twitter feed, I suspect most of these performance issues can be overcome with more experience.
Just wanted to add that you don't have to use continuations as such. I don't have any benchmarks on stateless web server, so can't say about its performance.
I'd just love to see this work well with a proper SCIP plugin on Windows. MIT/GNU Scheme sort of works on Windows, but you can't integrate it with EMACS. Dr. Racket comes closer, but the libraries have been moved from (or to, I don't remember off hand) Planet, and trying to get them installed is painful and prone to error. It becomes really difficult to study the lectures without a good environment and Dr. Racket is the most promising because it supports graphical output. I just wish it worked properly.
I got a fair way through SICP using DrScheme (now DrRacket) a few years ago without any special compatibility modes, and found the set-up to be pretty great.
That's what I've had such a hard time setting up. The newer Dr. Racket uses a different library system and last time I tried to get things working (on 6.1 I think) it has all sorts of problems downloading. I had to use older versions and it was never installed correctly.
Haskell is used as the pseudo-code for lectures while assignments are written in Racket.
The course was great because the professor (PR) was:
1- Passionate
2- Knowledgeable
3- A kind person
I have found Racket to be a very effective way to make students (most of them have either no CS background or only have played around with imperative/OOP languages) more comfortable with functional programming.
The best memory I have was during the first lecture. After all the administrative fluff, the prof open his pdf and the first slide reads: "Induction"
I remember thinking "Is this a maths or a CS course?"
The second slide defined the set of natural numbers. As the prof start explaining the syntax and its meaning, I slowly start to realize the beauty of those few words:
Data Nat = Z | S Nat
where Z represent 0 and S the successor function.
We define the data type "Nat" to be either zero or the successor function applied to a "Nat".
It was my "ahah" moment. I was mind-blown by the language's clear syntax and immensely powerful semantics. (This is Haskell not Scheme/Racket).
We would later be introduced to lambda calculus (untyped vs typed), infinite data structures, interpreters etc... It was glorious... What a great professor.
The only "downside" to this is that Racket/Scheme isn't very much used outside of Academia. Which is clearly a shame given its incredible built-in features and elegant LISP-like syntax.
Should anyone have insights/opinions on why Racket/Scheme aren't more used, please feel free to share them with us!