It's a good article because it talks about the differences between type systems in more depth than you normally see and it makes some excellent points in a section examining fallacies.
One particular fallacy that stood out for me was about how developers use dynamically typed languages:
Fallacy: Dynamically typed languages are weakly typedThe emphasis is mine because I see a lot of CFers get very tied up on this point and start using such horrors as pseudo-Hungarian prefix notation to "solve" a problem that simply doesn't exist.The statement made at the beginning of this thread was that many programmers have used dynamically typed languages poorly. In particular, a lot of programmers coming from C often treat dynamically typed languages in a manner similar to what made sense for C prior to ANSI function prototypes. Specifically, this means adding lots of comments, long variable names, and so forth to obssessively track the "type" information of variables and functions.
Doing this prevents a programmer from realizing the benefits of dynamic typing. It's like buying a new car, but refusing to drive any faster than a bicycle. The car is horrible; you can't get up the mountain trails, and it requires gasoline on top of everything else. Indeed, a car is a pretty lousy excuse for a bicycle! Similarly, dynamically typed languages are pretty lousy excuses for statically typed languages.
The trick is to compare dynamically typed languages when used in ways that fit in with their design and goals. Dynamically typed languages have all sorts of mechanisms to fail immediately and clearly if there is a runtime error, with diagnostics that show you exactly how it happened. If you program with the same level of paranoia appropriate to C - where a simple bug may cause a day of debugging - you will find that it's tough, and you won't be actually using your tools.
(As a side comment, and certainly a more controversial one, the converse is equally true; it doesn't make sense to do the same kinds of exhaustive unit testing in Haskell as you'd do in Ruby or Smalltalk. It's a waste of time. It's interesting to note that the whole TDD movement comes from people who are working in dynamically typed languages... I'm not saying that unit testing is a bad idea with static types; only that it's entirely appropriate to scale it back a little.)
The article is a good read and it should help you get a better grasp on the benefits of dynamic typing (and static typing) and, more importantly, benefits that CFML brings to the table.
TotAmount
... and some people use:
TotalAmount
to me, the latter is not unnecessarily long - it's a more valid name. TotAmount would be the amount of "Tot" or it could be the abbreviation for "total". If I'm jumping into a project for the first time, I might not know the domain too well and would love to have the longer, more explicit names. Why should there be *any* guess work to the name of a variable?
The article is talking about the practice of creating very long variable names that include descriptions of the 'type' of the data in the variable.
