Hi Saul, Thanks for the suggestions. I should say that I was only giving you my impression of using Clojure re: it's version number. I'm not saying any of the things I listed are not doable, just that they feel very ad-hoc and not quite ready for a "2.0".
I come from the Ruby world, and Ruby isn't even a 2.0, so my perspective is definitely colored. > - definitive, simple, integrated package management > Leiningen and Cake? I use leiningen and cljr for package management, depending on whether I'm working on a discrete project or on a script/quick hack/toy program. These tools are great, and I don't want to diminish the amount of effort that's gone into them. However, the whole process of getting package management working is a barrier to entry to Clojure. Getting package management up and running requires too many steps. I think that Clojure should come with a default executable that can take care of package management and start a REPL (loading all global packages into the classpath). Integrating leiningen into Clojure packages would give this definitive experience that new users are looking for when they try to get up and running. > > - a better REPL experience out of the box (esp. Jline support) > Slime/Emacs? I only use the REPL in very rare cases and aren't > bothered by a lack of JLine. > > - a simpler, more useful stack trace Slime? Three problems with the REPL: 1. The standard way Clojure tells me to get a REPL is using the java command. This makes Clojure not feel like a first-class language. 2. Once I do get a REPL, either through the java or lein or cljr commands, it has no indentation or Jline support. It feels messy. 3. I use Vim, so Emacs/Slime isn't really something I want to do. (And I don't want to have to use a specific editor in order to use the language of my choice.) > - better commandline integration > > https://github.com/gar3thjon3s/clargon I'll give this a look. In general, I think we need a way to write Clojure scripts so that they are directly executable (perhaps via a shebang directive at the top of our script). > > - abstracting away Java concepts like excessive hierarchies for package > > definitions (src/com/mycompany/wow/this/is/getting/long/my-library.clj) > > You don't have to use this convention. Personally I keep things > shallow. > You're right, but a lot of people do (even clojure.contrib does), which makes browsing Clojure source code feel rough. > > - better discovery for existing, well-tested libraries. > > You can search on http://clojars.org/. This works well for me. > However, the key to well tested libraries is having people give > feedback if a library breaks or is badly documented or doesn't meet > their needs. > To me, Clojars is not the most discoverable interface in the world, though I do appreciate that it exists. It doesn't have download counts or any other sort of quality indicator. What's more, some entries are domain-qualified and others aren't, and it's hard to know exactly what I'm getting when I install any package from Clojars. Side question (also relating to the ecosystem feeling rough), what's with all the "SNAPSHOT"s on Clojars? As I say, I really enjoy coding in Clojure, but the process surrounding coding is not always very polished. I see too much Java and not quite enough integration to think of it as a "2.0" yet, though I do think we can get there. I'm open-minded about this take, though. Maybe I just don't have a solid enough setup on my machine yet. (But should it really take that much effort?) David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
