langage de script et C++

Version imprimable

20/05/2009, 18h01
GeantVert13

langage de script et C++
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:

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
20/05/2009, 18h20
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ï
20/05/2009, 20h34
Mat.M

Citation:

Envoyé par GeantVert13

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/
22/05/2009, 10h44
GeantVert13

Merci pour vos réponses.

Je vais déjà examiner ces solutions là.
22/05/2009, 17h23
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
22/05/2009, 18h01
Jedai

Citation:

Envoyé par GeantVert13

à 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ï
26/05/2009, 15h31
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 !
26/05/2009, 16h45
alex_pi

Citation:

Envoyé par Jedai

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
26/05/2009, 20h37
Jedai

Citation:

Envoyé par 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.

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ï
30/05/2009, 23h12
nikko34

avec lua, luabind pour le C++ est vraiment très sympa
03/06/2009, 10h38
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 :D

Merci à tous !
03/06/2009, 12h36
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.
03/06/2009, 15h56
Jedai

Citation:

Envoyé par Mac LAK

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ï
03/06/2009, 16h44
Mac LAK

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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...

Citation:

Envoyé par Jedai

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...

Citation:

Envoyé par Jedai

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.
03/06/2009, 19h41
Jedai

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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é).

Citation:

Envoyé par Mac LAK

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. :?

Citation:

Envoyé par Mac LAK

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...

Citation:

Envoyé par Mac LAK

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).

Citation:

Envoyé par Mac LAK

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ï

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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:

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...

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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...

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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...

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

[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.

Citation:

Envoyé par Mac LAK

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).
Citation:
Envoyé par Mac LAK
Code:

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).

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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 ?

Citation:

Envoyé par Mac LAK

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.

Citation:

Envoyé par Mac LAK

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ï

04/06/2009, 16h25
Garulfo

Citation:

Envoyé par Mac LAK

[...]
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]
04/06/2009, 17h48
Mac LAK

Citation:

Envoyé par Jedai

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...)

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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"...

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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"...

Citation:

Envoyé par Jedai

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...

Citation:

Envoyé par Jedai

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 ?

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

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é.

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Jedai

"~" ? 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...

Citation:

Envoyé par Jedai

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.

Citation:

Envoyé par Garulfo

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...

Citation:

Envoyé par Garulfo

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 !!

Citation:

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...
04/06/2009, 23h46
Garulfo

Citation:

Envoyé par Mac LAK

[...]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.

Citation:

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 ;)
05/06/2009, 03h49
Jedai

Citation:

Envoyé par Mac LAK

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.

"Mon" index (en fait je trouve TIOBE relativement peu fiable, comme indiqué dans mon message d'origine) a au moins l'avantage de se baser sur des données objectives, à la différence de ton opinion qui n'est basé que sur ton expérience limitée à ton environnement. De plus je n'essayais pas de faire des comparaisons au millimètre entre les langages de têtes mais simplement de pointer la très forte différence entre l'indice de Lua et les indices des gros langages de scripts (Ruby compris), une telle différence est certainement significative et contraire à tes affirmations désinvoltes.

Citation:

Envoyé par Mac LAK

C'est très sympa de ta part de traiter la plupart des admins de gens "pas sérieux"...
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"...

Je n'ai jamais écris cela, j'ai dit que la plupart des admins sérieux utilisaient (entre autres) des outils d'administrations qui n'étaient pas directement installés de base dans leur Windows (pas forcément Perl). Et que Perl pouvait être l'un de ces outils, visiblement utilisé par un certains nombre d'administrateurs Windows au vu des publications sur le sujet (les publieurs informatiques n'ayant pas tendance a sortir des livres pour un marché inexistant).

Citation:

Envoyé par Mac LAK

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 ?

Non bien sûr, cela ne l'empêche pas, mais c'est un concept utile qu'on retrouve sous une forme ou sous une autre dans pratiquement tous les langages modernes excepté PHP... On se demande bien pourquoi tous ces langages s'embêtent avec ce truc inutile.

Citation:

Envoyé par Mac LAK

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...

Donc PHP et C même combat ? Je croyais qu'on parlais des langages de scripts, relativement modernes et adaptés à l'utilisation par des amateurs ?

Citation:

Envoyé par Mac LAK

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 ?

Tu as aussi un tas de gens qui ne supportent pas la syntaxe de Python, ou qui sont allergiques au PHP d'ailleurs... C'est un peu facile de dire "il n'y a pas de fumée sans feu", dans le monde informatique on ne trouverait pas un seul langage utilisable si on écoutait uniquement leurs détracteurs.

Citation:

Envoyé par Mac LAK

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 a vraiment besoin de lire du Perl caractère par caractère pour le comprendre ? Désolé mais dans ce cas tu n'es pas qualifié pour juger ce langage puisque tu ne le connais visiblement pas du tout, je te conseillerais même de travailler sur tes compétences de lecture en général.
Si ta critique portait sur les regex en particulier, elle est certainement plus justifié, néanmoins ce n'est pas exactement la faute de Perl, de plus Perl est l'un des rares langages à avoir justement fait l'effort de permettre d'écrire des regex plus lisibles (avec le modificateur /x, il est possible d'aérer la regex, de la commenter, ...) : en fait Perl est sans doute le langage avec les regexs les plus lisibles.
Quant à critiquer l'usage des regex en général, il faut croire qu'il y a pas mal de gens qui les ont appréciés à voir qu'on les retrouve maintenant partout, souvent recopiés (parfois imparfaitement) du modèle Perl. Il faut également voir que bien qu'une regexp puisse exiger une lecture particulièrement attentive, elle résume souvent en une ligne ce qu'il faudrait une trentaine de ligne pour faire avec des outils classiques.

Citation:

Envoyé par Mac LAK

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é.

Tu peux utiliser des regexps, des concaténations et des templates... Merveilleux, vraiment je n'ai jamais rencontré un langage avec telles capacités pour les manipulations de chaînes ! Ah si, Perl fait tout ça aussi, et plus élégamment, mais je suppose que tu ne le savait pas ?

Citation:

Envoyé par Mac LAK

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.

N'était ce pas toi qui me vantait les qualités du C et le comparait à PHP (un macro-assembleur lui aussi ?) un peu auparavant ? De toute façon, comme je l'ai dit dans ma réponse, l'analogie Algol=Perl, Pascal=PHP ne tient vraiment pas, les conclusions à en tirer n'étant donc d'aucun intérêt.

Citation:

Envoyé par Mac LAK

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"...

J'ai une dent contre PHP, je ne m'en suis pas caché et l'ai admis plus haut dans le débat. Je ne vois pas très bien où exactement dans mes arguments tu as trouvé que j'étais globalement anti-tout ce qui n'est pas "GNU & free & student" (je suis plutôt favorable à la philosophie GNU mais pas fanatique, je n'ai rien contre les logiciels ou services payants et la plupart des trucs écrit par des étudiants sont peu intéressants et/ou solides sauf rares exceptions). Je te signale d'ailleurs que PHP est très proche de la mouvance du logiciel libre, tu te contredis donc toi-même (peut-être que tu ne connais pas non plus très bien PHP après tout).

--
Jedaï
05/06/2009, 15h06
Mac LAK

Citation:

Envoyé par Garulfo

En tout cas toi, tu as une dent contre le monde UNIX.

Je ne m'en suis jamais caché : c'est bordélique, il te faut 12 libs, 3 programmes et 2 shells pour faire un truc "natif" sur d'autres OS (et non, pas forcément Windows), et en plus c'est plus lent, plus lourd et t'as des plantages folkloriques avec certaines MAJs de librairies. Je n'aime pas non plus le principe de "documentation" du code Unix, et à chaque fois, sans AUCUNE exception, je tombe sur un truc tellement mal documenté que je dois faire du reverse engineering pour finir par l'utiliser.
De plus, je ne suis pas d'accord avec la philosophie générale d'Unix, que je trouve aberrante de maintenir envers et contre tout, notamment quand cela plombe les performances et/ou la maintenabilité.

Pour être honnête, je ne suis pas non plus totalement d'accord avec la philosophie Windows, du moins pas sur tous les points... Notamment celle d'avoir un OS monolithique et peu personnalisable si l'on n'est pas dans les versions Embedded : j'ai eu souvent le cas où il aurait été intéressant d'avoir un Windows "seul", sans interface graphique et sans fioritures destinées à l'utilisateur final... Dommage de lancer un shell graphique complet pour, au final, avoir une console comme unique interface.

Citation:

Envoyé par Garulfo

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.

Je développe plus vite en C qu'en Java. Cela ne veut pas dire pour autant que ce langage est plus répandu que Java, ou mieux documenté, ou plus "puissant"... Mais juste que j'en ai plus l'habitude.
Quant à PHP / Perl... Je vois les gens se mettre bien plus facilement au PHP qu'à Perl, et ceci de façon constante et continuelle. Ils n'ont pas la "philo" Perl ? Certainement. Sauf que c'est là justement le nœud du problème : en PHP, pas besoin de s'immerger dans cette "philo" pour démarrer, c'est un peu comme Python ou LUA : c'est pas forcément optimal, mais ça permet d'avancer.
Et je préfère 60% de fait "à l'heure" que 100% "trop tard", pour ma part : on n'a pas forcément les mêmes contraintes de développement non plus...

Citation:

Envoyé par Garulfo

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 ?

Je n'ai rien de particulier contre l'OpenSource, ni contre les étudiants... Je reproche des choses à Unix, par contre.
L'attitude que je conteste, c'est plutôt celle du "geek étudiant pro-GNU intégriste anti-M$", qui prône tel ou tel langage envers et contre tout, et encore plus si c'est bien abscons et imbitable... Résurgence du mode "leet", sûrement...
J'en ai deux "spécimens" dans ma boîte, qui me gonflent à discutailler sans arrêt sur des queues de cerises alors qu'on leur demande un résultat avec obligation de moyens. Et c'est justement des aspects de leur discours que je retrouve chez Jedaï, et qui m'agacent tout particulièrement.

A côté de ça, j'ai aussi plusieurs collègues Unixiens à fond, pro-Unix et tout et tout, avec qui n'importe quelle discussion est agréable et courtoise. Pourquoi ? Parce que s'ils apprécient certains points d'Unix, que je ne conteste d'ailleurs pas, ils n'ont pas non plus d'œillères et reconnaissent que ce n'est pas la panacée pour tout, et que pour chaque boulot à faire, il y a un OS meilleur que les autres et que ce n'est pas forcément leur distrib Linux préférée.
Chose amusante, ils trouvent tous Perl lourd et laid, tiens... Pour être honnête, la moitié d'entre eux pensent la même chose de PHP.

Citation:

Envoyé par Jedai

"Mon" index (en fait je trouve TIOBE relativement peu fiable, comme indiqué dans mon message d'origine) a au moins l'avantage de se baser sur des données objectives, à la différence de ton opinion qui n'est basé que sur ton expérience limitée à ton environnement.

Mon environnement, comme tu dis, est principalement l'informatique industrielle, et des projets confidentiels. Données que tu ne trouveras donc pas sur le web, pour des raisons bêtement évidentes de secret professionnel.

Citation:

Envoyé par Jedai

De plus je n'essayais pas de faire des comparaisons au millimètre entre les langages de têtes mais simplement de pointer la très forte différence entre l'indice de Lua et les indices des gros langages de scripts (Ruby compris), une telle différence est certainement significative et contraire à tes affirmations désinvoltes.

Bien. Donc, d'après toi, IDL et VHDL sont des langages "anecdotiques" ?

Citation:

Envoyé par Jedai

Je n'ai jamais écris cela, j'ai dit que la plupart des admins sérieux utilisaient (entre autres) des outils d'administrations qui n'étaient pas directement installés de base dans leur Windows (pas forcément Perl). Et que Perl pouvait être l'un de ces outils, visiblement utilisé par un certains nombre d'administrateurs Windows au vu des publications sur le sujet (les publieurs informatiques n'ayant pas tendance a sortir des livres pour un marché inexistant).

Ce n'est pas parce qu'un livre est publié qu'il est forcément très vendu, pour commencer... Ça, tu peux l'affirmer s'il est réédité constamment, pas parce qu'il est sorti un jour. Un bouquin peut sortir à des fins de prospection de marché, de complétude d'offre, de sponsoring, il peut même sortir à compte d'auteur.

Qu'il existe un admin Windows qui utilisent Perl, c'est très certainement le cas. Je pense qu'il faut plus y voir un admin Unix à qui on a collé un parc Windows dans les mains (et qui utilise donc des outils dont il a plus l'habitude) qu'un admin Windows "pur", qui lui utilisera plutôt les outils standards de Windows... Qui suffisent plus qu'amplement, d'ailleurs, nul besoin de Perl pour ça. S'ils prennent un logiciel tiers, c'est plus souvent un système de sauvegarde qu'un langage de script.

Citation:

Envoyé par Jedai

Non bien sûr, cela ne l'empêche pas, mais c'est un concept utile qu'on retrouve sous une forme ou sous une autre dans pratiquement tous les langages modernes excepté PHP... On se demande bien pourquoi tous ces langages s'embêtent avec ce truc inutile.

Cela a une utilité (qui peut être discutée, mais c'est pas l'objet). Mais utiliser cet "argument" pour démonter le langage... Ça t'embête tant que ça de ne pas avoir plein de préfixes devant chaque fonction ? Marrant, moi je vois plus souvent des gens mettre "using XXXX" en C++ que de se taper systématiquement le nom qualifié, par exemple...

Citation:

Envoyé par Jedai

Donc PHP et C même combat ? Je croyais qu'on parlais des langages de scripts, relativement modernes et adaptés à l'utilisation par des amateurs ?

Non, juste que la présence ou l'absence d'un namespace détaillé n'a jamais fait qu'un langage était "bon" ou "mauvais", les milliers d'API existantes en C (inclus Unix, hein...) ne possèdent pas de namespace de par le langage utilisé pour les développer : ça les rend "nulles" pour autant ? Non.

Citation:

Envoyé par Jedai

Tu as aussi un tas de gens qui ne supportent pas la syntaxe de Python, ou qui sont allergiques au PHP d'ailleurs... C'est un peu facile de dire "il n'y a pas de fumée sans feu", dans le monde informatique on ne trouverait pas un seul langage utilisable si on écoutait uniquement leurs détracteurs.

Sauf que là, je te rappelle, tu a commencé à troller sur PHP en préconisant Perl à la place. PHP a l'avantage d'être plus répandu, plus facile d'accès, très bien documenté et effectue très bien les tâches requérant de grosses manipulations de chaînes.
Perl aussi ? Oui... Sauf qu'il est moins facile d'accès et moins répandu.

Citation:

Envoyé par Jedai

Tu a vraiment besoin de lire du Perl caractère par caractère pour le comprendre ? Désolé mais dans ce cas tu n'es pas qualifié pour juger ce langage puisque tu ne le connais visiblement pas du tout, je te conseillerais même de travailler sur tes compétences de lecture en général.

C'est donc toi, LE mec qui arrive à lire une regexp ou une commande gavée de modificateurs d'un coup d'œil, en lecture rapide, sans jamais te tromper ?
Tu crois quoi ? Qu'on m'accorde six mois de relecture sans sourciller ? T'as raté un chapitre important sur les réalités de l'informatique, je crois... La relecture de code, c'est hélas toujours la sixième roue du carosse (la cinquième, c'est occupé par le test et la maintenabilité à égalité, hélas). Relire 1000 lignes de code ? Yep, j'ai royalement au moins 15 minutes pour ça. Juste de quoi avoir le temps de voir s'il y a un problème "lourd" ou pas, ou si le code est justement imbitable ou pas. T'as juste le temps de voir les failles lourdes, pas les détails, et si la faille lourde est conditionnée par UN caractère, dont en plus le sens change en fonction de sa position / utilisation, c'est qu'il y a un problème grave : le langage utilisé.

Citation:

Envoyé par Jedai

Quant à critiquer l'usage des regex en général, il faut croire qu'il y a pas mal de gens qui les ont appréciés à voir qu'on les retrouve maintenant partout, souvent recopiés (parfois imparfaitement) du modèle Perl. Il faut également voir que bien qu'une regexp puisse exiger une lecture particulièrement attentive, elle résume souvent en une ligne ce qu'il faudrait une trentaine de ligne pour faire avec des outils classiques.

Une regexp doit être limitée à ce qu'elle est censée faire : la reconnaissance lexicale. Fournir un moteur de regexp dans un programme (pour les recherches par exemple), ou faire un analyseur lexical, sont heureusement des taches relativement rares. Qu'on puisse les utiliser, c'est très bien, ça a une utilité indéniable. En faire un leitmotiv, faut pas non plus pousser...

Citation:

Envoyé par Jedai

Ah si, Perl fait tout ça aussi, et plus élégamment, mais je suppose que tu ne le savait pas ?

Je me fiche qu'un code soit "élégant", je veux qu'il soit propre, lisible, maintenable et facilement testable.
J'ai vu assez d'horreurs "élégantes" en C++, merci.

Citation:

Envoyé par Jedai

N'était ce pas toi qui me vantait les qualités du C et le comparait à PHP (un macro-assembleur lui aussi ?) un peu auparavant ?

Non, relis mieux. C n'est pas un langage de "haut" niveau, il est très proche du système (c'est "juste" fait exprès...), et son but d'origine était de compiler le premier OS Unix d'un nouvel ordinateur.
PHP est au contraire un langage de très haut niveau, qui n'a rien à voir avec un macro-assembleur... J'aimerais bien que tu cites mes propos où je compare C et PHP, d'ailleurs... J'ai comparé C à Pascal.

Citation:

Envoyé par Jedai

De toute façon, comme je l'ai dit dans ma réponse, l'analogie Algol=Perl, Pascal=PHP ne tient vraiment pas, les conclusions à en tirer n'étant donc d'aucun intérêt.

Elle est pourtant très exactement similaire. Peut-être aurais-tu dû connaître d'anciens "partisans" d'Algol (ou de Cobol) qui vantaient les mérites de leur langage désormais supplanté pour comprendre l'analogie... Moi, j'en ai connu, par contre. C'est vingt ans plus tard, mais j'entends toujours les mêmes choses, y'a de l'écho on dirait.

Je ne réponds pas au reste, y'a la réponse en tête de post en fait.
Par contre, je remarque que tu n'as pas réagi à cette phrase : "Rien que ta question devrait pourtant te faire comprendre en quoi ce langage est bordélique..." J'en déduis que tu n'as toujours pas compris où se situait le problème...
05/06/2009, 19h12
Garulfo

Citation:

Envoyé par Mac LAK

Je ne m'en suis jamais caché : c'est bordélique[...]
Je développe plus vite en C qu'en Java. Cela ne veut pas dire pour autant que ce langage est plus répandu que Java, ou mieux documenté, ou plus "puissant"... Mais juste que j'en ai plus l'habitude.
Quant à PHP / Perl... Je vois les gens se mettre bien plus facilement au PHP qu'à Perl, et ceci de façon constante et continuelle. Ils n'ont pas la "philo" Perl ? Certainement. Sauf que c'est là justement le nœud du problème : en PHP, pas besoin de s'immerger dans cette "philo" pour démarrer, c'est un peu comme Python ou LUA : c'est pas forcément optimal, mais ça permet d'avancer.

Bon et bien on en vient au coeur du problème ;) TU as probablement du mal à faire la part des choses vu ton acharnement contre Unix et Perl.

