108 ms·

Dynamic typing and anti-lock brakes

27 points by johndcook 16y ago

plesn 16y ago
Good point, but the debate is still in the "C++ vs Python" bounds. Haskell has Hindley-Milner and Quickcheck and I think the debate is elsewhere: the cost of abstractions and tools (just read another doc/paper to understand how to do this) but also their benefits (scaffoldings and cranes while programming).
rbranson 16y ago
The comparison of static typing to anti-lock brakes is a bit off. Anti-lock brakes are more like the function of an optimizing compiler (JIT or otherwise). Unless you're on-top of your game all the time and have race car driver-like reflexes, you can't beat it.
- regularfry 16y ago
  It's not about beating it, it's about how having it affects your behaviour.
jrockway 16y ago
Yes, this is true, the dynamic language communities have compensated for the lack of a type system with explicit type checks (or type constraints) and lots of testing. But it's still nice to have a real type system (and I don't mean C or C++ or Java; those languages also have no type system). When I compile a Haskell project successfully, I have a reasonable belief that it's going to run to completion and at least produce some sort of result. The same is not true of Perl, even with lots of tests, my programs almost always die in the middle (during development) where a runtime type check or assertion fails. The reality of programming is that all functions and variables have types. If you add 42 to "hello world", you get garbage. In dynamically typed languages, you keep the types in your mind -- you know that the variable you are adding 42 is a number. In statically typed languages, you tell the compiler. The second way lets the computer do some of the work for you (ensuring that if you use the variable like a string, your program won't compile), the first way requires you to do everything. If you aren't careful, you get the wrong answer or a runtime error. I think dynamic typing was a nice way for the programming language community to realize that C's type system sucked, but it isn't the ultimate answer, it's just a stopgap. It's also good that people realized they needed to test their code automatically; but that works even better with statically-typed languages. Anyway, I am not going to give up Perl anytime soon, but I secretly wish it wasn't dynamically-typed.
- jcsiracusa 16y ago
  Is running to completion and producing an incorrect result really preferable to dying in the middle of execution due to a runtime check or assertion? Either your program works or it doesn't.
  - jrockway 16y ago
    Yes.
    - gnaritas 16y ago
      No. Failure is failure.
      - paulbaumgart 16y ago
        With dynamically typed languages and implicit variable declarations, I find the most common runtime errors are, in descending order of frequency: * Something returned null when I assumed it would return a value/object. * I used the wrong variable. * I made a typo in an assignment that implicitly created an unused variable (this is easy to catch with static analysis even in dynamically typed languages, admittedly). The first one is by far the most common. I'm not particularly experienced with Haskell, but my understanding is that the static typing will usually catch the second one and that more advanced static analysis (more advanced than type checking) can easily catch the third one. Most important, though, is the case of the first and most common error. Here, the language will very explicitly require you to handle the case that "Nothing" will potentially be returned. So, most of the sorts of errors that would have caused failed execution in a dynamically typed language will be caught at compile time. This means that when the program runs, it will usually be closer to being correct than it would be if it were written in a dynamically typed language and failed in the middle of execution.
        sid0 16y ago
        I agree. One of the biggest benefits of a proper type system (and by saying "proper" I immediately exclude C and Java, so don't even bother mentioning them) is that you get clean semantics for both nullable and non-nullable types. Hoare called null a billion-dollar mistake, and I completely agree.
angelbob 16y ago
This is true for "average drivers". The math is totally different with, say, racecar drivers. I think there's a strong parallel with programmers here, and whether you're optimizing for average-case job throughput (or hobby throughput) or whether you're optimizing something specific where safety or reliability is specifically important.
orblivion 16y ago
I ride a bicycle in the city with a helmet, knowing that I do it in order to ride a little more dangerously. It gets me where I'm going faster. When I'm without a helmet in the city I ride very defensively. I use Python and I'm very slowly getting into Haskell, I don't have much experience with static typing, but I think that the analogy will apply when I get used to it. I enjoy the safety net so that I can, in fact, be a little more reckless in my coding. Experiment a bit more, get things done a little faster, etc.
- devinj 16y ago
  Static typing is like a helmet that forces a speed limit, too. It won't necessarily help you experiment faster-- the common wisdom is that it does the opposite, in Java/etc. style static typing.
  - Periodic 16y ago
    Which is why we need to work on dispelling the myth that static typing requires explicit typing. Type inference gives you many of the advantages of type checking without having to explicitly type every variable. http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference
- chaosmachine 16y ago
  Re: helmets giving you more room to be dangerous... http://www.gizmag.com/go/7255/ http://www.gizmag.com/go/7255/ "Drivers were as much as twice as likely to get particularly close to the bicycle when [the cyclist] was wearing the helmet. Across the board, drivers passed an average of 8.5 cm (3 1/3 inches) closer with the helmet than without. The research has been accepted for publication in the journal Accident Analysis & Prevention." 20/20 video: http://www.youtube.com/watch?v=YdoE2YCvwdM http://www.youtube.com/watch?v=YdoE2YCvwdM
mkramlich 16y ago
I worked on a 20 KLOC app of mine yesterday that has neither static type decls or unit tests and yet is AFAIK bug free. This has been the rule and not the exception in my experience. So I prefer to not have them since in the general case they are not needed and just add clutter and drag.
- cabacon 16y ago
  I prefer to think of it as having bugs you just don't know about yet. Does anyone use the app besides you?
  - mkramlich 16y ago
    Good perspective, thanks. And yes, many users other than me. Another way of looking at it though is to say if a bug has never been encountered that arguably it is not actually a bug and/or it doesn't matter. Anti-Heisenbug? :)
- kragen 16y ago
  How long ago did you fix the last bug? That's probably a good estimate of how long you'll go before you fix the next one.
  - mkramlich 16y ago
    Bugs can exist within a coding session. I consider that a normal part of the development effort. You think of some change you want to make. You make it. If you discover you made a typo or overlooked some issue and thus it has caused a bug, during your dev-testing, you fix it. Once the desired change is done, working as intended, with no bugs, that change-sprint is done and commited to your VCS. Then you end the dev session or advance to the next desired change. The key is that when your dev session ends, and when you are just wearing the user's hat, there should be no bugs. In my experience, bugs can be found usually quickly and easily within the same coding session that introduced a new feature, while the code and your recent change are all fresh in mind, and you are in The Zone. That was a good heuristic you suggested, but I think it applies to situations where a bug survives beyond the end of a development session, accidentally.
pasbesoin 16y ago
Regarding the anecdote rather than the meat of the post, I drove for years under all conditions without anti-lock brakes. These days, I still find myself occasionally fighting them. I know very well how to control the car, including through controlled skids, and that's worked its way deep into my reactions. In extreme situations, the anti-lock brakes still sometimes throw me off and slow my overall reactions, as I have to pause and adjust to their presence. I also simply cannot perform some -- often useful -- maneuvers with them that I can on a vehicle not having anti-lock brakes. So... I can imagine some of the cab drivers, with years of driving experience, having some difficulty adjusting to the difference that anti-lock brakes make, with a corresponding increase in effective reaction time and with perhaps a surprising inability to negotiate risks as they have previously learned to and expect to.

27 points by johndcook 16y ago

plesn 16y ago

Good point, but the debate is still in the "C++ vs Python" bounds. Haskell has Hindley-Milner and Quickcheck and I think the debate is elsewhere: the cost of abstractions and tools (just read another doc/paper to understand how to do this) but also their benefits (scaffoldings and cranes while programming).

rbranson 16y ago

The comparison of static typing to anti-lock brakes is a bit off. Anti-lock brakes are more like the function of an optimizing compiler (JIT or otherwise). Unless you're on-top of your game all the time and have race car driver-like reflexes, you can't beat it.

regularfry 16y ago
It's not about beating it, it's about how having it affects your behaviour.

jrockway 16y ago

Yes, this is true, the dynamic language communities have compensated for the lack of a type system with explicit type checks (or type constraints) and lots of testing. But it's still nice to have a real type system (and I don't mean C or C++ or Java; those languages also have no type system). When I compile a Haskell project successfully, I have a reasonable belief that it's going to run to completion and at least produce some sort of result. The same is not true of Perl, even with lots of tests, my programs almost always die in the middle (during development) where a runtime type check or assertion fails. The reality of programming is that all functions and variables have types. If you add 42 to "hello world", you get garbage. In dynamically typed languages, you keep the types in your mind -- you know that the variable you are adding 42 is a number. In statically typed languages, you tell the compiler. The second way lets the computer do some of the work for you (ensuring that if you use the variable like a string, your program won't compile), the first way requires you to do everything. If you aren't careful, you get the wrong answer or a runtime error. I think dynamic typing was a nice way for the programming language community to realize that C's type system sucked, but it isn't the ultimate answer, it's just a stopgap. It's also good that people realized they needed to test their code automatically; but that works even better with statically-typed languages. Anyway, I am not going to give up Perl anytime soon, but I secretly wish it wasn't dynamically-typed.

