Some interesting points have been brought up in this thread. However, I think we need to step back a little, and look at these langauges in the time they were designed, not now, with 20/20 hindsight.
When COBOL was designed, it was an attempt at a language that allowed computing concepts to be express as natural language. Rather than terse, cryptic statements, it was *intended* to be wordy. This allowed programmers to think in more in English, and less in langauges like Fortran. COBOL was targetted at the business community, and not at the scientific/computing communities like other languages of the time.
By our standards, today, COBOL is a horrific langauage, an anthesis of everything we think a language should be. At the time, the idea was debugging would be reduced because concepts were expressed in
an 'English' like language.
People hadn't grown up with computers, like we do today. It wasn't all that long ago in the great timeline that computing facilities of any consequence were either company owned, or existed only on university campuses. What we take for granted today didn't exist back then, so there are a great number of comparisons that just aren't valid.
We consider Perl a pinnacle of development at this point in computing history. But
let's be realistic. Perl serves a very useful purpose, but as languages go, it's just as obscure as 'C', APL, and few others. We have odd little symbols that are not self-documenting. We have 25 different way of expressing a concept, all valid, but incomprehensible to the un-
initiated. If you were to explain basic logic constructs to a lay-person, odd's are they would have a better chance understanding a COBOL program than a Perl program. Certain langauges like LOGO are even more understandable. Oh, we may not consider them efficient, or elegant, but the reality is that what makes a langauge is more than just readability, just terseness, or just (fill in your favorite concept here).
I'm not very fond of language bigots. All languages serve a purpose, even if we never
learned what they are. The ones that died in the Darwinian pond of computing are ones that never went mainstream. I used to write in XPL0 on the Apple ][ (note correct use of brackets here!) I've written Forth, dozens of assembly variants, Fortran, Pascal, Logo, Perl, 4GL database langauges, PL/1, PLM, other stuff that you may or may not have heard of. Some I learned because they were there. Others because they filled a programming need that had to be satisfied. Not all were fun. Not all were even good. PLM was a wierd cross of high level IF constructs
combined with straight assembly. Not intuititve, and difficult to debug. Yet, the code ran. It was what the customer wanted. And it was the tool we had available, at that point in computing history.
It's important to remember that Perl is a young language, as langauges go. New langauges are introduced every year than the previous year. Because we grow up with tools like Yacc, and Lex.
Compiler design is no longer the rarified air of academics. We can do it at home, and it's easy. We've got the tools, we've got the code samples, we've got the net access to find out what we need to know.
Yea, we all like Perl. But again, Perl is a means to and end. It has it's place and it has places it shouldn't/never will be.
You aren't going to find Linux device drivers written in Perl. It's not the tool for the job. And 20 years from now, Perl programmers may get paid lots of bucks to maintain that old Perl code that no one uses anymore.
There is no 'best' language, in a general sense. There are 'best' languages for the job at hand, but NO language replaces all the others and leaves the in the dust. I won't say COBOL has a place much anymore, not with all the new tools we have. But the fact is, there are big iron machines out there only have COBOL and Fortran. And they run big expensive applications that people don't have the time or money to port over to modern machines. And as long as the hardware keeps running, they're going to run
their apps, because they server their need. And that's what computing is all about. Filling a need. Not arguing that your langauge is better than mine. Maybe at a given task yours excels, but there is *always* some that mine
will be better at. So get over language differences, and argue the tool to solve the problem, not how to make the problem look like a nail so you can use *your* hammer.
One more thing: Compiler technology has a come a long, long way from the days when COBOL and Fortran dominated the landscape. Computing power is far superior to those times. Keep that in mind when you get ready to start talking trash about the older langauges. We did it with what we had to do. Thanks to the efforts of the giants behind us, we can stand on their shoulders and build betters things. After all, Perl *is* written
in 'C'...
--Chris
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.