Live data from Hacker News

Design Principles Behind Smalltalk (1981)

cs.virginia.edu

21–30 of 33 posts

Re: Design Principles Behind Smalltalk (1981)

#21
post #19

Earlier quoted context omitted.

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

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

Search for Lucid C++ demo on YouTube.

Currently on mobile, not so easy to provide a link.

Re: Design Principles Behind Smalltalk (1981)

#22
post #13
post #7

Earlier quoted context omitted.

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…

Had not heard that, but this is truely heartbreaking. I still think that Smalltalk is the better language than most of the modern object oriented languages, and be it only that is is a bit more pure and its "successors" are too much a mix with other paradigms. Just thinking of Python - it is in a wide range of features equivalent to Smalltalk withtout being as consequent in the object orientation. One could only drea…

Actually, Sun tried to license Smalltalk from Parcplace to use in embedded devices. At that time Parcplace was quite happy to charge $3000 per seat and didn't make a reasonable offer to Sun, so the Oak (now Java) project was started instead.

To make things even worse, Parcplace merged with their main rival, Digitalk, which offered Smalltalks for PCs and Macs for $100 to $500. They promptly replaced those with "enterprise" products costing way more making it impossible for new people to learn the language except with toy implementations like Little Smalltalk and GNU Smalltalk (which later evolved into a very decent implementation). For some reason the nice Smalltalk/X (commercial, but free for educational use) only had a small niche in Europe.

Note that Sun already had a Smalltalk in the form of Self, but Java was created anyway and Sun decided to use it exclusively killing Self and Tcl (which spun off instead of dieing). Part of the Self group merged with a group researching Smalltalk with optional type declarations (Dart is the latest version of that) to create the company Animorphics to develop StrongTalk.

Meanwhile, the Pep project at Sun demonstrated that you could run Java on the Self VM and greatly outperform all existing Java implementations (which were simple bytecode interpreters). The Animorphics team did the same and showed off Java on their VM, which caused Sun to buy them to make this demo into the HotSpot VM.

Re: Design Principles Behind Smalltalk (1981)

#23
post #2

> 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

Some of us still use Smalltalk, as you might imagine (the language is hardly in the top 10 but is far from dead). Dan Ingalls, the author of that article, has been using Javascript for the past decade or so to create a Smalltalk-like environment called Lively Kernel. L Peter Deutsch gave a talk many years ago about why Python had replaced Smalltalk as his favorite language (I can no longer find the talk on the Internet). David Ungar (who co-created the Smalltalk On A RISC, SOAR, chip and the Self language) seems to be focused on Swift.

Re: Design Principles Behind Smalltalk (1981)

#24
post #15

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

Can you expand on that? I would never have expected to see Smalltalk being compared with Java. They really seem worlds apart.

If anything, among more "modern" languages, I would think that the closest thing to Smalltalk is Ruby.

EDIT: Here's an example piece of code of Smalltalk:

    #(1 2 3 4 5) select: [:i| i odd ]
in the equivalent Ruby:

    [1,2,3,4,5].select {|i| i.odd? }

Re: Design Principles Behind Smalltalk (1981)

#25
post #24
post #15

Earlier quoted context omitted.

We stick to our Java and .NET development environments, the only ones close enough to the experience.

Can you expand on that? I would never have expected to see Smalltalk being compared with Java. They really seem worlds apart. If anything, among more "modern" languages, I would think that the closest thing to Smalltalk is Ruby. EDIT: Here's an example piece of code of Smalltalk: #(1 2 3 4 5) select: [:i| i odd ] in the equivalent Ruby: [1,2,3,4,5].select {|i| i.odd? }

As a language, Ruby is closer to Smalltalk than Java or C# are.

But for overall development experience, modern industrial C# and Java developer environments may be closer to the Smalltalk dev experience.

Re: Design Principles Behind Smalltalk (1981)

#26
post #24

Earlier quoted context omitted.

Can you expand on that? I would never have expected to see Smalltalk being compared with Java. They really seem worlds apart. If anything, among more "modern" languages, I would think that the closest thing to Smalltalk is Ruby. EDIT: Here's an example piece of code of Smalltalk: #(1 2 3 4 5) select: [:i| i odd ] in the equivalent Ruby: [1,2,3,4,5].select {|i| i.odd? }

As a language, Ruby is closer to Smalltalk than Java or C# are. But for overall development experience, modern industrial C# and Java developer environments may be closer to the Smalltalk dev experience.

[deleted]

Re: Design Principles Behind Smalltalk (1981)

#27
post #21

Earlier quoted context omitted.

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

Search for Lucid C++ demo on YouTube. Currently on mobile, not so easy to provide a link.

No worries, I think I found it

https://www.youtube.com/watch?v=pQQTScuApWk

That's awesome.

-ss

Re: Design Principles Behind Smalltalk (1981)

#28
post #23

Earlier quoted context omitted.

I wonder - what do people who used to code in Smalltalk think of "modern" languages. Like Golang, Rust, etc. -ss

Some of us still use Smalltalk, as you might imagine (the language is hardly in the top 10 but is far from dead). Dan Ingalls, the author of that article, has been using Javascript for the past decade or so to create a Smalltalk-like environment called Lively Kernel. L Peter Deutsch gave a talk many years ago about why Python had replaced Smalltalk as his favorite language (I can no longer find the talk on the Intern…

You have a great memory. Thanks for the pointers, very educational.

-ss

Re: Design Principles Behind Smalltalk (1981)

#29
post #24
post #15

Earlier quoted context omitted.

We stick to our Java and .NET development environments, the only ones close enough to the experience.

Can you expand on that? I would never have expected to see Smalltalk being compared with Java. They really seem worlds apart. If anything, among more "modern" languages, I would think that the closest thing to Smalltalk is Ruby. EDIT: Here's an example piece of code of Smalltalk: #(1 2 3 4 5) select: [:i| i odd ] in the equivalent Ruby: [1,2,3,4,5].select {|i| i.odd? }

You are only focused on the language grammar, instead of the full development experience.

This is what most people miss when comparing languages.

Re: Design Principles Behind Smalltalk (1981)

#30
post #29
post #24

Earlier quoted context omitted.

Can you expand on that? I would never have expected to see Smalltalk being compared with Java. They really seem worlds apart. If anything, among more "modern" languages, I would think that the closest thing to Smalltalk is Ruby. EDIT: Here's an example piece of code of Smalltalk: #(1 2 3 4 5) select: [:i| i odd ] in the equivalent Ruby: [1,2,3,4,5].select {|i| i.odd? }

You are only focused on the language grammar, instead of the full development experience. This is what most people miss when comparing languages.

Even then, I heard Smalltalk development was like Lisp, with the ability to do incremental compilation / image based development where you initiate an image that represents a process with built-in, generic saving functionality and the ability to edit the code while it runs. You could start an image, run it, build the program as it runs, save it, restart the computer, and continue the image so it runs from the point it was saved. Here's some online documentation that describes that[1].

There's also REPLs for Smalltalk, but none for Java due to it's syntactic structure that prevents top-level statements.

That sounds like Smalltalk leads to far different development experiences compared to Java.

In other words, I can't think of how anything between Smalltalk and Java could be similar (at least more so than comparing it to any other programming language). Could you expand on that?

[1] http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.htm...

Post reply on HN