For those of you smalltalk fans, what are you working in today / what would you prefer to be working in today given your history with smalltalk?
The Rise and Fall of Commercial Smalltalk
41–50 of 141 posts
Re: The Rise and Fall of Commercial Smalltalk
#42Earlier quoted context omitted.
I can't see Go as anything more than tripe aimed at commoditized development. Yay at being a cog in a giant machine. Smalltalk and the ideas it was based on revolutionized personal computing. There is raw, unbridled genius in it and that should be widely recognized.
Who's to disagree with your aesthetic judgement? You're not wrong to like it, if you like it. I found it sufficiently obtuse that I walked away from my life's dream. The nostalgia circuit touts it as an amazing educational environment, in my experience it was not.
I was self-taught in Java, C and Foxpro, and then joined a company of Smalltalkers who had to transition to Java. They used Visual Age for Smalltalk and Visual Age for Java.
For various reasons, for a few months at work, I had a really low end computer that couldn't run Visual Age for Java. (I couldn't afford a computer that could run Visual Age for Java/Smalltalk).
However, I got to learn from some of the best Smalltalkers in the world. Thanks to the wonderful foundation they gave me in OOPs, I have since then been able grasp domains very well.
In a different set of circumstances, I got to learn how agile and Test Driven Development work very well even in larger teams. I've worked on teams with 250 odd people from three different companies and two different timezones and cultures. Due to my current work, I get to see how horrible a person's experience can be with agile and with Test Driven Development.
Today, I had an illuminating 90 minutes session on Complex Numbers. This was my second class online. After 30-odd years of being furious at Mathematics, I have now come to embrace it.
I have concluded that the right mentorship and learning materials and experience can go a long way in helping make a topic exciting and interesting.
Your hurt is evident. From what you have shared, it seems to be the absence of good tutorials that were a roadblock, and not Smalltalk or Visual Age for Smalltalk itself.
Re: The Rise and Fall of Commercial Smalltalk
#43From inside ParcPlace, it looked like we were starting to gain traction. There'd been a number of spectacular C++ project failures, and people seemed to be willing to try this weird, new (to them) thing that let them get prototypes up quickly and then grow them. Then Java arrived and sucked all of the air and mindshare out of the ecosystem. Java lucked into ideal circumstances, and Sun Marketing played their hand ver…
>There'd been a number of spectacular C++ project failures,
Do you have any examples in mind? Big corporate software project failures are always super interesting imo. Especially those that happened during such pivotal times as rhe 1990s.
Re: The Rise and Fall of Commercial Smalltalk
#44I 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…
> I couldn't believe that anyone would want to mouse-around to poke through the available classes and methods. So I dont know a ton about smalltalk outside of what I've read and poking aside in squeak for a few minutes, but is this how smalltalk apps were supposed to be distributed and run? Inside a sandboxes system like that?
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. You can do this with any language IDE today where you attach the source code of libraries to the project workspace.
Re: The Rise and Fall of Commercial Smalltalk
#45Those 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…
Yes, my recollection of the Squeak browser plugin was that the performance was indistinguishable from running regular Squeak, several orders of magnitude better than SqueakJS. And the startup time was vastly better than any Java plugin code.
However, if you were on dial-up, and your browser didn't already have a cached copy of the smalltalk image, then you were in for a quite a wait. (Though no doubt this could have been addressed - there were people arguing at the time for the creation of a much smaller Squeak image, but a combination of the lack of a clear goal to motivate this work, and the fact that for most existing users it was a non-issue, meant that nothing came of this within the timeframe where it might have made a difference.)
But it may be that this is all moot, because it could be argued that any browser-plugin deployment model would ultimately fail.
Re: The Rise and Fall of Commercial Smalltalk
#46From inside ParcPlace, it looked like we were starting to gain traction. There'd been a number of spectacular C++ project failures, and people seemed to be willing to try this weird, new (to them) thing that let them get prototypes up quickly and then grow them. Then Java arrived and sucked all of the air and mindshare out of the ecosystem. Java lucked into ideal circumstances, and Sun Marketing played their hand ver…
>There'd been a number of spectacular C++ project failures, Do you have any examples in mind? Big corporate software project failures are always super interesting imo. Especially those that happened during such pivotal times as rhe 1990s.
I wasn't there, but apparently Taligent was a failed C++ operating system from Apple and IBM in the 90's.
I think there is a talk on YouTube by Bryan Cantrill that gives some color on it...
Re: The Rise and Fall of Commercial Smalltalk
#47Speaking as a Smalltalk programmer active in the 1990s we pretty much dropped everything when Java showed up. It had the things we loved in Smalltalk (portable virtual machine, garbage collection, self-documenting APIs, collection classes, etc.) with the familiar syntax of C++ and concurrency. In a way Smalltalk prepared the way for Java in that it showed how great VMs and garbage collection were.
I can't understand. People says that ST ecosystem is much superior to nowadays languages, so why people at that time switched to the starter version of java, that is so bad compared to today? After the shift, did you miss something?
I actually went in the oposite direction: I started with C++ and Java. Until I had the opportunity to work with a very interesting team using Smalltalk (this was in 2004, so St was not popular anymore, but I liked the team and it was an opportunity to learn).
The article is very good describing what failed, from business to technology.
Why people jumped from St to Java? Besides the licenses and the OS movement that took many St companies off guard, there were also technical issues:
- Java was better for server side work. It had mature frameworks for Http/XML/Database access. Big companies allocated tons of resources to create Java frameworks and tools... the situation for St was different, you were at your own. For example, I had to debug and fix the WebServices framework available in VisualAge... because I didn’t have another choice.
- The JVM was superior in many areas: native threads, different GC algorithms, JIT, and many tools for monitoring and troubleshooting. Most of the St VMs only had green threads, it means that any blocking native libraries (like DB drivers) are problematic.
- As the article says, enterprises moved from desk apps to the web. And web frameworks for St arrived late.
- The classic St-80 was not designed with the idea of packages in mind. Loading a package is basically executing code that modifies your image. It’s powerful, but problematic because it can introduce unexpected bugs. Strongtalk tried to fix that, but it was a research project.
- To the package isolation problem, add the fragmentation between St implementations... it didn’t help to create an open source ecosystem of shared libs like in Java.
What I miss? The environment! In St you have absolute control of the environment. You can inspect everything (including your editing tools), and evaluate code everywhere without having to stop the world. Today you have editors or IDEs with plugin APIs, but is not the same. A comparable experience is modifying things live in the web browser, but it lacks the inspection/authoring tools from St.
Re: The Rise and Fall of Commercial Smalltalk
#48Discussions about Smalltalk almost always remind me of Self[0] from Sun. It is an extremely simple prototype-based programming language. An object can have many "parents", and defines properties on itself to expose an interface. It's really fun to mess around with. The Morphic UI is kind of archaic though. [0]: https://selflanguage.org/
Do you mean that the morphic ui is archaic looking? Because my impression of it is that it is still ahead of its time technically.
Re: The Rise and Fall of Commercial Smalltalk
#49Earlier quoted context omitted.
> I couldn't believe that anyone would want to mouse-around to poke through the available classes and methods. So I dont know a ton about smalltalk outside of what I've read and poking aside in squeak for a few minutes, but is this how smalltalk apps were supposed to be distributed and run? Inside a sandboxes system like that?
On certain systems, there are tools that make them feel more native. Eg. on Dolphin Smalltalk which ran on Microsoft Windows, you can run a utility to stripped off the unnecessary parts (eg. the browser/editors and unused classes) of the image and it gets bundled into an .exe which includes a VM. A user wouldn't know it's running Smalltalk. It turned out to be an excellent tool to write Windows app during its time. T…
No need for past tense there, Dolphin Smalltalk is still being developed and is open source now, https://github.com/dolphinsmalltalk.
Re: The Rise and Fall of Commercial Smalltalk
#50Earlier quoted context omitted.
On certain systems, there are tools that make them feel more native. Eg. on Dolphin Smalltalk which ran on Microsoft Windows, you can run a utility to stripped off the unnecessary parts (eg. the browser/editors and unused classes) of the image and it gets bundled into an .exe which includes a VM. A user wouldn't know it's running Smalltalk. It turned out to be an excellent tool to write Windows app during its time. T…
No need for past tense there, Dolphin Smalltalk is still being developed and is open source now, https://github.com/dolphinsmalltalk .
Haha. True. It's history for me, but the great product lives on.
The nick "blairmc-msft" is interesting though. He's at Microsoft, or was at some point?