[dnautics]

I haven't been in the developer industry for too long, but excepting the haskell community, I would say that the way CS tends to treat math is as guardrails, as in, "you can't do that because of the halting theorem". "you might be butting up against computational complexity if you try doing it this way". "reconstruction of this data shard is impossible because you don't have enough points to determine the equation".

In the FP communities, I do sometimes see people overoptimize for TCO. Your datastructure is never going to be more than 10-100 deep. Don't worry about it. Just write the most legible recursive algorithm, not the most performant.

[gowld]

Hmm? My queues and stacks are >100 deep.

My graph traversals are >100 deep.

My recursive calculations are >100deep

Dynamic programming wouldn't be relevant if non-tail recursion was always good enough in practice.

[dnautics]

I was obviously referring to a different you. Yes, there are (many) cases when tco is 100% a great idea.

[opportune]

The way development works, 95+%, yes math is simply guardrails. But it definitely isn’t always. I would actually say that we as the developer community have done a remarkable job of abstracting the hard math away from needing to be thought of by the average developer by bundling the math so invisibly into libraries.

I highly disagree regarding algorithms. No you don’t need to use the most modern Matrix multiplication algorithm ever but there are lots of situations (at least at large companies or people working with large amounts of data) where you do need to be aware of computational complexity.

[tathougies]

> Your datastructure is never going to be more than 10-100 deep. Don't worry about it. Just write the most legible recursive algorithm, not the most performant.

What? Try computing the 1000th fibonacci number.

[chopin]

I agree as it is important to know your boundaries. But I also like the GP prefer legible over performant code whenever it is obvious that I am not going to need more performance. In almost all cases I encountered the necessity to optimize code the reason was I/O bound. I don't recall any instance of algorithmic performance being a problem.

[tathougies]

Tco has little to do with timing performance and all to do with keeping code legible in functional languages.

[dnautics]

In FP that implements actor model, for example, you will be in a world of hurt if you don't TCO your actor - has nothing at all to do with legibility.