TImaniac a écrit 6420 commentaires

Une VM est définie par son jeu d'instruction. Un jeu d'instruction peut être représenter par un langage que l'on appelle langage d'assembleur. Ce n'est jamais qu'une question de représentation. Et le raisonnement inverse me paraît tout à fait valable : un langage défini une VM.
Cette dualité permet d'ailleur toutes les fantaisies : Je target Lisaac qui target le C qui target LLVM (qui a son langage d'assembleur qui défini son jeu d'instruction) qui target la JVM (qui a son langage de bytecode qui le défini) qui peut avoir pour target Mono (dans la VM est défini par le code IL) qui peut avoir pour target LLVM qui etc.

D'ailleur pour te montrer à quel point le C représente bien une machine virtuelle et non les instructions d'une machine physique, t'as qu'à utiliser GCC avec le backend LLVM... (c'est dans le nom), et hop, la VM interne de GCC (qui a toujours été là même avant LLVM) peut se voir utilisé par un moteur JIT.
Où comment faire du JIT avec Lisaac ;)

Question de point de vue.
Pour moi un langage s'assembleur représente les instructions machines sous une forme lisible.
Si le C est un assembleur pour Lisaac, cet assembleur représente des instructions machines... cette machine est une machine virtuelle, ce qui lui permet d'être portable.

Et y'a aucun simulateur pour ce type de matériel ???
On parle bien de micro-contrôleurs et autre processeurs qui sont "ciblables" avec GCC hein...

Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
Euh, le call on null ca serait pas fait par le JIT dans ce cas, mais par le compilateur en amont. De la même manière que c'est le compilateur Lisaac et pas GCC qui s'en occupe...

Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.

Cette limitation vient de l'implémentation de Mono, pas du modèle sous-jacent, le compilateur AOT de .NET n'a pas cette limitation.

Ensuite je vois pas pourquoi tu parles de ça...

De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
Garantie possible... uniquement si tu ne fait pas appel à des modules externes.

C'est impossible à faire sans analyse de flot, donc sans compilation globale.
Toutafé, on est d'accord. Les avantages sont indéniables, la question est de savoir si le jeu en vaut la chandelle au regard des inconvénients. Cela est d'autant plus bizzare vu la cible : embarqué, OS : jamais de code assembleur ? jamais de code externe ? jamais de drivers binaires ? Bref, combien de projet où le compilateur pourra vraiment offrir une garantie (ce qui suppose que tout soit codé en Lisaac et que toutes les sources soient compilées en même temps) ?

Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Bref, c'est donc bien possible. Comme déjà expliqué, la présence d'une VM n'implique pas JIT : on peut faire de l'AOT. Mais oui, niveau perf les services apportés par ces VM a souvent un impact négatif c'est clair.
Mais dans tout les cas ca reste tout à fait possible, CQFD.

ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus
Non non non et non. Une VM n'est pas un programme. Une VM c'est une machine virtuelle, une représentation abstraite sous la forme d'un jeu d'instruction d'une machine qui n'existe pas. C'est une confusion classique : on assimile une VM au runtime et son moteur JIT. Pourtant la technique AOT montre clairement que le bytecode est "lui compilé et le code machine ne bouge plus". C'est exactement pareil.

et surtout titanesque, de générer de l'assembleur.
Ok c'est bien un problème de moyen.

Maintenant moi j'ai une question : comment offrez-vous l'accès aux instructions spécifiques des processeurs modernes ? SSE & co ? Les unités de calculs vectorielles toussa ? En dehors des optimisations de base offertes par GCC, il est souvent très utile d'aller directement utiliser les instructions processeurs quand c'est vraiment les perfs que l'on recherche...

En résumé je trouve ce paradoxe assez étonnant : un des atouts de Lisaac, ce sont les perfs, et en même temps, vous limitez intrinséquement les perfs de Lisaac à la VM exposée par le langage C, autrement dit pas d'optimisation possible en dehors de cette VM... Lisaac est condamné à être aussi "lent" que le langage C "standard".

