anaseto a écrit 2229 commentaires

Eclipse propose une complétion, le gars accepte, et là Eclipse positionne le curseur entre les parenthèses et liste les arguments attendus par la fonction et leur type.

En même temps, ça dépend complètement du langage ce genre de choses. Pour OCaml, par exemple, tu as quelque chose du même genre (du moins par rapport à ce que ta description me fait imaginer) avec merlin, qui marche pour vim et emacs, et qui prend aussi en compte tes propres modules, et te dit aussi entre autres où sont tes erreurs de type exactement. L'avantage c'est que c'est un programme externe écrit en OCaml lui-même prévu pour être utilisé avec différents éditeurs.

Edit : marrant deux réponses simultanées qui commencent avec "ça dépend du langage".

Et ça pète joyeusement la moitié de tes raccourcis clavier de tes logiciels.

Tous les raccourcis de tmux passent par un ctrl-b par défaut (que chacun change à sa guise), je ne vois pas comment ça peut casser la moitié des raccourcis… tout au plus un raccourci par logiciel, si on n'a pas de chance. Perso, ça ne m'a cassé aucun des raccourcis que j'utilise avec ctrl-e à la place de ctrl-b ("e" parce qu'en bépo c'est sous l'index).

Ils ajoutent encore un niveau de raccourcis qui vient te casser les noisettes.

