[giberson]

>we leave this version here commented-out, because the code is very complex and likely to have subtle bugs. If bugs _are_ found, it might be of interest to look at the old code and see what did it do in the relevant situation.

Here are two better alternative solutions:

  * comments (in natural language not code) that describe what the code should do
  * test cases: to dictate what code should do and prove it does do it

[ajross]

That's the kind of smug naivete that makes young programmers so insufferable. Your use of "should" in your two sentences is a hidden, inappropriate abstraction. You're positing the existence of a "correct design" for expand-file-name and working backwards to how you'd write it in a modern ground-up development project.

The actual problem at hand was rewriting that function in a way that doesn't break the uncounted thousands of usages in the wild, which depend on the self-described "complex and likely to have subtle bugs" original implementation.

[daenz]

> That's the kind of smug naivete that makes young programmers so insufferable.

That is really toxic language. It's important to call out bad practices where they exist. Not having good comments and test cases for intended behavior is a bad practice. Yes, in the real world, plenty of code gets shipped without adhering to these practices, but it's really unfortunate to see someone talked down on for showing where good practices could have prevented the current circumstances. AFAIK, neither of you have personally written those lines of code, so why is ego getting in the way here?

[eitally]

Because with experience comes internalization of the maxim, "perfect is the enemy of good." Mature programmers get more done and ship more good code than they can remember, while junior programmers are so focused on following perfect standards using perfect frameworks and perfect syntax that they 1) ship very slowly, and 2) belabor every decision, causing even more bugs.

Yes, the language isn't the most ... diplomatic ... but it is also frank & honestly expresses one difference a decade of experience makes for most professional programmers.

[colund]

> Mature programmers get more done and ship more good code than they can remember, while junior programmers

Excellent insight!

[guest1539]

> so why is ego getting in the way here?

I find those kinds of comments insufferable as well, but I'll assume you actually wanted an answer and not just an excuse to chastise someone:

It's because those of us who have learned we don't know everything are annoyed by people who still act like they do know everything. It hurts because we're embarrassed by remembering our younger selves.

[klibertp]

> It's because those of us who have learned we don't know everything are annoyed by people who still act like they do know everything.

This is a beautiful way of explaining this. And so true!

[bobbyi_settv]

The post he's responding to is the equivalent of watching a horror movie from the 70s and asking "why didn't they just use their cell phones?" It's not "important" or helpful to anyone reading this thread.

[lmm]

It is important. Testing was not unknown at the time, and there are still people keeping commented out code around even today.

[TelmoMenezes]

> That is really toxic language.

It's honest communication, something that is becoming increasingly rare in this world of language policing. It's good to be nice to other people, but History as shown us time and again that freedom of speech is a very precious and important thing.

> Not having good comments and test cases for intended behavior is a bad practice.

This might be true, but nobody really knows for sure. There isn't a single development methodology that has been shown by rigorous experiments to be any better than anything else. In this case you have experienced developers doing what they think is best. Emacs is a very old and widely used project. There are very few software projects at that level of sustained impact (which is what actually matters in the end). Some humility might be wise.

[wcummings]

>It's honest communication, something that is becoming increasingly rare in this world of language policing.

It's political correctness gone mad!

/s

[ajross]

> It's important to call out bad practices where they exist

