4 ms·

Clojure has this advantage of Java Interop. So even if you didn't find native Clojure libraries, you can always find Java libraries. And you will find Java libr

• lispm 8y ago
  https://abcl.org https://abcl.org
• TeMPOraL 8y ago
  Sort of. Java interop is an extra win for Clojure, but I really meant just the Clojure libraries. Every time I need one, it seems much more feature-complete than CL alternative. To take an example: in a project I'm working on, we're using Ring[0] at the backend + bunch of middleware, including Liberator[1]. Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that, with so much thought that went into it? Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free. Etc. This kind of story seems to repeat every time I need a library. In Common Lisp, you have to hope that Edi Weitz, Shinmera or Fukamachi wrote something, and that you won't have to patch much to make it work for you. In Clojure, everything I've seen so far[3] makes me expect to find solid and feature-complete libraries whenever I need something. Now to be clear, I still love working in Common Lisp. It's just that my experience with Clojure made me jealous. -- [0] - https://github.com/ring-clojure/ring https://github.com/ring-clojure/ring [1] - https://github.com/clojure-liberator/liberator https://github.com/clojure-liberator/liberator [2] - http://clojure-liberator.github.io/liberator/ http://clojure-liberator.github.io/liberator/ [3] - I've been writing Clojure for only couple of months, so this may be colored by first impressions.
  • flavio81 8y ago
    >we're using Ring[0] at the backend >Ring is a Clojure web applications library inspired by Python's WSGI and Ruby's Rack. We have had this on the Common Lisp world for years, see "Clack" and "Lack" -- two libs that work together and do exactly this. > Take a look at e.g. Liberator docs[2] and tell me, where's a CL library for just that If you want exactly a "Liberator" in Common Lisp, there has been a good one for 3 years on: https://github.com/joaotavora/snooze https://github.com/joaotavora/snooze Note how Snooze uses Clack. Clack is almost a de-facto standard now. To be honest, REST services can be done with a regular web development routing lib. >Or, in a CL project we had to implement CORS handling ourselves, whereas in Clojure we get it for free But it's only adding a few headers to your HTTP headers... Patching the response handler to add those is an easy task in CL (Clack already has the facilities to let you add middlewares into the response handler), does one really need a library for that? I don't want to sound arrogant, but the complains seem a bit exaggerated.
• flavio81 8y ago
  >Clojure has this advantage of Java Interop. So even if you didn't find native Clojure libraries, you can always find Java libraries. You can do exactly the same in Common Lisp, by using ABCL. I am a happy "customer". (ABCL is free)
• village-idiot 8y ago
  Interestingly enough, I actually worked in both CL and Clojure professionally. Clojure for certain feels much more modern. They actually have modern build tools, logging systems, and testing frameworks, which is nice. The emphasis on more data types than just linked lists was amazing, sometimes you just need a hashmap, and Clojure's worked great. The rate of progress on the build tools was frankly spectacular, and some of my favorite libraries in the world are available in Clojure (core.logic anyone?) The Clojure community has an approach to libraries that is utterly unique in my experience, and I miss it in other languages. Clojure libraries are the most lightly coupled libraries I've ever seen, as they use data as the API (a very Clojure and very Rich Hickey thing to do), which makes tying libraries together a trivial and reliable thing to do. They also have a habit of finishing libraries and not arbitrarily creating competitors for whatever reason. The result is that there are a lot of Clojure libraries that are narrowly scoped, feature complete, and trivial to upgrade if necessary. I really miss that. Clojure also had some downsides however, both for how we used it and in general. The team that I worked on with it is now mostly Java these days. Domain specific issues. If you have a bunch of objects that are similar syntactically, but vary semantically, you do not want to use Clojure. Clojure has very poor structures for handling this kind of stuff, and it's very very easy to accidentally go from your pretty record type back to a regular persistent hashmap on accident. Basically Clojure encourages (although does not strictly enforce) hashmap oriented programming. There are some domains where this is fine, but ours was decidedly not one of them. Guidance wise, interacting with Clojure maintainers was rough. It's their project and they can guide it how they want, and we just got the feeling that they couldn't give a rip about what anyone else wanted. That's their right, but it was super annoying as an end user of the products that they were pushing so hard. We never really had any luck getting any of the bugs or issues that we found dealt with by the core team. We got the distinct impression that they were running the code we submitted and then deciding post-facto that what the code did was exactly what they'd wanted in the first place, but proving that is of course impossible. It's been a few years since I last tried to talk to them, so it's entirely possible that this has turned around since then. I quit that job before Spec was released, so I cannot really comment on how effective that is in bullet-proofing a Clojure code base. What I can say is that the core Clojure libraries are wildly type unsafe, to a degree that's really only beaten by PHP. There are a ton of core functions that'll change output types without warning, sometimes in several different ways. Nominally this is fine because all the collections are built on top of the seq abstraction, but in reality that abstraction is as leaky as they get. The result is that our code base was littered with "(map identity x)" and "(vec y)" and "(into {} z)" to handle all these little weird edge cases. My suspicion is that Spec is a tacit admission that these little type errors really get out of control in a larger Clojure code base, and they're trying to fix it without having to revamp the entire core library. That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.