Comment by js8
7 years ago
> 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
1 reply →
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".
4 replies →
> 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.
12 replies →
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.