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.

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)

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. 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, 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.

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.

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.

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!

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.

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.

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...

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!

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.