2 ms·

I have wanted something like this for so long that I can’t remember when I started. Strongly coupling source code to plain text is a lost opportunity to improv

I have wanted something like this for so long that I can’t remember when I started. Strongly coupling source code to plain text is a lost opportunity to improve tooling.

jtwaleson 2y ago
Same! I think we need to free "code" from files, characters, tabs/spaces and variable names. Put millions of ASTs in a database. Imagine how much cheaper and better AI code assistants can be if they can only generate valid code with their "next token".
- zokier 2y ago
  At some point the AST needs to be serialized as bytes on disk. In the big picture, the cost of having that serialization format be also human readable is relatively small as long as the syntax is designed to be sane (i.e. not c++/perl)
- norman784 2y ago
  > Put millions of ASTs in a database. That's basically what unison does, they store the source code in binary format in an sqlite database.
School-Cotton 2y ago
The emacs mode paredit is basically structural editing for lisp code (and some of its more modern competitors like Smartparens support other languages too, but not as well as Lisp). It's great.
norir 2y ago
I disagree that plain text is an obstacle towards better tooling. You can do most of what the author describes with direct plain text edits pipelined into an analysis program. But I also think that the ux the author presents is undesirable. When writing new code, one must pass through a phase of broken code to reach the working code. I would not want an editor blocking me from typing a word that isn't yet defined but I do want it to notify me instantly that there is a problem. I also struggled to understand the use case for the mouse based ux. I am typing this comment on an iphone mini and would much rather write raw text on its keyboard than use the clicking interface shown in the fibonacci example.
vidarh 2y ago
The problem is communicating about code. Almost every visual / structural programming language attempts strands on how you talk about the code, and e-mail people about the code, and write about the code, or even how you efficiently input it. It's a multi-decade-long problem with many attempts.

I have wanted something like this for so long that I can’t remember when I started. Strongly coupling source code to plain text is a lost opportunity to improve tooling.

jtwaleson 2y ago

Same! I think we need to free "code" from files, characters, tabs/spaces and variable names. Put millions of ASTs in a database. Imagine how much cheaper and better AI code assistants can be if they can only generate valid code with their "next token".

zokier 2y ago
At some point the AST needs to be serialized as bytes on disk. In the big picture, the cost of having that serialization format be also human readable is relatively small as long as the syntax is designed to be sane (i.e. not c++/perl)
norman784 2y ago
> Put millions of ASTs in a database. That's basically what unison does, they store the source code in binary format in an sqlite database.

School-Cotton 2y ago

The emacs mode paredit is basically structural editing for lisp code (and some of its more modern competitors like Smartparens support other languages too, but not as well as Lisp). It's great.

norir 2y ago

I disagree that plain text is an obstacle towards better tooling. You can do most of what the author describes with direct plain text edits pipelined into an analysis program. But I also think that the ux the author presents is undesirable. When writing new code, one must pass through a phase of broken code to reach the working code. I would not want an editor blocking me from typing a word that isn't yet defined but I do want it to notify me instantly that there is a problem. I also struggled to understand the use case for the mouse based ux. I am typing this comment on an iphone mini and would much rather write raw text on its keyboard than use the clicking interface shown in the fibonacci example.

vidarh 2y ago

The problem is communicating about code. Almost every visual / structural programming language attempts strands on how you talk about the code, and e-mail people about the code, and write about the code, or even how you efficiently input it. It's a multi-decade-long problem with many attempts.