Philippe F a écrit 2208 commentaires

Je ne pense pas que le multi-process résolve tous les cas, et ce n'est pas ce que j'ai écrit. J'ai juste rappelé que d'une part, que:

1. il y existait d'autres solutions possibles que le multi-thread pour gérer des programmes CPU-bound . Le module multiprocessing fournit un service transparent pour partager des données et lancer des opérations sur plusieurs processus. Ca peut toutefois poser des limites si la quantité de données à partager est importante, mais c'est un problème pas moins difficile à résoudre que d'écrire de programme multithreads sans bugs.

2. Beaucoup de programmes qui utilisent les threads sont IO-bound (on gère des opérations bloquantes) et dans ce cas, les threads en Python marchent très bien.

Un autre aspect sur le GIL qu'on peut rappeler, c'est que retirer le GIL sans affecter les performances des programmes mono-threads est extrèmement difficile. Sans verrou global, il y aura une multiplicité de verrous locaux à utiliser, ce qui dégrade le cas mono-thread.

Pour l'instant, à part une solution miracle que nous sortirait PyPy, le GIL est là pour rester

Dans ce cas, présis, ça a un sens d'avoir un entier associé avec le niveau de log. Tu peux ainsi définir assez facilement la notion de "tous les messages avec un niveau de log supérieur à ERROR" (ERROR + FATAL), "tous les messages avec un niveau de log supérieur à INFO" ( = INFO + WARNING + ERROR + FATAL).

Cela dit, ton besoin d'un symbole abstrait (si je l'ai bien compris) est justement couvert par l'ajout du module Enum à Python 3.4 :

>>> from enum import Enum
>>> Animal = Enum('Animal', 'ant bee cat dog')
>>> myPet = Animal.ant
>>> yourPet = Animal.beee
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    yourPet = Animal.beee
  File "C:\Python34\lib\enum.py", line 236, in __getattr__
    raise AttributeError(name) from None
AttributeError: beee
>>> 

Et tu gagnes en plus une vérification syntaxique à l'assignation de ta variable et non pas à son utilisation…

Pour reprendre ton exemple plus haut en ruby, par exemple, si tu remplaces :WARNING par :WAAAARNING, l'erreur ne sera visible que au niveau du h.setLevel(i) et pas lors de l'énumération des champs possibles.

Si Python utilisais un Enum pour gérer ça, tu aurais un logging.LogLevels = Enum('DEBUG', 'INFO', 'WARNING', 'ERROR' ) et tu pourrais faire :

for i in logging.LogLevels:
    ...

Mais globalement, si on regarde ça d'un peu plus haut, les différences sont globalement mineures et ne transforment pas massivement ni l'expressivité, ni la fonctionnalité dans un langage ou dans un autre.

Bref, c'est de l'enc******* de mouche .

asyncio, c'est vraiment la killer-feature de cette nouvelle version. Ca pourrait à lui seul justifier que des projets emprisonnés dans Python 2.7 passent en Python 3! Sauf que … il existe un backport Python 2 !

Finalement, presque la totalité des goodies de la lib de Python 3.4 sont disponibles sous forme de backport pour des version inférieures, et notamment Python 2.7 . Et côté évolution du runtime ou du langage, les évolutions ont l'air utiles mais ont relativement peu de chances d'impacter le développeur python "moyen" qui ne pousse pas Python dans ses retranchements. Ah si quand même, les évolutions autour de SSL, va vaut le coup.

Les entrées:

• un document word qui est une spec de test assez générale
• un document html généré par ma suite de test Python qui est le plan de test exact.

Evidemment, si je peux me passer de générer le html du plan de test, c'est encore mieux. Dans ce cas, un **/test_*.py est parfait.

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…