4 ms·
A somewhat similar thing I ran into is that existing Clojure code can be incredibly difficult to grok if you don't already know the language very well. Some of
by bunderbunder 2y ago
A somewhat similar thing I ran into is that existing Clojure code can be incredibly difficult to grok if you don't already know the language very well.
Some of this comes from lisp's minimalist syntax, which makes it hard to even know what kind of thing you're looking at when you're encountering a new thing for the first time. But the problem is also compounded by some of Clojure's more distinctive (and powerful) features such as ad-hoc polymorphism and using maps to pass function arguments.
The closest analogy from imperative languages that I can think of is another language that's famous for being incredibly productive in the hands of a skilled user, but whose code tends to feel kind of write-only: Perl.
- kazinator 2y agoIn Perl you have the dynamism, and the syntax. Evidently, 93% paint splatters, when OCRed, are valid Perl programs: https://www.mcmillen.dev/sigbovik/2019.pdf https://www.mcmillen.dev/sigbovik/2019.pdf I doubt that a similar thing is true for Clojure. Here, the only problem is that you don't know what the symbols and some of the notations mean. You can look at the unfamiliar syntax and know what is a child of what. Most operators are words you can search for.
- deleted 2y ago[deleted]
- slifin 2y agoIf I can get clojure storm running in my project then I find a lot of code incredibly straightforward Because there's a preference for just passing immutable data around the time travel debugger really helps me understand complex interactions