Over on the Manageability blog there's a few comments about static/dynamic typing:
What if you could remove type information from a static typed language?
What if you could annotate a dynamic language with type information?
For the first, developers doitout of necessity all the time - in C, it's the use of void. In Java or C++ (and C), it's casting. That's removing type information; you lying to the compiler because you know thecorrect answer and it doesn't. As to the latter, it happens every time we interface with external systems. Some dynamic languages already allow for his second point
Shouldn't languages have more than one mode?
If static type checking is just one kind of analysis, should we not be able to turn it off and on?
I understand that most modern Lisp systems have something akin to this (I'm no Lisp expert). Strongtalk can figure types out by itself, and allows for type annotations. Many of the functiona languages out there also figure types out, as well as allowing for annotations. In other words, this stuff exists.
If I knew the type of an object is my code, should I have the capability to tell the compiler what type it is?
If tests were so important, shouldn't I be able to ask the compiler to generate some of these tests ?
The right language should not be a choice between static and dynamic checking, it should give you that choice.
Point one - see above. Point two - you want the compiler to generate tests? What you want is AI above and beyond anything that exists now, that's for sure. Sounds almost like laziness to me - tests aren't that hard to write - there are too many XP and agile projects around to claim otherwise. Somehow I suspect that this is a cry to add these features to Java or C# - so that the author won't have to wander all the way over to Google and look about.
But wait, there's more! In another post, we see this old standby What I'm trying to get at is that static type checking is only one kind of checking. It's just one kind of static analysis that you can apply to code, in fact, it's a kind of testing. For static typed systems, it's part of the definition of the language and it's the minimum requirement that needs to be met. For dynamic typed systems, the definition of the language is more liberal, and the minimum requirement is much lower. Of course, it's every organization's responsibility to define what that minimum requirement, good organizations will require comprehensive test suites and bad ones will require passing a syntax check. In short, the more tests the better, by the same reasoning, the more prebuilt static checking, the better?
I'd say he ought to go read Bob Martin on this. "Uncle Bob" was a big, big static typing advocate until he became "test infected". In short:
About two years ago I noticed something. I was depending less and less on the type system for safety. My unit tests were preventing me from making type errors. The more I depended upon the unit tests, the less I depended upon the type safety of Java or C++ (my languages of choice).
I thought an experiment was in order. So I tried writing some applications in Python, and then Ruby (well known dynamically typed languages). I was not entirely surprised when I found that type issues simply never arose. My unit tests kept my code on the straight and narrow. I simply didn't need the static type checking that I had depended upon for so many years.
I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler
The win for dynamic languages is flexibility - refactoring is easier, initial coding is easier, there's no lying to the compiler. The should be written either way. If you write the tests, the static type checking is just getting in your way.
Finally, we get to this post
The pros I perceive is not what most would argue. It's actually based on my experience using the Visualage and Eclipse environments. The pros are that it's easier to navigate and search the code base. See the absence of type information makes it difficult to find the dependencies between code. Ask any smalltalker their experience of trying to reduce the size of the smalltalk image, it's an extremely painful process. Just because you're liberated today from type information, doesn't mean that it's not going to strike you back tommorrow.
Pain in trying to reduce the size of an image. That's the best he can come up with? First off, if you deliver your application using the tools the vendors provide, stripping is a one time thing (or once per vendor release cycle, when you update to a new release). In the interim, you ship out new packages of Smalltalk code that load into the baseline image (much like DLL's). Second, this is an issue that will be going away - Cincom Smalltalk, at least, will be shipping with an SRE (Smalltalk Runtime Environment) to address this issue. Second, why is he worried about size? No Java app or C# app - dependent on their respective runtimes - is small by any stretch of the imagination. I deliver BottomFeeder as a 5 mb (compressed) download, and it can be updated dynamically over the net. The runtime image was made pretty easily - I wasn't trying for a small image - and won't be updated until VisualWorks 7.2 ships.
The question you've got to ask is, should I sacrifice the code completion, quick-fix, search, etc. for a little fewer keystrokes?
No, the question is, can he build up a strawman to fight against? I think the answer to that is clear....
