APL in its ghetto (?) - Programming Languages

FDA <armingaud@noos.fr> wrote in
news:43d19845$0$9384$79c14f64@nan-newsreader-06.noos.net:
[color=blue]
> Randy Macdonald wrote:
>[color=green][color=darkred]
>>>1. Every time you want to execute a program on machines with
>>>different architecture[/color]
>>
>> Are you saying APL is inappropriate where it hasn't been ported?[/color]
>
> Sure. Do you suggest it is *appropriate* where it has not been ported[/color]

Not even as a joke.
[color=blue]
> ? Come back to earth : APL is *not* a mere abstraction, it is a *tool*
> . A tool that you cannot use everywhere you go will be less useful
> that another you can find everywhere.[/color]

"98% of everything is s4t" doesn't make me want to be a microbe.
[color=blue][color=green][color=darkred]
>>>a) the multiple dialects of APL are mostly uncompatible, and
>>>programming in their common subset leaves just an uncomfortable
>>>skeleton (which is why APL multiple and uncompatible extensions and
>>>auxiliary processors were developed in the greatest anarchy)[/color]
>>
>> I don't think the LCD approach ever worked, therefore I've never
>> pursued it.[/color]
>
> Huh ? Do you want an aspirin or something ?[/color]

Actually, trying t interpret that question _is_ giving me a headache.
[color=blue][color=green][color=darkred]
>>>b) APL, contrarily to Perl, Python and others, is not executable
>>>everywhere[/color]
>>
>>
>> See 1) above.[/color]
>
> See my answer too. Would you buy a car that you can only use on half
> on the roads in the country ?[/color]

Last time I looked, it was only legal to drive on one side of the road,
so any car would fit your dsescription.
[color=blue][color=green][color=darkred]
>>>c) If you ask to users of different APLs which one of the dialects
>>>they recommend to choose, every one of them will answer "MINE, of
>>>course !". Do you confirm, Jim Ryan ? Do you confirm too, David
>>>Liebtag ? :-D[/color]
>>
>>
>> I'd say J, then Dyalog, then APL2000, which was what I was paid to
>> develop in.[/color]
>
> See ? :-D[/color]

FDA misinterprets my statement. I was only paid to use APL2000. Dyalog,
I've never used for work, and J is still only a hobby. I've filtered lots
of J ideas into APL systems.
[color=blue][color=green][color=darkred]
>>>I can also assemble my car from nuts, bolts and the like given enough
>>>time and budget; but sorry, I have something else to do, and other
>>>languages, portable on any environment accepting ANCI C, already do
>>>it for me)[/color]
>>
>>
>> APL doesn't force wheel-reinvention[/color]
>
> Except on
>
> 1. Indexation by strings (a quite general need)[/color]

Do you consider a half-day project to be wheel reinvention? Maybe I
should up my dose of aspirin.
[color=blue]
> 2. Regular expressions (a must for every program dealing with text)[/color]

Not "a must" and a quick wrapping of some Perl gives me regexp tools.
[color=blue]
> 3. Spreadsheets I/O[/color]

No more difficult than interacting with any new data protocol. I'm sure
there's a Perl module to do that.
[color=blue]
> 4. OpenGL I/O (GRAPHPAK is still useful, but not up to today's
> expectations anymore, nor using the full potential of 3-D graphic
> cards today as it used beautifully the 3277GA w. a Tektronix screen in
> 1979)[/color]

There is lots of J for that.
[color=blue][color=green]
>> and is more potent then nuts-and-
>> bolts.[/color]
>
> Well, if the less things a language can do, the more potent it is, I
> shall credit you with that point.[/color]

Given that the premise is false, I don't believe anything is being said.
[color=blue][color=green][color=darkred]
>>>3. APL is unsuitable for problems using loops within loops except by
>>>using external product, which makes a catastrophic use of the
>>>µprocessor cache.[/color][/color]
>
> No answer? So we do agree on that.[/color]

Not even as a joke.
[color=blue][color=green][color=darkred]
>>>4. APL is not readable enough to specify certain simple ideas in
>>>simple ways. For instance if I have the F function on vector X, hot
>>>do I define the partial differences DF = F (X + EPSILON K) where
>>>EPSILON K returns a (rho X) vector made of zeros everywhere except in
>>>position K ? The mathematical idea is immediate. Its expression both
>>>in natural and APL languages is difficult. Why ?[/color]
>>
>>
>> Is that true? It seems like a simple adverb. J even has D. to do
>> this.[/color]
>
> I do not know. I want to use one language,[/color]

so, why do you speak English and not Esperanto?

? and in may case I know[color=blue]
> APL2. I do not want to learn half a dozen languages all called "APL"
> and all different, in order to program something I need in three days.[/color]
[color=blue][color=green][color=darkred]
>>>Moreover, I thougt that using an evoluted
>>>language was meant to AVOID assemble programming (which has exactly
>>>*zero* portability).[/color]
>>
>>
>> One can avoid the inevitable, just not completely. And _zero_
>> portability only would happen if the cpu was manufactured in a line
>> with 1 item.[/color]
>
> Portability problems (at least where ASCII or Unicode is used) are
> unexistent[/color]

"unexistent?" doubleplusungood.

with Perl. And what you seem to call "inevitable",[color=blue]
> assembler programming, can be found here. You name it, they very
> pronbably have it, free of charge. Where are the APL public
> open-source libraries ?[/color]

The Waterloo FTP site;
The Toronto toolkit;
[color=blue]
> [url]http://www.cpan.org/[/url][/color]

A good thing about Perl, and the Perl wheels fit well on the APL
speedster. I've called lots of Perl from APL.
[color=blue][color=green][color=darkred]
>>>>call them from APL. Again, the non-APL is tucked onto a corner.
>>>
>>>Are you joking ?
>>>
>>>[url]http://www.google.com/search?num=100&hl=fr&q=%22perl%2Fmysql%22[/url]
>>>[/color]
>>
>>
>> I'll respond to this when I know whart it means...[/color]
>
> OK. Get some education and I shall be glad to resume that conversation
> where we left it off :-)[/color]

I think you're telling me to learn how to breathe; something I've been
doing since JFK was alive. For now, I'll stay off your bridge. Calling
MySQL from Perl is old. Are you presenting it as a new concept?

--
-----------------------------------------------------------------------
|\/| Randy A MacDonald | you can't pay for it,
|/\| [email]ramacd@nbnet.nb.ca[/email] | even if you want to.
BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done..
Natural Born APL'er |
----------------------------------------------------(INTP)----{ gnat }-

fda <armingaud@noos.fr> wrote in news:43d20c22$0$18184$79c14f64@nan-
newsreader-07.noos.net:

[color=blue]
> Please, keep in mind what the subject is. It is *APL* , not me.[/color]

If the kind of remarks you make can start a fire in Iceland (inspire the
remarks I would not expect an extremely reasonable person like Bjorn to
make) I would suggest that you temper them and let the discussion get back
to APL.

-----------------------------------------------------------------------
|\/| Randy A MacDonald | you can't pay for it,
|/\| [email]ramacd@nbnet.nb.ca[/email] | even if you want to.
BSc(Math) UNBF'83 Sapere Aude | APL: If you can say it, it's done..
Natural Born APL'er
----------------------------------------------------(INTP)----{ gnat }-

>>>a) the multiple dialects of APL are mostly uncompatible, and[color=blue][color=green][color=darkred]
>>>programming in their common subset leaves just an uncomfortable
>>>skeleton (which is why APL multiple and uncompatible extensions and
>>>auxiliary processors were developed in the greatest anarchy)[/color][/color][/color]

I think APL implementors all over have done a great job keeping up with
all of the rampant ch-ch-ch-changes in the surrounding environments
over the years. From the IBM 1130 to the 360 to the 370 to DOS to OS
to MVS to the PC, Mac, Burroughs, CDC, Wicat, Data General, Unix,
Linux, Windoze, and so on. The selection of display devices has
changed through the years, the Tektronix 4015 storage tube to the
various flatbed plotters, on to OpenGL. Over the years and systems,
some of these solutions were implemented by []ARBOUT and []ARBIN (ASCII
device support, plotters, even 3270 support, etc.), others by shared
variables (TSIO, GDDM, sending host commands, etc.), others by adding
system commands ([]CMD, []WIN, []WGET, []WPUT, []WCALL), and by
allowing more direct access to host facilities ([]WI, []WC, []NA,
intrinsic functions).

Considering the hardy nature of APL through its nearly 40 years of
history, not to mention changes imposed by the outside, some
incompatibilties through the dialects are excusable. Also, consider
that applications often (but not always) migrated from the mainframe to
the PC to the same or similar family of APL - IBM went to IBM, STSC
went to APL2000, Sharp and some of the others went to Dyalog.

There are numerous examples of little incompatibilites ([]PENCLOSE vs.
[]ML 2, compress reduction, and so on), but they can always be
programmed around. They are a minor nuisance, but a fact of life, and
nothing that could not be taken care of with a good search and replace
facility. Other incompatibilities can be dealt with using a set of
cover functions. For better or worse, AP124 still lives.

In short, although I would agree that there were lots of
incompatibilities, they largely made life more interesting and were not
the end of the world.

To me, the only inexcusable area of inattention was the SQL interface.
IBM and Sharp had their AP127, while on recent Windoze platforms, there
are numerous methods using SQAPL, OBDC, DAO, and ADO. But everywhere
else, one needed to cobble something together. Not that it's bad, but
it may take a while to read millions of records.

Agreed. I always tried to make the best of what I had, which was
invariably good. Whether it was nested vs. boxed arrays, GDDM or one
of at least five versions of AP124, lack of []FMT, []WI or []WC, it
hardly mattered.

Faced with the apparent "come-down" of going from Sharp APL to VSAPL on
VM over 20 years ago, I was depressed for a minute or two. Then I
typed in a search and replace, a formatter, []VI, and []FI functions I
collected over the years and was on my way. While Sharp was clearly
richer in language features, VSAPL had connectivity.