Timeless Classics of Software Engineering

[apm]

I am suprised you say it's applicable to any language. The advice
about cyclic dependencies certainly is but I find much of the advice
is specific to C++, such as #includes, use of fwd class decls etc. But
that's ok coz it is supposed to be for C++ developers.

IMO it is a classic but the evolution of C++ has caused it to become
somewhat dated. That is why I give it a qualified recommendation. The
main ideas are certainly important and AFAIK are not covered by any
other text. And there is some pioneering work, such as metrics and
notation for physical dependencies. However, at the time of writing
(circa 1997), many commercial C++ compilers on Unix were quite limited
in what they supported and this is what makes me say the book is
dated. The compiler limitations made certain language features
off-limits in the interests of portability. Features such as heavy
template use (e.g meta-programming) and namespaces were of very
limited availability. So the way these features are handled would
probably not be in line with current usage. For more information on
this, see the comments made in passing on the ACCU web site
(http://www.accu.org/htdig/search.htm).

Regards,

Andrew Marlow

 

[Greg Comeau]

I am suprised you say it's applicable to any language. The advice
about cyclic dependencies certainly is but I find much of the advice
is specific to C++, such as #includes, use of fwd class decls etc. But
that's ok coz it is supposed to be for C++ developers.

IMO it is a classic but the evolution of C++ has caused it to become
somewhat dated. That is why I give it a qualified recommendation. The
main ideas are certainly important and AFAIK are not covered by any
other text. And there is some pioneering work, such as metrics and
notation for physical dependencies. However, at the time of writing
(circa 1997), many commercial C++ compilers on Unix were quite limited
in what they supported and this is what makes me say the book is
dated. The compiler limitations made certain language features
off-limits in the interests of portability. Features such as heavy
template use (e.g meta-programming) and namespaces were of very
limited availability. So the way these features are handled would
probably not be in line with current usage. For more information on
this, see the comments made in passing on the ACCU web site
(http://www.accu.org/htdig/search.htm).

While in a discussion with John over the summer, he said a
second edition of the book was being worked on. There is an
off chance that I misunderstood and has was referring to
something else.

 

[apm]

IMO it is a classic but the evolution of C++ has caused it to become
somewhat dated. That is why I give it a qualified recommendation.

[snip]
While in a discussion with John over the summer, he said a
second edition of the book was being worked on. There is an
off chance that I misunderstood and has was referring to
something else.

You misunderstood. John is working on something else. I specifically
asked him if he would produce a new edition of LargeScale bearing in
mind the dated aspects and he said he would not due to time, family
committments etc, which is perfectly understandable.

 

[Guest]

The other essential on my book case is Lakos' "Large Scale C++
That quote was mine, so I'll reply.

I am suprised you say it's applicable to any language. The advice
about cyclic dependencies certainly is but I find much of the advice
is specific to C++, such as #includes, use of fwd class decls etc. But
that's ok coz it is supposed to be for C++ developers.

A better way to express what I meant might be to say that the key
concepts in the book are applicable to large scale software projects
independent of language.

I mention applicability to other languages in the belief that people doing
projects in languages other than C++ can benefit. My personal experience
is with applying those principles, particularly the principles of physical
design, to the rearchitecture of a large body of ANSI-C code (the HP-UX
kernel).

IMO it is a classic but the evolution of C++ has caused it to become
somewhat dated. That is why I give it a qualified recommendation.

Fair enough. Because I'm more interested in the concepts and less in
the C++ implementation details, I didn't particularly notice. If
someone reads the book for C++ specifics it probably is dated. Thanks
for pointing that out.

The main ideas are certainly important and AFAIK are not covered by
any other text.

Not AFAIK either. If one wanted to make a timeless and more general
version you could factor out the following pieces:

* All of Part II Physical Design Concepts (Chaps 3-7)
* Chapter 8: Architecting a Component
* Section 10.2: Function Definitions

Levelizing the contents is left as an exercise for the reader .

Thanks for the interest in the book, the discussion, and pointing out
the issues for anyone who reads it from the viewpoint of modern C++.
I hope that this richer understanding may entice more people to read
the book and avoid disappointments for those who do.

Eric