[Swift-devel] Scala

[Allan Espinosa]

Also, popular scripting languages python (jython), ruby(jruby), perl(
jerl???) can import java classes in their equivalent java
implementations.  We can play around calling CoG+ java classes to make
the workflows :)

2009/10/25 Mihael Hategan <hategan at mcs.anl.gov>:
> 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.
>