Is type safety worth the trade-offs?

Question

I began coding in in Python primarily where there is no type safety, then moved to C# and Java where there is. I found that I could work a bit more quickly and with less headaches in Python, but then again, my C# and Java apps are at much higher level of complexity so I have never given Python a true stress test I suppose.

The Java and C# camps make it sound like without the type safety in place, most people would be running into all sorts of horrible bugs left an right and it would be more trouble than its worth.

This is not a language comparison, so please do not address issues like compiled vs interpreted. Is type safety worth the hit to speed of development and flexibilty? WHY?

to the people who wanted an example of the opinion that dynamic typing is faster:

"Use a dynamically typed language during development. It gives you faster feedback, turn-around time, and development speed." - http://blog.jayway.com/2010/04/14/static-typing-is-the-root-of-all-evil/

Answer 1

It's sort of a myth that programmers don't have to worry about types in dynamically typed languages. You still have to know if you're working with an array, an integer, a string, a hash table, a function reference, a dictionary, an object, or whatever. If it's an object, you have to know what class it belongs to. Assigning one of these types to a variable or function parameter expected to be another type is almost always an error. At a lower level, things like number of bits or signed versus unsigned frequently still must be accounted for if you are populating a TCP packet, for example. You can run into problems where you get a zero where you really wanted an empty string. In other words, you're still debugging type mismatch bugs. The only real difference is the compiler isn't catching the errors.

I'd argue that you aren't even saving much typing, because you tend to want to document in comments what type your function parameters are instead of documenting it in your code. This is why doxygen-style comment blocks are much more popular in practice throughout dynamically typed code, where in statically typed languages you mostly only see them for libraries.

That's not to say that programming in dynamically typed languages doesn't feel more pleasant because the compiler isn't always on your back, and experienced programmers don't tend to make the kind of bugs very often that static typing would catch anyway, but that's a completely separate issue from an alleged increase in efficiency or reduction in bug rate, for which dynamic typing is at best a wash.

Answer 2

As the types get stronger, they can help you more — if you use them correctly instead of fighting them. Design your types to reflect your problem space and logic errors are more likely to become compile-time type mismatches instead of runtime crashes or nonsense results.

Answer 3

Disclaimer: I am a type-lover ;)

Your question is difficult to answer: What are those trade-offs ?

I'll take an extreme example: Haskell, it is statically typed. Perhaps one of the most strongly typed languages that exist, in fact.

However, Haskell supports Generic Programming, it the sense that you write methods that work with any type conforming to a certain concept (or interface).

Furthermore, Haskell uses Type Inference, so that you never have to declare the type of your variables. They are statically computed during compilation, much as a Python Interpreter would compute them running the program.

I've found that most people harshing on static typing, were actually complaining about something else (verbosity, pain of switching one type in favor of another), but Haskell exhibits none of those issues, while being statically typed...

---

Example of brevity:

-- type
factorial :: Integer -> Integer

-- using recursion
factorial 0 = 1
factorial n = n * factorial (n - 1)

Apart from built-in support, it's difficult to get briefer.

Example of Generic Programming:

> reverse "hell­o" -- Strings are list of Char in Haskell
=> "olleh"
> reverse [1, 2, 3, 4, 5]
=> [5,4,3,2,1]

Example of Type Inteference:

> :t rever­se "hell­o"
:: [Char]

which can be computed simply:

• "hello" is a list of Char (expressed as [Char])
• reverse applied to a type [A] returns a type [A]

Try it out in your brower

Answer 4

Personally, I find that type safety helps me develop faster in my current job. The compiler does a lot of the sanity checking for me almost as I type, allowing me to focus more on the business logic that I'm implementing.

Bottom line for me is that although I lose some flexibility, I gain some time that would otherwise be spent tracking down type issues.

Answer 5

In my experience it is not worth it for very small pieces of software. For anything bigger than that, static typing becomes very important.

Answer 6

Is type safety worth the hit to speed of development and flexibility?

So really this comes down to what you are doing. If you are programming say, the backup systems for airplanes, type safety is probably the way to go.

Dynamic language vs Static language programming are really two different animals. They both require a fundamentally different approach from each other. You can mostly port a method of approach between static and dynamic, but you'll lose out on the advantages of the other.

It's a mindset really. Is one better than the other? That really depends on who you are and how you think. Most of the people I work with would never touch a dynamic language if they didn't have to, because they feel there is too much room for error. Are they wrong to think this? No, of course not, but it does mean that they have realized that they're approach of applying their coding style won't work in a dynamic environment. Other people I go to user groups with are the exact opposite. They find static typing too cumbersome, because it limits their approach to solving certain types of problems.

I can honestly say, I jump between JavaScript and C# a lot. Now, knowing and working in both languages does influence the other to some extent, but in truth, the code I write in each look entirely different from the other. They require a different approach, because they are fundamentally different. What I've found is that if you find yourself thinking, "Man this is so much harder to do this in X language," your approach is probably off a little. Here's an example, people talk about the "Pythonic" way of doing things. What it means is that there is a way the Python language works to make a problem easier. Doing it some other way is generally harder, and more cumbersome. You have to get over the hump of knowing how to a language works to really it work for you. It's the exact same thing with dynamic vs static languages.

Answer 7

I like both statically-typed and dynamically-typed languages. The two biggest advantages of type safety to me are:

1) You can often pretty much deduce what a function does purely from its type signature (this is particularly true in functional languages like Haskell).

2) When you do significant refactor, the compiler automatically tells you everything you have to do to keep everything working. When I refactor something in C++, my procedure is often simply a) change the one part I know I want to change, then b) fix every compile error.

Answer 8

Speed of development and flexibility is relative. Skilled developers can avoid the pitfalls either way. Working quickly can catch up with you if you're not careful.

Many have mentioned project complexity. Sorry, can't specify the cut-off from simple to complex projects, but know it when they kick you in the pants.

An uneducated child can learn their native language, why can't adults in the rest of the world?

Answer 9

For whatever reason, I don't make errors related to the type of an object that often anymore. In languages like C#, I am more likely to make errors related to runtime casts than I am likely to make a compiler-detectable type safety error, which, I grant, is usually caused by the occasional need to work around the staticness of a statically typed language. When I write ruby, the code tends to hint pretty strongly at the type of an object and the availability of a REPL means that I've already experimentally verified that the desired method/attributes exist, or I'll have a unit test that does basically the same thing, so I also rarely run into type safety problems in ruby.

But that's not to say statically typed systems can't be better than they are.

Within statically typed languages, the type system actually matters a lot as well. As an example, with something like the the Some monad in functional languages (type<Some> := yes x | no ), you gain compile-time checks that essentially prevent the dreaded NullReferenceException common in most type systems; when pattern matching code runs, you get compile time errors telling you that you failed to handle the null condition (if you use that mechanism to declare the type). You also reduce similar types of errors when you use things like the |> pipeline operator in F#.

In the Hindley–Milner tradition of static typing, you can build things that give you far more than a guarantee that a type claims to support interface X, and once you have those things, I'd say that the statically typed system becomes a lot more valuable.

When that's not an option, Design By Contract extensions to C# can add another set of mechanisms that increase the value of the static type system, but they still require more discipline than some of those functional paradigms.

Answer 10

When you're maintaining code where every function takes an array blob of data written by someone who didn't believe in documentation, you'll know why.

Answer 11

Yes, definitely. One thing you'll find as you use both strongly typed languages and Python(Python is strongly typed) more is that most well-written code in dynamic languages tends to follow a lot of the same conventions as strongly-typed code anyway. Dynamic typing is very useful for serialization and deserialization, but for most other things it really doesn't contribute much of an advantage. And unless most of your code is serialization-related, why throw out the free error-checking?

Answer 12

An important thing to keep in mind here is that Java and C++ have really terrible type systems that just get in your way half the time -- they are not very expressive. (Community wiki so that people who are more familiar with expressive type systems can expand on this.)

Answer 13

There was a similar question just asked recently: Dynamic vs Statically typed languages for websites

To restate the core of my answer:

As systems grow bigger, statically typed languages ensure robustness at component level and thus flexibility at system level.

Yes, Java is strictly typed and yes, Java sucks (no offense. it's awful. great platform & ecosystem, but one of the worst languages ever (actually being used)).
But infering from that, that strict typing sucks is just a fallacy. It's like pointing at PHP and infering dynamic typing sucks (again, no offense. it's slowly improving, I give you that).

Personally, I do most of my development in haXe, which has a static type system. Not only is it signifficantly more expressive, than that of Java and does it require much less effort due to type inference, but it's also optional. Should it ever get in your way, you just bypass it.

