Expressions versus statements? The future of functional programming (with Steve Krouse)

Поделиться
HTML-код
  • Опубликовано: 12 сен 2024

Комментарии • 26

  • @DanKaschel
    @DanKaschel 4 года назад +20

    Maybe I just wasn't the audience for this video, but: I was waiting the whole time for simple examples that would demonstrate these concepts. As someone interested in functional programming but never tried it, it was hard to connect this dialog to how I code and how I might do it better.

    • @funfunfunction
      @funfunfunction  4 года назад

      Have you used React?

    • @DanKaschel
      @DanKaschel 4 года назад

      @@funfunfunction I've done some code maintenance in react but haven't built an application in it or implemented a major feature.

  • @ShisuiElric50
    @ShisuiElric50 4 года назад +1

    The clean architecture is an architecture created by uncle bob:
    blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
    The essential idea is that instead of tying our backend service to a particular io device (http, websockets, tcp, amqp, smtp... i could go on),
    where for example an mvc framework always deals with http and sql and you need drivers for everything you use,
    We instead create controllers/presenters/gateway modules for each of these, and when we receive messages from client controllers,
    they trigger a interactor/"use case" function/object/module (size this as you please), that can then decide what to do with the message.
    So the flow of control can be something like this for creating a user and saving it to db:
    main starts controllers (e.g start database connections, start express server) ->
    client controller receives protocol message and converts it to entity ->
    client controller calls use case ->
    use case DECIDES what to do, maybe if its not valid it doesnt do anything, if it is, it calls the EntityRepository to save. ->
    entity repository converts the entity into db specific entity (here you can use your orm if you want) ->
    maybe if its functional you can return IO Success?
    use case sends back a entity to client controller ->
    controller converts it back into a protocol response.
    This architecture also emphasizes that the layers always only use their public interfaces, and do NOT require very specific modules,
    so you shouldn't just import a specific controller in a use case, but instead be passed in a controller.
    This is an architecture really so its more of a modules vs classes, I prefer doing this with modules that are singletons.
    You can use functional programming techniques for use cases for example to make them highly testable.
    You can mock all of the controllers that a use case needs to use.
    In the entities layer you can have modules that convert between entities or transform them. These should be independent of the application.
    Another good candidate for functional programming.
    So funny because literally just yesterday i was looking at the architecture to build an app in node.js for a couple of protocols.

    • @ShisuiElric50
      @ShisuiElric50 4 года назад

      Another note is that use cases are not tied to controllers, a controller can use multiple use cases.

  • @iAmTheSquidThing
    @iAmTheSquidThing 4 года назад +1

    Perhaps part of what makes functional programming inaccessible is that most programming languages aspire to be more like written English. Whereas something like Haskell seems to aspire to be more like terse mathematical notation.

  • @zehrhayader-_-6762
    @zehrhayader-_-6762 4 года назад +1

    Man, this discussion was fun.

  • @fuunnx
    @fuunnx 4 года назад

    I really love this subject, that was a great discussion !

  • @leonk6950
    @leonk6950 4 года назад +4

    I think the problem with monads is that the concept itself is extremely easy. flatMap is a very simple function. Using Promises isnt Hard. Working with Maybe-Monads is simple.
    Anyone can understand how to work with monadic "Maybe" types and such, thats not the problem.
    The problem are the implications of the concept. BECAUSE its so simple, it is extremely Hard to understand how they can allow for the complex, broader things that they are used for in haskell (state, IO, etc). Understanding how Do-Notation works is simple. Even knowing that if you do work on a state-monad, you never actually change the state directly, but just Tell the monad what to do once it Has some state is easy. This is taught reasonably well.
    But if you actually want to do sideeffecty stuff you need to understand how monads are a special-case in the runtime of haskell and such. You need to know what they Do. This is taught extremely poorly. People talk about being "in a monadic context" like it would be some big Thing you implicitly are in, which is definitely not the case.
    I think a great way to teach monads is to implement them in a language that doesnt need them, say Javascript or kotlin, scala, etc. Something with higher-order functions.
    You can Tell someone "Hey, youve got this one function that can perform side-effects, and it needs to be the main entrypoint to your Software. If you want to have a function deeply within your Code do some sideeffect, you need to create a way for it to express that sideeffect without executing it, just by handling it as a value.
    This way people can naturally arive at why and how monads work the way they Do, and gain Understanding about how they are used in pure languages runtimes.

    • @iAmTheSquidThing
      @iAmTheSquidThing 4 года назад

      This seems like a helpful explanation. I mostly understand what a monad is in programming. And I mostly understand what a monad is in category theory. But I've yet to understand why those two concepts are linked.

  • @qwarlockz8017
    @qwarlockz8017 4 года назад

    Great discussion. I can listen to this stuff all day! LOVE it! By the by... what software are you using to actually run the interview? What are you using to capture both and compose it?

    • @qwarlockz8017
      @qwarlockz8017 4 года назад

      I would love though a better differentiation between functional and non functional programming. I come to programming from a java centric background. Java is fast trying to incorporate more concepts of functional programming and reactive programming into its core. After watching this I still do not come out with a strong differentiation between the two. If it is that functional programming is mostly defined as each "entity" is composed only of other entities defined within until ultimately they point to base truths (number, boolean..etc) then cant we actually still write that way in java? Is it more just a way or writing disciplined code and not a difference in the language? I am sort of having trouble seeing that more fundamental difference.

  • @yashthatte6137
    @yashthatte6137 4 года назад +5

    TechLead video in recommendation hahaha

  • @Massenhaft1
    @Massenhaft1 4 года назад

    If you want to learn functional programming, try "ELM". It's really fun!

  • @PlerbyMcFlerb
    @PlerbyMcFlerb 4 года назад +2

    This is a great talk, but take slight issue with the broad assertion that ANY monad is a cheat. If you’re referring to the IO monad I’d agree, but how is, say, a Maybe monad a cheat? It’s just a useful composable abstraction and has nothing to do with side affects or breaking referential transparency.

    • @jingoringo
      @jingoringo 4 года назад +2

      For sure. There's list where the bind is like substitution and flattening, reader which models computations with an implicit argument, state which models computations whose implicit argument can be modified, and so on.
      It's not really about imperative programming at all. It can be, but in general it's more about how you build expressions and how those compound expressions are flattened or interpreted.
      For example, in maybe whenever a subexpression evaluates to Nothing, the whole expression flattens to Nothing. For State, the flattening ensures that changes to the implicit argument are sequential.

    • @MdImrulHassan
      @MdImrulHassan 4 года назад +1

      +1 Corey. I feel like the discussion made sense for IO monad - it is easier for someone coming from imperative programming background to think IO as a way imperative code.

  • @devluz
    @devluz 4 года назад

    linode looks like a good sponsor for you. I was thinking about giving it a try just to learn & play around with their cloud services / vm's but it looks like they bill based on data usages and other factors? I am too scared of some unpredictable bills showing up :s

    • @AkamaiDeveloper
      @AkamaiDeveloper 4 года назад

      @devluz All our services including CPU, transfer, storage, and RAM are bundled into one simple price. They are billed hourly, but only up to a monthly cap. Check out our FAQ on this page for more info www.linode.com/pricing/

  • @warlordzephyr
    @warlordzephyr 4 года назад

    I've used React for a little while now, but lately I've been considering Elm as an even more functional alternative.
    Have you looking into Elm? I'm very curious about your opinion.

    • @iliyass
      @iliyass 4 года назад

      Im in the same boat, but still not sure about using Elm in prod, there many limitations

    • @leonk6950
      @leonk6950 4 года назад

      Just try it! Elm is great because its really easy to Use, and there are few things that you can not Do.
      While Elm is incredibly limited compared to purescript and such (it most definitely wont be "satisfactory" feeling to people used to haskell and purescript, because it doesnt have most of the Mathematic abstractions they Do) it IS absolutely powerful for every Real-World usecase. If you have a project where you need Tons of local state or need to Use loads of third-party libraries,... Sure, go react or maybe purescript-react. But if you have an average Projekt and want the safety and readability and maintainability of one pretty much the "cleanest" language out there.... Go Elm!

    • @Supamic1
      @Supamic1 4 года назад +1

      In searching for more "comprehensive" frameworks, languages and design patterns I came across Elm which then lead me to Elixir + Phoenix which then lead me to Erlang and the BEAM VM. I can tell you everything you could want in pure functional reactive programming exists in various combinations of these tools for building fully distributed, fault tolerant and scalable systems. The key is immutable memory like Steve mentioned in the video, for FPV statements and mutability should be done at the implementation later of a language but Erlang and the BEAM VM( the core of the stack) are built on the idea of pure immutability so it forces you to build within that paradigm. I'm just in the early days of exploring these languages and concepts but I'm feeling like I've stumbled upon some serious gold.

  • @DoubtfulIntelligence
    @DoubtfulIntelligence 4 года назад +1

    denotative wam?

  • @NWCalvank
    @NWCalvank 4 года назад +2

    Seeing mostly negative comments on this discussion, so just thought I'd drop in and say that I really enjoyed it
    Though... 19:35 - I feel personally attacked ;)

  • @jamesjosuejara
    @jamesjosuejara 4 года назад +3

    first comment! awesome talk @jamesjara