Live data from Hacker News

This should never happen

github.com

201–210 of 214 posts

Re: This should never happen

#201
post #155

Earlier quoted context omitted.

getBytes is poorly designed. In a safety-oriented language like Haskell or Rust, the set of encodings would be represented as an ADT (which forms a closed set) or s Typeclass (open set). All possible type-correct encoding arguments would be safe.

Speaking to the Haskell part: An ExceptT or Maybe monad for handling encoding errors feels a lot like throwing exceptions, although they are less disruptive than exceptions. I'd probably represent a decoder as a function with type ByteString -> ErrorT ParseError m Text, which is neither an ADT or Typeclass. It's a 3rd solution. Either that or an Attoparsec parser, which is probably equivalent. An encoder seems like i…

In Rust, our main two string types are String and &str, which are both UTF-8 encoded. For interoperability with other things, we have additional types that you can convert to/from. http://andrewbrinker.github.io/blog/2016/03/27/string-types-... is a recent overview in a blog post.

Re: This should never happen

#202
post #154

Earlier quoted context omitted.

My favorite commit message of all time: https://core.trac.wordpress.org/changeset/26851 --- The Pinking Shears stir from their slumber, awakened by what may seem, to those innocent in the ways of The Shears, a triviality, a nothing-of-consequence. But there are consequences indeed for recklessly trailing your whitespace. Naturally, they a dire! One, two! One, two! And through and through The Pinking Shears went snick…

It doesn't surprise me that someone that would make a change like that would leave a comment like that. They removed a trailing space from a comment! They have plenty of free time to write witty check-in comments.

I definitely aim to remove things like that, but I tend to sneak it in with something else (partly because the fix likely came as soon as I used an editor properly configured to strip it).

I'm not sure if that's a 'bad' practice or just not the purest. But I don't think removing trailing comment space is bad in itself. As above, it probably didn't take any time at all; done automatically by a well-configured editor.

Re: This should never happen

#203
post #147
post #125

Earlier quoted context omitted.

In case anyone looks at that and thinks it's cute or clever or fun... it's not. People will end up hating you for doing that. Okay, maybe hate is too strong, but it will certainly engender some strong negative feelings in anyone who has to try to figure out what you did (and when and why you did it).

Agreed. A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them. If a developer consistently pushes commits like this, they should be guided by their team lead to understand thei…

    > But then rebase, squash, and edit the commits before
    > sharing them.
And then realise that doing it properly in the first place most definitely would not have been a slow-down!

Re: This should never happen

#204
post #147
post #125

Earlier quoted context omitted.

In case anyone looks at that and thinks it's cute or clever or fun... it's not. People will end up hating you for doing that. Okay, maybe hate is too strong, but it will certainly engender some strong negative feelings in anyone who has to try to figure out what you did (and when and why you did it).

Agreed. A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them. If a developer consistently pushes commits like this, they should be guided by their team lead to understand thei…

    > But then rebase, squash, and edit the commits before
    > sharing them.
And then realise that doing it properly in the first place most definitely would not have been a slow-down!

Re: This should never happen

#205
post #203
post #147

Earlier quoted context omitted.

Agreed. A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them. If a developer consistently pushes commits like this, they should be guided by their team lead to understand thei…

> But then rebase, squash, and edit the commits before > sharing them. And then realise that doing it properly in the first place most definitely would not have been a slow-down!

This is pretty simple to do outside of die-hard "continuous integration" shops -- most of the time I can just do git rebase -i HEAD~4 (where '4' is the number of little dumb commits I made) and squash them all into the first commit.

But if I made a few commits, then pulled in someone's changes, then made a few more... well... http://xkcd.com/1597/

Re: This should never happen

#206
post #86

Earlier quoted context omitted.

I preserved for posterity a colleague's unique commit style: https://gist.github.com/rcarmo/c671555169abbae83a1a

> 88642ba Fix all the conflicts > fbd2658 Conflict all the fixes Sounds like some amount of made-up work!

Merge conflicts never end when I think they will.

Re: This should never happen

#207

Earlier quoted context omitted.

It's a sub-pattern of "ain't got time for dat". Developer knows that condition should never happen, but is not inclined to prove it (as represented by coding type checking or other handling) yet realizes it shouldn't be ignored outright (if only to document the unproven condition in code, or to shut the compiler up about incompleteness warnings).

> It's a sub-pattern of "ain't got time for dat". Disagree on this. It has nothing to do with efficiency in context of unlikely events. As others have noted here, it is effectively an assertion of expected language/system/operating-environment properties. Think axioms .

No, I'm primarily thinking of "ain't got time for dat", as in "there's a very real deadline, I have a lot of other things to get done, and this case isn't ever going to happen and I don't have time to prove it to the compiler."

Re: This should never happen

#208

Earlier quoted context omitted.

You could always put a "this should never happen" right before the swear words so they know it wasn't your fault.

But there's a risk I'll become stuck in an infinite loop of writing shit! this should never happen shit! this should never happen shit! ... and so on. Still it would be a change from writing bad code.

Wow, deja-vu, this is just what happened to me one time when I was working on a new booking system for a hotel.

I was working on site over the winter season when the hotel was closed down, a lovely old hotel high up in the Rockies. Every day I sat down and wanted to write some brilliant code but all I ever ended up writing was the same comment

All objects and no functions makes Jack a dull boy. over and over again.

Drove me quite mad actually.

Sometimes I feel like I'm still there.

Re: This should never happen

#209
post #71

Earlier quoted context omitted.

amazing waste of time that is, of everybody, the commit authors and the people spending time looking them up and making slides out of them. And lets not forget the waste of space on HN regarding this referral post.

I bet you're a blast at parties

And youR* reply is about as useful as the whole thread, the reporting of other peoples laziness of committing with proper descriptions of their own code. What a surprise, people are lazy and it bites you in the ass in the long run wowiwow, what a surprise...

Perhaps if this type of post didn't come by every X time, it wouldn't annoy me so much.

Re: This should never happen

#210

My favorite example of a "this should never happen" error was when I got a call from a customer, who started the conversation by asking, "Who is Brian?". I was caught a bit off guard, but I assumed the customer must know someone at the company, since Brian was the name of the previous electrical engineer/firmware programmer. So, I told them that Brian didn't work here any more, but was there anything that I could hel…

Seems like Brian :) https://github.com/OpenLiveWriter/OpenLiveWriter/commit/1236...
Post reply on HN