
Smalltalk is not a perfect language. What are its shortcomings? - onig1990
https://itnext.io/smalltalk-is-not-a-perfect-language-what-are-its-shortcomings-72ac93b1ef0d?source=friends_link&sk=824399d2e9040849d1a82579e51a6574
======
ScottBurson
> 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.

~~~
igouy
And now MSWin and Ubuntu also sleep.

~~~
jolmg
The equivalent would be hibernation, though.

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

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

------
EdwardDiego
> 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.

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

------
BubRoss
Hello world being 50MB might be one.

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

What is the JVM equivalent ?

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

~~~
jolmg
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

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

~~~
igouy
> … shipping smalltalk applications generally means …

Is that what Edward Diego meant?

Is _Hello world_ what "smalltalk applications" generally means?

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

~~~
igouy
> 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?

------
SamReidHughes
> 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.

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

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

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

