The Next Steps in Functional Programming

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

Learn more about FP and make FP click by joining "How to think like a functional programmer" - impurepics.thinkific.com/cour...
💡 Useful links:
* The Joy of Abstraction: / 60658614
* Functional Programming in Scala: www.manning.com/books/functio...
* Functional Programming Made Easier: leanpub.com/fp-made-easier
* Grokking Functional Programming: www.manning.com/books/grokkin...
#fp #functional #scala
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 Where to go
1:39 On Category Theory
2:41 Books

Пікірлер: 15

  • @nicholasantidormi6238
    @nicholasantidormi62384 ай бұрын

    Grokking simplicity is another good book to start with for "beginners". FP made easier recommended to do the "paradigm shift"

  • @benniecopeland7388
    @benniecopeland73884 ай бұрын

    You can also use F# and Fable on the frontend. Fable allows you to transpile F# code to JavaScript and you can easily share the API types.

  • @sigmundwong2489

    @sigmundwong2489

    4 ай бұрын

    F# + Fable is **fantastic**

  • @mskiptr
    @mskiptr4 ай бұрын

    I learned Haskell and Idris by first going through an online tutorial (lyah specifically) and then watching tons of PLT conference talks, some tutorials | idea overviews (from Tsoding for example). I was also picking Haskell to do some university projects in - e.g. for the Information Theory labs.

  • @yarosav5396
    @yarosav53962 ай бұрын

    oh, red book, it's really hard

  • @davidochsner
    @davidochsner4 ай бұрын

    Real

  • @snatvb
    @snatvb4 ай бұрын

    Regarding category theory, my advice is not to dwell on it at all. I recommend studying it if only you want to go deeper, to understand where things come from. It's like studying CPU and memory structure for JS or Python programming, at the beginning of the way it will only slow you down and will not be useful, and when it comes to applying such knowledge, you will already forget this theory.

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    It's not like that at all. Functional languages are by definition defined with denotational semantics. They only have meaning from the math behind them. Trying to understand them operationally or with rote memorization is completely missing the point. So yes you need to understand the basics of lambda calculus, set theory, abstract algebra, category theory, type theory, etc if you want any of this to make any sense. The keyword is "basics" and the effort put into trying to avoid math is double that of just learning it This constant desire to avoid knowing anything in software engineering is a sickness. You'll never hear a civil engineer going through mental gymnastics to justify not having to know any math or science. And now with AI you're most likely going to lose your job if your understanding is surface level because nobody needs somebody to just memorize some idioms and copy paste code they don't really understand

  • @snatvb

    @snatvb

    4 ай бұрын

    ​@@user-tx4wj7qk4t I told about curve of education. If you wanna try FP and start work with it - you can do it wihout this deep theory. Actually you can move quite deep wihout theory and this will be enough for 80-90% of all tasks and code that we have in programming routine. If you wanna be architect, and etc it will be useful

  • @user-tx4wj7qk4t

    @user-tx4wj7qk4t

    4 ай бұрын

    @@snatvb the people who think this end up just writing slightly better js. That's not FP. If you don't at least understand conceptually what a functor, applicative, monad, semigroup, monoid, semirings, etc are and don't understand that types are sets and that ADTs are semirings then you don't know FP at all and will likely write bad code too. You can see this on exercism where most of the haskell solutions are terrible and look like slightly better js

  • @snatvb

    @snatvb

    4 ай бұрын

    ​@@user-tx4wj7qk4t you can't imagine that i've seen on oop in FP I have an option to refactor it, on OOP usually I have only one option - burn it out :D actually I know that if you know all of that, you can write bad code still cause wrtie simple, readable and supportable code is another skill

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

    Couldn't disagree more, the first part of bartosz' book clarifies a ton of things. If you don't understand at least that then you don't understand much of anything about FP past the absolute basics of lambda calculus but I'm assuming you think that's a waste of time too Also yes, you do need to know horticulture if your job is to grow plants... You seem to have the common view of software engineering as a blue collar widget churning factory job. I'm sorry to say but nobody needs those people especially with AI now. And NO the joy of abstraction is a literal propaganda with some crazy feminist randomly shoving politics into category theory and bringing up patriarchies. Read bartosz, a guy who actually cares about category theory and relates it to happen instead of an activist trying to destroy society And yes you do need to know what a kliesli category is if you want to actually understand monads. "IO" is not "monads". The very reason"nobody understands monads" is precisely this desire to avoid explaining kliesli categories and what functors and applicatives are.

  • @sigmundwong2489

    @sigmundwong2489

    4 ай бұрын

    I agree with your disagreement, but I don't know how much Bartosz's book cleared things up for me. At least, not until the chapter on the free monoid. As a non-mathematician, I strongly believe that the free monoid is the best entry point into CT for laypeople like me. Also, how to properly read commuting diagrams is comically underemphasized in almost all introductory texts for laypeople. Nearly ALL diagrams that non-category-theorists are used to looking at correspond to "string diagrams" in CT, NOT "commuting diagrams"-so we come pre-loaded with a lot of wrong intuition that nobody bothers to clarify. We are all used to reading diagrams to understand connectivity, but connectiviry is NOT what commuting diagrams are about. They are not there to tell you which objects are connected by which morphisms, but which parallel morphisms are equal. The notion of "equality of morphisms" is also underemphasized (and the difficulty of pinning down morphism equality is part of why "Hask" is not a category.

  • @reo101
    @reo1014 ай бұрын

    Fake

Келесі