Today’s Smalltalk: A Second Look At The First OO Language(blog.smartbear.com)
blog.smartbear.com
Today’s Smalltalk: A Second Look At The First OO Language
http://blog.smartbear.com/programming/todays-smalltalk-a-second-look-at-the-first-oo-language/
8 comments
Back in the early 90's Smalltalk was actually starting to be used in the enterprise, but then came Java.
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.
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.
>but then came Java<
Yes.
>image based source control systems<
"Mastering ENVY/Developer"
http://books.google.com/books?id=ld6E19QIMo4C
Yes.
>image based source control systems<
"Mastering ENVY/Developer"
http://books.google.com/books?id=ld6E19QIMo4C
I never heard of ENVY, thanks for the info.
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.
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.
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.
Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven't seen ST implementation with good development tools that is not at least partially image based.
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.
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.
True, they're partially image-based.
In all I haven't seen ST implementation with good development tools that is not at least partially image based.
Dolphin uses images too.
Funny you should mention Erlang, as I think that in its own way, it's treading the lisp/smalltalk path of getting a few things really, really right, and being head and shoulders better for certain kinds of applications. And yet, at the same time, doomed to sooner or later have enough of its goodies ripped off by programming languages that are more mainstream, that will far surpass it in functionality. Go and Scala, for instance, nabbed some of the concurrency stuff, although Go is still missing some of what makes Erlang really distinct.
Dart is trying to rip off Smalltalk and Erlang while putting on Algol sheep's clothing. I have no doubt they will be successful at the Smalltalk part as most of the team seem to be ex-Smalltalkers or ex-Smalltalk VM'ers. I don't know enough about Erlang to know if Dart isolates approximate it.
And yet people are talking about using VM images and the likes of Docker for deployment nowadays.
There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
>enough information to replicate the image from scratch... Smalltalk's images didn't really have this feature<
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.
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.
It's kind of funny that the closest thing to Smalltalk images in wide use are the world most popular object oriented programs: spreadsheet documents (and to an extent ms word documents).
I was always told to fileout my work and then filein into a blank image to remove any cruft that accumulates during development. That's pretty much the same?
There were 2 camps. I like to do my work with a single image over months, saving code to a native (Smalltalk) version control system. Just doing the occasional testing with a fresh image and loading my code in to verify things are doing fine, as well as when deploying.
There were people who worked with others, and people who didn't :-)
We are working on bootstrapping Pharo from source. Have a look here: https://github.com/guillep/PharoKernel But it's tricky and I guess it will take until Pharo4 or Pharo5 until this is in the main release
Smalltalk is incredibly cool, but I think one of the main things stunting it is it doesn't have a great free implementation. The only modern smalltalk environment I've used which felt like a serious environment was VisualWorks, and to download that you have to fill out a form and you can only use it under a "personal use" license.
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.
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.
I get what you're saying, but it's also really weird to me.
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 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're probably right about visual works, I haven't used it since 2005 so I kind of fell in that window.
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.
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.
>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.<
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.
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.
There are a number of great answers on StackOverflow as to why Smalltalk wasn't more popular:
http://stackoverflow.com/questions/711140/why-isnt-smalltalk...
http://stackoverflow.com/questions/711140/why-isnt-smalltalk...
Simula is generaly recognized as the first OO language, so it's a second look at the second OO language at best.
Correct. Although Smalltalk is generally regarded as the first one because the concept "object orientation" was first used in it.
Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely.
From Kay:
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.»I think the reason many later OO languages "missed" messages completely is because the distinction makes little sense in more static languages that lacks a way to dynamically call a method/send a message.
And incidentally, dynamic dispatching is recognised as the key feature of OO: (Cook 2009)
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.
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.
I'm not sure if you're agreeing or disagreeing with me.
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.
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.
Why would you take Kay's definition of OOP as gospel. To me, OOP is all about thinking and coding in terms of object metaphors. Everything else is a supporting detail.
Well, I wouldn't take it as gospel, but as a definition coming from the person who actually invented and first used this term.
Alan Kay is very opinionated, I respect his work but don't take him as a god. There are plenty of other people who did much work in OOP in the 70s and 80s who deserve around similar credits for starting up this field, and let's not forget the Scandinavians who actually invented it.
Simula and to a similar extent SketchPad are proto-OO: they planted the seeds many of the concepts that would go into OO, but Smalltalk is where the seeds were first reaped. But at the end of the day, we are arguing about a label, and its hard to tell where proto-X really becomes X (e.g. anthropologists argue about the line between proto writing and writing).
I'm curious what you believe Simula is lacking to make it fully OO.
See http://www.stanford.edu/class/cs242/slides/2007/simula-small....
The main omission is encapsulation.
The main omission is encapsulation.
Simula does provide encapsulation - it often considered the first language to do so.
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).
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).
Closures as a form of encapsulation is actually very lispy. Simula introduced classes while Sketchpad introduced prototypes (predates Simula by 5 years), so both were very much proto OO in that sense. But if it makes you feel any better, we could define proto OO just to mean OO before that was a term anyone invented.
It's not closures I described. I don't remember if Simula even have closures or not - it's possible it does. The mechanism I described involves message passing between co-routines.
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.
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.
Co-routines are based on what I would call closures (they just continue running rather than returning a value to be called!).
Surely you weren't using Simula 1 or Simula 67 in your courses?
Surely you weren't using Simula 1 or Simula 67 in your courses?
Nice article, but it fails to explain the experience using Smalltalk environment really is.
Smalltalk, like Lisp Machines, was originally a blend of GUI operating system, development environment and the first real IDE.
Smalltalk, like Lisp Machines, was originally a blend of GUI operating system, development environment and the first real IDE.
It's funny. Unix was also meant as an IDE (persistency, logic, machine and user interfaces). It seems they all were trying to reach the same goal in their own way.
The fact that dc was originally intended as basically the Unix system's bignums library http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2... helped to open my eyes to this. I think you could talk about this idea of Unix as "big Unix" and the narrower understanding of Unix programming, dominated by the C APIs, as "little Unix".
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.
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.
I never saw UNIX as an IDE, given its command line interface with ed and vi as editors.
it's a different user interface paradigm, mainly it's not graphically sophisticated (independent streams of text vs dynamic bitmap overlays)and less time integrated (you have to define how and which script to run when something change). But at the time it was thought so, that's how I felt reading bits of this book http://en.wikipedia.org/wiki/The_Unix_Programming_Environmen....
My first UNIX experience was in 1993 with Xenix, followed by almost all commercial variants of it.
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.
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.
UNIX is my IDE. perl5 is my VM. CPAN is my language.
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?)
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?)
If you've historically ignored Smalltalk due to its ecosystem or non-native UIs, I'd like to suggest you take a look at Amber (http://amber-lang.net/), a Smalltalk that runs on Node and works great for web dev.
Simula was the first OO language.
[deleted]
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.