sunaj,
Of course that is also the underlying concept behind horse races - the difference in opinion. I have used Fortran, BASIC BASIC, C++, Visual Basic, Pascal and two different assemblers. Not to mention SQL, Lisp and CICS. Some of them exhibit 'Specialties' and most do have a basis/origin in some area of computation. On the other hand I have used FORTRAN for 'database' work and Visual Basic is quite popular in financial applications which are computationally intensive - to the point where more than one customer has REQUIRED the product be developed in VB.
I tend to see the various alternatives more in terms of 'levels' of abstraction than the application. In that sense, I would put Assembler as lowest, with C down near those and C++ perhaps a step removed from even C. "Visual" Languages are 'way far away' from these, near the TOP.
As for efficiency, it really depends on your deffinition of the term. In "the good old days", human input was VERY cheap compared to the actual computer equipment, so having a Programmer work on 'stuffffff' for hours, days, weeks ... was 'not a problem' - as long as the final program was 'Efficient'. In today's world, that equation is more or less reversed. So, in general, only fossils like me even ever look at a piece of code that 'works' =- even if it is obvious that it is inefficient because it takes WAY to long to get the results. So efficiency - in term of 'the program' are (almost) meaningless. Efficiency - today - is really only measured by how fast te programmer is finished with the application.
In THOSE terms, FORTRAN couldn't come close to a VB app for the same problem - except for the existance of the libraries waterguy is asking about.
As one example, I 'translated' a popular FORTRAN program to VB about a year ago. Approximatly 1/3 of the FORTRAN Code was replaced by a single VB Form with less than 100 lines of code. The complete File I/O process in FORTRAN was reduced to a single common dialog control in VB. A dozen 'spaghetti code' routines to input edit and delete data arrays was replaced with a grid control with edit capabilities. Instead of dealing with a monolithic source code module (> 4K lines of code), a few recursive functions provided a replacement for the majority of the 'in-line' processing.
Why would anyone PAY ME to do this conversion from the "Efficient" FORTRAN to the "InEfficient" VB? Theirr answer was simple - maintenance. They wanted to ba able to add functionallity to the program, but found that the lack of boundaries in the FORTRAN code made the introduction of addditional capabilities very difficult. They also wanted to 'modernize' the data input process, however that was a secondary consideration.
Sorry for the soap box, but yoiu did ask (even if I baited you into doing so).
MichaelRed
redmsp@erols.com
There is never time to do it right but there is always time to do it over
