Blackknight a écrit 1244 commentaires

Qu'est ce qui empêche de sérialiser vers du XML ou vers une ribambelle de formats de sérializations tout aussi bizarres les uns que les autres ?

C'est clair que c'est pas ce qui manque les formats, binaires ou pas d'ailleurs :)
En plus, y en a même des normalisés comme XDR.

NdM : en 2009, le réseau interne de la Marine française, Intramar, a été contaminé par le virus Conflicker, laissant des Rafale « cloués au sol » faute d'avoir pu « télécharger leurs paramètres de vol » (source Blog Secret défense et journal LinuxFr sur ce sujet). Et toujours en 2009, les drones Predator américains relayaient leurs vidéos au sol sans aucun chiffrement (source WSJ).

Ben, contaminé certes mais ça n'a pas empêché les avions de voler.

[Ce blog est aujourd'hui (8/2/09) en mesure de confirmer l'essentiel des informations d'Intelligence Online. Toutefois, selon nos sources, il apparait que les Rafale de la Marine n'ont pas été concernés directement par ces ennuis informatiques.]

C'est d'ailleurs le même site qui le dit. Du coup, c'est moins sensationnel :D

Je ne vois pas où est la subtilité. Quand il s'agit de manipuler différentes classes, on fait un template, quand on cherche à spécialisé une classe on fait de l'héritage.

Oui effectivement, en réfléchissant à un exemple, je me demande si j'ai pas dit une connerie :D
Donc, j'en ai bien un mais bon, il est bof.
J'ai une classe qui permet de gérer des configurations sous forme de dépôt. Les configurations étant différentes, elles héritent toutes d'un même comportement issu d'une configuration abstraite, Configuration.
Si je veux stocker les configurations par type, je peux soit :
- Définir un dépôt abstrait Depot et le dériver pour chacune des sous-classes de Configuration (méthode Java avant l'introduction des génériques et classique des cours de POO)
- Définir le dépôt comme étant générique et instancier ce générique par sous-classe de Configuration

Mais bon, ok, c'est bof ;)

Non, je parlais du fait général de compiler les génériques/templates (et de comprendre/expliquer leur comportement) en remplaçant l'instantiation d'une template par son code

Oui, les generics sont effectivement assez compliqués à mettre en oeuvre. Un exemple "rigolo", c'est l'instanciation successive de trois génériques pour obtenir une matrice de complexes donc les composantes sont des réels (cf ARM). Ca donne un truc comme ça :

package Complex_type is new Ada.Numerics.Generic_Complex_Types(Short_Float);
use Complex_type;
package Real_Arrays is new Ada.Numerics.Generic_Real_Arrays(Short_Float);
use Real_Arrays;
package Complex_Arrays is new Ada.Numerics.Generic_Complex_Arrays(Real_Arrays, Complex_type);

au lieu de pouvoir raisonner de façon plus légère sur des fonctions polymorphes

C'est la grande bataille entre faire du pur objet en utilisant héritage, surdéfinition et faire du template. Quand utiliser quoi ? D'ailleurs, je trouve les templates plus complexes à manipuler, quelque soit le langage, qu'un graphe d'héritage

comment définir des génériques ou leurs instances localement, en profondeur dans la définition d'une fonction ?

Je vois pas la difficulté là, hormis syntaxique. Un bloc declare suffit normalement. Je dois pas avoir compris ce que tu voulais dire :)

Ada ne permet pas la spécialisation conditionnelle dont tu parles. Peut-être tant mieux, car ça rend la fonctionnalité drôlement compliquée, ce qui n'est pas terrible pour un langage orienté sûreté;

Tout à fait d'accord. Personnellement, je trouve la méta-programmation assez compliquée à manipuler et j'ai déjà assez de problèmes comme ça à coder sans :D

Non, je parlais bien de switch/case sur les chaînes de caractères, ce qui est hautement casse-gueule à mon avis.
Par contre, le switch/case sur autres choses, ça ne me fait pas peur tant que le quelque chose est de type discret.

Tout à fait d'accord avec toi, je n'y vois pas énormément d'intérêt. Ceci dit, on peut faire un truc assez cool, c'est de faire un case sur une énumération après avoir tenté de récupérer la valeur d'énumération dans une chaîne avec

procedure Get(Item : out Enum);

Bon, ok, c'est pas terrible... Non, c'est carrément nul mais faisable :D

(Mais oui Ada n'est pas la panacée; par exemple la généricité par spécialisation est très lourde à utiliser, on aurait envie d'une forme plus simple de polymorphisme paramétrique.)

La généricité déjà est lourde mais quand tu parles de généricité par spécialisation, tu parles bien de ça qu'on trouve en C++ ?
Si c'est le cas, je savais même pas qu'on pouvait le faire en Ada

Par contre, c'est vrai, il n'y a effectivement rien sur les cases avec chaines de caractères. Ada n'est pas la panacée ou l'El Dorado des langages, on peut pas tout avoir non plus :D

Au risque de me répéter : Ada où tout type discret peut servir.

Parce que sinon en effet aucun langages ne l'est vraiment!

Ca y est, c'est trop tard, t'as marché dedans ! ;)

multiplateforme c'est avec les os susnommés.

On est bien d'accord

Arrêtes, j'étais sûr d'être en week-end ce soir... Ça me déprime :D

Toi, t'as pas lu http://linuxfr.org/users/rewind/journaux/votre-langage-ideal sinon tu saurais que c'est pas multi-plateforme le C++ :D

Les porteurs, ça court les rues, c'est bien connu!

Ben vu le nombre de lib natives qu'embarque ton jeu, il doit bien en exister quelques uns quand même...

Je n'ai (malheureusement) jamais touché à ADA.

Franchement, le gap, pour un programmeur C/C++ qui aurait idéalement fait un peu de Pascal, est franchement très petit. D'ailleurs, il y a deux docs sympas, un en français pour introduction qui s'appelle "cours Ada95 pour le programmeur C++" et un en anglais, plus ancien mais toujours valable (merci la normalisation) sous le titre "Ada-95: A guide for C and C++ programmers". Enfin, c'est pas la doc qui manque !! :)

mais les énumérations de Java m'ont l'air d'avoir les même caractéristiques. Et je trouve en effet que c'est de loin bien meilleur que ce que propose le C++.

La différence avec Java, c'est que les énumérations sont natives du langage. En Java, c'est plus du sucre syntaxique à base d'instances statiques mais c'est toujours ça de pris et ça remplit bien la fonction demandée.

Les choses comme JML ou ce qui semble être ajouté à ADA 2012 m'ont l'air nettement plus pertinent que de ce limiter à un système de type. Par exemple

C'est du complément et ça va dans la lignée du langage

Oui, c'est vrai, les interfaces pourraient jouer ce rôle-là.

Ce n'est probablement pas aussi poussé, mais je ne vois pas très bien ce qui est ajouté ou non par ADA.

L'objectif, Michel, l'objectif !! ;)
Comme le dit la page que tu fournis, l'objectif est d'accélérer la construction du projet pas de vérifier la cohérence. Je crois que j'ai déjà donné ce lien plus haut qui te donnera plus d'explications.

En C/C++ tu as déjà une vérification du type (moins forte en C qu'en C++ certes). ADA apporte des vérifications de précondition comme le spécifie JML ?

C/C++ sont déjà des langages à typage fort, Ada fournit un système de typage qui va plus loin en incluant toutes les contraintes de valeurs pour les types simples et les vérifie seul à la compilation quand c'est possible ou en levant une exception au runtime.
Petit exemple tout simple :

procedure Test is

   type MonInt is range 1..5;
   Titi : MonInt := 5;
begin
   Titi := Titi + 1;
end Test;

J'adore le message de warning à la compilation :

fred@freddy:/tmp $ gnatmake test.adb 
gcc-4.4 -c test.adb
test.adb:6:17: warning: value not in range of type "MonInt" defined at line 3
test.adb:6:17: warning: "Constraint_Error" will be raised at run time
gnatbind -x test.ali
gnatlink test.ali
gnatlink: warning: executable name "test" may conflict with shell command

Alors, c'est vrai, l'exemple est simplissime mais dans les cas plus complexes avec énormément de types définis, ce genre d'aide n'est pas négligeable. Tu trouveras tout plein d'infos là si ça t'intéresse.

Ensuite, les énumérations sont de vrais types qui s'utilisent comme tels et on ne peut pas les substituer par leur valeur numérique sans le dire explicitment. D'ailleurs, on n'est pas censé maitriser ce mapping si on ne l'a pas spécifié.
Encore une fois, plutôt que de donner un exemple ridicule, je vais te donner un lien rien qu'à toi :D

Pour finir, je me suis aussi intéressé à JML après avoir vu ce qui se faisait en Spark Ada. Spark est un peu particulier puisque c'est un sous-langage d'Ada qui est très contraignant mais qui décrit bien les invariants, les pré-conditions... Du coup, ça avait l'air tellement bien que ce sera inclus dans la révision 2012 sous la forme définie là. Mais bon, c'est une norme ISO alors ça va prendre encore un peu de temps ;)

