Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

251–260 of 468 posts

Re: Things I Was Wrong About: Types

#251

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…

I don't think dynamic typing will ever swing back. They came out of an era when types were expensive and had moderate benefit. Now they are cheap (in modern languages) and have significant benefits. There will always be things like shell scripts and stuff, but I don't expect to ever see a big language without a good typing story ever again.

The problem to solve now is to lower the costs more and raise the benefits, not to try to eliminate them.

Re: Things I Was Wrong About: Types

#252
post #225

Earlier quoted context omitted.

> 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

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be wr…

i tend to agree with you. maybe more than just agree. if any of these "IDE's", or "tools", or whatever they are called actually provided a universal improvement in software quality and development time, then i would change my view.

experienced developer, the tools don't make a difference. VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.

Re: Things I Was Wrong About: Types

#253
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?

Yes but hardly any code uses them yet. Hell there's still lots of code on Python 2 (yes really, no I'm not imagining it).

Re: Things I Was Wrong About: Types

#254

Off-topic writing feedback: use less italics. Readers are good at figuring which words are important on their own :)

Extremely fair. I go through phases where I over-emphasize all the things, and usually a second/edit pass helps clean it up. I actually went through and removed a ton of them from the post itself, just because of this very comment. ;)

Re: Things I Was Wrong About: Types

#255

Is 'Maybe Haskell', mentioned in the article, worth reading? Or can anyone recommend a similar book of the 'just enough to be dangerous' kind on Haskell or maybe Clojure?

'Maybe Haskell' is a fantastic intro to using types and why you might care about them. It's focused in scope and really meant to give you a taste of some functional ideas and a bit of Haskell, and in that effort it does a great job. Also, you can't beat the price ($0). If nothing else, probably worth browsing through to see if something resonates with you.

Obviously I’m partial because of my history with the book, but having read a bunch of other introductory Haskell materials, this one is still my favorite. It’s my favorite in part because it doesn’t try to teach you the whole language, it just gives you a taste of some of its powerful abstractions, walking through them with just the `Maybe` type. I read the whole thing on a plane flight, and reread it on the flight back.

Re: Things I Was Wrong About: Types

#256

I don't understand why he thinks Typescript still isn't worth it, when all of his points are issues in JavaScript that are solved by Typescript.

I think you misread the post! I very much like TypeScript, am a core contributor to the TS work in the Ember.js ecosystem, and am actively involved in efforts to make TS a first-class supported language in my day job!

Re: Things I Was Wrong About: Types

#257

Earlier quoted context omitted.

Even though I learned C/C++ in school, I started off my career with a typeless language, Perl. I loved it for its simplicity and power to quickly spool up working code, but realized it was problematic to use for large projects for many of the same reasons you state. I then switched to a Java project and was immediately frustrated with types because of how verbose it was, but after a while I came to appreciate just ho…

I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of…

Yea, I agree and for this reason when I teach type systems to new programming students, I tell them that a type is somewhat analogous to a building material. You have brick, wood, steel and iron. You want to build a house that has solid bedrock and has easy forest fires in the area. What material would you use? Most would say rock.

Then I tell them about strings and ints. You can represent 66 both with strings and ints, but one is usable for computation where the other one is simply usable to write Alice in Wonderland with it, or simpler forms of text. Sometimes I get the question then: why can't a string both be computational and as a means of character display? And then I list the upsides and downsides of such a system, just like the upsides and downsides of mixing brick and wood to build the outer wall of a house.

I'm curious if people can think of other analogies that they use for teaching.

Re: Things I Was Wrong About: Types

#258

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…

> Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing.

My complaint is the compiler doesn't know what is going on.

> In addition to that, you get the pain in the ass of having the compiler always complaining.

This cuts down on the time required for the programmer to decide whether to complain or not.

> I've worked with dozens of TypeScript developers and not a single one really knew what they were doing.

I'd hate for them to start committing code that can't at the least be checked by the compiler.

Re: Things I Was Wrong About: Types

#259
post #199
post #187

Earlier quoted context omitted.

> Understanding other people's code is at least half the job of a programmer This was one of the pain-points when I was working more with node.js: the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery. In very, very short scripts you can get away without types (like in a notebook for example), but once a project starts to get even medium size the tin…

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.

I use a Python debugger in VSCode and hit the necessary breakpoints to figure it out.

Yes, it's bad, but it works. I hope there are better ways of doing it, but this is my way.

Re: Things I Was Wrong About: Types

#260

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…

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

It’s because the ergonomics of the previous generation of (mainstream) languages was cumbersome. No sum types, no type inference, nullability all over, terrible error messages, abhorrence of expressions, etc. some of those things are only indirectly related to static typing, but many people mistakenly attribute them to static typing nonetheless. The new crop of mainstream statically typed languages wed these quality of life improvements with the rugged practicality of the previous generation of mainstream languages (none of these features are new, but no serious team is going to switch from C++ to scheme for the type inference alone).

> With that said, it's important to note that type inference is not new. I was doing type inference with Scheme nearly 20 years ago. I believe the reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on. Which, ironically, is the complaint against dynamic typing. In addition to that, you get the pain in the ass of having the compiler always complaining. And because it's inferring types, the error messages are towers of baffling nonsense. It's the worse of both worlds.

Type inference is very much a “sweet spot” thing. Like many things, Rust nails this: you have to annotate struct fields and function arguments, but within a function body you get inference. Changes outside of the function don’t result in type errors inside of the function. Locality is key.

> One thing that never comes up in these discussions is the idea that creating good types is a skill itself.

This is an interesting point, and I agree; however, I think the issue is less that it’s hard to do and more that dynamic typists don’t see it as a worthwhile activity at all—“why should I try to create good types? I just need to get this happy path working so I can get on with life!” Of course there are abundant good reasons (we should care about quality and maintainability and not just superficially churning through feature tickets at the expense of all else), but I think this is a sort of fundamental disagreement between dynamic and static typists.

Post reply on HN