Is Functional Programming DEAD Already?

[@ContinuousDelivery]

Are YOU a Great Programmer? or a Regular Programmer with GREAT Habits. Download my FREE guide on how to adopt 30 of my favourite Programming Habits. Get yours HERE ➡ www.subscribepage.com/great-programmer

[@robertlenders8755]

Automatic parallelization and performance really isn't the main reason to choose a functional programming language. Algebraic data types for domain driven design, immutability by default and concepts like referential transparency produce code that is much easier to reason about the program state by merely reading the code rather than assessing all mutable fields and properties across multiple objects that talk to each other, usually by having to step through the operations in a debugger.

[@Nellak2011]

@@robertlenders8755 DDD mentioned

[@piotrc966]

Not always. A gazillion function calls are often difficult to read and debug.

[@J-Kimble]

@@piotrc966 A gazillion of everything is hard to read. Think of the 234 layers of interfaces in any oop lang.

[@piotrc966]

@@J-Kimble But no one argues that an oversized objectivity is good. And many argue that a purely functional approach is better. No, it isn't. The code is often bloated and hard to debug. Much more readable is imperative with funcitonal elements. Not pure fuctional.

[@robertlenders8755]

@@piotrc966 A gazillion function calls is just a straw man. You should be doing function composition at progressively increasing levels of semantic meaning, so the higher or lower levels can be disregarded depending on the problem to be fixed. The same principle applies to imperative code, it would be a poor design for the same imperative function to be applying business rules and be doing bit twiddling.

[@sjzara]

FP has had huge influence on other languages, with features like lambdas and immutability and declarative coding.

[@InconspicuousChap]

Not just has had. There are two ways of language development: towards Lambda Calculus, Category Theory and other math, or towards ad hoc stillborn internally controversial ideas (COBOL, OOP, etc). And this concerns not just languages, but the application architecture as well.

[@lkyuvsad]

Yeah. I learned functional through Java libraries, not a functional language. Did a bit more in .Net. I’ve got 1 year in production Clojure but that’s it for me. I still think in functional terms daily in Java, Kotlin, Typescript. In Clojure we still used protocols quite a bit and the impure bits of the codebase looked fairly OO.

[@Carl-md8pc]

Perhaps thinking in something closer to a natural language (conditionals, repetition and commands) is more accessible to most than mathematical thinking...and not many people have been exposed to algebraic structures, functors and monads. @@InconspicuousChap

[@krumbergify]

Functional programming doesn’t just potentially make your code run faster, it also forces you to structure your code in terms of inputs and outputs, making it easier to test and reuse. This can of course be done in OOP languages as well, but then it’s much easier to make a mess out of globals and side effects.

[@aabhishek4911]

How exactly does functional programming make your code faster ?

[@InconspicuousChap]

Functional programming is math. OOP is anti-math, promoting poor code structure and awful data models.

[@krumbergify]

@ If you write pure functions it is much easier and safer to run those over a data collection using many threads or even using different machines. Think “map-reduce” where each worker gets a small piece of the total work where those results are later collected in a reduce step. This CAN of course be done in any language, but then you have to worry about thread safety in a way that you don’t need to to if all your data is immutable.

[@aabhishek4911]

@@krumbergify So the main benefit of functional programming is immutability which can really be achived in any language, it is just the pure functional languages that enforce it at the compiler level.

[@krumbergify]

@ Yes. Guarantees matter. You can certainly write thread safe code in C++, but Rust makes it much easier since the compiler enforces that there are no data races in your Rust code (as long as you don’t write unsafe blocks).

[@Laggie74]

It's like Cartesian vs Polar coordinates. Some problems are better solved or expressed in one vs the other. Religious fanaticism is baked into some people's DNA.

[@AxiomaticAssumptions]

@@Laggie74 I don't like what you're saying! I'm gonna go become a mips programmer!!!

[@adambickford8720]

*Way* too much emphasis on parallelization. It's like dunking on the OO 'reuse' argument that just doesn't work beyond the most basic stuff. That doesn't mean OO is useless, just that aspect as oversold.

[@oliverglier8605]

Hi Dave, thank you for the interesting video. It is difficult to come up with hard data on performance, but maybe my experience is still worth mentioning: In 2012, we one wrote a data processing program in Java, using self-implemented purely functional streams (not the java stream lib!) and data structures. There were only two single-threaded streams, one in the middle for sorting and then the final stream for collecting the data. All other stream transformations inbetween could be parallelized horizontally and vertically. While our program run 3x faster on a quadcore compared to a single core, I agree that if tight loops were written in a heavily tuned imperative/destructive style, the program might have been about 20x faster, only limited by I/O. The funtional style allowed us, however, to be lazy with optimization and focus more on testability and expressivness. So my other observations might be of interest: 1. Conversions from iterators to immutable, lazy streams and vice versa enabled us to travel between both worlds, with the former being a bit tricky to implement. 2. Immutability made it easy to transparently compress the data outside the working window, which actually increased(!) the overall speed. 3. Writing tests worked like a charm and even a small testing dsl could be written in only 2 days. 4. Lazy streams and structural sharing lead to memory leaks at tail calls that were difficult to track due to the fact that eclipse and the jdk produced different bytecode. 5. In an imperative language you can implement purely functional data structures which are impossible to write in most (all?) purely functional language, namely those involving identity checking via deduplication for fast diffing. 6. One must be very careful that non-funtional side effects don't leak, for instance, identity hashs destroy referential transparency and therefore repeatability of tests. In the end, it was a fun experience, and the new program was still 20x faster than the old, db-centric C++ solution. LOC was reduced from approx. 300.000 to 25.000. The old program did not have any tests while the 25.000 for the new program even included ca. 8000 lines for the new data structures and 10.000 lines for tests. As far as I know, the program still runs flawlessly, processsing several 100.000 fairly complex data records per day within a few minutes. Of course, the numbers are from memory and not exact, but I'm pretty sure that they faitfully describe the overall picture.

