[Info-vax] Programming languages on VMS

[Bill Gunshannon]

On 01/24/2018 11:16 AM, Jan-Erik Soderholm wrote:
> Den 2018-01-24 kl. 17:03, skrev Arne Vajhøj:
>> On 1/24/2018 10:51 AM, Jan-Erik Soderholm wrote:
>>> Den 2018-01-24 kl. 16:36, skrev DaveFroble:
>>>> I'll preface the question by admitting that I view much of the "new 
>>>> languages" as some people who just want to "re-invent the wheel".
>>>>
>>>> Do the "new languages" actually present more and better capabilities?
>>>
>>> Is a screwdriver better then a hammer? I would guess that you
>>> understand that the answer is that "it depends"...
>>
>> Some languages are better for some things than for other things.
>>
>> Languages are designed with certain usage in mind. So they are
>> often good for that usage and rather poor for other.
>>
> 
> Isn't that just what I just wrote? That "it depends"? Or am I
> missing some point you are trying to make?
> 
>>> In our case, Cobol is "best" for our core applications since it
>>> gives smooth and fast applications for our end-users.
>>
>> I find it hard to believe that Cobol is the only language that
>> could provide that.
>>
> 
> Now, the context was *our* core applications. But yes, strictly
> technically, one could write the applications in a number of other
> (compiled) languages, but Cobol gives stable code with few options
> to "shoot yourself in the foot". We would not be able to rewrite
> all our Cobol code in Java (or Python), the performance would go down
> the drain. We need stable response times to the factory equipment
> including database updates.
> 
> Now, just speculating, but I think that it is easier to read 20-30
> year old and badly commented/documented Cobol code than 20-30 year
> old and badly commented/documented C code. I might be wrong... :-)
> 

Well, that depends on the code.  Or more likely the programmer who
wrote it.  I have little problem with C code of any age.  And, as a
teaching experience, I once wrote a totally functional but completely
incomprehensible COBOL example of the "Update Master File" genre.

Now, PHP, there is the language you should have mentioned.  Last
real world example of trying to fix a PHP program involved a rather
simple Web Form processor that even the person who wrote it cpuldn't
understand what it did just one year later.  And just to bring this
to a close, after 3 people struggled for 5 days trying to figure out
how it worked and why it didn't anymore, I wrote a replacement in
Bourne Shell in about 15 minutes. (I also wrote another in COBOL
just as a proof of concept.  That took about half an hour and most
of that time was typing it in.  I'm not as fast a typist as I once
was.)

bill