Hacker News Reader

Comment by misja111 | Hacker News Reader

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world.

The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.

Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern.

By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.

View on HN

> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.

Do you have a code example? It would be interesting to see what this kind of code looks like.

Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. It’s a pretty straightforward implementation detail that have very little to do with your business logic.

And business logic is far, far easier to model using ADTs (it’s literally just AND and OR, applied to data structures) than confounding object inheritance hierarchies.

In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.

Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.

Posting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory

For details of the interfaces that the class inherits from, see:

https://docs.spring.io/spring-framework/docs/current/javadoc...

They're talking about Existential Crises in another post today.

I think I still have a copy of the book that Johnson wrote to accompany the creation of Spring (which someone wants $300 bucks for on Amazon, I didn't know it was a collector's item). The last time I used Spring, I had the distinct thought that I should go through his book as if it were a bingo card, comparing it with the latest version. It seems like it has reacquired all of the bits of J2EE that it set out to avoid.

If, outside of Spring, there is anything in the Java world that more perfectly embodies Nietzsche's warning about fighting with monsters, I don't know what it is.

The guy next to me on the bus is asking why I'm laughing so hard. I'm not sure how to respond. "These class names are really funny!"

InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

I'm glad we got the Simple one

Sometimes, though, you can only get the desired effect with SimpleBeanFactoryAwareAspectInstanceFactory_EX.

Thank you! I’m deeply familiar with the phenomenon!

I'd prefer readability to suffer because the fold over a monad needs something clever that requires a bit of reasoning to understand than because vast amounts of "readable" boilerplate (for example, trivial getters and setters) hide a needle in a haystack.

Maybe in the 00s, but these days most languages have collapsed boiler plate down massively.

This comes across as an old fashioned view (bordering on extremely old-fashioned).

I haven't seen evidence of reduced getters & setters in my day to day yet - they still seem pretty prevalent when OOP comes into the picture. I'd even say they got a bit worse because now it's excessive getters and setters with gigantic JavaDoc style comments all around them. If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

What are you talking about? Get setters used to be 10 lines long like:

    int id;
    public int Id
    {
        get {
          return id;
        }
        set(val) {
            id = val;
        }
     }

They're now one liners, and obviously necessary

    public int Id { get; set; }

I don't keep up with Java any more, but C# has super short shortcuts for assignment like:

    public int Id { get; set; } => generateId();

If you, or your company, are misusing a completely optional documentation feature, which you definitely should not be using to annote obvious stuff like IDs, that's your problem, not OOPs.

Switching to a functional language won't save your monitor, you'll still be forced to write bad code if doing stupid things like that are in your style guide.

Your comment is entirely specific to C#. Java has no such shortcuts, its setters and getters look identical to how they looked in 1994:

    private int id;
    public void setId(int id) {
        this.id = id;
    }
    public int getId() {
        return id;
    }

> If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

I honestly believe we're in a dire need for a more up-to-date metaphor that lets us better express our anger at a computer, due to monitors becoming paper thin and lightweight in the past decade or so.

> > If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

> I honestly believe we're in a dire need for a more up-to-date metaphor that lets us express our anger at a computer, due to monitors becoming paper thin and lightweight in the past decade or so.

My experience may not be representative, but I believe I have encountered variants of "hurl the keyboard at the monitor" more often than "monitor out the window".

OTOH, that phrase doesn't account for laptops.

> OTOH, that phrase doesn't account for laptops.

It is also not anger-ready for people working on tablets with rubber keyboards attached.

Hitting the desk with a fist of moderate force is harmless and rattles lightweight modern computer equipment very satisfactorily.

Putting fist through the monitor?

folding over a monad (or any other combinator) doesn't require extra reasoning or anything clever, that's the point.

I think HelloNurse's point was less that a fold is inherently clever or subtle (as you say, it isn't), and more that, if there is something clever or subtle involved, the lesser verbosity of the fold makes it easier to see than would a more familiar, boilerplate-heavy approach in which the clever or subtle point could be lost.

It does if you are unfamiliar to the pattern. It probably has more to do with experience with the patterns used rather than readability.

I just wrote about some possible pitfalls down the ADT route: https://treetide.com/posts/domain-model-pitfalls-oop-fp.html

> As more operations are demanded, it is more likely that the existing partitioning of the world into the nice distinct cases won’t suit that operation anymore. Then, as a fix, we can introduce more specific cases, or make existing ones more general - leading to ambiguity, bloat and mental load for the existing operations.

Just an aspect.

I like it!

It’s the kind of reasonable discussion that I crave in this field.

> Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”.

This was just an example of a behaviour that, if taken too far, could eventually lead to those 'hundreds of lines of abstract code'. Of course a single fold in itself is nothing to be concerned about. But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already.

Again, this might not be bad, it can even be good, but the problem is that many FP enthusiasts overdo it.

> In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.

Yes, this is the same problem which pops up in the OOP world as well. I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.

> 'hundreds of lines of abstract code'.

Yeah, I’ve spent way to much time digging into “hundreds of thousands” of lines of abstract OOP code. And it’s sadly, largely ceremonial, mostly due to limitations in the language. The less fanatic about OOP the language is, the more useful it is, is a good rule.

But it’s absolutely not exclusive to either paradigm.

> But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already.

I completely agree, but I’m also curious how any API interface like that would pass code review. Since it’s so obviously too general.

But I guess the perceived upside is that the equivalent oop-construction would not get caught in code review.

> Yes, this is the same problem which pops up in the OOP world as well.

I know. I’ve spent more time working within oop than without. The type based FP-world just have orders of magnitude better tools.

> I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.

This is kind of a sad way to dismiss people, as if they’re some kind of ephemeral fireflies...

The reality is that trying to force reality into in an inheritance-based, tree-structured taxonomy, is not only stupid, it also creates endless maintenance headaches.

Some problems fit that model better sure, but most things fit a much simpler ADT-based model since it’s much closer to how we think logically. (In terms of logical primitives and implicit recursion)

I think many of the responses to your parent post are focusing too much on `fold` and not the custom monad that is implied to just be a re-implementation of list.

> By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.

This is a great point. I think there are a lot of open questions about basic questions such as how ergonomic effect systems can become and which functional programming abstractions become intuitive through enough practice versus always feeling confusing. I think that stuff will shake out in a decade or two, and we will end up with much better styles to choose from. Who wants to program in 1990s/early 2000s Java style anymore? (Well, okay, a lot of people, but ignore them.) Nobody would judge OOP negatively based on that mess, because we know it can be done a lot better, and languages have evolved to cater to what we've learned. I think functional programming has a lot of evolution to come that will make it more ergonomic and more practical. It will be especially interesting to see what the cohort of programmers introduced to functional programming via modern front-end Javascript will do as some of them transition to the back end and look for statically typed languages that are better than Typescript.

C#, mostly.

>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

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

> It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.

This feels backwards to me. If I‘m new and join your team I’m much more likely to understand what a monad and a fold are than to understand your domain specific business objects.

So if we are working for an insurance company and see the ‘Insurance’ type is an instance of Monad I now know a great deal about combing different insurance products into new derived ones. By reading a single word of code!

There is plenty of FP in the corporate world, the mistake that many FP advocates make is to make it a war of FP vs anything else.

Meanwhile multiple paradigm languages keep getting most of the features that actually matter to Joe/Jane developer.

> the mistake that many FP advocates make is to make it a war of FP vs anything else.

I don't disagree with this (goodness knows there are plenty of functional purists who come across as religious zealots), but I think it's also worth mentioning that there's an opposing camp of people who are hard-set against ever considering FP for anything at all because they've bought fully into object orientation and stateful computation.

Both solutions are well-suited to certain kinds of problems, and this opposition is well summarized by study of what is called the Expression Problem[0]. A good developer should know both paradigms (in addition to others!) and use each where it is best suited.

[0] There are other issues than those discussed by the EP, but the EP is, I think, the most simple perspective of the distinction between OOP and FP.

Edit: TIL you cannot escape an asterisk on HN. That's a bummer.

In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems.

In general it feels like the overall feeling to FP is either

"I don't have time to learn a new paradigm when my current one is working good enough to make the company money"

"I love using FP ideas in my code when it makes sense"

I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.

Oh, sure! I didn't mean to suggest that there were as many as the only-pure-FP crowd, though I can see how my phrasing may have suggested as much. I just meant to bring up that there are people like that, who refuse to (consciously) adopt any amount of FP in their development. I have interacted with some myself. Most of them make arguments about, like, "People think in terms of state so FP is inherently a bad user experience" or something to that effect.

I've had people chew me out for using function objects in Java, saying it's too complicated and the newest thing isn't always great. I wanted to point out that Java 8 is 6 years old now, and qsort() has been a thing for a while.

