RacketLanguage

Quora Answer : Why isn't the graphical programming environment Racket (DrScheme) more popular?

Oct 1, 2015

Rich Hickey, when asked why other Lisps had "failed" (in 7 Languages in 7 Weeks) said something that sounds pretty plausible to me.

Common Lisp and Scheme didn't fail at what they were designed for. CL was designed to create a standard between multiple Lisp vendors, Scheme was designed to demonstrate how much could be done with an elegant minimal language. They failed to become popular. But popularity wasn't an explicit goal.

OTOH, Clojure was designed explicitly to be a useful and widely used Lisp on the JVM.

I've been using Clojure for about a year. And played a bit with Racket and I think that's right. Almost everything about Clojure feels like it's well designed for practicality. The introduction of [] and {} make it easier for me to scan code visually. The immutable / lazy data-structures really let me get a feel for what's different and powerful in FP. While the protocols and records allow me to apply the architectural thinking that I'm familar with in Java. The libraries feel excellent. Hickey talks about the absense of user reader macros to discourage too many obscure dialects of syntax ... I don't have a strong sense of that, but it sounds plausible.

In other words, when you start learning Clojure you start to notice what a Lisp focussed on real-world use looks like. Conversely when I've looked at Racket, I've noticed the opposite : a language which is largely a toy-box for playing with Lisp variants. It inherits the academic virtues of Scheme. It's very clever, and many of those languages are undoubtedly powerful and elegant. But it reminds me rather of that earlier powerful but doomed toybox : Smalltalk. A lot of cute demos and ad-hoc demonstrations that something could be done - a text formating language, a web-server written in 4 lines of code, optional typing, optional laziness etc. - all jumbled up together into a colourful, entertaining party-bag of goodies.

Don't get me wrong. I LOVE environments like this.

But Clojure gives me the sense that, as I demand more of it - larger code, more access to platform libraries and resources, more speed - it, and its community, are going to scale up and handle it. DrRacket doesn't feel like that.

Update :

I've been playing with Racket a bit more, and thinking of teaching a short intro to FP using it. (It's great to have everything in a single IDE and installer, especially in Windows)

And here's what's really turning me off about it : lack of polymorphism in the standard libraries. I HATE that I have to use functions with different names for lists and for strings and for more abstract sequences etc. This is something that Clojure does really well ... make everything about interfaces so that any sequence-like thing talks the same sequence operators, and any map-like thing talks the same map operators etc. Switching from Clojure back to Racket really highlights how ugly it is not to have this ... and have dozens of long-winded, clunkily named functions to do basically the same work. Case in point 4.3 Strings How horrible is that?

Quora Answer : Is Racket a good introductory Programming Language?

Jan 11, 2018

Last night I did an impromptu "learn to program" workshop for two 8 year olds and their father.

Using Processing.

We made a colourful little "chase a bouncing ball with the mouse" game in about two hours. And managed to compile it down to run on an Android phone.

I was reminded again of what I think is the crucial virtue of a teaching language / environment. It needs to be able to let you do interesting stuff easily and directly. Not get too much in your way. And not load you up with boring responsibilities.

I've taught an intro to FP in Racket. Including to some people who knew very little programming. I have also taught an almost identical course in Clojure, using Klipse to make a kind of in-browser worksheet environment.

Here's what I think.

Firstly Racket is a Scheme. And a Scheme / Lisp is a great language in general. And fine for teaching.

Dr. Racket is a really good environment. Having an all-in-one installable environment is extremely important. Dr. Racket has that. And Dr. Racket is a toolbox full of goodies.

However there are some things I'm still not satisfied with.

Dr. Racket is not as fun and exciting as Processing. Although Processing is Java, a horrible language. And hardly a sophisticated environment. It is graphically powerful. And I can write 10 lines of Java (a not very efficient language) and make something very pretty and spectacular happen that makes people go wow and get excited.

Even working with Dr. Racket's graphical language of circles and rectangles, you can't do that.

I wish Dr. Racket would do its own version of a Processing-like framework.

Because in a real sense, Processing is "more powerful" and "easier" to have fun with. Despite Java.

I'm also really curious to know why Sophia Gold is says she'd prefer Racket over Clojure.

Here's where I think Clojure scores bigly over Racket. The consistent, common interface to the collections. I know Racket might be moving in this direction, but the fact that all sequences / lists / vectors look the same to a Clojure function, and all map-like things look the same, is a real boost for simplicity. With this commonality, Clojure has the kind of carefree simplicity of Python where you learn the standard interface to collections in 10 minutes and never think about it again.

Whereas every time I use Racket I spend a lot of time looking up the function for how to do something with strings vs. lists vs. some other sequential type thing.

I wish Dr. Racket would move quickly to a common standard API for collections like Clojure and Python have.

If Racket did this, then again, I'd have a lot more enthusiasm for it as a teaching language.

Finally, in some ways I find Processing documentation better. OK, that's not true. It's not really better. Processing does only a fiftieth of what Dr. Racket does. BUT the small amount it does do, it documents very clearly and cleanly. Documentation is simple to get at and well organized.

I wish Dr. Racket's documentation was as attractive and simple as Processing's.

If Dr. Racket could provide a clone of the Processing graphic library. If it could move all of Racket's standard libraries behind a common interface. If the documentation could be simple and beginner focused like Processing's and not so much like an extended man page. Then I think Dr. Racket would be a spectacular learning experience.

As it is, I'm torn ... I like teaching beginners in Processing because it has so much power and is therefore so much fun. Last night I ended up recommending people download and learn with Processing and not Dr. Racket. Despite being a Lisp lover.

I also still prefer writing code in Clojure to Racket because the libraries feel cleaner and more elegant.

You can tell I've been thinking about this a lot. In fact, only last month, I applied to the Processing Foundation, proposing a fellowship to make a Clojure mode for the Processing environment. I don't know how likely I am to get that. But if I get it, then Racket should watch out. ;-) A language as powerful and elegant as Clojure in an environment as simple and powerful as Processing will also be a pretty awesome teaching tool. :-)

Quora Answer : Why would having a universal programming language be good or bad?

Sep 21, 2018

It's not a feasible goal because :

some language features and semantics are mutually exclusive. A language can't both have immutability and mutability. Or strong static types, and dynamic types.

all languages must drive something to be useful. And for some languages, what it drives is a crucial part of what the language is. SQL drives a relational database. Urbiscript drives robots. Prolog drives an inference engine. Smalltalk drives the Smalltalk machine and environment which has its own characteristics. But what does a "universal" language drive? All of these? Or none of them?

often syntactic decisions favour one paradigm or semantics over another. It's rare that a single syntax is good for describing all kinds of things. Lisp is pretty good. But even that has room for improvement. Eg. the sublanguage for writing macros is still being worked on (see here for a much longer discussion)

The nearest you might get to a "universal language" is something like Racket. Which is a language specialised for writing other languages. And can mix and match compiled modules in these different languages Racket does let you compile one bit of your program with strong static types, while another part has no types.

However even Racket needs to have some access to external things to drive. And that puts some constraints on it. It's not completely universal.

Finally, unless you're thinking of language like Racket which is effective a language construction kit, I think languages that try to be a the "Swiss Army Knife" by throwing various paradigms into (I'm looking at you C++, Scala) end up being unwieldy and over-complex and having pretty ugly syntax for some things.