Pourquoi la communauté C++ s'intéresse plus à la technique et ignore la conception?

Citation:

---

Envoyé par koala01

On peut, effectivement, déplorer cet état de fait, mais la solution qui consisterait à faire en sorte que la norme du langage (qui n'est absolument pas adaptée à cela) s'attaque à ce problème serait un mal bien pire...

---

j'essaye de suivre ton raisonnement je me demande a quoi sert STL? ça sert a rien d'avoir un standard pour les conteneurs et les algorithmes.

encore une fois on va pas entrer les api de la couche technique dans la norme mais les standardiser sous l'égide de n'importe quel organisation.

voila a mon avis les etapes qu'on peut suivre pour arriver a ca:

- faire une première version de cette spec par les spécialistes.
- commencer a développer des wrappers autour des librairies existantes, soit par les créateur des librairies eux memes, soit par d'autres developpeurs open source( c'est juste une redirection après tout).
- on détecte qu'il y a un manque , on ajoute ce qu'il faut dans la spec et on remodifie les wrappers.

en suivant cette approche le plus gros intérêt est de bénéficier du retour d'un maximum de type de projet c++ et tout le monde va bénéficier des évolutions .

ces spec permettront la possibilité d'avoir des points d'injection pour les cas spécifiques dans des cas ou une librairie a un fonctionnement très spécifique qu'on ne peut pas généraliser.

ce processus va prendre des années mais c'est primordial pour dépasser a terme cette problématique.

ça reste juste une réflexion mais je considère que rien n'est impossible en informatique, il ya juste le facteur Temps a prendre en compte.

Il y a aussi le facteur "objectif", et malgré le fait qu'on te le dise dans presque chaque message, tu omets celui-ci. Une interface spécifique n'a pas forcément d'intérêt dans tous les domaines. Le nivellement par le bas, ça ne sert à rien.

Citation:

---

Envoyé par Matthieu Brucher

Il y a aussi le facteur "objectif", et malgré le fait qu'on te le dise dans presque chaque message, tu omets celui-ci. Une interface spécifique n'a pas forcément d'intérêt dans tous les domaines. Le nivellement par le bas, ça ne sert à rien.

---

alors ce que je comprends dans cette résistance dans les reponses , c'est que depuis des années qu'on développe et on arrive toujours pas a maitriser la couche technique.

si le fait de la maitriser est considéré comme nivellement par le bas , alors je me demande quel terme on peut qualifier le fait de subir cette jungle de librairies :)

et t'a raison j'ai oublier un autre facteur très important, il s'agit de la résistance a tout changement et évolution de la part de la communauté C++, j'ai l'impression que ça avance au ralentit avec aucune volonté d'aller vers le mieux.

a force de faire les choses d'une certaine manière, on croit que c'est la meilleure façon de le faire et on oubli que les débutants ont du mal avec cette jungle.

Citation:

---

Envoyé par Issam_Lahlali

c'est ce cas qui m'intéresse et ça peut concerner database,xml,MOM , gestion des répertoires et fichiers, cryptage et peut être d'autres , pour l'interface graphique ça devient chose impossible.

---

Concernant les bases de données et les systèmes de fichiers, l'existant est tellement hétérogène qu'une telle normalisation va conduire :