I remember when I discovered "map" and "filter" in Python around 2000 or so and everybody I showed them to at work (it was a Java shop) thought they were so difficult and abstract compared to

  ArrayList result = new ArrayList();
  for (int i = 0; i < input.size(); ++i) {
    etc.

To them that was the "easy" way, and I was a weird kid into weird shit. I didn't make any progress with them at all trying to convince them that "map" and "filter" were simpler than iterating over an index every single time. Now everybody has forgotten that business logic used to be one for-over-index loop after another, often nested, and debugging an error often meant running through a for-loop in a debugger over and over again examining the partially constructed result at the end of each iteration trying to figure out where it went wrong. FP saved us from that, and it gets no credit. People only think of FP as the scary stuff they haven't learned yet.

The funny thing (that I'm sure you're aware of) is that 'prefer composition over inheritance' is an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. In OOP, this means that inheritance is bad because it's not always clear what functions are inherited and/or overloaded.

> an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing.

The idea of "referential transparency" is that you should always be able to substitute a reference for its definition, or vice-versa, without changing the behavior of the program. This implies both immutability (so that duplicating a value doesn't change the result) and purity (so producing the value has no side effects and gives the same result no matter how many times you do it). It has nothing to do with knowing what a variable is referencing. If anything, functional programming encourages the use of generic functions which don't know or care what their variables are referencing (parametric polymorphism).

> Maybe there should be a new edition of Clean Code written specifically for FP

I’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly.

Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data.

All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach.

It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned).

[0] https://www.manning.com/books/grokking-simplicity

FP abuse can lead to abstractitis which is sad but nothing the Corporate World doesn't like ... it was the land of J2EE after all.

"... too enthusiastic about creating abstractions."

Like others, I'm eager to hear more of your thoughts.

I also have a theory. A bit of a riff on Rob Pike's observation (IIRC): "Show me your data and I'll understand your code".

Enterprise-y (corp IT) projects are data centric. Functional programming emphasizes flow-of-control over the data flow. Even more so than functional decompensation (imperative programming) and object-oriented.

Donald Norman's notion of "affordances" applies. Any one can certainly "do COBOL" in Scheme, but pushing that rope requires uncommon insight and intention.

The reason why FP still doesn't really break through in the corporate world is a marketing failure, in the strictest sense of the word marketing, which means prioritizing the right features to target the right market.

A large proportion of this talk is based on the book “Crossing the Chasm". The book was originally written for startups, and this talk adopts the book to an open source audience, especially Haskell developers.

Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA

I think the word abstraction here is overloaded. OOP is also fundamentally driven by abstractions. The difference is that FP abstractions are mathematical abstractions, while OOP starts with human-centric conceptual abstractions - the kind every two year old is taught. These are not the same in terms of cognitive understanding. I also use FP approaches all the time in OO languages (like C#), which I believe is more aligned with where the general purpose language world is moving.

Abstractions are drawn along different axes in both OOP and FP.

The showcase example "Circle, Square, Rectangles are kinds of Shapes that have area" represents an abstraction that is present in the conceptual schema (aka Domain Model, aka Universe of Discourse, aka "problem space"), regardless of implementation style.

Likewise, what you call "mathematical abstraction" (and I'd prefer to call a "implementation model") is present both in OOP (eg "visitor pattern, inheritance, facade") and in FP (eg "fold, pattern match, monad"). I don't really think the difficulty in groking "visitor" is much different from groking "fold".

I don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?

I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html

That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But for an IDE's parser, or even for a new coder discovering the codebase, it's pretty tricky to figure out what the code does.

If somebody is ultra-familiar with Common Lisp but for some reason never learned how the loop construct worked they might be stumped when they encounter the following code:

    (loop for x in '(foo 2) 
          thereis (numberp x))

What does that do exactly? What will it evaluate? What will it return? Which one of these symbols are special keywords and which one just refer to variables or functions?

Meanwhile if you code in, say, C, the macro system is so crappy and clunky that you basically avoid it for anything complicated. Writing a similar LOOP macro in C would be an absolute shitshow (not that it prevented people from trying). As such C code tends to be much more verbose, but also much easier to follow if you know the core rules of the language.

That's an interesting theory, but not true in practice. Common Lisp IDEs are great and don't have any problems with macros. Even going back to the 70s and 80s, with Lisp machines.

Using Slime, the Common Lisp IDE mode in Emacs, there are at least four ways to answer your loop questions:

1. Ctrl-x, Ctrl-/ to look it up in the Lisp spec

2. Alt-. to jump to the definition

3. Alt-x slime-macro-expand-1 or Alt-x slime-macro-expand-all to see what code the macro generates

4. Execute it in the REPL and see what it does.

Option 1 only works for things defined in the standard, obviously, but options 2-4 work for everything.

Perhaps if Macros where not such a mainstay and powerful element of some FP langs (I am not arguing against them), this argument would not be so strong. Macros in C/C++ are difficult for IDEs to deal with too, save for constants. Seeing though that macros are near fundamental to some FP langs, I understand better the driver for the design of Keli.

What gave you the idea that most FP uses macros? Much code in functional languages uses no macros at all. Perhaps you are confusing FP with Lisp.

Read the OP link.

Fold Over a Monad? You mean like:

``` ourReportAccumulatorFunc :: Monad m => m a -> m a -> m a ourReportAccumulatorFunc = blah

ourFunc :: (Foldable t, Monad m) => t (m a) -> m a ourFunc = foldr ourReportAccumulatorFunc someUnitValue ```

Why do you think a fold would be hundreds of lines outside of the business logic?

Quick tip: indent 4 spaces to get code formatting.

Actually it's only 2 spaces.

  Like this.
    Not this.

I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

Imperative languages have slowly been adopting some of these. 20 years ago you had people talking about how things like map and filter are confusing but nowadays most imperative languages have a version of it so obviously it isn't that confusing.

I don't know if this counts as irony, but here goes:

The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!"

Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place!

* Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples

> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

What you describe as a problem sounds like a solution to me :)

I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions.

That avenue of discussion sounds potentially valuable and fun to me :)

Reply on news.ycombinator.com