jcsiracusa 16y ago
Is running to completion and producing an incorrect result really preferable to dying in the middle of execution due to a runtime check or assertion? Either your program works or it doesn't.
- jrockway 16y ago
  Yes.
  - gnaritas 16y ago
    No. Failure is failure.
    - paulbaumgart 16y ago
      With dynamically typed languages and implicit variable declarations, I find the most common runtime errors are, in descending order of frequency: * Something returned null when I assumed it would return a value/object. * I used the wrong variable. * I made a typo in an assignment that implicitly created an unused variable (this is easy to catch with static analysis even in dynamically typed languages, admittedly). The first one is by far the most common. I'm not particularly experienced with Haskell, but my understanding is that the static typing will usually catch the second one and that more advanced static analysis (more advanced than type checking) can easily catch the third one. Most important, though, is the case of the first and most common error. Here, the language will very explicitly require you to handle the case that "Nothing" will potentially be returned. So, most of the sorts of errors that would have caused failed execution in a dynamically typed language will be caught at compile time. This means that when the program runs, it will usually be closer to being correct than it would be if it were written in a dynamically typed language and failed in the middle of execution.
      - sid0 16y ago
        I agree. One of the biggest benefits of a proper type system (and by saying "proper" I immediately exclude C and Java, so don't even bother mentioning them) is that you get clean semantics for both nullable and non-nullable types. Hoare called null a billion-dollar mistake, and I completely agree.

angelbob 16y ago

This is true for "average drivers". The math is totally different with, say, racecar drivers. I think there's a strong parallel with programmers here, and whether you're optimizing for average-case job throughput (or hobby throughput) or whether you're optimizing something specific where safety or reliability is specifically important.

orblivion 16y ago

I ride a bicycle in the city with a helmet, knowing that I do it in order to ride a little more dangerously. It gets me where I'm going faster. When I'm without a helmet in the city I ride very defensively. I use Python and I'm very slowly getting into Haskell, I don't have much experience with static typing, but I think that the analogy will apply when I get used to it. I enjoy the safety net so that I can, in fact, be a little more reckless in my coding. Experiment a bit more, get things done a little faster, etc.

devinj 16y ago
Static typing is like a helmet that forces a speed limit, too. It won't necessarily help you experiment faster-- the common wisdom is that it does the opposite, in Java/etc. style static typing.
- Periodic 16y ago
  Which is why we need to work on dispelling the myth that static typing requires explicit typing. Type inference gives you many of the advantages of type checking without having to explicitly type every variable. http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference
chaosmachine 16y ago
Re: helmets giving you more room to be dangerous... http://www.gizmag.com/go/7255/ http://www.gizmag.com/go/7255/ "Drivers were as much as twice as likely to get particularly close to the bicycle when [the cyclist] was wearing the helmet. Across the board, drivers passed an average of 8.5 cm (3 1/3 inches) closer with the helmet than without. The research has been accepted for publication in the journal Accident Analysis & Prevention." 20/20 video: http://www.youtube.com/watch?v=YdoE2YCvwdM http://www.youtube.com/watch?v=YdoE2YCvwdM

mkramlich 16y ago

I worked on a 20 KLOC app of mine yesterday that has neither static type decls or unit tests and yet is AFAIK bug free. This has been the rule and not the exception in my experience. So I prefer to not have them since in the general case they are not needed and just add clutter and drag.

cabacon 16y ago
I prefer to think of it as having bugs you just don't know about yet. Does anyone use the app besides you?
- mkramlich 16y ago
  Good perspective, thanks. And yes, many users other than me. Another way of looking at it though is to say if a bug has never been encountered that arguably it is not actually a bug and/or it doesn't matter. Anti-Heisenbug? :)
kragen 16y ago
How long ago did you fix the last bug? That's probably a good estimate of how long you'll go before you fix the next one.
- mkramlich 16y ago
  Bugs can exist within a coding session. I consider that a normal part of the development effort. You think of some change you want to make. You make it. If you discover you made a typo or overlooked some issue and thus it has caused a bug, during your dev-testing, you fix it. Once the desired change is done, working as intended, with no bugs, that change-sprint is done and commited to your VCS. Then you end the dev session or advance to the next desired change. The key is that when your dev session ends, and when you are just wearing the user's hat, there should be no bugs. In my experience, bugs can be found usually quickly and easily within the same coding session that introduced a new feature, while the code and your recent change are all fresh in mind, and you are in The Zone. That was a good heuristic you suggested, but I think it applies to situations where a bug survives beyond the end of a development session, accidentally.

pasbesoin 16y ago

Regarding the anecdote rather than the meat of the post, I drove for years under all conditions without anti-lock brakes. These days, I still find myself occasionally fighting them. I know very well how to control the car, including through controlled skids, and that's worked its way deep into my reactions. In extreme situations, the anti-lock brakes still sometimes throw me off and slow my overall reactions, as I have to pause and adjust to their presence. I also simply cannot perform some -- often useful -- maneuvers with them that I can on a vehicle not having anti-lock brakes. So... I can imagine some of the cab drivers, with years of driving experience, having some difficulty adjusting to the difference that anti-lock brakes make, with a corresponding increase in effective reaction time and with perhaps a surprising inability to negotiate risks as they have previously learned to and expect to.