Discussion :

[GeantVert13]

Bonjour tout le monde.

Merci de prendre quelques instants pour lire ce message.

Dans le cadre professionnel je cherche un language de script duquel je peux facilement appeler des méthodes écrites en C++.
En ce moment nous utilisons xml, mais c'est très limité dès qui s'agit de faire des itération, des test, (il faudrait écrire notre propre intérpréteur).

Je veux par exemple écrire une code du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
string s
s=une chaine contenant en général des valeurs hexa
exchange(s,response)

la fonction/procédure exchange correspondrait à une méthode en C++ et response est le résultat du traitement de cette méthode.

voilà en peu de mots ma problèmatique.... des idées ?

Merci

[Jedai]

La plupart des solutions de cet ordre sont pour C plutôt que C++, pour un tas de bonnes raisons... Néanmoins selon le langage de script que tu veux utiliser il peut y avoir des solutions, par exemple Inline::CPP en Perl fournit une solution plutôt agréable à utiliser.

--
Jedaï

[Mat.M]

Dans le cadre professionnel je cherche un language de script duquel je peux facilement appeler des méthodes écrites en C++.
Merci

Le grand classique c'est LUA très utilisé en programmation jeu vidéo mais qui devrait te satisfaire pleinement
http://www.lua.org/

Plus léger, Angelscript
http://www.angelcode.com/angelscript/

[GeantVert13]

Merci pour vos réponses.

Je vais déjà examiner ces solutions là.

[GeantVert13]

Re-bonjour,

à priori Lua serait un candidat sérieux, angelscript à l'air bien aussi, mais comme c'est assez peu connu, j'ai peur pour la pérennité... (je ne connaissais pas Lua non plus, mais ça a l'air d'être très utilisé)

Je pensais également à Python, avez vous des retours d'expérience à ce propos ?

Merci

[Jedai]

à priori Lua serait un candidat sérieux, angelscript à l'air bien aussi, mais comme c'est assez peu connu, j'ai peur pour la pérennité... (je ne connaissais pas Lua non plus, mais ça a l'air d'être très utilisé)

Je pensais également à Python, avez vous des retours d'expérience à ce propos ?

Pourquoi Perl ne fait-il pas partie des options ? C'est un langage extrêmement puissant, capable de s'interfacer avec C et C++ (et autres langages) facilement par les modules Inline::*, disposant de la plus large bibliothèques de modules externes facilement installable (le CPAN), multi-plateforme...

--
Jedaï

[GeantVert13]

Perl, me paraissait justement plus compliqué pour ce que j'ai à faire...

il me faut un langage de script qui puisse à la fois être intégré à, et étendu par du C/C++ (extended and embedded). Puisqu'au final, le logiciel (écrit en C/C++) devra lire/exécuter les scripts tout en l'étendant avec lesdites fonctions.

Le but n'est pas d'intégrer du C dans un script (ce qui parait, effectivement, très facile à faire avec PERL), mais de faire appel à des fonctions écrites en C/C++ dans une lib ou un exe à part.

Le but du jeu est que les scripts en question puissent être écrits par des non développeurs. Donc le plus simple possible, les extensions écrites en C/C++ seront complètement transparentes pour le redacteur du script.

Maintenant, il est très possible que je sois passé complètement à coté de ce que peux offrir PERL. Il me reste encore un peu de temps pour trouver des solutions alternatives, je vais y rejeter un coup d'oeil.

En tout cas, un grand merci pour votre implication... ça fait vraiment plaisir !

[alex_pi]

Pourquoi Perl ne fait-il pas partie des options ? C'est un langage extrêmement puissant, capable de s'interfacer avec C et C++ (et autres langages) facilement par les modules Inline::*, disposant de la plus large bibliothèques de modules externes facilement installable (le CPAN), multi-plateforme...

--
Jedaï

<troll>Parce que c'est un langage affreux ? :-D</troll>

Pour python, Py++ est parait-il une solution à envisager
http://www.language-binding.net/pypl...yplusplus.html

[Jedai]

Perl, me paraissait justement plus compliqué pour ce que j'ai à faire...

il me faut un langage de script qui puisse à la fois être intégré à, et étendu par du C/C++ (extended and embedded). Puisqu'au final, le logiciel (écrit en C/C++) devra lire/exécuter les scripts tout en l'étendant avec lesdites fonctions.

Le but n'est pas d'intégrer du C dans un script (ce qui parait, effectivement, très facile à faire avec PERL), mais de faire appel à des fonctions écrites en C/C++ dans une lib ou un exe à part.

Le but du jeu est que les scripts en question puissent être écrits par des non développeurs. Donc le plus simple possible, les extensions écrites en C/C++ seront complètement transparentes pour le redacteur du script.

Perl est tout à fait capable de ce que tu demandes, néanmoins, si tu envisages effectivement de rendre le langage de script disponible à tes utilisateurs un langage plus simple et moins riche comme Lua est probablement plus adapté effectivement.

--
Jedaï

[nikko34]

avec lua, luabind pour le C++ est vraiment très sympa

[GeantVert13]

Merci...

D'après ce que je comprends, pour luabind, il faut que j'utilise la librairie Boost... Malheureusement, la politique de la boite (pour le moment) est de s'affranchir des lib C++ autres que les notres.... J'avais omis de dire ça...

Donc on va probablement se diriger vers Python. L'intégration est un peu moins sexy que luabind... je vais voir si je peux faire un peu de lobbying

Merci à tous !

[Mac LAK]

LUA : testé et intégré, c'est pas mal, wrappable ultra facilement sur du C/C++ (cf. l'outil gratuit SWIG pour ça au besoin, ça gère plein d'autres langages de script), totalement intégrable au binaire final produit : pas de DLL, pas de runtimes, tout est incorporable à 100% dans le binaire.
LUA répond à 100% à ton besoin, y compris au niveau de l'intégration de la machine LUA... On pilote des bancs de tests complets avec ce langage, et un banc, c'est plusieurs grosses armoires contenant des dizaines d'unités centrales et des milliers d'entrées/sorties... Nous l'utilisons aussi bien en embarqué qu'en débarqué.

Python : testé via des wrappeurs uniquement, c'est pas mal, mais c'est plus "crade" à mon goût que LUA... Cela reste un avis personnel, l'intégration me semble également moins bonne (en terme d'intégration avec un programme natif). Par contre, en tant que langage de script externe de contrôle (pilotage par script de ton application, notamment à des fins de tests automatiques), c'est d'une puissance assez redoutable. Nous ne l'utilisons qu'en débarqué, toutefois, pour cause de manque d'un interpréteur Python sur la cible embarquée (et que c'est une usine à gaz pour en porter un).

Ces deux langages sont "adaptés" à des non-développeurs sans trop de soucis. Par exemple, des automaticiens s'en sortent très bien, tout comme des électroniciens ou des techs peu qualifiés.

Côté langages de script "plus exotiques", il y a aussi PHP (si tu dois traiter beaucoup de chaînes de caractères, c'est la "Rolls" des langages de scripts), Javascript (enfin, ECMAScript pour être précis), Ruby, Perl, et même du Pascal ! Et j'en oublie des dizaines, sûrement...

Toutefois, côté pérennité, j'opte plus pour LUA (sources intégraux, vastement utilisé, extensibilité quasi-maximale) et Python (à peu près pareil, bien que moins "intégrable" je trouve).

Le langage PHP est pérenne aussi, mais "lourd" à mettre en œuvre si tu le sors de son contexte idéal qu'est la manipulation de flux de texte.
Pascal est un éternel survivant, donc pérenne aussi, intégrable au même niveau que LUA, mais offre l'inconvénient d'être un langage plus "rigide", et demandant donc d'être plus calé en informatique pour être utilisé... Ce qui le rend inadapté à ton besoin.

[Jedai]

Côté langages de script "plus exotiques", il y a aussi PHP (si tu dois traiter beaucoup de chaînes de caractères, c'est la "Rolls" des langages de scripts), Javascript (enfin, ECMAScript pour être précis), Ruby, Perl, et même du Pascal ! Et j'en oublie des dizaines, sûrement...

Toutefois, côté pérennité, j'opte plus pour LUA (sources intégraux, vastement utilisé, extensibilité quasi-maximale) et Python (à peu près pareil, bien que moins "intégrable" je trouve).

Le langage PHP est pérenne aussi, mais "lourd" à mettre en œuvre si tu le sors de son contexte idéal qu'est la manipulation de flux de texte.
Pascal est un éternel survivant, donc pérenne aussi, intégrable au même niveau que LUA, mais offre l'inconvénient d'être un langage plus "rigide", et demandant donc d'être plus calé en informatique pour être utilisé... Ce qui le rend inadapté à ton besoin.

Pascal n'est pas un langage de script... Pourquoi ne pas leur apprendre à utiliser C directement tant que tu y es (j'admets que Pascal est un peu plus amical, mais il n'est vraiment pas à sa place dans ta liste).
A vrai dire tous les langages que tu as cité sont "pérennes", on ne peut pas dire que tu ais pris de risque de ce côté là... Donc ce n'est pas vraiment un critère.

Tu sembles également avoir une drôle de conception de PHP : ce n'est pas la "Rolls des traitements de texte", il est même relativement mauvais par rapport à Perl dans ce domaine, avec 40 fonctions pour faire ce que Perl fait avec 4 formes syntaxiques bien intégrées dans le langages (alors que les fonctions en PHP ont des noms peu cohérents). Il a été créé pour faire des pages dynamiques dans un serveur HTTP et c'est encore ce qu'il fait le mieux aujourd'hui (encore que je ne crois pas qu'il soit le meilleur choix dans le domaine, juste le plus répandu dû à sa facilité de déploiement pour les hébergeurs).

Javascript serait en fait un choix intéressant, surtout avec le développement récent d'interpréteurs rapides (mais c'est un domaine encore en fluctuation, probablement à éviter si on veut un déploiement simple et des outils stables et prouvés).

Ruby est lent (plus que la plupart des autres langages cités) et moins bien intégré/embarqué que Lua à ma connaissance, de plus c'est un langage complexe, très puissant et avec beaucoup de subtilités.

A mon avis, Lua est le choix le plus approprié.

--
Jedaï

[Mac LAK]

Pascal n'est pas un langage de script... Pourquoi ne pas leur apprendre à utiliser C directement tant que tu y es (j'admets que Pascal est un peu plus amical, mais il n'est vraiment pas à sa place dans ta liste).

Je me demande s'il vaut mieux être aveugle ou lire des trucs pareils... => http://www.remobjects.com/ps.aspx : autre chose ?
Ce n'est qu'un exemple, InnoSetup utilise aussi du Pascal en script, par exemple... Et quitte à faire du script (souvent avec des structures assez sales), autant le faire si possible avec un langage un minimum rigide et facile à apprendre.

A vrai dire tous les langages que tu as cité sont "pérennes", on ne peut pas dire que tu ais pris de risque de ce côté là... Donc ce n'est pas vraiment un critère.

Pérenne veut aussi dire "utilisé largement et donc ayant de la doc, des utilisateurs pouvant aider, etc. et ceci pour des années".
J'ai des doutes sur Ruby par exemple, que je vois finalement de façon "anecdotique", et que je trouve donc moins pérenne que Python. Perl est connu, certes, mais sorti du monde Unix, c'est le désert. PHP est pérenne, mais l'adaptation nécessaire pour le "sortir" de son environnement classique Web l'est un peu moins. Etc...

Tu sembles également avoir une drôle de conception de PHP : ce n'est pas la "Rolls des traitements de texte", il est même relativement mauvais par rapport à Perl dans ce domaine, avec 40 fonctions pour faire ce que Perl fait avec 4 formes syntaxiques bien intégrées dans le langages (alors que les fonctions en PHP ont des noms peu cohérents).

D'une part, apprends à citer correctement, s'il te plait. Si je veux un "traitement de texte", je prends un Word ou équivalent, pas un langage de programmation. Relis bien, je parle de "manipulation de chaines de caractères" et de "flux de texte"...
Quant à Perl... Un langage de script, ça se doit aussi d'être utilisable par (presque) tout le monde, et plus imbitable que Perl, c'est sed+awk. Que tu aimes bien ce langage, admettons. 99% des utilisateurs de Windows le trouvent tout simplement laid. PHP n'est pas un modèle de propreté, mais au moins c'est compréhensible.

Accessoirement, si Perl est si "autant plus mieux" que ça, je me demande bien pourquoi la plupart du contenu Web est fait avec du PHP, Javascript (serveur et/ou client), tandis que Perl est cantonné à quelques CGI, ou à la gestion des regexp, ou à des scripts pour les shells Unix...

Javascript serait en fait un choix intéressant, surtout avec le développement récent d'interpréteurs rapides (mais c'est un domaine encore en fluctuation, probablement à éviter si on veut un déploiement simple et des outils stables et prouvés).

L'intérêt majeur de Javascript (ECMAScript pour être précis), c'est qu'il fait l'objet d'un standard.

[Jedai]

Je me demande s'il vaut mieux être aveugle ou lire des trucs pareils... => http://www.remobjects.com/ps.aspx : autre chose ?
Ce n'est qu'un exemple, InnoSetup utilise aussi du Pascal en script, par exemple... Et quitte à faire du script (souvent avec des structures assez sales), autant le faire si possible avec un langage un minimum rigide et facile à apprendre.

En fait InnoSetup utilise exactement l'implémentation vers laquelle tu as donné un lien, ton "aussi" est donc légèrement ironique. Il est certain qu'à peu près n'importe quel langage mainstream peut être utilisé pour des scripts (ils l'ont même fait pour C !!), ça n'en fait tout même pas des langages de script.

Pérenne veut aussi dire "utilisé largement et donc ayant de la doc, des utilisateurs pouvant aider, etc. et ceci pour des années".
J'ai des doutes sur Ruby par exemple, que je vois finalement de façon "anecdotique", et que je trouve donc moins pérenne que Python. Perl est connu, certes, mais sorti du monde Unix, c'est le désert. PHP est pérenne, mais l'adaptation nécessaire pour le "sortir" de son environnement classique Web l'est un peu moins. Etc...

A mon avis, passé un certain point, il est stérile d'essayer de comparer la "pérennité" de langages bien installés : Ruby a une base d'utilisateurs énorme, sans doute pas comparable à Python mais néanmoins largement suffisante pour lui assurer plus d'une dizaine d'année d'évolution. Le fait que tu ais rencontré Python bien plus que Ruby peut être dû à plusieurs facteurs (environnement de travail, expérience dans le métier (Python est installé depuis plus d'un quinzaine d'année maintenant), pas en Asie....) mais n'est pas le fin mot de l'état du monde informatique.
Contrairement à ce que tu dis, Perl est utilisé comme langage d'administration dans le monde Windows depuis plus d'une dizaine d'année (cf. Win32 Perl Scripting: The Administrator's Handbook et autres livres sur cette page, ces éditeurs n'ont pas publié pour un marché inexistant).

Je ne te contredirais pas sur PHP (tu auras sans doute remarqué que ce n'est pas mon langage préféré).

D'une part, apprends à citer correctement, s'il te plait. Si je veux un "traitement de texte", je prends un Word ou équivalent, pas un langage de programmation. Relis bien, je parle de "manipulation de chaines de caractères" et de "flux de texte"...

Désolé pour la position malencontreuse des quotes, néanmoins lorsque je parlais de "traitement de texte", j'employais le terme dans son acceptation originelle et littérale, il semblait évident dans le contexte qu'il n'y avait aucun rapport avec les logiciels qui sont aujourd'hui désigné par cette appellation... Je reformule donc : pour "manipuler des chaînes de caractères", Perl est la "Rolls" des langages de programmation, et sans doute pas PHP. Affirmer autre chose est une méconnaissance des capacités respectives des deux langages dans le domaine. Si je devais comparer PHP à une voiture ce serait une pauvre coccinelle sur laquelle on aurait collé à la glu un nombre invraisemblable d'accessoires dépassant dans tous les sens.

Quant à Perl... Un langage de script, ça se doit aussi d'être utilisable par (presque) tout le monde, et plus imbitable que Perl, c'est sed+awk. Que tu aimes bien ce langage, admettons. 99% des utilisateurs de Windows le trouvent tout simplement laid. PHP n'est pas un modèle de propreté, mais au moins c'est compréhensible.

Il me semble que ta vision de Perl est extrêmement négative et mal informée... 99,9% des utilisateurs de Windows n'ayant jamais vu du Perl, je vois mal comment ils pourraient le trouver laid, la beauté étant de toute façon une caractérisation subjective et peu importante dans le contexte du choix d'un langage de programmation. PHP est bourré d'incohérences et le résultat d'une conception erratique, à mon sens il est de ce point de vue pire que Perl...

Accessoirement, si Perl est si "autant plus mieux" que ça, je me demande bien pourquoi la plupart du contenu Web est fait avec du PHP, Javascript (serveur et/ou client), tandis que Perl est cantonné à quelques CGI, ou à la gestion des regexp, ou à des scripts pour les shells Unix...

Tu as vu beaucoup de Javascript serveur ? Ce n'est pas une technique bien répandue dans mon petit coin du monde.
Comme je l'ai souvent dit, l'un des moteurs de l'adoption de PHP a été son adéquation au modèle des hébergeurs à bas prix : mod_php est simple d'installation et par défaut, PHP est un langage tout-en-un à un point absurde (l'ajout de namespace sera fait cette année, jusqu'ici, le core de PHP avec toutes extensions bourrait inconditionnellement plus de 3000 fonctions dans le seul espace de nom existant). Ensuite le succès nourrit le succès et une génération de programmeur web ont débuté avec PHP qui a maintenant des librairies d'une très honnête qualité et une documentation pléthorique.

Perl n'est pas cantonné à CGI, bien que comme la plupart des autres langages à mon goût meilleurs que PHP pour la programmation web (Python, Perl, Java, Ruby ne sont que quelques exemples), il n'aie pratiquement jamais droit à une meilleure interface avec le serveur sur les hébergements à bas prix.
Python, Perl ou Ruby ont d'excellent framework pour le net (Django, Catalyst, Rails et autres).

L'intérêt majeur de Javascript (ECMAScript pour être précis), c'est qu'il fait l'objet d'un standard.

C'est certes une bonne chose mais ce n'est pas le seul intérêt du langage en tant que langage de script : tout programmateur web même débutant a probablement appris au moins les rudiments du langage, les structures du langage sont relativement propres mais suffisamment flexibles et puissantes pour faire des choses intéressantes... On peut espérer le voir utiliser en tant que langage de script dans un nombre croissant d'application dans le futur proche.

--
Jedaï

[Mac LAK]

Il est certain qu'à peu près n'importe quel langage mainstream peut être utilisé pour des scripts (ils l'ont même fait pour C !!), ça n'en fait tout même pas des langages de script.

C'est un langage, c'est utilisé dans des scripts, on peut donc le qualifier de langage de script... Du moins dans cette implémentation. Quant à InnoSetup, c'est surtout que c'est l'exemple que j'avais le plus en tête.

A mon avis, passé un certain point, il est stérile d'essayer de comparer la "pérennité" de langages bien installés

Et pourtant... Côté particuliers, cela a peu d'importance, pour ne pas dire "aucune". Quant tu vends un produit qui doit être garanti entre 10 et 15 ans, tu n'as pas vraiment droit à l'erreur sur le sujet. A ce titre, même si Ruby a des tonnes d'adeptes, c'est un poids plume risible par rapport à Python et LUA... Et vu qu'ils occupent la même "niche" (langages de script), il est toujours POSSIBLE qu'il se fasse bouffer par un des deux : il est donc "moins" pérenne.

Contrairement à ce que tu dis, Perl est utilisé comme langage d'administration dans le monde Windows depuis plus d'une dizaine d'année

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Mac LAK>perl
'perl' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

No comment...
J'utilisais à l'époque "4DOS" comme interpréteur de commandes, avec ses extensions propres : ça n'a jamais fait de cet interpréteur une "norme" sous DOS. J'ai également un bash sous Windows : ça ne rend pas le shell Unix "normal" sous une machine Windows...
Ce n'est pas parce qu'un langage / shell existe sous Windows qu'il est standard... Ni qu'il est vastement utilisé. Il y a des chances que Powershell lui passe largement devant, je pense...

Je ne te contredirais pas sur PHP (tu auras sans doute remarqué que ce n'est pas mon langage préféré).

Ce qui te fait très certainement le dénigrer inutilement... Il est nettement moins crade (ou illisible, ou bordélique, rayer la mention inutile) que Perl, rend les mêmes services généraux et il est extensible (via code natif) avec une facilité presque écœurante comparé à d'autres langages de ce genre, même s'il est "cantonné" principalement au monde Web... Tout comme Perl est plutôt cantonné au monde Unix, d'ailleurs.

Je reformule donc : pour "manipuler des chaînes de caractères", Perl est la "Rolls" des langages de programmation, et sans doute pas PHP. Affirmer autre chose est une méconnaissance des capacités respectives des deux langages dans le domaine. Si je devais comparer PHP à une voiture ce serait une pauvre coccinelle sur laquelle on aurait collé à la glu un nombre invraisemblable d'accessoires dépassant dans tous les sens.

PHP est quand même maintenu de façon nettement plus active que Perl, pour les dates que j'ai pu voir de ci de là. De plus, la débauche de caractères spéciaux de Perl rend le truc particulièrement illisible, au même titre qu'un script shell bien velu ou un makefile bien complexe.
Que Perl soit puissant, je n'en doute pas. Que PHP permette les manipulations de chaine et la sortie en flux bien plus facilement et rapidement, je n'en doute pas non plus.
PHP est clairement inspiré de Perl, là aussi c'est évident. Le fait qu'il ait laissé derrière le côté "script pour geek hardcode" n'est pas un mal, et c'est très certainement une des raisons de son succès...
Tout comme, il y a bien longtemps, un langage nommé "Pascal" a voulu remplacer l'Algol, jugé "trop complexe"... L'histoire de l'informatique devrait t'indiquer qui a fini par gagner...

Il me semble que ta vision de Perl est extrêmement négative et mal informée... 99,9% des utilisateurs de Windows n'ayant jamais vu du Perl, je vois mal comment ils pourraient le trouver laid, la beauté étant de toute façon une caractérisation subjective et peu importante dans le contexte du choix d'un langage de programmation. PHP est bourré d'incohérences et le résultat d'une conception erratique, à mon sens il est de ce point de vue pire que Perl...

Sauf que PHP n'est pas gavé de caractères spéciaux au point presque absurde de Perl : trouver l'erreur quand un "~" manque dans un script bien dense revient à peu près à la même chose que trouver le TAB manquant dans un makefile...
PHP n'est pas exempt de défauts, bien entendu : comme la plupart des langages de script, on peut faire aussi bien de l'horrible que du "propre". Ce que je reproche à Perl, c'est que même le "propre" produit un truc qui apparaît bordélique et souvent pénible à lire.

Tu as vu beaucoup de Javascript serveur ? Ce n'est pas une technique bien répandue dans mon petit coin du monde.

C'est l'origine du langage, pourtant : le côté serveur... Même s'il faut reconnaître que seul Netscape a réellement continué sur cette voie. Toutefois, il reste utilisable côté serveur malgré tout.

Ensuite le succès nourrit le succès et une génération de programmeur web ont débuté avec PHP qui a maintenant des librairies d'une très honnête qualité et une documentation pléthorique.

Tout à fait... Ceci étant dit, s'il a eu autant de succès, c'est pas "pour rien" non plus, hein...

Perl n'est pas cantonné à CGI, bien que comme la plupart des autres langages à mon goût meilleurs que PHP pour la programmation web (Python, Perl, Java, Ruby ne sont que quelques exemples), il n'aie pratiquement jamais droit à une meilleure interface avec le serveur sur les hébergements à bas prix.

Cherches-en la cause dans les temps de développement avec du PHP, et de faire la même chose avec du Perl... Sur une solution gratuite / freeware, les gens ne vont pas s'emm... à se taper un langage hideux (et donc à développer une meilleure intégration) alors qu'ils ont à portée un langage plus pratique, plus extensible et au moins aussi puissant... Qu'ils amélioreront continuellement, par la force des choses.
Depuis le temps, tu n'as pas remarqué que les informaticiens sont "feignants", et que sans contraintes spécifiques, ils vont toujours vers la solution la plus simple et la plus rapide ??
Quant aux solutions payantes... Ben justement, c'est payant : les gens exigent donc quelque chose de pratique, rapide, efficace. Sur IIS, c'est pas non plus du Perl qui est implémenté par défaut, tu remarqueras.

Ne voulant pas non plus "casser" Perl à tout point de vue, il faut lui reconnaître les avantages suivants : il est bien plus pratique à utiliser qu'un script shell + sed + awk, plus rapide à l'exécution aussi, et il est vastement répandu dans le monde Unix, avec des scripts à foison qui deviennent de vrais outils à part entière, comme si c'étaient des exécutables "natifs"... On ne gomme pas 22 ans d'existence "comme ça" non plus. Mais PHP est plus "jeune" de 8 ans... Et corrige donc des "problèmes" rencontrés avec Perl pendant ces 8 années.

[Javascript]On peut espérer le voir utiliser en tant que langage de script dans un nombre croissant d'application dans le futur proche.

C'est fort probable, mais le fait qu'il soit standardisé tout en étant libre d'implémentation est l'atout principal qui permettra ceci : tu as le droit d'implémenter ta propre version de l'ECMAScript, en te conformant au standard, et de l'étendre au besoin tant que tu ne casses pas le "tronc commun" standardisé... Ce qui revient (en très light) à ce qui existe avec le C et la CLib : c'est "la même" partout, les programmes n'ont pas besoin d'être réécrits pour être portés s'ils restent dans le "tronc commun", et peuvent être adaptés conditionnellement (préprocesseur en C, directement à l'exécution en ECMAScript) pour la partie spécifique à la plate-forme.
La syntaxe ? Faut pas pousser non plus, si t'as bidouillé en C et/ou en Java, ce langage ne pose AUCUN problème... Ce qui est loin d'être le cas avec d'autres langages de script qui exigent un apprentissage spécifique.

[Jedai]

Et pourtant... Côté particuliers, cela a peu d'importance, pour ne pas dire "aucune". Quant tu vends un produit qui doit être garanti entre 10 et 15 ans, tu n'as pas vraiment droit à l'erreur sur le sujet. A ce titre, même si Ruby a des tonnes d'adeptes, c'est un poids plume risible par rapport à Python et LUA... Et vu qu'ils occupent la même "niche" (langages de script), il est toujours POSSIBLE qu'il se fasse bouffer par un des deux : il est donc "moins" pérenne.

Je ne considère pas qu'un produit qui a "des tonnes d'adeptes" puisse être appelé un "poids plume risible", même en comparaison à un autre langage. De plus tu semble déconnecté de la réalité : Ruby n'est pas si loin de Python que tu sembles le penser et Lua est encore un langage anecdotique par rapport aux poids lourd PHP, Python, Perl et Ruby, c'est du moins la conclusion de l'index TIOBE (peu fiable en réalité, néanmoins quand il y a une telle différence entre l'index de deux langages, cela reste significatif).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Mac LAK>perl
'perl' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

No comment...
J'utilisais à l'époque "4DOS" comme interpréteur de commandes, avec ses extensions propres : ça n'a jamais fait de cet interpréteur une "norme" sous DOS. J'ai également un bash sous Windows : ça ne rend pas le shell Unix "normal" sous une machine Windows...
Ce n'est pas parce qu'un langage / shell existe sous Windows qu'il est standard... Ni qu'il est vastement utilisé. Il y a des chances que Powershell lui passe largement devant, je pense...

Pour un administrateur système, l'installation d'ActivePerl est extrêmement simple, s'il estime avoir besoin de Perl, le fait qu'il ne soit pas installé par défaut n'est pas un obstacle... Les administrateurs windows sérieux qui se contentent des outils présents de base ne sont pas légion. Ton "argument" n'en est donc pas un.
Perl est utilisé pour gérer des ordinateurs et des réseaux sous Windows, il n'est donc pas restreint au monde Unix comme tu t'obstines à le répéter face aux preuves du contraire.

Je n'ai jamais prétendu par contre qu'il soit l'outil d'administration le plus répandu dans le monde Windows, ce serait ridicule vu qu'une majorité d'admin ne jure que par les langages et outils Microsoft (dont Powershell est un exemple très intéressant).

Ce qui te fait très certainement le dénigrer inutilement... Il est nettement moins crade (ou illisible, ou bordélique, rayer la mention inutile) que Perl, rend les mêmes services généraux et il est extensible (via code natif) avec une facilité presque écœurante comparé à d'autres langages de ce genre, même s'il est "cantonné" principalement au monde Web...

PHP est nettement plus bordélique que Perl : avoir 3000 fonctions dans son espace de nom par défaut, avoir 4 types de "égal", ... ne sont certainement pas des marques d'organisation. Quant à la lisibilité du langage, en dehors du fait que la nature orienté template de PHP ne le rend pas toujours extrêmement lisible, le Perl moderne (depuis 10 ans disons) est parfaitement lisible.
Perl est très facile à étendre en C comme le prouve la multitude de modules du CPAN qui utilisent une telle extension, essaie Inline::C pour une méthode d'extension dont la simplicité est difficile à battre.

PHP est quand même maintenu de façon nettement plus active que Perl, pour les dates que j'ai pu voir de ci de là. De plus, la débauche de caractères spéciaux de Perl rend le truc particulièrement illisible, au même titre qu'un script shell bien velu ou un makefile bien complexe.

Il est certainement vrai que PHP a plus de mainteneur que Perl5 (pas toujours de qualité, comme les nombreuses failles de sécurité dû à PHP lui-même en témoigne), mais Perl5 est aussi nettement plus mature que PHP et en tant que tel n'a pas besoin d'une telle attention.
Ta comparaison entre des script shell et Perl montre bien que tu n'as qu'une connaissance limitée du langage tel qu'il est utilisé actuellement... Les caractères spéciaux en Perl ne sont plus tant utilisé aujourd'hui et ils ne sont certainement pas un obstacle à la compréhension.

Que Perl soit puissant, je n'en doute pas. Que PHP permette les manipulations de chaine et la sortie en flux bien plus facilement et rapidement, je n'en doute pas non plus.

Tu ne doute pas de grand chose visiblement, mais peut-être devrais-tu te remettre en question de temps en temps : pour quelqu'un ayant travaillé avec les deux langages, ton affirmation est risible et évidemment fausse.

Tout comme, il y a bien longtemps, un langage nommé "Pascal" a voulu remplacer l'Algol, jugé "trop complexe"... L'histoire de l'informatique devrait t'indiquer qui a fini par gagner...

Mmmm... C, non ? Dérivé d'Algol (par le biais de CPL et B) et plus complexe que Pascal. Mais je ne suis pas trop sûr de comment ton analogie s'applique à notre cas.

Sauf que PHP n'est pas gavé de caractères spéciaux au point presque absurde de Perl : trouver l'erreur quand un "~" manque dans un script bien dense revient à peu près à la même chose que trouver le TAB manquant dans un makefile...

"~" ? Tu veux dire que pour toi "=" et "=~" se ressemble suffisamment, et que le fait qu'une variable sur laquelle tu voulais faire un match change subitement complètement de valeur n'est pas surprenant ? Ou alors tu faisais allusion à l'opérateur de négation bit à bit ?

PHP n'est pas exempt de défauts, bien entendu : comme la plupart des langages de script, on peut faire aussi bien de l'horrible que du "propre". Ce que je reproche à Perl, c'est que même le "propre" produit un truc qui apparaît bordélique et souvent pénible à lire.

Tu rigoles ? Perl permet de structurer son programme bien plus proprement que PHP, qui jusqu'à très récemment n'avait même pas de portée lexicale ou d'espaces de noms... Un script Perl moderne est parfaitement lisible.

Cherches-en la cause dans les temps de développement avec du PHP, et de faire la même chose avec du Perl... Sur une solution gratuite / freeware, les gens ne vont pas s'emm... à se taper un langage hideux (et donc à développer une meilleure intégration) alors qu'ils ont à portée un langage plus pratique, plus extensible et au moins aussi puissant... Qu'ils amélioreront continuellement, par la force des choses.
Depuis le temps, tu n'as pas remarqué que les informaticiens sont "feignants", et que sans contraintes spécifiques, ils vont toujours vers la solution la plus simple et la plus rapide ??
Quant aux solutions payantes... Ben justement, c'est payant : les gens exigent donc quelque chose de pratique, rapide, efficace. Sur IIS, c'est pas non plus du Perl qui est implémenté par défaut, tu remarqueras.
Ne voulant pas non plus "casser" Perl à tout point de vue, il faut lui reconnaître les avantages suivants : il est bien plus pratique à utiliser qu'un script shell + sed + awk, plus rapide à l'exécution aussi, et il est vastement répandu dans le monde Unix, avec des scripts à foison qui deviennent de vrais outils à part entière, comme si c'étaient des exécutables "natifs"... On ne gomme pas 22 ans d'existence "comme ça" non plus. Mais PHP est plus "jeune" de 8 ans... Et corrige donc des "problèmes" rencontrés avec Perl pendant ces 8 années.

Tu ne veux pas "casser" ce langage si hideux, illisible et inutilisable en dehors d'Unix, vraiment ? Admets que tu as une dent contre Perl, ça rendra le débat plus honnête au moins.

--
Jedaï

[Garulfo]

[...]
Quant à Perl... Un langage de script, ça se doit aussi d'être utilisable par (presque) tout le monde, et plus imbitable que Perl, c'est sed+awk. Que tu aimes bien ce langage, admettons. 99% des utilisateurs de Windows le trouvent tout simplement laid. PHP n'est pas un modèle de propreté, mais au moins c'est compréhensible.[...]

Je trouve PHP lourd et désagréable dans sa syntaxe. C'est plus la 2CV que la Rolls des langages de manipulations de chaînes de caractères. La 2CV a eu du succés, mais c'est loin d'être le grand luxe.

Dire qu'un pourcentage d'utilisateur d'un OS n'aime pas un langage ne fait pas de ce langage un mauvais choix. La plupart des développeurs crache sur les langages fonctionnelles et adorent le C/C++ ou le Java qui sont pourtant des langages lourds et à la syntaxe bien moins « propre » (ce qui n'empêche pas qu'ils aient des avantages cependant).

Perl n'est pas moins rapide pour le traitement des chaînes de caractères que PHP. Je me demande ou tu es allé chercher le contraire. Tu es plutôt présomptueux il me semble. Ici
http://shootout.alioth.debian.org/gp...ang=perl&box=1
tu pourras tester le test pour des regexp DNA et des Knucleotides.
Il n'y a pas de gagnants en regardant les deux tests en terme de rapidité, Perl gagnant cependant dans l'utilisation mémoire.

En tout cas, finissons par une blague qui sera appréciée par certains j'espère :
[TROLL]100% des utilisateurs de Windows utilisent Windows, ils ont donc des goûts détestables en matière d'esthétique et de design informatique [/TROLL]

[Mac LAK]

Je ne considère pas qu'un produit qui a "des tonnes d'adeptes" puisse être appelé un "poids plume risible", même en comparaison à un autre langage. De plus tu semble déconnecté de la réalité : Ruby n'est pas si loin de Python que tu sembles le penser et Lua est encore un langage anecdotique par rapport aux poids lourd PHP, Python, Perl et Ruby, c'est du moins la conclusion de l'index TIOBE (peu fiable en réalité, néanmoins quand il y a une telle différence entre l'index de deux langages, cela reste significatif).

Quelle réalité ? Dans la mienne, Ruby est inconnu, LUA / Python sont rois, Perl n'existe qu'en tant qu'outil tout prêt plus ou moins noyé dans l'OS et PHP sert à faire des pages Web... Vive le monde industriel.
A titre personnel, en tant que joueur, j'ai du LUA sous les yeux encore plus souvent qu'au boulot : je te laisse deviner avec quoi est scripté un certain MMO à 12 millions d'abonnés...

De plus, ton index est relativement déconnecté lui aussi, et/ou il te tire une balle dans le pied : le VHDL est quand même plus que vastement utilisé dans le milieu industriel (milieu certes "fermé", c'est le problème quand on ne se fie qu'à des trucs grand public et/ou influencés par les sponsors), Perl se casse la tronche, et je ne sais vraiment pas qui a exhumé le Logo de sa tombe... Sûrement un effet de mode.

Mais bon : un index basé sur les seules recherches de moteurs sur le net et cité en "référence", alors qu'il est calculé SANS tenir compte du nombre de lignes de code écrites dans ces langages (total + en moyenne sur période récente), ça m'a bien fait rire : je t'en remercie.

(Note : Penser à faire un langage idiot nommé "sex", afin de prendre 90% du marché selon TIOBE...)

Pour un administrateur système, l'installation d'ActivePerl est extrêmement simple, s'il estime avoir besoin de Perl, le fait qu'il ne soit pas installé par défaut n'est pas un obstacle...

Si : autant j'ai rarement vu un Unix sans Perl, autant un Windows avec, c'est moins courant... Ce qui peut poser des problèmes de déploiement, d'ailleurs.

Les administrateurs windows sérieux qui se contentent des outils présents de base ne sont pas légion.

C'est très sympa de ta part de traiter la plupart des admins de gens "pas sérieux"...

Perl est utilisé pour gérer des ordinateurs et des réseaux sous Windows, il n'est donc pas restreint au monde Unix comme tu t'obstines à le répéter face aux preuves du contraire.

Et "command.com" est utilisé sous Linux, également, via Wine : est-ce que ça en fait un interpréteur de commandes Unix pour autant ? Non.
Le fait qu'un outil existe n'a jamais voulu dire qu'il est répandu, vastement utilisé ou même tout simplement souhaitable, car il peut être totalement redondant avec un outil existant, répandu et vastement utilisé et n'offrir aucun avantage "lourd" justifiant qu'il remplace l'existant.

Je n'ai jamais prétendu par contre qu'il soit l'outil d'administration le plus répandu dans le monde Windows, ce serait ridicule vu qu'une majorité d'admin ne jure que par les langages et outils Microsoft (dont Powershell est un exemple très intéressant).

Tiens, tu vas encore te faire des potes chez les admins système, toi, vu que tout à l'heure tu prétendais qu'il fallait utiliser Perl sous Windows pour être "sérieux"...

PHP est nettement plus bordélique que Perl : avoir 3000 fonctions dans son espace de nom par défaut, avoir 4 types de "égal", ... ne sont certainement pas des marques d'organisation.

Et ça pose un problème d'avoir un seul espace de noms ? Cela empêche d'utiliser des fonctions ? D'avoir un code propre ? De structurer son propre code ?
Pour parodier un peu, je me fiche de savoir si les devs PHP indentent à 2 ou 4 espaces ou autres détails "internes". Cela n'influence en rien les programmes écrits en PHP : un dév goret fera du crade quel que soit le langage, quelqu'un de rigoureux arrivera à faire du (presque) propre même avec un langage bordélique.
Juste pour info, à part le fait de devoir parfois se battre avec les #include pour trouver "le bon", la CLib est elle aussi "monolithique" vis à vis des espaces de noms... D'ailleurs, le C n'a même pas ce concept. Et ça marche très bien...

Quant à la lisibilité du langage, en dehors du fait que la nature orienté template de PHP ne le rend pas toujours extrêmement lisible, le Perl moderne (depuis 10 ans disons) est parfaitement lisible.

Parce que tu y es habitué, très certainement. Si encore j'étais le seul à trouver Perl "crade", OK, mais c'est vraiment pas le cas... Il y a bien une raison, tu ne crois pas ?

Les caractères spéciaux en Perl ne sont plus tant utilisé aujourd'hui et ils ne sont certainement pas un obstacle à la compréhension.

Ils sont un obstacle à la LISIBILITÉ : désolé, mais quand j'ai 5k lignes de code à revoir dans 4 ou 5 langages différents, je n'ai pas le temps de suivre à l'écran avec le doigt caractère par caractère pour ne "rien rater". Quand un simple caractère, pouvant être "noyé" au milieu d'une regexp, change le comportement du tout au tout, j'appelle ça "illisible". S'il faut mettre la même attention à lire une ligne de code qu'à la concevoir et à l'écrire, ça n'offre AUCUN intérêt de reprendre / adapter du code, autant repartir de zéro à chaque fois.

Tu ne doute pas de grand chose visiblement, mais peut-être devrais-tu te remettre en question de temps en temps : pour quelqu'un ayant travaillé avec les deux langages, ton affirmation est risible et évidemment fausse.

Je vois mal comment "battre" l'aspect template de PHP, justement, sauf avec un langage lui aussi orienté dans ce sens.
Côté manipulations de chaînes, tu peux aussi bien utiliser la pire regexp que de simples concaténations, le tout dans un cadre plus ou moins fermé (le template). Désolé, mais plus pratique et avec moins de code, j'ai pas trouvé.

Mmmm... C, non ? Dérivé d'Algol (par le biais de CPL et B) et plus complexe que Pascal. Mais je ne suis pas trop sûr de comment ton analogie s'applique à notre cas.

Qu'Algol, précurseur, s'est fait éclater copieux par le "petit nouveau", malgré toutes les qualités du précurseur en question : c'est UN défaut qui l'a fait couler, sa complexité.
Après, puisque tu veux troller sur le C, il a beau être répandu, avoir des tas de qualités (et au moins autant de défauts), c'est avant tout un langage créé pour servir de macro-assembleur... Pas vraiment la même chose que Pascal, qui lui au moins n'a pas eu besoin d'un nouveau langage pour supporter la POO, c'est "un peu" l'avantage des langages stricts.

"~" ? Tu veux dire que pour toi "=" et "=~" se ressemble suffisamment, et que le fait qu'une variable sur laquelle tu voulais faire un match change subitement complètement de valeur n'est pas surprenant ? Ou alors tu faisais allusion à l'opérateur de négation bit à bit ?

Rien que ta question devrait pourtant te faire comprendre en quoi ce langage est bordélique...

Tu ne veux pas "casser" ce langage si hideux, illisible et inutilisable en dehors d'Unix, vraiment ? Admets que tu as une dent contre Perl, ça rendra le débat plus honnête au moins.

Admets que tu en as une contre PHP, et de façon générale tout ce qui ne sort pas du monde Unix façon "GNU & free & student"...
Parce que là, c'est pas un débat, c'est un troll, je te signale.

Perl n'est pas moins rapide pour le traitement des chaînes de caractères que PHP. Je me demande ou tu es allé chercher le contraire.

Je n'envisageais pas que mon "rapidement" pourrait être pris dans le sens "vitesse d'exécution"... Je parlais de temps de dév, sinon autant le faire en C++ et ne pas se casser la tête avec un langage de script, on le fait "en dur" à chaque fois...

Il n'y a pas de gagnants en regardant les deux tests en terme de rapidité, Perl gagnant cependant dans l'utilisation mémoire.

Oui, et ? Pour ma part, je vois un test où Perl est plus gourmand, l'autre où c'est le contraire, un programme PHP mal écrit être "lent", un coup PHP devant, un coup derrière, de multiples versions pour chaque langage... Je ne vois même pas en quoi un tel "benchmark" est significatif !!
Si encore c'était à chaque fois des dévs "spécialistes" qui font LE programme optimisé à mort, on pourrait éventuellement comparer les implémentations, mais c'est même pas le cas !!

Benchmarking programming languages?

How can we benchmark a programming language?
We can't - we benchmark programming language implementations.

How can we benchmark language implementations?
We can't - we measure particular programs.

Tout est dit... Avec de tels paramètres d'entrée, je te "prouve" qu'un Amstrad CPC programmé en Locomotive Basic explose un Cray programmé en C...

[Garulfo]

[...]Admets que tu en as une contre PHP, et de façon générale tout ce qui ne sort pas du monde Unix façon "GNU & free & student"...
Parce que là, c'est pas un débat, c'est un troll, je te signale.

En tout cas toi, tu as une dent contre le monde UNIX. Il faut t'en remettre. Personnellement je n'aime effectivement pas PHP. Je crois que sa seule réelle qualité est d'être répandu. C'est, pour moi, un mauvais langage, désagréable et mal pensé. Mais c'est mon avis et je n'attaque pas ceux qui pensent le contraire.

Je n'envisageais pas que mon "rapidement" pourrait être pris dans le sens "vitesse d'exécution"... Je parlais de temps de dév, sinon autant le faire en C++ et ne pas se casser la tête avec un langage de script, on le fait "en dur" à chaque fois...

Oui, et ? Pour ma part, je vois un test où Perl est plus gourmand, l'autre où c'est le contraire[...]
Tout est dit... Avec de tels paramètres d'entrée, je te "prouve" qu'un Amstrad CPC programmé en Locomotive Basic explose un Cray programmé en C...

C'était un exemple pour dire que justement ça ne se compare pas et qu'il n'y a pas de gagnants. Donc merci d'aller dans mon sens.

Pour le temps de développement, c'est aussi non mesurable. Tu penses que PHP est plus efficace et d'autres croient le contraire. En quoi serais-tu celui qui a raison ? Pas plus que les autres. C'est très subjectif comme critère. À moins que tu ne me sortes une étude sérieuse, je suppose que tu ne parles que de ton vécu. Or, un vécu n'est certainement pas gage de qualité. Peut-être étais-tu encadré de développeurs incapables de comprendre le sens des opérateurs de Perl ? Peut-être n'as tu jamais non plus programmé en Perl et tu ne fais que ressassé des choses que tu crois sans les avoir vraiment expérimenté ? C'est souvent le cas quand les gens posent des grandes affirmations comme « on développe plus vite en PHP qu'en Perl ». Je t'assure que je développe plus vite en Perl qu'en PHP. Mais ce n'est pas non plus une mesure scientifique.

Tu devrais donc juste prendre un pas de recul et admettre que tes critères sont purement personnels. Oui PHP doit avoir des qualités pour s'être imposés. Personnellement j'ai du mal à comprendre ça… enfin si on exclut ce qui fait qu'un langage s'impose : le marketing.

Tu sais quand même que PHP est né par le biais de Perl ? Tu sais aussi que le créateur de PHP adhère complètement à cette philosophie OpenSource/Unixienne/Student que tu sembles détester ? Il est un bon Unixien d'ailleurs. Ta guéguerre est un peu ridicule quand même, quand bien même tu aurais raison sur le reste. Dommage pour la discussion