Blackknight a écrit 1234 commentaires

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.

Trop gros, passera pas !!
Pour répondre quand même, Maven ne dit rien quand il y a ce conflit. Pour être précis, il s'agit d'un conflit entre plusieurs versions de log4j et c'est le plus fort qui gagne sans que Maven dise quoique ce soit.

C'est dommage, car ça ne correspond pas trop au besoin du libriste amateur qui veut passer le maximum de temps sur le cœur de ses projets et pas sur les problèmes techniques.

Hélas, le développement informatique reste avant tout une activité humaine technique et cela se confirme quand je vois tout ce que Maven a lui seul peut apporter comme problèmes techniques comme l'incompatibilité de versions tirées par deux dépendances différentes.

J'ai pas parlé de cross compilation mais je dirais juste que c'est aussi simple que d'avoir un compilateur croisé Arm sur plate-forme Intel... Donc, c'est pas si facile :D

Mais ça existe ;)
Une petite recherche Google m'a rapporté ça par exemple.

est-ce qu'il est facile d'écrire un programme multiplateforme?

Comme pour un programme Java, il y a des choses où il faut faire attention. Je pense notamment à tout ce qui touche les fichiers (casse prise en compte ou pas, droits d'accès). Globalement, l'Ada Reference Manual spécifie tout ce que doit savoir faire un compilateur Ada quelle que soit la plate-forme pour pouvoir s'appeler compilateur Ada.

est-ce qu'il est facile de déployer un programme multiplateforme? (ie bytecode ou crosscompilation simplissime)

Il semble qu'il soit possible de générer du bytecode Java (voir la doc associée) mais aussi de s'interfacer avec du Java relativement aisément (voir là). Perso, je n'ai pas essayé.

est-ce qu'il existe un outil de gestion des dépendances à la Maven?

Non, inutile de faire deux fois les mêmes bêtises :D
La seule gestion des dépendances que l'on peut avoir, c'est celle fournit par un système de gestion de paquetages de ta distribution :)
Trêve de plaisanterie, le développement Ada s'apparente nettement plus à du développement C/C++ qu'à du développement Java avec ses avantages et ses inconvénients. En clair, tout est à la charge du développeur en termes de dépendances.

Bon, vu que tout le monde a cité le couple C/C++, j'en choisis un autre qui vaut, à mon humble avis, le coup d'oeil et dont on parle rarement, Ada

Un qui soit fait de manière concertée entre plusieurs entreprises, "plusieurs" étant supérieur à 10 minimum, montrant que c'est pas une entreprise dans son coin qui veut faire un truc qu'il jettera quand plus besoin ou qu'il fera évoluer la licence ou l'évolution comme il a envie (Allez, une liste : Go, Rust, Java, C#...)

C'est le cas depuis presque 30 ans.

Un qui passe les organismes les plus connu (genre ISO)

Même remarque qu'au-dessus, sachant en plus qu'il s'agissait du premier langage objet normalisé ANSI/ISO

Un qui ne casse pas la compatibilité au bout de 10 ans, un que je sais que je pourrai compiler le code das 10 ans (pas exemple : Python)

Tu peux normalement compiler ton code Ada83 sans problème avec un bon vieux Gcc d'aujourd'hui.

Un qui soit utilisé par beaucoup de monde

Bon, là, effectivement, c'est sûr que ça pêche. Ceci dit, la communauté est ultra-compétente (voire trop des fois ?) et il est facile d'obtenir un coup de main

Un qui marche autant sur une petite machine qu'une grosse (non, pas de machine virtuelle)

La question ne se pose même pas. C'est quasiment prévu pour :)

Ensuite pour répondre au journal d'origine, les petits suppléments :
- Programmation concurrente normalisée (de bien plus haut niveau que ce qui se fait en Java d'ailleurs)
- Programmation distribuée normalisée
- Interfaçage avec le C/C++, le Java (depuis peu et pas prévu par la norme), le Fortran et le Cobol

Sinon, le sous-typage sans polymorphisme, c'est dedans, les génériques et les interfaces aussi.
Cerise sur le gâteau, Gcc (enfin gnat) est d'une précision redoutable dans ses messages d'erreur à la compilation.

de rin

Il manque la première devroom dans la journée de samedi.
Elle porte sur le serveur Web AWS et est donc une devroom Ada.
Le planning est d'ailleurs accessible ici.
C'eut été dommage de pas la mentionner compte tenu du beau monde présent :)

Et oui, ça fait des années que j'attends mon invitation au bal :D

Sinon, pour les mots qu'on comprends pas, il y a toujours :
- le dictionnaire
- Google
- Wikipedia

Ca évite la dépèche de quinze pages sinon, ça s'appelle plus une dépèche mais un article (cf. les dépèches de l'AFP qui ne font que quelques lignes).

Il est vrai que j'aurais pu donner les liens vers Wikipédia mais je l'ai pas fait, c'est une histoire de goût et de couleurs... Et comme je suis daltonien... :D

Exact, d'ailleurs l'auteur de la news originale en parle aussi et mentionne par la même occasion LPROF.
Donc il y a bien des outils mais les tarifs des colorimètres supportés ne sont pas les mêmes que les 48£ de ColorHug.
Après, il faut voir si la sonde est "fabricable" par le commun des mortels à un tarif plus raisonnable :)

Le problème, avec Free, c'est plutôt qu'ils ont déclaré toutes leurs IP résidentielles comme spammeuses sur une RBL.

Certes mais il me semble Free accepte que l'on utilise ses serveurs comme relais tout pendant que l'on est connecté chez eux.
D'ailleurs, je dis "il me semble" mais si c'était pas le cas, je comprendrais pas bien comme mon Sendmail arrive à envoyer des courriers, qui plus est, sous une identité qui n'est pas en @free.fr.
Après, pour ce qui est de l'IP et du nom de domaine, j'utilise Dyn depuis maintenant quelques années avec beaucoup satisfaction.