Only in one sense. As code is now cheaper, abstractions meant to decrease code quantity have decreased in value. But abstractions meant to organize logic to make it easier to comprehend retains its value.
Previously there was a tension between easy-to-write (helper functions to group together oft-repeated lines of code, etc) vs easy to read (where often modest repetition is fine and is clearer). I felt this tension a lot in tests where the future reader is very happy with explicit lines of code setting things up, whereas the test author is bored and writes layers of helper functions to speed their work up.
But for LLMs, it seems readability of code pretty much equals its writability?
To make code more authorable by LLM, we approximately just need to make it more readable in the traditional sense (code comments, actual abstractions not just code-saving helper functions, etc).
I hope so, but it adds an extra difficulty
Easy to understand is not always an absolute metric, a project with many lines of code can be easy to understand for a team with a certain experience and difficult to understand for another team with a different experience (not less but different).
Now I will have to think about "easy to understand" for AI
hhhAndrew|1 year ago
Previously there was a tension between easy-to-write (helper functions to group together oft-repeated lines of code, etc) vs easy to read (where often modest repetition is fine and is clearer). I felt this tension a lot in tests where the future reader is very happy with explicit lines of code setting things up, whereas the test author is bored and writes layers of helper functions to speed their work up.
But for LLMs, it seems readability of code pretty much equals its writability?
To make code more authorable by LLM, we approximately just need to make it more readable in the traditional sense (code comments, actual abstractions not just code-saving helper functions, etc).
benve|1 year ago