Discussion :

[Lolo78]

Je viens du monde du gros système et la réponse est OUI !!!
La performance est le premier critère en ce qui concerne un bon développement.

Quel que soit le système, le premier critère est de savoir si le résultat est correct. La performance ne vient qu'après.

Et de nos jours, la distinction gros système/moyen système/petit système est très largement dépassée. Dès les années 1999-2000, je travaillais sur un "moyen" système VMS qui était considéré comme le plus gros cluster d'Europe, donc dépassait tous les mainframes type Bull ou IBM de l'époque. Seuls quelques ordinateurs de calcul scientifique (type météo ou grosses simulation scientique) étaient plus gros.

Les ordinateurs d'aujourd'hui sont environ 50 à 100 fois plus rapides que ceux d'il y a dix ans. Pas forcément besoin de mettre des années à créer l'application plus rapide s'il suffit d'attendre que la loi de Moore fasse son effet (même si, bien sûr, elle se rappriche de certaines limites et commence à s’essouffler)

Et surtout, de nos jours, l'heure de développement coûte beaucoup plus cher que l'heure de CPU. Donc, quel que soit le système, la facilité de développement, le temps passé à développer, le time to market, sont bien souvent (presque toujours) plus importants que la performance pure. Ai pire, il revient ben moins cher d'acheter un peu de mémoire ou de puissance CPU supplémentaire.

[Philou67430]

Il n'y a rien de réducteur en cela, tout au contraire.

Si, vous réduisez le champs des possibles en segmentant fortement les langages.

Vous donnez vous même la réponse de l'usage du perl, à savoir créer de petits outils.

Non, je donne des exemples de "mes usages" qui ne sont pas des traitements de données (interaction avec un équipement embarqué par liaison série, clients internets, traitements en lien avec DOORS, calculs, bio-informatique...)
Ça n'est ni le domaine limité de Perl, ni mes propres limites en informatique (j'utilise aussi d'autres langages pour mes besoins professionnels).

Je ne critique pas le perl, tout au contraire, mais tout faire en perl est une erreur !

Où ai-je dis cela ?

Il y a peu être une différence avec votre approche, c'est que j'ai une connaissance informatique plus large que vous.

Comment le savez-vous ?

Encore une fois, mon objectif n'est pas la polémique. Perl, Python, Ruby, ... ne sont pas les mieux adaptés pour tout développement (notamment, dans l'embarqué, ma spécialité professionnelle, il est même assez peu supporté), mais ces langages de script de haut niveau sont, à mes yeux, beaucoup plus polyvalents que le domaine où vous semblez les cantonner.

[Artemus24]

Salut Lolo78.

Et de nos jours, la distinction gros système/moyen système/petit système est très largement dépassée.

Je ne suis pas d'accord sur ce point.
En micro, vous avez fréquemment à votre disposition un tas d'outils pour vous simplifier la vie.
Ce n'est pas le cas en gros système où vous devez programmer par vous même l'algorithme qui vous manque.
Le cas du tri en est un exemple. Vous avez besoin en cobol de trier une table en mémoire, et bien il n'existe aucun outil à votre disposition.
Vous devez par vos propres moyens choisir celui qui sera le plus rapide et qui réponde à votre attente.
Juste sur ce point, j'ai vu des développeurs ne pas faire le bon choix et constater que leur programme dure plus de quatre heures.
En modifiant le tri choisit par mes soins, le temps est tombé à moins de 5 minutes !

Quel que soit le système, le premier critère est de savoir si le résultat est correct.

Il va de soi qu'un programme qui ne répond pas aux attentes d'un utilisateur n'entre pas dans ce genre de critère.
Les trois critères les plus importants (pas nécessairement dans cet ordre) sont la performance, la taille mémoire et surtout la lisibilité.
Selon moi, c'est la lisibilité qui est le critère le plus important !

Dès les années 1999-2000, je travaillais sur un "moyen" système VMS qui était considéré comme le plus gros cluster d'Europe

Qu'est-ce que vous entendez par VMS ? Le système d'exploitation des machines DEC (Digital Equipment Corporation) ?
Car VMS signifie système de mémoire virtuel et s'applique à toutes les machines modernes.

Un cluster, c'est une grappe d'ordinateur. Ce dont je vous parle, c'est la capacité d'un seul ordinateur.

Le plus gros système que j'ai connu est IBM MVS TSO ISPF, dans les années 90, de la société RANK XEROX.
Il était situé à Londres et avait une vocation mondiale. Je travaillais à l'époque dans le nord de Paris.
Je n'ai jamais bien su le nombre d'utilisateurs qui travaillaient dessus, mais il parait qu'il y avait plus de 100.000 points d'accès dans le monde.

Les ordinateurs d'aujourd'hui sont environ 50 à 100 fois plus rapides que ceux d'il y a dix ans.

Non, c'est faux ! La plupart des ordinateurs n'ont pratiquement pas augmenté en vitesse (Ghz) du processeur.
Enfin, tout dépend de ce que vous entendez par "plus rapides".

Le processeur le plus rapide au monde est un AMD FX et tourne à 8,429 GHz avec seulement 8 coeurs.

Il y a une limite qui est difficile franchissable, celle des 5 GHz. On arrive difficilement à dépasser les 4 Ghz en overcloking.
Il suffit de voir les offres sur internet pour se rendre compte que depuis plusieurs années, la vitesse des processeurs n'augmentent plus du tout.
Mon ordinateur qui date de 2009 fait 2.4 Ghz et possède 1 seul coeur avec 2 files ==> HP Compaq 6830s notebook pc.
Donc en dix ans, la vitesse moyenne n'a même pas doublé car la grande majorité de ce que l'on trouve tourne plutôt à 4 Ghz.
Inversement, les processeurs sont multicœurs, avec facilement 8, 12 et 16 cœurs.

La tendance est plutôt au cluster, c'est-à-dire à des grappes d'ordinateurs qui sont montés en parallèle.
Du coup, et ce depuis fort longtemps, on ne parle plus de Ghz pour la vitesse, mais de flops.
--> https://fr.wikipedia.org/wiki/FLOPS

L'ordinateur le plus rapide au monde est chinois et tourne à 93 pétaflops par seconde !
--> http://www.20minutes.fr/high-tech/18...de-100-chinois
--> https://fr.wikipedia.org/wiki/Tianhe-I

Les processeurs sont des Intel Xeon E5540 qui eux tournent à 2.53 Ghz.
--> https://ark.intel.com/fr/products/37...-GTs-Intel-QPI

Pas forcément besoin de mettre des années à créer l'application plus rapide s'il suffit d'attendre que la loi de Moore fasse son effet (même si, bien sûr, elle se rappriche de certaines limites et commence à s’essouffler)

Voilà une information erronée.
La loi de Moore est relatif au nombre de transistors qui double tous les deux ans. Cette loi date des années 1975.
--> https://fr.wikipedia.org/wiki/Loi_de_Moore

La loi de Moore dont vous parlez est une fausse loi puisqu'elle n'a jamais été énoncé par Moore.
Il s'agit improprement de la troisième loi de Moore qui est relatif à la rapidité des processeurs.
Or dans le lien ci-dessus au paragraphe "Loi de Moore et fréquence d'horloge", l'augmentation de la vitesse en Ghz tend à stagner et ce depuis 2004.
Donc non, en plus de dix ans, la vitesse des processeurs n'a pas été multiplié par 50 ou 100.

Vous confondez la vitesse réelle d'un processeur avec sa capacité de traitement qui se fait en parallèle et que l'on nomme des flops.
Je vous conseille de lire le paragraphe "Vitesse réelle et vitesse subjective" du lien sur la loi Moore. J'adhère totalement sur ce qui est dit !

@+

[Lolo78]

Quand je parlais de VMS, je parlais bien évidemment du système d'exploitation VMS de DEC (puis Compaq, puis HP), de bécanes avec des processeurs Alpha à l'époque. Chaque bécane avait des dizaines de processeurs, et la plateforme était un cluster comprenant une vingtaine de bécanes. Résultat, bien que ces bécanes faisaient partie de ce qu'on appelait encore parfois des moyens systèmes (au même titre que par exemple les AS400), la plateforme dépassait en puissance la plupart des gros systèmes de l'époque.

Pour le reste, je n'ai parlé à aucun moment de vitesses d'horloge, mais de puissance associée aux multicores, aux caches multiples, aux mémoires bien plus grosses et bien plus rapides, aux racks de blades, sans parler de disques, de réseaux, etc.

[Artemus24]

Salut à tous.

Pour le reste, je n'ai parlé à aucun moment de vitesses d'horloge, mais de puissance associée aux multicores, aux caches multiples, aux mémoires bien plus grosses et bien plus rapides, aux racks de blades, sans parler de disques, de réseaux, etc

Euh ... question d'interprétation. Quand vous dites :

Les ordinateurs d'aujourd'hui sont environ 50 à 100 fois plus rapides que ceux d'il y a dix ans.

Que devons-nous comprendre ? Et comme j'ai eu un doute dans mon interprétation, j'ai répondu :

Enfin, tout dépend de ce que vous entendez par "plus rapides".

Quand vous dites :

Résultat, bien que ces bécanes faisaient partie de ce qu'on appelait encore parfois des moyens systèmes (au même titre que par exemple les AS400), la plateforme dépassait en puissance la plupart des gros systèmes de l'époque.

