7 ms·

I like strong typing and compilation errors

18 points by rayvega 16y ago

BoppreH 16y ago
I find it rather risky to change something and expect compilers to catch all the errors. Anyway, the non-typed languages I use tell me the line of code where the error occurred. Isn't that equivalent in this case?
- ori_b 16y ago
  No; The line has to be executed for the error to show up in a dynamic language. Think of types as logical propositions, and type systems as theorem provers. The stricter and more powerful the type system, the more exact and precise the proof will be, and the more you can be guaranteed that things won't go wrong.
  - BoppreH 16y ago
    Of course it has to be executed, but it's either something that you are going to execute yourself (as in pushing a button) or at least you are making an easy way to trigger this function. If you are testing such code you make sure to run it. I understand that strict typing works by guaranteeing some things won't go wrong, but I can't see many meaningful situations where it wouldn't generate a runtime error in a scripted language, or at least results that make the source of the error painfully obvious.
    - wvenable 16y ago
      > If you are testing such code you make sure to run it. Ahh, but that's not the problem. It's easy to test the code your changing, it's a much harder problem to find and test all the code that depends on that code. Having the compiler spit out every instance everywhere that you need to fix due to a new type-mismatch makes this significantly easier. Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later.
      - gte910h 16y ago
        >Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later. This happens with algol style static languages too (And is one of the reasons I find people arguing for Erlang instead of python more persuasive than those instead arguing C++ instead of ruby). You are confusing strong types with dynamic variables. Most of the algol languages have weak to medium type strength. For instance, python has much stronger types than C. However, it's variables are all dynamic references.
    - AndrewDucker 16y ago
      I work with systems with hundreds of thousands of lines of code. We try to check everything, and we have decent unit test coverage, but there are bound to be places we don't hit instantly - and running the tests takes longer than compiling does.
  - alec 16y ago
    "No; The line has to be executed for the error to show up in a dynamic language." That may be true for some dynamic languages with primitive tools and implementations, but is not inherent in dynamic languages. For example, SBCL will alert me to branches that are impossible to take, adding strings and numbers, and even more if I've specified types (which is optional). As an added bonus, if I'm using SLIME in emacs, the s-expressions in question will be highlighted with a note. Factor and Scheme will perform similar tricks, and there's even Typed Scheme, which lets you convert your dynamically-typed code to statically-typed code incrementally.
    - ori_b 16y ago
      That's a form of static typing (via type inference)
  - gte910h 16y ago
    >No; The line has to be executed for the error to show up in a dynamic language. This is a common misperception: http://pychecker.sourceforge.net/ http://pychecker.sourceforge.net/ http://www.logilab.org/857 http://www.logilab.org/857 (pylint) http://www.jslint.com/ http://www.jslint.com/ And to head off the common "But but but it's not the compiler", I contend you're doing something wrong if you're not also running lint against a C program, as C compilers do not catch tons of things that people do wrong, but lint does. Both types of languages have common type errors. Some can only be caught at runtime in both, but some sorts of errors (signature errors), static type checkers can catch them. I work in both types of languages. In the amount of time I spend fiddling with type system stuff in objective C, I could write 2 test harness classes in python, and happily would. Now if you're talking Erlang, et al, then we can talk about static type systems. But for the algol languages, I don't think they have all the benefits of a strong, static type system that outweigh the productivity of dynamism. If you use docstrings, doctests, etc, you can find quite a nice enterprise coding language in there. Remember dynamic are more expressive (by definition almost)than static languages per line of code. So that 20k Line java/C# program is something like 3-13k lines of python or 2-9k lines of ruby. The dominant reason to use static languages usually has little to do with their static nature with regards to errors: They are often faster at execution time. Also, they tend to have cheaper programmers. Both of these often dominate any code quality issues. I personally advocate mixed language situations (like python weave) for most situations like that so inner loops can get the speed of C, and the rest gets the development speed of a dynamic language.
- barrkel 16y ago
  It's not about catching errors, but showing which locations to be modified. It's an aid to code editing, not a proof of correctness.
InclinedPlane 16y ago
If you rest on the premise that merely because your program compiles it is also correct then you will face a career full of frustration and mediocrity.
- darrenkopp 16y ago
  That's not the premise he's making. He's saying it's more convenient. Also, I would think twice before referencing ayende and using the phrase "...[ayende] will face a career full of frustration and mediocrity."
  - InclinedPlane 16y ago
    I don't doubt that this is just one tiny aspect of Ayende's development practices, and in that context it's not necessarily even bad practice. The problem I have with Ayende's statement is that it can seem like advice, and there are a huge number of inexperienced developers for which that advice is incredibly dangerous outside of the proper context.
