Je constate un léger mieux, mais encore assez légé. Par contre, je constate avec plaisir que pour le moment, il ne s'emballe pas à consommer toutes les ressources CPU pour certaines pages chargées de javascript.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai pas vraiment étudié la question, mais si on on a un ORM où :
- Chaque tables est un objet singleton (en prototype, il sera non clonable). On pourra prendre comme convention qu'il a un s à la fin (comme dans ruby activerecord). Exemple, l'objet Tables
- chaque objet au singulier est clonable et représente une ligne d'une table. Exemple Tables contient une liste de Table.
Là ça pourrait marcher, grâce au fait qu'on ai un singleton par table ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
ça pose une question très profonde : comment éviter les framework bloatware ?
Parce que même si tu compiles tout ça, et que le compilateur te vire les 3/4 des appels qui ne sont que des appels, tu te retrouves avec un paquet de code qui ne sont que des abstractions.
Or, une abstraction, c'est une organisation humaine destinée à se retrouver mentalement dans la complexité du software.
On a le choix à faire du spécifique comme tu as fait, mais à donc ne plus avoir d'outil de "prémachage" sous la main, ou avoir les outils de prémachage et à devoir se battre contre une usine à gaz (où Spring/hibernate, etc... en sont le paroxysme, j'ai subi moi aussi...) tellement complexe qu'elle rend le développement impossible.
La hauteur de niveau des langages peut être une réponse. On peut voir par exemple avec Ruby, que certaines choses ne sont pas forcément nécessaire (au prix de performances moindre évidemment), vu l'approche interprété.
Le problème, c'est qu'en bas, on a toujours une bête machine de turing de base.
je ne sais pas ce qu'on pourrait faire de mieux... Un générateur de code, qui prend la description de ce qu'on veut faire, et génèrerai un truc spécifique... lisible ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Même si gcc est très bon pour ce genre de choses, les motifs qu'il est capable de paralléliser restent très limités, et bien souvent il suffit qu'il y ait un pointeur qui traine pour tout foutre en l'air. Dans la pratique, écrire du code que gcc peut paralléliser est souvent au moins aussi complexe que d'écrire directement le code parallèle avec les intrinsics. Et le plus embêtant c'est que la moindre petite modification anodine peut rendre le code non parallélisable, donc un patch par quelqu'un qui ne fait pas super gaffe peut-être catastrophique.
Le compilateur Lisaac a accès à une sémantique très "bas niveau" des calculs à effectuer, car les nombres sont tous des objets, et les opérateurs sont tous des messages classiques d'objets, à part les quelques primitives ( - , / , * , << ).
Comme les boucles sont elles mêmes déroulées de manière complète dans le langage très minimaliste en interne du compilateur, détecter des patterns de calculs afin de les optimiser au poil pour que GCC autovectorise, n'est pas insurmontable.
De plus, comme les boucles sont très uniformes de par le fait qu'elles sont définies en librairie, il est facile de les détecter et de cracher du C autovectorisable.
En C, ecrire du code autovectorisable est très difficile, mais pour un langage où le modèle est uniforme et assez minimaliste (c'est donc valable pour quelques langages), la simplicité fait que les patterns reviennent toujours au même et que leur détection en est ainsi facilitée.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour te situer le niveau du bonhomme, Dominique Colnet (SmartEiffel) m'a raconté que lorsque SmartEiffel est devenu GNU, il devait pour une raison ou une autre lui envoyer des données (en tar.gz je suppose). Dominique lui propose de lui envoyer ça en FTP : on est au début des années 90 et le mail était limité à l'époque.
Stallman lui répond que c'est pas possible pour lui car il n'existait pas de client ftp libre, et qu'il devait demander à son assistant de le faire pour ne pas toucher à un logiciel propriétaire (sale donc).
Assez hallucinant !
(J'avais pas demandé à Dom, mais ça m'a étonné qu'il n'existait pas de client ftp libre au début des années 90)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets
C'est ce que je pense, et je crois savoir que c'est ce que pense l'auteur du Lisaac.
On priorise comme on peut, tellement le roadmap est chargé.
La compilation séparée est un objectif depuis longtemps, mais ça pose pas mal de problèmes, car comme c'est quand même un projet de recherche, il y a pas mal de choses à inventer pour combiner le meilleur des deux techniques.
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
Où as-tu lu dans ce journal que je n'admettais pas qu'il y avait de limitations dans le langage ?
J'ai juste parlé des contrats hérités.. Ne me fait pas de procès d'intentions s'il te plait.
Évidemment que je l'admet, évidemment que le chemin est encore long et que le produit a beaucoup de limites.
Où ais-je dis le contraire sur ce journal ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
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...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
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.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
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.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
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.
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.
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...
Re..
1) Pourquoi utiliser C (et 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) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page : http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
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...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pensais comme toi que c'était petit, mais en fait c'est un marché énorme, et ça ne fait que commencer !
Regarde autour de toi tout ce qui peut comporter un micro-controleur.. Tiens je fais l'exercice là maintenant :
- Chaine Hifi (pour gérer les programmation, l'interface, les fonctions réveils, etc...)
- Télé
- Four, lave-vaisselle, lave-linge
- décodeur tnt, dvd, etc...
- Clim, chaudière
- Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Par contre, les bugs de logique me demandent souvent beaucoup de temps. Là ou en Lisaac je purais mettre un contrat, en C je peut mettre une assertion, donc la manière de faire est différente mais le résultat est proche.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités. Et de l'aveur de Dominique Colnet, il lui arrive assez souvent que son code pète sur un contrat posé il y a longtemps et assez haut dans l'arbre d'héritage.
Le fait qu'ils s'accumulent, et que tu puissent les poser sur du bas niveau (vu que tout est objet, tu peux les poser sur toutes les opérations), c'est un peu mieux que les asserts de C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Timaniac, je crois que tu travailles plus sur de l'informatique de gestion, et Nicolas sur de l'informatique embarqué très proche du processeur (Ils nous as souvent décrit ce qu'il fait).
L'info de gestion étant mon métier depuis pas mal de temps, je suis assez d'accord avec ce que tu dis, qui est pertinent pour l'info de gestion.
Mais, regardes un peu comment on développe des algos pour les moteurs d'avions (Nicolas nous a fait une pres sur le sujet, on peut te la passer s tu veux), ça n'a rien à voir.
Programmer pour de l'embarqué petit (genre des ARM à 16mhz et moins de 256 ko de mémoire), idem.
Ce sont de environnement, ou tu ne peux même pas mettre de code de debug dans ta cible, et où tu n'as pas forcément d'émulateur (sur ARM ça se trouve, mais sur d'autres archi...).
Donc, sur ce genre de cible, il vaut mieux que tout soit nickel à la compil.
Or, un des buts de lisaac, voire même sa cible principale, c'est la programmation système et embarqué. Donc les besoins ne sont pas les mêmes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Si je me souviens bien, la version lisaac prenait pas mal de mémoire de plus que la version C, ce qui nécessitait l'utilisation du swap, et donc ralentissait pas mal le calcul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est très intéressant cette histoire de plugin : j'en ai vaguement entendu parlé dans ma boite, sur une application qui aurait "celui qui m'a dit ça en était même pas sûr" utilisé ce genre de mécanisme.
Dans quel genre de contexte rencontre t-on ce genre de besoin ?
Parce que j'ai vu pas mal de gros logiciels en Java, mais jamais de use case où c'était nécessaires.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Euh disons que j'ai envoyé la vidéo "comme brouillon" "pour voir", à mes compères comme "étape intermédiaire du montage".
J'ai pour objectif de mettre les vrais slides dessus, mais c'est beaucoup de boulot :-)
Donc j'y travailles.
Pour les bruits de ventilateur, la lumière, etc.. on a fait ce qu'on a pu avec la webcam de mon mac....
La prochaine fois, on aura ptetre une cam
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Cela doit être très français de vouloir tout dénigrer.
Oui.
Lire le très intéressant "Français et Américains, l'autre rive" de Pascal Baudry, qui explique pourquoi on est, en France, rétif à toute innovation et critiques de tout ce qui est nouveau. http://pbaudry.com/
Ce bouquin est absolument passionnant, je vous le conseille !
(li livre est lisible gratuitement en PDF)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bon, je crois que vous emmêlez tous les pinceaux là.
1) Compiler, qu'est-ce que ça veut dire ?
Wikipedia (en) l'explique très bien :
A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code).
et se schéma explique le reste http://en.wikipedia.org/wiki/File:Compiler.svg
Donc js Et Lisaac ont leur compilateur.
Mais il ne font pas la même chose.
2)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.
Trace Tree et tout ces trucs sont pareils http://en.wikipedia.org/wiki/Trace_tree
ils prennent du code compilé avec très très peu d'optimisation, et regardent en temps réel ce qui peut être optimisé.
C'est le concept de la JIT, qui a été inventé par les créateur de Self.
Lisaac lui, crache certes du C. Mais ce C sera compilé tel quel par GCC, et sera transformé tel quel modulo les optimisations standard que propose GCC à tout code C et sur lequel le compilateur Lisaac compte en essayant de llui écrire (à GCC) le code au mieux afin qu'il détecte facilement ses cas d'optimisations.
Le binaire ne bougera jamais, il n'y a jamais d'analyse à la volée du code ou autres choses de ce genre.
Lisaac effectue une analyse de flot complète du code, en éliminant le code mort du programme (c'est à dire le code mort pour ce programme, en prenant son point d'entré), une détection de type draconienne (et donc les appels sur NULL), plein de patterns d'optimisation que Nicolas vous expliquerai mieux.
Bref, les deux se compile, mais compiler du Lisaac de cette façon, c'est à dire avec de l'analyse de flot, c'est la première fois qu'on le fait.
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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Les données au même niveau que le code implique que tu peux écrire une fonction foo, qui à la fin de son exécution, lorsque que le calcul est effectué devient une données avec le résultat.
Ca évite de gérer des booléen pour savoir si ça a déjà été calculé, ça permet de gérer des système de cache aisément, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai souvent défendu dans ces pages l'idée que c'était peut être un problème de difficulté de programmation : Cell c'est du NUMA à fond et c'est particulièrement compliqué à bien maîtrisé.
Tarlack, que je connais pour sa compétence, m'avait répondu que non en fait, pas plus que de coder pour du SIMD à la Seuseuseu http://linuxfr.org/comments/1063790.html#1063790
De plus, il doit bien y avoir quelques compétences qui trainent autour du Cell avec la PS3, mais ça n'a pas pris non plus.
En fait, ça serait-il pas tout simplement une question de prix ? 200 000 processeurs Intel/AMD coutent moins cher, on a une certitude d'avoir un support, et les ingénieurs de dev coutent surment moins cher car moins rare.
'fin c'est juste une hypothèse...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je plussois, car j'ai amorçé cette prise de conscience il y a quelques mois. C'est quand même une petite révolution.
Par contre, il y a quelques chose que j'ai du mal à prévoir : A un moment ou un autre Intel/AMD et Arm vont clacher, car leur domaines de marchés respectifs vont commencer à se recouvrir, qui plus est avec la convergence des OS.
Comment celava se passer ? Intel/AMD vont ils continuer à faire des bêtes de courses ? ya un marché pour les serveurs, et comme on va avoir tendance à refourguer une partie du boulot au serveur, avec juste l'interface sur le client, le marché va s'agrandir, mais quid du desktop ? Les gamers, les graphistes, vidéastes ? Mouais...
Le reste fait un gros marché en moins.
Surtout qu'on a là deux architectures, et qu"ils vont chacun la défendre (bien que développer un processeur à jeu d'instruction arm est bcp plus facile qu'un x86...)
Bref, un beau clash en perspective et je me demande ce qui va en sortir..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Quand tu écris la formule sur une feuille, tu écris bien
45020089
-------------
8!
Non ?
Le but est de pouvoir l'écrire au plus proche de cela.
Pour le reste, je suis d'accord avec toi ! Pas réfléchi ça peut vite devenir catastrophique, mais d'ici là qu'on ait au moins 100 personnes dans le monde qui codent régulièrement en Lisaac, on aura j'espère eu le temps d'écrire une bonne lib de maths qui fassent des opérations usuelles avec une syntaxe sympa et des priorités d'opérateurs réfléchis.
Autant les pointeurs, on peut, à mon avis, s'en passer, autant la surcharge des opérateurs est un réel plus, pour faire des libs sympa, réfléchies.
Mais bon, on verra...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.
45_020_089/8! fait environ 1116,56 donc il affichera ce résultat (print).
La division reste une division, la factoriel une factorielle.
Et on peut très bien implémenter factoriel dans la lib des réels (4 lignes de code) en prenant la valeur entière.
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Django
Posté par Ontologia (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rapidité sous macOS
Posté par Ontologia (site web personnel) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 2.
- Chaque tables est un objet singleton (en prototype, il sera non clonable). On pourra prendre comme convention qu'il a un s à la fin (comme dans ruby activerecord). Exemple, l'objet Tables
- chaque objet au singulier est clonable et représente une ligne d'une table. Exemple Tables contient une liste de Table.
Là ça pourrait marcher, grâce au fait qu'on ai un singleton par table ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 4.
Parce que même si tu compiles tout ça, et que le compilateur te vire les 3/4 des appels qui ne sont que des appels, tu te retrouves avec un paquet de code qui ne sont que des abstractions.
Or, une abstraction, c'est une organisation humaine destinée à se retrouver mentalement dans la complexité du software.
On a le choix à faire du spécifique comme tu as fait, mais à donc ne plus avoir d'outil de "prémachage" sous la main, ou avoir les outils de prémachage et à devoir se battre contre une usine à gaz (où Spring/hibernate, etc... en sont le paroxysme, j'ai subi moi aussi...) tellement complexe qu'elle rend le développement impossible.
La hauteur de niveau des langages peut être une réponse. On peut voir par exemple avec Ruby, que certaines choses ne sont pas forcément nécessaire (au prix de performances moindre évidemment), vu l'approche interprété.
Le problème, c'est qu'en bas, on a toujours une bête machine de turing de base.
je ne sais pas ce qu'on pourrait faire de mieux... Un générateur de code, qui prend la description de ce qu'on veut faire, et génèrerai un truc spécifique... lisible ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le compilateur Lisaac a accès à une sémantique très "bas niveau" des calculs à effectuer, car les nombres sont tous des objets, et les opérateurs sont tous des messages classiques d'objets, à part les quelques primitives ( - , / , * , << ).
Comme les boucles sont elles mêmes déroulées de manière complète dans le langage très minimaliste en interne du compilateur, détecter des patterns de calculs afin de les optimiser au poil pour que GCC autovectorise, n'est pas insurmontable.
De plus, comme les boucles sont très uniformes de par le fait qu'elles sont définies en librairie, il est facile de les détecter et de cracher du C autovectorisable.
En C, ecrire du code autovectorisable est très difficile, mais pour un langage où le modèle est uniforme et assez minimaliste (c'est donc valable pour quelques langages), la simplicité fait que les patterns reviennent toujours au même et que leur détection en est ainsi facilitée.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je me réfère souvent à cette page du projet GCC ( http://gcc.gnu.org/projects/tree-ssa/vectorization.html ) qui décrit quelles type d'écriture sont éligible à l'autovectorisation (utilisation de MMX, SSE, etc...)
Parles-tu de ce genre de vectorisation ou d'autre choses ?
S'il s'agit de ce genre de vectorisation, en quoi le C89 a t-il a voir avec ce genre d'écriture ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: GNOME pourrait se séparer du projet GNU
Posté par Ontologia (site web personnel) . En réponse au journal GNOME pourrait se séparer du projet GNU. Évalué à 4.
Stallman lui répond que c'est pas possible pour lui car il n'existait pas de client ftp libre, et qu'il devait demander à son assistant de le faire pour ne pas toucher à un logiciel propriétaire (sale donc).
Assez hallucinant !
(J'avais pas demandé à Dom, mais ça m'a étonné qu'il n'existait pas de client ftp libre au début des années 90)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
C'est ce que je pense, et je crois savoir que c'est ce que pense l'auteur du Lisaac.
On priorise comme on peut, tellement le roadmap est chargé.
La compilation séparée est un objectif depuis longtemps, mais ça pose pas mal de problèmes, car comme c'est quand même un projet de recherche, il y a pas mal de choses à inventer pour combiner le meilleur des deux techniques.
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
Où as-tu lu dans ce journal que je n'admettais pas qu'il y avait de limitations dans le langage ?
J'ai juste parlé des contrats hérités.. Ne me fait pas de procès d'intentions s'il te plait.
Évidemment que je l'admet, évidemment que le chemin est encore long et que le produit a beaucoup de limites.
Où ais-je dis le contraire sur ce journal ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
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...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
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.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
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.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
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.
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.
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...
Re..
1) Pourquoi utiliser C (et 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) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page :
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
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...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Regarde autour de toi tout ce qui peut comporter un micro-controleur.. Tiens je fais l'exercice là maintenant :
- Chaine Hifi (pour gérer les programmation, l'interface, les fonctions réveils, etc...)
- Télé
- Four, lave-vaisselle, lave-linge
- décodeur tnt, dvd, etc...
- Clim, chaudière
- Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités. Et de l'aveur de Dominique Colnet, il lui arrive assez souvent que son code pète sur un contrat posé il y a longtemps et assez haut dans l'arbre d'héritage.
Le fait qu'ils s'accumulent, et que tu puissent les poser sur du bas niveau (vu que tout est objet, tu peux les poser sur toutes les opérations), c'est un peu mieux que les asserts de C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
L'info de gestion étant mon métier depuis pas mal de temps, je suis assez d'accord avec ce que tu dis, qui est pertinent pour l'info de gestion.
Mais, regardes un peu comment on développe des algos pour les moteurs d'avions (Nicolas nous a fait une pres sur le sujet, on peut te la passer s tu veux), ça n'a rien à voir.
Programmer pour de l'embarqué petit (genre des ARM à 16mhz et moins de 256 ko de mémoire), idem.
Ce sont de environnement, ou tu ne peux même pas mettre de code de debug dans ta cible, et où tu n'as pas forcément d'émulateur (sur ARM ça se trouve, mais sur d'autres archi...).
Donc, sur ce genre de cible, il vaut mieux que tout soit nickel à la compil.
Or, un des buts de lisaac, voire même sa cible principale, c'est la programmation système et embarqué. Donc les besoins ne sont pas les mêmes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Si je me souviens bien, la version lisaac prenait pas mal de mémoire de plus que la version C, ce qui nécessitait l'utilisation du swap, et donc ralentissait pas mal le calcul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: 2 mots clefs... ou pas
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Dans quel genre de contexte rencontre t-on ce genre de besoin ?
Parce que j'ai vu pas mal de gros logiciels en Java, mais jamais de use case où c'était nécessaires.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: 2 mots clefs... ou pas
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Il dois en rester
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah que merci
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
J'ai pour objectif de mettre les vrais slides dessus, mais c'est beaucoup de boulot :-)
Donc j'y travailles.
Pour les bruits de ventilateur, la lumière, etc.. on a fait ce qu'on a pu avec la webcam de mon mac....
La prochaine fois, on aura ptetre une cam
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Oui.
Lire le très intéressant "Français et Américains, l'autre rive" de Pascal Baudry, qui explique pourquoi on est, en France, rétif à toute innovation et critiques de tout ce qui est nouveau.
http://pbaudry.com/
Ce bouquin est absolument passionnant, je vous le conseille !
(li livre est lisible gratuitement en PDF)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 9.
1) Compiler, qu'est-ce que ça veut dire ?
Wikipedia (en) l'explique très bien :
A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code).
et se schéma explique le reste http://en.wikipedia.org/wiki/File:Compiler.svg
http://en.wikipedia.org/wiki/Compiler
Donc js Et Lisaac ont leur compilateur.
Mais il ne font pas la même chose.
2)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.
Trace Tree et tout ces trucs sont pareils http://en.wikipedia.org/wiki/Trace_tree
ils prennent du code compilé avec très très peu d'optimisation, et regardent en temps réel ce qui peut être optimisé.
C'est le concept de la JIT, qui a été inventé par les créateur de Self.
Lisaac lui, crache certes du C. Mais ce C sera compilé tel quel par GCC, et sera transformé tel quel modulo les optimisations standard que propose GCC à tout code C et sur lequel le compilateur Lisaac compte en essayant de llui écrire (à GCC) le code au mieux afin qu'il détecte facilement ses cas d'optimisations.
Le binaire ne bougera jamais, il n'y a jamais d'analyse à la volée du code ou autres choses de ce genre.
Lisaac effectue une analyse de flot complète du code, en éliminant le code mort du programme (c'est à dire le code mort pour ce programme, en prenant son point d'entré), une détection de type draconienne (et donc les appels sur NULL), plein de patterns d'optimisation que Nicolas vous expliquerai mieux.
Bref, les deux se compile, mais compiler du Lisaac de cette façon, c'est à dire avec de l'analyse de flot, c'est la première fois qu'on le fait.
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
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 6.
C'est aussi expliqué dans la vidéo.
Les données au même niveau que le code implique que tu peux écrire une fonction foo, qui à la fin de son exécution, lorsque que le calcul est effectué devient une données avec le résultat.
Ca évite de gérer des booléen pour savoir si ça a déjà été calculé, ça permet de gérer des système de cache aisément, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: hégémonie d'Intel et AMD
Posté par Ontologia (site web personnel) . En réponse à la dépêche Le Top 500 de novembre 2009. Évalué à 5.
J'ai souvent défendu dans ces pages l'idée que c'était peut être un problème de difficulté de programmation : Cell c'est du NUMA à fond et c'est particulièrement compliqué à bien maîtrisé.
Tarlack, que je connais pour sa compétence, m'avait répondu que non en fait, pas plus que de coder pour du SIMD à la Seuseuseu http://linuxfr.org/comments/1063790.html#1063790
De plus, il doit bien y avoir quelques compétences qui trainent autour du Cell avec la PS3, mais ça n'a pas pris non plus.
En fait, ça serait-il pas tout simplement une question de prix ? 200 000 processeurs Intel/AMD coutent moins cher, on a une certitude d'avoir un support, et les ingénieurs de dev coutent surment moins cher car moins rare.
'fin c'est juste une hypothèse...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Symbian / Android
Posté par Ontologia (site web personnel) . En réponse au journal Samsung libère son OS pour mobile. Évalué à 2.
Par contre, il y a quelques chose que j'ai du mal à prévoir : A un moment ou un autre Intel/AMD et Arm vont clacher, car leur domaines de marchés respectifs vont commencer à se recouvrir, qui plus est avec la convergence des OS.
Comment celava se passer ? Intel/AMD vont ils continuer à faire des bêtes de courses ? ya un marché pour les serveurs, et comme on va avoir tendance à refourguer une partie du boulot au serveur, avec juste l'interface sur le client, le marché va s'agrandir, mais quid du desktop ? Les gamers, les graphistes, vidéastes ? Mouais...
Le reste fait un gros marché en moins.
Surtout qu'on a là deux architectures, et qu"ils vont chacun la défendre (bien que développer un processeur à jeu d'instruction arm est bcp plus facile qu'un x86...)
Bref, un beau clash en perspective et je me demande ce qui va en sortir..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
L'intention est louable mais le problème c'est que ton code est illisible. Sans parenthèses je me demande toujours si je doit comprendre (45020089/8)! ou bien 45020089/(8!). Et le fait de pouvoir spécifier la priorité de ces opérateurs de manière différente suivant le type de données manipulée rend les choses encore pire.
Quand je vois les horreurs qui sont fait avec la surcharge des opérateurs en C++, je n'imagine même pas à quoi on finira pas arriver en Lisaac.
Quand tu écris la formule sur une feuille, tu écris bien
45020089
-------------
8!
Non ?
Le but est de pouvoir l'écrire au plus proche de cela.
Pour le reste, je suis d'accord avec toi ! Pas réfléchi ça peut vite devenir catastrophique, mais d'ici là qu'on ait au moins 100 personnes dans le monde qui codent régulièrement en Lisaac, on aura j'espère eu le temps d'écrire une bonne lib de maths qui fassent des opérations usuelles avec une syntaxe sympa et des priorités d'opérateurs réfléchis.
Autant les pointeurs, on peut, à mon avis, s'en passer, autant la surcharge des opérateurs est un réel plus, pour faire des libs sympa, réfléchies.
Mais bon, on verra...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ah! C'est la saison de la galinette cendrée!
Posté par Ontologia (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 4.
J'espère que tu blagues en disant ça ? Utilisé proprement et avec beaucoup de modération, la redéfinition des opérateur peut-être utile mais dans ton exemple, on peut se poser des question sur la signification du "!" et le ".print" à la fin est pas vraiment plus lisible et plus clair qu'une méthode classique.
En voyant ton exemple je me pause les question suivante :
- est ce que le "/" veut encore dire division ou est-ce qu'un boulet en a changer le sens ?
- est-ce que le "!" veut dire factorielle ou autre chose et si oui, qu'est-ce qui est vraiment calculer si la valeur n'est pas ntière ?
- entre le "/" le "!" et le "." qu'elle sont les règles de prioritées et donc est-ce qu'il va bien m'afficher le résultat du calcul et surtout faire le bon calcul ?
On a les opérations infixées, préfixées, postfixées, ... Tu peux donc définir la priorité des opérateurs comme tu le souhaites. C'est fait pour pouvoir écrire tes formules au plus près de l'écriture mathématique classique.
45_020_089/8! fait environ 1116,56 donc il affichera ce résultat (print).
La division reste une division, la factoriel une factorielle.
Et on peut très bien implémenter factoriel dans la lib des réels (4 lignes de code) en prenant la valeur entière.
- Langage avec pointeurs, en enlevant toutefois la possibilité de faire des conneries avec. Qui a dit bricolage ?
On peut critiquer autant qu'on veut les pointeurs mais c'est comme la surcharge des opérateurs, dans les mains d'andouille qui font n'importe quoi ça pête dans tous les sens ; mais dans les mains de bon programmeur qui en usent sans en abuser et qui le font avec précautions, ça fait des choses magnifiques.
Des programmeurs "qui en usent sans en abuser et qui le font avec précautions" et qui sont capable de maitriser la chose, maintenant ça se compte sur les doigts de la main : va bosser dans des SSII, des boites ou on fait du logiciel de gestion, etc... Tu verras que très peu sont capable de faire du code propre sans qu'on soit constamment derrière leur dos, alors faire du code propre avec des pointeurs...
D'après toi pourquoi PHP, qui est un des langage les plus permissif et non rigoureux a eu un tel succès ?
Parce que le programmeur moyen a un niveau assez bas.
Faut faire des langages qui s'adaptent aux gens, pas l'inverse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Typage statique/dynamique
Posté par Ontologia (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker