4 ms·

Personally I think syntax-directed programming is the only thing that makes sense. It's 2014, why are we still programming using a batch workflow? Why are we no

by audunw 12y ago

Personally I think syntax-directed programming is the only thing that makes sense. It's 2014, why are we still programming using a batch workflow? Why are we not in a live feedback loop with the compiler? There are natural answers to this of course - programming is insanely complex. I think history will look back at this time and see that we were struggling just getting programming to work at all. Making a decent syntax-directed programming environment would add so much more complexity to something that's already hard. We don't even have the tools necessary to get started - what about an exchangeable tree format that doesn't suck? I've played around a bit to create an AST in XML by hand, and using CSS to make it look like code. It's really interesting, suddenly you see that you're freed from caring how the syntax is formatted.. want curly braces around your blocks? Sure. Want just indenting? Have it your way. Want your function names in a larger font? No problem But XML and CSS is not good enough. Not by far. The other issue is that we've gotten really good at making text editors, and we know how to use them well. But tree structure editors? I don't even know of any. I suspect we'll always be editing parts of the tree as text anyway, especially expressions, it's just natural when the primary interface is the keyboard. We're getting there though. Eclipse, VS and XCode goes quite far towards understanding the syntax and semantics of the code, and I understand that the primary motivator for Apple to go to LLVM was being able to integrate the compiler tightly into the IDE. I'm sure many here have seen it already, but I would recommend looking at Bret Victors work for an idea of how things could be: http://vimeo.com/71278954 http://vimeo.com/71278954

seanmcdirmid 12y ago
You can have a live feedback loop without syntax-directed editing. E.g. see http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx http://research.microsoft.com/en-us/people/smcdirm/liveprogr... (tl;dr writing an incremental compiler/execution engine is nowhere near impossible).
audunw 12y ago
Another thing is that programming languages are not generally designed to be compatible with this. Pre-processed macros and comments etc. Nimrod could be suitable for a syntax-directed programming editor. All macros are part of the AST, even the comments are embedded in the syntax tree.
agumonkey 12y ago
I've heard many times that syntax direction is too strict and break people flow. The article says it's suited to students, here that wouldn't be an issue. That said, I'm pretty sold on the structure/tree editors vs char buffers, but I think there's need and opportunity for ideas to make building syntactically and type correct programs without slowing too much the user stream of ideas that can be random and at temporarily incorrect.
- audunw 12y ago
  Indeed, I suspect in the beginning, you would want to convert the tree back and forth between text and structure, so that you can edit parts of it in text. Editing text is a bit like working with a scratch pad, you're jotting down ideas. But once you're down with a block or function, you want it to be correct. The structure would then be for the editor to give you instant feedback on the syntax and semantics, for navigation, and for refactoring. In a way, the most advanced text editors and IDEs already do something much like this, but it feels like they are still closer to a text editor than a pure structure editor. The point is also that the editor is working on the exact same structure as the compiler, so the compiler can give you instant feedback on things you actually have to compile the code to find out. You could have dummy inputs to your function for instance, and instantly see what all the variables evaluate to, how long it takes for the function to execute, and how much space it takes.
  - agumonkey 12y ago
    Maybe it's CISC vs RISC all over again. That said I don't want to serialize subtree into linear strings to be able to insert/delete a few things. It's information loss to me. I envision something like subtree derivations to "fork" the current code block into a new one and substitute some tokens (not strings). Basically interactive tree rewrite. Derive tests on the fly, add some visual cues (diffs, types, errors). Be creative, use a layout abstraction like DOM or even higher to experiment freely.
TeMPOraL 12y ago
> Why are we not in a live feedback loop with the compiler? > what about an exchangeable tree format that doesn't suck? > create an AST in XML > But tree structure editors? I don't even know of any. I suspect we'll always be editing parts of the tree as text anyway, especially expressions, it's just natural when the primary interface is the keyboard. I really think it's time for you to discover Lisp ;). Take a good look at the language, s-expressions (your "tree format that doesn't suck"), Emacs with SLIME and paredit (the tree structure text editor with live feedback loop with the compiler). Since you said you were playing with ASTs in XML, I think this will be an excellent introduction: http://www.defmacro.org/ramblings/lisp.html http://www.defmacro.org/ramblings/lisp.html.
- seanmcdirmid 12y ago
  Lisp has been doing live feedback like the 70s since the 70s. It's time to move on from lisp machine.
  - pjmlp 12y ago
    And Smalltalk, Mesa/Cedar, Oberon, ... Yet the majority of younger generations never experienced such environments. To move on from Lisp live feedback, I would say we need to reach again, before going elsewhere.
    - seanmcdirmid 12y ago
      They are quite familiar with edit and continue (hot code replace). But they want the full Bret Victor experience, not some lesser variation that was possible to implement with 70s-level technology. We can surely be inspired by the past, but let's not get stuck there.
      - TeMPOraL 12y ago
        Sure, but the thing is that problems audunw wrote about were all solved in Lisp and/or Smalltalk. People today keep reinventing things that we had in 70s, except those things from the past are much better, because when they were invented computers were slow and the industry wasn't run by fashion, so they had time to think about what they're doing and what problems they are trying to solve. I'm not saying we should stay stuck with 70s tech; I say people need to actually look at it. It feels to me like breaktroughs in the industry come from recycling Protean technology, except the Antients who made it didn't live millions of years ago; they were likely drinking beer with your parents. So before greenspuning a half-assed, bug-ridden clone of Paredit and calling it a Revolutionary New Editor, please, please look at the more geekier corners of the past. Realize, that we already have good solutions for all the problems you're trying to solve (audunw, in this case). Sure they're not perfect. But it's better to learn from the mistakes and improve on something solid than to run in circles. Or maybe I'm just missing the obvious - http://xkcd.com/297/ http://xkcd.com/297/.

