Welcome to Adam's Programming Pages!
Dear guest, I'm Adam Petersen, a programmer and part-time 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 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 Petersen 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.