Prior to Clojure I feel that I didn't really know how to do things well.<p>In the context of the domain I have the most experience with, web applications, I'd summarize the bulk of programming as defining data, data transformations and shoving data through APIs. Once you get the hang of it, Clojure makes it trivial to transform datastructures from A to B. This has enormously expanded the kinds of problems I can solve.<p>When Rich says
"It was impossible to
avoid the sinking feeling that I had been “doing it wrong” by using C++/Java/C# my whole career."<p>I feel somehow that this is the case for the majority of people but they don't realize it yet because their experience is the most popular trendy language or framework. I've seen many examples of libraries in different languages having enormous amounts of commits and hundreds issues for problems that are trivial to solve in Clojure.<p>I was in the same boat, constantly grabbing for frameworks and if one wasn't available that made my task simple, would struggle trying to bend the frameworks or language I was using to come up with a solution.<p>I'm not a language geek and I don't write code outside my work for fun. I want to spend the least amount of time possible in front of the computer and sleep knowing my web applications won't topple over. Clojure has fit me so well that I don't think I would have accomplished what I have in other languages.
The fascinating thing to me about Clojure is that it's so vocally a "practical" language, and yet is a) a Lisp, and b) purely functional[1]. Usually those two things are associated with language enthusiasts, and not """pragmatic""" development. In the end it works, clearly, it's just very interesting to see that juxtaposition.<p>I think it says something interesting about the practical value of higher-brow programming concepts, but also about how important the packaging/marketing/ecosystem is to conveying that value and making it accessible to the masses.<p>[1] I know it's technically not 100% functional, but all of its messaging highlights that philosophy as a focal point and advantage.
Great story, really enjoyed reading. Rick Hickey is a great speaker (if you haven't watched his talks on youtube, do it! They are totally worth it), and certainly a great programmer, which is why I respect his opinions on dynamic typing, even if I stubbornly disagree (one day I might still dive into Clojure, but I am diving into the arguably opposite end of languages right now: Rust!!). I have even more respect for him now knowing that he actually worked on Clojure for years without any income!! This is a work of passion, and I admire him for that, and for being able to turn that passion into a company big enough to pay his bills and that of several of Clojure's early adopters.
I remember being at the first Clojure/conj - I had just spent some time learning a bit of Common Lisp and stumbled onto the conference announcement somehow.<p>This was very fortunate for me - after attending the conj, I was able to use Clojure at work to sneak in some FP on the readily-available JVM platforms. I later used it to do some internal REST-API work. The code for that project has run for <i>years</i> without modification or error.<p>For whatever reason, I also discovered that thinking functionally with Clojure worked so much better and naturally for me than object-oriented design methods. While I have drifted away from Clojure over the last couple of years, I find that my problem solving mind is much better in other languages because of the time spent thinking functionally with Clojure.
I was at a talk by Guy Steele where he mentioned in passing that Clojure was a Lisp which had done everything right. This was all the more impressive to him because Rich Hickey had until then been a relative outsider to the Lisp/Scheme community.
A great quote from the introduction, on why Rich took a sabbatical to work on Clojure:<p><i>...to give myself the opportunity to work on whatever I found interesting, without regard to outcome, commercial viability or the opinions of others. One might say these are prerequisites for working on Lisps or functional languages.</i>
> When I first was learning Common Lisp I was appalled at the tolerance on Usenet comp.lang.lisp of arrogance, hostility, intimidation and other anti-social behavior of the presumed ‘smartest guys in the room’. I was determined (a) that the Clojure community would not be hosted there and (b) that kind of behavior would not be tolerated.<p>Thank you, Rich Hickey!<p>The persistent data structures and functional core library are great, but many would not bother with Clojure if they had to deal with the toxicity that is present in the Common Lisp community.
I've been working with Clojure for a few years now, and the thing I love most about the language is how it nudges developers to write straightforward code. It's maybe closer to a well-structured procedural style than to highly indirect OO or to deeply polymorphic category-theory-inspired typed functional programming. The emphasis on mostly-first-order pure functions composed of other functions, receiving and returning immutable values, makes it easy to untangle even the worst balls of mud, while the well designed set of data-structures (few) and functions operating on them (many) allow for easy and terse expression of everyday data manipulation chores.<p>If we keep the majority of the code pure and straightforward, we can deal with state and I/O with other constructs, like atoms and records, only where we need to (doing this systematically tends to lead me to some variation of the functional-core/imperative-shell pattern).
STM, multimethods, macros and whatnot are cool and have their uses, but after a while I think the really cool thing is how little do we need to resort to fancy stuff and how much is accomplished with just functions and data.
I was super excited to see this paper released. I've spent time with Python, Java, C#, Javascript and limited time on C and Rust. Clojure was the largest paradigm shifter by a large margin.<p>Having done concurrent programming in Java, and even implemented some concurrency primitives like semaphores, Clojure was incredible to use. For those that don't know, Clojure uses immutable data structures that mitigate concurrency issues. If you are curious how that's even practical, I highly recommend the paper and also reading about Persistent Data Structures. They reuse shared data, similar to how Git only tracks the delta's between commits, rather than multiple, full copies of the file.<p>On top of that, you up reducing lines of code by 60-70% of traditional Java or C#.
Thanks to Clojure (and ClojureScript), I was able to build my self-funded SaaS business. There is no way I would have been able to tackle the complexity without Clojure.<p>I also love the mature approach and mature community. It is, quite simply, a different world from most other software places, and one I enjoy a lot, as I'm mostly focused on building and shipping a large and complex codebase with an extremely small team.
I see nothing but praise for Clojure and for good reason. I experimented with it a bit a few years ago and it seemed to be a more practical and useful version of Lisp, although I say that as someone who wasn't that experienced in Lisp more generally, with only some small experiments in Scheme. Something just as significant was that the ecosystem seemed to be quite sane and I got on really well with Leiningen for example, if you were considering diving in then give it a go.<p>I personally won't consider it now but not because of the language or the ecosystem but because of the runtime(s). For me the layers of abstraction are too much complexity to not be justified.
I love clojure the language but hate the tooling.<p>Also a lack of documentation was always a problem, especially around clojure script.<p>I also don't like smug community. When you say about the lack of documentation and get told that's a good thing, clojure is meant to be hard to learn, it's not for everyone and maybe you just aren't smart enough...<p>Hmmm. That attitude might put people off.
I used Clojure a lot back in the beginning (contributed a little money, used Clojure fairly intensely on two long term consulting projects). Before that I used Rich's Common Lisp to Java bridge project. I think his impact goes far beyond just Clojure users, having helped push immutable by default, etc. as standard good practices.<p>I moved away from Clojure because I wanted to move away from the JVM. I did a fun project, a nutrition/cooking web app [1] about 12 years ago in Clojure, but I am slowly porting that from Clojure to Common Lisp for another example program for my book [2]. Perhaps not as well known, but Clojure joins other less commonly used languages like Haskell as languages with fairly good support for deep learning. I feel like any language that does not have a good deep learning story will be limited. Also interesting that Swift has such good access to Apple's deep learning libraries and also a version of TensorFlow. I encourage Clojure developers who work on deep learning support!<p>[1] <a href="http://cookingspace.com" rel="nofollow">http://cookingspace.com</a>
[2] <a href="https://leanpub.com/lovinglisp" rel="nofollow">https://leanpub.com/lovinglisp</a>
I've been here for the entire journey, but no one can summarize it quite like Rich. And I bet he could write twice that just on nurturing a community - He spend hours and hours on IRC in the early days, coaching, teaching, correcting and even admonishing bad behavior. He's truly done something remarkable in both building this powerful language that I use daily, and a very helpful, friendly and intelligent community around it.
A great read! What I really appreciate, beside all the technical stuff, is the effort to create a positive and helpful community around Clojure.<p>From the paper: "When I first was learning Common Lisp I was appalled at the tolerance on Usenet comp.lang.lispof arrogance, hostility, intimidation and other anti-social behavior of the presumed ‘smartest guys in the room’. I was determined (a) that the Clojure community would not be hosted there and (b) that kind of behavior would not be tolerated. Early on, on IRC and the mailing list, I established and required a tone of supportiveness, positivity and respect."
I fell in love with Clojure and fell out of it. It is a great language. Lisps have this inherent elegance to them especially in data transformation pipelines.<p>That said I found its performance still a bit on the wanting side particularly if you avoid type hints. For many tasks the performance is probably acceptable but the backend work I tend to do makes the abstract style get in the way of trying to figure out performance issues.<p>Also I'm coming around to the imperative style more and more. Sometimes a for loop is all that's needed and makes for a more understandable code than all those hipster maps and folds.
Section 2.4 of the paper gave me a chuckle. Like Rich, I've yet to write a program that didn't involve some kind of database. Organizations care about data not programs. Writing programs just gives them a way of applying organization-specific rules, in the way of transformations, to the data.
Thanks to Rich for designing and thanks to Alex & Rich (and others) for maintaining. It is my favorite language thus far out of (Java, Ruby, Python, Bash, Awk, Erlang, Swift, Tcl and Objective-C).
Has anyone used Clojure much? I love Rich's talks so I've been very interested in it but there are so many great languages to learn these days.
This is superb, and I'm only on page two. I'm thankful that Rich finds the time to produce his thoughtful content and I hope he has the opportunity to present this at HOPL-IV when it is rescheduled.<p>The distinction between Information Systems and Artificial Systems is the key point to me and reflects my experience, not that I understood it at the time.<p>I use Clojure today because it is a better thinking toolkit for Information Systems (or the inelegant 'Products' as I defined them in my conj talk). I'm an order of magnitude more productive in Clojure than I was in Java. It's not a small step, it's a step-change.
All right. That's it. I'm porting over all my code to Clojure.<p>Any tips to get me started? I'm writing a web app to process DAG-formatted data.<p>EDIT: Looking at re-frame + reagent 'cause I have some React background. I also found The Joy of Clojure and Elements of Clojure from other threads. Anything else I should know before diving in? (Past experience: Haskell, Python, C#, JS)
Sometimes when we have created things with code, we wipe the sweat from our foreheads and feel proud because it was kind of hard.<p>Usually when I have created something with clojure I feel disappointed because it was so easy.