ken

You joke, but I've wondered the same thing. Apple, of all companies, is happy to re-examine (or discard) the status quo. They dropped the headphone jack on many products -- as they said, it's "over 100 years old, used to help quickly exchange in switchboards". Yet their keyboards still look pretty much like a 19th-century Remington.

What point are you trying to make? Systemic racism is way bigger than just police killings.

Do you want to ignore the (non-lethal) evils of prejudice, and just play a numbers game with fatalities? From some back-of-the-envelope math, the average POC in America will still lose more years of their life from simply living in a racist society than from COVID-19.

Life isn't a pissing contest of "my problem is bigger than your problem".

I never understood why ortholinear keyboards aren't the standard. It's bizarre that the fingers on my left hand would move slightly to the left for the top row, but the fingers on my right hand would also move slightly to the left for the top row. And to the right, on both hands, for the bottom row. Fingers don't naturally move like that! My hands have mirror symmetry. Why doesn't my keyboard?

The number 6 exemplifies the problem. Touch-typing classes teach that it's pressed by the right hand, but the number row has drifted so far left that it's actually closer to the left hand. Sure enough, (non-ortho) split keyboards can't agree which side of the split to put it on. Sometimes even different models from the same company disagree.

Staggered keys is even crazier, to me, than QWERTY. There's no spending 2 weeks relearning where every letter is. There's no messing up spatial mnemonics like Z/X/C/V. It just instantly fixes your fingers from being slightly out of alignment.

And the craziest is when touchscreens do it. Keys were only staggered in that funny way to make room for the keylevers. Computer keyboards never had keylevers, but touchscreens really never had keylevers!

You're trying to exploit a slippery slope. There are many churches which have had no such scandals, and are not associated with any who have.

Just because Monitor (dozens of offices, thousands of employees) worked for Gaddafi doesn't mean "John & Jane's IT Setup Helpers" around the corner must also be an inherently immoral institution.

And the tester just happened to pick two friends, who live 20 miles apart in different cities, who have never ordered from the restaurant? That is both a remarkable coincidence, and a bizarre choice of test data.

> You do not communicate the full state of your system or even a small portion thereof when you use speech.

Right, but that's not even the purpose of speech. Abstraction is a feature, not a flaw.

Even with electronic systems where perfect and complete transfer is possible, we prefer simplified serialization of messages.

> So whatever the feeling of "I'm being direct" or "I'm being clear" is, it is almost certainly itself faulty. We're not built for that and language isn't either.

I half-disagree with you here. Given that language is so ambiguous, it's admirable to try to reduce unnecessary ambiguity, when your goal is to communicate a specific message.

Cool idea. Would you also limit the volume of the computer to typical human skull capacity?

A window manager may be only 2000 lines of source code but it implements a host of formal and informal standards and interacts with hundreds of other programs on my computer.

You may need only a day or two to orient yourself to the source code, but that’s on top of months or years of experience with X11R6 and ICCCMv2 and EWMH and such. How much debugging did you first need to do to discover your current issue was even in dwm?

EDIT: I especially love the phrasing in Wikipedia's ICCCM article: dwm "can be configured for compliance". If 'configuration' can include editing source code, I'm sure that's true!

> Their window manager dwm is just a window manager. It doesn’t handle things like transparency, compositing or volume control.

That is a strange division of labor. I thought transparency and composition were aspects of window management. What else would they be?

That's sort of true, in the abstract, but it wouldn't explain what's going on here. Even JavaScript (with a JIT, but not a separate compilation step, and certainly no type annotations) is faster at this than compiled Crystal. There's clearly other factors which are much more significant than simply having a compiler.

Maybe, but these two languages don't exactly have similar semantics.

You can't make a Ruby program that uses fixnums-only. You also can't make a Crystal program that's dynamic like Ruby. Interestingly, though, when the Crystal implementation is modified to use bignums, the Ruby implementation is over twice as fast while still being dynamic.

What I get from this is that Crystal's static compiler is slower than Ruby's dynamically dispatched interpreter, and Crystal's bignums are so slow you'll need to think hard about whether you want a 50x speed boost or correct arithmetic in all cases.

I think Crystal is a good concept, but it's only version 0.34.0. Every implementation is bad at version <<1.0. Ruby <<1.0 didn't have good performance, either. I'm sure Crystal will be great by the time it gets to 2.6.5, too.