3 ms·
web development today is literally just massive massive mutation operations on databases. Functional programming can't stop it, it just sort of puts a fence ar
by ninetyninenine 2y ago
web development today is literally just massive massive mutation operations on databases.
Functional programming can't stop it, it just sort of puts a fence around it. The fence makes sense if it's just 10% of your program that you want to fence off. But the database is literally the core of our application then it's like putting a fence around 90% of the house and you have 10% of pure functional programming.
Most operations are located at the database level. That's where the most bugs occur and that's where most operations occur. You can't really make that functional and pure.
This high level stuff is actually wrong. At the highest level web apps are NOT functional.
I get where he's coming from but he missed the point. Why do functional paradigms fail or not matter so much at the micro level? Because web applications are PRIMARILY not functional by nature. That's why the stuff doesn't matter. You're writing and changing for loops into recursion/maps in the 10% of your pure code that's fenced off from the 90% core of the application.
You want to make functional patterns that are applicable at the high level? You need to change the nature of reality to do that. Make it so we don't need to mutate a database ever and create a DSL around that is functional. SQL is not really functional. Barring that you can keep a mutating database but create a DSL around it that hides the mutation.
- Tainnor 2y agoThere must be something wrong in the way FP is taught if the takeaway that people have is that it prevents or is somehow opposed to mutation. On the one hand you have bunch of FP languages that don't care in the least bit about "purity" (i.e. being side-effect free) or are more pragmatic around it, such as various LISPs, OCaml, Scala or even parts of the JS ecosystem. And on the other hand, there's a lot of research and discussion in e.g. the Haskell community about how to properly deal with side effects. The idea here is not that side effects are bad, but that we want to know where they happen and combine them safely.
- Joker_vD 2y ago> The idea here is not that side effects are bad, but that we want to know where they happen and combine them safely. Yeah, the idea is not that people gathering together in groups more than two and/or past the 21:00 is bad, but that we want to know where it happens and ensure safety for all. Now, your papers, please or we'll apply the type checker (we'll apply it to y'all anyhow, of course, but we'd like you to cooperate with the inference process).
- chowells 2y agoI don't understand why people get so angry when a compiler points out that their code is broken. Is it better if runs and does the wrong thing instead?
- Joker_vD 2y agoI am fine with compiler pointing out broken code. I am not fine with people saying "The code with side effects must be segregated from the pure code, with the typechecker in place to maintain this separation, and we must also keep CONSTANT VIGIL against introducing any more effectful code than strictly necessary — but of course we don't think that side effects are bad, haha. Why, some of my best friends are side effects, I am not a functional purist" or something like that.
- Tainnor 2y agoNobody is forcing you to use Haskell.
- chowells 2y agoHell, you can write imperative spaghetti in Haskell if you want. I've done it. People will just keep suggesting you fix it, because it's so much more obvious how bad it is when you can so quickly and easily use the type system to guide the process of fixing it.
- ninetyninenine 2y agoNo you missed the point. I completely get the meaning of segregating IO/mutation away from pure logic. And my point is, what is the purpose of all of this is 90% of what your app does is mutation and side effects? Functional shell, imperative core indeed, but the shell is literally just thin layer of skin. The imperative core is a massive black hole. Functional programming can't save you from black hole.
- Tainnor 2y agoObviously the answer to "this doesn't solve my problems" is "don't use it then". If your problem domain literally is nothing but API calls and DB updates, then you may not benefit from this. OTOH, in my experience a lot of people underestimate how much pure business logic exists (or can be extracted) in many applications. In apps I've worked on I've found a lot of value in isolating these parts more cleanly. The blogbook series by the author of TFA (linked further upthread) goes into some detail about how to do that even without going fully down the "pure functional programming" rabbithole.
- ninetyninenine 2y ago>Obviously the answer to "this doesn't solve my problems" is "don't use it then". If your problem domain literally is nothing but API calls and DB updates, then you may not benefit from this. This is like 99% of web development today. And web development is like 99% of development. It's all very IO heavy and mutation heavy. You can't run from it. It's why FP is mostly ineffective on the smaller scale because you're already walled off from doing anything that matters in web. Your server is stateless anyway so anything you do in this arena doesn't even matter.
- Tainnor 2y ago> This is like 99% of web development today. You've claimed this several times now and I fundamentally disagree. In my 11 years of experience working across some 7 companies, web development has always been more than just 99% side effects. Obviously your experiences may be different, but this generalisation is silly.
- meltyness 2y agoWould you consider TLA+ functional? It sounds like the tension you're describing might be how most distributed consensus protocols are implemented as imperative code, and part of the Raft excursion involved writing a TLA+ proof of the protocol. https://github.com/ongardie/raft.tla https://github.com/ongardie/raft.tla