je fais exactement la même remarque concernant le super ordinateur chinois "Tianhe-I".
Le processeur est moyen (Intel Xeon E5540) en terme de performance, tandis que l'assemblage de millions de ces processeurs, font de ceux-ci un super-ordinateur.
Encore faut-il un système d'exploitation performant pour gérer tout cela !

Où ai-je dis cela ?

Ci-après, ou alors j'ai mal interprété votre pensée :

C'est exactement le point que je voulais souligner avec perl, l'incroyable richesse du CPAN, qui permet aujourd'hui de toucher à peu près à tous les domaines de développement.

Toucher tous les domaines de développement revient à dire que perl est un langage universel. Il n'y a qu'un pas pour avoir la tentation de tout faire avec perl !

Comment le savez-vous ?

Presque cinquante ans d'expérience dans le domaine informatique me donne quand même un léger avantage sur ce que j'avance, non ?
J'ai débuté dans les années 70, quand la micro-informatique n'existait pas encore dans les entreprises.

Et tout ça, parce que j'ai osé dire :

Pour moi, le perl n'est pas un langage de programmation, mais un langage de manipulation de données.

@+

[Philou67430]

Toucher tous les domaines de développement revient à dire que perl est un langage universel. Il n'y a qu'un pas pour avoir la tentation de tout faire avec perl !

Pas que je n'ai pas franchit... (de la même manière que C est un langage universel mais qu'on ne fait pas tout en C).

Presque cinquante ans d'expérience dans le domaine informatique me donne quand même un léger avantage sur ce que j'avance, non ?

Vous vous avancez alors que vous ne me connaissez toujours pas...

Et tout ça, parce que j'ai osé dire

Il ne s'agissait pas de souligner un outrage (osé), mais une erreur (langage de manipulation de donnée). A moins peut-être que vous parliez de Perl 1.0

[Artemus24]

Salut Philou67430.

Vous vous avancez alors que vous ne me connaissez toujours pas...

Je n'ai pas besoin de vous connaitre, pour savoir comment raisonne un informaticien (j'en suis un aussi).
Que vous soyez un expert en Perl est tout à votre honneur, mais le problème n'est pas là.
Votre tentation est de développer dans le langage que vous connaissez le mieux. Je ne dis pas que c'est mal.
Alors pourquoi développer dans un autre langage que vous ne maîtrisez pas, et qui aurait toutes les qualités recherchées pour ce type de développement ?
Dans certaines missions, je me suis retrouvé confronté à des usines à gaz, juste à cause d'informaticiens que ne voulait pas se remettre en cause.
Il est vrai que je ne vous connais pas, mais quand on fait l'apologie d'une langage, il est rare que l'on aille voir ailleurs.

Je vous sens légèrement susceptible sur cette question.

Il ne s'agissait pas de souligner un outrage (osé), mais une erreur (langage de manipulation de donnée).

Pourquoi considérez-vous que je vous provoque sur ce sujet ?
J'ai une opinion qui est différente de la votre, et c'est cela qui vous dérange !
Et je ne voie pas ce qu'il y a d'enrichissant dans nos échanges, si tout le monde à la même opinion.

Je prends comme exemple, un vieux bouquin (CGI/PERL et Javascript par Issac Cohen, Création de pages HTML interactives, éditions Eyrolles, 1996, ISBN 2-212-08918-X) qui parle de PERL :

Chapitre 5.
Le langage Perl.

Dans les chapitres précédents, nous avons décrit le langage HTML, et le protocole HTTP. Ces deux supports sont utilisés par le Web pour la création de documents et la gestions de requêtes. Ces deux concepts sont réunis lors de la création d'interfaces hébergées par les serveurs. Les applications les plus courantes sont l'accès à une base de données et la gestion de documents tel que les questionnaires. Ces documents sont dites dynamiques car créés lorsque l'utilisateur accède à la ressources.

La programmation de telles interfaces nécessites un langage permettant un accès simplifié au système et aux entrés/sorties standard représentant les canaux de communications privilégiés du protocole HTTP.

Le langage PERL constitue un outil adéquat puisqu'il répond à ceux deux propriétés et possède un ensemble d'opérateurs permettant un traitement simplifié des chaînes de caractères utilisés pour communiquer avec le protocole HTTP.

Le langage PERL est un lanage conçu pour la manipulation des chaînes de caractères, de fichier et de process. Cette manipulation est simplifiée par le nombre important d'opérateurs mis à la disposition de l'utilisateur. Le langage PERL est habituellement perçu comme un langage intermédiaire entre les shell scripts et la programmation en C. En effet, les programmes PERL sont une succession d'instructions et sont similaires à des shell scripts car il n'existe pas de procédures principale telle que la routine main en C. Ils se rapprochent néanmoins du langage C par leur syntaxe et le nombre important de fonctions permettant la manipulation de chaînes de caractères et de fichiers.

