Re: IBM Acquires Rational Ada

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

Marin David Condic wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
> news:3DF8D33F.9020205@cogeco.ca...
...
>>For example, you could get near standard conformance on text screens.
>>Yet, there does not exist any _standard_ curses package. There are
>>some public versions of bindings, but none of them are
>>complete or "standard". So even text based applications are
>>barely accomplished in a portable fashion.  In this sense IMHO,
>>Ada is still better suited to embedded applications, rather than
>>the general purpose use that other languages are used for.
> 
> To start with, I don't think that trying to add some sort of support for
> character cell terminals is going to impress anybody much. ("Wow! I'm
> impressed! You guys put into the language something that C has had for 20+
> years and got there just in time for the character cell terminal to go the
> way of the punchcard. What's next? A paper tape I/O package???")

I am very aware that text "fails to impress" people these days, but when
you own the company, you don't necessarily care that those under you
are stuck using cheap dumb terminals (especially if clients never get
tours for impressions). There are still a large number of warehouse
(and similar) situations, where they are quite content to use dumb
terminals. They're cheap, never need software upgrades, don't get
viruses, can't pass viruses onto the LAN etc. They also don't need
Microsoft licenses/extortion to keep them going.

Furthermore, text mode apps are very cheap and easy to maintain
compared to the GUI counter-parts.  I'll grant that good IDEs make
GUI maintenance easier. But overall, my experience is that they
take much longer to produce and cost more in time to maintain.

I still see dumb terminals in use at stores, particularly
video rental stores etc. Banks are still very text based.

So while it is not impressive technology, don't write it off.  It is
also very good console technology, when you cannot get your X server
running on Linux/*BSD/UNIX.

One last thing to consider is that data entry is far more efficient
on a properly designed text mode interface than a GUI screen. Any
time the operator has to take the hand(s) off the keyboard to work
a mouse, is an instant degradation in productivity.  I've seen
operators bang away at the keyboard on a text mode app
and never look at the screen until they reach
the point of Save/Update. You don't get that
experience with any of the GUI apps I've seen.

So yes, I see value in a "standard" or "defacto standard" text
mode interface.

> Also, if I were doing it, I wouldn't make bindings. 

That is my preference also ;-)

> I think that just ends u
> p in the "Me Too!!!" category and makes your stuff dependent on what happens
> in another language - also requiring you to haul around another compiler. If
> you wanted a curses package, it would be better (and not that big a deal) to
> implement it from the ground up in Ada and give it an Ada flavor while
> you're at it. You could probably even dramatically improve it beyond just
> cursor positioning and the like - give it more of a GUI feel (DEC had
> something like this - pasteboards, windows, etc, all out of VT220's.)

But who is going to do it? A binding is less work was my point.

I'd also love to see the entier X11/MOTIF framework rewritten in an
object oriented language (Ada naturally), but until someone takes on
this mamoth task, we'll both be sitting here wishing ;-)

> That said, it probably wouldn't hurt to throw in some version of a curses
> package if there was some reasonable perception out there that it would be
> mildly useful. (I just wouldn't advertize it as The Major Ada Productivity
> Improvement.)

No, text mode is frowned on by most people. However, if you have just
accounting, warehouse or even some scientific data to maintain, a text
mode system is probably more productive and your IT department can
respond to changes more quickly.

No, it certainly wouldn't be an "Ada selling point" -- but at least one
practical library tool.

> Suppose we had a package called "CAL" ("Conventional Ada Library") and under
> it we had, at minimum, a branch called "CAL.Containers". There's no reason
> someone couldn't propose a "CAL.Curses" and if whoever the controlling body
> of the library was agreed that it was at least moderately useful and not too
> difficult to make work on most platforms, I don't see why it should be kept
> out of the library. The notion being that this "CAL" library would be some
> semi-formal (Suit&Tie - No Tux Required :-) reference implementation that
> could maybe be released every 6 months or so and thus react quickly to what
> the perceived needs are of the Ada community and beyond. It would be a LOT
> more useful than waiting for some limited language extensions to come around
> every ten to fifteen years via the ARM.

Agreed. Standards move very slowly, and sometimes "works of art" can
become standards (much like the C++ STL did).

>>And if they actually did that (shift emphasis), there would be
>>less that would need to craft so much from scratch (like a
>>standard and complete curses binding).
> 
> That is exactly my claim. If you provide a million lines of code to the
> developer and he finds 100,000 lines of that is useful in getting his app
> out the door, he's got a reason to go use Ada. People often use languages
> they don't like because of all the leverage that goes with it. I've worked
> with guys who have been programming things in C for forever and they are
> fully aware of its weaknesses and wish they were using something else, but
> they've got some embedded RTOS or graphics library or something else that
> would be too costly to redevelop in another language, so they keep using C.
> Give them an Ada substitute and maybe they can see their way to switching
> languages.
> 
> MDC

I am not disagreeing with you here. But some were saying that many
can't get past the hassle of the "compile". To me, the "hassle" is
a well appreciated "feature" because it saves me a great deal of time,
not having to chase down what would be stupid errors.

One thing that does bug me though is this limitation that you cannot
take a procedure'Access within a generic body. This makes for extremely
clumsy work-arounds when you want to register callbacks!  But this issue
should be the subject of another thread ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg