Re: [vox] Who thinks Java is cool?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox] Who thinks Java is cool?
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
> 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
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.
vox mailing list