Conference bulova::decw_jan-89_to_nov-90

In my view, DECwindows V1 did not pay any attention at all to the
VAX bindings in terms of usability and correctness.  I did a lot of work
with Ada that had the side effect of improving the definitions for other
languages.  But most of this work was concentrated on the DWT routines.

As more and more attention is directed towards using DECwindows with
languages other than C, the situation will improve.  I don't know if anyone
was looking specifically at the Pascal bindings for V2, but if you
enumerated your complaints in QARs, that's a good way to draw attention
to them.

				Steve

>As more and more attention is directed towards using DECwindows with
>languages other than C, the situation will improve. 

I'm  not as sure about this as you are, Steve.  We are about to punt the
3+ years experience we have with the XUI bindings to do a new set for Motif.
That says things will start to get better (from where they are right now)
about 1992.

Unless we do Motif differently...

**(low)flame on

I'm not trying to pick a fight, but I believe that the "real" problem is
caused (at least in large part) by the resistance of many of our languages to
support the data structures, etc, required to use the "C" bindings.  For
example, ASCIZ strings.

And, to really paint the lily (as they say), we've written "VAX" bindings
to lots of routines just because the XUI routine names didn't contain enough
"$" and "_" characters!!!   Give me a break.

I can understand why we might have to ship data structure definition files
in many languages, but all those special entrypoints?

Can't we reduce the special-case "VAX" bindings to a minimum.  Isn't there
anything that could be done at the language level to make it easier to use
the "standard" bindings?  After all, many users are interested in writing
portable applications, and that means that they are reluctant to use anything
that is VAX-specific.  I know I am (reluctant).

Why is it that this problem only seems to have struck here (at DEC)?  Is there
some anti-C prejudice?  Why can't ADA, for example, with all its "power",
call the XUI entrypoints directly?

Now don't get me wrong - I love BLISS and FORTRAN and all our other languages.
But I won't code in BLISS anymore because it isn't portable (enough).  And
I've grown to love (the portability of) C.

Let's see if we can't do something to limit the proliferation of "bindings"
and build "real" software instead.

**flame off - opposing viewpoints are encouraged

-steve-

Re: .3

It's not true that the other languages can't call the C bindings, but that
in many cases it is very difficult to do so.

I find it darkly amusing that it is suggested other languages add support
for C's mistakes such as ASCIZ strings.   ASCIZ is the least efficient
method of handling strings I am aware of.

As for portability, C is far less portable as a language than Ada or FORTRAN.
The portability you get from C is because it happens to bundle in the Unix
operating system interfaces.

But this is really all beside the point.

I think and continue to think that it was foolish to ignore the widespread
use of languages other than C when designing the API for DECwindows.  And
it is just as foolish to just tell the majority of application programmers
in the world that they'll have to step back twenty years in software
engineering methodology in order to write DECwindows applications.  Ada
and FORTRAN and Pascal and BASIC and COBOL are widely used and their use
will grow in the future.  Let's not stick our heads in the sand about this.

Re: .2

I'm afraid you may be only too right, Jake.  By that point, a lot of people
may decide to abandon their modern languages in order to write Motif
programs in what amounts to little more than "portable assembler".

					Steve

RE -2:  Neat as an all C world might appear it doesn't fit reality.
All the other languages exist not only out of historical perversity,
but because they fill a need.  Try to do scaled decimal in anything
but Cobol.  Try to do RMS indexed io in C.  Sure, it complicates the
the routines to have extra entry points but even with the strong bias
toward C caused by all the errors in the VMS bindings, our support call
volume shows about HALF of the DWT (and XLIB) programming going on in
languages other than C.  That's a lot of customers, $, hardware, etc. 

