La programmation a énormément changé depuis 20 ans, tout en restant dans ses bases exactement la même chose.
La seule différence est analogiquement similaire avec la disponibilité de l'information il y a 20 ans et aujourd'hui : il était difficile de s'informer avant, alors qu'on croule sous l'information aujourd'hui.
Le développement a suivi un chemin similaire : pléthore de documentation, forum, librairies.
Et surtout gros changement, la machine avec laquelle j'écris ses lignes a la même puissance qu'une machine du top 100 il y a 25 ans.
Donc logiciels plus gros, plus complexes…
Pour gérer cette masse, on a besoin d'automatiser tout ce qui est possible pour automatiser les parties rébarbatives de problèmes qui sont toujours les mêmes et seulement devenus plus critiques à cause de cette masse d'information/complexité à gérer.
Donc oui, les IDEs, mais les outils en générale sont devenus assez indispensable en nous permettant de gagner un temps précieux et de gérer plus facilement cette complexité.
Les anciens vous expliquerait que le copier/coller n'existait pas pendant longtemps…
Donc, tout outil permettant d'automatiser est potentiellement intéressant : compilateur analysant le typage, vérification de cohérence, etc…
Maîtriser ces outils est juste une capacité du développeur de mieux gérer cette complexité.
L'industrie étant ce qu'elle est, difficile de s'en passer, ou alors dans des domaines de niches, car la productivité moyenne requise est basé sur ces IDEs.
Personnellement, je pense que c'est la sémantique des langages (toujours la même depuis 50 ans) qui est trop limité : pas de possibilité (dans les outils couramment utilisés) de gérer le temps, car le programme est un éternel amnésique sur ses donnés (quelle règle appliquer si on a tel changement successif sur les donnés ?).
Sémantique du langage limité à celle définie lors de sa conception. Aucune notion de calculs sur contraintes entre composant.
Pas de sémantique de définition du comportement global du système.
Etc…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
$ traceroute r15---sn-25g7sm7l.c.youtube.com
traceroute to r15.sn-25g7sm7l.c.youtube.com (208.117.236.52), 64 hops max, 52 byte packets
1 192.168.0.254 (192.168.0.254) 1.708 ms 12.111 ms 1.484 ms
2 78.233.124.254 (78.233.124.254) 23.849 ms 31.637 ms 54.124 ms
3 nantes-6k-1-a5.routers.proxad.net (213.228.11.254) 53.783 ms 33.918 ms 53.425 ms
4 nantes-crs8-1-be1001.routers.proxad.net (212.27.57.113) 56.875 ms 26.245 ms 32.371 ms
5 bzn-crs16-1-be1104.intf.routers.proxad.net (212.27.50.185) 93.081 ms 52.948 ms 119.273 ms
6 p11-crs16-1-be2000.intf.routers.proxad.net (78.254.250.126) 51.445 ms 57.948 ms 75.799 ms
7 th2-9k-1-be1001.intf.routers.proxad.net (78.254.249.6) 44.310 ms 93.285 ms 91.560 ms
8 ix-15-547.tcore1.pvu-paris.as6453.net (195.219.241.173) 53.775 ms 65.707 ms 47.093 ms
9 if-12-2.tcore1.pye-paris.as6453.net (80.231.154.69) 54.356 ms
if-2-2.tcore1.pye-paris.as6453.net (80.231.154.18) 47.786 ms
vlan14.icore1.pg1-paris.as6453.net (80.231.153.58) 67.653 ms
10 vlan1456.icore1.pg1-paris.as6453.net (80.231.154.78) 50.801 ms
port-channel11.icore1.pg1-paris.as6453.net (195.219.198.10) 30.328 ms
vlan1456.icore1.pg1-paris.as6453.net (80.231.154.78) 50.742 ms
11 port-channel11.icore1.pg1-paris.as6453.net (195.219.198.10) 56.250 ms 54.665 ms
208.117.236.52 (208.117.236.52) 54.153 ms
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je me pose des questions sur l'interco entre google et Free. En effet, l'autre jour, excédé, j'ai mis un proxy sur ma dedibox. Logiquement, ma dédibox est sur le réseau free, car c'est la même boite, donc ça devrait ramer pareil…
Eh bien là non, le débit est plus que correcte !
Je me demande s'il n'y pas restriction ailleurs…
Traceroute youtube sur la dedibox :
$ traceroute r15---sn-25g7sm7l.c.youtube.com
traceroute to r15---sn-25g7sm7l.c.youtube.com (208.117.236.52), 30 hops max, 60 byte packets
1 zar7-2-139.bzn.online.net (88.191.139.1) 0.840 ms 0.971 ms 1.091 ms
2 88.191.1.173 (88.191.1.173) 0.626 ms 0.909 ms 0.918 ms
3 a9k2-1013.dc3.online.net (88.191.1.133) 0.891 ms 1.131 ms 1.172 ms
4 a9k1-1012.dc1.online.net (88.191.1.130) 1.580 ms 1.901 ms 1.602 ms
5 bzn-crs16-1-be1500-t.intf.routers.proxad.net (212.27.58.49) 1.381 ms 1.768 ms 1.361 ms
6 th2-crs16-1-be2000.intf.routers.proxad.net (212.27.57.209) 1.038 ms 1.041 ms 0.984 ms
7 th2-9k-1-be1000.intf.routers.proxad.net (212.27.59.206) 1.484 ms 1.750 ms 1.814 ms
8 ix-15-547.tcore1.PVU-Paris.as6453.net (195.219.241.173) 0.957 ms 0.963 ms 8.817 ms
9 if-12-2.tcore1.PYE-Paris.as6453.net (80.231.154.69) 1.492 ms if-2-2.tcore1.PYE-Paris.as6453.net (80.231.154.18) 22.015 ms Vlan14.icore1.PG1-Paris.as6453.net (80.231.153.58) 7.847 ms
10 Vlan1456.icore1.PG1-Paris.as6453.net (80.231.154.78) 7.926 ms 7.829 ms Port-channel11.icore1.PG1-Paris.as6453.net (195.219.198.10) 1.755 ms
11 Port-channel11.icore1.PG1-Paris.as6453.net (195.219.198.10) 1.929 ms 1.783 ms 208.117.236.52 (208.117.236.52) 1.777 ms
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Certes, mais la masse de code de JS étant ce qu'elle est, je pense que c'est trop tard maintenant. C'est un risque trop gros de passer à un autre langage, surtout avec les années de maturation que ça va nécessiter et sans parler des problèmes de compatibilité entre navigateurs…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
En gros, c'est operations numeriques sur un bloc de memoire statique (et c'est tout). Va donc voir la sortie d'un bloc ASMJS par Emscripten et reviens nous expliquer la difference fondamentale avec du bytecode.
N'oublie pas qu'il y a ici un biais : le code généré en asmjs est généré à partir du bytecode LLVM qui est assez bas niveau.
Si tu regardes la spec de asmjs tu peux constater que c'est essentiellement un javascript classique qui doit être statiquement typé, le reste est moins fondamental (Bon, si, faut éviter les lambda et l'ordre supérieur en général ).
Statiquement typé signifie simplement qu'on explique bien clairement au compilateur que c'est du int/float/whatever et on ne change surtout pas le type de la variable en cours de route.
L'impression de bytecode est un peu biaisé si tu lis la spec. Le bytecode c'est plus une sorte d'assembleur, asm.js c'est plutôt du javascript écris comme du C-- sans pointeur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Très bien mais j'aimerai que cat/grep/wc/whatever comprennent une url comme un chemin de fichier et que ça soit totalement transparent.
mplayer le gère et c'est très pratique
Des trucs dans /proc ?
Oui mais pas que. "Je veux la liste des images qui sont de type PNG, dont la largeur est inférieur à 800px, et datant de plus d'un an, mais de moins de 4 ans"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ce que je veux dire, c'est que ce projet montre que les émulateurs de terminaux ne sont fait que pour afficher du texte, et qu'il serait peut être temps d'avoir la possibilité d'afficher des images, de lire du son, etc..
Tout en gardant son habitude de faire du ls, qui, s'il est pipé, ce comporte comme avant.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Une précédente tentative (dont je ne me souviens plus du nom) avait proposé la même chose. Mais c'était bugué et ça utilisait NodeJS.
Les quelques trucs que je souhaiteraient dans un terminal - qui relève de l'intégration avec ce que l'informatique est devenu - y sont :
- Intégration du ls et des types de fichiers multimédias
- (pas encore implémenté) URL fichier/web/whatever comme source de contenu. J'aimerai pouvoir faire grep patron http://www.unsite.fr/mapage.html
- Un format d'interrogation, genre query de toute ressource sur le système, oui ailleurs…
Bref, je rêve, mais tout ça va dans le bon sens et ça finira par être copié
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est marrant, j'ai développé un SMA dans lequel chaque agent est dirigé par une machine à état hiérarchique fini (pas encore mis sur github, code trop crade).
Est-ce que ce serait un sous ensemble de ton approche ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Appelle ça comme tu veux, mais toujours est-il que par expérience, ces concepts d'ordres supérieurs sont difficile à appréhender, ce qui fut pour votre serviteur pas évident au début (j'ai du mettre 2 ans à vraiment maitriser ce concept et je suis pas fier de cette lenteur).
Le concept de fonction qui prend n arguments (non fonctionnels) et en rend un, tout le monde comprend. Le concept de fonction prenant en argument une fonction, c'est plus dur déjà. C'est en train de percer, avec les lambda qui deviennent à la mode, mais il va falloir du temps pour que ça parvienne au cerveau de tout le monde, si tant est que c'est utilisé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
La notion de fonction de fonction, ou encore d'ordre supérieur, est par exemple difficile à comprendre par beaucoup de programmeurs.
La notion de module, comme rappelé à côté est pas évidente. Je fais du OCaml quotidiennement depuis 1,5 an, et je ne suis pas encore super à l'aise avec.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Java est rassurant au niveau industriel : spécifications, comités pour les standards, produit poussé par une boite qui faisait des serveurs pour la vraie vie, etc…
De plus, il était non disruptif par rapport à l'existant.
OCaml, et les langages fonctionnels en général ne sont pas facile à appréhender, les systèmes de types complexes demandent un certain apprentissage avant de pouvoir les utiliser.
Je pense aussi (mais c'est une pure intuition), que l'on comprend l'intérêt d'un tel langage, une fois que l'on a réalisé des grosses applications complexes et que l'on s'est pris le mur le de la complexité dans la face en codant avec un langage classique.
Ce qui fait que :
Peu de développeur sentent le besoin d'aller voir de tels sortes de langage (Haskell, Ocaml, Scala qui percera le mieux je pense), tant qu'il n'ont pas subi un logiciel imaintenable.
Et même parmi ceux qui l'ont vécu, peu oseront ou voudront sortir de ce qu'ils connaissent.
Les langages fonctionnels, de par leur niveau mathématique minimal requis, resteront des langages minoritaires.
Les gens aiment MacDo, Céline Dion et Jean-Jacques Goldman.
C'est comme ça.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
En ce qui concerne les nombres, Ocaml les box la plupart du temps, bien que l'unboxing ait fait du progrès. A partir de là, c'est pas évident d'imaginer ce que ça donne en asm…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Le problème de Batterie (mais je peux me tromper) c'est que ça te fait du CamlP4 dans ton dos, et ça pour moi c'est rédhibitoire. Autant sur du code perso, c'est pas grave, autant sur du code d'entreprise, je peux pas me permettre de compiler du code illisible. Surtout que les erreurs de CamlP4 sont totalement incompréhensible.
En gros, j'utilise surtout ExtLib (massivement en fait), je sais que c'est complètement dépassé, mais ça suffit à mes besoins.
Cela dit, j'ai jamais sérieusement étudié ni Batterie, ni Core.
L'idéal serait que je rencontre qqun qui m'explique l'intérêt de l'un ou l'autre (un peu comme t'as l'as fais).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ne satisfait pas les SSII, car trop bonne productivité (Le business model d'une SSII, c'est de vendre des jour.homme et des bugs, pas des bon logiciels)
On veux des noms!
Bah, toutes, c'est une question de modèle économique : aucun intérêt à faire des logiciels qui marchent. C'est un peu comme le syndicaliste de Coluche : s'il fait trop grève il est pas payé, s'il fait pas assez grève, ça va finir par se voir. En gros, un logiciel bugué mais pas trop, afin de vendre de la tierce maintenance applicative et de ne pas se faire griller par un concurrent qui proposerait une qualité légèrement moins merdique
Coût à l'exécution difficile à prévoir
Un exemple s'il vous plait monsieur?
J'en ai pas, mais prend un algo en O(n2 ) qui manipule pas mal de données (quelques centaines de Mo), tu risques d'avoir des surprises avec le GC déjà.
Ensuite, c'est bateau, mais quand je code enC, je vois assez précisément ce que ça va donner en asm. En Ocaml, avec des systèmes de types hachement compliqués tu as un peu de mal à savoir ce qui va se faire en asm.
Tu as du en chier à polytechnique ou normal (ou sup…), ça ta laissé amer on dirait.
Au contraire, je suis un cancre patenté, j'ai un cerveau gauche sous performant par rapport au droit, ainsi que me le font remarquer d'une autre façon pas mal de mes contradicteurs ici même.
Tant que du as des fonctions dans ton langage alors tu peux construire ton algo pas à pas.
Que tu fasse du fonctionnel ou de l'impératif du doit comprendre le truc sinon ça ne marchera pas.
Tout le monde utilise le papier et crayon au bout d'un moment c'est juste plus pratique pour dessiner des graphes.
J'ai souvent écris des algos qui marche sans comprendre pourquoi, c'est d'ailleurs ma manière de faire. Je suis un mauvais codeur, mais je passe pour un bon, parce que j'ai 20 ans de code et du nez (cerveau droit).
A regarder pas mal de gens, beaucoup font un mix entre "je comprend à peu près" et "essai erreur"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Effectivement, il y a plusieurs raisons de l'insuccès du langage :
Trop complexe à maitriser, minimum de maitrise mathématique requis trop élevé
Ne satisfait pas les SSII, car trop bonne productivité (Le business model d'une SSII, c'est de vendre des jour.homme et des bugs, pas des bon logiciels)
Coût à l'exécution difficile à prévoir
Système de compilation avec tous les problèmes qu'on a en C (makefile etc…). Il y a ocamlfind/ocamlbuild, mais c'est pas génial. Absence de NameSpace. On vient enfin d'avoir un vrai système de paquet (OPAM)… en 2013
C'est pas un langage à l'aise pour faire des interfaces, et il n'y a pas de lib sympa pour ça
Niveau de la ML très haut et très orienté "système de type ultra compliqué", ce qui fait que les programmeurs normaux se sentent tout de suite largués et ont aussi l'impression de se sentir comme des m**** face à une armée de normaliens et de polytechniciens (le langage a été fait par un normalien).
Paradigme fonctionnel, pas enseigné de base et difficile à appréhender : on peut construire un algo impératif pas à pas, par essai erreur. En fonctionnel il faut comprendre le truc après s'être torturé les méninges : beaucoup de gens n'aiment pas concevoir leur algo sur papier, OCaml t'y oblige, souvent.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Soit c'est mauvais signe, soit il est tout simplement terminé. Pour en utiliser quelques uns de ce genre au quotidien, c'est plus souvent ce cas là que je rencontre.
Pour mon petit soft, ça a été d'ailleurs la même histoire : il marche, j'y touche plus…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai l'impression que les utilisateurs de OCaml codent vite fait un outil dont ils ont besoin et le laissent dans un coin, en laissant la lib qu'ils ont codé en libre.
C'est aussi lié à la nature du langage : tu sais très vite quand ton logiciel est stable car le compilateur refuse de compiler sinon. Dès que ça compile et que ça marche, tu la laisses dans un coin.
Par exemple, une fois j'ai codé ça en 2h, et j'y ais plus trop touché : https://github.com/ontologiae/ArteVOD
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Parmi toutes les insultes que je reçois depuis le début, aucune n'est argumentée. Je veux bien admettre que j'ai raconté un gros tas de conneries, mais j'aimerai savoir lesquels, et avoir un retour argumenté qui sort un peu de l'insulte.
Car, en attendant une autre exécution en règle, mais argumentée, ta réponse (ainsi que celle de oao), c'est de la merde.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je te répond d'abord, pour ensuite m'occuper de ceux qui m'ont jeté (j'aurai d'ailleurs aimé un peu plus d'arguments, mais bon).
En fait, je me suis largement mal exprimé, mais tu cibles le point central.
Ce qui me pose question, c'est la sensibilité aux conditions initiales dans un système : certains systèmes y sont très sensibles et leur devenir peut changer radicalement si une condition, même minime, change. C'est ce qu'illustre ce qu'on appelle l'effet papillon : le battement d'aile d'un papillon quelque part peut provoquer une tempête une semaine plus tard.
Autrement dis, le changement minime d'une variable parmi des milliards va complètement changer l'avenir du système.
On peut ensuite se demander (et c'est surement qualifiée maintes fois au niveau mathématique) si toutes les variables, parmi les milliard du système peuvent avoir un impact aussi important sur le système. C'est aussi ça que j'appelle de la "cartographie".
L'effet papillon s'est avéré faux dans le domaine de la météo (voir l'article dont j'ai mis le lien dans le journal), mais la question que je me pose est de savoir quels systèmes existent dans le monde dans lequel on vie et sont aussi sensibles aux conditions initiales.
C'est ce que Taleb qualifie d'extremistan dans son livre. On pense immédiatement à la bourse.
D'autres systèmes sont peu sensibles, les systèmes que Todd étudie par exemple : c'est pas parce que une famille, ou quelques familles arabes vont rester dans le modèle traditionnel (beaucoup d'enfant par femme et absence d'alphabétisation) que la démocratie ne va pas s'imposer dans ces pays. Autrement dis, le fait que la majorité (c'est donc Gaussien) s'alphabétise et que la fécondité baisse "en statistique de masse" ne va pas changer le cours de l'histoire, qui est "inéluctable".
D'autre part la révolution a éclaté, mais c'est juste mon avis, parce qu'il y avait une forte concentration de gaz dans l'air et qu'une étincelle est apparu au mauvais endroit (malgré le sort de ce pauvre vendeur à la sauvette, on pourrait dire le bon"). Donc une certaine sensibilité au condition initiales (un type qui s'immole par le feu, j'appelle ça petit, ça concerne uniquement une seule personne), mais dans un cadre ultra sensible.
Cela aussi, ça se "cartographie".
Pour ce qui concerne ta dernière remarque, le point que Jorion relevait était que comme le chercheur doit se retrancher dans sa "subjectivité", il ne peu plus essayer de distinguer ce qui relève de l'extremistan ou du médiocristan. Donc il choisi l'extremistan (souvent sans s'en rendre compte souvent), à défaut de savoir, ou pire parce que c'est dans l'air du temps.
J'espère avoir été clair…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Elle est très intéressante cette thèse, alors même qu'au début, j'avais pas compris et je me demandais si c'était pas plus un truc d'ingénierie qu'autre chose ;-)
Pour le peu que j'ai vu de copperhead, tu dois te plier à la sémantique du GPU. Trop brainfuck pour moi et pour la plupart de gens.
Je pense que le genre d'outil que tu as développé va devenir très utile, parce à chaque fois on développe un langage pour le GPU, le chose, etc…
Or, leur sémantique est beaucoup trop particulière.
Et avec la généralisation du multicoeur et l'incapacité tant des devs que des compilateurs à être intelligents, il va falloir faire de la transformation de code.
L'idéal serait évidemment que cet outil de conversion soit prouvé en Coq ou quelques chose de ce genre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je lisais ce midi la partie Fr de ta thèse, tu utilises des techniques que tu y as développés dans Pytran ? Tu comptes faire de la génération pour GPU ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Automatisation indispensable
Posté par Ontologia (site web personnel) . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 10.
La programmation a énormément changé depuis 20 ans, tout en restant dans ses bases exactement la même chose.
La seule différence est analogiquement similaire avec la disponibilité de l'information il y a 20 ans et aujourd'hui : il était difficile de s'informer avant, alors qu'on croule sous l'information aujourd'hui.
Le développement a suivi un chemin similaire : pléthore de documentation, forum, librairies.
Et surtout gros changement, la machine avec laquelle j'écris ses lignes a la même puissance qu'une machine du top 100 il y a 25 ans.
Donc logiciels plus gros, plus complexes…
Pour gérer cette masse, on a besoin d'automatiser tout ce qui est possible pour automatiser les parties rébarbatives de problèmes qui sont toujours les mêmes et seulement devenus plus critiques à cause de cette masse d'information/complexité à gérer.
Donc oui, les IDEs, mais les outils en générale sont devenus assez indispensable en nous permettant de gagner un temps précieux et de gérer plus facilement cette complexité.
Les anciens vous expliquerait que le copier/coller n'existait pas pendant longtemps…
Donc, tout outil permettant d'automatiser est potentiellement intéressant : compilateur analysant le typage, vérification de cohérence, etc…
Maîtriser ces outils est juste une capacité du développeur de mieux gérer cette complexité.
L'industrie étant ce qu'elle est, difficile de s'en passer, ou alors dans des domaines de niches, car la productivité moyenne requise est basé sur ces IDEs.
Personnellement, je pense que c'est la sémantique des langages (toujours la même depuis 50 ans) qui est trop limité : pas de possibilité (dans les outils couramment utilisés) de gérer le temps, car le programme est un éternel amnésique sur ses donnés (quelle règle appliquer si on a tel changement successif sur les donnés ?).
Sémantique du langage limité à celle définie lors de sa conception. Aucune notion de calculs sur contraintes entre composant.
Pas de sémantique de définition du comportement global du système.
Etc…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Bizarre
Posté par Ontologia (site web personnel) . En réponse au journal youfree enfin un bon tube. Évalué à 2.
J'étais pas chez moi :-p
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Bizarre
Posté par Ontologia (site web personnel) . En réponse au journal youfree enfin un bon tube. Évalué à 9.
Je me pose des questions sur l'interco entre google et Free. En effet, l'autre jour, excédé, j'ai mis un proxy sur ma dedibox. Logiquement, ma dédibox est sur le réseau free, car c'est la même boite, donc ça devrait ramer pareil…
Eh bien là non, le débit est plus que correcte !
Je me demande s'il n'y pas restriction ailleurs…
Traceroute youtube sur la dedibox :
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Autre avis.
Posté par Ontologia (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 5.
Certes, mais la masse de code de JS étant ce qu'elle est, je pense que c'est trop tard maintenant. C'est un risque trop gros de passer à un autre langage, surtout avec les années de maturation que ça va nécessiter et sans parler des problèmes de compatibilité entre navigateurs…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas convaincu
Posté par Ontologia (site web personnel) . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 2.
N'oublie pas qu'il y a ici un biais : le code généré en asmjs est généré à partir du bytecode LLVM qui est assez bas niveau.
Si tu regardes la spec de asmjs tu peux constater que c'est essentiellement un javascript classique qui doit être statiquement typé, le reste est moins fondamental (Bon, si, faut éviter les lambda et l'ordre supérieur en général ).
Statiquement typé signifie simplement qu'on explique bien clairement au compilateur que c'est du int/float/whatever et on ne change surtout pas le type de la variable en cours de route.
L'impression de bytecode est un peu biaisé si tu lis la spec. Le bytecode c'est plus une sorte d'assembleur, asm.js c'est plutôt du javascript écris comme du C-- sans pointeur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Il était temps que quelqu'un montre la voie
Posté par Ontologia (site web personnel) . En réponse à la dépêche Terminology 0.3. Évalué à 3.
Très bien mais j'aimerai que cat/grep/wc/whatever comprennent une url comme un chemin de fichier et que ça soit totalement transparent.
mplayer le gère et c'est très pratique
Oui mais pas que. "Je veux la liste des images qui sont de type PNG, dont la largeur est inférieur à 800px, et datant de plus d'un an, mais de moins de 4 ans"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Il était temps que quelqu'un montre la voie
Posté par Ontologia (site web personnel) . En réponse à la dépêche Terminology 0.3. Évalué à 3.
Ce que je veux dire, c'est que ce projet montre que les émulateurs de terminaux ne sont fait que pour afficher du texte, et qu'il serait peut être temps d'avoir la possibilité d'afficher des images, de lire du son, etc..
Tout en gardant son habitude de faire du ls, qui, s'il est pipé, ce comporte comme avant.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Il était temps que quelqu'un montre la voie
Posté par Ontologia (site web personnel) . En réponse à la dépêche Terminology 0.3. Évalué à 6.
Une précédente tentative (dont je ne me souviens plus du nom) avait proposé la même chose. Mais c'était bugué et ça utilisait NodeJS.
Les quelques trucs que je souhaiteraient dans un terminal - qui relève de l'intégration avec ce que l'informatique est devenu - y sont :
- Intégration du ls et des types de fichiers multimédias
- (pas encore implémenté) URL fichier/web/whatever comme source de contenu. J'aimerai pouvoir faire grep patron http://www.unsite.fr/mapage.html
- Un format d'interrogation, genre query de toute ressource sur le système, oui ailleurs…
Bref, je rêve, mais tout ça va dans le bon sens et ça finira par être copié
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Ontologia (site web personnel) . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
Mes agents interagissent avec les autres et leur environnement par un mécanisme fourre-tout : les évènements.
En gros, chaque transition de l'automate se fait si l'équation booléenne exécutée rend vrai, et cette équation se type ainsi :
T'as pas un abstract ou un brouillon français de ta thèse (la flemme de lire en anglais ^^ ) ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un autre « framework » : ma vie mon œuvre
Posté par Ontologia (site web personnel) . En réponse au journal entity.JS - un "Entity System" en JavaScript. Évalué à 2.
C'est marrant, j'ai développé un SMA dans lequel chaque agent est dirigé par une machine à état hiérarchique fini (pas encore mis sur github, code trop crade).
Est-ce que ce serait un sous ensemble de ton approche ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Vraie application
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 2.
Le but était de montrer qu'il existe des librairies utilisables pour la vraie vie en OCaml, afin d'imaginer coder en les utilisant.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 2.
Appelle ça comme tu veux, mais toujours est-il que par expérience, ces concepts d'ordres supérieurs sont difficile à appréhender, ce qui fut pour votre serviteur pas évident au début (j'ai du mettre 2 ans à vraiment maitriser ce concept et je suis pas fier de cette lenteur).
Le concept de fonction qui prend n arguments (non fonctionnels) et en rend un, tout le monde comprend. Le concept de fonction prenant en argument une fonction, c'est plus dur déjà. C'est en train de percer, avec les lambda qui deviennent à la mode, mais il va falloir du temps pour que ça parvienne au cerveau de tout le monde, si tant est que c'est utilisé.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 1.
La notion de fonction de fonction, ou encore d'ordre supérieur, est par exemple difficile à comprendre par beaucoup de programmeurs.
La notion de module, comme rappelé à côté est pas évidente. Je fais du OCaml quotidiennement depuis 1,5 an, et je ne suis pas encore super à l'aise avec.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Manque de marketing, propagande ?
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 3.
J'avais publié une étude que j'avais réalisé sur les raisons du succès de Java : https://linuxfr.org/news/naissance-dun-g%C3%A9ant-java
Un dénommé ggins avait publié une analyse très intéressante : https://linuxfr.org/nodes/86730/comments/1251671
Java est rassurant au niveau industriel : spécifications, comités pour les standards, produit poussé par une boite qui faisait des serveurs pour la vraie vie, etc…
De plus, il était non disruptif par rapport à l'existant.
OCaml, et les langages fonctionnels en général ne sont pas facile à appréhender, les systèmes de types complexes demandent un certain apprentissage avant de pouvoir les utiliser.
Je pense aussi (mais c'est une pure intuition), que l'on comprend l'intérêt d'un tel langage, une fois que l'on a réalisé des grosses applications complexes et que l'on s'est pris le mur le de la complexité dans la face en codant avec un langage classique.
Ce qui fait que :
Les langages fonctionnels, de par leur niveau mathématique minimal requis, resteront des langages minoritaires.
Les gens aiment MacDo, Céline Dion et Jean-Jacques Goldman.
C'est comme ça.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 2.
En ce qui concerne les nombres, Ocaml les box la plupart du temps, bien que l'unboxing ait fait du progrès. A partir de là, c'est pas évident d'imaginer ce que ça donne en asm…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surpris
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 1.
Le problème de Batterie (mais je peux me tromper) c'est que ça te fait du CamlP4 dans ton dos, et ça pour moi c'est rédhibitoire. Autant sur du code perso, c'est pas grave, autant sur du code d'entreprise, je peux pas me permettre de compiler du code illisible. Surtout que les erreurs de CamlP4 sont totalement incompréhensible.
En gros, j'utilise surtout ExtLib (massivement en fait), je sais que c'est complètement dépassé, mais ça suffit à mes besoins.
Cela dit, j'ai jamais sérieusement étudié ni Batterie, ni Core.
L'idéal serait que je rencontre qqun qui m'explique l'intérêt de l'un ou l'autre (un peu comme t'as l'as fais).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 2.
Bah, toutes, c'est une question de modèle économique : aucun intérêt à faire des logiciels qui marchent. C'est un peu comme le syndicaliste de Coluche : s'il fait trop grève il est pas payé, s'il fait pas assez grève, ça va finir par se voir. En gros, un logiciel bugué mais pas trop, afin de vendre de la tierce maintenance applicative et de ne pas se faire griller par un concurrent qui proposerait une qualité légèrement moins merdique
J'en ai pas, mais prend un algo en O(n2 ) qui manipule pas mal de données (quelques centaines de Mo), tu risques d'avoir des surprises avec le GC déjà.
Ensuite, c'est bateau, mais quand je code enC, je vois assez précisément ce que ça va donner en asm. En Ocaml, avec des systèmes de types hachement compliqués tu as un peu de mal à savoir ce qui va se faire en asm.
Au contraire, je suis un cancre patenté, j'ai un cerveau gauche sous performant par rapport au droit, ainsi que me le font remarquer d'une autre façon pas mal de mes contradicteurs ici même.
J'ai souvent écris des algos qui marche sans comprendre pourquoi, c'est d'ailleurs ma manière de faire. Je suis un mauvais codeur, mais je passe pour un bon, parce que j'ai 20 ans de code et du nez (cerveau droit).
A regarder pas mal de gens, beaucoup font un mix entre "je comprend à peu près" et "essai erreur"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 4.
Effectivement, il y a plusieurs raisons de l'insuccès du langage :
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: fraicheur ?
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 1.
Soit c'est mauvais signe, soit il est tout simplement terminé. Pour en utiliser quelques uns de ce genre au quotidien, c'est plus souvent ce cas là que je rencontre.
Pour mon petit soft, ça a été d'ailleurs la même histoire : il marche, j'y touche plus…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: .
Posté par Ontologia (site web personnel) . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 2.
J'ai l'impression que les utilisateurs de OCaml codent vite fait un outil dont ils ont besoin et le laissent dans un coin, en laissant la lib qu'ils ont codé en libre.
C'est aussi lié à la nature du langage : tu sais très vite quand ton logiciel est stable car le compilateur refuse de compiler sinon. Dès que ça compile et que ça marche, tu la laisses dans un coin.
Par exemple, une fois j'ai codé ça en 2h, et j'y ais plus trop touché : https://github.com/ontologiae/ArteVOD
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Plusieurs remarques
Posté par Ontologia (site web personnel) . En réponse au journal Cartographie de la métadynamique. Évalué à 0.
Ok, alors quel mot à la con pour quels concepts.
Parmi toutes les insultes que je reçois depuis le début, aucune n'est argumentée. Je veux bien admettre que j'ai raconté un gros tas de conneries, mais j'aimerai savoir lesquels, et avoir un retour argumenté qui sort un peu de l'insulte.
Car, en attendant une autre exécution en règle, mais argumentée, ta réponse (ainsi que celle de oao), c'est de la merde.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Plusieurs remarques
Posté par Ontologia (site web personnel) . En réponse au journal Cartographie de la métadynamique. Évalué à -1.
Je te répond d'abord, pour ensuite m'occuper de ceux qui m'ont jeté (j'aurai d'ailleurs aimé un peu plus d'arguments, mais bon).
En fait, je me suis largement mal exprimé, mais tu cibles le point central.
Ce qui me pose question, c'est la sensibilité aux conditions initiales dans un système : certains systèmes y sont très sensibles et leur devenir peut changer radicalement si une condition, même minime, change. C'est ce qu'illustre ce qu'on appelle l'effet papillon : le battement d'aile d'un papillon quelque part peut provoquer une tempête une semaine plus tard.
Autrement dis, le changement minime d'une variable parmi des milliards va complètement changer l'avenir du système.
On peut ensuite se demander (et c'est surement qualifiée maintes fois au niveau mathématique) si toutes les variables, parmi les milliard du système peuvent avoir un impact aussi important sur le système. C'est aussi ça que j'appelle de la "cartographie".
L'effet papillon s'est avéré faux dans le domaine de la météo (voir l'article dont j'ai mis le lien dans le journal), mais la question que je me pose est de savoir quels systèmes existent dans le monde dans lequel on vie et sont aussi sensibles aux conditions initiales.
C'est ce que Taleb qualifie d'extremistan dans son livre. On pense immédiatement à la bourse.
D'autres systèmes sont peu sensibles, les systèmes que Todd étudie par exemple : c'est pas parce que une famille, ou quelques familles arabes vont rester dans le modèle traditionnel (beaucoup d'enfant par femme et absence d'alphabétisation) que la démocratie ne va pas s'imposer dans ces pays. Autrement dis, le fait que la majorité (c'est donc Gaussien) s'alphabétise et que la fécondité baisse "en statistique de masse" ne va pas changer le cours de l'histoire, qui est "inéluctable".
D'autre part la révolution a éclaté, mais c'est juste mon avis, parce qu'il y avait une forte concentration de gaz dans l'air et qu'une étincelle est apparu au mauvais endroit (malgré le sort de ce pauvre vendeur à la sauvette, on pourrait dire le bon"). Donc une certaine sensibilité au condition initiales (un type qui s'immole par le feu, j'appelle ça petit, ça concerne uniquement une seule personne), mais dans un cadre ultra sensible.
Cela aussi, ça se "cartographie".
Pour ce qui concerne ta dernière remarque, le point que Jorion relevait était que comme le chercheur doit se retrancher dans sa "subjectivité", il ne peu plus essayer de distinguer ce qui relève de l'extremistan ou du médiocristan. Donc il choisi l'extremistan (souvent sans s'en rendre compte souvent), à défaut de savoir, ou pire parce que c'est dans l'air du temps.
J'espère avoir été clair…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Liaison dynamique
Posté par Ontologia (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Elle est très intéressante cette thèse, alors même qu'au début, j'avais pas compris et je me demandais si c'était pas plus un truc d'ingénierie qu'autre chose ;-)
Pour le peu que j'ai vu de copperhead, tu dois te plier à la sémantique du GPU. Trop brainfuck pour moi et pour la plupart de gens.
Je pense que le genre d'outil que tu as développé va devenir très utile, parce à chaque fois on développe un langage pour le GPU, le chose, etc…
Or, leur sémantique est beaucoup trop particulière.
Et avec la généralisation du multicoeur et l'incapacité tant des devs que des compilateurs à être intelligents, il va falloir faire de la transformation de code.
L'idéal serait évidemment que cet outil de conversion soit prouvé en Coq ou quelques chose de ce genre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Liaison dynamique
Posté par Ontologia (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Je lisais ce midi la partie Fr de ta thèse, tu utilises des techniques que tu y as développés dans Pytran ? Tu comptes faire de la génération pour GPU ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Liaison dynamique
Posté par Ontologia (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Question : comment compiles-tu la liaison dynamique ? (ie. l'appel à méthode de classe lorsque tu as plusieurs type receveur possible)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker