Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

itnext.io

Post reply on HN
Print view View original

21–30 of 33 posts

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

#21

Post by epsilon_greedy »

igouy wrote: post #15
epsilon_greedy wrote: post #12

Earlier quoted context omitted.

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'…

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

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

#22

Post by dingosity »

BubRoss wrote: post #2

Hello world being 50MB might be one.

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.

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

#23

Post by igouy »

SamReidHughes wrote: post #20

> 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…

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

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

#24

Post by segmondy »

SamReidHughes wrote: post #20

> 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…

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.

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

#25

Post by SamReidHughes »

segmondy wrote: post #24
SamReidHughes wrote: post #20

> 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…

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 d…

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.

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

#26

Post by igouy »

SamReidHughes wrote: post #25
segmondy wrote: post #24

Earlier quoted context omitted.

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 d…

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 ch…

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.

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

#28

Post by sedachv »

SamReidHughes wrote: post #25
segmondy wrote: post #24

Earlier quoted context omitted.

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 d…

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 ch…

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

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

#29

Post by lispm »

igouy wrote: post #27
jolmg wrote: post #19

Earlier quoted context omitted.

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.

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

#30

Post by igouy »

epsilon_greedy wrote: post #21
igouy wrote: post #15

Earlier quoted context omitted.

> … 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?

Post reply on HN