Live data from Hacker News

Design Principles Behind Smalltalk (1981)

cs.virginia.edu

11–20 of 57 posts

Re: Design Principles Behind Smalltalk (1981)

#11

Earlier quoted context omitted.

On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, etc. Even C#'s LINQ, in its most powerful form, is ultimately a message passing system (and version 4 of the language that introduced `dynamic` went even further). Consider that the first MVC paper conce…

There were some insider events called Camp Smalltalk clustered around the year 2000, where people were saying to each other that we lost the battles, lost the war, but we won our cause. So many of the ideas that went into Smalltalk became mainstream. Java and then C#/DotNet was the validation of that. People continued to say this at other conferences. Consider that IDEs are becoming every more tightly integrated with…

> You should take a look at Smalltalk "IDEs" some time.

I've been delightedly toying with Squeak, Pharo, and Dolphin (as well as GNU Smalltalk, which is an anti-example, of course) for some time.

I cope with my day job by pretending that SQL Server is a Smalltalk.

Re: Design Principles Behind Smalltalk (1981)

#13
I believe there is a mistake in the user interface section. They use the word "esthetics" when they mean aesthetics which is > a set of principles underlying and guiding the work of a particular artist or artistic movement.

The root of the word is possibly Germananic (in German: Ästhetisch) or Greek Aisthetikos. It's not clear that there is a difference from any citable source, however deductive reasoning suggests that escetics is concerned with cosmetology and estheticians. The argument to be made that its the Latin dipthong AE is simplified to E is not valid in this case as inspection of Greek shows.

Edit: update. One given definition of esthetics is > relating to, involving, or concerned with pure emotion and sensation as opposed to pure intellectuality. [dictionary.com]

Re: Design Principles Behind Smalltalk (1981)

#14
post #3

Earlier quoted context omitted.

They were better than Smalltalk, not in terms of the language, but in terms of availability to developers. C++ and Java were free, Smalltalk during the time it could have risen, had no free implementations and cost a fortune to use. It's still a better language than either of those, but lost network effects gained by Java by being free.

They were better than Smalltalk, not in terms of the language, but in terms of availability to developers...Smalltalk during the time it could have risen, had no free implementations and cost a fortune to use. There were literally per-seat licenses at $5000 and $10000 at one point. There were free implementations around the time when Java was new, like GNU Smalltalk, but it would have been better if those hadn't exis…

Self was developed at Sun as a prototypal alternative to Smalltalk, which involved a lot of work on the compiler to make it performant. I'm pretty sure that effort fed into the JVM.

Re: Design Principles Behind Smalltalk (1981)

#15
post #13

I believe there is a mistake in the user interface section. They use the word "esthetics" when they mean aesthetics which is > a set of principles underlying and guiding the work of a particular artist or artistic movement. The root of the word is possibly Germananic (in German: Ästhetisch) or Greek Aisthetikos. It's not clear that there is a difference from any citable source, however deductive reasoning suggests th…

Just different spelling:

https://www.merriam-webster.com/dictionary/esthetic

http://dictionary.cambridge.org/us/dictionary/english/aesthe...

Re: Design Principles Behind Smalltalk (1981)

#16

Hmm. "Languages and systems that are of sound design will persist, to be supplanted only by better ones." I wonder if the author still thinks that, looking at the programming language landscape today. (Either he would have to say "it didn't work out that way", or to say that C++ and Java were better than Smalltalk.)

On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, etc. Even C#'s LINQ, in its most powerful form, is ultimately a message passing system (and version 4 of the language that introduced `dynamic` went even further). Consider that the first MVC paper conce…

> On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker,

"Recapitulated"... interesting choice of words.

Yes, this approach keeps being rediscovered, becomes a fad for a bit and then gets forgotten again. And for good reason: it leads to spaghetti designs with a chaos of actors sending and receiving messages to each other as an undebuggable mess.

Plus, it encourages the removal of types in programs.

It's really a poor idea in practice.

Re: Design Principles Behind Smalltalk (1981)

#17

Hmm. "Languages and systems that are of sound design will persist, to be supplanted only by better ones." I wonder if the author still thinks that, looking at the programming language landscape today. (Either he would have to say "it didn't work out that way", or to say that C++ and Java were better than Smalltalk.)

I think quite a few of the ideas behind Smalltalk were too radical for its time. Looking at the intellectual legacy of Smalltalk there is no denying it has been profoundly influential. It's not so much about C++ / Java vs Smalltalk but rather OOP vs Procedural Programming. There's a question about whether Java is OOP done right, but I think it's fair to say that it's done well enough to reap the majority of the benef…

Can you be more specific? If anything, a lot of the ideas in Smalltalk ended up being abandoned:

- Image based distributions

- Dynamic typing

- Extreme object orientedness (boolean ifTrue: foo ifFalse: bar)

- Meta object protocol

Re: Design Principles Behind Smalltalk (1981)

#18

Hmm. "Languages and systems that are of sound design will persist, to be supplanted only by better ones." I wonder if the author still thinks that, looking at the programming language landscape today. (Either he would have to say "it didn't work out that way", or to say that C++ and Java were better than Smalltalk.)

