Comment by Jenk | Hacker News Reader

Comment by Jenk | Hacker News Reader

Parent Full thread

I worked with Smalltalk for a number of years, and was even present at discussion during the ESUG (European Smalltalk User Group) meetup in 2008 that was the very birthplace of Pharo, though admittedly was a little out of my depth with some of the technicalities (and politics) that caused the rift from Squeak.

I loved working with Smalltalk as a language, and developing inside the fully integrated VM. It's my fondest development experience to date.

I really didn't love deploying Smalltalk applications and even collaborating was more difficult than file based languages/systems. Deployments (at the time) were a practice of shipping the image to the servers that needed to run. There literally is no (separate) "runtime" it's all in the image. This thing got bulky real quick.

I haven't touched Smalltalk in a while, so maybe (hopefully?) things have improved and deployments are no longer a problem.

I played around with Squeak over Christmas (basically trying to implement a ray tracer, although I started to lose interest after I rolled my own Matrix implementation with all the transforms).

As far as working with the code, debugging, reading and writing were concerned, it was great. It really gave me a taste for thoughtful OOP, simple documentation, and even TDD-style development again, because the whole environment just worked perfectly for it in a way that would be hard to reproduce in a traditional language where you're organising things on the file system.

Dealing with version control was a little more awkward (getting Git in place), and I'm glad I didn't have to worry about deployment or any kind of maintenance. Possibly GNU Smalltalk would be an ideal middle-ground there.

It's also one of the few occasions where I've not really had to rely on the internet so much to get help when I need it. It's been enough to have a book on Smalltalk and to rely on the documentation in the IDE.

In the Squeak/Pharo world, a built in tool called Iceberg handles VCS integration and is pretty slick. You can also easily load packages from external sources. In practice most packages are installed from their GitHub repo.

Deployments can start with a stock image, load your code and run, without you having to move around an actual binary blob from machine to machine.

My first Smalltalk was Smalltalk/V.

I fail to see how shipping a tree shaked version of the image was any different than shipping a C++ application with MVSCRT.dll, for example.

As for source control, while it was indeed a problem with workarounds like text export/import, image based SCM were eventually developed.

Reply on news.ycombinator.com