5 ms·

It's useful in education, but it also was competitive in what became the Java market. Weirdly, the world bought into a relatively static language when it had t

by zeveb 11y ago

It's useful in education, but it also was competitive in what became the Java market. Weirdly, the world bought into a relatively static language when it had the option to go for the extremely dynamic and flexible SmallTalk instead. I have always thought it an extreme shame that the man-centuries (man-millennia?) sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.

kabdib 11y ago
Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control? For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed? Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run". I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.
- vanderZwan 11y ago
  Regarding your last comment: surely there's a good compiles-to-JS option available these days? There's even a Smalltalk for client-side programming: http://amber-lang.net/index.html http://amber-lang.net/index.html ... not sure how that would work with WebGL though.
  - david-given 11y ago
    Amber's quite heavyweight and requires server-side support to do anything useful. But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc: https://github.com/davidgiven/stellation/tree/stellation5/client https://github.com/davidgiven/stellation/tree/stellation5/cl... Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...) Of course, writing the libraries is the bulk of the work.
- yaowenjiaozi 11y ago
  > Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control? Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that. > Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run". A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.
menacingly 11y ago
It's at least debatable whether or not an "extremely dynamic" environment is a pro or con when it comes to saving man hours
rlander 11y ago
> sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead. Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.
- illumen 11y ago
  ... and then some of that same team went on to do the compiler used by node, and Chrome (V8). Modern JavaScript has many Smalltalk features.. [starts putting on flame retardant suit].
  - bryanlarsen 11y ago
    The best parts of JavaScript are where the Lisp and Smalltalk heritage is apparent. The worst parts are where a PHB told Brandon Eich "we're going to call it Javascript, make it more like Java", and where the PHB told him "I don't care if it's done, we need to ship it".
    - protomyth 11y ago
      Given the object model, I would add another Smalltalk descendent into the mix: Self http://www.selflanguage.org http://www.selflanguage.org
      - thornkin 11y ago
        Self was definitely an influence. It's where the prototype inheritance came from. Not sure that's a good thing. Smalltalk was more traditional in its inheritance model even if it was all duck typing.
        protomyth 11y ago
        For UI, prototype inheritance was nicer on the Newton (NewtonScript) than on the several of the class-based stuff I played with[1]. Morphic include in Pharo / Squeak is based on Self's UI. I actually like a prototype (other than performance issues) more than class-based. It has a much nicer, lighter feel for me. I just don't think Javascript is the best at it. I loved programming NewtonScript other than its clunky syntax in places. NeXTSTEP got around a lot of crappy class-based behavior by having live objects. 1) I swear I still have nightmares that include OnOk
deleted 11y ago
[deleted]

by zeveb 11y ago

kabdib 11y ago

Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control? For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed? Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run". I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.

vanderZwan 11y ago
Regarding your last comment: surely there's a good compiles-to-JS option available these days? There's even a Smalltalk for client-side programming: http://amber-lang.net/index.html http://amber-lang.net/index.html ... not sure how that would work with WebGL though.
- david-given 11y ago
  Amber's quite heavyweight and requires server-side support to do anything useful. But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc: https://github.com/davidgiven/stellation/tree/stellation5/client https://github.com/davidgiven/stellation/tree/stellation5/cl... Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...) Of course, writing the libraries is the bulk of the work.
yaowenjiaozi 11y ago
> Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control? Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that. > Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run". A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.

menacingly 11y ago

It's at least debatable whether or not an "extremely dynamic" environment is a pro or con when it comes to saving man hours

rlander 11y ago

> sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead. Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.

illumen 11y ago
... and then some of that same team went on to do the compiler used by node, and Chrome (V8). Modern JavaScript has many Smalltalk features.. [starts putting on flame retardant suit].
- bryanlarsen 11y ago
  The best parts of JavaScript are where the Lisp and Smalltalk heritage is apparent. The worst parts are where a PHB told Brandon Eich "we're going to call it Javascript, make it more like Java", and where the PHB told him "I don't care if it's done, we need to ship it".
  - protomyth 11y ago
    Given the object model, I would add another Smalltalk descendent into the mix: Self http://www.selflanguage.org http://www.selflanguage.org
    - thornkin 11y ago
      Self was definitely an influence. It's where the prototype inheritance came from. Not sure that's a good thing. Smalltalk was more traditional in its inheritance model even if it was all duck typing.
      - protomyth 11y ago
        For UI, prototype inheritance was nicer on the Newton (NewtonScript) than on the several of the class-based stuff I played with[1]. Morphic include in Pharo / Squeak is based on Self's UI. I actually like a prototype (other than performance issues) more than class-based. It has a much nicer, lighter feel for me. I just don't think Javascript is the best at it. I loved programming NewtonScript other than its clunky syntax in places. NeXTSTEP got around a lot of crappy class-based behavior by having live objects. 1) I swear I still have nightmares that include OnOk

deleted 11y ago

[deleted]