On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, etc. Even C#'s LINQ, in its most powerful form, is ultimately a message passing system (and version 4 of the language that introduced `dynamic` went even further). Consider that the first MVC paper conce…

What a bunch of baloney.

Smalltalk didn't invent message passing. Even if it did, Ruby is an obvious descendant of Smalltalk. Messaging in Smalltalk and messaging in Erlang are almost completely different. There's nothing remotely asynchronous about messaging in Smalltalk. Docker and LINQ? You're insane.

MVC has to do with this how? MVC has enjoyed continuous popularity since its invention. And of course partly this is because MVC keeps getting post-facto redefined, much like messaging. The Controller in original Smalltalk MVC translated keycodes into messages to the model. This is pretty different from the role of the controller in Rails, where it acts as the be-all dispatcher. Also, look at the most direct descendants of Smalltalk's MVC concept: Morphic, which is an unmitigated disaster with no controller at all, and Cocoa, which eventually replaced almost all the controllers with three stock ones. Everybody doing anything like a GUI is using MVC, but almost nobody is doing it like Smalltalk originally did, including Smalltalk today.

JVM and V8 owing their performance to Smalltalk hackers just means that dynamic languages get optimized similarly to each other, and the people who did it the first time had the experience to do it again. There's almost nothing of Smalltalk in Javascript. Some of the same people being involved? So what, James Gosling and Guy Steele were huge influences in Java, do you see any goddamn Common Lisp in there? Gosling thought the central idea of Lisp was that it was garbage collected!

Atom isn't integrated with Javascript, it's an editor built on Javascript. If you think this is like Smalltalk, where the editor and the code are alive together in the same process image, you've totally missed it. And by the way, as wonderful as this is, it also means you can trash your image and lose code. This is an interesting idea but having lost work to it I am not at all convinced it is a good idea. VBA? Browser Dev Tools? I feel like I'm reading a recruiter-authored job post here, not a Hacker News comment.

Your interpretation of what has happened with Smalltalk is seriously confused. I think you've mixed up cause and effect, similarity with equivalence and allowed a cult of personality to override technical truths. This is the birth of a cult, not an honest appraisal of progress.

Smalltalk is a really interesting idea. Some of the insights from it have enjoyed wider success. But most of your heroes have moved on from it, and rightfully. If you want to keep the candle burning you should be honest with yourself about why that happened, rather than trying to rewrite history to fit your narrative.

Re: Design Principles Behind Smalltalk (1981)

#19

Earlier quoted context omitted.

On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, etc. Even C#'s LINQ, in its most powerful form, is ultimately a message passing system (and version 4 of the language that introduced `dynamic` went even further). Consider that the first MVC paper conce…

> On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, "Recapitulated"... interesting choice of words. Yes, this approach keeps being rediscovered, becomes a fad for a bit and then gets forgotten again. And for good reason: it leads to spaghetti designs wi…

[deleted]

Re: Design Principles Behind Smalltalk (1981)

#20

Earlier quoted context omitted.

On the other hand, the big idea behind Smalltalk, message passing (i.e. programming with computers rather just the programming of computers), keeps getting recapitulated in various forms such as Ruby, Erlang, Docker, etc. Even C#'s LINQ, in its most powerful form, is ultimately a message passing system (and version 4 of the language that introduced `dynamic` went even further). Consider that the first MVC paper conce…

What a bunch of baloney. Smalltalk didn't invent message passing. Even if it did, Ruby is an obvious descendant of Smalltalk. Messaging in Smalltalk and messaging in Erlang are almost completely different. There's nothing remotely asynchronous about messaging in Smalltalk. Docker and LINQ? You're insane. MVC has to do with this how? MVC has enjoyed continuous popularity since its invention. And of course partly this…

Why so angry?

Even if it did, Ruby is an obvious descendant of Smalltalk.

So you agree with him. Ruby's most powerful feature is the combination of OO and blocks. That's Smalltalk through and through.

MVC has to do with this how? MVC has enjoyed continuous popularity since its invention. And of course partly this is because MVC keeps getting post-facto redefined, much like messaging. The Controller in original Smalltalk MVC translated keycodes into messages to the model. This is pretty different from the role of the controller in Rails, where it acts as the be-all dispatcher. Also, look at the most direct descendants of Smalltalk's MVC concept: Morphic, which is an unmitigated disaster with no controller at all, and Cocoa, which eventually replaced almost all the controllers with three stock ones. Everybody doing anything like a GUI is using MVC, but almost nobody is doing it like Smalltalk originally did, including Smalltalk today.

So, again, you agree with him? MVC has been refined, but it still has a basis in Smalltalk.

JVM and V8 owing their performance to Smalltalk hackers just means that dynamic languages get optimized similarly to each other, and the people who did it the first time had the experience to do it again. There's almost nothing of Smalltalk in Javascript.

Of course he's referring to Strongtalk, which was the basis for the JVM. Javascript is clearly inspired by Self which is a descendant of Smalltalk.

You've got some good points but they'd be easier to take if you weren't being so rude about them.

This is the birth of a cult, not an honest appraisal of progress.

How is it the birth of a cult when as you've said people are moving on?

Post reply on HN