Hacker News Reader

Comment by hzhou321 | Hacker News Reader

> 1. There is a learning curve.

Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time and experience.

> 2. Haskell has some very nice libraries

So does NodeJS and (on an abstract level) Microsoft Word. Libraries are infrastructures and investments that (like time and experience) can cover up any shortcomings.

> 3. Haskell libraries are sometimes hard to figure out

That is simply negative, right?

> 4. Haskell sometimes feels like C++

That is also negative, right?

> 5. Performance is hard to figure out

That is also negative, right?

> 6. The easy is hard, the hard is easy

That is a general description of specialty -- unless he means all hard are easy.

> 7. Stack changed the game

Another infrastructure investment.

> 8. Summary: Haskell is a great programming language.

... I am a bit lost ... But if I read it as an attitude, it explains a lot about the existence of infrastructure and investment. Will overcomes anything.

View on HN

> The line that if it compiles, it’s probably correct is often true.

That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.

And while that's still not a great fleshed out explanation, it's a great oversimplification of the symptoms of a programming language with a great type system. And that type system is more or less the only reason to use Haskell.

As other people in this thread have commented, Haskell has fantastic abstract libraries, which let you do abstract things, the most useful of which that I'm aware of/understand is parsing. Parser combinators are a very natural fit for Haskell, and making DSLs with them becomes practically trivial to do.

Edit: I think the author takes for granted the general praise that Haskell gets, and was attempting to temper it with his practical experiences using the language.

"That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide."

That's interesting. I am pretty aggressive with C++ refactoring because the compiler will tell me what's wrong. Especially compared to JavaScript for example. In what way does the Haskell compiler provide better error checking?

The semantics of the program can be more thoroughly encoded in Haskell's far more powerful type system. So if the program type checks you're far more likely to have a correct program than in a language like C++ or Java.

> I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.

That's precisely what I was doing at work today in a C# project. I was going particularly crazy today, doing some refactoring with project wide regex replaces rather than leaning on VS/Resharper for everything.

I think it depends a lot on how your project is structured. If you're passing around object everywhere and casting... you're gonna have a bad time, sure. But at that point you're practically using Python or something. If you're using generics and so on properly, then you can lean on the compiler and type system quite a lot.

Yup, C# codebases (especially w/ tools like Resharper) can be massively refactored and, in my experience, almost always work perfectly as long as there are no compilation errors. C# tooling is fantastic.

> That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.

I work on Java projects and do big re-factorings using IntelliJ, relying on the compiler. So this is a bit project-dependent.

Java chooses two wrong defaults - nullability by default, and mutability by default. If your project consciously chooses to not opt into these defaults, from my experience, you can use javac to guide you in fearlessly making large refactorings.

"Java chooses two wrong defaults - nullability by default, and mutability by default."

Which of course, are two defaults that Haskell chooses correctly (which is maybe what you were implying).

OP here.

The point about a learning curve is that Haskell is different from most mainstream programming languages.

> > 2. Haskell has some very nice libraries > So does NodeJS and (on an abstract level) Microsoft Word. > Libraries are infrastructures and investments that (like > time and experience) can cover up any shortcomings.

Javascript is one of the most widely used languages in the world and MS Word leverages the Microsoft ecosystem, which is another of the most widely used development environments.

It's when you use less widely used environments (and Haskell may be borderline here) that you need to start worrying about libraries being available. I would not go as far as claiming that Haskell is as good as Javascript in that respect, but it is pretty good.

> > 4. Haskell sometimes feels like C++ > That is also negative, right?

I actually like C++ a lot.

It's also one of the most successful programming languages in the history of programming languages, so it has something going for it.

> > 5. Performance is hard to figure out > That is also negative, right?

Yes, it's a pitfall.

> > 7. Stack changed the game > Another infrastructure investment.

Yes, tooling matters.

So you understand I was commenting that your post didn't really say much about Haskell (learning curve, libraries, tooling ). What you commented or implied is a bit of current Haskell culture.

