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
Post by Rich HickeyAs we rapidly approach 500 members on the group (!) I thought it would
What are you doing with Clojure?
What 3 features would you most like to see added next?
Thanks,
Rich