The official unpopular opinions thread
-
@PleegWat
the BDSM thread is
-
@PleegWat said in The official unpopular opinions thread:
Sits down
but the chair is no longer there
-
@Applied-Mediocrity said in The official unpopular opinions thread:
@PleegWat said in The official unpopular opinions thread:
Sits down
but the chair is no longer there
probably eaten by a rogue malloc.
I think that a relational database is too cumbersome for most websites and a content repository would work better.
-
@dkf said in The official unpopular opinions thread:
The manufacturers of the hardware have given you interface definitions in C, stuff like the base addresses of all the memory mapped hardware devices, and replicating that for another language is a chunk of nasty busywork.
There's a tool for automatically generating Rust bindings from C headers. From what I heard, it works very well.
-
@DogsB said in The official unpopular opinions thread:
I think that a relational database is too cumbersome for most websites and a content repository would work better.
Isn't that basically what NoSQL is about?
-
@Gąska said in The official unpopular opinions thread:
@DogsB said in The official unpopular opinions thread:
I think that a relational database is too cumbersome for most websites and a content repository would work better.
Isn't that basically what NoSQL is about?
basically but with less acronyms and more indexing problems than you can shake a stick at.
-
@DogsB said in The official unpopular opinions thread:
I think that a relational database is too cumbersome for most websites and a content repository would work better.
There's no reason why that has to be a binary choice though.
A database could allow you to store arbitrary text (or even binary) documents. Then allow you to add more restrictions (XML only, must contain this element, etc.) and do the best job it can to index things at every point.
By the time you've defined all the elements your document must have, and disallowed any sub-elements, you literally have a relational database.
-
@anonymous234 said in The official unpopular opinions thread:
By the time you've defined all the elements your document must have, and disallowed any sub-elements, you literally have a relational database.
Not really. As the name suggests, relational databases are about relations and mathematical operations on them.
-
@Gąska You can have relations by making some of the elements in the document be a foreign key to another document. Then you can do stuff with them.
-
@anonymous234 relation is a set of tuples. It's not about foreign keys, it's about ordered tuples (they're not actually ordered but named columns give essentially the same result).
-
@PotatoEngineer said in The official unpopular opinions thread:
I like JavaScript.
...okay, that's not quite right. I like TypeScript. With a linter and an IDE that points out my dumber mistakes, ES6-like features, fat-arrow notation (which mostly removes the need for "this"), and proper classes (that are so similar to regular inheritance that I have a hard time pointing out exactly what's different about prototype inheritance)...
I like about 25% of JavaScript.
Opinion on
undefined
?
-
@dkf They don't give you a SVD file?
-
@pie_flavor said in The official unpopular opinions thread:
I like about 25% of JavaScript.
Opinion on
undefined
?I like it, mostly so I can tell the difference between "This value deliberately left null" and "I never got around to initializing that." Also, null == undefined (but null !== undefined), so when I'm being liberal in what I accept, I can use value == null for both checks. Except that, lately, I've been using Lodash's _.isNil() instead, to better communicate to my fellow devs, so the point is a bit moot.
I check for undefined when doing function overloading. JS doesn't support it, so when I accept one-of-three-different-param-sets, I strict-compare against undefined to see whether a param was supplied or not. (And I don't care whether the caller did func(onlyOneParam) or func(onlyOneParam, undefined) – I'll treat both cases the same.)
-
@Gąska Then a list of "documents" all with the same elements is a relation, because those documents are also tuples.
-
@anonymous234 then it comes down to what operations you can perform on those tuples. Can you do a Cartesian product of two such lists of documents? Like, return a list of every possible pair of documents?
-
@PotatoEngineer said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
I like about 25% of JavaScript.
Opinion on
undefined
?I like it, mostly so I can tell the difference between "This value deliberately left null" and "I never got around to initializing that."
Wouldn't you rather the second case to be automatic execution error?
@PotatoEngineer said in The official unpopular opinions thread:
I check for undefined when doing function overloading. JS doesn't support it, so when I accept one-of-three-different-param-sets, I strict-compare against undefined to see whether a param was supplied or not.
Oh God, I've seen quite a bit of code that did that. Some of the least readable code I've seen all year.
-
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
Opinion on
undefined
?I like it, mostly so I can tell the difference between "This value deliberately left null" and "I never got around to initializing that."
Wouldn't you rather the second case to be automatic execution error?
Not necessarily - when I'm dealing with data fetched from an API (as I often am in a webpage), I like the ability to handle such missing data in a fine-grained way. (The dubious quality of the APIs I'm hitting is a different question.) If I had to write four lines of try-catch around every single property access, the code would end up much less readable. And I often end up in a case where I'll handle data exactly the same way for null, undefined, and empty-string (and possibly 0), and I find it quite convenient that I only need to write as much error-handling as necessary, as opposed to handling every possible permutation of "data I can't do anything with".
-
@PotatoEngineer said in The official unpopular opinions thread:
I check for undefined when doing function overloading. JS doesn't support it, so when I accept one-of-three-different-param-sets, I strict-compare against undefined to see whether a param was supplied or not.
Oh God, I've seen quite a bit of code that did that. Some of the least readable code I've seen all year.
Yeah, there's a reason why I rarely do much more than "two optional params" when doing function overloading. It just gets ridiculous after a while. So then you write more-specific function names, which is ridiculous in its own right:
getThing, getThingByRing, getThingByRingAndBling, getThingByBling'sRing...
-
@PotatoEngineer said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
Opinion on
undefined
?I like it, mostly so I can tell the difference between "This value deliberately left null" and "I never got around to initializing that."
Wouldn't you rather the second case to be automatic execution error?
Not necessarily - when I'm dealing with data fetched from an API (as I often am in a webpage), I like the ability to handle such missing data in a fine-grained way. (The dubious quality of the APIs I'm hitting is a different question.)
...Yeah, I guess you are fully aware
undefined
cannot exist in a well-formed JSON.If I had to write four lines of try-catch around every single property access, the code would end up much less readable.
Of course. But what about, say, assigning a static TS type to a variable and getting automatic verification that all fields you need are in place? TS has something like that, doesn't it?
And I often end up in a case where I'll handle data exactly the same way for null, undefined, and empty-string (and possibly 0), and I find it quite convenient that I only need to write as much error-handling as necessary, as opposed to handling every possible permutation of "data I can't do anything with".
In moments like this, I love my statically, strongly typed languages where empty string and non-empty string are the only possibilities.
-
@PotatoEngineer said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
I check for undefined when doing function overloading. JS doesn't support it, so when I accept one-of-three-different-param-sets, I strict-compare against undefined to see whether a param was supplied or not.
Oh God, I've seen quite a bit of code that did that. Some of the least readable code I've seen all year.
Yeah, there's a reason why I rarely do much more than "two optional params" when doing function overloading. It just gets ridiculous after a while. So then you write more-specific function names, which is ridiculous in its own right:
getThing, getThingByRing, getThingByRingAndBling, getThingByBling'sRing...When you get this dilemma, most likely you're already trying to stuff too much into a single function and you should rething your design.
-
@Gąska said in The official unpopular opinions thread:
I strict-compare against undefined
Why not
typeof x === "undefined"
? Fewer bytes?
-
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
Wouldn't you rather the second case to be automatic execution error?Not necessarily - when I'm dealing with data fetched from an API (as I often am in a webpage), I like the ability to handle such missing data in a fine-grained way. (The dubious quality of the APIs I'm hitting is a different question.)
...Yeah, I guess you are fully aware
undefined
cannot exist in a well-formed JSON.Sure it does! It's when you access a non-existent property on an otherwise correctly-formed JSON object! ...while running JS/TS. I'm talking about "how to handle missing properties in TS", rather than "there's this literal undefined in my JSON." So while the API is never going to send me a literal undefined, it's definitely going to omit properties (even properties that I thought were required) from time to time. I just hit a case this morning, in fact – I thought that a particular metadata object would always have a Name property, but... nobody told the API that. (We have a syncing issue: two historically-separate DBs have been slowly getting more tangled over time, and the way to get data into the "new" DB is to sync it from the old one. There are something like 4 different sync tasks, and they all run just fine... most fo the time.)
If I had to write four lines of try-catch around every single property access, the code would end up much less readable.
Of course. But what about, say, assigning a static TS type to a variable and getting automatic verification that all fields you need are in place? TS has something like that, doesn't it?
It does indeed! If I declare something to be Type X, then it's a compile-time error (and a red squiggly in my IDE) to assign a literal that doesn't contain the required fields (in their required types) of Type X. The problem comes at runtime: when I'm fetching data from an API, it may (or may not!) contain all required properties. And if the returned JSON doesn't contain some required properties, it's not a runtime error until there's an illegal access. (Accessing a property-of-a-nonexistent-property. Asking for something and getting "undefined" is fine – JS doesn't scream until you ask for undefined.someOtherProperty or undefined.toString().) TypeScript is only compile-time safe. And, if you're a terrible person, you can force TS to disable its safety by declaring a variable or interface to be the "any" type!
And I often end up in a case where I'll handle data exactly the same way for null, undefined, and empty-string (and possibly 0), and I find it quite convenient that I only need to write as much error-handling as necessary, as opposed to handling every possible permutation of "data I can't do anything with".
In moments like this, I love my statically, strongly typed languages where empty string and non-empty string are the only possibilities.
Okay, it's really rare to get a 0 when you're expecting a string-or-null. If that happens, it's time to take the clue-by-four to your API authors. Frankly, I don't even check for that. I'm just saying that null/undefined/0 handling can be done by checking for JS-"falsy" values, and it's the same as checking for null/undefined/empty-string. (And it's common for me to treat null/undefined/empty-string identically: "do nothing with this value (or use the default value, or whatever)".)
-
@Zecc said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
I strict-compare against undefined
Why not
typeof x === "undefined"
? Fewer bytes?Works the same either way, and I see "typeof" rarely-enough that I don't think to use it. Also, I'd far rather compare to the keyword undefined than the string "undefined" – I'm not immune to typos, and my IDE will scream bloody murder if I typo a keyword.
Undefined is the only type that gets you a really-useful "typeof" result – unless you're writing print-anything functions. (Sure, "number" and "string" are reasonably useful results, but typeof null is "object", which has bitten me often enough that I just don't reach for typeof when I'm reasoning about types.)
-
@PotatoEngineer said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
@Gąska said in The official unpopular opinions thread:
@PotatoEngineer said in The official unpopular opinions thread:
Wouldn't you rather the second case to be automatic execution error?Not necessarily - when I'm dealing with data fetched from an API (as I often am in a webpage), I like the ability to handle such missing data in a fine-grained way. (The dubious quality of the APIs I'm hitting is a different question.)
...Yeah, I guess you are fully aware
undefined
cannot exist in a well-formed JSON.Sure it does! It's when you access a non-existent property on an otherwise correctly-formed JSON object! ...while running JS/TS. I'm talking about "how to handle missing properties in TS", rather than "there's this literal undefined in my JSON."
Oh, okay. That's a little less scary than I thought. Anyway - wouldn't it be awesome if, instead of relying on
undefined
and its weird comparisons, you could just query the object whether it has a property of given name set? And is some value in object was optional, it would actually say so in its type, and everything else was guaranteed to exist? And not as null - actually exist?Yes, I know it doesn't solve the problem of APIs not doing what they claim to do. But at least your own code is nicer.
If I had to write four lines of try-catch around every single property access, the code would end up much less readable.
Of course. But what about, say, assigning a static TS type to a variable and getting automatic verification that all fields you need are in place? TS has something like that, doesn't it?
It does indeed! If I declare something to be Type X, then it's a compile-time error (and a red squiggly in my IDE) to assign a literal that doesn't contain the required fields (in their required types) of Type X. The problem comes at runtime: when I'm fetching data from an API, it may (or may not!) contain all required properties.
And TS doesn't have a runtime equivalent of its compile-time typecheck? Man, that sucks. Such an obvious thing, and yet it's missing.
-
@Gąska said in The official unpopular opinions thread:
Anyway - wouldn't it be awesome if, instead of relying on
undefined
and its weird comparisons, you could just query the object whether it has a property of given name set? And is some value in object was optional, it would actually say so in its type, and everything else was guaranteed to exist? And not as null - actually exist?My Stockholm Syndrome around TypeScript is strong enough that this doesn't even register. How do you check whether a property exists on a dumb JSON object?
object.property === undefined
. If I wanted to be really serious, then I'd write a class for it, instantiate this data as a class instance rather than a dumb JSON object, and write the error-handling however I wanted – up to and including throwing exceptions in the constructor. But that's extra code, and I usually only write classes when it otherwise makes sense to do so – I assume that most APIs return data in the structure they say they will, and that the most likely API nonsense is missing data rather than data in the wrong shape. And TypeScript does a fine job for that: I have (from groveling Swagger.json files) all of the types that the API returns, so when there's data, I know exactly what properties exist (and their types), and the compiler will yell at me if I typo a property name.If I wanted to write a bit less code, then maybe I initialize a Map instance from this dumb JSON object, so I can call
mapInstance.has(keyName)
to check for existence of things – but that's more for dictionaries with a single value type. AndmapInstance.has(keyName)
is about the same number of characters asobject.keyName === undefined
, so this feels like we're arguing over semantics more than anything else. The main problem with TS's way is that if I typo and miss one of the =, it's still syntactically valid, and will accept null in addition to undefined.I've dealt with C#'s JSON libraries, and it's really quite neat that there's magic to convert JSON into actual C# types, but if you have optional values, you're still doing a lot of null-checking. The only advantage to C#'s JSON-parsing is that it will choke, die, and throw if required properties aren't present – whether that was a recoverable error or not. (i.e. a "required" property that you can do without for this specific operation. It's probably a good thing to die in that case, but it's a right pain to debug, since the exception gets thrown before you can touch it.)
And TS doesn't have a runtime equivalent of its compile-time typecheck? Man, that sucks. Such an obvious thing, and yet it's missing.
Eh, I've only occasionally found that useful. If you're applying types to everything correctly, the only possible sources of bad types are a) programmatically-generated objects and b) bad data. And you'll usually hit errors pretty quickly after either one of those. Usually. Probably. Likely. Maybe. Sorta. Occasionally. Sometimes. And it's not frustrating at all when it takes a long time to find out that data was missing 27 steps ago.
-
@PotatoEngineer said in The official unpopular opinions thread:
How do you check whether a property exists on a dumb JSON object? object.property === undefined.
False.
undefined = 4
is valid JS and will result in that check failing forevermore. The correct way istypeof(object.property) === 'undefined'
.
-
@pie_flavor said in The official unpopular opinions thread:
False.
undefined = 4
is valid JS and will result in that check failing forevermore. The correct way istypeof(object.property) === 'undefined'
.I cannot comprehend the kind of environment where that's even worth considering. You might as well worry about someone adding a C preprocessor directive on "NULL" – it's technically possible, but it's never gonna happen on any codebase you're ever going to develop on. (And if it does happen, it's time to reconsider your colleagues – either getting them fired, or getting out of Dodge.) I'm way more worried about typoing the string literal "undefined" (and undetectably screwing up my logic) than I am about someone redefining undefined from under me.
Also, I just tried this in Chrome's console, and again in Edge's and Firefox's. "undefined = 3" was accepted as a valid command, but asking for the value of undefined immediately afterward returned "undefined" in all three browsers, so no assignment occurred. Worrying about this is just plain bonkers.
-
-
@pie_flavor said in The official unpopular opinions thread:
They don't give you a SVD file?
They've certainly not given me one. One may have existed, especially for the core design, but I'm a lot less certain about for our custom hardware; it's entirely possible that the C header was written straight from the data sheet by the hardware developers.
-
@dkf well that's just rude. If they did give you an SVD file, then Rust dev becomes really easy as you can use a tool to auto-generate a library. and a good library at that, that uses lambdas and methods to batch writes while keeping your code sane.
-
@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) {
-
if you write Javascript backwards and make a typo it can cause strange problems
-
@hungrier 'strange' doesn't cover the half of it. The equivalent in other languages fucks up one method call, this fucks up the entire VM. And like I said, it may or may not be backwards depending on your code style.
-
@Gąska said in The official unpopular opinions thread:
@pie_flavor said in The official unpopular opinions thread:
undefined = 4
is valid JSNot anymore.
verily, i typed the characters one score:
undefined equal four
quoth the interpreter, "nevermore"
-
Dark themes annoy the heck out of me. I've tried them but I never had a problem with eye strain from light themes and I sit at a computer all day.
At night if I'm in a dark room I will lower the brightness on my computer and phone for sure, but it will still be a light theme.
Oddly enough the only exception to this is WTDWTF but I think that's because this place sucks the light out anyways so it is only fitting.
-
@pie_flavor said in The official unpopular opinions thread:
this fucks up the entire VM
I thought it was established a while earlier that you can't successfully assign to the
undefined
variable. (The assignment fails silently.) That means that it's just your code that's broken, not the VM.
-
@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) {
That's a linting error in my current settings. No assignments in ifs. And while there are a couple of reasons why you might do that (I saw it in a parser at one point, and it was useful and readable there), it bites enough people that it's a common linter error.
-
@hungrier said in The official unpopular opinions thread:
if you write Javascript backwards and make a typo it can cause strange problems
tpircavaJ
Hmm, what's that strange droning sound coming from the room next door?
-
@Zecc Probably irrelevant, as you typed it wrong. You're missing an s
-
@Vault_Dweller said in The official unpopular opinions thread:
You're missing an s
What is this, Reddit?
-
@Vault_Dweller said in The official unpopular opinions thread:
@Zecc Probably irrelevant, as you typed it wrong. You're missing an s
I wasn't sure what kind of typo I should make. Let's try again.
tpricsavaJ
Hey, was that black gooey stuff on that wall already there?
-
@Zecc Ahh, I missed the part about having to make a typo. As you were, then. Oh, and I would avoid the black gooey stuff if I were you.
-
-
@heterodox said in The official unpopular opinions thread:
the usual being what's now called P/Invoke in VB.NET; I don't remember what it was called then.
Declare
statements, You could also use COM/OLE, just as you can with .NET. (There's also specific language about ActiveX support, but that's just COM with extra steps.)@pie_flavor said in The official unpopular opinions thread:
undefined = 4
is valid JSThis is true.
@pie_flavor said in The official unpopular opinions thread:
and will result in that check failing forevermore.
The ES5 spec (Firefox 4+, IE9+, all versions of Edge, all tested versions of Chrome, Node 0.12+) says that it's not writable; attempts to write to it do nothing. Earlier than that though and you'd be right.
-
@dkf said in The official unpopular opinions thread:
the C header was written straight from the data sheet by the hardware developers.
-
@Vault_Dweller said in The official unpopular opinions thread:
Probably irrelevant, as you typed it wrong. You're missing an s
@pie_flavor
if you write Javascript backwards and make a typo it can cause strange problems
Filed under: Like mispronouncing a syllable from the Necronomicon.
Edit:
-
@Luhmann said in The official unpopular opinions thread:
@Cursorkeys
I think we found swampie's alt accountNo, he's still on VB5.
-
@Vault_Dweller said in The official unpopular opinions thread:
Oh, and I would avoid the black gooey stuff if I were you.
It was Salmiakki Koskenkorva. Good call.
-
@HardwareGeek said in The official unpopular opinions thread:
@dkf said in The official unpopular opinions thread:
the C header was written straight from the data sheet by the hardware developers.
It probably dates back to when they hadn't quite figured out that they actually did need to have real software specialists. (The bits in C are a lot less than the bits in Perl…)
-
I thought the Virtual Boy was a good console.