The official unpopular opinions thread
-
OneNote is a fantastically designed program with tons of useful features, provided you use the desktop version and not the terrible UWP version.
-
@anonymous234 I don't think that's an unpopular opinion among people who actually used it.
-
Time to necro this thread, since this is not actually a programming confession:
@dfdub said in Not Dates, but Hours:
Confession: I actually like checked exceptions.
I honestly do. Yes, they're sometimes annoying to deal with, but the exception specification is an important part of every API. In languages without checked exceptions, you still have to document your exception types as a library author and hope that the library documentation is accurate as a library user without getting any help from the compiler. I don't understand why people prefer that.
-
Unpopular opinion: Final Fantasy: Spirits Within was a good movie. Would have been better if they pulled the "Final Fantasy" name, but
-
@Benjamin-Hall I haven't played any of the Final Fantasies, but I have enjoyed the movie.
-
Both the Clone Wars and Rebels are better than most of the Star Wars movies.
-
@Captain Unfortunately, "better than most of the Star Wars movies" is a bar that is getting easier and easier to pass.
-
@remi said in The official unpopular opinions thread:
@Captain Unfortunately, "better than most of the Star Wars movies" is a bar that is getting easier and easier to pass.
Well, I think the prequels are the worst. The new trilogy has been okay so far.
Clone Wars and Rebels are good, and frequently awesome.
-
@Captain said in The official unpopular opinions thread:
Well, I think the prequels are the worst. The new trilogy has been okay so far.
-
The recent outlook update has made it's ux much better than gmail and I think I might start forwarding my emails to it. Also Word and Excel beat the shit out of sheets and docs and are worth the price of admission. If only they would include planner in the their home package.
-
@dfdub said in The official unpopular opinions thread:
Time to necro this thread, since this is not actually a programming confession:
@dfdub said in Not Dates, but Hours:
Confession: I actually like checked exceptions.
I honestly do. Yes, they're sometimes annoying to deal with, but the exception specification is an important part of every API. In languages without checked exceptions, you still have to document your exception types as a library author and hope that the library documentation is accurate as a library user without getting any help from the compiler. I don't understand why people prefer that.
I've never used a Java library with checked exceptions and thought "it's super awesome they have checked exceptions!" I'd probably be more annoyed their checked exceptions are going to pollute my code with either my own checked exception declarations or boilerplate wrapping with a RuntimeException of some sort.
To be fair I can see how it's a good idea. But the way it's done in Java is pretty awful. It strongly encourages (not intentionally) bad exception handling where people wrap or eat them. As implemented, it also doesn't let me have valid piece of code that doesn't care what exceptions come out of it and just want its parent scope to deal with it.
Maybe if the "must handle all declared exceptions" rule was only enforced at a public member level? Still would require the gross throws clause but wouldn't encourage the bad exception handling.
I've never felt limited by scala, C#, kotlin, etc. with their lack of checked exceptions.
-
@mikehurley said in The official unpopular opinions thread:
wrapping with a RuntimeException of some sort
Wrapping it? Why not, if it makes your API cleaner. But not in a RuntimeException.
I've never felt limited by scala, C#, kotlin, etc. with their lack of checked exceptions.
Well, there's a reason why I posted this opinion in this thread.
But recently, I ran into a static code analysis tool that produced a bunch of warnings about missing
@throws
annotations in a library I inherited. Which caused me to think about why people think this is better than checked exceptions. I guess the difference is that - as you proposed - they only need to be documented for public methods, but it still seems stupid to move that functionality out of the compiler.
-
@M_Adams Speaking of cats...
WTF of my day:
CATS - Official Trailer [HD] – 02:25
— Universal PicturesI'm okay with this.
-
The newest season of the Simpsons is the best season.
-
@dfdub said in The official unpopular opinions thread:
@mikehurley said in The official unpopular opinions thread:
wrapping with a RuntimeException of some sort
Wrapping it? Why not, if it makes your API cleaner. But not in a RuntimeException.
That's why I said "of some sort". I didn't mean you should literally throw a RuntimeException, but one of its subclasses.
To be fair, I would throw a straight RE instead of making my own. My own class wouldn't grant any special information and in my experience 95% of the time I'm going to log the exception and crash the program or move on to the next record. So I want a good exception message but I generally don't care about the type in code I/the company write. Unless it is a situation needing special handling and I'll make a new exception type.
But if I'm going to just wrap the exception, and not do any handling besides the wrapping, seems unnecessary and just clutters the code.
-
@pie_flavor said in The official unpopular opinions thread:
@Captain said in The official unpopular opinions thread:
Well, I think the prequels are the worst. The new trilogy has been okay so far.
The people who seem to be upset about the new trilogy are a set that's closely related to the set of people who know who Admiral Thrawn is and care.
-
@mikehurley said in The official unpopular opinions thread:
But if I'm going to just wrap the exception, and not do any handling besides the wrapping, seems unnecessary and just clutters the code.
Actually thinking about the failure modes of a program isn't unnecessary.
-
@dkf said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
@Captain said in The official unpopular opinions thread:
Well, I think the prequels are the worst. The new trilogy has been okay so far.
The people who seem to be upset about the new trilogy are a set that's closely related to the set of people who know who Admiral Thrawn is and care.
The new trilogy completely sucked. Not as Star Wars movies per se, just generally as movies.
-
@dkf said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
@Captain said in The official unpopular opinions thread:
Well, I think the prequels are the worst. The new trilogy has been okay so far.
The people who seem to be upset about the new trilogy are a set that's closely related to the set of people who know who Admiral Thrawn is and care.
I don't know who that is, but I want to read it as "Admiral Prawn." Come to find out, I'm not the first to think of that.
-
the command line is a shitty UI because if you hit the wrong key nothing works
-
I don't like Star Wars and can't stand listening about it.
-
I really don't get what's so good about The Godfather. It barely even seemed coherent.
-
@pie_flavor Maybe this will help make it accessible to someone of your generation
-
@dkf said in The official unpopular opinions thread:
@mikehurley said in The official unpopular opinions thread:
But if I'm going to just wrap the exception, and not do any handling besides the wrapping, seems unnecessary and just clutters the code.
Actually thinking about the failure modes of a program isn't unnecessary.
Agreed...? I also don't think every helper function is the place to do it. Most exception handlers are going to be log and rethrow/crash or log and process the next thing. In the vast majority of code you may treat 1, maybe 2, exception types as special (retry socket connections, retry database transactions, etc), almost all will be handled as a single "something bad happened" and be handled by generic failure logic.
-
@mikehurley said in The official unpopular opinions thread:
log and rethrow
I used to write code like that; I don't now. When you find that you've logged the same exception about ten times on the way out of a failed system call, each time with a full stack trace and so on, you quite rapidly get very bored of reading your log full of the same information repeated over and over. Don't log unless you're actually handling the failure in some way other than rethrowing (whether wrapped or otherwise); an exception ought to be logged at most once, no more.
-
@dkf said in The official unpopular opinions thread:
@mikehurley said in The official unpopular opinions thread:
log and rethrow
I used to write code like that; I don't now. When you find that you've logged the same exception about ten times on the way out of a failed system call, each time with a full stack trace and so on, you quite rapidly get very bored of reading your log full of the same information repeated over and over. Don't log unless you're actually handling the failure in some way other than rethrowing (whether wrapped or otherwise); an exception ought to be logged at most once, no more.
Hear hear. Log fatigue is a very real thing, so I do have to remind all the devs over here that you need just enough logging, not too much and not too few.
-
@dkf said in The official unpopular opinions thread:
@mikehurley said in The official unpopular opinions thread:
log and rethrow
I used to write code like that; I don't now. When you find that you've logged the same exception about ten times on the way out of a failed system call, each time with a full stack trace and so on, you quite rapidly get very bored of reading your log full of the same information repeated over and over. Don't log unless you're actually handling the failure in some way other than rethrowing (whether wrapped or otherwise); an exception ought to be logged at most once, no more.
Yes? Why would I log it multiple times? Usually main()/run() or some other higher level piece of code handles exceptions that generically come out. Why would you ever log at each and every level? That's terrible.
Once an exception hits that high level handler your app is pretty much dead so the rethrow is just to make it crash. You could also do an explicit exit call, but either way your app is dead at that point.
But yes, if you're in the lower level "do stuff" code you should only catch something if you're going to do something about the problem (db reconnect, etc).
-
@mikehurley Better yet, just use a try with no catch clause!
-
Someone suggested this, finally.
-
@Zecc He just threw that out there
-
@JBert said in The official unpopular opinions thread:
Hear hear. Log fatigue is a very real thing, so I do have to remind all the devs over here that you need just enough logging, not too much and not too few.
That Goldilocks zone can be very difficult to find. Most things I write have a verbose logging mode (usually verbose=11) that dumps everything I can think of into a log. For those times when you have no fing clue why something is failing.
-
@mikehurley said in The official unpopular opinions thread:
Why would you ever log at each and every level? That's terrible.
While not the best solution to the problem of: https://stackoverflow.com/questions/15668334/preserving-exceptions-from-dynamically-invoked-methods it did work.
-
@Dragoon said in The official unpopular opinions thread:
That Goldilocks zone can be very difficult to find.
QFFT!
Most things I write have a verbose logging mode (usually verbose=11) that dumps everything I can think of into a log. For those times when you have no fing clue why something is failing.
I resemble that. It's particularly fun when you can only capture the logs of the failures in production because they simply don't happen at all in test let alone when you have a debugger attached. (In one case earlier this year for me, that was because the test environment was on a different subnet to production, and the trigger of the failure was broadcast packets from other hardware on the prod subnet. That was hell to trace down!)
-
@Dragoon What we need is a thing that logs everything internally, and can stop execution at a certain point and let you play back and review every line of code executed.
Allow me to rephrase: why the fuck don't we have that?
-
@anonymous234 said in The official unpopular opinions thread:
@Dragoon What we need is a thing that logs everything internally, and can stop execution at a certain point and let you play back and review every line of code executed.
Allow me to rephrase: why the fuck don't we have that?
It exists, but you needed to be recording at the time of the crash and it is expected that it introduces noticeable overhead.
-
@JBert said in The official unpopular opinions thread:
it is expected that it introduces noticeable overhead.
That is an understatement.
-
@Dragoon especially since the requirement of executing line by line disallows reordering, and that kills 90% of compiler optimizations.
-
@Gąska said in The official unpopular opinions thread:
that kills 90% of compiler optimizations
Performance is killed by two things: branch misprediction and value boxing/unboxing. And, in particularly poor implementations, repeated symbol lookup. Those are the cost that utterly hammer bytecode engines. (Straight interpreters also have a bonus parsing cost that's another order of magnitude of performance drain.)
Strict ordering isn't as big a deal as it only needs to be respected where the results of being non-strict would be observable.
-
@dkf said in The official unpopular opinions thread:
Strict ordering isn't as big a deal as it only needs to be respected where the results of being non-strict would be observable.
And when you track execution line by line, this need goes from "almost never" to "literally all the time".
-
@Gąska said in The official unpopular opinions thread:
And when you track execution line by line
You mean, when you (presumably intentionally) turn on a mode that explicitly says that every operation is observable and so make operation reordering not permissible?
-
I unironically like Javascript.
-
@dkf said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
And when you track execution line by line
You mean, when you (presumably intentionally) turn on a mode that explicitly says that every operation is observable and so make operation reordering not permissible?
It's as if you didn't even read the context of what you were replying to and didn't notice @anonymous234 saying "play back and review every line of code executed".
-
@error said in The official unpopular opinions thread:
I unironically like Javascript.
Was it your first programming language? Because that's the only explanation, aside from clinical insanity.
-
@Gąska or you can like the prototype model and have never heard of Lua before.
-
@pie_flavor said in The official unpopular opinions thread:
or you can like the prototype model
Fun fact: If you don't have a crucifix handy, you can easily detect vampires by asking if they like the prototype model
-
@pie_flavor the first programming language is special for every programmer. It's what initially shapes their mind, and they absorb all its idiosyncrasies as normal. All later languages are then subconsciously compared to their first, and that makes flaws in all of them much more apparent. JS's prototype inheritance model might be cool (not to be confused with good), but all the glaring defects in the language overall grossly outweigh any benefits it might give, and it's very obvious right from the beginning - that is, unless it's your first language. Same as C++ and RAII - it used to be about the only language that has done it right, but it got so many other things wrong that it hardly matters. Even though personally, I don't really find it all that bad - but as you might've guessed, it's because it was my first language. If this wasn't the case, I'd stay as far away from it as I could to preserve any remnants of sanity I'd still have (like I do now with JS or Perl).
-
@Gąska my first language was TRS-80 BASIC and my first 'real' language was Java and I hate both of them thoroughly and most of their features and use vastly superior languages wherever possible.
-
@pie_flavor of course, as I should've mentioned, what I said might not apply for people born on Earth-73.
More seriously - I didn't mean that everyone loves their first language unconditionally (I actually hate C++ quite a lot!) Mostly, I meant that if someone genuinely likes JS despite all its flaws... Well, JS has way too many flaws in important areas for this to ever happen naturally. Pretty much the only way not to be strongly repulsed by them is not to know that those things are bad and that they could've been done much better.
-
-
@Gąska said in The official unpopular opinions thread:
It's as if you didn't even read the context of what you were replying to and didn't notice @anonymous234 saying "play back and review every line of code executed".
Quite apart from the usual …
Maintaining a full recording and rollback capability is expensive as it requires saving a lot of states that were previously transient. The memory (or storage) requirements of this are non-trivial, easily exceeding the size of physical memory once programs get remotely interesting, to the point where the cost of doing all that extra work will probably dominate the running of the program in that mode. (Yes, this is a BTDT case. )