Type safety is a feature (this is something many supposedly high level languages don't get right) to help you prevent shooting yourself in the foot.
And about any succesfull dynamically typed language would be simply better, if you had the option have your code type checked at will.
For example, I certainly enjoyed experimenting Ruby, but that was mostly because Ruby is fully object oriented, which is entirely orthogonal to the presence of a compile time type system.

I think the claim, that static type systems are obstrusive is merely based on lack of knowledge of good static type systems. There's a number of languages that do it right, haXe being one of them, and arguably not even the best in that regard.

Example haXe code:

class Car {
    public function new();
    public function wroom() trace('wroooooooom!')
}
class Duck {
    public function new();
    public function quack(at) trace('quackquack, ' + at + '!')
}

function letQuack(o) o.quack();
letQuack(new Car());
letQuack(new Duck());

This will produce a compile time error:

Car should be { quack : Void -> Unknown<0> }
Car has no field quack
For function argument 'o'
Duck should be { quack : Void -> Unknown<0> }
Invalid type for field quack :
to : String -> Void should be Void -> Unknown<0>
For function argument 'o'

You can't really claim I had to put a lot of effort into type safety.

Saying that you don't need type safety, because you have tests is even more idiotic. Writing tests is boring and repetitive. And I really don't want to write a test, just to find out, that an instance of Car won't quack and a Duck needs someone to quack at.

At the end of the day, you will find, no matter how much overhead type safety costed you, it is eventually ammortized (even in Java - although maybe not that soon).

Answer 14

It depends.

Human failure modes are often statistical. Strong type checking reduces the likelihood of a few certain types of human failures (causing buggy code). But just because you can fail doesn't always mean you will (Murphy non-withstanding).

Whether this reduction in potential failure odds is worth the cost depends.

If you are writing code for a nuclear power plant or ATC system, any human failure mode reduction might be extremely important. If you are rapid prototyping some website idea that has no spec and with near zero failure consequences, then the reduction in failure modes or probabilities may or may not buy you anything, but may cost you in development time (more keystrokes, etc.), and in brain cells distracted by memorizing the current type(s) required.

Answer 15

You're not going to get a truly objective answer to that, but my experience is that type-safety is invaluable until you master TDD. Once you have heavy unit-test coverage, where the tests have been written before the code, the compiler-checking becomes a pain and actually starts getting in your way.

Answer 16

Interpreted languages have lost a big advantage now that we have incremental compilation. My workflow programming java in Eclipse is as fast as programming an interpreted language. I never actually perform a compile. There's continuous compilation and the compiler is giving me continuous feedback on errors in my code which is invaluable.

Answer 17

There have been a lot of very complicated systems written in Lisp, and I haven't heard any Lisper complaining that they wanted static typing. When I worked with it, I don't remember any problems that slowed me down much that a static type system (and you can specify types statically in Common Lisp) would have caught.

Moreover, mainstream statically typed languages don't seem to be well suited for catching errors. In designing a layout, what's important is that a certain number is a vertical measurement on the page, not whether it's int, unsigned, float, or double. The compiler, on the other hand, will often flag type conversions it deems unsafe, and happily let me add a vertical measurement and the number of characters in a string. This weakness of the static type system was the original idea behind Simonyi's Hungarian notation, before it was bastardized into ugly uselessness.

Answer 18

Types are constraints on interfaces, so they're a subset of what you may want to test with unit tests, and so a lot of the trade-offs are similar:

• Static types give earlier feedback on whether or not the code meets the requirements that can be expressed by the type system, in exchange for delaying feedback from building something minimally functional (like customer feedback or higher level tests).
• Knowing that the code meets certain requirements can ease refactoring and debugging, but it also adds overhead to changing interfaces and changing requirements.
• Particularly if a statically typed language lacks coercion, it provides added security against code being used on data that would cause bugs (reducing the need for conditionals and assertions), but overly restrictive constraints require the user to write more code to massage their data into an acceptable form (such as explicit type casting).
• Explicit type annotations can aid understanding when reading code, or it can clutter code with redundant or unnecessary information.
• Depending on implementation, it can detract from terseness. This depends on things like whether type annotations are required or inferred, how well the type system can express generic types/interfaces, the syntax, and whether or not you intended to test for constraints that can be expressed by the type system (i.e., the same test is likely more terse as a language feature than as a unit test, but you may not have intended to test it).
• Additionally (but unrelated to TDD), static types can aid compile time optimization, at the expense of requiring that types check (and taking the time to check them and perform the optimizations), and better optimization can be done if data is restricted to types that map well to hardware. This eases development on code with performance requirements, but can cause trouble for code that doesn't fit these constraints well (as per point 3).

To summarize, I'd argue that dynamic languages are particularly useful for prototyping, whereas if you need to be sure that your code is correct, you should favor a strong type system.

Answer 19

I see this question come up alot, and I think that your software quality (and lack of bugs) has more to do with your development process, how your system is architected, and the commitment of you and your peers to code quality.

My last job was mostly python development. I worked for a large, international web hosting company and we had dev teams in the US, Canada, and South Korea. Custom python web framework for front end customer app that allowed the users to manage their domain names and web hosting accounts. Backend: all python too. Python web service to talk to individual servers to do things like provision a new web hosting site, create a new blog, create dns entries in our name service system; etc, etc. In my current job, client apps our all in java; our main product is a mixture of java and flash. Custom java web framework for our older apps, wicket for our newer internal tools.

Having worked in both, I have to say this question bugs me every time I see it. If you are using a dynamically typed language and actually test your code you'll be fine. If the system is designed well, and you follow standards, you will be fine. There were never a lot of bugs that came up due to lack of a compiler checking types. Most bugs were logical errors, just like my java job today.

Answer 20

The benefits of languages like Ruby, or Python on the front end are hard to ignore. I still prefer type-safe languages for any back-end coding, web services, etc. I think they can live happily together, just use whatever will solve your current needs the best.

Answer 21

YES.

I have worked in PHP applications, where types are not as "strong" as in Java or C#. Usually I finished "simulating types", because, in order to avoid bad automatic conversions, or validating data.

Dynamic Type Languages are good for O.S. scripts and quick small apps., not complex apps.

Summary: If I have to choose between an "Weak Type" or "Dynamic Type" Programming language, or a "Strong Type" Programming Language for a complex, business application, I choose the "Strong Type" Programming Language.