Common misunderstandings about Functional Programming

Ғылым және технология

Learn more about the philosophies of FP and make FP click by joining “How to think like a functional programmer” - impurepics.thinkific.com/cour...
#fp #functionalprogramming
Subscribe to Impure Pics: bit.ly/impure-youtube
More Impure Pics
🐣 / impurepics
📦 impurepics.com
👕 merch.impurepics.com
Functional Alphabet book
📗 Softcover: bit.ly/fp-abc-soft-cover
📘 Hardcover: bit.ly/fp-abc-hard-cover
Watch more Impure Pics
• Debunking Haskell Myth...
About Impure Pics
FP Advocat. Distilling functional programming for the good of all
Get in touch: zelenya.com
0:00 Intro
0:48 1. FP is too theoretical
1:38 2. FP is unintuitive
2:57 3. FP is too slow

Пікірлер: 29

  • @somnvm37
    @somnvm374 ай бұрын

    imo, the "fp is unintuitive" is like when people say that linux is unintuitive and difficult every time i hear people say this they give the idea about 10 seconds, and always try to force their old ways on it. either way, even If i don't end up using fp, learning about it would be fun and useful for regular oop programming too.

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    It's funny because it's actually far more like the math we learned in school then imperative which just randomly renames a bunch of things to make it confusing

  • @droydi
    @droydi4 ай бұрын

    Discovering Nix brought me here, I feel like I am falling into a deep rabbit hole

  • @beauteetmusculation8191

    @beauteetmusculation8191

    4 ай бұрын

    You don't know how deep this goes.

  • @i-am-the-slime

    @i-am-the-slime

    4 ай бұрын

    ⁠hey I really like your zig videos and your username even more

  • @beauteetmusculation8191

    @beauteetmusculation8191

    4 ай бұрын

    @@i-am-the-slime Thanks! ^^ Glad to know.

  • @tanko.reactions176
    @tanko.reactions1764 ай бұрын

    making changes in in a hello world program is nice. making changes in an enterprise level software which grew over 30+ years.. well, how do i put it... consider this example: you repair the door on the 3rd floor of an apartment and you MUST check if the entrance door to the building still works. you must also check whether delivery guy can park. you must also check whether the people entering and leaving the building are happy and had coffee yet. if you do this, you have covered 5% of all the use cases, then you declare your work done (because its unfeasible to continue checking) and pray to God nothing breaks.

  • @tanko.reactions176

    @tanko.reactions176

    4 ай бұрын

    what i wrote is due to one single principle, which is the antichrist: DRY. do not repeat yourself means that people abstract logic into common methods, which have a couple of overloaded variants. the thing is, this is the place where most other logic passes through, its a hot spot. if you change anything here, a line which appears like its doing nothing, appears like its pointless - BIG MISTAKE. shame on you. i once watched a junior guy be smart about it, being silent in the back grinning watching him do all those cleaning around existing huge code.. he then executed the tests and practically nothing worked anymore. Whoever came up with the idea of "DRY" was the false prophet, the left testic*le of the devil!

  • @yash1152
    @yash11524 ай бұрын

    3:45 > _"[copying immutable ds] is cheap; values are not physically copied"_ ahw nice, so, can u explain how would a map, or filter would work under hood. like say assembly level overview of compiler output for these operations?

  • @illusion466

    @illusion466

    3 ай бұрын

    It's actually a much more complex topic than his passing comment makes it seem. Not all immutable data structures are cheap to use, and many times, they are physically copied. Have to look at what's going on in a language by language basis

  • @yash1152

    @yash1152

    3 ай бұрын

    hi@@illusion466 ! yeah makes sense. aside... do you recall where ur youtube cover image was took from? it's kinda looking nice. the lady in black suite, netted neckline, with silvery sleeves and dual tone cape and sword.

  • @oskarwerner2164
    @oskarwerner21644 ай бұрын

    Great video!

  • @damiangilz
    @damiangilz4 ай бұрын

    FP is amazing, I just not like the maths lingo. I prefere loose FP than strict, though (like not forcing recursion).

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    So you'd rather have random names that nobody agrees upon and have to learn it 10 different ways with no way to actually understand the mathematical background behind it... Instead of using a math word?

  • @damiangilz

    @damiangilz

    4 ай бұрын

    @@user-tx4wj7qk4t hmm no, but if I had a fp language id just call the stuff the best way I can, Gleam is an example of this as it avoids the jargon. If OO ppl do it in the definition of a mere object why wouldn't I?

  • @i-am-the-slime
    @i-am-the-slime4 ай бұрын

    Zablo!

  • @impurepics

    @impurepics

    4 ай бұрын

    Hey there, thanks for dropping a Zablo!

  • @user-tx4wj7qk4t
    @user-tx4wj7qk4t4 ай бұрын

    Treating fp as "Java but with better defaults" is not going to get you any converts. Nobody is going to reduce their job prospects and make their life hard or change entire codebases for "better Java". The math and theory behind fp is the entire selling point and the change in mentality is the entire point. Also frankly if you actively dislike that stuff then this isn't the field for you. Computer science is math Oh and if you want practical then FRP is what you should be advocating for. There's nothing more practical and yet less talked about

  • @isodoubIet
    @isodoubIet4 ай бұрын

    I'm sorry but it seems very odd to argue that FP doesn't have a performance problem and then use a linked list as an example. Immutable data structures perform poorly, that's the thing. I did give functional programming the old college try. I stopped when it became clear that FP wasn't at all interested in solving the problems I wanted to solve. As for it being difficult, it's not that it's insurmountably difficult. It's that it's _unteachable._

  • @impurepics

    @impurepics

    4 ай бұрын

    What kind of problems do you want to solve?

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    For general purpose programming that is read heavy it is absolutely a better use case than any alternative. So unless you're doing something extremely low level than it is most likely the solution. And it's actually more efficient in countless ways especially with linear types Really the point is that the compiler can optimize your code instead of making you optimize it

  • @isodoubIet

    @isodoubIet

    4 ай бұрын

    @@user-tx4wj7qk4t In practice, it doesn't compete with a more hardware aligned language like C++. Haskell performs better than python, sure. Not exactly a high bar though.

  • @isodoubIet

    @isodoubIet

    4 ай бұрын

    @@impurepics I do math-intensive, performance sensitive work, so what I need are abstractions that perform predictably and well, giving me control over allocations, cache locality, parallelism etc while also being able to offload work to the GPU if needed. FP languages let me express the computations I need to perform, but they typically don't let me say anything about _how_ they'll be performed.

  • @guotesuoze
    @guotesuoze4 ай бұрын

    Nah, fp is cool, but its kinda annoying to use in actual programs. Though if you have to write some industry standard shit, you are fucked regardless of the language or paradigm haha.

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    What part is annoying? I find it far less annoying and boilerplatey than any alternatives. You actually say what you want using high level abstractions instead of having to write pages of instructions to do something simple

  • @guotesuoze

    @guotesuoze

    4 ай бұрын

    @@user-tx4wj7qk4t Where do I even start? I don't really wanna write in detail so it gets ignored by the community.

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    @@guotesuoze ignored by what community? And idk start anywhere? I use it in actual programs with GUIs and without and it's far less annoying than JS or Java

  • @BloodnutXcom
    @BloodnutXcom4 ай бұрын

    I'm sorry but I gave a thumbs down. Because the pain points list you talked about is mostly a typed vs untyped language problem, not FP. Some points were valid but not all necessarily correct. Immutable structures could be safer for multithreaded code but not necessarily efficient. In the case of green threads like Loom, you can use shared state and have locks and it will still be cheap, as opposed to increased GC pressure from all the extra allocations. The entire video felt too hand-wavy.

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    That's because the common criticisms are hand wavy. Saying "it's inefficient" ignores that it can be significantly more efficient if used correctly. It also ignores that 99% of software doesn't have an efficiency problem but rather a bad developer problem

Келесі