ok mais c'est quoi que vous voulez prouver au final : le langage (et son compilo) ok, mais les programmes écrits en Lisaac ? Il y aura une transformation en B ? Comment va-t-on rédiger les contrats "ala" B ?
Effectivement ca ajoute une dépendance à gcc, ca se tient.
les problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
Je ne connais que la méthode B dans le domaine, mais j'ai un peu l'impression que le B est à des années lumières de Lisaac (au niveau de la grammaire)... Vous avez tout de même les mêmes objectifs ?
Je continue cependant à croire que le C empêche un certain nombre d'optimisation. Je veux bien croire que Lisaac n'a pas cet objectif d'effectuer des optimisations locales. Cependant je penses qu'il y a un juste milieu pour conserver l'abstraction apportée par gcc vis-à-vis du matos sans perdre une parti des perfs à cause des hypothèses suggérées par la grammaire du C : faire un front-end à gcc. Vous évitez ainsi de passer par le C et vous cibler directement le langage intermédiaire de gcc puis utilisez son backend pour produire du code compilé sur une multitude plateformes.
Gcc a été conçu pour cela, son architecture est prête pour acceuillir de nouvaux langages sans passer par le C. Je sais pas si c'est faisable et si vous avez déjà envisagez cela mais ca mérite d'être regardé.
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
Arrête de me prendre pour un con comme tu dis si bien. Je comprend tout à fait l'intérêt d'un langage de haut niveau, c'est d'ailleur pour ca que j'évite dès que possible de code en C. Mais tu réponds toujours pas à ma question : pourquoi ne cherchez vous pas à "zapper" le C pour produire vous même du code machine, vous autorisant encore plus d'optimisations et vous aidant à "dépasser" les perfs du C ?
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
Je l'ai lu mais je vois pas pourquoi tu me parles de ca : j'ai jamais dis qu'en Lisaac on pouvait pas écrire un OS ou un driver. J'ai jamais remis en cause les fonctionnalités de Lisaac, ca va naturellement dans votre ambition de remplacer le C.
Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
Là encore j'ai l'impression que tu lis un mot sur 2 : quand je parle des peformances du compilateur, je parle pas des perfs du programme compilé ! C'est toi qui a parlé de temps de compilation exponentiel il me semble... C'est ça que j'appelle un gros problème.
on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
Ben je me fies uniquement à ton exponentielle, si pour 60000 lignes de codes il faut 30 secondes, pour le double de lignes il faut déjà un temps très long, et pour le triple et le quadruple c'est imbittable. Ou alors tu dis n'importe quoi en parlant l'exponentiel, ce que j'espère pour Lisaac.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
Ben non je connais pas comme je viens de le lire, j'en connais que la présentation que vous en faites sur votre site. Tant mieux pour toi si t'en connais plus.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Je viens de dire que je m'étais bien gardé de débattre sur ce que je ne connaissais pas... Enfin moi j'ai du mal à comprendre comment tu peux débattre des langages sans même comprendre de quoi je parle quand je te pointe un article sur les méthodes virtuelles... C'est un petit peu la base de beaucoup de langages objets actuels...
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
Que veux tu qu'on face d'une lib libre ou même d'un OS libre ? Toute la partie intéressante et indispensable au reste (compilation de prototype et optimisation globale dans le compilo) sont dans ce qui est fermé !
avec des fonctionalitées bas niveau.
Je vois bien l'intérêt, mais j'ai quand même une question : en C on doit parfois faire appel à de l'assembleur pour faire mumuse avec du matériel particulier (notamment quand on écrit un OS)... Vous faites comment en Lisaac ?
Moi j'essayais de m'intéresser au langage, j'essayais de voir s'il pouvait "prétendre" remplacer le C. Désolé d'y chercher ce que je trouve dans les autres langages industriels, le C n'étant pas un langage de recherche. J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications. J'en ai eu certaines : le langage compte bien être "industrialisé", mais il y a de gros problème de performance du compilateur.
Moi j'ai peur que ce langage n'est aucun avenir parcqu'il ne prend pas en compte les attentes des utilisateurs, visiblement il sert surtout à faire plaisirs à certains chercheurs. Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
Mon attitude n'a été que dirigé que par la "prétention" de la news. On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non. Quand à mon ton, désolé mais moi je n'ai pas dit que mon interlocuteur prenait les programmeurs "pour des cons !" (citation).
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Enfin quand je vois un commentaire noté pertinent quand il ne fait que dire "je ne suis pas d'accord" sans argumenté, je me demandes vraiment si vous n'acceptez tout simplement la critique, moi j'ai essayé de poser les bonnes questions (désolé si elles fachent ou si vous vous sentez agressez c'était pas le but), c'est vos réponses qui les ont rendues non constructives. Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Tu ne fait que vendre un service à l'entreprise; le jour ou elle n'a plus besoin de ce service, elle te licencie : tu fais la même chose avec tes commercants.
La différence c'est que le commreçant c'est son "boulot" de trouver des clients (et d'en perdre). S'il perd un client, il peut en retrouver un autre. Moi si du jour au lendemain je perd mon emploi c'est la moitié des ressources de mon foyer qui s'en va. Mais j'ai toujours les mêmes charges derrière.
Les entreprises doivent être au service des hommes, pas l'inverse. Et pas seulement des actionnaires comme tu le sembles vouloir nous faire comprendre ("on est les patrons").
Si pour toi il est plus important de refiler des dividendes aux actionnaires que de sauvegarder un ou plusieurs emploi, tu nous montre à quel point le modèle capitaliste est une magnifique preuve d'humanité.
Désolé, je sui pas d'accord.
Cool :) Mais encore ? Il y a des langages comme OCaml
C'est un point de vue que tout le monde ne partage pas.
Peut être, mais dans l'industrie où les éditeurs répondent aux besoins des développeurs, on retrouve aujourd'hui la boucle foreach (ou similaire) en : C++ , Java, C#, Python, Ruby. Là encore t'as le droit de ne pas être d'accord, mais tu peux comprendre que dans la vraie vie c'est ce qui se passe.
Je me dit que tu ne comprend pas tout ce que tu critique: Le virtual absolument rien a voir avec le final.
Non c'est clair ca n'a strictement rien à voir : une méthode "finale" ne peut être réécrite alors qu'une méthode "virtuelle" peut être réécrite. Le mot clé final fait passer une méthode de "virtuelle" à finale en Java, mais bien sûr ca n'a rien à voir, c'est complètement dissocié c'est évident. T'as lu le lien que j'ai posté ?
ce n'est pas sale de faire des macros comme en C++ car elle sont bcp plus puissante
Je critique pas la "beauté" de l'implémentation dans le langage, je critique l'utilisation qui en est faite : certains sont même allé jusqu'à redéfinir une syntaxe à la Lisp en C++, si c'est pas montré jusqu'où les macros peuvent dénaturer le langage...
Et biens paix a l'âme de .Net (et de Mono) : une méme plateforme pour tout les langages ....
Tous les langages subissent des contraintes en passant à .NET : ils doivent être objet, avoir un héritage simple, berf utiliser le modèle de la plateforme. Certains de ces langages sont "retravaillés" pour coller à .NET comme le C++ pour en exploiter toutes les possibilités.
Et forcé de constater qu'on perd une partie de la philosophie d'un langage quand tout à coup on utilise un ensemble totalement différent de bibliothèques...
Franchement t'es gentil avec ton post visiblement plus pertinent que le mien mais à part dire "je suis pas d'accord", me dire que les macros c'est sale ou encore argumenter à coup de "..." je vois pas l'intérêt de ton intervention.
Qu'en sais-tu ?
Ben j'en sais les benchs que vous donnez...
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
L'un empêche pas l'autre. Tout est bon pour contribuer à la qualité.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" : http://www.artima.com/intv/nonvirtual.html
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Ben moi je penses pas que c'est indépendant. C'était indépendant y'a 20 ans, mais à sens aujourd'hui le langage est intrinséquement lié à la plateforme d'exécution et inversement.
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
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 simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
trop de constructions dans le langage ==> trop de manière d'écrire le même code,
Evidemment, ne pas proposer des constructions redondantes mais des constructions "standardisant" la rédaction des patterns courants pour simplifier la rédaction et la relecture. Perl c'était visiblement pas les mêmes objectifs ;)
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é.
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.
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é).
Même si ce que tu racontes était vrai
j'ai dis "théoriquement". C'est évident que dans la pratique le programmeur n'écrira pas tout ca. Mais je constate qu'au final le langage n'apporte pas l'intérêt qu'il prétend avoir puisque dans leur unique bench le langage est légèrement plus lent que le C. Le langage et le compilateur semble sortir l'artillerie lourde question optimisation, mais j'ai l'impression que tout est perdu à cause de 2 choix :
- sortir du C plutôt que de sortir du code optimisé pour processeur.
- limiter le nombre de construction intégrées à la grammaire (et donc optimisables à souhait).
Enfin je pense que le premier choix peut évoluer. Par contre le 2ème j'ai beaucoup plus de mal. L'intérêt d'un langage de haut niveau, c'est d'exprimer des concepts d'une manière plus abstraite pour apporter un maximum d'informations (de "sens" comme dis plus haut) au compilateur pour qu'il fasse le travail le plus intelligent possible.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau
En fait j'ai vraiment du mal à voir ce que Lisaac apporte par rapport au C pour le code bas-niveau puisqu'on gagne rien en perf (d'après leur bench), donc je suppose qu'il peut aussi rivaliser avec les autres langages de haut nivaeu plus polyvalant. Visiblement tu me dis que non :) Ben je vois toujours pas l'intérêt de Lisaac du coup :)
le compilateur connaît plus de choses sur le "sens" des instructions que le compilateur de C.
C'est exactement ce que j'expliquais plus bas dans mon commentaire : les instructions du langages ont un sens particulier et permettent au compilateur de langages de haut niveau de procéder à des optimisations particulières. C'est pour ca que je disais avoir une grammaire ultra-simple sans les constructions minimum n'est pas vraiment aidant question optimisation, au contraire, ces instructions permettent bien plus d'optimisation. Donc on est bien d'accord :)
Moi je disais juste que c'est dommage de chercher à faire un langage de haut niveau puissant question optimisation si c'est pour produire du C au final : on va comme tu dis perdre un grand nombre de possibilités d'optimisation sur le code final, vu qu'on sera limité au sens du langage C.
Comment faire un langage plus rapide que C ?
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
D'ailleur au final votre benchmark MPEG2 le prouve, LISAAC est légèrement plus lent.
Pour aller plus vite que le C, faut commencer par le "sqeezer", c'est-à-dire produire directement du code machine, sinon Lisaac sera toujours limité aux contraintes sémantiques imposées par le C, contraintes qui empêche certaines optimisations possible dans d'autres langages.
Premier point : Le minimalisme du code.
Pas toujours vrai. Imposer des constructions de boucle ou de tableau dans le langage avec une sémantique précise permet au compilateur de faire des hypothèses valides supplémentaire. En fait la plupart des constructions qui sont intégrées au langage permettent au langage de faire des hypothèses valides et donc des optimisations supplémentaires.
Second point : La suppression de la liaison dynamique
Je veux bien moi, mais bon c'est plus un problème des langages objets que du C qui est ici le sujet :)
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
Eh bé :)
Maintenant dans la série "comment...", "Comment faire un langage qui remplace les langages objets actuels ?"
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
- Se focaliser sur la productivité et l'agréable.
Pour cela, il faut faire à la place du programmeur tout ce qui est trop techniques et lui fait perdre du temps sur des détails qui n'ont pas grand chose à voir avec l'objectif du programmeur : faire un programme qui répond à un besoin et des objectifs.
Pour cela :
- gérer la mémoire pour éviter toutes fuites mémoires et autres erreurs grossières d'accès mémoires
- proposer des types "primitifs" en "standard" dans la grammaire du langage (entier, flottant, chaîne de caractère, etc.) et des constructions "standards" (conditionnel, boucle) sans autre alternative : c'est une façon d'imposer un style de rédaction et d'écriture d'algorithme, avec comme objectif : se faire comprendre des autres programmeurs, et donc gagner du temps en maintenance, en relecture, en test, etc. Bref, avoir un dictionnaire de référence pour que tout le monde parle la même langue et se comprenne. Rien de plus frustrant de tomber sur des macros imbittable en C++, ou des types string personnalisés
- proposer un grand nombre de bibliothèque en "standard" implémentant les problèmes les plus courant. Ceci toujours dans la même idée d'éviter que chacun réinvente une roue au comportement pas forcement identique à celle du collègue programmeur. On retrouvera bien entendu dans ces bibliothèques l'accès au système de fichier mais aussi tout ce qui touche aux "communications" comme un mécanisme d'appel d'objet/procédure distant, des implémentations de standards courants comme XML, HTTP et les sockets, toujours dans le but de "standardiser" les moyens de communications entre application et donc éviter de se prendre le "choux" à faire communiquer 2 briques logiciels qui utilisent des implémentations différentes (et jamais parfaites) parfois de protocoles identiques.
On retrouvera également dans ces bibliothèques des types "standards" comme les collections ou les types exprimants le temps, toujours dans cet objectif d'avoir une représentation commune des structures les plus courantes, et ainsi grandement simplifier la réutilisation de code existant.
De la même manière on retrouvera des mécanismes de persistances (BDD, sérialisation automatique, etc.).
- la gestion de version : une brique logicielle évolue, et pour être réutilisée dans un cadre précis, il faut savoir identifier une version précise de la brique, mais aussi des types qui la compose voir des fonctions.
- un mécanisme de reflexion pour faciliter la programmation à un niveau supérieur mais aussi faciliter l'analyse et la vérification de code.
- une sécurisation de l'espace mémoire avec un mécanisme d'isolation empêchant un processus de faire s'écrouler d'autres processus.
Reste un dernier point qui n'est pas "obligatoire" :
- poser une couche d'abstraction vis-à-vis du matériel. C'est un gros avantage, mais il peut limiter la construction de logiciels utilisation du matériel justement :)
J'oublies sûrement plein de trucs, mais si un langage veut s'imposer il doit "réfléchir" à tous ces points et ne pas s'occuper uniquement de sa grammaire mais de son environnement complet : environnement d'exécution et bibliothèques proposées en standard.
Un point important à considérer également :
- faciliter la programmation multi-thread pour la rendre intuitive au programmeur.
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.
Ben, d'après mon Wikipedia ca date exactement du 30 décembre 1996 : http://en.wikipedia.org/wiki/Microsoft_Office "Office 8.0/'97 (Word '97, etc.) - released December 30, 1996 (was published on CD-ROM as well as on a set of 45 3½-inch floppy disks)"
Mais bon visiblement ton wikipedia semble plus pertinent que le mien ;)
et pour répondre au commentaire suivant je non je n'ai pas plus accès au betas que monsieur tout le monde, et je vois pas ce que j'en ferais sur mon PC équipé uniquement d'une Ubuntu.
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 :)
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.
Il faut tout de même préciser que la suite MS Office, niveau travail collaboratif, ne vaut rien de plus que OpenOffice sans le serveur MS Exchange
Oué c'est d'ailleur pour ca que MS Exchange fait parti de la gamme MS Office System :-p
MS Office c'est des applis, des serveurs et des services, c'est pas juste l'équivalent des applis qu'on trouve dans OOo : http://www.microsoft.com/france/office/system/applications/d(...)
C'est pas demain la veille qu'on aura tout ca d'intégré dans une même suite libre. C'est d'ailleur le pourquoi de la remarque du marketeux de Microsoft sur l''écart entre les préoccupation d'hier et celle d'aujourd'hui. OOo c'est une suite de bureautique "personnelle" comme l'était Office 97. Depuis chez MS ils sont passés à une suite complète pour les entreprises. Cela dit ca touche baeucoup moins de monde et pour le grand publique Office 2003 n'apporte quasiment rien par rapport à OOo.
ben voici leur présentation d'Office : "Microsoft Office est passé d'une suite de produits de productivité personnelle à un système intégré plus complet. Construit sur des outils connus de tous, Microsoft Office System inclut des applications de bureau, des serveurs et des services. En fonctionnant ensemble, ils répondent à la plupart des problèmes posés en entreprise. "
Maintenant celle de Outlook : Office Outlook 2003 fournit une solution intégrée pour la gestion et l'organisation des messages électroniques, des planifications, des tâches, des notes, des contacts et d'autres informations. Office Outlook 2003 fournit des innovations que vous pouvez utiliser pour gérer vos communications, organiser votre travail et collaborer plus efficacement, tout ceci de manière centralisée.
Voilà peut être pourquoi le 2ème est logiquement intégré dans le premier.
Y'a aussi Outlook qui fait parti de MS Office et qui n'a pas d"équivalent dans la suite OOo et qui concerne "beaucoup" de monde, notamment en entreprise.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
les problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
Je ne connais que la méthode B dans le domaine, mais j'ai un peu l'impression que le B est à des années lumières de Lisaac (au niveau de la grammaire)... Vous avez tout de même les mêmes objectifs ?
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Gcc a été conçu pour cela, son architecture est prête pour acceuillir de nouvaux langages sans passer par le C. Je sais pas si c'est faisable et si vous avez déjà envisagez cela mais ca mérite d'être regardé.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Arrête de me prendre pour un con comme tu dis si bien. Je comprend tout à fait l'intérêt d'un langage de haut niveau, c'est d'ailleur pour ca que j'évite dès que possible de code en C. Mais tu réponds toujours pas à ma question : pourquoi ne cherchez vous pas à "zapper" le C pour produire vous même du code machine, vous autorisant encore plus d'optimisations et vous aidant à "dépasser" les perfs du C ?
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Je l'ai lu mais je vois pas pourquoi tu me parles de ca : j'ai jamais dis qu'en Lisaac on pouvait pas écrire un OS ou un driver. J'ai jamais remis en cause les fonctionnalités de Lisaac, ca va naturellement dans votre ambition de remplacer le C.
Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
Là encore j'ai l'impression que tu lis un mot sur 2 : quand je parle des peformances du compilateur, je parle pas des perfs du programme compilé ! C'est toi qui a parlé de temps de compilation exponentiel il me semble... C'est ça que j'appelle un gros problème.
on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
Ben je me fies uniquement à ton exponentielle, si pour 60000 lignes de codes il faut 30 secondes, pour le double de lignes il faut déjà un temps très long, et pour le triple et le quadruple c'est imbittable. Ou alors tu dis n'importe quoi en parlant l'exponentiel, ce que j'espère pour Lisaac.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
Ben non je connais pas comme je viens de le lire, j'en connais que la présentation que vous en faites sur votre site. Tant mieux pour toi si t'en connais plus.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Je viens de dire que je m'étais bien gardé de débattre sur ce que je ne connaissais pas... Enfin moi j'ai du mal à comprendre comment tu peux débattre des langages sans même comprendre de quoi je parle quand je te pointe un article sur les méthodes virtuelles... C'est un petit peu la base de beaucoup de langages objets actuels...
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
Que veux tu qu'on face d'une lib libre ou même d'un OS libre ? Toute la partie intéressante et indispensable au reste (compilation de prototype et optimisation globale dans le compilo) sont dans ce qui est fermé !
avec des fonctionalitées bas niveau.
Je vois bien l'intérêt, mais j'ai quand même une question : en C on doit parfois faire appel à de l'assembleur pour faire mumuse avec du matériel particulier (notamment quand on écrit un OS)... Vous faites comment en Lisaac ?
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à -1.
Moi j'ai peur que ce langage n'est aucun avenir parcqu'il ne prend pas en compte les attentes des utilisateurs, visiblement il sert surtout à faire plaisirs à certains chercheurs. Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
Mon attitude n'a été que dirigé que par la "prétention" de la news. On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non. Quand à mon ton, désolé mais moi je n'ai pas dit que mon interlocuteur prenait les programmeurs "pour des cons !" (citation).
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Enfin quand je vois un commentaire noté pertinent quand il ne fait que dire "je ne suis pas d'accord" sans argumenté, je me demandes vraiment si vous n'acceptez tout simplement la critique, moi j'ai essayé de poser les bonnes questions (désolé si elles fachent ou si vous vous sentez agressez c'était pas le but), c'est vos réponses qui les ont rendues non constructives. Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
[^] # Re: pff
Posté par TImaniac (site web personnel) . En réponse au journal Ça chie pour Mandriva. Évalué à 1.
La différence c'est que le commreçant c'est son "boulot" de trouver des clients (et d'en perdre). S'il perd un client, il peut en retrouver un autre. Moi si du jour au lendemain je perd mon emploi c'est la moitié des ressources de mon foyer qui s'en va. Mais j'ai toujours les mêmes charges derrière.
Les entreprises doivent être au service des hommes, pas l'inverse. Et pas seulement des actionnaires comme tu le sembles vouloir nous faire comprendre ("on est les patrons").
Si pour toi il est plus important de refiler des dividendes aux actionnaires que de sauvegarder un ou plusieurs emploi, tu nous montre à quel point le modèle capitaliste est une magnifique preuve d'humanité.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 0.
Cool :) Mais encore ? Il y a des langages comme OCaml
C'est un point de vue que tout le monde ne partage pas.
Peut être, mais dans l'industrie où les éditeurs répondent aux besoins des développeurs, on retrouve aujourd'hui la boucle foreach (ou similaire) en : C++ , Java, C#, Python, Ruby. Là encore t'as le droit de ne pas être d'accord, mais tu peux comprendre que dans la vraie vie c'est ce qui se passe.
Je me dit que tu ne comprend pas tout ce que tu critique: Le virtual absolument rien a voir avec le final.
Non c'est clair ca n'a strictement rien à voir : une méthode "finale" ne peut être réécrite alors qu'une méthode "virtuelle" peut être réécrite. Le mot clé final fait passer une méthode de "virtuelle" à finale en Java, mais bien sûr ca n'a rien à voir, c'est complètement dissocié c'est évident. T'as lu le lien que j'ai posté ?
ce n'est pas sale de faire des macros comme en C++ car elle sont bcp plus puissante
Je critique pas la "beauté" de l'implémentation dans le langage, je critique l'utilisation qui en est faite : certains sont même allé jusqu'à redéfinir une syntaxe à la Lisp en C++, si c'est pas montré jusqu'où les macros peuvent dénaturer le langage...
Et biens paix a l'âme de .Net (et de Mono) : une méme plateforme pour tout les langages ....
Tous les langages subissent des contraintes en passant à .NET : ils doivent être objet, avoir un héritage simple, berf utiliser le modèle de la plateforme. Certains de ces langages sont "retravaillés" pour coller à .NET comme le C++ pour en exploiter toutes les possibilités.
Et forcé de constater qu'on perd une partie de la philosophie d'un langage quand tout à coup on utilise un ensemble totalement différent de bibliothèques...
Franchement t'es gentil avec ton post visiblement plus pertinent que le mien mais à part dire "je suis pas d'accord", me dire que les macros c'est sale ou encore argumenter à coup de "..." je vois pas l'intérêt de ton intervention.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
Ben j'en sais les benchs que vous donnez...
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
L'un empêche pas l'autre. Tout est bon pour contribuer à la qualité.
Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il manque quelque confort pour la chose c'est un détail qui se règle en quelques heures au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" :
http://www.artima.com/intv/nonvirtual.html
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Ben moi je penses pas que c'est indépendant. C'était indépendant y'a 20 ans, mais à sens aujourd'hui le langage est intrinséquement lié à la plateforme d'exécution et inversement.
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Et pourtant ... la bibliothèque standard C++ fournit différent mécanismes pour simplifier l'écriture de boucle dans l'en-tête (for_each & co).
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
Je n'aime pas non plus cette philosophie (qu'on retrouve par exemple dans java)
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
e lui fournir la possibilité de ne faire que des choses sans danger.
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Si le compilateur génère du C, je pense qu'il n'est certainement pas très compliqué d'ajouter la possibilité d'insérer des appels de fonction C qui ne doivent pas être traduits.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Tu cherches vraiment la petite bête. On te dis "un nouveau langage est créé avec une nouvelle manière de penser" tu réponds "
Ah non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
Je pense que la plupart de tes problèmes avec le langage viennent de ce que tu attends autre chose que ce que fournit le langage.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
Evidemment, ne pas proposer des constructions redondantes mais des constructions "standardisant" la rédaction des patterns courants pour simplifier la rédaction et la relecture. Perl c'était visiblement pas les mêmes objectifs ;)
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Ben l'à priori avec lequel je suis parti c'est : "tiens, un nouveau langage bien prétentieux". Ben oui il va "sans doute" remplacer le C c'est marqué. Donc je me dis qu'il doit être sacrément bien foutu et doit constitué un espèce de "state of art" de ce qui se fait en matière de langage, parcque pour déboulonner le C quand même...
Au début je me suis contenter de poser quelques questions sur le pourquoi le langage est génial. Ontologia a répondu à plusieurs reprises et si j'interprête correctement ses propos les points forts du langage sont :
- une grammaire simplissime, c'est paraît-il mieux pour les optimisations globales. Oui mais : au final c'est pas plus rapide que le C, donc première déception. Donc l'intérêt est pour moi limité.
- la possibilité de faire ses propres instructions d'itération & co : comme l'a dit quelqu'un ca ressemble beaucoup à de la masturbation intellectuelle qu'à autre chose. De ma petite expérience de programmation, c'est déjà assez affreux d'avoir à relire les macros C++ d'un collègue, alors si en plus je lui laisse la possibilité de fabriquer sa propre boucle for... Bref, pour moi ca n'a strictement aucun intérêt, c'est comme si le langage français avait 10 mot dans sa grammaire et qu'on avait tous nos dialectes bien à nous pour parler. Personne se comprend.
- la programmation à base de prototypes plutôt que de classes. Là je sais pas trop quoi penser, faut que j'essai. Mais si c'est du même topo que le reste, voilà quoi.
- un langage qui veut remplacer le C et les langages de haut niveau (c'est pas moi qui le dit). Ben y'a pour moi de nombreuses langages aux plateformes beaucoup plus "sexy" avec d'impressionnantes bibliothèques. Je vois mal Lisaac s'imposer face aux Java/.NET/Python/Ruby/Perl&Co.
- un truc magique et révolutionnaire breveté dans le compilateur. C'est gentil mais bon en attendant on est face à un compilateur qui demande des ressources de compilation exponentielles qui doive le rendre inutilisable dans le monde industriel, et qui pond du code pas plus rapide que du C.
Moi ce que je constate, c'est que ce langage semble être un joli produit de la recherche mais qui semble ignorer totalement toutes les contraintes industrielles, c'est pourquoi j'ai un peu peur qu'il "pète un peu trop haut". Visiblement y'a des énormes points noir qui me semble pourtant tellement évident :
- pour un langage qui veut remplacer le C, il est pas capable de présenter des APIs "àla C" réutilisables dans d'autres langages. En gros j'ai bien l'impression que si l'OS est en Lisaac, tout le reste doit l'être aussi. Bref aucune réflexion sur la transition et l'intégration avec l'existant.
- un algorithme de compilation qui n'apporte rien en terme de performance par rapport au C, avec en bonus un algorithme exponentiel.
- pas de réflexion sur le versionning, la documentation du code ou encore la documentation sous forme de schéma : comment représente-on une modélisation visant ce langage ? UML est-il adapté ? Sinon y'a-t-il des outils ?
Alors moi ma question est :
- Pourquoi utiliser ce langage plutôt que le C ? Visiblement c'est pas une question de perf, c'est pas une question de productivité puisque l'interfacage avec le monde existant semble absent, la grammaire est pas spécialement élégante à lire, en tout cas pas plus qu'un autre langage...
Désolé mais 'étais "dubitatif" au départ, mais après ces quelques échanges je suis loin d'être convaincu de l'intérêt du langage.
Enfin j'attend de voir le côté révolutionnaire du compilateur, ce qui sera breveté.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
Maintenant les inconvénients :
- moins de constructions dans le langage ==> moins de contraintes sémantiques ==> moins d'optimisations possibles.
- moins de constructions dans le langage ==> moins de contraintes de programmation ==> trop de liberté ==> trop de manière d'écrire le même code, difficulté de relecture par un autre programmeur, difficulés de maintenance, bugs potentiels.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
on y trouve pas de brevet sur un API complet.
on y trouve une demande de brevet (grosse différence), et sur une partie des API (comme précisé par Boubou).
C'est vraiment du FUD gratuit que de prétendre que l'ensemble des API .NET est breveté (c'est pas l'ensemble, et rien n'indique que ca sera effectivement breveté).
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
j'ai dis "théoriquement". C'est évident que dans la pratique le programmeur n'écrira pas tout ca. Mais je constate qu'au final le langage n'apporte pas l'intérêt qu'il prétend avoir puisque dans leur unique bench le langage est légèrement plus lent que le C. Le langage et le compilateur semble sortir l'artillerie lourde question optimisation, mais j'ai l'impression que tout est perdu à cause de 2 choix :
- sortir du C plutôt que de sortir du code optimisé pour processeur.
- limiter le nombre de construction intégrées à la grammaire (et donc optimisables à souhait).
Enfin je pense que le premier choix peut évoluer. Par contre le 2ème j'ai beaucoup plus de mal. L'intérêt d'un langage de haut niveau, c'est d'exprimer des concepts d'une manière plus abstraite pour apporter un maximum d'informations (de "sens" comme dis plus haut) au compilateur pour qu'il fasse le travail le plus intelligent possible.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau
En fait j'ai vraiment du mal à voir ce que Lisaac apporte par rapport au C pour le code bas-niveau puisqu'on gagne rien en perf (d'après leur bench), donc je suppose qu'il peut aussi rivaliser avec les autres langages de haut nivaeu plus polyvalant. Visiblement tu me dis que non :) Ben je vois toujours pas l'intérêt de Lisaac du coup :)
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est exactement ce que j'expliquais plus bas dans mon commentaire : les instructions du langages ont un sens particulier et permettent au compilateur de langages de haut niveau de procéder à des optimisations particulières. C'est pour ca que je disais avoir une grammaire ultra-simple sans les constructions minimum n'est pas vraiment aidant question optimisation, au contraire, ces instructions permettent bien plus d'optimisation. Donc on est bien d'accord :)
Moi je disais juste que c'est dommage de chercher à faire un langage de haut niveau puissant question optimisation si c'est pour produire du C au final : on va comme tu dis perdre un grand nombre de possibilités d'optimisation sur le code final, vu qu'on sera limité au sens du langage C.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Enfin thoériquement un langage qui produit du C en sorti aura dû mal à être plus rapide, si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire.
D'ailleur au final votre benchmark MPEG2 le prouve, LISAAC est légèrement plus lent.
Pour aller plus vite que le C, faut commencer par le "sqeezer", c'est-à-dire produire directement du code machine, sinon Lisaac sera toujours limité aux contraintes sémantiques imposées par le C, contraintes qui empêche certaines optimisations possible dans d'autres langages.
Premier point : Le minimalisme du code.
Pas toujours vrai. Imposer des constructions de boucle ou de tableau dans le langage avec une sémantique précise permet au compilateur de faire des hypothèses valides supplémentaire. En fait la plupart des constructions qui sont intégrées au langage permettent au langage de faire des hypothèses valides et donc des optimisations supplémentaires.
Second point : La suppression de la liaison dynamique
Je veux bien moi, mais bon c'est plus un problème des langages objets que du C qui est ici le sujet :)
Le compilateur Lisaac réalise le graphe de l'ensemble du code, c'est pour cela que compiler 40 000 lignes (libraririe comprise) prend avec ce compilateur 512 Mo de mémoire.
Eh bé :)
Maintenant dans la série "comment...", "Comment faire un langage qui remplace les langages objets actuels ?"
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
- Se focaliser sur la productivité et l'agréable.
Pour cela, il faut faire à la place du programmeur tout ce qui est trop techniques et lui fait perdre du temps sur des détails qui n'ont pas grand chose à voir avec l'objectif du programmeur : faire un programme qui répond à un besoin et des objectifs.
Pour cela :
- gérer la mémoire pour éviter toutes fuites mémoires et autres erreurs grossières d'accès mémoires
- proposer des types "primitifs" en "standard" dans la grammaire du langage (entier, flottant, chaîne de caractère, etc.) et des constructions "standards" (conditionnel, boucle) sans autre alternative : c'est une façon d'imposer un style de rédaction et d'écriture d'algorithme, avec comme objectif : se faire comprendre des autres programmeurs, et donc gagner du temps en maintenance, en relecture, en test, etc. Bref, avoir un dictionnaire de référence pour que tout le monde parle la même langue et se comprenne. Rien de plus frustrant de tomber sur des macros imbittable en C++, ou des types string personnalisés
- proposer un grand nombre de bibliothèque en "standard" implémentant les problèmes les plus courant. Ceci toujours dans la même idée d'éviter que chacun réinvente une roue au comportement pas forcement identique à celle du collègue programmeur. On retrouvera bien entendu dans ces bibliothèques l'accès au système de fichier mais aussi tout ce qui touche aux "communications" comme un mécanisme d'appel d'objet/procédure distant, des implémentations de standards courants comme XML, HTTP et les sockets, toujours dans le but de "standardiser" les moyens de communications entre application et donc éviter de se prendre le "choux" à faire communiquer 2 briques logiciels qui utilisent des implémentations différentes (et jamais parfaites) parfois de protocoles identiques.
On retrouvera également dans ces bibliothèques des types "standards" comme les collections ou les types exprimants le temps, toujours dans cet objectif d'avoir une représentation commune des structures les plus courantes, et ainsi grandement simplifier la réutilisation de code existant.
De la même manière on retrouvera des mécanismes de persistances (BDD, sérialisation automatique, etc.).
- la gestion de version : une brique logicielle évolue, et pour être réutilisée dans un cadre précis, il faut savoir identifier une version précise de la brique, mais aussi des types qui la compose voir des fonctions.
- un mécanisme de reflexion pour faciliter la programmation à un niveau supérieur mais aussi faciliter l'analyse et la vérification de code.
- une sécurisation de l'espace mémoire avec un mécanisme d'isolation empêchant un processus de faire s'écrouler d'autres processus.
Reste un dernier point qui n'est pas "obligatoire" :
- poser une couche d'abstraction vis-à-vis du matériel. C'est un gros avantage, mais il peut limiter la construction de logiciels utilisation du matériel justement :)
J'oublies sûrement plein de trucs, mais si un langage veut s'imposer il doit "réfléchir" à tous ces points et ne pas s'occuper uniquement de sa grammaire mais de son environnement complet : environnement d'exécution et bibliothèques proposées en standard.
Un point important à considérer également :
- faciliter la programmation multi-thread pour la rendre intuitive au programmeur.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
- Parcque dans le langage C++ tel qu'il a été défini, std::string n'existait pas
- std::string est fourni dans une lib de templates recompilé systématiquement dans chaque programme qui les utilise, et donc parfois incompatible d'une bibliothèque à une autre suivant le compilateur/optimisation : bref pas forcement compatible binairement, et peut être trop facilement étendu/modifié par les programmeurs.
- parcque dans la pratique, le type CString (oui gnagnagna c'est pas bien je suis bien d'accord) est tout aussi "standard" (de fait).
Bref pour toutes ces raisons et par le simple constat que la std::string est loin d'être utilisé partout, c'est pas le standard.
Pour LISAAC, ca a l'avantage d'être présent dès le départ, dans la lib de base. Mais j'ai bien précisé qu'à mon sens il faut empêcher d'éventuelles modification, ou tout du moins ne pas faciliter cela, au risque de se retrouver avec la même situation complètement absurde du C++. (Désolé mais là j'ai dû jongler pendant un moment sur un projet où chaque développeur utilisait les string qu'il préférait, des CString au char * en passant par les w_char, les std::string, les MString, une perte de temps effroyable et des conversions incéssantes contre-performantes)
Bref, rien ne vaut le type string en natif dans le langage, comme mot clé, avec un API et une représentation binaire normalisée et standardisée.
[^] # Re: liens-utiles
Posté par TImaniac (site web personnel) . En réponse au journal OpenOffice 2 : Dix ans de retard. Évalué à 4.
http://en.wikipedia.org/wiki/Microsoft_Office
"Office 8.0/'97 (Word '97, etc.) - released December 30, 1996 (was published on CD-ROM as well as on a set of 45 3½-inch floppy disks)"
Mais bon visiblement ton wikipedia semble plus pertinent que le mien ;)
et pour répondre au commentaire suivant je non je n'ai pas plus accès au betas que monsieur tout le monde, et je vois pas ce que j'en ferais sur mon PC équipé uniquement d'une Ubuntu.
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
En LISAAC d'après ce que tu dis c'est pas en standard dans le langage , mais dans la bibliothèque "standard" qui l'accompagne, ce qui revient à peu prêt au même. C'est déjà très bien à partir du moment où ce "type" n'est pas modifiable et/ou extensible.
Pour les autres constructions (conditionnel, boucle) je trouve cela beaucoup moins "intéressant" : il y a fort à parier que cette possibilité soit utilisée pour construire de nouvelles instructions voir étendre ces instructions avec un comportement loin d'être "universel" : le risque, c'est de se retrouver avec un code "customisé" pour le développeur, qui flattera certe son ego, mais qui sera probablement imbittable par les autres développeurs. Bref pour la maintenant ca sera bonbon.
J'imagine même pas si C++ avait pas mis les if else for, c'est vrai on aurait pu tout faire avec les templates et les macros, mais mon dieu dans quel cauchemard serions-nous :)
[^] # Re: Euh ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
Enfin sinon il est clair qu'un type string natif est vital. Quand je code en C++ ca me lourde franchement d'avoir à gérer les char * les CString, les std::string sans parler des classes dérivées de std::string, véritables "mod" dont les développeurs sont fiers.
# fds
Posté par TImaniac (site web personnel) . En réponse au journal OpenOffice et MS Office, 10 ans de retard, mes explications. Évalué à 5.
Oué c'est d'ailleur pour ca que MS Exchange fait parti de la gamme MS Office System :-p
MS Office c'est des applis, des serveurs et des services, c'est pas juste l'équivalent des applis qu'on trouve dans OOo :
http://www.microsoft.com/france/office/system/applications/d(...)
C'est pas demain la veille qu'on aura tout ca d'intégré dans une même suite libre. C'est d'ailleur le pourquoi de la remarque du marketeux de Microsoft sur l''écart entre les préoccupation d'hier et celle d'aujourd'hui. OOo c'est une suite de bureautique "personnelle" comme l'était Office 97. Depuis chez MS ils sont passés à une suite complète pour les entreprises. Cela dit ca touche baeucoup moins de monde et pour le grand publique Office 2003 n'apporte quasiment rien par rapport à OOo.
[^] # Re: C'est pas faux.
Posté par TImaniac (site web personnel) . En réponse au journal OpenOffice 2 : Dix ans de retard. Évalué à 4.
http://www.microsoft.com/office/preview/uioverview.mspx
[^] # Re: C'est pas faux.
Posté par TImaniac (site web personnel) . En réponse au journal OpenOffice 2 : Dix ans de retard. Évalué à 3.
"Microsoft Office est passé d'une suite de produits de productivité personnelle à un système intégré plus complet. Construit sur des outils connus de tous, Microsoft Office System inclut des applications de bureau, des serveurs et des services. En fonctionnant ensemble, ils répondent à la plupart des problèmes posés en entreprise. "
Maintenant celle de Outlook :
Office Outlook 2003 fournit une solution intégrée pour la gestion et l'organisation des messages électroniques, des planifications, des tâches, des notes, des contacts et d'autres informations. Office Outlook 2003 fournit des innovations que vous pouvez utiliser pour gérer vos communications, organiser votre travail et collaborer plus efficacement, tout ceci de manière centralisée.
Voilà peut être pourquoi le 2ème est logiquement intégré dans le premier.
[^] # Re: C'est pas faux.
Posté par TImaniac (site web personnel) . En réponse au journal OpenOffice 2 : Dix ans de retard. Évalué à 3.