Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Programming Lessons Conclusion

jerf.org

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Functional Programming Lessons Conclusion

#41

Post by Tainnor »

Joker_vD wrote: post #39
chowells wrote: post #17

Earlier quoted context omitted.

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

Nobody is forcing you to use Haskell.

Re: Functional Programming Lessons Conclusion

#42

Post by Tainnor »

ninetyninenine wrote: post #38
Tainnor wrote: post #37

Earlier quoted context omitted.

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

> In fact I'm willing to bet, if you lay out your experience you'll see it's almost entirely as I said.

I don't know how to respond to something like that. You can trust me that I know and understand my own experience better than you do.

Re: Functional Programming Lessons Conclusion

#43

Post by ninetyninenine »

Tainnor wrote: post #42
ninetyninenine wrote: post #38

Earlier quoted context omitted.

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…

> In fact I'm willing to bet, if you lay out your experience you'll see it's almost entirely as I said. I don't know how to respond to something like that. You can trust me that I know and understand my own experience better than you do.

Easy. No one knows this but In science and therefore reality proof is impossible. Proof is the domain of mathematics and logic.

But disproof is possible in reality. It can be done by a single counter example.

So if I’m wrong about your experience. Why don’t you lay out a single example in web development in your experience where what I said is utterly incorrect because I literally cannot even imagine a counter example.

One counter example is all it takes to disprove my “bet”. Even better if the example is extremely common. But this is up to you to you decide if you want to debate this. I’m certainly willing to tell you about my entire experience and all I’m asking for is a single counter example from you.

Re: Functional Programming Lessons Conclusion

#44

Post by Tainnor »

ninetyninenine wrote: post #43
Tainnor wrote: post #42

Earlier quoted context omitted.

> In fact I'm willing to bet, if you lay out your experience you'll see it's almost entirely as I said. I don't know how to respond to something like that. You can trust me that I know and understand my own experience better than you do.

Easy. No one knows this but In science and therefore reality proof is impossible. Proof is the domain of mathematics and logic. But disproof is possible in reality. It can be done by a single counter example. So if I’m wrong about your experience. Why don’t you lay out a single example in web development in your experience where what I said is utterly incorrect because I literally cannot even imagine a counter exampl…

* Take a complicated tree structure representing a document management system and transform it into some different tree structure, e.g. by filtering out elements or fields due to missing permissions, or by rewriting it in the way that the elasticsearch index expects it, or a bunch of other reasons.

* Generate a TOC of an HTML document by parsing all the header elements. More generally, anything that's related to parsing (something which I've had to do several times).

* Run a complex (> 50 LOC) validation on some user input.

* Generate a word document or PDF. Conversely, parse a word document or PDF.

* Financial computations, such as calculating totals of an order made up of multiple line items with discounts, taxes, additional charges, etc.

(I'm purposely leaving out more non-standard applications, such as pre-LLM chatbots, or an entire mathematical problem solver that doesn't even use a database, but just so you know, they exist too.)

There's also the much more immediate counterpoint that it's of course possible to write web applications in Haskell (or OCaml, Scala, ...), otherwise all these frameworks wouldn't exist.

Re: Functional Programming Lessons Conclusion

#45

Post by ninetyninenine »

Tainnor wrote: post #44
ninetyninenine wrote: post #43

Earlier quoted context omitted.

Easy. No one knows this but In science and therefore reality proof is impossible. Proof is the domain of mathematics and logic. But disproof is possible in reality. It can be done by a single counter example. So if I’m wrong about your experience. Why don’t you lay out a single example in web development in your experience where what I said is utterly incorrect because I literally cannot even imagine a counter exampl…

* Take a complicated tree structure representing a document management system and transform it into some different tree structure, e.g. by filtering out elements or fields due to missing permissions, or by rewriting it in the way that the elasticsearch index expects it, or a bunch of other reasons. * Generate a TOC of an HTML document by parsing all the header elements. More generally, anything that's related to pars…

First one looks like meta programming. IO. You are programming something else.

