Yusei a écrit 4649 commentaires

Tout d'abord: pourquoi es-tu aussi agressif envers les créateurs de Lisaac ? Tu n'aimes pas que quelqu'un critique ton C# chéri ? C'est étonnant comme réaction.

Ensuite, autant je comprenais tes arguments tout à l'heure, autant là j'ai décroché. En quoi le code n'est pas modulaire sous prétexte que la liaison avec la bibliothèque se fait à la compilation, et pas au runtime ? Ça a des avantages et des inconvénients, mais il est tout à fait possible de faire du code modulaire comme ça.

Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections.

Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle, dont l'implémentation dépend des sous-classes, et que tu ne sais pas toi même quel est le type de l'objet à un moment donné. Donc, dans tous les cas où l'héritage n'est pas juste une manière de coder proprement mais un besoin.

Tu auras un problème avec les collections, mais tu auras aussi un problème dès que l'utilisateur peut entrer des données qui déterminent le type de tes objets. C'est déjà assez problématique.

Le chiffre de 96% sort des stats du compilo.

Là dessus, il marque un point: ça peut vouloir dire que le compilo est efficace, mais aussi qu'il est codé sans utiliser vraiment de concepts d'objets. S'il n'y a pas beaucoup d'héritage, forcément, ça marche mieux. Et un compilateur, c'est assez bas niveau en terme de modélisation.

De toutes façons, difficile de débattre de points aussi techniques sans étudier le langage et les algos du compilateur, mais il est évident que l'analyse de flot atteint vite ses limites de par sa complexité. Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.

À mon avis, considérer Lisaac comme promoteur du libre plutôt que le contraire, c'est s'assurer qu'il n'aura jamais qu'une reconnaissance limitée.

Tout simplement parce que l'industrie ne voudra pas s'en servir (ça ne sert à rien d'investir dans un langage qui limite ce qu'on a le droit de faire avec son produit), et que si l'industrie ne s'en sert pas, beaucoup de développeurs ne prendront même pas la peine de l'apprendre.

Quand on voit le mal qu'ont à s'imposer de bons langages comme Eiffel ou OCaml, alors qu'ils n'imposent pas ces contraintes d'utilisation, on ne peut que se demander comment Lisaac pourrait attirer l'attention sans être utilisé dans l'industrie. Ce n'est pas un hasard si Java est plus utilisé qu'Eiffel alors que n'importe quel développeur raisonnable préfèrerait coder en Eiffel.

Si je dis ça, ce n'est pas parce que j'ai envie de coder des softs propriétaires, c'est surtout parce que j'aimerais bien un jour avoir la possibilité de choisir autre chose que le C++ quand je dois coder quelque chose de rapide. J'attends avec impatience un bon langage qui arrive à sortir du milieu académique. Il est très bien, le milieu académique, mais pour avoir tout un framework de développement autour du langage, il faut une grosse communauté.

je veux développer des programmes, pas faire des math.

C'est pas la même chose ?

Moi j'aimerais bien lire plus de news sur de nouveaux langages et sur des projets de recherche innovants. Sans se passer des news sur Lisaac, tant qu'à faire. Même s'il y en a, soyons fou, une par semaine.

D'ailleurs à chaque fois qu'on parle de Lisaac je vois mentionner d'autres langages innovants dont je n'ai jamais entendu parler, et des fois dans ma grande paresse je trouve la force de rechercher des infos dessus, et j'apprends des choses intéressantes.

En fait je comprend les exemples mais, comme beaucoup ici, je trouve ça assez laid. Les exemples sont simples, donc je comprend, mais ça m'inquiète quand j'imagine du code en plus grande quantité. Les exemples que je vois sur le site ne me montrent pas les qualités du langage.

(à part la syntaxe condition.if que je trouve rigolote)

Si jamais quelque chose de théorique (ie. compréhensible par quelqu'un qui n'a jamais codé de vrai compilateur mais qui aime bien les graphes) est publié sur le sujet par Benoit Sonntag ou quelqu'un d'autre, ça serait intéressant de faire un journal pour le signaler.

C'est ce que j'allais lui répondre, mais d'un autre côté la bibliothèque standard de Lisaac n'est pas non plus un compilateur. Juste un élément quasi-indispensable de la plateforme.

