My three year old daughter loves "Bob The Builder" - a chracter of which the parent of any pre-schooler almost anywhere in the world would know. One of the songs on his album is "Right Tool for the Job". A wonderful thing to remember.
If I want to write a device driver for Windows (something I do as a hardware designer!) then I use C++. Darn, I wish it could be easily done in assembler! When the person paying the bills asks for it I will use VB.
But most of the time my work is not speed critical, is not highly reliant on OLE and generally it is a benefit if it can work on various platforms. Over 30 years of hacking code I have tried oh so many. But my experience tells me one thing.
As an academic in my time I found that the computer scientists never liked Perl - it was not pure enough. Until Damian, and I enjoy reading his material because he has the larrikin Australian attitude to computer science.
As a research scientist and engineer in the 1970's I wish we had Perl. I used to say to my staff in those days that each profession needs two things - its own chain saw and its own duct tape. we cannot concentrate on the beauty or purity or academic rigour of our code unless that is what we are about. When I wanted to solve chained matrices in the 60's I used GE TimeShareBASIC - it was what I had access to, so it was the right tool for the job. In the 70's Fortran was better for the job, besides it handle complex numbers directly. By the 80's we had to solve much bigger matrices so we called upon Pascal and the C to implement our sparse matrix solutions. They were the most powerful chain saws we had available to us.
At every turn their was a "right tool for the job". But now the problems I was empoyed to solved have been solved, hundreds of programmers at HP, Aplac and Ansoft. Nowadays I hack a bit of stuff for web apps and a few other things to keep my three year old in DVD's and toys. So Perl is the right tool for the job.
Funnily enough I still get asked to deal with some obscure mathematical problem, or a model that needs evaluating of verifying. Since I discovered Perl Data Language I have been able to stop wasting huge amounts of money on Matlab and still get the job done. If somebody hasn't described Perl as the Chain Saw and Duct Tape of the 90's and btyond, well, I will do it now!
Every langauge has its place and it proponents, I like looking at arguments, and even friendly discussions about langauges. What we must all do is remember that vast numbers of programmers have no formal training, or if they are anywhere near as old as me they probably don't! Each will choose what suits them. In much the same way we choose poerating systems. Some choose Windows/DOS because that is all they have ever known - how many monks were born into a world that did not have IBM-PC's? Personally I don't believe that Windows per-se is such a huge backwards step. I think the entire PC architecture is possibly the biggest step backwards that was made since the inception of electronic computing, and Windows comes a close second!
Darn it, whilst we are going, lets talk about the design of CPU's. Nowadays we try to do everything with 16/32/64 bit machines. In the late 70's a colleague and I designed a 24 bit processor which was optimised for three dimensional array and matrix arithmetic. Then we expanded this to 48 and then 96 bits in the 80's. It was simple, elegant, and for its job, blindingly fast. The early machines used TTL, then bit-slice CPU's. The last one, built only six years ago uses CPLD's. The earlier ones used software floating point, then Intel floating point co-processors, then the last one did its FP using an array of CPLD based FP engines. But I shelved the entire project when my colleague died three years ago. You see we couldn't find anyone who wanted to write microcode for these things any more. Everybody who came to look at it said, well, do you have a C++ compiler for it? Of course the answer was no, but you are welcome to write one if you want to! But of course to do that you have to write the microcode to support it. A single one of our 48 bit matrix engines could outrun anything short of a super-computer class machine when it came to solving matrices. But it died because it didn't have a Java Virtual Machine.
The point really is that whe processors, langunages and architectures we rage Holy War over today are posibly not the best we have had. They may not be the most elegant. But they are what we have and I firmly believe that it is time we put the hatchets away and got down to improving them instead of trying to put the other guy out of business.
jdtoronto has now had his late Saturday night rant is is going to find a convenient hole to hide in till this all blows over, as it inevitably will :)
In reply to Re: Is Perl the best programming language - a better way for discussion
by jdtoronto
in thread Is Perl the best programming language - a better way for discussion
by pg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |