On Aug 18, 11:09 am, michele wrote:
> Wouldn't that make it easier to keep track of them.
>
> Example:
>
> (defn myfn-a [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b
>
> (defn myfn-b [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...
Being the one who asked the question and satisfied with the answers, I
agree. I never expected a question like this, about one of the oldest
programming languages, to generate so many responses and discussions.
Funny...
On Aug 29, 9:46 pm, lprefonta...@softaddicts.ca wrote:
> My rough estimate
My rough estimate is that more than 40 replies to that thread heave been
generated up to now (I deleted the 28 ones without reading them after reading
a couple of replies to the original post).
Hmmm,,, I am about to think that we could have powered a small town
with all that electrical nerve impul
You could do what one of my "modern language" (python) students did.
Put the open parens at the end of the line and it looks like python!
(
defun foo (
arg1 arg2 arg3 ) (
let (
tmp1 tmp2 ) (
firstFunction arg1 ) (
secondFunction arg2 ) (
thirdFunction arg3 )))
auggghhh! my eyes! my eyes!!!
See also
http://edward.oconnor.cx/elisp/hl-sexp.el
(Highlights the "innermost list structure".)
Sincerely,
Michał
--
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
On Aug 19, 12:08 pm, Brian Goslinga wrote:
> Here is another trick that works for me in Emacs: delete most of the
> stack of closing parens, and then spam the ) key until the Emacs
> matches it to the desired opening paren.
this.
--
You received this message because you are subscribed to the G
On Sat, Aug 28, 2010 at 1:10 PM, Laurent PETIT wrote:
>> I did find the 4 char indents easier to read than the 2 char indents.
>> I wish CCW respected the "displayed tab width" setting as its
>> indentation in strict structural mode as I'd rather have 4 spaces than
>> 2 but it seems 2 is pretty mu
Hi,
2010/8/18 Sean Corfield
> On Wed, Aug 18, 2010 at 1:36 PM, Greg wrote:
> > Attached is a screenshot of some code from the wonderful Incanter
> library. I think it's a great illustration of how confusing stacking
> parenthesis can be (there are many functions in there that are like this).
>
Yet another one for Emacs users that don't use paredit:
I have Paren Match Highlighting enabled and set to highlight the
entire expression within matching parens (the highlighting kicks in
when the cursor is before the opening paren or after the closing
paren):
(show-paren-mode 1)
(setq show-pare
Brian Goslinga writes:
> Here is another trick that works for me in Emacs: delete most of the
> stack of closing parens, and then spam the ) key until the Emacs
> matches it to the desired opening paren. I can't remember a time that
> I had to manually count the parens when using that technique
> Again, that's quite a straw man--the attached code uses tabs for
> indentation, (ick!) and you're viewing it with a different tab-stop
> setting
Whoops, you're right, it was an honest mistake on my part. I use tabs of size 4
and the tab-stop used there was 8 I believe.
This issue is making me
On Aug 19, 1:55 am, michele wrote:
> Thanks everyone for the your answers (and the internal debates). I
> will not put closing parenthesis on new lines. Even though the editor
> helps me with the parenthesis, there have been situations - while
> editing inside functions - that I had to count them.
On Aug 18, 2010, at 8:05 PM, Cyrus Harmon wrote:
> but I shudder to think what it would be like to read the code for doseq or
> destructure if each closing parenthesis were on its own line.
Good thing no one suggested that. :-)
> And, as for writing code, I couldn't live without paredit.
What
On Aug 18, 3:26 pm, Nicolas Oury wrote:
> There is no law. Do what is best for you.
But there OUGHT to be a law.
Adam
--
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
Thanks everyone for the your answers (and the internal debates). I
will not put closing parenthesis on new lines. Even though the editor
helps me with the parenthesis, there have been situations - while
editing inside functions - that I had to count them. Here is an idea
(by Harold A.), I will try:
In any Lisp, I think parens are for the compiler and indentation is
for humans.
Regards,
Shantanu
On Aug 19, 10:20 am, Rayne wrote:
> It isn't helpful at all to me. My eyes bleed when I see code written
> like that.
>
> It may be helpful to some people, but I don't see the point when I
> have an
It isn't helpful at all to me. My eyes bleed when I see code written
like that.
It may be helpful to some people, but I don't see the point when I
have an editor that can match parens for me without any real work on
my part. The parens aren't something I feel I need to "maintain",
because between
On Aug 18, 2010, at 7:48 PM, Paul Stadig wrote:
> It may help *you* grasp the meaning more quickly, but the opposite may be
> true for others. But I guess automatic formatting would totally destroy the
> ability to talk about line 16 of a particular file.
>
This is a nifty point and idea.
I thi
On Wed, 18 Aug 2010 22:48:07 -0400
Paul Stadig wrote:
> Then I move on to thinking it best for a language designer to just legislate
> fomatting and make it a compiler error, but that would probably generate
> more discussion than otherwise, so I've just written the whole thing off as
> a lose-los
I'm reminded gigamonkey's footnote about when functions get too big:
"A friend of mine was once interviewing an engineer for a programming job and
asked him a typical interview question: how do you know when a function or
method is too big? Well, said the candidate, I don't like any method to b
I've rarely found these coding style discussions to be productive, and have
wondered why source control systems don't just store code in a whitespace
normalized format and automatically format the code to your own taste when
you check it out, because, let's face it, formatting is semantically
irrel
The Incanter example is confusing for the same reason that the
Leiningen example from the blog post is confusing, and I don't think
paren style matters at all. The functions have grown over time,
they're now too big, and they need to be refactored into several
smaller functions. The paren style is
I wrote a post about this very thread.
http://blog.fogus.me/2010/07/12/wadlers-law-extended-to-clojure/
:f
--
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
> Too bad. If you wanted to focus on the trailing-parens (which you clearly did
> in that article), you should have kept everything else the same between your
> examples.
Perhaps I should, then I wouldn't have to respond to your emails. :-p
As I've said multiple times now, now indentation width
> Yes, I read the link. I'm going to hazard a guess that lisp is not your
> native language :-)
I consider Lisp to be one of my favorite languages (if not my favorite), and
I've been coding in it for several years.
It's rather silly to assume something about someone's programming experience
ba
Greg wrote:
Now the question you're asking is, why don't lispers write
(MyFactory somearg
)
which makes me cringe.
That's not at all what's being suggested -- you'll find that both in the OP's
code and in the link below, there are many locations where closing parenthesis
are ended on
On Wed, Aug 18, 2010 at 1:36 PM, Greg wrote:
> Attached is a screenshot of some code from the wonderful Incanter library. I
> think it's a great illustration of how confusing stacking parenthesis can be
> (there are many functions in there that are like this).
But the indentation is broken in t
Actually, to be honest the short C++ example with lisp bracket style I
find a lot easier to read: I don't need to scan all the page to find
what belongs where...
2010/8/18 Greg :
>> Now the question you're asking is, why don't lispers write
>> (MyFactory somearg
>> )
>> which makes me cringe.
>
On Wed, Aug 18, 2010 at 1:36 PM, Greg wrote:
> Attached is a screenshot of some code from the wonderful Incanter library. I
> think it's a great illustration of how confusing stacking parenthesis can be
> (there are many functions in there that are like this).
Again, that's quite a straw man--t
I should qualify my response though to say that I am not advocating that
everyone switch their preferred style of code.
Just simply giving reasons for why some prefer one style over another. It's a
personal thing, and I do not wish to engage in a flame war over it.
Best,
Greg
On Aug 18, 2010,
On Aug 18, 2010, at 2:49 PM, Greg wrote:
> On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:
>
>> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>>
>>> http://gregslepak.posterous.com/on-lisps-readability
>>
>> That article is dishonest.
>
> Speaking as the author, I'm a bit offended.
Too bad. I
A more serious answer is that when I code in Java I use the
brace-on-a-line kind of indentation. When I code in Lisp I
never write single-line parens of any kind.
I find that I think differently in each language.
My Java code is always a pile of declare-this, do-this, do-this, return
Thus I find
Hi,
Am 18.08.2010 um 11:09 schrieb michele:
> (defn myfn-a [a b]
> (if (zero? b)
>a
>(recur
> (afn (bfn (...)) a)
> (dec b
>
> (defn myfn-b [a b]
> (if (zero? b)
>a
>(recur
> (afn (bfn (...)) a)
> (dec b)
>)
> )
> )
I find it interesting, that peop
On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote:
> On Aug 18, 2010, at 1:38 PM, Greg wrote:
>
>> http://gregslepak.posterous.com/on-lisps-readability
>
> That article is dishonest.
Speaking as the author, I'm a bit offended.
Yes, the indentation width was changed, and this was acknowledged
On Aug 18, 2010, at 1:38 PM, Greg wrote:
> http://gregslepak.posterous.com/on-lisps-readability
That article is dishonest. The author changes indentation widths between
examples, while focusing entirely on the trailing-parens. He claims in a
comment that "the post is not solely about trailing p
The indentation is enough of a hint to get it right. For example, in
myfn-a, because you've indented it correctly I can easily tell that
(dec b) is the second argument to recur, without looking at the
parentheses at all. Isolating close-parens would probably help a
little with this task, but the lo
It's almost purely community convention that has been adopted from Lisp.
You may be interested in this link:
http://gregslepak.posterous.com/on-lisps-readability
There is much discussion about this topic there.
Cheers,
Greg
On Aug 18, 2010, at 2:09 AM, michele wrote:
> Wouldn't that make it e
Three reasons.
First, "code density", that is the number of
(/ number-of-lines-of-code number-of-lines-on-screen) should
approach 1 so that every line on the screen is code.
Second, real editors paren-bounce to show matching parens.
Third, "real lispers" don't exit the thought process until the
On 8/18/10 1:32 PM, Brian Goslinga wrote:
> Putting them on separate lines put the focus on the wrong element of
> the code. You do not want to be focusing on the parentheses, you want
> to be focusing on the structure of the code. The idiomatic lisp
> formatting style uses indentation to reveal
Putting them on separate lines put the focus on the wrong element of
the code. You do not want to be focusing on the parentheses, you want
to be focusing on the structure of the code. The idiomatic lisp
formatting style uses indentation to reveal the large scale structure
of the code, and so the
On Wed, Aug 18, 2010 at 1:11 PM, Sean Corfield wrote:
> On Wed, Aug 18, 2010 at 2:09 AM, michele wrote:
>> (defn myfn-b [a b]
>> (if (zero? b)
>> a
>> (recur
>> (afn (bfn (...)) a)
>> (dec b)
>> )
>> )
>> )
>
> I started out trying to do that but it ended up being far more wo
auto-indentation and parens highlighting are better than lines with
only one parens.
At least for me.
There is no law. Do what is best for you.
You might, or not, change your mind when you have more practice with
all those parens.
--
You received this message because you are subscribed to the
On Wed, Aug 18, 2010 at 2:09 AM, michele wrote:
> (defn myfn-b [a b]
> (if (zero? b)
> a
> (recur
> (afn (bfn (...)) a)
> (dec b)
> )
> )
> )
I started out trying to do that but it ended up being far more work
that it was worth - as Phil said, computer programs (IDEs / editor
On Wed, Aug 18, 2010 at 2:09 AM, michele wrote:
> Wouldn't that make it easier to keep track of them.
It would make it easier for people to keep track of them. However,
keeping track of parentheses is not something people should be doing
since it's menial, repetitive, error-prone work. Computer p
Wouldn't that make it easier to keep track of them.
Example:
(defn myfn-a [a b]
(if (zero? b)
a
(recur
(afn (bfn (...)) a)
(dec b
(defn myfn-b [a b]
(if (zero? b)
a
(recur
(afn (bfn (...)) a)
(dec b)
)
)
)
--
You received this message becau
45 matches
Mail list logo