J'ai beau utiliser une licence libre "vaccinante" pour tout ce que je code sur mon temps libre, j'ai tendance à penser que la bibliothèque standard fait partie du langage, et que par conséquent elle ne devrait pas "vacciner" les fichiers de sortie. C'est un peu comme si Inkscape rendait GPL les fichiers SVG qu'il génère.

Il me vient une petite interrogation concernant le fait que la bibliothèque vaccine/contamine les exécutables: existe-t-il des langages/compilateurs qui font ça et qui ont un jour eu du succès ?

Pour ma part, les quelques dépêches/journaux proposés par Ontologia m'avaient donné envie de regarder du côté de Lisaac, mais j'avoue qu'il y a tellement de "langages libres" que j'aimerais apprendre mieux (Eiffel, OCaml...) que je n'avais pas pris le temps d'essayer. C'est l'occasion de m'y mettre, pour voir.

(J'avoue aussi que les exemples de codes ne me parlent pas du tout, mais c'est peut-être normal)

<mode amateur de SF>En même temps, c'est du Werber.</mode>

L'autre solution, c'est qu'on quitte la Terre pour aller dévaster une autre planète.

Même pas. On peut aller dévaster une autre planète, pas de problème, mais on ne peut pas quitter la Terre. Je laisse au lecteur le soin de calculer combien d'argent et de temps il faudrait pour évacuer quelques milliards d'humains, même en étant très optimiste sur nos progrès techniques.

Ton raisonnement semble conclure qu'un projet doit implémenter toutes les fonctionnalités souhaitées par au moins un utilisateur. Je suis sûr que je me trompe, mais j'avoue ne pas avoir suivi toute la discution.

