Live data from Hacker News

Functional Programming Lessons Conclusion

jerf.org

31–40 of 48 posts

Re: Functional Programming Lessons Conclusion

#31
post #7
post #3

I've always thought that there should be mutability of objects within the function that created them, but immutability once the object is returned. Ultimately one of the major goals of immutability is isolation of side effects.

How does this work out for functions in the middle of the call stack? Can the objects a function creates be mutated by functions they call? Phrased differently, can functions modify their input parameters? If a function returns one of their input parameters (modified or not), does that mean the calling function can no longer mutate it? Maybe I'm discarding this too readily, but I don't think this idea of "local mutab…

I have to say I don’t understand your point! The parents comment is both clear and a reasonable, common approach of programming

> Can the objects a function creates be mutated by functions they call?

No

> can functions modify their input parameters?

No

> If a function returns one of their input parameters (modified or not), does that mean the calling function can no longer mutate it?

No. Because the called function isn’t allowed to mutate its inputs, there’s no problem for the caller to mutate it. It’s irrelevant whether the input was also an output of the called function as it cannot mutate it anyway.

I suppose you can get into race conditions between caller and callee if your language provides asynchronicity and no further immutability guarantees. Still, you eliminated a whole lot of potential bugs

Re: Functional Programming Lessons Conclusion

#32

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

It so happens that this was the topic of one of the posts in this series: https://jerf.org/iri/post/2025/fp_lessons_purity/#purity-is-...

I'm assuming from your post you haven't come from there, and we just coincidentally picked a similar example...

Re: Functional Programming Lessons Conclusion

#33

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

The author addresses this nicely in an earlier part of the blog book: https://jerf.org/iri/post/2025/fp_lessons_purity/

Re: Functional Programming Lessons Conclusion

#34

I mostly agree with the sentiments in this article. I was once an extremely zealous FP acolyte but eventually I realized that there are a few lessons worth taking from FP and applying to more conventional programming: 1. Pure functions are great to use when you have the opportunity. 2. Recursion works great for certain problems and with pure functions. 3. Higher order functions can be a useful shorthand (but please o…

> Otherwise, I think simple, procedural programming is generally a better default paradigm.

I think this is almost the opposite conclusion from the one TFA (and in particular the longer form article linked elsewhere here), which is more like: most standard imperative programming is bad and standard (pure) FP is at least slightly better, but people generally don't draw the right conclusions about how to apply FP lessons to imperative languages.

Re: Functional Programming Lessons Conclusion

#35

> I consider [having a big benefit at 100% vs an 80/20 rule] a characteristic of type systems in general; a type system that you can rely on is vastly more useful than a type system you can almost rely on, and it doesn’t take much “almost” to greatly diminish the utility of a given type system. This! This is why I don't particularly care for gradual typing in languages like Python. It's a lot of extra overhead but yo…

> you still can't really rely on it for much

And yet, type annotations in Python are a tremendous improvement and they catch a lot of bugs before they ever appear. Even if I could rely on the type system for nothing it would still catch the bugs that it catches. In fact, there are places where I rely on the type system because I know it does a good job: pure functions on immutable data. And this leads to a secondary benefit: because the type checker is so good at finding errors in pure functions on immutable data, you end up pushing more of your code into those functions.

Re: Functional Programming Lessons Conclusion

#36
post #21

Earlier quoted context omitted.

No 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.

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. 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 blog…

>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.

Re: Functional Programming Lessons Conclusion

#37
post #21

Earlier quoted context omitted.

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. 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 blog…

>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 a…

> 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.

Re: Functional Programming Lessons Conclusion

#38
post #37

Earlier quoted context omitted.

>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 a…

> 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.

My 15 years of experience web development, gaming, embedded systems, and High performance computation has always been 99% side effects for web development exclusively. 99 is an exaggeration but it is not far off. For web it's more like 70 to 80. My point is, it's the overwhelming majority and anyone who is smart and experienced would know this.

There are few places where functional can really be the entire stack and unfortunately those in those places the technological ecosystem surrounding those areas are just not well equipped for FP for historical reasons. For example CUDA in HPC or AI. It's a very functional process of inputs and outputs. Or gaming, which is also very CPU and graphic intensive. Both are great candidates for FP, but the ecosystem surrounding them is focused on C++.

Web is the opposite. It's literally a style of meta programming. Your web server is stateless. It mostly just does authentication and functions as a thin security and routing layer. You are creating a program that takes a route path and translates it into ANOTHER high level language that's used against a database and that's web in a nutshell. That database is doing most of the work in your system. That is the main thing you are programming. So you write server programs that write programs for databases and those servers spend 20% of their time constructing strings in the query language and 80% of the time waiting for the query to complete. Your database is doing all the computation and the server just waits on it.

Why else do you think we don't use rust or C++ for servers? Why can we use a slow ass language like python to do server work? Because the database is the one doing all the work and the servers are just waiting.

If you're going purely stateless with no db, the only thing I can think of in web is chat. But then chat is very IO based which is also not suited for FP. I guess Big data number crunching streams can be thought of as "functional" but those things don't really make up the majority of web either. Maybe video streaming? I feel decoding videos is very library based to be honest.

>Obviously your experiences may be different, but this generalization is silly.

No the only thing silly here is your opinion. I doubt our experiences are that different. In fact I'm willing to bet, if you lay out your experience you'll see it's almost entirely as I said. Servers are meta programmers weaving code in a query language that is forwarding computations to databases which are inherently mutating and IO by definition. All your servers do is just wait for external databases to finish and databases are the engines that drive the web. Databases are mutating IO freaks of nature which makes them not amenable to FP and as a consequence most of web is not amenable to FP either.

You can have any constellation of micro service architecture it doesn't matter. If you forward a call to a server, and that server forwards a call to another server and all those servers are in the end waiting on something that does the actual computations. Usually a database.

I know this because I've worked on things where functional programming is almost 99% applicable even on the smallest scales. Basically if you're programming the computation itself. Intensive high CPU, and high GPU computations which is more rare in web. You'll see for these applications most of your code is a giant composition of pure functions. It becomes so modular that it's almost like legos if you try to follow the FP paradigm in this arena. It just sucks that it's mostly C++, though rust is making big moves in this area.

You'll basically never encounter HPC in web. But you would know this if you had the experience you claim to have. And you would know that at the macro scale, web is not functional... It's imperative and mutation based.

Re: Functional Programming Lessons Conclusion

#39

Earlier quoted context omitted.

> 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 coop…

I 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?

I 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.
Post reply on HN