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 OCaml / ReasonML [2] - compiled to native machine code. (And we built a UI/Application framework called Revery [3] to support it)

There were very significant, tangible improvements in performance:

- Order of magnitude improvement in startup time (time to interactive, Windows 10, warm start: from 5s -> 0.5s)

- Less memory usage (from ~180MB to <50MB). And 50MB still seems too high!

The tooling for building cross-platform apps on this tech is still raw & a work-in-progress - but I believe there is much untapped potential in taking the 'React' idea and applying it to a functional, compile-to-native language like ReasonML/OCaml for building UI applications. Performance is one obvious dimension; but we also get benefits in terms of correctness - for example, compile-time validation of the 'rules of hooks'.

- [1] Onivim v1 (Electron) https://github.com/onivim/oni

- [2] Onivim v2 (ReasonML/OCaml) https://v2.onivim.io

- [3] Revery: https://www.outrunlabs.com/revery/

- [4] Flambda: https://caml.inria.fr/pub/docs/manual-ocaml/flambda.html

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

I have a suspicion this is only semi-true.

For controlling what the CPU and RAM are doing? Yes. The graphics shader, on the other hand, is a pipeline architecture with extremely tight constraints on side-effects. The fact the shader languages are procedural seems mostly accident of history or association to me than optimal utility, and the most common error I see new shader developers make is thinking that C-style syntax implies C-style behaviors (like static variables or a way to have a global accumulator) that just aren't there.

The way the C-style semantics interface to the behavior of the shader (such as shader output generated by mutating specifically-named variables) seems very hacky, and smells like abstraction mismatch.

Not exactly shaders, but for GPGPU stuff, futhark [0] seems to show that a functional paradigm can be very good to produce performant and readable code.

[0] https://futhark-lang.org/index.html

> is a pipeline architecture with extremely tight constraints on side-effects

That was true 10 years ago. Now they're just tight constraints but not extremely so: there're append buffers, random access writeable resources, group shared memory, etc.

> The way the C-style semantics interface to the behavior of the shader seems very hacky

I agree about GLSL, but HLSL and CUDA are better in that regard, IMO.

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.

Ten years ago, that was the only substantial game written in Haskell. That you're citing that same game now is a bit telling.

Note the upload date:

https://www.youtube.com/watch?v=0jYdu2u8gAU

Ok here's a talk about making Haskell games that took place last week: https://keera.co.uk/blog/2019/09/16/maintainable-mobile-hask... I don't deny that making games in Haskell is niche, but it's certainly possible. Frag was just an example I remembered (ten years is recent for an old git like me).

If I remember correctly, in that thesis the author mentioned explicitly that the game didn't run very fast. If you watch the video from 2008, the in-game stats list framerates >60fps but the game itself is very laggy. Maybe there is a separate renderer thread?

Ironically the first CAD workstations were developed in Lisp, and Naughty Dog is famous for their Lisp/Scheme based engines.

Here's a talk on making real world commercial games with Clojure on top of Unity.

https://www.youtube.com/watch?v=LbS45w_aSCU

I think you are seriously overselling the talk, and what Arcadia is ready for.

you: Here's a talk on making real world commercial games with Clojure

video: dozens of game jam games have been made

come on, the "games" showcased here have the complexity level of a 2003-like game and they barely achieve 200 fps on modern hardware. When I look at similar trivial things ran with no vsync on my machine, it's >10000 fps

That's just moving goalposts. The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019. If you're doing triple-A game development, maybe you need to get down to the metal, but for tons of games you'll be perfectly fine with FP.

Also worth noting that the idea is to use FP around stuff like the actual game logic, and then handle rendering details imperatively.

> The games showcased are the same complexity as plenty real world commercial games that are making good money in 2019

I mean, fucking todo apps are making "good money" in 2019, it does not mean that they are good examples. These kind of presentations should improve on the state of the art, not content themselves with something that was already possible a few decades ago. No one gets into game dev to make money, the point is to make better things than what is existing - be it gameplay wise, story wise, graphics wise...

The Poker prototype could be from 30 years ago, and drops to 15FPS on any game action! Arcadia is a neat toy at this point, but run far away if you are looking to do real world commercial development.

Even assuming that that's true (and it very well may be), the general topicwasn't games, and there are many places where "the norm" in programming as a whole differs from the norm in performance sensitive areas.

Brilliant. Haskell was standing outside the door not until it was good enoguh to be an industry standard, but until industry standards dropped so low that it became competitive!

Hey, and good luck with revery :) I am doing something very similar but I wouldn't ever consider any GC language for the low-level part.

I want to write UI in javascript because it's really nice language for prototyping but I also want it to be fast and javascript is unpredictable. Now, this might not be the case with OCAML but no matter what optimizations your compiler (or JIT interpreter) can do, you're still living in a lie, it's still some abstraction which is going to leak at some point.

I've recently removed quite a lot of rust dependencies (wrappers) and the speedup is very noticable, it's because abstractions always come with a cost and you can't just pretend you're living in a rainbow world.

BTW: you're not going to get much lower than 50M, cocoa has some overhead (10M IIRC), node has too (20M) and OCaml GC needs some heap too, and if you have any images, you need to keep them somewhere before sending to the GPU and GC to be fast needs to keep some mem around so that allocs are faster than just plain malloc.

BTW2: in rust world, it's common to see custom allocators and data-oriented programming because it starts to get noticeable and this is hard to do if you can't reason about memory.

If anyone is interested too, here's a repo https://github.com/cztomsik/graffiti

I couldn't have said it better myself. Thx for those links! And, yes, the compiler's flambda variant is an exquisite delight.

Is it fast because native & types or fast because of other reasons? The speed hierachy I've found goes: dynamic types w/ GC = 8x slower than C, static types w/ GC = 3x slower than C & static types w/ hybrid memory management like reference counting = 2x slower than C.

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.

