#clojure log - Aug 29 2008

The Joy of Clojure
Main Clojure site
Google Group
List of all logged dates

7:38 parth_m: Hello. I just started using clojure.contrib. I have basically added clojure-contrib.jar to the classpath. Just wanted to check it thats the recommended way of doing things. Seems to be working fine.


9:16 cemerick: rhickey: you said earlier this week you were looking (or planning on looking) at the >18 arguments issue I posted about; any ideas there? I ask only because it looks like the netbeans profiler is choking on that bytecode...

9:17 rhickey: cemerick: have you gotten the NB profiler to profile Clojure code at all?

9:19 cemerick: I was trying just a moment ago (not to profile clojure code specifically -- just an app that happens to have some clojure stuff floating around at the periphery). It's pretty unsuccessful -- an exception occurs with roughly the same message as what I posted.

9:19 rhickey: cemerick: Ok

9:19 was focusing on getting lib in first - that's done

9:20 cemerick: Sure, absolutely.

9:27 hoeck: rhickey: built-in lib support rocks, just on par with cl's defpackage and a bit of asdf :)

9:28 rhickey: hoeck: thanks to Steve Gilardi et al

9:28 hoeck: did you ever post the print multimethod?

9:29 hoeck: no, sorry, will do so as soon as i'm home from work

9:39 Chouser: The "requir" exception last night got me thinking -- I think it'd better if the :keywords and functions for ns had exactly the same name.

9:40 The declarative sense of "uses" and "requires" is nice, but if it's good enough for the ns keywords then I think we should use it for the function names too.

9:42 having ns do English grammar transforms on users' code seems like a bad idea. Rails does that and I don't think it turned out well.

9:59 rhickey: what do you think. Are you dead-set on leaving it how it is now?

10:00 rhickey: Chouser: why/when would you use the functions now?

10:01 Chouser: also, there is a difference in that one set are macros and the other needs quoted data

10:01 I had thought about changing the function names to the more declarative ones

10:01 Chouser: I don't plan to use the functions, but my main concern is the attempt to compute English grammar within the API

10:02 rhickey: I don't understand

10:02 Chouser: ...and the fact that that makes the public API less simple with little benefit.

10:03 the ns macro programmatically converts :requires to 'require and :uses to 'use.

10:03 I guess it's lucky there's not a 'try that needs to be computed from :tries

10:03 rhickey: Chouser: that's an implementation detail

10:04 could just as easily be a map

10:05 Chouser: yes, but it's exposed in the public API of providing the keywords and the functions, and in the stack traces produced when you forget (understandably) to use the present-perferct form form because you're inside the ns call.

10:06 it seems like complexity (in the programmers head and in the ns implementation) with very little benefit.

10:07 rhickey: Chouser: I understand and am not strenuously opposed, but you are speaking from the perspective of one who has been using the functions a la carte. For instance, you get alias from using :as

10:07 but I wouldn't call alias as nor :as :alias

10:07 Chouser: I understand, and if the a la carte functions were made private, I think my argument would be much weaker.

10:08 rhickey: My thinking was - the new method would be to use ns. Everything is declarative and the names are good...

10:09 then, at the repl you need to reload something, seems weird to call (requires ...)

10:11 so, if unified, the keywords would be :use, :import, :require - I'd be ok with that. But there's still the difference in API - quoted vs not, that make them incompatible - the bigge issue last night wasn't requir, it was the quoted data in :requires

10:11 Chouser: I can certainly see how we arrived here, and in a vacuum I'd probably prefer (requires ...), but with the existance and eventual prevalence of :requires, I think having (require ...) is actually more confusing.

10:11 rhickey: I would really like to discourage use of the functions in source

10:11 to the extent of saying tools will only analyze ns declarations

10:13 Chouser: well, I've lodged my complaint and I think you understand my argument.

10:13 Maybe I'm extra-skittesh on this one because of how far Rails took it

10:14 ...and what a poor choice that now seems to be (although I'm surprised how few complaints I hear about it).

10:14 rhickey: anyone else? on the table is changing :uses/:imports/:requires to :use/:import/:require in the ns macro

10:14 what is the Rails problem?

10:15 Chouser: they do it everywhere. The prominent example is that class names are generated from table names, but are converted from plural to singular along the way.

10:15 A table named customer-entries is handled by a class named CustomerEntry

10:16 rhickey: that's pretty common ORM I think, ORM being awful in the first place

10:17 Chouser: well, you'd better be sure your understanding of the rules of English grammar are exactly the same as Rails', or you're going to have trouble. ...and grep is suddenly much less useful.

10:17 anyway, as I said I don't actually hear people complain about it, but having written my one big Rails app, it seems like a big ol' waste.

10:18 rhickey: I understand, but the problem is in the approach to data as much as the names

10:18 I'm ok with :use/:require/:import

10:18 Chouser: clearly the (ns) issue is smaller because you're in complete control of both ends (both the ns API and the underlying functions).

10:25 rhickey: changed :requires/:uses/:imports in ns macro to :require/:use/:import

10:26 cemerick: FWIW, +1 on that

10:28 Chouser: what I hear from my Ruby colleagues is that, once you're past some initial prototyping stage, using the autogenerated stuff is a no-go (due to database performance issues)

10:31 rhickey: ORM is a bad idea

10:31 OODB is a bad idea

10:33 Chouser: cemerick: I think that's actually a separate issue. Even if you don't use the tool-generated code, the underlying ORM still uses that computed name mapping. I think. ;-)

