What to learn?

[Walter Kalata]

I'd consider myself something of a c++ hobbyist. Rather, I program mainly
at a personal project level. I started learning when I was about twelve
years old (currently eighteen), reading various books I could find at the
local library. In 1999, when I learned about C++96, I realized that it
really wasn't a great idea to read from someone else's aging book heap. To
bring this somewhat off-topic post to a point, my c++ book knowledge to date
consists of:

Various trash books by filth publishers, i.e. teach yourself c++ in 24
hours, c++ for the clinically retarded...etc
Various implimentation-specific books on sockets, windows/mfc programming,
programming in a posix environment...etc.
"Extreme Programming In Action"
Stroustrup's "The C++ Programming Language"
Scott Meyer's "Effective C++", "More Effective C++", and "Effective STL".
Josuttis's "The C++ Standard Library"
Alexandrescu's "Modern C++ Design"

Recently, I've picked up, but have yet to read:
Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
along with the GOF book.

I'm wondering what good books my shelf lacks, whether anyone can offer any
advice as to whether to pursue Algorithms or Patterns first, as either topic
isn't going to be at the top of my agenda and will take a very long time to
absorb. Any other tips to enrich my programming repetoire will be much
appreciated.

[Andrew Koenig]

> I'm wondering what good books my shelf lacks, whether anyone can offer any

advice as to whether to pursue Algorithms or Patterns first, as either topic isn't going to be at the top of my agenda and will take a very long time to absorb.

At the risk of sounding self-serving, I'd like to recommend "Accelerated
C++". Although you may find that much of the material in it is familiar, I
expect that you will probably also find it to be presented in a way that
offers new insight into how to program in C++.

[jeffc]

"Walter Kalata" <pl****@ucwphilly.rr.com> wrote in message
news:QZ*********************@twister.nyc.rr.com...

Recently, I've picked up, but have yet to read:
Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
along with the GOF book.

I'm wondering what good books my shelf lacks, whether anyone can offer any
advice as to whether to pursue Algorithms or Patterns first, as either topic isn't going to be at the top of my agenda and will take a very long time to absorb. Any other tips to enrich my programming repetoire will be much
appreciated.

Frankly, although the GOF patterns book was the first big one, and probably
rightly famous, I don't find it all that useful. I think the book is famous
more because it was a new book on a new topic than because it's easy to
read. I think there are some newer ones that might be better. Also, I
haven't read the algorithms book, but if it were me I might find that more
useful, depending on what I picked up when skimming it.

[Martin Eisenberg]

Walter Kalata wrote:

I'm wondering what good books my shelf lacks, whether anyone can
offer any advice as to whether to pursue Algorithms or Patterns
first, as either topic isn't going to be at the top of my agenda
Yes, you want to get something *done*, huh? :) Still, that attitude
might be a mistake. Besides the fact that many particular algorithms
in a book like Sedgewick's will come in handy once you got to know
about them, pondering their properties and why they work the way they
do -- i.e., Algorithmics -- can help tremendously in thinking about
your own programs in a clear and focused way. After all, those are
algorithms, unless they don't terminate ;) It will also lead to
figuring out some patterns all by yourself, and thus to a deeper
appreciation of the term "Pattern" (albeit on a different level from
what GOF talk about). No doubt you'll hit on quite a few things you
already knew, but only implicitly.
Any other tips to enrich my programming repetoire will be much
appreciated.

Looking at your reading list, I guess you're already acquainted with
the idea of functional programming in addition to the procedural and
OO mindsets. It is a nice thing to have in one's toolbox.
Martin

[osmium]

Walter Kalata writes:

Recently, I've picked up, but have yet to read:
Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
along with the GOF book.

This advice is too late for you, since you already own the book, and you may
not like the advice anyway.

But I have a very firm belief that an algorithms book should be language
neutral, rather than the language du jour. The latter approach leads to
things like _Mathematical Recipes for Fortran_ and the various attempts to
make it pertinent in today's world. If the title is garbled, sue me, you
know what I mean.

Sedgwick has a language neutral version of his book so the advice *can* be
followed if one wishes.

[jeffc]

