Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

blog.metaobject.com

Post reply on HN
Print view View original

81–90 of 114 posts

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#81

Post by blihp »

mpweiher wrote: post #48
blihp wrote: post #41

Earlier quoted context omitted.

Well Lisp and Smalltalk were designed for two entirely different purposes and audiences[1] so of course they were trying to jettison everything they could and keep things absolutely as simple as possible in Smalltalk. That doesn't mean that what was jettisoned didn't have value[2] in the right circumstances or hands, just that it wasn't appropriate for the needs of their project. Trying to do some things in Smalltalk…

> Lisp and Smalltalk were designed for two entirely different purposes and audiences > Smalltalk as a programming language primarily targeting children. Not entirely sure that is right. See The Early History Of Smalltalk [1] 'One day, in a typical PARC hallway bullsession, Ted Kaehler, Dan Ingalls, and I were standing around talking about programming languages. The subject of power came up and the two of them wondere…

You are correct regarding the initial concept, but what were the objectives of the Learning Resource Group that Alan Kay was leading at the time? And what were the various iterations of Smalltalk (i.e. -72 through -80) working towards? Squeak? Etoys? Croquet? (etc.) Alan has been pretty explicit in every paper and presentation I've seen from him: his career has been very much focused on computing as it applied to childhood education and development.[1] Of course Smalltalk is also an incredibly powerful language and still one of the better ones for adults to use IMO. But when push came to shove, the language design decisions were at least biased toward, if not explicitly based on what would work for children.

[1] Which is both profound and enlightened because in the same breath he'll say he didn't really care about educating children... he just wanted to help make better adults.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#82

Post by mpweiher »

EdwardCoffin wrote: post #63
mpweiher wrote: post #20

Earlier quoted context omitted.

> misconception that Lisp macros are mostly used to 'delay' evaluation. It was in the examples. No generalization to all of LISP was made or intended, though it would be interesting to make a survey study of actual macro usage by developers. It is also clear that you actually need the delay-evaluation mechanism in order to get something like "if" out of the language and into the library. > what Smalltalk calls 'block…

> they did not start out as a "function" mechanism, they started out as just a delayed evaluation mechanism Do you have a citation for this? Not disputing it, I'd just like to see whether there's something in Smalltalk's history I have overlooked, or didn't notice on my first reading.

That was what the article was about. The scans link to the source material Smalltalk-80: Bits of History, Words of Advice, one to the book on Amazon, the other to a PDF scan.

Quite frankly, I was a bit surprised so much of the discussion has been about LISP features that are neither in dispute nor subject of the article.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#83

Post by mpweiher »

m00natic wrote: post #65
mpweiher wrote: post #35

Earlier quoted context omitted.

> don't need to be valid code Yes. One of the examples from the talk was a comment macro. Very cool (and the talk was about fun/cool stuff, not about practicalities). The question is whether you want that sort of power in day-to-day programming. My guess is no. That's also what the PARC/LRG folks found out with Smalltalk-72. It's also something I hear from some very seasoned LISP hackers. It's also the sense I am get…

"we should always use the least powerful mechanism that will accomplish our goal" I like this when implementing something for non proficient users. But when it comes to providing tools for (supposedly) advanced users, like programmers... There's late-"socialism" joke in Bulgaria: "thrift is mother of misery". A designer doesn't know ahead of time what problems "creative" users will face long term. Providing a set of…

>> ... use the least powerful mechanism ...

> ... providing tools ...

Use ≠ provide. :-)

See:

The Rule of Least Power, Tim Berners-Lee

https://www.w3.org/2001/tag/doc/leastPower.html

See also:

Rule of least expressiveness

When programming a component, the right computation model for the component is the least expressive model that results in a natural program.

From Concepts, Techniques, and Models of Computer Programming, Peter van Roy, https://www.info.ucl.ac.be/~pvr/book.html

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#84

Post by m00natic »

mpweiher wrote: post #83
m00natic wrote: post #65

Earlier quoted context omitted.

"we should always use the least powerful mechanism that will accomplish our goal" I like this when implementing something for non proficient users. But when it comes to providing tools for (supposedly) advanced users, like programmers... There's late-"socialism" joke in Bulgaria: "thrift is mother of misery". A designer doesn't know ahead of time what problems "creative" users will face long term. Providing a set of…

>> ... use the least powerful mechanism ... > ... providing tools ... Use ≠ provide. :-) See: The Rule of Least Power , Tim Berners-Lee https://www.w3.org/2001/tag/doc/leastPower.html See also: Rule of least expressiveness When programming a component, the right computation model for the component is the least expressive model that results in a natural program. From Concepts, Techniques, and Models of Computer Progra…

I was more after

> The question is whether you want that sort of power in day-to-day programming

It's good to use the least powerful mechanism, no doubt. But it seems you are trying to sneak the usual "macros are too powerful for everyday use" so better be left out of a language altogether? I think when the storm comes - you'd better be equipped. Having varied ways to tackle problems (and macros are sort of linguistic abstraction orthogonal to lambda calculus/Turing machine derived toolboxes) allows for less complex solutions.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#85

