5 ms·
I think the most important part about Clojure is how ridiculously straight forward it is. Once your REPL is set up and you got used to the predominantly functi
by dgb23 6y ago
I think the most important part about Clojure is how ridiculously straight forward it is.
Once your REPL is set up and you got used to the predominantly functional API and its vocabulary, you are dealing with an extremely simple, data-driven environment that (almost) never gets in the way.
Part of that is due to deviations from traditional Lisps: a more human readable API (first, rest etc.) and less homoiconicity (data structure syntax). But also things like the first class support for names, a baked in, dead simple STM...
For me, this is the reason why it is so practical. I'm not good at top-down programming. I can think of and design a system or solution in an abstract way to get a sense of direction.
But when it comes to writing code I have to look at small, simple things in isolation, look at the results, change the shapes and build something up.
Clojure is very, very good at enabling this kind of dumb, simple, learning-by-doing approach of programming, because everything just works, is easily decomposed and merged together again, with very little ceremony or friction.
And when the simple approach reaches its limitations, then there are these extremely expressive tools like multiple dispatch, macros, transducers, spec etc. which all go beyond what most mainstream languages give you.
- junke 6y agoThis is a minor nitpick but please check your facts about other Lisps when comparing them with Clojure. > Part of that is due to deviations from traditional Lisps: a more human readable API (first, rest etc.) first, second, rest ... are defined in Common Lisp > and less homoiconicity (data structure syntax). Clojure is no less homoiconic, you just write vector literals in your code; you could write vector literal to represent code in Common Lisp too, but in fact [], {} etc. are not used by default in CL because they are reserved for the user, so that it can be used for domain-specific purposes.
- dgb23 6y agoThank you for those corrections. My limited Lisp experience before Clojure was with Scheme a very long time ago. I shouldn’t have made these false, blanket statements. Those can be harmful for discussion. In fact I know from reading about CL that it is extremely malleable and that you would be hard pressed to find features that are not present or possible there.
- kazinator 6y ago> I know from reading about :)
- okareaman 6y ago> homoiconicity (data structure syntax) Can someone explain to me why we need a murky word like "homoiconicity" and then explain it as "data structure syntax" (which doesn't clarify much) when "self-modifying code" and "metaprogramming" are crystal clear?
- zodiac 6y agoBoth "self-modifying code" and "metaprogramming" don't mean exactly the same thing to me as "homoiconicity"
- okareaman 6y agoI guess I need to learn Lisp to understand the distinction. My only reference is XLST which is also valid XML. https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity
- zodiac 6y agoWell, it depends on your exact definition of "self-modifying code" and "metaprogramming", given that it's not like there's an authoratative source you can look up the definitions in. The way I understand the term without additional context, XLST is not "self-modifying code" in the same way malware, certain JIT implementation techniques etc are.
- wtetzner 6y agoHomoiconicity means you're code is defined in terms of the same data structures that are used in programs written in the language. This makes self-modifying code and metaprogramming easier because the language's standard library is already full of functions that operate on those data structures. However, you can have self-modifying code and metaprogramming without homoiconicity, and you can have homoiconicity without support for self-modifying code and metaprogramming.