4 ms·

I've been in a good many debates about the practically of lambdas and parallelism for typical application development[1], and I stand by my claim. My opponents

by tabtab 8y ago

I've been in a good many debates about the practically of lambdas and parallelism for typical application development[1], and I stand by my claim. My opponents failed to give sufficient practical examples that stood up to scrutiny. Granted, some of it is subjective, but the fact it's subjective means it's not a necessity. True, sometimes it's good to have more than one way to do something, but sometimes it also creates a bigger and unnecessary learning curve. In the cases I looked at, making better OOP would result in a simpler language than adding lambdas, at least in my judgement. I'd be glad to debate it further, but this is not the best forum for such. [1] Some argue the same languages should be used for systems software and applications development. I don't agree.

burntsushi 8y ago
I see your debates and raise you practice. I've done plenty of typical application development that makes practical use of lambdas and parallelism for great benefit.
- tabtab 8y ago
  I'm not saying they "don't work", only that other features/designs can often do them also without using/adding new constructs: parsimony of language features. Can you suggest a forum to continue such debates? If not, I'll see what I can find. (My past favorite forums died.)
  - burntsushi 8y ago
    You've pretty drastically changed topics. I have no interest in a language design debate with someone who thinks of lambdas as "magic Legos." As I said before, our conceptions of reality are so drastically different that it would be a gratuitous waste of my time. You've gone from "parallelism is a fad" to "let's subjectively evaluate language design based on my ideas of parsimony." Parallelism isn't some kind of language feature I'm touting. It's an implementation tactic that can be used to make certain programs faster. Before such tactics were common, it was easy to write programs that were blissfully unaware of it in such a way that it is difficult to bolt on later. I used parallelism as one possible example of something that would be incredibly difficult to add to older programs to combat the notion that we should stop re-inventing the world and instead improve older stuff. Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out. Moreover, the degree to which parallelism can be wielded effectively will, in part, depend on your tools. Some tools make parallelism easier to use or reason about than other tools do. With that said, even that was immaterial to my point, because I wasn't doing a comparative analysis of parallelism across programming languages. I was just using it as an example of a concrete improvement that one could make to older programs that is often not practical to do, precisely because they are older programs that are widely used. Parallelism isn't the only example of this kind of improvement; jerf provided other examples in this thread. But parallelism is an easy one to grasp because most programmers with a few years of experience can appreciate what it's like to refactor a large program that is deeply coupled to unsynchronized shared global mutable state to a program that isn't---which is generally a good idea if you want to add parallelism to it. Your initial response to this was: > I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. But this is completely pointless. That parallelism is a useful way to make a program faster is taken as axiomatic in my comment. There is enough of my code (and others) out in the wild that uses parallelism to achieve some concrete measurable improvement that I feel it is obviously true and really doesn't need any further explanation. But here you are, nitpicking at an axiom with a bunch of nonsense about "fads," and completely missing my point in the process.
    - tabtab 8y ago
      Re: "let's subjectively evaluate language design based on my ideas of parsimony." -- I didn't claim that. I don't know where you got it. Note that "less code to do X" is often the claim made, and "code size" is probably the most objective metric available to compare techniques (but still imperfect). "Number of lines needing changes per change request X" is another. Other claim types such as "elegant" is often in the eye of the beholder. There is no universally accepted ruler (metric) for "elegant". And I'm not against SOME parallelism support in app languages. It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong. Re: "Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out." -- Fads tend to greatly increase the % of misuse. And lambdas and OOP do fight over similar territory, or at least can if the language has certain features. For example, Java coders may say, "I need lambdas here because OOP can't do what I need." But it turns out Java's OOP can't do what's needed, not something inherent in OOP. Anyhow, English is often not sufficient by itself to clarify such debates; we'd need specific code samples and scenarios to explore.
      - burntsushi 8y ago
        > And I'm not against SOME parallelism support in app languages. Once again, you said: > I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. So, what's your point? Every time someone talks about parallelism---whether it's legitimate or not---you see it as your duty to pontificate on the "fad" that is parallelism? You've completely and utterly missed my point, which had nothing at all to do with debating the legitimate use of paralleism in a specific case. That there are legitimate uses of parallelism is enough to make my point. > It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong. Again, so what? This has literally nothing to do with anything I've said in this thread. So, umm, thanks for derailing the conversation into your own pet cause? > And lambdas and OOP do fight over similar territory, or at least can if the language has certain features. For example, Java coders may say, "I need lambdas here because OOP can't do what I need." But it turns out Java's OOP can't do what's needed, not something inherent in OOP. Again, so what? This seems like a useless academic point. At no point did I invite such navel gazing.

by tabtab 8y ago

burntsushi 8y ago

I see your debates and raise you practice. I've done plenty of typical application development that makes practical use of lambdas and parallelism for great benefit.

tabtab 8y ago
I'm not saying they "don't work", only that other features/designs can often do them also without using/adding new constructs: parsimony of language features. Can you suggest a forum to continue such debates? If not, I'll see what I can find. (My past favorite forums died.)
- burntsushi 8y ago
  You've pretty drastically changed topics. I have no interest in a language design debate with someone who thinks of lambdas as "magic Legos." As I said before, our conceptions of reality are so drastically different that it would be a gratuitous waste of my time. You've gone from "parallelism is a fad" to "let's subjectively evaluate language design based on my ideas of parsimony." Parallelism isn't some kind of language feature I'm touting. It's an implementation tactic that can be used to make certain programs faster. Before such tactics were common, it was easy to write programs that were blissfully unaware of it in such a way that it is difficult to bolt on later. I used parallelism as one possible example of something that would be incredibly difficult to add to older programs to combat the notion that we should stop re-inventing the world and instead improve older stuff. Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out. Moreover, the degree to which parallelism can be wielded effectively will, in part, depend on your tools. Some tools make parallelism easier to use or reason about than other tools do. With that said, even that was immaterial to my point, because I wasn't doing a comparative analysis of parallelism across programming languages. I was just using it as an example of a concrete improvement that one could make to older programs that is often not practical to do, precisely because they are older programs that are widely used. Parallelism isn't the only example of this kind of improvement; jerf provided other examples in this thread. But parallelism is an easy one to grasp because most programmers with a few years of experience can appreciate what it's like to refactor a large program that is deeply coupled to unsynchronized shared global mutable state to a program that isn't---which is generally a good idea if you want to add parallelism to it. Your initial response to this was: > I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. But this is completely pointless. That parallelism is a useful way to make a program faster is taken as axiomatic in my comment. There is enough of my code (and others) out in the wild that uses parallelism to achieve some concrete measurable improvement that I feel it is obviously true and really doesn't need any further explanation. But here you are, nitpicking at an axiom with a bunch of nonsense about "fads," and completely missing my point in the process.
  - tabtab 8y ago
    Re: "let's subjectively evaluate language design based on my ideas of parsimony." -- I didn't claim that. I don't know where you got it. Note that "less code to do X" is often the claim made, and "code size" is probably the most objective metric available to compare techniques (but still imperfect). "Number of lines needing changes per change request X" is another. Other claim types such as "elegant" is often in the eye of the beholder. There is no universally accepted ruler (metric) for "elegant". And I'm not against SOME parallelism support in app languages. It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong. Re: "Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out." -- Fads tend to greatly increase the % of misuse. And lambdas and OOP do fight over similar territory, or at least can if the language has certain features. For example, Java coders may say, "I need lambdas here because OOP can't do what I need." But it turns out Java's OOP can't do what's needed, not something inherent in OOP. Anyhow, English is often not sufficient by itself to clarify such debates; we'd need specific code samples and scenarios to explore.
    - burntsushi 8y ago
      > And I'm not against SOME parallelism support in app languages. Once again, you said: > I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. So, what's your point? Every time someone talks about parallelism---whether it's legitimate or not---you see it as your duty to pontificate on the "fad" that is parallelism? You've completely and utterly missed my point, which had nothing at all to do with debating the legitimate use of paralleism in a specific case. That there are legitimate uses of parallelism is enough to make my point. > It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong. Again, so what? This has literally nothing to do with anything I've said in this thread. So, umm, thanks for derailing the conversation into your own pet cause? > And lambdas and OOP do fight over similar territory, or at least can if the language has certain features. For example, Java coders may say, "I need lambdas here because OOP can't do what I need." But it turns out Java's OOP can't do what's needed, not something inherent in OOP. Again, so what? This seems like a useless academic point. At no point did I invite such navel gazing.