Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.
Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.
Chacun ses contraintes, mais eux ont le financement :p
Et au pire quand ça pète ils sont plus dans la même boîte :D
Blague a part, je ne voulais pas dire que perl est mieux que les autres. Ce que je voulais dire, c'est que ton point n'était pas autant en défaveur de perl qu'il n'en donne l'impression, parce que justement il y a une grosse de base de code qui existe, et que ce n'est pas parce que les utilisateurs de perl sont discrets qu'ils n'existent pas.
Pour prendre un cas bien, bien extrême (on est vendredi après tout): "cobol is still relevant in 2022". Ca recrute encore sur cette tech, et il faut bien maintenir, le temps de finir les migrations, si elles ont été commencées, ce qui est loin d'être garantit partout.
Qu'un langage devienne un langage de niche n'est pas choquant, surtout que bon, perl, ça a toujours été un langage de niche pour moi: conçu pour remplacer /bin/sh, awk, grep, sed... mais les gens utiliserons toujours ces outils la en premier, par simple flemme et puis c'est ce qui est utilisé dans le terminal. Puis c'est simple. Chiant a maintenir quand ça se développe, un peu comme un fichier excel, et perl serait un peu le ms access du coup. Possiblement moins chiant, mais pas le truc qu'on fait naturellement.
Et je n'utiliserais pas perl sur de l'embarqué ou la contrainte de stockage est hyper forte. J'ai souri quand j'ai vu l'article considérer qu'une raspberry pi c'est serré... Je veux dire, il y a combien de stockage sur un rPI? Sur les BBB, de mémoire il y a un lecteur de carte + 8 gig de stockage. Tellement de place que c'est dur à remplir, si on fait juste un peu attention.
microperl A small standalone perl interpreter that can be built from the perl sources via "make -f Makefile.micro". If you really feel the need for perl on an embedded system, this is where to start.
Suivi juste après d'une phrase qui semble plutôt encourager à utiliser lua pour du code neuf. Et en terme d'embarqué ultra contraint, j'aurai tendance a me fier aux auteurs de busybox.
D'ailleurs, vu qu'il existe des compilateurs python, je dirais même que ça serait la solution la plus simple: une fois compilé, j'ose espérer que les programmes sont plus compacts que tout l'environnement (et plus rapide, mais ça, tant qu'on n'a pas mesuré, on peut pas savoir si c'est pertinent, et impossible d'avoir une estimation simple et générique, contrairement au stockage).
Ma question est plutôt sur le nombre de paquets a installer, et maintenir. Le contexte de cyber sécurité est loin d'être détendu, il me semble, donc même si je sais que la sécurité on s'en fout un peu, il me semble que faciliter la maintenance et réduire la surface d'attaque, c'est pas une mauvaise chose.
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.
[^] # Re: Vraie question
Posté par freem . En réponse au lien why PERL is still relevant in 2022?. Évalué à 4.
Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.
Et au pire quand ça pète ils sont plus dans la même boîte :D
Blague a part, je ne voulais pas dire que perl est mieux que les autres. Ce que je voulais dire, c'est que ton point n'était pas autant en défaveur de perl qu'il n'en donne l'impression, parce que justement il y a une grosse de base de code qui existe, et que ce n'est pas parce que les utilisateurs de perl sont discrets qu'ils n'existent pas.
Pour prendre un cas bien, bien extrême (on est vendredi après tout): "cobol is still relevant in 2022". Ca recrute encore sur cette tech, et il faut bien maintenir, le temps de finir les migrations, si elles ont été commencées, ce qui est loin d'être garantit partout.
Qu'un langage devienne un langage de niche n'est pas choquant, surtout que bon, perl, ça a toujours été un langage de niche pour moi: conçu pour remplacer /bin/sh, awk, grep, sed... mais les gens utiliserons toujours ces outils la en premier, par simple flemme et puis c'est ce qui est utilisé dans le terminal. Puis c'est simple. Chiant a maintenir quand ça se développe, un peu comme un fichier excel, et perl serait un peu le ms access du coup. Possiblement moins chiant, mais pas le truc qu'on fait naturellement.
Et je n'utiliserais pas perl sur de l'embarqué ou la contrainte de stockage est hyper forte. J'ai souri quand j'ai vu l'article considérer qu'une raspberry pi c'est serré... Je veux dire, il y a combien de stockage sur un rPI? Sur les BBB, de mémoire il y a un lecteur de carte + 8 gig de stockage. Tellement de place que c'est dur à remplir, si on fait juste un peu attention.
Sur le site de busybox on peut lire:
Suivi juste après d'une phrase qui semble plutôt encourager à utiliser lua pour du code neuf. Et en terme d'embarqué ultra contraint, j'aurai tendance a me fier aux auteurs de busybox.
D'ailleurs, vu qu'il existe des compilateurs python, je dirais même que ça serait la solution la plus simple: une fois compilé, j'ose espérer que les programmes sont plus compacts que tout l'environnement (et plus rapide, mais ça, tant qu'on n'a pas mesuré, on peut pas savoir si c'est pertinent, et impossible d'avoir une estimation simple et générique, contrairement au stockage).
Ma question est plutôt sur le nombre de paquets a installer, et maintenir. Le contexte de cyber sécurité est loin d'être détendu, il me semble, donc même si je sais que la sécurité on s'en fout un peu, il me semble que faciliter la maintenance et réduire la surface d'attaque, c'est pas une mauvaise chose.
Si un jour ruby ou python remplacement complètement perl dans le coeur de mon système, j'aurai le même type de critique contre l'usage de perl. Et le point ici, ce n'set pas vraiment l'espace disque, même s'il peut parfois être pertinent. C'est plutôt le problème de maintenance, de surveiller les failles de sécurité (qui existent dans tout éco-système, je ne crois pas que perl soit tellement mieux de ce point de vue) et de pouvoir boucher les trous. C'est plus facile de limiter le nombre de trous, quand il y a moins de trucs installés, c'est tout.