3 ms·

It's not a "forest of parens" any more than any language with C style syntax is, they're just in different places (the correct places) and there's no need to di

by F-0X 8y ago

It's not a "forest of parens" any more than any language with C style syntax is, they're just in different places (the correct places) and there's no need to distinguish with braces (which you shouldn't need to).

holografix 8y ago
That’s not true. When you’re passing functions to functions inside functions that return functions... it’s a nested mess. I studied Lisp and Scheme at university and that’s where it had to remain for me: academically entertaining mind puzzles in data structures and algorithms. It’s just not productive or easily graspable from one coder to another.
- taeric 8y ago
  Only if you insist on inlining all of the functions. Do yourself a favor and name a few of them. People that come after you will appreciate it, too.
- sooheon 8y ago
  Tasteful macros can alleviate this, and Clojure's std lib has a few which are just delightful. The following does exactly what you'd expect, and there are even cooler ones like `some->` or `as->`. (->> some-nums (map square-root) (filter even?) set count) This is what lisp buys you, dead simple rules for syntax, with the option to add syntax with macros. If you made a mistake in syntax design, deprecate the lib and make a new macro, it need not be a feature of core language for all eternity.
  - mschaef 8y ago
    And then you use a threading macro to assemble a middleware stack, only to find out that the middleware is applied in reverse order of what's listed as an inbound request comes in... (The outermost middleware being listed last in a threading form). There's a reason for it, for sure, but it's surely a part of the learning curve.
    - sooheon 8y ago
      Yep, it's always possible to have a mismatch in assumptions. That one definitely bit me as well. What's important is that the learning curve is not due to arbitrary rules, it's a faithful application of the logic of the macro. Remember that what is being passed through the threading macro is not the request, but the handler function itself. Each middleware takes the old handler, wraps itself over it to do things before and after the old handler. The threading macro is not a representation of the path your request will take, it is a way to build up a chained function that represents your final handler, which will then receive the request. Suddenly the ordering makes perfect sense :P

by F-0X 8y ago

holografix 8y ago

That’s not true. When you’re passing functions to functions inside functions that return functions... it’s a nested mess. I studied Lisp and Scheme at university and that’s where it had to remain for me: academically entertaining mind puzzles in data structures and algorithms. It’s just not productive or easily graspable from one coder to another.

taeric 8y ago
Only if you insist on inlining all of the functions. Do yourself a favor and name a few of them. People that come after you will appreciate it, too.
sooheon 8y ago
Tasteful macros can alleviate this, and Clojure's std lib has a few which are just delightful. The following does exactly what you'd expect, and there are even cooler ones like `some->` or `as->`. (->> some-nums (map square-root) (filter even?) set count) This is what lisp buys you, dead simple rules for syntax, with the option to add syntax with macros. If you made a mistake in syntax design, deprecate the lib and make a new macro, it need not be a feature of core language for all eternity.
- mschaef 8y ago
  And then you use a threading macro to assemble a middleware stack, only to find out that the middleware is applied in reverse order of what's listed as an inbound request comes in... (The outermost middleware being listed last in a threading form). There's a reason for it, for sure, but it's surely a part of the learning curve.
  - sooheon 8y ago
    Yep, it's always possible to have a mismatch in assumptions. That one definitely bit me as well. What's important is that the learning curve is not due to arbitrary rules, it's a faithful application of the logic of the macro. Remember that what is being passed through the threading macro is not the request, but the handler function itself. Each middleware takes the old handler, wraps itself over it to do things before and after the old handler. The threading macro is not a representation of the path your request will take, it is a way to build up a chained function that represents your final handler, which will then receive the request. Suddenly the ordering makes perfect sense :P