clojure-survey-2018-highlights.md

State of Clojure Survey 2018 - Open comment question

This is a selection of the most articulated critique found in the open comments section Q25 at the bottom of the survey. Recurring themes are:

1. Elitism, ivory tower, "not smart enough to get it" attitude of frequent speaker or early adopters.
2. Poor basic documentation, error messages, beginner friendly resources.
3. Fear of contribution (with reasons like a. community-built tools open to attack and replacement by core team b. hostile contribution environment c. closed development process)

• The community has to grow to create more opportunities. Many organizations don't want to even consider using it because they fear not being able to find Clojure developers. Unless you have a mentor or are extremely motivated, Clojure scares away most imperative developers. My suggestions is to team up with a university and get a Clojure course on Coursera or a similar platform. This is the only way I got into Scala (Martin Odersky's Coursera) as a full time developer and a busy family life. I was lucky enough to have a Clojure mentor to get me started.

• Just a suggestion, Clojure should move to Graalvm, it would definitely improve clojure startup characteristics.

• I am doing Clojure for some time now and what does not bring me joy is the fact that the message to other communities (other languages) is clear: "we are better and smarter". Working with several other languages at the same time I know this message is false. Clojure community has great people, but the further it moves forward the more alienated and "special" it becomes. So the choice is slowly moving towards living on the tiny island of "special, clever" people or just enjoy the world with no less clever people in a big free world. I think we can do better without thinking that we are.

• Thank you, Cognitects, for your great work and things you keep on creating and maintain! I believe that one fine day there will be as good jobs marketplace for Clojure, as it is for Ruby(Rails) now. When I will be able to choose between companies using Clojure based on their culture, work life balance and products they building, not only the fact, that they are using Clojure, may be only to be able to hire best people on the market, but doing not the best things engineering wize, comparing to some Ruby On Rails shops.

• I didn't want to tick the unpleasant communities cause it is not, it is one of the friendliest programming communities I have ever been into. However lately, maybe due to the fact that the community doesn't expand fast enough, I started noticing a kind of "elitism" especially from people that are frequent speakers or started working early with the language (doesn't apply to all of course). IMHO we need new influence in the community sooner than later. The ClojureBridge work is very important and should be supported more.

• Being in the Clojure community since around 1.2, I loved the language then, and I like the direction, it's been taking since. The community is great, very friendly and even its most controversial figures are usually polite, intelligent people. Heck, even the local troll from the mailing list is occasionally helpful, stays on point in his threads and sticks with the conversation, even after blowing stuff up. Another thing, that I want to add, is that practicing Clojure for that long has recently started paying huge dividends for me: When I started going to the Vienna Meetups, around 3 years ago, people were asking around for positions to do Clojure professionally. Around the beginning of last year, 2017, the market flipped and now companies are seeking to hire Clojure talent. This means more people being interested in Clojure, which is great for me, because I like to converse about it ;-) Reading through this, I'm realizing, that I probably shouldn't have taken the survey right after coming home from a party, drunk, but anyway, it's there now and I'm not backspacing it. As usual, thanks a ton for the great work! Clojure really does enable me to translate my programming passion into awesome programs, in a very effective and efficient way. cheers

• Clojure remains my absolute favourite programming language. However I do have a few pain-points to complain about ??. In my experience "Clojure developers", for some reason, often think they are much cleverer than they actually are, and create horrendously overcomplicated, unmaintainable messes of solutions instead of clean, simple ones. Hard to say why this happens, but I think that, while I love that it's a simple, pragmatic, productive language that lets you churn out simple, maintainable solutions quickly, for a lot of "Clojure developers" churning out simple maintainable solutions just isn't interesting enough. Perhaps because they're too "clever" to do something so simple, and perhaps because the problems they're working on are too boring in and of themselves so they have to keep themselves entertained somehow. I've seen the core team describe Clojure as a language "optimised for experts" a number of times but in my experience it is an excellent language for beginners and people moving from other languages, as long as you have more experienced people on hand to help with the bits that really aren't beginner friendly - like stacktraces. We've had much more luck with people we've hired that are new to Clojure than we have ever had with enthusiasts...

• What I miss most is a book which teaches how to approach problems with Clojure. I mean primarily not "best practices" or "design patterns" or language independent algorithms. Nor a kind of language reference or few lines long mini examples, but complex, advanced examples with detailed explanations about the pros and cons of certain solutions applied / not applied.

• I'm worried about the recent direction of travel for Clojure. I felt the decision to add spec to 1.9 as alpha was bizarre. The spec ecosystem is rapidly being populated, alpha or not, and the complexity this introduced to getting Clojure started concerns me a lot. We could have simply waiting longer for 1.9. These latest core libraries are being released as alpha with a big caveat that their APIs are subject to breaking changes in future. The upgrade story for Clojure has always been so great, but it now seems like we'll see major breaking migrations that split the ecosystems as soon as they get started. Now building the classpath is a major concern to start Clojure, hence tools.deps.alpha (also subject to change). Then git deps, creating new edge cases around how all existing libraries which use Maven now can't depend on deps (directly or transitively) that require resolution via git. This is complicating Clojure adoption when for years it has been blissfully simple. I haven't heard complaints about Clojars and lein from the Clojure community. A big problem for new starters, an issue that has been singled out time and time again over the years, is poor error messages that lead to difficult debugging of code structure. That Clojure 1.9 has actually made these error messages harder to understand is a disaster. Of course, I'm nobody when it comes to understanding these decisions about the direction of the language, and it's probably just my own ignorance on show. I hope I'm wrong and that I'll understand the grand plan eventually. I came to Clojure because of so many great decisions by the core team about what the Clojure experience is and should be, and I fear that new starters won't be having such a great experience now and in future. I don't think the Clojure community can afford to let the adoption experience suffer. I don't see these concerns being raised in the usual places, so either I'm crazy, or people feel they can't raise these things for fear of censure by the core Clojure team. I think I see signs that criticism like this is effectively banned in the places where Clojure is discussed. Am I a suppressive person? Sorry for raising these things anonymously.

• Clojure is already pretty nice, and everyone is of the opinion that the core library is pretty stable. I think the best thing to do would be to concentrate on the accessibility of the platform for beginners (there are always new beginners, especially if apps in a company gain traction). This can be done with a focus on - making documentation more approachable (prettier! https://cljdoc.martinklepsch.org/yada/yada/1.2.10/ is a nice mock) - error messages to be more sensical (I suppose some of the work with spec is supposed to go in this direction, but it seems like a temporary step back in that regard) - an acknowledgement that there are two types of people checking the docstrings of library functions (one that knows what they're doing but looking for the exact intricacies of the function, the other that has no idea what they're doing at all and find the docs escape them)

• No de-facto web framework - Pedestal is in dire need of documentation - Schema is deprecated and Spec isn't ready - all tooling for Schema will have to be ported for Spec - New CLI tools in Clojure 9 competing with Leiningen/Boot All of these complaints have something in common - looks like the Clojure core team is actively hostile towards the larger community. All community-built tools/libraries are open to attack and replacement by the core team and there's always fear of a major destabilizing revolution everyday.

• I was excited about spec initially; however, I find the error messages so large, noisy and unhelpful that I don't want to use it. To put it another way: when there's a spec failure, my heart sinks; knowing that the next few minutes are probably going to be frustrating and painful.

• Clojure has a long way to go to become more "beginner friendly". Excuses such as "sharp tools" are condescending and elitist; they deter new users.

• Not to put too much stock in the oversimplified Gartner hype curve model, it does seem like Clojure is passing through what they call the trough of disillusionment. Maybe we can say the same about the collection of functional programming languages that were created in the 00s, and consider the phenomenon a reaction to the overinflated hype around multicore computing. Regardless of the reason, one aspect of the clojure language that was striking was how friendly and upbeat the community behaved and how it was possible to feel the excitement around the direction of the language and the open source projects surrounding it. The good ideas continue to come through (specs and tools.deps are brilliant examples) but the enthusiasm appears to be fading a bit. Maybe clojure could take a page out of the Rust community organization, that appears to be succeeding in encouraging an efervescent atmosphere with initiatives such as setting goals for the year [https://blog.rust-lang.org/2017/02/06/roadmap.html] and identifying and addressing needs beyond the core language and stdlib [https://blog.rust-lang.org/2017/05/05/libz-blitz.html].

• Really, the core documentation is not written for beginners or even intermediates, the learning curve is steep and the frustration with getting sensible error messages is high.

• The Clojure Core really needs to be standardized with community-based decisions, like the JCP does for Java. Rich has done a great job, but it's time to let it go so it can grow. See, for example: http://ashtonkemerling.com/blog/2016/06/11/my-increasing-frustration-with-clojure/ Also, see Clojure's apparent decline in popularity under "Functional Languages" here http://www.benfrederickson.com/ranking-programming-languages-by-github-users/?imm_mid=0fae87&cmp=em-prog-na-na-newsltr_20180127 . This may not be accurate, but I expected to see significantly more growth over the last decade. Look now where Kotlin is, and see that Clojure is missing a big opportunity.

• Cognitect, Rich in particular, need to climb a few rungs down the ivory tower and engage with the community as if it were in fact made up of human beings trying to do their jobs. The clj and clojure.spec debacles are two big examples of this: take something from the community (hey, it's open source...), rebrand it as your own brilliant creation, ship it, then let it languish while the community "just figures it out on their own."

• I have multiple colleagues, all great developers, all former Clojure developers. I love Clojure, but whenever Clojure comes up they never fail to mention how alienating the "smarter than you" attitude sometimes present in the community can be. I want to tell them they're wrong but there is a certain streak in our community of "if you can't appreciate it, you're just too stupid to get it" that is definitely present at times. Frankly, this is a recipe for disaster and slow death. I don't want that. (In case you're wondering, they're all moving to Elixir in a serious way. I'm not sure what this says yet. Maybe nothing, but it's worthy looking into.) I think we need to ask ourselves the hard questions about how we can be more welcoming. I think we need to reflect seriously on why our beginner story is so poor in comparison to other communities. Being arguably the most interesting programming language community and the most welcoming aren't mutually exclusive. The knowledge wealth in this community is tremendous, and its just a shame that we seem to be so poor at sharing it in a way that makes people want to join rather than push back. I have heard it said that Clojure is a language for experts. This may be true, but again, how are we to capture the imaginations of new generations if no one wants to deal with us?

• Clojure has been a gateway for me to understand a lot of new concepts and abstractions; functional programming, the value of manipulating transparent, understandable data structures with a well-understood set of functions, the power of macros in a homoiconic language (though I am primarily a consumer of others' macros), logic programming (though I never managed to use core.logic properly), generative testing, specs as an alternative to static typing (though I am still on the fence about its usefulness - I definitely don't feel it lives up to its hype), and probably more. It's also deepened my perspectives on the usefulness and restrictions of dynamic and static typing, and the various ways that either can be implemented. While definitely not a silver bullet, Clojure is currently my favourite language, but ironically, its catalytic effect to widen my perspectives has lessened my belief in Clojure as the strongest langauge in all (or most) regards - it has both well-known, obvious faults as well as more subtly questionable design flaws, and I suspect that once I've had the chance to learn even more well-designed languages, Clojure will move from its position from "My favourite langauge" to "One of my favourite tools".

• Cognitect has continued to be good technical stewards of Clojure, but poor stewards of the relationship between the core team and the rest of the community. Many (most?) senior Clojure programmers want nothing to do with contributing to Clojure or any projects owned by Core (like the site) because the process is designed to frustrate and prevent meaningful contributions. I look at languages like Rust, Elm, and Elixir as examples of the power of a good community and leadership from the top. Currently there is an absence of community leadership, and a lack of empathy for non-expert Clojure programmers. Alex does an admirable job, but is ultimately not empowered to respond to people's complaints by improving or changing the language or documentation, only to deflect them. 2017 has shown a further retrenchment of Clojure/Core where development is done ever more in secret, popping out with a fully formed surprise at the end, and afterwards showing little interest in making meaningful changes from community feedback.

• It's been a longstanding complaint that development of the language is a "closed" process, making it difficult for the community to participate in its evolution and provide feedback as to what they want out of it. This situation has not changed, and at this point it's perhaps futile to expect it to, but it must be raised again as the foremost issue. The long-term viability of any project depends on the continued engagement and expansion of its community; Clojure makes this harder than necessary. 2. Right now, there's unclear direction of the language's future. Compared to past years, Rich has not been as active in 2017 in going to conferences (outside of Clojure/conf) and promoting Clojure or providing a roadmap for its evolution. Does Spec continue to be the primary developmental focus? Is it something else instead? This somewhat ties into #1; there's an opacity around where things are going. 3. What is the status of ClojureScript? It needs more than David Nolen as a core developer. David is incredibly intelligent and diligent, but he's only one man. The lack of a formal spec for Clojure also results in many small differences b/t CLJ/CLJS that frequently catch the user by surprise. The general CLJS situation could be improved.

• We should take example of how Rust community/documenation is run: BIG focus on newcomers, features MUST be perfectly documented before being shipped. This serve advanced users as well. No offense, but Rich Hickey should understand what good documentation is, or delegate completely to people who do so that he can focus and making a even greater language (his strong point). 2. Lisp curse: too many people develop their own solution for themselves. This is related to #1, since the community is not very well organized (even if welcoming and smart).