6 ms·

> One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops.

> One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. It sounds like you just haven't used Haskell enough to have the full extent of the reusability become apparent. I agree that on the surface it seems like you're right. But that particular example of reuse is just the tip of the iceberg. It's actually a very pervasive pattern that has tremendous positive impacts on your code at every level from small 3-line loops to large overarching abstractions. This isn't just me making baseless assertions. It has been backed up by real world experience. There was an ICFP presentation by a company that rewrote their entire application in Haskell. With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! The rewrite also decreased the size of their code base by something like 80%. Oh, and they saw a massive reduction in bugs and increase in performance. > But that premise has not been shown to be true. The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world. It's only been in the last 5 or so years that Haskell has really become commercially viable. This is too recent for the large apps you're talking about to have been written. But don't worry, we're working on it. The other day our newest hire made the comment that at our company each individual developer is responsible for roughly the equivalent of an entire team at all his previous jobs.

pron 12y ago
> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about reusing projects like ZooKeeper, Hadoop, etc. Being able to use such a project might save you millions of LOC, regardless of the level of internal code reuse. The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. In fact, using ZooKeeper also reduces a large number of bugs. > But don't worry, we're working on it. Excellent. I'd love to get a full picture, tradeoffs and all, of a big, important software project in Haskell (which isn't a compiler). > The other day our newest hire made the comment that at our company each individual developer is responsible for roughly the equivalent of an entire team at all his previous jobs. I can say the same for my current job, even though we're mostly doing Java (and some Clojure), and at our previous jobs we also used Java. This mostly has to do with the quality of developers, company structure and size, and less with the choice of programming language.
- jerf 12y ago
  "The most important kind of code reuse, IMO, actually happens at a larger scale," There's a hidden instance of begging the question here, which is that the reason why "large-scale" code reuse is "more important" in the real world is that OO has largely been a failure for mid-scale code reuse. You can build enormous frameworks in OO that serve a need (at some cost in constraining your options, but one that can be worth paying), and it can do certain fairly small-scale reuse like 'a generic red-black tree' or other data structures, but it has not done well in the middle. Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world". However, it is difficult to disentangle whether that is a fundamental characteristic of "reuse" or whether it's a fundamental characteristic of OO. (I can argue in favor of both, and I don't mean "both are true", I mean I could argue in favor of either one.)
  - chetanahuja 12y ago
    'Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world" ' I'm not a blind fan of any one type of software methodology but this assertion is completely wrong. Java and C++ world is replete with widely used code libraries that are used and reused in millions of diverse software projects. This fact is so obvious that I don't feel the need to list out the examples here, but I will if challenged.
- mightybyte 12y ago
  > The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. This is an instance of begging the question too. Newer, less popular languages will always have fewer libraries and bindings relative to more popular languages. It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. But the reality is that Haskell is actually doing quite well in terms of libraries and bindings. Pick anything you can think of...odds are probably pretty good that Haskell has bindings to it. As an example, let's look at the two projects you mentioned: ZooKeeper and Hadoop. Yep, there are Haskell bindings to both of them. For ZooKeeper there's hzk (http://hackage.haskell.org/package/hzk http://hackage.haskell.org/package/hzk), and for Hadoop there's hadron (https://github.com/Soostone/hadron https://github.com/Soostone/hadron) and there's even a nice presentation about it (http://vimeo.com/90189610 http://vimeo.com/90189610).
codygman 12y ago
Is there a video of that presentation anywhere?
- mightybyte 12y ago
  https://www.youtube.com/watch?v=BveDrw9CwEg https://www.youtube.com/watch?v=BveDrw9CwEg

pron 12y ago

> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies! If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about reusing projects like ZooKeeper, Hadoop, etc. Being able to use such a project might save you millions of LOC, regardless of the level of internal code reuse. The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. In fact, using ZooKeeper also reduces a large number of bugs. > But don't worry, we're working on it. Excellent. I'd love to get a full picture, tradeoffs and all, of a big, important software project in Haskell (which isn't a compiler). > The other day our newest hire made the comment that at our company each individual developer is responsible for roughly the equivalent of an entire team at all his previous jobs. I can say the same for my current job, even though we're mostly doing Java (and some Clojure), and at our previous jobs we also used Java. This mostly has to do with the quality of developers, company structure and size, and less with the choice of programming language.

jerf 12y ago
"The most important kind of code reuse, IMO, actually happens at a larger scale," There's a hidden instance of begging the question here, which is that the reason why "large-scale" code reuse is "more important" in the real world is that OO has largely been a failure for mid-scale code reuse. You can build enormous frameworks in OO that serve a need (at some cost in constraining your options, but one that can be worth paying), and it can do certain fairly small-scale reuse like 'a generic red-black tree' or other data structures, but it has not done well in the middle. Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world". However, it is difficult to disentangle whether that is a fundamental characteristic of "reuse" or whether it's a fundamental characteristic of OO. (I can argue in favor of both, and I don't mean "both are true", I mean I could argue in favor of either one.)
- chetanahuja 12y ago
  'Therefore, since OO has been the dominant paradigm for decades now, we do not see any middle-scale reuse in the "real world" ' I'm not a blind fan of any one type of software methodology but this assertion is completely wrong. Java and C++ world is replete with widely used code libraries that are used and reused in millions of diverse software projects. This fact is so obvious that I don't feel the need to list out the examples here, but I will if challenged.
mightybyte 12y ago
> The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. This is an instance of begging the question too. Newer, less popular languages will always have fewer libraries and bindings relative to more popular languages. It might be an argument against using Haskell at the current point in time, but it has nothing to do with the merits of the language itself. But the reality is that Haskell is actually doing quite well in terms of libraries and bindings. Pick anything you can think of...odds are probably pretty good that Haskell has bindings to it. As an example, let's look at the two projects you mentioned: ZooKeeper and Hadoop. Yep, there are Haskell bindings to both of them. For ZooKeeper there's hzk (http://hackage.haskell.org/package/hzk http://hackage.haskell.org/package/hzk), and for Hadoop there's hadron (https://github.com/Soostone/hadron https://github.com/Soostone/hadron) and there's even a nice presentation about it (http://vimeo.com/90189610 http://vimeo.com/90189610).

codygman 12y ago

Is there a video of that presentation anywhere?

mightybyte 12y ago
https://www.youtube.com/watch?v=BveDrw9CwEg https://www.youtube.com/watch?v=BveDrw9CwEg