Pretty disappointing article. All the arguments are pretty weak. For example, the article argues that FP is necessary going forward because immutable data helps avoid race conditions. However, immutable data does not make a programming language functional. I could just use Rust, which (although it incorporates functional constructs) is still clearly imperative, and avoid race conditions through its particular implementation of immutable data structures.
The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code. Also:
> Maybe we don’t have to worry about chips with 32,768 cores on them.
Author apparently has never written a GPGPU program.
>Pretty disappointing article. All the arguments are pretty weak. For example, the article argues that FP is necessary going forward because immutable data helps avoid race conditions. However, immutable data does not make a programming language functional. I could just use Rust, which (although it incorporates functional constructs) is still clearly imperative, and avoid race conditions through its particular implementation of immutable data structures.
Which is neither here, not there.
Rust is like the 1/10000th of what's going on in the programming world.
Just because this new language, not even widely adopted yet, offers some way to tame certain race conditions doesn't mean the general argument in favor of FP is moot.
For one, the implementation of "immutable data structures" in Rust, as well as other parts of Rust, was inspired by FP concepts itself. So whether one goes for pure FP or uses some of its concepts in a language like Rust, the central point that FP is important holds.
>The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code.
If you do it in 70s goto/spaghetti style then yes.
Else, citation needed.
Not to mention that Robert C. Martin literally wrote the book on Clean Code.
>> Maybe we don’t have to worry about chips with 32,768 cores on them.
Author apparently has never written a GPGPU program.
Author apparently knows about this trivial counter-example, and speaks about general purpose CPUs, not GPU programming in his post...
> The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code.
This is a Lisp macro. Macros are a powerful form of abstraction. Abstractions are what us programmers create to reduce complexity and clean code.
One just needs to be mindful of how this powerful tool is wielded, just like any other tool; you can make a mess with anything.
I have another gripe with these kinds of immutability / FP praising articles: The assumption that this must be faster, because multicore. As an example, many if not most of scientific applications (for which Haskell wants to position itself) are memory bandwidth bounded, not CPU bounded. These applications also deal with Gigabytes of data for each timestep, applied over dozens if not hundreds of kernels. So we're talking about thousands to tens of thousands of functional updates over data objects, each on the order of Gygabytes. The way this is dealth with efficiently in many cases is by doing pointer swapping - after each timestep, or even for intermediate kernels, the old output becomes the new input and the old input is overwritten by the new output. Swapping allows this to be an O(1) operation. Allocating new memory at each kernel launch for the output would absolutely kill the performance - we're talking one to two orders of magnitude here. Even if an FP compiler comes along that is able to optimize this, if this ever breaks I have zero trust that it will be a simple thing to figure out why the compiler doesn't do what I wanted, and at that point I'd rather just program it procedurally. To my knowledge, game programming is pretty much the same thing, so these usecases are rather wide spread.
I think there must be a (probably not yet invented) language somewhere that would allow me to write computations in immutable FP style, either as pointwise operations (i.e. stencils), or as matrix operations, but allows me to pass in some information that directly instructs the backend what it should do with the memory. I.e. I want to be able to program my own memory pools and link pointers to memory slots needed for the computations. Maybe that part could even be done using visual programming, akin to linking up GUI elements to properties in XCode: Let the compiler figure out where a memory slot is needed, do a dependency analysis for the memory slots and show graphically what slots are linked to what input and output. Then, let me add constraints to that linking and recompute a new solution whenever I move something around. The next step would be to do a performance model for each processor and figure out the best solution using machine learning, but let me actually see what the solution is without me having to go look at assembly (which, frankly, for FP frontends seems near impossible since it has even less to do with the frontend code than if you compile down something like C or Fortran).
Exactly. I've actually been giving this a fair amount of thought, as it also relates to "GC for everything", another obstacle for real time programming (soft or hard). I like many things about the FP approach, especially in terms of reasoning about the code. I just think the computer science community needs to focus on basically what you're advocating, immutable recycling alongside of garbage collection.
It seems to me that this is a fairly easy problem really, and things should move to more of a mixed memory handling model, where one could use one or more of manual memory management, recycling, or GC as needed. FP language scala-native is providing both manual management and GC already, for instance...
Thank you. Yes, well, from the CS people I usually just get blank stares. "What did you say, you prefer Fortran"? I feel like there's a big divide between engineering and CS. The latter would rather never care about anything to do with hardware. IMO the real innovation usually comes at the intersection of hardware and software - like the recent boom of neural nets. Those things are known since the 80ies and then promptly dropped because the hardware wasn't ready, until someone 30 years later took the time to make a good CUDA library and make
it work fast enough to be useable. Meanwhile the CS community focuses on adding more abstractions until no-one can figure out the hardware implementation anymore. Sorry for the grumpyness, guess my mood isn't the best today...
"The speed of light limit had been reached. Signals could not propagate across the surface of the chip fast enough to allow higher speeds."
Sorry, this is blatantly wrong. The 'wires are too long' problem was solved a couple of decades ago by adding pipeline stages.
Processors can easily get faster, today, by increasing the clock speed. Problem is, the generated heat fries them. Heat is a function of voltage and frequency. You can only lower voltage so much before switching states becomes unreliable. After that the only option is to lower frequency.
I am not an expert, but I heard differently. IBM z13 CPU had to decrease the frequency compared to its predecessor, because they had a rule that the CPU should be able to operate on contents of L1 cache in one cycle, and they decided to expand L1 cache a bit. So I think "wires are too long" problem is alive and well when it comes to L1 cache size.
Of course, long circuit lines will limit further increase in clock frequency. But in practice, heat is the lower bound. In CMOS, heat arises from charge dissipation, or voltage times clock frequency. Unless we can switch to transistor fabric that does NOT dump charge with every state change, heat will remain the dominant problem for future CPU speedup.
Despite what some claim, multicore is no solution to speedup. Coarse or fine grain parallelism is useful only when data parallelism is possible, which applies to less than 5% of today's software (graphics, speech, deep learning, et al). Functional programming may free code from explicitly addressing variables, but FP's implicit addressing does not magically eliminate sequential dependencies.
The vast majority of processes in mainstream software are inherently sequential. Simply implementing them in an FP won't make them parallel, so adding threads won't increase speed.
FP is going to kill it when compilers catch up to utilize new SIMD instructions.
I think we are going to see more per core "L0" caches and less reliance on the shared "L1" cache. With that many caches to juggle you want a strongly typed compiler doing it, not by hand.
> Now you know 95% of Lisp, and you know 90% of Clojure. That silly little parentheses syntax really is just about all the syntax there is to these languages.
And yet I still can't do anything useful with them. A language isn't just the syntax, it's also all of the functions that are defined by default.
15 comments
[ 0.23 ms ] story [ 52.3 ms ] threadThe most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code. Also:
> Maybe we don’t have to worry about chips with 32,768 cores on them.
Author apparently has never written a GPGPU program.
Which is neither here, not there.
Rust is like the 1/10000th of what's going on in the programming world.
Just because this new language, not even widely adopted yet, offers some way to tame certain race conditions doesn't mean the general argument in favor of FP is moot.
For one, the implementation of "immutable data structures" in Rust, as well as other parts of Rust, was inspired by FP concepts itself. So whether one goes for pure FP or uses some of its concepts in a language like Rust, the central point that FP is important holds.
>The most upsetting part is when the author brags about how Clojure programs can manipulate itself at run-time, on a website that's literally called "Clean Coder Blog". Self-modifying code is a clear opposite of clean code.
If you do it in 70s goto/spaghetti style then yes.
Else, citation needed.
Not to mention that Robert C. Martin literally wrote the book on Clean Code.
>> Maybe we don’t have to worry about chips with 32,768 cores on them. Author apparently has never written a GPGPU program.
Author apparently knows about this trivial counter-example, and speaks about general purpose CPUs, not GPU programming in his post...
I didn't say that. I'm not opposed to FP, quite to the contrary. My point is that there are better arguments for FP than those in the submission.
99% of the programmers out there never did and never will do.
This is a Lisp macro. Macros are a powerful form of abstraction. Abstractions are what us programmers create to reduce complexity and clean code.
One just needs to be mindful of how this powerful tool is wielded, just like any other tool; you can make a mess with anything.
I think there must be a (probably not yet invented) language somewhere that would allow me to write computations in immutable FP style, either as pointwise operations (i.e. stencils), or as matrix operations, but allows me to pass in some information that directly instructs the backend what it should do with the memory. I.e. I want to be able to program my own memory pools and link pointers to memory slots needed for the computations. Maybe that part could even be done using visual programming, akin to linking up GUI elements to properties in XCode: Let the compiler figure out where a memory slot is needed, do a dependency analysis for the memory slots and show graphically what slots are linked to what input and output. Then, let me add constraints to that linking and recompute a new solution whenever I move something around. The next step would be to do a performance model for each processor and figure out the best solution using machine learning, but let me actually see what the solution is without me having to go look at assembly (which, frankly, for FP frontends seems near impossible since it has even less to do with the frontend code than if you compile down something like C or Fortran).
It seems to me that this is a fairly easy problem really, and things should move to more of a mixed memory handling model, where one could use one or more of manual memory management, recycling, or GC as needed. FP language scala-native is providing both manual management and GC already, for instance...
Haskell isn't really a thing that could "want" to "position itself".
Sorry, this is blatantly wrong. The 'wires are too long' problem was solved a couple of decades ago by adding pipeline stages.
Processors can easily get faster, today, by increasing the clock speed. Problem is, the generated heat fries them. Heat is a function of voltage and frequency. You can only lower voltage so much before switching states becomes unreliable. After that the only option is to lower frequency.
Despite what some claim, multicore is no solution to speedup. Coarse or fine grain parallelism is useful only when data parallelism is possible, which applies to less than 5% of today's software (graphics, speech, deep learning, et al). Functional programming may free code from explicitly addressing variables, but FP's implicit addressing does not magically eliminate sequential dependencies.
The vast majority of processes in mainstream software are inherently sequential. Simply implementing them in an FP won't make them parallel, so adding threads won't increase speed.
I think we are going to see more per core "L0" caches and less reliance on the shared "L1" cache. With that many caches to juggle you want a strongly typed compiler doing it, not by hand.
And yet I still can't do anything useful with them. A language isn't just the syntax, it's also all of the functions that are defined by default.