Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of Commercial Smalltalk

wirfs-brock.com

Post reply on HN
Print view View original

121–130 of 141 posts

Re: The Rise and Fall of Commercial Smalltalk

#121

Post by hboon »

alrs wrote: post #97
solarengineer wrote: post #44

Earlier quoted context omitted.

I am surprised that what alrs has said. At some point, one actually does poke around and understand what is going on to know how a system works. alrs states that they are contributing to K8s. That does require poking around to learn the plumbing of the system. You could very well write Smalltalk apps without poking around the underlying classes. The Visual Age for Smalltalk environment just made it very easy to do so…

I love poking around. I love poking around with vi, more, and grep. I cannot fathom how someone would want to poke around with a mouse while pointing, clicking, and peering into a little 2" x 2" dialog box.

I have been using vim for about 2 decades so I can empathise with not having the familiar key bindings and speed of moving around.

A good Smalltalk environment does let a developer navigate the image [1]. On many systems that means it allows you to poke at everything about that Smalltalk system, not just your own code, but 3rd party libraries, as well as the Smalltalk system itself, including what we normally consider the text editor or IDE.

It's true that you lose access to vim [2], but you trade that it for the image as well as wonderful code browsing capability in the sense of looking up a type definition, senders and implementors of a message, stepping into any code, live debugging and editing during debugging, etc.

So Smalltalk is a tradeoff. If one can give up vi and work with the paradigm, it is really really great. [3]

[1] The Smalltalk image is a wonderful and beautiful concept. There is one glaring downside to it for most Smalltalk systems. It creates a divide between the image and the rest of the world. [2] Since you can redefine how any code in the image work, it's possible to define a few shortcuts so you get a very limited set vim functionality, but it's not feasible to reproduce the vi environment (even if we want to invest the effort) because the paradigms are different. [3] One can say that's generally true for everything. "Once you can accept X, you get Y", but the argument is that Smalltalk is really great once a developer does that.

Re: The Rise and Fall of Commercial Smalltalk

#122

Post by russellallen »

jecel wrote: post #104
russellallen wrote: post #67

Earlier quoted context omitted.

Unfortunately the version in Squeak is, in my opinion, fancy looking but a backwards step from the Self version in terms of the underlying system. Morphic doesn't seem to really fit all that well with class based systems.

While being class based does make Squeak's Morphic a bit more awkward than Self's, the big difference is that it is a hybrid system that can run older MVC (Model View Controller) applications with little or no modification. That means that there are two different ways of doing most things and someone looking for examples to copy might run across the MVC version instead of the "proper" Morphic version.

My experience of doing morphic stuff in both Squeak and Self, is that in Squeak there was a bit of a disconnect between the instance side and the class side - you could click together morphs, but in the end you had to write code in morphic classes to reconstruct those morphs.

There wasn't any automatic way to go from the morph instances to equivalent morph constructors, or any way to save the morph instances to copy and use later. So I ended up ignoring the instance manipulation and just coded morph creation methods.

In this way, the morph class hierarchy became much like a hierarchy of factories.

This mattered when I was doing a GUI to run on my Compaq iPaq because a lot of morphs (such as menus) were being created afresh each time they were needed. This was really slow and I only made it usable by caching the created menus and only displaying them when needed.

On Self I would have just copied the previously constructed menuMorph prototype and displayed it (if of course I had been able to port the huge pile of C++ that is the Self VM to the iPaq :)

This was ages ago though and I haven't played properly with modern Squeak or Cuis.

Re: The Rise and Fall of Commercial Smalltalk

#123

Post by fulafel »

hodgesrm wrote: post #27
pjmlp wrote: post #19

Earlier quoted context omitted.

It was free beer, while most Smalltalk products had prices on the enterprise ranges. Then all C / C++ compiler vendors, jumped on the wave by adding support for the free beer Java SDK on their IDEs. Just like Linux versus commercial UNIXes of the day, free is a mighty power.

The free part certainly helped adoption over time, but at the time Java first arrived everyone was conditioned to pay for IDEs and most compilers for that matter. Java took off because of the reasons I cited up-thread rather than cost. It was initially marketed as a language for web browsers. Most of us just ignored that use case and put it to work in enterprise apps.

I wonder if there are surveyst to be found about IDE usage from those times... IDEs were common in some circles in the early 90s but less so in others. Java wasn't a very high level language even in those days - we had Perl, Tcl, Python, PHP, etc used for web and non-web things. And on the low level side we had C. IDEs were less used with those languages.

Re: The Rise and Fall of Commercial Smalltalk

#124

Post by eitland »

e12e wrote: post #110
eitland wrote: post #109

Earlier quoted context omitted.

Are you looking for a smalltalk job? :-)

It certainly sounds intriguing...

I sent you a mail to the address in your profile :-)

For anyone else, I'm not in a position to hire anyone but if you know Norwegian, Danish or Swedish reasonably well and want an interesting job with nice people (well, if you like people from the Nordic countries) then feel free to ask me.

We mostly work on larger systems, some of the systems was born a decade before the youngest persons who maintain them, others are brand new today but will hopefully be equally valuable and live a long life as well :-)

Re: The Rise and Fall of Commercial Smalltalk

#125

Post by e12e »

eitland wrote: post #124
e12e wrote: post #110

Earlier quoted context omitted.

It certainly sounds intriguing...

I sent you a mail to the address in your profile :-) For anyone else, I'm not in a position to hire anyone but if you know Norwegian, Danish or Swedish reasonably well and want an interesting job with nice people (well, if you like people from the Nordic countries) then feel free to ask me. We mostly work on larger systems, some of the systems was born a decade before the youngest persons who maintain them, others ar…

Ah, I'm afraid the mx's are still down as a precaution due to the awful opensmtpd bug earlier this year. I'll pling the Gmail in your profile.

I really should bring those back up - unfortunately the servers need a bit of an (software/distro) upgrade.

Re: The Rise and Fall of Commercial Smalltalk

#126

Post by felideon »

travisgriggs wrote: post #119
felideon wrote: post #75

Earlier quoted context omitted.

> the languages I work in today (Swift, Kotlin, Python, Dart, C). Are you a mobile app developer?

I do embedded on the metal with no or RTOS, in C. Embedded on Linux (think Raspberry pi form factor) with Python and other Linux stuff. At Swift/Kotlin/Dart for mobile apps. A different sort of full stack where we're developing the gadgets and the apps that interface with them through bluetooth.

Interesting! Once you're at Swift and Kotlin, is there any reason to pick up Dart?

As a web dev, I've done Ruby, JavaScript, and Common Lisp; and have dabbled in Dart, Elixir, and now SwiftUI. If I wanted to start building mobile apps, I'm wondering if that would suffice or if I'd have to pick up Kotlin as well.

Re: The Rise and Fall of Commercial Smalltalk

#127

Post by agumonkey »

travisgriggs wrote: post #21

One of the things that Allen only barely hints at and I'm not sure Gilads piece really touches on was the shifting economics in Software development. In 1995/96 when Java gut punched the wind out of Smalltalk and the other OO solutions (CLOS, Eifel, Beta, etc), they spent a butt load on marketing and gave the stuff away for free. In other industries it would be called "dumping." It wasn't just Sun giving Java away. I…

Did colleges buy into Java through Sun's marketing ? because they felt that it would be a requirement to find a job ?

Re: The Rise and Fall of Commercial Smalltalk

#128

Post by klipt »

hodgesrm wrote: post #11
pixelrevision wrote: post #4

Earlier quoted context omitted.

It’s funny because I’ve only started using it recently and what really captivates me is the live environment. The fact that you can dig in and evaluate/change everything in the same environment you are running it provides an amazing feedback loop. To me it really seems like the “killer feature” of the language but I can’t think of any modern language that has adopted it.

Smalltalk was inspirational, but the environment was a double-edged sword. In ParcPlace Smalltalk even things like stack frames were editable classes. One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM. BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must…

> One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM

Sounds like these live environments didn't support version control or reproducibility in the modern sense then?

Re: The Rise and Fall of Commercial Smalltalk

#129

Post by agumonkey »

alrs wrote: post #6

I took my first college-level programming class in 1997, learning Smalltalk. 1. IBM VisualAge didn't run in Linux, so I had to buy a second hard drive and a copy of Windows 95. 2. I wanted to be working in a terminal, Smalltalk only let you work in an IDE. I couldn't figure it out. I couldn't believe that anyone would want to mouse-around to poke through the available classes and methods. 3. The text was the IBM manu…

about 2. even though I enjoy text, I can also accept that smalltalk placed itself into the interactive graphical realm first and thus would put you into a visual clickodrome of programming constructs.

Re: The Rise and Fall of Commercial Smalltalk

#130

Post by allenwb »

jecel wrote: post #32

Those are all very good points. Since Allen was there and I was not he is in a far better position to know. But my impression was that the Smalltalk group had been reasonably happy with their 8086 based NoteTaker computer and expected their partners (HP, Tektronix, Apple and DEC) to use commercial processors instead of designing custom ones. Even if they were far slower than the Xerox Dorado. About Squeak in a web br…

Dan Ingalls talks about Notetaker/Smalltalk-78 in his forthcoming HOPL 4 paper which should be available within the next two weeks.

There were only a few Notetaker machines built and apparently they were quite slow and not really very useful. But the Notetaker image and VM was also ported to the Dorado. In 1979-80 that was the primary version that was being used within the LRG and was used as the starting point for creating Smalltalk-80.

In my article is a link to the the invitation letter to Tektronix to participate in the Smalltalk-80 dissemination processed. In it they said: "We estimate about one work year for a very expert systems programmer to implement the microcode for the virtual machine and implement the i/o primitives." In the following discussions and visits they only showed us and talked about the microcoded Dorado and Dolphin implementations. They we repeated said words to the effect of "We want you to design a computer to run Smalltalk". LRG was quite secretive about some things and I don't think I had ever heard of Notetaker until 1993 when I read Alan's HOPL-2 paper.

One interesting thing I recently learned from Dan was that NoteTaker used a linear stack with overlapping activation records. This was dropped for the Dorado implementation and Smalltalk-80. That was unfortunate as the overhead of heap allocated stack frames was one of the major performance bottlenecks when implementing Smalltalk-80 on conventional processors. It took those of us doing such implementations a couple years to develop techniques for "cheating without getting caught" while using hidden linear stacks. In retrospect, the poor performance of Smalltalk-80's heap allocated activation contexts in combination with reference counting significantly delayed the viability of microprocessor based Smalltalk-80 implementations.

Post reply on HN