recommend a good object oriented book?
charif
if anyone could recommend a good book to start. Thanks in advance.
-- charif
Phlip
> I am new to the field. I have some programming experience. I was wondering
> if anyone could recommend a good book to start. Thanks in advance.
Design Patterns by the Gang of Four
Smalltalk Best Practice Patterns by Kent Beck
Refactoring by Martin Fowler
Test Driven Development by Beck
That last is in draft:
http://groups.yahoo.com/group/testdrivendevelopment/files/
/Design Patterns/ by the GOF shows how to arrange objects the simplest way
found so far to solve some common complex problems.
A program's current design quality is not as important as whether the
program can improve over time. If it can then the program can live forever,
and if it can't it will die. The book /Refactoring/ by Martin Fowler shows
how to incrementally improve.
We're trying to keep a secret from this newsgroup, but the best kind of
code, in theory, is "defensive". When we reuse or change such code it should
resist introducing bugs. The best kind of defensiveness we have discovered
so far is called "Test First". That means when we think of a line of code we
first write a line of test whose failure forces us to write that code. This
generates very high test coverage as a by-product of helping us code very
fast. The book /Test Driven Development/ by Kent Beck, in draft, shows how
this cycle works:
http://groups.yahoo.com/group/testdrivendevelopment/files/
In the archives of this newsgroup you will find quite a few posts by others
and me recommending these approaches to people who then went on to
successfully use them and learn. But I wish someone had pointed them out to
/me/ 5 years ago when I first started posting here!
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- All sensors report Patti having a very good time --
Shayne Wissler
practical book on C++, a must for anyone wanting to improve their skill at
writing C++.
I'd be wary of the theoretical books. There's a lot of junk out there.
Shayne Wissler
"charif" <cha...@charif.homeip.net> wrote in message
news:ag1nub$gfe$1...@nn-os103.ocn.ad.jp...
Charif Lakchiri
Thanks for the suggestion.
Do you mean that it's better to start with a book that teaches the concepts
of object orientation through a programming language than a book that is
language independant? I would really appreciate if anyone had any comments
or opinions on this question. Thanks.
-- charif
"Shayne Wissler" <thal...@yahoo.com> wrote in message
news:wE_U8.237401$R61....@rwcrnsc52.ops.asp.att.net...
H. S. Lahman
> I am new to the field. I have some programming experience. I was wondering
> if anyone could recommend a good book to start. Thanks in advance.
Alas, OT is a big field and one book probably won't do it for you.
I would suggest you start with a book on OOA and/or OOD. Such books
generally describe the fundamentals better. But avoid books with a
specific language or 'UML' in the title. Those tend to be about
manipulating syntax rather than fundamentals.
Even if you end up using a pure OOP-based process, you should still
trying some UML modeling. That's because it provides a good expression
of the fundamentals in a very compact manner. In this case a book with
UML in the title is an advantage.
Then you need to deal with OOP. For that you need a book with a
specific language in the title. Probably two books because it is useful
to start "playing" with OT using a "purist" language like Smalltalk.
That will complete the OOA -> OOD -> OOP cycle in the most coherent
fashion. (Alas, the most popular OOPLs have made more compromises with
Turing so the transition is less obvious.) Then you will need a book on
the language de jour if you plan on doing OT professionally.
You'll notice I didn't recommend any specific books. In each category
there are lots and most are pretty similar. Since I haven't read them
all, I can't even guess which one is actually the best. Just browse
them in a book store and pick the one that seems most readable and
provides the most clarity to you.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Shayne Wissler
If you are just starting, then yes, I think it's better to gain practical
experience first, and then improve your theoretical knowledge (actually, the
order isn't the issue, it's the emphasis. At first, more time should be
spent becoming proficient than at gaining a theoretical understanding).
If your ambition is to understand OO thoroughly, the best approach is to
learn several different, interesting languages (you don't have to be adept
at all of them), read some theory along the way, and most importantly, use
your own judgement to decide what you think is right and what isn't. Our
field is very immature. There is no one book or set of OO ideas that have
nailed it yet, so you're really on your own.
In the future there may be some cannoncial book, something like what
Bertrand Meyer was striving for, but there just isn't one.
Shayne
"Charif Lakchiri" <cha...@joy.ocn.ne.jp> wrote in message
news:ag1tlt$2ds$1...@nn-tk102.ocn.ad.jp...
Topmind
>
> > I am new to the field. I have some programming experience. I was wondering
> > if anyone could recommend a good book to start. Thanks in advance.
>
> Design Patterns by the Gang of Four
> Smalltalk Best Practice Patterns by Kent Beck
> Refactoring by Martin Fowler
> Test Driven Development by Beck
>
> That last is in draft:
>
> http://groups.yahoo.com/group/testdrivendevelopment/files/
>
> /Design Patterns/ by the GOF shows how to arrange objects the simplest way
> found so far to solve some common complex problems.
>
It is sometimes suggested that begginers avoid the GOF book,
as it might be too overwhelming, and also may be hard to
relate to without some experience under one's belt.
BTW, how come you left Bertrand Meyer's OOSC2 off the list?
It usually makes the top reading lists.
-T-
JRStern
<cha...@joy.ocn.ne.jp> wrote:
>Do you mean that it's better to start with a book that teaches the concepts
>of object orientation through a programming language than a book that is
>language independant? I would really appreciate if anyone had any comments
>or opinions on this question. Thanks.
It's pretty odd, isn't it, that there aren't fifty books with titles
like, "Introduction to Object-Oriented Programming"?
Well, let's try bn.com:
http://search.barnesandnoble.com/textbooks/booksearch/isbninquiry.asp?isbn=0201760312
An Introduction to Object-Oriented Programming 3RD
Timothy A. Budd
Our New Price: $63.00
In Stock:Ships within 24 hours
Same Day Delivery in Manhattan.
Format:Textbook Hardcover, 3rd ed., 450pp.
ISBN: 0201760312
Publisher: Addison Wesley Longman, Inc.
Pub. Date: October 2001
Edition Desc: 3RD
This looks good, judging from the description. Long. Academic. I
might like a look at it myself, actually.
There used to be an "OOP for Dummies", but it's out of print.
Just typing in "object oriented programming" as keywords gets me the
following (with dups removed):
1. Object Oriented Programming in C++
...
4. Object Oriented PERL
5. Abap Objects: Introduction to Programming Sap Applications with
Cdrom
...
7. Object-Oriented Programming in Java
8. Design Patterns: Elements of Reusable Object Oriented Software
9. Object-Oriented Programming Using C++, Second Edition
10. C++ How to Program
11. Programming Microsoft Visual Basic .NET (Core Reference)
12. Karel++: A Gentle Introduction to the Art of Object-Oriented
Programming
13. An Introduction to Object-Oriented Programming with Java 2nd
Edition
14. Java How to Program
15. Uml and the Unified Process: Practical Object-Oriented Analysis
and Design
16. Programming Python: Object-Oriented Scripting
17. Beginning Programming for Dummies
18. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Unified Process
19. Programming C#: 2nd Edition
20. Design Patterns Explained: Principles and Strategies on
Object-Oriented Design
21. Beginning Programming for Dummies
22. Fundamentals of Object-Oriented Design in Uml
23. The C++ Programming Language
24. Object-Oriented Macromedia Flash MX
25. Foundations of Object-Oriented Languages: Types and Semantics
The problem is, "object-oriented" is an adjective. You can't go into
a bookstore and ask if they have any good books on, "red". Or even
"red furniture". Odd, ain't it?
There are a dozen object-oriented languages, a dozen other languages
with some OOP features, OO analysis, OO methodologies, OO theory, OO
practice, OO myths, ... but where's the OO, really?
Probably the best thing you can do is (a) get an intro book on Java,
there are dozens (b) hack around with Java on your own, (c) read some
books on UML and/or RUP, the leading OO analysis/design approach
today.
Also, wander around on the web, for what it's worth.
Enjoy.
Joshua Stern
Phlip
> BTW, how come you left Bertrand Meyer's OOSC2 off the list?
Because I never read it.
I read interesting things here and in other forums by folks who read it,
though... ;-)
--
Phlip
http://www.greencheese.org/PhilosophyBrethrenThree
-- Whoever dies with the most features wins --
Martin Fowler
> if anyone could recommend a good book to start. Thanks in advance.
My first choice for starting with OO would be Applying UML and Patterns
by Craig Larman. (http://www.amazon.com/exec/obidos/ASIN/013092569). The
main title is a bit misleading, the subtitle (An Introduction to
Object-Oriented Analysis and Design and the Unified Process) is a better
description of the book.
After that the other suggestions people have posted here are good,
especially the ones that refer to my books ;-)
Martin
Topmind
Martin,
There is a question I have been meaning to ask you. One of
your books seemed to recommend the practice of
"hard partitioning". Do you generally recommend this
practice, or was it just an example that took shortcuts
for breivity purposes? (I didn't write down the
page number, sorry. It was an accounting example IIRC.)
Here is an excerpt from my webpage about hard
partitioning:
(begin quote)
Although hard partitioning is not native to object oriented designs, it
seems to be more common there. It is another manifestation of the IS-A
philosophy that under-pins much of OOP.
A typical example of hard partitioning is in a work-flow application. A
given item may "move" from a status of "pending" to "in-review" and later
to "reviewed", or perhaps "rejected" or "passed". Some designs have
separate physical buckets (or at least hard-coded buckets) that they
place each item into as it is being processed.
For example, they may have several collections, one called
"pending_collection", another called "rejected_collection", etc. This is
understandable, because it fits the visual impression that one may
initially have of the process. However, the fault with this is that it is
hard-wiring a single aspect (see above) into the design.
Suppose you did have all these separate collections defined. Then the
boss comes up and asks you for "all items submitted by Jane Doe between
January and June". The current status of the item may be part of such a
report, but it is only a minor player, one column among many. You now
have to combine all these collections to make the report. You have to
combine them because they are split on an aspect that is not important to
the new request.
In other words, the new request goes against the "grain" of partitioning;
an orthogonal dimension to the design. We now require more effort to work
around the hard-wired partitioning by status. Viewing information by
multiple aspects is becoming more and more important in business. Perhaps
in the old days where only the most important aspect of a business was
automated, hard partitions may have been satisfactory and very efficient.
However, the world is growing up, and wants more complex, cross-cutting
analysis.
The best approach is often "virtual partitioning". All such items should
be in one collection (such as a table). The status code is one attribute
(field) among many others. We don't elevate its status above other
attributes because each attribute may play a role under different
circumstances. Some of the circumstances may not be foreseeable at design
time. Thus, it is usually a safer bet to prepare for multiple
partitioning dimensions.
This approach allows us to supply a virtually partitioned collection when
needed, but not sacrifice easy access to other partitions when needed. If
we want to view by a particular status, we can issue a query or view such
as:
s = SQL("select * from Items where iStatus = 'pending' ")
(I am not saying that SQL is always the best way to do virtual
partitioning, just the most common.)
There is one caveat to this approach. Suppose we start out a consumer-
based store system by deleting all cancelled orders. After the system is
well established, the request comes in to keep all the cancelled orders
instead of delete them.
If we introduce a status code in order to separate them, then we may have
to change a lot of programming code in order to make sure every spot that
uses order data knows to filter out cancelled orders.
It is possible that we may forget a few spots. Thus, it may be less risky
to introduce a second collection (or table) that stores only the
cancelled orders.
One more possible reason is that the database system may not offer row-
level security. Thus, one has to have similar or duplicate table schemas
in order to separate rows for security reasons.
(end quote)
-T-
Martin Fowler
> There is a question I have been meaning to ask you. One of
> your books seemed to recommend the practice of
> "hard partitioning". Do you generally recommend this
> practice, or was it just an example that took shortcuts
> for breivity purposes? (I didn't write down the
> page number, sorry. It was an accounting example IIRC.)
From your quote I'm assuming by 'hard partitionng' you mean allowing a
class to be subclassed along only a single dimension. So you can't have
a Person subclassed as (Man | Woman) and as (Doctor | Nurse).
All the mainstream OO languages allow just a single dimension for
subclassing. In the OOA&D world Jim Odell referred to this as "Single
Classification" because a person could only have one classification that
inherited others. That is you can be a Man (and therefore a Person). To
support male nurses with subtyping you need multiple classification (you
can be both a man and a nurse, and both imply being a person).
The UML does support multiple classification, but it isn't used much as
it doesn't make sense in an implementation perspective since languages
don't support it. I do use multiple classification in conceptual
diagrams (you can find a few examples in Analysis Patterns, and the
notation there can easily be translated to UML).
In practice when you have multiple dimensions such as this, you can
either distinguish them through data values or by membership in an
external collection. However neither of those techniques support
polymophic behavior. To support polymorphism through multiple dimensions
you can use the state pattern.
So, getting back to your question, did I recommend single
classification? I do in implementation becuase that's your only choice,
it's kind of like recommending eyeballs for seeing. Conceptually however
multiple classification makes sense, then you have to decide how to
implement it. I might draw a UML diagram with multiple classification
while understanding a conceptual problem, essentially deferring
implementation until I've got some test cases to write.
If you want to dig more into this you can find some stuff on this in
Analysis Patterns, particularly section 14.2. Also Jim Odell's books
have more on this kind of thing.
Martin
HaimK
>multiple classification makes sense, then you have to decide how to
>implement it. I might draw a UML diagram with multiple classification
>while understanding a conceptual problem, essentially deferring
In business modeling, multiple (and dynamic) classifications are encountered
all the time. Rejecting them because <<insert your favorite implementation
mechanism here>> does not support it would be counterproductive. The above
(especially "deferring implementation") makes perfect sense.
See also
W.Harrison, H.Kilov, H.Ossher, I.Simmonds. From dynamic supertypes to objects:
A natural way to specify and develop systems. IBM Systems Journal, Vol. 35, No.
2 (June 1996), pp. 244-256,
the treatment of types and subtypes in the ISO Reference Model of Open
Distributed Processing, as well as my books on business modeling (the latest,
"Business models", was just published by Prentice-Hall).
HTH
-Haim Kilov
ha...@acm.org
krasicki
> if anyone could recommend a good book to start. Thanks in advance.
>
> -- charif
charif,
Do yourself a favor. Buy "C++ From the Ground Up" by Herbert Schildt.
This book starts from a context of C programming and then tells you
how it was transformed into C++. Reads like a novel and a great
reference.
Then try "Just Java" by Lindermann I think. Another lovely
masterpiece for anyone who wants to get it right.
When you get good, try "A Little Java, A few Patterns". I forget the
authors but MIT press. Stick with it - it's a gem.
Once you're good anything by Meyer(s) is great.
If you're into Java, "Practical Java" is a masterpiece.
Good luck.
Topmind
> > There is a question I have been meaning to ask you. One of
> > your books seemed to recommend the practice of
> > "hard partitioning". Do you generally recommend this
> > practice, or was it just an example that took shortcuts
> > for breivity purposes? (I didn't write down the
> > page number, sorry. It was an accounting example IIRC.)
>
>
> From your quote I'm assuming by 'hard partitionng' you mean allowing a
> class to be subclassed along only a single dimension. So you can't have
> a Person subclassed as (Man | Woman) and as (Doctor | Nurse).
>
> All the mainstream OO languages allow just a single dimension for
> subclassing. In the OOA&D world Jim Odell referred to this as "Single
> Classification" because a person could only have one classification that
> inherited others. That is you can be a Man (and therefore a Person). To
> support male nurses with subtyping you need multiple classification (you
> can be both a man and a nurse, and both imply being a person).
>
> The UML does support multiple classification, but it isn't used much as
> it doesn't make sense in an implementation perspective since languages
> don't support it.
That depends on how you view it. In relational thinking,
the "classification" is a virtual view. One issues relational
formulas to get the needed view for a given situation.
Any one view is not necessarily more important than
another, so it does not make sense to put some on a
diagram, and not others, unless your diagram is
to simply explore a given perspective.
One area where OO fans and I clash is the appearent
idea that the view modeling is "global" in OO
designs.
That is not very good "information hiding" in my
book. This "attitude" bothers me about OO, and
makes procedural/relational "modeling via formula"
superior in my mind, as it is easier to change
and experiment with formulas than global
declarations. And, you can have a noun participate
in a 100 different views without cluttering the global
view.
I don't want to get into a flame-war here, I just
want to understand why OO fans don't see this
as limiting, while I do.
Are there significant benefits to "magnifying a single
division" over other candidates that I am not
seeing?
> I do use multiple classification in conceptual
> diagrams (you can find a few examples in Analysis Patterns, and the
> notation there can easily be translated to UML).
>
> In practice when you have multiple dimensions such as this, you can
> either distinguish them through data values or by membership in an
> external collection. However neither of those techniques support
> polymophic behavior. To support polymorphism through multiple dimensions
> you can use the state pattern.
Polymorphism depends on the over-emphasis of a single
dimension IMO. It is an IS-A view in a HAS-A world,
as your nurse example demonstrates.
>
> So, getting back to your question, did I recommend single
> classification? I do in implementation becuase that's your only choice,
That is not a good thing, if you ask me.
> it's kind of like recommending eyeballs for seeing. Conceptually however
> multiple classification makes sense, then you have to decide how to
> implement it. I might draw a UML diagram with multiple classification
> while understanding a conceptual problem, essentially deferring
> implementation until I've got some test cases to write.
The test cases will then "suggest" that you pick one
partitioning dimension over others? (Or use
complex patterns)
>
> If you want to dig more into this you can find some stuff on this in
> Analysis Patterns, particularly section 14.2. Also Jim Odell's books
> have more on this kind of thing.
>
> Martin
>
Thank you for your feedback,
-T-
Topmind
Since you used the "G" word, it is time to point
out some criticism of Meyer's most famous work:
http://geocities.com/tablizer/meyer1.htm
>
> If you're into Java, "Practical Java" is a masterpiece.
>
>
> Good luck.
>
-T-
Martin Fowler
> Are there significant benefits to "magnifying a single
> division" over other candidates that I am not
> seeing?
From a conceptual point of view, no.
From an implementation point of view, yes.
I've not seen a language that did multiple classification, although I'm
sure some must be lurking in research labs somewhere. I imagine the
reason they don't catch on is because it's hard to see how to resolve
the methods in a general case. If both female and doctor define the
method foo, and you call foo on a female doctor - what do you do?
Multiple inheritance leads to similar problems and the view of most
language designers now is that the power of multiple inheritance isn't
worth the cost both of implementing it and understanding it. I suspect a
similar trade-off was made with respect to multiple classification -
although I'm not a language designer so I can't pretend to understand
all the issues here.
>
> The test cases will then "suggest" that you pick one
> partitioning dimension over others? (Or use
> complex patterns)
>
Yes, I'll use inheritance for the one that seems the most dominant, and
use state (or similar) for the others. (Hence the phrase, "inheritance
is card you can play only once".) I don't think there's a way to tell
other than from the actual requirements you are working with.
Martin
Phlip
> Do yourself a favor. Buy "C++ From the Ground Up" by Herbert Schildt.
And before you buy, go to http://groups.google.com and enter:
schildt group:comp.lang.c++
Oh, the rockets' red glare - flames bursting in air!
--
Phlip
http://www.greencheese.org/HatTrick
-- MCCD - Microsoft Certified Co-Dependent --
Topmind
Well, IMO procedural/relational techniques handle these kind
of situations better. You don't have
to rank one dimension above the
other, and can change the dispatching rules simply by
changing the dispatching formulas (boolean and/or relational).
It is simple, strait-forward, and flexible.
OO seems to get stumped or convoluted when multiple
factors control or can control behavior dispatching.
This is why I think OO seems to do well in "natural
domains" where the rules of nature are (assumed to
be) fixed, but not so well where the rules are changed
by the fluid thinking of managers, marketers, customers
and/or politicians.
Do you agree with this assessement, even to a lessor
degree perhaps?
-T-
Graham Perkins
> there are dozens (b) hack around with Java on your own, (c) read some
> books on UML and/or RUP, the leading OO analysis/design approach
> today.
I would be interested if you have found a good intro
book on Java that actually makes a decent attempt at the
OO paradigm. With the amount of Java teaching to support
at this college (and presumably many others) it is very
frustrating to find that most intro Java books are
so heavily procedural in approach. And those that attempt
OO approach seem laden with erroneous conceptions.
What we need is for someone who does lots of real OO
and loves eiffel, smalltalk, python, design patterns,
and two or three OO methodologies to sit down and write
an intro Java book instead of all those advanced
high-level books.
Perhaps they've already done it, but output lost
in the sea of junk texts?
-------------+ http://www.mk.dmu.ac.uk/~gperkins/
Graham Perkins
> language designers now is that the power of multiple inheritance isn't
> worth the cost both of implementing it and understanding it.
Is this really the case? It seems to me more likely that the view
is far more pragmatic: Language designers think they can get away
with not implementing it.
Java is a good example here. I see MI like generics: a few man-
years effort by designers and compiler writers could create a good
clean mechanism that would already have saved millions of man-years
of tedious coding by all the users.
But they correctly guessed that their system could sweep through a
mass market without any need to devote more effort to quality. It's
how industrial capitalism works :-(
-------------+ http://www.mk.dmu.ac.uk/~gperkins/
krasicki
charif
My recommendations are strictly based on your assertion that you know
a little programming and are a beginner to OO.
I will stick by my recommendations. I am not recommending the most
comprehensive or authoritative books you can buy. These are intended
as easy reads that are readable. As you get better at the practice of
programming, certainly you will find indespensible reference materials
by browsing the book offerings and reading reviews.
And truthfully, some of the critics may make a good point or two but
there are not enough cycles in the day to worry about these things.
No single book will guarantee success and your own taste and critical
judgement will guide you true.
Martin Fowler
> Do you agree with this assessement, even to a lessor
> degree perhaps?
I'd rather not go down that path. Too much bandwidth on this group is
wasted on debating the pros and cons of OO - and it's not a debate I
find particularly interesting.
Martin
Kevin Cline
Not much. Here's a real example, from a real business application.
I'm currently working on a large procedural retail ordering
application.
There are many actions (maybe two dozen) which can be performed on an
order, and perhaps forty different product types which require special
handling for one or more of those actions.
The system, being written with an procedural (action-centric)/
mindset, is organized by ordering action. Thus we see code like this:
delete_product_from_order(Order ord, Product prod)
{
// validation
switch(prod.type) {
case B:
// if this is the last 'B', return warning
case
...
}
// execution special cases
switch (prod.type) {
case A:
// also delete all 'B_TYPE' products
case B:
...
case C:
// update special-handling flag
case D:
...
}
}
add_product_to_order(Order ord, Product prod)
{
switch () ...
switch () ...
}
Of course the ordering actions are quite stable, but new product
types are continually introduced. The action-oriented organization
of the program makes this quite difficult and error-prone.
The business rules for each product type are scattered throughout
the code. The existing code must be touched in many places, and each
change
may break the existing code. It is often necessary to merge changes
from
developers working on different product types. Maintenance is
expensive
and risky. Writing automated tests for any particular action is very
difficult because of the large number of possible paths through the
code.
The system would be much easier and cheaper to maintain if it
were organized by product type (e.g. object-oriented rather than
procedurally aligned). One would have a base class:
class Product_Type {
validate_add_to_order(Order ord);
add_to_order(Order ord);
validate_delete_from_order(Order ord);
delete_from_order(Order ord);
...
}
and a derived class for each product type:
class A_Product_Type: Product_Type {}
class B_Product_Type: Product_Type ()
Now adding a new product type could be done by writing
a single new class. There would be no danger of screwing up
processing of orders that didn't include the new product type.
Testing could be done product type by product type, and the
number of paths through each function would be small (often only one
or two).
Most business systems share this property: the fundamental actions
supported
stabilize early, but the rules for those actions change frequently as
new classifications are introduced.
Tak To
First, let me apologize for this is not an answer to your questions. Instead,
I would like to ask you a couple of questions.
- Have you had any exposure to OO? If so, could you tell us what you
think "the field" of OO is? I am not asking for a precise definition;
any impressionistic notion would suffice.
- Regardless of your exposure to OO, why do you want to persue OO? Is
it simple curiosity, or because you think OO somehow is "useful",
"good", or "marketable" etc?
The reason I ask is that there is continual debate in this group, in which
one fraction holds the opinion that there is a "Phenomenon of OO" that is not
buttressed by actual technical merits, and that a lot of people are confused
by it (The Phenomenon). Another fraction holds that OO deserves all its
glory and that any attempt to debunk the so the called myth is a waste of
bandwidth of the group. The answer from a new commer like yourself would
perhaps help clarifying the issues for all of us.
Thanks in advance.
Tak
-----------------------------------------------------------+----------
Tak To ta...@alum.mit.edu.-
--------------------------------------------------------------------^^
[taode takto ~{LU5B~}] NB: trim the .- to get my real email addr
Buck The Wonder Dog
news:3D25D2C4...@alum.mit.edu.-...
The reason why your post qualifies for the most ridiculous of the day is the
fact that the marketplace has for the last decade already decided that OO is
the way to go, all the programming jobs are for implementing OO solutions,
so get lost troll.
Topmind
That is bull-honk!
Yes, the languages currently be pushed are indeed OO, however, many
OO fans agree that *actual* code being produced is rather
procedural in natural. IOW, programmers are grouping by
tasks and using IF statements and case statements (and
some tables) to dispatch behavior instead traditional
polymorphism or goofy GOF patterns.
IOW, there are a bunch of Java programmers out there
using classes as nothing but wordy procedural modules.
OO has won over PHB's more than it has programmers
because of all the clever cliches and catchy
shape and animal and device driver examples (that
don't scale to the real world).
-T-
Topmind
It sounds like a more tablized approach may work
where there are "features" to be selected or de-selected
per product. The features likely are going to be
orthogonal, which polymorphism chokes on.
Polymorphism assumes mutually exclusive categories.
However, the real world often takes a sh*t on
mutual exclusion in my observation.
And orthogonal ones also.
I have dealt with this, and trees barf when the size of
the operation exceeds a certain point.
Complex things just do NOT stay in tree-wise classifications
in the biz world.
For more on this, see:
http://geocities.com/tablizer/sets1.htm
-T-
Buck The Wonder Dog
news:MPG.178f82078...@news.earthlink.net...
topmind, just keep searching for those procedural jobs.....
Charif Lakchiri
First I'd like to thank everyone for your kind recommendations. I have
truely benefited from the numerous pointers to books and web resources that
I could not dig up by myself. I have not decided yet what to buy first, but
I have a broad idea on what kind of books exist on the market and what kind
of book would be suitable for a person such as myself.
"Tak To" <ta...@alum.mit.edu.-> wrote in message
news:3D25D2C4...@alum.mit.edu.-...
> charif wrote:
> >
(...)
>
> - Have you had any exposure to OO? If so, could you tell us what you
> think "the field" of OO is? I am not asking for a precise definition;
> any impressionistic notion would suffice.
>
Well, to be honest, I haven't had any serious exposure to OO. My major is
Information Engineering. We study a little bit of everything related to IT,
starting by programming, going through the different areas of computer
science, communications, electronics...etc.
I have 2 more years to go to graduate, so it's time for me to make up my
mind on what kind of job I want to have. Lately, I started feeling good
about programming, and the process of creating programs that can run on a
computer, so I decided I want to be a software engineer. I have programming
experience with procedural languages like C, pascal... and some functional
languages like SML, OCaml... but no experience with Object-Oriented
Languages. We don't have any course on OO in our curriculum. Besides, I've
read some articles from computer magazines that talk about OO, and how it
has become the trend in the software industry in the late decade, like Mr.
The Wrong Dog said. So at first I was curious about OO, but then it became
kind of obvious to me that I should learn Object Technology if I wanted to
become a better programmer and hopefully a software engineer in the future.
I think that knowing - and if possible mastering - different kinds of ways
and techniques to program is what makes the difference bitween a good
software engineer and a not-so-good one, right?
> - Regardless of your exposure to OO, why do you want to persue OO? Is
> it simple curiosity, or because you think OO somehow is "useful",
> "good", or "marketable" etc?
>
I've read some brief introductions about OO, and so far I have come to
understand that some problems can be solved easier or faster, or perhaps
more effectively by thinking in objects. For me, it was like when I have a
problem, I should do this, this, this and then that. And if I had something
like this, I should do that. And while I had something like this, I should
always do that... in other terms, the procedural approach. But when I read
about the OO way of thinking about the problem and trying to use objects,
manipulating them, making them inherit properties, making them communicate
with eachother, making them have different properties while having the same
names for them (I am not really sure about these definitions of inheritance,
messages, polymorphysm...), I tought that maybe this can be a better way of
thinking about and hadling the problem. So this is why I want to learn
Object-Oriented thinking. Even if it doesn't help me achieve my goals, it
would still be a plus to have in my knowledge, I think.
> The reason I ask is that there is continual debate in this group, in which
> one fraction holds the opinion that there is a "Phenomenon of OO" that is
not
> buttressed by actual technical merits, and that a lot of people are
confused
> by it (The Phenomenon). Another fraction holds that OO deserves all its
> glory and that any attempt to debunk the so the called myth is a waste of
> bandwidth of the group. The answer from a new commer like yourself would
> perhaps help clarifying the issues for all of us.
>
> Thanks in advance.
You're welcome.
I hope this answers your questions Tak.
Any comments and/or opinions from any one are all welcome.
Cheers.
-- charif
Topmind
> > > The reason why your post qualifies for the most ridiculous of the day is
> the
> > > fact that the marketplace has for the last decade already decided that
> OO is
> > > the way to go, all the programming jobs are for implementing OO
> solutions,
> > > so get lost troll.
> > >
> >
> > That is bull-honk!
> >
> > Yes, the languages currently be pushed are indeed OO, however, many
> > OO fans agree that *actual* code being produced is rather
> > procedural in natural. IOW, programmers are grouping by
> > tasks and using IF statements and case statements (and
> > some tables) to dispatch behavior instead traditional
> > polymorphism or goofy GOF patterns.
> >
> > IOW, there are a bunch of Java programmers out there
> > using classes as nothing but wordy procedural modules.
> >
> > OO has won over PHB's more than it has programmers
> > because of all the clever cliches and catchy
> > shape and animal and device driver examples (that
> > don't scale to the real world).
> >
> > -T-
>
> topmind, just keep searching for those procedural jobs.....
>
You are not getting it.
Nobody is going to *say* they are doing "procedural"
programming, nor ask for it by name. They just
do it in an OOP language, and call it OO.
"Yanked dOOdle went to town, riding on BS,
Stuck polymorphism in his hat, and made
a screwy mess."
Buck The Wonder Dog
the problem I have with those flame war is that there is lack of reason. OOD
is necessary to model large systems and objects. Procedural programming is
necessary to fill out the object methods and for libraries. Why can't we
just all get along?
Topmind
>
> the problem I have with those flame war is that there is lack of reason. OOD
> is necessary to model large systems and objects.
You are right, there is a lack of reason.
"Necessary"? That is a pretty strong statement.
Where exactly does procedural fail in "large systems"?
In good large p/r systems, you pretty much can focus
on one task at a time. That task communicates with other
tasks mostly via the database.
Large database schema is 10 times easier to comprehend
than a large object model, because the schema does not
model behavior for the most part. Attributes are inheritantly
easier to grok than behavior. One's "messages" to the
database simply alter attributes to communicate with
other tasks. That is the beauty of p/r.
> Procedural programming is
> necessary to fill out the object methods and for libraries. Why can't we
> just all get along?
Until the excess OO hype dies down, I will beat on OO like
Reginal Denny was.
>
-T-
Costin Cozianu
> Hi all,
>
> First I'd like to thank everyone for your kind recommendations. I have
> truely benefited from the numerous pointers to books and web resources that
> I could not dig up by myself. I have not decided yet what to buy first, but
> I have a broad idea on what kind of books exist on the market and what kind
> of book would be suitable for a person such as myself.
>
> "Tak To" <ta...@alum.mit.edu.-> wrote in message
> news:3D25D2C4...@alum.mit.edu.-...
> > charif wrote:
> > >
>
> (...)
>
> >
> > - Have you had any exposure to OO? If so, could you tell us what you
> > think "the field" of OO is? I am not asking for a precise definition;
> > any impressionistic notion would suffice.
> >
>
> Well, to be honest, I haven't had any serious exposure to OO. My major is
> Information Engineering. We study a little bit of everything related to IT,
> starting by programming, going through the different areas of computer
> science, communications, electronics...etc.
> I have 2 more years to go to graduate, so it's time for me to make up my
> mind on what kind of job I want to have. Lately, I started feeling good
> about programming, and the process of creating programs that can run on a
> computer, so I decided I want to be a software engineer. I have programming
> experience with procedural languages like C, pascal... and some functional
> languages like SML, OCaml... but no experience with Object-Oriented
> Languages.
You've said two magic words SML and OCaml. If you have exposure to
such elegant and powerful languages it is really a pitty to dive into
OO. From my experience, I wish I could have discovered functional
programming paradigm sooner rather than later. I first got exposure to
Pascal and then straight to OO, through Object Pascal and C++, later
Java, Smalltalk, Ada'95 and the whole enchilada. I got to the point
where I coudln't have started a program before thinking in classes and
objects and this was wrong.
Having learnt later paradigms other than OO (logic programming,
relational databases), I discovered lots of programming and design
mistakes that are common places in OO approach.
> We don't have any course on OO in our curriculum. Besides, I've
> read some articles from computer magazines that talk about OO, and how it
> has become the trend in the software industry in the late decade, like Mr.
> The Wrong Dog said. So at first I was curious about OO, but then it became
> kind of obvious to me that I should learn Object Technology if I wanted to
> become a better programmer and hopefully a software engineer in the future.
> I think that knowing - and if possible mastering - different kinds of ways
> and techniques to program is what makes the difference bitween a good
> software engineer and a not-so-good one, right?
Right, but it depends from whom you learn. In particular OO is the
most difficult approach to get it done right, and, unfortunately it is
the most easily trivialized under such pittiful and empty dogmas like
"everything is an object".
Keep in mind that while OO is a interesting and useful paradigm, it
doesn't naturally fit to all the problem domains, and in some cases OO
ideas are mis
My advice is for you to disregard any book on OO available on the
bookshelf at your local bookstore. For a person with your background
I'd recommend to read "Object Oriented Programming in the Beta
Programming Language" to get a proper exposure from the inventor of OO
himself. It is freely available from in PDF
ftp://ftp.mjolner.com/BETA/BOOK/betabook.pdf. It's a much better book
than most of the currently en-vogue ramblings on OO.
> > - Regardless of your exposure to OO, why do you want to persue OO? Is
> > it simple curiosity, or because you think OO somehow is "useful",
> > "good", or "marketable" etc?
> >
>
> I've read some brief introductions about OO, and so far I have come to
> understand that some problems can be solved easier or faster, or perhaps
> more effectively by thinking in objects. For me, it was like when I have a
> problem, I should do this, this, this and then that. And if I had something
> like this, I should do that. And while I had something like this, I should
> always do that... in other terms, the procedural approach. But when I read
> about the OO way of thinking about the problem and trying to use objects,
> manipulating them, making them inherit properties, making them communicate
> with eachother, making them have different properties while having the same
> names for them (I am not really sure about these definitions of inheritance,
> messages, polymorphysm...), I tought that maybe this can be a better way of
> thinking about and hadling the problem. So this is why I want to learn
> Object-Oriented thinking. Even if it doesn't help me achieve my goals, it
> would still be a plus to have in my knowledge, I think.
There is no "OO thinking". There is dogmatic thinking and free
thinking. A professional software engineer has to have a decent
cultural exposure to all major ideas and approaches in computer
science. Than he has to analyze the problem at hand, and decide what
particular set of tools/development paradigm is the best fit. Most of
the times only one paradigm is not enough because of the complexities
of the problem. So you often need to combine OO and functional , or
logic programming or even, yes, old style procedural programming.
But to get to the heart of the OO paradigm, I think that the BETA book
is the best introduction one would ever want. Plus most of the books
on OO contain bogus science, bad advice, flawed design example and
lots of cool stuff like that. You might want to get a distance from
the most popular authors and most popular trends.
Especially you might want to stay away in the beginning from stuff
like Java and UML. These are required by the industry and the job
market, but you can easily learn them overnight if you want to, as
long as you have the proper foundation.
The next book that helped me a lot to get the proper exposure to OO,
and I recommend it to you is "Principles Of Object oriented Software
Development" by Anton Eliens. This one will introduce you to the
fundamentals behind Object Orientation. This is also available for
free to browse in HTML on author's home page, if you want but the
printed edition is definitely worth the money.
Cheers,
Costin
Topmind
> > Well, to be honest, I haven't had any serious exposure to OO. My major is
> > Information Engineering. We study a little bit of everything related to IT,
> > starting by programming, going through the different areas of computer
> > science, communications, electronics...etc.
> > I have 2 more years to go to graduate, so it's time for me to make up my
> > mind on what kind of job I want to have. Lately, I started feeling good
> > about programming, and the process of creating programs that can run on a
> > computer, so I decided I want to be a software engineer. I have programming
> > experience with procedural languages like C, pascal... and some functional
> > languages like SML, OCaml... but no experience with Object-Oriented
> > Languages.
>
> You've said two magic words SML and OCaml. If you have exposure to
> such elegant and powerful languages it is really a pitty to dive into
> OO. From my experience, I wish I could have discovered functional
> programming paradigm sooner rather than later. I first got exposure to
> Pascal and then straight to OO, through Object Pascal and C++, later
> Java, Smalltalk, Ada'95 and the whole enchilada. I got to the point
> where I coudln't have started a program before thinking in classes and
> objects and this was wrong.
>
> Having learnt later paradigms other than OO (logic programming,
> relational databases), I discovered lots of programming and design
> mistakes that are common places in OO approach.
>
Care to share any by chance?
I would be happy to add them to my webpage:
http://www.geocities.com/tablizer/oopbad.htm
:-)
-T-
H. S. Lahman
>> I am new to the field. I have some programming experience. I was
>> wondering
>> if anyone could recommend a good book to start. Thanks in advance.
>
>
> My first choice for starting with OO would be Applying UML and Patterns
> by Craig Larman. (http://www.amazon.com/exec/obidos/ASIN/013092569). The
> main title is a bit misleading, the subtitle (An Introduction to
> Object-Oriented Analysis and Design and the Unified Process) is a better
> description of the book.
Actually, I think the title is well suited. The book is an excellent
treatment of the mechanics of using UML and patterns within the UP
context. Unfortunately it doesn't have a lot to say about the
fundamentals of OOA/D. So it would be my second choice for a beginner
after a good OOA/D book. B-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Tak To
Thanks for your reply.
CL> [...] I have programming
CL> experience with procedural languages like C, pascal... and some functional
CL> languages like SML, OCaml... but no experience with Object-Oriented
CL> Languages. We don't have any course on OO in our curriculum. Besides, I've
CL> read some articles from computer magazines that talk about OO, and how it
CL> has become the trend in the software industry in the late decade, like Mr.
CL> The Wrong Dog said. So at first I was curious about OO, but then it became
CL> kind of obvious to me that I should learn Object Technology if I wanted to
CL> become a better programmer and hopefully a software engineer in the future.
CL> I think that knowing - and if possible mastering - different kinds of ways
CL> and techniques to program is what makes the difference bitween a good
CL> software engineer and a not-so-good one, right?
CL>
CL> I've read some brief introductions about OO, and so far I have come to
CL> understand that some problems can be solved easier or faster, or perhaps
CL> more effectively by thinking in objects. For me, it was like when I have a
CL> problem, I should do this, this, this and then that. And if I had something
CL> like this, I should do that. And while I had something like this, I should
CL> always do that... in other terms, the procedural approach.
I am a little bit confused here. What is this "procedural approach" which
is distinct from "thinking in objects"?
CL> But when I read
CL> about the OO way of thinking about the problem and trying to use objects,
CL> manipulating them, making them inherit properties, making them communicate
CL> with eachother, making them have different properties while having the same
CL> names for them (I am not really sure about these definitions of inheritance,
CL> messages, polymorphysm...), I tought that maybe this can be a better way of
CL> thinking about and hadling the problem.
Do any of these new techniques repudiate what you have learnt as the
"procedural approach"?
Do these articles convey that OO is just additional technique over
"procedural"; or do they convey that OO is mutually exclusive with
"procedural"? If the latter, do they convey the idea that OO is
always better?
Thanks for your reply.
Chris Hanson
wrote:
> I've not seen a language that did multiple classification, although I'm
> sure some must be lurking in research labs somewhere. I imagine the
> reason they don't catch on is because it's hard to see how to resolve
> the methods in a general case. If both female and doctor define the
> method foo, and you call foo on a female doctor - what do you do?
This might be possible in CLOS or Dylan. They both have multiple
inheritance and do full multimethod dispatch -- the most specific
method is selected based on the types of its arguments, and any calls
to "next-method" within the method will call the next most specific
method.
I'm not sure about CLOS, but in Dylan you can even create a method
that's specific on one value (i.e. you can create a method Foo(x = 5)
*and* a method Foo(x :: <integer>); the first will be called before the
second if someone calls Foo(5).)
Unfortunately, understanding exactly what's going to happen in a
language with full multimethod dispatch can be difficult. Especially
if you have both the methods Foo(p :: <female>) and Foo(p :: <doctor>)
and you call Foo(doctorAlice)... I can't tell you what would happen in
that case off the top of my head, though if I page through the language
reference manual I might be able to figure it out...
(Incidentally, I think this is one of the two things that doomed Dylan.
The first was a switch from its original "Scheme with CLOS on steroids"
S-expression syntax to an "Algol-like" syntax, to appease Pascal and
C/C++ programmers who freaked out when they saw it and would never have
used the language anyway, and the very long delay this caused as some
fundamental research was done on things like syntax-extension hygienic
macro systems for infix languages. The second is that it was just too
far beyond the complexity barrier for most working software developers
to understand or take advantage of, much less get an intuitive handle
on.)
-- Chris
--
Chris Hanson | Email: c...@bDistributed.com
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: c...@mac.com
Shane Mingins
> if anyone could recommend a good book to start. Thanks in advance.
>
Hi
I have been learning OO coming from a stryctured programming
background.
Have yet to find the "book you must have" as the really good OO books
seem to be on a specfic topics/areas.
I have had the benefit of some courses but for some basic reading (and
free) you can look at the sun site www.java.sun.com for their starting
tutorials.
Bruce Eckel has a e-book called Thinking in Java which has
introductory chapters on OO concepts. http://www.bruceeckel.com
I am reading Bertrand Meyers OOSC2 and at this stage (chapter 8) it is
reasonably abstract and describes what he would see as the perfect OO
environment (which you have to then follow another notation to read
his examples). As a programmer I prefer more practical approaches and
I know what language I am going to be using so who cares about what it
is lacking.
This may (or may not) help.
Shane
Thaddeus L Olczyk
>krasicki wrote:
>
>> Do yourself a favor. Buy "C++ From the Ground Up" by Herbert Schildt.
>
>And before you buy, go to http://groups.google.com and enter:
>
> schildt group:comp.lang.c++
>
>Oh, the rockets' red glare - flames bursting in air!
http://www.accu.org/bookreviews/public/reviews/0au/s.htm
You'll probably have to search for the name, but once you find it
it's very distinct. Row upon row of bright red Not Reccomended s.
Thaddeus L Olczyk
wrote:
>I am new to the field. I have some programming experience. I was wondering
>if anyone could recommend a good book to start. Thanks in advance.
>
>-- charif
>
http://www.accu.org/cgi-bin/accu/rvout.cgi?from=0au_p&file=f002208a
I liked hiw first book better though ( despite the screwy notation ).
It was titled "What Every Programmer Should..."
Willard Thompson
> > I am new to the field. I have some programming experience. I was wondering
> > if anyone could recommend a good book to start. Thanks in advance.
>
I think that the best book for OO programming is B. Meyer,
Object-Oriented Software Construction, 2nd Ed., United States:
Prentice Hall, 1997. However, it might not be the best start off
because it is rather comprehensive.
Willard
krasicki
WRONG! Get yourself some glasses. It is reviewed in 1995. No other
comment accompanies this fact.
A lot of you critics are just a bunch of lemmings, IMHO. Read the
book, it's great.
Phlip
>> >
>> >Oh, the rockets' red glare - flames bursting in air!
>> http://www.accu.org/bookreviews/public/reviews/0au/s.htm
>> You'll probably have to search for the name, but once you find it
>> it's very distinct. Row upon row of bright red Not Reccomended s.
>
>
> WRONG! Get yourself some glasses. It is reviewed in 1995. No other
> comment accompanies this fact.
>
> A lot of you critics are just a bunch of lemmings, IMHO. Read the
> book, it's great.
Ask C++ folks like Pete Becker how great it is.
I learned C, design and coding, a long time ago from Schildt's C books. He
writes in a firm yet tender style that leads one gracefully thru hard
concepts.
And this often means he'l sacrifice accuracy for breeziness. But his
ultimate sin is he refused to create an Errata site, or even to fix the
problems in later editions of his books. Things as dreadfully obvious as
'void main' - things that the C++ community finds itself straightening
newbies out over again and again.
--
Phlip
http://www.greencheese.org/HoneySatellite
-- Who needs a degree when we have Web e-search engines? --
krasicki
> >> > schildt group:comp.lang.c++
> >> >
> >> >Oh, the rockets' red glare - flames bursting in air!
>
> >> http://www.accu.org/bookreviews/public/reviews/0au/s.htm
> >> You'll probably have to search for the name, but once you find it
> >> it's very distinct. Row upon row of bright red Not Reccomended s.
> >
> >
> > WRONG! Get yourself some glasses. It is reviewed in 1995. No other
> > comment accompanies this fact.
> >
> > A lot of you critics are just a bunch of lemmings, IMHO. Read the
> > book, it's great.
>
> Ask C++ folks like Pete Becker how great it is.
I don't know who Pete Becker is, nor do I care.
>
> I learned C, design and coding, a long time ago from Schildt's C books. He
> writes in a firm yet tender style that leads one gracefully thru hard
> concepts.
This is my entire point excatly. I can tell you I have taught at the
community college level and if you look at the alternatives to Schildt
you quickly realize that almost everyone else misses the beginner's
mark. His work is very, very comprehensible.
To suggest Meyers as a beginning text is hallucinatory. There are no
perfect texts and even the ones that I like certainly leave things
that might be more desirable but so what?
>
> And this often means he'l sacrifice accuracy for breeziness. But his
> ultimate sin is he refused to create an Errata site, or even to fix the
> problems in later editions of his books. Things as dreadfully obvious as
> 'void main' - things that the C++ community finds itself straightening
> newbies out over again and again.
Presumably these newbies you refer to aren't the dumb asses you make
them out to be. Any author who can present this information
gracefully should be thanked. No doubt there are errors and if you
want to be the errata police then have the time of your life.
As for the C++ community, they have straightened newbies out enough
for newbies to realize the Java community is a much healthier place to
operate.
Schildt's book passes a very basic law - that of sufficiency for what
its attempting to accomplish. And, I will add, he has the courage to
present the information to be understood. There are no other beginner
books that I'm aware of that don't fall into the C++/OO obfuscation
trap. 'Nuff said.
Thaddeus L Olczyk
wrote:
>Thaddeus L Olczyk <olc...@interaccess.com> wrote in message news:<abpuiusubkusokq04...@4ax.com>...
>> On 05 Jul 2002 05:05:37 GMT, Phlip <phli...@yahoo.com> wrote:
>>
>> >krasicki wrote:
>> >
>> >> Do yourself a favor. Buy "C++ From the Ground Up" by Herbert Schildt.
>> >
>> >And before you buy, go to http://groups.google.com and enter:
>> >
>> > schildt group:comp.lang.c++
>> >
>> >Oh, the rockets' red glare - flames bursting in air!
>> http://www.accu.org/bookreviews/public/reviews/0au/s.htm
>> You'll probably have to search for the name, but once you find it
>> it's very distinct. Row upon row of bright red Not Reccomended s.
>
>
>WRONG! Get yourself some glasses. It is reviewed in 1995. No other
>comment accompanies this fact.
>
I already have glasses. They work quite well. Instead I suggest you
get a rectal-cranial extraction.
The first edition is reviewed in 1995. No comment accompanies it.
Furthermore reading the review, one gets the clear impression that it
does not cover OO. Even if it did cover C++ well it would make it a
bad recommendation. The person asked for an introduction to OO not
C++.
I have already had enough experience with Schildts books. I don't need
any more. However the OP as well as anyone else reading may need some.
I would say that any author who racks up ( how many, too many for me
to bother counting ) "Not Recommended"s but fails to acquire a single
Recommended much less "Highly Recommended" speaks for itself.
Why anyone would ever bother to even consider such an author for
*anything* beats me.
>A lot of you critics are just a bunch of lemmings, IMHO.
In your very inexperienced and uniformed opinion.
As for lemmings, I know of very few people who can write
C++ better than I can. I don't think lemmings apply.
>Read the
>book, it's great.
Aside from the fact that I probably know about ten times
as much C++ as Schildt ever will, it would be an enormous waste
of my time. Judging from the two reviews of the second edition,
I guess even beginners will find it so.
Instead take the latest offering of Lipmann's or Accelerated C++
by Koenig and Moo for introductory texts.
Thaddeus L Olczyk
wrote:
>Phlip <phli...@yahoo.com> wrote in message news:<l7sY8.563$Xl4.13...@newssvr16.news.prodigy.com>...
>> >> > schildt group:comp.lang.c++
>> >> >
>> >> >Oh, the rockets' red glare - flames bursting in air!
>>
>> >> http://www.accu.org/bookreviews/public/reviews/0au/s.htm
>> >> You'll probably have to search for the name, but once you find it
>> >> it's very distinct. Row upon row of bright red Not Reccomended s.
>> >
>> >
>> > WRONG! Get yourself some glasses. It is reviewed in 1995. No other
>> > comment accompanies this fact.
>> >
>> > A lot of you critics are just a bunch of lemmings, IMHO. Read the
>> > book, it's great.
>>
>> Ask C++ folks like Pete Becker how great it is.
>
>I don't know who Pete Becker is, nor do I care.
>
In other words you don't care to know who the person who
wrote/presided over the writing of code that most of your students
routinely use, well OK not *your* students. But code that most high
quality students and serious developers routinely use.
Perhaps refunds are in order.
>>
>> I learned C, design and coding, a long time ago from Schildt's C books. He
>> writes in a firm yet tender style that leads one gracefully thru hard
>> concepts.
>
>This is my entire point excatly. I can tell you I have taught at the
>community college level and if you look at the alternatives to Schildt
>you quickly realize that almost everyone else misses the beginner's
>mark. His work is very, very comprehensible.
Lipman, Keonig and Moo do quite well. They also have the advantage of
not teaching enough C++ to be dangerous but not enough C++ to be safe.
>
>To suggest Meyers as a beginning text is hallucinatory.
No one suggested Scott Meyers as a begining text.
OTOH if you mean Bertrand Meyer then it is goodas a begining text.
( Allthough I would not recommend learning a language like Eiffel as
the first OO language. rather get something commercially viable
instead.
> There are no
>perfect texts and even the ones that I like certainly leave things
>that might be more desirable but so what?
>
But the texts you like teach one bad C++ programming techniques.
That means most other texts are much more desirable.
>
>>
>> And this often means he'l sacrifice accuracy for breeziness. But his
>> ultimate sin is he refused to create an Errata site, or even to fix the
>> problems in later editions of his books. Things as dreadfully obvious as
>> 'void main' - things that the C++ community finds itself straightening
>> newbies out over again and again.
>
>Presumably these newbies you refer to aren't the dumb asses you make
>them out to be.
Actually many aren't. I notice they avoid Schildt's books.
>Any author who can present this information
>gracefully should be thanked.
For making bad programmers. Hardly.
>No doubt there are errors and if you
>want to be the errata police then have the time of your life.
Like consistently, across how many books, not testing for self
assignment? Those aren't errors. Schildt just doesn't know C++.
>
>As for the C++ community, they have straightened newbies out enough
>for newbies to realize the Java community is a much healthier place to
>operate.
Not really Schildt writes Java books too.
>
>Schildt's book passes a very basic law - that of sufficiency for what
>its attempting to accomplish.
Making money for Schildt. Possibly allthough with the reviews he keeps
getting how long will that last.
>And, I will add, he has the courage to
>present the information to be understood.
Yes. It takes a certain type of courage to write bad books. The same
kind of courage that CEOs who lie about their profits have. Frankly we
are better off without that kind of courage.
> There are no other beginner
>books that I'm aware of that don't fall into the C++/OO obfuscation
>trap.
Either you haven't looked very hard. Or you actually believe that
books like Lipmann or Koenig and Moo.
If it is the later then please don't consult in C++. Sure I can make a
ton cleaning up messes made by people like you, but I would rather see
the code done right in the first place.
krasicki
> On 15 Jul 2002 16:53:09 -0700, kras...@consultant.com (krasicki)
> wrote:
>
> >Phlip <phli...@yahoo.com> wrote in message news:<l7sY8.563$Xl4.13...@newssvr16.news.prodigy.com>...
> >> >> > schildt group:comp.lang.c++
Row upon row of bright red Not Reccomended s.
> >> >
> >> >
> >> > WRONG! Get yourself some glasses. It is reviewed in 1995. No other
> >> > comment accompanies this fact.
> >> >
> >> > A lot of you critics are just a bunch of lemmings, IMHO. Read the
> >> > book, it's great.
> >>
> >> Ask C++ folks like Pete Becker how great it is.
> >
> >I don't know who Pete Becker is, nor do I care.
> >
> In other words you don't care to know who the person who
> wrote/presided over the writing of code that most of your students
> routinely use, well OK not *your* students. But code that most high
> quality students and serious developers routinely use.
>
> Perhaps refunds are in order.
Ted, I have Java 2, the Complete Reference by Naughton and Schildt
open to introductory pages talking about the history of C, C++, and
Java. Peter Becker is not even a footnote. Oh, I know, it's because
Schildt wrote the book.
One of the reasons I swear by Schildt books is that they are great
value to students and beginners who could buy much more expensive
tomes that lose their interest in three pages. The readability of
Schildt provides a deeper and longer attention span for the subject
matter which is dense.
I cannot excuse lack of accuracy but if you are so committed to it,
write Osborne - they do track errata. Instead you piss and moan.
> >>
> >> I learned C, design and coding, a long time ago from Schildt's C books. He
> >> writes in a firm yet tender style that leads one gracefully thru hard
> >> concepts.
> >
> >This is my entire point excatly. I can tell you I have taught at the
> >community college level and if you look at the alternatives to Schildt
> >you quickly realize that almost everyone else misses the beginner's
> >mark. His work is very, very comprehensible.
>
> Lipman, Keonig and Moo do quite well. They also have the advantage of
> not teaching enough C++ to be dangerous but not enough C++ to be safe.
>
If you like someone else you should have recommended them - that makes
some sense.
> >
> >To suggest Meyers as a beginning text is hallucinatory.
> No one suggested Scott Meyers as a begining text.
> OTOH if you mean Bertrand Meyer then it is goodas a begining text.
> ( Allthough I would not recommend learning a language like Eiffel as
> the first OO language. rather get something commercially viable
> instead.
> > There are no
> >perfect texts and even the ones that I like certainly leave things
> >that might be more desirable but so what?
> >
> But the texts you like teach one bad C++ programming techniques.
> That means most other texts are much more desirable.
Name the "bad" C++ techniques. Are you suggesting that errata
qualifies as bad programming technique? I consider this stuff noise
and if you read my full remarks I allow for the book to be a mild
introduction not the authority. But you have too much of a head of
steam going to accept the book for what it was recommended for.
>
> >
> >>
> >> And this often means he'l sacrifice accuracy for breeziness. But his
> >> ultimate sin is he refused to create an Errata site, or even to fix the
> >> problems in later editions of his books. Things as dreadfully obvious as
> >> 'void main' - things that the C++ community finds itself straightening
> >> newbies out over again and again.
> >
> >Presumably these newbies you refer to aren't the dumb asses you make
> >them out to be.
> Actually many aren't. I notice they avoid Schildt's books.
Maybe they're dumber than I take them to be.
>
> >Any author who can present this information
> >gracefully should be thanked.
> For making bad programmers. Hardly.
And "how" dear snobbish expert do intelligent, critical people become
bad programmers? I suggest to you that many people come into computer
science classes thinking there's a big paycheck there. Most of them
will not learn to be good programmers just because. This profession
requires a critical mind, a LOT of hard work and so on. Not everybody
qualifies.
>
> >No doubt there are errors and if you
> >want to be the errata police then have the time of your life.
> Like consistently, across how many books, not testing for self
> assignment? Those aren't errors. Schildt just doesn't know C++.
>
> >
> >As for the C++ community, they have straightened newbies out enough
> >for newbies to realize the Java community is a much healthier place to
> >operate.
> Not really Schildt writes Java books too.
As you can tell, I buy them too. Let me guess - you think I'm a dumb
ass.
>
> >
> >Schildt's book passes a very basic law - that of sufficiency for what
> >its attempting to accomplish.
> Making money for Schildt. Possibly allthough with the reviews he keeps
> getting how long will that last.
Many of the great books, movies, and other cultural artifacts get
truly shitty reviews - again, so what? Read a little of his work - it
has stunning clarity.
>
> >And, I will add, he has the courage to
> >present the information to be understood.
> Yes. It takes a certain type of courage to write bad books. The same
> kind of courage that CEOs who lie about their profits have. Frankly we
> are better off without that kind of courage.
>
> > There are no other beginner
> >books that I'm aware of that don't fall into the C++/OO obfuscation
> >trap.
> Either you haven't looked very hard. Or you actually believe that
> books like Lipmann or Koenig and Moo.
No, I don't look very hard - you are right.
>
> If it is the later then please don't consult in C++.
Because you say so...
> Sure I can make a
> ton cleaning up messes made by people like you, but I would rather see
> the code done right in the first place.
Thank heavens there are C++ gods among us.
max
> value to students and beginners who could buy much more expensive
> tomes that lose their interest in three pages. The readability of
> Schildt provides a deeper and longer attention span for the subject
> matter which is dense.
It may be easy to use; that is a pro. But C++ is a complicated language and
if it is not taught properly AS A LANGUAGE there will be some (possibly
significant) damage done to the student. Why not pick a beginner book
"approved" by the serious C++ community - one by Bruce Eckel, Deitel &
Deitel or better yet Koenig & Moo - besides learning programming in general
from some of the best teachers they will walk away with a good understanding
of 1st/2d most used prog. language.
>
> I cannot excuse lack of accuracy but if you are so committed to it,
> write Osborne - they do track errata. Instead you piss and moan.
Errata is useless for a bad book writted by someone who is not qualifyed to
talk about the subject. If I wrote a book on Japaneese history (which I know
virtually nothing about) can you fix it with errata?
krasicki
> > One of the reasons I swear by Schildt books is that they are great
> > value to students and beginners who could buy much more expensive
> > tomes that lose their interest in three pages. The readability of
> > Schildt provides a deeper and longer attention span for the subject
> > matter which is dense.
>
> It may be easy to use; that is a pro. But C++ is a complicated language and
> if it is not taught properly AS A LANGUAGE there will be some (possibly
> significant) damage done to the student.
Like intensely bad judgement? You have got to be kidding me because
this thread becomes more preposterous as it develops. I have to
admit, it's an absolute hoot to respond to but what are you critics
thinking?
> Why not pick a beginner book
> "approved" by the serious C++ community - one by Bruce Eckel, Deitel &
> Deitel or better yet Koenig & Moo - besides learning programming in general
> from some of the best teachers they will walk away with a good understanding
> of 1st/2d most used prog. language.
Look, I like Moo & Eckel's work very much. But both are advanced.
Deitel & Deitel is unimpressive, again, IMHO. But the entire concept
of C++ nazis "approving" of what gets taught is simply ludicrous at
face-value and downright terrifying in the extreme.
>
> >
> > I cannot excuse lack of accuracy but if you are so committed to it,
> > write Osborne - they do track errata. Instead you piss and moan.
> Errata is useless for a bad book writted by someone who is not qualifyed to
> talk about the subject. If I wrote a book on Japaneese history (which I know
> virtually nothing about) can you fix it with errata?
These kinds of statements border on a character assasination of
Schildt. I do not know the man but I can tell you that I wade through
an awful lot of technical material and MY REVIEW of this particular
book (C++, From the Ground Up} work ranks him among the very best
introductory and survey authors a beginner can try. Now, you and the
"serious C++ community" may take exception to that but I take none of
you seriously if you dismiss the possibility that this man can get a
good "review" despite your objections.
As for this errata business. If any author does not receive feedback
on his errors, (s)he cannot correct them. If you wrote a book about
Japanese history would you not deserve to know that you had
correctable errors in the text?
So to get on these newsgroups and imply that because some other book
by Schildt got a bad review then this book must also be bad AND
therefore the fellow is unqualified NOR should we correct his
misconceptions....
I mean, really, who the hell do all of you think you are?
Robert Jacobs
Has Schildt used void main for C++ in recent years?
Robert Jacobs
Phlip
> > And this often means he'l sacrifice accuracy for breeziness. But his
> > ultimate sin is he refused to create an Errata site, or even to fix the
> > problems in later editions of his books. Things as dreadfully obvious as
> > 'void main' - things that the C++ community finds itself straightening
> > newbies out over again and again.
>
> Has Schildt used void main for C++ in recent years?
Who cares? I'm hardly a student of Schildtism (and the books around me are
about Squeak and Mathematica and stuff). Like I said, an e-search will
locate excellent gripes about him. Here's one (admittedly from 1995):
----8<----------------------------------------
Laird Allshouse wrote:
>
> Here's a function Schildt uses (page 109) as an example
> of string input in his book "C++ from the Ground Up."
>
> MY QUESTION: Why is char temp [80]; in the function?
>
> void enter()
> {
> int i;
> char temp[80];
>
> for(i=0; i<10; i++) {
> cout << "enter phone number: ";
> gets(name[i]);
> cout << "enter phone number: ";
> gets(phone[i]);
> cout << "enter number of hours worked: ";
> cin >> hours[i];
> cout << "enter wage: ";
> cin >> wage[i];
> }
> }
>
> The arrays are all declared earlier in the
> program.
He must have wanted to keep a spare array around, just in case. Or maybe
he didn't want all that stack space to go to waste, so he figured he'd
use some of it, even though it wasn't needed. He also apparently hasn't
heard of istream::getline, which will do the same thing he's using
gets() for, but more safely. The biggest problem here is that unless
he's synced standard io with the iostreams, there's no guarantee that
the prompts will actually be displayed before the attempted input with
gets(). (getline(), being part of iostreams, does not have this
synchronization problem). All in all, about par for the course for
Schildt. That's why his books are on knowledgable peoples' "not
recommended" lists.
-- Pete
----8<----------------------------------------
'gets()' in an iostream program. Priceless.
--
Herbert Schildt
Robert Jacobs
"Phlip" <phli...@my-deja.com> wrote in message
news:sxe_8.3240$i42.13...@newssvr21.news.prodigy.com...
> "Robert Jacobs" wrote:
>
> > > And this often means he'l sacrifice accuracy for breeziness. But his
> > > ultimate sin is he refused to create an Errata site, or even to fix
> > > the problems in later editions of his books. Things as dreadfully
> > > obvious as 'void main' - things that the C++ community finds
> > > itself straightening newbies out over again and again.
> >
> > Has Schildt used void main for C++ in recent years?
>
> Who cares? I'm hardly a student of Schildtism (and the books around me are
> about Squeak and Mathematica and stuff). Like I said, an e-search will
> locate excellent gripes about him. Here's one (admittedly from 1995):
Well, I'm not here to defend Schildt, but I agree with Krasicki that many of
the people knocking Schildt are lemmings. They knock him based on what
they've read on Usenet or based on the row upon row of bright red Not
Recommended's. But they've never been near a Schildt book in their life.
I first learned C++ from a Schildt book and thought it was very good. Only
later did I find out that he had an awful reputation (I've never come across
an author in any field with a reputation as bad as Schildt's). I checked out
some of the criticism of his work and found that while it was accurate and
deserved, mostly it was years old. The book I had didn't exhibit the same
problems, and that was some time ago. Some time later, when the C++ standard
came out and C++ books were playing catch-up, looking through the offerings
in bookstores at the time I found that Schildt was better than many - better
than several that were recommended on Usenet at the time by those who
knocked Schildt.
Your own post, to which I replied, suggested (to me at least) that Schildt
was still using void main, and I thought he'd dropped that long ago - hence
my question.
Who cares? Well, not me particularly, but Krasicki has a point about
lemmings.
Would I recommend his book? Let's just say, there are plenty of good
alternatives.
Robert Jacobs
Phlip
>
> Well, I'm not here to defend Schildt, but I agree with Krasicki that many
of
> the people knocking Schildt are lemmings. They knock him based on what
> they've read on Usenet or based on the row upon row of bright red Not
> Recommended's. But they've never been near a Schildt book in their life.
> I first learned C++ from a Schildt book and thought it was very good.
The journey towards effective programming requires helpful tutoring over the
basic concepts, and requires a sense of pride in advanced rigor. In tricky
languages like C or C++ this often requires knowing, in every context, the
difference between well-formed and its alternative, and defined behavior and
its alternative.
The backlash to Schildt, among those who did learn from his books (including
me), is disappointment with oneself. As ones pride grows regarding ones
ability to program safely and correctly, ones resentment grows regarding
others who do not or can not seem to share this pride. Especially if they
write books. Especially books one once learned from.
[If the original poster is still - amazingly - tuned in, another book
recommendation is /Pitfalls of Object-Oriented Development/ by Bruce F.
Webster. And, of course, AntiPatterns.]
--
Phlip
Phlip
>
> Well, I'm not here to defend Schildt, but I agree with Krasicki that many
of
> the people knocking Schildt are lemmings. They knock him based on what
> they've read on Usenet or based on the row upon row of bright red Not
> Recommended's. But they've never been near a Schildt book in their life.
> I first learned C++ from a Schildt book and thought it was very good.
The journey towards effective programming requires helpful tutoring over the
krasicki
> "Robert Jacobs" wrote:
> >
> > Well, I'm not here to defend Schildt, but I agree with Krasicki that many
> of
> > the people knocking Schildt are lemmings. They knock him based on what
> > they've read on Usenet or based on the row upon row of bright red Not
> > Recommended's. But they've never been near a Schildt book in their life.
>
> > I first learned C++ from a Schildt book and thought it was very good.
>
> The journey towards effective programming requires helpful tutoring over the
> basic concepts, and requires a sense of pride in advanced rigor.
I have no idea what "pride in an advanced rigor" means. My degree
comes from Art and Education although I've attended countless
ComputerScience courses in addition to teaching Jr. High School Art
and Community College Computer Science topics.
I can tell you this, some people think that teaching is nothing but
repetition - that the student didn't hear you the first time,
therefore saying it over and over will do it. Another theory is to
yell at people because they are hard of hearing and volume makes one
learn.
Your proposal is that some kind of rigor be applied, so that, say in
learning the alphabet one never leaves the letter 'A' until all
nuances of 'A' are clearly articulated. It follows that any teacher
who doesn't apply this rigor is a liar and incompetent.
Listen to yourself - this is patently bullsh@t.
> In tricky
> languages like C or C++ this often requires knowing, in every context, the
> difference between well-formed and its alternative, and defined behavior and
> its alternative.
Or NOT.
>
> The backlash to Schildt, among those who did learn from his books (including
> me), is disappointment with oneself.
Now, we get to the meat of the matter. Looking into the rear-view
mirror one wonders why yhety ever needed a Schildt book - something so
plain and simple. Because NOW we're all geniuses aren't we and feel
shamed that we once weren't.
> As ones pride grows regarding ones
> ability to program safely and correctly, ones resentment grows regarding
> others who do not or can not seem to share this pride.
Pass the bong. Let me get this straight. You are now justifiably
proud of your acheivement and resent those who fell by the wayside -
and there are many. GET OVER IT! Life is long and deep - lots of
people raise families, enjoy sports, sex, life, whatever instead of
strutting their pride in having mastered, say English, C, Cobol,
driving a car, company politics, and so on. Is the picture clearing
up for you.
One of the most amusing things is listening to people who have never
had young children complain about say, the TV show Barney which is
aimed at tw-four year olds. Adults are absolutely indignant! They
already "know that" - geeeez! This is exactly how critics of Schildt
strike me.
> Especially if they
> write books. Especially books one once learned from.
Lose your shame - he's a great beginning author, fleas and all.
>
> [If the original poster is still - amazingly - tuned in, another book
> recommendation is /Pitfalls of Object-Oriented Development/ by Bruce F.
> Webster. And, of course, AntiPatterns.]
Never heard of either but I'll give the first a look. The second is
much to negative a look at life for me. I've increasingly had a more
difficult time with the darkly cynical looks at what we do. As I get
older I see my youth being replayed back at me in the behavior of
younger computer scientists and I don't like what I see.
It is very, very easy to take shots at what looks to be bad code. It
is very hard to do anything that isn't criticized in very short order
but some new regime of technology findings. These days I try to live
by some words of Martin Luther King who said his purpose was to,
"comfort the disturbed and disturb the comfortable." We need all the
help I can get.
The context that systems get developed in is always incomplete and
will always be. To pursue it otherwise is a fool's errand.
Phlip
> I have no idea what "pride in an advanced rigor" means
Very sorry to hear that.
--
Phlip
http://www.greencheese.org/SkeletonCrew
-- Appears that VIM is internationalized...
May I ask what's the point? --
Universe
> On 15 Jul 2002 16:53:09 -0700, kras...@consultant.com (krasicki)
> wrote:
>>Phlip <phli...@yahoo.com> wrote in message news:<l7sY8.563$Xl4.13...@newssvr16.news.prodigy.com>...
>>> >> > schildt group:comp.lang.c++
>>> >> >
>>> >> >Oh, the rockets' red glare - flames bursting in air!
>>>
>>> >> http://www.accu.org/bookreviews/public/reviews/0au/s.htm
>>> >> You'll probably have to search for the name, but once you find it
>>> >> it's very distinct. Row upon row of bright red Not Reccomended s.
>>> >
>>> >
>>> > WRONG! Get yourself some glasses. It is reviewed in 1995. No other
>>> > comment accompanies this fact.
>>> >
>>> > A lot of you critics are just a bunch of lemmings, IMHO. Read the
>>> > book, it's great.
>>>
>>> Ask C++ folks like Pete Becker how great it is.
>>
>>I don't know who Pete Becker is, nor do I care.
>>
> In other words you don't care to know who the person who
> wrote/presided over the writing of code that most of your students
> routinely use, well OK not *your* students. But code that most high
> quality students and serious developers routinely use.
Serious hackers, crackers and other assorted right wing pragmatist
cowboy *coders*.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ newsgroups+bitnet OK