5 ms·

Clojure at a Bank – Clojure Code Immaturity

111 points by Adrock 14y ago

pyrgz 14y ago
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 https://github.com/id-Software
- jeremyjh 14y ago
  I don't trust myself to know - while I'm writing code - how well I or anyone else will understand it cold. So if I'm in any doubt at all I leave a comment. Sometimes I do go back and remove them - refactoring has to include comments. Whenever we discuss this topic there are usually some defensive sounding remarks about the fact that inaccurate comments are much worse than no comment. This is certainly true but I don't share the conclusion that the only reasonable answer is to never leave a comment. I guess if that is already what you do, then its probably easier to conclude it is correct.
- zokier 14y ago
  > 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 14y ago
    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.'.
dmix 14y ago
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.
infinii 14y ago
Disappointing as this article has an inappropriate title, it contains nothing relevant to a "bank".
- mattdeboard 14y ago
  Except that the codebase being written about is in production at an investment bank.
- plinkplonk 14y ago
  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=693 http://www.pitheringabout.com/?p=749 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.
- kinleyd 14y ago
  Yes, to me the title suggested the article was about the immaturity of Clojure Code (as in not ready for prime time) and it was only upon reading it that I realized it was about the immaturity of the OP's Clojure code as he began his Clojure journey. It was a nice read. I liked the frankness - no claims to overnight Ninjitsu mastery - and yet I get the feeling it's all pretty solid.
dizzystar 14y ago
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?
- Moocar 14y ago
  I'm not sure why the team used single-letter names I find myself doing this quite a bit. I think the reason is that it's so pervasive in the core.clj code. Take the documentation for update-in below: (update-in m [k & ks] f & args) 'Updates' a value in a nested associative structure, where ks is a sequence of keys and f is a function that will take the old value and any supplied args and return the new value, and returns a new nested structure. If any levels do not exist, hash-maps will be created. After having looked at a lot of clojure doc, those single letter names make sense to me (k = key, ks = keys, f = function). I use the same style when writing "core-like" functions, but anything remotely application specific is descriptively named.
deleted 14y ago
[deleted]

111 points by Adrock 14y ago

pyrgz 14y ago

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 https://github.com/id-Software

jeremyjh 14y ago
I don't trust myself to know - while I'm writing code - how well I or anyone else will understand it cold. So if I'm in any doubt at all I leave a comment. Sometimes I do go back and remove them - refactoring has to include comments. Whenever we discuss this topic there are usually some defensive sounding remarks about the fact that inaccurate comments are much worse than no comment. This is certainly true but I don't share the conclusion that the only reasonable answer is to never leave a comment. I guess if that is already what you do, then its probably easier to conclude it is correct.
zokier 14y ago
> 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 14y ago
  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.'.

dmix 14y ago

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.

infinii 14y ago

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

mattdeboard 14y ago
Except that the codebase being written about is in production at an investment bank.
plinkplonk 14y ago
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=693 http://www.pitheringabout.com/?p=749 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.
kinleyd 14y ago
Yes, to me the title suggested the article was about the immaturity of Clojure Code (as in not ready for prime time) and it was only upon reading it that I realized it was about the immaturity of the OP's Clojure code as he began his Clojure journey. It was a nice read. I liked the frankness - no claims to overnight Ninjitsu mastery - and yet I get the feeling it's all pretty solid.

dizzystar 14y ago

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?

Moocar 14y ago
I'm not sure why the team used single-letter names I find myself doing this quite a bit. I think the reason is that it's so pervasive in the core.clj code. Take the documentation for update-in below: (update-in m [k & ks] f & args) 'Updates' a value in a nested associative structure, where ks is a sequence of keys and f is a function that will take the old value and any supplied args and return the new value, and returns a new nested structure. If any levels do not exist, hash-maps will be created. After having looked at a lot of clojure doc, those single letter names make sense to me (k = key, ks = keys, f = function). I use the same style when writing "core-like" functions, but anything remotely application specific is descriptively named.

deleted 14y ago

[deleted]