Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
- etc, etc...
Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
- etc, etc...
Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
- etc, etc...
Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
À (at) Mon, 27 Oct 2003 08:51:00 +0100,
"José Gallo" écrivait (wrote):Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
Ce ne sont pas vraiment des types (au sens des autres langages). Ce sont
plutôt des sortes de conteneurs... Le typage "fort" viendra avec Perl 6.
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
Il suffit d'utiliser 'use strict;' au début d'un script pour rendre
obligatoire la déclaration des variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
C'est la contrepartie de la puissance d'expression de Perl... Il suffit de
fixer des règles d'écriture pour les gros projets (comme c'est le cas avec
tous les autres langages). Évidemment, si ça n'a pas été fait au départ, il y
a du boulot en perspective...- etc, etc...
Là, je ne vois pas ;-)Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
C'est sûr que reprendre des milliers de lignes de code écrites n'importe
comment n'est pas agréable. Mais c'est tout aussi vrai en Perl qu'en n'importe
quoi d'autre.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
Ne pas perdre de vue que Perl est aussi un langage de script pour programmes
jetables. C'est pour cela qu'il faut qu'il puisse être aussi concis et
laxiste.
Utilisez cela en début de script pour y voir plus clair :
use strict;
use warnings;
# use diagnostics; # pour mieux comprendre les message d'erreurs
À (at) Mon, 27 Oct 2003 08:51:00 +0100,
"José Gallo" <jose.gallo@free.fr> écrivait (wrote):
Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
Ce ne sont pas vraiment des types (au sens des autres langages). Ce sont
plutôt des sortes de conteneurs... Le typage "fort" viendra avec Perl 6.
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
Il suffit d'utiliser 'use strict;' au début d'un script pour rendre
obligatoire la déclaration des variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
C'est la contrepartie de la puissance d'expression de Perl... Il suffit de
fixer des règles d'écriture pour les gros projets (comme c'est le cas avec
tous les autres langages). Évidemment, si ça n'a pas été fait au départ, il y
a du boulot en perspective...
- etc, etc...
Là, je ne vois pas ;-)
Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
C'est sûr que reprendre des milliers de lignes de code écrites n'importe
comment n'est pas agréable. Mais c'est tout aussi vrai en Perl qu'en n'importe
quoi d'autre.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
Ne pas perdre de vue que Perl est aussi un langage de script pour programmes
jetables. C'est pour cela qu'il faut qu'il puisse être aussi concis et
laxiste.
Utilisez cela en début de script pour y voir plus clair :
use strict;
use warnings;
# use diagnostics; # pour mieux comprendre les message d'erreurs
À (at) Mon, 27 Oct 2003 08:51:00 +0100,
"José Gallo" écrivait (wrote):Je viens de me mettre à la programmation en Perl (un peu contraint et forcé
j'avoue dans le cadre d'un nouvel emploi) et je constate avec surprise que
ce langage possède pas mal de faiblesses sur des notions pourtant basiques,
principalement :
- Le fait que Perl est très faiblement typé (seulement 5 types de
variable...)
Ce ne sont pas vraiment des types (au sens des autres langages). Ce sont
plutôt des sortes de conteneurs... Le typage "fort" viendra avec Perl 6.
- Le laxisme tout de même coupable sur les déclarations non obligatoires des
variables.
Il suffit d'utiliser 'use strict;' au début d'un script pour rendre
obligatoire la déclaration des variables.
- Une lisibilité du code relativement difficile due à toutes les bidouilles
sur les listes et les hashtable principalement.
C'est la contrepartie de la puissance d'expression de Perl... Il suffit de
fixer des règles d'écriture pour les gros projets (comme c'est le cas avec
tous les autres langages). Évidemment, si ça n'a pas été fait au départ, il y
a du boulot en perspective...- etc, etc...
Là, je ne vois pas ;-)Bref, je me demandais si vous n'étiez pas de ce fait confronté à des
problèmes de fiabilité ou de reprise de code délicat.
C'est sûr que reprendre des milliers de lignes de code écrites n'importe
comment n'est pas agréable. Mais c'est tout aussi vrai en Perl qu'en n'importe
quoi d'autre.
Je suis en effet habitué à des langages beaucoup plus bornés (Java, C/C++,
ADA...) et je me suis rendu compte combien ces restrictions, au départ
contraignantes, étaient au final génératrice de gain de temps et de
fiabilité à tout niveau. Merci de me faire partager votre expérience à ce
niveau et de m'indiquer les principeaux écueils que vous avez connus en
débutant la programmation Perl.
Ne pas perdre de vue que Perl est aussi un langage de script pour programmes
jetables. C'est pour cela qu'il faut qu'il puisse être aussi concis et
laxiste.
Utilisez cela en début de script pour y voir plus clair :
use strict;
use warnings;
# use diagnostics; # pour mieux comprendre les message d'erreurs
Le fait que Perl soit peu "typé" peut également être perçu comme un
avantage, et il est à noter que c'est le cas d'une majorité de langage
de script (même ceux qui passent pour 'strict' comme Python), de plus
contrairement à beaucoup de langages qui tendent à utiliser les mêmes
opérateurs pour les strings et les nombres (ce qui je trouve entraîne
une confusion regrettable), Perl utilisent des opérateurs tout à fait
différents pour les deux, ce qui permet de voir immédiatement dans
quel "contexte" on se place (la notion de contexte est omniprésente
dans Perl, y compris dans l'utilisation de $_) et évite toute
confusion.
Le fait que Perl soit peu "typé" peut également être perçu comme un
avantage, et il est à noter que c'est le cas d'une majorité de langage
de script (même ceux qui passent pour 'strict' comme Python), de plus
contrairement à beaucoup de langages qui tendent à utiliser les mêmes
opérateurs pour les strings et les nombres (ce qui je trouve entraîne
une confusion regrettable), Perl utilisent des opérateurs tout à fait
différents pour les deux, ce qui permet de voir immédiatement dans
quel "contexte" on se place (la notion de contexte est omniprésente
dans Perl, y compris dans l'utilisation de $_) et évite toute
confusion.
Le fait que Perl soit peu "typé" peut également être perçu comme un
avantage, et il est à noter que c'est le cas d'une majorité de langage
de script (même ceux qui passent pour 'strict' comme Python), de plus
contrairement à beaucoup de langages qui tendent à utiliser les mêmes
opérateurs pour les strings et les nombres (ce qui je trouve entraîne
une confusion regrettable), Perl utilisent des opérateurs tout à fait
différents pour les deux, ce qui permet de voir immédiatement dans
quel "contexte" on se place (la notion de contexte est omniprésente
dans Perl, y compris dans l'utilisation de $_) et évite toute
confusion.
Là, j'abonde fortement : la surcharge d'opérateur est nettement plus
choquant - d'un point de vue compréhension du code - qu'un code mal
codé.
Un code mal écrit -> poubelle. Un code bien écrit avec des surcharges
d'opérateurs, ben, on garde mais on peut souffrir. Un code bien écrit
en Perl se lit tout seul...
Je n'arrive pas trop à comprendre les gens qui râlent contre le côté
obscur de Perl : au contraire, les variables sont immédiatement
visibles, on sait toujours ce que l'on manipule (à défaut de savoir
pourquoi ;-)) et l'héritage de C dans la forme en fait un terrain
connu pour le débutant.
Le seul truc qui peut paraître rebutant sont les variables internes de
Perl... mais pas de quoi en faire un fromage quand même.
Là, j'abonde fortement : la surcharge d'opérateur est nettement plus
choquant - d'un point de vue compréhension du code - qu'un code mal
codé.
Un code mal écrit -> poubelle. Un code bien écrit avec des surcharges
d'opérateurs, ben, on garde mais on peut souffrir. Un code bien écrit
en Perl se lit tout seul...
Je n'arrive pas trop à comprendre les gens qui râlent contre le côté
obscur de Perl : au contraire, les variables sont immédiatement
visibles, on sait toujours ce que l'on manipule (à défaut de savoir
pourquoi ;-)) et l'héritage de C dans la forme en fait un terrain
connu pour le débutant.
Le seul truc qui peut paraître rebutant sont les variables internes de
Perl... mais pas de quoi en faire un fromage quand même.
Là, j'abonde fortement : la surcharge d'opérateur est nettement plus
choquant - d'un point de vue compréhension du code - qu'un code mal
codé.
Un code mal écrit -> poubelle. Un code bien écrit avec des surcharges
d'opérateurs, ben, on garde mais on peut souffrir. Un code bien écrit
en Perl se lit tout seul...
Je n'arrive pas trop à comprendre les gens qui râlent contre le côté
obscur de Perl : au contraire, les variables sont immédiatement
visibles, on sait toujours ce que l'on manipule (à défaut de savoir
pourquoi ;-)) et l'héritage de C dans la forme en fait un terrain
connu pour le débutant.
Le seul truc qui peut paraître rebutant sont les variables internes de
Perl... mais pas de quoi en faire un fromage quand même.
Combien de choses géniales ont été créées
avec des bouts de ficelles par des gens
peu rigoureux mais imaginatifs.
Perl c'est un peu pareil.
De plus, le fait de voir un truc développé
comme un cochon qui marche est autrement
plus motivant pour s'améliorer que de n'avoir
comme résultat que les messages d'erreurs du compilateur !
Voilà mon humble avis.
Combien de choses géniales ont été créées
avec des bouts de ficelles par des gens
peu rigoureux mais imaginatifs.
Perl c'est un peu pareil.
De plus, le fait de voir un truc développé
comme un cochon qui marche est autrement
plus motivant pour s'améliorer que de n'avoir
comme résultat que les messages d'erreurs du compilateur !
Voilà mon humble avis.
Combien de choses géniales ont été créées
avec des bouts de ficelles par des gens
peu rigoureux mais imaginatifs.
Perl c'est un peu pareil.
De plus, le fait de voir un truc développé
comme un cochon qui marche est autrement
plus motivant pour s'améliorer que de n'avoir
comme résultat que les messages d'erreurs du compilateur !
Voilà mon humble avis.
En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
Jean-Michel Hiver writes:
[...]En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
Voilà une bonne raison de ne pas coder en objet ;-)
Jean-Michel Hiver <YouNeedToRemoveThisjhiver@mkdoc.com> writes:
[...]
En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
Voilà une bonne raison de ne pas coder en objet ;-)
Jean-Michel Hiver writes:
[...]En fait des qu'on passe a la programmation objet on manipule presque
toujours des scalaires et les variables cessent d'etre "immediatement
visibles".
Voilà une bonne raison de ne pas coder en objet ;-)
Perl n'oblige personne à programmer proprement mais il offre tous les
mécanismes nécessaires pour le faire. Et si un mécanisme particulier vous
manque il est quasiment toujours possible de l'ajouter.
PS: j'ai un peu l'impression de prêcher des convaincus ;-)
Perl n'oblige personne à programmer proprement mais il offre tous les
mécanismes nécessaires pour le faire. Et si un mécanisme particulier vous
manque il est quasiment toujours possible de l'ajouter.
PS: j'ai un peu l'impression de prêcher des convaincus ;-)
Perl n'oblige personne à programmer proprement mais il offre tous les
mécanismes nécessaires pour le faire. Et si un mécanisme particulier vous
manque il est quasiment toujours possible de l'ajouter.
PS: j'ai un peu l'impression de prêcher des convaincus ;-)