revery does custom rendering on GPU, just like flutter & switfui (and graffiti)

> 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 databases, and it will happen here, too. Compilers with FP will become good enough in translating to the machine code so that almost nobody will really care that much.

The overall historical trend of programming is more/better abstractions for humans and better automated tools to translate these abstractions into performant code.

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 different needs from the lady writing a rendering engine.

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.

> Some people stopped worrying about not understanding compilers.

But no, it's not some people, it's not most people, it's 99%+ of all developers that stopped worrying about compilers. There will always be a use case for it, but when we're talking about < 1% of all developers we're really spending time talking about a niche.

There will always be niches in any industry, but we shouldn't design our industry/profession about niche cases.

While I 100% agree with you, as a Java dev who is very interested in optimization (particularly register coloring) at a certain point I think you have to realize that any "compiler type" optimizations you do (Ooh, I'll optimize my variable declaration order to not spill to memory!) is just ignored and re optimized by most compilers worth their weight in salt. Therefore, it's totally counter productive. All the time spent worrying about GC lag is, IMO, wasted compared to other more productive things. I haven't programmed anything mechanical in over 6 years. Basically, for your average developer, while I highly recommend learning the whole stack, I don't believe the notion that understanding the whole stack will actually lead to tangible improvements for programmers. They'd be better served focusing purely on theory (and by theory I mean algorithms).

As a side note: I hate hardware, but I love graph algorithms, which is why I love register coloring so much :)

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?

well as always when discussing functional programming people are not discussing the merits of functional programming but rather the merits of basically throwing away objective programming in favor of functional programming. That is ofcourse complete nonsense but modern computer science politics like all modern politics only deals in absolutes

Programming is has grown so much as a field that generalizations like this rarely capture the truth.

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.

The point here is that for many domains performance is not the top consideration. And it's also worth noting that it's perfectly possible to tune applications written in FP languages to get very good performance. It's also possible to identify the parts of the code that are performance critical and implement those using imperative style. This is especially easy to do with Clojure where you have direct access to Java.

So, yeah if you're working in a niche domain where raw performance is the dominant concern, then you should absolutely use a language that optimizes for that. However, in a general case using FP language will work just fine.

Sure I get that, but I'm saying your statement about "the overall historical trend" is wrong, or at least fails to capture a large part of the truth.

At some point in history, people stopped worrying about not understanding compilers

This part is misleading too -- I would say there is a renaissance in compiler technology now. For the first 10 years of my career I heard little about compilers, but in the last 10, JS Engines like v8 and Spidermonkey, and AOT compiler tech like LLVM and MLIR have changed that.

The overall historical trend is that computing is getting used a lot more. So you have growth on both ends: more people using high level languages, and more people caring about performance.

It's not either/or -- that's a misleading way of thinking about it. The trend is more "spread", not everyone going "up" the stack. There will always be more people up the stack because lower layers inherently provide leverage, but that doesn't mean the lower layers don't exist or aren't relevant.

And lots of people migrate "down" the stack during their careers -- generally people who are trying to build something novel "up stack" and can't do it with what exists "down there".

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 realized or discovered) when there's business to be done? The post-optimization is pure profit and can be quantified, so might as well wait and let some specialist (who does care about compilers) handle it if the product ends up being valuable enough to hire them. This is how development and hiring works today.

> At some point in history, people stopped worrying about not understanding compilers

> This part is misleading too

Not in the least. Interpreting that to mean "all people stopped worrying" is deliberate misinterpretation.

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.

Except OP said quite clearly "stopped caring" and "no one cares". Bit of a stretch from that to your over-focusing...

> At some point in history, people stopped worrying

Did they ? Because I keep seeing people around me who want to get into FPGA programming because they aren't getting enough juice from their computers. Sure, if you're making $businessapp you don't care but there is a large segment of people who really really really really want things to go faster, with no limits - content creation, games, finance... hell, I'd sell a rib for a compiler that goes a few times faster :-)

Large as in 1 out of 1.000

The point is that to be mainstream it's enough to be used by one major app store

How many apps care about FPGA or what compilers do, given that they don't even know what the underlying OS does or when and why memory is allocated?

I work in finance, even there performances are for niche projects, the bulk of the job is replacing excel macros with something slightly less 90s style.

Fun fact: C used to be considered a high-level language. Now everyone talks about it being "close to metal" which to olds like me is a dead give-away the person either doesn't know C or doesn't know the "metal". Most of the stuff people think of as being the "metal" in C are, in many cases, virtual abstractions created by the operating system. Embedded development w/o dynamic memory allocation less so... but that's not what most people are talking about.

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.

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.

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.

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.

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

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

I have done it multiple times in the past calling Assembly via JNI, from Oberon, from Turbo Basic, from Turbo Pascal, from Delphi, from .NET.

C is not a special snowflake.

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

It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know?

Regarding show, don't tell.

The 21st century React Native for Windows is written on top of COM/C++,

https://github.com/microsoft/react-native-windows

https://www.youtube.com/watch?v=IUMWFExtDSg

We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html.

> It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know?

I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine.

> The 21st century React Native for Windows is written on top of COM/C++

From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective.

You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me.

If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.

ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.

I really don't know what kind of COM you have been writing, because COM from VCL, MFC, ATL, UWP, Delphi, .NET surely doesn't fulfill that description.

As for what COM is good for,

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

Maybe I was unclear, but it was a C++ program (dealing with macros, as I said - VARIANTS and DISP_IDs and PROPERTIES and stuff). No joy to use.

As for other languages, I haven't touched COM at all but the idea of making GUIDs for stuff and registering components in the operating system doesn't seem a good default approach to me. Pretty sure it's more reliable to link object files together by default, so you can control and change what you get without the bureaucracy of versioning, etc.

> ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.

Is the fact that COM is buried under this pile more than an unfortunate implementation detail?

99% of the time you can forget about them, but when you get performance problems then you need to start digging in to what goes on behind the scenes.

Some engineers have terminal systems brain. That's a rude way for me to say it, but I have met engineers who feel the need to fully understand how code maps to hardware otherwise they don't feel comfortable.

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.

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.

You can analyze Assembly code just like in any other AOT compiled language.

Have a go at in Godbolt, https://godbolt.org/

OCaml also integrates with perf on Linux,

https://ocaml.org/learn/tutorials/performance_and_profiling....

Some performance tips from an old partially archived page.

https://hackerfall.com/story/writing-performance-sensitive-o...

And if you are feeling fancy, doing some pointer style programming

https://ocaml.org/learn/tutorials/pointers.html

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

Rust on the other hand is zero-cost abstraction but pushes you to write functional code.

I absolutely can say that about Haskell. You have to actually learn the language, but it doesn't do anything unpredictable.

Actually I’ve found it pretty easy to track / reason about. But I guess I do have a decent mental model for how the compiler works

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

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 laziness was the game changer here. And if you go all in with functional programming it's surprising how much baseline performance you can get with such little effort and how easy it is to scale to multiple cores and multiple hosts.

There are some things like vectorization that most functional languages I know of are hard pressed to take advantage of so we still reach out to C for those things.

However I think we're starting to learn enough about functional programming languages and how to make efficient compilers for them these days. Some interesting research that may be landing soon that has me excited would enable a completely pure program to do register and memory mutations under the hood, so to speak, in order to boost baseline performance. I don't think we're far off from seeing a dependently typed, pure, lazy functional language that can have bounded performance guarantees... and possibly be able to compile programs that don't even need run time support from a GC.

I grew up on an Amiga, and later IBM PCs, and that instinct to think about programs in terms of a program counter, registers, and memory is baked into me. It was hard to learn a completely different paradigm 18 or so years into my professional career. And to me, I think, that's the great accident that prevented FP from being the norm: several generations were simply not exposed to it early on on our personal computers. We had no idea it was out there until some of us went to university or the Internet came along. And even then... to really understand the breakthroughs FP has made requires quite a bit of learning and learning is hard. People don't like learning. I didn't. It's painful. But it's useful and worth it and I'm convinced that FP will come to be the norm if some project can manage to overcome the network effects and incumbents.

I would agree with this, I came up in the same time period and we just programmed closer to the metal in that period, we did not have the layers and it was just normal to think in terms of the machines hardware (memory addresses, registers, interrupts, clock, etc.) This naturally leads to a procedural way of thinking, variables where a think veil over the actual memory they addressed.

It actually takes a lot of unlearning to let go of control of the machine and let it solve the problem, when you are used to telling it how to solve the problem. I came to that conclusion when I dabbled in ProLog just to learn something different, and I had a really hard time getting my head around CL when I first got into it, due to wanting to tell then machine exactly how to solve the problem. I think it was just ingrained in those of us that grew up closer to the metal and I think the Byte magazine reference, in the talk, has a lot to do with it, we just did not have that much exposure to other ideas, given that mags and Barns and Noble, where our only source to new ideas. That and most of us where kids just hacking on these things alone in our bedroom with no connectivity to anyone else.

I remember before the web getting on newsgroups and WAIS and thinking how much more info was available that the silo'ed BBS we used to dial into. Then the web hit and suddenly all of these other ideas gained a broader audience.

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 specification or code-generational approach, but you are aware of the leaky abstraction/blackish box underneath and how your code runs on it.

I see FP and the "infrastructure as code" movement as part and parcel to the same cool end reality goal, but I feel that our current industry weaknesses are related to hiding and running away from how our code actually executes. Across the board.

"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 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?

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.

> 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 script looks like.

They do. Each "core" of the GPU executes a sequence of instructions, one by one, but each instruction manipulates several separate copies of the state in parallel; the effect is like having several identical cores which operate in lockstep.

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

The cause and effect are in the opposite direction. The "imperative mindset" comes from the hardware. Even Lisp machines used imperative machine code (see https://en.wikipedia.org/wiki/Lisp_machine#Technical_overvie... for an example).

> 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 construed as imperative code, but treats it as declarative rather than imperative.

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.

From wikipedia:

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

gpu just means lots of cores. the cores are composed of execution units too.

even the most exotic architecure you can think of is imperative (systolic arrays, or transport triggered architecture or...whatever)

there are instructions and they are imperative.

I can vaguely rememeber some recent iterative AI of some kind who had to produce a functioning circuit to do XYZ, and the final netlist that it produced for the FPGA was so full of latches, taking advantage of weird timing skew in the FPGA fabric and stuff, and no engineer could understand the netlist as sensical, but the circuit worked... I suppose when there's that level of non-imperative design, you can truly call it both declarative, and magic.

nope. end of the day there is a linear sequence of instructions being executed by any given part of the hardware.|

OO and FP are just higher-level ways of organizing source code that gets reduced to a linear sequence of instructions for any given hardware execution unit.

hardware is imperative at it's lowest level. sure, hey you can even say that the instructions are declarative if you are speaking of the perspective of the ALU with regards to stuff you send to an FPU, for example...

> FP has been largely introduced into the mainstream of programming through Javascript and Web Dev. Let that sink in.

Not really.

"Confessions Of A Used Programming Language Salesman, Getting the Masses Hooked on Haskell"

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....

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

>End of the day, the computer is an imperative device, and your training helps you understand that.

Well... it's complicated. A CPU is imperative. An ALU is functional. A GPU is vectorized functional.

true, well that's complicated too, as that ALU likely runs microcode or has a lookup table, but presuming boolean hardware logic underlaying it somewhere, THAT level is declarative, not sure about what functional composition is involved here, but declarative programming of boolean hardware where the actual imperative activity is occurring.

maybe the physics is imperative too lol

end of the day, some poor schmuck has to get up and DO something...lol

I suppose that since one is still only talking about the external interface to any given hw execution unit (gpu, alu, fpu) one could always present it in whatever format was useful or trendy.

But I'll contend that it's much more productive to basically wrap low-level functionality as modules that higher-level languages could compose. One could then optimize individual modules.

The mechanism of composition should lay it out as desired in memory for best efficiency, and hence the probably need for a layout step, presuming precompiled modules. (it could use 'ld', for example) i'm not sure how you would optimize memory layout for black-boxes, but perhaps some standard interface..

Most people here are doing this already without knowing it, if you look into the dependencies of your higher level programming tools and kit.

End of the day OOP is a code-organization technique. FP is too. They are both useful. We still have complexity. Some poster above needing actor models etc, depends upon the scale I suppose. If one is considering a distributed healthcare application, or is one trying to get audio/video not to glitch etc.

I am fully on board with you.

Learned to code in the mid-80's, Basic and Z80 FTW.

Followed up by plenty of Assembly (Amiga/PC), and systems level stuff using Turbo Basic, Turbo Pascal, C++ (MS-DOS), TP and C++ (Windows), C++ (UNIX), and many other stuff.

I was lucky enough that my early 90's university has exposed us to Prolog, Lisp, Oberon (and its descendants), Caml Light, Standard ML, Miranda.

Additionally the university library allowed me to dive into a parallel universe from programming ideas that seldom reach mainstream.

Which was great, not only did I learn that it was possible to marry systems programming with GC enabled languages, it was also possible to be quite productive with FP languages.

Unfortunately this seems to be yet another area that others only believe on its possibilities after discovering it by themselves.

> Some interesting research that may be landing soon that has me excited would enable a completely pure program to do register and memory mutations under the hood, so to speak, in order to boost baseline performance. I don't think we're far off from seeing a dependently typed, pure, lazy functional language that can have bounded performance guarantees... and possibly be able to compile programs that don't even need run time support from a GC.

Is there any more info/links available about this?

I don't think they've finished writing the paper yet but I'll post it out there when it gets published.

Just wait until this guy has to use something like SQL or Spark. They will always occupy a niche for exactly these reasons. Turns out it's a pretty big niche though. So big in fact, that maybe we shouldn't call it a niche.

Python's ecosystem is built on this premise. Let some other language (C) do the fast stuff and leverage that for your applications. It's not a niche language, even though you don't have direct control over things like memory management and GC.

Perhaps the commenter's role of real time graphics programming is actually the niche.

re python and scripting, afaik used to be known as "glue languages". not sure how true it is anymore.

> This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

I think things like real-time graphics are the exception not the rule. Most of the software run by users these days is in the context of a browser, which is implemented many layers of abstraction away from the machine. Much of the code running servers is also still interpreted scripting languages.

Don't get me wrong, I wish a lot more software was implemented with performance in mind, because the average-case user experience for software could be so much better, but a ton of the software we use today could be replaced by FP and perform just as well or better.

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, and it is only ever called when you try to allocate something and the system determines that it's time for cleanup (https://ocaml.org/learn/tutorials/garbage_collection.html, though this might change if/when Multicore OCaml ever happens?). So if you write an innermost function that does arithmetic on stuff but never allocates data structures, you will not have GC problems because you will not have GC during that time, period.

Also, there are cases where destructive mutation of things is more efficient than making pure copies. OCaml allows you to do that, you don't need to fiddle with monads to simulate state.

There really isn't that much black magic there. Just don't believe everything that is said about "FP".

My understanding is that OCaml is a decent imperative language when required and that's one reason why it can perform well.

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?)

> Can I use lambdas?

Not ones that capture anything from the environment. I'm not sure about ones that don't, but I imagine you can use them.

> pattern matching?

Yes.

> list compression

List comprehensions, you mean? They don't exist in OCaml, but if they did, they would have to allocate a result list. So no.

> for example, can I dedicate one core to one thread and guarantee that GC will never touch that thread?

I don't think so, maybe someone else can chime in. But more importantly, this is a one-in-a-million use case that is a far cry from "functional programming is always bloated and slow and unpredictable". GC is well-understood, advanced, and comfortably fast enough for most applications. And for other cases, if you really need that hot innermost part, write it in C and call that from OCaml if you're paranoid about it.

Something I've always wondered about Haskell. Given referential transparency, purity, etc shouldn't it be possible for the Haskell compiler to choose whether to evaluate something in an eager or lazy fashion depending on performance heuristics under the covers? You have to make sure you don't ever accidentally do that with an infinite list but it seems that there ought to be lots of scope for optimization and speeding up code written in a straightforward fashion. Possibly also turning lists into arrays secretly too if it can be proven to produce the same result.

Yes, it's called strictness analysis and is an important part of the GHC pipeline.

The point of lazy evaluation is to evaluate something only when you really need it. Not to auto-adjust the system performance wise. You can force eager evaluation in places where you want it evaluated sooner.

Personally, I think consistency is more important here because it leads to better predictability. If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.

> If you don't know whether the compiler assigns something to be evaluated lazily or eagerly that could lead to a lot of nasty debugging issues.

If the compiler only forces values that would be forced anyway, there shouldn't be a problem. Which is why GHC actually does it: https://wiki.haskell.org/Performance/Strictness

Strictness analysis is good and useful... and difficult and not magic.

Got it thanks, good info for me!

Jane Street wrote a compiler that converts Ocaml to Verilog which they run on FPGAs. The OCaml you write in that case is pretty different than what you write for CPUs.

Streeter here.

Although I don’t work directly with the FPGA stuff, it’s still a very, very small piece of the overall pie (and new).

The motivation behind using Ocaml is mainly in its correctness(!) not because it’s fast (it’s not). See Knight Capital for a good example as to why. There are great videos on YT by Yaron Minsky that explain this better than I can.

Speaking of correctness and performance, was Ada/SPARK ever considered before you guys picked OCaml? Hypothetically, would you consider Ada/SPARK now, especially that SPARK has safe pointers and whatnot?

SPARK was barely making waves when they selected OCaml. OCaml was much more established by that time.

Fair enough. Then they should probably just focus on the second question. :)

> See Knight Capital for a good example as to why

Not really, that was about incompatible versions of software talking to each other, which would not really fall under what is meant by "correctness".

While Knight Capital's problem was caused by incompatible versions of the software talking to each other, one of the reasons that happened was the deployment of the code was not correct. The SEC notes:

> “During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.

Rumor on the outside suggests that Jane St uses OCaml for things like deploying software.

How does OCaml prevent you from deploying working code that you didn't want to run?

"A FORTRAN programmer can write FORTRAN in any language"

And structured programming (including, of course, FP) is for quiche eaters!

For those who don't get the allusion:

https://web.mit.edu/humor/Computers/real.programmers

That certainly explains a whole lot. Thanks!

There are really many places in code where you really don't care about performance that much. And in that case conciseness/expressiveness/correctness can be extremely valuable.

Also there are different aspects to performance, and when (for example) it comes to latency, a platform like Erlang/BEAM makes it particularly easy to get low latency in certain contexts without thinking about implementation much. In Haskell you can accomplish similar things with green threads. It will probably need more clock cycles for a given action than a tuned C implementation but that's not always what matters, and the code will probably be cleaner.

Is the kind of HFT that Jane Street does that reliant on extremely low latency? A lot of HFT firms operate on the timescale of seconds, minutes, or even hours, not milliseconds.

I feel like there must be terminology confusion here - the HF in HFT stands for high frequency, which effectively means low latency. There may be HFT firms that additionally do slower stuff, but no one would call a trade on the timescale of hours HFT - it's a fuzzy line, but certainly nothing measured in units larger than microseconds would qualify to someone in the industry, and the line is likely lower than that.

I’m all for mechanical sympathy, and I’m sure that some programmers legitimately need their language to map neatly to assembly, but that isn’t the norm as evidenced by the overwhelming popularity of interpreted and VM languages. Lots of companies are making money hand over fist with Python, which is probably 3 orders of magnitude (or more) slower than the optimized C or C++ that this real-time graphics engineer is writing.

EDIT: Is this controversial? What are downvoters taking issue with? That Python is a very popular language? That it is much slower than C/C++?

we users pay a price for this trend though :( Those python users could switch to F#/OCaml/Clojure and get a big speed boost too!

Python is perfectly fine for glueing together functionality that deals with high latency systems, like a data pipeline that executes queries that are running for minutes. It does not matter from the performance point of view if this code is in Forth or Python, but it matters from the point of view how long does it take to implement and how many engineering hours need to go into it. This is why Python is a good option and F#/OCaml/Clojure is not going to bring much to the table in such cases. Even if I want to implement the ETL pipeline in Clojure or OCaml the rest of the engineers are not ok with these languages, the build systems involved and package management or IDE options, integrations. These are also factors when you select a language. Clojure is my absolute favourite language but there are no people in most of the companies where I work who could buy into it. Management sees it as a risk, not to be able to hire engineers for it. There are many dimensions to this problem than it appears at first.

I would not advertise Python as a language with good IDE support nor package management. I fight with both of these regularly. Also, Python is reasonably suited for gluing together other high performance systems, but not everything in the world is glue code, 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. People kid themselves into thinking that Python’s C interop will make things fast, and sometimes it does, but it often makes it even slower if the system needs to cross the language boundary O(n) or worse.

> but not everything in the world is glue code, 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.

And yet Python has one of the richest and most widely used scientific computing stacks. If writing performant code in a friendly language is all that important, then Julia stands as a more reasonable alternative than does some functional language.

That's exactly why people vectorize their code: to avoid slow loops in python and move them to the underlying c/cpp code.

>> 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 need to do.

My entire comment was about that details matter and you can't just blindly pick a language because of out of the box performance.

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 spends so much time dealing with environment issues that we’re exploring Docker solutions. And then packaging and distribution of Python artifacts is pretty awful. We’re using pantsbuild.org to build PEX files which works pretty well when it works, but pants itself has been buggy and not well documented.

> I never claimed that

I couldn’t tell since the context of the thread made it sound like you were either implying that Python is suitably performant because the majority of programming is glue code or you were going somewhat off topic to talk about glue code. I now understand it was the latter.

> Depends what you need to do. My entire comment was about that details matter and you can't just blindly pick a language because of out of the box performance.

I agree, but in practice you rarely know the full extent of what you will need, so you should avoid painting yourself into a corner. It really doesn’t make sense to choose Python any more if you are anything less than certain about the performance requirements for your project for all time—we now have languages that are as easy to use as Python (I would argue even easier, despite my deep familiarity with Python) and which don’t paint you into performance corners. Go is probably the best in class here, but there are probably others too.

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

Go for it (why would I take offense?). Rust is a fine choice. I'd pick Rust if I ever really needed to eek out every bit of performance out of my system and/or needed safety and was willing to trade quite a lot of developer productivity to get there. Mission critical real-time systems, high-end games, resource-constrained devices, etc are good applications for Rust (and of course there are many others). Rust is a great language and I'd like to use it more often; I just can't justify the productivity hit.

If Rust ever approaches Go's ease of use/learning curve/etc without losing its performance or incurring other costs, I'll happily make the switch for my productivity-sensitive applications as well.

You missed my point—the original comment argued that the software industry is in such great need for performance that functional programming is unacceptable (apart from niche use cases). If that we’re true, then Python and other slow languages wouldn’t be so wildly used. I fully agree that we’re leaving performance on the table by not using functional languages or virtually any other tier of languages including my personal favorite: Go.

Classic games programmer logic. I've heard it a billion times. "X feature abstracts the hardware and therefore I could never use it for programming in my tiny niche and therefore it could never become popular."

And how many of the top 10 languages are running in a virtual machine? Which could be literally doing anything under the hood with your allocations, caching, etc?!

There is nothing wrong with saying, I don't see this working out in my domain due to these concerns it's just silly to say, I never see it taking off because it can't work in my domain.

I think this video nails it pretty dead on. My team works almost exclusively in C# these days for reasons mostly beyond our control. The team generally likes the language quite a bit (it's one of my personal favorites). But when I find myself asking for new features they come in two buckets. I'd like feature that help certain members of my team write less side effect heavy code and I'd like immutability by default with opt-in mutability. Basically I'd like more functional like features. But hey, that's what I see from my niche.

> And how many of the top 10 languages are running in a virtual machine? Which could be literally doing anything under the hood with your allocations, caching, etc?!

VMs provide an environment, just like any other. Javascript articles are chock full of information on how to not abuse the GC by using closures in the wrong place. C#'s memory allocation is very well defined, Java has a million tuning parameters for their GC, Go is famous for providing goroutines with very well defined characteristics.

Heck people who know C# can look at C# code and tell you almost exactly what the VM is going to do with it. And now days C# allows direct control over memory.

People writing high performance code on Node know how the runtime behaves, they know what types of loads it is best for, none of that is a mystery.

Sure some details like "when does this code get JITed vs interpreted" are left up to the implementation, but it isn't like these things are secret. I think every major VM out there now days is open source, and changes to caching behavior is blogged about and the performance implications described in detail.

The fact is, all programming paradigms are merely ways to limit our code to a subset of what the machine can do, thereby making reasoning about the code easier.

They are purely mental tools, but they almost all have a performance cost for using them. They are turing complete tools of course, any solution is theoretically solvable with any of the major paradigms, but not every paradigm is appropriate for every problem.

So, you know, pick the paradigm that makes it easiest to reason about the problem space, given acceptable performance trade offs.

Yeah, this is literally my point.

I was quibbling with the point that because FP languages often don't give low level control they can't become successful even though nearly every language on that top ten list suffers from the same perf oriented deficiency.

To write performant code in any of those top ten languages you have to understand the characteristics and nuances of the underlying tech stack.

And honestly people who don't write performant Java because they didn't bother to learn about the GC wouldn't have magically done otherwise writing C++. Trust me, that language does not intrinsically cause you to write performant code. It does intrinsically cause you to leak memory though.

But the bigger point is that in many domains performance is second to many other concerns. Like you said pick the languages that matches your needs.

So I think we pretty much agree.

>> This is true for any company at scale

I do not think this is true outside your domain. Amazon uses Java, C++ and Perl. At the time I was there majority of the website code was in Perl. Amazon one of the biggest companies on the planet.

Amazon needed to create AWS to be able to run all that perl performantly (joke).

Actually, a lot of programming language improvements have come from trying to make lisp performant.

Many functional languages acknowledge this and are not pretending to have low-level language facilities. Instead, they have built-in mechanisms (FFI) to interface with those low level languages whenever needed.

Are you suggesting that oop allows programmers to understand the assembly output?

Did you watch the video? The most popular language is JavaScript, which is only not functional but a quirk of history.

The video makes an argument for marketing being the reason.

JS isn't really a functional language, it's an imperative, prototype-based language with partial functional support that allows multiple coding styles, like most of the popular scripting languages.

Yes. Which is why I said it's not functional. Because of a marketing choice.

The fun, and funny, and maybe (probably) even terrible, thing about javascript is that while it -is- functional, and (IIRC) always has been, historically it wasn't originally used that way!

Only relatively recently have programmers embraced its functional aspects; prior to that it was mostly used as a procedural language.

Then people started to used functional aspects of it to "shoehorn" it into allowing a quasi-OOP form of programming style, and this form has been baked (in no small part) into the latest version of ECMAScript.

But people following this path, coupled with (I believe) using JQuery, NodeJS, and other tools (and now React) have led most of them (raising hand here) to more fully embrace it as a functional language.

But here's the thing:

You can still use it as a procedural language - and an OOP language - and a functional language! All at the same time if you want - it doesn't care (much)! It's like this weird mismash of a language, a Frankenstein's Monster coupled to Hardware's killer robot.

Yes - with today's Javascript you can still write a unicorn farting stars that follows your mouse on a webpage while playing a MIDI file - and do it all procedurally. In fact, there's tons of code examples out there still showing this method.

You can mix in simple class-like constructs using anonymous functions and other weirdness - or just use the latest supported ECMAScript OOP keywords and such - go for it!

Want to mix it up? Combine them both together - it don't care!

Oh - and why not pass a function in and return one back - or an entire class for that matter! It's crazy, it's weird, it's fun!

It's maddening!

And yes - it's a crazy quirk of history - a language that was created by a single programmer over the course of a weekend (or so legend goes) at Netscape has and is seemingly taking over the world of software development.

Not to mention Web Assembly and all that weirdness.

I need to find an interview with that developer; I wonder what he thinks about his creation (which is greatly expanded over what he started with, granted) and it's role in software today - for good or ill...

> 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 procedure. The defining characteristic of functional programming is the absence of side effects. That isn't something you can just tack on to an imperative (or "multi-paradigm") language. No matter how many cosmetic features you borrow from functional languages, like closures and pattern-matching and list comprehensions, you still have the side-effects inherent in the support for imperative code, which means your program is not referentially transparent.

Haskell manages to apply the functional paradigm to real-world programs by essentially dividing itself into two languages. One has no formal syntax and is defined entirely by data structures (IO actions). This IO language is an imperative language with mutable variables (IORefs) and various other side-effects. The formal Haskell syntax concerns itself only with pure functional code and has no side effects. IO actions are composed by applying a pure function to the result of one IO action to compute the next action. Consequently, most of a Haskell program consists of pure code, and side-effects are clearly delineated and encapsulated inside IO data types at the interface between the Haskell code and the outside world.

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.

It's not required to write idiomatic JS, but pure functional code is very much idiomatic. (I.e. pure functional code isn't considered unidiomatic in JS as it might be in some other languages). Many people write the meat of their code in pure functions, and this paradigm is encouraged by React (especially with the invention of hooks).

As for libraries, you can just treat them as stateful external things you have to interact with the same way IO / network calls are stateful.

OK, but dismissing most of the things that people use computers for as "the fringe" is rather parochial.

I think he means more "the outer layers". For instance Alpha Go was written in Python at the outer layers. The core pieces doing the actual neural net work are low level libraries.

Similarly, google search, at the outer most layers, is javascript, then probably some layer of Go or similar, but then the core is highly tuned C++ and assembler.

I had a programming languages survey class in college. The thrust of the course was different languages for different applications. It's not startling that the person, whose comment you quoted, doesn't find the functional paradigm helpful in graphics programming. Functional programming helps with expressiveness and reasoning, i.e. variables don't suddenly change on you when you're not expecting it.

A video game programmer would probably not be helped because a big part of their coding, as I understand it, is wringing out every clock cycle and byte of memory possible. However, the programmer writing the AR/AP system that allows tracking for in-game purchases would find OCaml, for instance, very beneficial.

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.

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)

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?

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.

-Ofast enables fast-math optimizations and generally is not standard compliant. I hope projects do not deliberately enable it without thinking (as they say, it is hard to make stuff fool proof because fools are so resourceful).

My point was that options like -O<number> and -Ofast aren't the actual optimization switches, they turn on other switches and you do not know what you'll get - essentially wishing for fast code and hoping you'll get some (i mentioned -Ofast explicitly because of its name).

For example according to the documentation in GCC 7.4 -O3 turns on:

    -fgcse-after-reload
    -finline-functions
    -fipa-cp-clone
    -fpeel-loops
    -fpredictive-commoning
    -fsplit-paths
    -ftree-loop-distribute-patterns
    -ftree-loop-vectorize
    -ftree-partial-pre
    -ftree-slp-vectorize
    -funswitch-loops
    -fvect-cost-model

whereas in GCC 9.2 -O3 turns the above, plus:

    -floop-interchange 
    -floop-unroll-and-jam 
    -ftree-loop-distribution 
    -fversion-loops-for-strides

So unless you control the exact version of the compiler that will generate the binaries you will give out, you do not exactly know what specifying "-O3" will do.

Moreover even though you do know the switches, their documentation is basically nothing. For a random example what "-floop-unroll-and-jam" does? The GCC 9.2 documentation combines it with "-ftree-loop-linear", "-floop-interchange", "-floop-strip-mine" and "-floop-block" and all it says is:

> Perform loop nest optimizations. Same as -floop-nest-optimize. To use this code transformation, GCC has to be configured with --with-isl to enable the Graphite loop transformation infrastructure.

...what does that even mean? What sort of effect will those transformations have on the code? Why are they all jumbled in one explanation? Are they exactly the same? Why does it say that they are the same "-floop-nest-optimize"? Which option is the same? All of them? The -"floop-nest-optimize" documentation says:

> Enable the isl based loop nest optimizer. This is a generic loop nest optimizer based on the Pluto optimization algorithms. It calculates a loop structure optimized for data-locality and parallelism. This option is experimental.

Based on the Pluto optimization algorithms? Even assuming that this refers to "PLUTO - An automatic parallelizer and locality optimizer for affine loop nests" (this is a guess, no other references in the GCC documentation as far as i can tell), does it mean they are the same as the the code in pluto, that they based on the code and are modified or that they are based on the general idea/concepts/algorithms?

--

So it isn't really a surprise that most people simple throw out "-Ofast" (or -O3 or -O2 or whatever) and hope for the best. They do not know better and they cannot know better since their compiler doesn't provide them any further information. And this is where all the FUD and fear about C's undefined behavior comes - people not knowing what exactly happens because they are not even told.

Never written even a simple C compiler, but I, and most c++ programmers that care about performance I think, do have a decent idea what code g++ is going to generate.

But g++ is probably better than you at producing fast code for whatever architecture you run it on.

Of course it is, that's why I let it generate it.

I've been programming for 34 years - 25 of those professionally. In the early days of my programming life it was super important to know how the code would run on the metal (and much of my time was spent writing assembler for that reason). Processors were slow, memory access was slow, and memory quantity was small (32k on my first computer). I spent a decade in the games industry building graphics engines and hand interleaving assembler to get the maximum amount of juice out of whatever console I was writing for (I beat what Sony said their Playstation 1 could actually do).

Then OOP happened and much of the early guarantees about how something ran went away, abstraction everything meant we couldn't reasonably know what was happening behind the scenes. However, that wasn't the biggest issue. Performance of CPUs and memory had improved significantly to the point where virtual method calls weren't such a big deal. What was becoming important was the ability to manage the complexity of larger projects.

The big deal has come recently with the need to write super-large, stable applications. Sure, if you're writing relatively small applications like games or apps with limited functionality scope, then OOP still works (although it still has some problems). But, when applications get large the problems of OOP far outstrip the performance concerns. Namely: complexity and the programmer's inability to cognitively deal with it.

