> I'd like to convince some Python developers that Clojure is not
> foreign and does many things better than Python. I'd appreciate
> whatever suggestions you have about what I've written.
>
> Though I am crazy about STM and Clojure agents, I don't deal with
> them here. This has to be a gentle introduction rather than a
> thorough survey of Clojure, so I've left out other language
> features, too.
It's certainly a comprehensive survey of parallel impls of various
patterns. I've no idea how effective it'll be, not being a python
programmer (any more!), but it's worth a shot.
One thing did trouble me, though:
> Define a capturer object that can do two things: capture something,
> and return everything it's captured so far.
>
> [Clojure]
>
> (defn create-capturer []
> (let [captured (atom #{})]
> {:capture (fn [x] (swap! captured conj x))
> :get-all-captured (fn [] (deref captured))}))
I know you're trying to draw parallels, but I think this goes too far
in trying to write python (or java) in clojure, especially given
immutable data structures. All you need are #{x} to create a
'capturer', (conj c x) to add a new item to it, and c to get the set
of things captured so far. I know you know that, but presenting the
above doesn't seem to do anyone any favors since it's absolutely not
idiomatic.
Alternatively, if you feel like you must approach a direct corollary,
this is a little better IMO (I cringe a little at poor-man's closure-
methods :-):
(defn capture
([x] (atom #{x}))
([c x] (do
(swap! c conj x)
c)))
And of course, @c will get you the set of captured objects.
- Chas
Or Python 3.x:
print("Hello, world")
> A list (in Clojure, a vector) of three integers.
>
> [Clojure]
>
> [1 2 3]
This can also be written in Clojure as [1, 2, 3]. Commas are
considered whitespace.
> A hash-map.
>
> [Clojure]
>
> {0 false 1 true}
This can, as above, be written with commas if preferred:
{0 false, 1 true}
--
Michael Wood <esio...@gmail.com>
Read the contents of a file.
[Clojure]
(slurp filename)
[Python]
open(filename, 'r').read() # who cares about closing files opened in read-mode?
CPython will close the underlying file when its handle is garbage
collection. The collection itself will be prompt and deterministic due
to CPython's use of reference counting for GC. You shouldn't have a
problem, even in a tight loop.
Jython, on the other hand, ... uses Java's GC, which has many
advantages of Python's 70's style reference counter, but being
deterministic isn't one of them.
Incidentally, Python 2.6 provides something akin to Clojure's with-open macro:
with open( "somefile", "rb" ) as aFile:
do_something_with_contents_of(aFile)
// BEn
> [Python]
>
> open(filename, 'r').read() # who cares about closing files opened in
> read-mode?
>
> "who cares about closing files opened in read-mode" ?
>
> I would say anybody concerned about blowing up the underlying OS if
> not releasing files handles (especially if you open files in a tight
> loop), or do I miss something ?
In this particular case, there is no reason to worry: open() returns a
file object that is fed to the method read(), but after that method
returns, there is no more reference to the object, so it is garbage
collected. Upon destruction of the file object, Python closes the
file. All that is documented behaviour in Python, so it is safe to
rely on it.
It is another question if relying on a list of reasonable but not
evident behaviours is good style. Personally, I don't use such
constructs in library code, but I do in scripts for personal use.
In Clojure, I would be much more careful because I know the Java
libraries less well than the Python libraries. Which illustrates that
"good style" also depends on someone's experience.
Konrad.
Being primarily a Python programmer, I can say that the first thing my
On Aug 30, 2:24 am, Dan Fichter <daniel.fich...@gmail.com> wrote:
> The Clojure version is more concise and radically safer but a little more
> conceptually packed. Is it worth your trouble?
co-workers would say is that Clojure isn't as readable as Python is.
In this particular case, there is no reason to worry: open() returns a
file object that is fed to the method read(), but after that method
returns, there is no more reference to the object, so it is garbage
collected. Upon destruction of the file object, Python closes the
file. All that is documented behaviour in Python, so it is safe to
rely on it.
If I recall correctly (and correct me if I'm wrong), Python uses a reference counting garbage collector. Which means as soon as the reference to the object goes away, the object gets collected and the handle closed. Most JVMs use some form of mark & sweep algorithm, which means it may be some time before the object gets collected (and the resource freed). This is especially the case in a generational GC system, where long-lived objects get collected much less frequently. So, for long-running programs, it's possible to pile up uncollected resources to the point where you run out of the resource, simply because unused objects haven't been collected yet.
Generally, when you open a file descriptor, you should always make sure it's gets closed when you're done with it.
On Sun, Aug 30, 2009 at 9:31 AM, Jason Baker <amno...@gmail.com> wrote:On Aug 30, 2:24 am, Dan Fichter <daniel.fich...@gmail.com> wrote:Being primarily a Python programmer, I can say that the first thing my
> The Clojure version is more concise and radically safer but a little more
> conceptually packed. Is it worth your trouble?
co-workers would say is that Clojure isn't as readable as Python is.
Any language you are familiar and comfortable with is going to seem much more readable and much more intuitive than a language you are unfamiliar with. Even similarity to English presupposes a familiarity with and comfort with English- something most people on this planet don't have. A native English speaker would find a programming language whose syntax was based on, say, Mandarin or Swahili, very "unintuitive".
The point here is that arguing in favor of a new language on the basis of intuitiveness and readability is a losing argument.