> Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones. I loved coding in Smalltalk years ago. Guess “better” turned out to be rather subjective...
The issue with applying an evolutionary metaphor to programming languages is that Natural Selection will thins a population by culling based on some environmental event, which means that what one might rationally consider to be "fittest" is not what will be selected. So, the language may be well-strucuted, concise, extensible, etc. but natural selection may depend, for example, on availability for mobile platforms. I…
Design Principles Behind Smalltalk (1981)
11–20 of 33 posts
Re: Design Principles Behind Smalltalk (1981)
#12> Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones. I loved coding in Smalltalk years ago. Guess “better” turned out to be rather subjective...
-ss
Re: Design Principles Behind Smalltalk (1981)
#13Earlier quoted context omitted.
No, it's just that this principle isn't true. There are a lot of factors that influence which languages and systems persist. Being of sound design is a factor, but not the biggest one. Take Javascript, for example. It's the top language on Github. Its not there because its everyone's favorite language, or because it's an ideal language for writing reliable software. Its there because its baked into web browsers. We'r…
One turning point that saddens me as an ex-Smalltalker - at one point there were negotiations underway to have Smalltalk installed by default on all new Sun Workstations (this was back when Sun was a very significant player), but it fell through for financial reasons. Had this been the case, I'm sure Smalltalk would be significantly better known and more commonly used. And as justinpombrio says above, that has nothin…
One could only dream of how nice the programming world would be, if Sun had pushed Smalltalk instead of Java. Ironically, Hotspot started its life as a Smalltalk VM and only when Sun took over the development was turned into a Java VM.
Re: Design Principles Behind Smalltalk (1981)
#14Re: Design Principles Behind Smalltalk (1981)
#15> Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones. I loved coding in Smalltalk years ago. Guess “better” turned out to be rather subjective...
I wonder - what do people who used to code in Smalltalk think of "modern" languages. Like Golang, Rust, etc. -ss
Re: Design Principles Behind Smalltalk (1981)
#16Earlier quoted context omitted.
I wonder - what do people who used to code in Smalltalk think of "modern" languages. Like Golang, Rust, etc. -ss
We stick to our Java and .NET development environments, the only ones close enough to the experience.
-ss
Re: Design Principles Behind Smalltalk (1981)
#17Earlier quoted context omitted.
Or if PHP were built into browsers, we'd all be using PHP.
And the world would be slightly dumber, and even more willing to accept shoddy design. Shudder (Yes, modern PHP is okay , but there are still a thousand and one bits of legacy baggage from a darker time that yet remain to be fixed - things like sane process control (PHP can't reliably access subprocess return values!), standard I/O support (can't read from stdin one char at a time, so sane CLI tools are broken), DB s…
Re: Design Principles Behind Smalltalk (1981)
#18I don't see myself spending more time working with Smalltalk, as it stands today. It's single threaded, which is fine for a lot of tasks but is (in my opinion) a poor fit for a GUI environment. Having looked around at projects like Pharo, it looks like the Smalltalk community may be moving away from the idea of Smalltalk presenting the whole environment for the end-user, instead providing one application (often one that presents no UI, i.e. a web application).
From a personal standpoint, I would be very interested in a Smalltalk-like environment that I could use to develop my own software and, hopefully, use to replace a lot of the smaller bits and pieces I use to get my work done. Perhaps it could provide an IDE that I could also use to replace Emacs (which I also use for mail) and an IRC/chat client I could use to replace Weechat (which I also use for Slack, Google Talk and Facebook Messenger).
I don't feel a great affinity for many of the tools I use daily (email, chat, calendar, etc.), in part because they are not easy for me to alter or improve. It's funny: Emacs is clunky and weird, but I stick with it because it's easy for me to add or change the way it works.
I wonder if a Smalltalk implementation that revolved around objects implemented as actors passing messages (as opposed to the direct calling of methods that we have today) would be more amenable to multi-threading, yet still retain the simplicity that Smalltalk enjoys today.
Re: Design Principles Behind Smalltalk (1981)
#19Earlier quoted context omitted.
We stick to our Java and .NET development environments, the only ones close enough to the experience.
Oh, that's interesting indeed! Thanks. I speak zero Smalltalk (I must read a "Smalltalk book" after all), but somehow I expected to see C++ on the list, simply because Stroustrup said in his TC++PL book that Smalltalk has influenced C++ a lot. Do you think that Java and .Net are closer to Smalltalk than C++? -ss
Java and .NET are based on VM with mixed execution models, interpreted, AOT and JIT to native code.
Their semantic model is closer to Smalltalk, with GC, dynamic loading, incremental compilation, ability to change code in debug mode and continue, reflection, dynamically generate bytecode on the fly, ....
Re: Design Principles Behind Smalltalk (1981)
#20Earlier quoted context omitted.
Oh, that's interesting indeed! Thanks. I speak zero Smalltalk (I must read a "Smalltalk book" after all), but somehow I expected to see C++ on the list, simply because Stroustrup said in his TC++PL book that Smalltalk has influenced C++ a lot. Do you think that Java and .Net are closer to Smalltalk than C++? -ss
The only C++ environments that kind of came close to it were Lucid C++ and C++ Builder. Java and .NET are based on VM with mixed execution models, interpreted, AOT and JIT to native code. Their semantic model is closer to Smalltalk, with GC, dynamic loading, incremental compilation, ability to change code in debug mode and continue, reflection, dynamically generate bytecode on the fly, ....
BTW I just found out that, apparently, C++ Builder is, sort of, still alive. The most recent release is "10.2 Tokyo / March 22, 2017". I thought it was dead for a decade or so.
-ss