Merci pour cet article très intéressant. Je me suis posé récemment le même type de questions en cherchant un backend léger et sûr (du point de vue typage) pour des frontends écrits en Elm. Et en étudiant des architectures de backend, j'avais l'impression qu'entre la BD et la partie ORM du backend, il y a souvent beaucoup de redite.
Je suis alors tombé sur des projets (l'un en haskell) PostgREST et (l'autre en JS) Graphile, selon que l'on préfère les architectures REST ou GraphQL.
Je ne connaissais pas cette solution purement SQL, mais je trouve intéressant d'explorer les capacités de gestion des données directement par le SGBD, plutôt qu'en faisant (ou refaisant) les choses côté backend. Forcément, l'approche a ses limites : il faut souvent recourir à des notions de workers ou autre pour certaines actions… Mais le SGBD est bien souvent capable de réaliser des optimisations difficilement envisageables avec une couche ORM, pour peu qu'on décrive précisément ce qu'on souhaite faire.
J'apprécie beaucoup le côté déclaratif de SQL, qui sous-traite (généralement de manière assez efficace) au moteur du SGBD le soin de trouver le meilleur schéma d'exécution. Et, quand ce n'est pas le cas, c'est une très bonne occasion de se poser quelques questions sur la représentation/normalisation de nos données, et de réfléchir à l'utilité de créer tel ou tel index, vue matérialisée, etc.
Bref, quel est alors le lien avec le langage Elm, aucun, sinon un jeu de mot franco-anglophone qui me démangeait pour le titre de mon commentaire.
Est-ce offensant d'être catégorisé dans Others ou non ?
Car si on trouve ça offensant, alors pourquoi le mettre dans un acronyme ?
Si le but de l'acronyme est de recenser exhaustivement toute personne se définissant comme non hétérosexuelle, et si on pousse le raisonnement dans ses retranchements, alors pourquoi pas utiliser simplement Others ?
Parce que là, on est sûr d'être exhaustif (ça me rappelle les "CASE statements" en Ada…)
Mais c'est compliqué, car à dire Others, on glisse facilement sur le terrain du normatif et de la discrimination (et pourquoi ça serait eux les autres ?).
Bref, vouloir faire des catégories avec ce qui au départ sont surtout "des personnes" est toujours complexe et un poil casse-gueule !
Il faut aussi prendre en compte que la durée de vie d'un programme avion dépasse de loin celle d'une voiture, par exemple (pour ne pas parler de celle d'un smartphone…).
Un avion prend environ 5 à 10 ans pour sa conception, il est présent au catalogue pendant plus de 30 ans (depuis 1988 pour l'A320, beaucoup plus pour le B737, mais il a tellement changé que ce n'est plus le même avion qu'au début, sauf pour les autorités de certification américaines !!), et ensuite il peut encore voler pendant 25 à 30 ans (soit environ 100 000 cycles de décollage-atterrissage) dans des compagnies à peu près sérieuses (paradoxalement, les compagnies qui ont les flottes les plus jeunes sont les low-cost, car elles les font voler vraiment souvent!). Et on n'évoque pas ici une éventuelle seconde vie dans des pays beaucoup moins à cheval sur les réglementations !
Les premiers ingénieurs en chef de l'A320 sont à la retraite depuis un bon moment (programme lancé officiellement en 1984).
De manière plus générale, la transmission et la conservation du savoir et du savoir-faire en entreprise est un vrai défi.
Après, ça dépend un peu de la culture d'entreprise. Aux États-Unis, la grande mobilité (subie ?) des salariée fait que c'est beaucoup moins choquant de se séparer de tout son bureau d'étude lorsqu'on a rien en prévision. C'est en partie ce qui a permis à l'avionneur brésilien Embraer de débaucher quelques très bons ingénieurs à la fin du programme de développement du B777 pour attaquer le segment des avions monocouloirs de plus de 100 passagers, sur lequel il n'était pas encore présent.
D'ailleurs Airbus aurait les technologies pour remplacer l'A320 par un modèle plus efficace, mais à un coût difficile à absorber surtout après quelques semi-échecs commerciaux (A340, A380).
Je suis assez d'accord avec cette analyse.
Si à la fois Airbus et Boeing ont choisi la re-motorisation à la re-conception complète d'un avion, c'est d'abord parce qu'ils se marquent à la culotte, et ensuite parce que même si des technologies récentes permettent de faire des progrès sur le papier, il n'a pas encore été démontré qu'on savait le faire d'un point de vue industriellement rentable…
Airbus a introduit la plupart de ses nouveautés (du point de vue systèmes notamment) sur l'A380. Ils pouvaient se le permettre à l'époque, car au moment du lancement de l'A3XX c'était moins tendu économiquement, et l'avion devait représenter le savoir-faire d'Airbus pour l'avion du XXIème siècle. Les compagnies (certaines, du moins), était prêtes à payer pour un avion de tous les superlatifs (salon-bar, cabines "Première" avec douches privatives…).
L'A380 a pourtant lutté durant tout son (long) développement et sa (courte) carrière avec un problème de sur-poids. Les premiers modèles livrés étaient tellement loin du poids vendu par les commerciaux et tellement en retard qu'Airbus a dû payer des compensations énormes aux premières compagnies livrées.
Aux alentours de 2010, j'avais entendu par des infos internes qu'Airbus estimait que le nombre d'A380 à vendre pour amortir le développement ne serait jamais atteint (et à l'époque, ils ne projetaient pas d'arrêter la chaîne en 2020…).
Ce ne fut pas un échec complet, car l'A380 a permis à l'A350 de bénéficier d'énormément de développements, réutilisés tels quels, ou presque, là où Boeing a connu bien plus de déboires avec son B787 Dreamliner, qui a été parfois été rebaptisé Nightmareliner.
Sauf que l'A350 et le B787 ont eux aussi connu les difficultés rencontrées par l'A380 : non-respect des objectifs de coût, de masse et de délai. En grande partie à cause de l'introduction des composites (l'A380 en avait déjà un peu), encore une fois sur-vendue du point de vue des économies réalisables par les commerciaux d'Airbus et de Boeing. Dans l'industrie, on peut rarement chiffrer les économies en faisant A - B, surtout lorsque B a une forte influence sur A… Et la structure composite a eu une forte influence sur énormément de choses.
Pareil pour les systèmes : une autre des principales difficultés venait de l'augmentation du nombre de systèmes électrique, qui exigeait un redimensionnement des systèmes de refroidissement, qui à leur tour avaient un impact sur la consommation électrique et le poids…
D'évidence, loger toute ces technologies dans le format d'un A320 ou d'un B737 ne s'annonce pas simple du tout. Et je pense que ça effraye les deux constructeurs. Car se louper sur l'avion qui assure la majeure partie de la trésorerie de l'entreprise représente un risque économique bien plus élevé que de se louper sur des avions qui représentent beaucoup moins de volume (Boeing la démontré avec la crise du 737-Max).
La plupart des analystes annoncent que ces avions verront le jour lorsqu'il y aura une véritable rupture technologique (principalement au niveau moteur) qui justifiera une re-conception complète, en abaissant le coût opérationnel de manière bien plus significative que ce qu'un A320-Neo ou qu'un 737-Max peut proposer aujourd'hui.
Pourquoi ? Parce que le premier concurrent du remplaçant de l'A320 sera … l'A320, un avion optimisé jusque dans ses derniers retranchements depuis 30 ans, re-motorisé de surcroît, qui a fini par atteindre un taux de disponibilité opérationnel extrêmement élevé (idem pour Boeing, avant l'arrivée du Max). Et cet indicateur (surtout depuis l’essor des compagnies à bas-coût) est considéré en priorité par les compagnies, même avant la performance, le prix de vente ou la consommation (un avion rentable est un avion qui vole). Le temps que le remplaçant arrive à rivaliser avec son prédécesseur, lorsqu'on voit les déboires de conception rencontrés depuis les années 2000 par les avionneurs est, à mon avis, ce qui explique pourquoi personne n'a encore dégainé pour proposer le remplaçant de son best-seller.
Notre école aussi a été dotée d'une mallette de 14 tablettes Android sans aucune concertation, résultat, personne ne s'en sert ! Parlez-moi de gaspillage d'argent public !
Idem dans ma commune. L'école avait demandé à être équipée de plus de TBI (toutes les salles n'en ont pas, les autres doivent se partager des vidéoprojecteurs portables, lorsqu'il y en a de disponibles).
L'inspection académique a réussi à convaincre la mairie que ce sont des tablettes qu'il fallait acheter. Et là encore, personne ne s'en sert !
Le jour où l'on demandera leur avis à ceux qui utilisent le matériel…
Je te comprends. Je fais partie de ceux qui font télé-étudier leurs étudiants via Teams, Zoom et compagnie. Autant de solutions libres, sécurisées et soucieuses de la vie privée.
On a lancé un sondage auprès de nos étudiants sur leurs conditions de télétravail. Ce qui ressort, sans parler des problèmes purement techniques, c'est que ce n'est pas toujours simple d'avoir un environnement adéquat pour travailler dans son lieu de confinement.
Un petit florilège des remontées reçues :
enfants en bas âge, ambiance bruyante
maman assistante maternelle
enfermement dans un petit appartement en centre d'une grande ville
pas de bureau, doit travailler dans le salon
habitué au wifi de l'école, n'a pas pris de box chez lui
frère tromboniste qui pratique près de 5h par jours
voisin qui s’entraîne à la trompette qu'il ne sait pas jouer
connexion internet insuffisante pour que 5 personnes concernées par des cours en visio puisse suivre leur cours correctement en même temps
Je télétravaille quand ça fonctionne (assez souvent en fait).
Je fais télétravailler mes étudiants (quand il arrivent à se connecter, mais surtout à mettre en place un environnement adéquat…)
Mais ce qui me prend le plus de temps, c'est de faire télétravailler mes propres enfants.
C'est sympa l'école à la maison, mais ça prend du temps. Heureusement qu'on est deux pour s'en occuper. Comment font les parents seuls ? Sérieusement ? J'ai l'impression qu'ils ont à passer plus de temps sur l'ordinateur que moi pour faire tout ce qu'on attend d'eux. Il faut quasiment cinq ordinateurs à la maison pour s'en sortir.
Et je ne me plains pas, on a un jardin, et il a fait beau presque tous les jours pendant les deux premières semaines de confinement.
Difficile de comparer G'MIC et Photoshop, le premier est une bibliothèque de fonctions (et un peu plus que ça, on est d'accord), alors que le second est un environnement complet de gestion de photos.
Photoshop propose des fonctions puissantes avec un très bonne intégration et gère des choses pas très utiles au commun des mortels, mais indispensables pour certains professionnels (par exemple, la gestion fine des profiles de couleurs selon la destination de la production).
Il faudrait sans doute le comparer avec Gimp ou Krita. Gimp a une ergonomie qui historiquement a été assez clivante, mais qui aujourd'hui converge vers quelque chose d'assez homogène et abouti. De nombreuses lacunes pour un usage professionnel ont été comblées au fur et à mesure des versions. Il bénéficie d'une très bonne visibilité, d'une grande communauté de contributeurs, mais aussi d'utilisateurs. L'existence d'une boîte à outils telle directement accessible depuis GIMP que G'MIC en est un bel exemple. Mais cela va plus loin puisque des fonctions comme le coloriage intelligent sont maintenant directement intégrées dans le logiciel. Merci GREYC !
Krita, historiquement cantonné à l'univers KDE a connu pas mal d'engouement grâce à une stratégie de collaboration entre des artistes et des développeurs. Ces derniers essayant de comprendre au mieux les difficultés des premiers et essayant d'y répondre au mieux. Voir notamment le blog de David Revoy ou les articles publiés précédemment sur LinuxFr. G'MIC est aujourd’hui utilisable également directement dans Krita.
Photoshop est-il mieux ? À chacun de voir selon ses besoins, ses contraintes, son portefeuille, sa philosophie… En tous cas, les solutions intéressantes ne manquent pas, et il y a jamais eu autant d'alternatives alléchantes qu'aujourd'hui. Et encore, on n'a pas effleuré tout ce qui se fait dans des domaines connexes (comme par exemple Darktable, Hugin, RawTherapee, Inkscape, Scribus, etc, etc).
Tu as raison, je pensais qu'il était court, mais finalement, en le rejouant, j'ai découvert ce qu'il y a derrière le rocher…
Et comme toi, j'ai eu un bug avec grep. Mais je ne sais pas si ce n'est pas moi qui ait mis le bazar dans la bibliothèque en y déplaçant un dragon… Bref, histoire à creuser. Je verrai ça une autre fois, car on a vite fait d'y passer un peu de temps.
Mais, bravo d'autant plus aux concepteurs.
NB : il reste encore quelques passages non traduits. J'aurais bien envie de m'y pencher si je trouve un peu de temps.
Merci pour le rappel du C-u devant le C-c C-l, qui permet d'accéder directement aux système de fichiers. Je ne m'en souvenais plus, et c'est vrai que c'est bien pratique à l'usage. Car la plupart du temps, je fais des liens entre mes fichiers Org. C'est assez rare que je pointe vers autre chose (sachant que pour les URL Internet, il suffit de les taper en clair, puis de faire un C-c C-l pour leur ajouter un titre…).
On peut aussi utiliser la syntaxe avec les [[][]], mais ces symboles sont tellement pénibles à taper sur un clavier AZERTY (et je trouve que c'est encore pire sur un Mac), que je préfère essayer de retenir le raccourcis : C-u, C-u, C-u, C-u, …
C'est clair que Karnaugh ne donne pas toujours la solution optimale.
Un exemple que je donne en exercice à mes étudiants est la réalisation d'un circuit comparateur n-bits. Je leur fais d'abord faire un comparateur 2-bits en synthétisant les sorties à l'aide d'une table de Karnaugh. Dans un second temps, je leur fais faire un simple comparateur 1-bit, et on cherche comment fabriquer la version 2-bits en en combinant deux ensemble.
En comparant les deux solutions, on voit que la deuxième approche est à la fois meilleure pour minimiser le nombre de portes utilisées et en terme de profondeur de circuit (nombre de portes traversées entre l'entrée et la sortie dans le pire cas).
Moralité : Karnaugh fournit une forme normale disjonctive (en mathématiques du collège on dirait, la forme développée réduite d'une équation). Ça ne garantie en rien qu'il n'existe pas de meilleure solution par ailleurs.
À vrai dire, le plus difficile dans ce type de cours, c'est de parler de "comparateur deux bits" sans déclencher un rire général dans la classe :-)
Par contre je ne comprends pas le concept de plier une table de vérité pour en faire un objet en deux dimensions, vu que c'est déjà un objet en deux dimensions.
Une table de vérité classique se représente sous forme de tableau à une entrée (sous forme de colonnes, généralement), une table de Karnaugh est une table à deux entrées (lignes et colonnes). Une ligne dans une table de vérité correspondra à une case dans la table de Karnaugh.
Exemple : une fonction à quatre atomes se représente soit sous la forme d'une table de vérité à lignes, soit sous la forme d'une table de Karnaugh de taille . On retrouve exactement le même nombre d'information. Mais l'organisation des lignes et des colonnes a la propriété suivante : le passage entre deux lignes adjacentes doit produire le changement d'un et un seul atome à la fois. De même pour les colonnes. Et on considère que les lignes extrêmes sont également adjacentes (de même que les colonnes). D'où l'aspect circulaire, ou cylindrique de la représentation.
Il existe plusieurs manière de disposer les atomes sur les lignes et les colonnes. Une des manière de faire est d'utiliser le binaire réfléchi ou code de Gray : 000, 001, 011, 010, 110, 111, 101, 100, etc. Si on observe bien ces nombres, un seul chiffre varie lorsqu'on passe d'un nombre au suivant. La propriété nécessaire aux tables de Karnaugh est donc bien vérifiée.
L'avantage de cette disposition, c'est qu'elle permet de visualiser plus simplement l'influence de la variation d'une seule variable à la fois, ce qui peut conduire à des simplifications de l'expression.
Détecter, dans ce cas, tous les mauvais usage d'un type variant à la compilation n'est pas une chose difficile : c'est le principe même du type checking, tâche qui incombe au compilateur dans les langages à typage statique.
Je pense que que pour ce type de vérifications, il faut activer d'autres mécanismes du langage, comme par exemple le sous-typage et polymorphisme qui permettent de distinguer des objets spécialisés dans différents contextes. Du coup, la non-vérification d'un contrat (utiliser un attribut spécialisé alors qu'on a une référence sur le type général) sera explicitement traquée par le compilateur et signalée comme erreur, comme dans n'importe quel langage objet.
Sur un simple enregistrement variant, l'information n'est pas portée avec le type dans la signature d'une fonction. Je peux comprendre qu'on puisse préférer que le compilateur refuse tout simplement de compiler lorsque la vérification est hors de portée. Cependant, Ada laisse toujours pour chaque mécanisme du langage le choix à l'utilisateur de décider s'il souhaite en avoir les avantages (expressivité, sécurité) mais aussi les inconvénients (complexité, interopérabilité, impact de performance, etc).
Par exemple, dans le cas de Ada objet, on peut choisir d'activer séparément différents mécanismes :
- de l'encapsulation (avec les PACKAGES)
- de l'héritage (avec l'utilisation de types dérivés : TYPE ... IS NEW ...)
- de l'extension de type (avec les types TAGGED PRIVATE)
- du polymorphisme (type ACCESS Object'Class)
Alors Ada est-il le meilleur langage objet pour autant ? Ce n'est pas mon avis, car on a vite fit d'écrire beaucoup de code pour faire des choses qui s'exprimeraient de manière beaucoup plus concise dans bien d'autres langages. Mais, peu de langages permettent une distinction aussi fine de ces mécanismes. Ça peut avoir éventuellement une vertu pédagogique : je pense que quiconque maîtrise l'objet en Ada, dispose de la maîtrise de tous les concepts nécessaires pour appréhender rapidement n'importe quel langage objet.
Oups, désolé, je ne sais plus comment on a réussi à dériver d'une discussion qui par du compilateur Haskell pour finir par parler des langages objets. Toute mes excuses pour des propos qui auraient pu être interprétés comme blasphématoires dans ce fil de discussion de conviction plutôt fonctionnelle.
Il y a quelque chose que j'aime bien appuyer lorsque j'enseigne les tables de Karnaugh, c'est l'utilité des termes de recouvrement. Car, souvent, on dit qu'il suffit de s'arrêter lorsque tous les '1' sont couverts. Ce qui est juste, et ce qui permet d'exprimer l'équation en forme normale disjonctive (FND).
Sauf que si les groupes de '1' sont disjoint, le système peut connaître une instabilité lorsqu'on passe de l'un à l'autre de ces groupes. Imaginez que notre implémentation de porte NON ait une légère latence lors du basculement de son entrée, alors l'expression booléenne pourrait valoir faux pendant un court instant lorsque passe de vrai à faux.
De même la fonction booléenne pourrait être instable lorsque passe de vrai à faux. Mais si on rajoute le terme de recouvrement , la fonction reste vraie, même lorsque varie. Et ce qui est bien avec Karnaugh, c'est que le recouvrement est très visuel.
Parfois, je présente ça à mes étudiants en faisant l'analogie avec un assemblage hyperstatique en mécanique (faut dire aussi, que j'enseigne dans une école de mécanique). Pourquoi une chaise a-t-elle généralement quatre pieds, alors bien que trois points suffisent à faire une liaison avec le plan du sol ? Une chaise à trois pieds, c'est certes isostatique, mais dans la pratique, c'est plus casse-gueule ! Donc, il existe des cas dans lesquels on est prêt à payer le coût de l'hyperstaticité (un pied de chaise en plus, c'est pas gratuit), et même de ses inconvénients (ça sera forcément bancal).
Mais, quand même, on est plus serein quand on s'assoit dessus :-)
D'une manière générale, le principe du typage statique se situe dans la question : comment refuser d'exécuter un code qui plantera nécessairement ? ou plutôt, comment savoir qu'un bout de code plantera nécessairement avant de le lancer ?
Pour répondre au coup du Warning plutôt que de l'erreur pour le non respect du RANGE : Ada dispose d'une option pour forcer les Warning en Erreurs. Alors pourquoi laisser le choix ? Peut-être parce que le programmeur est un être libre :-) Non, blague à part, supposons que je souhaite écrire un test de couverture de code, car je m'interface avec un code en C qui ne dispose pas de ces vérifications de typage. Peut-être que cette option me facilitera l'écriture de mon cas de test.
Dans le cas de l'attribut qui n'existe pas selon le discriminant, il n'y aura même pas de Waring à la compilation. Uniquement une Erreur au Runtime. Ça me semble difficile de détecter tous les mauvais usages d'un type variant, surtout si on peut récupérer le record depuis un contexte extérieur (non-Ada). Il faut bien que ça plante quelque part, au niveau de l'interface, si on fait de la programmation par contrat, ou plus loin dans le code si on ne teste pas à l'entrée.
Après, on est d'accord, plus le compilateur englobe d'informations, plus il pourra nous aider à trouver les erreurs dans le code, voire dans sa sémantique. Mais si cette question était si simple, tout le monde coderait en COQ ! Comme ça tout serait toujours syntaxiquement et sémantiquement correct. Sauf que, si ce n'est pas le cas dans la pratique, c'est qu'il y a tout un tas de bonnes raisons de ne pas toujours le faire.
Haskell représente certainement un très bon compromis sur cette échelle, bien que lorsqu'on pousse le curseur un peu loin, le noyau de codeurs, aptes à comprendre de quoi il retourne, se réduit à peau de chagrin (cf. multiples discussions ci-dessus).
Ada, de son côté, a plein de limites, mais il a quand même été retenu pour bon nombre de projets dans des domaines tout à fait sérieux, et son système de typage (certes moins riche que celui de Haskell) n'y est sans doute pas étranger.
Beaucoup de choses entrent en ligne de compte lorsqu'on choisit un langage. Haskell et Ada sont sans doute de très bons candidats, chacun dans leur domaine d'excellence.
Il n'y a pas de garantie statique sur ce genre de chose ? Ça c'est dommage.
J'ai l'impression qu'on navigue à la frontière entre le rôle du compilateur et celui de l'analyseur de statique de code.
MaPolitique:=(NombreFixe,0);-- Warning: "Constraint Error will be raised at Runtime"
Ada le fait dans une certaine mesure comme dans la ligne ci-dessus. Pour des choses plus complexes, il faut donc faire appel à d'autres outils.
Une des forces d'Ada est l'obligation de conformité (ACATS) des compilateurs. Cela participe sans doute au succès d'Ada pour des usages critiques. Mais c'est parfois aussi un point faible, en terme de disponibilité rapide d'un compilateur lors de la sortie d'un nouveau hardware. Il faudrait voir quel impact une telle complexification du compilateur aurait sur ce processus de validation, que peu de langages s'imposent.
Un avantage de la solution Ada est que l'ensemble des tests au runtime peuvent être activés ou désactivés avec un simple pragma si on choisit de privilégier la performance. Je ne connais pas assez Haskell pour dire si ce type de modularité est possible avec les solutions proposées dans les commentaires.
Déjà, je me permets de renvoyer vers un excellent commentaire sur ton journal… Le mien :D
Désolé Blackknight, je n'avais pas lu le journal à l'origine de la dépêche. Mon exemple est effectivement plutôt redondant avec le tien. Mais ça fait toujours plaisir de voir d'autres personnes coder en Ada. On se sent moins seul !
Lorsque l'on ne précise pas de discriminant par défaut, le type est immuable de facto
C'est vrai que j'ai passé sous silence le cas immuable, parce qu'un variant immuable, bon ben… en fait ça ne varie plus trop (blague, pas taper svp).
Mais je reconnais que lorsqu'on code en Haskell, on a plutôt le réflexe de l'immuabilité, comme souvent avec les langages fonctionnels.
Par rapport à ton exemple, je pense qu'ADA propose également des solutions robustes du point de vu typage (et c'est un peu l'objectif de ce langage…).
Le code
WITHAda.Text_IO;USEAda.Text_IO;PROCEDUREVariantISTYPEPolitiqueThreadCaseIS(NombreFixe,NombreMaximumHardware,PasDeThreading,CasParticulier);TYPEPolitiqueThread(Politique: PolitiqueThreadCase:=PasDeThreading)IS-- valeur par défaut obligatoireRECORDCASEPolitiqueISWHENNombreFixe=>NombreThread:Positive;-- alias pour : Integer RANGE 1..Integer'LastWHENOTHERS=>NULL;ENDCASE;END RECORD;PROCEDURETestPolitique(Pol: INPolitiqueThread)ISBEGINCASE(Pol.Politique)ISWHENNombreFixe=>Put_Line("Nombre fixé à"&Integer'Image(Pol.NombreThread));WHENNombreMaximumHardware=>Put_Line("Fait chauffer la ferme de calcul");WHENPasDeThreading=>Put_Line("Plutôt tranquille");WHENCasParticulier=>Put_Line("Celui-ci je ne l'aime pas");ENDCASE;ENDTestPolitique;MaPolitique:PolitiqueThread;BEGINTestPolitique(MaPolitique);-- Par défaut : PasDeThreadingMaPolitique:=(NombreFixe,8);TestPolitique(MaPolitique);MaPolitique:=(Politique=>NombreMaximumHardware);TestPolitique(MaPolitique);MaPolitique:=(Politique=>CasParticulier);TestPolitique(MaPolitique);MaPolitique:=(NombreFixe,0);-- Warning: "Constraint Error will be raised at Runtime"EXCEPTIONWHENCONSTRAINT_ERROR=>Put_Line("n est trop bizarre...");ENDVariant;
Le résultat
Plutôt tranquille
Nombre fixé à 8
Fait chauffer la ferme de calcul
Celui-ci je ne l'aime pas
n est trop bizarre...
Exceptions
Donc, ça permet de gérer automatiquement le cas d'une valeur négative. Ada permet d'ajouter très simplement des tests au Runtime avec l'option RANGE. Très utile pour les tableaux également. Si l'on souhaite privilégier la performance, il est aussi possible de compiler en désactivant ces tests à l'exécution :
pragmaSuppress(Range_Check);
On a droit également à une exception si on tente d'accéder ou de modifier un champ alors que le discriminant n'est pas le bon :
The shell's name is an acronym for Bourne-again shell, punning on the name of the Bourne shell that it replaces and on the term "born again" that denotes spiritual rebirth in contemporary American Christianity.
# Morts aux ORM, vive ELM
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Écrire une appli web en une journée avec SQLPage. Évalué à 6.
Merci pour cet article très intéressant. Je me suis posé récemment le même type de questions en cherchant un backend léger et sûr (du point de vue typage) pour des frontends écrits en Elm. Et en étudiant des architectures de backend, j'avais l'impression qu'entre la BD et la partie ORM du backend, il y a souvent beaucoup de redite.
Je suis alors tombé sur des projets (l'un en haskell) PostgREST et (l'autre en JS) Graphile, selon que l'on préfère les architectures REST ou GraphQL.
Je ne connaissais pas cette solution purement SQL, mais je trouve intéressant d'explorer les capacités de gestion des données directement par le SGBD, plutôt qu'en faisant (ou refaisant) les choses côté backend. Forcément, l'approche a ses limites : il faut souvent recourir à des notions de workers ou autre pour certaines actions… Mais le SGBD est bien souvent capable de réaliser des optimisations difficilement envisageables avec une couche ORM, pour peu qu'on décrive précisément ce qu'on souhaite faire.
J'apprécie beaucoup le côté déclaratif de SQL, qui sous-traite (généralement de manière assez efficace) au moteur du SGBD le soin de trouver le meilleur schéma d'exécution. Et, quand ce n'est pas le cas, c'est une très bonne occasion de se poser quelques questions sur la représentation/normalisation de nos données, et de réfléchir à l'utilité de créer tel ou tel index, vue matérialisée, etc.
Bref, quel est alors le lien avec le langage Elm, aucun, sinon un jeu de mot franco-anglophone qui me démangeait pour le titre de mon commentaire.
[^] # Re: Ada corse le tout
Posté par gerfaut83 (site web personnel) . En réponse au journal Calendrier de l'Avent du code. Évalué à 1.
Ça me rappelle de bons souvenirs !
J'avais pensé à une solution assez efficace à l'aide de la fonction
rotatede la deque Python.[^] # Re: LGBTTQQIAAPO
Posté par gerfaut83 (site web personnel) . En réponse au journal Acronymes incrémentaux. Évalué à 3.
Je trouve le Others assez paradoxal.
Est-ce offensant d'être catégorisé dans Others ou non ?
Car si on trouve ça offensant, alors pourquoi le mettre dans un acronyme ?
Si le but de l'acronyme est de recenser exhaustivement toute personne se définissant comme non hétérosexuelle, et si on pousse le raisonnement dans ses retranchements, alors pourquoi pas utiliser simplement Others ?
Parce que là, on est sûr d'être exhaustif (ça me rappelle les "CASE statements" en Ada…)
Mais c'est compliqué, car à dire Others, on glisse facilement sur le terrain du normatif et de la discrimination (et pourquoi ça serait eux les autres ?).
Bref, vouloir faire des catégories avec ce qui au départ sont surtout "des personnes" est toujours complexe et un poil casse-gueule !
[^] # Re: A propos du Boeing 737.
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 6.
Je pense que ce ne sont pas les salariés d'Airbus membre du bureau d'étude, qui ont fait les frais des principaux plans de restructuration/compétitivité/licenciement (rayez les mentions inutiles) de ces 25 dernières années, qui te contrediront…
Il faut aussi prendre en compte que la durée de vie d'un programme avion dépasse de loin celle d'une voiture, par exemple (pour ne pas parler de celle d'un smartphone…).
Un avion prend environ 5 à 10 ans pour sa conception, il est présent au catalogue pendant plus de 30 ans (depuis 1988 pour l'A320, beaucoup plus pour le B737, mais il a tellement changé que ce n'est plus le même avion qu'au début, sauf pour les autorités de certification américaines !!), et ensuite il peut encore voler pendant 25 à 30 ans (soit environ 100 000 cycles de décollage-atterrissage) dans des compagnies à peu près sérieuses (paradoxalement, les compagnies qui ont les flottes les plus jeunes sont les low-cost, car elles les font voler vraiment souvent!). Et on n'évoque pas ici une éventuelle seconde vie dans des pays beaucoup moins à cheval sur les réglementations !
Les premiers ingénieurs en chef de l'A320 sont à la retraite depuis un bon moment (programme lancé officiellement en 1984).
De manière plus générale, la transmission et la conservation du savoir et du savoir-faire en entreprise est un vrai défi.
Après, ça dépend un peu de la culture d'entreprise. Aux États-Unis, la grande mobilité (subie ?) des salariée fait que c'est beaucoup moins choquant de se séparer de tout son bureau d'étude lorsqu'on a rien en prévision. C'est en partie ce qui a permis à l'avionneur brésilien Embraer de débaucher quelques très bons ingénieurs à la fin du programme de développement du B777 pour attaquer le segment des avions monocouloirs de plus de 100 passagers, sur lequel il n'était pas encore présent.
Ça a tellement bien fonctionner qu'en 2018, Boeing s'est lancé dans le rachat d'Embraer pour plus de 4 milliards de dollars (à moins que ce ne soit pour copier Airbus qui venait de reprendre les monocouloirs CSeries du canadien Bombardier), avant de finalement renoncer en 2020, suite à ses déboires financiers (737-Max + Covid-19)…
[^] # Re: A propos du Boeing 737.
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Bogues de logiciel et bogues de management : 737 Max et autres catastrophes. Évalué à 10.
Je suis assez d'accord avec cette analyse.
Si à la fois Airbus et Boeing ont choisi la re-motorisation à la re-conception complète d'un avion, c'est d'abord parce qu'ils se marquent à la culotte, et ensuite parce que même si des technologies récentes permettent de faire des progrès sur le papier, il n'a pas encore été démontré qu'on savait le faire d'un point de vue industriellement rentable…
Airbus a introduit la plupart de ses nouveautés (du point de vue systèmes notamment) sur l'A380. Ils pouvaient se le permettre à l'époque, car au moment du lancement de l'A3XX c'était moins tendu économiquement, et l'avion devait représenter le savoir-faire d'Airbus pour l'avion du XXIème siècle. Les compagnies (certaines, du moins), était prêtes à payer pour un avion de tous les superlatifs (salon-bar, cabines "Première" avec douches privatives…).
L'A380 a pourtant lutté durant tout son (long) développement et sa (courte) carrière avec un problème de sur-poids. Les premiers modèles livrés étaient tellement loin du poids vendu par les commerciaux et tellement en retard qu'Airbus a dû payer des compensations énormes aux premières compagnies livrées.
Aux alentours de 2010, j'avais entendu par des infos internes qu'Airbus estimait que le nombre d'A380 à vendre pour amortir le développement ne serait jamais atteint (et à l'époque, ils ne projetaient pas d'arrêter la chaîne en 2020…).
Ce ne fut pas un échec complet, car l'A380 a permis à l'A350 de bénéficier d'énormément de développements, réutilisés tels quels, ou presque, là où Boeing a connu bien plus de déboires avec son B787 Dreamliner, qui a été parfois été rebaptisé Nightmareliner.
Sauf que l'A350 et le B787 ont eux aussi connu les difficultés rencontrées par l'A380 : non-respect des objectifs de coût, de masse et de délai. En grande partie à cause de l'introduction des composites (l'A380 en avait déjà un peu), encore une fois sur-vendue du point de vue des économies réalisables par les commerciaux d'Airbus et de Boeing. Dans l'industrie, on peut rarement chiffrer les économies en faisant A - B, surtout lorsque B a une forte influence sur A… Et la structure composite a eu une forte influence sur énormément de choses.
Pareil pour les systèmes : une autre des principales difficultés venait de l'augmentation du nombre de systèmes électrique, qui exigeait un redimensionnement des systèmes de refroidissement, qui à leur tour avaient un impact sur la consommation électrique et le poids…
D'évidence, loger toute ces technologies dans le format d'un A320 ou d'un B737 ne s'annonce pas simple du tout. Et je pense que ça effraye les deux constructeurs. Car se louper sur l'avion qui assure la majeure partie de la trésorerie de l'entreprise représente un risque économique bien plus élevé que de se louper sur des avions qui représentent beaucoup moins de volume (Boeing la démontré avec la crise du 737-Max).
La plupart des analystes annoncent que ces avions verront le jour lorsqu'il y aura une véritable rupture technologique (principalement au niveau moteur) qui justifiera une re-conception complète, en abaissant le coût opérationnel de manière bien plus significative que ce qu'un A320-Neo ou qu'un 737-Max peut proposer aujourd'hui.
Pourquoi ? Parce que le premier concurrent du remplaçant de l'A320 sera … l'A320, un avion optimisé jusque dans ses derniers retranchements depuis 30 ans, re-motorisé de surcroît, qui a fini par atteindre un taux de disponibilité opérationnel extrêmement élevé (idem pour Boeing, avant l'arrivée du Max). Et cet indicateur (surtout depuis l’essor des compagnies à bas-coût) est considéré en priorité par les compagnies, même avant la performance, le prix de vente ou la consommation (un avion rentable est un avion qui vole). Le temps que le remplaçant arrive à rivaliser avec son prédécesseur, lorsqu'on voit les déboires de conception rencontrés depuis les années 2000 par les avionneurs est, à mon avis, ce qui explique pourquoi personne n'a encore dégainé pour proposer le remplaçant de son best-seller.
[^] # Re: Le libre dans des grosses communes ?
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Interview de Laurent, instituteur et libriste. Évalué à 2.
Idem dans ma commune. L'école avait demandé à être équipée de plus de TBI (toutes les salles n'en ont pas, les autres doivent se partager des vidéoprojecteurs portables, lorsqu'il y en a de disponibles).
L'inspection académique a réussi à convaincre la mairie que ce sont des tablettes qu'il fallait acheter. Et là encore, personne ne s'en sert !
Le jour où l'on demandera leur avis à ceux qui utilisent le matériel…
[^] # Re: Par définition…
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Une mise en cause infondée de logiciels libres dans une affaire de fausses factures ?. Évalué à 2.
Tu sous-entends que tout le monde ne le ferait pas ?!
# Par définition…
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Une mise en cause infondée de logiciels libres dans une affaire de fausses factures ?. Évalué à 8.
C'est dans la nature même du libre.
La FSF affirme que la liberté 0 d'une licence libre c'est :
Sans doute que si la personne avait voulu frauder avec un logiciel propriétaire, elle aurait enfreint le CLUF.
Donc, finalement, elle n'a pas eu d'autre choix que de frauder avec du logiciel libre.
CQFD.
[^] # Re: Je télé-étudie
Posté par gerfaut83 (site web personnel) . En réponse au sondage Ce que je fais ou à quoi je pense pendant le confinement. Évalué à 9.
Je te comprends. Je fais partie de ceux qui font télé-étudier leurs étudiants via Teams, Zoom et compagnie. Autant de solutions libres, sécurisées et soucieuses de la vie privée.
On a lancé un sondage auprès de nos étudiants sur leurs conditions de télétravail. Ce qui ressort, sans parler des problèmes purement techniques, c'est que ce n'est pas toujours simple d'avoir un environnement adéquat pour travailler dans son lieu de confinement.
Un petit florilège des remontées reçues :
Bref, ce n'est pas toujours simple !
# Et qui fait télétravailler ses enfants ?
Posté par gerfaut83 (site web personnel) . En réponse au sondage Ce que je fais ou à quoi je pense pendant le confinement. Évalué à 7.
Je télétravaille quand ça fonctionne (assez souvent en fait).
Je fais télétravailler mes étudiants (quand il arrivent à se connecter, mais surtout à mettre en place un environnement adéquat…)
Mais ce qui me prend le plus de temps, c'est de faire télétravailler mes propres enfants.
C'est sympa l'école à la maison, mais ça prend du temps. Heureusement qu'on est deux pour s'en occuper. Comment font les parents seuls ? Sérieusement ? J'ai l'impression qu'ils ont à passer plus de temps sur l'ordinateur que moi pour faire tout ce qu'on attend d'eux. Il faut quasiment cinq ordinateurs à la maison pour s'en sortir.
Et je ne me plains pas, on a un jardin, et il a fait beau presque tous les jours pendant les deux premières semaines de confinement.
[^] # Re: Note de Comparaison avec Photoshop
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche G’MIC 2.7.0 : Une rentrée pleine de style pour le traitement d’images !. Évalué à 5.
Difficile de comparer G'MIC et Photoshop, le premier est une bibliothèque de fonctions (et un peu plus que ça, on est d'accord), alors que le second est un environnement complet de gestion de photos.
Photoshop propose des fonctions puissantes avec un très bonne intégration et gère des choses pas très utiles au commun des mortels, mais indispensables pour certains professionnels (par exemple, la gestion fine des profiles de couleurs selon la destination de la production).
Il faudrait sans doute le comparer avec Gimp ou Krita. Gimp a une ergonomie qui historiquement a été assez clivante, mais qui aujourd'hui converge vers quelque chose d'assez homogène et abouti. De nombreuses lacunes pour un usage professionnel ont été comblées au fur et à mesure des versions. Il bénéficie d'une très bonne visibilité, d'une grande communauté de contributeurs, mais aussi d'utilisateurs. L'existence d'une boîte à outils telle directement accessible depuis GIMP que G'MIC en est un bel exemple. Mais cela va plus loin puisque des fonctions comme le coloriage intelligent sont maintenant directement intégrées dans le logiciel. Merci GREYC !
Krita, historiquement cantonné à l'univers KDE a connu pas mal d'engouement grâce à une stratégie de collaboration entre des artistes et des développeurs. Ces derniers essayant de comprendre au mieux les difficultés des premiers et essayant d'y répondre au mieux. Voir notamment le blog de David Revoy ou les articles publiés précédemment sur LinuxFr. G'MIC est aujourd’hui utilisable également directement dans Krita.
Photoshop est-il mieux ? À chacun de voir selon ses besoins, ses contraintes, son portefeuille, sa philosophie… En tous cas, les solutions intéressantes ne manquent pas, et il y a jamais eu autant d'alternatives alléchantes qu'aujourd'hui. Et encore, on n'a pas effleuré tout ce qui se fait dans des domaines connexes (comme par exemple Darktable, Hugin, RawTherapee, Inkscape, Scribus, etc, etc).
[^] # Re: Merci pour ce travail
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Terminus : un jeu d’aventure pour apprendre à utiliser la ligne de commande. Évalué à 2.
Tu as raison, je pensais qu'il était court, mais finalement, en le rejouant, j'ai découvert ce qu'il y a derrière le rocher…
Et comme toi, j'ai eu un bug avec grep. Mais je ne sais pas si ce n'est pas moi qui ait mis le bazar dans la bibliothèque en y déplaçant un dragon… Bref, histoire à creuser. Je verrai ça une autre fois, car on a vite fait d'y passer un peu de temps.
Mais, bravo d'autant plus aux concepteurs.
NB : il reste encore quelques passages non traduits. J'aurais bien envie de m'y pencher si je trouve un peu de temps.
[^] # Re: Merci pour ce travail
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Terminus : un jeu d’aventure pour apprendre à utiliser la ligne de commande. Évalué à 3.
Pareil pour ma part. J'ai déjà mis un lien dans mon cours !
Dommage qu'il soit court, on aurait bien joué plus longtemps. Peut-être que ça donnera des idées à de futurs contributeurs.
Merci pour cette dépêche. On découvre vraiment plein de choses sur LinuxFR !
[^] # Re: C'est assez clair !
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 9.
Tu risques d'être en concurrence, je crois que Le Robert et Larousse sont aussi sur le coup !
# Merci
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Org-mode 3/5 : des liens et des images dans vos notes. Évalué à 2.
Merci pour le rappel du C-u devant le C-c C-l, qui permet d'accéder directement aux système de fichiers. Je ne m'en souvenais plus, et c'est vrai que c'est bien pratique à l'usage. Car la plupart du temps, je fais des liens entre mes fichiers Org. C'est assez rare que je pointe vers autre chose (sachant que pour les URL Internet, il suffit de les taper en clair, puis de faire un C-c C-l pour leur ajouter un titre…).
On peut aussi utiliser la syntaxe avec les
[[][]], mais ces symboles sont tellement pénibles à taper sur un clavier AZERTY (et je trouve que c'est encore pire sur un Mac), que je préfère essayer de retenir le raccourcis : C-u, C-u, C-u, C-u, …[^] # Re: Rarement suffisant
Posté par gerfaut83 (site web personnel) . En réponse au journal À quoi sert un tableau de Karnaugh ?. Évalué à 7.
C'est clair que Karnaugh ne donne pas toujours la solution optimale.
Un exemple que je donne en exercice à mes étudiants est la réalisation d'un circuit comparateur n-bits. Je leur fais d'abord faire un comparateur 2-bits en synthétisant les sorties à l'aide d'une table de Karnaugh. Dans un second temps, je leur fais faire un simple comparateur 1-bit, et on cherche comment fabriquer la version 2-bits en en combinant deux ensemble.
En comparant les deux solutions, on voit que la deuxième approche est à la fois meilleure pour minimiser le nombre de portes utilisées et en terme de profondeur de circuit (nombre de portes traversées entre l'entrée et la sortie dans le pire cas).
Moralité : Karnaugh fournit une forme normale disjonctive (en mathématiques du collège on dirait, la forme développée réduite d'une équation). Ça ne garantie en rien qu'il n'existe pas de meilleure solution par ailleurs.
À vrai dire, le plus difficile dans ce type de cours, c'est de parler de "comparateur deux bits" sans déclencher un rire général dans la classe :-)
[^] # Re: Qu'est-ce ?
Posté par gerfaut83 (site web personnel) . En réponse au journal À quoi sert un tableau de Karnaugh ?. Évalué à 7.
Une table de vérité classique se représente sous forme de tableau à une entrée (sous forme de colonnes, généralement), une table de Karnaugh est une table à deux entrées (lignes et colonnes). Une ligne dans une table de vérité correspondra à une case dans la table de Karnaugh.
Exemple : une fonction à quatre atomes
se représente soit sous la forme d'une table de vérité à 
lignes, soit sous la forme d'une table de Karnaugh de taille 
. On retrouve exactement le même nombre d'information. Mais l'organisation des lignes et des colonnes a la propriété suivante : le passage entre deux lignes adjacentes doit produire le changement d'un et un seul atome à la fois. De même pour les colonnes. Et on considère que les lignes extrêmes sont également adjacentes (de même que les colonnes). D'où l'aspect circulaire, ou cylindrique de la représentation.
Il existe plusieurs manière de disposer les atomes sur les lignes et les colonnes. Une des manière de faire est d'utiliser le binaire réfléchi ou code de Gray : 000, 001, 011, 010, 110, 111, 101, 100, etc. Si on observe bien ces nombres, un seul chiffre varie lorsqu'on passe d'un nombre au suivant. La propriété nécessaire aux tables de Karnaugh est donc bien vérifiée.
L'avantage de cette disposition, c'est qu'elle permet de visualiser plus simplement l'influence de la variation d'une seule variable à la fois, ce qui peut conduire à des simplifications de l'expression.
[^] # Re: Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 1.
Je pense que que pour ce type de vérifications, il faut activer d'autres mécanismes du langage, comme par exemple le sous-typage et polymorphisme qui permettent de distinguer des objets spécialisés dans différents contextes. Du coup, la non-vérification d'un contrat (utiliser un attribut spécialisé alors qu'on a une référence sur le type général) sera explicitement traquée par le compilateur et signalée comme erreur, comme dans n'importe quel langage objet.
Sur un simple enregistrement variant, l'information n'est pas portée avec le type dans la signature d'une fonction. Je peux comprendre qu'on puisse préférer que le compilateur refuse tout simplement de compiler lorsque la vérification est hors de portée. Cependant, Ada laisse toujours pour chaque mécanisme du langage le choix à l'utilisateur de décider s'il souhaite en avoir les avantages (expressivité, sécurité) mais aussi les inconvénients (complexité, interopérabilité, impact de performance, etc).
Par exemple, dans le cas de Ada objet, on peut choisir d'activer séparément différents mécanismes :
- de l'encapsulation (avec les
PACKAGES)- de l'héritage (avec l'utilisation de types dérivés :
TYPE ... IS NEW ...)- de l'extension de type (avec les types
TAGGED PRIVATE)- du polymorphisme (type
ACCESS Object'Class)Alors Ada est-il le meilleur langage objet pour autant ? Ce n'est pas mon avis, car on a vite fit d'écrire beaucoup de code pour faire des choses qui s'exprimeraient de manière beaucoup plus concise dans bien d'autres langages. Mais, peu de langages permettent une distinction aussi fine de ces mécanismes. Ça peut avoir éventuellement une vertu pédagogique : je pense que quiconque maîtrise l'objet en Ada, dispose de la maîtrise de tous les concepts nécessaires pour appréhender rapidement n'importe quel langage objet.
Oups, désolé, je ne sais plus comment on a réussi à dériver d'une discussion qui par du compilateur Haskell pour finir par parler des langages objets. Toute mes excuses pour des propos qui auraient pu être interprétés comme blasphématoires dans ce fil de discussion de conviction plutôt fonctionnelle.
[^] # Re: Top
Posté par gerfaut83 (site web personnel) . En réponse au journal Sortie de matplotlib 2.0. Évalué à 2.
Idem, j'ai trouvé la vidéo très intéressante, au-delà même du contexte de Matplotlib.
Merci pour le lien.
# De l'utilité des termes recouvrement
Posté par gerfaut83 (site web personnel) . En réponse au journal À quoi sert un tableau de Karnaugh ?. Évalué à 7.
Il y a quelque chose que j'aime bien appuyer lorsque j'enseigne les tables de Karnaugh, c'est l'utilité des termes de recouvrement. Car, souvent, on dit qu'il suffit de s'arrêter lorsque tous les '1' sont couverts. Ce qui est juste, et ce qui permet d'exprimer l'équation en forme normale disjonctive (FND).
Sauf que si les groupes de '1' sont disjoint, le système peut connaître une instabilité lorsqu'on passe de l'un à l'autre de ces groupes. Imaginez que notre implémentation de porte NON ait une légère latence lors du basculement de son entrée, alors l'expression booléenne
pourrait valoir faux pendant un court instant lorsque 
passe de vrai à faux.
De même la fonction booléenne
pourrait être instable lorsque 
passe de vrai à faux. Mais si on rajoute le terme de recouvrement 
, la fonction reste vraie, même lorsque 
varie. Et ce qui est bien avec Karnaugh, c'est que le recouvrement est très visuel.
Parfois, je présente ça à mes étudiants en faisant l'analogie avec un assemblage hyperstatique en mécanique (faut dire aussi, que j'enseigne dans une école de mécanique). Pourquoi une chaise a-t-elle généralement quatre pieds, alors bien que trois points suffisent à faire une liaison avec le plan du sol ? Une chaise à trois pieds, c'est certes isostatique, mais dans la pratique, c'est plus casse-gueule ! Donc, il existe des cas dans lesquels on est prêt à payer le coût de l'hyperstaticité (un pied de chaise en plus, c'est pas gratuit), et même de ses inconvénients (ça sera forcément bancal).
Mais, quand même, on est plus serein quand on s'assoit dessus :-)
[^] # Re: Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 3.
Pour répondre au coup du Warning plutôt que de l'erreur pour le non respect du RANGE : Ada dispose d'une option pour forcer les Warning en Erreurs. Alors pourquoi laisser le choix ? Peut-être parce que le programmeur est un être libre :-) Non, blague à part, supposons que je souhaite écrire un test de couverture de code, car je m'interface avec un code en C qui ne dispose pas de ces vérifications de typage. Peut-être que cette option me facilitera l'écriture de mon cas de test.
Dans le cas de l'attribut qui n'existe pas selon le discriminant, il n'y aura même pas de Waring à la compilation. Uniquement une Erreur au Runtime. Ça me semble difficile de détecter tous les mauvais usages d'un type variant, surtout si on peut récupérer le
recorddepuis un contexte extérieur (non-Ada). Il faut bien que ça plante quelque part, au niveau de l'interface, si on fait de la programmation par contrat, ou plus loin dans le code si on ne teste pas à l'entrée.Après, on est d'accord, plus le compilateur englobe d'informations, plus il pourra nous aider à trouver les erreurs dans le code, voire dans sa sémantique. Mais si cette question était si simple, tout le monde coderait en COQ ! Comme ça tout serait toujours syntaxiquement et sémantiquement correct. Sauf que, si ce n'est pas le cas dans la pratique, c'est qu'il y a tout un tas de bonnes raisons de ne pas toujours le faire.
Haskell représente certainement un très bon compromis sur cette échelle, bien que lorsqu'on pousse le curseur un peu loin, le noyau de codeurs, aptes à comprendre de quoi il retourne, se réduit à peau de chagrin (cf. multiples discussions ci-dessus).
Ada, de son côté, a plein de limites, mais il a quand même été retenu pour bon nombre de projets dans des domaines tout à fait sérieux, et son système de typage (certes moins riche que celui de Haskell) n'y est sans doute pas étranger.
Beaucoup de choses entrent en ligne de compte lorsqu'on choisit un langage. Haskell et Ada sont sans doute de très bons candidats, chacun dans leur domaine d'excellence.
[^] # Re: Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 1.
J'ai l'impression qu'on navigue à la frontière entre le rôle du compilateur et celui de l'analyseur de statique de code.
Ada le fait dans une certaine mesure comme dans la ligne ci-dessus. Pour des choses plus complexes, il faut donc faire appel à d'autres outils.
Une des forces d'Ada est l'obligation de conformité (ACATS) des compilateurs. Cela participe sans doute au succès d'Ada pour des usages critiques. Mais c'est parfois aussi un point faible, en terme de disponibilité rapide d'un compilateur lors de la sortie d'un nouveau hardware. Il faudrait voir quel impact une telle complexification du compilateur aurait sur ce processus de validation, que peu de langages s'imposent.
Un avantage de la solution Ada est que l'ensemble des tests au runtime peuvent être activés ou désactivés avec un simple
pragmasi on choisit de privilégier la performance. Je ne connais pas assez Haskell pour dire si ce type de modularité est possible avec les solutions proposées dans les commentaires.[^] # Re: Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 1.
Désolé Blackknight, je n'avais pas lu le journal à l'origine de la dépêche. Mon exemple est effectivement plutôt redondant avec le tien. Mais ça fait toujours plaisir de voir d'autres personnes coder en Ada. On se sent moins seul !
C'est vrai que j'ai passé sous silence le cas immuable, parce qu'un variant immuable, bon ben… en fait ça ne varie plus trop (blague, pas taper svp).
Mais je reconnais que lorsqu'on code en Haskell, on a plutôt le réflexe de l'immuabilité, comme souvent avec les langages fonctionnels.
# Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 7.
Par rapport à ton exemple, je pense qu'ADA propose également des solutions robustes du point de vu typage (et c'est un peu l'objectif de ce langage…).
Le code
Le résultat
Exceptions
Donc, ça permet de gérer automatiquement le cas d'une valeur négative. Ada permet d'ajouter très simplement des tests au Runtime avec l'option RANGE. Très utile pour les tableaux également. Si l'on souhaite privilégier la performance, il est aussi possible de compiler en désactivant ces tests à l'exécution :
On a droit également à une exception si on tente d'accéder ou de modifier un champ alors que le discriminant n'est pas le bon :
La solution Ada est comme souvent un peu verbeuse, mais garde une bonne lisibilité.
[^] # Re: #WhatWouldTimblDo
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche #WhatWouldTimblDo : nouvelle campagne de la FSF contre les DRM sur le Web. Évalué à 2.
Visiblement, la référence était non pertinente ou trop peu connue…
What Would Brian Boitano Do? :
Bash :