10:34 cemerick: I'm completely not a ruby programmer, but from what I've heard, high-volume sites end up dropping the ORM entirely.

10:34 or, the automated ORM, to be precise -- one ends up specifying mappings between columns and attributes, etc.

10:35 Chouser: oh, wow. huh.

10:35 well, I'm apparently not a rails programmer either, then. :-) Ruby was probably my favorite language pre-clojure.

10:41 cemerick: keep in mind, that's not much more than rumor -- just what I hear from friends :-)

11:33 DrewR: cemerick: High volume sites end up dropping Rails, not just ORM. :-)

11:34 Having written a few highish-volume Rails sites I can officially say all the convenience it affords makes you yell profanity later.

11:35 Ruby is a difficult framework language.

11:36 It's great when you're building a framework because it's flexible, but it sucks when someone else needs to reverse engineer.

11:36 And because the abstractions usually leak in very bad ways, you always have to do the latter.

11:37 It's what drove me back to Python. What a clear, modular language.

11:37 Clojure is well on its way there and I'm excited.

11:40 Anyway, all that said, I vote for unambiguity in ns. :-)

11:40 ...which it looks like rhickey just checked in.

11:41 rhickey: drewr: yup

11:43 it's weird to be over 1000 checkins...

11:43 DrewR: Congratulations.

11:44 I'm really impressed you stuck with this for so many years.

12:32 ozzilee: Is anyone working an an http library for Clojure? The amount of code needed to issue a PUT in Java is ludicrous.

12:32 Chouser: from the client side?

12:34 ozzilee: Chouser: Yeah.

12:38 Chouser: http://groups.google.com/group/clojure/browse_thread/thread/f696552b40aa95da/0ff01dbe3b318cae

12:39 I haven't tried that out, but I remembered it being mentioned.

12:40 ozzilee: Hmm, I'll take a look.

12:40 I'm trying the apache commons httpclient right now, might be ok.

12:40 Chouser: sure

13:11 abrooks: Wow, I've been using FoxMarks for 10 minutes and already have 42 backup IDs (revisions).

13:11 This seems a bit excessive.

13:11 I don't think I've made that many changes.

13:11 er.... wrong channel.

13:11 * abrooks needs less allergies.

13:29 abrooks: sf.net is getting slower and slower it seems. I just pulled the entire clojure mercurial mirror in 7 seconds. It takes as much as twice (somtimes even more) that long to do most operations that involve the Subversion server. (Although it takes only 2.5 seconds to do a noop svn update.)

15:06 notyouravgjoel: is there any clojure OO implementation, or is it most common to do oo stuff in Java?

15:07 also, do clojure ints have a max size, or will they automatically become bigint-like things?

15:13 DrewR: notyouravgjoel: As a functional language, Clojure doesn't support the OO paradigm.

15:14 Arguably you can create much better abstractions.

15:15 notyouravgjoel: well, what about a struct system, then?

15:15 DrewR: To your second question, they grow automatically.

15:15 user> (* 99999 99999999999999999999)

15:15 9999899999999999999900001

15:15 Yep, it's got structs and generic functions.

15:15 notyouravgjoel: fun fun

15:16 ugh, poor xchat for windows

15:16 kotarak: notyouravgjoel: struct + multimethods are probably more flexible than the average OO system in <yourfavoriteOOlanghere>.

15:17 notyouravgjoel: I believe it

15:25 what about using random standard java things, such as hibernate?

15:38 achim_p: notyouravgjoel: you can create new java object instances and call methods on them, and you can define your own via proxy: http://clojure.org/java_interop

15:55 notyouravgjoel: thanks for the answers =)

15:57 one last thing: I'm thinking of writing a web bot in clojure, which will basically behave like a browser, parse web pages, and do actions based on the content. Any advice/sensible libraries/considerations?

16:06 fyuryu: notyouravgjoel: check out HttpUnit

16:09 notyouravgjoel: thanks =)

16:15 hoeck: notyouravgjoel: there is also http-client.clj in the files section of the google group

16:46 abrooks: rhickey: Are things all set for your Sept. 29th Boston Lispers talk?

16:47 rhickey: Yes

16:47 abrooks: Very cool. If the current plans stick, I'll be there. What's the topic?

16:49 rhickey: It will be about the Lisp nature of Clojure, Clojure as a Lisp, why I wrote a new Lisp etc

16:49 I can presume the audience knows Lisp, and dig in a bit more

16:50 kotarak: will the slides or video be available afterwards?

16:50 rhickey: kotarak: If it's a good talk :)

16:51 kotarak: rhickey: it will be. :) No doubt.

16:52 rhickey: I've been thinking about doing an online study group on something like yugma: http://www.yugma.com/

16:53 the talks I give are limited to being overviews/introductions

16:53 kotarak: That would be nice. I know Webex from work.

16:54 rhickey: would people be willing to 'meet' regularly for a study group?

16:54 I guess time zones would be an issue

16:54 kotarak: Most likely.

16:57 How much does yugma cost? I know our local solution work to be quite expensive.... But that's for a company. There everything is twice the price.

17:00 rhickey: kotarak: I think it's free for ad-hoc sessions of 10 people, full-featured is $10/10, $30/30 $70/100 per month

17:02 kotarak: rhickey: o.O That's nice. Our service charges per minute and participant.

17:03 abrooks: There's some features (such as whiteb