Discussion :

[Alp]

tant que tu n'as pas appris à les lire, ils sont horribles

Tu mets le doigt sur le problème. La mode aujourd'hui pour les développeurs c'est d'avoir le beurre et l'argent du beurre... D'avoir la simplicité de développement sans se prendre la tête à apprendre des choses

[Goten]

Dans ce cas autant changer de métier :/

[Alp]

Dans ce cas autant changer de métier :/

Hélas, je vois vraiment beaucoup de gens qui sont comme ça, aujourd'hui. Après on demande pas aux gens d'avoir le niveau de Abrahams & compagnie, mais un minimum quoi...

[MenshaKaine]

Après j'ai bien compris que sur le marché français, les templates c'est considéré comme étant une technologie expérimentale risquée. Si la France a réputation d'avoir 10 ans de retard en développement et en génie logiciel, ce n'est pas pour rien...

J'aime beaucoup ton message. Et je suis fortement d'accord avec la citation au dessus car je l'ai expérimenté lors de la majorité de mes entretiens.

Après je ne pense pas qu'on arrivera à trouver une réponse synthétique à la question de cette discussion.

De mon côté je m'intéresse autant à la technique qu'à la conception. Les deux sont pour moi très importante dans notre métier.


ps: Et pour l'histoire du public, je suis d'accord, on conçoit au cas par cas les classes. C'est juste que cette expérience m'avait choqué: on pouvait à la fin remplacer partout class par struct !

[Invité]

La programmation à base de copier/coller, franchement, je crois qu'on fait difficilement pire.

C'est juste un slogan, ça... Un #include, l'utilisation d'une librairie externe, un patch, une gestion de version, c'est quoi, sinon un copier-coller?

Sur les messages d'erreur, il me semble qu'on ne peut à la fois vanter le fait que le C++, grâce à la généricité, rend le code plus concis et élégant (et donc facile à maintenir), mais en même temps trouver normaux les affreux messages des templates, qui rendent la mise au point de ce code très désagréable. Mais bon, c'est l'affaire de quelques versions de compilateurs, je pense. Je me souviens d'un temps où les messages d'erreur des compilateurs C étaient presque toujours incompréhensibles...

Francois

[Issam_Lahlali]

C'est bien plus vaste que ça, mais bon...
Dans ces domaines là, tu ne penses pas que la couche "métier", c'est autre chose que ce que tu dis ? Encore une fois, je fais référence à la première correction que j'ai faite sur ton terme "métier". Pour moi, le métier, c'est justement ce qui est primordial, ce qui ne va pas forcément être récupérable à l'extérieur. Dans ce cas, c'est quoi l'utilité de faire une abstraction là-dessus ? Le métier, c'est la plus value de l'application dans l'entreprise, ce n'est pas en passant de MySQL à Oracle que ton entreprise va gagner des millions d'euros, mais en passant d'un algorithme de résolution numérique à un autre, on peut gagner des millions, voire des milliards. Et là, la couche d'abstraction, on s'en fout, on n'en veut pas car on doit rester proche du matériel, tout en étant super haut-niveau.

La seule vision que tu as, c'est la vision informatique de gestion de bureau, mais tu crois sincèrement que c'est tout ce qui existe dans le monde ?

sincèrement on a le même point de vue mais je ne sais pas comment tu comprends mes messages

moi aussi je m'en fout de passer par MySQL ou oracle , et justement comme tu le dis il faut ce concentrer sur la vrai valeur ajoutée ce que je ne cesse de répéter tout le temps.

et je remarque qu'on passe beaucoup de temps en technique plus qu'il ne faut or c'est pas la vrai valeur ajoutée et c'est pour cela que je préconise a chaque fois de faire abstraction a toute complexité technique pour que tout les développeurs se concentre sur le métier.

prenons par exemple le cas StartWith avec std::string, on remarque qu'on l'a pas mais c'est pas ça le probléme, et on l'utilise beaucoup et dans ce cas il faut faire une abstraction a cette méthode et la coder une fois pour toute, au lieu que chacun fait sa propre version et on aura que du copier/coller qui traine.

donc finalement j'ai le même but que toi se concentrer plus sur le métier qui est la vrai valeur ajoutée et pour ça a mon avis il faut simplifier la couche technique pour éviter que tout les développeurs perdent leur temps sur un truc qui n'a pas une grande valeur ajoutée.

[Issam_Lahlali]

Avant de poursuivre dans cette optique, veux-tu bien aller sur cette page, ainsi que sur ce sujet, et lire les documentations de chaque librairie présentée, s'il te plait ?

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme

Code :

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

1
2
3
 
WSADATA WSAData;
WSAStartup(MAKEWORD(2,0), &WSAData);

ou genre

Code :

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

1
2
3
4
5
6
7
8
 
SOCKET sock;
SOCKADDR_IN sin;
sin.sin_addr.s_addr	= inet_addr("127.0.0.1");
sin.sin_family		= AF_INET;
sin.sin_port		= htons(4148);
sock = socket(AF_INET,SOCK_STREAM,0);
bind(sock, (SOCKADDR *)&sin, sizeof(sin));

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

[Matthieu Brucher]

sincèrement on a le même point de vue mais je ne sais pas comment tu comprends mes messages

On a peut-être le même point de vue, mais ça ne se voit pas, la preuve avec le message suivant.

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca exoplique bien les sockets.

mais est ce que tu crois que je vais passer mon temps avec des trucs comme

Code :

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

1
2
3
 
WSADATA WSAData;
WSAStartup(MAKEWORD(2,0), &WSAData);

ou genre

Code :

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

1
2
3
4
5
6
7
8
 
SOCKET sock;
SOCKADDR_IN sin;
sin.sin_addr.s_addr	= inet_addr("127.0.0.1");
sin.sin_family		= AF_INET;
sin.sin_port		= htons(4148);
sock = socket(AF_INET,SOCK_STREAM,0);
bind(sock, (SOCKADDR *)&sin, sizeof(sin));

la première chose que je vais faire est créer une classe très basique qui contient Open, Send , Receive et Close comme ça on cache toute la logique bas niveau et le développement avec les sockets devient un pur bonheur

et on peut généraliser ça sur toute fonctionnalité technique ou on répète les mêmes choses a chaque fois.

Sauf que si une bibliothèque de socket permet cela, c'est qu'il y a une raison. Toi, tu n'en as pas l'utilité en informatique de gestion, mais le gars qui fait une bibliothèque de jeu en aura peut-être l'utilité.
Bref, tu occultes tout l'informatique qui ne te concerne pas et tires des conclusions à côté de la réalité.

[HS]Désolé, je suis énervé à cause d'UPS qui n'est même pas capable de téléphoner quand il y a un problème, ou plutôt si, 6 heures plus tard.[/HS]

[Issam_Lahlali]

On a peut-être le même point de vue, mais ça ne se voit pas, la preuve avec le message suivant.

Sauf que si une bibliothèque de socket permet cela, c'est qu'il y a une raison.

encore une fois une incompréhension je ne veux pas virer la bibliothèque socket ou dire que c'est mal fait.

elle est generique et c'est normale de se taper 10 lignes pour créer une socket, mais il faut pas dire c'est normale et laisser tout les développeurs se taper les 10 lignes ou faire du copier/coller.

il faut leur simplifier la vie de ce point de vue pour ce concentrer sur le métier, et pour cette affaire d'application de gestion mon diplôme de base est en automatique et j'ai travailler sur de gros projet industriels avant de faire d'autres non industriels et en plus non orienté gestion

[Matthieu Brucher]

Alors qu'est-ce qui te pose problème dans Boost.asio ?

[Mac LAK]

prenons par exemple les sockets avec ce cours de ce site http://c.developpez.com/WalrusSock/ qui est trés bien d'ailleurs ca explique bien les sockets.

Ce qui ne répond donc absolument pas à la question que j'ai posée, et montre (par exemple) que tu n'as même pas jeté un oeil sur la librairie ICE...

