How Does Functional Programming Work in Production?

Подписаться 1,4 тыс.

Просмотров 3,3 тыс.

50% 1

This is the long awaited part 2 to • Is Functional Programm...
Link to my website: www.spronket.com
In this video I talk about the tools functional programmers have to develop real-world production applications including:
Immutable Data Structures
- Immutable Arrays, Immutable Hashmaps, Immutable Sets
- Linked Lists
- Immutable Trees
I also talk about how to structure real-world functional programming applications including:
- how to build a webiste using functional programming/how to build a web server using functional programming
- how to build a client-side application/how to build a game/how to build a desktop application using functional programming.
I also talk about some of the benefits of functional programming, including memoization and lazy evaluation.

Опубликовано:

28 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 20

@user-dc9zo7ek5j Год назад

You never stop smiling during the whole video and this makes me also happy. I'm still trying to wrap my head around the pros and cons of each way of dealing with impurities. What I find interesting is that you can use popular OOP languages and make them pure. Even one of the main things added to them is lamba syntax, where you pass in methods to reuse implementations and allow for composition of smaller functions instead of writing a loop with filter and a new add to a new list and so on. I get the idea behind grouping side effects at start and end of logic instead of having them in the whole logic chain, but I don't get what are you going to do inside the function if you do this. For example, if we need to loop over all the rows from query in db and return a model list, then if we get all the rows and transform them beforehand, what's the point of the function, we've moved the side effect, but now this function is useless, another one is inserting, if we have the model and we just need to save it, then how can you extract a pure function out of this? I think the logical answer to those questions are with callbacks, for db query pass in a function which accepts a function which accepts a row and returns a model, for the insert however, I'm not entirely sure, maybe pass a function expecting a model and return the function again but with the model, to leave to the caller to execute that function db call. What do you think about this?

@sammytalks7215 Год назад

hm -- not sure if this is what you're getting at, but the main idea is that you can get the same style as a mutable update, without the mutability, by using immutable hash maps with fast updates. i.e. in the mutable world, you'd have if (rightButtonPressed) { worldState.marioPosition = currPosition + 30 } but in the immutable world, you could say if (rightButtonPressed newWorldState = worldState.newImmutableHashMapWithUpdatedValue(worldState, marioPosition, currPosition + 30); } then you could have a more complex function, like functionUpdateWorldState(oldState, controllerState) { worldWithMarioMoved = updateWorldStateForDirection(worldState); worldWithGoombasMoved = updateWorldStateForDirection(worldWithMarioMoved); ... worldWithCollisionsDetected = checkForCollisions(previousWorldState) } for looped behavior, you could use recursion (or reduce!) to pass in the previous iteration, i.e. function moveGoombas(listOfGoombas, worldState) { worldAfterFirstMove = moveOneGoomba(first(listOfGoombas), worldState) moveGoombas(rest(listOfGoombas), worldState) } it gives you this sort of complex modification, without the mutability. hope this helps! :D

@user-dc9zo7ek5j Год назад

@@sammytalks7215 I meant there are 2 ways of dealing with impurities. 1. partial application, 2 functions, one with implementation and the other one with abstraction. 2. Inversion of logic, invert the code so that the business logic is not the last one in the chain, and thus removing impurities. For example: 1. ui -> event -> business logic factory (real connection, impure) -> business logic with abstract dependency (get, modify, save user). 2. ui -> event -> business logic (real connection, impure), get db row and pass to pure function to create user type, pass old user and new settings to pure function with returns the updated user, save (impure). The first one is pure in theory, because we can pass in a dependency which is not external, but still, it has impure actions in the real world. The second one has the impurity upfront, but it calls it's pure business logic, which does not have such dependencies. Just like what you explain at 11:14.

@totallynotvme Год назад

Thank you for your videos! Really hard to find interesting and good talks or videos about functional programming on here and your videos helped me a lot so far

@szeredaiakos Год назад

