of clojure-mode
>> tickets that I thought were worth discussing here. The tickets are #265
>> <https://github.com/clojure-emacs/clojure-mode/issues/265> and #266
>> <https://github.com/clojure-emacs/clojure-mode/issues/266>, and they
>> later led to PR #96
I thought were worth discussing here. The tickets are #265 and #266, and
they later led to PR #96 on Bozhidar Batsov's Clojure Style Guide. The part of
the discussion I wanted to raise starts here, where there's some discussion
around the nature of the style guide itself.
Bozhidar clearly
You can use `.dir-locals.el` to alter the clojure-mode indentation settings on
a per-project basis.
—
Cheers,
Bozhidar
On December 20, 2014 at 8:47:10 PM, Andy L (core.as...@gmail.com) wrote:
Hi,
I realized recently that cohesive pretty formatting LISP programs is a very
difficult problem to
#x27;t read Clojure code since it's in the wrong style.
With so many different views, I think it's unwise to lock any editor into any
style. Instead give users options, and update the Clojure Style Guide with the
following (paraphrased) quote from Pirates of the Caribbean: "this Co
Yeah, shared (or at least as shared as possible) defaults would be awesome. I
feel that the style guide might provide us with
some insight about what those shared defaults should be.
—
Cheers,
Bozhidar
On December 20, 2014 at 11:51:33 AM, Laurent PETIT (laurent.pe...@gmail.com)
wrote:
I agree
hidar Batsov's Clojure Style Guide. The part of
the discussion I wanted to raise starts here, where there's some discussion
around the nature of the style guide itself.
Bozhidar clearly sees himself as the steward of a community style guide,
something he's done to great success
The only catch is that you should do this only for “relatively unique” names,
as clojure-mode is not namespace aware. Otherwise you might get
funky indentation in odd places.
—
Cheers,
Bozhidar
On December 21, 2014 at 3:23:17 AM, Reid McKenzie (rmckenzi...@gmail.com) wrote:
Protip: you already
Protip: you already can. From my .emacs:
(define-clojure-indent
(defroutes 'defun)
(GET 2)
(POST 2)
(PUT 2)
(DELETE 2)
(HEAD 2)
(ANY 2)
(context 2)
(for-all 1)
(such-that 1)
(let-routes 1)
(run-db 2)
(defspec 'defun))
Reid
On 12/20/14 16:28, John Jacobsen wrote:
Great
de
> tickets that I thought were worth discussing here. The tickets are #265
> <https://github.com/clojure-emacs/clojure-mode/issues/265> and #266
> <https://github.com/clojure-emacs/clojure-mode/issues/266>, and they
> later led to PR #96
> <https://github.com/
Great to see this discussion on the mailing list, rather than just comments
to PRs on GitHub. And a big thanks to Bozhidar for shepherding the current
style guide.
I came to Clojure from Python which has a strict standard (PEP-8) and a
linting tool which enforces a standard -- it's been my exp
On Saturday, December 20, 2014 12:53:41 PM UTC-5, Jonathan Irving wrote:
>
> It's not a docstring then, just the first expression in the body.
>
Leading to the interesting question: is the compiler smart enough to
optimize it away? A string literal has no side effects so if its return
value is u
Hi,
I realized recently that cohesive pretty formatting LISP programs is a very
difficult problem to solve in the first place due to its homoiconicity.
There could be some nice approximations but the devil is in the details.
That all made me so grateful for what we have and I stopped complaining :
That's true. I'm just saying I've accidentally done that before in single arity
functions with no penalty. But if you count on cider or similar picking up
docstrings from your own functions you'll want to do it the official way.
--Ashton
Sent from my iPhone
> On Dec 20, 2014, at 10:53 AM, J I
It's not a docstring then, just the first expression in the body.
On Sat, Dec 20, 2014 at 12:05 PM, Ashton Kemerling <
ashtonkemerl...@gmail.com> wrote:
>
> You can put the docstring after the args, but the tooling won't pick it
> up.
>
> --Ashton
>
> Sent from my iPhone
>
> On Dec 20, 2014, at 10
On Saturday, December 20, 2014 12:01:31 PM UTC-5, Eli Naeher wrote:
>
> Does anyone here know why in Clojure it was decided to move the docstring
> from its traditional-in-Lisp location after the argument list?
>
In a nutshell, arity-overloading.
--
You received this message because you are sub
You can put the docstring after the args, but the tooling won't pick it up.
--Ashton
Sent from my iPhone
> On Dec 20, 2014, at 10:01 AM, Eli Naeher wrote:
>
>> On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge
>> wrote:
>>
>> And on a client project recently, it was decided (when I wasn'
On Sat, Dec 20, 2014 at 8:30 AM, Timothy Baldridge
wrote:
> And on a client project recently, it was decided (when I wasn't around)
> that the arguments to a function should always be on a newline:
>
> (defn foo
> [x]
> (+ x x))
>
> Instead of:
>
> (defn foo [x]
> (+ x x))
>
Like you I pr
Defaults only please.
There are more pressing needs from dev tools than this sort of thing.
Diversity is what makes us well... different. Our minds are not formatted the
same
either. What may look readable to someone may look like garbage to someone else,
the context may also influence comprehe
On Saturday, December 20, 2014 9:30:47 AM UTC-5, tbc++ wrote:
>
> I recently browsed parts of that guide and was surprised how many bits I
> disagreed with. Especially around the "one space in these rare cases" bits.
> Not that that is a bad thing it's just my personal opinion that everything
>
of:
>
> (defn foo [x]
> (+ x x))
>
> I disagree with this idea also, but whatever, it's just style. It's not
> like I suddenly can't read Clojure code since it's in the wrong style.
>
> With so many different views, I think it's unwise to lock any
7;t read Clojure code since it's in the wrong style.
With so many different views, I think it's unwise to lock any editor into
any style. Instead give users options, and update the Clojure Style Guide
with the following (paraphrased) quote from Pirates of the Caribbean: "this
Code of
A way to hint indentation to the tooling would be nice.
Perhaps a metadata on vars such as {:body-indent #{then-clause
else-clause}} that could tell tools to indent an "if" this way:
(if condition
then-clause
else-clause)
instead of this way:
(if condition
then-clause
else-clause)
Let's start the list ! :-)
2014-12-20 10:57 GMT+01:00 Colin Fleming :
> Yes, perhaps just agreeing on sane defaults is a more achievable goal.
> Cursive currently does not indent everything exactly according to the guide
> by default. I would also not like to see tools' ability to implement more
Yes, perhaps just agreeing on sane defaults is a more achievable goal.
Cursive currently does not indent everything exactly according to the guide
by default. I would also not like to see tools' ability to implement more
sophisticated formatting hampered by an overly restrictive guide either,
since
s/sale/same
Le samedi 20 décembre 2014, Laurent PETIT a
écrit :
> I agree that if all tools could agree on sale out of the box defaults,
> this would be very valuable to users and clojure in general.
>
> Maybe a less ambitious goal than getting the whole community agree on
> standards could be t
I agree that if all tools could agree on sale out of the box defaults, this
would be very valuable to users and clojure in general.
Maybe a less ambitious goal than getting the whole community agree on
standards could be tool authors to agree on shared defaults. Which of
course doesn't prevent the
My view on this is very much along the line of discussions about
whitespace. While I have opinions about these matters, for the most part I
don't want to think about it--I have more pressing concerns. What's
important to me is consistency within a code base. Just like with
whitespace, I don'
;, and they later
led to PR #96 <https://github.com/bbatsov/clojure-style-guide/pull/96> on
Bozhidar Batsov's Clojure Style Guide
<https://github.com/bbatsov/clojure-style-guide>. The part of the
discussion I wanted to raise starts here
<https://github.com/clojure-emacs/clojure-
Thank you. My example was contrived as I was reading through the Clojure
style guide (linked below). This kind of thing isn't specifically mentioned
so I had the urge to try it and it works. That got me thinking that this
would likely be bad style (hackish). I started Googling but did not
Yes, I'd consider this bad style, for one, you don't get the arglists
metadata showing the names of variables during a repl session. That
metadata is on the var, and not the function itself. I'm not familiar with
Math/pow's function signature off the top of my head.
I would consider it only in t
Given the following code snippet would declaring a Var with an anonymous
function be considered bad style? Would there be any real use cases where
this would be regarded as a cleaner mechanism to declare a function rather
than declaring one with defn?
user=> (def pow #(Math/pow %1 %2))
#'user/pow
> Now it's been a long while since I wrote code to put food on the table -
> but back then if I saw C or C++ code written like this I would describe it
> as obfuscated - the sort of thing I would expect to see in the (now
> defunct?) annual obfuscated C competition. It's concise and rather cleve
BTW, in the case of frequencies, I did find it weird at first. But also
suspiciously useful. I think the reason is... in Clojure, I really feel how
I'm constantly moving things from datastructure to datastructure. ("Duh,
that's what I constantly do in any language...") So we can imagine that a
around a while.
As for the OP's question re. Style - many thanks to Erlis for posting the link
to the Clojure style tips: really helpful to us newbies. Now it's back to Miles
and macros for this greybeard!
--
--
You received this message because you are subscribed to the Google
Group
Really? You may of course be right; but double-checking [1], I see:
* it removed the "couple of magic numbers", the original post's most
substantive technical criticism
* it has a much larger and better docstring
I don't want to come across as zealot-y (who likes that?); it's just my
opinion a
On Monday, April 15, 2013 8:42:56 AM UTC+2, edw...@kenworthy.info wrote:
> Haha! I had similar advice from my Grandfather in the late 70s who
> predicted that computers will be writing all their own programs in the near
> future and so the job prospects for working in the field would be quite
>
Thanks everyone- that's been really useful.
And yes, frequencies, really throws me every time (as do some of the
unintuitively - to me - named functions).
On Wednesday, 10 April 2013 18:27:58 UTC+1, edw...@kenworthy.info wrote:
>
> So, page 143 of Clojure Programming has an implementation of Con
Haha! I had similar advice from my Grandfather in the late 70s who
predicted that computers will be writing all their own programs in the near
future and so the job prospects for working in the field would be quite
poor.
On Sunday, 14 April 2013 09:52:46 UTC+1, Korny wrote:
>
> I've been forget
I'm sorry but that's not true. The version over the page hasn't been
re-factored 'into a nicer version' it's been re-factored into a more
generic version to support, for example, hexagonal grids.
On Saturday, 13 April 2013 23:12:59 UTC+1, Tj Gabbour wrote:
>
> Hi,
>
> The text explains the "eleg
Nope, it's not an absolute age limit issue. It's more a question of your peak
throughput.
I am still faster than my customer's employees these days but the ratio had
dropped
when I was around 40 compared to what it was at 30. I was still rooted in the
Java world,
to my own despair.
This survey
I started writing clojure full-time a year and a half ago. At first, it
was a terrifying freedom that I could only write a few lines of code a day,
and each line was so packed with meaning it makes your head spin. It took
an incredibly long time to understand the terseness of code.
Maybe some
Hello all,
may I ask a very simple private question? How old is Rich? I suspect that, by
following some statements in this thread, he should have already refrained
himself from programming few years ago, perhaps before he invented Clojure.
mimmo
I'm very biased, being 52 years old
On Apr 14
Uh, Luc, are you suggesting anybody over the age of 30 can't code
productively any more? Because it sure sounds like that. If so, that seems
like a curiously ageist argument to make in a Clojure thread. I'll leave
it to the legions of skilled and productive programmers over 30 to
contradict t
I've always been awful at finding my keys, and rarely remembered if
yesterday's events were really three days ago. :) Being told to accomplish
rote tasks is gloomy, and I have to figure out how to internally motivate
myself. I've met many like me. Who knows the interpretation? Maybe a
charitabl
On Saturday, April 13, 2013 9:42:29 PM UTC+2, da...@axiom-developer.org
wrote:
>
>
> Inevitably I get rejected because I'm "overqualified", which is
> l33t speak for "old". Would you reject a builder, pilot, or lawyer
> for being "overqualified"?
>
They would, and for the same reasons, which
I've been forgetting my car keys consistently for the last 20 years - but
now I'm in my mid 40s it's easy to blame it on ageing :-) I've been coding
for longer than I've been losing car keys, and I can't say I've noticed a
lot of decline.
As for the lack of grey beards at conferences (mentioned el
Hi,
The text explains the "elegant" aspects of it; and then in the next page,
they refactor it into a nicer version which was 40% docstring. [1]
So this is like critiquing the readability of someone's first draft. :)
All the best,
Tj
[1]
https://github.com/clojurebook/ClojureProgramming/bl
In my own professional field I must admit that I also look to others like a
dino.
They all think "he should be in management by now...".
I have less patience these days to use technologies that require a big brain
estate for
a miserable return.
Never been a fan of learning surface knowledge eith
>> The average career length of a programmer is 8 years in the US (2003 survey)
>> and
>> the main reason invoked by those that left is their perceived lack of
>> productivity.
>
>TL;DR: Opinions about unproductive older programmers is ahead of the science.
I've been programming every day for
My point is not about unproductive older programmers, it's more an indication
of what one should seek to maintain his programming ability over time.
BTWY, I am 51 and I do not consider myself unproductive, I cheated, I switched
to Clojure an adaptive move to keep having fun and free myself fro
On Apr 12, 2013, at 1:18 PM, Softaddicts wrote:
> The average career length of a programmer is 8 years in the US (2003 survey)
> and
> the main reason invoked by those that left is their perceived lack of
> productivity.
TL;DR: Opinions about unproductive older programmers is ahead of the sc
I remember looking at the obfuscated C code submissions a decade ago at
least and it had nothing to do with the coded posted by the OP.
I remember a submission where the code was of circle created with underscores
in a main body. This was done with a few macros.
The thing would compile and spit
+1
Everyone will experiment this if they try to mantain their coding ability as
they age.
The average career length of a programmer is 8 years in the US (2003 survey)
and
the main reason invoked by those that left is their perceived lack of
productivity.
They could not get in that euphoric st
On Wednesday, April 10, 2013 7:54:37 PM UTC+2, Luc wrote:
>
> I can safely assume that the input state is also a set.
>
This emphasizes the toughest aspect of comprehending Clojure code: it is
not at all about conciseness or FP, but about dynamism. We just don't know
what value has what type s
When reading such concise code you must always remember that it is very
compressed and says a lot in a few words. So it is really the information
density that is disturbing the newcomer, not the legibility.
If the same code was expanded to 50 lines of Java code, then yes, each
individual line o
I think I would have found it pretty hard to comprehend when I first
started doing Clojure three years ago (eek - time flies!) but it made
sense reading it today and it is pretty elegant. It certainly helps to
know the rules of Conway's "Life"... I'm not sure I'd inflict this on
my team members yet
IMO, t the end of the day, if the code isn't immediately readable (for
other people on your team, which means what I'm saying is context
dependent), then it needs to be made clearer. That is *always* going to be
a value judgement. But I've heard the same comment about that particular
Game of Life
I agree that this seems a bit terse and magical. However, there are a
couple of mitigating factors to consider.
1. frequencies is a Clojure core function. It's simple enough to understand
on its own, but if you haven't encountered it, you'd need to look it up to
be sure what it's returning. Som
But I think you have mixed two different issues: code style vs readability.
For code style I'll suggest the github page
https://github.com/bbatsov/clojure-style-guide which offer a very nice
compilation.
Now for readability I would say that you can be entering in a very gray
zone here. Lisp
This single snippet does not look too obscure to me.
I have the book but never read this part.
>From what I can see, it gets a list of neighbors from the current state in
>cells,
extract pairs of location/frequency (de structuring loc and n for each pair
returned by frequencies) and returns cells
That said the code probably only needs a couple meaningfully-named private
functions to help make it more immediately obvious what it is doing, imo.
On Wed, Apr 10, 2013 at 10:39 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
> It isn't just you. It is not easy for me to see how thi
It isn't just you. It is not easy for me to see how this code works, until
I think about it for a while. In code review that'd be my main concern.
No offense to the author, because the implementation is actually really
neat. :)
On Wed, Apr 10, 2013 at 10:27 AM, wrote:
> So, page 143 of Cloju
So, page 143 of Clojure Programming has an implementation of Conway's Life:
(defn step
"Yields the next state of the world"
[cells]
(set (for [[loc n] (frequencies (mapcat neighbours cells))
:when (or (= n 3) (and (= n 2) (cells loc)))]
loc)))
The book claims this to be "an elegant
I agree - I thoroughly enjoyed this.
On 30 March 2013 08:45, Alan Thompson wrote:
> Hey - Just saw a nice article on this in (def newsletter) . It looks like
> quite a good reference on the subject.
>
> https://github.com/bbatsov/clojure-style-guide<https://github.com/bbatso
Alan,
Thanks for this. I've enjoy (and learn) a lot reading your clojure style
guide! Great job. I think it deserve a link in clojure-docs.org I couldn't
find anything similar on that page, wich I use a lot too.
Regards,
Erlis
On Fri, Mar 29, 2013 at 3:45 PM, Alan Thompson wrote:
&g
BerlinBrown a écrit :
>
> On Jan 16, 12:47 pm, Christophe Grand wrote:
>
>> BerlinBrown a écrit :
>>
>>
>>> Thanks all, this is what I ended up with:
>>> For noobs like myself, I am using this code to monitor files and
>>> refresh it when the file gets modified. I used 'ref' and 'agent'
On Fri, Jan 16, 2009 at 12:13 PM, BerlinBrown wrote:
>
> On Jan 16, 12:47 pm, Christophe Grand wrote:
>> BerlinBrown a écrit :
>>
>> > Thanks all, this is what I ended up with:
>> > For noobs like myself, I am using this code to monitor files and
>> > refresh it when the file gets modified. I
On Jan 16, 12:47 pm, Christophe Grand wrote:
> BerlinBrown a écrit :
>
> > Thanks all, this is what I ended up with:
> > For noobs like myself, I am using this code to monitor files and
> > refresh it when the file gets modified. I used 'ref' and 'agent'.
>
> > (def file-monitor-agent (agent
BerlinBrown a écrit :
> Thanks all, this is what I ended up with:
> For noobs like myself, I am using this code to monitor files and
> refresh it when the file gets modified. I used 'ref' and 'agent'.
>
> (def file-monitor-agent (agent false))
> (def file-state (ref {:open-state false}))
> (de
On Jan 16, 11:49 am, Christophe Grand wrote:
> BerlinBrown a écrit :
>
> > On Jan 16, 11:10 am, BerlinBrown wrote:
>
> >> I am working on this GUI tool and want to keep 'global' data
> >> structures in memory. For example, lets say I have a checkbox and
> >> want to be able to keep and access
BerlinBrown a écrit :
>
> On Jan 16, 11:10 am, BerlinBrown wrote:
>
>> I am working on this GUI tool and want to keep 'global' data
>> structures in memory. For example, lets say I have a checkbox and
>> want to be able to keep and access the state of that checkbox at any
>> time. Right now,
Hi Berlin,
Probably ref, if the state must be coordinate with other state, or
atom, if it is totally independent. But you might be able to avoid
using mutable state at all. We would need a larger example to tell.
Stuart
> On Jan 16, 11:10 am, BerlinBrown wrote:
>> I am working on this GUI
On Jan 16, 11:10 am, BerlinBrown wrote:
> I am working on this GUI tool and want to keep 'global' data
> structures in memory. For example, lets say I have a checkbox and
> want to be able to keep and access the state of that checkbox at any
> time. Right now, I am thinking the easiest thing
I am working on this GUI tool and want to keep 'global' data
structures in memory. For example, lets say I have a checkbox and
want to be able to keep and access the state of that checkbox at any
time. Right now, I am thinking the easiest thing to do is using a
Java hashmap and change the state
74 matches
Mail list logo
