[russellperry]

"...static typing becomes a big convenience in enforcing coherency across all the systems. You can guarantee that your dataflow is more or less going to work, and focus on the functional aspects...But as we move into a light-weight Service Oriented Architecture model, static typing becomes a genuine productivity boon."

A 'productivity boon'? I don't understand. At the risk of invoking the ancient static vs. dynamic religious war, this statement makes no sense to me.

I get that if your codebase is tangled enough, and your unit test suite is inadequate to "guarantee that your dataflow is more or less going to work" that maybe rewriting significant portions of it in a type-safe system makes sense. I guess. But without specific code examples it's hard to say exactly what he's talking about.

Myself, I've spent many years in both static and dynamic environments and I know exactly where I'm more productive -- and it's not wrestling complex parameterized types to the ground, pulling up abstract classes or interfaces, and/or configuring IOC containers, abstract factories and the like.

I wonder though -- this has echoes of Alex Payne's criticisms a couple of years ago, which I think Obie Fernandez addressed pretty well:

http://blog.obiefernandez.com/content/2009/04/my-reasoned-re...

[wpietri]

A 'productivity boon'? I don't understand. At the risk of invoking the ancient static vs. dynamic religious war, this statement makes no sense to me.

I don't know what they mean either, but my first guess has to do with company size and mobility of staff.

I love dynamic languages most when I'm coding solo or with small teams. I don't need to express a lot of things to the computer when they're so clear in my head. But if I'm going to take over an adequately maintained code base, I'd rather it be in a static language, because more of the intent is explicit.

At this point Twitter has a lot of engineers and is still growing, and they're in a very dynamic business. It's plausible to me that they get a global productivity boost even though static languages could feel like a productivity hit to each individual engineer.

[colin_jack]

> But if I'm going to take over an adequately maintained code base, I'd rather it be in a static language, because more of the intent is explicit

Out of interest would you feel the same if both codebases had adequate test coverage?

In the post one of the reasons given was that with a static language you can pretty much guarantee that a dataflow is going to work, that you won't be caught out by getting the wrong type. I'd see this being most useful at the edges of the system, and in those cases incoming data would normally go through some validation anyway (including through a schema in many cases) which would normally make clear the types involved.

Having said that I do think in those cases being able to specify types can makes things slightly easier for newcomers, I'm just surprised its seen as a big enough advantage to be one of the key motivators to switching language.

[prodigal_erik]

A decent static type system ensures every object will be compatible with the types of all its references, no matter how the program may manipulate them. Only 100% path coverage could replace that guarantee, and that's generally regarded as infeasible.

No project I've worked on in twenty years had test coverage I could call "adequate", though I realize this is partly my fault. Hard-core TDD from day one might get you as far as "mediocre", and the industry average is much worse than that.

[colin_jack]

Sure thing but I was really thinking more of the "more of the intent is explicit" issue (and its affect on developer productivity) not guarantees regarding compatibility.

[russellperry]

I see your point, but I got the impression he was talking about a tactical/technical productivity boost rather than expanding their recruiting net or code expressiveness.

[kenjackson]

I get that if your codebase is tangled enough, and your unit test suite is inadequate to "guarantee that your dataflow is more or less going to work" that maybe rewriting significant portions of it in a type-safe system makes sense.

Your unit tests can never guarantee anything about the dataflow of your system. That's not the purpose of unit tests. And unless you have a meta test system, that tests the properties of your unit tests, you can't get system-wide dataflow information.

[malkia]

Come to think of it,

static typing might be productivity gain when more persons are involved and dynamic typing might be productivity gain when less persons are involved

Or it might not matter.

A big country needs very big laws, but they are never strict (static), nor dynamic.

A small country, a town might not need laws at all (they are known - dynamic).

Not a very good analogy, but still...

[colin_jack]

Yeah I found this bit odd too, definitely feels like it could be explored further.