4 ms·

I'm not sure I follow, can you elaborate? I think something similar could be done in CL, although some of the design decisions might be different because Cloju

by w01fe 14y ago

I'm not sure I follow, can you elaborate? I think something similar could be done in CL, although some of the design decisions might be different because Clojure has nice map literals and function metadata.

dschiptsov 14y ago
I'm trying to get what all excitement is about. "We have put functions and data in the same graph-like data-structure because Clojure is so cool"?)
- w01fe 14y ago
  No, this isn't just about Clojure. You could do similar things in Scheme, or CL, or even Python or Ruby. What's cool about this isn't that we've managed to put functions in a data structure. It's that doing this in a particular way allows us to describe computations in a declarative way. This declarative specification opens up lots of interesting avenues to do new things with our code that weren't available before. Of course the idea of declarative programming isn't new either, but we think this particular instantiation is cool because it's extremely simple and close to the language. Writing a Graph doesn't feel any heavier than writing the corresponding non-declarative code, and this is crucial for making it actually useful in many kinds of situations (rather than just cases where heavy lifting is necessary, like distributed stream processing for example).
  - dschiptsov 14y ago
    Yes, using code as data and creation of the code when a program is running is the most powerful feature of Lisps. My point is that Clojure isn't a Lisp and JVM isn't the best possible platform, and embedded in a Lisp DSLs are even more powerful because of the common (for code and data) underlying data structure - conses. Of course, I know the counter-points about "Java is everywhere" and "Interloop with existing Java code". As of heavy lifting or whatever to call it, decent CL implementation would be faster (compiled native code), consume much less resources (predictable memory allocation patterns), and more manageable (behavior much less depended of the system load and how other processes behave).
    - w01fe 14y ago
      I programmed in CL for several years exclusively, and think it's an awesome language. But I also really love Clojure, and think it's the the most beautiful Lisp (or S-expression-oriented language with a read-eval-print loop, if you prefer) I've had the opportunity to explore. To each their own.
      - dschiptsov 14y ago
        Thank you for an alternative definition. In my opinion adding more data-structures into a Lisp ruins it. It is a List Processing, for John's sake.) More seriously, having exactly one common data-structure for code and data is what holds everything together, the source of power, compactness, elegance and readability. A small additional effort, a self-discipline of using lists correctly (remembering the costs) everywhere and using hash-tables and arrays only when absolutely necessary is the way to write decent Lisp code. In case of Clojure it is just a mess.
    - Confusion 14y ago
      Please cut out the CL evangelizing. Go play with your muddle of Turing tarpits made of conses.
      - dschiptsov 14y ago
        Oh, of course, cluttering the code with explicit conversion from one data-structure into another is a much better way, much more lines of code, bigger self-esteem, better salary. Java world. There is an example (very clever, no doubts) (defn keywordize-map "Recursively convert maps in m (including itself) to have keyword keys instead of string" [x] (condp instance? x clojure.lang.IPersistentMap (for-map [[k v] x] (if (string? k) (keyword k) k) (keywordize-map v)) clojure.lang.IPersistentList (map keywordize-map x) clojure.lang.IPersistentVector (into [] (map keywordize-map x)) x)) btw, this code is really clever, while in typical clojure project there are tons of meaningless conversions.
        14y ago

by w01fe 14y ago

dschiptsov 14y ago

I'm trying to get what all excitement is about. "We have put functions and data in the same graph-like data-structure because Clojure is so cool"?)

w01fe 14y ago
No, this isn't just about Clojure. You could do similar things in Scheme, or CL, or even Python or Ruby. What's cool about this isn't that we've managed to put functions in a data structure. It's that doing this in a particular way allows us to describe computations in a declarative way. This declarative specification opens up lots of interesting avenues to do new things with our code that weren't available before. Of course the idea of declarative programming isn't new either, but we think this particular instantiation is cool because it's extremely simple and close to the language. Writing a Graph doesn't feel any heavier than writing the corresponding non-declarative code, and this is crucial for making it actually useful in many kinds of situations (rather than just cases where heavy lifting is necessary, like distributed stream processing for example).
- dschiptsov 14y ago
  Yes, using code as data and creation of the code when a program is running is the most powerful feature of Lisps. My point is that Clojure isn't a Lisp and JVM isn't the best possible platform, and embedded in a Lisp DSLs are even more powerful because of the common (for code and data) underlying data structure - conses. Of course, I know the counter-points about "Java is everywhere" and "Interloop with existing Java code". As of heavy lifting or whatever to call it, decent CL implementation would be faster (compiled native code), consume much less resources (predictable memory allocation patterns), and more manageable (behavior much less depended of the system load and how other processes behave).
  - w01fe 14y ago
    I programmed in CL for several years exclusively, and think it's an awesome language. But I also really love Clojure, and think it's the the most beautiful Lisp (or S-expression-oriented language with a read-eval-print loop, if you prefer) I've had the opportunity to explore. To each their own.
    - dschiptsov 14y ago
      Thank you for an alternative definition. In my opinion adding more data-structures into a Lisp ruins it. It is a List Processing, for John's sake.) More seriously, having exactly one common data-structure for code and data is what holds everything together, the source of power, compactness, elegance and readability. A small additional effort, a self-discipline of using lists correctly (remembering the costs) everywhere and using hash-tables and arrays only when absolutely necessary is the way to write decent Lisp code. In case of Clojure it is just a mess.
  - Confusion 14y ago
    Please cut out the CL evangelizing. Go play with your muddle of Turing tarpits made of conses.
    - dschiptsov 14y ago
      Oh, of course, cluttering the code with explicit conversion from one data-structure into another is a much better way, much more lines of code, bigger self-esteem, better salary. Java world. There is an example (very clever, no doubts) (defn keywordize-map "Recursively convert maps in m (including itself) to have keyword keys instead of string" [x] (condp instance? x clojure.lang.IPersistentMap (for-map [[k v] x] (if (string? k) (keyword k) k) (keywordize-map v)) clojure.lang.IPersistentList (map keywordize-map x) clojure.lang.IPersistentVector (into [] (map keywordize-map x)) x)) btw, this code is really clever, while in typical clojure project there are tons of meaningless conversions.
      - 14y ago