[@rranft]

Keep a large and varied toolbox. "Functional programming is the ultimate tool" is dumb. "OOP is the ultimate tool" is dumb. Etc. Learn everything, use the tool that best solves the problem.

[@samuelkacer4997]

FP is not a class of programming languages. As it suggests, it is a programming paradigm. So, your analysis of FP's popularity based on the popularity of individual languages is fundamentally flawed. Yes, purely FP languages like haskell and erllang are not much higher on the list than before, however almost all the major languages on that list have moved towards FP. Since, Java8 onwards, the vast majority of new Java language features were adding support for FP. Also Javascript has completely been moving towardsFP. Especially in its libraries. Ever heard of a little library called React? The reactive design at its core comes completely from FP. FP is indeed eating the world, but it is mostly doing so by changing the existing programming language giants, not by breaking through with soleley FP based languages.

[@ContinuousDelivery]

I guess you didn't watch to the end 😉

[@jackgenewtf]

I hope watching too the end will discourage me from hitting that "Don't recommend channel" button.

[@jackgenewtf]

I'll be hitting that button. You'll not get continuous feedback from me, I'll just let you know that it's not necessarily because I disagree with you. Just that this hasn't been worth my 20 minutes, and I'm not a fan of clickbait titles in general.

[@captainawesome2226]

Well said. I was confused by the first three-quarters of the video where it addressed FP as a language rather than the paradigm. It's kind of a metaphor for what's happening at the implementation level a lot of time, so the irony gave me a chuckle :D

[@georgehelyar]

Modern languages have just taken the best parts of several paradigms, including FP. When every class with behaviour is really a singleton that's just a module, and when every method is pure then that's really a function, the syntax is just closer to natural language so it's easier for most people to read, and less strict about mutable state in local variables, as long as that mutable state is confined to the function.

[@AlexandreJasmin]

Smalltalk is really fun to use. It's a living system full of objects that you can modify (mutate) and play with and see what breaks. Educational systems, such as Etoys and Scratch, were built on top of it. If you're daring enough, you can even modify its compiler while using it. And if you make a mistake, you have save points (images) to save the day. Functional languages, on the other hand, aim at writing repeatable and testable algorithms by limiting side effects. Their focus on immutable data help avoid mistakes that stem from complex graphs of mutable objects and unconstrained concurrency. They both have their uses. One is explorative and playful the other is rigorous and predictable.

[@benfowler1134]

Type-level wankery is all well and good when you’re in your 20s and have time and money on your hands, but the cost-benefit tradeoff of using complex languages for real world systems, where every different developer and team uses a different subset of the language, doesn’t work. Happy to be convinced otherwise if “lean Scala” ever takes off.

[@bobbycrosby9765]

By my measure, functional programming had a resurgence about a decade ago. Mainstream languages subsumed some of those features, and static typing took charge then with things like Typescript, Rust, and typing for Python. I think automatic parallelization isn't a big deal in major programs. But one place I really like it is with scripting. I experimented with writing my utility scripts in a variety of languages, and one thing I really liked about Elixir was how trivial it was to turn most of my serial scripts into parallel ones. All it usually involved was changing a couple lines of code. Experimentation and measuring was trivial. Lots of functional languages can also do OOP. Like Clojure with their multimethods, which mimics a less powerful version of Common Lisp's OOP. If you've never tried out OOP in Common Lisp, I recommend it. It made it a real joy for me.

[@PassifloraCerulea]

In my (admittedly not very wide) experience, the only place I saw anything like "automatic parallelization" actually work is with OpenMP in Fortran-based weather models, i.e. feeding the outermost loop in deeply nested do-loops to different threads with a compiler directive. I still have yet to see major software get (re)written in the pure functional languages that were supposed to make this Just Work™ (and without annotations, mind!) like they were telling us in college a quarter century ago. It's still too weird/hard/whatever a way to program most of the time it seems. I always did like the design philosophy of Erlang and OTP though, and it's a shame I never spent much time with them or Elixir.

[@bbravoo]

Kotlin made much easier to mix functional and OO programming into the Java virtual machine

[@pompiuses]

Compared to modern Java I find the differences to be small.

[@gronki1]

2:47 Fortran is a modern programming language that now sees its renessaince with an active community and new set of tools developed. :) It actually was in the top 10 TIOBE index for the past couple months!

[@TheBackyardChemist]

