Unless someone had literally never seen anything on Haskell before, this kind of article adds absolutely nothing new to the discussion. It's all been said before, and more often than not it's been said by FP Complete. It reads like an infomercial, and it's frankly embarrassing reading it.
In Praise of Haskell
51–60 of 64 posts
Re: In Praise of Haskell
#52Earlier quoted context omitted.
It is not a "strong" statement to say that some Haskell code is backed by proofs. There is Wadler's Theorems for free![1] which allows one to reason about pure function's behavior purely from type signatures. As well GHC supports various features that enables one to encode some dependent typing[2] constructs. Allowing the type of value to to depend on the value itself. A common example being a list that can expresses…
I'm aware of dependent types and, more generally, the strong undercurrent of emphasis on provable correctness in the Haskell community at large. I don't disagree at all with what you wrote, but it's not what I was referring to with my comment. My disagreement was specifically with the implied claim that it can be mathematically proven that Haskell code is easier to maintain than code written in other languages. That…
I misread your comment, usually people challenge that point. I totally agree that it is difficult to talk about maintainability in an objective fashion, but there is something to be said about having as many of your assumptions in your codebase vs. your test suite. My experiences working in a Ruby code base is that many assumptions have been encoded in the tests, and not notated in the main code base. When those assumptions change there is a large burden on the programmer of having to unify ad-hoc assumptions from both the test cases and main code base. Validating whether those assumptions still hold, or if it is a test from 3 years ago, and has only been vacuously passing.
I found working in a big Ruby code base that this required spending a non trivial amount of time unifying the two. In that regard by minimizing the amount of test code one has to write and maintain I would argue that maintainability goes up. I've also seen a lot of FP practitioners boasting about relatively low test to code ratios, while in the Ruby world often times you have at least 2x test code, since often times you even have to validate assumptions like `object.responds_to? :foo`.
Re: In Praise of Haskell
#53This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming. In actuality the author is trying to sell Haskell because he sells Haskell IDEs. I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.
Yeah, definitely just more propaganda from "Big Haskell IDE".
[deleted]
Re: In Praise of Haskell
#54What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.
Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.
The worst thing to do when learning Haskell is to think that you will be comfortable in just a week. Learning Haskell for most is like relearning to program. It takes time to build up intuition and understanding of the language. I know that it took me multiple tries at Haskell over a few months before it finally "clicked" for me and became comfortable to work in.
Re: In Praise of Haskell
#55Earlier quoted context omitted.
Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others). I disagree. You can make objective measurements of maintainability. You can look at cyclomatic complexity and reusability (both wins for pure functions). You can test how often changes lead to bugs and how often the errors are caught. There are ma…
> You can look at cyclomatic complexity and reusability (both wins for pure functions). Yes, those are both wins for pure functions. But even there you need an asterisk, because side effects do have their place - the fact of the matter is, the primary task of most real-world software can be summed up as "manipulating mutable state". In light of that I don't think you can necessarily jump from the observation that the…
The win for Haskell is that it wears its statefulness on its sleeve. Of course you can, with sufficient discipline, write pure code in any language, though it can be frustratingly difficult in languages where libraries make idiomatic use of mutation. And yes, you can also write impure code in Haskell, at least for some definitions of "impure".
What you can't do in Haskell is write impure code that claims to be pure (up to the customarily and idiomatically avoided `unsafePerformIO`), or write code whose degree of statefulness is ambiguous. Reliable, explicit, and statically enforced purity holds more than just theoretical benefits. I don't have to read through library code to see if it is thread-safe. I don't have to worry about whether passing a data structure to a library function will result in that structure being mutated behind my back. I don't have to trust code comments that may not be in sync with the current state of the code. Simply by virtue of the fact that a function does not mention `IO` in its type, I can have total confidence that it won't violate my assumptions about its behavior. And I don't even have to take it on faith that the author wrote the correct type for his code; if he hadn't, the compiler would have rejected it. This is the difference between "pure by convention" and "provably pure".
Every language must necessarily have an "IO monad" and interact with the inherently stateful world, or else it is useless. Haskell is different not because you can choose to avoid I/O, but because when you do so, the type system will back you up with perfect accuracy.
Re: In Praise of Haskell
#56This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming. In actuality the author is trying to sell Haskell because he sells Haskell IDEs. I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.
Yeah, definitely just more propaganda from "Big Haskell IDE".
The author is the CEO of a company that sells the first (and only?) commercial Haskell IDE. I point this out because the author (from his background) clearly knows about the subject matter, while reading the content of the article would lead you to believe the author was a novice to software development and computer science.
The shallowness of the article combined with the background of the author can be reconciled if you understand the article as an advertisement.
Re: In Praise of Haskell
#57Earlier quoted context omitted.
Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others). I disagree. You can make objective measurements of maintainability. You can look at cyclomatic complexity and reusability (both wins for pure functions). You can test how often changes lead to bugs and how often the errors are caught. There are ma…
> You can look at cyclomatic complexity and reusability (both wins for pure functions). Yes, those are both wins for pure functions. But even there you need an asterisk, because side effects do have their place - the fact of the matter is, the primary task of most real-world software can be summed up as "manipulating mutable state". In light of that I don't think you can necessarily jump from the observation that the…
But even if that were granted for the sake of argument, it's not much of a win for Haskell. The ability to create pure functions is a feature of every language that has been invented during the lifetime of probably every person reading this post, and therefore not really a differentiating feature of Haskell.
I already dealt with this three posts above:
And no, it's not the case that Haskell is the only language which allows you to write pure functions. People who try to claim that are being silly and dishonest. Haskell's advantage is that its type system allows you to know at a glance whether or not a function is pure.
Nor is lack of ability to create impure functions a feature that can be claimed of Haskell, because that simply isn't true. Haskell's real differentiator in that department is just that you've got to jump through hoops to do it. And if your business rules are inherently impure, then it's not clear to me how a language that tries to ghettoize impurity makes them easier to implement.
That's only the case for beginners who don't understand monads and their associated libraries. For an experienced programmer, Haskell offers much more powerful and expressive (not to mention safe) means of combining effectful computations than typical imperative languages.
Re: In Praise of Haskell
#58The example provided is too contrived. By that logic, here's a way to "match" haskell with php: $a = range(2,100,2); $b = array_slice($a, 5);
Also Scala (just because):
val a = 4 to 100 by 2
val b = a drop 5Re: In Praise of Haskell
#59Earlier quoted context omitted.
Firstly, I think this is somewhat unfair to dynamic solutions. I could just as easily reword it as "you try and pull in a library and hope it doesn't break your compilation." Simply put, it could be the up front hell that probably puts a lot of people off of a solution. Not to mention adding a new piece to a highly type based solution could involve modifying a lot of the existing types to make room for the modificati…
It is more of a contract. The library author is stating this package was developed against these dependencies and versions. It is known to work well in these cases. This does not mean it will not compile. In fact often the fix is simply for the author or developer to relax the version bounds and everything will be fine. Lastly, many of these issues arise not because of a direct dependency but an indirect one. The pro…
I still feel you are being a touch unfair to the dynamic world. Many times, bringing in a dependency just works.
The analogy I have in my mind is a digital computer for a bike. The general "contract" is simply that you will somehow get a pulse to the computer for each rotation of a tire with a known size. The details of how the bike is constructed are ultimately irrelevant.
Further, because this is such a general contract, it doesn't actually matter if you hook it to the wheel or not. You can, in fact, use such a computer in a non bike device with success.
Re: In Praise of Haskell
#60Earlier quoted context omitted.
No, you can just watch this talk by John Carmack as he extols the virtues of Haskell for game programming: http://functionaltalks.org/2013/08/26/john-carmack-thoughts-...
The problem I have with this is Carmack is in the top 0.01% of developers so of course writing a game in Haskell is going to be within his grasp. For the rest of us it's a huge exercise in mental gymnastics. I've written a few visualizations for data using Gloss ( http://gloss.ouroborus.net/ ) with Haskell and although it does "just work" when it does compile understanding how to manage state in a pure environment is…
Many medical techniques were probably pioneered by specialists and later adopted by general practitioners.
The perceived difficulty of mastering pure functional programming for practical work might be a result of bias in the typical CS education experiences. That might shift as the value of pure functional programming gets more universally recognized.