by audunw 12y ago

seanmcdirmid 12y ago

You can have a live feedback loop without syntax-directed editing. E.g. see http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx http://research.microsoft.com/en-us/people/smcdirm/liveprogr... (tl;dr writing an incremental compiler/execution engine is nowhere near impossible).

audunw 12y ago

Another thing is that programming languages are not generally designed to be compatible with this. Pre-processed macros and comments etc. Nimrod could be suitable for a syntax-directed programming editor. All macros are part of the AST, even the comments are embedded in the syntax tree.

agumonkey 12y ago

I've heard many times that syntax direction is too strict and break people flow. The article says it's suited to students, here that wouldn't be an issue. That said, I'm pretty sold on the structure/tree editors vs char buffers, but I think there's need and opportunity for ideas to make building syntactically and type correct programs without slowing too much the user stream of ideas that can be random and at temporarily incorrect.

audunw 12y ago
Indeed, I suspect in the beginning, you would want to convert the tree back and forth between text and structure, so that you can edit parts of it in text. Editing text is a bit like working with a scratch pad, you're jotting down ideas. But once you're down with a block or function, you want it to be correct. The structure would then be for the editor to give you instant feedback on the syntax and semantics, for navigation, and for refactoring. In a way, the most advanced text editors and IDEs already do something much like this, but it feels like they are still closer to a text editor than a pure structure editor. The point is also that the editor is working on the exact same structure as the compiler, so the compiler can give you instant feedback on things you actually have to compile the code to find out. You could have dummy inputs to your function for instance, and instantly see what all the variables evaluate to, how long it takes for the function to execute, and how much space it takes.
- agumonkey 12y ago
  Maybe it's CISC vs RISC all over again. That said I don't want to serialize subtree into linear strings to be able to insert/delete a few things. It's information loss to me. I envision something like subtree derivations to "fork" the current code block into a new one and substitute some tokens (not strings). Basically interactive tree rewrite. Derive tests on the fly, add some visual cues (diffs, types, errors). Be creative, use a layout abstraction like DOM or even higher to experiment freely.

TeMPOraL 12y ago

> Why are we not in a live feedback loop with the compiler? > what about an exchangeable tree format that doesn't suck? > create an AST in XML > But tree structure editors? I don't even know of any. I suspect we'll always be editing parts of the tree as text anyway, especially expressions, it's just natural when the primary interface is the keyboard. I really think it's time for you to discover Lisp ;). Take a good look at the language, s-expressions (your "tree format that doesn't suck"), Emacs with SLIME and paredit (the tree structure text editor with live feedback loop with the compiler). Since you said you were playing with ASTs in XML, I think this will be an excellent introduction: http://www.defmacro.org/ramblings/lisp.html http://www.defmacro.org/ramblings/lisp.html.

seanmcdirmid 12y ago
Lisp has been doing live feedback like the 70s since the 70s. It's time to move on from lisp machine.
- pjmlp 12y ago
  And Smalltalk, Mesa/Cedar, Oberon, ... Yet the majority of younger generations never experienced such environments. To move on from Lisp live feedback, I would say we need to reach again, before going elsewhere.
  - seanmcdirmid 12y ago
    They are quite familiar with edit and continue (hot code replace). But they want the full Bret Victor experience, not some lesser variation that was possible to implement with 70s-level technology. We can surely be inspired by the past, but let's not get stuck there.
    - TeMPOraL 12y ago
      Sure, but the thing is that problems audunw wrote about were all solved in Lisp and/or Smalltalk. People today keep reinventing things that we had in 70s, except those things from the past are much better, because when they were invented computers were slow and the industry wasn't run by fashion, so they had time to think about what they're doing and what problems they are trying to solve. I'm not saying we should stay stuck with 70s tech; I say people need to actually look at it. It feels to me like breaktroughs in the industry come from recycling Protean technology, except the Antients who made it didn't live millions of years ago; they were likely drinking beer with your parents. So before greenspuning a half-assed, bug-ridden clone of Paredit and calling it a Revolutionary New Editor, please, please look at the more geekier corners of the past. Realize, that we already have good solutions for all the problems you're trying to solve (audunw, in this case). Sure they're not perfect. But it's better to learn from the mistakes and improve on something solid than to run in circles. Or maybe I'm just missing the obvious - http://xkcd.com/297/ http://xkcd.com/297/.