Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Currently having a new hire write a library in python and I noticed he was doing this in a few PRs. I went and explained to him this was not necessary and that he could just call the original function where he needed it. While showing him how to inline the functions I realised he was actually adding type annotations to functions which did not have them in the original libraries.
Nevermind what I told you, keep doing this.
One way in which this could have come about is that Math.random wasn’t supported in all relevant browsers when the library author wrote the library. So they had to roll their own randomness with blackjack and hookers. Later the web standards evolved and the author was able to remove the custom code, but now had people relying on his library’s exposing a getRandom function.
You see this kind of stuff in C all the time when a code base supports multiple OSs by using macros.
Yes, though at least with C you have the compiler to optimize the cruft out of your binary and end up with a nice, clean program.
With JavaScript this is going to incur some runtime cost everywhere this library is used, even if it only happens once when getting optimized out by the JIT compiler.
Pretty sure that math.random is decades old.
Pretty sure OP’s image is hyperbole.
Right. I'd agree this is a thing that happens, I just thought you were addressing this one in particular
Pretty sure many codebases running today (even JS ones) are older
Math.random() was always in the spec: https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf
Remember IE? Yeah. Probably responsible for a lot of now-superfluous things like this theory suggests.
Gotta admit, didn't think it was that old
How many JS codebases are over 30 years old? Can you name even one?
And? I don't know how to check but I'd guess math.random was included from the beginning.
Considering how many websites were temporarily obliterated by the left-pad fiasco, being an npmjs maintainer might be an even higher power-to-effort ratio (by virtue of a near-zero denominator) than being a billionaire CEO.
I still find it hilarious people think linking to some lib online on a live website makes sense. And people still do. Ehh.
i mean its still good to use an abstraction layer in case you ever have to change the underlying call; it's far easier to change it in one place instead of replacing every call
Is this a joke?
If you need a different random function, you write a different random function either way. Having one function do nothing but call another function does nothing.
There are several legit reasons why you'd do this. Unit tests, for example: override getRandom() with an implementation that always returns the same series of numbers, and now you have repeatable tests without touching the production code.
Can you override Math.random within a local scope?
At my shop we do create generic covers for vendor specific functionality, for the reasons you stated. Though the practice was started in case we ever needed to swap vendors.
You can, but you shouldn’t. You don’t know what else relies on Math.random. That’s why there’s the wrapper function. That you can override in unit tests without worrying about other, unrelated code.
It's not about a different function providing different randomness, but providing a compatible implementation for environments not supporting the "regular" implementation.
If this screenshot is legit, I guarantee you that either the library is older and there was some weird branching for IE or it's brand new and had branching for the hot new JS runtime / cross compiling.
Supporting a metric fuckton of browsers and environments takes the same amount of shims.
Just do a find and replace
YAGNI
I can imagine multiple scenarios where this could be useful. Simplest is perhaps the coder imagined at the time they could extend the function in later stages.
Then they could add their own function in later stages. YAGNI exists for a reason.
I think it is a balance. Despite having quite functional IDEs now a days, it is still more error prone to change 10 instances of math.random than a single function you define modularly. If you think there is a good chance such an extension might be needed in future or that you might want to change libraries later on, I wouldn't necessarily call this a bad decision, even if it goes unused.
YAGNI works best when it prevents adding complex unused futures which are error prone and complicates a simpler program logic and flow. In this case you are just encapsulating a function inside another one without any change to program complexity.
It definitely depends on the use case. I could accept this being abstracted out to facilitate mocking, for instance (although I'd recommend mocking at a higher level). But in general this wouldn't pass review with me unless I get a good explanation for why it's necessary.
Yagni?
“You ain’t gonna need it”. It means: Build the thing you need now and don’t try to predict what you’ll need in 3 years. You ain’t gonna need it anyway.
I get that this is a joke, but would something like import Math.random as getRandom work better? Because that basically what you're doing here, renaming the function.
that's not really a thing in JS as Math isn't imported, it's just an object available globally. the closest you can get is like const { random: getRandom } = Mathbut that's just uglier.
the implication is that this function is exported from a library so they have to keep the function around - obviously in a modern project you'd just do Math.random()
And that's only one of the many reasons that JavaScript is a clown language.
Which of these things, excactly? That Math just floats around in the global scope? Or that that destructuring assignment works? Or that the author chose to abstract around Math.random(). That has come very handy for me when testing.
Global scope.
Also that there's, after 35 years of webbrowsers, still no reliable way to match a domain without subdomain, except via string splitting.
I see your point regarding global scope. But personally, I’ve never encountered an issue with it. And it’s kinda nice not to have to import fetch every time you need it.
Regarding subdomains, if you’ll humor my curiosity: What’s the use case? I also wonder what an API for this might look like.
const {domain, subdomains, rootDomain} = new URL('https://wikipedia.org/')
// 'wikipedia.org', [], 'wikipedia.org'
const {domain, subdomains, rootDomain} = new URL('https://foo.bar.baz.net/')
// 'foo.bar.baz.net', ['foo.bar.baz.net', 'bar.baz.net'], 'baz.net'
A userscript over links for debugging purposes, that should ignore links to the same domain (www.w3schools vs campus.w3schools vs www.youtube).
Btw, it's funny how support.mozilla and some standards-teaching-sites are some of the worst offenders of web standards.
Edit: how to stop this auto-linking?
If I understand correctly, you want to check the current domain (eg. w3schools) against api.w3schools and www.youtube, and return true for the first and false for the second (or the other way around)
Then technically it’s possible without string splitting:
const href = 'retrieved-from-the-anchor-element';
(new URL(href, location.href).hostname).endsWith(location.hostname)
Edit: got it working yesterday evening. But with split().slice(-2). Thanks again.
Well, the whole web is basically "let's go, make it work somehow". Thanks for your effort!
Most scripting languages have a global scope of some kind. It's not that big of a deal.
I'd prefer not to have it, but it hasn't caused me problems in many years. Actually, the window object can be really useful in some situations so I'm not even sure about that.
That code snippet isn't even one line and it's already unreadable to me
If only there was a way to put ads in the code. Think of the revenue!
Simmer down, Satan
😂
Copilot - I see you're using a random function, would you like to buy this cool shirt whose designer used Math.random() to help make them all unique?
Its a modernized version of Infinite monkey theorem but instead of typewriters and Shakespeare its importing libraries and Facebook.