A Year of Functional Programming • Hacker News Board

Re: A Year of Functional Programming

#31

Post by Xurinos » Mon, Jun 09, 2014, 12:50 PM UTC

analog31 wrote: post #13

Ask HN: As somewhat of an old timer, I have a couple of questions about FP, not really worthy of creating their own thread: 1. I learned a rule (in my Pascal textbook), "avoid globals." Is FP just an embodiment of that principle? 2. I do a lot of programming involving hardware, often homemade. Hardware has state, such as whether a lamp is turned on or off. Does this just mean FP is inappropriate, or are there techniq…

1. I think we should challenge the definition of "global variable". In what context is the variable global? The traditional definition is that the context is the whole program. However, in imperative OOP [1] code, I find that people just learned to hide their global variables in class instances. The whole program cannot access them, right? but every method in the class can and does, and all those mutations and side effects can lead to the kind of spaghetti code we all hated when there was no OOP. It's just global variables with extra sugar. And we can make copies of them, so the code is maybe one step better.

Imperative OOP often feels like one is pivoting behavior around the data.

FP feels like the data is flowing from one transformation to the next.

There is the "functional" part of it, too... where functions are highly composable. One creates new functions by combining old functions, and these may carry along with them important context (closures).

2. From what I've learned of Haskell -- and I'm a Haskell noob -- it lets you work with the side effecty real world. You can alter your hardware state. The key is that it specifically flags such side effects and encourages separation between more "pure" code and code that is "tainted" with the side effects.

[1] OOP is an abstraction and compatible with pure FP. You can model your class instances such that they are immutable and get all the benefits of OOP. FP contrasts better with imperative programming.

Re: A Year of Functional Programming

#32

Post by platz » Mon, Jun 09, 2014, 12:57 PM UTC

VLM wrote: post #11

chriswarbo wrote: post #6

Earlier quoted context omitted.

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 unfamilia…

And yet that complex JVM interaction makes one possible way to "get toes wet" is to wrap existing lower level java processes (and libraries and things) in a larger functional wrapper. Top down. Assuming you have some experience, confidence, or sample code in java that you can use or understand in the problem domain. So rather than trying to find a way to use recursive functional definition of a factorial in your code…

Because Scala is a hybrid language, I feel it doesn't really try to teach FP, but some amalgamation of the two. So you'll end up thinking about case classes, traits, companion objects, unapply, etc... it's a way to solve problems in a unique way, but in comparison with the other more traditional FP languages, it doesn't present the same feel and can obscure which features are the ones necessary for FP - which is important to know if you're specifically trying to learn FP.

Re: A Year of Functional Programming

#33

Post by pron » Mon, Jun 09, 2014, 12:57 PM UTC

tegeek wrote: post #30

pron wrote: post #7

I 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…

I think you are describing extreme cases for the FP. Can you please provide one example how would you abstract away problems solved via Map, Reduce, Filter, List Comprehension, Pattern Matching, Partial Application and Currying using any OO language (say Java)? Filtering, transforming data takes a lot of code in any data driven app. You start trimming the code from the day 1 in any FP enabled language without even th…

Again, I was referring to that type of FP the author was talking about, i.e. the one practiced in Haskell/scalaz. Everything you mention is useful. But just to play devil's advocate for a second, the mere fact that something is useful does not always mean that it's worth its price. So whenever you give me a "solution" you first have to demonstrate the magnitude of the problem and the price I have to pay elsewhere. Simple map and reduce operations certainly have a non-negligible utility (more readable code, better reuse), and they do come at a low cost. But elaborate type systems and restriction of side effects cost a hefty price, so they need to justify their use a lot more than just show that they're useful.

Re: A Year of Functional Programming

#34

Post by noelwelsh » Mon, Jun 09, 2014, 1:09 PM UTC

pron wrote: post #29

noelwelsh wrote: post #27

Earlier quoted context omitted.

I don't agree with your definition of FP then. Erlang is broadly the same as Clojure: pure in the small but stateful in the large (mailboxes in Erlang store state). Your basic argument seems to come down to Haskell (the only pure statically typed language with any widespread adoption) vs any other language. That's not an argument I'm particularly interested in. As for OO vs FP in combinator libraries -- the same patt…

I agree with every word. Alas, 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.

Agreement with someone on the Internet? o.O

;-)

[To the downvoters: this is me replying to the conversation I've had in the previous posts in this thread. If you can't handle my surprise and happiness at reaching some agreement hit up 4chan.]

Re: A Year of Functional Programming

#35

Post by outworlder » Mon, Jun 09, 2014, 1:14 PM UTC

cageface wrote: post #28

pron wrote: post #7

I 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…

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. I've been reading religious advocacy of FP for almost 15 years now and yet there still don't seem to be many non-trivial apps written in any of these languages. Certainly many individual features of FP have bee…

