Month: February 2014
Fixes the Wrong Problem
Who Maintains Type Definitions?
== is still there and still has the shorter more natural syntax than the strict equality operator
===. There is still the strangeness of semicolon insertion. In some cases, the additional features actually make it more likely a developer will adopt the wrong mental model of the language semantics and walk right into a mine. Classes make the unchanged behaviour of the
this keyword more confusing. For example, in a class like
Greeter from the TypeScript playground, the use of
this is confusing:
One can’t help but feel the
this keyword in the methods of
Greeter should always reference a
Greeter instance. However, the semantics of
The above code displays “Hello, undefined” instead of the naively expected “Hello, world”.
However, if either variable has type
any it will not produce an error and continues to evaluate loose equality. For those not familiar with TypeScript,
any is a special type that can be either an object or a primitive like a number etc.
Not the Answer
When I was starting out as a programmer, I learned and worked in C++. There weren’t that many options for Mac OS 7 development at the time. I had a copy of MetroWorks CodeWarrior. It sure beat MPW, which was Apple’s own development environment. For languages the choices were pretty much Pascal, C or C++. Perhaps Pascal would have been a better first language to learn, but that’s not what I picked. As I really learned C++ and began programming in it, I discovered that C++ is a very large and complex language. Why? Well, there are a number of reasons. One is that it follows the zero overhead principle, basically “What you don’t use, you don’t pay for.” That means every language feature has odd limitations and pitfalls to make sure it can be implemented in a very efficient way. Another is that, due to the focus on low level efficiency, there are no safety checks built into the language. So when you make a subtle mistake, which is easy given all the weird edge cases, the program compiles and silently does the wrong thing in a way that maybe succeeds 99% of the time but crashes horribly the remaining 1%. Finally, the language is designed for maximum power and flexibility; so it lets you do anything, even the things you shouldn’t do. This produces a programming minefield where at any moment one might be blown up by some obscure behaviour of the language. Because of that and because other developers and the standard library make use of every language feature, one must learn the whole language. However, C++ is so big and convoluted, learning it is really hard.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off.
No Safe Path
When Maps Fail
for in loop without checking
hasOwnProperty because you mistakenly think that it is safe in your particular case. Beyond that, the human mind just isn’t set up to handle situations where things do not match their names. No matter how many times I tell myself that the
this keyword doesn’t mean this, my brain still falls back into thinking of it that way. It’s as if someone put a sign reading “Cave Tour” over the bear den. When I’m busy talking to my friend, thinking about how hungry I am and trying to find the cave tour, I’m liable to walk into the bear den no matter how many times I was told the sign is wrong. The fault isn’t with me, it’s with the sign.
Can We Clear the Minefield?
- Clear the minefield
- Go to a different field
- Build atop the minefield
This article is Part 1 in a 6-Part Series.