4 ms·

> But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, i

> But if you're writing a 10-line program and you forget one of the lines (or even one character), the program isn't 10% wrong, it's 100% wrong. (For example, instead of compiling and running correctly, it doesn't compile at all. Completely different results.) This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++).

nsomaru 12y ago
I'd rather know when something is incorrect, rather than pushing to production and finding out later because someone else took that code path.
- DougWebb 12y ago
  If you rely on your compiler to tell you that your code is correct, there are whole classes of bugs that are waiting to surprise you in production. I think that many years of developing large applications in Perl were really good for me. Perl is compiled when you run it, so you get the basic-syntax check that you get with other languages. But it's also very lenient, so you learn through experience to get your logic right, test return values, and do all of the things that help make sure that a program which executes is executing correctly.
  - brianwawok 12y ago
    There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.
    - DougWebb 12y ago
      I agree with you on all points, but the parent sounded like he was relying on the compile-time checks to determine correctness. I was making the point that that is a bad idea.
    - pdonis 12y ago
      > Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. I'm not sure I agree. "Work correctly" does not just mean "compile correctly". I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted. I agree that neither is ideal and that adding testing can improve any code.
      - dragonwriter 12y ago
        > I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted. As certain assertions related to logic can be encoded into static types (especially in a language with a type system more like Haskell's than, say, Go's), while static typing can't eliminate all logic errors, it can reduce the probability of logic errors escaping detection in the absence of testing, since compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.)
        pdonis 12y ago
        > compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.) Fair point. (Especially if, as you say, you are using a language with a type system like Haskell's, which to me is more like a program analysis engine than just a type system.)
amirmc 12y ago
This is a risk that you should be aware of when using languages like this and thus use them appropriately. To continue with the building analogy, you don't want it to take an actual fire to learn that all your fire exits are dead-ends.
wil421 12y ago
Wouldn't it be better to catch an error at compile time than throw an exception or have the app completely fail when a bad piece of code is run?
- bcbrown 12y ago
  Depends on if you're trying to engineer fault-tolerant, robust systems, or trying to learn how to program.
  - superobserver 12y ago
    Quite right. I was only mentioning it w.r.t. actual learning, not a more general use case. :/
wyager 12y ago
>This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. That's not beautiful; that's horrendous. A program that might contain syntactic (!) errors has no claim to being a sublime mathematical construct. I'd say it's "beautifully simple" when I can tell you with 100% confidence that my program will never, ever, ever experience errors of a certain type. Even better if I can tell you with 100% confidence that my program contains no errors at all (which is possible with proof-based languages). Saying a Python program is beautiful because it can have hidden failure conditions is like saying that a poorly maintained gun is beautiful because it can fire when rusty (but watch out for explosions!). I wish, when learning to program, that I'd been taught to write universally correct code instead of "mostly correct" code.
isaacremuant 12y ago
> This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++). Actually, that's one of the pitfalls of interpreted languages. You want to Crash Early & Crash Often [1] or you'll move along, merrily ignorant of a serious problem just because it doesn't get executed. I try to solve this shortcoming of languages like Python with proper unit testing. It gives me the confidence that there's a decent coverage of the different code paths so that I won't learn about the problem in production. [1] - https://pragprog.com/the-pragmatic-programmer/extracts/tips https://pragprog.com/the-pragmatic-programmer/extracts/tips
4ydx 12y ago
Unfortunately this is a dark hole of horrible bugs just waiting to happen not to mention the fact that interpreted languages are very liberal with silent type conversion. It is a nightmare to deal with in a large system written by careless programmers.
kruczek 12y ago
> This is where the beauty/simplicity of some programming languages Simplicity? Yes, probably (at least as long as I am writing the code and not debugging it). But definitely not beauty. I find this particular behaviour the ugliest part of interpreted languages. I may make a small typo, incorrectly capitalize variable name or forget a quote and nothing will tell me that my code is wrong or where exactly it is wrong - it will silently skip the error and happily show me wrong results.

nsomaru 12y ago

I'd rather know when something is incorrect, rather than pushing to production and finding out later because someone else took that code path.

