Except realistically the standards around commenting are going to change dramatically over the next decade because of generative AI.
I’ve been toying with selecting ‘comments’ as my language of choice for my next hobby project to see if pseudocode and comments can lead to a language agnostic project that can reliably be reproduced in multiple languages.
As the tech gets better, more and more of the job is going to be writing comments about what the code should do as opposed to documenting what it does do.
Just write your code, so that you (almost) don’t need comments (i.e. simple to read). The problems with (most) comments won’t be solved by AI.
(in-code) comments only make sense for me in roughly these scenarios:
complex piece of math possibly from a paper (e.g. a ref to the paper where it is explained)
function doc, here AI may really help at some time (right now, I’ll rather write it myself, AI represents this post very well in an even more verbose and literate way than the typical junior dev…)
This couples intentions to the code which in my example would be dynamic.
That’s going to be a bad time.
My point is that the conventions that used to be good for the past 50 years of development are likely going to change as tooling does.
Programming is effectively about managing complexity.
Yes, the abstraction of a development language being the layer at which you encode intention rather than in comments is better when humans are reading and writing the code itself.
But how many projects have historically run into problems when a decade earlier they chose a language that years later is stagnating in tooling or integrations versus another pick?
Imagine if the development work had been done exclusively in pseudocode and comments guiding generative AI writing in language A. How much easier might porting everything to language B end up being?
Language agnostic development may be quite viable within a year or so.
And just as you could write software in binary, letting a compiler do that and working with an abstracted layer is more valuable in time and cost.
I’m saying that the language is becoming something which software can effectively abstract, so moving the focus yet another layer up will likely be more valuable than clinging to increasingly obsolete paradigms.
Except realistically the standards around commenting are going to change dramatically over the next decade because of generative AI.
I’ve been toying with selecting ‘comments’ as my language of choice for my next hobby project to see if pseudocode and comments can lead to a language agnostic project that can reliably be reproduced in multiple languages.
As the tech gets better, more and more of the job is going to be writing comments about what the code should do as opposed to documenting what it does do.
Just write your code, so that you (almost) don’t need comments (i.e. simple to read). The problems with (most) comments won’t be solved by AI.
(in-code) comments only make sense for me in roughly these scenarios:
The problems with comments are explained well IMHO here: https://www.youtube.com/watch?v=Bf7vDBBOBUA
Here is an alternative Piped link(s): https://piped.video/watch?v=Bf7vDBBOBUA
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
This couples intentions to the code which in my example would be dynamic.
That’s going to be a bad time.
My point is that the conventions that used to be good for the past 50 years of development are likely going to change as tooling does.
Programming is effectively about managing complexity.
Yes, the abstraction of a development language being the layer at which you encode intention rather than in comments is better when humans are reading and writing the code itself.
But how many projects have historically run into problems when a decade earlier they chose a language that years later is stagnating in tooling or integrations versus another pick?
Imagine if the development work had been done exclusively in pseudocode and comments guiding generative AI writing in language A. How much easier might porting everything to language B end up being?
Language agnostic development may be quite viable within a year or so.
And just as you could write software in binary, letting a compiler do that and working with an abstracted layer is more valuable in time and cost.
I’m saying that the language is becoming something which software can effectively abstract, so moving the focus yet another layer up will likely be more valuable than clinging to increasingly obsolete paradigms.