Adding datatypes to APL 
Author Message
 Adding datatypes to APL

It's understandable that some folks would want to add datatypes to
APL in order, for example, to ease the difficulty of compilation.
And perhaps we can all agree that practical benefits can accrue from
automatic type checking of subroutine parameters.

However, some of the other reasons offered for additional datatypes
are puzzling to me.   I've learned that I can minimize the number of
errors in my code by -minimizing- the number of types.  All I use nowdays
in fortran and Ada are scalars and arrays of 64-bit reals, 4-byte
integers, and 1-byte characters.   Period.

I would of course extend this list if I had applications where it
was necessary or even desirable to do so.  But in my experience,
using more types than described above has led merely to unnecessary
complication, an increase in errors, and a reduction in readability.

Why is the experience of others so different from this?   Or is it,
really?  Might some of the alleged benefits of datatype proliferation
be just a tad illusory?

Jack Rudd



Sun, 09 Mar 1997 12:02:12 GMT  
 Adding datatypes to APL

Quote:
Jack Rudd writes:
>However, some of the other reasons offered for additional datatypes
>are puzzling to me.   I've learned that I can minimize the number of
>errors in my code by -minimizing- the number of types.  All I use nowdays
>in Fortran and Ada are scalars and arrays of 64-bit reals, 4-byte
>integers, and 1-byte characters.   Period.

>I would of course extend this list if I had applications where it
>was necessary or even desirable to do so.  But in my experience,
>using more types than described above has led merely to unnecessary
>complication, an increase in errors, and a reduction in readability.

>Why is the experience of others so different from this?   Or is it,
>really?  Might some of the alleged benefits of datatype proliferation
>be just a tad illusory?

I find this very interesting, given Jack's (enormous) experience in
real-time/simulation applications.  I think, those of us who learned to
think mathematically and abstractly find little need to "copy" the real
world; we finess away irrelevant details and work on an elegant abstraction
instead.  Of course we APLers have the benefit of a notation that is a tool
of thought as well as (scientific) experimentation.  Others are amazed at
our productivity, but they do not understand its source--abstraction.  That
word is understood very differently by mathematicians and computer scientists.

However, it is hard to transfer "abstraction-in-our-head" to somebody else.
It's enough for us to say "array Q of integers", but someone else who wants to
understand the program has to see "a-queue-of-customers-at-time-and-place".
It is easier for _them_ (who have to read and later to maintain the code) if
a "customer" is an encapsulated object with attributes and actions, instead
of subarrays of a bunch of arrays that get passed to a few indistinguished
functions sitting in the workspace.  It may be easier for _us_ to keep using
flat APL and a separate array for each record field--the problem of rearranging
or adding fields is nonexistent!  Instead of declarations that look like
struct { int xxx; char yyy[]; } zzz we use a few constants to index a nested
array, zzz[xxx] instead of zzz.xxx .  What can be simpler or more flexible?
So, yes it's true good old APL is flexible and can do just about anything.

One thing good old APL isn't very good at is user interface.  _We_ don't need
it--we abstract down to the essentials and things are _simple_.  However, to
sell this elegant program to the world, we need to put back all the inessential
details so the customer might have a chance of understanding what we have done.
The SOLUTION is simple, but we need to show them the PROBLEM as well.  And that
can seem very complicated.

So, this user interface beast is the very opposite of what we normally strive
for, namely abstraction.  Realism demands excruciating details, and in good
old APL they are very hard to manage and to control.  Simulation languages
like (object-oriented) SIMULA exist so people can recreate detailed aspects
of an interaction; the "desktop metaphor" user interface is a particular kind
of simulation.




Wed, 12 Mar 1997 00:00:04 GMT  
 Adding datatypes to APL

   ...   I've learned that I can minimize the number of
   errors in my code by -minimizing- the number of types.  All I use nowdays
   in Fortran and Ada are scalars and arrays of 64-bit reals, 4-byte
   integers, and 1-byte characters.   Period.

   ... Why is the experience of others so different from this?   Or is it,
   really?  ...

To decide we need to know what sort of applications you write.  To
give you an example of why that is important: I've never used
floating-point numbers in any application I've been paid to write for
the simple reason that they've never required floating point numbers!



Thu, 13 Mar 1997 15:57:14 GMT  
 Adding datatypes to APL
Jack Rudd:
: However, some of the other reasons offered for additional datatypes
: are puzzling to me.  I've learned that I can minimize the number of
: errors in my code by -minimizing- the number of types.  All I use
: nowdays in Fortran and Ada are scalars and arrays of 64-bit reals,
: 4-byte integers, and 1-byte characters.  Period.

Hmm...

The code in my signature has a constraint that the integers be at
least 1024 bit.

More to the point, in my production work, I use a lot of bit vectors,
and a lot of structures designed to represent bit vectors more
efficiently (after all, why represent directly 400000 consecutive
zeros?).

And then there's text standards that require more than one byte per
character...

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Fri, 14 Mar 1997 03:51:40 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Pervasive DataType to Clarion DataType...

2. DBCS G datatype -> X datatype

3. April 8 APL SIG event - ** added presentation **

4. I-APL, Vanguard APL, and APL.68000

5. Adding Strong Typing without adding to the Language

6. Trying to hire APL and DYALOG APL for Dallas

7. Converting Dyalog APL Multiple Assignments to APL*PLUS

8. Special Functions for APL (and making APL atractive for Science)

9. APL! (APL bang)

10. APL News and I-APL (New World)

11. Whither APL or wither APL ??

12. Whither APL or wither APL ??

 

 
Powered by phpBB® Forum Software