FP in a larger scale (Re: Comparison of functional languages) 
Author Message
 FP in a larger scale (Re: Comparison of functional languages)

On Tue, 16 Mar 1999 19:50:35 -0800, Nick Kallen

Quote:

>But the question then is: are array comprehensions good enough so that we
>don't need loops?

*Never* need loops?  Probably not.

Good style in APL tends to be considered to involve writing programs so
that they never use loops.  

APL programmers often go to great lengths to avoid the use of loops, and
the "purists" would probably argue that having good array manipulations
is indeed good enough to make loops unnecessary.

I would suggest otherwise, that having a good set of array manipulators
is *USEFUL* in that it makes it possible to make operations that are
naturally represented as array operators work better/faster.

And suggest the heresy that sometimes it may be more trouble than it's
worth to try to force operations into an "array style."

If you can get a good chunk of calculation done with improved efficiency
and robustness using array calculations, then "you've won."  

There may be a few calculations left where an array representation
doesn't help, and the best you can do is loop over the structure to do
whatever bizarre thing needs doing; in that case, looping with a counter
may just plain be "the only way."

My thinking is that a language that allows doing both of these things is
better for complex tasks than one that forces you into one or the other
"pigeonhole."

Compare the APL:

B .= A x 2 + 1

to the C:

for (i = 0; i < SIZEOFA ; i++)
   B[i] = A[i] * 2 + 1;

The APL representation can very probably be optimized better than the C
representation.

If I'm trying to build a complex pointer-based data structure, a
C-oriented representation may well work out better.

It's kind of nice to have the ability to use both abstractions.

--
"What is the purpose of a person acquiring perfect French pronunciation
if they have nothing of value to say in any language?"  -- Walter Ong



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:

>On Tue, 16 Mar 1999 19:50:35 -0800, Nick Kallen

>>But the question then is: are array comprehensions good enough so that we
>>don't need loops?

>*Never* need loops?  Probably not.

Inded, i would go further. There are some problems which are so inherently lopy
that they can not be solved without an explicit loop (or a use of the each
operator or of recursion which amounts to an explicit loop)

Computing a cryptographic message digest, or even a CRC, is one exampole of
such a problem.  In general, any algorithm in which later stages depend on
earlier stages is inherently loopy unless it can be described as a reduction or
a scan on an array (or by some similar operator).

Quote:
>Good style in APL tends to be considered to involve writing programs so
>that they never use loops.  

I would say that good style in APL involves not writing unneeded loops, and
using array orientation whenever it is a reasonable tool for the job.

I write APL code for a living, and i write plenty of loops, although i avoid
them when reasonably possible.

Quote:
>APL programmers often go to great lengths to avoid the use of loops, and
>the "purists" would probably argue that having good array manipulations
>is indeed good enough to make loops unnecessary.

I have seen the code produced by this mindset, and in many cases I don't think
much of it.

Quote:
>I would suggest otherwise, that having a good set of array manipulators
>is *USEFUL* in that it makes it possible to make operations that are
>naturally represented as array operators work better/faster.

>And suggest the heresy that sometimes it may be more trouble than it's
>worth to try to force operations into an "array style."

I agree wholeheartedly. I also agree with the remainder of the post, which i do
not bother to quote as I have nothing new to add.

                 -David E. Siegel



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:

> Good style in APL tends to be considered to involve writing programs so
> that they never use loops.

This seems to be a common misconception.  Over the years a number ofarticles
have been published in APL Quote Quad and other places showing
that APL code involving loops often executes much more quickly than
code cleverly constructed to avoid looping.  It depends on how efficiently
a given APL interpreter (or compiler) implements various operations.

Another consideration is how easy it is to parallelize code written in
looping and nonlooping forms if you want to execute the code on a
parallel processor.

Quote:
> There may be a few calculations left where an array representation
> doesn't help, and the best you can do is loop over the structure to do
> whatever bizarre thing needs doing; in that case, looping with a counter
> may just plain be "the only way."

> My thinking is that a language that allows doing both of these things is
> better for complex tasks than one that forces you into one or the other
> "pigeonhole."

True.  This is why there has been a great deal of discussion aboutintroducing
control structures into APL.  The APL+ version of APL,
sold by APL2000, inmplements control structures by taking advantage
of a "syntax hole".  I dislike the particular way in which these control
structures are implemented (I don't like the idea of introducing
keywords into APL; Rob Willhoft came up with a better syntax in
an article in one of the APL Conference Proceedings), but the
functionality is clearly useful.

--- Brian



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:
>True.  This is why there has been a great deal of discussion aboutintroducing
>control structures into APL.  The APL+ version of APL,
>sold by APL2000, inmplements control structures by taking advantage
>of a "syntax hole".  I dislike the particular way in which these control
>structures are implemented (I don't like the idea of introducing
>keywords into APL; Rob Willhoft came up with a better syntax in
>an article in one of the APL Conference Proceedings), but the
>functionality is clearly useful.

>--- Brian

Recent versions of Dyalog APL implement a similar set of control structures,
although there are some differences in teh way edge conditions are handled and
the effects on execution speed (APL+ uses the control structure to do
particular optimizations; I think, but I am not sure, that Dyalog generates the
same internal code as if a set of APL branches had been coded.)

As for the question of keywords, what are quad-functions and vars but keywords?
What is the objection to the keyword form of control structures?  None of the
"pure APL" foms which i have seen proposes appeared to me to be as easy for a
working production programmer to use, nor to offer any particular advantage to
the language implementor.

                 -David E. Siegel



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)
:
:> Good style in APL tends to be considered to involve writing programs so
:> that they never use loops.
:
:This seems to be a common misconception.  Over the years a number
ofarticles
:have been published in APL Quote Quad and other places showing
:that APL code involving loops often executes much more quickly than
:code cleverly constructed to avoid looping.  It depends on how efficiently
:a given APL interpreter (or compiler) implements various operations.
:[...]

If this is documented, i guess it must be a fact. But my experience is
quite different, i have found a clever statement of parallel execution
ALWAYS to be faster than any loop. Typically 2-3 times faster compared to
looping up to ca 10 times, and a lot more faster compared to code that
loops 10E2, 3, 4... times. Of course, looping will be faster than
"stupidly" constructed statements of parallel execution, made only to avoid
"ugly" looping.

That is not a disapproval of loops. I wouldn't believe that anyone of us
longer considers looping in APL a violation of the etiquette. I do use
looping a lot, mostly to repeat statements that already contain parallel
execution code, and which could/should not be written with more complexity
because of painful maintainability.

But i would say the instant result comes when you use optimized parallel
execution and ALSO the best possible primitives and variable structure for
the task in question.
/ Tomas



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)
First, define carefully what's a loop and what's an iteration ...
Quote:



>:
>:> Good style in APL tends to be considered to involve writing programs so
>:> that they never use loops.



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:

> On Tue, 16 Mar 1999 19:50:35 -0800, Nick Kallen

> >But the question then is: are array comprehensions good enough so that we
> >don't need loops?

> *Never* need loops?  Probably not.

> Good style in APL tends to be considered to involve writing programs so
> that they never use loops.  

> APL programmers often go to great lengths to avoid the use of loops, and
> the "purists" would probably argue that having good array manipulations
> is indeed good enough to make loops unnecessary.

> I would suggest otherwise, that having a good set of array manipulators
> is *USEFUL* in that it makes it possible to make operations that are
> naturally represented as array operators work better/faster.

> And suggest the heresy that sometimes it may be more trouble than it's
> worth to try to force operations into an "array style."

Certainly. Time simulation is an easy area - simulations can easily
involve memory and hysteresis, in which case it seems pretty pointless
to try and determine the solution at all time points
simultaneously. And then sometimes you want to run open ended, only
terminating via some event.

--
Sam Sirlin



Mon, 03 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:


> > Good style in APL tends to be considered to involve writing programs so
> > that they never use loops.

> This seems to be a common misconception.  Over the years a number ofarticles
> have been published in APL Quote Quad and other places showing
> that APL code involving loops often executes much more quickly than
> code cleverly constructed to avoid looping.  It depends on how efficiently
> a given APL interpreter (or compiler) implements various operations.
> ...

I know I'm going to get shot down in flames for saying this, but if
run-time efficiency is your ultimate goal, you should probably not be
using APL. Assembler might be better, or a compiled language with a
decent optimiser.

To me APL is about development speed and maintainability of code first,
run-time efficiency a secondary consideration. As such, loops are fine
where the impact on performance is not too horrendous and code clarity
is improved.

Quote:
> ...This is why there has been a great deal of discussion aboutintroducing
> control structures into APL.  The APL+ version of APL,
> sold by APL2000, inmplements control structures by taking advantage
> of a "syntax hole".  I dislike the particular way in which these control
> structures are implemented (I don't like the idea of introducing
> keywords into APL; Rob Willhoft came up with a better syntax in
> an article in one of the APL Conference Proceedings), but the
> functionality is clearly useful.
> ...

At first, as an "APL purist" I did not like these extensions, just as I
saw little use for coloured editors (had them for VS/APL: current line
was red, others green...). However, I've gotten used to these things and
now wouldn't be without them.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GO/! d- s++:+ a+ C++(++++) US+++$ P+ L+ E--- W++ N++ w--- O- V- PS+
PE- Y+ PGP- t+ 5++ X+ R* tv+ b+ DI++ D G e(*) h++/-- r+++ y?
------END GEEK CODE BLOCK------

-----------------------------------------------------
Bob Hoekstra:   APL & Unix Consultant
Tele:           +44 (0)1483 771028
                http://www.khamsin.demon.co.uk

-----------------------------------------------------



Tue, 04 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:


> >On Tue, 16 Mar 1999 19:50:35 -0800, Nick Kallen

> >>But the question then is: are array comprehensions good enough so that we
> >>don't need loops?

> >*Never* need loops?  Probably not.

> Inded, i would go further. There are some problems which are so inherently lopy
> that they can not be solved without an explicit loop (or a use of the each
> operator or of recursion which amounts to an explicit loop)

I don't see that the looping that occurs in 'f each' is any
more "explicit" than the looping which occurs in 'f/' or 'f\'
or'{jot}.f' or 'f.g'.  And while recursion is (sometimes)
explicit it isn't looping, not even when it has the same
effect (and not even when the language _processor_ converts
it to looping via, eg, tail-recursion limination).  Syntax
counts, as does name scope.

...

Quote:
> >I would suggest ... that having a good set of array manipulators
> >is *USEFUL* in that it makes it possible to make operations that are
> >naturally represented as array operators work better/faster.

> >And suggest the heresy that sometimes it may be more trouble than it's
> >worth to try to force operations into an "array style."

Defined operators can often be used to separate the
looping/iteration/recursion from the computation.  Ed
Eusebi had papers on this idea in the Proceedings of
the Seattle conference (APL Quote Quad V. 15 No. 4,
June 1985):  "Operators for Program Control", pp 181-189,
and "Operators for Recursion", pp 190-194.

//  M



Tue, 04 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:

> I know I'm going to get shot down in flames for saying this, but if
> run-time efficiency is your ultimate goal, you should probably not be
> using APL.

Not neccesarily.  A group of students was assigned to write a sort
routine.  After spending considerable effort on the project, they
compared timings on theirs (written in C) to the APL2 sort.  They lost.

In some cases, you are probably right but not all.  It depands on the
skill level of the programmers involved, the nature of the problem and
the time and effort to be spent.

Ted



Tue, 04 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:


> > I know I'm going to get shot down in flames for saying this, but if
> > run-time efficiency is your ultimate goal, you should probably not be
> > using APL.

> Not neccesarily.  A group of students was assigned to write a sort
> routine.  After spending considerable effort on the project, they
> compared timings on theirs (written in C) to the APL2 sort.  They lost.

> In some cases, you are probably right but not all.  It depands on the
> skill level of the programmers involved, the nature of the problem and
> the time and effort to be spent.

> Ted

What algorithm did the `students' use?


Tue, 04 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)

Quote:

> What algorithm did the `students' use?

Several but this was some years ago and I don't recall which ones.  A
binary sort/merge was one.

Ted



Wed, 05 Sep 2001 03:00:00 GMT  
 FP in a larger scale (Re: Comparison of functional languages)
:>
:>
:> > I know I'm going to get shot down in flames for saying this, but if
:> > run-time efficiency is your ultimate goal, you should probably not be
:> > using APL.
:>
:> Not neccesarily.  A group of students was assigned to write a sort
:> routine.  After spending considerable effort on the project, they
:> compared timings on theirs (written in C) to the APL2 sort.  They lost.
:>
:> In some cases, you are probably right but not all.  It depands on the
:> skill level of the programmers involved, the nature of the problem and
:> the time and effort to be spent.
:>
:> Ted
:>
:
:What algorithm did the `students' use?

Perhaps they used Bubblesort (was that the name?). For a matrix of strings:

1.Compare row n with row n+1 (using a loop that compares character by
character);
2.If row n comes alphabetically after row n+1; switch the two rows;
3.Increase n until it equals [nr of rows]-1; repeat comparison;
4.Repeat it all [nr of rows] times. At least :-).
5.Get ready to wait.

Once i discussed the speed of assembler routines with a friend, a "user". I
told him how extremely fast assembler is, and how much work is required to
write a working assembler routine. Then he called me very early the next
morning (too early:-). He said: "Tomas!!! I have written an assembler
program. It doesn't really do anything, but it's *extremely* fast!"

At another occasion i was asked to re-write a mail system. I found some
rows of code that read the "scancode" from the keyboard, and if there was
no key pressed, it read the scancode again. However, there was a "#DL 1" in
the loop. I told the coder that i have removed the #DL 1, and asked him why
he had put a delay of one second in the loop. He answered: "[with somewhat
angry voice] I'm not in the habit of having the processor to run at a
totally senseless speed while nothing happens".

There are lots of things to consider, when determining what makes sense...
/ Tomas



Wed, 05 Sep 2001 03:00:00 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. FP in a larger scale (Re: Comparison of functional languages)

2. DBC in functional languages [Was: comparison OOP and FP]

3. Speed of FP languages, prospects (was Re: Benchmarking Lazy Functional Languages)

4. Comparison of various functional languages?

5. Comparison of functional languages

6. Prevent Scaling of objects/indicators on FP

7. multi-language vs mono-language, 1/2 (was: Me and FP &c)

8. multi-language vs mono-language, 2/2 (was: Me and FP &c)

9. comparison OOP and FP (and how to put them together) was: Re: need help with haskell

10. non-functional syntax in a mostly functional language

11. language advocacy and language comparison

12. commerce, fp, Open Source Software(tm) (was: Re: Functional , compilers in the mainstream)

 

 
Powered by phpBB® Forum Software