Toc programming seems trivial. I put a loop here instead of a map and my html parsing library does all the work. Parsing in general is usually handled by a library. Programmers don’t do much work here tbh. If you’re writing your own parser combinators.. well that’s rare.

Validation again that falls in the authentication and security layer. This lives in the 20 percent.

Word to pdf sounds is a legit use but also it lives in the 20 percent.

Financial computations also legit but it lives in the 20 percent. The more line items you have the more you have to either shift it to the database to compute or some number crunching async job. That’s IO and compute.

Chatbots are high IO.

Math solver works but honestly I went through my entire career only writing one of those for fun. Non standard but these are 20 percent.

> There's also the much more immediate counterpoint that it's of course possible to write web applications in Haskell (or OCaml, Scala, ...), otherwise all these frameworks wouldn't exist.

You’re talking about web frameworks right? The kind that lives on top of servers?

The modern day method of coding these servers is to be non blocking as much as possible. Meaning not much room to do functional calculations as the more calculations you do the more you block a thread. You are forwarding the tasks via IO to task runners or the database whether or not you use a framework from Haskell or scala or whatnot.

I still can’t really agree with you. Like writing code to convert a tree or word to pdf or parsing is just rare enough to live in the 20 percent. Most of the time you are writing code that writes query code.

Agree to disagree. We can end it here if you want.

Re: Functional Programming Lessons Conclusion

#46

Post by Tainnor »

ninetyninenine wrote: post #45
Tainnor wrote: post #44

Earlier quoted context omitted.

* Take a complicated tree structure representing a document management system and transform it into some different tree structure, e.g. by filtering out elements or fields due to missing permissions, or by rewriting it in the way that the elasticsearch index expects it, or a bunch of other reasons. * Generate a TOC of an HTML document by parsing all the header elements. More generally, anything that's related to pars…

First one looks like meta programming. IO. You are programming something else. Toc programming seems trivial. I put a loop here instead of a map and my html parsing library does all the work. Parsing in general is usually handled by a library. Programmers don’t do much work here tbh. If you’re writing your own parser combinators.. well that’s rare. Validation again that falls in the authentication and security layer.…

You started out by saying 99% of web code is IO, then casually dropped down to 70-80%, as if that was the same thing. 20-30% of a huge codebase is still a significant amount.

I've never said IO is irrelevant to web applications. But that in my experience, those 20-30% or whatever can be important, complex and time intensive (the Word generation was actually one od the most time consuming parts of the last application I worked on) enough that fencing them off from the side effecting code in some way can pay off (one way to do this without going fully PFP is outlined here: https://www.jerf.org/iri/post/2025/fp_lessons_purity/#fp-pur...).

> First one looks like meta programming. IO. You are programming something else.

I don't understand what you're saying. I was working on a document management system whose contents were stored in tree structures. These structures routinely had to be transformed into other structures. That's a very algorithmic task where the IO can be fenced off very easily (and should be fenced off if only for the sake of easier unit testing). This was literally one of the most common things happening in the codebase.

> Chatbots are high IO.

in the sense that every useful program has IO. Otherwise, there's a whole bunch of transformations and intent recognition and skill dispatch and what not that happens between the request and the response, and that can happen entirely in memory on one machine (it can also be offloaded wholly or in part to an external service like Amazon Lex, it depends on the use case, but even in the case where we used Lex we ran a bunch of manual transforms on the output for postprocessing).

> The modern day method of coding these servers is to be non blocking as much as possible.

Recent developments (e.g. virtual threads coming to Java) seem to indicate otherwise. Blocking code and non-blocking code are both valid for different types of scenarios. And offloading tasks asynchronously to a task runner doesn't mean that the code running those tasks doesn't have to be written.

---

I really do think we've just worked on very different types of applications, and I just reiterate my point from above (and from the blogpost): There are enough use cases where clearly fencing off IO from algorithmic code pays off. If it doesn't for your use case, then don't do it.

Re: Functional Programming Lessons Conclusion

#47

Post by chowells »

Tainnor wrote: post #41
Joker_vD wrote: post #39

Earlier quoted context omitted.

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

Nobody is forcing you to use Haskell.

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