I started a healthcare software company in 2005 - we have a web-application that is now in the order of 15 million lines of code. It started off in the OOP paradigm with C#. Around 2012 we kept seeing the same bugs over and over again, and it was becoming difficult to manage. I realised there was a problem. I (as the CTO) started looking into coping strategies for managing large systems, the crux of it was to:

* Use actor model based services - this helped significantly with cognition. A single thread, mutating a single internal state object, nice. Everyone can understand that.

* Use pure functional programming and immutable types

The reason pure functional programming is better (IMHO) is that it allows for proper composition. The reason OOP is worse (IMHO) is because it doesn't. I can't reasonably get two interfaces and compose them in a class and expect that class to have any guarantees for the consumer. An interface might be backed by something that has mutable state and it may access IO in an unexpected way. There are no guarantees that the two interfaces will play nicely with each other, or that some other implementation in the future will too.

So, the reality of the packaging of state and behaviour is that there's no reliable composition. So what happens is, as a programmer, I'd have to go and look at the implementations to see whether the backing types will compose. Even if they will, it's still brittle and potentially problematic in the future. This lack of any kind of guarantee and the ongoing potential brittleness is where the cognitive load comes from.

If I have two pure functions and compose them into a new function, then the result is pure. This is ultimately (for me) the big deal with functional programming. It allows me to not be concerned about the details within and allows stable and reliable building blocks which can be composed into large stable and reliable building blocks. Turtles all the way down, pure all the down.

When it comes to performance I think it's often waaaay overstated as an issue. I can still (and have done) write something that's super optimised but make the function that wraps it pure, or at least box it in some way that it's manageable. Because our application is still C# I had to develop a library to help us write functional C# [1]. I had to build the immutable collections that were performant - the cost is negligible for the vast majority of use-cases.

I believe our biggest problem as developers is complexity, not performance. We are still very much working with languages that haven't really moved on in 20+ years. Yes, there's some improvements here and there, but we're probably writing approximately as many lines of code to solve a problem as we were 20 years ago, except now everyone expects more from our technology. And until we get the next paradigm shift in programming languages we, as programmers, need coping strategies to help us manage these never-ending projects and the ever increasing complexity.

Does that mean OOP is dead as an idea? No, not entirely. It has some useful features around extensible polymorphic types. But, shoehorning everything into that system is another billion dollar mistake. Now when I write code it always feels right, and correct, I always feel like I can trust the building blocks and can trust the function signatures to be honest. Whereas the OOP paradigm always left me feeling like I wasn't sure. I wish I'd not lost 10+ years of my career writing OOP tbh, but that's life.

Is functional programming a panacea? Of course not, programming is hard. But it eases the stress on the weak and feeble grey matter between our ears to focus on the real issue of creating ever more impressive applications.

I understand that my reasons don't apply to all programmers in all domains. But when blanket statements about performance are wheeled out I think it's important to add context.

[1] https://github.com/louthy/language-ext

After Minecraft, none of this makes any sense anymore. That is a genre-defining cultural masterpiece and runs on the JVM which is fosbury-flopping all over your registers on purpose. And everyone used to repeat some folk wisdom about Java back then.

I had some truly dismal experiences with code generators in the 90's. At one point I blamed code generation itself, automatically dismissed any solution out of hand, and was proven right quite a few times.

It wasn't until I used Less on a project that I encountered a generator that did what I expected it to do in almost every situation. It output essentially what I would have written by hand, with a lot less effort and better consistency.

I expect people who adopted C felt roughly the same thing.

People presenting on OOAD occasionally warn about impedance mismatches between the way the code works and the way you describe it[0]. If what it 'does' and how you accomplish it get out of sync, then there's a lot of friction around enhancements and bug fixes.

It makes me wonder if this is impossible in FP, or just takes the same degree of care that it does in OO.

[0] a number of cow-orkers have 'solved' this problem by always speaking in terms of the code. Nobody has the slightest clue what any of them are talking about 50% of the time.

There is some truth to that. I write a lot of performance intensive interactive software (music software, graphics software), and use C++ for that. However, you can bring a lot of the FP into C++ world, use it when appropriate, and reason about performance all the way through. I spend a lot of time building tools to make it easier, like for example: https://github.com/arximboldi/immer https://github.com/arximboldi/lager

I agree. I haven’t done a lot of FP but, as a person who is used to knowing how my code will be executed, I find it very difficult to map what I want the machine to do onto functional code.

Functional Programming might have great advantages in correctness but sooner or later the code is going to be run on a real CPU with real instructions and all the mathematical abstractions don’t mean much there.

That said, I can see they have their place for specialized areas.

A niche like JVM and AWS

The exact same could be used to describe SQL/Bash/Lua etc, which sometimes used by accountant/admin/game designer. Those languages are at the sometimes at the edge of the systems, but obviously not non-starter.

But it should be fine, then, as a replacement for anything written in Javascript, Ruby, Python, etc.

(Also, addressed in the video at the end, answering an audience member question.)

> core part demands efficiency

what about development efficiency? maintenance efficiency? developer onboarding efficiency? there are many efficiencies companies care about.

I'm a true believer that with C++ and lots of scary templates you can do FP that maps exactly on what you want it to be doing.

Jane Street does a fair bit of high-performance OCaml...

Sure for hardware, real time, embedded use cases (and probably others), makes sense.

Does it matter for data analysis and most web apps, infra as code, etc? Which data scientists do you know fetishize how Python is laying out memory?

OOP is a hot mess. Yes, I know, you’re all very well versed in how to use it “right”, but the concept enables a mess. It’s the C of coding paradigms when it would be great to have a paradigm that pushes towards Rust, and reduces the chance for hot messes from the start.

Most of this work is organizing run of the mill business information. Why it works from a math perspective is more universally applicable and interesting anyway.

With JavaScript as the most popular language out there I would say that this low level core stuff is now the fringe.