5 ms·

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 th

by gruseom 17y ago

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.

calibraxis 17y ago
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 http://lambda-the-ultimate.org/node/3640#comment-51563 This is his language which supports FEXPRs: http://web.cs.wpi.edu/~jshutt/kernel.html http://web.cs.wpi.edu/~jshutt/kernel.html
derefr 17y ago
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 17y ago
  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 17y ago
    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.
_delirium 17y ago
There's a bit of disagreement on the benefits of FEXPRs in the comments of this earlier HN discussion: http://news.ycombinator.com/item?id=1125109 http://news.ycombinator.com/item?id=1125109 In addition to the discussion on HN itself, the comments there also point to this excellent discussion: http://lambda-the-ultimate.org/node/3640 http://lambda-the-ultimate.org/node/3640

by gruseom 17y ago

calibraxis 17y ago

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 http://lambda-the-ultimate.org/node/3640#comment-51563 This is his language which supports FEXPRs: http://web.cs.wpi.edu/~jshutt/kernel.html http://web.cs.wpi.edu/~jshutt/kernel.html

derefr 17y ago

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 17y ago
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 17y ago
  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.

_delirium 17y ago

There's a bit of disagreement on the benefits of FEXPRs in the comments of this earlier HN discussion: http://news.ycombinator.com/item?id=1125109 http://news.ycombinator.com/item?id=1125109 In addition to the discussion on HN itself, the comments there also point to this excellent discussion: http://lambda-the-ultimate.org/node/3640 http://lambda-the-ultimate.org/node/3640