Donc il faut demander à tes utilisateurs d'installer des outils de développement

Est-ce si gênant ?

de savoir taper des commandes

Ce serait vrai si on ne savait pas faire d'IHM au-dessus de commandes shell.

et de te taper des Makefile tenant compte des N OS et distributions.

C'est du libre, fais le pour les OS que tu vises et s'il y a une demande pour ton soft sur un OS que tu ne possèdes pas ou ne cible pas, il y aura bien dans la nature un porteur. C'est d'ailleurs ce qui se passe pour une bonne partie des logiciels sous Linux.

De toutes façons, tu auras toujours le problème de la présence ou de l'absence de la machine virtuelle pour l'OS que tu vises. Aujourd'hui, en Java, je n'ai pas machine virtuelle disponible en binaire pour FreeBSD, je suis obligé de recompiler.

Ada, dommage que sa syntaxe rebute tout le monde.. Autrement ça serait une bonne alternative..

Oui c'est dommage parce que ça permet de faire des trucs sympas quand même

type Integer_1 is range 1 .. 10;
type Integer_2 is range 1 .. 10;
A : Integer_1 := 8;
B : Integer_2 := A; -- illegal!

Du coup, sur les appels de fonctions ou procédures, ça permet souvent de lever l’ambiguïté grâce à des types qui ne représentent pas la même chose. Et quand l’ambiguïté ne peut être levée par le type, on peut utiliser les paramètres nommés et ne pas se soucier de l'ordre de ceux-ci :

Phi := Arctan (Y => A, X => B);

est équivalent à

Phi := Arctan (X => B, Y => A);

Ada est verbeux. Je pense que les langages de demain ne doivent plus avoir de header. C'est une erreur, de la duplication de code qui ne sers à rien.

