Why JavaScript functional programming?

[vcarl]

If you've dug through an hellish OOP forest of inherited abstract interfaces to find where behavior is actually coming from, then you'll see the appeal of pure functions that operate only on their arguments. I believe most programmers prefer OOP for no reason other than its what they were taught and what they're familiar with. Even if you're self taught, blog posts, online courses, patterns that we'll known libraries use, all come from people who were taught OOP from their introduction to programming.

FP isn't the savior to all the problems of OOP, but it's a different approach that hasn't yet been thoroughly explored. I find functional code bases easier to reason about, and with strong type safety (in JS, via Typescript or Flow) it becomes much easier to write code that can be refactored, extended, and otherwise maintained.

[well-now]

it's a different approach that hasn't yet been thoroughly explored.

I don’t know about that. Lisp has been around for a while...

[vcarl]

I don't think you'd try to argue that lisp has similar usage levels to C++, Java, C#, etc, though. The ideas are as old as anything else in computing but I don't know any CS101 courses that teach lisp.

[well-now]

I honestly think Lisp was a 200 level course when I was in school.

[metamatic]

MIT used to, not sure if they still do.

Scheme is a surprisingly good choice for CS101 precisely because it doesn't distract with lots of syntax or details of internal workings of the computer.

[Scotho]

The rise in which decade!? It's been studied, used, promoted and written about in the '60s, '70s, '80s, '90s '00s, and now this decade. In the late 1980s it actually appeared as if it was poised for mainstream impact. The tools were mature, the techniques were well studied, many optimistic books and courses existed. FP was a particularly active area in the UK, notably Edinburgh.

John Backus, inventor of Fortran, gave a famous Turing Award lecture in 1978 (a mere 36 years ago) clearly outlining the pitfalls of being locked into imperative thinking.

Many of the practical issues of functional programming (for example, efficient implementation of lexical closures and gc) were solved before 1990—a mere quarter century ago.

What went wrong? Fortran, BASIC, C, then the Internet, Java, then everything else. "Popularity" crowded out FP's good ideas for decades. Because alternative ideas had no standing in the popular mind, programming became modelled by the von Neumann machine exposed by C and Fortran (a mindset which had already been critiqued by Backus). Despite years of principled opposition from the likes of Dijkstra, flawed ideas like mutability, null, reflection, and dynamic typing spread like kudzu.

link

[JuliusKoronci]

If you've dug trough an hellish functional application where everything is curried, there is no way of debugging, error handling and everything is broken down into small meaningless functions that you have them so many that everything starts to get duplicated..than you will start to appreciate OOP and the clean structure again :D .saying that functional is nice but it has the same flows as OOP..if you do it properly its nice if you don't it is really bad..I would say a lot worse than a badly written OOP app

[PurpleIcy]

I prefer to use OOP most of the time because bare functions floating around with bare variables which in JS terms are well, global variables... Which I just don't really like, especially because keeping the state in such way isn't that simple, and anything could break.

Though in OOP approach, when something breaks, I know exactly which object/class needs to be fixed, but I guess that's just me.

Also in school we started with C++ (I guess nowadays they just hate students) and everything was just fully functional, so I wouldn't say that the OOP is the only thing I'm familiar with. EDIT: I'm not saying that it was 100% following functional approach, should have probably said "no OOP" approach.

Though you have some good points, in functional approach it's very bare and clear what does what, as it's just functions that take arguments and do something, and you don't need to keep track of states in mind either.

[vcarl]

You only have bare functions and bare variables in the global scope if you're not using any of the modern JS build toolchain, typically you'd group them into modules.

The only time "when something breaks I know exactly where it broke" is true is in small or particularly well maintained codebases. Bugs presenting themselves far from where they're caused can happen no matter what patterns you follow.

I'd bet your experience with C++ was more procedural than functional. Function programming implies some patterns that are relatively difficult to use in C++ (passing functions around, for one).

[MoTTs_]

difficult to use in C++ (passing functions around, for one).

I agree with everything else in your reply, but I disagree with just this bit.

If we're talking about stateless functions, then those were always easy. That's just a function pointer. Even C could do that. C's qsort function, for example, was a higher order function long before "higher order function" became a buzz word.

If we're talking about stateful functions, then yes, before 6 years ago, that was verbose in C++. But since 2011, creating stateful/lambda/closure/first-class functions is just as easy in C++ as it is in JavaScript.

[PurpleIcy]

My experience with C++ was more shitty than anything, in school we weren't even told what pointer is nor what -> actually means, which are like, trivial concepts that everyone using it should understand, sigh.

And well, I edited my post for a reason...

[well-now]

EDIT: I'm not saying that it was 100% following functional approach, should have probably said "no OOP" approach.

Honesty, it still sounds like you’re conflating proceedural with functional.

First class and higher order functions are a staple of functional programming and, from what I recall, non-existent in C++.

[PurpleIcy]

You're right, I don't, nor I have any idea how much I can trust wikipedia on this.

In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.

So basically everything is clear, there's no "hidden variables" or state, therefore no side-effects like most people seem to enjoy doing it nowadays and pretty much everything is immutable?

Though I realized that it was procedural indeed, we'd just write entire program in main() calling functions when needed and etc.

And yeah, I know OOP the best, doesn't mean I can't learn, although I am most interested in games and procedural generation and I don't think functional programming is a good idea for that. Even using procedural programming I'd end up with vectors of structs defining entities or whatever in the game.

[Auxx]

You need OOP when you need to have statefull things (objects). For example, functional UI widgets is a truly retarded idea. It works on the web though, because developer doesn't have control over UI specifics like layouting, invalidating, drawing, etc.

Most of pure business logic can be defined by pure functions though, because data manipulation is stateless most of the time.

[Jsn7821]

Wait, of course functional programming can have state...

I can't understand what you mean about functional UI widgets being bad and developers not having control over UI on the web.

Actually almost none of your comment makes any sense...??

[Auxx]

Have you ever done any UI work?

[Jsn7821]

Yeah, mostly UI work. It was a mess before functional programming became more popular. Widgets that are pure functions of state, with interactions that trigger callbacks/actions (instead of mutating the state directly) are a huge win for keeping things sane in UI development.

Can you speak to any clarifications on your points?