
The Early History of Smalltalk - b-man
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
======
gruseom
A classic piece which contains one of the best things ever written about
design:

 _Take the hardest and most profound thing you need to do, make it great, and
then build every easier thing out of it._

It's interesting to me that the idea that inspired Kay to this insight was
FEXPRs: letting functions control the evaluation of their arguments. FEXPRs
have long been banished from the Lisp world, which makes a sharp distinction
between functions and macros (only the latter get to control evaluation). I
still don't quite understand the reasons for this, and it seems like Kay
doesn't either -- or at least didn't when he was inventing Smalltalk.

~~~
derefr
There's no real difference between a FEXPR, and a macro that calls eval or
apply during expansion. The real meaning of "banishing" FEXPRs is that we
actually get something _extra_ : guaranteed-non-macro functions that behave
according to a predictable pattern (evaluate arguments, pass them in, return a
value.) Functions are basically a codified Lisp design-pattern, while macros
(or FEXPRs, as they may be) are the real core of Lisp's abstraction mechanism,
and really what make Lisp, Lisp.

It's just the same with Smalltalk: functions take lambdas as arguments, not
primitive or composite values. "Receives values" is simply a design pattern.

~~~
gruseom
That's a pretty good explanation; if it's accurate, I wonder why no one else
explains it that way.

In Smalltalk, I thought arguments are always evaluated unless they're blocks.
Is that wrong? Or is it that, at a lower level, everything's a block, and
functions are implemented on top of that as something that always evaluates
args?

~~~
derefr
No, you're right—arguments _are_ always evaluated unless they're blocks in the
full Smalltalk design we have today. However, like I said, this is a
_codified_ design pattern—the language could get away without doing it while
still retaining the "core Smalltalk conceit" of everything being a message
sent to an object. This is basically what the io language does—it's basically
a Smalltalk at its core, but with less cruft.

------
makmanalp
This is really odd, I'm having a bug on chrome windows where the html gets
printed out as plaintext. MIME type issues on the server side maybe? Other
than that, looks like an interesting read.

~~~
tlrobinson
Yeah...

    
    
       Content-Type: text/plain; charset=ISO-8859-1
    

Interesting that Safari is "smart" and ignores the content type in this case.

~~~
philwelch
My Safari printed the raw HTML source at first, but rendered the HTML upon
reload.

~~~
watmough
Yeah, mine too. I'm almost motivated to go look why... but not quite.

I looked for a 'View as' menu item prior to reloading, but very interesting
that a reload fixed it.

------
kanwisher
Really good read, abeit a bit long. It has a lot more details about the Xerox
Parc days then the movies like "Triumph of the nerds had". It was interesting
to hear a deeper understanding of the actor model in Smalltalk and simula

