This was the best VO talk I have ever seen. After watching and reseaching countless hours on the subject I can finllay get my head around it. Thank you!
Enjoyed the talk very much, especially the humor. I came here as a professional Scala developer after an interview where I failed to enumerate functional programming patterns I use. I leave kinda disappointed because I use most of these patterns daily anyway. I guess when I'm asked to enumerate functional programming patterns I use again, I'm just going to use the fancy names like continuations, monadic bind and functors.
There is a problem with the technique used at 57:40. The Order total is wrong when the code is refactored. Original: 2 * 19.98 + 1 * 1.99 + 3 * 3.99 = 53.92 Refactored: 6 * 25.96 = 155.76
While I have quite a long way to go until I can properly re-program my brain to think more functionally, this talk really helped spark a couple light bulb moments. Some of the ideas I actually ran back to my company's OOP Enterprise code and implemented, funny enough. Great video, hopefully a couple more of these and I'll have my head wrapped around this crazy functional world :)
Functional programming is all BS, summed up as f(BS)! None of these talks illustrate clearly how to use functional programming to solve a the types of problems developers need to solve. They always cherrypick some mathematical problem like Fibonacci sequences. They also emphasize brevity of the code without discussing metrics we really care about such as performance. It's all intellectual masturbation.
There is no silver bullet unfortunately, all programming paradigms has its own pros and cons. In the end it depends on project, administrative politics, area of use, your team, your level, tasks etc. But it is better to be aware of all of them in order to choose the most appropriate one in your current situation. P.S. Yeah, seems like functional programming has its own benefits, compared to OO style for example and vice versa.
Wow, great! I think that FP patterns combine nicely with DB in 6th normal forms, since you call functions with included another functions - > You get benefits of right definition what to call. And in some super fast DB where only value pairs are possible you could get super fast code. There is Convergence I think.
Nice catch. You may try to implement a sample project since practice is the best judge for ideas. Try look at www.anchormodeling.com/about/ for some inspiration.
@@ivanplyusnin3292 I thought about using Key Value pair DB like REDIS or MemcacheDB. What do you think? Tools you provided link to might be way to MODEL DATA -> USE Key value DB in 6NF WITH Functional programming . Only think is how to store precipitant data. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-W2Z7fbCLSTw.html
you talk about how object-oriented is bad in the example where methods that take a string, expecting an e-mail address, could pass in some other string that's not an e-mail address such as a last name, to present the benefit of value-objects. but then you talk about how interfaces aren't needed in F# because you can functions compatible based on structure. It's a little bit misleading because in object-oriented programming, interfaces are the way you give data stronger type-safe guarantees. The interface from OOP which you seem to down-play *is* the primary mechanism to provide a type .
This was a very good presentation. But the more i watch/learn about FP the more holes i discover. For very small benefits we add so many not necessary things, complexity, dependencies, ugliness of code, non-uniformity, potential for errors ...
Alright I'm sort of confused. At 23:19 he talks about how he could rewrite the interface in F# using one function... If the interface is already only one method, and that method only accepts int and returns int. Could he not have just done the same thing in the original language by just ... scrapping the interface?
Does List.fold loop or is it a recursive higher order function? He says loop in the video but I am guessing that is just a hiccup and he means recursion but I don't know f#. From my understanding a big part of functional programming is treat data as immutable, so no loops. Is that right?
There is nothing wrong with loops in functional programming. Recursion is usually just a loop anyway. Look at the source for List.fold for an answer to your question. github.com/dotnet/fsharp/blob/main/src/fsharp/FSharp.Core/list.fs#L216-216
You can't really have something like NonIntegerZero in most languages. This is sort of the limit of even the most powerful static type systems. It is the domain of dependent typing but then you have to give up Turing-completeness...
no, dependently typed languages like F* and Idris are still Turing complete! diverging (non-terminating) functions are allowed, as long as they're marked as such.
basically many presenters which i have seen so far started introduction into FP same way as the last statement. "Monad is just a monoid....." together with bunch of lines with FP stuff while repeating same words over and over. Monoids, monads, functors, endomorphisms without explaining single word. This guy made this stuff much more clearer. Very good presentation.
1) 43:05 I didn't get the error handling part - he showed the code before and after error handling, it was the same, ok great soooo - where was the error handling? where did all the different error messages go? they were different for each error so surely you had to put them somewhere... highly misleading (he suggested 200% extra lines just for error handling, 0 extra lines for error handling in F# - that's what i'm challenging: the code did go into the monads sooo ... it's not like it disappeared ;) 2) 42:26 he got the promises wrong - the promises ACTUALLY SOLVE the pyramid of doom the exact same way bind does :-D he presented it as if they just rewrote it in different words.
I post a question in Stackoverflow(stackoverflow.com/questions/45626196/defining-a-non-zero-integer-type-in-f/45635075#45635075) about this matter and all responses revolve around creating a NonZeroInteger type that throws an exception when a zero is passed to constructor, but this can be achieved with any OO programming language so why the video's author claims this as a F# or a functional programming goodness. Honestly I feel tricked.
F* has refinement types that can do exactly what you're thinking of (among many other static typing features), and can be reduced to F#. www.fstar-lang.org/ But I think you're missing the forest for the trees. Even that example you linked shows how sum types like Option can be used to handle errors _without_ exceptions. If you watch the rest of the talk (or more relevantly, the follow-up talk on error handling vimeo.com/97344498 ) there are many examples of why that property is useful.
Is it just me, or does anyone else think exceptions are kind of nice. Why do the extra work, everyone knows what divide by zero exception means. Handling exceptions with try catch and doing some custom logic is hardly a new concept.
