Code : 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage
Posté par Nicolas Boulay (). Modéré le 09 mars 2006.
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.
![[fr]](../images/fr.png)
La conférence (539 hits)-
Le site web (1127 hits)
![[en]](../images/en.png)
La documentation du langage (689 hits)-
La page de Lisaac sur Wikipedia (1249 hits)
-
Self (261 hits)
-
Smart Eiffel (216 hits)
> Lire la dépêche (238 commentaires, moyenne: 3).
Vous avez demandé le commentaire #689703.
Euh ...
> 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.
On dirait les pronostics visionnaires des nouvelles d'OSNouille, et il n'y a pas de mal à ça attention ! C'est juste que j'ai tellement rigoler que j'ai faili en refaire sortir le hâchi parmentier par mes oreilles tellement ça me rapelle le discour sur l'objective C il a 10 ans ...
[^]Re: Euh ...
Oui mais nous on ne l'annonce pas, on le prouve : http://isaacos.loria.fr/li_speed.html
[^]Re: Euh ...
moi j'ai quelques questions :
- 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 ?
MonoFrance
[^]Re: Euh ...
Pour les exemples autant pour moi, j'ai la réponse à ma question dans le dossier example du zip téléchargeable :)
MonoFrance
[^]Re: Euh ...
"autant pour moi"--> au temps pour moi
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)
[^]Re: Euh ...
Au temps pour moi :)
MonoFrance
[^]Re: Euh ...
"au temps pour moi" -> "OTAN pour moi"
Ahhh, les trolls, on ne s'en lasse jamais...
[^]Re: Euh ...
ou bien encore http://www.langue-fr.net/index/A/au_temps-bis.htm , mais là, la parenthèse s'allonge...
[^]Re: Euh ...
Arrêtez avec ce troll, après il y en a qui utilisent "au temps" à chaque fois qu'il faut dire "autant" (pas seulement dans cette expression), genre "Au temps il est fort, au temps il est stupide"
[+] [^]Re: Euh ...
"autant pour moi"--> au temps pour moi
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)
[^]Re: Euh ...
Donc comment exporter des API en C ?
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).
[^]Re: Euh ...
Donc comment exporter des API en C ?
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 !!!
MonoFrance
[^]Re: Euh ...
Je précise que c'est un brevet défensif.
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
[^]Re: Euh ...
Un brevet défensif pour quoi faire ?
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.
MonoFrance
[^]Re: Euh ...
Le problème existe toujours que c'est un proces et 1 M¤ plus tard qui dira qui a raison.
D'où la GPL V3, ou l'on donne également une licence sur tout brevet utilisé par le code.
[^]Re: Euh ...
Dans tous les cas ils peuvent divulger le code source maintenant, à partir du moment où la demande de brevet est déposée... Les boîtes qui font des demandes de brevet n'attentent pas que le brevet soit validé pour l'exploiter, donc pour moi c'est clairement une fausse excuse pour justifier le côté "closed-source".
MonoFrance
[^]Re: Euh ...
Espèce de capilo-quadrisectomieur.
(PS: m'enfin il est toujours succulent de lire un partisan acharné de C# avoir peur de brevet logiciel sur un langage...)
[^]Re: Euh ...
Le langage C# n'a absolument aucun brevet, aucun n'est en préparation, de toute façon ce langage n'invente strictement rien.
Et c'est quoi un capilo-quadrisectomieur ? :)
MonoFrance
[^]Re: Euh ...
Un coupeur de cheveux en 4. Evident, non ?
Certe C# en lui-même n'est pas breveté mais seulement toutes ses API.
[^]Re: Euh ...
Puisque tu tiens à troller, pourve moi ce que tu affirmes et trouve moi brevet de l'ensemble des APIs
MonoFrance
[^]Re: Euh ...
On te l'a déjà montré 10 fois.
[^]Re: Euh ...
Je l'ai toujours pas vu. Il est où ?
MonoFrance
[^]Re: Euh ...
Là
https://linuxfr.org/comments/673971,1.html
là
https://linuxfr.org/comments/674008,1.html
et un peu partout autour...
[^]Re: Euh ...
Oué c'est bien ce que je dis :
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é).
MonoFrance
[^]Re: Euh ...
Parce qu'il faut avoir inventé quelque chose pour deposer un brevet ?
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Euh ...
Ben c'est la nature même d'un brevet, protéger une invention.
MonoFrance
[^]Re: Euh ...
c'est la théorie ça ;)
[^]Re: Euh ...
Avant de demander, il faut étudier s'il on peut demander....
[^]Re: Euh ...
Et donc quand peut on espérer découvrir ces inventions ? Non parcque et là on est quand même face à un logiciel bien proprio en première page de LinuxFR, leurs lecteurs ont soif de partage de connaissance sur un langage qui va "sans doute" remplacer le langage utilisé dans les entrailles de leur OS favori...
MonoFrance
[^]Re: Euh ...
Explique ton problème à la direction de l'INRIA. Ce n'est pas nous qui décidons.
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.
[^]Re: Euh ...
Je comprend bien, mais là comme ca sans plus de détail, mais en tant que linuxien et libriste je ne vois aucun intérêt à s'intéresser à un langage purement proprio qui n'est pas normalisé et pas encore finalisé. Je pensais qu'en cherchant à publier sur LinuxFR vous souhaitiez attirer l'attention sur "l'ouverture" du langage, son utilisation possible sous Linux. Forcer de constater qu'il ne colle pas du tout à sa philosophie.
MonoFrance
[^]Re: Euh ...
Le langage est jeune et prometteur. Il ne sera soutenu par l'inria que si il y a des partenaires industriels derrière. Ils sont encore échaudé par OCaml qui ne décolle toujours pas.
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...
[^]Re: Euh ...
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.
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 ...
Les gens qui veulent changer de langage en profitent en général pour changer de paradigme et passer à beaucoup plus haut niveau
Ça tombe bien, il se trouve que c'est le cas.
[^]Re: Euh ...
> Ils sont encore échaudé par OCaml qui ne décolle toujours pas.
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 ...
J'ai effectivement pour projet de monter un CLAN (Comprehensive Lisaac Archive Network). C'est d'ailleurs à toi que je dois cette idée, m'étant rendu compte à te lire que c'est effectivement indispensable.
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 !
[^]Re: Euh ...
Je ne sais pas en quoi est programmé l'original (le CTAN de TeX) mais le CPAN de Perl est bien sur programmé en Perl ;-) D'ailleurs, pour faire celui du javascript (JSAN), ils prennent aussi du Perl car si mes souvenirs sont bons, il y a des choses que le javascript ne peux pas faire.
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 ...
Sinon, c'est un beau projet que de le faire en Lisaac lui-même, histoire de montrer la souplesse de celui-ci ;-)
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 ?
[^]Re: Euh ...
> Boulot énorme !
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 ...
> Faut savoir qu'en Lisaac, tu n'as pas de import à faire comme en perl
> 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 ...
J'ai tout de même un peu de mal à voir ce que tu reproche à Java (j'ai sans doute loupé un truc dans ton explication). Le nommage des packages n'est pas basé sur le DNS, c'est un conseil de Sun de nommer ses packages en utilisant un nom de domaine qu'on possède afin de limiter au maximum les collisions. Pour simplifier les choses, 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
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
Hurd will be out in a year (or two, or next month, who knows)
-- Linus Benedict Torvalds, 1991
[^]Re: Euh ...
> Le nommage des packages n'est pas basé sur le DNS, c'est un
> 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 ...
Explique ton problème à la direction de l'INRIA. Ce n'est pas nous qui décidons.
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 ...
Je savais bien que le troll allait démarrer quand j'ai voté pour que cette annonce soit en première page !
À "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 ...
Tu trouveras les coordonnées utiles ici.
http://www.inria.fr/inria/organigramme/fiche_dirdri.fr.html
Merci, j'ai écrit au premier nom de la liste ;-)
[^]Re: Euh ...
Avant de remplacer le C, il va falloir :
- 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 ...
Java remplace le C là ou la sureté est plus important que la vitesse. Dans le cas contraire...
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é.
[^]Re: Euh ...
Il faut bien dire que la syntaxe de lisaac a l'air absolument atroce (cf les exemples de http://fr.wikipedia.org/wiki/Lisaac ) je me demande ce qui justifiait d'adopter une écriture aussi laide et tordue. En tout cas ça donne pas envie.
[^]Re: Euh ...
C'est ce que je me suis dis aussi :)
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.
[^]Re: Euh ...
"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)."
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 ...
> 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.
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 ...
tu veux dire que tu n'as jamais accidentellement fait une affectation en lieu et place d'un test ?
[^]Re: Euh ...
> tu veux dire que tu n'as jamais accidentellement fait une affectation en lieu et place d'un test ?
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 ...
>Si, mais comme j'utilise gcc en -Wall,
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 ...
bool b;
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 ...
bool b;
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.
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Euh ...
Il suffit de faire comme Python : décréter que les affectations ne sont pas des expressions. Du coup tu ne peux plus mettre d'affectation dans une conditionnelle (syntax error).
>>> x=0
>>> if (x=1): print "hop"
File "", line 1
if (x=1): print "hop"
^
SyntaxError: invalid syntax
>>> x
0
[^]Re: Euh ...
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..
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 ...
en même temps smalltalk aussi n'a que 4 mot clefs ... c'est d'ailleurs une caractéristique que j'aprécie beaucoup...
La Roue du Temps
[^]Re: Euh ...
je me demande ce qui justifiait d'adopter une écriture aussi laide et tordue. En tout cas ça donne pas envie.
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.
[^]Re: Euh ...
Ce qu'il y a d'affreux ? Les mascules, j'ai horreur d'avoir l'impression que le code me gueule dessus.
[^]Re: Euh ...
et puis les majuscules partout ça rappelle trop le FORTRAN77, pas idéal pour le langage du troisième millénaire :)
[^]Re: Euh ...
et puis quand on tape à dix doigts, utiliser beaucoup le shift, c'est un peu pénible et quand on utilise le caps lock, il finit toujours par être activé quand il doit être désactivé ou l'inverse.
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: Euh ...
Oui enfin le passage de parametre par nom plutot que par position n'est pas une nouveauté: Ada, Python, etc..
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 ...
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.
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: Euh ...
D'ailleurs, en ObjectiveC, la solution est superbe.
[^]Re: Euh ...
Tu parles de ce langage où on est obligé de mettre le nez dans le code pour comprendre la signature d'une fonction.
Quand les developpeurs veulent bien se donner la peine d'expliciter les paramètres.
[^]Re: Euh ...
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 !
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: Euh ...
Java remplace le C là ou la sureté est plus important que la vitesse. Dans le cas contraire...
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 ...
Java est devenu le langage d'entreprise. Il y a remplacé C++.
Je pensais que tu parlais de Java pour l'embarqué utilisé dans certaines applications (javacard...).
[^]Re: Euh ...
>> M'enfin c'est vrai que pour la vitesse, rien ne vaut le C. Enfin l'assembleur..
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 ...
FreePascal fait quoi de special avec les chaines de caractere pour etre plus rapide que le C ? Il garde la longueur de chaine qqe part ?
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 ...
Le problème de C, c'est que la taille de la chaîne est connu du fait qu'on un un '\0' à la fin.
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.
[^]Re: Euh ...
En C y'a pas de chaîne de caractère. Certains utilisent des structures "string" complexe, d'autre se contentent d'un pointeur sur un caractère avec un '\0' terminal. Mais c'est pas du tout la faute au langage qui n'impose strictement rien.
MonoFrance
[^]Re: Euh ...
C'est précisément la faute du langage qui n'impose rien, et favorise ainsi des solutions paresseuses et sous-optimales.
Ne pas intégrer un type chaîne de caractères (fondamental dans 99% des applications), c'est une grave lacune.
[^]Re: Euh ...
En fait après réflexion ce que j'ai dis au dessus n'est pas vraiment exact : le langage C a "participer" à cette solution paresseuse en introduisant la syntaxe "machaine".
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.
MonoFrance
[^]Re: Euh ...
Je comprend pas ce que tu veux dire.
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.
[^]Re: Euh ...
normaliser certains types "univesels" est utile, pour s'assurer que tous l'utilise de la même manière, sans avoir le risque qu'un "malin" utilise son propre format qui nécessiterait des conversions incéssantes. Le langage C (et C++) ne propose pas de véritable type string par défaut et on constate bien les dégâts que cela occasionne, à plus forte raison parcqu'il n'y a aucune abstraction du type, c'est directement une structure mémoire bien définie que l'on peut manipuler à son aise.
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 :)
MonoFrance
[^]Re: Euh ...
>Le langage C (et C++) ne propose pas de véritable type string par défaut
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).
Wr ar fbhunvgr cnf ha qrfgva sharfgr à yn cncnhgé. Nzra.
[^]Re: Euh ...
Excuse moi, mais je ne vois pas en quoi "std::string" n'est pas un type standard du C++
- 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.
MonoFrance
[^]Re: Euh ...
C'est vrai que la norme et le standard est un problème fondamental, et le libre ne simplifie pas les choses...
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.
[^]Re: Euh ...
Si on reste dans un l'optique d'un langage libre (mais controllé par l'inria), il suffit de voir comment perl, ruby, php s'en sorte...
[^]Re: Euh ...
C'est précisément ça : en ASCII par exemple, le premier caractère contient la longueur de la chaîne.
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)
Non, rien.
[+] [^]Re: Euh ...
question : comment peut on preferer coder en java plutot qu'en C... perso je ne comprend pas ! les math.truc.bidule.machin a gogo ca me sort part les trous de nez...
par contre pour l'instant, pas de problèmes avec le python !
[^]Re: Euh ...
as tu déja utilisé eclipse plus de 10 minutes ?
ebaobab.net - Partagez avec vos amis tout en conservant votre vie privée !
[^]Re: Euh ...
faut mieux utiliser eclipse plus de 10 min si on veut lui donner le temps de se lancer :p
[+] [^]Re: Euh ...
as-tu déjà codé en java plus de 10 minutes ? ;o)
[^]Re: Euh ...
> 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.
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 ...
Non, car
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.
[^]Re: Euh ...
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 ...
L'intérêt c'est que tu peux définir dans la librairie toute les conditionnelles que tu désires.
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.
[^]Re: Euh ...
L'intérêt c'est que tu peux définir dans la librairie toute les conditionnelles que tu désires.
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 ...
Bah, si ça change rien pour le programmeur, mais que ça permet de simplifier le compilateur, pour moi ça apporte quelque chose : de la simplicité pour l'un, sans pénaliser l'autre.
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 ...
ee la simplicité pour l'un, sans pénaliser l'autre. Donc, il y a un avantage.
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.
MonoFrance
[^]Re: Euh ...
Je viens de relire toute la page et l'ensemble de tes commentaires. Je me demande ce que t'ont fait les développeurs de Lisaac pour que tu partes avec autant d'à prioris contre ce langage ... <humour>un concurent à c# ?</humour>
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 ...
Je me demande ce que t'ont fait les développeurs de Lisaac pour que tu partes avec autant d'à prioris contre ce langage
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é.
MonoFrance
[^]Re: Euh ...
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 ...
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 ?
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 sim