Je suis sur Solaris 9.
J'ai qques scripts Bash, et Perl qui font des trucs long et toutes les
heures. Ca marche assez bien.
Mais bon, que ce soit en Perl ou en Bash, je lance souvent (en boucle)
des commandes de l'OS : 'echo' 'cp' 'mv' 'ssh' 'ftp' sftp' 'sqlplus'
... donc en fait ma solution n'est pas super optimisee : a chaque fois
l'OS alloue un shell (thread/RAM/pile...) teste mes parametres, exec la
fonction et libere tout ca avant de rendre la main a mon script.
Je pense qu'en C se serait 1000 fois + rapide...
Comme j'ai un peux de temps, et d'autres projets du meme style qui
arrivent, ma question :
- dois-je tout porter en C (me faire des fonctions, structs, squelette
app.)
- dois-je explorer + en detail les lib Perl (qui sont en Standard sur
Solaris 9).
- Perl est-il compile a la volee, ou tout le temps interprete ? J'ai
l'impression que c'est un peux comme Java, me trompe-je ?
Il y a certains trucs que je sais pas faire en Perl (exec .profile,
SQL...) et puis je ne sais pas trop quelles lib sont installee en
standard sur Solaris... c'est pour ca que je passe par Bash et meme en
Perl je lance des commandes de l'OS (sqlplus, ftp, sftp).
L'Académie Française Spécialiste en profilage de code ;-)
est d'accord avec Google, goulot d'étranglement est le terme le plus usuel. Certes. Mais la raison en est peut-être simplement que plus de gens
connaissent, parfois intimement, le goulot que le goulet ?
[...]
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ? Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier. Ah. Puisqu'il faut ....
-- Pierre Maurette
[...]
L'Académie Française
Spécialiste en profilage de code ;-)
est d'accord avec Google, goulot d'étranglement est le
terme le plus usuel.
Certes. Mais la raison en est peut-être simplement que plus de gens
connaissent, parfois intimement, le goulot que le goulet ?
[...]
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de
limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier.
Ah. Puisqu'il faut ....
L'Académie Française Spécialiste en profilage de code ;-)
est d'accord avec Google, goulot d'étranglement est le terme le plus usuel. Certes. Mais la raison en est peut-être simplement que plus de gens
connaissent, parfois intimement, le goulot que le goulet ?
[...]
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ? Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
On doit d'ailleurs pouvoir se passer de "d'étranglement", en restant clair.
Non, il s'agit d'une locution et il faut l'employer en entier. Ah. Puisqu'il faut ....
-- Pierre Maurette
listes
Stephane Zuckerman wrote:
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces soi-disant nouveaux langages qui sont révolutionnaires, mais qui empruntent tout à C ou C++, et ne font finalement que changer les mots-clef.
Vous pensez là à l'objective-c ? (j'avoue que ma connaissance en programmation est trèèèèès limitée. A part le basic, j'ai pas pratiqué les autres langages, mais j'ai un peu suivit l'histoire des langages.
Voilà... et désolé de vous avoir interrompu.... -- <http://www.clampin.com/>, l'actualité par Clampin
Stephane Zuckerman <szuckerm@etu.utc.fr> wrote:
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses
idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces
soi-disant nouveaux langages qui sont révolutionnaires, mais qui
empruntent tout à C ou C++, et ne font finalement que changer les
mots-clef.
Vous pensez là à l'objective-c ? (j'avoue que ma connaissance en
programmation est trèèèèès limitée. A part le basic, j'ai pas pratiqué
les autres langages, mais j'ai un peu suivit l'histoire des langages.
Voilà... et désolé de vous avoir interrompu....
--
<http://www.clampin.com/>, l'actualité par Clampin
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces soi-disant nouveaux langages qui sont révolutionnaires, mais qui empruntent tout à C ou C++, et ne font finalement que changer les mots-clef.
Vous pensez là à l'objective-c ? (j'avoue que ma connaissance en programmation est trèèèèès limitée. A part le basic, j'ai pas pratiqué les autres langages, mais j'ai un peu suivit l'histoire des langages.
Voilà... et désolé de vous avoir interrompu.... -- <http://www.clampin.com/>, l'actualité par Clampin
Richard Delorme
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
-- Richard
Mais la raison en est peut-être simplement que plus de gens
connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de
limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer
son contenu. Le goulot, c'est quand même bien pratique pour verser un
liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur,
mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
-- Richard
Emmanuel Delahaye
Richard Delorme wrote on 01/10/05 :
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today; those that understand binary, and those that dont."
Richard Delorme wrote on 01/10/05 :
Mais la raison en est peut-être simplement que plus de gens connaissent,
parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de
limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son
contenu. Le goulot, c'est quand même bien pratique pour verser un liquide.
Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais
pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today;
those that understand binary, and those that dont."
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today; those that understand binary, and those that dont."
Pierre Maurette
Richard Delorme wrote on 01/10/05 :
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum... De faux rhum.
Puisqu'on est dans le goulot, la carafe et le pichet, restons-y.
-- Pierre Maurette
Richard Delorme wrote on 01/10/05 :
Mais la raison en est peut-être simplement que plus de gens connaissent,
parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de
limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son
contenu. Le goulot, c'est quand même bien pratique pour verser un liquide.
Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais
pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum...
De faux rhum.
Puisqu'on est dans le goulot, la carafe et le pichet, restons-y.
Mais la raison en est peut-être simplement que plus de gens connaissent, parfois intimement, le goulot que le goulet ?
Ou que goulet est un terme désuet ?
L'idée de limiter un débit est plus dans goulet que dans goulot.
Ce n'est pas évident, l'objectif d'un goulot (col de bouteille) est de limiter le débit, non ?
Non. D'économiser le liège. Et de limiter l'oxydation du contenu.
Une carafe¹ a un goulot, n'utilise pas de liège et sert plutôt à aérer son contenu. Le goulot, c'est quand même bien pratique pour verser un liquide. Sinon on mettrait le vin dans des bocaux.
¹ A ne pas confondre avec un pichet, qui a une anse et un bec verseur, mais pas nécessairement de goulot, et qui est moins pratique à l'usage.
Mince, je me suis trompé de forum... De faux rhum.
Puisqu'on est dans le goulot, la carafe et le pichet, restons-y.
-- Pierre Maurette
bruno modulix
clampin wrote:
Stephane Zuckerman wrote:
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces soi-disant nouveaux langages qui sont révolutionnaires, mais qui empruntent tout à C ou C++, et ne font finalement que changer les mots-clef.
Vous pensez là à l'objective-c ?
Je ne pense pas, non. Objective-C - qui est est un langage déjà ancien - "n'emprunte" rien au C, puisque c'est un sur-ensemble *strict* du C. Il ne fait qu'ajouter au C standard une surcouche objet directement inspirée de Smalltalk.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
clampin wrote:
Stephane Zuckerman <szuckerm@etu.utc.fr> wrote:
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses
idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces
soi-disant nouveaux langages qui sont révolutionnaires, mais qui
empruntent tout à C ou C++, et ne font finalement que changer les
mots-clef.
Vous pensez là à l'objective-c ?
Je ne pense pas, non. Objective-C - qui est est un langage déjà ancien -
"n'emprunte" rien au C, puisque c'est un sur-ensemble *strict* du C. Il
ne fait qu'ajouter au C standard une surcouche objet directement
inspirée de Smalltalk.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Et Perl n'est pas C. Donc il possède quand même sa syntaxe et ses idiômes, et c'est tant mieux. Je commence à en avoir ras-le-bol, de ces soi-disant nouveaux langages qui sont révolutionnaires, mais qui empruntent tout à C ou C++, et ne font finalement que changer les mots-clef.
Vous pensez là à l'objective-c ?
Je ne pense pas, non. Objective-C - qui est est un langage déjà ancien - "n'emprunte" rien au C, puisque c'est un sur-ensemble *strict* du C. Il ne fait qu'ajouter au C standard une surcouche objet directement inspirée de Smalltalk.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Vincent Lefevre
Dans l'article <433bf1ff$0$11756$, Pierre Habouzit écrit:
désolé, mais des trucs du genre :
$| = 1;
qui veut dire que le dernier fichier ouvert va être ouvert en mode synchrone, c'est vachement élégant, c'est évident ... </ironie>
Évite de parler de ce que tu ne connais/comprends pas. Merci.
$| s'applique au canal en cours. En pratique, c'est STDOUT. Si tu veux spécifier le fichier, ça se fait avec HANDLE->autoflush(1). Le C n'est pas très différent, avec certaines fonctions qui s'appliquent à stdout (e.g. printf); et que dire de la différence entre puts et fputs...
Je suppose que le $| a été gardé pour compatibilité avec les très vieilles versions de Perl, mais maintenant que Perl a des objets, il n'est plus utile, sauf pour écrire des choses simples (genre quand on ne travaille que sur STDOUT).
Perl est un langage qui sous des prétextes fallacieux de concision pousse à écrire des horreurs syntaxiques. Perl est par essence un langage Write-Only.
Pas plus que le C.
Il y a évidemment certaines choses qu'on peut vraiment reprocher en Perl. Par exemple, le fait que /$rx/ avec $rx vide utilise la dernière expression rationnelle qui a matché au lieu d'utiliser la regexp vide. Donc pour faire un filtrage optionnel, il faut écrire quelque chose du genre /(?#)$_[0]/ au lieu de /$_[0]/, i.e. en insérant un commentaire vide.
Autre exemple: le fait que le comportement de |, & et ^ dépende du type interne, dont l'utilisateur n'a généralement pas conscience. Mais les conversions implicites de C (notamment entre signed et unsigned) ne sont pas mieux (idem pour "double x = 1/2;" qui est pourtant assez logique).
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
Dans l'article <433bf1ff$0$11756$626a14ce@news.free.fr>,
Pierre Habouzit <madcoder@debian.org> écrit:
désolé, mais des trucs du genre :
$| = 1;
qui veut dire que le dernier fichier ouvert va être ouvert en mode
synchrone, c'est vachement élégant, c'est évident ... </ironie>
Évite de parler de ce que tu ne connais/comprends pas. Merci.
$| s'applique au canal en cours. En pratique, c'est STDOUT. Si tu
veux spécifier le fichier, ça se fait avec HANDLE->autoflush(1).
Le C n'est pas très différent, avec certaines fonctions qui
s'appliquent à stdout (e.g. printf); et que dire de la différence
entre puts et fputs...
Je suppose que le $| a été gardé pour compatibilité avec les très
vieilles versions de Perl, mais maintenant que Perl a des objets,
il n'est plus utile, sauf pour écrire des choses simples (genre
quand on ne travaille que sur STDOUT).
Perl est un langage qui sous des prétextes fallacieux de concision
pousse à écrire des horreurs syntaxiques. Perl est par essence un
langage Write-Only.
Pas plus que le C.
Il y a évidemment certaines choses qu'on peut vraiment reprocher
en Perl. Par exemple, le fait que /$rx/ avec $rx vide utilise la
dernière expression rationnelle qui a matché au lieu d'utiliser
la regexp vide. Donc pour faire un filtrage optionnel, il faut
écrire quelque chose du genre /(?#)$_[0]/ au lieu de /$_[0]/,
i.e. en insérant un commentaire vide.
Autre exemple: le fait que le comportement de |, & et ^ dépende du
type interne, dont l'utilisateur n'a généralement pas conscience.
Mais les conversions implicites de C (notamment entre signed et
unsigned) ne sont pas mieux (idem pour "double x = 1/2;" qui est
pourtant assez logique).
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses
difficilement parsables par des humains pour tout traitement avancé
(cf les fonctions utilisées en internes pour les complétions).
Dans l'article <433bf1ff$0$11756$, Pierre Habouzit écrit:
désolé, mais des trucs du genre :
$| = 1;
qui veut dire que le dernier fichier ouvert va être ouvert en mode synchrone, c'est vachement élégant, c'est évident ... </ironie>
Évite de parler de ce que tu ne connais/comprends pas. Merci.
$| s'applique au canal en cours. En pratique, c'est STDOUT. Si tu veux spécifier le fichier, ça se fait avec HANDLE->autoflush(1). Le C n'est pas très différent, avec certaines fonctions qui s'appliquent à stdout (e.g. printf); et que dire de la différence entre puts et fputs...
Je suppose que le $| a été gardé pour compatibilité avec les très vieilles versions de Perl, mais maintenant que Perl a des objets, il n'est plus utile, sauf pour écrire des choses simples (genre quand on ne travaille que sur STDOUT).
Perl est un langage qui sous des prétextes fallacieux de concision pousse à écrire des horreurs syntaxiques. Perl est par essence un langage Write-Only.
Pas plus que le C.
Il y a évidemment certaines choses qu'on peut vraiment reprocher en Perl. Par exemple, le fait que /$rx/ avec $rx vide utilise la dernière expression rationnelle qui a matché au lieu d'utiliser la regexp vide. Donc pour faire un filtrage optionnel, il faut écrire quelque chose du genre /(?#)$_[0]/ au lieu de /$_[0]/, i.e. en insérant un commentaire vide.
Autre exemple: le fait que le comportement de |, & et ^ dépende du type interne, dont l'utilisateur n'a généralement pas conscience. Mais les conversions implicites de C (notamment entre signed et unsigned) ne sont pas mieux (idem pour "double x = 1/2;" qui est pourtant assez logique).
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
"Vincent Lefevre" <vincent+ wrote in message news:20051005133806$
Dans l'article <433bf1ff$0$11756$, Pierre Habouzit écrit:
Perl est un langage qui sous des prétextes fallacieux de concision pousse à écrire des horreurs syntaxiques. Perl est par essence un langage Write-Only.
Pas plus que le C.
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
Attention, ne provoque pas madcoder sur zsh ;-)
-- Chqrlie.
PS: si perl n'existait pas, il ne faudrait pas l'inventer.
"Vincent Lefevre" <vincent+news@vinc17.org> wrote in message
news:20051005133806$3b63@prunille.vinc17.org...
Dans l'article <433bf1ff$0$11756$626a14ce@news.free.fr>,
Pierre Habouzit <madcoder@debian.org> écrit:
Perl est un langage qui sous des prétextes fallacieux de concision
pousse à écrire des horreurs syntaxiques. Perl est par essence un
langage Write-Only.
Pas plus que le C.
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses
difficilement parsables par des humains pour tout traitement avancé
(cf les fonctions utilisées en internes pour les complétions).
Attention, ne provoque pas madcoder sur zsh ;-)
--
Chqrlie.
PS: si perl n'existait pas, il ne faudrait pas l'inventer.
"Vincent Lefevre" <vincent+ wrote in message news:20051005133806$
Dans l'article <433bf1ff$0$11756$, Pierre Habouzit écrit:
Perl est un langage qui sous des prétextes fallacieux de concision pousse à écrire des horreurs syntaxiques. Perl est par essence un langage Write-Only.
Pas plus que le C.
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
Attention, ne provoque pas madcoder sur zsh ;-)
-- Chqrlie.
PS: si perl n'existait pas, il ne faudrait pas l'inventer.
Pierre Habouzit
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
zsh a une syntax dégueulasse, ca je suis le premier à le reconnaitre.
mais : (1) zsh ne se veut pas être un langage de programmation, et est par essence write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche plus et on les commente lourdement. Comme ils n'intéragissent pas avec le reste, on s'en fout un peu si c'est pas lisible.
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde (sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement heureux.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire justifie les saletés qu'on voit dans tel ou tel autre langage. C'est un argument bien faible.
pour (1) il est clair que perl se *veut* être un langage de programmation (ou alors les gens le croient tellement, que ca en devient une vérité de facto)
pour (2), perl ne se traine que sa propre compatibilité. Si il est si horrible, c'est parce que dès l'origine sa conception est catastrophique.
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses
difficilement parsables par des humains pour tout traitement avancé
(cf les fonctions utilisées en internes pour les complétions).
zsh a une syntax dégueulasse, ca je suis le premier à le reconnaitre.
mais :
(1) zsh ne se veut pas être un langage de programmation, et est par essence
write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts
de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche
plus et on les commente lourdement. Comme ils n'intéragissent pas avec
le reste, on s'en fout un peu si c'est pas lisible.
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde
(sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement
heureux.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire
justifie les saletés qu'on voit dans tel ou tel autre langage.
C'est un argument bien faible.
pour (1) il est clair que perl se *veut* être un langage de programmation
(ou alors les gens le croient tellement, que ca en devient une vérité de
facto)
pour (2), perl ne se traine que sa propre compatibilité. Si il est si
horrible, c'est parce que dès l'origine sa conception est catastrophique.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Et on est loin du zsh, où on est quasiment obligé d'écrire des choses difficilement parsables par des humains pour tout traitement avancé (cf les fonctions utilisées en internes pour les complétions).
zsh a une syntax dégueulasse, ca je suis le premier à le reconnaitre.
mais : (1) zsh ne se veut pas être un langage de programmation, et est par essence write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche plus et on les commente lourdement. Comme ils n'intéragissent pas avec le reste, on s'en fout un peu si c'est pas lisible.
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde (sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement heureux.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire justifie les saletés qu'on voit dans tel ou tel autre langage. C'est un argument bien faible.
pour (1) il est clair que perl se *veut* être un langage de programmation (ou alors les gens le croient tellement, que ca en devient une vérité de facto)
pour (2), perl ne se traine que sa propre compatibilité. Si il est si horrible, c'est parce que dès l'origine sa conception est catastrophique.
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Vincent Lefevre
Dans l'article <4346bc9e$0$21220$, Pierre Habouzit écrit:
mais : (1) zsh ne se veut pas être un langage de programmation, et est par essence write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche plus et on les commente lourdement. Comme ils n'intéragissent pas avec le reste, on s'en fout un peu si c'est pas lisible.
Tiens, la dernière fois que j'ai cité du zsh (il y a deux jours), il y avait plus de commentaires que de code (mais ce n'était pas à cause de la syntaxe, et pas la faute de zsh).
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde (sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement heureux.
Oui, je pense que c'est la raison principale, et le fait de vouloir garder un peu de consistence.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire justifie les saletés qu'on voit dans tel ou tel autre langage. C'est un argument bien faible.
Pour Perl, je ne trouve pas vraiment qu'il est horrible ou sale.
Dans l'article <4346bc9e$0$21220$626a54ce@news.free.fr>,
Pierre Habouzit <madcoder@debian.org> écrit:
mais :
(1) zsh ne se veut pas être un langage de programmation, et est par essence
write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts
de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche
plus et on les commente lourdement. Comme ils n'intéragissent pas avec
le reste, on s'en fout un peu si c'est pas lisible.
Tiens, la dernière fois que j'ai cité du zsh (il y a deux jours),
il y avait plus de commentaires que de code (mais ce n'était pas
à cause de la syntaxe, et pas la faute de zsh).
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde
(sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement
heureux.
Oui, je pense que c'est la raison principale, et le fait de vouloir
garder un peu de consistence.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire
justifie les saletés qu'on voit dans tel ou tel autre langage.
C'est un argument bien faible.
Pour Perl, je ne trouve pas vraiment qu'il est horrible ou sale.
Dans l'article <4346bc9e$0$21220$, Pierre Habouzit écrit:
mais : (1) zsh ne se veut pas être un langage de programmation, et est par essence write only : lorsqu'on écrit son .zshrc il y a des tas de petits bouts de zsh qui trainent, et qui une fois qu'ils marchent, on ne les touche plus et on les commente lourdement. Comme ils n'intéragissent pas avec le reste, on s'en fout un peu si c'est pas lisible.
Tiens, la dernière fois que j'ai cité du zsh (il y a deux jours), il y avait plus de commentaires que de code (mais ce n'était pas à cause de la syntaxe, et pas la faute de zsh).
(2) zsh est obligé de respecter un minimum les shells POSIX, et vu la merde (sisi) qu'est cette syntaxe, si on veut l'étendre, c'est rarement heureux.
Oui, je pense que c'est la raison principale, et le fait de vouloir garder un peu de consistence.
(3) je ne vois pas pourquoi le fait que tel ou tel langage soit pire justifie les saletés qu'on voit dans tel ou tel autre langage. C'est un argument bien faible.
Pour Perl, je ne trouve pas vraiment qu'il est horrible ou sale.
