Print

Code Watch: Functional programming's smugness problem



Larry O Brien
Email
April 16, 2012 —  (Page 1 of 2)
I like functional programming. I think it's going to drive code evolution through the next decade: languages will adopt more functional features, developers will adopt more functional techniques, and at some point, everyone will think that functional programming principles are the "natural" and clearest way to structure code.

But I am no longer sure of this scenario. Functional programming has a major problem that is evident to every mainstream programmer who has expressed an interest in learning what the excitement is about: Functional programmers are a bunch of smug jerks.

What are monads? "Monads are just monoids in the category of endofunctors! Ha ha, you don't understand any of those words, do you, stupid mainstream programmer?"

What are the design patterns that help structure functional systems? "Design patterns? Hey everyone, look at the muggle try to get the wand to work!"

What does functional programming have to offer to my team of programmers developing enterprise applications that have to live in a real-world ecosystem of data, interfaces and APIs? "You don't even see how... (long silence) If you knew category theory, you'd get it!"

Functional programmers have applied modern advances in type theory to yesterday's Smug LISP Weenie to generate today's Insufferable Haskell Prick. Just as LISP advocates carefully avoid the reality of decades of Scheme- and LISP-exposed CS students who happily left those languages behind, functional advocates carefully avoid acknowledging the programmers who have filed in to the functional programming room, listened to the conversation for a bit, read the literature, and quietly left.

What's incredibly frustrating about this is that many functional programming benefits are both clear and already being used by today's programming mainstream. Good programmers understand that immutable data is generally preferable to mutable, that functions that always return the same value for the same inputs are easier to work with than functions whose behavior depends on hidden state, and that complexity is best built with small functions that are focused on a specific purpose. And once programmers get a taste of lambda functions in combination with collection classes (the maps, flatMaps, finds and folds of the world), they won't want to go back.


Related Search Term(s): functional programming

Pages 1 2 


Share this link: http://sdt.bz/36534
 


Comments


04/17/2012 01:20:03 PM EST

There are smug pricks on all sides. Like people who write articles name calling a whole class of people.

United Statesorbitz


04/18/2012 11:30:26 AM EST

I understand that there can be some very vocal advocates who can come off as smug, but that is something you can find in any area of the software industry (especially when people want a panacea). In fact is is a matter of life that you will always find people like that. I'm pretty new to the Haskell community, but the interactions I have had with them so far have been very warm. "This is my message to today's functional programmers: You can either change the industry or you can be smugly elite. Choose one. " "Only a sith deals in absolutes."

United StatesMatthew Brunelle


04/18/2012 11:52:49 AM EST

Awesome post... except for the Java vs Scala study. Scala is a horrible language that makes both object oriented programming and functional programming painful. It's syntax is one of the least intuitive in the programming world. Not a valid comparison. Now something like F# vs C# would be interesting, you can write object oriented code in F# in half the lines you do in C#, and this isn't even taking into account all the lines saved by using the functional paradigm (which the language supports quite well, though not as much as haskell). It also supports type extensions much better than C#, and inline class definitions. http://blogs.msdn.com/b/timng/archive/2010/04/06/f-quick-guides-object-oriented-programming.aspx That's a study I'd like to see.

PortugalNoDeal


04/18/2012 11:57:18 AM EST

1. Attacking strawmen gets you nowhere. 2. Legacy code requires work in the legacy paradigm. 3. Academic tools are looked down upon by industry 4. Please keep writing Java, I like competing with you. :-)

United StatesSmug Lisp Weenie


04/18/2012 11:59:22 AM EST

I feel the need to step in here and note that the Erlang community is fairly awesome. Both on IRC and the Mailing Lists. I don't know where the awesome springs from, it might be the impure nature of Erlang (it is a get it done language, not slavishly devoted to functional purity), it might be the laid back nature of the languages core developers (and their continued involvement / development / experimentation on the list) ... it might just be the right mix of personalities. But, rather than being shot down when I ignorantly stepped into the community knowing nothing and with a real world problem, I was greeted with great advise, awesome feedback, and help galore from very busy people.

United StatesRobert Melton


04/18/2012 03:47:31 PM EST

I think you have it backward. Every example of "smugness" you give is an example where you're using concepts heavily embedded in the procedural paradigm and asking how they apply in the functional world. You're not even speaking the same language. But, what you forget is that these "smug" functional folks aren't knocking on your door trying to sell you something -- if they were, they'd have to speak your language. Instead, you're knocking on *their* door, pleading with them to help you solve problems that your procedural paradigm has failed to solve. You know they have the answers, but now you're whining because they expect you to learn *their* way of thinking rather than having their successful model broken by conforming to yours. So, watch it with the "smug". The Haskell community is one of the friendliest out there. Yes, figuring out monads is difficult, you're going to have to learn a whole new approach. That's the nature of the problem, not "smugness" on the part of the people who've solved it.

United StatesScott Brickner


04/18/2012 06:24:08 PM EST

Don't blame the tool for part of its user base. If the tool is good, it doesn't matter who else uses it. It still drives nails, right? Personally, learning Lisp was quite the eye opener. It made me realize how a computer was meant to be used.

SwedenNot That Smug LISP Weenie


04/18/2012 08:33:32 PM EST

Hi. I am a designer of statistical programming languages. I have reason to believe that functional methodologies may be a beneficial research direction for that subject area (emphasis: "may") But some caveats. Functional is a fad in academia, so people block their ears when you point to the tradeoffs, good and bad. And functional programming languages are really HARD. Haskell is HARD. More research needs to be done with an emphasis on usability (like SGML to XML). I think I could make a difference here. Robert Wilkins

United StatesRobert


04/18/2012 08:35:44 PM EST

First of all, wow: I would never imagine I could be called a "smug jerk" because I use functional languages!(Seriously, though, why this kind of opinionated bullcrap is getting upvoted?!). >>> What are monads? "Monads are just monoids in the category of endofunctors! Ha ha, you don't understand any of those words, do you, stupid mainstream programmer?" It's not my problem if you can't understand a perfectly valid answer. Or, maybe, Google for dozens of more down-to-earth monad tutorials (e.g. [1]) instead of venting your frustrations in a less-than-polite manner? However, maybe, the right question for you to ask is how to use them? I think it's actually fine to use monads without understanding all the math -- I've done it for a long time. And, after all, you don't need to know the whole cat theory, just know the 3 monad laws and you're good to go. >>> What are the design patterns that help structure functional systems? "Design patterns? Hey everyone, look at the muggle try to get the wand to work!" Here's my take on Monads (I'm going to use Haskell as an example as Monads seem to be most prominent there): apart from being a mathematic construction, they are an interface to programming/design patterns (there are others: e.g., Arrows). And then the patterns themselves are the concrete monadic types/typeclasses, like State or IO or Reader etc. And when you add monad transformers to the mix, that approach makes even more sense: with transformers you can easily combine different patterns while having a unified interface to them (>>=, return, do-notation, lift). Hope this helps, but I am not holding my breath as you've just called me a smug jerk for understanding something you didn't. [1] http://www.haskell.org/haskellwiki/Monads

United StatesAndrey


04/19/2012 04:38:07 AM EST

And here is the reaction of the Smug Haskell Community to this article: http://www.reddit.com/r/haskell/comments/sg3yt/functional_programmings_smugness_problem/ What a bunch of jerks!

United StatesGuy


04/19/2012 08:46:43 AM EST

I have more than 30 years of programming experience, primarily in Assembler/C/C++. I used to think that I had a pretty good idea of what developing software was all about. However, after I decided to learn new languages such as Clojure, Erlang and Haskell, I realized that there is so much more to learn. And yes it takes real effort to learn something truly new. But what a joy it is to feel your brain become more agile and your thinking starting to move in new interesting directions. You realize that there is a whole new world to be discovered and play with. For that reason alone, functional programming is worth learning. Even if you can't or won't switch from your current language.

