Earlier quoted context omitted.
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…
They already said they were working in games. None of what you said applies to that field.
Why Isn't Functional Programming the Norm? [video]
181–190 of 417 posts
Re: Why Isn't Functional Programming the Norm? [video]
#182The 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…
> 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…
Michael Abrash (graphics programmer extraordinaire) said it best, and I'll paraphrase: the best optimizing compiler is between your ears. The right algorithm beats the pants off the most optimized wrong algorithm. Or, as i like to say "there is nothing faster than nothing" -- finding a way to avoid a computation is the ultimate optimization.
And managed memory is wonderful, almost all the time. That is, just until the GC decides to do a big disposal and compaction right in the middle of a time-sensitive loop causing that thing that "always works" to break, unpredictably, due to a trigger based on memory pressure. Been there, done that. If it's a business report or a ETL, big deal. If it's a motor-control loop running equipment, your data or machinery is now trash.
For most of the programming world, and I count myself in this group, the highly abstracted stuff is great. Right up until the moment where something unexpected doesn't work then it turns in to a cargo cult performance because it's nearly all black-box below. Turtles, all the way down.
There is value in understanding the whole stack, even today.
Re: Why Isn't Functional Programming the Norm? [video]
#183The 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 they are adding more and more cores. To take advantage of lots of cores you need concurrency. OOP is not very concurrency-friendly because objects have state, and to avoid corrupting state in a multi-threaded environment you need locks, and locks reduce concurrency. Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.
Re: Why Isn't Functional Programming the Norm? [video]
#184Earlier quoted context omitted.
Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.
The "oh no it's slow, and you can't reason about performance" FUD is mostly directed at Haskell's lazy evaluation, but people like to throw it vaguely in the direction of "FP" in general. Most of the performance problems you have in Haskell (as in this recent submission: https://news.ycombinator.com/item?id=21266201 ) are not problems you will have in OCaml. Yes, OCaml has garbage collection. It's a very efficient GC…
My usual issue with the 'you can avoid the GC by not allocating' claims in any language, is how much of the language is still usable? Which features of the language allocate under the hood? Can I use lambdas? pattern matching? list compression or whatever nice collection is available in the language?
Note that I do agree that even in very high performance/low latency applications, there will be components (even a majority of them) that will be able to afford GC without issues; but then it is important to be able to isolate the critical pieces from GC pauses (for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?)
Re: Why Isn't Functional Programming the Norm? [video]
#185Earlier quoted context omitted.
I too have been programming professionally for nearly two decades. Much longer if you consider the time I spent making door games, MUDs, and terrible games in the 90s. I think functional programming gives you powerful tools to reason about the construction of programs. Even down to the machine level it's amazing how amortized functional data structures change the way you think about algorithmic complexity. I think la…
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…
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 programming model years ago, perhaps chip manufacturers would have had more freedom to break free of the imperative mindset, and we could have radically different architectures by now?
Re: Why Isn't Functional Programming the Norm? [video]
#186Functional 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…
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.
Re: Why Isn't Functional Programming the Norm? [video]
#187Earlier 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…
Okay, so first of all this is an excellent joke. But it's not that great of an analogy. This quote chooses one of many FP syntaxes. It's cherry picking. It uses "a = b where c = d." That's equivalent to "let c = d in a = b." Let will allow you to write things like: let cake_ingredients = [butter, white sugar, sugar] batter = cream(ingredients=cake_ingredients, dish=large_bowl, condition=LIGHT_AND_FLUFFY) prepped_pans…
Re: Why Isn't Functional Programming the Norm? [video]
#188Earlier quoted context omitted.
Does OCaml give you enough tools to optimize around things like CPU-cache and memory management costs? It's one thing to know what kind of assembly is going to be produced by a block of code, but it's another thing to be able to get the machine to do exactly what you want.
If “to get the machine to do exactly what you want” is an important goal, I'd recommend C or C++. Those are well known tools for those purposes. FP languages are rather about getting more ideas from math into how you structure your code.
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.
Re: Why Isn't Functional Programming the Norm? [video]
#189Earlier 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…
> In computer science, imperative programming is a programming paradigm that uses statements that change a program's state.
All CPU's I know of are definitely imperative. My (limited) understanding of GPU instruction sets is that they are fairly similar, except that they use all SIMD instructions.
Re: Why Isn't Functional Programming the Norm? [video]
#190The 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…
> 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…
It's true that in many domains, people care much less about performance than they used to.
At the same time, other people care a lot more about performance. Programming is just big and diverse.
The end of single score scaling is one big reason it's more important than ever.
Another reason is simply that a lot more people use computers now, and supporting them takes a lot of server resources. In the 90's there were maybe 10M or 100M people using a web site. Now there are 100M or 1B people using it.
I think there's (rightly) a resurgence in "performance culture" just because of these two things and others. CppCon is a good conference to watch on YouTube if you want to see what people who care about performance are thinking about.
----
If you're writing a web app, you might not think that much about performance, or to be fair it's not in your company's economics to encourage you to think about it.
But look at the hoops that browser engineers jump through to make that possible! They're using techniques that weren't deployed 10 years ago, let alone 20 or 30 years ago.
Somebody has to do all of that work. That's what I mean by computing being more diverse -- the "spread" is wider.