What about people who are colorblind?

What about people who see color on four dimensions instead of more common three?

1) Glance at the touchscreen to find the button you want.
2) Put your thumb below the touchscreen, aligned with the button you want vertically.
3) Look back at the road.
4) Rotate your hand a little to place your index or middle finger to where you want it to be, without looking.
5) Tap.

That said, steering wheel buttons are better.

This is awesome. Not so much for running a word processor in a browser, though that is nice. The awesome part is that it probably means they have a robust widget set compiled to WASM. The world has been really, really, really needing a robust widget set for WASM.

The browser has become a near-universal client. Programming for it with Javascript+HTML+CSS is a mess. We put up with this, so endusers don't have to install anything. If we can get WASM to take off, it'll be a much better alternative. It'll still require no software installs, but have a much more rational programming model.

> Even if you go the hardened route of SSH or an X connection, you have to keep track of where they all are. What is there to remember? If you use ssh at the command line, just slap the hosts in your /etc/hosts or other naming facility.

PuTTY has been available for Linux for a long time too - nothing to remember there.

Or use the one I wrote: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fstromberg.dnsalias.org...
It can start a remote shell from a menu in 3 clicks, if you count the click for starting it up.
It sets up X11 tunneling, and can do multi-hop ssh - nice if you have a bastion host to hop through.
It also can set up tty logging, and $PS0, which is great if you have to do a "what happened when" post mortem.

Actually, for sufficiently large inputs, AOT implementations and JIT'd implementations are the same, perfomance-wise. Keep in mind that a JIT has access to runtime info an AOT optimizer (usually) doesn't.

But there's nothing that prevents an AOT implementation from inserting a JIT, and there's nothing that stops a JIT from doing whole-program analysis.

Again: for sufficiently large inputs.

No, it's not "utter BS".

in C if you want to pass an array to a function, you either need an array of pointers to arrays, or you need to act sort of Pascal-ish and treat the dimensions as part of the type. Most C programmers would opt for the former, not the latter.

Granted, it's been decades since C was my favorite language. Maybe the situation has improved?

People used to say the same about hand-coded assembler.

That's mostly what I was taught in school - but there was a brief aside, one day, saying that sometimes a worse algorithm could be faster if it, for example, stayed all in memory instead of hitting disk.

EG, Python has a list type, which is kind of like an array, but the types can be heterogeneous, and they resize automatically. They're much faster than a linked list in Python, even though many algorithms that repeatedly append to a list are amortized O(n). Underneath it all, they're O(n^2), because to resize a list sometimes you have to copy it, but the memory latency of a list is great because it's contiguous memory locations.

Linked lists in Python are pretty slow, comparatively, because each element of the list is in noncontiguous memory. That is, traversing the linked list from beginning to end is a different cache line hit for (almost?) every element.

ISTR hearing that Codon cost money for commercial use. Also, ISTR that it doesn't support much of the python standard library.

Also, it's not sounding that different from Shedskin and Cython, which do have at Least some standard library support.

Also, when a program running on CPython is running too slowly (which isn't that common), you just profile and run the hot spot on something like Shedskin, Cython or C - it's very rare to need to rewrite the whole program in another language.

Building your own seems like an attractive option, until you realize how hard it is to eliminate the possibility of heat problems when just slapping together some components that "should work".

Buying a Windows system and reinstalling it with Linux seems like an attractive option, until you realize that this pads Microsoft's installed-base figures, which in turns contributes to developers only releasing software for Windows. Also, it contributes to computer companies having few to no Linux preinstall options, which means that if Microsoft tries to make it so you CAN'T run anything but Windows on a computer, the computer companies won't push back. Microsoft is NOT above this.

As far as a Linux-preinstalled computer company goes, I used to buy from PC's For Everyone (they stopped selling Linux preinstalls and changed their name), then I started buying from ZaReason (they went out of business, and they'd been using cheap CPU fans that had to be replaced eventually), and... most recently I got a computer from Think Penguin.

I've been using my Think Penguin system daily since November 2021, and I've been quite happy with it, and I love it that it's not contributing to Microsoft's monopoly.

There was a time when Firefox was my main browser. I tend to open a lot of tabs on a large virtual desktop, and leave them open for days. Firefox's crashes were a problem for this, so I switched to Chrome and Chromium - mostly Chrome. I recently gave Firefox another try, and found that it was still too crashy, so I went right back to Chrome.

I've posted elsewhere here on a mere smattering of the better ways of speeding up Python code.

The more important point is that Developer Time is much more expensive than Machine Time, so it makes more sense to use something you can code in rapidly and effectively.

I used to think assembly language was the bee's knees. I got over it. You likely should move on too.

There's currently a project to make CPython faster, with Guido Van Rossum heavily involved.

I think the most important for Python's future, more than runtime optimization, is HPy: a better API for Python: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgithub.com%2Fhpyproject%2F...

Granted, it'll take a while to move most "C Extension Modules" to HPy, but it should allow runtime developers a great deal more latitude in creating faster runtimes.