(33:26) Areas where Haskell needs improvement: modules, garbage collection, records, IDEs, research/industry impedance, increasing syntactic and type-system clutter, typeclasses (an overly complicated mechanism with multiple purposes, the main probably being post-hoc interface abstraction)
I would say modules, IDEs, (and garbage collection performance) are key criteria for not adopting Haskell....other mainstream languages do not have these deficiencies. You could also say that having 5-6 different stream libraries is a problem, what in fact you should have just one; included in your core set of libraries. Perhaps we just take the best bits of Haskell?
@@jimiscott thanks for your comments as I am new to Haskell and this is valuable. Strictly for me IDE is not overly important but for many developers it is, so you're still right on that one.
To me Haskell makes it overly complicated with monoids, functors and monads : all who introduce the concept to audiences speak like gurus. That’s not normal. I wouldn’t do away with these concepts but I would make their presence more seamless. Actually I wouldn’t do away with variables and procedural programming altogether. I would rather have the possibility for any function without side actions to be transformed canonically into a procedure with side effects, and vice versa, with the functional notation being always easier, clearer, cleaner, shorter than the sequential ones. The way to do it would be the use of iterators (as in Python) treating lists like sequential or indexed files with io operations. The for loop should be present in functional Haskell but in the very same way it is already present in list comprehensions : looping in space rather than in time so as to produce a list from other ones. This possibility would be tremendously reassuring to newcomers, like the if then else and case constructs. Changeable variables should be reintroduced but only as a io objects to be accessed with io actions such as get and set and put.
OO might no longer be the absolute king but putting nails in his coffin and sharpening the guillotine might lead to even harsher a tyranny : evolving towards an OO constitutional monarchy might spare a lot of trouble to the future denizens of software engineering.
Very nice talk. I liked the transition between subjects... thanks for sharing ;)
in particular the abstraction landscape slide at 22:53.
Nice talk thanks to publish
(33:26) Areas where Haskell needs improvement: modules, garbage collection, records, IDEs, research/industry impedance, increasing syntactic and type-system clutter, typeclasses (an overly complicated mechanism with multiple purposes, the main probably being post-hoc interface abstraction)
I would say modules, IDEs, (and garbage collection performance) are key criteria for not adopting Haskell....other mainstream languages do not have these deficiencies. You could also say that having 5-6 different stream libraries is a problem, what in fact you should have just one; included in your core set of libraries.
Perhaps we just take the best bits of Haskell?
@@jimiscott thanks for your comments as I am new to Haskell and this is valuable. Strictly for me IDE is not overly important but for many developers it is, so you're still right on that one.
@@jimiscott RIO provides a sane set of basic features and replaces Prelude.
To me Haskell makes it overly complicated with monoids, functors and monads : all who introduce the concept to audiences speak like gurus. That’s not normal. I wouldn’t do away with these concepts but I would make their presence more seamless. Actually I wouldn’t do away with variables and procedural programming altogether. I would rather have the possibility for any function without side actions to be transformed canonically into a procedure with side effects, and vice versa, with the functional notation being always easier, clearer, cleaner, shorter than the sequential ones. The way to do it would be the use of iterators (as in Python) treating lists like sequential or indexed files with io operations. The for loop should be present in functional Haskell but in the very same way it is already present in list comprehensions : looping in space rather than in time so as to produce a list from other ones. This possibility would be tremendously reassuring to newcomers, like the if then else and case constructs. Changeable variables should be reintroduced but only as a io objects to be accessed with io actions such as get and set and put.
Typeclasses are useful for theoretical structure. It's good for encoding that a type is an instance of a specific mathematical object
It'd have been more convincing if the bad stuff was first. Otherwise it's a very well-structured talk.
I think the opposite, showing respect to other ways soon enough is a sign of careful thinking and open-mindedness.
25:31
OO might no longer be the absolute king but putting nails in his coffin and sharpening the guillotine might lead to even harsher a tyranny : evolving towards an OO constitutional monarchy might spare a lot of trouble to the future denizens of software engineering.
While the first part is alright, his annoyances with the language just look like incompetence of the guy to properly set up his environment
If a skilled user isn't competent to set up the environment and can't become so, is the system one to be persisted?