I feel the need to nitpick about the clockspeed claim of 3 GHz, true enough that the previous trend has broken, but a lot of CPUs these days are capable of ~5 GHz sustained if adequately cooled. Even if we ignore "gaming PCs" and look at the pinnacle of reliability, IBM mainframes, their newest CPU is the Telum II which runs at a fixed 5.5 GHz. So I think 5 GHz would be a better choice as the current practical limit of clock speed.

[@PierreThierryKPH]

I don't think performance is the main advantage, but correctness. Performance comes as a side-effect, when you are free to write highly concurrent code that doesn't trip itself.

[@JonRonnenberg]

In my limited experience, writing parallel programs, off the main thread, meant that I could write really unoptimised code in the parallel processes and it didn't have any impact on the program as a whole. I'm sure you wouldn't be able to measure any performance boost on a benchmark but the perceived performance was great. And writing unoptimised code takes a lot less time to write. I want to make clear that agree with everything you said in the video. Your millage may vary.

[@pixtweaks393]

I've abandoned the idea of FP after I benchmarked it years go. Having said that, OOP has its overheads so I use it only when it makes sense.

[@JunYamog]

I have used Scala a about a decade ago and got it in production systems. Not pure FP however it does nudge you to think about state, idempotency, etc. Now even if I code in Python and JavaScript I definitely like there are FP influenced constructs and think about the lessons I learned back then.

[@johntrevithick5900]

