TDPL notes, part 1

[bearophile]

I have finally received my copy of The D Programming Language :-)
This is a first post of notes that I am writing while I read this text for the first time.

I'd like to know how many copies have being sold so far, it can give a starting idea of how many people are interested in D2.

I have seen the PDF on the site, but I'd like to see colored code in the electronic text. Source code colorization improves code readability (an offline PDF version that allows copy&paste can allow me to give better quotations here).


About the cover of the book:
- My copy of the book is the authorless one. Despite being a "bug", it makes this cover page strangely clean and elegant, because it removes a source of noise from it :-)
- Strong contrasting colors are not elegant, shades (here of grey) are often more elegant, but I think the uppercase D is the most important element of the whole cover, so I think it's better written in a dark red color.
- The cover art is not bad, I don't mind it. But it's good to keep in mind that such style of art is now about one century old, it's not contemporary art :-)


I like the prefaces, expecially the one written by Walter, that explains what are hir original (as in almost-child ones) purposes. I hope Walter will be able to create another engineering system in his future, like another language, etc.

---------------

CHAPTER 1:

P 3-4 (Page 3 and 4): I don't agree that omitting the type, and leaving just "immutable" gives a program as safe. Conversion constants for units don't change, but often hardcoded constants in programs do change.
If I have code like:
immutable foo = 12.2;
And later I have to change the value to 12, I can forget the dot:
immutable foo = 12;
This changes the type of foo. This can cause problems. It's better to write code that is not fragile and doesn't cause problems if the programmer is a bit distracted.
- Isn't it better to use 'enum' instead of 'immutable' in your program here? I see no purpose in using the more wordy 'immutable' here. I don't like the keyword 'enum' to define constants in D, but this is what we got.


P 5: clear writefln format string errors: even better, the D compiler in most cases knows the format string statiacally, so most times it can perform static typing, as GCC does:
http://d.puremagic.com/issues/show_bug.cgi?id=4458


P 6: Python-style indentation of D2 code: it's named Delight:
http://delight.sourceforge.net/
(Well, it's not a preprocessor, it's more like a variant of D2 (it introduces few improvements, like nonnull references).


P 8, first program:
- Unsigned integers are dangerous in D, their usage must be discouraged as much as possible, use them only when they are strictly necessary, they are premature optimization, don't use them in the first few hundred pages of the book. And assigning length to an uint loses precision anyway, because length is a size_t that can be 64 bits too, so in this early example it is *much* better to use just one int value.


P 8, second code:
- In Python default formatting rules (PEP 8) say that lists (arrays) can be written as: [1, 2, 3]. I too prefer this formatting compared to the one you use: [ 1, 2, 3 ].
- "new int[20];" I don't like this much. In D2 there are two different syntaxes to define dynamic arrays:
new int[20];
new int[](20);
Having two different syntaxes to do the same thing is bad. I'd like the first one (new int[20];) to be deprecated.
Later you can use syntax like:
new int[20][][10](20);
To define a 3D array where some axes are dynamic arrays and some other ones are fixed sized ones :-)


P 10:
In this line of code:
while (!input.empty) {
There is not so much need of using an external function plus a negation:
while (input.length) {
If you use an IDE it's easy to see where a function comes from, but in a printed book you can't. So in a book it's better to write:
import std.array: empty;
Instead of:
import std.array;


P 12 second program: any explanation of idup is missing, but this can wait later.
The strip() there is useless, split ignores leading and trailing spaces, you can see with this program:
import std.stdio, std.string;
void main() {
    string s = "  how are  you?  \t";
    auto a = split(s);
    foreach (ss; a)
        writeln(">", ss, "<");
}
It prints:
>how<
>are<
>you?<


P 14:
This is not a lambda function, it's a lambda function template:
(a, b) { return freqs[a] > freqs[b]; }
"D guarantees no indirect calls": in this example indirect calls are avoided because it's a lambda function template, if you use a normal lambda function dmd is not able to inline it yet.


P 15: I miss a little the struct inheritance. But it's mostly an efficiency thing, not so important.


P 16-17: I like the page 17 that reminds this bug-prone part. But if I use D to write 20-lines long scripts I really don't want to remember to dup all things (in D1 code I sometimes end up dupping too much, to be on the safe side). So I suggest a different API for the line reading:
- stdin.byLineMutable() (or another similar name): for the current behaviour that avoids a memory allocation for each line read. This is faster but it's less safe.
- stdin.byLine(): that allocates a new string for each line, this is safer, as in Python.
D default design policy says that unsafe but faster things need to be asked for, and the default things must be less bug-prone.
If I write small scripts I can use byLine(), with more hope to avoid bugs. If later I see it's too much slow, I can replace the byLine() with the other method and optimize the code, carefully.


I'll continue in the next posts. I hope to find the time and energy to comment the whole book.

Bye,
bearophile