Both. Hence the paradox.
I am serious, I just don’t mean 0% and 100% literally.
Conceptualizing perfect and an absolute impossibility. An almost perfect editor is one that is very productive transfering your thoughts to code that works. By sitting a very small amount of time in front of it. Spending 100% of that small time coding a high value program.
It allows you to spend nearly 100% of the close to 0% time you allocate to writ code in order to deliver a valuable program.
Programming is the reification of decision-making. A perfect computing system is one which turns a description of a problem space into a reliable, timely, correct solution for it. In existing computing systems, editors are used to turn human thoughts about solutions to the problem space into a code representation.
So a perfect editor would instantly turn what you would have thought of if you had thought about it perfectly correctly into the best possible code. Anything less than that is a mere approximation of a perfect editor.
Productivity is not so easily quantifiable, nor is time fungible.
If I produce the perfect text editor, which does not get in the way or distract me while I am thinking, and this is what allows me to come up with my next big idea, is that worth it?
If I produce a text editor with which I am 10% faster, I get a negative return on my time investment, sure, but what if I get more value from introspection into the way I spend my time?
I think that the resolution starts by noting that there are two ways that people conceptualize computation. When we focus on the computation itself, then a computer is a data transformer which takes inputs and turns them into outputs. When we focus on our own usage of machines, then a computer is a prompt where we lose time waiting for events to occur. So, on one hand, we want code editing to be efficient in terms of the transformations that we perform on our code; but on the other hand, we want to spend as little time editing code as possible.
In my opinion, you use “code editor” to equivocate between two different
tools. One is for programmers, and it facilitates programming. We usually call
these IDEs. The other tool is for product designers, and facilitates product
development without programming. This is closer to the prototyping or WYSIWYG
tools of today.
I think this equivocation is a disadvantage when it comes to answering
some of your initial questions:
What metric can we even use to measure the perfect code editor? How will we
know if and when we have it? Are we close to reaching that point?
You can’t hold IntelliJ and Figma to the same standard, nor VSCode and
Squarespace.
This is why the problem statement appears contradictory: two different solutions
to two different problems are compared as if they were of the same kind.
You could also zoom out a level and ask the same question about computing as a whole. Is the computer an end itself that brings you utility, or fun, or something else? Or should it help streamline your life, but invisibly, so that you can find joy elsewhere?
Both. Hence the paradox. I am serious, I just don’t mean 0% and 100% literally.
Conceptualizing perfect and an absolute impossibility. An almost perfect editor is one that is very productive transfering your thoughts to code that works. By sitting a very small amount of time in front of it. Spending 100% of that small time coding a high value program.
It allows you to spend nearly 100% of the close to 0% time you allocate to writ code in order to deliver a valuable program.
To me, the perfect editor is one I don’t have to think to use. I know it so well, it dissolves into the background.
Programming is the reification of decision-making. A perfect computing system is one which turns a description of a problem space into a reliable, timely, correct solution for it. In existing computing systems, editors are used to turn human thoughts about solutions to the problem space into a code representation.
So a perfect editor would instantly turn what you would have thought of if you had thought about it perfectly correctly into the best possible code. Anything less than that is a mere approximation of a perfect editor.
Productivity is not so easily quantifiable, nor is time fungible.
If I produce the perfect text editor, which does not get in the way or distract me while I am thinking, and this is what allows me to come up with my next big idea, is that worth it?
If I produce a text editor with which I am 10% faster, I get a negative return on my time investment, sure, but what if I get more value from introspection into the way I spend my time?
I think that the resolution starts by noting that there are two ways that people conceptualize computation. When we focus on the computation itself, then a computer is a data transformer which takes inputs and turns them into outputs. When we focus on our own usage of machines, then a computer is a prompt where we lose time waiting for events to occur. So, on one hand, we want code editing to be efficient in terms of the transformations that we perform on our code; but on the other hand, we want to spend as little time editing code as possible.
In my opinion, you use “code editor” to equivocate between two different tools. One is for programmers, and it facilitates programming. We usually call these IDEs. The other tool is for product designers, and facilitates product development without programming. This is closer to the prototyping or WYSIWYG tools of today.
I think this equivocation is a disadvantage when it comes to answering some of your initial questions:
You can’t hold IntelliJ and Figma to the same standard, nor VSCode and Squarespace.
This is why the problem statement appears contradictory: two different solutions to two different problems are compared as if they were of the same kind.
You could also zoom out a level and ask the same question about computing as a whole. Is the computer an end itself that brings you utility, or fun, or something else? Or should it help streamline your life, but invisibly, so that you can find joy elsewhere?