Horses for courses is right. Or perhaps horses for environments? I once worked on Java applets in the browser, and I can say that OOP is not a good fit for that environment. It cured me of my Java snobbery when I saw how easy it was to handle events and async code using first-class functions that even early Javascript supported, compared to the laborious boilerplate that Java 5/6 required.* I recall an earlier video on this channel about event-driven programming, and my feeling is that this is a paradigm that may well suit FP more. At least, if GUI coding is any indication. I have no data to support that claim, though. :( * It has been a while since I have worked in the Java space. I would expect that the lambdas have improved things now.

[@fabricehategekimana5350]

I also think presenting FP as a huge performance boost is wrong. Fp can only outshine OO performance wise in machine learning which rely heavely on paralellism. It's also impossible to build everything with a purely FP style At the beginning I thought I hated OO but I just had a problem with inheritance and classes. When I get rid of those and use OO ideology designed by Allan Key, everything become great So I prioritize a FP first then procedural and OO when needed

[@jamoncitovideos]

Saying scala is simply OO with functional capabilities it a bit off. I'd rather say the opposite

[@СергейМакеев-ж2н]

Same with F#. It's more like almost-completely-FP, but with some backwards compatibility with the underlying platform (Java and C# respectively).

[@a_rugau]

Great content sir! Thank you. May I ask, would Rust be considered functional? I've dip the toe in it, and seems like it wants to be seen that way.

[@Nellak2011]

@@a_rugau From what I have seen Rust is Functional inspired but isn't functional in the traditional sense. Due to its borrow checker you can write low level code and know it will work with certain guarantees, like functional, however, the mechanism it does it to give these safety guarantees don't use immutability but the borrow checker. Its syntax is inspired from the ML functional family, esp. OCAML

[@ContinuousDelivery]

Well, certainly the default stance of variables to being immutable goes some way to justifying that claim, but I think I'd think of it as a hybrid, rather than a pure functional language, like most modern languages.

[@C4CH3S]

As long as the BEAM is still used, functional will never die. The people who actually write code that needs to scale (and vercel doesn't count, sorry) use it for a reason.

[@Nellak2011]

@@C4CH3S I guess I am a Next.js soy dev then 🤣 I can't wait to test out Gleam on the BEAM I hear it is OP.

[@sphengosine]

Vercel typescript soydev andys would never understand being an elixir gigachad

[@krumbergify]

Let it crash!

[@andrewwrench1959]

Always a thumbs up for any emphasis on Amdahls law, the most important in high performance compute. Most often for large problems that require massive parallelism one is more concerned about memory cache, memory paging and data distribution. Some problems it is cheaper to repeat calculations than to distribute those calculations, in others the very largest memory space possible is the way to go for the exact opposite reason. OO or functional is pretty far down the list, and likely immaterial, especially once the compiler has done its thing. If the kernel matters that much then assembly may be required, but that still has to do better than the compiler on its own.

[@WileeRunner42]

FP has a hard time catching on because it is a major paradigm shift that can be difficult for some programmers to understand. With FP, it is easier to write async code and to automatically parallelize in terms of concurrent scalability. Some code I've written in imperative/FP is fully thread-safe without the use of locks so team members don't realize all the async and tasks going on with the support for an unknown number of network connections. That non-understanding does have some drawbacks. The advantage is that I don't have to consider its thread-safety later on. I haven't done performance benchmarks though nobody has found any performance issues. The concept of a microservice is that it is a large external function in FP. I'm not a paradigm purist and will reach for the tool that I think would work the best.

[@pedrovasconcelos8260]

I've been doing FP for over 25 years and was always very skeptical of the possibly for automatic parallelization because, as you pointed out, you may end up with a parallel but slower program. However, there are much easier benefit for concurrency: immutable data structures allow safe unrolling the effects of concurrent threads. Together with explict side-effects is why you can have easy and efficient Software Transactional Memory in Haskell but not in mainstream languages.

[@ApprendreSansNecessite]

There is a nice conference by Richard Feldman about why FP has not become the norm.

[@guotesuoze]

There's something fascinating about how we fail grasping formal languages, even if we created them, like PLs. I think it has to do with fundamental problems in formal reasoning, that the sciences can't recognize or are shoving aside as something that's not worth thinking about,

[@logiciananimal]

I wouldn't go that far, but I do think it that it is fascinating that we serialize by speaking then try to develop artificial "speech like" systems (written language) that we have trouble reparalleizing.

[@logiciananimal]

I've thought for a while that the good way to have data science sorts do stuff with traditional software devs is to have the former work in a purely functional way (or almost so). That allows (for example) the latter to do much of the application security (e.g., related to file and network I/O). I have yet to succeed in using this division of labour, however. A sticky point was that DS wants to do "visualizations" and that often entails web stuff (e.g., ShinyApp) hence a security boundary, etc.

[@alanmacmillan6957]

we're doing both OO and functional style programming in python. In the case of needing to model objects that provide functionality to other users in modules - we use the OO features where those fit best with tackling that problem. In other pieces of code we are manipulating lists and collections of data that lend themselves really well to set theory and functional programming to solve the problem in an elegant way. it's horses for courses. you tighten a nut with a spanner. you put in a nail with a hammer.

[@somcho]

the lean4 community is alive and well my friends

[@feralaca123]

I worked for a company that used ruby and elixir, and spend some time learning both (previously I used JS and Java). I loved both languages (oop and fp respectively), but could not find another elixir job after that contract ended. I stick with ruby for personal projects. IMHO, I think the culprit is the dynamic of the job market. A competent java programmer can learn elixir in a reasonable amount of time, but the recruiters will pass on those candidates, then complain that it is impossible to staff, and suggest moving to another technology. Is a vicious circle.

[@efilson7581]

I see a lot of FP videos, but every time I've encountered it in the wild, there's a dearth of unit tests (or any tests at all) and no one wants to touch it for fear of breaking it because somehow inevitably the person who wrote it no longer works at the client. The assumption seems to be that it runs in a magical black box (though I myself have a very mixed style in Python).

[@paulsmith8289]

The readability, understand-ability, and maintainability by developers has to trump functional (or functional style) code most of the time, for businesses at least. I've been a dev for 34 years and hate picking up someone else's code that is unfathomable, taking far too long to figure out what it is doing.

[@domenichelfenstein6584]

Every paradigm has its place. I use OO where encapsulated state is of importance (in-memory caching comes to mind for example) and FF for modeling my data types and implementing something with inputs and outputs (often algorithms). Interesting for me was my realisation that, in the end, web requests and their responses are nothing else than input->output functions. So, for me, the functional approach fits extremely well for that kind of application.

[@MikeCorvin-x4p]

Thanks, good commentary! Absolutely agree: apply the approaches and paradigms that best express the problem and the solution in the most understandable, readable - and, yes, elegant! - way. Then think about performance & optimize, including parallelization. Weaned on structured programming, thence to OO and finally FP, I've found they all bring concepts that can help enable beautiful code that solves the problems. I do find myself using FP more and more for more concise code, but wherever there is persistence and mutable state, those are objects. (These days the team I'm on slings Python, but I have a crush on Julia...)

[@Pretagonist]

I like the functional idea and I always rejoice when I can make methods static and when I can remove loops by using things like LINQ. That said, purely functional styles tend to end up clunky and have difficulties interacting with the rest of the world. For me I strive to make my code more functional wherever possible but it isn't an end goal in itself. I like representing my systems with objects and I try to make all my transformations of data between objects as functional as possible.

[@mehandsomething]

The main Haskell compiler has some very subtle performance-gotchas that trip up even experts, one being related to how it does beta-reductions of let-bindings IIRC, and the side effect of heat is not captured in the I/O monad. Probably Rust is a better fit in most cases where performance is equally important to correctness. But sometimes OCaml or Lua is best, and why not keep an eye on Inko and Zig. Having a large toolbox with not just hammers is a win.

[@capability-snob]

Nailed it. True, there's a lot more to be said both for and against, but I'm glad we're actually talking about this. FP is great, but it's not a silver bullet and there are valuable things you give up when you use it.

[@isodoublet]

Guy Steele (of Scheme and Common Lisp fame) tried (and he tried _really hard)_ to make a language that would actually live up to the promise of effortless parallelism. It was called "Fortress", and in many ways it was heavily influenced by functional ideas, but built from the ground up with this vision of "abstracting away" the computational substrate as a core design idea. Long story short, it didn't work. They came across some very difficult problems along the way and the project, while promising, was abandoned. This idea that FP will just automatically and effortlessly let you threadpool everything is a pipe dream.

[@sfermigier]

Very hard to agree with you, except on the historical facts. A programming language is "functional" as soon as it has first-class and higher-order functions, so most mainstream programming languages are now functional in that sense. The "functional core, imperative shell" mantra is now widely considered a foundational design pattern in modern software development, especially within the context of multi-paradigm programming languages. This approach is widely adopted in production systems, as it promotes code modularity and enables the use of functional principles where they are most effective, while accommodating imperative styles for managing side effects, such as I/O operations. A friend of mine, who was trying to "sell" me OCaml (a language which was mostly created by two other friends, BTW) a few years ago argued that the main differentiating feature was pattern-matching. Following his advice, a few years later, I tend to use pattern-matching a lot in my Python code. (In other words, Python has gained a few years ago a feature that was considered a differentiating feature of FP languages).

[@gudrungunzelmann]

Functional programming, like OOP, became a commodity in nearly all modern languages. I often apply FP and functional concepts in C++ or Go, especially in multi-threaded applications. If it cannot be done purely functional, I step back to single threaded solutions, because it's often an indicator that the algorithm is not suitable for parallel processing (think twice before using mutexes or semaphores). But the most simple solution is usually just an imperative procedure. OOP shines when used like Alan Kay suggested - by radical decoupling and only using messages for communication. Use the paradigms where you gain the biggest benefit from them, always take the middle path and never trust in silver bullets!

[@angeloceccato]

The value of FP is not only the pararel of performance compared to the single core. But how to compose the software and the cognitive impact of it. In my opinion, oop shines in dependency management and encapsulation, but it failed to sell inheritance as a core feature when it isn't. FP basics help maintain explicit state, avoid globals, and decouple software from time. I like both styles.

[@gardnerjens]

I think one argument for FP style, if we talk a language like Rust, is that it gives you a way to make higher level abstraction, and also we can get rid of the null by using the option Monad. And if the compiler can manage to make the code into a imperative style, one compilation then it should be with out cost.

[@sarabwt]

Null safety has nothing to do with FP. Kotlin had null safety way before rust was even a thing.

[@gardnerjens]

@@sarabwt i was more thinking about using an optional monad to force you to handle "null" checks at compile time

[@janlanik2660]

@@sarabwt The way Koitlin handles null is a functional programming element. All major languages have integrated elements from functional languages, that is the real success of functional programming.

[@sarabwt]

@@janlanik2660 No it isn't. Again, null safety has nothing to do with FP.

[@janlanik2660]

@ The way how you call a function on a type that may be null and it returns null in case the underlying object was null instead of raising an exception, that’s a functional programming pattern.

[@KostasOreopoulos]

The main advantage of using "purely" functional, or OO programming languages or a language that enforces paradigm X, is that you are "forced" to develop an new type of thinking. This is purely impossible in an environment that allows multiple paradigms. This is why C++ programmers back in the day, used C++ as C, with a sprinkle of OO ideas or we use functional ideas here and there. I think the great value of strictly X-type languages is that they force you to think that way and develop some skills that you will or will not use, depending on your problem. You do not learn Haskell to make your next big project in Haskell, but to train your brain to think AND in that way

[@dawnrazor]

I went through a phase of loving fp and in the process took it too far. I lot of code was satisfying to write but sometimes difficult to read after written. I also began to fear the runtime overhead that it creates. Nowadays I’m much more pragmatic I still fp but not exclusively, rather, I like the declarative approach when it can improve maintainability. For example, I discovered that reduce can be used in more situations than at first may seem to be the case. When I see a reduce in code I know exactly what it’s trying to achieve. However solving the same problem without a reduce often means it can be harder to deduce the intentions of the code because of the lack of an instantly recognisable pattern and thus increased cognitive load. But to me practically is king, so use fp when appropriate not because you want to go all in on an ideology

[@fantasypvp]

As someone who mainly uses rust fot projects, i heavily utilise functional programming patterns for my code but the object-like data types that rust provides with methods and traits would be hard to live without in a purely functional language

[@d3stinYwOw]

1. Rust also would help with adoption of FP principles :) 2. Ada is NOT dying! New versions are still pushed forward, modern tooling like alire and ada-language-server as built.

