Created
December 2, 2013 05:37
-
-
Save puredanger/7745559 to your computer and use it in GitHub Desktop.
Categorized responses from the Clojure/ClojureScript survey
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Respondent ID | Text | Category | Sub | |
|---|---|---|---|---|
| 61448432 | Local Adoption. The community is very much concentrated in the US, with the exception of London. In the rest of Europe, not so much. In Belgium we hardly get 6 to 10 people joining a meetup. You see it in conferences too: Clojure presence is much higher at US conferences. | adoption | ||
| 61454845 | Needs enterprise uptake and buy-in. | adoption | ||
| 61455773 | It's a fairly insular community. | adoption | ||
| 61463826 | In Japan... * Very little developer use with clojure. * it is too hard to find clojure developer. * it is too hard to find clojure documents for **non-lisp** programmer (I was non-lisp programmer before use clojure, but I am joyful **lisp style** programming with Clojure). | adoption | ||
| 61506717 | Not mature enough language yet to be mainstream in corporate datacenters who think .NET is all you need. | adoption | ||
| 61508083 | I think that if it were easier to write Java libraries with Clojure it would become a more compelling option for Java/"enterprise" shops. | adoption | ||
| 61516831 | The idiocy of people not understanding it | adoption | ||
| 61629580 | Convincing co-workers to adopt (because it's a lisp, non-technical co-workers take a long time to learn, yada-yada) | adoption | ||
| 62117049 | Wider adoption | adoption | ||
| 61413662 | The lack of a killer app that we enthusiasts can point to and say: "Hey, that super awesome thingy was written in Clojure". The closest thing is Datomic, but it's not open source. We have Pedestal, but that's only awesome if you're already in. Prismatic is cool, but it's not a thing and it's not open source. Loads of cool libraries, but again, only cool if you're already in. | adoption | success stories | |
| 62033834 | The use of the EPL, which goes some way to undoing the Java interop benefits. | adoption | license | |
| 61354727 | A lack of developers who can inherit codebases. The hiring + legacy maintenance thing. | adoption | Staffing | |
| 61358737 | Not really a problem, but because it's still fairly niche there's too much risk in developing in Clojure at my workplace in terms of future hires. | adoption | Staffing | |
| 61369380 | This will (hopefully) be solved in time: IMO, Its still a big leap for a long time developer or development shop to jump to Clojure. This is both good and bad. Good: Too mainstream and you get potentially bloated. Bad If you are looking to use it at work you still may have to sell the language. I don't have this problem at my employment, but I know others who do. | adoption | staffing | |
| 61384295 | low commercial usage and lack of job positions, start up time | adoption | staffing | |
| 61394145 | Still a large lack of developers | adoption | staffing | |
| 61403742 | Long term viability and lack of developer resources. A chicken-and-egg problem, but I think it's getting better. Only time will tell. | adoption | staffing | |
| 61824672 | Hiring Clojure developers is still difficult. Naturally, it's still a small language and gaining in popularity. Still I worry about it fading into obscurity in favour of say Scala without a more rapid adoption in the wider technological community. | adoption | staffing | |
| 62031990 | Mindshare. Hard to convince managers to adopt with limited hiring pool; hard to grow hiring pool with limited adoption, recur. | adoption | staffing | |
| 61420196 | Lack of language-level experimentation by non-clojure.core folk. | community | too small | |
| 61384910 | I love the language. In my 15 years as a professional developer and general technologist - across security, networking, perl, c, c++, php, ruby, java, linux .... and more communities - I have never encountered a less friendly unwelcoming community. Ruby comes close. But again I do love the language so much that I will continue, for now. | community | ||
| 61391109 | Arrogance and smack talk by central clojure figures towards developers who haven't seen the light. | community | ||
| 61397600 | Its leadership and the suck up community that wants to worship its own uniqueness and greatness instead of push for faster and more open development. | community | ||
| 61399298 | Some people are rather arrogant. Steep learning curve for tools and deployment. Unsure if it will get widespread acceptance or stay in a niche. | community | ||
| 61426782 | Dismissive/Combative public attitudes towards differing opinions by prominent members of the community. "Quit sh*tting on our lawn" was a comment indicative of this attitude. Others are not as caustic, but similar in nature. | community | ||
| 61642114 | Small community | community | ||
| 61815597 | small community | community | ||
| 61444269 | Coming from Haxe, the biggest wish I have for Clojure - ignoring cost - is for cross platform development to be embraced as part of the core compiler itself. ClojureScript forked off as something separate to Clojure it seems to me primarily over file size concerns, in order to use the Closure compiler, which rules out arbitrary eval. This makes perfect sense for the trade offs when deploying to the web - nobody wants 1mb js files. But this doesn't scale; if ClojureC were added in order to generate executables, there would be three compilers and at least two languages. Ideally we'd instead have one language and one compiler with a backend API, with macros to do conditional compilation and warnings (eg, you can use eval in js, but the compiler warns you that it can't use the Closure compiler). I realize this is unlikely to happen, as growing up as a Java language Clojure is already firmly anchored in the trade offs of server side development, but it would be incredible to be able to write high performance games and other native apps in Clojure. The biggest reason not to do this is that over the very long term (10+ years), Javascript (with threads) will become more and more acceptable in areas that previously required native code. | compiler | cross compilation | |
| 61458753 | Need more cross-host libraries that only provide the abstraction of other libraries, but can switch to different implementations depending on the host/library. | compiler | cross compilation | |
| 61881746 | Lack of an easy way to write cross-platform (JVM/CLR/JS) clojure | compiler | cross compilation | |
| 61426179 | no self-hosting compiler | compiler | self-hosting | |
| 61444139 | Compiler in Java | compiler | self-hosting | |
| 62131101 | Not being self hosted (Clojure in Clojure, ClojureScript in ClojureScript) | compiler | self-hosting | |
| 61415606 | weakness - production vs development profiles blindsopt - android | deployment | profiles | |
| 61732601 | Deployment, particularly of web-apps (and datomic deployment, although that's technically not clojure) | deployment | ||
| 62144283 | Limitations in the JVM. It's extremely hard to ship an app that relies on external platform-specific libraries without just as much effort paid to a custom build toolchain for the project. OpenGL would be the best example--ztellman has noted that this is why he abandoned his "penumbra" library. | deployment | ||
| 61362076 | I disagree with the creator's stance on distributed programming, and would like to see a semi-official integration of Actor Models like the Erlang systems use. Clojure's concurrency primitives are nice, but unisufficient and often weird to use (like the "agents" that are currently there). | Dist sys | actors | |
| 61372586 | Distributed computing is still "roll your own" using mostly interop. Not terrible, but not great. Reducers and core.async have been amazing at tackling scaling up. I'd love to see Clojure leap-frog other JVM languages and be the first to really make use of Graal+Sumantra+HSA [1] [1] https://wiki.openjdk.java.net/display/Sumatra/AMD+Sumatra+prototype%3A+APU+meets+Stream+API | dist sys | ||
| 61378749 | Distributed Computing - much of core libs are around performance on a single VM. I would love to see these extended to included distributed node vms. I am aware there are some libraries that do this but I would like to see more focus from the core team. | dist sys | ||
| 61514454 | better clojure to clojure runtime communication, for instance erlang like distributed systems. The way to keep growing systems robust and simple is to build them of simple parts. It can be done in Clojure but "we are not there yet" | dist sys | ||
| 61380951 | no examples of people using advanced/unique features successfully in real/large projects: refs, agents, datomic. | docs | advanced | |
| 61363632 | Documentation. The official page really could use some love. | docs | clojure.org | |
| 61369244 | Official web site design and content. clojure-docs.org does much better job educating about clojure | docs | clojure.org | |
| 61382521 | To outsiders, the walk-up experience to Clojure is still weird. The various resources (clojuredocs.org, clojure.org, cheat sheets, etc.), are not consistently under one umbrella, and often bit-rotted (clojure docs still has v 1.3??). This is in stark contrast to, for example, node.js. Look what's on the front page of http://nodejs.org/: 3 prominent buttons. There is a blog button -- leading to a blog that is kept extremely current. There is a core API documentation button -- leading to a part of the _same website_ which is coherent, consistent, and great. There is a downloads button which leads to a clear and communicative table of options -- contrast to what the Clojure download page leads you to: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-alpha1/ Someone in the Clojure core needs to understand: THIS STUFF IS IMPORTANT. Languages and their communities don't just thrive as a result of technical excellence. For the next 5 million Clojure programmers, who haven't ever heard of Clojure yet, Clojure's web presence __IS__ Clojure. If it's not Rich's core competency or main concern, he needs to empower someone else to take the situation in hand. | docs | clojure.org | |
| 61383100 | The reference documentation is awful. The author really does not want people to understand. It is just one giant puzzle. Case in point - zippers - "See Huet". Or just try figuring out how you are *supposed* to do I/O. Another case - the lovely language page about datatypes, then you look at the API and it is 100% Alpha. Is it real or is it vapor? No way to tell. There are tons of tutorials, I do not want a tutorial, I want a *manual*, a K&R, a Stroustrup. | docs | clojure.org | |
| 61430635 | clojure.org is uninviting and doesn't help people get started - and the Confluence wiki is a HORRIBLE user experience. | docs | clojure.org | |
| 61523562 | Honestly? Bad publicity. http://clojure.org doesn't do it justice. Some more if I'm allowed: * start-up time * unsuitable for mobile * native compilation for small services (where golang excels) * Less important: lack of a "standard" story for distributed jobs (thinking: Pulsar, Storm) | docs | clojure.org | |
| 61671649 | The main website (clojure.org) is rough. To put it succinctly, it doesn't invite new users (cf. http://clojure.org/lazy). The content is good but incomplete. The presentation is lacking. To verying degress, this problem is pervasive throughout the site. | docs | clojure.org | |
| 61406186 | For me the lack of good public documentation is the single biggest barrier to introducing new people to Clojure. The docstrings attached to functions from the standard library are not sufficient as API docs, and community efforts to beef up the docs have all dies on the vine. This stands somewhat in contrast to Clojure's public projection of itself as a highly idiomatic language with clear opinions. I hope leadership can come from Rich Hickey and other prominent Clojurians that this is an important aspect of the community. | docs | docstrings | |
| 61506037 | Documentation assume you know too much about how the language internally works and what the functions goal is, almost across the board. Documentation has too few examples of usage, ESPECIALLY at edge cases. If they do cover a case its the main use case. JVM. dealing with Classpath, different versions, deployment, all of that. I need to know what a WAR file is if I want to deploy this. JVM has a lot of garbage that clojure just doesn't seem to shake. | docs | examples | |
| 61509355 | Lack of Documentation and examples. | docs | examples | |
| 61356690 | Far too much deprecated information shows up in google results. | Docs | freshness | |
| 61357851 | Out-dated documentation. | Docs | freshness | |
| 61372404 | Documentation. There is a lot of out-of-date information online, and the documentation quality for the core language and libraries is not nearly as good as, say, Python. Clojure has an amazingly powerful story to tell but it is also a somewhat strange story to many mainstream developers. The documentation could tell that story better, and still be simple. The several excellent books out there go a very long way but they are not enough. I do think the strictness of the CA / ticket execution process does hurt this aspect a bit. Documentation is a way for relative newcomers to contribute, but the process is slow, and not particularly simple or easy IMO. | docs | freshness | |
| 61450927 | The biggest problem is the documentation. The core functions need examples and a better discovery mechanism for finding functions for meeting a particular task. Additionally there is no documentation that I can find on the underlying types (PersistentMap etc). This would be ok if you didn't need to know about them but these need to be known when adapting a new protocol to existing types. Since the normal Clojure user needs to know about them a set of public interfaces/classes should be defined a documented. Googling often turns up documentation that is out of date. I'm not sure what Clojure core can do about this but it's a problem that plagues beginners. It's especially unfortunate that ClojureDocs isn't being maintained anymore since the examples were so good. | docs | freshness | |
| 61356567 | Newbie friendliness. We need to figure out a way to make people aware that Clojure, actually, is just as easy and fun to learn as Ruby, for example. Also Ruby has killer documentation, not just in the core libraries, but also for third party ecosystems. Rails sucks, but has an incredible wealth of information out there about it. | Docs | getting started | |
| 61357113 | Getting started documentation | Docs | getting started | |
| 61357298 | Hard to say as I'm deep in it, and take a lot for granted, and work around a lot of issues that come up without thinking. I think this is a good question for folks who have not yet come to the language, and are looking at it from the outside. BUT, if I had to guess, I would say there is some inaccessibility issues for beginners--it strikes me that it is very much an environment/language for folks with a particular experience and mindset: developers who have been around the block, seen the problems with other options, and are both pragmatic but idealistic. This means we are willing to be patient and see "the cup is half full" when a beginner may look at one more stacktrace and say "what the hell?" Maybe; this is supposition though. Another thing I see often--a weakness that I think is also a strength (funny how those go hand-in-hand): the diversity and flexibility that the language allows, combined with the non-prescriptive nature of the community, means that we get a lot of variations on a theme with a lack of strong standardization in general practices. Luckily in web development we have Ring, but otherwise you are on your own--take templating or database wrappers, for example. It's great we have these options, but challenging to figure out good approaches at times, and there is still a good bit of re-inventing the wheel, it seems. But, on the flip side, the language is powerful enough that many solutions to problems are very, very easy to build yourself. And when good, simple,"Clojure-esque" solutions come up (again, see Ring, and Compojure, for examples) the community tends to rally around them. So I think the jury is out on this one. | Docs | getting started | |
| 61358702 | The documentation for learners | Docs | getting started | |
| 61376554 | I think getting started with Clojure is the biggest problem. First, it's can be difficult to setup your development environment. Second, prefix notation is jarring for most OO and procedural developers. | docs | getting started | |
| 61458923 | Too hard to get started. Uninformative error messages. | docs | getting started | |
| 61460466 | It's barrier to entry is still to high (mainly due to Maven / JVM ). For example, anyone can download NodeJS and then clone git repos and begin working with the code in minutes. The setup for a Clojure environment takes longer and there is also per project setup which is much harder if all dependencies are not in THE maven repo. More approachable languages (Python, Ruby, Javascript) tend to attract a larger audience. | docs | getting started | |
| 61607064 | Getting up and running (especially a simple CLI app.) | docs | getting started | |
| 61814914 | It is still very difficult to find a good, simple "Quick-start" guide to point interested parties at. The JVM loading mechanism also means Clojure is subject to dependency hell - which could be solved with a loading system like the one in Node.js | docs | getting started | |
| 61420696 | Lack of instructional information about integration with existing systems. | docs | integration | |
| 61503536 | a language reference specification is a need. | docs | language spec | |
| 61927350 | No standard and only one implementation being (largely) led by one commercial entity. | docs | language spec | |
| 61711115 | few examples of clojure scaling to large projects | docs | large projects | |
| 61823990 | A broad community understanding of best practice on how to structure state in systems. A typical example is database connections and other 'global' state resources. Stuart Sierra and Prismatic has done some great work in this field, but I feel more examples and discussions are needed in the community to break new ground. | docs | large projects | |
| 61414455 | Documentation. Even for core libraries like core.logic, it can be incredibly difficult to get substantial examples of use, pattern/anti-patterns, etc. | docs | libs | |
| 61357711 | I think that lack of centralized documentation and listing of mature libraries is the biggest roadblock to adoption. Currently, it can still be difficult for beginners to find what libraries are well maintained and whether they will continue to be maintained. Currently, majority of libraries are maintained by individuals. They can get tired of maintaining the code base, or get it to the point where it solves their particular problem and have no interest of extending the functionality after that point. Another issue is the lack of documentation on how to structure real world applications. | Docs | Organization | |
| 61362001 | One coherent place to find acurate info on the language and it direction in the futur. Should be one place with : - reference documentation for every clojure major versions, with examples and remarques - language discovery, first step, download page - commercial support - libraries resources - supported tools Actual web presence of clojure is to scattered around the web. It does not help industrial, commercial acceptance and adoption. | Docs | organization | |
| 61365231 | Lack of official high quality up to date documentation and library discoverability | docs | organization | |
| 61378798 | The clojure documentation is spread thinly between too many sites. Please consolidate to clojure.org: http://clojure.org/documentation http://dev.clojure.org/display/doc/Home http://clojure.github.io/clojure/ http://clojuredocs.org/ | docs | organization | |
| 61421137 | The official website isn't very good (last I checked it doesn't even mention lein), docs are scattered. I wish there was a more clear path from noob to competent online (I'm always recommending clojure programming). | docs | organization | |
| 61470567 | Documentation. Personally, I don't have a problem with it. But the API docs are at once site, extended API docs (with examples) at another (clojuredocs.org) and out of date, and a third (with tutorials and area guides (clojure-doc.org) incomplete, and at yet another site. On the other hand, these days,"Just Google It" works pretty well for me. Regardless, it's not access to the information that's so important here, it's the appearance of a clean, unified whole that matters. "These people have this under control," is what you want to be thinking, even if you find a function's doc string is confusing, or an area-guide incomplete. | docs | organization | |
| 61586712 | cohesive learning experience. i found 2 books, used 4clojure.com, read irc, did blog after blog etc and used clojure docs which is woefully incomplete and not up to date. There should be an obvious official api page like java has, which is always up to date. another great thing would be a setup that shows you the latest info on getting clojure on x (where x is swing/web/android/ios etc). I'm imagining a site kind of how scalatra breaks out different view technologies, but more in depth. make it a hub, the clojure community needs one. | docs | organization | |
| 61363202 | There's a lack of good examples about how to structure large clojure projects. Consider Stuart Sierra's "clojure in the large". We've had people hacking at this idea all year long and still nobody has a coherent public example of how to structure a large Clojure app... | Docs | project structure | |
| 61369632 | absence of high scale (large codebase) design instructions. Big apps I saw just a mess. | docs | project structure | |
| 61393081 | It's hard to settle on an approach to any problem, because development in a dynamic functional style is still so new to most developers. "Just do it" seems to be the only way forward sometimes. Ruby has Rails, which makes so many choices for you that you're almost just left "filling in the blanks", which is quite easy to do compared to striking out to build a new Clojure system. | docs | project structure | |
| 61393284 | Lack of good, informative examples of how to structure and manage large Clojure projects. | docs | project structure | |
| 61399032 | - no good ide - difficult to refactor - no two pass compilation (helper functions on top, real meat on bottom -- opposite of expectation) - no best practice for code layout - no clear multi-project support | docs | project structure | |
| 61456153 | Re-learn how to architecture things coming from years of OOP. Something it's hard to find information on how to structure a big app. | docs | project structure | |
| 61458010 | How do you compose a production system out of hundreds of pure functions? | docs | project structure | |
| 61507452 | Organizing mid-sized code bases. (>2000 lines) | docs | project structure | |
| 61561288 | Developing particularly large applications is difficult in both that there are few established idioms for doing so using names paces and functions. Furthermore lack of a static type system makes large applications difficult. This is why typed Clojure is such an exciting project. Optional typing is exactly what I want. | docs | project structure | |
| 61614852 | Lack of support of "programming in the large" | docs | project structure | |
| 61362348 | Standardization of code structure / style. | Docs | style | |
| 61376300 | The community, though strong, doesn't have the resources to help people write good clojure code. I've written clojure on an off, at work and in my spare time, for quite a while now. I was at the first two conj-es, but haven't been since. Despite all the books and the code, I'm still not sure what good clojure really is. Maybe there isn't one true way, but I often feel as though I'm not using clojure the *right* way. | docs | style | |
| 61563140 | Lack of a comprehensive style guide. This is a small point, but let's face it, Clojure is great. | docs | style | |
| 61359180 | Tutorials Documentation Guidelines for "idiomaticness" | Docs | tutorials | |
| 61367727 | Since it's young, it is very hard to find guides for anything if you're young. For example how to make a game in Clojure (and a full game not just Pong or something). | docs | tutorials | |
| 61371246 | Documentation, tutorials, especially for simple things like the REPL. | docs | tutorials | |
| 61415734 | Education and lack of educational resources. That said, its improving. | docs | tutorials | |
| 61503167 | Need more tutorials like the pedestal client tutorial to support self learning | docs | tutorials | |
| 61524610 | Compared to other languages, development and debugging tools are weaker. Tutorials are also weaker in terms of number and how often they are updated (many Clojure tutorials are 1.1, 1.2). | docs | tutorials | |
| 61864029 | Would love to have a series of blog articles or something that talks about the best way to do things in Clojure. Since I don't have a Clojure expert to learn from I find myself sometimes unsure of how to proceed with certain task in the language. | docs | tutorials | |
| 61422258 | Some blind spots towards web development as compared to infrastructure/big data | docs | web apps | |
| 61505961 | Documentation primarily. In the domain I'm most concerned about, web development, more guidance around using ClojureScript idiomatically. | docs | web apps | |
| 61619386 | As a web developer myself, I'd expect an important rise in the number of web devs coming from the Rails and NodeJS communities and having a hard time trying to get their heads around web development on Clojure. There are some efforts around a curated selection (a la framework) of libraries such as luminusweb.net, but I'm missing others. | docs | web apps | |
| 61903035 | Despite the excellent publications on the language itself, getting started with web development is still very difficult. The dissolution of Noir and lack of large, open-source projects to emulate make getting started difficult. | docs | web apps | |
| 61353953 | The documentation, for sure. It's _terrible._ | Docs | ||
| 61358108 | Lack of good documentation. "Good enough" is not enough. Lack of maturity in most libraries. The main/core/professional libraries are OK, but outside that, there's a wasteland of abandoned libs and poor documentation. | Docs | ||
| 61359525 | Documentation | Docs | ||
| 61387029 | documentation | docs | ||
| 61403267 | Documentation | docs | ||
| 61410639 | Clojure is technically excellent. Where it suffers is in documentation, as well as in the stability of some fundamental libraries. It's a bit off-putting to see something as fundamental as the JDBC library in an alpha state, with recent breaking API changes. The libraries may be excellent, but it makes the stack a difficult sell to my more conservatively minded colleagues. | docs | ||
| 61425372 | Docs | docs | ||
| 61432003 | Inconsistent documentation, it's frustrating to troubleshoot for hours just to realize the documentation is incorrect. | docs | ||
| 61444251 | - Bad Documentation Style , If There's Any! - Bad Performance - Time to find proper Command/Library - Weak/Complex web tools | docs | ||
| 61447962 | Documentation, while good, is not as good as JDK Javadoc, for example. | docs | ||
| 61453412 | Again, that protocols aren't built into the language at the bottom. Also pattern-matching style function dispatch a la Haskell would be super sweet. Also the official documentation sucks hardcore, and the unofficial documentation sources (clojuredocs et al) also kinda suck. I think Cognitect or whoever should put together something like clojuredocs which stays up-to-date, but with better function discovery features. also why no dissoc-in? | docs | ||
| 61457725 | Approachable, pragmatic documentation. | docs | ||
| 61457842 | Dearth of resources (tutorials, documentation) for learning libraries. Generally core stuff is well documented, but newer things and many libs, even commonly used ones, are poorly documented. | docs | ||
| 61475468 | Clojure seems effective for the very smart but I find a lack of documentation and recommended practices from Cognitect frustrating. E.g. clojuredocs.org is still a go-to site for me even though it only targets Clojure 1.3.0. Why doesn't Cognitect provide something like this? The hangup of not accepting any documentation or tutorials that don't have the protective halo of the Contributor Agreement is frustrating. There should be an active effort to identify the best docs, tutorials and practices out there (i.e. "useful shit") and collect them under one roof. Source: I can currently only program in Clojure very part-time. | docs | ||
| 61533956 | DOCUMENTATION. PLEASE? CAN WE GET OUR ACT TOGETHER HERE? | docs | ||
| 61538621 | More promotion. Better documentation and tutorials. Clojure presenters a and advocates can have more real-life exples | docs | ||
| 61557043 | Lack of high-quality documentation, as well as unsuitability for scripting tasks (Which is a shame, given Leiningen is awesome). | docs | ||
| 61663059 | Official documentation. Un-official documentation is fantastic. | docs | ||
| 61695087 | A lack of continuity in the development story and established best practices. Though RoR is overbearing at least the whole of the community can rally behind it. | docs | ||
| 61895028 | There should be a better online (with robust offline "mode") documentation-system maintained by the core Clojure team. Something like devdocs.io, with the ability to point at external docs of the user's choosing, e.g. docs available at some github http endpoint (with prefs stored in localstorage): http://devdocs.io/ Such a project, very close to the core "Clojure effort" would help to bolster the community and define a standard for documenting Clojure projects. | docs | ||
| 62037074 | Documentation for more obscure methods and macros is nearly impossible to find or too terse to understand. If a library is not well documented with plenty of simple examples it might as well not exist. | docs | ||
| 62043453 | Documentation, without a doubt. | docs | ||
| 62067601 | Poor documentation. It seems that while this is often pointed out by the community, efforts stall (we're forever waiting for someone to finish porting clojuredocs.orc, etc) and the language stewards don't care about it. | docs | ||
| 62134361 | "Where are the docs?" "Read the (tests|docstrings)." "Did you just tell me to go fuck myself?" "I believe I did, Bob." | docs | ||
| 61359557 | Error messages: common mistakes often lead to very strange compiler exceptions. The community stance of 'unspecified input has undefined behavior and should not be tested' should not apply in this case. We need to define those cases and stop showing developers stack traces from inside the compiler. | Errors | messages | |
| 61361914 | good debugger, funky error messages, slow startup | Errors | messages | |
| 61364869 | unhelpful errors or stacktraces depending of the environment (nRepl with Emacs or not etc.), dynamic typing for big projects, records and maps are similar but not identical (can lead to surprising problems) | errors | messages | |
| 61365302 | errors are often only found at runtime; error messages are sometimes hard to interprete (anonymous functions, etc.) | errors | messages | |
| 61368478 | Esoteric error messages and inline core function documentation. | errors | messages | |
| 61375964 | Error messages that are difficult to understand | errors | messages | |
| 61377415 | arcane error messages | errors | messages | |
| 61429358 | I think the bar has been set by Ruby and Python. Clojure needs to give error messages as least as good as they do and also needs to do better at loading files and projects that may have an error in a file -- the file should still partially load while simultaneously alerting the user to the issue. | errors | messages | |
| 61355663 | Obviously, cleary, evidently, manifestly, patently, without a shadow of doubt the unhelpful and maddening stack traces CANNOT PROCESS RULE __q_40123 | Errors | Stacktraces | |
| 61356354 | stacktrace is not so good | Errors | Stacktraces | |
| 61357156 | unreadable stack traces | Errors | stacktraces | |
| 61357779 | Debugging: in JVM version, stacktraces. Poor EMACS and NREPL integration, and some bad choices made in it. Debugging REPL entered code (no line numbers, so it's lost). Etc. I've been a Lisper since 1978 (sic); I pity those new to it trying to use Clojure on the JVM. | Errors | stacktraces | |
| 61360227 | stacktraces are horrendous | Errors | stacktraces | |
| 61363051 | Exceptions are leaking Java (something like slingshot should be the default). | Errors | stacktraces | |
| 61368731 | Stack traces | errors | stacktraces | |
| 61369322 | Stacktraces are still hard to read | errors | Stacktraces | |
| 61375494 | Stack traces are hard to read, mixed in with Java-isms as they are. And I'd like a proper debugger. I've never been a huge user of debuggers in other languages, but when you need it, you need it. Something like Emacs' edebug would rock my world. | errors | stacktraces | |
| 61376813 | The stack traces, on nested anonymous functions can get pretty hairy. Most of the time I can figure out what the problem is, and then the information in the stack trace is very clear, could we have better behavior there? | errors | Stacktraces | |
| 61385195 | Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! | errors | stacktraces | |
| 61386076 | Stack traces/debugging/profiling are still a pain. Error messages in general Null pointer exceptions | errors | stacktraces | |
| 61395568 | Error messages - the stack-traces are hard to read and require understanding of the implementation. | errors | stacktraces | |
| 61405381 | If I had to pick something, and this isn't something that really seems to hamper my work or hobby use of Clojure very much, it would be the desire for better ways to make sense of stack traces when something goes wrong (possibly something in a JVM library, for example). Really, I'm still pretty spectacularly happy with where Clojure is right now, and I recognize that my lack of a good answer here probably just indicates that I'm not successfully trying to do "enough" with Clojure to find warts and problems yet. | errors | stacktraces | |
| 61414090 | Vague stacktraces | errors | stacktraces | |
| 61418011 | stacktraces | errors | stacktraces | |
| 61419796 | It's a pain to deal with JVM tracebacks for things like syntax errors. I'd really rather Clojure have its own traceback formatter with knowledge of sub-expressions and so forth. | errors | stacktraces | |
| 61429681 | Error messages (stack traces) | errors | stacktraces | |
| 61436873 | Stack traces are often needlessly long. Also, debugging is really difficult. | errors | stacktraces | |
| 61447153 | Slightly cryptic stack traces (the destructuring ones are particularly egregious). | errors | stacktraces | |
| 61457256 | I can't think of any serious issues in Clojure. But reading Clojure stack traces is painful. | errors | stacktraces | |
| 61507258 | Stack traces and interactive debugging (in emacs at least). | errors | stacktraces | |
| 61538638 | Incomprehensible stack traces on JVM. | errors | stacktraces | |
| 61557192 | Modeling enterprise data: I had a hard time finding comprehensive documentation on this fundamental topic. Reading and understanding stacktraces in the REPL is difficult. They are noisy and identifying the source code that fails isn't easy. Why isn't the failing source code directly displayed, with its line numbers and source file name? Profiling memory usage is difficult (with Java profiling tools like JVisualVM). | errors | stacktraces | |
| 61584767 | reporting errors, stack traces | errors | stacktraces | |
| 61595908 | I've probably got used to it by now, but the cryptic stack-traces are baffling when trying to teach newcomers. Usually the conversation goes: 'ah, a WTFException', 'that means that <X>', 'how on earth did you know that?!', 'I've seen it before...' | errors | stacktraces | |
| 61862305 | stack traces | errors | stacktraces | |
| 61885408 | Atrocious stack traces Java culture leaking in | errors | stacktraces | |
| 62096390 | The JVM error message | errors | stacktraces | |
| 62107896 | It's really hard to think of any! If pressed, I'd say the weakest points are: the default error reporting/stack traces can be hard to handle. And the ns macro syntax can sometimes be a bit confusing. Although I feel that less now that I've stopped using 'use'. | errors | stacktraces | |
| 61366238 | Debugging errors via stacktraces can be difficult. | errors | ||
| 61391697 | I believe that feedback to the user/developer needs to become a first-class priority within the Clojure runtime and compiler. This means a much greater focus on identifying errors, including user errors, and providing real feedback about the cause of the problem and guiding users towards a solution. It means that a compiler error should be reported in an organized and readable fashion ... not as 100 lines of nested stack trace. It means that the compiler should trace its behavior in such a way that the true location of errors can be reported (contact me offline for a more complete discussion of this - hlship@gmail.com). Clojure is, for me, very pleasant to work in ... right up until I have a problem, such as an invalid namespace definition, or passing improper parameters into a function. At that point, it can be hair-pulling exercise to extract out the details of what went wrong so that I can identify where to fix the problem. I think many would see the current status quo as a barrier to entry: "I guess I'm not smart enough to use Clojure". No such barrier should exist, as in nearly every real way, Clojure is the simplest and easiest language I know ... but the current indifference to the needs of the user creates an artificial message that Clojure is only for the Rich Hickeys and Stu Halloways and Cognitects of the world. | errors | ||
| 61395916 | bad errors :) | errors | ||
| 61404780 | Error messages | errors | ||
| 61406536 | I'd like to see some functions become less "forgiving". For instance, `(:foo 1)` and `(get 1 :foo)` both return `nil`, but it seems to me it would be more helpful for them to throw an exception. Calling these functions on a number (or other incompatible objects) is, in my experience, always a programmer error and throwing early would make those errors easier to find. | errors | ||
| 61407648 | Being "reader based" is both a benefit and a curse, having code "run" when "compiling" ( i.e. lein compile, mvn compile ) can lead to some interesting, and confusing bug hunting. | errors | ||
| 61408607 | Error messages / debugging! This is sure to remain a favourite. | errors | ||
| 61418242 | Stack traces, debugging, error messages, documentation. | errors | ||
| 61435766 | it's not friendly to new users given the poor error messages at language level, a strategy copied by pretty much all clojure libraries. | errors | ||
| 61438309 | those runtime errors that do not point to a specific place in the code. | errors | ||
| 61473886 | hard to interpret error messages | errors | ||
| 61526708 | Some of the compilation errors are just weird. | errors | ||
| 61662936 | The poor error messages maybe. | errors | ||
| 61763243 | Clojure's weak spot is the information given at compile time, mainly for stack traces, but also type information. (I'm aware of core.typed, but there is zero documentation or 'community use' at present). | errors | ||
| 61843098 | Error messages could be improved. | errors | ||
| 62040537 | Error messages, etc. Lack of transparency in core dev. Lack of transparency in official contribs dev. | errors | ||
| 61511825 | it's main goal, targeting the jvm could be it's weakest point. the jvm is a great platform, but is not going to be as dominant in the future as it has been this years. All its libraries are wrappers of some java lib/fw and they are not easily portable to other platforms. I am more interested on BEAM than JVM, for now. | host | BEAM | |
| 61403745 | I don't know that it's a glaring weakness, but I think some more focus on ClojureCLR would help to grow the community. I can't conveniently use Clojure on the back end for the Web because I'm constrained to IIS on the server side. If I could easily use ClojureCLR in a ASP.Net application, that would be fantastic. | host | CLR | |
| 61953299 | Clojure clr is interesting but very poorly documented | host | CLR | |
| 61369790 | Lack of native compilation. (Targeting iOS for example) | host | ios | |
| 61416457 | Target JVM and enterprise space - excellent Target browser/JavaScript - excellent Target iOS - pleeeeze | host | ios | |
| 61489627 | Lack of support for Objective-C runtime as a deployment platform (for iOS development) | host | ios | |
| 61498080 | Its primary tethering to the JVM has given it powerful host interop, but the unavailability of a robust C/C++/Objective-C runtime prevents its use in my primary area of development, iOS. | host | ios | |
| 61545857 | It does not run on iPhone/iPad | host | ios | |
| 61357943 | The JVM | Host | JVM | |
| 61358983 | It's biggest strength is also its biggest weakness. It'd be nice to be able to ditch the JVM if desired. | Host | JVM | |
| 61359924 | You have to learn Java alongside Clojure through the stacktraces. | Host | JVM | |
| 61360439 | It “feels” heavy because of the JVM. | Host | JVM | |
| 61364472 | Java ecosystem. | host | JVM | |
| 61377935 | The JVM as the central component of Clojure is both it's biggest advantage and it's biggest downside. While the Java ecosystem is very large and fairly comprehensive, the culture of Java is to pretend that it lives own it's own. Integrating more closely with the core OS is time consuming and often fraught with difficulties. Just as one small example, it is extremely difficult to unpack a zip file in java and still retain original ownership/permissions. | host | JVM | |
| 61382469 | Dependence on the JVM is a two edged sword; there are a ton of benefits but ultimately it is controlled by Oracle. Oracle tends to consume and destroy successful things. Clojure also needs a non-JVM host that can be used for writing scripts. Finally, Clojure Docs needs to be updated :D it's an awesome site, just... out of date. | host | JVM | |
| 61389350 | The Clojure's most glaring weakness comes from the JVM. While the JVM brings a lot to the table, there is an impedance mismatch it an UNIX-based systems. It would be great if our tooling ecosystem could help overcome this. | host | JVM | |
| 61399801 | That the default version depends on (the huge) Oracle Java JDK, rather than being a simple C-based portable native compiler. | host | JVM | |
| 61411492 | The armies of mediocre java developers, and their mutable java code creeping into the library eco-system. | host | JVM | |
| 61419625 | Too tied to the JVM. Should have it's own VM. | host | JVM | |
| 61420458 | Being wedded to the JVM for its primary implementation is still Clojure's biggest weakness. It brings a lot of benefits in terms of adoption and library re-use, but puts hard limits on Clojure's runtime performance and prevents it from being useful as a scripting language. | host | JVM | |
| 61438146 | The JVM and its ecosystem. It's too slow for numerics, too bloated to deploy for client-side apps on the desktop or on iOS, too enterprisey to be as productive as ruby/python for web development. The world is web dev and mobile and enterprise. Clojure's sort of plausible for enterprise because of java, but that's it. Concurrency is usually irrelevant. | host | JVM | |
| 61439922 | Too tied to the JVM... I want to run a solid implementation on ARM! | host | JVM | |
| 61470790 | Java | host | jvm | |
| 61543134 | The over-dependence on the Java stack. Somewhat ironically this is also one of Clojure's greatest strengths. | host | JVM | |
| 61724038 | Oracle | host | JVM | |
| 62061467 | If you don't use java much, I don't think it as easy to get going as one might think; There are many things that do not work as advertised out of the box (mostly on osx, but even on linux); | host | JVM | |
| 62062231 | too tied to the jvm ecosystem | host | JVM | |
| 61359800 | Lack of native compiler/Clojure in Clojure | Host | native | |
| 61413153 | No good native implementation (clojure-metal/clojure-c). | host | native | |
| 61547439 | The alternative implementations should gain more attention and support from the community. I personally don't like the JVM because memory usage is often more important for me than CPU usage. I was thinking about using ClojureScript with node.js, or even ClojureC, but it would be so much more painful: tools like Leiningen and most libraries focus on JVM, and _some_ have some support for ClojureScript. But experimenting with ClojureC or clojure-py would take a lot of effort. | host | native | |
| 62017172 | Performance and C library interop. These sort of go hand in hand, but are also the main reasons I would love to see a version of clojure on the llvm. Python, though slow, does well in the scientific computing space due to relatively easy interop with fast C libraries. | host | native | |
| 62027179 | I don't know much in general not just clojure to judge awesome clojure but I think a distinct extension for pure clojure would be nice. clj for jvm cljs for js c or cl for pure clojure (that hopefully runs regardless of target host) | host | native | |
| 61378427 | Right now, I just wish I could run it on a Ruby VM :) | host | Ruby | |
| 61362081 | From the technical point of view, maybe the lack of tail-call-optimization on the host platform (JVM), so you must remember to user recur in your clojure code, and the lack of pattern matching by default for function arguments. But those are really minor points. | Host | TCO | |
| 61402303 | JVM is great, but no longer a goto choice for portability (think mobile). Clojurescript may be a passable alternative, but language differences are a concern. | host | ||
| 61383562 | it would be nice to have better Android app development support | host | Android | |
| 61411963 | Missing documentation on how to create in a straightforward manner JARs which look and feel exactly as if they had been written with Java; esp. regarding the "translation" between Java packages and Clojure namespaces. I.e.: to enable Java programmers to "import com.example.coolclojurestuff" | interop | Java usage | |
| 61360510 | Lack of easy integration with host OS functions and hardware. | Interop | OS | |
| 61367994 | Clojure is incompatible with several Java libraries because when importing a class it runs its static initializers. | interop | run static initializers in compile | |
| 61368648 | Interop with existing libraries on the host platform is great, but lots of libraries don't share Clojure's philosophical ideals, and create a paradigm mismatch. On the whole it's obviously useful to interop, but sometimes it's Simpler to rewrite things in Clojure. lein is fine as a build tool, but not for deployment tool. | interop | ||
| 61387688 | Async. While core.async is coming along nicely, I still don't see why some of the core functions can't support some async capabilities. | lang | async | |
| 61368835 | Except for the slow pace of change in contrib libraries (I understand why core changes as slowly as it does), most of my frustrations with Clojure are things that couldn't be changed without the language ceasing to be Clojure (and becoming Haskell, or whatever). The frequently surprising behavior of runtime initialization and AOT compilation has bitten us several times though, and I could wish non-AOT and AOT code were just more _like_ each other. | lang | AOT | |
| 61371499 | AOT is a second class citizen, slow to build, quirky on deploy | lang | AOT | |
| 61422026 | AOT is a second-class citizen - excruciatingly slow builds and corner-case differences between AOT'd apps and compiled-at-runtime apps. | lang | AOT | |
| 61506977 | Edge-case discrepancies between AOT and compiled-at-runtime Clojure. Gotchas and excruciatingly slow build times. | lang | AOT | |
| 61685092 | Number of class files when AOT | lang | AOT | |
| 61356482 | The atom of agents - i keep constantly running in to situations, where I need to maintain handles on generated agents, channels, or other atoms. All books and documentation say "don't put mutable objects in atoms". | Lang | Atoms | |
| 62028399 | It's really hard to use unboxed values. It requires advanced tactics to stop the compiler from doing intermediate boxing. And it's even harder to pass around unboxed values from function to function. | lang | boxing | |
| 61376955 | The monolithic Java-based compiler. | lang | compiler | |
| 61705760 | Compressing function names and meaningless function names - aget, aset, conj, assoc, conde - turn code that could be highly expressive into meaningless soup that repels developers with any aesthetic sensibilities. | lang | fn names | |
| 61422397 | Needing gen-class to extend with custom init | lang | genclass | |
| 61361849 | I miss some things from Haskell-language family, like automatic partial application (need to use partial), (.) operator for function composition (need to write comp), missing pattern matching (core.match is not sufficient), missing ordered maps (need to use flatland's ordered map). | Lang | Haskell | |
| 61525659 | - Most of the time I do not use sequences in a lazy way and it often bites me - Dynamic typing (Stu said static typing only prevents easy mistakes. I agree, but I still make these mistakes and would like a tool that helps me with that) | lang | laziness | |
| 62047422 | The mix of lazy-seq and non-lazy functions. I have rarely had a use case for lazyness, so it has only caused problems when results mysteriously aren't realized and minor performance penalties. It is one of the harder things for a beginning clj dev to wrap their head around. | lang | laziness | |
| 61906379 | Proliferation of bizarre macros that complect things (I said it) you have to be "in the know" to figure out what they do -> | I'm a newbie so these things stick out for me now. | lang | macros | |
| 61354371 | After all these years I still find explaining problems with namespaces problematic. | Lang | namespaces | |
| 61357777 | File hierarchy and namespaces. I don't see why they have to be bound so tightly. | Lang | Namespaces | |
| 61371984 | I always have a hard time figuring out how to use/require/import stuff in my namespace (be it in a file or at the REPL) I think a clear single entry point for documentation would help best. http://clojure.org/documentation vs http://en.wikibooks.org/wiki/Clojure_Programming vs (http://clojuredocs.org/ vs http://clojure-doc.org/ !!!) | lang | Namespaces | |
| 61378384 | A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. | lang | namespaces | |
| 61400706 | clojures namespace handling. Clojure defaults to immutability almost anywhere but forms like def modify the current namespace. This leads to incidental complexity and annoying problems with code reloading at the repl for example. | lang | namespaces | |
| 61424530 | Not sure how to articulate this, but namespaces seem to be implemented in a strangely non-Clojure way currently. Surely they should be more like maps, with the environment being a versionable immutable value, instead of the rather scarey mutable vars system. I have servers which cannot be stopped, and I always get a bit worried when I :reload namespaces, even though I've tried to make them all stateless and manage their lifecycle well. On another note, I feel Clojure could learn a lot from Smalltalk. I despise the culture of emacs and the text-based world. What Smalltalk showed us, back in the 70s!, was that programming can be a well-rounded, extensible, fun, comprehensive, self-explaining, approachable, multi-sensory experience. There is great potential for there to be a Clojure programming environment, with an image backed by Datomic, which replicates and builds on the Smalltalk environment. | lang | namespaces | |
| 61585256 | Namespace syntax is confounding to the beginner. Do I quote it? Stuff in a vector (and quote too)?? Up to date examples in the doc would be really helpful. For a lot of libraries some basic information is assumed and for the beginner this could be a hurdle not worth jumping over. | lang | namespaces | |
| 61717623 | Namespaces are a horrible, broken mess. They are a wildly complected nightmare. | lang | namespaces | |
| 61889778 | Namespaces are a poor alternative to modules. We sometimes see ourselves in a situation where we must opt between code duplication (quasi-verbatim ns in several projects), littering fns with extra parameters, or using mutability. See Newspeak or even Scala for better alternatives. | lang | namespaces | |
| 61376694 | I wish the core abstractions used protocols! | lang | protocol internals | |
| 61489070 | managing native resources | lang | resources | |
| 61369620 | The sequence/collection API is very patchwork and inconsistent. In partcular: Next vs. rest (+ nil-punning), the confusion between lists and seqs in the API (e.g. list*). | lang | seqs / collections | |
| 61381362 | For my personal use, mostly things like good support for static methods (other than backed by Vars as with gen-class), nested loops (see Q. 10) etc. Nothing deal-breaking, to be sure. | lang | static methods | |
| 61355750 | Implementation details leakage (stacktraces, into written with reduce -> can be used with reducers, recent hash code of sets discussion, ...) | Lang | ||
| 61435062 | Java and its GUI are in with one install, you have layers. I tried to implement simple logical expressions and your functions can't do true and false properly -- there should only be ONE possible way to represent FALSE or TRUE and (not TRUE) is FALSE. Even the comments within the compiler (great idea) need to be proofed by at least one other person... | lang | ||
| 61397764 | reader macros | lang | reader macros | |
| 61451799 | Functional programming is still a foreign concept for mainstream developers. | learning | FP | |
| 61577391 | Not about clojure in particular but coming from java it's much harder to find solutions for problems that are functional because most languages are object oriented. It makes the learning process much more difficult. Clojure itself, the language, is very easy to learn. It's the functional aspect that makes it hard, at least for me and other people I know. The advantage is that the community seems to exist of people who are REALLY interested and are doing some amazing things. | learning | FP | |
| 62091157 | Not enough people exposed to functional programming. | learning | FP | |
| 61398267 | Coming from an OO, it was hard to develop a sense of design aesthetics; how to decompose functions into namespaces, what sorts of coupling are problematic, etc. Also, tooling: how to use the repl and automated tests effectively, how to decipher (and avoid) exceptions. | learning | OO to FP | |
| 62098469 | Lack of standards the beginners could cling to. | learning | style | |
| 61376166 | Still learning all the great existing features. The only part I struggle with is the functional aspect and I consider that more my problem in learning idiomatic way to do things than blaming the language. | learning | ||
| 61404384 | Approachability to outsiders – a lot of the conventional wisdom assumes the kool-aid has been drank. | learning | ||
| 61408706 | learning curve | learning | ||
| 61408847 | It seems hard to read/understend/enter for programmers who are not used to it. Therefore a lot of convincing work is needed to make a team give it a chance. | learning | ||
| 61415145 | Difficulties in bringing new people to the language. Acceptability. | learning | ||
| 61431440 | Clojure's greatest problem, is perhaps, it's greatest strength: it's heavily Lisp influenced. Many programmers I know are still... "indoctrinated" to a Java OOP world view and would need intensive "un-learning" to appreciate the world view offered by Clojure's Lisp heritage. | learning | ||
| 61445363 | The learning curve for non-Java programmers is high and steep, especially as regards deployment. Java interop is surprisingly easy in spite of sparse previous Java experience. | learning | ||
| 61470607 | Still weird for new users. People are a lot more receptive than they used to be, but we need to invest in making it super easy to get people hooked. | learning | ||
| 61478906 | Also it's best asset, is the paradigm shift in thinking required to express the simple ideas. Takes longer to learn what to do than to actually do it, for many many months, even as a seasoned developer. | learning | ||
| 61503225 | Clojure is initially unapproachable due to the setup and stacktraces (java). Since development is Repl driven, the developers I have been working with don't know how to do that kind of development and resort back to python/ruby ways of scripting. A good working setup through Lein is nice, but the real a-ha moment is running an interactive repl that is tied to the text editor where code loading is a keystroke away. | learning | ||
| 61507631 | Onramp for newcomers is still too difficult. | learning | ||
| 61543218 | Making the beginner path more bearable | learning | ||
| 61550787 | Steep learning curve | learning | ||
| 61575086 | Noobfriendlynessless | learning | ||
| 61360761 | Learning curve is steep, though satisfying. | learning | ||
| 61507414 | coherent method of finding and grabbing libraries - clojars + sometimes getting a github URI isn't good at knowing libraries. | libs | dep mgmt | |
| 61362436 | Difficulty in finding the correct libraries. Interop is cool, but when you want to do things in clojure style... | Libs | discovery | |
| 61371621 | Lack of cohesion. This includes the "standard library" of core.*, tools.*, etc. libraries as well as the fragmentation of development environments. I feel the Clojure *ecosystem* would be more discoverable and would project more reliability if Clojure's web presence were more clearly laid out. At this point, Github acts as the table of contents for Clojure's standard library, and folks have to depend on various other websites either for lists of libraries for particular domains, or more narrative/practical documentation that could be made available within the official Clojure web presence. While things are moving fast, as with ClojureScript, I can understand not taking the time to consolidate information about various efforts, libraries, and experiments in one place. However, it seems that JVM Clojure has reached a level of maturity both in the language implementation and ecosystem that the lack of a cohesive body of knowledge does not do justice to the language and community. | libs | discovery | |
| 61436627 | As a very experienced Rails developer who completely gets + like the Clojure "way", finding libraries + documentation + community remain the biggest challenge, and a major step down from that world. | libs | discovery | |
| 61525553 | Fear of batteries included, opinionated, comprehensive frameworks for web specifically. Killing adoption. | libs | frameworks | |
| 61382140 | Incanter is a great library but needs much more attention and development to be on par in terms of performance with other data analytic libraries found in other languages. Ideally, Incanter would be much more performant (comparable with C) and offer a clojurescript version that offers D3-esque visualization capabilities. | libs | Incanter | |
| 61379578 | native data analysis/linear algebra libraries | libs | linear algebra | |
| 61361235 | Lisp Curse: every domain has a dozen libraries, each of which implements 30-60% of what is needed to deploy a non-trivial app, and none of which integrate well together. This is exacerbated by the community's hostility to (and ignorance of) frameworks. Beautiful algorithms are easy. Integration is the hardest and most time consuming part of any software effort, because that is where all the edge cases are. clojure has no solutions for this. | Libs | Lisp curse | |
| 61367025 | Too many choices for libraries doing the same thing. The incredible amount of options when it comes to things like logging, database/ORM, etc mean that choosing the one that will be available long term is difficult as the whole community isn't behind a single solution. Seems counter-intuitive, but for example on server side, you have to choose from ring, noir, aleph, pedestal, http-kit, immutant, vertx, etc. For a "newer" community, it would be helpful if the options for web server had a single or even two options as then both would likely be supported and exist long term. As it stands right now, no one option is the norm other than ring somewhat and so any choice can easily be deprecated within 6 months to a year which is not good for production usage. | libs | Lisp curse | |
| 61420973 | Better statistical and scientific computing libraries | libs | math | |
| 61422904 | Not really a weakness of the language but for the kind of work I do, scientific programming, it does not have the same level of library maturity and community as Python with Numpy, Scipy, Pandas, etc. I am not sure it will ever have enough to convince people to make the jump. | libs | math | |
| 61437918 | From scientific perspective, lack of good numeric libraries for matricies and ND arrays (compare to say SciPy/NumPy or Matlab) Hard to interact with linux/BSD OS, i.e I still tend to write many bash scripts / C tools | libs | math | |
| 62084116 | There are not high-quality Clojure libraries that work with scientific computing libraries, like those that NumPy/SciPy make accessible to Python users. | libs | math | |
| 61360440 | Many libraries still "too young" | Libs | maturity | |
| 61365059 | Libraries/frameworks not as developed due to age | libs | maturity | |
| 61419318 | I fear the community is too small to sustain a good set of libraries. Instead it seems to become the same clusterfuck of half abandoned / derelict libraries as in Python / Ruby where it's often necessary to read to code line-by-line to trust it doesn't completely fuck your application over. This as apposed to Java / C where there are good trusted and established libraries where the risk of using them is more limited. | libs | maturity | |
| 61420724 | The fact that the ecosystem is still under development and thus many libraries don't exist or are not battle tested. | libs | maturity | |
| 61430812 | lack of libraries | libs | maturity | |
| 61437337 | Lot of libraries having overlapping functionalities with less documentation. Less of batteries included frameworks for webdev, example Luminous Web which was addressing webapp development doesn't have a good authentication mechanism supporting various openid providers etc which are taken for granted in other languages. Friend's looks promising but documentation is not comprehensive etc. | libs | maturity | |
| 61444892 | Libraries are still immature. | libs | maturity | |
| 61457002 | The open-source Clojure library / tooling ecosystem is focused too much on developer convenience and not enough on quality, stability, and innovation. | libs | maturity | |
| 61526369 | A lot of the libraries, while of high quality, have not yet reached a stable 1.0 release. The language itself: not exactly a problem with Clojure per se, but a lot of people are turned off by Lispy parentheses.. their loss.. but.. :-( | libs | maturity | |
| 61567109 | ClojureWerkz. I find their pretentious declaration of 'this is the right way', especially when it comes to their documentation, to be damaging to the Clojure community. I find their docs to be completely unreadable and their projects never pass a sniff check of 'go read the code'. Obviously the answer is for me not to use these libraries, but I am concerned that their hold over the community may make new libraries have a similar convention. | libs | maturity | |
| 61616064 | Sometimes the ecosystem (third party libraries) are either hard to find, or have a very short life-time (dropped after several month of development). that makes it pretty difficult to find what you need. it's not really a weakness of clojure: but I find it still hard to structure code (especially in bigger projects -> month of development). | libs | maturity | |
| 61677990 | Immature and poorly documented libraries (RTFS required often). | libs | maturity | |
| 61778242 | The libraries are often immature and sometimes not very well designed. | libs | maturity | |
| 62027855 | The one that I've had several times is that the "core" JDBC library is far from ready for heavy use. It only exposes a small fraction of JDBC functionality. It obscures things that could readily be made available. That is just one I have personally stumbled on repeatedly. The maturity of the libraries, especially those with the core name, is the most glaring weakness I see. | libs | maturity | |
| 61545043 | Lack of a good data visualisation library (I come from R) | libs | visualization | |
| 61383636 | Still much, much too hard for people interested in joining the community to get started building and deploying web apps. I believe this stems from the community emphasis on individual libraries and open disdain for frameworks, as well as the dependence on emacs as the main editor. I fully agree with the community that libraries are preferable in fostering a healthy ecosystem evolution over the longer term, but there's something to be said for a set of well tested libraries that just work well together for common tasks beginners want to accomplish. It's my hope that LightTable can become that approachable editor. | libs | web apps | |
| 61614957 | In the web domain, Clojure can't beat Ruby in terms of frameworks for productivity such as Rails. This is a needed killer app if Clojure is to make a huge impact in full-stack web development. | libs | web apps | |
| 61355767 | I think there needs to be a broader core.* toolset to match python's "batteries included" approach. There could be a core.community.* approach for not 100% vetted libs. Small enhancements like useful & friend are hard to evaluate on a day to day basis, and newcomers have to rely on arbitrary metrics at first (is the author a known contributor, who else is using this lib ?). | Libs | ||
| 61422764 | (relative) lack of idiomatic libs | libs | ||
| 61478482 | Reliance on existing java libraries and frameworks. | libs | ||
| 61516579 | I think the standard library should be more comprehensive (like include a socket programming api). | libs | ||
| 61431675 | Immature native libraries. | libs | maturity | |
| 61371645 | Adoption by big companies | marketing | adoption | |
| 61372704 | Adoption is the aspect I worry about most. I love using Clojure and want very much for it to be a viable option at any company. How do we get developers to know about Clojure and to use it - especially over JVM languages that appear to be easier to get started with. | marketing | adoption | |
| 61378384 | A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. | marketing | adoption | |
| 61362264 | The relatively common belief that dynamically typed languages lead to hard-to-maintain systems. Perhaps Typed Clojure might be enough to help convince people who hold this belief that Clojure has their concerns covered? | Marketing | Dynamic langs | |
| 61589629 | Hard to sell to enterprise people | marketing | enterprise | |
| 61360991 | The world needs to be better-educated about Clojure's strengths. | Marketing | ||
| 61363697 | Nothing really, we just need to keep growing the community. | marketing | ||
| 61494566 | Some docstrings of core functionality are outdated. The focus in Clojure marketing should not be targeting developers from foreign languages anymore, but widely (in schools, education etc.) presenting Clojure as the king of abstraction in Computer languages that everyone can learn without many knowledge about other programming languages or IT-specific problem domains. Clojure makes it finally possible to learn a craft from the top of its evolution. | marketing | ||
| 61501343 | It's difficult sell still. | marketing | ||
| 61529694 | The "different-ness" from almost every mainstream language, and working to convince people from those environments that it is a positive. | marketing | ||
| 61885850 | It's a "hard sell." | marketing | ||
| 61885973 | Marketing! It seems to me that Clojure community doesn't stress enough on marketing themselves , as Scala people do. Even though Clojure may be better than Scala, but the lay men do not have awareness. | marketing | ||
| 61910727 | Poor marketing (terrible website). Many abandoned libraries. | marketing | ||
| 61434918 | There is no all-in-one bundle or simultaneous release of Clojure/editor/related libraries as there is within the Eclipse ecosystem. In my company every library, no matter how small, requires separate approval, so I want a single umbrella release in a single download for the purposes of satisfying management and compliance. An all-in-one bundle of high-quality Clojure+libraries with a predictable release schedule would greatly help | marketing | batteries included | |
| 61364754 | AD hoc implementation of fundamental abstractions | misc | ||
| 61369405 | A rush to "decomplect" without a solid understanding of the implications on the composability requirements of such an approach. (not= :decomplect :composable) | misc | ||
| 61393073 | Accessibility to new users. | misc | ||
| 61423679 | Sometimes the community (there's exceptions) can be blind to places where other languages are better. I think this is because many people stop 'looking' once they've found Clojure, and assume if it was necessary, Clojure would have it. | misc | ||
| 61438153 | clojurescript cross-browser development ! | misc | ||
| 61507500 | The flexibility & power of clojure is both a blessing and curse. It gives the programmer the chance to build great software systems quickly and easily, but can also make it very difficult for new comers. It gives you plenty of ways to write something in a more complex or unmaintainable way, and you generally have to work through those implementations before you find a better way of doing the same thing. Fortunately, refactoring is also quick & easy. | misc | ||
| 61668365 | Community inertia. Clojure is doing absolutely the right thing by not compromising on immutability; however this makes it harder to sell to the ruby/python types in my office. Golang has been an easier sell because it still feels imperative enough. | misc | ||
| 62112382 | Most people rarely create macros, so they don't need homoiconic syntax. They'd prefer Clojure to have a more Pythonic syntax. | misc | ||
| 61366833 | Nothing in particular, mostly minor stuff. I might be mistaken about this, it might be possible, but it would be cool to be able to extend data types to implement the interfaces Clojure defines. I remember trying to extend patterns to implement IFn, but that wasn't possible (unlike ClojureScript, I think?) | misc | ||
| 61381351 | that is really hard to say. I think it would be nice to have some more polish, there are lots of little corners marked experimental or alpha, or not documented, etc | misc | ||
| 61417058 | I haven't identified Clojure's most glaring weakness yet. | misc | ||
| 61355531 | it's a Lisp | perception | parens | |
| 61358938 | People fear it. | Perception | fear | |
| 61361958 | Fear of lisp. | Perception | fear | |
| 61365765 | Still difficult to get people to take the plunge on it (i.e., when coming from more imperative backgrounds) | perception | fear | |
| 61370572 | I guess the hardest part is getting new developers to clojure over that initial mind hurdle. Once they have recovered from the mind twist, then they are converted for life :). | perception | fear | |
| 61372144 | I think parentheses scare people. Also not everyone loves the JVM (but my day job is Java, so I like having access to all that Java stuff). | perception | fear | |
| 61383954 | How different it is from other mainstream languages. | perception | fear | |
| 61384877 | In our shop, it's mostly the perception of being an arcane Lisp dialect that keeps many from wanting to try it | perception | fear | |
| 61438218 | It is so different that it is difficult to get everybody on board. | perception | fear | |
| 61616546 | Clojure is a dramatic change from "mainstream" languages. I suspect many developers, and companies are - and will be - reluctant to use it. Does this mean developers should continue investing time in it? Or would they see a greater ROI by applying the functional lessons learned from Clojure to projects implemented in more "mainstream" languages? | perception | fear | |
| 61627599 | People are nor willing to learn it. | perception | fear | |
| 61445206 | 1. Functional programming is not all that popular yet as it is supposed to be. 2. Building case to convince people to adapt Clojure. | perception | FP | |
| 61357583 | It is, or looks like it is harder/weirder than other languages. | Perception | looks weird | |
| 61402107 | Its reputation as a "concurrency language" or a language for solving "very hard problems", as opposed to a general-purpose language that gives you great productivity across domains. | perception | only for hard problems | |
| 61432681 | People often let the original syntax bias their opinion, because they think it's going to be a lot of counting ()'s. Better exposure for tooling that makes this a non-issue would help the adoption of clojure. | perception | parens | |
| 61439406 | Tends to be overlooked because of its Lispy syntax. | perception | parens | |
| 61479139 | Perception of lisps from outside world | perception | parens | |
| 61504119 | The most glaring weakness is it's lisp, but the greatest stength is it's lisp . . . (ha ha) run time performance seems to be lagging behind other language gains over the past two years. | perception | parens | |
| 61507333 | being a Lisp, plain and simple. it's hard to convince people it's not crazy to use it. | perception | parens | |
| 61510757 | Parentheses freaks the people out | perception | parens | |
| 61554396 | A number of collaborators won't consider a Lisp. I would not call this a weakness or a blind spot, but a problem. When comparing functional programming to OO, almost all Clojure programmers focus on OO as commonly practiced. This is understandable and relevant, but It also has a cartoon like feel. Many projects do create complex class hierarchies with no behavior and that should be criticized, but its not OO as Kay, Beck, Fowler or Wirfs-Brock understand or advocate it. The result is an impoverished discussion. | perception | parens | |
| 61615145 | Lisp syntax continues to be the single biggest barrier-to-entry to getting other developers to look at Clojure. I find it similar, but to a lesser degree, to some developers' initial reaction to significant white space in Python. | perception | parens | |
| 61710495 | most programmers don't understand the benefits of functional programming, and don't want to look at Clojure because of the parenthesis. I think the ecosystem has matured technically and now needs to bring in a wider audience for adoption. | perception | parens | |
| 61442034 | It's very hard to read. Between its immature documentation tools and its dynamic nature, I spend a lot more time diving through source code for third party libraries than I'd like. The language would really benefit from a proper "Javadoc" alternative, and the tools that currently exist aren't quite up to snuff. | perception | readability | |
| 62123898 | code readability | perception | readability | |
| 61373938 | Perception of snootiness | perception | snootiness | |
| 61458990 | It requires smarter programmers | perception | ||
| 61509395 | Educating developers who aren't familiar with lisp. | perception | ||
| 61897946 | Performance / Integration with android's Dalvik VM. Clojurescript as the "Mobile Story" doesn't work on android yet - far from it with regard to native UX. | performance | android | |
| 61357427 | It's really slow compared to Common Lisp. | Performance | Common Lisp | |
| 61358601 | Performance issues can be troublesome for soft real-time applications like game development. | Performance | games | |
| 61509940 | The lack of ability to use co-processors. | performance | gpu | |
| 61405703 | There are a lot of people in the mailing list having problems getting Clojure to perform well with multicore problems. Given that this is one of Clojure's big selling points it doesn't feel like these features have been very deeply tested in the same way that, say, the equivalent Java libraries have. | performance | multicore | |
| 61363798 | not compiling to native code as Go does | performance | native | |
| 61363954 | Difficult to use for games and similar high-performance, real time applications. | performance | real time | |
| 61356785 | runtime performance seems to generally be worse than Scala. Of course Clojure does a lot more internally, but it's hard to explain that to someone who has only done OOP. | Performance | Scala | |
| 61356293 | Startup times | Performance | startup | |
| 61356317 | Startup time. Tooling designed in Clojure (e.g. Leiningen) takes a very long time to start up. | Performance | startup | |
| 61359745 | Start-up time and memory use | Performance | startup | |
| 61361914 | good debugger, funky error messages, slow startup | Performance | startup | |
| 61362013 | JVM starting time | Performance | startup | |
| 61362875 | Startup time | Performance | startup | |
| 61363275 | Start up time is *still* a killer with a standalone application of any size, with a bunch of libraries. | performance | startup | |
| 61364063 | JVM startup time. | performance | startup | |
| 61364764 | startup time and overall typical runtime speed, confusing java interop | performance | startup | |
| 61365446 | Startup time. Hopefully porting to additional backing runtimes will help with that, though we need to be careful about compatibility and portability of Clojure code to those systems. A compatibility layer may be useful. | performance | startup | |
| 61366144 | Startup Speed | performance | startup | |
| 61367162 | Startup time and memory usage. | performance | startup | |
| 61367496 | The startup time of the JVM. | performance | startup | |
| 61368103 | Probably the start-up time and lack of ability to compile to a binary. I would totally write all my command-line utilities in Clojure if it weren't for that. | performance | startup | |
| 61368948 | It's partly because of the JVM, but clojure programs are really slow to start. | performance | startup | |
| 61369426 | startup time :( | performance | startup | |
| 61370513 | JVM start up time | performance | startup | |
| 61371420 | JVM/Startup time | performance | startup | |
| 61371948 | Startup time. 1.5―2.0x JVM startup time would be tolerable for scripting. | performance | startup | |
| 61375903 | Startup time - loading docstrings etc. | performance | startup | |
| 61378384 | A weakness about what? About adoption? => A reasonable debugger About mobile? => Fingerprint, memory consumption (unless you think clojurescript) About general use? => Startup time (JVM related) About the language? => Lousy namespaces and many cryptic compiler error messages. Regarding adoption I'm not sure a huge community is desirable though. | performance | startup | |
| 61392770 | startup speed | performance | startup | |
| 61395927 | Slow start-up time | performance | startup | |
| 61397964 | Not very suitable for GUI programs due to slow startup time of JVM. | performance | startup | |
| 61403723 | The JVM startup time. | performance | startup | |
| 61408747 | JVM bootstrap time | performance | startup | |
| 61413926 | Startup time for quick scripts (and I'm not a fan of the various "hot JVM" solutions) | performance | startup | |
| 61417268 | JVM memory pressure and start-up time are hindrances. | performance | startup | |
| 61417520 | Startup Time. | performance | startup | |
| 61417834 | JVM startup overhead, documentation | performance | startup | |
| 61422828 | Slow startup time and lack of proper documentation | performance | startup | |
| 61424650 | JVM startup time. | performance | startup | |
| 61429592 | That damn jvm startup time. | performance | startup | |
| 61435032 | Startup time | performance | startup | |
| 61445858 | startup time | performance | startup | |
| 61493377 | Startup speed | performance | startup | |
| 61505460 | Its usefulness in many potential applications is limited by the jvm's startup time. | performance | startup | |
| 61506735 | For my usage, the weakest spot is startup time, but maybe I'm just using it wrong. | performance | startup | |
| 61527816 | slow start-up time | performance | startup | |
| 61530330 | Start up time | performance | startup | |
| 61548472 | JVM Prejudice, I used to have such against Java. JVM startup time still sucks. | performance | startup | |
| 61564154 | the slow start-up when using the JVM | performance | startup | |
| 61694544 | start up time and deployed package size (these are related, and not just the jvm's fault) | performance | startup | |
| 61713933 | Slow startup time | performance | startup | |
| 61930880 | slow start-up time of jvm | performance | startup | |
| 62120166 | Startup time for scripting. (indirect problem) | performance | startup | |
| 61359670 | Optimizing tight loops without resorting to Java can be hard. It's often hard to figure out what needs to be tagged (and how) in order to achieve best performance. | Performance | tuning | |
| 61362362 | JVM limitiations (slow startup, no staged eval, slow multimethods, lack of value types, no TCO) | Performance | ||
| 61368054 | Runtime speed and/or launch speed. Otherwise, it's a good melting pot :-) | performance | ||
| 61372920 | Performance. And yes, I know I'm also asking for better Python interop, but there are multiple scenarios where Clojure shows off the worst side of the JVM (RAM and GCs), and where Python is slower but more resource-efficient. | performance | ||
| 61396501 | Runtime Speed | performance | ||
| 61400278 | Performance is not quite there for desktop/android applications. | performance | ||
| 61407782 | Runtime characteristics, in time and space, for some use cases. Mainly hard to embed or deploy (due to artifact size), or slow to start, or consumes too much memory. Usually necessitates using a special or novel host VM, which tends to be immature or incomplete even if it is performant enough. This includes use cases on Android, small computers (e.g. Raspberry Pi), cheap/lightweight virtualized servers, short-lived desktop or command line tasks, etc. | performance | ||
| 61409906 | Slow performance compared to other Java-hosted languages, let alone Java, let alone C/C++. | performance | ||
| 61419690 | Performance, both in runtime and compiler. It's *good*, but many projects take 30 seconds or more to compile; throws a serious wrench in my dev process. Keyword interning is O(n) because it does a weak ref scan over the whole keyword table. Primitive math is unpredictable. Recur is significantly slower than a java for loop. That sort of thing. | performance | ||
| 61426092 | Clojure consistently does everything I need, but not always fast enough. I frequently find the need to refactor heavily-used code into Java. This is specifically in the case of scientific applications (molecular dynamics, robotics, etc.). It may be style, or too much reflection (one can always factor out more reflection), but either a Clojure implementation in C/C++/Assembly or Clojure -> Java conversion, would be nice. | performance | ||
| 61502376 | Although it's not exactly glaring, I'd say performance; the rest is all good. | performance | ||
| 61596990 | It would be nice if the performance were closer to native Java | performance | ||
| 61613911 | performance | performance | ||
| 61903527 | performance | performance | ||
| 62030821 | Sometimes performance hits strike even with idiomatic Clojure. Hard to predict/fix, require knowledge of underlying mechanisms. | performance | ||
| 61355308 | It solves interesting, hard problems at the expensive of solving the boring, easy ones. | process | ||
| 61353736 | AFAICT, there is no committed maintainer. Lots of things _could_ be done to improve Clojure, but few are interested in the process, or waiting YEARS for simple improvements to land. | Process | attention | |
| 61356167 | Speed of bug/doc fixes in the language, hopefully changing w/ Cognitect. | Process | attention | |
| 61359422 | Slow clj.core issue handling (bottlenecks) | Process | attention | |
| 61365755 | The appearance of stalling on Clojure the language. There might be progress on tickets (patches, discussions, testing) but getting that into master and getting a release out. Even smaller bug fix releases etc. | process | attention | |
| 61367082 | The JIRA development process is very slow-paced. You'll have a long beard until you'll get feedback on some ticket/patch. And even if all is fine, i.e., you have addressed all concerns and comments, you'll usually have no indication wether it will ever hit the master branch and when. The only responsive person in JIRA is Andy Fingerhut, and he does an extraordinary good job (thx!). However, the "deciders" like Rich himself aren't that active. My impression is that they look into JIRA only before they'd like to cut a release, then select a good dozen of recently active tickets, apply their patches, and that's it. Well, that situation is basically the same as last year, maybe it has improved a little, but not enough. | process | attention | |
| 61367431 | Mainline development is understandably a slow deliberate process, but some aspects of it are relied on by ClojureScript. Recently this has improved because ClojureScript has reinvented some bits in order to move at its own rate. | process | attention | |
| 61368835 | Except for the slow pace of change in contrib libraries (I understand why core changes as slowly as it does), most of my frustrations with Clojure are things that couldn't be changed without the language ceasing to be Clojure (and becoming Haskell, or whatever). The frequently surprising behavior of runtime initialization and AOT compilation has bitten us several times though, and I could wish non-AOT and AOT code were just more _like_ each other. | process | attention | |
| 61374102 | conservative approach to accepting patches | process | attention | |
| 61385614 | The development of Clojure itself is frustratingly slow. | process | attention | |
| 61565607 | slow core library development | process | attention | |
| 61358949 | Paper CA and the development process that's quite cumbersome for contributors. | Process | CA | |
| 61362422 | High-friction core contribution process. | Process | contribution hard | |
| 61428248 | Nothing was exactly glaring to me. The contribution process seems to frequently irk people. | process | contribution hard | |
| 61359029 | releases aren't too often, no "real agenda" for next releases, some problems (like error traces/reporting) isn't fixed for a long time | Process | focus | |
| 61368092 | Relevance, Inc. | process | Relevance / Cognitect | |
| 61381631 | Lack of approachability as a design goal. The core team seems to think that being approachable to newcomers is incompatible with offering full power to experienced users, but admirable projects like Racket prove that this is not the case. | process | relevance / Cognitect | |
| 61389795 | The lack of insight into Relevance and Rich Hickey in particular, leading to the glacial pace of development. | process | relevance / Cognitect | |
| 61362001 | One coherent place to find acurate info on the language and it direction in the futur. Should be one place with : - reference documentation for every clojure major versions, with examples and remarques - language discovery, first step, download page - commercial support - libraries resources - supported tools Actual web presence of clojure is to scattered around the web. It does not help industrial, commercial acceptance and adoption. | Process | roadmap | |
| 61397520 | Until the hiring of Andy Miller the lack of community management but there still needs to be more visibility / feedback on community proposals and what the roadmap. Is there a 2.0 plan? Until Cursive a decent IDE, and the ridic emacs fetish. Now its probably the slow paths that are hard to predict till you hit one and then are hard to profile. Its time to rewrite the compiler. Oh and namespaces kinda suck. | process | roadmap | |
| 61421399 | Clojure 2.0 should merge back with ClojureScript and be more internally extensible than the current Java monolith. Clojure-in-Clojure hopefully a reality. Who's actively driving the vision now - is Rich focusing on Datomic? | process | roadmap | |
| 61490705 | There are either super advanced explanations or baby steps. Not much in the middle. | process | roadmap | |
| 61360779 | Both a plus and minus: Incredibly reserved, methodical and quiet language maintainers (Cognitect) | Process | ||
| 61372404 | Documentation. There is a lot of out-of-date information online, and the documentation quality for the core language and libraries is not nearly as good as, say, Python. Clojure has an amazingly powerful story to tell but it is also a somewhat strange story to many mainstream developers. The documentation could tell that story better, and still be simple. The several excellent books out there go a very long way but they are not enough. I do think the strictness of the CA / ticket execution process does hurt this aspect a bit. Documentation is a way for relative newcomers to contribute, but the process is slow, and not particularly simple or easy IMO. | process | ||
| 61375960 | Difficulty contributing to the language (JIRA, CA, etc) | process | ||
| 61382259 | JIRA and the CA-backed contribution process discourages positive contributions to the language. This has been talked about to death, and it seems to always end with inaction. I'm not asking for it to change overnight, but I wish as a community we could come together and make it less of an ordeal to be part of the Clojure development process. I've seen people's hard work on patches get chucked into the fire, and this is after they signed a CA, spent the time to write the code, followed the process for submitting their change, and waited a year and a half without bugging anyone, only to have it closed without comment. Those people are not going to contribute again, and I think that's a shame. | process | ||
| 61439056 | the dichotomy between the official position that contributions to the core are welcome and the fact that they are not | process | ||
| 61447313 | Improvements and fixes go in only in case they fix something for cognitect or in case drumming is reeeally loud. (Same story since years despite the efforts of people like Andy or Alex.) | process | ||
| 61462237 | Nothing in particular. Would it be kicking a dead horse to ask for Clojure to accept GitHub pull requests? :-) <ducks> It's a great language, great ecosystem, great leadership. I'm happy and am a strong advocate of the language. | process | ||
| 61475468 | Clojure seems effective for the very smart but I find a lack of documentation and recommended practices from Cognitect frustrating. E.g. clojuredocs.org is still a go-to site for me even though it only targets Clojure 1.3.0. Why doesn't Cognitect provide something like this? The hangup of not accepting any documentation or tutorials that don't have the protective halo of the Contributor Agreement is frustrating. There should be an active effort to identify the best docs, tutorials and practices out there (i.e. "useful shit") and collect them under one roof. Source: I can currently only program in Clojure very part-time. | process | ||
| 61536338 | "Toy language" attitude - the developers don't seem to care about error messages, backward compatibility between versions (e.g. the change in the meaning of = bit us, and so did the way clojure.contrib libraries just disappeared in one upgrade with just one poorly-maintained wiki page with a list of possible replacements, except in cases where there was no replacement). | process | ||
| 61399415 | If I want to write a Python script I can make a file called "hello_world.py" whose contents are "print 'hello world!'". To run it I can type "python hello_world.py" at the command line. To do the same thing in Clojure requires using "lein init", navigating down a couple of directories, editing a file, and then still not being able to run the "script" except through Leiningen. (I could use "lein run" but then I'd have to edit project.clj too.) The process of "installing" Clojure itself has gotten less painful but this barrier to running a script, no matter how simple, makes Clojure unattractive for projects larger than "messing around in the REPL" but smaller than "modestly-sized application". | scripting | ||
| 61616607 | shell scripting | scripting | ||
| 61616793 | Language runtime bootstrapping takes way too much time, which renders the otherwise desirable scripting story impractical. | scripting | ||
| 61760357 | Lack of command-line facilities | scripting | ||
| 61817971 | Still too much accidental complexity in tooling, startup speed. I'd like to use Clojure where I use Python and that can't happen yet. | scripting | ||
| 61369825 | There is no *good* way to write a multiplatform library. In addition, clojurescript libraries are distributed as jars, which doesn't make much sense. Now that multiplatform is becoming a serious use case I think it is time to update our tooling so that it is not so coupled to the jvm. | tools | cross compilation | |
| 61353929 | Tracing/Debugging | Tools | debugger | |
| 61357779 | Debugging: in JVM version, stacktraces. Poor EMACS and NREPL integration, and some bad choices made in it. Debugging REPL entered code (no line numbers, so it's lost). Etc. I've been a Lisper since 1978 (sic); I pity those new to it trying to use Clojure on the JVM. | Tools | debugger | |
| 61357780 | better/easier debugging and profiling tools | Tools | debugger | |
| 61357840 | lack of easy runtime debug capability | Tools | debugger | |
| 61358713 | Robust tooling support like java, specially debuggers, profiling tools. | Tools | debugger | |
| 61359402 | better and easier debugging and profiling tools. | Tools | debugger | |
| 61359461 | Integrated IDE with debugging support - if only IntelliJ supported it out of the box... | Tools | debugger | |
| 61361914 | good debugger, funky error messages, slow startup | Tools | debugger | |
| 61362915 | Final closing off of tools stories: debugger from all the IDEs/Editors. The filling out of libraries like Friend so that the ecosystem has strong libraries to match the competition. | Tools | debugger | |
| 61363477 | Debugging possibilities (instead of println). Error messages. | tools | debugger | |
| 61368613 | A lack of a well tested debuggers. | tools | debugger | |
| 61380854 | It is bleeding hard to debug at times. Mostly do to lazy evaluation. | tools | debugger | |
| 61381029 | The tool set is still too adhoc and primitive: many moving pieces, little support for debugging and refactoring. | tools | debugger | |
| 61385180 | Poor debugging and general tool support will continue to hamper Clojure adoption IMO. I love emacs, but I can't limit my hiring process to users of emacs. :) | tools | debugger | |
| 61385195 | Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! | tools | debugger | |
| 61387542 | Lack of proper, approachable Clojure-specific debugger(s). A real module system. | tools | debugger | |
| 61387959 | Difficulty of debugging dense clojure code. | tools | debugger | |
| 61389398 | debugging | tools | debugger | |
| 61398265 | debugging | tools | debugger | |
| 61407425 | Poor debugging facilities | tools | debugger | |
| 61409673 | Tooling / debugging | tools | debugger | |
| 61417340 | All of these are library issues, not core language issues: 1. Tools for insight into runtime behavior are worse than primitive. Even a decent basic debugger. This is something a Lisp language is expected to do well. 2. Use as a "data science" language not as advanced as should be. Clojure is a great "data" language, so many infer that it might be a great data science (predictive modeling etc) language. Incanter is not very good, yet it's the best we have to recommend to data scientists evaluating use Clojure. There are are a number of good libraries out there but it is difficult to formulate a good case to the working data scientist (who has an R, octave, python workflow), as their excitement fades when they realize that they can't be as productive. However if they are coming from a Java/C/C++ workflow it is better than that for sure. 3. Core or library-introduced constructs for multi-node parallelism. | tools | debugger | |
| 61417476 | Tooling needs to be more robust (inspectors, debuggers) | tools | debugger | |
| 61427440 | lack of a Python pdb-esque debug repl. (debug-repl and cdt aren't nearly as useful as import pdb; pdb.set_trace()) | tools | debugger | |
| 61430676 | Development environment. No debugger (nrepl-ritz never worked), could not interrupt stuck programs in the REPL, 100+ line stack dumps on errors/compile errors, compiler errors only identified one at a time. 'lein test' is great though, really easy to write test suites, and even if the compile-test cycle gives up the power of the REPL, it's kept my sanity (and kept me from dropping the language). | tools | debugger | |
| 61438199 | debugging tools | tools | debugger | |
| 61440462 | Lack of a debugger, comprehensible error messages. | tools | debugger | |
| 61440609 | I'd say the lack of a good debugger | tools | debugger | |
| 61462436 | Debugging!!!!!!!!!!!!!!!!!! Debugging!!!!!!!!!!!!!!!!!! x10e100 To get valid breakpoints that work in the code is inconsistent between windows and linux. And if one then throws a couple of machine specific dll's into the mix a whole of of pain seems to ensue. I don't want nor need a all encompassing debugger, but I do want to be able to set/clear break points, look at local stack and local variables through a repl and have that work for both windows and linux. Yes there is ritz, but its not working my windows box at the moment. | tools | debugger | |
| 61468300 | Debugging, error messages | tools | debugger | |
| 61516306 | *Simple* debugging in Emacs please. | tools | debugger | |
| 61523910 | Code debugging, profiling and optimisation. | tools | debugger | |
| 61531345 | Better debugging tools. | tools | debugger | |
| 61594065 | Getting up and running with a debugger. | tools | debugger | |
| 61723070 | debugging system. | tools | debugger | |
| 61890259 | Lack of a good IDE / debugging support | tools | debugger | |
| 61910185 | Debugging, error messages, &c, could use a cleanup pass. | tools | debugger | |
| 62038628 | debugging | tools | debugger | |
| 62114501 | Debugging facilities seems to be limited to println. Making sense of stacktraces can be difficult. | tools | debugger | |
| 61615203 | Too complicated java-esque namespacing and dependency resolution | tools | dep mgmt | |
| 61372153 | Lack of generally accepted solutions for deploying and ensuring reliability of more complex systems. This includes configuration of component and a mechanism for packaging and running them that goes beyond lein uberjar or lein run. | tools | deployment | |
| 61446796 | Built-in ability to add new project dependencies without restarting the JVM. Warnings if there are updated versions of the dependencies available. Switching between Emacs (due to my lack of Emacs knowledge) and LightTable (due to not having all the features I require at the moment). It would be nice to have a full-featured dev environment for Clojure that matched and even succeeded Visual Studio in features. | tools | deps | |
| 61905657 | Emacs :-) | tools | Emacs | |
| 61354587 | The credo of Emacs as "the one true way". For a newcomer to the language, that's an immense cognitive load in addition to learning the language. | Tools | Emacs focus | |
| 61356468 | lack of IDE options/emacs centric community | Tools | Emacs focus | |
| 61357049 | *IDE support* Emacs is good, but it requires one to be an Emacs expert to effective. Eclipse/CCW either doesn't cut it so well, or it's not so well documented how to use it as effectively as one would in Emacs. | Tools | IDE | |
| 61358253 | ide support | Tools | IDE | |
| 61360460 | Solid IDE support, and respect for IDE users in the community | Tools | IDE | |
| 61368475 | Tooling is a barrier to entry for developers used to IntelliJ/Eclipse type IDEs. Yes there are lots of options, but none is clearly the best. | tools | IDE | |
| 61368548 | IDE on par with static-language IDEs. Lack of static typing helps Clojure be an amazing *lanuage*, but the language itself is only a part of the overall dev experience. | tools | IDE | |
| 61368897 | The only real improvement I'd like to see is a good IDE, preferably something that isn't based on Eclipse. | tools | IDE | |
| 61407218 | One major area of deficiency comes in Java interop IDE intelligence. Eclipse Java editing, for instance, provides comprehensive lists of fields/functions/methods and associated Javadoc materials as part of the code completion process on an object in the source. Opening the documentation separately becomes largely unnecessary, since the salient majority of information useful for invoking a method is accessible with a Ctrl+Space. The facilities for resolving the class of an object statically naturally make this capability more tractable to implement in Javalang than in Clojure (where type annotation is optional, and methods will be resolved by reflection if necessary), but it would be astronomically helpful to include comparable information in a code completion hotkey for annotated Java object references. I don't even know who to suggest this to, though. | tools | IDE | |
| 61436366 | Tooling/IDE Integration * symbol renaming * var extraction of inline functions * moving functions/vars to another namespace * better errors/stacktraces * test integration (e.g. junit) | tools | IDE | |
| 61437752 | Eventhrough a perfect IDE for a dynamic language seem impossible, but we really need a good enough one. I use emacs for clojure programming, but for many other coders, emacs seems hard to marster. | tools | ide | |
| 61442785 | superior IDEs | tools | IDE | |
| 61476178 | To really gain mainstream, IDE editor support must be not only better, but entirely different. LightTable address ease of use well and has great dynamic evaluation features, but it does not at all address the code maintenance the mainstream static type people are used to (which is really orthogonal to the first one). What really is missing is smart code organization and refactoring tools like e.g. Refactoring Browser in Smalltalk. While conciseness and expressiveness was appreciated by anyone I showed Clojure to, none wants to find the function definition and refactor using file search and text search/replace. Indeed, Java with Intellij/Eclipse is vastly superior in this respect and the main reason I am unable to sell Clojure to anyone in corporate env. at the moment. | tools | IDE | |
| 61524802 | Lack a good development environment, i.e. an extensible editor that's easy for beginners to pick up, easy to extend, and powerful enough to work across larger codebases, where the ability to quickly and easily locate function definitions etc is key. A decent built-in debugging tool with breakpoints and step-in/step-over/step-out would be awesome too. | tools | IDE | |
| 61609734 | Integration with modern IDE's is anemic and a joke. | tools | IDE | |
| 61614749 | Lack of IDEs with integrated debugging | tools | IDE | |
| 61619077 | The tooling is the problem. Not everyone uses terminal/emacs for programming. The integrated IDEs like LightTable free up from a need to setup everything manually - it's not open source yet, and not finished. Counterclockwise is fine but still feels fragile. | tools | IDE | |
| 61707795 | lack of first class development environment | tools | IDE | |
| 62027717 | Good integration with graphical IDEs | tools | IDE | |
| 62032117 | I love Emacs. I've been using Emacs since 1991. I can't find people who are Emacs experts who are also interesting in functional programming or know Clojure or are familiar with Java or the JVM. There needs to be a productive dev environment for Clojure that is less intimidating than CIDER/nrepl.el + Paredit. | tools | IDE | |
| 61424638 | Having a workbench for developing several projects simultaneously. But jig is a tool that's addressing that. https://github.com/juxt/jig/ | tools | large projects | |
| 61436409 | leiningen not allowing local libs :( i know thats not a clojure problem, but still... | tools | lein | |
| 62035542 | Lack of a linter | tools | lint | |
| 61354838 | Decent dev environment with refactoring. Come from Java/Eclipse background. | Tools | Refactoring | |
| 61359608 | The tooling. Clojure still lacks good IDEs that provide basic refactorings and automatic generation of namespaces/imports. | Tools | refactoring | |
| 61583670 | Difficult to do refactoring. | tools | refactoring | |
| 61848276 | Refactoring using any IDE is tough. I ran into an interop problem when using a Java library that returned instances of a private class. I had to figure out type hinting. | tools | refactoring | |
| 61361743 | lack of good REPL/slime type integration in anything but emacs, options in other editors are poor at best | Tools | REPL | |
| 61359894 | Lack of static analysis tools. | Tools | static analysis | |
| 61413968 | Windows ecosystem is second class | tools | windows | |
| 61354169 | Complexity of setting up a development environment | Tools | ||
| 61360120 | development environment documentation | Tools | ||
| 61361319 | Environment - though that it changing. I think that Scheme has done it so well with Dr Racket. We have a few of these environments that are interesting and I am hoping that the Clojure community adopts one of these as an official platform and develops it out. That would make Clojure unstoppable. | Tools | ||
| 61365288 | editors/development environment (take a look at something like DrRacket) | tools | ||
| 61367965 | Getting up and running with an editor requires far too much prior knowledge. If you're not using Emacs you feel like a second-class citizen, and getting up to speed adequately with Emacs takes far too long. I didn't want to learn about Emacs package management on day 1, but I was forced to. Coming from Vim (my preferred editor), the landscape was too variable. Vim-clojure pushed us towards Foreplay, which became Fireplace, but the functions aren't all there, and you need to install several different packages to get it to be useful. But then the packages can interfere with each other, and things can be really hard to configure to make them work. Even then, how do I find all the appropriate packages, and how do I keep versions in sync, so that they play nicely? Over time I ended with less functionality than I started with, which is why I tried Emacs. Counterclockwise looks nice, but the Eclipse system can be far too heavyweight unless you're in a large project. Emacs/Vim can both be launched quickly to inspect/modify code, but Eclipse will take a minute or more to start from scratch. Lighttable looked nice in presentations, but I've yet to get it to talk to a REPL, despite multiple attempts. Embarrassing as it is to admit, I still rely far to much on saving to disk combined with a command line REPL with copious re-use of (require ... :reload-all). Emacs/cider has allowed me to move to a more integrated system, but the learning curve to get there was more than it should have been. | tools | ||
| 61370414 | for me I still haven't figured out the right tooling. I use Eclipse + CCW, but I don't particularly love it. | tools | ||
| 61374870 | Lack of decent developer tools. | tools | ||
| 61375271 | Editors in general is something I've found to be a weakness. Especially when you want to use Clojure and Clojurescript at the same time. Switching editor is also a high cost in terms of time. | tools | ||
| 61382411 | The tooling around Clojure is ok, not great. In the long term, everyone suffers for the lack of official/sanctioned tools for setting up environments, perf testing, and code analysis. Everyone seems to have written their own Clojure parser/analyzer, with little thought to keeping such tools unified across implementations and Clojure runtimes. | tools | ||
| 61383641 | It hasn't sufficiently capitalised on the ease of real-time programming by integrating with emacs/vim as well as lisp has. Because it is JVM only it is difficult to argue for production usage where other languages will compile natively. There is also a lack of acceptance in the workplace. | tools | ||
| 61389592 | The tooling. | tools | ||
| 61391382 | Tools, and tool support for dynamic languages to match static languages | tools | ||
| 61397331 | Great tooling support. | tools | ||
| 61399032 | - no good ide - difficult to refactor - no two pass compilation (helper functions on top, real meat on bottom -- opposite of expectation) - no best practice for code layout - no clear multi-project support | tools | ||
| 61402990 | Tooling. | tools | ||
| 61408619 | I think that the editor story needs to be better. I live in the REPL as much as possible, but as a Vim user I feel like I am either limited by the tooling or just don't know how to be effective. I don't know how to reload an entire namespace into the REPL from Vim, switch namespaces without doing it wrong, etc. I Kickstarted LightTable and have tried to use that, but frankly it was too confusing last time I fired it up. Maybe we just need better documentation/walkthroughs. To be clear, I can edit-compile-run just fine, but what I like about Clojure is the interactivity and so I have high standards there. | tools | ||
| 61411313 | Development tools. Leiningen is great, and nREPL and CIDER together are a strong start; but for all the elegance Clojure has on offer, chasing down errors is still messy, with a suboptimal signal-to-noise ratio. | tools | ||
| 61412631 | Tooling compared to traditional Java | tools | ||
| 61418465 | It is way too difficult to get an easy-to-use Clojure development environment up and running. I've tried 4 or 5 of the options, and all are poorly documented and have very steep learning curves. Part of the issue is that you can't just put some code in a file and use an interpreter or compiler on it, like you can most other languages. You have to set up a project, etc., which just makes it a pain for both new users and experienced ones alike. | tools | ||
| 61419744 | The development tools are lagging behind... Not that Leiningen or emacs or ccw, etc are not good, but there's a lot of work to customize one's environment, worst in teamwork. And here again is missing documentation (well not to be searching around), not on pieces but to put the whole in a coherent state. Some libraries are lagging too or cross dependencies give difficulties. A local cache for external libraries to be able to work offline... | tools | ||
| 61425492 | Developer creature comforts. This is being largely addressed but if we really want to take over the world, we've gotta get better at this. :) | tools | ||
| 61435162 | Editors and a "series" of recommended toolchains. Even a simple comparison and contrast of 'framework X vs framework Y' especially in the Web/Clojurescript space. | tools | ||
| 61445365 | tooling | tools | ||
| 61461889 | tooling, troubleshooting headaches | tools | ||
| 61472598 | Clojure is wonderful at handling and provided ways of thinking about state in an application. This then leaves the meta-level of state accumulated in the development environment. This is being addressed somewhat by tools and best practices put forward by the community but it still seems a weakness. In general there are great resources for learning how to *program* with Clojure. There is much less with respect to learning how to *develop* with Clojure - manage projects, namespaces, documentation practices etc. This is particularly true for those coming to clojure on their own and not as part of a team or company adopting Clojure. | tools | ||
| 61487025 | Tools and/or infrastructure support for assembling & deploying anything other than toy or small programs. | tools | ||
| 61499770 | Tooling | tools | ||
| 61513289 | Tooling - no equivalent to "find references" a la Java IDEs. | tools | ||
| 61520856 | I'm interested in RAD tools. Things I can develop robust apps with efficiently. The lack of a SQL/Relational DB ORMs pains me. Coming from Python/Django it seems like a glaring omission blocking efficient app development. I've also never bonded with an IDE which gives me rich debugging tools: friendly stack traces, stepping through code, updating variables. | tools | ||
| 61525916 | It's not the easiest language to get going with. If you're already an Emacs/Vim guru, there's simple plugins to get going with. But if you're not of that type, there's no easy path in (learning Emacs as part of a new language is a non-starter for 99% of the population). | tools | ||
| 61592131 | setting up Emacs, swank, slime | tools | ||
| 61596055 | Emacs + cider/nrepl seems to be the common environment for Clojure developers. This setup is not so smooth for newbies to learn. I am optimistic about the Nightcode IDE. | tools | ||
| 61596835 | find references in a large code base | tools | ||
| 61928139 | Developer tools. General inertia about using language that looks non-C like. | tools | ||
| 61940670 | so many editors, web-frameworks/stacks | tools | ||
| 61962354 | Tooling. It's improving immensely, but most people don't want to use Eclipse (much less emacs), and the missing debugger's a show-stopper for most people I've run across who are willing to try to look past the horrible college class they took using scheme. | tools | ||
| 62117110 | Tooling. On one hand, there are superb build tools, like Leiningen. On the other, I'm still using Vim with with lackluster Clojure support and println to debug. | tools | ||
| 61360032 | Lack of good type system means less fun with monads. | Types | No monads | |
| 61355144 | Data type definitions. One has to look at the origin of the data in the call chain to be able to figure out what it actually is (e.g. what keys a map should contain). There's active effort to this direction though. | Types | ||
| 61358968 | For me it's the lack of static typing when the project becomes bigger. Always force myself to better define protocols between modules. If I don't, I'll pay for it in the long run. | Types | ||
| 61364869 | unhelpful errors or stacktraces depending of the environment (nRepl with Emacs or not etc.), dynamic typing for big projects, records and maps are similar but not identical (can lead to surprising problems) | types | ||
| 61372150 | The dynamic type system is flexible but has trade off.Some issues can't be found until application runtime.And we have to write many unit test cases for our endpoints. Clojure's source code static analyzer is not good enough,i think maybe someone could migrated findbugs in java to clojure,because clojure generates the same byte-code with java,but i am not sure it can be. | types | ||
| 61385195 | Debugging Clojure can be a pain in the ass. With its dynamic typing (which can be great) it's sometimes hard to catch subtle errors that the compiler could have avoided otherwise - at compile time. Also, the stacktraces are ugly at best. For beginners not really helpful and sometime even misleading! | types | ||
| 61419888 | Its lack of types is its strength and weakness | types | ||
| 61429073 | Parenthesis paralysis, lack of infix math notation and weak type enforcement keep it from adoption. | types | ||
| 61435245 | Official support for optional static typing. Android. | types | ||
| 61493708 | Personally, I'm a fan of type safety, which no dynamic language has. | types | ||
| 61531857 | Lack of a static type system (core.typed is a nice start but it's not quite there yet ...) | types | ||
| 61534385 | In my oppinion dynamic typing is a strength, but it also makes it hard to sell Clojure to old Java/C#/C++ programmers. | types | ||
| 61690919 | I'd like some kind of gradual typing ability. Maybe Prismatic Schema or core.typed would work for that. | types | ||
| 61826923 | Static type system, though my typical projects - mid-sized web apps - are feasible with dynamic typing. | types | ||
| 62028226 | static typing a la ML or Haskell, but I doubt that can change at this point. Typed Clojure may be nice but can't provide the same thing. | types | ||
| 62033048 | Lack of static typing. It makes it hard to understand and use 3rd party and our own APIs. And it results in bugs being introduced that would have been impossible with static type checking. | types | ||
| 62083878 | Well-defined record structures (including types and sub-structures) could help with domains dealing with complicated data models. I think Prismatic's Schema is on the right track for this, but having defined record structures in the language, and widely adopted, would eliminate a lot of the headaches of sharing complex data structures. | types |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment