Pardon me if I have hurt your sentiments in any way, because that was never the intention. I started off with an appreciation of your work, and I would like you to know that the appreciation remains throughout this exchange and beyond.

I agree that let’s stop this discussion here. We have started to repeat ourselves, and I would not like a technology debate to turn into a heated discussion. It’s common to have technologists differ in their opinions, yet maintain a mutual respect for each other’s viewpoints.

End note: I did learn a couple of useful points through your article and also our discussion. I thank you for the same.

All the best,

/Ashish

The link you gave is interesting, where you talk about the business benefits of Java which I had left out. Thank you for pointing those out.

Combined with the promise of backward compatibility like you mentioned in the other article, the advantage jumps even higher

The argument of backward compatibility actually went to the fact that Sun like Microsoft had constraints that they have to work with. If Sun maintained say PHP and Java was open sourced, theres a likelihood my entire argument could’ve been pro PHP than pro Java. These statements were not in the context of why Java will thrive – they were in the context of why Java will not die. And finally arguments simply were orthogonal to static vs. dynamic typing.

I can realise carefully worded statements made to twist an author’s intent. And I don’t like it – especially when I am the author.

Programs start small, and then start growing one feature at a time. Initially, a discipline like static typing sounds burdonsome; but if we do not do that then the programs start becoming unmaintainable. So much so that the ROI starts sinking below acceptable limits.

Okaaaay, now we have dynamic typing being offered as the sacrificial lamb at the altar of maintainability and what I assume you to be referring to as code decay. I should really look back and revisit my experiences since I had perhaps mistakenly come to a belief that a number of other factors which ended resulting in code decay. One of them I thought was my observation that longer code typically decayed faster. And if I look really hard every static typing project which did result in a code decay should be treated as an aberration since its dynamic typing which results in code decay. And maybe I should look at Struts and Django code bases – probably django should be becoming unmaintainable much faster because it is dynamically typed. If the statement above had not been so tragic, in my opinion it would have bordered on the irresponsible.

Lets just agree to disagree. Its usually a smell when arguments get rehashed, words get twisted out of context, and some rather unsubstantiated opinions turn facets of debate into sacrificial lambs. Thats fair in a public relations campaign. This is a technology argument and I will not disrespect the spirit of such an argument.

All the best,
Dhananjay

Thank you for your replies. As both of us agree, the context of an application would always play a role in determining the right technology.

My only point is that the safety net provided by the static typing is a good thing to have, although it increases the code and forces one to leave out some cool things. This point usually does not come about clearly when we keep talking about all those cool things. (That was the ‘other angle’).

The link you gave is interesting, where you talk about the business benefits of Java which I had left out. Thank you for pointing those out.

Here are the individual points:

(a) No, my argument about testing is not narrowly made. It helps to have as much safety net as possible, in defense of innumerable possible breaking points of one’s code. This can be said without getting into any long debate.

(b) Generics of course make the code more verbose where they are declared. Sure they save the trouble of typecasting the object when it’s taken out of the collection, but that’s relatively minor. Again, the point is that the important thing here is the added type-safety, which is good even at the cost of more typing while declaring.

(c) I agree there is more to code maintainability than just static typing. However, given a choice where the types of method arguments are clearly mentioned (and hence the operations that can be performed on them), versus another where they are not, what would one choose? The former would be clearly easier to understand and to prevent errors as your program starts growing bigger.

From time and again, this is exactly something that we have seen happen. Programs start small, and then start growing one feature at a time. Initially, a discipline like static typing sounds burdonsome; but if we do not do that then the programs start becoming unmaintainable. So much so that the ROI starts sinking below acceptable limits.

Again, languages with static typing are not necessarily going to solve all problems in the world; but they are clearly better off than the others in dealing with this aging process. Combined with the promise of backward compatibility like you mentioned in the other article, the advantage jumps even higher, and that’s what serious businesses look for: stability and maintainability over time, a long life of their programs and thus a high ROI in the long run.

On the final point, we anyways agree… we choose the tool/ language that gives the best ROI, and the choices keep changing from application to application and from time to time.

/Ashish

One of the things I’ve attempted to do through this article is to not make statements which sound “universally true”. There’s a reason for that. We are a function of our experiences since our experiences are the universe for us. So what at times may seem to be universally true statements are actually so only contextually so, and any reasonable discussion requires a explanation of the context we operate in. While I do challenge many of your assertions in terms of universality, I do so with the full knowledge that its a much easier job since to challenge the universality of a statement requires only one or more experiences which contradict the assertion.

Having said that I am not coming at it from another angle – the primary angle I come from is the ROI angle. Horses for courses. If one doesn’t know the course and the horses, one can’t pick a horse.

We all know that any amount of testing is never foolproof. So if a language gives us a better chance of catching a good %age of errors automatically, there is wisdom in using that language, even if it’s not so sexy.

I wonder if the argument is narrowly made. The wisdom is in applying a variety of criteria not just compile time error checking alone in static vs. dynamic typing. Not looking at the matter in a composite way is a reminder of the elephant and seven blind men fable. I believe that except for a clearly defined context, it is completely unwise to get into a debate about which is superior. The argument you make has been made hundreds of times and has been contested hundreds of times (and vice-versa) in tens (if not hundreds) of pages over the net. I don’t recall any one of them reaching any degree of closure. What I can most certainly assert is that in my opinion there are contexts where one is appropriate and there are contexts where another is. Any discussion on ROI for a software project / product will require taking into cognisance that particular project / product contexts and its ROI influencers.

Do generics make code more verbose? Yes.

They reduce not increase verbosity. You no longer have to do a type check after extracting an object out of a list. Secondly they eliminate the necessity of writing otherwise duplicate code for ensuring type safety.

Do they make your application more robust? Yes again!

Only in certain contexts. I would argue that in certain contexts, some of the metaprogramming and functional programming constructs are able to boil down a very complex logic into a fairly small code. Also the defect density per line of code doesn’t vary as sharply across languages as does function points per line of code. So smaller code leads to lesser errors. So what would you choose ? A large code base with all static errors resolved by the compiler but a larger number of other defects per function point or a smaller code base with fewer defects per function point ? Is this comparison of mine even valid ? The context decides. I assert that application robustness is too comprehensive and nuanced a topic to be closed so quickly.

One fact of life is that static typing goes a long way in making your programs highly maintainable.

I have emphatically stated in other writings that often refactoring is tougher in dynamic languages than static ones. Many have challenged me on that. Assuming I am right on that count, I still believe refactorability is only one aspect of maintainability, and to that extent reduces the maintainability of dynamic typed applications. However there are other reasons why dynamic languages are much easier to maintain. If one goes by the assumption that the static typing makes code more maintainable as you state and also believe the other equally credible statement that dynamic typing makes code more maintainable, the interesting question is why do we have unmaintainable code ? Clearly theres far more to maintainability than static or dynamic typing. Also it needs to be understood both typing systems move maintainability in different directions as measured by different criteria of measuring maintainability – neither of them make the language more maintainabile on all criteria.

The lines are clearly drawn then. Java is meant to be a business language, meant to solve serious business problems. It was never cool or sexy. (I wish Java did something about this aspect quickly.)

Java was designed to be a cable set top box language. It was extraordinarily cool and sexy at one time (latter half of nineties). I remember clearly since I was one of the relatively early adopters and enthusiastic proponents of the same. Java is certainly used quite extensively in business. What is a business language meant to solve a serious business problem ? I could attempt to answer that if I could understand the question.

I prefer the dynamic languages for smaller programs, or for giving some dynamic scripting ability on top of existing apps. But I prefer to bet on the proven solid workhorses for life-size apps.

In 1997 I took a pro Java call as an architect in face of exactly the same argument (Java was on the other side of the fence during 1996-2002). End of the day it was based on a composite assessment of a variety of factors influencing the ROI. Its a call I look back at with lots of pleasure and no regret. I would always bet on whatever delivers me the best ROI under the context and circumstances.

Dhananjay

While having less code and metaprogramming are great, we should also keep an eye on whether we are missing out on something important.

We all know that any amount of testing is never foolproof. So if a language gives us a better chance of catching a good %age of errors automatically, there is wisdom in using that language, even if it’s not so sexy.

With release 1.5, Java went a step further in its strong typing system to embrace Generics. The idea of Generics is that you are no more content by declaring an object type to be a List, but you now want to mention additionally that all its elements would be of a given type instead of some other. (C++ folks would remember templates here.)

Do generics make code more verbose? Yes.

Do they make your application more robust? Yes again!

The lines are clearly drawn then. Java is meant to be a business language, meant to solve serious business problems. It was never cool or sexy. (I wish Java did something about this aspect quickly.)

One fact of life is that static typing goes a long way in making your programs highly maintainable. This is because when you look at a method, you instantly know what are the types of the arguments that are coming in and what you can do with them. That makes the understanding better and also avoids incorrect edits by compile time checking.

Secondly, although the code ‘weighs’ more, some of it can be auto-generated (like the getters-setters). Also, powerful editors can do a much better job of suggestiions or auto-completion based on the types of arguments, which improves productivity and avoids stupid spelling mistakes. As a result, the speed of development is not necessarily slow. (Developer productivity is more associated with the framework one uses than the language.) Also, the code is now easier to understand and hence easier to maintain (contrary to the simple-minded expectation of less code to look at should be easier to maintain.)

The static type info of method arguments is so useful that if the language I use did not allow it, I would mention the type of each argument in method comments. A better alternative is to use a language (like Java, C#, C++) which supports strong type system and take advantage of the compile-time error catching. As an added bonus, your application will also be fast. :-)

Finally, as Dhananjay said, there is no ‘one size fits all’. I prefer the dynamic languages for smaller programs, or for giving some dynamic scripting ability on top of existing apps. But I prefer to bet on the proven solid workhorses for life-size apps.

/Ashish