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
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
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
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
Well, Luc, I'm still not convinced there is such a significant decline in
performance with age - maybe I never reached as high a peak in the first place!
But I certainly agree that it's important to work smarter, not harder as we
gain the experience to do so, especially in Javaland where so
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
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 clever,
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
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 are
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
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
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
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
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
On Apr 12, 2013, at 1:18 PM, Softaddicts lprefonta...@softaddicts.ca 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
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
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 42 years,
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
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]
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
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 so
+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
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
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
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, edw...@kenworthy.info wrote:
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 this
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
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 code
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.
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
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,
31 matches
Mail list logo
