hctaw

I'd quibble with whether folks understand the performance implications. I think most people know division is expensive. It's just non trivial to remove it. If it was that easy to replace, it would be done in hardware and division wouldn't be expensive anymore.

I think the problem is equating "coding" to "algorithmic thinking."

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.

It's a task more commonly found in computational geometry (3D range query == find all the points in a data set enclosed by a cube).

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.

Efficient 3 dimensional position or range queries (line/column/page) is a pretty well studied problem. You don't need to query every point of the space to answer anything.

Google docs is their document editor. Sheets is a part of GSuite.

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.

I feel the need to argue that the browser is not the browser engine. An app sitting in a chrome tab is significantly different than an app built on electron, they just share some rendering code paths.

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.

Microsoft Word, Pages and Open Office don't seem to be bottlenecked by rendering performance like Google Docs. Perhaps the browser is the wrong platform for document editing.

> it is not unless your security model is one where codesigning exists to prevent the addition of new native code

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

Doesn't the referenced data have to be guaranteed to outlive the callee, which would only be true if the callee is guaranteed to return to the calling scope?

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.

I'm reminded of Chesteron's Fence in this.

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

What chips can be targeted by C compilers today that don't use 2's complement?

Having a mostly statically linked executable handle this rather than some bastard child of virtual environments and docker images is a dream come true.

Time Machine can't run on my Mac because there's not enough space on disk for it to run. Third party backup services that can function with the comically small default SSDs are preferable.

You have to backup more regularly than every two months...

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.

My point of the analogy is that film was an entirely new medium for creators a century ago and while the projector and camera manufacturers came up with the idea of a cinema, it was the artists that made something worth showing.