Snipping and reordering:
However, I am aware that this is a) Off Topic, and b) I'm by no means an expert on COBOL.
Blow that. This is one of the most interesting topics on the mailing lists in ages. Besides, you started this topic so you get to say what its about.
Mark Rogers a while back on the thread said:
My experience is that the language differences are sufficiently subtle if you are a "programmer", ie you are used to programming generally.
I think thats a very generalized statement, and for the moment it suits my purpose to agree to exagerated proportions (I hate the term expert) : As an expert professional engineer in a different language, I'm more then have this discussion about Cobol...
As far as I'm aware, Cobol wasn't originally designed to "database" stuff - its just too old* (I'm talking pure original Cobol here). Programmers would have to develop their own file routines (however Cobol was one of the first languages to have the concept of "libraries" of other peoples code that you could call, so undoubtedly there would be database-type-libraries that could be added on.
Not trying to be awkward, but as far as I can work out, COBOL started with File handling routines, and these supported Indexed files right from the start, which is what it was intended to do - Common Business Oriented stuff. Whilst indexed random access files might not qualify as the fully functional Relational Database Management system that we're expect when we talk about Databases today, I'm sure programmers at the time would have considered it "Database Stuff."
Lets hunt out some Cobol programmers.... Nev from the other topic is one!
I think we're saying the same thing but the language is different - my point is that by "database stuff" I mean that the language itself does "database stuff" rather then programmers making database like applications using the more basic file handling.
And this is part of the original point - if you've got 3 months to write an application in, and you spend two of those pissing about with file handles and following indexes, then you're program is limited in what it can do.
Instead these days, I spend a fair amount of time working out what I want to build, what the data layout is, just like they would in original days, and then I just say create a database, create my objects as they are on paper, and just say "store 'em in there" and boom dingaling it does it. I then have 2 spair months to sit around complaining about various things and arguing about whether if I was writing in Cobol I would be a better programmer.
Noodles from irc also pointed out that Cobol does include SQL injection routines, but I think we have a fundamental problem, which is that our concept of the language is what it could do when we discovered that language - Cobol dates to late 50's, SQL dates to early 70's, so certainly all that you could want from a language gets added to it over time.
This though, can also be a bad thing - PHP got added to quite rapidly, but not in a very good manner, and as such there are various annoyances such as inconstancies in argument ordering across different libraries.
So, I say one language *can* be better then another language, and age, and forward planning and knowledge of future technologies is one of the prime factors to this.
Actually it seems there is a strand of Cobol for .Net, working fully and the engineers even going so far as to write ASPX pages... must.... not ..... must.........not....