Lambda the Ultimate

I want you to think about what that would actually mean - do you mean winking at a type error? The alternative is that the type system is not powerful enough, and a cast (or other technique to circumvent the type system was used), or that some sort of soft typing is being used (for instance as in Oz).

If you don't mean that, then I assume that you mean a polymorphic function that is defined over a certain number of types, and is defined with some sort of default clause that does not actually use the value in any operation which is not known to be similarly defined over all other types. This is possible in C++ with templates.

I was'nt thinking of "winking at a type error", what I was thinking was to get help from the type system to do automatic delegation (Java's Dynamic Proxy is close).

Which fits in your second statement, I think.

I would be thankful if you could point me to an example of how you would solve the problema with C++ templates

I would be thankful if you could point me to an example of how you would solve the problema with C++ templates

You can only do compile-time polymorphism using C++ templates and I'm assuming this is what Marcin was alluding to. There are basically two approaches, either using templated classes or templated functions.

Templated class example:

template<typename T>
struct Helper
{
    static void f(const T& value)
    {
        // Default handler.
    }
};

template<>
struct Helper<int>
{
    static void f(int value)
    {
        // int handler.
    }
};

template<typename T>
struct Helper
{
    static void f(const std::vector<T>& value)
    {
        // std::vector handler.
    }
};

Templated function example:

template<typename T>
void f(const T& value)
{
    // Default handler.
}

void f(int value)
{
    // int handler.
}

It is hard to say whether one is strictly better than the other. Because the templated function approach uses argument list overloading rather than template specialization, it interacts nicely with inheritance whereas the templated class approach does not. On the other hand, you don't have the benefit of partial specialization with templated functions. (See the std::vector partial specialization in the templated class example.)

This thread on the Gwydion Dylan gd-hackers mailing list seems relevant.

I have a vague recollection that the Digitalk Smalltalk implementations may have named the message messageNotUnderstood:

In other Smalltalks, MessageNotUnderstood is a Smalltalk class - a kind of (perhaps resumable) Exception.

doesNotUnderstand:aMessage is a Smalltalk message - the default implementation Object>>doesNotUnderstand: creates a new instance of MessageNotUnderstood and instantiates it from the current Context.

You have some reflection capabilities in Java, and on .Net. Does that make these language dynamic? Not according to most.

Also: metaprogramming (macros, staging) can support some of the things reflection is used for (read below on AR). Are these enough for statically typed languages to be called dynamic. Again, not by most people who use the term.

My feeling is that the term doesn't really describe languages, but rather environements (REPLs etc.), programming style etc. But maybe I am wrong about this: most of these languages are indeed dynamically type checked.

I recall Guido saying something about the term in the presentation I linked to a couple of weeks ago.

I think that the expression "dynamic language" is most often used to mean "late-bound language". Of course, this isn't just about type systems... but dynamic typing does help to delay binding a long way.

There's a distinct programming style that relies on extremely late binding. Languages like Java fail to support that style, not because they don't have enough features (reflection is nice sometimes), but because they have the wrong features. For example, you can't write a transparent proxy for a Java class that has final methods.

"the term doesn't really describe languages"

Agreed, but dynamic language is about marketing and advocacy and promotion more than technical description - just be happy that "agile language" hasn't really caught on :-)


My hope is that many folk will use the dynamic language in a mushy vague way, and we'll all understand that it's a vague hand-waving term and be able to move past that to more specific discussions.

While dynamic type checking (or, more commonly, spotty, uneven, and often no type checking at all) is a characteristic of the dynamic languages, it's by no means the most useful. Nor is it the most annoying, when dealing with things from the bottom up.

Introspection's not, in my experience, a defining characteristic. The languages that people commonly think of as dynamic generally have, at best, awkward introspection capabilities. That's sort of a shame, but there you go.

In addition to dynamic type checking, there's also late code loading, which is a bigger hassle. Perl/Python/Ruby et al, with their integrated compilers, tend to encourage this, and it is immensely useful -- it's not at all uncommon to find configuration files that are really executable code. Rather than parsing the file to extract the info, you just compile and run the configuration file.

Probably the single biggest feature that the dynamic languages have going for them is the extreme late-binding of functions and methods, late binding to the point where they're re-bound each and every time they're invoked, such that a function or method can be redefined or deleted on the fly and the changed function will be used instead of the old function on the next invocation.

These dynamic features -- delayed/weak/nonexistent typing, dynamic redefenition, and at-runtime code compilation -- certainly aren't the only features that the dynamic languages appealing, but they are what makes them dynamic. (And a damn pain to write efficient runtimes for, but that's a rant for another time)

