Functional-style programming doesn’t make it any more natural, it just forbids you from doing things any other way. I spend most of my time when dealing with functional-style programming (primarily in XSLT) trying to figure out ways around the constraints imposed by the language rather than actually solving the problem I’m working on.
In XSLT I once copied a chunk of code 8 times, replacing its recursive function calls with its own code, because it was blowing up the stack; and it’s not like I could use mutable variables and skip the recursion, it was literally the only implementation possible. And it had to call itself in multiple places of its own code; it couldn’t be phrased in a tail-recursion friendly fashion. Meaning that for that code, no functional language could have resolved the stack explosion issue. -That’s- functional programming to me; dysfunctional.
[ETA: Apparently there is a pattern which would overcome the tail stack issue, and compilers exist which can take advantage of it, so my statement that “No functional language could have resolved the stack explosion issue” was false.]
no functional language could have resolved the stack explosion issue
A functional language could compile to code that uses references to continuations (functions to call, with parameters) instead of the physical stack. See continuation passing style. (The language wouldn’t need to use continuation passing style itself, the conversion would straightforward for the compiler to do.)
That, to me, falls under “Trying to figure out ways around the constraints imposed by the language.”
I suspect it would have made for even messier code, as well, provided it would have even worked for that particular problem. I was parsing a deliberately and ingeniously obfuscated document, and I was updating particular pieces of information based on information obtained in recursive references which, needless to say, were obfuscated, including false flag references which would get me incorrect information if followed; the falsity couldn’t be determined locally, either, and required complex conditional comparisons to information contained in parent references. Some of the references were cyclical, to boot.
That, to me, falls under “Trying to figure out ways around the constraints imposed by the language.”
Functional languages do not have inherent stack limits. A stack limit is imposed by a particular implementation of the language, and what I described is how a different implementation of the language could have a much larger stack limit, (constrained by total memory rather than memory initially allocated to the physical stack), with no difference in the source code because the compiler can make the transformation to continuation passing style for you.
The point is that this problem you had with XSLT does not generalize to all possible functional languages the way you think it does.
The parts of XSLT that cause me problems are the functional programming parts; not every problem is well-suited to functional programming, especially when it comes to, as in that case, parsing complex interconnected documents to find information (ETA: Particularly when that information isn’t guaranteed to be in any one particular place, and you have to conditionally check multiple locations, each of which itself may be referenced in one of multiple locations that have to be conditionally checked).
Functional programming takes a mathematical approach to problem-solving. There are some problems it is exceedingly elegant at solving. The issue is that it isn’t any more elegant than a well-written alternative in another language, and it makes that elegance mandatory, which causes severe problems when you’re dealing with an inelegant problem.
I’m not hired to solve elegant problems. I’m hired to solve the problems that companies have spent 20 million dollars to fail to solve.
The parts of XSLT that cause me problems are the functional programming parts; not every problem is well-suited to functional programming, especially when it comes to, as in that case, parsing complex interconnected documents to find information
So your example of how ‘functional programming fails’ is to use a vague personal anecdote about possibly the worst ‘functional’ language in the world, many versions of which don’t even have higher-order functions which is a basic key functional feature dating back literally to the 1960s, and of which people have published research papers just to prove it is Turing-complete?
Do you understand why no one is going to find your claim that “functional programming sucks because I once wrote a bad program in XSLT” even remotely convincing? Even if you do boast about yourself that
I’m not hired to solve elegant problems. I’m hired to solve the problems that companies have spent 20 million dollars to fail to solve.
The problem was done under an NDA, so I can’t get too specific. The shortest explanation, however, is “Parsing obfuscated document.” It was a problem which was intentionally created by somebody to be as difficult as possible to solve in a programming language.
Functional programming doesn’t suck because of that problem; it would have been difficult in ANY language. Functional programming sucks because it deliberately prevents you from doing things. As a rule, any time anybody says “You shouldn’t be doing that,” it is because they lack imagination as to why you would need to do that. Functional programming is designed around the principle that “You shouldn’t be doing that.”
Functional-style programming doesn’t make it any more natural, it just forbids you from doing things any other way. I spend most of my time when dealing with functional-style programming (primarily in XSLT) trying to figure out ways around the constraints imposed by the language rather than actually solving the problem I’m working on.
In XSLT I once copied a chunk of code 8 times, replacing its recursive function calls with its own code, because it was blowing up the stack; and it’s not like I could use mutable variables and skip the recursion, it was literally the only implementation possible. And it had to call itself in multiple places of its own code; it couldn’t be phrased in a tail-recursion friendly fashion. Meaning that for that code, no functional language could have resolved the stack explosion issue. -That’s- functional programming to me; dysfunctional.
[ETA: Apparently there is a pattern which would overcome the tail stack issue, and compilers exist which can take advantage of it, so my statement that “No functional language could have resolved the stack explosion issue” was false.]
A functional language could compile to code that uses references to continuations (functions to call, with parameters) instead of the physical stack. See continuation passing style. (The language wouldn’t need to use continuation passing style itself, the conversion would straightforward for the compiler to do.)
That, to me, falls under “Trying to figure out ways around the constraints imposed by the language.”
I suspect it would have made for even messier code, as well, provided it would have even worked for that particular problem. I was parsing a deliberately and ingeniously obfuscated document, and I was updating particular pieces of information based on information obtained in recursive references which, needless to say, were obfuscated, including false flag references which would get me incorrect information if followed; the falsity couldn’t be determined locally, either, and required complex conditional comparisons to information contained in parent references. Some of the references were cyclical, to boot.
Functional languages do not have inherent stack limits. A stack limit is imposed by a particular implementation of the language, and what I described is how a different implementation of the language could have a much larger stack limit, (constrained by total memory rather than memory initially allocated to the physical stack), with no difference in the source code because the compiler can make the transformation to continuation passing style for you.
The point is that this problem you had with XSLT does not generalize to all possible functional languages the way you think it does.
Hm. Granted.
In fairness, I think it does generalize to most implementations.
I think I see the problem here.
Perlis comes to mind:
The parts of XSLT that cause me problems are the functional programming parts; not every problem is well-suited to functional programming, especially when it comes to, as in that case, parsing complex interconnected documents to find information (ETA: Particularly when that information isn’t guaranteed to be in any one particular place, and you have to conditionally check multiple locations, each of which itself may be referenced in one of multiple locations that have to be conditionally checked).
Functional programming takes a mathematical approach to problem-solving. There are some problems it is exceedingly elegant at solving. The issue is that it isn’t any more elegant than a well-written alternative in another language, and it makes that elegance mandatory, which causes severe problems when you’re dealing with an inelegant problem.
I’m not hired to solve elegant problems. I’m hired to solve the problems that companies have spent 20 million dollars to fail to solve.
So your example of how ‘functional programming fails’ is to use a vague personal anecdote about possibly the worst ‘functional’ language in the world, many versions of which don’t even have higher-order functions which is a basic key functional feature dating back literally to the 1960s, and of which people have published research papers just to prove it is Turing-complete?
Do you understand why no one is going to find your claim that “functional programming sucks because I once wrote a bad program in XSLT” even remotely convincing? Even if you do boast about yourself that
The problem was done under an NDA, so I can’t get too specific. The shortest explanation, however, is “Parsing obfuscated document.” It was a problem which was intentionally created by somebody to be as difficult as possible to solve in a programming language.
Functional programming doesn’t suck because of that problem; it would have been difficult in ANY language. Functional programming sucks because it deliberately prevents you from doing things. As a rule, any time anybody says “You shouldn’t be doing that,” it is because they lack imagination as to why you would need to do that. Functional programming is designed around the principle that “You shouldn’t be doing that.”