"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Sunday, November 14, 2004

More Problems with Rigid Languages

This from people trying the new Java 1.5 language changes...

And generics: "In a nutshell, I have this to say about Java generics: my code feels more robust, but it's harder to read."

Also an interview with one of the authors of Hibernate: "Well, we are a bit stuck. We can't use many of the new features, because Hibernate needs to stay source-level compatible with older JDKs. The annotations stuff is okay, because we can provide it as an add-on package.

Too bad the language is not simple enough to accomodate change, especially backward compatible change. Agile languages win again.

Update: A question in the comments asks how this is different from Python. My answer is "not much different". Python is a mixed beast when it comes to extension. Here's why...

The big problem is that these changes occur at all.

In Lisp, the core language (e.g. Common Lisp or Scheme) does not have to change much. Change is facilitated by making syntax extension a part of the language. And the core is expressive enough to ward off the need to change.

Smalltalk does not have the same syntax extension, but again is simple, expressive, and mature so that the existing message sending paradigm can be used to define new forms of control.

I am not sure why Python is changing or needs to. But the core language is more limited than Lisp or Smalltalk in the sense that it is "C"-like and distinguishes significantly between function calls, operators, and control structures.

A more uniform language would not have as many of these backward-compatibility issues. This is the main issue I have with Python... it's syntax is OK, but not great for extension.

4 comments:

Anonymous said...

How is this a win for agile languages? I do a lot of coding in Jython. I can't use any of the features introduced in Python 2.2 or 2.3 or 2.4, and any code written to use those features won't work for me. If I'm lucky I might be able to use a new library module.

I'm not complaining, but I don't see how Python is doing better than Java at backward compatible change.

Anonymous said...

Python 2.4's decorators and generator comprehensions won't work with earlier Python interpreters either. And while it's not source-compatible with earlier JDKs, Java 1.5 code with generics *is* bytecode-compatible with earlier JVMs (whereas IIRC C#/Whidbey code with generics won't work with earlier CLRs).

Patrick Logan said...

The big problem is that these changes occur at all.

In Lisp, the core language (e.g. Common Lisp or Scheme) does not have to change much. Change is facilitated by making syntax extension a part of the language. And the core is expressive enough to ward off the need to change.

Smalltalk does not have the same syntax extension, but again is simple, expressive, and mature so that the existing message sending paradigm can be used to define new forms of control.

I am not sure why Python is changing or needs to. But the core language is more limited than Lisp or Smalltalk in the sense that it is "C"-like and distinguishes significantly between function calls, operators, and control structures.

A more uniform language would not have as many of these backward-compatibility issues.

Ian Bicking said...

I really don't see how Smalltalk is better. It has blocks, and that's cool, and you can use them in several interesting ways. But in many ways its model is more rigid. Well, maybe it's more appropriate to say that its representation of source is more rigid, specifically the IDE. I can imagine Smalltalk objects that are completely general and not particularly related to classes. But I can imagine block objects in Python; in both cases, there's no good way to represent them (traditionally) in source.

Python has some flexibility that Smalltalk tends not to because of its imperative style. Since each Python module is a script, you can program how the objects that are constructed. Decorators are one obvious example of this -- and something where syntax was added for aesthetic effect, but the semantics were already well worked out, and fit into Python's model just fine.

Because Smalltalk has declarative source, there's not as much room for building objects on the fly. Again, you can do it, but it's not nearly as comfortable.

In the end, it doesn't seem like Smalltalk is an evolving language, and there's no one to even go to to ask for new features (who would realistically respond in a positive way). So it's hard to compare; in all of these languages, you can cope somehow. You can always do code generation, after all. In evolving languages there are options besides coping; that people respond to that and ask for changes doesn't indicate a more flawed language.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.