Re: [Algorithms] Complexity of new hardware

[Sam M. <sam...@ge...>]

> Wouldn't that be a tough sell? You'd already be competing with free 
> implementations of LUA, Python, JavaScript and their ilk on the low
end, 
> and built-in languages like UnrealScript on the high end. 

I don't think there's a market for that kind of scripting DSL. A new
language would need to eat into the remaining C++ development burden
that isn't suitable to implementing in Lua, say. Which is plenty.

> Doesn't this bring us back full circle? I recall a statement from a 
> month ago saying that we all need to think differently about how we
put 
> together massively parallel software, because the current tools don't 
> really help us in the right ways... 

Another reason to consider pure functional languages. This is a much
deeper topic that I'm now about to trivialise, but the referential
transparency of these languages makes them particular suitable to
parallel evaluation. For example, GHC (arguably the most mature Haskell
compiler) can compile for an arbitrary number of cores, although it's
still an active research area as I understand it.

Thanks,
Sam

------------------------------------------------------------------------
------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t