In my experience, the cost of static typing feels roughly constant per line of code, while the benefits of static typing feel roughly O(N log N) in lines of code or O(N) in number of cross-type interactions. These are just wild guesses based on gut feelings, but they feel about right. The constant factors are affected by individual coder preference, experience, and ability, but also specifics of thy type systems involved and the strength of type inference in the tools being used.

In any case, I think often times dynamic typing proponents and static typing proponents have vastly different notions of what a large code base is, or at least the size code bases they typically use.

One problem is that many code bases start out where the advantages of static typing aren't readily apparent, but re-factoring into a statically typed language is often not realistic, even/especially when a project starts groaning under its own weight.

I'd love to see more mainstream use of gradual typing/optional typing/hybrid typing languages, especially something like a statically typed compiled subset of a dynamically typed interpreted language, where people could re-factor portions of their quick-and-dirty prototypes into nice statically typed libraries.

I disagree; that Java was the standard example of statically typed languages is what convinced me for a long time that I didn't want anything to do with it. Having to pollute my code with all that crap, deal with a lot of dumb restrictions and still have NPEs left me with a sour taste.

Only after I discovered Haskell (and more recently Idris), did I realize that static typing can actually be worthwhile.

This allows you implement patterns like duck typing which are idiomatic in languages like javascript, but impossible to implement in java.

In fact, the only cases I've ever swapped even a HashMap has been to trove, which implements data structures for builtin types rather than reference types. In which case using interfaces everywhere doesn't help.

What crap? Types?

>deal with a lot of dumb restrictions

Like what?

Types, especially those that could easily be inferred and that provide no value to the programmer. Writing types down can be useful - Python programmers do it too. Having to tell the compiler every little thing is crap.

Like what?

Type erasure. Having to treat primitives and arrays differently from other types. No first class functions or classes. I won't go on, the arguments are easy to find.

I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.

Persuading you on the general demerits of Java wasn't really my intention; my point was that if you want get more people on the static typing train, Java is a bad ambassador and might work against you.

I am surprised though that you were completely ignorant of the benefits of static typing outside of Java. I would think that simply out of curiosity you would do a language survey just to get an idea of what else is out there.

Well, back then (early 2000s) I was a self-taught teenager with a poorer grasp of English (I'm not a native speaker), so while my curiosity did lead me to discover a few languages (JavaScript, PHP, Python, Lua and C), anything remotely approaching "academic" - Haskell, OCaml, Oberon, etc - was out of bounds for me.

Since C was the only other statically-typed language I knew, and I also knew it was much older and designed for much slower machines, I assume static typing was mostly for efficiency, like manual memory management.

There are no senses to come to. Static and dynamic typing each have their own benefits, and there are genuine tradeoffs to choosing one over the other. That we are even having this debate in 2017 shows that the world of typing is not a "solved problem" and there are still good reasons to use one over the other for various reasons.

I struggle to think of any benefits of dynamic typing on a reasonably sized code-base (e.g. 50k+ LOC).

There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.

I expect any programmer to be able to transfer their skillet to a new programming language - especially when we're talking about mainstream languages with a GC.

>There's always going to be an agility multiplier so long as VC is flowing and getting an mvp and a high head count is worth more than any kind of sustainable product.

What kind of agility multiplier? Maybe it makes a difference during a hackathon where you have 24 hours to put something together or maybe if you're putting together shell scripts ... but taking something to MVP takes weeks or months - mainstream dynamic languages simply don't have any edge in development speed in those instances.

Being able to define and initialize types at runtime offers more flexibility and it's quicker to develop in.

I'm frankly surprised nobody brings it up more often but the prototypical example of "static typing done right" - Haskell - is talked about nearly constantly but when I look for actual software I might use that's written using it.... there's so little it's almost embarrassing. One obscure window manager, one obscure VCS, facebook's spam filter and some tool for converting markup.

Given a sprinkling of asserts, a decent linter and a high level of test coverage I don't see much of a benefit to adding static typing.

Quicker if you're writing shell scripts or a small single-purpose applications. Not quicker if you're adding to a codebase of any significant size.

Yes, IME it's still quicker.

OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver.

No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time. At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point. Worse for dynamic languages, this is where improved tooling and static type constraints start paying extreme dividends.

Yes. And all equally true for statically typed languages.

Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.

If you prototype faster, as you usually will in a dynamically typed language, your design mistakes cost less. Since in large software systems I tend to find that the two biggest sources of bugs are a) errors in specification and b) poorly designed APIs, not obscure edge case bugs, quicker prototyping helps in large projects too.

