Discussion :

[Tommy31]

Qu'est-ce que "la sûreté de typage" si tu construis correctement ton soft ????
Pourquoi en aurais-tu besoin ???

Arrête de troller.
A moins d'assortir le soft d'une batterie de tests qui garantissent une couverte d'exécution totale, tu es toujours à la merci d'une coquille. Si tu le fais c'est bien, mais en général dans un contexte professionnel non contraint par une exigence forte de fiabilité, on mène pas ce genre de tests, c'est trop couteux.

[Tommy31]

L'OOP n'est plus vraiment à la mode (selon moi!). Je veux parler de l'OOP classique à la Java. Ce qui est à la mode, il me semble, c'est une mixture regroupant à la fois des éléments OOP mais aussi des concepts empruntés aux langages fonctionnels. Javascript, Ruby, Scala, Haskell... ça c'est à la mode.

En réalité, ce qui est à la mode c'est l'agilité au travers des :

- langages scriptables dont la plupart s'intègrent ou coopèrent pleinement avec les langages classiques (python, ruby, scala, groovy...).
- langages multi-paradigme. La modélisation s'opère alors dans un hyperespace (fonction, objet, aspect).

Les langages java ou c# sont parfaitement dans cette mouvance.

L'objectif est d'utiliser le bon moyen pour le bon problème.

[souviron34]

Arrête de troller.
A moins d'assortir le soft d'une batterie de tests qui garantissent une couverte d'exécution totale, tu es toujours à la merci d'une coquille. Si tu le fais c'est bien, mais en général dans un contexte professionnel non contraint par une exigence forte de fiabilité, on mène pas ce genre de tests, c'est trop couteux.

Depuis quand fabrique-on un soft sans savoir quelles données on manipule ??

Encore une fois, en théorie c'est sans doute un concept magnifique, mais dans la pratique, peut-être dans les contextes où j'ai travaillé je te l'accorde, mais j'en ai quand même fait pas mal, je n'ai jamais vu de cas où l'on ne savait pas ce qu'on traitait, et par conséquent ne construisais pas le soft ou les structures en en tenant compte..