[@mattevans3511]

I use both OOP (Python) and FP (Elixir) in real life. I personally find FP easier to work with, although it could be argued that Elixir isn’t a pure FP language. That said the main reason for the dominance of OOP in my opinion is that it was the new hotness in the late 80’s / early 90’s, when most of today’s SE managers were in college.

[@SimGunther]

Given the 250 pages before an assignment statement was used in the SICP book, it's not really as "dead" as you claim it is LOL

[@ContinuousDelivery]

Look again, at the title, I didn't claim it was dead, I posed the question. Betteridge’s Law of Headlines. It states: “Any headline that ends in a question mark can be answered by the word ‘no.’” 😉

[@jfftck]

I am in the camp that functional programming is just a set of tools that can be applied to any other paradigms. I don’t see why mixed paradigm programming languages are not put into a category of its own, these languages have a greater impact for most developers and that’s why they end up being much more popular. But, it’s strange that functional programming languages don’t have object oriented concepts integrated into them as object oriented languages have these days. I haven’t tried using pure functional languages as I find the syntax more difficult to understand as they enjoy hiding everything in symbols, plus it looks like many people are creating their own libraries in these pure functional languages.

[@jonathanjacobson7012]

FP is also about recursion, which may (or may not) improve your understanding of how to solve a probelm.

[@arkeynserhayn8370]

@@jonathanjacobson7012 [...] May or may not be a good method of abstractly representing the problem at hand. But sure, it is individuals' problems if recursion doesn't represent the problems they want to solve.

