ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When I 'recycled' myself into IT in 1978, people said that COBOL would be dead soon. Now I am a decade old retiree, it still lives.
The advantage of COBOL is it's can be decompiled (to get the source code), so hackers cannot insert malicious codes into a program easily.
Actually, EdGr, "this is emphatically not(!) the case!" Not when you are talking about "dollars and cents!"
If your task is to "add up an endless column of figures," and you do this using floating-point, then the errors can quickly grow to be very large ... because you are translating each input into a floating-point "equivalent," then translating the final sum back out.
Although most programming languages – including Perl – provide "decimal arithmetic" using some external package or packages, none other than COBOL (to my knowledge ...) built it right into the language itself ... and optimized the hell out of it.
Every microprocessor that I am aware of ... even the M6502 ... implemented a "decimal mode" as well as "binary." So, the hardware support has always existed, and I doubt that "speed" was ever a consideration between the two.
Yes: "BCD = Binary-Coded Decimal" has always been important, where each four-bit group represents either a decimal digit or a sign indicator, and arithmetic is performed using decimal rules. CPU hardware has supported both.
I did some stuff in PL/1 back in the day. It also had decimal mode built in. PL/1 also allowed you to start arrays at either 0 or 1 (or anywhere else, for that matter). It tried to be everything to everyone, I think.
When operating on BCD integers in x87 FPU data registers, BCD values are packed in an 80-bit format and referred
to as decimal integers. In this format, the first 9 bytes hold 18 BCD digits, 2 digits per byte. The least-significant
digit is contained in the lower half-byte of byte 0 and the most-significant digit is contained in the upper half-byte
of byte 9. The most significant bit of byte 10 contains the sign bit (0 = positive and 1 = negative; bits 0 through 6
of byte 10 are don’t care bits). Negative decimal integers are not stored in two's complement form; they are distin-
guished from positive decimal integers only by the sign bit. The range of decimal integers that can be encoded in
this format is – 10^18 + 1 to 10^18 – 1.
The decimal integer format exists in memory only. When a decimal integer is loaded in an x87 FPU data register, it
is automatically converted to the double-extended-precision floating-point format. All decimal integers are exactly
representable in double extended-precision format.
Note: if you are on hardware that does not have x87 FPU registers, or purposefully does not make use of them, then BCD format is preserved. For some kinds of processing this is critical.
About 2000, I designed & built battery powered hardware for a prototype 7 segment paper display. I just had a PIC Microcontroller, which is a pretty stupid cpu - more a bank of adressable switches for it's legs. I ran it @32.768khz, because there was little room or need for a clock chip. I did all of this stuff in Assembler. There probably was a binary --> bcd instruction, but I don't know if I used it, because IIRC, I kept each digit in a separate register for convenience.
On topic: If you as a programmer are looking backwards, sure, learn Perl. If you're looking forward, do Python. I don't consider myself a programmer at all, but the one programmer I know well has at least 12 languages under his belt, although he's only automatic in about half of them.
PL/1 was taught in our University although the language never went very far. Like Ada after it, I don't think that it was used by much of anyone outside of government contractors.
The COBOL designers later started introducing "object oriented" features into their language, although I don't know how widely they were ever adopted.
PL/1 was taught in our University although the language never went very far. Like Ada after it, I don't think that it was used by much of anyone outside of government contractors.
The COBOL designers later started introducing "object oriented" features into their language, although I don't know how widely they were ever adopted.
Hmmm...ADD 1 TO COBOL GIVING COBOL.
I worked for several years at a steel company. They ran Object Oriented Microfocus COBOL to code their interface between Oracle databases on IBM AIX and Windows machines and the remote mainframe DB2 database servers. At one point the manager and I had to pull them apart and make changes, because we were the only ones left that could GROK COBOL!
It was "interesting", but we got it to work.
I really WISH we could have used PERL!! It would have taken half the time and 20% of the code!
But at the time that the company started that initiative, their technical options might have been much more constrained. Today, we live with "an embarrassment of riches." But that certainly was not always the case – as all of us well remember. (And in the case of Perl, but likewise many other tools, the real "leaps and bounds advances" have occurred within CPAN – and the binary libraries that many CPAN packages actually use to do the work.) At the time, and really as now, "we do what we need to do with whatever we have to do with it, and hope to retire before we get caught."
Now, looping back to the original question of "is it still worth learning Perl," I myself have always been very interested in programming languages and even invented one. You never know which tools you are going to find being used in any "shop." I have found it to be to my advantage to become cursorily familiar with languages as they come along, particularly the concepts and metaphors that each one "champions."
The "rust" programming language, for example, is all about safe concurrency. Google's "Dart/Flutter" system for cross-platform mobile development implements many of the same ideas. All of these systems have excellent web sites with extensive conceptual material as well as traditional syntax documentation. It's well worth your time to make yourself aware of everything that's going on in your industry ... both new and "old."
I only set out to learn a language if I have to use it. I've added a few over the years due to work assignments.
I can learn them readily enough. So not setting out specifically to learn one for kicks.
I know you've discussed whether it's better versus other script languages. Can't say, but bash, and Python seem to be the most typical ones I see being used for scripts.
Python is an excellent interpreter and I generally use it more often these days than Perl ... but you just never know what you'll find out there at your next job or assignment. You're almost never writing new software. You're almost always maintaining a mission-critical existing system, and those systems don't move from the original language they were written in. Perl still moves a lot of freight.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.