Hacker News Reader

Comment by TooCreative | Hacker News Reader

I code without types. My "proof", that types do not pay for themselves goes like this:

Every time I encounter a bug (during coding, testing or in production) I make a note what type of bug it was and how it could have been prevented.

Types are way down on the list of what could have prevented the bug. Especially for production bugs, which are the most important of course. It is so rare, that a bug could have prevented by types that I can say with confidence that they would have been a net negative.

Talking about which tool can prevent the most bugs, integration tests win by a large margin.

The reason is that most bugs are conceptual. Like "Oh shit! We have allowed people to tag items as duplicates of other items. And we have a function that traverses the list up to the original item. But now this new feature over there had a bug where it marks the last original as a duplicate of another duplicate and then when the traversal function in that other module is used, it ends up in an infinite loop".

Another example of a popular bug category: The code contains assumptions about the environment that do not hold true. For example PHP's mb_strtolower() will not always create the same string as MySQL's LOWER(). It is very rare and only holds true for a tiny tiny fraction of the UTF-8 characters. So you might expect them to behave the same until you one day trip over one of those few chars.

View on HN

I think it takes people who do not start out 'believing in types' (I was taught by pupils of dijkstra in NL so my belief in strict-as-possible has always been quite firm) a same kind of timespan / experience as the OP; experience (very) large weak/stringy typed projects, experience them for at least a few years full time and then, when the frustration sets in, try something which is the complete opposite like Haskell/Rust.

I think a certain frustration needs to be there to try something else anyway, when you come against the billionth cannot call hello() on undefined error in a critical (for the company), 100k+ LoC, multi-team project, you might wonder if there is something else.

You are probably not going to post your 'list' here but proper types prevent many trivial and non trivial bugs. Many of the points on your list will fit there, but you wouldn't know it yet.

> Talking about which tool can prevent the most bugs, integration tests win by a large margin.

Obviously there are ways of catching them without types, but proper type systems catch them at compile time and also; how are these mutually exclusive; we use both. We just need less integration tests.

> Like "Ooooooh shit! We have allowed people to tag items as duplicates of other items. And we have a function that traverses the list up to the original item. But now this new feature over there had a bug where it marks the last original as a duplicate of another duplicate and then when the traversal function in that other module is used, it ends up in an infinite loop".

In some of my favorite languages you can catch this in types at compile time.

Obviously; do what works best for you and your team; I just don't buy your overarching statements and 'proofs'. If it works it works, but it would probably work better with types.

Working on a large scala codebase, I quickly learnt that 'compile time' in one language does not always happen before 'run time' in another language.

What matters is not the phase in which the bug is found but how close in absolute time finding the big is to writing it.

Agreed and we have to continue improving in every way; dynamic/static/hybrid, just saying that I have not seen this dynamic enlightenment in larger projects. I have only seen the pain of runtime errors that other (static language) teams never had. Sure, if you would-have-written a test for it, you wouldn't have had it either, but types rather force you to think about it while writing. So sure, you are 'done faster', but the fall-out, and again ofcourse YMMV, of having statically preventable bugs popping up in Sentry at 3 am in the morning with things you would've prevented (not necessarily directly by the types but you would've thought about it more because you had to define the types, which is I think what the parent poster here misses too; I just tend to think less and try more without types which, again for me, is a bad state, but ymmv) is not great.

But sure, I am biased as my experience with statically typed langs has been good since I moved from asm/basic in the 80s to pascal/c (they were an improvement over asm/basic and my first experience with types, not saying you should use them now, or not).

The view I've heard expressed is that deep thought on a piece of code reduces bugs. Whether that takes the shape of religious TDD, rigorous proofs or detailed type design doesn't make such a lot of difference.

I used to be fully bought into types, but I've since realised that they have a number of downsides that in many cases more than offset their benefits:

1. Ergonomic typesystems require a lot of work to happen at compile time and slow down the iteration time (one of the more important things for programming in my view). In my view, saving the source and seeing the result almost immediately in a browser is one of the big advantages of web development.

2. Types are almost always written in a second, much less powerful DSL and then sprinkled distractingly through the code that actually does the work. I prefer the way Haskell does this- separate the type signature out onto at least a separate line rather than mashing the two different languages together.

3. Higher levels of abstraction tend to become very hairy in many type systems (although not all). This ends up just meaning that people who like types often restrict themselves (unconciously) to less abstract programming. They spot the time they're saving by avoiding some kinds of bugs, but they don't see the time they're wasting by being unable to talk at a higher level of abstraction. Another way this shows itself is that types are very rarely first class objects in strongly typed languages, making it very difficult to create code that operates on types, or understands types.

4. Type systems open up opportunities for type driven architecture astronauting, which is just yet another way you can go down an unproductive rabbit hole. There was an interesting study done on different teams solving problems with different languages. The differences of different teams within the same language was much bigger than between languages, but the team that made slowest progress (and without particularly having an unusually low number of bugs) was the team that leant the hardest into encoding everything in the type system.

5. Type systems encourage code generation build pipelines, which again slows iteration time and makes everyones life miserable.

6. Type systems reflect a incorrect model of the world - user input, network input, file system data is not typed. The misery that I've had with some web server frameworks that refuse to acknowlege that they don't know every possible thing that the web client might send them and are able to slot it into a predefined type. I think this is the same kind of error that we made with OO systems - thinking that we could fit the world into a predefined inheritance hierarchy.

7. Type systems encourage a static view of the world. The types of things can change under you, dynamically, (e.g. the structure of a table in a database), but in most typed languages you can't cope with that correctly without shutting down and deploying entirely new code.

8. Related to that, it's hard to imagine using a strongly typed language with the live image approach of smalltalk or sometimes used by lisp systems. This means that the popuarity of strongly typed languages is killing valuable and interesting approaches to building complex systems that emphasise observability, interaction and iteration as a way of understanding them.

There are genuine advantages to typed languages, but many of the advantages touted as being unique to typed languages can be provided by advanced linting and IDEs (intellij was surprisingly capable on plain JS + jsdoc). You can also ameliorate some of the disadvantages of untyped languages while keeping the benefits by deliberately programming in a fail-fast way.

I'm sure that type systems have their place. The research I've come across on empirical studies suggests that while there may be positive effects they are small, which does not at all mesh with the extreme partisanship I generally observe. Yes, type systems gain you something, but there seems much less awareness of what you lose.

I am positive about a lot of these points for the future. Especially the performance points; that's going forward fast. But yes, that's often pretty slow; not that bothered by it for my work though. Also, linters work well for statically typed languages too; I usually don't have to compile for 100s of lines of code. If the editor does not complain, it'll probably all work fine. Like I said; do what works for you , but I think at least a good mix will get more benefits.

6. People mention this more often, but I just don't see how that works; you cannot program without knowing what data you are getting. Sure the world is not typed, but at the moment you are going to use the data, it is typed; be it in your logic, head or actual types. Any webserver can go lower level and give you a ByteStream, but when you finish parsing that, you still have types. You might not know them upfront, so you use ByteStream for a bit, but once you know, you bake types and the world is nicer. Imho :) Not sure why that's a difference?

7. This is an issue where? I know it's Erlang domain, but microservices/docker/k8s/ci/cd/lambda/functions/.../all modern crap do this (redeploy, killing the previous instance(s)) with any code, always, including dynamically typed code. So sounds like a niche?

8. Agree with this; we should experiment and research these things and continue building them. I work with Lisp/Clojure as well and like it, I just miss types often. I never suggested it's all crap; I'm just looking where benefit comes from.

A good post on point six: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

> you cannot program without knowing what data you are getting

Types almost always overconstrain. Each part of your code relies on some very specific properties of your data, yet most type systems end up restricting your function to only work with data that meets a whole bunch of other properties that your code doesn't actually care about.

> Types almost always overconstrain

Not in my experience; so many, basically, stringy types.

> Each part of your code relies on some very specific properties of your data,

So then you either have a type that exposes those you need or you have different types for different functions.

> yet most type systems end up restricting your function to only work

Again, I don't understand this statement; someone implemented the types to fit the data for some functions they needed. How does the 'type system restrict' anything?

There's a lot of things, some about old-school types (Java, C), other about modern ones. I don't think most are fundamental, even though some are common experiences today.

#1 is fundamental. (Yet people somehow live with the JS ecosystem that's slower than GHCi.) It's supposed to evolve into always becoming a smaller problem, since computers are always getting faster; but I don't think we've put everything we can into types already, so I expect it to get worse in the near future.

#2 and #3 are about old-school types.

#4 Oh, yeah, they can. But they can also help a lot in team coordination. Powerful stuff enable you either way, if you harm yourself or take advantage of it is your choice.

#5 Failures in type systems encourage code generation. Expect that to always improve, but always slowly.

#6 That's why there's always a parsing stage between input and processing. You deal with input errors at the parsing stage, and processing errors at the processing stage. Most communities of dynamic and old-school languages make a large disservice to the industry by mixing those; they explode error handling into something intractably complex.

#7 Hum... You are holding it wrong. Do not state variants into your types. Instead, use the type system to get every invariant out of the way, so the variants stand clear. (And yeah, there are plenty of libraries and frameworks out there that try to encode the environment into types. That deeply annoys me... But anyway, if you do that, take the types as requirements upon the environment, not its description. Those are different in very subtle ways.)

#8 This shouldn't be fundamental. AFAIK there are not many people trying this, and the few there face a Sisyphean task of keeping their code up to date with the mainstream changes. I do hope people make progress here, but I'm not optimistic.

> Yet people somehow live with the JS ecosystem that's slower than GHCi.

I think a lot of people, including the parent, seem to equate speed of ecosystem and iteration with web development and instant reload of web pages. When other systems allow fast iteration, it goes unnoticed unless it's for web dev. Luckily, a bunch of those 'impossible' systems have to now too, like [0].

[0] https://ihp.digitallyinduced.com/blog/2020-08-10-ihp-live-re...

Web development is an example. Fast iteration is the thing that I like. I have so far associated fast iteration with dynamic languages, and it is certainly the case that my experience is that most fast iteration systems are dynamic.

But maybe that simply reflects a concern of the relevant communities. If strongly typed language systems start adding fast iteration approaches to things and are able to achieve a similar level of quick iteration then that will definitely address one of the things I dislike about them. I haven't coded significant amounts of haskell since 2000, but back then what you could do interactively was very restricted.

At the end of the day, the compiler is doing a bunch more stuff in strongly typed languages. It's like taking a bunch of your verification infrastructure and saying 'these must run before you're allowed to see the result of what you wrote'. It will necessarily be slower, although with work maybe it won't be so much slower that it matters.

> Fast iteration is the thing that I like

> haskell since 2000,

Things changed a lot in 20 years.

Thanks for noting down something about your age; I have always been a bit ageist about 'fast iteration' as I never met someone close to my age (been devving professionally for 30 years this year) that cares too much about it. I am not a very good programmer, but a very experienced one and i'm consistently faster at delivering than my 'fast iterating younger peers' as I simply know what i'm going to type beforehand, I don't need too many iterations to get it right and I have enough experience to know that i'm close to what we need after it compiles. The people who just type/run 1000 times/minute get stuff done, but it's not the way I would ever like (or liked) to work.

> It will necessarily be slower,

GHCi is fast but other avenues can be explored as well, like creating a real interpreter just for development , like Miri for Rust. Only for faster iteration of logic, you forgo some of the type benefits, but when you are done iterating, you compile and voila. I guess the merging of incremental compilation, jits, interpreters etc will evolve in something that might not run optimally but gives blazingly fast iteration up to perfect performance after deployment. And anything in between.

> #2 and #3 are about old-school types.

There absolutely are approaches to this that don't fall foul of my complaints, but when you say 'old-school types' I think you're talking about Java and non inferred types.

I was including other more modern languages in my criticism. Scala for example ends up with pretty hairy types very quickly for higher level code. So much so that they made the documentation system lie about the types to make it easier to understand.

And most currently popular languages don't give you runtime access to types and allow you to treat them as first class.

The languages that allow you to deal with types with the same language you write code in are not remotely mainstream. So unless by 'old school' you include all mainstream languages then I disagree.

Yes, I meant types systems like Java's.

I was thinking about unusable code, caused by the need to write way more down in brittle types than anything you save on coding. In fact there are problems with complex types.

It's interesting that you talk about bugs, when the OP doesn't make that argument. The OP is very clear, actually:

> It didn't mean I was free from logic bugs. (Nothing can do that in the general case!) It did mean that a program which type-checked wouldn't blow up in ways the type-checker said it shouldn't, though.

Other than soundness (which is not the same as avoiding logic bugs, anyway), the points the OP raises are about expressiveness. Types help [you / the OP] organize more of your knowledge in the codebase. That's never going to be the most obvious preventative measure against bugs, because the goal is higher-order: structuring your codebase so you can reason more clearly about the program.

That might be a matter of personal taste. How ones brain is wired. For me, types make code less expressive. I can grasp the structure of a piece of code the easier, the less meta data there is on top of the algorithmic structure.

What are you working on though? What algorithmic structure?

Compare this:

    private static function request(?string $method, ?string $url, array $options): array
    {
        ...
    }

To this:

    function request($method, $url, $options)
    {
        ...
    }

I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have such a good grasp on it as with the former.

Counter point: with the former, I know exactly how to use it: for item in request(“get”, “google.com”, []) { .... } Whereas if there’s no example for the latter, I’d have to read the code of that function (or sometime the code of the functions it called) to know how to use correctly.

Wishful thinking.

You know it returns an array, but you don't know what the array contains. So you don't know how to use it.

You still need to look into the code to see what it returns. Then you will see that it returns an array and what the array contains.

And now you had to process the information that it returns an array twice. Once in the function definition and once in the function body.

> You know it returns an array, but you don't know what the array contains. So you don't know how to use it.

That's a limitation of your specific example, not type systems in general.

For the example I took a random line from Symfony and shortened it a bit:

https://github.com/symfony/http-client/blob/master/HttpClien...

You are free to link to some other example.

Any example where the type is defined as something more specific than an array (especially in PHP, where the `array` type doesn't even differentiate between numerically indexed arrays and dictionaries).

Regardless, I still think the type hints in Symfony's version are better than nothing. It's also worth noting that `private static` is concerned with scope, not types.

Most type systems also provide information about what’s in the array, like Array<String> or int[]

That is just another piece of metadata. But it does not help either. Now you know you get an array of strings. But you still don't know what is inside of the strings.

It might be ['headers'=>'...','body'=>'...' ] or ['status'=>'...','response'=>'...'] or god knows what.

And you are back to reading the function body.

Is that like a hashed array you’re implying? In that case, the type wouldn’t be string anyway, but something like HashMap, Object, Dict, etc. More commonly though, something like HTTP options would be its own type, with defined properties, which you could browse via autocomplete or your IDE’s hover/peek functionality. That type would then specify the types of its values, so you can be certain that options.status is an integer, for example.

You’d generally only use an otherwise untyped array of strings when you can’t know beforehand what their values can be.

Heck, not only I don't have to look at the code, with proper IDE setup, I even don't have to go to the documentation page, just `item.` and my IDE/editor will present me with the list of things that are applicable to my item.

And that's only the response part of the usage, there's absolutely no way for me to know if the method is an enum/constant or is it a string without looking into the code for dynamic typing, and again, sometime N-level deep to get enough information of "what to pass to this function so it will work".

You're showing an example of a function signature in a specific language, not an example of typing though. These are related but not exactly the same.

For example here is a Ruby version, very dynamic:

    def request(method, url, **options)
    end
    request("get", "http...", foo: "bar")

And here is a completely statically typed Crystal version:

    def request(method, url, **options)
    end
    request("get", "http...", foo: "bar")

The argument types are inferred automatically from the usage and mismatched usage will be caught at compile time. And in the second case the ide can still tell you the types in the signature if you want to know them.

In the third example, here's completely dynamic python:

    def request(method: str, url: str, **options): Dict[...]

No type checking happens here in the language itself.

So what I'm getting at is - if you don't like languages with verbose explicit type signatures, it doesn't mean you don't like static types.

Nitpick: It's -> Dict[...]. Colons begin a function body.

Got that, but was triggered by ‘algorithmic structure’; that sounds a tad ‘over the top’ when you then come with some basic web request.

However, I would not call your example particularly well typed. Array is still basically untyped.

When I talk about types I mean things like;

     Either<Error,Group> AddGroup(string GroupName, User[]? users)

In this case I know what I am getting and I know the users are already, when reaching the webserver, deserialized, validated (or the type would reject them and produce an error and I know I am getting an actual Group back.

in your case that would be;

      function AddGroup(GroupName, Users)

I have no idea how that is better or clearer or less work to write? No idea what it returns; Users probably is an array of users, but is it? Or is it a typo? And I need to validate whatever comes in.

You can add docs but I do that still with the typed version (although thats automated mostly unless I need to explain something).

Worse as well is that when I have this:

      function AddGroup(GroupName, Users)
      function AddGroups(GroupNames, Users)

Now i'm completely lost. I'm not even sure these users as input are the same things? Both arrays? Both the same User 'things'? Output?

But yes, in php I write typeless mostly too (although I luckily do not have to touch it much anymore) as the types mostly suck. But in more advanced type systems, the types will tell you a lot/all about the input/output, so you can do without a lot of docs and trying things out can be automated; as we know the precise input so some generator can generate example input that will immediately work; like swagger on speed.

Etc. But agreed, your example does not benefit too much from typing, however I would define Option[] as something precise than just a void* and hope for the best. Also Method and URL so I know invalid input for those very well defined things cannot be violated.

So your example:

    private static function request(Method $method, URL $url, Option[]? $options): WebResult

would clear up a lot for me. Now, for instance, I can see, and not guess, that you are answering a web request instead of some request with confusingly similar names to webrequests.

But how about some more 'concrete' examples; 'request' is rather a low level / abstract thing (I hope...). But your business logic would contain more concrete functions; any examples from those that are similarly badly geared to types?

And now instead of

    $body = Http::request('GET', 'https://example.com')['body'];

You have to do this?

    $body = Http::request(new Method('GET'), new URL('https://example.com'))->body;

And you have cuttered the global namespace with "Method", "URL" and "Option"?

Why would they be in the global namespace? They would be in imported namespaces (something\Http for instance). That's rather normal.

And yes, now you have to make sure you are passing the proper and valid types, which is obviously the goal here:

    $body = Http::request(Method.GET, URL.Parse('https://example.com'))->body;

In other languages you can make it so that the static URL is validated at compile time even.

For that to work, you have to import those explicitly:

    use something\Http;
    use something\Http\Method;
    use something\Http\URL;
    $body = Http::request(Method.GET, URL.Parse('https://example.com'))->body;

Now you have a bunch of lines instead of one. And have "Method" and "URL" in your current scope.

And all of that instead of this beauty:

    $body = Http:request('GET', 'https://example.com')['body'];

Beauty is in the eye of the beholder, however we were not talking about verboseness vs terseness though.

You can make anything terse with stringy types and you indeed seem to favour that, however, this was about how types change readability and brittleness. This is all easier to read by people who do not know what request() does => request is not a good example, but it still stands. In your case, you have no case what $method or $url are supposed to be; you can do;

    $body = Http:request('rabbit', 'cracker')['body'];

I assume something in Symfony catches that, but I cannot see it from the signature at all, and the validation error is, in my opinion (obviously) in the wrong place; it should be at the call site because that's where you are creating the erroneous input so that's where I want to be lead to.

A better example for a typed function would be something like:

    function Request(string method, string url, RequestOptions options) : Result {...}

    Result Request(string method, string url, RequestOptions options) {...}

Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might suggest even making `method` an enumeration.

If the function name was better, you could call that function right now without needing any more information.

Also, especially if you're a fan of defensive programming, most of the basic argument checking is performed at compile time, leaving the function body cleaner.

Based on your example alone, perhaps you don't have enough experience with typed languages to appreciate the benefits. I don't mean that in a belittling way, but more of an invitation to learn more about the craft.

For the example I simply took to a random, recently updated file from Symfony:

https://github.com/symfony/http-client/blob/master/HttpClien...

And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.

Well, for me it's easier - perhaps because I'm used to reading parameters in type+name pairs.

The data type is right next to the parameter name - and it will be in the pop-up provided by my IDE when I use the function... I don't need to look at the docs or comment (which may not exist).

you could possible write an IDE plugin that hides the types information and only show them on hover etc. I don't think this reason is that strong of a point IMHO.

I moved (very roughly) from Java to Python to Haskell. When I was coding in Python if you asked me what percentage of bugs I encountered could have been caught by types, I would've probably said about 10%. Because I would've been thinking about types in Java and errors like calling "length" or a string and then accidentally calling "length" again on that int value from the previous call to length.

Now that I am working primarily in Haskell if you ask me the same question I would say probably about 90%. Not only does catching the "calling length on an int" types of errors at compile time but it gives you whole new tools (newtypes, Sum types, mtl-style constraints) for expressing complex concepts in a simple manner in the type system.

And all of these tools result in having to spend much less time thinking about things I had to think about in python, leaving me to spend more time thinking about the business logic which reduces the number of logical errors (which obviously can still occur).

As a concrete example I transliterated some Python code that someone was asking about on reddit into Haskell here: https://gist.github.com/lgastako/f7465339214c6fde0fd75f4e488...

You can see on line 57 "unless (status == Fresh) $ do" -- I originally wrote checkStatus as a function that returned a boolean and the expression was "unless fresh $ do" but I replaced the boolean with a tri-valued sum type and rewrote the check against the value "Fresh" -- this avoids the boolean blindness problem and makes it much harder to get the condition wrong -- and while it's still possible to get the condition wrong, it's much easier to find it when you do.

I find the value of static typing to be more from increasing the ease of exploration and understanding of a codebase than preventing bugs directly. The constraints on how the code you're reading could be being used making building a mental model faster. Not to mention the tooling built on top of the typing that can help with exploration.

> increasing the ease of exploration and understanding of a codebase

Very true and a good thing to remember when discussing static typing.

Can't be beat for refactoring. In languages I can trust the compiler, I can refactor fearlessly

Maybe your style is not fit for types?

So I fixed a bug recently where a url validatior code was falling because the code was old and recently what is allowed in an url changed. Imagine there was a language where url/email/file path was a type that could validate itself when you create it and you don't need to always try to create regex to validate things. Even more cool would be if string would not be something we use daily (like we don't use every day bytes) so we would have always a type for customer name, file name or file path and you would need to explicitly ask a conversion from a customer name to a file name etc. The way I think future languages and types could help is to make it almost impossible co create invalid data structures or state.

It's not just about preventing bugs. Types restrict what you can do with each variable, such as what methods/members exist on the variable and what valid operations you can do with it. It makes development easier because you don't have to hold it all in your head. Every member/method access is validated at compile time, without needing to write any tests.

You may not make such mistakes when writing dynamically typed code, but if you ever need to change something (like the name or type of a variable/method/member) it inevitably means trawling through all references in your codebase manually and changing them by hand. Please correct me if there's a better way to do it in dynamically typed languages.

Given that you don't code with types, how are you certain which bugs you could have prevented?

I'd be curious to see this list. Is it anecdote, anecdata, or is it a spreadsheet you have somewhere?

I have the feeling you are applying your experience from coding your own project.

And not from a project in a team, where you didn't code everything.

IMO types in Python mostly pay for themselves when you develop in a team.

They greatly improve the developer experience by providing automatically enforced documentation. Allows IDEs to provide code completions etc.

Can you share the tally? I wonder about the categories you used.

Reply on news.ycombinator.com