t;
> (let [top-right (create-top-right-quadrant-for letter)
>right (stack top-right
> (flip top-right))
>diamond (beside (map reverse (drop-first-col right)) right)]
> (display diamond))
>
> The broad takeaway is: if I write a function
thanks
On Tuesday, 9 December 2014 08:01:58 UTC, Colin Yates wrote:
>
> I forgot to mention but https://github.com/bbatsov/clojure-style-guide is
> a pretty good resource.
> On 9 Dec 2014 00:24, "Philip Schwarz" > wrote:
>
>> Hello David,
>>
>> I h
unction I only use once, I usually
> just inline it. Unless of course I believe deep in my heart I'll have need
> of it somewhere else soon :).
> This is somewhat a matter of taste, and again, the requirements history
> usually determines what gets abstracted into functions, an
ain - the structural shape of the code imparts knowledge sometimes.
>
> As David says, if you haven't looked at Prismatic Schema then have a look.
> I find the definition of the schema is also an excellent place to capture
> this extra layer of info in the names of those structur
, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
> to use it, just that I wouldn't expect to see it.
>
> I hope this is u
to how other developers
> familiar with Clojure (or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I
ach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
e, I usually
> just inline it. Unless of course I believe deep in my heart I'll have need
> of it somewhere else soon :).
> This is somewhat a matter of taste, and again, the requirements history
> usually determines what gets abstracted into functions, and history can be
> mes
Hi Leif,
> you just need to consolidate the more concrete steps. Something like:
> flip-bottom-up -> flip (or vertical- and horizontal-flip)
> join-together-side-by-side -> beside
> put-one-on-top-of-the-other -> stack (or ontop, or ...)
> reverse-every-row -> (map reverse rows) ; very readabl
y
> just inline it. Unless of course I believe deep in my heart I'll have need
> of it somewhere else soon :).
> This is somewhat a matter of taste, and again, the requirements history
> usually determines what gets abstracted into functions, and history can be
> messy. :
t. Unless of course I believe deep in my heart I'll have need
> of it somewhere else soon :).
> This is somewhat a matter of taste, and again, the requirements history
> usually determines what gets abstracted into functions, and history can be
> messy. :)
>
> Hope that
y solution may be closer to how other developers
> familiar with Clojure (or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
&
in - the structural shape of the code imparts knowledge sometimes.
>
> As David says, if you haven't looked at Prismatic Schema then have a look.
> I find the definition of the schema is also an excellent place to capture
> this extra layer of info in the names of those stru
elopers
> familiar with Clojure (or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't
h is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
> to use it, just that I wouldn't expect to see it.
>
> I
;s the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--the
; concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
> to use it, just th
?
The separation of WHAT from HOW seems to have a parallel in the [design by]
*wishful
thinking* approach described in the following section of the LISP bible,
Structure and Interpretation of Computer Programs:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_idx_1306
Philip
O
(or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main f
x27;m claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. Bu
oncise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a main function, and you don't see
> them in libraries, certainly. But that is minor--there's no reason *not*
> to use it, just that
t; of functions come up time and
> time again - the structural shape of the code imparts knowledge sometimes.
>
> As David says, if you haven't looked at Prismatic Schema then have a look.
> I find the definition of the schema is also an excellent place to capture
> this extra l
ojure (or functional programming in general) may approach
> it--not that I'm claiming it's the best approach. I do think it is more
> concise without sacrificing readability (which is subjective, I fully
> appreciate).
>
> - I don't know if I've ever once used a ma
Hello,
can you please review my first solution to the diamond kata [1] and tear it
to bits: let me know all the ways in which YOU would improve the code.
I am not so interested in a better algorithm for solving the kata. I am
learning Clojure and what I want to know is what YOU would do to make
v 7, 3:25 am, André Thieme wrote:
> Am 06.11.2010 12:57, schrieb philip schwarz:
>
>
>
>
>
>
>
>
>
> > Hi all,
>
> > be gentle please: I have only just started using clojure.
>
> > I run the following on an Intel Core 2 Duo CPU (starting clojure w
ed to the total computation time required.
>
> Andy
>
> Sent from my iPhone
>
> On Nov 6, 2010, at 4:57 AM, philip schwarz
> wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > be gentle please: I have only just started using clojure.
>
> > I run
Hi all,
be gentle please: I have only just started using clojure.
I run the following on an Intel Core 2 Duo CPU (starting clojure with
"java -Xms1000m -Xmx1000m -jar clojure.jar"):
user=> (time (nth (doall (map inc (range 1000))) 999))
"Elapsed time: 5944.068355 msecs"
1000
user=>
27 matches
Mail list logo
