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.
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.
One way in which this could have come about is that
Math.randomwasn’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 agetRandomfunction.Pretty sure that math.random is decades old.
Pretty sure many codebases running today (even JS ones) are older
How many JS codebases are over 30 years old? Can you name even one?
Math.random() was always in the spec: https://ecma-international.org/wp-content/uploads/ECMA-262_1st_edition_june_1997.pdf
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.