Quicklisp: On Beyond Beta, Talk at European Lisp Symposium 2015 | Hacker News Reader

Quicklisp: On Beyond Beta, Talk at European Lisp Symposium 2015

github.com

43 pointslispm6 comments

So I spent the beginning of my week screwing around at work with the Pharo Smalltalk environment again, for the third or fourth time in the last few years of "flirt with different programming environments."

Problem is, it is just so GUI for development. I mean it is cutting edge so wonderful, but at the same time so much bling. I do wish to continue with GNU Smalltalk and maybe not so much Pharo, because Seaside is very appealing.

So why do I bring this up? The infinite introspection and modability of Smalltalk and Common Lisp make them so beautiful and sexy to a budding wannabe deep-dive hacker. I keep wanting to dive deep into a platform (said elsewhere, I am back to school for Java), but I keep coming back to SBCL.

So I just want to say thanks to Zach Beane (xach). His CL work has been awesome, and Quicklisp is the only way I have used SBCL/CCL/ECL with slime in Emacs so far. And it is just wonderful for me.

I know people were making fun of his smug (in his slides he is like raise your hand if you use CL without Quicklisp, no hands?, ah that's right), but it has been surprisingly little headache for me except for compiled code (Qt5 versus Qt4 in the CommonQt packages for GUI).

So, thanks to yoy, Zach, and the rest of the kickass CL community.

I've been working on and off with Smalltalk since about 1996.

I'd encourage you to be open to having a GUI-first development tool. Yeah, it's blingy. But it's also incredibly productive, and I think that eschewing Pharo for GNU because you find the GUI too neat is a bit odd.

(There have been complaints that Pharo's GUI actually makes it too easy to code overly abstracted crazy stuff, which I'm actually quite sympathetic to, but I don't think that's what you're saying.)

I find the aversion to outside tooling hard. I know everything is an object, but I have to live completely in the land of $implementation Smalltalk's view. I understand that has power though, so I cannot knock it. GNU became interesting to me through quick research because it kind of rides the line between the two, and feels very Lispy to me.

But you are very experienced. Tell me: if I reinstall Pharo right now, should I just dig into Seaside? Is there anything I can play with and read that will push farther into the traditional Smalltalk camps?

So, let me cover three different things here: my attitude on Smalltalk the language; my thoughts on Seaside; and what would push you further into the Smalltalk camp. Last one first.

Smalltalk shines when you go native and really buy the idea that the Smalltalk IDE is going to be your one-stop shop for everything. I personally find that this happens naturally when I'm doing really rapid prototyping. Nowadays, I'm a fairly passionate strong typing proponent in general, and I generally find myself happier languages like Rust, TypeScript, F#, and Kotlin than in languages like Python, Ruby, Io, or JavaScript. But when I'm not entirely sure what I'm doing yet, when I'm exploring a space or trying to figure out how something ought to work, then I find that the power of Smalltalk's introspection, and the flexibility afforded by the browser, debugger, rewriting tool, and metaobejct protocol (similar to but different from Common Lisp's) more than make up for the loss of safety. So if you were going to play with it in order to get hooked, I'd suggest doing it in an area where you're not quite sure what you're doing yet. Maybe Cryptopals or something where you're out of your element.

That all said, the strength of the tooling results in some odd patterns in Smalltalk that I am increasingly thinking are bad decisions. For example, there are no case or match statements. Instead, you're expected to make all the objects that you would be switching on all implement some method (maybe e.g. #handle:), and then you unconditionally call that method and rely on the object's differing behavior to cover the match statement. But that means that you're suddenly unclear who all can actually be affected by a given line of code. The tooling helps, but it's annoying.

The language also shows its age in some other ways. There's not a real concept of immutability, for example, and the only real literals are numbers, strings, and arrays. (Pharo kind of skirts this issue by having an #asDictionary method on their runtime arrays that converts an association list to a hash table, but it's quite ugly for nested structures.) The threading story is green threads only. With all variables being private and no macros, there's a fair amount of boilerplate that shows up (although, like a modern Java IDE, Pharo's IDE can write the setters and getters for you) (I'll also confess to not being sure how the new slots system impacts this, so this may no longer be an issue.) In the real world, for production code, I don't think these have to all be issues, but they keep Smalltalk from being my general go-to language.

That leaves your question about Seaside. I love prototyping in Seaside (see above) because it lets me basically ignore JavaScript and still code a fully stateful website, but I don't personally actually like designing server-local stateful web services these days. I'd personally probably use Teapot (a Sinatra/Flask/Dropwizard-like REST server) and a straight single-page JavaScript app (or maybe Amber, if I wanted to use Smalltalk all the way down) instead. I think Seaside was an absolutely amazing idea when it came out, and I have a very high opinion of its quality, but I don't honestly think it's a great way to design services these days.

Sorry for the late reply. I will take more time to play with Pharo. I read some of your stuff on Reddit and it seems compelling to use for proto-typing. I started reading about Seaside-REST, Teapot, and Amber after following your name to Reddit comments about the Smalltalk Renaissance.

Guys like you make me love HN. You took the time to advocate. So I will take the time to take another look.

> I know people were making fun of his smug (in his slides he is like raise your hand if you use CL without Quicklisp, no hands?, ah that's right)

But let's be honest here. When it first launched, Quicklisp went from 0 to 80% of the market basically overnight, and 100% within the first year or so. This is in part because the previous "state of the art" was so terrible that anything would have been an improvement, but it was not as if there hadn't been other efforts. Quicklisp addressed the workflows that CL implementation and library hackers wanted to use, and therefore quickly commanded a lot of respect. Everything that had existed previously had seemed like a toy for beginners (e.g. the different variations on Lisp-in-a-box). It really was a night and day difference.

Reply on news.ycombinator.com