Smalltalk is not a perfect language. What are its shortcomings? | Hacker News Reader

Smalltalk is not a perfect language. What are its shortcomings?

itnext.io

21 pointsonig199032 comments

> Seventh, Smalltalk represents a new programming model where the image is a snapshot of the total execution state of the application (including the Smalltalk system).

"New"?? Lisp has worked this way since the mid-1960s.

And now MSWin and Ubuntu also sleep.

The equivalent would be hibernation, though.

True. I'm really not sure why I don't use either.

hibernation and sleep doesn't have much to do with 'images' or Lisp 'worlds'.

On a Symbolics Lisp Machine I would create lots of runtime objects in memory. These objects would be state of my development environment, my applications, my user data, etc.

I can then save a world to disk, which is basically a memory dump (possibly with memory optimizations like doing a full GC, defragmentation of memory, sorting of objects, improving locality of data structures, etc.). I can also save a chain of delta worlds. As a user I can keep several of these images or delta images on disk and boot into the one I'm interested in. I could also ship the image to another user and have him/her boot that image or even myself have my Lisp Machine boot such an image over the network from a server.

The Lisp Machine development environment tracked changes to the currently active software in memory (source locations, versions, patches, ...). Thus a typical way to work was to boot the latest delta worlds, log into it as a user and load all available patches to the loaded software - typically in a networked environment these patches would be loaded from a central server - even the some of the base images might be prepared on a central server. Loading code ways relatively slow (large disks for these systems were slow - over ESDI or early SCSI) and booting an image was relatively fast - a full boot on an end 80s Lisp Machine took roughly 3 minutes.

OTOH something like Interlisp-D was relatively similar to how Smalltalk 80 worked. Interlisp-D inherited the image-based development from BBN Lisp, which is from the end 60s / early 70s.

> First, Smalltalk is dynamically typed. People who believe static typing is a better way to code will view this as a shortcoming. I don’t.

"People might raise problem X, but nah" isn't an overly convincing way to argue for dynamic typing.

Most Smalltalks have two types: SmallInteger and Object. And they are very strongly typed.

There is plenty of online content discussing the pros and cons of both static and dynamic types. Discussing it in this post would be tangential, I believe. The authors point is to list shortcomings of Smalltalk, not so much trying to convince us on the advantages of dynamic types.

I think this is really an article about Squeak, one specific implementation of Smalltalk, along with a few comments about GNU Smalltalk. Smalltalk is, like Lisp, really a collection of implementations sharing particular features.

ParcPlace Smalltalk was different from Digitalk SmallTalk/V was different from IBM Visual Age Smalltalk was different from CinCom Smalltalk was different from Dolphin was different from Squeak was different from GNU Smalltalk.

Hello world being 50MB might be one.

How big is your operating system?

Smaller than it would be if it were written in Smalltalk instead of C. (I'm kidding, I like Smalltalk, but the comparison to an OS doesn't do much when we're discussing the size of very small bits of code).

Actually, having written operating systems in C, Objective-C and Smalltalk I can say that unless we are talking about something MS-DOS like in simplicity then the Smalltalk OS will be much smaller than the C one.

The unstripped binary for the Little Smalltalk 3 virtual machine is 55,229 bytes on my Linux computer and the systemImage file, at 102,100 bytes, includes mostly things that would not be needed for a "hello world" program.

What is 50MB supposed to be the size-of ?

What is the JVM equivalent ?

Let's say that the size we're measuring is the distributable unit. I give you this, and assuming you've got common dependencies, you can run it without building or compiling.

I only have a few minutes worth of knowledge of Smalltalk, but...

  $ cat hello.st
  #!/usr/bin/gst

  Transcript show: 'Hello World!'.
  Transcript cr.
  $ ./hello.st  
  Hello World!
  $ du -b hello.st 
  64 hello.st

That's 64 bytes in a distributable unit. So, what's 50MB?

Even combining the whole of the smalltalk package I used, it's only 18M:

  $ du -bhc $(pacman -Qlq smalltalk | grep -v '/$') | tail -1
  18M total

Gnu Smalltalk isn't used often (as far as I'm aware). If you use something more common like Pharo or Squeak, the base image includes things like the IDE, window environment, etc. and accounts for the 50MB size.

Edit

I should mention that shipping smalltalk applications generally means shipping the entire image. While there is work to make distributing just the code easier (EG. iceberg mentioned in the article) I don't believe this is yet a common practice. Even in that scenario however, you'll need an image to run that code and it will still be 50+MB.

> … shipping smalltalk applications generally means …

