A Year of Functional Programming
japgolly.blogspot.com.au
A Year of Functional Programming
1–10 of 172 posts
Re: A Year of Functional Programming
#2" Recently I looked at some code I wrote 8 months ago and was shocked! I looked at one file written in “good OO-style”, lots of inheritance and code reuse, and just thought “this is just a monoid and a bunch of crap because I didn't realise this is a monoid” so I rewrote the entire thing to about a third of the code size and ended up with double the flexibility. Shortly after I saw another file and this time thought “these are all just endofunctors,” and lo and behold, rewrote it to about a third of the code size and the final product being both easier to use and more powerful."
That would be so much more useful if it came with the examples.
Re: A Year of Functional Programming
#3Would you recommend starting with Scala before Haskell if one want to learn FP?
Re: A Year of Functional Programming
#4Would you recommend starting with Scala before Haskell if one want to learn FP?
No. Actually it would be easier to learn Haskell without knowing any imperative language at all. For me Scala also was "gateway drug to Haskell" and after using Haskell for some time I got some good FP habits which made my Scala/JS/whatever code better.
Re: A Year of Functional Programming
#5" Recently I looked at some code I wrote 8 months ago and was shocked! I looked at one file written in “good OO-style”, lots of inheritance and code reuse, and just thought “this is just a monoid and a bunch of crap because I didn't realise this is a monoid” so I rewrote the entire thing to about a third of the code size and ended up with double the flexibility. Shortly after I saw another file and this time thought…
Exactly, 2/3 code reduction sounds so great that I would like to be able to see that.
Re: A Year of Functional Programming
#6Would you recommend starting with Scala before Haskell if one want to learn FP?
No. Scala does some interesting things, but it adds a lot of complexity in order to interact with typical JVM code.
Haskell doesn't have that kind of baggage, so at its heart it's a very very simple language (Lambda Calculus + algebraic datatypes + typeclasses). There are a bunch of extensions, but they can be mostly ignored while getting to grips with the basics.
Programming in Haskell can involve a lot of unfamiliar concepts like monoids, functors, monads, etc. but these are just the APIs used by libraries; the language itself doesn't care about them (except for "do" notation). Just like you don't need to understand design patterns to learn how Java works.
Re: A Year of Functional Programming
#7I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them.
One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops. This is never a big issue. Writing the same 4 line method -- which could have been abstracted with a monad -- 10 times in a 50-150K LOC project is never a big problem, and these methods rarely contain bugs. On the other hand, OO code is often easier to refactor and modify. Sometimes -- in Java for example -- dynamic linking combined with OO, lets you modify/add functionality without even re-compiling existing code. Heck, it let's you add and load new polymorphic type implementations at runtime. It is much more malleable than FP code.
Another is state management: yes, FP is one solution to the problem of managing state, especially in a multicore environment. But it is neither the only solution, nor is it the best. The Clojure solution of -- for lack of a better name -- "transactional" mutable state is simpler than the pure FP one, and just as safe. I.e. there are ways to make side-effects safe without restricting them so much that they become a nuisance (after all, all software, possibly with the exception of compilers, exists for the sake of its side effects).
Finally (and I've said this before on HN), a language like Haskell discounts the very useful choice of reasoning about your code after it runs, favoring, instead, all-upfront reasoning, often at the expense of facilitating the former. There are some domains where figuring everything up front is very important. Others, where trial and error is far more productive.
So pure FP increases code reuse, but of code that's not that important to reuse. It helps deal with the hard problem of state management, but other, simpler solutions exist. Finally, it makes it hard to "feel" how your code runs, to debug it, to profile it, and more. I think it is based on the premise that if programming could be made more formal -- more mathematical , if you will -- it will become easier/"better". But that premise has not been shown to be true. The lack of magically bug-free, FP OSs, drivers, control software, and large applications, shows that even the biggest supposed benefits of languages like Haskell, are yet to be demonstrated in the real world.
EDIT: Just to clarify: Unfortunately FP does not have a definition, so, when I was saying "FP", I meant "FP as the article's author practices", which means "statically typed, pure FP". FP using Java streams, FP in Clojure/Erlang, and FP in Haskell mean very different things.
Re: A Year of Functional Programming
#8I used to like functional programming. Now I think that it's -- more often than not -- a solution in search of a problem. I can understand some of the things FP gets you (although those come at a cost, which I'll get to later); I'm just not so sure these are the things we need, or that FP is the best solution for them. One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it…
Wow, I sure have the opposite reaction to you. Makes me wonder what kind of code you wrote. Some specific points:
"One is code reuse: yes FP code is definitely more reusable. The problem is that the kind of code it enables reuse of more than OO is very small, simple loops."
Combinator libraries sure are pretty useful, and they're more than small simple loops.
"Writing the same 4 line method -- that could have been abstracted with a monad -- 10 times in a 50-150K LOC project is never a big problem"
All our goes code through a bunch of monads (mostly Future + Writer). Very puzzled how you're using monads if they only appear 10 times in 50KLOC.
"Another is state management"
I think you're referring to STM here. That's been extensively explored in the Haskell community.
Re: A Year of Functional Programming
#9Would you recommend starting with Scala before Haskell if one want to learn FP?
A 3rd "no" from here. Scala is unnecessarily complex because of the Java/JVM compatibility. It's not built from ground up on functional principles, but rather "augments Java" with functional features.
My recommendation is that start with Haskell or Scheme.
Re: A Year of Functional Programming
#10Would you recommend starting with Scala before Haskell if one want to learn FP?
[deleted]