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?

You can also cheat it by introducing a null statement that consists of zero tokens; then "a;" is really the same as "a;null", and it's still a separator - even if it behaves as a terminator in practice.

It's a useless trick in a statement-oriented language, but in expression-oriented ones, where it's all expressions and not statements, it's useful to be able to define";" as the sequencing operator that evaluates left side first and right side second, and then returns the right side.

In Pascal it actually made some sense, since the main program was wrapped in begin .. end. - with a terminating period. So the entire program was the "sentence".

Why does it look strange? It's the standard mechanism adopted by every single mainstream PL by now.

And how would you handle them otherwise? Do you prefer just passing in a function pointer / method reference? You can do it too in Java 8, it would be something like SetOnActionEvent(this::eventHandler).

"dynamic" in idiomatic C# is rare, but still very useful for those cases where you do have to interop with some data structure with a dynamic schema (e.g. JSON). But the main reason why they added it was in fact easy interop with COM IDispatch, and dynamic languages like Python or Ruby. So you usually have it at the transitional boundary or at the site where you crack open the data, but from there you stick it into something strongly typed.