The official unpopular opinions thread

[Zerosquare]

You're wearing red-tinted glasses!

[boomzilla]

@_P_ said in Suggest appropriate goals for a super-basic Python class (HS level):

OO and SQL are fun?

SQL is definitely fun! I think trying to figure out a tricky query is my favorite part of this job.

[_P_]

Shower thought: Refactoring is bad.

If you refactor logic code that are used in different places, more often than not they actually require doing things slightly differently, which means you either have to pass in a control which obscures what your function is actually doing, or create different implementations which defeats the purpose of refactoring in the first place (not to mention your code is now one step closer to Enterprise Java Bloat ), or writing adapters at the input/output to adapt to additional changes which means you're wrapping on a wrapper, which is also one step closer to Enterprise Java Bloat .

If you refactor "constants", it remains to be see whether it actually worths it. Like people who think that writing String.Empty is "clearer" than just putting "" there. And some people prefer to do it by putting const instead of readonly, which is equivalent to telling the compiler to inline every reference with the specified value, aka not refactoring.

If you refactor tiny snippets of utility functions, you often end up wrapping built-in functions and re-inventing the wheel. And what're you gonna do if you need to use the same utility functions you wrote in a different project? Copy the entire code/refer to the entire library? That sounds like you've made this more WTF than it was before refactoring!

If you refactor code that would be accessed by many other places in different threads, you may encounter race condition issues due to multi-threading. Then you have to put a mutex/lock on your refactored code which makes things slower than before the refactoring.

Finally, refactoring by turning common expressions into functions introduces performance overhead because of additional function calls, and if you annoy the compiler too much on this regard it'll just inline your refactored function anyway, undoing your work.

Anyone here to change my mind?

[MrL]

@_P_ said in The official unpopular opinions thread:

Finally, refactoring by turning common expressions into functions introduces performance overhead because of additional function calls, and if you annoy the compiler too much on this regard it'll just inline your refactored function anyway, undoing your work.

Anyone here to change my mind?

Well, for one, you extract common behavior to functions to avoid errors coming from reimplementation, to ensure same results, to make code more compact and readable. So it's done for humans - how it looks after compilation doesn't matter.

[Zecc]

@_P_ said in The official unpopular opinions thread:

If you refactor "constants", it remains to be see whether it actually worths it.

I just created an enum for contants without any plans on ever changing their values.

They now read DataMasticationSuccess, DataMasticationRunning and DataMasticationError instead of 0, 1, 2.

You're welcome.

[_P_]

@MrL said in The official unpopular opinions thread:

@_P_ said in The official unpopular opinions thread:

Finally, refactoring by turning common expressions into functions introduces performance overhead because of additional function calls, and if you annoy the compiler too much on this regard it'll just inline your refactored function anyway, undoing your work.

Anyone here to change my mind?

Well, for one, you extract common behavior to functions to avoid errors coming from reimplementation, to ensure same results, to make code more compact and readable. So it's done for humans - how it looks after compilation doesn't matter.

Copy-pasting surgery seems perfectly fine too though, no? In addition, it allows fine-grained control over which part of behaviour to replicate. It's better than copying an existing function that you cannot (forbid or unable to) modify and then try to do adapter hackeries to make it work for your particular case, aka the situation I mentioned.

[_P_]

@Zecc said in The official unpopular opinions thread:

@_P_ said in The official unpopular opinions thread:

If you refactor "constants", it remains to be see whether it actually worths it.

I just created an enum for contants without any plans on ever changing their values.

They now read DataMasticationSuccess, DataMasticationRunning and DataMasticationError instead of 0, 1, 2.

You're welcome.

"Without any plans on ever changing their values" is a very bold statement. Is your enum boolean? Even they aren't immune to the FileNotFound value.

Not to mention that these aliases only make sense to your source code: if I'm calling your CRUD REST API or querying your database, how am I supposed to know what 0, 1, 2 mean? Which proves my point: if you're using integers as enums they don't make sense to anyone else but your source code (because it has the mapping); and if you use strings (assuming it's even possible in the first place because strings as enums are typically not possible), you're really defining constants more than enums, not to mention that the strings would probably be success, running and error, which are shorter and still descriptive, so by not refactoring them into strings you reduce the bloat.

[Zecc]

