P. Graham a conçu Arc car il considérait que le langage Lisp, qui fête cette années ses 50 ans, avait perdu de sa fraîcheur et de sa pureté originelle, celle qu'il avait lorsqu'il a été conçu par John McCarthy à la fin des années 50, lui-même se basant entre autres sur le lambda-calcul élaboré par A. Church quelques années auparavant.
Arc est un langage à la fois minimaliste, comme Scheme, mais voué à être réellement utilisé, Graham étant un programmeur, pas un théoricien. Avant d'être publié, il a d'ailleurs été utilisé pour réaliser une application web : le forum Hacker News, dont le code source est disponible depuis quelques jours.
Le noyau du langage a été écrit en quelques centaines de lignes de Scheme et peut être très facilement étudié. Le reste du langage, c'est une de ses caractéristiques, a été écrit en Arc lui-même.
NdM : pour ceux qui voudraient retracer l'évolution de l'intelligence artificielle côté États-Unis principalement, n'hésitez pas à (re-)lire Crevier et son livre À la recherche de l'intelligence artificielle.
Peu après la publication des premières versions de Lisp au début des années 60, celui-ci a intéressé nombre de développeurs, plus intéressés cependant par les aspects pratiques que par le côté théorique et conceptuel du langage. Et ainsi, les années suivantes, Lisp a été principalement "patché", voyant des ajouts et modifications apportées surtout pour des raisons pragmatiques ou de performance. Et plusieurs versions concurrentes et incompatibles ont alors foisonné.
Des nombreuses versions publiées aux cours des années par les divers vendeurs d'interpréteurs / compilateurs Lisp, il est sorti une norme, Common Lisp. Ce langage est très complet, trop d'après certains. Il en existe diverses implémentations, dont certaines, libres, offrent d'excellentes performances.
Puis Scheme est paru, suite à un désir de certains de"purifier" ce qui était devenu à leurs yeux une véritable "usine à gaz". Scheme est devenu de fait l'un des langages les plus minimalistes qui soient. Il corrigeait aussi certaines "atrocités" de Common Lisp, tel le symbole NIL, représentant à la fois le booléen faux, la liste vide, l'absence de valeur... Désormais, le booléen #f et la liste vide seraient des concepts différents. Les macros ensuite, une des spécifités de Lisp, très puissantes puisqu'elles permettent de générer du code à la volée, très dangereuses aussi. Scheme propose alors des macros, dites "hygyéniques", plus propres mais aussi moins puissantes.
Paul Graham a alors conçu son Lisp idéal, prenant des idées à Common Lisp comme à Scheme. Il voulait un langage à la fois très pragmatique (son objectif est d'obtenir un outil permettant de développer rapidement des applications) et ayant en même temps un noyau aussi minimaliste que possible. L'objectif est que, hormis les axiomes de base, toutes les fonctionnalités du langage soient écrites dans le langage lui-même. Ainsi, le langage est lui-même sa propre spécification et peut être étendu, voire modifié, par le développeur lui-même, au gré de ses besoins.
Le langage est encore en cours de conception et évolue donc régulièrement, mais il est tout à fait utilisable en l'état. Il propose à l'heure actuelle peu de bibliothèques, hormis une librairie web très intéressant (contenant un serveur web et des fonctionnalités permettant de concevoir des applications web basées sur l'utilisation de continuations).
Une petite communauté d'utilisateurs s'est formée, et elle propose certains patchs, améliorations et extensions (expérimentales) au langage. Enfin, P. Graham publie régulièrement de nouvelles versions de l'interpréteur (3 en un mois !), corrigeant certains bugs ou apportant de nouvelles fonctionnalités. À ce sujet, une polémique avait éclaté lors de la sortie du langage : P.G se vantait que Arc ne gérait que l'ASCII et qu'il ne voulait pas passer de temps à gérer Unicode. Au bout de quelques jours, un patch est paru et Arc est maintenant l'un des langages gérant le mieux UTF-8.
Aller plus loin
- Arc : site officiel (124 clics)
- Le forum d'Arc (24 clics)
- Le site de P. Graham (14 clics)
- Versions expérimentales d'Arc (17 clics)
- Le forum Hacker News, première application Arc (23 clics)
# Le théoricien rêveur et le programmeur pragmatique, quelle blague !
Posté par Yurug . Évalué à 4.
| être réellement utilisé, Graham étant un programmeur, pas un
| théoricien.
Cette phrase a certainement été écrite alors que tu n'étais pas bien réveillé. Il n'y a aucune opposition entre être un programmeur et un théoricien.
Oui, le théoricien est plein de rêves, mais, parmi eux, on trouve aussi celui de voir ses idées "réellement utilisées". Cependant, pas n'importe lesquelles et pas n'importe comment. Le théoricien a le goût pour les choses bien faites et quand il programme, ces productions sont des oeuvres d'art. Comme tout art, pour l'apprécier, il faut se faire les yeux : se délecter de Knuth, s'irradier de Leroy, se perfuser de Turing.
De plus, compte tenu du nombre de pisseurs de C que j'ai rencontrés qui pensent qu'en tunant leur assembleur, ils pourront résoudre un problème NP-complet ou bien encore, que, eux, ils programment sans bug, j'ai du mal à dire qui est le plus proche de la réalité.
Ceci dit, je n'ai rien contre Paul Graham que j'ai pu écouter lors d'une conférence sur les langages fonctionnels (tu sais les langages pour théoricien ;-) ).
[^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague
Posté par Taku . Évalué à 4.
[^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague
Posté par fleny68 . Évalué à 10.
Son lambda calcul est extrêmement pragmatique, pour résoudre la question à laquelle il s'est attaqué. Et ce n'était pas de concevoir un langage de programmation.
[^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague
Posté par sacado . Évalué à 10.
Oui, enfin il y a quand même quelques divergences dans les objectifs visés. Dans le monde Lisp, il y a traditionnellement de véritables scissions entre les adpetes de Common Lisp, qui ont bidouillé leur langage pour l'optimiser à mort, au détriment de la pureté conceptuelle, et ceux de Scheme, qui sont au contraire plus intéressés par la pureté et le minimalisme conceptuel afin d'avoir le langage le plus simple possible, au détriment de l'efficacité. Je n'invente rien : cherche des Schemeurs dans le monde industriel, tu en trouveras peu. Cherche des Common Lispers parmi les théoriciens des langages, tu en verras aussi peu. Le but de Graham est en quelque sorte de trouver un compromis entre ces deux tendances.
Et puis, il n'y avait rien de péjoratif là-derrière, j'ai passé plus de temps dans ma vie à utiliser Scheme ou Smalltalk qu'avec C ou C++. J'ai juste voulu préciser ce point en voyant venir de très loin les commentaires du genre "Ouais, mais d'abord, c'est nul Lisp, encore un délire de chercheur dans sa tour d'ivoire qui fait des langages fonctionnels alors que ça sert à rien dans la réalité". Ce genre de choses.
[^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Gambit-C Scheme, Larceny, Stalin, Bigloo... autant d'implantations de Scheme qui sont rudement efficaces, rapides (et qui ne font pas qu'interpreter, mais aussi qui compilent aussi).
Scheme est le langage ideal pour toutes les demarches de conception de langage, car il y est on ne peut plus simple de creer un langage par dessus, et le monde academique ne s'en prive pas, et l'industrie vient alors utiliser ces produits (je pense a Termite pour Gambit-C, un langage "a la Erlang" sur Scheme). (enfin, la, je crois qu'on est d'accord, mais je suis pas sur d'avoir bien lu ton paragraphe).
Je persiste et je signe: la simplicite' de Scheme ne s'est pas faite au detriment de l'efficacite'.
[^] # Re: Le théoricien rêveur et le programmeur pragmatique, quelle blague
Posté par paul . Évalué à 5.
> Scheme est le langage ideal pour toutes les demarches de conception de langage, car il y est on ne peut plus simple de creer un langage par dessus (...)
vrai, et d'ailleurs c'est le cas pour Arc http://arclanguage.org/install
Pour ceux qui se demandent comment on peut se vanter de ne pas gérer l'UTF8, sachez que P.G. a réussi le tour de force de faire un Arc qui ne le prend pas en charge, alors que mzScheme sait le faire ! Chapeau bas, quand même ...
Mais bon, on en reparlera dans un siècle ( http://www.paulgraham.com/arc.html et http://www.paulgraham.com/arcfaq.html ).
# bootstrapping myself
Posté par Guillaume Gimenez (site web personnel) . Évalué à 6.
Je dirais que c'est une caractéristique minimale pour un langage...
Le C ça puxor, gcc est écrit en brainfuck, c'est bien connu
mes 2 cents
[^] # Re: bootstrapping myself
Posté par Olivier Grisel (site web personnel) . Évalué à 7.
La VM java n'est pas ecrite en java non plus il me semble.
[^] # Re: bootstrapping myself
Posté par Guillaume Gimenez (site web personnel) . Évalué à 0.
voilà le problème
Mais la vrai question est : "Comment puis-je faire, moi aussi, pour faire un programme voué à être réellement utilisé" ???
Celui qui a la réponse me permettra peut-être de gagner aussi 445000 yahoo shares !
mes 45M $
[^] # Re: bootstrapping myself
Posté par Beretta_Vexee . Évalué à 5.
[^] # Re: bootstrapping myself
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: bootstrapping myself
Posté par sacado . Évalué à 6.
L'intérêt, c'est de permettre d'adapter le langage aux problèmes auxquels on se trouve confronté, de A à Z : selon la devise Lispienne, c'est "un langage de programmation programmable".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: bootstrapping myself
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Et bien souvent, le but de la creation d'un langage est d'apporter de nouveaux concepts. Avec le bootstrap, une fois le concept cree, t'as plus qu'a l'utiliser ! Avoue qu'il serait dommage de creer un truc uber cool et de pas pouvoir en profiter dans l'application que tu developpes...
[^] # Re: bootstrapping myself
Posté par Sarcastic . Évalué à 2.
# Différences notables avec scheme ?
Posté par celastus . Évalué à 7.
(set! x 12) => (= x 12)
(set-car! '(1 2) 11) => (= (car '(1 2)) 11)
(let ((x 1) (y 2)) (cons 1 2)) => (with (x 1 y 2) (cons x y))
Ca commence mal ! En scheme le symbole "!" est utilisé pour représenter l'affectation, l'effet de bord, le mal pour celui qui aime les langages fonctionnels, le compromis pour celui qui aime l'efficacité. Une convention veut que toute fonction qui utilise effet de bord se termine pas un point d'exclamation, c'est facile à voir
Utiliser "=" pour l'affectation fait déjà perdre cette convention tellement utile.
En bref, quels sont les principales différences avec scheme, quels sont les avantages de arc par rapport à scheme, quels sont les inconvénients ?
[^] # Re: Différences notables avec scheme ?
Posté par sacado . Évalué à 3.
Pour ce qui est des principales différences :
- Pas de différence entre le symbole nil, la liste vide et le booléen faux : le mal absolu pour les schemeurs (et même pour McCarthy lui-même) ; on aime ou on n'aime pas, il y a des avantages et des inconvénients, l'avantage étant la concision, l'inconvénient étant de prendre une liste vide pour un booléen faux dans un cas où ça n'a rien à voir.
- Macros non hygiéniques : en scheme, les variables définies dans une macro ne peuvent pas entrer en conflit avec celles qui sont définies par l'utilisateur (la capture de variable). C'est une source de bug fréquente et assez difficile à repérer. Mais la capture de variable peut parfois être voulue. Par exemple, arc définit une macro "aif" (anaphoric if) qui affecte à la variable "it" le résultat du test :
(aif (max une-liste-très-longue) (prn it) (prn "vide !"))
équivalent de :
(let it (max une-liste-très-longue) (if it) (prn it) (prn "vide !"))
- Des divergences dans la façon de concevoir les programmes. Par exemple, là où Scheme incite fortement le programmeur à suivre le paradigme fonctionnel, Arc est assez "agnostique" : il y a tout ce qu'il faut pour écrire des algos fonctionnels (map, filter, reduce, tail-recursion, ...) comme des algos procéduraux (notamment beaucoup de types d'itérateurs) ; ce qui explique en partie l'absence de "!" dans les noms des fonctions.
Toutes ces divergences, c'est ce que Graham a retenu de Common Lisp. Mais globalement, je trouve Arc plus proche de Scheme.
Enfin, Arc contient un peu de syntaxe :
(~f x) <=> (not (f x))
(f:g x) <=> (f (g x))
a.b <=> (a b)
a!b <=> (a 'b)
[^] # Re: Différences notables avec scheme ?
Posté par celastus . Évalué à 3.
Les macros ne sont plus hygiéniques, ce qui permet quelques bidouilles (liées elles aussi aux effets de bord) et fait perdre la sûreté des macros (on ne peut plus utiliser une macro dans n'importe quel contexte, l'environnement lexical peut interférer avec elle).
Alors, quel est l'avantage de Arc sur Scheme ? Un peu de sucre syntaxique ? Moi je ne suis pas convaincu du tout du tout
ps : à lire : la vision de l'auteur de l'objet et de l'héritage, et pourquoi Arx n'intègre pas ses notions : http://paulgraham.com/noop.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.