I've said it before and I'll say it again, the industry can rip Clojure from my cold, dead hands. It's unfortunate that people in this thread seem to down on the language, but the only possible way I would stop using it is if I literally cannot earn income with it. It is by far the most pleasant language I've ever used, I feel at home writing it, and it improves the quality of my work.
I've said it before and I'll say it again, the industry can rip Clojure from my cold, dead hands. It's unfortunate that people in this thread seem to down on the language, but the only possible way I would stop using it is if I literally cannot earn income with it.
Some superstitious people would say, don't tempt fate by saying that out loud!
It is by far the most pleasant language I've ever used, I feel at home writing it, and it improves the quality of my work.
Very familiar. Be sure to diversify. (Ex Smalltalker here.)
>>Very familiar. Be sure to diversify. (Ex Smalltalker here.)
Very true. Coming from a Ex Perl programmer.
Though Perl is still around and you can solve problems using it for everyday work. But you will hard pressed to find a job that requires you writing or maintaining Perl code.
And yeah, like I said elsewhere I know my way around Python quite well and it's impossible to write a lot of Clojure and not know Java too. If both of those end up dying along with Clojure down the line then I'll be in a bad spot. :)
I am not disagreeing nor challenging you; I'm happy you like it and I think you should keep using it since you enjoy it so much. My question is: Wouldn't the same be said by most programmers with a high degree of proficiency with a language? What sets Clojure apart from Haskell or Scala or Elixir or Erlang? Do you have a high degree of proficiency with something else?
Clojure is the language that I have always wanted to learn, but the benefits never seemed very apparent. I'm hoping your response will make them clear.
Some experienced devs might say the same thing if they've also found a language that just clicks with them as I have.
Clojure is a locus of things I really, really like and I have no reason to change despite the recent FUD around it. Namely: Lispiness, dynamic typing, functional programing, immutability, lean pragmatic design, and it runs on the JVM. I haven't seen anything that compares to it in these regards that also has the community support that Clojure has (great projects like Leiningen, Lacinia, and so on).
I've tried Haskell but felt I was fighting the compiler due to the static typing (I hate static typing). It also felt like it was designed for eggheads and not people like me just doing a job. Scala feels like it doesn't know what it wants to be when it grows up. Elixir and Erlang are neat but I haven't had a chance to really try them out, but Elixir's choice to emulate Ruby-like syntax is unfortunate.
That said, I do have a high degree of proficiency with Python, which shares dynamic typing and kinda-functional programming with Clojure. Python was my language of choice for years before I finally gave Clojure a try, and I haven't really looked back. The poor handling of the Python 3 switch really soured me to Python.
I also did a good chunk of Go, but the static typing and syntax weirdness just killed it for me. Amusingly, Go seems to have a similar "ivory tower" approach to language design to Clojure - which indicates that type of management isn't really a problem for me.
My question for you would be, why Clojure over, say, Racket? Is it just the JVM?
I personally prefer Racket because of the ease with which you can use it to hack on itself. Macros are no stranger to LISPs, but Racket goes beyond by having the entire system around it built to accommodate language design and modification.
Want to use dynamic typing? Just use #lang racket. Want to use static type checking? Use #lang typed/racket. Reactive programming is there with #lang frtime. And that's before we even consider things like Scribble.
As an aside, I totally agree with you on Elixir. Erlang is wonderful for what it's built for. Elixir's choice to use Ruby syntax, however, ruins Elixir for me -- and it's not because I hate Ruby. I actually like Ruby a fair deal. Instead, it's because using Ruby syntax makes it more difficult (for me) to truly and fully think in the paradigm. Erlang/Elixir are nothing like Ruby. Making the syntax Ruby-like just obfuscates what's actually going on in the system. (I find similar issues whenever I try to program using imperative chunks in, say, F# or Scala.) Just my two cents.
The answer is just that I haven't gotten around to trying Racket. I've eyed it now and then but I've never done anything serious with it. It does seem to be the closest match for me barring Clojure.
That said, the JVM is a huge part of why I like Clojure. Because of the mountains of corporate code written in Java there is an insane amount of pretty high quality (if extremely object oriented) code available for it. I can find a library for basically any third party tool I'd want to use and if someone hasn't written a Clojure wrapper for it yet I can whip one up pretty quickly most of the time.
And sometimes I can do fine with no wrapper at all. Not only there's a lot of JVM code available, but interfacing with it is pretty quick, straightforward and smooth compared to wrapping C (or, god forbid, C++) from any Scheme I tried. I found that's very important. You can have lots of code theoretically available for wrapping, but there's more of an impedance mismatch between C and Scheme (think continuations/TCO, garbage collection, type conversion, and the fact that some tools in Racket/Scheme ecosystems will be blind to what happens in C land) so in practice it's a lot more work.
Besides the JVM part, this is my take on it: as a language, Racket defines a vast possibility space, which is a superset of that defined with Clojure. You could implement Clojure (barring the JVM) quite naturally in Racket, while the other way around would be impractical. Now, Clojure is a pretty sweet spot in that design space, and someone else has done the immense work to carve it out, define it, implement it, and foster a sizable community around it.
I played around with Erlang back when people rediscovered it the last go around in ~2006, and I didn’t think the syntax was crazy, so I’ve never gotten too excited to learn Elixir. Lisp Flavored Erlang (LFE) on the other hand looked cool.
But Racket... oh, Racket. Every time I get to write Racket, I feel like it’s the past, present, and future.
I do like some of the immutable collection abstractions in Clojure, and I like that there’s always a library in Java that’ll allow me to mostly still write Clojure. But Racket is definitely my language sweet spot.
Do you have any resources to start with Racket? I did it in first year but I haven't really seen (or searched too hard for!) materials that explain how I'd use it in production.
I don't know what exactly Clojure has but Racket/base has immutable lists, vectors, hash maps, and structs. (As well as mutable versions). Most default data structures are immutable.
Regarding Haskell, the type system is really the main feature of the language, not the paradigm. Haskell allows you to program in the type system (using some popular extensions) and simply derive all your code from your types. I highly recommend Type Driven Development with Idris as an intro the absolutely crazy things you can do with a powerful type system.
The issue with dynamically typed FP is that FP is essentially about functions as mathematical objects, and there's really nothing mathematical about dynamic typing. Primarily, static types act as a proof, and because we're talking functions in the mathematical sense, you can actually reason about your program in the normal way.
Haskell is for eggheads though. What I really like is Rust, which feels like you're using Haskell and C at the same time. It's both powerfully low level and powerfully high level, and extremely pragmatic.
All that said, it sounds like you're super passionate about clojure, and I hope no one rips it out of your hands. I know what it's like to play the language wars games, and I wish you and all our fellow brethren the best of luck.
Interesting. I asked mostly because I've hopped around a lot, trying to find that one language that just clicks with the way my brain works. Java, Javascript, Go, Scala, Ruby, Rust, Python...they all had things about them that kinda clashed with the way I intuited problems and attempted to solve them. I've instead tried to rescope my thinking into "I'm the problem, I should try to follow the language's idioms to find solutions."
Of the languages that I've enjoyed, I've spent the most time in Go. I've kind of just hitched my wagon to it, regardless of whether I like it or not.
> Wouldn't the same be said by most programmers with a high degree of proficiency with a language?
Perhaps for some, but not for me. Clojure is by far my favorite language, despite not being one that I'm most proficient in -- maybe not even my top 5 right now.
> What sets Clojure apart from Haskell or Scala or Elixir or Erlang?
For one thing, I've never written a (non-trivial) program in any of those other languages. :-)
Based on just what I've heard: Elixir and Erlang sound like good languages, and they're next on my list to learn, and I might well feel the same about them. For Scala, the one thing I've heard consistently is that it's incredibly complex, which is the opposite of one of the main reasons I like Clojure, so it's unlikely I would feel the same about it.
> Do you have a high degree of proficiency with something else?
Yes, I've earned money for writing assembly, C, C++, Java, C#, Python, Ruby, Tcl, Common Lisp, Objective-C, Swift, JavaScript, and probably a couple others I'm forgetting at the moment. Even after a couple years in those other languages, when I felt I was getting pretty good, I never felt like any of them were a great model of computation.
> Clojure is the language that I have always wanted to learn, but the benefits never seemed very apparent. I'm hoping your response will make them clear.
Writing a program in a language like C# or Swift or Python, to me, means taking 100 random pieces of kit (which look like the inside of Anders'/Chris's/Guido's head) and being creative enough to find a way to assemble them into something that works like I want today. None of them ever matches the problem space very well, so I have to pick how to compromise the design, and guess what axis of flexibility I'll want in the future. Next week when my requirements change, I learn that I often picked wrong, so now I have to redo part of it. The syntax is complex. Managing state is complex. Decomposing problems into reusable pieces is hard. Developing a new version of a program usually means rewriting methods I've already written (for new features, additional genericity, etc), and I personally find that frustrating. I want to finish things, once. I like it when languages let me extend built-in types with methods I think they ought to have had in the first place, but I'm also annoyed that I have to write these at all.
When I first tried Clojure, almost everything felt natural right away. The syntax is pretty simple -- just complex enough, beyond classic Lisp, to make common data structures (list/array/dict/set) easy to type. Learning Clojure mostly consisted of learning their new names for functions -- either functions I already knew, or which I guessed would probably exist (and always did). Remarkably, I usually find that the easiest way to solve any given problem in Clojure happens to result in functions which are already generic and composable and reusable. Once written, I very rarely have to touch a Clojure function again, either for correctness or modularity. (The obvious exception is the front-end, which is a thin simple layer that is easy to change.)
I can pretty much guess how I think something ought to work in Clojure, and it does. The work is not figuring out how to map my problem to the syntax of the language (and then having to maintain that state and those invariants), but simply writing some simple functions (map data to data) to transform the format I have to the format I need.
I was passively introduced to Clojure when I joined my current team at my current company a few years ago. After spending 5 years in a humongous, horribly-maintained Java code base, and a short period of time with a new-ish Scala code base that was littered with code written in almost all kinds of programming paradigms (procedural, object-oriented, and functional) and then being intimidated by the incidental complexity of the language itself prior to this transition, I was frustrated to realize the cruel fact that I had to learn another JVM language that feels even “weirder” and more “complicated” than Scala. At first, I had similar questions as you have now: “What makes this ‘ugly’ language so special that one of our smartest team leads preferred it to, say, Scala, Go, or Rust?” It was not until I watched one [1] of “Rich Hickey’s Greatest Hits” [2] did Clojure finally “click” with me. It’s all of those principles that were applied and the values that were upheld when Rich Hickey designed this elegant language. I cannot reiterate all of them here. Go watch those talks and give this language a serious try. You might end up falling in deep love with it just as I did. :-)
I've had a relatively high degree of proficiency with other languages by several accounts, including Java, Scala, and JavaScript. Yet I've observed empirically that I am usually much more productive in Clojure for the sort of programs I write (high-level software: web apps, components of information systems, data plumbing, etc.). This is well I ended up adopting Clojure professionally: after failing repeatedly to reproduce this productivity in more popular alternatives.
Regarding the benefits, for me it's the practical benefits of interactive development and the simplicity of everything in the Clojure ecosystem, which allow me to focus.
Of course, I would encourage everyone to be open to alternatives to Clojure!
I personally don’t have a great answer for you because I haven’t used the other languages much or at all. If you’re able to watch someone really effective at repl driven development, I think you’re able to see how that sets productivity in the language apart.
Bruce Hauman has given a few good talks about how you can use tools like Figwheel to bring a REPL-like development experience to web development.
You can watch him live-code the game 2048 in the screencast where he introduces DevCards[0]. Notice that the video came out 4 years ago!
One thing that really drew me to Clojure is that it seems to be a nexus of really good ideas that have trickled out into the larger community. If Clojure was where all the smart kids ate their lunch, maybe if I ate lunch with them too (so to speak), some of their smarts might rub off on me :)
I feel the exact same way (s)he does about node.js and I 100% would never want to write Clojure. So to your point, yes. Using the language I know well enough to make money with is awesome. Other languages don't entice me because I can already do everything I need to well with what I currently have.
> feel the exact same way (s)he does about node.js [...] can already do everything I need to well with what I currently have
This is a provincial take. That is, “do everything I need to” is strongly limited by what a person currently knows. If you don’t have at least moderate amounts of experience with alternative ways of thinking, it’s impossible to know what you are missing. There are many things which are needlessly complex, slow, brittle, unproductive, ... in any particular programming environment, and javascript is one of the more limiting choices IMO.
Ideally, students would be exposed to a broad range of approaches and tools in school to build a strong foundation, but in practice this often doesn’t happen, and the folks I know who reliably build the best systems are the ones who spend a decent fraction of their time learning new tools and ideas throughout their careers, many entirely self taught.
Probably because you don't need to do things that Node isn't well suited for. If you did, then other languages which did those things well would become useful to you.
You can make any language do anything if you have days/months/years of free time, but NodeJS isn't suitable for systems programming. Imagine trying to write a tcp load balancer or interface with Linux specific kernel APIs from Javascript. It's not a great choice for a CLI tool since there's inherent startup time for JITed VM based language. It doesn't scale well for CPU bound thread pool applications like image processing, etc.
So there are lots of places where it doesn't make any sense at all or it's just a very, very poor choice for a particular task.
Some more would be statistical (R, Matlab, SPSS), gaming outside the web (C, C++, Java), scientific computing (Python, Fortran, Julia), supercomputing simulations (Fortran, C++, C), embedded devices (C, C++, Rust), server farms (C++, Go, Java), financial (Java, Cobol, J/K), to name three PLs in each category that come to mind.
There is a big world of computing outside of apps and websites.
People use Clojure for all of those. From the rationale (https://clojure.org/about/rationale), Clojure "endeavors to be a general-purpose language suitable in those areas where Java is suitable".
I'm glad you're still earning income from it. It was my favorite of the JVM alt-languages, but it just seemed to have died around 2015 with all the others.
I say "died" but I know that people still write in Scala and Groovy, but how many new projects are you seeing in those languages?
At one point I set out to find work doing Clojure, but not much turned up in my locale. I did one professional project at a former company and only got the green light for using Clojure because it was basically a throw-away in a couple years when a new business process was coming in anyways.
Good luck to you, but it's not a niche I would want to be in. You have to mold yourself to the market, not the other way around (usually).
I think 2015 was the year that Node started getting popular on the backend at the expense of some of the JVM technologies, but Clojure fortunately runs well on that platform too.
F# and Clojure are notably ranked as the highest paid languages for the past 2-3 years in a row. Trust me - market is shifting towards FP and Clojure one of the best choices.
I can easily speculate that not for the same reasons. F# and Clojure are the most payed languages because today they are the most used FP languages in fintech sector.
Okay, here's my take on the implicit narrative here: Clojure is done. It will continue to improve, people will continue to use it and build cool things with it, but maintainers are burnt out, mostly because there aren't enough of them and partly because of the passive-aggressive relationship Cognitect has with the community.
There's a whole bunch of languages with small dedicated communities doing interesting stuff. D and Julia occur to me off the top of my head. It's not "failure" that Clojure doesn't really challenge Kotlin or Scala for mindshare. It's nonetheless disappointing for people like me who used to be really excited by Clojure's potential.
Could it have been different? I don't know. The powers that be could definitely have been more committed to growing the base, but it never seems to have interested them. Would it have made a difference? I honestly don't know.
This sentiment is in direct conflict with all of the data in the survey, which shows increasing use and importance of that use. I know of more than one company that has bet big on Clojure in the last year and is succeeding where they have failed with other stacks at business-changing levels. I know of companies with 100s of Clojure devs. Download stats continue to trend up. Etc.
The core team is rocking right now and feel like we are on the tail of lifting spec to the next level (and out of alpha), and interested in finding ways to work better with the community. Some many great ideas in the hopper for REBL and other things too. 2019 is going to be a great year for Clojure.
Download stats mean nothing. The truth about Clojure adoption can be found by typing "title:Clojure" into Indeed.com. Search for United Kingdom and you'll find 4 Clojure jobs, 3 of which are in London.
Using "title:" you meaninglessly narrowed your search. There are postings like "Software engineer" with body saying "Developing with JS, and Clojure" which won't appear in your results.
Number of "Clojure" results is 109, compared with 98 for "Haskell", for instance (in London, according to indeed.co.uk). So both are not scoring big, certainly, but those numbers are nevertheless better than 3-4 years ago.
In my experience (in Sweden), most of those results are "false positives". Companies/recruiters like to look for passionate programmers, so they put smaller languages like Clojure in their ads, even though the job itself has nothing to do with it.
True, except they don't include languages just for being smaller (we don't see Befunge, or Unlambda there), but those associated with smartness, and passion for learning. In context of the discussion (dead/alive state), I wouldn't count this as a bad thing. There's no arguing that finding FP job is hundreds (or thousands, depending on city/country) times harder than OOP job. It doesn't mean all functional langs are dead.
I agree with what you're saying, my post was mainly trying to point out that there might appear to be more Clojure jobs than there actually are. For the past couple of months, I've been looking for Clojure jobs (after my company in one fell swoop decided that Clojure was out, and we were no longer allowed to use it for new projects), and though there are quite a few matches when searching just for "Clojure" on job boards, most of those have nothing to do with Clojure. Out of 50-100 matches, maybe 2-4 of those were actual Clojure jobs. Granted, this is in Stockholm, but the situation was pretty much the same a couple of years ago, and things don't seem to have improved. I love Clojure, it's probably my favorite programming language, but I finally decided on a more normal C#/Java/JS position for my new job.
Well, I have already agreed FP jobs aren't plenty :-) Business executives mostly prefer to stick to beaten paths, and it's understandable. I just don't see a tragedy here. OCaml was born in 1996, if I'm not mistaken, so it's a decade older than Clojure. Despite never reaching the industry mainstream, it never stopped being developed, it is used in real projects, so I guess we can agree it's very much alive. Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java. So while I don't believe it will conquer the world anytime soon, I also believe it's not going to disappear anytime soon.
>Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java.
OCaml can embed or be embedded in native applications, but that's not the point.
I think that the main problem with Clojure is the lack of types.
Just look at how much Scala is more popular than Clojure, although it's also a strange functional language derived from OCaml/SML.
There is a common opinion that types are a necessity, even ruby, racket and python are adding them. Clojure people are just trying to substitute types with a runtime evaluated contracts/Hoare triplets, which is not an adequate substitution.
What had kept happening was that services written by my team (mostly doing Clojure for backend development) were taken over by other teams that either weren't interested in learning Clojure, or weren't allowed by management to do Clojure development (for whatever reason), so each time this happened our original service would be rewritten in Java or Node.
...of course, for the other team to be able to do this, they still needed to learn some Clojure in order to understand our code, but even in the cases where they actually liked doing Clojure, they were still forced to do the rewrite. The company was/is expanding very rapidly, so part of me can understand the decision to narrow it down to fewer "allowed" languages, to allow services/responsibilities/teams to move around more freely.
But it was one of the main reasons I decided to leave the company. I had joined after years hoping for Clojure to be my main professional programming language (for a substantial part of my career, at least), and I left a somewhat more bitter developer, but at the same time feeling a bit more free and relaxed - there are sooo many opportunities to pick from, now what I'm a bit more open when it comes to the tech!
I'll offer a different take: Clojure is settled. It found its niche: a small/medium group of experienced professionals who like its practicality and power. There's a comment somewhere else in this section that Clojure devs are more experienced on average than JVM devs. I'd like to add another stat from the State of JS survey[0] that went out a while back. Developers who used ClojureScript had the highest salaries and most years of experience when compared to other compile-to-js languages.
This narrative makes intuitive sense to me. Clojure is not the most beginner friendly language. It goes harder on functional programming concepts than the popular scripting languages, which is a bit of a learning curve. The cultural tendency to prefer smaller scoped libraries to broader frameworks means puts more cognitive load on the developer, who has to decide which libraries to use and how to wire them up. But this is a positive attribute for a more experienced developer, who might have strong opinions on how an application should be structured.
> Clojure is settled. It found its niche: a small/medium group of experienced professionals who like its practicality and power.
Agreed. I'll add though that the problems with Clojure are soft ones. Here's my summation:
* it's business- and Java-friendly. Enterprise-focused.
* it's quite beautiful, though steeped in Java-isms
* its license is GPL-incompatible
* it's not a community-focused language and project; it's Cognitect's [edit: Rich's] project which they're graciously sharing with us.
That last one (IMO, the last two items) is a problem. For example:
* docstrings. Real improvements from the community?
* Lein? The clear winner, and yet for the longest time there was no mention of it in the getting-started guide on clojure.org, and then Boot was created. And then clj. NIH?
* It took ages until they began accepting PR's for their docs.
* I don't know the status of improving error messages. They've been complained about for years.
Clojure is Cognitect's [edit: Rich's] industrial-strength enterprise-ready Java-replacement and they sell consulting services for that. That's what Clojure is for and it's very good at that. It's also a seductively beautiful language, but if you're expecting a community-driven project with grassroots adoption and support, you're going to be disappointed.
Just a clarification, Clojure copyrights etc are owned by Rich Hickey, not Cognitect. Cognitect pays for all of the core development team salary, infrastructure, etc.
docstrings - we apply many docstring fixes in every release.
NIH - are we literally never supposed to try to make anything new? Doesn't this non-argument apply to literally the creation of every language, library, and tool? This is silly. clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps).
We have been accepting PRs for docs on the site for 3 years. Who cares how long it took before we started doing that if we're doing it now? Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?
Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better? This is a good thing. I suppose we can also ignore the hundreds of tickets, patches, and contributors to the language, many of whom have nothing to do with Cognitect or their consulting, as that's more convenient for this line of reasoning.
Do you think Clojure would be in a better place today if it did not have this support from a company willing to champion it? How often has that been a successful strategy for languages?
> Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?
My apologies; I don't mean to insult. Thanks for the reply. My point is that it says something about what the core team thinks is important. Glad to hear that the team has been accepting doc PR's for years now.
> Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better?
I think we're arguing at cross-purposes. Certainly Clojure is a productive environment. But I'm interested in community-focused projects. These projects often have less corporate adoption than projects like Clojure. I was disappointed with Clojure, but not because it lacked a company championing it (it has one), not because it lacked corporate adoption (it doesn't), and not because there's anything in particular wrong with the language (I think it's an excellent language) -- by those metrics Clojure is certainly successful.
I'm amazed when people complain that they can't get their boss on board with introducing Clojure into their enterprise Java project. That appears to me to be exactly the market Clojure is targeting and succeeding in, when employed there.
From inside the core team, I feel entirely community-focused. I spent a good chunk of last year working on improving many aspects of error messages, the top community complaint in surveys. Currently I'm spending time working on spec and trying to guide external (community!) work on clj for Windows, also two things highly mentioned in the survey. I spent all day today answering dozens of questions in HN, reddit, slack, mailing lists, jira issues, github issues, etc. Not even sure how it's possible to be more focused on the community than I am.
Clojure on the JVM with Clojure libraries is one thing. Clojure with Java interop is quite another. Though a fine Lisp in itself, Clojure's identity is somewhat schizophrenic, hosted as it is on a platform designed for mutable OOP. This is the main reason most Java shops would never touch Clojure.
I personally believe that it is this sort of attitude that is driving some people away from Clojure. You could have easily structured your comment to be constructive instead of being defensive. The issue is not so much that people don't like how Clojure is managed, it is more so the lack of transparency and the (rather unprofessional) way that Cognitect (Rich) handles criticism and input from the community.
I get it. Clojure is Rich's gift to the world and he will do with it as he see's fit. That's all well and good but make that clear so that people thinking about checking out Clojure know it up front.
I don't get how you go from my comment to that. I literally talk to people all day long, every day, about what we should be doing in Clojure. The idea that this is "Rich's gift" and we're not taking input from others is just wrong.
http://insideclojure.org now has weekly journals detailing everything we're doing in Clojure dev if you're interested.
"clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps)."
I think the build tool is the part of the tool chain where you most want a single project to rally behind. You want everyone building artifacts and expressing dependencies the same way.
Clojure is not the most beginner friendly language.
I really disagree here. My first job out of college was at a Clojure shop and it has been the easiest language I've ever learned. There is a small hurdle of switching to lisp syntax when all you've ever used is C style languages, but that's about it. I also find frameworks more effort to learn than pulling in a small library that does the one thing I need.
I can really only speak from my personal experience here. I learned Clojure on my own time in college, and it took some time for me to understand how to deal with things like immutability, laziness, and pure functions. After I did finally 'get' it, I was unable to convince any of my classmates that the initial effort was worth it. I love the language and its opinions, but JavaScript (another language I learned on my own time) was probably 10x easier.
"I learned Clojure on my own time in college, and it took some time for me to understand how to deal with things like immutability, laziness, and pure functions."
I suspect much of that time was spent "unlearning" habits from procedural languages.
I know Carnegie Mellon now teaches functional programming as the introductory course, and only introduces advanced topics like "mutability" later. I think that sequence makes it easier for beginners to reason about what their program is going to do and experience less frustration.
One thing that makes Clojure hard for beginners is the tooling.
For example, consider how a beginner can write Ruby and Python in notepad.exe while a lisp would be insufferable (and a common, awful first experience for that reason). Also, some of its best features, like cider/nrepl and Paredit, are hidden behind yet more tooling and keyboard shortcuts.
Is there one single beginner that starts their programming journey with notepad.exe? I've never seen a single one, and I see hundreds of them each year.
Notepad++? Textmate? Look at the first paragraph of the first chapter of Chris Pine’s Learn to Program.
Now that you've gotten everything setup, let's write a program! Open up your favorite text editor and type in the following:
puts 1+2
Save your program (yes, that's a program!) as calc.rb (the .rb is what we usually put at the end of programs written in Ruby). Now run your program by typing ruby calc.rb into your command line. It should have put a 3 on your screen. See, programming isn't so hard, now is it?
Why not just start at the REPL or with a Notebook? Having an interactive environment seems like it would be easier to learn the language. Then they can move to a code editor when they're ready for writing more complex programs.
It's this sort of thing that probably drives the likes of Alan Kay crazy when even learning a language isn't interactive by default.
I agree, but there is also something conceptually useful in learning early that a program is code saved in a text container that is then either compiled or interpreted.
There’s mine? I used Notepad to create my first Windows .bat file (in fact, it was rather a juvenile piece of malware that opened notepad.exe thousands of times), which was the first programming I ever did. I later went on to use Notepad to modify files for a desktop game and write my first PHP and Ruby scripts. Now I write software professionally (including, but not limited to, Clojure) using a Mac :)
I don't see how that's implicit in the article at all.
Also, I don't see why we need to keep pitting languages against one another like this. Sure, there is a market, but can't we be happy that there is a diverse offering pushing language design forward? Not every language needs to become Java in terms of adoption.
In my last job I had two realms of development. The first was strictly based on what the company had been doing for years, what we expect new hires to know and what we touted as our language of choice. Embedded world that was C.
The second realm was languages that I picked purely because they filled a niche better than anything else. Often these were side projects, or tooling, or things that I could sell based on how quickly and efficiently I could get up and running with X language that would save us money even if we eventually had to replace it if no one learned it.
I used F# for big data processing because I am an FP guy and they wanted .Net and I could do data manipulation like nobody's business. I used tcl/tk because I needed a super quick and dirty UI for tooling that I could quickly update to add new features. I used Racket when meta programming would hugely benefit me.
The problem is that for a lot of our jobs we are stuck with realm 1, the things we can't change. This is the area where we end up pitting languages against each other because they end up used way more than realm 2. You have to push really hard and hope someone listens but more often than not you just keep on doing what you're doing.
I worked on a huge JVM based project and even though no one in the company knew Java there was just no selling upper management on using Clojure. FP would have reduced complexity, meta programming and dynamic code generation would have made it much more robust without a lot of effort, but it was just too foreign (or at least not advertised as being used in places well enough), too new, and when you Googled it the "major" issues developers had scared everyone.
There are literally 10-100 times more clojure jobs in every market I’ve searched than Julia or D jobs. The ecosystem continues to evolve in new and exciting ways, and third party developer tooling and integrations keep expanding. HN has been bullish on D for at least 10 years going and yet all the _new_ systems programming roles in my city are C++ and a bit of Rust.
I’ve been a software engineer and a backend engineer but I’ve bever been a “clojure engineer”. Why needlessly require the language in the title? Any reference to it anywhere in the body is unambiguously referring to the same programming language.
Anyway, using LinkedIn, roughly 70 results in Boston, 30 in Denver, 130 in San Francisco. 867 across the US. I worked for three years with clojure and just chose between two new job offers after a short search, also in clojure. I’m seeing the language get use in microservices in larger, more established orgs that may already have a jvm docker image that their devops supports.
Being a systems programming language with a GC, following the footsteps of Algol68 RS, Mesa/Cedar, Oberon, Oberon-2, Component Pascal, Active Oberon, Sing#, M#,...
Coupled with powerful meta-programming capabilities, while having quite fast compilation times.
They just suffer from being a tiny community, so everything kind of improves slowly.
While on the other extreme, Java and .NET keep improving their tooling and features for AOT compilation and low level programming, with OS platforms to go along.
It is not easy to find that sweet spot that makes a language take off.
Ruby was unknown for almost a decade until Rails came along, for example.
The trend of programming languages is to move toward static typing. Not as an afterthought, with gradual typing or retrofitted years later into an unwilling compiler, but languages designed from day one with static typing, parametric polymorphism, and type inference.
Clojure's life time was limited from day one because it's simply going against the trend.
Clojure is a Lisp. When the evidence and pragmatism of static type systems become scientifically proven facts I'm sure someone will figure out a way to extend the language without turning it into a disaster. Right now Clojure makes sense and it is way more productive to use it than any statically typed language.
This 100x! I don't understand how people can work on a complex codebase without a strong static type system. I've tried it once, and still remember the lack of confidence after every non-trivial refactoring.
I've worked on multiple large Java codebases, and on semi-large Clojure code bases. The Java ones compiled great but were full of bugs obscured by 100s of useless classes with bespoke interfaces. I found the Clojure code bases to be far more tractable because the language leads to better opportunities for abstraction and more concise code with way less incidental complexity. I think spec can add another layer of description where it's useful (and is not required where it's not).
That's anecdotal, and probably more a consequence of the seniority of the engineers who wrote these two code bases than the nature of the type systems.
My point about static type systems is broader and actually backed by science and mathematics. And also, just observing the trend and seeing where the wind blows.
You'll never get it because there isn't any. Static vs dynamic typing is largely a matter of preference despite all the hooting from the recent static typing fad. I truly wish this "apparent truism" would go away, since it commonly turns to people flaming dynamic languages as somehow inherently lesser than those with big fancy type checkers.
Indeed. I’ve googled for this research, and there isn’t much of it - just something that “everybody knows”.
The best, recent thing I found was a study done about 5 years ago or so (I think) by a fellow at UC Davis, and the data were pretty weak. Functional programming, and the requisite memory management, had at least as big an effect as static typing.
At this point some Haskell snob steps in and say “sound typing”... :-)
I guess that's why all those statically typed programs don't have any bugs and don't need any tests.
Being "sound" just means you can prove things are consistent with the assumptions you can encode in it. If there are things you can't encode in the types, or if your assumptions are wrong (misapprehension being one of the main problems in software), or if your requirements change, soundness is not going to save you.
Static types and proofs are valuable. Programs like compilers have fixed inputs and outputs and are excellent places to lean on things you can prove. But most of the programs I've worked on are not like compilers. They run for years, the requirements change, they have to deal with dirty data, talk to other messy systems, etc. And I'm not saying that dynamic types are perfect either.
My point is simply that static types are not a magical end goal of programming. They are a tool with tradeoffs.
> I guess that's why all those statically typed programs don't have any bugs and don't need any tests.
This is both a straw man and a fallacy. Nicely done.
Also something I never claimed.
You are basically saying that since you can't prove a program can be 100% demonstrated to be correct, there's no point in trying to approach this goal, therefore dynamically typed languages are good enough.
With your reasoning, we wouldn't be using safety belts because they can't guarantee you'll survive a car crash 100%.
Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types, which is why we see dynamic languages converging toward static typing and never the other way around.
In ten years from now, we'll look at dynamically typed languages as "It looked cool at the time, but we know better now". A bit like we look at FORTRAN and COBOL today.
> Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types
That has not been my experience and I don't think there is much objective proof of this. Most of the (admittedly not great) studies I've seen show dynamic languages as comparing favorably or better in bug counts for example.
Some of the things we're working on in the next version of spec are is head-on the notion of how to define expressive contracts for functions and allow those to meaningfully evolve in compatible ways over time as program requirements change.
I look at FORTRAN as a great language for its domain, so maybe you're right. :)
In a nutshell, if you can mathematically prove a certain degree of soundness of your code, you have not done anything to show your code does what it is supposed to do.
Basically, you could be doing wasted work to satisfy your compiler, and have made zero progress in solving your problem, because that's not what the type system does.
Dynamical languages focuses on solving problems of human beings. The human beings' requirements are often inherently arbitrary, logically unsound, or even self-contradictory. Shoehorning a type system in there often serves to make solving human's problem harder. Consequently, in practice, most popular programming languages are dynamic. The current craze with types is just a fad, in my opinion.
> Dynamical languages focuses on solving problems of human beings
> Shoehorning a type system in there often serves to make solving human's problem harder.
For the first pass author maybe. Subsequent readings and modifications of the code by other authors are much, much harder without "annotated" code (be that types or schema like spec)
Having worked on many codebases of all sizes, hand written by an ever changing population of developers (contractors, interns, consulting companies, etc.) I don't look at such annotation as the holy grail of developer-to-developer communication (in this respect, I find them quite less powerful than tests), nor as the philosophical stone of coping with changing requirements.
This is a similar straw man to someone claiming the trend of cars is clearly going electric and you saying "I doubt it, look at all these gas propelled cars we have today".
Python and Javascript are going to be around for a while, sure, but 1) they are also moving toward static type safety and 2) fewer and fewer projects will be started in these languages because statically typed alternatives are a better choice across the board.
"an intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument."
The parent poster stated that clojures days were numbered because in his opinion statically typed languages were becoming increasingly popular and Clojure didn't follow this trend.
I specifically mentioned JavaScript and python because people have been extolling the virtues of static typing literally before either shipped, while both rose to prominence, and became wildly popular. I'm arguing that neither posters personal preference nor even a correctly assessed trend in computer language design is by itself a useful tool to predict the future success of a given language.
This especially rings false when the same prediction is made several decades in a row.
I wont even address your analogy because analogies are like buttholes. Everyone has one and yours stink.
Given the huge uptake on Typescript, I don't think using JS as an example makes sense.
Static typing helps. It doesn't have to be Java-esque. F# & friends have really nice static type systems where you don't need to declare types for most things - they're automatically inferred.
Seems like javascript is destined to be here for the long haul despite the presence of typescript. In fact static type proponents have been predicting the death of dynamic type languages since this gulf became apparent. Thus far reports of one camps deaths have been greatly exaggerated by the other.
No one is arguing that dynamically typed languages are all going to die out (though CoffeeScript and Perl certainly aren't doing well). Languages almost never die. People are still writing COBOL.
But the relative share of programmers writing code in statically typed languages appears to be increasing. When the web got big, there was a very rapid growth in dynamically typed scripting languages: Perl, Python, Ruby, etc. Then, when client side web development became a thing, JS got huge and then CoffeeScript.
In the past decade or so as developers have moved to writing larger more performance-intensive client-side applications (read: mobile with touch UIs running at 60 FPS), there is now a turn back towards static typing: TypeScript, Kotlin, Swift, etc.
Also, the sophistication of static type systems is increasing. Generics are now a given, control over variance is increasingly common, as is static control over null references.
This doesn't mean the graph will go towards static types forever, but it certainly appears to be right now.
CD's are not going to become popular again to listen to music because "pendulums swing".
When a trend is clearly going toward increased comfort or clear progress, there is only one direction that the trend is going.
I argue that statically typed languages are headed in that direction and that in ten, twenty years from now, dynamically typed languages will be looked at as "something that seemed like a good idea at the time".
"Increased comfort" and "clear progress" are subjective measures about which people may disagree (to whit, I disagree).
I argue that in ten or twenty years from now, we will have great tools in dynamic languages to express constraints when needed, without requiring proofs.
Tempting to interpret this as the last major issue in Clojure use (error messages) being resolved with the introduction of spec. Consensus on concerns seem to be dissolving away from runtime issues to softer community management issues ("documentation", which is very context specific, and "startup time" which is important but precisely not an issue while running Clojure).
I do suspect that the survey is under-weighting how much beginners must struggle to navigate setting up CLASSPATH. If you don't come to Clojure from Java then the toolchain is a bit intimidating with whatever a Maven is, followed by a process of trying to follow what both Java and Clojure tools are doing. This is one area Clojure compares very poorly with, eg, C (similarly awful setup process, but usually all the burden is shouldered by the distribution provider) or Python (use pip).
It is interesting coming at Clojure from a Debian background at how resistant Leiningen has been to being integrated into the Debian apt archive. I think the package was removed in 2014 and only came back in 2018; so still isn't in the most recent stable. Given that Leiningen is itself probably the first choice of tool to manage dependencies, this raises questions about the technical underbelly of the tools used to build Clojure programs.
> I do suspect that the survey is under-weighting how much beginners must struggle to navigate setting up CLASSPATH. If you don't come to Clojure from Java then the toolchain is a bit intimidating with whatever a Maven is, followed by a process of trying to follow what both Java and Clojure tools are doing. This is one area Clojure compares very poorly with, eg, C (similarly awful setup process, but usually all the burden is shouldered by the distribution provider) or Python (use pip).
The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues. In the 3 years I used Clojure professionally, there were only small handful of times I had to deal with the classpath directly, and that was only for pretty exotic packaging issues.
> It is interesting coming at Clojure from a Debian background at how resistant Leiningen has been to being integrated into the Debian apt archive. I think the package was removed in 2014 and only came back in 2018; so still isn't in the most recent stable. Given that Leiningen is itself probably the first choice of tool to manage dependencies, this raises questions about the technical underbelly of the tools used to build Clojure programs.
What questions does it raise? Debian doesn't deal gracefully with any external dependency management systems, as far as I know.
> The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues.
Most of them. I struggled a lot with the specific case of "I have jogl installed through apt and I want to use it in a Clojure lein setup".
> In the 3 years I used Clojure professionally
That is why I think the issue is underappreciated. Java provides a very comprehensive set of concepts to deal with making Java code run everywhere, and that sort of thing is just baggage when trying to learn a language as an amateur on one system. I expect it becomes a feature when something needs to be done professionally and platform is no longer a given.
> What questions does it raise?
* In a language that requires a lot of probably-new mental models to understand, how much extra burden is created if mistakes are made configuring dependency management?
* Can a novice successfully identify what is going wrong if they muck up their dependencies in a 3rd party tool?
* Will a novice identify that they should be using a 3rd party tool to manage their dependencies, rather than relying on other mechanisms that might be familiar to them?
* Is the hosted nature of Clojure creating interesting new failure modes for novices in the build system as issues might now straddle two languages?
These aren't questions that a professional would encounter, I expect being across complicated build systems is sort of how things are. But the leap from pure Clojure, having fun in the repl, to pure Clojure + a library is a very steep learning curve. The quality of the project setup has to go up a long way. At the moment, based purely on that learning curve, it must be one of the early barriers that causes beginners to drop the language. I'm surprised it doesn't get mentioned in the survey.
Watching Rich's talks, I always got the impression that dependencies in general are an outstanding to-be-thought-about problem.
> Debian doesn't deal gracefully with any external dependency management systems, as far as I know.
External dependency management systems fail to meet Debian user's expectations of quality and stability, tyvm :). Yeah, you're right.
I've struggled with jogl as well. Clojure being hosted is a definitely a double-edged sword; while it makes it possible to use something like jogl, actually doing so can require you know something (or a lot of things) about the underlying platform.
The questions you raise here are real issues. I've been able to scaffold things for newcomers to the language in the past, but I can easily imagine how they could go off the rails without some guidance. I believe that the new "deps.edn" mechanism is meant to be the official, paved path for dependency and platform interaction in the future. But until everybody is using it, there will be two ways of doing things and the confusions that goes with having a choice. Perhaps it's necessary to move the platform forward.
I think it is totally bizarre that the official getting started page just kind of throws a Maven invocation in, like it's no big deal. It's at the bottom of the page, but if you are going to mention additional software that needs to be installed, why not mention Leiningen instead?
git clone https://github.com/clojure/clojure.git
cd clojure
mvn -Plocal -Dmaven.test.skip=true package
This is not the "first step" way to get started, which is why it's at the bottom of the page. Leiningen is not any easier to install and use than what's already there at the top of the page as the recommended path.
Windows clj is a work in progress and the page will be updated when it's ready. So, it will.
The Maven example is a way to get a standalone local-only (spec libs included) jar. Some people do this (it seems weird to me, but people do).
Leiningen and Boot are not official tools and are more than you need to get started (excepting the Windows caveat, which is a small portion of the Clojure user base that will be plugged, hopefully soon).
Because most development happens on Linux and MacOS systems, and most services deployed run on Linux. Even languages that make the sdk installation easy, the rest of the ecosystem of packages and tooling often considers windows a second class citizen (thinking here of node.js and ruby at least). If you have limited resources it makes sense to target the biggest group of users first.
Let's say I'm a beginner. I've installed Clojure following the instructions on that page.
Now what?
Neither "Learn Clojure" nor "Programming in REPL" even mention how to run it. I'm assuming you need to just type `clojure` in the shell (I'm only assuming this because I have experience with other languages that allow this, neither Java no C/C++ have this)?
"Learn Clojure" has a bunch of examples before it even gets to REPL. I guess I can run them? Somewhere?
The there's the "Programming at the REPL" section and... Then what? How do I start a project? How do I create a program? How do I compile and build a project? Run it? Test it? Configure it? Where is all that?
Fully learning the language, the tools, and how to make a project are all different topics, and have their own interactions with whatever other tooling they are using. I think a lot of that is there but I'll take your point that they aren't guided well enough. Definitely worth taking a few more passes, thanks.
> probably the next logical step but maybe could be highlighted better
It's definitely not a "next logical step". A next logical step is "create, test, and deploy a clojure program". For some reason these important topics are given a total of maybe 5 paragraphs inside a section on CLI tools?
> I think a lot of that is there but I'll take your point that they aren't guided well enough
"A lot is there" is a total of two paragraphs on writing a program outside of REPL, a total of two paragraphs not even on testing but on how to include a test directory. And that's it.
As a beginner I wouldn't even know where to look for this (Google is often not enough).
Clojurescript is slightly better in this regard. At least after the quick start guide I have some understanding on what goes there.
The state of leiningen in windows itself seems to be shaky. I do feel moving away from leiningen will be better for clojure, and will provide a better "batteries included" experience for the user.
This was an interesting tidbit as well from another analysis [1]:
This year’s survey also included a question about how long people had been programming professionally. 1 in 10 Clojure users have over 20+ years of developing experience; 49% had over 10+ years of experience. In comparison, only 42% of JVM developers have that much programming experience.
Clojure having a higher than average percentage of experienced developers directly contributes to the quality of the language and the ecosystem around it.
Percentages don't create software, people do. Absolute numbers are definitely more important for ecosystems. I'd wager that for every 1 clojure dev with 20+ years experience, Java has 100.
I'd always consider language power to be an amplifier of experience...a 20+ year veteran that knows clojure like the back of his hand is going to be more productive than a java dev of similar experience. But the community size gap is huge. I deal with this as a scala programmer quite a bit. The ecosystem is pretty great for how small it is, but it's never going to be as good as java devs have it.
You can directly leverage everything from Java and Js ecosystems with Clojure. So, I'm not sure I follow the argument here. If a useful library comes out, I can still use it from Clojure while enjoying the benefits of a much better language.
You were the one to make the comparison to other JVM developers. Not sure why you would make the comparison if your whole point was that you can use both.
Of course that point is spurious at best. Clojure devs can use java libraries about as well as java devs can use C libraries: it's an unidiomatic nightmare with tons of unsafe sharp edges. And java devs can even use clojure libraries, but they don't and probably never will. Using java libs from scala is a hell of a lot easier than using them from java, but I still avoid them like the plague. If we're comparing the relative merits of ecosystems for different languages, it makes sense to compare the ecosystems developed natively in that language, not lumping in the thousands of other ecosystems that technically can interop with it.
My point is that the clojure ecosystem is weak in comparison to other more popular languages because experience in absolute quantities matter far more than percentages. The Arc ecosystem basically consists of a single 20+ year veteran, Paul Graham. That's 100% veteran composition. According to your line of argument, they surely must have the world's greatest programming language ecosystem. Does it?
At best, the clojure ecosystem can claim to be good enough for most uses. That's certainly a lot better than the vast majority of languages. I'd be overjoyed if SML, Pony, MiniZinc, or Mercury had the ecosystem that clojure enjoys. But compared to Javascript, Java, Python, C++, C, Javascript, Swift, Ruby, etc., it's not even close.
Clojure was designed to be a hosted language from the start, and it embraces the underlying ecosystem. There are plenty of Clojure libraries that use Java libraries internally and provide an idiomatic API. Having a mature ecosystem to lean on is just practical. For example, take a look at Apache MX Net bindings, HTTP Kit, clj-http, clj-pdf, and so on. All these libraries leverage the host ecosystem. There's absolutely no value in reinventing the wheel here. And the interop nightmare you're imagining simply doesn't exist in practice.
>My point is that the clojure ecosystem is weak in comparison to other more popular languages because experience in absolute quantities matter far more than percentages.
And yet in 8 years of working with Clojure I have yet to run into a situation where the ecosystem failed me.
>But compared to Javascript, Java, Python, C++, C, Javascript, Swift, Ruby, etc., it's not even close.
And Clojure leverages both Java and Javascript ecosystems directly. The whole ClojureScript ecosystem is based around React. When you write web apps you build them on top of React components, and other Js libraries. And this is how seamless interop is:
The ecosystem is not an interesting problem to solve. Interesting things are happening in the code you write. The business logic of your application is where the language matters. Even when interop is unsafe you're doing it at the edges of the application, and you treat it the same way as you would any side effect.
Maybe a positive feedback loop. Clojure made experienced developers feel right at home with something neither too esoteric but concise, fast enough, safe enough. Hickey had 20~ years in the field too, I guess he shared the same concerns.
The reason for the clojure user base having an experienced majority is that is overwhelming and tedious for an inexperienced programmer to use Clojure to accomplished things, the "you already should know how that works and how to do that, roll your own" mantra dominates, in contrast to JS/Python, where there are good learning resources for almost everything you want to accomplished (for things that have already been done).
There is just way more hand holding in these massive communities (JS/Python).
Another big reason is that if you want to write production level code in Clojure, you have to know Java and its APIs well, the same for Clojurescript and Javascript, making the barrier to entry much bigger.
So yes, IMO, right now Clojure is a language meant for experienced developers and my guess is that will remain so.
The good thing is, Clojure and Rich brought some good concepts to mainstream use. He did a good marketing job.
I'd like to highlight that knowledge of Java makes working with Clojure a lot easier. I think you can probably get pretty far by picking the right libraries and being careful, but eventually a mistake will be made and understanding Java makes it that much easier to track down the issue.
I can't go back and test my theory (I've been doing Java for what feels like a century) but I feel like it will be difficult for people without a Java background to get a production Clojure project off the ground.
Clojure was my first JVM language. It indeed was a nightmare. The java underpinnings affect everything you touch. Trying to use a library that didn't have a stable wrapper was terrible...you have to essentially learn two languages at the same time.
Clojure is not only simple and thoughtfully designed/composed from first principles it also is pragmatic (!) and reaches (JavaScript, JVM, CLR, …).
The power and joy derived from the above is incredible and (to many) even more important: it means Clojure is not sitting idly in its own ivory tower it plays very well with real world day to day situations.
Try to find languages that see eye to eye with Clojure here.
I’m super excited about the language and the welcoming community. Also super fascinating to see how so many community efforts are composing and compounding so well. I wish other languages / communities would look more closely and adopt some (more) of it.
A bit confused with some of the comments here but then again YMMV and just wanted to jot some of my thoughts down before I transition into some late-night recreational coding that I was looking forward to the whole day. < 3 Clojure
Based on some of the comments in the thread I see there is some veracity to the claim that interest in Clojure is leveling off or declining. However, it has been my experience that the community embraced Clojure around 2013-14 to the point of "irrational exuberance". The reality that the ecosystem is full of under-engaged projects and dead ends really set in for me after I went to Clojure / West in 2014 and saw several demos break on stage.
I want to use Clojure at work, but I'm just not productive in it yet as other languages and I haven't found the time to build momentum with it. That said, I still want to get there.
Every time something Clojure related appears in HN top - there are a bunch of comments criticizing the language and most of them are so unfounded.
You'd start reading and even before finishing a second sentence you'd realize - the person has no clue what they're talking about. Listen, Clojure is not a small language like Lua - you probably won't be able to form an educated opinion about it by trying to build something simple over a weekend.
People would say the hate JVM, when they actually mean "Java". In 3 years of using Clojure I almost never had to even read Java code.
They'd dismiss the language immediately because it is not statically typed. If you think maintainers of the language have no clue about type theory and completely unaware of all the research of recent years happening in Racket, Haskell, Julia, Agda and Idris - you are very wrong. Things you can do with clojure.spec are absolutely mind-blowing.
If you claim that it's hard to find a Clojure job - that's not true. It is not harder than finding a job in Scala, OCaml, Erlang, Haskell or F#. If you've forced yourself to "love" Javascript, Python, Java or Typescript simply because they can guarantee an employment - I'm truly sorry for you. Sometimes I think people must be either crazy or completely ignorant - who in the right mind would choose JSX over Hiccup and Json over EDN?
If you claim that it is hard to hire Clojure developers - that not true either, you simply need to be ready to pay more. People come to Clojure out of curiosity - not for dogma, not for points in résumé. Clojuristas are usually more experienced devs, tired of all the bullshit that inevitably gets accumulated overtime in almost every language. Clojure(script) is not a silver bullet either. But in most-cases it simply makes sense and it just works.
I don't hear as much about Clojure these days, and I don't know if it's because my reading habits have changed or if the community has become quieter. My impression was that other languages have captured the zeitgeist and that the enthusiasm for Clojure has abated. I could be wrong though.
That's my impression too, and I think it's happening for a combination of reasons. Clojure's no longer the new thing, so its faults don't have the benefit of being hidden behind a lack of experience with the language. Clojure's also a language that rewards long-term investment more than most. That's inherent in all of the mechanisms for abstraction and reuse it provides, but it's not necessarily the kind of thing that's immediately obvious. In the short-term you see the funky syntax and all these linguistic tools you don't quite get, but it takes a while to see how it all fits together into a more productive whole. And by the time you do, you or your team may have moved onto something else because the error messages suck or there's not quite the library you want.
I also think languages can suffer because their scope is so limited. There have been times I've thought that I'll switch languages and solve a bunch of problems, only to find out that most of my problems are still there. The requirements are still vague, the team still has its dysfunctions, and the surrounding systems are still unreliable, poorly specified, and run by teams that have no interest in helping because of some organizational dynamic set in place ten years prior.
None of this should be a surprise, but the real point is that even a putative perfect programming language can only address a relatively small fraction of the problems that arise in software work. That can make it even more difficult for minority languages like Clojure to produce a positive risk-adjusted return on the investment they require to adopt in a serious way..
I don't hear as much about anything these days. I feel like it started with Rails, we had a run of years where new languages, frameworks, databases, platforms were coming out every day.
The last couple years have been much more ... boring in that respect. Things have consolidated into whatever the big cloud vendors want to support, and even their pace of innovation seems to be slowing dramatically, not too unlike cellphone tech.
k8s is probably the buzziest thing, but even that, I have trouble getting very excited about something primarily oriented around ops.
My impression is that Clojure has reached maturity and most people that are using it are just quietly getting on with their lives and building useful things with it.
From my perspective, it has never been better than it is now and there are a few more things coming this year that are the cherry on the cake.
It's an interesting phenomena to look at from a language philosophy perspective. AFAIK, Rich Hickey has advocated for a very pragmatic approach to programming from coljure's inception, and I believe (perhaps excepting the introduction of Spec) the language has stuck to and reflected that philosophy. I believe Hickey has even gone so far as to say it's usually a waste of time to fiddle around with type declarations when you should be solving problems and transforming data (I'm paraphrasing, of course).
Contrarily, nearly every other popular modern programming language project (Haskell, Rust, Scala, Crystal, to name a few) hopes to provide nuanced, robust type systems and compile time guarantees--these projects focus less on pragmatics and problem solving and more on correctness and safety. Even elm, which is just a language for building frontends, boasts of its compile time guarantees and elimination of runtime issues using a type system. Clojure is the only recent language that I know of to go against the grain in this regard. That might factor into its decline in popularity--presumably all of these languages are going after type safety and correctness because they are perceived as features people desire these days and clojure never emphasized these properties (some of the things it emphasized instead, such as immutability, problem solving, and interoperability with an existing platform are still important features ,they just don't happen to be as prized right now as correctness/safety and perhaps noiseless/sparse syntax).
The introduction of spec can even be perceived as a sort of concession to this popular demand. Even the spec about page hints at the slight[1] incongruence between spec and the overall Clojure philosophy:
"However it has always been a guiding principle of Clojure, widely valued and practiced by the community, to simply represent information as data. Thus important properties of Clojure systems are represented and conveyed by the shape and other predicative properties of the data, not captured or checked anywhere since the runtime types are indistinguishable heterogeneous maps and vectors."
[1]: Slight because the purposes of spec are not those of a type system or compile checks. What spec does do, however, is introduce some of the bookkeeping sorts of procedures that, in my estimation, the design behind clojure intended to minimize as much as possible.
I feel very similar. But I still love Clojure. Sure, the hype has died down/moved elsewhere, but whenever I go back to Clojure it feels like going back to a beautiful place. There's currently nothing new or exiting and that's fine. Sometimes you pick your languages because you know what you can expect from them, because you know them so well.
It surely changed, I remember how every clojure conj was a source of enlightenement. Reducers, Transducers .. Many Hickey talks were iconic(sic). Now it's not as trendy.. even clojure 1.10 felt ~meh in a way. But taking a bit of distance I thought .. it's better than having people changing the language every 6monthes leading to js fatigue like symptoms. Slow is good. It seems that clojure users are happy with what it is now.
I've tinkered with Clojure and find it a really refreshing paradigm to work in for building web services. However, I'm not sure I'd ever use it for something serious - it's a hard sell to management, and it's difficult to get developers on board to try something radically different compared to the imperative/OO programming models. Regardless, having played with it has changed my perception of how code ought to be structured and written. Thanks to Cognitect and the Clojure team!
I'm in the middle of this transition and the biggest challenge is getting the OO way of thinking out of people's heads.
It's very challenging to stop thinking about mutating state in an object graph and adopt a functional programming model using immutable data-structures.
Be prepared to face quite a bit resistant on that (as well as static vs dynamic typing, and the expressiveness of types vs. something like spec or schema)
I'm not too concerned about selling to management (well, I'm the CTO, so 1/3 of management is on board ;) since there are many success stories around Clojure and the list of well-known companies using it in some fashion is pretty large. When pushed, I just mention NuBank (over 4 million customers) which runs their business on Clojure.
I would dearly love to use Clojure more professionally but the problem in every country I've worked has always been the talent pool; I struggle to hire because Clojure devs are comparatively much harder to find. Clojure is a wonderful language and I was firmly on the hype-train back in 2011 or so but I'm not convinced it has much of a future outside its current niche. I would be very happy to be proven wrong though!
I had a similar epiphany to you in that coming from a Python background, Clojure radically changed how I thought about and approached problems. Rich Hickey's work is fantastic and I'm very happy to have spent time in that particular corner of the tech world.
There's no need to hire Clojure programmers, just hire good programmers, and get them to work on Clojure. Our experience is that new people can start producing something useful in two weeks at most. There's not really a lot to learn to become useful. Most of beginner's hurdles are on environment setup, coding habits, etc, these are not problems at all if they join a team .
The reason why Clojure is easy to teach on the job is that Clojure code base is small and code are very localized.
It's impossible to be productive in a large Java code base within a month even if you joined as a seasoned Java developer. But it is routine for a programmer who has not even heard of Clojure before to become productive in a production Clojure code base in two weeks. We do this all the time with our interns.
I work in Big Data at a Fortune 10 company. We don't even do what you suggest. There is very little appetite for niche languages that are difficult to just hire for. For example, we have a ton of Scala code due to a misguided belief that Spark must use Scala because it was written in Scala. We can't even go to the market and find people who have used Scala before. It's all Java developers, and many (most?) are not very good developers. So then I say we need to train organically if we want to have good Scala (and Java) people in the organization. Oh man! You would think I took away their birthdays! Train people? Dear god, no!
It's all optics and bullshit. Scala is pretty easy to pick up, as is any programming language. The problem is you have to spend the time. Time for most people, me included, is extremely limited.
In some parallel universe, I'm sure Clojure is the #1 JVM language. It's great and Rich taught me so much about functional programming and many other things. But at the end of the day, Clojure here in this universe didn't take off and I'm not sacrificing my career to beat that drum anymore. I tried hard, I really did: 2013 & 2014 were the years that were make or break. The wave didn't crest. When the people maintaining the plugins to Eclipse faltered, it broke down hard. IDEA never had solid support, either. Then, when the support tooling faltered, it was really hard to make the case to management, especially when other asshole developers were arguing for their pet tools. Type safety, meh! I don't need it, never have... So I write Java Streams and it pisses me off every single fucking day.
There is nothing more to say than "if you can find a job doing Clojure you are extremely fortunate."
I hope we move on from Slack as a community hub. It's not about searchability -- it's totally unsuitable for public/open communities. If you've been in there recently you probably know what I mean -- it's vulnerable to griefing in a way that, to my understanding, Slack is not interested in fixing.
[edit: original parent said "no idea what you mean" - just noting b/c my response only makes sense to that, not b/c offended by it or anything]
spoofing identities (or, I guess, making sockpuppet ones) to @-everyone and post porn gifs & racial slurs from slackbot in #clojure
--
Yes, the Clojure community is awesome! I only mean that Slack has problems that allow malicious people to spoil the fun. I don't know if it's been addressed. I logged out the last time it happened.
I very much agree with you here. Slack is bad software in general but particularly bad for open source communities. Searchability is essentially gone, it requires a proprietary and extremely heavy piece of software to access, and it's very hidden from public view.
I know there's been a couple efforts to find a place to relocate to, but it's never really gone anywhere.
The repeated message from the authors is that clojure.core docstrings are not gonna improve.
If you think it's an easy problem to solve, please point out a single resource (library, website) which is 100% high-quality, comprehensive, up-to-date, IDE-integrated, and noncontroversial. Where is it? Why haven't we all adopted it?
The facts are: we have good-enough docs, nREPL, a massive corpus of beginner material (books, videos) and real-time support from enthusiasts on Slack.
If you ain't clojuring, it's because you don't want to!
I don't think that anyone believes that it's an easy problem to solve, but it IS a problem.
I've been Clojuring since 1.0, contributed 100s of examples to Clojure docs websites, and I still don't understand some of the .core docstrings even when I know exactly how to use the function.
It may not be easy to solve, but it does need to be solved.
Worth pointng out: if you know exactly how to use a function, how much of an actual problem is that the docstring is contrived?
I'd sure like nicer docstrings, but also I understand that the authors (core and community alike) have limited bandwidth.
So we may never see a "100% solution", which is perfectly fine.
(Thought exercise: say the docstrings get just a little nicer. Couldn't that create even more problems in some ways? Now everyone expects nice docstrings, and bikesheds about format, contents, etc)
The issue with understanding how to use a function and having difficulty with the docstring is:
I assume my knowledge is fallible, and that the docstring is the de facto source of information for that function.
If my knowledge clashes with what I understand the docstring to convey, then my understanding vanishes. I go from happily coding to "Uh, I don't know what I'm doing" in seconds.
It's not a super frequent issue, and I've reported it when it is, but I've heard many other people express similar sentiments. It's a slow process to improve this because everyone understands written language slightly differently.
I'd like to highlight an issue with the docstrings as they stand. It has been stated by Rich himself on Jira that he doesn't like or want usage examples in docstrings. However, it would seem that many other people would love to see exactly that; myself included.
He made this clear a few years ago - I don't know if he has changed his mind since?
This would probably help beginners more than anybody else.
docstrings are intended to be a concise statement of what the function does and we would like to stick with that.
Examples are also great. We would love to have documentation pages (or even doc functions in the repl) that combine multiple sources of information to help you out (docstrings, examples, see alsos, etc). That stuff does not have to be "in the docstring" for it to be available to you as a user.
For example, clojuredocs.org does exactly this, combining multiple sources of information into one combined page (ex: http://clojuredocs.org/clojure.core/zipmap). There used to be an api for clojuredocs.org and a repl lib you could use that would give you an additional function to get those examples at the repl too (I think that fell out of maintenance).
The summary is, we can both have docstrings that don't include examples AND provide examples by merging docstrings with other things for the user.
I think the Java standard library docs fall in this category. It's always been one of my favorite part of working with the language.
(I guess the library design is controversial, or rather, it is now... Collections are looking rather outdated just to cite the obvious. But as for the documentation, it's still killer.)
I believe the reason, besides the fact that docstrings can be consumed via a REPL, is that the docstrings get compiled into the final classes. So if we had huge JavaDoc style docstrings, it would negatively affect loading times.
It's a dynamic language, if you must have static typing over Clojure it's not for you. (You can of course do a lot of other things at compile time via macros)
In all my time in Clojure I've never seen a project use compile-time type checking. core.typed [1] exists but I've never used it. Most people use either no type checking or if needed they'll judiciously apply something like schema [2] or spec [3].