[@mintx1720]

I think it kinda correlates to the death of enthusiasm on rust backend. Something something clean code + messy internet + messy business requirement = disaster.

[@craigyoung8008]

For a long time now I’ve maintained that developers fail to appreciate just how fast computers are. Most efforts at multi-threading add complexity, increase errors, introduce overheads orthogonal to the problem; and ultimately slow things down. The biggest mistake is failing to be fully aware of what the performance bottle-neck actually is. When it’s not the CPU, the only thing multi-threading “achieves” is making multiple cores fight for access to the bottle-necked resource.

[@ContinuousDelivery]

...and it is very rarely "the CPU"! Everything else is SO MUCH SLOWER than any CPU these days, that a huge amount of the work in a high performance system is keeping the CPU fed with data.

[@madlep]

Language choice isn’t based on technical merits. 90% of it is sociopolitical. If everyone going through a boot camp learns JavaScript or Python, they’re not going into jobs using functional programming.

[@InconspicuousChap]

I mean who are those "we" who are going to move one way or another? Hundred millions of coders only knowing how to plug a framework into their CRUD app? They would be happy to use COBOL, BASIC, Python or any other ad hoc stuff with the lowest entry threshold possible, only it's not them who decide it. E.g. Apache Spark dealing with big data is written in Scala and is most efficiently used from applications written in Scala. Whether coders want that or not they have to learn Scala in order to use it. That would be the case with any area where FP is a fit: once problems become big enough, they require more math to be solved, and FP is some of that math. That's the way the world is moved, not via mediocracy voting.

[@almari3954]

I think this video, as many others, confuses parallelism with concurrency. Concurrency is not about running things faster. Also, FP is not (only) about using pure functions. FP is about using higher-order things. Mutation is only one type of side effect. So FP has more to do with correctness - building larger systems without bugs. Languages have not really embraced FP. Having iterators in language is not FP.

[@ContinuousDelivery]

I was replying to the most common argument that I hear used in favour of FP, that it allows us to automatically parallelise things more easily. If concurrency is not about improving performance, but makes the code lengthier, and more complex, then what is the advantage? I certainly buy the idea that 'correctness' matters and certainly believe that FP can help with that.

[@almari3954]

@@ContinuousDelivery Parallelism is about _processing_/_doing_ multiple things at the same time. Concurrency is about _handling_ multiple things at the same time. So concurrency is about IO, or more generally, about handling side effects. Small examples might be giving an impression that the code just gets lengthier, and more complex. The advantage is seen with bigger, more real-world problems. Automatic parallelisation, when it /occurs/is possible/ is just an added bonus, but not the primary goal.

[@ripwolfe]

I'm currently learning Haskell to work on my FP muscles and am enjoying the exercise, but gotta say, not sure I'd want to use it in production. The language itself is fine, with its own fair share of quirks, but the developer experience with documentation, the LSP, and package management is a bit of pain. I'd love to work on a full production project in Haskell just to see what the heck I'm missing.

[@anoh2689]

@@ripwolfe elixir is much more suited for production than haskell

[@JChen7]

I think comparing code snippets of toy algorithms feels a little like comparing big-O results for small values of N... Better than nothing, but not at all illustrative of how it scales to even slightly larger codebases and teams. Also, although I also found the Scala code to be more verbose, I don't think it's safe to conclude it's more complex just by LOC. The imperative style in the Java example is easier to parse, but you're also forced to parse through it every time. Of course it's possible to factor the code into properly abstracted functions, but I'd argue FP/declarative pushes you more naturally toward doing it from the start whereas imperative (and to a similar extent OO) doesn't. Would also be interested to hear from a Scala dev how well crafted that code is or whether the same result could be obtained without so much hoop jumping.

[@andrewdunbar828]

Don't confuse the year a concept appears and the year its now-standard name appears. For instance assemblers and compilers are older than words "assembler" and "compiler". They used to be called "translators" and were not clearly separated until later. Same for "operating system". So it probably apples to "software" as well.

[@lbGkifoo1bj12e9plhjfWA]

OOP languages like C# is converging towards a gimped and syntactically noisy version of F# at every new C# version. Java finally got lambdas. That is where FP has gone... Personally though, I feel that I am drowning in syntax and 'spooky action at a distance' (lack of referential transparency) whenever I look at mainstream languages like C# or Java. It probably just boils down to personal preference, but I find FP way easier to read and maintain.

[@noahwinslow3252]

I think immutability is often easier to read for someone not familiar with the code in question but isn't it the case that mutations are on the whole more efficient since they don't involve as much reallocation of memory?

[@gammalgris2497]

it's just part of the toolset. Use it where it helps you.

[@DataPastor]

Multiparadigm languages like Python, JavaScript or Swift are procedural, functional (to an extent) and object-oriented (to an extent) all in one (kinda). We should inspect, at what extent functional ideas like pure functions are actually used in these languages. And at least in my domain (data processing) while OOP is used of course, but it is not a leading paradigm in good code bases, at least not in “Java style”. Most new mainstream languages (like Go, Rust, Swift, Kotlin) are more or less as functional as object-oriented. And although CS education has a strong bias towards OOP style programming (this is my feeling), developers learn how to write different style of programs at the job, e.g. not wrapping functions into classes unnecessarily if they don’t need to.

