Articles précédents : Code
- [70] Microsoft "vend" son code source
- [52] Le noyau Linux 2.6.15 est arrivé
- [56] Apple ouvre le CVS de WebCore
- [54] Nouvelle avancée du port du Hurd sur L4
- [29] Templeet certifié J2EE
- [92] Sortie du noyau 2.6.11
- [29] Délégation de pouvoirs avec un contrôleur de domaine Samba
- [96] Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4
- [107] SPT : Une alternative au système historique de partitionnement des PC
- [40] Sortie de OpenBGPd
Liens connexes
- La conférence (533 hits)
- Le site web (1113 hits)
- La documentation du langage (686 hits)
- La page de Lisaac sur Wikipedia (1244 hits)
- Self (260 hits)
- Smart Eiffel (211 hits)
Dépêche modérée par
Dépêche éditée par
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 (533 hits)-
Le site web (1113 hits)
![[en]](../../../images/en.png)
La documentation du langage (686 hits)-
La page de Lisaac sur Wikipedia (1244 hits)
-
Self (260 hits)
-
Smart Eiffel (211 hits)
> Lire la dépêche (238 commentaires, moyenne: 3).
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 ...
Posté par Ontologia (page perso, ) le 09/03/2006 à 20:54. (lien). Évalué à 2.Oui mais nous on ne l'annonce pas, on le prouve : http://isaacos.loria.fr/li_speed.html
-
[^]Re: Euh ...
Posté par TImaniac (page perso, ) le 09/03/2006 à 21:12. (lien). Évalué à 8.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 ?-
[^]Re: Euh ...
Posté par TImaniac (page perso, ) le 09/03/2006 à 21:21. (lien). Évalué à 1.Pour les exemples autant pour moi, j'ai la réponse à ma question dans le dossier example du zip téléchargeable :)
-
[^]Re: Euh ...
Posté par yesi () le 10/03/2006 à 10:18. (lien). Évalué à 0."autant pour moi"--> au temps pour moi
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)-
[^]Re: Euh ...
-
[^]Re: Euh ...
-
[^]Re: Euh ...
Posté par Joël SCHAAL () le 10/03/2006 à 11:10. (lien). Évalué à 0.ou bien encore http://www.langue-fr.net/index/A/au_temps-bis.htm , mais là, la parenthèse s'allonge...
-
[^]Re: Euh ...
Posté par Thomas Douillard () le 10/03/2006 à 13:01. (lien). Évalué à 5.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 ...
Posté par yesi () le 10/03/2006 à 11:29. (lien). Évalué à -4."autant pour moi"--> au temps pour moi
et pour la culture...
http://www.academie-francaise.fr/langue/questions.html#au_te(...)
-
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 00:03. (lien). Évalué à 6.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 `
section HEADER
- name := VIDEO;
- comment := "X11 Driver video - Xlib -";
- category := MICRO;
- bibliography:= "http://IsaacOS.com";
- author := "Benoit Sonntag (bsonntag@loria.fr)";
- external :=
`
#include <X11/Xlib.h>
Display *display;
Window window;
GC gc;
Screen *screen;
XImage *ximage=NULL;
`;
section INHERIT
* parent_bitmap:BITMAP;
section VIDEO
- line_tmp:BMP_LINE;
section PUBLIC
- is_active:BOOLEAN;
- planes:UINTEGER;
- make w,h:INTEGER <-
( + data:NATIVE_ARRAY[USMALLINT];
// Init BITMAP:
width := w;
height := h;
// Creation Server X:
`display = XOpenDisplay(NULL)`;
// Screen Default:
`screen = ScreenOfDisplay(display,DefaultScreen(display))`;
// Init Graphic context:
`gc = DefaultGC(display,DefaultScreen(display))`;
// Creation Window:
`window = XCreateSimpleWindow(display,RootWindow(display,DefaultScreen(display)), 0,0,@w,@h,2,0,0)`;
// Event manager:
//XSelectInput(display,window,ExposureMask);
// Title window:
`XStoreName(display,window,"X-Isaac")`;
// Display Window:
`XMapWindow(display,window)`;
planes := `PlanesOfScreen(screen)`:UINTEGER;
"Video mode: ".print;
planes.print; "bits\n".print;
planes
.when 15 then {
line_tmp := BMP_LINE_15.create w;
data := line_tmp.get_storage;
`ximage = XCreateImage(display,None,15,ZPixmap,0,(char *)@data,@w,1,16,0)`;
}
.when 16 then {
line_tmp := BMP_LINE_16.create w;
data := line_tmp.get_storage;
`ximage = XCreateImage(display,None,16,ZPixmap,0,(char *)@data,@w,1,16,0)`;
}
.when 24 then {
line_tmp := BMP_LINE_32.create w;
data := line_tmp.get_storage;
`ximage = XCreateImage(display,None,24,ZPixmap,0,(char *)@data,@w,1,32,0)`;
}
.when 32 then {
line_tmp := BMP_LINE_32.create w;
data := line_tmp.get_storage;
`ximage = XCreateImage(display,None,32,ZPixmap,0,(char *)@data,@w,1,32,0)`;
};
is_active := TRUE;
);
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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 08:20. (lien). Évalué à 1.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 !!!-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 08:24. (lien). Évalué à 5.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 08:57. (lien). Évalué à 0.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.-
[^]Re: Euh ...
Posté par Nicolas Boulay () le 10/03/2006 à 09:33. (lien). Évalué à 6.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 12:27. (lien). Évalué à 0.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".
-
[^]Re: Euh ...
Posté par Nicolas Boulay () le 10/03/2006 à 12:31. (lien). Évalué à 5.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 12:53. (lien). Évalué à 0.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 ? :)-
[^]Re: Euh ...
Posté par Nicolas Boulay () le 10/03/2006 à 13:06. (lien). Évalué à 5.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 13:15. (lien). Évalué à 1.Puisque tu tiens à troller, pourve moi ce que tu affirmes et trouve moi brevet de l'ensemble des APIs
-
[^]Re: Euh ...
Posté par Nicolas Boulay () le 10/03/2006 à 13:22. (lien). Évalué à 3.On te l'a déjà montré 10 fois.
-
[^]Re: Euh ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 13:36. (lien). Évalué à 0.Je l'ai toujours pas vu. Il est où ?
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 11/03/2006 à 15:41. (lien). Évalué à 1.Là
https://linuxfr.org/comments/673971,1.html
là
https://linuxfr.org/comments/674008,1.html
et un peu partout autour...-
[^]Re: Euh ...
Posté par TImaniac (page perso, ) le 11/03/2006 à 17:50. (lien). Évalué à 1.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é).
-
-
-
-
-
-
[^]Re: Euh ...
Posté par imalip (page perso, ) le 10/03/2006 à 13:24. (lien). Évalué à 5.de toute façon ce langage n'invente strictement rien.
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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 13:38. (lien). Évalué à 2.Ben c'est la nature même d'un brevet, protéger une invention.
-
[^]Re: Euh ...
-
-
-
-
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 12:42. (lien). Évalué à 2.Avant de demander, il faut étudier s'il on peut demander....
-
[^]Re: Euh ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 12:57. (lien). Évalué à 5.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...
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 13:13. (lien). Évalué à 4.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 13:21. (lien). Évalué à 2.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.
-
[^]Re: Euh ...
Posté par Nicolas Boulay () le 10/03/2006 à 14:02. (lien). Évalué à 5.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 ...
Posté par Antoine () le 10/03/2006 à 17:13. (lien). Évalué à 3.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 ...
Posté par Philip Marlowe (Jabber id, ) le 10/03/2006 à 17:41. (lien). Évalué à 3.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 ...
Posté par Sytoka Modon (page perso, ) le 11/03/2006 à 10:27. (lien). Évalué à 8.> 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 ...
Posté par Ontologia (page perso, ) le 11/03/2006 à 11:26. (lien). Évalué à 4.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 ...
Posté par Sytoka Modon (page perso, ) le 11/03/2006 à 14:47. (lien). Évalué à 5.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 ...
Posté par Ontologia (page perso, ) le 11/03/2006 à 15:35. (lien). Évalué à 2.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 ...
Posté par Sytoka Modon (page perso, ) le 12/03/2006 à 07:51. (lien). Évalué à 4.> 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 ...
Posté par Sytoka Modon (page perso, ) le 12/03/2006 à 08:03. (lien). Évalué à 2.> 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 ...
Posté par jcs (page perso, ) le 11/03/2006 à 15:59. (lien). Évalué à 2.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-
[^]Re: Euh ...
Posté par Sytoka Modon (page perso, ) le 12/03/2006 à 09:08. (lien). Évalué à 2.> 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 ...
Posté par Pierre Jarillon (page perso, ) le 10/03/2006 à 19:40. (lien). Évalué à 10.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 ...
Posté par Pierre Jarillon (page perso, ) le 10/03/2006 à 20:44. (lien). Évalué à 5.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 ...
Posté par Arnaud (page perso, ) le 09/03/2006 à 21:39. (lien). Évalué à 4.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 ...
Posté par Nicolas Boulay () le 09/03/2006 à 21:45. (lien). Évalué à 2.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 ...
Posté par Troy McClure (page perso, ) le 09/03/2006 à 21:53. (lien). Évalué à 10.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 ...
Posté par Nicolas Boulay () le 09/03/2006 à 21:57. (lien). Évalué à 4.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 ...
Posté par Gael Tessier (page perso, ) le 09/03/2006 à 22:59. (lien). Évalué à 2."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 ...
Posté par reno () le 10/03/2006 à 07:08. (lien). Évalué à -1.> 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 ...
Posté par gaaaaaAab () le 10/03/2006 à 14:47. (lien). Évalué à 3.tu veux dire que tu n'as jamais accidentellement fait une affectation en lieu et place d'un test ?
-
[^]Re: Euh ...
Posté par reno () le 10/03/2006 à 16:20. (lien). Évalué à 4.> 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 ...
-
[^]Re: Euh ...
Posté par Julien () le 11/03/2006 à 18:25. (lien). Évalué à 1.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 ...
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 11/03/2006 à 19:52. (lien). Évalué à 3.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 ...
Posté par Antoine () le 10/03/2006 à 17:16. (lien). Évalué à 4.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 ...
Posté par Lionel Draghi (page perso, ) le 10/03/2006 à 23:43. (lien). Évalué à 5.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 ...
Posté par Mildred (Jabber id, page perso, ) le 10/03/2006 à 22:48. (lien). Évalué à 4.en même temps smalltalk aussi n'a que 4 mot clefs ... c'est d'ailleurs une caractéristique que j'aprécie beaucoup...
-
-
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 00:08. (lien). Évalué à 2.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
GUI_BUTTON.create_in INTERFACE at 120,90 size 80,20 label "Hello !" action self;
à
GUI_BUTTON.create_in(INTERFACE,120,90,80,20,"Hello !",this);
C'est beaucoup plus clair, à mon humble avis.-
[^]Re: Euh ...
Posté par Jb Evain (page perso, ) le 10/03/2006 à 00:17. (lien). Évalué à 10.Ce qu'il y a d'affreux ? Les mascules, j'ai horreur d'avoir l'impression que le code me gueule dessus.
-
[^]Re: Euh ...
Posté par Troy McClure (page perso, ) le 10/03/2006 à 08:52. (lien). Évalué à 7.et puis les majuscules partout ça rappelle trop le FORTRAN77, pas idéal pour le langage du troisième millénaire :)
-
[^]Re: Euh ...
Posté par Arthur Accroc () le 10/03/2006 à 21:22. (lien). Évalué à 1.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.
-
-
-
[^]Re: Euh ...
Posté par reno () le 10/03/2006 à 07:11. (lien). Évalué à 3.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 ...
Posté par Arthur Accroc () le 10/03/2006 à 22:25. (lien). Évalué à 1.Oui enfin le passage de parametre par nom plutot que par position n'est pas une nouveauté: Ada, Python, etc..
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.-
[^]Re: Euh ...
Posté par Sytoka Modon (page perso, ) le 11/03/2006 à 09:41. (lien). Évalué à 3.D'ailleurs, en ObjectiveC, la solution est superbe.
-
[^]Re: Euh ...
Posté par golum () le 12/03/2006 à 17:02. (lien). Évalué à 4.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 ...
Posté par Arthur Accroc () le 13/03/2006 à 00:33. (lien). Évalué à 2.Quand les developpeurs veulent bien se donner la peine d'expliciter les paramètres.
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 !
-
-
-
-
-
-
[^]Re: Euh ...
Posté par snt () le 09/03/2006 à 22:24. (lien). Évalué à 4.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 ...
Posté par Nicolas Boulay () le 09/03/2006 à 22:55. (lien). Évalué à 1.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 ...
Posté par drmad () le 09/03/2006 à 23:39. (lien). Évalué à 1.>> 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 ...
Posté par pasBill pasGates () le 10/03/2006 à 01:39. (lien). Évalué à 5.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 ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 08:29. (lien). Évalué à 3.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 13:41. (lien). Évalué à 6.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.
-
[^]Re: Euh ...
Posté par Antoine () le 10/03/2006 à 17:18. (lien). Évalué à 2.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 17:27. (lien). Évalué à 4.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.-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 17:41. (lien). Évalué à 2.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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 18:07. (lien). Évalué à 2.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 :)-
[^]Re: Euh ...
Posté par agmk () le 10/03/2006 à 19:12. (lien). Évalué à 5.>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 ...
Posté par TImaniac (page perso, ) le 10/03/2006 à 23:06. (lien). Évalué à 4.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.
-
-
[^]Re: Euh ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 19:27. (lien). Évalué à 2.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 ...
Posté par Nicolas Boulay () le 12/03/2006 à 22:12. (lien). Évalué à 3.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 ...
Posté par Dring FirebirdVsMySql () le 10/03/2006 à 09:24. (lien). Évalué à 3.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 ...
Posté par Charles-Victor DUCOLLET () le 10/03/2006 à 08:30. (lien). Évalué à -1.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 ...
Posté par louis perrier () le 10/03/2006 à 10:11. (lien). Évalué à 5.as tu déja utilisé eclipse plus de 10 minutes ?
-
[^]Re: Euh ...
Posté par Guillaume Knispel () le 23/03/2006 à 21:50. (lien). Évalué à 2.faut mieux utiliser eclipse plus de 10 min si on veut lui donner le temps de se lancer :p
-
-
-
[^]Re: Euh ...
Posté par ouah (page perso, ) le 10/03/2006 à 10:33. (lien). Évalué à 1.> 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 ...
Posté par Ontologia (page perso, ) le 10/03/2006 à 10:59. (lien). Évalué à 1.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 ...
Posté par Antoine () le 10/03/2006 à 17:20. (lien). É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 (page perso, ) le 10/03/2006 à 17:37. (lien). Évalué à 2.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 ...
Posté par Antoine () le 11/03/2006 à 17:17. (lien). Évalué à 5.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 ...
Posté par Thomas Douillard () le 11/03/2006 à 18:06. (lien). Évalué à 4.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 ...
Posté par TImaniac (page perso, ) le 12/03/2006 à 12:27. (lien). Évalué à 4.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.-
[^]Re: Euh ...
Posté par Julien () le 12/03/2006 à 15:47. (lien). Évalué à 5.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
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.
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 fon
-
-
-
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.