[vox] Who thinks Java is cool?

[Norm Matloff]

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