Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday October 22, 2004
09:15 AM

Bruce Eckel on "Latent Typing"

[ #21472 ]

I really need to read Bruce Eckel more often. Being a Java guy, he may not be the most popular person here, but he has very good things to say. Some of those things are very Java-specific. Most here don't care about the erasure problem in Java's Tiger release. However, many of his articles discuss programming in general and are quite applicable to us. In fact, he's becoming a bit of a convert to dynamically typed languages (er, Python, to be fair.) He has a great article about "latent typing" (a.k.a., dynamic typing) which is definitely worth a go.

One interesting point in the article is reinforcing that a Class is merely a new type. However, because of polymorphism, we have something a bit closer to dynamic typing. When OO programming first came on the scene, there were arguments that it would make things worse because the programmers wouldn't know if their object.shoot() method would go "bang" or "click." Few people today argue this about 00 programming, though this argument should sound somewhat familiar to dynamic typing enthusiasts.

The key difference, in Eckel's view, is whether we desire "directing" (telling programmers what to do and protecting them from their mistakes) or "enabling" (giving programmers the tools to get their job done faster) technologies. Both are valuable; each has flaws.

Some people, though, just don't get it. In this c2 article about latent typing, Chris Handley writes:

So in summary, LatentTypes sound great, but they leave such much information unstated (and in fact unchecked) that (a) the programmer is required to spend a lot of extra effort when writing code, and (b) they also leave programs wide open failing as soon as someone changes a seemly trivial implementation detail.

For the legions of good Perl programmers out there, this will come as a bit of a surprise. Of course, this person also wrote a criticism of OO programming where he claims "OO is based on some ideas that are catchy on a small scale or in toy examples, but they don't scale to the real world well, requiring many layers of indirection to work around their limits." I wonder if he and Shlomi Fish are friends?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The Ruby community refers to this as "Duck Typing", i.e. if an object walks and talks like a duck, then the interpreter treats it as if it were a duck.

    In fact, this has become such a prominent issue among Rubyists that the latest version of "Programming Ruby" has its own chapter devoted to Duck Typing.

  • It's worth noting that one of the things that helped push Bruce over to the latent typing side was unit tests. Once you have good unit tests, static typing gets in the way more than it helps.
    • Interesting you should mention that. I've been giving a lot of thought to that and I realized that one of the benefits of strong typing is that it is a form of testing. It's awfully tough to add 3 to an IP address in Java. Not so in Perl. Specifying types in signatures (for example) makes this type of bug more unlikely in strongly typed languages. However, given that we should be writing unit tests regardless of how the language handles typing, this argument goes the way of the goto.

      • Typing is only as good as your type system. If programmers can define their own types, they can make mistakes in their definitions.

        Maybe it's a little bit safer that way with enforced static checking, but Java took six major releases of the language to provide any sort of type-safety on collections of objects (and I'll be blunt, preprocessor-inserted casts to and from Object aren't type-safety, they're typo-safety). It's difficult for me to believe that it's worth the price.

      • That's a really bad example. An IP address (v4, anyway) is nothing more than a 32 bit unsigned integer. Adding 3 to it is a perfectly legit operation. :)

        -Dom