Blackknight a écrit 1240 commentaires

Merci de l'explication, j'avais pas tout compris effectivement et c'est dommage puisque je me suis amusé à commencer une implémentation à l'identique en Ada ;)
Du coup, il vaut mieux comprendre :D

En tout cas, c'est finalement très logique et ça explique bien les paramètres que l'on peut passer.

Normalement, en Ada, il ne me reste que la gestion des options (autre que le simple argc, argv) et l'internationalisation car ce sont des trucs qu je n'ai jamais bidouillé.

D'abord, félicitations pour ce petit soft bien sympa.
Ensuite, j'ai une petite question sûrement idiote mais pourquoi as-tu stocké les timestamps de chaque appui de touche pour ne finalement prendre que la première et la dernière valeur et calculer une moyenne ?
N'était-il pas plus simple de ne garder que le nombre d'appuis et le premier et le dernier horodatage ?
J'ai dû louper un truc :D

contrairement au développeur original dont la lecture est biaisée par le contexte de la création du code.

Ça ne s'applique que lors de la création parce que quand on revient sur du code que l'on a écrit 5 ou 6 ans plus tôt, on se retrouve dans la position de l’œil extérieur et généralement, c'est là qu'on regrette de ne pas avoir été clair

Super, bravo et merci

Alors pour le coup, c'est un publi-communiqué ?
Tant qu'on n'a pas vu le code source et la licence, on a donc un journal noté à plus de 40 pour exposer de la pub !!

Y a que moi que ça choque de voir ça sur LinuxFr ?

beaucoup de programmeurs sont fâchés avec ces concepts difficiles mais doivent faire face au quotidien à des difficultés qui viennent justement de ce manque de compréhension fine des concepts

Oui alors bon, on va quand même être plus circonspect, on (les informaticiens) a beaucoup d'autres problèmes techniques à résoudre dans la majeure partie des cas avant d'en arriver à se poser des questions d'analyse numérique :D

PS: Je me suis permis une petite correction de conjugaison sur la citation, "la grande majorité" se trouvant entre parenthèses, j'espère que tu ne m'en voudras pas :D

Alors oui, je suis bien d'accord avec ton explication mais le but de mon exemple était juste de montrer qu'en utilisant la bonne techno, ici un type à virgule fixe, on répond au problème d'origine… Ton exemple montre qu'on ne répond pas à tout avec.

Le tout, c'est de le savoir :)

with Ada.Text_io; use Ada.Text_Io;

procedure Test_Real is
   type mon_real is delta 0.1 digits 3 range 0.0..10.0;

begin
   Put_line (mon_real'Image(2.0 - 1.8 - 0.2));
end Test_Real;

Et voilà, c'était pas compliqué :D

Bon, ok, c'est pas des vrais float, c'est de la virgule fixe

GlusterFS est performant lorsqu'il gère peu de très gros fichiers, du genre des fichiers de VM. Et il est mauvais lorsqu'il doit gérer une multitude de petits fichiers et répertoires.

Un peu hors sujet, mais typiquement, avec CodaFS, c'est plutôt l'inverse vu que les fichiers sont rapatriés dans le cache ce qui peut prendre un temps non négligeable.

Pour être précis : dans la mesure du possible, nous essayons de porter nos changements à la FSF (que ce soit pour le front end GNAT, ou nos modifications dans le middle/back end de GCC) de manière régulière tout au long de l’année, pas seulement vers juin.

Merci de la précision Pierre-Marie, ça doit être une légende urbaine qui a la peau dure :D

Y a de ça mais c'est aussi plus que seulement le compilateur.
En fait, dans GNAT Pro, ce qui coûte n'est finalement pas le compilateur en lui-même mais tout ce qui va autour, à savoir, le support technique notamment pour les certifications, les outils développés spécifiquement pour la suite GNAT Pro et les runtimes exotiques.
Pour avoir une petite idée de ce que cela couvre, voici le tableau comparatif.

En fait, à l'origine, GNAT était développé par l'université de New York.
Après la sortie et la validation du compilateur, licencié sous GPL, les auteurs ont fondé deux sociétés AdaCore à New York et ACT Europe à Paris.
Si au début, le compilateur vivait sa vie en dehors de Gcc, il fait maintenant partie intégrante et AdaCore, fusionné depuis 2012 avec ACT Europe, reverse ses développements tous les ans dans le code de Gcc, généralement vers juin.
Il existe donc plusieurs versions:

• FSF GNAT, sous GPL3+ avec une exclusion pour le Runtime
• GNAT Pro, la version "commerciale" d'AdaCore avec support
• GNAT GPL, la version GPL d'AdaCore qui est généralement une version Pro avec un an de retard et sans support téléchargeable sous forme binaire depuis le site Libre

Au passage, depuis plusieurs mois, AdaCore dispose maintenant d'un compte Github sur lequel on retrouve les versions de développement des différents outils développés par leurs soins.

Ah ouais, j'ai tellement voulu mettre de liens dans le journal que finalement, j'ai oublié le plus important !
Dommage que je ne puisse plus modifier le journal.

En tout cas, un grand MERCI :)

