4 ms·

Hickey wrote it once, and now you don't have to. But Steele is talking about introducing fundamental new constructs all the way up to the application level. Th

by gruseom 17y ago

Hickey wrote it once, and now you don't have to. But Steele is talking about introducing fundamental new constructs all the way up to the application level. This is not a problem that can be abstracted away by better language implementations, and certainly not by better implementations of familiar constructs.

apgwoz 17y ago
> and certainly not by better implementations of familiar constructs. Why not? I sort of took the slides as just that. For a good chunk of the slides he talks about the simple singly-linked list found in LISP. Then shows that implemented as a Tree (conc list), familiar operations still exist, but we get improvements by making operations more parallelizable. Slide 24 starts showing how `first`, `rest`, `append` can be implemented with conc lists, and 31 shows `map`, `reduce`, `mapreduce` as well. Then, he goes on to show `length`, `filter` and `reverse` in terms of `mapreduce`.
- gruseom 17y ago
  Why not? Well, if first and rest are unsuitable for parallelism as Steele says, a programming edifice built on top of better implementations of those might be beside the point. My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before; what we need is a new set of primitives (modeled by conc lists in this talk) that would allow us to compose programs differently, with more parallelism. And that far from being insulated from this, programmers will have to be thinking about it throughout. It's possible that Clojure's implementation is already such that these primitives, and a programming style built on them, are feasible today. If so, that's awesome. But this is a different thing than providing better implementations of cons-based abstractions. Edit: another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one?
  - mquander 17y ago
    > It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one? Now that is food for thought.
    - doelie_ 17y ago
      Concatenative / point-free style? Guy already suggests this on p.68. Paraphrased, if data can be chopped in pieces, maybe code can too?
  - herdrick 17y ago
    I don't think so. Lisp code is already a tree.
    - gruseom 17y ago
      It's a tree in the sense that a list is a tree.
      - herdrick 17y ago
        No, it's really a tree structure. In fact lisp code is much like the abstract syntax tree that you get when you parse other languages.
  - apgwoz 17y ago
    > My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before; Yes, I agree he was saying that, but that doesn't mean we can't change the implementations of what we use now to actually make it easier to do accomplish this. > another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one? But, you could still implement car and cdr in terms on conc, so this is not really an issue. It might not be the most efficient thing, but that's sort of the benefit of macros. Expand at compile time, and avoid the overhead. So, in summary, write macros in terms of an emulated cons cell, and use conc optimized primitives elsewhere.

by gruseom 17y ago

apgwoz 17y ago

> and certainly not by better implementations of familiar constructs. Why not? I sort of took the slides as just that. For a good chunk of the slides he talks about the simple singly-linked list found in LISP. Then shows that implemented as a Tree (conc list), familiar operations still exist, but we get improvements by making operations more parallelizable. Slide 24 starts showing how `first`, `rest`, `append` can be implemented with conc lists, and 31 shows `map`, `reduce`, `mapreduce` as well. Then, he goes on to show `length`, `filter` and `reverse` in terms of `mapreduce`.

gruseom 17y ago
Why not? Well, if first and rest are unsuitable for parallelism as Steele says, a programming edifice built on top of better implementations of those might be beside the point. My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before; what we need is a new set of primitives (modeled by conc lists in this talk) that would allow us to compose programs differently, with more parallelism. And that far from being insulated from this, programmers will have to be thinking about it throughout. It's possible that Clojure's implementation is already such that these primitives, and a programming style built on them, are feasible today. If so, that's awesome. But this is a different thing than providing better implementations of cons-based abstractions. Edit: another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one?
- mquander 17y ago
  > It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one? Now that is food for thought.
  - doelie_ 17y ago
    Concatenative / point-free style? Guy already suggests this on p.68. Paraphrased, if data can be chopped in pieces, maybe code can too?
- herdrick 17y ago
  I don't think so. Lisp code is already a tree.
  - gruseom 17y ago
    It's a tree in the sense that a list is a tree.
    - herdrick 17y ago
      No, it's really a tree structure. In fact lisp code is much like the abstract syntax tree that you get when you parse other languages.
- apgwoz 17y ago
  > My understanding of the slides is that we don't need better language runtimes to exploit parallelism for us while we continue to write the same kind of code as before; Yes, I agree he was saying that, but that doesn't mean we can't change the implementations of what we use now to actually make it easier to do accomplish this. > another thing - the transformation from cons to conc is nontrivial in the Lisp context because Lisp's code=data is so tied to cons. It might be an interesting to think about what programs would look like if you applied code=data rigorously in a conc model. Would a language whose expressions are represented as concs look or feel significantly different than a cons-based one? But, you could still implement car and cdr in terms on conc, so this is not really an issue. It might not be the most efficient thing, but that's sort of the benefit of macros. Expand at compile time, and avoid the overhead. So, in summary, write macros in terms of an emulated cons cell, and use conc optimized primitives elsewhere.