[vox] Who thinks Java is cool?

[Alex Mandel]

On 06/15/2011 11:41 PM, Norm Matloff wrote:
> 
> On Wed, Jun 15, 2011 at 08:49:37PM -0700, Bill Broadley wrote:
> 
>> Been busy, but I couldn't represent throwing out a few (er, well it
>> started that way) thoughts.
> 
> Thanks for the essay, very interesting.
> 
>> Python has very nice combination of easy to use, powerful, yet
>> structured enough so non-trivial sized programs don't turn into a mess.
>> I'm not a big fan of the lack of types, but that's not a major issue
>> for me.  I like how the language is growing, still well designed, and
>> willing to depreciate the old approach and keeping thing coherent and
>> well designed.  While the GIL is gross, python seems relatively unique
>> in providing multiprocess safe pipes and queues as part of the language
>> standard.  Suddenly having 1-N producers and 1-M consumers safely
>> communicating to keep that fancy multicore phone/tablet/laptop/server is
>> rather straight forward.
> 
> Python is my favorite language for general-purpose programming (R for
> data/statistical stuff), but the GIL continues to be a major issue.
> They did add the "multiprocessing" package which helps a bit, but only a
> bit.
> 
>> Oh, for anyone interested in learning python google has a cool 2 day
>> class that has 7 lectures, laps, and is rather well done.  You'll
>> definitely have a good grasp of the basics by the end if you have any
>> familiarity with any programming language.  Hopefully folks can figure
>> out how to find said online class.
> 
> Or see my own Python tutorial :-) .  It's at
> 
>    http://heather.cs.ucdavis.edu/~matloff/python.html 
>  
> The first unit is on the general language, then there are units on
> networks, threading and so on.
> 
>> I've recently been tinkering with Go.  It's strongly typed (which I
>> like), has a nice clear syntax, and is available compiled or
>> interpreted.  It seems to be the most multi-processing friendly language
>> I've tried.  I wrote a multithreaded mandlebrot solver that was the
>> fastest go implementation for the debian alioth benchmark last I
>> checked.  It was shockingly easy (a single sitting) to write a producer
>> of chunks, asynchronously talk to N clients that got variable sized
>> chunks of work and talk to a single consumer to take the out of order
>> chunks of finished work and write them in order to a file.
>> Disappointingly my first implementation while elegant, was a bit
>> overkill for the example program provided with not much I/O and a fair
>> bit of work per pixel.  No points for more efficient I/O, higher
>> parallelism, or less sensitivity to highly variable CPU per chunk.
>  
>> I kind of think of Go as a second generation C designed to be more OO
>> and multicore friendly.  I particular I'm really fond of channels.
> 
> Unfortunately, I have the opposite point of view.  Thanks for pointing
> us to Go (I'd been vaguely aware of it), but the use of channels would
> be a big negative for me.  It's generally believed in the parallel
> processing community that the shared-memory paradigm makes for clearer
> code than does message-passing, and I personally agree.
> 
> It's too bad, because I really like coroutines, which I see Go includes
> and indeed highlights.  (Python can set them up too, using generators.)
> But lack of shared-memory would be a big drawback for me.
> 
> Or have a misread the Go Web page?
> 
> What is your opinion of the Cilk language?
> 
> By the way, thanks to Alex for the info on Sun/Oracle.  Again, this is
> something I had only been vaguely aware of.
> 
> Norm
> 

I'm curious to hear yours and Bill's take on Celery:
http://celeryproject.org/

I did talk to several people at a recent conference who were doing
multi-processing in python and seemed happy with it, but they were
Geographers not Computer Science and in Geography python is the language
to go with these days for interoperability and libraries.

Thanks,
Alex