[kalekold]

I've just left a startup company who's entire backend was written in a functional style using Typescript by an agency. The only reason I can fathom why is 'why not, functional programming is cool right!'. A new dev team was created to take over and it was a disaster. It was an absolute mess of piped, mapped, reduced functions everywhere and completely unreadable and unmaintainable. I remember getting lost in a hierarchy of about 30+ piped (non db framework) functions to write a JS object to a database. I didn't stay long.

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.

[atraac]

> 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'.

[lolinder]

> I've just left a startup company who's entire backend was written ... by an agency. ... A new dev team was created to take over and it was a disaster.

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...

[bigDinosaur]

You can make code in any paradigm suck. You can do horrible unmaintainable things in any language in any paradigm: Java with twenty layers of abstractions, Python with immense amounts of spaghetti, C with its hard to control safety. You can also do awful, abysmal imperative or OOP code in Typescript. So I just don't really see how you can single out FP here at all. Your codebase sucked, and whoever was hired to write it in a FP style just sucked at doing so. Sorry.

[WA]

> So I just don't really see how you can single out FP here at all.

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.

[biorach]

> Just use FP and nothing can go wrong. That’s at least the impression I get when I read about FP.

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.

[hnfong]

I generally agree with you. That said I do think the GP has a point w.r.t. Java and OOP. It's somewhat analogous in the sense that Java's main selling point was its ability to overdo OO abstractions.

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)

[wiseowise]

> 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.

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

[Sohcahtoa82]

> Java with twenty layers of abstractions

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.

[mhitza]

> Functional programming is a big mistake for some real-world code.

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.

[eckza]

Inexperienced developers that don't understand what they're doing, armed with a language known best for being worst-in-class at everything except for "running everywhere", is a recipe for disaster, no matter how you spin it.

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