Et mes 150 lignes de Ruby contre tes 4000 lignes de Fortran ont un avantage certain
Fortran peut être employé de deux manières extrêmes. La première est de faire du scripting comme du temps des cartes perforées où l'on met le juste nécessaire pour faire un job, la seconde est coder dans un style plus verbeux et avec la gestion des incidents.
Au niveau de la verbosité, les deux exemples suivants sont rigoureusement identiques au niveau du processeur Fortran :
Version coding style 'scripting'
write(*,'(a)')"Hello World!"
Version coding style 'joli code'
write(&unit=*&fmt='(a)'&)"Hello World !"`
Je suis passé d'une ligne de code à quatre pour rigoureusement le même code ! Et tout mon projet est codé dans ce second style afin de le rendre lisible pour le plus grand nombre de personnes (à commencer par moi !). Mais on pourrait en dire autant pour le langage C ou les feuilles CSS. D'un autre côté, le codage en mode verbeux permet de réduire considérablement le montant des commentaires explicatifs.
Il y a aussi la gestion des incidents qui augmente le nombre de lignes de code de mon projet. En effet Fortran, comme bien des langages, peut gérer de façon facultative les incidents inopinés comme l'échec d'ouverture de fichier ou l'allocation dynamique de mémoire qui échoue. Si l'on code un script dont on est le seul utilisateur, on ne s'embêtera pas à à prévoir ces cas là. Mais, pour mon projet, j'ai pris en compte beaucoup (mais pas tous) des incidents possibles. Rien ça peut quadrupler le nombre de lignes du code.
Contrairement à un script j'ai implémenté sur fBlog, outre une interface utilisateur à la ligne de commande, une seconde interface utilisateur pour la console. Et ce, sans recourir à une bibliothèque externe. Ça fait beaucoup de lignes de code (et bien des tracas) !
Pour faciliter la vie de l'utilisateur lors de l'installation du logiciel, je l'ai créé en un seul tenant de façon à éviter l'emploi de makefile. Ainsi la feuille de style standard qui aurait dû, selon les standards du génie logiciel, être un fichier externe au lieu de la mettre dans une constante. Ça fait des centaines de lignes de code en plus au compteur de fBlog !
Enfin, selon que l'on code tout "from scratch" ou avec des bibliothèques, forcément le nombre de lignes du projet ne sera pas le même. Et si Fortran peut agir avec presque toutes les bibliothèques écrites en C il peut aussi agir à la ligne de commande. Pour fBlog, je n'ai pas employé de bibliothèque externe (j'aurai pu faire une interface utilisateur en ncurses au lieu de celle que j'ai codé à la main) mais il utilise des commandes Posix externe comme ls, rm, stty... Si j'avais voulu me passer de ces commandes, le nombre de lignes du projet aurait franchement explosé. Et ma tête aussi.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard . En réponse à la dépêche Moteur de blog fBlog. Évalué à 2. Dernière modification le 17 mars 2015 à 13:09.
Fortran peut être employé de deux manières extrêmes. La première est de faire du scripting comme du temps des cartes perforées où l'on met le juste nécessaire pour faire un job, la seconde est coder dans un style plus verbeux et avec la gestion des incidents.
Au niveau de la verbosité, les deux exemples suivants sont rigoureusement identiques au niveau du processeur Fortran :
Je suis passé d'une ligne de code à quatre pour rigoureusement le même code ! Et tout mon projet est codé dans ce second style afin de le rendre lisible pour le plus grand nombre de personnes (à commencer par moi !). Mais on pourrait en dire autant pour le langage C ou les feuilles CSS. D'un autre côté, le codage en mode verbeux permet de réduire considérablement le montant des commentaires explicatifs.
Il y a aussi la gestion des incidents qui augmente le nombre de lignes de code de mon projet. En effet Fortran, comme bien des langages, peut gérer de façon facultative les incidents inopinés comme l'échec d'ouverture de fichier ou l'allocation dynamique de mémoire qui échoue. Si l'on code un script dont on est le seul utilisateur, on ne s'embêtera pas à à prévoir ces cas là. Mais, pour mon projet, j'ai pris en compte beaucoup (mais pas tous) des incidents possibles. Rien ça peut quadrupler le nombre de lignes du code.
Contrairement à un script j'ai implémenté sur fBlog, outre une interface utilisateur à la ligne de commande, une seconde interface utilisateur pour la console. Et ce, sans recourir à une bibliothèque externe. Ça fait beaucoup de lignes de code (et bien des tracas) !
Pour faciliter la vie de l'utilisateur lors de l'installation du logiciel, je l'ai créé en un seul tenant de façon à éviter l'emploi de makefile. Ainsi la feuille de style standard qui aurait dû, selon les standards du génie logiciel, être un fichier externe au lieu de la mettre dans une constante. Ça fait des centaines de lignes de code en plus au compteur de fBlog !
Enfin, selon que l'on code tout "from scratch" ou avec des bibliothèques, forcément le nombre de lignes du projet ne sera pas le même. Et si Fortran peut agir avec presque toutes les bibliothèques écrites en C il peut aussi agir à la ligne de commande. Pour fBlog, je n'ai pas employé de bibliothèque externe (j'aurai pu faire une interface utilisateur en ncurses au lieu de celle que j'ai codé à la main) mais il utilise des commandes Posix externe comme ls, rm, stty... Si j'avais voulu me passer de ces commandes, le nombre de lignes du projet aurait franchement explosé. Et ma tête aussi.