4 ms·

It’s an optimisation problem. Both classes of people, at a fundamental level, want shit to get done. It’s a question of whether you want it done right (for some

It’s an optimisation problem. Both classes of people, at a fundamental level, want shit to get done. It’s a question of whether you want it done right (for some definition of “right”) or whether you want it done now. Most of the time, there’s a balance to be struck in the tool you choose—if we did it in Haskell or OCaml or Scala, it’d probably be more correct and easier to maintain in the long run; but we are a startup that is likely going to run out of funding in a month or two, and if we hack it together in Ruby or Python or Node then no one will fault us and we can rewrite it in a good language later if we have the budget of time and money. So while Haskell might be my primary language at work and play—and I see the tremendous value it holds for experienced developers—when beginners ask me what language they should learn, I invariably say: “Java”. At this point, it’s the essence of mediocrity, the dead middle of the bell curve; you can go better or worse from there.

RyanZAG 13y ago
Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving. For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'. Not that I've ever seen any real numbers which is a big problem when making statements like that.
- mercurial 13y ago
  > Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving. While I don't have actual proof of anything (and I doubt parent has either), removing classes of issues is a big win. Not to say that any of the three languages you list is a silver bullet, they all come with a long list of drawbacks. You just have to pick which drawbacks you dislike the least. > For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'. What do you mean by this? If your types are fine-grained enough (which you can absolutely do in Java, at the cost of a lot more code), and you change your specification, you will need to change your types. But if you did not have fine-grained types (in any language), you're going to be fixing errors at runtime instead. If you're not going to leverage the type system, you may as well work with Python, you'll get the same effect with a lot less code.
  - RyanZAG 13y ago
    If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly. If it was something like javascript, you'd just add the new information somewhere and it would be passed through without changes to where you'd need it. Making a statement like 'Haskell is easier to maintain' doesn't seem to ring true in this case. If you have unit tests for both your Haskell and javascript code then they should both be equally correct after the change. Now maybe Haskell really would be easier to maintain - but it's something that needs proof and hard evidence. To use a car analogy for the GP's post, "I could buy a Ford because it is safer and easier to repair, but sometimes I'd just buy a Chrysler because it's cheaper and easier to purchase". There's nothing wrong with this statement if you have real numbers on the two different cars - but making the statement based on some kind of assumptions on what you think the two languages will or won't do is pure folly. If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.
    - mercurial 13y ago
      > If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly. It depends on what you do. If you (say) add a new field to an existing type, this will screw up pattern matching. It's a bit inconvenient, but typically not a big deal. On the other hand, if your previously non-nullable String field becomes a Maybe String, you're going to have to update every location where you access it... and that's exactly what a reasonable programmer wants to do. Unfortunately, you can't encode this in Javascript, so you're going to resort to 'grep' (good luck if you have the same field name for several objects), or forget about it and get runtime errors. Sure, in theory you can rely on your Javascript unit tests to detect the error, and you may be right in practice, or you may be out of luck. Generally speaking, Haskell has its fair share of problems, but it's not one of them. > If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. It definitely matches my own experience (it obviously depends on your proficiency in both languages, and Haskell will have only marginal advantages if you use String everywhere because types are hard). > He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself. It's the kind of thing for which it is extremely hard to get any evidence for (and not only in Haskell vs Javascript debates), for obvious reasons. The best you can say is that the stronger guarantees of correctness offered by a strongly-typed program ensure that it makes it much easier to detect regressions. On the other hand, if, say, there are no third-party libraries for the problem domain at hand, strong typing will not magically fix that.

RyanZAG 13y ago

Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving. For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'. Not that I've ever seen any real numbers which is a big problem when making statements like that.

mercurial 13y ago
> Just curious if you have any actual proof that Haskell or OCaml or Scala would really be more correct or easier to maintain than the other languages you mentioned? It feels like the kind of statement that really does need hard proof and not just hand waving. While I don't have actual proof of anything (and I doubt parent has either), removing classes of issues is a big win. Not to say that any of the three languages you list is a silver bullet, they all come with a long list of drawbacks. You just have to pick which drawbacks you dislike the least. > For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'. What do you mean by this? If your types are fine-grained enough (which you can absolutely do in Java, at the cost of a lot more code), and you change your specification, you will need to change your types. But if you did not have fine-grained types (in any language), you're going to be fixing errors at runtime instead. If you're not going to leverage the type system, you may as well work with Python, you'll get the same effect with a lot less code.
- RyanZAG 13y ago
  If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly. If it was something like javascript, you'd just add the new information somewhere and it would be passed through without changes to where you'd need it. Making a statement like 'Haskell is easier to maintain' doesn't seem to ring true in this case. If you have unit tests for both your Haskell and javascript code then they should both be equally correct after the change. Now maybe Haskell really would be easier to maintain - but it's something that needs proof and hard evidence. To use a car analogy for the GP's post, "I could buy a Ford because it is safer and easier to repair, but sometimes I'd just buy a Chrysler because it's cheaper and easier to purchase". There's nothing wrong with this statement if you have real numbers on the two different cars - but making the statement based on some kind of assumptions on what you think the two languages will or won't do is pure folly. If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.
  - mercurial 13y ago
    > If you're adding in new information into the type system, you'd have to go through each part of the system that uses that type and update it to use the new information correctly. It depends on what you do. If you (say) add a new field to an existing type, this will screw up pattern matching. It's a bit inconvenient, but typically not a big deal. On the other hand, if your previously non-nullable String field becomes a Maybe String, you're going to have to update every location where you access it... and that's exactly what a reasonable programmer wants to do. Unfortunately, you can't encode this in Javascript, so you're going to resort to 'grep' (good luck if you have the same field name for several objects), or forget about it and get runtime errors. Sure, in theory you can rely on your Javascript unit tests to detect the error, and you may be right in practice, or you may be out of luck. Generally speaking, Haskell has its fair share of problems, but it's not one of them. > If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. It definitely matches my own experience (it obviously depends on your proficiency in both languages, and Haskell will have only marginal advantages if you use String everywhere because types are hard). > He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself. It's the kind of thing for which it is extremely hard to get any evidence for (and not only in Haskell vs Javascript debates), for obvious reasons. The best you can say is that the stronger guarantees of correctness offered by a strongly-typed program ensure that it makes it much easier to detect regressions. On the other hand, if, say, there are no third-party libraries for the problem domain at hand, strong typing will not magically fix that.