Blackknight a écrit 1237 commentaires

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.

On peut dire la même chose du diagramme UML…

C'est censé être un vue synthétique, pas exhaustive ce qui est impossible, le code lui le sera toujours, exhaustif.

En fait si le code peut être généré depuis l'ULM et inversement, il n'y a pas beaucoup de valeur ajoutée à faire l'un plutôt que l'autre

Ce ne sont pas les mêmes niveaux de conception. D'ailleurs, le code, ce n'est pas de la conception, c'est de la réalisation.
C'est peut-être aussi pour ça qu'un architecte fait des plans de maison et que le maçon les réalise ensuite.
Au passage, j'adorerai voir une méthode agile appliquée au bâtiment :D
L'informatique me donne l'impression d'être la seule activité d'ingénierie qui dit, on fait sans concevoir parce que c'est chiant et qu'il est plus facile de refaire ce que l'on a réalisé.

Je fais partie de ceux qui trouvent plus clair de définir le modèle de donnée directement en code plutôt qu'en UML.
Et si quelqu'un veut absolument de l'UML pour discuter, bah on le génère depuis le code. Y'a autant d'info au final, et c'est plus facile à maintenir dans ce sens là.

Ben, y a des gens qui ne lisent pas le code et pour qui une représentation graphique vaut mieux qu'un long discours abscons dans une langue inconnue.

En outre, ce genre d'architecture inverse le contrôle de l'architecture de l'app. Bref, ce n'est pas là qu'on va innover, on est là pour rentrer dans les rails.

C'est rigolo comme formule quand on pense que c'est dans le ferroviaire, l'aéronautique et le spatiale qu'on cherche le plus à faire du développement piloté par les modèles :D
Du coup, on écrit des spécifications au travers de modèles que l'on transpose ensuite dans le langage cible.

Pour le reste de l'informatique, tout ceci a pratiquement disparu et quand tu cherches une documentation technique de haut niveau, on te renvoie vers le code parce que c'est le code qui fait foi, ce qui est vrai au final mais terriblement bas niveau.
Finalement, c'est juste la mort de l'ingénierie logicielle sacrifiée à l'autel du Time to market

Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.

C'est toujours mieux que rien. Je lis beaucoup de gens ici se plaindre d'avoir à écrire du code boilerplate et franchement écrire le squelette d'une classe, ce n'est justement que ça.

Personnellement, j'ai travaillé il y a une quinzaine d'années sur un projet où la spécification détaillée a été écrite en utilisant des diagrammes de cas d'utilisation, des diagrammes de classes et des diagrammes de séquences.
Finalement, le client, un automaticien reconverti en chef de projet, a trouvé le document très clair et cherry on the cake, on utilisait le même modèle UML pour générer l'ossature du code C++ ainsi que remettre les diagrammes à jour depuis le code ensuite.
Alors, ce n'est pas parfait mais pour moi, le code n'est que la conséquence de la conception et la conception est l'image de la compréhension du problème. UML fournit un langage qui permet de représenter rapidement l'image qu'on se fait du problème.
Du coup, pPlonger dans le code directement introduit les biais issus de la conception du langage et obscurcit par la même occasion le problème.

Au passage, aux dernières nouvelles, le code C++ généré (en partie) fonctionne toujours.