Okay, I'll leave this alone, but one last thing, from Making it stick:
I would agree that Smalltalk still (after thirty plus years) seems ahead of its time.
After thirty years, what does it meant to be ahead of your time? There was a little meme going around that I can't remember well enough to find again -- when you explain something and the other person doesn't understand, it's not their problem, it's yours.
That's not entirely fair -- Smalltalk has informed and influenced the computing world a great deal. But it's still worth thinking about. Or to paraphrase myself, as lame as self-quoting is: saying that Smalltalk has achieved every success it deserves would be to damn with faint praise.
Maybe more Smalltalk users should offer opinions on the flaws of the language, since they don't want to hear my opinion. If they think it is without flaws then they lack both imagination and ambition, because there is always more to be done.
VisualWorks certainly has flaws (fonts, for example). Syntax and the image are not the problem though. You might want to look at this post:
for where I think we are. The developers who decide to stay with "good enough" are going to share the fate of many 1970's and 1980's blue collar workers - "good enough" can be done elsewhere for less.
Those who move UP the value chain will stay....
Ian, here's the link or 'meme' you were thinking of I think: http://www.tbray.org/ongoing/When/200x/2004/01/13/LawOfConversation
more Smalltalk users should offer opinions on the flaws
They have, for many years, on comp.lang.smalltalk
(Note that self-assessment of performance with a tool is notoriously inaccurate - measurement works.)# Isaac Gouy
Smalltalkers discuss and improve Smalltalk in Smalltalk forums. Quite naturally so.
For example, the Squeak developers mailing-list is bursting with ideas, improvements etc.
And I would like to hear anyone's opinion - unless it is just ramblings and wild claims that are not even remotely based on facts.
Smalltalk is still ahead of it's time in the sense
that rather new dynamically typed languages such as Python, have defencies
that Smalltalk doesn't have.
See also my blog for more comments.
I read your original article, your followup, and all the comments and trackbacks on each. My take on it is that the Smalltalk users who commented didn't think Smalltalk was without flaws; they just thought you didn't know what you were talking about, and that the things you thought were flaws were either not present or virtues. In short, they did want to hear what you had to say, and they heard it, but what you had to say was almost entirely wrong.
In their opinions. I don't know enough about Smalltalk to comment.
(I know I shouldn't keep up with these threads, it's mostly distracting not helpful, but I can't help myself, and meta-discussion is stupid, yet I can't help myself)
In response to Kragen, others: My posts were based on the premise there was something wrong with Smalltalk. Because it was a premise, not the real content of my post, I think people who didn't agree with the premise found it difficult to respond (for no fault of their own), the best you can do in such a situation is say "Smalltalk is great!" which isn't a very satisfying response for either side. But then I wasn't really willing to turn this into a multi-part tretise where I outline my points from basic principles, so I must expect people to infer what my premises are and come up with their own conclusions.
Anyway, after we get past that issue, there's the strawman issue. My original post was imprecise in language (my fault), and was misinterpreted in a number of ways. People criticised these misinterpretations, e.g., that you could not easily use foreign functions in Smalltalk, when I intended to refer to the conceptual difficulty when Smalltalk and foreign interfaces are not isomorphic. They plucked a few of these misunderstandings out and then declared that I knew nothing about Smalltalk. Which I found very frustrating. Still do, I suppose, otherwise I wouldn't be commenting here.
Ultimately, I guess I was looking for a retort I didn't get -- a "no, Smalltalk's problem isn't what you said, the problem is X". I suppose it's rather too optimistic to think I'd get that kind of response. It requires a thoughtful response, and requires that the reader attempts to understand my perspective and frame the response in those terms -- and I recognize that it takes a great deal of effort to create that kind of response, and the people who responded didn't necessarily have any investment in my opinion, so they weren't inclined to invest in that kind of response. Well, there were some long responses (Georg wrote whole essays) -- I'm not sure what it means that I'm not satisfied with those either. Maybe I am just stubborn.
But frankly, I do go out of my way to respond in thoughtful ways taking into account the perspective of my audience, so I'm not asking for something I'm not myself willing to give. (Which is why I appreciate the difficulty of composing that kind of response)
You shouldn't start language arguments if you don't want to get essays from me ;-)
I think the main point why you didn't get a "Smalltalks flaws isn't X, it's Y". Smalltalk isn't that flawed in large scale. Sure, there are some smaller problems in the language itself (for example the missing operator precedence - but then, you get used to that, in the same way you get used to significant whitespace in Python or big loads of braces in Perl). It's quite a complete language whose implementations usually carray around quite a complete environment with most tools a programmer will need. They have some centuries of experience in building development environments, not like the make-compile-link-debug-segfault programmers with their centuries of not-development-environments ;-)
The reason why Smalltalk didn't take off in larger scale? Timing. Marketing. Mostly the same reasons as there are for the acceptance problems of Lisp. Ok, one special Lisp problem is missing: the "teached-to-death" symptom. Don't know how many people got driven away from Lisp or Scheme just because stupid courses at their university. :-(
Smalltalk had it's high time in the 90s. Then came Java and people jumped that language after failing with C++. Had there been better marketing for Smalltalk, I am sure that it would have taken over then. But the market wasn't reacting to the opportunities. There was a very interesting discussion in the Smalltalk panel at OOP in 98 or so - when the guy who wrote Smalltalk/X talked to the panel and explicitely accused them (the panel was boarded with people from the Smalltalk companies and from Universities) of making Smalltalk bad with their way to do stuff, especially with their closed-shop-mentality. Not enough public visibility. Cincom does the right thing: giving their environment away for free (as in beer) to allow programmers to play with it. Back then there were only very few freely available Smalltalk versions around: Smalltalk/X (a commandline compiler for Smalltalk to C), Squeak (in a much simpler version than today) and GNU Smalltalk (commandline interpreter). The rest (Tiny Smalltalk and lot's of other projects) were mostly toy implementations or specialized university projects. Yes, I know, Self was already there, but Self is it's own category, even if it shares a lot with Smalltalk.
So I think it's not the language fault that it didn't take off in larger scale. It's mostly a problem of people. As allways ...
"So I think it's not the language fault that it didn't take off in larger scale. It's mostly a problem of people. As allways ... "
Hah, I got you to say it! ;) That was exactly my point! Or, my counter-point, or the point which was central to my underlying accusation. It's not the problem of people. "When you’re explaining something to somebody and they don’t get it, that’s not their problem, it’s your problem." If Smalltalk has a message and an idea that people aren't getting, it's not the people's problem, it's Smalltalk's problem (in a practical as well as philosophical sense). That's the flaw, and the premise, that I have been trying to explore all along.
Sorry, but that's plain wrong. "If they don't get it, the explanation is wrong" is already a stupid sentence (it's misused as an excuse for lazy and sloppy people far too often), but at least right to some degree - wrong teaching can do a lot of wrong for language learning. Think of the silly way Latin usually is teached - without actually speaking it, giving the reason that it's a dead language and so no need to speak it - but that way people often don't "get it", because like me they _think_ in the language they are using and a language without talking blocks this way to use it. But "they don't get it, so the tool is at fault" is just plain silly - it's not Smalltalks fault as a language or environment that people don't teach it right.
Programming language knowledge doesn't fall out of trees. It's an art that you need to master - and there is a lot of work to be done before one can decide wether a language is the right or the wrong tool for the job. For me there were several languages I used quite a lot where I early on decided that they are not the right tools for me. Mostly had to do with aesthetics. So I don't object to people saying that some language wasn't done for them. But saying a language failed because people don't "get it" is silly. People failed. Either by teaching it or by learning it. Languages are tools, tools don't fail. Oh, and tools don't have a message. They are tools. They might not be the right tool for the job - but if you say "language X isn't the right tool for job Y" be prepared for several other programmers popping up and saying the opposite. Just because they are solving exactly your problem in exactly the language you said wasn't fit for the job. People told me that Python as an interpreted language isn't fit for distributed file system programming. I objected and wrote one. There are TCP/IP stacks out there written in pure Lisp. People write games using Lisp - and I am not talking about oldfashioned stuff here! There are distributed systems written in Smalltalk. Telecom switches programmed in Lisp or some in Erlang (mix of functional and declarative programming language - two paradigms where people are fast to tell you that they are not usefull for real world problems). I've seen device drivers written in Smalltalk - if the system is designed for Smalltalk, that's not uncommon.
I've heard this "language X is at fault" about far too many languages before. Smalltalk. Comon Lisp. Scheme. Haskell. Clean. ML in it's manyfold variations. Prolog. Weird enough, if you do dig a bit through google, you will find many success stories for those languages and for real world problems. Ok, Haskell is a bit handicapped there - it is the only language where even I failed in "getting it". I don't blame the language, though, but much more my deficits in knowledge about the needed abstractions.
So in my experience people only pull the "if they don't get it, it's wrong" card when they themselves didn't "get it". And try to explain that fact by the inapproprietness of the tool instead looking for the real reasons. The fact that you allways hammer your thumb instead of the nail isn't an indication that the tool named "hammer" failed. It's just an indication of your manual imperfectness :-)
If you just want to make something that's cool, maybe you can blame the person who doesn't get it. But if you want to change the world (even in a little way), then you have to blame yourself when the other person doesn't get it, since it's your ambition that then fails, not their. Smalltalk's dream has always been to change the world.
But Smalltalk doesn't have a dream. It's a language. So what dream did fail? Adele Goldbergs dream to build tools that help children to learn programming? That's a success, she is using them and kids are learning programming with Smalltalk based tools - Squeak carries some of those tools. Alan Kays dream to build the integration language of a graphical workstation? That was a success, the machine was built, it ran and worked. His dream of building a full blown tool for teaching programming and testing implementations in a extensive environment? Look at Squeak. A big success for the field it's built for - you can even try different VM implementations based on Smalltalk code. The dream of the Parkplace founders to get a development environment that spans several platforms and operating systems? Was a success, see the result in the current version of Cincom Smalltalk. Ok, it wasn't a success for the company itself, at least not in the long run - but then, most companies sooner or later drop out of business. The business model for Parkplace failed, but their tools are still working and are still used - is that failure for you?
Smalltalk _did_ change the world. It spawned whole languages like Objective-C that are nowadays used to implement an operating system that powers 5% of the personal computers in use. It influenced graphical environments more than most other system. It influenced development tools in many ways - hierarchical class browsers, the Python module path browser, many tools are modeled after what was already there in the original Smalltalk systems (and wasn't there before in this particular way - some Lisp machines did have similar tools, but they were still quite different from the much simpler view Smalltalk presented). So in what way did Smalltalk actually fail? There are not really that many languages and environments that changed so much in the world of software development as Smalltalk did. Generational garbage collection - first implemented in Lisp systems and Smalltalk systems. Virtual machine with defined bytecode - first done for Smalltalk. Hotspot optimization technology (dynamically compiling bytecode to machine code) - first done in Smalltalk systems. Full blown object oriented systems with extensive class libraries - first done with Smalltalk (Simula was the first implementation of OO, but the class library was rather small and more targeted at simulation software, Lisps Flavors and Loops were early OO systems, but no class libraries, as they were used to implement AI software). Sorry, but how can you talk about "Smalltalks dream to change the world" and say it was a failure?
Oh, and building things that should last _is_ about building cool things. Only cool things stay around, as people love to play with cool things. Build cool things and you _will_ change the world. Even those boring things that dominate some field usually started as cool - Java _was_ cool when it started it's life as just the JVM with the Java language. It became boring by SUN trying to dominate the software world and adding warts like J2EE instead of coolness.
Don't know how cool it was when Admiral Grace Hopper implemented the first Cobol compiler, though ...
Ok, ok, your right, I shouldn't underestimate the influence and importance of Smalltalk. And dominance shouldn't be confused with success. At least when you're considering actors that are not motivated purely by commerce -- Java would be a failure if it was super cool, but not a commercial success, because for a public company commercial success is the only success there is. But the people behind Smalltalk have never seemed primarily motivated by that.
Smalltalk hasn't and probably won't achieve dominance, but that's okay.
Main problems with Smalltalk: it's not popular. Popularity results not so much from the quality of the product or idea, but from history and marketing. Marketing Visual Basic [the MOST successful language in terms of $$$] was done by a company with a big guaranteed revenue stream run a by a shrewed money-making management team.
Smalltalk was invented at Xerox in the early 1980's, but Xerox had no idea what to do with it commercially -- Xerox didn't market it or use it very much -- and then a few years later Xerox was being clobbered by Japanese copier companies and didn't have the money to market the hell out of development platform.
Consider what could have happened if PARC had been a Microsoft research facility -- if Bill Gates had commercialized Smalltalk instead of Visual Basic.
As to the other big development at PARC - windowing / easy to use interfaces - Apple took that idea and commercialized it, and then Microsoft copied Apple. Note that when Steve Jobs founded NEXT, Inc. he copied not only the idea of windowing interfaces, but also the idea of an OO application framework, having learned to look beyond the surface. NextStep [and now Apple's Cocoa] uses Objective C -- And Objective C is C with Smalltalk-like OO extensions.
If I remember right, Xerox Parc also developed ethernet (but didn't make money at it) and the predecessor of PostScript (but didn't make money at that).