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

391–400 of 417 posts

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

#391

Post by bernawil »

AlchemistCamp wrote: post #370
hootbootscoot wrote: post #168

Earlier quoted context omitted.

OTOH, think of the vast hordes of new developers exposed to lot's of FP and NOT having that background in Amiga and PC and bare-metal programming that you do. FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. Let that sink in. End of the day, the computer is an imperative device, and your training helps you understand that. FP is a perfectly viable high-level specificat…

> FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. JavaScript's use of more and more functional patterns came with Underscore.js and CoffeeScript, which were both inspired by Ruby-based web dev! I'd say the entire industry, Java included, has been moving towards more FP in a very sluggish fashion.

Having first-class functions and closures was the can of worms. How much you can get done passing callbacks is what got me wondering how much more stuff is there to learn in FP.

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

#392

Post by nybble41 »

ummonk wrote: post #315
nybble41 wrote: post #229

Earlier quoted context omitted.

> Oh - and why not pass a function in and return one back The "function" in "functional programming" is a reference to mathematical functions. Mathematical functions do not have side effects, and consequently are referentially transparent (the result doesn't depend on the evaluation order or on how many times the function is evaluated). Code with side effects is not a function in the mathematical sense, it's a proced…

You could write pure code in JS. You'd just need a linter to enforce it.

You can write pure code in almost any language, though some make it easier than others with features like lexical closures and algebraic data types. But is that the idiomatic form? Is it evaluated efficiently? And can you count on libraries to be written the same way?

Javascript without any support for mutation or other side effects wouldn't really be recognizable as Javascript any more.

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

#393

Post by socksy »

dragonwriter wrote: post #294
cesarb wrote: post #293

Earlier quoted context omitted.

> but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days The interface to the CPU is imperative. Each core (or thread for SMT) executes a sequence of instructions, one by one. Even with out-of-order and speculation, the instructions are executed as if they were executed one by one. > and GPUs absolutely don't work in an imperative manner, despite what a GLSL…

> The interface to the CPU is imperative. Each core (or thread for SMT) executes a sequence of instructions, one by one. Even with out-of-order and speculation, the instructions are executed as if they were executed one by one. That is, in the traditional model of declarative programming, the semantics given are guaranteed, but the actual order of operations are not. So, in a sense, the CPU takes what could be constr…

Exactly my point. With out of order execution, we execute as if they are in order, making sure that an item with a dependency on the outcome of another is executed in the correct order.

We end up having to rely heavily on compilers like LLVM which make boil down exactly what should depend on what, and how to best lay out the commands accordingly.

Imagine if the dominant programming style in the last few decades had been a declarative one. We wouldn't have had any of this nonsense about working out after the fact what depends on what, we could have been sending it right down to the CPU level so that it could deal with it.

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

#394

Post by BoiledCabbage »

blub wrote: post #359
Supermancho wrote: post #295

Earlier quoted context omitted.

Once parallel execution became part of every design discussion that had a performance concern, the vast majority of programmers stopped caring (and consequently talking) about compilers. Who cares if you can do 36k requests/s to my 18k if I can do 36k across 2 or 3 machines? I pass that on to the customer. Why try to hire for or wait around for an optimization trick to double performance (that will likely never be re…

You're simply used to working in environments where technical excellence doesn't exist. In such environments performance is not a big concern, but neither is quality in general...

Over-indexing on performance has nothing to do with technical excellence. It having the the wrong priorities.

Saying people who don't optimize for performance don't have technical excellence is just like saying people who don't get all of their program to fit into 32kb don't have technical excellence.

Yes it requires skills to get a program to run in such a small amount of space, just like it takes skill to perform detailed performance optimizations. But in either case if that's not your job you're wasting time and someone else's time, even if it makes you happy to do so.

A product is designed to serve a purpose, if instead of working on that purpose is developer is squeezing out a few additional cycles of perf or a few additional kb of memory they have the wrong priorities.

No that doesn't mean go to the other extreme, but choosing to not spending unnecessary time on performance or size optimization is entirely unrelated to technical excellence. And any senior engineer knows this.

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

#395

Post by hiccuphippo »

bryanphe wrote: post #143
_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…

In terms of performance, the way we build applications today is such a low bar that IMO it opens the door for functional programming. Even if it is not as fast as C or raw assembly - if it is significantly faster than Electron, but preserves the developer ergonomics... it can be a win for the end user! I created an Electron (TypeScript/React) desktop application called Onivim [1] and then re-built it for a v2 in OCam…

Does Revery use a native toolkit (winforms, gtk, etc) or is it also a webview like electron?

I've seen a couple of gui toolkits in rust following the Elm architecture and I think it's an amazing idea. It would be great if I was able to create apps like this using something like Qt behind the scenes.

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

#396

Post by lonelappde »

classified wrote: post #88
_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 regularly read the assembly output of the OCaml compiler I'm using and there are very few surprises. The mapping from source to generated assembly is quite straightforward. You couldn't say the same for Haskell, though. So it depends on which FP language you're using.

Wrong metric. It's not the mapping that matters, it's the assembly that matters.

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

#397

Post by lonelappde »

Bjartr wrote: post #261
OskarS wrote: post #188

Earlier quoted context omitted.

I don’t think you need to go that low level. I find it much easier to optimize around things like memory layout, allocation patterns and cache effects even in Java and C# compared to (essentially) any functional language. I think this is just a feature of imperative languages over functional ones. Functional languages are excellent for many things, but not for this stuff.

Where should I look to learn about doing those things in Java? Last time I tried looking for guidance I mostly found people saying it's not worth the effort since the JVM JIT will do better.

This thread is for people who are smarter than compilers. Java is not different from C in that regard.

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

#398

Post by hyperpallium »

ummonk wrote: post #317
hyperpallium wrote: post #21

Earlier quoted context omitted.

Even in maths, I find a solution in terms of the problem easier to understand than one in terms of the previous step. Even when the recursive form is a more natural representation, like arithmetic sequences: start at s , increase by d with each step: a(0) = s, a(n) = a(n-1)+d a(n) = s + n*d The analytical form seems simpler, neater, more "right" and more efficient to me - even though, if you want the whole sequence,…

This doesn't look to me like the difference between functional and imperative so much as the difference between recursion / iteration and map / list comprehension.

You may need to exercise some charity here.

I've been trying to see why fp isn't intuitive for me.

I suspect it's like a second (human) language acquired as an adult: only those with a talent for language (maybe 5%?) can become fluent with practice.

Regarding my first example, I see recursion (or induction) as the essence of fp; and the recurrence form of arithmetic sequences is the simplest recursion I've seen used in mathematics.

The explicit form in that example is harder to justify as "imperative". But a commonality of imperative style is referring to the original input, rather than a previous step (see the first line of my above comment). This isn't the literal meaning of "imperative", but may be a key distinction between fp and ip style - the one that causes the intuitive/fluency issue for me.

To illustrate using my third (jq) example of suffixes, here's an "imperative" version, in py-like psuedocode:

  for i = 1 to length
    # a suffix
    for j = i to length
      print a[j]
    print \n
This is so much longer than jq (though shorter if used .[j:]), but it is how I understand the problem, at first and most easily.

It always refers to the starting input of the problem, not the previous step, and this might be why it's easier for me.

I'm interested in your comment - could you elaborate please? There's a few ways to relate your comment to different parts of mine, and I'm not sure which one was intended.

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

#399

Post by Hercuros »

jjav wrote: post #211
xamuel wrote: post #152

Earlier quoted context omitted.

>I suspect I'm just not smart enough Nah, I have a PhD in math and I agree with you completely. Imperative is way better. And most mathematicians agree with me. You can see this by cracking open any actual math or logic journal and looking how they write pseudocode (yes, pseudocode: where things like performance don't matter one tiny little bit). You'll see they're almost entirely imperative. Sometimes they even use…

Agreed. I arrived at programming through math (B.S. in Mathematics) and have no love for FP. At the end of the day all software (except hobby projects) is mostly about maintaining it. FP adds unnecessary complexity, abstraction and obfuscations. None of those qualities help code maintenance.

Is this view of FP based on actual experience maintaining a non-trivial program written in an FP language? In my experience, FP doesn’t necessarily add a lot of unnecessary complexity. Sure, languages like Haskell are perhaps initially a bit more abstract when learning them, but once you know the basics, you can write pretty straightforward code in it. You can also do crazier things, but there is no need for that in most software.

Keeping a functional style, regardless of the language (although FP languages lend themselves better to this) can help in keeping code more decoupled, since you have to be explicit about side effects.

I think that both FP and imperative languages have places where they shine, and I freely switch between them depending on the project. Given how much some imperative languages have recently borrowed from FP languages, I think that this shows that functional programming has some significant merits.

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

#400

Post by cannabis_sam »

cryptica wrote: post #115

OOP was designed to prioritize encapsulation at the expense of referential transparency. Functional programming was designed to prioritize referential transparency at the expense of encapsulation. You cannot have referential transparency and encapsulation at the same time. In order to prevent mutations (which is a requirement of FP), a module cannot hold any state internally; this necessarily means that the state mus…

Encapsulation is trivial in FP tho.
Post reply on HN