De l'abstraction d'un langage bas-niveau

Bonjour,

Établissons :
- "A" : "un langage de programmation haut-niveau (grosse couche d'abstraction)"
-- "α" : "un programme écrit en A et compilé"
- "B" : "un langage de programmation BAS-niveau (genre C)"
-- "β" : "un programme écrit en B et compilé"

Est-il vrai que β s'éxecutera plus rapidement que α ? Si non, pourquoi ?

A devrait être capable de remplacer sa couche d'abstraction par du code bas-niveau... à moins que je ne confonde langage haut-niveau et abstraction : contrairement à B, A ne peut remplacer sa couche d'abstraction par le code bas-niveau original puisque A est tout sauf bas-niveau !

En ne confondant pas "langage haut-niveau" et "abstraction" :

Si B possède une belle couche d'abstraction : équivalente au haut-niveau de A ;
Quelles seront leurs (α et β) vitesse d'exécution comparées ? vα < vβ ? (avec vх vitesse d'exécution de х)


Questions subsidiaires :
Le paradigme d'un langage (OO, impératif, fonctionnel, ...) peut-il évoluer en fonction de son niveau d'abstraction ? Exemple C -> C++ <=> impératif -> OO-impur

Existe-t-il un langage bas-niveau compilé permettant une grande abstraction (équivalente au DSL) ? La compilation prendrait du temps mais le programme en résultant serait rapide, j'pari !

Déjà une remarque sur le titre, le niveau d'abstraction d'un langage bas niveau est... bas !

Citation : Radioxid
C'est souvent le cas, mais le contraire est possible.

Pourquoi ? Simplement car ça dépends de l'implémentation, pas du langage en lui même. Un code bas niveau compilé avec mauvais compilateur risque d'être lent (sauf si le programmeur tout fait pour contourner les défauts du compilateur). Inversement, avec un bon compilateur qui optimise bien, on peut avoir un langage très haut niveau qui soit rapide (par exemple du Common Lisp compilé et bien optimisé arrive à des niveaux de perfs comparables à du Java ou du C#, qui sont eux-même pas très loin du C et du C++).

Citation : Radioxid
Gné ?

Faudrait détailler un peu parce que je suis pas certain de comprendre pourquoi tu te contredis entre la première partie et la seconde...

Citation : Radioxid
Voir première partie de la réponse : tout dépend de l'implémentation et du talent du programmeur.

Citation : Radioxid
Un langage normalement c'est relativement figé : C et C++ sont deux langages différents.

Citation : Radioxid
Un langage bas niveau = faible abstraction, contrairement à un langage ayant un faible niveau d'abstraction.

Tu sépares le "niveau" d'un langage et son abstraction, mais pour moi c'est la même chose, si tu pouvais préciser ta pensée...

Le C++ ou l'Objective-C sont basés sur le C; pour moi, ils sont du C avec une couche d'abstraction. C'est-à-dire qu'ils sont transformés en C puis en langage machine et non directement en langage machine. c'est là que se situe pour moi la différence entre langage haut-niveau et langage bas-niveau + couche d'abstraction.

: pour moi l'abstraction se fait dans le code du programme et le niveau est uniquement relatif au langage.

Je pense qu'on peut remonter le niveau d'un langage en utilisant l'abstraction : on peut se passer des pointeurs en C++ grâce aux objets...
Une fonction c'est déjà de l'abstraction.

Ma question la plus précise est celle-ci :
En ne confondant pas "langage haut-niveau" et "abstraction" :

Si B possède une belle couche d'abstraction : équivalente au haut-niveau de A ;
Quelles seront leurs (α et β) vitesse d'exécution comparées ? vα < vβ ? (avec vх vitesse d'exécution de х) Avec des compilateurs et implémentations de qualité identiques; ce sont les langages que je souhaite comparer.

Citation : Radioxid
autant c'était vrai au début pour le C++, autant ça fait longtemps que c'est plus le cas.

Citation : Radioxid
Mouais, ça n'a pas trop de sens, un langage est défini par une certaine syntaxe, son niveau d'abstraction dépends du langage lui-même, pas de son implémentation.

Citation : Radioxid
Oui, mais si on modifie un langage existant, on se retrouve avec un nouveau langage différent du premier

Citation : Radioxid
Typiquement les programmes produits par un langage plus bas niveau, même avec une surcouche, ont un niveau de perfs élevé alors qu'un langage de niveau plus élevé sera plus lent. Après c'est difficile de comparer la qualité de deux implémentations de deux langages différents, donc c'est impossible de te faire une réponse absolue.

