Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

Post reply on HN
Print view View original

211–220 of 468 posts

Re: Things I Was Wrong About: Types

#211

Post by lgas »

TooCreative wrote: post #4

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 prevente…

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.

Re: Things I Was Wrong About: Types

#212

Post by billisonline »

deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on

With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

Re: Things I Was Wrong About: Types

#213

Post by castwide »

TooCreative wrote: post #155
castwide wrote: post #94

Earlier quoted context omitted.

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

Re: Things I Was Wrong About: Types

#214

Post by dilawar »

arvinsim wrote: post #208
bo1024 wrote: post #199

Earlier quoted context omitted.

This kills me about python. So many times I cannot figure out what exactly a functions expects and what it returns, sometimes even from reading the documentation! Matplotlib is especially bad.

Didn't Python 3.5 introduce optional typings?

Only annotations which can be checked by mypy or other linters. I think cpython doesn't check them at runtime.

Re: Things I Was Wrong About: Types

#215

Post by dnautics »

NicoJuicy wrote: post #16
echelon wrote: post #3

I followed a similar trajectory. Types were the bane of my early career. Hideous, extraneous. But really, they're the light at the end of the tunnel once you've worked your way though the dynamic / weak typing minefield. It took me a lot of Python, Javascript, and Ruby for me to get there, but now I'm way more comfortable on the other side. The correct type system is actually way more expressive than not having stron…

The incoherent thinking I see with some people even in typed systems, would make me very scared to let them do the same in dynamic ones.

I mean there's also an argument that those people don't stay in dynamic systems for very long.

Re: Things I Was Wrong About: Types

#216

Post by mamcx »

pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

> I started off in PHP. It was wild.

Help a lot to start with something SO wrong :)

My first dynamic language was python, and the quality of the docs and overall apis of major libraries soft the landing.

But later I note that was parts of MY code that become a mess. The problem of delay of good design? is that good design GETS delayed.

And then fix that later is a problem. Major libraries and core APIs have the time frame and focus to polish them, but the rest of the code most do?, not much, so it stay in the awkward phase of "later will be refactored, maybe. Perhaps..."

Then later I move to F# and rust and can't delay bad design for long.

Is a chore to slow down at the start of the coding phase but later the speed up is huge: i don't need to fix my past mistakes by the truckloads...

Re: Things I Was Wrong About: Types

#217

Post by mamcx »

billisonline wrote: post #212
deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs.

With python, for example, I can't at first see what a function need but at least see the body give huge clues, because python rely less of abstract type stuff (it have a issue with monkey patching and delayed build of objects BUT, "if look like a duck.." is most of the time enough to get things..

Re: Things I Was Wrong About: Types

#218

Post by billisonline »

eru wrote: post #124
pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

Apropos PHP: I hate it with such as much passion as the next guy, but I am quite impressed with what Facebook managed to do with Hack! (Including adding lots of types.)

Don't forget, much of that effort has now trickled down into the PHP language itself. We've long had scalar types for function parameters and return values, but with 7.4 and 8.0 we've added union types[1], nullable types[2], and typed properties[3]. While not a part of the language yet, generics can be annotated with the linting tools PHPStan and Psalm[4], and native support for these annotations is coming to the next release of PhpStorm[5].

Using PhpStorm, I've worked with 100 kloc PHP codebases where almost every type was inspectable. And the language support and tooling are only getting better all the time.

1: https://stitcher.io/blog/new-in-php-8

2: https://www.php.net/manual/en/migration71.new-features.php

3: https://stitcher.io/blog/typed-properties-in-php-74

4: https://phpstan.org/blog/generics-in-php-using-phpdocs

5: https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psal...

Re: Things I Was Wrong About: Types

#219

Post by thurn »

rswail wrote: post #159

A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code. Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a s…

I agree with this for really large codebases, but I think you can get a surprising amount done before your program becomes "non-trivial" using a good dynamic language. For example, the website you are writing this comment on has been perfectly maintainable in lisp without any static typing for the past 15 years.

Re: Things I Was Wrong About: Types

#220

Post by deckard1 »

mannykannot wrote: post #166
jenscow wrote: post #125

Earlier quoted context omitted.

Personally, I prefer the type names to be at the start of the line, so I don't need to scan to the end of the line (or guess based on a function name). But I agree, it's a waste to type it all out. So I use an intelligent IDE that reduces the repetitive typing: So typing `Person.var` gives me `Person person = new Person();` or typing `Person person = ` will suggest `new Person()` Sure, it doesn't look as appealing wh…

I think you are making a good case for a somewhat different point: we have long reached the point where the tools we use for writing and reading programs can give us all sorts of semantic information on demand, and language syntax design should take advantage of the fact that everything the programmer needs to know need not be forced into just one flat page-of-text view of the code. Alan Kay made essentially this sug…

This has always been the case. Emacs could do all this decades ago. Genera/Lisp, Smalltalk, etc. to various degrees did this. And they all failed to make their case. Time after time. Hiding context has always been bad for understanding code. The same reason dynamic scoping went out of style the moment lexical scoping was invented. Or that GOTO is considered harmful. Or that we all prefer simple, small functions rather than multi-page monsters that do ten different things at once.
Post reply on HN