5 ms·

I spent a large amount of personal time becoming an intermediate Haskell developer from 2009-2015, culminating in landing a job doing exclusively functional pro

by mlthoughts2018 8y ago

I spent a large amount of personal time becoming an intermediate Haskell developer from 2009-2015, culminating in landing a job doing exclusively functional programming for an analytics team in a large company. My experience made me give up on Haskell & functional programming entirel, despite my feeling that the principles of functional programming are often “better” than object orientation and other paradigms. The only language-specific thing that turned me off of Haskell in a significant way was that so many important concepts in Haskell are implemented via pragmas that extend the language and either enforce syntax restructions, enable totally new (and often esoteric) syntax, or change the meaning of existing syntax. This is really painful and makes you generally avoid great mew features and artificially limit yourself to more basic designs because of the learning curve and how committed to one siloed set of patterns you can become. It reminds me of Dennis’s coffee shop idea in 30 Rock: Dennis: One word. Coffee. One problem. Where do you get it? Liz: Anywhere, you get it anywhere. Dennis: Wrong. You get it at my coffee vending machine. in the basement at K-mart. You just go downstairs. You get the key from David. And boom, you plug-in the machine. ^^ that’s what it feels like reading Haskell tutorials when all you want to do is multiple dispatch or heterogeneously type some built-in container, simple things in so many languages. This alone wasn’t what put me off though. The real problem is sociological. Most companies hardwire a feedback loop between development teams and product or business managers that teaches developers they will be rewarded for their ability to unsafely hack things into a Jenga tower of system components for the sake of rapidly addressing ad hoc business questions even when, perhaps especially when, nobody has the slightest idea if answering the ad hoc business request is likely to be worth the additional instability the hacks will put into the Jenga tower. This is very nearly philosophically at odds with the spirit of functional programming, from a first principles level, which means even if you eke out a platform capable of dealing with this in a functional paradigm, youknow for sure that the business willnot see your work as valuable, and safety guarantees, correctness proofs, automatic parallelization, etc., will often notbe rewarded, meanwhile just hacking stuff into some C++ or Python codebase that “just works” will be rewarded. It’s not a satisfying phenomenon, but it convinced me that it’s not worth investing any more of my time into functional programming.

mlevental 8y ago
>The only language-specific thing that turned me off of Haskell in a significant way was that so many important concepts in Haskell are implemented via pragmas that extend the language and either enforce syntax restructions, enable totally new (and often esoteric) syntax, or change the meaning of existing syntax. god the ghc extensions. good luck figuring out why something is happening that you don't expect.
- nightski 8y ago
  What? They are opt in per module unless you manually enable them globally. Anyways the entire reason Haskell was created was to be a base for future language research. The extension system was largely the point.
galaxyLogic 8y ago
Could I summarize your objection to Functional Programming in business setting as the fact that Object Orientation makes it simpler to model the businesses and thus easier to solve their problems? If you think about a Function it does just one thing. But real world "agents" that run a business do many things. An OO-class has many methods, not just a single input and a single output. And inheritance: Businesses differ from others incrementally. Inheritance is a way of modeling such incremental differences to a degree, explicitly. Even if inheritance is not perfect and can cause problems, it helps in many cases.
- mlthoughts2018 8y ago
  I personally believe almost the opposite. Even when I write Python, I use classes sparingly and if I ever choose to get a lower back tattoo it would probably say “Inheritance Sucks” in Chinese or something. Think of a constructor function for a class. It is so easy to shove new complexity in there. Just add new optional arguments, assign them as instance attributes, and off you go. If you have a class like MonthlyReport, and all of the sudden your boss wants to know how many widgets per month you sell specifically in Narnia, well you can probably hack this into the existing methods of MonthlyReport very quickly. Doing it once maybe isn’t so bad. But doing it a dozen times quickly leads to a bunch of functionality shoved into MonthlyReport that probably shoukd be refactored out, and lord help you if your boss all of the sudden says you need all of it to go into DailyReport, and you need a new YearlyReport class with overloaded behavior for FiscalYear, CalendarYear, and NarnianYear. If I heard about a system like this, my guess would be that it’s got a crapload of copy/pasted code, constructors and general class methods with huge lists of parameters and switches, maybe a few subsystems where someone tried to rewrite this with misguided MixIn patterns and abstract base classes, and everyone is terrified to change anything because no one knows how it actually works. Even an imperative design that just used boring modules of functions, maybe with a tiny amount of metaprogramming like decorators for repeated logic, would be waaay better, no functional programming needed. But well-crafted functional programming would be better still. The problem is sociological. Business managers won’t tolerate being told, “No. I cannot get you this result for a daily Narnian calendar by tomorrow— for that, we’ll need to draw up a quick design plan to make sure we add it in a maintainable way.” Functional programming mostly requires saying no, being careful, measuring twice and cutting once. With object orientation, you optionally can push back, say no, and try to do it carefully, but you don’thave to because of all the different buckets of mutable state, you often can find a place to shoe-horn unplanned complexity in somewhere, and leave it for future people to worry about when the shoe-horned complexity causes a big problem.

mlevental 8y ago

>The only language-specific thing that turned me off of Haskell in a significant way was that so many important concepts in Haskell are implemented via pragmas that extend the language and either enforce syntax restructions, enable totally new (and often esoteric) syntax, or change the meaning of existing syntax. god the ghc extensions. good luck figuring out why something is happening that you don't expect.

nightski 8y ago
What? They are opt in per module unless you manually enable them globally. Anyways the entire reason Haskell was created was to be a base for future language research. The extension system was largely the point.

galaxyLogic 8y ago

Could I summarize your objection to Functional Programming in business setting as the fact that Object Orientation makes it simpler to model the businesses and thus easier to solve their problems? If you think about a Function it does just one thing. But real world "agents" that run a business do many things. An OO-class has many methods, not just a single input and a single output. And inheritance: Businesses differ from others incrementally. Inheritance is a way of modeling such incremental differences to a degree, explicitly. Even if inheritance is not perfect and can cause problems, it helps in many cases.

mlthoughts2018 8y ago
I personally believe almost the opposite. Even when I write Python, I use classes sparingly and if I ever choose to get a lower back tattoo it would probably say “Inheritance Sucks” in Chinese or something. Think of a constructor function for a class. It is so easy to shove new complexity in there. Just add new optional arguments, assign them as instance attributes, and off you go. If you have a class like MonthlyReport, and all of the sudden your boss wants to know how many widgets per month you sell specifically in Narnia, well you can probably hack this into the existing methods of MonthlyReport very quickly. Doing it once maybe isn’t so bad. But doing it a dozen times quickly leads to a bunch of functionality shoved into MonthlyReport that probably shoukd be refactored out, and lord help you if your boss all of the sudden says you need all of it to go into DailyReport, and you need a new YearlyReport class with overloaded behavior for FiscalYear, CalendarYear, and NarnianYear. If I heard about a system like this, my guess would be that it’s got a crapload of copy/pasted code, constructors and general class methods with huge lists of parameters and switches, maybe a few subsystems where someone tried to rewrite this with misguided MixIn patterns and abstract base classes, and everyone is terrified to change anything because no one knows how it actually works. Even an imperative design that just used boring modules of functions, maybe with a tiny amount of metaprogramming like decorators for repeated logic, would be waaay better, no functional programming needed. But well-crafted functional programming would be better still. The problem is sociological. Business managers won’t tolerate being told, “No. I cannot get you this result for a daily Narnian calendar by tomorrow— for that, we’ll need to draw up a quick design plan to make sure we add it in a maintainable way.” Functional programming mostly requires saying no, being careful, measuring twice and cutting once. With object orientation, you optionally can push back, say no, and try to do it carefully, but you don’thave to because of all the different buckets of mutable state, you often can find a place to shoe-horn unplanned complexity in somewhere, and leave it for future people to worry about when the shoe-horned complexity causes a big problem.