Re: Ideas for Ada 200X (Ada.Sockets, enlightened)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Tarjei T. Jensen wrote:
> Warren W. Gay wrote:
> 
>>But going from being a "Good Thing" to "the only thing we need" is
>>an entirely different matter.  If you only plan for TCP in your
>>socket support, you will have an "unwashed mess of package(s)"
>>which will be ugly or difficult to extend for other important
>>network functionality. Some of which, may not be well understood or
>>anticipated at this time.
> 
> I don't want to extend it. 

But this is the problem isn't it?  Your needs may be simple, but
others needs are definitely not.

 > I or sombody else may want to make its interface
> a subset of a more complete socket library. Or possibly make the simple
> socket library an interface to a more complete library.

It is easier to provide a "simpler interface" from a more complete
(and thus more complicated interface). I sense that you've not been
using Ada very long. Ada has very strict rules, including package
visibility rules. If you get your package hierarchy wrong, you'll
paint yourself into a corner. You'll see ;-)

>>BTW, you _will_ want Naming services support. Without them, you'll
>>not connect to anything, except explicity by IP number. ;-)
> 
> There is no problem using DNS under the hood in such a library, but there is
> no need to give the job of handling DNS resolution to the user.(S)he don't
> want to know.

They might not "want to know", but there often is no choice in that.
Yes, for TCP/IP, you can make assumptions about what a string represents
and do the necessary lookups on their behalf (IIRC, Java does this). But 
there are a number of situations where things are much more complicated 
than that.

Here's one: You want to connect to a web server, but you're not
getting any response (the web server is down). Yet, if you were to
use the name server in a more advanced way, you could find out that 
there are alternative web servers (all having the same name, but 
possessing different IP numbers).

Doing a lookup today on www.yahoo.com, I saw 9(!) different IP#'s that
can be used to reach a web server. An application exploiting that 
information could bypass the one server that is down, but trying one of 
the other 8. Your "simplified" application would have to report a 
failure to connect.

So your needs might be simple, but simplified libraries don't help 
everyone else that are solving more difficult problems.

>>Ada streams and endian issues are also important. Write a program
>>that uses a socket between two endian different machines and the
>>endian issue becomes painfully important.  This also shows up
>>in the strangest places. My APQ PostgreSQL package lets you use
>>Ada streams to write blobs to the database. Well, guess what. If
>>you have machines of a different endian persuation trying to read
>>back those blobs written by a different endian persuation (with
>>Ada streams), then "they ain't right". Right now, I live with that
>>limitation because there is no elegant way to fix this.
> 
> You will create confusion by adding things the user does not need.

But there are _many_ users, with _many_ different needs. What you want
is something real simple. This serves only a small portion of the
overall community.

Part of the challenge for standards and library writers is striking
a comfortable balance between simplicity (elegance) and general
utility (functionality). And it does require careful planning and
compromise. But beware: if you compromise too much towards a simple
library, you will only be able to address simple needs. Additionally,
in Ada, this can be difficult to extend later (more on that later).

> A simple
> library is most likely to be used to echanging textual messages. Once the
> user starts doing binary stuff (s)he will know more or simply work around
> the problem.

This is the kind of problem that people want to solve. They don't want 
to have to write Ada bindings to "work around the problem". The problem 
is that the library doesn't exist in standard form. You may only want to 
exchange text, but many here need to much more than that.

With no attempt to offend here, but if you want a simple environment to 
learn in, then there are other environments like BASIC. For networking, 
Java has a simple network model, but for more difficult problem spaces, 
it too has "problems".

> By starting to add features you shoot down in glorious techicolour flames
> the concept of a simple library that does one thing well.

There are many computing problems that are anything but simple. 
Networking, is one of them. Yes, you can do simple networking, but 
simple networking only solves simple network problems. If your
problems are always simple, then good for you.

I am not interested in "adding features". I am interested however, in a 
complete solution. Microsoft sells features (flying folders and animated 
paperclips etc.). We in comp.lang.ada are interested in serious 
solutions to programming problems. Some programming problems are very 
serious, and have a bearing on the safety of human lives.

You're obviously fond of the simplicity argument so let's review 
Einstein's statement that "things should be simple, but not simpler":

You've focused on the phrase "things should be simple". But Einstein was 
very careful to add "but not simpler". This means that if the solution 
is too simple, then it does not solve the problem (in the case of 
physics, this means that the theory does not map to reality). A simple 
but _complete_ solution is elegant. A simple but incomplete solution is 
not only ugly, but is by definition "incomplete".

The "earth is in the center of the universe" theory was very attractive 
  because of its simplicity. Yet today, you don't think that way, 
because you have been trained to know that the universe is more 
complicated than that. To go back to that kind of thinking with what you 
know, would be regressive.

Let's not regress in what we've learned about networking to date.

 > You obliterate the
> ability for an ordinary user to understand and use the library. You drown
> userful information in useless gobbledegoook.

"Gobbledegook" may be the way you see it now. After your apprenticeship
is over, you will see it in a different light. I had very little respect 
for Calculus before I learned how to handle differentials and perform 
integrations. Before I was trained in these things, calculus looked like 
a bunch of "Greek stuff". After I learned what it was about, it became a 
powerful tool in my hands. You too can eventually reach
"enlightenment". ;-)

> The road to hell is paved with good intentions and creeping featurism.
> Resist!!!!
> 
> Keep it simple!

Your "good intentions" or mine? You have good intentions, but they will
paint you into a corner if you focus on simplicity only. The solution 
must also be complete, or at least allow it to be complete someday. With
the strict Ada visibility rules of child packages, and the danger of 
circular package references (which won't compile), you really do have to 
"plan ahead". Anyone that has written Ada libraries as a set of packages 
learns this lesson (sometimes we continue to re-learn it ;-)

If you only plan for the simple, you'll be stuck there. The only way out 
will be to tick people off by making wholesale package changes later. 
NOBODY wants those kinds of changes. What we decide today, we will be 
stuck with for another 10 years. Probably very much longer than that.

I hope that helps to enlighten. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg