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.
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.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
Dans mon code, j'ai des assertion pour vérifier l'indicage des tableaux et autre conneries du même style, donc généralement tous ces bigs sont résolus très rapidement.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
fsync() à une sorte de sémantique d'urgence, qui fait ralentir tout le système.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"+" à la place d'un "-", je veux bien comprendre que cela soit difficile à attraper statiquement, mais cela dépend aussi de comment tu écris ton contrat. Il y a des contrats ou tu utilises des propriétés à conserver, genre "f(a,b)=f(b,a)", cela permetrait d'attraper certaine erreur dans les équations. On pense aussi mettre une lib qui vérifie la dimension physique des opérations (cela n'aura pas le + à la place du -, certe).
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
Je dirais que en théorie tu as raison. Mais dans ce cas, comment expliques tu que tout les utilisateurs de SSD considèrent que leur PC a perdu toutes ses petites latences qui rend l'ordinateur "mou" et surtout comment voit-il une différence entre SSD comme avec le X25-e ?
J'ai lu il y a un moment un blog d'un codeur du noyau linux. Il était content des nouveaux OCZ vertex, qui sont les 1er SSD a être compétitif face à ceux d'intel.
Au bout d'un moment, git lui remontait des erreurs dans ses fichiers (git utilise des hash sha-256). Il s'est rendu compte que les OCZ faisait moins attention à ses données que les disques intel. Il est donc retourné dépité sous intel.
On peut même dire que la différence entre SSD pro type X25-e et X25-M, c'est la bande passante des paquets de 4Ko en écriture aléatoire. En gros autour de 1Mo pour les disques dures et à plus de 10 Mo pour les SSD pro.
C'est une donnée très importante pour toutes applications qui passent leur temps à faire des fsync() comme firefox avec SQLlite.
Est-ce qu'il y a des filtres pour "gommer" les déformations géométriques des objectifs ? Il existe un logiciel libre dont j'ai oublier le nom qui utilise une formule connu avec 3 paramètres. Ceux ci sont dans une base de donné pas mis à jour (fulla de mémoire, mais j'ai pas vérifier depuis un moment).
Il serait super utile tout de même d'avoir un plugin qui permet de faire un truc "au jugé" à la main. (http://wiki.panotools.org/Lens_correction_model ). Si il est possible de faire ça par plan de couleur, cela permet aussi de récupérer des abérations chromatique (les franges violettes).
Si mais de façon bizarre, en gros, tu as interdiction de modifier, tu lis des trucs commun, et tu écris ailleurs. Beaucoup d'algos peuvent se faire comme ça. En gros, cela ressemble à un filtre shell :)
Les assertion attrapent les erreurs dynamiquement. Les contrats sont des conditions sur l'état des objets. C'est vérifier à l'exécution en mode debug. Le sain graal serait de pouvoir les vérifier automatiquement.
Le compilo attrape les "call sur nul" statiquement, sans utiliser de contrat.
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
J'ai répondu un peu coté, j'attendais les vrais arguments mais la personne en question répond peu au mail. Et c'est argument était faible (en gros, c'est que javascript n'est pas été conçu pour être compilé). Ensuite concernant faire un tour sur le web, tu tombes sur la page wikipedia. Et souvent sur des très trucs pointus, c'est pas la joie.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.
- les gars, vous compiler toujours tout.
Oui, et c'est pas si lent.
- si vous devez compiler pour tester, vous compilerez tout.
Oui mais les bugs sont attrapé par le compilo en majorité. Une grosse parti de la compile pour être mis en cache.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
- si vous devez compiler pour débugguer, vous compilerez tout.
Oui, c'est sans doute le plus chiant. Le débug, en ligne, est aussi le degré zéro de la validation, même si on n'a pas encore le choix.
- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.
Si en plugin. Ensuite, j'imagine que niveau performance, cela sera beaucoup plus intéressant de distribuer des binaires complets différents. Et plus l'appli est grosse et plus cela sera intéressant par la magie de la compilation global.
- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.
Oui, sauf sous forme de plugin. J'imagine que l'on pourrait faire une sorte de paquet prédigéré pour accélérer la compilation et la distribution, faire cela juste pour l'obfuscation, c'est un peu naze surtout si il y a beaucoup d'introspection dans le langage.
Est-ce que tu es sûr que les Tile ont une cohérence mémoire ? Dans un soc habituel il n'y en a pas, et c'est assez horrible à gérer. C'est un défi en soi.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
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.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Souvent on voudrait juste un fdone(), quitte à le mettre dans un thread. Mais j'ai aucune idée de comment il est possible de garantir l'atomicité d'une modification sans fsync(). En gros, on veut écrire 64K, mais en cas de problème on veux soit la version précédente sois la nouvelle version mais pas un mixte. Je pense qu'un simple write (sys_write()) doit avoir cette sémantique avec les nouveaux systèmes de fichier mais que l'on a aucune idée de la taille max qu'il peut gérer comme cela (une page de 4K ? un buffer autour de 1Mo ? une grosse page de 4Mo ?).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
"La première sécurité est la liberté"
[^] # Re: AMHA
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Surfez avec Internet Explorer et offrez vous un système de sauvegarde gratuit. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: et le kernel dans tout ça ??
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 2.
Si tu fais une copie de fichier de 1 Mo par exemple ou moins, un SSD serait plus rapide qu'une grosse baie raid 5.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: filtre anti-déformation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal G'MIC : Goinfrez Moi d'Images Cristallines !. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Durable!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 3.
Au bout d'un moment, git lui remontait des erreurs dans ses fichiers (git utilise des hash sha-256). Il s'est rendu compte que les OCZ faisait moins attention à ses données que les disques intel. Il est donc retourné dépité sous intel.
"La première sécurité est la liberté"
[^] # Re: 2 petites infos inutiles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Faut-il craquer pour du SSD ?. Évalué à 3.
C'est une donnée très importante pour toutes applications qui passent leur temps à faire des fsync() comme firefox avec SQLlite.
http://www.pcworld.fr/image/zoom/1045351/ControllerWR (intel SLC, c'est le X25-e)
"La première sécurité est la liberté"
# filtre anti-déformation
Posté par Nicolas Boulay (site web personnel) . En réponse au journal G'MIC : Goinfrez Moi d'Images Cristallines !. Évalué à 2.
Il serait super utile tout de même d'avoir un plugin qui permet de faire un truc "au jugé" à la main. (http://wiki.panotools.org/Lens_correction_model ). Si il est possible de faire ça par plan de couleur, cela permet aussi de récupérer des abérations chromatique (les franges violettes).
"La première sécurité est la liberté"
[^] # Re: cohérence de cache<
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je ne vois pas de licence là-bas. Cela serait à ajouter qq part, d'ailleurs.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le compilo attrape les "call sur nul" statiquement, sans utiliser de contrat.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
J'ai répondu un peu coté, j'attendais les vrais arguments mais la personne en question répond peu au mail. Et c'est argument était faible (en gros, c'est que javascript n'est pas été conçu pour être compilé). Ensuite concernant faire un tour sur le web, tu tombes sur la page wikipedia. Et souvent sur des très trucs pointus, c'est pas la joie.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
Cela a pourtant été pointer par d'autre, je pensais au message de mathieu ici :
http://linuxfr.org/comments/1087357.html#1087357
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.
- les gars, vous compiler toujours tout.
Oui, et c'est pas si lent.
- si vous devez compiler pour tester, vous compilerez tout.
Oui mais les bugs sont attrapé par le compilo en majorité. Une grosse parti de la compile pour être mis en cache.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
- si vous devez compiler pour débugguer, vous compilerez tout.
Oui, c'est sans doute le plus chiant. Le débug, en ligne, est aussi le degré zéro de la validation, même si on n'a pas encore le choix.
- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.
Si en plugin. Ensuite, j'imagine que niveau performance, cela sera beaucoup plus intéressant de distribuer des binaires complets différents. Et plus l'appli est grosse et plus cela sera intéressant par la magie de la compilation global.
- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.
Oui, sauf sous forme de plugin. J'imagine que l'on pourrait faire une sorte de paquet prédigéré pour accélérer la compilation et la distribution, faire cela juste pour l'obfuscation, c'est un peu naze surtout si il y a beaucoup d'introspection dans le langage.
"La première sécurité est la liberté"
[^] # Re: Intel Marketing
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Les grosses copies de fichiers sous Linux
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: cohérence de cache<
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: Intel Marketing
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Intel présente un prototype de processeur x86 octatétracontacœur. Évalué à 2.
"La première sécurité est la liberté"