@_P_ said in The official unpopular opinions thread:

Copy-pasting surgery seems perfectly fine too though, no?

No. It really doesn't.

@_P_ said in The official unpopular opinions thread:

"Without any plans on ever changing their values" is a very bold statement. Is your enum boolean?

No, it's a bunch of const ints in my class.

@_P_ said in The official unpopular opinions thread:

if you're using integers as enums they don't make sense to anyone else but your source code

It's not my source code. It's source I inherited. And because I'm not an asshole, I don't want the next person having to waste time same as I have digging up what every number means.

@_P_ said in The official unpopular opinions thread:

and if you use strings (assuming it's even possible in the first place because strings as enums are typically not possible), you're really defining constants more than enums, not to mention that the strings would probably be success, running and error, which are shorter and still descriptive, so by not refactoring them into strings you reduce the bloat.

This is what I would have done if I had been the one starting this project. As it is though, the best I can do is... refactor.

[MrL]

@_P_ said in The official unpopular opinions thread:

Copy-pasting surgery seems perfectly fine too though, no?

Nope.

In addition, it allows fine-grained control over which part of behaviour to replicate. It's better than copying an existing function that you cannot (forbid or unable to) modify and then try to do adapter hackeries to make it work for your particular case, aka the situation I mentioned.

Functions must have clearly defined behavior. If you want different effects it's either different function or existing one should be parametrized.

[_P_]

This post is deleted!

[Tsaukpaetra]

@_P_ No no no, what did you say? I wanna know!

[_P_]

@Tsaukpaetra said in The official unpopular opinions thread:

@_P_ No no no, what did you say? I wanna know!

TIL NodeBB doesn't handle multiple concurrent replies well.

[Tsaukpaetra]

@_P_ said in The official unpopular opinions thread:

@Tsaukpaetra said in The official unpopular opinions thread:

@_P_ No no no, what did you say? I wanna know!

TIL NodeBB doesn't handle multiple concurrent replies well.

Ah, yes. You want the Bugs category, but by default it auto-selects Meta. That's happened to me on occasion, but never fear! Mods are sleeping!

[Tsaukpaetra]

Status: Fuck, based on the lack of green in this thread I haven't read it at all. Well, there goes my last-read-bookmark...

[_P_]

@MrL said in The official unpopular opinions thread:

In addition, it allows fine-grained control over which part of behaviour to replicate. It's better than copying an existing function that you cannot (forbid or unable to) modify and then try to do adapter hackeries to make it work for your particular case, aka the situation I mentioned.

Functions must have clearly defined behavior. If you want different effects it's either different function or existing one should be parametrized.

1. If it belongs to a different function, that's not really refactoring as you're just pulling a block of code into a function that hasn't been used multiple times yet; and if said function is only seldom called then my point applies.
2. If several different, similar blocks of code are refactored into a single parametrized function, in lots of cases the function is now entangled with multiple different possible code flow. Now you have a function that is difficult to traverse all possible code flows and achieve 100% code coverage because of the combinatorial explosion in the parameters and possible branches; not to mention that most of the combinations are probably irrelevant and unused anyway.
3. So, let's modularize the differing parts of the code, right? Then the level abstraction goes through the roof and it takes much more effort to write and use such code (see: Enterprise Java Bloat). It's simply not worth doing this unless the reward is big enough to justify it.

So, I dunno, everyone says that copy-pasting code is bad and they should be refactored, but the arguments don't quite hold water. At least to my shower thought brain atm anyway.

[PleegWat]

@_P_ Sometimes there are patterns you simply need to repeat. Recognising which frequently-occurring pieces of code are patterns you should repeat and which ones you should refactor out is part of what makes a good programmer.

Your refactorings being inlined back out by the compiler is a good thing. The point of refactoring is to make the source easier to maintain. I'd rather have a 4kloc source file with one entry point contain a dozen or so functions than just a single one, even if a single call of the function results in all code running exactly once anyway. It forces separation, and to document the internal interfaces which a file that large will have.

My codebase contains a constant SECONDS_PER_DAY, with value of 86400. That's not ever going to change. And the compiler is going to inline it everywhere (especially since it's a C #define). It was simply the opinion of that developer that SECONDS_PER_DAY is more readable than 86400 or (24*60*60).

If your entire codebase is only a few thousand lines, you probably won't ever have run into all of this.

[MrL]

@_P_ said in The official unpopular opinions thread:

@MrL said in The official unpopular opinions thread:

In addition, it allows fine-grained control over which part of behaviour to replicate. It's better than copying an existing function that you cannot (forbid or unable to) modify and then try to do adapter hackeries to make it work for your particular case, aka the situation I mentioned.

Functions must have clearly defined behavior. If you want different effects it's either different function or existing one should be parametrized.

1. If it belongs to a different function, that's not really refactoring as you're just pulling a block of code into a function that hasn't been used multiple times yet; and if said function is only seldom called then my point applies.
2. If several different, similar blocks of code are refactored into a single parametrized function, in lots of cases the function is now entangled with multiple different possible code flow. Now you have a function that is difficult to traverse all possible code flows and achieve 100% code coverage because of the combinatorial explosion in the parameters and possible branches; not to mention that most of the combinations are probably irrelevant and unused anyway.
3. So, let's modularize the differing parts of the code, right? Then the level abstraction goes through the roof and it takes much more effort to write and use such code (see: Enterprise Java Bloat). It's simply not worth doing this unless the reward is big enough to justify it.

So, I dunno, everyone says that copy-pasting code is bad and they should be refactored, but the arguments don't quite hold water. At least to my shower thought brain atm anyway.

To me it sounds like you do refactoring badly. Extracted code should be common, single purpose and short. Parametrization, if needed, should be simple and limited. If you get complexity explosion, you're doing it wrong - it should be multiple functions, or helper object, or a full service.

And yes, extracting code to a function that will be called from few places, even one, is good refactoring. It encapsulates functionalities in their own units and makes code a lot more readable.

[Zerosquare]

@_P_ said in The official unpopular opinions thread:

the arguments don't quite hold water. At least to my shower thought brain atm anyway.

I didn't expect to write that one day, but I think you should take fewer showers.

[HardwareGeek]

@Tsaukpaetra said in The official unpopular opinions thread:

never fear! Mods are sleepkneeling!

FTFKW

[dcon]

@Zecc said in The official unpopular opinions thread:

@_P_ said in The official unpopular opinions thread:

If you refactor "constants", it remains to be see whether it actually worths it.

I just created an enum for contants without any plans on ever changing their values.

They now read DataMasticationSuccess, DataMasticationRunning and DataMasticationError instead of 0, 1, 2.

You're welcome.

You're a good person. Though in C++, I'd instead do:

enum class DataMastication
{
    Success,
    Running,
    Error
};

[HardwareGeek]

@PleegWat said in The official unpopular opinions thread:

My codebase contains a constant SECONDS_PER_DAY, with value of 86400.

Leap seconds.

[PleegWat]

@HardwareGeek Those are localtime seconds. Guess what the number of seconds in a DST change day is

[djls45]

@pie_flavor said in The official unpopular opinions thread:

I really don't get what's so good about The Godfather. It barely even seemed coherent.

I've never even seen it.

[djls45]

@hungrier said in The official unpopular opinions thread:

@pie_flavor Maybe this will help make it accessible to someone of your generation

But was he defenstrated? There's little point to yeeting if it's not also a defenestration.

[djls45]

@mikehurley said in The official unpopular opinions thread:

@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).

