Re: Programming skills required by mathematicians?

In article
<42b587d9-1e0c-4f4a-949f-e695d2923096@[EMAIL PROTECTED]
>,
Marshall  <marshall.spight@[EMAIL PROTECTED]
> wrote:
>On Jun 25, 12:23 pm, hru...@[EMAIL PROTECTED]
 (Herman Rubin) wrote:
>> In article
<fd0e8605-ee29-4365-a130-e0baedb3d...@[EMAIL PROTECTED]
>,
>> translogi  <wilem...@[EMAIL PROTECTED]
> wrote:

>> >I am still a favourite of old fa****oned Q basic.
>> >I think it is good to know the basics in a simple way.
>> >It maybe slower than C++ but it is easy.
>> >And you can make  very sophisticated programs with it.

>> [...]
>> Computers are essentially a fixed program, the
>> hardware, which then has a small initialized amount
>> of software, quite variable, which enables it to
>> try to do what the user wants.  Keep this in mind;
>> understand what the hardware can do, which is
>> different on different machines, and think in those
>> terms, not the current poorly designed languages.

>Not quite sure what you're saying here. If it's a
>warning against basic, then sure. But thinking
>in terms of specific machine architecture? That's
>virtually never a good idea. Even if you're using
>something antique like plain C, you're still a lot
>better off than you are with assembly or machine
>language. What is "the current poorly designed
>languages" supposed to refer to?

The current languages do not allow the user to have
full use of the power of the computer; in fact, this
has led to declines in the quality of hardware as
well.  A user who thinks that absolute value is as
expensive as a transcendental function will be making
a big mistake, and they are not taught that.  Also,
the tricks around gotos slow down the computer; the
computer uses gotos, and the current procedures cause
many oft repeated steps take many times as long because
of the need to use variables instead of keeping the
state of the program just in instruction locations.

Multiple precision arithmetic is difficult because of
the hidden bit in  floating point numbers and forced
normalization.  Good integer arithmetic does not exist.
One needs to be able to put a list of variables before
the equals sign in a replacement statement; the ways
around it are inefficient.

I believe that one can have a weakly typed with type
override assembler with highly overloaded operators
which will take less than twice the code length as
a HLL; the optimization should be done at this stage,
not at compilation time.  There should also be a decent
way of writing macros, with macro "name" not being the
first argument in using it.  For example, one might 
define subtraction for a new type; in that case, one
would define the =- macro to get x=y-z.  BTW, this is
how the assembler instruction should look; no conversion,
and type override available.  The user should know when
to "mix types"; it is not machine independent, but it is
im****tant.  Instead of trying to make things foolproof,
make it powerful; as Einstein said, nature is winning in
producing better fools.

There is more, but this should be an indication.
-- 
This address is for information only.  I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@[EMAIL PROTECTED]
         Phone: (765)494-6054   FAX: (765)494-0558