Summary
JBoss' Bill Burke discusses some frequent myths and rationalizations about dynamic languages, and shares his requirements for a language that would make him switch from Java.
Burke starts out by noting his openness to languages other than Java, and even to dynamically-typed languages:
I do wish that a statically typed dynamic language would come of age, but until then, I’ll stick with Java. Really, I don’t know why somebody hasn’t done it it. Is static typing really that hard to implement well? For example, why not gut Groovy and have Dynamic Java? Or do the same with Scala? Or add static typing to Python and get Jython up-to-date...?
While I don’t believe that Java is the one language to RULE THEM ALL, I do believe it is vastly superior to anything out there to build applications with...
I also do not believe that Java is the end all, be all of existence. It still needs elegant, typesafe closures to complement annotations as a way to implement DSL. It needs a standard, non-code generating way of adding behavior to annotations. It needs a structural syntax to make initialization easier. AOP support might be nice too, or at least JVM support to make it easier to implement AOP-like features. Better zero-turnaround development features in both the JVM and APIs like Java EE, Seam, Hibernate, Spring, and JBoss AS would help out tremendously as well.
Burke, primary author of JBoss' Java EE application server, details many of what he believes are myths and rationalizations about dynamic languages, and backs up his claims from his own experience:
Dynamic Language XXXX didn’t do well against Java in XXXX benchmark
Ruby VM cannot support kernel threads
Dynamic languages like Ruby, Python, etc… are not typesafe/statically typed
Lack of type safety doesn’t scale well to large teams
Lack of static typing does not allow for reliable refactoring in modern IDEs
Software Engineers should use the best language for the job
More lines of code means more bugs, thus dynamic languages are better.
I am more productive in XXX dynamic language because the syntax is cleaner, more elegant, and more powerful.
One of Burke's main points is that modern IDEs for statically typed languages support reliable refactorings that make up in productivity for the verbosity of languages such as Java:
I was a VI/Emacs user up until 2002 when Intellij came out with refactoring capabilities. Up until then, I was as productive with emacs, find, grep, and sed as I could be with any IDE out there. After finally becoming familiar with IntelliJ and its refactoring capabilities, I found that I was 5, 10 times more productive with my IDE than I was before. Now, Ruby fanboys will argue, “Intellij and Netbeans have refactoring capabilities for Ruby!” My answer is, it is not reliable refactoring.
What do you think of Burke's points about refactoring IDEs versus language conciseness in making programmers productive?
I think Bill Burke has missed the point about verboseness being in the way of READING code, and that he's become overhappy about automatic refactorings *without having programmed with and without automatic refactorings in parallel*.
He seems to require static typing only because it allows reliable refactoring by an IDE. Though, in my mind, an IDE could possibly refactor decently without static typing. It's just that static typing makes the job much easier.
The problem for the IDE is that with OO languages, namespaces (class instances) can be passed around at runtime as first-class objects. When you want to rename a variable or function in a particular namespace, the IDE has to figure out all of the different locations in code that refer to that variable in that namespace, without misidentifying a variable with the same name, but in a different namespace.
Static typing makes that job much easier, since it explicitly identifies which namespace (class) a variable is going to use. Though there are still loopholes, such as reflection, that allow the IDE to miss.
For a non-statically-typed language, you can perform almost as good a job with data-flow analysis, but that is a much harder problem to solve. It is also not without its loopholes. If you have a function that operates on serialized objects that come in via I/O, there is no way the IDE will know whether that object's namespace is the same as the one you're trying to modify.
Anything new here that hasn't been discussed a million times before without any result? Programming related blogs become increasingly boring, redundant, uninspired...
I wonder, given how keen he is on refactoring tools, if he knows the first refactoring tool was built in smalltalk, a dynamic language.
And I don't think he would last a week in the game industry. Those folks regularly use two to several languages.
Heck, I've been doing enterprise apps for most of my career and have had need of C++, C# and VB (several flavors) all for one project because of different requirements for different pieces. I didn't find it to be anywhere close to a nightmare. More of a nightmare would have been writing dynamic web content in C++, I think. Even if I were to use something like Ch.
There are certain things I can do in python that I just can't easily do in other more static languages. Maybe it is simply because nobody has written the libraries yet. Just today I cranked something out pretty quickly in python that I needed done that would have taken me, I estimate, 3 times as long to do in C#.
The other thing that is nice about dynamic languages, for me, anyway, is that they usually get you thinking about a problem differently. I miss things like list comprehensions and the set data type that python has when I'm in a different language environment. Coroutines in scheme, if you need them, aren't as clean, in my opinion, in other languages. Hell if you are in a microsoft world it is still hard to beat some flavor of visual basic for quickly gluing together COM components to talk to a database and do something useful. No amount of IDE coolness can replace those.
Bill works on JBoss and likes Java and that is fine. It would appear it is what he knows and likes to do, which is also fine. As Kay said, this has been discussed a million times before and that particular rant doesn't bring anything new to the party, is incorrect in some places, and despite claims to the contrary, shows some pretty strong biases.
Sounds like he should take a look at F# or ML.
I also find it slightly amusing that, in one way or another, we are all ranting about a rant.
> > He lost me when he said "I do wish that a statically > typed > > dynamic language would come of age.." > > Seriously, though, what does that mean (if anything)?
That's exactly why he lost me. It doesn't mean a thing unless he has a wildly different notion of static and dynamic typing.
> > > He lost me when he said "I do wish that a statically > > typed > > > dynamic language would come of age.." > > > > Seriously, though, what does that mean (if anything)? > > That's exactly why he lost me. It doesn't mean a thing > unless he has a wildly different notion of static and > dynamic typing.
I would guess he wants something with a decent type inference mechanism. But then you are talking about a strongly typed dynamic language, where type matters but does not need to be explicitly declared.
Anyway, reading the comments was kind of enlightening, which is why I said he had definite biases. Along the way somebody had mentioned that the first refactoring tool was done in smalltalk and the response was
"Smalltalk may have been first, but Intellij dudes were the ones to finally bring refactoring to a statically typed language. Thank you JetBrains. You guys rock!"
And yet one of the main bolded points is "Lack of static typing does not allow for reliable refactoring in modern IDEs".
So, if I understand correctly, you can't have refactoring tools without static typing, but the first good refactoring tool was done in a dynamic language. But that's not allowed. I'm confused.
> > > > He lost me when he said "I do wish that a > statically > > > typed > > > > dynamic language would come of age.." > > > > > > Seriously, though, what does that mean (if anything)? > > > > That's exactly why he lost me. It doesn't mean a thing > > unless he has a wildly different notion of static and > > dynamic typing. > > I would guess he wants something with a decent type > inference mechanism. But then you are talking about a > strongly typed dynamic language, where type matters but > does not need to be explicitly declared.
Type inference would only be meaningful in a staticly-typed language, right? How would type-inference be used in a dynamic language? If you don't declare the types, what's to infer? Or in other words, what would the type be checked against?
It seems to me that in this context dynamic and static are opposites. Maybe I'm missing something.
> Anyway, reading the comments was kind of enlightening, > which is why I said he had definite biases.
I also believe that he is biased.
> And yet one of the main bolded points is "Lack of static > typing does not allow for reliable refactoring in modern > IDEs". > > So, if I understand correctly, you can't have refactoring > tools without static typing, but the first good > refactoring tool was done in a dynamic language. But > that's not allowed. I'm confused.
I think what he's saying is that what a refactoring tool can do in a statically typed language is more than what a refactoring tool can do in a dynamic language. As far as I have been able to gather, this is true. However, he probably underestimates what refactoring tools can do in a dynamic language and ignores that Java's reflection makes it subject to those same limitations.
> > > > > He lost me when he said "I do wish that a > > statically > > > > typed > > > > > dynamic language would come of age.." > > > > > > > > Seriously, though, what does that mean (if > anything)? > > > > > > That's exactly why he lost me. It doesn't mean a > thing > > > unless he has a wildly different notion of static and > > > dynamic typing. > > > > I would guess he wants something with a decent type > > inference mechanism. But then you are talking about a > > strongly typed dynamic language, where type matters but > > does not need to be explicitly declared. > > Type inference would only be meaningful in a > staticly-typed language, right? How would type-inference > be used in a dynamic language? If you don't declare the > types, what's to infer? Or in other words, what would the > type be checked against? > > It seems to me that in this context dynamic and static are > opposites. Maybe I'm missing something. >
I don't think you are. I was just taking a stab at what I think he may have meant. A slippery slope I know, especially when talking about types because I think that is becoming a rather slippery slope, anyway. He asks for a statically typed dynamic language.
What I'm trying to say is, I think he meant to say strongly typed dynamic language. There are plenty of languages where you don't declare the type explicitly and the language's runtime has a type inference engine to figure out what is what.
A big part of the problem with these discussions is that not everybody even agrees on what makes a language static or dynamic. Type systems, I think, are pretty well understood, but what makes a language dynamic or not? The type system is part of, but not, the entire picture.
> What I'm trying to say is, I think he meant to say > strongly typed dynamic language. There are plenty of > languages where you don't declare the type explicitly and > the language's runtime has a type inference engine to > figure out what is what.
The main thing he's looking for (from what I can tell) is static analysis for refactoring support. I'm not sure the above would provide this.
Personally, I think that it would be pretty difficult to make a language statically typed without eliminating some of the most useful features of dynamic languages.
I also see the value in static typing but I think it's possible that static languages create some of the refactoring needs that they make possible. It's kind of like the arguments for WS* over REST that I read and hear: WSDL allows for code generation. But the thing is that the main reason for needing the code generation is to deal with the complexities of the standards supported by it.
This isn't to say that there isn't a value. I think there is but I think it's easy to get stuck in a static view when judging dynamic languages and vice versa.
I agree that the comment about wishing for a statically typed dynamic language seems a bit contradictory. The "dynamic" tag applies not only to typing but also to the development cycle, where people think of interpreted languages that don't require re-compilation or re-deployment as "dynamic" irrespective of how the type system works (though they do often go together).
With that said, my company does have an internally-developed scripting language that runs on top of the JVM (and can thus interact with Java) that is kind of a hybrid of static and dynamic typing; it's statically typed but the typesystem is essentially pluggable. So basically you can easily extend the typesystem to add new types to the system, and you can make changes to the type system and then refresh it on the fly. Of course, for static typing to work that means the types have to be defined at compile time, but compilation is always done dynamically at runtime from source, which means that as long as the type system is initialized before you attempt to reference a type you can still statically type everything while retaining some of the advantages of dynamic typing. Granted, it's not as dynamic as something like Ruby or Lisp where it's easy to programatically shove methods and classes into the system at any point during program execution, but that lack of restrictions is precisely why IDEs and refactoring tools can't deal reliably with them.
And I should add that naturally we do have type inference in there, which is also a big help in reducing the drag caused by static typing.
Flat View: This topic has 19 replies
on 2 pages
[
12
|
»
]
Previous Topic
