Path: utzoo!attcan!uunet!husc6!think!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!markv
From: markv@uoregon.uoregon.edu (Mark VandeWettering)
Newsgroups: comp.lang.misc
Subject: Re: Modern languages (Slight return)
Message-ID: <2031@uoregon.uoregon.edu>
Date: 21 May 88 01:05:44 GMT
References: <3292@enea.se> <2414@uvacs.CS.VIRGINIA.EDU> <2096@ur-tut.UUCP>
Reply-To: markv@drizzle.UUCP (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
Lines: 51

In article <2096@ur-tut.UUCP> pmjc@tut.cc.rochester.edu.UUCP (Pam Arnold) writes:
>For many situations, Modula-2 is NOT an improvement over C. I am not
>claiming that it is an all-in-all 'better' language. It does, however,
>require the programmer to use the language 'as is', whereas the C
>preprocessor allows - some might say encourages - the programmer to
>virtually remake the language. The original point I was responding to
>had to do with the difficulties in creating and enforcing style rules
>in C environments; the relative merits of C *AS A LANGUAGE* are not
>at issue here.

	I see this criticism of C often.  The preprocessor does indeed
	allow the programmer to "remake" parts of the language.  Doing
	so however is generally considered VERY poor style.

	Uses of the cpp should be:

	1.	Have the benefits of inline code within the syntax of
		having a "function call".  For example,  wouldn't you
		rather see
			max(a,b)
		than
			(a>b)?a:b 
		But we don't wish to have the overhead of a function
		call for something so trivial...  I made extensive use
		of this to do vector operations in a raytracer I wrote.
	
	2.	Replace constants with a symbolic name, to allow
		reconfiguation quickly...
	
	3.	Hide awkward dereferencing of nested pointer structures,
		esp complicated unions....


>One advantage I will claim for Modula-2 (and for Pascal as well): I haven't
>seen any other languages in which algorithms may be expressed with such
>clarity - a terrific plus where maintenance is concerned.

	Sigh, I would say that personal preference is at least as
	important.  Generally, I write some kind of very loose
	psuedocode when I wish to describe an algorithm.

	Also, it is not clear that imperative languages are the best
	language for understanding algorithms.  Because of their
	inherently sequential structure, algorithms developped within a
	framework of imperative languages tend to not parallelize well.

	Functional or logic programming languages are seemingly much more
	"natural" to me, because they separate "what" needs be done from
	"how" it is to be done.

mark vandewettering, more from the desk blotter of...