Stef, First a general note: various people have contacted me about the format of my email messages. I share your irritation at the illeffects of decisions beyond my control. First they foisted Group(Un)wise on us, and now LookOut! has the job. I could use a different account, but that causes problems of its own. Anyway, the length of this lead me to try a suggestion that came my way recently: ditch Word as LookOut!'s editor. I swear I tried that early on and did away with it due to something not working correctly (surely not); we'll see. Back to our regularly scheduled program...
Perhaps just my ignorance showing, I see two problematic sides to concurrency. The first is a big deal: getting an image to use multiple processors. The second involves calls to external libraries, where we need to be able to ensure that Pharo is not brought to its knees by a library that blocks for a long time. A final piece of the puzzle is multiple Process instances, but the troublesome aspects of that (I think) fall into the first two categories. In terms of multiple processors/cores, I have no brilliant answers. Andreas floated an idea that made a lot of sense to me. I do not recall the details, but it struck me as being a lot like having multiple system dictionaries to compartmentalize the object memory, simultaneously providing a natural decomposition of the image for the GC. If his idea is nonsense, he fooled me :) External libraries demand an easy way to use OS threads. Dolphin provides "overlapped calls" that block the calling Process but not the entire image. The usual caveats of thread safety apply, but "any" function can be so marked and will be called on separate OS thread. IIRC, they have enhanced the mechanism to lazily choose an OS thread per Process, and to use the thread for all future overlapped calls on that Process. They started out with a thread pool with no memory, but many libraries have thread affinities that can cause problems in the that case. As an example, OpenSSL stores error information in thread local storage, and one obtains it by a separate function call on the same thread. At the time that I wrote my interface for Dolphin, I ended up making a DLL that put a façade around the various functions of interest (there were only a few) to make the call and then check for error data as one atomic operation. Then Dolphin could changes threads on me at will, and all was fine. That hack might not be necessary in the current and future versions of Dolphin. I should raise one flag about the email you forwarded: I smell a troll. Actually, it might not be a troll so much as someone who has bought into the idea that external components are a panacea. In my experience, there are some external libraries that are extremely helpful, but most are simply trash. The more "cool" the interface technology, the worse the software. Many C-callable libraries seem to do what the advertise; most are incomplete junk. I am sad to report that the vast majority of COM components are buggy non-sense with all manner of undocumented dependencies between the various methods. I will also freely admit that Dolphin's ability to dip into that pool of slime has saved my skin several times. At a minimum, I think we should provide an answer to Dolphin's overlapped calls. The rest can come as inspiration strikes regarding how to do things properly. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Wednesday, March 18, 2009 4:17 AM To: Pharo Development Subject: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? 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. 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
