This seems perfectly logical to me. There's nothing about "UNTIL" that implies that condition will be tested after the loop - the only meaning that the word carries is the negation of the condition. I suspect that this confusion comes from Pascal, where "repeat .. until" was the way to write loops with condition testing after the body - but there it was more a quirk of a language, and "until" by itself still just meant negation of the condition; the order of evaluation was defined by the relative ordering of parts of the loop in the syntax:

while condition do staement;
repeat statement until condition;

In your example, "perform until condition" comes before "statements", so it makes perfect sense to check the condition first.

The best syntax for such loops was actually in MS dialects of BASIC (QBasic, VB etc) - it had WHILE, UNTIL and pre- and post-conditions in all the possible combinations, as well as infinite loop, all syntactically uniform and very obvious:

DO
..
LOOP
 
DO WHILE condition
..
LOOP
 
DO UNTIL condition
..
LOOP
 
DO
..
LOOP WHILE condition
 
DO
..
LOOP UNTIL condition

This is because "GO" is not actually a feature of Transact-SQL (the language itself) - it's a feature of the command line REPL, to signify end of input and beginning of execution. So it's not parsing the SQL there, it's just looking for a line that matches "GO", and then takes all the preceding text and hands it over to the server - which then actually parses it as SQL.

Callback pyramid is not a language feature, it's a framework feature.

And it does actually make it asynchronous. I'm not sure what you even mean by "magic" - there's nothing magical about callbacks, it's a pretty obvious idea that just took a while to catch on. If you want actual magic in the same vein, that's C# "await".

It's kind of quirky, but at least it's better with JS where you have blocks and variable declarations inside those blocks, but for some mysterious reason the variable declaration is not scoped to the block in which it is declared, but to the entire function. You'd think that the sensible thing to do would be to either disallow "var" inside blocks and require it to be on top level (and, since it's visible throughout the function, at the beginning of it - like in C89), or else to do proper scoping like Lua did. In Python, the scope is implicit but it doesn't lie.

And, of course, they did add "nonlocal" in Python 3 for those cases where you really do want to assign to an outer variable.

It's not about "copy deep" - it's about the fact that your variables are references to objects, not objects themselves, so copying copies the reference. It's the same exact thing in any language with reference semantics, including C#, Java, Python etc.

(Sometimes I wish we made it standard to make that referencing explicit in type declarations, even though it would have to always be there and so be redundant - but at least it'd remind people that they're dealing with references!)

The real WTF in VB6 was the difference between "Let" and "Set" - the fact that you had to write "Set x = y" vs "Let x = y" (or omit the "Let", since it was the default) depending on the type of "y" - "Set" for object references, and "Let" for everything else. The double-WTF here is that the version with "Let" would in fact compile and run if "y" was an object and "x" returned an object, as well - it just wouldn't do what you expected it to do, but instead assign "y" as the new value of the property of "x" that was designated as a default (and only fail if there was no such property). The triple-WTF was that, when variants were involved, the behavior was decided based on the actual runtime type of the assigned variant. And on the other side of that equation, when defining a property setter, it was actually possible to define two separate methods handling the "Let" and the "Set" (I'm not actually sure if it was so in VB, but you could definitely do it when authoring a COM component in C++, and VB would then understand that).

All so that people could write things like "textBox = 123" instead of "textBox.Text = 123".

This is still normal behavior for most C/C++ compilers for IEEE platforms. It is also the expected behavior for Java and C# both. It's just much easier (and faster) to do floating point math if you don't have to truncate every intermediate result to fit the original precision on platforms where it is not normally the case.

I actually prefer to think of it in reverse: there's only one operation, and that is "copy", but there's also only one data type for storage locations (like variables, list elements etc), and that is a reference. So you're copying the references around.

By the way, (C)Python doesn't do any kind of fancy tagged pointer representation for integers regardless of their size - they're always pointers to an actual PyLongObject value. However, it does preallocate a bunch of "small integer" values in a static array, and for many (but not all) code paths it will give you a cached value. From the language spec point of view, the meaning of "is" for integers is basically implementation defined (and not really useful at all, since, them being immutable, there's nothing meaningful that you can derive from comparing them for identity).

The standard didn't decide to change it - the old behavior predates the standard (assuming that we're speaking about the ISO one here). ISO C++ always required the second interpretation, but it came fairly late in 1998, and a lot of code was already written using the former, so many compilers didn't switch right away.

It was particularly bad on Windows, where VC++ 6.0 (also shipped in 1998) was such a compiler, and it also happened to be the one on which many people stayed for many years to come, taking a strong dislike with newer versions shipped with VS 2002 and above. On the other hand, some people actually hacked the old compilers to make this work, by doing something like:

#define for if(false);else

Then every for would implicitly be inside an else-branch, which guaranteed its own scope. But doing that before including any third party headers would break them if they had inline functions, so you had to be very careful...

This is actually a generic problem with JavaScript (of which ActionScript is a derivative). I don't know whose smart idea it was to introduce the notion of local variable declarations and code blocks, but then completely ignore the interactions between the two.

And JS doesn't get a pass for being dynamic. I know of at least two languages which get this right. In Lua, "local" declarations are actually scoped to the block they are in. And in Python, all variables are local by default unless declared global, so there's no confusing local declaration that looks like it's scoped to something that it is not actually scoped to.

The good news is that they're fixing it in ES6 with "let".

Unfortunately, he's right in that many other languages have adopted the same rule, that if one operand of + is a string, the other can be anything and will be turned into a string. Java and C# are two particularly prominent abusers.

It's not undefined - it won't even compile. Pointer arithmetic does not allow the addition of two pointers - the operation is meaningless. You can subtract a pointer from another pointer (the result being an integer difference), or you can add an integer to a pointer. This is definitely true for any version of ANSI/ISO C (including those before C99). I think it's also true for K&R C.

Your last two examples add together an int and a double - where did you see any string there, much less an implicit cast?

C# will indeed let you apply + to an arbitrary object, so long as another operand is a string, and will convert that other object to a string by calling ToString on it (or using an empty string if it's null). This is the same behavior as Java. It is bad, but not so bad as JS, in which strings can also magically become numbers on the right context.

Of course JS knows what types A and B are, it just happens at runtime. The behavior is fully deterministic every time, it just so happens that it varies with inputs, and therefore can differ for subsequent evaluations of that same expression (but, again, every particular evaluation is still deterministic).

JS sucks because it won't tell you that you're being a moron. Since that's where most people start their careers, using a language like JS (or PHP) leads to them believing that their moronic habits are really "best practices" and such, and results in heaps of unmaintainable code.

How is iota any better than the conventional C-style enum syntax (or better yet, true ADTs), other than being quirky?