While I was wondering if using haXe or Java with my server, I’ve stumbled upon some discussion on Static Typing (Java) vs. Dynamic Typing (Ruby, Php).
In a really interesting blog post (read the comments too) I found this touching phrase:
“Static typing is Communist Bureaucracy”.
In short: since we (should) have pervasive testing, Static Typing is only more testing. However, a comment is enlighting:
I’m finding this logic hard to follow. Testing is good, coverage is good. Static typing is, among other things, a way to have the compiler test your code for type issues. Since we like testing, this makes static typing good, right?
But Static Typing not only prevent you to do mistakes, like typos, it allows your IDE to know what you are doing:
DynamicStatic Typing speeds up development because there is physically less to type since ctrl+space and ctrl+2 write the declarations for you.
Its seems obvious to me that Dynamic Typing is worth the catch only for a quick start or for learning.
Since almost all of the dynamically typed languages (like Actionscript, Perl, Php) have migrated to some kind of Static Typing (eg: Type Inference), there should be a reason.
Periodically, a new Dynamically Typed language spawn, attracting junior/tired programmers with the mirage of the simplicity and the less-to-type-ing, riding the hype until his young audience grows and start doing large projects hoping not to call a function with the wrong arguments.
Only then they realize the big truth: Static Typing is just more informations in the source code.
And more information means less wondering-what-object-was or what-was-the-method-name-and-parameters or who-instantiate-this-object, not to mention static analysis.
And hey, they have invented Javadoc-like documentation and Annotations just to add some more information, why remove one of the most important?
Factually your blurb is wrong in several points. It’s written with a poor understanding of the core argument of why static typing is a manifestation of a discipline&bondage language, as opposed to a freedom language. Setting you straight is probably impossible and would bind my time here undesirably. So I would kindly ask you to internalize two important facts.
1. You’ve not yet a clue about the issue at hand
2. Since your opinion isn’t based on understanding, it is inevitably wrong.
Thanks for the reply,
however, the next time please be assured that you have enough time to explain your opinion, otherwise your comments would be useless.
I moved from a static typing language (C++) to a dynamic typing language (actionscript) and I find that while my static typing habits prevent me from writing incomplete or unreadable code, there’s much power in the dynamic approach that is hard give up. It’s definitely annoying when people who started with actionscript write unreadable and buggy code due to bad habits, but that doesn’t mean you can’t write good code in actionscript, and you can do things you can’t do in C++. Therefore, I vote for dynamic.
As a fan of Flash and ActionScript in general, I was thinking to AS3 where I wrote this post, since it is an example of how dynamically typed languages are migrating to the static typing.
AS3, while maintaining the option to use dynamic types, is statically typed at runtime. It is even more typized than AS2 that was dynamically typed at runtime but statically typed at compile time (and MTASC does it even better). Not to mention AS1/Javascript.
My point was that since you can achieve the same speed benefit with a good IDE, static typing give you the same with less bugs.
Switching from Java to Php at work the first I notice is that in Php I run often the page to see what errors I’ve done, while in Java those came out while I type.
“Static Typing is just more informations in the source code.”
This is bullshit, and shows your lack of understanding of the issue. Dynamic typing has major implications at runtime that you have entirely ignored.
I agree that it is helpful to have the ability to state the type eg. of a parameter (and wish Ruby had it), but being dynamic doesn’t exclude this as optional. Being static does however exclude the ability eg. to add methods to a class or object at runtime, or to handle method calls that don’t actually exist eg. Customer.find_by_name_and_street_and_postcode(‘fred’,’main st’,’6056′) using method_missing in Rails.
Static typing also means you often have to cast a generic object to a specific class to access a method, when a dynamic language would just find the method requested.
Your reasoning _for_ Static Typing doesn’t exclude Dynamic Typing entirely, and you haven’t grokked the additional advantages.
Classic anecdotal support for dynamic languages. “I can code faster therefore its better”. “I can do something dynamically therefore its more powerful”. You can build houses with straw fast too and straw can bend in ways that brick can’t. Therefore, straw is superior to brick?
Support 100K of your favorite dynamic language in a production app and then say how great it is.
Magpie you have take exactly the point, with Dynamic typing there can be two points of view:
you say: we can call a method if we know for sure it exists without bother to explain it to the compiler
I say: every time we call a method we hope it exists (and that we had spell it correctly), the best way is to lose some keystroke to instrument the compiler so we can be sure.
The fact that you can mix static and dynamic types in some languages is the proof that static is the Good Thing, especially because often it is a feature added in newer, more advanced, version of the language.
An then hey, look at a well-written dynamic application, is full of types specified in the comments or worst in the variable names.
See: http://en.wikipedia.org/wiki/Static_typing#Static_typing
The point about migration to a static typing system is dead-on btw. All languages that start nice and easy eventually hit the design limits and get really ugly as they attempt to add restrictions where there previously were none. Aren’t there already community calls for Ruby static typing? That makes me laugh.
Unfortunately, by the time they need it, the community has already settled on the “easy” way and won’t pick up the new features (looking at you Php). Going the other way is a lot easier, since you just have to relax, thus the various forms of Java expressions (OGNL, JexL etc).
Having gone from static to dynamic languages a number of times I have come to the conclusion that (my) productivity has more to do with the tools that come with them, and so far I prefer the (VisualWorks) Smalltalk IDE.
The simplicity and consistency of the Smalltalk syntax is also nice when compared to the “keyword” list one needs to remember when switching between static languages.
Where I have found the Smalltalk IDE to be particularly beneficial is in the maintenance and further development phase of a project. Exploring and debugging code seems so much easier than what I have found with Eclipse/Websphere and Visual Studio.
In a production multi million dollar environment (investment banking) where our Smalltalk project is competing against or is integrated with static language projects, our project is *always* the first to market. The dev team is also the smallest.
I don’t know Smalltalk enough, does it or the IDE parser support type inference?
I see type inference as the best (and secure) way to drop type declarations: often we declare the type and populate the field at the same time.
However, I can do something similar and with the same number of keystrokes in Java pressing a shortcut (Eclipse).
Anyone wanting to write about static typing in general would do well to look at modern statically typed languages like Haskell, OCaml and F#. These languages offer many benefits over Java, for example.
Some variants of Smalltalk I believe have type inference for code completion.
I typically use runtime type information rather than try to infer types for code I am not familar with. ie. The Smalltalk debugger has full REPL support and once a method has been edited and saved, the program can be resumed from anyway on the stack. ie. There is never a compile/link stage to Smalltalk development. This fact alone saves so much time for a large project.
IMHO, you can’t get enough static typing. I am aware that dynamic languages let you do things like add methods at runtime and so on – but as far as I’m concerned YOU SHOULD NOT BE ABLE TO DO THAT. If you add methods at runtime, how can you be sure, when you call a method, that it exists?
Any feature which takes a runtime exception and converts it into a compiler error is, in my opinion, a good feature. Compiler errors mean that if you manage to compile your code, THAT ERROR CAN’T POSSIBLY HAPPEN. Runtime exceptions mean that no matter how hard you test, there’s still a chance it can happen.
Dynamic languages basically take the compiler error “invalid typecast” from static typed languages, and turn it into a runtime exception, therefore making no guarantees that it won’t blow up in your face at runtime.
To follow on from what Jon Harrop said, look at modern static languages – in particular my favourite Haskell. I say there should be NO DOWNCASTING. Consider the “Object” type in Java or .NET. You can downcast this to whatever you like – giving a runtime exception if you downcast to the wrong type. This is equivalent to a dynamic typed language, except it only happens when you explicitly downcast.
Haskell has no downcasting at all – everything is done using generics. A no-downcasting type system (maybe not Haskell’s, but the concept of a no-downcast system) still lets you do everything required by an inheritance hierarchy, albiet sometimes in a more roundabout way, but importantly, the programmer is forced to ensure that all “downcasts” (their equivalents) are successful, thereby eliminating the downcast exception altogether. For more information, check out Haskell’s bizarrely super-safe static type system.
Static typing definitely is superior in one point: It allows a compiler (or even a smart “pre-compiling” interpreter) to find an error before the program has to be executed. I once programmed in a language called “SML” which checked the type without static typing which was pretty cool, but (to find an example) the average scripting language does not work that way. I am not sure if Haskell and/or Smalltalk do work in a comparable manor, but I think they do (Haskell is a kind of ancestor to the research done in SML).
I, personally, want the compiler to check my errors wherever applicable. Therefore I do accept to type more code, even if it is more work at the moment. I, too, like to have it (the type of a program, definition of a method etc.) in black and white, written in code, so that I can follow my own thoughts more simple later on.
And I do not like “dynamic code”, i.e. trusting on methods never written in first place. I did things like “programs that write programs/extensions” in the early 80s (in Assembler, every clockcycle counted, so you poked your own machine code from other machine code to be faster) – this cannot be the way to write code for nowaday applications, no one can maintain that for long.
Conclusion (for me): There are, in my opinion, two ways: Use dynamic typing for prototyping (get results done fast) or “small” projects, use static typing for structured (more manpower where you want to rely on your compiler) or “larger” projects.
Just my 2 cents, Georgi
For me, the difference between static and dynamic typing is relatively simple: trust or don’t trust the programmer. Dynamic typing trusts the programmer to make the right choice, and by consequence allows more flexibility (as with any relationship based on trust). Static typing does not trust the programmer to know more than the compiler, and by consequence is less flexible (as with any relationship based on distrust). Certain situations call for each. In a friendship, you want trust — similarly, in a project where you know the programmers are good, you want trust, so you can use a dynamically typed language. In a business relationship, a healthy measure of distrust is reasonable — similarly, in a project where maybe you don’t think all of the programmers are as good, a healthy measure of distrust is reasonable, so a statically typed language can provide that distrust.
That aside, I’m not sure why you couldn’t have open classes in a statically typed language, provided there was a directive that told the compiler to consider files where class extensions/redefinitions occurred before considering other files. It would complicate things, yes, but I still think it would be doable.