Is that what Edward Diego meant?

Is Hello world what "smalltalk applications" generally means?

That is what I took "distributable unit" to mean, yes. Perhaps it's not fair to say that this is true for "hello world" as you've shown in your Visual Works example and jolmg has shown with GST.

> not fair

That's not the issue.

Not sensible is the issue.

What relevance does the distributable size of hello world have when the goal is to develop enterprise scale systems?

It's like you shipped your shell, text editor, debugger and more with every program you made in Java. :D

Why would you ship those with a release of a smalltalk application?

Quite a good question.

I think the most broadly applicable answer now is simply that including those development tools usually requires less-effort than not doing so.

That's a legacy from Smalltalk-80 application development at Xerox Special Information Systems (XSIS, back in the mid 1980s):

— "My response … is to remind the customer that the system is designed so that they can easily and freely change it. This concept is a new one to many people because traditional programming environments carefully protect system code from modification. The Smalltalk-80 environment treats system code and user code alike. Mold the system into an environment that suits your needs. The researchers designed the system so that they could experiment with creating new systems; the changeability of all of the system parts is a necessary attribute of this research."

p501 "Smalltalk - The Interactive Programming Environment", 1984.

Of course, some Smalltalk implementations did things differently:

- Dolphin Smalltalk could ship applications packaged as MSWin dlls

- Resilient Smalltalk used a completely separate Eclipse development environment to connect over TCP/IP to a VM+image embedded-system

    ~$ ./visual ./visualnc64.im -nogui -doit "Stdout nextPutAll: 'Hello world'; cr. ObjectMemory quit"

Hello world

~$

If you read further in the documentation, you can find the bit where you can remove all the objects you don't need for anything other than emitting "Hello World" on the terminal. On an older version of Squeak I was able to get it down to about 250k, which is about on par with the Golang hello world.

> However, some people mistakenly view this as a shortcoming because they believe that the image prevents you from using your favourite programming tools, like Emacs, GitHub, diff, grep, etc. That’s not actually true.

Talk about... I'm about to go Frank Grimes here. Images are bad because you want a visible and complete description of your program, not some image with details squirreled away in nooks and crannies. It's basic engineering to have an exhaustive and explicit description of what your program is doing.

Smalltalk's main shortcoming is that it offers nothing useful that other languages lack. And it lacks stuff other languages offer. Other languages let you look at the code and see that certain things cannot happen, while looking at a small fraction of the code. Smalltalk doesn't offer this. That's a serious deficiency.

> Images are bad because

Because we lack the wits to archive source-code elsewhere?

Save the source-code in files (or some other repository) and when desired build a working image — duplicate the distro image and fileIn your own source-code files (hint: that’s scriptable) — fileOut changes as convenient.

I'm not a fan of the image thing as well, but I suspect it's just a learned behavior. Most of us view code like a book, something to be ready in an orderly fashion. But if you view it like a sculpture, an image is like one. You start with a big block of wood, ice, stone and start chipping away and shaping it into what you wish, anytime you come back to it, you have that same exact block with all the things you have done to it.

When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on the fly. So, you have control over how the source is textually written and organized, but can run your UI and see how things get affected by your changes immediately. That’s nice when writing UI code, since you get a tight REPL experience, and lots of little changes to make and try out, without having to restart your program, navigate to the screen, etc. But also, there is a clean separation between your permanent code and your temporary changes. There’s no fileOut business, and no downside.

The proper form of your analogy is that you want to chip away at your code, not at a runtime image. The REPL is the advantage here (in Smalltalk), not the fact that there is an image.

When developing in Smalltalk, you're editing class definitions and method definitions meant to run sometime in the future but can evaluate the class definitions and method definitions on the fly. … But also, there is a clean separation between your permanent code and your temporary changes. … The proper form of your analogy is that you want to chip away at your code, not at text scattered among files. The lively computation is the advantage here (in Smalltalk), not the fact that there is an image.

The image just makes the lively computation persistent.

> When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on the fly. So, you have control over how the source is textually written and organized

Interlisp did not work like that; editing took place on in-memory lists and the definitions would be serialized into files on request, which were sort of treated like mini databases. Image-based development was used a lot on Symbolics machines, there are advantages to it over always loading from flat text files.

> Most of us view code like a book, something to be ready in an orderly fashion.

Do authors write books sequentially, first-chapter to last?

Is code used sequentially, only in the same order those procedures are defined in a text-file?

Does the text-file order of procedure definitions help us understand the call sequence?

Reply on news.ycombinator.com