I suppose. But second guessing the development of GNU Emacs in 1984 (let's be clear: a program on the short list of the most successful bits of software ever written in the history of computing) might be a bad place to start if you're trying to avoid embarassing yourself.

RMS was writing this, alone, on a VAX most likely, or maybe a Sun 2 if he was really lucky. What hardware do you expect he would have dedicated to that putative "test suite" even if he had time to write it?

Kids today.

[oh_sigh]

Toxic to whom or to what? Chocolate is toxic to dogs - it doesn't mean that chocolate is dangerous in all circumstances.

[philsnow]

Is there a sector of the community that is okay to ostracize with word choice?

I can't imagine why you would have written,

> Chocolate is toxic to dogs - it doesn't mean that chocolate is dangerous in all circumstances.

if you didn't think that.

[klibertp]

> Is there a sector of the community that is okay to ostracize with word choice?

For sure. I'm an example. And I have a reason for this.

I remember myself from some ten years ago and I remember how far from reality my thinking was. I was largely self-taught, but I read many, many books and even wrote quite a bit of working code. I wish someone told me how naive I was, how mistaken in many areas. Instead, I went on to work - having quite a good luck and joining a very capable, professional team - and was in for the most depressing half a year in my life. All my teammates helped, and gradually I started seeing things in context and learned to appreciate all the accidental complexity and real-life requirements. However, this still was a terrifying experience for me and I'd be much better off, I think, had someone told me, without trying to be unnecessarily polite, how stupid and childish I was BEFORE I went and got bitch-slapped hard (repeatedly) by reality.

So yeah, I have no motivation to do this myself, because young programmers are indeed insufferable, but I cheer for everyone who tries to destroy the false, unfounded confidence of "young programmers". I strongly believe it will be good for these younglings in the long run.

[oh_sigh]

Your post is toxic to me. Please don't ask me what that means.

Or: Sure. How about murderers? They are frequently described as inhuman, barbaric, etc. Was that really the point you were trying to make, or is there something else you are getting at?

[philsnow]

I grant you that it's less bad to ostracize "murderers" than "[insufferable,] young programmers".

That doesn't put ostracizing young programmers in the plus column.

[lamontcg]

And solving the actual problem would be much easier with test cases than an algorithm. This is made ever more important if the original implementation is "complex and likely to have subtle bugs" since that implies that anyone reading the comment is likely to miss 'seeing' important edge cases.

A really simple way to solve this would be to move the simplified algorithm to a test suite which iterated over some important edge conditions and validated that the simplified algorithm and the refactored code agreed. That would preserve the simplified code, but in a much more useful form where automated testing could be done against it.

[supercheetah]

That's assuming that your test cases test for all the subtle little edge cases. That's incredibly naive, and unlikely.

[zeckalpha]

No test suite is complete, however, each test is one better than none. With time, (30 years!) a test suite becomes complete enough to matter, as edge cases are accounted for in the wild.

[mootothemax]

>each test is one better than none

My experience has been the reverse: lots of ultimately pointless tests add nothing to a given codebase but maintenance costs and developer frustration.

The most successful projects I've worked on used (completely automated, no code getting pushed to staging unless the CI server says it passes) tests sparingly.

[lamontcg]

Having a single test for a subtle edge case that can be missed is better than a committer and a reviewer both missing that edge case and committing code that breaks it.

I can't fathom how anyone thinks that documenting the algorithm is better than running the algorithm. The only possible explanation that occurs to me is sociological and that when someone eventually breaks the code which was only documented, you can heap scorn on those who allowed it to be broken because they weren't as smart as you are to be able to see that edge case in hindsight.

Which I guess is 'better'. I'd prefer to have a test that fails. When code breaks an edge case that nobody thought of, I'd add that edge case to the test suite. It will never be perfect, but it will work at least some of the time.

And assuming that test suites must be perfect and complete to be useful is also incredibly naive and a sign of an immature and fairly novice developer. Test suites are always imperfect, you must always guard against them and not assume they do everything for you, and yet you need to take the time to build them and maintain them since they make your code quality better when they do catch edge conditions where you weren't smart enough to see your own bugs you were introducing.

I guess some programmers are just smart enough to never commit buggy code though and don't need them...

[draw_down]

> That's the kind of smug naivete that makes young programmers so insufferable.

You said it.

[Johnny555]

That might be workable idea if the guy writing the replacement code has such a perfect understanding of the original code that he can spell out every assumption and edge condition that the code covers (as well as write tests to cover all conditions). The best you can hope for is comments and tests that cover the new author's impression of what the old code was doing, which is not necessarily the same as what the old code did.

In this case, since he apparently doesn't feel that he has that perfect understanding, he left the original code there, so when someone says "Hey! I counted on behavior XXX, this change broke my workflow!".

And any change no matter how trivial or "correct" always breaks someone's workflow.

https://xkcd.com/1172/

[pyre]

You missed:

* Comments referencing the original code by date / version / commit id. Date and version are relevant because the comment might not get updated if there is ever another VCS migration.

[bastawhiz]

It's a bit ironic that there's a longer comment describing why the code shouldn't be removed than there are comments describing what the code _actually does_ or _why_ inline.

[eximius]

I wonder what the most complex algorithm you've ever implemented was. The most complex I ever implemented was a toy crypto system that I implemented first naively, then again with simple optimizations. In neither case was there a simple way to describe what the code should do because it was inherently complex.

[woah]

Good thing it was a toy.

[keyle]

Only comment if the code is doing something tricky, or unclear and has been written in such a way for a reason worth noting.

Don't write comments about what the code should do. If you have to write something, comment on the domain/context, not the code.

[reddytowns]

How about:

The old version of this code is under source-control <here>. The code is very complex and likely to have subtle bugs. If bugs _are_ found, it might be of interest to look at the old code and see what did it do in the relevant situation.

[gaius]

Where is <here> and will it always be there?

[V-2]

What is "always" and do we have to care about always? Sounds like splitting hairs to me.

Even the comment in question admits: "it's true that it will be accessible from the repository".

Only then it goes on to say "but a few years from deletion, people will forget it is there" - well, then just leave a comment reminding them about it.

I see no plausible reason for keeping dead, commented out code in the codebase when you've got VCS.