Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

231–240 of 468 posts

Re: Things I Was Wrong About: Types

#231
post #219
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.

It also hasn't changed much in 15 years. Now that could be (and probably is) a deliberate decision. But there are more than enough cases of projects that haven't changed because they can't...they've painted themselves into a corner, and every time they try to change something, something else breaks.

I've felt this way with Python and Ruby and Node projects (it is a major complaint in the RoR community), but have never felt that way with Scala, Java, C#, F#, Rust, or OCaml. Most of the time, when I need to make a change, I just change it, iteratively eliminate any type errors, and once the type errors are gone, the tests magically pass too.

Re: Things I Was Wrong About: Types

#232

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

Definitely not true.

Re: Things I Was Wrong About: Types

#233
post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

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…

Sure, type inference isn't always better, but it's usually clearer — I almost always already know the type of the thing, so explicit types are just noise — and languages with inference still let you write

    let me: Person = something.getOwner();
so you still have the freedom to write the type explicitly.

Re: Things I Was Wrong About: Types

#234
post #68

One note of caution. There's a pleasure to solving problems that arise from type systems akin to solving Sodoku puzzles. It's intellectually satisfying and feels like productive work. I sometime worry that a lot of the overhead and baggage that type systems sneak into coding are hidden because it's fun to resolve them. I'm still on the fence about types. I love them when they help me but I find myself generally writi…

> There's a pleasure to solving problems that arise from type systems akin to solving Sodoku puzzles.

IMO, That's not type system but OOP. Where I have problems with types is usually due to class hierarchies, and developers trying to invent "beautiful" taxonomies and abstractions for the sake of abstractions.

I guess generics sometimes come as a cludge too, particularly if they are combined with the above OOP issues.

In a typical bussiness/app code if you don't use inheritance or keep it to minimum, and use generics where they belong, static typing is rather mindless. "This needs something that implements interface ServiceA, and a string" and then a bit of familiarity with handling collections and "Options".

From my experience, it's only sudoku puzzles if you (code author) make it so. Not very unlike the opposite version when people go very wild with abilities of lack/dynamic typing.

Re: Things I Was Wrong About: Types

#235

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. Not always. If you examine history not everything is a cycle, depending on what you look at human efficiency improves as well. Society goes through natural selection. The cultures, methods and b…

Both classic static and dynamic typing are trending over time to being replaced with the option of static typing with gaps; languages with static typing are more frequently implementing dynamic escape hatches and languages with dynamic typing are getting optional static type checking tools, and both static-first languages and optional typecheckers for dynamic-first languages often have fairly robust type inference, so the firm bright lines that used to exist between static and dynamic languages of the experience of using them is quite a bit blurred.

Re: Things I Was Wrong About: Types

#236
post #37

Types are important and necessary. Can you skip them in a typed language? Yes, just use any, Object or whatever the equivalent. Can you add them to an untyped language? No. They are not needed anywhere. But I argue that especially JavaScript module-systems would have benefited greatly from them. A million lost hours in fixing obscure "undefined is not a function"-errors from output of highly dynamic pluggable build/t…

"They are not needed anywhere." -> This should have been "They are not needed everywhere."

Re: Things I Was Wrong About: Types

#238

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

Are you talking about scheme? It didn't take off for the same reason all other functional languages didn't take off. Why functional languages aren't as popular, who knows.

> Types are meant to document code.

Not true. Comments/documentation are meant to document code. Types and type systems exist to constrain the program space to produce sound programs. Type systems limit the number of valid programs. Types and type systems do not exist to document code.

Re: Things I Was Wrong About: Types

#239

Earlier quoted context omitted.

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.

Python indeed doesn't check them. Really they're just syntactic sugar for what you'd otherwise put in documentation.

Re: Things I Was Wrong About: Types

#240

Earlier quoted context omitted.

>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. Not always. If you examine history not everything is a cycle, depending on what you look at human efficiency improves as well. Society goes through natural selection. The cultures, methods and b…

Both classic static and dynamic typing are trending over time to being replaced with the option of static typing with gaps; languages with static typing are more frequently implementing dynamic escape hatches and languages with dynamic typing are getting optional static type checking tools, and both static-first languages and optional typecheckers for dynamic-first languages often have fairly robust type inference, s…

Yes, but overall static typing is trending again in the sense that more and more static typing is being used... just a little less strict because of the trapdoors as you say.
Post reply on HN