3 ms·

It is a shame that we don’t have better tools, and that we are still hand-editing text files in order to write programs. Imagine having an editor which automat

It is a shame that we don’t have better tools, and that we are still hand-editing text files in order to write programs. Imagine having an editor which automatically applied your local preferences around tabs/spaces, code formatting, variables up top vs nearest use, function definitions nested to minimize top-scope surface area vs all functions flat at top scope, etc etc etc And when you are done editing, all of these local changes are reversed and you submit the minimal possible diff. (and if we want to really talk pipe dreams, the dev only sees an AST editor and the underlying text is never even exposed in the first place) Our tools are so far behind mostly because everyone’s thinking is still chained to 1970’s hand editing text files mentality. This is the flying car which isn’t being worked on because everyone is still thinking about making better bicycles.

spaetzleesser 5y ago
Agreed. It seems silly that we still have to deal with things like tabs vs spaces or formatting in different ways. This should be handled by IDEs and editors.
cjfd 5y ago
AST editting would be kind of okay. But never better than kind of okay. Thoughtfully formatted text can be quite a bit nicer. Also, cities where one can get around on bicyles are much nicer than where one needs to use cars. Flying or otherwise. https://www.youtube.com/watch?v=ul_xzyCDT98 https://www.youtube.com/watch?v=ul_xzyCDT98 To summarize both points: what looks like progress superficially may actually not be progress at all.
ajuc 5y ago
The benefit is minimal, the task is hard, there's decades worth of tools that won't work, and it's easy to mess up introducing "impossible bugs" with behind-the-scenes transformations. Also - AST isn't THAT important when reading the code. Let's say I give you this: X (X X X X; X X X; X X) { X (X X X) { X(X X X X X) } } Do you know what this code does? How about this: for int i = 0 i < 10 i ++ if i % 2 printf " %d " , i I've used several graphical languages professionally (not AST-based, graph-based, but the problem remains) and the main problem was - structure wasn't fully describing what happens - the "meat" of the behaviour was still in text form and was hidden behind the pretty graphic form - in case of both of these languages the meat was in the names of the subprocesses called and in the mapping of process variables <-> subprocess parameters. And there were A LOT of these, so you couldn't show them at once on the same screen as the graphical view of the process. So programming with both of these languages was very frustrating - you had to click on each node and look through long lists of x:y substitutions to track how parameters flow through the system.
al2o3cr 5y ago
Our tools are so far behind mostly because everyone’s thinking is still chained to 1970’s hand editing text files mentality. People IN THE LITERAL 1970s were talking about this exact idea. We still don't have this, for anything other than highly-specialized applications (for instance, equation editors in word processors). It's almost like it's way, way, way harder to deliver software than it is to handwave about how much better things would be if people just listened to YOU.
- cellularmitosis 5y ago
  > if people just listened to YOU. Not really the tone I had intended, but it looks like that's the tone which came across. To be more explicit: "It's a shame there's no money in next-gen tooling"
  - morelisp 5y ago
    Tons of money got dumped into 4GLs and 5GLs. For the time just unbelievable sums, and a whole generation of PL research. Almost all down the toilet.
feoren 5y ago
One thing people never realize when they talk about this kind of technology is the amount of time code spends in a non-compiling state. Think about what your dream tool does what you cannot parse the code into an AST because you're in the middle of an hours-long refactor. That's a huge reason why it's so useful having the lowest-level representation as text. Another problem is that virtually all of these efforts completely misunderstand what makes programming hard.

spaetzleesser 5y ago

Agreed. It seems silly that we still have to deal with things like tabs vs spaces or formatting in different ways. This should be handled by IDEs and editors.

cjfd 5y ago

AST editting would be kind of okay. But never better than kind of okay. Thoughtfully formatted text can be quite a bit nicer. Also, cities where one can get around on bicyles are much nicer than where one needs to use cars. Flying or otherwise. https://www.youtube.com/watch?v=ul_xzyCDT98 https://www.youtube.com/watch?v=ul_xzyCDT98 To summarize both points: what looks like progress superficially may actually not be progress at all.

ajuc 5y ago

The benefit is minimal, the task is hard, there's decades worth of tools that won't work, and it's easy to mess up introducing "impossible bugs" with behind-the-scenes transformations. Also - AST isn't THAT important when reading the code. Let's say I give you this: X (X X X X; X X X; X X) { X (X X X) { X(X X X X X) } } Do you know what this code does? How about this: for int i = 0 i < 10 i ++ if i % 2 printf " %d " , i I've used several graphical languages professionally (not AST-based, graph-based, but the problem remains) and the main problem was - structure wasn't fully describing what happens - the "meat" of the behaviour was still in text form and was hidden behind the pretty graphic form - in case of both of these languages the meat was in the names of the subprocesses called and in the mapping of process variables <-> subprocess parameters. And there were A LOT of these, so you couldn't show them at once on the same screen as the graphical view of the process. So programming with both of these languages was very frustrating - you had to click on each node and look through long lists of x:y substitutions to track how parameters flow through the system.

al2o3cr 5y ago

Our tools are so far behind mostly because everyone’s thinking is still chained to 1970’s hand editing text files mentality. People IN THE LITERAL 1970s were talking about this exact idea. We still don't have this, for anything other than highly-specialized applications (for instance, equation editors in word processors). It's almost like it's way, way, way harder to deliver software than it is to handwave about how much better things would be if people just listened to YOU.

cellularmitosis 5y ago
> if people just listened to YOU. Not really the tone I had intended, but it looks like that's the tone which came across. To be more explicit: "It's a shame there's no money in next-gen tooling"
- morelisp 5y ago
  Tons of money got dumped into 4GLs and 5GLs. For the time just unbelievable sums, and a whole generation of PL research. Almost all down the toilet.

feoren 5y ago

One thing people never realize when they talk about this kind of technology is the amount of time code spends in a non-compiling state. Think about what your dream tool does what you cannot parse the code into an AST because you're in the middle of an hours-long refactor. That's a huge reason why it's so useful having the lowest-level representation as text. Another problem is that virtually all of these efforts completely misunderstand what makes programming hard.