

Quicklisp: On Beyond Beta, Talk at European Lisp Symposium 2015 - lispm
https://github.com/quicklisp/els-london-2015

======
616c
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.

~~~
gecko
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.)

~~~
616c
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?

~~~
gecko
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.

~~~
616c
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.