Le langage Perl n'est pas précompilé, mais il est toutefois plus rapide que la plupart des langages interprétés, notamment le Bourne Shell. Ceci est dû au fait que les programme PERl sont analysés, interprétés et compilés par l'interprète PERL avant exécution.

Nous présenterons, très brièvement, les principales caractéristiques de PERL. Pour approfondir ces éléments nous conseillons vivement de consulter les ouvrages Learning PERL [Sch94] et Programming Perl [WS92].

J'ai pris le temps nécessaire pour reproduire ce texte, afin de montrer que l'auteur Isaac Cohen, considère le PERL comme un langage de manipulation.
Même si depuis cette époque (1995), le langage PERL a beaucoup évolué, il n'a pas changé de définition, à savoir manipuler des chaînes de caractères et de fichiers, et jouer un rôle intermédiaire entre des SHELL SCRIPTS et des langages de programmations comme le C.

Pourquoi paraphraser la citation de Arthur C. Clarke : « Any sufficiently advanced technology is indistinguishable from magic ».
Considérez-vous PERL comme de la magie ?

@+

[Philou67430]

Mes interventions sont résumées dans votre citation du livre de Cohen (que j'ai également)... je ne me suis pas arrêté à la version de perl de 1995.
Mais vous semblez être bien plus expert que moi en Perl, ce qui est tout à votre honneur.
Au revoir.

[Artemus24]

Salut Philou67430.

Mes interventions sont résumées dans votre citation du livre de Cohen (que j'ai également)...

Je suis fort heureux que vous possédiez ce livre car vous pouvez constater que je n'ai rien inventé.
J'ai pris le temps de recopier ce chapitre pour donner l'opinion de M. Issac Cohen, que je partage entièrement avec lui.

Je ne sais pas en quoi cela vous dérange que je fasse de ce langage un usage différent du votre.
Mais je tiens à souligner que même si nous ne partageons pas la même vision, je respecte votre opinion.

je ne me suis pas arrêté à la version de perl de 1995.

Si je me suis inscrit dans le forum consacré à Perl, c'est pour me perfectionner dans ce langage que j'apprécie toujours.
Oui, en effet, mon Perl date de cette époque, et je n'ai pas honte de le dire.

A l'inverse de vous, je veux bien me remettre en cause dans mes imperfections.
Voire apprendre ce que je ne connais pas, afin d'atteindre un bon niveau de compétence.

Mais vous semblez être bien plus expert que moi en Perl, ce qui est tout à votre honneur.

Je ne sais quoi penser de votre remarque désobligeante.

D'une part, je ne suis expert en rien du tout car je n'ai jamais aimé porter des titres pompeux.
Tout ce que je cherche à faire, c'est participer à des échanges enrichissants pour me perfectionner.
Si je commets des erreurs, j'aimerai bien que l'on me dise pourquoi.
Mais ce que je déteste le plus, c'est d'avoir l'impression d'être dans une secte ou il y a une seule façon de penser.

D'autre part un expert à une vision unique de son domaine de compétence.
Comme énonce le principe de Peter, je pense que vous avez atteint votre niveau d'incompétence.
Pourquoi ? Car vous n'êtes plus en capacité de vous remettre en cause.

Au revoir.

La preuve, vous n'avez même pas les arguments pour vous justifier.
Si vous tirez votre révérence, j'en ferais de même.

Bonne continuation.
@+

[Philou67430]

Si je commets des erreurs, j'aimerai bien que l'on me dise pourquoi.
Mais ce que je déteste le plus, c'est d'avoir l'impression d'être dans une secte ou il y a une seule façon de penser.

D'autre part un expert à une vision unique de son domaine de compétence.
Comme énonce le principe de Peter, je pense que vous avez atteint votre niveau d'incompétence.
Pourquoi ? Car vous n'êtes plus en capacité de vous remettre en cause.

La preuve, vous n'avez même pas les arguments pour vous justifier.
Si vous tirez votre révérence, j'en ferais de même.

Allez, ce n'était qu'un au revoir.
Perl + CPAN supporte :
- des interfaces avec des logiciels divers : Excel (lecture/écriture), Word, Matlab, R, OLE, systèmes Unix, Windows, ..., gestion avancée de l'Unicode
- les interfaces graphiques natives : Tk, Gtk, wx => applications intégrant des interfaces graphiques
- des interfaces avec diverses bases de données
- des frameworks complets : Moose (modern object oriented), bioperl (bio-informatique), Catalyst (web application development), ...
- accès à de nombreux protocoles de communication : rs232, la grande majorité des protocoles internets, le multi-threading, les communications inter-process, les RPC, ...
...
Tout ceci laisse supposer que l'on peut faire un peu plus que ce qu'on en faisait en 1995.
D'ailleurs, en 1995, le protocole CGI utilisait principalement le langage perl dans ses implémentations. Ce n'est pas ce que j'appelle à proprement parler un usage "de manipulation de données".