[Swift-devel] Scala

[Michael Wilde]

Here's my thinking. When I said "2 paths", I meant one path that we are 
executing and another path that we are thinking about. It still does 
seem reasonable to think once in a while :)

But we should stay focused on the first path - and I believe we are.

We should keep discussing the second path, as a side-conversation geared 
to  future work and future funding, which this discussion is.
Once we have some ideas for a library more distilled, we should carve 
out a small finite time to try it and see how it feels.

If it looks like the library (from gedanken experiments) would be 
pleasing to code in, we should see if we can find a cheap way to 
prototype it and see if its feasible. That could lead to a paper and 
then a proposal (and then funding).

But the main point of my posting below is this: as you and Ben point 
out, most other parallel languages are geared toward parallel threads of 
control for tasks that are geared mostly to in-memory operations. The 
Swift execution model is geared to parallel execution of external 
applications and and data movement. That's unlikely to be found in any 
other language, and hence argues for either a language focused on that 
model (e.g., Swift) or a library that can implement that model, where 
the host language is used as "glue" between operations of the model.

My main point is that if we want a good host language, lets focus on 
popular languages rather than esoteric ones.

- Mike



On 10/25/09 11:56 AM, Mihael Hategan wrote:
> Do we have funding for this or is this going to be yet another way to
> ensure that what we started with isn't going to get done?
> 
> On Sun, 2009-10-25 at 11:00 -0500, Michael Wilde wrote:
>> I believe rather than examining more exotic languages (which themselves 
>> are likely struggling to gain a toehold) we should stick to and rally 
>> behind the earlier idea of expressing "swift" semantics as a library, 
>> which can be used from the already popular languages: Python, Java 
>> (+Groovy et al), Perl, Ruby - in roughly that order. Probably C/C++ as well.
>>
>> We should continue, I feel, to pursue two paths:
>>
>> - improve Swift itself, especially in documentation and support tools, 
>> because it works and is gaining in usage, from which we can gain a lot 
>> of experience. Swift's slow pace adoption step more from 
>> documentation/tutorial shortcomings, rough edges in environment support 
>> and debugging, and lack of people to do these things, than from an 
>> intrinsic lack of market attractiveness. Swift is a thin language by 
>> design, which should enhance its attractiveness.
>>
>> - try some simple experiments with a Swift library for Python, to see 
>> how it feels to program in, and how much of our current runtime 
>> infrastructure we can reuse.
>>
>> 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.
>>
>> A Swift function library could have these elements:
>>
>> - declare data types
>> - declare data(set) instances
>> - define app wrappers
>> - define blocks (dataflow dags)
>> - define foreach-iterators
>> - launch a script
>> - monitor script progress and extract results
>>
>> It should be possible using these primitives to both run the semantics 
>> of most or all current swift programs, and likely to re-use, at least 
>> initially, large portions of the Swift runtime system.
>>
>> For example, if we were to do an experiment in Jython, we could embed 
>> much of swift and the karajan engine into a single process with the 
>> Python language iterpreter.
>>
>> We could also implement the Swift engine as a companion process with a 
>> socket interface to accept and process definitions and script execution 
>> requests, and this engine could both continue to serve the current Swift 
>> execution base and as a the engine for other language bindings.
>>
>> - Mike
>>
>>
>>
>> On 10/24/09 9:07 PM, Mihael Hategan wrote:
>>> On Sat, 2009-10-24 at 19:51 -0500, Ian Foster wrote:
>>>> Hi Ben:
>>>>
>>>> I gather you are in Australia at present? Say hello from me.
>>>>
>>>> I think that the key feature of Swift (apart from functional semantics  
>>>> and XDTM-like mechanisms) is its use of single assignment variables  
>>>> for synchronization.
>>>>
>>>> I'm not sure that one has to have everything-parallel semantics to do  
>>>> what we want. One could also have explicitly parallel operators, like  
>>>> "forall" and "par" used in CC++.
>>> We could have forall and par in Java, as libraries. Which is something I
>>> would personally like to see regardless of what Swift does. I'm not sure
>>> why Scala would be better (other than being a more interesting but more
>>> obscure language - which is a milder version of the Swift - Java
>>> conflict).
>>>
>>>> I remain interested in the question of whether we can reduce barriers  
>>>> to use of Swift, and its long-term maintenance costs, by adopting some  
>>>> existing technology to build on. Scala is one of several potential  
>>>> candidates.
>>> My opinion on that is that what we're trying to address with Swift (as a
>>> language) is for us to deal with the nasty problems of concurrency so
>>> that our users don't have to (questions of whether we succeed at that
>>> notwithstanding).
>>>
>>> Choosing Scala or Java instead would mean that, while being able to work
>>> with a more stable and better known language (as well as some of us
>>> having an easier job), our users will have to take care of some of those
>>> harder problems.
>>>
>>> Taking the limit, the maintenance costs of doing nothing are pretty low.
>>>
>>>
>>> _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>