In the Balloon, or Out of it

"But there's a wee problem: Smalltalk came first."

The function call syntax used by mainstream languages appeared in Fortran, the very first high level language. Smalltalk took a detour (for very good reasons) and nobody else followed (for equally good reasons), but Smalltalk most definitely did not come first.

Audax:

If you look at things in a modern context James's comment makes more sense. Language systems like Java and .Net, and the Ruby language (I venture to add C++, but I'm moving towards putting it in the Simula camp), borrow a lot from Smalltalk. So in that sense, Smalltalk came first. If you want to talk about C, then okay, you can talk about Fortran getting there first. :)

Fortran had a major influence on the industry, not just in its own form, but also with BASIC. From what I've read, BASIC was Fortran with syntax and semantics that were easier to understand. BASIC was very popular up until recently. It'll be with us for decades to come, I'm sure. As I understand it, C, C++, and Java are the dominant languages now, all of which trace their lineage to Algol in one way or another. If you put C next to some Algol code you'll see the resemblance right away. Simula, another research language, was an OO form of Algol, from what I understand. My guess is if you put C++ and Java code next to it, there would be a resemblance as well, though Java borrows a few things from Smalltalk.

Re: Ian Bickings posts on this

I'm glad you brought this back up, James, because as I read Ian's posts, I felt like responding, but...it was from 3 years ago. For me, the web has helped out A LOT in understanding Smalltalk as a system (though a good book helps as well), particularly Google Video, seeing Alan Kay's presentations. I wrote a couple posts at:

http://tekkie.wordpress.com/2007/07/19/squeak-is-like-an-operating-system/ and http://tekkie.wordpress.com/2007/07/11/redefining-computing-part-2/