Je trouve logique que des actions fréquentes soient en accés direct (comme la plupart des actions d'édition typiques), et que des choses moins fréquentes qu'on ne fait pas plusieurs fois par seconde (ouvrir un nouveau onglet), demandent un niveau d'indirection. En tous cas, tmux me sert de gestionnaire de fenêtres pour mon environnement vim+mutt+shell+etc. et je trouve ça très agréable.

Ils sont utilise surtout pour garder des logiciels ouverts entre différentes sessions.

En plus des avantages que procurent les sessions, il y a les avantages comme pouvoir copier-coller au clavier facilement du texte d'un pane à un autre, ainsi que pouvoir scripter ce genre de choses (ce qui permet, par exemple depuis vim avec le plugin vim-slime, d'envoyer facilement du texte n'importe où ailleurs).

Je suis d'accord, mais la première méthode n'offre pas toujours une intégration parfaite : si tu prends un client graphique, il t'ouvre ensuite quelque part une autre fenêtre avec ton éditeur, qui n'a pas la même ergonomie ni des raccourcis dans le même esprit, c'est pas idéal non plus. Après, vim+mutt c'est un duo qui marche bien, mais je ne trouve pas l'approche d'emacs si répréhensible, la philosophie Unix j'aime bien, mais des petits écarts de temps en temps ne sont pas forcément mauvais. Le navigateur web intégré ou d'autres trucs du genre, je trouve ça un peu plus limite parce que ça n'a vraiment plus grand chose à voir avec la lecture et édition de texte.

Le mail, c'est plus gadget, mais quitte à écrire du texte, autant utiliser un éditeur avec de vrais fonctionnalités d'édition (voire utiliser toutes les fonctionnalités d'org-mode !).

Je ne trouve pas que ce soit gadget du tout, je suis sûr que si j'écrivais mes mails avec un éditeur de texte ad hoc fait pour l'occasion, je ne me sentirais vraiment pas à l'aise (bon, en l'occurence je fais du mutt+vim, mais c'est la même idée).

Sublime Text ou Atom peuvent être utilisés dans un terminal ?

C'est tout de même de moins en moins utile ça.

Curieux comme remarque, en quoi ça l'était plus avant et moins maintenant ? En tous cas, chez moi, à part ce qui a trait à images/vidéo/pdfs… , tous les logiciels que j'utilise passent par le terminal dans une session tmux, ce qui me fournit un environnement homogène, tous les outils que je connais étant à portée de main; et aussi, j'ai le même environnement à travers ssh qu'en local, ce qui n'est pas mal.

Pour ce qui est de la redondance (qui n'a rien à voir avec le contexte dont parle Michaël), un possible avantage qui me vient c'est que, s'il y a une erreur de syntaxe, elle soit plus facilement localisable : avec des S-expressions, vu qu'on ferme toujours avec le même symbole, s'il manque une parenthèse fermante, on peut plus difficilement deviner quelle parenthèse on a oubliée de fermer.

En plus, je ne suis pas persuadé que ce freeze soit un gain pour Debian en général. Qui utilise stable ?

Eh bien, moi j'ai debian stable sur un portable que je n'utilise pas beaucoup, ça m'évite de perdre du temps avec quand j'en ai besoin (j'utilise un fixe avec openbsd le reste du temps).

En même temps, il faut voir si la situation serait différente si l'évasion fiscale était impossible.

Ou si tout le monde y avait droit et que, n'étant pas plus bêtes que d'autres, on devenait aussi un paradis fiscal… mais quelque chose me dit que ceux qui font de l'évasion fiscale en France n'apprécieraient pas.

En plus c'est pas comme si perl était dénué de défauts (comme tout langage).

En effet. Ceci dit, ces dernières années je trouve, en lisant les perldelta, que beaucoup de choses sont faites, et qu'il y a plus d'activité que dans le début des années 2000. Je ne suis pas sûr que python ou ruby aient vraiment plus évolué (au sens, le langage en soi) que perl ces dernières années (après, je ne suis pas le détail d'évolution de ces langages, donc je peux me tromper).

En quoi Perl gère-t-il les chaînes de caractères et les encodages particulièrement bien ?

Eh bien, disons que les chaînes de caractères étaient, initialement, une des raisons principales d'être de Perl. Le nombre de fonctions pour manipuler de base de façon pratique des chaînes de caractères, et la quantité de fonctionnalités des regexps perl (qui évolue régulièrement), ne se retrouve pas ailleurs, que je sache. Pour ce qui est de l'encodage, perl se débrouille bien avec l'unicode, qui se marie bien avec les regexps, entre autres. Une des choses qui peut surprendre venant d'autres langages est qu'il n'y ait pas de "unicode par défaut", l'encodage devant être précisé à la main. Mais c'est motivé (j'étais tombé un jour sur cette question sur stackoverflow, et la principale réponse m'avait montré à quel point faire de l'unicode bien est compliqué, alors que je me demandais justement pourquoi ce n'était pas automatique comme dans d'autres langages).

Et pourquoi les autres structures classiques n'ont-elles pas un préfixe à elles ?

Parce qu'en Perl il n'y a que ces trois structures de base. Les objets rentrent dans la catégorie "scalaire". Le choix de se limiter à ces trois est peut-être pas idéal d'un point de vue théorique, mais en pratique il se justifie assez vu l'utilisation qui en est faite.

En même temps, ce n'est pas un langage idéal d'un point de vue marketing. Il n'aura par exemple probablement jamais beaucoup d'avenir dans l'éducation. Ce n'est pas non plus un langage qui "fait sérieux" (il suffit de voir les petites blagues par-ci par-là dans la doc officielle). C'est un langage qui a été pensé pour être pratique et efficace pour le programmeur, pas pour être élégant, et, ça, ce sera toujours une barrière à sa popularité.

Les 2 gros "concurrents" python et ruby ont fait parler d'eux pour l'un pour (entre autre) fabric, glance et django et l'autre pour (entre autre) puppet, rail et capistrano.

Ces logiciels datent pas non plus d'hier, et puis côté web, avec mojolicious, dancer, etc. je trouve qu'au contraire perl s'en sort plutôt bien, et qu'il y a de l'activité. Mais reste que la "killer app" de perl, c'est perl lui-même et CPAN, et c'est ce qui fait qu'il est utilisé toujours aujourd'hui, et qu'il continuera à l'être encore longtemps probablement.

et perl 5 semble presque être en mode maintenance. Une grosse partie des nouveautés sont des idées de perl6 portées.

C'est assez vrai, mais je ne vois pas trop en quoi c'est un problème, c'est même plutôt une bonne chose. À y regarder de près, perl a beaucoup changé depuis les premières 5.00x jusqu'à la 5.020. Et c'est d'ailleurs une preuve que perl5 n'était pas si mal fait que de voir qu'il a pu évoluer sans pour autant avoir eu de rupture majeure dans le langage. En un certain sens, perl a évité une rupture, vu qu'en pratique perl6 a surtout servi comme source d'inspiration et d'expérimentation, sans vraiment prétendre, je pense, remplacer perl5, et ce n'est peut-être pas plus mal finalement.

Sincèrement si vous aimez perl, si vous utilisez perl, n'hésitez pas à partager votre enthousiasme pour ce langage c'est à mon avis la seule chose qui lui manque.

Je suis d'accord, quelque chose qui manque à perl c'est bien le marketing, et faire passer de la tête des gens l'étape "script CGI fait à la va-vite impossible à relire" —étape à laquelle perl a dû sa mauvaise réputation et qui paradoxalement a été le responsable de l'apogée de sa popularité à une époque—, pour qu'ils sachent à quoi ressemble perl aujourd'hui.

Allez, je marche sur le troll (c'est pas bien, je sais, mais c'est demandé si gentiment…).

Non mais sérieusement, qui utilise encore perl en 2014?

Par exemple, ceux qui ont besoin d'un langage de script qui gère les chaînes de caractères et les encodages particulièrement bien, et de façon commode. Ou ceux qui aiment que leur langage soit un peu rigoureux et sache ce qu'est une variable locale à un bloc, qu'il prévienne lorsque l'on redéfinit une variable, ou lorsqu'on essaie une comparaison numérique douteuse comme 42 == "ma chaîne". Certains veulent un langage qui permette d'écrire des vraies fonctions anonymes. D'autres aiment pouvoir savoir d'un simple coup d'œil si leur variable est un tableau, un hash, ou un scalaire, ou aiment que 42 == "42" renvoie vrai, etc. Enfin, certains aiment que lorsqu'ils font juste un one-liner pour la ligne de commande, les warnings et limitations qui seraient utiles pour un script ne viennent pas les embêter.

Il y a aussi tous ceux qui ont découvert un jour le module CPAN de leurs rêves, qui n'existait pas pour d'autres langages et qui leur a fait gagner du temps ; il y a aussi ceux qui aiment la communauté, et son esprit pratique et d'apprentissage par l'exemple avec des cookbook, et qui fait qu'utiliser un module ne demande souvent même pas d'entrer dans le cœur de la doc, les exemples de la synopsis ou du cookbook qui va avec le module étant suffisants pour démarrer. Et puis ceux qui aiment la stabilité de perl, et le fait que des scripts d'il y a plus de quinze ans marchent encore out-of-the-box, ou alors avec de très petites modifications, même s'ils ne se conforment plus au style d'aujourd'hui.

Il y a aussi tous les utilisateurs indirects de programmes finaux, comme toi probablement.

Et j'oublie multitude de raisons d'utilisation, comme l'existence des cpantesters.

Pour la peine, et pour revenir au sujet, un module qui n'est peut-être pas mon "préféré", mais peut-être un de ceux qui m'ont le plus émerveillé : Devel::Nytprof, un profiler pour perl.

S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.

La différence principale, c'est que même les langages de programmation soi-disant compliqués, sont vraiment beaucoup plus réguliers et faciles à apprendre qu'une langue naturelle, si on met de côté les concepts de programmation génériques qui ne sont pas spécifiques à un langage. Passer de python à perl, ou de perl à ruby, c'est extrêmement facile par rapport à passer du français au russe, ou du russe au chinois.

Et si certaines tournures semblent trop concises dans des langages comme perl, je n'ai pas l'impression qu'en pratique ce soit un problème pour peu qu'on s'y mette; je sais que certains semblent avoir souffert avec ce langage, mais la seule explication convaincante que j'ai pu trouver jusqu'à présent c'est qu'ils ont dû supporter la lecture d'un code dans un style d'il y a quinze ans ou plus écrit à la va-vite et dont le problème majeur n'était pas l'utilisation de tournures concises.

Mais un code ne peut pas être « trop » optimisé

En un certain sens, oui : certaines mesures de mitigation d'exploit utilisées sur OpenBSD impactent (un peu) les performances. Les annuler pour des raisons de performance peut, suivant les cas, être considéré comme une optimisation de trop.

Et au-delà, le fait qu'optimiser en général complique le code et le rend moins auditable, fait que performance et sécurité ne vont pas forcément bien ensemble, donc du point de vue sécurité, on peut avoir du code trop optimisé (à moins que l'optimisation soit prouvée formellement, bien sûr, mais il y a peu de chances).

Ce que j'ai retenu, c'est que latexmk se débrouille très bien pour faire le calcul de dépendances et du nombre de passes nécessaires pour compiler un document LaTeX. Du coup, BSD Owl pourrait simplifier et améliorer significativement cette partie en passant par latexmk (du moins comme dépendance optionnelle) pour son module pour LaTeX. D'autres choses (comme la possibilité de faire un "make install"), font que les deux outils peuvent devenir complémentaires pour le LaTeX.

Je pense que si tu en étais resté purement aux points techniquement faibles du système que latexmk résout, ton message aurait été beaucoup mieux reçu ; il vaut mieux éviter les "on est en 2014" et ce genre de choses, qui ne sont pas très efficaces, et brouillent le message.

Enfin, merci quand même de m'avoir fait découvrir latexmk, je pense que je vais l'utiliser à partir de maintenant.

J'ai dit que ça ne marchait pas, c'est vrai.

Je te trouve quand même un peu catégorique. Je ne dis pas que latexmk n'est pas bien, au contraire, je trouve ça intéressant, mais un système plus naïf marche quand même dans beaucoup de cas. Pour dire, ma façon de faire est encore plus naïve (simples makefiles portables écrits à la main avec un peu de m4 pour pas trop me répéter) et je n'ai pas l'impression de passer mon temps avec des problèmes de build.

La page man de dash dit "sous-shell" dans les deux cas, et celle de ksh aussi, celle de bash ne précise pas, mais dans tous les cas, on ne dirait pas qu'il y ait de différence de ce point de vue entre les deux syntaxes.

La lisibilité du code pour une initiation à l'algorithmique, ce n'est pas l'essentiel, ce n'est pas comme s'ils allaient tous devoir maintenir par la suite de vrais programmes. Et puis, ce n'est pas parce qu'il y a des parenthèses qu'il n'auront pas le droit d'indenter. Enfin, je pense plutôt que des séparateurs bien visuels qui donnent la structure du code sont un plus pour les débutants, et puis ça évite une explication sur la différence entre les tabs et les espaces (parce que je ne crois pas qu'au lycée les élèves soient aujourd'hui tous très habiles avec un éditeur de texte).

D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?

Oui. Car on compare des choses qui sont de nature différentes.

En fait moi je me serais attendu à plusieurs choses sauf ça. Soit j'utilise un langage rigoureux comme OCaml et je m'attends à avoir une erreur à la compilation, soit j'utilise un langage typé dynamiquement, et dans ce cas je m'attendrais soit à une exception, soit à obtenir True, mais surtout pas False. Car False ne donne aucune information utile : si ça cache un bug, non seulement on ne s'en rend pas compte immédiatement, mais en plus on obtient un résultat qui probablement est le contraire de ce à quoi on pensait en l'écrivant.

Maintenant lorsque je regarde les autres langages, ces includes sont souvent là (et très nécessaires dès que l'on veut faire quelque chose de sérieux): des "import" de python ou Haskell, aux "use" de Perl en passant par les include de Caml… Dur de s'en passer… Je pense même que des élèves qui auront fièrement fait leurs premières fonctions, vont vite trouver pénible de toujours devoir recopier tout leur code quand ils veulent en faire d'autres… Non ?

Sans doute, je pense que la différence c'est qu'en C tu as besoin d'incantations même pour des choses basiques, alors que d'autres langages permettent de faire de l'algo de base, affichage, etc. avant d'avoir besoin d'utiliser des modules. Franchement, je suis d'accord que ça ne va pas être une barrière insurmontable, mais je vois pas non plus d'argument en faveur d'utiliser C pour apprendre l'algorithmique, vu que le jour où le petit nombre de ces élèves qui deviendra informaticien aura besoin d'apprendre C, ça ne lui changera pas beaucoup de connaître un peu sa syntaxe depuis le lycée, je pense.

Je suis d'accord que mettre en évidence certaines différences et points communs entre fonctions est intéressant. Ceci dit, pour revenir à ta remarque, l'avantage d'écrire (plus 2 3) c'est potentiellement justement que l'élève peut être amené à se poser des questions de commutativité, etc. qu'il ne se posera jamais si c'est écrit de la façon à laquelle il est habitué en cours de maths. Il y a sans doute un intérêt pédagogique aussi à écrire les choses de façon différente à son cours de maths, et donner des exemples qui justifient cela, comme mettre un effet de bord sur un des arguments, et s'apercevoir qu'en fait + n'est pas forcément commutatif dans tous les langages de programmation (ou plutôt, qu'il ne l'est que dans de rares langages).

Et par "quelque magie", j'entendais qu'écrire certaines fonctions avec des syntaxes spéciales peut carrément conduire l'élève à penser qu'il ne s'agit même pas d'une fonction, et ne pas faire le lien avec une fonction "normale".

Si le public visé n'a pas à écrire des tas de formules compliquées mais juste à comprendre le concept de boucle, de variable, etc. pourquoi ne pas leur faire faire du C ?

Je pense que le fait de devoir compiler est une barrière, mais pour le reste, je ne pense pas que ce serait vraiment un problème, à part le fait que j'attendrais d'un langage pour débutant que faire des manipulations sur les chaînes de caractères soit plus simple (comme concaténer facilement, etc.), et préférablement typé dynamiquement.

Il faut être méfiant et ne pas sur-simplifier les choses en prenant le risque d'induire les élèves en erreur et leur compliquer l'apprentissage ensuite.

Dans le cas que tu mentionnes, je ne vois absolument pas en quoi le fait d'utiliser une notation infixe assure à l'élève que l'opérateur définit un groupe abélien : le signe < est tout aussi infixe, et pourtant donne une fonction tout sauf commutative. Et puis, enseigner le détail de propriétés algébriques des fonctions qu'il utilise à un élève, c'est pas vraiment, je pense, ce qu'il attend pour un cours de base sur l'algorithmique. Si c'est pour étudier ce genre de choses, autant passer direct à faire du coq, et démontrer soi-même que + est commutatif :)

Personnellement, je te rejoins sur la syntaxe : si l'objectif c'est juste d'apprendre des principes d'algorithmiques à des parfaits débutants, ils n'auront pas à écrire tout un tas de formules arithmétiques, mais plutôt à comprendre qu'est-ce qu'une boucle, une variable, etc. Donc que les formules ne soient pas écrites de façon pratique n'est pas important. J'irai même jusqu'à dire qu'au lieu d'utiliser des symboles comme < et +, on pourrait tout autant avoir inférieur et plus, histoire que ce soit bien clair que ces fonctions ne diffèrent pas par quelque magie des autres.

Ceci dit, je pense que la syntaxe n'est pas non plus si importante que ça, du moment qu'elle est suffisamment intuitive, de sorte que si l'élève recopie un bout de code et l'adapte un peu, il n'ait pas de mauvaises surprises. Je pense que la façon d'expliquer les algos, etc. va être beaucoup plus importante pour les élèves que le choix d'une syntaxe ou d'une autre.

le « Système » a fait un virage à gauche toute

J'aurais dit plutôt direct vers un cul-de-sac en plein dans l'extrême centre, sans suffisamment de place pour manœuvrer et faire demi-tour. Et de toutes façons, le pire, c'est que je crois que le rétro-viseur est cassé.

Mais tout ça étant dit, je ne vois toujours pas comment on peut être fier d'ignorer quelque chose.

De tirer fierté de son ignorance (truc stupide), à en avoir honte (truc triste), il y a tout un pas.