Hacker News Reader

Comment by benreesman | Hacker News Reader

I’m currently a bit overweight, like maybe 10-15lbs. This is because I have some combination of bandwidth-consuming and focus-consuming things going on that results in me not doing an obviously correct thing: get the fuck back in shape.

Every hacker in the peanut gallery deep-down knows that they should know Haskell and Lisp well. They resent the fact that their job or personal life or whatever doesn’t leave room to get serious about computation theory. And they vent this frustration endlessly on people lucky enough to have had the bandwidth at the right time to thoughtfully contrast computation with physical computing machines (the only person I know to stomp Lemire in AVX is a GHC hacker).

I’m kinda fat because I haven’t fixed it yet. People don’t know Haskell and Lisp well because they haven’t fixed it yet.

Neither is an appealing look.

View on HN

I've worked with Haskell professionally. It was... interesting. I'd rather be in shape than deal with Stack/Cabal/Nix again. If anyone reading this is wondering if they should learn Haskell - wonder if your time could be better spent having a fun and active life instead lol.

Oh I feel you on the weird effort/payoff curve. I spent months wanting to throw my computer out the fucking window learning Nix.

But I eventually cracked the code and now it like where is deep enough to bury anything running Ubuntu. Let’s fucking break non-dynamic linking of libc because GNU.

NixOS is fundamentally wrong on a few key points. But it’s close enough to right to make everything else look ridiculous. Who doesn’t love never really knowing without rigorous audit what is running on my machine that’s highly optimized for Drepper’s career.

I second this. I think Haskell is a research programming language, and in a way I feel lucky that I first learned it way back in 2002, long before anyone seriously thought of using it for professional software development.

Haskell 98 is a pretty awesome programming language. It's not the best fit for every domain, but you can write concise readable code in it. The type system is just sophisticated enough to let you model your domain, but not so sophisticated that it becomes a distraction.

A lot of modern Haskell code has the unfortunate property that the types of the functions are harder to understand than their implementations. Type inference is much more valuable when it's the other way round. You know that [a] -> [a] is the right type for the 'reverse' function, so if you get a type error, you're sure that you made an error in your implementation. Conversely, many modern Haskell libraries give rise to extremely complex types, even when you're doing something mundane like making an SQL query. When you get a type error, it's then anyone's guess whether you misannotated a type somewhere or made an error in your implementation.

I personally feel that partial types systems are the way forward. Type the 80-90% of your code that's easy to type without a fancy type system. Dynamically type the rest and write some tests for it. Fancy types make you feel smart (and in all seriousness are a fascinating and important research topic), but their practical utility is limited IMO.

I agree that gradual type systems are great, but man, I feel like the expressiveness of e.g. Typescript is fantastic even for 'normal' programming.

Something like fully typed forms (so that e.g. <Input type='text' path='address.street' /> only works if your form data has a { address : {street : string} } + branded types for more custom data fields) is absolutely magical and makes working with lots of highly complex forms a breeze. Tests just don't compare.

To take your analogy further, the LISP masters are like ultra-fit personal trainers. When they run a bootcamp for out-of-shape people, they start off with impractically intense exercises and just make everyone demotivated.

"Oooooooh! Welcome to Rex Kwan Do! Let me show you how superior I am to you know-nothing chumps! Bow to your sensei! Bow to your sensei!"

I had some pretty bad language instruction in college, but the professor teaching Haskell was the worst. Maybe it really was a case of "if you can't explain it simply, you don't understand it well enough.", but I remember everyone finishing that class (just barely) and nobody ever wanting to do use it again.

To present anecdotal counter evidence: my FP class using Haskell was phenomenal. I've talked to other students who've also taken the class and they generally agree.

Meh. I have had the time to learn a fair amount of Haskell and do a few projects in it (mainly interpreters). It's a fun language in some ways, and it was nice to know how to use it because it expands your ways of thinking, but beyond that it's not terribly useful, and I don't think that it's much better at that than other functional programming languages. Learning about the type-system is neat but IMO not as perspective changing as "getting" purely functional programming.

However, as an actual tool to do actual work, I really don't see why you would go about it for anything but very specific projects.

I seriously suspect there is a bimodal distribution are play here, because I would love to use Haskell, or something like it that's possibly more powerful like Idris, wherever I could. And at the same time I notice a lot of people expressing your sentiment.

These systems make it easy(er) to model concepts in a mathematical way and this is my natural (or preferred?) mode of thinking. And they enable you to do it easily and ergonomically. What is there not to like?

(I know there are flaws at hand, even some potentially very debilitating flaws depending on your use case. But damn, I'd use these languages wherever I can.)

See the thing is, I also love thinking about things mathematically/as relations/as recurrences. But I like the more imperative way of thinking about algorithms and data wrangling just as much.

So in practice, I'll go for a language that allows me to do both easily, instead of going for something like Haskell where any imperative way of doing things is very painful (as well as other issues, of course). So why would I use Haskell and limit myself for fairly marginal benefit?

How is the imperative way painful in Haskell? Nothing stops you from just writing everything in the IO monad if you feel your algorithm is easier to write in an imperative style.

What's the point of using Haskell if I'm going to do that? I much prefer using a language that does imperative programming very well and functional programming fairly well if I'm going to use both.

Because Haskell is a general purpose programming language. It doesn't do imperative programming worse then for example Python or C#.

That's very false. Python or C# are significantly better at imperative programming.

The point is you're going to have parts of the program where you won't be doing imperative style at which Haskell will excel, including at combining and composing the imperative and non-imperative components.

There is also the saying that Haskell is the world's best imperative language, and that is not without reason, since you can re-use its usual power of abstraction while writing imperative code too.

I completely disagree that Haskell is a good imperative style language. It's barely adequate by today's standards.

It's awkward, it has a bad ecosystem, it has just as many issues with hidden state, etc...

The only reason you would want to write imperative Haskell over a modern imperative language is the typesystem, but even that can be an issue sometimes, and I'd risk saying that the Rust or C++ typesystems while being very slightly less expressive are better at scale overall due to their flexibility imo.

Another big one is that it really sucks to debug. Seriously, it's brutally slow compared to what you can do with a good debugger in other languages.

If you care about performance, Haskell can be significantly worse than others, both lower level compiled languages (lazy evaluation, large amounts of trash to be collected by the GC, cache trashing, etc...), and higher level interpreted languages, due to the lack of native accommodations to bind into fast code, or even into GPUs.

There are a lot of disadvantages to Haskell if you're going to do mostly imperative code.

I have to disagree with vm this, Haskell is by far the most powerful imperative language I’ve used, because it allows me to abstract what I mean by imperative programming.

I don’t have time to go into details but nearly every statement you’ve made here is in my opinion wrong, other than the difficulty in debugging (and there are very good reasons why this is difficult).

I’ e never found it hard to write fast Haskell, because I put in the effort to learn how to do it. People forget they also put in the time to learn how to write fast C++, and Java; it’s a very large portion of any software engineering curriculum, it’s literally what algorithms is all about. People find writing fast Haskell hard not because it is fundamentally hard, but because they were never taught how.

> due to the lack of native accommodations to bind into fast code, or even into GPUs.

I have no idea what you mean by this, GHC provides a very good FFI, and there are libraries for binding to Rust, R, Objective-C and others. We also have Accelerate for data processing on GPUs, which includes runtime compilation of native code for both GPUs and CPUs.

Have you tried?

Yes, what kind of question is that? Why would I say this if I didn't do it myself. I have written many imperative style functions in Haskell. It's basically required if you are doing things with files, network or Hardware interfaces.

We're not talking about functions, rather about larger programs where most of the code has to be imperative.

What are these programs where most of the code has to be imperative? That seems like a design decision, not an inherent constraint for most programs.

Haskell is a great language for imperative programming, actually. You are not limited by the language in that regard.

People say that a lot, but it's not my experience. Your imperative code will be less readable, an order of magnitude more difficult to debug, and it's going to be much harder to leverage the ecosystem.

Our experiences differ, then. I have found it to be more easy to refactor and parallelize that other languages I have used.

Debugging has not been difficult either, but I have always use print debugging in every language, so there is not much I can compare.

For me personally, it is because the benefit is not fairly marginal nor do I feel like limiting myself when using Haskell, not even for imperative parts of the program.

> Haskell code has the unfortunate property that the types of the functions are harder to understand than their implementations.

Interesting point. What is the purpose of type-declarations? To make implementation easier to understand, I think. When you know (and understand) the type of a component or function you know how to use it, and how to not use it, and thus how to write code that uses it and does what you think it should do.

But if types are harder to understand than the implementation, then types don't help much, do they?

On the contrary, when you can move your complexity into the type system, the. You have just taught your compiler how to check that you are using things correctly, and that is insanely useful in large scale software.

> These systems make it easy(er) to model concepts in a mathematical way

I feel this is largely a lie. The type system is still a crippled language that is also incompatible with the runtime language. It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine?

I think the solution is: Just use regular code, it works best. Use types to describe interfaces. Simple types, because with anything else you're painting yourself in a corner.

I think it is largely not, though it's not something that is a magical solution to all modelling problems. It probably depends on the domain you're solving problems in, but on the other hand, I've written CRUD applications in Haskell successfully and would characterize it as a nice experience.

> It possible to do some very specific things in it, but does it help you describe a system's data flows? Memory allocation patterns? GUI layout engine?

I feel you're underselling quite a bit when you say very specific things, but again, perhaps this depends on the problem domain, your thinking style, your programming style or some other undetermined factor. Out of the things you mention, I would say a definite yes to system's data flows, weaker yes for GUI layout and no to memory allocation patterns, because that is a known weak point.

> it’s not terribly useful

Well, it’s been paying my wages for the past eight years, so it’s incredibly useful to me. Are we services “very specific projects”? Are data processing systems? Are geospatial data munging? Are financial systems? Those all sound like mundane, every day projects, and they’re exactly what I’ve been working on.

And when it comes to “actual work”, that’s where Haskell truly shines - being able to fearless refactor code and iterate until the compiler is happy again is my favourite feature of Haskell. It’s not the “neat type system”, it’s the ability to not have to keep the entire project in my head at absolutely all times because I might forget to make a stupid change the compiler should have caught for me. The productivity is massive, once you’ve invested the time, but it does take time and it is an investment.

> I’m currently a bit overweight, like maybe 10-15lbs. This is because I have some combination of bandwidth-consuming and focus-consuming things going on that results in me not doing an obviously correct thing: get the fuck back in shape.

Luckily, this doesn't take as much time as it sounds, because exercise (and other time consuming things) aren't helpful for losing weight. Everything else yes, losing weight no.

That's because it's pretty much entirely about your diet, and exercising makes you hungrier, which makes it harder to comply with the diet.

Learning Haskell is a mind makeover I agree. People are missing the point when they say nonsense like, "well if haskell is so great why isn't every piece of software written in it and outperforming on all possible metrics?"

That kind of lazy thinking "isn't even wrong." You learn haskell to become the kind of person who "has learned."

The ignorant imagine haskell is a promised superpower that will under-deliver "productivity gains." It's a new way of thinking and building software.

If there are productivity gains they will be invisible: you wont make the first feature X twice as fast (dev time), but you might make the 100th feature twice as fast due to lack of tech debt, but you wont notice as every team gets used to their cadence.

The lack of tech debt comes from there not being the horrible OO sins. OO is great but there is a lot of “assume not null” and L in SOLID violations in practice and it all adds up.

Haskell has explicit opt-in nulls (optionals) and there is no L to worry about as there is no subtyping.

Reply on news.ycombinator.com