The Absolute No-Frills Quite Ignorant Incomplete Beginner’s Guide to Smalltalk | Hacker News Reader

The Absolute No-Frills Quite Ignorant Incomplete Beginner’s Guide to Smalltalk

deprogrammaticaipsum.com

102 pointszdw70 comments

>GNU Smalltalk turned out to be the perfect dialect for this first contact with Smalltalk, offering a very traditional command-line experience. And Vim provided the syntax highlighting I needed to write those initial lines of code.

Sorry, but if you're using VIM and command line, you're missing all of the best parts of Smalltalk. It's like trying to learn HTML/CSS by designing web pages in Word.

If you want to see what the fuss is really all about, you should download a standalone Pharo VM and latest stable image: https://pharo.org/download

It instantly gives you everything you need to learn and develop things with a modern IDE. It has Playground (better REPL), the famed debugger, the code explorer and a bunch of other things.

Then listen to MOOC: http://mooc.pharo.org/

Then buy The Blue Book on Ebay (Smalltalk-80: The Language and its Implementation). Absolutely worth it. Yes, even now. Yes, even if you don't plan to use SmallTalk.

If you need help, join Pharo Discord or use the mailing list.

Agreed. GNU Smalltalk is a non-starter for me. It is not a standard Smalltak environment.

Early in my career I wrote Smalltalk in a GUI-based environment (VisualWorks/GemStone), with the browser, debugger, transcript, etc. It was an incredible experience.

Later, I used Common Lisp with SLIME and had a very similar experience, at least as productive, except that I was using my preferred IDE (Emacs) and saved the code to normal files so I could use more common tools like grep, SVN/Git, etc. I still built code into an image, which I could update live via the REPL.

I haven't used GNU Smalltalk personally, but I do like the idea of a Smalltalk that's less of an island, particularly if that makes it more palatable to a new generation of programmers.

For a Lisp/Scheme fan who's very on the fence about giving Smalltalk a try, could someone explain in words what all the fuss is about?

https://pharo.org/features

https://pharo.org/success

The author is obviously enthusiastic. Smalltalk is undoubtedly impressive. However, many heroic sagas are rather marketing hypes than based on true facts.

> The Smalltalk galaxy was at the origin of the Graphical User Interface (GUI)

Well, the operating system of the Alto and the first groundbreaking WYSIWYG desktop applications were written in BCPL. Sure, Smalltalk did also run on the Alto, but the responsibles apparently have not considered it suitable for practical use. See e.g. http://xeroxalto.computerhistory.org/xerox_alto_file_system_....

> And since Java was strongly influenced by Objective-C, Smalltalk’s legacy amplified even more.

A bold claim. Actually Java was the implementation of the Simula 67 object model with a C syntax. Smalltalk was not involved here (neither Obj-C). Gosling is quite clear in this respect. The HotSpot JIT eventually was implemented by the folks who were already involved with the Self JIT, but it would be far-fetched to attribute these achievements to Smalltalk.

Even more points, but I'm running out of time.

I am not sure if there were any other implementations of overlapping windows on the Alto other than Smalltalk-76 (which was what Steve Jobs saw in his famous visit to PARC). The windows idea was cleaned up and implemented in more static languages for the Star, of course.

As Dan Ingalls mentions in his recent HOPL (History Of Programming Languages) paper, several times an idea would be discussed between different groups and in the next meeting the Smalltalk guys would show it working while the other groups were still sketching on the whiteboard. Seeing the idea in action would prompt them to also implement it in Mesa or similar language.

Well, the claim was "Graphical User Interface (GUI)", not "overlapping windows". There are many examples of GUIs without overlapping windows and even usability experts claiming that it makes no sense to overlap windows. If I recall correctly neither Mesa nor Cedar used them.

In fact Smalltalk-76 didn't have overlapping Windows, and the people at Apple had already come up with that before seeing the Smalltalk demo. Bill Atkinson describes that here. https://www.cnet.com/news/tracing-the-origins-of-the-macinto...

