Today’s Smalltalk: A Second Look At The First OO Language
blog.smartbear.com
blog.smartbear.com
It wasn't until OSX made Objective-C take off and Rails made Ruby take off that some of the fundamental language features entered the mainstream, and they did so with a gusto that other 'ivory tower' languages wish they could achieve. But only by leaving the image model behind.
It seems like something like Erlang managed to do what Smalltalk tries to do with the image better, allowing for easier to reason about deployment, collaboration, and version control while still letting you deal with a system of relatively opaque boxes of replaceable code.
But only by leaving the image model behind.
That said, I believe the image is a very valid model, and I prefer working on a Pharo environment than anywhere else. However powerful text editors, IDEs and debuggers may be, you can never reach the same level of integration between tools and system if your tools, your language and your system are not the exact same thing.
The problem I see with ST IDEs is the fact that most advanced features work by introspecting live image state and autogenerating some source code, which completely break any attempts to meaningfully define what is (versionable) programmer-written input and what is derived tool output.
In all I haven't seen ST implementation with good development tools that is not at least partially image based.
Code changes in ST-80 (the Smalltalk made public in 1980) were automatically logged outside the image. There were (at least) 3 files:
- the original source code provided with the implementation (.sou)
- the replayable log of changes since the sources file was made (.cha)
- the compiled bytecode and objects that make up the current state of the program (.im)
The most basic approach to re-building was to take the vanilla sources file and vanilla image file provided by the vendor, and "fileIn" the changes you'd made from the change log.
And then there were change sets.
And later, a fine-grain method-level VCS database.
iirc JPMorgan had 4 people employed just as code-librarians to work on code-reuse across their Smalltalk projects.
We had access to VisualWorks at the university back then.
Many developers aren't aware that Eclipse roots are in Visual Age for Smalltalk. Also that Eclipse's workspace concept was an attempt to create a virtual image out of files.
Having said this, Smalltalk's image was a problem in the time when VMs weren't that mainstream in the industry.
Additionally many of modern image based source control systems weren't available back then.
Yes.
>image based source control systems<
"Mastering ENVY/Developer"
We used VisualWorks around 1995 in the university for a few projects.
When I looked again to Smalltalk, Squeak was already around and Monticello was being used.
Squeak, despite being impressive, has always felt like a toy. I like Pharo in spirit, but GUI wise, it looks really off. If I can use a weird metaphor to describe it: it's like reading a brilliant PhD thesis written in Comic Sans. That's what the GUI reminds me of. The content is brilliant, but the presentation really leaves you scratching your head. I know it's not fair to judge an entire development environment off its aesthetics, but people are going to do it anyway.
You cannot sanely use Pharo or Squeak to write native apps right now; that's totally true. You also couldn't do that for Visual Works, except for a very narrow window when they properly emulated enough Windows XP widgets you could probably fake it. But Pharo and Squeak proper look (to me) neither more nor less native than IntelliJ, which people happily use. Both have professional-looking IDEs that do not look native. That doesn't impact you if you're doing web work, command-line work, etc.
There are lots of other reasons I would finger instead (C interop was historically poor, people were historically reticent to use VMware-image-like language environments, etc.), but Pharo and Squeak have looked fine for most purposes for awhile.
You could always do the work yourself to properly emulate whichever UI look and behavior was needed. (Which was both blessing and curse.)
>There are lots of other reasons I would finger instead...<
Lack of standardization between vendor implementations.
I don't have a problem w/ non-native looking GUI's in principle, but I just think Squeak and Pharo are kinda fugly. Bad spacing, weird colors, weird fonts. If that only effected my development environment I could live with it, but if the apps I make are also going to look like that? Ick. The only thing I'd really use it for is writing games where GUI's are always going to be custom anyway. (I think Smalltalk in general would be great for game development actually.)
Another thing is that at least in other smalltalks, it generally used OS windows at least. The controls might look weird, but it does feel like part of the system. Writing code in Squeak feels like you're either using a VM or Remote Desktop, it's just totally isolated.
The thing is most of these, in isolation, aren't deal killers, but once you've added up enough weird points it gets a bit too weird. You could make similar arguments about Java, but I think the difference is in magnitude: Java's weirdness is kind of weird, smalltalk's weirdness is really weird.
http://stackoverflow.com/questions/711140/why-isnt-smalltalk...
Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely.
From Kay:
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.»Object-oriented programming is successful in part because its key technical characteristic—dynamic dispatch-is essential to supporting independent, interoperating extensions; and because interoperable extension is in turn essential to the reuse of architectural code (as in frameworks), and more broadly to the design of modern software ecosystems.
Dynamic dispatch is supported by most statically typed OO languages. C++ virtual member functions are dynamic dispatch. So indeed, dynamic dispatch is one of the key features that makes the distinction between calling methods and sending messages sufficiently un-important that static OO languages are still useful.
What was (perhaps too imprecisely) referred to in my comment above is late/dynamic binding.
The main omission is encapsulation.
It does not provide an easy mechanism for information hiding of the encapsulated instance variables.
I think that is an exceedingly weak argument against calling it OO, especially as you AFAIK can do information hiding in Simula by using the simulation support that was it's raison-d'etre, namely by using the object lifecycle and co-routine support and starting a method to encapsulate state as part of the class body (constructor, effectively).
In any case, I detest Simula with the kind of burning hate you can only experience after having been forced to use it (it was the language used in a compulsory CS course; though admittedly most of my hate stems from the horrible standard libraries), so it won't make me "feel any better".
I just don't see any excuse at all for not calling Simula OO, and I'm trying to understand what basis you have for thinking so. So far the reasons are weak and fuzzy enough that I don't see anything worth changing my opinion over.
Surely you weren't using Simula 1 or Simula 67 in your courses?
Smalltalk, like Lisp Machines, was originally a blend of GUI operating system, development environment and the first real IDE.
By then I was already spoiled with GUI environments from Atari ST, Amiga 500, Windows 3.x and GEM, as well as the typical MS-DOS IDEs from Borland.
So I never saw UNIX that way.
ref: http://shadow.cat/blog/matt-s-trout/but-i-cant-use-cpan/ | https://news.ycombinator.com/item?id=968757
NB. Though I think someone else earlier (Audrey Tang perhaps?) made a similar quote (something like CPAN is my syntax?)
Little Unix took over the world, while big Unix collapsed under its own weight due to things like portability/versioning hell, robustness problems due to faulty tools and text-parsing errors, performance issues and so on. (Partly this was a success catastrophe, of course, for example in how the popularity of Unix resulted in a profusion of different Unix userlands with varying interfaces and bugs.) Also little Unix was more comprehensible from, and more portable to and from, the world of PC (MS-DOS/Windows/Mac) application development, where the environment is more or less the kernel's/OS vendor's APIs. The fact that clearly many more people have bought or read K&R http://www.amazon.com/dp/0131103628/ (with its very little-Unix perspective) than /The Unix Programming Environment/ http://www.amazon.com/dp/013937681X reflects this divergence, and also surely helped to create it.