Lisaac se veut un langage de très haut niveau comme Smart Eiffel et Self, tout en gardant un accès bas niveau au hardware et de bonne performance. Il se veut clairement un concurrent du C.
Il est à l'origine prévus pour écrire un OS : Isaac. On ne peut s'empêcher de faire le parallèle avec le C conçu pour Unix.
Une implémentation C et Lisaac d'un codeur mpeg2 ont été comparé et montre des performances similaires mais avec 30 % de ligne de code en moins pour Lisaac (notamment grâce à sa gestion automatique de la mémoire).
Lisaac est un langage à prototype à héritage dynamique et à contrat. Son compilateur génère du C ce qui lui permet d’être portable sur toutes les architectures où gcc existe.
C'est un langage très prometteur qui arrivera sans doute à remplacer le C avec de meilleures performances à terme et avec un plus grand confort de codage.
Aller plus loin
- La conférence (17 clics)
- Le site web (16 clics)
- La documentation du langage (15 clics)
- La page de Lisaac sur Wikipedia (15 clics)
- Self (4 clics)
- Smart Eiffel (10 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 8.
- Lisaac se vente d'être un conccurent du C. Moi je dis ok, donc Lisaac est destiné à être utilisé là où est utilisé le C. Donc première étape pour être utilisé, s'intégrer avec les autres bibliothèques écrites en C et inversement. Donc comment exporter des API en C ? Comment utilisé des API écrits en C ? (Si on arrive en C on arrivera dans d'autes langages)
- Plutôt que de faire un décodeur MPEG2, pourquoi ne pas montrer pleins de petits exemples beaucoup plus didactique ? Implémenter les algos les plus répendus, etc. Un peu plus que la factorielle et le hello world du site :)
- Pourquoi ne pas par exemple participer au benchmark http://shootout.alioth.debian.org/ ? On peut facilement y comparer les performances mais aussi admirer l'élégange d'un langage.
- Franchement ca sert à quoi de filer le code du compilateur sous la forme d'un unique fichier source C complètement illisible ? Le code Lisaac est bourré de brevets top-secret ?
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Euh ...
Posté par yesi . Évalué à 0.
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Euh ...
Posté par peco . Évalué à 3.
Ahhh, les trolls, on ne s'en lasse jamais...
[^] # Re: Euh ...
Posté par Joël SCHAAL . Évalué à 0.
[^] # Re: Euh ...
Posté par Thomas Douillard . Évalué à 5.
[^] # Re: Euh ...
Posté par yesi . Évalué à -4.
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 6.
Ce n'est pas encore très clair pour le moment, mais du fait que Lisaac est censé pondre des objets, c'est à dire un fichier C avec une liste de fonctions et quelques variables, compilable en un .o ensuite utilisé dans l'IsaacOS, on devrait pouvoir produire des API en Lisaac en C, l'idéal serait de générer aussi le .h
Comment utilisé des API écrits en C ?
Voir le manuel utilisateur.
Un exemple tout de même, le driver video adapté à X11, que tu trouveras dans la lib.
On inline le c entre quote inverse `
Plutôt que de faire un décodeur MPEG2, pourquoi ne pas montrer pleins de petits exemples beaucoup plus didactique ?
Parce que depuis deux ans, Benoit perd son temps entre des post-docs où on lui demande de faire des choses inutiles, ou de donner des cours. Faut bien vivre..; Et je pense que tu es au courant que pour un jeune chercheur, en France, c'est dur aujourd'hui.
Le décodeur Mpeg2 est une demande de ST
Pour te donner une idée, Benoit est en train de réécrire le compilateur quasi intégralement, il avait commencé... fin 2004, depuis il n'a jamais réussi à trouver le temps...
Pourquoi ne pas par exemple participer au benchmark http://shootout.alioth.debian.org/ ? On peut facilement y comparer les performances mais aussi admirer l'élégange d'un langage.
Je le ferai quand le compilateur sera libre, pour le moment seule la lib et l'OS le sont (pas encore publié sur le site, car on travaille à préparer la distrib, la doc, finir le compilo, etc... dans deux mois ça devrait être bon)
Le code Lisaac est bourré de brevets top-secret ?
C'est justement que c'est pas encore brêveté, c'est ça le problème, quand ça le sera, ça deviendra libre (normalement).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
Ce n'est pas encore très clair pour le moment
Autant dire que c'est indispensable si vous voulez que Lisaac devienne autre chose qu"un joujou d'universitaire.
Ah oui un autre truc : faire un langage avec 4 mot clés en donnant la possibilité de faire de nouveau mot clé par construction, c'est "cool", mais dans la vrai vie je préfère largement un langage qui m'impose les constructions standards, justement pour "standardiser" l'écriture du code ete le rendre intelligible par n'importe qui.
C'est justement que c'est pas encore brêveté, c'est ça le problème, quand ça le sera, ça deviendra libre (normalement).
Mon dieu !!!
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 5.
RMS lui même m'a conseillé (la mort dans l'âme il est vrai) de brèveter (ça ne m'amuse pas non plus.
Il s'agit de brèveter aux Etats-Unis
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 0.
Si il y a quelque chose de réellement innovant qui n'est pas encore était fait et que quelqu'un cherche à breveter cette technique dans le futur, vous pourrez toujours démontrer l'antériorité... A condition bien entendu de publier les sources dès aujourd'hui.
PS : Aux états-unis aussi ils disent tous porter des armes pour leur défenses.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
D'où la GPL V3, ou l'on donne également une licence sur tout brevet utilisé par le code.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
(PS: m'enfin il est toujours succulent de lire un partisan acharné de C# avoir peur de brevet logiciel sur un langage...)
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 0.
Et c'est quoi un capilo-quadrisectomieur ? :)
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Certe C# en lui-même n'est pas breveté mais seulement toutes ses API.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 1.
https://linuxfr.org/comments/673971,1.html
là
https://linuxfr.org/comments/674008,1.html
et un peu partout autour...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
on y trouve pas de brevet sur un API complet.
on y trouve une demande de brevet (grosse différence), et sur une partie des API (comme précisé par Boubou).
C'est vraiment du FUD gratuit que de prétendre que l'ensemble des API .NET est breveté (c'est pas l'ensemble, et rien n'indique que ca sera effectivement breveté).
[^] # Re: Euh ...
Posté par imalip . Évalué à 5.
Parce qu'il faut avoir inventé quelque chose pour deposer un brevet ?
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Euh ...
Posté par Aiua . Évalué à 10.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 5.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Ils seront surement très sensible à ton argumentation.
Tu trouveras les coordonnées utiles ici.
http://www.inria.fr/inria/organigramme/fiche_dirdri.fr.html
Mais faut pas s'en prendre à nous qui sommes intéressés par ce langage, il ne nous appartient pas et on est pas décideurs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Donc, il cherche un "business model".
Je conçois mal que le compilo ne soit pas libre. Rien que ça serait un gros atout (cf perl, ruby, python,...) sinon il finira comme tous les langages de niche.
Par contre, l'inria peut fournir du portage sur un nouveau cpu, du codage spécialisé, du support, faire des modules pour l'os pour de l'enfouis (vendre des licences proprio de l'OS), etc...
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par Antoine . Évalué à 3.
Je crois de toute façon qu'il finira comme tous les langages de niche. C est trop bien implanté pour qu'un "successeur" incompatible puisse s'imposer.
Les gens qui veulent changer de langage en profitent en général pour changer de paradigme et passer à beaucoup plus haut niveau (Python, etc.).
[^] # Re: Euh ...
Posté par Philip Marlowe . Évalué à 3.
Ça tombe bien, il se trouve que c'est le cas.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Il faut dire que l'INRIA est incapable de mettre en place un CPAN, et c'est pas la première fois que j'en parle ici.
Idem pour Lissac, si vous voulez que ca marche, prévoir de suite deux choses :
- un compilateur LIBRE (pas comme scilab)
- un CPAN dès l'origine avec le même fonctionnement que l'original. Le premier servis s'accapare l'espace de nom (l'espace de nom est global a tous les utilisateurs). Surtout ne pas faire l'erreur de java avec des espaces de nom basé sur les domaines DNS. Le système perl a montré que c'est un système qui fédère les différentes communautés alors que le système java les cloisonne.
Remarque : pour Scilab, l'INRIA fait la même erreur que pour OCaml. C'est à se demander s'ils ont vraiment envie que leurs technologies soient réellement utilisées ?
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Je pense l'écrire bientôt, quand j'aurai trouvé le temps (en php je pense).
Par contre je ne comprend pas de quoi tu parle avec ton histoire d' "espace de nom".
Pourrais-tu être plus explicite ?
Merci !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
http://www.openjsan.org/
Bref, le CPAN étant encore très actif au niveau de son développement, j'irais plutôt regarder du coté du perl que du php. Il doit y avoir plein de bout de code a récupérer.
Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
Reflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
L'expérience du CPAN de perl a montré que le classement fait par les développeurs est généralement très pertinent et a une très bonne durée de vie.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
Boulot énorme !
Falloir que j'étudie Apache, faire un module, gérer les get/post, faire une grosse API pour générer du html (parce que mettre du HTML dans le source signifie modifier le compilateur, donc il faut que ce soit du Lisaac classique qui génère du HTML), faire un binding pour gérer une BDD (pas encore fait).
C'est une bonne idée parce que le serveur surement très bien la charge, mais j'ai peur du boulot que ça implique...
S'il y a des volontaires...
A propos des espaces de nom, c'est l'un des gros defaut d'Eiffel de ne pas les supporter. Il s'agit de tout simplement hierarchiser les classes sous une arborescence ressemblant a un systeme de fichier. Si on est intelligent, on les range après physiquement dans des sous dossiers de même nom ;-)
Cela permet de ne pas avoir toutes les classes aux mêmes niveaux mais de les répartir en domaine. Par exemple, en perl, les modules (classes) sous Net:: concerne le reseau avec Net::Telnet par exemple. Idem, sous CGI:: il y a tous les modules concernant la gestion CGI du web et ainsi de suite.
C'est une idée séduisante, mais j'entend d'ici la réponse de Benoit.
"Oui, mais comme le compilateur va chercher tout seul les objets... Je vois pas l'utilité"
Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl ou en Java.
Tu as un fichier path.li qui se trouve dans le répertoire $LISAAC, et celui-ci contient divers infos comme la liste des répertoire contenant les objets de la lib.
Après le compilateur se débrouille : si tu fait - a : OBJET_TOTO;
il ira chercher objet_toto.li tout seul.
Cela dit, c'est une idée intéressante pour une question de rangement et sur le CLAN, il faudra le ranger comme cela.
Réflexion : je suis sur qu'il y a quelque chose avec faire avec cet espace de nom. Par exemple, les attributs privés seraient accessible dans le même espace de nom... Ou on pourrait avoir des classes privé accessible que depuis le même espace de nom. Ce dernier exemple m'est déjà arrivé. Je voulais avoir une classe accessible depuis plusieurs autres classes de mon projet mais je ne voulais pas rendre son API public. A l'heure actuelle, ce n'est pas possible.
Je suis persuadé qu'il y a une place entre public et private dans les structures des langages, mais pas le protected du C++. Par exemple, le mot 'friend' rendrait les choses accessible à l'espace de nom. L'espace de nom n'ayant rien a voir avec l'arbre des classes. L'espace de nom n'est qu'un rangement que l'homme décide pour son classement.
Il faut savoir (voir manuel utiisateur sur le site) qu'en Lisaac tu as la possibilité d'aller un peu plus loin que le "protected" de c++.
Le protected correspond à toutes les méthodes défini dans la
Section SELF
Evidemment c'est généralisable :
Tu peux si tu le désir définir du code dans une
Section MACHIN, TRUC
qui implique que ton code écrit dans cette section sera accessible uniquement aux prototypes MACHIN, TRUC ainsi qu'à leur descendants.
Evidement avec un espace de nom, on peut imaginer d'aller plus loin, parce qu'espace de nom est différent de l'héritage.
NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il y a des chances, mais il faudrait que ce ne soit pas obligatoire).
On pourrait donc imaginer de jouer avec cette histoire de section pour définir l'accessibilité des méthodes.
Mais ça risque de faire doublon.
Qu'en penses-tu ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je le sais bien d'ou mon smiley ;-) D'un autre coté, c'est sur des trucs énorme que le langage progresse...
D'ailleurs on voit bien l'intérêt de l'espace de nom. Tout ce qui concerne spécifiquement le CLAN serait sous l'espace de nom 'CLAN::'.
Très bien ta réponse sur les sections. Faut vraiment que je regarde plus du coté des langages à prototypes. En fait, j'ai évoquer ce problème d'appel à d'autres classes car je trouve que les langages classiques que je connais n'offrent pas de bonne solution de ce coté là.
> NET.HTTP ne signifie pas que HTTP hérite de NET (dans la pratique, il
> y a des chances, mais il faudrait que ce ne soit pas obligatoire).
La structure de l'espace de nom ne doit surtout pas suivre l'arbre d'héritage ! Cela ne veut pas dire que les sous classes doivent être dans un autre espace de nom, bien évidement. Par contre, il y a dans un espace de nom, un ensemble de 'module' ayant un rapport commun pour faire un certain type de composant/application. Par exemple, il y a sous l'espace de nom 'Apache::' de Perl tous les modules lié au serveur web apache.
Bref, l'espace de nom est une structure 'sociale' décidé par l'homme et non par le langage. Le langage doit laisser l'homme très libre sur celui-ci.
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> ou en Java.
En Perl, il n'y a pas d'import. D'ailleurs, les import sont un truc pourri. Le seul intérêt est d'éviter d'écrire le chemin complet lorsqu'on instancie un objet. Mais le code peux ne plus compilé un jour si on fait un import * come en java ou en python.
En Perl, on fait des use ou des require. Je suis d'accord que c'est parfois un peu chiant et que cela pourrait être évité.
Cependant, le use charge le code dans la phrase de pré-compilation alors que le require ne charge le code qu'au moment de l'éxecution. La librairie n'est alors pas chargé au démarrage. Dans le cadre de gros programme ayant plein de fonctionalité, le fait de charger les modules qu'en fonction des besoins et au dernier moment est très intéressant.
De toute manière, si Lisaac veut concurrencer le C, il faudra bien qu'il supporte la compilation modulaire (des librairies et pas que des executables) et qu'il puisse charger du code dynamiquement. Imagine un peu si le code d'Apache n'était pas modulaire...
[^] # Re: Euh ...
Posté par jcs (site web personnel) . Évalué à 2.
Ensuite, ce que tu proposes pour l'accessibilité des variables et méthodes d'une classe existe en Java. Pour rappel, il existe 4 niveaux de protection en Java :
- private : accessible uniquement depuis les instances de la même classe
- package : accessible uniquement depuis les instances des classes du même package
- protected : comme package mais accessible aussi depuis les instances des classes filles
- public : accessible par tous
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> conseil de Sun de nommer ses packages en utilisant un nom de
> domaine qu'on possède afin de limiter au maximum les collisions
C'est ca que je reproche. Lorsque j'ai vu ca la première fois il y a ... au début de java, je me suis dis, les autres sont des idiots, cette idée est géniale.
Et bien non. Cela cloisonne les projets. En pratique, les personnes mettent effectivement le domaine dns à l'envers. On a un espace de nom qui ne veut rien dire avec des org.machin.toto...
Si tu regardes un peu du coté du CPAN, on ne perds pas son temps dans des org.machin.toto, on va directement au but et toutes les personnes du monde se partagent le MEME espace de nom. Et ca marche FORMIDABLEMENT bien. Il n'y a AUNCUNE collision !
Pourquoi, parce qu'il y a un CPAN ou tout le code de tous les modules écrit et voulant être mutualisé se trouve.
Bref, le systeme d'un seul espace de nom pousse a la mutualisation du code. Celui qui ne veut pas mutualisé peut avoir un jour un risque de collusion, tant pis pour lui (en java, c'est la meme chose pour ce point la).
Comme le code n'est pas centralisé en java, si tu veux prendre des packages d'un autre esapce de nom org.truc.titi par exemple, qu'est ce qui t'assures que ce bout de code sera encore valable dans six mois ? Bilan, tu recopies voire tu remet tout dans ton espace de nom.
Dernier point, comme chacun travaille dans son espace, si tu travaille sur un module qui fait du ping et un autre qui fait du telnet, tu peux avoir un
import org.machine.net.ping
import org.truc.net.telnet
Comme machin et truc son dans deux esapce de nom différent, il est certain qu'il n'y a pas d'homogénéité dans la philosophie des modules ping et telnet. Au niveau du code, c'est aussi pas super explicites. On ferait un
import net.ping
import net.telnet
Ce serait quand meme bien mieux.
Ensuite, se tapper les org.machin... a chaque fois est pénible, du coup on voit souvent dans les sources des
import org.machine.*
Et ca, ca devrait être interdit par le langage. Surtout que si il y a plusieurs import de ce type et que les API sont étendues, le code peux ne plus compiler !
Un des problèmes des langages objets et que cela devient lourd parfois de faire des choses très simple. Par exemple écrire sur la sortie standard. Sans ce * dans les import en java, c'est très lourd. C'est là ou Sather a une solution GENIALE. Il y a deux classes à la racine : IN et OUT, et il y a un raccourci pour faire appel a la méthode create (ou new du C++), il suffit de mettre un # devant la classe. Donc
#OUT == OUT.create
Avec ca, écrire sur la sortie standard en pur objet tout en restant humain se fait par la seule ligne
#OUT + "hello world !\n"
On instancie la classe OUT, on appelle la méthode + sur cet objet et c'est tout !
> package : accessible uniquement depuis les instances des
> classes du même package
Désolé de mon ignorance sur ce point là. Un package est'il extensible ? Est'il lié à la notion d'espace de nom.
Mon idée est la suivante. Je veux une classe interne a mon espace de nom. En effet, elle n'a aucun intérêt a être public et je veux pouvoir modifier son API.
Mais si une autre personne étend mon espace de nom en rajoutant des classes, il a bien sur le droit d'y avoir accès puisqu'il travaille sur le même thème. Cependant, dans le contrat social implicite, il sais qu'il doit suivre la philosophie de l'espace de nom et s'adapter au changement des API interne à l'espace.
En fait, le choix de l'espace de nom, de faire un CPAN... ont plus un impact sociologoique que technique. En inscrivant dès le départ ce choix dans le langage, on inscrit le projet dans un mouvement communautaire et plutôt lié au libre. Après, la sauce marche ou ne marche pas. Dans un cadre de type INRIA, c'est intéressant de mettre ce type de base car cela évite que des pontes au dessus ai des vues plus monétaires des choses. Une fois la dynamique lancée, ils sont coincés (c'est comme ca qu'un copain a pu sauver son projet libre qui marche relativement bien et que l'université voulait récupérer a son profit).
> il y a correspondance entre chemin et nom de package. Par
> exemple la Classe org.linuxfr.Main sera dans le fichier
> org/linuxfr/Main.java
Heureusement, il faudrait être fou pour proposer un autre système... bien qu'en ada avec gnat, on a le choix de pouvoir mettre des tirets à la place des slash et donc de tout avoir à plat dans le même dossier.
[^] # Re: Euh ...
Posté par Antoine . Évalué à -2.
Ils seront surement très sensible à ton argumentation.
Depuis que son directeur est mort, il est très mal vu de critiquer l'INRIA. Si si.
[^] # Re: Euh ...
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
À "Solutions Linux", j'ai eu l'occasion de discuter avec Patrice Prez, de la Direction du Développement et des relations Industrielles de l'INRIA (il a tenu à me laisser sa carte de visite).
Il espère vendre Lisaac aux Chinois ! Je pense surtout qu'il s'accroche à des modèles économiques éculés qu'on lui a appris à l'école et qu'il n'a ni sa liberté de penser, ni une bonne connaissance des modèles économiques issus des logiciels libres.
Lisaac ne peut avoir un avenir que si il dispose d'un très large base d'utilisateurs. Cela ne peut se faire de nos jours qu'avec une licence libre.
On peut aussi imaginer une licence double comme MySQL et dans ce cas, on peut espérer vendre le logiciel à ceux qui veulent faire du propriétaire sur un logiciel à grande diffusion.
Il y a 15 ou 20 ans, j'aurais voulu utiliser ADA au lieu de Pascal. La politique de prix m'en a dissuadé. C'est vraiment dommage, mais c'est comme ça que des commerciaux incompétents ont tué l'un des meilleurs langages informatiques. Monsieur Prez, ne les imitez pas, s'il vous plait !
[^] # Re: Euh ...
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
http://www.inria.fr/inria/organigramme/fiche_dirdri.fr.html
Merci, j'ai écrit au premier nom de la liste ;-)
[^] # Re: Euh ...
Posté par Arnaud . Évalué à 4.
- faire normaliser Lissac par un comité ISO (probabilité presque nulle)
- faire découvrir aux gens que "Lissac, c'est mieux".. bon courage
- faire changer d'habitude les programmeurs
- faire enseigner Lissac dans toutes les universités du monde
Beaucoup ont essayé de remplacer le C, personne n'a réussi. le C est indéboulonnable : trop connu, base installée trop grande, trop de systèmes critiques reposent dessus. Pour la place du language "mieux, plus productif", la place est déjà prise : Ada et/ou Java.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ada est de plus en plus remplacé par le C car personne ne connait Ada.
Bon, ok, c'est pire avec Lisaac.
Lisaac est encore plus haut niveau que Java ou Ada, et il est réellement possible de faire plus d'optimisation qu'un C. Notamment en maitrisant le layout mémoire. Il peut (potentiellement) détecter beaucoup plus d'erreur que Java ou Ada à la compilation.
De plus, l'absence d'outils complètement libre et les JVM sont un frein à l'adoption de Java. Ada est en déclin car les compilos Ada coutaient extrément chère. Gnat arrive un peu tard.
Bref, le C existe encore malgré tout ses défaults.
Mais je suis d'accord que c'est pas gagné.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par Troy McClure (site web personnel) . Évalué à 10.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Mais en fait, c'est que les mots clef sont trés peu nombreux. Les "if" "while" sont des fonctions de la library (des methodes).
Cela déroute un peu mais si tu regarde mieux, tu verra que la structure est simplissime.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par Gael Tessier . Évalué à 2.
C'est comme ça qu'il se place en deuxième position dans le classement des langages qui ont le moins de mots clés mais c'est un peu triché à mon goût ;-) Je ne dis pas que l'idée est mauvaise mais que leur classement est biaisé. J'ai été très surpris en ne voyant que quatre mots clés !
Un bon point concernant la syntaxe, c'est l'adoption comme en Pascal par exemple, du ":=" pour l'affectation et non plus le "=" du C qui a forcément joué des tours à beaucoup d'entre nous.
[^] # Re: Euh ...
Posté par reno . Évalué à -1.
Forcément? Tu prends ton cas pour une généralité!
Utiliser la syntaxe Pascal/Ada pour l'affectation plutot que celle du C me paraît assez absurde, le nombre de programmeurs Pascal/Ada se comptant sur les doigts d'une main..
Dans certains, la syntaxe du C a de clair inconvénient: la lecture des déclaration de variable en C est bien plus complexe que celle de Pascal, mais l'affectation ne fait pas partie de ces cas la..
[^] # Re: Euh ...
Posté par gaaaaaAab . Évalué à 3.
[^] # Re: Euh ...
Posté par reno . Évalué à 4.
Si, mais comme j'utilise gcc en -Wall, j'ai corrigé le probleme rapidement.
De plus c'est un probleme qui vient surtout des types en C: si les int et les bools étaient des types disjoints, dans la majorité des cas le compilateur se plaindrait si on faisait une affectation à la place d'un test. Il est vrai que cela pourrait toujours se produire c'est en faisant un test sur une variable booleenne..
[^] # Re: Euh ...
Posté par gaaaaaAab . Évalué à 3.
mine de rien, là, tu confirmes qu'il y a un problème sur la syntaxe de l'affectation en C, même si tu le contournes avec le compilo ;-)
[^] # Re: Euh ...
Posté par Julien . Évalué à 1.
if (b=true) /* ... */;
Le problème est que c'est une construction valide et parfois utile. Il est donc difficile de faire des tests automatisés pour vérifier qu'il n'y a pas confusion ...
[^] # Re: Euh ...
Posté par Nicolas Schoonbroodt . Évalué à 3.
if (true=b) /* ... */;
Faire ceci par défaut, et dans le cas où cette construction sert à quelque chose, inverser l'ordre, comme cela, c'est explicite.
[^] # Re: Euh ...
Posté par Antoine . Évalué à 4.
>>> x=0
>>> if (x=1): print "hop"
File "", line 1
if (x=1): print "hop"
^
SyntaxError: invalid syntax
>>> x
0
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . Évalué à 5.
Si la syntaxe provoque les erreurs, ce qui parait absurde c'est de ne pas la changer.
Et en l'occurence, c'est pas ça qui va t'amener les neurones dans la zone rouge lors de l'apprentissage d'un nouveau langage.
[^] # Re: Euh ...
Posté par Mildred (site web personnel) . Évalué à 4.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
Je voudrais bien comprendre, une bonne fois pour toute, ce que tout le monde trouve de si affreux dans cette syntaxe ?
Franchement je préfère
à
C'est beaucoup plus clair, à mon humble avis.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Jb Evain (site web personnel) . Évalué à 10.
[^] # Re: Euh ...
Posté par Troy McClure (site web personnel) . Évalué à 7.
[^] # Re: Euh ...
Posté par Arthur Accroc . Évalué à 1.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Euh ...
Posté par reno . Évalué à 3.
Je suis d'accord que c'est plus lisible mais je n'aime pas non plus le reste de la syntaxe de Lisaac.
[^] # Re: Euh ...
Posté par Arthur Accroc . Évalué à 1.
En Perl aussi, c'est possible : les paramètres se récupérant dans un tableau, il suffit de l'affecter à un tableau associatif plutôt qu'à une liste de variables.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Euh ...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Euh ...
Posté par golum . Évalué à 4.
Quand les developpeurs veulent bien se donner la peine d'expliciter les paramètres.
[^] # Re: Euh ...
Posté par Arthur Accroc . Évalué à 2.
Signe d'un manque total de sens de l'humour.
Par exemple, si tu écris une fonction qui consiste à faire quelques pré et post-traitements spécifiques à ton programme autour de l'appel d'une fonction existante, il y a de bonnes chances qu'elle prenne comme paramètres pratiquement les mêmes que la fonction existante, et tu peux donc te débrouiller pour ne jamais expliciter ceux-ci...
Comme ça, tu es sûr de ne pas faire d'erreur dessus, et puis d'un autre côté, le mec qui te relis, il rame.
Que du bonheur !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Euh ...
Posté par snt . Évalué à 4.
C'est quand meme moins vrai sur les dernieres versions de java ( alors qu'effectivement c'est insupportable sur les premiers jdk ). Avec le JIT on a meme des resultats surprenants : imaginons un cas qui n'est pas si rare : tu as un binaire livré avec ta distro compatible i386 et un processeur recent. Avec la compilation JIT, ton bytecode va etre compilé pour ton proc alors que le binaire n'est pas optimisé lui.
M'enfin c'est vrai que pour la vitesse, rien ne vaut le C. Enfin l'assembleur..
De plus, l'absence d'outils complètement libre et les JVM sont un frein à l'adoption de Java.
Il y'a des outils libres ( voir la fondation apache ou les serveurs d'appli libres). Les IDE java libres sont légion et ils sont en plus de tres bonne qualité ( eclipse, net beans tout ça ). Il y'a des JVM libres ( kaffe, gcj, jamvm) Et il y'a des implementations libres des classes de base ( enfin y'a classpath .. ). Et meme dans le pas libre, la norme n'est pas si "fermée" puisque je connais au moins 3 "vendeurs" de jvm différents ( sun,ibm et bea. et je suis pas un pro de java ).
Enfin pour ce qui est de l'adoption de java, j'ai bien l'impression que ça marche plutot pas mal quand je zone sur les sites d'offres d'emploi.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je pensais que tu parlais de Java pour l'embarqué utilisé dans certaines applications (javacard...).
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par drmad . Évalué à 1.
Essaie FreePascal et tu verras...
Non seulement c'est Objet, ça compile plus vite que son ombre et la vitesse de l'executable est impressionnante, surtout lorsque tu traites des chaines de caractères, là, la vitesse est de loin supérieure au C.
[^] # Re: Euh ...
Posté par pasBill pasGates . Évalué à 5.
Parce que j'ai du mal a voir ce qui peut lui permettre d'etre plus rapide qu'une fonction identique ecrite en C.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 3.
strlen doit donc parcourir celle-ci.
Une gestion (plus lourde d'une chaine) utilisant un entier décrivant la taille, permet d'éviter ce genre de choses.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 6.
[^] # Re: Euh ...
Posté par Antoine . Évalué à 2.
Ne pas intégrer un type chaîne de caractères (fondamental dans 99% des applications), c'est une grave lacune.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 4.
Enfin sinon il est clair qu'un type string natif est vital. Quand je code en C++ ca me lourde franchement d'avoir à gérer les char * les CString, les std::string sans parler des classes dérivées de std::string, véritables "mod" dont les développeurs sont fiers.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
En lisaac précisément, tu as un type STRING défini dans la librairie (comme les nombres, booléen, etc...) mais pas dans la grammaire et ceux-ci sont très simple à utiliser.
Mais effectivement, un langage sans string c'est galère.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
En LISAAC d'après ce que tu dis c'est pas en standard dans le langage , mais dans la bibliothèque "standard" qui l'accompagne, ce qui revient à peu prêt au même. C'est déjà très bien à partir du moment où ce "type" n'est pas modifiable et/ou extensible.
Pour les autres constructions (conditionnel, boucle) je trouve cela beaucoup moins "intéressant" : il y a fort à parier que cette possibilité soit utilisée pour construire de nouvelles instructions voir étendre ces instructions avec un comportement loin d'être "universel" : le risque, c'est de se retrouver avec un code "customisé" pour le développeur, qui flattera certe son ego, mais qui sera probablement imbittable par les autres développeurs. Bref pour la maintenant ca sera bonbon.
J'imagine même pas si C++ avait pas mis les if else for, c'est vrai on aurait pu tout faire avec les templates et les macros, mais mon dieu dans quel cauchemard serions-nous :)
[^] # Re: Euh ...
Posté par agmk . Évalué à 5.
et
>pas en standard dans le langage , mais dans la bibliothèque "standard" qui l'accompagne, ce qui revient à peu prêt au même.
Excuse moi, mais je ne vois pas en quoi "std::string" n'est pas un type standard du C++, dans la mesure où il appartient à la STL (ce qui revient au même, tu le reconnais)...
Il me semble que la STL (ou plutôt une implémentation de celle-ci) est fournie avec chaque compilateur C++ digne de ce nom (et peu importe si chaque lib propose sa version, de CString des MFC qui puxent à QString de Qt).
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 4.
- Parcque dans le langage C++ tel qu'il a été défini, std::string n'existait pas
- std::string est fourni dans une lib de templates recompilé systématiquement dans chaque programme qui les utilise, et donc parfois incompatible d'une bibliothèque à une autre suivant le compilateur/optimisation : bref pas forcement compatible binairement, et peut être trop facilement étendu/modifié par les programmeurs.
- parcque dans la pratique, le type CString (oui gnagnagna c'est pas bien je suis bien d'accord) est tout aussi "standard" (de fait).
Bref pour toutes ces raisons et par le simple constat que la std::string est loin d'être utilisé partout, c'est pas le standard.
Pour LISAAC, ca a l'avantage d'être présent dès le départ, dans la lib de base. Mais j'ai bien précisé qu'à mon sens il faut empêcher d'éventuelles modification, ou tout du moins ne pas faciliter cela, au risque de se retrouver avec la même situation complètement absurde du C++. (Désolé mais là j'ai dû jongler pendant un moment sur un projet où chaque développeur utilisait les string qu'il préférait, des CString au char * en passant par les w_char, les std::string, les MString, une perte de temps effroyable et des conversions incéssantes contre-performantes)
Bref, rien ne vaut le type string en natif dans le langage, comme mot clé, avec un API et une représentation binaire normalisée et standardisée.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
Concernant la librairie, elle est très proche de Eiffel (elle en est tirée).
Je suis pour le moment un peu inquiet là dessus : quel mécanisme juridique peu permettre de garantir un standard ?
Quel mécanisme pour intégrer les bonnes idées et rejeter les autres. Je pense que ce sera son concepteur qui jouera ici le rôle de Linus.
Cela dit la lib n'est que du texte, ce ne sont pas des binaires, donc enlever, rajouter, interchanger n'est pas trop problématique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Euh ...
Posté par Dring . Évalué à 3.
En plus, du coup*, le premier caractère d'une chaîne est bien "machaine[1]", et non pas "machaine[0]".
En terme de syntaxe, j'ai toujours considéré le Pascal comme beaucoup moins casse gueule que le C. Le ":=" pour l'affectation, les "begin/end" pour les blocs, la gestion des dépassements de tableau, etc...
*enfin bon, de toute façon, en pascal, on peut choisir les bornes d'indexation d'un tableau, genre :
type montab = array[-5..5] of double;
(Attention, j'ai pas fait de pascal depuis plusieurs années ; je ne fais plus que du C ou du Java)
[^] # Re: Euh ...
Posté par Charles-Victor DUCOLLET . Évalué à -1.
par contre pour l'instant, pas de problèmes avec le python !
[^] # Re: Euh ...
Posté par jmny . Évalué à 5.
[^] # Re: Euh ...
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Euh ...
Posté par shalalala . Évalué à -1.
[^] # Re: Euh ...
Posté par ouah (site web personnel) . Évalué à 1.
> un accès bas niveau au hardware et de bonne performance. Il se veut clairement un concurrent du C.
Le C étant une sorte d'assembleur "portable", si Lisaac est un langage de "très haut niveau comme Smart Eiffel et Self", la concurrence est déjà exclue dès le départ.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 1.
1/Le compilateur Lisaac effectue une analyse de flot de ton code, c'est à dire qu'il l'analyse afin de
- recenser le code vivant
- supprimer toutes les instructions inutiles
- résoudre la liaison dynamique -> plus de VFT
L'intérêt du compilateur tient en son minimalisme : la conditionnelle étant défini dans la lib, elle se trouve n'estre qu'une simple résolution de lien dynamique objet.
En effet, le message if est défini comme suit :
dans Boolean.li
- if true_block then false_block <- defered
defered est l'équiv de virtual en Java
Dans true.li
- if true_block then false_block <- (
true_block.value;
);
dans false.li
- if true_block then false_block <- (
false_block.value;
);
Evaluer une condition fausse ou vrai pour le if revient à résoudre un message.
Cela implique que le compilateur ne sait pas faire la différence entre un if, et un héritage dynamique par exemple, il ne connait que la résolution dynamique.
Cela permet d'avoir un langage extrêmement minimaliste en interne et d'optimiser à mort.
2/ Le compilateur peut mettre en place des optimisations qui rendent le code trop vite illisible pour un être humain.
Citons par exemple la gestion de la mémoire qui peut être géré à la main : tu fait un malloc de départ et tu gère l'emplacement de tes données à la main pour en optimiser l'emplacement, pour le cache par exemple.
Tu peux aussi supprimer l'ensemble des appels inutile, c'est à dire inliner ton code, ce qui le rend illisible pour un être humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Antoine . Évalué à 1.
L'intérêt du compilateur tient en son minimalisme : la conditionnelle étant défini dans la lib, elle se trouve n'estre qu'une simple résolution de lien dynamique objet.
Génial. Mais à part la beauté théorique et la joie de l'auteur de compilateurs, je ne vois pas ce que ça apporte en pratique. Que "if" soit un mot-clé ou une fonction standard, pour le programmeur final ça ne change strictement rien.
(ah, si, on peut redéfinir "if" : la belle affaire)
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
Différents tests :
+ monboolean, monautrebooleen : BOOLEAN;
monboolean.if_true { cond_vrai;};
monboolean.if_false {cond_fausse;};
monboolean.if { cond_vrai;} else {cond_fausse;};
monboolean.if {
/**/
}.elseif monautrebooleen then {
/**/
} else { /**/ }
etc...
Tu peux en créer autant que tu veux de ce style.
De même, avec les blocks (je te les mets entière) :
- while_do body:BLOCK <-
( //? {body!=NULL};
value.if {
body.value;
while_do body;
};
);
- do_while test:BLOCK <-
( //? {test!=NULL};
value;
test.value.if {
do_while test;
};
);
- until_do body:BLOCK <-
( // ? {body!=NULL};
(! value).if {
body.value;
until_do body;
};
);
- do_until test:BLOCK <-
( //? {test!=NULL};
value;
(! test.value).if {
do_until test;
};
);
Et si tu veux en inventer d'autres, tu peux. Tu n'est pas obligé de les implémenter dans la grammaire du langage.
Et cela en gardant les performances du C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Antoine . Évalué à 5.
Tu ne réponds pas à la question.
Tu aurais tout aussi bien pu avoir le "if" dans la grammaire, et ajouter d'autres conditionnelles dans la bib standard (sans compter la stupidité profonde des exemples que tu donnes).
Bref, le soi-disant avantage de n'avoir que 4 mots-clés n'en est pas un, c'est de la branlette intellectuelle.
[^] # Re: Euh ...
Posté par Thomas Douillard . Évalué à 4.
Donc, il y a un avantage. CQFD.
La simplicité du compilo, ça apporte quoi ? moins de bug potentiel, code plus concis, sans doute plus facile de faire des compilos prouvés (avantage pour l'embarqué, par ex) ... Quoi que c'est à vérifier, pour le dernier point, la résolution dynamique de méthode virtuelle c'est quand même plus compliqué théoriquement qu'une conditionelle.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 4.
Maintenant les inconvénients :
- moins de constructions dans le langage ==> moins de contraintes sémantiques ==> moins d'optimisations possibles.
- moins de constructions dans le langage ==> moins de contraintes de programmation ==> trop de liberté ==> trop de manière d'écrire le même code, difficulté de relecture par un autre programmeur, difficulés de maintenance, bugs potentiels.
[^] # Re: Euh ...
Posté par Julien . Évalué à 5.
Je ne suis moi même pas convaincu qu'on ait là le langage qui remplacera le C.
Je dois avouer que j'aime quand même bien l'idée d'un langage minimaliste où tout est extensible.
Ton argument selon lequel, je cite
me semble être lié à un raisonnement un peu rapide.
Ce n'est pas parce qu'une fonctionalité n'est pas inscrite dans la grammaire du langage qu'elle n'est pas standard. Il existe aussi la notion de bibliothèque standard.
Je ne suis pas suffisamment connaisseur du fonctionnement des compilateurs pour argumenter sur l'autre argument.
Par contre, si je comprend bien, ce compilateur analyse le code en entier avant de le compiler. J'imagine donc que le temps de compilation doit être relativement élevé. Surtout qu'il faut ensuite compiler le C généré ... Sur un gros projet, ça peut être très handicapant.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben l'à priori avec lequel je suis parti c'est : "tiens, un nouveau langage bien prétentieux". Ben oui il va "sans doute" remplacer le C c'est marqué. Donc je me dis qu'il doit être sacrément bien foutu et doit constitué un espèce de "state of art" de ce qui se fait en matière de langage, parcque pour déboulonner le C quand même...
Au début je me suis contenter de poser quelques questions sur le pourquoi le langage est génial. Ontologia a répondu à plusieurs reprises et si j'interprête correctement ses propos les points forts du langage sont :
- une grammaire simplissime, c'est paraît-il mieux pour les optimisations globales. Oui mais : au final c'est pas plus rapide que le C, donc première déception. Donc l'intérêt est pour moi limité.
- la possibilité de faire ses propres instructions d'itération & co : comme l'a dit quelqu'un ca ressemble beaucoup à de la masturbation intellectuelle qu'à autre chose. De ma petite expérience de programmation, c'est déjà assez affreux d'avoir à relire les macros C++ d'un collègue, alors si en plus je lui laisse la possibilité de fabriquer sa propre boucle for... Bref, pour moi ca n'a strictement aucun intérêt, c'est comme si le langage français avait 10 mot dans sa grammaire et qu'on avait tous nos dialectes bien à nous pour parler. Personne se comprend.
- la programmation à base de prototypes plutôt que de classes. Là je sais pas trop quoi penser, faut que j'essai. Mais si c'est du même topo que le reste, voilà quoi.
- un langage qui veut remplacer le C et les langages de haut niveau (c'est pas moi qui le dit). Ben y'a pour moi de nombreuses langages aux plateformes beaucoup plus "sexy" avec d'impressionnantes bibliothèques. Je vois mal Lisaac s'imposer face aux Java/.NET/Python/Ruby/Perl&Co.
- un truc magique et révolutionnaire breveté dans le compilateur. C'est gentil mais bon en attendant on est face à un compilateur qui demande des ressources de compilation exponentielles qui doive le rendre inutilisable dans le monde industriel, et qui pond du code pas plus rapide que du C.
Moi ce que je constate, c'est que ce langage semble être un joli produit de la recherche mais qui semble ignorer totalement toutes les contraintes industrielles, c'est pourquoi j'ai un peu peur qu'il "pète un peu trop haut". Visiblement y'a des énormes points noir qui me semble pourtant tellement évident :
- pour un langage qui veut remplacer le C, il est pas capable de présenter des APIs "àla C" réutilisables dans d'autres langages. En gros j'ai bien l'impression que si l'OS est en Lisaac, tout le reste doit l'être aussi. Bref aucune réflexion sur la transition et l'intégration avec l'existant.
- un algorithme de compilation qui n'apporte rien en terme de performance par rapport au C, avec en bonus un algorithme exponentiel.
- pas de réflexion sur le versionning, la documentation du code ou encore la documentation sous forme de schéma : comment représente-on une modélisation visant ce langage ? UML est-il adapté ? Sinon y'a-t-il des outils ?
Alors moi ma question est :
- Pourquoi utiliser ce langage plutôt que le C ? Visiblement c'est pas une question de perf, c'est pas une question de productivité puisque l'interfacage avec le monde existant semble absent, la grammaire est pas spécialement élégante à lire, en tout cas pas plus qu'un autre langage...
Désolé mais 'étais "dubitatif" au départ, mais après ces quelques échanges je suis loin d'être convaincu de l'intérêt du langage.
Enfin j'attend de voir le côté révolutionnaire du compilateur, ce qui sera breveté.
[^] # Re: Euh ...
Posté par Julien . Évalué à 5.
Est-ce que ce n'est pas ce qu'annoncent tous les langages ? Le nouveau langage qui révolutionne tout et remplacera tout ce qui existe jusqu'à maintenant. Je ne pense pas que grand monde ici y croie vraiment, mais de là à descendre Lisaac comme tu le fais ...
Ce qu'il dit, c'est que du code Lissac écrit dans une optique de bonne architecture et donc assez facile à comprendre générera du code C optimisé mais imbitable. Je veux bien le croire. Si Lissac permet d'obtenir les mêmes performances que du C écrit dans une optique d'optimisation agressive mais en restant maintenable, ça n'est peut être pas une révolution, mais c'est déjà une bonne évolution non ?
Et pourtant ... la bibliothèque standard C++ fournit différent mécanismes pour simplifier l'écriture de boucle dans l'en-tête <algorithms> (for_each & co). Encore une fois, ce n'est pas parce qu'une fonctionalité n'est pas dans le langage qu'elle n'est pas standard.
Je n'aime pas non plus cette philosophie (qu'on retrouve par exemple dans java) selon laquelle il faudrait prendre le développeur pour un dangereux terroriste et ne lui fournir la possibilité de ne faire que des choses sans danger. Parfois il est utile de faire ce qui ailleurs est une erreur de conception. Laissons la liberté au programmeur en précisant quand même les dangers de chaque construction.
Sur ce point là, je te rejoins complètement. Ca n'enlève pas les qualités intrinsèques du langage qui reste utile comme proof of concept et qui fournira peut être des outils utiles à d'autres langages plus pragmatiques. C'est un peu comme ça que fonctionne la recherche, ça ne me choque donc pas de la part d'un langage développé à l'INRIA.
Si le compilateur génère du C, je pense qu'il n'est certainement pas très compliqué d'ajouter la possibilité d'insérer des appels de fonction C qui ne doivent pas être traduits. On sort cependant là du cadre de la recherche et je pense que c'est en mûrissant que le langage sera agrémenté de ce genre de possibilités.
Tu cherches vraiment la petite bête. On te dis "un nouveau langage est créé avec une nouvelle manière de penser" tu réponds "est-ce qu'il est prêt pour la production ? est-ce que tous les outils qui vont autour sont disponibles ?"
Ce n'est pas Sun ou Microsoft qui proposent leur langage pas super innovant mais vachement bien supporté, c'est une équipe de recherche qui présente le résultat de ses travaux. Je pense que la plupart de tes problèmes avec le langage viennent de ce que tu attends autre chose que ce que fournit le langage.
Je vais essayer de ne pas tomber dans le troll, mais je crois que pour résumer ma pensée, je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Et pourtant ... la bibliothèque standard C++ fournit différent mécanismes pour simplifier l'écriture de boucle dans l'en-tête (for_each & co).
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
Je n'aime pas non plus cette philosophie (qu'on retrouve par exemple dans java)
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
e lui fournir la possibilité de ne faire que des choses sans danger.
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Si le compilateur génère du C, je pense qu'il n'est certainement pas très compliqué d'ajouter la possibilité d'insérer des appels de fonction C qui ne doivent pas être traduits.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Tu cherches vraiment la petite bête. On te dis "un nouveau langage est créé avec une nouvelle manière de penser" tu réponds "
Ah non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
Je pense que la plupart de tes problèmes avec le langage viennent de ce que tu attends autre chose que ce que fournit le langage.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
Qu'en sais-tu ? Pour le moment, le compilateur crache du code légèrement mois rapide que du C, mais peut être que celui-ci sera plus rapide bientôt ?
Je crois beaucoup aux optimisations de gestion de la mémoire, à la réécriture de boucle, etc...
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Ce langage date de deux ans, et depuis deux ans son auteur a pas eu le temps de faire grand chose (post-doc, cours à la fac, etc...).
On débute ! On est pas SUN ni Microsoft ! Laisse nous le temps de lister, réfléchir à tout le travail qui doit être effectué à ce propos et de l'implémenter !
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
foreach est dans la lib à ma demande, de toutes façon, c'est une fonction qui prend 15 secondes à s'écrire. dans collection.
- foreach_do blk : BLOCK <-
(
1.to self.count do blc.value self;
);
Terminé.
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Je suis totalement d'accord avec toi, mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Je te signale que tu as un exemple de code plus haut bourré d'Inline en C...
Tu inline ton C dans le code tout simplement, et le compilateur le pose dans le fichier généré.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
C'est un de ses intérêts, mais pas le seul.
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
Chaque chose en son temps.
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
C'est vrai que les centres d'intérêts prioritaire de nicO transparaissent dans cette news.
Pour le reste on t'a expliqué ce que ça apporte (voire mon dernier post de tout à l'heure, tout en bas).
Pour l'objet à prototypes, je te renvoi en aux transparents sur le site, ainsi qu'au manuel d'utilisateur.
La différence entre le proto et la classe,c'est que le prototype est vivant à l'exécution et se clone, tandis que la classe s'instancie.
Cela signifie que lorsque tu dit B hérite de A. L'instance de B est objet unique, un mix de A et B. Tandis qu'en prototypes A et B restent deux objets indépendants, ils peuvent avoir une existance physique séparée en mémoire (Pagination, voir segmentation par objet avec pour chacun leur zones de code, de donnée et leur pile à eux).
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
De plus Lisaac permet de jouer avec les opérateurs '-','+','*' que tu met avant chaque slot, cela permet des subtilités très poussées dans le partage des variables entre enfants d'un parent, la possibilité d'embarquer des méthodes, comme en Java/C++/etc.. et plein de choses qui sont expliquées pas très clairement dans le manuel.
Un des gros challenge futur, c'est de faire ue doc pour expliquer tout ça, parce que c'est très puissant.
Encore une fois, je te renvoi au manuel http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Tu auras quelques explications ici http://isaacos.loria.fr/download/lisaac_overview.zip
Et la grammaire est là : http://isaacos.loria.fr/li_docs.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
Ben j'en sais les benchs que vous donnez...
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
L'un empêche pas l'autre. Tout est bon pour contribuer à la qualité.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" :
http://www.artima.com/intv/nonvirtual.html
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Ben moi je penses pas que c'est indépendant. C'était indépendant y'a 20 ans, mais à sens aujourd'hui le langage est intrinséquement lié à la plateforme d'exécution et inversement.
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 4.
Ce n'est pas parce que l'implémentation d'un concept à un instant T est moins performante, que ce concept est invalide. Ce n'est pas une condition nécessaire, tu n'as rien prouvé là.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
La librairie est en libre (Cecill), si quelqu'un a une primitive intéressante, on l'intègre.
Pour le reste, s'il y a au moins 1% de codeur qui toucheront à Boolean.li, je serai très étonné.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
C'est hors de question. Le compilateur restera hyper minimaliste, comme je l'ai expliqué en bas, ça permet de se concentrer sur la sémantique du code. de plus, comme on te l'a expliqué ailleurs, cela permet de faire un compilo plus propre, donc moins de bug, etc...
Seront rajoutées des primitives lorsqu'on tombera sur du très haut niveau, genre le SQL intégré ou des primitives très haut niveau comme "qqsoit x de l'ensemble".
>Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il >manque quelque confort pour la chose c'est un détail qui se règle en quelques heures >au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
Il y a une ML pour le projet, tu as le droit de contribuer.
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" :
http://www.artima.com/intv/nonvirtual.html
Envoi un mail à Benoit, je ne me sens pas assez qualifié pour répondre à ça.
[héritage dynamique, prototype]Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
C'est à toi de répodnre à cette question lorsque tu designe une application.
Premièrement, cela apporte que la structure objet que tu codes, restera la même à l'exécution, ce qui n'est pas le cas avec l'objet à classe. Une classe n'est qu'un moule, il faut l'instancier pour qu'elle devienne vivante, tandis qu'un prototype est vivant dès le début.
Deuxièmement, l'héritage dynamique te permet de simplifier considérablement l'arbre d'héritage.
On met beaucoup de temps à comprendre l'intérêt de ces possibilités. Même son auteur a mis beaucoup de temps à utiliser l'héritage dynamique dans son langage. Le compilo actuel n'en n'utilise pas, le futur qui sortira bientôt, l'utilise massivement.
C'est en designant ton appli que tu en vois l'intérêt.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
Pour résoudre les bugs, ya pas de debugger mais ça viendra.
intégrer le code à l'existant, c'est dors et déjà possible, on va travailler à améliorer la cosmétique.
Pour la doc, un générateur de Doc, un peu dans le style de Javadoc sera intégré dans la prochaine version du compilateur.
Pour concevoir des API friendly, le haut niveau du langage et son expressivité sont là pour ça. Observe la lib de la GUI par exemple, elle est à mon sens beaucoup mieux pensée que ce qu'on peut trouver ailleurs.
Pour les tests, tu as les contrats.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par thecat . Évalué à 5.
- moins performant que du C (ils l'ont montré)
Nous avons l'implémentation d'un langage de haut niveau, complétement objet, avec ramasse miette, trés indépendant de la plateforme d'éxécution. Un bench sur une application reele (pas une factorielle ou un helloworld) qui montre que l'on a moins de 2% de temps d'éxécution en plus sur une application aussi "critique" qu'un décodeur mpg2 comparé a son implémentation C.
Et toi tu nous sort que c'est une preuve que c'est mon performant et que le becnh est en faveur du C ?
Désolé, je sui pas d'accord.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard".
C'est un point de vue que tout le monde ne partage pas.
Dans Lisaac (comme d'autres langages comme Lisp ou SmallTalk), ce n'est pas sale de faire des macros comme en C++ car elle sont bcp plus puissante (c'est pas un simple prépoc. syntaxique).
les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Je prend ton similey pour de l'humour car si tu croit vraiment ce que tu écrit, nous avons une conception complètement différente d'un "bon" langage objet .... mais quand j'ai lu ce que tu répondait ... :
dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final".
Je me dit que tu ne comprend pas tout ce que tu critique: Le virtual absolument rien a voir avec le final. Il sont complètement dissocié et ne correspondent absolument pas a la mème problèmatique.
C'était indépendant y'a 20 ans, mais à sens aujourd'hui le langage est intrinséquement lié à la plateforme d'exécution et inversement
Et biens paix a l'âme de .Net (et de Mono) : une méme plateforme pour tout les langages ....
Bon j'arrete, j'ai faim ... et ca ne m'interesse plus ...
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 0.
Cool :) Mais encore ? Il y a des langages comme OCaml
C'est un point de vue que tout le monde ne partage pas.
Peut être, mais dans l'industrie où les éditeurs répondent aux besoins des développeurs, on retrouve aujourd'hui la boucle foreach (ou similaire) en : C++ , Java, C#, Python, Ruby. Là encore t'as le droit de ne pas être d'accord, mais tu peux comprendre que dans la vraie vie c'est ce qui se passe.
Je me dit que tu ne comprend pas tout ce que tu critique: Le virtual absolument rien a voir avec le final.
Non c'est clair ca n'a strictement rien à voir : une méthode "finale" ne peut être réécrite alors qu'une méthode "virtuelle" peut être réécrite. Le mot clé final fait passer une méthode de "virtuelle" à finale en Java, mais bien sûr ca n'a rien à voir, c'est complètement dissocié c'est évident. T'as lu le lien que j'ai posté ?
ce n'est pas sale de faire des macros comme en C++ car elle sont bcp plus puissante
Je critique pas la "beauté" de l'implémentation dans le langage, je critique l'utilisation qui en est faite : certains sont même allé jusqu'à redéfinir une syntaxe à la Lisp en C++, si c'est pas montré jusqu'où les macros peuvent dénaturer le langage...
Et biens paix a l'âme de .Net (et de Mono) : une méme plateforme pour tout les langages ....
Tous les langages subissent des contraintes en passant à .NET : ils doivent être objet, avoir un héritage simple, berf utiliser le modèle de la plateforme. Certains de ces langages sont "retravaillés" pour coller à .NET comme le C++ pour en exploiter toutes les possibilités.
Et forcé de constater qu'on perd une partie de la philosophie d'un langage quand tout à coup on utilise un ensemble totalement différent de bibliothèques...
Franchement t'es gentil avec ton post visiblement plus pertinent que le mien mais à part dire "je suis pas d'accord", me dire que les macros c'est sale ou encore argumenter à coup de "..." je vois pas l'intérêt de ton intervention.
[^] # Re: Euh ...
Posté par Troy McClure (site web personnel) . Évalué à 4.
si tu parles de unimperative ( http://www.unimperative.com/ ) c'est pas basé sur les macros mais juste sur des couches bien épaisses de templates et de surcharge de l'opérateur virgule :)
[^] # Re: Euh ...
Posté par Julien . Évalué à 3.
Ta (vraie) vie à l'air d'effectivement se résumer à l'industrie.
Dans ce cas, tu as tout à fait raison de limiter ta vision des langages à java et c#, mais ne viens pas pourrir une news intéressante par tes troll et ton agressivité s'il te plaît.
Ce que je retiens de tes arguments, c'est 2 choses :
- si c'est différent de ce qui se fait actuellement, c'est mal (ça aide pas à évoluer, ça ...)
- si je tu tu sais pas ou si tu ne comprends pas, tu critiques (constructif ...)
Devant ton attitude, j'ai décidé de ne plus répondre à tes messages, comme pas mal d'autres ici. Tu es vraiment trop de mauvaise foi.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à -1.
Moi j'ai peur que ce langage n'est aucun avenir parcqu'il ne prend pas en compte les attentes des utilisateurs, visiblement il sert surtout à faire plaisirs à certains chercheurs. Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
Mon attitude n'a été que dirigé que par la "prétention" de la news. On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non. Quand à mon ton, désolé mais moi je n'ai pas dit que mon interlocuteur prenait les programmeurs "pour des cons !" (citation).
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Enfin quand je vois un commentaire noté pertinent quand il ne fait que dire "je ne suis pas d'accord" sans argumenté, je me demandes vraiment si vous n'acceptez tout simplement la critique, moi j'ai essayé de poser les bonnes questions (désolé si elles fachent ou si vous vous sentez agressez c'était pas le but), c'est vos réponses qui les ont rendues non constructives. Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est la dernière fois que te répond parce que t'es vraiment bouché, et c'est pas la première fois que je me fait cette réflexions. Tu as une aptitude pour donner l'impression d'argumenter d'une façon qui se révèle en fait bancale qui me laisse rêveur.
J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications.
Question : T'as au moins fait l'effort de jeter un oeil sur la doc ?
Elle est là : http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Va falloir que je la cite pour t'expliquer.
Page 47.
3.2.3 The mapping section The mapping section purpose is to format data slots description according to some o/xed hard-ware data structure.
In such a section, the compiler follows exactly the order and the description of slots as they arewritten to map exactly the
corresponding hardware data structure. Thus, one is able to write data slots description according to the hardware to handl
e.You can only deo/ne slots with the + symbol, and only datas (not code). Otherwise, these attributes are used exactly as th
e others not in the mapping section (readingor writting).
Section MAPPING
+ x1:uinteger; // 4 bytes, unsigned
+ x2:usmallint; // 1 byte, unsigned
+ x3:smallint; // 1 byte, signed
+ x4:ushortint; // 2 bytes, unsigned
+ x5:uinteger; // 4 bytes, unsigned
+ x6:shortint; // 2 bytes, signed
+ x7:ushortint; // 2 bytes, unsigned
These prototype match exactly a 16 byte physical structure.
Slots inside some mapping section are considered private for any other objects. Slotscan only be deo/ned with the + property
. No slot outside this section can be deo/ned with the + property.
La section INTERRUPT
Page 48
3.2.4 The interrupt section
The goal of the interrupt section is to handle hardware interruptions.In this section you can deo/ne methods (code slots) that will be executed only while there is an interrupt associated.Each slot is associated with one of the processor's interruptions [Hum90]. These slots dioeer from others in their generated code. For example, their entry and exit codesare related to the interrupt processing. Their invocations are asynchronous and borrow the quantum of the current process.Generally, these slots are little time consumers and they don't require specio/c process' context for their executions.It is thus necessary to be careful while programming such slots to ensure the consistency of the interrupted process.
Deo/ne your method (without return value, because you don't explicitly call it) as any otherclassical method. Then associate the adress of your method with the eoeective interrupt jump adress (it dependsof your architecture). This can be done using a system mapped object. When your interrupt physically happends, there is the call of your associated method, whichreturns a pointer on the code. The compiler will not optimize local variables of your interrupt method because of its particu-larity : the call depends of the context and cannot be anticipated during compilation.
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
L'intérêt de Lisaac est de permettre de gérer des interruptions ainsi que des sections Mapping permettant de poser le code sur une structure binaire.
Ceci permet donc d'écrire des drivers. IsaacOS, que certains qui se sont exprimés ont comme moi vu tourner sur une machine est un OS entièrement écrit en Lisaac qui utilise ces fonctionalitées pour écrire un OS from scratch.
Il te faut quoi comme preuve ?
Pour le reste, c'est une affaire de goût (pointeurs, langages, etc...) mais ces fonctionalitées permettent d'écrire des drivers.
mais il y a de gros problème de performance du compilateur.
Un langage qui sur une application "critique", un décodeur Mpeg2, 9852 lignes de code en C, 6176 lignes de code après traduction en Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
T'es con ou t'es con ?
Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
C'est vrai... mon logiciel de GPAO ou mon gros client mail, je le compile tout les matins en arrivant au boulot. Mon FireFox aussi..
Qu'est-ce qu'on en a à foutre que la compilation est "lente" (parce qu'en passant, "lente", Lisaac met 30 secondes pour compiler 60 000 lignes, je crois pas que Gcc puisse soutenir la comparaison, désolé).
Est-ce que tu pourrais me démontrer en quoi dans l'industrie, à part pour ces conneries de JIT (nous c'est pas notre problème, c'est compilé), on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non.
C'est de ma faute à moi ?? C'est de la faute à l'auteur de la news ???
Non, c'est une question qui concerne celui qui a le pouvoir de libérer le code, soit la direction de l'INRIA.
T'es prié d'apprendre à te plaindre à la personne responsable, pas ceux qui n'y peuvent rien.
Quand on te colle une amande parce que tu t'es mal garé, tu gueule contre le flic ?
Moi non. Il fait son boulot, et c'est normal qu'il le fasse.
J'aimerai que ça soit pareil vis à vis de moi, merci.
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
De plus, tu as toute la doc disponible sur le site pour apprendre ce qu'est l'objet à prototype. C'est un concept vieux de 20 ans, et cela ferai du bien à ta culture.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Apprend que tout est lié.
Il faut vraiment que tu apprennes à raisonner, TImaniac, ça devient grave.
Boubou te l'a déjà dit, lui qui est normalien et docteur en maths, il est bien placé pour le savoir.
Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Il est très loin d'être parfait, vu tout ce que je veux mettre dedans, et de toutes façon le modèle des langages à grammaire classique m'emmerdent, je trouve ça beaucoup trop restrictif.
Donc non. Je défend Lisaac parce que je pense que ce langage apporte ce qui n'existait pas jusqu'alors : un langage de haut niveau avec des performances proches du C (et bientôt meilleurs je pense) avec des fonctionalitées bas niveau.
La preuve, un OS a été écrit avec.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Je te l'ai déjà dit p****, c'est pas de notre ressort.
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par agmk . Évalué à 4.
Toi aussi t'es sous Gentoo \o/ ?
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 2.
Je l'ai lu mais je vois pas pourquoi tu me parles de ca : j'ai jamais dis qu'en Lisaac on pouvait pas écrire un OS ou un driver. J'ai jamais remis en cause les fonctionnalités de Lisaac, ca va naturellement dans votre ambition de remplacer le C.
Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
Là encore j'ai l'impression que tu lis un mot sur 2 : quand je parle des peformances du compilateur, je parle pas des perfs du programme compilé ! C'est toi qui a parlé de temps de compilation exponentiel il me semble... C'est ça que j'appelle un gros problème.
on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
Ben je me fies uniquement à ton exponentielle, si pour 60000 lignes de codes il faut 30 secondes, pour le double de lignes il faut déjà un temps très long, et pour le triple et le quadruple c'est imbittable. Ou alors tu dis n'importe quoi en parlant l'exponentiel, ce que j'espère pour Lisaac.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
Ben non je connais pas comme je viens de le lire, j'en connais que la présentation que vous en faites sur votre site. Tant mieux pour toi si t'en connais plus.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Je viens de dire que je m'étais bien gardé de débattre sur ce que je ne connaissais pas... Enfin moi j'ai du mal à comprendre comment tu peux débattre des langages sans même comprendre de quoi je parle quand je te pointe un article sur les méthodes virtuelles... C'est un petit peu la base de beaucoup de langages objets actuels...
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
Que veux tu qu'on face d'une lib libre ou même d'un OS libre ? Toute la partie intéressante et indispensable au reste (compilation de prototype et optimisation globale dans le compilo) sont dans ce qui est fermé !
avec des fonctionalitées bas niveau.
Je vois bien l'intérêt, mais j'ai quand même une question : en C on doit parfois faire appel à de l'assembleur pour faire mumuse avec du matériel particulier (notamment quand on écrit un OS)... Vous faites comment en Lisaac ?
[^] # Re: Euh ...
Posté par LeMagicien Garcimore . Évalué à 4.
Je suis assez d'accord avec toi, mais ce dernier point me gêne. En fait, tu peux très bien dire :
trop de constructions dans le langage ==> trop de manière d'écrire le même code, difficulté de relecture par un autre programmeur, difficulés de maintenance, bugs potentiels.
Genre Perl avec ce 25 façons de faire la même chose, ce qui fait que chacun utilise la sienne et que c'est super chiant de relire du code Perl écrit pas quelqu'un d'autre...
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . Évalué à 1.
Evidemment, ne pas proposer des constructions redondantes mais des constructions "standardisant" la rédaction des patterns courants pour simplifier la rédaction et la relecture. Perl c'était visiblement pas les mêmes objectifs ;)
[^] # Re: Euh ...
Posté par golum . Évalué à 2.
La liaison dynamique existe pour supporter le polymorphisme, comment l'éviter si on ne connait pas l'implémenation de la classe que l'on va utiliser? Ca signifie qu'il faut refaire l'edition de lien de tout ton projet si tu rajoutes une nouvelle classe qui implémente le même contrat ?
[^] # Supprimer la VFT
Posté par Ontologia (site web personnel) . Évalué à 4.
Tu peux aussi, avec le compilateur compiler des "macro-objets", c'est à dire que tu as un code procédural (un fichier C avec plein de fonctions dedans et un .h associé), et tu utiliseras (c'est le cas d'IsaacOS) de la liaison dynamique pour communiquer entre objet.
(Bien qu'on ai imaginé Benoit et moi un mécanisme tordu de table dichotomique à trou qui se rempliraient une fois les objets installés en mémoire...)
Prenons un exemple.
Soit une classe/prototype IMAGE et ses descendants BMP et JPG. Soit une méthode affiche_toi() définie comme virtuelle dans IMAGE, mais contenant du code dans BMP et IMG.
Soit image une variable de type BMP ou JPG.
1/Dans le monde à classe (Eiffel, donc), on effectue une analyse syntaxique (ou une analyse de flot) du code pour créer des procédure contextualisant le polymorphisme.
C'est à dire que le compilateur SmartEiffel va produire en C
BMP_affiche_toi()
JPG_affiche_toi()
et il colle un test du genre si besoin :
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Tandis qu'avec une VFT, image est un pointeur sur la structure :
(là imagine que C++ produise du C)
struct Image_jpg
{
//données
void *affiche_toi();
};
et
struct Image_bmp
{
//données
void *affiche_toi();
};
donc si la variable (l'instance dans le monde objet) image est de type BMP, on a
Image_bmp *image;
Et un appel de la fonction se fait
image->affiche_toi();
La compilation de l'Eiffel est pas trop problématique car c'est un langage à classe, donc ta variable image est soit de type BMP ou soit de type JPG. Il suffit de lire le code et d'appeler la bonne fonction.
Seulement ni C++ qui fait de la VFT, ni Eiffel qui fait du procédural ne produise que la fonction qui va être utilisée.
Même si tu as un code du genre
private BMP image;
image.set_image(mon_bitmap); //on lui balance le tableau d'octets
image.affiche_toi();
C++ va te pondre les deux structures décrites plus haut et va te faire un appel dans la VFT.
Eiffel, il me semble (je ne suis pas sûr) va faire de même, mais en procédural lui, donc sans vider le cache code du processeur, ce qui coute très cher et en pouvant faire des inlines, etc....
2/Dans le monde à prototype, le problème est beaucoup plus ardu parce tu as l'héritage dynamique.
Donc là tu renverse ton arbre d'héritage.
Tu vas avoir IMAGE qui va hériter, soit de JPG ou soit de BMP
Tu auras dans le code :
- name := IMAGE;
Section INHERIT
- parent choix : BOOLEAN : OBJECT <-
(
+ result : OBJECT;
choix.if {result := JPG;}
else
{result := BMP;};
result
);
Il suffit que tu en enchaine qq uns comme ça et ça explose vite...
Donc là on est obligé de faire de l'analyse de flot : il faut recencer le code vivant, autrement dit, calculer quels sont les possibilités que tu vas utiliser pour virer les autres.
Le compilateur recence donc le code vivant, spécialise les appels (s'ils se rend compte que tu n'utilise jamais BMP.affiche_toi; il ne la compile pas) et inline au besoin.
Mais je le répète, ce n'est possible que si le compilateur dispose de l'ensemble du code sous la main.
Sinon, tu es obligé de faire de la VFT ou de la table dichotomique à trou, c'est à dire à du code asm auto-écrit, et là ça part un peu en live.
Les contrats c'est pareil, ils sont compilés, backpropagés, etc...
Pour finir, je cite Benoit, dans un mail qu'il m'a écrit il y a un an et demi pour m'expliquer ça (et dont je me suis largement inspiré) :
"
Le pb est que C++ n' est pas capable d'analyser suffisemment son code pour
savoir si il y a un ou plusieurs type possible pour un site d'appel.
Consequence: Tous les appels sur les objets sont realise' par la technique
decrite en 4)[ie. la VFT]. Alors que, dans la pratique, il n' est pas rare que le type
soit unique et que donc, l'appel peut etre direct (statique).
Dans un langage comme C++, tout n' est pas objet, donc 2+2 n' est pas
un appel du type 2.plus(2) (le message "plus" sur l' objet 2) donc sa technique
reste lente mais viable. En Lisaac, 2+2 est un appel sur objet, si nous
utilisions la technique de C++, les perfs serait tout bonnement catastrophique!
Ici, le compilo detecte sans mal qu'il n'y a qu'un seul type dynamique
possible, l'appel est direct et statique sur la methode "plus" de NUMERIC.
Cette methode sera ensuite inline', et nous retomberons sur un 2+2 aussi
efficace que C.
Meme dans le cas de site reellement polymorphique (plusieurs type dynamique
possible), il est preferable de realiser des branchements avec des appels
statique.
Exemple:
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Les appels statiques ainsi produit peuvent ensuite etre inline', specialise',
... Et les caches du processeurs ne sont pas vide' (meme dans le cas de
multiple branchement, le pipeline execute les differentes branches en meme
temps et choisi les effets de bord de la bonne branche apres evaluation
de la conditionnelle).
Donc, la ou C++ realise un appel indirect (considere' comme liaison dynamique),
le compilo Lisaac produit ou un appel statique (84%) ou plusieurs branches
avec des appels statiques (16%).
Ce score est passe' a 91% en produisant des methodes plus specialise' selon
le contexte courant d'appel. Nous produisons plusieurs exemplaires d'une
methode. Chaque exemplaire etant specialise' a un contexte d'appel et donc
plus rapide (moins de types dynamiques possible dans ce contexte d'appel plus
precis)."
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Supprimer la VFT
Posté par left . Évalué à 4.
C'est à dire que le compilateur SmartEiffel va produire en C
BMP_affiche_toi()
JPG_affiche_toi()
et il colle un test du genre si besoin :
if (image->type == BMP) {
affiche_toi_BMP();
} else { // C'est du JPEG
affiche_toi_JPEG();
};
Je pinaille mais:
1. Ce n'est pas Eiffel qui fonctionne comme cela, mais SmartEiffel. Eiffel est un langage et n'impose rien pour l'implémentation du compilateur.
2. Je crois (j'espère!) que ce n'est pas comme ça : comme le compilo connait toutes les classes au moment de la compil, il fait un:
switch (image->type)
{
case BMP: affiche_toi_BMP(); break;
case JPEG: afficheçtoi_JPG(); break;
default: raise_exception (...);
}
et il se trouve que ce code n'est pas moins rapide (voire même plus rapide) que de passer par une VFT. Avec un if/else, le nombre de tests pourrait devenir bien plus important (et donc pénalisant par rapport à l'usage d'une VFT).
Mais ce n'est bien sûr possible que parce que *tous* les types sont connus au moment de la compilation. D'où l'impossibilité d'utiliser les DSO avec SmartEiffel.
[^] # Re: Supprimer la VFT
Posté par outs . Évalué à 6.
Il y a bien une table de liaison dynamique avec SmartEiffel. Mais elle est restreinte aux seul cas possibles par l'analyse du code.
Si jamais le compilo trouve qu'il n'y a qu'un seul cas possible il supprime le mécanisme et on se retrouve avec une methode aussi efficace quand dans le cas d'un fonction non virtuel en C++. Avec en différence que l'optimisation est réalisée par le compilateur systématiquement.
Ca c'est pour l'héritage simple. Pour l'héritage multiple c'est encore mieux que cela. Il n'est en effet pas possible d'utiliser dans tous les cas une table pour résoudre le polymorphisme dans le cas multiple, en particulier si il y a des cycles dans les parents de la classes. Dans ce cas il faudrait faire un parcour du graphe. Solution très couteuse (c'est une des raisons pour laquelle pas mal de langague ne supportent pas l'héritage multiple). Mais il existe une solution. En analysant le code et en calculant tous les cas possible on peut quand même créer une table. D'ou un héritage multiple au même cout à l'execution que le simple.
Je rappelle qu'il est impossible du supprimer tout le temps la table. En effet l'héritage bien utilisé remplace des if dans le code. Dans ce cas il n'y a pas de surcout a utiliser le polymorphisme cela correspond juste au if qui a été supprimé.
J'espere avoir pas dit de connerie
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
T'abuses, là!
C'est même plutôt le contraire : les propos éronnés sur Ada dans ces colonnes se font rares, je trouve que les allusions sont plus justes ces derniers temps. J'y vois preuve d'une meilleure connaissance (j'espère), ou au moins d'une meilleure reconnaissance.
C'est peut-être lié au fait qu'on a pas mal parlé du langage dans la presse du "libre" depuis 2005. Bravo au passage à Yves Bailly pour sa série d'article dans GNU/Linux mag, et à Etienne Baudin pour ses articles dans Login.
J'espère que d'autres articles exposeront les nouveautés d'Ada 2005.
[^] # Re: Euh ...
Posté par Lionel Draghi (site web personnel) . Évalué à 2.
Que Java, je n'en doute pas. Que Ada me paraît être une bien plus belle performance.
Au passage, si tu les mets au même niveau, comme ta phrase peut le laisser penser, alors jette un coup d'oeil sur https://libre2.adacore.com/Software_Matters/, en particulier la présentation Programming in the Small: C/C++/Java Pitfalls & Ada Benefits
J'en recommande également la lecture à ceux qui pense que reprendre la syntaxe du C est un bon choix pour un nouveau langage.
Etant donné que nous sommes nombreux à considèrer la détection d'erreur à la compilation comme une qualité essentielle du couple langage/compilo, nous donner quelques exemples d'erreurs que ne détecte pas Ada ferait une excellente publicité pour Lissac.
[^] # Re: Euh ...
Posté par Romain Be. . Évalué à 4.
Complètement faux..
Ce raisonement a déja été tenu pour un grand nombre d'autres changement technologiques, et pas uniquement en informatique.
Le problème n'est pas de savoir si le C sera un jour remplacé, c'est évident qu'il le sera un jour comme toute technologie, il n'y a qu'à regarder l'histoire de l'humanité jusqu'à présent.
En revanche, se prétendre la Paco Rabane de la technologie est plus que délicat. En effet, l'histoire nous apprend qu'un changement majeur de technologie n'est pas franchement toujours dicté par les innovations et améliorations, mais bien par un subtile mélange de chance, d'innovations (quand même!), d'opportunisme, et de plus ou moins bonne anticipation des acteurs.
Un exemple? hum...
MS Dos et le premier PC IBM
"Histoire
Son origine remonte à 1981, lors du lancement du PC (Personal Computer) par IBM. La société avait demandé à Digital Research, créateur de CP/M qui dominait le marché à l'époque, de porter son système sur le PC, mais devant le peu d'empressement de son directeur Gary Kildall, elle s'était adressée également à Microsoft (une autre version circule selon laquelle Kildall se serait fait purement et simplement « doubler » par Gates !)."
http://fr.wikipedia.org/wiki/MS-DOS
IBM ne croyait pas au PC, et planchait sur peu de ventes. Elle a donc choisi un OS moins bon que ce qui se faisait à ce moment par ailleurs car il était moins cher.... Seulement le PC a cartonné, avec les conséquences que l'on sait! :)
[^] # Re: Euh ...
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Il y a toujours de grosses applications écrites en COBOL et des programmes de calcul écrits en FORTRAN !
Je pense que Java remplace progressivement le COBOL dans les entreprises, mais le FORTRAN n'a pas encore vraiment de successeur.
Pour la petite histoire, j'ai écrit une assez grosse application de gestion de données techniques en FORTRAN. Si je devais la recommencer, je prendrais un langage à objets mais je n'en ai encore trouvé aucun qui me plaise tout à fait.
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par salvaire . Évalué à 5.
- compréhensible par des scientifiques (gens normaux): donc pas C++, pas de STL,
- sans perte de performance, langage compilé: donc pas java à cause de VM,
- optimisé pour le calcul numérique, soit un accés directe aux registres du processeur: c'est pas le cas d'ocaml, et peut être de lisaac
Il y a bien C, mais c'est pas objet ... Le choix est donc difficle.
[^] # Re: Euh ...
Posté par gasche . Évalué à 2.
[^] # Re: Euh ...
Posté par salvaire . Évalué à 4.
[^] # Re: Euh ...
Posté par med . Évalué à 2.
[^] # Re: Euh ...
Posté par Troy McClure (site web personnel) . Évalué à 2.
Je ne peux pas laisser passer ça.
FORTRAN MUST DIE.
Signez la petition: http://www.fortranstatement.com/cgi-bin/petition.pl
[^] # Re: Euh ...
Posté par CdeMills . Évalué à 4.
1) "If it ain't broken, don't fix it" (A. Cox)
2) Certaines applis en milieu industriel ont des années de développement derrière elles. Les premiers programmeurs ont quité la boîte, la doc, quelle doc ?, les tests, quel tests ?, bref personne n'oserait changer de façon fondamentale l'existant.
3) les programmeurs sont souvent issus de hautes écoles autant que d'universités : DEUX mondes à convaincre plutôt qu'un.
4) il faut en outre convaincre les décideurs (vos programmeurs ne passeront plus un temps bête à résoudre des bugs), les RH (sisi, ce genre de profil se trouve), les autres fournisseurs de produit (on aurait besoin que votre API soit portée dans un nouveau language), etc
Bref, c'est pas gagné. Ca ne veux pas dire que ce n'est pas faisable ;-) Le C a aussi commencé sa carrière comme un language de niche ...
CdM
[^] # Re: Euh ...
Posté par ouah (site web personnel) . Évalué à 2.
> trop connu, base installée trop grande, trop de systèmes critiques reposent dessus.
Cela fait déjà quelques années que le C s'est fait "déboulonner". S'il est majoritairement présent dans le monde du logiciel libre, dans le monde de l'entreprise il a quelques longueurs de retard au profit de Java/C+/C#. Essaye de trouver une place de travail si tu ne codes qu'en C, ce n'est pas évident.
Dans un ACM Communications de la fin de l'année passée, le journal montrait les offres d'emplois en fonctions des langages et le C était carrément à la traîne.
[^] # Re: Euh ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Le C remplace notamment l'assembleur dans le codage sur DSP par exemple.
L'informatique industriel bien que moins visible est quand même énorme...
"La première sécurité est la liberté"
[^] # humour
Posté par bertrand . Évalué à 2.
- faire normaliser ce langage par un comité ISO (probabilité presque nulle)
- faire découvrir aux gens que ce "langage est mieux".. bon courage
- faire changer d'habitude les programmeurs
- faire enseigner ce langage dans toutes les universités du monde
Beaucoup ont essayé de remplacer le Cobol, personne n'a réussi. le Cobol est indéboulonnable : trop connu, base installée trop grande, trop de systèmes critiques reposent dessus. Pour la place du language "mieux, plus productif", la place est déjà prise : Ada et/ou Java.
[^] # Re: humour
Posté par stephwww . Évalué à 3.
>- faire normaliser ce langage par un comité ISO (probabilité presque nulle)
Question naîve : Qu'est ce qui fait qu'un langage peut être normalisé par un comité ISO ou non ?
# Titre
Posté par machin Truc . Évalué à 3.
Ne sachant pas qui et comment contacter la personne qui pourrait changer le titre...
# Fautes
Posté par tiot (site web personnel) . Évalué à 3.
ont été comparés (ont été == auxiliaire être)
# Mieux que le C
Posté par Jarod_Summers . Évalué à 6.
Y'a deja Haskell ^^.
http://www.haskell.org/
The next mainstream programming language:
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc(...)
N'y voyons ici qu'un partage de point de vue et non une guerre de chapelles ^^.
[^] # Re: Mieux que le C
Posté par agmk . Évalué à 3.
Les concepteurs le disent eux mêmes, Haskell n'a pas du tout pour vocation de remplacer le C (troll: ce serait réducteur) :
http://haskell.org/haskellwiki/Introduction#When_C_is_better
Ca ne l'empèche pas d'être un excellent langage (autre troll: le meilleur pour certains trucs ?), mais pratiqué en majorité par des docteurs en info et/ou maths, et incorporant les toutes dernières avancées/recherches en théorie des langages (évaluation paresseuse, inférence de type ou plus récemment des versions distribuées & co), alors que Lisaac est il me semble sensé être relativement simple d'accès.
[^] # Re: Mieux que le C
Posté par lasher . Évalué à 2.
[^] # Re: Mieux que le C
Posté par agmk . Évalué à 3.
[^] # Re: Mieux que le C
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais les langages plus ou moins purement fonctionnelles sont beaucoup plus complexe à comprendre que des langages impératifs.
"La première sécurité est la liberté"
[^] # bof
Posté par Vivi (site web personnel) . Évalué à 3.
... parce que sinon moi je dis « les langages impératifs / orientés objets sont beacoup plus complexes à comprendre que les langages fonctionnels » (et je le pense).
[^] # Re: bof
Posté par reno . Évalué à 1.
[^] # Re: bof
Posté par remyremy . Évalué à 9.
Dans mon entourage professionnel : 0.
Alors malgré tout le respect que j'ai pour eux, leur avis sur la question me semble assez peu pertinent.
[^] # Re: bof
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: bof
Posté par reno . Évalué à 2.
Si tu juges l'avis des étudiants qui apprennent un language pas pertinent, il ne faut pas s'étonner que personne ne l'utilise..
[^] # Re: bof
Posté par gasche . Évalué à 3.
[^] # Re: bof
Posté par lasher . Évalué à 4.
1) Ouvre n'importe quel bouquin de niveau licence/maîtrise pour faire de l'algo.
2) Choisis les chapitres concernant les graphes et les arbres plus particulièrement.
3) Prends un algo au hasard.
4) Surprise ! L'algo est récursif. Et c'est carrément « naturel » de penser ainsi, soit dit en passant. L'alternative itérative est beaucoup moins facile à imaginer.
5) Réessaie avec le chapitre sur les tris efficaces (pire cas ou cas moyen). Retourner en 4 pour la conclusion.
Il faut évidemment nuancer tout ça : si l'algo en question est récursif terminal, il existe une version équivalente itérative, et on peut même s'amuser à automatiser la transformation (certains compilateurs le font dans les cas assez simples).
Par contre, une chose est certaine : autant l'approche récursive est tout à fait naturelle dans certaines structures de données (les structures ... récursives, tiens donc !), autant, pour un langage comme le C, la récursivité peut faire très mal (surtout si elle n'est pas terminale).
Moralité : il faut des mecs super balaises en algo/prog C pour élaborer des algos itératifs pour gérer les cas (cf. la glibc, par ex), sinon il y a risque de faire exploser la pile des variables automatiques.
Corollaire : les programmeurs « moyens » utilisent des structures de données comme on le leur a dit, sans vraiment leur expliquer comment elles fonctionnent, et du coup bousillent totalement les perfs d'un programme. Par exemple, ils ont l'habitude d'utiliser des listes d'éléments (en Java, C#, que sais-je), et n'ont jamais entendu parler des arbres rouge-noir (pourtant implémentés en tant que TreeMap en Java par ex). Résultat : ils vont se faire chier à faire des sortes de « tri par insertion » sur une liste, plutôt que d'utiliser une structure spécifiquement élaborée pour ce genre de cas.
Maintenant, un langage fonctionnel a beau avoir une approche plus « mathématique » de la programmation (pour la forme), je pense avoir eu autant de mal au début à comprendre comment faire des boucles for/while/do-while en Perl/C qu'à faire des récursions en LISP pour la première fois. Non, pire. Ca avait été plus dur, car comme on m'avait relativement bien formé à C, on n'avait cessé de me répéter : « la récursivité, c'est le Mal » (à cause du passage des paramètres par valeur, etc). Donc j'étais bien endoctriné.
[^] # Re: bof
Posté par reno . Évalué à 1.
Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof.
La plupart du temps quand on programme, cela tient plus de la recette de cuisine avec des bon vieux automates à état fini qu'aux algorithmes que tu as cité, donc la recursivité, à part dans les bouquins d'algo, bof!
[^] # Re: bof
Posté par lasher . Évalué à 7.
Mmmmh. Je m'en sers tous les jours en faisant des "cd ..", "cd /usr/share/doc", etc. Ah oui, et si tu manipules du XML, avec des requêtes XPath, ça peut être pas mal de comprendre comment fonctionne la structure d'un arbre. Ca peut aussi éclairer ta lanterne sur le fait qu'utiliser l'opérateur "//" doit être mûrement réfléchi.
« Pour le tri, il y a des librairies qui font cela que l'implémentation soit récursive ou pas bof. »
Idem pour les arbres (d'où ma référence à la glibc). Mais relis mieux ce que j'ai dit ensuite : le problème est de savoir utiliser les bons outils, et donc, connaître les forces et les faiblesses des structures de données manipulées.
« La plupart du temps quand on programme, cela tient plus de la recette de cuisine »
Euh. Tu te rends compte que ce que tu dis finalement, c'est « Puisque j'y arrive de cette manière, pourquoi j'essaierai d'apprendre à le faire d'une autre manière, aussi pratique soit-elle au final ? »
La programmation fonctionnelle est extrêmement puissante, permet de faire des programmes assez concis, et faciles à comprendre. Après, il est possible de faire de même en prog itérative, bien sûr. Mais il s'agit dans les deux cas d'outils à utiliser en fonction des besoins. Faire une IA en C est bien plus difficile que faire la même chose en LISP. Faire un programme sûr est bien plus facile avec un langage comme Java (qui est sûr du point de vue des types) qu'avec un langage de type C ou FORTRAN.
Dans tous les cas, la prog fonctionnelle n'est certainement pas plus compliquée à apprendre dans l'absolu que la prog itérative. D'ailleurs, si tu prends un langage comme Perl, il permet de faire les deux (en faisant une ou deux contorsions, c'est vrai).
[^] # Re: Mieux que le C
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il prend haskel pour exemple mais fini aussi par ses défaults. Notamment l'inférence de type qui peut être pris en défault.
"La première sécurité est la liberté"
[^] # Re: Mieux que le C
Posté par Ontologia (site web personnel) . Évalué à 2.
J'ai bien envi de mettre pas mal de chose que je vois dedans dans Lisaac.
Pour la v0.4, ça serait bien.
C'est vrai qu'il serait intéressant de définir les choses de manière plus mathématiques, par exemple de parler d'entiers naturels, d'intervals, de réels, de définir des ensembles du genre A={ (x,y) ¤ X | x<20| y>56}
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# gestion automatique de la mémoire
Posté par salvaire . Évalué à 4.
[^] # Re: gestion automatique de la mémoire
Posté par Ontologia (site web personnel) . Évalué à 1.
./lisaac/distrib/lisaac/lib/memory/mem_block.li
Dans ces deux fichiers, la réponse à ta question tu trouveras :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Portable ?!?
Posté par lud42fr . Évalué à 3.
Sur ma machine (amd64 - gentoo) :
~/tmp/lisaac/lisaac $ make
- Lisaac compiler installation For Unix / Linux / Windows -
Please wait...
install_lisaac.c: In function `get_environment_variable__87F':
install_lisaac.c:659: warning: cast to pointer from integer of different size
Run 'install_lisaac' to finish the installation
~/tmp/lisaac/lisaac $ ./install_lisaac
Segmentation fault
Mouais !!!
De plus je me pose une question: comment debugger le code. Avec gdb je suppose, mais dans ce cas on debugge le code C genere ?
[^] # Re: Portable ?!?
Posté par Ontologia (site web personnel) . Évalué à 3.
Cela sera corrigé dans la prochaine version.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Portable ?!?
Posté par Hugo . Évalué à 2.
Je me pose la même ...
[^] # Re: Portable ?!?
Posté par Ontologia (site web personnel) . Évalué à 2.
Pour le moment, il faut faire avec le -d (option du compilo)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# N'y-a-t-il pas antinomye ?
Posté par abgech . Évalué à 2.
Comment être plus performant que le C si l'on génère du C ?
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par agmk . Évalué à 6.
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par Jean-Michel Hautbois . Évalué à 3.
Système embarqué vs Système autre...
En effet, dans l'embarqué, le C est très utilisé. Ce qui pose problème le plus souvent, c'est la mémoire, si la gestion mémoire de ce langage est meilleure que la meilleure gesion mémoire qu'un humain spécialiste de l'embarqué peut faire, alors, il est très intéressant, c'est évident !
Mais comme aucun document n'est disponible pour pouvoir faire ce genre de comparaison, c'est dommage. De plus, quelles architectures sont supportées ?
A partir du moment où gcc existe sur une archi, Lisaac tounera ?
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par pfrenard . Évalué à 2.
- de faire un "méta" language qui génere du C "optimisé",
- ou bien à terme d'avoir un compilo capable de généré du code exécutable pour toutes les archi,
- ou bien carrément un langage supplémentaire de GCC (qui signifie rappelons le "GCC, the GNU Compiler Collection" )
Bon courage aux développeur/codeurs !
Fox
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Non de faire un langage qui, au lieu de générer de l'asm, génère du C (très bas niveau le C).
ou bien à terme d'avoir un compilo capable de généré du code exécutable pour toutes les archi
Je ne vois pas trop à quoi cela pourrait servir : les types qiu font tourner Gcc sur n architectures font très bien leur boulot. Pourquoi s'emm** à refaire la roue ?
ou bien carrément un langage supplémentaire de GCC (qui signifie rappelons le "GCC, the GNU Compiler Collection" )
Why not ? Il faudrait modifier le compilateur afin qu'il crache du langage intermédiaire. Mais l'intérêt est très moyen, vu qu'on peut utiliser le compilateur C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: N'y-a-t-il pas antinomye ?
Posté par Thomas Douillard . Évalué à 3.
Après, le compilo il peut le transformer en ce qu'il veut, en général de plus bas niveau (C, assembleur, etc.), mais le langage en lui même, il génère rien, il permet juste d'exprimer des trucs.
# IDE
Posté par jmny . Évalué à 2.
[^] # Re: IDE
Posté par Ontologia (site web personnel) . Évalué à 5.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: IDE
Posté par jmny . Évalué à 3.
# J'espère....
Posté par GuieA_7 (site web personnel) . Évalué à 8.
Sinon j'espère que le langage ne tombera pas dans un certain nombre d'écueils (en plus de la non-'libricité' - ça existe ça??!) : non standardisation/normalisation, pas de librairie standard, etc....
Parmi les écueils possibles, celui qui me semble être assez récurrent à l'INRIA, c'est de faire un langage avec des idées très puissantes (donc potentiellement très bon), mais qui néglige tout le reste qui n'est pas très conceptuellement intéressant, mais qui est pourtant indispensable dans la vraie vie (d'un codeur :).
Je m'explique : j'ai découvert OcamL dans mon école d'ingé, dans le cadre de la programmation fonctionnelle, et ça m'a bien plu. Plus tard sur LinuxFR j'ai appris qu'il était multi-paradigmique, qu'il pouvait être interprété, compilé ou dans une VM. Il montait encore dans mon estime. Pourtant plus tard, alors que j'errais sur le Net à la recherche d'un éventuel langage pour de futurs projets, je me suis aperçu qu'il avait l'air de manquer des choses assez essentielles (à mon sens) dans le langage :
- j'aime les systèmes de plugins, mais d'après la doc, on ne peut charger de module OcamL qu'en mode VM. Du coup c'est assez décevant, je dois me passer du mode compilé (le coup des 3 modes d'exécution est donc un peu faux). Peut-être qu'on peut charger des modules en C ??(mais alors ce n'est plus un programme en OcamL à proprement parler)
- je m'intéresse aux système multi-tâches, mais là encore déception : il y a des lightweight threads, c'est très bien, mais nulle trace de vrais threads qui permettent d'utiliser plusieurs processeur à la fois.
Je précise que je ne suis pas un spécialiste OcamL, donc j'ai très bien pu louper quelque chose (n'hésitez pas à me le signaler). Mais si je ne me trompe pas sur les 2 points plus haut, c'est assez gênant. Parce que s'il n'y avait pas de parser XML ou de bibliothèque d'envoi de mails par exemple, et ben il suffirait de les coder (du moment où il y a la gestion des fichiers ou des sockets pour mes exemples, ou qu'on peut binder avec du C), mais dans les cas que j'ai cités, il faudrait toucher au langage lui même, ce qui n'est plus du même niveau !!
J'ai vu les mêmes manques dans SmartEiffel (coder aussi par l'INRIA). Attention, les gars de l'INRIA sont certainement très compétants et je n'ai pas l'intention de casser du logiciel libre (au contraire). Mais d'un autre côté, on voit souvent des gens vanter leur outil de prédilection (moi le premier), et parfois se plaindre qu'il n'est pas assez utilisé alors qu'il est bien mieux que tout le reste sur tous les plans. Alors que ce n'est pas vrai : en C je vais peux être pas avoir des super objet dynamique sans Virtual Table, avec analyse du flot d'exécution le tout avec des paradigme de haut niveau etc..., mais si je veux faire des plugins, des threads, et ben je pourrais, je ne serais pas bloquer par le langage. Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'. Alors évidemment on peut faire des tas de programmes très bien sans plugins ni threads, mais c'est dommage que ces langages modernes ne permettent pas ce que peuvent des langages vieillissants.
D'ailleurs même si ça me fait un peu mal de le dire, en parcourant rapidement la doc de Mono, je n'ai pas vu de manque si cruel. Ne vous méprenez pas, Mono n'est pas (encore?) installé sur ma machine, je ne fais pas de prosélytisme.
Voilà, en espérant que mes remarques soient constructives.
[^] # Re: J'espère....
Posté par ouah (site web personnel) . Évalué à 1.
lubricité ?
[^] # Re: J'espère....
Posté par reno . Évalué à 2.
Si on te prends à la lettre tu as raison bien sûr.
Mais des chercheurs pour Microsoft bossent sur un OS Singularity écrit en C# mais compilé "normalement" sans VM, les threads de l'OS partagent tous le même espace mémoire mais ils utilisent des preuves de programmes pour s'assurer que deux thread ne vont pas écrire ailleurs qu'elles en ont le droit, ce qui est une forme de 'bac à sable'.
Ceci dit, tout l'OS n'est pas prouvé bien sûr..
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je suis d'accord avec toi. L'analyse globale du code, c'est bien mais si cela supprime le chargement dynamique de librairie, c'est plutôt une regression dans 99% des cas. Sans cette fonctionalité, pas de greffons ;-(
Pour l'aspect multi-thread, encore une fois, l'ada l'a a l'origine ! C'est pareil ici, il faut un modèle permettant de faire du parallèlisme simple dans le langage. Surtout que les microporcesseurs mulit-core arrivent et que c'est clairement le futur proche.
L'INRIA a pas mal travailer sur Eiffel, personnellement, je lui préfère Sather (et pSather). Sather ressemble a Eiffel mais a choisis la voie de l'orthogonalisation des concepts plutôt que celui de la fusion. Bilan, je le trouve bien plus propre et simple. Un truc super en Sather sont les iterateurs, sorte de coroutine, qui renvoi la double structure des conteneurs du C++ au moyen age, la structure de boucle d'Eiffel dans la catégorie des usines à gaz... Les itérateurs de Sather sont bien plus puissant que ceux de ruby, leur implémentation n'est pas si difficile /a priori/ et leur utilisation élimine des centaines de bogues des programmes.
Une autre caractérisque qui manque a beaucoup de langage est la reflexibilté. La reflexibité permet, entre autre, le transfert des objets d'une machine à une autre.
[^] # Itérateurs et ruby
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Itérateurs et ruby
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Les itérateurs de Sather sont défnis comme les autres fonctions mais leur parametres peuvent avoir en plus des attributs in, out, inout l'attribut 'once' qui veut dire evalué qu'a la première execution. Bien sur, l'objet sur lequel est appellé l'itérateur à l'attribut once.
Ensuite, on ne peux les utiliser QUE dans une boucle 'loop' du langage. On peux donc en mettre plusieurs dans la même boucle et les itérateurs vivent leur vie chacun de leur coté mais en parallèle. On n'a donc pas une boucle par itérateur.
[^] # Re: J'espère....
Posté par golum . Évalué à 4.
Pourrais tu developper un peu, je ne saisis pas bien ce que tu entends par là ?
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
[^] # Re: J'espère....
Posté par outs . Évalué à 3.
On peut donc utiliser les même méchanismes maintenant en Eiffel, bien que ce ne soit pas l'habitude.
(et aussi dans le pseudo standard ECMA de Eiffel qui est sortit il n'y a pas très longtemps)
# Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 6.
Comment cela peut être possible ?
Premier point : Le minimalisme du code.
Le langage Lisaac est basé sur 7 primitives (elles sont définies dans le manuels, on les trouve aussi dans la librairie sous la forme `1`).
Ce nombre minimaliste permet au compilateur de travailler sur un code intermédiaire extrêment minimaliste et dépouillé.
C'est nécessaire pour réaliser l'ensemble des optimisations.
Second point : La suppression de la liaison dynamique
Je reprend ce que j'ai écrit sur Wikipedia :
Les langages objets classiques, jusqu'à SmartEiffel, utilisent des VFTs (de l'anglais Virtual Function Table) pour compiler la liaison dynamique: :
Soient l'objet IMAGE, et ses deux descendants PNG et XCF. Quand on appelle la fonction PNG.affiche_toi() en Java ou en C++, on se retrouve en assembleur avec un appel du type :
Call dword ptr [__adresse_de_PNG + index_dans la_VFT_de_la_fonction_affiche_toi()]
L'adresse de PNG (l'objet receveur) pointe sur la base de la VFT, ensuite on ajoute le bon index pour recuperer le champs correspondant à la bonne methode...
Ce qui implique que cela vide le cache du processeur et que l'inlining est bloqué à la compilation.
Le compilateur lisaac supprime la liaison dynamique en analysant finement le type dynamique des objets grâce à un algorithme de prédiction de type. La liaison dynamique supprimée, il devient possible de procéder à des inlining et à des spécialisations de code.
Je devrai y rajouter que le polymorphisme se gère en utilisant une table duchotomique, ce qui implique que la recherche se fait en log de n.
Cela permet surtout d'avoir un code entièrement procédurale, sans dynamicité pour tuer les performances.
Troisième point : L'analyse de flot
Comme vous le savez pour la plupart d'entre vous, l'analyse de flot est une technique qui permet d'analyser le code (son graphe) pour y trouver diverses choses.
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
C'est un algo de complexité exponentielle, ce qui est risqué pour des programme de taille plus ample.
L'analyse de flot va par exemple permettre de détecter que l'on ait par exemple n := n*2+1; quelque part et que dans une autre méthode, "10 km plus loin" on fasse un (n mod 2).if
Dans ce cas le test est supprimé.
Ce n'est pas encore implémenté car trop gourmand en mémoire (4 Go pour 400 lignes hors librairie).
Pour le moment, le compilateur recence le code vivant, supprime toutes les étapes inutiles, supprime le code mort, spécialise les types.
L'analyse de flot permet, par reconnaissance de forme, de transformer des structures lourdes en structures légère.
Par exemple le message if, initialement, est écrit comme suit (en C):
if(id_obj) { /*V*/}
else
if (!id_obj) { /*F*/}
transformé en if (id_obj) { /*V*/} else { /*F*/}
de même les récurcivité terminale sont dérécurcivées.
Dans le futur, on peut pense à des techniques d'optimisation de la mémoire, pour se coller à la structure du cache, ou des techniques permettant de gérer automatiquement les threads, ou encore des techniques permettant de spécialiser des corps de calculs en fonction des données.
Ce dernier point vous sera mieux expliqué par nicO qui développe en ce moment ces idées.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par thecat . Évalué à 7.
Premier point : Le minimalisme du code.
Ton argument, qu'un nombre minimalmiste de primitive est necessaire pour réaliser l'ensemble des optimisations, est (plutot) faux.
Si le langage donnait, directement dans ces primitives, la possibilité de définir une structure complexe (arborescente par ex.) avec des traitement dessu (un tri), le compilo aurrait la charge d'optimiser au mieux cette 'primitive' (qui ne semble pas minimale pourtant).
Bon ok, ajouter des primitives devient trés lourd a gérer au niveau compilo ...
Les gros avantages d'un minima de primitive sont a mon sens:
* La plus grande facilité d'implémenter un compilo "complet".
* La possibilité (future?) de prouver ces primitives de manière plus simple et plus complète; et ainsi par extension prouver des programees plus grand n'utilisant que ce jeux restreint d'instruction.
Second point : La suppression de la liaison dynamique
Les vft ont beaucoup été critiquée mais surtout a cause de leurs gestion catastrophique de l'héritage multiple (en héritage simple cette technique est trés efficace). En héritage multiple, il est necessaire d'introduire un décalage (offset) supplémentaire qui plombe les performances.
D'autres solutions ont biens étaient testé avant SmartEiffeil/Lissac:
* L'approche "SmallTalk" avec (pour faire simple) une recherche bourrin de la méthode récursivement dans les parents puis gestion d'un "cache de résolution" qui stocke qu'elle methode est appelé pour quel message: résultat le premier appel est plutot lent mais ensuite on accede directement à la bonne méthode.
* La méthode dite de "coloration": C'est plus compliqué à expliquer, mais en gros avec cette technique on peut réaliser une sorte de vft à simple indirection, mème en héritage multiple. De plus il serrait possible de repousser ce calcul au moment du link.
J'avait fait un test de cette technique en détournant le compilo SmartEiffel (seulement pour l'appel de procédures et sans paramètres, c'etait pour des tests ;-) ) et mes résultat sur mon archi d'alors (AMD K6-2 500) était plutot bon pour mon implémentation super-bourrine-et-rapide: temps comparable a l'implémentation "normale" de SmartEiffel. (ni plus lent, ni plus rapide).
Le gros problème de cette solution c'est qu'il n'y a jamais eu d'implémentation sur un compilo "complet" et "diffusé".
[Pour plus dinfos, voir les publications ici: http://www.lirmm.fr/~ducour/ C'est pas évident a comprendre, ce type fait parti des "aliens" de l'informatique.]
Troisième point : L'analyse de flot
Je suis trés critique vis-a-vis de ce point. Je suis complètement sûr qu'il est necessaire mais pas dans son implémentation actuelle.
Il manque, à mon sens, une "sauvegarde" optimisé des analyses précédentes. SmartEiffel à des performances pitoyables sur mon PC car il réanalyse la classe STRING a chaque compilation, ce n'est pas "gérable" comme tu le dit pour des programes plus "ample".
De plus cette technique est un frein a un chargement dynamique de code (librairies, plugin ...) et c'est inacceptable "de nos jours".
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
D'ailleur au final votre benchmark MPEG2 le prouve, LISAAC est légèrement plus lent.
Pour aller plus vite que le C, faut commencer par le "sqeezer", c'est-à-dire produire directement du code machine, sinon Lisaac sera toujours limité aux contraintes sémantiques imposées par le C, contraintes qui empêche certaines optimisations possible dans d'autres langages.
Premier point : Le minimalisme du code.
Pas toujours vrai. Imposer des constructions de boucle ou de tableau dans le langage avec une sémantique précise permet au compilateur de faire des hypothèses valides supplémentaire. En fait la plupart des constructions qui sont intégrées au langage permettent au langage de faire des hypothèses valides et donc des optimisations supplémentaires.
Second point : La suppression de la liaison dynamique
Je veux bien moi, mais bon c'est plus un problème des langages objets que du C qui est ici le sujet :)
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
Eh bé :)
Maintenant dans la série "comment...", "Comment faire un langage qui remplace les langages objets actuels ?"
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
- Se focaliser sur la productivité et l'agréable.
Pour cela, il faut faire à la place du programmeur tout ce qui est trop techniques et lui fait perdre du temps sur des détails qui n'ont pas grand chose à voir avec l'objectif du programmeur : faire un programme qui répond à un besoin et des objectifs.
Pour cela :
- gérer la mémoire pour éviter toutes fuites mémoires et autres erreurs grossières d'accès mémoires
- proposer des types "primitifs" en "standard" dans la grammaire du langage (entier, flottant, chaîne de caractère, etc.) et des constructions "standards" (conditionnel, boucle) sans autre alternative : c'est une façon d'imposer un style de rédaction et d'écriture d'algorithme, avec comme objectif : se faire comprendre des autres programmeurs, et donc gagner du temps en maintenance, en relecture, en test, etc. Bref, avoir un dictionnaire de référence pour que tout le monde parle la même langue et se comprenne. Rien de plus frustrant de tomber sur des macros imbittable en C++, ou des types string personnalisés
- proposer un grand nombre de bibliothèque en "standard" implémentant les problèmes les plus courant. Ceci toujours dans la même idée d'éviter que chacun réinvente une roue au comportement pas forcement identique à celle du collègue programmeur. On retrouvera bien entendu dans ces bibliothèques l'accès au système de fichier mais aussi tout ce qui touche aux "communications" comme un mécanisme d'appel d'objet/procédure distant, des implémentations de standards courants comme XML, HTTP et les sockets, toujours dans le but de "standardiser" les moyens de communications entre application et donc éviter de se prendre le "choux" à faire communiquer 2 briques logiciels qui utilisent des implémentations différentes (et jamais parfaites) parfois de protocoles identiques.
On retrouvera également dans ces bibliothèques des types "standards" comme les collections ou les types exprimants le temps, toujours dans cet objectif d'avoir une représentation commune des structures les plus courantes, et ainsi grandement simplifier la réutilisation de code existant.
De la même manière on retrouvera des mécanismes de persistances (BDD, sérialisation automatique, etc.).
- la gestion de version : une brique logicielle évolue, et pour être réutilisée dans un cadre précis, il faut savoir identifier une version précise de la brique, mais aussi des types qui la compose voir des fonctions.
- un mécanisme de reflexion pour faciliter la programmation à un niveau supérieur mais aussi faciliter l'analyse et la vérification de code.
- une sécurisation de l'espace mémoire avec un mécanisme d'isolation empêchant un processus de faire s'écrouler d'autres processus.
Reste un dernier point qui n'est pas "obligatoire" :
- poser une couche d'abstraction vis-à-vis du matériel. C'est un gros avantage, mais il peut limiter la construction de logiciels utilisation du matériel justement :)
J'oublies sûrement plein de trucs, mais si un langage veut s'imposer il doit "réfléchir" à tous ces points et ne pas s'occuper uniquement de sa grammaire mais de son environnement complet : environnement d'exécution et bibliothèques proposées en standard.
Un point important à considérer également :
- faciliter la programmation multi-thread pour la rendre intuitive au programmeur.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . Évalué à 3.
Un langage de plus haut niveau que le C a un avantage énorme pour l'optimisation: le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C. Par exemple, un compilateur de C a peu d'informations sur une boucle for quand le critère d'arrêt n'est pas une constante, et donc il lui est difficile de savoir comment dérouler la boucle de manière optimale. Un compilateur pour un langage de plus haut niveau pourrait avoir des informations supplémentaires sur la boucle, par exemple le fait qu'elle contient toujours un nombre pair d'itérations, etc. Dans ce cas, l'optimisation est souvent plus simple.
L'exemple que j'ai pris est un peu simpliste: on peut se dire que ce genre de cas peut aussi être géré en C par le développeur. Dans des cas plus compliqués, déléguer la tâche au compilateur est très appréciable. Comme les développeurs ont toujours une contrainte de temps, moins ils passent de temps à produire du code illisible mais optimisé et mieux c'est.
Pour prendre un autre exemple, les templates du C++ sont à la fois un outil qui aide à coder plus vite et un outil qui aide à optimiser. Si ça ne servait qu'à coder plus vite (au détriment de la vitesse d'exécution), l'intérêt serait beaucoup plus limité. Pourquoi est-ce que ça optimise aussi la vitesse d'exécution ? Parce que le traitement par le moteur de templates est effectué à la compilation, pas à l'exécution.
Quand le langage ne permet pas d'exprimer l'information nécessaire, le compilateur ne peut pas effectuer le travail pendant l'étape de compilation, et donc tu as le choix entre faire le travail toi même ou bien utiliser le langage pour faire le travail pendant l'exécution. Faire le travail soi même, c'est souvent long et compliqué, et faire le travail à l'exécution, ça implique souvent une perte de performance. Donc plus un langage donne d'informations au compilateur et plus il est à même de produire du code rapide si le compilateur est malin.
Dernier exemple, l'héritage: en C, tu ne peux pas exprimer l'héritage dans le langage, mais tu peux le simuler avec des pointeurs de fonctions et des casts bien placés. Par contre, le compilateur n'a aucune notion d'héritage, et donc l'héritage est forcément géré en partie pendant l'exécution. Ça veut dire que tu vas avoir des pointeurs de fonction dans tes objets, et que pour appeler une méthode d'objet, tu vas devoir accéder au pointeur de la fonction correspondante. Ça veut dire entre autres que tu ne peux pas inliner le code de ces méthodes. Ça implique une perte de performances.
Si le compilateur du langage L connaît l'héritage, alors il peut produire du code C qui évite dans la plupart des cas l'usage de pointeurs de fonctions pour simuler l'héritage, donc du code C qui sera plus facile à optimiser pour le compilateur C, et qui au final sera plus rapide. Faire la même chose pour le programmeur est théoriquement possible, mais en pratique irréalisable car trop long et trop compliqué.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est exactement ce que j'expliquais plus bas dans mon commentaire : les instructions du langages ont un sens particulier et permettent au compilateur de langages de haut niveau de procéder à des optimisations particulières. C'est pour ca que je disais avoir une grammaire ultra-simple sans les constructions minimum n'est pas vraiment aidant question optimisation, au contraire, ces instructions permettent bien plus d'optimisation. Donc on est bien d'accord :)
Moi je disais juste que c'est dommage de chercher à faire un langage de haut niveau puissant question optimisation si c'est pour produire du C au final : on va comme tu dis perdre un grand nombre de possibilités d'optimisation sur le code final, vu qu'on sera limité au sens du langage C.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . Évalué à 6.
Dans le cas particulier où la grammaire du langage L ne permet pas d'exprimer des concepts de plus haut niveau que le langage C, on est d'accord. Mais en règle générale, on n'est pas d'accord: je prétend qu'on peut faire un langage de haut niveau qui compile vers du C et qui tourne plus vite que code C saisi par un humain.
Je disais le contraire... Si tu avais raison, ça ne servirait à rien (au niveau des optimisations) de coder dans un langage de haut niveau puisque de toutes façons au final on se retrouve avec du code machine qui manipule des bits.
Je ne peux pas tellement trouver d'exemples plus explicites que ceux de mon précédent message (d'autant plus que ce n'est pas mon domaine). L'idée générale, si on a la chaîne de compilation suivante:
[code en L] --(étape 1)--> [code en C] --(étape 2)--> [code en M] -> (étape 3: exécution)
Admettons qu'on a à faire un programme P, et qu'on le donne à un développeur, qui produit un programme PL en langage L, et à un autre développeur qui produit un programme PC en langage C. Appelons PLC le programme PL compilé vers du C.
Si le langage L permet de manipuler des concepts de plus haut niveau que le langage C, alors le compilateur L peut essayer durant l'étape 1 de faire des optimisations sur PL qui font que PLC compilé en M produira du code plus rapide que PC compilé en M.
Je reprend l'exemple de l'héritage. Soit L un langage objet, et soit c un objet de classe C qui hérite de B qui hérite de A. Quand j'appelle c.toto(), on doit chercher si C implémente toto(), sinon B, sinon A. Une fois qu'on a trouvé toto(), on peut décider soit de faire un appel de fonction, soit d'inliner la fonction si c'est plus efficace.
Si on peut toujours résoudre le problème de trouver la fonction à appeler à l'étape 1, alors on peut produire du code C avec des appels de fonction directs ou bien du code inliné.
Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
(Disclaimer: un programmeur peut théoriquement faire le boulot du compilateur L à l'étape 1 et produire lui-même à la main le code C correspondant. De la même manière qu'un programmeur peut théoriquement recoder n'importe quoi entièrement en assembleur. C'est simplement trop compliqué et trop long à faire dans la vraie vie.)
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 2.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . Évalué à 3.
Ça ne change rien à l'argument principal, bien sûr, le préprocesseur étant de toutes façons un compilateur pour un langage qui produit du C :)
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est vrai que c'est une optimisation de très bas niveau.
On est en train de réfléchir à des optimisations plsu haut niveau, comme le déroulement et la paraléllisation de grosses boucles. Du genre transformer
http://www.haypocalc.com/wiki/Image:Graphe_s%C3%A9quentiel.j(...)
en
http://www.haypocalc.com/wiki/Image:Graphe_paral.jpg
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Arrête de me prendre pour un con comme tu dis si bien. Je comprend tout à fait l'intérêt d'un langage de haut niveau, c'est d'ailleur pour ca que j'évite dès que possible de code en C. Mais tu réponds toujours pas à ma question : pourquoi ne cherchez vous pas à "zapper" le C pour produire vous même du code machine, vous autorisant encore plus d'optimisations et vous aidant à "dépasser" les perfs du C ?
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 2.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Gcc a été conçu pour cela, son architecture est prête pour acceuillir de nouvaux langages sans passer par le C. Je sais pas si c'est faisable et si vous avez déjà envisagez cela mais ca mérite d'être regardé.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 2.
Plus précisément ça le gonfle, il estime (et je suis d'accord) qu'il y a des choses plus intéressantes à faire.
Je te rappel qu'il est chercheur et t'informes qu'il est plus intéressé par des problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
C'est pas une mauvaise idée en soit du moment qu'elle soit optionnelle.
Cela dit, on ferait beaucoup mieux de travailler sur l'optimisation de la sémantique que de pinailler sur des optimisation en assembleur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 2.
les problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
Je ne connais que la méthode B dans le domaine, mais j'ai un peu l'impression que le B est à des années lumières de Lisaac (au niveau de la grammaire)... Vous avez tout de même les mêmes objectifs ?
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 4.
C'est dans la lignée des travaux de Jean-Christophe Filliatre
http://why.lri.fr/index.fr.html
Exemple : http://why.lri.fr/examples/sqrt/sqrt.mlw.html
Why génère une preuve pour COQ qui se charge dé montrer que l'algo est valide.
Le problème est que COQ n'est pas incrémental.
Il y a plusieurs défis :
1/ Concevoir un générateur de preuve à partir des contrats
2/ Concevoir un système qui vérifie la cohérence des contrats, ie. qu'il n'y ait pas incomplétude.
3/ Prouver le compilateur ou au moins une bonne partie
donc
4/Prouver le langage (sa grammaire)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par outs . Évalué à 3.
Mmmh infaisable.
Enfin générer le modèle B à partir du code et des contrats associé ce n'est pas un probleme : le B étant très expressif.
Mais tu va te retrouver avec un modèle beaucoup trop compliqué et qui n'utilise pas le raffinement. Le prouveur automatique n'aura aucune chance de trouver les preuves.
Hors l'interet principal de B est de distribuer la complexité des preuves en créant plusieurs modèle qui se raffinent les un les autres. Mais écrire ces raffinement demande une réflexion humaine. Pas possible de la faire faire par le compilo.
Plus généralement ca fait depuis 1960-70 qu'il existe des méthodes pour certifier les programmes. Hors cela n'a pas révolutionné l'informatique. Pourquoi ? car tous ces problèmes sont indécidables. Dans certain (model checking) on peut se ramener a un problème NP-complet, mais on est quand même coincé par la complexitée du travail. Il ne faut pas s'attaquer a ca avec naiveté, sans vouloir te vexer.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Vivi (site web personnel) . Évalué à 2.
ouais enfin pas tant que ça.
Ça existe les bibliothèques/framework de génération de code pour compilateurs. Vous avez regardé ?
C-- http://www.cminusminus.org/
LLVM http://llvm.org/
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . Évalué à 5.
Je ne sais pas quelle est la version de Lisaac à ce jour, mais ça n'a pas l'air d'être "fini". Ça n'aurait aucun sens, pendant qu'on fait de la recherche dessus, de perdre son temps à supporter plusieurs architectures de manière optimale. En compilant vers du C, tu hérites déjà de la compatibilité avec toutes les plateformes de GCC.
En plus, le C étant de plus haut niveau que le langage machine, c'est probablement plus facile à optimiser. Et donc si ça peut permettre de s'intéresser aux concepts plutôt qu'aux détails d'implémentation, c'est un choix justifié.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Philip Marlowe . Évalué à 3.
Même si ce que tu racontes était vrai, si le programmeur met 10, 100, 1000 fois plus de temps pour faire la même chose... En plus le fonctionnement des optimisations mises en places par le compilateur peuvent être garanties dans leur fonctionnement, et même parfois carrément être prouvées. Ca engendrera des bugs de pus haut niveau...
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau, et postulant de ce fait au remplacement du C ou le concurrençant, mais permettant une écriture à partir de concepts plus élaborés. Ce n'est pas un langage alternatif aux langages du genre Python, C#, Java ou Eiffel. Ou alors là, c'est moi qui ai mal compris.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . Évalué à 2.
La notation de Lisaac est fonction de sa spécification (on passe bientôt à la 0.2), effectivement on pourra mettre plein de features haut niveau dans les spécifs 0.3, 0.4, etc...
Voir https://linuxfr.org/~Montaigne/20582.html pour des exemples.
Mais effectivement, je pense que Lisaac sera un langage en grande partie destiné à l'embarqué, dans l'industrie, là ou ses performances seont vraiment utile. Parce que quand on voit la lenteur de Java et sa grande popularité on comprend que c'est un paramètre totalement secondaire.
Et puis pour faire marcher Lisaac dans l'info de gestion, il faut de la lib, des framework à la J2EE, des serveurs d'applications, etc...
Donc oui l'intérêt, est de remplacer C, pour C++, Java, on verra plus tard, si c'est possible.
Pour en revenir aux optims, je plussoie ce que tu répond à TImaniac et j'ajouterai que ça permet de l'avoir sans se tapper un code illisible puisque c'est le compilateur qui se tappe les réécriture fastidieuse, chiante et illisibles.
La devise qui prévaut à la conception du compilateur est :
"Ne laissez jamais un humain faire le travail d'un programme"
;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Philip Marlowe . Évalué à 3.
Ca me rappelle la signature que j'utilisais avant, qui me venait de réflexions que je me faisais en tant que programmeur Eiffel devant les discussions acharmées de tenants de Java, C# ou C++, surtout quand ils abordaient les notions de virtual : "Se prendre pour un compilateur, c'est un trouble du comportement".
Sinon je saisis l'occasion de te remercier et de t'applaudir de faire connaître le travail de Benoît Sonntag ainsi que pour les essais que tu as écrits autour des concepts de Lisaac,qui donnent lieu à de fructueuses réflexions. Je regrette seulement de ne pas avoir plus de temps à consacrer aux travaux pratiques autour de ça. Merci aussi à nicO, pour les mêmes raisons.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . Évalué à 1.
j'ai dis "théoriquement". C'est évident que dans la pratique le programmeur n'écrira pas tout ca. Mais je constate qu'au final le langage n'apporte pas l'intérêt qu'il prétend avoir puisque dans leur unique bench le langage est légèrement plus lent que le C. Le langage et le compilateur semble sortir l'artillerie lourde question optimisation, mais j'ai l'impression que tout est perdu à cause de 2 choix :
- sortir du C plutôt que de sortir du code optimisé pour processeur.
- limiter le nombre de construction intégrées à la grammaire (et donc optimisables à souhait).
Enfin je pense que le premier choix peut évoluer. Par contre le 2ème j'ai beaucoup plus de mal. L'intérêt d'un langage de haut niveau, c'est d'exprimer des concepts d'une manière plus abstraite pour apporter un maximum d'informations (de "sens" comme dis plus haut) au compilateur pour qu'il fasse le travail le plus intelligent possible.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau
En fait j'ai vraiment du mal à voir ce que Lisaac apporte par rapport au C pour le code bas-niveau puisqu'on gagne rien en perf (d'après leur bench), donc je suppose qu'il peut aussi rivaliser avec les autres langages de haut nivaeu plus polyvalant. Visiblement tu me dis que non :) Ben je vois toujours pas l'intérêt de Lisaac du coup :)
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Yusei (Mastodon) . Évalué à 2.
Tant qu'on n'a pas créé une intelligence artificielle qui soit plus "intelligente" qu'un humain, "théoriquement", le programmeur peut toujours faire mieux que n'importe quel compilateur.
Il vaut mieux s'intéresser à ce que peut faire le programmeur "en un temps raisonnable", et pour définir le critère "raisonnable" je propose "qui ne nécessite pas plus de X% du temps consacré au développement".
[^] # Un peu de transparence
Posté par agmk . Évalué à 3.
C'est ici que j'ai pour la première fois entendu parler de Lisaac. Sans a-prioris, je me suis renseigné, j'ai lu certains pdf d'isaacos.loria.fr, etc... Je suis favorablement impressioné. Toutefois, certaines questions subsistent :
* Ça fait plusieurs mois qu'on parle de la libération du compilo, qui n'est pas libre (officiellement) par crainte de la copie des algos par MS^Wune grosse entreprise quelconque. En résumé (corrige-moi si je me trompe) : suite à une discussion avec RMS, il a été envisagé de brevetter aux USA. Bon, ça en est où précisément ? Une date est envisagée ? Que pense Benoit Sonntag de l'hypotétique libération ? Quel avenir voit-il pour ce qui doit-être son "bébé" ? Au final, qui décide, lui ou l'INRIA ?
* Sur certains PDF, j'ai remarqué que ST Microelectronics est/était assez impliqué dans le projet. Il me semblait même avoir lu dans un document qu'une vente était prévue (mais je ne retrouve plus le pdf en question). Cela concerne uniquement IsaacOS ou Lisaac également ? Est-ce toujours d'actualité ? Que pensent-ils d'une libération ? D'un brevet ?
* La libération de Lisaac est envisagée, et celle d'IsaacOS ? Je pense que serait un plus (mais certes pas le plus important). D'ailleurs d'après http://www.loria.fr/software/tous/logiciel?id=36 Isaac est libre, mais après lecture de la licence, ce n'est pas le cas (usage non commercial only, etc).
Si je pose ces questions, c'est parce que Lisaac me semble plus que prometteur. Mais je doute que dans le paysage actuel , un langage de plus sortant de nulle-part, sans entreprise ni communauté derrière, réussise à s'imposer (aussi révolutionnaire fût-il). AMHA une libération ne serait pas du luxe, avec la création d'un groupe d'utilisateurs motivés pour développer les outils/modules/libs nécessaires, si vous voulez avoir un jour une chance de percer.
[^] # Re: Un peu de transparence
Posté par Ontologia (site web personnel) . Évalué à 3.
C'est l'INRIA qui décide, je ne me permettrai pas de commenter leur décision, où ce que j'ai cru comprendre qu'ils pensent.
Je crois que Pierre Jarillon s'est exprimé là dessus plus haut.
Benoit pense (et je pense) qu'il faut breveter la techno centrale du compilateur, libérer le compilateur et autoriser tout ceux qui feront du libre avec.
De toutes façon, le fait que la librairie du code soit en Cecill implique qu'on est obligé de faire du libre avec, à moins de réécrire celle-ci (bonne chance).
L'INRIA se financera (je suis pour que la recherche française, quelque fois, essaye de gagner de l'argent à condition qu'on laisse les chercheurs tranquille quand il veulent faire du fondamental) sur la vente de licence propriétaire, et éventuellement sur des droits du brevets.
Mais surtout sur la (les) start-up créé autour de la technologie : il y aura de toutes façons besoin d'une expertise qui se vendra très cher.
* Sur certains PDF, j'ai remarqué que ST Microelectronics est/était assez impliqué dans le projet. Il me semblait même avoir lu dans un document qu'une vente était prévue (mais je ne retrouve plus le pdf en question). Cela concerne uniquement IsaacOS ou Lisaac également ? Est-ce toujours d'actualité ? Que pensent-ils d'une libération ? D'un brevet ?
Benoit a effectué sa post-doc à ST. Il y a développé certains bouts de codes qui ne seront donc pas libérés.
Cependant, cela ne concerne ni l'OS, ni le compilateur.
* La libération de Lisaac est envisagée, et celle d'IsaacOS ? Je pense que serait un plus (mais certes pas le plus important). D'ailleurs d'après http://www.loria.fr/software/tous/logiciel?id=36 Isaac est libre, mais après lecture de la licence, ce n'est pas le cas (usage non commercial only, etc).
La libération du compilateur Lisaac est à la discretion de l'INRIA, tu peux leur poser la question concernant ce point.
Benoit a reçu, jusqu'à nouvel ordre, l'autorisation de libérer IsaacOS.
Il travaille d'arache pied à finir la récriture intégrale du compilateur v0.2
Il s'occupera ensuite de nettoyer IsaacOS afin d'en faire une distribution "propre".
Quand à moi, je vais m'occuper de commenter un peu le code et de rédiger e la doc.
J'espère avoir fini début mai.
Si je pose ces questions, c'est parce que Lisaac me semble plus que prometteur. Mais je doute que dans le paysage actuel , un langage de plus sortant de nulle-part, sans entreprise ni communauté derrière, réussise à s'imposer (aussi révolutionnaire fût-il). AMHA une libération ne serait pas du luxe, avec la création d'un groupe d'utilisateurs motivés pour développer les outils/modules/libs nécessaires, si vous voulez avoir un jour une chance de percer.
Je suis entièrement d'accord avec toi : Seul quelques entreprises ont à l'heure actuelle la capacité de vendre un langage propriétaire : Microsoft, éventuellement Sun, Borland, bien que j'y crois guère pour ces dernier.
Les coûts d'évangélisation sont énormes (il y a un marketeux pour 5 développeur à Microsoft) et le libre constitue un marketing gratuit que l'INRIA ne peut pas payer. De toutes façon cette organisation n'a pas les structures nécessaires.
Espérer diffuser Lisaac en tant que langage et compilateur non libre constitue de l'irréalisme totale et à mon sens une méconnaissance du marché de l'informatique qui n'a plus rien à voir avec ce qu'il était il y a encore 3 ans.
Le marché est dorénavent séparé entre deux acteurs : Microsoft et ses féaux, et le monde du Libre. Tout le monde, chinois compris, suit et subit cette situation.
Si IBM et consort se sont rangés derrière le libre, ce n'est pas par conversion à l'idéal communiste, mais par réalisme stratégique : ils ont compris que c'était leur seul moyen de s'en sortir et que la mutualisation des coûts de développement, les économies énormes en coûts de marketing sont une force très difficile à combattre, on commence à voir les fruits que cela rapporte.
De toutes façons, vendre un compilateur à l'heure actuel n'est plus du tout adapté au marché, ça l'était peut être encore il y a 10 ans, mais aujourd'hui, c'est une stratégie vouée à l'échec.
Par contre, vendre du service autour, du support pour les SSII, du dev de libs, de framework est un modèle qui pourrait être très rémunérateur.
J'espère qu'ils sauront le comprendre. Je pense qu'ils sont clairvoyants, il le comprendront donc, si ce n'est déjà fait.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu de transparence
Posté par vieuxshell (site web personnel) . Évalué à 6.
C'est bien planqué, au milieu d'un pavé, si on lit un peu vite on ne le voit même pas et pourtant il est là, il n'attend que toi avec ses longs poils et son gourdin pour t'assomer !
# Isaac ou Lisaac
Posté par moramarth . Évalué à -2.
Toi, t'as perdu en crédibilité pour parler dudit langage...
[^] # Re: Isaac ou Lisaac
Posté par moramarth . Évalué à 5.
C'est pas possible d'avoir l'info sous les yeux et de ne pas la voir.
J'ai plus qu'à me suicider...
# Optimiser un langage minimaliste cai mieux..
Posté par Ontologia (site web personnel) . Évalué à 2.
J'ai demandé au maîître de m'expliquer pourquoi ce point de vue est plutôt faux.
Elle est fausse pour des primitives de bas niveau du genre if, while, traitement des nombres, etc...
Elle peut être vrai pour des primitives très haut niveau du genre "quel que soit x dans l'ensemble".
C'est faux pour les if, while car il arrive souvent que dans le code il y ait des if caché, de s while caché, etc...
Une résolution dynamique classique, peut, par envoi de message être un if caché.
Il est donc beaucoup plus intelligent de les rendre équivalent, et de les optimiser de la même façon.
Lorsqu'on optimise le while comme une récurcivité terminale, on optimise toutes les récurcivités terminales, on repère d'autres structures similaires qui n'auraient pas été vu.
Il faut bien voir que le compilateur Lisaac passe un certains temps à inliner tout ce qui est possible d'inliner, de par son algorithme d'analyse de flot, donc on retombe facilement sur des if, des while cachés, etc...
"Les optimisations ne sont plus liées à une syntaxe, mais à la sémantique du code...
C'est justement bien plus profond !"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par lasher . Évalué à 3.
Je ne sais pas si c'est une spécialité de l'INRIA ou bien de la recherche dans les langages de programmation en général, mais j'ai l'impression que pas mal de langages issus de labos de recherche « remontent » les traitements au niveau sémantique ... Je pense entre autres à CDuce (http://www.cduce.org), un langage fonctionnel et généraliste à la ML qui a été créé pour traiter efficacement les transformations de documents XML. Là aussi, on a passé certains pans du langage au niveau sémantique (notamment le sous-typage qui est classiquement utilisé au niveau syntaxique, est « remonté » au niveau sémantique - et c'est le compilateur qui trouve tout seul comme un grand quel est le type d'une fonction donnée).
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est simplement qu'on sans doute arrivé au bout des techniques de compilation syntaxiques.
De plus on a maintenant des machines sufisament pourvue en mémoire pour faire de l'analyse de flot.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Thomas Douillard . Évalué à 5.
C'est nécessaire pour pouvoir faire des raisonnements éléborés d'abstraire les structures. Plus on se rapproche du niveau sémantique, et plus il est facile de faire de déductions, et donc de faire des déductions efficace. Optimiser au niveau de l'algorithme et non plus de la boucle. Une idée qui m'est venu comme ça : un langage ou le compilo choisit lui même la structure de donnée adaptée pour stocker une collection d'objet, en fonction de ce qu'on en fait : optimisation des accès si il y en a beaucoup, ... Au lieu de préciser 'vecteur', 'liste', 'arbre de recherche', on dit 'collection de' et on laisse le compilo se débrouiller en fonction de l'utilisation qu'on en fait.
Puisqu'on parle de langage, c'est le genre de chose nécessaire par exemple en traitement du langage, par exemple pour faire des traductions de textes. La technique "de base" c'est de faire du mot à mot. Pour faire plus efficace, il faut extraire les structures, grammaticale, etc. Pour faire plus efficace, ou plus fidèle, il faut carrément essayer de comprendre le sens du message avant de le retranscrire.
Dans le même genre, niveau langage, certains pensent (genre MS) qu'on va de plus en plus vers des langages spécialisés, dans lequel le spécialiste du domaine (plus forcément un informaticien spécialiste) peut exprimer ce qu'il veut, et laisser faire le boulot à des algos spécialisé, le travail de l'informaticien ce recentrant sur la conception des langages et des algos spécialisés.
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Ontologia (site web personnel) . Évalué à 2.
Alors ça c'est dingue !!! C'est précisément l'idée qu'on a eu avec Benoit l'autre jour. Je crois que c'est parti d'une remarque de nicO au SL2006 et on est arrivé à la conlusion qu'il fallait faire un type LIST général qui hérite dynamiquement de toutes les collections existantes (FIXED_ARRAY, LINKED_LIST, etc...). On ajoute un mot clé pour que le codeur puisse dire au compilateur de choisir lui même le parent en fonction de ce qu'il y a dans le code.
Par analyse de flot, le compilateur calcule le temps d'exécution dans le pire des cas de chaque branche et choisi la meilleur.
Dans le même genre, niveau langage, certains pensent (genre MS) qu'on va de plus en plus vers des langages spécialisés, dans lequel le spécialiste du domaine (plus forcément un informaticien spécialiste) peut exprimer ce qu'il veut, et laisser faire le boulot à des algos spécialisé, le travail de l'informaticien ce recentrant sur la conception des langages et des algos spécialisés.
Je ne savais pas qu'MS en arrivait là, mais j'en arrive aussi à la même conclusion. Suite à mes réflexions (voir mes articles), j'en arrive qu'il faut (liste non exhaustive):
- Un langage de manipulation de données ensembliste, genre Cduce, mais en plus haut et orienté langage naturel avec des idées de prolog.
- Des fonctionnalitées agent
- Du pattern matching, encore du pattern matching !
- La possibilité de définir une sémantique grammaticalisé avec les règles associées facilement.
C'est encore très flou, mais le concept "un paradigme pour tout faire", j'y crois plus.
Il faut que les langages ne se contentent plus de définir des graphes de code et il faut arrêter avec les grammaires dures (genre il manque un ';' donc ça compile pas).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Ontologia (site web personnel) . Évalué à 2.
Je travaille sur un concept déclaratif s'inspirant de la méta-programmation.
Ca va plus loin que la définition d'un mini langage : c'est de la reconnaissance de forme.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par vieuxshell (site web personnel) . Évalué à 1.
Tiens, ca m'interpelle ca !
On m'a tjrs dit dans mes cours d'algo "faisez pas de la récursivité terminale, une boucle est largement plus performante".
Et là je vois que l'inverse est fait par votre compilo... alors qu'est ce que j'ai pas compris:
* mes cours ?
ou
* ta phrase ?
[^] # Re: Optimiser un langage minimaliste cai mieux..
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est un pattern matching : dès qu'il en détecte une il la dérécurcive.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# qques questions sur Lissac et... Ruby, Java, Caml...
Posté par ddevito (site web personnel) . Évalué à 3.
(1) A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
Est-ce que qqu'un a comparé ces deux langages ?
(2) les optimisations mises en oeuvre pour la compilation de Lissac pourraient-elles être mises en oeuvre pour d'autres langages comme Java ?
Par exemple, un certain nombre d'optimisations sont en cours d'élaboration pour détecter si tel ou tel objet a un scope qui peut lui permettre d'être allouer dans la pile au lieu d'être alloué dans le tas. Voir http://www-128.ibm.com/developerworks/java/library/j-jtp1018(...)
Serait-il possible de mettre en oeuvre les optimisations de Lissac pour d'autres langages ?
(3) Ruby connait un grand enthousiasme en ce moment via (a) le framework Ruby On Rails pour la programmation web et (b) comme candidat pour fabriquer facilement des DSL (via la métaprogrammation ?).
Si Lissac, via la compilation, enfonce Ruby (dont le coté dynamique a l'air d'avoir un cout), et supporte des fonctionnalités analogues à celles de Ruby, Lissac pourrait aussi être positionné sur les mêmes créneaux (a) et (b).
Cela a-t-il été envisagé ?
(4) Lissac supporte-il le polymorphisme à la Caml ?
par exemple, en Caml, on peut écrire une fonction telle que (j'écris de mémoire) :
let rec size list = match list with
[] -> 0
| head::tail -> (size tail) + 1
et cette fonction est typé comme ['a] -> int : elle peut opérer sur des listes de n'importe quoi.
Je trouve qu'avec l'inférence de type cela donne un fort avantage par rapport à Java. En Java, sans inférence de type, en utilisant des types paramétrés, on peut arriver à écrire qque chose comme :
public SortedMap<ArrayList<MBeanServerInvocationHandler>> getFoo() {
SortedMap<ArrayList<MBeanServerInvocationHandler>> foo =
new SortedMap<ArrayList<MBeanServerInvocationHandler>>();
foo.doSomething();
return foo;
}
Beurk, quelle horreur.
Voir http://www.cabochon.com/~stevey/sokoban/docs/article-java.ht(...) pour une critique de Java.
(5) en Caml, on peut aussi faire du pattern matching, une sorte de switch, comme en C, mais amélioré car pouvant porter sur des types de données qui ne sont pas limités au type 'int'.
Est-ce possible via Lissac ?
Merci de vos éclaircissements.
Dominique
http://www.jroller.com/page/dmdevito
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 2.
L'inférence de type c'est une autre paire de manche. Écrire un moteur d'inférence est très complexe et pose des problèmes dans le cadre des langages objet, bien que cela soit dans une certaine mesure possible (cf implémentation objet de Ocaml). Initialement l'inférience est basé sur le typage automatique des lambda-calcul (fondement de la prog fonctionnelle), comme Lissac est objet et non pas fonctionnel il faut réétudier l'inférience dans ce cas.
(5) Le pattern matching est en fait une application des concepts de réécriture. Très souvent ajouté dans les langagues fonctionnels pour les enrichir. Le problème est qu'en objet on doit utiliser le polymorphisme pour éviter les switch entre les cas. Les branchement par cas sont à éviter en prog objet pour améliorer la capacitée du code à évoluer (pas besoin de modifier les switch suffit d'hériter une classe à la place). Il y a clairement un clash entre les deux paradigmes. Cela dit il y a peut être matière à creuser. Demande à ontologia il adore spéculer :))
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Ontologia (site web personnel) . Évalué à 2.
(1) A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
Est-ce que qqu'un a comparé ces deux langages ?
Pas à ma connaissance. Personnelement, je ne connais rien à ce langage.
Serait-il possible de mettre en oeuvre les optimisations de Lissac pour d'autres langages ?
Je m'étonne qu'il y ait fallu quasiment une semaine pour que quelqu'un pense enfin à poser la question.
Je pense que, sauf les fonctionalitées comme la réflexivité, etc... on pourrait tout à fait utiliser le compilateur Lisaac pour compiler du Java, du C++ (beuurk), d'autres.
Il faudrai pour cela pas mal retravailler l'objet PARSER pour lui faire bouffer la syntaxe.
J'ai un peu peur duand à la gestion des mots clé, qui sont énormes dans ces langages.
Ca serait un gros parser, mais ça passerai.
Ce qui serait marrant, c'est du Java aussi rapide que du C....
(3) Ruby connait un grand enthousiasme en ce moment via (a) le framework Ruby On Rails pour la programmation web et (b) comme candidat pour fabriquer facilement des DSL (via la métaprogrammation ?).
Si Lissac, via la compilation, enfonce Ruby (dont le coté dynamique a l'air d'avoir un cout), et supporte des fonctionnalités analogues à celles de Ruby, Lissac pourrait aussi être positionné sur les mêmes créneaux (a) et (b).
Cela a-t-il été envisagé ?
Peut être pas sous cet angle, et que par moi (les délires sur les langages du futur, c'est ma spécialité)
Mais je v étudier la question, le titre "Creating a weblog in 15 minutes" est assez bandant.
Si t'as des idées là dessus, tu es le bienvenu, les discussions sur les spécifications 0.3 et surtout 0.4 de Lisaac sont ouvertes (la 0.2 est en train d'être implémentée).
Fais moi signe ;)
(4) Lissac supporte-il le polymorphisme à la Caml ?
par exemple, en Caml, on peut écrire une fonction telle que (j'écris de mémoire) :
let rec size list = match list with
[] -> 0
| head::tail -> (size tail) + 1
et cette fonction est typé comme ['a] -> int : elle peut opérer sur des listes de n'importe quoi.
A vue de nez, ça donnerai
- size lst :LINKED_LIST[E] : INTEGER <-
(
+ result : INTEGER;
+ tmp : LINKED_LIST[E];
(lst.count <1).if {result :=0} else
{
lst.remove_first;
result := (size lst) +1;
}
result
);
Bon là je me rend compte, que j'en ai marre, je veux une fonction tail et une fonction head dans les collections.
- size lst :LINKED_LIST[E] : INTEGER <-
(
+ result : INTEGER;
+ tmp : LINKED_LIST[E];
(lst.count <1).if { result :=0;
} else { result := (size lst.tail) +1; };
result
);
C'est mieux
Ya encore du progrès à faire.
La futur version 0.2 qui sort bientôt te permettra de rendre plusieurs valeurs, comme caml, donc de faire du vrai fonctionnel.
public SortedMap<ArrayList<MBeanServerInvocationHandler>> getFoo() {
SortedMap<ArrayList<MBeanServerInvocationHandler>> foo =
new SortedMap<ArrayList<MBeanServerInvocationHandler>>();
foo.doSomething();
return foo;
}
Oui effectivement...
Section PUBLIC
- get_foo lst : SORTED_MAP[ARRAY[MBEAN] <-
(
+ foo : SORTED_MAP[ARRAY[MBEAN] := SORTED_MAP[ARRAY[MBEAN].create;
foo.do_something;
foo
}
(5) en Caml, on peut aussi faire du pattern matching, une sorte de switch, comme en C, mais amélioré car pouvant porter sur des types de données qui ne sont pas limités au type 'int'.
Est-ce possible via Lissac ?
Merci de vos éclaircissements.
Non, mais moi j'aimerai bien.
Alors comme il se trouve que Xavier Leroy et Benoit Sonntag se connaissent, j'aimerai bien que ce soit implémenté dans le compilo.
Ca va venir, je pense.
Cela dit, je pense qu'il est implémentable dans la lib un truc similaire mais un moins puissant.
Faudrait y réfléchir.
Tu me donnes une idée, merci :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Ontologia (site web personnel) . Évalué à 2.
- size noeud:LINK[E] :INTEGER <-
( + result:INTEGER;
(noeud = NULL).if {
result := 0;
} else {
result := 1 + size (noeud.next);
};
result
);
Mais de toutes façons ça sert à rien, car il y a l'attribut count dans les listes...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par reno . Évalué à 3.
A première vue, du point de vue la syntaxe et du fait que tout à l'air objet pour Ruby et Lissac, Lissac me fait penser à Ruby
<<
Tu es allé cherché la ressemblance ou??
C'est amusant, cela m'a fait exactement l'effet opposé coté syntaxe: Ruby a une syntaxe riche destiné à simplifier la vie au programmeur et Lissac a une syntaxe destiné à simplifier la vie au compilateur.
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par ddevito (site web personnel) . Évalué à 2.
Je n'ai jeté qu'un coup d'oeil rapide à Ruby et Lisaac. Je ne connais pas en profondeur Ruby . A première vue, la syntaxe de ces 2 langages m'a semblé non-standard, unusuelle pour les yeux de programmeurs Java, et ex-programmeur Caml.
Mais je me suis peut être trompé sur cette ressemblance...
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Ontologia (site web personnel) . Évalué à 2.
Non là tu ne peux pas dire ça.
La grammaire est certes minimaliste. Connaissant benoit, je dirai que c'est une approche philosophique qu'il affectionne (et moi qui ne le suis pas du tout, je me rend compte qu'en fait c'est mieux : les axiomatiques trop grosses, c'est jamais bon).
La grammaire de Lisaac a été très pensée, et on s'y habitue assez vite. De fait on l'apprend très vite (quelques heures), c'est quelques choses que j'apprécie beaucoup.
Moi aussi au début, j'ai gueulé contre les types en majuscules, parce que Shift à chaque fois, c'est lourd.
Je crois que la solution, c'est un emcas ou autre qui te le met automatiquement en majuscule.
Moi aussi au début j'ai gueulé contre l'interdiction de majuscules dans les variables, qui me permettaient de faire des phrases dans mes variables (je fais souvent des variables avec des noms interminables).
J'ai reprogrammé en Java, et j'ai passé un temps fou zsur des erreurs du type "ah erde, là ya un majuscule pour la 2ème lettre" et je me suis rendu compte que c'est galère.
Par contre j'adore les mots clés. Ca fait des phrases.
Comme il parait que j'aime spéculer ;o)) L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par reno . Évalué à 4.
> L'avenir des langages est pour moi vers des langages de spécifications en langages naturels.
Bof, on avait des langages de dev en 'language naturel' (COBOL) et on en est revenu.
Et remplacer des langages de dev, par des langage de spec n'apporte pas grand chose: au lieu d'avoir des erreurs de codage, on a des erreurs de spec, le gain n'est pas terrible..
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Thomas Douillard . Évalué à 4.
Si on a un bon langage de spec, de niveau relativement haut disons, qui permet de pondre plus ou moins automatiquement du code, ca permet de se concentrer plus sur la spec elle même, et moins sur le code. Alors certe, tu peux faire des erreurs de spec, mais dans ce cas, au moins, t'as plus à tout recoder. D'autant plus que, t'étant à priori plus concentré sur la spec, t'as moins de chance d'avoir fait une erreur fondamentale.
Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.
Après, on en est pas encore là ^^
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par reno . Évalué à 3.
Certe et le propre d'une spécification "normale" est de ne pas entrer dans les détails sur le comment mais indique le résultat désiré sans entrer vraiment dans le détail non plus d'ailleur.
Par rapport aux spec avec lesquelles j'ai a bosser, pour pouvoir éventuellement genere du code avec, il faudrait que la taille des specs soit multipliées par 10 et encore, c'est probablement sous estimé.
> Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.
Oui, enfin le boulot du codeur n'est pas de prendre la spec et de pisser du code, mais de l'interpreter, remplir les blancs, discuter, etc..
Ce qui permet de trouver aussi des erreurs de specs, et je peux te garantir que j'en ai trouvé quelqu'une.. Avec une spec qui grossit d'une taille *10, le nombre d'erreurs grossira aussi.
La génération automatique de code, j'ai déja donné et même sans partir de spec, cela a des avantages mais aussi de gros inconvénient: temps de compil monstreux (genre le générateur qui génere une classe différente par type d'entier différent, oui c'est du vécu), opacité du code généré (à débugger c'est "sympa": les débuggeur remontent rarement au niveau du générateur initial, débuggé du code généré automatiquement c'est à peu près aussi drole que d'aller chez le dentiste).
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est une tentative de repenser intégralement la façon de programmer en introduisant des notions de reconnaissances de forme, de manipulation ensembliste des données, de métaprogrammation, etc...
Cela dit, tu soulèves des points intéressants, bien que je pense qu'il est possible de faire un langage de spec très haut niveau sufiseament léché au niveau théorique pour cracher quelque chose de propre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Thomas Douillard . Évalué à 2.
Dans ce cas, le boulot du codeur serait toujours de remplir les blancs, donc de partir d'une spec vague et en faire une spec complète et correcte, sans avoir à se préoccuper du code.
Après, sur les perfs, c'est un autre problème, sur la faisabilité aussi, les problèmes à résoudre étant souvant indécidables ... Ce que je dis est plus de l'ordre d'un fantasle idéaliste, d'autant plus que je suis pas spécialiste du domaine.
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 1.
On commence par un modèle abstrait général qui pose le but a atteindre.
On prouve qu'il est cohérent
On écrit un modèle qui raffine le premier en rajouter des detail, par exemple la forme générale de l'implémentation.
On prouve qu'il raffine le premier modèle, c'est à dire qu'il fait la même chose. On prouve qu'il est cohérent.
Et ansi de suite jusqu'a obtenir un modèle avec la precision souhaitée.
Si on le souhaite on peut aller jusqu'a la précision requise pour une implémentation. Dans ce cas on peut générer le code automatiquement. Le code est assez crade en effet, mais ce n'est pas très grave vu qu'il est correcte par contruction pas besoin de le débugger.
Mais il ne faut pas réver, trouver une preuve est un problème indécidable. Il y a un prouveur dans les outils qui arrive faire les plus faciles mais il faut faire les plus complexes à la main. Au final il faut s'accrocher et le temps pour faire tout cela est long mais on arrive a un logiciel 100% certifié.
Pour info cette méthode a déjà été utilisée dans l'industrie, par exemple pour réaliser le logiciel qui pilote le metro parisien METEOR
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Et encore, les mauvaises langues disaient que la pluspart des preuves avaient été faite à la main.
"La première sécurité est la liberté"
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 0.
Et alors ?
Si c'est une réthorique de ta part pour sous-entrendre que le B n'a jamais servis a rien d'autre, je trouve ca mesquin. Je ne vais pas chercher d'autre exemples pour te faire plaisir.
Je n'ai prétendu que toute les preuves avaient été faites automatiquement. Sache que "indécidable" veut dire qu'il n'existe pas de procédure automatique permettant de résoudre un problème donné. Il qu'il n'en existera jamais : c'est un fait scientifique.
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 1.
je ne vois vraimement pas ce qui te choque ?
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La démonstration que l'on m'avait présenté revient pour moi à démontrer qu'un logiciel A de calcul d'arret d'un autre logiciel B ne peut pas décider de l'arret de B en ayant aucune entrée (donc B également exclus). Ce que je trouve d'un interet discutable...
Beaucoups de cas pratiques peuvent souvent se résoudre par backpropagation. Je suis d'accord qu'il n'existe pas d'algo pour le cas général, mais je suis persuadé que l'on peut en trouver plein pour des problèmes courant.
"La première sécurité est la liberté"
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 1.
Plein de cas courant peuvent être résulu, et c'est cela qui nous permet d'écrire des prouveurs, ou de faire marcher des algos de model-checking.
Il n'empeche que même dans les cas courant (de l'industrie) il y a des cas emmerdant qui ne fonctionnent pas avec les techniques actuels. Que cela soit avec le prouveur de B ou n'importe quel autre. La principale limite étant que la complexité de ce genre d'algo est généralement exponentielle. Alors qu'un être humain arrive, plus ou moins, a *voir* la solution directement.
En pratique en B on dirige le prouveur en lui faisant faire des cas intermédiaire et en lui machant le travail. Alors même dans les preuve à la main le prouveur est essentiel.
Perso je trouve que ca marche pas trop mal, bon ok defois on s'arrache les cheveux et sa demande pas mal d'expérience et de temps.
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par outs . Évalué à 1.
Et il en existe un sacré paquet pourtant des méthodes ...
alors je considere ca normal d'utiliser tjrs cet exemple et d'en être fier surtout que c'est une étape fondamentale dans l'histoire du B.
Et celui ci a évolué depuis. On est passé au B événementiel et une nouvelle version des outils est en préparation http://rodin-b-sharp.sourceforge.net/ en plus cela sera libre.
# One size fits all
Posté par ufoot (site web personnel) . Évalué à 8.
mmm, là j'ai du mal.
J'ai du mal parce que ça donne l'impression que Lissac veut cumuler les avantages du haut niveau avec les avantages du bas niveau. Je stigmatise mais y'a de ça. Or l'expérience montre que c'est loin d'être simple. C'est ultra ambitieux, on ne peut certes pas démontrer que c'est impossible, mais quelques décennies d'informatique nous montrent que bon, y'en a qui ont essayé, ils ont eu des problèmes.
Ma vision de la chose, c'est qu'au contraire il vaut mieux laisser C là où il est, tranquille, le conserver en tant qu'interface de base pour les bibliothèques. Ca n'empêche pas de s'extraire ensuite de toute cette plomberie avec un langage de plus haut niveau. C'est ce qui est fait pour la plupart des applications web d'ailleurs, vous avez un moteur en C (un mod_python, un PHP, voire une machine virtuelle JAVA) et par-dessus quelque chose de plus haut niveau qui tourne. Le cloisonnement bas niveau / haut niveau n'est pas quelque chose dont il faut essayer de se débarasser AMHA. Au contraire... Ca permet d'y voir clair. Au langage C le traitement de tableaux, de matrices de flottants agencés tout bien comme il faut pour que ça arrive tout près tout chaud dans un pipeline graphique. A un autre langage la tâche plus "noble" de décider si oui ou non on va exécuter telle ou telle chose, de savoir si oui ou non il faut afficher ou pas telle ou telle chose à l'écran. En clair: quand on fait du bas niveau, ce qui compte, c'est de savoir ce qu'on fait, et à ce jeu là C gagne à tous coups. Après, si on veut faire de l'orienté objet, on extrait une API (avec SWIG par exemple), et on s'amuse dans un vrai langage type Python, Perl, Ruby, voire Java pour ceux qui pensent que c'est souple (*sigh*).
Les exemples d'applications construites sur ce modèle sont légions, déjà, le site même sur lequel vous lisez ces pages, c'est un gros moteur C (PHP) qui lance des scripts. Et accessoirement le tout génère du HTML, à partir de requêtes SQL. 4 langages impliqués au minimum. Chacun son job.
Ensuite, en vrac : Quake, Emacs, Mozilla, Gimp -> tous utilisent à des degrés divers des langages différents pour chacune des tâches à exécuter. Quake en C avec de l'assembleur pour le "très bas niveau" et un langage de plus haut niveau ad-hoc (Quake-C) pour faire des mods et articuler tout ça. Emacs, c'est le plus vieux dans les exemples que je cite, et ça n'est jamais rien qu'une grosse machine virtuelle (Emacs)Lisp... codée en C. Mozilla et XPFE, dans le genre multilangage c'est une caricature... Et Gimp, hé ben yet another example.
Tout ça pour dire qu'autant je pense que l'évolution des langages n'est pas terminée, autant le créneau "du C en plus joli" est bouché. Si c'est pour damer C sur son créneau, il faut faire mieux sur son créneau. Et pas ailleurs. Donc faire "plus facile de contrôler soi-même la mémoire", "plus rapide", et "plus de bibliothèques supportées". Voyez avec les gens qui continuent à développer en C aujourd'hui, je ne suis pas sûr qu'ils pensent "C n'est pas assez haut niveau". En tous cas pas moi. Si tel était le cas, ils seraient passés à autre chose... Le cas C++ est bâtard, et je suis certain que nombre de spécialistes C++ trouveraient leur pied bien plus facilement côté C#, Java, voire même plus simplement en langage de script. L'orienté object en C++, j'ai donné, c'est à chier. Tous les inconvénients du C alliés à la lourdeur d'un formalisme ultra-rigide.
Pour moi le truc qui pourrait révolutionner quelque chose, c'est un modèle, un framework, une façon de faire, un "truc" qui me permette de faire de l'assembleur, du C, du SQL, du Python, du HTML de manière transparente sans avoir à me soucier de rien. C'est là-dessus que j'ai besoin de simplicité. Il y a bien des efforts, .Net de Microsoft va dans ce sens, mais reste très limité car le principe de bytecode intermédiaire est très limitatif (pas trivial de représenter tous les paradigmes de tous les langages avec une fidélité parfaite, on ne veut pas le plus petit dénominateur commun de tous, sinon Perl ou Scheme perdent toute saveur une fois rentrés dans le moule), SWIG fait gagner un temps précieux mais la plomberie reste présente. Dans l'ensemble je pense qu'on n'a pas fini de réfléchir sur le problème.
Donc voilà, en tant que programmeur, ce qui me ferait triper c'est d'avoir "quelque chose" qui me permette d'utiliser *simplement* le langage le plus adapté à chaque problème. Et certainement pas qu'on me dise "j'ai trouvé le langage Y qui va remplacer le langage X".
Je ne vois pas trop qui mieux que Perl 6 pourra supplanter Perl 5, et avant de s'attaquer à l'assembleur ou à C, il faut se poser la question de savoir "dans quel but?". L'assembleur, pour ne prendre que cet exemple, a toujours ses applications. On s'en sert toujours. On s'en sert de moins en moins mais par définition il est irremplaçable. Ce qu'il faut, c'est simplifier l'interface entre l'assembleur et les candidats de plus haut niveau, mais en aucun cas on ne peut s'en débarasser. Le C ne l'a en fait d'ailleurs pas "remplacé", il a simplement remplacé l'assembleur dans les cas où ce dernier n'avait aucun intérêt, aucune valeur ajoutée. Pour qu'un candidat au "remplacement de C" aujourd'hui ait une chance, il faudrait que C soit utilisé dans un cas où il n'a aucune valeur ajoutée par rapport à un autre langage existant (de plus haut niveau par exemple). Sachant qu'aujourd'hui il y a 40 manières de faire une "base" en C et une sur-couche de plus haut niveau (regardez Lua, c'est excellent), ceux qui ne le font pas le font AMHA pour 4 raisons:
- ils ne connaissent pas et n'ont pas envie de connaître (depuis le temps...);
- ils ont un tel passif, une telle somme de code existant, que bon ils sont forcés de continuer en C;
- ils obéissent à une norme (cas typique en entreprise) qui dicte de manière plus ou moins arbitraire "ici les développements se font en XYZ";
- ils ont une vraie bonne raison, C leur convient parfaitement, alors...
Pour motiver ces gens-là à changer, bon courage.
Ceci étant, dans le cadre de recherches scientifiques, il est tout à fait compréhensible et souhaitable qu'on ne vise pas l'application directe et immédiate, donc Lisaac, bah très bien, faut continuer!
[^] # Re: One size fits all
Posté par Ontologia (site web personnel) . Évalué à 5.
Lisaac a été pensé pour ne plus avoir besoin de faire du C.
D'ailleurs, un Système d'exploitation entier a été écrit avec. Il tient en 30 000 lignes, interfaces graphique comprise. Il est intégralement objet et fonctionnel. Tu trouveras sur le site une démo tournant sous linux ou tu pourras évaluer l'empreinte mémoire.
Lisaac est doté de mécanismes permettant de se passer de C. Tu trouveras la doc sur le site, mais j'évocquerai ici :
- La section INTERUPT qui permet de définir des interuptions, le code étant compilé en conséquence.
- La section MAPPING qui permet de définir une structure de données ordonné, se posant sur le binaire
- Des perfs et une consommation mémoire similaire au C.
Benoit Sonntag, le concepteur de Lisaac a 400 000 lignes de C à son actif, et un peu plus en assembleur x86.
C'est dire s'il a fait le tour de la question.
Décidé d'en finir une bonne fois pour toute avec l'obligation de passer par ce langage pour le bas niveau, il a fait Lisaac.
Il a la prétention de penser que Lisaac est fait pour rendre (théoriquement parlant) le C comme un langage dépassé, bien qu'exceptionnel.
J'ai la flemme de répondre sur tes idées sur le framework qui sont très intéressantes et que j'irai relire de temps en temps, mais ça fait quasiment une semaine que je ma bat ici, je fatigue :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: One size fits all
Posté par ufoot (site web personnel) . Évalué à 5.
Je l'aurais parié 8-)
En fait je suis assez intéressé et preneur du concept de Lissac, mais c'est la phrase :
> Sa palette d'utilisation couvre tous les besoins puisqu'il est à la fois bas, moyen et haut niveau.
qui me fait tiquer... AMHA faut choisir: on s'attaque à C ou aux autres, mais pas les 2. En relisant la doc du langage, en fait peut-être bien que la cible c'est vraiment effectivement le C, mais je reviens au truc précédent, va falloir être fort pour vendre ça aux types qui comme moi continuent à faire du C aujourd'hui, après avoir essayé C++ et Java, et en être revenu. Concrètement pour moi ça a de la la valeur et c'est bien de manipuler un "unsigned char ***", dans certains cas, j'ai effectivement besoin d'un tableau d'octets à 3 dimensions, et pouvoir faire ce que je veux avec...
Sur le "plus haut niveau", c'est pareil faut se lever de bonne heure pour aller chercher les langages de script sur le terrain de la facilité d'utilisation. Pas de compilation, lisibilité maximale, typage & introspection dynamiques...
> Benoit Sonntag, le concepteur de Lisaac a 400 000 lignes de C à son actif, et un peu plus en assembleur x86.
Ouh la! Bon d'accord, mais bon ça frise l'overdose, je n'ai clairement pas autant codé, simplement pour avoir longtemps tourné autour du concept "j'ai un problème comment le résoudre" ma petite expérience me dit que le langage qui fait tout, heu c'est comme la couleur qui plaît à tout le monde. Ca explique peut-être la différence de point de vue entre Benoît et moi 8-)
Néanmoins bon, note que je ne serais pas forcément le dernier à utiliser un Lissac, mais attention, DANGER WARNING ne vous mettez pas des bâtons dans les roues avec les licences. Ca a été dit plus haut mais c'est évident et clair, *aucun* langage, fût-il génial, ni *aucun* OS, fût-il génial, n'a de chance aujourd'hui si il n'y a pas une implémentation de référence sous licence libre. Même gratuit ça ne suffirait pas je pense, il n'y a qu'à voir comme certains boudent Java parce que l'implémentation de référence est proprio. Donc voilà, release early, release often, et surtout release free. Pour ce qui est des brevets, il me semble que le fait qu'il existe un implémentation de référence et qu'elle soit largement distribuée doive faire sauter toute tentative de brevet par un tiers, car ça constitue un précédent, donc il n'y aura plus "innovation". A-t'on essayé de breveter Perl?
SVP ne nous refaites pas le coup de Scilab qui est excellent mais s'est bêtement vu refuser plein de contributions externes parce que la licence contenait des clauses qui font que bon, apt-get install scilab y n'y marche pas par défaut... C'est triste. Mais bon je sais bien que vous ne décidez pas de tout. Néanmoins c'est déjà pas mal que l'INRIA finance ce type de recherche.
> ça fait quasiment une semaine que je ma bat ici, je fatigue :)
Meuh non on se bat pas on discute. C'est plutôt une bonne chose que ça suscite la réaction, non?
Keep up the good work!
[^] # Re: One size fits all
Posté par Ontologia (site web personnel) . Évalué à 3.
Oui bien sûr, ça va prendre du temps.
Lisaac aura ses utilisateurs, C sera encore utilisé encore longtemps... Et alors.
Certains projets utiliseront C, d'autres Lisaac, ce sera en fonction de la situation de chacun.
Personnelement, à la différence de nicO, qui en tant qu'ingé microélectronique s'intéresse au bas niveau, je suis plus attiré par les fonctionnalités haut niveau, le (bon) design de la lib, etc...
Après... Lisaac possède en natif des fonctionnalités système, personellement je ne les utiliserai pas et de toutes façons, elles sont là et les utilisera qui veut.
Seulement, quand on aura un code qui pour un algo similaire fera 30 % de lignes code en moins pour 10 % de perf en mieux (pour le moment on est à 2% moins bien), pas mal de projet faisable qu'en C à l'heure actuel pourront être fait en Lisaac.
Pour le très bas niveau, ok, le C, c'est très bien.
Pour des applications critiques comme un player mpeg2 ou autres choses du même style, j'en vois par contre un gros intérêt : réduire les coûs, de dev, mais aussi de debugging.
Le leimotiv de Benoit (je l'ai entendu 15 fois) c'est "un gros projet en C, ça devient ingérable. C'est vrai qu'on se sent puissant à jouer avecles pointeurs, mais à un moment ça devient trop lourd". Et il sait de quoi il parle !
Effectivement, les langages de scripts ont des avantages (introspection), mais je pense qu'en bidouillant, on peut se débrouiller pour les compiler.
Lisaac est une aventure qui ne fait que commencer.... ;-)
En ce qui me concerne, le travail à fournir est plus dans les fonctionnalités du langage (fonctionnalités agent créant des threads automatiquement, type MATCH permettant de choisir son type au dernier moment, SQL intégré, etc..) mais aussi dans le designe de la lib.
Regarde la librairie graphique, pour gérer des fenêtre, elle est super bien faites, avec son système de boite au lettre qui te permet de gérer les éveènements clavier souris comme du courrier.
L'avenir du langage passe aussi par là...
- Faire gaffe à l'inflation de types, comme Java. --> minimum de type pour le maximum de choses. Merci l'héritage dynamique, ça va servir à ça.
- Faire des fonctions avec des noms et mot clés intuitifs.
Pour la question des licences, je suis totalement d'accord avec toi, comme je l'ai expliqué plus haut.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: One size fits all
Posté par ciol . Évalué à 1.
# Hello word
Posté par Uvoguine . Évalué à 3.
941 lignes de code C complètement imbitable (que je ne copierai pas ici). C'est assez rigolo à lire, de loin...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.