"Geir Harris Hedemark" wrote in message
...
"Ted Byers" writes:
interruptions are not tolerable (at least in most situations I have
seen)
and no-one interrupts because everyone there knows that any interruption
in
many procedures will result in the entire effort being scrapped and
started
over.

You must be fond of souffles.

Can't say that I've tried them. But there are a geat many things, both in
the kitchen and in the wetlab, where an interruption can cause trouble. In
the kitchen, one of the common consequences of interruptions is that the
item burned.

they are of no help with things like Grandma's favourite butter tart
recipe,
or with my efforts to modify it so that the revised version doesn't put
my
blood sugar ten times higher than it is supposed to be. And on
checking, I

I guess you have a problem with the apples themselves, then.

Actually, I have to watch almost all fruits because of their sugar content,
as well as starchy foods (almost all root crops) because of their starch.
Beets are so high in sugar and starch that I can almost never have them, and
I love them. Nothing is trictly forbidden, but quantities haveto be vry
carefully controlled.

diet). She would complain that she didn't know what or how to cook for
him
because it seemed that no matter what she prepared, someone told her
that he
couldn't eat it because it was bad for him. It seemed to me that if she
had
had a product like this, and obtained instructions from her physician
regarding what the minimum and maximum daily intake for each nutrient
should
be given Dad's health, she could rather easily find recipes and
construct
meal plans that would have met Dad's dietary needs. But in adition to
those

You are now assuming that we know the full and final truth about
nutritional needs.

No I don't.

I assume only that the measurements that have been taken of nutrient content
for a given food are reasonably accurate. It is to be expected that there
will be some error in them, though. So we're talking about estimates; not
claims that a given number represents "the TRUTH" with respect to the
nutrient content in a given food.

If you look ten years back in time, it is easy to see how things have
progressed. I can't see any reason why todays answers aren't wrong
tomorrow.

When it gets right down to it, todays answers are wrong today! The
existence of error in empirical data is inevitable. But that doesn't mean
we don't try to do the best we can with the data presently available.

This is why I think most people should eat a varied diet. People who
tell you to eat something or other usually have a book to sell.

You are quite right. A varied diet is indispensible.

This isn't an effort to tell anyone what to eat or not eat.

Rather, it is only to provide the best available information about the
nutrient content of given foods.

It is up to the individual to get advice from his primary health care
provider as to what the daily recommended intake ought to be for each
nutrient; and I have no doubt that that advice will change through time, but
that does not affect how my product would, or could, be used. In fact, I am
planning a custom version for the health care industry in which the user can
maintain a log of what is eaten, what medication is taken, what kinds of
health issues have arisen and when and for how long, &c., so that primary
health care providers can have sufficient data to examine how a given
patient responds to given foods and medications and combinations thereof.

Isn't everyone's? Almost all of the development I have done in recent
years
has been in C++ and very object oriented. I do do some structured and

C++ went out of style around here in the early 1990s. Come to think of
it, it never really took off. Awful language, by the way. It feels
like C with a huge great big roof rack on top where are the objects
are kept, making the whole thing waddle through corners.

That is debatable. I don't mind C either. Like all languages, there are
nasty synactic corners, but overall, it is the most useful language I have
studied, with Perl being a close second.

Java, I find the object model in VB seriously broken and the Java
runtime a
major performance problem (but Java is a very interesting language - it
just
doesn't have much utility in the kinds of programming I do).

Performance problem? Strange. I can't see more than a 10 or 20%
degradation over using vanilla C. CPUs are inexpensive. Out-of-control
pointer bugs are not.

That depends very much on what you're doing. The bulk of my work has
involved intensive number crunching and simulation modelling. Between the
overhead of the runtime and the programming idioms supported, I have
personally observed improvement in performance, WRT a JAVA version of a
product, of a factor of well over 100: simulations that took several hours
in the Java version ran to completion in seconds when I reimplemented the
program in C++. One of the big factors proved to be supported idioms;
idioms that could be used trivially easily that would have been quite
painful to adapt to Java. Yes, I know both Java and C++ are Turing
complete, so anything that can be done in one can be done in the other in
theory, but that sidesteps the important issue practicability.

If I were developing a distributed database application, the runtime
overhead would probably not be an issue for a network or website that
doesn't see enormous amounts of traffic.

If a given application has out of control pointer bugs, that speaks directly
to the competence of the team that developed it; not the utility of being
able to use pointers.

I wouldn't use Java for low-level OS stuff. For a recipe database, I
think it is a good match. That may be because I use Java every day.

That is quite possible.

Please note I am NOT saying that Java is a bad language; only that it isn't
appropriate for most of the development I do.

As a point of fact, I am looking at a new database development that will
likely use Java applets for client side processing and PHP+SQL for server
side processing, along with some server side development using either C++ or
fortran (for the number crunching requirements). This project is, in fact,
a database that will include a substantial amount of orchid data (along with
comparable data for all other plants as well as animals).

Are you familiar with SQL? If so, how would an XML database provide an
advantage over combining SQL with C++ and perhaps COM/DCOM? I can see
how

The query bits of SQL is a relational query language. If something
can't be expressed in terms of static relations, you are out of luck.

The inverse problem also applies - XML is, IMNSHO, truly awful at
efficient static relations.

OK, so a little multiparadigm analysis will show that for one part of a
given development, one would use SQL and XML for a different part of it;
given their current strengths and weaknesses. I have no qualms about mixed
language development.

one can relatively easily find all objects satisfying your search
criterion
using SQL and C++ and a suitable class inheritance tree (and one of the
things making it easy is the availability of the STL in C++ and the
power of
SQL).

How do you propose to do this while at the same time allowing the
user to define his own relations? You place some constraints on the
top-level nodes ("I want a keywords node around here somewhere if it
exists") the rest is left as a user-defined application space.

This really isn't an onerous problem. It just takes careful design;
something I have plenty of experience with. Some of my more successful
applications not oly supported but required theuser to establish
relationships for themselves. A careful analysis of what is required (along
with the features of, and idioms supported by, C++ ;-) would show how
simple this really is. In this case, the static relations would be
maintained using SQL, and the dynamic ones by C++. I haven't done the
analysis required to know if what is to be done here using C++ could in
principle be supported by SQL with a suitable abstraction.

I sincerely hope you are not telling me you want to create tables for
every node the user may want to dream up on the fly. That
would be maintenance hell.

Nope! Not a chance! But tables are not the only tool in the toolbox.

Many people split things. The topmost information is kept in
relational tables, the rest is put into blobs or object databases as
XML or something else that may be adapted by the user.

The very act that some relational information might be stored in blobs or
object databases suggests a possible approach to using a mixture of C++ and
SQL to obtain the functionality you require.

These issues are faced in the interaction between orchid growers and
taxonomists all the time when the latter decide to cause us trouble by
changing how species are classified. Relationships are changed, and so hard
coding such information is problematic. I have an advantage in this because
of the importance of numerical taxonomy in my background. But there are
ways around dynamic relationships, even if one is using the mix of languages
I intend to use in my next database project.

Cheers,

Ted