14.3.05
Tom Sgouros
My family (two five year olds, geek averse wife, and geeky I) all enjoyed Tom Sgouros's show, Judy -or- What is it like to be a robot? Old chestnuts about philosophy, strong AI, and the soul turned fresh and funny. The most enjoyable evening I've spent in the theatre in years (and Edinburgh has plenty of theatre).
Simon Patterson at the Fruitmarket
You'll have seen one artwork by Simon Patterson: "The Great Bear" is the London subway map with the names of stations replaced by philosophers, actors, explorers, Italian painters, and the like. All of his artwork involves similar transpositions from one form of representation to another -- perfect for computer scientists! I particularly enjoyed his short films High Noon (heavy-breathing timepieces) and Escape Routine (airplane instructions intersperesed with Houdini). He's on at the Fruitmarket in Edinburgh until 1 May.
10.3.05
POPL, Plan-X, FOOL
Here are notes on some of my favorite talks at POPL, Plan-X, and FOOL.
Plan-X, 11 Jan 2005.
Michael Carey, BEA, on BEA Liquid Data, an approach to data integration. He notes that BEA developers tend to ignore the strong typing features of XQuery, for two reasons, one trivial and one material. Trivial: developers find it inelegant to have to validate the data after it is created in order to attach type information to it. This is just a matter of writing "validate { ... }" around the XML that creates the data, but they strong resist this. Material: validation can change the data in various corner cases, and so interferes heavily with optimization. I took two points away from this. First, XQuery seems to have failed in the goal of integrating types with queries -- trying to fit well with Schema has inevitably thrown up a lot of road blocks. Second, sometimes seemingly trivial points can be just as significant as material ones; another example of this is how the C-like syntax of C++ and Java helped these languages to spread rapidly.
Alan Schmitt on Xtatic. The pattern matching style of Xduce/Xtatic does not do well with data evolution, unlike XPath, as adding more elements to the data causes matching to fail. I would have thought of this as a bad thing, but Schmitt claims it is good, as the failure tells you where you need to change your code.
The demo session worked well. I particularly liked Fisher and Fernandez's PADX, which I had not seen before.
POPL, 12-14 Jan 2005.
Rob Pike on a programming language for searching Google's data. His neatest example was an animated map, with one pinprick of light for each query sent to Google in one day, correctly located in space and time -- one could watch the pattern of queries flow across the world. The data for the map was generated by a program just a few tens of lines long. The key to the query language is, as Rob noted, a simple idea from the functional programming community: use map and fold as the basis of parallel programming, where the fold is over over associative and commutative operators. Pike's language is based on Google's map-reduce system. (Added 27 Aug 2007: Pike's language is called Sawzall. Later a paper on it appeared here.)
Peter Selinger on a quantum programming language. A lovely presentation of tricky ideas, the first time I had made it through to the end. I finally understood that quantum programming involves two levels of probability, within a state there is the probability attached to each qbit, and then there is the probability of being in a particular entangled state. Selinger explained a clever matrix representation due to von Neuman that captures both levels. He gave a nice explanation of quantum teleportation/quantum compression as two halves of a "use once" isomorphism -- a pair of inverse functions that contain a free linear variable so each can be used only once, where the order of composition determines whether one has teleportation or compression. When I asked him why one should bother with programming languages for computers that might never be built, he pointed to the ability of the language to give precise descriptions of tricky thought experiments, as in the teleportation/compression example.
Pat Hanrahan argued that game processors pose a worthy challenge for language designers. He observes that game processors have a steeper "Moore's law" curve than traditional processors, and hence will outperform them by an exponentially increasing factor.
Dinner on the Queen Mary was fun. Mads Tofte hasn't been active in research lately, and it was great that he showed up to receive the award for Most Influential POPL paper of 1994, for his work on regions.
FOOL, 15 Jan 2005.
There was some question as to whether FOOL would continue after this year, but the meeting was lively and there was a strong concensus in favor of continuing. Benjamin Pierce commented "Most years there is at least one talk at FOOL that, after you hear it, you wish it wasn't accepted. But that wasn't the case this year." Special thanks to Benjamin for serving as chair of the FOOL steering committee for many years, and to Kathleen Fisher for picking up this role going forward.
My two favorite comments, both from the final panel on "Extreme Typing".
Robby Findler: Programmers are motivated to write strong contracts, because the stronger the contract the more likely that blame for a failing program will be assigned to the other guy. This explains why the notion of blame attached to higher-order contracts is important.
Jan Vitek: A recipe for stealth adoption: don't change the syntax of the language, but reinterpret the semantics of the existing constructs. (No one will notice the change anyway!) He was following the mandate to be provocative, but there is a knotty kernel of truth here.
Plan-X, 11 Jan 2005.
Michael Carey, BEA, on BEA Liquid Data, an approach to data integration. He notes that BEA developers tend to ignore the strong typing features of XQuery, for two reasons, one trivial and one material. Trivial: developers find it inelegant to have to validate the data after it is created in order to attach type information to it. This is just a matter of writing "validate { ... }" around the XML that creates the data, but they strong resist this. Material: validation can change the data in various corner cases, and so interferes heavily with optimization. I took two points away from this. First, XQuery seems to have failed in the goal of integrating types with queries -- trying to fit well with Schema has inevitably thrown up a lot of road blocks. Second, sometimes seemingly trivial points can be just as significant as material ones; another example of this is how the C-like syntax of C++ and Java helped these languages to spread rapidly.
Alan Schmitt on Xtatic. The pattern matching style of Xduce/Xtatic does not do well with data evolution, unlike XPath, as adding more elements to the data causes matching to fail. I would have thought of this as a bad thing, but Schmitt claims it is good, as the failure tells you where you need to change your code.
The demo session worked well. I particularly liked Fisher and Fernandez's PADX, which I had not seen before.
POPL, 12-14 Jan 2005.
Rob Pike on a programming language for searching Google's data. His neatest example was an animated map, with one pinprick of light for each query sent to Google in one day, correctly located in space and time -- one could watch the pattern of queries flow across the world. The data for the map was generated by a program just a few tens of lines long. The key to the query language is, as Rob noted, a simple idea from the functional programming community: use map and fold as the basis of parallel programming, where the fold is over over associative and commutative operators. Pike's language is based on Google's map-reduce system. (Added 27 Aug 2007: Pike's language is called Sawzall. Later a paper on it appeared here.)
Peter Selinger on a quantum programming language. A lovely presentation of tricky ideas, the first time I had made it through to the end. I finally understood that quantum programming involves two levels of probability, within a state there is the probability attached to each qbit, and then there is the probability of being in a particular entangled state. Selinger explained a clever matrix representation due to von Neuman that captures both levels. He gave a nice explanation of quantum teleportation/quantum compression as two halves of a "use once" isomorphism -- a pair of inverse functions that contain a free linear variable so each can be used only once, where the order of composition determines whether one has teleportation or compression. When I asked him why one should bother with programming languages for computers that might never be built, he pointed to the ability of the language to give precise descriptions of tricky thought experiments, as in the teleportation/compression example.
Pat Hanrahan argued that game processors pose a worthy challenge for language designers. He observes that game processors have a steeper "Moore's law" curve than traditional processors, and hence will outperform them by an exponentially increasing factor.
Dinner on the Queen Mary was fun. Mads Tofte hasn't been active in research lately, and it was great that he showed up to receive the award for Most Influential POPL paper of 1994, for his work on regions.
FOOL, 15 Jan 2005.
There was some question as to whether FOOL would continue after this year, but the meeting was lively and there was a strong concensus in favor of continuing. Benjamin Pierce commented "Most years there is at least one talk at FOOL that, after you hear it, you wish it wasn't accepted. But that wasn't the case this year." Special thanks to Benjamin for serving as chair of the FOOL steering committee for many years, and to Kathleen Fisher for picking up this role going forward.
My two favorite comments, both from the final panel on "Extreme Typing".
Robby Findler: Programmers are motivated to write strong contracts, because the stronger the contract the more likely that blame for a failing program will be assigned to the other guy. This explains why the notion of blame attached to higher-order contracts is important.
Jan Vitek: A recipe for stealth adoption: don't change the syntax of the language, but reinterpret the semantics of the existing constructs. (No one will notice the change anyway!) He was following the mandate to be provocative, but there is a knotty kernel of truth here.
Yet another Links comment.
A Links comment from Chui Tey. Pat Hanrahan of Stanford gave an invited talk at POPL 2005 on a similar theme, arguing that game processors ose a worthy challenge for language designers. He observes that game processors have a steeper "Moore's law" curve than traditional processors, and hence will outperform them by an exponentially increasing factor.
----
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
# posted by Chui Tey : 1:43 AM
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
----
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
# posted by Chui Tey : 1:43 AM
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
6.3.05
Xcaml
Xcaml is an extension of Caml for web applications, overlapping with Links in goals and methods.
Links update
Two updates on Links.
(1) The meeting will be 9.30--17.30 Wednesday 6 April 2005, in the Conference Suite, School of Informatics, 2 Buccleuch Place. After the meeting, we will adjourn for a drink in The Links Bar, Bruntsfield. As before, let me know if you want to attend.
(2) The Links meeting is colocated with ETAPS. There is no requirement to register for ETAPS to attend Links, but you may wish to do so. Please note that ETAPS registration fees increase after Monday 7 March. (Apologies for the late notice, but the venue was confirmed only recently.)
http://www.etaps05.inf.ed.ac.uk/
Cheers, -- P
(1) The meeting will be 9.30--17.30 Wednesday 6 April 2005, in the Conference Suite, School of Informatics, 2 Buccleuch Place. After the meeting, we will adjourn for a drink in The Links Bar, Bruntsfield. As before, let me know if you want to attend.
(2) The Links meeting is colocated with ETAPS. There is no requirement to register for ETAPS to attend Links, but you may wish to do so. Please note that ETAPS registration fees increase after Monday 7 March. (Apologies for the late notice, but the venue was confirmed only recently.)
http://www.etaps05.inf.ed.ac.uk/
Cheers, -- P
3.3.05
2.3.05
Three links from Will Partain
Tim O'Reilly on The Open Source Paradigm Shift
http://tim.oreilly.com/opensource/paradigmshift_0504.html
The magic behind google maps
http://jgwebber.blogspot.com/2005/02/mapping-google.html
For ideas about applications students will want to work on,
see Jamie Zawinski's recent rant on "groupware":
http://jwz.livejournal.com/444651.html
http://tim.oreilly.com/opensource/paradigmshift_0504.html
The magic behind google maps
http://jgwebber.blogspot.com/2005/02/mapping-google.html
For ideas about applications students will want to work on,
see Jamie Zawinski's recent rant on "groupware":
http://jwz.livejournal.com/444651.html
Subscribe to:
Posts (Atom)