anaphylactic

Yes, and this is a bit obvious, but reals, complex numbers, split complex numbers, quaternions, octonions, sedenions, can all be represented as matrices of the appropriate form.

Yeah, octonion multiplication is alternative.

I don't know, I was requesting clarification for the line "people will exploit themselves".

> There the game stops. Proof surfaced in 1898 that the reals, complex numbers, quaternions and octonions are the only kinds of numbers that can be added, subtracted, multiplied and divided.

1. I think they meant "the only kinds of numbers constructed in this way". 2. Sedenions can still be added, multiplied, subtracted and divided. it's just that multiplication and division lose most of their useful properties. With octonions you've already lost associativity and commutativity, though.

So let met get this straight - you're telling me that people are staking their livelihoods entirely on Uber, and none of this is Uber's fault, it's just the people who are idiots?

No!

- Parametric polymorpism isn't OOP, pretty much every halfway-decent language has it (including Haskell, which is as functional as they come).

- Boxing in Rust isn't what you think it is - it's just heap allocation (more like malloc than the monstrosity that is boxing in Java).

- Again, operator overloading isn't OOP either. Seriously, is it that hard to believe that "you get to use + and - with your own types" is an expectation independent of any paradigm?

> I must have gotten the wrong idea.

Yes. Go and Rust are both very far from what most people would consider "OOP".

That's a good point, and it's not just a problem with C++. As any project matures, the voices of current users drown out the voices of new users, and as a result discoverability gets thrown out the window. How would you engineer a project so as to avoid this fate?

I disagree. If a perfectly good optional type can be implemented without making new syntax, why bother making new syntax? It obscures what's going on under the hood, makes implementation needlessly complex, and increases mental overhead for users.

I believe (hope) that OpenGL continues to be that developer-friendly API. Building OpenGL on top of Vulkan shouldn't be too hard, and it means we don't have to pointlessly deprecate and recreate the huge number of OpenGL resources out there.

I know this comment is rather inane, but rarely have I seen a library name so fitting yet so humorous as "burgled-batteries".

I think the parent's trying to tell you guys not to sell yourselves short - that what you're doing is exactly what mathematics is.

I'm guessing XML doesn't count as a text-based file format? Otherwise, that's what every office suite (technically a zip file of XML files, but that's splitting hairs), vector editor, and graphical HTML editor already does.

Anyway, I especially like the `sc` spreadsheet format and editor as an example of a GUI tool that works with text-based file formats. Despite the giant disclaimer at the top of each file saying not to edit it, it's shockingly human-friendly.

I don't understand what your concern is - this only took me about a minute to write and it looks completely safe and efficient.

https://play.rust-lang.org/?gist=674f4b88876614f603fd70368cb...

Maybe is just another Optional type, but with a much weirder name, so that's pretty obvious. But this makes me wonder - does Haskell optimize `Maybe`-like types down to a null-pointer, like Rust does?

Optionals are sum types, too! No special-casing there. It's just that Crystal just has anonymous sum types, I guess, which can be a lot nicer to look at.

Runtime performance will obviously vary across platforms, but in all cases, at least the executable will be much, much smaller! :)

It's not foolproof but this tool needs to be more widely-known - it would've saved me on countless occasions.