The (server-level) (Java) program that I work with uses exceptions for control flow in the user-level failure cases. No exception will ever reach the point that the whole app crashes (or rather, it shouldn't ever – I've seen it happen a few times). I have access to only certain parts of the system, so logging the exception when and where I can may be the only logging that occurs, because a few levels above my access, the exception is simply eaten and ignored while processing resumes as if the user hadn't attempted to start an action, i.e. as if nothing had happened.

[djls45]

@Zecc said in The official unpopular opinions thread:

@Rhywden said in WTF Bites:

@M_Adams Speaking of cats...

WTF of my day:

https://youtu.be/FtSd844cI7U

I'm okay with this.

2:09-2:12
"HEIL!!"

[djls45]

@Polygeekery said in The official unpopular opinions thread:

I don't care what anyone says, 'Polar Express' is creepy as fuck. -shudders-

I've never seen the movie, but in the previews and ads for it, the CGI people look like they crawled out of the bottom of the uncanny valley.

[djls45]

@PleegWat said in The official unpopular opinions thread:

My codebase contains a constant SECONDS_PER_DAY, with value of 86400. That's not ever going to change.

Doesn't it change on two days out of every year with daylight savings?

@PleegWat said in The official unpopular opinions thread:

Guess what the number of seconds in a DST change day is

Spring forward (northern hemisphere) => 23-hour day = 82800 seconds
Fall back (northern hemisphere) => 25-hour day = 90000 seconds

[JBert]

@_P_ said in The official unpopular opinions thread:

Shower thought: Refactoring is bad.

If you refactor logic code that are used in different places, more often than not they actually require doing things slightly differently, which means you either have to pass in a control which obscures what your function is actually doing, or create different implementations which defeats the purpose of refactoring in the first place (not to mention your code is now one step closer to Enterprise Java Bloat ), or writing adapters at the input/output to adapt to additional changes which means you're wrapping on a wrapper, which is also one step closer to Enterprise Java Bloat .

If you refactor "constants", it remains to be see whether it actually worths it. Like people who think that writing String.Empty is "clearer" than just putting "" there. And some people prefer to do it by putting const instead of readonly, which is equivalent to telling the compiler to inline every reference with the specified value, aka not refactoring.

If you refactor tiny snippets of utility functions, you often end up wrapping built-in functions and re-inventing the wheel. And what're you gonna do if you need to use the same utility functions you wrote in a different project? Copy the entire code/refer to the entire library? That sounds like you've made this more WTF than it was before refactoring!

If you refactor code that would be accessed by many other places in different threads, you may encounter race condition issues due to multi-threading. Then you have to put a mutex/lock on your refactored code which makes things slower than before the refactoring.

Finally, refactoring by turning common expressions into functions introduces performance overhead because of additional function calls, and if you annoy the compiler too much on this regard it'll just inline your refactored function anyway, undoing your work.

Anyone here to change my mind?

The big problem is that "refactoring" means different things to different people. I've known at least one dev who said "refactoring" when he meant "rewrite it from scratch". I would have prefered if he started from a copy which he could then mutilate in any way he saw fit rather than throwing away good code.

As for pulling out reusable logic, I tend to go with the "rule of three" which Jeff once posted an article about (back in the day he posted so much stuff that like a broken clock he had to be right at least once in a while). For everything else you just pull out logic into private function if and when they make sense. Copy/pasting is thus not an immediate issue as long as you are aware that you need to check for exact duplicates every once in a while (especially if copies are complex and fautly enough that they start showing similar bugs).

Inlining constants is not a problem as long as your assemblies / modules are not meant to be replaced with different versions at runtime. You're not programming for someone with ILDASM (or any other disassembler / byte code viewer), you are meant to keep the code readable for your future amnesiac self and your poor innocent co-workers. (Also, use of String.Empty might be for those who distrust string interning)

Then the thing about multi-threading needing locks... Why would you refactor something with shared state into a reusable bunch of code? The fact that it has shared state would indicate that it is not reusable as a whole, it would at the least need to be turned inside out so that keeping state is the responsibility of the threads themselves.

Finally, if the overhead of additional function calls matters that much to you in terms of performance then you should already have setup a performance test to see how close you are to a given goal. You can then refactor until the code is readable, then go back to see if you can hit that goal spot-on while keeping things readable. Going for "damn fast but nearly undecipherable" should always be the last choice.

[PleegWat]

@djls45 said in The official unpopular opinions thread:

@PleegWat said in The official unpopular opinions thread:

My codebase contains a constant SECONDS_PER_DAY, with value of 86400. That's not ever going to change.

Doesn't it change on two days out of every year with daylight savings?

@PleegWat said in The official unpopular opinions thread:

Guess what the number of seconds in a DST change day is

Spring forward (northern hemisphere) => 23-hour day = 82800 seconds
Fall back (northern hemisphere) => 25-hour day = 90000 seconds

Though the real problem is using unix stamps with DST correction at all. One of those things we'll probably never get round to fixing.

[HardwareGeek]

@JBert said in The official unpopular opinions thread:

your poor innocent co-workers

Hah! Poor, sure. Innocent, not so much.

[Rhywden]

@pie_flavor said in The official unpopular opinions thread:

