Hacker News Reader

(Disclaimer: Haskell fan who is also a complete newbie here).

I like what the article is trying to do, but I must admit there is something off about it. Maybe it's me, but I read between the lines something like "you and me both know Haskell is the best language, but try to be gentle with unbelievers and admit that nobody, even Haskell programmers, is perfect. Other languages have some good insights, too." which sounds a bit cultish to me, a bit like teaching a Jedi knight to be humble. A truly open-minded position would have to continually consider that maybe Haskell and its type system are not the best options at all, instead of merely adopting a humble attitude and avoiding aggressive confrontation.

Nothing wrong with believing a tool is better than others (I do!) but it makes the article sound a bit condescending...

I'm ready to admit maybe I'm wrong and there is no implied presuposition that Haskell is superior in the article :)

----

Re-reading other comments, here is something related to what I've just said. Someone quoted Newton: "If I have seen further it is by standing on the shoulders of giants."

That statement sounds humble (a "humblebrag", some other commenter called it) but carries the implication that you have, indeed, seen further. Maybe the assumption that you as a Haskeller have "seen further" sounds immediately condescending to others who think differently.

> A truly open-minded position would have to continually consider that maybe Haskell and its type system are not the best options at all

There are two ways that I can parse this comment. The first is that you mean that there are other, newer options out there that will turn out to be better than Haskell. This, almost all Haskellers would agree with: most of us have more than a passing interest in e.g. Idris, Agda, Shen, etc.

The other reading is that you mean that other established paradigms are better options (A third reading is that there is no such thing as better, but for that I'll just point you to pg's classic Blub essay). This is a good thing to consider once, but I strongly disagree with considering it continually. Once you've made the comparison, if you come to the conclusion that one tool is better than another, it doesn't make sense to continue that comparison forever. It may make sense to revisit it from time to time as you grow in your understanding of the task and the context, but at some point your posterior probability of the other tool being better must grow so low as to no longer be worth investigation. For many Haskellers, the comparison between a Haskell-like type system and dynamic typing is this kind of comparison. My posterior probability of dynamic typing being a better choice is less than one percent, so it makes no sense for me to continue reevaluating that option.

If the latter is what you mean, I can't disagree that it is a truly open-minded position, I can only point you to a quote by the inimitable Tim Minchin: "If you open your mind too much, your brain will fall out."

I mean the latter, but not because it's my position (I certainly don't think an effective use of my time would be to continually re-evaluate each of my opinions on programming languages), but because I think it would mesh better with the article's tone of "humility above all things".

My own opinion is that sometimes you're right and your interlocutor is wrong, and sometimes this means you simply cannot avoid sounding condescending.

You presume that reevaluation of your position is an expensive operation that we must economise on. But sometimes it is just keeping your eyes open. For this particular question, I see lots of very good and beautiful written in imperative and dynamically-typed languages. There are many problems for which the most natural program is imperative or object-oriented. So to me at least looking at the programming language world with the presumption that Haskell-like languages are always superior seems cultish indeed.

It's not a presumption. It's not a prior that we're holding to regardless of evidence. The superiority of Haskell is, for all the Haskellers I know, a conclusion that they came to after extensive research and experimentation. It's not like we were somehow trained in some hidden refuge where imperative and object-oriented languages aren't spoken of. I cut my teeth on PHP, of all things. I know what's out there, I've made the comparisons, and I see no reason that I should keep doing so forever.

When you say "problem" you are describing something higher level than just an algorithm, yes? Could you give some examples of problems that the most natural program is imperative or object-oriented?

For a given problem, no doubt, some languages are better than others. I still doubt one can say that in general, without qualifying what kind of problem he's solving.

I'm just writting a device controller in a side project (at userland - I already have enough problems to solve - the kernel sees it as a soundboard and a USB TTY). At fist I tought "wait, great time to try some serious reactive programming in Haskell", but I gave up, C++ looks much better fit to that problem. When it's done, I'll probably write some Haskell wrapper, and use it in a functional reactive program, but Haskell is just not the language for the controller itself.

Also, another side project requires a CRUD web app, with some simple rules. It's in Python. No way I'm going to write it in Haskell. Another component is a TCP server with a complex behaviour and that I want to scale, it's in Haskell, no way I'm going to write it in Python. Another component is in VB.Net, go figure...

Maybe there is a young and mostly unkown language that is indeed best - no strings attached. But it's certainly not Haskell and I still didn't find it.

There's definitely a tradeoff between library maturity and language quality. There are also a few specific domains that are best-served by more domain-targeted languages. That doesn't mean we can't say that, aside from those issues, one language is better than another. I can say that Haskell is a better language than Python and then go ahead and use Python anyway because NumPy/SciPy/pandas or whatever. We can separate the issues and render judgments about language quality independent from library maturity, etc.

The existence of specialized domains justifies an argument that you should use specialized languages in those domains, but that is almost never what we're discussing. Java, Python, Ruby, Haskell, Clojure... none of these are languages specialized for a given domain. They're all general-purpose languages, and if you compare them as such independent from their libraries, Haskell is the best of them. That does not mean that it's the best choice for every project, but that's a completely different question.

Sorry, but I still disagree.

It's the flexibility of Python that makes it great for writting CRUD applications with diverse data types, at the same time that it's the rigidity of Haskell that makes it great for writting a complex specialized server. It's the unsafety of C++ that makes it great for directly interfacing devices, but you really does not want that unsafety in any of the other examples.

None of that is a matter of maturity, it's the other way around, the available libraries are good for different tasks because the languages allow them to be. You can't just compare those languages without context.

I wasn't going to wade into the object-level CRUD app discussion because it seems beside the point, but I can't possibly disagree more about Python somehow being better suited for the domain because of "flexibility". Python is not more flexible than Haskell in any meaningful way.

The only possible argument against static typing comes in the form of a program that won't typecheck, but should. This is the only type of "flexibility" that Python could win at, with regard to type systems. Please, show me a practical example of such a program. I've asked a dozen people for one, and nobody has ever followed through.

The only other argument against Haskell's "flexibility" I can think of would be against purity, but that argument doesn't fly either. Any competent Haskell programmer can work easily with state, IO, etc, and I've never run into an effectful task in practice that takes meaningfully longer to do in Haskell than in Python.

People are often quick to typecast languages into some role that seems to fit. Haskell is rigid and mathematical, Python is flexible and readable, etc. These impressions rarely come close to capturing the reality, and in this case end up being downright misleading.

If I'm starting developing a web application from scratch, with zero libraries available to me, I'm picking Haskell without a shadow of a doubt.

Every single value in Python is weakly defined, and can change at runtime. Functions can accept any set of parameters, objects do not need to conform to a class, the entire namespace can be replaced during the execution of a function. If you have a better name than "flexibility", please tell me, because I can't think of any.

Haskell is in the oposite extreme of that dimension.

Anyway, that has no relation to readability. Python's flexibility leads too easily to metaprogramming, for example, what's extremely powerfull, but a nightmare to read. And classifying a language as "mathematical" is borderline nonsensical - it only carries some slight meaning because people that say that normaly want to say "algebrical", in oposition to, maybe, "logic-temporal".

Maybe reread my post - I wasn't saying that those typecasts of the languages were accurate, I was doing exactly the opposite.

The characteristics of Python you just mentioned are only specific to it in cases when they are erroneous. They basically all evaluate to "Python isn't type-safe." So again, show me a program that is best represented in a non-type-safe way, and I will concede the point. If you can't, then this flexibility you're praising isn't a feature, it's a bug.

> The characteristics of Python you just mentioned are only specific to it in cases when they are erroneous.

They are explicit at the official documentation, if they got there by error, they are official features now.

> They basically all evaluate to "Python isn't type-safe."

Yes, they do. They are at the opposite extreme from type-safety. That's why I used them to exemplify how it's the languages that apply better to some problems.

> So again, show me a program that is best represented in a non-type-safe way, and I will concede the point.

Well, any Django[1] CRUD would do. They are quite trivial, in there's little meaning in specifying exactly the manipulated data. Yes, Haskell has tools for displaying data at the web, and querying a database; no they are simply not as powerful when applied to that problem.

[1] In other frameworks they are about as simple, but you asked for one example.

I find this a strange and unconvincing example -- if I'm understanding you correctly, that is. Is your complaint about strong typing here that you'd be forced to define stuff like a record Customer with fields "lastName", "firstName", etc. and you'd rather avoid that?

If you'd like something more "dynamic" (i.e. type-unsafe), you can instead just define a "universal data type" for all your CRUD data. For example you could define, say

   data Any = Number Int
            | Str String
            | Map String Any
            | Date ...
            | ...

and where you want "universal" data manipulation you just use Any.

EDIT: Thus you've confined all the "fuzziness" of your data definitions to a "subsystem" of your system and you can still benefit from proper types and type checking everywhere else.

Where do you find that Python is better than Haskell for CRUD applications? I've found the type system to eliminate most common CRUD application/web dev bugs and make me much more productive.

Have you tried a CRUD web app in Haskell? There are now several frameworks that make it a breeze.

You point us to the Blub essay as if that settles the matter. It doesn't. I think the Blub essay is wrong.

Here's the Lisp people. They're sure that they are at the top of the power curve (including compared to Haskell), and they can tell you exactly why. "How can you get anything done in Haskell? It doesn't even have macros."

Over here are the Haskell types (pun intended). They're sure that they are at the top of the power curve (including compared to Lisp), and they can tell you exactly why. "How can you get anything done in Lisp? It doesn't even have a decent type system."

This situation - two different languages each looking down at the other - reveals the problem in pg's Blub Paradox. The problem is this: The idea that all languages can be ranked on a one-dimensional axis called "power" is wrong.

You can see this with hardware, for instance. We know what power is in hardware - it's MIPS. But once you think a bit deeper, you might remember that your workload contains a fair amount of floating point, so you have to worry about FLOPS... and there's that one data set that doesn't fit into cache, so you have to worry about memory bandwidth... or would it be worth lower MIPS to have a bigger cache? Now "power" has at least four dimensions (MIPS, FLOPS, memory bandwidth, and cache size). Even more (but for the same reasons), it's naive to say that programming languages can be strictly ordered according to on a one-dimensional "power" axis.

So now you have to start asking "power for what"? I think this is the right question, because nobody ever writes a general computer program. We always write specific ones. We want a programming language that has the most power for that specific problem we're trying to solve.

Once you crack open that door, in walks (for example) a Fortran person, who asks, "How can you get anything done in Haskell or Lisp? They don't even have decent matrix packages!" And before you say "of course they can do matrix math", by "decent" the Fortran person meant a package that can, for example, efficiently handle a banded hermitian matrix with complex elements, and still get good answers even if it turns out to be a stiff problem. I strongly suspect that Lisp and Haskell matrix packages aren't yet up to that standard. (And if you're going to say, "Well, that's just a niche", I suspect that niche is at least as big as the entire Haskell universe.)

Then a hard-real-time embedded programmer comes through the door, and says that their world needs a language that not only doesn't garbage collect, but doesn't cons either. (That niche is probably also as big as the Haskell or Lisp universe.)

And so on.

Think of programming languages as a tree. Think of your problem as a vector. Use whatever branch of the tree gets you the furthest along the vector of your problem. In other words, the best tool for the job. It's not always Haskell. It's not always anything. Learn more than one tool.

Your point that there is more than one axis on which to measure the power of a programming language is well-taken. That said, you can normalize to one axis. The point of pg's essay is that only people who have learned the relevant tools are qualified to judge them.

The solution to your Lisp v. Haskell dilemma is simple: ask the people who know both. I agree with Lispers that macros are powerful, and the stuff in the book Let Over Lambda is ridiculous and awesome. I also think that macros are dangerous, and I prefer to only use them if there's no other alternative. I pick Haskell over Lisp, having used them both extensively, and I've seen far more people come to Haskell from Clojure than the other way around.

With regard to Fortran, embedded, etc, see my response to marcosdumay. Yes, those niches are sizeable and you should use the correct tool for the job. That has no bearing, though, on the question of which programming language is better.

> That said, you can normalize to one axis.

True, but such a normalization is not unique. That is, one language or the other can come out as "more powerful", depending on the normalization chosen.

Your point about "ask those who use both" is harder to refute...

> I mean, how can you even try to ask people to improve their communication skills, when you say that people that do not think programming is math is because they have the wrong notion of math?! I just don't see how you are going to convince anyone of anything with that level of condescension.

You're projecting a level of condescension onto Gershom's words that just isn't there and makes no sense within the context of the article. His point is that the "debate" about programming/mathematics is largely one of semantics and consists of well-intentioned people arguing from a different set of definitions. I'd hardly consider this to be a controversial statement, much less condescending.

Did you read the same article I read? The article states the exact opposite of what you said, that you shouldn't go around with the goal of "slaying dragons" (slaying what you think are falsehoods)

... Are you sure your clearly preconceived notion about "Haskell People" didn't taint your perception?

Er, isn't that the whole point of the article?

"Every time we learn something new and want to share it, we face these issues all over again -- the desire to proclaim, to overturn received wisdom all at once -- and the worse the received wisdom, the more vehemently we want to strike out. But if we are generous listeners and attentive teachers, we not only teach better and spread more knowledge, but also learn more, and enjoy ourselves more in the process."

"What we have to tell a young language enthusiast is that there is much insight in ideas different than our own, and that there is much to learn in looking outside of what you consider the best. Maybe there are tools that are better suited for other kinds of problems. Maybe not everyone that disagrees with you is very wrong about things and needs to be converted."

The article says exactly the opposite, but you're too lazy to read.