3 ms·
It seems to me that part of the problem he was having is that he didn't really understand how these methods were being implemented internally. I know that all l
by tdb7893 10y ago
It seems to me that part of the problem he was having is that he didn't really understand how these methods were being implemented internally. I know that all languages inevitably have these problems but how do the amount of leaky abstractions compare in Haskell to other languages?
- kqr 10y agoI don't think Haskell is worse than any other language in that regard. What perhaps sets it apart is how much of its functionality is implemented in third-party libraries, which may be difficult for a beginner to come to grips with. "Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" I can come up with two explanations for this reliance on third-party libraries. 1) Haskell has always been a quickly evolving language attracting research-minded people which in turn go on to develop really cool libraries that are much better than conventional ways of doing things. The interpretation of this explanation is that it's simply not possible to keep the standard library up to date with the latest library developments. It may also be the case that 2) Haskell has always been a really powerful language capable of offloading important tasks to libraries. What would need to be built-in functionality in other languages can be implemented as libraries with no sort of special treatment in Haskell, so people do it that way because they can, and because it keeps the base simple.
- bunderbunder 10y agoI'm leaning toward #2, largely because I know that's the Scheme approach, and I get the impression that Schemers and Haskellers have similar feelings about protecting the design purity of the language. By contrast, the Python community has always been pragmatic, arguably to a fault. I can say that newcomers also seem to get a lot of advice that's directly at odds with how the Haskell community seems to think people should use the language. For example, Learn You A Haskell starts right off the bat by encouraging people to use the "list of characters" version of strings, even though that approach courts serious performance concerns.
- tome 10y agoIt might be simpler than that. Array syntax is not built in in Haskell therefore the array implementation needn't be built in.
- kqr 10y agoI'm sure I misunderstand you, because it sounds to me like other languages were designed on the basis of "Wait! How did this array syntax get built into my language? Oh well, now that it's there I guess I might as well build in arrays..." I would guess those languages get built-in array syntax specifically because they have built-in arrays. The arrays come first, the syntax later.
- tome 10y agoI suspect that typically both arrive at the same time!
- cousin_it 10y ago> > how do the amount of leaky abstractions compare in Haskell to other languages? > I don't think Haskell is worse than any other language in that regard. Many Haskellers are happy about this kind of stuff: min = head . sort which is the very definition of a leaky abstraction. The blame lies with laziness, because it allows code to depend on implementation details of other code in crazy ways: "sort is O(n log n) unless you ask for only the first element, in which case it's O(n). What if you ask for the last element? Uhhh..."
- dTal 10y ago>"Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" Python does in fact use a third-party library for efficient arrays (Numpy) and its use is so widespread as to be a defacto language unto itself.