TImaniac a écrit 6420 commentaires

Ceux qui disent cela ne connaisse que java ou le C.
C'était justement volontaire : c'est imbittable pour la plupart des gens.
C'est pour les mêmes raisons que des langages comme smalltalk ou ocaml restent confidentiels.
Perl n'en parlons pas, c'est un truc de barbu.

La syntaxe lisaac est une version strict des règles de génies logiciel : avoir un maximum de clareté (MAJUSCULE pour les type, minuscule pour les slots, Une seul majucule pour les mots clef)
Un langage moderne part du principe que y'a un éditeur spécialisé avec coloration syntaxique... La règle des majuscule montre clairement que le langage n'a pas été conçu pour être utilisé dans un environnement moderne.

Cela a un coup énorme sur l'ambiguïté de la syntaxe, sa difficulté à lire, la difficulté à compiler et rendre performant une grammaire large.
D'accord sauf pour la difficulté à lire, puisque c'est justement l'objectif : simplifier la lecture par un noobs avec une syntaxe familière. Vous vous sacrifiez justement la familiarité et donc la simplicité de lecture pour répondre à d'autre besoins. C'est un choix, mais vous prenez l'énorme risque de vous retrouver avec un langage confidentiel comme Smalltalk.
Faudra pas venir pleurer.

la programmation par contrat facilite aussi la vérification.
On est d'accord, mais tant que vous aurez pas compris que le principal truc qui rebute, c'est la syntaxe.
C'est comme dans la vraie vie : c'est quoi le plus facile à apprendre : l'anglais qui utilise le même alphabet que nous ou ne chinois ?
Si tu dois créer une nouvelle langue, tu crois que c'est pertinent de créer un nouvel alphabet qui ne se rapproche d'aucun alphabet existant, si ton objectif est qu'il soit parler par le plus grand nombre ?

Une grosse part des outils en question, fonctionnent avec n'importe quel binaire ou n'importe quel fichier texte.
Les IDE c'est pas de simple vim, faut pas déconner. Utilise Visual un jour, son éditeur, utilise le debuggueur, utilise les profilers, tout ça.

C'est exactement le cas de Lisaac qui s'appuie sur les compilo C pour le coté universel et performant "partout".
Quand je parle d'universalité, c'est au sens "répendu" dans la tête des gens et dans les compétences des développeurs.
Lisaac a une syntaxe imbittable pour le commun des mortels, et vu que personne n'apprend se langage, ben il est pas prêt d'être universel.
Les langages qui tentent ou réussissent à s'imposer sont beaucoup plus pragmatique et cherche à rendre leur syntaxe "familière" aux développeurs justement habitués à l'universalité du langage C.

Ta vision de l'industriel ce limite à la gestion codé en Java.
Absolument pas.

Et si les qualités que tu cites étaient aussi importantes, expliques moi pourquoi C, C++, Fortran n'ont pas encore disparu dans les nouveaux designs.
Parcque ce sont des langages industriels qui ont de nombreux avantages, à commencer par une très grande maturité, des outils adaptés, des bibliothèques nombreuses, une certaine universalité, des performances adaptées à certains contextes, etc. Bref Lisaac est très très loin de pouvoir prétendre à remplacer ces langages, comme tu le fais si bien remarqués, ils sont vieux mais sont encore vivants et utilisés alors qu'il existe pourtant des langages plus modernes mais sans les mêmes atouts (D par exemple).

Parfois les performances brutes comptent, l'empreinte mémoire compte.
J'ai jamais dit le contraire.

Et je ne voix pas ce que vient faire la taille de la bibliothèque sur l'expressivité d'un langage.
Juste que ca forme un tout. Un langage sans une bonne bibliothèque n'est rien.

On est d'accord : votre but est de créer un langage qui intègre le résultat de vos recherche. Un langage de labo donc.
Rien à voir avec la philosophie d'un langage pensé pour être utilisé par des développeurs au quotidien.
Ce sont 2 objectifs différents, les 2 sont utiles, mais il est totalement idiot de dénigrer l'un plus que l'autre : Lisaac est à la ramasse totale en ce qui concerne le côté industriel. Les langages "modernes" sont conçus avec en tête leur utilisation dans un IDE (autocomplétion intelligente, refactoring), leur déploiement avec toutes les contraintes qui vont avec (composant, sécurité, portabilité, signature, sandboxing, etc.), la familiarité de la syntaxe, la bibliothèque standard (énorme), etc.
Donc arrête avec tes attaques à 2 balles sur la prétendu supériorité de Lisaac sur les autres langages.

ca n'empeche pas que ce sont des approches tres differentes
la seule et unique différence, c'est que le compilateur JIT travail "en live" quand le compilateur classique (AOT) travail en amont. Mais le travail effectué est absoluement identique !
D'ailleur la commande AOT de mono qui permet d'obtenir un binaire exécutable n'est rien d'autre que l'appel vers le moteur JIT en lui disant que tout doit être compilé là maintenant tout de suite.

Ce que tu appels un "énorme" bout de code pour transformer en code natif, tu le retrouves pareil dans GCC comme l'a très bien expliqué beafg.
GCC est basé sur un frontend et un backend avec au milieu un langage intermédiaire qui est tout comme un bytecode : une représentation qui fait abstraction des spécificités de la machine cible, le backend se chargeant de traduire dans le code machine cible.
Il n'y a donc fondamentalement pas de différence entre GCC et le compilateur C#+compilateur mono.

Je sais tres bien que mettre du code interprete en cache n'est pas du jit, mais s'il ya cache, c'est qu'il ya une forme de compilation, non?
Un interpréteur ne met rien en cache, il interprête !
Un interpréteur c'est ça :
while(true)
var instruction = analyse_instruction_suivante(input)
switch(instruction.type)
case "add" : locale[instruction.res] = intruction.left + instruction.right
case "mul" : locale[instrction.res] = instruction.left * instruction.right
etc.

Bref, une boucle infini qui analyse chaque instruction et exécute l'action correspondante, il n'est pas possible de mettre de code en cache, tout ce que tu peux mettre en cache c'est l'analyse. Tu seras toujours obligé de te taper en "live" le switch, bref le code qui s'exécute c'est celui de l'interpréteur.

Tout l'inverse d'un compilateur, qui lui joue plutôt comme ca :
foreach(instr in extractInstructions(source))
switch(instruction.type)
case "add" : exe.append(tranlateAddToX86(instr));
case "mul" : exe.append(translateMulToX86(instr));

Un compilateur JIT ne fait ni plus ni moins la même chose, sauf qu'au lieu d'écrire le résultat dans un binaire, il l'écrit dans un cache et l'exécute.

L'interpréteur a un seul intérêt : il est extrêment simple et ne nécessite pas de connaître le langage machine sur lequel il tourne (forcement il n'en produit pas), il suffit juste que l'interpréteur soit lui même écrit dans un langage portable pour que le langage interprété le soit également.
Le compilateur en revanche, cherche à éviter à tout prix la phase d'interprétation coûteuse (le switch voir l'analyse) en effectuant une traduction en code machine. C'est beaucoup plus complexe, et c'est ce que font .NET et GCC.

Les frontieres sont extremements floues dans ce domaine
Elles sont floues dans ta tête :) Ce sont 2 techniques totalement différentes sans rapport, si ce n'est leur but.

mais tu ne m'enleveras pas de l'idee est que chaque langage vient avec une philosophie
certes.

Et cette philosophie inclue la chaine de compilation, interprete, bytecode ou natif pur.
Pour moi non :
Python a d'abort été un langage interprété, puis est apparu un moteur JIT.
JavaScript a subit la même destinée. Java également.
.NET marche avec un compilateur AOT ou un compilateur JIT mais peut aussi être interprété.
Tu peux coller GCC en sortie de mono. Tu peux coller mono en sortie de GCC.
Pour moi la phylosophie d'un langage c'est d'autres caractéristiques : typage fort, dynamique, syntaxe, prototype, objet,etc.
Après ses caractéristiques peut le rendre plus ou moins facilement compilable, c'est un fait.

Et ca inclue aussi le runtime de base du langage, et le fait de savoir si on peut faire confiance a une couche en dessous, qui va verifier que tu ne dereference pas un pointeur null, que t'as acces a tel api d'ecriture sur le disque qui va verifier tes droits et tout ce genre de connerie, couche qui s'appelle une VM, verifie la signature du code, que la version de la lib est la bonne etc.
Là encore, tu confonds plusieurs choses : runtime et VM.
Une VM, ce n'est ni plus ni moins qu'un ensemble d'instruction "virtuelles", un processeur virtuel. C'est la représentation intermédiaire pour le frontend GCC, c'est le C89 pour Lisaac, c'est le bytecode pour le compilateur Java, etc.
Le runtime, c'est l'ensemble des services/code nécessaires à l'exécution pour rendre concrêtement la sémantique du langage pour lequel il est prévu.
Le C a un runtime minimaliste, le C++ en a déjà plus élaboré (pour les exceptions ainsi que pour la vérification de type, optionnel), Java en a un beaucoup plus gros parcqu'il offre de nombreux services.