The screenshot in the article (which _does_ have overlapping windows) is evidently Smalltalk-80 because Smalltalk-76 used the "hollow colon" character in its message syntax where Smalltalk-80 uses the typographic colon.

There might be a misconception. Have a look at Ingalls' 1978 paper "The Smalltalk-76 programming system design and implementation" (https://dl.acm.org/doi/10.1145/512760.512762) which clearly shows overlapping windows. There is even an online version based on the original source: https://www.lively-web.org/users/bert/Smalltalk-76.html

https://cs.gmu.edu/~sean/stuff/java-objc.html

Listen to the original author: https://www.youtube.com/watch?v=ccRtIdlTqlU&feature=youtu.be...

Thanks, cool link!

"And since Java was strongly influenced by Objective-C, Smalltalk's legacy amplified even more."

If this was true, this would be a point against Smalltalk, not for it.

The influence of Smalltalk is generally overestimated, especially also in the referenced article. The author does not present evidence for his assertions, but simply the opinions of any people.

Yes. At the origin... as in XEROX Palo Alto Research Center, not the origin.

The origin of the graphical user interface was actually elswhere. The https://en.wikipedia.org/wiki/Semi-Automatic_Ground_Environm... system had a display system with a "graphical user interface" and a "ligth gun" (i.e. pointing device) by 1958; also e.g. https://en.wikipedia.org/wiki/Sketchpad had similar features in 1963; but these were CRT displays with vector drawings. The Alto in 1973 in contrast had a bitmaped screen and the first GUI following a desktop metapher (see e.g. https://www.microsoft.com/en-us/research/publication/alto-pe... or http://bwlampson.site/38-AltoSoftware/Abstract.html).

> Smalltalk is undoubtedly impressive.

Maybe ST80 was what Alan Kay needed.

Maybe what the rest-of-us needed was Modular Smalltalk?

"An Overview of Modular Smalltalk"

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=An+O...

Actually Smalltalk-72 seems to better reflect Kay's vision of "object-oriented" than Smalltalk-80; see e.g. https://dl.acm.org/doi/abs/10.1145/3386335. Using tools like ENVY or Objectory you could do decent work in ST. Nevertheless, I switched to other languages like C++ and Java.

> Using tools like ENVY…

As many of us did.

What I had not previously considered was how the novelty of gui software and the vision may have overwhelmed more mundane concerns.

Seems like — even with the image, even with the ST80 language — there could have been a coarse separation into layers of functionality, and that would have been enough to address some of the practical concerns.

But that was mundane, not fun.

There were namespaces (aka environments).

My speculation was what it might have been like if PARC ST80 had a coarse separation into layers of functionality before release to the world.

If PARC ST80 had provided both:

no-gui no-ide boostrapped image + libs

:and:

bootstrapped image + libs + gui

:and:

bootstrapped image + libs + gui + tools

:as separate images.

There’s enough beginners guides to smalltalk. What there is none of is “smalltalk for working programmers”. Or “do meaningful things with smalltalk”.

Pharo has some good guide books, but they still keep things contained just within the single VM.

How do I read user input and spit something back out? Does all the activity need to take place inside the VM? Seems so constraining.

Can you be more specific? I'm sure you realize that there is full modern UI support in any reasonably up to date Smalltalk implementation, it even includes mouse and keyboard input support. If you mean accessing data from the filesystem, yes that can be done as well. And guess what, there is even network support.

That said, if it comes down to more OS specific stuff, then yes, you may need to do more work. Squeak/Pharo very directly support loading external modules (platform specific code written specifically to a VM-specific API) as well as a reasonably competent FFI implementation. I have less knowledge of other implementations but I'm sure something similar is also available.

> I'm sure you realize that there is full modern UI support in any reasonably up to date Smalltalk implementation

