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

71–80 of 112 posts

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

#71

Post by marshray »

tptacek wrote: post #15
tumult wrote: post #13

Earlier quoted context omitted.

The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural pro…

I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.

I believe there have been functional programming contests where the language used by the winners was the functional subset of C, which as you would expect includes C functions.

But the term "FP" is as much about freedom from side effects, lambdas, currying, and sometimes lazy evaluation as it is about the superficially-similar functions in a typical imperative language.

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

#72

Post by marshray »

klez wrote: post #8
stmartin wrote: post #5

This is the lie that every functional programmer has perpetuated for the last 50 years since the dawn of Lisp - that somehow, automagically, productivity or effectiveness of programmers increase with the use of functional languages. It's the biggest lie in the programming world, and it was designed to make the uber-geeks of this world, those people that you walk around the block just to avoid saying hello to because…

I'm not a FP-fan boy (yet), but it seems you have a very limited view of FP. It's not just recursion...

I assure you, it's recursion all the way down.

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

#74

Post by dustingetz »

Cushman wrote: post #36
Spyro7 wrote: post #31

Earlier quoted context omitted.

"I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is." Thank you for your thoughtful reply. I really do appreciate it. It isn't the programming that is the hard thing. Writing some code to do something meaningful is not what is giving me a problem. Actually, it is trying to develop a deep understanding of functional programming that I am f…

Maybe the problem is that I am confusing functional programming with purely functional programming? Yeah, you nailed it. Writing a whole program with purely functional constructs is a little mind bending, since procedurally fundamental things like "printf" don't really exist. But that's just something that's much easier to do procedurally; it's hard for everyone, and there's no real secret to understanding it. The im…

+1. I fat thumbed you and downvoted, so sorry!

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

#75

Post by dpritchett »

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

i speculate the edge compounds as, say, a competitors java codebase's complexity increases faster than a lisp codebase. exponentiate this over time and the edge is obvious.

The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

http://www.paulgraham.com/avg.html

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

#76

Post by jberryman »

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…

I don't know if FP will appeal to you or make your life easier, but why not spend a couple weeks learning Haskell and see? Try "learn you a Haskell" or the Real World Haskell book (both excellent and free online).

I'm a fucking music major and figured it out pretty well. I'm sure you'll have no problems if it's something you're actually interested in learning about in your free time.

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

#77

Post by jberryman »

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…

> 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.

I feel that OO the paradigm is rickety, a marrying of ad hoc semantics and syntactic sugar, and that it is inherently limited.

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

#79

Post by nandemo »

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…

Of course, most of useful software involves input and output and state. Functional programming doesn't preclude that. There are compilers, package managers, documentation systems, etc, written in Haskell. They all use files and databases. Of course, your programs have to be designed differently.

For reference, here's is a talk by Don Stewart et. al about the design of XMonad:

http://www.scribd.com/doc/19503176/The-Design-and-Implementa...

I guess if one can write a window manager in Haskell, one can also write a todo list.

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

#80

Post by richcollins »

dasil003 wrote: post #2

The thing that got me really interested in learning Haskell was the realization that something like 90% of the nasty bugs that I fixed in production over the years would be have been impossible in a pure functional language. The thing that slows me down is the prospect of actually getting paid to write Haskell, and my doubts about it's ultimate suitability for iterate-quickly, fail-fast software world. But reading th…

They might have been impossible but how long would it have taken to write the functional code vs write the code with side effects and fix the bugs?
Post reply on HN