The pipe feels like a block of restricted statements, `peekErr` and `scan` recreate conditionals, the Maybe monad behaves like a try-catch here, etc.

Of course there are differences, like `map` working on both lists and tasks, as opposed to a naive iteration. That's cool. But this new programming language comes with limitations, like the difficulty in peeking ahead or behind during the list iteration, reusing data between passes, and not to mention the lost tooling, like stack traces and breakpoints.

I've written many (toy) programming languages, the process is exactly like this article. And it feels awesome. But I question the wisdom of presenting all this abstract scaffolding as a viable Javascript solution, as opposed to a Javascripter's introduction to Haskell or Clojure, where this scaffolding is the language.

I've worked on some big TypeScript code bases that make heavy use of sort of FP the article promotes; dealing with stack traces and debugging the code is incredibly painful. Jumping around between 47 layers of curried wrapper functions and function composers that manage all state mostly in closures is a real drag.

Until the tooling is better, I can't recommend these idioms for real work.

TBF, there is a kind of beauty to the approach and as you really dig into it and understand it, it can feel like a revelation. There's something addictive about it. But any feeling of joy is obliterated by the pain of tracing an error in a debugger that isn't equipped to handle the idiom.

This leads to fewer errors than the imperative/object-oriented paradigms, and greater development velocity (and quicker developer onboarding, and better tools...) than the 100%-purely-functional strategy.

Hopefully, over time, we'll get functional programming techniques that can easily model more and more of real-world problems (while incurring minimal programmer learning curve and cognitive overhead), making that remainder get smaller without extra programmer pain - but we may never eliminate it completely, and that's ok. 100 lines of effectful code is far easier to examine and debug then the entire application, and our job as programmers is generally not to write purely functional code, but to build a software artifact.

The above applies to type systems, too, which is why gradual typing is so amazing. Usually 99/.9% of a codebase can be easily statically-typed, while the remaining small fraction contains logic that is complex enough that you have to contort your type system to address it, and in the process break junior's developers' heads - often better to box it, add runtime checks, and carefully manually examine the code then resort to templates or macros parameterized on lifetime variables or something equally eldritch.

