Quelles différences entre langages haut et bas niveau ?
Une copie d'étudiant fait le tour du Net et déchaîne les passions

Le , par Idelways, Expert éminent sénior
Le scan d'une feuille d'examen fait le buzz sur Internet. Il déchaine les passions sur les blogs et les sites spécialisés entre partisans des langages haut et bas-niveau.

L'étudiant y répond à la question qui demande de décrire la hiérarchie des langages de programmation et l'usage de chaque niveau. Mais sa réponse se prend un impitoyable zéro.

Étourdi ou incompris ?

Sa réponse est très simple (voire simpliste) mais pas complètement inintéressante : Plus le langage est convivial pour le développeur, plus lent sera le programme. Et plus le langage est « convivial pour l'ordinateur », plus rapide sera le programme.



Réponse stupide ? Provocante ? Ou plutôt bien vue ?

Et vous ?

Quelle note auriez-vous mis à cette réponse ?

Partagez-vous cette conception de la différence entre les langages haut et bas niveau ?

Préférez-vous les langages haut-niveau ou bas-niveau ?
Ce choix a-t-il été déterminant pour l'orientation de votre carrière de développeur ?

Lire aussi :

Un designer crée une nouvelle police de caractères pour développeurs censée faciliter l'écriture du code, comment la trouvez-vous ?

En collaboration avec Gordon Fowler


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de arkhamon arkhamon - Membre éprouvé https://www.developpez.com
le 22/03/2012 à 15:40
Allez c'est jeudi, et ça fait longtemps que j'ai pas fait mon sale caractère.
Cet étudiant mérite.... 0, 0 et mille fois 0 !
On lui demande une chose, il ne répond pas à la question, répond à une autre qu'on ne lui a pas posé, et en plus sort des conneries ! Donc mille fois 0 !

Je m'explique :

Au début était... Le binaire. Pour ceux de mon âge ou plus, rappelez vous si vous avez bossé sur un nano-ordinateur : 8 interrupteurs, un bouton reset et un bouton run... Ca c'est du binaire, encore appele langage machine, ou L1G. C'est le seul compris par l'ordinateur. Pour le coup, pas très convivial mais bon... Ici la dépendance est au niveau de l'ordinateur lui même !

Vient ensuite l'assembleur :
LD AH, ...
MOV ...
PUSH AL...
Que du bonheur ! On est déjà en dehors de ce qui est compréhensible par la machine, puisqu'on est obligé de passer par un pseudo compilateur (ASM et EXE2BIN ça vous rappelle de (mauvais) souvenirs ?
Ca c'est L2G. La dépendance est au niveau du micro-processeur, et dans certains cas de la machine et/ou de l'OS (si si rappelez vous l'appel des interruptions DOS (surtout celles non documentées)...)

Bonheur suprême : BASIC, Pascal COBOL, Fortran, ADA, JAVA, Shell Unix (ben oui c'est aussi un L3G)... Le royaume de l'informatique, l'eldorado des programmeurs... Enfin des boucles compréhensibles, de la récursivité (presque) contrôlée, des données évoluées... Tiens vous notez comment j'ai volontairement pas parlé de C ? Bon d'accord, en fervent défenseur de Pascal, je suis de mauvaise foi... Bien sur que C a aussi sa place ici !
Certains sont interprétés (Basic, VB), d'autres compilés (C, Pascal, Ada), certains enfin sont pseudo compilés, on parle de P-code (Cobol, JAVA...) et ça nécessite un compilateur et un interpréteur (cherchez l'erreur).
J'oubliais : on est en L3G. Ca y est, on est enfin indépendant du processeur et de la plateforme. Et même dans certains cas (le seul intérêt du P-Code à mon avis), on est multi plateforme !

Viennent ensuite les langages de manipulation de données type SQL : là on s'éloigne temporairement des notions de programmation standards et on se tourne vers la manipuilation de données hiérarchisées, relationnelles... C'est les L4G. Là on est totalement indépendant de l'OS aussi : c'est l'ère du client-serveur, de Saint Oracle...

Et quand on a fait tout ça on fait quoi ? On essaie d'être intelligents (ou du moins de faire croire que les machines le sont) et on attaque les L5G : les langages de manipulation de prédicats pour l'intelligence Artificielle (LISP, Prolog....). Perso je suis hermétique, mais bon... Bon là je sais plus trop de quoi on dépend en fait... Notez bien que même ici, on passe par un interpréteur ou un compilo, puisque de toutes façons...

AU FINAL, ON REVIENT TOUJOURS AU BINAIRE !!!!!

Voila ce qu'une bonne réponse (si j'ai fait une coquille dites le moi) eut pu être. Mais certainement pas ce qu'il a marqué !

Après pour ce qui concerne la convivialité et tout le reste, faut voir. Certaines personnes adorent le C, d'autres le Pascal, j'avais un pote en ingé qui était tri-lingue : Français, Anglais et assembleur 80386, et qui ne comprenait pas qu'on passe par un compilo avec ces langages de tapette alors qu'on peut tout faire en ASM... Je respecte, et suis même u peu jaloux...

Ensuite les perfs... Là je m'amuse. A plateforme identique (je veux dire même machine et même OS), qu'est ce qui fait la différence de perf sur un même résultat ? Je parle bien de resultat et pas de soft, la nuance est subtile :
  • la qualité du progragrammeur, qui sait (ou pas) générer un code optimisé (genre on balaye une liste jusqu'à ce qu'on ait trouvé l'élément et pas tout balayer)
  • la qualité du code produit par le compilateur
Vous remarquerez que je laisse de côté les langages interprétés, ils sont effectivement plus lents. Que dire alors du P-Code...

Donc, pour un même algorithme (mot utilisé volontairement), la seule différence de performance se situe dans le code généré par le compilateur. Si celui ci est optimisé, alors le code est plus rapide ou moins gourmant...
Certains compilateurs (dont Turbo PAscal et delphi après) optimisent déjà certaines choses. Ainsi dans le code suivant (et avec la bonne option de compilation qui va bien) :
Code : Sélectionner tout
1
2
3
if false and MaFonction(argument) then 
  begin 
  end;
l'appel à la fonction MaFonction ne sera jamais exécuté car il est inutile, le résultat du test étant de toutes façons "False". Notez bien que si je tenais le programmeur qui a pondu ce code, je le....

En conclusion, à mon avis, entre mêmes générations de langages, et même mode d'exécution, AUCUN langage n'est plus rapide ni performant qu'un autre, tout dépend du compilateur.
Avatar de Gecko Gecko - Membre éprouvé https://www.developpez.com
le 22/03/2012 à 22:22
arkhamon>

Grace à toi j'aurais appris des chose super intéressantes ^^
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 23/03/2012 à 6:52
Citation Envoyé par arkhamon  Voir le message
Allez c'est jeudi, et ça fait longtemps que j'ai pas fait mon sale caractère.
Cet étudiant mérite.... 0, 0 et mille fois 0 !

alors j'ai fait un peu de math dans mon jeune temps et j'en ai gardé (entre autre) que mille fois 0 ça fait toujours 0

ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit
Alors évidemment il était question de projets qui nécessitaient des temps de réponse particuliers, comme mon émulateur CBM64 qui tournerai parfaitement et sans optimisation sur un PC moderne, mais pas sur un 286
Avatar de Tommy31 Tommy31 - Membre chevronné https://www.developpez.com
le 23/03/2012 à 8:36
Citation Envoyé par Paul TOTH  Voir le message
ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit


D'où l'existence de la confortable directive assembleur, dont je me suis beaucoup servi étant plus jeune pour l'optimisation.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
 
Begin 
  ... 
  asm 
    ... 
  end; 
  ... 
End;
Avatar de arkhamon arkhamon - Membre éprouvé https://www.developpez.com
le 23/03/2012 à 8:49
Citation Envoyé par Paul TOTH  Voir le message
alors j'ai fait un peu de math dans mon jeune temps et j'en ai gardé (entre autre) que mille fois 0 ça fait toujours 0

J'adore le pragmatisme des mathématiciens Tout à fait d'accord. Un peu d'humour ne nuit jamais dans ce monde de brutes !

Citation Envoyé par Paul TOTH  Voir le message
ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit
Alors évidemment il était question de projets qui nécessitaient des temps de réponse particuliers, comme mon émulateur CBM64 qui tournerai parfaitement et sans optimisation sur un PC moderne, mais pas sur un 286

Effectivement j'ai le souvenir d'avoir fait ça pour m'amuser car je n'ai jamais développé de trucs ayant de tels besoins de perfs. Un peu avec mon ZX81 quand il avait 1 KO de RAM ouais ouais vous avez bien lu, mais bon c'était au siècle dernier... Effectivement Paul, tu as raison, Turbo pascal, comme la presque totalité des L3G, est moins rapide que du code ASM inséré dedans, car en général le compilateur doit être assez général, donc il génère un code assez gros et aps forcément optimisé. On retrouve ici le vieux débat entre processeurs RISC (Reduced Instruction Set) et CISC (Common Instruction Set) : plus le proc est capable de faire de choses différentes, plus il met de temps à décoder ce qu'il doit faire. Pareil pour un compilo...
Mais tu as parfaitement raison...
Avatar de ALT ALT - Membre expérimenté https://www.developpez.com
le 23/03/2012 à 10:17
Euh non !
CISC = Complex instruction set code.
Avatar de arkhamon arkhamon - Membre éprouvé https://www.developpez.com
le 23/03/2012 à 13:17
Citation Envoyé par ALT  Voir le message
Euh non !
CISC = Complex instruction set code.

Oopps si je me mets à raconter des conneries moi... Oui effectivement, erreur de ma part...
Avatar de romuald59220 romuald59220 - Membre à l'essai https://www.developpez.com
le 07/01/2014 à 18:59
Alors ? Tous d'accord pour son 0 pointé ?

Rappel de sa réponse :
"Plus le langage est convivial pour le développeur, plus lent sera le programme. Et plus le langage est « convivial pour l'ordinateur », plus rapide sera le programme."
Avatar de CodeurPlusPlus CodeurPlusPlus - Membre expérimenté https://www.developpez.com
le 08/01/2014 à 2:29
Citation Envoyé par arkhamon  Voir le message
(...)

En conclusion, à mon avis, entre mêmes générations de langages, et même mode d'exécution, AUCUN langage n'est plus rapide ni performant qu'un autre, tout dépend du compilateur.

Il n'y a donc plus qu'à écrire un compilateur Python qui fera mieux que n'importe quel compilateur C... ainsi les gentils rêveurs qui nous expliquent que les langages de haut niveau sont plus rapides que les langages de bas niveau pourront enfin avoir raison.

Sinon je ferais remarquer qu'il ne faut pas prétendre, comme certains l'ont fait, que la question posée était stupide. Parce qu'il faudrait savoir ce qu'il y avait dans le cours pour juger de la pertinence de la question.
Avatar de - https://www.developpez.com
le 08/01/2014 à 9:18
A en juger par le volume de discussions, ça ressemble plus à un sujet de philo que d'informatique pure

Steph
Avatar de rinhary rinhary - Nouveau Candidat au Club https://www.developpez.com
le 26/03/2014 à 4:50
ceci est un échantillonnage d'après moi.
réponse: vous deviez assurer vos connaissances entre manipulation, compilation et exécution des données
Offres d'emploi IT
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil