Summary
In a thread on Heron, some issues came up that I thought were worth clarifying.

Here is the original posting by Christopher Diggins, and the comments that followed.

Duck Typing: this is a casual term that aliases "latent typing" or "structural typing." It means that you, in effect, specify a type by giving a subset of the methods it needs to support. I usually put it like this: "I don't care what type you really are, as long as you walk() and quack()." The "duck" comes from the phrase "if it walks like a duck, and talks like a duck, then for all intents and purposes it's a duck." Thus the actual constraints on a type are loosened, and code that you write using latent typing is more "generic" -- it works across a larger set of types. Dynamically-typed languages like Python and Ruby support latent typing, but so does C++, so latent typing is not constrained by wether the language uses static or dynamic typing. Java and C#, alas, do not support latent typing, so the result is that their generics are far less "generic" than they could be, and as much as they (especially Java) bash C++, C++ templates are a more powerful generic type mechanism than Java or C# (although C# still has some advantages over Java where generics are concerned).

Languages and libraries: I think focusing on library components is definitely a key aspect of language design. Arguably the biggest leverage we get in a language is the ability to easily reuse library components. One of the attractions of PHP, for example, is its large collection of solved problems in the form of library components.

When I was on the C++ Standards Committee, one of the stiking things I heard Bjarne Stroustrup say was something to the effect that C++ was intended to make library use easier. It did this, but it did not make library creation that much easier, and as a result the creation of libraries did not increase that much. Java actually made library creation easier, and so components were easier to create as well as use, and we saw an explosion of components (I would argue that, for some reason I haven't been able to put my finger on, I find library components in Python much more intuitive to use than Java library components; something about the way that you're encouraged to create the components makes the Java components more obscure to me, whereas I can usually drop a Python component into a program and get it doing what I want in a much shorter time).

So I would say that writing library components is simply a more difficult process, which really tests and challenges the boundaries of a language. In the first versions of Visual Basic, you couldn't create VB components using VB, which probably seemed good in theory at the time but turned out to be quite limiting. And although C++ moved the library issue forward, it didn't make it easy enough, which opened the door for Java. And Java left the door partway open for C#, etc. The uptake of these languages is driven by improved productivity, and the greatest benefits in this area are still to be found in library creation and use.

Concurrency Support: that said (and keeping in mind that I just finished the Concurrency chapter in Thinking in Java 4th edition), I think the other area where a language could have great advantage is in implementing a much better model for concurrency. This is where Heron or Nice or D could really stand out and solve a lot of problems, but as far as I can tell they are all following a kind of "decorated pthreads" (aka Java) approach to the problem, which I think is a dead end -- the concurrency problem is not subdued with such a strategey.

I understand why language designers are doing this; concurrency is hard, and "decorated pthreads" is well-understood, especially if you are draw to the low-level details as compiler writers often are. But if you really want to make a breakthrough language, I think it will be essential -- especially with multiprocessor machines becoming more common -- to come up with a more object-oriented model for concurrency, one that makes it much easier to write working concurrent programs and much harder to write broken ones. I've started a thread discussing these issues for Python, which you can find here (look for "Pythonic Concurrency"), and a number of postings include URLs for papers and implementations that describe newer thinking on the subject.

Talk Back!

Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.