(and, like the above, hopefully as time goes on we'll get more advanced and easier-to-use type systems to shrink that remainder)

JS with Ramda (and an FRP library, if needed) is the sweet spot for me. I use a lot of pipes() but usually don't break them down into smaller functions until there is a reason to; but FP makes it trivial to do so.

We maintain a service which is making heavy use of Ramda. It seemed like the right tool for the job, because the service is mostly doing data transformation, and the code ends up "clean" and terse. However, we found that onboarding people who are not familiar with FP is time consuming and often people outright refused to learn it. We decided to ditch Ramda, rewrite the service in vanilla JS, prefering immutability where possible. We're about halfway done and it was definitely the right decision. Sure, `R.mapObjIndexed(doSomething, someObject)` is simpler compared to `Object.fromEntries(Object.entries(someObject).map(doSomething))` and now there's a ton of multi-level object spreads, but at least it's simple enough to understand for anyone familiar with JS.

We also came up with a `pipe` function that handles Promises. It makes chaining (async) functions very convenient:

const pipe = (...functions) => (input) => functions.reduce((chain, currentFunction) => chain.then(currentFunction), Promise.resolve(input));

I couldn't come up with a succinct way to say exactly this, since this is very much how I am with it right now. Thanks for that.

I will add I'm comfortable with, and prefer, map/select/reduce over for loops where provided.

That said, you need these things less when you don't have mutable state and you do have referential integrity so you can zoom in on the critical path of side effecting code.

The only problem I encountered regularly was that bugs did only manifest in the optimized versions not in the debugged ones.

I would strongly object this.

Have you seen ZIO?

https://zio.dev/

(Without tooling the stack traces can be noisy.. but that's incidental in this discussion context)

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

It took me years (and Elixir) to get past the "here are some words, some mean what you think, some mean something completely different to what you know, some mean almost the same thing. Also here's 30 overloaded operators that you have to juggle in your head and we wont introduce things like variables for another 4 pages." without running back to something imperative to actually build something.

Functional programming's great when you have immutability to drop an entire class of bugs and the mental energy that accompanies that, can pass-around and compose-with small functions easily which makes writing, testing and figuring much simpler and can make your brain click that "its all data" without trying to over complicate it by attaching methods to it.

Honestly I think that's 90% of what the royal You needs to understand to get FP and actually try it. Selling people on "its all stateless man" or other ivory tower tripe is such garbage because (as the tutorials always point out) a program with no state is useless, and then the poor shmuck has to learn about monads just to add a key to a map and print something at which point they're asking "how was this better again?"

I think a lot of the friction you mentioned comes from learning imperative programming first. Our vocabulary, tools, and even requirements come with an implicit imperative assumption.

PS: I didn't downvote you, though your tone is harsher than I prefer for HN.

Oh, that's how it works? That actually makes sense. Thanks!

Some traditional CS algorithm? Mutable it is. But a compiler with different passes is a great fit for the FP paradigm.

But even if we go to pure math, you will have constructive proofs beside traditional ones.

There are plenty of programs and libraries written in "imperative" languages like Python with lots of functional style applied. That should be the starting point, not sermonizing about whether a monad can even be defined with English words.

"A monad is just a monoid in the category of endofunctors, what's the problem?"

/s

None of the concepts are particularly complex. They're unfamiliar, sort of, but they're not insanely obscure.

But then there's the labelling. If an ordinary for-loop was called a yarborough and a function call a demicurry it really wouldn't help with the learning.

I realise the concepts are supposed to map[1] to category theory, but category theory stole words like monad from elsewhere anyway.

[1] Ha.

German, Polish, and Chinese programmer all learn what "for" means.

And anyway, Java calls functions "methods", yet somehow we survived.

Imagine you're a Chinese programmer. Obviously a lot of open source documentation is in English, so you have to learn basic English anyways (I'm bilingual from an early age, but most people struggle if they start the process even in their teens).

Then you see English-speaking programmers talking about yarborough and demicurry as if they were English words. Now you're majorly confused. Worse, an encyclopedia of philosphy tells you that it means something (see eg. https://plato.stanford.edu/entries/leibniz/#MonWorPhe ) What's the actual connection? When you ask, people casually tell you to read up on category theory, which is apparently something they teach to advanced Math majors. Remember we're struggling to learn basic English here!!!

Eg: in Python you get `dict` ... In Haskell you get very specialized versions of you need them. Do you have integers as keys? `IntMap` is your friend. Hash able keys? `HashMap`! Don't know anything about your keys except for it a key is different from another? You still functions that tread a list of tuples as a map.

Yes that's exactly my point and why no one cares about how great a monad is when trying to learn FP.

Idioms and quirks come after rote memorization of basic vocabulary and sentence structure, which are then used to learn the idioms and quirks. I think Bongo is saying FP-ers are skipping the basic vocabulary part and jumping straight to the idioms and quirks.

It was interesting in 2015/2016 to see co-workers learn some of that basic vocabulary of functional programming without realizing they were touching on it, using map/fold/etc when learning React.

is same as

unit(1).chain(add(1))

That's the beauty of immutable data.

2. the beauty of immutable data isn't in hiding meaning behind meaningless piles of functional abstractions

A hundred percent. FP for me, is "let's stop gluing state and functions together for no reason" and get all the benefits above. I understand pure functions, avoiding state, closures, and using first class functions as the basic building blocks of creating higher level structures.

When it becomes "a functor is a monoid of the schlerm frumulet" - ala the typical FP advocacy blog / latest React state management manifesto masquerading as library documentation, I zone out. The odd thing is, I don't feel I've lost anything by doing so.

The two main FP things that you need to learn to do Elixir well (IMO) are thinking about data structures first, and purity. Choose the right representation of the data at each stage and then what functions do you need to move between each. Make those functions side effect free (but not obsessively). Then you put your stateful code in GenServers and you have useful real code and most of it was incredibly easy to test.

Let's say your data is a log file and you want to load everything in memory. You write the code that returns the data, which you either store in a variable or compose with other functions. At the end, you compose all of these functions in your programs. Everything is an expression, meaning that you can extract things easily into functions. This is how you make things readable. `load-log-from-file` and `auth-failure-count` is better than keeping everything together in a single function.

I doubt it was easier to reason about at all. The code set an error var on a number of if / else conditions. They then used a separate flag, so that a double write wouldn't be necessary. ie. int flag = 0;

int err; // notice no initializer

if(stuff) { flag = 1; err = 1; } else {}

if(other_stuff) { flag = 1; err = 2; } else {}

if(flag) { LogError(err); }

I follow the "avoid double write" convention too, but in some cases, it can become very difficult to reason whether a local is uninitialized; this is a pretty terrible class of bug, because you work with garbage data off of the stack.

Setting to zero at declaration makes it much clearer that it will never be uninitialized, but it's essentially meaningless and arguably a form of dead code.

Maybe someone will suggest a redesign? More functions, smaller functions? It seems that there's a strong (though unpopular) argument that you should use medium sized functions, and some teams insist on doing this. In some cases, it can be easier to find the content, verify specifications.

Edit: On second thought I can see we didn't avoid the double write, just did it in a different variable. So I don't understand what the author's point is, lol.

    bool go = true;
    if (go) doA(&go);
    if (go) doB(&go);
    if (go) doC(&go);

I'm generally pretty okay with similar patterns over accumulators, as long as it's clear that the purpose of that variable is to be an accumulator. If we're just overwriting a variable because we don't need the old value anymore, or something like that, I'm much less charitable.

A big benefit of functional programming, for me, is to learn the safe roads as explicitly as possible, so that you can then identify (and use) them when they aren't so well signposted.

If you are doing a lot of work inside those branches it may be worth a refactor to simplify the branching logic.

The fact that it set off the static analyzer is very annoying too. Now I have to somehow debug the static analyzer, or just accept the risks. I've had some uncomfortable experiences assuming the analyzer is wrong and ignoring or suppressing it... theoretically, the static analysis will do a much better job than a human, so I can't help but doubt, and feel I missed something.

Just as an aside, some teams try to avoid multiple return paths. I believe there's some studies indicating a higher incidence of bugs... for a solid code quality reason you could theoretically deviate.

I don't really see how it could increase bugs over setting a flag. With a function that sets a flag there's always a risk that you change the flag accidentally after you already hit the value you want. Which is the same risk as returning earlier than you want, I suppose.

I just find the multiple return paths easier to read, debug and understand, rather than stepping through to trace the value of the flag, you just figure out which return is firing.

The more I write, the more I lean into immutability though. Bugs happen when values can change that shouldn't.

From experience, I have never once heard anyone from higher-level languages (above C & C++) complain about "multiple return paths". That said, for C, I definitely understand the need for reduced return paths due to lack of auto-free / destructor mechanics.

I actually prefer pcollections: https://github.com/hrldcpr/pcollections

AtomicReference + immutable data types is a really nice way to program in Java, and is basically the way most Clojure programs are written.

Surely this would cause some strange performance outcomes with, say, a gradually built up immutable list.

I'd rather focus my energy on adding unit testing, and refactoring to be testable. If you have easy-to-read unit tests that cover all possible edge cases, I stop caring (as much) about how the actual method is written. Be as optimized/clever/concise as you want. I don't care if you reassign your local variables.

The only excuse is when I am doing something algorithmic and that would improve the performance.

By extension I prefer local variables over class state and static state and other “self managed lifetime” stuff like that.

And I am a GC blub programmer, I don’t use Rust or C.

Stuff like this is the reason why functional programming is synonymous with inefficiency and why Real Programming™ is still done in languages like C.

You'd get the benefit of easier to reason about code everywhere you used it, even if others within the codebase don't. Using that argument, we would argue that it's never worth trying to find a cleaner way to implement something because maybe some intern some day will do something weird in a different part of the code base. We don't have to drop down to the lowest common denominator for code quality and we benefit every time we simplify things, even if not everyone does.

You see them very rarely, and usually with a narrow scope.

I agree that you probably can't enforce an absolute rule of no mutable variables. But making it the exception rather than the rule (e.g. require it to be justified in code review) makes a huge difference.

Use the best tool for the job.

You start out with code that will not win any beauty awards but it gets the job done. It's easy to understand by programmers of any seniority, it's simple to debug and reasonably easy to put in an automatic unit test.

Next, you add all kinds of vague, poorly named meta utilities that don't seem to solve any tangible real world problem. You even mess with built-in JS methods like map. The code is now harder to understand and more difficult to debug.

A massive pain is added for some theoretical purity that few even understand or will benefit from. I'll double down on my rebellion by stating that the portability of code is overrated.

Here we're writing code to format notification objects. In our overengineering mindset, we break this down into many pieces and for each piece consider reusability outside this context to be of prime importance.

Why though? Why not just solve the problem directly without these extra self-inflicted goals? The idea that this is a best practice is a disease in our industry.

Most code that is written prematurely as reusable, will in fact never be reused outside its original context. And even if it is reused, that doesn't mean that outcome is so great.

Say that the sub logic to format a user profile link turned out to be needed outside this notification context. Our foresight to have made it reusable in the first place was solid. Now two completely different functional contexts are reusing this logic. Next, the marketing department goes: well actually...you need to add a tracking param specifically for links in the notification context, and only there.

Now your "portability" is a problem. There's various ways to deal with it, and I'm sure we'll pick the most complicated one in the name of some best practice.

After 20 years in the industry, you know how I would write the logic? A single method "formatNotification". It wouldn't weirdly copy the entire object over and over again, it would directly manipulate the object, one piece at a time. Error checking is in the method as well. You can read the entire logic top to bottom without jumping into 7 files. You can safely make changes to it and its intuitive to debug. Any junior would get it in about 2 minutes.

Clear, explicit code that requires minimum cognitive parsing.

1. Don't use globals. Zero global variables should be the goal, that way, you avoid "spooky action at a distance" where some code here changes a global that changes the behavior of code over there. A function that avoids global variables is easier to deal with than one that doesn't. If you feel you need to use a global, think about why you need one before adding it. Maybe you can avoid it.

2. Parameters to functions are immutable. That way, you won't have to worry about data changing during a function call. If the parameter can be mutated, can you signal the intent in the function name or signature, so the programmer knows that to expect? Generally, try to avoid changing parameters in a function.

3. Separate I/O from processing. Do input, do your processing, then output. God, I wish the major component I worked on did that (concurrent DB requests)---it would make testing the business logic so much easier as it can be tested independently from the I/O.

Those three things can be done in any language, and just by doing those three things, you can most of the benefit of FP without the mathematical jargon (Monads? How do they work?). There's no need for over-engineered code, and you can be as explicit as you like while keeping the cognitive aspects to a minimum.

I love your answer.. And I love how you can use it in every language.

This is a very good article about the problems with monad tutorials: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

> “Of course!” Joe thinks. “It’s all so simple now. The key to understanding monads is that they are Like Burritos. If only I had thought of this before!” The problem, of course, is that if Joe HAD thought of this before, it wouldn’t have helped: the week of struggling through details was a necessary and integral part of forming Joe’s Burrito intuition, not a sad consequence of his failure to hit upon the idea sooner.

TL;DR There’s no beautiful explanation that will help you understand, you need to get your hands dirty with code.

Purists will say it's not entirely correct, but we don't care about purism :)

Someone correct me if I'm wrong.

For example, the Maybe monad has no state. It sequences operations that can fail. The Error monad aborts the computation and returns an error. Similarly, Min, Max, Product, Sum, Dual don't have an state.

Anyone can rewrite a piece of good, succinct, clear code. Even if its performance is poor.

That cannot be said for clever hacker code that -was- fast until business requirements changed over time and now the guy that used to understand the code is long gone.

It's about recognizing patterns in code that exist all over the place and reusing those existing patterns for the new code you're writing. This way you can break your new feature into say 20% newly written domain specific code and 80% reusing existing patterns. Patterns that help with composition, enforcing invariants, simplifying writing test-cases, and more clearly signaling intent.

For example, if you provide a monad instance for your "formatting notification objects" I will probably understand how to use your library without even reading a single line of implementation at all. Just by scanning a few type signatures.

This way you and your team mates have a huge head start in understanding your new addition to an existing code base. This is a great win for everyone!

My first and main point is that 80% of software developers, the silent majority of so-called "bread programmers", do not grasp these concepts. So even if the concept is great, it doesn't matter.

Second, and this is purely based on experience, I do not subscribe to the idea that your envisioned way of writing a new business feature is very realistic or useful. It leads to dependency hell, difficult to understand code, which is difficult to debug. I don't even subscribe to the idea (anymore) that if you're asked to implement a business feature, that it is implied that you should write it as if it can be torn apart and used for some imagined other feature. Nobody asked for that, we just made that up.

One can say that I've become a DRY infidel. I don't expect you to agree, very few would agree. Yet I've arrived here for a reason: 20 years of headaches looking at "best practice" codebases.

