2009/3/18 Stéphane Ducasse <[email protected]>: > Hi all > > I found this email really interesting. > Especially the concurrent aspects. > Clearly some nice research projects in perspective. > Also the immutability bit supports would be great. >
I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads. There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems. From this point, running separate object memory per native thread seem most perspective way. Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming. > Stef > > Begin forwarded message: > >> From: Antony Blakey <[email protected]> >> Date: March 18, 2009 2:50:47 AM CEST >> To: [email protected], VWNC NC <[email protected]> >> Subject: Re: [vwnc] Would you start a new Smalltalk project today? >> >> I am a commercial user of VW. >> >> I've recently replaced my VW/GLORP/Postgresql app with one built in >> Ruby/CouchDB. I moved to Ruby because the documentation/learning >> material is superior to VW, because of the number of third party >> components, which is partly an issue of VW not being Open Source, >> because of tools such as Rails, Sinatra and Merb (which I still prefer >> over Seaside), and because I needed to focus on sustainable technology >> transfer into a market that won't accept VW. Tangentially I wanted to >> (subjectively) quantify the productivity improvement due to Smalltalk >> relative to another dynamic language (as opposed to Java in Eclipse). >> >> My experience with Ruby is that the language itself is just too much >> of a hack, and this was especially brought home to me when I started >> doing Scala and Clojure, and that emphasized for me the beauty of >> Smalltalk and Lisp/Scheme. >> >> I'm going back to Smalltak for new commercial development, partly >> because of this, but also because a) the Squeak community is getting a >> real injection of energy with Cog and Pharo (which itself pushes >> Squeak) and b) I'm getting a good feeling about the way the Cincom >> team is changing VW - not only what they're doing, but there seems to >> be a much clearer vision and approach that when I first encountered >> it. >> >> I'm also building a commercial application in Scala and Clojure. Both >> are great languages, especially for highly concurrent apps, and the >> library support is huge because they seamlessly use Java. If this were >> the "good old days"(TM) I'm sure someone would be working on decent >> concurrency support for Smalltalk. Using multiple images is one >> approach, but not one that I like - it seems (IMHO) to be a reaction >> to the lack of resources to do something better. Most of the Erlang/ >> Scala/Clojure goodness could be layered into Smalltalk if someone had >> the will to do so, but I think Cincom would have to do that for it to >> get the wide support it would need to have a dependable future. >> >> One benefit that a JVM language has, as opposed to Smalltalk, is that >> both the underlying performance improves, and the available libraries >> increase and improve independently of the language. Clojure and Scala >> don't need effort per se to improve. Oh for a Smalltalk running on the >> JVM in a high performance manner, with JVM object model integration. I >> think there is no other way to solve this problem for Smalltalk. >> >> I really miss programming in an image despite the pain of the Object/ >> Subject problem. I don't think it's *always* more productive than >> Scala or Clojure (esp for concurrency) but it's more *consistently* >> productive. >> >> Smalltalk's decline has not been terminal, implementations are >> improving albeit more slowly than one would like, and as long as it's >> the right tool for the job then you should use it. >> >> On 18/03/2009, at 8:03 AM, David Finlayson wrote: >> >>> Clojure has some great ideas but you need to know Lisp and Emacs. >> >> Both Scala and Clojure have good and improving support in (to varying >> degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM >> required. I use Clojure and Scala in IntelliJ, and I've done so in >> Eclipse as well. >> >>> 2. No Smalltalk I've used has a decent GUI. Squeak is an >>> abomination, down the road Pharo may be good, but not today and VW >>> looks like it hasn't been updated since the NT days. Although >>> everyone hates Java cross-platform desktop apps, it is interesting >>> to compare a VW app (say Bottom Feeder) to a Java app of similar >>> design (http://www.rssowl.org/overview). In my opinion the Java >>> version fits in a lot better than the VW version (particularly on >>> the Mac). >> >> For VW, my LinkuisticsUI bundle in the public Store improves the >> situation somewhat on OSX for VW 7.6. Cincom are also making >> improvements to the OSX UI for 7.7. >> >> Closure and Scala have Swing integration. Scala has very good SWT >> bindings. All three IDEs have GUI builders. >> >> Maybe you should consider a Web UI - checkout tools such as Capuccino >> and efforts like bespin. >> >> Antony Blakey >> ------------- >> CTO, Linkuistics Pty Ltd >> Ph: 0438 840 787 >> >> A reasonable man adapts himself to suit his environment. An >> unreasonable man persists in attempting to adapt his environment to >> suit himself. Therefore, all progress depends on the unreasonable man. >> -- George Bernard Shaw >> >> >> _______________________________________________ >> vwnc mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
