|
Dynamic Typing vs. Static Typing
BB: Ruby is a dynamically-typed language. But static-type checking is a good thing. Isn't it?
Justin: A solid suite of unit tests is every bit as good, if not better than, static-type checking. Because all you want in type checking is confidence that you haven't made the basic mistakes. A good set of unit tests will provide that for you.
BB: But static-type checking is so well defined. Compared to static-type checking, unit testing is an art.
Neal: Static-type checking is very safe. But when you ride a bike, you use only two tires. You don't use training wheels even though training wheels are clearly safer. Why not use training wheels when you ride a bicycle?
BB: Training wheels slow you down.
Neal: And static-typing slows you down.
Stuart: Also, the domains in the situations we are modeling are dynamic, not static. As you build systems, they tend to grow, not shrink. Objects get new subclasses, new fields, new capabilities. But also, you gain a better understanding of your domain models. So the domain model, in an abstract sense, may have been there all along, but your understanding of what it should look like changes over time. Being able to evolve and make those changes are easier in a more dynamic language.
The other point that is really important, is that casting Java as static and these other languages as dynamic is really inappropriate. I just think they take very different paths to being dynamic. The path to being dynamic in languages like Ruby and Python is "this is an apple because I say it's an apple." If I change my mind later and say it's an orange, or say it's bigger or it has a worm in it, those things are very easy to say in the language. I add a method to an instance at run time.
In Java, you have those same things, but you do them at a level of architecture that is hidden from the average application developer. You do it with reflection, class loading, and with domain languages, like JSP—domain languages that add more dynamic capabilities. So, the question is not: "Are we going to be dynamic or not?" We're absolutely going to be dynamic. The question is: "What languages and idioms are going to allow us to be dynamic more quickly?"
With Java, we model changing domain scenarios over time by swapping classes out at run time with class loading. In many cases, that stuff is down inside the container stack and application developers don't look at it. Depending on your application and your needs, that may be a good thing or a bad thing. For the kinds of systems I've worked on in the past couple of years, it was very important for that kind of information and deployment thinking to be front and center for everyone on the team. It didn't help us to have a J2EE stack in a class loading-type scenario, because we were heavily customizing those kinds of things anyway. If a container gives you, out-of-the-box, exactly what you need, you may not need to run out and get your dynamic capabilities in some other way. But I think it's a misplaced argument to pretend that anyone models the world with static typing as it appears in languages like C++ or Java.
Justin: If you look at some systems, like Spring or Hibernate, you see the synthesis of dynamic proxies at run time based on interfaces or base classes. You tell the framework: "I am going to need extra work done on my behalf on this instance or this class of instances at runtime." This extra work isn't in the compiled version of the class. In languages like Ruby and Python, adding extra work is a language feature, not a framework.
BB: What about AspectJ?
Justin: AspectJ, AspectWerkz or any of the AOP frameworks, are bolted onto Java. Aspect-oriented programming isn't a natural part of the language but it's still a capability of the platform. Whereas in a dynamic language like Ruby or Python, the capability is baked into the language to walk up to any instance (or any suite of instances) and say "change the way you act, right now, but revert later."
BB: Is the trend toward dynamic-typing just a swing of the pendulum? Dynamically-typed languages, statically-typed languages, type safely, type unsafely...the community's prevailing opinion swings back and forth.
Neal: Smalltalk—which is a dynamic language—didn't do very well because we didn't have a sufficiently strong emphasis on unit testing. Now, we are seeing the pendulum swing back the other way. We're realizing that unit testing is the only way you can get anywhere close to proving the validity of a piece of software. You can't mathematically prove validity. So now we're swinging back, saying that dynamic languages are okay. You don't get into trouble with a dynamically-typed language if you have a good suite of unit tests. So testing has become vitally important in all software development. It just happens that it's easier to write code in dynamic languages. With a dynamic language, testing is your safety net.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
