https://pastebin.com/1Ud2Uphd
That code fails when the last line doesn't have a line terminator.
You know what makes all code fail.
People making up requirements.
Note the code works if the last line has no newline. It fails when it DOES have a newline as it produces an enumeration of a blank line.
The input file provided is static. I can read it. It does not have a newline on the end of the last line. Therefore the code is bug free and obtains the correct answer.
You are obviously wrong, but ... I guess you don't care?
Which maybe gives a hint as to why functional-style code has a tendency to have fewer bugs: If you avoid dealing manually with indices, you can't have off-by-one indexing errors.
Functional-style code does not have a tendency to have fewer bugs. It's just the sheer amount of code that is put behind the functional-style APIs has been well unit tested. You know what those APIs use under the covers? Indices, arrays and iterators (aka pointer arithmetic).
So, your argument is that because an abstraction is based on something that is prone to bugs, therefore, the abstraction can not abstract away that risk by using one well-tested implementation? Are you sure that that makes sense?
However, as computers, nor humans work in a functionally orientated way it tends towards massively inefficient code, code that is hard to read and repeatedly has to be re-written, results in dozens of different ways to do the same thing. All of which are bad for code quality. IMHO.
You do realize that you are assuming that your personal subjective experience is universal, right? You are, maybe, not thinking in functional terms. Which is fine. That doesn't mean that that is universal among humans.
Now, I have no idea why you think that functional-style code needs to constantly be rewritten, or why you think that there being dozens of ways to do the same thing is somehow unique to functional-style code.
What I do notice, though, is that you found a way to write imperative-style code that's incorrect, and that you didn't even manage to see the bug after I pointed out to you what the bug was.
There is a video on YouTube where a dev sends his python project in for "opimisation". In functionally orientated higher, than high level Python it was written in it ran in something like 15 minutes.
Simply removing all the functional crap, list comprehension and all the high level "convenience methods" and just using plain old lists/arrays and iteration dropped the run time below 2 minutes.
Rewriting it in Rust and it ran in 15 seconds. In pure C and then ASM small gains only where made.
None of which addresses correctness. I didn't claim that functional-style code is the solution to all problems.
But also, isolated execution times of some piece of code is just completely irrelevant. If that code is run once a year in yome batch job, it would be nonsensical to spend any time on optimizing it. If you start buying more servers because that thing is being called all the time and dominates your CPU consumption, then you are just bad at selecting the right tool for the job.
The only people really behind this style of coding are the large enterprises. It is cheaper on aggregate for them to buy 10 servers and 3 cheap developers, than it is to buy 1 server and 3 expensive developers. Servers do not cost $2500 a DAY!)
That's a nonsensical comparison?
What functional languages like Scala and Haskel et. al yield does not come from the syntax. It comes from the strict management of state and it's mutability. The same principles can be applied in Java, C, Python and ASM, without fancy gibberish producing closures (lambda). Though they are exceptionally easy to copy and paste off GPT or Stack Overflow.
I guess it is true that it doesn't come from the syntax, as you don't really need much syntax to have HOF or lambdas!? I mean, the C standard lib has higher-order functions (see qsort()), and GCC even has sort-of closures in C (aka nested functions), and I think clang even supports function literals in C!? It is unfortunate, of course, that it took C some 50 years or so to catch up with Lisp.
Though I guess I am really curious what it is about lambdas that seems to confuse you so much!? Do loop bodies also confuse you? Or is it the concept of functions with lexical scope? Or ... what?