3 ms·

The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstractio

The linked article talks about abstraction, and that you could abstract so much that the concrete problem doesn't fit in your abstraction. I.e., your abstraction is broken. I think that is precisely why OOP started to disappoint (tbh: I also think many people did not understand OOP really well). Haskell pushes you to compose types instead of building inheritance hierarchies. Multiple inheritance turned out to be a bad idea too, so yeah, OOP program do typically not have the best models of the problem domain they were intended to model. At the other end of the spectrum you see people just give up: everything is a kind of dict or a string, or wo knows, null? Looking at you php, python, javascript.. All the improvements you see in todays OOP languages are ideas stolen from functional languages like Haskell. What Haskell could have done better is be strict instead of lazy by default. To model the real world and make assumptions explicit, a type system, as Haskell gives you, is so nice. I agree that you can make types also really abstract like some people indeed do. It's fine if you do that as a library author, but you should offer a facade with some simpler type aliases. If you stick to Haskell98 and possibly enable GADT support you already get an immensely powerful language. Also, I have not used Haskell for a while, but I heard the compiler error messages have become way more human friendly these days, so that helps with complex types.

titzer 4y ago
As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed. It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.

titzer 4y ago

As with anything, it all goes well until it doesn't. When you have a single bug (e.g. type error or dynamic error), the guts of whatever is in the box spill out. Case in point: all the implicit template parameters to std:: in C++ these days. The only way to add configuration options in a backwards-compatible way was to add default values for template arguments. That's all fine and good when you can't see them, but as soon as you have a nasty type error, the types that come spilling out in error messages have zillions of default arguments that get printed. It's almost always the same with inference. I would be very, very wary of doing so much type sophistry that it requires heavy inference to be usable.