5 ms·

Yes! This is basically why my new language is functional, and not OO. I bought in the OO dogma in college, but programming in functional languages is just so mu

Yes! This is basically why my new language is functional, and not OO. I bought in the OO dogma in college, but programming in functional languages is just so much easier.

whitepoplar 9y ago
Any chance you can talk more in depth about this? I'm really curious! FP seems wonderful, but there are few side-by-side code examples out there.
- sli 9y ago
  That may be less useful than you think, since the FP versions of many OO design patterns are just functions. The FP design patterns can end up being quite different than the similar OO versions, if you can even call them design patterns. So, all of this below is written in terms of FP beginners, so if I make a claim, it's in those terms, not general functional programming terms. I know that some of the information below is not entirely correct, just bear with me. Some argue that FP doesn't really have design patterns, which isn't true, but can be a useful mental model to keep you from getting hung up on them while you're learning. Consider than many of OO's design patterns are built to structure mutations on data. FP, by contrast, doesn't (typically) mutate data. That's where things diverge, and that's fairly early in the learning process. All that said, there are slews of things that can be "close enough" one-to-one mapped to an OO version, it's just that most of those things are fairly trivial. Map/filter/reduce vs. for-loops, for example. Perhaps you could start there. Rewrite some for-loops with map/filter/reduce. Learn the rules they follow, learn what a monoid is and what laws it follows and why they're useful, go from there. Something that helped me early on was implementing each of those in terms of the others. For example, implementing filter with reduce. Experimenting with good "playground" languages can help a lot. Hy[1] is an example of that, it's Lisp-flavored Python. You'll have a Lisp with a standard library that's very widely known, and you only need to install a Python module to use it (rather than, say, the entire Clojure stack). The biggest takeaway is that FP is geared very heavily towards writing programs and data pipelines that are built with small, composable pieces that are ideally also associative. You can of course do this with OO, but then your code ends up looking like this: someFunc(anotherFunc(thirdFunc(data))) Or: var someVal = thirdFunc(data) var anotherVal = anotherFunc(someVal) var finalVal = someFunc(anotherVal) Or: // Mutate data = thirdFunc(data) data = anotherFunc(data) data = someFunc(data) Compare to Clojure's version: ((comp third-func another-func some-func) data) And Haskell's (might be wrong, I'm not a Haskell programmer): (thirdFunc . anotherFunc . someFunc) data [1]: http://docs.hylang.org/en/stable/ http://docs.hylang.org/en/stable/
  - jayachdee 9y ago
    The usual Haskelly way is thirdFunc . anotherFunc . someFunc $ data
