Hacker News Reader

Comment by MikeTaylor | Hacker News Reader

For a contrary perspective, see my blog-post "We can’t afford to write safe software" (http://reprog.wordpress.com/2010/06/05/we-cant-afford-to-wri...) in which I make the rather obvious point that all the scaffolding you have to erect in statically typed languages is itself a cost, and that ignoring that is misleading. ("You have to fill in a form in triplicate before you can throw an exception", as one of our poets has written.)

Please note (if you can't be bothered to read the actual post before responding), I am _not_ saying that static typing has no value. I'm saying it has both a value _and_ a cost, and too many arguments seem to consider only one of these.

View on HN

I don't think you are really arguing against static type checking in that post, but rather the explicit type declarations that often accompany it.

These are not the same thing. See Haskell for a counterexample.

EDIT: I see that Haskell is mentioned in the comments. Still, I don't see any understanding there that static vs. dynamic is not the issue.

Haskell is inspiring, I did the interactive "Try Haskell" tutorial and though "Oh, it's dynamically typed." Later I found it it's just really good and inferring types. From what I've read, it sounds like good Haskell practice is explicitly declare types on functions, but otherwise never declare types. The compiler can then use the few explicit declarations you have made to infer all the other types.

Most of the time compiler can do without most top-level declarations too. They're a form of documentation enforced by the compiler.

The compiler can already infer all the types anyways, you don't need to declare types. It is considered good practice (and -Wall warns for it) to provide types for top level definitions, as they are usually important enough to warrant this form of machine checked documentation.

note: Yes I know the compiler can't actually infer all types all the time, but the exceptions are obvious and require type information in dynamically typed languages too (ie. convert a string to an int: you have to tell it you want an int, you can't just say "convert this string" and have it guess what you want it converted to).

But the cool thing is that in many (most?) cases you can actually infer the type of reading from a string. You are going to do something with that value right? So you can say 1 + (read "1") and the compiler will know that you must want to read "1" as a number and does that!

That kind inference only works because + is defined to work on Nums only (importing only prelude). You don't even need the initial 1. A nice trick but these are rather small details.

Yeah, I most commonly hit "oh, I need to annotate that" when I'm building some expression piece by piece in ghci, and so effectively what I'm doing with that value is "print it, as appropriate to the type" - which doesn't tell us much about what type it is.

It's also pretty easy and useful to step out of the HM, inferable fragment using any number of popular language extensions. I'm not arguing that it's a problem, but it's disingenuous to suggest that anything resembling all code can be type-inferred.

I don't think so. We are talking about haskell after all, not haskell + experimental ghc extensions. And which popular extensions break type inference anyways?

RankNTypes are pretty popular in libraries and break total inference. You don't need to enable the extension personally to suffer it either.

With the caveat that the compiler can come up with A consistent inferred typing, but it may not be the exact type you had in mind, especially when dealing with numerics. This is very rarely a problem, but in some cases may result in less optimized code than might be possible with a stricter annotation.

I'm admittedly new to the language, but my convention has been as follows:

Declare types of all named functions (i.e. not lambdas). This serves two purposes.

First, it makes your code more self-documenting. When I look at a function, probably the first thing I want to know is: "What are its parameters?" Type declarations on functions give you a trustworthy and highly readable answer to that question.

Second, it makes type errors easier to understand. If you don't explicitly declare types, the compiler will perform type inference. When your code has a type error, the compiler can infer a nonsensical type for a function, yielding a hard-to-understand error message. If your function has a type declaration, the error message is more likely to point you to where your actual mistake is.

Rarely declare types on anything that's not a top-level function definition. For example, if I want to call (foo (bar baz)), I don't need to add separate type declarations to baz, (bar baz), and (foo (bar baz)), even though each quite possibly has a different type. On the other hand, if you want to remind yourself of the type of some inner expression, or you think it'll make the type errors more readable, you can add the declaration. It won't hurt you.

I've gotten in the habit of explicitly declaring the types of everything I can. As you already mentioned it's a form of (excellent) documentation that I find myself missing in many languages - when writing Python I get frustrated because I have to go dig or debug the type of a value when in Haskell I can simply look for the type declaration (happily Python I think is considering type annotations). If you use Emacs, haskell-mode and ghc-mod + ag or grep have some awesome features for finding type definitions in source, querying hoogle, and lambdabot style de-sugaring and queries.

While type inference is cool, it's only really useful when I'm playing inside GHCi. Also - it can often improve the quality of a program a lot by thinking about your types first, declaring them, then filling out the function definitions (that is often how I do it).

On the flip side, I tend to declare types mostly at the top level. It's nice to be able to change just a few types and have everything else work itself out. There are times it doesn't work and I don't hesitate to add more type annotations then, and when I get weird type errors my first response is go through and decorate it piece by piece.

You're right that it has a cost (although type inference can significantly reduce that cost). But...

From TFA:

"They write test cases for every identifier ever used in the program. In a world where misspellings are silently ignored, this is necessary. This is a cost."

So in a dynamic language the cost is still there. In fact, it's probably higher than in a static language because you have to build at least some of the infrastructure yourself. Well, I imagine some people would argue that in a dynamic language the cost is optional. And again, I point to type inference where sophisticated static languages achieve the same thing.

> In a world where misspellings are silently ignored, this is necessary.

How does "dynamic typing"="misspellings are silently ignored"? Maybe in some languages but that's not a corollary of dynamic typing.

Disclaimer: Haven't read TFA so shoot me down if the context makes this clear

TFA was talking specifically about Javascript there. But I think the overall point about the cost of testing applies to dynamic typing across the board.

How would one consider JS to silently ignore misspellings?

Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs.

And yes, you'll need to do a little bit of infrastructure on the test cases, but you'll gain the extra power that comes with dynamic types, that makes everything (even writting tests) much easier. And, of course, your codebase can be much less "huge" with that extra power.

Anyway, all that thing is a big red herring. Nobody decides to create a huge codebase.

> but you'll gain the extra power that comes with dynamic types

What "extra power" are we talking about here? If we're talking about the power to pretend a bool is a string or vice versa, then no thanks, I'll pass. I suspect that a number of the things you are referring to that give you "extra power" are actually things that don't have anything to do with the type system like first class functions, tuples, etc. Static languages can have those things too, you know.

> If we're talking about the power to pretend a bool is a string or vice versa, then no thanks

That's weak typing. JavaScript does this, Python and Ruby don't.

Typically when people bring up the power of dynamic languages it's in the ability to alter definitions. The ability to extend existing classes/objects is pretty powerful, and isn't always trivially duplicated in static languages.

Many concepts that can be painful in statically typed languages (creating/programming against new interfaces to existing types, reflection, delegation, etc) are easy as breathing with dynamic types. It's not a matter of can vs. can't so much as easy vs hard.

Oh right, my mistake.

s/pretend a bool is a string or vice versa/not know whether an object even has a certain method because it isn't added until runtime/

I'll grant you that this type of thing is more difficult in static languages. But in my experience, the need for this kind of dynamic behavior is quite rare in terms of lines of code. So I'll trade it away any day of the week for the ability to reason about my code with more guarantees. At their core, all bugs are situations where the programmer's expectations didn't match reality. In my experience programmers who are good at debugging are good at being able to question as much of what could be going wrong as possible. Strong static types are about reducing the amount of things we have to question.

"Except that'll write those same tests on staticaly typed languages (except Haskell), because their typing system isn't powerfull enough to detect most bugs."

Agda is offended.

The counter argument is the main argument for clean code and documentation -- code is consumed much more than it is produced.

You can hack code together and forgo documenting it, but it's a form of technical debt. When creating a minimum viable product for a startup, taking on some forms of technical debt probably makes sense, but by the time you're talking about huge code bases, you're probably past the startup phase (I hope) and you're already up to your neck in technical debt.

Related: static typing is itself documentation (low-cost, machine-checked documentation).

When the static type checking system has an inference engine there is a strong incentive not to document types on the part of programmers. Conversely, a requirement that for explicit type declarations makes the use of generics more cumbersome.

Fortunately, your IDE can use inference to add a type signature with a keystroke.

And now you've added the cost of mandating an IDE, and someone has to write that feature for the IDE in the first place.

The feature exists in emacs and vim, and is nice but not mandatory.

It should be easy to integrate into any editor.

"It should be easy to integrate" is the downfall of many a software developer.

Anyway, my point is not that it's difficult or bad: it's that it's has _some_ cost.

> When the static type checking system has an inference engine there is a strong incentive not to document types on the part of programmers.

But then the compiler has the capacity to write/emit the type declarations.

> When the static type checking system has an inference engine there is a strong incentive not to document types on the part of programmers.

Not the case in Haskell, at least. Most Haskell code out uses type signatures.

> Conversely, a requirement that for explicit type declarations makes the use of generics more cumbersome.

True enough, but you can't have your cake and eat it. Either you want explicit documentation-by-types, which has a cost, or you don't (which also has a cost in terms of maintenance).

Yes, but mostly this type of documentation: http://photos1.blogger.com/blogger2/1715/1669/1600/larson-oc...

A contrary perspective? Even the original post is a dubious argument to the effect of "it's not that the language is dynamic, it's that dynamic languages lack X or Y!".

For me, I've looked inside one of the biggest Python codebases in existence (the EVE Online client). It's a freaking mess. A simulation of static typing but mostly they just passing freaking tuples around. Everything is a tuple in a tuple in a dictionary in a tuple in a homegrown table.

Any modern type system barely require scaffolding, lowering the cost and providing a way more value (see Haskell or ML, or even compare Java with Scala)

You're confusing static typing with explicit typing. This is static typing's version of the "dynamic typing doesn't have to be weak typing" argument.

There are a variety of languages that don't impose explicit typing on you to enable static typing. OCaml and Haskell are popular options. Scala makes the compromise choice of having explicit function signatures with inferred typing elsewhere.

If the only thing you're using the type system for is to make sure arguments line up, you're barely using it at all. When your types can encode (and thus, ensure) aspects of your program logic, that is when static typing becomes useful.

I view the extra scaffolding as writing unit tests. The type definitions are just a way to specify unit tests in a formal way. The compiler does the rest of unit testing using the type definition, at compile time. With the correct tools a lot of the scaffolding are automated and kept to a minimum so not much is loss.

The op is arguing that static typing is correlated with project scalability (due to language support for a number of other features that help encapsulation, modularity, etc). Not that static typing by itself is what makes it easier to scale project complexity.

For C++, note the now accepted use of `auto` and `decltype` which together remedy a number of issues from C++03 and prior.

That might be one of the reasons that type information is optional in Erlang, and what makes it fairly expressive at the cost of some static analysis.

>in which I make the rather obvious point that all the scaffolding you have to erect in statically typed languages

You mean "in which I pose the rather obvious strawman". What scaffolding? What is this mysterious "extra stuff" people give vague names like "scaffolding" to that I've never encountered despite programming in a statically typed language all the time?

I think he means having to implement toString() ten times to handle all the various types that need to be converted to strings. toString() is a trivial example because most languages have that built-in to some degree. But there have been several times where I would have to write the same C/C++ function again and again to support a new type.

Try "deriving (Show)". And stop using the C/C++/Java straw man as the basis for arguing against static type systems.

I don't know what your first sentence means. As for the second, I was explaining what I thought the author meant by "scaffolding" not making an argument for or against anything. Now here is an argument for you: shouldn't two of most widely used languages be included in an argument about static vs dynamic typing?

The first sentence is a hint toward Haskell's wonderful derivation system which tells the compiler to write the "obvious" code for all kinds of common scaffolds. It's almost always all you need for equality, showing, ordering, hashing. There's also the GeneralizedNewtypeDeriving which allows you to inherit instantiation of types into all kinds of structurally equivalent types.

And while it's valuable to talk about popular languages in terms of the kind of static typing people are likely to encounter... they also have really outdated static type systems. While you can argue that it's likely that you'll bump into Java/C/C++ when working with static types, it's pretty invalid to argue generally about static type systems using them as examples. Things have just come a really long way.

Fair enough.

He was referring to Haskell's syntax for derived instances - http://www.haskell.org/tutorial/stdclasses.html#sect8.4

And my first sentence was explaining why even that interpretation of the author's meaning is an invalid argument. It demonstrates the equivalent of writing toString() in Haskell. And no, the two most widely used languages should most definitely NOT be used in an argument about static typing because the state of the art in static typing has evolved significantly since those languages were created. The fact that you didn't know the meaning of my first sentence tells me that you're arguing from ignorance about what is possible today in a fairly well-established language.

> shouldn't two of most widely used languages be included in an argument about static vs dynamic typing?

No, because the affordances and limitations of static typing are not the same as the affordances and limitations of static typing as implemented in Java/C++. You can't infer very much about static typing from statements made about those languages, and you can't infer much about those languages from statements made about static typing, so it follows that you can't freely substitute one for the other in these discussions.

stop using JavaScript as the basis for arguing against dynamic type systems.

(not necessarily directed at you personally)

Who does that? Dynamic type systems don't actually exist, it is simply a lack of a static type system. Nobody argues about dynamic type systems, they argue about whether or not to have a static type system.

But if we exclude C/C++/Java then static typing is just an obscure feature of some academic languages.

Why did you have to write the same function again and again? I guess polymorphism would have helped, would it not? Not knowing too much c++ I can't really comment so I guess I am asking for a clarification.

C does not have proper support for polymorphism. It can be simulated with structs in certain cases though. I can't remember a specific instance with C++ off the top of my head. It has been a several years since I touched it. Sorry.

That is an argument against particular languages that happen to be statically typed. That is not an argument against static typing, which requires nothing of the sort.

In Python, you have to reimplement __repr__ for every class whereas in Haskell you use deriving Show. This has nothing to do with static vs dynamic.

Python's `__dict__` is probably a better example of duplicating Haskell's `derive Show` behavior.

Why? __repr__ (or __str__) is pretty much the "show" method, in Python. It isn't derivable (or rather, the default derivable one is useless), though.

In what language do you not have to implement a conversion-to-string for each type? It's not like the compiler can know what string representation you have in mind for some arbitrary object.

Haskell. It's often not about a specific representation, but rather just some representation that allows you to see a type's internals.

For debug purpose (like you'd use Show in Haskell), Perl gives use Data::Dumper to dump your data structures. Not quite the same as deriving Show, but for most purposes, entirely sufficient.

> there have been several times where I would have to write the same C/C++ function again and again to support a new type.

If the function has to handle different types in different ways, you'd have to write it again anyway. Otherwise, you could have used templates.

One example in the article was the difference between def qsort(a) and public static void ArrayList<Integer> qsort(ArrayList<Integer> a)

The cost is significantly reduced by type inference (see Go and Vala).

Go does not do type inference, it just does type deduction, a much weaker thing that at least relieves some basic tedium, but still leaves the source code fairly full of type declarations.

Reply on news.ycombinator.com