Post by mpweiher »

blihp wrote: post #81
mpweiher wrote: post #48

Earlier quoted context omitted.

> Lisp and Smalltalk were designed for two entirely different purposes and audiences > Smalltalk as a programming language primarily targeting children. Not entirely sure that is right. See The Early History Of Smalltalk [1] 'One day, in a typical PARC hallway bullsession, Ted Kaehler, Dan Ingalls, and I were standing around talking about programming languages. The subject of power came up and the two of them wondere…

You are correct regarding the initial concept, but what were the objectives of the Learning Resource Group that Alan Kay was leading at the time? And what were the various iterations of Smalltalk (i.e. -72 through -80) working towards? Squeak? Etoys? Croquet? (etc.) Alan has been pretty explicit in every paper and presentation I've seen from him: his career has been very much focused on computing as it applied to chi…

"Although Smalltalk-80 is not meant to be used by children, application programs can be written that will allow them to be creative and, at the same time, learn about programming."

Is the Smalltalk- System for Children?, Byte, 6(8), August 1981. 3. Adele Goldberg , Steven T. Abell , David Leibs

https://archive.org/details/byte-magazine-1981-08

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#86

Post by blihp »

mpweiher wrote: post #85
blihp wrote: post #81

Earlier quoted context omitted.

You are correct regarding the initial concept, but what were the objectives of the Learning Resource Group that Alan Kay was leading at the time? And what were the various iterations of Smalltalk (i.e. -72 through -80) working towards? Squeak? Etoys? Croquet? (etc.) Alan has been pretty explicit in every paper and presentation I've seen from him: his career has been very much focused on computing as it applied to chi…

"Although Smalltalk-80 is not meant to be used by children, application programs can be written that will allow them to be creative and, at the same time, learn about programming." Is the Smalltalk- System for Children? , Byte, 6(8), August 1981. 3. Adele Goldberg , Steven T. Abell , David Leibs https://archive.org/details/byte-magazine-1981-08

