Yes, I believe it's possible to train our brains and learn to perceive better in higher dimensions. There's a great description in the science-fiction book Neverness, where pilots meld their minds with the spaceship computer to visualize and navigate hyperspace.
You're right, it's not just about post-install scripts nor NPM and JavaScript. This is a deep fundamental issue in software development practices across most programming language ecosystems. And not only open-source, since proprietary code is often even worse about vetting dependencies. More eyes are better, therefore open source (or source available) is a prerequisite for security.
Improving NPM's processes, having more companies auditing packages, changing the way NPM the tool works - that's all good but far from enough, it doesn't actually address the root vulnerability, which is that we're way too comfortable running other people's arbitrary code.
Containerization and strict permissions system by default seem to be where we're headed.
It's an interesting question, why immutability is not built into more languages as the default, so that the most intuitive syntax of assignment produces new values.
Without having any expertise in the matter, I'd guess that mutability has the advantage of performance and efficient handling of memory.
obj.foo[5].bar.a = 2
An immutable interpretation of this would involve producing new objects and arrays, moving or copying values.
Another possible advantage of the mutable default is that you can pass around references to inner values.
That's always the case with immutable data structures; this assignment syntax didn't create that problem. If you used lenses to write 2 into "a", and you expected to get back a new "obj", you would still need to produce all those new objects and arrays. That's just immutable data structure stuff. I'm only asking about the assignment syntax here.
> Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine.
Hmmm, it still has a pretty extensive default list of permitted npm packages, which wouldn't necessarily be a problem if there were a way to disable it, but I can't seem to find it.
> General relativity treats spacetime as dynamical and exhibits its breakdown at singularities. This failure is interpreted as evidence that quantum gravity is not a theory formulated {within} spacetime; instead, it must explain the very {emergence} of spacetime from deeper quantum degrees of freedom, thereby resolving singularities.
> Quantum gravity is therefore envisaged as an axiomatic structure, and algorithmic calculations acting on these axioms are expected to generate spacetime. However, Gödel’s incompleteness theorems, Tarski’s undefinability theorem, and Chaitin’s information-theoretic incompleteness establish intrinsic limits on any such algorithmic program. Together, these results imply that a wholly algorithmic "Theory of Everything" is impossible: certain facets of reality will remain computationally undecidable and can be accessed only through non-algorithmic understanding.
> We formalize this by constructing a "Meta-Theory of Everything" grounded in non-algorithmic understanding, showing how it can account for undecidable phenomena and demonstrating that the breakdown of computational descriptions of nature does not entail a breakdown of science. Because any putative simulation of the universe would itself be algorithmic, this framework also implies that the universe cannot be a simulation.
Apparently NaN (not a number) becomes false when type-cast to boolean.
Boolean(NaN)
===> false
For a hypothetical NaB (not a boolean), the same behavior seems logical.
Boolean(NaB)
===> false
So the condition `if (NaB)` is false and will fall through to the `else` branch. But..
> what you do determines what NaN === NaN actually evaluates to
I think I disagree with this because it's not about casting to boolean, it's a totally different question of self-identity, or comparing two instances (?) of a value (?!).
From the article:
typeof NaN
===> "number"
For symmetry and consistency:
typeof NaB
===> "boolean"
> NaN is the only value in the whole of JavaScript that isn’t equal to itself .. the concept of NaN is meant to represent a breakdown of calculation
Similarly, NaB would represent a breakdown of true/false condition (somehow) as an exceptional case. Whether it equals itself is a matter of convention or language design, not logic - since it's beyond logic just as NaN is beyond numbers. I would say:
NaN === NaN
===> false
NaB === NaB
===> false
> you throw an exception (and imo it is better..
I agree throwing an exception is better design for such exceptional cases - but we know JavaScript as a cowboy language would rather plow through such ambiguities with idiosyncratic dynamic typing, and let the user figure out the implicit logic (if any).
I don't necessarily think about JS in particular. A lot of languages have similar design and prob most have to deal with this issue in general.
In your examples, it does not make sense to have both
typeof NaB
===> "boolean"
and
Boolean(NaB)
===> false
But maybe if you had NaB it would make sense to evaluate
Boolean(NaN)
===> NaB
And maybe also evaluate `NaN === 1` to NaB?
I am not too fond of NaB because boolean is supposed to encode binary logic. There exists ternary logic and other concepts that could be used if you do not want strictly two values. Or if you want to encode exceptional values, no reason not to use int8 directly, instead of calling it boolean but actually using sth that could be represented as int8 (NaB has to be represented by some byte anwyay). In general, tbh, I think often it is not useful to encode your logic with booleans because many times you will need to encode exceptional values one way or another. But NaB will not solve that, as it will just function as another way to encode false at best, throwing exceptions around at worst.
> Similarly, NaB would represent a breakdown of true/false condition (somehow) as an exceptional case.
Still, in JS `NaN || true` evaluates to `true` hence I assume `NaB || true` should evaluate to true too. It is not quite the same as NaN + 1 evaluating to NaN. And as NaN (and hence NaB) functions as false when logical operations are involved for all intents and purposes, except if you exactly inquire for it with some isNaB() or sth, to me NaB is another way to encode false, which is probably fine depending what you want it for.
Apparently this is also called "three-valued logic".
> In logic, a three-valued logic (also trinary logic, trivalent, ternary, or trilean, sometimes abbreviated 3VL) is any of several many-valued logic systems in which there are three truth values indicating true, false, and some third value.
> the primary motivation for research of three-valued logic is to represent the truth value of a statement that cannot be represented as true or false.
Personally I think I'd prefer a language to instead support multiple return values, like result and optional error. Or a union of result and error types.
> no reason not to use int8 directly
Hm, so it gets into the territory of flags, bit fields, packed structs.
It's like Twitter, there was no good reason to change a name with years of trust and reputation. "X" sounds juvenile and stupid, and so does "Wise". I don't understand how it's legal for companies to name themselves as common words like "Alphabet". It's not only confusing, it's arrogant as hell.
Apple wasn't a name change, though: that was its name from the beginning. Slightly different situation. (Yes, they changed their name from Apple Computer Company to Apple Inc. once they started making smartphones, but that's not the same because the part of their name that everyone called them, Apple, was kept unchanged). Their logo was always an apple with a bite out of it, their first computer was the Apple I (first one of theirs I ever used was the Apple II)... they really leaned into the name, and made it part of their identity. Which isn't the case with Alphabet or Wise.
reply