Je ré-itère (et j'ai été dans des environements professionels à fortes contraintes et exigences de fiabilité) je n'en vois pas l'intérêt pratique..

Et ce n'est pas un troll...

[Tommy31]

Depuis quand fabrique-on un soft sans savoir quelles données on manipule ??

Ce n'est pas ce que j'ai dis. Tu me dis que tu n'as pas besoin de la sureté du typage. Moi je te dis que bien que tu saches ce que tu manipules, si le compilo lui ne le sais pas, il restera muet sur ton intention. Or à moins d'être infaillible, ou de faire des campagnes de tests, tu cours des risques.
Et c'est d'autant plus vrai que le projet est complexe et implique un grand nombre d'intervenants.

Et ce n'est pas un troll...

Je pense que tu es sincère, mais je serais curieux de connaître les clients pour lesquels tu as travaillé. A titre professionnel, j'ai travaillé pour un gros équipementier avionique, pour de l'embarqué, et je peux t'assurer que le typage était un des points sur lesquels aucune transigeance n'était accordée. La couverture des tests aussi d'ailleurs.

[dragonno]

Moi je pense qu'il vaut mieux que le typage soit respecté car on a beau penser qu'on est infaillible et qu'on sait chaque fois comment controler son programme, ce n'est pas ce qui nous protegera d'une erreur humaine, tandis que le langage lui veillera ...

Sinon si ça vous ennuie pas^^ faudrait peut-etre revenir au sujet du débat initial

Et à ce sujet, mon avis c'est qu'en procédural on va déclarer et appeler plusieurs fois des bouts de codes (variables et autres) alors qu'en objets il suffit de faire hériter et voilà^^

[Garulfo]

[...]
Je pense que tu es sincère, mais je serais curieux de connaître les clients pour lesquels tu as travaillé. A titre professionnel, j'ai travaillé pour un gros équipementier avionique, pour de l'embarqué, et je peux t'assurer que le typage était un des points sur lesquels aucune transigeance n'était accordée. La couverture des tests aussi d'ailleurs.

Et bien je pense que vous avez peut-être des clients en commun
En fait vous avez tous les deux raisons. Ce n'est pas en opposition: une bonne architecture tiens compte d'une forme de typage avant la programmation. Mais si on veut ajouter des sécurités on rajoute des typages pendant la programmation. Vous pinaillez tous les deux sur des choses sur lesquelles vous êtes probablement en accord.

Par contre, juste pour précision, tu dois savoir que les couvertures totales de systèmes n'existent pas. Et que si on se limite à des sous-parties, en ayant ainsi la possibilité d'avoir des couvertures totales — Model Checking par exemple — alors il y a aussi d'autre technique qui assure une fiabilité à 100% en fonction de besoin formalisé: les approches par raffinements. À mon avis tu le sais déjà. C'est plus en info pour les autres lecteurs que je dis ça.

[Garulfo]

L'OOP n'est plus vraiment à la mode (selon moi!). Je veux parler de l'OOP classique à la Java. Ce qui est à la mode, il me semble, c'est une mixture regroupant à la fois des éléments OOP mais aussi des concepts empruntés aux langages fonctionnels. Javascript, Ruby, Scala, Haskell... ça c'est à la mode.
Bien sûr, être à la mode n'implique pas être utilisé à grande échelle dans une variété de domaines différents.
A part peut être pour Javascript actuellement, les langages les plus utilisés à un instant donné ne sont jamais à la mode

Ce qui est à la mode — dans le sens le plus employé et le plus encensé dans l'industrie — c'est toujours l'OO. Le prochain qui sera à la mode sera probablement l'OA.

Sinon je suis très conscient du phénomène d'osmose venant des langages fonctionnels. D'abord parce que ça fait des années que je prédis ça et après parce que j'en suis profondément heureux. Mais on est très loin d'une utilisation prononcé de ces langages. Finalement, classer Haskell dans les langages objets avec un peu de concepts empruntés aux fonctionnels c'est quand même osé

[Tommy31]

Bref, Garulfo l'a très bien dit : dans un cas on se penche vers les données, de l'autre vers les fonctionalités... L'une n'est pas plus simple de l'autre. Tout dépend du cadre : 3 fonctionalités à 30 objets sera (sans doute) plus simple en objet. 30 fonctionalités à 3 objets sera sans doute plus simple en procédural..

C'est justement ca qui est définitivement avantageux en objet, tu t'adapte au point de vue qui sied le mieux. Dans les architectures logicielles actuelles, en multi-tiers, le modèle de données est une construction objet anémique, qui ne contient aucune fonctionnalité. Et l'ensemble du référentiel fonctionnel est portée par une couche service.
Dans le paradigme aspect, c'est exactement la même démarche. Tu capture les éléments par entités de type procédure, objet ou aspect selon ce qui est le plus approprié.

[alex_pi]

Depuis quand fabrique-on un soft sans savoir quelles données on manipule ??

Justement, toute l'idée du typage est là. Si on sait bien quelles données on manipule, et si le système de type est assez expressif, on peut facilement expliquer au compilo quelles sont ces données, et lui demander de vérifier qu'on n'a pas fait une boulette (par exemple une faute de frappe, ou une modification en amont qui pervertirait le code en aval). Un "bon" système de type ne devrait pas restreindre une "bonne" programmation. Si l'idée qu'on a de ce que l'on fait est correcte, le système de type devrait l'accepter sans râler. Il n'est pas là pour brimer le programmeur, mais pour l'aider à ne pas tomber dans le ravin. C'est un garde fou, par un rail.

Pour parler au physicien qui est en toi, un système d'unité n'est pas seulement quelque chose de "joli en théorie", c'est quelque chose d'indispensable à la pratique du physicien. Quand on écrit une formule, si les unités sont incohérentes, on *sait* qu'on a fait une bêtise, que ça ne pourra pas marcher. Donc si on a "quelque chose" (par exemple un thésard :p) qui reprends nos formule une par une et vérifie que les unités sont tout le temps cohérente, ce n'est pas une contrainte, c'est une sécurité complémentaire. Personne n'est à l'abri d'avoir oublié un hbar quelque part dans une grosse formule. C'est pareil quand on écrit un gros programme. On n'est jamais à l'abri d'une typo, d'une erreur de copier coller, etc. Le système de type est là pour nous en protéger. C'est parfaitement pragmatique et pas du tout une lubie de théoricien.

Et pour revenir au sujet initial, le modèle objet apporte une forme de souplesse au système de type (j'entends par souplesse quelque chose qui permet d'accepter plus de programme correct tout en maintenant une "sécurité de typage") en autorisant à manipuler une donnée sans en connaitre son type exact, mais juste un "sur type". Par exemple, ça permet de manipuler une "figure" sans nécessairement savoir si c'est un carré ou un cercle. Cette souplesse permet entre autre d'expliquer au compilo ce que l'on est en train de faire ("je sais que je manipule une figure en général, vérifie juste que ce que je fais est cohérent"), ce qui limite les risques d'erreur.

C'est cette souplesse qui permet d'écrire des éléments de codes (des "librairies") de façons génériques (puisqu'elles ont besoin de connaitre qu'un sous ensemble des propriété des données qu'elles manipulent), le tout de façon bien typé pour éviter les erreurs. Et qui dit généricité dit réutilisabilité.


En espérant avoir été productif, non trollesque, et vaguement dans le sujet.


PS : pour revenir aux unité, le langage F# permet justement d'écrire des formules avec des unités et de demander au compilo de vérifier qu'on ne s'est pas planté ! Et bien plus encore

[Jimalexp]

Si j'ai bien compris la problématique du typage, c'est ce qui serais à l'origine des "generics" en Java 1.5 avec une notation du genre ArrayList<Dog> dogList (en opposition avec la déclaration pre-Java 1.5 ArrayList dogList). C'est pratique du moment qu'on ne souhaite pas travailler avec des couplets.

Ce qui amène une petite question. Dans le contexte de la gestion avec un langage objet qui ne supporte pas ce genre de possibilité, est-ce qu'on effectues des tests sur l'objet recupéré et ce pour en déterminer sa nature ? Ou part t-on de l'idée que le logiciel a été bien conçu d'avance ?

[Garulfo]

C'est justement ca qui est définitivement avantageux en objet, tu t'adapte au point de vue qui sied le mieux. Dans les architectures logicielles actuelles, en multi-tiers, le modèle de données est une construction objet anémique, qui ne contient aucune fonctionnalité. Et l'ensemble du référentiel fonctionnel est portée par une couche service.
Dans le paradigme aspect, c'est exactement la même démarche. Tu capture les éléments par entités de type procédure, objet ou aspect selon ce qui est le plus approprié.

C'est un point de vue qui n'est pas partagé par tous les « experts ». Notamment les nouveaux prophètes de l'OA disent que l'OO a complètement raté cette partie là d'où l'importance de l'OA.

Grammatici certant et adhuc sub judice lis est (l'ai-je déjà dit ?)

[Garulfo]

Si j'ai bien compris la problématique du typage, c'est ce qui serais à l'origine des "generics" en Java 1.5 avec une notation du genre ArrayList<Dog> dogList (en opposition avec la déclaration pre-Java 1.5 ArrayList dogList). C'est pratique du moment qu'on ne souhaite pas travailler avec des couplets.

Ce qui amène une petite question. Dans le contexte de la gestion avec un langage objet qui ne supporte pas ce genre de possibilité, est-ce qu'on effectues des tests sur l'objet recupéré et ce pour en déterminer sa nature ? Ou part t-on de l'idée que le logiciel a été bien conçu d'avance ?

Tout dépend de l'application est du niveau de confiance que tu dois avoir pour l'utiliser. Dans les cas les plus parano, même avec des langages « sûrs » (on note les guillemets merci), on fera aucune présupposition comme celle que tu poses: on retestera et revérifiera autant que possible.

Si tu veux parler de système dont le typage est sûr, tu n'es pas bon avec Java de toute façon. Ocaml, Ada et Haskell par exemple sont des bons candidats. Peut-être les seuls dans les « grands » langages en fait.

[Garulfo]

[...]
PS : pour revenir aux unité, le langage F# permet justement d'écrire des formules avec des unités et de demander au compilo de vérifier qu'on ne s'est pas planté ! Et bien plus encore

Tiens... vas-tu te reconvertir vers F# ? Ou LLB t'a-t-il engagé ?

[souviron34]

Je ne répondrai que sur un seul point, car ça me fatigue....

Moi je te dis que bien que tu saches ce que tu manipules, si le compilo lui ne le sais pas, il restera muet sur ton intention. Or à moins d'être infaillible, ou de faire des campagnes de tests, tu cours des risques.
Et c'est d'autant plus vrai que le projet est complexe et implique un grand nombre d'intervenants.

Moi je pense qu'il vaut mieux que le typage soit respecté car on a beau penser qu'on est infaillible et qu'on sait chaque fois comment controler son programme, ce n'est pas ce qui nous protegera d'une erreur humaine, tandis que le langage lui veillera ...

Justement, toute l'idée du typage est là. Si on sait bien quelles données on manipule, et si le système de type est assez expressif, on peut facilement expliquer au compilo quelles sont ces données, et lui demander de vérifier qu'on n'a pas fait une boulette (par exemple une faute de frappe, ou une modification en amont qui pervertirait le code en aval). Un "bon" système de type ne devrait pas restreindre une "bonne" programmation. Si l'idée qu'on a de ce que l'on fait est correcte, le système de type devrait l'accepter sans râler. Il n'est pas là pour brimer le programmeur, mais pour l'aider à ne pas tomber dans le ravin. C'est un garde fou, par un rail.

Je crois que vous sous-estimez largement ET la capacité d'analyse des informaticiens en général ET les méthodes de développements trraditionnelles...

http://emmanuel-delahaye.developpez....-codage-c/#LVI

Je répète que, avec un compilateur bien réglé (ce qui se fait dans tout développement sérieux), les problèmes cités n'apparaissent jamais... A la limite à la première compil, si jamais tu as eu la tête en l'air, mais jamais plus tard.

Toute cette argumentation est fallacieuse...

[alex_pi]

Je crois que vous sous-estimez largement ET la capacité d'analyse des informaticiens en général ET les méthodes de développements trraditionnelles...

http://emmanuel-delahaye.developpez....-codage-c/#LVI

Je répète que, avec un compilateur bien réglé (ce qui se fait dans tout développement sérieux), les problèmes cités n'apparaissent jamais... A la limite à la première compil, si jamais tu as eu la tête en l'air, mais jamais plus tard.

Toute cette argumentation est fallacieuse...

Si j'ai en début de code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
typedef struct pObjet {
    int Type ;
    int x  ;
    int y ;
    int width ;
    int height ;
} Objet ;

#define RECT 0
#define ELLIP 1

drawRect(Objet *rect){
  blah rect blah
}

drawEllip(Objet *ellip){
  blah ellip blah
}

C'est quoi l'option de compilation magique qui fait que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void Draw_Enhanced ( Objet *ObjetATracer )
{
    switch ( ObjetATracer->Type )
     {
        case ELLIP ;
               drawEllip(ObjetATracer);
               break ;
         case RECT :
               drawRect(ObjetATracer;
               break ;
     } 
}

compile et que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void Draw_Enhanced ( Objet *ObjetATracer )
{
    switch ( ObjetATracer->Type )
     {
        case ELLIP ;
               drawEllip(ObjetATracer);
               break ;
         case RECT :
               drawEllip(ObjetATracer;
               break ;
     } 
}

échoue ?

[souviron34]

C'est quoi l'option de compilation magique qui fait que
compile et que
échoue ?

Et c'est quoi l'option langage objet qui fait que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Rect
{
  :draw;

  draw() : 
      Draw_Ellip ;
}

Ellip 
  :draw;
  
  draw() :
     Draw_Ellip;
}

T'indique une erreur ??

Les erreurs de copier-coller sont aussi fréquentes en langage objet qu'en procédural...

[dragonno]

Moi je ne suis pas fort en programmation, je dirais même que face à vous je suis moins que rien^^ mais je sais parfaitement une chose, on ne doit et on ne peut jamais être complètement sûr de soi au point de ne mettre aucune sécurité, et c'est ce que tu fais Sauviron.
Et puis on est en discussion pas besoin de dire que ça te fatigue
N'oublie pas que le but de ce topic est une discussion donc chacun donne son avis et je comprend que basé sur ton expérience et peut-etre ton âge tu sois fatigué par nos avis contraires, mais je le répète on discute c'est tout, en tous cas moi je ne cherche pas à te convaincre, je donne juste mon avis

[souviron34]

Moi je ne suis pas fort en programmation, je dirais même que face à vous je suis moins que rien^^ mais je sais parfaitement une chose, on ne doit et on ne peut jamais être complètement sûr de soi au point de ne mettre aucune sécurité, et c'est ce que tu fais Sauviron.

Je ne mets pas "aucune sécurité" et je ne me sens pas plus sûr de moi qu'un autre.

Je dis juste que l'argument du "le langage objet contrôle les typages" et "les langages procéduraux ne peuvent pas être sûrs à cause de ça" avec les exemples donnés n'est pas un argument valable dans la vraie vie.

Et que la sécurité/le manque de sécurité de typage peut s'obtenir dans n'importe quel langage et développement...

Sinon nous n'aurions jamais eu les hommes sur la Lune, Ariane, des avions, des ordis, des téléphones portables, etc etc....

[dragonno]

Et que la sécurité/le manque de sécurité de typage peut s'obtenir dans n'importe quel langage et développement...

Oui ça je suis d'accord avec toi

Mais bon ce n'est pas seulement sur le programmeur qu'il faut compter c'est ce que je dis moi, et à mon point de vue de débutant je vois le langage objet aussi typé et sécurisé que le langage procédural, c'est là où la qualité du programmeur fait la différence, mais on ne doit pas compter que sur la qualité du programmeur de façon générale quoi^^

Mais c'est quand que le sujet initial sera retrouvé sinon au juste ?
je parle là pour les prochains intervenants, car ça m'interesse ce sujet^^

[gorgonite]

a priori, je dirai qu'ici les deux échouent... sans doute une erreur de c/c

peux-tu mettre en gras les différences dans les deux codes ?