semi off-topic: Prof. Pierce's research group created the Unison bi-directional file synchronizer and open-sourced it. It's a really useful tool that I use literally every single day to keep my files synchronized. Think of it as a predecessor to dropbox, without the UI polish ;)
Additional interesting fact, unison is written in ocaml. Very cool to see interesting systemsy software written in a functional programming language. I'm very excited to peruse it later.
Unison also hasn't been updated at all since the original authors stopped working on it, as far as I can tell. It's only one data point, but it does suggest a downside of using ocaml for open source software...
Yes, it's exciting problem. I think it's good he's articulated it.
Yet in ways, this paper seems like a confession that he's reached something of a brick wall with the problem.
If you look at the bidirectional link, http://lambda-the-ultimate.org/node/1526, he goes over a series of partial solutions before discussing his (very general) approach. I suspect that a workable system might be better through putting together all the classes of partial-but-well-behaved solutions rather than attempting a fully general solution.
Another thing that interests me is bidirectional code that operates on itself.
The "You need a PHD to understand Haskell" slur is so bloody ridiculous. I certainly didn't have a problem with it, and I haven't even finished my degree yet! On a more general note, I find the idea that a programming language can be "too smart" troubling. Is the solution to have dumber programming languages then?
There is a very big difference between "too smart" and "too complicated". I think Haskell is dangerously close to the former category while C++ is firmly in the second. I appreciate "smart" for many tasks, but sometimes the operational semantics become important (e.g. it's performance-sensitive) and then you have to understand the stack at a pretty deep level and it can be awfully confusing why a tiny source-level change makes a big performance or space difference.
Sometimes I pretty much know what assembly I want and it's much easier to make a C compiler produce it than to get GHC to produce it.
I agree that it is hard to get GHC produce the assembly you want, but I think this is unfair to "blame" GHC for this. In my eyes Haskell is mostly a high-level language and if you worry about the assembler produced I think we have left high-level language territory and it might easier to just write C and use the FFI.
Tools that fit the task make it simpler. Otherwise, much of your attention is diverted to the tool itself, and not available for the actual task. This can be fun provided the task isn't pressing.
One example is multiplication in the complex roman numeral system vs. (our) simple arabic numeral system.
Another example is PHP (tool) for webapps (task). Worked for YouTube and CDBaby. -- Honestly, I think the concept of embedding commands in HTML is brilliantly simple, because the program is largely isomorphic to the result, making it intuitive to reason about. [disclaimer not a webapp developer]
"Another example is PHP (tool) for webapps (task). Worked for YouTube and CDBaby. -- Honestly, I think the concept of embedding commands in HTML is brilliantly simple, because the program is largely isomorphic to the result, making it intuitive to reason about. [disclaimer not a webapp developer]"
Simple until you have to come in and maintain it. There are many levels of simple. What is often simple for the original writer is horrible for the person who picks it up later on and has to extend and maintain it.
A lot of academic research doesn't acknowledge that the reason a working programmer wants a tool that is really simple is because I am constantly working with the threat of my project becoming overwhelmingly complex. A really simple, clear tool lets me keep a little more distance from that final, looming complexity.
What's a good introduction to contracts? I'd like to know how a basic contract system works and which extensions are there? What's the relation between contracts and assert?
Provided that to you, a "good introduction" is something with a lambda-calculus extension and a reduction semantics, the 2002 paper by Findler and Felleisen[1] is a good read.
With respect to very precise type systems, and coupling between program structure and types, one of the reason mathematics is so powerful is its flexibility
I actually have trouble with mathematics, because it is so flexible. For example, equality of sets A and B is typically shown by saying that every element of A is in B, and every element in B is in A. Why on earth do they do that? Why not just say they're the same??!
One advantage is it gives you the flexibility to demonstrate the first limb using one technique, and the second limb with a completely unrelated approach. I saw one example of showing equivalence of language defined by a class of grammars, and a language defined by constraints over sequences. You could even use a constructive and a non-constructive proof for each half.
http://www.cis.upenn.edu/~bcpierce/unison/