Laziness in Clojure
Lazy evaluation is delaying known operations until they are forced. What I mean by laziness in this post is a bit more general than that, for some constructs what operations are delayed is not known and some are evaluated before a value is forced. When used correctly these differences should not matter. A significant detail, however, is that they all evaluate at most once.
In Defense of the Obvious - Part 2
First part was about certain biases managers of software developer have towards taking shortcuts and against taking bitter pills in general. To recap:
- The cost of doing the right thing™ can be calculated but the cost of dealing with foreseeable problems can only be estimated.
- Things might just work out fine in the end.
- It is easier to manage down.
- Blame can always be shifted below.
In Defense of the Obvious - Part 1
Sometimes the most important insights about things that may go wrong are obvious. As in you know the other party can (and should) easily deduce them. Sometimes these are the hardest things to communicate. And if you fail to communicate these obvious issues, guess who will bear the blame when they occur?
Infinite Sequences in Clojure
I consider infitine sequences to be one of the building blocks of functional programming. Though not a fundamental one like first class functions, immutability or laziness. Actually infinite sequences are derived from laziness. All infinite sequences are lazy, but not all lazy sequences are infinite. For example (map inc coll) returns a lazy sequence, regardless of coll being infinite or not.
This post is written with newbies in mind. If you are Clojure guru you will probably not learn anything new.
Completely Fair and Democratic Elections in Turkey
There is a lot to be said, but I’ll try to stick to the facts: