I love so much about Smalltalk but also felt many frustrations with implementations and community issues. A couple of me own rants on that include from 2007: "

I love so much about Smalltalk but also felt many frustrations with implementations and community issues. A couple of me own rants on that include from 2007: "[Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re: More Pipeline News)" https://mail.python.org/pipermail/edu-sig/2007-March/007822.html https://mail.python.org/pipermail/edu-sig/2007-March/007822.... "There is once again the common criticism leveled at Smalltalk of being too self-contained. Compare this proposal with one that suggested making tools that could be used like telescope or a microscope for relating to code packages in other languages -- to use them as best possible on their own terms (or perhaps virtualized internally). Consider how the proposal suggests scripting all the way down -- yet how are the scripting tools built in Squeak? Certainly not with the scripting language. And consider there are always barriers to any system -- where you hit the OS, or CPU microcode, or proprietary hardware specifications, or even unknowns in quantum physics, and so on. :-) So every system has limits. But by pretending this one will not, this project may miss out on the whole issue of interfacing to systems beyond those limits in a coherent way. For example -- OpenGL works, and represents an API that has matured over a quarter century, and is linked with lots of hardware and software implementations; why not build on it instead of "bitblt"?. Or consider how Jython can use Java Swing libraries and other such Java libraries easily. Consider this example of proposed failure: the proposal's decision to punt on printing -- no focus there in difficulties of interfacing with a diversity of OS services as a guest -- of relating to prior art. This is where Python often shines as a system (language plus libraries plus community) -- and Python is based on a different design philosophy or perhaps different design ethic. Python has also prioritized "modularity" from the beginning, which has made a lot of these issues more manageable; Kay's proposal talks a lot about internal integration, but the word "modularity" is not even in the document. In this sense, I think Kay's group are repeating mistakes of the past and also dodging another very difficult issue -- one that Python somehow has more-or-less gotten right in its own way. It's their right to do their own thing; just pointing out a limitation here." And later from 2010: "[fonc] On inventing the computing microscope/telescope for the dynamic semantic web" https://www.mail-archive.com/fonc@vpri.org/msg01445.html https://www.mail-archive.com/fonc@vpri.org/msg01445.html "As I said at the end of my second post linked above: "It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)"" The sourceforge link in that post rotter; that last quoted text can now be found at: "Re: [PataPata-discuss] Thinking on PataPata four years later..." https://sourceforge.net/p/patapata/mailman/message/26393156/ https://sourceforge.net/p/patapata/mailman/message/26393156/