[@matthewwilson2369]

I don't think we can call LISP a functional language. It's a very different programming model to what existed at the time, and it had a different idea about how functions could be manipulated and applied, but still a procedural language which happily works with non-immutable values and shared state. McCarthy used the word "lambda" to label a function declaration, but he has written that he had no interest in (or knowledge of) lambda calculus - it just seemed like a sensible sort of thing to call a function declaration.

[@khai96x]

If you try OOP in Rust, you would have a very hard time. If you try FP in Rust, you could make your program outcompete other implementations in other languages in term of benchmarks (even C++ sometimes).

[@Eldad.K]

TBH choosing to speak about clock speeds being relatively the same and performance stagnating since 2005 is a slight miss calculation, because clock speeds have increased to around 4-5 Ghz and we have boosting tech to increase single core frequency on demand. In addition instruction per clock (IPC) has increased dramatically by using bigger caches sizes, pipelining and vectorization. and that increased performance by a big margin compared to 2005

[@stuff9282]

FP has (slowly) been siping in imperative/oop languages, and with time its become the norm. We will never see "real" FP (like in ocaml) as popular as something like javascript. Its does not matter, as the impact has been there, and devs are more aware. There might still be room for a killer lang that "takEs oVer thE worlD", but that remains to be seen.

[@agedvagabond]

Ive been experimenting with functional programming, it is good but i have been using a hybrid approach, sometimes using a direct function call in an object is more performant and sometimes having a decoupled task or service is more appropriate. I probably dont fully grasp what is an isnt functional programming, but i have enjoyed using messages to keep everything nice and tidy and synchrononized.

[@ahallock]

You can split FP into two camps: the pragmatic and the more pure version based on category theory, with functors, monads, and actual mathematical laws. You won't see the latter adopted because it requires a lot more skill and not a lot of people have even heard of it.

[@spacelem]

I've been loving FP in R. My last project I've been slowly converting it so that it's almost entirely done in maps, reduces, and filters, with nary a for loop to be seen.

[@AlexGarcia-ir7fl]

How could one assume the way people write code is dead or not. I rarely ever declare a class the Java way (I mean I use structs or enums for holding values together), all the lifting can be done with functions and structs, a breeze to test in my day to day with Python and Go. Edit: FP is not only to parallelize work and use immutability, it is also the style you choose to write code; readability, testability and control over your code are huge “soft gains” of adopting FP.

[@AlexGarcia-ir7fl]

Also as a Computer Engineering graduate. Abstractions do not exist, it’s all about registers moving bits in memory and “executing a routine” has less blueprint that allocating a whole object with its overhead before start using it.

[@ContinuousDelivery]

As a Nerd, I'd just have to point out that "Registers" and "Bits" are abstractions 😉 😁

[@TheVincent0268]

Is a purely FP language a good choice for front end applications (web, mobile or desktop)? And if so, are there examples of that? The most simple definition of FP I use for myself is that I make use of a function pointer rather than a data pointer.

[@gunt-her]

I've incorporated functional ideas into my design patterns (notably no side effects inside functions), and avoid inheritance trees, but ultimately I still write procedural, and use objects without inheritance. Pure functional programming IMO becomes a bit (a lot) impractical once you have to deal with IO a lot.

[@MonochromeWench]

Functional Programming will never be dead as long as Mathematicians, who know Lambda Calculus, are getting into computer science. The book example of parallelization may not be good as it will depend on how the system has decided to break up the work and if there any hints to tell the system how to break up the work. If you just have a block of text it might be difficult to auto parallelize but a book in chapters is easier. If the auto palarallizer breaks it up into too many small pieces synchronization and start up overhead can be a big chunk of time. I wouldn't trust auto parallelizing unless I can tune it

[@ContinuousDelivery]

The parallelisation thing, seems pretty fundamental to me. However you choose to divide up the work, you will need to integrate the results to get an answer. Now you are into shared or synchronised state, and now ANY wins that you gained from the parallelism are outweighed by the costs of sync. We measured this. The book example wasn't slow because of dumb code, this was the best case example - 4x slower!

[@danilomenoli]

Stackoverflow pools from a statistics viewpoint are completely useless to infer anything. If you volunteer yourself to answer a pool, you don't have a proper sample and therefore any inference based on it is invalid.

[@brandonmansfield6570]

Single threaded performance is not stuck in 2005. Ignoring IPC is mistaken. Clocks are limited, but not fixed at 3ghz.

[@zamf]

The approach of thinking about a single way of solving a problem has the benefit that many things can be assumed to be true and the programmer can step on these assumptions allowing them to focus their attention on the actual problem solving and not on the coding style. The problem is that this approach comes with the cost of worse performance (both in terms of writing the code that doesn't fit the paradigm well and in terms of actual runtime performance). Nevertheless, this approach is widely used in the industry. For example, when using a specific library or framework the programmer is bound to write their code in a style that fits that particular library. And often using two libraries that do the same thing but differently results in a lot of code mess and complicates stuff even though one library could be better suited in one part of the application and the other library could be better suited in another part of the application.

[@gruntaxeman3740]

Idea in functional paradigm is not the performance. It is avoiding side effects. In fact, when solving problem, functional paradigm should be the first to try. If that is too hard to understand or seems to be complex, then object oriented paradigm can be used. While functional paradigm avoids side-effects, to be useful program it needs side-effects. Next best option after functional paradigm is to split problem to functional tasks and put them to pipeline. Then there is only one way to mess it up: using wrong order of tasks. But why should anyone use OOP is that code is written to other people and to be easy to understand. When some local states and messaging is involved, or need to design high level structures OOP is then right tool make those inside process that is running.

[@K_3_V_R_A_L]

The idea that Functional Programming was always going to take of in an Imperative-based system is just like saying the Chinese language will be the next standard for communication in an English-based country; it was never going to happen because what's the point in learning some other foreign and abstract idea, when you've already learnt your own abstract language that is tailor-made for the exact environment you use.

[@oleksii6038]

We have some interesting situation when Java stream().map(...) was MATCH MORE faster then parallelStream().map(...) on big amount of simple map operations

[@wiktorzdrojewski890]

simple map operations - yup checks out, parallelStream probably spawns new threads which is costly

[@oleksii6038]

@@wiktorzdrojewski890 yeap, exactly it was this situation.

[@NuncNuncNuncNunc]

80/20 rule. Many languages get you 80% of the value of functional programming but require libraries in order to approach getting that last 20%.

[@elkaro5]

I remember programming in lisp back in the university days. What a parenthesis orgy!!

[@kamikarmy]

I feel there are some nuances that might not hit home. I do agree with most such as one should use the right tools, and let's not be religious about it. There are comments that address these (about react for example). I would say that instead of looking at a micro level (that Java vs Scala micro benchmark proves a point of over design, not readability or performance), let's look at it at a macro level. Consider that Whatsapp/ FB Messenger are good case study of FP design that makes a system scale and is easier to manage. Or compiler design such as parsing expressions grammars, which are quite popular on FP languages, and leveraged in recent years by Python and Guido. Overall though, FP did get through the backdoor, slowly.. there is a question of education and culture which takes so much time for folks to get used to. Just like most systems, we end up with a mix of everything, hopefully working altogether. =)

[@disdroid]

functional algebras don't always translate well to actual software. for example, recursion - rec(x) resolves to an infinite amount of x, or effectively, one more x than we will use in the program. but no computer has an infinite amount of memory.

[@arcuscerebellumus8797]

In a list of stupid hills to die on, "FP vs OOP" comes as a close contender for the first place. ALL paradigms are equally irrelevant if looked at in a vacuum. One can write oneself into a corner in any of them, and all of them can become a vehicle for "untangling" any problem. The main factors that determine on which side of this spectrum a concrete individual falls are and always were: experience and domain specific knowledge.

[@xyhmo]

Few years ago… new kid on the block? Haskell was our main language in my CS program 20+ years ago. And the talking points were the same back then. No worries, it will conquer the world any day now.

[@arborinfelix]

I am an F# developer and I use it for domain modelling and readability

[@vitaliiivanov9514]

Yeah, FP languagea are great for domain modeling! I like using Scala for that

[@rotgertesla]

Do you still have to code your F# functions in the right order or else he program won't compile?

[@arborinfelix]

@@rotgertesla Your business processes are also in an order. You will not ship a product before you get the money. You will not push a button on your coffee machine before you make sure that there is already some water and coffee beans in the machine. The thing with the order is one of the most important things in FP. When you feed the output of your function to the input of your next function you have to make sure that the output of the previous matches the input of the next one. After you made this work then you write this with errors/exceptions and missing values in mind (none (null/nothing in other languages))

[@ZapOKill]

Lisp (and all its dialects) is not FP, but Parenthesis Oriented Programming

[@AndrewBlucher]

I like PoPs, but it's not limited to Lisp. Prolog is fun too!

[@AndrewBlucher]

18:40 An excellent demonstration of the danger of premature optimisation!

[@shardator]

FP is super difficult. I want to tell the program what to do, and have control over the execution. It is hiding a lot of things behind obscure layers of abstractions. How does someone do any low latency functional programming, like ever?

[@bearwolffish]

Maybe the hype has died down, though the patterns feel much more prevalent throughout code bases. Best case as any hype passes is to have the elements that organically make sense be absorbed by the relevant parties/sectors. Personally am still reading books on functional cpp, and patterns learned from an old ocaml course still heavily define my style in all languages. So it hasn't gone anywhere for me.

[@KarlLew]

FP keeps dying since I wrote a LISP interpreter half a century ago. Which means that FP is a useful tool but not the only tool.

[@Vogon42]

I would love to see the benchmark comparing Python and JS.

[@deyanvp]

My advice: program at least 3 years in a FP language and then make a 2nd video. Hearsay is not good enough. The main problem is mainstream, critical mass or what is a safe choice career-wise for both developers and their managers. Started a new FP project 5 years ago - ask me how many times I was (jokingly) asked if it was a good choice, if hiring is OK etc...

[@talananiyiyaya8912]

We're alive and well in HFT and finance in general.

[@culturehyena]

A suggestion: If there are text-based quotations in a video, please get someone to read them out!

[@farsthary1984]

Great video. Developers are no different than the fashion industry.