How is static typing really helpful in bigger projects?

Question

While curiosing on the main page of a scripting programming language's site, I encountered this passage:

When a system gets too big to keep in your head, you can add static types.

This made me remember that in many religious wars between static, compiled languages (like Java) and dynamic, interpreted languages (mainly Python because it's more used, but it's an "issue" shared between most scripting languages), one of the complaints of statically typed languages' fans over dynamically typed languages is that they don't scale well to bigger projects because "one day, you'll forget the return type of a function and you'll have to look it up, while with statically typed languages everything is explicitly declared".

I never understood statements like this one. To be honest, even if you declare the return type of a function, you can and will forget it after you've written many lines of code, and you will still have to return to the line in which it's declared using the search function of your text editor to check it.

As an addition, as functions are declared with type funcname()..., without knowing type you will have to search over each line in which the function is called, because you only know funcname, while in Python and the like you coud just search for def funcname or function funcname which only happens once, at the declaration.

More over, with REPLs it's trivial to test a function for it's return type with different inputs, while with statically typed languages you would need to add some lines of code and recompile everything just to know the type declared.

So, other than to know the return type of a function which clearly isn't a strength point of statically typed languages, how is static typing really helpful in bigger projects?

Answer 1

More over, with REPLs it's trivial to test a function for it's return type with different inputs

It's not trivial. It's not trivial at all. It's only trivial to do this for trivial functions.

For instance, you could trivially define a function where the return type depends entirely on the input type.

getAnswer(v) {
 return v.answer
}

In this case, getAnswer doesn't really have a single return type. There is no test you can ever write that calls this with a sample input to learn what the return type is. It will always depend on the actual argument. At runtime.

And this doesn't even include functions that, e.g., perform database lookups. Or do things based on user input. Or look up global variables, which are of course of a dynamic type. Or change their return type in random cases. Not to mention the need to test every single individual function manually every single time.

getAnswer(x, y) {
   if (x + y.answer == 13)
       return 1;
   return "1";
}

Fundamentally, proving the return type of the function in the general case is literally mathematically impossible (Halting Problem). The only way to guarantee the return type is to restrict the input so that answering this question does not fall under the domain of the Halting Problem by disallowing programs that are not provable, and this is what static typing does.

As an addition, as functions are declared with type funcname()..., whitout knowing type you will have to search over each line in which the function is called, because you only know funcname, while in Python and the like you coud just search for def funcname or function funcname which only happens once, at the declaration.

Statically typed languages have things called "tools". They are programs that help you do things with your source code. In this case, I would simply right click and Go To Definition, thanks to Resharper. Or use the keyboard shortcut. Or just mouse over and it will tell me what the types involved are. I don't care in the slightest about grepping files. A text editor on its own is a pathetic tool for editing program source code.

From memory, def funcname would not be enough in Python, as the function could be re-assigned arbitrarily. Or could be declared repeatedly in multiple modules. Or in classes. Etc.

and you will still have to return to the line in which it's declared using the search function of your text editor to check it.

Searching files for the function name is a terrible primitive operation that should never be required. This represents a fundamental failure of your environment and tooling. The fact that you would even consider needing a text search in Python is a massive point against Python.

Answer 2

Think of a project with many programmers, that has changed over the years. You have to maintain this. There's a function

getAnswer(v) {
 return v.answer
}

What on earth does it do? What's v? Where does the element answer come from?

getAnswer(v : AnswerBot) {
  return v.answer
}

Now we have some more info —; it needs a type of AnswerBot.

If we go to a class-based language we can say

class AnswerBot {
  var answer : String
  func getAnswer() -> String {
    return answer
  }
}

Now we can have a variable of type AnswerBot and call the method getAnswer and everyone knows what it does. Any changes are caught by the compiler before any runtime testing is done. There are many other examples but perhaps this gives you the idea?

Answer 3

You seem to have a few misconceptions about working with large static projects that may be clouding your judgement. Here are some pointers:

even if you declare the return type of a function, you can and will forget it after you've written many lines of code, and you will still have to return to the line in which it's declared using the search function of your text editor to check it.

Most people working with statically typed languages use either an IDE for the language or an intelligent editor (such as vim or emacs) that has integration with language-specific tools. There is usually a fast way of finding the type of a function in these such tools. For example, with Eclipse on a Java project, there are two ways you'd typically find the type of a method:

• If I want to use a method on another object than 'this', I type a reference and a dot (e.g. someVariable.) and Eclipse looks up the type of someVariable and provides a drop down list of all the methods defined in that type; as I scroll down the list the type and documentation of each is displayed while it is selected. Note that this is very difficult to achieve with a dynamic language, because it is hard (or in some cases impossible) for the editor to determine what the type of someVariable is, so it cannot generate the correct list easily. If I want to use a method on this I can just press ctrl+space to get the same list (although in this case it is not that hard to achieve for dynamic languages).
• If I already have a reference written to a specific method, I can move the mouse cursor over it and the type and documentation for the method is displayed in a tooltip.

As you can see, this is somewhat better than the typical tooling available for dynamic languages (not that this is impossible in dynamic languages, as some have pretty good IDE functionality -- smalltalk is one that jumps to mind -- but it is harder for a dynamic language and therefore less likely to be available).

As an addition, as functions are declared with type funcname()..., whitout knowing type you will have to search over each line in which the function is called, because you only know funcname, while in Python and the like you coud just search for def funcname or function funcname which only happens once, at the declaration.

Static language tools typically provide semantic search capabilities, i.e. they can find definition of and references to particular symbols precisely, without needing to perform a text search. For example, using Eclipse for a Java project, I can highlight a symbol in the text editor and right click it and choose either 'go to definition' or 'find references' to perform either of these operations. You don't need to search for the text of a function definition, because your editor already knows exactly where it is.

However, the converse is that searching for a method definition by text really doesn't work as well in a large dynamic project as you suggest, as there could easily be multiple methods of the same name in such a project, and you likely have no readily available tools to disambiguate which one of them you are invoking (because such tools are hard to write at best, or impossible in the general case), so you will have to do it by hand.

More over, with REPLs it's trivial to test a function for it's return type with different inputs

It isn't impossible to have a REPL for a statically typed language. Haskell is the example that springs to mind, but there are REPLs for other statically typed languages too. But the point is that you don't need to execute code to find the return type of a function in a static language -- it can be determined by examination without needing to run anything.

while with staticly typed languages you would need to add some lines of code and recompile everything just to know the type declared.

Chances are even if you did need to do this, you wouldn't have to recompile everything. Most modern static languages have incremental compilers that will only compile the small portion of your code that has changed, so that you can get almost instantaneous feedback for type errors if you make one. Eclipse/Java, for example, will highlight type errors while you're still typing them.

Answer 4

1. Because static checkers are easier for statically typed languages.
   • At a bare minimum, with no dynamic language features, if it compiles, then at runtime there are no unresolved functions. This is common in ADA projects and C on microcontrollers. (Microcontroller programs get big sometimes... like hundreds of kloc big.)
2. Static compile reference checks are a subset of function invariants, which in a static language can also be checked at compile-time.
3. Static languages usually have more referential transparency. The result is that a new developer can dive in to single file and understand some of what's going on, and fix a bug or add a small feature without having to know all the strange things in the codebase.

Compare with say, javascript, Ruby or Smalltalk, where developers do redefine core language functionality at run time. This makes understanding the large projct harder.

Bigger projects don't just have more people, they have more time. Enough time for everyone to forget, or move on.

Anecdotally, an acquaintance of mine has a secure "Job For Life" programming in Lisp. Nobody except the team can understand the code-base.

Answer 5

I never understood statements like this one. To be honest, even if you declare the return type of a function, you can and will forget it after you've written many lines of code, and you will still have to return to the line in which it's declared using the search function of your text editor to check it.