Tu peux très bien compiler du code C# en code natif qui embarque le runtime (c'est ce que propose mono pour développer sur iPhone grâce à l'AOT), comme le fait le compilateur C++ qui est linké avec le runtime C++. C'est strictement identique, les étapes sont les mêmes, le service "validation" de l'AppleStore n'y voit que du feu : c'est du code natif et rien n'est généré dynamiquement.

De meme pour les "libs" d'aop qui fonctionnent en manipulant en temps reel le bytecode
Ce sont des libs, pas le langage. Les libs n'ont qu'à pas faire trop de supposition sur le code qui s'exécute. Le contrat, c'est la VM, rien n'indique que le bytecode est disponible sous la forme de donnée à l'exécution.

Lisaac qui est designe pour etre execute de facon native.
On est d'accord, Lisaac peut être conçu pour être utilisé d'une certaine façon. En l'occurrence Lisaac a été conçu pour être compilé en targetant la VM C89 de GCC.
Idem pour JSCript.NET, il a été conçu philosophiquement pour targeter la VM CLI de .NET en reprenant la syntaxe ECMAJavascript.
GCC comme .NET propose la compilation en code natif, c'est strictement identique, à la différence que .NET propose la souplesse de le faire en amont (comme GCC) ou en live.

On pourrait aussi dire la meme chose pour un langage interprete
Evidemment qu'au final c'est du code machine qui s'exécute !
M'enfin faut arrêter, y'a 2 méthodes classiques pour y arriver : l'interprétation et la compilation. Ce sont 2 techniques bien distinctes, je vois pas pourquoi t'essai de les mélanger.

Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence
Bah non, c'est comme ca qu'on marché pendant très longtemps les interpréteurs JavaScript dans les navigateurs. Jusqu'à l'arrivée (relativement récente) de la technique de JIT.

Ce n'est absoluement pas le fait de mettre en cache qui permet de passer de l'interprétation à la compilation. Refais tes TP de fac bon sang :)

Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.

On est d'accord :)

on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.
Bah non, surtout pas : dans l'interpréteur, le code machine il est déjà présent... dans l'interepréteur.
C'est toute la différence avec la compilation dont le but est de traduire et de produire du nouveau code. C'est ce code qui est exécuté.

Regarde les problèmes qu'il y a sur l'iPhone : faire un interpréteur, c'est possible car il n'y a pas de création de nouveau code, juste interprétation. Utiliser un moteur JIT c'est pas possible, parcque par nature (c'est un compilateur), il génère du code, et l'OS de l'iPhone refuse catégoriquement d'exécuter ces nouvelles instructions. D'où la technique AOT pour contourner.

Je penses que t'as vraiment pas bien saisie la différence entre compilation et interprétation.

Il voit mono comme non compile
Non, il connaît juste pas Mono.

- interprete
- langage a VM
- langage compile.

Ridicule. Un langage est un langage, point.
Beaucoup de langages peuvent se compiler et s'interpréter. La présence d'une VM est une problématique différente.
Pour Lisaac, la VM c'est le langage C89, pour JScript.NET c'est le bytecode. Les 2 sont suffisament de haut niveau pour être portable.

Faut arrêter de tordre la réalité dans tous les sens pour essayer de lui donner en partie raison : la compilation est un concept qui existe depuis un bon moment en informatique, et il s'oppose classiquement à l'interprétation. Ces sont 2 techniques totalement différentes.
Les moteurs JIT n'efface en rien cette différence : ca reste avant tout des compilateurs car ils utilisent la technique de compilation et en aucune manière l'interprétation, ils sont juste conçus pour être très rapides afin bosser "en live".

...
Je viens de dire (et j'ai vérifié) que dans le cas d'eval, le runtime JScript compile en bytecode qui est lui même compilé en code natif par le CLR (JIT). La dernière étape est l'exécution du code machine associé.
Même eval est donc bien compilable. C'est juste pas possible de le faire de manière statique avant de lancer ton programme. Mais c'est la nature même de la fonction qui veut ça.
En Lisaac t'auras exactement le même problème si tu veux fournir l'équivalent.

Avec évidemment le rappel aux frais de l'appelant initial.
Y'a pas moyen, imagine les abus : "ah bon vous nous avez pas appelé vous êtes sûr ? Attendez vous ne connaissez pas notre nouveau forfait trucbidule(TM) ?"
T'aurais envie de payer pour qu'on te spam ? non.

et pas un langage derive de JavaScript, du javascript quoi
Le but était de trouver un langage à prototype compilé. JScript.NET en est un, il est compilable, CQFD.

donne moi le code natif (archi de ton choix), du bout de code suivant:
Super, je vais pas te donner tout le code généré par le compilateur.
Mais si tu regardes l'implémentation de eval dans Microsoft.JScript.dll tu verras qu'il génère dynamiquement du code IL (bycode donc). Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.

Mon petit doigt me dit que tu vas devoir embarquer un bout de code natif tellement gros qu'on pourra aisement qualifier ton binaire de VM compilant un code inexecutable tel quel, et donc le placer dans la categorie des langages non compile nativement.
Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).