- pbiggar 9y ago
  Sure. I presume you're asking about why FP is easier, though if you're wondering about my language there's more info at https::/darklang.com. I think the quote about the gorilla and the banana and the jungle is a really important piece. It's just hard to compose things in OO languages unless they're designed to be used together. Whereas in an FP language, you focus on simpler primitives (arrays, hashtables, nullable types, and errors values typically, depending on the language), and you have a ton of functions that know how to work with those, so you kinda use them for everything. A second reason is static typing (doesn't apply to the lisp family of FP). Good static typing makes it very easy to understand what's happening, and makes it hard(er) to make errors. For example, in OCaml, Elm and Haskell, it's impossible to have a NullPointerException, which is the biggest bug class in Java. Similarly, the biggest problem in a python/ruby codebase is "what exactly is this thing I have", a problem eliminated by the type system as well. Of course, these features have a cost. It can sometimes be trickier to do things that are easy in dynamic OO languages like Python (and of course Haskell has layers of complexity so I don't recommend going near it), esp the learning curve if you're not familiar with FP. But being in deep in a functional codebase is much much easier than being in a deep in a java, ruby, python, js, etc, codebase. If you're looking to check FP out, I recommend Elm, ReasonML, or Clojure.
  - whitepoplar 9y ago
    Thank you! Do you have any thoughts on Elixir/Erlang/LFE? Elixir is dynamic, but seems to have many of the benefits of a static type system by use of Dialyzer, Erlang's static type analysis tool.
    - pbiggar 9y ago
      I have no experience with Erlang sadly. I did my PhD on static analysis though, and my general opinion is that the difference between a language designed for analysis (eg via a type system), and one that isn't, is night and day.
      - kazinator 9y ago
        In that respective order, too. You could have caught that had you assigned night and day different types, instead of having it blow up 19 hours later in the field like this.

Yes! This is basically why my new language is functional, and not OO. I bought in the OO dogma in college, but programming in functional languages is just so much easier.

whitepoplar 9y ago

Any chance you can talk more in depth about this? I'm really curious! FP seems wonderful, but there are few side-by-side code examples out there.

sli 9y ago
That may be less useful than you think, since the FP versions of many OO design patterns are just functions. The FP design patterns can end up being quite different than the similar OO versions, if you can even call them design patterns. So, all of this below is written in terms of FP beginners, so if I make a claim, it's in those terms, not general functional programming terms. I know that some of the information below is not entirely correct, just bear with me. Some argue that FP doesn't really have design patterns, which isn't true, but can be a useful mental model to keep you from getting hung up on them while you're learning. Consider than many of OO's design patterns are built to structure mutations on data. FP, by contrast, doesn't (typically) mutate data. That's where things diverge, and that's fairly early in the learning process. All that said, there are slews of things that can be "close enough" one-to-one mapped to an OO version, it's just that most of those things are fairly trivial. Map/filter/reduce vs. for-loops, for example. Perhaps you could start there. Rewrite some for-loops with map/filter/reduce. Learn the rules they follow, learn what a monoid is and what laws it follows and why they're useful, go from there. Something that helped me early on was implementing each of those in terms of the others. For example, implementing filter with reduce. Experimenting with good "playground" languages can help a lot. Hy[1] is an example of that, it's Lisp-flavored Python. You'll have a Lisp with a standard library that's very widely known, and you only need to install a Python module to use it (rather than, say, the entire Clojure stack). The biggest takeaway is that FP is geared very heavily towards writing programs and data pipelines that are built with small, composable pieces that are ideally also associative. You can of course do this with OO, but then your code ends up looking like this: someFunc(anotherFunc(thirdFunc(data))) Or: var someVal = thirdFunc(data) var anotherVal = anotherFunc(someVal) var finalVal = someFunc(anotherVal) Or: // Mutate data = thirdFunc(data) data = anotherFunc(data) data = someFunc(data) Compare to Clojure's version: ((comp third-func another-func some-func) data) And Haskell's (might be wrong, I'm not a Haskell programmer): (thirdFunc . anotherFunc . someFunc) data [1]: http://docs.hylang.org/en/stable/ http://docs.hylang.org/en/stable/
- jayachdee 9y ago
  The usual Haskelly way is thirdFunc . anotherFunc . someFunc $ data
pbiggar 9y ago
Sure. I presume you're asking about why FP is easier, though if you're wondering about my language there's more info at https::/darklang.com. I think the quote about the gorilla and the banana and the jungle is a really important piece. It's just hard to compose things in OO languages unless they're designed to be used together. Whereas in an FP language, you focus on simpler primitives (arrays, hashtables, nullable types, and errors values typically, depending on the language), and you have a ton of functions that know how to work with those, so you kinda use them for everything. A second reason is static typing (doesn't apply to the lisp family of FP). Good static typing makes it very easy to understand what's happening, and makes it hard(er) to make errors. For example, in OCaml, Elm and Haskell, it's impossible to have a NullPointerException, which is the biggest bug class in Java. Similarly, the biggest problem in a python/ruby codebase is "what exactly is this thing I have", a problem eliminated by the type system as well. Of course, these features have a cost. It can sometimes be trickier to do things that are easy in dynamic OO languages like Python (and of course Haskell has layers of complexity so I don't recommend going near it), esp the learning curve if you're not familiar with FP. But being in deep in a functional codebase is much much easier than being in a deep in a java, ruby, python, js, etc, codebase. If you're looking to check FP out, I recommend Elm, ReasonML, or Clojure.
- whitepoplar 9y ago
  Thank you! Do you have any thoughts on Elixir/Erlang/LFE? Elixir is dynamic, but seems to have many of the benefits of a static type system by use of Dialyzer, Erlang's static type analysis tool.
  - pbiggar 9y ago
    I have no experience with Erlang sadly. I did my PhD on static analysis though, and my general opinion is that the difference between a language designed for analysis (eg via a type system), and one that isn't, is night and day.
    - kazinator 9y ago
      In that respective order, too. You could have caught that had you assigned night and day different types, instead of having it blow up 19 hours later in the field like this.