Keep in mind that was at a time when Adele was working to commercialize Smalltalk in the real world[1] eventually as a business venture selling to businesses (i.e. ParcPlace Systems) so there was more than a little bit of spin involved. (especially given the writing, photo and video evidence to the contrary from the 70's with Adele in-frame :-) Also, look back at the Early History link from your first post and you'll find 'children' mentioned 35 times including this quote: 'and a language I now called "Smalltalk"—as in "programming should be a matter of ..." and "children should program in ..."'

[1] If I'm not mistaken the only reason Squeak and its derivatives even exist today was that during this time, as Xerox was trying to figure out what to do with what PARC produced, Apple received one of the handful of the Smalltalk-80 Version 1 licenses. IIRC, the Version 2 license was more restrictive and wouldn't have let Apple do what it did in terms of open sourcing Smalltalk. Notice that there was never a Smalltalk-82 etc... virtually all future work came from the commercial side until Squeak came along.

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#87

Post by mpweiher »

blihp wrote: post #86
mpweiher wrote: post #85

Earlier quoted context omitted.

"Although Smalltalk-80 is not meant to be used by children, application programs can be written that will allow them to be creative and, at the same time, learn about programming." Is the Smalltalk- System for Children? , Byte, 6(8), August 1981. 3. Adele Goldberg , Steven T. Abell , David Leibs https://archive.org/details/byte-magazine-1981-08

Keep in mind that was at a time when Adele was working to commercialize Smalltalk in the real world[1] eventually as a business venture selling to businesses (i.e. ParcPlace Systems) so there was more than a little bit of spin involved. (especially given the writing, photo and video evidence to the contrary from the 70's with Adele in-frame :-) Also, look back at the Early History link from your first post and you'll…

>> "Although Smalltalk-80 is not meant to be used by children..."

> spin

So when the people involved directly und unambiguously contradict your opinion, for which you have presented zero evidence, they are lying.

When I looked at Smalltalk in 1975, I was looking at something great, but I did not see an enduser language, I did not see a solution to the original goal of a "reading" and "writing" computer medium for children.

That's Alan in Early History.

> 'children' mentioned 35 times

That's an odd metric at best, but let's play. First mention of "children" after the introduction:

A month later, I finally visited Seymour Papert, Wally Feurzig, Cynthia Solomon and some of the other original researchers who had built LOGO and were using it with children in the Lexington schools. Here were children doing real programming with a specially designed language and environment.

Hmm..LOGO. What's LOGO?

Logo is a multi-paradigm adaptation and dialect of Lisp, [..] The goal was to create a mathematical land where children could play with words and sentences

Oh, and LISP is mentioned 29 times. Having read this document many times, as well as the History papers and listened to talks etc., I have yet to find any evidence that anything was done to "dumb down" Smalltalk in order to make it work for children. Quite the contrary:

One of the basic insights I had gotten from Seymour was that you didn't have to do a lot to make a computer an "object for thought" for children, but what you did had to be done well and be able to apply deeply.

This incident and others like it made paramount that any tool for children should have great thinking patterns and deep beauty "built-in."

Shortly after that:

As I mentioned previously, it was annoying that the surface beauty of LISP was marred by some of its key parts having to be introduced as "special forms" rather than as its supposed universal building block of functions. The actual beauty of LISP came more from the promise of its metastructures than its actual model.

By this time [Smalltalk-80] I was both happy about the cleanliness and elegance of the Smalltalk conception as realized by Dan and the others, and sad that it was farther away than ever from the children

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#88

Post by mpweiher »

m00natic wrote: post #84
mpweiher wrote: post #83

Earlier quoted context omitted.

>> ... use the least powerful mechanism ... > ... providing tools ... Use ≠ provide. :-) See: The Rule of Least Power , Tim Berners-Lee https://www.w3.org/2001/tag/doc/leastPower.html See also: Rule of least expressiveness When programming a component, the right computation model for the component is the least expressive model that results in a natural program. From Concepts, Techniques, and Models of Computer Progra…

I was more after > The question is whether you want that sort of power in day-to-day programming It's good to use the least powerful mechanism, no doubt. But it seems you are trying to sneak the usual "macros are too powerful for everyday use" so better be left out of a language altogether? I think when the storm comes - you'd better be equipped. Having varied ways to tackle problems (and macros are sort of linguisti…

> sneak the usual "macros are too powerful for everyday use"

Not trying to "sneak" anything, I openly say that language design, which is what macro usage is, is not something you should have to engage in everyday. In fact, I would turn it around: if you have to (repeatedly) resort to language design in your everyday programming, your programming language is (woefully) inadequate. Most are.

Which is why the reasons for hitting that boundary interest me: where do I have to resort to metaprogramming, why, and what can I do about it? What non-metaprongramming facilities are missing here so that I don't have to resort to metaprogramming? And if I don't want to just add those facilities to the base, which I don't, what mechanisms can I add to the language so that users of the language can use plain, non-meta mechanisms to provide those facilities themselves?

This is a bit tricky, but I am making good progress using a software architectural approach[1], with frequent surprises as to how much simpler things can be.

> left out of a language altogether?

Quite the contrary. I think "escape hatches" (metaprogramming) are fundamental and your everyday language(s) should be built 100% on top of those mechanisms. Heck, I named my company "metaobject"[2] 20 years ago, after The Art of Metaobject Protocol.

[1] http://objective.st/

[2] http://www.metaobject.com/

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#89

Post by EdwardCoffin »

mpweiher wrote: post #82
EdwardCoffin wrote: post #63

Earlier quoted context omitted.

> they did not start out as a "function" mechanism, they started out as just a delayed evaluation mechanism Do you have a citation for this? Not disputing it, I'd just like to see whether there's something in Smalltalk's history I have overlooked, or didn't notice on my first reading.

That was what the article was about. The scans link to the source material Smalltalk-80: Bits of History, Words of Advice , one to the book on Amazon, the other to a PDF scan. Quite frankly, I was a bit surprised so much of the discussion has been about LISP features that are neither in dispute nor subject of the article.

> they did not start out as a "function" mechanism, they started out as just a delayed evaluation mechanism

I still don't see where you are getting this from. The scans you provide [1] don't make this claim. For instance, look at page 17 of Technical Characteristics of Smalltalk-76 [2]:

> heights _ students transform each to each height

The document seems to have some OCR problems - I'm pretty sure that underscore is meant to be a left arrow, or := in more modern Smalltalks. I understand this to be the equivalent of Smalltalk-80's

> heights := students collect: [:each | each height].

which is clearly a mechanism for mapping a function over a collection, not just a delayed evaluation mechanism.

[1] You might add to your article a footnote specifying that the citations from Bits of History, Words of Advice are from pages 14-15

[2] http://xeroxalto.computerhistory.org/Filene/Smalltalk-76/.sy...

Re: Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

#90

Post by EdwardCoffin »

mpweiher wrote: post #82
EdwardCoffin wrote: post #63

Earlier quoted context omitted.

> they did not start out as a "function" mechanism, they started out as just a delayed evaluation mechanism Do you have a citation for this? Not disputing it, I'd just like to see whether there's something in Smalltalk's history I have overlooked, or didn't notice on my first reading.

That was what the article was about. The scans link to the source material Smalltalk-80: Bits of History, Words of Advice , one to the book on Amazon, the other to a PDF scan. Quite frankly, I was a bit surprised so much of the discussion has been about LISP features that are neither in dispute nor subject of the article.

> Quite frankly, I was a bit surprised so much of the discussion has been about LISP features that are neither in dispute nor subject of the article.

It's because Lisp macros and their motivations were described inaccurately, and some people want to make sure that these inaccuracies are not perpetuated.

Post reply on HN