[Swift-devel] Scala

[Hodgess, Erin]

Would you be interested in Rmpi, by any chance, please?

I'm doing a little bit of work on that at the moment.

Thanks,
Erin


Erin M. Hodgess, PhD
Associate Professor
Department of Computer and Mathematical Sciences
University of Houston - Downtown
mailto: hodgesse at uhd.edu



-----Original Message-----
From: swift-devel-bounces at ci.uchicago.edu on behalf of Michael Wilde
Sent: Sun 10/25/2009 12:37 PM
To: Mihael Hategan
Cc: swift-devel; Ian Foster
Subject: Re: [Swift-devel] Scala
 
You make some good points here Mihael. Im going to drop off this thread 
while I mull it over further. There is some user demand from the 
R/OpenMx community to also pursue an host-language embedding of Swift 
semantics. That might be a good place to explore this (which *does* have 
funding). R has the library packages "Snow" and "Snowfall" which do 
something similar and have proven useful and popular - perhaps a good 
model to examine and perhaps integrate Swift into.

- Mike


On 10/25/09 12:31 PM, Mihael Hategan wrote:
> On Sun, 2009-10-25 at 11:00 -0500, Michael Wilde wrote:
> 
>> Swift-as-a-library seems to me to have potential similar to MPI to 
>> achieve great success - wider that Swift-as-a-language - while not 
>> eliminating the benefits and continued support and improvement of the 
>> current system.
> 
> Btw, I have reasons to believe this is not true. CoG+Java (and then the
> python cog + python) already provide the tools necessary to achieve most
> of this. A parallel parameter sweep would look like this (boilerplate
> removed):
> 
> Task[] tasks = new Task[params.length];
> for(int i = 0; i < params.length; i++) {
>   tasks[i] = buildAndSubmitTask(params[i]);
> }
> for(int i = 0; i < tasks.length; i++) {
>   tasks[i].waitFor();
> }
> 
> There is also a scheduler to take care of scheduling, with an API and
> many other things. All documented, with examples, a hefty FAQ, papers,
> posters, etc.
> 
> Didn't work. I suspect because complexity is not in how hard it is to do
> something, but how hard it is to distinguish the right solution from the
> sea of potential solutions. In which case a "canned" solution works
> better.
> 
> And frankly I wouldn't use it either. If something goes wrong from a
> programming standpoint, throubleshooting each "workflow" is a pain,
> because there is no clear separation between the domain specific problem
> and the library. In debugging, I wouldn't be able to separate the two.
> Whereas in Swift as it is, it's much easier to distinguish between a
> runtime-swift bug and having written your script wrong. The library is a
> carrot in a soup. Swift is layered.
> 
_______________________________________________
Swift-devel mailing list
Swift-devel at ci.uchicago.edu
http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20091025/5556c95e/attachment.html>