3 ms·

I think people will soon realize that code is a data structure, not text. Like a hash map or an array, its text representation is merely a human-readable inter

I think people will soon realize that code is a data structure, not text. Like a hash map or an array, its text representation is merely a human-readable interface to it. I predict the capabilities of IDEs will expand, and to make their state persistent, they will begin to store IDE-specific files in your source code directory. Eventually this will morph into the source code itself being stored in binary format and opened/searched by editors. The programming language Unity is pioneering in this domain, but they are too far ahead of their time. The transition to code-as-data will be gradual.

oumua_don17 5y ago
>> people will soon realize that code is a data structure, not text Are you being tongue in cheek because most haven’t realised it in 63 years!!! [1] https://en.wikipedia.org/wiki/Lisp_(programming_language) https://en.wikipedia.org/wiki/Lisp_(programming_language)
mcphage 5y ago
> I think people will soon realize that code is a data structure, not text. Always 5 years out, like nuclear fusion. :-(
feoren 5y ago
When I see people talking about storing code in an AST representation or something similar, I see people who are focusing on the "happy path" and not really thinking about why code-as-text has been so sticky for half a century. (1) Code spends a huge amount of time in a non-parsable state. I need to be able to save code even when it's not currently parsable into a valid AST of the language I am writing. Sometimes I even need to check in this code to my source control. You cannot have the primary storage of your code be valid, parsed syntax trees for this reason, so you need to invent a brand new format that is different from both text and the AST being modeled. This format needs to be optimized for programmer workflow, clarity, and communication; not optimized for the machine. (2) You need to re-invent how source control works for your representation if you're not using text. This actually has a lot of potential -- syntax-aware merging done well would be a godsend. But this is a huge undertaking to do well, and problem 1 rears its head strongly here as well.
- drainyard 5y ago
  > (2) Have you heard of https://dion.systems/ https://dion.systems/ that was linked here recently? They are working towards going away from text as the source format. It remains to be seen whether or not it is a good idea and/or if it will succeed if it is. > (1) I guess in something like Dion, you have a source format that doesn't allow syntax errors, since you are not editing something that can be in an invalid state (necessarily).
- hcs 5y ago
  > (1) Code spends a huge amount of time in a non-parsable state. One way to attack this is via holes, as in https://hazel.org/ https://hazel.org/
chudi 5y ago
So you mean smalltalk or lisp?

oumua_don17 5y ago

>> people will soon realize that code is a data structure, not text Are you being tongue in cheek because most haven’t realised it in 63 years!!! [1] https://en.wikipedia.org/wiki/Lisp_(programming_language) https://en.wikipedia.org/wiki/Lisp_(programming_language)

mcphage 5y ago

> I think people will soon realize that code is a data structure, not text. Always 5 years out, like nuclear fusion. :-(

feoren 5y ago

When I see people talking about storing code in an AST representation or something similar, I see people who are focusing on the "happy path" and not really thinking about why code-as-text has been so sticky for half a century. (1) Code spends a huge amount of time in a non-parsable state. I need to be able to save code even when it's not currently parsable into a valid AST of the language I am writing. Sometimes I even need to check in this code to my source control. You cannot have the primary storage of your code be valid, parsed syntax trees for this reason, so you need to invent a brand new format that is different from both text and the AST being modeled. This format needs to be optimized for programmer workflow, clarity, and communication; not optimized for the machine. (2) You need to re-invent how source control works for your representation if you're not using text. This actually has a lot of potential -- syntax-aware merging done well would be a godsend. But this is a huge undertaking to do well, and problem 1 rears its head strongly here as well.

drainyard 5y ago
> (2) Have you heard of https://dion.systems/ https://dion.systems/ that was linked here recently? They are working towards going away from text as the source format. It remains to be seen whether or not it is a good idea and/or if it will succeed if it is. > (1) I guess in something like Dion, you have a source format that doesn't allow syntax errors, since you are not editing something that can be in an invalid state (necessarily).
hcs 5y ago
> (1) Code spends a huge amount of time in a non-parsable state. One way to attack this is via holes, as in https://hazel.org/ https://hazel.org/

chudi 5y ago

So you mean smalltalk or lisp?