• Soit à prendre uniquement ce qui est commun à tous et donc de se priver de possibilité intéressante sur les autres. Ce qui n'est peut être pas gênant dans certains cas mais le sera rapidement dans d'autre (T'imagines-tu avoir une bibliothèque gérant les fichiers sans la notion de répertoire et avec des noms de 6 caractères ?).
• Soit à avoir énormément d'API dont le support est optionnel. Ce qui ne fait que déplacé le problème sans le résoudre.
• Soit à laisser volontairement de côté certains systèmes et/ou fonctionnalité.

Concernant le XML, c'est davantage réalisable, mais

• Si tu souhaites tout supporter (DOM, SAX, Xpath, XSLT, DTD, Schéma, etc.) tu vas obtenir quelque chose d'énorme donc long à réaliser et dont la lourdeur risque d'être rédhibitoire dans plusieurs cas.
• Si tu ne supportes qu'une partie, tu ne couvres pas tous les besoins.

Concernant la cryptographie, c'est un peu le même problème (soit un truc énorme, soit une couverture très partielle) auquel il faut rajouter les problématiques de prise en compte d'algorithmes récents, propriétaire ou d'usage restreint, ainsi que la présence d'algorithme jugé "faible".

Bref, dans le principe avoir une API normalisée unique pour gérer tout cela est certain alléchant, mais c'est malheureusement difficilement faisable.

Citation:

---

Envoyé par Issam_Lahlali

alors ce que je comprends dans cette résistance dans les reponses , c'est que depuis des années qu'on développe et on arrive toujours pas a maitriser la couche technique.

---

Ce qu'on essaie de te faire comprendre, c'est qu'il n'y a pas de manière universelle, dans aucun langage, de faire cette couche technique. Ca dépend du backend, sinon tu dois faire une interface minimaliste avec ce qui est commun à toutes les solutions existantes.

Citation:

---

Envoyé par gl

Bref, dans le principe avoir une API normalisée unique pour gérer tout cela est certain alléchant, mais c'est malheureusement difficilement faisable.

---

je ne parle pas d'une solution immédiate, ça va prendre quelques années bien sur.

mais il faut commencer si on veut y arriver, le succès de java ou maintenant il est numero 1 (http://www.tiobe.com/index.php/conte...pci/index.html) c'est justement ce framework homogène et suffisant dans beaucoup de cas.

il ne faut pas rester bloqué sur le fait que c'est impossible et laisser trainer ce probléme a l'infini, il faut commencer un jour :)

Citation:

---

Envoyé par Matthieu Brucher

Ce qu'on essaie de te faire comprendre, c'est qu'il n'y a pas de manière universelle, dans aucun langage, de faire cette couche technique. Ca dépend du backend, sinon tu dois faire une interface minimaliste avec ce qui est commun à toutes les solutions existantes.

---

cette abstraction de la couche technique est normalement indépendante de tout langage, aucune implémentation juste une spec, et si dans d'autre langages on a une solution suffisante pour la majorité des cas, qu'est ce qui bloque pour C++.

par exemple pour la base ADO ou JDBC sont largement suffisant, pourquoi ne pas avoir une spec pareil en C++?

est ce qu'on peut me dire qu'est ce qu'on peut pas faire avec ADO ou JDBC qui va m'imposer a chercher ailleurs?

Mais justement, ce qu'on se tue à te dire, c'est que ça ne répond pas à tous les cas !
Il y a tout de même des cas où il y a "standard"/"specs", comme pour les arbres DOM XML, où les premières bibliothèques ne suivent pas les _recommandations_ du W3C, mais les nouvelles tendent à les suivre. C'est possible car le DOM a été proposé en même temps qu'XML. Maintenant, faire des specs pour une interface SQL alors qu'aucun SGBD n'a les mêmes fonctions :|
Il y a des tentatives dans différents langages (Python ou Ruby), mais je dois avouer être sceptique quant à leur utilité à moyen terme.

Citation:

---

Envoyé par Matthieu Brucher

Mais justement, ce qu'on se tue à te dire, c'est que ça ne répond pas à tous les cas !
Il y a tout de même des cas où il y a "standard"/"specs", comme pour les arbres DOM XML, où les premières bibliothèques ne suivent pas les _recommandations_ du W3C, mais les nouvelles tendent à les suivre. C'est possible car le DOM a été proposé en même temps qu'XML. Maintenant, faire des specs pour une interface SQL alors qu'aucun SGBD n'a les mêmes fonctions :|
Il y a des tentatives dans différents langages (Python ou Ruby), mais je dois avouer être sceptique quant à leur utilité à moyen terme.

---

dans ce cas quoi dire de l'api ODBC qui est implémenté par tous les moteurs de base de données relationnels.

si on arrive juste a proposer une api c++ autour de ODBC elle sera largement suffisante.

et merci pour l'info pour Python qui est un bon exemple ou on propose une spec de database, je ne connais pas trop Python mais je commence a le respecter :)

et a mon avis tout nouveau langage a intérêt de proposer aussi des specs pour la couche technique.

Citation:

---

Envoyé par Issam_Lahlali

mais il faut commencer si on veut y arriver, le succès de java ou maintenant il est numero 1 (http://www.tiobe.com/index.php/conte...pci/index.html) c'est justement ce framework homogène et suffisant dans beaucoup de cas.

---

Es-tu vraiment aussi certain que Java soit aussi homogène que ça ? Pourtant pour un certain nombre de fonctionnalité, il existe différents framework et différentes bibliothèques (parfois au sein d'un même framework) qui ne sont pas compatible entre eux.

Je doute fortement que les bibliothèques utilisées côté serveur fournissent les mêmes APIs et services que celles utilisé sur mobile ou sur JavaCard.

Citation:

---

Envoyé par Issam_Lahlali

il ne faut pas rester bloqué sur le fait que c'est impossible et laisser trainer ce probléme a l'infini, il faut commencer un jour :)

---

Vas-y je t'en prie.


PS : l'indice TIOBE est quand même à prendre avec des pincettes. Le mode de calcul ne reflète ni le "meilleur" langage (en supposant que cette notion est vraiment un sens, ce dont je doute) ni nécessairement le plus utilisé.

Citation:

---

Envoyé par gl

Vas-y je t'en prie.

---

je pense que j'ai eu ma réponse,jamais on pensera a faire cette démarche et tant pis c'est pas grave d'avoir N librairie pour un même besoin, ça engendre des jobs en plus pour maintenir ou migrer ou refactorer.

d'ailleurs de quoi je me mêle, que c++ soit compliqué ou pas ne présente en aucun cas un probléme , les experts le maitrise bien et les jeunes développeurs ne le font même plus, donc finalement c'est un faux probléme ;)

En fait, cette discussion aura certainement servi a beaucoup de gens sauf a toi.

Citation:

---

Envoyé par Klaim

En fait, cette discussion aura certainement servi a beaucoup de gens sauf a toi.

---

t'inquiète ça m'a beaucoup servi, plus que tu ne crois , et le probléme est que ce type de message ne fait que polluer la discussion ou on ne trouve aucune idée juste des accusations, et tu me dira que tu fais la même chose avec ce message aussi ;)

