4 ms·

Guile has [multi-methods][1] and [fast hash maps][2], but not yet [dynamic vectors][3]. Clojure's data structures are easier to use, though. [1]: https://www.

• exabrial 1y ago
  Clojure is such a departure for me, coming from C-Like languages. I have absolutely no idea whats going when looking at the code.
  • rufusthedogwoof 1y ago
    it's not code it's data. :) -macro
  • roenxi 1y ago
    Fun fact: the big difference isn't the syntax. Lisps only go from foo(bar baz) to (foo bar baz) which is a change but not really much of one. The change is actually the immutable and high performance basic data structures. Clojure can do something that something like C can't do - cheaply create a copy of something with a small change. That leads to a completely different preferred code style in the Clojure community that is a big departure from C-like languages which make heavy use of variables. The code is doing something practically different from what a C-like language can ergonomically handle.
    • Zambyte 1y ago
      Clojure has a bunch of other syntactic structures not found in other lisps that makes it a lot more visually noisy. I'm very comfortable with Scheme and I can very quickly absorb Scheme code when reading it, but I have to very slowly decipher the code in the article.
      • iLemming 1y ago
        > not found in other lisps that makes it a lot more visually noisy I disagree. It only feels that way, until you learn how destructuring works in Clojure. Once you grok that, you'd understand why the vector syntax for function arguments was chosen, and not a simple list like in other Lisps. In general, Clojure is highly pragmatic - if something done certain way, most-likely it's for good reasons, and not by accident. Also, Clojure-maps are just freaking amazing. I wish others, e.g., Elisp had them. Clojure is extremely and nicely readable, just requires some getting used to it. At some point, I completely replaced my API-testing workflows, switching from JSON to EDN - it's almost twice more compact and much better visually, not to mention that it's incredibly nice to be able to just explore and visualize any given data through the REPL.
        • Zambyte 1y ago
          > It only feels that way, until you learn how destructuring works in Clojure Well... yes. The original comment was about how Clojure code looks very foreign. The reply to that was that Lisp code is not actually that foreign because it's just taking the common foo(bar baz) and making it (foo bar baz). My comment was that Clojure is more foreign to most programmers than other Lisps, because it's not simply mapping foo(bar baz) to (foo bar baz). Of course when you learn the things that make it unique, it becomes familiar.
  • JoshCole 1y ago
    Lisps (like Clojure) treat code as data (lists), so you write: `(if x (y) (z))` instead of Python’s `y() if x else z()`. So the code is more concise, but does less to walk a novice through it. This gains a huge advantage, which allows even more concision: all code is data, so its easy to transform the code. In Clojure if you want to add support for unless, a thing like if, but evaluating the opposite way you could do this: `(defmacro unless [p a b] `(if (not ~p) ~a ~b))`. Obviously if you wanted to do the same thing in Python you would in practice do `z() if x else y()`. However, you would do it that way because Python isn't as powerful a language. To actually do the same thing in Python you would need to... 1. Add __future__ support. 2. Update the Python language grammar. 3. Add a new AST type. 4. Add a new pass stage to the compiler. 5. Add a python library to integrate with this so you could use it. Then you could do something like: from __future__ import macros defmacro unless(pred, then: block, else_: block = []): return q[ if not u(pred): u*(then) else: u*(else_) ] So in the trivial case its just hundreds of lines harder plus requires massive coordination with other people to accomplish the same feat. This sort of, wow, it takes hundreds or thousands of lines more to accomplish the same thing outside of Lisp as it does to accomplish it within Lisp shows up quite often; consider something like chaining. People write entire libraries to handle function chaining nicely. `a.b().c().d().map(f).map(g)`. Very pretty. Hundreds of lines to enable it, maybe thousands, because it does not come by default in the language. But in Lisp? In Clojure? Just change the languages usual rules, threading operator and now chaining is omnipresent: `(->> a b c d e (map f) (map g))`. Same code, no need to write wrapper libraries to enable it.
    • roenxi 1y ago
      That doesn't look like a factor in the article though, he isn't using many if any macros that aren't part of the core language. And the one macro I do spot (defcfn) is pretty mild in context.
      • sabellito 1y ago
        I've programmed in Clojure professionally. People like GP often repeat that talking point: "code is data so that's amazing because of macros". In practice, by and large, with very few exceptions, macros are frowned upon in the same way that using metaprogramming in ruby is. Macros are only fun to the person writing them (and not even the author when they have to maintain it). Macros can almost always be expressed with a simple function and remove all the unexpectedness without losing anything. Again, there are some exceptions.
  • iLemming 1y ago
    That's just existing muscle memory. Nothing is wrong with you and nothing is wrong with Clojure. I had the same feeling when I started with Lisp. Give it some time, it's absolutely worth it. Interestingly, every single programmer I introduced to Clojure as their very first programming language had no issues picking it up. Later, they complained about difficulties getting used to Javascript and Python.
  • pjmlp 1y ago
    Many of Lisp ideas are possible in C++, but I guess that depends how much you know it.
• wedesoft 1y ago
  Yes, I forgot. However Clojure multi methods are more generic in that the function computing the dispatch value can also be defined.