Contained to the VM itself, yes? I've never seen any information on packaging a GUI and making it presentable to a user. For example, what if I want to style/brand it to not look like Pharo or a smalltalk VM? How limited am I with that?

> If you mean accessing data from the filesystem, yes that can be done as well.

How? I've never seen it explained in a book, but I could easily have missed it. That's more of what I'm talking about though. For example, how do I read / parse a CSV for the computer? Or better yet, download a CSV from the internet and then parse it.

> And guess what, there is even network support.

I'm aware of this because I know there's a web framework. I think there's an entire book on this for Pharo.

Different Smalltalk implementations have done things differently — so the best answer to many questions is "it depends".

> what if I want to style/brand it to not look like Pharo or a smalltalk VM?

Use emulated platform widgets or native widgets or invent your own widgets.

> Or better yet

http://books.pharo.org/booklet-Scraping/html/scrapingbook.ht...

> How do I read user input and spit something back out?

I don't actually use Pharo though I've toyed with it; reading files is well documented (e.g., in the free book Deep Into Pharo). While I think there are convenience methods for standard input and output, but you can at a minimum use normal file access with /dev/stdin and /dev/stdout.

I seriously thought this was going to be a guide to small talk - as in how to start conversations and keep them going.

LOL, +1.

My first thought was "Oh nice, a guide to help introspective folks to start a conversation"

I'm pretty sure there's a decent audience for such a guide, which is not toned like "Stu the Cockatoo is New at the Zoo". =)

I present: https://www.reddit.com/r/NoStupidQuestions/comments/dw8f8c/i...

Someone asking how to order a sandwich (from a pretty stressful sandwich shop..) There's a huge audience for what most people consider the simple stuff.

you're not alone lol

Same here. Does anyone have a good one?

That happens a lot on the smalltalk programming language subreddit. Thankfully, most don't mind as there is very little activity anyway.

LOL that's actually hilarious! They are so lonely in their empty reddit that they're maybe even happy when anyone comes around just to say hi or talk about the weather?!

Lol. I think it's more so that there are so few posts that it's pretty understandable why someone would make that mistake.

I think smalltalk is neat, but have never been too successful in getting up to speed. It doesn't help that I could never use it where I work. Also, although the stdlib is great, I still often have no idea how to do something. Compare that to Python, Perl, C#, Java, Bash, Powershell....etc. With those languages, I can ask nearly anything and get find 10 websites with examples and code snippets.

If anyone is interested in learning more about Smalltalk by talking to actual users, the UK Smalltalk User Group[1] is running monthly online meetings with presentations. We have recently started recording these meetings, and publishing them online [2]

[1] https://www.uksmalltalk.org/ [2] https://vimeo.com/ukstug

Are any of the commercial Smalltalk implementations worth using anymore? They kinda of strike me as a relic of a past time and I don't understand how some of them are still in business. The Cincom people run "Smalltalk job board" with a depressingly small amount of monthly listings many which involve rewriting Smalltalk systems or are written in such a way which makes you imagine very little Smalltalk is actually used.

Dolphin is now open source and still a viable way to build Win32 apps. If only I had a need to write apps solely for Windows...

Well there are a few companies that use Cincom, for example Deutsche Bahn, HRworks, OOCL.

Others use Pharo.

Instantiations is supporting old IBM VASmalltalk installations.

But I don't think it makes to much sense in starting new Smalltalk developments besides the learning experience.

I tried to take Pharo for a test drive a while back, but it doesn't support hidpi displays. It would be really cool if someone made an implementation with an IDE for the JVM, like Clojure. Something to make it practical and fit in with modern ecosystems would be great.

> actually used

Legacy systems are actually used.

If you don't have legacy systems then ride the wave of enthusiasm that comes with using the latest newest tech.

Nice article. I would just add the smalltalk is not just a language, but a whole environment. If you have the time I encourage you to give image based development a go. It's still the most productive programming environment I have ever used.

