Customer Reviews

The D Programming Language

5 star:		(24)
4 star:		(8)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

This book is one of the things D really needed to launch itself out of obscurity. It thoroughly explains the strengths of the language, why it is a practical language to learn and use, and it walks you through the more complex aspects of the language such as meta programming and concurrency/threading (which is often overlooked). As others have stated, it would be nice to have more real world examples - but then again, I never liked the books that have 5 out of 6 pages completely filled with code. This book is a good introduction to the rich toolset D provides - it's up to you to dig in and get experienced.

I've been using D regularly for about 2 years. When I heard about this book, I bought it more out of curiosity than anything. I was pleasantly surprised when this book revealed facets of D that I had not been aware of through two years of usage, library writing and forum surfing. Andrei's entertaining yet to-the-point style makes this a pleasant read, and he manages to cover both basic and advanced topics thoroughly yet succinctly.

First, a little context. I've been around the D community for a few years, keep a blog about items of interest to D users, maintain an open source D project and, in 2007, coauthored "Learn to Tango with D". Through all of that, the majority of my experience was with D1. I was hesitant, even reluctant, to use version 2 of the language because, in some ways, it is a bit paradigm shift from the first version. Andrei's book has dispelled any doubts I had about moving forward with D2.

D2 melds several different programming paradigms into one whole. One of the most radical differences from existing C-family languages is the concept of 'ranges', which are intended as an improvement over, and replacement for, the more familiar 'iterators' of other languages. Before the book, while ranges were being implemented in the alpha versions of the D2 compiler, some people had trouble wrapping their heads around ranges. Here, Andrei explains them in a way that makes them easy to grok and will have you using them in no time. And it's important that you do understand them as Phobos, D's standard library (which is intentionally not given much coverage in the book) has been reworked around the concept.

Aside from ranges and the more basic features of D which aren't so foreign, you'll also learn about D's interpretation of constness and immutability (D's const and immutable keywords are intended to improve upon the mess that is C++ const), and the D style of concurrent programming. D is poised to slot seamlessly in to the world of multi-core programming, with built-in features that simplify the process for those, like me, who can't think on that scale. Andrei's explanation of concurrency pitfalls and D's solutions should turn a light on for you if you're in the dark about it.

I've highlighted these particular aspects of the book because they are the areas about which I was most uncertain before reading it. But the entire book is well written, witty and easy to read. If you've never written a line of D in your life, you should have no trouble doing so after reading this book. I can't begin to speculate how much a beginning programmer might get out of it, but I would certainly recommend it to anyone who has at least a basic familiarity with another language from the C family. Andrei has that rare gift of taking potentially boring or complicated material and making it not only digestable, but fun.

Executive Summary: Well written book by experienced writer adds humor and style to a book that is designed to teach you how to program in D using D paradigms, but the book is not designed to be a D language reference manual, nor does it always reflect the language as compiled by current compilers. Misses 5 stars by a very narrow margin.

##

I have been a programmer longer than some of the people who read this book have been alive. Retired now, I still like to play at programming. I am intrigued by the technology of programming languages -- so many times they are playing to the flavor of the minute and have nothing to contribute. The number of times I have read in my career that this new, wonderful language would allow anyone to program, or would allow managers to determine what their technicians were doing, or would improve productivity, or some other wild claim, well, that sort of thing seems to happen on about 7 year cycles, and every 7 years, it is some other wonderful advancement in language that will make this possible, and the promises are not delivered on.

I have experience in C, Java, and several other Algol format languages as well as many others - I used to learn programming languages for relaxation. I decided to use the D language to implement a mathdoku (also known as Ken-ken) calculator - not a solver, I wrote something that would only process one cage at a time. This was not a large task - it ended up at just fewer than 2000 lines when written to parse command line arguments and output to a cmd or console window. But it was enough to allow me to actually use the book, as opposed to just reading it, and to use the book to look things up.

When I was working as a programmer, people would frequently ask me to recommend a book on programming or on a particular language and I would tell them, "go to a bookstore, flip through a number of books, and buy the one that "talks to you". You might pick a different book than I do because you are at a different level than I am." One major problem with D and this approach: there are few books that talk about D. But the book you want to have when you are reading to initially learn the language may be different from the book you want to have when you are writing code and looking in the book.

I truly apologize for the length of this introduction, and, for that matter, this review, but I felt that it was important for you to understand what level I approached the problem from and what I might have expected in a book about a programming language. Let's now continue to the D language and how I used the book, and where it failed.

As to this book, it is not a language reference manual; it discusses programming in D from a programmer's viewpoint and tries to make you into an efficient D programmer while teaching you some techniques about programming in D, as well as teaching you what is different. A D programmer, as opposed to a C++ programmer who happens to be programming in D, will use the language to help him to code effectively, using D paradigms. That is what this book is about. It will teach you D, as opposed to writing C++ programs in D or Java programs in D.

So, what is this language? It is supposed to be a language that is fast enough for operating systems programming, comfortable with bit manipulation (some subroutines that test bits are translated to assembly language sequences rather than being implemented arithmetically. It is the language that the author of the language wanted to program in, and it might be the language I want to program in - it is comfortable, without chafing too much. In many ways, the language is close to C++ - but, by default, it uses garbage collection as a primary memory management technique, for things like cleaning up objects.

In some ways it is like Java, but it does not lock you into the "reference to object" box.

I found that basic things were missing when I tried to use the book as a language reference manual. For example, I wanted to see if the language supported subroutines with optional arguments, essentially, polymorphic subroutines with a single declaration. C++ supports such subroutines, you specify the default argument with x=default, right where the model arguments are specified in the parameter list, and then the routine, even though it has only a single definition, becomes polymorphic - the arguments specified change the routine that is being called, slightly. The default is the value you want put in x if it is not specified by the caller. (Java does not have this feature - you can simulate it). This was a basic feature, and I searched for in in the book for a very long time, as a point. Would it be there? How would it be indexed? where was I supposed to be looking? I never found it. It might be there, but if so it was very hard to find. I found it easily in the online language reference at mars (home of D on the web), they are supported using the C++ syntax.

In D, plain variables have some attributes. Arrays have a length attribute - you can look at the length attribute to see if the array is a certain length or you can adjust the length of an array by setting it. The book says that the length is a lvalue and shows it being adjusted with a postincrement, as "array.length ++;" (Kind of a cool thing, it adds an array member to an extant array In an efficient manner but when I tried to do that, the compiler objected, and I found that I had to use the "array.length = array.length + 1;" idiom instead. When I looked online, I found that this had been discussed for some time and people had not come to a consensus regarding how to fix the parser to accept "array.length++" or even whether they should make that change. But I guess the book made the presumption that it would have been fixed.

These were minor things, but they were enough to cause me to drop the rating on the book from five stars to four. I am not doing this because of deficiencies in the language, but because the book should accurately reflect the language. In any case, I don't feel that this sort of reference is what this book was written to be. Also, given that D is a new language, the classical language reference manual would have been appreciated, so that I ended up with a one stop shopping spot for D.

D has native support for hashed arrays. An array can be indexed, not only by a numeric that must be more or less continuous, but by any basic type. You can have array["fred"] if the array is declared that way. I had a routine that was being called over and over again with the same argument, and I wanted to shield it from the duplicate processing. It was simple to take the arguments and make a hash out of them, then determine if they were already in a hash, and to break out of the routine early if they were there or to continue the subroutine after adding them to the hash if they were not. This is the sort of thing that one frequently does in Perl.

Such a routine (wrap a call in a hash lookup and only call the routine once for each hashed value) is already in the library but I thought I could do a better job of making the hash from the arguments since only some of the arguments mattered.

There was only a brief discussion of hashed arrays. If I had not been familiar with them from Perl, I might have found the book lacking.

But all in all, the book was good. No one book can be all things to all people on any complex language. But it was lacking in just a few things. No, not 5 stars, but close.
The writing of the book is excellent. Humorous, sophisticated, in a way that you usually do not see regarding programming manuals. Recommended - even if what you want to do is to steal features from D and install them in your favorite language.

After writing the program, I wanted to move it to my Android phone. That meant porting the program to Java. Java is similar to D in many ways. It uses Algol syntax, it is a garbage collection language, and it is object oriented. Large parts of the program simply ported. All of the hashed arrays became objects out of standard system classes. While Java has classes that allow one to do all of the sorts of things that I could do in D using the language's built in syntactic sugar, I found that, universally, the code was easier to understand when it was in D. It was more straightforward and easier to think about, when writing it and reading it - and, because the programs' processing was so complex, I can also say that it was faster by far in D - both in loading and in running. On my system, the program went from instant to a notable pause when loaded and when crunching. It might actually be faster on my cellphone. But I believe that the code is better for being written in D. It was easier to work out many of the algorithms in D than it would have been to do the same in C++ or Java. Whether this was a recompilation or the loading of the JVM, I can't guess.

Reading the program at this point is hard. The syntax of the hash indexed collection of objects is not straightforward as read. Things are so busy that you get lost in that busyness and you don't see the point of what you are doing. In many ways, you can't underestimate the value of syntactic sugar.

So, this book is not a language reference manual. It is more for a programmer who is a Journeyman who wants to add a language to their abilities - maybe not one with wide commercial applicability, but one that will allow you to see other ways of doing things. It will lead you through the language features, and it will do so while allowing you to appreciate some of the humor of programming - the writer's personality comes through over and over again - it is not a dry book.

D allows for programming metaphors you might not have used in other languages. The book spends most of its time trying to teach you to use those metaphors. Really unique languages (Prolog, Lisp, APL) stretch the way you think about programming. The algorithm you write in Prolog will not be the algorithm you write in C, unless you write unwinders so that you can run your program backwards on failure. D is not THAT unique, but it is good. It allows metaphors that C++, say, does not encourage, and this book will teach them to you.

This language is not a major departure in new ways to describe stored programs, as, say, APL (Mathematical new notation) or Prolog (Algebraic/Logical) or even Lisp (infix recursive/programs and data as lists, equally processible). It is a minor departure from the major languages of today, those being C++ and Java and variants. What it does is borrow from those languages and some others, and the result is a hybrid that is not a major departure, but small things in the language make things easy that are hard in other languages.

The flaws I found in the book were minor. The flaws in the language were, in some ways, worse. The parser did a great job if the code was correct. If the code was not correct, the language did not do a good job at pointing at the error, or at generating a small number of errors when there was only one error. I ended up fixing one error and recompiling out of self defense.

One question you might ask yourself is, "If I want to give programs away, will I be able to do it in D? Or will the end user have to install libraries and so forth that might make it harder for them to use my program? I was able to give someone a command line program by just making a copy of the .exe file. It was compiled with debugging on, so I presume it was statically compiled. But that is not hard.

If I want to write a program for myself in the near future, I will probably do it using D rather than C++. In many ways, the language makes more sense, I like the way it lets me think about problems. But the possibility that I will want to write the algorithm using Java because of Java's portability (especially to the Android platform) makes Java a winner. Too bad. One thing that D shares with Java is garbage collection, and, well, the sort of strong typing that allows that to work. Java knows it does not have pointers to a structure, because it knows what the pointers to classes are (or, rather, the references to classes are) and there is a finite number of those pointers. You can't stash one in an integer, say, because you can't cast it out of that integer, and I'm not at all sure you can cast it in. I wish that a language more like D was winning the battle. Java is just too poor, syntactically, in many ways.

D is a bit faster and looser. There is certainly the theoretical possibility of creating a union between a pointer and a long, say, and deconstructing the pointer, or even creating a false pointer. So you do not have the inherent safety where your coder is not allowed to shoot themselves in the foot. (In C, if the programmer wants to shoot themselves in the foot, they are issued a machine gun). In D, the programmer can build a machine gun, but it is harder to find bullets for it. The type controls make it much harder to make many classes of mistakes, although sometimes they get away with perfectly reasonable programming.

But after having used C++, Java and D, I believe strongly that object storage management is best done in a system that recovers the storage used to hold created objects using garbage collection. Requiring that the user release objects, or that objects be deleted when they go out of scope even though someone has a reference to the object is needlessly complicated.

Amazon allows you to look at pages in some books, and this is one of them. Look at a few pages, in the early chapters, and see if the book talks to you. If it does and if you want to learn D, then, by all means, buy this book. Given the quality and clarity of the writing, you probably will not be sorry.

This book is excellent and you should buy it right now.

I found it eminently readable, thanks in no small part to the delicate balance the author strikes between precise technical writing and entertainment. I find myself wishing that every programming book could have sections entitled "Shenanigans" or "Concurrentgate" and still manage to contain such dense, high-quality information.

I was completely drawn in by TDPL, and read the entire book in one sitting. Several times during the read I grew concerned that D was missing something vital (Forced reference semantics for objects? But that means I can't do C++ style RAII! This language sucks!) only to have the author directly address my problem and provide the solution in the subsequent chapter (In this case, structs with forced value-semantics saved the day, as did the really neat scope keyword).

The only criticism I can offer is that there were a few errors in the text; it would be worth your time to scan the errata before, after, or during your read, located at [...] Since these didn't detract from my enjoyment of the book or from its value as a D language reference, I still feel comfortable giving it 5 stars.

I'll repeat, buy this book. You'll be glad you did.

I started to read the book just because I was curious about the language. I was taught C++ at University and I've used it for years (and still use it even for my pet projects).
The book is very well-written and everything is explained crystal clear. The author has a flair for explaining things. I also read "C++ Modern design" from the author, and it's easily the best C++ book I've read together with "The C++ Programming Language" from Bjarne Stroustrup.
I think the language itself has a bright future, so I recommend to anyone that wants to
do systems programming or that simply worries about performance to read this book. This language is the heir of C++.
I hadn't still found a candidate to replace C++, but the D language together with this book is the closest thing I've found to date (and I've been looking for candidates for years). It has MORE powerful templates than
those of C++ and everything that C++ does improved, plus a built-in concurrency model that surpassed my highest expectations. On the down side it's that D is still a young language, so you don't have some powerful libraries that c++ has, like boost.asio, for example.
The only criticism about the language (not the book) from my point of view, is the mandatory
garbage collector, which could be a problem in certain contexts.
All in all, I highly recommend this book and the language itself, which has been designed very carefully. Stop thinking about Google Go, this language is the future as a general purpose language.

This is an excellent reference tome for those who want to learn the D language. It is not really an introductory programming book, but it doesn't claim to be. It's filled with tremendously interesting bits of wisdom from the point of view of a compiler writer as well, which gives the Computer Science student a bit of amusement (Computer Engineers will merely find it interesting).

This certainly rates up with the K&R C book, though it is definitely a more interesting read.

"Just what I need -- another D in programming." -- segfault

Perhaps in the application space you've been using Java/C# and a dynamic language like Python or Ruby. Maybe you're looking at Scala. But you also want a more modern replacement for C and C++ in the system space. You browse the D web site and find it interesting, so you decide to invest in this book.

I did, and found this a very good book, and D a very interesting language.

The author writes with clarity, using many easily understood small examples that show, usually with D's slick unit-test facility, what each feature does. Typographically, the examples are set off from the text in light gray boxes -- a nice touch. He is very good about motivating each feature, giving you a sense that some as-yet-unmentioned facility is needed in order to solve some problem, and hey -- look what we have here...

There are no long examples -- I don't think any of them reached a full page. I honestly didn't feel like I missed them, although arguably it would have helped to see many of the features used together in a more substantial example.

Oh, by the way -- Andrei has a great sense of humor! It really shows in the book, making it more readable.

I particularly enjoyed the last chapter, on concurrency. The author spends seven excellent pages just talking about the need for concurrency, what was done about it by the previous crop of languages, and what's wrong with that approach. Then he rolls out D's concurrency support, which is pretty cool. He starts this off with a remarkably well chosen example requiring concurrency -- very realistic, but quite brief -- and then makes short work of it using D's spawn() function, letting D's slick "owner thread" mechanism take care of the coordination. The result is impressive for its simplicity.

I wish he had gone a little deeper into D's library support for functional programming, but I guess he had to draw the line somewhere. All in all this is an exceptional book; it will be interesting to see what it does for the language. Great job, Andrei!

This is not only the pre-eminent book on the D language, it is also a fascinating read. It actually covers D2, the 2nd generation of the D language.

This is a must-have book for anyone who programs in D or wants more than a cursory understanding of the D language. It is also excellent for any C++ or Java programmer who (like me) would appreciate insights into the how and why of language design.

As an experienced C++ programmer who has also used many other languages from LISP to Java, I was intrigued by D and wanted to learn more. Andei Alexandrescu did not let me down. He not only provides a complete expose on the language, but also offers a remarkably insightful look at how language design choices were made. It was, I might add, a very compelling argument in favor of D. I wish I could switch from C++ today, but only time will tell if D will become well enough established to broadly supplant C++ and/or Java.

D was given birth by Walter Bright, an experienced C++ compiler designer, who wanted to design a better language from the perspective of a compiler writer with a very intricate understanding of the C++ language and its inefficiencies. The end result is a language that is not only more compiler-friendly, but is a joy to program. D is intended to be suitable as systems programming language, as was C++; but also provides the means for simpler code to do more complex tasks. It is quite flexible and supports multiple programming paradigms while remaining high performance.

This book is both entertaining and intellectually stimulating. As I read, I felt that I was thinking along with the author, as if in a close conversation. At times, I felt that reading the book required perceiving the author's mindset to fully grasp what was being said. Perhaps the book requires a certain amount of self-confidence in the reader. Andrei doesn't usually reassure the reader by spelling out the obvious; everything is there, but more concentrated - sort of like the D language itself. It is chock full of great insights and anecdotes without any fluff.

Some of the concepts and integrated features in D covered in this book that I found particularly interesting include code correctness, built-in unit tests, contract programming, memory safety, immutability, hijack protection, in-line assembly code, and D's well-planned approach to concurrency.

This book serves as an excellent reference, even including quick language reference guides at the ends of chapter 2 and 3, but is also a joy to read, providing a fascinating look at how a great programming language was conceived by some of the greatest minds in computer science today.

"The D Programming Language" is a fascinating read for experienced programmer who like to investigate the interesting ideas in programming space. While I do not plan to switch to D language right away, I did enjoy learning about it.

The book contains an exhaustive overview of the design and features of the D language. As usual in programming languages, it starts with simple illustrative examples, then focused on each major feature, like arrays, objects oriented programming, compile time calculations, etc. in a separate chapter. Overall the flow of the book is nice, and rarely caused any boredom.

It would not be possible to review the book, without talking about the language itself. I'll try to keep it simple, without attracting much controversy, I found it interesting, but not differentiated enough to switch today. The language contains several nice ideas, like a robust compile time evaluation system, pure functions, and fixes some C++ issues, like going to unicode for character representation. While adding some dubious features, e.g.: reinventing the RAII pattern in "scope" keyword, or going totally dangerous by introducing significant mix of reference/value types in the same syntax, or not going all the way with unicode, and leaving some possible ways to easily shoot yourself in the foot.

My main issue, is of course the lack of industry support atm. While you can get some tool support, and it's possible to compile most C programs verbatim, you'll not be able to exercise this language in a company, which actually is a "chicken and egg problem".

Going back the book, I found the examples chosen very well. Most of the time, instead of introducing examples, which cannot make sense in real life, the author is able to come up with real life use cases, which are also simple enough to understand. Most of the examples are very illustrative, and anybody with experience with C style languages (C/C++/Java, C#, etc) would feel at home.

As a summary, I'd recommend to book as a good technical reading, and the language for curious people. If you're knowledgeable about C/C++ style languages, and able to govern your own language choice, you'll find yourself at home developing in D, otherwise, you'll still learn good ideas to use in the language you're currently using.