I love this so hard. I've been a dev for over a decade and just recently discovered functional programming (in a now undergraduate academic sense) and it has changed all my code. Things are so much simpler, easier to follow, and far far less code as I focus on data structure as state, and functions as things that operate on the data structures. Everything is just so much simpler now.

Won't pass code review till you can use dependency injection to pass a + operator mock for testing.

It doesn't even implement IIntegerOperation!

Ugh. Relies on mathematical assumptions that may not be correct in other realities.

-1; please add a logging/tracing call in your add method. Since that introduces impurity, make an algebra for effects you can do with logging, construct the program as a free monad in that algebra and evaluate it.

With great comedy, you never know if they're being serious...

This is one reason I hate our industry. No one engineers anything. They all just abuse OOP so that code is packaged together in some arbitrary heirarchy and then refactor it every single time a user story is added.

Not only that but there's this obsession(?) with doing things as quickly as possible. No matter what task it is on a story it is always, "should only take a couple hours". NO! Stop! You're training your managers to think that every task can be done in two hours! Give yourself some time to stop and reason about the code you're writing AND integrating into the larger system. Be patient. Be thoughtful. Be careful.

Now, I'm not advocating taking a 3 days to do this. But stop with the "couple hours" crap.

Do note that in a corporate setting, this obsession is primarily due to Project managers, Implementations, and even Sales who don't have a hand in the actual development expecting projects to be finished quickly, and to "just work."

When these groups hear the words "Agile Development" which was a common buzzword in recently past years - they take it literally - "moving quickly."

I completely agree, and it is often the cause of absolutely unnecessary bugs, stress, inefficient code, and developers often precipitate this bad obsession. But it comes from, and is ingrained from, somewhere else.

I think it's easy to blame others, but programmers are optimistic by nature and bad at estimating. Also, I think all of us have had the opposite scenario where a request comes in from a business-minded person that they think will take forever and it turns out to be trivial. It feels great to do a lot of good very quickly, independent of what the project schedule says.

This is so painfully true. Sprints are organized to have very little time for technical debt and refactoring. From time to time there is a technical debt sprint that addresses all the wrong issues.

But there is plenty of time to endlessly maintain crap code that should simply be rewritten. Plenty of hours to endlessly debug hard to debug code, for that time is not an issue. But to rewrite something that really needs to be rewritten, there is no budget for that.

In the end it takes much more time to maintain bad code than to rewrite it, the users have bad user experience and there are endless bugs.

Software factories are agile only in the view of agile consultants. This much process where developers are basically managed like assembly line workers is the antithesis of agile: agile should be about collaborating together to solve a problem with very little process: "Individuals and interactions over processes and tools"

If we forced everyone to switch to Haskell, do you think this would really be any different? People would still do the bare minimum to implement the latest user stories, because that is literally what the boss is paying for.

We force everyone to switch to Haskell. OK. Even the fair-to-mediocre programmers? Yes. Who tend to program by copypasta and change stuff until it gets the right answer? Yes.

Run away. Run far, far away. You don't want to see what "design patterns" and urban legends these people layer on top of Haskell to make it intellectually manageable.

I remember being a sophmore in college and I understood the basics of haskell (not really monads yet) and we worked in groups. My partner was very intelligent, but didn't have a grasp on the language at all.

For the final project, we had a problem that I didn't understand well, but he couldn't use the language effectively. We ended up having him work out the problem incorrectly in a shared notepad and I would refactor his broken code into something that worked. It was a mess. I'm pretty sure I've seen worst things you can possibly build in haskell -- and they are bad.

> You don't want to see what "design patterns" and urban legends these people layer on top of Haskell to make it intellectually manageable.

Do share examples if you have them.

I think the point is to not force any single paradigm. OOP is what is being forced today, but it would also be bad if the industry forced functional programming. Large programs typically call for multiple styles of programming. One piece may suit an imperative style, another functional, another logic/relational, another object-oriented, etc. In general, I think OOP is nearly always the wrong tool, though.

I'm in university right now and there is an object-oriented programming course (which is required by most other advanced courses), but no functional programming course. That shows how skewed the industry is. It's a pretty forward-thinking university as well.

OOP is sometimes the right tool, but most times it definitely is not. It's important to be able to know your tools and choose the right one. The current situation is disappointing though.

In Haskell? I'm afraid the bare minimum is the most abstract possible engine with business rules added on as data or high level function application.

But I'm not really disagreeing. It's just that those people will spend months and months on some stupid repetitive concrete code, while the smart way would take a week, and the OOP way would take 3 weeks in Java.

Are you saying you prefer example 2, in the comment you replied to?

In Java-land, this seems to be the kind of thought process referred to as "engineering". Read the code in any random Spring project, for example.

Personally, I prefer writing simple code for the job at hand, and, yes, refactoring when I find two or more places where the same code can be re-used. And even though I develop mostly in Java, the most "functional" solution is generally the one with the least complexity, and easiest to debug.

I definitely hate solution number 2.

One major problem I find with OOP is that it is often requiring refactoring. Every time you shove something into an object you actually take away from it.

One thing that greatly inspires me from Haskell is that it does have design patterns, but they are based on category theory. Math is the ultimate tool. I don't think we can accidentally "create" something as richly descriptive for describing the benefits and problems for using a certain pattern.

I'm having trouble understanding your definition of "refactoring", then.

When I refactor, it's almost always to eliminate repetition and make the code more concise. But doesn't the same thing happen in a functional program? If you find the same code twice, refactor into a single function.

I'm getting at the idea of having to rearrange the code inside classes because your original assumptions have changed. Sometimes this involves moving stuff between classes. This is especially messy if the class has any member variables or relies on private functions.

I think you need to pass it a NumberFactory instead of this magic dot-dot-dot syntax, I can't read it.

Your first example is actually procedural. Needs more lambdas.

It never lasts long enough to get complex, it appears in a virtual functional/anti-functional pair and then they annihilate each other.

Only in the presence of a powerful gravitational force, like the edge of a corporate programming style guide, will one of the pair be sucked into the maw, leaving the other to accumulate cruft.

For example, the second can incorporate two-way binding as noted, logging, synchronization via Operational Transforms, and so much more...

> Needs more lambdas.

I'll be using this in every code review from now on.

I'll need an interface for that so I don't have to read into the code to see what it does.

Your design lacks a `Factory` I think. You don't use design patterns enough.

It’s factories all the way down.

So if you have some object named Obj, and you have some interface for it, and you have a factory that creates objects matching that interface, and that factory has an interface, then what do you call the factory that builds implementations of that interface?

A.) IObjFactoryFactory

B.) IIObjFactory

C.) IIObjFactoryFactory

D.) An abomination upon mankind.

E.) IObjFactoryIFactory

JavaProxyEnterpriseBeanConnectorAbstractInterfaceFactoryImplementationMockup

or something.

Like "functional" programming can't be abstracted so it becomes way too generic.

But where's your specs?