Extremely informative. Thankyou. Did brush up my functional skills. The key points what I took away: - Systems implementing the functional paradigm offloads the state management to another discrete system. - FP is highly reliant on memory allocation and garbage collection which, TBH, is an avenue for optimization costly in terms of dev time, but very fun - FP works extremely well for LIGHT processing extreme amounts of data - It has high potential for mud-ball, special care for the structure and dependency is far more important than in OOP as well as built in resilience is a must since observability is nonexistent. - Asynchronous systems are mostly limited to pipeline architecture My major grievance with FP is that data structures change all the time. It is a constant of every application, service, you name it, which is in production. In OOP dealing with these changes is usually done my making full use of polymorphism. This goes by with almost no changes in the entire execution pipe from DB to client. Exceptions are services which fully utilize the FP paradigm and the actual implementation endpoints of the changes. For this reason, later on in development I advise steering away from the functional paradigm. The reason why I am watching this because one of our services is having massive complexity and performance issues which after my research it boils down to religious implementation of the paradigm. What I like about functional, is the speed at which one can get a result in building a solution. Relinquishing the sideeffects problem is empowering to say the least but, as I said, this comes at a cost, a cost which, as we found out, remained unmitigated due to "time to market" reasons. Technical debt is nothing new but on the functional side of things it is downright crippling, to the point where entire systems have to be rewritten. Parallel code, for example, (modules witch do multiple things thins in multiple ways via 'if' statement sprinkles) is not a new anti-pattern but in functional is almost impossible to separate. In OOP and high performance systems however, mutability is and should be God. The finite state machine is also a very old idea and there is no way to make that happen in pure FP. But like God, mutability can also be cruel. Vast majority of this .. cruelty can be eliminated via a solid structural pattern on any given project. Which is surprisingly hard to build and maintain especially considering that every single tutorial on any language or framework gets it wrong. This is not an overstatement at all, there is literally 0 fucks given by anyone on the web about translating business requirements to structural design pattern. That being sad, the FP is one of the most essential tools a programmer can hold in it's brain. Tho' OOP was designed as response to the shortcomings of FP more specifically t design a language and a paradigm which a normal human at least has the chance of understanding it there are some problems which are not reduceable or should not be reduced. FP is and should be the default for those problems coupled with a healthy dose of TDD. This is based on my 15 years of experience I mostly played in the OOP sphere. That is enough time to notice that it's not necessarily the paradigm which breaks projects. But its nice to split hairs.

@sammytalks7215 Год назад

those are good points! I think the statement that "FP is highly reliant on memory allocation and garbage collection" is (on-average) a good takeaway a couple of caveats: - fp and polymorphism are not mutually exclusive. If you want, it's possible to do a hybrid of fp and oop (i.e. make objects without mutation). - mutation can make it easier to optimize hardware-level performance, but fp can make tasks easier to parallelize, which is often the limiting factor for building scaling web apps.

@szeredaiakos Год назад

@@sammytalks7215 Well, technically at its core polymorphism goes directly against what it's at heart of fp. So they are effectively mutually excusive. request.sortData() can do anything since it can be overwritten, but in functional sortRequestData() should only do one thing. Objects without mutation are technically functional. At that point they are pointless to be objects. The coupling of data and methods is precisely there because of mutations. Did try hybridization at that level but it never worked out for me. Ended up with 0 benefits so I switched back all of them after one particular time where I had to play with a larger data chunk. On the notion of parallelization, yes, you are correct. Another nifty feature of OOP is the coupling of data and process. You not only split your process but you also need to shard your data. Having it granular at the object level does not help. Tho to be honest I have little experience with this, I deal with asynchronous systems which are naturally parallel where they count.

@sammytalks7215 Год назад

you can still have methods that operate on an object (like request.sortData()), but instead of mutating the object, you can return a new, immutable copy of the object with the data modified. (so it'd look like requestSorted = request.sortData()) it's ok to do this, because if you rely on objects backed by immutable trees, the copy doesn't use that much more memory than the mutable mutate. I think stylisticly, this is underutilized by many people who practition fp, but I've found it to be pretty workable in my own projects maybe oop in fp sounds like a good topic for a video haha

@ashishalex10 Год назад

I never thought a website of as a function, thanks for that analogy

@funmath3835 Год назад

thank you

@giansingh4710 Год назад

I like your videos

@thedude00 Год назад

Isn't insert into ArrayList O(n), and not amortized O(logn)?

@sammytalks7215 Год назад

arraylists are clever - they occasionally double in size when you add elements to them, to reduce the number of times you need to copy the entire array so for example, if you had allocated an array of size 16 on disk, and you tried to add element 17, then it would allocate an array of size _32_ and copy all the elements over. You then wouldn’t need to do another copy until the array doubled in size. I think a lot of implementations are actually O(1) average case, since (1 + 2 + 2^2 … 2^n = 2n+1) but I said logn just to be safe lol

@thedude00 Год назад

@@sammytalks7215 ah, are you using "insert" as a synonym for "append"? I think that's not the usual meaning

@sammytalks7215 Год назад

I see - yeah that’s fair - sorry for the confusion

@thedude00 Год назад

@@sammytalks7215no worries, thanks for answering and for the video! It was truly very informative; I especially appreciate learning about the expected performance of immutable data structures which I use in non-functional-focused languages. If you'd like a video idea: what is the clojure JavaScript and Java interop experience like? Is it an almost-strictly-better alternative to TypeScript and Kotlin? This is important to me; I find that the most important aspect of a language is how much existing code can be reused.

@sammytalks7215 Год назад

that's a good idea :D -- I think the TLDR is that the Java interop experience is very good, and the clojurescript experience overall is kind of questionable

@funmath3835 Год назад

of course it works

@bayrock1337 Год назад

Arguably it's the only paradigm that does.

@KohuGaly 9 месяцев назад

Saying that functional programming is more limiting is not really true. Yes, you are not allowed to do some operations that you can do in imperative. However, it also allows you to do some operations that would be unsound in imperative code, because you can rely that the code you're calling is not allowed to do some operations. It's not more or less limiting than imperative - it's just a different tradeoff. A very appealing tradeoff, might I add, because generally the bigger your codebase gets, the more your code calls other code to do work instead of doing it directly.