I got a couple reactions to my last post. As I said, it was half baked, which is to say that I didn't know my conclusion when I started writing the post, and I didn't rewrite everything that came ealier once I realized my conclusion. So they labelled me uninformed, rather than merely disorganized.
I did a fair amount of Smalltalk programming at one time when I was in school. I drank the Kool Aid, I understood the philosophy, I read the literature. I only used Squeak, and I am aware that other systems offer more tools. Those other systems are all proprietary, and sadly the Smalltalk community (for the most part) is not a Free Software kind of community. I'm sure cool Open Source things happen (and Squeak is certainly cool), but all the most advanced (most "modern") features seem to be proprietary. Maybe it's not fair to dismiss them because of that. But I am not fair and I dismiss them because of that. And I offer no apologies for this.
Now, working back from my conclusions:
Smalltalk offers no path from here to there. Smalltalk has a lot of nice things about it. A lot of them involve different ways of thinking about programming and thinking about the nature of programs themselves. There's also the syntax -- it's not a bad syntax, but it's not the dominant syntax, and it clashes badly with the dominant syntax. It's hard to phrase one in terms of the other (i.e., they do not map to each other). The syntax is only a small part of it, but it's one of many things where Smalltalk reinvents everything from the ground up. Much of it is successful, much of it is particularly elegant when viewed as a whole. But you take it or you don't, it's very hard to go part way. That's a huge flaw.
Smalltalk devalues the idea of a "program". The Smalltalk image is a lively set of interacting objects, like agents in a community. It often seems almost spontaneous the way they interact, and it's like they are all peers with no center. Ravioli code is often the result.
But it's more than just ravioli code. Smalltalk encourage a style where there's often no program at all. Everything is developed in a persistent environment where there's little distinction between code and infrastructure. You open a workspace, set up some objects and tie them together, then trigger a key method that sets it in motion. But as a result the program is hard to distinguish from your one-time workspace. Zope has a lot of the same problems, and interestingly this article advises that you follow a methodology that "Devalues the data that goes into any given ZODB storage," due the challenge of cooperating in such an environment. I know there exist better tools for Smalltalk collaboration than for Zope. But they are generally proprietary, so I dismiss them :P (I don't live in a Smalltalk world either, so please don't ask me to choose to abandon my existing tools)
Still, the damage that ravioli code causes should not underestimated! A quick definition from the wiki page:
In the structured programming world, when things got messy your code became SpaghettiCode. Everyone knows what SpaghettiCode is. It has been said that with objects you get RavioliCode: thousands of little classes everywhere and no one knows how to find the places where things really happen.
Again, ravioli code doesn't offer a path from here to there. "Here" in this case is the ignorant programmer first introduced to the code, "there" is the same programmer successfully making whatever change they need to make. In my experience with ravioli code there is a gestalt which is arrived at in a sudden realization, when the picture comes together. But before you reach that realization you find yourself in a murky set of code where it is difficult to predict effects or determine causality, and you seldom know how far away you are from the gestalt realization.
This is some of what I was referring to when I said that Smalltalk programming styles led to too many frameworks and not enough libraries -- a framework requires you to take on a certain metaphor of execution, to adapt your thought process to the framework instead of adapting the program to your thoughts. Frameworks can be worth it, but they always exact a significant cost.
The lack of decent syntactic support for simple imperative programming (i.e., functions) also doesn't help Smalltalk be any simpler or more accessible.
I've become distracted from my main point here: Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects. Maybe we'll get to that world of objects, but there needs to be a path leading there that starts here.
So maybe my new conclusion is that Smalltalk is uncompromising in its vision, but the world is not ready for that vision. I say "the world is not ready" from an empirical basis, not as a judgement. Nor do I judge the world or rail against its ignorance for not embracing a good thing. The world is what it is, we are where we are. We can push the world in the direction we choose, but we can only move it, not wish it elsewhere.
(Maybe that's not fair -- we as individuals can leap about as we wish, for our minds are light; perhaps this is the nature of invention; thus my conclusion is self-doubting)
This article is translated to Serbo-Croatian language by Jovana Milutinovich.
Sorry, but I think the comments on your last posting still stand: you never really lived in Smalltalk. Programming in Smalltalk isn't enough: you need to really dive into the interactive system. Maybe it's the fact that I love Lisp Machines and their highly integrated world view that I am rather fond of Smalltalk systems. The first problem you have is what people often have: there is no program. Yep, that's right in a weird way: you usually don't build standalone programs (although there are options on how to do this - Cincom has it, or use Smalltalk/X if you want a classic standalone batch compiler), but work in the interactive environment. For me the Smalltalk environment became my desktop. Everything I wrote lived there, everything I wrote was instantly reachable from there and so it was very easy to integrate those parts. This isn't a problem or a bug, it's a feature!
What you do to deliver your application is to strip the image from what isn't needed any more (standard stuff with Lisp environments, too, so not really an obscure feature) and bind it with the virtual machine to form the application. This usually is a builtin tool. The reason you do it this way is that Smalltalk - same as good lisp environments - allows you to make much more use of what is already there in the image. You decide how much of the standard environment you need. Need a scripting language? Use smalltalk, deliver parts of the development environment with your application. Need a hierarchical browser for in-image structures? Use the available ones as a starting point. Need a simple attribute panel? Use the inspector. Sure, there are solutions that give you much of this flexibility in more classic environments - Ruby, Perl and Python for example. The power of already installed tools is what makes me use Python ;-)
But Smalltalk really dominates if you want a feature rich environment. Due to the demise of Lisp Machines, Smalltalk is actually the only option if you want such rich and well integrated environments. None of Eclipse or XCode or any other integrated development environment comes even close to what Smalltalk offers.
The comparison with Zope is actually quite good. Only problem is, Zope is far too much centered around the content management and web application meme. Ok, newer versions become much better in that area. Tools in Zope are still a bit crude. Especially in-Zope development (ZClasses are the only way to develop your own products inside Zope) isn't as sophisticated - you don't have hierarchie browsers or even simple class browsers in Zope, you only have the rather flat view of products in the control panel. But yes, one could see Zope as the Pythonic Smalltalk for Web development. It just needs to grow up in some areas.
Oh, regarding free resources: Cincom makes their smalltalk free (as in beer) available and since that is a rater grownup Smalltalk, it includes everything and the kitchen sink. And since it is built in the good stand of Smalltalk environments, it includes the source for everything including the kitchen sink.
Squeak is the other option with free (as in speech). To say that Squeak is a small environment or a limited environment or just to say "only programmed in Squeak" shows that you didn't really dive into Squeak, as you missed about 95% of the nice features and tools in Squea. For example the whole virtual machine abstraction is available in Squeak in Smalltalk.
So if you really want to build yourself a usefull Smalltalk background, you can jump into Sqeak again, you will get most standard Smalltalk tools and then some more (Morph is quite cool - wish other GUI libs would be as modern and usefull). Or jump into Cincom to see what big Smalltalk systems are alike, what additional tools they provide (many tools for Cincom are free in both senses - there is a quite vivid Smalltalk Free Software world!).
So why didn't Smalltalk really take off? Complicated question. First anser is: it _did_ take off. It was in high regard for many years before Java really took off. It's just that it became a smaller area in the world of programming due to the high visibility (and actually Hype) of Java. It's the same with Delphi vs. Visual Basic in Windows: Delphi is much cleaner and much more powerfull, still people jump the Visual Basic train. I think that market movements (and programming language choices in the world often don't have to do with technical choices, but much more with marketing than we would like to!) just pushed Smalltalk to it's side, as much as they did with Lisp systems. There still are several Smalltalks out there and there still are several Lisps out there. They fit their job very good. Free implementations are available in both languages, and there are free implementations with quite complete toolsets (although Smalltalk wins over Lisp here - there are only rudimentary development environments for free Lisp). But I won't say they didn't take off - they were just damped by bad marketing of the companies and by the Java stuff.
There _is_ the fact that people often don't "get" the idea behind the Smalltalk environment. But that's mostly because people try to see Smalltalk from the typical batch compiler point of view and think they miss stuff in Smalltalk. Actually it's the other way around: if you ever really _worked_ with Smalltalk, lived in the environment, you will miss many tools in the outside world.
So I think the really interesting question would be to ask why other languages didn't take up those ideas and why they don't deliver as sophisticated tools. Why is idle so crude? Even DrPython is primitive in comparison with a Smalltalk environment.
Damn. Now I have to boot my lisp machine to feel better again ;-)
>I only used Squeak
Then maybe you should talk about "Where Squeak Went Wrong"?
>not a Free Software kind of community
You used Squeak - Squeak has a vibrant Free Software kind of community!
>proprietary... I dismiss them
Are you generalizing far beyond your experience?
>clashes badly with the dominant syntax
What do you mean specifically by "the dominant syntax"?
>a lively set of interacting objects
Yes this is OOP.
Kristen Nygaard, in his ECOOP 2002 Banquet Speech:
"In object-oriented programming the programs are not organised in a single sequence. Instead, an object is created for each individual component... In this way a system, including information systems, may be understood, described and represented by a collection of objects in a computer, each object acting and/or is acted upon through the carrying out of the parallel object-related computing sequences."
Maybe you mean: OOP devalues the idea of a "program"?
>support for simple imperative programming
Why would we use an OO programming language to do simple imperative programming?
# Isaac Gouy
Georg: I did live in the Smalltalk world. I find it annoying that everything thinks otherwise because I wasn't awed into silence by that environment. I'm not saying that using Smalltalk is a waste of time, or that it doesn't have some great features, many of which still haven't been replicated elsewhere. But when I had to make the choice between the Smalltalk environment and the rest of the world, eventually I chose the rest of the world. Georg, haven't you too? My point is that it is a flaw to force people to make that choice. Most of the time Smalltalk loses that battle -- if not right away, eventually.
Isaac: Then maybe you should talk about "Where Squeak Went Wrong"? -- maybe, but I think Squeak's goals are more modest and academic than Smalltalk's as a whole. Smalltalk had great ambitions (does it still have them? maybe not...). I don't think it has fulfilled those ambitions. I'm open to an argument that Smalltalk has achieved every success it deserves, but I suspect that would be a case of damning with faint praise. This all started in a response to "Why People Don't Get Smalltalk". So I'm giving my answer -- and unlike other people's, my answer isn't "because everyone is too misguided and uninformed".
You used Squeak - Squeak has a vibrant Free Software kind of community! It does. It seems to be the only such community. Maybe I'm wrong, I'm not intimately aware of the current state of the Smalltalk community. Squeak is a good hobbiest project, and it's a good academic/experimental project, but I haven't seen it work outside of that.
What do you mean specifically by "the dominant syntax"? I mean function(args...) or object.function(args...). Mapping, say, Objective C into another syntax looks funny, you get stuff like obj.setX_y_(x, y) or much worse (usually much worse). Mapping the other way turns into object methodWith: arg1 with: arg2 with: arg3. I think other languages have been successful when they've been able to adopt foreign interfaces and APIs -- it allows them to quickly leverage other work (either porting code or using external code directly), and leverage not just the code but the documentation and skills around that interface. Smalltalk's syntax hinders that.
Maybe you mean: OOP devalues the idea of a "program"? Yes! That's exactly what I mean. I don't think the world is ready for that.
Why would we use an OO programming language to do simple imperative programming? Because it's simple? A lot of problems are simple. Easy problems should be easy to solve. I think imperative, non-component programming is simpler. It's not always appropriate -- but when it is, it's really nice to have it available. This is what I think of when I distinguish between frameworks and libraries -- with libraries the control stays with the caller, and the programmer defines the basic flow of code. A framework, in contrast, takes over control from the programmer, and the programmer customizes the framework, they can't simply use the framework.# Ian Bicking
Ian: sorry, but no, I haven't chosen "the other world". Actually I am still working with many different systems. That I choose Python for most of my work isn't because I want to ditch Smalltalk or Lisp, it's because Python is one of the few languages that give me reasonable language features and runs on many different systems. I do have to work for a living and prefer to use stuff that will solve my problems. Since most projects at work include Zope, Python is the language of choice currently.
Language decisions change over time for me quite often. For example I already feel the itch to rewrite PyDS with Common Lisp, as there are several very cool libraries and tools available now. Older stuff I wrote was in Perl (several years my main language) and Java, even older ones in OCaml, Ada, Oberon-2, Modula-2, Assembler, Cobol (don't ask, took 10 of my best years), PL/I (don't ask), Lisp, Smalltalk (mostly Digitalk, but some ObjectWorks too) and whatever happened to cross my way (yes, I even used C++ to quite a large extent before deciding on disliking it). So the fact that I _now_ program Python doesn't say anything about Python or other languages, but says a lot about _me_.
And I still don't accept the "Smalltalk vs. the rest of the world" stuff. Sorry, but that's quite wrong. Smalltalk systems integrate nicely into operating systems and system libraries nowadays. There is no "other world" - every language and language environment have their pros and cons and it's weird to devide the language space of round about 1500 programming languages into two areas where Smalltalk is on one side and supposedly everything else on the other side. Actually even if you narrow your view on languages with batch compilers and standard linking/loading mechanisms, you will find many highly different concepts. Even if you go down to procedural languages in that area it's not a simple homogenous field. Take for example the library concepts of Modula-2, Ada and C++. Highly different, even though the languages share many similar concepts. Add Eiffel or Sather to that bunch and you will get even more differences. Or look at the Smalltalk side: you need at least take Smalltalk 80 descendants and Self as two languages from that camp. Maybe you need to add Objective-C - it borrows many concepts from Smalltalk, although it's mixed into C. How can you make statements about such a divergent field of languages?
The main problem with your statements is that for every point you list where Smalltalk supposedly failed, people will be able to show you implementations and implementation details that will set a counterpoint. Even the "Smalltalk is an integrated environment" isn't correct any more, as both GNU Smalltalk and Smalltalk/X both sport a much more standard file interface. So it's quite understandable that people tell you that you didn't live in Smalltalk or didn't understand it, as the arguments you list are just plain and simple wrong.
That's no big deal, as _any_ "this language failes because of these reasons I give" posting I ever read was plain wrong and didn't say so much about the language but much more about the programmer. Usually it boils down to the fact that people should put the title up as "why this language failed _for_ _me_" and everything is fine. C++ failed for me because I think it's plain ugly and I can't stand the syntax and semantics. Other people are happy with C++. That doesn't tell you much about C++. It tells you a lot about me (a snob) and others (the mob) ;-)
So maybe my new conclusion is that Smalltalk is uncompromising in its vision, but the world is not ready for that vision.
Agree with that. The fact is that Smalltalk, despite it exist since...30 years? did not get wide audience in real concrete applications, I mean the kind you pay money for. My feeling is that it is in advence on its time or century. What we can see is that widly spreaded languages and platforms (java, .net, Windows, etc...) are converging toward concepts that were built in Smalltalk since its beginning. Hence, I think that even if it is hard for us to forgot our way of thinking from data/process world, it is rewarding to embrace the "Smalltalk way of life". You get a new vision of what can do computers and how to use them.
Of course, at the end of the day, you will go back to Java/C# for your industrial applications, but with a new vision of how to architecture your system. Look at Kent Beck, and such guys: they came from Smalltalk to really deeply improve our way of working in Java/C#.
To come back to the reasons of Smalltalk failure, I agree with your social interpretation of programming, from another blog: Because computing is functional, because it is social, I think it must develop in an incremental and continuous fashion. Revolutionary ideas have to be parseled out in small packages, or be optional, and Smalltalk doesn't seem to offer that.
However I expect that classics languages are slowly but surely moving toward Smalltalk.# notarianni
Maybe you mean: OOP devalues the idea of a "program"? Ian: Yes! That's exactly what I mean. I don't think the world is ready for that
Seems like you should explain that at length - it's difficult to tell if you intend to say that the world isn't ready for Java & C# (and the numerous languages that have been made object friendly - C++ Python Ada) or if you intend to say that Java & C# and ... aren't used to write OO programs.
Ian: my answer isn't "because everyone is too misguided and uninformed"
Nor mine. John M Carroll & Mary Beth Rosson found out how to make Smalltalk training effective - much of that research is online.
function(args...) or object.function(args...)
You wouldn't map code into Smalltalk in that way - you'd try and take advantage of what the language provides.
I think imperative, non-component programming is simpler
So if you have a simple little problem that you will be able to solve faster with an imperative programming language - use the imperative programming language ;-) Choose the appropriate tool.# Isaac Gouy
The Smalltalk community is very much a "free software kind of community". Look at CampSmalltalk, look at all the code visible to you in the commercial Smalltalks, look at the culture of sharing code, look at the principle of delivering code in source, look at the availability of free (in eiter sense of the word) Smalltalks - lots of them.
And the point that "most advanced features" are in the commercial arena is also IMHO not true. And besides - what are we comparing to? The same can be said of most other languages/environments too.
The thing you call a "huge flaw" is instead part of what is best with Smalltalk. If you just want something that is just like everything else - then fine, stick to everything else instead. Saying something is "flawed" because it is different is just plain ignorant. And the syntax is in many ways superior - ask anyone who have grasped the concept of keyword syntax and realized that it conveys much more information to the reader. Other langs have tried emulating it with optionally named arguments.
The idiocy about ravioli code is almost too dumb to respond to. It's called OOP and Smalltalk invented it. Ravioli code is just a good description of BAD OO code, not OO code in general.
Then comes more silliness trying too fool us into thinking that Smalltalkers write their programs in a workspace. Of course not - workspaces are meant as a playground, an experimental scrapbook. And then comes the "there is no program" line again reinforcing that you haven't understood OO - programs or systems are made up of objects, and then you can package them as an executable using various techniques. What is the problem?
Furthermore take a look at ChangeSets (admittedly tricky sometimes, but a nice concept) or Monticello for a free very good system for managing source code. Sure, free such advanced systems haven't been around in abundance - but I can't say I see them in other environments either really - they just rely in file based CM solutions non aware of the semantics of the language.
Saying that "lack of support for simple imperative programming" almost takes the biscuit. It is IMMENSELY easier to whip up an "imperative" snippet of code in Smalltalk than in most other languages. Not that Python, Lisp and Ruby (just to mention a few) don't have a similar capability. But it is simply not true what you are saying.
And then in the end you are saying something vague about the world not yet ready for Smalltalk blabla. Did you know that Smalltalk had about 33% (don't remember the reference, but C++ was top dog then at about 60%) of the OOP market before Java with its hype came onto the scene? Are you aware of the large systems built using VisualWorks, VisualAge and GemStone?
Btw I know several companies using Squeak for products including our own - and you know what? It works perfectly.
I could have made this simple and instead just repeated what Vassili wrote. So tired of people throwing around theories without any solid facts or experiences to back it up. You don't see me blabbering on about say Haskell, OCaml or Ruby - simply because I don't know enough facts.
/Göran
I totally agree when you say: "Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects." That´s the real question here. Smalltalk isn´t a "programming language", its an object environmnent, where objects live and evolve, which HAS a programming language to specify method behavior. The programming language inside Smalltalk is irrelevant, and could easyli be changed (syntax) and Smalltalk would be the same.
In Smalltalk there are no programs, but object systems. And it´s GOOD, not bad. Here is when I disagree with you. But you are 100% right in commenting that the vast majority of today software developers are not ready for this, they WANT to see a program, and don´t understand that working with programs is working proceduraly, not object oriented. To truly work according to the object oriented paradigm you need an environment like Smalltalk. Today software development world isn´t ready for that.
"Furthermore take a look at ChangeSets (admittedly tricky sometimes, but a nice concept) or Monticello for a free very good system for managing source code. Sure, free such advanced systems haven't been around in abundance - but I can't say I see them in other environments either really - they just rely in file based CM solutions non aware of the semantics of the language"
Uh, don't you see the simple solution as a good thing? My source code repository has files in 5 different languages checked in to it (C++, Java, PilRC, XML, and Perl), along with gifs, jpegs, wavs, and a host of other filetypes. Surely you don't expect my repository to know about all these languages, along with any random other one I happen to come across or invent in my spare time. Or perhaps you're saying that I should have different repositories for each file type? No, wait, maybe I should convert all my jpegs into C++?
Having everything be flat text files has some major advantages, which I feel are being overlooked. More commentary here.
Actually if you have a structured storage for files, you sooner or later end up with an image that's just not stored in one file but in severals. Look at what the Zope people are doing with their storage alternatives - there is already one that stores objects as single files in the filesystem. And look at what beasts like ClearCase are doing: the file storage is actually stored in VOBs which are nothing less than images with repository features that can be exported as filesystem lookalikes. Or look at Mac OS X (or NextStep) applications: they aren't single file executables, but several files in specially tagged directories. If you look at what is in there and look at the Windows EXE format, you will notice that EXE files are just the same, only they are integrated into one filesystem object ..
So there isn't so much difference between images and filesystems with structure. There are even ways to map one onto the other. I don't think it would be too big a problem to write a DAV capable webserver in Smalltalk that doesn't export filesystem objects, but Smalltalk classes from the image in fileout format. Not that I am eager to write such a beast, I just think it would be doable - and simple. And with a DAV interfaces you could mount your Smalltalk image in most desktop environments without noticing the difference.