Philippe F a écrit 2204 commentaires

Je suis tout à fait d'accord. Et c'est idem pour les machines à laver, les lave-vaisselles, les fours, etc etc.

Mon point de vue est qu'il va falloir un jour rependre ça en main et que c'est pas l'industrie qui va le proposer. Ca va donc être à nous, les particuliers, de nous réapproprier ces produits. On en voit l'émergence avec les FabLab. J'imagine très bien que dans quelques années on pourra se fabriquer soi-même ce type d'engin, voire trouver des boites qui comme les distrib linux, te fournissent du matériel Open Source, de la maintenance et des pièces détachées pour ce genre de produit.

On pourrait penser qu'une voiture sera impossible à faire dans ce mode. Et bien non, c'est déjà en cours et pas mal avance: http://wikispeed.org/ . La caractéristique numéro 1 d'une voiture wikispeed, c'est que toutes les pièces sont remplaçables en moins de 3h. On peut notamment substituer complètement le moteur assez facilement.

Je suis dans une petite boite où on a une approche assez pragmatique et peu formelle du développement. Pourtant, même dans ce contexte, je vois bien l'utilité de ce genre de programme. Même pour des projets de 1 mois, on se perd vite entre des grosses specs de fonctionnalités, des grosses spec de tests, et une implémentation des tests.

A mon boulot, mon équipe a développé un framework de test en Python pour faire des tests avec beaucoup de meta-données. Chaque test référence notamment un requirement, ou une référence du plan de test (parfois les deux) plus deux ou trois autres informations utiles.

Du coup, on peut générer un plan de test assez touffu à partir de l'implémentation même. Ce qui est bien, c'est que les deux informations "ce qui est testé" et "le test même" sont au même endroit, donc on a pas le risque que l'implémentation des tests soit moins à jour que le plan de test lui-même.

Avec ton outil, je pourrai prouver que mon plan de test généré à partir de ma suite de test couvre bien toute la spec de test et tous les requirements identifiés.

Et quand le standard arrive 20 ans après l'existence du logiciel, c'est quand même petit de le critiquer.

Excuses ma grande naïveté mais à chaque fois que je vois "on gère tout en RAM", je ne comprends pas. Comment tu fais si on tu as un crash de ton serveur ? Tu as bien une notion de persistance hors-RAM quelque part ?

C'est toujours le reproche numéro 1 que font les ruby-istes à Python: en python on écrit souvent len(toto), type(toto), unicode(toto), etc et ça choque les ruby-istes (et les smalltalk-istes) qui estiment qu'un langage n'est pas objet si on peut pas faire toto.len(), toto.type(), toto.as_unicode().

Le choix a été fait il y au longtemps par Guido, avec l'argument suivant: il estimait que la forme Python était plus lisible et plus facile à comprendre. Cet argument peut faire débat, perso, ça me passe au dessus. En langage courant en dit "je veux la longeur de toto" et "I want the length of toto", ce qui se calque bien sur le choix fait par Guido.

Ce qui me gène par contre, c'est l'argument que à cause de ce choix de syntaxe, Python ne serait pas un langage objet. Où est-il dit que si on applique une fonction à un objet, un langage n'est plus objet ? Et le C++ avec la STL qui contient beaucoup de fonctions génériques à un ensemble de containers (copy, sort, … ) est-il un langage objet ?

Est-ce que interdire la fonction main() comme le fait java en fait un langage plus objet qu'un langage où on appelle une fonction main() ?

C'est un besoin extrêmement courant.

Sous Vim, j'aurai tendance à faire une macro vite fait: je me mets au début du premier blabla, je tape qq, je fais ma modif et ma place sur le 2e blabla, et je tape q, puis @q pour répéter sur les lignes suivantes.

Sous SublimeText, je pose le curseur sur le premier bla, je duplique le curseur sur les 6 lignes avec Ctrl+Alt+Down. Ensuite, j'édite mes 6 lignes simultanément, en profitant d'un feedback visuel immédiat.