> I actually like C++ a lot.

Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). I simply find your comparisons odd. Given their deliberate design choice difference and it ended up feeling alike, how can that be positive?

> Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends).

Haskell is also a continuous patchwork, just look at the number of deprecated GHC extensions.

... which is the opposite of its pure vision, which is why I can't help think it is a negative.

>>> Haskell is an example of academic carefully crafted language

>> Haskell is also a continuous patchwork

> which is the opposite of its pure vision, which is why I can't help think it is a negative

I'm very confused. One second, you're literally saying Haskell was "carefully crafted", and the next, you're saying it's "the opposite of its pure vision"

It's almost as if you're just trying as hard as you can to argue, not caring what stance you're arguing, just so long as you can act like the author is wrong

> I'm very confused. One second, you're literally saying Haskell was "carefully crafted", and the next, you're saying it's "the opposite of its pure vision"

> It's almost as if you're just trying as hard as you can to argue, not caring what stance you're arguing, just so long as you can act like the author is wrong

Let me write the complete sentence:

([luispedrocoelho commented that] Haskell is also a continuous patchwork ) (which I simply accepted and followed -- even though I am doubtful) which is the opposite of its pure vision, which is why I can't help think it is a negative (regarding OP's point).

I commented originally that OP's this C++ comparison is also negative, right? So it is consistent.

When I say something is carefully crafted, I am refering to its intention. When I accept that someone find it like C++ or is also a patchwork, I accept that as a reality. When the reality runs against its design goal/vision/purpose, it is a negative, IMHO. -- Hope this clarifies.

EDIT: to make it even clearer, I didn't comment that whether a pure design goal or a continuous patchwork reality on its own is positive or negative. That is subjective. However, having a design goal and reality conflict, that can't be positive.

Every time I've tried to dedicate time to really learning Haskell, I've come away with the feeling, "If I was a lot smarter or had a lot more time to dedicate to it, this would be a fantastic language to develop in after about 2-3 years."

