<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [Swift-devel] Scala</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Would you be interested in Rmpi, by any chance, please?<BR>
<BR>
I'm doing a little bit of work on that at the moment.<BR>
<BR>
Thanks,<BR>
Erin<BR>
<BR>
<BR>
Erin M. Hodgess, PhD<BR>
Associate Professor<BR>
Department of Computer and Mathematical Sciences<BR>
University of Houston - Downtown<BR>
mailto: hodgesse@uhd.edu<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: swift-devel-bounces@ci.uchicago.edu on behalf of Michael Wilde<BR>
Sent: Sun 10/25/2009 12:37 PM<BR>
To: Mihael Hategan<BR>
Cc: swift-devel; Ian Foster<BR>
Subject: Re: [Swift-devel] Scala<BR>
<BR>
You make some good points here Mihael. Im going to drop off this thread<BR>
while I mull it over further. There is some user demand from the<BR>
R/OpenMx community to also pursue an host-language embedding of Swift<BR>
semantics. That might be a good place to explore this (which *does* have<BR>
funding). R has the library packages "Snow" and "Snowfall" which do<BR>
something similar and have proven useful and popular - perhaps a good<BR>
model to examine and perhaps integrate Swift into.<BR>
<BR>
- Mike<BR>
<BR>
<BR>
On 10/25/09 12:31 PM, Mihael Hategan wrote:<BR>
> On Sun, 2009-10-25 at 11:00 -0500, Michael Wilde wrote:<BR>
><BR>
>> Swift-as-a-library seems to me to have potential similar to MPI to<BR>
>> achieve great success - wider that Swift-as-a-language - while not<BR>
>> eliminating the benefits and continued support and improvement of the<BR>
>> current system.<BR>
><BR>
> Btw, I have reasons to believe this is not true. CoG+Java (and then the<BR>
> python cog + python) already provide the tools necessary to achieve most<BR>
> of this. A parallel parameter sweep would look like this (boilerplate<BR>
> removed):<BR>
><BR>
> Task[] tasks = new Task[params.length];<BR>
> for(int i = 0; i < params.length; i++) {<BR>
> tasks[i] = buildAndSubmitTask(params[i]);<BR>
> }<BR>
> for(int i = 0; i < tasks.length; i++) {<BR>
> tasks[i].waitFor();<BR>
> }<BR>
><BR>
> There is also a scheduler to take care of scheduling, with an API and<BR>
> many other things. All documented, with examples, a hefty FAQ, papers,<BR>
> posters, etc.<BR>
><BR>
> Didn't work. I suspect because complexity is not in how hard it is to do<BR>
> something, but how hard it is to distinguish the right solution from the<BR>
> sea of potential solutions. In which case a "canned" solution works<BR>
> better.<BR>
><BR>
> And frankly I wouldn't use it either. If something goes wrong from a<BR>
> programming standpoint, throubleshooting each "workflow" is a pain,<BR>
> because there is no clear separation between the domain specific problem<BR>
> and the library. In debugging, I wouldn't be able to separate the two.<BR>
> Whereas in Swift as it is, it's much easier to distinguish between a<BR>
> runtime-swift bug and having written your script wrong. The library is a<BR>
> carrot in a soup. Swift is layered.<BR>
><BR>
_______________________________________________<BR>
Swift-devel mailing list<BR>
Swift-devel@ci.uchicago.edu<BR>
<A HREF="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>