Apres, tu peux te limiter a subset du langage, comme Mono le fait si j'en crois le site web. Ca ne supporte d'ailleurs pas les generics, c'est ballot quand meme
2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.

mais c'est surement aussi parce que je connais deja lisaac , ca genere du C derriere, donc j'ai naturellement fait l'association compiler = compiler nativement.
Bah oué tu vois j'ai fais le même raisonnement que toi : c'est sûrement aussi parcque je connais déjà JScript.NET, ca génère du code IL derrière, donc j'ai naturellement fait l'association compiler = compiler nativement.

D'aucuns considerent qu'une compilation a la volee en prerequis exlue d'emblee pour le qualificatif "compilation native", et quelque part, c'est dur de leur donner tord.
Le but de la compilation à la volée est avant tout de produire du code natif exécutable, c'est quand même extrêment osé de dire que la technique de JIT n'est pas de la compilation native.
Faut pas déconner, c'est dans le premier paragraphe de la définition de JIT sur Wikipedia :
" It converts code at runtime prior to executing it natively, for example bytecode into native machine code. "

Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.

En fait il aurait fallu remplacer :
Lisaac est le seul langage à prototype compilé.
par
Lisaac est le seul langage à prototype compilé en code natif statiquement avec exécution qui n'offre pas de fonction de type eval.

Bah dans ce cas faut pas critiquer les langages mainstream si la seule destinée de leur recherche c'est in fine de se retrouver dedans...

vi enfin si t'as un client qui tourne, c'est que t'as la VM hein :)
Et puis faut arrêter avec les architectures esotériques : les implémentations de VM s'adaptent à la popularité des plateformes. Du moment que la VM est sous licence libre, on pourra toujours l'adapter à une nouvelle cible :)

... J'ai juste pris un exemple pour dire que je voyais pas de quoi parler dans ce journal.

C'est un peu ce que j'essayai de dire : c'est pas trollesque, c'est pas révolutionnaire, y'a pas grand chose à en dire, donc on discute d'autre chose.

Je dis pas que y'a pas d'intérêt, juste que c'est pas révolutionnaire et que y'a pas grand chose à en dire si ce n'est que c'était indispensable.

En tout cas, on en vient directement au fait : on est agressif parcque vous dénigrer tout les langages "industriels" utilisés aujourd'hui. Et vous les dénigrez tellement qu'il faut vous expliquer comment ils marchent, pourquoi ils fonctionnent comme ça, à quels besoins et ils répondent.
C'est pourtant ce dernier point qui est essentiel : votre objectif est-il de vanter les mérites de Lisaac ou de répondre aux besoins des codeurs ?
Qu'est ce qui est le plus important pour un développeur ? que la grammaire soit simple ou de faire en sorte que la syntaxe ne lui paraisse pas étrange ?
Pourquoi Java C# & Co se sont inspirés de la syntaxe du langage C ?

Bah eval c'est une fonction qui n'interdit en rien la technique de JIT. Effectivement c'est impossible de faire de l'AOT mais il reste toujours 2 techniques d'exécution disponibles : la compilation à la volée et l'interprétation.