And, if your design is solid, you can still achieve similar benefits as static typing by "locking down" your boundary code with asserts so that future development that interacts with that boundary code will fail quickly if it interacted with in the wrong way.

>At that point, you're not limited by your typing speed as you may be putting in net 10 lines of code a day. There is just no benefit to dynamic typing at that point.

This is fallacious. You're never limited by your typing speed in any language at any point. The cost of "extra typing" is cognitive, not a finger speed limitation.

The benefit of dynamic typing is more flexibility in the code you write (especially useful for writing frameworks and such) and quicker turnaround when prototyping because you do not have to prespecify as much up front.

>Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.

We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.

>And, if your design is solid ...

Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing. So if you do everything right, avoid the pitfalls, you can have something solid. A similar argument is made to me when I assert JavaScript is a terrible language. I don't disagree with either but it doesn't prove anything.

>The cost of "extra typing" is cognitive, not a finger speed limitation.

Exactly.

I am, because that's the way I'd work in any language, because I'm not a hack.

>Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing.

Eliminate.

>A similar argument is made to me when I assert JavaScript is a terrible language.

No, javascript is different. The weird and fucked up implicit type conversions render even a high level of testing insufficient to achieve a high level of confidence in the code. There's way too many edge case behaviors where it should be throwing exceptions and it does something weird instead. C suffers from this problem too despite being statically typed.

And yet, it's done all the time with great results.

There is a different problem with the more powerful and useful type systems in more modern statically typed languages though: learning curve. Haskell is dysfunctionally hard to learn and other languages do a little bit better but there's still friction in the learning curve that gets in the way of widespread adoption in projects that want to be able to hire rapidly.

This is the #1 reason I leaned away from static typing. Typescript and Swift have changed my mind. I now see typing as a helpful tool that can solve a lot of problems.

People always say this and it baffles me. Bugs like that should be caught immediately by your test cases. You shouldn't rely on the compiler to catch them for you.

I worked on a small Python project some years ago and we had a type error in production despite having tests.

We traced it back to a call to a third party library. It was supposed to return a list of results, and all of the test cases around it worked and always got a list back. In production however we encountered an error because if there was only one value to return, the library would not return a list of one element, as we expected, but a scalar value. So the rest of the code was expecting a list and when it encountered a scalar it blew up.

You can blame it on us for having insufficient test cases, or not coding defensively enough, or not reading the source code of the library we used, or the author of the library for bad design, but ultimately, this bug would not have been possible in a statically typed language.

So just saying "have test cases" is not good enough. Your test cases can be not exhaustive, but a good static type system and type checker is.

That's the whole point: as it's often said "type checking keeps you honest"

I stumbled time and time again upon badly designed libraries... With a static type system, the painfulness will be obvious and felt the first time you'll try to build your code

with dynamic types, the pain might not be felt at all, until a crazy bit of code will be invoked, sometimes at the most unfortunate of times

That's the one. That's a damned stupid decision.

By adding sanity checking asserts in a dynamically typed language you can achieve more or less the same result.

Yes. We call that 'typing'.

I see all too often, java bad, just look at how many lines you need to write to get "hello world". Who cares, the IDE generates that for you, but if you don't understand static void main as a beginner... again who cares, just put it in and ignore it until you need to understand it. Also read that dynamic languages are so productive, but they never mention you need to then write tests to detect what the compiler would catch for free. Yes good code needs tests, but the compiler IMO is a damn good built in test suite for catching many classes of errors

What's wrong with relying on the compiler? Bugs like that will be caught immediately by a good static type system, so you don't have to rely on your test cases to catch them for you.

Relying on a test suite to verify basic properties that could be enforced automatically through a type system means you're only checking some cases instead of all cases. It also means you're cluttering your test suite with boilerplate about language mechanics instead of writing high value tests that verify the real operational behaviour of your system.

There are pros and cons to static vs. dynamic typing in general, but in this particular respect, static typing is strictly more powerful, less verbose and more efficient.

None of those things are true.