DougWebb 12y ago
If you rely on your compiler to tell you that your code is correct, there are whole classes of bugs that are waiting to surprise you in production. I think that many years of developing large applications in Perl were really good for me. Perl is compiled when you run it, so you get the basic-syntax check that you get with other languages. But it's also very lenient, so you learn through experience to get your logic right, test return values, and do all of the things that help make sure that a program which executes is executing correctly.
- brianwawok 12y ago
  There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.
  - DougWebb 12y ago
    I agree with you on all points, but the parent sounded like he was relying on the compile-time checks to determine correctness. I was making the point that that is a bad idea.
  - pdonis 12y ago
    > Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. I'm not sure I agree. "Work correctly" does not just mean "compile correctly". I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted. I agree that neither is ideal and that adding testing can improve any code.
    - dragonwriter 12y ago
      > I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted. As certain assertions related to logic can be encoded into static types (especially in a language with a type system more like Haskell's than, say, Go's), while static typing can't eliminate all logic errors, it can reduce the probability of logic errors escaping detection in the absence of testing, since compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.)
      - pdonis 12y ago
        > compiling a statically typed program is, in effect, a form of testing (limited to those assertions about behavior which can be encoded into the type system.) Fair point. (Especially if, as you say, you are using a language with a type system like Haskell's, which to me is more like a program analysis engine than just a type system.)

amirmc 12y ago

This is a risk that you should be aware of when using languages like this and thus use them appropriately. To continue with the building analogy, you don't want it to take an actual fire to learn that all your fire exits are dead-ends.

wil421 12y ago

Wouldn't it be better to catch an error at compile time than throw an exception or have the app completely fail when a bad piece of code is run?

bcbrown 12y ago
Depends on if you're trying to engineer fault-tolerant, robust systems, or trying to learn how to program.
- superobserver 12y ago
  Quite right. I was only mentioning it w.r.t. actual learning, not a more general use case. :/

wyager 12y ago

>This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. That's not beautiful; that's horrendous. A program that might contain syntactic (!) errors has no claim to being a sublime mathematical construct. I'd say it's "beautifully simple" when I can tell you with 100% confidence that my program will never, ever, ever experience errors of a certain type. Even better if I can tell you with 100% confidence that my program contains no errors at all (which is possible with proof-based languages). Saying a Python program is beautiful because it can have hidden failure conditions is like saying that a poorly maintained gun is beautiful because it can fire when rusty (but watch out for explosions!). I wish, when learning to program, that I'd been taught to write universally correct code instead of "mostly correct" code.

isaacremuant 12y ago

> This is where the beauty/simplicity of some programming languages, namely, intepreted languages (e.g., Python), comes in: if a bad line of code never gets executed, then the program itself will run fine. In other words, if the line is never called in the program, then you'll not know that the functionality that that line presented was bad. In this case, the analogy breaks down a bit - and also shows why certain languages are easier to learn than others (e.g., Python vs. C++). Actually, that's one of the pitfalls of interpreted languages. You want to Crash Early & Crash Often [1] or you'll move along, merrily ignorant of a serious problem just because it doesn't get executed. I try to solve this shortcoming of languages like Python with proper unit testing. It gives me the confidence that there's a decent coverage of the different code paths so that I won't learn about the problem in production. [1] - https://pragprog.com/the-pragmatic-programmer/extracts/tips https://pragprog.com/the-pragmatic-programmer/extracts/tips

4ydx 12y ago

Unfortunately this is a dark hole of horrible bugs just waiting to happen not to mention the fact that interpreted languages are very liberal with silent type conversion. It is a nightmare to deal with in a large system written by careless programmers.

kruczek 12y ago

> This is where the beauty/simplicity of some programming languages Simplicity? Yes, probably (at least as long as I am writing the code and not debugging it). But definitely not beauty. I find this particular behaviour the ugliest part of interpreted languages. I may make a small typo, incorrectly capitalize variable name or forget a quote and nothing will tell me that my code is wrong or where exactly it is wrong - it will silently skip the error and happily show me wrong results.