Static typing will not save us from broken software
drmaciver.com
drmaciver.com
Yesterday was a pretty productive day for me. TypeScript easily caught hundreds of little errors as I coded and refactored which I fixed just a quickly. Most of the time when I tested my changes things just worked. I thought to myself every time TypeScript found something, 'wow I just avoiding another runtime error, thanks'
Maybe people don't write or maintain client side software at scale. I don't know. But there's so little cost to having static typing I don't know why you wouldn't want it. I am easily an order of magnitude more productive with it. I code faster, my code works first time around more often, other people can understand my code easier, and my tests don't have to worry about validating types so they can be more logic oriented.
There is zero chance anyone would of been able to be as productive as I was yesterday if that code base was dynamically typed. Not even close.
For many pure front-end devs that have never really worked with static typing, the compiler just seems like another arbitrary build step in the pipeline with no discernible benefit.
I don't think the OP would claim TypeScript is a bad idea, as, with its relatively weak type system, it doesn't really suffer from "if you find a bug it’s easy and unintrusive to add a test for it, but may require a substantial amount of work to refactor your code to add types that make the bug impossible".
As an example of a strong type system, in Haskell code, the database access layer will may types such as "ISO-8859-1 string of at most ten characters"
If it turns out that you want to store ISO-8859-2, changing that type can and often will cause a cascade of necessary changes, for example because you're calling a ISO-8859-1 to UTf-8 conversion function, and the compiler will not accept that call to now take a ISO-8859-2 string, or because you are concatenating that string with another ISO-8859-1 one. Then, you will have to decide whether to convert locally or whether to also change the type of that second string, etc.
Now, of course, each of those compilation errors becomes a bug if you just use variable-sized byte arrays. Question is how much work you are willing to do to prevent those bugs.
Static typing provides universal guarantees, which sounds great at first, until you realize that it really does mean "universal". Sometimes that extreme rigidity makes changes very difficult, especially when you're dealing with cross-cutting changes across many teams and organizations.
I work in a very large company with lots of services. The best practice, espoused by most of the senior/principal engineers (particularly ones with extensive SOA experience), is to keep your service interfaces and document models dynamically-typed. It makes them much easier to change. Big systems should be assembled from loosely-coupled components which are internally rigid but externally flexible and dynamic.
When operating at any sort of scale, a system that's "easy to change" stops sounding virtuous. Communicating and integrating service changes effectively is usually more expensive than making the changes themselves, for a large organization. Providing service descriptions which can be converted into static types (e.g. swagger) is very cheap, and can prevent a host of expensive human errors.
In truth, poorly specified services or documents can end up impossible to change, since the risk and impact of doing so is difficult to size (or the exercise of doing so costs more than the change is worth).
In many situations, a true statically-typed service interface can be nearly impossible to change, or even add fields to. Adding new schema versions (particularly for write APIs) or dynamic/polymorphic schemas that change based on the input are extraordinarily useful and very easy with dynamically-typed interfaces, but can be very difficult with strict statically-typed interfaces, particularly the kind that e.g. Java nudges developers towards.
There are some hybrid frameworks that mix dynamic and static typing, which solve some of these problems (e.g. protobuf, Avro, Ion). They make reasonable compromises.
Confirmed.
TBH there are very few languages that I'd claim were a bad idea. The point I'm making is not "Statically typed languages are a bad idea" it's "If you think statically typed languages are going to make software correctness magically better then you're going to be disappointed".
> My general experience of the correctness software written in fancy statically typed languages is not overwhelmingly positive compared to that of software written in dynamic languages. If anything it trends slightly negative.
ETA: The point of that anecdotal impression was not "This is definitely true" but "Given that this is my general experience it would be surprising if the actual trade offs experienced in practice were such that static typing was regularly a clear winner", which I feel much happier supporting on an impression than "You should do this".
Not everybody writes new stuff; some software has to interface with stuff written decades ago.
Also, even for software 100% written today it often is impossible to stay in a world where all strings use compatible encodings.
Examples where you need conversions: when connecting systems that support different Unicode versions or when generating http headers, windows file names, or QR codes. I guess many 'older' systems will not handle ZIP or tar files that use UTF-8 for file names in the archive, either.
I have a smaller Scala code base to maintain (around 50k lines) and it is a breeze b/c many types are annotated, e.g. Money @@ Netto or String @@ InvoiceNumber. Beside Option this has been the greatest productivity gain vs. Java.
My team did a big refactor on our ClojureScript code base last week. We've been developing the project for over a year now. We had no trouble with type refactoring. We use Schema (https://github.com/plumatic/schema) to validate the data at the edges, and the REPL to run code as we write it. Type errors simply have never been a problem for us.
I change the property 'Part' to 'PartList' on my DTO and now I need to find all places that Part is referenced and update them.
I have a function that takes a 'User' as a parameter, but I don't know what the property is called for the display name. Is there an easy way of figuring it out without running the app? REPL wouldn't help because I dont even know how to create a User object (this is a very large code base that I didn't write myself)
I add a new parameter to a render() function and I need to find out all the places the function is called so I make sure to update them.
I make a spelling mistake calling a function or referencing a property. Do I get any instant alert to the error or do I have to run the app, or run REPL on it?
If I'm changing tons of code across many files I don't want to have to run/REPL for every little thing to validate that I didn't make a dumb mistake. Ideally the mistake is caught as soon as I type it. Does ClojureScript have this?
Yup, I use Cursive IDE (https://cursive-ide.com/) and it provides precise symbol lookup using static analysis.
>I have a function that takes a 'User' as a parameter, but I don't know what the property is called for the display name.
Clojure is a functional language so I don't have a problem of dealing with a plethora of classes. The data model is defined using the schema and I can easily tell what it looks like. Furthermore, since it's a functional language, I don't have any global state to worry about. I can try any function in the REPL in isolation to see what it's doing and how it behaves with different inputs.
Destructuring (http://clojure.org/guides/destructuring) is alos commonly used for readability in Clojure. When a function takes a non-primitive type, it's idiomatic to destructure it to show what the shape of the data is right in the arguments.
>I add a new parameter to a render() function and I need to find out all the places the function is called so I make sure to update them.
Yup, absolutely. I can look up usages of a function in Cursive.
>I make a spelling mistake calling a function or referencing a property. Do I get any instant alert to the error or do I have to run the app, or run REPL on it?
Yes, Cursive will highlight undefined symbols as well is invalid function arity. I get immediate feedback if I mistype something, try to use a function that doesn't exist, or pass wrong number of arguments to a function.
>Ideally the mistake is caught as soon as I type it. Does ClojureScript have this?
That's generally exactly what happens in my experience, and in addition I also have the REPL that lets me run any code if I'm not sure about what it's doing.
I think that Clojure has much cleaner language semantics than JavaScript, and this makes the code much easier for the IDE to analyze it.
That said, there is optional static typing available with Typed Clojure, and it can even generate type annotations from tests as seen here: https://github.com/typedclojure/auto-annotation
My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system.
In addition to this failure to use the type systems, testing is becoming a much more rich environment. I think popular resources on effective testing are much better and numerous than popular resources on effective typing. There are great books and tools around helping developers test their software more thoroughly and efficiently. Comparing these testing resources with typing resources, the closest popular book I can think of for typing is Design Patterns, and I don't think most popular type systems are built with the program correctness as a top priority.
I think rich type systems like haskell's will play more of a role in the future, and I think current users of these systems do experience a benefit. But if you have only ever done dynamically typed programming or used Java/C#, you are probably going to improve your correctness more over the next year by using a property based testing tool like propr (ruby), hypothesis (python), fscheck (.net), scalacheck (jvm), or jsverify (js), spec (clojure).
(I maintain a list here: http://hypothesis.works/articles/quickcheck-in-every-languag...)
This sounds like C# as written by people that don't really know or like C#. If you're stuffing everything into strings or a dynamic, you missed the point of the type system in a very serious way.
> In addition to this failure to use the type systems, testing is becoming a much more rich environment. I think popular resources on effective testing are much better and numerous than popular resources on effective typing. There are great books and tools around helping developers test their software more thoroughly and efficiently. Comparing these testing resources with typing resources, the closest popular book I can think of for typing is Design Patterns, and I don't think most popular type systems are built with the program correctness as a top priority.
There is some overlap between problems that can solved by type systems and test suites, but there are many problems that can only be caught by one or the other.
It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles.
I agree, but I think it is the reality. Software development is a job, not divine appointment. And assuming it is reality, I think the best short term gain those developers isn't doubling down on type systems.
> It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles.
I'm totally with you. I remember a friend being so impressed when a hypothesis test caught a bug in an example that I set up. The funny thing was that I made the example from a function over an F# Union. A lot of people seem to get super irritated by compiler errors but seem to be really impressed by clever testing. I think it has to do with the error messages. Property based testing frameworks tend to show you the simplest concrete example of your error. Type checkers tend to show you the most abstract example of your error. Maybe if type checkers started to to incorporate more concrete examples of error, people would generally find them more appealing.
I think this is a really important insight! And in fact, there is some recent research about making type checkers produce counterexamples: http://lambda-the-ultimate.org/node/5355. Ergonomics of type systems is an unfortunately understudied area.
Also, there are cases where using strings is more appropriate than using enums. Where passing a blob is preferred over guaranteeing the correctness of the blob's structure. Where "null" really is better than an Option type.
And conversely, there are companies who hire crappy developers or don't give their good developers enough time to learn the idioms and best practices of their tools.
WAT? Give me an example.
Theoretically it's not necessary, but given real-life constraints, there are most definitely times when null is more appropriate than e.g. Java's Optional.
Error handling with null is wrong and broken, regardless of whether the null is "typed" or not.
null might have some very limited other uses, but they will never compete with those structures designed for error handling, because they do something fundamentally different.
Java is the platform with NPEs and null checks everywhere. If that's your definition of practical, sure, go ahead.
someOptional.map(a).map(b) NOT EQUAL TO someOptional.map(a.andThen(b)Because of the order in which side effects occur, or is there something else as well? (I haven't Javaed in anger since before Optional).
scala> val str: Function[String, String] = s => if (s.length > 3) s else null
str: java.util.function.Function[String,String] = $$Lambda$1369/859456754@2c668c2a
scala> val num: Function[String, Integer] = s => if (s == null) -1 else s.length
num: java.util.function.Function[String,Integer] = $$Lambda$1376/1887041776@121cf6f4
scala> Optional.of("Foo").map[String](str).map[Integer](num)
res12: java.util.Optional[Integer] = Optional.empty
scala> Optional.of("Foo").map[Integer](str.andThen(num))
res15: java.util.Optional[Integer] = Optional[-1]
It also leads to all sort of weird usability issues: The old "`someMap.get(...)` returned null ... now does that mean the entry doesn't exist, or the entry exists and it is null?"
In fact they are currently working on special hacks to Java 10's Generics, because they realized that important collection classes don't work well with specialization, and even their new Optional can't save them. (Not directly related, but a good example how design mistakes combine and cause even more pain down the road.)
My point was not specifically aimed at typed nulls and compiler optimization, it was that there will always be practical constraints that force us to compromise static guarantees in order to get things done in a reasonable amount of time. As software engineers, our problems are first practical before they are theoretical.
In my experience, the opposite is the case. If I can offload some checks to my tooling, I don't have to be constantly performing them mentally. And with type inference at a repl, I can ask about the shape of things that can't possibly run yet (though I don't think I get that with C#).
I see this happen when a bad database design was born before the C# code, e.g. varchar NULL types everywhere.
1. Start using hypothesis or jsverify. 2. Play around with Elm. 3. Participate in a community that highly values types.
## Properties vs Types
Just to explain a bit, types and properties are about program correctness. So they serve the same purpose for us. Types are essentially properties that your type checker can prove for you. Sometimes it is hard or impossible to prove something, so you might reach for property based tests to "approximate" the proof.
So when I'm thinking about my code correctness: 1. write a type where I can 2. write a property where I want to write a type 3. write examples to keep me grounded
Property based testing frameworks will help you move up that ladder.
## Elm
Of course, it will also be helpful to start actually leveraging a type system. I think Elm is a good option for people who are new to using types this way. It has a powerful, but relatively simple, type system that can help you learn good type design without having to deal with all of the features that Haskell/Scala/Rust/Ocaml/etc would have. Also, it has pretty great compiler error messages. So it should be less intimidating than a lot of nearby options.
## Community
Community might be the most important element. Participating in a community that values types (again, I suggest Elm) will be a great investment. Downloading Elm and a property based testing library could be a recipe to feel overwhelmed. Be sure to have a slack channel/mailing list/irc channel ready to help you when you start to feel overwhelmed.
The main advantage for static typing from my experience are what happens when you have projects above 10kloc with multiple maintainers, and maybe the original devs have moved on to other teams. At that stage in a product's lifecycle, static typing reduces friction and covers some cases that are hard to test properly. Greenfield projects don't suffer from this problems for the first year or so.
Refactoring is the major thing that's easier with static typing, IMO.
I agree though: it's a tool in the tool belt. It also varies dramatically across different languages and supported features which can make a huge difference in the kinds of problems it solves for you. Lately I've been doing a lot more modeling of problems with types when it makes sense... things like measurement units and their operators to ensure you can't accidentally add meters to watts. Or using unique ID types for each model so you can't accidentally create a reference with the wrong ID.
The newer languages and updated standards (e.g. Swift, Rust, C++ with auto) take a lot of the useless repetition of types out of the equation and feel more like type annotations in a dynamic language. In the end I think we'll mostly settle on hybrids. Some will be static by default but support dynamism. Others will be dynamic by default but support static type annotations.
What won't change is that you can't scale transistors below a single atom and we can see that endpoint on the roadmap. Performance improvements will not continue at the current rate. One could argue we're already there given the perf delta between CPU and memory or CPU and storage has gotten orders of magnitude worse.
In a future where abstractions impose a real cost the optimization function may change, especially for established businesses and processes. Hiring a couple of Rust or Swift senior devs to rewrite your Python backend in a statically compiled language, then applying repeated optimizations might be worth the cost when you know it will be 10 years before a new CPU is released and it will be 10-20% faster at best. Or if you imagine future CPUs require exotic materials and 10x as much R&D to hit the same targets they become 10-100x as expensive.
Citation needed.
Most proponents of static typing, myself includes, have much more modest claims: that is saves time spent by developers on smaller, more mundane errors. That it makes refactoring easier. That it allows for better IDE support like autocompletion and hover-over documentation.
Even if these advantages are modest compared to fixing "broken software", they're still huge and worth the increasingly minor annoyances of modern static type systems, many times over.
This is the premise of a large part of the article. And it is wrong. At the very least a citation is needed. And even if there is a scientific source, I disagree with it. I'd argue that many people do want to write non-broken software, but they do not know how to efficiently use static type system, or they don't know how effective it is. If all you know is Java or C then of course you're going to doubt if a type system is worth at all.
> As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it usually comes with an additional cost: Build times.
I disagree. When you are working with Haskell, use ghcid and you'll have near instant recompile times. I made a proof-of-concept of a web frontend in Haskell, and it reloads with sub-second delay. That is comparable to a JavaScript project which uses webpack and babel.
If catching the types of bugs that static typing prevents resulted in reduced costs of software development, you'd see static typing out-compete dynamic typing. It's really that simple.
Apart from network effects, inertia, lack of education and awareness, and all the other confounding factors.
Considering how long both disciplines have been around, you'd think we'd see some clear benefits by now. Yet, here we are swapping anecdotal evidence.
You can't ask the general developer population how they feel about static vs dynamic typing. The result will be biased towards dynamic because that's the only thing most developers know.
https://courses.cs.washington.edu/courses/cse590n/10au/hanen...
http://macbeth.cs.ucdavis.edu/lang_study.pdf
http://eprints.bournemouth.ac.uk/10668/1/tratt__dynamically_...
Well, that pretty much signals how people should interpret the rest of what you say.
Being able to hit . and get a reliable list of things I can do is worth many millions of dollars to me.
...and mostly is possible because of the many millions of dollars that were thrown into developing it rather than the type system. Quality of tooling has much more to do with the amount of money invested in it than whether the language is statically typed.
But this isn't a post about static vs dynamic typing as I said right at the top. It's a post about the effect of static typing on software quality.
Code completion tools originally came out of Smalltalk. It's relatively doable if you can attach to a running process that has dynamic access to your code.
So that's "not necessary". It's also not sufficient: Most statically typed languages simply don't have this sort of tooling because it's very hard to write, and advanced type systems make it even harder.
Ditto most statically typed languages.
> The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one.
It doesn't, but the fact that there's nearly as much variation within statically typed languages in terms of how difficult this is to do as there is between statically and dynamically typed languages does. And this only gets worse as we move to the sort of languages that the static-types-for-correctness people advocate for.
I really don't buy this. Yes different languages present different degrees of difficulty, but the ceiling is much lower for dynamic languages compared to static ones. In dynamic languages, there are absolutely (very common) situations where types cannot be accurately inferred (or inferred at all). If I write
def f(x, a): return x[a]
The reason why not every static language has great tool support is more to do with A) if the compiler was designed with hooks/apis for tools to use (like clang and rust do), and B) if the language has enough popularity for anyone to bother. I'm pretty sure if you take two languages of relatively equal popularity, and compare the dynamic one to the static one, the static one almost always has better IDE/tool support. For instance, lets take Swift vs Ruby (they're next to each other on the Tiobe index). I've yet to see a Ruby IDE that is much of an improvement on a text editor, whereas Swift is pretty young and already has tooling comparable to much more mature languages.
The compiler will errr if x isn't indexable, or if it is but not by the type of a, in terms of your function's names.
For my own Objective-Smalltalk, I added code-completion to both the REPL and a few IDEs fairly trivially.
I've never worked with Ruby, but I do work with (and mostly enjoy) Swift. The one thing I really don't like about Swift is that the currently available tooling (both AppCode and Xcode) is extremely primitive compared to what I am used to from Common Lisp and Clojure.
This pre-supposes that you don't have a test to run the program, because if you do you can just embed an interpreter in it and you have access to everything - tab completion included.
IMO This approach is partly what made IPython notebooks so spectacularly successful, and the future of dynamic language programming will look something like that.
Haskell people excepted.
Refactoring Browser: Smalltalk.
Eclipse: used to be VisualAge for Java (written in Smalltalk), split off from VisualAge for Smalltalk.
In my REPL/IDEs with Objective-Smalltalk, I most certainly have code completion, which wasn't hard to implement at all.
You should get out more ;-)
> Java's compile times are sorta reasonable but are apparently getting worse.
I'm not entirely sure what this is about. Could it have anything to do with JEP 215? [1] There were some slowdowns in `javac` in Java 8, but these should be fixed in Java 9. Note this has more to do with type inference than with Java's type system per se, though this distinction is of little difference to most Java programmers.
In our experience with OpenJDK builds, the main performance issues have been around redundant loading/parsing of library class files and JVM/JIT warmup time. These have mostly been mitigated by JEP 199. [2] With the exception of the issues I mentioned above, it's hard for me to see that static typing has had an impact on the performance of Java compilation.
(Overall I agree with the main thrust of the article, particularly with regard to the "set of complicated trade-offs." Personally I find static typing very helpful, but it won't solve software quality problems.)
This is the meat of the entire argument, and it's false, as you can verify by running ghc with the -fno-code option. Type checking is extremely fast. It's everything else that's slow and that has absolutely nothing to do with static typing.
class Tuple<T1, T2>
{
public Tuple(T1 t1, T2 t2) { }
public T1 Item1 => default(T1); // null for reference-types
public T2 Item2 => default(T2); // null for reference-types
}
I would love to see tests at the interface level (or typeclass level for Haskellers) rather than the implementation level, to enforce that all implementations of an interface satisfy laws like this. In Haskell, this would mean that you could enforce things like monadic laws which we all assume to be true anyway.
Side note: you seem to be replying to all of my comments, are you following me? :P
Checking in occasionally - you've been steadily posting things worth replying to :)
1) Behavior needs to be automatically checked 2) To check behavior, you can either write tests or specify types 3) Tests are more flexible than the type systems of popular languages (e.g. to write end-to-end tests) 4) Testing purely dynamic languages is quicker than compiling statically typed code 5) So prefer tests to type systems because agility
Honestly this is a load of bollocks and I'll explain why:
* When business execs throw out the old UI (old end-to-end tests) and replace it with a new UI (new end-to-end tests) and your new tests are failing because undefined, well, have fun and good luck! * The longer a system lives, the longer the test suite gets. So no, your developers are not going to be running the entire test suite at their desks, even if at the beginning of that project, running that test suite took all of half of a second. This is one of the reasons for continuous integration servers, actually, so that the massive test suite can be parallelized across a bunch of build slaves and run overnight while the programmer is at home or working on a different feature/problem. And then the difference in compile and start-up times is psychologically irrelevant because the programmer will still think "ok, I submitted the build to CI, time to go home/work on something else". * Good type systems, combined with proper IDE support and proper object-oriented design, do optimize for deletion by reducing the number of places in a codebase in which refactoring has an impact. It is incorrect to state that type refactoring should be some kind of massive refactoring affecting every file in the codebase every time you refactor. A refactor should either eliminate a given subtype, thus leaving the other subtypes unaffected, or add a subtype, where no-longer-common code/behavior can be factored into a new intermediate type. When the supertype needs to be changed, well, you still need to test those changes, but at least you only needed to make the change in one place, and not an indeterminate number of copy/pasted places in dynamically typed code which, you know, good luck finding them all.
Static typing is a practical requirement for long-lived, large systems. OP makes way too many assumptions on the basis of small, short-lived projects.
Also, this makes me think about incorporating testing directly into the language, which kind of brings us to Design By Contract and formal methods. It seems to me that now would be a good time to resume active research on those things, instead of all these exhortations to use magic type systems and magic immutability and so on.
I would disagree. In very large projects, strong types don't scale very well across repositories / deployable units.
A very large single repository, it may be ok. Except that refactoring types will like break a lot of in-flight pull requests and branches.