Hacker News Reader

Comment by mhh__ | Hacker News Reader

This is a slightly loaded question, but is a Haskell codebase harder to work on than one in a reasonable non-functional language?

Maybe it's because the bugs are generally less common and easier to fix, but when I look at Haskell codebases it seems like it's quite difficult to achieve the same level of "separation" one would in (say) Java - i.e. an average Haskell file seems to purely consist of many loose free functions (often with very short names!).

I might be missing the point but the aforementioned always pushed me away from Haskell - great language, but seems to have legibility as an afterthought (as opposed to python, which is an awful language, does manage to enforce some sort of legible coding style)

View on HN

In my experience, even bad Haskell codebases are easier to work with than mainstream language ones. Once I got over the learning curve, I barely think very hard when programming Haskell. It's all mechanical.

For this reason, I find code style to not affect me in Haskell. I've seen a bunch of different styles and I'm never taken aback. The code is all simple & mechanical to reason about.

I've been able to refactor other people's "bad code" without much effort too. This is after others have said the code is bad and unfixable. It just takes a good attitude and the same mechanical approach as always.

At the end of the day, I think a lot more about the business problem in Haskell than other languages. I hate having to think about code & simulate a computer in my head. But if you wish to use other languages and pay me to think like a computer, feel free! It's your money.

You can think of modules as Java classes and get the same sort of code separation fwiw.

I've found it to be easy to work personally, if you want long names of functions in your code if it helps you should. Common libraries might not have long names for functions, but you'll find the same thing for the most part if you look at the API of collections in various languages for example.

Oddly now I find it really legible compared to other languages, you can still make things obtuse if you really want to, but the flow seems so much clearer.

I would say compared to Java (as you mentioned it) there's much less separation because things invariably gravitate towards big balls of mud containing lots of state. But in Haskell the function you're looking at is only tied to the functions and data types it uses, no more, no less.

Yes, you are missing the point. It is very common for people to miss it when they only have experience in OOP, and very hard to adjust to the required paradigm.

Good Haskell code is not organized the same way as good OO code. While in OO you will have separated instances that take complete care of different business concerns, in Haskell you will abstract the care into different parts, and integrate the business concerns into a few instances that take complete care of them.

I’d suspect the difficulty comes from the paradigm shift.

I’ve personally switch code to functional style and it has simplified and reduced code for me. Granted if you don’t know how monads work it could be very confusing.

I'm a bit rusty but I do understand the type and category theory behind Haskell. I don't find it confusing, just sort of suboptimal a la C++ template syntax

Ah yes if you have a language that isn’t conducive to it... luckily Typescript is multi-paradigm enough.

How could it be tweaked to make it better?

What D does. Angle brackets make instantiations harder to parse. Also the template keyword is pointless

Reply on news.ycombinator.com