IMHO, DRY is only useful when the underlying problem structure has a fundamental overlap with an existing problem. Incidental overlaps should be kept separate. That's where the premature abstraction problem comes from. Often in times of changing requirements, you can't predict where things will lead to.

I suspect it's something to do with how OOP is taught. Universities start with abstract concepts and apriori principles (eg. encapsulation, polymorphism, etc.). So juniors fresh out of school tend to feel compelled to make up abstractions to be a "good citizen" so to speak.

OTOH I actually started by encountering issues with duplicate code and repeated patterns (which was a problem mainly because I had to copy and paste and retype too much code), and only afterwards I learned about how OOP techniques could help solve these problems. For me personally they were just practical tools to solve practical problems, instead of a moral imperative. I happily write very specific code to do specific things instead of pretending there's some apriori abstraction waiting to be discovered.

IMHO there's a humility in admitting that there's more than one way to look at (i.e. perceive in abstract manner) things.

Right… but is that not the point of these articles? To teach those programmers these concepts so they can get the benefits the GP commenter is talking about?

Your comment there seems to presuppose that they can never learn, unless I’m misunderstanding!

There is nothing I love more when editing a feature than having 10 files open. :)

Or having to later "de-nomalise" previously DRY work because feature X doesn't need what feature Y now does, but they share code, so now I've got to dance.

I used to live all the best practices, but over time learned that the number one enemy in a codebase is complexity. 90% of software development is maintenance. People doing maintenance are lowly productive because the vast majority of time is spent on trying to understand how things even work, debugging, and making changes in a way that is safe.

The reason code is complex are abstractions and dependencies. Many of which are of a questionable or negative value and never deliver their imagined benefits. Hence, instead of "abstract by default" and seeing DRY as some religion, I abstract when value is real, proven and outweighs the massive downsides of doing so.

Imagine that we'd need to write a recipe. Sane and pragmatic people would write it as a sequential step of instructions. If a software engineer were to write one, just to follow the recipe you'd need to have 23 additional papers each describing a sub step referred to from the main instructions. Next, we would abstract each substep into "Motion" and "Activity" generalizations. This way, you can reuse "Motion" when you walk your dog later that day. Quite obviously, motions can fail so we extend it with a MotionError, which is a sub class of Error. MotionError has a Logger interface. These 3 super abstractions are useful, instead of just directly saying that you failed a recipe step, we can now apply failure wherever we want, even onto life itself. Since recipes are written in a language, we should abstract Language, itself a composition of sentences, words, characters and glyphs with a Dictionary interface, which itself is an array of Name and Value objects, that we might as well generalize as Thing.

Anyway, those were recipe steps. Next, let's do ingredients, also known as immutable multivariant singletons. But not really, because as we follow the instructions, the ingredients morph into something else, which we'll solve with a Morp object, which holds an interface StateChange, consisting of two State objects, which are Things. A ThingsIterator takes care of handling multiple things but not in a way you'd expect, we'd override map() because I really feel my Thing is special. Thinking of recipes, they can potentially come from any source so we'll implement Verbal (an abstraction of Language), Database and the jungle that comes with it, all neatly wrapped into MoreThings.

Next we redo all of his by writing unit tests, so that our software that by now implements most of the universe is qualitative. It's math.

Or...we can just write the damn recipe.

A "functional" recipe is just as simple and straightforward as an "imperative" recipe.

Over-abstraction on the other hand, can be introduced with imperative object oriented programming just as easily as with functional programming.

for example, elizabeth david (never a one for accurate measurements) has a great recipe for beef with olives, which comes down to onions, garlick, bay leafs (other herbs to taste) olive oil, lemon peel, beef, black olives, red wine. then just cook them. any experienced cook will have no probs with this - the interesting thing is the combination of beef and olives. all the quantities are somewhat irrelevant and can be adjusted to taste.

whereas a computer program must be pin-point accurate in all details

analogies == bad. imho

sorry i went on a bit there

:)

I think this is the only part I disagree with. Immutable data types make it much easier to understand code, because everything is local. You don't have to worry that some other part of the code base might have a reference to this object, and could be manipulating it out from under you.

Like calling do_something(object) might call something inside it that changed the object, but not likely unknown..

Now if you're talking about threading. Honestly, I worked as a c++, java, rails and now elixir dev for > 20 years. I can't tell you how many times I built something that threaded, but not all that often. It's just doesn't come up all that often.

Just because you create them yourself doesn't mean they aren't there.

I remember one meeting where clueless business person told developers (including me) that we need an *abstract* solution for a problem.

It took me quite some hours to explain to other devs that for this business person abstract solution is not what they think it is. Business person wanted CRUD app where they could configure names for database entries where developers wanted to make some fancy data types to be used with parametric polymorphism.

Ah, yes, the most intelligent people tended to take it up, therefore if I take it up I, too, am intelligent.

That single line in the article encapsulates everything wrong with FP zealots' approach to their advocacy.

Yes you have to be intelligent to understand complex problems and complex solutions. But just because you are intelligent enough to understand a complicated solution, does not mean the solution is "intelligent".

True intelligence is about coming up with solutions where complexity is minimized.

Even though an intelligent person can understand a complicated solution the complexity of a solution strains even the most intelligent programmer. It takes time to ensure yourself that the solution is correct. Whereas with a simple solution that is easy. It takes intelligence to find a solution that is simple and thus easy.

FP is a bit like Assembler. The building blocks are very simple. The resulting programs are not. In a more conventional language the building blocks are not so uniform there are many different things you build your program out of. Think COBOL. Not very abstract code at all. But easy to read.

Conventional languages are more like "Domain Specific Languages" where the domain is building business etc. software. FP gives you the full (?) power of mathematics, it is fully general, not domain specific. Yet DSLs are often a better fit for the task at hand.

I do tend to find FP does attract people who've really embraced jargon.

Kind of like how a faster car in the hands of a less talented driver won't make them faster, but might just cause them to crash? Whereas a talented driver would pick a faster car and actually benefit from it?

Personally I think it's not so much about intelligence or talent, but passion. In think the developers who demonstrates that they've learned and tried more development techniques and styles, that shows a passion and interest towards software development, engineering and comp-sci. That passion is often key to success and long term performance.

There's probably a cutoff between talent and passion, where passion alone probably has some limits, but also where talent alone has limits as well. If you find someone with both though, that's a pretty good sign.

The question is, are talented developers drawn to FP, or is it passionate developers that are? Or those that have both?

And the other question is, can FP make someone more talented? Can it make them more passionate?

You dismiss or disagree, because you don't like the author's attitude?

IMO, the author makes an observation of familiarity bias and resistance to change. These are just how humans in general tend to behave, and it's not unreasonable to think that these factors are in play.

Moreover, there is an overlap between intelligence and curiosity / openness to new experiences.

If someone is not particularly curious about FP, they shouldn't take it personally: nobody is suggesting they're not intelligent-- that's not what's being said here.

Neither of which makes sense when you look at something like Git or Linux, where someone decided to make a whole new thing without dependencies, and it displaced the previous thing, and the people who use it don't need to care what language it was written in.

In the world of programming (and I guess elsewhere, too), there are simply many more aspects at play when "choosing" the programming language than purely how good the language itself is. Easiest example is Javascript were it's simply widespread because it was the only language available in the browser. I recommend again that you watch the video :-).

I would strongly recommend reviewing the functional-relational programming model described in this paper - http://curtclifton.net/papers/MoseleyMarks06a.pdf

The overall theme goes something like: FP is for handling all your logic, and RP is for arranging all of your data. Some sort of relational programming model is the only way to practically represent a domain with high dimensionality.

For real-world applications, we asked ourselves: "Which programming paradigm already exhibits attributes of both FP and RP?" The most obvious answer we arrived at is SQL. Today, we use SQL as a FRP language for configuring our product. 100% of the domain logic is defined as SQL queries. 100% of the domain data lives in the database. The database is scoped per unit of work/session, so there are strong guarantees of determinism throughout.

Writing domain logic in SQL is paradise. Our tables are intentionally kept small, so we never have to worry about performance & indexing. CTEs and such are encouraged to make queries as human-friendly as possible. Some of our most incredibly complex procedural code areas were replaced with not even 500 characters worth of SQL text that a domain expert can directly understand.

Okay maybe it works for you, but I've worked on one of these systems for a financial engine with over 10m SQL LoC. This was a big product that was ~15 years old and used by dozens of companies having bespoke feature flags that changed significant parts of the calculation engine. Everyone except a couple grey beards who'd joined straight out of university left that place after a few years because of how insane it was to work on and we all became way too interested in good architecture design from that experience. My friends from that time who I still keep in touch with are almost entirely working on FP-based environments now.

