Can Clojure be as readable as Python or Ruby ?
Leon Talbot
Thanks !
Angel Java Lopez
If so, how ?
Thanks !
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Angel Java Lopez
Timothy Baldridge
>>
I think Python may be easier for you, but it's not simpler than
Clojure. Simplicity is the strength of Clojure.
http://www.infoq.com/presentations/Simple-Made-Easy
I can learn a new syntax almost overnight (last night I started
writing Dart code for the first time after googling the syntax for 15
min), but the power of macros, immutable data, and laziness are what
really makes Clojure stand out.
Timothy
--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)
Aaron Cohen
Isn't it already?
Jeff Heon
I've only moderate experience with Clojure, but the following example
from Open Dylan made me realize I really do prefer a concise
representation over what is considered easier to read.
http://opendylan.org/documentation/intro-dylan/why-dylan.html#functional-languages
define method shoe-size (person :: <string>)
if (person = "Larry")
14
else
11
end if
end method;
Versus
http://opendylan.org/documentation/intro-dylan/why-dylan.html#algebraic-infix-syntax
(define (shoe-size person)
(if (equal? person "Joe")
14
11))
Albeit my preference could be different over a different example.
Silly humans 8)
The thing is, if you just keep using Clojure or another Lisp for a
little while, you'll probably get used to it and find it comfortable.
James Sofra
I have recently started working in python, I don't find python very readable at all compared to clojure.
It is more about familiarity than anything else.
Alex Baranosky
Alan Malloy
Mark Engelberg
I think that the real question that is: if you know Python and Clojure equally well, then which is easier to read?Alex
I know both equally well (actually, I've logged more hours in my life coding in Lisp syntax than other syntaxes), and I still consider Python to be significantly easier to read.
A few specific things that hinder Clojure's readability in my opinion:
* prefix notation for arithmetic operators defies centuries of mathematical notation conventions and consequently any mathematical formula will be less readable.
* introducing variables creates new indenting level, making code "creep to the right"
* as code creeps to the right, you need to have a lot more newlines (for example, between each input to a function) to get it to fit on the page. This lengthens the code block making less fit on a page, and also makes the code look a lot different than the exact same code would look if it were appearing in a place that were less indented.
* The convention of using hyphens to separate words is hard to read (since - looks like the minus operator) and also takes up more width than camel case, contributing to the problem that you quickly find lines getting too wide and needing to be broken up.
* loop/recur is significantly less readable than either the corresponding looping constructs in Python or the named let that Scheme offers, *especially* when you have some sort of nested looping going on, which is extraordinarily difficult to read in Clojure.
* cond branches are sometimes written with the test and the answer on the same line, or when the test gets too long you have to write it with the test and answer on subsequent lines; this inconsistent formatting can make it hard to know in long blocks whether you are looking at the test or the answer
* Interweavings of cond and let (a common pattern) end up ridiculously indented and hard to read [Grand's flatter cond macro helps with this; I'd love to see this brought into Clojure core]
* Decades worth of classic algorithms involving imperative manipulation of arrays look significantly uglier in Clojure, because Clojure intentionally makes imperative manipulation more difficult. I have, for fun, converted many Knuth algorithms to Clojure, and they invariably are far less scrutable than the original.
* Expression-oriented syntax (along with the indenting cost of using let) encourages people to pack far too much into one line rather than giving names to intermediate results.
* DSLs are supposed to bring customized readable notation to many tasks, but by the time you include namespace prefixes and colons for all the keywords, DSLs don't really look that good. I mean, compare Frinj to Frink. Frinj's integration into Clojure is cool, but is there anyone who considers it even half as readable as Frink? I certainly don't.
* I feel really clever when I condense some complex loop into some sort of map/filter/reduce using anonymous functions. And it looks brilliant when I read my own code that does this. But when I read someone else's compact higher-order stuff, it's usually a nightmare to try to interpret what it is doing. Python's loops may be verbose, but I always know exactly what I'm looking at when I read someone else's code.
* And the number 1 problem with all Lisps is that when you look at Lisp code, it's a sea of sameness. Function applications, Macros, Control constructs, bindings, data lookups, etc. all look exactly the same. You look at Python code, and you instantly see the control flow of the code, the assignments, the tests, the results, the loops, the data, the data lookups, the breaks. It's organized, but visually distinct.
I write code in Clojure because I find the semantics appealing, and I feel I can get more done in less time than a language like Python. "Code as data" might be nice for writing macros, but the reality is that it forces programmers to code in an abstract syntax tree which is more computer friendly than human friendly. If I were given the option to *read* a sample program illustrating some concept in any language of my choice, I would choose Python over Clojure in a heartbeat.
All one man's opinion, of course, but I wanted to bring it up because I am someone who has logged many years working in Clojure and related Lisp languages and I still have the opinion that Python is the most readable language I have encountered.
Joachim De Beule
Thanks!
Mark Engelberg
Please define "readable".
Thanks!
"Readable" is a measure of how readily apparent the meaning of a program is from looking at it.
If you wanted to measure this objectively, one possible way to do this would be to time how long it takes a group of programmers to read and understand a well-crafted program to perform some complex algorithm. Let's assume that the programmers are all competent in the language being measured. There are other things you might also measure: you could quiz them to determine if they really understand it as well as they think they do, you could ask them to modify the code, you could ask them to self-rate their subjective sense of how easy it was to understand the program.
Tim Daly has opined several times that it would be nice if researchers would do something like this for literate programming, for example. It would be useful to know for sure whether programs in literate form are more readable than ordinary "self-documenting" code.
We tend to think of readability as a fairly subjective thing, and it is subjective to the extent that for most of us, the only measure that matters is how long we personally feel it takes us to understand code written in a given language, and how much effort we have to expend to gain that understanding. But certainly it is a quantifiable concept, and it is theoretically possible to compare languages, code coloring schemes, documentation styles, pop-up support, and all other aspects of code readability in an objective way.
Mark Engelberg
(let x 2)
code
would behave like the current:
(let [x 2]
code)
Andy Fingerhut
Mark Engelberg
You might have a difficult time getting other Clojure coders to adopt the practice in their code, but would this be almost as good?(let [x 2]code)Achieving that would be as simple as hand-indenting it that way, or adjusting the auto-indenter of your favorite text editor to do it that way. A couple of minutes of perusing clojure-mode.el for emacs didn't make it obvious to me how to do that, but I suspect it wouldn't be difficult.Andy
It's an interesting question as to how much of my psychological objection to let is the added nesting versus the physical indenting. I agree it would be a worthwhile experiment to adjust the auto-indenter for a while and see how it feels.
In the meantime, I *strongly urge* everyone to check out Grand's flatter cond macro:
https://github.com/cgrand/parsley/blob/master/src/net/cgrand/parsley/util.clj
It lets you insert lets in the middle of cond expressions (like you can currently do with for) like:
(cond
(pos? x) 2
:let [y (* x x)]
(> y 20) 4))
This totally transformed my coding style and improved the readability of my code substantially. Highly recommended. Since it is backwards compatible, I very much wish it were part of the core, and see no reason that it couldn't be.
--Mark
Sean Corfield
> * introducing variables creates new indenting level, making code "creep to
> the right"
Mitigated by breaking functions into sub-functions (which is good
practice anyway).
> * as code creeps to the right, you need to have a lot more newlines
Then your code is too deeply nested and should be broken into
sub-functions. That's standard best practice across all languages.
> * The convention of using hyphens to separate words is hard to read
I disagree. I find camelCase far harder to read than hyphenated-names.
> * loop/recur is significantly less readable
I don't think it's "significantly" less readable but I do agree that
recur is a bit of a wart.
> * cond branches are sometimes written with the test and the answer on the
> same line, or when the test gets too long you have to write it with the test
> and answer on subsequent lines; this inconsistent formatting can make it
> hard to know in long blocks whether you are looking at the test or the
> answer
Don't write long blocks. Don't write complex conditions. Introduction
more sub-functions.
> * Interweavings of cond and let (a common pattern) end up ridiculously
> indented and hard to read
See above (and I don't agree it's a "common" pattern... perhaps an
anti-pattern?).
> * Decades worth of classic algorithms involving imperative manipulation of
> arrays look significantly uglier in Clojure
Yet many algorithms are significantly cleaner in a pure functional style...
> * Expression-oriented syntax (along with the indenting cost of using let)
> encourages people to pack far too much into one line rather than giving
> names to intermediate results.
Again, poor style. Break things into sub-functions.
> * DSLs are supposed to bring customized readable notation to many tasks, but
> by the time you include namespace prefixes and colons for all the keywords,
> DSLs don't really look that good.
Then those DSLs are not achieving their design goals. DSLs are a good
use case for :use or :require/:refer.
> * ... But when I read someone else's compact
> higher-order stuff, it's usually a nightmare to try to interpret what it is
> doing.
Really? I find the compaction outweighs the effort involved - as long
as the code is modular enough (see comments above).
> * And the number 1 problem with all Lisps is that when you look at Lisp
> code, it's a sea of sameness. Function applications, Macros, Control
> constructs, bindings, data lookups, etc. all look exactly the same.
I actually find that to be a plus - there's no distracting variance
that artificially makes things "different" that don't need to be.
Syntax is very subjective. It's really good to here your pro-Python
thoughts tho'...
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Mark Engelberg
I agree that breaking things into smaller functions can potentially help. Often, though, I find that a function begins by unpacking and computing a large number of values that are all important for subsequent computations. Dispatching these computations to helper functions would mean passing an unwieldy number of variables. One option is to have the helper functions inside the main function, inside the scope of these bound variables so that they don't have to be passed explicitly. But this potentially means several levels of nesting to bind the variables to their appropriate values (possibly testing for nil and other such conditions before computing further values), and then yet another level of nesting to create the helper functions (possibly with letfn, which is poorly indented by most of the IDEs last I checked). In such scenarios, decomposing into inner helper functions might actually exacerbate the problem of deeply nested and therefore highly indented code.
It would be interesting to run a scan of public Clojure code to get a sense for the average nesting level, indenting level, and the average line width. I'd be curious as to how far off the norm my own code is, and how Clojure compares to other languages.
Nicolas
points really help. Most counter arguments here resume to "you are
doing it wrong" and "all clojure 'warts' are here to force you to
better design".
Indeed some kind of code is more readable when written in an
imperative way than functional way. Like some kind of code is more
readable when written in a functional way. This depend what kind of
code you want/need to write and that a strong point for supporting
both style in same language.
Clojure try to avoid imperative code style... Honestly I’m not sure if
avoiding all imperative code is a good idea or not... I need more
experience in clojure and lisp like language to have a good opinion on
that point. But anyway I enjoy clojure as it is today.
Mark, I would say using a few well designed macros you can make
clojure feel a lot more like you want to. That would be interesting to
see and experiment on.
Have a nice day, all!
Nicolas.
On 8 mar, 08:37, Sean Corfield <seancorfi...@gmail.com> wrote:
Mark Engelberg
I actually find that to be a plus - there's no distracting variance
that artificially makes things "different" that don't need to be.
I just thought of an amusing analogy. To me, reading Lisp takes more mental effort in the same way that it takes more mental effort to follow someone who is speaking in monotone (precisely because there is "no distracting variance").
The main reason I spoke up was because of the comment in the thread suggesting that readability is purely a function of what kind of syntax you are most used to seeing. Many people tend to assume that if you don't like the way Lisp looks, you just haven't been using it long enough. I wanted to offer a counterexample, as someone who has spent over 20 years reading Lispy code. I prefer to *write* Clojure, but I prefer to *read* Python.
If I can find a language that I enjoy reading as much as I enjoy writing, that would be nirvana. That's why the original post for this thread caught my eye, and struck me as worthy of discussion. I know Rich has mentioned that he admires Python's concision, so it seems reasonable to compare and contrast their readability.
It is worth noting that Clojure does have several things that elevate it over other Scheme/Lisps in terms of readability. The use of [] for vectors and {} for maps is a huge help. The ability to add commas anywhere you want is nice. The removal of extra parens from let is nice (I'm less keen on the removal of extra parens from cond because of the awkwardness that results when the test and answer are too big to fit on the same line). Short names for most of the built-in functions are also nice.
Mark Engelberg
I’m not sure that just adding counter responses to almost all Mark
points really help. Most counter arguments here resume to "you are
doing it wrong" and "all clojure 'warts' are here to force you to
better design".
Looking back at my initial email, I can see that it probably came across as a bit of a rant, and probably not as constructive a response as I had intended it to be. I understand where Sean is coming from with his point-by-point.
djh
On Wednesday, March 7, 2012 5:39:08 PM UTC, Leon Talbot wrote:
If so, how ?
Thanks !
Stuart Halloway
Looking back at my initial email, I can see that it probably came across as a bit of a rant, and probably not as constructive a response as I had intended it to be. I understand where Sean is coming from with his point-by-point.
Evan Gamble
lets you insert conditionals in your lets (vs. your suggestion of
inserting lets in conds).
I wrote a let? macro that does that: https://github.com/egamble/let-else
- Evan
On Mar 7, 10:51 pm, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> In the meantime, I *strongly urge* everyone to check out Grand's flatter
Sean Corfield
> Looking back at my initial email, I can see that it probably came across as
> a bit of a rant, and probably not as constructive a response as I had
> intended it to be.
No, I thought it was an interesting set of observations but, like Stu,
I disagree on many points. As noted, syntax is definitely subjective.
Ruby makes my skin crawl but I can't really put my finger on why (it
feels like punctuation has been used for cryptic semantics - but I
don't react to some other languages against which I could level that
criticism). If I was doing heavy numeric computations, I'd probably
find the prefix syntax in Lisp annoying, so I suspect your problem
domain has a lot to do with your feelings about a language too.
> I understand where Sean is coming from with his
> point-by-point.
Most of my comments would be true of code in other languages (and
Scala came to mind, specifically, as I was suggesting breaking code
into smaller units to aid readability). I'm interested in hearing more
about the sort of functions that begin "by unpacking and computing a
large number of values that are all important for subsequent
computations". I'm not seeing this in my code so I assume we're
working on very different problem domains - could you elaborate?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Laurent PETIT
Your discussion made me think that editors may help further in this area, without having to change the syntax.
Currently, the editors only try to give some "hints" by playing with colors, but there are some other ideas that could be followed:
- playing with contrast by also using the ability to change the fonts
- playing with contrast by slowly decreasing the font's opacity as the code gets deeper (but where the cursor is, this should probably go away to ensure good visibility) => could help see the overall structure without seeing to much of the details?
- playing with "proximity" by adjusting the line sizes. For example, there could be extra space around the "true" and "false" clauses of an if, there could be extra space around "condition/then" clauses of a cond, etc.
- playing with the background color of blocks, potentially minimizing (and to some extend -in a modal structural editor- almost removing from sight) the parens
- since it's not the same thing to "write/edit" and to "read" code, there could be the possibility to have a "read" mode where the editor could represent totally differently the source code (think it could even present it in some sort of prefix-notation :-) )
Phil Hagelberg
> Most of my comments would be true of code in other languages (and
> Scala came to mind, specifically, as I was suggesting breaking code
> into smaller units to aid readability). I'm interested in hearing more
> about the sort of functions that begin "by unpacking and computing a
> large number of values that are all important for subsequent
> computations". I'm not seeing this in my code so I assume we're
> working on very different problem domains - could you elaborate?
I see this every so often, but it's usually easy to solve with partial.
(defn write-jar [project out-file filespecs]
(let [manifest (make-manifest project)]
(with-open [jar-os (-> out-file
(FileOutputStream.)
(BufferedOutputStream.)
(JarOutputStream. manifest))]
(doseq [filespec filespecs]
[HUGE GLOB OF CODE THAT USES project AND out-file]))))
The doseq call needed to be converted to a reduce so it could accumulate
some state, but the big glob of code to be extracted needed access to
the `project` and `out-file` locals. Reducing with a partially-applied
function makes this work nicely:
(defn write-jar [project out-file filespecs]
(let [manifest (make-manifest project)]
(with-open [jar-os (-> out-file
(FileOutputStream.)
(BufferedOutputStream.)
(JarOutputStream. manifest))]
(reduce (partial copy-to-jar project jar-os) #{} filespecs))))
Just a thought. I can see where Mark is coming from, but I don't think
the workaround is particularly difficult or onerous.
-Phil
Leon Talbot
Moritz Ulrich
>> * The convention of using hyphens to separate words is hard to read
>
> I disagree. I find camelCase far harder to read than hyphenated-names.
I'm pretty sure there is an Emacs mode for displaying foo-bar-baz as
fooBarBaz and reversed.
--
Moritz Ulrich
Tassilo Horn
>>> * The convention of using hyphens to separate words is hard to read
>>
>> I disagree. I find camelCase far harder to read than
>> hyphenated-names.
>
> I'm pretty sure there is an Emacs mode for displaying foo-bar-baz as
> fooBarBaz and reversed.
There's glasses-mode for displaying CamelCase as Camel_Case, Camel-Case,
or whatever you like. Not sure if there's a mode that does the reverse.
Bye,
Tassilo
evandi
Evan Gamble
let, but I often find myself writing a series of nested lets, when-
lets, if-lets, etc. to handle the exceptional cases in lets. A
contrived example:
(when-let [a foo]
(let [b bar]
(when (even? b)
(let [c baz]
(when (> b c)
(let [d qux]
(f a b c d)))))))
becomes:
(let? [a foo :else nil
b bar :is even?
c baz :when (> b c)
d qux]
(f a b c d))
Mark Engelberg
That would work for replacing a single cond surrounded by a single
let, but I often find myself writing a series of nested lets, when-
lets, if-lets, etc. to handle the exceptional cases in lets. A
contrived example:
(when-let [a foo]
(let [b bar]
(when (even? b)
(let [c baz]
(when (> b c)
(let [d qux]
(f a b c d)))))))
becomes:
(let? [a foo :else nil
b bar :is even?
c baz :when (> b c)
d qux]
(f a b c d))
Right, I do run across this sort of nesting on a regular basis, and that's the kind of thing that that bothers me. With the cond macro, it would look like:
(cond
:when-let [a foo]
:let [b bar]
:when (even? b)
:let [c baz]
:when (> b z)
:let [d gux]
(f a b c d))
Mark Engelberg
You should probably both share gists of real code you're talking about, shouldn't you ?
Most of the stuff I'm working on is closed-source. Offhand, I'm not sure what examples I can share, but I'll keep an eye out for that.
In the meantime, just to get a feel for whether this is unique to my code or universal, I decided that I was going to carefully scrutinize the nesting level of the next public Clojure code I encountered. Completely randomly, the next Clojure code I encountered was this blog post:
http://blog.japila.pl/2012/03/block-scanner-from-let-over-lambda-in-clojure
Take a look at how indented the code is after merely 10 lines of code. We start to take this for granted in Clojure, but if you look at it with a fresh eye, it really is ridiculous.
Your discussion made me think that editors may help further in this area, without having to change the syntax.
Currently, the editors only try to give some "hints" by playing with colors, but there are some other ideas that could be followed:
- playing with contrast by also using the ability to change the fonts
- playing with contrast by slowly decreasing the font's opacity as the code gets deeper (but where the cursor is, this should probably go away to ensure good visibility) => could help see the overall structure without seeing to much of the details?
- playing with "proximity" by adjusting the line sizes. For example, there could be extra space around the "true" and "false" clauses of an if, there could be extra space around "condition/then" clauses of a cond, etc.
- playing with the background color of blocks, potentially minimizing (and to some extend -in a modal structural editor- almost removing from sight) the parens
- since it's not the same thing to "write/edit" and to "read" code, there could be the possibility to have a "read" mode where the editor could represent totally differently the source code (think it could even present it in some sort of prefix-notation :-) )
I love these ideas. I think your final comment is especially insightful. I have no problem writing Clojure code, I just find it unnecessarily taxing to read it. The idea of separating the two, and possibly having a read-mode is an absolutely fascinating idea. In some sense, Marginalia is already a good positive step in this direction. The first time I ran Marginalia on my code I was astonished at how much more readable it was to have the comments in a separate column alongside the code, rather than interrupting the code itself. It makes me wonder how many other things could have such a positive, dramatic effect.
Mark Engelberg
I'm interested in hearing more
about the sort of functions that begin "by unpacking and computing a
large number of values that are all important for subsequentcomputations". I'm not seeing this in my code so I assume we're
working on very different problem domains - could you elaborate?
I can't show my closed-source code, but I'll try to elaborate to give you an idea where I'm coming from.
I'm working with trees where the nodes can have a lot of attributes associated with them. I represent the nodes as maps like
{:tag ____
:data ____
:children ____
:attribute1 ___
:attribute2 ___}
When working with a tree node, not only do I have to destructure/unpack a lot of these attributes, but often, there are several "measurements" I need, which are computationally intensive because computing those measurements generally involves walking the tree.
Not all nodes have all the attributes, so there is a fair amount of testing as I'm destructuring and computing these measurements to make sure I'm doing the right thing. I use multimethods, dispatching on :tag, to handle certain types of context-sensitive behavior, but that alone doesn't handle all the dynamic combinations of attributes that can occur.
If the helper function is external to the main function, that becomes a lot of stuff that needs to be passed along and immediately destructured at the other end.
Meikel Brandmeyer (kotarak)
Am Freitag, 9. März 2012 03:12:52 UTC+1 schrieb puzzler:
(cond
:when-let [a foo]
:let [b bar]
:when (even? b)
:let [c baz]
:when (> b z)
:let [d gux]
(f a b c d))
I wonder how long it will take until someone proposes monads.
(domonad
[a foo]
[b bar]
:when (even? b)
:when (> b z)
(f a b c d))
Just a thought.
Sincerely
Meikel
Tassilo Horn
Hi Mark,
> In the meantime, just to get a feel for whether this is unique to my code
> or universal, I decided that I was going to carefully scrutinize the
> nesting level of the next public Clojure code I encountered. Completely
> randomly, the next Clojure code I encountered was this blog post:
> http://blog.japila.pl/2012/03/block-scanner-from-let-over-lambda-in-clojure
>
> Take a look at how indented the code is after merely 10 lines of code. We
> start to take this for granted in Clojure, but if you look at it with a
> fresh eye, it really is ridiculous.
In some book (I think some Common Lisp book), I've read that code
leaning to the right is a pretty good indicator for code written in a
functional style. If it's straight top-down, then it's probably more
imperative with one outer let and setf-ing of that let's variables.
That said, of course there's nothing wrong with macros like the cond
with :let or the let? in this thread. They look really useful, and I
think I have some spots in my code where I could make use of them.
Bye,
Tassilo
Daniel Jomphe
I love these ideas. I think your final comment is especially insightful. I have no problem writing Clojure code, I just find it unnecessarily taxing to read it. The idea of separating the two, and possibly having a read-mode is an absolutely fascinating idea. In some sense, Marginalia is already a good positive step in this direction. The first time I ran Marginalia on my code I was astonished at how much more readable it was to have the comments in a separate column alongside the code, rather than interrupting the code itself. It makes me wonder how many other things could have such a positive, dramatic effect.
Jason Lewis
This has been a fascinating discussion, thanks to everyone involved.
I do kind of feel like complaining about indentation in Clojure is like complaining that Ruby has too many parentheses ( shut up, they're optional!).
I still feel like a big part of 'readability' comes down to personal preference. Python is often the canonical example of a readable language, but I find significant whitespace offensive, and other 'features' just terribly limiting. I spend most of my time coding in Ruby, which is very readable (for me), but I enjoy reading and writing Clojure equally well, if not more.
One side-effect of Clojure's 'difficulty', for me at least, is being forced to think harder. This is a good thing. Homoiconicity was never a feature geared toward easiness, but rather power and simplicity.
Anyhow, thanks for this discussion. I've enjoyed it.
Jason
Timothy Baldridge
So I've been lurking on this thread for some time, and thought I'd go
and offer my two cents on the topic. While writing clojure-py, I've
been in the unique situation of having to decide which language
features will be implemented in Clojure and which will be implemented
in Python. For example, deftype is not a compiler feature in
clojure-py it is actually big macro that ends up calling the python
internal functions to create types.
My viewpoint is that, in general, Clojure and python are equal in
their "readability" on a feature to feature basis. That is, define
feature A in both Clojure and Python and you'll find that it will take
you about the same amount of time to grasp what is being done in both
implementations. The difference is that it normally takes 1/2 the
number of lines of code to do something in Clojure than it does in
Python. In other words, Clojure is more terse, and hence more dense
than Python.
So I think the question of readability I think it really comes down to
the programmer making sure that he considers what future readers of
his code will think. For example, this is perfectly valid Python, and
something I see fairly often in other people's Python code:
print [(x, y, x * y) for x in (0,1,2,3) for y in (0,1,2,3) if x < y]
But personally I consider this sort of code unacceptable.
Instead I tend to write Python code thusly:
for x in (0,1,2,3):
for y in (0,1,2,3):
if x < y:
print (x, y, x*y)
It looks cleaner and is much easier to understand.
In Clojure we have the power to reach the middle-ground:
(print (for [x [0 1 2 3]
y [0 1 2 3]
:when (< x y)]
[x y (*x y)]))
Here we get the get the "expression" style of the first Python
example, with the code structure of the second python example, and at
the same time end up with less indents/linewidth than either Python
example.
This is the reason why the majority of clojure-py is written in
clojure and not python.
Timothy
Konrad Hinsen
> (when-let [a foo]
> (let [b bar]
> (when (even? b)
> (let [c baz]
> (when (> b c)
> (let [d qux]
> (f a b c d)))))))
>
> becomes:
>
> (let? [a foo :else nil
> b bar :is even?
> c baz :when (> b c)
> d qux]
> (f a b c d))
For yet another take on this, consider using the maybe-m monad from
clojure.algo.monads:
(domonad maybe-m
[a foo
b bar
:when (even? b)
c baz
:when (> b c)
d qux]
(f a b c d))
This is not 100% equivalent because any nil result in the binding list
will terminate the whole expression and return nil. That's quite often
the right thing to do. If not, there is a way to introduce bindings
that are allowed to be nil:
(domonad maybe-m
[a foo
b bar
:when (even? b)
c baz
:when (> b c)
:let [d qux]]
(f a b c d))
Konrad.
Konrad Hinsen
> For example, this is perfectly valid Python, and something I see
> fairly often in other people's Python code:
>
> print [(x, y, x * y) for x in (0,1,2,3) for y in (0,1,2,3) if x < y]
>
> But personally I consider this sort of code unacceptable.
>
> Instead I tend to write Python code thusly:
>
> for x in (0,1,2,3):
> for y in (0,1,2,3):
> if x < y:
> print (x, y, x*y)
How about this (my preferred version):
print [(x, y, x * y)
for x in (0,1,2,3)
for y in (0,1,2,3)
if x < y]
I prefer this especially when the result is used in a computation,
rather than printed. It removes the need to initialize some variable
to an empty list and then appending to it.
Konrad.
Craig Brozefsky
> (let? [a foo :else nil
> b bar :is even?
> c baz :when (> b c)
> d qux]
> (f a b c d))
Macros like that just make your code so much LESS readable. I now have
to understand the semantics of a bunch of keywords specific to the
macro, their order of operations within the macro, as well as
recognizing the little ? on the end of the let as I'm scanning. I also
have to see if that's a keyword or the start of another binding!
:else nil? really?
:is ... Geezus christ
:when !?!?! Put down that nailgun, kid
;; This maintains the same logic (unless I fucked up transcoding)
;; and also the same err, complexity, in that forms are not exeuted if
;; they don't need to be, as your initial example, without nesting all
;; the way over to the side, or using some weird keyword language.
(when-let [a foo]
(let [b bar
c (when (even? b) baz)]
(when (and c (> b c))
(f a b c qux))))
;; or
(when-let [a foo]
(let [b bar
c (when (even? b) baz)
d (when (and c (> b c)) qux)]
(when d (f a b c d))))
Keep your constructs simple, and learn to love the nil.
Also, people have been writing lisp for a real long time, and they
haven't invented a chucklehead macro like let? yet, so prolly not really
needed to improve the readability...
--
Craig Brozefsky <cr...@red-bean.com>
Premature reification is the root of all evil
Tassilo Horn
Hi Craig,
> Also, people have been writing lisp for a real long time, and they
> haven't invented a chucklehead macro like let? yet, so prolly not
> really needed to improve the readability...
They have invented `loop' and `format'. ;-)
SCNR,
Tassilo
Evan Gamble
training necessary to read it, but not a lot. Probably no more than
the keyword clauses of the "for" comprehension. The argument that
decades of Lisp programmers haven't invented this particular
"chucklehead" macro is a bit weak, since there have been many other
similar macros.
...and I have learned to love nil, even the :else nil clause that
repels you.
- Evan
On Mar 9, 9:26 am, Craig Brozefsky <cr...@red-bean.com> wrote:
daly
> I find let? useful and readable, as do others. There's a bit of brain-
> training necessary to read it, but not a lot. Probably no more than
> the keyword clauses of the "for" comprehension. The argument that
> decades of Lisp programmers haven't invented this particular
> "chucklehead" macro is a bit weak, since there have been many other
> similar macros.
>
> ...and I have learned to love nil, even the :else nil clause that
> repels you.
There is a bit of brain-training necessary to read code with
parens but not a lot. In fact, my editor can read paren code.
The let? syntax breaks code walkers.
The let? syntax breaks pretty printers.
The let? syntax "complexes" read.
See the loop package in Common Lisp.
Some people swear by it, others swear at it.
The idea isn't new.
If you want "readable code" write a literate program.
Literate programs communicate from person to person rather
than having the person "decode" your idea from the code.
If you understand the idea, any syntax is easy to read.
Tim Daly
Craig Brozefsky
Yah know, I was thinking of those as I wrote that, and I figured they
actually would stand as supporting evidence for my quip 8^)
Nicolas
If you use standard constructs and I'am proeficient with clojure I'll
understand your code fast. I'll concentrate on understanding your code
relevant for your application and domain. But just adding a few new
constructs specific to ypur libr can make code really complex to read,
even to experimented clojurians.
That the power of macros (or even functions). Abstract things away.
But you also need to know the function/macro. And if it is not
standard, we end up with many different version of let? depending of
the library, author...
By all means I'm not against let? macro or
Nicolas
So I'am not against let? macro of whatever you might need. That why we
have a lisp here. But be sure you really need it/use it. And it is
designed to be intuitive as possible.
Mark Engelberg
Craig Brozefsky
> I find let? useful and readable, as do others. There's a bit of brain-
> training necessary to read it, but not a lot. Probably no more than
> the keyword clauses of the "for" comprehension. The argument that
> decades of Lisp programmers haven't invented this particular
> "chucklehead" macro is a bit weak, since there have been many other
> similar macros.
Sure, you feel your defmacro, oats you write some ghetto macros with
syntactically significant keywords, maybe stay up late a few nights
expanding it into a some monstrosity and suddenly you have loop (I don't
think CL's format is in the same realm actually). It works for you, you
dig it, mazel tov. God knows I've written worse by far.
> ...and I have learned to love nil, even the :else nil clause that
> repels you.
The idea of and explicit :else nil, in a situation where the negation of
the logical operation is implicitely nil, just stinks in my nose.
Seriously though, don't let my aesthetic griping stop you from rocking
out whatever kinda clojure code tickles your brain.
Evan Gamble
On Mar 9, 11:13 am, daly <d...@axiom-developer.org> wrote:
> There is a bit of brain-training necessary to read code with
> parens but not a lot. In fact, my editor can read paren code.
can't read code with parens. I've been writing Lisp since 1983,
starting with Lisp Machines, before CL was designed. I have no
difficulty reading highly parenthesized, nested code.
I wrote let? to scratch a very specific itch. I often found myself
writing what amounted to a series of let bindings, where some or all
of the bindings had assertions associated with them that would stop
further binding if the assertions failed. Conceptually, that pattern
really feels like it should be a single let form, but in practice it
has to be implemented with a bunch of nested lets, when-lets, if-lets,
etc. So let? allowed me to write code for that pattern as the single
let that it wanted to be.
I wanted a single let form for that pattern for exactly the same
reason that we have the convenient form:
(let [a foo
b bar]
...)
instead of the less concise
(let [a foo]
(let [b bar]
...))
>
> The let? syntax breaks code walkers.
Should that stop us from writing useful macros? If so, why do we have
the macro facility? If every useful macro is already part of the
language, should we even have defmacro?
> The let? syntax breaks pretty printers.
to your .emacs or .emacs.d/init.el:
(define-clojure-indent
(let? 1))
> The let? syntax "complexes" read.
>
> See the loop package in Common Lisp.
> Some people swear by it, others swear at it.
people coming from imperative languages.
> The idea isn't new.
happy to admit that macros like let? have been written before.
>
> If you want "readable code" write a literate program.
> Literate programs communicate from person to person rather
> than having the person "decode" your idea from the code.
> If you understand the idea, any syntax is easy to read.
makes the specific pattern it's designed for clearer by making a
single let form with clauses to handle the assertions and failure
code.
Andrzej
> If so, how ?
Syntax is a list of arbitrary rules made by a language designers. It's
always possible to come up with a different (perhaps more compact,
cleaner, more readable) syntax but:
- that means creating a new incompatible language,
- that would exactly zero new capabilities. Power of the language is
defined by its semantics, not syntax.
If I was going to design a new LISP language, I'd consider one of these
two possibilities:
1. Getting rid of textual representation altogether and provide tools
(editor, diff, patch etc) handling AST semi-graphically (think of the
way spreadsheet editors handle 2D arrays). This breaks so many
established conventions that it's unlikely at large scale. Yet, this is
what LISP was originally supposed to be, and technical limitations that
forced us to use textual representation are long gone.
2. Changing some of the arbitrary decisions LISP designers have made.
Specifically, they have decided that a procedure application literal is
simply a list: (proc arg1 arg2), which then forces us to use a
constructor syntax for getting a list: (quote a b c) or '(a b c). This
is a very clean and compact representation indeed but it makes it easy
for the programmer to confuse a procedure application with a list.
We could reverse this design decision and make the list literal denote a
list: (a b c), and come up with an explicit literal form for an
application. For example:
.fun <nil> ; (apply fun)
.fun (arg1 arg2 ...) ; (apply fun '(arg1 arg2 ...))
.fun arg ; (apply fun arg) (any use for that?)
.fun {arg1 val1} ; (apply fun {arg1 val1}) (ditto)
So instead of writing:
(map + '(1 2 3) '(4 5 6))
we could have:
.map (+ (1 2 3) (4 5 6))
A bit more complex example:
(def fib-seq
((fn rfib [a b]
(lazy-seq (cons a (rfib b (+ a b)))))
0 1))
could become:
.def
(fib-seq
. .fn (rfib [a b]
.lazy-seq (.cons (a .rfib (b .+ (a b)))))
(0 1))
If we added one more "apply" literal:
.(arg1 fun arg2) ; (apply fun '(arg1 arg2))
we could even write:
.def
(fib-seq
. .fn (rfib [a b]
.lazy-seq (.(a cons .rfib (b .(a + b)))))
(0 1))
IMHO the result is both more explicit and more readable than the
conventional LISP syntax (and yes, I'm using LISP long enough to be
comfortable with its syntax). Is it worth implementing in an *existing*
language? Nah..., maybe in some DSLs.
Andrzej
Evan Gamble
On Mar 10, 12:19 am, Craig Brozefsky <cr...@red-bean.com> wrote:
> Sure, you feel your defmacro, oats you write some ghetto macros with
> syntactically significant keywords, maybe stay up late a few nights
> expanding it into a some monstrosity and suddenly you have loop (I don't
> think CL's format is in the same realm actually). It works for you, you
> dig it, mazel tov. God knows I've written worse by far.
assertions to be combined into a single let form. I won't let it grow
into a huge monstrosity, like loop.
>
> > ...and I have learned to love nil, even the :else nil clause that
> > repels you.
>
> The idea of and explicit :else nil, in a situation where the negation of
> the logical operation is implicitely nil, just stinks in my nose.
haven't thought of a simple alternative. Can't use a naked :else
without the nil, because parsing would be ambiguous.
>
> Seriously though, don't let my aesthetic griping stop you from rocking
> out whatever kinda clojure code tickles your brain.
Softaddicts
The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of physical
memory (magnetic-core memory).
It had a structural editor. We would change nodes, add/remove child nodes, ...
Of course there were no WYSIWYG GUIs. The representation was all text
base showing a tree shape view of your code.
Navigation was a bit akward since it was 5 years before the mouse/windows
concept came to market.
I still wonder how it could fare compared to the text base approach we are used
to these days. Maybe this is worth an attempt with the current processing power
we have at hand and graphic aids that did not exists et the time.
Item 2:
From what I recall, there were no such confusion in a structural editor. The confusion
could still be removed by using proper syntax highlights even in a text base
editor.
In any case, you would not want to change the underlying representation
otherwise code that processes code would not work anymore or would become
more complex to write.
Luc P.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail!
James Reeves
> What I met by readable, is the capacity of reading someone's code.
I develop Ruby professionally, and write Clojure in my spare time.
Off hand, I can think of several Ruby libraries I'd consider to have
unreadable code, but no Clojure equivalents immediately spring to
mind.
Perhaps this is because there is a tendency for Ruby projects to
become very "deep". The functionality for a single class is often
scattered throughout several files of mixins and base classes. The New
Relic Agent library (https://github.com/newrelic/rpm) is particularly
bad in this regard.
Clojure, on the other hand, tends to encourage libraries that are very
shallow. Each namespace is contained in a single file, and holds a
list of functions and values. You rarely get the sort of functionality
spread that seems to occur in some large Ruby projects.
So returning to your question:
> Can Clojure be as readable as Python or Ruby?
The answer is: probably, but why would we want to make Clojure less readable?
- James
Andrzej
<lprefo...@softaddicts.ca> wrote:
> About item 1:
>
> The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of physical
> memory (magnetic-core memory).
> It had a structural editor. We would change nodes, add/remove child nodes, ...
Interesting. I thought it was only a planned feature, which has never
got implemented.
> I still wonder how it could fare compared to the text base approach we are used
> to these days. Maybe this is worth an attempt with the current processing power
> we have at hand and graphic aids that did not exists et the time.
I think it could work rather well in an education-oriented environment
or in DSLs. I don't think it would be interesting enough to flip
mainstream software engineers on its side, unless it had an Apple
badge on it. ;-)
I'd rather like to see it working in practice - LISP is all about
about using and manipulating ASTs, yet s-expressions are somewhat
masking this feature (at least to newcomers, which tend to think of
the LISP syntax as of a string of characters with some parentheses
added to it).
> Item 2:
>
> From what I recall, there were no such confusion in a structural editor. The confusion
> could still be removed by using proper syntax highlights even in a text base
> editor.
For a graphical/structural representation you'd likely need some sort
of meta-data for annotating the source code (e.g. for layout and
formatting). These data could then also be used for differentiating
between procedure applications and list literals, even if their
underlying structures were still the same.
> In any case, you would not want to change the underlying representation
> otherwise code that processes code would not work anymore or would become
> more complex to write.
Certainly not in an existing language, unless both representations
were perfectly compatible, which is unlikely.
As for the macros - that's a valid point. They would have to be
redesigned to match against "(apply proc ...)" forms. I don't think
that would have to be any more difficult than it is now, though. A new
language would likely come with its own macro framework.
Andrzej
daly
> On Sun, Mar 11, 2012 at 2:56 AM, Softaddicts
> <lprefo...@softaddicts.ca> wrote:
> > About item 1:
> >
> > The first Lisp I used was runing on a DEC-10 with 256k 36 bits words of physical
> > memory (magnetic-core memory).
> > It had a structural editor. We would change nodes, add/remove child nodes, ...
>
> Interesting. I thought it was only a planned feature, which has never
> got implemented.
VMLisp on the IBM Mainframe also was a structure editor.
(Mark Wegman, Martin Michaelson, Fred Blair)
They were useful because the initial editors on small systems
used sed-like commands to edit the text so you did "blind
edits" (e.g. c/the/twe/ .... 200 lines changed). Think DOS
edlin, TECO, etc. In my first 7 years of programming, the
only way to see the text was to type it out but that was
hugely wasteful of paper and something you rarely did so
"editing" was done "in your head".
Structure edits made sure that your edits were properly
formed s-expressions. This helped a lot because you no
longer had to keep a running count of parens in your head.
>
> > I still wonder how it could fare compared to the text base approach we are used
> > to these days. Maybe this is worth an attempt with the current processing power
> > we have at hand and graphic aids that did not exists et the time.
Structure editors took up more memory. Since my big PDP 11/40
had 8k (including the OS), this was a trade-off. With a simple
editor files could be up to 4k of text before the next char
crashed the system. A more complex editor ate into the program
size and caused an earlier crash due to memory being exhausted.
>
> I think it could work rather well in an education-oriented environment
> or in DSLs. I don't think it would be interesting enough to flip
> mainstream software engineers on its side, unless it had an Apple
> badge on it. ;-)
Emacs has paredit which allows s-expression level edits, see
paredit-splice-sexp, paredit-forward-slurp-sexp, etc. The
http://www.cliki.net/Editing%20Lisp%20Code%20with%20Emacs
has examples.
>
> I'd rather like to see it working in practice - LISP is all about
> about using and manipulating ASTs, yet s-expressions are somewhat
> masking this feature (at least to newcomers, which tend to think of
> the LISP syntax as of a string of characters with some parentheses
> added to it).
This leads to thinking about s-expressions as "wholes" where
each s-expression at every level does something you could name.
This tends to break down a bit as you get closer to the machine.
However, at the DSL level structure edits are pretty clean.
If you are at a level where you can think in "wholes" then
a structure editor might be useful. The VMLisp editor
tended to make you think on the syntax level and that
is very distracting. You generally don't "see" the parens
when writing code since lisp allows one to ignore all
syntax issues. Other languages (e.g. C++) require random
';', '{', etc. which forces attention to syntax. Maybe
that's why people like IDEs since they tend to provide
auto-insertion of delimiters and motion by expression
which is a kind of structure editing.
Clojure brings back some syntax issues because binding
contexts require [ ] pairs and other structured surface
syntax protrudes into your attention. Would a Clojure
structure editor tend to drift to an IDE? Wouldn't
CCW qualify as a structure editor? I believe they have
some of paredit's abilities:
http://code.google.com/p/counterclockwise
Tim Daly