I'm actually building a production application with it for the company where I work, which is quite exciting. (Until my permission to do so gets revoked, of course). That's also why I'll no doubt be spamming the list with so many questions :p
The application will be of the server-side message dispatch variety, being the controller piece between a bunch of incoming and outgoing messages and protocols that 'do things' (UI eents, payment processes, turning on/off services, etc etc) I haven't yet used the language enough for me to consider my own 'wishlist' of any merit, since I have so many newbie-obstacles to overcome (but am just now getting to the point where I can actually get stuff done). I will send some items later though as they occur to me and seem decent. There is a real advantage to working on a real project, in that it makes you need to do real things, whether the tools are there or not. Two things that do stand out to me still are: 1) Lack of good 'newbie' information. (This isn't really what you asked for, nor do I need it as much now as I did) This isn't a knock against the language of course, but will hinder its general acceptance. In particular I've found that while the learning curve for understanding the basic ideas is low, the curve for actually doing stuff in practice is steep. There are many subtle nuances that have to be understood, and many things you initially try to do are the 'wrong way' etc. And I was a lisp lover *before* I started. Once you make it through this initial period it really starts to click, but I'm afraid many would-be newcomers will quit after struggling to get parenthesis just right or seeing a cryptic error. 2) Any advances in the error handling / reporting would be greatly beneficial. Sometimes you see in the nasty stacktrace the actual 'problem' or 'clojure line of text' that is the culprit, but many times you do not. This can be kept in check with super-incremental development, which is a good idea anyway, because you just know that the last 'whatever u did' broke it, regardless of what it says. But I would suggest in general better means to tie error messages to actual errors in clojure text, though I realize that is probably quite difficult to do. Some *possibilities* for new language features (not necessarily my top list): 1. Not a good way to READ from a string, I hit this as working on an REPL loop that feeds from a stream. In particular this would be needed if you wanted to do some string parsing / alteration BEFORE the EVAL (for example, adding the parenthesis automatically to the edges). I agree working with the data structures directly as opposed to strings is better when possible, but when the data is dynamic and incoming you dont have that option. But I realize this has been brought up before, and also you could read from a reader from a string, etc. On a similar note, I suspect being able to convert between data structures and string representations of those structures, might allow for some neat unanticipated tricks to be performed. This just seems to be a natural & easy thing to provide since the language is already reflective and dynamic by nature. 2. Would there be any need for more reflective type operations? Like 'what file am I in' (which I would have already used, but just as a reload-convenience feature), or perhaps 'what higher level functions am I in', etc. I haven't really hit a need for these yet, and I suspect the lispy nature of it all already mitigates this a bit, but again seems like it might be easy to provide. 3. I'm curious about several of the cool lispy things that did NOT make it in, though I understand some of these have been discussed already, and there are good reasons or jvm obstacles for it. In particular I am thinking of the lisp error handling retry stuff, and continuations (we dont have those, right?). I have personal experience with neither, however, so can't comment much. Also, aren't there several types of macros in lisp, reader macros, and others? You said something about the read table not being accessible in the api docs, so naturally that made me wonder what cool things could be done if it were.. 4. I also wonder if there will be language problems as applications scale larger, with many different files and namespaces. I've noticed functions can only refer to those previously defined, so you couldnt have 2 that depend on one another. Again, unsure if this is needed, but it stood out to me. Also it seems I need to specifically load each file from other files, as opposed to some sort of directory / package mechanism. I'm wondering how that will scale on a large project, and what about the case where multiple files each have the same dependent, etc, like C++ includes. 5. On a minor note, and in a recent thread posting, I hit the case of needing to specifically bind and re-set the namespace because i was doing an EVAL in a separate thread. It seems a default of retaining the default namespace that the EVAL and thread expressions are in would be more convenient. Afterall, I never explicitly changed my namespace, and was writing functions in a file that specified a given namespace. I was quite surprised that by simply 'adding a thread' stuff quit working. Of course I decided I did really want the separate thread eval to be a different namespace afterall, so maybe it's not a big deal. You could add a namespace argument (maybe defaulting to current) to EVAL, in fact I wrote a function for my application is essentially that. Hope some of this helps --n On Sep 10, 2:40 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > As we rapidly approach 500 members on the group (!) I thought it would > be a good time to conduct another poll: > > What are you doing with Clojure? > > What 3 features would you most like to see added next? > > Thanks, > > Rich --~--~---------~--~----~------------~-------~--~----~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
