6 ms·

A Conversation About OOP vs. FP Turns Constructive

73 points by svanderbleek 10y ago

nitrix 10y ago
A few incorrect points during the discussion as well as poorly approached. The only thing beneficial that I see from it is people trying to better their skills and Haskell gaining traction. I personally would recommend #haskell-beginners on freenode IRC as well as http://haskellbook.com http://haskellbook.com for the ones interested. For everybody else, well I'm not a sale person and my job isn't to convince you. If it takes you 30 years to (re)discover Haskell, so be it.
- jblow 10y ago
  Haskell has been around for over 20 years. If it hasn't set the programming world on fire yet, there are probably reasons.
  - tome 10y ago
    Surely there are reasons. And those reasons need be nothing to do with whether it's worth using Haskell in 2016.
  - NegativeK 10y ago
    Haskell might be bad, but its unofficial slogan is "Avoid success at all costs" -- so I don't think lack of fire necessary implies it's shitty (which is I think what you were implying.)
    - cm3 10y ago
      Actually, Simon PJ clarified that it's "avoid success-at-all-costs" and not "avoid success at-all-costs".
      - tome 10y ago
        In any case, it's mostly a joke.
      - dllthomas 10y ago
        I've always interpreted it (and I'm not sure Simon would disagree) as a serious "avoid success-at-all-costs" and a tongue-in-cheek "avoid success at-all-costs".
  - embwbam 10y ago
    Like we only now see how bad large OO systems can be? :D. Seriously though I think that people are becoming interested in FP because they see the limitations of their current tools. That's what happened for me anyway. Also I don't know that Haskell will become mainstream, but something that looks way more like Haskell than Java will.
    - deleted 10y ago
      [deleted]
  - SomethingOrNot 10y ago
    ML has been around for 40 years, but only lately have algebraic data types been catching on somewhat.
  - thinkpad20 10y ago
    Haskell as we know it now, with high performance, large library selection, more powerful type system, advanced tooling, testing and profiling etc, has been around for significantly less time than that. I also think that's a specious argument. Many things influence a language's popularity that have nothing to do with the language's actual value. Haskell is very idiosyncratic compared to other mainstream languages, requiring a "relearning" of a lot of skills developers take for granted. Many people balk at the learning curve and never get into it. Haskell has also received comparatively little contributions from industry and was never the pet language of a major organization (like e.g. C#, Java, Go, Rust, Dart, etc). Also the influence of Haskell can be seen in a variety of areas, from other languages adopting more advanced type systems, type classes, systems like LINQ in C#, and the increasing popularity of functional programming in general. Finally, although popularity drives language ecosystem and therefore usability, Haskell's merits purely as a language stand on its own regardless of how many people use it.
  - seagreen 10y ago
    The good haskellers I've talked to about this say Haskell has only recently become a mature language=) The modern fast data structures packages date from 2007 to 2011 (containers, vector, text, and unordered-containers). Recently there have been more breakthroughs like FB adoption and an unrivaled web API library in Servant (https://haskell-servant.readthedocs.io/ https://haskell-servant.readthedocs.io/). Also we got Stackage and Stack recently (which ended "cabal hell"). Even "cabal hell" is gone with the new cabal-install improvements. So don't count Haskell out too easily because it's old. It's an awesome language, but it took people a long time to figure out how to program well in it, given that it's so different from the normal way of doing things.
  - knucklesandwich 10y ago
    Haskell definitely has problems. I'm a huge fan of the language, but I think its disingenuous to pretend like its flawless. To name a few: 1. Poor debugging tools. Unfortunately this is sort of intrinsically tied with non-strict evaluation. Typical evaluation stepping debuggers would be sort of unpredictable in haskell. Along these lines, haskell doesn't have stack traces enabled by default, and reading them is sort of tricky. 2. Clumsy exceptions model. There are asynchronous and synchronous exceptions, with the later being further broken down into exceptions in pure code or exceptions thrown in IO. Only exceptions thrown in IO are catchable. You can think of exceptions in pure code as similar to "panic()" calls in other languages, except they're even tricker due to lazy evaluation, and aren't necessarily guaranteed to be triggered due to slipperiness with laziness. Also since exceptions are used for interrupting computations (timeouts, for instance) and there isn't a way (other than some type class conventions) to distinguish between interrupting exceptions that should be allowed to propagate and exceptions due to "exceptional circumstances", catching all exceptions safely is a tricky matter. 3. Record syntax leaves a lot to be desired. It's incredibly easy to run into situations where you would have conflicting functions due to record syntax. Lenses are a partial fix for this, but its sort of annoying that something like row polymorphism isn't just a part of the language. 4. Laziness can make reasoning about time and space complexity trickier. Generally this is a little overstated, but you'll occasionally run into space leaks. There are definitely real problems with the language, and some of them (such as poor debugging capabilities) can be legitimate showstoppers to use in industry, but generally I find that its advantages far outweigh its negatives.
    - dllthomas 10y ago
      The bits about exceptions and IO isn't quite right. So far as I'm aware, there is no technical difference between exceptions thrown in IO versus exceptions thrown in pure code. There are two contextual differences. First, exceptions can only be caught in IO, but everything running has IO above it somewhere, or it wouldn't be running in the first place. Regarding exceptions thrown in IO versus elsewhere, it's worth noting that exceptions thrown anywhere are only actually thrown if the thunk representing them is forced. IO values tend to be used quite close to where they are created, whereas an exception in lazy, pure code might hide in the creation of the leaf of a tree or at the end of a list.
  - runT1ME 10y ago
    How long has ML been around and how long did it take for it to become 'mainstream' enough to be used by big teams at Facebook and Jane Street?
- wfo 10y ago
  Many people learn Haskell (or FP in general) at university and then wash their hands of it and refuse to ever touch it again. Perhaps consider it could be a matter of preference or right-tool-for-the-job rather than the fact that the unwashed peasants just haven't "discovered" enlightenment yet. Spoken as someone who prefers FP but is not a zealot.
- svanderbleek 10y ago
  I'd love if you can point out the incorrect points, but I understand that's not your responsibility. Thanks for the feedback!
ebbv 10y ago
This conversation is awful. This seems like a bunch of armchair developers with really strong opinions and no real world experience. No experienced developer I want to work with has the kind of dogmatic views that most of the people in this chat log have. FP and OOP are both just tools, how you use them is way more important than which tool you choose.
- frozenport 10y ago
  Indeed, for example I think that the so-called "reliability" offered by FP is can be attributed to comparable simple tasks these developers work on. It's typically some form of parsing data.
  - seagreen 10y ago
    Come on frozenport, do you really think that applies to Standard Chartered, Jane Street, or FB?
    - frozenport 10y ago
      While the motivation for their models might be complex or esoteric, calculating out the parameters might as well be done in Excel. Typically, the data flow is linear, and well suited for FP. But it ain't hard either. The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner, along with the user interaction that is found in desktop applications - or in my case that controls hardware instruments.
      - seagreen 10y ago
        the so-called "reliability" offered by FP is can be attributed to comparable simple tasks these developers work on The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner[..] There's more than one kind of complexity. Keeping 1.3 million SLOC of trading code relatively error free while allowing non-full-time programmers to contribute to it is also complex.
fowlerpower 10y ago
I really believe the future is a mixed OOP and FP world. I think we will see industry use languages like Scala and F# more and more. In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. I also believe the crazy complexity of OO languages like Java is slowly being reigned in. With other languages like Go explicitly making trade offs towards simplicity.
- jjnoakes 10y ago
  I have no stake in pro-Go or anti-Go statements here, but I do want to say that a simple language does not always lead to simple code in that language. For example, if one has to copy and paste because a language is too simple to provide a needed abstraction, then the code is needlessly complicated (through duplication) because the language is too simple.
  - DubiousPusher 10y ago
    Exactly. C is a vastly smaller language than C++ but OO C is very complex with factories booking up function pointers, lots of macros, etc. Creating an object with runtime polymorphism in C++ is much simpler.
- nv-vn 10y ago
  >In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style. >languages like Go explicitly making trade offs towards simplicity I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.
- nv-vn 10y ago
  >In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style. >languages like Go explicitly making trade offs towards simplicity I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.
wangchow 10y ago
At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. This is why you see languages like C++, Java, and C# adding support for them all. It is useful to express a particular problem domain in a way that is efficient and makes sense. I would be more interested in a discussion about concurrency because it becomes more relevant across the programming-language or paradigm barrier. Because at the end of the day we are confined by how the hardware operates and concurrency is very much a modern way of thinking as developers.
- TheRealPomax 10y ago
  realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. And I say that as someone with a formal education in programming and decent understanding of most programming paradigms.
  - ebbv 10y ago
    If you are a professional developer you should always be learning and growing your skill set. You don't have to learn about functional programming, but choosing to remain ignorant does not reflect well on you. There's a difference between learning about it and using it at work. Your job may not have any good opportunities to apply FP, but you should be learning about it in your spare time given how many great use cases it has in today's world.
    - TheRealPomax 10y ago
      the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD. I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sole maintainers of complex codebases, with zero need or intention to learn new approaches because it won't let them do their job any better. Does that make them less likely to get a new job? sure, unless their new job still uses the language they use right now, which when you have 20 years of experience tends to not happen - other big companies and institutions will hire you on the spot. But a more important question is: will they even get to a point where they will need to look for a new job before retiring? Chances of that are roughly zero.
gfunk911 10y ago
Put it in a more readable format here: https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90ae4a468 https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90...
- elmigranto 10y ago
  I'm not sure if right-aligned text is more readable.
- svanderbleek 10y ago
  Cool, but I find that hard to read. I'm going to do a custom stylesheet, I was just waiting to see if there was any interest in the conversational format form my Slack conversations. Really appreciate your effort.
