Remember Smalltalk? (2008)(blogs.gartner.com)
blogs.gartner.com
Remember Smalltalk? (2008)
http://blogs.gartner.com/mark_driver/2008/10/09/remember-smalltalk/
8 comments
It's simple. Java was free, Smalltalk was $50,000/seat.
Gartner also had an active hand in killing Smalltalk in the enterprise.
CTOs would pay Gartner millions of dollars to have them confirm their bias to go 100% Java/Windows/IBM.
Not that ParcPlace did themselves any favors.
CTOs would pay Gartner millions of dollars to have them confirm their bias to go 100% Java/Windows/IBM.
Not that ParcPlace did themselves any favors.
Basically correct, except for the price of $50K. In the early 1980s I had a Xerox Lisp Machine (cost about $25K with extra RAM). Xerox let me use a Smalltalk license for a while for evaluation - I forget the exact price, but it was about $5K.
Now, nearly all programming languages are free :-)
Pharo Smalltalk (based on Squeak) is very nice, and runs on Mac, Windows, or Linux box using very little resources.
Now, nearly all programming languages are free :-)
Pharo Smalltalk (based on Squeak) is very nice, and runs on Mac, Windows, or Linux box using very little resources.
I learnt Java in '95 and was getting paid for it in '96 - the option to become a Smalltalk developer simply never existed for me - you already had to be one, to get access to it! That it faded into irrelevance is completely unsurprising, where was the fresh blood supposed to come from?
I rode the Java wave early on also. A good ride.
Smalltalk is still used, as is Common Lisp, Scheme, etc. Just because languages are only used for < 1% of commercial projects does not mean that people skilled in their use shouldn't use them. My go-to languages right now are Clojure, Java, and JavaScript, but, I still like to code occasionally in Pharo Smalltalk (good online tutorials, BTW, if you want to play with Pharo).
Smalltalk is still used, as is Common Lisp, Scheme, etc. Just because languages are only used for < 1% of commercial projects does not mean that people skilled in their use shouldn't use them. My go-to languages right now are Clojure, Java, and JavaScript, but, I still like to code occasionally in Pharo Smalltalk (good online tutorials, BTW, if you want to play with Pharo).
I started my professional career doing Smalltalk in the early 90's. The experience of development as a conversation in which I persuade a system to behave was really formative.
In a lot of ways, I'm still programming in Smalltalk... just in other languages.
In a lot of ways, I'm still programming in Smalltalk... just in other languages.
So, what's the advantage of Smalltalk over Ruby?
It seems like Ruby is a better Perl than Perl, a better Smalltalk than Smalltalk, and a better Python than Python.
It's slow (though that's getting better) but otherwise it allows genuinely beautiful system design.
It seems like Ruby is a better Perl than Perl, a better Smalltalk than Smalltalk, and a better Python than Python.
It's slow (though that's getting better) but otherwise it allows genuinely beautiful system design.
>a better Python than Python
As someone who's quite the Ruby fan, this is the only one on the list I'd object to.
There's a very real philosophical difference between the two, which I'd identify as being their attitude to "magic". Ruby is OK with a certain level of increased complexity and semi-hidden behaviour if it means more expressivity. Python, on the other hand, prefers simplicity and explicitness.
It's not the most radical divide, and I don't really think either one is the One True Philosophy; they're just different. And neither is better at embodying the other's philosophy.
As someone who's quite the Ruby fan, this is the only one on the list I'd object to.
There's a very real philosophical difference between the two, which I'd identify as being their attitude to "magic". Ruby is OK with a certain level of increased complexity and semi-hidden behaviour if it means more expressivity. Python, on the other hand, prefers simplicity and explicitness.
It's not the most radical divide, and I don't really think either one is the One True Philosophy; they're just different. And neither is better at embodying the other's philosophy.
Well I mean that's Smalltalk: Things that look like magic in Ruby look as simple and explicit as Python in Smalltalk.
The environment.
If you think pry is a cool tool for Ruby, you gotta see any smalltalk platform.
If you think pry is a cool tool for Ruby, you gotta see any smalltalk platform.
I remember a rubyconf talk from a ST veteran saying if they'd only look at its VM nobody would ever say 'Ruby is slow' again. So all things being equal, that's one advantage.
I do believe it was the Gemstone folks (http://maglev.github.io)
seems right :
- https://www.youtube.com/watch?v=Wh0BHJ7fUoc
- http://www.infoq.com/news/2008/05/MagLevAtRailsConf
Weird that it never got any steam or buzz ..
- https://www.youtube.com/watch?v=Wh0BHJ7fUoc
- http://www.infoq.com/news/2008/05/MagLevAtRailsConf
Weird that it never got any steam or buzz ..
> So, what's the advantage of Smalltalk over Ruby?
Smaller language, more coherent, first-class blocks, clearer messaging syntax, message cascading, conditions, …
> a better Smalltalk than Smalltalk
Not by a long shot no.
> and a better Python than Python
Not that one either.
Smaller language, more coherent, first-class blocks, clearer messaging syntax, message cascading, conditions, …
> a better Smalltalk than Smalltalk
Not by a long shot no.
> and a better Python than Python
Not that one either.
Lets see.
The concepts of live coding originated in Lisp and Smalltalk environments.
Smalltalk was the birth of IDEs and unit testing. Also its sucessors StrongTalk and SELF were the first environments to have JIT compilers.
Finally, having Smalltalk as OS made the computers quite interactive.
The concepts of live coding originated in Lisp and Smalltalk environments.
Smalltalk was the birth of IDEs and unit testing. Also its sucessors StrongTalk and SELF were the first environments to have JIT compilers.
Finally, having Smalltalk as OS made the computers quite interactive.
Anyone else love Smalltalk's message syntax. Objective-C uses it too. It has got to be the best syntax invented for a programming language. To see what I mean compare the normal procedural code vs. the OO version:
(a) drawRect(50, 50, 10, 21)
(b) aRect drawAtX: 50 andY: 50 width: 10 height: 21
(a) drawRect(50, 50, 10, 21)
(b) aRect drawAtX: 50 andY: 50 width: 10 height: 21
It sounds neat. I've wanted this kind of thing when I programmed in languages that didn't have it.
But having gone from c++ to Ruby to C++, I think the benefits of this expressiveness may not really be there.
This construction makes each line of the whole program that much longer, it asks that every functions arguments be meaningful outside the context of the function as well as within. Basically, this syntax may show you that certain calls are wrong but there are many other calls it won't prevent and it gives you larger amount of code to page through to find those other errors.
Remember, a good program wouldn't be using 10 as a function input except if there was some reason it's meaning was clear. And a rect would take two points rather than four ambiguous ints.
So what you can have is drawRect(Pt(screenLeft, screenTop), Pt(screenRight, screenBottom) if you want a rect covering the screen and you want expressiveness.
But having gone from c++ to Ruby to C++, I think the benefits of this expressiveness may not really be there.
This construction makes each line of the whole program that much longer, it asks that every functions arguments be meaningful outside the context of the function as well as within. Basically, this syntax may show you that certain calls are wrong but there are many other calls it won't prevent and it gives you larger amount of code to page through to find those other errors.
Remember, a good program wouldn't be using 10 as a function input except if there was some reason it's meaning was clear. And a rect would take two points rather than four ambiguous ints.
So what you can have is drawRect(Pt(screenLeft, screenTop), Pt(screenRight, screenBottom) if you want a rect covering the screen and you want expressiveness.
In Smalltalk you define points with '@' so you could do...
drawRectOrigin: 50@50 extent: 10@21.
drawRectOrigin: 50@50 corner: 60@71.
, otherPoint
^ Rectangle origin: self corner: otherPoint.
drawRect: (50@50),(60@71).
drawRect: (screenLeft@screenTop),(screenRight@screenBottom).C# isn't too terribly worse:
aRect.Draw(x:50, y:50, width:10, height:21);I look at those commas and wonder why? Is there a reason other than "must keep separators from normal function call"?
it kind of helps me visually dissect the parameters better - I'm sure if I got used to omitted commas it wouldn't be that big of a deal. When I would run into ruby code that omitted the parenthesis on a function call, it was considerably tougher to read for me.
Labeled parameters are optional. In fact they're so optional, that you don't even have to label all of the parameters at a call site (just the ones that appear after the first labeled parameter).
So with that (mis)feature, eliding commas would make a lot of code harder to reader.
So with that (mis)feature, eliding commas would make a lot of code harder to reader.
> So with that (mis)feature, eliding commas would make a lot of code harder to reader.
Not really. Lisps get by without them and it doesn't have formal keyword parameters.
Not really. Lisps get by without them and it doesn't have formal keyword parameters.
True, but that's an advantage of Lisp's uniformity. Imagine passing a query comprehension (or two) as arguments.
Foo(from n in range select n * n into: from n in range where n % 2 == 0 select n)Or, for that matter, Javascript, if you write it like this:
aRect.Draw({x:50, y:50, width:10, height:21})It's nice sometimes, but other times it gets in the way and makes lines so noisy that you end up needing to split that function call into eight lines just to be able to read it tomorrow.
Note that Obj-C's APIs tend to be much more verbose than Smalltalk's generally were. Compare Objective-C's
enumerateObjectsUsingBlock: aBlock
do: aBlock
objectForKey: aKey
at: aKeyThat's true. I suppose what I was thinking of is more an artifact of Objective-C's quirky typing than a problem with Smalltalk's message syntax.
There's that, Objective-C's options or errors returning doesn't help, NextStep/Apple seems to be very much in long message names, and some patterns/conventions of Objective-C also factor into it (e.g. `[NSArray arrayWithArray: anArray]`, smalltalk would just say `anArray copy`)
True, though [anArray copy] is idiomatic in Objective-C too. It used to be that people would prefer arrayWithArray: because copy returns an owning reference and you'd need a matching release, but now with ARC that isn't really a going concern. I'd feel weird writing [NSArray arrayWithArray:anArray] these days.
I think the majority of Objective-C's verbose conventions are artifacts of the Frankenstein type system — for example, having two methods with the same selector but different signatures will cause any use of either method with an id type to emit warnings, and possibly to generate incorrect code if the types are not compatible. So in order to avoid these awkward situations, Objective-C prefers to be as explicit as possible about what it's getting and giving. (Case in point: The extra verbosity in the examples you gave is almost entirely caused by adding nouns.)
I think the majority of Objective-C's verbose conventions are artifacts of the Frankenstein type system — for example, having two methods with the same selector but different signatures will cause any use of either method with an id type to emit warnings, and possibly to generate incorrect code if the types are not compatible. So in order to avoid these awkward situations, Objective-C prefers to be as explicit as possible about what it's getting and giving. (Case in point: The extra verbosity in the examples you gave is almost entirely caused by adding nouns.)
I still like it best, but also like the combo the current Objective-C allows. Mainly, it makes it easier to remember what the heck each parameter is supposed to be while reading the code. Its nice to have that information in the code instead of looking at the docs.
This looks nice on toy examples, but you aren't supposed to litter your code with numerical constants..
With variables, the readability difference is much lower, it helps avoiding mistake, but IMHO it would be better to use types to detect those mistakes..
I guess that's better in a COBOLly sort of way. I'd prefer a tool that let me investigate the signature and validate the arguments if I was interested; otherwise its awfully wordy and slow to write/read.
wordy maybe, but incredibly easy to understand upon coming back to the code. At least, more than a list of 5+ unnamed arguments in an arbitrary order made up by someone you'll never meet and you can only understand by looking at the api docs, if there are any.
I'd agree, except arguments are rarely just a list of numbers. With well-named constants, methods and variables its pretty clear what's being passed.
Yes, but in the case of a sometimes inconsistent API, you get things like string methods that are sometimes method(needle, haystack) and sometimes method(haystack, needle) and so on. If you were sending properly labeled messages, like you are forced to do in just about every web api ever, you can at least inspect the message to get an idea what is going on.
It's sort of weird to me that so much effort goes into making programming languages expressive, yet we cling to incredibly terse method names, sometimes too terse, and no labels on method inputs. So, if you don't know what some bit of code does, you have to figure out what the methods are doing and what arguments they are supposed to take.
I guess to me it's like if you had to do a dictionary lookup for every word you read and had minimal context to understand a words meaning in the context of the other words around it. At the very least you would cling to a dictionary if you wanted to get anything done.
It's sort of weird to me that so much effort goes into making programming languages expressive, yet we cling to incredibly terse method names, sometimes too terse, and no labels on method inputs. So, if you don't know what some bit of code does, you have to figure out what the methods are doing and what arguments they are supposed to take.
I guess to me it's like if you had to do a dictionary lookup for every word you read and had minimal context to understand a words meaning in the context of the other words around it. At the very least you would cling to a dictionary if you wanted to get anything done.
Undoubtedly slow(er) to write, but I think "slow to read", as in comprehend, needs some evidence.
Have you actually programmed in COBOL? I find it nothing like COBOL. Maybe AppleScript, but not COBOL.
I find it faster to read since I don't have to glance at API docs at the same time.
I find it faster to read since I don't have to glance at API docs at the same time.
The Smalltalk spirit is still alive, witness Pharo.
And the legacy lives on in so many languages, like Ruby, Objective-C.
With blocks, the semantics and programming paradigms of Objective C are now very close to Smalltalk. Seems like a Smalltalk targeting OS X and iOS would be a very good fit, similar to RubyMotion (which further demonstrates the underlying similarities between Ruby, Smalltalk and Objective C).
http://www.rubymotion.com/
http://www.rubymotion.com/
I don't think we're that close. If you're looking from Java, yeah, Objective-C looks pretty close to Smalltalk; if you're looking from Smalltalk, Objective-C is a little dot on the horizon. Objective-C is just at its core much more low-level than Smalltalk and considers that a feature rather than a bug.
If you're interested in the idea though, F-Script was actually pretty close to "Smalltalk for Cocoa," though it's more designed as a developer tool for Objective-C programs than an applications development language in its own right. It has an object browser and everything.
If you're interested in the idea though, F-Script was actually pretty close to "Smalltalk for Cocoa," though it's more designed as a developer tool for Objective-C programs than an applications development language in its own right. It has an object browser and everything.
And even spawns new heirs, such as Objective-Smalltalk: http://objective.st/
F-Script was actually how I discovered the beauty of Smalltalk :)
I remember some IBM guys not nostalgic at all about ST. They said it was a doesNotUnderstandHELL. Maybe they didn't receive adequate training. They were quite in love with Eclipse/EMF/RSA way of life too. Funny.
Beware! This Website will throw up 40 or 50 cookie permission dialogs in Firefox.
Yeah, I got a nice experience with VisualWorks while at University, around 1996.
However Smalltalk lost the enterprise place it got, but its spirit lives partially[1] on modern dynamic languages.
[1] Without live coding experience, it isn't a full Smalltalk descendent.
However Smalltalk lost the enterprise place it got, but its spirit lives partially[1] on modern dynamic languages.
[1] Without live coding experience, it isn't a full Smalltalk descendent.
I daydream about the fact that we're slowly climbing toward a lisp/st OS without acknowledging it. As you say nowadays people accept and enjoy having hackable userland (dom/javascript) and it's only a late bolted on addition.
Really live coding with Objective-Smalltalk[1]:
[1] http://objective.st/
http://www.youtube.com/watch?v=sypkOhE-ufs
[1] http://objective.st/
Here a simply equation. In terms of mental fortitude…