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

361–370 of 417 posts

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

#361

Post by nineteen999 »

pjmlp wrote: post #352
nineteen999 wrote: post #304

Earlier quoted context omitted.

Well it depends on what side of the kernel/userspace boundary you are talking about doesn't it. While C for userland programs may need to conform to the operating system's libc and system call interface abstractions, on the other side of the syscall boundary is C code (ie. the kernel) that is indeed very "close to the metal".

Except that C's abstract machine is closer to a PDP-11 than an modern i7/ARM are doing. So unless you are doing PIC programming, that "close to the metal" is very far away.

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the MMU, GDT and IDT for x86), or via MMIO for modern busses/devices. The language doesn't necessarily "need" to have a complex model of the entire physical machine to be able to achieve all of those things. How much closer to the metal do you want to be?

You really want your programming language to have innate constructs for directly controlling the baggage the x86 CPU (or any other for that matter) brings with it? I don't.

You also want kernel code to be performant (ie. compiled by a decently optimizing compiler, of which there are many for C), allow you to disable garbage collection or be totally free of it so you can explicitly manage separate pools of memory. C ticks all those boxes which is why its still the most dominant and widespread language for OS kernel development nearly half a century since UNIX was first rewritten in C, and will be for years to come, like it or loathe it, and despite there being much more modern contenders (eg. Rust) which don't have the momentum yet.

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

#362

Post by Crinus »

gpderetta wrote: post #177
Crinus wrote: post #172

Earlier quoted context omitted.

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…

To be fair, most of the set of optimization parameters enabled for the various for -Ox, including x=fast, is usually documented. At least in GCC though, there are a few optimizations included in the various -O flags that have no corresponding fine grained flag (usually because they affect optimization pass ordering or tuning parameters).

Yes they are documented, though the documentation is really something like "-fawesome-optimization, enabled by default on -O3" and the "-fawesome-optimization" has documentation like "enables awesome optimization" without explaining much more than that.

And even then pretty much every project out there uses "-Ofast" instead of whatever "-Ofast" enables without caring about what it does or how its behavior will change across compilers.

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

#363

Post by Crinus »

undershirt wrote: post #210
Crinus wrote: post #172

Earlier quoted context omitted.

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…

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

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?

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

#364

Post by pjmlp »

nineteen999 wrote: post #361
pjmlp wrote: post #352

Earlier quoted context omitted.

Except that C's abstract machine is closer to a PDP-11 than an modern i7/ARM are doing. So unless you are doing PIC programming, that "close to the metal" is very far away.

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the…

C doesn't tick any box regarding:

- vector execution units

- out of order execution

- delay slots

- L1 and L2 explicit cache access

- MMU access

- register windows

- gpgpu

All of that is given access by Assembly opcodes, not C specific language features.

And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys.

The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones.

And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.

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

#365

Post by nineteen999 »

pjmlp wrote: post #364
nineteen999 wrote: post #361

Earlier quoted context omitted.

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the…

C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language…

Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell.

I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or FORTRAN77 to write your kernel.

I'm not even going to bother with your security comments, we all agree by now. There are plenty of people using C99 in embedded at least in userspace, even the Linux kernel uses some C99 extensions (eg. --std=gnu89 with gcc), and those FOSS UNIX clones have taken over the planet at this point in terms of smartphone adoption, data center servers etc. Despite the obvious flaws, this is still a better world to live in than Microsoft's proposed monoculture of the 1990's.

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

#366

Post by pjmlp »

nineteen999 wrote: post #365
pjmlp wrote: post #364

Earlier quoted context omitted.

C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language…

Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell. I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or…

None, including C, which makes it nothing special. Any compiled language can call into Assembly.

The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release.

As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVisor written in Go, on Amazon on top of Firecracker written in Rust, and on ChromeOS containers written in a mix of Go/Rust.

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

#367

Post by nineteen999 »

pjmlp wrote: post #366
nineteen999 wrote: post #365

Earlier quoted context omitted.

Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell. I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or…

None, including C, which makes it nothing special. Any compiled language can call into Assembly. The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release. As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVis…

> Any compiled language can call into Assembly.

So ... you're repeating what I already said.

Android -> Linux -> mostly C, and assembly

IOS -> Darwin -> XNU -> C/C++, and assembly

Hyper-V runs as a Windows Server role. Windows kernel is C, and assembly

gVisor runs on Linux -> C, assembly

Firecracker runs on KVM, which runs on Linux -> C, assembly

In every single thing you have listed, the closest thing to the "bare metal" is C, and assembly. THAT's what makes C special. Its level of adoption, ubiquity and accessibility. Not its spectacular lack of security risks.

Anyway, you have come a very long way from where the parent poster started which was:

  Most of the stuff people think of as being the "metal" in 
  C are, in many cases, virtual abstractions created by the 
  operating system.
To which I merely pointed out, on the other side of the interface layer is, most commonly C. And assembly.

Operating Systems design has to and is obviously evolving away from this. I disagree that we have reached "peak C" and that is going to decline before it gets bigger.

Unfortunately pjmlp many of the conversations we have start this way, and devolve into this. I don't think I'm going to bother again. I think one (or both) of us will just have to agree to disagree. Have a nice day.

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

#368

Post by jstimpfle »

pjmlp wrote: post #364
nineteen999 wrote: post #361

Earlier quoted context omitted.

Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the…

C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language…

> And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.

In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440

Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed languages, practicality of 90's business software development (C++/COM), practicality of dead commercial languages (Delphi + VCL).

Giving just endless lists of ancient buzzwords doesn't help.

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

#369

Post by jstimpfle »

pjmlp wrote: post #366
nineteen999 wrote: post #365

Earlier quoted context omitted.

Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell. I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or…

None, including C, which makes it nothing special. Any compiled language can call into Assembly. The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release. As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVis…

> None, including C, which makes it nothing special. Any compiled language can call into Assembly.

I wish you joy and entertainment interfacing your managed data structures with assembly code.

Yesterday I was forced to look into COM for the first time. There was some kind of callback that I was interested in, and it had basically two arrays as arguments, only in a super abstract from. I'm not lying, it was 30 lines of code before the function could actually access the elements in the arrays (with special "safe" function calls to get/set data).

Of course, that stupid callback had to be wrapped as a method in a class, and had to be statically declared as a callback with a special macro that does member pointer hackery, and that has to be wrapped in some more BEGIN_MAP/END_MAP (or so) macros. Oh yeah, and don't forget to list these declarations in the right order.

Thanks, but that's not why I wanted to become a programmer.

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

#370

Post by AlchemistCamp »

hootbootscoot wrote: post #168
agentultra wrote: post #119

Earlier 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…

> 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.

Post reply on HN