4 ms·

I don't think this snarky remark is warranted. I think the point was that in Lisp-style languages (such as Clojure/ClojureScript) new features such as pattern m

by jwr 9y ago

I don't think this snarky remark is warranted. I think the point was that in Lisp-style languages (such as Clojure/ClojureScript) new features such as pattern matching can easily be added without "changing the language", as libraries. This is how core.async was added to Clojure, to pick a non-trivial example. Or more to the point, how core.match works. Additions such as those do not have to be one lonely programmer's macros, they can be libraries widely accepted by the community. I had a similar thought when reading the ECMAscript extension proposal: I'm glad that in the languages I use, features like that can be provided by libraries.

emodendroket 9y ago
Yes, but I think the other point is well-made, as well: languages that allow this can be very difficult to work in if you have to maintain a large app with multiple contributors over a long period of time.
- heretoo 9y ago
  The same can be said for function calls, with the indirection they create hiding details of broken and side-effecting implementations. None the less, the opposite is also true. Languages that have macro facilities can aid in writing more legible code. (See `threading` in clojure), or the `loop` macro and regular expression macros in common lisp.
  - Roboprog 9y ago
    Well said. Rambling Java code with little to no abstraction is its own kind of nightmare. Some people are just terrified of any new abstractions, I guess, preferring to work with an endless series of tally marks, rather than these obfuscating “multiplication” and “exponent” complications (exaggerating to make a point - abstract != unintelligible).
    - emodendroket 9y ago
      I think there is probably some middle ground between "no abstraction at all" and "literally anything goes."
      - Roboprog 9y ago
        LCD? Alas, that tends to be the steady state for Enterprise development :-( (I know that’s not literally what you said, but that’s where that “middle ground” attitude leads to: the bottom)

by jwr 9y ago

emodendroket 9y ago

Yes, but I think the other point is well-made, as well: languages that allow this can be very difficult to work in if you have to maintain a large app with multiple contributors over a long period of time.

heretoo 9y ago
The same can be said for function calls, with the indirection they create hiding details of broken and side-effecting implementations. None the less, the opposite is also true. Languages that have macro facilities can aid in writing more legible code. (See `threading` in clojure), or the `loop` macro and regular expression macros in common lisp.
- Roboprog 9y ago
  Well said. Rambling Java code with little to no abstraction is its own kind of nightmare. Some people are just terrified of any new abstractions, I guess, preferring to work with an endless series of tally marks, rather than these obfuscating “multiplication” and “exponent” complications (exaggerating to make a point - abstract != unintelligible).
  - emodendroket 9y ago
    I think there is probably some middle ground between "no abstraction at all" and "literally anything goes."
    - Roboprog 9y ago
      LCD? Alas, that tends to be the steady state for Enterprise development :-( (I know that’s not literally what you said, but that’s where that “middle ground” attitude leads to: the bottom)