Vi enfin ca c'est débile, tu peux pas demander à ce qu'un tiers t'offre le service associé à un serveur Jabber et en plus exiger de pouvoir tracer tout ce qu'il fait de tes données.
De toute façon, à moins d'aller physiquement sur le serveur en question pour voir s'il a pas modifier le source, tu n'as aucun moyen de savoir ce que deviennent tes données.
Question de confiance.

C'est quand même rigolo les expériences individuelles : moi c'est totalement l'inverse : prezi.com est complètement fluide, avec des images animées et tout, et de l'autre côté la présentation sozi sacade en tentant d'animer 2 paragraphes et 3 courbes.
Config : Firefox 3.5... sous l'OS du mal.

le plus gros utilisateur de jabber, c'est GTalk, qui n'est pas libre...
Non, vraiment, le principal, c'est que la liberté de chacun soit respectée : la liberté de choisir son soft. Pour celà ca suppose que l'admin puisse choisir son serveur et l'utilisateur son client. Bref, le principal, c'est d'avoir un protocole standard librement implémentable comme indiqué plus haut.

Un compilateur qui fait de la JIT, se contente de compiler le code tel qu'il est. Pour vous donner une idée à quel point cet idiome est respecté, ya même la notion de classe et d'instance de classe dans le langage de la JVM.
Euh là tu montresuniquement que le bytecode est toujours de haut niveau, et que donc le boulot du JIT revient à compiler un code de haut niveau en code natif... comme le compilo Lisaac.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...

Il n'y a pas de VM, et donc le code peut être exécuté sur une machine sans OS.C'est pour ça qu'il a été conçu à la base
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.

Lisaac lui, crache certes du C.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...

"TIM"
C'est trop mignon :)
Sinon t'as totalement raison.
J'ajouterai que le plus important dans tout ça, c'est qu'ils retiennent que si les autres langages ne sont pas conçus comme le leur, c'est pas parcqu'ils sont pourris mais parcqu'il cible un public bien différent.
La conclusion, c'est qu'ils arrêtent de prétendre que Lisaac c'est LE langage C-killer parcque de haut niveau et avec les même perfs.
Parcque des langages de haut niveau qui remplace le C, y'en a une palanquée. Non, vraiment la différence c'est que Lisaac n'adresse (et ne peut adresser de par ses défauts/avantages conceptuels) qu'un public bien précis de développeurs C : ceux qui font de l'embarqué, de préférence sur de petits projet, de préférence sur du matériel exotique sans émulateur et de préférence avec des contraintes de performances ET de fiabilité.
Pour le reste, passez votre chemin, c'est pas pour vous.

Vi enfin en gros ce que tu dis, c'est que Lisaac c'est utile que pour l'embarqué où les ressources sont très limités et où y'a pas d'émulateur.
Ca doit être petit comme marché :)

Vi vi vi je connais, j'ai fait mumuse avec des outils comme ca à la fac. C'est très rigolo, mais ils partent tous d'un même principe : ils cherchent à automatiser lest tests/validation.
Je ne connaissais pas les ref que tu pointes pour les specs, mais il faut se faire une raison : tu ne peux pas contraindre le développeur à porter tout l'effort de validation sur les assertions et autres techniques déclaratives.
Je comprends bien la pertinence que cela a pour le compilateur et les garanties qui peuvent en découler, mais celà a un coup qui est loin loin d'être négligeable.
Regarde un truc comme le kernel Linux : il ne suit absolument pas ces process de dev. On est d'accord, ca conduit à un soft probablement buggué de partout avec des failles dans tous les sens (suffit de voir les journaux récents sur le sujet), mais le logiciel rempli tout de même une bonne partie du rôle que ses développeurs ont décidé de lui accorder, et le succès est là.
Donc oui, tout déporter le travail de validation en amont, de manière formelle, avec vérification statique par le compilateur est pertinent, mais dans un cadre vraiment limité : contexte industriel avec de fortes contraintes de fiabilité/sécurité. Lisaac pourrait donc être pertinent dans ces contextes... quoique du coup tu auras du mal à convaincre également ces industriels pour qui les perfs (principal atout de Lisaac), c'est secondaire : faut d'abord que ca marche (TM).
Hors de ce contexte, y'a d'autres méthodes de dev largement moins coûteuses, qui n'offre pas la même "qualité" en terme de fiabilité/sécurité on est d'accord.
Voilà tout ca pour dire que ton évangélisme sur LinuxFR est voué à l'échec, tout simplement parcqu'on est pas le public d'utilisateurs cible, donc c'est assez logique que l'on trouve finalement plus d'inconvénients dans ce langage que d'atouts.

Ton IDE il peut rien faire si le langage est mal conçu (ou en tout cas pas conçu pour répondre à ces problématiques) : l'IDE il faudra toujours qu'il cherche à compiler le code en arrière plan pour proposer un retour à l'utilisateur le plus rapidement possible, si cette phase prend 3 plombes, c'est même pas envisageable.
Donc je le répète : langage + libs + outils forment un tout, ils doivent être conçus ensemble et pour répondre aux différents cas d'utilisation des développeurs.
Le tout n'est pas d'avoir un bon langage ou un bon compilateur ou une bonne bibliothèque, il faut une plateforme complète qui soit cohérente, avec des compromis, et qui soit utilisable.

L'intérêt des plugins, c'est généralement quand tu veux proposer un point d'extension dans ton application pour laisser le soin à des tierces personnes d'ajouter leurs propres fonctionnalités.
Pour les client "lourds" t'as des miliers d'exemples : firefox, visual studio, Eclipse, etc.
Même le kernel propose le chargement dynamique de module "à chaud", c'est un mécanisme de plugin.
Perso j'utilise souvent ce pattern même pour des applications purement métier/serveur : support de nouveaux formats, de nouveaux workflows, etc.
Exemple : plateforme d'indexation de contenus vidéo : nous avions un serveur d'indexation qui chargeait dynamiquement des "moteurs" d'indexation développés par des développeurs/chercheurs dans des labos séparés. Bah les moteurs constituaient des plugins pour étendre les possibilités d'indexation de la plateforme.

Je crois que niveau validation/test, tu t'es trompé de siècle.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
T'es toujours aussi doué dans ton argumentaire : simple, efficace, une démonstration parfaite en quelque sorte.

Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
T'es vraiment un mec hallucinant. Tout ce qui t'intéresse, c'est d'être en désaccord. Pour celà, ton cerveau ignore la moitié des mots que tu lis. Je te parle de "complémentarité" et tu réponds par "se contenter ". Où est-ce que j'ai dit qu'il fallait se contenter de tests exploratoire ???
Moi je suis un pro langage avec typage fort et statique, je suis un pro assertion, un pro tests unitaires, un pro tests tout-ce-que-tu-veux-pourvu-que-ca-pète-pas-a-lexecution, donc me fait pas dire ce que j'ai pas dit.
L'impression que tu donnes, c'est que la plupart des bugs sont vérifiables à l'aide du compilateur. Moi je te réponds en disant juste que la plupart des bugs se situe généralement entre la chaise et le clavier, et que le compilateur peut juste s'assurer que syntaxiquement et sémantiquement ce qu'a écrit le développeur est correct.
Le compilateur ne peut pas deviner ce que doit faire le programme. Les assertions peuvent l'aider à vérifier certains points, mais elles ne sont pas exhaustives et rien ne garantie qu'elles soient correctement écrites.
Et puis tout est une question de compromis : dans l'idéal on coderait tout avec une méthode de type langage B. Mais le coût de développement est "monstre" et à part faire rouler des rames de métro automatique ou piloter des centrales nucléaires, on n'utilise pas. Pourtant c'est génial niveau "validation" (bien que cette méthode ne résoud pas les problème d'interface chaise/clavier et les specs incorrectes, obsolètes, ou ne répondant pas au besoin). Parcque ca a un coût. Pareil pour les assertions, pareils pour les tests U, etc. Bref une plateforme de dev doit éviter de contraindre l'utilisateur dans un modèle prévis de développement : il doit avoir un minimum de liberté sur le coût qu'il souhaite mettre dans la validation et les tests.
Et puis avant la validation, y'a la phase de développement "pur", où l'on souhaite tester rapidement un algorithme ou tester un pattern particulier. Compile & Debug, 2sec après je vois le résultat de mon expérimentation.

C'est très difficile de connaitre les vrais besoins.
Toutafé. C'est bien pour ça qu'en général il est difficile de se contenter de demander aux utilisateurs ce qu'ils veulent. Ils faut le deviner, anticiper, proposer, attirer et parfois créer le besoin.
Le minimum, c'est de regarder l'état de l'art de ce qui se fait.
La plupart des environnements modernes proposent un feedback instantané au développeur : ca se traduit par des IDE qui propose coloration contextuelle, completion, compilation en arrière plan, deboggage avec modification du code en live, ca se traduit également par des langages s'utilisant principalement avec un interpréteur (je test en direct le code auquel je pense), etc.
Maintenant les utilisateurs sont habitués à ça, et ca va être difficile pour eux de revenir en arrière, même si vous proposez d'autres atouts.
Comme déjà dit, les assertions c'est gentil, mais encore faut-il savoir les écrire. Encore faut-il savoir quoi mettre dedans. Encore faut-il ne pas se tromper lors que l'on écrit ce que l'on met dedans. Encore faut-il que les specs que l'on implémente soient correct. Encore faut-il qu'on les est bien comprises.
Les environnements actuels sont pragmatiques : rien ne vaut une exécution pour s'assurer que ce que fait le programme semble correspondre au besoin de son (futur) utilisateur.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
C'est pour ça que dans tous les cas il ne faut pas ignorer le temps de compilation, les outils de déboggage, les outils de vérifications de code, les outils de test, les IDE, bref toute la chaîne de production. Et oui : la plateforme (langage+runtime+lib) doit être conçu dès le départ pour prendre en compte ces différents aspects, sinon c'est l'assurance d'avoir un joli truc bon pour le placard.

Vous êtes gentils mais vous comparez les problème de compilation/debug avec le C... le C il a une excuse : 30 ans d'ancienneté.
Un environnement de dev (langage+compilo+IDE) moderne, il te fait de la compilation en arrière plan pendant que tu codes et te surligne les fautes en live. Sans parler de la completion intelligente qui t'évite de toute façon de taper la plupart des identifiants.
Et ces environnement sont conçus pour apporter ce retour à l'utilisateur : c'est un confort et un gain de productivité énorme. Ignorer ces aspects, c'est prendre le risque de freiner la plupart des curieux qui approche le langage : ce sentiment de retour dans les années 70 va leur faire mal au c...

Combien d'erreur pour simplement un mix minuscule/majuscule?
Le but c'est quoi : faire ressortir les types au développeur pourqu'il s'aperçoive du premier coup qu'il y a un problème, avant de compiler. Les IDE modernes propose une couleur particulière pour les types, sans parler de la compilation en arrière plan et le soulignage en rouge pour ce type de faute.
Lisaac ignore totalement ces "avancées" et propose une alternative digne des années 70 : tout mettre en majuscule, comme ca le développeur repère plus facilement s'il a mis une minuscule quelque part par erreur.
Au passage Lisaac sacrifie une part de la lecture du type : la coloration syntaxique permet d'utiliser les minuscules/majuscules pour autre chose : distinguerLesMotsDansUnNomLong. NETTEMENTMIEUXQUENLISAACSANSPARLERQUECAFAITMALAUXYEUX.

Sinon, le fait de faire plaisir au compilo permet plein de chose que veut l'utilisateur
Ben oui mais bon vous oubliez d'attirer les développeurs débutants... le truc pourtant primordial pour un nouveau langage... le ticket d'entrée de la syntaxe vous le mettez de côté.

C'est gcc qui rame ensuite quelques minutes.
Ce qui est totalement insupportable quand on parle de phase de dev.

Oui mais les bugs sont attrapé par le compilo en majorité.
Tu vas rire, mais y'a beaucoup de bug qui sont ailleur : le compilo vérifie que le code est correct mais il vérifie pas qu'il fait ce que le développeur voudrait.

Une grosse parti de la compile pour être mis en cache.
Tu m'expliques comment tu mets en cache ce que compile GCC, la compil globale peut avoir un impact n'importe où dans le .c généré pour GCC... donc sans compilation séparée... point de salut.

Si en plugin.
Vi mais comme tu le précises, ca sera plus intéressant de faire des build différentes, bah oui car dans ce cas précis tu devras faire un choix entre perf et facilité de déploiement. Paradoxe insoluble avec la solution de la compilation globale.

Oui, sauf sous forme de plugin.
Donc pas le choix : faudra diffuser les libs sous forme de source. Point de proprio, que de l'open-source. On est sur LinuxFR, on va dire que c'est un point positif ;)

Si si il en parle de cet argument.
"En javascript, tu fais la distinction entre variable et fonction"
Donc c'est pas un langage à prototype.
Où est le rapport avec la définition communément admise de langage à prototype ?
http://en.wikipedia.org/wiki/Prototype-based_programming
Aucun. Donc il défini lui même ce que lui considère comme étant un langage à prototype. Changer le sens commun d'un mot, c'est encore la meilleure façon de se donner raison.
En tout cas il a l'esprit aussi large que sa définition.
On va voir s'il a les couilles de modifier wikipedia ou s'il préfère garder sa science infuse pour lui.

On ne le fera jamais. Cela ne sert à rien.
Donc là t'es en train de dire à tous les utilisateurs :
- les gars, vous compiler toujours tout.
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.
- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.
- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.
C'est sûr, c'est une gaçon de résoudre le problème.

Oui c'est bien pour ça que j'ai dit "la plupart", y'a aucune "garantie".

Tu confonds modularisation du code et compilation séparé. L'un n'entraine pas forcément l'autre.
Je confonds absolument pas : je dis clairement quand "on modularise le code avec complétion séparée". Oui tu peux prendre que la première partie de la phrase mais moi je te parle de ma phrase entière.

Tu confonds modularisation du code et compilation séparé. L'un n'entraine pas forcément l'autre.
J'attend de voir ce que ca va donner quand vous aurez la compilation séparée...

Mais j'imagine que tu préfères gérer une exception au runtime.
Bien sûr que non. Avec un langage qui propose des assertions par contrat on peut éviter la plupart de ces "call sur null".

Un port USB qui devient une imprimante ou une clef usb
Pourquoi pas, je suppose donc que changer de parent nécessite tout de même de conserver un certain héritage en commun sinon c'est dangereux non ? (en l'occurence la clef USB reste un port USB)

il y a l'analyse de flot qui enlève 99.3% des VFT du code du compilateur sur 410 000 appels,
Analyse qui pert une grande partie de son score dès qu'on modularise le code avec compilation séparée. Du bon boulot mais qui encourage à des pratiques inverses des pratiques conseillées traditionnellement en génie logiciel.

tu as la detection des call sur null en statique.
Idem : comment le garanties-tu en cas de compilation séparée ?

Tu as la gestion de l'héritage dynamique
Tu peux montrer un exemple de code où c'est pertinent ?

Tu m'expliquera comment une coloration syntaxique corrige une faute de syntaxe.
Y dit qui voit pas le rapport. Votre langage part du principe que les types sont en majuscule par soucis de "clareté". Bah pour la clareté on a inventé la coloration syntaxique. Nettement plus élégant que les majuscules.

Perl et Ocaml propose beaucoup de "simplification" par sucre syntaxique.
Perl est utilisé par les barbus justement parcqu'innaccessible pour ces connards de noobs.
Ocaml, c'est une des raisons qui fait qu'il est peu utilisé.

Concernant la syntaxe, c'est tellement un avantage pour le compilo, qu'il y a peu de chance qu'elle bouge.
Je comprends, pour un langage de labo, qu'on privilégie les concepts et en l'occurence tu fais plaisir au compilo.

Ce que vous comprenez pas, c'est que pour un langage de "tous les jours", il faut faire des compromis entre faire plaisir/attirer le développeur et faire plaisir aux chercheurs.