Fwd: [vwnc] Would you start a new Smalltalk project today?

> From: Antony Blakey <[hidden email]>
> Date: March 18, 2009 2:50:47 AM CEST
> To: [hidden email], VWNC NC <[hidden email]>
> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

> Stef
>
> Begin forwarded message:
>
>> From: Antony Blakey <[hidden email]>
>> Date: March 18, 2009 2:50:47 AM CEST
>> To: [hidden email], VWNC NC <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> From: Antony Blakey <[hidden email]>
> Date: March 18, 2009 2:50:47 AM CEST
> To: [hidden email], VWNC NC <[hidden email]>
> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

>  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.

>
> On 18/03/2009, at 10:46 PM, Igor Stasenko wrote:
>
>> 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.
>
> The Erlang/Scala/Clojure concurrency models are applicable to a green
> threads model. Concurrency is difficult even with green threads.
>

>> Running single object memory on multiple native threads opens a can of
>> worms. And the complexity of VM implementation will be overwhelming.
>
> Not neccessarily. There may well be legacy issues related to specific
> VMs and images, but the problem itself is not overwhelming. If it were
> you wouldn't have the JVM or CLR.
>
> This argument is exactly what I meant when I wrote:
>
>> 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.
>
> I would prefer to tackle this problem and do something worthy of
> Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the
> multi-image model is actually a good and principled decision - but
> it's not, it's surrender.
>

> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> In anything at all, perfection is finally attained not when there is
> no longer anything to add, but when there is no longer anything to
> take away.
>   -- Antoine de Saint-Exupery
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> On 20/03/2009, at 1:30 PM, Michael van der Gulik wrote:
>
>> So now it seems that Gemstone is the only multi-core capable
>> Smalltalk VM :-(.
>
> And maybe this: http://etoileos.com/ ?
>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> Plurality is not to be assumed without necessity
>   -- William of Ockham (ca. 1285-1349)
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> indeed may be we should not have lost our time with squeak and
> participate to invent
> really a new smalltalk :)
>
> Stef
>
> On Mar 20, 2009, at 4:09 AM, Antony Blakey wrote:
>
>>
>> On 20/03/2009, at 1:30 PM, Michael van der Gulik wrote:
>>
>>> So now it seems that Gemstone is the only multi-core capable
>>> Smalltalk VM :-(.
>>
>> And maybe this: http://etoileos.com/ ?
>>
>> Antony Blakey
>> --------------------------
>> CTO, Linkuistics Pty Ltd
>> Ph: 0438 840 787
>>
>> Plurality is not to be assumed without necessity
>>  -- William of Ockham (ca. 1285-1349)
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
>
> On Thu, Mar 19, 2009 at 10:02 AM, Michael van der Gulik
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     If you want to use multiple CPU cores, I believe that ST/X and
>     Gemstone both do this. I haven't tried though.
>
>     Smalltalk/X: http://www.exept.de/
>     Gemstone: http://seaside.gemstone.com/
>
>
> I'm sorry, I lied.
>
> Smalltalk/X can /not/ use multiple cores. I tried it on a dual-core
> system; only one core was used :-(.
>
> So now it seems that Gemstone is the only multi-core capable Smalltalk
> VM :-(.

>
>
> On Sat, Mar 21, 2009 at 8:38 AM, Janko Mivšek <[hidden email]>
> wrote:
>>
>> Philippe Marschall pravi:
>> >> Michael van der Gulik wrote:
>>
>> >> So now it seems that Gemstone is the only multi-core capable Smalltalk
>> >> VM :-(.
>>
>> > AFAIK Gemstone isn't multi-core capable as well. You can just run
>> > multiple gems and they share the same persistent memory. Which is
>> > similar but different.
>>
>> Well, Gemstone can for sure be considered as multi-core capable. Every
>> gem runs on its own process and therefore can run on its own CPU core.
>> All gems then share a Shared Memory Cache. So, a typical multi-core
>> scenario.
>>
> By multi-core, I mean that the following code would spread CPU usage over at
> least two cores of a CPU or computer for a while:
>
> | sum1 sum2 |
>
> sum1 := 0. sum2 := 0.
>
> [ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork.
>
> [ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork.
>
> (I didn't try the above so there might be obvious bugs)
>
> If a VM can't distribute the load for the above over two or more CPU cores,
> I consider its multi-core capabilities a hack. No offense intended to the
> Hydra VM.
>

> I'm feeling a bit disheartened by the fact that there aren't any Smalltalk
> VMs, commercial or not, that can do fine-grained parallelism.
>
> Gulik.
>
> --
> http://gulik.pbwiki.com/
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/3/22 Michael van der Gulik <[hidden email]>:
>>
>>
>> On Sat, Mar 21, 2009 at 8:38 AM, Janko Mivšek <[hidden email]>
>> wrote:
>>>
>>> Philippe Marschall pravi:
>>> >> Michael van der Gulik wrote:
>>>
>>> >> So now it seems that Gemstone is the only multi-core capable Smalltalk
>>> >> VM :-(.
>>>
>>> > AFAIK Gemstone isn't multi-core capable as well. You can just run
>>> > multiple gems and they share the same persistent memory. Which is
>>> > similar but different.
>>>
>>> Well, Gemstone can for sure be considered as multi-core capable. Every
>>> gem runs on its own process and therefore can run on its own CPU core.
>>> All gems then share a Shared Memory Cache. So, a typical multi-core
>>> scenario.
>>>
>> By multi-core, I mean that the following code would spread CPU usage over at
>> least two cores of a CPU or computer for a while:
>>
>> | sum1 sum2 |
>>
>> sum1 := 0. sum2 := 0.
>>
>> [ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork.
>>
>> [ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork.
>>
>> (I didn't try the above so there might be obvious bugs)
>>
>> If a VM can't distribute the load for the above over two or more CPU cores,
>> I consider its multi-core capabilities a hack. No offense intended to the
>> Hydra VM.
>>
>
> Michael, that's would be too ideal to be true, especially for smalltalk.
>
> Consider the following:
>
> | array sum1 sum2 |
>
> sum1 := 0. sum2 := 0.
> array := Array new: 10.
>
> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork.
> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork.
> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
>
> This code reveals the following problems:
> - concurrent access to same object
> - a heavy memory allocation during running 3 processes, which at some
> point should cause GC.
> While first is more or less on the hands of developer (write a proper
> code to avoid such things), but second is a problem that you need to
> solve to be able to collect garbage in real time , when there are
> multiple threads producing it.
>
> Another problem, which will force you to rewrite many things in
> smalltalk code base, is problems with concurrent access to complex
> collections such as ordered collections, streams & dictionaries:
> | dict |
> dict := Dictionary new.
> [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork.
> [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork.
>
> at some point dictionary would require rehashing, but there are
> another thread which constantly putting new values in it. Obviously,
> access to dictionary should be synchronized to avoid conflicts.
> And synchronized access to collection(s) ( semaphore critical: [] )
> makes them really slow, which scales very poorly on multiple cores.
> The code above will take more time to complete comparing to same code
> when running in single native thread (green threading model), because
> you don't have to deal with synchronization.
>

>
>> I'm feeling a bit disheartened by the fact that there aren't any Smalltalk
>> VMs, commercial or not, that can do fine-grained parallelism.
>>
>> Gulik.
>>
>> --
>> http://gulik.pbwiki.com/
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>