Re: Char type verification

["KE" <koray.erkan@yahoo.com>]

Thanks everyone.

Just to settle this once and for all, let me clarify what was on my
mind.

--

For those who are still curious about this thread (and I believe they
shouldn't be since there's not much to see here folks, move on), let me
explain what I did. (Had some of you not read too much into my post, it
would have been obvious from the start, but "obvious" is Latin for
"overlooked.")

I just threw a quick and dirty example involving a very simple
operation (verifying a property, a letter's case) combined with some
not-so-transparent calculation (using modulo to locate an index)
combined with a common technique known for its usefulness (table
lookup).

It shouldn't have mattered as I was neither after a language war nor
intended to insult my fellow programmers with any arrogant and blind
belief in this or that language.

Nor was I trying to learn any specific "features." Rather, I was (and
am) trying to learn the LANGUAGE.

Here's an analogy to clarify that last point.

Suppose you want to learn a foreign language, say Dutch. Now the worst
way to start would be to pick up a grammar book. To be sure, the
grammar book can - and will - be useful all along, but only as a
*reference.* An equally naive method would be to pick up a
comprehensive dictionary and start from letter A. Again, the dictionary
will be your friend all along, but there's not much there other than
just columns of words.

The sensible first step is to buy a "teach yourself" book or to get
enrolled in a course.

So far so good. But still, textbooks will also get you only so far and
no further.

Sooner or later, you'll reach that stage which most language learners
dread: you'll have to pick up material actually written in that
language - newspapers, magazines, books, etc. - and start reading them.
Even worse, you'll be asked to speak and write, preferably with/to
someone whose native tongue is Dutch.

I wanted to see how Ada programmers with experience would approach a
simple, quick-and-dirty problem. It shouldn't be too difficult to
imagine that even for seemingly simple problems there are at least two
- and frequently more - solutions.

Another analogy: In a plastic arts academy, for instance, they throw
simple challenges at students to force them to think, to be inventive,
to look at objects differently. Even with your run-o-the-mill "nude"
model, there are umpteen ways of dealing with the figure.

I wanted to see how many different ideas you would suggest, how many
"aspects" of the problem you'd layer out and try to generalize, how
many "idiomatic" ways of coding would emerge.

Should I have challenged you to write the some avionics modules of the
new F-22 fighter? I don't even know a thing about avionics, other than
that it's a neologism. (I mean the word.) As Chancey Gardener from
'Being There' would say for "making a claim" (after being asked
repeatedly if he'll "make" one), "I don't even know what they [those
"avionic" thingies] look like." Between you and me, I only know... ehm,
"catatonics."

The challenge was purposefully simple and messy so that you didn't get
bogged down with the theoretical intricacies of a major one.

I guess this is not the way people use comp.lang.ada. Which is why I
dropped a resentful - and regrettably not too gallant - closing note.

--

This should settle this as I did not intend the thread to be much ado
about nothing.

Thanks for reading.



Good luck
-- KE

P.S. Jeff, I'd rather you not share your wisdom on my final words.
You're obviously too smart or experienced for me to handle. If this
thread looked like a total waste of your time from the beginning, then
why drop 4-5 long posts on how silly it is?