23.2.05
17.2.05
More Links comments
More comments, from Tony Hoare and Joachim Durchholz.
--------
From Tony Hoare
Dear Phil,
Thanks for the note. I'm afraid I can't get to Edinburgh on April 6th.
But I hope your discussions go well.
I would recommend that you concentrate initially on a clear definition
of the purely scientific, possibly long-term, challenges of expressing
web applications in a transparent functional style. As a result, even
if you never get as popular in the short term as python (let alone
Visual Basic, with its four million programmers), your project will
represent a significant step forward in our understanding of the
principles of programming and programming language design.
Your long list of existing languages is essential as a summary of
sources of experimental data for evaluating and evolving any emerging
language and implementation by application to realistic examples; I
think this is your intention. Otherwise your project may just
degenerate into an attempt to throw everything into one unholy stew.
Leave that kind of cookery to the standardisation bodies who made the
mess: the scientific method has no particular contribution to make to
clearing it up.
My last two paragraphs have described two extremes. Most people engaged
in your project will take a position somewhere between them. Perhaps
no-one would or should embrace solely the scientific ideals. A most
fruitful outcome of your meeting would be to define a framework within
which scientists can collaborate in working towards a long-term goal,
while competing in achievement of shorter term milestones.
Now let me add my own bit of gristle to the stew. A modern language for
Web Services should surely incorporate the concept of a long-running
transaction, as in languages such as BPEL or Microsoft's XLANG.
Please circulate this note if you think it will contribute.
Yours,
Tony.
--------
From Joachim Durchholz
Dear all,
as the response to the above message in the comp.lang.functional newsgroup has shown, there's an immense interest in this project.
The announcement also sparked a rather extensive discussion on the features that such a language should (or should not) have. However, the discussion suffered from the typical newsgroup syndrome: no consensus, threads dropping off into silence, etc.
Since I know that WikiWiki webs have a better track record in this regard, I have set up one at
http://durchholz.org/jo/links/wiki/pmwiki.php
(For those who don't know what a WikiWiki web is: it's a web site where anybody can edit the pages. Since the pages are versioned, it's easy to revert accidentally or maliciously defaced pages to the last known good state.)
I have already added some of my personal pet peeves, but I sincerely hope that others will contribute as well, with additional proposals or critiques.
Enjoy!
Jo
--------
--------
From Tony Hoare
Dear Phil,
Thanks for the note. I'm afraid I can't get to Edinburgh on April 6th.
But I hope your discussions go well.
I would recommend that you concentrate initially on a clear definition
of the purely scientific, possibly long-term, challenges of expressing
web applications in a transparent functional style. As a result, even
if you never get as popular in the short term as python (let alone
Visual Basic, with its four million programmers), your project will
represent a significant step forward in our understanding of the
principles of programming and programming language design.
Your long list of existing languages is essential as a summary of
sources of experimental data for evaluating and evolving any emerging
language and implementation by application to realistic examples; I
think this is your intention. Otherwise your project may just
degenerate into an attempt to throw everything into one unholy stew.
Leave that kind of cookery to the standardisation bodies who made the
mess: the scientific method has no particular contribution to make to
clearing it up.
My last two paragraphs have described two extremes. Most people engaged
in your project will take a position somewhere between them. Perhaps
no-one would or should embrace solely the scientific ideals. A most
fruitful outcome of your meeting would be to define a framework within
which scientists can collaborate in working towards a long-term goal,
while competing in achievement of shorter term milestones.
Now let me add my own bit of gristle to the stew. A modern language for
Web Services should surely incorporate the concept of a long-running
transaction, as in languages such as BPEL or Microsoft's XLANG.
Please circulate this note if you think it will contribute.
Yours,
Tony.
--------
From Joachim Durchholz
Dear all,
as the response to the above message in the comp.lang.functional newsgroup has shown, there's an immense interest in this project.
The announcement also sparked a rather extensive discussion on the features that such a language should (or should not) have. However, the discussion suffered from the typical newsgroup syndrome: no consensus, threads dropping off into silence, etc.
Since I know that WikiWiki webs have a better track record in this regard, I have set up one at
http://durchholz.org/jo/links/wiki/pmwiki.php
(For those who don't know what a WikiWiki web is: it's a web site where anybody can edit the pages. Since the pages are versioned, it's easy to revert accidentally or maliciously defaced pages to the last known good state.)
I have already added some of my personal pet peeves, but I sincerely hope that others will contribute as well, with additional proposals or critiques.
Enjoy!
Jo
--------
14.2.05
Links comments
I received useful comments on Links from Garry Hodgson, Amanda Clare, and Rodrigo Barnes. (Posted with permission.)
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
1.2.05
Links meeting at ETAPS
Taking advantage of the fact that the world will be visiting my
doorstep, with the help of some colleagues I am organizing a
meeting on Links for 6 April 2005, to overlap with ETAPS.
The meeting is by invitation only --- please
let me know if you would like to be invited!
Dear Colleagues,
If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications.
* Databases. Kleisli and Mnesia (not to mention SQL and
XQuery) have demonstrated the value of functional languages as query
languages.
* XML. Xduce, Cduce, Bigwig (not to mention XSLT and XQuery)
have demonstrated the value of functional languages for manipulating
XML.
* Continuations. PLT Scheme and WASH have demonstrated the value of
functional languages for structuring CGI interfaces.
* Distribution. Erlang and JoCaml have demonstrated the value of
functional languages for distribution and mobility.
The technique of building a coalition to design, implement, and
promote a general-purpose programming language has proven
spectacularly successful for ML and Haskell. Can we apply this
technique again, this time aimed at an application domain?
ETAPS will attract a large number of researchers to Edinburgh, and
seems an appropriate point for launching this project. We propose
to meet on *** Wednesday 6 April 2005 in Edinburgh ***. We hope you
can come.
The working name for this project is Links. A quarter of a century
ago, Burstall, MacQueen, and Sannella introduced Hope, the source of
the algebraic types of ML and Haskell. Hope was named after Hope Park
Square, located near Edinburgh University on the Meadows. Links is
named after the Bruntsfield Links, located at the other end of the the
Meadows and site of the first public golf course.
Points to be discussed at the Links meeting include:
* Presentations on work to date -- we hope you will contribute to this.
* Types. The type system of Haskell and the module system of ML
are both extremely powerful, but quite different. Regular expression
types for XML are also powerful, but it is unclear how to combine
these with polymorphism or higher-order functions. Further, to be
successful, any new language must play well with SOAP, Java, and C#,
at a minimum; how do we integrate OO and FP types?
* Effects. It is proposed that the language be strict, with an effect
type system (combining the advantages of Haskell monads with ML effects).
What variety of effects should be supported? Can we provide support for
laziness within this framework? (See Wadler and Thiemann for
relations between monads and effect type systems, see Wadler, Taha, and
MacQueen for a proposal to support laziness in a strict language.)
* Targets. Web applications are often structures as three tiers:
browser (running HTML, XML, Javascript, Flash, Java), server
(running Java, C#, Python, Perl), and database (running SQL or XQuery).
We hope to compile code to run in all three tiers from a single source.
How can a compiler framework support multiple targets of this kind?
(See Thiemann on generating multi-tier programs from a single source.)
* Organization. How to structure the work? Should we put in for
European and/or US grants?
Volunteers for presentations and suggestions as to topics and organization
would be most welcome.
We look forward to hearing from you!
Yours sincerely,
Xavier Leroy
Simon Peyton Jones
Benjamin Pierce
Philip Wadler
doorstep, with the help of some colleagues I am organizing a
meeting on Links for 6 April 2005, to overlap with ETAPS.
The meeting is by invitation only --- please
let me know if you would like to be invited!
Dear Colleagues,
If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications.
* Databases. Kleisli and Mnesia (not to mention SQL and
XQuery) have demonstrated the value of functional languages as query
languages.
* XML. Xduce, Cduce, Bigwig (not to mention XSLT and XQuery)
have demonstrated the value of functional languages for manipulating
XML.
* Continuations. PLT Scheme and WASH have demonstrated the value of
functional languages for structuring CGI interfaces.
* Distribution. Erlang and JoCaml have demonstrated the value of
functional languages for distribution and mobility.
The technique of building a coalition to design, implement, and
promote a general-purpose programming language has proven
spectacularly successful for ML and Haskell. Can we apply this
technique again, this time aimed at an application domain?
ETAPS will attract a large number of researchers to Edinburgh, and
seems an appropriate point for launching this project. We propose
to meet on *** Wednesday 6 April 2005 in Edinburgh ***. We hope you
can come.
The working name for this project is Links. A quarter of a century
ago, Burstall, MacQueen, and Sannella introduced Hope, the source of
the algebraic types of ML and Haskell. Hope was named after Hope Park
Square, located near Edinburgh University on the Meadows. Links is
named after the Bruntsfield Links, located at the other end of the the
Meadows and site of the first public golf course.
Points to be discussed at the Links meeting include:
* Presentations on work to date -- we hope you will contribute to this.
* Types. The type system of Haskell and the module system of ML
are both extremely powerful, but quite different. Regular expression
types for XML are also powerful, but it is unclear how to combine
these with polymorphism or higher-order functions. Further, to be
successful, any new language must play well with SOAP, Java, and C#,
at a minimum; how do we integrate OO and FP types?
* Effects. It is proposed that the language be strict, with an effect
type system (combining the advantages of Haskell monads with ML effects).
What variety of effects should be supported? Can we provide support for
laziness within this framework? (See Wadler and Thiemann for
relations between monads and effect type systems, see Wadler, Taha, and
MacQueen for a proposal to support laziness in a strict language.)
* Targets. Web applications are often structures as three tiers:
browser (running HTML, XML, Javascript, Flash, Java), server
(running Java, C#, Python, Perl), and database (running SQL or XQuery).
We hope to compile code to run in all three tiers from a single source.
How can a compiler framework support multiple targets of this kind?
(See Thiemann on generating multi-tier programs from a single source.)
* Organization. How to structure the work? Should we put in for
European and/or US grants?
Volunteers for presentations and suggestions as to topics and organization
would be most welcome.
We look forward to hearing from you!
Yours sincerely,
Xavier Leroy
Simon Peyton Jones
Benjamin Pierce
Philip Wadler
20.1.05
TIOBE Programming Community Index
The TIOBE Programming Community Index tracks popularity of programming languages. "The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings." Lisp, Scheme, and ML rate mentions. Erlang and Haskell are tracked, but no ratings are reported since they are not in the top 50.
7.1.05
ICDT
ICDT is in Edinburgh this year. Some highlights:
Moshe Vardi on model checking for database theorists. A lovely introduction.
Michael Schwartbach on type systems for XML. A perfect invited talk: a summary of the field as a whole, including the speaker's work but not focussed on it, with some hot-off-the-presses new research at the end (static typing for XSLT with DTDs as types). Beautifully illustrated with cows.
Wim Martens, Frank Neven and Thomas Schwentick on Which XML Schemas Admit 1-Pass Preorder Typing. Neat results, neatly presented. They have a very nice characterization of the "element declarations consistent" constraint in Schema.
David Maier on Streaming. One of the more interesting things I learned at ICDT is that Maier is responsible for introducing the term "impedance mismatch" to the database field, circa 1984. (It may have been introduced into computing more than once, as I believe I saw the same term used in a paper on AWK earlier than that.)
Victor Viana told me about his latest work. I went back to my office and downloaded his Specification and Verification of Data-driven Web Services from PODS 2004.
Moshe Vardi on model checking for database theorists. A lovely introduction.
Michael Schwartbach on type systems for XML. A perfect invited talk: a summary of the field as a whole, including the speaker's work but not focussed on it, with some hot-off-the-presses new research at the end (static typing for XSLT with DTDs as types). Beautifully illustrated with cows.
Wim Martens, Frank Neven and Thomas Schwentick on Which XML Schemas Admit 1-Pass Preorder Typing. Neat results, neatly presented. They have a very nice characterization of the "element declarations consistent" constraint in Schema.
David Maier on Streaming. One of the more interesting things I learned at ICDT is that Maier is responsible for introducing the term "impedance mismatch" to the database field, circa 1984. (It may have been introduced into computing more than once, as I believe I saw the same term used in a paper on AWK earlier than that.)
Victor Viana told me about his latest work. I went back to my office and downloaded his Specification and Verification of Data-driven Web Services from PODS 2004.
Links in Lambda the Ultimate
Ehud Lamm at Lambda the Ultimate was kind enough to post something about Links, and the comments have been positive so far. Thanks, guys!
(Tim Sweeney expressed a hope that the syntax would be more like C/Java/Python than like Haskell. That is the plan. Once the language is out, comments on all aspects, including the syntax, will be welcome.)
(Tim Sweeney expressed a hope that the syntax would be more like C/Java/Python than like Haskell. That is the plan. Once the language is out, comments on all aspects, including the syntax, will be welcome.)
5.1.05
FP goes mainstream
Jeremy Yallop has pointed me to an article describing continuations for web programming at the IBM DeveloperWorks website. Nice to see working programmers picking this up, as it is one of the key ingredients in Links.
8.12.04
Scottish Programming Language Seminar
Yesterday was the inaugural meeting of the Scottish Programming Language Seminar. Three cheers to Simon Gay at Glasgow for hosting! Scotland is home to some of the best programming language researchers in the world, and I am hoping big things will come from gathering together regularly. James Cheney at Edinburgh will host the next meeting, in a few months time. (Thank you, James!)
Quick reviews of the talks:
David Watt looked at the relationship between subtyping and mutability. His examples were simple and clear, making the presentation a pleasure to follow. But the talk was marred because he wasn't aware of "wildcard types" in Java 1.5 (one of the twists added since my own contribution to the design of generics for Java). At first I thought wildcards could do everything David wants to do, but he showed that Wildcards and his approach provide complementary capability. Apart from mutability, Watt has some interesting ideas about building a language which is suited both for scripting (as in Python) and for static compilation (as in Java). I've been thinking along similar lines, wondering whether one way to sell my new language Links is to claim that functional languages blur the line between scripting and programming.
Phil Trinder spoke on higher-level abstractions for communication. Some interesting ideas, but way too much crammed into the time available. He now needs to do a series of talks, expanding each segment of this one!
James McKinna on applying Epigram to compiling. He claims that dependent types offer a simpler approach to some aspects of proof carrying code -- interesting if true, but requires further demonstration! Regardless of that, Epigram is clearly interesting, an attempt to finally bring dependent types to the masses.
Paul Cockshot on supporting graphics primitives in Pascal. Entirely straightforward.
John Reynolds on grainless concurrency. His recent work, with O'Hearn and others, on Separation Logic is a huge advance in the way we reason about programs with state. Here John cuts a Gordian Knot in which the semantics community has been tangled for many years. Rather than try to work out all the possible ways in which things can go wrong when concurrent threads access the same variable without benefit of locking, he simply defines all such accesses as "wrong" -- the sort of idea that is obvious when you see it, but takes years to surface.
Quick reviews of the talks:
David Watt looked at the relationship between subtyping and mutability. His examples were simple and clear, making the presentation a pleasure to follow. But the talk was marred because he wasn't aware of "wildcard types" in Java 1.5 (one of the twists added since my own contribution to the design of generics for Java). At first I thought wildcards could do everything David wants to do, but he showed that Wildcards and his approach provide complementary capability. Apart from mutability, Watt has some interesting ideas about building a language which is suited both for scripting (as in Python) and for static compilation (as in Java). I've been thinking along similar lines, wondering whether one way to sell my new language Links is to claim that functional languages blur the line between scripting and programming.
Phil Trinder spoke on higher-level abstractions for communication. Some interesting ideas, but way too much crammed into the time available. He now needs to do a series of talks, expanding each segment of this one!
James McKinna on applying Epigram to compiling. He claims that dependent types offer a simpler approach to some aspects of proof carrying code -- interesting if true, but requires further demonstration! Regardless of that, Epigram is clearly interesting, an attempt to finally bring dependent types to the masses.
Paul Cockshot on supporting graphics primitives in Pascal. Entirely straightforward.
John Reynolds on grainless concurrency. His recent work, with O'Hearn and others, on Separation Logic is a huge advance in the way we reason about programs with state. Here John cuts a Gordian Knot in which the semantics community has been tangled for many years. Rather than try to work out all the possible ways in which things can go wrong when concurrent threads access the same variable without benefit of locking, he simply defines all such accesses as "wrong" -- the sort of idea that is obvious when you see it, but takes years to surface.
Subscribe to:
Posts (Atom)