3 ms·

I skimmed your blog post, and I'm not quite sure I understand how it will make editing easier. It seems more complex to me, although that might be because it's

by chubot 8y ago

I skimmed your blog post, and I'm not quite sure I understand how it will make editing easier. It seems more complex to me, although that might be because it's unfamiliar. If you want some intelligent counterpoint, here is a post by the designer of Rust on why text is a good representation for programs: Always Bet On Text https://graydon2.dreamwidth.org/193447.html https://graydon2.dreamwidth.org/193447.html As someone who's working on a programming language, and has implemented a few DSLs and many parsers, I tend to agree with him. Parsing is a pain in the ass, but I think it can made easier. The difference between text and structured data is "just" parsing, so I don't feel that switching to structured data can be a real paradigm shift. If there was a paradigm shift to be found, then it would have been implemented already by converting text to structured data, and operating on that data. And this of course already happens in dozens of IDEs, and that's great, but it already happened. And while I have seen people be fantastically productive in IDEs, a lot of the best programmers I've seen also use emacs/vim. But your ideas do seem more fleshed out than most, and I think that developing a prototype is the only way to make them more concrete, and more clearly see the benefits and costs. I do think there are benefits to making structured data the primary format -- I just think they are outweighed by the costs. Graydon's post outlined a bunch of things you lose if you abandon text.

westoncb 8y ago
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 8y 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 8y 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.”)

by chubot 8y ago

westoncb 8y ago

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 8y 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 8y 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.”)