4 ms·

I which there was a little more elaboration on _why_ he originally disliked types so much. This perspective is still very strange to me, as the value of types s

I which there was a little more elaboration on _why_ he originally disliked types so much. This perspective is still very strange to me, as the value of types seems self-evident for systems more complex than a script, and I'd like to understand it better. As it stands now, my only assumption is that this comes from the place the author is coming from: people who don't think types are useful are generally coming from a place of ignorance. This feels facile and self-serving though ("people who disagree with me don't know what they're talking about"), so it's more likely that I have a blind spot. Are there any current or former type-haters that can help shed light on their perspective? EDIT: I should note that my production experience is primarily with (modern)C++ and Python, so I don't even have the benefit of more modern static typing systems like Rust's.

steveklabnik 6y ago
I can't speak for Chris, but I can speak for myself. I did the bulk of my early programming in statically typed languages. Specifically, late 90s C, C++, and Java. Then I found Perl, and pretty much went into dynamically typed languages only for the next near-decade. At the time, I felt like the types didn't pull their weight. There was a lot of extra writing, and you got very little benefit for it. Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true. For example, seeing stuff like https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch11_08.htm https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch11_08... absolutely blew my mind, and I had no idea how you could do something like this in the statically typed langauges I was exposed to at the time. It wasn't until I discovered languages that had significantly more powerful features, and had a significant amount of type inference, that I felt the equation changed. The former to give me something better than purely "don't make some kinds of simple mistakes", and the latter to make it ergonomic enough.
- wutbrodo 6y ago
  > Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true. This resonates a lot with me (though as you say, isn't really a typing thing). I work on ML systems for autonomous vehicles, so I switch between Python and C++, and I definitely occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable than the usually-less-readable naive construct like a loop (eg I'm surprised at how often std::transform comes out looking terrible). Do you mind if I ask about the size of the systems/teams you've worked on throughout this process? My experience with C++ has been in large systems worked on asynchronously by lots of engineers (with strong code review policies in place), and my experience with Python has been everything from moderately-sized systems down to smaller ones down to scripting. The Python case also included work with an inexperienced (and frankly, partially unintelligent) team of engineers, which made the discipline imposed by typing all the more valuable, but I have found the documentation and structure that typing imposes on code to be invaluable in communicating As I said in my other comment, I'm still concerned this is a little facile, but having started my career on C++ systems at Google, I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible (I'm certainly an order of magnitude better at reading code than anyone my current team, but this is confounded by the fact that everyone else has a weaker engineering background and stronger robotics or ML domain expertise). To be clear, I don't think this applies to you necessarily; your approach of trading off the benefits of ergonomics vs structure resonates strongly with me, and I'd imagine it's even more the case on pre-modern statically-typed languages. What I'm really curious about is the perspective expressed in the OP, which, in the 2010s, doesn't even see _value_ in types beyond perhaps negligible benefit from some compiler checks. Thank you very much for the perspective!
  - steveklabnik 6y ago
    > Do you mind if I ask about the size of the systems/teams you've worked on throughout this process? The "oh wow I'm never doing static typing again" bit happened entirely as a hobbyist, maybe working on a project with a friend or two. My early professional life was dominated by Ruby, mostly in smallish teams, that is, like, under 30 people. Then I got into working in Ruby open source, where the teams are much bigger, and aren't all working for the same org... > occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable Not to be That Guy, but you should give Rust a try if you haven't yet. You may not like it, but it will make writing that style of code feel more like Python, often. > I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible I think the issue isn't about possibility, but about realization. That is, I also did know that more robust static typing existed, but in 2008 I wasn't going to be writing a web app in Haskell, but in PHP or Rails. So it felt pretty academic. And even knowing that it's possible in theory isn't the same as experiencing it in practice. One of the things that frustrates me about this particular Discourse (static vs dynamic types) is that many dynamic language proponents (myself included historically) will understand that testing is a skill that they need to practice with in order to succeed, but don't perceive types the same way. It takes practice! You won't just magically see benefits immediately. They're a tool. But in order to justify doing that work, you have to be able to see a real benefit. I don't begrudge people that don't see the connections here and so don't want to put in the time or effort to realize the benefits.
    - wutbrodo 6y ago
      > Not to be That Guy, but you should give Rust a try if you haven't yet. You may not like it, but it will make writing that style of code feel more like Python, often. I've never used Rust but I was a (low-confidence) big fan the moment I saw it, and everything I've seen since has only strengthened this impression. I don't exactly _love_ C++ and all its janky weirdness, and Rust seems like it improves ergonomics while allowing even more powerful control over memory and type safety. Unfortunately, there are a couple of computer science subspecialties that I prioritize when looking for roles, so I lose some degrees of freedom in the ability to pick jobs or side projects that would expose me to Rust.
- chriskrycho 6y ago
  Steve says he can’t speak for me, but in this case… he basically can. The timelines are a little different (late ’00s for me instead of late ’90s), but the trajectory was the same, and the feature gaps he alludes to here were definitely a part of it. I recall arguing in 2012 or so that types were useless… with a colleague who had a background with OCaml. The problem was that when we said “types” I meant something completely different than he did. (Jerrad, if you happen to read this, you were right. )
- erik_seaberg 6y ago
  Oh yeah, types need to express everything people actually want to do or they become a straitjacket. In the late 1990s we had to find cumbersome workarounds for seemingly-valid templates that would crash Borland C++. Today Java’s type system is … not great, but it was a lot worse before generics in 2004.
edanm 6y ago
I originally worked with C++. I then moved to Python and loved it, partially because of the dynamic type system. I'm still in the dynamic-types camp, though I haven't really learned a language with a good static type system yet, and the little I've learned of Haskell has made me super interested in a good type system. To answer your question, the reason I prefer Python to C++, in terms of types at least, is that I feel the type system makes you get the order of building a program wrong. I think the right way, in most cases, is an agile-style, prototype-first approach. You should usually start with the simplest prototype of something that does what you want, then slowly expand and generalize as you learn more about the problem domain and make product and design decisions. With C++, you usually start off with lots of decisions on how your data looks, and it's usually really hard to make changes afterwards. This forces you to make a lot off the architectural decisions when you know the least, and are fairly locked into those decisions. The main benefit proposed benefit of a type system, or at least of C++'s type system, is that the compiler can help you catch type errors. However, these errors represent a small fraction of possible buga - so you're going to have to write tests anyway, and it's not hard to add type tests as well (where relevant- the idea is that it's often less relevant than you think!). Caveats to my opinion: 1. I haven't worked in C++ for many years, and I know that there's been a lot of changes. Not sure how my opinion stacks up to current cpp. 2. If the type system gives you more than just catching some class of errors, I can see that it might be worth it. Again, no real experience with anything other than Python and js in many years. 3. I'm pretty sure I'm right about the correct way to build software in terms of steps. The older waterfall approach where everything is designed to front makes little sense in most projects I've seen, or at least in the early phases. Possibly something like Excel, in exchange there's very little new product development and in which the product domain is super well understood, has different trade offs. Having said that, I might be wrong about how much cpp forces you to do things the other way. That was my experience and most people's that I know- but that was also the common way to do things in the past anyway. Possibly, there are good ways of doing that kind of development in cpp today.
- chriskrycho 6y ago
  In my experience, types (at least in the kinds of languages I like) and tests are orthogonal, though people enamored of either often try to use it to do the work the other is best at. I both TDD and TDD: that is, I do both type-driven and test-driven development, and the combo is incredible. I strongly suspect that if and as I’m able to add tools like formal methods, logic programming, etc. to my tool belt they will similarly become orthogonal tools for correctness that I can employ where appropriate.

steveklabnik 6y ago

I can't speak for Chris, but I can speak for myself. I did the bulk of my early programming in statically typed languages. Specifically, late 90s C, C++, and Java. Then I found Perl, and pretty much went into dynamically typed languages only for the next near-decade. At the time, I felt like the types didn't pull their weight. There was a lot of extra writing, and you got very little benefit for it. Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true. For example, seeing stuff like https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch11_08.htm https://www.cs.ait.ac.th/~on/O/oreilly/perl/cookbook/ch11_08... absolutely blew my mind, and I had no idea how you could do something like this in the statically typed langauges I was exposed to at the time. It wasn't until I discovered languages that had significantly more powerful features, and had a significant amount of type inference, that I felt the equation changed. The former to give me something better than purely "don't make some kinds of simple mistakes", and the latter to make it ergonomic enough.

wutbrodo 6y ago
> Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true. This resonates a lot with me (though as you say, isn't really a typing thing). I work on ML systems for autonomous vehicles, so I switch between Python and C++, and I definitely occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable than the usually-less-readable naive construct like a loop (eg I'm surprised at how often std::transform comes out looking terrible). Do you mind if I ask about the size of the systems/teams you've worked on throughout this process? My experience with C++ has been in large systems worked on asynchronously by lots of engineers (with strong code review policies in place), and my experience with Python has been everything from moderately-sized systems down to smaller ones down to scripting. The Python case also included work with an inexperienced (and frankly, partially unintelligent) team of engineers, which made the discipline imposed by typing all the more valuable, but I have found the documentation and structure that typing imposes on code to be invaluable in communicating As I said in my other comment, I'm still concerned this is a little facile, but having started my career on C++ systems at Google, I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible (I'm certainly an order of magnitude better at reading code than anyone my current team, but this is confounded by the fact that everyone else has a weaker engineering background and stronger robotics or ML domain expertise). To be clear, I don't think this applies to you necessarily; your approach of trading off the benefits of ergonomics vs structure resonates strongly with me, and I'd imagine it's even more the case on pre-modern statically-typed languages. What I'm really curious about is the perspective expressed in the OP, which, in the 2010s, doesn't even see _value_ in types beyond perhaps negligible benefit from some compiler checks. Thank you very much for the perspective!
- steveklabnik 6y ago
  > Do you mind if I ask about the size of the systems/teams you've worked on throughout this process? The "oh wow I'm never doing static typing again" bit happened entirely as a hobbyist, maybe working on a project with a friend or two. My early professional life was dominated by Ruby, mostly in smallish teams, that is, like, under 30 people. Then I got into working in Ruby open source, where the teams are much bigger, and aren't all working for the same org... > occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable Not to be That Guy, but you should give Rust a try if you haven't yet. You may not like it, but it will make writing that style of code feel more like Python, often. > I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible I think the issue isn't about possibility, but about realization. That is, I also did know that more robust static typing existed, but in 2008 I wasn't going to be writing a web app in Haskell, but in PHP or Rails. So it felt pretty academic. And even knowing that it's possible in theory isn't the same as experiencing it in practice. One of the things that frustrates me about this particular Discourse (static vs dynamic types) is that many dynamic language proponents (myself included historically) will understand that testing is a skill that they need to practice with in order to succeed, but don't perceive types the same way. It takes practice! You won't just magically see benefits immediately. They're a tool. But in order to justify doing that work, you have to be able to see a real benefit. I don't begrudge people that don't see the connections here and so don't want to put in the time or effort to realize the benefits.
  - wutbrodo 6y ago
    > Not to be That Guy, but you should give Rust a try if you haven't yet. You may not like it, but it will make writing that style of code feel more like Python, often. I've never used Rust but I was a (low-confidence) big fan the moment I saw it, and everything I've seen since has only strengthened this impression. I don't exactly _love_ C++ and all its janky weirdness, and Rust seems like it improves ergonomics while allowing even more powerful control over memory and type safety. Unfortunately, there are a couple of computer science subspecialties that I prioritize when looking for roles, so I lose some degrees of freedom in the ability to pick jobs or side projects that would expose me to Rust.
chriskrycho 6y ago
Steve says he can’t speak for me, but in this case… he basically can. The timelines are a little different (late ’00s for me instead of late ’90s), but the trajectory was the same, and the feature gaps he alludes to here were definitely a part of it. I recall arguing in 2012 or so that types were useless… with a colleague who had a background with OCaml. The problem was that when we said “types” I meant something completely different than he did. (Jerrad, if you happen to read this, you were right. )
erik_seaberg 6y ago
Oh yeah, types need to express everything people actually want to do or they become a straitjacket. In the late 1990s we had to find cumbersome workarounds for seemingly-valid templates that would crash Borland C++. Today Java’s type system is … not great, but it was a lot worse before generics in 2004.

edanm 6y ago

I originally worked with C++. I then moved to Python and loved it, partially because of the dynamic type system. I'm still in the dynamic-types camp, though I haven't really learned a language with a good static type system yet, and the little I've learned of Haskell has made me super interested in a good type system. To answer your question, the reason I prefer Python to C++, in terms of types at least, is that I feel the type system makes you get the order of building a program wrong. I think the right way, in most cases, is an agile-style, prototype-first approach. You should usually start with the simplest prototype of something that does what you want, then slowly expand and generalize as you learn more about the problem domain and make product and design decisions. With C++, you usually start off with lots of decisions on how your data looks, and it's usually really hard to make changes afterwards. This forces you to make a lot off the architectural decisions when you know the least, and are fairly locked into those decisions. The main benefit proposed benefit of a type system, or at least of C++'s type system, is that the compiler can help you catch type errors. However, these errors represent a small fraction of possible buga - so you're going to have to write tests anyway, and it's not hard to add type tests as well (where relevant- the idea is that it's often less relevant than you think!). Caveats to my opinion: 1. I haven't worked in C++ for many years, and I know that there's been a lot of changes. Not sure how my opinion stacks up to current cpp. 2. If the type system gives you more than just catching some class of errors, I can see that it might be worth it. Again, no real experience with anything other than Python and js in many years. 3. I'm pretty sure I'm right about the correct way to build software in terms of steps. The older waterfall approach where everything is designed to front makes little sense in most projects I've seen, or at least in the early phases. Possibly something like Excel, in exchange there's very little new product development and in which the product domain is super well understood, has different trade offs. Having said that, I might be wrong about how much cpp forces you to do things the other way. That was my experience and most people's that I know- but that was also the common way to do things in the past anyway. Possibly, there are good ways of doing that kind of development in cpp today.

chriskrycho 6y ago
In my experience, types (at least in the kinds of languages I like) and tests are orthogonal, though people enamored of either often try to use it to do the work the other is best at. I both TDD and TDD: that is, I do both type-driven and test-driven development, and the combo is incredible. I strongly suspect that if and as I’m able to add tools like formal methods, logic programming, etc. to my tool belt they will similarly become orthogonal tools for correctness that I can employ where appropriate.