On peut dire qu'un langage de programmation haut niveau falicite/rend possible/encourage l'abstraction.
Il faut ensuite définir l'abstraction, mais globalement il est vrai que la compilation d'un code écrit dans un langage bas-niveau produit un exécutable plus performant qu'un équivalent partant d'un langage de haut niveau.
Ce qui est d'ailleurs logique puisque le bas-niveau est plus proche du langage machine, et donne un contrôle plus important au programmeur sur l'exécutable final contrairement au langage de haut niveau dont le compilateur cherchera de manière automatique (et donc moins performante) à traduire le programme vers du langage machine ( donnant lieu à des constructions peu efficaces).

Pour moi, tout dépend du langage en question, et surtout de la façon de programmer... Genre si tu fait un truc bien moche en bas niveau, le programme s'exécutera moins vite que du code propre en "A". Pareil avec l'exemple des langages différents, tu prends un langage comme le caml (que tu va apprendre l'année prochaine d'ailleurs ), certain programmes seront beaucoup plus efficace qu'en C par exemple. Après encore tout dépend de ta façon de coder...
Faut trouver le compromis quoi...

Tiens ? Camille ? (en fait j'pense faire une prépa MPSI avant d'envisager aut'chose, genre ENSIMAG)

Là je pense pluss comparer les langages plutôt que les optimisations moches qu'on peut faire (relatives au langage et non à l'algorithme)...

En Common-Lisp, les macros permettent la création et l'usage de http://en.wikipedia.org/wiki/Domain-specific_language ; ça c'est une forme claire d'élévation du niveau du langage avec une couche d'abstraction. Même si CL n'est pas bas-niveau...

Si on peut réélever le niveau d'un langage par l'abstraction, de la même manière peut-on en changer le paradigme ? CL le peut mais il est déjà multiparadigme... Y a-t-il un paradigme pour les gouverner tous ?

C'est ridicule de parler de changer le paradigme d'un langage.
Le paradigme est inhérent à celui-ci.
Ainsi, un langage est fonctionnel si il encourage la programmation fonctionnel, ce qui ne veut pas dire qu'on ne peut pas programmer dans un style fonctionnel dans un langage non fonctionnel.

Tu pourrais programmer en fonctionnel avec du Basic ?

Je pourrais adopter un style fonctionnel en Basic, ça oui.

Pas dans tous les Basic. Programmer dans un style fonctionnel sans fonctions d'ordre supérieur et sans récursivité (entre autres), ça ne signifie pas grand chose.

Comme je l'ai dit un langage est fonctionnel s'il encourage (et permet) de programmer dans un style fonctionnel.
Donc un langage non fonctionnel, par sa sémantique, n'est clairement pas destiné à la programmation fonctionnel bien qu'il ne soit pas non plus impossible d'y programmer dans un style fonctionnel.
Ensuite tout dépend du langage : en Python, il est possible (et facile) d'adopter un style fonctionnel; je conçois par contre mal la chose en Brainf*ck.

Sans connaître le Basic (je n'ai pas que ça à faire), je sais qu'il inclut des instructions GOTO (oh qu'il est vilain !), qui rend possible d'implémentation de la notion de fonction (procédure à plus forte raison), récursive qui plus est.

"Comme je l'ai dit un langage est fonctionnel s'il encourage (et permet) de programmer dans un style fonctionnel."

Oui, mais il y a une différence entre programmer "en fonctionnel" et ce que tu appelles "dans un style fonctionnel". Le style fonctionnel implique de ne pas faire d'effets de bord (plus ou moins selon la pureté du langage, mais pas systématiquement : un goto n'a rien à voir avec du récursif) par exemples. En Basic, affecter une variable à une certaine valeur avant de revenir au début de la fonction avec un goto n'a rien à voir avec une fonction récursive, même si dans les deux cas ça peut ressembler à "on change la valeur et on recommence".

Idem pour passer une fonction en argument à une autre fonction, dans de très nombreux basic (tous ?), c'est impossible, et idem, les goto ne sont pas la solution équivalente.

Une procédure basic n'est *pas* une fonction comme elles sont prévues dans le paradigme fonctionnel. Elle agit le plus souvent par effet de bord, qui est justement ce que les fonctions, la récursivité, les monades etc. cherchent à éviter.

Oui, mais il faut savoir le paradigme fonctionnel est étendu; il existe des caractéristiques qui ne trompent pas, quand on a des connaissances réelles, on peut facilement faire la par des choses entre ce qui est fonctionnel ou non.

Pour ce qui est du Basic, il est clair que ce n'est pas un langage propice à l'adoption d'un style fonctionnel; il n'en possède pas les outils sémantiques. Il n'empêche que la façon de penser du programmeur pourra être "fonctionnelle" (c'est un cas imaginaire), dès lors il peut se refuser à la mutation de donnée ou aux effets de bords (évités dans le style fonctionnel) et se concentrer sur le calcul de valeur (même si la syntaxe ne suit pas).
Pour simuler une "fonction d'ordre supérieur", il suffirait de passer en argument le numéro de ligne du début d'une fonction qui serait appelée.

