
Clojure at a Bank – Clojure Code Immaturity - Adrock
http://www.pitheringabout.com/?p=778
======
dizzystar
I came to Clojure after learning Scheme. One would think going from lisp to
lisp would be an easy task, but the languages are so different. Clojure is an
incredibly rich language, which is why so many blogs talk about how after 6+
months, the team is still trying to grasp all it has to offer. I started by
rolling my own over and over again, only to discover a data structure or
technique that erases 50 LOC and opens up a whole new world of program reuse.
I have zero idea how someone coming from Python, Java, or Ruby would handle
the transition, but I imagine it would be very messy at first.

I'm not sure why the team used single-letter names. Using non-descriptive arg
and function names (if he did that too?) is about as anti-lisp as it gets.

I wonder if this blog, and other blogs like this, do a disservice to the
growth of Clojure. Not only is it apparent that using a lisp and immutability
is completely alien to the teams adapting it, they seem to take a very long
time to ramp up into it, and the conclusion is always the same: they are still
slipping and sliding, but at least they aren't breaking their noses anymore.
At the same time, these blogs are informative of what companies are likely to
get into and it should help stymie the surprises and perhaps keep the noise
down for a while, so maybe it helps with growth by attracting those that are
really willing to hack it. The author, as most are, is forthcoming with the
early mistakes and surprises. This is most certainly to be expected when
transitioning to any language, but it doesn't seem like there are many
languages where bloggers feel inclined to dote on the initial shock outside of
Clojure. It is a wonder that they don't complain about the lack of frameworks
a'la RoR/Django and other things one would figure they'd want before diving
in. Was it the lack of structure that made them go for it in the first place?

~~~
plinkplonk
" I started by rolling my own over and over again, only to discover a data
structure or technique that erases 50 LOC and opens up a whole new world of
program reuse. I have zero idea how someone coming from Python, Java, or Ruby
would handle the transition, but I imagine it would be very messy at first."

This is a good point and keeps happening to me. Otoh, there are a _lot_ built
in (and so a lot not to reproduce accidentally). clojure/core has > 500
symbols in it[1]. Is there a systematic way to learn what is 'built-in' to
Clojure vs waiting till one stumbles across specific items?

[1] (count (ns-publics 'clojure.core)) --> 580

(on the version of Clojure on my machine -> 1.4.0)

~~~
snprbob86
Do the puzzles at www.4clojure.com and be sure to "follow" the top 20 or so
users. Once you solve the puzzle, you're shown the solutions of those users
that you follow. I learned a lot of neat tricks that way!

------
dmix
Completely agree with learning the clojure core functions. It helps
significantly when working with clojures data structures to know whats
available.

I also made the newbie mistake of writing simple hash mapping functions that
were already well implemented. The problem is coming from Ruby,/Java you're
not intuitively aware of the standard functions compared to going from one OO
language to another.

------
pyrgz
_Therefore when we jumped both feet into Clojure we unconsciously brought with
us the belief that comments just weren’t needed_

I used to be in the "code tells a story, no comments needed" camp. In large
part because two of my three university courses had automatic marking system
which detracted points if comments exceeded a certain percentage of text mass.
Habits!

Gradually I've been finding myself commenting more and more in my code. In FP
(mostly F#) code I almost always end up with some incredibly information dense
set of lines that needs at least some defense of its existence.

Having spent some recent weekends reading the sources of id-software games[1]
I've started to really think about the approach to comments in imperative code
too. I've started commenting lots and then cutting it down later. If anything,
it helps me reason about my code better.

On a totally separate tangent, I feel like the kernel of most of my FP code
for data processing is essentially array programming like APL / J, just way
way way more verbose.

[1] <https://github.com/id-Software>

~~~
zokier
> In large part because two of my three university courses had automatic
> marking system which detracted points if comments exceeded a certain
> percentage of text mass

That sounds like a horrible system. Why'd they ever do that? The grading
systems I have seen do the inverse, requiring certain amount of comments. That
of course leads students writing gibberish just to fulfill the comment quota,
but even that is better than penalizing for commenting.

~~~
adrianhoward
There speaks somebody who has never spent their evenings wading through
terribly project submissions with > 70% comments.

The 'why' would be that there's an entire class of newbie developer who write
opaque code, and use the comments as an excuse not to write code clearly.

I see too many developer with the general attitude 'This code is opaque - it
needs a comment', where I vastly prefer 'This code needs a comment, how can I
make it less opaque.'.

------
infinii
Disappointing as this article has an inappropriate title, it contains nothing
relevant to a "bank".

~~~
plinkplonk
This is the third of a series of posts about introducing Clojure at an
investment bank.

The first and second posts are here

<http://www.pitheringabout.com/?p=693>

<http://www.pitheringabout.com/?p=749>

Tangentially, the 'swedish colleague' the author brought in to help with the
transition to Clojure is the immensely talented Hakan Raberg (sorry don't know
how to type umlauts etc on my keyboard) , who is a good friend and worked with
me at ThoughtWorks before he went indie.

