Lambda the Ultimate

In light of yesterday's big news from Apple, I am left wondering what will become of the many fine language implementations that we have seen emerging under OS X?

Will the transition present problems for PLT Scheme, Haskell, Frontier, J, Croquet, FScript, etc....?

Will the various vm engines and self-hosted native code generation capabilities survive with a few minor tweaks and a simple recompile or are they predicated on the PowerPC architecture itself forcing language designers back to the blackboard?

Finally, from a purely technical perspective vis-a-vis the chip sets in question, was this move a stroke of genious, a case of 'worse is better', a bad idea, or an overall wash?

The Lambda calculus is a logical language and so are derivations such as lisp, scheme, and other functional languages. As such they theoretically could be used to prove facts as in languages like Prolog but I have never seen this done.

Moreover there is an intuitionistic logic (could this also be the more classic synthetic logic??) which could be quite useful for dealing with "real" dynamic, or uncertain environments. Something that could be very useful. Yet I am not awair of any practical tools for this.

Might not the logical interpretation of a function be more clear if the functions were written as rules, and had only a works/doesn't work return value?

Just wondering
Hank

I was wondering if there is any interest in a ranking of open source developers.

Such a ranking might be automatically determined by seeing how successful their applications have been (e.g., # downloads). We could also take into account other factors such as the size and complexity of the application.

Of course, if an application is built by many developers, we have to address the credit assignment problem. Namely, who is primarily responsible for the success of the application? We might examine the CVS repository to see who wrote what.

In any case, once we have this ranking of open source developers, we could then consider various applications:

* code search that returns code fragments written by particularly good developers (e.g., I might search for "drag and drop" across KDE apps and the most highly ranked drag & drop code fragments returned by the search would come from expert developers)

* mailing list search that takes into account how good of a developer the poster is (e.g., I might search for a problem related to drag and drop and the most highly ranked drag & drop messages returned by the search would come from expert developers)

Do you think building a ranking of open source developers would be worthwhile?

Do you think the applications mentioned would be compelling?

Evolving the Java Platform by Graham Hamilton:

Probably the most significant single feature in Mustang (J2SE 6.0) is the addition of a full-scale scripting engine, including a lightweight JavaScript implementation. We think the Java language is great, but we also think that scripting languages are a valuable adjunct to the core language.

The following quote captured my attention:

Thus, no single option is always best or even attainable. Moreover, each can pose problems. For example, pull protocols cannot deal with unexpected or prioritized events. Push protocols cannot always be buffered effectively, and require the existence or development of scheduling policies and algorithms. Shared memory requires the overhead of synchronization to avoid storage inconsistencies.

What is TXL ?
TXL is a unique programming language specifically designed to support computer software analysis and source transformation tasks. It is the evolving result of more than fifteen years of concentrated research on rule-based structural transformation as a paradigm for the rapid solution of complex computing problems.

http://www.txl.ca/

What is ETXL ?
ETXL is the prototype implementation of the ideas developed in Adrian Thurston's Master's Thesis. He set out to update the TXL Programming Language. The prototype is itself a TXL program that transforms ETXL to pure TXL then runs the TXL engine on the result.

http://www.cs.queensu.ca/home/thurston/etxl/

For a general view of TXL
http://www.cs.queensu.ca/~cordy/Papers/Cordy_TXL_LDTA04.pdf

Adrian Thurston's Master's Thesis
http://www.cs.queensu.ca/home/thurston/evotxl-final.pdf

In a few words, it simply rocks !

My lurking here at LtU has motivated me to learn about type theory, so I picked up a cheap used copy of Hindley's _Basic Simple Type Theory_, and have found myself woefully unprepared for it. A lunchtime sojourn to wikipedia yesterday was my first introduction to S & K combinators, so needless to say, all the formal logic, proofs, etc., are right over my head.

Is there a more basic, simpler introduction to type theory that doesn't assume a competant formal background that y'all can recommend, or, failing that, can y'all recommend a list of preparatory works to read first?

thanks in advance,

JimDesu

[quote]
6 Conclusion

There have been positive and negative aspects to both
our sets of experiences with Haskell and ML, as there
would doubtless have been with whatever language we
had chosen. Overall, we consider Standard ML to be a
slightly better choice for our kind of application than
Haskell, more because of a more stable environment
of supporting tools than because of language features.
Of course, there are many alternatives including other
functional languages of which we have less experience;
O'Caml might be a strong candidate. However, it turned
out in our discussions that none of us were enthusiastic
about the idea of using a functional language for a fu-
ture verification tool, because of their impoverished envi-
ronments compared with mainstream programming lan-
guages. Our conclusion is that if/when we develop new
verification tools, these will be written in \a Java-ready
subset of C++". That is, we would prefer to be writ-
ing in Java, but at present this appears premature for
performance reasons. We would write therefore in C++,
trying to avoid using features (such as multiple inheri-
tance, non-virtual functions, \friends") which cannot be
readily translated into Java.
[/quote]

Also interesting and very true observation from the same article:

[quote]
Why is there so little material to help developers
make an informed choice? Part of the reason must be
that it is very hard to do convincing comparisons of lan-
guages without being vulnerable to the criticism that
one is not comparing like with like. We think that a fair
comparison needs to be based on real experience of peo-
ple using the languages to build real systems in the same
domain; otherwise it is almost impossible to be sure that
diferences are not due to diferences in the domains of
application. The systems themselves need to be broadly
comparable in size and complexity, need to be more than
toys, and should preferably have been developed and
maintained over years (since a language that makes de-
velopment easy might nevertheless encourage the devel-
opment of code which is unmaintainable). Moreover, the
domain should be one where either of the languages is
a reasonable choice, and the comparison should be done
by people with a reasonably typical level of experience in
the languages. A comparison is probably most generally
useful to developers when it is done neither by novices
in the languages compared nor by people intimately fa-
miliar with the compiler internals.
[/quote]