Hacker News Reader

I did work in Smalltalk in the university and I must say that in practice it was horrible to work with.

It was very common to have the image corrupted -- imagine that you by mistake add a bug to your code. Now the live version you're dealing with is just unworkable and you have to find the last version that worked (because in practice the code you add is live with the code of your whole system in just a single place, so, anything bad you did affected not only your target env it also affected your dev env).

-- version control was basically saving the whole image and no, you didn't have a way to diff 2 different images.

I think that the current state where you edit text files and run your code based on those (and which you can sanely version control) and edit with a separate IDE is a much saner approach.

Thanks for sharing your experience with working with Smalltalk.

I wonder in a parallel universe, a smalltalk one, what VCS would have been like? Would the "last version that worked" also just have been an object?

Check out the Monticello VCS for Smalltalk.

https://wiki.squeak.org/squeak/1287

You've been given a mistaken impression of the Smalltalk-80 development process.

Changes were automatically logged to an external text file and could be recovered.

By the late '80s there was multi-user fine-grained version control: ENVY/Developer

https://www.google.com/books/edition/Mastering_ENVY_Develope...

Fortunately things have changed in the intervening years. Pharo, for example, includes a complete git integration:

https://github.com/pharo-vcs/iceberg

> version control was basically saving the whole image

No, it really wasn't!

Is it possible that there were ways to archive code with Smalltalk that you did not know?

iow you were doing it wrong.

"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.

…

The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."

1984 Smalltalk-80 The Interactive Programming Environment page 46

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

----

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)

1984 "Smalltalk-80 The Interactive Programming Environment"

I wanted to play with Smalltalk on a new machine similar to raspberry pi but I was struggling to port squeak to it. Generated C source didn’t compile even though raspberry pi version should work there.

So now what? The only way forward is to really dig deeply into the ‘beauty” of C to make it work? This is exactly what I was trying to avoid in the first place!)

Perhaps you are the right person to ask. Do you think it is a design flaw to have vm tightly coupled with C and all it’s compilation nightmares ?

It doesn’t compile/run on the machine, possibly due to the lack of sound hardware but excluding sound package didn’t help. Where/what is the best way to get help with that? Perhaps you can give a wise advice on that.

What is the difference between "sending a smalltalk message" and "calling a method" (i.e., jumping the central thread of execution to a particular label until a ret instruction is reached)? This isn't truly distributed, it's still centralized. If one method gets stuck in a loop, the entire system grinds to a halt. If each "object" or "service" gets its own process or thread however, this doesn't happen, and you get graceful system degradation which can be mitigated by spinning up redundant services.

You're right, most businesses don't need microservices, indeed "monolithic" (not distributed) architectures are totally fine and they have less overhead. And yeah probably a lot of businesses that do use microservices don't even make use of the benefits of a distributed system yet have all of the drawbacks. That's just people being people (stupid).

If we wrote things as objects sending messages we might be able to disregard their remoteness most of the time. The value could be in writing software which wouldn't need to change much as you changed the way it's getting used radically.

For a crappy example, a tool like rsync can talk to a copy of itself over any kind of stream and sync things that are remote so because it has this abstraction, you can rsync over ssh but you're not limited to ssh. If some future stream protocol arises rsync could probably be made to work over it without a rewrite.

If we had gone down the path of Smalltalk rather than the UNIX-like path we have taken, I imagine we'd see systems with asynchronous message-passing semantics using processes/threads. Think something like E (or now Spritely Goblins, which takes inspiration from it) with at least one separate vat per "application". This would result in a system like Smalltalk, but with concurrency to prevent the situation you're describing.

I think we'd be in a much better place today had we taken that path, for a number of reasons.

In Smalltalk, calling a method is what the system does after a message is sent and the system looks up the receiver and its class hierarchy. This is a little different from C++ where the message dispatch is just vtable lookup by the calling code, because the system might have different behavior, such as changing the message to a #doesNotUnderstand: message.

However, in your question it is not much different because the default approach is synchronous. Yes, the calling process waits for the receiver to send a response. This has been one of the sticking points of remoting objects since the beginning, that you cannot treat the network as completely transparent. The options are the same as in other languages: promises, callbacks, forking a process, etc.

On the other hand, having a simple representation for network calls that the runtime can figure out for you automatically is pretty cool. You can ask Smalltalk to create proxies on the fly that act like the real thing but do the marshalling and network calls. The same was true for RMI in Java, which may have been based on Smalltalk and/or Modula-3. Comparing this to COM or CORBA, where the representation is defined externally, or to SOAP or some JSON api, where all bets are off, keeping everything in one system makes this stuff easy.

Smalltalk was, and in many ways remains, my favorite programming language - as a language. But the image-based development environment, and the performance of the system, were both awful.

As for message passing, and the potential for remote objects - well add CORBA into the mix of elegant, but ultimately unsustainable technologies alongside Smalltalk.

The world was not ready for "pure" OO in the 80s, and I'm not sure it's ready now. Some things really are better in the mind, than in practice.

Yes we are living in a worse version of the world that has come about because the more beautiful ideas didn't make it out in a wider way and with the right level of practicality-at-the-time to be scaled up.

We probably will get there eventually but by a very very circuitous route.