colonelxc 16y ago
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.
pw0ncakes 16y ago
Strong static typing is great. You can cut your runtime bug count by 70-80% easily if you know what you're doing, which provides an enormous increase in productivity. Also, type discipline seems to lead naturally to better architecture. You have to build your data structures and functions from the ground up, which tends to kill a lot of the sloppy thinking and nonexistent architecture that you sometimes see in the dynamically-typed world (although this can't be blamed on the languages, because a lot of users of such languages write great code). Dynamic typing wins on prototypes and small projects, but for a project of more than 2000 lines, I'd be hard-pressed to see a case where dynamic typing wins. Of course, I'll add the caveat that good dynamic typing is essential. Most people think dynamic pwns static because they're most familiar with Java and Python, but Java has shitty static typing (you have to declare types, and moreover end up needing to subvert the type system to do anything interesting) whereas ML and Haskell have awesome type systems.
- derefr 16y ago
  > but for a project of more than 2000 lines, I'd be hard-pressed to see a case where dynamic typing wins Would "the game-world model for a MUD/MOO" be a cheap shot?
  - pw0ncakes 16y ago
    Explain. Large projects are certainly doable in dynamically-typed languages. I just think that static typing becomes a win once you have: * enough code that internal interfaces become important, * enough code that at least 30% of time is spent debugging, and: * more than one programmer on the project by necessity.
    - derefr 16y ago
      In the world model popular in a http://en.wikipedia.org/wiki/MOO http://en.wikipedia.org/wiki/MOO, almost every object has its own unique set of "verbs" (methods), which each destructively update the world in manifold unpredictable ways. There are no real "classes" of objects, per se, as having more than one of a world object that acts in exactly the same way ruins its "mystique" or "sense of fun"; instead, objects are created first through prototypical inheritance (cloning), and then by defining singleton methods (and adding mix-ins composed thereof), each of which may have originated within any other object. Objects survive mostly by memetic transmission (see an object you like, retain a clone for yourself) rather than some sort of unified architecture.
gruseom 16y ago
People tend to pick one side or the other of this issue and then argue for it. It's rare for anyone to change their mind, and even when they do, it's usually just a boolean toggle to the opposite position. Most people believe (even if they don't say it) that the opposite camp is, basically, stupider. The entire subject is remarkably evidence-free. That's surprising; you'd think (on the surface, at least) that it could be studied objectively. Of course, we all have our individual experiences as programmers, but those aren't worth much as evidence, because we interpret our experiences to suit our pre-existing belief. Indeed, we don't even notice experiences that contradict it. (I've seen static typing proponents go on about how compilers catch bugs and then spend hours tracking down an InvalidCastException.) In light of the above, I'm more interested in hearing what people have to say in favor of the position they disagree with. The debate is too tiresome otherwise, entirely predictable. Although I currently favor dynamic languages, I recently started the thought experiment of asking myself, when fixing a bug, whether a good type system would have caught it. Certainly there are times that the answer is yes (though not always). The difficulty, of course, is whether the aggregate benefit would outweigh the cost.
- strait 16y ago
  That the subject is remarkably evidence-free reflects on the evolution of computing technology that's cascaded all the way up to the way we program at the highest level. We're so adept at noticing the differences between static typing and dynamic typing, but evaluating them much more objectively inside the entire computing environment context is like comparing two heaps of random trash and trying to decide which pile makes the best art piece. How is that for an evidence-free assessment? :)
- gstamp 16y ago
  The problem is obtaining this evidence is really hard. So many considerations are involved during the coding of a non-trivial system. It's hard to isolate all factors involved. I remember code complete presenting some evidence that 100-200 line functions are the best size but how true is that really? What consideration does language have on that? Most people these days would see that functions that size as way too long.
- 16y ago
btilly 16y ago
I don't see the need for the invasive change. Given the problem that he had I would have written a new function that returned the more complex data structure, converted the old function into a wrapper around the new one, then called the new function in my new code. Much simpler. Much safer. Much less chance of breaking existing code. (Decent unit tests could help verify this.) And you avoid duplication of logic. If I wished to convert existing code to use the new function, I could do that at my leisure. Furthermore if someone happens to be developing code in another branch or at another site which expects the old function to be there, I don't break them.
- AndrewDucker 16y ago
  If you're refactoring a lot then your method leaves you with huge amounts of extra code, which makes maintainability much harder, because you've got multiple levels of indirection.
  - btilly 16y ago
    If even your internal modules are clearly separated into public interfaces and internal stuff, then most refactorings won't need that level of care.