Il n'y a rien à dénoncer, il faut juste savoir garder un œil critique.
On n'a jamais vu un langage percer uniquement en le comparant aux autres.
Que quelqu'un recode Mr. Boom en Rust et montre les avantages et inconvénients comme cela a été fait dans le journal sur Gnirehtet, c'est beaucoup plus constructif que de dire que coder en C c'est nul.

Ok, du moment qu'on a le droit de critique le C et le C++, et autant qu'on veut (du moment que c'est justifié).

Et Rust aussi

Parce que bon, Rust n'existe pas que pour le plaisir.

Comme beaucoup d'autres langages, rien de nouveau sous le soleil.

Au moins, il y a quand même un truc super positif qui ressort de tout ça, c'est qu'avec tout ce qu'il y a à ré-écrire, les développeurs Rust ont du boulot pour au moins 15 ans :D

Après, c’est sur que si ta référence de qualité pour le code c’est du brainfuck…

J'ai juste pas voulu taper sur Python après l'exemple sur Ansible :)

on s'éloigne d'UML qui contient plusieurs centaines de concepts, c'est trop pour comprendre toutes les subtilités.

Tout à fait d'accord. Personnellement, je trouve aussi qu'il y a trop de choses dans UML mais avec les diagrammes de classes, de séquences et use-cases, tu documentes déjà pas mal.
Après,un diagramme de déploiement ne fait pas de mal :D

Pas forcément. La mode est de décrire l'architecture

Je ne voulais pas forcément parler d'AADL et autres joyeusetés, ça aurait filer trop de boutons à certains ;)

Faudrait arrêter aussi de chier des logiciels aussi gros.

Heu, comment dire, briques simples => communication entre briques => validation d'interfaces => documents d'interfaces. Je ne suis pas sûr que cela simplifie

Il y a des cas où la complexité du projet fait que non, tu ne t'amuses pas à découper en micro-services.
L'exemple C++ dont je parlais est un système de contrôle-commande qui pilote des automates de plus bas niveau alors comme tu gères la cohérence et la gestion d'un système complet interagissant avec d'autres systèmes, tu ne peux pas découper.

Je pense à l'exemple Ansible vs Saltstack.

C'est vrai que vu qu'Ansible est codé en Python, il vaut mieux faire des petits trucs parce que c'est pas la compilation qui va t'aider à t'y retrouver en cas de refactoring.
Et puis, dans certains systèmes, le message tutu has no attribute fera beaucoup moins rire les utilisateurs.

Ça reste un diagramme alors sauf s'il est écrit des annotations en cyrillique, oui, j'ai l'espoir, voire la prétention, d'en comprendre nettement plus qu'un code écrit en Brainfuck par un obscur codeur qui a décidé qu'il ne documenterait rien car son code est, de fait, auto-documenté.

dans l'informatique on fait exactement la même chose sauf que les documents de conception sont les fichiers sources !

Ok, je te file un code en Ada83 de plusieurs dizaines de milliers de lignes et je te dis, voilà le doc de conception, tu as deux heures pour m'expliquer ce que tu as compris… Et encore, avec toi, j'ai bon espoir, tu fais du C++ :)

Dans le cas d'un logiciel de gestion faisant intervenir des humains, le nombre de degrés de liberté devient énorme et les belles méthodes idéales atteignent vite leurs limites.

Certes mais cela n'empêche pas d'avoir un minimum de documentations comme une spécification fonctionnelle, un modèle de base de données (en quoi d'ailleurs ? En SQL directement ou en Entité-Relation/Merise ?) et une spécification technique (explication "grosse maille" de l'architecture du code)

cela a permis d'avoir les mêmes règles dans chaque établissement et chaque secteur.

J'ai toujours trouvé que, pour les logiciels de gestion, le principal avantage de l'analyse, c'est de permettre de rationaliser les strates de process qui n'ont pas été dépoussiérées depuis des lustres par le client :)

Le seul point sur lequel on n'est pas d'accord, c'est que tu considère qu'on ne peut pas faire de la conception en codant.

Exactement, tout comme on ne conçoit pas une maison pendant qu'on la construit.
Il y a quand même un bémol, si le projet est de taille raisonnable, c'est faisable mais dès que le projet devient gros et qu'il y a toute une équipe de développeurs, ça devient le bordel et chacun "conçoit" dans son coin.
Et de toutes façons, comme tu le dis, c'est de la documentation donc ce n'est pas inutile.

Je ne vois pas en quoi du code est terriblement bas niveau.

Une conception peut être réalisée dans différents langages et ne spécifie pas les détails d'implémentation.

Si c'est la mort de l'ingénierie logicielle qui considère que le code c'est pour les grouillots car c'est trop concret pour eux, et bien je ne vais pas les pleurer.

Je n'ai jamais dit ça mais pour comprendre un problème faut-il obligatoirement être un dieu du langage d'implémentation ?
C'est juste une séparation des responsabilités ou des niveaux d'abstraction.
D'ailleurs, dans le cadre du développement d'un système complet, il peut très bien y avoir différents langages d'implémentation. doit-on tous les connaître pour comprendre ce que fait le système dans son ensemble ?

D'un autre côté je pense que tout spécifier graphiquement nuirait à la productivité.

C'est pour ça que l'on parle de modèle d'analyse, de modèle de conception et de modèle d'implémentation. Le dernier n'est normalement qu'un extrait de l'implémentation réelle qui n'ont aucun intérêt dans une représentation graphique.