But I think the basic premise of combining functional and relational is valid. At the very least it avoids the object relational impedance mismatch.

SQL isn't built with sensible decisions. Delete/update forget a where clause? Whoops. Lots of traps like that. Also it's not easily testable. Domain concepts don't always easily map.

Part of the reason is also the thinking and philosophy behind DBMSs as interactive systems. Especially with regards to code.

A function doesn't just exist. You create a function and it lives in the database until you alter it or drop it.

This creates a different (temporal?) impedance mismatch with standard code management tools like version control. The result is most often a maintenance nightmare.

- I can understand why this might appear as hell to many. SQL is unwieldy and doesn't play nice with many tools we use to make life easier.

- I agree with the fundamental premise that a combination of functional and relational principles can be highly effective for data heavy scenarios

- i disagree that pure SQL is the solution to achieve this. If using MS SQL Server, there are great opportunities to leavrage the CLR and F# (with caveats because F# gets less love than C#). You can write functional logic once and use it both outside of the database and inside the database. PostgreSQL has extensions for other languages.

I am sure in the future, .Net Core and Standard will be supported.

I agree that you are technically correct. It is simply declarative in nature. I've got a habit of conflating these terms. Functions aren't first-class citizens in SQL. We also have some UDFs that are impure (because the real world unfortunately exists).

I'd be perfectly happy to rename this a "Declarative-Relational" programming model if that sits better with everyone.

BAD: copying data needlessly and turning trivial stuff into a functional pipeline that is impossible to debug. You want your code to read top to bottom like the problem you're trying to solve, if at all possible. If your call stack looks like map, fold, reduce you've introduced a ton of complexity, and why exactly?

Every programmer should understand functional programming. Higher order functions can be super useful. Immutable objects are invaluable for preventing subtle bugs. But if you feel the need to transform simple linear code into a map of higher order functions because of some abstract benefits you're probably doing stuff that's too easy for you and you should get your mental challenge from solving a more difficult problem instead.

I stand a better chance understanding the sequential code than a complicated recursive (edit: nested) monad. Depending how it was written.

I can probably understand Kafka pipeline's or a functional map, reduce pipeline.

My parser for my programming language which I'm building is a recursive Pratt parser but it's written in Java.

I want to understand functional programming better. I am interested in software transactional memory and parallelism. I am aware Erlang and Go use message passing but only Erlang is functional.

In theory functional code can be parallelised due to immutability but you need some kind of communication to indicate transference of values. Imagine a pipeline where you need to share a value to a few other threads. I'm aware Haskell has software transactional memory

Isn't that simply because you're a Java developer (as I understand from the rest of your post)?

> I would rather inherit someone's stateful JavaScript or Java than a complicated codebase by a seasoned Clojure, Haskell, Scala developer. I stand a better chance understanding the sequential code than a complicated recursive monad. Depending how it was written.

True, but you add here the "complicated" attribute deliberately .. usually it is the other way round. The functional approach code is simpler to read and reason ( and usually not with much recursive monoids), while the believed sequential program has so many "concurrent" paths (even if there is no real concurrency, but just in the many hidden ways how the super distributed statefulness is manipulated).. not?

It spurned a chain of events that you might find interesting.

I am interested in parallel software and multithreading, so that's the kind of software I enjoy writing.

The branches of a single threaded software can think of potential future interleavings.

Your post inspired me to think of programs as "circular" or not. That is, they return to a steady state and can function properly no matter how many times they run and whether or not the execution is interrupted at any point.

A program that is interrupted can leave the program state in an invalid state that cannot be recovered.

So I started writing a parser to parse an assignment language. I plan to track object identities membership over time and see if objects get stuck in processing - they stop moving.

  program {
      available = {};
      assigned = {};
      main {
        program = programs {
           current_available = program.available {
                available += (current_available, 1);
                assigned - current_available;
            }
            item = program.requests {
                available (=) item {
                    program.answers += item;
                    available - item;
                    assigned + (item, 1);
                }
            }
        }
      }
    }

  program {
      requests = [];
      requests += (add, 1);
      main {
        item = answers {
            new_requests = [(add, 1)];
            available += (item, 1);
            new_request = new_requests {
                requests += new_request;
            }
          
        }
      
        answers -= answers;
      }
  }

I'd rather inherit a complicated Java program than a complicated Scala program. But I'd take a well written Scala program over a well written Java program any day of the week.

Since I quit, the entire new engineering team quit and it looks like the company is going under. Functional programming is a big mistake for some real-world code.

Generalizing much? I write C# for a living, Elixir in my free time, I would take Elixir codebase any day of the week. If you try to write C# in a strictly functional fashion it's going to be shitshow as well. Moderation is the key, using immutable data structures, getting rid of side effects if possible etc.

You had a bad experience because you and/or people you worked with simply tried to fit a square peg into a round hole, you didn't get it in, threw a tantrum and now you're blaming all the squares for being bad.

I on the other hand, after learning functional language, have trouble looking at most code written by pure 'OOP developers', most of it is a spaghetti shitshow of hierarchy classes, dependencies and jumping across 20 different files of factories and providers because DUHH sOlId and ClEaN. That doesn't mean that OOP is a 'mistake for real-world code'.

I honestly think these are the important bits of this story. The startup outsourced their backend to an agency, then tried to replace the agency with a brand new internal dev team.

There's no way that story ends well, regardless of the paradigm the agency chose or how skilled they might have been (probably not very). Every codebase is unmaintainable when the team that built it is suddenly replaced.

Peter Naur had a lot to say about this in Programming as Theory Building [0]:

> The extended life of a program according to these notions depends on the taking over by new generations of programmers of the theory of the program. For a new programmer to come to possess an existing theory of a program it is insufficient that he or she has the opportunity to become familiar with the program text and other documentation. What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory, so as to be able to become familiar with the place of the program in the wider context of the relevant real world situations and so as to acquire the knowledge of how the program works and how unusual program reactions and program modifications are handled within the program theory.

[0] https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f...

Not OP but imho, it’s because FP is "sold" as the perfect solution for readability and code maintainability. Just use FP and nothing can go wrong. That’s at least the impression I get when I read about FP.

The fact that one can write abysmal OOP code is nothing new.

To be fair that was the kind of nonsense that was being talked about OOP in the late 90's and early 2000's.

There are no silver bullets, and anyone who claims otherwise is flat wrong.

However most techniques have their advantages, when used well - and I'd say FP has more to offer than OOP in this context.

What I don't agree with the GP is specifically the claims on other languages:

