Things I Was Wrong About: Types • Hacker News Board

Re: Things I Was Wrong About: Types

#351

Post by pvorb » Sun, Sep 27, 2020, 9:30 PM UTC

cle wrote: post #348

cannabis_sam wrote: post #277

Earlier quoted context omitted.

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

There’s a continuum for sure. Type systems have their own kind of cognitive load, because you have to learn them, how to model your invariants in them, how to understand error messages, avoid common pitfalls, etc. Type systems are usually quite “general” and abstract, and that always comes with cognitive load. Quite often reading the code of a parametrically-polymorphic Python function is way easier than understandin…

I don't buy this "choose the right tool for the job" thing. I'd always advise you to choose the tool that your company has the most knowledge in. If there's a problem that cannot be solved in that programming language, then you can look for a better tool. But you shouldn't pick a language that nobody else understands, just to save a few lines or some time when doing the initial implementation - just to realize that you now have to constantly keep up the knowledge to be able to support it.

Re: Things I Was Wrong About: Types

#352

Post by chriskrycho » Sun, Sep 27, 2020, 9:34 PM UTC

sgt101 wrote: post #349

I realized these lessons about types in the first semester of compsci at Uni - no one "taught me" but the curriculum meant that I learned this. It's great that people come to these insights on their own - but it's really clear that this is a very inefficient way of learning.

Kind of! But there is also, in many areas of life (and perhaps including this one) a reality that you can't actually learn things truly without going through some of these bumps along the way.

The funny thing is, I started out passionately affirmative of the value of types, became disillusioned as discussed in the post, and then came around when I found types that actually did the things that I wanted.

Re: Things I Was Wrong About: Types

#353

Post by throwaway894345 » Sun, Sep 27, 2020, 9:36 PM UTC

cle wrote: post #348

cannabis_sam wrote: post #277

Earlier quoted context omitted.

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

There’s a continuum for sure. Type systems have their own kind of cognitive load, because you have to learn them, how to model your invariants in them, how to understand error messages, avoid common pitfalls, etc. Type systems are usually quite “general” and abstract, and that always comes with cognitive load. Quite often reading the code of a parametrically-polymorphic Python function is way easier than understandin…

For the most part this cognitive load already exists in order to write correct programs. Types don’t just appear when a type checker is present. Type systems only add on the additional burden of needing to understand the formalization of that intuition. It’s not an insignificant burden, but it’s a much smaller gap than learning to intuit about programming correctly in the first place.

Re: Things I Was Wrong About: Types

#354

Post by GordonS » Sun, Sep 27, 2020, 9:36 PM UTC

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 also started off with PHP, about 20 years ago. Soon after, I started working with C# and had the same feelings you had about Java - code was so much more readable, maintainable and refactorable, and so much less buggy. I've never looked back from static typing, and am put off from using languages I'd otherwise be interested in (like Elixir).

Re: Things I Was Wrong About: Types

#355

Post by csb6 » Sun, Sep 27, 2020, 9:38 PM UTC

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 have had similar experiences with Python. What endlessly frustrated me when looking up the documentation for Python’s standard library (I was using the classes for working with emails/imap) was that what kind of thing to pass in as arguments wasn’t specified clearly. It made using the API so much harder because I had to trial/error to figure out how to construct the proper object that the API would accept.

Re: Things I Was Wrong About: Types

#356

Post by codebje » Sun, Sep 27, 2020, 9:38 PM UTC

jkoudys wrote: post #322

temporallobe wrote: post #130

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 did Java dev for a while, after being C before then. I felt like everything needed a pile of typecasting in front of it to work, even though these were often objects for classes you'd think should all play nicely. I realized only after dealing with it for so long that Java wasn't supposed to work that way, but how things can work when well written, vs old apps where half the code is written by a long line of 4-mont…

Type systems limit the set of programs accepted by the compiler. A sound type system will reject every bad program - but also may reject some good programs. Type systems therefore also will have escape hatches to let the programmer overrule the compiler.

Bad type systems need you to use the escape hatches frequently - you can't write much C without using casts.

I haven't yet used a language with no need at all for an escape hatch - but some languages need them far less often than others.

Java's type system is better than it was. The main places it still has weaknesses are around exceptions (you will need to wrap checked exceptions in runtime exceptions in places you'd have preferred to specify an exception type via generics, eg) and the occasional cast after an instance type check.

You can phrase good development practices in business terms: what are the risks to the business due to sloppy code? Are they greater than the risk of being slow to market?

Sloppy code has accumulating costs. A good type system can help greatly with refactoring to address those costs, but it cannot help with the attitude that those costs aren't real and don't need to be paid.

Re: Things I Was Wrong About: Types

#357

Post by Falkon1313 » Sun, Sep 27, 2020, 9:40 PM UTC

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…

Me too, but I learned in Turbo Pascal and early Java which had some real limitations to their type systems. Imagine - strings of different lengths being incompatible types, arrays of different lengths being incompatible types, no generics, so no standard collections, no serialization, tons of manual typecasting. Having to write separate methods for every possible set of parameters.

Out of nostalgia, getting so frustrated with dynamic-typed code, I once tried to go back to some of that old code and make it use JSON instead of proprietary formats. That was a nightmare.

In the dynamic languages it would be utterly trivial. Just call json_encode($whatever), or $whatever = json_decode($some_string).

Modern languages with modern type systems, inference, generics, etc. that make things like that possible and relatively clean completely change the picture.

Another thing that bugs me about dynamic languages is of course you have to manually check everything all the time because the compiler can't. We used to complain about the bloat of having to write all those type names and casts, but dynamic code, if it has good checks, can actually be more bloated in addition to being less expressive.

Re: Things I Was Wrong About: Types

#358

Post by joe_the_user » Sun, Sep 27, 2020, 9:41 PM UTC

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…

For many enterprises, getting code out the door is a key win. So in an idealist conception, maintainability, correctness and good design are everything. In the practical reality of today, these often have to take a back seat to speed of implementation.

What I'd like to see is a language that allows typeless programming to start but which is designed to allow the imposition of types at a later point.

Re: Things I Was Wrong About: Types

#359

Post by pmontra » Sun, Sep 27, 2020, 9:42 PM UTC

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 with C and some Pascal. Then Java and Perl. Then JavaScript, then Ruby, then Python, then Elixir.

The great thing of Java was garbage collection. No more malloc/free hell and programs still worked.

The great thing about Perl and the other scripting languages was no type declaration (plus garbage collection.) And programs still worked.

After 30 years I kind of agree with the author of the OP: the time lost annotating programs with types of not offset by the benefits. In almost all cases type discovery is something the computer should do, not me. Same as for memory management: automatic, not manual.

Re: Things I Was Wrong About: Types

#360

Post by a_humean » Sun, Sep 27, 2020, 9:43 PM UTC

MiroF wrote: post #341

lolinder wrote: post #290

Earlier quoted context omitted.

It's not perfect, but TypeScript goes a long way toward making frontend feel as safe as backend. You still have the potential for weird bugs when interacting with external JavaScript, but your internal code is pretty safe. Also, TypeScript's type system is impressively flexible, and I often find myself missing features (like unions) when working with other languages.

> missing features (like unions) when working with other languages. Which languages are missing unions? Off the top of my head, they exist in C/C++ and mypy python.

Typescript allows you to have literal type discriminators in their unions, which combined with control flow based type narrowing of unions effectively gives you sum types. That is what he is talking about, because most mainstream langauges don't have sum types and you need to go to strongly typed functional langauges (haskell, scala, etc...) or modern strongly typed langauges such as Rust to get access to such features.