331–340 of 344 posts
Earlier quoted context omitted.
aka "Why duck typing is better than inheritance". Yes, great book, but if you're using a language that doesn't support duck typing, some of the concepts will frustrate you and make you wish you were using Ruby instead.
You can do some (most) of the stuff using interfaces/protocols in languages that support these.
Earlier quoted context omitted.
I also emphatically suggest D.Knuth's "The Art of Computer Programming". Super dense, not like a sit down and read from cover to cover, but really good set to have around.
Another Knuth-related one that is less programming that I found rewarding to read was 'Concrete Mathematics.' It is per its own description a lengthier version of the TAOCP, but it's mostly or entirely exempt of actual code. But because of the subject matter it spawned from it tends to cover math of 'what comes later' so there is a very specific perspective of Knuth style that comes from it and its easier to see the…
Earlier quoted context omitted.
Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff. I would say generally C++ style has evolved through last decades with people understanding class based architecture as an antipattern and data pipelines based on preferably immutable data as the more robust and understandable approach. This has nothing to do with language standards or 'idiomatic' constructs - b…
> Idiomatic sounds like preference to dogmatism rather than pragmatism which is generally the worse tradeoff. That's never been the way that I've read it, and it's not how I meant it. New language constructs allow for more-natural ways for the code to express the intent of the programmer, replacing the use of older constructs in the places that they were clumsy . The entire point is to make the language more practica…
Well, if the original code is of the worst kind of a mess, Feather's circa 2004 collection of methods to make it more understandable but functionally the same work just fine for the first part of the refactoring. In my experience this is the most difficult part as well. To what dialect of the language the code is ported after it is understandable, is a relatively trivial syntax transform after this.
I speak from experience from having recently had to implement features to a production codebase with millions of lines of code, some of which date back to Fortran, and that took the final step of evolving into C++ sometimes in the late 90's.
I prefer the definition of legacy code that it's any code that does not have unit tests. In this case every transformation to a production codebase needs to retain the original behavior - without exact understanding what that behavior is.
I think this comment should have been my original response to this thread instead of the relatively cheeky responses I wrote earlier.
- Code complete
- Pragmatic programmer
- Design patterns
- Programming pearls
- If you're going for hardcore programming: the dragon book, something on modern hardware and something on OS internals.
Some of the most interesting books I've read in support of my software-development work are: * "Compilers: Principles, Techniques, & Tools" by Aho et al. (i.e., "the dragon book") * "Data Flow Analysis: Theory and Practice" by Khedker et al. * "Understanding MySQL Internals" by Sasha Pachev. * "Transaction Processing: Concepts and Techniques" by Gray and Reuter. * "Fundamentals of Wireless Communication" by Tse and V…
I've seen the "dragon book" mentioned several times, and I think it (and similar books) are good if you really do plan to (re-)invent a real world, large scale, programming language. If you really just want to get a feel for what's going on under the hood, the language presented in Nand2Tetris is specifically designed to have the necessary complexity to cover most of the details, but not so many special cases that you end up "chasing dragons". And the course is modular enough that you can jump right in and just implement the compiler if you want.
Earlier quoted context omitted.
I share your sceptical opinion about ESR, but I concur with the other commenters that The Art of Unix Programming is still worth reading. (In contrast eg to his thing about Bazaar vs Cathedral.)
The Cathedral and the Bazaar was not an excellent piece of writing, but it was sort of necessary at the time. It has served its evangelical purpose well, to the point where it's no longer necessary. Open Source won the day, in no small part due to ESR. (I think it vital to give my enemies their due praise). TAoUP is a good book on the Unix Philosophy, but it's worth noting that the ultimate expression of these ideas…
Earlier quoted context omitted.
And it's playful. It seems like, 20+ years ago, there were a lot more authors who wrote playful tech books. I miss 'em.
Any to recommend?
I'd say the 'Head First' books are modern equivalents with a similar spirit.
Any computer themed book of Gerald M. Weinberg is a must read: https://leanpub.com/u/jerryweinberg If at first sight my may think that they are outdated and superficial, but you can't be more wrong.