Why Isn't Functional Programming the Norm? [video] • Hacker News Board

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

#191

Post by AnimalMuppet » Thu, Oct 17, 2019, 5:01 PM UTC

soulofmischief wrote: post #147

strangenessak wrote: post #19

Earlier quoted context omitted.

> personally I find my brain works very much like a Turing Machine Exactly this. How baking a cake in FP looks like: * A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes. * A preheated oven is an oven that has been heated to 175 degrees C. * A prepared cake is batter that has been poured into prepared pans, where ba…

> In any case the point is this: I had some straight imperative code that was doing the same thing several times. In order to make it generic I couldn’t just introduce a loop around the repeated code, but I had to completely change the control flow. There is too much puzzle solving here. In fact I didn’t solve this the first time I tried. In my first attempt I ended up with something far too complicated and then just…

"It doesn't fit the way I think" != "I'm too stupid or lazy to figure it out".

And why should s/he do so? Between the language and the programmer, which one is the tool? Should not the tool fit the human, and not the other way around?

FP fits the way some people think. It doesn't fit the way others think. And that's fine. It's not a defect that some people think that way, and it's not a defect that some people don't.

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

#192

Post by grumpyprole » Thu, Oct 17, 2019, 5:14 PM UTC

Scarbutt wrote: post #181

tick_tock_tick wrote: post #158

Earlier quoted context omitted.

They already said they were working in games. None of what you said applies to that field.

I would say "real time graphics" is one of the niches FP is not well suited for, most business software doesn't need to work at the level of the machine.

There is certainly prior art for complex games running smoothly in Haskell: https://wiki.haskell.org/Frag

This particular solution used functional reactive programming, essentially a composition of signal/event processing functions/automatons.

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

#193

Post by StreamBright » Thu, Oct 17, 2019, 5:24 PM UTC

weberc2 wrote: post #122

StreamBright wrote: post #113

Earlier quoted context omitted.

>> I would not advertise Python as a language with good IDE support nor package management. VS Code, VIM works for me. Conda or PIP also. Not sure what is missing for you. >> but not everything in the world is glue code I never claimed that. >> 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 Depends what you ne…

I use VS Code too, but dynamic typing means I have to deal with this sort of thing every day: https://mobile.twitter.com/weberc2/status/118275131245637632... Compared with, say, Go where I just hover the cursor. As for pip, you also need virtual environments to protect you from side effects, and even then, if you’re doing C interop you probably still have dynamic links to so files outside of your virtualenv. Our team…

>> Go is probably the best in class here

Sorry no offence but I do not want to write Go at all. If I want to use such a language I will use Rust with nicer features and better out of the box performance (see TechEmpower results), no GC and more safety (no memory corruption bugs or data races).

I am not sure if I am the one who paints himself into a corner.

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

#194

Post by rafaelvasco » Thu, Oct 17, 2019, 5:24 PM UTC

I feel it's because functional programming is not a general application methodology. It excels at several idioms that we use as programmers but I feel it's something more specialized and niche then OO programming. I personally use OO as a base and iterate from there, using Functional idioms where is applicable. Some classes of programs can be described in its entirety in functional terms, but they're a small portion compared to the whole. Everything can be expressed in OO idiom, even if it's not the optimum way; I don't know if the same can be said of Functional. Would like to know more;

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

#195

Post by proc0 » Thu, Oct 17, 2019, 5:49 PM UTC

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…

" the more interchangeable the components will be. It's like Lego blocks; "

This is precisely the reason why pure FP is prioritizing referential transparency. Even if objects are perfectly encapsulated, with enough complexity, because other objects will depend on that information, and because that information mutates and changes over time, this is bound to cause some errors.

Compilers can't check program correctness because of the halting problem, so FP aims to give the programmer some patterns + laws to help better reason across this "higher" dimension of moving parts.

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

#196

Post by doboyy » Thu, Oct 17, 2019, 5:57 PM UTC

hyperpallium wrote: post #45

ben509 wrote: post #27

Earlier quoted context omitted.

Was it a mistake, though? Languages have to be accessible to their audience, and Javascript caught on because of its relatively gentle learning curve. If SchemeScript hadn't caught on, it might have been that VBScript took over the web.

