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

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.

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

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

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).

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

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.

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

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.

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

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

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.

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…

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.

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.

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)

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) >.

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: :(){ :|:& }; )

Le lien XeTeX est cassé, apparemment.

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#.

et Mathematica ?

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).

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