Hacker News Reader

Comment by superobserver | Hacker News Reader

> 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++).

View on HN

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.

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

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.

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.

> 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.

> 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.)

> 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.)

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.

> 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

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.

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?

Depends on if you're trying to engineer fault-tolerant, robust systems, or trying to learn how to program.

Quite right. I was only mentioning it w.r.t. actual learning, not a more general use case. :/

> 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.

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.

Reply on news.ycombinator.com