C'est de moins en moins vrai avec les dernières constructions du langage, mais pendant longtemps, quand tu voyais un programme Python et que tu connaissais le C,C++,Java,VB ou C#, tu comprenais ce que faisais le programme.

mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner.

Je serai curieux de voir ça. Python 2 est globalement rétrocompatible.

Du côté de mon expérience personelle:

• j'ai appris à coder en Python 1.5.2 et j'ai codé longtemps avec un interpréteur 2.2 sans rien connaitre des nouveautés de Python, sans que ça me pète à la gueule
• lors de nos migrations internes au boulot 2.2 -> 2.5 et 2.5 -> 2.7, on a rencontré absolument aucun problème.
• je maintiens un programme qui tourne sur Python 2.5 à 3.4 toutes versions comprises, avec une seule base de code.

Par exemple, None et yield sont des noms de variable valide en Python 2.2.

Là, bon évidemment! Mais tu assignes souvent une valeur à None, même en Python 2.2 ? J'aimerai bien voir un programmer marcher avec None = 1, juste pour rire.

Il reste donc les nouveaux mot-clés: yield , with et probablement un ou deux autres.

• Qt: javascript

Honnêtement, ça m'arrache le c** de dire ça mais je pense que javascript est le meilleur langage de script qui réponde à ces contraintes:

