Re: [HS] Langages interprétés, vos avis
Le samedi 23 novembre 2013 23:12:43 Bzzz a écrit :
>[…]
> > Ok, donc tu peux oublier les langages « interprétés »¹,
> > Python étant un des plus rapides.
> > (Pour ce que ça vaut → http://shootout.alioth.debian.org/ )
>[…]
>
> Ben, ça n'est pas tout à fait ce que dit cette page:
> http://onlyjob.blogspot.fr/2011/03/perl5-python-ruby-php-c-c-l
> ua-tcl.html la différence avec perl est qd même "intéressante"
> (wai, je sais, perl = mêmes PBs que C si on code un tant soit
> peu goret).
0. Qui c’est ce type ? C’est publié quelque part de sérieux ?
Nan, c’est un nain nonyme pas connu sur un blog. (Ouais,
argument d’autorité inversé, mais quand même, j’ai plus
confiance dans ce que dit le shootout (que beaucoup ont vu,
commenté, corrigé…).)
1. Ses tests ne portent que sur la manipulation de chaînes de
caractères (et le ramasse-miettes).
2. Ce type code comme un pied. Il ne tient pas compte du
modèle mémoire des langages. Donc, effectivement, il arrive à
bien faire foirer ses tests à ceux qu’il n’aime pas.
Ex. pour Java : les String sont immuables, quand on travaille
sur des chaînes de caractères muables, il faut utiliser des
classe de chaînes de caractères muables, comme les StringBuilder
ou les StringBuffer. Pas étonnant qu’il lui fasse exploser la
RAM et donc le ramasse-miettes.
Plus loin, une mise à jour où certains lui ont fait remarquer
qu’il avait comparé des pommes et des oranges. Que fait-il ? Il
ne change pas ses tables, il met juste une note dans un coin
(donc charge au lecteur de refaire les graphiques dans sa tête,
s’il ne s’est pas arrêté avant).
Juste après, il compare la verbosité de Java aux autres
langages. En gros, son programme Java fait tout avec des
primitives alors que pour les autres langages, il charge une
bibliothèque et appelle une fonction. Rebelote sur les
remarques : « nan mais je triche mais c’est parce que Java c’est
vraiment pas bien. » Ouais. Pas biaisé le gars…
Ne parlons pas du fait que pour certains langages, il fait du
remplacement de chaîne et pour d’autres, du remplacement
d’expression rationnelle…
En dehors de ces supercheries, et même quand on utilise les
bonnes classes et fonctions, si on veut comparer un peu plus
correctement ce que restera des pommes et des oranges, il faut
aussi s’intéresser à ce que fait chaque langage pour une
opération pas forcément aussi simple qu’il y paraît : p.ex. est-
ce qu’il y a des vérifications supplémentaires (des indices de
tableau, de la mémoire utilisée…) ?
Nan mais sans déc., ce gars a réussi à me faire défendre
Java !
(Moi aussi je trouve Java trop verbeux, avec une API
« spatiale »¹. Mais, d’une part, ses performances ne sont pas si
terribles (il s’en tire bien sur beaucoup de vrais tests) et,
d’autre part, je suis allergiques aux dogmes, mèmes et autres
psittacismes. Surtout les choses « naturelles » ou
« évidentes ». (Un simple argument comme « trop verbeux » me
suffit, hein.))
¹ « spatiale » : une hiérarchie de classes très conceptuelle
(c’est joli en diagramme) mais pas pratique du tout.
’fin bref, de toute façon :
1. pour la vitesse d’exécution d’un programme, il n’y a qu’un
test : avec le programme lui-même ;
2. « premature optimization is the root of all evil » D. Knuth
(ou à peu près).
>[…]
> Ouais, là, c'est pas gagné (à moins que perl ou autre ne
> permette de faire ça d'une façon triviale; par ex. sans
> avoir à gérer manuellement des sémaphores, etc).
1. Les sémaphores, c’est très 1965. Tu sais qu’on a inventé
mieux² depuis ? (moniteurs, co-routines, acteurs…)
2. Si tu décomposes correctement ton programme³ en modules /
services, les communications (et donc les risques de concurrence
et les besoins de s’en protéger) seront simplifiées et tu
pourras encore mieux utiliser des modules / services déjà faits.
P.ex. tu mets un module métier dans un service HTTP et tu peux
utiliser les techniques et logiciels de répartition de charge,
cache et réplication qui existent déjà.
3. Certains langages intègrent des facilités de
parallélisation. C’est p.ex. un gros argument de vente de :
— Java où tout objet peut être un moniteur ;
— Go(lang) et ses [cg]oroutines ;
— Erlang et son modèle acteur, etc.
² plus faciles/simples à manipuler.
³ je dirais même SI puisque tu as des BD, du GUI…
Pour finir, pour chaque langage, tu peux faire une simple
recherche « <langage> sucks » et tu comprends alors pourquoi il
y a encore et toujours des optimistes qui pensent pouvoir créer
le langage parfait…
--
Sylvain Sauvage
Reply to: