4 ms·

I'm glad I actually read the article, because while I too like strong typing and compilation errors, but I don't want to be associated with programmers who do t

I'm glad I actually read the article, because while I too like strong typing and compilation errors, but I don't want to be associated with programmers who do things like this: >Today I had to modify a piece of JavaScript code. The code used return a single string, and I needed to modify it to return an array of objects. Using C#, it would have been easy, change the return type, hit the compile button, fix the errors, rinse & repeat until it compiles. The compiler does not save you from having to think, and like InclinedPlane says, compilation doesn't 'prove' correctness, only shows you that the compiler could at least sludge its way through your code. The code should pass some mental unit tests of expected inputs and outputs before you even make the change.

liuliu 16y ago
It is interesting to observe that TDD (or our intelligent IDE) actually makes programmers never think. They tend to develop in more ad-hoc way: Google some example code snippet, change the order and play around with some parameters, fix the Eclipse "syntax error" hint and try it out until it works. EDIT: yes, it is just plain wrong, no excuse. But I am trying to point out that it truly happened and I am curious about why or how.
- WalterGR 16y ago
  Hogwash. No good developer does what you describe, no matter what tools they use.
  - liuliu 16y ago
    That is my point. But it trained many incompetent programmers who fancy they can do the job "just right" in the market.
  - InclinedPlane 16y ago
    Good? No. But making a living writing code, maybe even important code? Far more likely than you'd like to think.
    - WalterGR 16y ago
      > But making a living writing code, maybe even important code? Far more likely than you'd like to think. I've never seen developers who work this way: not in industry - not even in college. In my experience, the "mess around with the code arbitrarily until it works" style described by liuliu is the programmer's equivalent of a moral panic. Everyone talks about it and laments it, but it doesn't really happen.
barrkel 16y ago
The type system is a unit test of expected inputs and outputs - it ensures that values are bounded to their domains, and aren't manipulated incorrectly. The advantage of doing it like Ayende says is when you already have a mental model of the transformation that you want to perform, the compiler can do the work of showing you the bits you need to edit to finalize the transformation. This process isn't mindless; because you've informed the type system about the substructure of your code, when you want to change the shape of that substructure, the compiler is then able to tell you exactly where it is now inconsistent. Whereas with dynamically typed code, you need unit tests with 100% path coverage (line coverage isn't enough) to guarantee that you caught every interaction, if you were to approach the change in the same way. (As an aside: that's a whole lot of tests that need rewriting and refactoring, one reason I don't like unit testing for very early stages of a project when the design is quite fluid.) The alternative is eyeballing the code and perhaps getting a runtime type violation or two before all the locations are gotten right. Note that here I'm only talking about finding the locations to modify, not about guaranteeing that the modifications are correct. If the structural change is simple, where all the in-place modifications are trivial, having a static type system that tells you about all the locations is really handy, whereas you need to do a lot more work with a dynamic type system. IMO the benefits of a dynamic type system are more apparent when the systems you're working with are themselves dynamic and (relatively) quickly changing in nature, or when the substructure is too tedious to efficiently express in a static type system (especially apparent with mutually recursive generic types with dependencies among type parameters, like you might find in generic parsing and graph transformation libraries, etc.).
andywood 16y ago
I think that you, InclinedPlane, and BoppreH are missing the point, while cautioning against a strawman. It is elementary that successful compilation does not imply correct code; but that is not what Ayende is talking about at all. There are specific, disciplined ways in which you can use the compiler to reliably tell you what you need to fix when making certain kinds of changes. Such techniques are very valuable in large codebases. For example, you change the semantics of an interface method slightly, and this results in changing the type of the return value, or the arguments. After changing the method signature in the interface, the compiler tells you exactly where you need to make corresponding changes in the rest of your large codebase. Naturally, it can't tell you exactly what changes to make - for that you use your brain. But it tells you exactly where you need to make changes, and gives a good general idea of what changes to make. That's the kind of technique this post is talking about. Whether you intend it or not, dismissing effective use of such powerful tools as "confusing compilation with correctness" is both misleading, and kind of insulting to users of strongly typed languages who know what they're doing.

liuliu 16y ago

It is interesting to observe that TDD (or our intelligent IDE) actually makes programmers never think. They tend to develop in more ad-hoc way: Google some example code snippet, change the order and play around with some parameters, fix the Eclipse "syntax error" hint and try it out until it works. EDIT: yes, it is just plain wrong, no excuse. But I am trying to point out that it truly happened and I am curious about why or how.

WalterGR 16y ago
Hogwash. No good developer does what you describe, no matter what tools they use.
- liuliu 16y ago
  That is my point. But it trained many incompetent programmers who fancy they can do the job "just right" in the market.
- InclinedPlane 16y ago
  Good? No. But making a living writing code, maybe even important code? Far more likely than you'd like to think.
  - WalterGR 16y ago
    > But making a living writing code, maybe even important code? Far more likely than you'd like to think. I've never seen developers who work this way: not in industry - not even in college. In my experience, the "mess around with the code arbitrarily until it works" style described by liuliu is the programmer's equivalent of a moral panic. Everyone talks about it and laments it, but it doesn't really happen.

barrkel 16y ago

The type system is a unit test of expected inputs and outputs - it ensures that values are bounded to their domains, and aren't manipulated incorrectly. The advantage of doing it like Ayende says is when you already have a mental model of the transformation that you want to perform, the compiler can do the work of showing you the bits you need to edit to finalize the transformation. This process isn't mindless; because you've informed the type system about the substructure of your code, when you want to change the shape of that substructure, the compiler is then able to tell you exactly where it is now inconsistent. Whereas with dynamically typed code, you need unit tests with 100% path coverage (line coverage isn't enough) to guarantee that you caught every interaction, if you were to approach the change in the same way. (As an aside: that's a whole lot of tests that need rewriting and refactoring, one reason I don't like unit testing for very early stages of a project when the design is quite fluid.) The alternative is eyeballing the code and perhaps getting a runtime type violation or two before all the locations are gotten right. Note that here I'm only talking about finding the locations to modify, not about guaranteeing that the modifications are correct. If the structural change is simple, where all the in-place modifications are trivial, having a static type system that tells you about all the locations is really handy, whereas you need to do a lot more work with a dynamic type system. IMO the benefits of a dynamic type system are more apparent when the systems you're working with are themselves dynamic and (relatively) quickly changing in nature, or when the substructure is too tedious to efficiently express in a static type system (especially apparent with mutually recursive generic types with dependencies among type parameters, like you might find in generic parsing and graph transformation libraries, etc.).

andywood 16y ago

I think that you, InclinedPlane, and BoppreH are missing the point, while cautioning against a strawman. It is elementary that successful compilation does not imply correct code; but that is not what Ayende is talking about at all. There are specific, disciplined ways in which you can use the compiler to reliably tell you what you need to fix when making certain kinds of changes. Such techniques are very valuable in large codebases. For example, you change the semantics of an interface method slightly, and this results in changing the type of the return value, or the arguments. After changing the method signature in the interface, the compiler tells you exactly where you need to make corresponding changes in the rest of your large codebase. Naturally, it can't tell you exactly what changes to make - for that you use your brain. But it tells you exactly where you need to make changes, and gives a good general idea of what changes to make. That's the kind of technique this post is talking about. Whether you intend it or not, dismissing effective use of such powerful tools as "confusing compilation with correctness" is both misleading, and kind of insulting to users of strongly typed languages who know what they're doing.