that I think begin to explain the fundamental underpinnings of the whole Smalltalk philosophy. One of the most profound things I learned recently is that Kay wrote Smalltalk to implement his conception of OOP, which was based on his work in biology (his Bachelor's degree). Objects = cells. The primary reason he did this is he observed the way nature scales. It goes from single-cell organisms to complex organisms made up of millions of cells. It also creates systems that can grow without having to be taken down for maintenance. It all works pretty well. It creates systems that can live for decades. That's what he was after at the technical level: software that scales and doesn't have to be stopped and restarted in order to do so. He also wanted a system that wouldn't crash, that was fault-tolerant when defects were detected. Not to say that Smalltalk is uncrashable, but it's much more fault-tolerant than C, C++, and Java. This emulates nature as well. Occasionally defects are created through mistakes in cell reproduction. The organism doesn't "crash" when this happens. The body deals with these defects by destroying them. In Smalltalk you deal with them by correcting the "DNA" of the object: the defective code--without shutting down the system.

So in short I think Ian misses the point of the system. He complains about the language syntax, the way the system works, and how it doesn't interoperate in a way he thinks would otherwise be obvious. Smalltalk is an attempt at a solution to a much deeper problem than Ian discusses.

IMO, Smalltalk marketing needs to take the form of education, seminars. So many programmers are trained in one way of thinking, but it leads them down the garden path to systems that are inflexible, and don't scale easily, not without a lot of complexity thrown into them, which just makes their job harder.

The main objection I've seen newbies throw at Smalltalk is its all-in-one, living-in-an-image scheme. They don't understand why it was designed this way. It runs so contrary to what they've been doing all this time. They have their attachments to their tools. The fact that Smalltalk seems to disallow their use makes them feel constrained. I guess they feel like it demands that they accept it all at once, rather than gradually, which I think is a point Ian made implicitly. The case really needs to be made for why it lives in an image, and why "the way of Smalltalk" is better, compared to their tools. Once that barrier is crossed, I think acceptance will be easier.

Interestingly it seems to me that IT shops have attempted to get around the inflexibility, robustness, and scalability problems of their existing technologies through computer engineering/I.S., rather than software engineering. I think that's the reason we've seen the n-tier distributed architecture arise with web applications. It's a way to try to get the benefits of Smalltalk, but through manipulation of whole systems, rather than code. They can create a form of late-binding this way (emulate it, anyway), but still use early-bound languages to create the software for each box.

Mark Miller wrote "If you look at things in a modern context James's comment makes more sense. Language systems ... borrow a lot from Smalltalk."

The first Ian Bicking paragraph quoted by James was about syntax and concluded "it's one of many things where Smalltalk reinvents everything from the ground up".

James' response to that paragraph was Smalltalk came first.

Do you mean to say that Java and .Net and Ruby borrow from Smalltalk syntax?

Well, to clarify where I was (and still am) coming from in that post, I worked with Smalltalk fairly early on in my life as a programmer.  The syntax didn't bother me -- really I quite liked it.  The image initially was really exciting (I quickly got on an Orthogonal Persistence Everywhere kick after I started using Smalltalk).  I learned a lot from the experience, and would recommend it to other young programmers; it's a great way to learn OO programming.  When it became frustrating, and when I moved on to other languages, is when I wanted to do something useful.  Like make a website.  Or write a little tool I could use.  And probably the biggest thing that drew me away from Smalltalk is that I wanted to be part of the Free/Open Source community.  And that community is mostly oriented around C, with a variety of satellites (not being particularly fond of C, I chose one of those satellites: Python).  

So the intention of my article was to answer "why I think I wasn't able to achieve the things I wanted in Smalltalk".  A lot of those things are about community and collaboration.  Some of those have little to do with Smalltalk the language -- the relative dominance of proprietary companies in the community was just as much of a problem as the environment.  I think that isn't just a coincidence.  In part it is a historical accident -- Smalltalk grew up before and separately from the internet.  Part of it is based on the environment, where decoupling code requires significant discipline, and integrating with foreign code (like a C library) is not done as often or casually, and the environment is novel enough that it benefits the professional at the expense of the hobbyist.  And of course collaboration.  Do you guys have free hosted version control systems for open source Smalltalk projects?  I hope so; if not you need to fix that.  SourceForge mattered a lot.

Many of these things are better now, but then Smalltalk is competing with environments that are themselves advancing, and I'm not sure if it's caught up on the whole. 

Also people who just want to Get Shit Done are probably not best served by the environment.  And most people, at some point, really need to Get Shit Done.  This is what constantly draws people towards the worse that is better -- the short term solution when a short term solution really is the right thing.  We need tools that work for all these situations.  The world of files and scripts and programs and pipes gives us the diverse environment that lets us do what we need to do, to make compromises when appropriate.  Smalltalk still isn't part of that world.

Comment by James Robertson

Cincom hosts the public store repository for Cincom Smaltalk development - it's freely available.

Isaac:

I was a bit unclear in my response to Audax's comment. Java's syntax looks more like C++, and I think Simula, but the ideas in the JVM, such as garbage collected memory, and object reflection owe a lot to Smalltalk. Ruby's syntax is the first up-and-coming language I've seen that bears a striking resemblance to Smalltalk syntax. Perl and Python also had an influence. It's missing a couple Smalltalk conventions, like named (keyword) parameters, and message cascading, but as I show below, there's a strong resemblance.

I was going to say in my last comment that Ruby is what I'd call a "Duckbill Platypus" language, which is what some developers like about it. It has a bunch of elements thrown together from Python, Perl, and Smalltalk. Ruby syntax has some elements that are familiar to most programmers, like for-loops (which don't exist in Smalltalk, though they can be emulated through other structures easily). It also has traditional if-then-else syntax for branching (which also doesn't exist in Smalltalk). Smalltalk is more purist: you create a boolean True or False object via. a conditional expression and then pass ifTrue: and ifFalse: messages to it to do if-then-else actions. The way Smalltalk operates is more familiar to Lisp programmers, though Ruby also has some Lisp-like structures, like "unless" (a shorthand version of if not X then...).

Where the similarities between the two begin is in other structures. I took some examples from "Programming Ruby: The Pragmatic Programmer's Guide" at http://www.rubycentral.com/pickaxe/

Hashes in Ruby: {'dog' => 'canine', 'cat' => 'feline'}

equivalent in Squeak (not sure if this works in ANSI Smalltalk): {'dog'->'canine'. 'cat'->'feline'}

summation of collection in Ruby: [1, 2, 3, 4, 5] sum

equivalent in Smalltalk: #(1 2 3 4 5) sum

One form of iteration in Ruby: 3.times {print "X "}

equivalent in Smalltalk: 3 timesRepeat: [Transcript show: 'X']

Another in Ruby: 50.step(80, 5) { |i| print i, " " }

equivalent in Smalltalk: 50 to: 80 by: 5 do: [:i | Transcript show: i, ' ']

Ranges in Ruby:

digits = 0..9
digits.include?(5)
digits.min
digits.max
digits.reject {|i| i < 5}
digits.each do |digit| dial(digit)

equivalent in Smalltalk:

digits := 0 to: 9.
digits includes: 5.
digits min.
digits max.
digits reject: [:i | i < 5].
digits do: [:digit | self dial: digit]. (assuming dial: is a method in an enclosing object)

This was actually kind of educational for me. The examples were a kind of "stream of thought" as I was reviewing "Programming Ruby". Fun. :)

