la distinction est de taille: si moarvm est clairement la vm de choix pour perl6, rakudo vise plusieurs backends (celui de la JVM par exemple ne me laisse pas indifférent: il y a des milliards de dollars qui ont été balancés dans écosystème java. se dire qu'on peut réutiliser tous ces outils sans avoir à se tapper des langages tels que java ou kotlin me parait bien agréable). aussi c'est dommage de passer NQP sous silence.
tous les vieux tricks sont accessibles mais la communauté perl a eu tendance a mettre de jolis modules avec de la jolie syntaxe devant (comme le framework objet Moo https://metacpan.org/pod/Moo plutot que de faire des bless à la main, Path::Tiny pour accéder à tes fichiers , … ). les signatures sont arrivés, comme plein de petites améliorations ici et là dans le langage qui permettent des choses assez élégantes.
après: perl reste perl avec ces blocks anonymes, ses variables magiques (mais tellement pratiques), l'expressivité des sigils et ses choix de comportement par défaut qui nécessite de comprendre immédiatement ce qui est vendu comme de la killer feature avancée dans les autres langages (comme le spread operator de JS ou le ** de python
perso je dirais que ca ne vaut plus le coup d'apprendre perl5 (ou js ou python ou tout autre langage de plus de 20 ans d'age) si on en a pas besoin: perl6 a posé la barre bien plus haut en terme d'expressivité en plus d'avoir une cohérence qu'aucun vieux langage ne peut assurer
Tu peux aussi utiliser Function::Parameters (https://metacpan.org/pod/Function::Parameters) qui utilise les pluggable keywords donc ca marche depuis perl 5.12. on l'utilise dans le module Sympatic (https://metacpan.org/pod/Sympatic), l'overhead est faible et le systeme de signatures est plus riche que celui qui est actuellement experimental
rakudo n'est pas une vm! c'est l'implémentation de la spec perl6 en NQP ce qui permet d'avoir plusieurs VM (a ce jour moarvm, la vm officielle, jvm et transpilation vers js).
pug était un interpreteur écrit en haskell. pas une vm non plus donc
au lieu d'avoir 20 interfaces sur lesquels il te faille te balader parceque tu participes à 20 listes différentes, tu a une seule interface parfaitement intégrée a tes outils (les memes abbréviations, completion et mappings partout la capacité de comparer facilement un bout de code d'une réponse avec la version que tu as dans ton repo (en mode diff), le fait d'avoir des bouts de reponse pretes a l'emploi dans le cas ou tu fais de l'assistance), que le tout soit extensible avec qq lignes de shell ou de viml de temps en temps … quelle interface graphique, aussi jolie soit-elle, ne me forcera a abandonner ce confort. et puis quand tu as l'habitude de vim, les textareas sont juste des plaies.
ca fait 20 ans que je me forge cet environnement a coup d'une ligne de conf de temps à autres et je me rend compte quand je fais le menage de temps en temps que ca fait 20 ans que ce systeme m'accompagne dans mes pratiques, mes macros ont evolué en fonction du job du moment pendant que d'autres allaient d'un outils à l'autre. cette régularité aussi, je l'apprécie parceque chaque nouvelle connaissance et experience est rentabilisée sur un long terme et donc gratifiante comme aucune interface web ne le sera jamais.
bon alors ca c'est clairement une question qui vaudrait un article sur mon blog … parceque c'est long et j'avoue ne pas avoir le temps de m'y consacrer immédiatement. mais en résumé très vite (et du coup ca pourrait paraitre naif comme ca …)
les réseaux sociaux sont soit centralisés et privés, soit décentralisés et pas ou peu adoptés. nous on pense que smtp est déjà un réseau social décentralisé qui manque d'une bonne interface web.
aujourd'hui les trolls sont réguliers pour savoir si les communautés doivent utiliser les web fora ou les messages pour communiquer. pour ce qui est de ma propre experience: je n'ai jamais vu la moindre interface web qui approche de pret ou de loin ce que je peux faire avec mutt/vim/(qq fonctions zsh) mais je comprend que nombre d'entre nous n'aie pas envie de se mettre à ce genre d'outils. il faut donc un systeme qui permettent les deux interfaces (mail et web) et pe plus encore. c'est ce qu'est deja sympa (page de post+archive) mais l'interface web est catastrophique: on compte changer ca
c'est non seulement plus simple pour les contributeurs mais aussi pour nous: ils connaissent github et nous n'avons aucune doc spécifique à écrire, aucune assistance ou presque a faire.
je crois que toutes les solutions évoquées actuellement nécessitent un passage à git mais nous espérons faire ça bien en contactant les projets actifs, leur expliquer l'intéret qu'ils auraient à passer a git et les assister dans cette démarche (de la formation si besoin).
les avantages sont nombreux et dépendront de l'outils choisi mais si tu vas sur github par exemple, les fonctionnalités proposées pour voir l'état et l'activité de ton projet, créer des branches facilement, faire des pull requests, tagger les tickets sont clairement des choses qui aident la contribution.
ensuite: l'intégration de l'intégration continue et pe a terme du déploiement continu sont un énorme gain.
effectivement: pour le moment tout dans le code est pensé pour faire tourner de gros sites et YUnohost nous lance clairement un défi: faire tourner sympa sur un Pi.
d'un autre coté: les discutions qu'il y a eu pendant le hackathon autour de l'autohébergement et les fonctionnalités qui pouvaient en découler font que c'est un dossier qu'on va vraiment prendre en compte dans la refonte de sympa. Je n'espère rien de la branche actuelle.
nous partageons complètement ton analyse … à tel point que je suis en train de plancher sur un nouvel archiver. si tu as des idées ou envie d'échanger: n'hésite pas à me contacter ou venir en discuter sur la liste https://listes.renater.fr/sympa/info/sympa-fr.
ca n'est pas du gout de tout le monde (github ca pue c'est pas libre, tout ca …) mais c'était pragmatique et le release manager actuel (Soji) est très content de la situation actuelle. Il y a clairement plus de contributions sporadiques qu'avant mais je ne crois pas que ce soit simplement lié a github: le hackathon lui-même a amené de nouveaux contributeurs dans le projet.
perso j'ai pas d'avis ferme par rapport a github: par principe, j'étais plus attaché à sourcesup mais l'outils est clairement daté.
certes, les backends llvm ont tjrs des perfs intéressantes mais en comparant des implémentations naives, le benchmark ne reflète qu'un avantage théorique qui n'a pas de lien avec la réalité. Je ne pense pas que ce benchmark est volontairement partial: il met juste en évidence ce que les développeurs de gambas s'attendaient à trouver.
Toutefois, lorsque des problèmes de performance se posent, on se met a regarder le code (après lecture diagonale, on se débarrasse du double parcours de tableau dans la boucle qui creuse inutilement l'écart) et on utilise les outils adaptés (pdl en perl et je pense que ce serait numpy pour python).
ça serait donc intéressant de voir des codes plus idiomatiques et pratiques remplacer les benchs existants.
ensuite: comparer avec des langages dynamiques c'est pas très sport! les implémentations haskell ou go seraient plus courtes que leurs équivalentes gambas: quid des perfs dans ces deux languages?
bref… si qq1 a un peu de temps libre, ça peut être intéressant de fournir à la communauté gambas des chiffres plus objectifs (je répète que je ne crois toutefois pas qu'il y ai eu un quelconque calcul propagandiste!)
[^] # Re: on peut modifier l'article ?
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 2.
la distinction est de taille: si moarvm est clairement la vm de choix pour perl6, rakudo vise plusieurs backends (celui de la JVM par exemple ne me laisse pas indifférent: il y a des milliards de dollars qui ont été balancés dans écosystème java. se dire qu'on peut réutiliser tous ces outils sans avoir à se tapper des langages tels que java ou kotlin me parait bien agréable). aussi c'est dommage de passer NQP sous silence.
[^] # Re: En tout cas ...
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 1.
tous les vieux tricks sont accessibles mais la communauté perl a eu tendance a mettre de jolis modules avec de la jolie syntaxe devant (comme le framework objet Moo https://metacpan.org/pod/Moo plutot que de faire des bless à la main, Path::Tiny pour accéder à tes fichiers , … ). les signatures sont arrivés, comme plein de petites améliorations ici et là dans le langage qui permettent des choses assez élégantes.
après: perl reste perl avec ces blocks anonymes, ses variables magiques (mais tellement pratiques), l'expressivité des sigils et ses choix de comportement par défaut qui nécessite de comprendre immédiatement ce qui est vendu comme de la killer feature avancée dans les autres langages (comme le spread operator de JS ou le ** de python
perso je dirais que ca ne vaut plus le coup d'apprendre perl5 (ou js ou python ou tout autre langage de plus de 20 ans d'age) si on en a pas besoin: perl6 a posé la barre bien plus haut en terme d'expressivité en plus d'avoir une cohérence qu'aucun vieux langage ne peut assurer
[^] # Re: Prototypes et signatures
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 1.
Tu peux aussi utiliser Function::Parameters (https://metacpan.org/pod/Function::Parameters) qui utilise les pluggable keywords donc ca marche depuis perl 5.12. on l'utilise dans le module Sympatic (https://metacpan.org/pod/Sympatic), l'overhead est faible et le systeme de signatures est plus riche que celui qui est actuellement experimental
[^] # Re: on peut modifier l'article ?
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 2.
oui mais là vraiment je suis sur de moi: ca fait des années que je surveille perl6
[^] # Re: on peut modifier l'article ?
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 5.
bon en fait c'est l'article wikipédia qui dit de la merde. je note dans ma todolist
# on peut modifier l'article ?
Posté par eiro . En réponse à la dépêche Sortie de Perl 5.30.0. Évalué à 5.
je n'ai pas encore tout lu mais en diagonal:
[^] # Re: Actualité du courriel en 2017
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 2.
au lieu d'avoir 20 interfaces sur lesquels il te faille te balader parceque tu participes à 20 listes différentes, tu a une seule interface parfaitement intégrée a tes outils (les memes abbréviations, completion et mappings partout la capacité de comparer facilement un bout de code d'une réponse avec la version que tu as dans ton repo (en mode diff), le fait d'avoir des bouts de reponse pretes a l'emploi dans le cas ou tu fais de l'assistance), que le tout soit extensible avec qq lignes de shell ou de viml de temps en temps … quelle interface graphique, aussi jolie soit-elle, ne me forcera a abandonner ce confort. et puis quand tu as l'habitude de vim, les textareas sont juste des plaies.
ca fait 20 ans que je me forge cet environnement a coup d'une ligne de conf de temps à autres et je me rend compte quand je fais le menage de temps en temps que ca fait 20 ans que ce systeme m'accompagne dans mes pratiques, mes macros ont evolué en fonction du job du moment pendant que d'autres allaient d'un outils à l'autre. cette régularité aussi, je l'apprécie parceque chaque nouvelle connaissance et experience est rentabilisée sur un long terme et donc gratifiante comme aucune interface web ne le sera jamais.
[^] # Re: Actualité du courriel en 2017
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 3.
bon alors ca c'est clairement une question qui vaudrait un article sur mon blog … parceque c'est long et j'avoue ne pas avoir le temps de m'y consacrer immédiatement. mais en résumé très vite (et du coup ca pourrait paraitre naif comme ca …)
les réseaux sociaux sont soit centralisés et privés, soit décentralisés et pas ou peu adoptés. nous on pense que smtp est déjà un réseau social décentralisé qui manque d'une bonne interface web.
aujourd'hui les trolls sont réguliers pour savoir si les communautés doivent utiliser les web fora ou les messages pour communiquer. pour ce qui est de ma propre experience: je n'ai jamais vu la moindre interface web qui approche de pret ou de loin ce que je peux faire avec mutt/vim/(qq fonctions zsh) mais je comprend que nombre d'entre nous n'aie pas envie de se mettre à ce genre d'outils. il faut donc un systeme qui permettent les deux interfaces (mail et web) et pe plus encore. c'est ce qu'est deja sympa (page de post+archive) mais l'interface web est catastrophique: on compte changer ca
[^] # Re: github
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 1.
c'est non seulement plus simple pour les contributeurs mais aussi pour nous: ils connaissent github et nous n'avons aucune doc spécifique à écrire, aucune assistance ou presque a faire.
[^] # Re: github
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 1.
je crois que toutes les solutions évoquées actuellement nécessitent un passage à git mais nous espérons faire ça bien en contactant les projets actifs, leur expliquer l'intéret qu'ils auraient à passer a git et les assister dans cette démarche (de la formation si besoin).
les avantages sont nombreux et dépendront de l'outils choisi mais si tu vas sur github par exemple, les fonctionnalités proposées pour voir l'état et l'activité de ton projet, créer des branches facilement, faire des pull requests, tagger les tickets sont clairement des choses qui aident la contribution.
ensuite: l'intégration de l'intégration continue et pe a terme du déploiement continu sont un énorme gain.
je te propose de t'inscrire sur libresup (https://groupes.renater.fr/sympa/info/suplibre), j'aimerais clairement y ouvrir le débat.
[^] # Re: github
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 1.
la seule chose que je peux te dire c'est que la discution est clairement en cours avec des gens qui poussent
[^] # Re: Yunohost ?
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 3.
effectivement: pour le moment tout dans le code est pensé pour faire tourner de gros sites et YUnohost nous lance clairement un défi: faire tourner sympa sur un Pi.
d'un autre coté: les discutions qu'il y a eu pendant le hackathon autour de l'autohébergement et les fonctionnalités qui pouvaient en découler font que c'est un dossier qu'on va vraiment prendre en compte dans la refonte de sympa. Je n'espère rien de la branche actuelle.
[^] # Re: Archives
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 4.
nous partageons complètement ton analyse … à tel point que je suis en train de plancher sur un nouvel archiver. si tu as des idées ou envie d'échanger: n'hésite pas à me contacter ou venir en discuter sur la liste https://listes.renater.fr/sympa/info/sympa-fr.
[^] # Re: Les idées de design d'interface
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 2.
un logiciel proprio sous mac qui s'appelle sketch. Quentin était clair là dessus: y'a juste pas d'alternative correcte
[^] # Re: github
Posté par eiro . En réponse à la dépêche Actualités Sympa. Évalué à 2.
ca n'est pas du gout de tout le monde (github ca pue c'est pas libre, tout ca …) mais c'était pragmatique et le release manager actuel (Soji) est très content de la situation actuelle. Il y a clairement plus de contributions sporadiques qu'avant mais je ne crois pas que ce soit simplement lié a github: le hackathon lui-même a amené de nouveaux contributeurs dans le projet.
perso j'ai pas d'avis ferme par rapport a github: par principe, j'étais plus attaché à sourcesup mais l'outils est clairement daté.
[^] # Re: Material ?
Posté par eiro . En réponse à la dépêche Hackathon pour les vingt ans de sympa les 1ᵉʳ et 2 avril 2017. Évalué à 1.
j'ai demandé à notre lead frontend. il m'a dit "pas la peine de répondre: Moonz a tout dit"
# des chiffres plus réalistes
Posté par eiro . En réponse à la dépêche Sortie de Gambas 3.3. Évalué à 2.
salut,
certes, les backends llvm ont tjrs des perfs intéressantes mais en comparant des implémentations naives, le benchmark ne reflète qu'un avantage théorique qui n'a pas de lien avec la réalité. Je ne pense pas que ce benchmark est volontairement partial: il met juste en évidence ce que les développeurs de gambas s'attendaient à trouver.
Toutefois, lorsque des problèmes de performance se posent, on se met a regarder le code (après lecture diagonale, on se débarrasse du double parcours de tableau dans la boucle qui creuse inutilement l'écart) et on utilise les outils adaptés (pdl en perl et je pense que ce serait numpy pour python).
ça serait donc intéressant de voir des codes plus idiomatiques et pratiques remplacer les benchs existants.
ensuite: comparer avec des langages dynamiques c'est pas très sport! les implémentations haskell ou go seraient plus courtes que leurs équivalentes gambas: quid des perfs dans ces deux languages?
bref… si qq1 a un peu de temps libre, ça peut être intéressant de fournir à la communauté gambas des chiffres plus objectifs (je répète que je ne crois toutefois pas qu'il y ai eu un quelconque calcul propagandiste!)
[^] # Re: Han !
Posté par eiro . En réponse à la dépêche Journées Perl : dernières infos pratiques. Évalué à 0.
il "fallait" pas s'inscrire mais c'est tjrs fortement conseillé pour avoir les actus, participer au wiki sur les animations et tout ca …
par contre oui: si tu veux du réseau, ton id me transmettre tu dois.
[^] # Re: Oui mais…
Posté par eiro . En réponse à la dépêche Journées Perl : dernières infos pratiques. Évalué à 0.
comme je le disais plus bas: ne pas écrire a epitech directement: je centralise les demandes et leur transmet un CSV.
marc
# Surtout ne dérrangez pas Epitech!
Posté par eiro . En réponse à la dépêche Journées Perl : dernières infos pratiques. Évalué à 1.
salut a tous,
merci de ne pas déranger les gens d'épitech! vous pouvez m'envoyer un mail a ( khatar [at] phear [dot] org ): je traiterais.
(la plupart des gens m'ont transmis les infos par reply sur les listes de diff).
cordialement
marc