The principal was obviously a product of the US education system system, which is apparently too busy with the science/religion question to worry about something as mundane as free speech. That, plus a mistrust of even the least qualified lawyer to tell them what the constitution says about free speech, makes these issues increasingly frustrating, and expensive.
Now all that's needed is dispensers that enable it to be administered surreptitiously in crowded areas, although seeing someone standing next to you turning green might cause other problems.
I'm wondering what percentage of the drain began during the Bush administration, when the perception held by foreigners around the world began to be increasingly negative, and as a result if the financial meltdown, which has put a crimp on the American economy. In my previous travels, just about everywhere I went, people talked about their friends and relatives who were in school or working in the United States positively, and often great pride. Now, not so much...
As a dinosaur who started cranking code more than 40 years ago, I've been out of touch with things like virtualization for some time. The last word on virtualization in the mainframe world in the 70's and 80s was IBMs VM series of virtual machine operating environments: CP/67, VM/370, VM/SP, etc., coupled with CMS, the Conversational Monitoring System OS for each virtual machine. These were spectacularly useful across a wide spectrum of user profiles. In concept, how do current virtualization strategies differ from these early IBM products, and what took so long for products of this type to return to the mainstream?
Acucorp has been doing something like this since about 1985 with their COBOL compiler. It produces object code that is executable by a platform-specific run-time system; it is availabale for just about any platform (except IBM mainframes). The object code is copied to the target platform using a special utility, and it works. They do some spactacular stuff with databases, too.
For the uninformed, programming languages simply implement the facilities of the processor hardware or microcode, they don't change it. In most cases, comments like "you can't to this or that in a particular programming language" simply means that the original developers of the specific compiler chose no to implement certain aspects of the processor's instruction set. Either that, or the facilities of the particular languge were not well enough understood by the critic. There's a big difference between "can't be done" and "I don't know how to do it" or "it's not worth the effort". Further, many of these criticisms can often be remedied by doing a "CALL" to a routine written in what might be deemed a "more suitable" language, or a routine in a specialized or domain-specific library.
In comparing languages, it might be wise to remember that most of code written in any language was written by programmers, the vast majority of which never took the time to understand the languages in which they code; remember, the 80-20 rule applies virtually anywhere. It has been estimated that becoming a good programmer in any language takes 4-10 years. Most of those old COBOL programs were written by people just as motivated, dedicated and knowledgable as today's programmers. What has changed is the environment. In the early days of computing, practitioners didn't have the tools, training and techniques in any language that they have now; in many cases, much of what was being programmed was being done for the first time, ever. And the biggest COBOL facing programmers maintaining COBOL programs has little to do with the language, it has to do with the maintenance of the records pertaining to the application, particularly the state of the available source code. In that regard, with few, if any, exceptions, COBOL's supposedly verbose syntax is self-documenting, as it was intended to be. Frankly, most of the negative comments I've seen have been made by people with only limited knowledge or experience in COBOL. Another factor in the decline of COBOL is that it was used predominantly on mainframes; when minicomputers (remember them?) came along, it took some time for full versions of the COBOL compiler to be implemented on them, so applications were written in other languages. Today's COBOL compilers, like those from Acucorp, Fujitsu and Microfocus, to name a few, offer facilities, functionality, ease of use and productivity that are equal to or exceed that of many other languages. As in many other fields, apples-to-apples comparisons are often difficult to verify, and are often clouded by the experiences of those doing the comparisons: one man's fish is often another man's poison, and not alwasy within the realm of objectivity. I've found that most of what are commonly described as COBOL's faults or weaknesses are simply opinions based on a limited knowledge of COBOL versus other languages. Remember, it pays to know what end of the horse is doing the talking.
Slashdot Mirror
The principal was obviously a product of the US education system system, which is apparently too busy with the science/religion question to worry about something as mundane as free speech. That, plus a mistrust of even the least qualified lawyer to tell them what the constitution says about free speech, makes these issues increasingly frustrating, and expensive.
Now all that's needed is dispensers that enable it to be administered surreptitiously in crowded areas, although seeing someone standing next to you turning green might cause other problems.
I'm wondering what percentage of the drain began during the Bush administration, when the perception held by foreigners around the world began to be increasingly negative, and as a result if the financial meltdown, which has put a crimp on the American economy. In my previous travels, just about everywhere I went, people talked about their friends and relatives who were in school or working in the United States positively, and often great pride. Now, not so much...
As a dinosaur who started cranking code more than 40 years ago, I've been out of touch with things like virtualization for some time. The last word on virtualization in the mainframe world in the 70's and 80s was IBMs VM series of virtual machine operating environments: CP/67, VM/370, VM/SP, etc., coupled with CMS, the Conversational Monitoring System OS for each virtual machine. These were spectacularly useful across a wide spectrum of user profiles. In concept, how do current virtualization strategies differ from these early IBM products, and what took so long for products of this type to return to the mainstream?
Acucorp has been doing something like this since about 1985 with their COBOL compiler. It produces object code that is executable by a platform-specific run-time system; it is availabale for just about any platform (except IBM mainframes). The object code is copied to the target platform using a special utility, and it works. They do some spactacular stuff with databases, too.
For the uninformed, programming languages simply implement the facilities of the processor hardware or microcode, they don't change it. In most cases, comments like "you can't to this or that in a particular programming language" simply means that the original developers of the specific compiler chose no to implement certain aspects of the processor's instruction set. Either that, or the facilities of the particular languge were not well enough understood by the critic. There's a big difference between "can't be done" and "I don't know how to do it" or "it's not worth the effort". Further, many of these criticisms can often be remedied by doing a "CALL" to a routine written in what might be deemed a "more suitable" language, or a routine in a specialized or domain-specific library.
In comparing languages, it might be wise to remember that most of code written in any language was written by programmers, the vast majority of which never took the time to understand the languages in which they code; remember, the 80-20 rule applies virtually anywhere. It has been estimated that becoming a good programmer in any language takes 4-10 years. Most of those old COBOL programs were written by people just as motivated, dedicated and knowledgable as today's programmers. What has changed is the environment. In the early days of computing, practitioners didn't have the tools, training and techniques in any language that they have now; in many cases, much of what was being programmed was being done for the first time, ever. And the biggest COBOL facing programmers maintaining COBOL programs has little to do with the language, it has to do with the maintenance of the records pertaining to the application, particularly the state of the available source code. In that regard, with few, if any, exceptions, COBOL's supposedly verbose syntax is self-documenting, as it was intended to be. Frankly, most of the negative comments I've seen have been made by people with only limited knowledge or experience in COBOL. Another factor in the decline of COBOL is that it was used predominantly on mainframes; when minicomputers (remember them?) came along, it took some time for full versions of the COBOL compiler to be implemented on them, so applications were written in other languages. Today's COBOL compilers, like those from Acucorp, Fujitsu and Microfocus, to name a few, offer facilities, functionality, ease of use and productivity that are equal to or exceed that of many other languages. As in many other fields, apples-to-apples comparisons are often difficult to verify, and are often clouded by the experiences of those doing the comparisons: one man's fish is often another man's poison, and not alwasy within the realm of objectivity. I've found that most of what are commonly described as COBOL's faults or weaknesses are simply opinions based on a limited knowledge of COBOL versus other languages. Remember, it pays to know what end of the horse is doing the talking.