Hacker News Reader

Comment by bauerd | Hacker News Reader

>The other reason is that many FP users are too enthusiastic about creating abstractions.

Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful languages. Therefore, take away their guns, ie make languages less powerful. I still wish there was something like Elm, but tailored for backend/network programming: https://news.ycombinator.com/item?id=21909087

View on HN

I started with Elm, then I started working through Learn You a Haskell. At first I thought the lack of typeclasses in Elm was a big missing piece, but now I see the potential for me to turn a programming problem into a little-too-philosophical debate about the nature of truth in the universe or some such. In other words leaving out typeclasses may help but not guarantee that I keep my eyes on the screen and off of my navel.

The hard part with Elm’s lack of typeclasses is the lack of do notation. It’s pretty easy to end up in Elm’s version of “callback hell” where you’re nested several `andThen`s deep. And that’s for a language that doesn’t have `IO`. That said, I would love to try an “Elm on the backend” that specifically lacks features compared to Haskell.

Scala seems quite close. It has a lot of features. But it's flexible enough that it doesn't "hurt" as much as writing production code in Haskell.

The advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing.

For simple cases, the end result of no typeclasses can be compelling sometimes.

For larger cases, taking away that useful tool to wrangle inherent complexity usually results in more complexity taking the form of gobs more simple code that obsfucates the task at hand.

Overuse of abstraction is penny-wise and pound-foolish.

It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder.

Why? Because when you have an abstraction, your code, possibly in many places, depends on it. Now if you need to make a change, you will need to understand both the abstraction, and your "instance" of it.

Well no rather you need to understand ALL instances of that abstraction, to know that if you change the abstraction you are not breaking ANY of its uses.

Penny-wise and pound-foolish in many cases.

I agree with you because you said overuse - but I wanted to reinforce that this is statement reads: "It's a bad idea when it's a bad idea" which isn't super helpful and might give the impression that abstraction is usually the bad option. There are very very few times when I've seen the correct answer between abstracting code and leaving it as-is being leaving it as-is when a good abstraction is possible - but I've also seen a lot of incorrect misaligned abstractions that abstract functionality that coincidentally looks the same (i.e. sharing similar business rules as an origin) but is actually quite different. If you're calculating the final price on a transaction and that item could be either a donut with a 5% food tax or a t-shirt with a 5% sales tax it's not appropriate to abstract taxes to be 5% - they're different taxes and just because they happen to be the same number making them reference the same logic block or constant is a Bad Idea(tm).

Abstraction is (generally) an investment in the long term health of your system, whether you, the dev, can justify the costs to higher ups or not is usually a pretty big part of the question. But, if there are legitimately abstractable things you can abstract please do abstract them (and add tests over everything).

> Abstraction is (generally) an investment in the long term health of your system

Don't forget the Opportunity Costs. If you spend much time abstracting, it is less time actually producing something that helps the users of the application.

Now if your business is maintaining an existing application it makes sense you should invest in making its maintenance easier.

But if you are programming a new application you want to get it in production fast, so that you can learn about what needs to be different about it.

I would say that the time to think about maintenance is mostly when you are in the maintenance stage, because of the huge benefit of getting early feedback,

if you don't mind losing static types, there's erlang and elixir.

> I want an FP ecosystem that's not rooted in research

Erlang is rooted in practicality. https://www.youtube.com/watch?v=7AJR66p5E4s&t=180s

Reply on news.ycombinator.com