Linked from the full results from the 2012 State of Clojure survey.

What do you think is Clojure's most glaring weakness / blind spot / problem?

Bootstraping a working environement. But it got better with lein and ccw.

* tooling

* (lack of) lean-ness. We need stripped down jars starting as fast as java

 

Reluctance of the core to accept patches from the community. If a problem doesn't bite the people working on Datomic, it is very hard to get it fixed.

debugging.

The API documentation sometimes is a bit vague and you need to search further for examples.

An unfair characterization of being an elitist and/or hard-to-learn language.

Install process followed up by confusing error messages.

It would be nice to get rid of the need for declare, but it does tend to enforce some structure to a file, so it's not a biggie.

 

It would also be good if a circular dependency introduced by compiling from slime was an error, rather than discovering these things when we restart.

The docs, while promising, still need work. ClojureDocs.org is great but out of date. And it's really hard, when learning the language, to discover which functions/macros/patterns are available to accomplish a given algorithmic task. For now, Stack Overflow seems to be the best option.

* Frameworks and libraries are still young, many have only one maintainer and die out, others are "pre-alpha" quality. Many libraries and frameworks are VERY promising and quite usable though, and I'm sure that things will stabilise over time.

 

* I'd love to see full structural editing support in an IDE that's not Emacs+Paredit :)

 

* A decent test coverage tool

 

* an IDE with refactoring tools

Error traces are still not very friendly.

Startup time is awful. It makes me reluctant to just do something with Clojure because of the time (seconds, even tens of seconds) it will require to start Clojure up.

 

If I'm not around electric socket, I won't start 'lein cljsbuild auto' just because it drains battery too much. I guess that's the price you pay for JVM.

 

Maybe I should say 'lack of tutorials', but frankly I think it's not lack of tutorials but lack of understanding on my part - I worked too much with languages like Python and JS and my brain is shaped for their strengths, weaknesses and style of writing. I have no idea how to make switch to Clojure/functional way of thinking easier for common programmer.

 

I would love to see more support/tutorials for ClojureScript though, something like 'if you are unsure how to proceed follow our way for now' instead of 'here are your tools, do something' - it makes it harder to start with.

The choice of emacs by a lot of users, especially core users. And the way they are "religious" about it.

 

Why?

 

Because, from the outside, Clojure comes with a lot of "odd" choices:

- immutability by default

- lisp syntax

 

This is probably already too much for a bunch of people (sadly).

 

But add it to the fact that the same people that promote Clojure promote the user of emacs, and you've lost a bunch of other people, following the reasoning : I found immutability/lisp syntax odd, but maybe rational should I investigate more, but really, the same people don't even look beyond emacs, WTF?

 

Memory use, Android, limitations of JVM, stacktraces, debugger story,

The development process for core is quite weak with regard to quickly vetting, cleaning up, and merging enhancements from the community.  It's so bad that we just maintain a fork with our own enhancements applied because we'll all grow old and be programming with a strong AI to assist us before core gets around to merging this shit.

 

For example, this is going on a year old:

http://dev.clojure.org/jira/browse/CLJ-863

 

I understand the desire to move slowly and methodically for large or breaking changes, but how many <10 line patches have been rotting in jira for *years*?

 

It makes me angry enough to want to use Java.

1.2.0 vs 1.3.0 vs 1.4.0 and the associated library wrangling

Documentation of Clojure itself and many (most) libraries. clojure.org is just shame. Instead clojure/core spends a ton of time on esoteric stuff like core.unify.

The CA required even for simple contributions, I guess this prevents a few contributions to be known.

 

It is quite a lengthy/complex process compared to pull requests. I know there are copyright issues involved, and it is a protection more than anything, but I hope a better solution can be found enventually.

 

 

Bootstrapping time

Documentation and educational resources

Clojure dev process

 

At the micro level: I've had a tough time finding a local/available mentor; at the macro level: IDE support still seems tough to come by, tough to set up.

The greatest weakness is its greatest strength: Clojure is different, and for some, that presents a steep learning curve.

Less-than-perfect official website; lack of prominent Leiningen endorsement.

Selling other developers on it: Java developers perceive it as a "hipster" language and bemoan having to learn Emacs (no matter how many non-emacs toolchains there are).

 

JVM startup time makes it a tough sell to replace Ruby/Python/etc.

 

 

The only thing that comes to me off the top of my head is the lack of tooling on the ClojureCLR side. I'm sure this is directly related to the amount of people who use it.

Also its strength: it's a lisp :)

Most definitely the lack of documentation, there is enough introductory material on the subject to get started for sure. The current gap in documentation definitely lies in the "advanced" topics such as developing web applications, desktop applications, etc... using clojure.

 

An analog to O'reilly's "Building Web Applications With Erlang" would be a decent start, though amping up the community's documentation in articles and blog posts would probably do more to stimulate the community.

 