Bref, tous ça pour dire qu'il ne faut pas faire l'amalgame entre programmation fonctionnelle et langage de programmation de paradigme fonctionnel (comme nous le montre bien OCaml qui fournit les outils adaptés à la programmation fonctionnelle mais dans lequel on peut égaler programmer impérativement ).

Donc plusieurs paradigmes peuvent coexister.

Mais un paradigme peut-il en engendrer un autre ?

Dans quel sens ? Explique-toi, car nue comme ça, ta question n'a pas de sens.

"(comme nous le montre bien OCaml qui fournit les outils adaptés à la programmation fonctionnelle mais dans lequel on peut égaler programmer impérativement ). "

Ocaml est fonctionnel et impératif. Donc tu peux faire les 3.
Basic est uniquement impératif. Donc pas de fonctionnel.

Par exemple : on a le BrainFuck ou une série de commandes simples pour parcourir une mémoire et changer le contenu de ses cases. Typiquement, un language simple mais Turing-complet.

Avec de bonnes macro (à la mode du C), on pourrait augmenter le niveau d'abstraction du BF, tout en préservant son bas-niveau. Dans ces macros, on peut ensuite choisir de changer le paradigme ?

up please

La notion de "paradigme" est très mal définie. Je serais très étonné d'apprendre que vous donnez tous la même signification à ce mot. Il veut un peu tout dire et il ne me semble pas productif d'essayer de discuter en mettant ce terme à la base du sujet.

Je pense, comme EMC1, que l'on pourrait par un ensemble de traductions compliquées (que l'on ne peut pas résumer à des macros, il faut traiter globalement le programme pour obtenir par exemple des fonctions d'ordre supérieur en l'absence de "computed goto" ou équivalent), utiliser des techniques de programmation fonctionnelle en Basic. Ce serait certainement très lourd syntaxiquement (mais ici des macros pourraient améliorer la chose), et sans doute sensiblement plus lent (à un facteur multiplicatif)) qu'en utilisant le style procédural classique.



Par ailleurs, je trouve que la réponse de LoupSolitaire sur la relation entre le niveau d'abstraction d'un langage et ses performances n'est pas satisfaisante. Il a répondu en substance "tout dépend des implémentations", mais je pense qu'on peut dire plus de chose.

Par exemple, en reprenant l'exemple de départ, on peut imaginer une implémentation du langage A, de haut niveau, qui traduise chaque programme vers un programme du langage B, de bas niveau, et réutilise l'implémentation du langage B. Cela permet d'avoir une base commune pour comparer.

Dans le langage A, il y a :

- des concepts qui ressemblent à ceux du langage B : on peut traduire très simplement du code qui les utilise vers du code dans le langage B. Aucune perte de performances (mais aucun gain en expressivité du langage puisqu'on fait la même chose qu'avant)

- des concepts qui sont beaucoup plus généraux, avancés, et puissants que ceux du langage B. Ceux-là sont difficiles à traduire vers le langage B, puisqu'il s'agit de réduire le niveau d'abstraction : il se passe quelque chose d'important. Une traduction générale de ces concepts vers le langage B sera sans doute coûteuse, puisqu'elle demandera des transformaitons peu naturelles et sans doute un certain nombre de manipulations.

Un programme utilisant ces concepts, codé dans le langage A, et traduit uniformément (chaque concept est traduit dans le cas le plus général), sera nettement plus lent qu'un programme codé dans le langage B sans utiliser ces concepts avancé ou leur équivalent. En même temps, ce programme du langage B sera certainement moins élégant, plus difficile à maintenir que celui du langage A, puisqu'il ne peut pas profiter de l'expressivité supplémentaire.

Dans le cas extrême où le programme exige des manipulations compliquées, équivalentes à la fonctionnalité puissante du langage A, le programmeur devra écrire un programme équivalente à la traduction d'un programme du langage A, mais directement dans le langage B (faisant ainsi le travail du compilateur), ce qui n'est pas agréable, et produit un code au final aussi performant qu'en A.


En bref, le cas intéressant est le cas où on utilise des fonctionnalités puissantes du langage A, qui sont difficiles à traduire vers le langage B. Il y a deux points supplémentaires à évoquer pour avoir une vision mêm simple du sujet.

