Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Programming Is Hard, That's Why It's Good

dave.fayr.am

Post reply on HN
Print view View original

61–70 of 112 posts

Re: Functional Programming Is Hard, That's Why It's Good

#61

Post by mwexler »

Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"?

Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro Lisp and Hadoop, so I haven't had the deep dive indoctrination others appear to have had.

But as each new computing metaphor comes, we find ways to make it easy for folks trained in older metaphors to come over. Other than Scala, I've found few bridges that are trying to help procedural and OO lang folks adopt functional. It's no-one's fault, I guess, other than new folks are trained in it, and older folks aren't.

But I'll keep looking for that bridge, that shining one thing that will make me go "aahhha, I see" and not "one of these books will explain how passing this function through this multi-nested other function is better than just making a loop".

Because after all these articles, I know functional is great. I just feel bad that I haven't been able to make it great for me... yet.

Re: Functional Programming Is Hard, That's Why It's Good

#62

Post by andolanra »

ebiester wrote: post #49
dasil003 wrote: post #29

Earlier quoted context omitted.

You're making the same mistake that the Java loyalists did when Rails came out: judging something based on your distaste for the advocacy around it without any real understanding. I'm not going to pretend to know your motivations here, but often times people throw up this defense mechanism to protect their own professional knowledge; but here's the thing, that does nothing but stunt your own growth. Functional progra…

Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the…

Functional programming isn't just "no effects." There are many parts to functional programming: there's the idea of functions as the primary means of expressing data/information (as opposed to e.g. objects in OOP), the idea of functional purity (which is obligatory in Haskell but merely preferred in ML or Scheme), the various degrees of static type-safety, expressivity and power (e.g. Haskell with extensions is powerful but not always safe, Coq is safe and expressive but necessarily limited in power, Scheme is dynamically typed), as well as a handful of other concepts which appear from time to time. Even OOP isn't necessarily a conflicting paradigm, see OCaml or Common Lisp's CLOS system for the intersection of objects and functional programming. For more radical ideas, look at e.g. Functional Reactive Programming for functional data-flow programming.

w/r/t the specific side-effects in pure-functional programming: in Haskell, functions which perform effects are specially marked in the type system, so a function which performs side effects can call another one which performs side effects, but non-effectful functions can't unexpectedly induce effects. You end up writing programs with an effectful core for e.g. the manipulation of the db, and non-effectful functions for whatever processing you need to do with the data, with compile-time guarantees that the processing functions can be tested in isolation and won't cause exceptions or do unexpected IO.

Of course, you can write imperative code in a functional setting, and you can write functional code in an imperative setting. There's an old saying that bad programmers can write FORTRAN in any language; you can also write Lisp in any language, or Haskell in any language, with varying degrees of effectiveness or utility. Functional programming partisans—myself included—assert that functional techniques, correctly applied, can reduce errors (c.f. the Compcert C compiler) and simplify writing good code (c.f. the functional implementations of the Actor model of concurrency, parser combinators). I don't personally believe it to be a panacea, but it puts another tool in the toolbox for whenever your existing hammers aren't solving your problem.

Re: Functional Programming Is Hard, That's Why It's Good

#63

Post by anghyflawn »

kenjackson wrote: post #57

I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too." I'd really love to see the code for something that one would do in a day or two in Lisp, but wou…

Also speculating, but I would hazard a guess that a lot of that was due to the fact that the library ecosystem was much smaller then, which means people would be implementing things that you don't have to think too hard about now.

Re: Functional Programming Is Hard, That's Why It's Good

#64

Post by cageface »

thesz wrote: post #52
joe_the_user wrote: post #47

Earlier quoted context omitted.

All sorts of interesting stuff and then... ... OOP is inherently less useful that FP ... Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.

>Is it that hard to see different uses for different languages? Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2. Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hack…

As for C++, it's domain shrinks every year.

Mobile seems to be generating a resurgence of interest in C++. Squeezing every last bit of performance out of tightly constrained CPU and RAM matters again.

Re: Functional Programming Is Hard, That's Why It's Good

#65

Post by dustingetz »

mwexler wrote: post #61

Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"? Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro…

one of the cardinal rules of OO is: "each unit (method, object, whatever) should do exactly one thing"[3]. this rule is universally ignored in all the big OO codebases I've seen[1]. applying this rule with discipline, forces you to have a better understanding of what your code is actually doing. I think, that applying this rule even in OO languages forces you towards "functional-style in the small, object-oriented in the large", and the only difference is your code will have fewer classes/methods, and more high-level data-structures with operations like list.filter on them.

[1] i get it, refactoring takes discipline and time, and desire to practice and learn[2], and a team of like minded people, on top of sensible business constraints. [2] http://www.dustingetz.com/nostrademons-75h-work-week-harmful... [3] http://en.wikipedia.org/wiki/Single_responsibility_principle

edit: added source for single-responsibility principle

Re: Functional Programming Is Hard, That's Why It's Good

#66

Post by SamReidHughes »

dustingetz wrote: post #65
mwexler wrote: post #61

Ok, I've been a procedural programmer for years. I struggle even with OO. Where's my easy bridge to Functional? Where's the killer "here's the trick, the secret, the leap"? Because I have to say, for all the "functional will save you" mantras, I keep finding a procedural approach gets the problem solved. Are my problems too simple? Not scale issues? Perhaps. And clearly, I am not trained in anything other than intro…

one of the cardinal rules of OO is: "each unit (method, object, whatever) should do exactly one thing"[3]. this rule is universally ignored in all the big OO codebases I've seen[1]. applying this rule with discipline, forces you to have a better understanding of what your code is actually doing. I think, that applying this rule even in OO languages forces you towards "functional-style in the small, object-oriented in…

That's not a cardinal rule of OO or even a rule of OO.

Re: Functional Programming Is Hard, That's Why It's Good

#67

Post by Dn_Ab »

I see that some people are saying that functional programming is more powerful than OOP. I disagree with that.

I do not think one is less than the other. Actually there is a mathematical argument why one is not less than the other. To me functional programming is "what does what I'm trying to describe do?". In object oriented programming it's "what are the properties of the thing I'm trying to describe?". In functional programming I describe the interactions directly and in OOP the interactions come about from how I have described the objects. Done properly, they are both about interactions, it is just a difference of what you focus on.

It has been shown that classes of OOP can be modelled for the most part as co-algebras. This means that objects are a mathematical dual to algebraic types of functional programming. The reason why functional programming is important is that some things are easier to express in a dual space. This means that many things that are hard in OOP are trivial in functional languages. But the reverse is also true. This is why it is important to not drop one for the other.

The real advantage IMO in functional programming is that these languages tend to be developed with stronger mathematical foundations. Hence programming in them tends to encourage people to be principled and rigorous (at least in theory). It is very likely that if you study the subject you will naturally come to be interested in why monads are only one particular type of functor, that polymorphic functions are well described as natural transformations or try to wrap your head around mechanically generating dynamic algorithms in terms of hylomorphisms. The more mathematical nature also makes it less magical and rickety to the self taught programmer (such as myself). That I think is the real advantage. But there is nothing inherent in OOP that stops it from also being built from more rigorous foundations. Such things will come to matter more with increasing concerns in security.

I think functional programmers sleep on the power of coalgebras. In fact his example of google map reduce is completely ignorant of the fact that the real hero in MapReduce tm is unfold not reduce.

I have a pet theory that the fact that algorithms are written in dual styles is why experienced OOP people find functional programming so hard. They literally have to reverse their style of thinking. This takes a lot of energy. Just because it takes place in your head doesn't make it any less physical than trying to roll a boulder uphill or get a wagon wheel out of a rut.

http://www.cs.ru.nl/E.Poll/papers/durham97.pdf

Re: Functional Programming Is Hard, That's Why It's Good

#68

Post by KirinDave »

ebiester wrote: post #49
dasil003 wrote: post #29

Earlier quoted context omitted.

You're making the same mistake that the Java loyalists did when Rails came out: judging something based on your distaste for the advocacy around it without any real understanding. I'm not going to pretend to know your motivations here, but often times people throw up this defense mechanism to protect their own professional knowledge; but here's the thing, that does nothing but stunt your own growth. Functional progra…

Here's the problem I have with this: nearly everything I do involves state. It's called a database. Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task. Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the…

> It's called a database.

Programs have to have state and side effects to interact with the outside world. That's not what's frowned upon.

The goal with functional programming is to try and minimize the number of functions that involve those external transactions. The spine of your program in Haskell will revolve around IO, but all the limbs can probably avoid requiring anything more than inputs and outputs.

Perhaps a concrete example would help? Imagine parsing incoming HTTP requests on your TODO app. Ignoring streaming (which I think we can do safely in this case), your IO code is to read and write to the socket, but the intermediate code to parse the incoming request into data structures for inspection? That can and should NOT be dependent on I/O. Similarly, the code that actually generates your HTML output (before writing it to the socket) need not care about I/O.

Re: Functional Programming Is Hard, That's Why It's Good

#69

Post by richcollins »

kenjackson wrote: post #57

I'd really love to hear PG defend this line: "But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too." I'd really love to see the code for something that one would do in a day or two in Lisp, but wou…

It's not because they were using lisp. It's because everyone else was using C.

Re: Functional Programming Is Hard, That's Why It's Good

#70

Post by dustingetz »

Dn_Ab wrote: post #67

I see that some people are saying that functional programming is more powerful than OOP. I disagree with that. I do not think one is less than the other. Actually there is a mathematical argument why one is not less than the other. To me functional programming is "what does what I'm trying to describe do?". In object oriented programming it's "what are the properties of the thing I'm trying to describe?". In function…

i think the root problem here is out-of-band -- expertly written OO models are fine. the problem is that i've never encountered an expertly written OO system, which is probably because OO allows you to get lazy, where functional patterns require thought and understanding. i'm gradually starting to suspect that an expertly written OO system actually kinda looks like a functional system, except with practical compromises with respect to functional purity.
Post reply on HN