[loufoque]

C'est juste un slogan, ça... Un #include, l'utilisation d'une librairie externe, un patch, une gestion de version, c'est quoi, sinon un copier-coller?

Un copier/coller, c'est du code dupliqué.
Justement, les macros permettent d'éviter la duplication de code plus que les templates, en faisant le copier/coller à ta place, mais il faut bien savoir décerner ce qu'il faut généraliser, sinon on tombe dans un gros bordel.

À propos de bordel, ce sujet en est un incroyable. On a atteint un nouveau record dans le nombre de pages non ?

[metagoto]

Après j'ai bien compris que sur le marché français, les templates c'est considéré comme étant une technologie expérimentale risquée. Si la France a réputation d'avoir 10 ans de retard en développement et en génie logiciel, ce n'est pas pour rien...

C'est vrai ça, la réputation des 10 ans de retard ?

En tant que simple observateur extérieur, au grès de mes pérégrinations sur le net depuis plusieurs années, j'ai remarqué que les "français" sont forts en maths. Là je parle du très haut niveau. J'ai aussi l'impression qu'ils sont forts en informatique théorique (encore une fois, l'aspect mathématique mais aussi dans des domaines tels que les conséquences des théories quantiques (cryptographie etc)).
Alors comment expliquer cette réputation ? (si se n'est qu'on ne trouve pas un département à la INRIA dans chaque université).

[Mac LAK]

Ce que tu n'as pas l'air de comprendre, c'est que C++ te permet de définir un langage spécifique à un domaine particulier.

Un "langage" ? Tu en as la grammaire ?

Comprends bien quelque chose : oui, c'est possible. Et oui, c'est laid, quoi que tu en dises : c'est difficilement maintenable par rapport à un interpréteur Python "câblé" dans ton programme C++, ou LUA, ou JavaScript, et qui, lui, sera réellement adaptable par ton client sans devoir tout recompiler.

Il aura des fonctions métier, un "bac à sable" ne risquant donc pas de lui péter à la tête et il est totalement affranchi des contraintes techniques et/ou d'une maîtrise importante du langage C++. Je te rappelle que 99% des clients se contrefichent de savoir COMMENT tu l'as réalisé, tant que ça marche bien, que ça répond à leur besoin et qu'ils peuvent faire leur partie métier tranquillement.
Et en terme de temps de développement, je suis loin d'être persuadé que le faire en C++ soit plus rapide que de coupler un interpréteur à une "librairie métier", pour assurer les mêmes fonctionnalités au final.

Parce que quoi que tu fasses, C++ reste compilé, et des fonctions comme "eval()", courantes en langages interprétés (et franchement pratiques), restent impossibles à faire sans appeler un compilateur C++ à la volée...
Et si le but est de réécrire un langage de script à base de templates, autant câbler directement un interpréteur tout prêt : t'as largement plus de chances de ne pas déstabiliser l'utilisateur final en lui faisant apprendre un langage supplémentaire, alors qu'il maîtrise sûrement déjà quelque chose d'approchant (script Python/LUA, Grafcet, etc.).

Encore une fois : ce n'est pas parce qu'un langage permet de faire quelque chose (ou que quelque chose est réalisable avec ce langage) que c'est forcément souhaitable et/ou optimal de le faire. Et C++ n'échappe pas à la règle.

[Issam_Lahlali]

Alors qu'est-ce qui te pose problème dans Boost.asio ?

Ce qui ne répond donc absolument pas à la question que j'ai posée, et montre (par exemple) que tu n'as même pas jeté un oeil sur la librairie ICE...

pour boost.asio voila ce qui confirme ce que je dis http://www.boost.org/doc/libs/1_40_0...ion/server.cpp

ou tu trouve 3 classes ou dans le commentaire on voit bien le mot clé Wrap pour cacher la complexité de l'utilisation et pour simplifier.

ce qui est normal puisque toutes les librairies sont en general generiqe et forcement a un moment on va se taper a chaque fois qlq lignes repetitifs pour un besoin donné et il faut avoir le reflexe d'avoir des wrappers comme dans l'exemple de boost.asio.


mais si on considère que c'est très simple sans passer par wrapper c'est un choix a respecter mais il faut assumer les dégâts du aux Copier/Coller.

[loufoque]

Ce retard dont je parlais c'est dans le privé, et c'est par rapport aux États-Unis (qui est un peu le leader de l'industrie de l'informatique). Le transfert technologique a aussi plus de mal à se faire qu'au Royaume-Uni à cause de la barrière de la langue.

Enfin tout de même, ça dépend vachement des entrerprises. Il y a pas mal qui ont beaucoup de retard, mais certaines en ont relativement peu.

[Mac LAK]

pour boost.asio voila ce qui confirme ce que je dis http://www.boost.org/doc/libs/1_40_0...ion/server.cpp

Et tu n'as donc toujours pas regardé ce que proposait ICE...

[loufoque]

Un "langage" ? Tu en as la grammaire ?

La grammaire, c'est à toi de la créer.
(Enfin il faut qu'elle soit construite au dessus de celle des expressions de C++ quand même)

c'est difficilement maintenable par rapport à un interpréteur Python "câblé" dans ton programme C++, ou LUA, ou JavaScript, et qui, lui, sera réellement adaptable par ton client sans devoir tout recompiler.

Ce sont des besoins différents.
Un DSEL c'est en particulier utilisé pour générer du code performant, en particulier pour la vectorisation, la programmation parallèle, la génération d'un parser...
Un intérpréteur c'est fait pour embarquer un comportement dynamique flexible, c'est totalement différent.

des fonctions comme "eval()", courantes en langages interprétés (et franchement pratiques)

Ce style de programmation est plutôt déconseillé.

[Issam_Lahlali]

Et tu n'as donc toujours pas regardé ce que proposait ICE...

je croyais que j'étais clair lorsque j'ai parler de boost.asio et pour ICE j'en ai déjà fait avant avec TAO dans le cadre de choix d'une solution pour le distribué et ICE c'est pas en doc ou en théorie que j'ai lu , je l'est pratiqué et a chaque fois on essayait de faire l'abstraction dés que possible pour laisser toujours l'utilisation très facile.

et sincerement lorsqu'on lit une doc ou on fait de la theorie c'est pas la meme chose que pratiquer, par exemple pour ICE ou toute solution pour le distribué il y a plusieurs services a prendre en compte :

naming service,event service,notification service, property service, reprise ainsi de suite, et dans ce cas va utiliser les classes de base de ICE ou n'importe quelle autre librairie et je te raconte pas la galère ou tu demandera a tout les développeurs de connaitre toutes les subtilités , par contre dans des projets ou j'ai travailler ou on bosse avec ce type de librairie avec plus que de 100 développeurs je t'assure que juste 4 développeurs qui était concerné par cette librairie et tous les autres il ne savait même pas ce qui se passe derrière, qu'on utilise ICE ou TAO ou Orbacus et c'est très bénéfique.

et encore une fois toute librairie technique est générique et c'est tout a fait normal c'est aux développeurs de créer leur boite a outil autour de ces librairies pour leur besoin pour faciliter le dev.

et autre chose pas toutes les boites ont les compétences ou les connaissances pour choisir la librairie idéale pour leur besoin, sinon cette discussion n'aura pas lieu mais le conseil quelque soit le choix qu'on fait est :
essayer de cacher au maximum toute complexité technique.

[white_tentacle]

Y a quand même un truc où je ne comprends plus rien à la logique de ce que tu racontes.

Tu défends les frameworks "tout faits" façon .NET/Java, qui ne présentent pas de grande difficulté technique.

Mais tu défends le fait qu'il faille wrapper toute librairie utilisée pour masquer sa complexité. Et quand on te répond que s'il faut masquer la complexité de la librairie, c'est probablement parce que la librairie est (au choix) inadaptée ou mal faite, tu t'obstines à défendre le fait qu'il faut la wrapper.

Ça ne te semble pas un peu contradictoire, tout ça ?