18 points by rayvega 16y ago

I find it rather risky to change something and expect compilers to catch all the errors. Anyway, the non-typed languages I use tell me the line of code where the error occurred. Isn't that equivalent in this case?

ori_b 16y ago
No; The line has to be executed for the error to show up in a dynamic language. Think of types as logical propositions, and type systems as theorem provers. The stricter and more powerful the type system, the more exact and precise the proof will be, and the more you can be guaranteed that things won't go wrong.
- BoppreH 16y ago
  Of course it has to be executed, but it's either something that you are going to execute yourself (as in pushing a button) or at least you are making an easy way to trigger this function. If you are testing such code you make sure to run it. I understand that strict typing works by guaranteeing some things won't go wrong, but I can't see many meaningful situations where it wouldn't generate a runtime error in a scripted language, or at least results that make the source of the error painfully obvious.
  - wvenable 16y ago
    > If you are testing such code you make sure to run it. Ahh, but that's not the problem. It's easy to test the code your changing, it's a much harder problem to find and test all the code that depends on that code. Having the compiler spit out every instance everywhere that you need to fix due to a new type-mismatch makes this significantly easier. Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later.
    - gte910h 16y ago
      >Some dynamic languages will happily convert values from one type to another even when that's not the desired result -- you might not get an error at all, just some bad data you might not find until much later. This happens with algol style static languages too (And is one of the reasons I find people arguing for Erlang instead of python more persuasive than those instead arguing C++ instead of ruby). You are confusing strong types with dynamic variables. Most of the algol languages have weak to medium type strength. For instance, python has much stronger types than C. However, it's variables are all dynamic references.
  - AndrewDucker 16y ago
    I work with systems with hundreds of thousands of lines of code. We try to check everything, and we have decent unit test coverage, but there are bound to be places we don't hit instantly - and running the tests takes longer than compiling does.
- alec 16y ago
  "No; The line has to be executed for the error to show up in a dynamic language." That may be true for some dynamic languages with primitive tools and implementations, but is not inherent in dynamic languages. For example, SBCL will alert me to branches that are impossible to take, adding strings and numbers, and even more if I've specified types (which is optional). As an added bonus, if I'm using SLIME in emacs, the s-expressions in question will be highlighted with a note. Factor and Scheme will perform similar tricks, and there's even Typed Scheme, which lets you convert your dynamically-typed code to statically-typed code incrementally.
  - ori_b 16y ago
    That's a form of static typing (via type inference)
- gte910h 16y ago
  >No; The line has to be executed for the error to show up in a dynamic language. This is a common misperception: http://pychecker.sourceforge.net/ http://pychecker.sourceforge.net/ http://www.logilab.org/857 http://www.logilab.org/857 (pylint) http://www.jslint.com/ http://www.jslint.com/ And to head off the common "But but but it's not the compiler", I contend you're doing something wrong if you're not also running lint against a C program, as C compilers do not catch tons of things that people do wrong, but lint does. Both types of languages have common type errors. Some can only be caught at runtime in both, but some sorts of errors (signature errors), static type checkers can catch them. I work in both types of languages. In the amount of time I spend fiddling with type system stuff in objective C, I could write 2 test harness classes in python, and happily would. Now if you're talking Erlang, et al, then we can talk about static type systems. But for the algol languages, I don't think they have all the benefits of a strong, static type system that outweigh the productivity of dynamism. If you use docstrings, doctests, etc, you can find quite a nice enterprise coding language in there. Remember dynamic are more expressive (by definition almost)than static languages per line of code. So that 20k Line java/C# program is something like 3-13k lines of python or 2-9k lines of ruby. The dominant reason to use static languages usually has little to do with their static nature with regards to errors: They are often faster at execution time. Also, they tend to have cheaper programmers. Both of these often dominate any code quality issues. I personally advocate mixed language situations (like python weave) for most situations like that so inner loops can get the speed of C, and the rest gets the development speed of a dynamic language.
barrkel 16y ago
It's not about catching errors, but showing which locations to be modified. It's an aid to code editing, not a proof of correctness.

InclinedPlane 16y ago

If you rest on the premise that merely because your program compiles it is also correct then you will face a career full of frustration and mediocrity.

darrenkopp 16y ago
That's not the premise he's making. He's saying it's more convenient. Also, I would think twice before referencing ayende and using the phrase "...[ayende] will face a career full of frustration and mediocrity."
- InclinedPlane 16y ago
  I don't doubt that this is just one tiny aspect of Ayende's development practices, and in that context it's not necessarily even bad practice. The problem I have with Ayende's statement is that it can seem like advice, and there are a huge number of inexperienced developers for which that advice is incredibly dangerous outside of the proper context.

colonelxc 16y ago

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.

pw0ncakes 16y ago

Strong static typing is great. You can cut your runtime bug count by 70-80% easily if you know what you're doing, which provides an enormous increase in productivity. Also, type discipline seems to lead naturally to better architecture. You have to build your data structures and functions from the ground up, which tends to kill a lot of the sloppy thinking and nonexistent architecture that you sometimes see in the dynamically-typed world (although this can't be blamed on the languages, because a lot of users of such languages write great code). Dynamic typing wins on prototypes and small projects, but for a project of more than 2000 lines, I'd be hard-pressed to see a case where dynamic typing wins. Of course, I'll add the caveat that good dynamic typing is essential. Most people think dynamic pwns static because they're most familiar with Java and Python, but Java has shitty static typing (you have to declare types, and moreover end up needing to subvert the type system to do anything interesting) whereas ML and Haskell have awesome type systems.

derefr 16y ago
> but for a project of more than 2000 lines, I'd be hard-pressed to see a case where dynamic typing wins Would "the game-world model for a MUD/MOO" be a cheap shot?
- pw0ncakes 16y ago
  Explain. Large projects are certainly doable in dynamically-typed languages. I just think that static typing becomes a win once you have: * enough code that internal interfaces become important, * enough code that at least 30% of time is spent debugging, and: * more than one programmer on the project by necessity.
  - derefr 16y ago
    In the world model popular in a http://en.wikipedia.org/wiki/MOO http://en.wikipedia.org/wiki/MOO, almost every object has its own unique set of "verbs" (methods), which each destructively update the world in manifold unpredictable ways. There are no real "classes" of objects, per se, as having more than one of a world object that acts in exactly the same way ruins its "mystique" or "sense of fun"; instead, objects are created first through prototypical inheritance (cloning), and then by defining singleton methods (and adding mix-ins composed thereof), each of which may have originated within any other object. Objects survive mostly by memetic transmission (see an object you like, retain a clone for yourself) rather than some sort of unified architecture.

gruseom 16y ago

People tend to pick one side or the other of this issue and then argue for it. It's rare for anyone to change their mind, and even when they do, it's usually just a boolean toggle to the opposite position. Most people believe (even if they don't say it) that the opposite camp is, basically, stupider. The entire subject is remarkably evidence-free. That's surprising; you'd think (on the surface, at least) that it could be studied objectively. Of course, we all have our individual experiences as programmers, but those aren't worth much as evidence, because we interpret our experiences to suit our pre-existing belief. Indeed, we don't even notice experiences that contradict it. (I've seen static typing proponents go on about how compilers catch bugs and then spend hours tracking down an InvalidCastException.) In light of the above, I'm more interested in hearing what people have to say in favor of the position they disagree with. The debate is too tiresome otherwise, entirely predictable. Although I currently favor dynamic languages, I recently started the thought experiment of asking myself, when fixing a bug, whether a good type system would have caught it. Certainly there are times that the answer is yes (though not always). The difficulty, of course, is whether the aggregate benefit would outweigh the cost.

strait 16y ago
That the subject is remarkably evidence-free reflects on the evolution of computing technology that's cascaded all the way up to the way we program at the highest level. We're so adept at noticing the differences between static typing and dynamic typing, but evaluating them much more objectively inside the entire computing environment context is like comparing two heaps of random trash and trying to decide which pile makes the best art piece. How is that for an evidence-free assessment? :)
gstamp 16y ago
The problem is obtaining this evidence is really hard. So many considerations are involved during the coding of a non-trivial system. It's hard to isolate all factors involved. I remember code complete presenting some evidence that 100-200 line functions are the best size but how true is that really? What consideration does language have on that? Most people these days would see that functions that size as way too long.
16y ago

btilly 16y ago

I don't see the need for the invasive change. Given the problem that he had I would have written a new function that returned the more complex data structure, converted the old function into a wrapper around the new one, then called the new function in my new code. Much simpler. Much safer. Much less chance of breaking existing code. (Decent unit tests could help verify this.) And you avoid duplication of logic. If I wished to convert existing code to use the new function, I could do that at my leisure. Furthermore if someone happens to be developing code in another branch or at another site which expects the old function to be there, I don't break them.

AndrewDucker 16y ago
If you're refactoring a lot then your method leaves you with huge amounts of extra code, which makes maintainability much harder, because you've got multiple levels of indirection.
- btilly 16y ago
  If even your internal modules are clearly separated into public interfaces and internal stuff, then most refactorings won't need that level of care.