5 ms·

Design Principles Behind Smalltalk (1981)

81 points by molteanu 8y ago

mrexroad 8y ago
> 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...
- crimsonalucard 8y ago
  It's not about subjectivity. It's about exposure. A lot of people weren't exposed to a language long enough to know what is actually better. I bet if everyone were exposed equal parts to smalltalk, javascript, haskell, lisp and python you will see an entirely different paradigm.
- justinpombrio 8y ago
  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're now starting to get full-featured reliable compilers into JS with sourcemaps and whatnot, plus things like webassembly. So it's becoming quite reasonable these days to write code for the web in a language that isn't JS and not feel like a second-tier citizen. But that hasn't always been the case, so people wrote a lot of JS out of necessity. And that's why it's at the top. (I don't mean to riff on JS in this post. There are plenty of other opportunities for that. The language has improved over the years, and this is surely part of the reason it's remained at #1, and part of the reason why browser vendors didn't throw up their hands and try a different language instead. But the main reason its at the top is because it's the language of the web.) If SmallTalk were built into browsers instead of JS, then we'd all be writing SmallTalk. And it'd be blazing fast. And that has nothing to do with how sound its design is.
  - paulddraper 8y ago
    Or if PHP were built into browsers, we'd all be using PHP.
    - exikyut 8y ago
      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 sanity (the SQLite3 extension will run all queries twice unless you code around bugs that have been known about for 10 years), etc), socket I/O (you physically cannot write rock-solid sockets code; the builtin streams functionality _and_ the socket extension do not provide enough surface area to handle all plausible error conditions, and it's entirely possible your script will hard-crash in certain obscure scenarios because the runtime doesn't give you the ability to trap all errors), and because of these longstanding issues PHP _does still have_ a sad culture of "it's okay, we'll just do this crazy horrible workaround", and nobody's fixing it. I wanted to give a practical example, but unfortunately I can't find it. I was debugging some incredibly confusing socket behavior one day, and found where a major library/framework had hit exactly the same problem, and what they did - it was a remarkably well-engineered solution - was to setup a custom error handler, preg_match() the PHP error string (!) inside the error handler, then use some magic "if this is set to this and that var equals that value" derived from reading the PHP source code to detect a socket error condition. This code is still in place since PHP 7 hasn't fixed any of this, I just can't remember the library name or where to look for the code unfortunately. </rant>
      - deleted 8y ago
        [deleted]
  - teapot7 8y ago
    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 nothing to do with how good or bad the language is.
- mistersquid 8y ago
  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. In which case, languages that flourish on mobile platforms (e.g. browser-resident JavaScript) will survive that measure of "fitness". The same is true in biology. What may seem well-formed, robust, and inevitable is meaningless to the process of natural selection. Nature randomly and arbitrarily chooses what those species that are fittest. People too often mistake "survival of the fittest" to mean "survival of the most beautiful" or "survival of the most logical" because they consider existing species as fit by applying post hoc ergo propter hoc logic.
  - molteanu 8y ago
    Yes, I think it's a well accepted idea (Darwin might have agreed) that "evolution is not progress".
- senozhatsky 8y ago
  I wonder - what do people who used to code in Smalltalk think of "modern" languages. Like Golang, Rust, etc. -ss
  - pjmlp 8y ago
    We stick to our Java and .NET development environments, the only ones close enough to the experience.
    - senozhatsky 8y ago
      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
      - pjmlp 8y ago
        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, ....
        senozhatsky 8y ago
        Thanks a ton, very interesting. I heard of Borland C++ Builder (never had a chance to try it out tho), have never heard of Lucid C++. 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
        pjmlp 8y ago
        Search for Lucid C++ demo on YouTube. Currently on mobile, not so easy to provide a link.
npudar 8y ago
Smalltalk is still a thing of beauty.
femto 8y ago
A pity that Scratch is no longer written in Smalltalk. It was a natural move for a child to discover shift-click-R and progress from Scratch to Smalltalk hacking.
andrepd 8y ago
Everything in this article sounds very fine and agreeable to me. But can anyone actually point me to use cases or examples of the brilliance of Smalltalk? As it stands, it always leaves me feeling this is all very abstract/idealised...
cmiles74 8y ago
There is a lot that I like about Smalltalk. I think one of the most interesting ideas is that everything in the environment is written in the same language; that it's easy to use code from an installed package when you write your own code. I also like the idea that it provides its own GUI environment and IDE, making it easy to interact with and change the way things work. I 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.

