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

Why Isn't Functional Programming the Norm? [video]

youtube.com

Post reply on HN
Print view View original

321–330 of 417 posts

Re: Why Isn't Functional Programming the Norm? [video]

#321

Post by hinkley »

_han wrote: post #30

The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…

I had some truly dismal experiences with code generators in the 90's. At one point I blamed code generation itself, automatically dismissed any solution out of hand, and was proven right quite a few times.

It wasn't until I used Less on a project that I encountered a generator that did what I expected it to do in almost every situation. It output essentially what I would have written by hand, with a lot less effort and better consistency.

I expect people who adopted C felt roughly the same thing.

People presenting on OOAD occasionally warn about impedance mismatches between the way the code works and the way you describe it[0]. If what it 'does' and how you accomplish it get out of sync, then there's a lot of friction around enhancements and bug fixes.

It makes me wonder if this is impossible in FP, or just takes the same degree of care that it does in OO.

[0] a number of cow-orkers have 'solved' this problem by always speaking in terms of the code. Nobody has the slightest clue what any of them are talking about 50% of the time.

Re: Why Isn't Functional Programming the Norm? [video]

#322

Post by hechang1997 »

goatlover wrote: post #217
weberc2 wrote: post #105

Earlier quoted context omitted.

I would not advertise Python as a language with good IDE support nor package management. I fight with both of these regularly. Also, Python is reasonably suited for gluing together other high performance systems, but not everything in the world is glue code, and as soon as you need to do something O(n) on your dataset, you’re either paying an enormous performance penalty or you’re not writing that bit in Python. Peop…

> but not everything in the world is glue code, and as soon as you need to do something O(n) on your dataset, you’re either paying an enormous performance penalty or you’re not writing that bit in Python. And yet Python has one of the richest and most widely used scientific computing stacks. If writing performant code in a friendly language is all that important, then Julia stands as a more reasonable alternative tha…

That's exactly why people vectorize their code: to avoid slow loops in python and move them to the underlying c/cpp code.

Re: Why Isn't Functional Programming the Norm? [video]

#323

Post by mbo »

ukj wrote: post #308
mbo wrote: post #305

Earlier quoted context omitted.

Okay, so FP is more difficult to learn. Assume for the sake of this argument that FP has a tangible benefit over other paradigms, that manifest themselves at scale. You're tasked with educating students in this paradigm, but they complain that it is more difficult than the techniques that they are used to. What do you do?

I validate your assumption against reality. If FP is not mandatory at Google-scale, it isn’t mandatory at your scale. The kind of problems that emerge at scale are not the kind of problems FP tackles.

Sorry, I mean scale as in "large scale projects".

Spark is the quintessential Google-scale FP project - it was even born out of the MapReduce paper by Google!

And there's plenty of other large-scale projects that are arguably in an FP style specifically to deal with the problems associated with scaling them: the Agda/Isabelle proof checkers, the seL4 kernel, the Chisel/FIIRTL project, Erlang/OTP, the Facebook Anti-Spam system (built on Haxl), Jane Street's massive investment into OCaml, Twitter's investment into Scala.

Not all scale problems are distributed problems. Some distributed problems are tackled by FP, and some aren't. Ultimately, these large-scale projects pop up at similar rates to the usage of the language themselves. It's intellectually dishonest to say that FP can't be used to tackle large scale problems, and the problems that occur at scale, because its repeatedly validated that it can.

Re: Why Isn't Functional Programming the Norm? [video]

#324

Post by mbo »

Mirioron wrote: post #307
mbo wrote: post #305

Earlier quoted context omitted.

Okay, so FP is more difficult to learn. Assume for the sake of this argument that FP has a tangible benefit over other paradigms, that manifest themselves at scale. You're tasked with educating students in this paradigm, but they complain that it is more difficult than the techniques that they are used to. What do you do?

I don't know, because I'm not qualified for it. I had to pass a course on FP, but frankly, I wouldn't be able to do anything with it in practice, let alone teach it. My only personal experiences with it were negative. If it had been Haskell that was the entry level programming course, then I probably would never have learned to program.

Okay, so given this answer here's what I would do:

1) I wouldn't make it the entry level course. It's clearly a paradigm that's used by a minority of people, so it doesn't make sense to start educating students with it.

2) I mandate that all students take it, maybe in their 3rd year. We're going to mandate it because there are tangible benefits (which we've assumed for the sake of this argument). They're going to find it harder and more confusing because its's different to what they're used to. A lot of them may not like it and won't see immediate benefits. Some may even come to dislike it. Frankly, I don't care, some will pick it up and learn about it further. And when the students that disliked it inevitably run it into the future, they sufficiently prepared to deal with it.

We're back to square 1: forcing it down student's throats. If you still think that we shouldn't be forcing students to learn FP in schools, I think you have a problem not with FP but with structured curriculums.

Re: Why Isn't Functional Programming the Norm? [video]

#325

Post by hinkley »

lewisjoe wrote: post #6

