Reinventing coding for the iPad : edit the parse tree
slidetocode.com
slidetocode.com
In fact, I think a Self-type environment might be the best: image-based, most of the objects are live (not types and a class browser as in Smalltalk, but a hierarchy of live objects) and can be manipulated via small pop-up menus, drags and swipes, with only minimal actual text edition.
It's a very visual experience, where actual typing is generally restricted to small functional blocks (for method slots), this is shared with Smalltalk (methods are edited one at a time in a small self-contained editor).
I don't think text is a good primary interface when the keyboard is a second-class citizen, this is decorated text but text is still king. The problem should be turned around, in touch-based environments where keyboards are secondary so should text be: it should be a DSL for defining behaviors but most of the application-building should be spent away from text.
I think this would be an interesting approach for a language that has Hindley-Milner type inference (like Haskell or OCaml.)
Then you could build an interface that makes it impossible to write a program that can't compile. In that case, the cost:benefit of such a UI might be most favorable.
(Update: Typed Racket might be a good target for your UI, since it has both a Lisp-like syntax and a robust typing system http://docs.racket-lang.org/ts-guide/)
Your point about type inference is great. I'm keen on Haskell and I do like the idea of an editor in which I can only write code that compiles.
The problem with making a editor that enforces "correct" coding is how to make the transitional writing work. At least for me, I tend to write things that wouldn't work, jump to some other place and fix up some related issue, and then jump back to where I was to finish that fragment. If you only allow "correct" code that wouldn't work. Also, saving code that is in a half-finished state might be an issue.
Marking the offending s-expressions, though... that would be a neat feature.
Your point about the intermediate state between a blank file and working program is true, but for example in TouchScheme you could never have a simple parentheses mismatch error such as (display (+ 1 2) as it takes care of that part of the S Expression for you. This does not however sacrifice any flexibility in what you can write.
Cool, I guess I'll just have to be patient then...
> Your point about the intermediate state between a blank file and working program is true, but for example in TouchScheme you could never have a simple parentheses mismatch error such as (display (+ 1 2) as it takes care of that part of the S Expression for you. This does not however sacrifice any flexibility in what you can write.
Yes, that's true. But the grand-grand-parent wasn't only talking about such simplistic error-checking. At least that was my impression. Say that you were to start writing a lambda expression, and then realize that you need to change something else:
(lambda (x
(lambda (x))
That said, you have a very interesting program and the ideas I see here are very interesting as well. I hope that you plan to post more updates on this to hacker news!
In a future post I will attempt to explain TouchScheme's behaviour in this sort of situation more fully, I think I have a good compromise. If you do have an iPad though, please get in touch, I'd love to hear your feedback on the beta.
"One hundred years ago, programs were punched onto cards that were fed into the machine. Fifty years ago, programs were written in a text editor and compilers just did the most basic optimizations. Now, of course, programs are...."
It seems obvious to me that in 30, 40, 50 years, we won't be developing software in the same manner we do now. Especially web software, which is a painful step backwards from UI Builders.
In this timeline, the transition from procedural to OO is insignificant, like the transition from hand-punched cards to machine-punched. With the benefit of hindsight, OO, Functional, whatever, will all feel primitive.
I predict that C& or C% will have an enormous industrial following, and the breakthrough of functional programming into industry will still be just around the corner.
More seriously my hope is that functions will begin to be filled in from a specification. In principle it would be great to write the test, and have the code filled in from there. It is not a problem I see being solved in the immediate future though.
"... described in natural language and/or generated preemptively."
I had a similar project for my dissertation and I also came to the conclusion that working on the AST is vital, so Lisp looked like a great option. But it was believed that it's much to unpopular and scary for anyone to ever manage to use it, so I ended up generating JS from blocks. Didn't work very well at all.
If you are interested in coding from your iPad, check out http://jackalope.me to sign up for early access.