3 ms·

> What languages exist that are hard to write bad code in? A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code,

> What languages exist that are hard to write bad code in? A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code, because it eliminates a large class of potentially "bad" programs, and thus provides guarantees about the code that does type check. If I have an arbitrary Haskell program, it might still be messy and hard to read, but I know I'll have certain guarantees about the code. For example, if a function isn't in IO, it won't have any effects, and a replacing it with a function that returns the same values for the same arguments will be safe. Additionally, the language makes it easy for libraries to have well designed APIs, that ensure that the user doesn't forget to make the required checks. For example, removing null, and forcing Option/Maybe for functions that might fail forces the the caller to handle the failure case, instead of just forgetting to check for null, which is common.

vlovich123 6y ago
If they don’t have bad code it’s because it’s a bunch of enthusiasts that are good at coding. Realistically I’m sure there’s even now examples of code that would be considered “bad” in any of those languages.
- webgoat 6y ago
  It's more the fact that these languages force certain best practices using their compiler. While python can be great when used in best practice, its level of freedom make it easy for the user to get away with obvious mistakes. It's great to have freedom like that when you're writing small projects, but a large project could lead to unintended effects that cause more damaging issues than the time lost using a stricter language.
  - vlovich123 6y ago
    That’s all great in principle, but is there any evidence to support this claim? Certain properties are of course enforced so it’s impossible for a project to do certain things that make the code harder to read. On the other hand, humans are so creative that I have a hard time imagining that, given time and a wider mix of talent, you’ll still have code hygiene issues. Maybe not the exact problems that another language might have, but certainly your own flavor will be developed as developers have less contact with the core language enthusiasts that establish said best-practices.. Again, happy to be proven wrong but I’d like at least anecdotes or some kind of evidence rather than a theoretical argument from first principles that completely ignores the human element.
deleted 6y ago
[deleted]
holri 6y ago
> and a replacing it with a function that returns the same values for the same arguments will be safe No. That is only safe at compile time but not at runtime. Because the type alone often does not guarantee the meaning and semantics of the values in the specific context and program are the same.
- Asraelite 6y ago
  I'm not sure I get the argument here. So long as the input-output mapping for the function is identical, it cannot change the benavior of the program. This is what I would consider safe. The semantics of values are irrelevant because the function will behave identically regardless of those semantics.
  - holri 6y ago
    This only true if the type describes the whole meaning of the values. If the exit code of a unix program changes from 0 to 1 it still returns an int, but the meaning of that value is completely different one.
    - Asraelite 6y ago
      But the exit code can't change from 0 to 1. For any given input to the Unix program, if the output was 0 with one implementation, then it would always remain 0 with any other _equivalent_ implementation. This is literally what is meant by "returns the same values for the same arguments". Any function that fits this description, by definition, cannot suffer from the problem you are describing.
insertnickname 6y ago
>A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code, Maybe they wouldn't be writing any code if they had to write it in a languages like that.
bollu 6y ago
In a world where unsafePerformIO, error, etc don't exist, sure. The reason most Haskell codebases are cleaner is because the culture manages to uniquely emphasize good practices such that people don't try to break abstraction barriers. I'm sure it's possible to write Haskell code that "misbehaves" as much as python code does. Once smart people with no training are let loose on something, that'll definitely happen. We're lucky that Haskell hasn't been attacked yet :)
eesmith 6y ago
Words like "any effects" and "safe" have broader meanings than the way they are used in type systems. I ask that you be a bit more precise in your advocacy. I can replace a sorting method having O(N log N) time with one having O(N^2) time, without changing the type. But it will certainly have an effect on my system, and if the run-time is too long, may result in an unsafe system (eg, in a real-time control system which requires a maximum response time). While I know what you mean, "bad code" includes things like unacceptable performance. I also find it hard to understand how to apply type systems to algorithms. What is the type of an algorithm which returns a graph diameter, and how does it differ from one returning the graph eccentricity or other graph property? (That's where "same values for the same arguments" comes in, but that's that hard part of the problem, yes?)

vlovich123 6y ago

If they don’t have bad code it’s because it’s a bunch of enthusiasts that are good at coding. Realistically I’m sure there’s even now examples of code that would be considered “bad” in any of those languages.

webgoat 6y ago
It's more the fact that these languages force certain best practices using their compiler. While python can be great when used in best practice, its level of freedom make it easy for the user to get away with obvious mistakes. It's great to have freedom like that when you're writing small projects, but a large project could lead to unintended effects that cause more damaging issues than the time lost using a stricter language.
- vlovich123 6y ago
  That’s all great in principle, but is there any evidence to support this claim? Certain properties are of course enforced so it’s impossible for a project to do certain things that make the code harder to read. On the other hand, humans are so creative that I have a hard time imagining that, given time and a wider mix of talent, you’ll still have code hygiene issues. Maybe not the exact problems that another language might have, but certainly your own flavor will be developed as developers have less contact with the core language enthusiasts that establish said best-practices.. Again, happy to be proven wrong but I’d like at least anecdotes or some kind of evidence rather than a theoretical argument from first principles that completely ignores the human element.

deleted 6y ago

[deleted]

holri 6y ago

> and a replacing it with a function that returns the same values for the same arguments will be safe No. That is only safe at compile time but not at runtime. Because the type alone often does not guarantee the meaning and semantics of the values in the specific context and program are the same.

Asraelite 6y ago
I'm not sure I get the argument here. So long as the input-output mapping for the function is identical, it cannot change the benavior of the program. This is what I would consider safe. The semantics of values are irrelevant because the function will behave identically regardless of those semantics.
- holri 6y ago
  This only true if the type describes the whole meaning of the values. If the exit code of a unix program changes from 0 to 1 it still returns an int, but the meaning of that value is completely different one.
  - Asraelite 6y ago
    But the exit code can't change from 0 to 1. For any given input to the Unix program, if the output was 0 with one implementation, then it would always remain 0 with any other _equivalent_ implementation. This is literally what is meant by "returns the same values for the same arguments". Any function that fits this description, by definition, cannot suffer from the problem you are describing.

insertnickname 6y ago

>A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code, Maybe they wouldn't be writing any code if they had to write it in a languages like that.

bollu 6y ago

In a world where unsafePerformIO, error, etc don't exist, sure. The reason most Haskell codebases are cleaner is because the culture manages to uniquely emphasize good practices such that people don't try to break abstraction barriers. I'm sure it's possible to write Haskell code that "misbehaves" as much as python code does. Once smart people with no training are let loose on something, that'll definitely happen. We're lucky that Haskell hasn't been attacked yet :)

eesmith 6y ago

Words like "any effects" and "safe" have broader meanings than the way they are used in type systems. I ask that you be a bit more precise in your advocacy. I can replace a sorting method having O(N log N) time with one having O(N^2) time, without changing the type. But it will certainly have an effect on my system, and if the run-time is too long, may result in an unsafe system (eg, in a real-time control system which requires a maximum response time). While I know what you mean, "bad code" includes things like unacceptable performance. I also find it hard to understand how to apply type systems to algorithms. What is the type of an algorithm which returns a graph diameter, and how does it differ from one returning the graph eccentricity or other graph property? (That's where "same values for the same arguments" comes in, but that's that hard part of the problem, yes?)