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.

Right. I’d agree this is a thing that happens, I just thought you were addressing this one in particular

“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.

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.

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.

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.

@bleistift2@sopuli.xyz

Back when I coded that (it’s been years), I opted for the shortest one-liners possible (I often catch myself doing one-liners and code-golfing for the fun of it), with “n” and “x” meaning respectively “miN” and “maX”. Hence why I also do a call to rand inside the irand, so irand is as shortest as possible.

As for the bias towards the mid, it’s by design, because ends up quite similar to the central limit theorem:

> Array.from(Array(10000), _=>irand(0,6)).reduce((p,v)=>({...p, [v]: (p[v]||0)+1}), {})
{
  '0': 840,
  '1': 1602,
  '2': 1658,
  '3': 1691,
  '4': 1684,
  '5': 1687,
  '6': 838
}

Notice how both extremities have lower values while the median (3) got the maximum value (1691). I wanted something behaving similarly to how noise often feels like in real world settings (e.g. SDR radio settings, never truly uniform), hence why the “maX” value is inclusive, it’s purposefully meant to, just like the “miN” value is also inclusive, because they need to be inclusive so it gets to appear amidst the samples.

As a comparison, when I change it to trunc (because floor would behave differently for negative numbers), as in:

> irand = (n, x) => Math.trunc(rand(n, x))
[Function: irand]
> Array.from(Array(10000), _=>irand(0,6)).reduce((p,v)=>({...p, [v]: (p[v]||0)+1}), {})
{ '0': 1684, '1': 1659, '2': 1685, '3': 1668, '4': 1676, '5': 1628 }

…then the sample gets too annoyingly uniform, not even to say about how max (the 6) ends up missing from the samples (thus requiring a x+1 whenever the max value is intended to be inclusive). This may be the best distribution for certain scenarios where uniform randomness is expected, but this doesn’t feel… natural.

That’s also why I implemented this JS flavour in a personal Ruby gem (utils.rb) because Ruby got this annoyingly uniform distribution with its native Random.rand (again, useful sometimes, but not exactly natural):

irb(main):041:0> 10000.times.map{Random.rand(0..6)}.tally.sort{|a,b|a[0]<=>b[0]}.to_h
=> {0=>1431, 1=>1449, 2=>1395, 3=>1435, 4=>1411, 5=>1465, 6=>1414}
irb(main):042:0> def rand(n,x) = Kernel::rand()*(x-n)+n
=> :rand
irb(main):043:0> def irand(n,x) = rand(n,x).round
=> :irand
irb(main):044:0> 10000.times.map{irand(0,6)}.tally.sort{|a,b|a[0]<=>b[0]}.to_h
=> {0=>892, 1=>1612, 2=>1744, 3=>1643, 4=>1592, 5=>1708, 6=>809}

See how my Ruby’s irand implementation behaves exactly as my JS’s irand do: with this more natural bias towards the middle.

As for the possibility to do irand(x), because the use case often involves having a well-defined range instead of a maximum target value (minimum value isn’t even always zero, but something arbitrary such as e.g. irand(65,65+25) for generating codepoints for alphabet letters), this is why it’s not overloaded so to default n to zero.