21–30 of 64 posts
I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.
Functional languages seems to be one of the hardest things for people without a CS background to pickup in my experience.
I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.
I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.
If you look at Bloch's book Effective Java you'll see he describes functional approaches quite a lot (eg prefer immutability) - these are places you go when you see that they're better.
I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.
I'm self-taught and while I can see the formal appeal of functional programming, I'm a low-level coder that implicitly reduces state to bare-metal registers and cache in GPUs and embedded systems. Since I'm already sweating bits over state down to the byte-level, I just don't see what FP would improve on this.
Using a function style or a higher-level language sometimes makes it easier to modify the program (and hence use a better algorithm).
I remember people swearing by assembly language back in the 80's, thinking C would make their programs slow and bloated. In reality, it was usually the other way around because C code is much more malleable than assembly. You might want to give FP a second look.
I've noticed hackers/self taught prefer functional programming styles and CS degree holders prefer the more common style.
I'm self-taught and while I can see the formal appeal of functional programming, I'm a low-level coder that implicitly reduces state to bare-metal registers and cache in GPUs and embedded systems. Since I'm already sweating bits over state down to the byte-level, I just don't see what FP would improve on this.
Earlier quoted context omitted.
I'm self-taught and while I can see the formal appeal of functional programming, I'm a low-level coder that implicitly reduces state to bare-metal registers and cache in GPUs and embedded systems. Since I'm already sweating bits over state down to the byte-level, I just don't see what FP would improve on this.
The big improvements often come from better algorithms and data structures. Using a function style or a higher-level language sometimes makes it easier to modify the program (and hence use a better algorithm). I remember people swearing by assembly language back in the 80's, thinking C would make their programs slow and bloated. In reality, it was usually the other way around because C code is much more malleable tha…
https://en.wikipedia.org/wiki/C%2B%2B_AMP
However, my best algorithms are stylistically equivalent to a map-reduce with combiners entirely in GPU-space. The map tasks themselves carry all the scope I need. They are independent units of work executed by independent warps (synchronized groups of 32 GPU threads) whose results need to be reduced to floating point numbers. That reduction is done with 64-bit fixed point atomic ops (my combiners) because:
1) This insures the sum is deterministic
2) Ever since Kepler (GK104), it's much faster than reduction buffers and uses a fraction of the memory
3) It's possible because I can precompute the expected dynamic range and adjust the fixed point exponent accordingly
Now given that, do you see a functional programming equivalent that significantly improves on this design? I haven't yet.
Earlier quoted context omitted.
I'm self-taught and while I can see the formal appeal of functional programming, I'm a low-level coder that implicitly reduces state to bare-metal registers and cache in GPUs and embedded systems. Since I'm already sweating bits over state down to the byte-level, I just don't see what FP would improve on this.
Here's the relationship. How can you guarantee your low-level code is correct? Here's one way. You have a language like Idris create a DSL that targets the machine you want. You can model what the set of correct programs in your domain look like, and then produce correct code. That's why functional programming in general, and dependent-type programming in particular, is useful for low-level problem domains.
Earlier quoted context omitted.
The big improvements often come from better algorithms and data structures. Using a function style or a higher-level language sometimes makes it easier to modify the program (and hence use a better algorithm). I remember people swearing by assembly language back in the 80's, thinking C would make their programs slow and bloated. In reality, it was usually the other way around because C code is much more malleable tha…
There is a very active attempt to make GPUs FP-friendly called C++AMP. And for streaming transformation tasks, it's a nice abstraction. https://en.wikipedia.org/wiki/C%2B%2B_AMP However, my best algorithms are stylistically equivalent to a map-reduce with combiners entirely in GPU-space. The map tasks themselves carry all the scope I need. They are independent units of work executed by independent warps (synchronized…
Who cares if you implement the combining with atomic ops or by sending data to a process that does the combining or whether you stuff the data in a buffer and then reduce it afterwards?
(Of course you might care for performance reasons -- but conceptually it's the same thing.)
One difficulty with functional style c++ is just how verbose it is. Every time I tried to use std::transform (the equivalent of "map") I had to delete it and rewrite as a loop because it was just too hard to read. Functional style on a large scale is still possible.
if (std::find(container.begin(), container.end(), element) != container.end())
Earlier quoted context omitted.
The article is not about the functional C++ you mention. It is about using pure functions (functions that do not modify global context).
I get that. But the two ideas are very closely related. See also my final sentence.