Le topic de la programmation: Et envoyez des sioux!

[William Vaurien]

Pour avoir parler avec des 'anciens', un de leurs arguments en faveur des grandes méthodes linéaires, c'est que c'est plus facile à 'dérouler', le flux n'est pas séparé en plein de petits fragments. Le programme va de A à B et c'est tout.

Avec des outils plus 'primitifs' - moniteur pas forcément très grand et probablement en noir et blanc (voir en mode teletype pour les plus anciens), IDE limité (oui vi et emacs, ...), sans compter le côté pénible des langages (déclaration des headers, compilation) - finalement ça a du sens de faire au plus simple: la grosse méthode.

Et les mêmes galèrent pas mal avec les concepts objets qu'ils n'ont jamais mis en oeuvre (oui c'était contemporain aux année 90, mais tout le monde n'en utilisait pas à l'époque), sans compter que la diffusion du savoir n'était pas du tout comme maintenant. Le savoir était dans des gros classeurs et des livres dans des étagères, pas dans des blogs dissertant de bonnes pratiques.

Bref, c'est juste pour dire que c'était plus tolérable de faire des tartines et des tartines de code dans la même méthode il y a 30 ans qu'aujourd'hui.

[Max_well]

Et puis c'est beaucoup plus simple à imprimer

[Møgluglu]

Bref, c'est juste pour dire que c'était plus tolérable de faire des tartines et des tartines de code dans la même méthode il y a 30 ans qu'aujourd'hui.

Ouais enfin là on parle des années 1990, pas 1960. Tes collègues ont juste leurs petites manies à eux, et ils trouveront toujours un moyen de se justifier pour ne pas se remettre en question. Qu'ils programment en C en 1990, en Ruby en 2010 ou en Plankalkül en 1940, ce serait pareil.

[Orhin]

Ben quand tu dois bosser sur un code de plusieurs centaines de milliers de ligne principalement écrit par des physiciens....

Perso j'ose pas appeller pas ça du "code".

[William Vaurien]

Ouais enfin là on parle des années 1990, pas 1960. Tes collègues ont juste leurs petites manies à eux, et ils trouveront toujours un moyen de se justifier pour ne pas se remettre en question. Qu'ils programment en C en 1990, en Ruby en 2010 ou en Plankalkül en 1940, ce serait pareil.

J'ai appris à programmer à la fin des années 90 et c'était quand même un peu 'roots', j'ose pas trop imaginer les conditions de travail des informaticiens des année 1980-1990...
Dans l'absolu tu as raisons pour les petites manies, je dis juste que ce genre de manie est plus compréhensible à cette époque. Alors qu'aujourd'hui, physicien ou pas, il n'y a plus vraiment d'excuse pour faire des 'God Class' ou l'équivalent en C.

J'ai eu affaire à pas mal de projets ayant connu plusieurs vies (commencé sur des mainframes puis évolution vers du client lourd puis vers du web (avec généralement une migration au Java avec bien souvent un passage en XML/XSL au début de la phase java, puis Struts ). Chaque techno correspond bien souvent à une époque précise par ex XML/XSL entre 2000 et 2005
Et dans tous ces projets j'ai retrouvé ces méthodes gargantuesques dans les sources ayant le moins évolué.
Ce n'est pas juste un ou deux collègues, j'ai l'impression que c'est un peu générationnel :/

[TiNitro]

Ouais enfin là on parle des années 1990, pas 1960. Tes collègues ont juste leurs petites manies à eux, et ils trouveront toujours un moyen de se justifier pour ne pas se remettre en question. Qu'ils programment en C en 1990, en Ruby en 2010 ou en Plankalkül en 1940, ce serait pareil.

ouais exactement, faut pas déconner.

- - - Mise à jour - - -

..., j'ose pas trop imaginer les conditions de travail des informaticiens des année 1980-1990.../

Ben écoute, franchement, y a des endroits ça allait. Si t'étais un peu "à la pointe" tu avais des outils de travail convenables : gestionnaire de source, éditeurs visuels (genre emacs), langages corrects (C++, Ada).

[ducon]

Ouais enfin là on parle des années 1990, pas 1960. Tes collègues ont juste leurs petites manies à eux, et ils trouveront toujours un moyen de se justifier pour ne pas se remettre en question. Qu'ils programment en C en 1990, en Ruby en 2010 ou en Plankül en 1940, ce serait pareil.

[Orhin]

outils de travail convenables

genre emacs

Bon je trolle, pour l'époque c'est effectivement très bien.

[William Vaurien]

Je sens poindre le débat vi-emacs si cher à nos anciens

[Orhin]

Je sens poindre le débat vi-emacs si cher à nos anciens

IDE Jetbrains > all.
/thread

[Mayalabielle]

Je sens poindre le débat vi-emacs si cher à nos anciens

neovim.

[TiNitro]

Bon je trolle, pour l'époque c'est effectivement très bien.

Ben quand je vois le nombre de mecs qui bossent avec ultra-edit ou notepad++....
C'est juste que 10 ans après c'était pas tellement mieux...

- - - Mise à jour - - -

Je sens poindre le débat vi-emacs si cher à nos anciens

oh nonononono

[Møgluglu]

À ne pas confondre avec le Plan Calcul pour combler le trou de Bull.

[Lazyjoe]

Perso j'ose pas appeller pas ça du "code".

Et pourtant, c'est ça le code du vrai monde qui va tourner sur des supercalculateurs de la nasa à coups de millions d'heures de calcul. Et le vrai monde il va s'acheter un pantalon pour commencer, déjà.

[Tramb]

ouais exactement, faut pas déconner.

- - - Mise à jour - - -


Ben écoute, franchement, y a des endroits ça allait. Si t'étais un peu "à la pointe" tu avais des outils de travail convenables : gestionnaire de source, éditeurs visuels (genre emacs), langages corrects (C++, Ada).

Pour le coup, sur les vcs, faut reconnaître que ça a bien évolué.
J'ai pas connu rcs, mais cvs et sourcesafe, c'était quand même moins cool que ce qu'on a aujourd'hui

Mais sur le reste j'approve à fond.

[Orhin]

Et pourtant, c'est ça le code du vrai monde qui va tourner sur des supercalculateurs de la nasa à coups de millions d'heures de calcul. Et le vrai monde il va s'acheter un pantalon pour commencer, déjà.

Mouais, j'ose espérer que ce code là est un poil plus optimisé et mieux écrit que celui d'un thésard ou d'un physicien lambda derrière lesquels aucun ingé n'est passé.
Et pas besoin de pantalon, on est Dimanche.

J'ai pas connu rcs, mais cvs et sourcesafe, c'était quand même moins cool que ce qu'on a aujourd'hui

T'as quand même malheureusement beaucoup trop de boites qui sont encore sous CVS ou SVN.

Ben quand je vois le nombre de mecs qui bossent avec ultra-edit ou notepad++....

Wait, ça existe encore les gens comme ça ?
Pour faire au chose que du script rapide ?

[Lazyjoe]

Mouais, j'ose espérer que ce code là est un poil plus optimisé et mieux écrit que celui d'un thésard ou d'un physicien lambda derrière lesquels aucun ingé n'est passé.

"Faut optimiser par contre faut pas trop changer et compliquer les choses, les thésards qui débutent en dev doivent pouvoir comprendre et modifier le code facilement".

[Orhin]

"Faut optimiser par contre faut pas trop changer et compliquer les choses, les thésards qui débutent en dev doivent pouvoir comprendre et modifier le code facilement".

Ouais ça je l'ai vu au boulot sur des algo de mecs du CEA.
Après y'avait quand même une certaine latitude pour passer sur du C++ moderne (en partant de vieux Fortran ) et la partie algorithmie était vraiment bien optimisée.

[TiNitro]

Pour le coup, sur les vcs, faut reconnaître que ça a bien évolué.
J'ai pas connu rcs, mais cvs et sourcesafe, c'était quand même moins cool que ce qu'on a aujourd'hui

Oui, je dirais que c'est ce qui a le plus changé au quotidien, à l'époque c'était de l'archivage amélioré.

- - - Mise à jour - - -

T'as quand même malheureusement beaucoup trop de boites qui sont encore sous CVS ou SVN.

Je n'aime pas SVN, mais on l'utilise au taf pour le code Legacy et ça va, il y a pire.

Wait, ça existe encore les gens comme ça ?
Pour faire au chose que du script rapide ?

Ouais ouais, par exemple un très bon pote à moi (qui travaille dans l'embarqué) travaille exclusivement ligne de commande et éditeur... comme moi en 1990... Il faut dire que l'IDE qu'on lui propose est moisi de chez moisi...

[Orhin]

Je n'aime pas SVN, mais on l'utilise au taf pour le code Legacy et ça va, il y a pire.

C'est un bon outil des années 2000 quoi.

Si tu bosses tout seul ça va, mais à plusieurs c'est quand même ultra limitant.

Ouais ouais, par exemple un très bon pote à moi (qui travaille dans l'embarqué) travaille exclusivement ligne de commande et éditeur... comme moi en 1990... Il faut dire que l'IDE qu'on lui propose est moisi de chez moisi...

Il peut pas choisir l'IDE qu'il veut ?

[TiNitro]

Il peut pas choisir l'IDE qu'il veut ?

non compilo spécifique

[Orhin]

non compilo spécifique

Et ?
Il peut toujours utiliser l'IDE de son choix comme un éditeur très avancé et continuer le reste en ligne de commande comme avant (qu'il pourra surement lancer d'un clic depuis l'IDE si il configure correctement le bousin).
Rien que pour le refactoring, le parcours de code, l'autocomplétion avancée et les templates/snippets de code ça vaut largement le coup.

[Lazyjoe]

Et ?
Il peut toujours utiliser l'IDE de son choix comme un éditeur très avancé et continuer le reste en ligne de commande comme avant (qu'il pourra surement lancer d'un clic depuis l'IDE si il configure correctement le bousin).
Rien que pour le refactoring, le parcours de code, l'autocomplétion avancée et les templates/snippets de code ça vaut largement le coup.

Suffit d'être limité par l'environnement. Vi et ligne de commande c'est ce que j'ai droit au quotidien, car il n'y a rien d'autre sur les calculateurs.

Quand j'ai de grosses modifs à faire, je récupère le code sur ma machine et je peux utiliser sublimetext, mais après obligé de recopier à nouveau sur les serveurs pour compiler et tourner.

[vectra]

IDE Jetbrains > all.
/thread

Quand tu peux l'avoir par ton employeur ou l'avoir pour rien, en effet c'est pas mal.
Mais avant de dire du mal d'emacs, il faudrait déjà citer une fonctionnalité qui lui manquerait. Le connaissant bien, je pense qu c'est piégeux comme exercice, et je m'y risquerais pas...

[Møgluglu]

Suffit d'être limité par l'environnement. Vi et ligne de commande c'est ce que j'ai droit au quotidien, car il n'y a rien d'autre sur les calculateurs.

Quand j'ai de grosses modifs à faire, je récupère le code sur ma machine et je peux utiliser sublimetext, mais après obligé de recopier à nouveau sur les serveurs pour compiler et tourner.

Si tu as un accès SSH même indirect à la machine, tu peux monter le répertoire distant et travailler dessus avec ton éditeur préféré en local, non ?

Moi je fais ça pour coder avec Gedit ou Pluma.

[Tramb]

Si tu as un accès SSH même indirect à la machine, tu peux monter le répertoire distant et travailler dessus avec ton éditeur préféré en local, non ?

Moi je fais ça pour coder avec Gedit ou Pluma.

T'as jamais de soucis de timestamp ou autres avec tes process de builds ?
Je sais que j'ai déjà souffert avec samba.

[Møgluglu]

J'ai déjà eu ce problème, mais pas récemment. Ça devait être avec Samba aussi, par SFTP ça semble mieux se passer. Par contre je n'ai aucun retour quand un fichier que j'ai ouvert est modifié à l'autre bout (genre par un git pull), donc faut faire un minimum gaffe.

[Orhin]

Suffit d'être limité par l'environnement. Vi et ligne de commande c'est ce que j'ai droit au quotidien, car il n'y a rien d'autre sur les calculateurs.

Quand j'ai de grosses modifs à faire, je récupère le code sur ma machine et je peux utiliser sublimetext, mais après obligé de recopier à nouveau sur les serveurs pour compiler et tourner.

Mon petit cœur baigné à l'intégration continue a mal en lisant tout ça.

Quand tu peux l'avoir par ton employeur ou l'avoir pour rien, en effet c'est pas mal.
Mais avant de dire du mal d'emacs, il faudrait déjà citer une fonctionnalité qui lui manquerait. Le connaissant bien, je pense qu c'est piégeux comme exercice, et je m'y risquerais pas...

Test : est-ce que lorsque tu fais du refactoring sur les fichier (déplacement/renommage/etc) emacs va automatiquement modifier les paths des imports (aussi bien au sein du fichier que dans ceux qui l'importent) ?
Après, ça fait surement quasiment tout, sauf que la dernière fois que j'ai pu l'utiliser (ou voir quelqu'un l'utiliser, mon colloc' thésard ne jurant que par ça) je l'ai trouvé totalement anti ergonomique et user-friendly.

Quand tu peux l'avoir par ton employeur ou l'avoir pour rien, en effet c'est pas mal.

Vu le coup relativement faible de la licence (surtout si tu veux juste un des produits genre Webstorm) :
- ton employeur est con si il ne veut pas la payer (comparé au cout de ton salaire c'est peanut) ;
- si t'es indépendant, c'est toi ton employeur.

[William Vaurien]

En ce qui concerne VI et consort, il y a sûrement moyen d'obtenir un truc quasi équivalent à un IDE moderne, mais l'effort nécessaire pour avoir ne serait-ce que le minimum vitale ne me parait pas vraiment en valoir le coup.
Et pour ceux qui ne jurent que par les raccourcis claviers ('si si regarde pour effacer 23 lignes je tape 23 d c'est super rapide !!!') il y a même des plugins exprès dans les IDE jetbrains.

Pour en revenir sur la différence d'esprit et de vision sur la programmation en général, je me rappel que pendant mes études (IUT puis DESS de 1998-2003) , aucun prof ne nous a parlé de qualité de code, de bonnes pratiques ou de tests unitaires. Le manifeste agile circulait dans la classe pendant mes dernières années de fac, mais j'avais pas vraiment compris de quoi il s'agissait...
Si certains profs insistaient sur le découpage en petits blocs, beaucoup d'autres voulaient de la "bonne grosse méthode qui fait tout". Je m'étais pris plusieurs fois des réflexions à ce sujet.
Je ne savais même pas ce qu'était un gestionnaire de version en sortant de la fac, et le seul prof qui nous a montré un IDE était un intervenant externe qui nous a sorti Eclipse. Et en 2003 c'était déjà tout pourri Eclipse, j'avais déjà découvert Intellij !

Et faire du refactoring avec nedit (époque IUT) ou autre éditeur de texte basique, ou même un vi / emacs bien maîtrisé c'est pénible et dangereux comme renommer une fonction ou en changer les paramètres ! Naviguer dans le code aussi !
La - fausse - solution: garder les choses le plus simples possible et éviter la 'prolifération' des petites méthodes...

Du coup je me suis pris un grosse claque lors de mon premier job, et j'ai bien apprécié des outils comme 'checkstyle' qui valorisait la brièveté (un peu trop parfois !) avec des warnings dès qu'une méthode fait plus de 20 lignes ou quand la complexité (nombre d'instruction de contrôle/boucle) est trop forte.

[Lazyjoe]

Mon petit cœur baigné à l'intégration continue a mal en lisant tout ça.

Dans le fond c'est un monde que j'aimerais bien découvrir quand même un jour. Par curiosité.

Les tests de non-régression en calcul scientifique c'est assez goleri. Ca donne un mail général du physicien en chef du code : "La nouvelle version est en validation. Merci à tous les téhsards de faire tourner leur simulations dessus et comparer les résultats avec l'ancienne version." A la sortie, si chez tout le monde ça tourne sans planter, qu'on a pas de paquets de 0 et infini qui traînent dans les résultats et que les courbes ont à peu près la même forme, on valide la nouvelle version.