Design Principles Behind Smalltalk (1981)
cs.virginia.edu
Design Principles Behind Smalltalk (1981)
1–10 of 57 posts
Re: Design Principles Behind Smalltalk (1981)
#2Hmm. "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.)
Re: Design Principles Behind Smalltalk (1981)
#3Hmm. "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.)
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.
Re: Design Principles Behind Smalltalk (1981)
#4Hmm. "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 benefits of OOP.
Re: Design Principles Behind Smalltalk (1981)
#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 era of work.
Re: Design Principles Behind Smalltalk (1981)
#6Hmm. "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 concerned Smalltalk and was published sometime in the late seventies, but only discovered by the broader programmer community about 15 years ago. Certainly Microsoft developers only seemed to have become aware of it in the last ten years.
Consider that both the JVM (Hotspot) and Google's V8 owe their performance to Smalltalk hackers.
Consider that IDEs are becoming every more tightly integrated with their their client programming languages (Roslyn+Visual Studio, Atom/VSCode+JavaScript, VBA, Browser Dev Tools). Smalltalk was the canonical existence proof that this was a good idea (although Sketchpad did it first).
...
Dan Ingalls (along with Alan Kay and Adele Goldberg) deserve to feel pretty smug (although Kay was supposedly disappointed that they stopped evolving Smalltalk because it became too useful).
Re: Design Principles Behind Smalltalk (1981)
#7"...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 get a robotic arm to do so.
Re: Design Principles Behind Smalltalk (1981)
#8"...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…
I don't think he means the models of the human mind at the implementation level.
Rather he's referring to the mental conception of a specific problem or task, or even a natural language description of the problem, and how that is translated to a computer program that models that problem.
Re: Design Principles Behind Smalltalk (1981)
#9Hmm. "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…
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 their their client programming languages
You should take a look at Smalltalk "IDEs" some time. There's hardly anything there! The meta level is so easy to access, along with the compiler. The debugger is mostly just an ordinary Smalltalk application. In VisualWorks, a good coder can start writing a debugger and be browsing stack frames from real exceptions, literally within minutes. A warty but fully workable Class Browser could be finished by one coder in a week. There is no "tight integration" with the language. It just seems that way because almost everything is just an ordinary first class Object.
Re: Design Principles Behind Smalltalk (1981)
#10Hmm. "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.)
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 existed, because they didn't convey the benefits at all.
LightTable had YouTube to enable people seeing the benefit of the environment. Smalltalk could have really used that at the right time. That still wouldn't have helped, because the Smalltalk community didn't understand the network-effect benefits to the same degree almost any programmer understands them today.
Smalltalk could have been Java. Sun actually approached the owners of the VM to ask if they could use it for their early set top box project. They were rebuffed and went on to write what was to become the JVM. (Smalltalk becoming Java might well have resulted in huge early Internet security disasters blamed on it, because of the difficulty in securing the system, and the preference developers had for code signing as the primary security mechanism.)