Probably the single biggest feature that the dynamic languages have going for them is the extreme late-binding of functions and methods, late binding to the point where they're re-bound each and every time they're invoked, such that a function or method can be redefined or deleted on the fly and the changed function will be used instead of the old function on the next invocation.

I've always used the term "dynamic languages" to mean "languages that make me feel dynamic". I include both dynamically typed languages (e.g. Ruby, Smalltalk) and statically typed languages (e.g. Haskell) and even weakly typed languages for some things (Tcl).

There's much more to "dynamism" than the type system. I think it's more the malleability of the language: that you can change the language to match your thinking about the domain rather than vice versa.

I'm not certain that there's all that much useful stuff in Ruby that we don't know how to check, or could not be remade in a way that we know how to check whilst losing no useful functionality.

ActiveRecord (one of the most attractive things in Rails) makes heavy use of the fact that class definitions are executable code, i.e. you can do metaclass hackery - auto-generating methods for talking to the database etc. - at class-definition time.

Mapping this into a typed language is a non-trivial effort (yes, I know about HaskellDB, but it isn't aimed at the same problems as ActiveRecord).

ActiveRecord (one of the most attractive things in Rails) makes heavy use of the fact that class definitions are executable code, i.e. you can do metaclass hackery - auto-generating methods for talking to the database etc. - at class-definition time.

ActiveRecord and its ilk are really nice. While the dynamicism of Ruby makes something like AR more convenient to implement, you can achieve the same effect in a more statically-typed language by a hybrid approach based on code generation. Firstly, you would allow untyped access using accessors, e.g. getValue("name_of_column") and setValue("name_of_column", new_value). Secondly, you could generate strongly-typed interfaces at compile-time by connecting to the database. (This integrates really well with C# 2.0's support for "partial classes".) This seems to basically cover all the AR use cases I can think of. It could be made about as convenient as AR by decent build process integration.

Let the dynamic-fan in me make a few nitpicks.

by decent build process integration

But you don't _need_ a build process in Ruby. You edit the code, then run it.

This seems to basically cover all the AR use cases I can think of.

Does your AR look-alike know that "person" is the singular for "people"? The real ActiveRecord does :-)

generate strongly-typed interfaces at compile-time by connecting to the database

So now your build process needs a network connection to the main database?

See, dynamic fans have a reason to complain about static fans making things too complex :-)

Let the dynamic-fan in me make a few nitpicks.

FWIW, I do most of my programming these days in Python so I'm very much a "dynamic-fan". :)

But you don't _need_ a build process in Ruby. You edit the code, then run it.

I know. Ultimately what matters is workflow though, agreed? If you have to use a compiled, statically-typed language (there are good reasons that might constrain your choice) then my point was that you could achieve a workflow that is fairly close to working with AR in Rails.

Does your AR look-alike know that "person" is the singular for "people"? The real ActiveRecord does :-)

That kind of thing is not difficult regardless of how you end up handling things. I re-implemented most of AR in Python in just two evenings worth of work, it's really pretty simple implementation-wise.

So now your build process needs a network connection to the main database?

Sure. If you already have the functionality for doing all that stuff (which you would need for the run-time parts of the class library) it's a simple matter to write an IBuildTask class that plugs into MSBuild. (MSBuild is the new build system in Visual Studio 2005, which is in beta right now. It's awesome.)

I agree this is more complex than it would be in a dynamic language (there's that word again) like Python or Ruby. But presumably you have good reasons for using a compiled, statically-typed language that would justify the extra work. My point was that in this case (and other cases) most of the workflow gap between dynamic and non-dynamic languages can be bridged with just a small amount of tool work.

"Another tangent: I always refer to the .Net VM and not the the CLR. It’s a VM, such things have always been called VMs"
For years I probably imagined that VMs were invented for Smalltalk at PARC, so it's fun that the first chapter of Virtual Machines is about BCPL.

That looks like a fun book, thanks for the link! Springer always puts out excellent, if pricey, books.

By the way, the irony of that quote you reference is mind-boggling. Surely everyone remembers the original PR push for Java? Sun was bandying the term "VM" around in relation to Java as if they themselves invented VMs! Because of this I think a lot of "commercial programmers" made (and still makes) the connection "VM <-> Java". Given this, it's not at all surprising that Microsoft is favoring the CLR term as a point of differentiation. In any case, it's hilariously ironic that a Sun engineer is getting upset about it!