PL/SQL -> Ada

PL/SQL -> Ada

[Foo Bar]

I've been dropping in and out of c.l.a for a couple of years now and
something has always bothered me. With all the discussion of getting
programmers to use Ada instead of <fill in the blank>, I never see any
discussion of "recruiting" Oracle PL/SQL programmers.

Oracle will freely admit that PL/SQL is "based on" Ada and a perusal of
the reserved words list shows a lot more of Ada (probably Ada83) than
Oracle has ever chosen to make an official part of PL/SQL. "with" for
example.

Given the oodles of PL/SQL programmers out there who are already
familiar with many of the basic concepts of Ada (count me as one of
them), why no documentation or tutorials or roadmaps aimed at helping
the PL/SQL programmer "graduate" to Ada? Heck, it'd be nice to see a
paper or two on taking your PL/SQL programs and running them outside of
Oracle via Ada, perhaps working against another brand of database (DB2,
Sybase etc.). And seeing that the Postgres folks have their own
PL/Postgres which is obviously a sort-of clone of PL/SQL and gaining in
popularity, the base is expanding further.

Seems to me to be a natural. So how come I've never seen anything about
it?

Re: PL/SQL -> Ada

[Foo Bar]

Foo Bar wrote:
>
Rats, I forgot to reset my "identity" before posting. Blame me for the
diatribe :-)

-- 
Bill Meahan WA8TZG    wmeahan@wa8tzg.org
Cro-magnon woodworker. Unix Bigot. Perl fan. Oracle weenie.
Managing software development is like herding cats.

Re: PL/SQL -> Ada

[Marin D. Condic]

Foo Bar wrote:
> Given the oodles of PL/SQL programmers out there who are already
> familiar with many of the basic concepts of Ada (count me as one of
> them), why no documentation or tutorials or roadmaps aimed at helping
> the PL/SQL programmer "graduate" to Ada? Heck, it'd be nice to see a
> paper or two on taking your PL/SQL programs and running them outside of
> Oracle via Ada, perhaps working against another brand of database (DB2,
> Sybase etc.). And seeing that the Postgres folks have their own
> PL/Postgres which is obviously a sort-of clone of PL/SQL and gaining in
> popularity, the base is expanding further.
> 
At one time in the not too distant past, I spent a great deal of time
programming in Ada, connecting to SQL for access to the Rdb database.
DEC had an SQL pre-processor for Ada that made this pretty painless. (As
you know, this is now owned by Oracle and is being migrated - if not
already - to match the Oracle product.) Ada always mixed well with SQL
IMHO mostly because it has such rich data representation capabilities.
Naturally, I like the programming structures of Ada and accessing a
database from it is an added bonus.

I suppose that the reason such tutorials/papers are not available is
because it takes someone with A) experience in both languages, b) time
and skills to write such material, c) a desire to advocate Ada to "the
masses" and d) contacts within the PL/SQL community to spread the word.
Kind of makes it hard to find someone to sign up for the job, eh? :-) 

I would imagine that if you were to write a sort of
"Pascal-Subset-Intro-To-Ada-For-PL/SQL-Programmers" paper, we could find
an appropriate website to put it on. Adapower comes to mind for that
task. Then you'd need to talk it up to the PL/SQL newsgroups. I'm also
sure that you could find help here in the way of answering specific
questions, ("I can do this in PL/SQL - How does it work in Ada?") and
probably find a few distinguished reviewers who would look it over and
make suggestions. If you think it is important, maybe you are the best
qualified to do the job.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Andreas Schulz]

"Marin D. Condic" wrote:
> At one time in the not too distant past, I spent a great deal of time
> programming in Ada, connecting to SQL for access to the Rdb database.
> DEC had an SQL pre-processor for Ada that made this pretty painless. (As
> you know, this is now owned by Oracle and is being migrated - if not
> already - to match the Oracle product.) 

Emmm - what decade (or product?) are you talking about ? 
The Oracle Pro*Ada precompiler has been in use for years, 
until they decided to abondon it with Oracle 8, concentrating
on Pro*C and Pro*COBOL (IMHO) due to lack of request.

Andreas

Re: PL/SQL -> Ada

[Tony Matthews]

Andreas Schulz <accot.schulz@nord-com.net> wrote in message
news:38DE8D9B.83F8D13B@nord-com.net...

> "Marin D. Condic" wrote:
> > At one time in the not too distant past, I spent a great deal of time
> > programming in Ada, connecting to SQL for access to the Rdb database.
> > DEC had an SQL pre-processor for Ada that made this pretty painless. (As
> > you know, this is now owned by Oracle and is being migrated - if not
> > already - to match the Oracle product.)
>
> Emmm - what decade (or product?) are you talking about ?
> The Oracle Pro*Ada precompiler has been in use for years,
> until they decided to abondon it with Oracle 8, concentrating
> on Pro*C and Pro*COBOL (IMHO) due to lack of request.
>
> Andreas

Oracle haven't completely abandoned Ada. It's true that all ProAda
precompiler development has been stopped for some time now, but they have
replaced ProAda with SqlModule Ada. I'm not sure how many different
platforms are supported, but Windows NT and SCO UnixWare are certainly
amongst them.

It is a completely different beast to ProAda, though, in the way that it is
used. As far as I can determine, you write PL/SQL subprograms/packages to do
the jobs you want done and pass them through SqlModule, which spits out Ada
Specs for you to compile against (and presumably chunks of object code for
you to link against).

We've got masses of the stuff that we have to migrate, somehow!

Tony M.

--

       Any opinions expressed above are mine.
 To reply by E-Mail remove "SpamJam." from my address.
+===========================+=========================+
| Tony Matthews             |     Senior S/W Engineer |
|                           |  Alenia Marconi Systems |
| Tel: +44 (0)1633 835110   |             Ty-Coch Way |
|                           |                 Cwmbran |
| Fax: +44 (0)1633 835022   |                   Gwent |
|                           |                NP44 7XX |
| E-Mail:                   |                      UK |
|   tony.matthews@gecm.com  |                         |
+===========================+=========================+

Re: PL/SQL -> Ada

[Vladimir Olensky]

Tony Matthews wrote in message <38df972e$1@pull.gecm.com>...
>Andreas Schulz <accot.schulz@nord-com.net> wrote in message
>news:38DE8D9B.83F8D13B@nord-com.net...
>
>Oracle haven't completely abandoned Ada. It's true that all ProAda
>precompiler development has been stopped for some time now, but they have
>replaced ProAda with SqlModule Ada. I'm not sure how many different
>platforms are supported, but Windows NT and SCO UnixWare are certainly
>amongst them.
>
>It is a completely different beast to ProAda, though, in the way that it is
>used. As far as I can determine, you write PL/SQL subprograms/packages to
do
>the jobs you want done and pass them through SqlModule, which spits out Ada
>Specs for you to compile against (and presumably chunks of object code for
>you to link against).



From http://ocsystems.com/frames/news/index.html

OC Systems and Oracle sign exclusive SQL*Module agreement!
On July 2, 1998, OC Systems and Oracle Corporation signed an agreement in
which PowerAda is the sole designated Ada compiler for SQL*Module on AIX
Release 4.2 and subsequent releases.
This agreement is an acknowledgment of OC Systems' commitment to superior
product quality, to long-term support of its products, and IBM AIX-specific
expertise.

OC Systems is an Oracle AllianceTM partner.

Re: PL/SQL -> Ada

[Marin D. Condic]

Andreas Schulz wrote:
> Emmm - what decade (or product?) are you talking about ?
> The Oracle Pro*Ada precompiler has been in use for years,
> until they decided to abondon it with Oracle 8, concentrating
> on Pro*C and Pro*COBOL (IMHO) due to lack of request.
> 
DEC had a precompiler for Ada/SQL at least since 1989. (That's when I
started working with it.) However, what I was talking about was Oracle's
acquisition of Rdb - DEC's database product. My understanding was that
Oracle planned to merge Rdb with their own database. I would presume
that meant doing something for the development tools that went with Rdb,
but I have not been following the database stuff for some time now.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]


Andreas Schulz a �crit dans le message <38DE8D9B.83F8D13B@nord-com.net>...
>Emmm - what decade (or product?) are you talking about ?
>The Oracle Pro*Ada precompiler has been in use for years,
>until they decided to abondon it with Oracle 8, concentrating
>on Pro*C and Pro*COBOL (IMHO) due to lack of request.
>


Yes Oracle as abondoned Pro*Ada and I do think that this is good
thing. Pro*Something is just a plain mess and makes your program
non-portable at all. I would prefer to use a high level library (based on
ODBC if possible) to access the content of a database. At least if this
library is based on ODBC you'll have the possibility to change the
database.

PRO*Something just encourage you to have database access all around
your application.

I have worked on an application where we have used PRO*C instead of
and at least it was good because PRO*C is well supported and it was
not possible to "easily" mix PRO*C code with Ada code. So the design
was important here and the interface between both world was clear
and well defined. But I would still prefer to use a high level library to
do the job...

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: PL/SQL -> Ada

[Bill Meahan]

"Marin D. Condic" wrote:
> 

> I suppose that the reason such tutorials/papers are not available is
> because it takes someone with A) experience in both languages, b) time
> and skills to write such material, c) a desire to advocate Ada to "the
> masses" and d) contacts within the PL/SQL community to spread the word.
> Kind of makes it hard to find someone to sign up for the job, eh? :-)
> 
> I would imagine that if you were to write a sort of
> "Pascal-Subset-Intro-To-Ada-For-PL/SQL-Programmers" paper, we could find
> an appropriate website to put it on.
> 


I think you miss my point: PL/SQL **is** Ada. Well, not really, but it
_is _cobbled from Ada83 (they left a lot of the good stuff out). Hence
an PL/SQL programmer _already_ knows a subset of Ada, probably without
ever realizing it. Oracle seems to have gone to great lengths to not
mention the derivation and only a handful of 3rd-party Oracle texts even
make a passing reference to PL/SQL's origins let alone expound on them.

At the risk of being repetitious: It's not that Ada interfaces well with
SQL (in general), it's that thopusands of Oracle programmers are already
using what amounts to (a piece of) Ada83. So why no effort to expand on
that base?

BTW, at a PL/SQL session of Oracle OpenWorld last November, I asked the
celebrity PL/SQL author, who is really well connected to Oracle's PL/SQL
team and who actually mentions Ada in his books, if, given Oracle 8i's
object features, we could expect some Ada95-isms in future versions of
PL/SQL. He looked at me as if I were from Alpha Centauri, choked, and
said, "No." 


-- 
Bill Meahan WA8TZG    wmeahan@wa8tzg.org
Cro-magnon woodworker. Unix Bigot. Perl fan. Oracle weenie.
Managing software development is like herding cats.

Re: PL/SQL -> Ada

[Marin D. Condic]

Bill Meahan wrote:
> 
> I think you miss my point: PL/SQL **is** Ada. Well, not really, but it
> _is _cobbled from Ada83 (they left a lot of the good stuff out). Hence
> an PL/SQL programmer _already_ knows a subset of Ada, probably without
> ever realizing it. Oracle seems to have gone to great lengths to not
> mention the derivation and only a handful of 3rd-party Oracle texts even
> make a passing reference to PL/SQL's origins let alone expound on them.
> 

There seems to be some general "embarassment" about mentioning that
someone or something has any connection to Ada. Its as if the Anti-Ada
bigots have enforced some kind of "Technical Correctness" on us all and
that to admit you use Ada or derived something from Ada is tantamount to
admitting that you eat babies for desert - or at least that you are a
moron. :-)

Maybe we need to start a Technical Rights movement - have a march on
Silicon Valley, boycot some buses, stuff like that. It could get some
media attention and swing some sympathy our way, eh? :-)

> At the risk of being repetitious: It's not that Ada interfaces well with
> SQL (in general), it's that thopusands of Oracle programmers are already
> using what amounts to (a piece of) Ada83. So why no effort to expand on
> that base?
> 

Well, my question would be: How do you reach them? And what would you
offer them with Ada? Could you find them on a newsgroup? If so, would
offering them a compiler alone be sufficient benefit to them? Or would
you have to offer them some bindings to something, development tools, or
what? Just because they are using an Ada-ish language to work with a
database does not necessarily imply that they have much use for a
general purpose language outside of the database realm unless there is
some utility or connection between the two. What might that be?

I'm all for promoting Ada wherever we can. It benefits us all to expand
the tent and bring in new users. The question of how to attract this
potential audience is one I don't have an answer for, but if you do, I'm
sure you'll be able to find some help here.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Brian Rogoff]

On Mon, 27 Mar 2000, Marin D. Condic wrote:
> Bill Meahan wrote:
> > 
> > I think you miss my point: PL/SQL **is** Ada. Well, not really, but it
> > _is _cobbled from Ada83 (they left a lot of the good stuff out). Hence
> > an PL/SQL programmer _already_ knows a subset of Ada, probably without
> > ever realizing it. Oracle seems to have gone to great lengths to not
> > mention the derivation and only a handful of 3rd-party Oracle texts even
> > make a passing reference to PL/SQL's origins let alone expound on them.
> > 

... snip ...
> 
> > At the risk of being repetitious: It's not that Ada interfaces well with
> > SQL (in general), it's that thopusands of Oracle programmers are already
> > using what amounts to (a piece of) Ada83. So why no effort to expand on
> > that base?
> > 
> 
> Well, my question would be: How do you reach them? And what would you
> offer them with Ada? Could you find them on a newsgroup? If so, would
> offering them a compiler alone be sufficient benefit to them? Or would
> you have to offer them some bindings to something, development tools, or
> what? Just because they are using an Ada-ish language to work with a
> database does not necessarily imply that they have much use for a
> general purpose language outside of the database realm unless there is
> some utility or connection between the two. What might that be?

For better or worse, many programmers will migrate to tools which are
superficially similar to tools that they already know (witness Java).

I don't use relational databases a lot in my work, but let me offer a 
suggestion to Bill: take a look at some of the Ada bindings to existing 
DB interfaces (Postgres, ODBC, etc.) and see if these come close to
providing some of the functionality of PL/SQL. If so, you can use these 
to build some open source Ada DB tools that are familiar to PL/SQL
programmers, if not, you can hack away until you get something close. 

If you have questions about how to use Ada to build a PL/SQL like
interface on top of these bindings, this newsgroup would be an excellent
forum for them. In fact, why not take a look at the issue from the other
side too (educating Ada programmers about PL/SQL) and that way Ada
programmers will be better prepared to assist you.

-- Brian

Re: PL/SQL -> Ada

[Bill Meahan]

Brian Rogoff wrote:

> For better or worse, many programmers will migrate to tools which are
> superficially similar to tools that they already know (witness Java).

Precisely my point! So why aren't PL/SQL programmers migrating to Ada
en' masse? I'm trying to :-)

BTW Besides PL/SQL I've programmed in Fortran (II, IID, IV, IVG, IVH,
66, 77) numerous dialects of Assembler from SPS to 8080 to 32-bit minis,
FOCAL, BASIC (regular and Visual varieties), Perl, C, PIL, SH/KSH, Excel
Macro, Remedy declarations and probably some others I've long since
forgotten. 35+ years of programming is a long time :-)

Right now, for no special reason other than personal enlightenment, and
looking at what PL/SQL might have been if Oracle had left more Ada in
it, I'm learning Ada. I'd like to have my programming staff at work
leverage their PL/SQL knowledge into Ada and build some really robust
applications but TPTB would probably hang me by my thumbs in front of
the iTek building. Seems Ada has a reputatation (around most of the auto
industry, anyway) of being a language for missle programmers and/or
anal-retentive types who spend more time arguing chapter and verse of
ARM or ARM95 than actually coding anything useful. Sorry, but that's the
image TPTB have of Ada. They'd rather throw up crap "Web applications"
quickly than build robust systems. Code quality ain't Job 1. If it were,
our "enterprise architecture" would not be 100% Microsoft, that's for
sure :-(


(For the acronym impaired, TPTB = "The Powers That Be")
-- 
Bill Meahan WA8TZG    wmeahan@wa8tzg.org
Cro-magnon woodworker. Unix Bigot. Perl fan. Oracle weenie.
Managing software development is like herding cats.

Re: PL/SQL -> Ada

[Marin D. Condic]

Bill Meahan wrote:
> the iTek building. Seems Ada has a reputatation (around most of the auto
> industry, anyway) of being a language for missle programmers and/or
> anal-retentive types who spend more time arguing chapter and verse of
> ARM or ARM95 than actually coding anything useful. Sorry, but that's the
> image TPTB have of Ada. They'd rather throw up crap "Web applications"
> quickly than build robust systems. Code quality ain't Job 1. If it were,
> our "enterprise architecture" would not be 100% Microsoft, that's for
> sure :-(
> 
Behold! I send you out as sheep amidst the wolves. :-)

Most wrong impressions of Ada come either from rumors based on
misunderstandings or from experiences people have had misusing the
language. (Even us missile guys get it wrong sometimes) But someone has
to stand there and gently make the case for Ada as a viable tool. I've
had young fresh outs who've asked me why we didn't just scrap Ada and go
use C/C++ like the rest of the world, to which I respond that we can't
run mission critical software with the reliability of your average
Windows app. I could point to solid metrics that demonstrated an error
reduction by a factor of four and to numerous other studies that showed
C/C++ code to be far more error prone in ways that Ada code cannot even
get to. You then ask what is the cost of failure. Corporate dollars down
the tubes? Aborted missions? Deaths and lawsuits? Ada starts to sell as
cheap insurance - something your average businessman can understand.
Keep trying to make the case.

BTW: I'd have to agree about the language lawyer types as being a
negative sell for Ada. While I understand the value of language lawyers
when it comes to language design and implementation, I have often been
frustrated by them getting in the way of getting my job done. I've
sometimes tried to do something which looks perfectly reasonable from
the programmer's perspective only to have the compiler puke over it and
get told by the experts "Well the compiler is doing something perfectly
legal...." Maybe its legal but the law doesn't get the job done. Maybe
what we need to help avoid this is get the Ada language lawyers on
Valium or something so that when the programmer wants something
reasonable from the compiler, the response is more one of "Hey dude! No
problemo!" :-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Charles Hixson]

> ...

> BTW: I'd have to agree about the language lawyer types as being a
> negative sell for Ada. While I understand the value of language lawyers
> when it comes to language design and implementation, I have often been
> frustrated by them getting in the way of getting my job done. I've
> sometimes tried to do something which looks perfectly reasonable from
> the programmer's perspective only to have the compiler puke over it and
> get told by the experts "Well the compiler is doing something perfectly
> legal...." Maybe its legal but the law doesn't get the job done. Maybe
> what we need to help avoid this is get the Ada language lawyers on
> Valium or something so that when the programmer wants something
> reasonable from the compiler, the response is more one of "Hey dude! No
> problemo!" :-)
>

Well, DWIM is always the desired action, but if the language specs don't say
that it should do what you want it to, how is the compiler supposed to know?
"Perfectly reasonable" generally makes sense to another person (not always!),
but compilers need to have things spelled out in a bit more detail.

Re: PL/SQL -> Ada

[Ted Dennison]

In article <38E0EC54.A38F66CE@quadruscorp.com>,
"Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> BTW: I'd have to agree about the language lawyer types as being a
> negative sell for Ada. While I understand the value of language
...
> sometimes tried to do something which looks perfectly reasonable from
> the programmer's perspective only to have the compiler puke over it
> and get told by the experts "Well the compiler is doing something
> perfectly legal...." Maybe its legal but the law doesn't get the job

I'm not sure I understand this sentiment. If the compiler pukes on
something you do, and someone explains to you why, how is that person a
problem?

I'm sure that the C groups are full of language laywers too. Its just
that they spend all of their time telling people why the code did (or
was allowed to do) the unexpected thing it did, rather than why the
compiler didn't allow something to compile. Given the relative amount of
time to track down those two different kinds of problems, I'd be much
happier with the Ada "lawyers".

--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: PL/SQL -> Ada

[Marin D. Condic]

Ted Dennison wrote:
> I'm not sure I understand this sentiment. If the compiler pukes on
> something you do, and someone explains to you why, how is that person a
> problem?
> 
Well as often happens in Ada, a compiler can *correctly* handle
something by simply refusing to do it. Representation clauses are a good
example. (And, BTW, the usual area where I want to shoot the language
lawyers! :-) You try declaring a type and adding a rep clause that is
perfectly reasonable and the compiler rejects it for some reason and you
get frustrated. The language lawyer says "Well, because this was here
and that rule collided with the other and the moon was in this phase and
Jupiter aligned with Mars, the compiler was perfectly within its rights
to reject your rep clause." My response ends up "That's all very
interesting and I'm so happy for you that your compiler doesn't have a
bug in it, but how the heck do I get what I *want* out of the damned
thing??!?!?!"

To the practitioner, the language lawyer can be seen as a stumbling
block in the path to getting the job done. I *do* understand the value
of language law and I'm *glad* we've got sharp lawyers around to make
sure compilers behave according to the rules, but just as real world
lawyers can hose-up a perfectly good business deal, language lawyers can
do the same in the programming world.

If you want specific examples, I'll be happy to discuss them off-line. I
deal with lots of different vendors from time to time and don't want to
get into besmirching specific products in public when the products are
in most other respects quite good.

> I'm sure that the C groups are full of language laywers too. Its just
> that they spend all of their time telling people why the code did (or
> was allowed to do) the unexpected thing it did, rather than why the
> compiler didn't allow something to compile. Given the relative amount of
> time to track down those two different kinds of problems, I'd be much
> happier with the Ada "lawyers".
> 
That, and the "I bet you can't figure out what *this* code does...!"
mindset and we are in agreement. 

   "I don't want a lawyer to tell me what I cannot do; I hire him to 
    tell me how to do what I want to do." 

        --  J.P. Morgan 

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Robert Dewar]

In article <38E2486D.ADB30CCB@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

> Well as often happens in Ada, a compiler can *correctly*
handle
> something by simply refusing to do it. Representation clauses
are a good
> example. (And, BTW, the usual area where I want to shoot the
language
> lawyers! :-) You try declaring a type and adding a rep clause
that is
> perfectly reasonable and the compiler rejects it for some
reason and you
> get frustrated.


My experience is that when people get frustrated in this
situation, it is VERY often because they have some fundamental
misconceptions, or are thinking using fuzzy logic :-)

It would be instructive if you would give specific examples.
Remember we are asking for examples where the dreaded language
lawyers are the ones giving you trouble, not just cases where
compilers fail to accept reasonable optional representation
clauses.

Note that there is a well defined set of rep clauses that is
REQUIRED to be accepted by the compiler, so presumably you
must be talking about examples outside this set (otherwise
you are simply pointing out bugs or shortcomings [no Annex
C support] which is another matter entirely.


The language lawyer says "Well, because this was here
> and that rule collided with the other and the moon was in this
phase and
> Jupiter aligned with Mars, the compiler was perfectly within
its rights
> to reject your rep clause." My response ends up "That's all
very
> interesting and I'm so happy for you that your compiler
doesn't have a
> bug in it, but how the heck do I get what I *want* out of the
damned
> thing??!?!?!"

Usually this is a case in which you simply do not understand
some important and critical semantic principle.

> To the practitioner, the language lawyer can be seen as a
> stumbling block in the path to getting the job done.

This is almost never an accurate reading of the situation.
It is true that users often think that something should work
without understanding things (like the person in some other
thread who thought that "with Standard.Ada.Text_IO;" should
be allowed with the "obvious" meaning. Unfortunately, what
was obvious to him was in fact plain wrong.

> I *do* understand the value
> of language law and I'm *glad* we've got sharp lawyers around
to make
> sure compilers behave according to the rules, but just as real
world
> lawyers can hose-up a perfectly good business deal, language
lawyers can
> do the same in the programming world.

Again, my experience is that when people feel this way it is
simply that they do not know the language well enough and are
missing some critical semantic points. Remember that the people
who designed Ada 95 are highly pragmatic people who understand
pragmatic issues very well, there was not a single theoretician
in the design team from my point of view.

> If you want specific examples, I'll be happy to discuss them
off-line. I
> deal with lots of different vendors from time to time and
don't want to
> get into besmirching specific products in public when the
products are
> in most other respects quite good.

Well it would be interesting to see some examples, especially
if you think my characterization above is unfair :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: PL/SQL -> Ada

[Marin D. Condic]

Robert Dewar wrote:
> My experience is that when people get frustrated in this
> situation, it is VERY often because they have some fundamental
> misconceptions, or are thinking using fuzzy logic :-)
> 
Well, I'm thinking of situations where I know *exactly* how many bytes
are occupied by specific items and I have to line those bytes up with
data coming from the outside world, so I can't accept alternative
representations and I can prove beyond any shadow of doubt that the
bytes will in fact fit just like I said they would and for various
language and/or implementation reasons the compiler says "Sorry, Chalie!
No can do." My problem isn't a misconception about the language or its
implementation. My problem is getting what I want out of the compiler.

> It would be instructive if you would give specific examples.
> Remember we are asking for examples where the dreaded language
> lawyers are the ones giving you trouble, not just cases where
> compilers fail to accept reasonable optional representation
> clauses.
> 
I said I won't do this in public because I don't want to besmirch
otherwise good products with gripes I normally take up with the vendor.
If I had a current problem where I thought I might get some help with
"how do I phrase this in Ada so I get blahblahblah out of the back end"
I might post it and ask for help. At the moment, I'm just bitching about
prior experiences that are water under the bridge. :-)

> Note that there is a well defined set of rep clauses that is
> REQUIRED to be accepted by the compiler, so presumably you
> must be talking about examples outside this set (otherwise
> you are simply pointing out bugs or shortcomings [no Annex
> C support] which is another matter entirely.
> 
Yup. They'd be outside of what a compiler is required by law to do. :-)

That, or they are corner-cases of intersecting rules that stop something
from being legal - even if reasonable.

Remember, Robert, that I'm as big a fan of Ada as you are and that I am
generally very happy with the fact that Ada gives us such wonderful
capabilities for handling data representations. I was just commenting on
the fact that overly-zelous adherence to "the law" sometimes puts people
off from the language because it can get in their way.


> > to reject your rep clause." My response ends up "That's all
> very
> > interesting and I'm so happy for you that your compiler
> doesn't have a
> > bug in it, but how the heck do I get what I *want* out of the
> damned
> > thing??!?!?!"
> 
> Usually this is a case in which you simply do not understand
> some important and critical semantic principle.
> 
I will always concede that when it comes to the syntax and semantics of
Ada that you are "The Man" and I make no claims to being an expert in
this area. What I do is *use* Ada on a very regular basis to build other
things. 99% of the time, I'm a happy camper and I think I'm pretty good
at understanding the syntax/semantics of Ada well enough to use its
constructs properly and in the way they are intended. Occasionally, I
misunderstand features and either because of help from outside or trial
& error, my understanding improves over time. The bulk of the time, Ada
and its various implementations serve me quite well.

Every so often, I've had a problem where I've said "This looks like a
very natural fit with feature XYZ..." I might get 95% of the solution
implemented and then go find the Devil in the details. Some small part
of the problem doesn't work because of language rules or implementation
limitations. The vendor may respond with "You can't do that - but you
could do it this way..." Then you end up tossing aside some very elegant
solution in favor of something much less attractive. You can eventually
get there somehow, but not the way you wanted to.

Probably, this is not just an Ada issue - other languages have their
restrictions as well. Its just that Ada has a tendancy to get more
"legalistic" than some other languages and it can get in the way. I
suppose if you want the benefits that come with Ada's legalisms (safety,
reliability, etc.) you occasionally have to put up with the down side.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Tucker Taft]

"Marin D. Condic" wrote:
> Well, I'm thinking of situations where I know *exactly* how many bytes
> are occupied by specific items and I have to line those bytes up with
> data coming from the outside world, so I can't accept alternative
> representations and I can prove beyond any shadow of doubt that the
> bytes will in fact fit just like I said they would and for various
> language and/or implementation reasons the compiler says "Sorry, Chalie!
> No can do." My problem isn't a misconception about the language or its
> implementation. My problem is getting what I want out of the compiler.

As a user I can sympathize.  As a compiler builder, I will
say that supporting representation clauses in their full
generality is an enormous pain.  I frequently look longingly
at languages which provide little or no control over representation,
and wish I could be so lucky.  

To give you an analogy which might make you feel sorry for us
poor compiler-writer slobs.  Imagine a chauffeur and a passenger.
The compiler is the chauffeur, and the programmer is the passenger.
When there are no representation clauses, you get to tell the
chauffeur to drive the car to the store, and that is about it.
When there are representation clauses, you get to tell the chauffeur
that you want them to put their left foot exactly there, their right
foot there, their left index finger here, their right thumb there,
and their left pinkie over here.  *Now* drive to the store, at exactly
the speed I tell you to, with your tires following exactly along the
pair of white lines I drew on the road earlier today.

In the original scenario, the chauffeur really only needs to know one
way to drive, and they can handle all the road hazards that come up
in the way they choose.  In the second scenario, the passenger is
exerting so much control, that the chauffeur must learn a hundred
different ways to drive, in millions of different combinations, so
they can follow exactly the orders being given by the passenger.

Anyway, so much for the compiler writer's soap opera...

> MDC
> --
> =============================================================
> Marin David Condic   - Quadrus Corporation -   1.800.555.3393
> 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
> http://www.quadruscorp.com/
> m c o n d i c @ q u a d r u s c o r p . c o m
> 
> ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***
> 
> Visit my web site at:  http://www.mcondic.com/
> 
> "Because that's where they keep the money."
>     --  Willie Sutton when asked why he robbed banks.
> =============================================================

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: PL/SQL -> Ada

[Marin D. Condic]

Tucker Taft wrote:
> To give you an analogy which might make you feel sorry for us
> poor compiler-writer slobs.  Imagine a chauffeur and a passenger.
> The compiler is the chauffeur, and the programmer is the passenger.
> When there are no representation clauses, you get to tell the
> chauffeur to drive the car to the store, and that is about it.
> When there are representation clauses, you get to tell the chauffeur
> that you want them to put their left foot exactly there, their right
> foot there, their left index finger here, their right thumb there,
> and their left pinkie over here.  *Now* drive to the store, at exactly
> the speed I tell you to, with your tires following exactly along the
> pair of white lines I drew on the road earlier today.
> 
I like your analogy. Pretty clever.

Yes, I can sympathize with the fact that once I start mucking about
telling the compiler where to put things, it makes your life harder.
Normally though, the representation clauses I've had to apply are mostly
because the data has to fit some format for the outside world. (Reading
hardware registers, messages up and down the hose, stuff like that.) I
don't know if it makes your life any easier if all I ever want to do is
move the data and never actually compute with it. (I could unpack it
into an un-represented-type). Maybe some "usage is non-computational"
clause could be applied?

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: PL/SQL -> Ada

[Brian Rogoff]

On Tue, 28 Mar 2000, Bill Meahan wrote:
> Brian Rogoff wrote:
> 
> > For better or worse, many programmers will migrate to tools which are
> > superficially similar to tools that they already know (witness Java).
> 
> Precisely my point! So why aren't PL/SQL programmers migrating to Ada
> en' masse? I'm trying to :-)

I suspect because many PL/SQL programmers are really *just* database
programmers, and Ada is really a general purpose language. Many PL/SQL 
programmers don't need Ada or C++ since the specialized tools for their 
domain are substantially more productive if you don't need to do more than 
DB programming.

Have you taken a look at the Ada 95 DB bindings? I'm interested in how
much more work you think needs to be done to make a decent open source 
tool that could aid in your Ada evangelism. 

> BTW Besides PL/SQL I've programmed in Fortran (II, IID, IV, IVG, IVH,
> 66, 77) numerous dialects of Assembler from SPS to 8080 to 32-bit minis,
> FOCAL, BASIC (regular and Visual varieties), Perl, C, PIL, SH/KSH, Excel
> Macro, Remedy declarations and probably some others I've long since
> forgotten. 35+ years of programming is a long time :-)

Indeed. However, I'm of the opinion that if possible it is better to work
in *very* different programming languages to expand your mental problem
solving toolset. I actually consider Ada, C++, Fortran, Java, and many
others to be very similar (this isn't a troll BTW ;-). A representative 
sample of some different languages would include Haskell, Icon, Mercury, 
Common Lisp, Objective Caml, and Forth. In my field, the domain specific 
languages (analogous to Excel and PL/SQL) are Verilog and VHDL, where 
VHDL is an Ada-like language. I use Verilog because almost all of the ASIC 
designers in the valley do, but they are also quite similar.

> Right now, for no special reason other than personal enlightenment, and
> looking at what PL/SQL might have been if Oracle had left more Ada in
> it, I'm learning Ada. I'd like to have my programming staff at work
> leverage their PL/SQL knowledge into Ada and build some really robust
> applications but TPTB would probably hang me by my thumbs in front of
> the iTek building. Seems Ada has a reputatation (around most of the auto
> industry, anyway) of being a language for missle programmers and/or
> anal-retentive types who spend more time arguing chapter and verse of
> ARM or ARM95 than actually coding anything useful. Sorry, but that's the
> image TPTB have of Ada. They'd rather throw up crap "Web applications"
> quickly than build robust systems. Code quality ain't Job 1. If it were,
> our "enterprise architecture" would not be 100% Microsoft, that's for
> sure :-(

Well, you can hack in Ada too, and IMO it is a nice language to hack in 
once you know it becuase of the strong typing. Better hack/debug ratio. 
Not all Ada fans are language lawyerly types; I've been known to say
"Dude!" and curse like a sailor :-)

-- Brian