On Wed, 14 Dec 2005 18:54:27 -0800, "William L. Brandt" <[log in to unmask]> wrote:

> Gosh I came from an era when there was COBOL, FORTRAN, and assembler.

... and ADA, and ALGOL, and APL, and BASIC, and BLISS, and CORAL, and PL/1, and LISP, 
and PASCAL, and TECO (anybody here remember DEC SYSTEM 10 & 20?) and SPL, and 
RPG, and RPGII, and C, and C++, and SMALLTALK, and FORTH, and so on ad nausium.  
These, to my recall, all pre-date 1990 and most pre-date 1980 in origin.

These are called languages by convention, but with few exceptions they are all dialects of 
ENGLISH, some more TERSE than others.

> Now there's Ruby On Rails (actually a system to work on a language called
> Ruby), C, Perl, Python, PHP, TCL, Java, Ajax, Flash (for buiilding web
> sites), Dojo, Domo Arigato (ok, just made the last one up.....)

RUBY is ten years old while RAILS is a framework generator, still in beta, that is akin to 
STRUTS for JAVA.. TCL/TK and PYTHON are both nearly fifteen years old.  PERL is twenty 
years old.  AJAX is an acronym for "Asynchronous Javascript And Xml" which is arguably a 
process description involving a programming language (JS) dating from 1994 and a mark-up 
language dating from 1998 and not a programming language in any conventional sense of the 
term.  

FLASH is an animation authoring program not far removed from other graphic editing programs.  
While it possesses scripting features I would no more classify it as a programming language 
than I would VisiCalc, Lotus-1-2-3, or Microsoft Word/Excel prior to VBA.  I take this stance on 
the basis of the unspoken, but widely accepted, principal that programming languages are 
intended to be general purpose problem solving tools rather than application specific extensions, 
regardless of how much a given language may favour particular approaches to solutions. 
However, I concede that the distinction between an application and a virtual machine is, in 
essence, arbitratry.

The nature of the problem to be solved and resource constraints external to the problem itself 
are what drive programming language development.  Specific data processing tasks are much 
more economically addressed when a variety of tools are available.  For example, while I have 
no problem with a database driven commercial application suite written in POWERHOUSE or 
SPEEDWARE I do not think it appropriate to use QTP to find and forward in compressed format 
over the a secure SSL link the contents of a group of files to another computer.  However, in 
BASH this takes one line of code (once the enabling SSH environment and key exchange is 
setup on both machines). 

tar cz $(find / -type f -name \*.conf -not -name \*so.conf) | ssh target.host.tld "cat > 
/var/spool/lvm_backups/tld.host.target/inet05.configs.$(date +'%Y%m%d').tar.gz"

This could be generalized trivially by substituting variables for the filename selection criteria, 
hosts, and directories but the point is made.  On the other hand, I doubt very much that an 
acceptably economical, non-trivial, multi-user transaction procressing system could be written 
entirely in BASH, regardless of the talents of the individuals involved.

The question is one of economy of effort rather than assuaging the misapphension of people 
who probably believe that their idiosyncratic comprehension of ENGLISH is itself universally 
accepted.

Regards,
Jim

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *