APL (langage) - Définition

Lacune d’APL

APL n’a jamais officiellement permis d’indexer un tableau avec autre chose que des valeurs entières. On ne peut pas par exemple y écrire

CAPITALE[⊂'FRANCE']←⊂'PARIS'

ou, pour rester dans le vectoriel,

CAPITALE['FRANCE' 'ESPAGNE' 'ITALIE']←'PARIS' 'MADRID' 'ROME'

ce qui est regrettable, car :

1. une telle extension ne demanderait que très peu de modification de syntaxe, et n'en demanderait aucune des programmes existants
2. tous les langages modernes permettent l'indexation par des chaînes de caractères (soit l'indexation des tableaux comme en PHP qui autorise à écrire $capitale['France']='Paris';, soit via des objets voisins comme les tables de hachage en Perl).
3. Très rares sont les applications où il ne faille pas gérer des accès par symboles plutôt que par numéros. Si APL ne le permet pas de façon immédiate, l’utilisateur se tourne de façon fort naturelle vers d’autres langages répondant mieux à ses besoins.

Il est peu ergonomique de contourner cette lacune au prix de variables supplémentaires, comme par exemple: FRANCE←32 (dès lors, CAPITALE[FRANCE]←⊂"PARIS". Si le pays provient d'une saisie, l'indice peut être retrouvé par "execute" : ⍎"FRANCE" qui rend 32, mais l'application perd en robustesse et on encombre inutilement la table des symboles (APL/X contourne la difficulté par des namespaces).

Une autre manière est de définir un vecteur des noms de pays : PAYS ←'BELGIQUE' 'FRANCE' , l'instruction devenant alors : CAPITALE[PAYS⍳⊂'FRANCE']←⊂'PARIS'

Mais en ce cas, indépendamment de la lisibilité plus faible, le temps d'accès n'a plus le moindre rapport avec un accès direct de type "hash" en Perl ou PHP, surtout si s'il y a des centaines de noms.

Non seulement la lisibilité des programmes n'y gagne rien, mais leur facilité de maintenance s'effondre compte tenu des variables supplémentaires ainsi surajoutées dans le programme.

Quelques opinions

Edsger Dijkstra

« APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums ».

« APL est une erreur, poussée jusqu'à la perfection. C’est le langage de l’avenir pour les techniques de programmation du passé : il crée une nouvelle génération de fainéants du codage».

Roy Keir

« APL is a write-only language. I can write programs in APL, but I can’t read any of them ».
« APL est un langage en écriture seule. Je peux écrire des programmes en APL, mais je ne peux en lire aucun. »

Joel Moses

« APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way - even by adding another diamond - you get an ugly kludge ».

« APL est comme un diamant. Il a une superbe structure cristalline; toutes ses parties sont en correspondance d’une façon uniforme et élégante. Mais si vous essayez d’étendre cette structure de quelque façon que ce soit - même en y ajoutant un autre diamant - vous obtenez un bricolage hideux ». (Allusion au passage d’APL à APL2).

Jacques Arsac

« Je ne recommanderais pas de mettre rapidement APL entre les mains des étudiants ».

APL, langage cryptique ?

Parce qu’il épargne l’usage des indices, APL permet d’écrire de façon concise et rapide des expressions qui seraient bien plus longues avec un langage classique. Pour cette raison, il a été parfois qualifié de langage cryptique. Cet avis est-il fondé ? À vous d’en juger :
Étant donné la compacité et la puissance du langage, certains puristes considéraient que pour être "élégant", un programme APL ne devait pas dépasser une ligne de code. Ces programmes, nommés one-liners dans la revue de l'ACM APL Quote-Quad étaient les ancêtres des deulignes de ce qui sera plus tard Hebdogiciel.