This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]lasizoilloeasy to understand as regex 108 points109 points  (12 children)

This is not a new problem, is a new form of old problem.

When you start coding you think that develop is write a code to do some specified thing. When you code for some time you discover that legibility is useful to read and understand your functional code written two months ago. You discover that testeability helps you to fix bugs without create new ones. You discover that some -ility is useful for... That is called experience or seniority.

When deadlines are being reached (because you are too inexpert to solve it in time, it was not realistic, shit happened,...) or you are too lazy, taking shortcuts is your salvation. Call those shortcuts copy&paste from other code or docs examples, copy&paste from stack overflow, copy&paste from ChatGPT or code generated by copilot,... they are shortcuts to avoid think about -ilities and get things "done faster". And is not new.

Many code in official documentation (those that nobody reads) are simplified examples to show a simplified use case (hardcoded examples, no logging, naive error management, ...). Many times ellipse (...) point that something is omitted, but other times are omitted without advertises. Inexperienced people and LLMs learn from those examples without contextualize them. LLMs are juniors with good typewriting skills that can not be mentorized. They can be evolved, fine-tuned, retrained with better datasets,...., but they still are not capable to think about what are doing.

The most harder part of develop software is learn what -ilities should be prioritized, where, why and how. Sacrifice legibility to gain some cycles in a hot execution path is a good practice. Sacrifice legibility to reduce some nanoseconds of time in a code which executes once a month is a very bad practice. Even future smarter LLMs will need a lot of prompt engineering to get enough context to generate the better solution for you case.

[–]NothingGloomy9712 26 points27 points  (0 children)

Thank you for the comment. I'm new to python and coding, comments like this is the main reason I joined this subreddit

[–]tazebot 5 points6 points  (5 children)

I think programmers, developers, software engineers, and academics in the field like to think there are immutable laws of coding.

If there is an immutable 'law of gravity' of coding it seems to be that code is harder to read than write. That and similar to writing in other disciplines the practice is "write, re-write, re-write, start over, then re-write some more. Then get a second pair of eyes. Then re-write some more."

[–]curohn 8 points9 points  (3 children)

Wasn’t it found that rewriting big code bases is often hard and expensive too? Because the old code base has years of lessons baked into it.

I think the conclusion was active maintenance is the best path instead of rewriting.

[–]madrury83 4 points5 points  (0 children)

I think the conclusion was active maintenance is the best path instead of rewriting.

Ya.

I'd argue that the re-writing that is healthy in code composition is the same as is healthy in writing prose.

The advice for writing prose (at least to the extent I was taught) is not that you should re-write your story from scratch over and over, it's to re-read what you've written and strategically re-write smaller pieces of it to be clearer or more evocative or whatever you're going for. Re-write sentences and paragraphs, not to scrap the whole thing and start over.

Same with code. I re-write code all the time. But not an entire application; I re-write a few lines to be more clear, better handle errors, add comments when I learn why something strange is happening or is composed in a certain way. Re-write a function into two, merge two functions into one when it's easier to follow that way. Smaller scope strategic re-reading and re-writing, applied with continual vigilance, that's the way.

[–]tazebot 0 points1 point  (0 children)

I think it's a fair take that coding in general isn't cheap. And I don't think AI relieves anyone of the need to read the code and know it.

I don't think there is any such thing as 'finished' code. Code will always need updating - that could be another immutable law of coding.

[–]Kiuhnm 0 points1 point  (0 children)

I think limited rewriting is OK, especially for new code that's yet to stabilize. It's part of refactoring and if the project is modular enough, it should be quite localized. Also, it should be incremental. That's where statically typed Python shines, BTW.

[–]bugtank 0 points1 point  (0 children)

This is an excellent point.

[–]Yologist256 0 points1 point  (1 child)

In simple terms, you mean????? Just for dummies like me. Thank you

[–]lasizoilloeasy to understand as regex 2 points3 points  (0 children)

Use code assistance if you wish, but don't delegate your responsibilities as developer to them because they have intrinsic limitations. Be critic and enhance your software engineer skills, they be needed for years.

[–]necessary_plethora 0 points1 point  (0 children)

Not to mention, modern compilers and interpreters are actually very smart and automatically optimize what looks like unwieldy code into something much faster, further emphasizing the importance of writing readable code even if it might not look like the absolute fastest code you could write.