Comment by viraptor
10 days ago
You have conflicting requirements there - expressive type systems are not direct and simple. And elegant is subjective.
But seriously though: have you tried to see how far you can get with the design right now? You can start iterating on it already, even if the implementation will lag.
I do not have conflicting requirements. Expressive type system ARE direct and simple.
Expressive power is the ratio how strongly/clearly you can encode invariants to how complex and ceremonious the syntax of it needs to be.
See how JS, a language usually seen as a middling/mediocre language, can distill the basic good parts of OOP into very direct and clear idioms? I can just create an object literal and embed simple methods on them that receive the "this" pointer and use it. The constructor would be just a regular function. None of the cruft of standard OOP.
See how you define an enumerable union in TypeScript? Very simple. And yet I can think of many major languages that do not have this, certainly not with a lot of ceremony and complexity.
And I can go on.
> 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
2 replies →