AustraliaMorten Brodersen


04/20/2012 07:18:24 AM EST

I believe the problem is not when you are a "functional" developer or "OOP" developer. The deeper problem is when you try to solve problems in only one paradigm. The solution in my mind is to become a more rounded developer, learn a few different paradigms. Use them together in a combination to solve a problem (and not individually). To this end, I think its about better education. I'm trying to do my part, I've created a forum: http://www.theitninja.co.uk specifically to try and create a community of passionate developers, ones that are not just "functional" developer or "OOP" developer. In summary, there probably are a lot of "smug" individuals, but they are simply on a journey and have yet to "mature".

United KingdomDarknite


04/20/2012 07:53:00 AM EST

Any craft that is practiced professionally and is in high demand is done so by smug jerks and also by people who have no business doing it beyond an amateur level. They will both create more drama than product of their craft.

United StatesChris Umbel


04/20/2012 11:08:34 AM EST

One theme of the responses here and elsewhere seems to just be doubling down on the claim that FP provides something special. Smug Lisp Weenie says LISP gives him a competitive advantage, Scott Brickner says "You know they have the answers, but now you're whining because they expect you to learn *their* way of thinking rather than having their successful model broken by conforming to yours." To which I say "[Citation needed]". Another theme seems to be "Gee, actually the community seems very nice and welcoming." Which is humiliatingly mature.

United StatesLarry O'Brien


04/20/2012 11:59:24 AM EST

I'm a Java programmer; As such, I do all my work using a combination of object oriented and procedural techniques. Back when I was in college, I learned C first, then C++, and finally Perl and Java. Note that my progression echoed the exact way in which these languages were developed: first procedural, then object oriented - procedural hybrid, and finally scripting and pure object oriented. What I'm driving at is that each new language in the progression added something that solved a specific problem programmers were facing. Procedural languages can generally handle complexity up to the 50KLOC to 100KLOC level, which is about the highest level at which a single programmer can understand the entire body of code (the source code for the original Quake had 100KLOC). C++ gave us an object-procedural hybrid which generated massive interest in object oriented programming. Object oriented code enables programmers to understand and use code bases up to millions of lines of code, provided the API is well designed and documented. Scripting languages, of course, were designed to allow programmers to quickly and easily build websites, which is a different sort of problem. For functional languages to succeed, they must solve some problem that object oriented and procedural languages cannot solve. But I have not seen any such problems. It seems to me the primary goal of functional programming adherents is some sort of slavish devotion to formality. What do all those formal, rigid rules buy you? How do they help you write code? If your approach is actually HARDER it's a step backwards. Not a troll. Actually curious.

United StatesPhil Perry


04/21/2012 09:08:53 AM EST

No smugness intended, but FP does have design patterns, and they're discussed in plane sight: higher-order functions, continuation-passing style, monoids, monads, and etc. Sure, the mathematical basis of these "patterns", and of FP itself, that scares people off. However, that's no more a short-coming of FP than of, say, science or medicine. Fear and ignorance of immunization does not make Jenny McCarthy right. I have found there to be many friendly and helpful people in the various FP language communities. Don't waste your time whining about hurt feelings. As a programmer, you're paid to be a little bit smarter than average. Start earning it.

CanadaMichael J. Forster


04/21/2012 10:00:10 AM EST

I think there is no doubt that learning functional techniques makes you a better programmer, but (IMHO) the functional community believes that it can impose a function language with out addressing the pain points - user interface, logging, exception handling, translation etc. Commercial software products require more than just source code. Until we have an end-to-end approach for developing software with functional languages, I am afraid they will remain marginal.

Francedennis


close
NEXT ARTICLE
Code Watch: Functional programming: A sequence of FARTS
A new way of looking at functional programming is to break it down into this particular sequence Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?