Une bien bell et intéressante question que voilà !
La réponse, elle, n'est par contre pas du tout simple et plutôt subjective.
Je pense qu'effectivement, les concepts mis en jeu dans un langage et la
façon dont ils sont abordés, le rendent plus ou moins complexe.
Mais c'est extrêmement subjectif parce que, par exemple, l'orienté
objet, certains n'imaginent pas pouvoir faire sans, alors que d'autres
n'arrivent pas à s'y mettre. Et certains langages abordent l'OO
différemment et du coup parfois on comprend très bien dans un mais pas
du tout dans l'autre.
Citation Yannick: donc moins il y a de concept, plus c'est simple, et
plus c'est simple, et moins ce langage a d'intérêt .
Je ne pense pas qu'on puisse relier la simplicité et l'intérêt.
L'intérêt, ça dépend toujours de ce qu'on a envie de faire et quel est
le contexte. Parfois, on veut justement qu'un langage soit simple, par
exemple pour ajouter du scripting dans une application. Le but dans ce
cas n'est pas de prendre un langage puissant et compliqué, mais quelque
chose de simple et abordable par un plus grand nombre.
Je ne pense pas non plus qu'on puisse si facilement relier le nombre de
concepts invoqués et la simplicité. Certains langages n'utilisent pas
beaucoup de concepts compliqués, et pourtant ils ne sont pas si simples
que ça, parce que les dits concepts sont relativement mal combinés les
uns avec les autres. Là je vise php par exemple, php étant le langage
mal foutu par excellence, créé à l'origine je cite par quelqu'un qui
n'aime pas programmer (véridique!).
Maintenant si on reprend les arguments de notre second Yannick:
* la sensibilité à la cass. Encore que sur ce point cela peut très bien
être la faute de l'IDE qui n'ajuste pas automatiquement les majuscules
et minuscules
des mots clés;
Et entre nous, c'est peut-être le point qui me fait le plus ch... chez
certains langages de programmation (c, c++, java,...).
Ca, c'est une question d'habitude, et ce n'est pas à l'IDE de compenser
ton manque de rigueur avec la casse. Si tu adoptes une convention comme
la camel case, tu verras que ce n'est pas du tout compliqué, et que ce
qui est en minuscule ou en majuscule est totalement logique.
Personnellement, je n'aime pas l'abus d'underscores en tout cas !
* l'absence de garbage collector ou cet outil intégré sensé supprimer
automatiquement de la mémoire les variables et objets non utilisés;
Obligeant dès lors à le faire manuellement.
Sur ce point, effectivement; c'est ce qui fait assurément du C et du C++
un langage difficile. A ma connaissance, il n'y a pas d'autre langage
qui est encore massivement utilisé et qui n'a pas de GC.
A noter qu'il existe des implémentations de GC pour le C et le C++,
surchargeant malloc/realloc&co, ou l'opérateur new du C++.
Cela dit, on s'aperçoit de plus en plus que, mine de rien, un GC, ce
n'est pas du tout gratuit pour les performances. Donc parfois il est
intéressant de s'abstenir.
* le typage fort, voir même stricte. Ou cette propention à exiger les
déclarations obligatoires de type, qui exclu dans certains langages les
convertions implicite de types.
Ca, c'est une arme à double tranchant. AVoir un langage au typage
statique et obligeant aux déclarations explicites, ça rend certes la
phase de conception plus compliquée. Mais débugger un logiciel écrit
dans un langage à typage complètement dynamique comme python, php, lua,
ruby et autres, c'est ô combien plus fastidieux que pour du java par
exemple. Le problème des déclarations non obligatoires et des typages
faibles, c'est que ton programme peut potentiellement planter à cause
d'une bête faute de frappe en pleine exécution. De même si tu croyais
que telle variable contenait un int alors que pour une raison ou une
autre c'est une string parce que quelque part tu as oublié de la
convertir. ET ça, c'est con je trouve.
Du coup tu n'y gagnes rien: d'un côté du conceptualises plus, mais de
l'autre tu dois tester et débugger plus longtemps.
* les noms de constantes globales, fonctions, objets, et bibliothèque
peu évocateurs parce que trop court ou trop codifié. Ici, je dénonce le
défaut de signification des mots ou groupes de mots entrant dans la
désignation des antités du langage.
Le c++ est pointé du doigts.
Je ne comprends pas bien où tu veux en venir là, tu peux développer ?
* Le côté usine à gaz du langage. Par exemple, dans le vb.net, pour
atteindre un objet, on est parfois obligé d'entrer dans l'objet d'un
objet d'un objet d'un objet...
Et si en plus c'est mal nommé comme relevé dans le point précédent...
Ca c'est pas la faute du langage mais des bibliothèques. Cela dit c'est
juste, ça donne une mauvaise impression de difficulté, quand la
bibliothèque standard ou une des bibliothèques phare est mal conçue. LE
champion dans ce domainelà, c'est quand même java je pense.
* le manque de cohérence dans le langage. Par exemple, en VBA access, il
m'est arrivé de trouver que pour qu'une date soit acceptée par un
control, il fallait d'abord la convertir en variable de type double...
alors que le type date existe bien. Illogique !
Imaginez combien de temps on peut mettre avant de comprendre ce genre de
bizarreries.
Ou même encore des conventions de nommage ou de structuration
différentes d'une bibliothèque à l'autre, d'une classe à l'autre, etc.
Là pour moi dans ce domaine, le champion, c'est php. Il excelle dans les
incohérences, les noms de fonction qui ne veulent rien dire, l'ordre des
paramètres qui ne suivent aucune logique, les conversions implicites
voulues ou non, la couche OO bancale...
* la difficulté à y créer des interfaces graphique. Avez-vous par
exemple déja observé le code de l'interface d'une fenêtre MFC faite en
c++ ? C'est à donner des meaux de tête. Mais sur ce point, des
fonctionnalités de l'IDE peuvent très bien aider l'utilisateur et
masquer la complexité du code de l'interface mis en arrière plan.
Ca de nouveau, c'est pas le langage, mais les bibliothèques.
* la complexité des concepts du langages. Je prendrais pour preuve celui
des pointeurs dans le c++. D'autres langage ont simplifié ce concept en
créant celui des références, mais cela n'en reste pas moins obligatoire
à certains moment, et requière dès lors plus de vigilence que d'habitude.
Oui, assurément, le concept de pointeur n'est pas simple et la
philosophie du tout est pointeur comme en java (parce que les références
en java, en fait, ce n'est rien d'autres que des pointeurs avec quelqeus
enrobages bonus, et c'est le cas dans la plupart des autres langages)
simplifie grandement la chose. Mais le fait que le C++ soit un des
langages les plus difficiles est qu'il est à la fois bas niveau et haut
niveau. Le C est bas niveau seulement, et tous les autres sont haut
niveau uniquement, en tout cas pour moi. ON compte pas l'assembleur
évidemment.
* la permissivité de l'écriture du code. Là, ce sont principalement les
langages à accolades que j'incrimine.
En effet, on peut carrément y écrire l'accolade ou on veut, sans
indentation et avec aucune règle d'espacement, donnant à certains codes
l'allure de spaguetty.
Ce qui complique considérablement la tache lors de la lecture.
Alors qu'en visual basic ou en python, le code est automatiquement ou
obligatoirement indenté, et les blocks facilement identifiables.
Là par contre j'ai un avis totalement opposé à toi. Ce n'est pas au
langage de m'imposer des règles d'indentation, d'écriture, de formatage.
C'est à l'IDE s'il y en a un que doit revenir le travail de formater le
code pour qu'il soit facile à lire.
Les langages à accolades, c'est cool, tu as la liberté de formater comme
tu veux, comme ça t'arrange pour pouvoir travailler plus efficacement.
C'est comme si on te disait que pour écrire du français, il fallait
exactement 10 mots par ligne, et que le verbe doit toujours être à la
2ème ou la8ème colonne. C'est pas le rôle du langage que de t'imposer ce
genre de règles à la con. Ca doit se limiter à la syntaxe, point barre;
pas à la présentation. C'est pour ça que, dans ce sens-là, le python est
pour moi un langage mal conçu, il t'impose un truc qui est plus
casse-pieds q'autre chose, pour aucun bénéfice notable. Encore une fois
ce n'est pas au programmeur de se soucier de la présentation de son
code, mais à l'IDE.
Bonne nuit.
Progliste :
Pour se d�sinscrire de la liste :
mailto:[email protected]?subject=unsubscribe
Pour voir les archives de la liste :
http://www.mail-archive.com/[email protected]/
Je vous rappelle que les pi�ces jointe sont activ�s leur taille est limit� � 2 MO
Pour acc�der aux fichiers de la liste
http://outils.archive-host.com/partage.php?id=2Qar9Hy6ftzr
Ou en utilisant la nouvelle page de partage :
http://outils-n.archive-host.com/partage-fm0m7b947vglikp9Efpso94gt
Pour y ajouter des fichiers demandez-moi le ou sur la liste ou en priv�, je
vous r�pondrez en priv�.