There are notable versions of Smalltalk such as GNU Smalltalk or SOM which are not running in a virtual image, but can be used like normal file based programming languages. Virtual image based systems have some advantages, but even more disadvantages when it comes to deployment and integration. No wonder that the concept did not catch on. Today there are variants of it, e.g. in Dart, to shorten the start-up time.

GNU Smalltalk does run in an image. The main differences are: 1) it's possible and easy to rebuild the image from scratch 2) it's relatively common to reuse the same image and load files into it through the command line, without saving it the image back at the end of every execution. However the image is still there. :)

Well, there is the Object Memory as defined in the Bluebook, but otherwise it's file based. There are important differences to Smalltalk-80, where even the compiler and the scheduler are part of an "eternal" (i.e. with no unique origin) virtual image.

The guy you're replying to is the guy behind GNU Smalltalk.

So what? I also implemented a couple of Smalltalk VMs, see https://github.com/rochus-keller/Smalltalk or https://github.com/rochus-keller/som, and I also spent a lot of time with the GNU ST implementation.

So what? So maybe you should listen to what they say about GNU Smalltalk. They might know a few things.

This is a discussion based on provable facts. Science needs no proof of authority.

Saying GNU Smalltalk "is not running in a virtual image" is incorrect.

For example, GNU Smalltalk does not load the whole standard library from scratch when you start it, the way for example Python does when you "import os". In addition it's perfectly possible (or even common) to load more packages into the image so that any file-based scripts you launch load faster.

And even though by default the compiler is written in C, if you load the "Compiler" package then GNU Smalltalk switches on the fly to a parser and bytecode compiler that's written in Smalltalk. If you load the "Debugger" package, exceptions will take you to a gdb-like debugger, with a companion text-based interactive inspector. (The scheduler is part of the image in the same way as in Smalltalk-80, and features such as exception handling and the debugger are entirely implemented in Smalltalk; the only custom feature of the GNU Smalltalk VM that the debugger uses is single-stepping).

So even though the image is not as pervasive as in Smalltalk 80 or Pharo (development happens in files and builds upon an image, instead of happening straight in the image), the image is there and it's not just an implementation detail.

Thanks for the explanation. It's about the wording. The fellow used "whole environment" and "image based development". I used the term "virtual image" from the Bluebook to mean the same. The Bluebook says "Two major components of the Smalltalk-80 system can be distinguished: the virtual image and the virtual machine. 1. The virtual image consists of all of the objects in the system [...]". The important point here is "all of the objects", especially also the compiler. There is no Smalltalk language outside of a Smalltalk-80 virtual image. You cannot do anything in an original Bluebook system without running the virtual image. That's what the fellow referred to by "whole environment" and I by "running in a virtual image". In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. There is a compiler and and interpreter, and being "file based" is known to be a core benefit proposition of GNU Smalltalk, isn't it?

> In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable.

True but the first thing the VM does if it does not give an image is create empty classes and load files that define those classes. Only then does it do whatever it was asked to do, so the ObjectMemory was not loaded from a persisted state but is effectively indistinguishable from one.

Once the image exists, the main difference between the GST file-based approach and the traditional Smalltalk-80 image-based development is that saving the image back is not "saving your work" but "preparing a cache" in which to load source files ephemerally. But that's just an additional possible use of the image that could be implemented in Squeak/Pharo as well, just like GST had class browser for development if you really wanted.

Thanks. As I said, it's just about the wording. In the matter we are talking about the same. My whole point was to demonstrate to the fellow that it is well possible to use the Smalltalk language without being forced to always use a "whole environment", and that the ST-80 virtual image approach also has disadvantages. Obviously you came to the same conclusion.

Is Windows support there now?

I honestly haven't done any serious work on GNU Smalltalk in the last 10 years, but it should have worked already back then. The GUI used GTK+, but it was still on 2.x.

> but even more disadvantages when it comes to deployment and integration.

For example? Compared to what?

> For example

Getting rid of objects not belonging to the application to be deployed is difficult or impossible. According to my analysis of the original ST80 v2 virtual image there is a very high interdependency among objects; and since there is no static type information, many dependencies are not statically identifiable. There are also many objects that have not been created or initialized anywhere in the source code (neither in the sources file nor in the Bluebook interpreter), but on which the functionality of the system depends. Versioning of objects and corresponding source code is difficult, also combining a certain version of different components or communication drivers with other parts to be integrated, and so on.

> Compared to what?

E.g. Java or C++ or any technology with clearly identifiable compilation and configuration units.

> Getting rid of objects not belonging to the application to be deployed is difficult or impossible.

1) So don't get-rid, now where is "the problem"?

2) So only add "belonging to the application" stuff to the base image.

> … objects that have not been created or initialized anywhere in the source code … but on which the functionality of the system depends.

3) So those are objects that will always be deployed, now where is "the problem"?

> Versioning of objects and corresponding source code is difficult…

So application source code isn't just text that can be saved in text files and versioned like other text files, and loaded into a Smalltalk image in a scriptable repeatable build process?

> So don't get-rid, now where is "the problem"?

Well, not every software manufacturer want's to deploy all development tools used to develop the software and possibly code which is only meant to be used inhouse. And if you e.g. deploy to safety-related targets you even have to demonstrate that there is no "dead code" (e.g. DO-178). Of course it doesn't matter for hobby or non-critical applications.

> So application source code isn't just text that can be saved in text files and versioned like other text files

In ST80 source code is just an external dump file; the actual configuration unit is the virtual image. Bootstrapping a virtual image from source code in ST80 is very difficult or nearly impossible.

No, not "all development tools used to develop the software and possibly code which is only meant to be used inhouse".

Just the development tools included in the base Smalltalk implementation — we can choose whether or not to include other stuff.

> Of course it doesn't matter for …

Apparently, it doesn't matter for the whole range of business critical applications that do not need to be DO-178 certified.

> In ST80 source code is just an external dump file …

Do you mean that in ST80 source code can be saved as a text file and versioned like other text files?

> Bootstrapping a virtual image …

We can use a base virtual image someone else implemented. (Like we use a JVM someone else implemented, …)

Well, you were asking.

From your answers so far, it doesn't seem at-all obvious that were considering disadvantages of "virtual image based systems" rather than particular disadvantages of the ST80 implementation.

Would a Smalltalk image without gui classes not be feasible?

I spent much of my life in an with Smalltalk images (some would say too much), and there were also the big names and figures when I did Smalltalk projects in the nineties. Some of the issues could be handled spending a lot of money. The basic concepts (and issues) are the same in all Bluebook offsprings. You probably mean GNU ST; it has the advantage that there is a compiler and library available outside of virtual images and you can use it like a "normal" compiled language and easily re-assemble a virtual image with the objects and versions required. This allows you to use the image as a cache to reduce startup times like e.g. Dart does it. But this is not the original Smalltalk virtual image idea, i.e. not the "whole environment" the fellow referred to.

> You probably mean GNU ST

I mean that "deploy all development tools used to develop the software" seems to be a separable from "Bootstrapping a virtual image from source code in ST80 is very difficult or nearly impossible".

bootstrapped image + libs + gui + tools + app ==> development environment

bootstrapped image + libs + gui + app ==> gui deployment

bootstrapped image + libs + app ==> headless deployment

> smalltalk is not just a language, but a whole environment

I mean could the fellow have his "whole environment" for development - and - have his no-gui no-ide boostrapped image + libs + app for deployment.

Not adding anything to the discussion,but when you click on the cookie policy it redirects to a 404. Then what I am accepting to in "Accept cookie policy" ?

Also missing a nope button.

'incomplete' alright ^^

Sorry, that's my fault, I hadn't published the privacy policy page! I've fixed it now, thanks for flagging that.

fwiw

https://news.ycombinator.com/item?id=24720801

Reply on news.ycombinator.com