Which prompts today's trivia question:

What British cover of a old American blues song starts off with what may very well be the greatest drum break in the history of rock and roll?

It checks one low-level layer of cases out of a whole conceptual stack that extends way up beyond any language definition, and even then only at certain spots, and only as long as you feed in the correct assumptions for the check cases themselves.

In other words, it does a little thing that computers are already good at. It does little or nothing for the big picture.

That's very true. I figure that the only way to make significant software projects look "easy" will be to develop sufficiently advanced AI technology so that the machine goes through a human-like reasoning process as it works through all of the corner cases. No fixed language syntax or IDE tools will be able to solve this problem.

If the requisite level of AI is ever developed, then the problem might be that the machines become resentful at being stuck with so much grunt work while their meatbag operators get to do the fun architecture design.

Sounds like these people would benefit from something like a visit by three ghosts on Christmas Eve.

You don't expect them to give access to advanced features such as file system subdirectories for free, do you?

tl;dr shld b 32 chr max #attnspn

I'm not copying and pasting. I'm using things like Ctrl-P to do code completion without having to type out the full name. Maybe I shouldn't have used the term "copy".

I tried that, too. It still won't let you write in readonly mode without warning you.

Not really. Most code is highly repetitive, and I typically copy far more words than I type out. I use various shortcuts to create most of the common syntax constructs of the languages that I use.

Moreover, developing software is usually an iterative process, where more effort is spent on revising the code than on entering it.

My whole point was that normal mode is far more powerful than insert mode, and it allows you to accomplish many tasks with a small fraction of the typing you would need with only insert mode.

If you have any issues with RSI, then vim is by far the best editor (especially the GUI mode version).

The command mode allows you to formulate in your mind what you want to do, and accomplish it in the minimum possible key strokes. This is important because your brain won't wear out like your joints and tendons can. The command mode usually allows you to specify repeat counts to avoid repeatedly mashing keys. It lets you make common text selections such as words, nested brackets, statements, etc with a couple of key strokes. It also allows you to create macros on the fly and repeat previous commands further cut down on repetition.

I find that reaching for the arrow keys puts my wrists at an awkward angle which induces more stress. Having to pound on them repeatedly while holding down various combinations of control keys makes things worse. (To address a common complaint with vim, I've added a mapping of Alt+F to ESC, so I don't have to reach up for that key if I don't want to.)

I probably spend more time in command mode than insert mode when I'm using vim to write code. That says to me that keeping an editor always stuck in insert mode may not be the best idea.

I tried your scenario.

If play your boss and I exit with ':q', no problem. Your version is still there.
If I exit with ':wq', vim says: "E45: 'readonly' option is set (add ! to override)"
If I exit with ':wq!', vim says: "WARNING: The file has been changed since reading it!!!
Do you really want to write to it (y/n)?"

So I conclude that one of the following is likely the case:
a) your boss is was an idiot who would ignore a message ending with three exclamation points
b) you boss installed a bizarre custom vim config file that somehow allowed silent overwrites of modified files from readonly mode
c) your story is a fabricated troll

So now you get the "best guy" for the cost of a faceless drone plus some nominal administrative overhead. That's still much cheaper than having to get a "best guy" by a more conventional route, such as enticing the top staff of your competitors to come work for you with higher pay.

Moreover, you focus on a single case. However, in aggregate, there is no doubt that increasing the supply of workers for a particular field will lower the average salary paid for everyone. So companies can hire everyone at lower salaries.

Acceptable to you or not, that's how it would be done physically.

Your acceptable solution involves a discrete math system. That's fine, but the safety of those children still shouldn't magically depend on whether you allocated them as Python ints or floats.

In the real world, 5 / 2 == 2.5. This is true whether the operands are integers or floats.

In some discrete math systems, 5 / 2 == 2.

A language has no way to really know what kind of problem you are working on and which calculation would be more appropriate. Python 2 made the assumption that if you fed in two integers, then you were working in a discrete math system. This turns out to not usually be the case, and was a source of surprise and bugs for many people. (Python 2's division was modeled after C, which is still problematic, but at least C's division behavior is lexically determined by its static typing system, so it's usually somewhat less surprising. However, it would have been more clear if C had based its decision on the type being *assigned* to.)

With Python 3's implementation, it's always explicitly clear which kind of math you're doing. If your problem's math system depends on the types of the operands and you need to do type checking, then so be it. At least it's clear what's going on.

Looks like it'll be annoying to wear for long (5+ min.) durations.