The way that functions can compose in the hands of a gifted developer is truly elegant. That said, I'm not sure it's a skill that translates well to the general development community (and maybe that's fine?).

Out of curiosity, what method/resource did you use to try to learn it?

I've tried "Learn You A Haskell for Great Good" and "Real World Haskell".

That was my guess, but I didn't want to be presumptuous. I tried with them and as well it didn't really stick. In my opinion "Learn You A Haskell" is a great supplememental reference, but a terrible teaching tool. And I think It's done more disservice to enforcing the reputation of Haskell being difficult to learn.

I highly recommend the lecture notes online from the "Upenn Spring 2013 Haskell" class. Search that phrase and it should be the first hit (am on mobile).

Go through the lecture notes, and do all the exercises in the homework. (Link in purple at the top). It's a night and day difference from LYAH.

And you get to build some nifty real world style projects along the way.

Good luck!

> (#1) Time and experience can cover up anything.

This is simply not true. Time and experience can never cover up for lack of expressiveness, and expressiveness is one of the biggest selling points of Haskell.

In fact, experience can only cover for complexity, and lack of discoverability or intuitiveness. Haskell has all those three flaws, so you see, experience is really needed.

> (#2) So does NodeJS and (on an abstract level) Microsoft Word.

No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell.

> (#3) That is simply negative, right?

That's the inevitable downside of #2.

> (#6) That is a general description of specialty -- unless he means all hard are easy.

Well, not all obviously. You still can't declare "f = solution to SAT in polynomial time" and be done with that. But the sheer amount of hard stuff that becomes easy is unsettling.

About #8, I'll let it open. Experience and investment can certainly not overcome anything as you claim, but I'm still not decided wether to classify Haskell as "the best available for nearly anything (maybe except if you have a killing library in another language)" or "hell, why can't somebody just come and rewrite it as something _simple_", or both.

> Time and experience can never cover up for lack of expressiveness

Expressiveness is subjective. Experience can alter one's perception.

In fact, time and experience alter the basis of comparisons, from objective comparisons to subjective comparisons.

> No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell.

You mean you can express the idea of taking browser screenshot (for example) or producing a publisher acceptable document with the same kind of ease(expressiveness in my dictionary) in Haskell?

Again, without specifics, the comparisons does not mean much -- which was all I was commenting.

> But the sheer amount of hard stuff that becomes easy is unsettling.

Another meaningless subjective word (sheer). I wasn't debasing Haskell. I was commenting on the meaningless of original post.

haskell is objectively expressive. (where expressive means amount of logic per character)

there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and variable names serve as VERY powerful documentation, especially when combined with haskell's also VERY powerful type system (which e.g. has sum types where most languages do not, which allows for example, defining most error states of program as a data type (which can then derive from any typeclass)).

one of the primary benefits of laziness is to make function composition possible under a wider variety of situations (which also increases expressiveness, at the cost of occasional though not difficult to avoid space leaks)

one joke I've heard is that the ideal haskell program is 20 lines of imports and one line of perl.

By objective, you mean succinctness (which can be simply measured by program character counts)? In this regard, APL must be the most objectively expressive language. What if we run deflation over APL?

It happens that I measure expressiveness by the amount of the time the author takes to express an idea and/or the amount of the time the reviewer takes to comprehend an idea. That, unfortunately, is very subjective.

APL programmers write very short programs, but they express it at one character a minute (or less) pace.

Well I can't argue with the contention that there's a level of subjectivity here. However your definition of expressiveness is most likely positively correlated with the one I provided; furthermore, while you may be able to more quickly "express an idea" in a dynamically typed language, your ability to precisely enumerate the idea will be less than a statically typed one.

I've been writing haskell for only several months, yet I would say I'm already more expressive with it than other languages I have more experience with, like javascript or python, outside of domain specific languages like sql.

> furthermore, while you may be able to more quickly "express an idea" in a dynamically typed language, your ability to precisely enumerate the idea will be less than a statically typed one.

What we need realize is not all ideas are precise. In fact, most of our ideas are vague to certain extent. They are still OK as long as the vagueness does not matter to the problem of interest or it is already constrained or implied in the context. So to efficiently express an idea, both insufficiency or over specificness are negative to expressiveness. To disclaim, I don't claim any language is the best to that regard. I believe language should be suited to the problem (as well as the experience of the team).

Since you particullarly mentioned type, I would suggest that not always a particular type is important in a idea. For example, sorting, the types of the items are not intrinsic in the idea. Having to specify the type contributes negatively to the expressiveness. However, when performance is concerned ragarding to certain specific sorting problem, types (as narrowly specific as we can) are of importance. However, we should recognize that is a different idea from the original idea of sorting. So even though in the program eventually it expresses both the algorithm for sorting as well as the types, being forced to mix ideas are negative toward expressiveness.

Haskell, its types and pureness, for example, are not always essential in a programming idea. Having to take care of these language requirement while it is non-essential, makes it less expressive (in those problem domain).

I agree to some extent, but haskell pureness for example , which I take to refer to monads and other concepts from category theory in haskell, is actually very very abstract; the "constraint" of pureness (IO monad) just leads to the design of more consistent and very general interfaces; once you become familiar with these interfaces you are quicker than you would otherwise be, also haskell's type inference help alot with expressiveness vs. dynamic languages. In fact, personally my road to really learning haskell was through converting shell scripts to haskell, a task typically left to dynamic languages but which haskell might actually be uniquely suited for contrary to convential wisdom due to aforementioned factors.

Not saying haskell is some kind of panacea, doesn't run in as many environments as javascript, and can't handle programs that require very high performance at very low latencies due to garbage collection.

For web dev, the library situation seems very mature to me.

What evidence do you have that APL programmers do not express and comprehend ideas in APL programs much faster than programmers using other languages? Similarly for Haskell.

How do you know you're not just a Blub programmer?

http://www.paulgraham.com/avg.html

The first evidence is a direct evidence, but limited only to my direct channel, which is my personal experience.

The second evidence is an indirect evidence. If average APL programmers can write and read programs at the same speed (character count/minute) as average programmers for other languages, Java for instance, then APL programmer will possess significant advantage in finishing similar programming tasks, given that the typical code size is often a few orders smaller. Why such advantage is not embraced and see APL programmers everywhere? My hypothesis is avg APL prgrammers program at much slower speed.

Like any science, I cannot say my hypothesis is conclusive. I am open (eager) to hear and examine any other evidences (and change my hypothesis if necessary).

Expressiveness is a objective term, although it's multidimensional. It's the number of different concepts you can express in a language without writing an interpreter¹. Anyway, the dimensionality isn't much of a problem on that comparison since Haskell has the upper hand in an overwhelming number of dimensions.

Keep in mind that Javascript required a multi-year process in what a committee reached an agreement and all interpreters had to be changed so that JS programmers could use continuation monads. And they are still restricted to continuation, and a way too verbose syntax.

> Another meaningless subjective word (sheer).

That "The easy is hard, the hard is easy" assessment is inherently subjective, but "subjective" is not the same as "meaningless", even less when nearly everybody that experienced it has the same assessment. (Are you also going to complain about my "overwhelming" above?)

1 - I'd give you a point on subjectivity if you were talking about the difference between a library and an interpreter. But those languages (that is, JS and Basic) are just not expressive enough for this to become a problem.

> but "subjective" is not the same as "meaningless", even less when nearly everybody that experienced it has the same assessment.

Subjective on its own don't have to be meaningless. It can be subjectively meaningful. However, use a subjective statement to pass as an objective support, that is meaningless. So if OP and you are merely commenting on the status of mind or his and yours, that is fine -- and I do learn something in that regard. OP, and several other commenters, did not seem to realize they are substituting their (personal) subjective opinion to objective reasoning, that was what I pointed out, in case it become useful (to them).

I feel the same way. I think the Author was trying to give an honest opinion on the pitfalls. Would have been nice to hear about the honest benefits too.

I don't think being like C++ is a negative and it is far easier to learn compared to Haskell.

> ... I am a bit lost

Google "cognitive dissonance" and the "sunk cost fallacy."

The point of the article was focusing on things to fix. Having used Haskell, there's a great many things that were worth the cost of learning it. For one thing, it's made me a vastly better programmer in other languages. It lets me appreciate better styles of writing code and think outside the box when solving things. Using Haskell also gives me the tools for many projects to write code almost thoughtlessly -- you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system. Libraries exist for abstractions you wouldn't even think of in other languages that can cut down the code to 1/100th the length it would be and maintain expressiveness and type safety. At the same time, I don't find myself using Haskell all that often because I do think it's missing a lot of things I desire, but depending on what you're working on it can be very far from a sunk cost.

> you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system

That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here?

My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.

There's no conspiracy; programming in Haskell is the most fun I've ever had with a computer.

The "if it compiles, it works" thing describes people's experience. It isn't always true and it isn't a valid excuse not to do proper testing, but in Haskell a non-working solution is usually at least broken in a way that makes sense in the context of the problem you're trying to solve. If you program an incorrect solution to a problem, you'll probably get a wrong answer. But a wrong answer is different than nonsense, which is what you get if, say, you write past the end of an array in C.

The Haskell type system is a very good nonsense filter, and probably a majority of programming errors are from telling the program to do something nonsensical. If you filter those out, sometimes what's left is a working program.

A Haskell programmer is unlikely to write a several thousand line program and have it work correctly the first time, but even large programs are written in small pieces. When those small pieces work correctly the first time, it's gratifying.

I'm not sure how this corresponds to your experience with Haskell, but as an OCaml user there's been numerous times where I have been forced to write large chunks of code without a compiler/IDE to aid me at all (e.g. VM wasn't working so had to work from Windows temporarily). In each of these cases, upon compilation, I have been greeted by a flood of errors (syntax errors, type errors, and everything in between). However, without exception, the program has always worked as expected when I ran it the first time. I think it's reasonably plausible that one could write a program the magnitude of ~5k lines in Haskell and have it work on the first attempt.

Reply on news.ycombinator.com