> The question is - if most of the work we want to do is about changing existing code, then why is the system not optimized for change by default? The code we write is optimized for reading the source text and its storage.
But it is optimized for change! That's exactly the reason line-by-line textual coding has been so hard to disrupt! Many, many non-text or augmented-text options for code have been tried, and they all fail exactly because they're not optimized for change! It's a pain in the ass to go and change some visual, graph-based program that someone else wrote, and an even bigger pain to keep it in source control. Text is the easiest thing in the world to change.
And I'll repeat the same refrain whenever the idea of non-text-based programming comes up: you're underestimating how long code spends in a non-functional state (cannot be unambiguously parsed into an AST), and how important that intermediate state is. Text handles that state beautifully, and every other option fails at it hard.
> Or even better, I want to specify a goal like "I want this function to not take this parameter" and let the system figure out how to transform the program to achieve this goal.
Or, even better, I want to specify a goal like "Make me a website that does cool shit" and let the system figure out how to achieve this goal. The author's stated goal is extremely ambiguous, and it's exactly our jobs to resolve that type of ambiguity. What exactly should the system to do? If you want someone else to figure that out for you, then you just don't really want to be a programmer.
>I can imagine a system that can combine small transforms into larger ones and use some AI magic to figure out how to compose them to achieve the specified goal.
So this whole article really is just "I'm sick of programming and I want an AI to do it for me". It's OK to be sick of your profession, but that doesn't mean other people are doing it wrong.
> If we instead focused on building the right model, we could better optimize that model for editing and the text could be just a view of that model. If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care.
But we do just focus on building the right model. The text is not the hard part -- not by a long shot! That's why discussion and deep thought are where the real programming happens; translating it into working code is a very small fraction of the whole process. "The text is just a view" just kicks the can down the road -- a view into what? Whatever that underlying thing is (some awful clunky graph-based model?), that's now your language. Of course you have a language somewhere.
Again I get the impression the author is just sick of being a programmer.
But it is optimized for change! That's exactly the reason line-by-line textual coding has been so hard to disrupt! Many, many non-text or augmented-text options for code have been tried, and they all fail exactly because they're not optimized for change! It's a pain in the ass to go and change some visual, graph-based program that someone else wrote, and an even bigger pain to keep it in source control. Text is the easiest thing in the world to change.
And I'll repeat the same refrain whenever the idea of non-text-based programming comes up: you're underestimating how long code spends in a non-functional state (cannot be unambiguously parsed into an AST), and how important that intermediate state is. Text handles that state beautifully, and every other option fails at it hard.
> Or even better, I want to specify a goal like "I want this function to not take this parameter" and let the system figure out how to transform the program to achieve this goal.
Or, even better, I want to specify a goal like "Make me a website that does cool shit" and let the system figure out how to achieve this goal. The author's stated goal is extremely ambiguous, and it's exactly our jobs to resolve that type of ambiguity. What exactly should the system to do? If you want someone else to figure that out for you, then you just don't really want to be a programmer.
>I can imagine a system that can combine small transforms into larger ones and use some AI magic to figure out how to compose them to achieve the specified goal.
So this whole article really is just "I'm sick of programming and I want an AI to do it for me". It's OK to be sick of your profession, but that doesn't mean other people are doing it wrong.
> If we instead focused on building the right model, we could better optimize that model for editing and the text could be just a view of that model. If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care.
But we do just focus on building the right model. The text is not the hard part -- not by a long shot! That's why discussion and deep thought are where the real programming happens; translating it into working code is a very small fraction of the whole process. "The text is just a view" just kicks the can down the road -- a view into what? Whatever that underlying thing is (some awful clunky graph-based model?), that's now your language. Of course you have a language somewhere.
Again I get the impression the author is just sick of being a programmer.