""" Python with immense amounts of spaghetti, C with its hard to control safety, abysmal imperative or OOP code in Typescript ""

These are not sold as advantages for the respective languages. Python doesn't say it's easier for the programmer to write spaghetti. C's unsafe constructs are a known side effect of being closer to the metal (and optimizing for speed at expense of safety). Typescript's selling point is type checking, which is orthogonal to abysmal code.

But FP is just sold as making it easier to make abstractions all the way down. And for many of us FP-skeptics, that's not a selling point, that's a turn off. (And to reiterate my original point - this is the same for Java, OOP and OOP-skeptics)

That’s because it is. FP is not immune to incorrect implementation. Both statements are true.

Only twenty? That'd be a reduction.

If your stack trace doesn't have at least 30 calls of "thingHandler.invoke()", you're not abstract enough.

The emphasis on "some" should be stronger in your comment, otherwise it reads, on a quick pass, as a broad dismissal of functional programming.

Functional programming concepts and ideas have been steadily incorporated in most mainstream languages in the last 10+ years. However, when people move past the language's functional programming primitives, it's when the project enters potentially dangerous territory. Your, and the article's, example of pipes, for one.

Personally, I'd like more languages to incorporate ADTs (algebraic datatypes) for me to be able to "de"layer programs back to a mostly procedural + functional programming. And based on the current adoption rate of FP concepts, I'm not sure we're that far away from having proper ADTs and pattern matching in the most popular imperative programming languages of today.

It feels egregious to implicate "the entire surface area of functional programming" here, when there are other obvious issues at play.

Hard to follow code is mostly a consequence of point-free style in Haskell which is an heresy to be avoided at all cost.

ML typically uses a piping operator to compose code instead and that leads to top to bottom code which is extremely easy to read.

There is zero difference then between a map and a loop. Loops are not read top down anyway nor are function calls. It seems to me you are just more used to these indirections than other ones and are therefor blind to them. This leads to an argument which I consider a straw man personally.

This phenomenon seems to happen more frequently with FP or related tools and languages (RxJs abstraction soup comes to mind).

> RxJs abstraction soup comes to mind

Merely a side effect of being implemented in a language that wasn’t really designed for it.

But their scope can be limited.

Do you have a link to a good one?

[1] https://elixirschool.com/en/lessons/basics/pipe_operator

https://cs3110.github.io/textbook/chapters/hop/pipelining.ht...

If you're talking about a sequence of statements, I've rarely come across such a thing.

Firstly, the mere existence of statements in a language is an incredible complication:

- It forks the grammar into two distinct sub-languages (expressions and statements)

- Expressions compose with each other, and with statements; but statements don't compose with expressions.

- It introduces a notion of (logical) time into the semantics ('before' a statement is executed, and 'after' a statement is executed)

- The times of each statement need to be coordinated. Chaining one-after-another is easy (usually with ';'), but concurrency gives an exponential explosion of possible interleavings.

- The computer often cannot help us spot mistakes, and compilers have very little ability to optimise statements.

This is especially silly in Python, where many common tasks require statements, which often requires rewrites (e.g. we can't put statements in lambdas; hence we often need separate function defs (which themselves are statements); pulling those out may lose access to required lexically-scoped variables, requiring even more plumbing and wrapping; urgh.)

Compare this to functional code, where there's only a single language (expressions) where everything is composable; where there is no control flow (only data dependencies); there is no notion of time; mistakes are more obvious (e.g. 'no such variable' errors at compile time); compilers have lots of scope to optimise; and code is trivial to parallelise.

“Logical time” actually matters when you have side-effects. Of course we can agree code without side effects is simpler to reason about. Unfortunately you need side effects to do anything useful.

"Time" doesn't matter; causality/dependency is what matters. That is modelled quite well by passing around values. For example:

  let hostname = lookup("hostname")
      username = lookup("username")
      password = lookup("password")
      connection = connect(hostname, username, password)
   in query(connection, "SELECT foo FROM myTable")

This form of data dependency is no different than, say, arithmetic: to calculate '3 × (2 + 4)', the multiplication depends on the result of the addition, so it must "happen afterwards". (The imperative equivalent would be 'push 2; push 4; +; push 3; ×;')

> Worth noting Haskell ended up reinventing the statement/expression distincion in the do-notation

Yes, do-notation "desugars" into plugging return values into arguments, like above. This gets a little tedious for things like 'IO', where we pass around a unit/null value to represent "the real world".

Still, a nice lesson from Haskell is that there's value in making things opt-in; e.g. many languages have Maybe/Option, but it's less useful in languages which allow 'null' anywhere; many languages have IO/Effect/Task/etc. but it's less useful in languages which allow I/O anywhere; etc.

What if instead we said

  let connection = connect(hostname, username, password)
      _ = query(connection, "INSERT INTO t1 VALUES ('abc')")
      data = query(connection, "SELECT * FROM t1")
    in print data

The order of execution of code is actually important every time you have such a side effect, and languages that don't strictly define it make this type of thing very error prone.

The language can't "know the order" of these calls, since they are not ordered. No information is passed from one call to the other, hence neither is in each other's past light cone.

If you want to impose some order, you can introduce a data-dependency between the calls; e.g. returning some sort of value from the "INSERT" call, and incorporating that into the "SELECT" call. Examples include:

- Some sort of 'response' from the database, e.g. indicating success/failure

- GHC's implementation of IO as passing around a unit value for the "RealWorld"

- Lamport clocks

- A hash of the previous state (git, block chains, etc.)

- The 'connection' value itself (most useful in conjunction with linear types, or equivalent, to prevent "stale" connections being re-used)

- Continuation-passing style (passing around the continuation/stacktrace)

> languages that don't strictly define it make this type of thing very error prone

On the contrary, attempting to define a total order on such spatially-separated events is very error prone. Attempting to impose such Newtonian assumptions on real-world systems, from CPU cores to geographically distributed systems, leads to all sorts of inconsistencies and problems.

This is another example of opt-ins being better than defaults. It's more useful and clear to have no implicit order of calculations imposed by default, so that everything is automatically concurrent/distributed. If we want to impose some ordering, we can do so using the above mechanisms.

Attempting to go the other way (trying to run serial programs with concurrent semantics) is awkward and error-prone. See: multithreading.

See also https://en.wikipedia.org/wiki/Relativistic_programming

Note that you haven't specified the database semantics either.

Perhaps the connection points to a 'snapshot' of the contents, like in Datomic; in which case doing an "INSERT" will not affect a "SELECT". In this case, a "SELECT" will only see the results of an "INSERT" if we query against an updated connection (i.e. if we introduce a data dependency!).

Perhaps performing multiple queries against the same connection causes the database history to branch into "multiple worlds": each correct on its own, but mutually-contradictory. That's how distributed systems tend to work; with various concensus algorithms to try and merge these different histories into some eventually-consistent whole.

PS: There is a well-defined answer in this example; since the "INSERT" query is dead code, it should never be evaluated ;)

PPS: Even in the "normal" case of executing these queries like statements, from top-to-bottom, against a "normal" SQL database, the semantics are under-defined. For example, if 'query' is asynchronous, the second query may race against the first (e.g. taking a faster path to a remote database and getting executed first). This can be prevented by making 'query' synchronous; however, that's just another way of saying we need a response from the database (i.e. a data dependency!)

Trying to make all statements implicitly concurrent unless they have explicit dependencies is a terrible way to complicate your life. That in some cases you can optimize the code (or the CPU will do it for you) by executing it in certain other orders where it is safe is supposed to remain an invisible optimization.

It is obvious to everyone that distributed code, eventual consistency, and other similar non-totally-ordered examples are much harder to get right than procedural code. Even simple print-based debugging/logging becomes excessively complex if you get rid of the local total ordering.

Even most network-based computing is done over TCP (or, more recently, QUIC) exactly because of how enormously useful having a total order is in practice (even if it's just an illusion/abstraction).

> PS: There is a well-defined answer in this example; since the "INSERT" query is dead code, it should never be evaluated ;)

It's only dead code if you assume Haskell's bizarre lazy execution model. In virtually every other language, unless the compiler can prove that query() has no side effects, the INSERT will be executed.

There are no statements in the above examples, just expressions (composed of other expressions). Evaluation order of expressions is not well defined in "most popular languages", e.g. consider this expression:

  printSecondArgument(
    query(connection, "INSERT INTO t1 VALUES ('abc')"),
    query(connection, "SELECT * FROM t1")
  )

I agree, that's one reason why I dislike statements (see my list in a parent comment)

> It is obvious to everyone that distributed code, eventual consistency, and other similar non-totally-ordered examples are much harder to get right than procedural code.

This is a category error. All code is distributed; the world is partially-ordered. "Procedural code" (i.e. serial/sequential execution) is a strategy for dealing with that. It's particularly easy (give each step a single dependency; its "predecessor"), but also maximally inefficient. That's often acceptable when running on a single machine, and sometimes acceptable for globally-distributed systems too (e.g. that's what a blockchain is).

Forcing it by default leads to all sorts of complication (e.g. multithreading, "thread-safety", etc.). Making it opt-in gives us the option of concurrency, even if we write almost everything in some "Serial monad" (more likey, a continuation-passing transformer)

While C and C++ are extremely commonly used, I would still say that the majority of popular languages fully define evaluation order. Even more so since most of these languages considered they are fixing a flaw in C. Rust is particularly interesting here, as they initially did not specify the order, but then reversed that decision afelter more real-world experience.

> "Procedural code" (i.e. serial/sequential execution) is a strategy for dealing with that. It's particularly easy (give each step a single dependency; its "predecessor"), but also maximally inefficient.

> Forcing it by default leads to all sorts of complication (e.g. multithreading, "thread-safety", etc.). Making it opt-in gives us the option of concurrency, even if we write almost everything in some "Serial monad" (more likey, a continuation-passing transformer)

You yourself admit that serial code is a strategy for dealing with the complexity of the world - it doesn't complicate anything, it greatly simplifies things.

Threads and other similar constructs are normally opt-in and used either to model concurrency that is relevant to your business domain, or to try to achieve parallelism as an optimization. They are almost universally seen as a kind of necessary evil - and yet you seem to advocate for introducing the sort of problems threads bring into every sequential program.

Thinking of your program as a graph of data dependencies is an extremely difficult way to program, especially in the presence of any kind of side effects. I don't think I've ever seen anyone argue that it's actually something to strive for.

Even the most complete and influential formal model of concurrent programming, sir Tony Hoare's CSP, is aimed at making the order of operations as easy to follow as possible, with explicit ordering dependencies kept to a minimum (only when sending/receiving messages).

> That's often acceptable when running on a single machine, and sometimes acceptable for globally-distributed systems too (e.g. that's what a blockchain is).

It's not just blockchain: TCP and QUIC, ACID compliance and transactions, at-least-once message delivery in pub-subs: all of these are designed to provide an in-order abstraction on top of the underlying concurrency of the real world. And they are extremely popular because of just how much easier it is to be able to rely on this abstraction.

Serial code greatly simplifies serial problems. If you want serial semantics, go for it. Parent comments mentioned Haskell, which lets us opt-in to serial semantics via things like `ST`. Also, whilst we could write a whole program this way, we're not forced to; we can make different decisions on a per-expression level. Having rich types also makes this more pleasant, since it prevents us using sequential code in a non-sequential way.

However, there is problem with serial code: it complicates concurrency. Again: if you don't want concurrency then serial semantics are fine, and you can ignore the rest of what I'm saying.

> Threads and other similar constructs are normally opt-in and used either to model concurrency that is relevant to your business domain, or to try to achieve parallelism as an optimization. They are almost universally seen as a kind of necessary evil

Such models are certainly evil, but not at all necessary. They're an artefact of trying to build concurrent semantics on top of serial semantics, rather than the other way around.

> and yet you seem to advocate for introducing the sort of problems threads bring into every sequential program.

Not at all. If you want sequential semantics, then write sequential programs. I'm advocating that concurrent programs not be written in terms of sequential semantics.

Going back to the Haskell example, if we have a serial program (e.g. using `ST`) and we want to split it into a few concurrent pieces, we can remove some of the data dependencies (either explicit, or implicit via `do`, etc.) to get independent tasks that can be run concurrently (we can also type-check that we've done it safely, if we like). That's easier than trying to run the serial code concurrently (say, by supplying an algebraic effect handler which doesn't obey some type class laws) then crossing our fingers. The latter is essentially what multithreading, and other unsafe uses of shared-mutable-state are doing.

Use "from" and "to", which talks about data dependencies rather than temporal dependencies. Most people assume dependency order implies temporal order, and then you introduce them to lazy evaluation to decouple even that.

For example, if 'foo = g(x)' is defined in one module, and another module does 'f(foo)', then the data flow is preserved. If we try to force things to be the wrong way round, we'll get compiler errors like 'No such variable foo'.

Compare that to temporal ordering of statements; if one module executes 'g(x)' and another executes 'f()', how do we ensure the latter occurs after the former? How could the compiler tell us if they're the wrong way around? Very difficult.

The only situation for this that I can think of is inside a list comprehension / generator expression. You are aware that you can define functions at any scope in python?

  >>> lambda myVar: (def foo(): return myVar + 1, foo)[-1]
    File "<stdin>", line 1
      lambda myVar: (def foo(): return myVar + 1, foo)[-1]
                     ^
  SyntaxError: invalid syntax

  def f(myVar):
      def foo():
         return myVar + 1
      return foo

  pruned = map(
    # Remove all elems whose foo is less than the number of elems
    lambda elems: list(filter(
      lambda elem: elem.foo < len(elems),
      elems
    ))
  )

  total_foos = [0]
  pruned = map(
    # Remove all elems whose foo is less than the number of elems
    lambda elems: list(filter(
      lambda elem: (
        # Add elem.foo to our total_foos accumulator
        total_foos.append(total_foos.pop() + elem.foo),
        elem.foo < len(elems)
      )[-1],
      elems
    ))
  )
  total_foos = total_foos.pop()

  total_foos = 0
  
  # Have to define this outside the map, since it's a statement
  def checkAndAccumulate(elems):
    """This checkAndAccumulate function is just a wrapper, for closing-over
    the elems variable (since it's not in-scope outside the map call).
    Returns the actual checking+accumulating function."""
    def checker(elem):
      """The actual function we want to filter with"""
      total_foos += elem.foo
      return elem.foo < len(elems)
    return checker

  pruned = map(
    # Remove all elems whose foo is less than the number of elems
    lambda elems: list(filter(
      checkAndAccumulate(elems),
      elems
    ))
  )

> But if you feel the need to transform simple linear code into a map of higher order functions because of some abstract benefits you're probably doing stuff that's too easy for you and you should get your mental challenge from solving a more difficult problem instead.

This code is only complicated because you insist on following some abstract ideal. The actual way to solve this in python is:

  total_foos = sum(elem.foo for elem in elems)
  pruned = [e for e in elems if e.foo < len(elems)]

  total_foos = 0
  pruned = []
  for elem in elems:
      total_foos += elem.foo
      if elem.foo < len(elems):
          pruned.append(elem)

Problem is that is not a programming language supported by anybody else than you. It is not part of the standard library. If it was it would probably be of high quality, highly tested-in-practice code.

But if you constructed your pipeline-framework (as in the article) by yourself you now need to understand not only the solution in terms of your created framework, but also how the framework itself exactly works. If this is a one-off problem-solution what looks like simpler code in the end hides its complexity inside its framework-code. And as you keep programming your framework is a moving target. You will improve it from time to time. Understanding it becomes a moving target too. It is a real problem for maintenance for you or anybody else who wants to use and adapt your existing code in the future.

Think about having the problem and a solution and being able to describe both in English. But then you say hey if I invent this new language Klingon and express the problem and solution in Klingon, then both the problem and solution become simpler. Cool. But now you must also program the Klingon interpreter for yourself. And be aware of which version of Klingon your code is assuming is used.

This is the tendency and cost of over-engineering. It is fun and natural to look for the "ideal solution", but it comes with a cost.

The idea to handle validation (we get HTML instead of expected JSON) by passing some Nothing object down the flow is horrible, if we expect JSON and get something unparsable, well, the best strategy is to fail fast and let know client side that we have a wrong data. Instead we show off with some fancy code structure with zero value for the user of the software.

I think where functional programming really shines is in combination with a good type system, that can enforce those restrictions. In languages like js I find it not so useful (even if using map, filter, etc.) because I have no guarantees that there is a hack somewhere in the function that I did not see.

When there are a lot of pure functions the cognitive load is reduced so much I can use the "extra capacity" to focus on the task.

- No side-effects makes reasoning about logic easier, code more deterministic, and tests more reliable. However, certain problems become harder to solve (e.g. simple caching or memoization).

- Async-style interfaces allow for waiting on slow operations in a non-blocking fashion, meaning those don't occupy threads, thus a more economic use of resources. However, async-style code can be harder to read, write, and debug, though this varies heavily between languages and frameworks.

You can still write pure functions and avoid state in imperative code. Use consts, immutable objects, etc. You get some of the benefits of functional programming while still writing readable code.

  let foo = MakeMeAnObject();
  let bar = MakeSomethingElse(foo);
  DoSomethingForSideEffects(foo, JoinThings(bar, baz));
  return foo;

Neither of them can be modified by it in the future - e.g. someone else can't change MakeSomethingElse() to also modify its inputs, thereby accidentally breaking your code that's using this function.

Another way of looking at it: a lot of problems with reasoning about code, or parallelism, can be drastically simplified by assuming the data being passed around is only copied, and not modified in-place. "Immutable objects" as a language feature is just making this assumption the default, and enforcing it at the language/compiler level.

In terms of use, it isn't that much more inconvenient over mutable objects. You can always do something like:

  foo = DoSomeTransformation(foo);

I can't think of anything where I'd want that. Don't you end up needing infinite amounts of memory? Isn't it absolutely slow as balls copying all that stuff around?

Is it as fast mutable everything? No, some copy must happen, but is a mutable-standard languages as fast as raw hand tuned asm? Also (probably) no, but the trade offs are worth it. It likely matters a lot less than you think unless you're writing actually performance critical tight loop code vs just thinking about performance.

This way:

- passing an object around can always be by reference, since no one can change it

- depending on structures used, for changed bits you don't need to copy the entire structure, but simply shift pointers to old data or new data

- garbage collection can become trivial, and granular, since you know exactly what's new and old, and shifting data around becomes just moving pointers around (again, depends on implementation and optimisations)

There are downsides if you are not careful, of course:

- creating a bunch of new data that references old data will run out of memory, but this doesn't happen as often as you would think.

- sending data between processes/threads may result in copying that data (depends on implementation)

However, the upside is quite good: your data never changes under you. That is a call to func(data) doesn't sneakily change data. And all data becomes trivially thread-safe without mutexes or race conditions.

Why would I want to have a thing in memory, copy it to more memory, modify the copy, then free up the original memory every time? That just seems like a waste.

You don't do that, runtime does that for you.

The main benefit is better assumptions about code you write. The prime example is how different languages handle object construction and modification:

   var date = new Date(2022, 11, 21)

   var other = date.addDays(10)

Depending on the language the answer may surprise you. Some languages modify `date`. Others don't. And you never know which of the methods exposed on an object modify it unless you read documentation. Neither the compiler nor the type system can help you.

However, if objects are immutable, you are guaranteed that the original object, `date` is never modified. And if you need to use it again, you know it contains the same data without it suddenly changing.

This gives rise to another important property: you can send this to another thread without mutexes or without creating weird synchronization points like Java's AtomicInteger. Since the object cannot be mutated, threads don't have to fight for exclusive access to read it.

Var object=object() If (isValid(object)) // Do something

In which the isValid function modified the object in unexpected way and caused the issue. With mutability, I loose confidence in the code and literally have to read implementation of everything the object touches to be sure i understand what's going on. Much more relevant in bigger projects.

In theory the functional approach is more stable and predictable. But whether this really causes a lot of bugs in practice is another question.

for example (pseudocode)

  var newUser = Person(name: "some guy", age: 0)

  // newUser is replaced with a new object that is
  // initialized with field.name and previous age (0)
  // the old object is discarded
  newUser.name = field.name

  // object is passed as copy-on-write, assuming a 1 sec delay
  // it will print the objects values at this point in time
  // (age: 0) even if altered later
  async(after:1) { print(newUser.age) } // prints 0

  // age was changed to 32 a nanosecond later,
  // but now a new object again is initialized
  // instead of mutated
  newUser.age = 32 
  print(newUser.age) // prints 32

  ----------
  output:
    32
    0

[1] https://stackoverflow.com/questions/27084007/what-is-value-a...

would appreciate a correction!

I like being able to trust that something is what I think it is because it cannot be something else. Meaning: if I know that something can’t change, I don’t have to check for eventual accidental change.

What's the use case of all this copying and shunting stuff around and consuming massive amounts of memory?

What kind of programs would you write that would benefit from this?

Wrong. For instance, state can be stored in locals. Two threads accessing the same structure, one reading and one writing, the reader loads some state into locals and the writer then invalidates that state in the middle of the reader's computation, and the reader proceeds to computing a result mixing old state and new state thus leading to inconsistency. This ABA problem is well known and it just can't happen if the structure is immutable. And this doesn't even go into cache coherency issues.

I frankly don't think you appreciate the number of hazards just making data structures immutable actually addresses, and given you don't seem aware of the hazards implicit to mutable data structures, I suppose that's not surprising.

> What kind of programs would you write that would benefit from this

Pretty much every single program that accesses a relational database benefits from this. There are a few of those around n in case you didn't know. Perhaps you've heard of multiversion concurrency control?

But a more common case is how I get my records from my db. Only the ORM can create those DB record for me ( because I set it up that way )

When I return a response; I compose another immutable response object.

And only my service layer can don that. ( it won’t compile elsewhere)

Don't you use scope? I don't think I use more than 1 or 2 global variable per system.

This is "safer" for any code still operating on the original object, as it will not be changed unexpectedly.

    extern result fubar(struct foo *);
    extern result snafu(struct foo const *);

The author begins by replacing a language feature, the . operator, with a pipe() function. After that they swap out exceptions for Result, null/undefined for Maybe, Promise with Task, and the final code ends up becoming an obfuscated mess of wrapper functions and custom control flow for what you could write as:

    fetch(urlForData)
      .then(data => data.json())
      .then((notifications) =>
        notifications.map((notification) => ({
          ...notification,
          readableDate: new Date(notification.date * 1000).toGMTString(),
          message: notification.message.replace(/</g, '&lt;'),
          sender: `https://example.com/users/${notification.username}`,
          source: `https://example.com/${notification.sourceType}/${notification.sourceId}`,
          icon: `https://example.com/assets/icons/${notification.sourceType}-small.svg`,
        })
      )
      .catch((err) => { console.log(err); return fallback });

This post has nothing to do with functional programming, this is a poor monad tutorial.

But the seemingly arising "Haskell religion" is at least as mislead as the OOP-religion that held mainstream in stranglehold for a long time.

Haskell's syntax isn't anything to imitate. It's hostile to IDE features, at least. Alone that should make it a no-go.

The next thing is that Haskell's features may make sense in the Haskell context, but they don't make any sense at all in almost any other language.

When you don't have strong types, no lazy evaluation by default, and it's not mandatory to use IO-wrappers, it makes not sense to mimic solutions that arose out necessities that are again results of constrains of Haskell's feature design. You need to do some things in Haskell the Haskell way because Haskell is the way it is. In a different language the chosen solutions are at best bonkers (even they may make sense for Haskell).

As always: It's a terrible idea to start doing something because "it's cool" and the "new hot shit", without actually understanding why exactly things are (or should be) done the way they are. The "Haskell religion" is by now imho already mostly only cargo cult… The more worrisome part is that it seems it attracts more and more acolytes. This will end up badly. It will likely kill the good ideas behind FP and only leave a hull of religious customs that the cult followers will insist on; exactly like it happened to OOP in the past.

That's my personal opinion, speaking as a big FP Scala fan.

I wanted to say the same but you were faster than me. The article reminded me a lot of the design patterns fad in the OOP world: that compulsion to make everything abstract and reusable even if there's no use for it yet. But hey, at some point it might be needed and then it would be great!

Of course there are some cases where you really want to be ahead of what might come , e.g. public library api's, but those are rare.

The overwhelming majority of problems do not fit OO, and using OOP on them makes a mess. Similarly, FP.

Can you elaborate on this? I haven't used Haskell in years but I recall enjoying some of its really cool IDE-friendly features, such as typed holes and the ability to press a key and have whatever is under my editor's cursor show me its type and another key to insert that inferred type into the document.

I have heard that more recent versions support nice record syntax using the '.' operator (but without whitespace, to differentiate it from composition). That's also very IDE friendly since type inference in the editor should be able to resolve the members of a data type that's been defined with record syntax.

When I hold some object I can easily discover the things I can do with that object—just by typing "." after the object reference.

In something like Haskell I need to know upfront what I may do with some "object". The IDE can't help me discover the methods I need. All it can do is to show me all available functions in scope. Most of this functions aren't what I'm looking for. But the IDE can't know that as it's missing the "context" in which I want to call my functions / methods.

And regarding records in Haskell: First of all you will get beaten when you use them (that's part of the religious movement and has nothing to do with comprehensible reasons). The other part is: Records are no substitute for objects. Not even close. Those are just quite primitive structs. (To learn how unpractical is it to try to build objects from structs without proper language support just ask someone who was forced to use C after coming from a more complete OO language).

Sorry, but this just isn't true. Hoogle <https://hoogle.haskell.org/> searches function by type, fuzzily: ask for functions whose first parameter is the type of the object-like thing, and you'll get just what you're looking for. And it's perfectly possible to run hoogle locally and integrate it with your editor.

Now, the tooling for a language like Java have had several centuries more of aggregate development work done on them compared to Haskell's tools, and if that polish is a difference-maker for you, that's fine! But it's not a fundamental limitation, and claiming it is is just fud.

I could imagine an editor having some sort of "holes" capability, where I can hit a key combo to insert a hole where a function should go, provide the function arguments, then double back and fill in the hole with search results from Hoogle. Done right, such a system would be marginally harder to use than Java-style IDE completions, but not enough to be a problem. The main difficulty is that the implementation and UX complexity of such a system is far greater than with a noun-first syntax.

But even aside from that, I don't think verb-first needs to be a showstopper: given that we've got type signatures, there's a lot of local context to work with. You're probably calling a function on one or more of the parameters, or else you're typing the leftmost-piece of a composition chain that gives you your result type. So throw Param1Type -> a, b -> ResultType etc at hoogle and populate a completion list. Completion doesn't have to be perfect to be useful. The hard part would be performance: if completion isn't fast, what's the point?

The point of data-oriented (functional) programming is that we believe it's fundamentally unknowable what sorts of verbs a noun should support, and that it's a mistake to try to enumerate them (OOP).

I don't deny that it's very convenient to type . and get IDE autocomplete. And we should absolutely have better solutions than we do for writing functional code in IDEs. But it's a misunderstanding of your problem domain to suppose that a noun's verbs are inherently enumerable.

This presumes to know what my problem domain is, and for many domains I can think of it's simply not accurate.

If my problem domain is traffic signal control, Signal has exactly one verb: transition.

If my problem domain is calendar appointment scheduling, Appointment has easily enumerable verbs: create, reschedule, delete, move. Maybe you could throw a few more in there, but there certainly aren't infinite things you can do with a calendar appointment.

If my problem domain is running a forum, Post has a few easily enumerable verbs: create, delete, edit, reply-to. As with Appointment, you could conceive of more, but quantifiably so.

I'll grant you that if my domain is something abstract like list processing, quantifying the things someone might want to do with a list becomes very difficult. But in the world of business software, it's really not.

> If my problem domain is traffic signal control, Signal has exactly one verb: transition.

Interesting, so you never define new "compound verbs", such as "transition and then transition again"?

In a C++ / Java / C# like language classes are open by default (even this creates some issues). The reasoning behind that is exactly the one that it's impossible to know all "verbs" upfront.

On the other hand it's a fundamental concept in software engineering to define interfaces. Haskell calls them "type classes". (And Haskell's type-classes are coherent; which by the way creates the mirror problem to open classes).

> I don't deny that it's very convenient to type . and get IDE autocomplete. And we should absolutely have better solutions than we do for writing functional code in IDEs.

I see here the exact same misunderstanding as in the article we're discussing: Whether code is functional or not is not defined by mere syntax. You can use "method syntax" and write perfectly fine functional code.

More modern FP languages even embrace this. The `|>` syntax is quite popular by now. That's a syntax that's actually not so far away from the C++ token `->` for (virtual) method calls.

It's also not only the IDE issue. English, and a lot of western languages at least, use S-P-O as primary word order. Method call syntax mimics that. Whereas P-O sentences actually denote an imperative in English. "Verb noun" syntax is therefore, quite obviously, a tradition form imperative programming: `print("sentence")`, `process(data)`, `do something`… If it were written in declarative form it would look more like `"sentence".printed`, `data.processed`, `something.done()`, I guess.

Anyhow, FP and OOP is on the fundamental level even the exact same thing. ;-)

http://www.javiercasas.com/articles/codata-in-action (You should read the paper, too!)

But there's clearly a difference in practice.

The main point about FP is imho not data as such (and data oriented design is anyway an orthogonal topic) but the primary ideas are immutability of data and, of course, the usage of (mostly) pure functions. This yields the greatest benefits, makes code more robust and simpler to reason about. Syntax isn't relevant to this.

Sort of. But you can just write

    _ x
       ^

    x.
      ^

Interesting.

Could you point to some demo of such IDE integration? Never seen it.

I'm still struggling to imagine how something like "IntelliSense" would look like in such a system. Do you have e.g. any demo video you could point to? Curious to learn more!

(In practice, I'm usually starting from a slightly different place: I know I want a Frob and I've got a This and a That, so I do :hoogle This -> That -> Frob and get some options. The thought-process is working backwards from the goal more than forwards from one key object in focus. A different way of working, but I'm not convinced it's less effective.)

My point though was that it's an engineering issue, not a fundamental language limitation. ie not a reason all future languages should shun haskell features. The building blocks to do better at completion than haskell curently does are there.

>grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug

>big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct

>grug say tool magic pop up of what can do and complete of code major most benefit of type system, correctness also good but not so nearly so much

I wrote up something similar [0] but not quite as creative. Discoverability and Locus of Control are two of the best reasons to use OOP that rarely comes up in the academic discussion of OOP as a practice.

Honestly, OOP is many cases is simply more practical.

Even imperative code has its merits; case in point: it's often much easier to debug.

[0] https://medium.com/@chrlschn/weve-been-teaching-object-orien...

How could I miss that?

Gold! Thanks!

>is ok: how many shiney rock grug really need anyway?

... I actually needed to see this today

Good types do work for you, so that you don't need to write the code to do that work. Correctness is a side effect, because being wrong would take more work.

I agree with you about C and Haskell's records, but I'm curious if you'd say the same about Rust's struct + impl system? Are there problems that can only be solved with real, Smalltalk-inspired objects, or can lightweight structs do the job if supported by enough syntactic sugar?

Indeed Rust striked some kind of sweet spot because it got the defaults right.

Syntactic it mimics mostly the OOP approach, but without the conceptional burdens behind it.

Still Rust could not do without dynamic dispatch (which is the—wrong—default in OOP).

In the (admittedly) seldom cases where you need dynamic dispatch & runtime polymorphism you just need them.

You could build this stuff by hand (and people did in the past in languages without this features built-in) but having dedicated language level support for that makes it much more bearable.

Structs + the impl system is static dispatch. This just can't replace dynamic dispatch. If it could nobody would have ever invented v-tables…

  [1, 2, 3] & 
              ^-- suggestion here

Sure. Because you memorized all the functor methods and remembered that there is a functor instance defined for the data type at hand… ;-)

> Unfortunately this wouldn't be very idiomatic in Haskell, maybe in Idris with |> this would make more sense?

Or you could just admit that the "OOP style syntax" is superior. (I'm not saying that OOP is superior, though)

Do you really think this is a adequate replacement for proper IDE support?

I perform operations on stuff, if I don't know the name of the operation I intend to perform I clearly have some reading to do. Integrated look up for one specific class of operation which isn't even omnipresent in Class-oriented languages isn't a killer feature for me. Nor is structuring every module even if it's completely stateless as a class, just to benefit from IDE driven development a reasonable price to pay.

That's a question of language.

  object SomeModule:
     def someMethod(someRandomNumber: 42) =
        s"The answer is: $someRandomNumber."
     
     def someOtherMethod = someMethod(42)


  @main def entryPoint =
     
     val someTheory = SomeModule.someMethod(23)
     
     import SomeModule.someOtherMethod
     import StringExtension.*
     
     (someOtherMethod :: "No!" :: someTheory :: Nil)
        .fold("")(_ + _ + "\n")
        .printLine()


  object StringExtension:
     extension (s: String) def printLine() = println(s)
     // Because methods compose better in a fluent style…
     // You don't need to read your code backwards!

That's Scala.

Two cute stateless modules. Nicely wrapped in singletons.

Not quite sure why I had to add the handy `printLine()` method to the String class myself, after the fact…

But as extending arbitrary classes with new methods without touching them is trivial, who cares.

(Frankly it does not compile. It says something like `Found: (23 : Int); Required: (42 : Int)`. No clue)

Haskell is great but it’s not for everybody. It really gets you thinking about software engineering in a different way.

I wrote Haskell full time for five years, with some of the best in the industry and I can tell you that there is no real religion. I will admit the language attracts ideologists, theorists and folks who like to pioneer (which I like), but everybody is just trying to make things work - these are patterns that solve problems and guidelines that avoid problems.

Now, it’s really hard to take the good parts of Haskell and bring them to a language like JavaScript and have it feel “natural” - especially to someone who isn’t a native Haskell writer! And especially a concept as reliant on higher kinded types as effects!

BTW: Haskell uses its IO wrapper also only for a very narrow set of effects.

One of my favorite examples: `head []` will result in a crash at runtime. IO won't safe you. (Besides that the whole "effect wrapping" story in Haskell is anyway shallow at best. There is nothing like "none observable effects" at all as every computation needs to happen in space-time, leaving observable traces therein; you can't define away "side channels" and call the result "pure"; that's mocking reality).

This is realllly unidiomatic in real world Haskell. Even removed from Elm and PureScript.

Idris maybe has better effect handling for your taste. Also see: Koka, Frank (mainly a paper)

Whether idiomatic or not does not matter. It proves my point:

IO won't save you, and even very mundane effects are not part of the game…

Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).

Koka is a toy, and Frank mostly "only a paper" (even there is some code out there).

The "Frank concept" is to some degree implemented in the Unison language, though:

https://www.unison-lang.org/learn/fundamentals/abilities/

Having a notion of co-effects (or however you please to call them) is imho actually much more important than talking about effects (as effects are in fact neither values nor types—something that all the IO kludges get wrong).

I think the first practicable approach in the mainstream about this topic will be what gets researched and developed for Scala. The main take away is that you need to look at things form the co-effects side first and foremost!

In case anybody is interested in what happens in Scala land in this regard:

https://www.slideshare.net/slideshow/embed_code/key/aLE9M37d...

https://docs.scala-lang.org/scala3/reference/experimental/cc...

But also the development in OCaml seems interesting:

https://github.com/ocaml-multicore/eio#design-note-capabilit...

Look mom, "effects", but without the monad headache!

Issit? I thought they track effects in a special part of the type system as to not do it monadically. Possibly both are possible.

Yet it is the actual behaviour in the stdlib Prelude.