🚀 go-pugleaf

rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
: Ah, that depends. Consider the lowly pocket calculator. Do you have to
: declare the type of the data you're using? Nope. 
: Now, let's write an algorithm. Lessee here.  "a+b-c". There. That
: wasn't too hard, was it? WIll it work for integers? Yup. Floats?
: Yup. Complex. Yup. 

This is an unusual and mostly irrelevant situation, due primarily to the fact
that mathematics is nice enough to be able to embed the group of integers
in the fields of real and complex numbers and have all arithmetic operations
be compatible and make sense.  This automatic special case conversion is
built in to nearly all compilers for common languages these days as a special
treat for the users.  (Pocket calculators just run everything in base 10
floating point, in any case, right?)

On the other hand, what does it mean to index an array with a complex number?
I don't want this error to go until runtime whence it realizes I made
a typo along time ago when writing it, but the compiler couldn't be sure
that I wouldn't have passed some integers in that part of the array.
(This is of course unsolvable in general because it can't predict what I'm
going to type in as inputs).

: The point being: Why write 3 or more algorithms when one will suffice?
: A fairly reasonable compiler can even do data flow analysis and generate
: optimal code if it can determine (perhaps via an assertion - see above)
: that the arguments are always of type X.

In general you'd have to write different algorithms for different data
types anyway, because most algorithms just plain don't make sense for
all datatypes, and computers can't invent them from scratch---humans have to.
If there's some commonality, then I believe common practice
is to make a new abstract data type with methods to perform the
operations that make sense.  The programmer has to write out the specifics
of implementing those methods anyway, and I find it very unlikely that
a compiler could always figure out how to do it.

: As for code being buggy: Not as likely as if you have to write AND 
: MAINTAIN the same algorithm for many different data types.

There's no such thing as a free lunch. Somebody has to make the code
for all the special cases sometime, somewhere.

: a. Verbosity masks comprehension. If you need comments, add them.

(You wouldn't happen to be an editor of Physical Review Letters, would
 you?  :-) )

Following this suggestion, I think all further articles in this
thread should be encoded using indexes in /usr/words/dict and
passed through compress(1).

More seriously, I think that this attitude is a big mistake.  A "verbose"
language is formalized, explicit and precise commentary.  It may not add
anything that a compiler absolutely _needs_ to make code, but it adds many
things that a human needs to rapidly understand the code when reading, and I
think humans should come first.  I don't think that it should take any
effort for humans to get the literal meaning of any line of code. The
comments ought to be reserved for more abstract issues.  Naturally, if the
language is too primitive, the lack of powerful features may make it
cumbersome, but _not_ impossible, to solve some problems.  It's hard to use,
but in an easy way.  A language with hyper-punctuated, over-notated and just
plain bassackwardsly bizzare syntax engenders headaches every fucking time
anybody tries reads the code.  (C++ programmers: feel a little familiar?)
Only professional mathemeticians truly have the ability and facility to deal
with things like this without semi-herculean effort, and mathemeticians are
about as far away from "real life" as it gets.  No insult intended, but it's
just not the thing for "the rest of us".

I'm also of the opinion that humans have biological specialization for
certain kinds of language, and by language I emphatically *dont* mean
everything that's turing equivalent.

Do you not think that, say, Italian is easier to learn than Classical
Chinese for native English speakers?  

As an extreme example, why is there no natural language in which 'speakers'
compose sentences by uttering large integers, whose factors
index the meanings of each phrase?  (Gee I wonder what the crossword
puzzle would be like?  And Jeopardy...
"I'll take 'Dirty Limericks' for $1000, Alex."
"9348186596359757225381328109257040201107"
"What is 22222223 * 111111113 * 22222253 * 111111163 * 69 * 22222223 ?"
(Are non-prime factors double entendres?)
.......
In the news today, a supercomputer called a Connection Machine has found the
largest product of two large primes that's also divisible by the sum of its
digits after adding one.  According to Professor Snigglefaut of Harvard's
English department, the quality of the computer-generated poetry may even
exceed Shakespeare's and Von Neumann's.... )  :-)

signature:
42