It's not about you forgetting the return type -- this is always going to happen. It's about the tool being able to let you know that you forgot the return type.

As an addition, as functions are declared with type funcname()..., whitout knowing type you will have to search over each line in which the function is called, because you only know funcname, while in Python and the like you could just search for def funcname or function funcname which only happens once, at the declaration.

This is a matter of syntax, which is completely unrelated from static typing.

The C family syntax is indeed unfriendly when you want to look up a declaration without having specialized tools at your disposal. Other languages don't have this problem. See Rust's declaration syntax:

fn funcname(a: i32) -> i32

More over, with REPLs it's trivial to test a function for it's return type with different inputs, while with statically typed languages you would need to add some lines of code and recompile everything just to know the type declared.

Any language can be interpreted and any language can have a REPL.

---

So, other than to know the return type of a function which clearly isn't a strong point of statically typed languages, how is static typing really helpful in bigger projects?

I'll answer in an abstract way.

A program consists of various operations and those operations are laid out the way they are because of some assumptions the developer makes.

Some assumptions are implicit and some are explicit. Some assumptions concern an operation near them, some concern an operation away from them. An assumption is easier to identify when it is expressed explicitly and as close as possible to the places where its truth value matters.

A bug is the manifestation of an assumption that exists in the program but doesn't hold for some cases. To track down a bug, we need to identify the erroneous assumption. To remove the bug, we need to either remove that assumption from the program or change something so that the assumption actually holds.

I'd like to categorize assumptions into two kinds.

The first kind are the assumptions that may or may not hold, depending on the inputs of the program. To identify an erroneous assumption of this kind, we need to search in the space of all possible inputs of the program. Using educated guesses and rational thinking, we can narrow down the problem and search in a much smaller space. But still, as a program grows even a little bit, its initial input space grows at an enormous rate -- to the point where it can be considered infinite for all practical purposes.

The second kind are the assumptions that definitely hold for all inputs, or are definitely erroneous for all inputs. When we identify an assumption of this kind as erroneous, we don't even need to run the program or test any input. When we identify an assumption of this kind as correct, we have one less suspect to care about when we're tracking down a bug (any bug). Therefore, there is value in having as many assumptions as possible belong to this kind.

To put an assumption in the second category (always true or always false, independent of inputs), we need a minimum amount of information to be available at the place where the assumption is made. Across a program's source code, information gets stale pretty quickly (for example, many compilers don't do interprocedural analysis, which makes any call a hard boundary for most information). We need a way to keep the required information fresh (valid and nearby).

One way is to have the source of this information as close as possible to the place where it's going to be consumed, but that can be impractical for most use cases. Another way is to repeat the information frequently, renewing its relevance across the source code.

As you can already guess, static types are exactly that -- beacons of type information scattered across the source code. That information can be used to put most assumptions about type correctness in the second category, meaning that almost any operation can be classified as always correct or always incorrect with respect to type compatibility.

When our types are incorrect, the analysis saves us time by bringing the bug to our attention early rather than late. When our types are correct, the analysis saves us time by ensuring that when a bug occurs, we can immediately rule out type errors.

Answer 6

You remember the old adage "garbage in, garbage out", well, this is what static typing helps to prevent. Its not a universal panacea but the strictness over what kind of data a routine accepts and returns means that you have some assurance that you're working correctly with it.

So a getAnswer routine that returns an integer will not be useful when you try to use it in a string-based call. The static typing s already telling you to watch out, that you're probably making a mistake. (and sure, you can then override it, but you'd have to know exactly that's what you're doing, and specifying it in the code using a cast. Generally though, you do not want to be doing this - hacking in a round peg into a square hole never works well in the end)

Now you can take it further by using complex types, by creating a class that has ore functionality, you can start passing these around and you suddenly get much more structure in your program. Structured programs are ones that are much easier to make work correctly, and also maintain.