> and yet there still don't seem to be many non-trivial apps written in any of these languages

Perhaps you are not looking hard enough? Sure, if your problem space is CRUD web apps, then you won't find many implementations. Try looking into more difficult problem spaces, such as high-frequency trading, and you'll suddenly find more FP examples.

Also, there's Erlang, which was developed by Ericsson to solve a very specific, real-world problem. Look it up.

Re: A Year of Functional Programming

#36

Post by outworlder » Mon, Jun 09, 2014, 1:19 PM UTC

Kiro wrote: post #3

Would you recommend starting with Scala before Haskell if one want to learn FP?

If you want to focus on FP and not worry about the existence of libraries, I'd say to go with Clojure. The learning curve is not that steep and it's a very pragmatic language.

Re: A Year of Functional Programming

#37

Post by Touche » Mon, Jun 09, 2014, 1:19 PM UTC

pron wrote: post #33

tegeek wrote: post #30

Earlier quoted context omitted.

I think you are describing extreme cases for the FP. Can you please provide one example how would you abstract away problems solved via Map, Reduce, Filter, List Comprehension, Pattern Matching, Partial Application and Currying using any OO language (say Java)? Filtering, transforming data takes a lot of code in any data driven app. You start trimming the code from the day 1 in any FP enabled language without even th…

Again, I was referring to that type of FP the author was talking about, i.e. the one practiced in Haskell/scalaz. Everything you mention is useful. But just to play devil's advocate for a second, the mere fact that something is useful does not always mean that it's worth its price. So whenever you give me a "solution" you first have to demonstrate the magnitude of the problem and the price I have to pay elsewhere. Si…

You really should have said this from the start. Instead of:

> I used to like functional programming.

you should have said

> I used to like Haskell.

It's caused a lot of confusion in this thread. Also, I think it's unfair to compare Haskell vs. Every Other Programming Paradigm. Because by doing so you are only picking and choosing parts of other paradigms which work as well as the Haskell equivalent and not judging the whole of Haskell vs. Language X.

Re: A Year of Functional Programming

#38

Post by SeanDav » Mon, Jun 09, 2014, 1:19 PM UTC

Not at all trying to diss the OP, who wrote an interesting article, but if anything, this has put me off FP a bit. It really does seem like a lot of effort to go through for unclear benefits.

I have no doubt that learning FP will make me a better programmer (so perhaps it is worth it for that alone) but it seems to me I should rather spend those hours learning more data structures, or algorithms or machine learning.

Not sure I get it.

edit: it appears partially to be a definition problem. Exactly what is meant by FP and in what language, is a large part of the question.

Re: A Year of Functional Programming

#39

Post by dkersten » Mon, Jun 09, 2014, 1:25 PM UTC

piokoch wrote: post #5

jacquesm wrote: post #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…

Exactly, 2/3 code reduction sounds so great that I would like to be able to see that.

I, too, would like to see examples.

Though I will note that I recently saw some OO code written by a colleague that takes in a set of data names, runs a set of processes on them (translating the names to process-specific ids, fetching the data, turning it back into generic names) and then outputs it to one or more places. It was a pretty standard class hierarchy for reusing common code, selecting optional processing and so on. I've been spending a lot of time doing functional programming lately and would call myself a little bit of a functional programming enthusiast, so when I looked at the code, my first thought was that each of these parts are just functions that get passed into the appropriate places as higher order functions. Smaller, simpler and more flexible because you can customise what happens just by changing a function.

It occurred to me that when I think about problems in a functional programming mindset, there really isn't a need for crazy class hierarchies at all, because they're really just a dispatch mechanism for code reuse, but higher order functions acting on pure data structures handle 90% of this just fine with very little work. The other 10% are the complex cases that FP solves using fancier techniques like pattern matching (in the simpler cases) or multimethods or something similar in the complex cases.

Re: A Year of Functional Programming

#40

Post by mark_l_watson » Mon, Jun 09, 2014, 1:29 PM UTC

Nice article!

I have been using Clojure for years, initially because a repetitive customer mandated its use, later for my own projects because it reduced my development time and is fun to code in. I tried Scala (really liked Martin Odersky's Coursera class!) but it did not stick.

That said, Haskell has started to win my mind share. At least for my own projects I have been mostly using Haskell this year, with some bits of Ruby for quick text processing and munging. When my Haskell abilities improve I would like to start using it for small text processing utilities also.

Sometimes Haskell can be as frustrating as hell (yes, cabal, I am thinking of you). It can be frustrating also when writing a bit of useful code took a while because of the never ending (for me) learning curve. However when I am in the flow with Haskell, it feels like my 30+ years of Lisp experiences, but with a stronger language. It has become a cliche about Haskell's type system guiding you away from bugs, but it is true. I never had that feeling with Common Lisp and Scheme (but I have not tried strongly typed Racket yet).