"osmium" <r1********@comcast.net> wrote in message
news:br************@ID-179017.news.uni-berlin.de...

But I have a very firm belief that an algorithms book should be language
neutral, rather than the language du jour. The latter approach leads to
things like _Mathematical Recipes for Fortran_ and the various attempts to
make it pertinent in today's world. If the title is garbled, sue me, you
know what I mean.

Sedgwick has a language neutral version of his book so the advice *can* be
followed if one wishes.

On the other hand, there is also specific language idioms that he would
probably want to learn.

[Walter Kalata]

On the other hand, there is also specific language idioms that he would
probably want to learn.

I was hoping to try to tackle Knuth's series in the future, and correct me
if I'm wrong, but I doubt that any algorithms I choose (or with the
libraries of this day and age, need) to impliment from Sedgewick's C++
Algorithms book would even remotely resemble his sample code, and will be
built from the textual explaination on how they function, with the code
sample used more or less as something to double-check with. Couldn't this
apply to writing the sample code in the language of tomorrow's day?
Cross-referencing the code with C++ would probably only make it easier to
understand, especially because at this point C++ is the most natural
language for me to analyze and fathom, as opposed to pseudo-code, or worse,
machine code for a pseudo-processor.

[osmium]

Walter Kalata writes:

I was hoping to try to tackle Knuth's series in the future, and correct me if I'm wrong, but I doubt that any algorithms I choose (or with the
libraries of this day and age, need) to impliment from Sedgewick's C++
Algorithms book would even remotely resemble his sample code, and will be
built from the textual explaination on how they function, with the code
sample used more or less as something to double-check with. Couldn't this
apply to writing the sample code in the language of tomorrow's day?
Cross-referencing the code with C++ would probably only make it easier to
understand, especially because at this point C++ is the most natural
language for me to analyze and fathom, as opposed to pseudo-code, or worse, machine code for a pseudo-processor.
What I see you saying is that you prefer n%m to n mod m. How do you feel
about *a++?

C, and especially C++, are ugly, cryptic, obfuscating languages with some
plug ugly idioms. C++ is loaded with booby traps, which Sedgewick has to
provide work arounds for if he did a workman like job. (I don't know if he
did or not, I have both the C++ version and the language neutral version, I
always use the latter. BTW I am not particularly fond of either of them, I
just happen to have them.) As said upstream, no one is proposing you return
the book you already have. I would lean towards Cormen if I were just
starting out and had to use a book that is currently in print. Or look
through used books, I am sure a good source of used books would have
something *I* would like better than either of these (Cormen, Sedgewick).
Wirth is at least along the lines of what you want, I assume it is out of
print. My working hypothesis is that most good books are out of print. My
post was mostly meant to assist lurkers, not you.
or worse, machine code for a pseudo-processor.

You are going to *love* Knuth :-)
What I see you saying is that m%n makes more sense to you than m mod n. How
do you feel about *a++?

[Unforgiven]

Walter Kalata wrote:

On the other hand, there is also specific language idioms that he
would probably want to learn.

I was hoping to try to tackle Knuth's series in the future, and
correct me if I'm wrong, but I doubt that any algorithms I choose (or
with the libraries of this day and age, need) to impliment from
Sedgewick's C++ Algorithms book would even remotely resemble his
sample code, and will be built from the textual explaination on how
they function, with the code sample used more or less as something to
double-check with. Couldn't this apply to writing the sample code in
the language of tomorrow's day? Cross-referencing the code with C++
would probably only make it easier to understand, especially because
at this point C++ is the most natural language for me to analyze and
fathom, as opposed to pseudo-code, or worse, machine code for a
pseudo-processor.

At Uni, the Algorithmics and Datastructures courses would use pseudocode.
Most of the time it would either look a lot like C++ or Pascal, and hide any
of the uglyness that stuff like pointers adds to an algorithm. If the
pseudocode is well-chosen, the examples in it can be far more clearer than
in a relatively low-level language like C++, as the example can focus on
what the algorithm does, not on how you get C++ to do it.

Just my opinion of course.

--
Unforgiven

[Walter Kalata]

osmium writes:

What I see you saying is that you prefer n%m to n mod m. How do you feel
about *a++?

Not to start a flame war or anything, but how exactly would you express *a++
in pseudocode?

[jeffc]

"Walter Kalata" <pl****@ucwphilly.rr.com> wrote in message
news:fx**********************@twister.nyc.rr.com.. .

osmium writes:

What I see you saying is that you prefer n%m to n mod m. How do you feel about *a++?

Not to start a flame war or anything, but how exactly would you express

*a++ in pseudocode?

You mean like "Access the value of the thing pointed to by a, and then
increment a" ?

[osmium]

Walter Kalata writes:

What I see you saying is that you prefer n%m to n mod m. How do you feel about *a++?

Not to start a flame war or anything, but how exactly would you express

*a++ in pseudocode?

I wouldn't. My mind doesn't consider such possibilities when writing
pseudocode. There are numbers and one can add, subtract, multiply and
divide them. And there is the notion of a thing called a pointer. These
are disjoint things.

[Jerry Coffin]

In article <QZ*********************@twister.nyc.rr.com>,
pl****@ucwphilly.rr.com says...

[ ... ]

Recently, I've picked up, but have yet to read:
Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
along with the GOF book.
If the purchase was _really_ recent, this may not have been a mistake --
you might still be able to take these back and get a good book (E.g.
Knuth or Cormen, Rivest et. al.) instead. Otherwise, about the best way
to use these to learn about algorithms is to burn them to give yourself
light to read a different book.
I'm wondering what good books my shelf lacks, whether anyone can offer any
advice as to whether to pursue Algorithms or Patterns first, as either topic
isn't going to be at the top of my agenda and will take a very long time to
absorb. Any other tips to enrich my programming repetoire will be much
appreciated.

IMO, a book on algorithms should come before one on patterns. Patterns
occur in the implementation of algorithms. Until you know what
algorithm you're going to implement, the patterns involved in their
implementation are more or less irrelevant.

Once you have at least one decent book on algorithms, it's probably time
to start thinking more in terms of what interests you and what kinds of
programs you really want to write -- depending on your interests, that
might be a book on compiler writing, or numeric analysis, or number
theory, or any number of other possibilities.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <QZ*********************@twister.nyc.rr.com>,
pl****@ucwphilly.rr.com says...

[ ... ]

Recently, I've picked up, but have yet to read:
Robert Sedgewick - "Algorithms in C++", Parts 1-4 and Part 5
along with the GOF book.
IMO, the Sedgewick books are best replaced with something else -- I like
Knuth, but Cormen, Rivest, et al, is quite good as well. The Sedgewick
books, however, are basically worse than nothing at all. For the
theorist, their analysis is so shallow as to be meaningless at best, and
more often downright misleading, so you'll need to unlearn what they
teach before you can learn anything else.

For the pragmatist who wants to implement the algorithms, they're even
worse. You often turn to a book to clarify details on algorithms you
already _basically_ understand. These books contain such lousy
explanations, that after reading them, you'll no longer just be confused
over the details, but probably be confused over the basic idea of the
algorithm too. In case the poor explanations don't confuse you, he
still has an ace up his sleeve: sometimes he'll claim to describe one
algorithm, but really describe something almost completely different.

I've had a copy of the GoF book since it first came out, and while I can
understand some of the enthusiasm about it, I have to say that I've
never found it particularly useful either. OTOH, it's not anywhere
close to the same class as Sedgewick -- even at very worst, it's utterly
harmless, which is a lot better than can be said for Sedgewick.
I'm wondering what good books my shelf lacks, whether anyone can offer any
advice as to whether to pursue Algorithms or Patterns first, as either topic
isn't going to be at the top of my agenda and will take a very long time to
absorb. Any other tips to enrich my programming repetoire will be much
appreciated.

IMO, algorithms first, patterns later. Knowing algorithms is what
allows you to accomplish something. Knowing patterns allows you to
write nicer code to accomplish it. Knowing patterns without algorithms
allows you to write nice code that doesn't accomplish anything.

--
Later,
Jerry.

The universe is a figment of its own imagination.