Bender from Futurama: "Wouldn't it be better to use a potato? Or a battery?"

I probably doubled popularity of Python in all these lists few years ago because I had to google literally everything that was more complex than a=b+c...

I dropped ST-225 and head 0 got damaged. I had to install inverters in both head select signals on the drive so the unusable head was now #3. BIOS didn't like the idea of head #0 being bad. I also wrote a driver for modified drive parameter block telling the DOS that the disk only had 3 heads. 15MB total instead of 20MB but it worked. Later I 'upgraded' my XT to 486. The PC did not have regular chassis, it was a frame built from random aluminum rails. Mounting holes for new motherboard lined up with holes on XT motherboard so I installed 486 straight on top of XT on standoffs.

I'd say C/C++ are weakly typed because you can always convert one type into random other type. Java/C# only allow limited conversions between related types.

I would divide general purpose languages into categories (not all fitting languages are listed): 1. Assemblers 2. C, C++ 3. Java, C# 4. Python, JavaScript 5. Perl, TCL Anything that is not like the 5 categories above is not worth categorizing.

SourceTree 1.10. Tried 2.x and 3.x and upgraded them back to 1.10.

Norton Commander was ok, now most of that functionality is in FAR Manager, I use it all the time.

Few years ago I almost wanted to run away. Needed one for my wife, she had few simple requirements: Windows 7 (she tried Windows 10 and hated it, and it made my life harder as well), 1920x1080 screen, and few would-be really good options: non-glare display and back-lit keyboard. After some time managed to find one of last Dell Precision laptops ever made that matched all 4. Upgraded HDD to SSD, the rest was good enough as we got it. No problems with that laptop.

You're missing the point. A misplaced space in Python completely changes the structure of the program. In curly braces languages you can format the program as an ASCII art, and it still works just the same.

Syntactically Python is one of the worst languages that are developed recently. Maybe there are others like that, I don't know. This is one of the languages where 'nothing' matters, as in white spaces define the structure of the program. Code reviews are made almost impossible because instead of answering a question 'is the program structure as-is correct?' you need to answer a question 'which of all possible structures would be correct?'. Simple yes/no becomes 'design same program that you're reviewing on the spot and see if you come up with same result'. Example:

if (x)
something()
somethingelse()

Should somethingelse() be indented like this? If that code is already indented by 5 levels, maybe somethingelse() needs to be pulled back one level? two? three? People can't indent properly in languages where indentation is not important (curly brace languages, for example), and you'd expect them to indent something correctly where it is important? The initial hype came by showing: look, it's simple, i type '2+3', it prints '5'. An over-glorified calculator. Next, they print 'hello world' and see on console 'hello world', and it only takes one line of code instead of 10. Great. It makes simple things simpler and hard things almost impossible. There are tons of libraries written in Python, but i haven't seen data about how efficient Python is for developing these libraries, as opposed to some languages with static typing. Less lines of code does not mean it is overall efficient. Look at code golf on Stack Overflow, they solve small but relatively complex problems there using programs written with 10-20 Unicode characters that are incomprehensible for most developers. Writing a program is about 10% of the effort, maintaining it is another 90%, and languages should be such that maintenance is easier. Maintenance is not 'figuring out what the program does'. That part is trivial, run it through debugger with single-stepping and you see what it does. Maintenance is like any other reverse engineering, where you try to 'figure out what the developer was thinking when they developed that program'. With the example above it is not possible to say for sure if somethingelse() was thought of being part of that condition block or not. You'd need to reverse engineer the entire algorithm in that function, then think if you'd do it in the same way, and if you disagree, you'd do it differently, probably introducing more bugs because you don't have any guidance about original thinking. There