the best dev env is (was) Emacs... this was a big hurdle to get to grips and get setup... (came from java so used to fully interactive advanced IDE's)

1. While ok for many additions and non-trivial patches even simple doc fixes hang for months in the issue tracker. Yes. Clojure is a "hobby" project for all the contributors, but maybe making the last friday afternoon in the month into a "patch afternoon" to get those smaller fixes out of the queue would still be bearable. (Insert any other frequency as for feasibility)

 

2. Version locking through AOT sucks.

 

3. Produced jars may be quite large when using AOT. I'd like to have a tree shaker, which removes all functions from a namespace which are not used by the application to reduce size of the final jar.

Clojure is still new and while there is a lot of great things in the core, there's still much room for improvement. How the growth and improvement will continue in the future, is a big question to me. I'm hoping Clojure can evolve and old warts can be cleaned, so that it's not yet another bloated language and set of libraries in the future.

 

Also as a consultant, it's a tough sell. I would not hesitate to use it myself if I was paying, but since I'm working for others, I do not get to choose.

Slow multimethods in Clojure, no multimethods in ClojureScript

"I don't need to write documentation, I have docstrings!"

 

"Here's the owner's manual for your car, Jimmy, go read it and I'll take you for your driver's test in a week or so."

Clojure is said to be performing well, but there are no real hints how to achieve performance. Literature/blog posts are missing dealing with common pitfalls.

Due to the relatively small community there just isn't that much stuff to read around. It covers the basics and intermediate level, though.

Jobbing programmers aren't familiar with Lisps, and exhibit a fear of the unknown that's hard to overcome when compared to, say, Scala (which I find a thoroughly unpleasant language to work in). On the other hand, I think that being a Lisp is the best thing about Clojure.

Better debugging tools would be nice.

 

Would be useful to have toolage for any of the major IDEs approach the utility level of Emacs+SLIME+paredit-mode; they're all pretty awful in comparison, but in a Java shop, IDE usage is hard to get away from.

Sloooooow. If we could work on that, it'd be a huge win.

Adoption-wise: "Out of the box" working IDE. Getting better with CCW / lein integration.

Hard to say. I'm still in the honeymoon phase. :-)

Stack traces are horrible in both Clojure and ClojureScript. Really, we need to fix that. I shouldn't have to see errors in AFn. I should be able to get actual line numbers where the errors occur (clojure-py excels in this area).

need something like socket.js or singalr

I don't do anything big/productiony enough to have an informed opinion.  For my uses, the most annoying thing is the long JVM startup time.  The REPL is a *great* place to write small utilities, but then you can't really give them to other people to run from the command line.

Managers see it as all risk with minimal benefit.  They are scared that you will leave them with an unmaintainable blob of code.  The more public wins, the easier the story is to tell.

It's difficult to get everything setup.

 

Not so much of a problem for someone who has taken the time to learn Clojure, but more of an issue if I want to get a colleague to run a simple tool.

Departures/differences from Common Lisp.

The ecosystem - the answer the the question: which lib to use.  

contrib doesn't seem very contrib-y.

Tools.  I love emacs and have been using it for more than 20 years.  I think the emacs/clojure integration is the best option available now, but given that, developing in emacs/vim is simply not a compelling solution.  There has to a strong emphasis on productive/extensible developer environments - paredit style structural editing, clojure-specific refactors, tight repl integration, strong debugging support.  I see some of this happening now, but so far everything (including my current choice) really is hardly anything more than a toy environment.  If I wanted to spend a year customizing emacs for a perfect experience, I'm sure I'd feel relatively happy, until I moved to another project or team and those inflexible personalizations break in a new environment.

 

Stacktraces...

In my experience, t's been a tough sell to "senior architects" and VPs. The former because of their love of static types. The latter because they're afraid of languages without curly braces.

Compiler error messages.

amongst my colleagues, the most common feedback i get after demonstrating things in clojure is that lisps are "ugly" and difficult to read/follow. there is a stigma there that i think holds it back somewhat.

Development environment setup is still very complex

Debugging is even more complex

Everyone hates the ugly stack traces

While I am comfortable with the available documentation, those new to the language would benefit greatly from one centralized, up-to-date site containing both reference material as well as introductory tutorials.

Scripting because of JVM startup time.  Clojurescript hasn't made much progress here.

It's hard to manage libraries and get things going quickly. I hate having to set up projects for everything. I'd like to just have what python has in terms of global libraries.

finding out what is best practice and good libraries

Toolsupport for refactoring. As I´m not that experienced using Clojure this is more an assumption that a fact.

The dependency on Java knowledge to use Clojure effectively. I understand the power of a hosted language, but not coming from a Java background, I feel at a disadvantage with Clojure. Many examples/books just assume that you know about the data manipulation methods available from the Java-side.  Add to it (and it may just be my lack of understanding at this point), but the introspection (from the REPL) doesn't lend itself to exploring the language as well as others I've worked with.  This makes self-guided learning more challenging.

A recent trend here at work has been to replace almost every instance of multimethods with protocols, due to the runtime cost of multimethod dispatch (as evidenced by some YourKit profiling).

A standard toolchain.  You basically have to try all the libs out to figure out which suits you best atm.

Lack of optional typing

not being able to send pull requests for fixes

Probably getting good stacktraces and error messages.

Some of the documentation is terse, clojuredocs becomes the go-to source.

drawbacks on macros in comparison to common lisp

stacktraces, and the community that's cool with them being so bad.

No central place to see all the contrib libraries, also contrib libs are quite often poorly documented.

Namespaces. Everything else in Clojure is so simple, namespaces feel like a big ball of yarn and confusion.

Error reporting.

 

It's non-trivial to create a stand-alone desktop application that targets all platforms.

 

Lack of support for "live coding" i.e. concurrency semantics for namespaces, ability to easily manage executing threads from the REPL (i.e. equivalents of top and ps), sane error reporting, compiled code keeping a version of its source, etc.

Documentation, Documentation, Documentation

Android. Last time I tried to develop an android app (March 2012) I was unsatisfied with too long loading and start-up times, toolchains, REPL etc. However the situation may have changed already. I need to give it a try again

* Not easy to get started for newcomers (basic installer should come with a good REPL included)

* Runtime overhead: makes it impractical for command-line tools and constrained devices (Android)

* Confusing error messages (like, if you make a mistake on your (ns ...) macro)

* The ns/use/require/refer dance is powerful but not simple

 

Editor. Though every time counter clockwise gets another release, the world gets better.

nothing from the language, but slow startup times

Need to get day-to-day software engineers on board - the community is so talented and experienced with more advanced computer science concepts that it can be intimidating (though everyone has always been very helpful when approached)

Clojure's needs:

* A graphic design makeover for its online presence

* Tutorial-style documentation *on clojure.org*

* A *great* editor/IDE story other than Emacs

Really good "architecture" type learning materials/tutorials to help developers transition from OOP to functional programming.

Not a problem with the language per se, but I frequently have issues finding what I think I want in the documentation.  This may just be due to a lack of familiarity with the language and the docs (specifically, clojuredocs.org).

 

A useful dev environment is also a minor issue. Eclipse+Counterclockwise is great, but I find that I like the REPL in Emacs+SLIME better. And Emacs+SLIME took some effort for me to get working (again, this is no fault of Clojure).

performance

Too 'elitist' approach by key community members, and too much of 'Rich said...' without considering the reasons behind some proposals. And one implementation detail: still waiting for http://dev.clojure.org/jira/browse/CLJS-27 to fully explore different clojure backends with single codebase.

No one way to get it installed and running. Related: no scripting story.

slow start-up time

 

Clojure is fantastic and I'd like to use it for everything I do, including image analysis and numerical simulation (I originally come from a Python & C/C++ scientific world).

What I've seen so far is that there's a cap in terms of performance that is hard to overcome, and sometimes overcoming it requires a deep knowledge of what lies beneath clojure and how JVM features are used in the language.

The Stack Trace!!!!  

I think Clojure needs to learn something from Erlang, and Erlang from Clojure. I think their two concurrency models are very complementary.... maybe making Clojure target the Erlang VM can be a good approach.

clojure.org - is it even maintained? http://clojure.org/getting_started should be replaced with https://github.com/technomancy/leiningen/blob/master/README.md

The "80% problem" many of the Clojure libraries are suffering from: A lot of immature, incomplete libraries, leading to a lot of yak shaving in daily development work.

long start up time

Clojure is HARD to get started using in any serious way due to the lack of a good and easy to use IDE unless you are an Emacs user (which I am not).

 

Clooj is a start, but a great IDE - like Dr. Racket would be *so* welcome.

 

Also (and I understand that there are a lot of challenges associated with this) but getting up and running with ClojureScript is even more confusing than with Clojure. A way to incorporate Clojure and ClojreScript into a seamless environment (maybe using LightTable?) would make for such a compelling case for the use of Clojure.

Debugging and profiling in terms of Clojure code.

lack of standard interactive debugger and out of the box complete development system

Perhaps because it's so fast moving, quality and consistency of documentation, especially 3rd party libraries, is spotty. Compare w Python.

 

Also I still hate the slow start times of the JVM. And those towering stack traces.

It's not really useable on mobile platforms due to poor performance. Clojurec and gambit-clojure-c seem like good steps towards native compilation of static libraries that could be included in mobile apps.

Resistance to acknowledge defects in core Clojure.

Ramp up time. Getting started with something like ruby or python is a ton easier than with clojure. It seems to take forever to figure out how to get everything installed (and figure out what to install), what tool chain to use, etc. Not sure exactly why but that's been the hardest thing so far in my efforts to learn clojure.

Lack of perceived openness around issues and features in core

 

Clojure in clojure would help all the various implementations, both in terms of ease of implementation, but also in keeping pace with JVM clojure.

Clojure's official web presence is very poor. The clojure.org website does a good job explaining background, why Clojure exists, and works well for reference, but people who've decided to learn Clojure don't need any of that. The "Getting Started" page suggests using the laughably primitive built-in repl. Third-party documentation is out there (Volkmann's tutorial is comprehensive and approachable, and Colin Jones' tutorial on namespaces is the only coherent explanation that exists on the web), but newcomers have very little chance of finding it.

 

Clojure has a rich, vibrant, and helpful community, but clojure.org completely fails to reflect it.

Many of the community developed libraries (even those considered the best one for the task) are highly opinionated and put arbitrary limits (that are probably there because there are only few developers) to the functionality.

 

Since Clojure developers come from all kinds of different backgrounds like systems, ruby, common lisp etc. and don't have established guidelines/approaches for many domains every library has a different opinion for necessary functionality and how the API should be it can get messy. There are many established libraries out there that are designed in the creator's own black box with different paradigms, naming schemes etc. And most of the higher level abstractions out there (web frameworks like Noir for example) are build on top of its own arbitrary set of these lower level foundations.

 

I love how it is not wrapper over wrapper in Clojure and you are expected to drop down to these foundations but since there is a obvious lack of manpower behind these libraries (especially the higher level ones) they aren't very flexible. Because of their highly opinionated nature I often end up rewriting stuff to get around restrictions. Thankfully this is a natural and thing to do in Clojure and since most of these layers are so thin I believe they are result of personal needs just like mine.

 

The problem is as the codebase keeps grows it becomes hard to figure out where things are implemented and if they aren't implemented where should I put them. Often I need to search in 5 different API documentations to find the functionality I want and use functions from all kinds of places in the same namespace/file/even a function. This constant searching becomes quite tiring as all these APIs are designed with different mindset and it is impossible to guess how the function I'm searching for is named. Some are using very abstract terms, some are named by implementation details, and some are Java functions with crazy naming schemes so often I give up and reimplement the wheel.

 

I don't know how this problem can be solved without building big frameworks like RoR or grand architectures, therefore losing the properties that make Clojure the Clojure we love, and I'm sure I could've said all those in fewer sentences but I guess I needed to get this one out.

Java and OOP's domination of University curricula and the unfair stillment of fear of lisp again due to academic shortsightedness.

 

Pointy-haired bosses that still think Java/C++/C# are sexy.

 

After you've seen Paris (Lisp/Clojure), it's exceedingly difficult to go back to the farm (Java, C++, C#). But, unfortunately pointy-haired bosses have the driver seat.

Exceptions, debugging, SLIME integration (or at least something comparable). I waste time trying to track down bugs without any help from the environment. SBCL/SLIME is fantastic at issuing warnings and errors immediately when you compile an expression; the stacktraces are clear and include the values that each function was called with; and the SLIME inspector lets you navigate through the runtime to view values and remove artifacts.

 

As for exceptions, I have yet to understand why they are have such low importance in Clojure.

Lack of documentation with examples for contrib libraries.

For my use cases (bunch of projects with backends written in C/Erlang) JVM becomes noticeable drawback.

Lack of credibility/familiarity in the eyes of other stakeholders (r&d managers, architects)

The same as once of its greatest strengths. The nature of the community is highly diverse, and the ruby aesthetic is very different from the common lisp aesthetic, which results in emergent idioms. This is good when you want flexibility; bad when you want understandability. This has resulted in a large community emphasis on the value of simplicity, but the presence of multimethods, protocols, macros, etc. mean you sometimes end up fighting the language to provide simplicity.

Lack of input from Rich Hickey on future plans for Clojure, the glacial pace of core development and bug fixes. Perceived oligarchy of Relevance Inc with regard to Clojure direction and development.

It's not easy to just dive right into a project. Getting into the zone takes a while, due to library setup issues, using your own libraries from other of your own libraries in a development environment (because I don't want to rebuild a jar every time I make a change to a dependency), and installation issues (installing immutant and torquebox together is a major pain in the rear). Library management should be as simple as using rubygems and bundler in a Ruby setting. Leiningen is a big step in the right direction, but it's still not all the way there.

Standard library is quite small, and there is over-reliance on interop.

All documentation / libraries assume you already know a Lisp. Just yesterday, I was told that I'll need to learn Prolog before I can understand core.logic!

Canonical documentation for transient features of the core language (e.g. ns forms) even after cutting a stable release seem to be difficult to follow without combing the dev mailing list.

Documentation, and particularly documentation to get non-LISP programmers started with the language, stuff that would get the average C#/Java industry interested in the language.

the startup time, again.

When it comes to native libraries it is unclear how to distribute well.

Also, the lein-git integration story should become better / more documented. The whole local-repository / git-repository / native libraries as dependencies should get better support and documentation, it bites me again and again.

There are many great ideas at a course grained level, but there are lots of little rough spots. Some smoothing and polishing would be nice, but it tends to be difficult/not worth the effort to try to get a small bug fix or documentation change pushed through the "process."

1. The clojure.org website :-(

2. Discoverability of libraries for various purposes

3. Clojure error messages

4. Comprehensive documentation of Clojure libraries

5. Clojure tooling needs to improve (e.g. Pallet should be more approachable and easier to get started with)

6. Open Source examples of non-trivial web applications written in Clojure

It's still less approachable than Ruby from almost every angle - initial setup, syntax, readability, size/engagement of community. The language/community actually has pretty good answers for all of this, but we need to get that out there in a way that helps people understand why Clojure is worth investing some brain energy into. I can't shake the feeling that we need a _why to bring some chunky bacon: explain Clojure in broadly appealing terms that entices new users to dig in deeper after the Real Meaty Goodness.

 

Obviously Ruby isn't the be-all-end-all standard for comparison, but they have built a huge, engaged community, so if Clojure would like to do that it'd not a bad example to follow.

No commercial backing up

Lot of old documentation that makes difficult to find the relevant things.

Stacktraces/namespaces/lack of idiomatic clojure libs (needing to use java).

(although all of this has been getting better).

I feel the core documentation could use examples, or perhaps just slightly longer winded descriptions.

Compile errors that don't tell you where the compile error is.

A small pet peeve is that clojure.core seems to be getting a little bloated, like cl-user in common lisp.

- Startup time

- Uses outside the JVM universe (Games, Visual Effects Pipelines)

(I've a bit interested in Bridj to see about closing gaps)

No consistent function naming scheme / not self explanatory

Core documentation

Tossup between lack of good example documentation build-in to the system and difficulty finding which function does exactly what you want (which ties back into documentation)

Some of the guys I currently work with can't seem to grasp Ant, and don't mind writing pages upon pages of boilerplate, so I'm working it in in little pieces at work.

 

Even guys who wrote Haskell in college and read raw FIX stream still scream "WTF!?!? PARENS ARE HARD". Luckily, I can explain Clojureish things in Ruby and they appreciate it (and start adopting that style in Ruby).

Just as with other popular languages (Ruby and Python come to mind), the tendency to create multiple, disjunct partial solutions which all solve a very similar problem. Call it the 'fork' vs 'join' problem. It was heartening when Leiningen and Cake actually merged, the whole community gained. However, the proliferation of half-complete solutions continues a pace in too many other areas.While it's great that we have more conferences, we'd all benefit if every conference resulted in an announcement similar to Cake-Leiningen. And kudos to those guys for showing how it should be done.

Polish and attention to detail at a "project" level.  In introducing my co-workers to Clojure, I've found the following two things to be biggest stumbling blocks:

 

- Difficult-to-follow error messages in difficult-to-follow stack traces. After a bit of experience it's pretty easy to tease out the issue in most cases. But the newcomer is presented with a completely impenetrable wall of text whenever they make a mistake. This can be intensely frustrating.

 

- Well-presented and maintained central documentation resources. The clojure.org web site is far inferior to e.g. python.org or ruby-lang.org. There's lots of useful information there, but the wrong stuff is front-and-center, reference to e.g. leiningen is entirely missing, and the reference documentation is not attractively presented. Community web sites like clojuredocs.org work around this, but also feel like just that: workarounds for something which is broken about how the central resources are managed.

There are not too many libraries and using Java libs all the time is not the point.

Debugging, interpreting stack traces, etc is worse than any other language I use regularly.

Getting started!!!

 

I tried many times spending countless hours trying all different approaches to setup a workable environment with sublime/intellij/counterclockwise/etc in windows/linux/osx over the course of several years, and eventually realized there just was no other path but emacs. It was oh so very, very difficult to get to a basic workable emacs config setup and learn enough emacs skills to actually begin working with clojure in a productive fashion. I forced myself to focus on only that for several weeks earlier this year. That said, after going through that pain, emacs/paredit/slime/clojure-jack-in/lein, it's great. I am really greatfull to all the work done by others and hope to contribute what I can back to the community.

 

Hopefully LightTable will make the getting started process easier.

Runtime performance

Getting up and running! Leiningen is helpful, but it needs to be simpler.

Common practices and patterns may be needed when it comes to more advanced usage of e.g. protocols, multimethods, macros vs. thread-locals, etc. I'm unsure of how choices here affect the overall architecture. That seems to defeat the "simple is better than complex" idiom. (But I have barely dipped my toes in those waters really, so my worries may be dispersed if I just learn more.)

There's something unappealing about Lein, though it's got a great guy behind it and lots of effort put into it.  Maybe the maven-ish roots of it are off-putting (my prejudice, not clojure's problem). So either go all out and have Lein be the entry path to beginners, or else do something less, maven... It's an extra hurdle for people to 'install' clojure or start new projects with "this lein lien thing, whatever. how do you say it?" ;-)  let's make it dead simple for beginners to try it.  there's enough high class comp sci shtuff to learn once somebody gets used to the basics. Make that stuff easy so they can get to the important stuff sooner...

Documentation and example projects for people looking around after learning the basics and saying now what? I think projects like noir and overtone help in this regard.

biggest problem: (unfounded) negative community perception and reputation of Lisp

Documentation/blogs on the web about Clojure and Clojure libraries that are out-of-date and don't work with the latest stable version of Clojure.

 

 

Adding/commenting on/attaching patches to issues in the Clojure issue tracker sometimes feels like redirecting to /dev/null, i.e., nobody (except for Andy Fingerhut!) seems to care.  It would be very motivating for contributors to get on-time feedback, even if it's "No, rejected, bad idea, because of..." or "I have to think about this a bit more".

 

I'm speaking only of CLJ. At least by judging from the JIRA activity stream, the situation is much better for CLJS because David Nolen works for a good dozen of people. :-)

Paradigm overload: Functional programming is a big step for a lot of newcomers. Lisp is another big step. The recent emphasis on declarative programming has been really interesting to me, but I worry that we're scaring newcomers.

I think powerful tooling is a big issue. Debugging being the #1 thing.  Clojure being a Lisp should have debugging on the level of a Smalltalk or a Lisp Machine.  It does not.  There is no 'trace' to speak of, certainly no 'step' functionality.  Also the ability for a programmer to load in his system and then have a visual representation of the namespaces etc. There is a lot of work that can be done to make this better as well.  

I find that it is hard to name temporary variables because a lot of the names that I customarily use are already taken commonly used functions in Clojure. For example, str, num, list, val, min, max, count, key, val, ... It's just a minor annoyance really but catches me surprisingly often because it forces me to stop and think about names for trivial intermediate values.

It's hard to move from a full IDE like Eclipse to a text editor. I miss having an IDE that runs my tests with a keystroke (Ctrl+Alt+F, T), or looks up code with another (F3). I'm sure it's possible to have as rich of an experience developing Clojure, and I would love to see screencasts to learn how.

The patch submitting / approval process.

The installation and compilation process. Trying to learn SLIME or something similar to ease the development process is difficult for those new to LISPs. Clojure should adopt a tool like Leiningen and label it as an official tool, so that new users can build and deploy projects without fiddling around with classpath nonsense on the command line.

Debugging, despite improvements such as CDT being included in swank-clojure. Oh, and the good old stack traces, of course :)

I'd like to be able to use defrecords across namespaces without using a hack.

Lack of decent android suport, especially startup time.

everything else rocks :-)

While the java interop is useful at times, I feel like it pollutes things a bit and would prefer turtles all the way down.

The best environment for Clojure at the moment is Emacs, and I still haven't figured out how to get paredit recognizing vector literals in the repl. I'm an artist and designer, and my similarly-occupied friends all want to get into Clojure, but they leave as soon as I tell them to remap their keyboard for ergonomic emacs bindings. To learn a really nice, friendly Lisp like Clojure, you have to first learn some gnarly elisp. Counterclockwise is good – that's how I got started – but people in the art and design community are frustrated with Eclipse as well (the cursor must blink, no native support for light-on-dark text, etc). Sublime Text is bare-bones and doesn't have very good repl support. Tough sell, just because of the tools. It's really a pity, because in many ways Clojure is the best art and design technology out there. Most A&D tools aren't programming languages, of course, but a lot of that is the total unsuitability of mainstream languages to the artistic process. For visualization, nothing's better than Clojure, even if it's shackled at the moment to Java's graphics facilities.

As soon as the development tools sort themselves out and we get some C interop, the creative coding community is going to be all over Clojure. Learning the language is relatively painless, for all its functional-persistent-concurrent-homoiconic exotica, and the experience of doing creative work in Clojure is infinitely better than that of doing creative work in static C languages, the current default. But very few artists can afford to get into it right now.

Not very useful stacktraces.

lack of a more extensive standard library (when compared to python)

unofficial async programming facade.

 

to some extent, the lack of well accepted project layouts can lead to messy code (case in point: most noir apps around)

It's really hard to point new Clojure devs to online "practical advice." Especially for those new to the JVM, common stumbling blocks are...

* Deployment

* Resolving package differences

* use/require/ns

* Most anything with lein2

IDEs / debuggers / tooling

While not terrible by open-source standards, the tooling for Clojure lags so far behind that for Java that it becomes almost impossible to convince colleagues to take it seriously.

Startup Time

Two: general documentation (and the resistance by people in the community to admit it's hugely inferior to, say, Python's), and the aforementioned stack traces from hell.

stack traces

Documentation has been improved, but could be better

The hubris it's champions have about functional programming.

packaging/module system of Clojure. When to use :use or :require.

People love to attach Clojure in terms of benchmarks.  Some of which is JVM startup time.  I don't think that relevant data has been presented in terms of quick run-time or development-time (this one is likely more subjective).  In many videos/books, it is stated as being as fast (or faster) than Java.  I would love to see use-cases where Clojure is not only bringing a satisfying development experience, but better performance.

If this data exists, then I believe it is not well evangelized for the proper use cases.

A decent condition/restart system (like Common Lisp's one) would be much appreciated. Error messages are not so bad themselves, but the Javish way to handle them is a burden.

Too many different concepts (a lot of stuff from CL, a lot of stuff due to JVM integration) in a single language some of which don't even work together well (take dynamic bindings + lazy evaluation: http://s-expressions.com/2009/02/27/clojure-understanding-dynamic-vars-and-laziness/).

This is where Scheme feels a lot better. The fewer concepts a language has, the SIMPLER it is :).

The perceived difficulty of getting started with it

Widespread mis-understanding and stereotyping of LISPs

It's just so different than the other languages I'm familiar with:  Scala, Haskell, Ruby, Python, Obj-C.  I don't see the beauty of it.  It just seems like another way to do what I want.

The large number of people who will dismiss it without even trying it or learning anything about it just because they have some malformed opinion about lisp or something that happened to them in college long ago.

beginner friendliness  (for adoption)

Vague/misleading error messages.

Most open-source Clojure libraries are buggy and poorly designed, especially when compared with Clojure itself. At best, they ignore too many important details and edge cases. At worst, they are built around assumptions that are fundamentally limiting. This is true of both clojure-contrib and third-party libraries.

 

Too many libraries gained widespread adoption and momentum by being first. Now people are building other libraries on top of those early mistakes, making it much harder to escape the underlying design flaws.

 

To make matters worse, library documentation is weak or nonexistent.

From everything I read, cloujure requires a better class of developer and getting new high quality engineering talent is very difficult. I'm hesitant to run off and implement too much with clojure for this reason. I don't want to be stuck supporting the entire system forever.

 

I think this is more a commentary on the state of CS and the engineering discipline in the US more than anything.

Bus count.

 

Core isnt responsive enough to community, lots of patches languish.

 

Theres plenty of issues where the community wants to contribute to fundamental improvements like CinC but needs to know constraints/parameters of investigation, desired directions and the information isnt forthcoming from core.

 

OSGi integration. Key for java enterprise shops these days.

 

Github. Theres no communtiy with Github projects because of lack of mailing lists and forums. Key clojure projects outside of contrib need to be promoted to some sort of ClojureForge.

 

 

Horrible horrible error reporting. Subpar. Most of the time the information provided is close to useless. Sorry, the language is great, but this bugs me a lot and slows me down quite a bit.

Startup time and JVM memory consumption.

Unreadable Backtraces

Honestly cannot think of any.

Jvm, lack of hype factor

startup time

Clojure has a lot of large problems, in a way that pointing to one as "the largest" contains little information because they are all so similarly large. Nonetheless, I think most of those problems stem from the same root problem.

 

Clojure as a project is, for the average *production commercial* user, about as responsive as if it was unmaintained. The leadership is unresponsive to problems people have, rarely engages in discussions about how to improve Clojure with the people who want to do the work, and controls development so tightly that non-inner-circle coders cannot get their issues resolved in a timely manner. It proudly boasts that it "doesn't owe anyone anything" is its community principle. At the same time, the top maintainers appear to have moved on to other commercial projects, so the few changes that do happen appear mainly to cater to their own needs. At the last Conj Rich Hickey stood up and described a number of things that could be next for Clojure. It seems clear that come his next Conj keynote, the only one that will have seen any serious work is the extensible reader. Github's code graph quantifies this: https://github.com/clojure/clojure/graphs/code-frequency As 2012 looks on track to come in far below 2011's already slow pace of development, it seems worthwhile to ask ourselves, are we there yet?

 

Once you understand this situation, the state of the rest of Clojure seems an obvious consequence. All of the commercial users of Clojure I know have given up and run their own private forks with the bug fixes and improvements they need. The attitude among most of the Clojure coders I know is that it is not even worth trying to get an improvement to Clojure through the red tape. Clojure is splintering into an increasing number of independent, incomplete, and incompatible implementations as people try to get it onto other platforms without the benefit of CinC. And really, given the mismatch in between user excitement and actual pace of improvement, these other implementations point to the future of Clojure as another messy lisp with many incomplete, incompatible implementations that was overtaken in short order by other languages that could learn from its successes and then execute better.

Acceptance by customers and programmers

The syntax and semantics of :use :require :import etc

The community is at a stage of quite intense self-congratulating. Although it is great that people are polite and civil, there is a risk that the level of politeness will lead to stagnation.

 

Most of the talks/blog post/etc. rave about how great clojure is, and how much better it is than anything else (one presentation started with _the premise_ that clojure was the best tool in the world for managing risk). Relatively few, however, talk about the shortcomings of it. It is wonderful that people are so enthusiastic about the language, and anything built in it, but until we start to talk about the shortcomings, they are unlikely to get solved.

 

There is also the risk that, if the community retains its level of introspection, it will not learn from advances made in other language communities.

Startup time for scripting tasks

Namespace imports/uses, and

Debugging Stacktraces

No easy to use debugging tooling.

clojure.org does a bad job bootstrapping new users. googling leads to out of date information.

 

Error messages are a disaster.

 

 

dont feel like I know the language well enough to comment on this, but perhaps refer to my response in general comments...

Performance for numeric processing, although this is true for anything on the JVM so is not Clojure specific.

I still think that development tools still have a way to go.

Business community fear of the learning curve, especially for support / handover to future teams

The fact that it is a lisp is a big barrier to entry for a lot of people that I've tried to evangelize. Also, the fact that most of the power clojure people use emacs (and vi to a lesser extent) keeps a lot of people away. I don't know if this is a problem or weakness; perhaps it is a strength, but I think it hurts adoption.

1. not having an intuitive tracer/debugging functionality

2. namespaces. are a kind of incidental complexity

3. macro abuse

The long hard road to adoption by the industry at large, and subsequent uncertainty around future career prospects.

Great support in IDEs:

* Eclipse is heading in a great direction thanks to CounterClockwise.

* IntelliJ seems to be lagging quite a lot with La Clojure.

* Emacs+SLIME is excellent but most people scorn at Emacs.

Who knows, may Light Table help people forget about all this?

Splintering of Clojure contrib. SLIME needs a lot of tweaking depending on the version.

Keeping slime talking with both clojure and common lisp has been a running source of frustration.  

Stack traces!

The books on Clojure are too narrowly focused. There's just not that much difference between them. There's no Land of Lisp for Clojure. No Learn You Clojure for Great Good. Kids can't get into it.

- not good enough performance

- performance drop in 1.4 compared to 1.3

- absence of jobs in Europe

- Clojure feels "alien" to current Java world developer and even more alien to small to big enterprise companies (they call it "exotic" language)

- absence of killer app showcases that can improve the "alien" thing

- absence of "look-ahead" declaration usage: if there is a file say "myprog.clj", there is a need to declare all functions before using them in "main" function. It is more convenient to have these functions in the end, while "main" function goes first

- confusing behavior of "conj" that changes behavior depending on input data type and minor confusing things at library level

Emacs/SLIME seems to be the most well supported toolset for clojure, yet it is very poor at debugging. I have not been able to find a good debugging tool for Clojure yet.

The tools/debugging experience (yes, still). It's come a very long way, but it still the least fun part of developing in Clojure. Huge wins like the REPL, immutability, and expressiveness often feel offset by the pain of digging around in stack traces when something goes wrong.

JVM IO performance, memory inefficiency of strings.

TargetIng mobile development

App init time

 

Enterprise-level concurrency framework like Akka. Clojure's threading and multi-proc support is good but it doesn't have the powerful and straightforward features of Akka.

Yet to reach critical mass whereby people seek to use it for everyday problems.

Language is still evolving so quickly that libraries I rely on cannot seem to keep up.

Lack of up-to-date information for newbies. While the Clojure community is very welcoming and helpful, there is sense of an implicit assumption that you will already be familiar with emacs and that whole world, whereas many of us come from completely different backgrounds. Tutorials on the web are increasingly outdated, and the whole business of getting Leiningen and everything installed and running is painful at times, not really Clojure's fault, more Maven ("Could not find artifact xxxxxx in central (http://repo1.maven.org/maven2)"). I've adapted, but I have colleagues from the Microsoft world who would use it if it ran easily in Visual Studio for instance, but there's hardly any info about how to do that.

Lack of fast native matrix & vector manipulation is a bummer. Why can't Clojure natively represent data structures like matricies efficiently and allow fast math operations on them ? Why does Incanter default to Java for this ?

Then there's the problem of knowing what the trade-offs are between using different data structures and functions. The doco is very terse. I think every function should include at least one example of its use and a hint as to the order of the algorithm (space/time complexity etc).

Finally I'd say it's amazing that the default mode of editing code in Clojure is to use a text-editor. Surely the first environment you see when you run Clojure should be a *functional* code editor, i.e. one that works by passing expressions through functions, transforming them into new ones. It should be written in Clojure and be a standard repl/editor/ide. More like Smalltalk - an integrated system which is self-hosting, not dependent on all kinds of ad-hoc external bits and pieces.

That said, I love Clojure and I'm loving learning it :)

Complexity arising from Java interop (Classes vs Record vs Protocol, etc)

 

Complex namespace import and usage mechanism (Although thank God it's still simpler than Scala's.)

 

Lots of 3rd party clojure libraries are broken on Clojure 1.3

Compiler error messages are extremely poor (sometimes I got stack trace from compiler)

Stack trace is useless in lambda functions (fn_12345 ?)

:use :require :import syntax and error messages are very confusing

Clojure should provide enough meta info that allows me to covert an AST back to source code, It's 2012, and we are still storing programs as text files?.

 

This is probably more a strength of the language expressed as a weakness, but there isn't one "right-and-obvious" way to do something (say, build a website, or a blog), so as a beginner, my confidence takes a bit of a hit because I'm constantly wondering if the way I'm going about my project is "correct".

 

 

I think probably it's the libraries and working out what the best way of doing a particular task is.  That can be v.annoying.

I'm new so...

 

Scattered libraries that are a bit hard to approach (what should I use for X? is it well maintained..?) Cute names for every project.

 

JVM startup time

 

Lisp-ish (non)syntax will always be a barrier for some

 

Emacs for new users is a heavy load

startup time, both on desktop and Android

to be a little unfair, i would say no tco

i'm too confused with the change to contrib, so i keep going back clojure 1.2

The center of gravity for the core Clojure community is on the East Coast

This is not a Clojure problem, but rather one of the tools around it. I have two main complaints:

1. The version of SLIME favored by Clojure advocates is not only years out of date, it still lags behind the mainline SLIME in terms of features and behavior available with Common Lisp, such as "presentations" in the REPL.

 

2. Leiningen is acceptable, but it doesn't acknowledge Ivy as an alternate dependency manager to Maven. My company uses Ivy exclusively, and any build tool that can't understand how to resolve Ivy-hosted artifacts will not be accepted.

 

In general, while Clojure's interoperability with Java works nicely at the code level, it it still very difficult to figure out how to integrate Clojure into a larger Java project (embedding it). I've seen some Maven recipes for this, but they all look to be experimental.

Startup time?

It seems to me that there are not yet enough "killer libs" -- by that I mean, exemplary Clojure libraries of a kind that LOTS of programmers would tend to need.  One exception is web servers; Ring and friends seem to get decent press and there's healthy library growth there.  But beyond that, I'm not seeing a lot of action.  We need to find some more domains where Clojure really shines, and focus on creating a killer library in those domains that will cause programmers to try Clojure just because they want to use that awesome library.  And then do a great job of publicizing -- that is, documenting.

Clojure's biggest problem is one of perception: shops that are amenable to Lisp aren't going to like the fact that Clojure is a lisp-1 with oddball, Java-y limitations and syntax (no tail call optimization, no continuations etc.,) and Java shops (even ones like mine that dabble in languages built on Java,) are going to throw up their hands at the mention of Lisp; the only solution to these problems is the continued growth of the Clojure community.

The language is elegant and has an endless flow of interesting ideas and projects; however, nobody seems to care to make this easy to deploy and install, most especially that you could have a "batteries included" thing like Ruby or Python or Per.  For this reason, and despite the unbelieveable amount of awesomeness in it, it is unlikely to become truly mainstream beyond a small/medium community of diehard users.

 

Also, while Clojure is pushing the envelope in several dimensions, there are some rather odd idiosyncracies that one must still learn through osmosis in the community. The are several books, and they're great, but I feel they don't take away the learning curve. Clojure has a learning curve steeper than most people will bother with, and therefore is unlikely to ever grow to be as widespread as Python or Ruby.

 

Setup tutorial lacking for beginners, eg how to use with lein. An officially supported IDE like idle-for-python would be nice, including an easy system for downloading libraries through the IDE.

Adopting it has been a little difficult. It hard to switch from an imperative background to this functional and lisp like language. I'm not sure what the best solution is here. Maybe a book for clojure like Eloquent Ruby. What does idiomatic clojure look like?

I still feel that ideas around the language itself is complex to approach to if coming from more popular languages such as Python and Ruby. Some functional ideas are presented to new users in more familiar terms.

 

I also think that, while the clojure.org homepage has a lot of material, it could be revamped to be more accesible to newcomers.

 

Also, the Clojure Documentation wiki (http://dev.clojure.org/display/doc/Home) should be easier to find in the Clojure.org homepage

I can't see any at the moment.

Enterprise Java positioning, i.e. how can people using Java (and Spring, and the like) use Clojure today?  There's a lot of positioning of Clojure ot the Python/Ruby community, but not a lot to the Java community.

Lack of simple deployment for web apps on aws. Heroku and gae are simple but, even with lein-beanstalk, ec2 stack with sessions etc is too hard.

Weak conditional compilation and no easy way to reuse libs between impls (Clojure, ClojureScript, etc.)

JVM startup time, which is, of course, not wholly Clojure's fault.

The Clojure.core folks may well have good reasons for not putting much effort into the CLR version and associated libraries, but since my work is primarily in C# this reduces Clojure's usefulness to me.  Nevertheless, I've always liked Lisp and it's nice to have one that feels modern.

That its not easy :) but rather simple

Cumbersome devel process -- especially for a beginner. It seems to take a _lot_ of fussing to do simple things.

Libraries and toolchains still need better documentation and tutorials. There are still a few missing pieces in given stacks (e.g. web stack). Progress is being made here though.

web development, I prefer Erlang...

Startup times. Preaching from community leaders.

There are at least two very different paradigm switches: functional programming and lisp.  I think this is the obvious hurdle to overcome for more widespread adoption.  The 'typical' organization that has already adopted other languages/platforms/etc., will likely resist such switches.

Making things easy / approachable for newcomers to the language. If you are from a Java background, emacs is terrifying. If you are from a non-Java background, fiddling with the classpath is terrifying. Clojure needs a really good "out of the box" experience.

* The lack of good error reporting. Even though you get used to the stack traces after a while, it never gets efficient to find the actual problem in all that noise.

* I wish Clojure had a culture for *useful* documentation. To be fair, there is only one language community where I have seen this: Python.

Dynamic Typing. While it is fantastic to mix types in maps and vectors, it would be great if Clojure was like Haskell and had type inference for speed. Optimizing code by adding type hints just seems wrong somehow...

Lack of a framework like Akka.

I haven't come across any literature which helps understand how to program without OOP. For example, how would an existing OO codebase be translated into idiomatic Clojure showcasing multimethods and friends. That would be one hell of a topic for a screencast or a talk.

the repl never works well by default---i spent hours trying to set it up properly in bash and might have given up on clojure altogether had i not found "lein repl".  the default installation is poor when you want to get it working quickly.

As someone just learning Clojure, the lack of books and other resources geared towards beginners has proven to be a hurdle to using Clojure more.

The general belief of java/scala developers that you cannot build robust systems in a language without static type checking.

No centralized source of information for non-core stuff, i.e. libraries (like a Clojure Wiki)

It feels like it is too easy writing programs with sub-optimal performance.

I'm working with iOS development in my professional life, and I can't use Clojure for that, partially because it's not targeted at the platform, partly because my co-workers don't know how to program Clojure and aren't interested in learning to do so. In general, I think the "co-workers don't want to learn" is a major problem of Clojure in bigger companies.

The initial learning curve

1.Startup a clojure process is so slow that it could not be used to develop a script/command line app.I hope it will improve this in future.

 

2.If clojure can support actor or coroutine in future,it would be great.A choice is kilim?

 

A lot of the online material is out of date. This makes it hard for newbies to get started.

Current/up-to-date means to get started into the language.

 

The assumption that people already have programming and/or linux experience in those they approach.

 

I'm self taught at relational database design who's first and, up to recently, only exposure to real programming was stumbling through trying to piece together a database front end using non-traditional database interfacing in visual studio.

 

I am drawn to clojure (as well as datomic) for what they are in their current and up to date condition, yet to get just the environment set up while coming from almost no linux or other programming experience has been a nightmare. If it wasn't for the great promise of the simplicity and power of clojure I would have threw in the towel long ago. But the very project I want to complete would be uniquely and greatly advantaged by my doing it via clojure and datomic, so I slog on. It's just an insanely steep learning curve for myself.

stack traces can often be really hard to interpret

it made me dislike, dare I say hate,  Java!!!

the core libraries dont do enough, clojure contrib is confusing to use unless you just let a build tool handle it

Stack traces are agony

Build tools "set your hair on fire"

Very hard to get a working IDE setup

Want to download a jar a use it easily and not have maven/lein try to enforce something else on me.

It advertises with its paralleliation abilities but (as of now) has only rudimentary built-in functions or macros for executing parallel computations (pmap & co).

That might change with the reducers library.

 

Unreadable unhelpful stacktraces

That it's only little known compared to other great languages like Ruby/Python...

- a little helping stack-traces

- poor integration with some frameworks (UI: jsf, rich-faces, gwt, DB: jpa, hibernate) or missing analogous ones in Clojure

Don't have any idea, probably I'm not experienced enough in Clojure to think of it's weak spots.

Lisp legacy puts people off.

Needs to have a comprehensive enterprise-like solution to get the mainstream onboard.

A coherent "official" documentation. There are very nice articles on several core features, and great libreries, but it s all a bit chaotic. Much documentation is "deprecated" from new Clojure versions point of view (ie: not enough stuff about deftypes and defrecords).

 

I know it s not an easy problem of course, due to the fact that Clojure is still growing and solidifying.

Android. Last time I tried to develop an android app (March 2012) I was unsatisfied with too long loading and start-up times, toolchains, REPL etc. However the situation may have changed already. I need to give it a try again

Requiring non-Java people to know about the Java standard library.

Command Line Apps most likely due to JVM. Hence why I am quite intrigued by clojure-py and clojurec.

Accessible tooling for debugging

The barrier to entry into Clojure for most non Alpha Geeks is the transition into functional programming, non-imperative programming and the theories behind them. There is a large hump to get over the concerns of coming to a complex issue how can I resolve in an environment that I don't fully understand.

Start time

(1)

Start up time renders it more or less useless for writing command line scripts in it. Would it be possible to bundle (and deeply integrate!) Nailgun or an alternative implementation with Clojure so it really has "batteries included"?

(2)

The bus number problematic: just one (brilliant) "lead developer".

A compelling and easy way to build small and fast Android and IOS applications.

 

Still the toolchain: no one standard environment (actually emacs is, which I love, but is hard to recommend to others a lot of the time), primitive debugging (need tracing!).

The community is too much focused on web development, leaving other potentially viral areas (command line, mobile) not sufficiently explored.

 

Precise performance reports are also required for it to be seriously taken into consideration.

No builtin app/exe deployment (a jar is _not_ an end-user option).

Editors.

 

La Clojure is workable but suffers from many minor annoyances and the heavy weight parent IDE. Ditto for Eclipse and Counterclockwise.

 

VimClojure + nailgun almost works, but suffers from bad defaults and having to manually run lein vimclojure before each session. It could at least stop displaying the warning whenever you open a .clj file without a nailgun server running.

 

Swank-clojure only supports two year old version of slime. It was a mistake to stop following slime. Life gets really hard when you also want to develop in Common Lisp and Scheme. Emacs has a terrible learning curve, but it seems most of the community has rallied behind it and pretty much everyone assumes you're using emacs.

Hard to say. It is what it says it is: a modern LISP targetting the JVM

alienating syntax, but it's also a strong feature to those who get over it.

Lack of idiomatic libraries/frameworks with approachable documentation.

Lack of Android/iOS targets

clojure's ugly stack trace is usually hard to read.

 

I would like to have official bundle of Clojure stuff by a reputable company that includes the build system, relevant libraries, and Eclipse plugins.  I need to approve each library individually now, and I want an all-in-one package with a company name attached.

aot, tooling

too slow -- awkward to use -- I am generally not a fan.

The best code tool (Emacs+Slime, in my eyes) is not used by many developers, and makes it difficult to get started with Clojure.

Documentation

The power of having one framework where everything is coming together (best practises, community), this is also a strength...

Clojure's instructional materials need to go beyond math problems, and also include real-world production problems. The immutability, polymorphism, multimethods, and so on are great, but how do you take on a problem you can solve in a flash, say, in Python or Informix 4GL/C?

 

In addition, there should be stepwise refinement in teaching concepts, like vectors and indexes, then taking the instruction a step further to see here is why indexes are not as useful, as using maps. You should not only stress laziness, but explain where recursion can be used and why, rather than just saying it is low level, and leave it at that.

 

The incredible libraries and innovative projects from the Clojure community are one of the most exciting things about working in Clojure. However, you need to be deeply embedded to learn about projects and can often find yourself completely missing great projects that you are half-heartedly re-implementing based on ignorance. Projects like ClojureWerkz are a great step towards improving this.

Needs to support OSGi / be available as an OSGi bundle.

Needs more users to get more users.  The suits worry that adopting it will cause problems when trying to hire new developers, which is hard enough these days when only looking for Java skill-sets.

No flagship killer app to sell people on. A clojure equivalent of AKKA , Rails , Django etc.

 

Lack of good error messages making the language unsuitable for most programmers

Barrier to initial entry is still quite high for migrating developers, mainly in terms of the install process and the ease of setting up and using a familiar IDE.

Although the main Clojure website (clojure.org) does an excellent job of explaining various language features and the overall rationale behind the language's development, it fails to provide a step-by-step installation path from zero to program. A great deal of information is available in sections of the wiki, but unless one thinks to follow the small link in the upper right side of the page, it is never reached. I suspect this one thing stops more people from trying out Clojure than anything else. This is especially frustrating when the blessed toolchains and repositories are well-established at this point (e.g. Leiningen, github, clojars.org).

The predilection towards 'hard problems'.  This is one of the greatest strengths of the community, and something I as a veteran developer love.  But it often inhibits the creation of teaching material for completely novice developers.  This seems to be turning around (light table, clooj, etc), I would just encourage the community to keep pushing and worrying about a good balance in this area.

It is really slow to start it up.  Even uberjar's, which you would think would be AOT compiled, are *slow* to start up.  Makes using them for anything where a user would have to wait for the startup almost impossible.  The runtime performance seems good -- once you get it started.

Clojure is ahead of it's time.

Startup time. Exceptions. Debugging.

Startup time.

Performance, though I think it's already reasonable at this point.

Error reporting (stack traces), though I haven't specifically looked at 1.4 yet to see what the current state is.

It needs more docs and more libraries

JVM-centricity, which is waning, but having clojure be abstracted more and more from the underlying implementation platform, and allowing facilities for libraries to do the same could be a huge win.

The only difficulty I have had is understanding how to code clojure. This is my fault and quickly going away. The language itself is great.

Use in embedded environments.

Mainly the lack of or immaturity of some libraries for key tasks. This is probably just related to how young the language is. It seems that a few key members of the community are able to put out some great quality work, but not enough people are able to step up to the plate and contribute to projects to really keep them going. I think some key examples of this are Korma, which has potential to be THE sql library for clojure but falls a little short (it lacks many-to-many relationship types which seem pretty basic for a sql library, among a few other things). Also, Clojurescript One, which was a great piece of work and it was beneficial to see all that code, but in the end it wasn't exactly designed to pick up and use for a project in a clean manner

The type system is a mess. In stuff like types and protocols the implementation is leaking through.

Documentation is a bit terse.

Getting the environment set up. This has been improving lately, but a year ago it almost made me give up on Clojure.

Lack of good 'getting started' documentation

For a lisp not a lot, i tend to like strong type systems but writing clojure code is more the ultimate freedom than the ultimate jail that haskell is, so it scratches a different itch.

 

My biggest pet peeve is no forward declarations though.

 

 

The installation has improved for emacs/slime, but it still requires a bit of searching to find the most efficient path.

Laziness. Its practical advantages aren't that great and the downside is huge: many pitfalls await the unwary programmer. Also, dynamic variables are dangerous because of laziness and because bindings do not hold across threads.

Too hard to find packages. After being spoiled with rubygems and npm, lein seems pretty half-baked.

Stacktraces that don't tell you anything.

Relying on non-clojure libraries to fill in gaps. Clojure should have a comprehensive runtime library covering pretty much everything out of the box. Look at what's offered by Go for an example. If we aren't careful we're going to end up like Haskell where nobody seems to know what libraries work or work together.

It is an elitist language.

Tutorials need to be a little more clear, and a little more inviting for new people coming to the functional language, as well as maybe the JVM.

 

Also, I'm having trouble finding tutorials that help you make an application from 0 to finish, mainly there is just...This is how you do X and Y in clojure. I want a, this is how you can implement a X in clojure, and here are the proper steps to do so from A -> Z.

 

 

The terrible documentation. Seriously.

It's really hard coming from OO world to start a designing of an app (what ever the "app" is), I would like to have more high level tutorials on how to create a whole app. For instance, How to break things up? I know that some the OO patterns has no meaning in functional language, even though we need to write a lot of code to build an app (put the name that best fits to clojure community), but I would like to have some recipes on how think an app at least for some common uses like webapps, games, cruds....

Most Clojure code is indented more or less like Python instead of like Lisp, which is frustrating since it is less meaningful.

I just started learning, from a procedural background, so I am still getting used to functional. That's not really Clojure's "fault" though, I knew what I was getting into. It's like going to a strip club as a married man and getting a blowjob in the Champagne room. You can't really claim you were *surprised* by what happened to you, but in the end, it adds to the richness of your life.

Appeal to new programmers and the "killer app". Ruby's adoption was driven heavily by Rails. Clojure afaik has no library driving the demand in the same way.

 

I hope to see tools like Cascalog, Storm and other "big data" projects become that Clojure sweet spot that pull in developers from other languages.

The stack traces are still rather difficult to read.

 

Starting up the Clojure environment takes a bit too long.

I'm still fairly new to closure, but it sometimes feels like STM is _the_ only way to do things and it isn't always a good fit.

Documentation, andriod, iOS

slow start time, ease of iterative development in scripting / web development environments vs python or ruby

The stacktrace is horrible, and startup time is horrible.

Not all algorithms/problems are easily/efficiently solvable using the functional approach. Core library doc should include more sample code (like javadoc has).

Clojure has a paradigm and a programming philosophy that in several respects is unique to Clojure.  Discovering and discerning the intended use as described in Rich's talks is a challenging process.  I think some lower level tutorials that focus on the evolution of problem solutions from initial (naive) discovery towards idiomatic Clojure would be very helpful.

Honestly, I can't think of much that is weak about clojure but if I had to pick one, I'd say being labeled a LISP. It carries a lot of preconceptions among programmers who have never used it which might put them off before even using. Compare to something like Go which doesn't carry preconceptions about its lineage. This isn't really a huge weakness and overall I find the Clojure ecosystem to be very strong and a pleasure to be a part of.

(1) Not compatible with Common Lisp

 

(2) SLIME/clojure doesn't work with SLIME/Common Lisp

as i say, the java platform itself is my biggest problem... everything is more difficult in java comminuty. build tools, xml files, slow runtime, huge memory footprint even for simple jobs, big file size (compiled), heavy tools (like eclipse), no static compile,....

i come from C/Python background... C is so hard, but it feels so simple, also its damnn fast... python is kind of slow, but it feels fast!!!! and its really simple...

 

clojure is really a promising language, but i really want to see an official native compiler for it, at least in x32, x64 and arm.

It is still really difficult to get into the language. Clojure Lang  serves as an API documentation site and is really cold for beginners. Documentation can be greatly improved for the clojure.core by providing examples. This would be especially helpful for people new to clojure.

While the community is small the odds someone has had the same problem as me and had it solved on S.O or similar is low

Performance when compared to Scala / Java

All of the bloat needed to get it running on Android & large startup time

Deverlopment Environments, Killer App, to get a mentor

The documentation is often explicit but weak. Things like clojuredocs.org exist because the default documentation is so bare bones. I find myself going to clojuredocs 100% of the time when given the choice between the official docs and them.

 

Often times libraries are not the easiest thing in the world to find. I think node did a good job at this early on by maintaining a "libraries list", go started this but got out of date too soon.

The main problem is lack of development environment support. I like that Clojure on Ubuntu it is one apt command (for version 1.3, anyway) away but on other platforms the install and running process is not so good. I use IntelliJ on Windows and Mac since setting up a text editor and shell process manually was too much of a bother.

None of these apply to me directly but are just my own observations based on developer feedback I get:

 

- Syntax, or lack thereof, is just to foreign

- Clojure, like most other Lisp dialects, is very powerful. This can be a double-edge sword as the developers can get lost in the macro-world of `i-bake-my-own-language-when-i-feel-like-it`.

Web app framework like Grails

The JVM is more of a black box than I would like. My other go-to language is Python, and the CPython (the canonical implementation) developers have gone to great pains to expose the inner workings of the interpreter to normal developers (through a C API). There are two libraries that implement real continuations (greenlet and eventlet). The core of greenlet (http://codespeak.net/py/0.9.2/apigen/source/c-extension/greenlet/greenlet.c.html) is under 1000 lines of C. Imagine trying to do that on the JVM. That transparency precludes the CPython devs from going after certain optimization strategies (the GIL is still around because removing it would break C modules), but the ability to pop the hood makes me feel a lot more comfortable about using the language. And there have been times when I've had to do that, either to integrate with low-level libraries or (less commonly) for improved performance.

 

Also in that vein, JNI is an abomination.

 

Also also in that vein, the Java community seems to be hostile to the operating system. Why to I have to juggle hundreds of different nouns (Selectors, SelectableChannels, SelectionKeys, etc) just to use one syscall (epoll)? Compare https://github.com/facebook/tornado/blob/master/tornado/epoll.c to the implementation java.nio.selectors. And what do I do when I want to use splice or tee? Or mmap a file larger than 2GB? Do I have to write JNI bindings?

Load time.

While error messages (upon throwing uncaught exceptions) have improved, I feel there is still room for improvement.  For example there are some cases in which one of my source files has a syntax error, but the exception points me to a line number in a different file where (use ...) is called on the file with the syntax error.

Single pass compilation

Startup time

Stack traces and error reporting are one of the largest deficiencies.  I understand the complexities linked to JVM interop, but I think this is one spot that really needs a lot of love especially with the drive for Clojure-in-Clojure.

I tend to forget about problems once I have a workaround, sorry.

Being shackled to the JVM

JVM dependency

Documentation is difficult to navigate.  Why are there no links in the function descriptions?  Please add links to types and functions mentioned to in the function description.  Why is there no easy way to see all the functions that apply to particular type, e.g. find all seq functions?

 

Installation remains difficult but has gotten much better with leiningen.

 

parens

Documentation of 3rd party libraries on Clojar. Some languages come with everything built in, like PHP. Other languages (Ruby, Clojure) have meta-programming abilities that make it especially easy to integrate 3rd party code into one's projects. On the bright side, I end up using a lot of 3rd party code, as it is easy to grab from Clojar. On the dark side, some libraries sound very promising but then I can not figure out how they work.

Java.

JVM startup time

user=> (count (ns-publics 'clojure.core))

580

 

... and I don't find that set of functions well thought out or orthogonal. munge? ffirst? next vs rest?

universities

The documentation can be confusing for beginners and it can be hard to find  recommended tools/best practices for a given problem.

tied to jvm

debugging

performance

 

JVM-imposed restrictions on FP as it could be

Type safety - through some kind of pluggable mechanism

Startup

the confused state of libraries across different versions.  you google for a solution, then spend half an hour working out whether it's relevant to 1.4, and then another hour trying to find the right pom / jar to download.

New people have to navigate a jungle of cool guys

being tied to the JVM is both good and bad. Being able to target CLR is ok, but unless Clojure runs on the Xbox it's not a good thing for me. I'm seeing where ClojureScript and ClojureC go, since those are very interesting targets for me (gamedev, game-engine dev)

A concerted effort to make a first class toolchain to build stand-alone applications for iOS, OS X and embedded devices (stuff that would be the traditional realm of C and it's ilk)

Error reporting!  

Stuff for people who are new to Clojure / Lisp:

 

Foremost, a step-by-step way to set up your tooling environment from scratch. I tried writing up what I know/knew, but I'm sure a better job can be done:

http://www.elangocheran.com/blog/2012/05/the-newbies-guide-to-learning-clojure-part-2-tooling/

 

Secondarily, I think it would help to have little "snippets" of code that show how to do common operations & transformations in Clojure / Lisp. For example, "when do you use reduce vs. apply"? I like to draw the analogy between the set of command line utilities manipulating on streams and the set of Clojure core functions manipulating on sequences, and what I'm getting at is that we need our own version of Commandlinefu, but less reddit-y and more educational. I at least have a saved blog post draft of what I'm thinking about, but I'm sure someone smarter (ex: you) can take the idea and run with it.

approachable editor for newbies (but this continues to get better with ccw, clooj, light table)

Uninformative stack traces

- clojurescript toolchain

- clojurescript libraries

- no RoR-like web framework

- stacktraces

- protocols

The amount of outdated and hence, incorrect, clojure setup docs and tutorials on the net - especially for emacs/slime.  

Official documentation sucks. Its spread in many places, if it exists at all. e.g. type (doc assoc!) and it doesn't really mention the words, "does not bash in place," but its here: http://clojure.org/transients

 

Library documentation (i.e. not so much in Clojure itself) is also frequently circular. e.g. Function X will X your data. Library Y is a Y'ifier for Clojure.

 

If it weren't for clojuredocs.org (which is falling behind - where's 1.4? functions from clojure.core missing from quickref) then it would have ended in a massive "fuck this" long ago.

 

I also forsee problems with the syntax differences introduced by clojurescript e.g. accessing fields a record is different. WTF?

i)  Lack of broad and deep tutorials like the Java tutorials/MSDN examples.

ii) IDEs that cannot give auto-completion. Beginners, especially, will be put off by this.

The Java-source of its implementation is a pain to look at.

Both from an idiomatic standpoint, as well as from a basic formatting point of view.

Google's guice could be used to render Hickey's love for `static' useless, for example.

That's such a shame, because the source code's ideas must be beautiful.

 

The reference page has a lot of typos and no one seems to care. That's such a shame,

compared to clojure's incredible beauty.

 

A built in high end REPL would be nice. But that's probably nasty to do, as you need to

interface with native stuff.

 

Not Clojure's fault: JVM startup time sucks. That makes Clojure (on the JVM) useless for

scripting tasks. Clojure->C or Clojure->Javascript running on NodeJs might help out.

 

For those learning clojure, but unfamiliar with java: having to dip into java interop for very basic things, e.g., parse a string to a number.

 

For everyone: stack traces.

Getting started. Getting started still hurts. Also, not the MOST glaring, but build tools still seem to not fit my needs very well.

The CA is a big issue that makes it very annoying to contribute simple fixes. Having a digitally signed one would be awesome--I want to contribute some perf improvements, but I don't have the motivation to deal with the CA.

Interaction of namespaces, protocols, records, use / import, AOT.

leiningen needs ivy integration for dependency management

Debugging

 

I feel that the significant performance difference between Java and Clojure is an area of concern for me, although I do feel that this is offset well enough by the lack of boilerplate and conciseness of the language itself is reason enough to use Clojure over java.

Leiningen support for Windows.  The two biggest things that it could do to improve this are:

1) Not require users to manually add it to their PATH

2) Be more clear on where it looks for a user's ~/.lein directory (I have to make lein-swank a dependency of projects that I want to use it on because I haven't been able to find the magical place that I need to put my profiles.clj file for it to work)

Complexity of getting started, especially for clojurescript: the documentation is very disorganized and the toolchain is annoying to set up and get reliably working.

 

Set of comprehensive tutorials for performing common tasks (Web development, database interaction, etc.)

hard sell to my colleagues, but that might mean i need different colleagues.

People end up writing code with in-place mutation for performance reasons, and the language doesn't make that easy.

 

Clojure with all the type annotations required to make it perform well looks a lot less like the elegant thing we know and love.

The same thing that makes it great: its syntax (or lack thereof). Most of the people I've shown it to have seen it as a curiosity or a toy due to the LISP-like syntax. Unfortunately, in enterprise-land, mainstream C-family languages are the standard, and anything else (including Ruby, Python, Perl, etc.) has an air of "risky startup." This isn't really a complaint, though; if Clojure looked just like the code I wrote for my job, I probably wouldn't be interested. Maybe Clojure can partner with Microsoft and then my dreams of writing Clojure all day will come true ;-)

I don't get the feeling that Rich Hickey is as involved (or at least as publicly) as, say, Martin Odersky is with scala.

clojuredocs.org is great and should be the standard. The standard docs are a little intimidating without good examples. IntelliJ has minimal support for debugging. You can only see the variables in the same function scope.

 

While concurrency is a big reason for consideration having remote actors and agents like Akka for Scala built-in would make it a lot more appealing.

There's no easy path for newcomers—especially those coming from Ruby or Python. And in many cases, this happens because newbies are left to discover some of Clojure's idiosyncratic strengths for themselves.

 

For example, Clojure comes packed with a powerful REPL. Clojure's REPL is much more useful throughout the development process than, for example, Ruby's IRB. However, someone coming fresh from Ruby will not know that.

 

So Clojure folks might tell our Ruby refugee, "Look, it's so easy to get a REPL up and running! Off you go!"

 

And the Ruby guy will be left wondering, "But I don't want #$%@ IRB; how do I get started with *real* development?" Nobody told him the relative strengths of Clojure's REPL.

 

There needs to be an easy-to-find reference that really spells this stuff out.

Incomplete and often bad documentation of the standard libraries. Lack of official documentation for internal interfaces and protocols. The developer agreement required for submitting patches, even for documentation.

Clojure's biggest weakness is hands-down its dependency on the JVM. While some people swear by it, I consider it to be a bloated and inefficient monolithic VM which makes using Clojure quite painful.

 

That being said, I'm very excited about the prospect for native Clojure via `clojurec`—though I am worried about breadth of libraries and interop of a native clojure. Libraries and interop is what has kept me from investing fully in Scheme or Common Lisp.

A very poor toolset around dealing with exceptions.

Editors

Android support. This should be required for any JVM language.

clojurescript is still beta. Because of this Clojure isn't getting the reach it should.

 

There are many awesome tools to make development productive, but getting them up and running together on my system takes more time than is convenient for hobby projects. I've upgraded to the latest versions of emacs, clojure-mode, paredit, and leiningen and had a hard time getting everything to work. This is likely because of my system configuration, but it is still a turn off.

slow :(

Packaging!

 

After three years there's still no good way to just jump into a REPL. I have shell functions for a one-off repl, and I keep a dummy leiningen project around to run lein-swank from, but that's pretty weak...

INSTALLATION

Static type checking is really missing in large projects.

 

The Lisp background makes it hard to sell the language in the enterprise world of Fortune 500 companies, specially where programmers are treated as replacement parts.

Startup time.

Performance and simplicity with regard to persistent data structures, immutability, and cheating when you need to.

Not a glaring weakness per say, but if Clojure could target iOS the popularity of the language would skyrocket.

namespaces

Since I supply my colleagues with some tools I write in clojure FASTER STARTUP-TIME would greatly enhance their acceptance.

Error outputs in Java are ugly and often next to useless.

To be frank, I'm a newbie with Clojure, so I can't write anything bad about this language.

The time required to load clojure.jar is pretty huge.  

Some parts of the language are still in flux.

Not a big deal, but I think the whole packaging/library environment is way too fragmented. Leiningen is nice and integrates well with clojars, but I think a bigger issue is *finding* libraries that do what you're looking for, sometimes.

It's still a new language.  Nothing to do about that but let time pass and Clojure success stories bubble up outside of the Clojure community.

 

I can't tell if the job market for Clojure skills is increasing. That's really a poor measure of a programming language's success. But it matters some - first, you like to think that if you are the type of hacker who works for other people, that maybe people exist who will hire you to hack in your choice of programming language. Second, it implies that Clojure offers benefits that are recognized in the marketplace.

a) Debugging error messages, esp where anonymous functions are concerned. This might also be due to my inexperience, but I feel error messages could be more descriptive

Documentation is very ambiguous much of the time. Clojuredocs.org helps with that.

Lack of libraries compared to established langs like ruby

Difficulty debugging issues that occur at the integration point with other systems and Java libraries.  Getting logging working properly in a larger application was painful, for example.

Lack of good IDE and debugger

Not being able to program interactively when using protocols and records.

 

Namespace definition and management. The syntax oddities and the issues around needing to use a large number of namespaces. Immigrate stinks.

Definitely the documentation. Now that I've coded clojure for a few months it's fine, but starting out I felt like I needed a dictionary ("form? the hell is a form?"). Having a guide to help the uninitiated get familiar with the new concepts and terms presented in clojure would go a long way, I think.

Too many promising libraries get abandoned soon after a few releases.

Google's Go is going to be its biggest competitor.

Most people don't find Functional Programming easy enough to start with.

Lack of comprehensive official documentation.  (clojuredocs fills this gap somewhat, but it shouldn't have to).  Deprecation of libraries makes google searches harder -- i.e. "I found this clojure.contrib lib and it does exactly what I need, oh what's that? It doesnt exist anymore? well what do I use???"

On Java 7/Windows, It takes 21 seconds for a Noir/Compojure/Aleph/Netty web server to start up on my Q6600 box with an SSD.  It takes a similar amount of time for clj-ns-browser to start up, though less.  I think most of that time is spent in the Clojure compiler.  If it did some kind of .class caching by default that I didn't have to configure, I'd be using it more already.

 

I prefer using IntelliJ IDEA and La Clojure needs a lot of work to match the interactive capabilities of Emacs + SLIME. Learning and configuring Emacs is another huge bottleneck for me.

 

I've had to track down a hundred dependencies and write my own Clojure/Java build system, because I don't want to pull down random jars from Maven Central, even if they're signed. This isn't as big of a deal as the other two things.

The official website is very crowded and does a bad job of directing (especially new) users to relevant places (like up-to-date information on acquiring & using clojure, getting help & documentation, and current developments).

Hard to evangelize for Clojure given many developers' misconceptions about languages, tooling, static typing, OO, etc. Not really Clojure's fault, but without buy-in from my coworkers (or even admission that Java is lacking), I cannot push Clojure in my workplace as I'd like to. Perceived performance seems a challenge, even though performance can be made fast up to the limits of the JVM.

 

Regarding contributing to Clojure, it has been difficult for me to see where and how I can contribute even though I have already registered a contributor agreement. A roadmap for various types of contributions would be helpful.

Most frustrating part for me(as mostly Ruby programmer) is too tight relation with Java. Sometimes it's good(when you wrap Java libs, etc). But sometimes even for plane tasks you need to know core Java API quite good.

 

For example, (Integer/parseInt "123"), or (.charAt "foo" 0) - you can't do such common tasks via pure Clojure. This means different Clojure dialects will be not compatible even in trivial things.

I guess, all "javisms" from this http://hyperpolyglot.org/lisp can be implemented in pure Clojure and this can help to adopt it for non-Java programmers.

There are some really terrible choices in the core which should be remedied.  For example, the behavior of conj is different depending on the type given.  For a long-time Lisp hacker, this is an atrocity.  The entire Clojure 1.x version should be considered a "demo".  Please oh please don't do what Java has done and effectively say "this is it". Learn from experience (of which there is a lot), fix what's broken, and move ahead to 2.x.

Startup performance for small programs. A ClojureScript interpreter would be amazing.

integration with older projects with a large amount of technical debt

It isn't rolled and packaged into a nice little unit that requires a simple installation. To get Clojure, swank and lein set up is not a trivial exercise for potential users, especially compared with the Python ecosystem. Imagine two prospective programmers. One wants to use Python. He goes to the Python website and "Download[s] Python". A would-be clojurian would have to independently install at least 3 separate things and have the know how to install them. What may be a simple task for a hardcore UNIX-like system user might not be so for someone who would choose Python over Clojure purely because of the lengthy install process. The install process is certainly the bottleneck. Clojure the language rocks!

It lacks interop with a decent GUI toolkit (e.g. GTK, Qt). Swing has "the Swing look" (that is, non-native on every OS), and feels non-Clojure-ish.

 

In fact, a good declarative/functional wrapper around any of the above would be great.

Adoption is too damn low

"User guide" style documentation.  The reference information is generally good, but n00bs such as myself who are trying to accomplish some task usually don't know where to start.

 

The various tutorial sites (4clojure etc.) are good, but require a fair bit of time investment.

 

Despite being ugly and antiquated, the old Sun tutorials for Java (http://docs.oracle.com/javase/tutorial/) are a great resource for n00bs. They walk through common scenarios end-to-end, and while one can argue as to whether they espouse best practices or not (EJB *cough*), there's no denying they are very approachable and lead the n00b up the slope towards apprenticeshipdom.

Finding libraries.  The clojure-toolbox.com and clojars.org are sometimes helpful but usually not.  Also after identifying libraries for a certain task it can be hard to tell what is canonical/deprecated/abandoned.

Integration with existing tool chains.  I'm coming from Java, and it's great that I can interop my existing Java code, but maven integration has been a huge pain.

 

If I could start a new project with leiningen / ring, etc that would be great, but for a language to really take off I think it needs to be compatible with existing code in the last thing (i.e. C => C++).

 

The maven plugins leave quite a bit to be desired. The clojure-maven-plugin compiles my class files to 1.6 and throws a version error if I try to use any of my Java code in 1.7. Pallet's zi doesn't have a junit output for tests, which for me is critical in keeping with Bamboo for CI.

My biggest problem with clojure is the mental gear-shifting requried to switch between javascript on the client and clojure on the server.  Clojurescript addresses this directly, but I have found the clojurescript documentation challenging, I'm worried about the performance overhead, and overall CLJS doesn't feel ready for prime time.

 

Next up would be JVM startup time.

Clojure/core's apparent unfriendliness to community contributions.

Stack traces, patch process.

Library discovery.  Some outdated projects on Github.

There appears to be no incremental transition to clojure, you just have to jump in.  I suppose there is nothing to be done about that, given the nature of lisp.

A lot of people think jvm is the only way to go..but i wish there was clojure in clojure

Awful error messages.  Just awful.

Somewhat cryptic stack traces? It's hard to say, particularly with a language that gives every appearance of being really well balanced. Maybe the JVM load time, where for instance the difference between getting a nodeJS server and a Noir server up and running can be a matter of several seconds. But, uh, those are just seconds, and it only has to happen once, and consider the tradeoffs...

it scares me a little that the clojure maintainers (rich, stuart, etc) are jumping around (clojure -> clojurescript -> datomic) so i worry about their commitment to the future of each of them.

* Scripting is not straightforward:  (maybe I'm not using the right libs, I heard that with lein2 we could even shebang a script #!/bin/lein, I should look closer into that).

 

* Namespaces are painfull: I have to cut & paste them all the time (again maybe not using the right libs: I heard of (immigrate) but not used yet).

 

 

Lack of a step-wise graphical debugger. If I could debug clojure/clojurescript as easily as coffeescript I would double the number of projects I use clojure on.

As mention above the dependency on the JVM - leading to some performance and portability (iOS) issues.  

unhelpful / uninsightful  error messages

 

Good api documentation with examples and an easy way to find whatyou need. Clojure corewould need nice examples. Luckily the nice people at clojure doc have provided quite many.

Good api documentation with examples and an easy way to find whatyou need. Clojure corewould need nice examples. Luckily the nice people at clojure doc have provided quite many.

Haven't used it enough to really know, but for clojure adoption I think one problem is that there are no really good online comprehensive tutorial ala "learn you a haskell for great good". Another thing that could be improved is the clojure.org site that doesn't contain much info and haven't been updated in a long time.

Clojure devopment in a windows environment.

Starting time, Performance.

I'd like to see progress on the "pods" concept, or whatever can handle auto-cleanup of allocated resources in the context of lazy evaluation.

 

I'd like to see a smoother Emacs-based environment than SLIME+swank. SLIME itself is (was?) terrific for Common Lisp, especially when it first came out, but the project is not a good fit for Clojure.

I was surprised to hit this on Clojure 1.4 (while trying to implement a Sieve of Eratosthenes):

 

user=> (vec (repeat 2000000 true))

OutOfMemoryError Java heap space java.util.Arrays.copyOf (Arrays.java:2882)

 

after just a few days of playing around with the language. I realize that I can tweak the size of the Java heap, but I don't understand why Clojure has this issue at all out of the box. In Ruby, I can easily create a two million element array with no OOM errors.

 

And if a more experienced Clojure user would respond to this by telling me I need to better understand the way Clojure's core data structures work, I think Clojure will lose out to languages that don't require me to think so hard so early on.

 

Making it easy to write in "baby talk" -- using inefficient data structures and non idiomatic patterns that look more like one is writing Ruby-in-Clojure, for example -- is a healthy thing for a language, IMHO. In this case, I literally could not wrap my head around writing the sieve without reading a white paper (and even still...), because I seemed to be forced to do it lazily, which was an extremely hard concept to wrap my head around coming from Ruby.

Rich Hickey has placed a lot of emphasis on avoiding 'complecting' Clojure with overlapping features but deliberately avoiding an object system has led to some conflicting/confusing features aimed at obtaining some of the advantages that objects afford. I think that a CLOS-like system, whose use was both flexible and optional, added at the beginning would have been simpler and more comprehensable, especially when you realized that Clojure has to work with Java's object system anyway.

 

That's a lost a cause at this point however. A bigger issue now is probable the long startup time which is not just due to the JVM but also to the fact that the compiler can't remove the Clojure.core from a compiled Clojure binary. some Common Lisp implementations could do that and they were much faster. This defect rules out whole classes of applications which Clojure would otherwise be suited nicely for.

 

Also, something needs to be done about those stack traces.

There definitely is friction between being such a different programming paradigm from Java but often needing familiarity with the JVM infrastructure. Leiningen really helps here.

 

Java interop is very strong but the joint hurdles of integrating non-maven libraries and the confusing ns macro/use/require/import semantics are a barrier to entry for fully leveraging it quickly.

tied to jvm

Start up time on the JVM

It's great, and that's not a good sign, since crap rules in the real world.

 

Perhaps if Clojure sucked, then everyone would accept using it, but then, I wouldn't want to use it. So that wouldn't solve anything anyway.

 

Try getting an enterprise Java shop to even consider Clojure. They won't. So my solution is to come up with a product using clojure, to deploy in a situation where customers don't know or care what language it is written in.

i think it's a wonderful language heading in a great direction. i'm fairly ambivalent with regards to hosting it on the jvm, though i see it as a big win for a number of reasons. i hope that the trans-compiling craze doesn't effect the community too greatly — in my mind the perfect outcome for the language would be clojure on the jvm, clojurescript and one, solid, native compiled implementation.

Limitations of the JVM + lack of mature non-JVM implementations.

 

It appears most Clojure people are using Emacs. That scares many people away.

I like Emacs, but of the 100 colleagues I work with, I'm the only one.

Eclipse might be a better target.

 

Also, I think that the lack of type safety limits the use of Clojure for many enterprise applications. Perhaps Scala might be more interesting there. (Or perhaps Xtend, Kotlin, Ceylon?).

 

There is a lot of "competition" going on in JVM-based languages. I think acceptance of Clojure probably boils down to simple marketing. Spend amazing amounts of money to push it, and it might be embraced by a larger community. Do not, and it will probably die away along with the rest of Lisp :)

 

clojure.org needs a major overhaul.

Long-term, the JVM will probably be a liability.  And that liability is likely to sneak up on the community.

 

 

The default repls awful lack of history going backwards, or anything useful.

Difficulty finding / evaluating relevant libraries

 

It is very hard to tell which library is the preferred library to use for a particular situation (e.g. the json libraries, csv libraries, web server libraries). I understand that within the same domain some will be better for certain purposes than others, but there is often no clear consensus (or it is hard to find one) on what is a good default library to use for any particular problem.

 

Some libraries also seem really useful, but appear to no longer be under active development, and then it is hard to tell what fork is now the main branch. I know I should take this as a call to action to contribute, but that's difficult for me to do right now.

IDE support. I think EMACS/SLIME is the best environment (for me). I *so* hate using EMACS/SLIME... :/

I know work is being done on it, but stack traces continue to be very ugly and difficult to decipher.

Debugging/error messages are subpar.

Also editor support (particularly for lein) is lacking.

Performance can be a real problem but only if there is a real need (heavy calculus...)

Make sure people are aware Emacs is not the most useful editor. It puts off many people that want to just dive in clojure.

A killer app (Rails, Drupal, JQuery, etc)

Examples of how different software libraries can be combined into an

enterprise development stack (not including Immutant).

That it was a moving target for a couple of years with breakage between different versions.

Start up time

Slow To start lein. Diffucult to make sense of a stack trace some times.

Installation and tooling concerns. "Well, you should really use emacs, but otherwise there are the following 7 incomprehensible and bad options."

Setup is frustrating. Support in vim is weak. REPL is immature. It shouldn't be this hard to get started.

The clojure docs have good info but are horrible to work with because of formatting and organization I guess.  Behind python (& PHP... Sorry)

Profiling Clojure programs is really hard. I'd love it if there were a way to figure out which fns were using the most time, where I've leaked a seq head, etc.

Useful and non trivial examples

The documentation of the standard library lacks a comprehensive overview. A breakdown of functions per category (i.e. functions to deal with seqs etc) and example usage could be a solution.

Clojure is a Lisp. Therefore, its just harder to find people who know it and/or are interested in learning more about it. Its not impossible, just harder, so the benefits of using it are tempered with the fact that it will be more difficult to scale up teams on it. That said, Java interop does ameliorate that somewhat since ex-Javaheads can use the libraries they are already familiar with.

embedded/mobile devices

Slow start time, general JVM awkwardness, build process, installing dependencies. Lein makes a lot of it better, but it's still slow any time I work with on project.

That it is a Lisp.  I hate to say this, as I really love Lisps in general, and Clojure in particular (it was the Lisp I finally sat down and learned).  Yet, I am compelled to give this answer because for some reason people seem immune to Algol's curly braces while becoming ill from "all those parens".  It's weird...

Not enough "marketing", or examples of use, case studies of commercial applications. I just don't want Clojure to stay a marginal language. Obviously Clojure is still a young language but I feel only ubergeeks are using it. We need to bring it to the mass somehow. But things improve steadily so there is hope!

Stack traces.  

The only glaring weakness I see is the youth of the language. Similarly to Scala many of the problems that must be solved have to do with facilitating more real world use. Which mostly comes in the form of tools, support, development environments ect. Over the last year or so I've been tracking Clojure I've seen tons of improvements in the language, environments, and tooling. Yet still things aren't at the maturity level they are for other languages, which is expected. I think good progress is being made though and isn't too much of an issue.

One site to rule them all.  We need some place to go for a reference to all the tutorials, examples, blogs, etc.

 

I have been having a difficult time debugging seqs.

 

 

Confusing use/import statements

Fast parser generator integration. Antlr, Beaver and the like generate Java, and need non-trivial coding to integrate with Leiningen.

Hard to understand error messages, steep learning curve

Needs something like grails or rails to get crud apps working very quickly. I keep trying to build one of these...

Lack of builtin type inference- might be interesting to have a variant on Ocaml or something with type inferencing, though obviously that variant would "feel" fairly different.

The error messages.

Lack of CL like restarts

Lack of tail call optimizations

Performance, and libraries/features to help mitigate those performance weaknesses.

 

Lack of information on canonical ways of managing resources/source code/namespaces.

Version compatibility between libraries turns ugly quickly.

Lack of attention from core team for better debugging functionality.

Clojure requires you to "step up your game" when learning it:

 

1. Emacs as the canonical development tool

2. Functional versus the imperative paradigm we learn in university

3. Lack of marketshare in business/enterprise

 

makes Clojure a language that really requires concerted personal effort to attain. Nothing wrong with that! It's just hard to find anyone in my technical circle who is interested in it though :(

 

Perhaps some way to make Clojure apps more "sharable" would make it more attractive to personal learners who can then show off their cool apps (without the receipient installing a jvm). For instance, python has py2exe, py2dmg to create standalone applications. For this reason, I'm really looking forward to clojure-lua.

JVM

Non-interoperability with legacy linear algebra and related software (LAPACK/LINPACK and such). This is a runtime issue. The JVM alternatives simply don't compare favorably with the options in C/Fortran. Non python interop is also a problem.

Its compilation story. Its hard to build a deliverable product and give away the source code. Compiling a large product with lots of libraries isn't a smooth path right now.

- clojurescript toolchain

- clojurescript libraries

- no RoR-like web framework

- stacktraces

- protocols

Not being feasible for command line apps, but this seems to be being attacked on multiple fronts, so I don't have many complaints at the level I'm using it at.

Difficult stacktraces. When you get NPE and other non executing problems in the code, it can be VERY difficult to track down where. This of course encourages good testing, but can still be frustrating.

Dependency on the JVM if one wants to use all of Clojure.

Lack of support for (primitive) numerics, areduce et-al with n-dimensional arrays is REALLY painful - Prismatic created the flop library for this reason but have not open sourced it, hopefully something similar will be released in the future

Getting started, and library documentation.

 

It took me months of tinkering to get a emacs / SLIME setup working how I want it.

 

Almost every library I come across in the community has poor-to-non-existent documentation. This is extremely unfriendly to newbies. You have to know the language so you can read the source of the libraries and figure out what they do. At the same time, how are you supposed to learn the language when you can't use / understand any of it's libraries?

The yellow spot on the back of its neck. If you hit it, you get critical damage.

Not enough maturity/investment in the clojurescript ecosystem.

0 love - I love clojure but you did ask...

 

1 contrib - What happened to contrib is an abomination and disaster. I have no problem with it's decoupling. But it was poorly realized and is still difficult to find, use and discover.

 

2 documentation - Clojure/core roadmap, discovery of changes and improvements to anything official. The community has done an excellent job of improving documentation. None of that matters if Clojure/core (Clojure.org, official stuff) still sucks. Example: Go find a competent python developer, put them in a room and tell them to use the latest version of clojure and clojure.math.combinatorics. <wait and see what happens... you can't cheat and tell them about lein, the google group, etc.>

 

3 Clojure/core - They don't use standard community tools or repositories - lein and clojars. They don't communicate with the hackers who are actively using Clojure in real world apps. Please, rejoin the community. Or at least provide some easily discoverable information for how to get and use $LATEST. nrepl is a great improvement and example.

 

The REPL is great - but everyone uses stepping debuggers now. Clojure needs one - badly.

Lack of tail call optimization

Namespaces too confusing

JVM

 

The start up time of the JVM

Poor error messages and unhelpful stack traces

My biggest wins (general purpose collections) have their downside: They cause confusion and errors when the values become more complex (e.g. strongly nested maps with many attributes). I help myself with stuff like this (https://github.com/toofuu/like), but I think a more thorough approach would really improve the maintainability of larger clojure codebases. I'm not saying we need static typing, but rather a means for evidently describing the shape of our data, so that we still can understand our old code later. In part, you would need a language construct to specify this shape (like my helper funcion above, but more seamless), and the other part would be the inference of this information for the consumers of this data (e.g. let bindings that transform this data, or the return value of the function). Maybe the clojure compiler could automatically add this as metadata.

That's just an idea, not sure if it's a good one, but I definitely think Clojure needs a way to describe the shape of its data.

Lack of jobs available. Limited too much to hobbyists and self funded projects. Jobs stimulate the ecosystem.

Error Messages, Documentation, hidden traps like defonce on multimethods etc.

The error messages and stack traces are often cryptic and unhelpful.

No simple editor/IDE for Clojure. The current IDEs are either way too bloated or lacking. There is no "default" editor to simply code. It's a great hurdle especially to newcomers who have to deal with the frustrating process of setting-up.

Not _really_ a problem: probably all functional languages seem strange, when not used to them. Parentheses are NOT a problem (if any, then the funny 'tradition' in LISPs to close all parentheses on one line ; -)

I think the Clojure's biggest weakness is that it isn't famous or "big enough" and thus decision makers see it is a big risk to adopt it.

Lack of debugging support.

Having a optional static type checker would be very nice.

The Lisp stigma and the limitations of the JVM.

Lack of debugging support.

Lack of job postings.

I think it's not a technical problem, i think it's a perception problem.

It's seen as an elite language.

 

I've tried my best to explain to technical people the reasons of its existence - #fail

I also tried to demonstrate how to use it. There is a 'wahou' effect but still nothing later - #fail.

 

It may be me or the tools that i used or both that make people scared...

 

Granted, i'm no Rich Hickey but still i can make sense when i talk... or not?!

don't know yet

I've made a major rework of an existing Java backend service processing huge amount of data, and I have never had such a great development experience before. It was fun, it was fast and easy to research, develop and test and I'd love to see my coworkers using Clojure too, but most of them use IDEs for Java development (IntelliJ Idea mostly) so I examined La Clojure plugin. It is not very powerful and solid yet, it lacks features and it's clumsy and a bit buggy. Moreover, it is not actively developed. I'm pretty sure better IDE support would make more developers to come to Clojure from Java in companies using Java. But there's no this kind of bridge today. I just can see it with my eyes how it's not happening in my company. But why? Clojure is just a Java library! =)

Stack traces / debugging

I don't know yet.

Debugging is not straightforward. (Poor stack traces.)

Clojure's biggest problem for me is it's lack of object oriented programming features. While OOP is not a panacea, it does lend itself easily to some aspects of my work, and I've made good use of CLOS in the Common Lisp world. A Clojure counterpart to CLOS would be nice. But, the possibility remains that I simply have not yet figured out how to approach some development tasks in a functional/non-OOP style.

 

200-line-long stack traces are kind of a pain, too.

Runtime performance on android.

having something like rails for beginners would be great

Well, I am not such a great fan of dynamic typing and at this point I am evaluating both Haskell and Clojure.

Better tooling and a better library of knowledge is what Clojure needs right now.  Last survey, I had more to say about the marketing, need for better release management, and killer apps - this year, it looks like many things have been improved, but there still needs to be more polish, and a bit more organization.  And again, I'll refer interested parties to the scala website scala-lang.org for inspiration.  Everything you need is there: examples, links to plugins, research, history, development, news...enterprise gravitas.  As a newbie or manager, there are no unanswered questions on the Scala website.  Their website makes me want to learn scala, which is just...bizarre.

 

There are still multiple sites (Confluence?) for Clojure information. Google groups is still kinda painful compared to other forums. Why not create native installers for various platforms? Why not pick up some of the properties that enhance the Clojure experience such as Clojars, and put them under the clojure.org umbrella?

 

 

 

 

 

The JVM is a performance cancer.

If you don't develop in a disciplined way, you get into bugs which could have been caught by a type system.

Missing code completion hinders me from using java libraries more extensively.

Making libraries easy to find

company/culture acceptance.  People who have never heard of it or people who hear the word 'lisp' or 'lispy' won't even try it.  It keeps it from being more 'mainstream' imho.  It is a catch-22 tho ... the 'lispy' aspect of the language is what makes it amazing and unacceptable to others at the same time.

Editor situation remains problematic, although substantially improved. Excited to see non-JVM runtimes develop

emacs is terrifying

 

Having the language available somewhere other than the JVM.  I realize web is big, but I want to put it in memory constrained embedded environments, and use it for tool development as well.  The JVM and JVM start up time both interfere with that.

I think, all right with Clojure. Keep going, guys!

Same thing as in previous question - lack of easy to use debugger, benchmark and refactoring tools.

Also - emacs+slime as primary development solution. While I love emacs, most newcomeres are not familiar with it, and forcing them to learn emacs and Clojure at the same time is too much for many. Let's hope that Lighttable will solve this problem.

* Parenthesis blindness.

* Lack of a unit testing culture

to little information how ClojureScript interoperates with JavaScript

Minor, finicky points:

 

List of de facto "best" libraries and fragmentation. People write duplicate wrappers, post them to github/clojars. Clojars is too basic.

 

Documented installation.

 

IDE.

* Fuckup inherited from Java, like the missing tail call optimisation.

 

* Not having proper pattern matching just weak destructuring.

* Destructuring of maps is just weird. {:foo 1 :bar 2} is matched by {foo :foo bar :bar} instead of {:foo foo :bar bar}

 

* Most of the time when people need a Lib and there is a Java one they will use that without any kind of wrapper, so you end up with unclonable mutable objects like BufferedImage.

Decent android jvm development implementation.

Getting namespaces right and figuring out how to cross reference different files/functions under my leiningen project was perhaps the biggest practical obstacle for a clojure newbie like me. In general, I see no major problems with Clojure. Naturally the functional paradigm and laziness and other such "weird" things - from the imperative/OOP point-of-view - are challenges for the language  newcomers and adopters.

Deployment.

Lack of killer frameworks and overall community movement compared to something like NodeJS which has caught on like wild fire.

 

Very little resources on Clojure for mobile development also.

Debugging, without a doubt.  Stack traces are oftentimes indiscernable and tools like CDT are pretty rough around the edges when it comes to breakpoints, stepping, continuing in a REPL like Slime.

It's extremely off putting to a beginner.  Examples: The website is sparse, not up to date.  The core docs are very terse and hard to understand.  The stacktraces and error messages are practically incomprehensible.  

 

 

 

 

1.Clojure seems to have overdone it when trying to defy the conventional wisdom (no support for protocol and data inheritance, complecting speed path and abstraction and etc). I still have a love-hate relationship with it (not sure what I gain from the language is worth what I lose) and don't know how many others feel so.

 

2.There seems to be a "everything is so wonderful, nothing is broken", semi-cult like attitude developing. Overenthusiastic community.

I feel it lacks a standardized library platform -> a place which categorically documents and promotes "approved" libraries. People who know enough are free to use whichever library they want, but for those of us who are simply looking to "get the job done", it would be nice to see a list of stable and idiomatic libraries.

I have all 5 books, Emerick and Halloway are the best because they bother to explain a little bit.  You changed away from the 'contrib' lib -- that is fine, but right now you are in the middle of it -- I can wait, but please finish.  I cannot wait for Seesaw with Mig -- the author is great and has some documentation.  I am working hard on learning it, but can someone give him some documentation help?  Probably all libs have the same problem, but you need a GUI so that is a priority for me.

When the clojure.contrib libraries disappeared, the documentation was inconsistent and frustrating.  it may not have been obvious to the core clojure team or people close to that team, but it was confusing as hell for those of us new to the language or more on the periphery. Since a lot of people were using the libraries, my sense from the #clojure IRC channel and my conversations with others was that confusion and misunderstanding were widespread.  People close to the core team, or people really deep in clojure app development, were well aware of what was going on, so didn't need additional documentation.  When I started using clojure, the contrib libraries were documented in the books I bought, and there was nothing in the main github web site to suggest that they were/had gone away.

troubleshooting: debugging, tracebacks, compile errors, etc.  Both in JVM and JS.

Startup time, tooling.

Lack of killer frameworks and overall community movement compared to something like NodeJS which has caught on like wild fire.

 

Very little resources on Clojure for mobile development also.

Tooling is Still weak in comparison to Java. It would be nice if it was more scripting friendly like Groovy

clojure.org (except the Dev part) seems to be "neglected". It does not link to the very helpful clojuredocs.org, it did not have the newest info when 1.3 was out and so on.

exception traces

debugging

low adoption rates

Single-pass compiler with ugly stacktraces as error messages

I miss statement of direction / roadmap.

 

Clojure people now have two great projects (Datomic, ClojureScript). Both projects might have big impact and become killer apps. I see a lot of effort focused on Datomic which makes me wonder about Clojure and especially CLJS development.

 

(please do not get me wrong - David Nolen is making great progress on CLJS and I really would like to see Datomic rock! :)

We need clojure for android!

1.The version skew / documentation problem about libraries.

It's ok for namespaces and API's to change (IMHO), but it is very, very, very

difficult to find which functionality has become part of "Clojure" vs. external libs and

in either case find enough data to evaluate. The elders on #clojure know this

by "oral tradition", but it really needs to be written down (and machine indexable).

 

2. Lack of harmonization in core around leiningen

 

It isn't "easy" when you work with imperative languages most of the time. So basically the Clojure mindset is too different to quickly switch. Of course it has major benefits, but these come at the cost of a long learning period and continuous practice.

Start-up time

Lack of comprehensive debugging environment

Air of being pleased with itself

With Clojure in general - tooling. Although that might change with Light Table.

 

Clojurescript specifically has a very serious problem with documentation and tutorials. Especially ones that bring together Clojurescript interop with Google Closure. I find Google Closure to be very valuable but it's quite an undertaking to get started with it.

 

 

 

 

 

 

 

Getting the attention of developers

Startup time. Ease of (or documentation for) tying scripts into swank or nailgun is a big hole that could be filled with probably little effort. lein-oneoff and lein-exec need updating and speed improvement.

 

Newbies can get confused about existence of old contrib stuff. Needs to show up less/minimally in searches and in docs.

 

Interesting that clojure is the only runtime/compiler on a system for which you can't determine version info (though not necessarily a problem).

 

Would like to have more case studies published about large projects successfully using clojure. Functional skeptics still believe large systems require OOD.

 

Make sure newcomers don't think that Emacs is an important part of clojure.

 

The STM and concurrency story still feel like advanced topics. Anything that can be done (focused, in-your-face, early presented documentation) to make these features feel simple will attract many more to the language.

 

Need a weekly podcast covering news, interviews, and interesting explorations.

 

Need a version of "Land Of Lisp" written in clojure. I know Barski is a clojure fan.

 

I haven't seen many published benchmarks comparing clojure to other languages for common use cases.

 

I think clojure is probably approachable as a first language for kids. Would be nice to see a young learners' resource.

 

One would expect clojure to have a better Android story.

Clojure in Clojure and platform (JVM, ClojureScript) interop and portability. IDE beyond Emacs/Slime.

It starts too slowly for command line apps / utilities (JVM problem)

youth

doco terseness

bosses being risk averse (not clojure's fault of course)

clojurescript producing crappy, humungous JS (should be more neutral like coffeescript, big ask I know)

dynamic typing

youth

doco terseness

bosses being risk averse (not clojure's fault of course)

clojurescript producing crappy, humungous JS (should be more neutral like coffeescript, big ask I know)

Hard (impossible?) to use to develop for mobile devices (I heard of plans regarding Android, but that probably will not be enough to attract a lot of mobile developers).

Difficulty in debugging, e.g. stack trace / dynamic fn hell.

The correct use of 'use' 'import' et al is still a bit confusing...

It needs to outgrow from JVM to standalone implementation in my opinion.

Cryptic error messages and stack traces. General difficultly with debugging.

- small community, not much jobs .

- maturity and recognition of clojure idioms (STM with actors, ref, ... - "in middle states" with laziness ...)

- IDEs are slowly improving but there are a lot of room for improvements there.

The syntax and programming style is unfamiliar to most people. This means that many new comers give up before it clicks. This is why I believe it's very important to have more beginner friendly tutorials, examples, and community support for new comers. Sites like 4clojure and ClojureDocs go a long way in that respect.

The installation/configuration issues for newcomers are being addressed but could still use a lot of attention IMHO. It would be fabulous to have an environment with Clooj's ease of installation/use but more of the features of a full emacs+lein setup. Guidance for newcomers re: libraries and simple example/demo code would also make a big difference for me and for my students.

there is a steep learning curve coming from an imperative programming language background

Lack of established conventions

lack of C interop

It's sometimes difficult to find existing functions in the clojure.core namespace that solve a particular problem unless you can guess what a function does based on its name.  Clojuredocs helps in most cases, but not in all cases.

Native libraries / JNI libraries. Some essential functionality is not found in the JDK, or the Java implementation is sub-optimal in performance. While Common Lisp implementations have non-standardized protocols for communicating with C libraries, it is at least possible with a minimum of fuzz. In Clojure, you depend on JNI, and it is non-trivial/non-obvious to pack and refer to native dependencies in the current build systems. That clojure contrib is only for Clojure code, also leads to native dependencies to be put on Clojars, where you usually find 6 or more different flavors made by just as many individuals. Clojure needs an "official" repo for native deps that "just works". The OpenGL / jOGL library is a prime example.

 

More user-friendly debugging alternatives is also missing. Being able to restart/restore crashes and exceptions in SLIME without confusing macros would be golden. Right now debugging is a println-feast.

 

Take this with a pinch of salt, as I'm a novice both in Clojure and Java. But it's my current opinion even though it might be an ignorant one.

It was hard to get up and running quickly.

No easy "standard" way to wrap a thread pool around futures and/or pmap.

No easy "standard" way to simply farm out processes to other machines.

 

performance

I think the biggest problem to overcome is the image that Lisp like languages have, combined with the (sometimes) hard to understand code that can be written.

Difficult for non-lisp programmers to get started due to lack of "Clojure for new guy" type tutorials or applied example documentation

Too much reliance on Java tools/APIs (maven, log4j, apache httpclient, etc) instead of developing pure clojure solutions; this often results in awkward usage or configuration at the clojure level.

More clear demonstration of why Clojure is better than "X".

--Effective embeddeding within a primarily java app:  Calling java from Clojure is cute, having portions of your enterprise java app embedded in clojure is pure power.  Mechanisms for embedding clojure are clumsy and limited in java/clojure interaction richness.

--Eclipse Counterclockwise REPL is way buggy ... general clojure eclipse intergration needs help. I'm not downloading a stand alone editor just to use the language.

--OSGi clojure jars. Counterclockwise has done this but its near impossible to just extract the clojure api from the counterclockwise usage of it. It would be nice if clojure came packaged as an osgi bundle with java embeddable services ready out of the box.

I'd prefer a better mobile story than ClojureScript. Not saying that ClojureScript isn't awesome, but something like RubyMotion (http://www.rubymotion.com/) would be killer way for Clojure to make its way to mobile.

tools -- IDE, debugging, profiling

A  single go to place for all the performance tricks .. would be very help full. If one   can make the c/c++ integration better it would be very helpfull

There is not enough, and there should be more, sites like webnoir

API documentation is lacking examples and very, very difficult to navigate.

 

For instance, If I am reading about 'reduce' (which I just remembered off the top of my head) then a link to 'comp' would be very helpful, as they are both higher order functions and I might not be sure about which one to use.

 

The documentation is also very generic and assumes you are an expert in functional programming, language like "Applies the functor to the vertices in order" (I made that up) rather than Plain English (tm): "Calls the given function for every element of the sequence, returns a new lazy list of the combined results. Note that you might need to use _doall_ to force the execution for the whole list".

 

The only good thing about the current API documentation is that it shows the source code, which is often the only way to understand what a function does. However that obviously does not work when the source does (. clojure.Internal.stuff).

 

 

This is not exactly about Clojure but it is linked to it: the lack of good materials on functional programming. I guess many people such as myself come from the OOP world. You can find million of books on OOP, only a couple for functional programming. I am currently reading your book which is so far really good but I would like to see more on functional programming concepts. I have heard many good things on"Introduction to Function Programming using Haskell" from Richard Bird. Maybe an idea for your next book? :)  

Exception stack traces (especially when using lambdas, laziness)

Lisp inheritage , which is at the same time  a pro and a con. There are few programmers that even heard of lisp before, not to mention those that actually grasp it to full extent.

IDE integration

Paradigm change

startup time,

port to mobile, performance on small system probably jvm

language jargon though clojure is a high level abstraction language you need to fight through language jargon used to describe much of what makes it clojure.  

Tool and IDE support.  I wish there were a style guide and some best practices around using clojure in larger projects.

Clojure is ahead of its time. I think the Debian Benchmarks (http://shootout.alioth.debian.org/) also cast a bad light on Clojure. If I ever get around to it, I'd like to implement a basic concurrent system in Java and Clojure then compare the performance where Clojure shines. I think Clojure is easier to understand and reason about, but there's no easy way to benchmark that. Perhaps we can push the metric "performance per line of code" or "performance per development time"

Clojure governance- that is, the difficulty in getting even trivial fixes into the language, let alone useful not-so-trivial changes.

 

I feel like the debugging story for Clojure is still a bit weak, though that is mitigated somewhat by the REPL.

Installation and runtime environment, though much better over last year

Same as its greatest strength - it is a lisp, which is just wrong for a lot of developers' brains

I still have some problems with finding good tutorials/documentation/best practices for various topics/libraries but compared to previous years its soooo much better so i think it's just a matter of time. Availability of development environments is also a matter of time - that's just a problem of young language (and counterclockwise which i get's better and better).

Both Clojure and Scala have attracted a lot of attention the past few years. The thing is that more and more people are finding Scala to be faster without any tuning at all. Of course there are clear reasons for that (dynamic vs static typing and reflection) but in general people are finding that it takes a bit more effort to fine-tune their clojure code  in order to get the appropriate performance. This on its own makes senior managers and 'bosses' a bit nervous to make the switch to clojure. Personally I am convinced you can get to almost identical speed with Java & Scala if you're prepared to get down and dirty (in-place mutation and transients)...so far i've not needed anything like that but it is good to know that they are there.

People new to the language find the stacktraces on exceptions off-putting.

As with all open source projects, its the documentation.  The documentation within the core library is good but is definitely written by the developer for people who have their level of understanding.  

 

Within the contrib libraries, its often very minimal with at most a single example to get you started. command-line (or whatever its current name is) is an excellent example.

The fact that it's non-typed makes it difficult to know what data structure you're dealing with, which makes you ended printing debug statements or using the REPL.

Finding errors in your program is to hard.

high barrier to entry with tooling, still. Immutability still conceptually difficult for many new developers, perhaps.

Syntax + IDE + toolchain + JVM start time.

First you need to get over the syntax if you are not familiar with lisp.

If you are not an emacs user finding a tolerable IDE becomes the next challenge.

Once you've settled on editor/ide with minimal syntax support and highlighting you need to fall figure out leiningen

IDE Tooling around Leiningen:  La Clojure should just work with leiningen projects, cutting out the maven pom.xml.  Same goal applies to each IDE.  Eclipse tooling around leiningen is critical for "on-boarding the Stodgy Enterprise" culture.  Emacs-Swank is going well.  I have high hopes for Light Table.  

It is still difficult to get my fellow Java programmers to Lisp Style programming.

It is still difficult to get my fellow Java programmers to Lisp Style programming.

1. Clojure requires knowledge of the Java platform to benefit from its libraries. For this reason Clojure is not suitable as a first or beginner language.

 

2. Getting started is not easy. It took me a year from reading the first Clojure book to actually using the language. In part, because https://clojure.org/getting_started is NOT the way to get started. As a newbie, I lost days trying to get a usable REPL, a working Emacs setup, and coherent classpath everywhere (it worked sometimes, but broke later). It is only by chance that I learned that leiningen solves _all_ these problems. Getting started page should suggest to start using lein right away. I understand it is not the only way to use Clojure, but there should be one simple way to get started.

 

3. Library repositories are not very approachable for non-Java people. 3a) It took me a while to discover that maven central repository exists. 3b) Both MCR and Clojars are great when you know the package name. There are few tools to discover libraries by topic. 3c) Most Clojars releases lack URL of the project or a link to documentation, often older revisions are missing.

 

4. Hard to interface with legacy C and Fortran code.

 

5. Long start prevents from using Clojure as a scripting language in UNIX environment.

Debugging an application is an order of magnitude more difficult/time-consuming than other languages like Python or Java.

Getting the word out seems to be difficult.  Getting old-school Java programmers to embrace the parenthesis.  Not having proper tail-call elimination does alienate some of the base because it is almost expected of functional languages these days.

Effing slow in real life without all sorts of compiler hinting

Lack out out-of-the-box debugging.

Exceptions often hidden (when using SLIME), and usually unhelpful when shown.

As Rich said too, it needs too long time to startup when running up as a stand alone tool.  Huge uberjar size is also a big problem.

 

Documentation that would help to find the right functions/functionality. Clojure docs helps, but would be crazy nice if there would be nice and "official" api documentation that is easy to use (with examples, nice search e.g.)

Documentation suitable for those not familiar with functional programming or locations/availability of existing libraries.

Debugging.

Startup time

Lack of information about successful use in the field; proven advantages over java or scala in the field. Standard cl repl is somewhat user unfriendly.

Employer education.

Clojure's greatest strength is also it's greatest barrier to acceptance into the mainstream corporate IT world - namely, it's LISP syntax (which I personally like quite a bit).  The LISP syntax is to difficult a promote in a world dominated by Java and .Net.

Documentation is severely scattered.  Easy to get new libraries out there, but figuring out what's useful/relevant/supported is very difficult.

 

Toolchain not quite competitive with the best of languages/environments today.

A) Common Lisp disease e.g. "Real programmers use Emacs", "Clojure is for the elite", "Java is for losers".

 

B) Debugging.

 

C) Lack of a *great* lisp IDE.

Very little has changed since last year. I felt like both the strength and the weakness remain the same. Plus I felt the future vision isn't made clear to everyone like it used to be. What is the next big thing in upcoming clojure? Is the current clojure "good enough" as is? Communication can be improved.

better support for aot compilation, mixed java/clojure projects.  Possibly an easy way to compile/reload java classes from the repl.

 

Bringing repl-driven development into existing java codebases might be a cool way to drive adoption

Sadly, not having enough people that know it.

Difficult to interpret exception stack traces

Absence of static code/dataflow analysis (I`d like to see warnings about possible type errors)

 

class path

Stacktraces can be difficult to understand... and often doesn't help at all. The only thing I know for sure is that I got an error.

Debugging becomes running your functions from the inside out until the error occurs and then you look for the error there

Lack of tooling has been by far the highest deterrent factor to newcomers. This is improving with Emacs Live, maturing Counterclockwise and hopefully with Lighttable.

Dynamic language needs a lots of test units. It should be static typed lang with type inffering just like in scala.

The language is beautiful except deftype/defrecord does not allow a good enough code reuse.

Debugging tools, Unhelpful error messages

Its association with Lisp makes it a tougher sell to organisations, although it is making some headway.

 

Functional programming takes a while to get used to, if coming from OO/Java ... more step-by-step tutorials from experienced Clojure developers would be helpful.

Incomprehensible and incomplete error messages. Something goes wrong, and you waste a lot of time tracking it down. Like, a precondition fails and you have no idea what datum tripped it. Or can't make a keyword out of a sequence (or etc etc) and it gives no clue what the sequence in question might have been.  

Lck of IDE integration and poor android performance

Lack of a full stack web framework with an robust and easy to understand authentication and authorization library. Why is Ring the only game in town? I would use Clojure instead of Rails if I could figure out Friend, if Sandbar wasn't so freakin' old, and if someone could show me non-trivial implementations. See the Rails Omniauth and Devise as a reference on how to explain authentication to journeyman software developers.

 

Nobody is doing a Clojure Railscast or Codeschool-type product offering.

Tracebacks are unreadable, which can make it a pain to debug a piece of code you're having problems with.

JRE startup time - I would use it more for shell scripts etc if it wasn't for that.

Clojure Errors/StackTraces are not helpful. This is a bad / daunting experience for newcomers to the language. Same for Clojurescript x 10. It's not a very interesting area to work on but the benefits for adoption would be great IMHO

It is far from a mainstream

A mature comprehensive Rails-like web framework

Lack of an "official" way to do platform integration that works over multiple platforms.

E.g. selecting different function implementations depending on config values, ...

 

An official way is needed in order to provide a homogenous interface to config values

real world implementations examples