4 ms·

Interesting talk. Smalltalk (like Lisp) has indeed a very simple (i.e. minimal) syntax. But that doesn't necessarily mean that it is also simple to write and re

by Rochus 3y ago

Interesting talk. Smalltalk (like Lisp) has indeed a very simple (i.e. minimal) syntax. But that doesn't necessarily mean that it is also simple to write and read code, or to implement an efficient compiler. E.g. blocks - as great as they are - make inlining very difficult; it eventually took 30 years to implement a VM with decent performance (see http://software.rochus-keller.ch/are-we-fast-yet_crystal_lua_node_som_pharo_i386_results_2020-12-29.pdf http://software.rochus-keller.ch/are-we-fast-yet_crystal_lua... for the results of https://github.com/rochus-keller/Som/ https://github.com/rochus-keller/Som/ and https://github.com/rochus-keller/Smalltalk/ https://github.com/rochus-keller/Smalltalk/ compared to Cog/OpenSmalltalk). Another language explicitly designed for simplicity is e.g. Oberon, which is statically typed and easier to implement with decent performance. In my experience, at the end of the day, it's more the familiarity with a language that makes it seem "simple". And there is a trade-off between "simplicity" of the language and "simplicity" of the solution; if the language is too minimal, the solution quickly becomes confusing instead, and vice versa.

wslh 3y ago
> But that doesn't necessarily mean that it is also simple to write and read code Right, having several friends in the smalltalk/Squeak scene I tried "obvious" things that required to know the patterns of, for example, Morphic framework [1]. I understand that if you include a good development wizard/assistant would significantly improve the learning curve. [1] https://wiki.squeak.org/squeak/morphic https://wiki.squeak.org/squeak/morphic
Rochus 3y ago
Funny, I wrote that two days ago, here it says three hours.
- Jtsummers 3y ago
  Second chance pool. When a post is on there, it will may get its timestamp updated to the current time and will be tracked as if it was submitted at that time. All existing comments will get that same timestamp for a while. The fake timestamp helps to game the ranking so it goes to the front page for its second chance at discussion and votes. Eventually the real timestamp is restored. https://news.ycombinator.com/pool https://news.ycombinator.com/pool
hayley-patton 3y ago
Self wasn't sufficiently fast? Craig Chambers's compiler [0] had to be careful around recursive inlining* but it's not that bad, and the compiler definitely came around in less than 30 years of Self or Smalltalk existing (even if you start counting from Smalltalk-72). A sibling comment mentions that Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: in the bytecode, but Self pulled nothing like that. [0] http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 *Although maybe too careful - the important parts are that you don't inline forever, so some degree of recursive inlining is okay (and would help in the factorial example), and that you have a good reason to inline.
- Rochus 3y ago
  > Self wasn't sufficiently fast? Self apparently is sufficiently different from Smalltalk-80 so that even today JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. Remember that also Python is known to be pretty resistant to performance improvements. So some languages/VMs apparently are more amenable than others. In my referenced report you can see that there is still nearly a factor two between Pharo (using OpenSmalltalk) and Node.js (using V8). But Pharo is at least faster than LuaJIT, which again is about factor 220 faster than a Smalltalk interpreter which does the caching and inlining described in the Bluebook. So Cog/OpenSmalltalk went a long way to finally be the fastest Smalltalk engine around. A comparison with Smalltalk 72 makes little sense because it was a completely different language and engine. > Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: That was just because a convention on lexical level made it possible. Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline. If you're interested in the machinery behind the scenes, here are a couple of tools which facilitate an analysis: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk.
  - matheusmoreira 3y ago
    > Remember that also Python is known to be pretty resistant to performance improvements. People certainly say that a lot. This thread for example: https://news.ycombinator.com/item?id=38923741 https://news.ycombinator.com/item?id=38923741 > The take that CPython should be a reference implementation and thus slow always aggravated me What is the actual reason for that? How do other languages avoid falling into that trap? That thread gave me the impression the source of the problem is direct linkage to C extensions instead of native high level foreign interfaces. The resulting code is too tightly coupled to CPython internals which prevents optimization. Is this right?

by Rochus 3y ago

wslh 3y ago

> But that doesn't necessarily mean that it is also simple to write and read code Right, having several friends in the smalltalk/Squeak scene I tried "obvious" things that required to know the patterns of, for example, Morphic framework [1]. I understand that if you include a good development wizard/assistant would significantly improve the learning curve. [1] https://wiki.squeak.org/squeak/morphic https://wiki.squeak.org/squeak/morphic

Rochus 3y ago

Funny, I wrote that two days ago, here it says three hours.

Jtsummers 3y ago
Second chance pool. When a post is on there, it will may get its timestamp updated to the current time and will be tracked as if it was submitted at that time. All existing comments will get that same timestamp for a while. The fake timestamp helps to game the ranking so it goes to the front page for its second chance at discussion and votes. Eventually the real timestamp is restored. https://news.ycombinator.com/pool https://news.ycombinator.com/pool

hayley-patton 3y ago

Self wasn't sufficiently fast? Craig Chambers's compiler [0] had to be careful around recursive inlining* but it's not that bad, and the compiler definitely came around in less than 30 years of Self or Smalltalk existing (even if you start counting from Smalltalk-72). A sibling comment mentions that Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: in the bytecode, but Self pulled nothing like that. [0] http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72 *Although maybe too careful - the important parts are that you don't inline forever, so some degree of recursive inlining is okay (and would help in the factorial example), and that you have a good reason to inline.

Rochus 3y ago
> Self wasn't sufficiently fast? Self apparently is sufficiently different from Smalltalk-80 so that even today JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. Remember that also Python is known to be pretty resistant to performance improvements. So some languages/VMs apparently are more amenable than others. In my referenced report you can see that there is still nearly a factor two between Pharo (using OpenSmalltalk) and Node.js (using V8). But Pharo is at least faster than LuaJIT, which again is about factor 220 faster than a Smalltalk interpreter which does the caching and inlining described in the Bluebook. So Cog/OpenSmalltalk went a long way to finally be the fastest Smalltalk engine around. A comparison with Smalltalk 72 makes little sense because it was a completely different language and engine. > Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: That was just because a convention on lexical level made it possible. Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline. If you're interested in the machinery behind the scenes, here are a couple of tools which facilitate an analysis: https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk.
- matheusmoreira 3y ago
  > Remember that also Python is known to be pretty resistant to performance improvements. People certainly say that a lot. This thread for example: https://news.ycombinator.com/item?id=38923741 https://news.ycombinator.com/item?id=38923741 > The take that CPython should be a reference implementation and thus slow always aggravated me What is the actual reason for that? How do other languages avoid falling into that trap? That thread gave me the impression the source of the problem is direct linkage to C extensions instead of native high level foreign interfaces. The resulting code is too tightly coupled to CPython internals which prevents optimization. Is this right?