mais concrètement heureusement qu'on a un débat d'idées et on ne doit pas avoir forcement les mêmes idées, chacun essaye de défendre ces idées avec les arguments et l'expérience qu'il a déjà vécu.

juste un conseil il faut éviter au maximum le débat entre personnes ça ne sert a rien ou on pointe du doigt a chaque fois ou on est pas d'accord c'est la manière la plus facile mais heureusement dans cette discussion c'était pas beaucoup le cas.

et pour cette idée de spec c'est pas nouvelle et c'est de loin mon idée ,on a commencer déjà a faire des specs pour C++

SCA : une spec pour le WebService,MOM et distribué et elle est très prometteuse, j'ai eu l'occasion de l'étudier une fois lorsqu'il fallait choisir une solution C++ pour le distribué.

OMG: pour les specs CORBA, ou plusieurs frameworks existent et j'ai eu l'occasion de bosser sur une migration d'un brocker a un autre et heureusement l'existence de spec a relativement rendu cette migration aisé.


ODMG:pour les bases de données objet.

Citation:

---

Envoyé par Issam_Lahlali

mais il faut commencer si on veut y arriver, le succès de java ou maintenant il est numero 1 (http://www.tiobe.com/index.php/conte...pci/index.html)

---

C++ est en hausse, Ruby est en baisse!!!!!!
D est en forte baisse!!!!!!!!!!
Haskell est 33ième, c'est dingue (je l'imaginais beaucoup mieux placé)

Mais revenons au coeur de la cible du problème: la couche du métier technique :mrgreen:

Citation:

---

d'ailleurs de quoi je me mêle, que c++ soit compliqué ou pas ne présente en aucun cas un probléme , les experts le maitrise bien et les jeunes développeurs ne le font même plus, donc finalement c'est un faux probléme

---

C'est pas faux. Le qualificatif d'expert-friendly n'est pas usurpé :ccool:

