Hm, re: "ads are everywhere" - is it just me, or are two of the three sample posts in the screenshot content-based ads?
First for the novel Cibola Burn, and third for the app Halide.. the middle post seemingly is a reply to an ad of some book series as well :) Or "influencer" paid content != ads?
This is fascinating. For anyone interested in a slightly odd but unique and in-depth view of Systems design and failure, would like to recommend "The Systems Bible: The Beginner's Guide to Systems Large and Small" by John Gall.
- "Team Geek: A Software Developer's Guide to Working Well with Others" http://shop.oreilly.com/product/0636920018025.do -- Software engineering teamwork a-b-c. I'd love to work on teams where everyone has read this one.
[edit: 2nd edition of "Team Geek" is titled "Debugging Teams"; having read both, no difference which you get]
It's "My hovercraft is full of eels", not "My hovercraft has an arbitrary amount of eels in it"!
Now looking at the ES5 spec [0], the max length of an array is an unsigned 32-bit integer due to the `ToUint32` operation that the spec defines. So that means our `craftCapacity` here needs to be 2^32-1
Sadly we can't use `Number.MAX_SAFE_INTEGER` here because that assumes double-precision floating points as the underlying storage method, so we just have to hardcode our value:
[0] While the spec says this in a roundabout way, i'm not sure if any implementations actually adhere to this limit, and i'd guess most convert the array to a hashtable internally long before it gets to that size.
ekke assumed the hovercraft can hold at most 331 eels. You assumed it holds 4 billion eels. Who's right? I don't know but a billion eels sounds far off.
If an array is the hovercraft, it can hold 4 billion "things" regardless of what those things are! So you need to fill that up to meet the requirements of the saying.
Ah but now we're at the crux of the issue; in Javascript, hovercrafts grow in size to accommodate as many eels as you put in, but to a maximum of ~4 billion. So "full" is not a question you can ask of your hovercraft, though it will tell you once it's overflowing.
What if we used a storage method that didn't grow?
In JavaScript we have typed arrays, we could use a `Uint16Array` to store UTF-16 code points as integers in each element, then we could define the amount of eels that our "hovercraft" could store ahead of time in a way that it won't expand.
const hovercraftEelCapacity = 331 // We can define our hovercraft to have room for 331 eels
const eel = 'eel'
const hovercraft = new Uint16Array(new ArrayBuffer(2 * eel.length * hovercraftEelCapacity)) // Each "eel" takes up 3 16-bit integers
for (let i = 0; i < hovercraftEelCapacity * eel.length; i += eel.length) {
hovercraft[i] = eel.codePointAt(0)
hovercraft[i+1] = eel.codePointAt(1)
hovercraft[i+2] = eel.codePointAt(2)
}
console.log('Your hovercraft full of eels: ', hovercraft)
While we're nitpicking, unless you have partial eels, it's arbitrary number, not amount. That calls to mind measuring blended eel, of which I don't want to make a career.
Well to be fair the saying doesn't specify the state of the eels.
It could be liquefied remains of eels! Although I'm guessing we would need to study a few of the translations in languages that explicitly differentiate between "a collection of whole somethings" and "an amount of something". Although now that I'm thinking about it in english saying "my hovercraft is full of eel" would imply that it's an amount of eel, not a distinct number of eels.
Still, if it were the "amount", a simpler JS expression would convey the message:
Whoa, whoa. Did you just assume the transitive property of sound pressure fluctuating languages with voltage fluctuating languages? You should check your access privilege.
Let me guess, I bet you think people can transmit information via the fluctuation of electromagnetic waves too. Brilliant!
I don't know how many reported it to npm, but when I initially saw the post on HN, I took the steps to report the packages.
I don't know who to credit on this, and neither does npm but OP seems to be the source of these findings, although it would baffle me if they didn't report it to npm.
A naive strategy where they never die, and hopefully stay in prison for slightly less than a few billion years:
One prisoner is the light-counter (Mr C). Others follow a simple pattern - if the light is off, and they have never turned it on yet, turn it on. If it is already on, or they have already ever turned it on, do nothing.
Mr C enters the room, if the light is on, remembers it, and turns it off.
When Mr C has entered the room 99 times with light on, he can say 'Yes' and they are safe.
This is essentially the same solution I came up with. I'm not sure it needs to be optimized assuming we can set the starting state and the strategy for every prisoner.