@PotatoEngineer it's really easy to accidentally do, actually. Depending on your code style.

if (undefined == x.a || undefined == x.a.b || undefined = x.a.b.c) {

I'm rather more fond of using JS various autocasts.

const c = x.a && x.a.b && x.a.b.c;

[Mason_Wheeler]

Remember that time Square made a deeply psychological RPG where you play as a bizarrely fractured character with weird mental issues? Where the early-game main villain is a shadowy, overpowered character who is, in some strange way, both an alternate version of the main character and also(!!!) the main character's father? Where you visit the place where Save Points are manufactured, and find out that they're not simply a game convention, but are actual in-universe devices created by the bad guys for spying on the people and keeping the populace under control? Where the hero's enigmatic love interest turns out to be a reincarnation of a woman from ancient times, created specifically to help bring down an evil omnicidal god? Where the reason the hero is special is because long ago, another version of himself came into contact with a mystical power source with a connection to said evil omnicidal god? It was pretty great, wasn't it? Except for the "cute" character with the obnoxious vocal tic, and the overly-ambitious development that led to a horribly rushed and incomplete Disc 2. Despite its flaws, it's considered one of the greatest JRPGs of all time, and with good reason.

But then they did it again, the exact same thing, only this time they set it on an archipelago, removed the awesome mecha fights, and turned it into a pseudo-sequel-ish-thing to one of the other greatest JRPGs of all time... and it was terrible, for six main reasons.

1. It had already been done in Xenogears.
2. It had already been done better in Xenogears.
3. All the Xenogears stuff did not mesh well with the Chrono Trigger stuff.
4. Trashing the legacy of CT. Crono and the gang saved the world, only for everything to fall apart, get conquered and destroyed, all the kids dying horribly or being erased from existence, the Masamune turning evil for no reason, etc. That was just a slap in the face to all the fans.
5. All the stuff that makes Chrono Trigger awesome was just not there. (I distinctly remember, before the game came out, hearing about the huge cast and wondering how they were ever going to come up with Dual and Triple Techs for that many permutations of characters. Answer: ha ha, suckers! They didn't even try!)
6. Both CT and Xenogears are renowned for their awesome soundtracks. Chrono Cross... not nearly so much. There were only two things in the entire soundtrack that have stuck with me to this day: the intro, mostly because of the cool way they updated and re-used part of the CT intro, and the final boss battle theme, because it infamously didn't exist! That was another slap in the face after Chrono Trigger gave us not one but two of the greatest final boss themes ever.

Let's just call it what it is. If there were an Honest Trailers for CC, the title at the end would be "Xenogears: Island Edition." Only instead of the Gears, and the fun, you get slaps in the face.

[ObjectMike]

@Mason_Wheeler said in The official unpopular opinions thread:

Remember that time Square made a deeply psychological RPG where you play as a bizarrely fractured character with weird mental issues? Where the early-game main villain is a shadowy, overpowered character who is, in some strange way, both an alternate version of the main character and also(!!!) the main character's father? Where you visit the place where Save Points are manufactured, and find out that they're not simply a game convention, but are actual in-universe devices created by the bad guys for spying on the people and keeping the populace under control? Where the hero's enigmatic love interest turns out to be a reincarnation of a woman from ancient times, created specifically to help bring down an evil omnicidal god? Where the reason the hero is special is because long ago, another version of himself came into contact with a mystical power source with a connection to said evil omnicidal god? It was pretty great, wasn't it? Except for the "cute" character with the obnoxious vocal tic, and the overly-ambitious development that led to a horribly rushed and incomplete Disc 2. Despite its flaws, it's considered one of the greatest JRPGs of all time, and with good reason.

But then they did it again, the exact same thing, only this time they set it on an archipelago, removed the awesome mecha fights, and turned it into a pseudo-sequel-ish-thing to one of the other greatest JRPGs of all time... and it was terrible, for six main reasons.

1. It had already been done in Xenogears.
2. It had already been done better in Xenogears.
3. All the Xenogears stuff did not mesh well with the Chrono Trigger stuff.
4. Trashing the legacy of CT. Crono and the gang saved the world, only for everything to fall apart, get conquered and destroyed, all the kids dying horribly or being erased from existence, the Masamune turning evil for no reason, etc. That was just a slap in the face to all the fans.
5. All the stuff that makes Chrono Trigger awesome was just not there. (I distinctly remember, before the game came out, hearing about the huge cast and wondering how they were ever going to come up with Dual and Triple Techs for that many permutations of characters. Answer: ha ha, suckers! They didn't even try!)
6. Both CT and Xenogears are renowned for their awesome soundtracks. Chrono Cross... not nearly so much. There were only two things in the entire soundtrack that have stuck with me to this day: the intro, mostly because of the cool way they updated and re-used part of the CT intro, and the final boss battle theme, because it infamously didn't exist! That was another slap in the face after Chrono Trigger gave us not one but two of the greatest final boss themes ever.

Let's just call it what it is. If there were an Honest Trailers for CC, the title at the end would be "Xenogears: Island Edition." Only instead of the Gears, and the fun, you get slaps in the face.

I still remember the ridiculous marketing for that game. I remember seeing quite a few commercials for it on many channels.

[Applied Mediocrity]

I fucking hate SQL as a thing, and I'm certain the world by would have been unicorns and rainbows if not for this garbage idiotic crapshit whoreblow garbage.

[Gąska]

@Applied-Mediocrity SQL itself is fine. It's the custom extensions every DB system has added on top without thinking it through that makes me want to kill myself.

[Carnage]

@Applied-Mediocrity said in The official unpopular opinions thread:

I fucking hate SQL as a thing, and I'm certain the world by would have been unicorns and rainbows if not for this garbage idiotic crapshit whoreblow garbage.

The real funny bit is how all the NoSQL databases eventually end up reinventing SQL poorly.

[Applied Mediocrity]

Ok, so I got pranked by the ol' "SQL REAL doesn't support NaN" gotcha. Haha, nice one, you guise are good. Haha. Yeah.

Fuck you ancient relic morons up your shriveled cunts with a railgun and fuck the dandruff-stained suspender pants you fucked in on.

If Trump wins (he won't), I'll be writing to him about banning SQL immediately. Let's see the world scream bloody murder for that

[Gąska]

@Applied-Mediocrity said in The official unpopular opinions thread:

Ok, so I got pranked by the ol' "SQL REAL doesn't support NaN" gotcha. Haha, nice one, you guise are good. Haha. Yeah.

Fuck you ancient relic morons up your shriveled cunts with a railgun and fuck the dandruff-stained suspender pants you fucked in on.

There is a very sensible rationale for that but I bet you don't even want to hear it.

[boomzilla]

@Gąska HE DIDN'T ASK FOR AN EXPLANATION

[Applied Mediocrity]

@Gąska said in The official unpopular opinions thread:

There is a very sensible rationale for that but I bet you don't even want to hear it.

No, please go ahead. I will reload my rant-o-gun in the meantime.

*ch-chuck*

All I can think of is that NaN (and -/+Inf) wasn't invented/standartized before IEEE 754 came around. Variable width number storage formats were made to accomodate architectures and precious memory in the early days. And then it stuck like many other such decisions dragged along for decades.

And that's the sensible part. The thing is that while some systems (even Oracle!) have provisions for binary floating-point format, TSQL keeps chowing down crayons and pretending somebody may want to run it on DEC VAX or something.

MSDN says REAL maps to Single. The allowed range keeps changing depending on the page you look at, but nowhere does it say that it actually doesn't support the special values, much less that your program will crash with misdirecting yapping about binary stream of incorrect length. Why the fuck does it write it to the stream at all?

I might add that in my model NaN is a meaningful value, so I'll have to store it alongside somehow. And somewhere down the road some query will be wrong because it will be forgotten.

[boomzilla]

@Applied-Mediocrity said in The official unpopular opinions thread:

I might add that in my model NaN is a meaningful value, so I'll have to store it alongside someh

The null REAL is NaN?

[Applied Mediocrity]

@boomzilla said in The official unpopular opinions thread:

@Applied-Mediocrity said in The official unpopular opinions thread:

I might add that in my model NaN is a meaningful value, so I'll have to store it alongside someh

The null REAL is NaN?

Unfortunately no. In my hurr hurr case NULL is also meaningful. It stands for either "not entered" or "N/A".

[ObjectMike]

@Applied-Mediocrity said in The official unpopular opinions thread:

@boomzilla said in The official unpopular opinions thread:

@Applied-Mediocrity said in The official unpopular opinions thread:

I might add that in my model NaN is a meaningful value, so I'll have to store it alongside someh

The null REAL is NaN?

Unfortunately no. In my hurr hurr case NULL is also meaningful. It stands for either "not entered" or "N/A".

I'll ask the dumb question: How is NaN something you want to keep and not indicative of somebody doing something wrong or a bug in the code?

[Gąska]

@Applied-Mediocrity said in The official unpopular opinions thread:

@Gąska said in The official unpopular opinions thread:

There is a very sensible rationale for that but I bet you don't even want to hear it.

No, please go ahead. I will reload my rant-o-gun in the meantime.

To be able to perform queries quicky, DB needs to be heavily optimized for comparisons, sorting and indexing. Most of the efficient sorting and lookup algorithms strongly rely on total ordering (for any x,y either x<y, x=y or x>y). When NaN is involved, none of the three is true. One possible workaround is to do a lot of special-casing around NaN to impose some artificial total order, which is slow, quite finicky (read: easy to get wrong in non-obvious ways) and now you have to decide what to do when comparing two NaNs with different fraction values, and how to treat signaling NaN. Or you could simply disallow NaN.

I might add that in my model NaN is a meaningful value

LOLGF.

Oh, you want some helpful advice? Okay then. Consider using nulls instead, or if that's already in use too, a second boolean column that tells you whether the null NaN. Remember to add a CONSTRAINT value IS NULL OR !isNan.

[Applied Mediocrity]

@mikehurley said in The official unpopular opinions thread:

How is NaN something you want to keep and not indicative of somebody doing something wrong or a bug in the code?

It kind of is, yes. It's a certain sensor adjustment value. If it's NULL, the adjustment has not been specified or the device doesn't support it. If it is NaN, a valid value could not be read from the device (some of the fucking APIs return NaN, goddammit) or 1D10T happened, but an attempt was made and device not only supports it, but probably requires it.

You work with things you're given. Changing that model might be... difficult.

@Gąska was being @Gąska The official unpopular opinions thread:

fuh fuh fuh forting flow fwactional falues

Oh wow, you were right, agony aunt! I didn't want to hear that. I don't give a shit about any of that. Tecknology and tools must serve me, not the other way round.

Remember

And that's where the problem is.

I'll put it in a goddamn BINARY(4).

[Gąska]

@Applied-Mediocrity said in The official unpopular opinions thread:

@Gąska was being @Gąska The official unpopular opinions thread:

fuh fuh fuh forting flow fwactional falues

Oh wow, you were right, agony aunt! I didn't want to hear that.

Told you.

I don't give a shit about any of that. Tecknology and tools must serve me, not the other way round.

Ever had a stupid boss who ordered you in no uncertain terms to do a stupid thing, then blamed you for doing the stupid thing? You've become that boss.

I'll put it in a goddamn BINARY(4).

A fine choice. Preserves all data exactly, has very simple semantics, and is very portable. As long as you never have to use it for filtering/ordering, and it sounds like you don't, that's the best thing you could do in your situation. Seriously. If you mentioned earlier that you don't actually care about the value as long as it saves correctly, I'd bring this up myself.

[Applied Mediocrity]

@Gąska said in The official unpopular opinions thread:

Told you.

But you forgot to mention that it's a solved problem.

Let's see. Postgres manual says that:

On a machine whose floating-point arithmetic does not follow IEEE 754, these values will probably not work as expected

If it's nasal demons, it shouldn't even run. Apart from that:

IEEE754 specifies that NaN should not compare equal to any other floating-point value (including NaN). In order to allow floating-point values to be sorted and used in tree-based indexes, PostgreSQL treats NaN values as equal, and greater than all non-NaN values.

So the behavior is entirely defined. Even sorting kind of works! Chairman Wow!

A fine choice.

A Hobson's choice.

[error]

I know they were hugely influential to a lot of bands I like, but I find Nirvana to be pretty mediocre.

[LaoC]

@error said in The official unpopular opinions thread:

I know they were hugely influential to a lot of bands I like, but I find Nirvana to be pretty mediocre.

It does smell like teen spirit, and teen spirit is one of the things that only stinks from a distance. Kind of the opposite of musk. Or Musk for that matter.