Richard Gabriel’s famous essay “Worse is better” ( https://www.jwz.org/doc/worse-is-better.html ) is an interesting perspective on why Lisp lost to C. In a way, the same arguments (simplicity vs consistency vs correctness vs completeness) can be made for why functional programming lost to OOP. But those philosophical perspectives aside, personally I find my brain works very much like a Turing Machine, when dealing wi…

Lisp lost in a much more profound way recently, and it's very rare to see anyone mention it, especially on the Lisp side of the conversation.

Over the last 10 years or so, we have come to the painful conclusion that mixing data and code is a very, very bad idea. It can't be done safely. We are putting functionality into processors and operating systems to expressly disallow this behavior.

If that conclusion is true, then Lisp is broken by design. There is no fixing it. It likes conflating the two, which means it can't be trusted.

Re: Why Isn't Functional Programming the Norm? [video]

#326

Post by gmfawcett »

pyrale wrote: post #61
pas wrote: post #49

Earlier quoted context omitted.

Could you elaborate on this a bit? Basically calling a functions form an other is how a step-by-step algorithm would work in FP, no? And pattern match on what comes in, and return an immutable copy. For example you can put functions in a list, and push a datastructure through them, like a pipeline. edit: https://probablydance.com/2016/02/27/functional-programming-...

The control structure that takes the different functions/values and glue them together is what makes your code imperative or descriptive. While there is a lot of overlap between descriptive style and fp, it is not always the case. In haskell, for instance, the do notation lets you write imperative code: f article = do x ...and then the compiler desugars it to a more descriptive form.

In fairness, we could be in the List monad here, and this would effectively be a list comprehension rather than an imperative program. Even if we are in IO, `getPrices` and `book` may never execute --- even `finishDeal` may never execute! --- depending on non-local details that aren't shown here.

The code certainly "looks imperative" but it's still a declarative program --- the semantics are rather different from what a typical "imperative programmer" would expect.

Re: Why Isn't Functional Programming the Norm? [video]

#327

Post by petra »

mbo wrote: post #298
jasode wrote: post #281

Earlier quoted context omitted.

>Because I think it is harder for people who have programmed with other paradigms I still think there's something missing in your theory of cause-&-effect. A math topic like quaternions is hard and yet programmers in domains like 3d graphics and games have embraced it more than FP. I also think Deep Learning / Machine Learning / Artificial Intelligence is even more difficult than Functional Programming and it seems l…

> Why can't FP's benefits be obvious so that it doesn't require evangelists? Because there aren't immediate benefits. They only pop out at scale and with complexity, as I said. > similar real world massive productivity improvement to Imperative Programming Because there isn't. It's a reasonable benefit, but it's not transformative. I think it's there, enough to commit to FP completely, but the massive productivity im…

>> Because there aren't immediate benefits. They only pop out at scale and with complexity, as I said.

What about low-barrier situation with scale and complexity ?

An imaginary situation:let's say you start building your system from a large open-source project that needs a lot of customization.

Will FP be of big enough benefit than ?

I'm curios about the answer, but for a sec, let's assume it does:

Than could it be a uni project ? dig into the belly of 2 beast projects, one FP, one OOP. And see the difference in what you could achieve.

Could something like that work ?

Re: Why Isn't Functional Programming the Norm? [video]

#328

Post by gambler »

senderista wrote: post #292
gambler wrote: post #267

Earlier quoted context omitted.

What a coincidence. This sounds exactly like what happens with OOP. Every discussion here gets swarmed with clueless people who think Java is the apex of OO programming, because that's what gets taught in universities these days. They don't understand any of the core concepts that prompted Xerox Park to develop the OO paradigm in the first place. They aren't aware of any of the relevant research. They operate under t…

I think the Smalltalk paradigm is deeply defective and the Actor model (the purest form of OOP to my mind) remedies most of its faults but perpetuates some others. A few flaws: - Modeling all communication as synchronous message-passing. Some communication (such as evaluating mathematical functions) is naturally modeled as synchronous procedure calls, while communication which is naturally modeled as message-passing…

All of this has been addressed zillion times. Modern Smalltalk dialects have actor libraries and have code reuse mechanisms that don't involve inheritance. There are ways of doing static analysis on late-bound code. (Obviously, guarantees are not going to be the same. I take that as a reasonable trade-off.) OOP isn't predicated on mutable state and there are ways for the system to manage it anyway. (Although, to be fair - that is one thing from the list that hasn't been fully addressed in any practical OOP system I'm aware of.)

https://tonyg.github.io/squeak-actors/

http://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=123...

http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf

http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De...

http://bracha.org/pluggableTypesPosition.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134...

Even if none of the work I mentioned above existed, this sort of criticism is amateurish at best. Real engineering requires considering trade-offs in real-life contexts. For example, compile-time checks aren't going to help you figure out that some vendor supplies incorrect data via a web service. An early prototype, however, can do exactly that.

Re: Why Isn't Functional Programming the Norm? [video]

#329

Post by iLemming »

pnako wrote: post #287

Because it's not that useful. There is an contest organized by the International Conference on Functional Programming: https://en.wikipedia.org/wiki/ICFP_Programming_Contest It was more or less designed to show the superiority of functional programming languages. Yet in that contest C++ has done better than OCaml or Haskell... The FP crowd seems to be more active doing advocacy than writing code. Yes, we know, there…

Just because you don't see it, doesn't mean it's not happening.

- Have you ever heard about how Walmart handles Black Fridays?

- Do you even know what's behind Apple's payment system?

- You ever used Pandoc, Couchbase, Grammarly, CircleCI, Clubhouse.io, Pandora, Soundcloud, Spotify?

- Have you ever asked a question - what is an app like WhatsApp that was sold for $19 Billion runs on?

- or How Facebook fights spam, Cisco does malware detection or AT&T deals with abuse complains?

- How Clojure is used at NASA or how Microsoft uses Haskell?

Frankly, I don't even know what's there to debate about. Functional programming is already here and it's been used in the industry for quite awhile already and its usage growing in a quite steady pace. Almost every single programming language today has certain amount of FP idioms, either built-in or via libraries. So yeah, while you're sitting there, contemplating about if FP useful or not, people been building hundreds of awesome products.

Post reply on HN