XP Wabi Sabi (Refactored) William E. Caputo, October 17 2014 All requested features delivered. Speculation avoided. Mindful of our tendency toward completeness, necessary code is added, unnecessary code is removed. Refactored. Implementations incomplete - shadows of the their real-world counterparts, yet precisely the functions and properties required. The desire to add more, tempered by the satisfaction of not doing so. Technique and knowledge are increased to decrease their application. Simplicity. I posted that on the WabiSabi page of the c2 wiki on or about October 28th, 2002. I typically feel the same about my old writing and my old code ("what was I thinking?"), but I like this (even if it is a bit pretentious); especially the line about Technique and Knowledge. It cover many of the forces that need to balanced to ship software consistently. Happy Friday.
Test Driving Clojure Macros William E. Caputo, August 6 2014 When testing functions, one tests: evaluation result side-effects (if any) When testing macros, one may also wish to test: expander code expansion
Immutability and Safety William E. Caputo, May 25 2013 Work in clojure for any length of time, and you must get used to the idea that data structures are immutable. For programmers coming from imperative languages this can be jarring, (no loop counters? recursion? wtf?) but after a while, you start to get it, then you start to like it, then you start to rely on it - or at least I have. To such an extent that it's jarring not to have them. After a recent javascript coding session, I tweeted: "clojure's immutability has forever spoiled me - destructive operations in other langs feel like bugs now." This prompted Joshua Kerevsky to ask me via email to elaborate, as he has been talking about safety in programming lately. This is a revision of my answer... <<Full Article>>
Design goals and Complexity William E. Caputo, March 14 2013 "the young man or the young woman must possess or teach himself, train himself, in infinite patience, which is to try and to try and to try until it comes right" - William Faulkner Programmers solve problems. How they solve each problem is a function of their skill, talent, knowledge & time. The resultant solution will resolve the problem with greater or lesser complexity in the design. Thus, I find thinking about how (and more importantly where) complexity is handled, a useful way to evaluate a design. For this I use the time-honored technique of having three levels: Level Zero (Below this level, the problem is not solved) The programmer has provided a solution. However, the interface is a mine-field; click things in the wrong order, the program crashes. Or it works great, but you need to reread the documentation Every. Single. Time. Or the resultant surrounding workflow is a Rube Goldberg device. However it surfaces, the programmer has placed the complexity on the user. Level One T ... <<Full Article>>
Expoloring the French Defense (G30 practice game at DRW) William E. Caputo, January 19 2013 Played an interesting practice game last Friday (1/12) evening with one of my fellow DRW chess teammates, Oliver Gugenheim. After my stupendous blunder last week, I'm interested in playing some practice games - both to drill my pre-move thinking process, and because there's nothing like a bad loss to motivate one to start playing again... Oliver and I wound up exploring a sharp line of the French defense - an opening I have historically not enjoyed playing as white, and so had started learning more about the past week. Oliver (without us discussing it) obliged me by playing a line I had looked at that day so we went a good way into the "book" before (very quickly thereafter) reaching crazy territory. The most interesting bit tho, is actually black's move: 9. ... f6. The conclusion I got from this analysis, is that 9. ... f5 is better (see below for more) and so this was a useful game for this analysis alone... ... <<Full Article>>