Welcome to Adam's Programming Pages!
Dear guest, I'm Adam Tornhill, a programmer and psychology student based in Sweden. On these pages you'll find my articles and book reviews. All of them, in one way or another, related to programming.
The Definitive ANTLR 4 Reference
I've been a professional programmer for 20 years now. During that time a lot of technologies have passed by, often leaving few reasons to mourn their demise (yes, COM, I'm looking at you). The software industry is a tumultuous place to be; New languages and frameworks pop-up all the time and it takes effort just to keep up. At the same time, few technologies are genuinely new. And some skills are as useful today as they were two decades ago when I started. Parsing text falls into this category. In fact, I'll claim that parsing is one of the most neglected skills of many programmers. Knowing when and how to write a parser is likely to save you a lot of time, bugs and headaches. Trust me - I'd be a rich man if I had a penny for every block of code with nested loops, conditionals and primitive string operations that I've replaced with a simple parser invocation. Unfortunately I've never been compensated that way, so let's leave that here and move on to discuss ANTLR instead.
Peak: Secrets from the New Science of Expertise
I've been doing technical interviews with software developers for a decade now. While I do look at their CV I don't care much about past experience as measured in years. Instead, the thing I put most value on is if the candidate has shown the ability to learn. To me, that's the skill that makes a real difference. It doesn't matter how many years of a specific technology you have under your belt; If you don't have a habit of learning new stuff, much of your skills will become obsolete. Worse, you'll miss a lot of opportunities in a fast moving field like ours. That's the reason I'm obsessed with learning and try to learn continuously myself, often by diving into different subjects/technologies/research that I don't really understand in an attempt to broaden my horizon (one example is my book Lisp for the Web that I wrote as a way to understand Common Lisp). I talked about this as a guest on Developer on Fire and I studied expert learning in my psychology courses. As such I was quite familiar with the research of Anders Ericsson. When I found out that he's been writing a whole book on the subject of learning, I jumped at the opportunity to read it.
Software (r)Evolution - Part 2: Novel Techniques to Prioritize Technical Debt
In this part of the Software (
Software (r)Evolution - Part 1: Predict Maintenance Problems in Large Codebases
Bad code tends to stick. Not only does it stay where it is; It stays there for years often outliving its original programmers, in the organizational sense, and to the displeasure of the next generation of programmers responsible for its maintenance. Making changes to such code is a high risk activity. Given the scale of today's codebases, we need more efficient tools to identify those parts of the system so that we can apply corrective actions, invest extra testing efforts, or focus code reviews. In this article we use data on our past behavior as software developers to guide such decisions.
The Apollo Guidance Computer
By now I've spent almost two decades in the software industry. Before that I used to hack around on my own toy projects, so it's probably fair to say I got a decent grasp on programming. But despite all these years thinking about code I noticed that I knew embarrassingly little about how computers actually work. What happens to all the code we write once it has been compiled down to machine instructions? How does it get executed? And, just as interesting, how can ones and zeros control peripherals like keyboards, printers or even rocket engines? My degree in electrical engineering gave me a decent understanding of several necessary components but it was far from enough. And yes, for those who know me, I may not have been the most motivated student back in the early 90ies. Thus I decided to make up for lost time by diving deeper into this subject and develop my mechanical sympathy. My first stop on this learning tour was the brilliant Code by Charles Petzold. A book about the Apollo Guidance Computer seemed like a natural next step for several reasons. First of all because I'm genuinely fascinated by both space flight and the Apollo program, but also as a way to study a real computer architecture in detail.
On Software Analysis, Code as a Crime Scene and Clojure
I talk about my book, Your Code as a Crime Scene, and my startup Empear that we founded to automate all the software analyses from Your Code as a Crime Scene. I also share my experience of building our products on Clojure, the productivity advantages and the minor drawbacks that we've seen.
Watch the video or read the transcript here.
The Leprechauns of Software Engineering
I set a number of goals when I started to write on what eventually became Your Code as a Crime Scene. One of those goals was to take some fascinating research on software and make that academic research accessible to the practicing programmer. At that time I was fresh of a research project I'd conducted for my Master degree in psychology. As such, I paid extra attention to the sources I used. I read the papers carefully, often 3-4 times to make sure I understood what was studied and what wasn't. However, I never took it to the level of scrutiny that Laurent Bossavit does. In his book The Leprechauns of Software Engineering, Laurent investigates a number of well-known claims in the software industry to uncover the true source of the supposed fact. As it turns out, that data is 1) often not there, 2) measures something else, or 3) suffers serious methodical problems.
Understanding Large Codebases with Software Evolution
I did an interview with InfoQ about my work on software evolution and my upcoming talk and workshop at GOTO Amsterdam 2016. I talk about why we need an evolutionary approach to reason about large-scale codebases, the importance of understanding the social side of code, and how organizational problems are mistaken as technical issues.
Read the interview at InfoQ.
Code: The Hidden Language of Computer Hardware and Software
I was fortunate enough to start my coding adventures back in a day where assembly languages were still a thing for application programming. I taught myself some of the basics on my Commodore 64, programmed micro controllers at the university, and started my professional career by writing assembly for an ancient 16-bit safety critical system for the railway industry. As such, I got a bit closer to the metal than I do these days. However, I still didn't have a solid understanding of what really happens in a computer. That's why I turned to Code: The Hidden Language of Computer Hardware and Software. Because what we have here is brilliant. Charles Petzold takes us on a ride from flashlights and telegraph relays all the way to classic microprocessors like the Intel 8080 and Motorola 6800. Along the way we get to actually implement
real computers, RAM, controllers for peripherals, and even basic persistence mechanisms.
A Machine Made This Book
It's been a couple of years since I read OCaml from the Very Beginning by John Whitington. It is a great read that presents an accessible introduction to functional programming in general and OCaml in particular. Thus, I responded with an enthusiastic
YES when John offered to send me his latest book: A Machine Made this Book. A Machine Made this Book covers a different topic and targets a different audience. A Machine Made this Book is a popular science book that promises to introduce computer science to the uninitiated. On a good day I like to view my self as at least half-competent in the topic, so I'm not really in a position to tell how well the book would work for a newcomer. However, what I found was a wonderful book that many professional programmers would enjoy and benefit from.
Developer on Fire
I'm happy to announce that I was interviewed by Dave Rael for his wonderful podcast Developer on Fire. I'm a big fan of the podcast and proud to be part of it. I particularly like Dave's focus on the people behind the technology rather than the technology itself.
The interview with me is called
Learn to Learn. You can listen to it here.
I worked on my first microservice architecture back in 2005. Of course, at that time we didn't have the label nor the surrounding hype. We arrived at a microservice architecture by responding to certain requirements balanced with our experience of the system we wanted to replace. The reason it became
micro is because we also followed the UNIX philosophy. The system turned-out to be quite successful, both in operation and from a maintenance perspective. However, there were certain aspects of system complexity that worried me. As microservices now enter the mainstream, I wanted to catch-up on the recent ideas. Sam Newman's book is an excellent starting point.
Refactoring for Software Design Smells
I'm probably ridiculously biased, but there seems to be an increasing interest in legacy code. This is an important trend. We programmers spend the majority of our time on modifications and improvements to existing code. And we want to make sure it's time well invested. Refactoring for Software Design Smells fits right in that spot.
Clojure for Machine Learning
I have to be right in the target audience for this book. I do most of my coding in Clojure. And the work I do at Empear, with Clojure, utilizes several machine learning algorithms to spot patterns in how large software systems evolve. While I do enjoy coding in Clojure, every now and then I long for Python with its strong machine learning tooling and libraries. I hoped Clojure for Machine Learning would close that gap for me. Unfortunately the book don't deliver on that promise. Sure, I got some useful pointers to libraries and techniques that I probably need, but my overall impression is that the book doesn't dig deep enough.
Workshops in Chicago and Amsterdam
Both workshops will explore Code as a Crime Scene in Practice and we'll get hands-on experience with the analysis techniques on real-world codebases like Scala, Clojure, ASP.NET MVC and many more. Hope to see you there!
Keynote at GOTO Stockholm and Conference Presentations ahead
I'm honoured to announce that I'll give a keynote speech at GOTO Stockholm.
I'll also speak at Craft in Budapest, SDD in London, GOTO Chicago, and GOTO Amsterdam. I'll premiere at least one new talk, Seven Secrets of Maintainable Codebases, where I'll attempt to challenge how we view large-scale software development.
Best Articles of 2015
by Adam Tornhill, February 2016
I'm proud to announce that my articles made it to the top of ACCU's survey for people's favorite articles of 2015. ACCU publishes two magazines. My article Meet the Social Side of Your Codebase made it to the top in the Overload magazine while Writing a Technical Book made the second place in the CVu magazine. These awards actually mean a lot to me. Yes, really, they do. Let me explain how it all started.
Clojure for the Brave and True
Clojure has been my primary programming language for the past six months. Empear, our startup, builds its product portfolio with Clojure. Before that, I've been using Clojure on and off for my side projects for a couple of years. Even though I still have a lot to learn when it comes to Clojure (and programming in general), I'm not really in the target audience for an introductory Clojure book. However, Clojure for the Brave and True has other qualities. So when the friendly people at No Starch Press asked if I wanted a copy, my response was an enthusiastic
Yes! Let me tell you why.
Kill the Clones: How Temporal Coupling helps you identify Design Problems in large-scale Systems
Your Code as a Crime Scene presents around 15 different software analyses. Of all those analyses, Temporal Coupling is the most exciting one. In this article we'll put the analysis to work on a real-world system under heavy development: Microsoft's ASP.NET MVC framework. You'll see why and how Temporal Coupling helps us design better software as we detect a number of possible quality issues in ASP.NET MVC. In addition, you get a preview of Empear Developer, a new tool to automate software analyses.
Code as a Crime Scene: The Workshop
I'm happy to announce that I've now opened my Code as a Crime Scene workshop. I do either 1 or 2 days and all material is adapted to your company. That is, we'll focus on the programming languages and environments that you use!
Programming Collective Intelligence
I bought Programming Collective Intelligence years ago. My idea at that time was to use it as a basis for practical applications as I learned Python. I picked a topic that looked interesting, say genetic programming, and experimented with the example code to test my Python fluency. In the process I picked up the basics of the most common families of machine learning algorithms. Since then I've returned over and over again to Programming Collective Intelligence. But now I use the book as a refresher or introduction to different machine learning domains.
Presentation, guest blog and video at SwanseaCon 2015
Analyzing Code Churn with Clojure and Zoo
Clojure in combination with the powerful Incanter library is a great platform for data analysis. In this article we'll put Clojure to work as you learn to calculate and visualize code churn trends.
Mastering Clojure Macros
In Lisp, the code you write is expressed using the language's own data structures. Macros are a metaprogramming system that allows you to hook into the compile phase and manipulate the source code before it's compiled. It's a simple idea, yet it gives rise to amazing capabilities for the programmer. Suddenly you, as an application programmer, has the same power as the language designer. Lack a language feature to make your program more expressive or succinct? Want a special construct to raise the level of your program to that of the problem domain? No problem - with Lisp that power is just a macro away.
The Code as a Crime Scene Gallery
I've started to publish an annotated best of collection from some of the open source projects I've analyzed with the Code as a Crime Scene techniques.
Writing a Technical Book: Motivation, Publishing and how to stay focused without ruining your Life
Do you dream of writing your own technical book? I hope you do – our programming profession needs more high-quality books. In our fast evolving field there’s an endless amount of new topics to cover and timeless ideas to rediscover. This article is here to help you get started. I’ll make sure to give you a high-level overview on everything from the initial planning to tips on different publishing models. You’ll also learn about the motivational hacks I used to stay on track and make a steady progress on my own books.
Speaking at EuroClojure 2015
I'm happy to announce that I'll speak at EuroClojure 2015 in beautiful Barcelona, Spain.
I'll premiere my new talk: Beyond Code - Repository Mining with Clojure. In my session I'll discuss the design of my Clojure application to mine social information such as communication paths, developer knowledge and hotspots from source code repositories (including Clojure itself). We'll also look at some interesting libraries like Incanter and Instaparse before we discuss the pros and cons of writing the tool in Clojure.
Hope to see you at EuroClojure 2015!
Statistics Done Wrong
Statistics underpin much of modern scientific research. It's our mathematical wonder tool that helps us identify groundbreaking findings and lets us separate real effects from noise. That is, as long as we're using our statistical tool the way it's intended. And even then there's no guarantee that our results aren't biased. Statistics Done Wrong is a marvelous journey through the major statistical methods, their pitfalls and misuses. It's the kind of book I wish I'd read as I did my first research.
Interview: Using Forensic Psychology to Spot Problems in Code
This month I did an interview with Fog Creek for their blog. It's a short interview, but we manage to cover a lot of ground like my new book, how we can improve architectures, and social biases in groups. I also talk about how the techniques from Your Code as a Crime Scene complement existing practices like unit tests and code reviews.
The whole interview is just 10 minutes and you can read the transcript or view the video at the Fog Creek site.
Meet the Social Side of Your Codebase
Let’s face it — programming is hard. You could spend an entire career isolated in a single programming language and still be left with more to learn about it. And as if technology alone weren’t challenging enough, software development is also a social activity. That means software development is prone to the same social biases that you meet in real life. We face the challenges of collaboration, communication, and team work.
Why I view Code as a Crime Scene
The interview was done by my project editor, Fahmida Y. Rashid. I chose to publish it here as well for a reason; Over the past years I've delivered several presentations about this topic. One of the most common questions I get is how I came up with the idea. So, here it is - this is why I view Code as a Crime Scene!
Speaking at DevWeek 2015
Next week I'll return to London to give two talks at DevWeek.
The presentations will be 90 minutes each. That gives me an opportunity to dive deeper and explore some angles I haven't covered in earlier versions of these talks. I've preparared plenty of new material for these two sessions.
I look forward to DevWeek and hope to see you there!
Speaking at QCon London 2015
My talk will be about the traces we leave behind as we create our systems. You'll see that there's a lot of valuable information in the evolution of your codebase. I'll show a set of techniques to mine and apply that information. At the end of the session you'll have a suite of analysis techniques that let you identify maintenance problems, team productivity bottlenecks and the code that’s most prone to bugs.
Learning Smalltalk from Pharo by Example
I was close to become a Smalltalk programmer back in 2005. At that time I worked in a large company. Somewhere in a dusty corner of the corporation there was a skilled team of Smalltalk programmers. These programmers were responsible for a bunch of legacy applications. Since I've heard a lot of interesting things about Smalltalk from smart people, I decided to dive into the language by joining that team. Unfortunately it became a short ride; On my first day in my new Smalltalk team a management decision was made to outsource the development. A terrible decision for the company, it turned out, and bad timing for me indeed. I went back to other languages and ten years passed. Then I met Tudor Girba at a conference last year. Tudor told me about this cool, modern open source Smalltalk implementation called Pharo. I decided to finally give Smalltalk a chance by working through the book Pharo by Example. What I found was something I've searched for years; an interactive, live environment that allows us to develop programs in a way that fits the way our brains are wired.
Speaking at Beauty in Code
I'm very happy to announce that I'll be giving a new speech, Software Design, Team Work and other man-made Disasters, at the Beauty in Code conference in Malmö, Sweden.
My presentation is about the intersection between technical decisions and people. You'll learn to mine social information from source code repositories. That allows us to see how the way we chose to organize affects the code we write and how an architecture is as much a social as a technical design.
Don't miss the conference - it's an amazing program with 7 speakers from 7 countries.
Read more about Beauty in Code.
Learn You a Haskell for Great Good!
I got my first exposure to Haskell back in 2003. At that years ACCU conference I attended a session by Simon Peyton Jones. Simon talked about meta-programming in Haskell. I remember that his presentation made an interesting contrast to all the C++ template craze of that year. Unfortunately, much of Simon's presentation went over my head at that time. Haskell has evolved since then and so has, hopefully, I as a programmer. That's why I turned to Learn You a Haskell for Great Good to get an idea of what the language has to offer.
Microsoft's Windows Communication Foundation (WCF) is a .NET framework for building service-oriented applications. The idea is that each service specifies its contract, much like an interface in object-oriented solutions. Clients access each service via an endpoint. That endpoint is defined by a service address and a binding model that specifies the transport mechanism. WCF is quite flexible and allows a bunch of different bindings such as HTTP, TCP or a message bus. Of course, WCF also allows you to specify how the service shall behave with respect to traceability, concurrency, data sizes, etc. With WCF you're able to tweak virtually any aspect of the connectivity, hosting and transport mechanisms. The WCF framework attempts to hide much of the details in a superficially simple programming model. Superficial, since as soon as you need to customize any aspect beyond the standard configurations you're in a world of deep accidental complexity.
New book: Your Code as a Crime Scene
In the book, you'll learn forensic psychology techniques to successfully maintain your software. We'll see how we can:
- Predict the code with most defects and steepest learning curves.
- Understand how multiple developers and teams influence the quality of the code.
- Use software evolution to find the code that matters most for maintenance.
We hope to get the complete book out in early 2015. By then, the book will also include a pretty cool forward. Stay tuned.
Why so silent?
It's been quite some time since I published anything. Over the past six month I've been busy writing on my new book.
My writing experience has been both fun and rewarding. I wanted to write the best book I possibly could. That also meant I had to put the rest of my life on hold for a while. After the book is released, I'll continue my activies on these pages.
Once the book is out, I also plan to write an article about my experience. I learned a lot and I'd love to share it with you.
Guest on .NET Rocks!
I'm proud to announce that I'm today's guest on the amazing .NET Rocks! audio talk show.
I talk about why psychology matters to programmers, a bit on functional programming, on my upcoming book about Code as a Crime Scene and techniques to identify design issues in large codebases. All of it in my inimitable swedish version of english.
Thanks a lot to Carl Franklin and Richard Campbell for having me on the show - you do rock!
Listen to Psychology in Programming on .NET Rocks!
Beauty in Code
The challenge of all software design is to control complexity. Less complexity means that our programs are easier to understand, reason about and evolve. This article shows how we can use beauty as a mental tool for that purpose. Starting in the field of the psychology of attractiveness, we'll expand its theories on physical beauty to also cover code. In the process we'll learn a bit about Clojure, meta-programming and destructuring.
Erlang and its philosophy had a tremendous impact on how I design software. It changed the way I think about scalability, error handling and other technical aspects. More importantly it influenced how I view code. Erlang was the first technology I learned that took a holistic view of systems. As the Erlang family now grows with a new language – Elixir – I set my expectations high. What can Elixir possibly offer to compete with my Erlang focus? In short: everything. And nothing.
Clojure for Domain-specific Languages
One of the core strengths of any Lisp, Clojure included, is their support for domain-specific languages (DSL). Writing a DSL in Clojure is a natural and low ceremony design technique. Perhaps that's the reason why the existing literature has been sparse on the subject; there's not really anything special about the mechanisms behind a Clojure DSL. But even if the mechanisms are straightforward, other design decisions are more challenging. An embedded DSL always imply a trade-off. For example, when things go wrong we want to report errors in the language of the domain yet include enough information for the client to react on. A DSL is also challenging from both a syntactic and semantic perspective. A book covering those aspects with balanced discussions on trade-offs would be a welcome addition to my Clojure bookshelf. Unfortunately this book falls short on meeting my expectations, both from a technical perspective and from its content.
Clojure High Performance Programming
Clojure has several good introductory books by now. Clojure Programming is a pragmatic introduction that I always recommend to newcomers. The Joy of Clojure is a strong second book on the philosophy of the language. I've enjoyed them both. But as Clojure programs hit the real world we need books like Clojure High Performance Programming. It presents an overview of the performance characteristics of different Clojure constructs, explains basic profiling techniques and optimizations on different levels. Besides introducing an important subject it also deepens the understanding of the Java ecosystem where most Clojure programs live. The book presents a natural next step for the intermediate Clojure programmer.
Speaking at NDC Oslo
I'm proud to announce that I'll be giving a talk at NDC Oslo. My talk will be about Code that fits your brain where I set out to answer the question of how code should look to fit the way we think, remember and reason. It'll be a session that combines code in C#, Erlang and Clojure with findings from different fields of psychology. Hope to see you in Oslo!
The Art of the Metaobject Protocol
The basic idea of a metaobject protocol is to implement an object system using its own constructs as building blocks. The fundamental constructs available to application programmers, such as classes, generic functions and methods, are themselves instances of (meta)classes. While the resulting design is remarkably consistent and clean, the big win is that a metaobject provides an extremely powerful extension mechanism. The metaobject protocol behaves like an interface towards the language itself, available for the programmer to incrementally customize. Just as we can specialize and extend the behavior of the classes we define in our own applications, we can now extend the language itself using the very same mechanisms. It's a design resulting from the direct conclusion that no language will be universally appropriate for all problems. Instead of fighting the language, the programmer adapts and evolves it to the problem at hand. The Art of the Metaobject Protocol (AMOP) is a wonderful book to learn about these topics.
The Soundtrack to Code
To a programmer, noisy work environments are a devastating killer of job performance. Surprisingly, most workplaces still seem to ignore the problem and leave the root causes untreated. Instead the symptoms of a deep, severe problem are left to the individual programmers to address. The following essay discusses the consequences, perils and possible remedies from a cognitive perspective.
New book: Lisp for the Web
Dear reader, I'm proud to announce my new book Lisp for the Web. The idea with the book is to convey a feeling of how it is to develop in Lisp rather than focusing on the details. In the process we'll find out how a 50 years old language can be so well-suited for modern web development and yes, it's related to all those parentheses.
I wrote the book to be read. Thus is opted for Leanpub's variable pricing model. That means you can get the book for free. Just head over to Leanpub, download the book, get the source code and let's make programming just as fun as it always should be.
Join me at Jfokus 2014
I'm proud to announce that I'll give a talk at Jfokus 2014 in Stockholm. My session will be my final delivery of Code as a Crime Scene, a talk about identifying design issues and productivity bottlenecks in large-scale software systems. As a bonus, I promise to take you from Jack the Ripper to Java in just two slides. Hope to see you there on the 5th of February.
Object-Oriented Metrics in Practice
Over the past decade I've used metrics in virtually all of my non-toy projects. The degree and kind of metrics I use always vary with the challenges of the task at hand. I use metrics to guide me and help me answer questions about the design and progress. I've also made an active effort to let the metrics stay in the background as just one, out of potentially many, sources of information. Use them to guide, but ensure you collect more qualitative information before acting upon potential problems. To me that's a crucial factor in the successful application of metrics; make them an end in themselves and things start to fall apart rapidly. And it won't be pretty.
Clojure Data Analysis Cookbook
Learning Clojure was a rewarding experience. Not only is the language itself a marvel of elegance. There are also several good books available. I'm glad that the Clojure community has continued the Lisp tradition of exceptionally good books. My two favorites turned out to be The Joy of Clojure and Clojure Programming. I often turned to them for advice. But reading books only takes you so far. All learning is based upon a feedback loop. Without diving into learning theory, suffice to say there's a lot of support for the idea of learning by doing. For me, to really grasp a language, I want extensive programming experience with it. I need to make mistakes, learn from them, and see my designs improve as I accumulate more expertise and memorize the basic idioms. To get that experience with Clojure I decided to code my side-projects in the language. After a few web-apps and smaller utilities, my interests turned to data mining and analysis. And in that context, Clojure Data Analysis Cookbook is a great next step.
Code as a Crime Scene
Technical challenges rarely come in isolation. In any large-scale project they interact with social and organizational aspects. To address that complexity we need to look beyond the current structure of the code. We need strategies to identify design issues, a way to find potential suspects like code smells and team productivity bottlenecks. Where do you find such strategies if not within the field of criminal psychology?
Loving Common Lisp, or the Savvy Programmer's Secret Weapon
A programmer approaching Common Lisp from an OO background is in for a challenge. I know, since I've made that transition myself. But it's a challenge well worth the effort; learning a high-level multi-paradigm language like Common Lisp will change the way you look at programming for the better. To ease the task, a Common Lisp newcomer is lucky to have several high-quality books available. My personal favorite is Practical Common Lisp. Once you've worked through that one, the Lisp field is rich with exceptional books on more advanced aspects of the language (PAIP, SICP and LoL are all highly recommended). All these books focus on the core language. What I've been missing is a hands-on approach to real, large-scale development. Such an approach would necessarily include the usage and application of the powerful open-source libraries available to Common Lisp programmers. Loving Common Lisp is a step in that direction.
Dawn of a new domain
What a great summer it was! I got married to my beautiful Jenny and changed my family name in the process; Petersen became Tornhill and moved to this new domain. Welcome, dear guest!
Paradigms of Artificial Intelligence Programming
Back in 2005 I started to publish my book reviews on these pages. My long term goal at that time was "to create lists of recommended reading on different subjects". Since then my collection of reviews has grown substantially even though I don’t review every technical book I read. The ones is publish make-up around every 3rd or 4th book I read. In my published reviews I always try to cover both ends of the awesomeness spectrum; good books are reviewed to provide the recommendations and, perhaps even more important, I write about the occasional, lousy book too in order to save your time and effort for something actually worth it. Just the other day I noticed that I haven't reviewed one of my all time favorites, Paradigms of Artificial Intelligence Programming (PAIP). I decided to immediately restore the order and churn out a review. PAIP is one of the best programming books ever written. It's also considerably broader in scope than its title suggest and a book I always recommend to the ambitious programmer.
CodeMaat: The history of our code predicts its future
I just published an early version of Code Maat, an open-source command line tool used to mine and analyze data from version-control systems (VCS).
The Wisdom of Psychopaths
Psychopathy is characterized by fearlessness, ruthlessness and lack of empathy, all hidden behind a mask of superficial charm. Psychopaths cause a lot of harm. People that get in their way are ruthlessly exploited and left behind in the trails as the psychopath moves on. At the same time, given the long history of psychopathy it's reasonable to assume that its traits, at some points in our historic past, have given their carriers an evolutionary advantage.The irony is that today, in our frantic, high-paced modern society, psychopathic traits may be more of an advantage than ever. In this controversial book, Kevin Dutton gives his take on the subject in a witty, intelligent and genuinely fascinating form.
Snakes in Suits
Whereas the media picture of psychopaths generally goes along the lines of a Hannibal Lecter stereotype, the real world is more diverse. Most psychopaths aren't violent killers. Their violence is often instrumental and in most cases psychological rather than physical. Interestingly enough many psychopaths are found in the corporate world, surprisingly often riding the wave of seemingly successful careers. In this book, organizational psychologist Babiak and the world-renowned expert on psychopathy Hare describe the potential damage a psychopath does to an organization as well as advices and strategies to cope with and to avoid recruiting psychopaths in the first place.
OCaml from the Very Beginning
Learning a new programming language is always a challenge. It's not so much about getting accustomed to a new syntax or memorizing a bunch of reserved words. Rather, the challenge lies in learning to think different. It's about how to think in the new language, how to express thoughts in it and ultimately solve problems in an idiomatic way. That challenge grows if the language is based on an unfamiliar paradigm. Today, functional programming presents such a challenge to a whole generation of object-oriented programmers. With its no-prerequisites approach, OCaml from the Very Beginning offers a first step onto the functional road that will be useful no matter what technology you ultimately decide to invest in.
Growing Object-Oriented Software, Guided by Tests
One of the challenges of traditional Test-Driven Development (TDD) is to maintain an overall sense of direction while taking baby-steps towards the goal. As I started out with TDD in the early 00's, I noticed something surprising about my software solutions; while I benefitted from the flow and feedback of TDD, I often lacked an overall idea of what the resulting software looked like. I had to build that understanding after the fact in order to reason about future changes and analyze the impact of new requirements. My response was to combine my test driven approach with some sketching and diagrams in order to keep track of the overall design. The goal of my sketches was to identify the main components and, more importantly, the relationships between them. I put-off coding until I had a basic understanding of the solution space. I let my sketches remain a starting-point and allowed myself to deviate from them as I learned more. My lasting impression is that TDD works well in certain contexts but has to be complemented with other ideas. This book presents one such viable TDD approach.
The Nature of Code
The Nature of Code is a beautiful introduction to simulations of natural systems. Through Daniel Shiffman's concise prose, clear illustrations, carefully chosen systems and detailed code samples the reader is guided through the basic math behind our physical world into the corresponding computer representations in the Processing language. While Processing may not be the most elegant programming language in existence, it sure serves the purpose of this book.Visualizations are always low ceremony in Processing which allows the reader to focus on the concepts instead of the mechanics to express them. This is important because The Nature of Code goes well beyond Processing. The book is a solid introduction to basic game physics, randomness, genetic algorithms, cellular automatons, neural networks and much more.
Born in the MIT Media Lab, Processing is a language and environment for creative coding. With a simple and visually responsive environment, Processing targets artists and designers. The feedback loop is short and the language allows interesting creations with a minimum of overhead. Given its flat learning curve, Processing also serves remarkably well as an introduction to programming in general. And that's the intended audience of Daniel Shiffman's book. Learning Processing is aimed at absolute beginners.
Framework Design Guidelines
Consistency is a key-characteristic of all well-designed software. Consistency is also one of the most challenging aspects of any large-scale project. As such I've came to view the main purpose of software architecture more as a set of principles and guiding decisions towards consistency and conceptual integrity rather than taking the traditional and largely dysfunctional view of architecture as a system blueprint. Such a set of architecture and design principles would ideally represent a layered model. A model that goes all the way down to individual classes and functions. To those lower layers, Framework Design Guidelines provides an excellent basis for API consistency on both syntactic and semantic levels.
Our world of mainstream software development is driven by fashion. Methodologies come, make an impact on many organizations only to eventually be replaced with some new promising idea. The cemetery is getting stacked with a growing pile of dead methodologies. After CMM we were extreme before we became agile. Test-Driven Development should be used for everything. Oh, wait, we're behavior driven now. The progress is based on failures past. New methods to solve problems introduced by the previous silver bullet. While I personally see value in many of these ideas, something nasty happens the moment they hit the mainstream.
The Joy of Clojure
Languages evolve idioms for a reason. Idioms are mental shortcuts to expressive and robust solutions. They are the sign of expertise and true understanding. Mastering those idioms is the hardest part of learning any language. Given that Clojure has been around for almost six years now it has grown its fair share of idiomatic constructs. Some of them are radically different from other Lisps. The Joy of Clojure captures these idioms and serves as a guide for the intermediate Clojure programmer looking to bring his command of Clojure to the next level.
It's been three years since I embarked on my Clojure journey. I'd been following the language for some time before I wrote my first small programs. Clojure was this promising new language designed for a multi-core age and fueled by the potent open-source eco-system of the Java world. Most important to me, it was a Lisp. I've never got to spend enough time with Clojure. But I tried to keep up to date with the development, waiting for an opportunity to pick up Clojure where I left. As the opportunity knocked, Clojure Programming turned out to be a great guide to the simplicity and practicality of Clojure.
The Signs of Trouble: On Patterns, Humbleness and Lisp
As software developer and author of a technical book on patterns I obviously find value in the pattern format. And as a psychologist I see the links to our cognitive capabilities and the social value of patterns. In this article I will detail my view on patterns and the value I see in them. Since patterns are a controversial topic, I will build the article around the criticism against patterns. Let the critics have the first word.
Let me state right up front that I'm not in the intended audience for this book. Fluent C# is a book for beginners to programming. Although I do feel like one from time to time, I've spent the better parts of my adult life hacking together software systems of all scales. Reviewing a book for novices is hard. My view will be quite different. A reader with little programming experience is likely to focus on other aspects and will probably face different problems. So why did I opt to review it? Well, this book claims to be different. It's based on principles of cognitive science and instructional design. Both topics I have an interest in. From that perspective parts of the book provide an interesting read. To a beginner interested in learning C#, the technical inaccuracies are likely to become an obstacle.
Patterns in C - The Book
Dear reader, I'm pleased to announce my first book, Patterns in C. Patterns in C is a collection of idioms, design and architectural patterns in the C programming language. The book highlights the value of patterns. In the right context, patterns serve as an excellent tool for communication and reasoning. The book provides a C programmer with techniques to benefit from the growing body of knowledge captured in patterns.
Erlang and OTP in Action
Learning Erlang is an experience that alters how you view software. Technical challenges, traditionally viewed as hard, suddenly come within reach. You might even find that Erlang's radically different approach makes them non-issues and solved problems. Challenges like scaling on multi-cores and writing reliable distributed applications all fall in this category. Within it's domain of soft real-time systems, Erlang is unparalleled in power. It's minimalistic approach and simplicity makes Erlang a true joy to code in.
Development Fuel: software testing in the large
July 2012 (co-autored by Adam Tornhill and Seweryn Habdank-Wojewodzki)
As soon as a software project grows beyond the hands of a single individual, the challenges of communication and collaboration arise. We must ensure that the right features are developed, that the product works reliably as a whole and that features interact smoothly. And all that within certain time constraints. These aspects combined place testing at the heart of any large-scale software project.
This article grew out of a series of discussions around the role and practice of tests between its authors. It's an attempt to share the opinions and lessons learned with the community. Consider this article more a collection of ideas and tips on different levels than a comprehensive guide to software testing. There certainly is more to it.
The Architecture of Happiness
I have a long running interest in architecture. Not just because of its metaphorical relationship to software architecture; since the dawn of large-scale programming projects, the software community has borrowed both terminology and design philosophy from the discipline of architecture. Sometimes, one could argue, the parallels have been stretched beyond the limits of both use and reason. Like later parts of the design patterns movement that sprung from the work of architect Christopher Alexander. Instead I appreciate architecture for its intrinsic artistic values.
Recently I revisited an old blog post by Kathy Sierra. The work of Kathy has been a main influence on my own career. Her always brilliant writings are one of the reasons I once choose to embark upon a learning journey outside my own technological field. So far it's been a journey that took me through a degree in psychology and continues to this day. When I read her reference to David Gelernter's Machine beauty as her favorite book on aesthetics and technology, I knew it had to be good.
Back in 1988 a study by Curtis and colleagues identified the thin spread of domain knowledge within development teams as one of the major problems with building large, complex systems. The situation hasn't improved much since then. Yet domain knowledge is fundamental to any project. Not only in order to know what problem to solve; domain knowledge is a key to successful software design. A hallmark of a great design is the proximity between the problem expressed by the domain and the solution expressed in code. The closer they are, the easier the reasoning and understanding of the design. Eric Evans' book is an authoritative source on the concept of such domain modeling.
97 Things Every Software Architect Should Know
97 Things Every Software Architect Should Know is a collection of edited blog post. The core idea is to let experienced software architects present valuable principles on various development issues. Issues that span a wide range of areas and often go beyond technology. Although an honorable idea, the execution failed to meet my expectations. In general I like collections like this. I'm ready to accept that, given a broad range of subjects and authors, some articles will interest me more than others. This is the case with 97 Things Every Software Architect Should Know too; the problem is just that the interest to non-interest ratio is way too low to motivate the investment in time of reading it.
In the Theater of Consciousness
The human consciousness may well be one of the hardest problems of science. Everyone of us is aware what it feels like, yet there's a mystic quality to how a biological machine can give rise to subjectivity and self-awareness. Worse, we're trying to solve this grand problem by use of the object itself, our brain. It's a quest for something we may never reach. As illustrated by the failures of great minds like Descartes and Locke, our search may well turn out to be futile. Yet there's a growing body of modern research into consciousness. Research that provides new insights into the nature of consciousness and its role. Understanding these properties of consciousness is a necessity, not at least from an ethical perspective emerging out of the ever deeper uncanny valley.
The ever increasing focus on software testing may be the single most valuable contribution from the agile community. Development methodologies like Test-Driven Development (TDD) are now mainstream and the quest for further automation goes on. Complete systems are developed, driven by high-level test cases. The resulting applications are delivered with extensive regression test suites. And on the way, the test cases serve as an excellent communication tool. Done right, test automation enables an interesting and efficient way of working. Surprisingly, one of them is that valuable time spent on manual testing may be both more focused and increased. On several occasions I've also experienced how non-trivial features may be implemented rather late in the projects. Unfortunately I've also experienced several pitfalls of both testing practices and test automation. And since I spend a significant amount of my professional (=paid) time on test automation, I've been looking forward to read Agile Testing for a while now. My verdict may come out hard, but I do see serious issues with the book.
Dive into Python 3
Python has been on my radar since early 2003. Back at that years ACCU conference, Guido van Rossum gave a keynote on the evolution of Python and the philosophy that shaped the language. I liked what I heard and actually made an effort to learn Python some years ago through Mark Lutz book Learning Python. My goal at that time was to use Python in my everyday scripting automating repetitive tasks. Somehow I ended up using different Lisp dialects instead. Clojure, Common Lisp, even newLISP at times. Lisp worked beautifully, but it was only part of the reason I never made the transition to Python. In retrospect, I think it had more to do with motivation. As I reviewed Learning Python, I remarked that it was "too basic and slow paced". I simply lost interest as I read along. At the end, Learning Python made me wish for another approach that started "by a small, yet real-world example, and walk us through the program design step by step". Little did I know that Dive into Python takes exactly that approach.
Earlier this year I finished a course on geographic profiling. Our course was based on books edited by David Canter. The course material was great, yet Davids own contributions stood out as extraordinaire; David Canter has a gift for making complex science accessible without loosing any relevant details. Coincidentally, a year ago, I attended the Oxford Literary Festival where David Canter presented this book. And now I finally got around to read it.
Code Patterns updated
I've made some updates to my Code Patterns article after feedback from Steve Love and the C Vu review team - thanks! The most significant change is an expansion of the Patterns chapter.
Lisp for the Web, part II
A few years ago, I wrote an article called Lisp for the Web . My intent with Lisp for the Web was to show that Lisp is a relevant high-level language with unique features. Unfortunately, the original article is becoming slightly dated with respect to the third-party libraries used. Thus, it was a pleasant surprise as Matthew Snyder wrote me and announced a sequel.
Matthew did a great job with Lisp for the Web. Part II . He's clearly taken it to the next level and makes sure to include some new features (e.g. writing CSS in Lisp, jQuery in Parenscript, and a test suite). Personally, I find it rewarding that he found my work interesting enough to build upon, improve and extend.
New article: Code Patterns
This year marks the 10th anniversary of my Test-Driven Development (TDD) career. It's sure been a bumpy ride. If a decade of experience taught me anything, it is that the design context resulting from TDD is far from trivial. TDD is a high-discipline methodology littered with pitfalls. In this article I'll look at the challenges involved in introducing and teaching TDD. I'm gonna investigate something we programmers rarely reflect over, the form and physical layout of our code, and illustrate how it may be used as a teaching-tool.
Interfacing Erlang from C++: tinch++ 0.3.1 released
This new version of tinch++ introduces support for boost versions up to 1.46.1. tinch++ is still backwards compatible to boost 1.42.1 but I do recommend upgrading to the latest boost version. Also some words on the future of tinch++ and the planned new standard C++0x.
On Intelligence is Jeff Hawkins radically different approach to machine intelligence. While traditional AI has leads to several useful products, it becomes clear early on that Hawkins is out for something radically different. Or, as he puts it himself, traditional AI scientists "left out the most important part of building intelligent machines, the intelligence". I do think Hawkins is spot on here. He seeks the failure of AI in its focus on behavior (a tradition with roots dating back to behaviorism, the direction that dominated psychology as AI was born). Even if AI will continue to deliver value it simply won't lead to truly intelligent machine. Rather, intelligent machines have to be based on how the human brain works. In this excellent work, Jeff Hawkins defines such ideas in his unifying memory-prediction theory.
Pro .NET 4 Parallel Programming
Last month I wrote about "Design Patterns for Decomposition and Coordination on Multicore Architectures" . The patterns target the .NET framework and build heavily on the .NET 4 parallel programming constructs. While providing detailed code samples capturing the idiomatic usage in C#, the book doesn't really focus on the language details. Rather, a potential reader is expected to master the basics in order to make qualified decisions and balance trade-offs between different implementation techniques when applying the patterns. My idea when starting to read Pro .NET 4 Parallel Programming was that the book would fill the role as preparation for such high-level material. I hope you caught my usage of past tense. Even if things looked promising, all expectations fell flat.
Design Patterns for Decomposition and Coordination on Multicore Architectures
Over the last years, trends and developments in hardware architectures have driven software increasingly into parallelism. With Java's concurrency libraries and the parallel extensions to .NET 4, parallel programming is indeed entering the mainstream. But adding language and library support on top of these imperative languages, designed with a sequential programming model in mind, is challenging to say the least. Given that constraint, the .NET extensions are quite impressing. And Parallel Programming with Microsoft .NET is a high-quality book that makes an excellent job in capturing idiomatic usages in C#. Even if I'm in favor of this book, the technology it presents worries me. Join me, and I'll explain before returning to the parallel patterns themselves.
C# 4.0 in a Nutshell
I do love the irony that a programming language designed with the explicit goal of being simple ends up with a +1000 pages tome just to capture its essentials. And I do love to contrast it to John McCarthy's original Lisp definition taking up basically a single page. Language design aside, C# in a Nutshell served me well in getting up to speed with the language.
Effective C#: 50 Specific Ways to Improve Your C#
As the millennium was young, I plowed through Scott Meyers Effective C++ books in order to bring my C++ skills up to date. And reading Meyers books saved me a lot of time by helping me navigate the minefield that large-scale C++ is. I still consider Meyers books essential reading for anyone serious about C++. As I recently needed to sharpen my C# skills, getting Bill Wagner's book was a no-brainer. Unfortunately Effective C# doesn't deliver on the same high level as Scott Meyers books; it's not that it is a particularly bad book, it isn't, but it sure has its flaws.
The Mind of a Mnemonist
Imagine having a long list of made-up nonsense syllables read to you. And imagine being able to remember them and repeat the list in any requested order. Impressive, isn't it? Now, imagine being asked, without any prior warning, to repeat the performance a decade later. How much would you be able to remember? S. did not only remember the exact setting where the original testing took place; he could also repeat the original list without any errors in recall. Thanks to A.R. Luria's fine work we get a view of the mechanism behind the apparently limitless memory of S. Further, Luria examines the consequences of living with such a memory; how does it impact personality and what are the weak contra strong points of such a person? The result is a classic book and a highly fascinating glimpse into an amazing mind.
The Art of Multiprocessor Programming
The free lunch is indeed over. As the processor manufacturers reached the practical limits of single core designs the new multicore architectures entered the mainstream. The challenge for us software developers is to make programs that scale on all these multiple cores. It's a challenge that calls for radically different technologies and a different kind of programming. The Art of Multiprocessor Programming turned out to be a really good introduction to the building blocks used for parallelization. But make no mistake - it's a hard read.
Psychopathology of everyday life
The Psychopathology of everyday life may well be Sigmund Freud's most accessible work. Psychopathology follows in the steps of its one year older relative, The Interpretation of Dreams . The book is built around lots of small anecdotes of apparently innocent and insignificant everyday events like the forgetting of names, misspellings and slips of the tongue. I write "apparently" because Freud's psychology was based on the idea that these innocent slips represented "unwelcome, repressed, psychic material, which, though pushed away from consciousness, is nevertheless not robbed of all capacity to express itself".
For a long time, we could count on the chip manufacturers to simply provide ever faster processors with ever increasing clock frequencies. As the chip manufacturers hit the practical limits of single core design, the answer is to increase overall capacity by putting multiple processors on a single chip. These multicore computer architectures have now entered the mainstream. And the challenge for software developers is to make programs scale and take advantage of multiple cores. It's a different kind of programming.
Rework offers a glimpse into the world and business of 37signals. Originally a web design company, 37signals grew into a product company with a line of web-based applications. And it was during the development of their first product, Basecamp, that David created the Ruby on Rails framework. 37signals have remained profitable the whole way and in this book they share some of their insights and highly opinionated ideas on how to run a business.
tinch++ version 0.3 released
tinch++ is a platform independent, open-source library for interfacing Erlang from C++. This new release introduces binary Erlang types, bitstrs (a binary whose length in bits isn't a multiple of 8), and RPC with user-defined timeouts.
Drive: The Surprising Truth About What Motivates Us
In his previous book, A Whole New Mind , Daniel Pink declared that we're on our way to become obsolete. The future belongs to a different kind of person with a different kind of mind. Traditional "right-brain" skills like design, story, empathy, and play are what matters in the dawn of the conceptual age. A Whole New Mind was one of the most rewarding non-fiction books I read last year. As Daniel Pink now continues by looking into what motivates us, I set my expectations high.
The Art of UNIX Programming
The Art of UNIX Programming (TAOUP) gets my vote for the most misleading title ever. The book contains very little code, which is quite surprising given a book about, well, programming. Rather, TAOUP offers a look at the history of UNIX, its community and design philosophy. If I should put the book in any category, it would be software architecture. TAOUP covers the whole spectrum of high-level decisions involved in building software. Everything from protocols, GUIs and domain-specific languages to documentation and licensing models. And despite the UNIX (defined to include Linux) in the title, the greater part of the book is applicable to software development in general.
A year ago I read Stuart Halloway's Programming Clojure . Stuart's book is a solid introduction to the language. I expected Practical Clojure to complement it, explore the language in more depth and at a larger scale. The title obligates. I remember my first pass through Peter Seibel's Practical Common Lisp five years ago. The very first sentence breathed excitement, promising to change the way the reader looks at programming. As I got to chapter 3, the first practical chapter, I understood what makes Lisp different and why I want to use it. The rest of the book delivered to its promise, illustrating how to solve non-trivial problems in an expressive and elegant way through the unprecedented power of Lisp. I expected Practical Clojure to follow that style and do the same for Clojure as Peter did for Common Lisp. I was in for a hard disappointment.
tinch++ version 0.2 released
tinch++ is a platform independent, open-source library for interfacing Erlang from C++. This new release introduces process links between mailboxes and remote Erlang processes.
The Design of Design
Fred Brooks is the author of one of the true classic texts on software development. His Mythical Man-Month is a tremendously influential book and one of the most frequently quoted texts on project management. Despite being written in the 70's, and describing a project from the 60's, the Mythical Man-Month hasn't lost a tiny bit of relevance. In a way, this is worrying for the software industry; we keep repeating the mistakes Brooks described 35 years ago over and over again. Sure, sometimes we dress them up in fancy new concepts and methodologies, but the underlaying fallacies are the same. To some extent this obviously indicates a failure to learn, but there's more to it. The Mythical Man-Month isn't a technical book; it's about people and people really haven't changed much since the 60's.
Linux and the Unix Philosophy
In many ways I was lucky. My first job was in a company basing their development and products on Unix. Thus, it was a natural step to use Linux at home for my own programming projects. I never reflected much on that decision. Fast forward ten years. I switched company and started development on a Windows-based platform. At that time I didn't know what to expect. How bad could it possibly get? Well, it turns out that most of the techniques, flexibility and simplicity I had taken for granted were gone. What used to be a few lines of a shell script transformed into a manual and expensive process. I learned the hard-way that an operating system is not just technique; when you choose technology, you also choose a community along with its unique culture and philosophy.
I use to travel to Vienna a few times a year. While there, I always buy a stack of books in order to keep my German language skills alive. As a psychology student, I often head for that section in the bookshop. And believe me, Freud and psychoanalysis are still huge in Vienna. Over the last years, I've read several of Freud's publications. With my language goal in mind, Freud is actually a good choice. Freud was a great writer and Eric Kandel even puts him on par with literary giants like Franz Kafka and Thomas Mann. As far as his psychology goes, things look different though.
Programming in Prolog
Prolog is one of those languages I've been curious about. I had two reasons for my curiosity. First, I try to follow the sound advice of the Pragmatic Programmers and learn a new language each year. To get the most out of it, the languages should be as diverse as possible. Second, I wanted to learn more about the roots of Erlang. At birth, Erlang was implemented as an interpreter in Prolog. Since then, Erlang has obviously come a long way, but its Prolog heritage is still quite prevalent.
Distributed Erlang nodes in C++
tinch++ is a platform independent, open-source library for building distributed Erlang nodes in C++. Distributed Erlang nodes provide a high-level model for integrating other languages with Erlang programs. With tinch++, your C++ code will be able to communicate with Erlang processes by means of message passing. To the Erlang processes, your C++ node will look and behave like any Erlang node.
The Mind Map Book
Mind maps are an efficient technique for organizing thoughts around complex areas, be it in business or daily-life. Tony Buzan is the inventor of modern mind mapping (the concept of mind maps actually have a much longer history ). I use mind maps a lot when attending presentations, learning a new domain, or understanding an existing program. I read this book with the goal of making my mind mapping more efficient and understand how it's really done.
The Time Paradox
The Time Paradox is all about our attitudes towards time. Its core message is that we all have a unique, biased time-perspective that influences our decisions and behavior. Yet we're normally not aware of it, hence the paradox. This book makes us aware of our personal time-perspective and how it influences our feelings, actions, and future. It also promises to teach the ideal time profile and provides us with the tools to get there.
Coders at Work
Wow! This is an amazing book. I've been looking forward to Coders at work since Peter published the first names on his blog two years ago. Given Peter's track-record , I knew he would do a terrific job, yet I'm positively surprised. Coders at work is a book that I recommend, without any reservation, to anyone interested in programming or aspiring to become a programmer. It's that good.
Masterminds of Programming
A book featuring interviews with the minds behind
several historic and highly influential programming languages
promises to be an interesting read. And indeed it is, although
much of the books potential value is lost due to omissions and flaws.
Erlang was designed to solve real-world, practical problems. And it was designed to solve those problems in an elegant way. To me, Erlang is a perfect blend of research oriented towards practical applicability in the industry. The language itself is small and with a background in functional programming I found it quite easy to learn. But from learning the syntax and writing some simple programs to actually get a feel for how systems are designed, well, that step is huge.
Clojure is the most exciting and innovative addition to the Lisp language family in a long time (sorry, Arc ). With the 1.0 release of Clojure just outside the door, Programming Clojure is perfectly timed. I've followed the development of Clojure over the last year and had high expectations on Stuart's book. Let me say that I'm impressed. Both with Clojure the language and with this book.
Structure and Interpretation of Computer Programs
Structure and Interpretation of Computer Programs (SICP) is one of the true programming classics. It's a well-deserved position; SICP is simply the best programming book I've ever read. I made my first pass through it a year ago but deliberately postponed my review; reading SICP completely changed the way I approach programming. Thus, I wanted to get some distance to my reading experience and a chance to judge how much influence SICP would have on my everyday programming. I found that SICP does two things for you: it improves your coding no matter what languages you use at the moment. SICP also serves as a platform for learning new languages and techniques by building a foundation and context for your future learning.
A Whole New Mind
We're all about to become obsolete. Just like the industrial worker of the 19th century got replaced by machines, or made superfluous as production moved to cheaper countries, the knowledge worker of the 21th century is facing outsourcing and ever growing global competition. Or at least, that's Daniel Pink's hypothesis. To survive, we need to broaden our skills. We need to look past our traditionally valued linear and logical thought-processes and develop more, in pop-science terms, "right-brain" skills like design, story, empathy, and play. In other words, we need a whole new mind.
What attracts me about Python is its simplicity. And I mean simple in the right way through a minimum of accidental complexity and not, like Java, by limiting the possible design space. I plan to use Python for much of my everyday scripting and was looking for a book that quickly got me up to speed. With that goal, Learning Python was far from a perfect choice.
Pragmatic Thinking and Learning
Andy Hunt's new book fills an important gap. While much of the people-oriented work in the software industry targets better and more effective ways to work, I've always lacked the focus on what really matters: our skills. At the end, the ability to constantly learn and evolve is what really makes a difference. It's not just about new languages and tools; we have to learn different problem domains, understand the challenges they possess, and address them with creative solutions. Drawing on research in cognitive research and learning theory, Andy explains how we can learn more effectively and boost our creativity.
Over the past 10 years, I've learned a lot from Robert C. Martins writings. His previous book was a rewarding read and I had high expectations on Clean Code. It covers a vitally important area: the quality of our code matters. Any book that manages to teach us how to develop clean code is mandatory reading in my world. Unfortunately, I cannot put Clean Code in that category.
The Lucifer Effect
The person-situation controversy stands as a theoretical divide in the field of personality psychology. Historically, the former camp held the upper hand emphasizing the individual's inner nature, personality traits, and even the character in explaining behavior. Zimbardo challenges that view by explaining how situational forces can bring good people into antisocial and destructive behavior. The Lucifer Effect is an important book well worth reading for several reasons.
The Soul of a New Machine
Back in the 1970s, Data General was known as the "Darth Vader of the computer industry". The company had some success selling their 16-bit Eclipse machines, but times were changing; DEC had just released their 32-bit VAX and it was clear where the future was. The soul of a new machine is the story of Data General's struggle to create a new computer to compete on the 32-bit market.
Dreaming in Code
In 1981 Tracy Kidder gave the world The soul of a new machine . The book described how a new computer came alive. In the process, Kidder wrote some of the best portraits of the developers behind the machine and the motivational factors that drive them. A quarter century later, Scott Rosenberg tries to do the same for software as Kidder did for hardware.
Forth has the characteristics that make a language attractive to me: expressiveness, minimal syntax, immediate feedback, and a natural way to grow. Combining these properties sets the stage for good design by iteratively letting us build the language towards concepts in the current problem domain. Forth also puts the constraints where they should be; on the skill and creativity of the programmer. Thinking Forth describes a way to think about programming as a creative process. And it does so in an entertaining and pedagogical way. The result is a brilliant work that stands as some of the best software writing I've read.
Previous books (e.g. Hackers and Founders at Work ) have told the story about Steve "Woz" Wozniak's groundbreaking creation: the Apple II computer. The Apple II not only set a completely new standard for computers that carried Apple the company into a multimillion dollar business; Apple II is also widely acknowledged as a beautiful piece of design and technical brilliance. As Steve Wozniak finally writes his autobiography, I have high expectations. Like any biographical work, I'm expecting to get a view into that persons unique mind; to understand how he thinks and get an idea of his personality. In this particular case, I'm also expecting to understand the events and thoughts that lead to the creation of Apple II. Based on those criterions, this book is a success. But iWoz has its limitations and left me with the feeling that it could have been so much more.
Hackers: Heroes of the Computer Revolution
Hackers is the story of the early days of computers. From a time when hacking was truly underground and a single computer took up an entire room, over the microprocessor revolution, to the booming videogame industry of the eighties. Through the whole journey Steven Levy lets us step into the great minds of the early hackers, understand their motivations and why programming is so fascinating. The result is a classic book that is of significant importance even today.
Smart and Gets Things Done
The title "Smart and Gets Things Done" refers to the criterions you look for in a technical interview. These are the candidates you want to hire. But there's more to hiring technical talent than an interview, hence the rest of the book.
First of all, Joel motivates why you should care about finding the best developers. To any programmers who care about their craft this is obvious; there's a tremendous variation not only in productivity but also in quality between programmers. And it's simply not a matter of throwing more man-hours on the problem, let's say by hiring 10 mediocre programmers instead of a really great one. Brooks law provides an economic argument against that idea. Besides that, a great programmer writes code that lesser skilled programmers will never, ever be able to deliver. On some level, most managers understand this. The problem is that almost everyone does little more than paying lip service to the idea. Joel not only understands it, he also bases his company on the idea and provides some rather convincing data and discussions. It's an interesting and important introductory chapter that sets the stage for the rest of the book.
Let Over Lambda
New Lisp books are rare, so this is a big event in my world (think Christmas, graduation and birthday at once and you're close). Let over Lambda is a self-published book of remarkably high quality. The first three chapters are available online, but in a way that's a shame; it's actually after these chapters that the book really takes of.
The introductory chapter makes clear that this is going to be highly opinionated and potentially flammable material. Doug doesn't shy away from breaking well-established Common Lisp idioms and holds strong opinions on both programming and language design (in Common Lisp, these two areas actually converge). Personally, I find it refreshing. At times it's a good idea to challenge conventional wisdom and get another perspective on how to do things. I may not change my initial believes, but at least it gets me to actively rethink my coding habits. That said, you do have to know Common Lisp pretty good in order to know that to sort out.