Perl + Smalltalk

Continuing the discussion from Introduce Yourselves!:

I’ve never been a developer, but I like to tinker, and Perl helped a lot.

Smalltalk on the other hand, was fascinating, with a different way to think.

I’ve never put it into actual practice, but it was an eye opener.

I like building my own tools, and I liked the idea that you have a living system that you can continuously improve.

Pharo mostly, and I also liked the amber-smalltalk project.

1 Like

I’ve never tried doing anything in Smalltalk and I know too little about it. I mean, yes I could do some research, but can you quickly explain what’s cool about it? I would enjoy that, I think! :sweat_smile:

Hmm, I’m not sure from where to start, as there are several interesting things about Smalltalk.

To start, Smalltalk was created as a bet, Alan Kay argued that you can specify a powerful language on a single page, so his friends asked him to prove it. He did the specification and his friend Dan Ingalls implemented it!

About the language itself: surprisingly, there are very few keywords (according to Wikipedia: six). Everything else is defined.

And although it’s quite old (1970), but it held up quite well.

Now I come to my personal reasons: I’m a tinkerer, and Smalltalk is good for tinkering. In Smalltalk everything is there for you to tinker with, and this requires some kind of explanation.

In Smalltalk you don’t get a compiler where you write code and it will compile/interpret it. You get a complete environment with objects that can do different stuff, and you can manipulate them or add to them.

And this is one of the peculiar thing about it, which makes using it different: to use it you run like a virtual machine and what you build is all in that box.

And this brings us to the downsides of Smalltalk: unlike normal languages, your product is not a separate application that you run independently, it’s still something within this closed environment.

Also, taking the Information Security point of view: Smalltalk is dangerous, as (oh, I forgot to mention this) you have the complete source of all the components of the language available for you to manipulate, there is almost no restrictions on what you can do to even some of the core components of the language/environment.

In my personal opinion: it might be the case that it would be a challenge to put Smalltalk into a modern production environment. Although I know that there are commercial versions but I have no knowledge of the actual challenges. But I would totally understand that it will not be accepted in the company where I work!

But I think it’s interesting that with the web, we have an interesting way to separate the application from the environment, as there is a very interesting web development framework, and the benefit here is that the end user has only access to the generated page, and completely removed from the open system where the application resides.

At the end, I have also to confess, although I have been interested in it for a very long time, but I have never used it in anything practical :-(, but I think it would be very good for prototyping and incrementally developing something.

At the end, if you are curious, you can check out https://pharo.org/, it’s quite easy to check.

2 Likes

This is what makes me doubt whether I’ll use it as a primary hobby language, but I’m trying to keep an open mind. Seems like there may be a way out, depending on how rich a set of libraries you need. There’s GNU Smalltalk that, unlike Squeak, Pharo, or the javascript based implementations, implements Smalltalk as a regular Unix scripting language with bindings to GTK etc. for a UI. Since I chose as my learning exercise an application I want to use long term, and I won’t want to always start the full world-unto-itself environment that squeak is every time I use it, I’m hoping to use that as an escape hatch later. But compared to a “real” Smalltalk GNU Smalltalk looks to have a pretty impoverished environment. On the bright side, I could use emacs developing with it (or you could use vim). But back to the downsides, it looks to have between zero and one maintainers and the distro packagers seem not to be managing well with it, at least on Debian and NetBSD (OTH Slackware 14.2 + its GNU Smalltalk Slackbuilds script seems fine, but that may be a function of older distro libraries avoiding the build problem I see).

Another smaller, less walled off Smalltalk came up in the context of a (now defunct and never finished?) desktop environment named Étoilé. Étoilé was meant to be a radical departure from typical “Linux” desktops, taking a document centered model and doing various other things differently (but not so differently from Smalltalk?). It was to sit atop GNUstep, which is a GPL licensed version of the graphical foundation libraries from NeXT, the latter of which became Cocoa, the GUI libraries for Macs. Most of this development was in Objective C but David Chisnall and others made a Smalltalk interpreter for it. Randall Schwartz, btw. is also a Perl + Smalltalk guy, so you can find interviews with Chisnall about Étoilé as well as one with Dan Ingalls on Smalltalk in Floss Weekly’s archives. (Ingalls btw. is one of those names that has a connection to a certain corner of the (Canadian) Maritimes, but as far as I know he’s not from there.)

One last thing: RedeemerF, correct me if I’m wrong, but if a person were traveling backwards in time he might describe Smalltalk as Objective C with the C part removed.

1 Like

To be honest I don’t understand GNU Smalltalk, the original Smalltalk was similar to the Squeak/Pharo model. While in GNU, you go back to the source code/runtime dichotomy, which in my mind defeats the Smalltalk way of thinking: being in a living system and changing it from within.

As I mentioned, I respect Smalltalk very much, but I don’t believe it’s suitable for normal applications usage. And that’s why for me the use-case is prototyping and slowly building a system with the participation of the user. So no programmer/end-user split, which is not the case for normal applications.

But building web-apps might be the only way out, in my point of view.

In what I wrote, I didn’t get into the Object-oriented topic, so thank you for bringing this up.

I’m totally unfamiliar with Objective C, my OO knowledge started from Turbo Pascal.

In university, we learned pascal, and when I was looking into building UIs in it, I got introduced to object-oriented programming, and I was hooked. The idea to encapsulate data/behavior was very interesting.

I later moved into Delphi, and I wrote several programs with OO mentality.

I leaned C++, but didn’t actively use it.

But when I learned about Smalltalk I was surprised by how light it was to use.

In the languages that I used, you had to write a lot of code just to define the object, the methods, the implementation,… etc. But in Smalltalk, you just name the message, and the code, with almost no extra cosmetics!

And not to forget: in all other languages, Objects seem to be something special: you have normal data types and Objects, but in Smalltalk, all are objects.

Smalltalk teaches you to really think in the object oriented way. While in other languages, I see that people slip into writing long data manipulation code, and not thinking in intelligent objects.

So, for me, even if I didn’t use it, it influenced the way I think about programs.

1 Like

Interestingly, it seems to have a repl and emacs mode. I’m not saying that’s as good as a real Smalltalk environment, but if you’ve played with Lisp, it could be like that, where you have the repl running in an editor window and could add, change or evaluate objects in the program live by highlighting expressions and pressing macro keys to evaluate them.

It also has a nice little tutorial:

One funny thing. I listened to an old NYC BSD user group video about Plan 9. Someone asked what programming languages exist. Of the handful of languages beside the native shell and C the speaker found one was Squeak. No recent Perl or Python, but Smalltalk is represented! Also ML (OCaml). I need to upgrade to Plan 9 just to force myself to learn more interesting languages.

My user is different. He’s a curmudgeonly old fart who hates the web as technology. :wink:

I have a very bad short term memory, So a repl is not the best interface for me, having direct access to the code and definition of other objects to cut/paste and compose new stuff is easier for me.