Bon sinon, merci aussi de m'appuyer encore une fois pour souligner combien l'argument sur « développe plus vite en XXX » n'est pas pertinent. C'est surtout une question d'habitude. Et si toi, il te semble que c'est plus rapide de s'immerger en PHP, ce n'est pas mon cas. Tu compares avec Python ? Il me semble que beaucoup de personnes croient avancer rapidement dans Python alors qu'ils ne font finalement que prendre des mauvaises habitudes et dévelloper comme des porcs. C'est peut-être aussi pour ça que je trouve PHP à chier. Dans tout ce que j'ai pû voir la qualité de code du PHP est souvent déplorable contrairement à ce que j'ai vu en Perl. C'est peut-être dû au fait qu'on peut faire joujou plus vite. Mais réellement développer, ça prend autant de temps selon moi. Certains iront plus vite dans l'un ou l'autre selon leurs baggages, mais en moyenne ça doit se valoir. Bien sûr c'est empirique comme réflexion. Il y a un prérequis pour faire du PHP : il faut comprendre l'objet. D'expérience, ça demande autant une formation que tout autre paradigme. C'est un paradigme qui n'est pas évident contrairement à ce qu'on entend souvent. Les étudiants débutants s'en tirent souvent mieux avec une approche plus « mathématique » par des fonctions que par des objets. C'est aussi une supposition basée sur une simple expérience de l'enseignement depuis plusieurs années. Je me trompe peut–être, mais je vois bien plus d'horreur dû à la prog objet qu'à la prog procédurale...

En tout cas, je ne dis que ceci pour remettre en perspective ce genre de jugement sans argument réel : « le langage XXX c'est sans contexte mieux que le langage YYY. » C'est simplement faux.
05/06/2009, 19h13
Garulfo

Citation:

Envoyé par Mac LAK

[...]
Chose amusante, ils trouvent tous Perl lourd et laid, tiens... Pour être honnête, la moitié d'entre eux pensent la même chose de PHP.[/SIZE]

Comme quoi rien n'est évident n'est-ce pas ;) ?
05/06/2009, 19h47
Mac LAK

Citation:

Envoyé par Garulfo

TU as probablement du mal à faire la part des choses vu ton acharnement contre Unix et Perl.

Du tout. Sinon, je ne pense pas que j'aurais cité Python, LUA ou même PHP, j'aurais parlé d'ASP, Powershell, C# ou autres solutions Microsoft.
Mais effectivement, les reliquats quasi-préhistoriques que l'on trouve (trop souvent) sous Unix me font pas mal hérisser le poil, tout autant que le manque de rétrocompatibilité binaire.

Citation:

Envoyé par Garulfo

En tout cas, je ne dis que ceci pour remettre en perspective ce genre de jugement sans argument réel : « le langage XXX c'est sans contexte mieux que le langage YYY. » C'est simplement faux.

Sauf que tu oublies le contexte : les langages de script hébergés par des applications C++.

En général, c'est fait pour scripter rapidement l'application, par l'utilisateur (souvent un NON DÉVELOPPEUR, dois-je le rappeler ??), soit à des fins de tests, soit à des fins de pilotage de fonctions "câblées".

Tu te vois, toi, devoir expliquer à un client qui vient d'aligner plus de 500 KILOeuros pour un produit qu'il va devoir, EN PLUS, former son personnel pour utiliser un langage "qu'il est plus zouli, plus 'pur' et gnagnagna" ??? T'as pété un plomb, là, je crois... L'enseignement, c'est très bien, il en faudrait bien plus d'ailleurs quand je vois le niveau de certains "jeunes", mais coller aussi à la réalité du "terrain", c'est pas mal : tu devrais essayer.

Tu te vois aussi manipuler de gros flux de texte en LUA ou Python ? Pas moi, en tout cas... C'est faisable, mais c'est lourd au possible. Javascript s'en sortirait un poil (petit, le poil) mieux, PHP s'en sort très bien.
Et au moins, t'as pas besoin de former des gens qui sont à la base des électroniciens, automaticiens ou ingénieurs réseau à des langages de programmation imbitables. Voilà en quoi PHP permet de développer plus rapidement que Perl.

Citation:

Envoyé par Garulfo

Comme quoi rien n'est évident n'est-ce pas ;) ?

Relis mieux : "tous" d'un côté, "la moitié" de l'autre.
06/06/2009, 04h00
Garulfo

Citation:

Envoyé par Mac LAK

[...]
Relis mieux : "tous" d'un côté, "la moitié" de l'autre.

Comme tu veux... le monde entier hait Perl.
Allez bon courage dans ta lutte contre le démon.
06/06/2009, 19h15
Philou67430

Citation:

Envoyé par Mac LAK

Quant à PHP / Perl... Je vois les gens se mettre bien plus facilement au PHP qu'à Perl, et ceci de façon constante et continuelle.

[troll]En démarrant le PHP, ils avaient sans doute déjà acquis de bonnes bases ... de perl.[/troll]
08/06/2009, 11h48
alex_pi

Non mais concrètement, vous êtes vraiment en train de troller sur le fait que PHP est la "rolls des langages de script" ? Fin je veux dire, c'est tellement gros qu'il dit ça juste pour rire. Replaçons nous une seconde dans un contexte historique : PHP a été crée pour pouvoir insérer un micro-morceau de code dynamique dans une page majoritairement statique (ça s'appelait quand même Personal Home Page, c'est pas pour rien). Ensuite ont été empilé là dessus des extensions sans aucune cohérence. Une des meilleures preuves est qu'il n'y a absolument aucune norme php (norme au sens très large hein...)

Effectivement, les débutants s'en sortent souvent mieux avec PHP qu'avec un autre langage. La question qui se pose c'est : est-ce une preuve d'un point positif ? En l'occurrence, je pense que non. PHP fait parti de ces langages (heureusement de plus en plus rare) qui font en sorte que "tout marche" sans se poser de question, sans jamais embêter le programmeur. Moralité ? On se retrouve avec des tableaux qui sont convertis en la chaine de caractère "Array" (si si), on a le booléen false qui vaut 0 en entier qui faut "0" en chaine de caractère qui faut true en tant que booléen, on a des erreurs qui se retrouvent imprimer discrètement a des endroits aberrant du code HTML produit. Alors effectivement, pour le débutant très débutant, c'est "pratique" puisque "ça marche" grossièrement. Malheureusement, ils prennent très vite des habitudes *immondes* sur le style de programmation, et dès qu'il veulent faire des choses un peu plus compliqué, c'est tout de suite la cata puisqu'il est très difficile (impossible ?) de structurer les programmes (ok, le modèle objet apparu tardivement aide vaguement, mais ça reste passablement moisi...)

Et même dans ce qu'il est sensé faire, à savoir la programmation web, PHP est une aberration mentale issue d'une vision statique du Web.

Déjà, la façon "normale" et de base pour produire une page web est de générer du *texte* (le code HTML). Bien sûr, il y a des moteurs de templates qui sont venus se greffer par dessus, mais la solution proposée par le langage est de produire le code à coup de "echo". Le fait que le code HTML est un arbre et pourrait être produit comme tel est complètement passé sous le tapis. Après bien sûr (à partir de PHP5), rien n'empêche le programmeur de se faire sa petite hiérarchie de classe, ses petits paterns pour l'impression, etc. Mais rien de tout ça n'est proposé nativement, il faut tout se coltiner à la main. Et bizarrement, tout le monde n'est pas capable de concevoir son propre framework propre.
Pour les requêtes SQL, c'est la même, on se les écrit à la main... Miam la sécurité !

En bref, on a une syntaxe lourde (à la C, mais avec des $ partout en plus), un style ignoble (aucun type, toutes les opérations acceptent n'importe quel type en entrée et tente de convertir sans rien dire, une définition des des constantes à partir de la chaine de caractère correspondant à leur nom), un modèle de la programmation web (vision par page plutôt que par service, production "à la main" du code) complètement dépassé.
Pour les avantages ? Euh, c'est dispo partout. Ok, super... :-\

Bref, pour moi c'est plus la lada des langage : c'est en plastique pas cher, mais ça reste complètement nase.
08/06/2009, 12h03
gorgonite

+1 avec la majorité des propos de alex_pi, mais...

Citation:

Envoyé par alex_pi

Le fait que le code HTML est un arbre et pourrait être produit comme tel est complètement passé sous le tapis. Après bien sûr (à partir de PHP5), rien n'empêche le programmeur de se faire sa petite hiérarchie de classe, ses petits paterns pour l'impression, etc. Mais rien de tout ça n'est proposé nativement, il faut tout se coltiner à la main. Et bizarrement, tout le monde n'est pas capable de concevoir son propre framework propre.
Pour les requêtes SQL, c'est la même, on se les écrit à la main... Miam la sécurité !

il existe des frameworks qui le font (souvent de façon lourde pour la génération du html...) mais il ne faut pas exagérer non plus ;)
exemple du SQL et Zend-Framework est assez parlant... :)

Citation:

Envoyé par alex_pi

En bref, on a une syntaxe lourde (à la C, mais avec des $ partout en plus)

ça s'inspire beaucoup du C, mais faut pas pousser non plus, il y a des foreach, une absence d'allocation mémoire explicite, etc

tu as peut-être fait trop de Caml pour accepter qu'on puisse trouver les ressemblances avec le C "pratique" pour beaucoup de programmeurs lambdas (malheureusement formés uniquement sur des bases Java la plupart du temps :?)

Citation:

Envoyé par alex_pi

Bref, pour moi c'est plus la lada des langage : c'est en plastique pas cher, mais ça reste complètement nase.

on va quand même devoir troller sur Ocsigen ici :aie: ?
08/06/2009, 13h13
alex_pi

Citation:

Envoyé par gorgonite

il existe des frameworks qui le font (souvent de façon lourde pour la génération du html...) mais il ne faut pas exagérer non plus ;)
exemple du SQL et Zend-Framework est assez parlant... :)

ça s'inspire beaucoup du C, mais faut pas pousser non plus, il y a des foreach, une absence d'allocation mémoire explicite, etc

Je parlais vraiment de la syntaxe en elle même. Mais si tu veux parler d'allocation, le fait que PHP râle à peine (un petit warning, mais on continue le calcul coute que coute) quand on utilise une variable non initialisé (contrairement à python qui génère typiquement une erreur dans ce cas) est encore une des aberrations de ce langage.

Citation:

Envoyé par gorgonite

tu as peut-être fait trop de Caml pour accepter qu'on puisse trouver les ressemblances avec le C "pratique" pour beaucoup de programmeurs lambdas (malheureusement formés uniquement sur des bases Java la plupart du temps :?)

Ah non ! Là en l'occurrence je pensais à d'autres langages de script (typiquement python que je trouve fort sympathique) qui ont quand même des syntaxes vachement plus légère. (Il se trouve que je n'apprécie pas particulièrement la syntaxe d'OCaml)
Mais puisque tu mets les langages fonctionnels sur le tapis, à ma connaissance PHP ne s'est toujours pas décidé à prendre un minimum de traits fonctionnels, contrairement à python et rubby. Ils expliquent que c'est entre autre parce que leur définition de la porté des variable est complètement absurde :-D

Citation:

on va quand même devoir troller sur Ocsigen ici :aie: ?

Pourquoi pas ? :mrgreen:
08/06/2009, 13h26
gorgonite

Citation:

Envoyé par alex_pi

Je parlais vraiment de la syntaxe en elle même. Mais si tu veux parler d'allocation, le fait que PHP râle à peine (un petit warning, mais on continue le calcul coute que coute) quand on utilise une variable non initialisé (contrairement à python qui génère typiquement une erreur dans ce cas) est encore une des aberrations de ce langage.

ça se règle... et clairement, la rigueur n'est pas de mise en programmation php
d'ailleurs beaucoup disent que php est fait pour créer quelques pages web, alors que {python,perl,ruby,...} sont plutôt faits pour créer des sites web
et je trouve que ça résumé bien la situation.

quand tu vois que le principe des exceptions est rarement compris par un développeur php, là où tous les langages modernes savent sans servir (parfois en abusent :?), on est en droit de se demander si son utilisation peut être vue comme "professionnelle" :mouarf:
mais il y a aussi des conceptions robustes et des frameworks bien pensés en PHP, et il serait dommage de dire que tout ce qui est fait en PHP est bon à jeter alors que c'est surtout l'usage qui en est fait qui est proche du ridicule :aie:

Citation:

Envoyé par alex_pi

Ah non ! Là en l'occurrence je pensais à d'autres langages de script (typiquement python que je trouve fort sympathique) qui ont quand même des syntaxes vachement plus légère. (Il se trouve que je n'apprécie pas particulièrement la syntaxe d'OCaml)
Mais puisque tu mets les langages fonctionnels sur le tapis, à ma connaissance PHP ne s'est toujours pas décidé à prendre un minimum de traits fonctionnels, contrairement à python et rubby. Ils expliquent que c'est entre autre parce que leur définition de la porté des variable est complètement absurde :-D

je trouve que l'introduction du fonctionnel dans ruby est pas mal alors que dans python, c'est souvent décevant... faut dire que cpython a quand même réussi à faire très fort ses derniers temps :P
je suis allergique à la syntaxe avec "indentation forcée" (c'est d'ailleurs un point qui m'énerve avec #light de F# comparé à OCaml)
08/06/2009, 13h41
alex_pi

Citation:

Envoyé par gorgonite

d'ailleurs beaucoup disent que php est fait pour créer quelques pages web, alors que {python,perl,ruby,...} sont plutôt faits pour créer des sites web

Ah oui, j'aime beaucoup comme résumé ! Et comme un site web n'est pas qu'un agglomérat de page web, PHP n'est pas adapté :)

Qed :p

Citation:

Envoyé par gorgonite

mais il y a aussi des conceptions robustes et des frameworks bien pensés en PHP, et il serait dommage de dire que tout ce qui est fait en PHP est bon à jeter alors que c'est surtout l'usage qui en est fait qui est proche du ridicule :aie:

Ah mais je connais effectivement de très bon programmeurs qui, forcés d'utiliser PHP, réussisse à force d'efforts colossaux à faire quelque chose de très bien ! Mais il n'empêche que je ne connais personne qui choisirait PHP pour commencer un projet from scratch.

Citation:

Envoyé par gorgonite

je trouve que l'introduction du fonctionnel dans ruby est pas mal alors que dans python, c'est souvent décevant... faut dire que cpython a quand même réussi à faire très fort ses derniers temps :P

J'avoue ne pas assez connaitre ruby pour comparer

Citation:

Envoyé par gorgonite

je suis allergique à la syntaxe avec "indentation forcée" (c'est d'ailleurs un point qui m'énerve avec #light de F# comparé à OCaml)

Là, c'est clairement les gouts et les couleurs :p
08/06/2009, 14h16
Jedai

Citation:

Envoyé par gorgonite

d'ailleurs beaucoup disent que php est fait pour créer quelques pages web, alors que {python,perl,ruby,...} sont plutôt faits pour créer des sites web

Tout à fait approprié ! :ccool:

Citation:

Envoyé par gorgonite

je trouve que l'introduction du fonctionnel dans ruby est pas mal alors que dans python, c'est souvent décevant... faut dire que cpython a quand même réussi à faire très fort ses derniers temps :P

Perl a un relativement bon support pour le fonctionnel également, de façon surprenante... (Pour un langage plus moderne selon MacLak, PHP est décidemment nettement en retard)

Citation:

Envoyé par gorgonite

je suis allergique à la syntaxe avec "indentation forcée" (c'est d'ailleurs un point qui m'énerve avec #light de F# comparé à OCaml)

Moi je n'ai jamais apprécié la syntaxe de Python, mais d'un autre côté j'aime bien la syntaxe d'Haskell, les deux sont pourtant sensibles à l'indentation... Parfois le coeur a ses raisons que la raison ignore, n'est-ce pas ?

--
Jedaï
08/06/2009, 15h37
GeantVert13

Et bien... je ne pensais pas déchaîner tant de passion en posant cette question...:oops:

Bref, je poste juste pour vous dire que nous nous orientons plutôt vers du Python, peut être pour des mauvaises raisons... mais bon faut bien prendre une décision... justement pour des raisons de pérennité, Python a fait ses preuves et Lua est un peu jeune (c'est un avis personnel, et je pense que ma hiérarchie "achètera" plus facilement....

Mon seul regret, par rapport à Lua, c'est le package... je m'explique.

Avec Lua, j'ai besoin d'une seule librairie pour interpréter mes scripts, donc très facile à livrer.
Python en revanche, à besoin d'une lib (statique ou dynamique) plus un certains nombre de .py, ce qui complique (un peu) la livraison, mais bon, n'exagérons rien, c'est pas non plus l'horreur...

Encore une fois, merci pour votre implication, vous m'avez donné pas mal d'idées et de pistes !
09/06/2009, 04h29
Garulfo

Citation:

Envoyé par alex_pi

Non mais concrètement, vous êtes vraiment en train de troller sur le fait que PHP est la "rolls des langages de script" ? [...]

Je veux pas te faire de peine, mais je crois qu'il le pense vraiment ;)