2
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 May 2024
2 points (100.0% liked)
FreeAssembly
75 readers
1 users here now
this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.
in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.
some posting guidelines apply in addition to the typical awful.systems stuff:
- all types of passion projects and contributions are welcome, including and especially those that aren't programming or engineering in nature
- this is an explicitly noncommercial, share-alike space
- don't force yourself to do work you don't enjoy, or demand it of others
(logo credit, with modifications by @dgerard@awful.systems)
founded 8 months ago
MODERATORS
OK sorry this is rambly but I gotta get these programmer feelings off my chest.... If anything 4 hours is an understatement.
Back in university I once spent an entire week tracking down a latent bug in my program after the professor changed the project requirements a week before the due date. It was an accidental use of
=
instead of a copy in Java. We're talking every waking moment both in and out of class (I was not the best at debugging back then...).Now in the working world there's bugs-- but they're not just my bugs anymore. Rather there's decades of bugs piled on top of bugs. Code has dozens of authors, most of whom quit long ago. The ones that remain often have no memory of the code.
Just last week I did a code review of a co-workers bugfix for a bug introduced in 2008. The fix was non-trivial due to:
So reviewing the code involved comparing every iteration of the code, from the initial commit, up to where the bug was introduced, up to the state it was in today before my coworkers fix, and my coworkers fix. It turns out he got it wrong, and I can't exactly blame him because there is no right in this sort of environment. Fortunately the wrongness was caught by me and whatever meager unit-tests were written for it.
This all took maybe half a day for me, and a day for my coworker, for 1.5 days of work between the two of us. All to fix a condition which was accidentally negated from what it should have been.
And this is indeed what LLM for code enthusiasts miss.
Even if the LLM saves some time with writing boilerplate code, it'll inevitably mess up in subtle ways, or programmers will think the LLM can do more than they actually can. Either way they'll end up introducing subtle bugs; so you have a situation where someone saving 20 seconds here or there leads to hours of debugging effort, or worse, at an unpredictable point in the future.
At least with human written code you can go back and ask them what they were thinking, or read the design doc, or read comments and discussion. Even the most amateurish human author code has the spark of life to it. It was in essense a manifestation of someone's wish.
On the other hand with code that's just statistical noise there's no way to tell what it was trying to do in the first place. There is no will / soul / ego in the code, so there is no understanding, so there is no way to debug it short of reverting the whole change and starting over.