Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Le moins élémentaires justement dans ce domaine c'est souvent de devoir aller taper dans un mix assembleur ou appel système / autre langage car ce dernier ne permet pas tout.Envoyé par deuz59
Travaillant dans les systèmes critiques je peux te dire qu'on pense pas en POO ici...
On développerai peut être plus vite, mais on sortirai des usines à gaz en terme de temps d'exécution.
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Voilà un autre exemple du coup => ton objectif est d'abord d'avoir une perf irréprochable car système critique : clairement la POO n'est pas un moyen adapter
Néanmoins, tes problématiques restent complexes et tes choix techniques, sûrement plus complexes que la POO, le reflète !!!
C'est la critique la plus habituelle de la POO, mais j'ai l'impression que c'est la moins sérieuse.Travaillant dans les systèmes critiques je peux te dire qu'on pense pas en POO ici...
On développerai peut être plus vite, mais on sortirai des usines à gaz en terme de temps d'exécution.
D'abord parce que l'idée que la POO c'est forcément lent et gourmand en mémoire, c'est un peu dépassé. On trouve C++ compilé qui a des performances très voisines du C équivalent.
Ensuite, parce que le code tellement critique qu'on est à la limite des performances matérielles, c'est très rare en pratique. La plupart du temps, quand on met le matériel à genoux, c'est un problème d'algorithmique ou de conception.
Enfin, parce que même si on doit, en fin de compte, écrire des parties critiques en assembleur ou chaipaquoi, on peut avoir une conception objet, voir du code objet autour.
Je crois que les principales raisons pour lesquelles il n'y a pas d'objet dans certains secteurs, c'est qu'on y a pris d'autres habitudes, qu'on essaye de conserver un style compatible avec l'existant, que les langages utilisés y sont mal adaptés, ou qu'on a des problèmatiques pour lesquelles le procédural parait plus naturel (code très linéaire, programmes très courts).
La performance, c'est souvent une excuse...
Francois
De mon expérience perso:
J'ai raté l'examen de C en 1ère et 2ème session (première année bac info) et
réussi C++ en 2ème session (2ème année). Les prof s'en étonnaient: avoir réussi C++ et "doubler" le cours de C, ça il faut le faire...
Pour Java (3ème et 4ème) je n'ai eu aucun souci et l'examen C# (4ème) s'est merveilleusement bien passé. Cherchez l'erreur...
Il y a peut-être des cas où la programmation orientée objet n'est pas indispensable. J'ignore si cela existe et je ne veux même pas savoir.
Chaque fois que tu dis "je ne peux pas", n'oublie pas d'ajouter le mot "encore".
Moi je dis heureusement que la POO s'est imposée dans tous les projets logiciels des grandes entreprises .... ça a permis et ça permet encore à de nombreuses TPE de survivre
On fait pas tous du système critique sur des multicoeurs tournant à 3Ghtz et embarquant 16Gio de RAM...
Je travaille actuellement sur un code très simple, une autre personne a tenté de le porter en POO, et a tenté moultes optimisation et refonte de code. Il n'a jamais réussi à faire mieux que 25-30% de performances (en moins par rapport à la version en C).
J'attends déjà ceux qui me sortiront que c'est un benêt qui sait pas coder... Mais je ne répondrai pas à ça.
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Non, mais je ne suis pas certain de comprendre ce que ça prouve. Tel travaillera avec des ressources minimales, tel autre avec une contrainte matérielle, tel troisième avec un volume de données déraisonnable, tel autre encore avec des calculs lourds. Et presque tous ceux qui sont dans le métier depuis plus de 20 ans sauront te parler des contraintes techniques du "bon vieux temps" (genre, le charme du calcul numérique quand une multiplication valait 10 additions, les délices du traitement de données sur stockage externe, et les bonheurs de l'interaction avec du matériel analogique)...
Sérieusement, presque tout le monde a rencontré (ou cru rencontrer), à un moment ou un autre, les limites techniques du matériel.
Ca non plus, ça ne prouve pas grand chose.
Mais je suis étonné par ce chiffre de 25 à 30%. Avec un compilateur moderne, du code C++ et du code C compilé, c'est souvent très voisin, et quand ça ne l'est pas, un coup de profileur a très vite fait de révéler un problème facilement corrigeable.
Donc, sur un code simple, avoir quelques % d'écart (pour cause de tables virtuelles, et indirections supplémentaires qu'on laisse passer pour conserver la lisibilité du code), je veux bien, mais 25-30% après optimisation, ça me parait un peu fantaisiste...
Tu es sur que tu compares du compilé à du compilé, que la phase d'optimisation et de refonte s'est faite sur la base d'un profilage du code initial, et qu'on n'était pas dans le cas où, au nom de la POO, le programmeur s'est senti obligé de ne quasiment pas gérer sa mémoire, par exemple de réallouer des objets à l'intérieur des boucles?
Ce n'est pas la question... Mais pour faire du C et du C++ depuis quelques années, des écarts de 25 à 30%, sur du code simple, après optimisation, ca me parait très étrange.
Pour te donner une idée, sur du calcul numérique lourd, 25-30% c'est à peu près l'écart auquel on arrive quand on compare un langage interprété spécialisé (l'APL dans l'exemple que j'ai en tête) et du code "cousu main" (en C). Et je connais des cas ou l'interprété est en deça, non pas parce que le programmeur C est un benêt, mais parce qu'on peut faire des choses très impressionnantes en APL...
Francois
Dernière modification par Invité ; 10/08/2012 à 22h58.
Je jetterai un oeil à son code lundi si j'y repense.
Mais toujours est-il qu'il est parti à la poubelle du coup, c'était une tentative de convertir l'équipe à la POO pour certains projets car on a des codes qui deviennent rapidement très difficile à relire et ce malgré des règles de codage très strictes et une documentation bien fournies. La POO a l'avantage de penser structure.
Les temps sortis de son application ne pouvaient pas convenir, déjà qu'on peine à faire rentrer la version C sur le matériel...
Après certes le matériel n'est pas dimensionné pour ce que l'on souhaite en faire, mais on choisi pas toujours malheureusement... Il y a toujours quelqu'un plus haut qui dicte et on peut pas ouvrir sa bouche même si c'est une idiotie.
Cela me fait penser qu'en fait il y a deux façon de faire du système critique, l'un c'est le traitement, l'autre c'est de faire rentrer le traitement sur le matériel.
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Entièrement d'accord avec stardeath !...
"comment faire ceci" et "comment vais-je structurer mon programme", n'est-ce pas là en fait exactement la même question pour un programmeur ? A moins bien sûr de considérer le rôle du programmeur comme celui d'une secrétaire capable de taper du code bien présenté et sans faute d'orthographe (ie compilable) !...Envoyé par crf 70:
Tout à fait d'accord, quand on commencer à développer avec de la programmation orientée objet, le problème n'est plus "comment faire ceci ?" mais "comment vais-je structurer mon programme ?".
Aujourd'hui, dans mon école, l'étudiant moderne a le choix entre 3 filières d'enseignement ... C'est cool : de "mon temps", nous n'avions pas le choix et devions suivre simultanément ces mêmes trois cursus ; en cadeau, nous étions virés à moins de 12/20 de moyenne générale !!! (certes, il est exact que la starAc et autres télé-réalités sont passées par là entre temps ...;-).
C'est ce que j'entends par ce n'est pas forcément la meilleur solution. On peut tout faire avec de l'objet mais on ne fait pas forcément mieux. Cela dépend du type de problème.
Par exemple pour les specs fonctionnels je pense d'avantage d'avantage calcul propositionnel qu'objet.
Je traduis les specs en clause puis je crée un moteur d'inférence. Éventuellement je factorise le code dans un second temps pour que ça a l'air objet mais cette étape n'apporte rien au code, ni en lisibilité, ni en modularité et ni en performance.
En fait ces problématiques sont purement ergonomique. Le boulot est fait mais il me faut encore me mettre dans la peau d'un "codeur-utilisateur" qui ne lira pas le code source pour comprendre le fonctionnement mais qui modifiera une zone précise sans regarder le reste.
Faut il centraliser toute les règles dans un fichier ?
C'est bien pour estimer la cohérence de l'ensemble d'un simple coup d’œil mais c'est chiant quand on veut savoir quelles règles sont utilisée par une classe lambda.
En fait les critères de lisibilité, modularité et maintenabilité sont très subjectives. En revanche, un algo efficient met tout le monde d'accord.
Quelque part j'ai envie de dire que c'est le boulot d'un architecte qui écrirait la doc technique avant l’implémentation du code. Pour le coup l'objet aide effectivement a respecter des specs mais il s'agit de specs méta-techniques et non de specs de techniques pure et encore moins les specs métiers.
De plus à la vitesse ou la technologie évolue rien ne dit que celui qui passe derrière profitera vraiment de la maintenabilité et ne préféra pas utiliser le nouveau framework en vogue.
Pour ce qui est de l'utilisation ou non d'une bibliothèque java, c'est une autre problématique. On est dans la peau d'un codeur-utilisateur.
Tout à fait d'accord. Avec un début en POO, on oublie de passer par les BA-BA et tout le monde porte facilement le manteau de développeur. Alors qu'avec du code pure, toute la différence est faite et c'est bien en analysant le problème posé et en refléchissant aux éventuelles solutions que l'on trouve l'essentiel. Très bien penser et très bien dit mon frère.
je pense aussi qu'il faut de la progression dans l'apprentissage.
mais je ne suis pas d'accord sur le fait que le développement procédural doit être un prélude à la POO.
en fait je ne pense pas que savoir skier soit nécessaire pour apprendre à faire du snowboard et vice versa.
je pense plutôt que c'est les façons d'enseigner la POO ou la PP sur lesquelles il faut prendre du recul.
je constate en éffet très souvent (c.a.d. quasiment tous les jours et parfois plusieurs fois par jour) que la POO est très mal connue et dans 90% des cas considéré comme un assemblage construit au dessus de la PP. Je constate aussi que la POO est quasi systématiquement assimilé à la notion de classe ce qui dans la théorie ne représente qu'une petite branche des approches POO.
bref tout comme pour le ski et le snowboard qui sont toutes les deux des diciplines de glisse la POO et la PP peuvent être enseignées de façon indépendantes.
j'ai toujours enseigné le C++ à des gens ne conaissant pas le C sans faire du C un préalable. alors que le C++ est l'exemple typique de ce qui menne à cette confusion qui considère que la POO c'est une evolution de la PP.
je pense aussi que l'enseignement de la programation en général pouse à une confusion entre langage (donc expression) et outil informatique. je trouve que beaucoup trops de developpeur n'ont pas conscience qu'un langage n'est qu'un moyen de produire du verbe et non pas un exécutable.
bref je pense qu'on a encore beaucoup de travail.
A+JYT
Pour ma part etant etudiant, j ai debuté avec Pascal puis C\C++ et la transistion vers Python/Java fut douce. Pour ce qui est de la POO il faut avouer qu a la base je gardais mes distances comme avec les pointeurs mais ca vient avec le temps. Ca reste tout de meme un point de discorde dans les projets. il y en a qui feraient bien 10 classes pour representer un abre sous pretexte qu on aurait dit : "plus il y en a, mieux c est"
donc en gros, pour la POO apres le procedural. A moins que l on ne forme des visual-devs -_-
Win 10 64 bits / Linux Mint 18, - AMD A6 Quad: Py27 / Py35
CONTENU D'UNE QUESTION
Exemples:
- Configuration (système d'exploitation, version de Python et des bibliothèques utilisées)
- Code source du morceau de programme où il y a un bogue
- Ligne de code sur laquelle le bogue apparaît
- Erreur complète retournée pas l'interpréteur Python
- Recherche déjà effectuée (FAQ, Tutoriels, ...)
- Tests déjà effectués
La POO c'est juste "plus de temps": plus de temps cpu, plus de temps pour apprendre, plus de temps pour former, plus de temps pour conceptualiser, et (sauf cas particulier et quoi qu'en disent certains) plus de temps pour coder, plus de temps pour debugger, plus de temps de maintenance.
Et comme on dit, "le temps c'est de l'argent" ...
en gros je suis d accord mais pas avec le point sur la maintenance. juste un serpent PP Vs un serpent POO a maintenir faire passer a une nouvelle evolution et la...La POO c'est juste "plus de temps": plus de temps cpu, plus de temps pour apprendre, plus de temps pour former, plus de temps pour conceptualiser, et (sauf cas particulier et quoi qu'en disent certains) plus de temps pour coder, plus de temps pour debugger, plus de temps de maintenance.
Et comme on dit, "le temps c'est de l'argent" ...
Win 10 64 bits / Linux Mint 18, - AMD A6 Quad: Py27 / Py35
CONTENU D'UNE QUESTION
Exemples:
- Configuration (système d'exploitation, version de Python et des bibliothèques utilisées)
- Code source du morceau de programme où il y a un bogue
- Ligne de code sur laquelle le bogue apparaît
- Erreur complète retournée pas l'interpréteur Python
- Recherche déjà effectuée (FAQ, Tutoriels, ...)
- Tests déjà effectués
Concernant la maintenance ça dépend effectivement du type de problème à régler mais dans le cas de la reprise de code de quelqu'un d'autre en 15 ans je n'ai jamais été bloqué par de la reprise de code procédural (vu qu'au pire on peut réecrire facilement une partie en faisant attention à d'éventuels effets de bords "techniques"), en revanche avec la POO et ses "effets de bord conceptuels" je me suis souvent retrouvé dans une impasse.
Après il est évident que je maitrise bien plus le procédural que la POO donc ça explique sans doute certaines impasses, mais les personnes maitrisant vraiment la POO sont très rares du coup pour trouver quelqu'un capable de maintenir efficacement de la POO c'est très difficile (donc "en pratique" la maintenance sera rendue plus difficile).
je crois que justement c'est là que la bât blesse.La POO c'est juste "plus de temps": plus de temps cpu, plus de temps pour apprendre, plus de temps pour former, plus de temps pour conceptualiser, et (sauf cas particulier et quoi qu'en disent certains) plus de temps pour coder, plus de temps pour debugger, plus de temps de maintenance.
Et comme on dit, "le temps c'est de l'argent" ...
lorsque les concept fondamentaux de la POO sont acquis de façon naturelle comme un dérivé de la PP ou come une technique de codage.
la POO c'est du temps du temps et du temps.
alors que pour quelqu'un qui maitrise la théorie sous-jacente la POO c'est gain de temps gain de temps gain de temps.
le pire c'est quand je vois des gens qui crachent sur la POO et à qui je montre un code spaghetti en PP et qui me font une démo du genre "c'est sur mais regarde avec une bonne conception ..." et les voilà qui me refont le truc en PP en structurant leur code leurs concepts et au final appliquent en les niant les fondamentaux de la POO
je rappelle que la POO ce n'est pas un pb de langage c'est une façon de penser.
on peut très bien faire de la POO en assembleur. c'est sur qu'un langage qui intègre les notion facilite (quoi que...) les choses. la POO ce n'est pas coder des classes.
A+JYT
Malheureusement c'est comme ça que c'est utilisé en pratique et plus il y a de classes et plus les POO maniaques sont contents d'eux.
Les "frameworks" en sont la meilleure illustration ... personnellement je reste "admiratif" devant tant d'imagination pour arriver à créer une hierarchie spaghettis/poupées russes pour au final faire des choses très basiques.
ça c'est faux, la POO est une réponse efficace à certains problèmes complexes pour lesquels le procédural ne fait pas mieux. c'est un peu comme si tu disais que les variables locales c'est nul ça prend de la place sur la pile, il ne faut utiliser que des variables globales...c'est faisable mais c'est loin d'être aussi pratique.La POO c'est juste "plus de temps": plus de temps cpu, plus de temps pour apprendre, plus de temps pour former, plus de temps pour conceptualiser, et (sauf cas particulier et quoi qu'en disent certains) plus de temps pour coder, plus de temps pour debugger, plus de temps de maintenance.
Et comme on dit, "le temps c'est de l'argent" ...
Paul je pense que ta vision de la chose est déformée par le fait que tu maitrises très bien les 2 approches donc face à chaque problème tu choisis la plus efficace.
Tu dois être dans le top 1% des programmeurs, il ne faut donc pas croire que ceux qui sont seulement dans le top 5, top 10 ou plus bas encore font de même
Le plus souvent ils utilisent uniquement la POO même quand ce n'est pas du tout adapté, soit par vanité, soit par bétise, soit par pur calcul financier.
Le résultat étant catastrophique en termes de consommation de "temps" à tous les niveaux.
Je vais encore faire une moisson de thumbs down mais il faut savoir vivre dangereusement
[EDIT: merci pour ces nombreux thumbs down, au moins certains se sont reconnus
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager