51–60 of 129 posts
Earlier quoted context omitted.
That’s because the parallelization in the STL is encapsulated. In Haskell and Rust it’s explicit, it’s not just about adding a parameter to an existing function, it’s a general mechanism.
Rayon literally works on iterators just like the C++ algorithm library.
Functional programming appeals to many of us for reasons other than these practical considerations: Functional programming feels like reasoning in algebra. As in Modern Algebra for math majors (groups, rings, fields) and beyond. There's a saying in mathematics that when any field matures it turns into algebra. Life crossed a threshold from chemistry to biology on Earth, and developed exponentially from there. Order i…
> There's a saying in mathematics that when any field matures it turns into algebra. Life crossed a threshold from chemistry to biology on Earth, and developed exponentially from there. Order in mathematics crosses a similar threshold, as it becomes sufficiently structured to support algebraic reasoning. The subjective experience is like ice melting into a churning liquid, or a land-locked creature learning to fly. O…
Not to fully justify the OP (though it rings both true and not quite true to me), but I think topology is a good positive example. It's impressive how much of continuity can be captured purely algebraically. For example, topologies are a kind of lattice, which cross both algebra and order theory. And then you get literal algebraic topology, which captures useful and interesting properties of individual topological spaces effectively.
> A more substantive objection is that the sole purpose of parallelism is performance.
I disagree a lot more strongly here, though I will twist your words a little bit. Yes, parallelizing a program is about making it run faster; but parallelism is also a base fact of many problem domains, where you have multiple agents (up to and including humans) collaborating and interacting simultaneously.
Abstracting over the speed-up aspects of parallelism gets you to concurrency -- the independence of knowledge held by distinct agents that is not directly knowable by others -- which is far more fundamental than simply making programs run faster. In my experience, most properties of modular systems can be stated in terms of concurrency. Parallelism is an exploitation of that concurrency structure to schedule things efficiently, but it is by no means the only application.
The fact that "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" tells me that Haskell is extremely good at letting you expose the concurrent structures of your problem domain.
Earlier quoted context omitted.
> To this day it has the best implementation of parallelism; one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program. Eh, you can achieve the same in Rust using rayon, this isn't exclusive to Haskell or FP. Do you have an example in Haskell, where you get an effortless speedup which wouldn't be easy in another language?
From the article at https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskel... : > let colors = fmap computeColor coordinates to > let colors = fmap computeColor coordinates `using` parListChunk 32 rseq So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon co…
Earlier quoted context omitted.
Heavily? It's actually heavily inspired by ML (SML/OCaml), not Haskell. Most of its functional programming attributes originated in SML, and has avoided most of the things that make Haskell unique. Really it is just type classes that came from Haskell.
I was around in the very early days of rust, and it was explicitly stated in many places in the docs that the trait system, ADTs, etc. were all inspired by Haskell experience. I don't think we ever mentioned OCaml or SML. The trait system in Rust has nothing whatsoever to do with SML or OCaml and everything to do with Haskell's typeclass system. So between that and ADTs, on what grounds do you think it was "heavily i…
How could you have not mentioned OCaml? The original Rust compiler was implemented in it. By this, Rust has a very clear (OCa)ML heritage.
It's meaningless to argue, whether Rust got ADTs from Haskell or OCaml, because the author (Graydon Hoare) had been clearly familiar with both and both got ADTs from ML, which is much older than either of them.
On the other hand, traits are a different story, those just Type classes with a different name, and that is a Haskell thing.
Requiring a functional programming approach when you teach makes your life much easier. I teach a computationally-intensive course for advanced economics PhD students. These days I have them think carefully through their problem, set up a recursion, and make one call to reduce. The vast majority of problems fit into this framework. I no longer have to work my way through 500-line monsters that look like entries in an…
You can do this in any language, functional or not. Every language has recursion, every language has a simple one liner way to do reduce. They have generally had them for over a decade now. I don't know if it's the case any more as I mainly work alone, but I often saw new programmers had been taught about recursion, but didn't actually understand it. So they never used the concept until you pointed it out, even if it…
Functional programming appeals to many of us for reasons other than these practical considerations: Functional programming feels like reasoning in algebra. As in Modern Algebra for math majors (groups, rings, fields) and beyond. There's a saying in mathematics that when any field matures it turns into algebra. Life crossed a threshold from chemistry to biology on Earth, and developed exponentially from there. Order i…
Mutations and IO are very critical parts of programming and the two areas where FP breaks down. Even the IO Monad leaks the imperative nature of the program over to the programmer.
The only way pure FP can sort of work is if there are heavy frameworks abstracting IO and mutation away from the programmer. If you're not doing IO or mutating something then your caching framework, database or Haskell runtime is doing it for you. Additionally like I said earlier, Even if your database is handling mutation for you, you still end up embedding mutation commands into the strings of your pure FP function. Updating a database in haskell still necitates the haskell user to place the mutation command in a SQL string.
My point is, that math is not the complete solution to the programming problem. What FP allows the programmer to do is to use the framework to segregate combinatorial logic away from mutation and IO. Your combinators will always be more composeable and modular but your IO and mutation functions will be less modular but they still have to exist.
Earlier quoted context omitted.
> To this day it has the best implementation of parallelism; one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program. Eh, you can achieve the same in Rust using rayon, this isn't exclusive to Haskell or FP. Do you have an example in Haskell, where you get an effortless speedup which wouldn't be easy in another language?
From the article at https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskel... : > let colors = fmap computeColor coordinates to > let colors = fmap computeColor coordinates `using` parListChunk 32 rseq So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon co…
var colours = coordinates.stream().map(this::computeColour).collect(toList());
var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList());
I disagree with the higher order functions thing. Writing functions that receive other functions as input can lead to over complicated code that's really hard to read. It's literally the same thing as dependency injection just with functions instead of objects. Use sparingly. I would avoid altogether except for common ones like map, reduce and filter. Functional programming promotes the idea of composition of morphis…
Although your opinion is more extreme than I can get behind, I don't entirely disagree. I find monads and applicative functors are far easier to understand when presented in their non-higher-order formulation -- that is, "flatten" instead of "bind", and "merge" instead of "ap". You still need to understand "map", but that's an incredibly common pattern that you can get a lot out of for putting in just a little.
I wrote a little comment on this earlier this week.
https://news.ycombinator.com/item?id=24894849
I also agree with your opinion elsewhere about preferring combinators instead of directly passing higher-order functions, but I suspect that's much more of a style and design issue than a language feature distinction. You still need higher-order functions (and I'm frustrated weekly by Java's lack of higher-kinded types or pleasant existential types) as the basement layer to expose a beautiful API in more natural terms.
I think it all comes down to one question, do you need objects or not?