[nightski]

It's not like you avoid the problem by going to languages with less foundation in math. You just tend to end up with leaky abstractions (which break the laws found in this math disdained so much) and hard to maintain code (technical debt). It might be worth the trade off some times but we do waste a lot of time on this. Probably more than it would take to learn these concepts.

[kangdolit]

I've seen just as many FP projects strain under technical debt as I have OO projects. Technical debt is a product of the developers, not the language. And FP developers are just as imperfect as OO developers.

[nightski]

We have not invented a language that is immune to technical debt or leaky abstractions. Haskell's type system is not rich enough to let us impose all the constraints implied by the mathematics.

However it is a significant improvement on allowing one to express the constraints in the type system preventing large classes of bugs and towards providing proper abstractions.

Let's not throw the baby out with the bathwater. No one is claiming FP developers are "better" than OO developers. In fact why would anyone ever classify themselves as one or the other? Instead we should use the best tools for the job.

[dkarl]

There is a kind of technical "debt" imposed when you can't express the simplest solution in a straightforward way in the language you're using. I put "debt" in quotes because in a strict sense it isn't really debt, because you can't escape the payments by paying off the principle. It's more like a tax that drains away a portion of your effort every time you touch the code.

[runT1ME]

I find this claim dubious. I have been in the industry a long time and I have found the opposite.

[ddito]

Could you elaborate?

[runT1ME]

I've worked on teams of various sizes and skills writing OO applications and trying to use inheritance and OO to get code reuse is always a nightmare. I currently work on large project with hundreds of Scala engineers of various abilities, and structuring our code in functional ways has bought us a ton of reuse and prevented a lot of technical debt.

We primarily write libraries, and our 'applications' are more or less throw away code because of how small they end up being (because they can leverage many of our libraries). Testing is easier in functional land (for various reasons), which means regressions are much harder to introduce, which means refactoring can happen faster, which means less technical debt.