81 points by molteanu 8y ago

> 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...

crimsonalucard 8y ago
It's not about subjectivity. It's about exposure. A lot of people weren't exposed to a language long enough to know what is actually better. I bet if everyone were exposed equal parts to smalltalk, javascript, haskell, lisp and python you will see an entirely different paradigm.
justinpombrio 8y ago
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're now starting to get full-featured reliable compilers into JS with sourcemaps and whatnot, plus things like webassembly. So it's becoming quite reasonable these days to write code for the web in a language that isn't JS and not feel like a second-tier citizen. But that hasn't always been the case, so people wrote a lot of JS out of necessity. And that's why it's at the top. (I don't mean to riff on JS in this post. There are plenty of other opportunities for that. The language has improved over the years, and this is surely part of the reason it's remained at #1, and part of the reason why browser vendors didn't throw up their hands and try a different language instead. But the main reason its at the top is because it's the language of the web.) If SmallTalk were built into browsers instead of JS, then we'd all be writing SmallTalk. And it'd be blazing fast. And that has nothing to do with how sound its design is.
- paulddraper 8y ago
  Or if PHP were built into browsers, we'd all be using PHP.
  - exikyut 8y ago
    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 sanity (the SQLite3 extension will run all queries twice unless you code around bugs that have been known about for 10 years), etc), socket I/O (you physically cannot write rock-solid sockets code; the builtin streams functionality _and_ the socket extension do not provide enough surface area to handle all plausible error conditions, and it's entirely possible your script will hard-crash in certain obscure scenarios because the runtime doesn't give you the ability to trap all errors), and because of these longstanding issues PHP _does still have_ a sad culture of "it's okay, we'll just do this crazy horrible workaround", and nobody's fixing it. I wanted to give a practical example, but unfortunately I can't find it. I was debugging some incredibly confusing socket behavior one day, and found where a major library/framework had hit exactly the same problem, and what they did - it was a remarkably well-engineered solution - was to setup a custom error handler, preg_match() the PHP error string (!) inside the error handler, then use some magic "if this is set to this and that var equals that value" derived from reading the PHP source code to detect a socket error condition. This code is still in place since PHP 7 hasn't fixed any of this, I just can't remember the library name or where to look for the code unfortunately. </rant>
    - deleted 8y ago
      [deleted]
- teapot7 8y ago
  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 nothing to do with how good or bad the language is.
mistersquid 8y ago
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. In which case, languages that flourish on mobile platforms (e.g. browser-resident JavaScript) will survive that measure of "fitness". The same is true in biology. What may seem well-formed, robust, and inevitable is meaningless to the process of natural selection. Nature randomly and arbitrarily chooses what those species that are fittest. People too often mistake "survival of the fittest" to mean "survival of the most beautiful" or "survival of the most logical" because they consider existing species as fit by applying post hoc ergo propter hoc logic.
- molteanu 8y ago
  Yes, I think it's a well accepted idea (Darwin might have agreed) that "evolution is not progress".
senozhatsky 8y ago
I wonder - what do people who used to code in Smalltalk think of "modern" languages. Like Golang, Rust, etc. -ss
- pjmlp 8y ago
  We stick to our Java and .NET development environments, the only ones close enough to the experience.
  - senozhatsky 8y ago
    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
    - pjmlp 8y ago
      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, ....
      - senozhatsky 8y ago
        Thanks a ton, very interesting. I heard of Borland C++ Builder (never had a chance to try it out tho), have never heard of Lucid C++. 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
        pjmlp 8y ago
        Search for Lucid C++ demo on YouTube. Currently on mobile, not so easy to provide a link.

npudar 8y ago

Smalltalk is still a thing of beauty.

femto 8y ago

A pity that Scratch is no longer written in Smalltalk. It was a natural move for a child to discover shift-click-R and progress from Scratch to Smalltalk hacking.

andrepd 8y ago

Everything in this article sounds very fine and agreeable to me. But can anyone actually point me to use cases or examples of the brilliance of Smalltalk? As it stands, it always leaves me feeling this is all very abstract/idealised...

cmiles74 8y ago

There is a lot that I like about Smalltalk. I think one of the most interesting ideas is that everything in the environment is written in the same language; that it's easy to use code from an installed package when you write your own code. I also like the idea that it provides its own GUI environment and IDE, making it easy to interact with and change the way things work. I 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.