Discussion :

[kripteks]

Salut à tous.

Voila, pour commencer, je n'ai jamais fait d'assembleur. J'ai juste une connaissance globale.

De nos jours, les systèmes (d'exploitation ou autres) sont un peu pourris, ce que je veux dire, c'est fonctionnel, mais: pas stable, pas durable, pas compatible, etc.

Et tous cela (je pense) à cause des multiples langages bas niveau/haut niveau + les outils créés par ces derniers qui font que sortir des nouvelles versions créant des incompatibilités sans arrêt et de manière assez rapidement, ce qui fait qu'ils deviennent instables et non durables.

Je me demandais si un système fait en assembleur et d'une bonne manière aurait pu ou pourra éviter cela, pour en résulter: un système stable, compatible et durable.

[Obsidian]

Voila, pour commencer, je n'ai jamais fait d'assembleur. J'ai juste une connaissance globale.

De nos jours, les systèmes (d'exploitation ou autres) sont un peu pourris, ce que je veux dire, c'est fonctionnel, mais: pas stable, pas durable, pas compatible, etc.

Ça dépend, compatibles avec quoi ?

Ta question est loin d'être anodine et détermine en partie la voie que l'informatique devrait suivre à un moment donné. Mais avant tout, quels systèmes as-tu déjà pratiqué ? Par exemple, as-tu travaillé sous Unix, que l'on présente comme un modèle de solidité et de pérennité (même si ça se perd un peu aussi de ce côté-là, aujourd'hui).

Et tous cela (je pense) à cause des multiples langages bas niveau/haut niveau + les outils créés par ces derniers qui font que sortir des nouvelles versions créant des incompatibilités sans arrêt et de manière assez rapidement, ce qui fait qu'ils deviennent instables et non durables.

Il y a du vrai. Moi, j'appelle cela la théorie de la décharge à ordures : un terrain propre dont on se sert de base pour développer de nouveaux outils, de nouvelles infrastructures, etc. qui finissent par « forker » et/ou voir apparaître différents dialectes d'une même technologie. Quand ça devient ingérable, on recouvre le tout par une bonne couche de terre pour dissimuler tout cela, comprendre par là une « couche d'abstraction unifiée » censée simplifier les choses et ne présenter qu'une seule interface. Là dessus, de nouvelles technologies se développent et le processus reprend depuis le début.

Le problème c'est que toutes ces couches ne se remplacent pas les unes et les autres, mais se cumulent. Et le micro-processeur, en fin de compte, est obligé de toutes les prendre en charge, ce qui finit par devenir vraiment lourd.

Je me demandais si un système fait en assembleur et d'une bonne manière aurait pu ou pourra éviter cela, pour en résulter: un système stable, compatible et durable.

Hélas non, ce n'est pas l'assembleur qui t'apportera la solution, pour la bonne raison qu'il s'agit de la couche « la plus basse ». Tout le monde devrait y mettre les doigts au moins une fois dedans pour savoir comment leurs programmes sont réellement exécutés en fin de compte, mais l'assembleur est par nature ce qu'il y a de moins compatible : chaque famille de micro-processeurs est accompagnée de son propre assembleur qui est différent de celui des autres familles.

Ensuite, une fois que tu sais piloter le micro-processeur lui-même, il faut encore le faire dans l'environnement dans lequel il est installé. Aujourd'hui, les ordinateurs grand public sont quasi-exclusivement des PC, et même les iMac utilisent des processeurs Intel, ce qui, paradoxalement, recrédibilise l'assembleur puisqu'un même code peut fonctionner directement sur la totalité des machines.

Mais ça n'a pas toujours été le cas, et même des ordinateurs très différents les uns des autres peuvent partager le même micro-processeur : par exemple, le 68000, qui a équipé les Atari ST, les Amiga de Commodore et les… Mac ! Si le jeu d'instruction est le même, le matériel que dirigeait le micro-processeur était foncièrement différent, et pas du tout situé aux mêmes endroits dans le plan mémoire.

Par contre, les arguments que tu exposes sont ceux qui expliquent l'exceptionnelle longévité du langage C : on a coutume de dire qu'il se trouve « un cran au dessus de l'assembleur » même s'il s'agit d'un langage très différent. Ceci parce qu'il est très versatile, qu'il est très proche du fonctionnement réel d'un micro-processeur et parce qu'il limite au maximum les dépendances à des infrastructures sous-jacentes : en particulier, il est tout-à-fait concevable et même très répandu d'écrire en C un programme pour micro-contrôleur, sur lesquels toutes les fonctions de la bibliothèque standard sont rarement disponibles.

En outre, bien qu'apparu en 1972, le langage a été très bien conçu et si le développeur s'attache à respecter la norme, alors un programme C est en principe portable partout même sur des architectures très exotiques (par exemple celles qui n'utilisent pas l'octet comme format standard), à condition d'y apporter un tout petit peu de soin.

Ce qui va justifier, ensuite, l'apparition d'autres langages sont les changements de paradigmes dont la principale est la programmation orientée objet. Il est possible d'adopter une approche objet en C dans la conception de son programme mais comme le langage n'est pas spécialement prévu pour cela à la base, il faut tout vérifier à la main ce qui devient vite fastidieux. L'autre cas est formé par la différence entre langages compilés et interprétés. Dans ce dernier camp, le grand langage à la mode en ce moment est Python.

Pour tenter de t'apporter une réponse, disons que plus que les langages, ce qui va t'apporter aujourd'hui compatibilité et pérennité sont des standards ouverts et bien conçus.

« Bien conçus » est déjà une gageure parce qu'il faut tenter de viser juste dès le départ : ce sont rarement les standards les mieux imaginés qui font référence mais ceux qui sont sortis les premiers.

« Ouvert » signifie documenté, si possible normalisé par un organisme officiel et conçu de telle manière qu'on ne se retrouve pas dépendant du bon vouloir d'un organisme donné. Et ça, ce n'est pas facile du tout, d'abord parce que la majorité des utilisateurs ne sont pas sensibilisés à ce problème, ensuite parce certains grands acteurs de l'édition de logiciels ne voient pas cela du tout d'un bon œil : quand on a le pouvoir de fait, on ne va pas le céder exprès.

Note bien que ce problème de format de document n'a, pour le coup, rien à voir avec la programmation et que l'assembleur (ou tout autre langage) ne t'est d'aucun secours. Il en reste que c'est un enjeu crucial à long terme. Par exemple, beaucoup de gens utilisent Word pour écrire le moindre document, ce qui fait beaucoup enrager les gens qui (comme moi) n'utilisent pas Windows et parce que rares sont les personnes à utiliser ce traitement de texte qui possèdent effectivement la licence.

Récemment, une réflexion a été menée pour savoir quels formats et quels supports utiliser pour conserver des informations dans une centrale nucléaire. Ça n'a l'air de rien car l'informatique se renouvelle très vite et a donc toujours l'air « neuve ». Mais lire des documents écrits en 1990 commence déjà à poser problème. Il vaut mieux donc avoir traité ce problème avec soin.

[kripteks]

Je suis sous linux depuis environs 6-7 ans, mais depuis quelques jours je comptais passer sous un système unix et encore hier j'ai fait quelque teste sous virtualbox avant un passage futur.


Sinon, je suis totalement d'accord avec toi.

J'avais pas voulu donnée de nom de système pour rester globale, mais j'avais aussi en tête le système unix qui englobe tes dires comme bon exemple.

Suivre une bonne logique et standard est la meilleur chose à faire, ce que unix et sa philosophie semble le faire.

Mais malheureusement, tous n'est pas fait dans cet voie qui fait que tout devient mélangé.