Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

51–60 of 468 posts

Re: Things I Was Wrong About: Types

#51

I don't really see most of my code being improved that much by types and I also see a lot of extra complexity that people in the sphere I am (indie games) have to deal with when using typed languages. It just doesn't seem worth it. When you have to spend a lot of time fighting your language, and handling numerous extra concepts that don't exist in an untyped language because they don't need to, it feels like the peop…

Statically typed languages (or at least the good ones) are disciplined so the programmer doesn't have to.

If you can work reliably with dynamic typing, that means you are very disciplined about giving the right data to the right function, in exactly the right form. That you are very disciplined about tests, possibly including fairly stupid-looking unit tests (which aren't actually stupid, at least in a dynamic context). Adding static typing on top of that wouldn't help much of course.

When I write something from scratch however, I found that static typing actually speeds up my development. It's less work, not more. Because I don't have to write as many tests, or even worry about huge classes of errors — the compiler (and if I'm lucky, my editor/IDE) just checks them for me.

I don't know the work you do, but I bet that your style could benefit from some static checks. Perhaps not the mainstream ones, but your scripts work somehow, don't they? That mean they respect a number of invariants, some of which could certainly be checked at compile time, saving you significant time on stupid bugs. The result won't be TypeScript or Rust, but I don't think it would be fully dynamically typed either.

Re: Things I Was Wrong About: Types

#52

Earlier quoted context omitted.

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…

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).

Re: Things I Was Wrong About: Types

#53
post #38

The benefits of types is not something to be discovered, but something that's taught in school with very convincing arguments, if not too much zeal. It's interesting to see this kind of post. Not to be sarcastic about the late discovery of typed goodness, but the fact that this is not already a concensus in the engineering world.

It’s not a consensus because many of us have found that types are not the panacea we were taught. Erlang is a fantastic language, and it’s arguable that types would not improve it, but rather hinder some of its better features. Same is true for Smalltalk and various lisps. I think there’s a place for various approaches to types.

Re: Things I Was Wrong About: Types

#54

I was a statically typed fanboy for most of my early career. C# and later F# were my daily drivers and still hold a fond place in my heart. More recently, I learned TypeScript and a bit of Haskell and Rust. However, I think dynamic languages have their place. Most of my server side code involves parsing one string and transforming it into another (JSON to SQL or the like). Something like Clojure spec is really, reall…

How about a language that supports both strong typed data type and dynamic data types? Not sure about other language, but Free Pascal and Delphi support both of them.

Re: Things I Was Wrong About: Types

#55

I don't really see most of my code being improved that much by types and I also see a lot of extra complexity that people in the sphere I am (indie games) have to deal with when using typed languages. It just doesn't seem worth it. When you have to spend a lot of time fighting your language, and handling numerous extra concepts that don't exist in an untyped language because they don't need to, it feels like the peop…

I think it depends on size or codebase, how many people are working on things and how long you can afford to develop before releasing.

I do mostly work with python and JS, but last Christmas I learned Rust, and it strongly occurred to me that exhaustive matching, no nulls, borrow checking and strong type inference would be a real boost to development given the initial time to build the codebase up. I'd put money on them removing hours of hunting subtle bugs, and on missing the ramifications of refactors.

I built some small scale game stuff using SDL2 for Advent of Code and I enjoyed rust for doing that a lot.

I think also dynamic languages work best when developers actually are knowledgeable about the underlying types and effectively write code in a typed manner anyway. It's a much worse trade-off when function signatures actually avail of loose typing to do strange things.

Re: Things I Was Wrong About: Types

#56
post #25

For me it is somewhat different: I always used typed languages and occasionally have to read and improve untyped code. I must admit, I feel half blind in the latter. When debugging a python web service, trying to figure out the control or data flow, I very often scratch my head and wonder "what is this thing"? This applies both to library functions and code from colleagues. Sometimes it feels like untyped languages a…

This is my biggest gripe, too. Discipline about commenting helps, but only so much.

In my case, I have Clojure spec or the JavaScript equivalents at the important boundaries in my code. That makes this issue much less painful and also solves a few other issues to boot.

To be honest, in more advanced type systems, I’d ask: “What is this” only to be shown a convoluted type signature. I then put a println or breakpoint in there just like I would with a dynamic language and poked around.

Re: Things I Was Wrong About: Types

#57

To play against the current wave, and give a contrarian pov: I'm grown up with statically typed languages from C/C++/C#/Java and later and didn't know about dynamic languages till recently. 1. Which types are we talking about? - In earlier static-typed language, the processor-based types `uint64` looked very strict, optimized the code for hardware architecture. - Having mathematically and ontological correct types is…

Dynamic languages don't do away with such types, especially uint/float, etc. They just hide it away from you. The only thing it gives you is false confidence, where one day you end up doing operations on two floats because your untyped function is supposed to get numbers in, and you're left with 36.99999999999994$ on your bank account because it wasn't explicit. So, you write unit tests to make sure that you only pas…

In Python you'd usually use a `Decimal` for money and it would give you an error if you tried to mix it with floats, not silently throw away information (which I certainly agree would be a dire consequence).

In JavaScript, good luck for now, but a solution is being rolled out: [https://caniuse.com/bigint].

Re: Things I Was Wrong About: Types

#58

Having started out with Pascal and C, I thought I hated statically typed languages as well until I got exposed to SML and Miranda. I guess Rust or Swift have the same enlightening impact to people coming from Java or Go and I'm glad such approach is finally hitting the spotlight, even if a bit hampered. That being said, and as much as I see the appeal on those and hoped that stuff like ATS or SPARK were more prevalen…

Yeah the article is just "hey, I discovered SML!". I've been using SML, Haskell, then OCaml since the early 90s and the benefits of (proper) types and type inference have always been obvious.

Re: Things I Was Wrong About: Types

#59
A good static type system is better than dynamic typing. But, dynamic typing is better than a bad static type system.

A bad static type system will slow you down, forcing you to appease its irrelevant complaints, and pervert your code into a form that no sane programmer would choose to write it in, if it weren't for the type system looking over their shoulder. I won't mention any names, but suffice to say such languages exist.

On the other hand, a good type system recognises that its goal is to allow the programmer to write code first in the form that makes sense to them, and then be expressive enough to describe it.

Re: Things I Was Wrong About: Types

#60
People often think about coding, but that's generally a small piece of it.

Typing is a form of structure, and especially a kind of documentation.

When encountering APIs of various kinds 'typing' is part of how they are expressed.

It's hard to build large monoliths without typing.

When working with 'wide scope' problems, when the typing is more oriented towards the data, that's another thing altogether, which is why I think for many systems untyped JS and Python works well enough there.

What most typed systems lack is a fluent way of mapping to 'data types' which are often external to the system, or at least externally defined.

Post reply on HN