Amis lecteurs, vous avez été nombreux à répondre au sondage que j’avais initié sur les pages perso. J’avais un projet de moteur de page perso / blog minimaliste en cours depuis des années et vos réponses m’ont donné un nouvel élan.
fBlog est un moteur de blog utilisable par toute personne ayant déjà mis en ligne ses pages Web et possédant des notions de HTML et CSS. Il est publié sous licence GPLv3 et codé en Fortran. Son interface utilisateur est soit la ligne de commande classique, soit un mode interactif à la console d'un genre nouveau. Contrairement à la plupart des autres logiciels de ce genre, fBlog est un binaire exécutable. Il est sans dépendance à la compilation, mais à l’exécution il requiert quelques commandes externes Posix et un quelconque éditeur de texte. Il s’installe aisément en suivant les instructions sur la console et il est immédiatement fonctionnel sur tout système Linux de base.
Sommaire
Version courte
fBlog n’est basé sur aucun framework et les pages générées ont toutes à peu près le même source HTML. La personnalisation du HTML des pages est faite par un fichier de configuration où l’on défini le titre, l’introduction, le pied de page, etc. L’aspect des pages générées est entièrement fondé sur la feuille de style externe (qui n’est même pas obligatoire).
fBlog est minimaliste et ne supporte ni les commentaires (ça a permis d’éviter JavaScript et *SQL), ni les catégories. Les billets sont des fichiers texte individuels où le nom de fichier est la date et l’heure de création, le premier enregistrement est le titre et le restant le corps du texte rédigé en HTML (Markdown non supporté).
fBlog est en libre téléchargement depuis SourceForge. Il y a un binaire pour les PC mais il est vraiment facile de le compiler en suivant les instructions. La seule chose dont vous ayez besoin est le compilateur GCC (pas plus vieux que la version 4.7.3) avec l’option gFortran.
Concernant la discussion hébergement à domicile vs hébergement pro vous pouvez tester mes pages en changeant le TLD de « .com » en « .fr ». Tout ce qui est sous le TLD « .com » est chez moi sous modem ADSLv1 alors que ce qui est sous le TLD « .fr » est un miroir chez un hébergeur bien connu.
Version longue
Au commencement était NanoBlogger
Au commencement, c’était une histoire de bateau ! En 2006, je mettais en chantier une coque de voilier pour faire un tour du monde et j’éprouvais le besoin de bloguer sur cette aventure. Aujourd’hui le voilier n’est pas tout à fait terminé, contrairement à ce que j’avais planifié. Mais ça, c’est une autre histoire.
Donc, en 2006, je prospectais ce qui existait en matière de logiciels de blog. (Je n’étais pas totalement novice car j’avais déjà mis en place le site Web d’une association, composé de pages statiques, écrites à la main, hébergées sur le compte Free d’un adhérent.) Le logiciel devait répondre à des besoins très précis en matière d’administration : je devais pouvoir tout faire à distance, depuis un cybercafé doté d’une connexion pourrie. Dans le contexte de l’époque, c’était du Telnet avec Putty sous Windows. Le moteur de blog devait être administrable à la ligne de commande. J’ai donc choisi NB (NanoBlogger) que j’ai adoré au point de m’impliquer dans sa traduction et de fédérer quelques utilisateurs francophones.
Mais NB était d'une horripilante lenteur lorsque il atteignait une centaine de billets. (C’est beaucoup moins vrai avec la puissance des machines d'aujourd'hui ; et il y a encore des fidèles qui ont maintenant des centaines de billets.) Donc, juste pour cette question de lenteur, je me suis résolu à écrire mon propre logiciel. Le seul moyen que je voyais était de le programmer plutôt que de le scripter. J’avais pris conscience de la dépendance aux langages interprétés qui oblige à intervenir souvent sur le code lors des nouvelles versions du langages (Bash pour NB).
Puis vient la programmation
Concernant le choix du langage capable de générer un binaire, la liste était très courte : il n’y avait pas de Basic (à l’époque) pour Linux ; restait le langage C, Ada et Fortran. Le langage C j’oubliais vite, car j’étais un marin pas un informaticien professionnel. Ada me tentait assez, mais Fortran m’a paru plus évident car je m’y était déjà un peu essayé en guise de remplacement du Basic anciennement pratiqué avec MS-DOS. En 2009, j’ai commencé mes premiers pas en programmation Fortran et ça n’a pas été facile.
Ce langage a connu de si profonds changements que les quelques rudiments que j’avais pu assimiler quelques années avant se sont avérés insuffisants. Pour faire bref, la glorieuse époque de Fortran est celle de la version F77 ; laquelle faisait à peu près tout ce que l’on peut faire avec du scripting Bash mais en infiniment plus vite. F77 ne connaissait pas encore les pointeurs, les allocations dynamiques et bien évidement pas les modules et autres facilités du génie logiciel moderne. Il a fallu me mettre à jour et ingurgiter des savoirs avec une maigre documentation et absolument aucun exemple à me mettre sous les yeux autres que ceux illustrant la norme. Et aujourd’hui encore je n’ai pas connaissance d’un source Fortran qui ne soit pas le replâtrage d’un vieux soft écrit en F77 ou F90. Et je ne connais aucun logiciel écrit en Fortran pour faire autre chose que du calcul intensif !
J’ai choisi gfortran qui vient avec GCC et qui profite de la même infrastructure que le langage C. À ce moment là, gfortran couvrait la totalité de la norme 77, la quasi totalité de F90 et F95 et introduisait F2003. Aujourd’hui gfortran commence à introduire la norme F2015 (à partir de GCC-5.0) mais ne couvre pas encore la totalité de F2003 et F2008. Depuis 2009, j’ai eu l’occasion de tester les nouveautés de ce langage et elles ont été nombreuses et intéressantes !
Je dois dire que l’abondance de ces nouveautés logicielles m’a fait perdre beaucoup de temps ! Si j’en étais resté au Fortran 77, je n’aurais eu qu’à faire une traduction du script Bash qu’est NanoBlogger et la messe aurait été dite depuis longtemps. Mais là je me suis trouvé devant plein d’options différentes et je me suis livré à de longs errements. Du genre, module ou pas module ? Et si module, procédures dedans ou seulement des variables communes ? Variables globales à tout le programme ou panachage avec des variables mises en modules ?
Suivie de la question du style
Un autre point aussi qui m’a pesé : le « coding style ». Si l’on peut à la rigueur écrire un source F90 à la manière de F77, avec les dernières normes ce n’est plus envisageable : à cause de la longueur des noms des nouvelles procédures intrinsèques et leur cortège d’options. Je me suis donc créé mon propre style, un peu à la manière du langage C. Il y avait aussi le choix de rester dans la concision du style F77 ou de passer à la verbosité dorénavant permise par la norme. J’ai fait le choix de la verbosité car je me suis aperçu que c’était plus facile pour me relire plus tard. C’est vraiment là que l’on souffre de ne pas pouvoir lire du code récent écrit par d’autres. Comme je ne me suis pas stabilisé immédiatement en style, j’ai eu à réécrire plusieurs fois l’intégralité du code.
En dehors du langage de programmation, j’ai eu à faire d’autres choix qui auraient de toute façon été à faire quel que soit le langage choisi et qui concernent l’ossature du moteur de blog. Le tout premier était de choisir entre une base de donnée interne ou externe. Le choix fut rapide et le même que pour NanoBlogger : pas de base de données externe à la SQL mais des billets saisis sur un fichier plat individuel. Chaque fichier prend pour nom la date et l’heure de création et il est facile d’en faire le tri avec la commande externe « ls ». La création ou modification ultérieure d’un fichier se résume à y faire intervenir un éditeur de texte externe. Comme Fortran peut utiliser la ligne de commande, je pouvais faire comme si je scriptais en Bash.
Puis arrivent internalisation et régionalisation
Le second choix, plus difficile, fut la question linguistique. Devais-je rédiger en français, en anglais ? Devais-je rendre le logiciel facilement adaptable dans une autre langue, le proposer à la fois en français et en anglais ? Dès le départ j’avais dans l’idée de faire un vrai projet, donc l’anglais s’imposait. Je me suis posé la question pendant plusieurs années. Vraiment. Aujourd’hui, j’ai le parti pris de l’anglais comme langue unique mais j’ai fait en sorte que tout se tienne dans le même module de façon à ce qu’un traducteur éventuel puisse ne pas trop souffrir. De toute façon, l’utilisateur de ce genre de logiciel en ligne de commande doit maîtriser un peu l’anglais. Et la base d’utilisateur est très faible au vu du nombre des usagers de NanoBlogger. Se limiter à la sphère française, serait coder pour une poignée d’individus.
Ainsi que l'interface d'administration
Je voulais aussi expérimenter une autre interface utilisateur que la seule ligne de commande mais qui soit compatible avec une session Telnet/ssh. Je ne voulais pas me perdre avec une interface à fenêtres avec ncurses (et surtout pas à jouer avec la programmation mixte !). J’ai donc créé une interface d'un genre nouveau qui fait absolument tout ce que la ligne de commande faisait déjà, un peu comme avec ncurses au niveau des touches à action instantanée (dit-on « hot key » ?) mais en mode ligne plutôt qu'en page écran.
Ceci a eu pour effet d’introduire des tas de bugs qui n’avaient pas de raison d’apparaître à la seule ligne de commande qui fait un traitement linéaire. Autant dire que le seul ajout de cette nouvelle interface utilisateur m’a obligé à réécrire quasi entièrement un code déjà parfaitement fonctionnel à la seule ligne de commande ! Mais bon, maintenant ça marche et c’est joli.
Et l'interface fournie aux lecteurs
Un autre choix drastique a concerné la partie HTML, CSS et JavaScript. Je n’ai pas voulu m’embêter avec JavaScript (que je n’ai jamais pratiqué) car avec NanoBlogger on arrivait bien à s’en passer. De plus il n’y a pas le support des commentaires qui l’aurait rendu nécessaire. Reste que HTML venait de passer à la version 5 (bang, encore un apprentissage) et que CSS montait aussi à la version 3 (re-bang !). De tous les mois que j’ai pu consacrer à ce projet, je crois que la seule partie concernant les CSS m’a pris la moitié du temps. Contrairement au codage en Fortran, c’est pas fatiguant mais c’est long ! Encore une fois, j’ai pris une option de codage risquée mais qui semble prometteuse.
Avec l'inflation du vocabulaire en HTML 5 il est devenu plus facile d’amarrer du style à toutes ces balises. Au point que j’ai pensé supprimer les balises DIV et faire appel aux pseudo classes en CSS. Ça a marché. Alors j’ai supprimé aussi les balises SPAN par la même occasion ! Encore une fois, ça a marché. Puis ce fut le défi imposé par la dernière mode, les feuilles de style « responsives ». Quelques dizaines d’heures encore plus tard… Ouf !
Au final, le moyen que j’ai trouvé pour réussir le couplage HTML – CSS, ce fut de me concentrer sur le seul HTML et de ne faire les CSS qu’ensuite. Aujourd’hui, on a la chance que les navigateurs traitent grosso modo le style par défaut de la même manière. (Comme si, par exemple, votre feuille CSS ne contenait aucun code.) Donc si le code HTML affiché par défaut dans le navigateur suffit à la bonne compréhension du blog, le fichier CSS est juste du bonus. Et le site est compatible pour les navigateurs en mode texte.
Enfin un moteur pour mes besoins initiaux
J’arrive maintenant au bout de la première étape que je m’étais fixée, celle d’un moteur de blog qui convienne à mes besoins initiaux. Mais comme j’ai déjà bien d’autres envies, il y aura de nouvelles fonctionnalités dans les versions futures de fBlog. Et ce, jusqu’à la version 1.0. Ensuite, ça ne sera plus que de la maintenance. Le code HTML généré depuis la version présente jusqu’à la future version stable 1.0 ne devrait plus beaucoup bouger. Une feuille de style personnalisée par vos soins aujourd’hui devrait pouvoir supporter les mises à jour sans trop de souci.
Exemples de blogs générés par fBlog :
- blog du site officiel (style conçu pour se rapprocher de celui de SourceForge) ;
- mon blog principal (style non modifié livré avec fBlog) portant surtout sur le cinéma ;
- photo blog ;
- cargo (style non modifié livré avec fBlog), un blog rétrospectif sur mon ancienne carrière de marin au long cours ;
- le blog sur mon voilier (celui qui est à l'origine de cette aventure !) ;
- code de nuit (style ordinausaure), divagations sur l'informatique.
Aller plus loin
- Journal à l'origine de la dépêche (72 clics)
- Dépôt sur Sourceforge (90 clics)
- Blog de démo (style fBlog standard) (492 clics)
# Oui, mais c'est pas forcément le bon outil
Posté par let antibarbie = xp <- xp - 1 . Évalué à 3.
C'est bien, mais on peut sûrement qualifier ce logiciel de joli "hack", car il faut bien admettre que la "force" du Fortran c'est le calcul numérique et l'héritage ancestral des métiers qui utilisent ce type de calculs et les librairies "métier" qui vont avec.
Alors pour faire un parallèle marin, super je peux arriver à faire une traversée avec un vieille voile trop grande, on peut admirer la prouesse d'être surtoilé et d'arriver à naviguer sans se renverser, mais c'est pas pour autant que mon gréement est agréable à manipuler (!)
Bref c'était juste pour dire qu'une bonne partie de l’ingénierie logicielle consiste à choisir le bon outil pour effectuer le bon travail.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 10. Dernière modification le 14 mars 2015 à 21:38.
Désolé de vous contredire ! Le langage Fortran (historiquement le plus ancien des langages de programmation) a été inventé à une époque où les programmes tournaient sous hyperviseur et non pas sous système d'exploitation (pas encore inventé). Ceci a fait que Fortran, dès ses débuts, devait gérer lui-même les lectures-écritures des fichiers en mémoire vive et aussi les entrées-sorties sur les périphériques. Par exemple, Fortran a toujours connu le principe des fichiers temporaires en mode virtuel (fichiers scratch). Et Fortran peut agir sur les fichiers de façon à se créer des bases de données sans recourir à un logiciel externe.
Oui, La part de calcul pour un moteur de blog est minuscule. Par contre la gestion des fichiers est d'une toute autre ampleur ! Faite le calcul du nombre de pages générées pour un blog qui serait tenu par un blogueur qui posterait au même rythme qu'un Bortzmeyer à la fin de sa vie ? J'ai fait un test en convertissant le blog (sous Wordpress) du très fameux Eric S. Raymond pour voir si fBlog tenait la charge…
Que Fortran ait été créé pour faire du calcul intensif est une évidence. Mais ledit calcul intensif suppose de brasser des tonnes de données. Or un blog, qu'il soit statique ou qu'il soit dynamique, doit brasser des tonnes de données. Si l'on a pas le bon langage de programmation pour le faire, on est obliger de sous-traiter la chose par une base de données externe *SQL (ce qui résoudra la question des lectures-écritures des données mais pas celle les entrées-sorties sur les mémoires de masse).
Est-il nécessaire de rappeler que Fortran est presque entièrement interopérable avec C/C++ (donc la libc !) de nos jours ?
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 7.
Faut avoir beaucoup de choses à raconter pour qualifier un blog de "tonnes de données". Il s'agit essentiellement d'IO de quelques centaines (soyons fous, milliers) de fichiers de quelques Ko, il n'y a pas de quoi mettre à genoux une machine.
Certes, on sait que les disques durs standards sont pas super à l'aise sur les IO de petits fichiers, mais ce n'est pas le langage du moteur du blog qui va y changer grand chose : une IO reste une IO. C'est plus de l'ordre d'une bonne stratégie concernant la gestion de ces fichiers (afin de ne traiter que le nécessaire).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 3.
J’ai dimensionné fBlog sur la base d’un blogueur hypothétique qui posterait un billet par jour sur 50 ans. Si l’on multiplie 365 jours X 50 ans, ça fait déjà 18250 permaliens. Comme on a aussi une page d’indexation des billets chaque mois, ça fait 12 mois X 50 ans soit 600 pages. À cela l'on ajoute la page d’accueil plus la page d’archive récapitulative soit 2 pages. Au total : 18250 + 600 + 2 = 18852 pages Web à générer. Mes tests sur un vieil ordinateur me donnent moins de une minute de traitement avec fBlog.
Dans la pratique, il peut se passer deux choses : soit le blogueur poste 2 billets par mois et fBlog est surdimensionné, soit il prend six photos par jours qu’il poste à chaque fois sur son blog et là fBlog tiendra la charge seulement quelques années (alors il faudra bien me remettre au code et étudier la parallélisation des tâches qui est l’un des dadas du langage Fortran).
Les chiffres que je donne sont à considérer avec ceux des utilisateurs de Facebook : ils sont plus ou moins bavards (et aussi plutôt « texte écrit » ou plutôt « images »).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 2.
Certes, mais tu n'as pas besoin de tout régénérer à chaque fois que tu postes un article, si ?
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 6.
Si. Et j’ai fait exprès, en plus !
Il y a deux bonnes raisons raisons à vouloir réécrire 100% des fichiers lorsque l’on poste un article. La première est technique (la facilité de maintenance du logiciel), la seconde est d’ordre humain (un logiciel ne doit pas nuire).
Fblog est issu de ma seule expérience d’avec NanoBlogger (je n’avais jamais blogué auparavant). NanoBlogger a l’option de rafraîchissement qui permet une mise à jour partielle du blog en cas d’ajout d’un billet (ou de sa modification) et une autre de reconstruction totale. Je pense que d’autres moteurs de blog statique ont eux aussi ces deux options (mais en fait, je n’en sais rien…). Les utilisateurs de NanoBlogger ont rapportés de nombreux bogues car ils se contentaient de faire une mise à jour partielle plutôt qu’une mise à jour intégrale lors de certaines circonstances. Le vrai problème pour le programmeur est de décider où doit se situer le curseur entre le partiel et l’intégral. Et le problème pour l’utilisateur est de savoir ce qu’en pense le programmeur. En plus, du point de vue du code, c’est une sacré complication que d’implémenter et faire coexister les routines des mises à jour partielles et intégrales.
J’ai longtemps hésité sur l’utilité d’une mise à jour partielle. Mais quand j’ai vu que la technologie des machines d’aujourd’hui permettait de générer des milliers de fichiers en quelques secondes, d’un point de vue pragmatique, j’ai décidé que c’était un tracas inutile que d’implémenter l’option de rafraîchissement. L’autre raison est bien plus cruciale : un logiciel ne doit pas nuire à son utilisateur.
Un blog est une chose amusante à tenir, sinon en en tiendrait pas, hein ? Sauf que sur Internet, comme dans la vraie vie, « si les paroles s’envolent, les écrits restent ». Il peut arriver que l’on ait à supprimer un ancien billet devenu compromettant. Dans ce cas, l’option de rafraîchissement du blog devra-t-il en tenir compte ou pas ? C’est le choix du programmeur et uniquement lui. Et encore heureux s’il ne change pas d’avis entre deux versions ! Il y a aussi, dans le cas d’une option de rafraîchissement, la possibilité de dé-indexer le billet mais sans le supprimer du système de fichier. Tout est possible, c’est le programmeur qui décide ! Reste qu’à ce moment là, si le billet compromettant a été mis en marque-page quelque part, il sera toujours lisible sur Internet même si son lien au sein du blog a été supprimé.
Il y a aussi une chose encore plus pernicieuse concernant la suppression d’un billet de blog : celle que cette action entraîne un aveu de culpabilité. En effet, si quelqu’un demande et obtient la suppression d’un billet offensant, il jubile. Encore faut-il qu’il puisse apporter la preuve que sa réclamation ait été couronnée de succès ! En effet, pour des facilités de modification / suppression d’un billet de blog statique, il semble évident d’attribuer un identifiant à chaque billet. Ce pourrait être la date et l’heure mais c’est pas pratique à saisir. Donc, j’ai choisi un identifiant numérique. Mais si j’attribue un identifiant numérique fixe qui s’incrémente au fur et à mesure que le blog grossi , la suppression d’un billet sera visible car il y aura un trou dans l’ordre des identifiants. C’est pourquoi fBlog renumérote absolument tous les billets que l’on en ajoute ou que l’on en supprime. Et pour couronner le tout, j’ai choisi de mettre le numéro le plus faible pour le plus récent des billets (numéro 1) et le numéro le plus fort pour le billet le plus ancien (numéro égal au total des billets du blog). Ainsi, en ouvrant la page d’accueil du blog, on ne peut pas deviner si un billet a été supprimé suite à un contentieux.
Le seul fait de renuméroter tous les billets du blog entraîne une mise à jour intégrale. Fblog, pour ces raisons de sûreté de la vie privée, détruit l’intégralité des données résidant dans le sous-répertoire « fBlog/export_html » avant de procéder à la mise à jour. Ceci évite donc d’y voir résider un billet que l’on pensait avoir supprimer de bonne fois. Cependant, si l’utilisateur se contente d’uploader les fichiers de ce sous-répertoire vers son serveur Web (au lieu de faire une vraie synchronisation !), le billet qu’il croyait avoir supprimé sera toujours visible sur Internet. Mais ça, ce n’est plus de ma responsabilité d’auteur !
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 1.
Ton argumentaire sur la jubilation potentielle de quelqu'un qui aurait demandé la suppression d'un article ne tient pas la rout. Chaque article est identifié uniquement par un permalien, qui est sa date de création. Le principe du permalien, c'est d'avoir un lien permanent, et ce lien, le mec en question, il le connait. Il verra donc que cet article n'est plus disponible, et l'identifiant numérique que tu associes à chaque article n'y change rien.
En plus, cet identifiant te simplifie uniquement la vie pour faire des
--edit-post=XXXou--delete-post=XXX, mais oblige à réécrire l'ensemble des pages à chaque ajout ou suppression d'un article, uniquement pour passer cet identifiant de N à N+1 ou N-1. Je te conseille d'utiliser la date, qui te sert déjà de permalien. Certes, ça t'obligera à taper 14 caractères plutôt que 3 ou 4 pour les commandes précitées, mais ça va t'éviter de regénérer chaque page à chaque ajout ou suppression d'un article : tu as juste à regénérer la page suivante et la page précédente afin de mette à jour les liens "page suivante" et "page précédente" (enfin, si ces pages existent). Quant aux pages d'archives, tu dois juste mettre à jour la page du mois concerné par l'article ajouté/supprimé, ainsi que la page d'archive générale. Ce qui nous donne un maximum de 5 fichiers à écrire (article ajouté, article précédent, article suivant, page d'archive du mois concerné, page d'archive générale).Certes, il y a des action qui continuent de nécessiter une regénération de l'ensemble des pages (ajout ou suppression d'une page statique, changement éventuel du template contenu dans le binaire). Mais dans ce cas, je te suggère d'ajouter une commande
--update-allqui se chargera de cette lourde tâche, mais uniquement lorsque cela sera nécessaire.Alors oui, cela va complexifier un peu le code du moteur, mais pour des raisons évidentes de performances, ou encore de facilité de débuggage, je pense que cela sera bénéfique.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 4.
Honnêtement, qui est capable de copier 14 caractères de mémoire ? Certes on peut toujours utiliser la souris pour faire un copier-coller… Non, définitivement non, un identifiant basé sur la date et l'heure ça ne le fait pas pour les humains.
Concernant le principe du rafraîchissement partiel du blog et de sa reconstruction totale de temps à autre : ma réponse précédente me semblait claire. Relis-la ! J'ajoute que je l'avais implémenté au début dans mon propre projet. Je sais faire ! Et quand je dis que prends à cœur les loupés que l'utilisateur pourrait commettre en cas de rafraîchissement partiel de son blog au lieu d'une totale reconstruction, c'est sincère et basé sur mon expérience de la communauté des utilisateurs francophones de NanoBlogger. Je privilégie la sécurité des données au détriment de la performance.
J'ajoute aussi que tenir un blog n'est pas une chose anodine : il ne se passe pas une semaine en France (ou ailleurs) sans qu'un scandale éclate à la seule vue d'une phrase scabreuse écrite à la va-vite dans un post ou la photographie d'une soirée arrosée entre copains où l'on est vu déguisé d'une manière inapproprié ou en tenue d'Adan. Pouvoir éliminer le billet compromettant à coup sûr alors, que l'on en proie à une émotion vive due à un entourage très colère ou encore dans les vapeurs d'alcool de la soirée de la veille, me semble une chose importante.
De tout ce qui précède je maintiendrai ma position en matière d'ergonomie et de sûreté des données. Ceci étant, fBlog est sous GPL, chacun est libre de le forker. Et les connaisseurs du langage Fortran pourront témoigner, j'en suis sûr, que j'ai pris soin à ne pas offusquer le code ni à le rendre abscons (c'est si facile avec Fortran !).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 1.
Je ne remets pas cause ta capacité à écrire du Fortran, je dis juste qu'il y a une faille dans ta logique, et qu'en faisant les choses légèrement différemment, tu pourrais alléger certains traitements. Mes suggestions vont dans ce sens et, je pense, n'altèrent en rien les fonctionnalités que tu souhaites avoir. En particulier, je ne vois pas en quoi cela mettrait à mal la sécurité, pourquoi un rafraîchissement partiel serait plus propice à des "loupés", ou pourquoi cela nuirait à la capacité à pouvoir éliminer à coup sûr un article compromettant.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 2.
Si l'on se place dans le cadre d'une mise à jour partielle d'un blog, l'on n'aura que peu de fichiers à transférer vers le répertoire du serveur (environ 2 ou 3). Et d'une manière générale, toute modification sera systématiquement l'ajout ou la modification d'un billet existant. Dans ce cas, au fur et à mesure que le blog grossi, on pourra faire ce transfert manuellement soit en copiant en vrac la totalité des fichiers si le répertoire du serveur est sur la même machine que le moteur de blog soit en les transférant vers le répertoire de l'hébergeur. Il y a deux possibilités alors : rsync ou ftp. Mais certains hébergements n'ont que ftp. Alors il semble évident de ne transférer que la poignée de fichiers modifiés. C'est absolument sans inconvénient tant que l'on ajoute ou que l'on modifie un billet.
Comme la routine de la mise à jour du blog devient une seconde nature, lors du cas exceptionnel d'une suppression de billet, s'il agit comme d'habitude l'utilisateur peut oublier d'enlever le billet incriminé résidant sur le répertoire du serveur. Ou se tromper dans la suppression du fichier car mon système de nommage n'est absolument pas fait pour les humains (une suite de chiffres).
En ne conservant qu'une seule procédure de mise à jour, la procédure de transfert sera la même qu'elle que soit le nombre de billets ajoutés ou supprimés. Et les fichiers auront tous la même date ce qui rend encore plus délicat de savoir ceux qui ont été réellement modifiés ou pas. Le plus simple sera donc de procéder par wagon entier pour les transferts. (Par exemple, mon hébergeur conseille d'uploader une tarball plutôt que les fichiers individuellement.) Dans ce cas, on videra le répertoire du serveur et l'on y éclatera une tarball. Ce qui veut dire que le blog mis à nouveau en ligne sera complètement clean que l'on ait fait une mise à jour anodine ou critique.
Une autre possibilité serait de lier symboliquement le répertoire du serveur sur celui d'export du moteur de blog si les deux résident sur la même machine (ou de faire un montage NFS sur un serveur distant ?).
Tout ceci peut sembler paranoïaque mais, faisant parti des gens que l'on peut qualifier de "tête en l'air", je sais qu'il existe un risque sérieux et réel lors d'une suppression de billet. Et je sais aussi que les conséquences sociales peuvent être lourdes.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par ckyl . Évalué à 8. Dernière modification le 15 mars 2015 à 18:30.
En même temps ça serait inquiétant que ça ne soit pas le cas. fBlog ne fait RIEN. Grosso modo il rajoute un header et un footer à des fichiers texte et maintient trois pauvres index. C'est entièrement IO bound et ça ne peut pas être lent au delà des lectures et écritures de fichier.
Commençons par créer le blog 365 * 50:
Maintenant regardons le temps écoulé dans les cas suivants:
Avec sync:
Sans sync:
Les mesures sont prises ainsi
Pour vider le cache VFS
Je passe l'analyse plus poussée. Tu peux jouer avec perf ou plein d'autres choses pour voir ou passe le temps en espace noyau et utilisateur.
Tu pourrais utiliser un langage qui repose sur une VM à base de lutin en grève ça ne changerait rien au temps d'exécution, le logiciel ne fait virtuellement rien.
Paralléliser ne changera rien tu es IO bound.
Ton approche de tout refaire peut très bien être justifiée. C'est un bête moteur de blog ! Maintenant si tu voudrais améliorer les perfs, la seule option c'est de faire moins de travail. C'est à dire ne pas refaire bêtement du travail déjà fait.
Bon en vrai on s'en balance. C'est un moteur de blog statique, la génération est faites une seule fois en asynchrone…
Et une fois que tu connais ton markup et les index que tu veux maintenir, la génération ca se recode dans la journée dans à peut prêt n'importe quel langage.
PS: Ton archive ça serait mieux si elle ne pourrissait pas le répertoire courant quand tu l'extrais.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 2.
C'est si facile à faire un moteur de blog statique qu'il en existe des centaines de projets ! La vérité oblige à dire que si l'on peut aisément citer de tête les trois premiers acteurs en matière de moteur de blog dynamique, on ne peut pas en dire autant des moteurs de blog statiques (enfin, ceux qui tiennent vraiment la route).
Oui, pour la fabrication d'une page, il y a juste à l'encadrer de l'en-tête et du pied de page qui va bien. Là où ça se corse c'est quand on veut y mettre les deux liens des pages précédentes et suivantes. C'est quand même une fonctionnalité sympa que bien des moteurs de blog (statiques ou dynamiques) n'ont pas. Pour Wordpress, il semblerait qu'il ne le fasse que depuis peu. Et ça c'est du traitement de données internes. Pas du I/O.
Pour les index : ah ah, ça c'est le gros morceau à coder ! Au point qu'il n'y a pas tant de moteurs de blog que ça offrant une recherche par date d'un permalien. fBlog le fait en 2 clics. Une grande partie des autres moteurs de blog (statiques ou dynamiques) se contentent de saucissonner le montant des billets en paquets de dix et à en mettre les liens en bas de pages (comme les résultats des moteurs de recherche). Les plus sophistiqués font un tri par mois et il faut se taper la totalité de la page de ce mois où va s'agglutiner tous les billet dudit mois. S'il y en trois ok ; mais avec une vingtaine… Et ça, c'est du traitement de donnée interne. Pas du I/O
Le test de performance m'a intéressé car je n'ai pas de SSD. Sauf qu'il est à refaire complètement car il ne rime à rien ! En effet, ton one liner génère les billets sur des dates très rapprochées. Il faudrait tu refasses ce test en se basant sur un billet par jour sur 50 ans. Et là, je suis certain que les chiffres seront très différents. Et je suis sûr que tu verras que le temps de cogitation est non négligeable comparés aux I/O. Tu verras aussi qu'il y a une routine qui rame, celle qui fait l'indexation des mois. (Elle est codée naïvement, j'avais prévu de l'optimiser cet hiver mais je n'ai pas eu le temps.)
J'attends avec impatience ces nouveaux tests !
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par ckyl . Évalué à 3.
De tête Jekyll, Pelican et quelques dizaines d'autres dont j'ai oublié le nom. Je t'avoue que c'est pas ma passion.
Arrête. On parle d'indexer 18K dates pour en sortir:
Ca consomme 0 en ressource. Ton CPU à une éternité pour faire ça pendant que les IO font du slow motion. Grosso merdo en étant large, si t'y passes plus de quelques µs par entrée y'a un soucis quelque part (ou il y a un truc non trivial que j'ai loupé).
Ce n'est aucunement une critique du projet ou de la réalisation. C'est juste une réalité technique de la problématique. Pas mal de gens l'on oublié mais un CPU ça va vite quand on l'utilise correctement.
Je ne refais pas les différents tests puisque tout ce qui va changer c'est la conso CPU en espace utilisateur.
Prenons deux billets par jour pendant un siècle:
Regardons ce que ça donne
Et visualisons le CPU flamegraph résultant (cliquer sur ce lien pour l'avoir en dynamique)
Donc à a vue de pif dans ce cas tu passes 20% du temps on CPU dans la fonction
html_month_archive. En l'optimisant tu gagneras au mieux 20%. J'ai survolé le code 11s mais j'ai du mal à voir ce qui peut demander un algo en n3 pour faire un index par mois. Après comme je l'ai déjà dit, ton truc fait très largement le job.PS: je t'ai trouvé un bug. Si le nombre de fichier dans export_html dépasse le nombre d'argument supporté par la ligne de commande tu plantes (
sh: /usr/bin/rm: Argument list too long).[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 2.
Ça confirme bien ce que je pensais; mais bien évidement ce n'est pas impactant sauf sur ma petite fierté !
Merci de l'info !
Oui, sauf que je n'en ai pas encore vu un seul qui répondait à mes désirs : des permaliens, un chaînage par lien des permaliens entre-eux et un moyen de retrouver un billet précis connaissant le mois de sa publication puis connaissant soit son titre, soit son jour et heure de publication. Il doit aussi supporter au moins un billet par jour sur de nombreuses années.
Jekyll et Pelican ne semblent pas avoir de liens chaînant les permaliens entre-eux et la page d'archive ne convient pas pour un blog ayant de nombreux billets sur de nombreuses années. Mais si je dis une bêtise, que quelqu'un donne l'URL d'un blog fait sous Pelican ou Jekyll et qui répondrait à mes besoins.
Et si quelqu'un a la connaissance d'un moteur de blog statique qui a au moins les mêmes fonctionnalités que fBlog, merci de me répondre ici !
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 3.
Non, s'il est difficile de citer les principaux moteurs de blog statiques, c'est parce ce genre d'outil est assez peu utilisé.
Ajouter deux liens dans une page, oui, si on veux, c'est du traitement, sauf que ça ne demande rien à faire. Comme cela a été dis plus haut, ce que fait ton moteur de blog, c'est trois fois rien pour un développeur. Surtout avec des outils plus adaptés.
Par exemple, si je prend du Ruby, je dois pouvoir lister les fichiers d'un dossier et les trier par ordre alphabétique en 5 lignes de code. Parcourir cette liste et, pour chaque élément, concaténer un en-tête, le contenu du fichier et un pied de page, y intégrer deux liens vers les pages suivantes et précédentes, le titre du blog et quelques pages statiques listées dans un fichier de config, et écrire le résultat dans un autre fichier devrait me prendre 25 de lignes (en étant généreux, et parce qu'il y a un peu de html à stocker quelque-part). Trier la liste des fichiers par année et mois devrait prendre 10 autres lignes, et générer les pages d'archives 25 autres. Ce qui nous fait 65 lignes, que j'arrondis à 150 histoire d'être large. Ce script utiliserait uniquement des fonctionnalités présentes dans la bibliothèque standard de Ruby, j'aurai pu l'écrire de la même façon lorsque j'ai appris le Ruby en 2006, et je pense que dans 10 ans, vu sa simplicité, il fonctionnera toujours. Coté performances, mon script n'aura rien à envier à ton moteur en Fortran, quand bien même il s'agit d'un langage de script.
Vouloir avoir un moteur de blog qui fonctionnera encore dans 50 ans, c'est joli, mais ça ne rime à rien. Le plus important aujourd'hui, c'est d'être capable de faire face au changement. Et mes 150 lignes de Ruby contre tes 4000 lignes de Fortran ont un avantage certain : il sera bien plus facile de les maintenir et de les faire évoluer. De plus, rien de garantit que ton binaire sera encore fonctionnel dans 50 ans. Au hasard, abandon des archis 32 et 64 bits, ou du format d'exécutable Elf.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 4.
Oui, c'est statistiquement vrai. Mais je crois que les gens commencent à s'y intéresser un peu plus car les moteurs de blogs statiques ont certains avantages de robustesse.
Absolument d'accord ! La partie programmation pure d'un moteur de blog n'est pas un exploit. Tant que l'on sait ce que l'on veut. Si l'on sait ce que l'on veut, soit le problème a déjà été fait par autrui et il n'y a qu'à copier-coller, soit on est dans dans un cas nouveau. Auquel cas on ne sait pas d'avance si c'est réalisable ou pas. Mais très vite on est fixé.
Le souci commence quand on ne sait pas très bien ce qu'on veut. Généralement on sait très bien ce qu'on ne veut pas. Si la liste des options restantes est bornée, il suffit de procéder par élimination. Sinon, on brasse…
Dans mon cas, j'avais identifié mes problèmes avec NanoBlogger qui étaient uniquement dû à un mauvais passage à l'échelle. (Un mur au-delà de 100 billets).
Dans le cadre d'un blog tenu sur une longue durée avec de nombreux billets par mois, il me semblait indispensable d'avoir un système d'archivage. Le problème n'est pas de coder ça mais de savoir combien de pages on veut (une récapitulation par an, une récapitulation par mois, une récapitulation par semaine ?).
Je m'arrête là car il y aurait beaucoup d'autres point de détails à communiquer et la place, et l'énergie me manque.
En fait, si l'on a déjà vu à quoi ressemblait une roue et si l'on en a vue une application (pour une brouette par ex.) n'importe quel abruti peut construire une brouette. Mais on a connu jadis de très grandes civilisations qui ignorait cet accessoire si banal dans nos jardins.
Donc coder un logiciel en se basant sur le design d'un logiciel existant est à la portée de bien des gens. Et c'est même le minimum syndical pour un pro. Reste l'outillage : sujet hautement trollesque ! J'ai donné plus haut mes motivations sur le choix de Fortran, je n'y reviendrai donc pas.
Mais j'affirme que la partie codage en Fortran de fBlog n'a été qu'une très petite part du temps consacré. Le restant se partageant entre mes hésitations sur le design des pages et le codage HTML et CSS. Vous pouvez ricaner sur la difficulté à maîtriser HTML et CSS ! Mais regardez donc l'annonce faite dans ces colonnes le mois dernier concernant la mise à jour de Dotclear et une remarque que j'avais faite. Aujourd'hui le site officiel de Dotclear est toujours sous le doctype XHTML 1.0 Strict ! J'ai exploré aussi les limites des CSS en supprimant les balises DIV et SPAN et en les remplaçant par des pseudo classes. Ça aussi, ça prend temps. Et je n'étais même pas sûr que ce soit faisable. Mais, tant que j'y suis : amis lecteurs, avez-connaissance d'un moteur de blog n'employant que des pseudo classes ?
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . É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.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par grim7reaper . Évalué à 10.
Nope, le plus ancien langage c’est l’assembleur (1949).
Nope, il est encore plus vieux que ça.
Le premier hyperviseur est sortie dans les années 60 il me semble.
La première version de FORTRAN en 1957.
Hum, ça dépends ce que tu appelles « débuts »… À ses débuts, FORTRAN n’avait même pas la notion de fichiers.
Les scratch files dont tu parles sont apparus en FORTRAN 77 (d’ailleurs avant FORTRAN 77 il n’y avait même pas de type CHARACTER, on devait utiliser les constantes d’Hollerith).
Et un truc aussi basique que accéder aux arguments de la ligne de commandes (argv en C) était impossible de manière portable avant Fortran 2003 (GET_COMMAND_ARGUMENT), avant il fallait passer par des fonctions spécifiques au compilateur. La joie…
Encore, mieux pour lancer une commande externe (genre ls) il aura fallut attendre Fortran 2008 pour avoir un truc standard (EXECUTE_COMMAND_LINE).
Ça me fait doucement rire de lire que Fortran savait tout faire depuis ses débuts. On en est loin.
Fortran ne va pas t’apporter de gain de performance sur la gestion des fichiers, les I/O c’est limité par le disque de toute façons, pas par le CPU (pour du traitement de données en mémoire ouais Fortran va sûrement être performant, mais pour des I/O sur des fichiers sur disques, non).
Avec le C++ ça m’étonnerait, vu que l’ABI est pas standardisé.
Par contre avec le C ouais, surtout depuis Fortran 2003 :)
Attention, je ne remet pas en cause le choix du Fortran (qui est un langage que j’apprécie aussi, au cas où mon message laisserait penser le contraire) pour ton moteur de blog, je trouve ça même carrémment cool :)
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 0.
Je n'ai jamais pratiqué l'assembleur (tout juste quelques "hello world!"). Je n'ai jamais rien entendu d'une quelconque normalisation de l'assembleur et je remarque qu'il existe plusieurs notations (AT&T ou Intel ?). Je ne mets pas l'assembleur pur dans les langages de programmation sauf, à la rigueur, si on le mixe avec des directives et des macros comme ça semble se faire aujourd'hui.
Dans le contexte des années 50 (je ne faisait pas d'informatique à ce moment là !) il n'existait que des programmeurs purs et durs. Un ingénieur ou un scientifique devait passer par eux car l'apprentissage de la programmation était vrai métier pas un hobby. L'invention de Fortran visait à rendre accessible l'écriture de programmes aux personnes n'ayant rigoureusement aucune qualification en programmation. Et donc à se passer de programmeur. Aujourd'hui, gfortran traduit le source Fortran en source assembleur. Et gcc fait de même pour le langage C.
De ce qui précède, je ne considère pas l'assembleur comme étant un langage de programmation car le but d'un langage de programmation est de générer un source assembleur.
Oui, mais au sein d'IBM. On peut aussi considérer que Fortran est vraiment né quand il a été porté chez d'autres constructeurs qu'IBM. Et là, oui, on est dans les années 60 !
Le sujet de mon article était la promotion de mon logiciel et non pas celle du langage Fortran, j'ai forcément fait court. Par exemple, j'ai le livre de Madeleine Bernheim "Fortran mode d'emploi" édité en 1991 et qui donne la version F77 comme étant la cinquième évolution de ce langage. (Peu de gens savent aussi qu'il a été normalisé par l'ISO un Fortran "Temps réel" !)
Mais si l'on doit faire court, on peut raisonnablement considérer la version F77 comme étant la première au vue de sa popularité. D'ailleurs gfortran supporte la version F77 et non celle plus ancienne F66 pourtant normalisée par l'ISO.
Tout à fait d'accord ! Mais, là encore, j'ai voulu faire court dans mes propos. À disque dur égal, Fblog aura des variations de performances considérables selon les options de journalisation du système de fichier. Ceci portant sur le second volet des I/O. Et l'on est tous les deux d'accord sur la bonne prise en charge du traitement des données en mémoire par Fortran.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 2.
Même en 2015, développeur est un vrai métier ! Je comprend ce que tu veux dire: à l'époque, on n'était pas "développeur du dimanche". Mais "avoir la programmation comme hobby" et "être développeur", ce n'est pas la même chose (et il y a bien trop de personnes qui le pense).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par jmliger . Évalué à -3.
Les recommandations d'un développeur spécialisé dans les web apps :
1. Building light web applications and modules.
2. Building easy to maintain and reusable software.
3. Building software that makes collaboration easy.
4. Having fun by writing elegant and concise code.
http://blog.cozycloud.cc/technic/2014/10/03/why-coffeescript/
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par grim7reaper . Évalué à 3.
De part sa nature (avoir accès au jeux d’instructions du CPU sous-jacent), il est impossible d’avoir un unique langage assembleur (et donc quelque chose de normalisé).
Ça n’est que de la syntaxe, la plupart des assembleurs (je parle ici du logiciel) supporte les deux syntaxes.
Pourtant, c’en est un.
Au contraire, je pense (peut-être à tord) qu’à l’époque la plupart des informaticiens était des scientifiques (matheux et physiciens surtout) plus ou moins reconvertis.
Il ne devait pas y avoir de cursus « informatique » dans les universités.
Pour avoir bosser sur un modèle de simulation écrit par des non-développeurs prendant près de 10 ans, je peux te dire que « se passer de programmeurs » est une très mauvaise idée…
Le code s’est développé de manière organique et est impossible à maintenir ou faire évoluer. Aux dernière nouvelles, il était en cours de réecriture par un « vrai » informaticiens.
Mauvaise définition (beaucoup de langages de programmation ne respecte pas cette définitions)
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par cfx . Évalué à 2.
Je suis trop jeune pour en attester, mais j'ai déjà entendu la même chose. Ce développeur était aussi le mec en charge d'écrire le programme sur des cartes perforées (le cas échéant).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard (site web personnel) . Évalué à 1. Dernière modification le 16 mars 2015 à 20:06.
Bon, ceci est hors du topic de mon journal qui visait à faire en première lieu à faire la promo de fBlog et en second lieu de mettre en parallèle deux sites identiques générés sous fBlog (l'un en hébergement à domicile sur un ordi de bureau banal oceamer.com, l'autre chez un hébergeur de premier plan oceamer.fr ). L'aspect du choix de Fortran pour la programmation est pour moi secondaire. Si j'avais eu la maîtrise de Python au début, nul doute que c'est ce langage que j'aurais employé. Mais comme j'avais un passé avec Basic, Fortran m'a paru être plus évident.
Chacun a sa petite opinion sur la définition d'un langage informatique, je vais donc préciser ici ce que j'en pense (mais je suis un pur autodidacte, pas un distingué docteur en informatique !).
À mon sens la programmation pure se fait en opcode ou en assembleur. J'ai connu un navire de commerce construit en 1999 avec un système de contrôle de cargaison de gaz de pétrole liquéfié qui ne pouvait se programmer qu'en opcode depuis un télétype qui servait aussi d'imprimante pour la transcription des alarmes. Je ne sais pas si ça existe toujours dans l'industrie de nos jours.
Par abus de langage, dans la mesure où l'on écrit dans un langage informatique qui va ensuite générer du code assembleur qui ensuite sera transformé en un fichier elf (ou autre), je parle encore de programmation et de langage de programmation. Mais, j'en conviens, c'est un abus de langage !
Ceci étant, il n'y a pas que des langages capables de générer au final un fichier elf. Il y a ceux qui sont interprété soit dans une runtime soit dans un interpréteur externe. Si l'on prend le cas de Fortran, la norme n'emploie absolument pas le mot de "compilateur" mais celui de "processeur". Car Fortran peut tout aussi bien être exécuté par un interpréteur ! Si je ne connais pas d'interpréteur Fortran en usage aujourd'hui, d'après mes lectures, j'ai des raisons de penser qu'il en a existé jadis.
De nos jours, le mot "développeur" tend à se substituer à celui de "programmeur". Je pense qu'il y a là-aussi un abus de langage. Pour moi le développement est la création d'un logiciel alors que la programmation est la création d'une routine. Le développeur fait une agrégation de plusieurs routines (qui pourront être écrites dans des langages différents) alors que le programmeur agit sur un spectre plus étroit.
Par exemple, si j'écris une routine pour afficher un calendrier sur une console à la ligne de commande, j'estime être dans le cas d'une programmation. Si la même routine fait appel à la bibliothèque ncurse pour afficher le calendrier d'une manière plus jolie, j'entre dans le développement. Idem si la routine attaque une bibliothèque graphique sous X-Window.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Gof (site web personnel) . Évalué à 3.
L'ABI du C++ est tout autant normalisée que celle du C.
(Ni l'ABI du C ni l'ABI du C++ ne sont normalisées par le langage lui même. Par exemple, les conventions d'appel de fonctions, les tailles et l'alignement des différents types sont laissés libre à l'implémentation.
Pour les deux langages il existe des documents qui documentent l'ABI sur différentes plateformes. Par exemple SystemV ABI pour le C, ou Itanium C++ ABI pour le C++.
Il est vrai que l'ABI du C++ est beaucoup plus vaste car le langage à beaucoup plus de fonctionnalité.)
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par grim7reaper . Évalué à 2.
Oui, j‘ai fait un raccourci un peu rapide (qui pourrait laisser entendre que l’ABI du C est standardisé au même titre que le langage).
On est d’accord que l’ABI du C dépends du système mais c’est déjà beaucoup moins variable que celle du C++ (surtout à cause du name mangling (du coup, ça varie entre compilateurs)) et stable (on peut avoir des suprises entre versions du même compilateur, GCC 5 pète l’ABI du C++).
Donc, ce que je disais reste vrai : c’est casse-couille de s’interfacer avec du C++, mais avec du C c’est très simple.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par zurvan . Évalué à 1.
il fallait lire « le plus ancien des langages de programmation de haut niveau ».
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par grim7reaper . Évalué à 2. Dernière modification le 17 mars 2015 à 19:38.
Haut niveau (et bas niveau) c’est relatif.
Un développeur Web (ou même Java) va te rire au nez si tu lui dit que Fortran est un langage haut niveau.
Après, pas rapport à l’assembleur c’est plus haut niveau.
Et l’assembleur est plus haut niveau que le binaire ou l’hexa.
Tout est relatif.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Dr BG . Évalué à 2.
Il y a quand même une différence : l'assembleur n'est pas compilé, les instructions ne sont que des mnémoniques du code binaire (on gros, il y a bien quelques fioritures dans les assembleurs modernes).
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par GuieA_7 (site web personnel) . Évalué à 1.
Le programme en langage assembleur est transformé en programme équivalent en langage machine : c'est bien une compilation. Une compilation triviale certes, une compilation qui laisse peu de place à l'imagination certes, mais une compilation quand même.
[^] # le bon outil ...mais je débute!
Posté par justin . Évalué à 0.
D'abord bravo pour les résultats que donnent fblog, une fois mis en œuvre dans les exemples proposés.
J'ai téléchargé, puis décompressé l'archive… (peut-être pas au bon endroit?) en tout cas, la console refuse de l'exécuter et m'affiche 'commande introuvable' lorsque je fais --create ou -a, à partir de l'exécutable.
J'ai visité le lien du blog, mais je n'ai trouvé que des infos de mises à jour.
J'avoue que le README et le MAN n'a pas non plus débloqué mon pb.
Est-il possible d'avoir quelques instructions d'installation supplémentaires?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.