🚀 go-pugleaf

In article <5400@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:
>In article <1940@uoregon.uoregon.edu>, Mark VandeWettering writes:
>> 	Mathematics suffers from exactly the same problems as
>> 	programming languages: ideas get muddled in notation.

>This is silly!  Mathematical formalisms provide you with tools to define
>and reason about your ideas in a precise and unambiguous manner.  

	Perhaps I was overly terse in my answer (which ought to be
	considered a virtue, but what the heck).  

	I agree, mathematical formalisms (notation) provide you with
	tools to concisely express ideas unabiguously.  Programming
	languages serve precisely the same purpose in the world of
	computer programming.  A program is a description of a task,
	written (hopefully) unabiguously.

	Now, the question is:  Is mathematics a good notation for
	describing problems that are typical in computer science?  

	My answer is: no.  

>If someone can't use these tools effectively, the problem is with him, not
>with mathematics.  

	My point is:  the majority of tasks cannot be expressed within a
	strict mathematical framwork.  Try to describe the actions of a
	modern operating system in terms of ANY formalism.  A feat which
	I am sure most will agree is beyond doing.  And the problem
	remains:  Now that I have described this operating system, can I
	actually convert this description into runnable object code for
	some machine.

>Just because I can write unintelligible code in Lisp
>or Prolog doesn't make them poor languages; just because I can flatten
>my thumb with a hammer doesn't make the hammer a bad tool.

	But, a hammer is used for hammering, and not ballet dancing. 

>In article <11526@ut-sally.UUCP>, nather@ut-sally.UUCP (Ed Nather) writes:
>> It's much worse than that.  The basic notation -- and therefore the thought
>> processes it fosters -- describes a system of "eternal truth", usually
>> shown by the equals sign ( = ).  It not only says stuff on each side is
>> equivalent; it implies it always has been, and always will be.  Whatever
>> process change is needed must be artificially imposed from outside.
>
>That depends on the kind of system you're working with.  First order
>predicate logic won't let you reason (directly) about change, but try the
>various temporal, modal and dynamic logics that are around.

	Again, if it can be translated into some sort of executable code
	for a machine, then it probably can be used as a programming
	language.  That doesn't guarantee that it is good at expressing
	tasks in a given problem domain.

	The level of depth of postings in this area (while not
	particularly Saumya Debray) have been very low, indicating
	people who don't have significant depth in the areas of
	compilation and programming languages.  

	I am arguing, not against formalism, or formal methods at all.
	I am arguing that traditional mathematical notations (such as
	predicate logic) are probably inappropriate forms to express
	tasks to a computer.

>Saumya Debray		CS Department, University of Arizona, Tucson
>
>     internet:   debray@arizona.edu
>     uucp:       {allegra, cmcl2, ihnp4} !arizona!debray

mark vandewettering