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.

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

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.

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.

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.

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).

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.