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…
Design Principles Behind Smalltalk (1981)
31–40 of 57 posts
Re: Design Principles Behind Smalltalk (1981)
#32Earlier 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…
Re: Design Principles Behind Smalltalk (1981)
#33Earlier 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'd argue that the CompSci community DOESN'T choose the best thing that comes along, but merely the first one that fits the bill. It's a mixture of darwinian processes and market force.
If you take the example of Smalltalk vs UNIX vs DOS in the 80s then you get exactly that. People chose DOS+IBM PC because it was a shitload cheaper than a Xerox Star. They'd also choose UNIX (for mainframes) over Smalltalk because it was already there, everyone knew how to use it, and nobody wants to ever break backwards compatibility (so you're stuck).
(EDIT: also, compare to the WWW. Is it really so much superior than what we had before?)
Sure, SOME things have improved, but overall it's a complete shit show and I don't think that the things that have improved are THAT much better (while everything else is downright garbage).
Re: Design Principles Behind Smalltalk (1981)
#34Earlier 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…
Ok, someone already said that, now to enjoy the rest of your posts (with which I'll probably agree).
Re: Design Principles Behind Smalltalk (1981)
#35Earlier quoted context omitted.
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…
What are the other two fantastic books of which you speak?
http://www.lulu.com/us/en/shop/andres-valloud/a-mentoring-co...
http://sdmeta.gforge.inria.fr/FreeBooks/WithStyle/SmalltalkW...
Re: Design Principles Behind Smalltalk (1981)
#36Earlier quoted context omitted.
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…
> If Smalltalk GUI building is so great, how come nobody uses it today? Because it's maddeningly inferior to everything we have today. I'd argue that the CompSci community DOESN'T choose the best thing that comes along, but merely the first one that fits the bill. It's a mixture of darwinian processes and market force. If you take the example of Smalltalk vs UNIX vs DOS in the 80s then you get exactly that. People ch…
Re: Design Principles Behind Smalltalk (1981)
#37Earlier quoted context omitted.
> If Smalltalk GUI building is so great, how come nobody uses it today? Because it's maddeningly inferior to everything we have today. I'd argue that the CompSci community DOESN'T choose the best thing that comes along, but merely the first one that fits the bill. It's a mixture of darwinian processes and market force. If you take the example of Smalltalk vs UNIX vs DOS in the 80s then you get exactly that. People ch…
Yes, but today they're both free. Why don't you download Pharo today and use Morphic? Then come back and tell me it's competitive with Cocoa, Qt, JavaFX. Morphic was a neat idea where it was born (in Self!) but there are reasons it hasn't taken off among hobbyists—it's bloated, it's slow, it is worse for most usecases. If it were better today , where's the community of people being hyper-productive and trumpeting it…
I'm especially not thrilled about the underpinnings of current systems. You have to put in a huge amount of effort (millions of lines of code) for very little effect (web browsers, modern operating systems, etc). Just because something is the best that doesn't mean it is actually good. /I/ think, we could do a whole lot better. Just recently, I had a similar debate. Money quote: "nothing beats a nice C implementation".
What I'm always curious about: does this /Idea/ really not work or did simply put not enough effort in it (compare what amount of money, time, and man power is spent on modern systems compared to Smalltalk or any less popular system; I'd say it isn't a fair comparison wrt the former leading to better results).
Re: Design Principles Behind Smalltalk (1981)
#38Earlier quoted context omitted.
Yes, but today they're both free. Why don't you download Pharo today and use Morphic? Then come back and tell me it's competitive with Cocoa, Qt, JavaFX. Morphic was a neat idea where it was born (in Self!) but there are reasons it hasn't taken off among hobbyists—it's bloated, it's slow, it is worse for most usecases. If it were better today , where's the community of people being hyper-productive and trumpeting it…
That's not what I was arguing. I was arguing that a better idea does not (necessarily) get adopted, even if it is superior. Sure, Smalltalk might not compete today, but I'd say it was superior /then/ (and still didn't see wide adoption!). That's why I don't have any hope that a superior idea will get adopted in the /future/, whatever it may look like (and this is my main issue here). I'm especially not thrilled about…
Fundamentally, I think if you're talking about Smalltalk, you're either talking about it in situ, or as it is today, or as an influencer. In the original context, it was thrilling, far ahead of its time in many ways, and lost out because of the reasons you mention: expensive machines, expensive licensing, performance.
If you're talking about it as it is today, it's a mixture of great and horrible and if someone is uniformly positive about it that tells me they have limited experience—either with Smalltalk itself or with competing modern systems.
As an influencer, there are things that can make a reasonable claim to inherit concepts from Smalltalk, especially Ruby. But the influence is not as wide as gets claimed by its proponents. Some of the ideas in Smalltalk are synergistic and don't work well taken piecemeal. Many of the claims about Smalltalk's influence above are unreasonable, either because they are a semantic ball-and-cup game or because they claim a kind of invisible human influence that bears no technical resemblance.
Smalltalk is worth using today, but it has actual faults that shouldn't be whitewashed, and I find the cult of Smalltalk distasteful because it prioritizes in-group mythbuilding over the truth. We should all download Pharo and use it for a few weeks. That direct, personal experimentation is the ultimate cure to technology triumphalism, whether we're talking about Smalltalk or anything else.
I certainly agree with you that we can do better than what we have today, and that Smalltalk has lessons for how to do that which would absolutely apply.
Re: Design Principles Behind Smalltalk (1981)
#39Earlier quoted context omitted.
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/
Meanwhile the part of the Self group still at Sun created Pep, which was a Java on top of Self that was way faster than any other Java. But it was a quick hack with a few serious limitations.
Animorphic, the StrongTalk company, did a more polished implementation of Java on top of their VM technology and got bought by Sun to turn that into the HotSpot VM working together with the part of the Self group that had stayed at Sun all along.
Around 2000 Sun allowed the Self project to be restarted until they killed it again in 2006, at which time they open sourced StrongTalk (which had been hidden since Animorphic had been bought).
Re: Design Principles Behind Smalltalk (1981)
#40I 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...