Lambda the Ultimate

Considering the paper isn't exactly a peer-reviewed publication, but free on the internet, the usual caveats about free advice apply. No doubt he is over-stating his case, but his examples does show at least one very important point: 2D graphic layout. For the things that involve a time, it's best to use one of the dimensions of the screen for that information, rather than giving a small button to click. I'm sure that observation and some good experimental evidence for faster task accomplishment, is worth a real paper. Very few places utilise the screen as a 2D canvas to present information.

Personally, I think all the stuff about context-sensitivity is far, far harder than he's making it out to be. Inferring semantics from textual snippets is basically trying to do type-inference on natural language. By the usual rule that anything a human can't do reliably, we can't get a computer to do at all, the proposed feat is pretty high up.

Check out some of my new SuperGlue work. I've integrated SuperGlue with an IDE to enable live programming, which still means that someone has to write code, but at least they can see the results of what they are doing while they are writing. I was wondering if this would be possible in an FRP language like FrTime or FlapJax.

I didnt know a word about FlapJax. Im "playing" width the compiler and i really like it. I want to use it to my personal site of Songs, Letras de canciones.
Thanks in advance!

During my own course of experiments with FRP I too have wondered about IDE integration... what I envision is a graphical tool (much like LabVIEW or Max/MSP) allowing the programmer to create data flow graphs with arrows and boxes, running in parallel with another tool which allows them to graphically construct a GUI. Any widgets placed into the GUI are made available for use in the signal graph, and vice-versa (this is the same idea used in LabVIEW and schematic/layout capture tools such as Cadence). Individual signal nodes can have algorithmic code associated with them, in the programmer's favorite language, and can be edited the "old-fashioned" way (this is how schematic capture tools which support HDL code work, and I believe also LabVIEW and Max as well).

Now, thanks to the nature of FRP systems that can modify their own signal graphs, combined with a system such as MetaOCaml to compile the algorithmic code, we can go the SuperGlue route and make entire system live: add a button to your GUI, wire up its signals, click it, and watch what happens. Add support for an O'Caml-style time-travelling debugger (possible because the FRP system "knows" where all the state is kept) and the user will have a convenient way to test different changes from some known state without having to revert back to the initial state. The FRP system's state-omniscience also gives you state marshalling "for free", allowing programmers to share "buggy" states with each other, save a debugging session for later, etc.

I still feel the risk of ambiguity is too high to apply history and context to languages themselves, but could be convinced.

Do you mean that a language based on a situation/action perspective is ambiguous? This must be allowed as a possibility because otherwise there would be no need for named action or situation. That is the action would be determinate and the situation would be a state space.

Programming with a situation/action perspective, or activity representation, must be a backtracking language to account for unexpected results. The situation/action perspective is goal oriented. A program is successful by reaching its goal not by executing a specific process.

That creates a really interesting dilemma. It is better to create inclusive interfaces which can be used by as many people as possible. However, I think that it is also a mistake to optimize for the needs of the few at the cost of the efficiency of the many. To tie this in to PL - read The Development of Chez Scheme where K. Dybvig states his compiler-design philosophy (paraphrased) where "the advanced features have to pay their own way, and do not affect the cost of the common features".

I prefer interfaces with many different views to suit different needs. I am a strong non-believer in one-size-fits-all, especially when it comes to language design and IDEs. Of course, we are very far away from having the engineering body-of-knowledge available to create languages/IDEs with multiple views (back to the link with IP!).

1D ASCII is close to lowest-common-denominator (but not quite, as I know a brilliant programmer who is completely blind). Having a language/system which are extremely difficult to use by blind people is not good (and they exist: think Simulink; the underlying ASCII files are quite monstrous).