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.
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.
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?
Interesting, there's a researcher by the name of John Shutt who in said "I suspect them of offering fundamentally greater abstractive power than any other programming language feature yet devised" in 2009. http://lambda-the-ultimate.org/node/3640#comment-51563
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.
Another interesting thing is exploring being pedantically standards compliant (breaking usefulness sometimes) versus bending standards (in the expense of encouraging bad practice)
(I did it to be able to read the paper without all the distracting OCR errors/typos in the OP's version; perhaps they've been fixed since then, though they weren't at the time I sent him this.)
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
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.
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.
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?
1 reply →
There's a bit of disagreement on the benefits of FEXPRs in the comments of this earlier HN discussion: http://lambda-the-ultimate.org/node/3640
Interesting, there's a researcher by the name of John Shutt who in said "I suspect them of offering fundamentally greater abstractive power than any other programming language feature yet devised" in 2009. http://lambda-the-ultimate.org/node/3640#comment-51563
This is his language which supports FEXPRs: http://web.cs.wpi.edu/~jshutt/kernel.html
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.
Yeah...
Interesting that Safari is "smart" and ignores the content type in this case.
My Safari printed the raw HTML source at first, but rendered the HTML upon reload.
2 replies →
Another interesting thing is exploring being pedantically standards compliant (breaking usefulness sometimes) versus bending standards (in the expense of encouraging bad practice)
2 replies →
View -> Text Encoding -> Autodetect.
This seems to resolve the issue well enough.
In case it helps any, here's a mirror I put up long ago, without the MIME issue AFAIK:
http://accesscom.com/~darius/EarlyHistoryST.html
(I did it to be able to read the paper without all the distracting OCR errors/typos in the OP's version; perhaps they've been fixed since then, though they weren't at the time I sent him this.)
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