4 ms·

I'm more referring to a type of technical debt. Of course if your product manager wants you to refactor your web app into a PS5 video game nothing can save you.

I'm more referring to a type of technical debt. Of course if your product manager wants you to refactor your web app into a PS5 video game nothing can save you. I wouldn't call the fact that your code wasn't prepared to be refactored into a PS5 video game "technical debt." As most software engineers know, there's tons of examples where the main issue was mostly organizational issues preventing the programmer from simply removing/replacing/moving logic to fulfill the main objective. This is the "technical debt" I'm talking about. In that case if all your logic was combinators (and thus dependency free) then all you need to do is move things around, pull things out and/or put things in like lego blocks. The main reason why people can't move code around like lego blocks is because most logic contains dependencies or is tied to state. Combinators are never tied to state or anything and thus if all your code was made up of combinators you would have no issues in moving logic around. The problem of organizational technical debt is solved with combinators. If you take it a step further and use the point free style, you are eliminating state all together further protecting your program from ever being dependent on state. The logic is pretty sound though most people can't put the benefits of FP into purely logical terms. They only talk about why they like it qualitatively without ever pinpointing why it's truly better for design/organizational issues.

yowlingcat 6y ago
> If you take it a step further and use the point free style, you are eliminating state all together further protecting your program from ever being dependent on state. The problem is that the part of your program which processes state...is generally the useful part. This is part of the reason why I eventually came back down to earth after a couple of years of FP zealotry in my early career. I realized that it makes the easy parts easier. And there is something to be said about that -- there are a lot of codebases where just doing the table stakes refactoring that minimizes the surface area of stateful code does a ton to improve the codebase. But in my experience, that's only table stakes. It doesn't make the hard parts (such as unfucking a broken data model and code + existing prod data which depends on those implicit assumptions) any easier. So it's a tool of limited use for most of the thorny issues I've come across in my career, across startups and BigCos.
- Geminidog 6y ago
  You cannot write a program without state. I am obviously not talking about eliminating all state. I am talking about eliminating state from sections of code that don’t need it. Generally for web development the only required state is caching and the database.I am not saying that you eliminate this. Additionally shortcuts can be taken. Graph algorithms tend to be easier with mutation. > But in my experience, that's only table stakes. It doesn't make the hard parts (such as unfucking a broken data model and code + existing prod data which depends on those implicit assumptions) any easier. So it's a tool of limited use for most of the thorny issues I've come across in my career, across startups and BigCos. Well your talking in terms of fuzzy feelings and experience. I am talking about a hard logical rule. A mathematical rule. If you want to eliminate all technical debt that originates from organizational issues then where you want that technical debt eliminated you simply need to have all your code be combinators in that location. This occurs because combinators have no dependencies and therefore can alway be moved shifted decomposed and reused. This is a logical statement different from some random anecdote from experience. Also this isn’t just fp. A combinator is different from a pure function. Look you can’t eliminate IO and you can’t eliminate state in practice. So the formal logic I stated above cannot effectively be applied to your code to completely eliminate this form of debt. It is however a logical statement and holds as a truth. Thus if you follow it as much as possible you will see that what ends up happening is a segregation and minimization of state along with a minimization of the form of technical debt I described. (Which of course cannot apply to the stateful part of your program) Most of web development is a similar pattern that was developed independently from the above philosophy but coincidentally arrived at the same conclusion. Web applications are generally stateless with state segregated away to databases and caches. You will find that generally the technical debt lives in this state more then it lives in the web app, but if you follow the combinator rule, you can eliminate organizational technical debt from a good portion of your web app. The purpose of this post is to elucidate a logical rule and pinpoint the hard origins of technical debt arising from organizational issues rather then walk around and talk about fuzzy feelings and intuitions that arise from experience. Of course state and io cannot be removed from your program. What this means logically is that organizational technical debt can also never be fully removed, but it can be segregated. Better to understand this concept as a science rather then some fuzzy art that comes from experience. The industry often repeats history because of lack of formal understanding. It’s very hard to optimize something without formal understanding. You cannot prove one pattern is better than another with just fuzzy experience. Hence the reason why the industry jumps from pattern to pattern in an endless flat circle.

yowlingcat 6y ago

> If you take it a step further and use the point free style, you are eliminating state all together further protecting your program from ever being dependent on state. The problem is that the part of your program which processes state...is generally the useful part. This is part of the reason why I eventually came back down to earth after a couple of years of FP zealotry in my early career. I realized that it makes the easy parts easier. And there is something to be said about that -- there are a lot of codebases where just doing the table stakes refactoring that minimizes the surface area of stateful code does a ton to improve the codebase. But in my experience, that's only table stakes. It doesn't make the hard parts (such as unfucking a broken data model and code + existing prod data which depends on those implicit assumptions) any easier. So it's a tool of limited use for most of the thorny issues I've come across in my career, across startups and BigCos.

Geminidog 6y ago
You cannot write a program without state. I am obviously not talking about eliminating all state. I am talking about eliminating state from sections of code that don’t need it. Generally for web development the only required state is caching and the database.I am not saying that you eliminate this. Additionally shortcuts can be taken. Graph algorithms tend to be easier with mutation. > But in my experience, that's only table stakes. It doesn't make the hard parts (such as unfucking a broken data model and code + existing prod data which depends on those implicit assumptions) any easier. So it's a tool of limited use for most of the thorny issues I've come across in my career, across startups and BigCos. Well your talking in terms of fuzzy feelings and experience. I am talking about a hard logical rule. A mathematical rule. If you want to eliminate all technical debt that originates from organizational issues then where you want that technical debt eliminated you simply need to have all your code be combinators in that location. This occurs because combinators have no dependencies and therefore can alway be moved shifted decomposed and reused. This is a logical statement different from some random anecdote from experience. Also this isn’t just fp. A combinator is different from a pure function. Look you can’t eliminate IO and you can’t eliminate state in practice. So the formal logic I stated above cannot effectively be applied to your code to completely eliminate this form of debt. It is however a logical statement and holds as a truth. Thus if you follow it as much as possible you will see that what ends up happening is a segregation and minimization of state along with a minimization of the form of technical debt I described. (Which of course cannot apply to the stateful part of your program) Most of web development is a similar pattern that was developed independently from the above philosophy but coincidentally arrived at the same conclusion. Web applications are generally stateless with state segregated away to databases and caches. You will find that generally the technical debt lives in this state more then it lives in the web app, but if you follow the combinator rule, you can eliminate organizational technical debt from a good portion of your web app. The purpose of this post is to elucidate a logical rule and pinpoint the hard origins of technical debt arising from organizational issues rather then walk around and talk about fuzzy feelings and intuitions that arise from experience. Of course state and io cannot be removed from your program. What this means logically is that organizational technical debt can also never be fully removed, but it can be segregated. Better to understand this concept as a science rather then some fuzzy art that comes from experience. The industry often repeats history because of lack of formal understanding. It’s very hard to optimize something without formal understanding. You cannot prove one pattern is better than another with just fuzzy experience. Hence the reason why the industry jumps from pattern to pattern in an endless flat circle.