And a question — what is the difference between “FP”, “Functional Programming” (uppercase), “function based programming”, “functional programming” (lowercase) ?
And where would Python & JS fit into those categories?
I'm trying to point out that the very idea of _functions_, whether pure or not, is old and overly-restrictive. I first encountered function-based everything in "C". Today, FP is merely the evolution of this idea, aimed at more and more purity.
This sounds strange when I say it: "CPUs don't implement functions, CPUs implement subroutines".
Subroutines are simply sequences of opcodes that would be inlined, except for concerns about saving space. Subroutine sequences are cut/pasted into other parts of memory and can be used, sequentially in a blocking manner as if inlined, by multiple other subroutines.
To properly implement _functions_ in all their glory you need to implement virtual memory and preemption and increase memory usage, all of which tends to imply the need for operating systems. Functional, sequential, synchronous programming discarded asynchrony and replaced it with synchrony. Now, we're chipping away at trying to put asynchrony back into synchronous programming (ultimately impossible, but, with some interesting results) using doo-dads like caches, instruction scheduling, multi-core, etc.
Okay that makes sense. When I encountered “functional programming” (colloquial definition) for the first time, I was confused as to why Python, JS, Java, etc weren’t considered functional because I was using functions in those languages all the time.
Super thought provoking. Okay… earlier today my son made a comment about checking the time using a phone, and I realized that he’s never really been around anyone who wears a watch. And I was thinking that, in a lot of ways, the bundling of *everything* in an iPhone isn’t a matter of elegance, it’s a matter of economics. Having hardware for dedicated tasks is actually much more elegant than smushing everything together. (I hate modern cars in this regard.) I think it’s because hardware is expensive to develop, but also we’re really bad at pricing distractions. (Just thinking out loud…now that I think about it, it actually makes sense to pay like $5000 for a watch across ten years to save myself 10 looks at my phone every day. Right? I’m just melting my brain looking at this thing.)
But anyway, my thought with your essay was: are we always going to be hamstrung in our way of thinking so long as we use traditional CPUs? And, like the iPhone, do we use one CPU architecture for every task because it’s elegant or because it’s economical? And will there be a day when we can identify that alternative architectures that will bring so much developer productivity that they’re actually worth the investment?
FP's sweet spot is single-threadedness. We should be using multiple CPUs. We couldn't do this in 1960 because of cost. We can do it today with the advent much cheaper hardware, but, we cling to old practices instead. [More thoughts on Massive Parallelism](Massive Paralellism https://programmingsimplicity.substack.com/p/massive-parallelism?r=1egdky)
And a question — what is the difference between “FP”, “Functional Programming” (uppercase), “function based programming”, “functional programming” (lowercase) ?
And where would Python & JS fit into those categories?
Uppercase vs. lowercase is caused by my laziness.
I'm trying to point out that the very idea of _functions_, whether pure or not, is old and overly-restrictive. I first encountered function-based everything in "C". Today, FP is merely the evolution of this idea, aimed at more and more purity.
This sounds strange when I say it: "CPUs don't implement functions, CPUs implement subroutines".
Subroutines are simply sequences of opcodes that would be inlined, except for concerns about saving space. Subroutine sequences are cut/pasted into other parts of memory and can be used, sequentially in a blocking manner as if inlined, by multiple other subroutines.
To properly implement _functions_ in all their glory you need to implement virtual memory and preemption and increase memory usage, all of which tends to imply the need for operating systems. Functional, sequential, synchronous programming discarded asynchrony and replaced it with synchrony. Now, we're chipping away at trying to put asynchrony back into synchronous programming (ultimately impossible, but, with some interesting results) using doo-dads like caches, instruction scheduling, multi-core, etc.
Python & JS are function-based, impure FP.
Okay that makes sense. When I encountered “functional programming” (colloquial definition) for the first time, I was confused as to why Python, JS, Java, etc weren’t considered functional because I was using functions in those languages all the time.
Super thought provoking. Okay… earlier today my son made a comment about checking the time using a phone, and I realized that he’s never really been around anyone who wears a watch. And I was thinking that, in a lot of ways, the bundling of *everything* in an iPhone isn’t a matter of elegance, it’s a matter of economics. Having hardware for dedicated tasks is actually much more elegant than smushing everything together. (I hate modern cars in this regard.) I think it’s because hardware is expensive to develop, but also we’re really bad at pricing distractions. (Just thinking out loud…now that I think about it, it actually makes sense to pay like $5000 for a watch across ten years to save myself 10 looks at my phone every day. Right? I’m just melting my brain looking at this thing.)
But anyway, my thought with your essay was: are we always going to be hamstrung in our way of thinking so long as we use traditional CPUs? And, like the iPhone, do we use one CPU architecture for every task because it’s elegant or because it’s economical? And will there be a day when we can identify that alternative architectures that will bring so much developer productivity that they’re actually worth the investment?
FP's sweet spot is single-threadedness. We should be using multiple CPUs. We couldn't do this in 1960 because of cost. We can do it today with the advent much cheaper hardware, but, we cling to old practices instead. [More thoughts on Massive Parallelism](Massive Paralellism https://programmingsimplicity.substack.com/p/massive-parallelism?r=1egdky)