Par rapport à SCA, OMG etc, je n'ai pas l'impression que cela résoudrait le problème de la couche technique. Ce sont des spécifications, oui, mais dès lors que l'on plonge dans l'implémentation, on se retrouve tributaire de choix techniques dont une partie est dictée par les specs justement (d'accord, c'est fait pour). Quelque part, ça n'est guère différent des choix techniques d'une librairie quelconque auxquels le développeur doit se plier, et dont les specs sont le code (à défaut d'avoir un bon wiki).

Si on reprend l'exemple de Microsoft COM présenté par Issam_Lahlali beaucoup beaucoup beaucoup plus en amont dans cette thread, où il notait avec justesse la nécessité de rendre COM-agnostique la couche métier, et bien ne faudrait-il pas adopter la même démarche dans le cadre d'une application qui se reposerait en partie sur SCA, par exemple ? Au final, les mêmes longues séances de refactoring et d'inventions de la roue seraient nécessaires si on se rend compte que, ben tout compte fait, toutes ces méthodes virtuelles, ça ne fit pas trop avec les nouvelles contraintes qui viennent de tomber...

Citation:

---

Envoyé par metagoto

Par rapport à SCA, OMG etc, je n'ai pas l'impression que cela résoudrait le problème de la couche technique. Ce sont des spécifications, oui, mais dès lors que l'on plonge dans l'implémentation, on se retrouve tributaire de choix techniques dont une partie est dictée par les specs justement (d'accord, c'est fait pour). Quelque part, ça n'est guère différent des choix techniques d'une librairie quelconque auxquels le développeur doit se plier, et dont les specs sont le code (à défaut d'avoir un bon wiki).

---

des fois ça peut beaucoup aider une spec, en tout cas pour le cas Corba, ça nous a rendu une migration facile vu que les brocker CORBA implémente la même spec.

et vu l'historique faire les specs pour la couche technique pour C++ devient effectivement mission impossible, pour un nouveau langage c'est très recommandé qu'il apporte aussi cette spec.

et la qu'on revient au sujet de la conception,si on cherche des projets C++ sur le net on a le constat général suivant:

Couplage très fort avec la couche technique.

en C++ il y a plusieurs cas ou ce couplage fort peut créer pas mal de problèmes après, donc il faut passer par une abstraction fait maison pour rediriger a la vrai librairie, le but est d'isoler cette couche technique.

est le plus gros souci avec le couplage fort avec une librairie technique est le fait qu'on traine des types de cette librairie dans tout le projet, par exemple imaginant qu'elle redéfinit les chaines de caractères on aura enormement de types represenatant les chaines de caracteres qui cohabitent dans notre projet et ca devient vite usine a gaz.

je plaide pour une spec unifié pour limiter la complexité généré par toutes les librairies utilisés, et d'ailleurs pour un projet la première chose est d'avoir un framework technique qui fait abstraction au maximum de librairies utilisés(IHM c'est mission impossible :) ) et ce framework n'aura que des types natifs de c++ ou de la STL.

ce type de framework rend la vie très très facile après ou on donne a une equipe de 2 personnes au maximum de s'en occuper et les autres développeurs vont être isolé de toute complexité et non homogénéité des librairies.

et si demain on se rend compte qu'une librairie n'est pas performante , l'impact sur le dev est minime , puisqu'il y aura juste l'equipe framework qui sera impacté par ce changement.

j'ai deja pratiquer ce type de découplage a plusieurs reprises et c'est trés trés important même pour les ressources humaines :) , avec un couplage fort nous sommes obligés de trouver qlq qui maitrise la majorité de librairies techniques utilisés, par contre avec un couplage faible on cherche juste un developpeur C++ de base.

j'ai participer a des projets avec et sans couplage fort, et la différence est énorme, c'est pour cela que je me demandais pourquoi chacun doit faire son propre framework pour ça , pourquoi ne pas avoir un framework standardisé?


finalement même si c'est pas possible, il faut penser au maximum a isoler cette couche technique pour minimiser au maximum les types utilisés dans le projet et rendre la vie facile aux développeurs.

CORBA, c'est pas le truc que tout le monde abandonne parce que c'est tout pourri ?

Sinon, c'est quoi MOM ? Première fois que j'entends parler de ça...

Citation:

---

Envoyé par white_tentacle

Sinon, c'est quoi MOM ?

---

Choisis la réponse qui te convient (premières entrées de google) :
MOM
MOM
MOM

:mouarf:

Message Oriented Middleware ;)

Oh. Vous ne pouvez pas appeler ça dbus, comme tout le monde :mouarf:

Citation:

---

Envoyé par white_tentacle

Oh. Vous ne pouvez pas appeler ça dbus, comme tout le monde :mouarf:

---

Désolé pour cette ambiguïté pour le MOM :) , finalement j'entre dans le même piège dans lequel je met en garde pendant toute la discussion qui est le fait que des choses deviennent évidentes si on en fait beaucoup :)

sinon je crois pas que dbus est exactement la même chose que MOM, j'ai vu rapidement ce que ca fait c'est surtout pour communiquer entre process, mais peut etre je peux me tromper.