So far for a simple Vim script running a loop while Vim currently takes five seconds to run, the Vim9 code can run it in 0.07 seconds, about the same amount of time as a Lua script and quicker than Python. In a more relevant code snippet, Vim9 could run a script in 0.19 seconds compared to 0.85 seconds previously.
C'est juste que le boulot est terminé, d'où l'annonce.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
J'y ai pensé, mais comme je ne pratique pas le Hard Way et n'ai pas suivi le développement (là on est plus ou moins en phase RC, à moins que ce ne soit une // ?), je me suis dit que ça peut attendre la sortie officielle…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je préfère l'approche Neovim qui utilise Lua, ce langage rodé et fiable.
Je me méfie de quelqu'un qui crée un langage et dont la signature explose les limites du tableau:
hundred-and-one symptoms of being an internet addict:
115. You are late picking up your kid from school and try to explain
to the teacher you were stuck in Web traffic.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Vim supports interfaces to Perl, Python, Lua, Tcl and a few others. But these interfaces have never become widely used, for various reasons. When Vim9 was designed a decision was made to make these interfaces lower priority and concentrate on Vim script.
Still, plugin writers may find other languages more familiar, want to use existing libraries or see a performance benefit. We encourage plugin authors to write code in any language and run it as an external tool, using jobs and channels. We can try to make this easier somehow.
Using an external tool also has disadvantages. An alternative is to convert the tool into Vim script. For that to be possible without too much translation, and keeping the code fast at the same time, the constructs of the tool need to be supported. Since most languages support classes the lack of support for classes in Vim is then a problem.
Le premier paragraphe adresse ta remarque : Neovim ne fait qu'utiliser ce que ce quelqu'un avait déjà mis en place… Le troisième paragraphe t'explique pourquoi ça ne peut jamais être optimal avec le DSL existant, et le but est justement d'améliorer ce DSL avec le retour d'expérience. Ah les fans…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je me exprimé de façon lapidaire, je vais développer un peu.
Vim9 tente de corriger les défauts du VimL (son langage de script dédié d'origine) avec un nouveau langage de script.
Qui va utiliser ce langage ?
Les utilisateurs de Neovim sont passés à Lua, qui a l'avantage d'avoir été mis au point dans une sphère plus large que l'écosystème d'un éditeur de texte. Un autre avantage de Lua est sa rapidité d'exécution (pas le plus important, mais ça fait toujours plaisir) et sa robustesse (dû à une simplicité parfois critiquée, le débat « tables vs dict/array/liste… »).
Les utilisateurs de Vim sont maintenant confrontés à un choix cornélien: réécrire les scripts VimL, comme si ils passaient à neovim en adoptant Lua ? Dans ce cas, quel intérêt ? L'utilisateur de Vim tient souvent à la rétrocompatibilité du VimL, qui assure qu'un script développé pour Vim7 tournera encore dans Vim9. Ça ne sera plus le cas avec le nouveau langage, et je suis prêt à parier que bien des utilisateurs de Vim9 resteront à l'ancien système de script.
L'auteur de Vim s'épuise dans une feature qui sera peu ou pas utilisée, et qui va fragmenter sa communauté. Quand à l'argument de l'optimalité, Vim9+nouveau langage ne fait pas mieux que Neovim+Lua (et je parle de l'interpréteur Lua, pas d'un Neovim compilé avec le support Luajit). Même les benches présentés par l'auteur de Vim ne montrent pas de spectaculaire gain de vitesse, surtout par rapport à tous les problèmes qu'il va soulever en effets de bord.
Un nouveau langage de script est toujours délicat, même au sein d'une communauté florissante. Je ne suis pas certain que la communauté de Vim ait quelque chose à gagner (dans son ensemble) à une nouvelle fragmentation. Ce genre de décision risque surtout de favoriser les éditeurs de texte (je ne nommerai personne) qui ont le vent en poupe.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Voilà, il tente de corriger les limites de VimL : ce n'étaient pas forcément un défaut et n'avait pas été accueilli comme tel ; mais avec l'évolution des contributions et les plugins qui deviennent de véritables applications ça commence à s'essouffler.
Encore une fois, Lua (et pas que) est déjà disponible avec Vim (Neovim ne l'a pas inventé) mais n'est pas tant utilisé que ça (même dans Neovim il y a pas mal de plugins utilisant VimL.) Outre ce constat, ces langages éprouvés et robustes, comme tu dis, se heurtent à un mur : ce n'est pas du natif mais une traduction en quelque chose qui sera interprété par Vim (comme l'est VimL.)
Par contre, je pense (et croise les doigts car n'ayant pas regardé l'évolution du code) que ce travail va bénéficier à tous : le mur sera repoussé pour les autres langages qui s'exécuteront plus vite aussi.
Comme tu n'as pas regardé la doc, tu n'as pas compris que la rétrocompatibilité est conservée. Les scripts pour Vim7 continueront à fonctionner avec Vim9. Par contre, si power-user décide de faire un truc pour Vim>9 ça ne bénéficiera pas aux anciennes versions (encore que les mécanismes pour faire le taf en double sont prévu si certaines personnes y tiennent ; auquel cas on aura un truc plus rapide avec Vim9 et suivant mais qui marchera quand même pour les anciens.)
On a déjà eu le cas avec chaque version majeure depuis Vim4 : des ajouts qui fonctionnent pour les nouvelles versions mais pas les anciennes, tout en gardant la compatibilité. La seule question est donc qui va l'utiliser. Et si ce n'est pas utiliser, bah y aura qu'à retirer de Vim10. Évolution et non fragmentation (FUD gratuit)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# vimscript reborn
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
J'ai pointé vers l'annonce faite hier sur la liste dédiée, pour donner le contexte. J'aurais pu pointer directement vers https://github.com/vim/vim/blob/master/runtime/doc/vim9.txt
On a souvent reproché à VimL, le langage dédié, de ne pas être élégant ni assez rapide. Braam a donc remis sur l'établi et s'est attaqué à ce dernier point. https://www.reddit.com/r/vim/comments/ejfn57/vim9/
Le nouveau langage, Vim9Script?, est fortement inspiré de JS et les résultats sont époustouflants… https://groups.google.com/g/vim_dev/c/OPbZwpcBP98
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: vimscript reborn
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Phronix en avait déjà causé positivement en janvier 2020 : Vim Creator Bram Moolenaar Aiming To Improve Vim Performance With Vim9 Fork
C'est juste que le boulot est terminé, d'où l'annonce.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Statuts
Posté par barmic 🦦 . Évalué à 2.
Ça aurait mérité un journal :-)
Il demande encore si des gens ont des remarques, c'est mergé mais pas releasé ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Statuts
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 01 janvier 2022 à 10:12.
J'y ai pensé, mais comme je ne pratique pas le Hard Way et n'ai pas suivi le développement (là on est plus ou moins en phase RC, à moins que ce ne soit une
/
/ ?), je me suis dit que ça peut attendre la sortie officielle…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Ça Bram dans les repos
Posté par jseb . Évalué à 3.
Je préfère l'approche Neovim qui utilise Lua, ce langage rodé et fiable.
Je me méfie de quelqu'un qui crée un langage et dont la signature explose les limites du tableau:
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Ça Bram dans les repos
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Et c'est parti… (mais je l'espérais pour vendredi, hier étant sur le fuseau CET)
:-)Il y a une neuvième/dernière partie du lien pointé, « Rationale », avec une section « Why not use an embedded language? » que je te recopies.
Le premier paragraphe adresse ta remarque : Neovim ne fait qu'utiliser ce que ce quelqu'un avait déjà mis en place… Le troisième paragraphe t'explique pourquoi ça ne peut jamais être optimal avec le DSL existant, et le but est justement d'améliorer ce DSL avec le retour d'expérience. Ah les fans…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ça Bram dans les repos
Posté par jseb . Évalué à 3.
Je me exprimé de façon lapidaire, je vais développer un peu.
Vim9 tente de corriger les défauts du VimL (son langage de script dédié d'origine) avec un nouveau langage de script.
Qui va utiliser ce langage ?
Les utilisateurs de Neovim sont passés à Lua, qui a l'avantage d'avoir été mis au point dans une sphère plus large que l'écosystème d'un éditeur de texte. Un autre avantage de Lua est sa rapidité d'exécution (pas le plus important, mais ça fait toujours plaisir) et sa robustesse (dû à une simplicité parfois critiquée, le débat « tables vs dict/array/liste… »).
Les utilisateurs de Vim sont maintenant confrontés à un choix cornélien: réécrire les scripts VimL, comme si ils passaient à neovim en adoptant Lua ? Dans ce cas, quel intérêt ? L'utilisateur de Vim tient souvent à la rétrocompatibilité du VimL, qui assure qu'un script développé pour Vim7 tournera encore dans Vim9. Ça ne sera plus le cas avec le nouveau langage, et je suis prêt à parier que bien des utilisateurs de Vim9 resteront à l'ancien système de script.
L'auteur de Vim s'épuise dans une feature qui sera peu ou pas utilisée, et qui va fragmenter sa communauté. Quand à l'argument de l'optimalité, Vim9+nouveau langage ne fait pas mieux que Neovim+Lua (et je parle de l'interpréteur Lua, pas d'un Neovim compilé avec le support Luajit). Même les benches présentés par l'auteur de Vim ne montrent pas de spectaculaire gain de vitesse, surtout par rapport à tous les problèmes qu'il va soulever en effets de bord.
Un nouveau langage de script est toujours délicat, même au sein d'une communauté florissante. Je ne suis pas certain que la communauté de Vim ait quelque chose à gagner (dans son ensemble) à une nouvelle fragmentation. Ce genre de décision risque surtout de favoriser les éditeurs de texte (je ne nommerai personne) qui ont le vent en poupe.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Ça Bram dans les repos
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Voilà, il tente de corriger les limites de VimL : ce n'étaient pas forcément un défaut et n'avait pas été accueilli comme tel ; mais avec l'évolution des contributions et les plugins qui deviennent de véritables applications ça commence à s'essouffler.
Encore une fois, Lua (et pas que) est déjà disponible avec Vim (Neovim ne l'a pas inventé) mais n'est pas tant utilisé que ça (même dans Neovim il y a pas mal de plugins utilisant VimL.) Outre ce constat, ces langages éprouvés et robustes, comme tu dis, se heurtent à un mur : ce n'est pas du natif mais une traduction en quelque chose qui sera interprété par Vim (comme l'est VimL.)
Par contre, je pense (et croise les doigts car n'ayant pas regardé l'évolution du code) que ce travail va bénéficier à tous : le mur sera repoussé pour les autres langages qui s'exécuteront plus vite aussi.
Comme tu n'as pas regardé la doc, tu n'as pas compris que la rétrocompatibilité est conservée. Les scripts pour Vim7 continueront à fonctionner avec Vim9. Par contre, si power-user décide de faire un truc pour Vim>9 ça ne bénéficiera pas aux anciennes versions (encore que les mécanismes pour faire le taf en double sont prévu si certaines personnes y tiennent ; auquel cas on aura un truc plus rapide avec Vim9 et suivant mais qui marchera quand même pour les anciens.)
On a déjà eu le cas avec chaque version majeure depuis Vim4 : des ajouts qui fonctionnent pour les nouvelles versions mais pas les anciennes, tout en gardant la compatibilité. La seule question est donc qui va l'utiliser. Et si ce n'est pas utiliser, bah y aura qu'à retirer de Vim10. Évolution et non fragmentation (FUD gratuit)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.