Most coding problems are wiring stuff up. If you can change a tire or put together a LEGO set, you can probably write code.

The problem with the golden geese that you're pointing out is mostly one of tooling, in my opinion. Undergrads at top CS programs are as clueless as your grandmother about developing software because the tools are either toys for children or extremely sharp knives with a blade on the handle. This is a problem that replit is trying to solve.

There are numerous data structures that are well suited for various geometric queries like ranges/lookups (interval trees, quadtrees) as well as more text-oriented operations like cut/copy/paste/insert/merge/etc (like ropes).

I'm not familiar with the operations required to put a cursor at the right place in a document, but knowing how much research has gone into storing similar data and looking up what you need efficiently the idea of "going through all the text every time" is a big code smell.

I've also never had trouble pasting a spreedsheet selection into a word document. Email is a nightmare in general though.

I'm not sold on collaboration personally. I've had to do it a bunch since the pandemic began and I've found it to be an anti pattern. One of the big inconsistencies is that cells in sheets don't update while being edited while collaborating, which is not great if you have a spreadsheet heavy workflow. Docs is impossible to replace that though, because it's auto formatting is draconian and always seems to reset its preferences. When editing docs we spend more time formatting them then creating the content.

Electron apps have shown that you can use a browser's rendering engine to make high quality apps distributed on multiple platforms. They also have the benefit of persistence, filesystem access, hooks into native code should you need them (not WASM - mind you), you can implement true multithreading and explicit SIMD optimizations. You don't have memory limitations, and you don't have to worry about browser sandboxing, malicious or well intentioned extensions that break the experience, etc.

The browser is not the same platform as electron. I would guess that Google Docs would function much better in electron than on the web.

It is if your security model includes things like parental controls and payment processing.

You can get around the immutability of the reference if your compiler implements the ABI with copy on write semantics, which I think is a reasonable compromise. But I'm still not certain how you would handle arbitrary control flow that the compiler may not be able to reason about.

If for example your arguments may be behind const references, how would you implement getcontext/swapcontext for your ABI? If everything is an integral value in registers or on the stack then it's really easy, but i would think it would have to be a compiler intrinsic if it depends on the function signature of the calling context, in order to perform the required copies.

Every major ABI is listed here as containing the same mistakes. I'm inclined to think the people who designed these ABIs were smart enough to understand the consequences of their design decisions.

I don't know whether this author is correct or not, but my gut is there is something missing here with respect to non local control flow (like exception handling, setjmp/longjmp, and fibers).

And Apple replaces the entire motherboard if a component on it fails. The agreement that you may lose data has been around awhile and it's just boilerplate. When mucking around on a board they aren't going to guarantee anything - and I don't know if third party repair shops would do that either. There is always the chance someone screws up and breaks something.

I think AR/VR is that it's being used like film was in the early 20th century. There are obvious technical challenges to overcome, but what it lacks is an industry of creators and auteurs to define new forms of art. The mistake is that the revolution will be driven by artists working out of garages and warehouses, not VC funded startups that only focus on technical challenges trying to corner the markets.

> rather than being completely unaffected by S[n]? Is n here a discretization of time or a "meta-time" that captures state progression?

It would be remarkable if the "next state" of the universe did not depend or was so correlated to the "current state" that symbolically we represent it as a dependency. A ball only rolls downhill because it was once uphill, after all - one of the few things that unites various models of the universe was the existence of causality.

> If the former, then you are treating time as a primitive, whereas the representation or even existence of time can be part of state and vary over state changes, so this does not work.

This is interesting but I feel reductive. the "nth" state is not the state at time n, but the state that follows n-1 - it is dimensionless, but one might express it in spacetime if that is convenient. Nothing suggests it is uniformly sampled or even computable.

> completely independent from each other is indistinguishable from a multiverse with inaccessible sub-universes and should be called as such

No idea what this implies, but in a non-deterministic state machine there are multiple S(n + 1) for any given S(n).

> you are also assuming linearity and discreteness of state changes, whereas it could be a DAG or more complex structure.

GP does not suggest evolve(S) is linear or discrete (they suggest either continuous or discrete, actually). Neither of these imply anything about topology so I'm not sure what that has to do with a DAG. State transitions can encapsulate arbitrary topologies (and vice versa). They are duals.

> rather than a more chaotic or unstructured universe that behaves more like a disjoint set than an orderly structure

I feel GP covers this base by mentioning that state transitions may not be deterministic. Just because a system is chaotic or unpredictable does not imply we cannot formulate the nature of its chaos or unpredictability symbolically.

If you're on Linux, musl libc and musl-tools are useful for dealing with this reliably.

About on par with C/C++ and Go. In that you don't have one and don't want for one. REPL driven development is difficult with languages like Rust, both to implement and use.

I think there are some projects floating around out there, but I personally don't see a purpose for one. It's not python or matlab.