Pas eu le temps de lire en detail (c'est vrai que ce ne sont vraiment pas des pros de l'ergonomie web, le site est balourd. Et le matrix shell est pathetique), mais il y a l'air d'y avoir plein de bonnes choses.
Lier de nouveaux concepts d'OS a une nouvelle forme de langage, c'est une demarche qui a deja connu le succes (unix+C. Par des chercheurs, dont la page gopher aurait surement ete naze si elle avait existe).
Les langages a prototypes sont peu utilises, en partie parce qu'on ne sait pas trop bien les compiler, parce que les classes forcent a structurer meme quand le programmeur est bordelique (voir a ce sujet la disctinction entre Languages for Masses / Languages for Smart People sur http://www.paulgraham.com/vanlfsp.html(...)), parce qu'il est presque impossible de changer les paradigmes de programmation dans l'industrie (Java/C++, c'est quand meme sympa, ca ressemble plus a de l'ALGOL qu'a un language objet hardcore. Ca fait moins peur au COBOListe dans l'ame). D'un autre cote, la distinction entre classe et objet, notamment, devient assez artificielle des qu'on a les fonctions commes valeurs du 1er ordre (un langage fonctionnel, quoi). A part que les classes facilitent un peu le typage (essentiellement, seuls les objets acceptent la subsomption, seules les classes acceptent l'extension. Ces deux features sont difficiles a faire cohabiter), mais bon, il y a d'autres facons de faire. Et surtout, les classes obligatoires alourdissent beaucoup les relations d'heritage. Mais ca permet de faire des "stuff which looks like work" : des beaux schemas UML qui impressionnent le chef (un ancien commercial evidemment), et d'interminables dissertations sur les strategies laborieuses qui permettent de contourner les faiblesses du modele a classes (genre le visitor pattern, et en fait l'essentiel du contenu du bouquin "design patterns").
dans un langage a protos, on peu assez facilement definir les choses de facon incrementale tres fine. Ca permet d'eviter les metaphores binaires, e.g. au lieu de dire "tout est un fichier" ou "un fichier c'est un fichier et rien d'autre", pour gerer par ex. les sockets. on peut dire "une socket c'est un fichier sauf que foo et bar" (et ce plus facilement qu'avec un langage a classes). La facon d'Unix de faire ca (les sockets, les devices, tout ce qui est "a peu pres" un fichier) est pour le moins laborieuse, c'est un exemple typique de leaking abstraction (tres bien explique sur le pas tres linuxophile http://www.joelonsoftware.com/articles/LeakyAbstractions.html(...)). Idem, pour construire un driver pour une carte reseau precise, on a "juste" a frobnifier l'implementation la plus proche, qui peut etre plus ou moins generique. Plus fin, comme approche, que l'utilisation de librairies, plus agreable et maintenable que de copier-coller de paves de codes d'un driver a l'autre.
Un truc, son langage n'a pas l'air fonctionnel (au sens fonctions du 1er ordre, a verifier en lisant toute la doc), ou au moins, il n'en fait pas la promotion. Pour les couches tres bas niveau c'est normal, mais des qu'on passe a des trucs moins proches du metal, ca va manquer cruellement. Ca fait 40 ans (Lisp en gros, voir meme plus, cf. lambda calcul vs. machine de Turing) qu'on sait que les langages fonctionnels sont plus puissants, expressifs, concis etc., meme s'ils exigent plus de capacite d'abstraction pour le programmeur. Meme dans un langage aussi bondage&discipline que Java ils ont introduit les fonctions anonymes et les fermetures (enfin, il vont le faire avec la 1.5). En plus, avec les fonctions du 1er ordre, le passage des classes aux prototypes est tout naturel (essentiellement, ca supprime la necessite de distinguer champs et methodes).
Bref, la presentation est pas top, mais la piste est prometteuse, les resultats apparement excellents, la marge de progression probablement encore plus vertigineuse.
# Re: Un nouveau système d'exploitation architecturalement révolutionnaire
Posté par Fabien F. . En réponse au journal Un nouveau système d'exploitation architecturalement révolutionnaire. Évalué à 1.
Lier de nouveaux concepts d'OS a une nouvelle forme de langage, c'est une demarche qui a deja connu le succes (unix+C. Par des chercheurs, dont la page gopher aurait surement ete naze si elle avait existe).
Les langages a prototypes sont peu utilises, en partie parce qu'on ne sait pas trop bien les compiler, parce que les classes forcent a structurer meme quand le programmeur est bordelique (voir a ce sujet la disctinction entre Languages for Masses / Languages for Smart People sur http://www.paulgraham.com/vanlfsp.html(...)), parce qu'il est presque impossible de changer les paradigmes de programmation dans l'industrie (Java/C++, c'est quand meme sympa, ca ressemble plus a de l'ALGOL qu'a un language objet hardcore. Ca fait moins peur au COBOListe dans l'ame). D'un autre cote, la distinction entre classe et objet, notamment, devient assez artificielle des qu'on a les fonctions commes valeurs du 1er ordre (un langage fonctionnel, quoi). A part que les classes facilitent un peu le typage (essentiellement, seuls les objets acceptent la subsomption, seules les classes acceptent l'extension. Ces deux features sont difficiles a faire cohabiter), mais bon, il y a d'autres facons de faire. Et surtout, les classes obligatoires alourdissent beaucoup les relations d'heritage. Mais ca permet de faire des "stuff which looks like work" : des beaux schemas UML qui impressionnent le chef (un ancien commercial evidemment), et d'interminables dissertations sur les strategies laborieuses qui permettent de contourner les faiblesses du modele a classes (genre le visitor pattern, et en fait l'essentiel du contenu du bouquin "design patterns").
dans un langage a protos, on peu assez facilement definir les choses de facon incrementale tres fine. Ca permet d'eviter les metaphores binaires, e.g. au lieu de dire "tout est un fichier" ou "un fichier c'est un fichier et rien d'autre", pour gerer par ex. les sockets. on peut dire "une socket c'est un fichier sauf que foo et bar" (et ce plus facilement qu'avec un langage a classes). La facon d'Unix de faire ca (les sockets, les devices, tout ce qui est "a peu pres" un fichier) est pour le moins laborieuse, c'est un exemple typique de leaking abstraction (tres bien explique sur le pas tres linuxophile http://www.joelonsoftware.com/articles/LeakyAbstractions.html(...)). Idem, pour construire un driver pour une carte reseau precise, on a "juste" a frobnifier l'implementation la plus proche, qui peut etre plus ou moins generique. Plus fin, comme approche, que l'utilisation de librairies, plus agreable et maintenable que de copier-coller de paves de codes d'un driver a l'autre.
Un truc, son langage n'a pas l'air fonctionnel (au sens fonctions du 1er ordre, a verifier en lisant toute la doc), ou au moins, il n'en fait pas la promotion. Pour les couches tres bas niveau c'est normal, mais des qu'on passe a des trucs moins proches du metal, ca va manquer cruellement. Ca fait 40 ans (Lisp en gros, voir meme plus, cf. lambda calcul vs. machine de Turing) qu'on sait que les langages fonctionnels sont plus puissants, expressifs, concis etc., meme s'ils exigent plus de capacite d'abstraction pour le programmeur. Meme dans un langage aussi bondage&discipline que Java ils ont introduit les fonctions anonymes et les fermetures (enfin, il vont le faire avec la 1.5). En plus, avec les fonctions du 1er ordre, le passage des classes aux prototypes est tout naturel (essentiellement, ca supprime la necessite de distinguer champs et methodes).
Bref, la presentation est pas top, mais la piste est prometteuse, les resultats apparement excellents, la marge de progression probablement encore plus vertigineuse.