The amount of comments is difficult to balance and yes as you get more
experience, you'd rather cram
as much code lines in a screen shot as possible. 0 comments ? No that's
not good. The other extreme he shows
is also not viable. If maintaining the comments takes as much time as
maintaining the co
I hesitate to extend this unpleasant thread, but here's a relevant
post that definitely takes a stand on the commenting issue:
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
As usual with Steve, it's a funny post, so I hope nobody takes it too
seriously :)
Hugh
On Wed, Dec 31,
It was our own initiative. 4 of us integrated an existing team of
developers and they
were required to spit out detailed specs at every release.
This was a real-time redundant system to control production and
transportation of electricity in the province of Quebec.
That system had to show up 99.99
On Dec 31, 2008, at 1:29 PM, Luc Prefontaine wrote:
> In the mid 80's I and others in a Fortran dev. team created a super
> javadoc. This beast was spitting out a FULL
> document in the editor used by office people.
>
> You would write comments in the code that were extracted and you
> would
My two cents...
Comments are worse since Javadoc came to life, up to date or not.
Most of the time they do not describe the behaviour of the class in
depth and you have to get the source code
on your screen.
We replaced quality by quantity. If I want to find the signature of a
function I can al
On Dec 31, 8:13 am, "Mark Volkmann" wrote:
> Suppose you had been studying Clojure for one week before coming
> across this code. Would you know what was going on here? Let's see ...
> we've got an anonymous function that uses an anonymous function which
> iterates some number of times calling do
> This is the excuse continually trotted out by people too lazy to
> comment, or who think themselves superior to merely mortal programmers
> who have to work in teams and actually communicate with people.
> Redundancy in communication is almost never redundant; think of it as
> a checksum.
I'd like to focus the attention back to a specific example. See the
first code snippet at http://clojure.org/concurrent_programming.
(import '(java.util.concurrent Executors))
(defn test-stm [nitems nthreads niters]
(let [refs (map ref (replicate nitems 0))
pool (. Executors (newFixed
Simon Brooke wrote:
> On Dec 29, 3:15 am, Rich Hickey wrote:
>> On Dec 28, 8:13 pm, "Mark Volkmann" wrote:
>>
>
>> I'll not argue for making code harder to read, but I have to object to
>> most of your example.
>>
>> Making something 4x longer does not make it easier to read.
>>
>> Redundant co
"'Redundant comments are useless' is the mantra of the dilettante, the
amateur, and the cowboy."dilettante, the amateur, and the cowboy"", ouch.
Redundant comments are... redundant (hence the name), and a support overhead
and a source of misunderstanding if they are not updated in line with the
cod
On Dec 31, 9:42 am, Simon Brooke wrote:
> On Dec 29, 3:15 am, Rich Hickey wrote:
>
> > On Dec 28, 8:13 pm, "Mark Volkmann" wrote:
>
> > I'll not argue for making code harder to read, but I have to object to
> > most of your example.
>
> > Making something 4x longer does not make it easier to
On Dec 29, 3:15 am, Rich Hickey wrote:
> On Dec 28, 8:13 pm, "Mark Volkmann" wrote:
>
> I'll not argue for making code harder to read, but I have to object to
> most of your example.
>
> Making something 4x longer does not make it easier to read.
>
> Redundant comments are useless.
This is the
What about some sort of lint program? I'm thinking about something
like pylint for clojure with configurable rules, but which will
default to the standards agreed upon bu the clojure community. Even
if you don't follow the rules 100%, it could be useful to see where
you are deviating to be sure
On Mon, Dec 29, 2008 at 4:10 PM, Chouser wrote:
> I believe the idiom for global values like this is to place asterisks
> around the name.
I thought the asterisk convention was for variables intended for
dynamic binding. It took me a minute to figure out where I got that
idea. "Programming Cloju
Mark Volkmann a écrit :
>> (assoc snake :body
>>(cons
>> (map + dir (first body))
>>
>
> The previous line needs to be (vec (map + dir (first body))).
>
It works without the vec. Since we aren't using indexing anymore we
don't need to make a vector: a seq (or any collection type)
On Tue, Dec 30, 2008 at 4:21 AM, Christophe Grand wrote:
>
> Mark Volkmann a écrit :
>> For example, here's some code that I don't
>> know how to rewrite in a way that I find self-explanatory:
>>
>> (every?
>> #(<= (- (apple %) +grid-size+) (head %) (+ (apple %) +grid-size+))
>> [+x-index
Mark Volkmann a écrit :
> For example, here's some code that I don't
> know how to rewrite in a way that I find self-explanatory:
>
> (every?
> #(<= (- (apple %) +grid-size+) (head %) (+ (apple %) +grid-size+))
> [+x-index+ +y-index+]))
>
> And here's another one:
>
> (assoc snake :body
>
On Dec 29, 1:15 pm, "Mark Volkmann" wrote:
> It's early enough in the life of Clojure that we haven't developed any
> deeply held habits yet. I think it would be a good idea for you and
> other Clojure committers to at least suggest the way you think things
> should be done in code. If you think
A useful comment addition:
How do I run it?
Cheers
Tom
2008/12/29 Mark Volkmann
>
> On Mon, Dec 29, 2008 at 3:58 PM, Chouser wrote:
> >
> > On Mon, Dec 29, 2008 at 4:40 PM, Mark Volkmann
> > wrote:
> >>
> >> I think that's supposed to be + instead of *, at least Common Lisp
> >> seems to us
Mark,
Thanks for providing that. I've linked to it from the site of the
original post at http://www.plt1.com/1070/even-smaller-snake/
(Btw, a typo in my name at the top of your page :-)
On 12/30/08, Mark Volkmann wrote:
>
> On Mon, Dec 29, 2008 at 3:58 PM, Chouser wrote:
>>
>> On Mon, Dec 29
On Mon, Dec 29, 2008 at 3:58 PM, Chouser wrote:
>
> On Mon, Dec 29, 2008 at 4:40 PM, Mark Volkmann
> wrote:
>>
>> I think that's supposed to be + instead of *, at least Common Lisp
>> seems to use +.
>
> I meant * -- I don't know CL at all, but the *asterisk* form is used
> frequently in clojur
I don't know CL that well myself, but I think the convention is to use
+ for constants (i.e. defconst) where * is used for global variables
(i.e. defparameter). In that case the + convention doesn't really
make sense in clojure as it doesn't have any notion of a constant
reference type.
--Darren
On Mon, Dec 29, 2008 at 4:40 PM, Mark Volkmann
wrote:
>
> I think that's supposed to be + instead of *, at least Common Lisp
> seems to use +.
I meant * -- I don't know CL at all, but the *asterisk* form is used
frequently in clojure.core, while no +plus+ form ever appears. I also
was careful
On Mon, Dec 29, 2008 at 3:10 PM, Chouser wrote:
>
> On Mon, Dec 29, 2008 at 3:40 PM, Mark Volkmann
> wrote:
>>
>> On Mon, Dec 29, 2008 at 2:24 PM, Brian Doyle wrote:
>>> Looking at this code the uppercase variables stands out.
>>> This isn't idiomatic is it?
>>>
>>> (def GRID_SIZE 10)
>>> (def
On Mon, Dec 29, 2008 at 3:01 PM, Stuart Sierra
wrote:
>
> On Dec 29, 3:40 pm, "Mark Volkmann" wrote:
>> On Mon, Dec 29, 2008 at 2:24 PM, Brian Doyle wrote:
>> > Looking at this code the uppercase variables stands out.
>> > This isn't idiomatic is it?
>>
>> > (def GRID_SIZE 10)
>> > (def HEIGHT
On Mon, Dec 29, 2008 at 3:40 PM, Mark Volkmann
wrote:
>
> On Mon, Dec 29, 2008 at 2:24 PM, Brian Doyle wrote:
>> Looking at this code the uppercase variables stands out.
>> This isn't idiomatic is it?
>>
>> (def GRID_SIZE 10)
>> (def HEIGHT 600)
>> (def MARGIN 50)
>
> I don't know.
I believe th
On Dec 29, 3:40 pm, "Mark Volkmann" wrote:
> On Mon, Dec 29, 2008 at 2:24 PM, Brian Doyle wrote:
> > Looking at this code the uppercase variables stands out.
> > This isn't idiomatic is it?
>
> > (def GRID_SIZE 10)
> > (def HEIGHT 600)
> > (def MARGIN 50)
>
> I don't know. I was following Java c
On Mon, Dec 29, 2008 at 2:24 PM, Brian Doyle wrote:
> Looking at this code the uppercase variables stands out.
> This isn't idiomatic is it?
>
> (def GRID_SIZE 10)
> (def HEIGHT 600)
> (def MARGIN 50)
I don't know. I was following Java conventions of making constants all
uppercase. Is there a co
Looking at this code the uppercase variables stands out.
This isn't idiomatic is it?
(def GRID_SIZE 10)
(def HEIGHT 600)
(def MARGIN 50)
On Mon, Dec 29, 2008 at 12:19 PM, Mark Volkmann
wrote:
>
> On Mon, Dec 29, 2008 at 11:11 AM, lpetit wrote:
> >
> > You should consider using docstrings for d
On Mon, Dec 29, 2008 at 11:11 AM, lpetit wrote:
>
> You should consider using docstrings for documenting functions
Good suggestion. I've changed my code to do that. I also noticed that
I had forgotten to replace special characters with built-in entities
in my HTML, so that is fixed now. The new
Not sure about that; knowing what a function is for is an important starting
point to understanding it. Anyway' half of the code you work on will be
using the other half (for given values of 'half' of course ;-) .
Generally, Clojure is a Lisp so Lisp idioms should apply (closing all your
braces o
On Monday 29 December 2008 09:11, lpetit wrote:
> You should consider using docstrings for documenting functions
There's a big difference between the comments directed at someone
reading the code (possibly the author at a later date) and someone
wishing to use it. Function-level documentation s
You should consider using docstrings for documenting functions
On 29 déc, 16:45, "Mark Volkmann" wrote:
> On Mon, Dec 29, 2008 at 5:44 AM, Mark Volkmann
>
>
>
> wrote:
> > I would like to produce a version of the snake code that could serve
> > as an example of the kind of code that the Clojure
On Dec 29, 2008, at 10:45 AM, Mark Volkmann wrote:
>
> On Mon, Dec 29, 2008 at 5:44 AM, Mark Volkmann
> wrote:
>
>> I would like to produce a version of the snake code that could serve
>> as an example of the kind of code that the Clojure community thinks
>> is
>> "good". Unless it's part of a
> My challenge to everyone on the list is to start with any version of
> the snake code you've seen and make it as readable as *you* think it
> should be by doing things like renaming variables and functions,
> adding comments and changing indentation. I'd really like to see what
> *you* think is
On Mon, Dec 29, 2008 at 5:44 AM, Mark Volkmann
wrote:
> I would like to produce a version of the snake code that could serve
> as an example of the kind of code that the Clojure community thinks is
> "good". Unless it's part of an exercise to produce the shortest code
> possible, I think we shou
On Mon, Dec 29, 2008 at 12:03 AM, Abhishek Reddy wrote:
>
> Speaking for myself, as the author of the original Snake example, I
> had no intention of converting developers to Clojure, or of producing
> instructive or readable code, with that snippet.
>
> While I agree with some of your critique,
I think that just as important as "compactness" is the issue of
"density": the ratio
of the "conceptual weight"of the computation to the size of the code
expressing it.
if a computation is inherently complicated and I manage to squeeze it
into
a few lines (typically accomplished via an intense co
Mark,
Thanks so much for pointing that out, it makes Clojure to belong to others.
Clojure should not be only for FP experts and PH.D holders. I took time to
check the background of some members in this group: we have lecturers,
research scientists and others from the best technical schools. I know
Speaking for myself, as the author of the original Snake example, I
had no intention of converting developers to Clojure, or of producing
instructive or readable code, with that snippet.
While I agree with some of your critique, I do think it is misplaced.
The aim of this particular exercise was
On Sun, Dec 28, 2008 at 9:15 PM, Rich Hickey wrote:
>
> On Dec 28, 8:13 pm, "Mark Volkmann" wrote:
>> This is related to the thread titled "Proxying in Clojure". I've spent
>> a lot of time studying the code in this "snake" example and have some
>> observations I'd like to share.
>>
>> First off
On Dec 28, 8:13 pm, "Mark Volkmann" wrote:
> This is related to the thread titled "Proxying in Clojure". I've spent
> a lot of time studying the code in this "snake" example and have some
> observations I'd like to share.
>
> First off, obviously I care about the future of Clojure or I wouldn't
This is related to the thread titled "Proxying in Clojure". I've spent
a lot of time studying the code in this "snake" example and have some
observations I'd like to share.
First off, obviously I care about the future of Clojure or I wouldn't
have spent the last six weeks or so trying to learn it
43 matches
Mail list logo