That the implementation of X is so narrow is a shame, but that we're 
making it available to the rest of the world is not only laudable, but 
necessary.  If you guys and gals weren't doing the extra work to make 
the VMS bindings happen we'd be in serious trouble with the ones who
pay our bills.  Many of our customers are loyal to DEC and their 
favorite language.  It gives us a unique competitive advantage which I 
hope marketing is exploiting (but don' think they are) that you can do 
windows from almost any language under VMS.  Rather than be embarrased 
by it, we should take advantage of the difference.

Bruce, CSC/CS

re: .3

Do you really believe that adding Digital Extensions to ANSI standard languages
to handle C datatypes and mappings will ENHANCE application portability?   You
make it sound like having Digital Compilers solve the problem on VMS will 
solve it everywhere for everyone - I don't see how. 

Do you really believe that such extensions, even if they were embraced by other 
vendors, have any chance of becoming ANSI standard in our lifetimes?  
(Witness COBOL 8x, FORTRAN 8x, etc...).   And I'm just talking about politics.  
Adding C-Style data structures to all our languages would be a substantial 
technical effort too.

Different languages evolved mostly because they make it easier to solve different
sorts of problems.  Trying to make them all the same just so you can call a silly 
API that only understands 'C' is not the solution.  Making the API less 
language sensitive is a much cheaper and more portable solution.  Bindings,
while somewhat 'gross', at least allow us to 'fix' a bad API that is out of our
control.

I don't see how your proposed solution helps either customers or Digital.  
Customers still will have 'VAX' extensions in their code (except now they will be
relying on compiler extensions as opposed to bindings).  Digital will have to
spend lots of money in lots of places to add these extensions (and not do
important work in other areas).

Please enlighten us...

    I've been told by a reliable source that Vince Orgovan has said
    that if we can't do a better job with the Motif VMS bindings, then
    don't do them at all!  
    
    Great!  Who needs 'em!
    
    Just kidding folks.... :-)
    
    A few pieces of good news related to this:
    
    1.  A large majority of the Motif VMS bindings will be the same as the
        XUI bindings.  So, the ones that are correct today, should be
        correct in Motif (if we can copy code and chew gum at the same
        time...).
    
    2.  We plan on building tests which call each entry point at least
        once (radical idea, isn't it...).
    
    3.  We're not bound by "strict" upward compatibility in going from
    	XUI -> Motif, so if we did some of the XUI bindings wrong,
     	we have a chance to fix them.  Anything you find in XUI that
    	you think is wrong, please QAR it!
    
    Leo
       

  I work with a DOD customer (USAF) that is using DECwindows and PHIGS for
graphical displays of data.  Since it is a military customer they (USAF) are
mandated to use only the Ada language.

  When we first started using DECwindows a year ago we went through a lot of
pain in the learning curve, mainly for the lack of support of the $ bindings.
But as with anything, if you toy with it long enough things begin to click.

  Now I don't want to sound as if I am promoting the use of C (I'm still just
learning it and I *do* like it) but I found that after I took a college class
for C, that I have a better understanding of how the X, XT, and DWT calls
work and have been able to use DECwindows thru Ada with a much better
understanding.  In fact, with Ada I've used both the MIT C and $ bindings with
little or no problems.

  I guess what I'm really trying to say here is that with the knowledge and
understanding of C and its idiosyncrasies that there should not be any problem
with using DECwindows from your language of choice.

					-=> Jim <=-

    Re .3
>Why is it that this problem only seems to have struck here (at DEC)?  Is there
>some anti-C prejudice?  Why can't ADA, for example, with all its "power",
>call the XUI entrypoints directly?
    
    Why is it that C, for example, with all its "power", can't build string
    descriptors?  the answer, of course, is that it can, but it's not the
    way C normally works.  However, most other languages do use descriptors
    for strings, so it would seem to make sense for the toolkit to provide
    descriptor-style entry points as the default, and perhaps a set of
    special C-bindings for those C programmers who find it tiresome to have
    to build descriptors for their entry calls.
    
    Languages other than C have their strengths.  For example, if the
    toolkit were written differently, multi-tasking languages would be the
    natural choice for writing graphical UI applications.  Imagine how much
    easier it would be to implement a complex UI with one task handling
    each logically parallel part of the application (eg a task for each
    active menu, a task for each major screen area, and other tasks to do
    the actual work), rather than the current situation which requires the
    application- writer to specifically design his application around the
    UI and use work-procedures to simulate the required parallelism,
    instead of being able to truly separate form from function.

Hey, that sure got your goats, didn't it.  :}

Seriously though, you (all) make some good arguments.  Looks like I'll have
to think about it some more.

-steve-

    Hum, another religious one.
    
    C *is* the standard, nowadays. That means C with all its manierisms.
    Yes, by default it uses ASCIIZ for strings, and so does Unix - why
    should the standard language have to adapt to the others by using a
    default access mechanism( by descriptor) that is not the default choice
    of that language???
    
    Anyhow, this is probably a mute point. Evrybody has his favorite
    language. Make one the standard (C in our case) and almost all will
    agree that it stinks. But choose another, and again almost all (though
    not quite the same) will agree that it also is dismal in its treatment
    of this or that....
    
    So I guess we just get to grumble and live with it...
    
    JP

I believe that even IEEE POSIX (the Unix stndard) has specified that no future
IEEE standards will be done with a C binding, but that the specification 
will be language independent.

jake

    The problem of language-neutrality goes deeper than just a binding,
    unfortunately.  The issue of work-procedures vs. language-provided
    multi-tasking is one example of this.  Error-handling is another.  To
    provide genuine language-neutrality, you really need to think about it
    from day 1.  Tacking on alternative bindings only addresses the
    cosmetic aspects of the problem.
    
    John

>    The problem of language-neutrality goes deeper than just a binding,
>    unfortunately.  The issue of work-procedures vs. language-provided
>    multi-tasking is one example of this.  Error-handling is another. 
 
I'm afraid "standards" such as Xlib , X Toolkit Intrinsics, and Motif
are driven to "lowest common denominator" solutions for error-handling,
multi-tasking. etc... because they are designed for OS and architecture
"neutrality".  We have to continually act as "watch-dogs" to keep the
standards "OS-neutral", 'cause if we don't, they will become OS-specific
and the OS I mean isn't VMS...

So, while if we were designing an RTL for VMS only, we would naturally use
VMS error handling etc..., "life" is not so easy in the new world of
"standards".

Leo

>I'm afraid "standards" such as Xlib , X Toolkit Intrinsics, and Motif
>are driven to "lowest common denominator" solutions for error-handling,
>multi-tasking. etc... because they are designed for OS and architecture
>"neutrality".  We have to continually act as "watch-dogs" to keep the
>standards "OS-neutral", 'cause if we don't, they will become OS-specific
>and the OS I mean isn't VMS...
    
    I understand the principle expounded here, but the same argument could
    be used to explain the impossibility of implementing (for example) Ada
    under U*x (which is clearly possible, and requires both multi-tasking
    and stack-frame based exception handling).  Lowest common denominator
    thinking isn't the only way to achieve portability.
    
    Just because the OS doesn't provide a feature shouldn't prevent the
    toolkit from providing it, nor need it prevent the toolkit from providing
    the necessary hooks to connect to language-provided support for those
    features.
    
    Take error-handling as an example.  The ideal form of error-handling
    for XUI would probably be per-widget handlers (_not_ VMS-style stack-
    based exception handlers, unless the calling heirachy of the toolkit
    and application were drastically changed).  When an error is raised, the
    toolkit could find the widget responsible and invoke a handler for that
    particular widget instance, if one had been specified.  If a handler
    didn't dispatch the error, the handler of the widget's parent would be
    invoked, and so on until the error was handled, or reached the shell,
    at which point the global handler would still be called.  This would
    require no OS support, and wouldn't have to cost much in performance
    terms until an error condition were raised.
    
    Multi-tasking could be handled by making the toolkit fully re-entrant.
    If designed with tasking in mind, the toolkit could then support
    multiple simultaneous calls from those languages that provide
    multi-tasking, multiple call-stack environment, whereas languages
    without that functionality would have to continue to use the
    work-procedure mechanism.
    
    I would consider it to be far better to provide a language-neutral
    toolkit (one that didn't impose one particular programming style on the
    application-developer), and a set of good language-specific bindings,
    as opposed to a toolkit designed around a single language (which
    therefore has to be a lowest common denominator language) and a set of
    "cosmetic" bindings for other languages.

>>> C *is* the standard

    Wo.

>>> Evrybody has his favorite
>>> language. Make one the standard (C in our case) and almost all will
>>> agree that it stinks. But choose another, and again almost all (though
>>> not quite the same) will agree that it also is dismal in its treatment
>>> of this or that....

    Hey, wait a minute. Wasn't this problem adressed a few generations ago 
    when someone invented the

	* VAX PROCEDURE CALLING AND CONDITION HANDLING STANDARD *

    which united all the languages in the universe that ran under VAX/VMS.
    All external applications interfaces made were supposed to conform,
    *just* *so* this kind of bickering and blistering didn't happen. 
    And the result was very, very good - everything worked in any language.

    Now, throw in some new hardware, and everyone is reverting back to some
    sort of tribal warfare, where it's every language's lobby for itself. 
    
    This is regression. If someone years ago had said "If they want to use
    system service calls, let them write in MACRO", *someone* would have
    corrected that person, explaining the major errors of his thinking. 
    The programming world cannot get by with one language.

    Doesn't the same logic apply? What we now need is a calling standard
    that works on all languages *and* all machines. Maybe not the same one
    as the VAX PROCEDURE CALLING AND CONDITION HANDLING STANDARD, but one
    nonetheless. 

>>> So I guess we just get to grumble and live with it...

    Spoken like a true C fan.

    I believe it is just this kind of engineering apathy that is making C a
    "standard" on non-Unix systems. It certainly isn't because C is
    convenient, powerful, or versatile. Everytime someone gives in and 
    goes with C, C becomes harder to escape from from the next guy.

    It might just be a black hole.

    Kevin

>    Spoken like a true C fan.
    
    Whooooo, wait a minute. I'm no C fan. I think C is a stupid language
    that makes me do all the work that any normal, typed structured
    language does for you. All you ever get in C is "access vio", when a
    normal language could have told you that you exceed an array bound, or
    something more useful.
    
    but a language is a language is a language. Who ever said there was
    ever any relationship between what becomes a standard and what is the
    best tool.........
    
    JP

    not that this has anything more to do with the topic than the last
    42 notes, but, i read somewhere that someone (perhaps mit? (whatever
    mit might mean in this context)) had developed bindings for at least
    xlib in at least lisp and ada.  is that true?  if so, are they
    available?  are they lisp-ish and ada-ish, or c-ish?  if they don't
    exist, are there plans to do this?
    
    as much as i hate to criticise the vax bindings (because i'm sure it
    was hard work creating them, and without them we'd be shutting out a
    lot of programmers from using x) they are the ultimate lowest common
    denominator, and they are not likely to be appreciated by programmers
    on non-dec machines.  i think what's needed are bindings tailored to
    each language, calling the c routines directly where possible, with
    jackets (or maybe full-length coats) where necessary. 

    i'm quite sure that x developers have a great deal to do, but perhaps
    in a spare moment (you weren't going to take _all_ christmas day
    off were you?) at least a specification for a standard {ada, pascal,
    forth (just wanted to see if you were paying attention)...} binding
    could be designed and widely posted, so that others could write
    them.  by specification i mean names of routines, parameters (and
    parameter positions), constants etc.  unfortunately, i realise that
    writing such a spec is not far from writing the actual bindings.
    
    		in for a penny, in for a pound  -- dd
    
    ps. i'd love to write an ada binding, if i thought that anyone but
    me would use it, and if i knew that there weren't 796 other people
    writing their own, which would be incompatible with mine.

    pps. don't write a bunch of flames about how certain languages can't
    do certain things (like ada can't pass procedures and functions
    like modula-2 and c (except in the hacky 'address way)).  the challenge
    of writing these bindings would be to overcome exactly these problems.

    and last but not least, just when you think c is _the_ "standard";
    being an instructor, i come in contact with lots of customer
    application developers and while c would, in fact, come out first in
    "choice of language to write x applications" it only barely
    beats...fortran!