Bah non, c'est comme ca sur LinuxFR : quand est un journal n'est pas intéressant (désolé, on va pas s'extasier sur le support 16 ou 64 bits), on le recycle. Un débat sur les techniques d'exécution (compilation, JIT, AOT, VM, natif, interprétation) et l'évolution qu'a subit Java ou Javascript, c'est quand même plus intéressant.

tu passes ton temps à vanter les trucs autour de .NET.
Désolé de comparer avec ce que je connais. Je suis pas spécialement "pro-Java" et pourtant j'ai pris soin d'en parler également. J'ai également parlé de JavaScript, pourtant je supporte pas ce langage.

Et les mécanisme de VM n'ont rien de supérieur au mécanisme natif,
Disons qu'ils répondent pas aux mêmes besoins, n'offrent pas les mêmes services.
Après oui je suis à titre personnel plus intéressé par les technos qui offrent des modèles de sécurités fiable pour faire des applis et dans le futur des OS que les technos qui visent les perfs. Après il en faut pour tous les goûts.

Mais effectivement, je suis souvent agressif sur les journaux Lisaac, parcque quand c'est pas toi, c'est Ontologia, et votre verbiage sur le soit disant meilleur langage que-vous-savez même-pas-argumenter-faut-systématiquement-demander-au gourou c'est assez pénible.

Probablement.
On attend avec impatience de voir l'étendu des mise à jour que vous allez faire dans Wikipedia sur les articles concernant Javascript et les langages à prototypes.
Surtout dans la version anglaise rédigée dans la langue des américains et de ces atlantistes d'anglais.

Comment tu peux te croire tellement supérieur aux autres pour croire que l'on ne connait pas comment fonctionne un JIT ?
Attend, je te recites pour voir :
"C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut. "
T'affirmes des trucs alors que ca fait 10 ans que la réalité te donne tord. Pas de ma faute à moi.

Continues de défendre tes dieux américains et fichent nous la paix.
Pauvre choupinet, faut pas venir sur trollFr avec un journal pour venter les mérites d'un langage (c'est pas une version révolutionnaire, donc à quoi bon ce journal ci ce n'est faire de la pub pour le langage ?) en commencant l'intro par "Lisaac est le seul langage à prototype compilé."
Et puis bon le côté bon français moi je supporte pas les technos des ricains, c'est du joli.
On parle de techno, rien à foutre de l'origine. En tout cas ca explique que vous soyez pas au fait de l'état de l'art, qui s'établi de part et d'autre de l'atlantique...

Et moi, cela me gave de lire des gens qui pinaillent sur des bêtises et qui cassent les trucs innovants et ne font que ça.
T'es rigolo, tu débarque avec un journal, et la première phrase vente le fait que Lisaac soit le "seul" langage à prototype compilé. Forcement ca fait tilte et ca prête à critique. Surtout que le reste des nouveautés est pas spécialement excitant et ne prête pas à grosse discussion...

C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Alors s'il le dit...
C'est vrai quoi, y'a les vrais langages, les langages des hommes quoi, et les autres, les langages de tapette.

Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
Toutafé. Mais personne ne déploie le code généré par ngen. D'ailleur ngen va mettre l'exécutable dans un cache du système que si tu vas pas sur google tu risques même pas de le trouver, donc bon...

Et puis bon, parler de l'état de l'art quand on sait même pas qu'un moteur JIT est un compilateur et non un interpréteur, que ca fait presque 10 ans qu'il existe un standard ISO qui défini une VM dédié à la compilation en code natif plutôt que l'interprétation... voilà quoi :)
Désolé pour la pique, mais bon vous semblez pas vraiment au fait de ce qui se fait depuis un bon moment déjà...

Le duck typing n'existe pas en Java.
http://en.wikipedia.org/wiki/Duck_typing#In_C.23

Il suffit de regarder ce qui tourne sur une workstation.
ben regardes tout ce qui tourne dans un navigateur web et dis moi si t'es pas content que le javascript ou Flash s'exécute dans une machine virtuelle :)
Avec la mode des OS "web", ca va devenir le standard ce genre d'appli.

Cela ne concerne pas grand chose comme code
Pour moi ca concerne "tous" les codes : j'ai déjà pas confiance dans mon propre code alors :) Y'a pas que le code malicieux, y'a aussi les "bugs" des logiciels en local. Franchement je suis bien content que dans mes applications une division par 0 ou une référence nulle se solde par une exception qui peut être rattrapée à tous les coups plutôt que de bouffer une erreur de l'OS qui tue illico mon application.

Et puis non, y'a pas que la sécurité comme exemple, je peux prendre par exemple l'introspection : ce service me garantie que je peux dynamiquement charger des plugins en "regardant" ce qu'il y a dedans. Si ce service était optionnel et qu'un plugin n'était pas compilé avec, pouf plus de meta pour l'introspection, pouf chargement foiré.

Autre service utile : le bytecode. Il me permet de déployer sur un serveur des plugins sans me soucier de l'architecture cible. Côté client, je peux checker les plugins sur le serveur, les télécharger et les exécuter en local : ca marche, sous x86, ARM ou je sais pas quoi.
Si le bytecode était un target optionnel, je ne pourrais pas garantir la portabilité de ce que sort le compilateur.

Une phrase que je trouve assez juste pour résumer la notion de runtime, tiré de http://en.wikipedia.org/wiki/C_standard_library :
"run time in this context means the run-time support package associated with a compiler which is understood to make a language complete."