Discussion :

[Jean-Marc.Bourguet]

j'aurais plutot dit d'un délire de spécialistes de la théorie des langages au fond de leur labo... donc très éloigné de tout ce que les industriels auraient pu vouloir

Les langages n'etaient si theorise que cela dans les annees 60-70, au moment ou la POO apparait (SIMULA 67, SmallTalk 74).

Oui, il y a une reflexion theorique, mais en vue de resoudre des problemes pratiques bien reels. Et ces problemes n'etaient pas tant lies a la maintenance que la realisation meme de programmes importants.

Apres oui, les theoriciens ont parfois delire...

[InOCamlWeTrust]

L'approche objet est essentiellement fondée sur la question Qui fait quoi ?

L'approche classique reste elle sur le Que fait-on ?

La conception modulaire, dont l'objet fait partie, permet de lier les deux approches.

[super_navide]

Il est étonant voir stupide de nier l'existance d'un langage universel pour tous les domaines.
Le langage Smalltalk me parait un bon candidat.
Il a une syntaxe qui se raproche du langage naturel
example :
leChat mange: uneSouris sur: laTerrasse avec: unGrandPlaisir

il permet de représenter le langage des predicats avec quantificateurs
example :
[ :s :y | ((s > y ) & s estReel & y estReel ) => [:m |(m estReel & (m> s) & (m <y ) )] exist ] all

et il permet de faire de la programation objet.

Le seul point faible est sa performance mais la c'est une question d'implémentation technique et je ne rentrerai pas dans les details


je me souvient j'entendais dire , on fera jamais de jeux en java ouhais avec le GC ca va faire des pose dans le jeux, ouais c++ c'est dix mille fois plus rapide

et pourtant il existe des jeux qui sont correcte.


De plus la POO peut etre utilisé dans toutes les disciplines elle a été créer pour ca.
Et même pour créer un autre langage on pourra modeliser les base de ce langage avec la POO

[Woufeil]

Il est étonant voir stupide de nier l'existance d'un langage universel pour tous les domaines.

OK. Donc si Smalltalk est universel, il permet de créer un OS. D'exécuter dans des temps corrects des calculs météorologiques complexes. De faire de la compilation.

Certes on peut faire des jeux en Java, mais dans beaucoup de laboratoires on utilise FORTRAN 77 (même pas 90 ou 95) pour des raisons de performance, et ils neveulent surtout pas entendre parler d'autre chose (et surtout pas de Java).

Smalltalk est sans doute est un très bon langage (je ne le connais pas), mais il n'est pas univsersel... Et puis, Larry Wall (il me semble) disait bien qu'un langage de programmation ne se différencie pas des autres forcément par ce qu'il rend possible, mais par ce qu'il rend facile. C'est la raison pour laquelle il n'existera jamais de langage universel...

[super_navide]

si smalltalk est universel je vois pas en quoi ca implique qu'il doit être utilisé partout.

Windows est bien plus utilisé que linux ca veut pas pour autant dire que linux est moin bien que Windows et moins puissant.

[Jean-Marc.Bourguet]

Il est étonant voir stupide de nier l'existance d'un langage universel pour tous les domaines.
Le langage Smalltalk me parait un bon candidat.

Il va falloir commencer par me convaincre qu'un langage type dynamiquement est un bon candidat pour les gros projets (avec ma definition de gros: ou une personne ne peut qu'avoir une vision tres partielle de l'ensemble).

[super_navide]

Il va falloir commencer par me convaincre qu'un langage type dynamiquement est un bon candidat pour les gros projets (avec ma definition de gros: ou une personne ne peut qu'avoir une vision tres partielle de l'ensemble).

Et Ben il y a 2 entreprises que je ne citerai pas qui ont de très gros logiciel en Smalltalk.

un lanage type dynamiquement n'est pas un frein .
Si tu teste convenablement tu n'a pas de problème.
en java tu a le problème du NullPointerException et du ClassCastException
ca revien presque pareil ...
J'ai lontemps pensé ouais typé c'est mieux car il y a le compilateur qui detecte certaine erreurs.
Mais avec l'experience je me suis appercus que ca ne changeait rien du tout .
Il y a autant d'erreur possible dans un langage type que dans un langage non typé.

Le seul point faible de smalltalk et il est de taille ce sont les Float et les Double qui sont des objets
Mais cette faiblesse est supprimé pour les floats sur les architecture 64 bits
mais bon après il y a les vecteurs les matrices qui sont des objets mais la pour java c'est la même chose.
Il faudrait pouvoir créer des objet sur la pile d'execution ...
Mais même la je commence a avoir des doutes sur la réelle utilité d'une tel possibilité.
Car le gabage collector de java est une merveille de performance.
Même si il est très très complexe...

[Air Marty]

(...)
Je voudrai savoir si la POO a été inventée comme formalisme pour se départir de certains problèmes techniques tels que la gestion de la mémoire, où si elle a plutôt été inventée pour simplifier les implémentations et la structuration des données.

Je voudrais savoir en fait, en réponse à quels problèmes la POO est-elle devenue une façon de programmer distincte de la programmation en général et dans quel contexte?

Tout cela pour en savoir plus sur la nécessité de posséder un formalisme objet pour un programmeur.

Mon premier post pour moi, je me permet de citer la question posé en tout début de post.
Je te donne mon avis basé sur mon expérience et sur ce que je vis au quotidien (j'encadre un service de 35 ingénieurs en développement).
Je ne vais pas te parler de théorie mais d'industrie car ça je connais bien, c'est mon gagne pain.
Tu dois considérer que les langages sont au service de la conception et ne sont que des outils qui vont te permettre de bâtir l'application que tu dois livrer.
Il faut en effet, comme il est cité plus haut, distinguer la conception objet des langages de programmation orienté objet (je reprends volontairement tes termes). En effet les puristes vont commencer à te parler de langage "orienté objet", "à objet" ou "basé objet" or toi tu cites la "POO" donc la Programmation Orientée Objet.
Je rappelle la définition du mot Ingénierie :

Ingénierie, subst. fém. ,,Ensemble des fonctions allant de la conception et des études à la responsabilité de la construction et au contrôle des équipements d'une installation technique ou industrielle.

Il va de soi que de nos jours un ingénieur en génie logiciel se doit de connaitre les concepts objets et de maitriser un ou des langages orientés objet (ou "à objet").
La question n'est pas de savoir si c'est mieux ou moins bien que d'autres langages et d'autres approches, c'est juste qu'il faut savoir que c'est utilisé dans l'industrie et les méthodes de conception objet ainsi que les techniques (par technique j'entends langages) ont été adoptées pour tous types d'application.
Attention cela ne veut pas dire que dans la pratique la maitrise par les équipes de développement des concepts et des langages soit arrivée à maturité, je fait juste état d'un constat : l'objet est là et il faut faire avec.

Ensuite sans rentrer dans le débat des puristes et autres théoriciens (que je ne suis pas) j'ajouterai que non ce n'est pas la réponse à tout, c'est une réponse comme une autre qui a ces avantages et ces inconvénients.
C'est là qu'intervient le savoir faire de l'ingénieur : quelle méthodes et quelle techniques sont les plus adaptées pour répondre à mon besoin (cahier des charges) et selon les critères d'exigence (prix, délai, qualité).
Dans l'industrie les langages comme le C++ ont su démontrer leur capacité à permettre de réaliser des applications de toutes sorte malheureusement ils ont aussi permis de hisser les problématiques de pointeurs nuls en tant qu'art à part entière.
Donc pour répondre à ta question oui il est important de connaitre les formalismes objet et oui cela devient quasiment une nécessité.
Une dernière chose, ne pas confondre conception et programmation .

[super_navide]

Oui il ne faut pas confondre conception et programmation objet mais dans 99% des cas quand on fait une conception objet on utilise un langage objet.
Faire un super model objet tous beau et l'implémenté en Assembler ou en C n'est pas très judicieux et a faire ...

[millie]

Faire un super model objet tous beau et l'implémenté en Assembler ou en C n'est pas très judicieux et a faire ...

Pourquoi ? Je suis pas d'accord, quand on fait une grosse application en C, en général, on fait de la conception objet.

[super_navide]

Par conception Objet j'entend faire des diagrames de classes , des diagrame de séquence.
Je sais que implémenté une classe en C c'est possible mais c'est lourd ...
Montre moi comment on implemente facilement une classes avec une hierarchie en c , comment on fait des appels de méthode , comment on définit des méthodes...
De toutes façon les langage sont traduit en assembler (ou c ) donc théoriquement c'est possible de faire de l'objet avec de l'assembler mais a quel prix...
Les compilateurs sont concu poru facilité le travail...

[Jean-Marc.Bourguet]

Montre moi comment on implemente facilement une classes avec une hierarchie en c , comment on fait des appels de méthode , comment on définit des méthodes...

http://ldeniau.web.cern.ch/ldeniau/oopc.html