D'une part, j'ai évoqué une "traduction uniforme". Par exemple, si dans le langage A, on a des fonctions d'ordre supérieur, chaque appel de fonction peut être une indirection vers une fonction stockée dans une variable (par exemple passée en paramètre). Si on traduit chaque appel de fonction dans le langage A vers du code du langage B comprenant cette indirection, les performances vont être très mauvaises, par rapport à un simple appel direct dans le langage B. Mais il y a de nombreux cas dans un programme du langage A où un appel de fonction n'est en fait pas une indirection, et peut être traduit vers un appel direct du langage B. Avec une traduction "non uniforme", qui exploite ces spécificités, on peut traduire ces cas spécifiques de manière aussi efficace que dans le langage B (c'est ce qui est d'ailleurs fait en OCaml par exemple, les appels statiquement déterminés sont optimisés, et le traitement de la curryfication est semblable).
Dans le meilleur des cas, on peut en fait dire qu'un traducteur intelligent du langage A vers le langage B pourra choisir la traduction la plus adaptée, et ainsi ne faire payer le coût des fonctionnalités puissantes (expressives) de A que lorsqu'elles sont réellement utilisées, et pas lorsqu'on les utilise dans des cas où l'expressivité moindre du langage B suffit. Évidemment en pratique un traducteur n'est jamais idéal, et il y a toujours des cas où il pourrait traduire mieux, ce qui fait qu'en général un tel traducteur produira des programmes (légèrement) moins efficaces.

D'autre part, le langage A de plus haut niveau a plus d'information à sa disposition que le langage B de plus bas niveau. Il peut apporter des fonctionnalités puissantes qui ne font que compliquer la traduction (par exemple la possibilité d'obtenir une variable en fournissant son nom sous forme de chaîne de caractère pendant l'exécution, fonctionnalité aussi puissante que détestable et difficile à traduire de façon efficace), mais il peut aussi apporter des informations supplémentaires sur les programme qui au contraire augmentent les possibilités d'utilisation. Par exemple, si le langage A n'a pas d'arithmétique des pointeurs, il y a beaucoup moins de phénomènes d'aliasing possible (deux variables pointent en fait sur la même information), et le traducteur peut en tirer parti pour réordonner le code de façon plus efficace, alors qu'une fois traduit dans le langage B, cette information est perdue et il est très difficile pour l'implémentation du langage B d'utiliser cette possibilité, même (en général) pour du code qui vient directement de la traduction du langage A.
Cette opportunité d'optimisation supplémentaire est encore plus grande dans le cas général où le langage A est traduit vers le langage de son choix, pas nécessairement le langage B, puisque la traduction peut alors exploiter des garanties que le langage B ne permet pas forcément d'exprimer (par exemple, que deux expressions peuvent être calculées en parallèle).
Ce phénomène fait qu'en général, si tu écris un programme dans le langage haut niveau A, et un programme équivalent dans une couche d'abstraction de B, le programme de A sera en fait plus rapide, car l'implémentation de A saura utiliser ces informations, alors que l'implémentation de B (après traduction de la couche d'abstraction) ne le fait pas. Bien sûr, on pourrait imaginer qu'elle le fasse par des analyses très compliquées (on rejoint l'idée de la traduction "optimale" du point précédent), mais ce n'est en général pas réalisable en pratique. Il est en général très difficile de récupérer cette information dans le langage B, beaucoup plus difficile en général que ce dont je parlais dans le premier point, trouver les endroits du langage A où la pleine puissance des constructions n'est pas nécessaire.


Il apparaît dans ces deux points que tous les langages de haut niveau ne sont pas égaux en matière d'implémentation. Il faut faire des choix entre l'expressivité supplémentaire que l'on apporte au programmeur, et les garanties que l'on a sur les programmes. Certaines fonctionnalités apportent beaucoup d'expressivité, mais détruisent toutes les garanties que l'on pourrait vouloir dans le cas général (il faut alors les récupérer partiellement en faisant des analyses plus fines). La conception d'un langage de programmation est une activité délicate qui demande de garder ce genre de considération à l'esprit. Si on a du mal à optimiser correctement beaucoup de langages "haut niveau" à la mode (Python, Javascript, etc.) c'est avant tout parce qu'ils possèdent des fonctionnalités qui rendent difficile une traduction efficace.

Enfin, cette tension entre expressivité et invariants des fonctionnalités du langage n'est pas importante que pour les implémenteurs, elle joue aussi un rôle important sur les programmeurs, qui doivent eux aussi raisonner sur les programmes. Un langage qui apporte peu de garanties sera plus difficile à comprendre ou à débugguer, par exemple.