Re: programming language genealogy

[Hans Boldt <boldt@xxxxxxxxxx>]

Steve Richter wrote:
> I just dont agree with rejecting things that work because they dont meet the
> catch all definitions imposed by academics and other blowhards.  The OO
> discussion of a few weeks ago is an example of this.  Programming and design
> methods which Hans correctly defined as "modular programming" work very
> well, yet the OO crowd dismiss them simply because they are not OO.
>
> But at least the OO crowd has their own distinct wording.  Sennet has
> hijacked the generic "programming language" term for her own narrow
> definition.

Jean Sammet is a highly respected expert in the field of programming 
languages, and so her opinions cannot be ignored easily. No one is 
forcing any definition down anyones throat. Based on her studes of 
programming languages, she has come up with a useful definition of 
what a programming language is. Whether or not you or anyone else 
accept that definition is irrelevant for the purposes of that 
definition.

If you *really* think her definition is worth debating, is there any 
activity of writing programs in a programming language not covered 
by her definition? Or does her definition include languages not used 
for computer programming?

> In your first msg on this subject I read:
>
> "a programming language is a set of characters with rules for combining
> them. It has the following characteristics; 1) Machine code knowledge is
> unnecessary, 2) Potential for conversion to other computers, 3) Instruction
> explosion, and 4) problem-oriented notation.".
>
> When did we all vote that languages have to be platform/hardware independent
> and portable? 

Again, no one is forcing anyone to use tools that are platform or 
hardware independent or portable. But many people willingly choose 
to do so since that means their software will have a wider potential 
audience. For example, it is the reason why GNU software is so 
widespread. It is the reason why Apache and Perl (to name a few 
examples) are so popular.

> Seperating the language from the OS adds levels of
> abstraction, which means more details that the programmer has to deal with.

No. In most cases, it means fewer details that the programmer has to 
deal with. To take one example from the Python class library, one 
commonly used function is "os.path.join()", which combines elements 
of a file path name intelligently. Without that, you'd have to code 
special cases for each platform you wanted the program to run on. 
But more to the point, even if your program was intended solely for 
one particular platform, it would still be easier using that 
function than assembling the path name yourself.

> The bottom line is that if languages had useful platform dependent features
> they would be eagerly used by programmers.

But only if your program was only ever intended to be run on one 
particular platform. These days, fewer and fewer shops run 
homogenous system environments.

Cheers! Hans