Re: COBOL, PL/SQL, or both

On Fri, 20 Sep 2002 02:00:38 GMT, John Russell <netnews4_at_johnrussell.mailshell.com> wrote:

>On Thu, 19 Sep 2002 13:28:44 GMT, spamdump_at_nospam.noway.nohow (Ed
>Stevens) wrote:
>>>I would also stick all the updated data into a PL/SQL collection
>>>(probably an index-by table) and then use the FORALL to loop through
>>>all the UPDATE statements. It's much faster than doing a separate
>>>UPDATE for each changed row.
>>>
>>>John
>>
>>A nice technique, but would that not require that the application be written in
>>PL/SQL? If so, I refer you back to the original post -- the app is written in
>>cobol and the project is to port it to a different platform.
>
>Oops, I did overlook that, what with the pseudo-code. I tend to
>mentally translate it always to PL/SQL. :-)
>
>However, it might still be practical to embed a PL/SQL anonymous block
>to do the core of the update loop, assuming that's a relatively simple
>and self-contained bit of code. Pro*COBOL supports embedded PL/SQL:

I wasn't aware of that. I'm sure we won't use that technique on this project, but it's a good piece of information to file away for future reference. Thanks for the lead.
>
>http://otn.oracle.com/docs/products/oracle8i/doc_library/817_doc/appdev.817/a76951/pco06pls.htm#3835
>
>On a slight tangent...
>
>I'm interested in the notion of transitioning from other languages to
>PL/SQL, or integrating PL/SQL into an application that's mostly
>written in something else, e.g. via embedded PL/SQL or stored
>procedures.
>
>Some of the new 9i features put me in mind of the similarities between
>Perl and PL/SQL <snip>

I'd bet that the guys that developed PL/SQL were Unix-heads who tended to THINK in Perl. Since my first language is COBOL, I tend to concieve all solutions in COBOL, then figure out how to translate that to the language at hand. Thus, I tend to write VB, Rexx, and PL/SQL all as if they were COBOL with a different syntax. Especially in the early stages of learning a new language. I have a friend who is very conversant in 'C' and it tends to show in his COBOL programs. Most of the people around here *hate* to maintain his work because they find it overly complex. I'd guess the same mechanism is at work in developing a new language, such as PL/SQL. The language developers tend to think in their first language.

Works in human languages also. I have a friend who's parents were missionaries to Puerto Rico. He grew up with Spanish being just as much a first language as English. As a result, believe it or not, he sometimes has difficulty translating between the two. His explanation is that when he is speaking in Spanish, he is *thinking* in Spanish, and when speaking in English he is *thinking* in English, thus seldom has to concern himself with the complexities of translation.

--
Ed Stevens
(Opinions expressed do not necessarily represent those of my employer.)