[coldtea]

>Dart even chose to have an unsound type system because subtyping and parametric polymorphism (generics in Java) were deemed too hard for Google programmers to understand. The Go designers agreed.

And they were both wrong, as millions of programmers use Java and C# and C++ just fine, and have created much more impressive software than what Dart or Golang programmers have. Plus, people used to the power of C++ would never switch to Golang (which is also what the Golang team observed: they mostly got people from Python/Ruby and that kind of services).

>Haskell and OCaml are a joy to program in, in part because they (mostly) eschew subtyping.

Sorry, but did you just said that "subtyping and parametric polymorphism (generics in Java) were deemed too hard for Google programmers to understand" (an argument based on complexity) and then went on to argue in favor of Haskell, which is notoriously difficult to grasp, and has so many foreign concepts that it makes Generics look like BASIC level concepts.

[willtim]

Ignoring all the abstractions and concepts (made possible by underlying simplicity), Haskell is absolutely a simpler language than C++ or Java with Generics.

EDIT: my point was that subtyping is controversial, I assume the downvotes are for my own personal position.

[coldtea]

Many people who've tried to get into it, and whose horror stories we read on HN frequently, would argue otherwise.

[willtim]

Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java?

Where I work we do have some business people successfully writing Haskell.

I've worked on very large codebases in many large organisations with C++, Java and Haskell. Haskell certainly wasn't the horror story.

[coldtea]

>Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java?

How hard should they have tried? Should they have burnt the midnight oil?

This Java you talk about, is still in the top 1-3 languages by programmers, is it not?

And supposedly Haskell is easier (according to the parent comment) but at the same time needs people to try harder to get it than Java? It can't be both...

>I've worked on very large codebases in many large organisations with C++, Java and Haskell. Haskell certainly wasn't the horror story.

No, but it was the new novelty on greenfield staff. Easy to start as better. Java wasn't the horror story in 2000 either.

[willtim]

> This Java you talk about, is still in the top 1-3 languages by programmers, is it not?

I'm disappointed that you appear to judge technology based on popularity. By this argument, JavaScript trumps Java.

> And supposedly Haskell is easier (according to the parent comment) but at the same time needs people to try harder to get it than Java? It can't be both...

I can assure you, having learned both, that understanding Java and all its idioms/patterns is at least as hard as learning Haskell, especially if one seeks to build concurrent software (where the intricacies of Java's complex memory model cannot be ignored).

Because of the immense amount of investment already made, likely these people give up when they realise they cannot make much use of it in Haskell, at least not at first.

> No, but it was the new novelty on greenfield staff.

You've made an incorrect assumption. The Haskell codebases I have worked on, in both cases, have been large and over a decade old.

Anyway, my original post was about the controversy of subtyping, not Haskell versus Java.

[MichaelGG]

He said Haskell was simpler than C++ which might be true. Doesn't mean it's easier. I'm more familiar with F# and C#. I'm guessing that the F# language is simpler in as far as having fewer language concepts. But many people struggle and would find it more difficult, at first. Brainfuck is even simpler yet even harder for many people.

[Chyzwar]

ML languages are simpler, but require paradigm shift.

[coldtea]

Shouldn't the paradigm shift factor into the calculation of the simplicity?

"It's simple once you've changed how you think about stuff" just hides the complexity in a prerequisite.

[willtim]

> Shouldn't the paradigm shift factor into the calculation of the simplicity?

Not at all. You sound like you're looking for excuses not to learn something new!

[dragonwriter]

> Shouldn't the paradigm shift factor into the calculation of the simplicity?

No, because it's path dependency, not complexity.