2014-09-16 20:12 GMT-03:00 Torsten Bergmann <[email protected]>: > Smalltalk should/could have a place in this (web centric) world: > > 1. As a backend to serve the web > 2. On the client > 3. Combining 1. and 2.
1. This is were I see it stronger today, and I'm sure it is the majority of Pharo based solutions. 2. I can't tell. I really don't know if there are any software products built with Pharo/Squeak that DEPEND on Morphic exclusive features other than Qwac/Teleplace and Pharo/Squeak itself. Unless you're building something crazy/amazing I don't see the advantage of Morphic/Custom drawn UI over traditional widgets, even HTML widgets. > But we should also rethink Smalltalk to find a better place as a scripting > language. What > I still would like to see: > > - tiny and fast VM with a command line and REPL The Pharo VM is really fast, and according to all I'm reading here regarding Sista and the CogVM itself is going to get faster. It's startup time is fast even for a 40 MB image, smaller images boot faster. The REPL is doable with today's version, I even think there was a REPL implementation out there. The scripting part needs some tweaks to current CommandLineHandlers, maybe using getops like parameters. > - single small base image but fast loadable binary code components (modules, > maybe using the > LoadLibrary trick), similar to what David had with SmallScript or what > BeeSmalltalk is doing with SLL's VisualSmalltalk also had SLL's that could load lots of code really fast. And the VM itself was fast too. I developed with VSE and it was really cool being able to deploy "parts" of your app and bind them at demand and/or update only a particular module. As any library, it also introduced some dependency hell, so it had its tradeoffs. > - but still with the ability to bootstrap up to a full saveable image > - ability to serve the web with easy callbacks into Smalltalk for > implementing functionality > (especially with this we may catch 90% of the usual UI cases). You mean async I/O? If you look at the HTTP2/SPDY drafts or discussions, what I see is that it is going to speed up communications a lot, it will still be text based, but I think binary data is going to be there too, so the cost of HTTP messaging for intercommunication is going to be cheaper in the future. Regards! Esteban A. Maringolo
