← Back to context

Comment by viraptor

11 days ago

> the expressive type system of Haskell

> Expressive type system ARE direct and simple.

Those result in a conflict because given expressive types, people will make them not simple. For example, you realise why Haskell continuously gets academic papers like "Functor is to Lens as Applicative is to Biplate; Introducing Multiplate"? There's no reason for something like that in Go for example, because it's less expensive and the signatures are trivial.

> JS (...) can distill the basic good parts of OOP into very direct and clear idioms?

Clear in that one specific project context that you need to know. Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place.

> There's no reason for something like that in Go for example, because it's less expensive [sic] [1] and the signatures are trivial.

Whoah, Are you saying, for example, that generics are not useful? That's quite the claim. In that case, to make things even simpler, let's remove recursion, functions as data, even type systems altogether, because they lead to "complex" code. See where your reasoning leads?

Any language feature can be abused. In the same vein, you also say:

> Perl suffers from this. You can build your own OOP, so many people did and now there are hundreds of mostly-compatible-but-not-fully versions of OOP with different syntax and semantics all over the place.

One can create OOP in any most modern Turing-Complete languages, so this is not a strong argument.

[1] I believe you meant "expressive" here

  • > Are you saying, for example, that generics are not useful? That's quite the claim.

    That's why I didn't make that claim. If you just want to invent straw men, I'm out.

    • That is your implied claim. If that is not it I'm not sure what your arguments is.

      You mentioned that Go does not have certain advanced features and thus does not lend itself to tying oneself up in complexities. I'm asking you where you draw the line.