7 ms·

> Second, and more substantively, it is not the case that mathematical fields inevitably turn into algebra. Not to fully justify the OP (though it rings both t

by Twisol 6y ago

> Second, and more substantively, it is not the case that mathematical fields inevitably turn into algebra. 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.

spekcular 6y ago
Certainly, algebraic topology is a huge win for algebraization! > 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. Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place? It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement. I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.
lptk 6y ago
> 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. I don't think parallelism is the word for that. More like concurrency Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).[5][6] In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution. https://en.wikipedia.org/wiki/Parallel_computing https://en.wikipedia.org/wiki/Parallel_computing What you're describing sounds like it would be solved by primitives such as the actor model, not by Haskell-style FP.

by Twisol 6y ago

spekcular 6y ago

Certainly, algebraic topology is a huge win for algebraization! > 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. Maybe I should say what I meant more clearly. The claim "one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program" implicitly has a "and this is good because being fast is good" at the end. Why care about a speedup if you don't care about speed in the first place? It follows that when evaluating a language's ability to gain speed through parallelization, we should also evaluate how fast that language is in the first place. If you can get a 7x speedup on 8 cores from a few lines of code, but the original algorithm is, say, 10x slower than a similar implementation in C/Rust/Go on one core, then who cares? The ultimate criterion is always absolute speed, not relative improvement. I agree that being able to deal with concurrency is important, but as the Go people always remind me, concurrency and parallelism are distinct concepts.

lptk 6y ago

> 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. I don't think parallelism is the word for that. More like concurrency Parallel computing is closely related to concurrent computing—they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).[5][6] In parallel computing, a computational task is typically broken down into several, often many, very similar sub-tasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution. https://en.wikipedia.org/wiki/Parallel_computing https://en.wikipedia.org/wiki/Parallel_computing What you're describing sounds like it would be solved by primitives such as the actor model, not by Haskell-style FP.