OK, i agree to som of what you are saying but I alsö
disagree to some of it.
I agree that the best way to learn programming is by doing it. But
at least in my experience more theoretical issues give you a lot
of the ideas that you later choose to experiment with in practice.
I disagree to your view on Lakos work as mainly concerned with
dividing projects into directories, rather i would say his main concern
is insulation, i.e. how to minimize compile time dependencies between
components, an issue of major concern to anyone designing/implementing
large software systems (in a compiled language anyway).
When it comes to your view that the "language is irrelevant" i do
understand what you are getting at, i.e. that the same design can be
realized in any language (with more or less pain of course). The problem
with the "language is irrelevant" view, in my opinion, is that it breaks
down in many
practical settings. Consider the STL for example, imagine implementing that
in
a language without support for templates... Another example would be using
Prolog
for implementing the next version of the Appache web server, surely Prolog
could deliver the appropriate function but the hardware requirements as
well as the development costs would surely break through the roof...
Another issue, related to the "language irrelevancy", is the fact that there
is
always many ways to implement the same design (even in the same
programming language and perhaps especially in languages such as C++
which supports several design paradigms). The problem is that many of these
"ways"
are really bad, perhaps not at first sight but perhaps when the system grows
larger or when it has to be ported to some other platform etc...
Given these very real problems i think that literature such as the book by
Lakos
is invaluable in that it discusses real world success, i.e. things that
worked
really well in this or that setting (In Lakos case, really large systems)
/K
/K
"Victor Bazarov" <v.********@attAbi.com> wrote in message
news:vj************@corp.supernews.com...
"Kymert persson" <mi*****@ida.his.se> wrote... Thanks for the tip, but i think this book is a bit too high-level
compared to what i am looking for. And i guess this is part of
a general problem concerning software/programming-
literture, i.e. that they are either fairly low level descibing a
language or rather high level descibing things such as
reusability, modularity, portability etc., without really demonstrating
how to realise these ideas in a particular language (preferrably C++
in my case)
The only reason they don't is because the language is irrelevant.
I think that the "Large scale C++ software design" by Lakos, J. is
exceptional in this respect, he discusses fairly high level issues
concerning
large system design without ever loosing the connection to the
implementation
level.
As far as Lakos is concerned, his book is good for a novice who has
never worked on large project before. Once you've been there two or
three times and faced different issues than splitting projects into
directories, you will set that book aside as a memento, nothing more.
Your level changes as you progress. The level of the book doesn't.
And it doesn't cover issues that are increasingly important. Only
the basics, which become details very soon.
I recommend "shock therapy" as the main approach to learning things.
Programming? Knuth. C++? Stroustrup and Ellis, Coplien. Driving?
Get on the road after you learn shifting from the first to the second
gear. Swimming? Jump in the water at the deep end of the pool. From
my point of view, you learn by doing. Join a big group of people and
see how they organise their work to understand what motivates them and
what is wrong with their processes. As soon as you can consciously
make a suggestion and it gets accepted, you got it. Reading books is
not going to get you there, trust me.
Victor