rjbwork 10y ago
Most statically typed programs/systems these days (Java, C#, even C++ if you wish) these days, use DI via IoC containers as the mechanism for constructing objects and choosing which code to run. You can even do it with dynamic languages like JS/Python if you wish, though many argue it being dynamic means you don't need to use a container - which is pretty true. This approach is equivalent to a family of functions (with side effects), one family per class, each with N(c) + N(m) arguments, where N(c) is the number of constructor arguments, and N(m) is the number of method arguments. Upon object construction, these families are partially applied to construct a new family of functions that contain only N(m) arguments. You can think of a constructor as a functor, that returns a number partially applied functions - the methods on the classes. This is how I actually think of my OO programs these days. I also make liberal use of the actual functional tools made available to me. For instance, my bread and butter is C#, and LINQ heavily promotes a purely functional style when manipulating collections of data, though side effects are possible. At a system level, I also tend to think of my data pipelines as functional transformations as well - their being written as an OO program is of little actual consequence.
- edem 10y ago
  This is how I also work. You can use rudimentary languages like java to do FP if you have the proper mindset.
musesum 10y ago
From Bill Gathan: http://www.codenewbie.org/blogs/object-oriented-programming-vs-functional-programming http://www.codenewbie.org/blogs/object-oriented-programming-... Michael Fogus, author of “Functional JavaScript”, suggests in his blog post “FP vs OO, from the trenches” (http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/ http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/) that when he deals with data about people, FP works well, but when he tries to simulate people, OOP works well. I wonder about shape of the data as it moves from domain -> range? How would they map to machine and biological models for learning? First guess is the that ML maps well onto FP; for CNNs, the data progresses synchronously from one layer to the next. For Bio, state is asynchronous; neurons, after firing have an efficacy period. Maybe super-fine-grain objects? Petri nets are interesting in that they can feedforward state asynchronously.
johncolanduoni 10y ago
I think the OOP vs FP debate misses the real asset that functional programming offers us, and it's not writing everything in [your favorite functional language]'s typical style. Look at a language like Idris; a formal definition of its unsugared semantics would fit on half a page easily. However it still manages to give us all kinds of goodies, like effect tracking, compile-time checking for virtually any condition you can write a decision procedure for, and design-by-contract on steroids. These features are useful whether the code you're writing is pure, stateful, object-oriented, functional, and/or whatever paradigm you write up tomorrow. Forget aesthetic arguments about elegance; where else can you build so much without ad-hoc concessions to individual language features? As far as I know, there's no other method that lets you treat powerful language features as libraries without either (a) making a mish-mash when they're used together like compiler plugins do (b) making debugging your compile process a full time job like various strongly-typed macro systems tend to. Why not use FP to form the fundamentals of our languages, something where as of yet it has no equal, and build up the structures we need (regardless of programming tradition of origin) on top of that?
- svanderbleek 10y ago
  I like your points, but I'm not sure of the Idris on half a page. How much tacit knowledge does that rely on? We do need to focus on the fundamentals of education, the spectrum of logics with quantifiers, lambda calculus, and natural deduction style presentations of language semantics (not sure what to actually call this?).
  - delish 10y ago
    > How much tacit knowledge does that rely on? It looks like you're criticizing the GP's praise of Idris' concise formal definition of its unsugared semantics. I wouldn't use such a formal definition for educating novices (like I think you're implying in your next sentence); I'd use it professionally to show that many desirable things--effect tracking, compile-time checking, and design-by-contract--derive from the same thing. Ken Iverson in his notes on mathematical notation says that one criterion for a good notation is "suggestibility"--the notation should suggest that other problems similar to those you found just now could be solved as well. Whether formality is useful for novices, it is certainly useful for experts.

73 points by svanderbleek 10y ago

A few incorrect points during the discussion as well as poorly approached. The only thing beneficial that I see from it is people trying to better their skills and Haskell gaining traction. I personally would recommend #haskell-beginners on freenode IRC as well as http://haskellbook.com http://haskellbook.com for the ones interested. For everybody else, well I'm not a sale person and my job isn't to convince you. If it takes you 30 years to (re)discover Haskell, so be it.

jblow 10y ago
Haskell has been around for over 20 years. If it hasn't set the programming world on fire yet, there are probably reasons.
- tome 10y ago
  Surely there are reasons. And those reasons need be nothing to do with whether it's worth using Haskell in 2016.
- NegativeK 10y ago
  Haskell might be bad, but its unofficial slogan is "Avoid success at all costs" -- so I don't think lack of fire necessary implies it's shitty (which is I think what you were implying.)
  - cm3 10y ago
    Actually, Simon PJ clarified that it's "avoid success-at-all-costs" and not "avoid success at-all-costs".
    - tome 10y ago
      In any case, it's mostly a joke.
    - dllthomas 10y ago
      I've always interpreted it (and I'm not sure Simon would disagree) as a serious "avoid success-at-all-costs" and a tongue-in-cheek "avoid success at-all-costs".
- embwbam 10y ago
  Like we only now see how bad large OO systems can be? :D. Seriously though I think that people are becoming interested in FP because they see the limitations of their current tools. That's what happened for me anyway. Also I don't know that Haskell will become mainstream, but something that looks way more like Haskell than Java will.
  - deleted 10y ago
    [deleted]
- SomethingOrNot 10y ago
  ML has been around for 40 years, but only lately have algebraic data types been catching on somewhat.
- thinkpad20 10y ago
  Haskell as we know it now, with high performance, large library selection, more powerful type system, advanced tooling, testing and profiling etc, has been around for significantly less time than that. I also think that's a specious argument. Many things influence a language's popularity that have nothing to do with the language's actual value. Haskell is very idiosyncratic compared to other mainstream languages, requiring a "relearning" of a lot of skills developers take for granted. Many people balk at the learning curve and never get into it. Haskell has also received comparatively little contributions from industry and was never the pet language of a major organization (like e.g. C#, Java, Go, Rust, Dart, etc). Also the influence of Haskell can be seen in a variety of areas, from other languages adopting more advanced type systems, type classes, systems like LINQ in C#, and the increasing popularity of functional programming in general. Finally, although popularity drives language ecosystem and therefore usability, Haskell's merits purely as a language stand on its own regardless of how many people use it.
- seagreen 10y ago
  The good haskellers I've talked to about this say Haskell has only recently become a mature language=) The modern fast data structures packages date from 2007 to 2011 (containers, vector, text, and unordered-containers). Recently there have been more breakthroughs like FB adoption and an unrivaled web API library in Servant (https://haskell-servant.readthedocs.io/ https://haskell-servant.readthedocs.io/). Also we got Stackage and Stack recently (which ended "cabal hell"). Even "cabal hell" is gone with the new cabal-install improvements. So don't count Haskell out too easily because it's old. It's an awesome language, but it took people a long time to figure out how to program well in it, given that it's so different from the normal way of doing things.
- knucklesandwich 10y ago
  Haskell definitely has problems. I'm a huge fan of the language, but I think its disingenuous to pretend like its flawless. To name a few: 1. Poor debugging tools. Unfortunately this is sort of intrinsically tied with non-strict evaluation. Typical evaluation stepping debuggers would be sort of unpredictable in haskell. Along these lines, haskell doesn't have stack traces enabled by default, and reading them is sort of tricky. 2. Clumsy exceptions model. There are asynchronous and synchronous exceptions, with the later being further broken down into exceptions in pure code or exceptions thrown in IO. Only exceptions thrown in IO are catchable. You can think of exceptions in pure code as similar to "panic()" calls in other languages, except they're even tricker due to lazy evaluation, and aren't necessarily guaranteed to be triggered due to slipperiness with laziness. Also since exceptions are used for interrupting computations (timeouts, for instance) and there isn't a way (other than some type class conventions) to distinguish between interrupting exceptions that should be allowed to propagate and exceptions due to "exceptional circumstances", catching all exceptions safely is a tricky matter. 3. Record syntax leaves a lot to be desired. It's incredibly easy to run into situations where you would have conflicting functions due to record syntax. Lenses are a partial fix for this, but its sort of annoying that something like row polymorphism isn't just a part of the language. 4. Laziness can make reasoning about time and space complexity trickier. Generally this is a little overstated, but you'll occasionally run into space leaks. There are definitely real problems with the language, and some of them (such as poor debugging capabilities) can be legitimate showstoppers to use in industry, but generally I find that its advantages far outweigh its negatives.
  - dllthomas 10y ago
    The bits about exceptions and IO isn't quite right. So far as I'm aware, there is no technical difference between exceptions thrown in IO versus exceptions thrown in pure code. There are two contextual differences. First, exceptions can only be caught in IO, but everything running has IO above it somewhere, or it wouldn't be running in the first place. Regarding exceptions thrown in IO versus elsewhere, it's worth noting that exceptions thrown anywhere are only actually thrown if the thunk representing them is forced. IO values tend to be used quite close to where they are created, whereas an exception in lazy, pure code might hide in the creation of the leaf of a tree or at the end of a list.
- runT1ME 10y ago
  How long has ML been around and how long did it take for it to become 'mainstream' enough to be used by big teams at Facebook and Jane Street?
wfo 10y ago
Many people learn Haskell (or FP in general) at university and then wash their hands of it and refuse to ever touch it again. Perhaps consider it could be a matter of preference or right-tool-for-the-job rather than the fact that the unwashed peasants just haven't "discovered" enlightenment yet. Spoken as someone who prefers FP but is not a zealot.
svanderbleek 10y ago
I'd love if you can point out the incorrect points, but I understand that's not your responsibility. Thanks for the feedback!

ebbv 10y ago

This conversation is awful. This seems like a bunch of armchair developers with really strong opinions and no real world experience. No experienced developer I want to work with has the kind of dogmatic views that most of the people in this chat log have. FP and OOP are both just tools, how you use them is way more important than which tool you choose.

frozenport 10y ago
Indeed, for example I think that the so-called "reliability" offered by FP is can be attributed to comparable simple tasks these developers work on. It's typically some form of parsing data.
- seagreen 10y ago
  Come on frozenport, do you really think that applies to Standard Chartered, Jane Street, or FB?
  - frozenport 10y ago
    While the motivation for their models might be complex or esoteric, calculating out the parameters might as well be done in Excel. Typically, the data flow is linear, and well suited for FP. But it ain't hard either. The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner, along with the user interaction that is found in desktop applications - or in my case that controls hardware instruments.
    - seagreen 10y ago
      the so-called "reliability" offered by FP is can be attributed to comparable simple tasks these developers work on The kind of complexity I'm referring to is the need to synchronize and coordinate concurrency in a time efficient manner[..] There's more than one kind of complexity. Keeping 1.3 million SLOC of trading code relatively error free while allowing non-full-time programmers to contribute to it is also complex.

fowlerpower 10y ago

I really believe the future is a mixed OOP and FP world. I think we will see industry use languages like Scala and F# more and more. In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. I also believe the crazy complexity of OO languages like Java is slowly being reigned in. With other languages like Go explicitly making trade offs towards simplicity.

jjnoakes 10y ago
I have no stake in pro-Go or anti-Go statements here, but I do want to say that a simple language does not always lead to simple code in that language. For example, if one has to copy and paste because a language is too simple to provide a needed abstraction, then the code is needlessly complicated (through duplication) because the language is too simple.
- DubiousPusher 10y ago
  Exactly. C is a vastly smaller language than C++ but OO C is very complex with factories booking up function pointers, lots of macros, etc. Creating an object with runtime polymorphism in C++ is much simpler.
nv-vn 10y ago
>In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style. >languages like Go explicitly making trade offs towards simplicity I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.
nv-vn 10y ago
>In mission critical portions of systems people will use a functional style and try to isolate state, while most things in an OO style will be just fine. What makes you think that programmers who are used to writing in FP style for mission critical components would step away from FP for OOP for less important code? In my experience, most of the time functional code is often more succinct and easier to write. I don't think it would benefit anyone to write the majority of an application in the more verbose style. >languages like Go explicitly making trade offs towards simplicity I think Go is a counterargument to your point here. It's simplicity makes it much less suited for multi-paradigm programming than a complex language like C++ or Scala.

wangchow 10y ago

At this day and age people should be familiar with multiple paradigms. Whether procedural, functional, or Object-Oriented they are all useful. This is why you see languages like C++, Java, and C# adding support for them all. It is useful to express a particular problem domain in a way that is efficient and makes sense. I would be more interested in a discussion about concurrency because it becomes more relevant across the programming-language or paradigm barrier. Because at the end of the day we are confined by how the hardware operates and concurrency is very much a modern way of thinking as developers.

TheRealPomax 10y ago
realist contrarian question: why? If you didn't receive a formal education but you got good at OOP js or php, your expected salary gets pretty close to six figures. No understanding or even theoretical appreciation of other paradigms required. And I say that as someone with a formal education in programming and decent understanding of most programming paradigms.
- ebbv 10y ago
  If you are a professional developer you should always be learning and growing your skill set. You don't have to learn about functional programming, but choosing to remain ignorant does not reflect well on you. There's a difference between learning about it and using it at work. Your job may not have any good opportunities to apply FP, but you should be learning about it in your spare time given how many great use cases it has in today's world.
  - TheRealPomax 10y ago
    the real world does not particularly line up with that statement. For a fast moving contract based world, sure, but there's also the other part of the programming landscape where codebases need to be maintained forever for institutions and large companies whose idea of stable is even stricter than OpenBSD. I know plenty of people who work on both, and the second category gets paid very good money indeed to be the sole maintainers of complex codebases, with zero need or intention to learn new approaches because it won't let them do their job any better. Does that make them less likely to get a new job? sure, unless their new job still uses the language they use right now, which when you have 20 years of experience tends to not happen - other big companies and institutions will hire you on the spot. But a more important question is: will they even get to a point where they will need to look for a new job before retiring? Chances of that are roughly zero.

gfunk911 10y ago

Put it in a more readable format here: https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90ae4a468 https://gist.github.com/mharris717/cb2111a4f74ea1ef7f3a5de90...

elmigranto 10y ago
I'm not sure if right-aligned text is more readable.
svanderbleek 10y ago
Cool, but I find that hard to read. I'm going to do a custom stylesheet, I was just waiting to see if there was any interest in the conversational format form my Slack conversations. Really appreciate your effort.

rjbwork 10y ago

Most statically typed programs/systems these days (Java, C#, even C++ if you wish) these days, use DI via IoC containers as the mechanism for constructing objects and choosing which code to run. You can even do it with dynamic languages like JS/Python if you wish, though many argue it being dynamic means you don't need to use a container - which is pretty true. This approach is equivalent to a family of functions (with side effects), one family per class, each with N(c) + N(m) arguments, where N(c) is the number of constructor arguments, and N(m) is the number of method arguments. Upon object construction, these families are partially applied to construct a new family of functions that contain only N(m) arguments. You can think of a constructor as a functor, that returns a number partially applied functions - the methods on the classes. This is how I actually think of my OO programs these days. I also make liberal use of the actual functional tools made available to me. For instance, my bread and butter is C#, and LINQ heavily promotes a purely functional style when manipulating collections of data, though side effects are possible. At a system level, I also tend to think of my data pipelines as functional transformations as well - their being written as an OO program is of little actual consequence.

edem 10y ago
This is how I also work. You can use rudimentary languages like java to do FP if you have the proper mindset.

musesum 10y ago

From Bill Gathan: http://www.codenewbie.org/blogs/object-oriented-programming-vs-functional-programming http://www.codenewbie.org/blogs/object-oriented-programming-... Michael Fogus, author of “Functional JavaScript”, suggests in his blog post “FP vs OO, from the trenches” (http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/ http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/) that when he deals with data about people, FP works well, but when he tries to simulate people, OOP works well. I wonder about shape of the data as it moves from domain -> range? How would they map to machine and biological models for learning? First guess is the that ML maps well onto FP; for CNNs, the data progresses synchronously from one layer to the next. For Bio, state is asynchronous; neurons, after firing have an efficacy period. Maybe super-fine-grain objects? Petri nets are interesting in that they can feedforward state asynchronously.

johncolanduoni 10y ago

I think the OOP vs FP debate misses the real asset that functional programming offers us, and it's not writing everything in [your favorite functional language]'s typical style. Look at a language like Idris; a formal definition of its unsugared semantics would fit on half a page easily. However it still manages to give us all kinds of goodies, like effect tracking, compile-time checking for virtually any condition you can write a decision procedure for, and design-by-contract on steroids. These features are useful whether the code you're writing is pure, stateful, object-oriented, functional, and/or whatever paradigm you write up tomorrow. Forget aesthetic arguments about elegance; where else can you build so much without ad-hoc concessions to individual language features? As far as I know, there's no other method that lets you treat powerful language features as libraries without either (a) making a mish-mash when they're used together like compiler plugins do (b) making debugging your compile process a full time job like various strongly-typed macro systems tend to. Why not use FP to form the fundamentals of our languages, something where as of yet it has no equal, and build up the structures we need (regardless of programming tradition of origin) on top of that?

svanderbleek 10y ago
I like your points, but I'm not sure of the Idris on half a page. How much tacit knowledge does that rely on? We do need to focus on the fundamentals of education, the spectrum of logics with quantifiers, lambda calculus, and natural deduction style presentations of language semantics (not sure what to actually call this?).
- delish 10y ago
  > How much tacit knowledge does that rely on? It looks like you're criticizing the GP's praise of Idris' concise formal definition of its unsugared semantics. I wouldn't use such a formal definition for educating novices (like I think you're implying in your next sentence); I'd use it professionally to show that many desirable things--effect tracking, compile-time checking, and design-by-contract--derive from the same thing. Ken Iverson in his notes on mathematical notation says that one criterion for a good notation is "suggestibility"--the notation should suggest that other problems similar to those you found just now could be solved as well. Whether formality is useful for novices, it is certainly useful for experts.