Personnellement, je trouve que les headers ne servent pas à rien et je préfère de loin lire juste un fichier ads (fichier de spec ou header) que de lire le fichier adb (corps ou body). En plus, il ne faut pas oublier qu'en Ada contrairement au C/C++, le fichier de spec se compile au même titre que le corps ce qui permet de vérifier avant tout chose que tout code client d'un autre respecte bien le contrat prévu. Cela permet aussi la vérification de la compatibilité avant que le corps ne soit réellement codé.
En C/C++, le header n'est qu'un fichier comme un autre géré par le macroprocesseur (beurk :D) avec tous les désagréments que cela implique (inclusion d'un .cpp/.c dans un autre header, c'est moche mais je l'ai vu :( ).
En Java, même si j'aime bien ce langage, tout est dans tout et vice-versa, et ça, ça me gêne pas mal quand même... Surtout quand dans ton équipe tu as des spécialistes de la classe de 3000 lignes. Bon, c'est relativisé par l'emploi d'un IDE moderne mais quand même.

Ca marche bien, mais seulement dans le cadre de FreeBSD.

Je pense que c'est juste un choix. Après tout, les ports FreeBSD, ce ne sont que des Makefiles, des fichiers de checksum et des fichiers patch. Il n'y a donc pas grand chose qui puisse empêcher la portabilité d'un tel système, si ce n'est inclure dans le système de base des choses qui n'y sont pas normalement dans une distrib Linux.

Merci pour le lien, pour ça, je plussoie ton commentaire.

Soit il y a une solution viable (soft2 est correct avec la version 1 ou soft1 est correct avec la version 2) et tu peux la forcer. Soit y'a pas de solution à ton problème.

On est d'accord et dans ce cas, on est bien dans la gestion manuelle de la dépendance.

Gère un projet un tant soit peu important avec qui à 10 ans d'historique et on en reparle. De même pour faire un système d'intégration continue, gérer à la main c'est tout réinventer.

Excusez-moi, maître, je ne suis qu'un simple novice. Je ne suis rien face à votre expérience de projet de 10 ans d'historique...
Bon, là, maintenant, tu te calmes, on se connait pas, je sais pas ce que tu fais dans la vraie vie, tu ne sais pas ce que je fais dans la vie (même si c'est pas dur à trouver) alors arrêtes de me prendre de haut parce qu'à part m'énerver, ça sert à rien.

Maven à des milliards des défauts mais la tu reproches un truc qui touche n'importe quel gestionnaire de dépendance.

J'ai jamais dit parlé d'autres gestionnaires, mon garçon. On me parle de Maven, je parle de Maven. Et effectivement, ce que je reproche à Maven, je le reproche aussi aux autres.

Bien sur que si. Si un soft1 en version X dépend d'un soft2 en version Y à Z ce n'est pas du tout la même chose qu'un soft2 en version supérieur à Y. Mais en général tout le monde se fou de faire les dépendances correctement (être strict à aussi des inconvénients) et ca pète à runtime par ce que tu te retrouves avec la version Z. La faute ne revient pas à l'outil mais au mec qui à ecrit le pom.

Mon soft A dépend de soft1 qui dépend de Y en version 1 mais dépend aussi de soft2 qui lui dépend de Y en version 2. Dans mon pom, je ne gère que la dépendance vers soft1 et soft2. Qui est en faute ? Celui qui n'a pas upgradé vers la version 2 ?
Ça, je ne le maitrise pas et c'est juste ça qui me gêne.

T'as exactement les mêmes problèmes pour le faire à la main. Sauf que dans 90% des cas, ca marche très bien avec la version automatique. T'as juste perdu ton temps pour rien.
Non, je n'ai pas perdu mon temps. Je connais ce que j'inclus et je le maîtrise. Trop de dépendances ? Ok, on prend une lib plus légère.

C'est aussi bête que de dire que le boulot fait par les gestionnaires de paquets et les packageurs ne sert à rien. Ca marche mieux pour eux par ce qu'ils construisent une configuration figée.

Désolé mais je vois pas le rapport et je ne crois pas avoir dit quelque chose de la sorte.

Java, Python, Ruby, Perl, PHP... Beaucoup de logiciels libres se basent sur des langages interprétés/bytecompilés. La difficulté de distribuer des binaires compilés n'y est certainement pas étrangère.

Certes mais quoi qu'il arrive, il faut bien un moment où on descend au niveau du binaire compilé dépendant de l'architecture sous-jacente.
Mais il est vrai que de distribuer un .py ou un .pl est plus simple que de trouver un packager qui acceptera de s'assurer que tout marche.

Après n'utiliser que des binaires n'est pas non plus obligatoire, si on prend un système comme FreeBSD, tout est fait pour utiliser les sources et au final, ça marche plutôt bien.

Et t'es sur que c'est pas simplement des pom mal maintenus ? Si la version n+1 pète la compat et qu'un dit log4j >= n et l'autre log4j >= n+1 bha tu te retrouves avec n+1 par ce que c'est ce que les gens qui ont écrit les pom ont demandé... à tord.

Il n'y a pas d'histoire de tord ou de raison. tout le monde n'utilise pas forcément les mêmes versions d'une même bibliothèque. Simplement, Maven n'est pas la panacée et ne résout pas ces problèmes que l'on a aussi en gérant à la main. Cependant, à la main, on maitrise mieux son environnement de développement et on peut peser le pour et le contre d'inclusion de telle ou telle bibliothèque, notamment les problèmes de compatibilité.

Maven c'est une bonne idée; très mal réalisée (la conf est complètement stupide). Mais faut pas l'accuser de n'importe quoi.

Je ne l'accuse pas de n'importe quoi, je dis que c'est juste un outil automatique et comme tout outil automatique, il cache énormément de choses qu'il vaudrait mieux maitriser et qui ne peut résoudre certains problèmes qui sont déjà difficiles à régler pour des humains.

Après le vrai problème; qui existe dans tout les langages mais qui est exacerbé en Java du fait de la réutilisation massive de nombreux composant non inclus dans le runtime, c'est comment avoir deux versions de la même lib en parallèle dans la même appli.

Tout à fait d'accord mais quand tu codes une appli en C/C++, il est quand même rare, me semble-t-il, de lier avec deux versions d'un même composant sans qu'il ne se passe de collision.

Non mais dependency:tree est un outil d'analyse qui marche tout aussi bien que ldd. Il n'empêche absolument pas les conflits d'apparaître.

Au final, ce que je veux dire, c'est que Maven n'est pas la panacée et que passée une certaine taille de projet, on ne maitrise plus la configuration complète de son développement et la multitude de dépendances tirées de droite et de gauche.

Si tu n'as pas le temps d'écrire 36 scripts de cross-compilations et de monter 40 machines virtuelles pour tester tous les environnements, mais que tu veux quand même livrer un projet qui tourne sur le maximum de distributions et même sur quelques OS privateurs, C/C++ est inutilisable.

Voilà, t'as tout compris et heureusement pour nous, les environnements seront bientôt tous codés en Java.

Ou alors tu acceptes de juste distribuer les sources avec un INSTALL_DEMERDEZ_VOUS.txt.

Oui parce que je distribue pas les sources à ceux qui peuvent pas les installer.