From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,901cf02e3fdf0c96
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder3.cambrium.nl!feed.tweaknews.nl!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.freenet.de!feeder2.ecngs.de!ecngs!feeder.ecngs.de!npeer.de.kpn-eurorings.net!npeer1.kpn.DE!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 18 Jul 2007 10:17:58 +0200
From: Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de>
Organization: #
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: SI Units - has Ada missed the boat?
References: <1183907619.564482.240470@w3g2000hsg.googlegroups.com>
 <1184742672.910297.54010@o11g2000prd.googlegroups.com>
In-Reply-To: <1184742672.910297.54010@o11g2000prd.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <469dcbd2$0$21009$9b4e6d93@newsspool1.arcor-online.net>
NNTP-Posting-Date: 18 Jul 2007 10:14:10 CEST
NNTP-Posting-Host: 3129c5ed.newsspool1.arcor-online.net
X-Trace: 
 DXC=O^GH>>e<bC]U6b:FjPaGjQic==]BZ:af^4Fo<]lROoRQFl8W>\BH3YRXYdM8MY6K<TA:ho7QcPOVSJhi1O5AS2N]lNnQXRe\PgY
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:16507
Date: 2007-07-18T10:14:10+02:00
List-Id: <comp.lang.ada>

kevin cline wrote:

> This is rather unwieldy since Java does not allow operator
> overloading.  Who wants to read code like:
> 
>    time_aloft = sqrt(height.times(2).divide(g))

I'd like to know why this programmer's expression of a formula
for use by a computer is inferior, assuming the typical alternative
would be[*]

     time_aloft = sqrt((2 * height) / g))

I see that if you have very few operators in a program,
the chance of a human misreading a possibly ambiguous operator is
fairly low, understanding rather than misunderstanding the formula
might be easy.
So there is some amount of correspondence between uses of {punctuation
characters and symbols} in physics text on the one side and uses of
{punctuation characters} in programming text on the other side.
E.g., "/" usually means division in either case, even when the
semantics do not match 100%.

But in general, will it help to mimic a specific math expression
in larger programs, using (sub-)domain specific symbols?[**]
When I have a package for motion operators and then another operators
package for unrelated uses (since this is about overloading, there
are at least two). I can make one group of operators visible locally.
But is the effect really superior enough in the long run to
warrant all kinds of symbol overloadings? Or is it just the
desire of programmers for some magic spells (possibly improving
productivity due to an increased fun factor)?

I like the idea of concise formulae in a program when the symbols
are well understood and/or stand out (including some Unicode symbols,
at last!)

Imagine having to switch programming languages every now and then.
"Wait, what does '!' stand for, uuh, yesterday I was using C++---no
it was Fortran 90, that was the day before yesterday. Now this is ML,
not APL, ehr, '!' means ..."


 -- Georg 

 [*] assuming that a physicist, being used to the mathematical
expression, will assume commutativity of "*", which might or might
not be a good idea.

 [**] Indeed, typesetting systems have made some texts suffer from what
is criticised as symbolitis, making them more difficult to understand.