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."Too bad the language is not simple enough to accomodate change, especially backward compatible change. Agile languages win again.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.
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:
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.
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).
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.
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.
Post a Comment