Live data from Hacker News

Design Principles Behind Smalltalk (1981)

cs.virginia.edu

21–30 of 57 posts

Re: Design Principles Behind Smalltalk (1981)

#21

Earlier quoted context omitted.

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

How has dynamic typing been abandoned? What is Javascript? what is Python? What is Ruby?

The meta object protocol is alive and well in Python, Ruby, and to a lesser extent lua with metatables.

I don't see the point in exaggeration.

Re: Design Principles Behind Smalltalk (1981)

#22
post #5

"...a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware" We do know what the models in our computing hardware look like, but do we actually know the models in the human mind? Don't get me wrong, I love everything about this document. But I can't help but feel like that conceit is really dangerous. And seems common in this er…

In what way is it dangerous? It's a good description of what programming languages do, even if we don't know exactly how our minds work.

Re: Design Principles Behind Smalltalk (1981)

#23

Earlier quoted context omitted.

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 Smallt…

I'm angry because the cult-building around Smalltalk is stupid and I fell for it and wasted years trying to see what was there.

- It's stupid because you can use Pharo today; Smalltalk isn't dead. Try it and find out if it's great. They're trying as hard as they can to keep it relevant and it's a constant struggle because they have to build from scratch everything Smalltalk didn't invent.

- It's stupid because tiny languages like Smalltalk beget huge libraries; I have owned ~20 books on Smalltalk and all but two of them were essentially useless tours of defunct libraries. (The other two are fantastic and useful no matter what language you're using, if it's OOP.)

- It's stupid because most of what was powerful about Smalltalk is either nowhere in sight or became mainstream years ago. I'm angry at the cult-building because it builds nostalgia instead of systems. It makes it easy to spurn what we have and make excuses for our own non-productivity—obviously I'd be so much more productive if only it were 1985 and I had Smalltalk! If Smalltalk GUI building is so great, how come nobody uses it today? Because it's maddeningly inferior to everything we have today. Take your "Javascript fatigue" and try out Morphic, tonight. Here's a bottle of Rogaine and vue-cli for when you lose your hair and sanity trying that little experiment.

The cult-building is maddening because it misses the truly amazing things. To appreciate the amazing things requires immersion, and immersion sucks! You know, if you make a web app with Seaside and it throws an exception, you can serialize the debug window, bring it down to your image and continue the debugging session locally. The serialization works on blocks, which is to say closures, so you get the whole state of the app locally. Has the OP tried this lately? Because it only works if you use the newest serialization method, if you have exactly the same code in both images, and once you make the change in your local image, how do you get it up to the server again? Oh, you either have to endure the awful homegrown Monticello VCS (inseparable from its insufferable GUI, because Smalltalk) or you have to do the file-out file-in trick with git, because Smalltalk hates external tools.

It's a cult because MVC, in the overarching sense that it would have to mean to be applicable to all the aforementioned systems, would have arisen organically without Smalltalk because it's just a sensible design. It's a cult because messaging in the broadest sense that must be meant by including completely different things like Erlang and LINQ predates Smalltalk. If you ascribe things to Smalltalk (or influential people who happened to use Smalltalk) that did not originate in Smalltalk, you are taking Smalltalk as more important than history or fact, and that is the essence of building a cult. Methods-as-messages originate in Smalltalk, sure. If you say Smalltalk invented that, that's true. But of the five things mentioned, only Ruby has that. Java, Javascript, LINQ and Erlang do not. They are not Smalltalk's inheritors; they don't owe their concepts to Smalltalk, even if the same people worked on it.

Smalltalk was great, is great. Pharo is great. What makes it a cult is the alpha-and-omega bullshit. Great ideas happened before and after Smalltalk. They chose general names for specific ideas. History is mutilated if we ascribe to Smalltalk the general ideas or give Smalltalk credit for unrelated things because some of the same folks were in the room.

Re: Design Principles Behind Smalltalk (1981)

#24

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…

> Ruby, Erlang, Docker

Erlang is about messaging between processes, a smalltalk object is not a process and I really don't understand why Docker is in that list.

Re: Design Principles Behind Smalltalk (1981)

#25

Earlier quoted context omitted.

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.

fyi http://www.strongtalk.org/

Re: Design Principles Behind Smalltalk (1981)

#26

Earlier quoted context omitted.

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

How has dynamic typing been abandoned? What is Javascript? what is Python? What is Ruby? The meta object protocol is alive and well in Python, Ruby, and to a lesser extent lua with metatables. I don't see the point in exaggeration.

> How has dynamic typing been abandoned? What is Javascript? what is Python? What is Ruby?

Languages that are in the process of tacking on static typing features in a bid to stay relevant.

Most serious Javascript programmers are now moving to Typescript, Python has PEP-484, etc.

Re: Design Principles Behind Smalltalk (1981)

#27
post #7
post #5

"...a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware" We do know what the models in our computing hardware look like, but do we actually know the models in the human mind? Don't get me wrong, I love everything about this document. But I can't help but feel like that conceit is really dangerous. And seems common in this er…

People are associate not procedural so objects do map somewhat better than functions. Many of the hardest problems in computer science are very short term. Navigating a car across the country is not that hard, not hitting anything or breaking any laws in the next 10 seconds and every 10 seconds along the way is vastly more difficult. It's easy to calculate a trajectory to toss a ball into a hoop, it's much harder to…

At a molecular level, we could argue that everything is procedural in humans as well. Of course things get complicated at biological neural networks where parallel processing becomes more important.

In the end, both humans and machines have to follow the laws of nature (physics) in order to process information. There is nothing magic about it, at a certain point of abstraction we both (all) work in the same information processing way.

Re: Design Principles Behind Smalltalk (1981)

#28
post #7
post #5

"...a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware" We do know what the models in our computing hardware look like, but do we actually know the models in the human mind? Don't get me wrong, I love everything about this document. But I can't help but feel like that conceit is really dangerous. And seems common in this er…

People are associate not procedural so objects do map somewhat better than functions. Many of the hardest problems in computer science are very short term. Navigating a car across the country is not that hard, not hitting anything or breaking any laws in the next 10 seconds and every 10 seconds along the way is vastly more difficult. It's easy to calculate a trajectory to toss a ball into a hoop, it's much harder to…

When trying to come up with hard problems in computer science I would think np hard, not robotics.

Building a robot to toss the ball is still hard but that is an engineering and physics problem. The calculations remain simple.

Re: Design Principles Behind Smalltalk (1981)

#29

Earlier quoted context omitted.

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 Smallt…

I'm angry because the cult-building around Smalltalk is stupid and I fell for it and wasted years trying to see what was there. - It's stupid because you can use Pharo today; Smalltalk isn't dead. Try it and find out if it's great. They're trying as hard as they can to keep it relevant and it's a constant struggle because they have to build from scratch everything Smalltalk didn't invent. - It's stupid because tiny l…

I have always considered the standard library to be part of the language.

How big is Python the language? How big is Erlang/Elixir?

The power you get from each is that there are very powerful batteries included, and most 3rd party libraries fall into the same patterns learned from the STL.

Re: Design Principles Behind Smalltalk (1981)

#30

Earlier quoted context omitted.

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

Lisp had image-based distributions and dynamic typing before Smalltalk. Those and extreme oop-ness (Generic Functions, ...) plus MOP are still in Lisp (-> CLOS).

https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...

Post reply on HN