50 comments
pieterbreed · 8 days ago
What the author did is cool in a social sense; lispers go on and on about homoiconicity, which here means that the original lisp code is data. The author uses this property by reading this code/data and transforming it into text, that represents syntax-full code. It is "cool" because it demonstrates the value of homoiconicity.

However; it's not cool in a technical sense. The result is not homoiconic any more. Code that had a cool property has been turned into code that does not, and the result looks like every other syntax-full blub language. The result destroys value.

Show replies

adz5a · 8 days ago
Interesting project, showing how "easy" it is to host[1] another language within Clojure. Like others, I admit I see little value for myself or as a selling point for beginners. For experienced engineers however, like I wrote above it should serve as a case study into how to hook up everything together to produce a working tool. Then it is a matter of seeing if and when there is opportunity to reuse such techniques to build DSLs that compile to native Clojure.

[1] Clojure is known to being designed to be hosted within another platform, but like all Lisps it is also a valid (and productive) hosting target by itself. It should be known that many of the APIs in the Clojure ecosystem rely either on:

- literal data structures - macros reusing native Clojure patterns / forms such as `let`, `def` ... - the shape of native (ie: defined within clojure.core) Clojure APIs, such as `get-in`, `with`...

Some examples: specter, integrant, mount, clojure.core.logic, datalog (datascript, datomic, xtdb), clojure.spec ...

yogthos · 8 days ago
I'd argue that the main thing this illustrates is how silly the argument that s-exps are hard to read is. A very slight syntactic change makes Clojure look just like Python. Anybody who claims they just can't wrap their head around writing Lisp is not being serious.

Show replies

benrutter · 8 days ago
This is really cool, I like it a lot! I don't think the parens in lisp are actually the problem, I think it's the embedding. I.e. List programps naturally tend to get very nested very fast, kinda like this:

(-

  (+ (* 3 4)

     (- 3 1))

  3)
It's just a simple sum, but reading it involves a lot of remembering contexts and how things should work in lisp. The CWP examples uses arrow/pipeline style macros a bunch, which are awesome! I kinda feel like they already solve the issues that a lot of people have with parens:

(->> 3

     (* 4)

     (+ (- 3 1)

     (- 3))
There's still a tonne of parens there, but the flow is a lot more readable for me.

Edit: sorry for the very difficult to read code formatting - couldn't figure out how to monospace things in hackernews.

Show replies

vim-guru · 8 days ago
The parenthesis are a strength that allows for faster editing and easier parsing. Although I respect every en-devour to have fun with code, I hope people don't run with this as a serious option. It would be better to have editor extensions that emulate this with regular Clojure code; that! I could get behind.