• raisonnablement populaire
• facile à apprendre pour que n'importe qui crache un script vite-fait
• corollaire: ressemble à un langage existant genre C/C++/Java. Exit donc tous les choix en dehors de Python
• portable
• raisonnablement facile à embarquer (Python brille pas ici mais il s'en sort)
• relativement compact (Python, oups… mais il fait des progrès il parait)

Je pense que c'est pour toutes ces raisons que Qt a finalement choisi Javascript bien que ce soit pas un choix évident.

Vraiment, tu devrais regarder de SublimeText. Il a un très gros inconvénient: il est closed source. En dehors de ça, il fait tout ce que tu décris et plus: curseur multiples, édition verticale (si j'ai bien compris), mapping Vim, extensibilité en Python, portable sur le trio Lin/Win/OsX

Il fait des bidouilles qui marchent pas trop mal. Sauf que ce type de bidouille a ses limites. Pour un portage vers KDE en mode composant KPart, on a dépassé ces limites.

Pour l'autre produit phare de Fog Creek, FogBugZ, Joel Spolsky a fait un choix inverse.

• FogBugZ est développé dans un langage maison qui ressemble a du PHP, mais en mieux, avec quelques fonctionnalités sympa.
• ce langage est compilé vers du PHP de base, et tu peux choisir la version cible de ton PHP
• du coup le déploiment d'un FogBugZ en interne dans une entreprise est triviale, la seule dépendance est un PHP de base, sans modules à la con.

Le mode de distribution a donc une influence majeure sur les choix techniques à mettre en place dans l'architecture du logiciel et a fortiori son langage de programmation.

Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème?

mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature.

Oui et non. De fait, le fork va réduire le nombre de lignes de code en s'appuyant sur des lib existantes, en supprimant des fonctionnalités inusitées (la comapbilité old-vi est elle encore une fonctionnalité ?).

Une restructuration de la base de code permettra de séparer mieux les GUI et limitera le mélange des genres.

Après, il ne faut pas se leurrer, Vim reste un gros logiciel. Il y a un langage de script, un moteur de coloration syntaxique, un gestionnaire de terminal, la gestion de macros, de registres, des 5 modes d'éditions différents, de lancer des compilations, des bindings pour différents langages (Python, …).

Tout ça ne va pas disparaitre et va rester coton à maintenir !

Pour l'avoir tenté, lua ne serait pas mon premier choix, même si c'est celui qui a été fait par neovim.

Ce qui est cool, c'est d'avoir un langage de script prêt à l'emploi, documenté, avec même un jit qui existe. Les gros incovénients de lua, c'est:

• le paradigme de programmation est plutôt original par rapport à ce qu'on connait: pas de classes mais une émulation complexe est possible mais va vite être potentiellement foireuse
• pas de compatibilité assurée entre les différentes versions de lua. Et ça, ça fait mal. Il n'est même pas possible d'écrire un programme qui soit à la fois compatible entre lua 5.0 5.1 et 5.2 . Les syntaxes diffèrent de manière incompatibles…

Je l'ai fait, ca s'appelait KVim et ça ne marche pas. Justement à cause de la structure monolithique de Vim. Neovim entend casser cette structure monolithique et permettra si il remplit ses objectifs de faire un KVim fonctionnel et facile à maintenir.

Les ifdef peuvent avoir une utilité pour un logiciel qui doit en effet se décliner en N versions différentes.

Est-ce le cas de Vim ? Je suis loin d'en être persuadé. Il y a bien un besoin entre un Vim minimaliste pour des plate-formes minimalistes et un Vim bouffi pour ceux qui ne regardent pas à la taille. Mais choisir individuellement entre avoir le support des split verticaux, des jumplist, et autres joyeusetés, est-ce que ça a un sens.

Pour ceux qui veulent voir à quoi ça ressemble, c'est:
https://code.google.com/p/vim/source/browse/src/feature.h

Supprimer les ifdef est enlever une fonctionnalité (pas qui t'interesse, mais qui itneresse une autre personne). Donc pas terrible.

En l'occurence, il supprime la possibilité de supprimer une fonctionnalité en l'incluant automatiquement de base.

J'ai fait le compte vite-fait, il y a 110 feature différentes qui peuvent être activées ou désactivées. Question subsidiaire, qui teste les 2¹¹⁰ = 1298074214633706907132624082305024 combinaisons qui en resultent ? On est clairement dans un truc incohérent.

Dans les faits, certaines de ces fonctionnalités correspondent à des fonctionnalités spécifiques à des plate-formes. Mais au lieu d'avoir une couche de portabilité claire et des fichiers sources isolés, tout est en bazar dans la même base de code, sans permettre de distinguer facilement ce qui appartient à quoi.

Les forks réussis qui durent sont extrèmement rares,
Ca arrive, et ça arrive même

Une des clés me semble être l'adhésion d'une partie de l'équipe de développement principale.

C'est vrai que mesurer les chances de réussites du projet à l'aune de savoir si il va standardiser les fichiers de config façon freedesktop, c'est une bonne approche !

Je me suis renseigné un peu sur le projet. Ayant eu la naïveté de vouloir coder un clone de Vim par le passé ( Yzis ) et ayant tenté plusieurs projets d'intégration de Vim (KVim et autres), j'étais curieux de voir ce que ça donne.

Rappelons quand même que:

• Vim est un très bon éditeur, globalement plutôt stable, très portable
• des tonnes de plugin pour faire plein de trucs sont dispo. C'est pour ça que l'auteur veut maintenir la compatibilité avec les plugin
• Bram le maintient avec succès depuis des années.

Les points négatifs:

• la base de code de Vim est infame. Comme le note Thiago l'auteur du fork, il est bourré de ifdef pour chaque fonctionnalité alors que dans les faits, les distrib vont surtout faire toutes les fonctionnalités ou un vim minimal mais vont très rarement s'amuser à ajouter/enlever une fonctionnalité particulière.
• la couche graphique s'intègre très mal. Il n'y a pas de boucle d'évènement dans vim, il est toujours basé sur le principe "j'attends un caractère et je le traite". Ca rend très compliqué tout un tas d'évolutions qui pourraient apporter des trucs sympa.
• le code mélange allègrement des variables globales, des allocations d'éléments de listes en plein milieu d'une fonctionnalité élaborée. Faut s'acrocher. Rien qu'utiliser une lib générale pour gérer des listes comme glib simplifierai significativement le code.
• Bram est très lent à intégrer des patch. J'ai déjà proposé des patchs triviaux sur des trucs visiblement mal fini qui ne sont pas intégrés parce que globalement, Bram s'en fout de cette partie-là de Vim.
• la direction générale de Vim est plutôt incohérente. On sent que Bram préferait qu'il n'y ai finalement aucune nouvelle fonctionnalité, mais des gens lui proposent des patchs à tour de bras pour plein de trucs avec lesquels il n'est pas à l'aise. Du coup, ça s'intègre mais de façon sporadique. On sent pas pas le "Non, je mettrai rien de nouveau", ou le "oui, OK pour intégrer des nouveaux trucs mais sous telles et telles conditions". Ca reste un arbitrage un peu flou. C'est là qu'on mesure mieux le talent de leadership de Linus.
• Pour illustrer l'esprit, il y a encore deux ou trois ans, Bram publiait encore des patchs sur la mailing liste et des outils horribles tels que CVS, SVN, HG ou GIT ou autres étaient proscrits.

• pour citer des gros points faibles :

  • c'est dur de faire évoluer le GUI de vim, parce que l'architecture de Vim se prête très mal à un GUI moderne
  • le langage de script maison, c'est sympa mais ça commence sérieusement à montrer ses limites
  • Vim ne peut rien gérer en asynchrone. Pour tout un tas de plugin, c'est vraiment génant.
  • Si vous aviez le projet comme moi d'embarquer Vim en tant que composant dans un autre logiciel (IDE ou autre), c'est en fait infaisable à cause de la nature très monolithique de Vim et de l'absence de boucle d'évenement.

Pour moi, Vim est un très bon éditeur, qui commence à montrer son age. Les pratiques de développements d'un autre age ne tiennent plus la route face à la popularité et aux nouveaux enjeux d'un éditeur moderne. C'est un peu la FSF contre Github.

Donc un rafraichissement tel que celui proposé me semble tout à fait louable, avec un bon potentiel d'amélioration. Après, il ne faut pas sous-estimer la tâche. Vim est très gros, maintenir un fork de cette taille est un boulot monstrueux, et ce n'est pas sur qu'une équipe même motivée arrive à faire le travail de fond que fait Bram depuis des lustres.

J'ai regardé un peu le CV de Thiago de Arruda qui est l'auteur de cette initiative. C'est pas un manchot, il a déjà codé des trucs intéressants avec Vim, mais globalement, il est loin d'avoir donné la preuve qu'il est à la hauteur de l'enjeu. Forker un gros projet, c'est très difficile à tenir dans le temps. Les forks réussis qui durent sont extrèmement rares, il faut l'adhésion d'une partie de l'équipe de développement du coeur pour que ça réussisse. Sinon, ça retombe au bout de quelques mois.

En tout cas, bonne initiative. Ca me permettra peut-être de lacher SublimeText pour revenir à Vim…

Ah ah ah.

A l'époque des trollsdicussions sur la licence de Qt, des gens avaient envisagés de réécrire Qt en GPL au lieu de QPL. Si je me souviens bien, ils avaient même pas fais l'ensemble du tutorial Qt….

La motivation pour maintenir un système qui n'a pas de futur me semble difficile à trouver…

C++ : tu n'es pas obligé de te mettre à niveau.

Si, je suis obligé de me mettre à niveau. Je travaille dans une entreprise, et des collègues utilisent C++11 . Si je comprends rien à leur code, ça va être difficile de coopérer.

Mais bon, c'était juste une remarque générale, se mettre à niveau fait partie de la vie des informaticien normalement. C++ a toujours été un langage complexe, il le sera encore plus…

Ca c'est vraiment un argument à deux balles. Quel serait l'intérêt de faire un programme purement impératif et objet en OCaml ? Si c'est pour faire du OCaml autant tirer partie des points forts du langage…

C'est sur que C++ est un langage compliqué et qu'on s'éloigne de la simplicité "je connais le C/Java/C#, je comprends le C++".

OCaml souffre quand même deux ou trois problèmes si j'ai bien suivi:

• c'est un paradigme différent et plus difficile à appréhender qu'un langage Objet impératif comme le C++. Pas mal de programmeurs formés aujourd'hui ne sont pas préparés à ce niveau d'abstraction (voire en sont complètement incapables).

• il a l'air très bien en langage autonome, mais pour s'interfacer avec le monde extérieur, ca a l'air plus compliqué. Typiquement, si je veux faire un beau GUI portable, je vais me tourner vers Qt : je cherche sur les GUI supportés par OCaml, pas de Qt (tu m'étonnes, avec le C++, c'est pas gagné de transformer ça en logique pseudo-fonctionelle).

  C'est pas grave, allons voir Gtk en espérant que ça reste aussi portable. Bon, il y a LablGtk qui supporte Gtk 2.18 soit une version de Gtk qui est sortie en 2009. Même si le package a été mis à jour en décembre 2013, ça donne pas super confiance. J'ai pas l'impression que OCaml soit un bon choix pour une application qui a un GUI…

• il parait aussi que la syntaxe est pas extra, au point qu'il existe des package pour des syntaxes alternatives…

Sinon, j'avais fait du CamlLight et j'avais trouvé ça plutôt sympa bien qu'un peu bizarre.

Bon, plutôt que de râler, je suis aller lire le lien proposé dans la dépêche sur les nouveautés de C++ (les dépêches techniques, c'est bien fait pour ça non ?)

Je dois reconnaître qu'il y a plein de bonnes choses. Des constructions qui étaient régulièrement pénibles à mettre en oeuvre deviennent plus souples (initializer-list, initialisation des variables non statiques dans les classes, etc). Le langage va clairement être beaucoup moins rigide.

Par contre, bonjour la croissance en complexité. Et j'en suis qu'au début.

Par exemple, si vous pensiez que c'était compliqué de penser à la fois au constructeur par défaut, constructeur par copie et copie explicite, bienvenue dans le nouveau C++11 où il faudra aussi penser au constructeur par déplacement et copie par déplacement, et avoir en tête qu'une partie est généré automatiquement.

Je vous laisse méditer 5 minutes sur cette petite phrase avant d'être sûr d'en avoir extrait la signification:
If any move, copy, or destructor is explicitly specified (declared, defined, =default, or =delete) by the user, no move is generated by default. If any move, copy, or destructor is explicitly specified (declared, defined, =default, or =delete) by the user, any undeclared copy operations are generated by default, but this is deprecated, so don't rely on that.

Pour ma part … hum hum (sourire gêné) … je vais avoir besoin de plus de 5 minutes pour aller lire ces histoires de move.

les différences entre python 1.5 et python 3.3 sont quand même gigantesques

De fait, elles le sont. Mais la syntaxe est restée très homogène. Regarde la syntaxe lambda de C++, où la complexité de certaines définitions quand on commence à manipuler des functor, on est plus dans le même monde.

En plus de ce que tu as cité, tu as aussi:
- old-class vs new-class

C'est complètement non intrusif au niveau de la syntaxe. Aujourd'hui, tu n'as même pas besoin de savoir que cette différence existe si tu lis du code Python.

compréhension liste, et autres extensions de syntaxes pour les dictionnaires et les ensembles

La première fois, la syntaxe est un peu étonnante, notamment quand tu as deux boucles et des if. Mais très vite, on remarque que:
- la syntaxe est cohérente avec l'existant
- la seule difficulté, c'est vraiment la règle des précédences entre les multiples for et if
- la même syntaxe fonctionne pour les générateurs, les list-comprehenions, les set, les dictionnaires: ca veut dire que si tu as compris la syntaxe une fois, tu l'as compris pour tous les générateurs.

• une API C cassé n-fois

Moui, on sort un peu du langage cependant.

• nouvelle syntaxe pour le formatage

C'est celui où j'ai le plus de réserves.

• print() \o/

non, le plus méchant dans l'évolution de Python, c'est bien la gestion de l'unicode, le passage au byte-string.

Si on regarde la question sous l'angle de "quelqu'un qui a appris Python 1.5 serait-il capable de comprendre un programme Python écrit en 3.4", on voit que :
- il va buter sur les générateurs/list compréhensions
- il va buter sur les décorateurs
- il va buter sur les gestionnaires de contextes

Bon, au final, il va ramer un peu c'est vrai, mais ça me semble moins violent que pour le C++.

J'ai appris le C++ quand tout ce fratras de C++11 n'existait pas (je crois même pas qu'on osait lever une exception à l'époque) et Python en version 1.5.2 . En quelques heures, je me suis mis à niveau en Python. Pour C++, j'ai l'impression que je vais galérer beaucoup beaucoup plus.

C'est vrai que le C++11 a l'air de proposer des ouvertures intéressantes.

Pour ce qui est de l'opérateur "" + le litéral _type, j'avoue que je suis un peu effrayé. Est-ce qu'on peut utiliser l'opérateur "" tout court ? Est-ce que ça risque pas de pourrir toutes les chaînes de caractères de ton programme + de toutes les lib qu'il utilise ?

Par contre, je suis de plus en plus convaincu que le C++ souffre d'un gros problème, qui ne fait que s'empirer avec le C++11 : très peu d'être humains sont capables de comprendre tout le langage C++. Et les programmes sont encore écrits par des êtres humains … donc par des gens qui ne comprennent pas toutes les conséquences ce qu'ils écrivent. Et c'est encore plus vrai pour ceux qui les relisent.

Les nouvelles additions permettent vraiment de faire des trucs intéressants, et on peut dire que aucun problème n'échappera au C++. Mais à quel prix ? Combien de mot-clés en plus, de constructions bizarres, de symboles pas facile à comprendre ? Je note que pour chacune des nouvelles constructions (template, lambda, …), j'ai de plus en plus de mal à faire le tri entre les valeurs retournées, les valeurs sur lesquelles portent la fonction, nom de la fonction elle-même.

Je comprends le désir pour le C++ de rester dans la course avec du typage allégé, des closures, des lambda, des template plus light, etc. Mais le langage perd à chaque fois en simplicité et lisibilité.

De mon point de vue, un langage de programmation doit rester concis et clair. Pas trop de mot-clés, pas trop de constructions alambiquées.

J'avais été effaré de voir le nombre de mot-clés du C# par exemple, où il y a une dizaine de façon différentes de protéger l'accès à une méthode de classe. Mauvais approche ! Ils ont pu jouer a "qui a la plus longue" avec Java qui avait moins de possibilité, mais au final, le perdant, c'est à mon avis le développeur. Quand tu vois qu'en Python, il y a à peu près 0 protections sur l'accès aux méthodes et qu'on arrive quand même à écrire des programmes, ça fait réfléchir.

Si je regarde Python, au niveau de la construction du le langage, il s'en sort pas mal. Il y a eu pas mal de nouvelles constructions par rapport à la version 1.5.2 que j'avais apprise, mais elles s'intègrent syntaxiquement de façon assez fluide dans le langage: itérateurs, générateurs, yield from, string unicode, décorateurs, gestionnaires de contextes. Tout ça a ouvert vraiment la voie à un style de programmation plus évolué, tout en restant dans la simplicité initiale et la syntaxe du langage.

Mettre C++ sur son CV ne veut maintenant plus rien dire. Quel C++ ? On est bien loin des 3 classes et deux constructeurs que j'ai appris à l'école.

Mais bon, je râle mais je sais très bien que c'est inutile: selon la vieille théorie du "worse is better", on va se traîner C++ avec ses anciens et ses tous nouveaux problèmes encore très longtemps, tout comme Javascript…