[Swift-devel] LQCD meeting at Fermi

[Yong Zhao]

They do mention in the discussion that the Swift approach is not much
different from their ad hoc scripts (just because the way we deal with
file names and command line arguments in invoking applications). They said
they wanted something purer ( in the sense of having just procedure
interfaces & data flows, and hiding invocation/mapping/wrapping details).
But I guess neither side (us and them) has a clear idea about how to
actually achieve that.

They also notice the mixed flavor of scripting, imperative programming and
functional programming in the language, they seem to favor the python
style, more functional style of programming language. Also they do not
quite like the @ functions.

I think due to the slow process and also they have been trying to figure
out the language features by themselves, they are a bit discouraged and
disappointed at this point. So we need to get their semi-working scripts
working very quickly in order not to alienate them.

Yong.

On Fri, 1 Jun 2007, [UTF-8] Ian Foster wrote:

> Ben:
>
> The question for me is whether they are invested, or just playing with it and finding things that are "wrong" not because they are serious problems but rather as excuses for them not to do more. (I've often experienced that.)
>
> So I want to know if they are using it for real work or not. So far things don't look so good--as I understand things, they don't have a working program after what mus be 4-5 months talking to us (?).
>
> Ian
>
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: Ben Clifford <benc at hawaga.org.uk>
> Date: Fri, 1 Jun 2007 22:38:42
> To:Ian Foster <foster at mcs.anl.gov>
> Cc:Veronika Nefedova <nefedova at mcs.anl.gov>, swift-devel at ci.uchicago.edu
> Subject: Re: [Swift-devel] LQCD meeting at Fermi
>
>
>
> On Fri, 1 Jun 2007, Ian Foster wrote:
>
> > Thanks for the summary. I am very eager to see some results for executions of
> > real application problems. Did they agree to a timeline for that?
>
> Would also be good to have some definition of what is an acceptable 'real
> application problem', in terms of which programs are to be run on which
> datasets on what sized resource.
>
> --
>
>