The standards doc on the wiki here:
http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards
Makes this recommendation:
"Idiomatic code uses destructuring a lot. However, you should only
destructure in the arg list if you want to communicate the
substructure as part of the caller
On Aug 7, 5:43 am, Peter Schuller wrote:
> Interesting. Why do you consider it recommended to read one character
> at a time in a case like this? Maybe there is such a recommendation
> that I don't know about, but in general I would consider it contrary
> to expected practice when doing I/O if per
Any chance of getting this in before 1.2?
On Jun 25, 7:43 am, cageface wrote:
> Thanks Stuart & Peter for following up on this. Now I can get back to
> plowing through this mountain of ldiff data with Clojure!
--
You received this message because you are subscribed to the Goo
On Jun 30, 5:15 pm, Chas Emerick wrote:
> An oldie-but-goodie post from Chouser talking about what clojure-in-
> clojure is and why it matters:
>
> http://blog.n01se.net/?p=41
To quote:
"But a more fascinating benefit is that porting Clojure to non-JVM
targets will be much easier. The majority of
My clj file looks like this:
#!/bin/sh
export CLASSPATH=$CLOJUREPATH:./lib/*:.:$CLASSPATH
if [ -z "$1" ]; then
exec java -server jline.ConsoleRunner clojure.main
else
SCRIPT=$(dirname $1)
export CLASSPATH=$SCRIPT/*:$SCRIPT:$CLASSPATH
exec java -server clojure.main "$1" "$@"
fi
H
On Jun 30, 10:17 am, Sean Allen wrote:
> The larger the clojure community gets, the more you should be prepared
> for those dogs then.
To put it more bluntly - the day that clojure no longer interoperates
smoothly with java is the day it becomes useless to me. I'm all for
hiding the guts from beg
On Jun 29, 10:50 pm, Sean Allen wrote:
> So those who left Java behind years ago but like Lisps in general and Clojure
> in particular and want to minimize their contact with Java, where do
> they fit in your view?
> Enemies of the proper use of Clojure? Destroyers of the future?
Dogs barking up
On Jun 29, 8:17 pm, Michael Richter wrote:
> A good salesman also doesn't come across as smugly self-satisfied and
> projecting a sense of superiority.
I did a moderate amount of CL hacking in 2003-4 and I've been dipping
my toes back in lately with Clojure but I hardly count as a "lisp
weenie".
Let's rephrase this slightly. I completely agree with the spirit of
this article:
http://programmingzen.com/2008/10/26/what-arc-should-learn-from-ruby/
i.e. - That the tipping point for any language into wide use occurs
when it makes it significantly easier to solve a common, but painful
problem.
On Jun 29, 6:25 pm, Michael Richter wrote:
> Are you *trying* to evoke the "Smug Lisp Weenie" vibe, cageface, or is this
> just a natural byproduct of being a burgeoning Smug Clojure Weenie?
How many times do I have to say I'm in favor of making things as easy
as possible
On Jun 29, 7:24 pm, Chas Emerick wrote:
> More talking up the complexity of Clojure, to its detriment. Stop
> it. Familiarity is not a metric that anyone is aiming at, least of
> all the language principals -- capability in various axes is, and
> that's what's attracting people from all si
On Jun 29, 12:54 pm, Chas Emerick wrote:
> Indeed, there are many nontrivial personas that actively wish for a
> smaller (or at least not maximally large), more exclusive community.
Only a fool would actively wish for a smaller community. Some of just
recognize that selling a sports car to gr
On Jun 29, 1:22 pm, Chas Emerick wrote:
> Any talk about how Clojure might be "too much" for some, for whatever
> reason, is out of bounds IMO. Clojure, as a language, is *simpler*
> than just about all of the popular alternatives out there, and the
> language is eminently approachable and
On Jun 28, 9:39 pm, Brent Millare wrote:
> While I agree his wording wasn't really the best, I think it can also
> be interpreted differently depending on what kind of n00b he is
> talking about.
For the record, "noob" was not my choice of terms. Like any other
profession, programming attracts pe
On Jun 28, 9:14 pm, Michael Richter wrote:
> Ah. The Clojure community has already started down the road to Common
> Lisp-style, smugness-generated obscurity and disdain. Bravo! Well-played!
Not at all. Nothing would make me happier than "Clojure for Dummies"
and Wrox Professional Clojure book
Several people have suggested that usage examples in the docs would be
helpful and this is something I often find myself wishing for. Are
patches introducing examples welcomed by the core team?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post t
On Jun 28, 3:04 pm, Mike Meyer wrote:
> What you're calling "The LISP way" I first met under the name
> "bottom-up programming" - the only real difference is that LISP lets
> you muck about with what is syntax in other languages - except you
> pretty much have to stay with S-expressions in LISP (b
On Jun 28, 2:44 pm, Daniel Gagnon wrote:
> > 1. you don't have to worry about PYTHONPATH for a while with a
> > standard install, although the day will come
> No, you never have to.It's taken care of by virtualenv.
Maybe it's just me but I think virtualenv is far more intimidating
than getting a
On Jun 28, 2:26 pm, Brian Hurt wrote:
> I'd argue that it's a bad idea to teach students a "professionals" language
> as their first language. You don't learn to fly in a 747, even if that's
> what the professionals fly. There are reasons for this.
I have to agree with this. I wouldn't dream of
On Jun 28, 12:16 pm, Martin DeMello wrote:
> It depends. I found the concepts pretty easy, since I have done a lot
> of functional programming, but when I was new to clojure I had a truly
> horrible time figuring out the various classpath issues needed to get
> things working.
What is it about th
On Jun 28, 1:10 pm, Mike Meyer wrote:
> Not true as I understand "the Lisp way". You also need to reread the
> last paragraph again.
I actually agree with you that the typical block of lisp code is less
readable than the typical block of python. It bugs me when lisp
advocates present s-expr synta
On Jun 28, 12:25 pm, Daniel Gagnon wrote:
> I believe that the success of ruby is due in great part to *Why's Poignant
> Guide to Ruby* and *Learn You a Haskell* is doing the same for Haskell. It's
> fun to read, it holds your hand in setting up everything you have to and it
> makes you want to le
On Jun 28, 12:04 pm, Mike Meyer wrote:
> The Python approach leads to more readable
> code:http://www.mired.org/home/mwm/papers/readability.html
You don't seem to be very sympathetic to the Lisp way of doing things.
What's your interest in Clojure?
--
You received this message because you are
As I said in the HN thread, I think you're right that getting started
with a productive clojure environment is harder than it has to be.
However, as I also said in the thread, I think the *real* obstacles
for a noobie are the concepts in the language itself. Clojure is very
elegantly designed, but
On Jun 28, 11:09 am, Daniel Gagnon wrote:
> That feature would *not* be a simple macro. It isn't simply a call to .close
> on whatever object, it's an arbitrary cleanup procedure on any object that
> implements the feature. The whole standard library implements it and objects
> know how to clean a
I haven't done any Erlang coding but I have heard various complaints
in blogs etc that Erlang isn't great for string handling.
Is that what you mean? Is Erlang a good or bad example of this?
On Jun 27, 1:11 pm, Timothy Baldridge wrote:
> "1. a string/text type"
>
> *cough * Erlang *cough *
>
> T
On Jun 27, 1:17 pm, Mike Meyer wrote:
> Not quite - it's to keep the language *readable*. And if there's a use
> case for a feature that outweighs the damage done by abusing it,
> they'll add it. Witness with, list comprehensions, and those
> never-to-sufficiently-cursed augmented assignment opera
Python definitely seems to be the product of a very different design
philosophy than Lisp. I've always felt it was too prescriptive.
Omitting features that *might* be misused in an effort to keep the
language simple seems to have backfired on them. Too keep up with the
competition they've had to ad
When I read about new "features" in other languages that would be
simple macros in Lisp I just have to smile:
http://docs.python.org/dev/reference/compound_stmts.html#with
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send ema
Thanks Stuart & Peter for following up on this. Now I can get back to
plowing through this mountain of ldiff data with Clojure!
--
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 pos
I put a self-contained test up here:
http://gist.github.com/452095
To run it copy this to slurptest.clj and run these commands
java clojure.main slurptest.clj makewords 100 (100 seems good for
macs, 300 for linux)
java -Xmx3G -Xms3G clojure.main slurptest.clj slurp|
slurp2
Trying either slurp or
Has anyone else had a chance to try this? I'm surprised to see manual
buffering behaving so much better than the BufferedReader
implementation but it does seem to make quite a difference.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
Interesting. Here are the times I get:
LINUX:
slurp, *in* 18.8 seconds
slurp, System/in 18.2 seconds
slurp2, *in* 6.7 seconds
slurp2, System/in 5.7 seconds
I have an intel iMac here too, running 10.6.4:
slurp, *in* 20.4 seconds
slurp, System.in 19.0 seconds
slurp2, *in* 7.2 seconds
slurp2, System
It looks like it's having trouble figuring out if "test#1.log" is a
file path or a URI.
Not sure what a real solution is but this seems to work as a
workaround:
(clojure.xml/parse (java.io.File. "test#1.log"))
On Jun 23, 12:30 pm, Zak Wilson wrote:
> (clojure.xml/parse "test1.log")
> works cor
Another example. I'm running this on a Ubuntu 10.04 laptop with this
java:
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
and this command line:
java -Xmx3G -server clojure.main cat2.clj
(require '[clo
Sure. Here's my clj script:
#!/bin/sh
if [ -z "$1" ]; then
exec java -server jline.ConsoleRunner clojure.main
else
SCRIPT=$(dirname $1)
export CLASSPATH=$SCRIPT/*:$SCRIPT:$CLASSPATH
exec java -Xmx3G -server clojure.main "$1" "$@"
fi
(Usually I don't have the -Xmx flag there. I add
For the record, this program runs in 3.3 seconds so I guess that
points to the implementation of slurp:
(import '[java.io BufferedReader InputStreamReader])
(let [reader (BufferedReader. (InputStreamReader. System/in))
file-data (StringBuffer.)
buffer (char-array 4096)]
(loop [total
Not sure if this is a clojure issue or a something else but I'm seeing
surprisingly slow I/O on large text files.
For example, on a unix machine try this:
1. create a large file
rm -f words; for x in $(seq 300); do cat /usr/share/dict/words >>
words; done
2. create a clj file that just slurps it
I think I'm going to take this route. The style seems pretty common in
clojure contrib and it's readable, if a bit odd at first.
On Jun 22, 2:20 pm, David Powell wrote:
> I tend to write the condition and action on separate lines, and put a
> blank comment in between each, like this:
--
You rec
This looks nice but requires more hand-indenting, right? I really like
being able to select a block in emacs and hit indent-region and get
predictably tidy code. (The failure of emacs to do this 100% with
scala code is a pet peeve).
On Jun 22, 1:50 pm, Michael Gardner wrote:
> Try this:
>
> (defn
This is fine when you just have simple clauses like this, but what if
the clauses are more complex, even containing subclauses?
A quick scan through clojure contrib suggest that people are inserting
blank lines between clauses when they get more complex. I guess this
is idiomatic for clojure?
On
Picky syntax question:
In common lisp cond requires more parenthesization than clojure:
(cond
((evenp a) a);if a is even return a
((> a 7) (/ a 2));else if a is bigger than 7 return a/2
((< a 5) (- a 1));else if a is smaller than 5 return a-1
(t 17))
vs clojure:
(con
Maybe it's only because I'm coming from Ruby, in which number
promotion is automatic and everything is slow, but if I have to choose
between correctness and performance as a *default*, I'll choose
correctness every time. I think there's a good reason that GCC, for
instance, makes you push the compi
Quick disclaimer - there are a lot of things I like in Scala and I
think Odersky & crew have done some very impressive work bringing
functional language concepts to the VM and giving Java developers a
path forward. I also don't think Clojure vs x language battles are
very productive and don't want
On Mar 23, 11:09 am, Michael Kohl wrote:
> http://github.com/citizen428/ClojureX/archives/1.1.0
>
> Sorry, really not trying to pitch my project here, but the archive
> above basically contains what you are asking for.
Cool. Maybe we could link this and/or Stuart's labrepl from the
getting starte
So perhaps it would be worthwhile to create, like jruby, a single zip/
tgz file containing clojure, clojure-contrib, and a reasonable bin/clj
file that will find at least the core clojure jar files on its own? I
don't see how you're going to actually deploy any clojure apps, or
connect to a databas
On Mar 22, 2:48 pm, Sean Devlin wrote:
> There are a ton of people who are ready for dabbling with Clojure but
> aren't ready for production systems. You'd be surprised how linearly
> independent system administration skills and software development
> skills really are. They aren't quite orthogo
I'll certainly agree that it should be as easy as possible to get
started in Clojure, but I really don't think that the kind of people
that can't use anything without a windows installer are going to get
very far with Clojure in any case.
I mean, if it's too much to install java, unzip a file and
What a strange reason to dismiss Clojure. And also strange to refuse
any further input.
--
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 - plea
So will deftype/protocol be the recommended, idiomatic way to
implement ADTs in Clojure 1.2? Will the current map/struct based
approaches essentially be deprecated?
The doc here http://www.assembla.com/wiki/show/clojure/Datatypes
suggested to me that they were more for interfacing with Java in a
m
That was it. I was fixated on the ResultSet object and didn't consider
overloading. Adding the (int) hint sped things up considerably.
Thanks!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.c
I'm trying to eliminate some reflection overhead in little SQL utility
I'm working on and can't seem to get the type hint right for this
code:
(import 'java.sql.ResultSet)
(set! *warn-on-reflection* true)
(defn rs-get-row [#^ResultSet rs]
(if (.next rs)
(let [cols (.. rs getMetaData getCol
On Mar 9, 12:09 am, Meikel Brandmeyer wrote:
> How about this?
>
> (defn leafs
> ...
This should be leaves, not leafs, right? Another one of those weird
irregular English plurals.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this gro
On Mar 8, 12:47 pm, Richard Newman wrote:
> Interesting reading from 2006:
>
> http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns...
Yeah I was just reading that this weekend actually.
To be clear, I'm not knocking the verb-oriented approach. I guess I
just think it's interest
On Mar 8, 11:48 am, Raoul Duke wrote:
> uh, hey, wait a second, please note that is about type checking, not
> about OO vs. FP!
Yeah I'm not talking about OO vs FP but about the function-centric
approach that Lisps and languages like Haskell take as opposed to the
object, or noun-centric approach
The one potential downside I've seen to the function-oriented approach
is that you often wind up encoding the argument type in the function
name.
For example, if I write a library to manipulate SQL databases I might
write a lot of functions that start with db- and resultset- and
statement- etc. So
I've been reading about some of the clever things Scala does to allow
safer monkeypatching and this started me thinking about Clojure's
approach to this technique. Maybe I'm overlooking something but is
this just a non-issue in Clojure? Since functions aren't attached to
objects it seems to me you
Takes 15 seconds on my i7 laptop. Gotta love it.
--
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
On Mar 4, 7:21 am, Stuart Halloway wrote:
> Preferred is
>
> (require '[clojure.contrib.string :as str])
That's an easy solution. Thanks.
--
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
N
On Mar 3, 11:03 pm, Meikel Brandmeyer wrote:
> Almost correct:
>
> (use '[clojure.contrib.string :exclude (repeat)])
That did it. Thanks!
I finally had to do this to get the whole package to load:
user=> (use '[clojure.contrib.string :exclude (repeat butlast reverse
get partition drop take)])
I
In trying to build compojure with the git MASTER versions of clojure &
contrib I ran into this error:
Clojure 1.2.0-master-SNAPSHOT
user=> (use 'clojure.contrib.string)
java.lang.IllegalStateException: repeat already refers to:
#'clojure.core/repeat in namespace: user (NO_SOURCE_FILE:0)
So I figu
On Mar 3, 2:05 pm, Jarkko Oranen wrote:
> Well, it seems to me that the "universal interface" is the sequence.
> Turns out many things can be represented as sequences. :) And since
> maps are just collections of key/value pairs, very generic code can be
> written to process them, too. As long as t
I've been reading through the examples of "OO" in clojure using multi-
methods and they certainly seem very flexible and powerful. I'm
wondering, however, how people handle interface & library design. If
people can implement "objects" as maps, structs, or just about
anything else you can discrimina
63 matches
Mail list logo
