Actually it is really really fast relative to speeds we are familiar with in our lives. Space is just so big that it makes the speed of light (c) feel slow.
Even on Earth, c is slow and it's pretty inconvenient. We wouldn't have to worry too much about which edge location a resource is served from if intercontinental latencies were on the order of 100 microseconds instead of 100 milliseconds.
this video[1] by Dr James O'Donoghue really made me stop and consider how slow the fastest possible speed is, relative to the awesome vastness of space. I mean how many people have actually paused for 8:20 mins and thought, "wow that's a really long time for light to arrive from that star that seems like a stone's throw away!"
I'm going to go the other way on this. I like this idea, but I can see it's not for everyone.
I like to do some Javascript coding with my son on his Chromebook, and having a development environment is a hard problem for us to solve for some reason.
Having a webpage that just spins up VSCode and allows us to publish and test in a registry might be just what we need, no?
I know lots of devs are different, but if I could do all my work in a web app and never install any development software in my laptop, I'd do it in a heartbeat.
Exactly right. It's polarizing. Very polarizing, if this comment thread is any indication. And the pole of people who absolutely love it will buy it. That group of people does not need to be large for this to be successful.
This is a great example of the marketing strategy that advocates focusing on a small group of very passionate customers. If you can create a set of fanatical early adopters for a brand-new product, you're on your way to success. Very few products achieve immediate mainstream success and assuming that Tesla won't likely have the production capacity to meet mainstream demand anyway, this is a very smart play.
Something I don't quite understand about quantum mechanics and the MWI... At the point the atom passes through the diffraction grating, it has a quantum superposition. According to MWI, reality has "branched", right?
Then the two realities interfere with each other to form the probabilistic pattern at the detector. So, according to MWI, reality has "merged" again?
If we accept the mulitiverse idea of MWI, doesn't that mean at some point particles aren't able to marge with their branched-reality versions?
The "at some point" doesn't have to do with time. It has to do with the rest of the wavefunction of the universe. If the atom becomes entangled with everything else (in fact, a single quantum-mechanical spin suffices) the two branches become orthogonal and the interference terms from 'merging' vanish. We say the wavefunction 'decohered' when it becomes too complicated to see how to reverse this effect---as more and more particles get involved it becomes hopeless.
Good question. As I define it no, a tree language uses white space and only white space for syntax. While both python and yaml use white space for a portion of their syntax, the bulk of their syntax is traditional BNF.
I like this article, but I think actually the software industry has seen a succession of silver bullets. The problem is, once they appear, you take them for granted:
I've started to think I'm better off building lots of small OSS libraries than one big one.
The big one seems like some massive accumulator bet, which is really unlikely to pay off, whereas one of the smaller parts may just have an impact on it's own...
Not that documentation is bad but it is rarely correct. Now you have to spend time trying to match documentation that doesn't match the code you see.
I always prefer a different approach. There is no need to document what a function does, that is self evident from stepping through it. The thing that should be included in the code is the WHY, meaning why does this function even need to exist and how does it fit into the architecture?
Now an accurate high level architecture diagram and function raison d'etre telling you everything you need to know with much less risk of not having an accurate and up-to-date documentation process.
> Not that documentation is bad but it is rarely correct. Now you have to spend time trying to match documentation that doesn't match the code you see.
It depends on what you mean by documentation. If you mean articles on Confluence or whatever, yeah, that's hopeless. If you mean comments in the code, I couldn't disagree more.
I don't buy the common argument that comments easily become inconsistent with the code. I can't imagine changing a line of code and completely ignoring the comment above it, and I'd definitely require a fix if I saw someone else do that in a code review. That's just a ridiculous level of sloppiness.
> There is no need to document what a function does, that is self evident from stepping through it.
I'm afraid I disagree here too, though again conditionally depending on what you mean. Straightforward logic shouldn't be littered with superfluous comments. But on the other extreme, the fast invsqrt algorithm needs more of a comment than the canonical "what the fuck?"
Yes, given weeks of head scratching any arbitrarily-dense block of code will release its secrets, but that's not good engineering. Anyone can build a bridge by dumping a hundred billion dollars of concrete into the bay until it's dry; good engineering is doing it cost-effectively. A well-placed comment in some non-obvious logic can save time for a developer (likely you) every time they interact with it.
> Not that documentation is bad but it is rarely correct.
Rarely? I often turn to the documentation to check the capabilities, syntax and semantics of the languages and interfaces that I use. If it were only rarely correct, I would be in trouble.
If you are talking about application code specifically, my experience is that documentation is too rarely present to be an issue.
Which is why:
Verbosity is not bloat.
Abbreviations are a code smell.
I remember encountering a platform in a language before namespacing was introduced in that language, and it had names for the classes like `Platform_Catalog_Model_Product_Simple_Collection`. It looked really silly, but I always knew what I was working with at a glance. It was honestly a really nice developer experience.
Which, it turns out is really, really slow. Big revelation to me!