3 ms·

I can’t give a full reply atm, but briefly I’d say: yes, it’s more complex than character sequences but that complexity (which isn’t much) could be shifted to a

I can’t give a full reply atm, but briefly I’d say: yes, it’s more complex than character sequences but that complexity (which isn’t much) could be shifted to a lib once for any number of languages, as opposed to needing to parse every language uniquely.

chubot 7y ago
That's true, but what I'm saying is that parsing is not a bottleneck in programming tools. Parsing every language uniquely is a lot of work. But it is doable and more or less "done". After that you have a whole bunch of other problems to solve (i.e. all the other things an IDE or debugger does), and that's where the real work is. You can get rid of parsing by making structured data the primary format rather than the secondary format. But then you introduce a whole host of other problems. For example, how do you 'git merge'? You can't even collaborate anymore because merging is a textual algorithm. You would have to write a new merge algorithm for every single programming language, because each one has its own structured data format. So basically you get a slight benefit by removing text, in exchange for a huge cost. BTW here are some posts I've written about parsing: http://www.oilshell.org/blog/tags.html?tag=parsing#parsing http://www.oilshell.org/blog/tags.html?tag=parsing#parsing Again, parsing is a pain in the ass, but I believe it can be made easier, and it's not a bottleneck in any case. In my mind, the biggest bottlenecks in programming are: 1) Understanding the problem well enough to formulate the solution, whether it's in a programming language, math, or a visual syntax. 2) "Size is code's worst enemy". Many programming languages are inappropriate to express the problems they are solving. The code becomes unmanageably large pretty quickly. A million lines of C++ code is not a great way to express a solution to anything, yet it's the state of the art for vital projects like LLVM and Clang, Word, Photoshop, etc. Both of these are 1000x bigger problems than parsing IMO. I'm not trying to criticize your specific idea, but I have heard the general idea to "get rid of text" several times, including more than once on this thread ... so that's my general rebuttal, if you're interested in a reasoned critique.
- westoncb 7y ago
  Again I’m out atm and can’t reply on full, but I think if you read my post in more detail it already has the response to much of what you’re describing. I agree it’s not the bottleneck to programming languages overall, but it is the bottleneck to the HCI/UX component of language design. Edit: the git merge problem can be resolved by having a canonical text representation or doing a structure diff instead. As for the rest of your response, you’re basically saying you didn’t take the time to get a basic understanding of my proposal, and you think other problems are more important than the specific one I’m addressing. I’m not sure how that could lead to a fruitful discussion. I will take a look at the post about benefits of text though, so thanks for that. (Apologies if my frustration is coming out here, it’s just that I have had many responses—most much worse than yours—basically saying, “I didn’t read what you wrote but you should consider X instead.”)

chubot 7y ago

That's true, but what I'm saying is that parsing is not a bottleneck in programming tools. Parsing every language uniquely is a lot of work. But it is doable and more or less "done". After that you have a whole bunch of other problems to solve (i.e. all the other things an IDE or debugger does), and that's where the real work is. You can get rid of parsing by making structured data the primary format rather than the secondary format. But then you introduce a whole host of other problems. For example, how do you 'git merge'? You can't even collaborate anymore because merging is a textual algorithm. You would have to write a new merge algorithm for every single programming language, because each one has its own structured data format. So basically you get a slight benefit by removing text, in exchange for a huge cost. BTW here are some posts I've written about parsing: http://www.oilshell.org/blog/tags.html?tag=parsing#parsing http://www.oilshell.org/blog/tags.html?tag=parsing#parsing Again, parsing is a pain in the ass, but I believe it can be made easier, and it's not a bottleneck in any case. In my mind, the biggest bottlenecks in programming are: 1) Understanding the problem well enough to formulate the solution, whether it's in a programming language, math, or a visual syntax. 2) "Size is code's worst enemy". Many programming languages are inappropriate to express the problems they are solving. The code becomes unmanageably large pretty quickly. A million lines of C++ code is not a great way to express a solution to anything, yet it's the state of the art for vital projects like LLVM and Clang, Word, Photoshop, etc. Both of these are 1000x bigger problems than parsing IMO. I'm not trying to criticize your specific idea, but I have heard the general idea to "get rid of text" several times, including more than once on this thread ... so that's my general rebuttal, if you're interested in a reasoned critique.

westoncb 7y ago
Again I’m out atm and can’t reply on full, but I think if you read my post in more detail it already has the response to much of what you’re describing. I agree it’s not the bottleneck to programming languages overall, but it is the bottleneck to the HCI/UX component of language design. Edit: the git merge problem can be resolved by having a canonical text representation or doing a structure diff instead. As for the rest of your response, you’re basically saying you didn’t take the time to get a basic understanding of my proposal, and you think other problems are more important than the specific one I’m addressing. I’m not sure how that could lead to a fruitful discussion. I will take a look at the post about benefits of text though, so thanks for that. (Apologies if my frustration is coming out here, it’s just that I have had many responses—most much worse than yours—basically saying, “I didn’t read what you wrote but you should consider X instead.”)