Un élément de réponse au niveau des performances sans tester et sans regarder comment fonctionne PMO: dans la plupart des configurations "de base" de PHP, les scripts sont re-analysés à chaque requête. ActiveRecord garde en cache le schéma de la base de données, ce qui lui permet de ne pas être trop lent (en gardant dans l'idée que ça reste du Ruby), et PMO ne peut pas faire ça dans les cas où le script est relancé dans un nouvel environnement à chaque requête. Il y a donc un risque que ce soit lent

Évidemment, pour une application sérieuse, on doit pouvoir faire en sorte d'une part de ne pas réanalyser le script à chaque requête, d'autre part des garder des infos en cache, même en PHP. C'est juste que ce n'est pas le comportement par défaut.

En fait on peut généraliser en "Que faire si X ?". Et fermer le site.

Tu m'as l'air bien sûr de la supériorité du p'tit-jeune-qui-n'en-veut face à l'ingénieur. Faut être réaliste, le mec qui n'a ni diplôme ni expérience, il faut qu'il ait de bons arguments pour se faire embaucher... et souvent le seul argument possible c'est un salaire plus bas.

En plus, la "compétence réelle des gens", ce ne sont pas ces "gens" qui sont en mesure de l'évaluer. Le p'tit jeune à moitié autodidacte qui croit coder comme un pro, donne lui quelques années d'expérience et il se rendra compte à quel point il était mauvais à l'époque. Pas évident, donc, comme critère.

ça sert à quoi de venir bosser dans les murs alors que tout ce qu'il faut c'est une connexion au web...

Parfois c'est cool de voir des humains, et pas toujours les mêmes 2-3 tant qu'à faire.

(Si on m'avais dit que je dirais ça un jour)

Pour les bindings, ça revient en gros à écrire des fonctions qui effectuent les conversions entre les données du langage 1 vers celles du langage 2, appellent les fonctions voulues du langage 2, et refont la conversion dans l'autre sens. Dans certains cas, c'est automatisable.

De mémoire, et pour faire un binding d'une lib en C vers du ruby, ça revient à coder en C des fonctions qui appellent des macros pour faire les conversions, dans ce style:

TYPE_RUBY ma_fonction(TYPE_RUBY arg) {
type_c arg_c = CONVERSION(arg);
TYPE_RUBY retour = ma_fonction_c(arg_c);
return TYPE_RUBY;
}

Ensuite dans une fonction dont le nom est standardisé, tu "connectes" les fonctions C définies comme ça à des noms de méthodes de classe ou d'instance, ce qui ressemble à:

fonction_livree_par_ruby("toto", &ma_fonction, nombre_arguments);
fonction_livree_par_ruby("toto=", &ma_fonction, nombre_arguments);
fonction_livree_par_ruby("[]", &ma_fonction, nombre_arguments);


Ensuite, pour écrire une bibliothèque pour un langage... ça dépend de ce que tu veux écrire. Pour écrire un parseur XML, tu n'as pas besoin d'utiliser un langage de bas niveau, tu possèdes déjà toutes les primitives nécessaires. Pour écrire une bibliothèque de protocoles réseau, si tu n'as aucune primitive réseau, il te faudra à un moment ou un autre "redescendre" au niveau du C pour utiliser ses primitives réseau, mais tu n'as pas forcément à coder toute la lib comme ça.

(La version 1 de Rails est très récente, je dirais décembre 2005)

Concernant la lenteur, il n'y a pas actuellement de solution, et Ruby ne tire pas vraiment profit des multi-coeurs. Les threads Ruby n'utilisent qu'un coeur. Par contre, il faut savoir que:
- Avec Rails et un serveur web bien configuré, on peut traiter plusieures requetes en parallèle et donc là le multi-coeur est exploité automatiquement
- La prochaine version de Ruby utilisera une machine virtuelle avec, si j'ai bien compris, compilation JIT.

Concernant l'alliage entre Apache et Mongrel, je me demande comment ça fonctionne, car Mongrel est un serveur web. Peut-être veux tu dire Apache et FastCGI ? C'est en effet d'une lourdeur indicible, et un gros frein au déploiement d'applications Rails. Ça fait un an que j'en installe régulièrement et que je ne fais (presque) que des applicatons rails, et je galère encore parfois avec FastCGI.

En dehors de ça, c'est quand même un framework génial. Pas parfait, mais très agréable à utiliser. Au point de me faire parfois choisir de coder une application web plutôt qu'un client lourd, alors qu'en réalité je préfère les clients lourds.

Qu'est-ce qui te fait croire que QT viole moins de brevets que Mono ?

440¤ c'est encore beaucoup, surtout si en plus les pauvres employeurs doivent payer des charges sociales. Pour être bien sûr de créer le plein emploi, il suffirait de mettre le salaire minimum à 0. Les machines auront du mal à concurrencer ça !

Il faut que le gars ayant du travail engage un gars n'ayant pas de travail pour aller faire ses courses à sa place. Comme ça c'est bon.

S'il n'existe plus de travail sans qualification, que fait-on de tous ces jeunes qui sortent de l'école sans qualification.

Ils meurent de faim. Du coup, par sélection naturelle, au bout de quelques paquets de milliers d'années, la race humaine se sera beaucoup plus douée à l'école.

On a enfin trouvé le remède à la chute du niveau des maths au lycée.

Le problème, c'est la définition de l'intelligence.

En informatique, j'aime bien le dicton qui dit que l'intelligence artificielle englobe la liste des choses que l'ordinateur sait moins bien faire que l'humain. Ça a été dit pour expliquer que dès que l'ordinateur devenait bon pour faire quelque chose, soudain on n'appelait plus ça de l'IA.

Si on applique le même raisonnement à l'humain, les gens que je trouve plus intelligents que moi sont les gens qui savent faire plus de choses que moi. Et donc les gens intelligents "dans l'absolu" sont ceux qui savent faire plus de choses que la moyenne des gens. Suivant ce point de vue, le QI serait une bonne mesure d'intelligence, mais dans un domaine restreint (logique, mémoire, ...).

Je me doute que cette définition d'intelligence va déplaire à certains, qui diront que savoir faire les choses n'implique pas de les comprendre, mais bonne chance pour faire une distinction objective entre les deux. Et puis on peut toujours inclure "savoir expliquer la théorie de la relativité" dans la liste des choses que l'on sait faire.

(Je n'ai jamais fait d'objet en PHP, je répond au hasard)

Ton problème vient visiblement de la fonction de sérialization, pas de la récursivité de tes objets en elle même. Je suppose que la sérialisation ne gère pas les références des objets, et se contente de "les déplier" récursivement. C'est le même problème que pour faire une fonction "clone" qui duplique un objet "entièrement", et pas juste ses références vers d'autres variables.

Tu peux contourner le problème en codant toi-même une fonction de (dé)sérialization pour A et B: en sérializant A tu lui attribues un identifiant unique, et en sérialisant B tu identifies son parent avec cet identifiant unique au lieu de le re-sérializer.

Je ne sais pas s'il existe une manière plus propre de faire ça en PHP.