Hacker News new | past | comments | ask | show | jobs | submit login
Reinventing coding for the iPad : edit the parse tree (slidetocode.com)
92 points by steeleduncan on March 18, 2012 | hide | past | favorite | 21 comments



This kind-of look like the shots/demos I've seen of the Self environment.

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 your prototype is interesting and probably a step in the right direction, though perhaps not practical until it is fleshed out more.

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/)


This is definitely a prototype and at best a first step. I am looking to sign up beta-testers, so get in contact if you are interested.

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.


I must say that this is a very interesting project. Any hope for an android version?

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.


Android (like other languages) is on the roadmap once the iPad scheme version is working smoothly.

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.


> Android (like other languages) is on the roadmap once the iPad scheme version is working smoothly.

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
With automagic paren-balancing you'd get

  (lambda (x))
which is still an invalid form. You could make the editor auto-insert a nil (or is it #f in scheme? I always get those mixed up), but that would be a dangerous route to take. Or you could mark it as an invalid form and make the user fix it before the editor even considers evaluating the program (or just that fragment).

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!


The scheme equivalent of nil is ill-defined and differs between implementations, though I certainly don't intend to go that route.

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.


Have you studied Touch Develop by Microsoft Research? They seem to have found a good way of enabling coding on touch devices. You can get more info at http://www.touchdevelop.com/


They're typing parenthesis in the video. You can't type parenthesis on an iPad without switching the key set. That, plus the small targets and odd autocomplete (missing close-parenthesis, by the look of it) makes me wonder if they've actually used this to a significant degree on an iPad instead of in the emulator...


You also need to switch keyboards to type numbers, and parentheses are there just one switch away. Similar to those behind the iPad port of Vim I think that the slight convenience of a keyboard accessory view does not justify the reduction in screen space.


I don't think I could code with something like this, the elements of the interface keep moving, things slide in and slide out all the time, it's just too distracting. I guess people used to IDE who constantly nag you like Eclipse might like it.


That seems surmountable. Surely the slidiness is tweakable, at least at the design level. Even if it was just faster, that would help, wouldn't it?


Sometimes I like to think about how this sentence will be finished:

"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.


C has been going strong for 40 years now, and Lisp for 50, so code may look worryingly similar.

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.


Probably

"... described in natural language and/or generated preemptively."


I think this is fairly interesting, it would be cool to explore combining this with visual block style stream processing like Max MSP or pd or vvvv, etc.


I didn't like how the user types at the top, but is constantly going down to the bottom to press "Run" for the REPL. Maybe that's just watching the video, and with the ipad it's not so annoying?


Seems to me like Run deserves to be a gesture.


Very interesting. Looks like a cross between the App Inventor (blocks-to-scheme) and Alice (fill-in-java).

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.


I am also working on a set of iOS tools that allow you to view, edit, and commit your Github projects on the go.

If you are interested in coding from your iPad, check out http://jackalope.me to sign up for early access.


I really like that you have taken the typing out of syntax. Syntaxes could be distilled into icons and be put out of the line thought. I'd like to code like that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: