Comments on Quels sont mes langages de programmation préférés ?

simple-touriste (2013-04-16T22:52:11Z)

Pourquoi C++ est un langage tellement en évolution?

Parce que c'est un langage qui se cherche!

Le problème est la gestion du polymorphisme statique :

template <typename T>
class Baz;

// ni foo ni qux ne sont déclarés comme des types dans cette portée
// foo et qux peuvent être des fonctions, ou des templates de fonction dans cette portée, ou pas

template <typename T>
void f(T x)
{
foo (x);
std::cout << x;
x::bar ();
Baz<T>::baz ();
qux (Baz<T>::baz ());
}

De quel foo s'agit-il? Dans quelle portée faut-il le chercher?
Pareil pour operator<<.

Dans le cas de bar, la portée est claire.

Dans le cas de baz, la portée est claire, mais il faut savoir où chercher les déclarations des spécialisations de Baz.

Dans le cas de qux : on ne sait même pas quel est le type de Baz<T>::baz () à ce moment là; Baz<T> est déclaré, mais pas défini, par définition, puisque T est une variable de type.

Il y a eu un changement majeur dans C++ en passant d'une approche macro-like pour les template à la gestion "moderne", ce qui a cassé du code comme :

template <typename T>
void f(T x)
{
T::Type x;
}

puisqu'au moment où le compilateur parse ça, il ne connait pas T par définition et ignore donc que T::Type désigne un type, il considère que T::Type désigne un non-type non-template (donc une fonction ou une variable). Il faut écrire :

template <typename T>
void f(T x)
{
typename T::Type x;
}

(remplacez x par *x pour voir que c'est ambiguë dans le cas général : expression ou déclaration?)

De même on ne peut pas écrire T::Template<int> quand T est une variable de type, il faut écrire template T::Template<int> sinon le compilateur n'imagine pas que T::Template est un template (c'est ambiguë dans le cas général, on peut écrire T::Template<4>(a), et si T::Template peut être une variable, ça voudrait dire (T::Template) < 4 > a (double comparaison de la forme (1 < 2 > 3), je me souviens plus de l'associativité).

Il y a plein de cas dans la syntaxe C qui sont ambiguës et nécessitent de savoir si un nom désigne un type (notamment a*b; et a(b); peuvent être des declaration ou des expression-statement selon que a désigne un type ou non). En inventant le cast fonctionnel (int(3.14) équivalent à (int)3.14 en C), C++ a rajouté d'autres cas d’ambiguïté. Le template en utilisant des opérateurs infixes < > ont rajouté d'autres ambiguïtés : a<b>(c); déclaration, expression (appel de fonction), ou expression (comparaison)?

Il faudrait un système de contraintes sur les types, dans la veine des signatures de O'Caml pour contraindre les templates et éviter ces ambiguïté, pseudo-code :

template <typename T où T::Type est un type>
void f(T x)
{
T::Type *x; // x est un pointeur; pas de multiplication ici
}

mais ça devient vite passablement difficile de formaliser un tel langage de spécification qui soit suffisant en pratique : C++ n'est pas O'Caml, et se formalise moins élégamment.

Sinon, il y a la portée i dans for (int i=0;i<10;++i) qui a changé, aussi, il y a très longtemps.

Le soucis de ne pas casser du code existe, mais il est moins fort que le soucis de rendre le langage plus cohérent.

Xavier Combelle (2013-04-16T12:41:35Z)

brainfuck est un vrai langage au sens ou il est turing complet. Mais non, personne ne programme avec ça.

titipukhân (2010-04-16T12:57:01Z)

Bonjour, pardonnez mon ignorance, mais le langage "brainfuck"… c'est une blague…? Il y a des gens qui travaillent avec ÇA?????

JML (2010-04-13T17:06:01Z)

Deux aspects intéressants de C++ :
- le bouquin écrit par Stroustrup, The C++ Programming Language, propose une vraie vision de ce que peut être une programmation de qualité industrielle dans ses différents aspects, c'est loin d'être juste un bouquin qui décrit le langage sans plus
- la manière dont le langage a échappé à ses concepteurs quand ils ont introduit quelques éléments de méta-programmation (les templates) et que des petits malins ont fait plein de hacks pour avoir beaucoup plus de méta-programmation… C'est fascinant comme un langage peut avoir sa vie propre, comme s'il disait clairement qu'il faut maintenant le modifier de telle ou telle manière pour qu'il marche mieux.
Mais seul un faible pourcentage des gens qui se disent programmeurs C++ ont lu le bouquin de Stroustrup, une certaine médiocrité plombe la communauté.

En tout cas j'attends avec impatience que des types brillants créent enfin un vrai méta-langage, intégrant le fait qu'il y a peu de différences entre un éditeur de texte / environnement de programmation pour ce langage et un compilateur, qu'un bon programme doit pouvoir être regardé par chacun de la manière qu'il préfère (puisqu'un bon programme est aussi un document didactique), qu'il faut prévoir d'entrée un mécanisme standard de mise à jour de bibliothèque qui permette de modifier les anciens programmes pour qu'ils se pluggent à la nouvelle interface, et aussi que fournir un langage puissant et magnifique sans une approche pédagogique qui permette de savoir quoi en faire, c'est comme offrir un famas à un gamin de 8 ans.
Et, honnêtement, je crois que notre civilisation sombrera dans le chaos faute d'avoir su accoucher d'un tel type de langage (… et de quelques autres trucs qui procèdent du même état d'esprit).

Apokrif (2010-03-28T22:01:22Z)

Personne n'a cité le Cobol, pourtant réputé pour sa lisibilité (du moment qu'on n'utilise pas l'instruction ALTER).

bubbatls (2010-03-26T09:26:44Z)

Effectivement le concepteur d'un langage ne doit pas empêcher le programmeur de se tirer une balle dans le pied. Mais il y en a quand même qui lui donnent un flingue chargé et qui lui dessinent une cible sur le pied.

Notamment javascript, le scope des variables n'est pas le même que dans les autres langages, et la matrice d'égalité du == ressemble plus à space invader qu'à une belle diagonale.
<URL: http://edonjon.lescigales.org/#index.jsop~p%3Djavascript.jsop >
Pour bien faire il faut utiliser === et une fois qu'on a décharge le flingue tout va bien et c'est super (cela ne s'est pas vu mais je suis zélote javascript).

Le problème avec le fait de permettre de faire de l'illisible, c'est qu'au final 90% du code est illisible. C'est la même chose avec les commentaires, les langages permettent d'en mettre mais il y en a jamais (assez?). Si on donne la possibilité à quelqu'un de moins travailler (et moins taper sur son clavier c'est moins travailler) il le fera. Et moi je préfère du code lisible sans commentaire que du code illisible sans commentaire.

Perl restera un langage pour ingénieur système quoiqu'on en dise.

Suzu (2010-03-23T17:23:18Z)

Le PHP, c'est bien pour rencontrer des mimi graphistes.

ushu (2010-03-21T16:23:09Z)

C# est vraiment un langage intéressant, qui a beaucoup évolué depuis sa création (3 versions déjà). Pour les bons côtés je citerai: gros soutien industriel, bonne librairie standard, support de plusieurs paradigmes de programmation dont des aspects fonctionnels (lambda expressions depuis la v2, expression trees depuis la v3, etc.). Pour les mauvais côtés, la portabilité est encore loin d'être parfaite, et l'image du langage souffre du syndrome "Microsoft c'est mal"…

Sinon personne n'a cité Ada. C'est très loin d'être mon langage préféré, mais il a ses qualités pour de (très) gros projets.

jko (2010-03-20T22:41:20Z)

Allez un petit lien pour le fun vers la Hello World Collection dans 428 languages :

http://helloworldsite.he.funpic.de/hello.htm

… il y a même Unlambda

DH (2010-03-20T21:54:48Z)

Personne ne parle de Fortran (77 ou 95, je ne suis pas raciste) ? ;-p

Couard Anonyme (2010-03-20T21:29:43Z)

Bah… si tu veux du depaysement, il faut aller jouer avec les langages descendant de Prolog. Notamment ceux qui ont melange Prolog a la programmation fonctionnelle pour donner des choses comme Mercury, dans la meme veine Alice est un delirant fourre tout, sans parler des Prolog d'ordre superieur comme lambda-Prolog. Puis il faut aller regarder la sous-branche qui s'est specialisee dans les bases de donnees a la suite de Datalog, notamment les Prolog tabules. Et enfin les langages qui ont remplace le systeme de recherche exhaustive de Prolog par un moteur dedie, le langage servant essentiellement a preparer les donnees pour le moteur, c'est le cas d'AMPL, GAMS ou OPL (Van Hentenryck).

Sinon, pour le langage 'multi-purpose', chez moi c'est clairement ML. Ensuite tu utilises la variante que tu veux (Haskell, SML, Caml, F#) mais c'est fondamentalement la meme chose. Au detail pres que pour moi Caml est un meilleur SML et F# est un meilleur Caml. Et Haskell deconne a etre aussi pur.

Ensuite, une des raisons des defauts de Caml est l'approche minimaliste de Xavier : pas de sucre, flemme d'ecrire un parseur autorisant une syntaxe plus complexe que LALR. La bonne nouvelle est que transformer du Caml en SML ou F# est un jeu d'enfant pourvu que tu n'utilises que core-ML. Concernant la bibliotheque standard, tu delires completement : ML etait pendant tres longtemps la seule famille a avoir une bibliotheque potable, avec tout le necessaire pour faire du calcul symbolique. Avec C/C++ t'etais a poil, Java a pris mille ans pour y parvenir et c'est bancal, C# n'a pas d'ensembles et il faut jongler pour faire un dictionnaire vers un type structure genre int -> int * int. C'est sur, pour faire du XML, du graphique et tout ca, c'est pas terrible. Mais justement, F# a corrige tout ca (et a mis du sucre a la Haskell pour pouvoir faire des one-liners). Par contre F# est seulement windoze ce qui fait chier.

La prochaine generation de MLs sera la bonne ! Mais encore faut il que nous (chercheurs) acceptions de bosser sur comment generer une bibliotheque graphique puissante qui n'ait pas besoin de 1000 hommes-an de travail, pareil pour le traitement de texte et XML, les bases de donnees, etc. Et c'est pour ca que j'aime bien le boulot d'Alain sur CDuce/OCamlDuce. L'idee est d'incorporer un nombre minime de fonctionalites au langage afin de trivialiser la tache. Ensuite c'est plus ou moins bien reussi, mais l'intention est bonne.

FlorentR (2010-03-20T15:22:18Z)

Bonjour,

En tant que zélote Python, je vais me contenter de répondre au
paragraphe le concernant. Tes arguments (David) me semblent presque tous
raisonnables, mais tu n'en tires pas les mêmes conclusions que moi. Les
miennes ne proviennent sans doute pas que des arguments « théoriques »,
mais aussi de l'expérience, du plaisir à écrire en Python… plaisir
dont je ne suis pas sûr que tu aies assez goûté. ;-)

Point par point :

- « Python n'est pas adapté aux one-liners »

Bah oui, Python n'est pas vraiment un shell. C'est d'abord un
langage de programmation… De manière à peine provocatrice, on
pourrait dire que Perl est un shell que beaucoup prennent pour un
langage de programmation. Grosse erreur. :-)
(programmer en Perl, c'est comme programmer en csh, sauf que Perl
est un peu moins vieux, quoi)

Oui, les accolades-faisant-blocs-logiques dont tu parles en
mentionnant Haskell seraient pratiques pour écrire des one-liners en
Python, mais elles pourriraient sans doute la lisibilité des vrais
programmes. Les objectifs déterminent les bons outils…

Là où ta conclusion est un peu délirante, c'est que la décision de
ne pas mettre d'accolades pour cela n'a *rien de religieux* à mon
avis. Cela me semble être une décision tout à fait rationnelle dont
le but est de préserver la lisibilité des programmes !

- Cela me semble être du même accabit pour le pb
instructions / expressions. Je comprends fort bien la frustration à
ne pas pouvoir faire tout ce que l'on veut dans une fonction anonyme
(lambda), mais l'idée est sans doute que si une lambda devient un
peu grosse, le code gagnerait en lisibilité si l'on redéfinissait la
lambda comme une fonction normale (ce qui permettrait au passage de
rajouter très rapidement une doc basique via la docstring).

Je pense aussi que Guido van Rossum (le Créateur de Python, qui joue
toujours un rôle très important sur les évolutions du langage),
n'aime pas trop les paradigmes de la programmation fonctionnelle. Il
me semble d'ailleurs qu'à une époque (vers Python 2.2 ou 2.3), il
parlait même de supprimer des fonctions telles que map() et
reduce()… La raison en est sans doute l'accessibilité du code. Si
ce style de programmation est assez naturel pour les matheux, qu'en
est-il pour autres ?.. (personnellement, je serais très malheureux
si map() venait à disparaître ; ce qui prouve, contrairement à ce
que tu prétends, que les lambda *sont* utiles en Python, malgré les
limitations de ce qu'on peut faire dedans)

- Morceau suivant, que je reproduis ici :

« un langage de programmation n'est pas là pour faire la morale
aux programmeurs, il est là pour leur donner ce qu'ils veulent, y
compris de quoi se tirer une balle dans le pied si c'est ça qu'ils
veulent (et la tradition d'Unix, et de Perl, a toujours été de
fournir un abondant arsenal pour les programmeurs qui veulent se
tirer des balles dans le pied :-) ; plus sérieusement, le
programmeur est quand même mieux placé que le concepteur du
langage, aussi malin soit-il, pour décider ce qui est le mieux
dans le contexte précis de son programme »

Hum, hum, tu ne considères que ton point de vue de bonhomme
intelligent qui n'a pas de problème avec une API riche ou complexe.
Ce n'est pas le cas de tout le monde. Il y a certainement pas mal de
monde que cela aide grandement d'avoir peu d'outils à disposition,
mais des outils judicieusement choisis : performants, indépendants,
et le moins dangereux possible. C'est un peu comme bien choisir ses
axiomes dans une théorie mathématique. Le but, c'est plutôt d'en
avoir le *minimum* nécessaire pour résoudre les problèmes qui nous
intéressent.

Pour te prendre au mot, si je dois équiper un garage pour y enfermer
un bricoleur pendant un an (encore une super idée de jeu
télévisé…), je ne pense pas qu'il soit très utile d'adjoindre à la
panoplie des outils une arme à feu (sauf si, dans le cadre du jeu
télévisé, c'est pour laisser une chance au malheureux cobaye de se
suicider en direct pour le plaisir des petits et des grands ; mais
ce serait un petit peu malhonnête de penser ainsi tout en le
justifiant en arguant qu'une bonne panoplie de bricoleur doit
permettre de se tirer une balle dans le pied, non ?).

Pour prendre une autre analogie : un exo de maths est plus facile à
résoudre si l'on te donne juste les données pertinentes que si l'on
te noie dans des données dont seule une petite partie est utile pour
arriver à la solution…

Toutes ces décisions de conception, limitatrices à tes yeux, mais
qui servent en fait la lisibilité et l'accessibilité du langage,
sont sans doute pour une bonne partie à l'origine de son succès dans
le monde Windows.

- sur les « références » de Perl qui seraient absentes de Python, je
ne peux pas commenter car je n'ai pas idée de ce à quoi elles
servent.

En gros, je ne serais pas surpris que tu aies lu (ou parcouru) des
documents sur Python, dont sans doute la doc officielle, mais sans
écrire de vrai programme pour te faire une idée plus concrète…

Geo (2010-03-20T13:34:36Z)

Personnellement, mes langages préférés sont ceux qui me font passer le moins de temps devant l'ordinateur…

Comme tu le dis, j'ai le sentiment que certaines de tes critiques sur OCaml ne sont plus forcément d'actualité. Je laisse à d'autres le soin de répondre. Juste un point, tu reproches à Haskell d'être trop "pur". Il me semble justement que OCaml offre un bon compromis entre pureté et pragmatisme.

Ruxor (2010-03-20T02:29:16Z)

Ce qui me pose problème avec OCaml (ou ce qui me posait problème la dernière fois que j'ai regardé, du moins), c'est :
* c'est un langage de recherche, visiblement plus conçu pour donner des thèses aux thésards de l'INRIA que pour que des gens s'en servent derrière, et ça se voit à la faiblesse ou au manque de cohérence de la bibliothèque standard (pas un sujet sexy) par rapport au système de typage, ou à la façon dont la compatibilité ascendante est préservée (i.e., peu),
* il n'y a pas de distinction claire entre la spécification et (l'unique) implémentation (OCaml est loin d'être le seul langage auquel on peut reprocher ça, bien sûr !, mais ça contribue à empirer le point suivant),
* c'est un langage très marginal (développé essentiellement à *un* endroit), dont on peut donc craindre pour la pérennité, (ce n'est pas la faute du langage, bien sûr, c'est une contingence extérieure, mais on a l'impression que les développeurs du langage ne font pas des masses d'effort pour attirer une masse critique de développeurs extérieurs pour rendre plus certaine la survie à long terme d'OCaml), et
* le système de typage est vraiment trop compliqué (on a l'impression de voir chaque thèse du projet cristal…), on ne comprend rien à la façon dont toutes les extensions dans tous les sens interagissent entre elles, et pourtant, je suis mathématicien et je n'ai pas spécialement peur des abstractions ou de la théorie des catégories ou du λ-calcul, et je n'ai pas l'impression d'un tel sac de nœuds en regardant le typage de Haskell.

Donc, globalement, je crois que je préfère Haskell, et dans la mesure où je prendrais spécifiquement un ML ce serait probablement plutôt SML/NJ. Mais bon, ces reproches ne sont pas très forts, certains ne sont peut-être plus d'actualité, et je conviens tout à fait que OCaml est un langage au moins digne d'intérêt.

W (2010-03-19T23:58:17Z)

Je plussoie les commentaires qui mentionnent OCaml. D'un côté, il est dans la catégorie des langages qui "devraient, logiquement, être tes préférés" : c'est un langage fonctionnel avec un gros potentiel de masturbation intellectuelle, qui incite effectivement à "faire les choses de façon pure". D'un autre côté, il est un petit peu moins puriste que Haskell : l'évaluation n'y est pas paresseuse, et le programmeur peut (s'il le veut :) ) utiliser des facilités impératives/objet plus simplement qu'en Haskell.

Mais je ne connais pas Haskell, donc peut-être qu'en bon zélote d'OCaml j'ai des tas d'idées reçues sur ses concurrents.

Ruxor (2010-03-19T23:18:06Z)

Je suis d'accord que « s/// » est moins compréhensible que « replace » pour faire une substitution, m'enfin, faudrait arrêter de se focaliser sur ce point précis : le « += » du C, il est tout aussi incompréhensible, et pourtant il a été repris en Python. De toute façon, le problème avec les substitutions, c'est que dès qu'on veut faire quelque chose de pas totalement évident on a besoin d'expressions régulières, or *tout* le monde utilise sensiblement la même syntaxe pour les expressions régulières (à des différences près, hautement confusantes mais néanmoins faibles), syntaxe qui est vraiment illisible pour le coup (pourquoi est-ce que « ab* » désigne un a suivi de n'importe quel nombre de b, y compris zéro, alors que dans d'autres contextes ça désigne ab suivi de n'importe quoi ?). L'employeur du programmeur peut très bien exiger que ce dernier commente toute ligne du style « $s =~ s/foo/bar/ » pour dire « remplacer "foo" par "bar" dans $s » si on pense que c'est important.

Et tu continues à faire du nombrilisme sur l'« industrie ». À part OCaml qui a été développé par un institut de recherche public, l'immense majorité des langages de programmation sont développés par l'« industrie » ! Erlang, qui est un des langages les plus atypiques qui soit, a été inventé par Ericsson pour leurs usages industriels et ça leur a fait gagner une productivité délirante par rapport au C++. F# est développé par Microsoft, Go par Google, etc. J'ai un ami qui bosse pour un industriel pour un système qui pourrait remplacer le moteur de réservation des compagnies aériennes : actuellement c'est de l'assembleur IBM S/360 (un système complètement disparu de nos jours, et émulé sur des PowerPC), et le remplacement putatif est écrit en Common Lisp. Tout ça c'est de l'industrie, évidemment.

xavier (2010-03-19T22:58:28Z)

Je n'aime pas le Perl parce qu'il y a trop de symboles.
Tout comme je n'aime pas le japonnais dans le trouve que ce n'est pas élégant comparé à un alphabet. Je trouve plus naturel pour un humain de lire "replace" quand il s'agit de "rempalcer" que de lire "/s" ou tout autre symbole peu clair *a priori*.

Pour le reste, on s'est mal compris je crois.
Il n'y a pas de Vrai ou de Faux.
Il y a des gens dont le boulot est de concevoir des langages jolis et bien foutus avec des belles API. Ca donne des merveilles du style d'Ocaml.
D'un autre coté, il y a des gens qui bosent dans l'industrie et qui, de fait, ont en gros le choix entre C, C++ et java. Tout le reste ne sera souvent pas considéré et classé dans la case "exotique et hors de propos". Ce un long combat pour virer matlab et faire du python ou même du scilab à la place. Pourquoi? Car ça coûte cher de changer.

Je ne porte bien sûr aucun jugement de valeur sur l'un ou l'autre des deux mondes.
Je note simplement qu'un argument du style "c'est quoi ce machcin avec des symboles de partout (ou c'est quoi ce machin "fonctionnel"?!?), je veux un truc qui me parle plus sinon les gens qui font l'assurance qualité vont être perdus et ce sera le souc" est tout aussi recevable dans l'industrie qu'il est totalement hors de propos quand on parle à un developpeur de D ou de ocaml.

Ce trou entre l'industrie et la recherche existe. Je ne sais pas si c'est un bien ou un mal mais c'est un fait. Un fait qu'on ne peut pas changer car sinon tout l'édifice s'écroule. C'est comme si on demandait à un chercheur en info de se plier aux règles d'assurance qualité de l'industrie. Ce serait aussi stupide que contre productif.

Les critères de beauté ne sont pas les même pour tout le monde. Je regrette parfois que l'industrie rejette des choses sous prétexte qu'elles lui sont inconnues. Ceci étant dit, on ne peut pas en vouloir à un ingé de trouver beau un truc qui fonctionne dans les délais. Changer coûte cher.

Presque aucun (libre à toi de mettre la mesure que tu veux là dessus :)) ingé ou biologiste (pour parler seulement de ce que je connais…) n'utilise Haskell ou Perl ou D ou Ocaml car ça ne correspond pas aux critères de beauté en vigueur dans le milieu.

Je pense que le décalage est N fois plus grand si on parlait de maths et non de langages.
Seule une petite fraction de la recherche trouvera un jour son chemin dans l'industrie…et c'est ça qui est beau quand on y pense (même si ça fait parfois râler à la fois les chercheurs et les industriels)

rjolly (2010-03-19T21:07:57Z)

J'ai la faiblesse de voir un signe dans le fait que Scala est cité en dernier. Signé : un zélote de scala :-) D'autre part, voici deux langages que je ne connais pas bien mais qui ont l'air intéressants : <URL: http://en.wikipedia.org/wiki/Go_(programming_language) > et <URL: http://en.wikipedia.org/wiki/Fortress_(programming_language) >.

Ruxor (2010-03-19T20:45:47Z)

xavier →

Tu continues à confondre allègrement « le langage X permet d'écrire des choses illisibles » et « le langage X ne permet pas d'écrire des choses lisibles ». Qu'est-ce que c'est censé prouver, qu'on peut écrire une fork-bomb en bash par « :(){ :|:& } », sachant que ce programme a été écrit *exprès* pour être illisible ? Ça prouve à peu près autant que le fait qu'on trouve des programmes de ce genre en Pyton (<URL: http://c2.com/cgi/wiki?ObfuscatedPython > et <URL: http://www.p-nand-q.com/python/obfuscated_python.html >), c'est-à-dire, rien.

C'est probablement vrai qu'il est plus dur d'écrire du code Perl lisible par quelqu'un qui ne connaisse rien à Perl que du code Python lisible par quelqu'un qui ne connaisse rien à Python. Mais la raison tient plus à, par exemple, la façon dont on initialise les objets, qu'à la présence de $, @ et autres : puisqu'on parle de *lire* le code et pas de l'écrire, la personne qui lit le code sans rien connaître au langage va juste ignorer ces sigils et si le code a été raisonnablement écrit, ça ne gêne pas. (De même pour les variables internes du Perl, qui ont toutes un nom anglais compréhensible.) Bref, il faudrait vraiment arrêter de sortir ces faux arguments bidons et épidermiques (je n'aime pas le Perl parce qu'il y a trop de symboles, je n'aime pas le Python parce que le whitespace a une sémantique, je n'aime pas le Lisp parce qu'il y a trop de parenthèses). Je conçois à la limite qu'on n'aime pas APL : ça c'est un langage dans lequel il est *vraiment* difficile d'écrire du code lisible. Dans tout autre langage, on peut très bien écrire du code lisible : on le structure correctement, on l'indente correctement, on le commente correctement, et c'est lisible. Si, si.

Je relève aussi le thème de « moi je fais des Vraies Choses (i.e., pas de l'informatique) ». C'est marrant, tout le monde le ressort régulièrement : tout le monde a toujours l'impression que ce qu'il fait, c'est du Vrai, et que tout le reste c'est des jouets. Le monde (ou le monde des gens qui manipulent des données, terme tellement vague qu'on ne sait pas ce qu'il peut vouloir dire) se réduirait aux domaines où l'informatique est le cœur du métier (et qui peuvent faire joujou avec des langages bizarres et ésotériques) et les Vrais Gens qui travaillent avec des Vraies Choses (des « projets industriels »), donc matlab-et-remplacements ? There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.

Oui, évidemment qu'il y a des gens qui traitent des données avec Perl, en témoignent le nombre de livres publiés sur le sujet. Sauf si par « traiter des données » tu veux dire faire exactement ce que tu fais (whatever it is), auquel cas probablement ça se fait dans le langage dans lequel tu le fais, mais c'est souffrir gravement de myopie que de croire que c'est la seule chose pour laquelle on emploie un ordinateur. Haskell, évidemment, est fait pour des applications plus éloignées de ce pour quoi Python et Perl sont faits, donc évidemment si les seuls usages qui te paraissent sérieux sont ceux que tu as, Haskell ne va pas te sembler un langage sérieux. C'est juste le signe de tes propres biais.

C'est malheureusement souvent la façon dont la plupart des gens se forment une idée sur un langage de programmation : ils se disent, pour mon usage à moi, tel jour, j'ai essayé tel langage, et soit ça m'a plu et alors j'en conclus que ce langage est très bien, soit ça m'a déplu et alors j'en conclu que ce langage est pourri. Ils oublient que tout le monde n'a pas les mêmes usages…

xavier (2010-03-19T19:44:33Z)

J'ai seulement dit que python est meilleur dans un contexte de projet industriel.

"s'ils ne veulent pas apprendre le langage, que foutent-ils à lire le code ?"
Ils le lisent car ils ont besoin de le modifier légèrement pour le *réutiliser*.
J'interdis bash (et tous les autres sh) et perl pour une utilisation de type "scripts". Je le fais car on constate vite que ces scripts ne sont lissibles que par ceux qui les ont écrits. On perd un temps fou à les rééccrire au lieu de modifier deux lignes, faute de les comprendre.
Ho bien sûr, si on avait toujours sous la main des techniciens spécialistes en langage de scripts…des spécialistes qui comprennent exactement ce qu'on veut sans avoir besoin de passer du temps à leur epxliquer et qui seraient toujours là pour modifier leurs codes en fonction des besoins, alors ça pourrait bien être codé en brainfuck que je m'en foutrais totalement.

Il se trouve que je n'ai toujours croisé que des gens non spécialistes en info et qui ne veulent pas perdre leur temps à apprendre un outil cryptique.
foo.replace("a","b") oui. /s/'a'/'b' non.

Si le programmeur écrit un code que personne ne peut relire, ce n'est pas son problème dans ce contexte. C'est le mien. On a perdu en temps ($$) et en qualité donc j'ai lousu.

En dehors des milieux dont l'info est le coeur de métier, seul le C, le java et le C++ existent en tant que langages généralistes. Python commence tout juste à exister grâce à scipy/numpy/pylab. Il rentre en séduisant les gens qui en ont marre de matlab. Perl et haskell n'existent pas en tant qu'outils destinés à faire au chose que de l'informatique.
Qui traite ses données en perl ou en Haskell? Personne.

Comme je vois que c'est un sujet sensible, je vais me garder de dire que Perl ne permet pas de faire des codes lisibles.
Par contre, je crie le fait que bash ne permet pas de faire des script lisibles (pour un ingé dont ce n'est pas le coeur de métier et qui ne dira que "wttf??" devant ce tas de symboles à la noix: :(){ :|:& }; )

Ruxor (2010-03-19T15:29:51Z)

xavier → C'est vraiment le genre d'arguments qui m'agacent, ça, « les one-liners Perl sont illisibles, donc Python est meilleur ». Perl *permet* de faire des programmes illisibles. Ça, c'est un avantage : c'est au programmeur de savoir ce qu'il veut, et s'il veut un programme illisible (par exemple parce que le but est de le taper directement en ligne de commande, et qu'il ne resservira pas), c'est SON problème. Si on dit « Perl ne permet pas de faire des programmes lisibles », là, effectivement, c'est une critique valable ; reste à défendre qu'elle est vraie, et en tout cas, à bien différencier l'affirmation « Perl permet de faire des programmes illisibles » de « Perl ne permet pas de faire des programmes lisibles ». Du reste, je suis quand même sceptique quant à l'utilité de faire des programmes qui soient lisibles de gens qui ne connaissent pas le langage (s'ils ne veulent pas apprendre le langage, que foutent-ils à lire le code ?). Python a plein d'avantages intéressants (et j'en ai cité dans mon post : les générateurs et les coroutines sont assez haut dans la liste) sans qu'on ait besoin d'invoquer l'argument fallacieux « les programmes Python sont plus lisibles ».

Abie → Corrigé.

Abie (2010-03-19T14:33:05Z)

Le lien XeTeX est cassé, apparemment.

xavier (2010-03-19T13:37:01Z)

Ben mathematica c'est pas mal du tout je trouve.
On peut en gros utiliser/mixer différents styles en mathematica.
Par contre, ca reste un langage fermé au sens ""personne" ne code de bibliothèques en mathematica".

Etant ingé, je préfère de loin python à Perl justement car j'aime bien que "tout le monde" puisse lire un code en cas de besoin.
Si on parle le C, le C# voire le java, on comprend un code python presque sans effort. Ce n'est pas le cas avec les one-liners Perl. Les &% et autres @ font fuir les gens qui ne connaissent pas la langue.
Si on a une truc du genre
str="abc"
str.replace("a","k")
tout le monde comprend ce que ca fait. Ce n'est pas le cas si on écrit la même chose avec une syntaxe "à la reg exp" (genre /s/a/k).
C'est important dans le monde des ingés.

Ce qui me fait coder en python, c'est scipy, numpy et pylab (sans eux je ferais plus de mathematica).

C est très raissonnable mais ne sait rien faire de haut niveau…même pas les strings.
C++ est une horreur beaucoup trop compliqué.

C# est bien…mais il n'y a pas de communauté scientifique autour de C# (on sait pourquoi…) donc il n'exsite pas d'équivalent de scipy/numpy en C#.

Geronimo (2010-03-19T09:12:41Z)

et Mathematica ?

Fork (2010-03-19T07:02:59Z)

Ruxor → Comme j'imagine que tu t'attends à ce genre de commentaire je vais en faire un :
«Tu ne cites pas Caml dans ta liste ? Pourtant c'est un très bon langage ! Etc.»

En ce qui me concerne, je suis bien parti pour faire du C plus ou moins intensivement au moins jusqu'à la fin de l'été, ce qui n'est pas pour me déplaire (de toute façon, pour faire de la programmation système Unix, je ne sais pas s'il y a vraiment une alternative aujourd'hui.)
Le problème, c'est que je suis généralement trop fainéant pour apprendre sérieusement un langage dont je n'ai pas *besoin* sur le moment. Et on a beau pouvoir apprendre un nouveau langage en un temps raisonnable, je trouve que ça s'oublie aussi remarquablement rapidement sans pratique (ce qui n'est pas surprenant, en fin de compte).

Arthur Rainbow (2010-03-19T06:36:05Z)

C'est juste moi, où c'est quand même assez cocasse de lire "on finit par envisager d'inventer son propre langage" de la part de quelqu'un qui l'a déjà fait !

Bon, j'ai bien compris que unlambda n'entrait pas dans le genre de langage décrit dans ce billet, mais quand même.

Je n'avais jamais vu la liste sur wikipédia, je me permet de rajouter, si certains ne connaissent pas, le lien vers le poster de l'histoire des langages de programmation, édité par O'Reilly, dans un sens, je le trouve assez bluffant.
http://oreilly.com/news/graphics/prog_lang_poster.pdf

--
Arthur, qui vient d'ajouter Coq à la liste


You can post a comment using the following fields:
Name or nick (mandatory):
Web site URL (optional):
Email address (optional, will not appear):
Identifier phrase (optional, see below):
Attempt to remember the values above?
The comment itself (mandatory):

Optional message for moderator (hidden to others):

Spam protection: please enter below the following signs in reverse order: feed62


Recent comments