after the "wtf"s have worn off a bit, go on reading. imagine a simple problem: you have a collection of numbers and you have to write a function which collects all the numbers that are contained uneven times. for example, for a collection (1,2,3,2,3,4) the correct result is (1,4)
ask a child: "you just make pairs and return the leftovers" ask a non-child human: "count how often a number is in the list and pick the ones that are contained uneven times" i also asked some oo programmers. one of the answers involved a multimap, building it, iterating over it again and putting the result in a new list. one answer was "i don't see any purpose in this". there was no FP coder around at that time. i've noticed this since i started to work as a programmer 10 years ago. programmers in general are supposed to be good at finding simple solutions, but my experience is: they are not. on the contrary, many suffer from their individual tunnel visions without being aware of it. to a hammer, everything looks like a nail. i have walked a different path. when i was a child, i wondered: had i been born in a different country having different friends and parents, how would i be like? would i believe in a different god? would i like different music? i decided to try to be as independent from outside condition as possible, so i needed something as close to "the absolute truth" as possible and base my decisions on that. that absolute truth was nothing other than logic itself. it would always give the same answer, given the same input. it would never lead me to contradictions. it could not answer everything, but if it could, the answer always turned out to be correct - if testable. you could say logic is my personal tunnel through which i see everything, but i have yet to find a better one. i never care about how many people agree or disagree with me. if logic says "it's true", it just is. when solving a problem, i always try to find the most simple and elegant solution thinkable in a grand scheme. i'm pretty demanding here. i barely accept my own code if it doesn't fit exactly to the problem it is supposed to solve :) now back to the topic. when writing code, i try to follow a few simple rules as good as possible: * no one should every have to read the code to figure out how it works. it should always be enough to take a look at what it does, not how. * when changing code, everything that is not in the current mental scope should not have any connection to the code that is being changed. it should always be possible to ignore everything else without breaking it by accident. * use the highest abstraction level that still makes sense. * not applicable to clojure, but: type your code well. well typed code is easy to analyse and hard to use wrong. if you're working with tables and define a rowint and a colint-type, you would never be able to confuse them. if you had a nonzeroint and a zeroint-type, you would never accidently divide by zero. if you are accessing an array that is zero-based, there should be a zerobasedindexint. otherwise, there should be a onebasedindexint. * if you need something more than once, there should be an easily useable and accessible function for it. * write code in such a way that it cannot go wrong :) * solve problems once (and for all) with structure, not with flat logic at many points. if a solution is too simple, its users will have to make up for it by adding logic on the outside. this email didn't really have a purpose, i just didn't know a better place to post this. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