Re: Ian's comments

I think what Ian reveals in his comment here is that he disliked Smalltalk because he felt isolated from the wider OSS community, which is largely based around C. I can understand that. Years ago I was a C/Unix developer and I felt isolated there. So I moved to developing for Microsoft Windows with C++/MFC and then C#/.Net. I felt happy there for a while, but eventually MFC felt frustrating, too complicated. I moved to C#, felt happy there for a while, and probably would've stayed so until everything was moved to the web. I moved to ASP.Net, felt kind of thankful that it seemed easier to deal with than other web frameworks, but then I ran into its limitations. I see that with Smalltalk it's a smaller community, but I guess what I care more about is working with a system that can handle complexity well.

Ian says that one reason he moved away from Smalltalk was he wanted to create web apps. There were some web frameworks around on Squeak that have been around since at least 2000. Maybe they were primitive. I don't know. Seaside exists on Squeak now and other Smalltalk platforms. It handles session state like a dream.

Re: "Do you guys have free hosted version control systems for open source Smalltalk projects?  I hope so; if not you need to fix that.  SourceForge mattered a lot."

There's SqueakSource at www.squeaksource.com. It integrates well with Monticello, over http.

Re: "Also people who just want to Get Shit Done are probably not best served by the environment."

You're probably right, but then Alan Kay had a saying: "When we think programming is small, that’s why your programs are so big!" You either end up creating disposable code, which is useful for a relatively short period of time, throwing it away after a while, because it's just easier to rewrite it than try to scale it to more demanding requirements; or you end up grafting on more and more code until it turns into a hairball of a system that becomes more and more difficult to maintain. That's the result of the "Get Shit Done" approach. I mean, I understand that in today's irrational world of software development this is basically a requirement in some cases, but it doesn't mean it's going to make your life any easier in the long run. It just makes it easier for you to justify your position (nothing personal against you, really--I've dealt with this), and for the company/organization to justify its messed up process. IMO Smalltalk represents a model that's more sane, but it takes people implementing a sane process to use it.

Ian Bicking wrote "In part it is a historical accident -- Smalltalk grew up before and separately from the internet."
Yes.

Ian Bicking wrote "Part of it is based on the environment, where decoupling code requires significant discipline..."
Yes - lack of modularity.

Ian Bicking wrote "Also people who just want to Get Shit Done are probably not best served by the environment."
Plain silly. It depends what shit you need to get done.

Mark Miller wrote "the ideas in the JVM, such as garbage collected memory..."
iirc Lisp implementations provided GC long ago.

"and object reflection owe a lot to Smalltalk"
afaik that's reasonable but then I really don't know enough about Lisp history.

"Java's syntax looks more like C++, and I think Simula"
That's right Java and .Net really don't borrow from Smalltalk syntax.

"It's missing a couple Smalltalk conventions, like named (keyword) parameters, and message cascading"
Those aren't conventions they are part of the language definition.