Au hasard de la promenade dans les nouvelles fonctionnalités de Lion,
trois liens qui me semblent intéressants et méritent sans doute
approfondissement :
1/ le prix de la version serveur (sans limitations ?)
<http://www.apple.com/fr/macosx/server/>
2/ le Per-user screen sharing qui romprait avec l'utilisation de Mac OSX
uniquement "en avant plan" (si je comprends bien)
<http://www.apple.com/fr/macosx/whats-new/features.html#screensharing>
3/ les solutions de restauration sur partition dédiée ou depuis un
backup TimeMachine (et pas seulement en ligne)
<http://www.apple.com/fr/macosx/whats-new/features.html#internetrestore>
(pour répondre aux inquiétudes de notre ami)
Il semble qu'il y ait pas mal d'autres bonnes choses à découvrir
Le 29/06/11 20:42, FiLH a écrit : >> >> Peut-être, mais entre une syntaxe où chaque tâche gérée par crond >> consiste en une unique ligne dans un fichier commun, et une syntaxe qui >> réclame un fichier de 30 lignes par tâche, mon choix est vite fait. >> D'autant plus que dans le premier cas la syntaxe est commune à tous les >> unix. > > Oui mais bon ça ne marche pas bien pour tous les cas modernes. > > Par exemple comment déclarer une tache cron qui dépendrait du lancement > d'un autre service. > > J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : > faire les tâches de maintenances du serveur n'est utile que si le > serveur est actif sur la machine. > > Ce sont des cas qui n'existaient pas il y a 10 ans... > > Donc oui c'était plus simple avant... mais on faisait tellement moins de > choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des cascades d'outils simples et canoniques, ce qui correspond à la philosophie unix depuis ses débuts.
Et avec des bouts de codes localisés non génériques et non standardisés :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
pehache <pehache.7@gmail.com> wrote:
Le 29/06/11 20:42, FiLH a écrit :
>>
>> Peut-être, mais entre une syntaxe où chaque tâche gérée par crond
>> consiste en une unique ligne dans un fichier commun, et une syntaxe qui
>> réclame un fichier de 30 lignes par tâche, mon choix est vite fait.
>> D'autant plus que dans le premier cas la syntaxe est commune à tous les
>> unix.
>
> Oui mais bon ça ne marche pas bien pour tous les cas modernes.
>
> Par exemple comment déclarer une tache cron qui dépendrait du lancement
> d'un autre service.
>
> J'ai par exemple le cas d'un cluster actif/passif de serveurs webs :
> faire les tâches de maintenances du serveur n'est utile que si le
> serveur est actif sur la machine.
>
> Ce sont des cas qui n'existaient pas il y a 10 ans...
>
> Donc oui c'était plus simple avant... mais on faisait tellement moins de
> choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des
cascades d'outils simples et canoniques, ce qui correspond à la
philosophie unix depuis ses débuts.
Et avec des bouts de codes localisés non génériques et non standardisés
:)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le 29/06/11 20:42, FiLH a écrit : >> >> Peut-être, mais entre une syntaxe où chaque tâche gérée par crond >> consiste en une unique ligne dans un fichier commun, et une syntaxe qui >> réclame un fichier de 30 lignes par tâche, mon choix est vite fait. >> D'autant plus que dans le premier cas la syntaxe est commune à tous les >> unix. > > Oui mais bon ça ne marche pas bien pour tous les cas modernes. > > Par exemple comment déclarer une tache cron qui dépendrait du lancement > d'un autre service. > > J'ai par exemple le cas d'un cluster actif/passif de serveurs webs : > faire les tâches de maintenances du serveur n'est utile que si le > serveur est actif sur la machine. > > Ce sont des cas qui n'existaient pas il y a 10 ans... > > Donc oui c'était plus simple avant... mais on faisait tellement moins de > choses avant...
C'est faux. Simplement, les choses complexes se faisaient avec des cascades d'outils simples et canoniques, ce qui correspond à la philosophie unix depuis ses débuts.
Et avec des bouts de codes localisés non génériques et non standardisés :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
La Bete des Vosges (Francis Chartier) wrote:
Le Wed, 29 Jun 2011 20:42:31 +0200, FiLH a écrit :
> Par exemple comment déclarer une tache cron qui dépendrait du lancement > d'un autre service.
Ben en faisant des tests sur l'existence de locks ou de process, non ?
Et je devrais réécrire ces tests pour chacun de mes crons ? Alors que je pourrais avoir un système bien foutu qui avec un bon fichier de conf aurait cette fonctionnalité de base ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
La Bete des Vosges (Francis Chartier) <francis@bete-des-vosges.org>
wrote:
Le Wed, 29 Jun 2011 20:42:31 +0200, FiLH a écrit :
> Par exemple comment déclarer une tache cron qui dépendrait du lancement
> d'un autre service.
Ben en faisant des tests sur l'existence de locks ou de process, non ?
Et je devrais réécrire ces tests pour chacun de mes crons ?
Alors que je pourrais avoir un système bien foutu qui avec un bon
fichier de conf aurait cette fonctionnalité de base ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Le Wed, 29 Jun 2011 20:42:31 +0200, FiLH a écrit :
> Par exemple comment déclarer une tache cron qui dépendrait du lancement > d'un autre service.
Ben en faisant des tests sur l'existence de locks ou de process, non ?
Et je devrais réécrire ces tests pour chacun de mes crons ? Alors que je pourrais avoir un système bien foutu qui avec un bon fichier de conf aurait cette fonctionnalité de base ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
filh
J.P wrote:
In article <1k3o1f6.2wub68pz1204N%, (Olivier Marti) wrote:
> J.P wrote: > > > > > Ça existe encore les informaticiens qui commentent leurs programmes ou > > leurs scripts :-) > > Alors la je pouffe !!! Les vieux informaticiens voudraient nous faire > croire qu'autrefois on commentait plus que maintenant .....
Euhhhhhhhh! non :-) Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des noms de fonctions et de variables qui sont humainement et simplement compréhensibles.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
J.P <jpp@gmail.com> wrote:
In article <1k3o1f6.2wub68pz1204N%olivier.marti@ensta.org>,
olivier.marti@ensta.org (Olivier Marti) wrote:
> J.P <jpp@gmail.com> wrote:
>
> >
> > Ça existe encore les informaticiens qui commentent leurs programmes ou
> > leurs scripts :-)
>
> Alors la je pouffe !!! Les vieux informaticiens voudraient nous faire
> croire qu'autrefois on commentait plus que maintenant .....
Euhhhhhhhh! non :-)
Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les
commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des
noms de fonctions et de variables qui sont humainement et simplement
compréhensibles.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
In article <1k3o1f6.2wub68pz1204N%, (Olivier Marti) wrote:
> J.P wrote: > > > > > Ça existe encore les informaticiens qui commentent leurs programmes ou > > leurs scripts :-) > > Alors la je pouffe !!! Les vieux informaticiens voudraient nous faire > croire qu'autrefois on commentait plus que maintenant .....
Euhhhhhhhh! non :-) Ne pas commenter, c'était la sécurité de l'emploi.
Commenter ne sert à rien : au bout de deux ans, le code a évolué, les commentaires non.
La seule bonne façon de faire : écrire du code auto-commenté , avoir des noms de fonctions et de variables qui sont humainement et simplement compréhensibles.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
xavier
FiLH wrote:
qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années 50/60 :)
Horresco referens !
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
FiLH <filh@filh.orgie> wrote:
qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années
50/60 :)
Horresco referens !
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
qui n'a rien de nouveau, cela s'appelle du lisp est ça date des années 50/60 :)
Horresco referens !
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
xavier
FiLH wrote:
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent d'exprimer pas mal de choses, avec des sections imbriquées, tout en restant lisibles, et SURTOUT grep/sed-able !
Entre autres, les plist d'Apple regorgent de BLOBs absolument incompréhensibles, et qui pourraient certainement être évités.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML, là où un simple script shell (avec éventuellement un DFA dedans pour les fichiers structurés) pourrait faire l'affaire. Sans parler des plist binaires, qu'il faut convertir avant d'obtenir du xml, technique qui relève de la shadokerie la plus totale.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
FiLH <filh@filh.orgie> wrote:
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à
chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins
hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent
d'exprimer pas mal de choses, avec des sections imbriquées, tout en
restant lisibles, et SURTOUT grep/sed-able !
Entre autres, les plist d'Apple regorgent de BLOBs absolument
incompréhensibles, et qui pourraient certainement être évités.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML,
là où un simple script shell (avec éventuellement un DFA dedans pour les
fichiers structurés) pourrait faire l'affaire. Sans parler des plist
binaires, qu'il faut convertir avant d'obtenir du xml, technique qui
relève de la shadokerie la plus totale.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
Les fichers texte évolués de config de par ex. de BIND, permettent d'exprimer pas mal de choses, avec des sections imbriquées, tout en restant lisibles, et SURTOUT grep/sed-able !
Entre autres, les plist d'Apple regorgent de BLOBs absolument incompréhensibles, et qui pourraient certainement être évités.
Ca me gave d'être obigé d'écrire un outil en Perl avec les modules XML, là où un simple script shell (avec éventuellement un DFA dedans pour les fichiers structurés) pourrait faire l'affaire. Sans parler des plist binaires, qu'il faut convertir avant d'obtenir du xml, technique qui relève de la shadokerie la plus totale.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Erwan David
(FiLH) écrivait :
Philippe Manet wrote:
FiLH wrote:
> > Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme > > parser. > > Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en > rester au niveau syntaxique.
d'un autre coté, c'est difficile de décrire une ontologie un peu raffinée avec un fichier à plat...
Disons que le pb dans ce cas c'est qu'on va à chaque fois inventer une nouvelle syntaxe pour chaque outil quand le xml au contraire permet d'avoir une syntaxe unique, vérifiable, et implémentée sous forme de bibliothèque dans tous les langages.
Foutaise. Une syntaxe unique ? Non pusique ça cga-hange à chaque schéma/DTD...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
filh@filh.orgie (FiLH) écrivait :
Philippe Manet <yapu@invivo.edu> wrote:
FiLH <filh@filh.orgie> wrote:
> > Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme
> > parser.
>
> Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en
> rester au niveau syntaxique.
d'un autre coté, c'est difficile de décrire une ontologie un peu
raffinée avec un fichier à plat...
Disons que le pb dans ce cas c'est qu'on va à chaque fois inventer une
nouvelle syntaxe pour chaque outil quand le xml au contraire permet
d'avoir une syntaxe unique, vérifiable, et implémentée sous forme de
bibliothèque dans tous les langages.
Foutaise. Une syntaxe unique ? Non pusique ça cga-hange à chaque
schéma/DTD...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
> > Juste de pas se fatiguer à réfléchir et d'utuiliser un bloartware comme > > parser. > > Ben.. je préfère réfléchir à des concepts plus amusants qu'à devoir en > rester au niveau syntaxique.
d'un autre coté, c'est difficile de décrire une ontologie un peu raffinée avec un fichier à plat...
Disons que le pb dans ce cas c'est qu'on va à chaque fois inventer une nouvelle syntaxe pour chaque outil quand le xml au contraire permet d'avoir une syntaxe unique, vérifiable, et implémentée sous forme de bibliothèque dans tous les langages.
Foutaise. Une syntaxe unique ? Non pusique ça cga-hange à chaque schéma/DTD...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
yapu
pehache wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement... c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite... -- Philippe Manet qui se souvient avec émotion du cout de son premier disque de 50 MO
pehache <pehache.7@gmail.com> wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement
10% (ce qui est le cas des plist), on peut raisonnement se demander si
XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne
peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des
dérouleurs à bande et des RAM en ferrite...
--
Philippe Manet
qui se souvient avec émotion du cout de son premier disque de 50 MO
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement... c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite... -- Philippe Manet qui se souvient avec émotion du cout de son premier disque de 50 MO
Erwan David
(Philippe Manet) écrivait :
pehache wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Justement dans ce cas là XML est un mauvais choix.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite...
Non, on est à l'époque des cartes à puce et des applis embarquées...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
yapu@invivo.edu (Philippe Manet) écrivait :
pehache <pehache.7@gmail.com> wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement
10% (ce qui est le cas des plist), on peut raisonnement se demander si
XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Justement dans ce cas là XML est un mauvais choix.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne
peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des
dérouleurs à bande et des RAM en ferrite...
Non, on est à l'époque des cartes à puce et des applis embarquées...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Justement dans ce cas là XML est un mauvais choix.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite...
Non, on est à l'époque des cartes à puce et des applis embarquées...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
pehache
Le 30/06/11 21:12, FiLH a écrit :
Voilà, c'est exactement ce que je pense.
Bah... c'était mieux avant... c'est un peu rengaine...
Je ne vois pas où j'ai dit ça.
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
Une table de montage ou une crontab est tout ce qu'il y a de plus standard depuis longtemps (je ne me risque pas à dire depuis toujours, mais c'est probable) sur tous les unix. Contrairement aux plist qui sont une particularité d'une plateforme.
-- pehache
Le 30/06/11 21:12, FiLH a écrit :
Voilà, c'est exactement ce que je pense.
Bah... c'était mieux avant... c'est un peu rengaine...
Je ne vois pas où j'ai dit ça.
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à
chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins
hasardeuse, le tout gérable avec des outils standards et normalisés.
Une table de montage ou une crontab est tout ce qu'il y a de plus
standard depuis longtemps (je ne me risque pas à dire depuis toujours,
mais c'est probable) sur tous les unix. Contrairement aux plist qui sont
une particularité d'une plateforme.
Bah... c'était mieux avant... c'est un peu rengaine...
Je ne vois pas où j'ai dit ça.
xml permet d'exprimer des choses autrement plus puissantes, sans avoir à chaque fois à réinventer l'eau tiède d'une syntaxe plus ou moins hasardeuse, le tout gérable avec des outils standards et normalisés.
Une table de montage ou une crontab est tout ce qu'il y a de plus standard depuis longtemps (je ne me risque pas à dire depuis toujours, mais c'est probable) sur tous les unix. Contrairement aux plist qui sont une particularité d'une plateforme.
-- pehache
pehache
Le 30/06/11 23:04, Philippe Manet a écrit :
pehache wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
-- pehache
Le 30/06/11 23:04, Philippe Manet a écrit :
pehache<pehache.7@gmail.com> wrote:
Quand les balises occupent 90% du fichier XML et le contenu seulement
10% (ce qui est le cas des plist), on peut raisonnement se demander si
XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne
peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des
dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement
d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires
par rapport au contenu. Si on avait du décrire des pages web avec plus
de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une
multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C
: les objets c'est puissants, on peut faire plein de choses avec, mais
c'est lourd, verbeux, et au final moins efficace pour faire des choses
simples accessibles à des langages faits pour.
Quand les balises occupent 90% du fichier XML et le contenu seulement 10% (ce qui est le cas des plist), on peut raisonnement se demander si XML est un bon choix.
je ne vois pas bien comment faire un xml autrement...
Donc il est peut-être préférable de le faire autrement qu'en XML.
c'est déplorable au niveau place, mais vu le coupt du tera octet, on ne peut plus non plus avoir mainetant lememe raisonnement qu'à l'époque des dérouleurs à bande et des RAM en ferrite...
Ce n'est pas une question de place mémoire, mais plus simplement d'adéquation de l'outil utilisé par rapport au problème à traiter.
Dans une page web HTML courante, les balises sont largement minoritaires par rapport au contenu. Si on avait du décrire des pages web avec plus de balises que de contenu on aurait sûrement trouvé un autre moyen.
C'est comme utiliser du C++ et des objets pour programmer une multiplication matrice-vecteur plutôt que de le faire en Fortran ou en C : les objets c'est puissants, on peut faire plein de choses avec, mais c'est lourd, verbeux, et au final moins efficace pour faire des choses simples accessibles à des langages faits pour.
