For me, the flip side of all of Alan's (and other's) inspiring work on Smalltalk is that, having started programming with Smalltalk in the late 1980s (especiall

For me, the flip side of all of Alan's (and other's) inspiring work on Smalltalk is that, having started programming with Smalltalk in the late 1980s (especially with VisualWorks and OTI's Envy), my entire professional career since then has seemed like a long succession of dealing with less pleasant systems around people who just don't get it. That has been frustrating and painful (even if the money is good) -- in some ways, it might be better not to know what is possible because then you don't miss it. It's sad that ParcPlace Systems made such a mess of commercializing ObjectWorks/VisualWorks Smalltalk (including not licensing it to Sun affordably for settop boxes, where Sun then reacted by creating Oak/Green/Java) and then they sold Smalltalk for a song to Cincom instead of open sourcing it and becoming a services company. I remember talking with one ParcPlace salesperson who kept going on about how Digitalk was their competitor, with my trying to point out that Visual Basic was really their competitor (and ParcPlace buying Digitalk was another part of the disaster for Smalltalk commercially). It was also sad to see IBM abandon two reliable fast Smalltalks it owned in favor of a buggy slow early Java for marketing reasons. And even working within IBM at IBM Research around 1999, I could not use Smalltalk because IBM's OTI subsidiary (which IBM had bought) wanted around US$250K a year internally just to let the embedded speech research group I was in try their embedded Smalltalk for the product we were making. They claimed they'd have to devote an entire support person to it -- and I tried to explain I was going out on a limb there as it was to suggest using Smalltalk instead of C and VxWorks (which my supervisor had already licensed). So instead I got IBM Research to approve Python for internal use (which took weeks of dealing with IBM's lawyers) and Python, not Smalltalk, ended up on Lou Gerstner's desk when he asked for one of our "Personal Speech Assistant" devices for his office. I really learned to dislike proprietary software from that experience of seeing something I loved like Smalltalk being killed by a business model focusing on runtime fees and such. I remember how when an IBM Research group licensed their Jikes Java compiler as FOSS, their biggest surprise was not how many external users they had -- but how many internal IBM users they suddenly had who no longer had to jump through complex hoops to gain access to it. Even now, Java, JavaScript, and Python are not quite where Smalltalk was back then in many ways. Of course, it's decades later, so there are other good things like faster networks and CPUs and mobility and DVCS and above all a widespread culture of FOSS -- and when I squint, I can kind of see all the browsers out there running JavaScript as a sort of big multi-core Smalltalk system (just badly and partially implemented). For a while I had hopes for Squeak, but it got bogged down early on by not having a clear free and open source license. Sames as I did recently to Automattic when it used React with a PATENTS clause, when I pointed out the concern, some lawyer chimed in with how everything was fine -- and only years later did the growing damage to the community become obvious to all. http://wiki.squeak.org/squeak/501 http://wiki.squeak.org/squeak/501 https://github.com/Automattic/wp-calypso/issues/650 https://github.com/Automattic/wp-calypso/issues/650 I really learned to dislike unclear licensing on a community project from that early Squeak experience. Squeak continues to improve and has fixed the licensing issue, but it lost a lot of momentum. Also the general Squeak community remains more focused making a better Smalltalk -- not making something better than Smalltalk. That is something Alan Kay has pointed out -- saying he wanted people to move beyond Smalltalk with Squeak as a stepping stone. Yet most people seem to not pay attention to that. But if even Dan Ingalls could be willing to build new ideas like the Lively Kernel on JavaScript, I decided I could too, and I shifted my career in that JavaScript direction inspired by his example. As luck would have it, my day job is now programming in the overly-complex monstrosity that is Angular, when I know the more elegant Mithril.js is so much better from previous experience using it for personal FOSS projects... I guess every technology has its hipster phase where decision making is more about fads than any sort of technical merit or ergonomics? I can hope that sorts itself eventually. But once bad standards get entrenched either in a group or the world at large, it can be hard to move forward due to sunk costs, retraining costs, retesting costs, and so on. But, thick-headed as I am, I keep trying anyway. :-) And as in another comment I made, there are important social/political reasons to keep trying to create better systems to support democracy: https://news.ycombinator.com/item?id=15311950 https://news.ycombinator.com/item?id=15311950