Insufficiently C-like languages get ignored, according to: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

Language designers and enthusiats will forever be disappointed at how many social and human factors are at play, which coincidentally, is a large part of the motivation for programming languages

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

#197

Post by McWobbleston » Thu, Oct 17, 2019, 6:11 PM UTC

cuddlecake wrote: post #186

flowerlad wrote: post #183

Functional programming is not new, it has been around for many decades. The reason it didn't catch on is because it doesn't map very well to how our brain works. Human brains are object oriented, so OOP is very easy to grasp. The real question is, why are people now taking a second look at functional programming. And the answer is Moore's law. Moore's law is coming to and end, and CPUs are not getting faster. Instead…

> Human brains are object oriented, so OOP is very easy to grasp. Can I cite you on this? Because I have only ever seen this explained in Programming 101, where Java is the language they teach. I wonder where this sentiment comes from. I imagine it came from marketing.

Yeah I've gotta be honest the first few times I was taught OOP I couldn't quite grasp the purpose. I like it now for encapsulation of state, but generally I find it much easier to deal with records + pure functions as building blocks.

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

#198

Post by HALtheWise » Thu, Oct 17, 2019, 6:13 PM UTC

One thing I haven't seen brought up in this thread yet is support for foreign language embeddability. For example, Python code is technically quite slow, but that often doesn't matter much because it is easy to write external functions in C or C++ that behave like normal Python functions. I imagine that it would be more difficult to embed C++ code into a language with strong functional gauruntees. In that sense, the performance of Python is close to the performance of the fastest language with the same paradigm, which is (with current compilers) better for imperative programs that are structurally more similar to how the CPU operates.

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

#199

Post by agentultra » Thu, Oct 17, 2019, 6:13 PM UTC

socksy wrote: post #185

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…

"End of the day, the computer is an imperative device, and your training helps you understand that." I mean... it's not though, is it? Some things happen synchronously, but this is not the same thing as being an imperative device. Almost every CPU out there is multi core these days, and GPUs absolutely don't work in an imperative manner, despite what a GLSL script looks like. If we had changed the mainstream programm…

Individual cores execute instructions speculatively these days!

Predicting how the program will be executed, even in a language such as C99 or C11, requires several layers of abstraction.

What most programmers using these languages are concerned about is memory layout as that is the primary bottleneck these days. The same is true for developers of FP languages. Most of these languages I've seen have facilities for unboxing types and working with arrays as you do. It's a bit harder to squeeze the Haskell RTS onto a constrained platform which is where I'd either simply write in C... or better, compile a subset of Haskell without the RTS to a C program.

What I find neat though is that persistent structures, memoization, laziness, and referential transparency gave us a lot of expressive power while giving us a lot of performance out of the gate. In an analogous way to how modern CPU cores execute instructions speculatively while maintaining the promise of sequential access from the outside; these structures combined with pure, lazy run time allow us to speculatively memoize and persist computations for more efficient computations. This lets me write algorithms that can search infinite spaces using immutable structures and get the optimal algorithm for the average case since the data structures and lazy evaluation amortize the cost for me.

There's a good power-to-weight ratio there that, to me, we're only beginning to scratch the surface of.

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

#200

Post by traderjane » Thu, Oct 17, 2019, 6:17 PM UTC

jackhack wrote: post #182

js8 wrote: post #142

Earlier quoted context omitted.

> FP will always occupy a niche because of where it sits in the abstraction hierarchy At some point in history, people stopped worrying about not understanding compilers, how they allocate registers and handle loops and do low-level optimizations. The compilers (and languages like C or C++) became good enough (or even better than humans in many cases) in optimizing code. The same happened with managed memory and data…

Some people stopped worrying about not understanding compilers. They're not working on drivers, realtime (esp where low lag & jitter are concerned such as motion control), or high performance software of all stripes, trying to squeeze the most out of the available hardware. It's all about choosing the right tool for the job, and there is no right tool for every job. A guy generating sales reports has very, very diffe…

Yes, the pickup truck has its uses, but when we talk about high-level vs low-level programming, are we debating about the sedan or the pickup truck?