←back to thread

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

(www.youtube.com)
296 points gyre007 | 2 comments | 17 Oct 19 10:10 UTC | HN request time: 0s | source
Show context
_han ◴[17 Oct 19 11:49 UTC] No.21281004[source]▶
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 collection, you name it. FP will always occupy a niche because of where it sits in the abstraction hierarchy. I'm a real time graphics programmer and if I can't mentally map (in rough terms, specific if necessary) what assembly my code is going to generate, the language is a non-starter. This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

replies(29): >>21281094 #>>21281291 #>>21281346 #>>21281363 #>>21281366 #>>21281483 #>>21281490 #>>21281516 #>>21281702 #>>21282026 #>>21282130 #>>21282232 #>>21283002 #>>21283041 #>>21283257 #>>21283351 #>>21283424 #>>21283461 #>>21285789 #>>21285877 #>>21285892 #>>21285914 #>>21286539 #>>21286651 #>>21287177 #>>21287195 #>>21288087 #>>21288669 #>>21347699 #
journalctl ◴[17 Oct 19 16:01 UTC] No.21283424[source]▶
Unless you’ve written a modern, optimizing C/C++ compiler, you have absolutely no idea what kind of machine code a complex program is going to spit out. It’s not 1972 anymore, and C code is no longer particularly close to the metal. It hasn’t been for some time.
replies(2): >>21283537 #>>21283627 #
Crinus ◴[17 Oct 19 16:13 UTC] No.21283537[source]▶
This is wrong, you absolutely can have an idea of what a C (and most of the time, C++) compiler will generate. You may not know the exact instructions, but if you are familiar with the target CPU you can have a general idea what sort of instructions will be generated. And the more you check the assembly that a compiler generates for pieces of code, the better your idea will be.

Note that you almost never need to care about what the entirety of a "complex program" will generate - but often you need to care about what specific pieces you are working on will generate.

The C language itself might be defined in terms of an abstract machine, but it is still implemented by real compilers - compilers that, btw, you also have control over and often provide a lot of options on how they will generate code.

And honestly, if you have "absolutely no idea what kind of machine code" your C compiler will generate then perhaps it it will be a good idea to get some understanding.

(though i'd agree that it isn't easy since a lot of people treat compiler options as wells of wishes where they put "-O90001" and compiler developers are perfectly fine with that - there is even a literal "-Ofast" nowadays - instead of documenting what exactly they do)

replies(2): >>21283652 #>>21285460 #
1. undershirt ◴[17 Oct 19 19:19 UTC] No.21285460[source]▶
From: https://queue.acm.org/detail.cfm?id=3212479

> Compiler writers let C programmers pretend that they are writing code that is “close to the metal” but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language

replies(1): >>21289912 #
2. Crinus ◴[18 Oct 19 09:43 UTC] No.21289912[source]▶
That article relies on the flawed premise that because modern CPUs do not expose their real inner workings then C is not a low level language. However this is irrelevant because as a programmer you do not have any access below what the CPU itself exposes - if the CPU exposes an API (its instruction set) that pretends to be serial then it doesn't matter if underneath the seams things happen in parallel since you simply are not given any control over that. From the perspective of someone who is working against such an instruction, C is a low level language since there is little lower level between it and what is exposed to the programmers by the CPU.

Beyond that it doesn't really invalidate anything i wrote and is only tangentially relevant to my comment (where i didn't even mentioned C as a low level language, i only said that you can have an idea of what sort of instructions a C compiler will generate for a piece of code if you study its output for a while), why did you post it without any comment of your own?