Réponse rapide sur le "full OO", il faut être un peu stupide pour croire qu'un langage/framework/notion puisse être la solution idéale à tous les problèmes ... comme dans la vie réelle il n'existe pas de solution miracle. L'avantage avec l'objet c'est que ça a permis de faire évoluer le pouvoir d'expression de pas mal de langage informatique, de faire évoluer les mentalités des informaticiens, d'ajouter une couche d'abstration supplémentaire par rapport au langage machine.
J'ai commencé l'informatique en apprenant l'UML et Java (et Perl) (en 1998 il me semble), mais déjà à l'époque on voyait les limitations de ces langages mais c'était déjà mieux que le bon codage pourri qui était encore de mise dans pas mal de boite d'informatique (méthodologie, structuration, maintenabilité ? on ne construit pas des voitures ici on fait du code !). Le problème, c'est que le premier langage objet à rentré dans l'industrie c'était Java et qui 7 plus tard commence à combler les manques qu'il pouvait avoir par rapport à des langages comme SmallTalk (début des années 80). Évidemment, Sun & co on fait de la pub sur la force de Java sur la notion de réutilisabilité, de maintenabilité, d'intéropérabilité qu'apportait leur langage ... mais c'était avant tout de la pub !
Le problème de l'informatique c'est la synergie des entreprises toujours frileuses à changer de technologie, finalement je défend Java car il a permis de faire évoluer les entreprises. Si tu veux découvrir la prochaine révolution niveau notion de programmation fait un petit tour sur les sites des laboratoires de recherche en génie logiciel, pour ma part la programmation orienté aspect ne me convainc pas plus que ça.
Enfin, pour ce qui est des librairies, j'ai eu exactement la même reflexion que toi, sauf qu'à mon époque c'était Perl qui détendait le maximum de fonctionnalités. Après mettre cassé la tête pour faire de l'objet sur ce langage, je suis passé à Ruby. Et vu l'évolution de ce langage, je pense que le retard par rapport à Python sera vite comblé. On est actuellement à la phase adaptation des librairies natives comme SDL, OpenGL ... arrivera ensuite les librairies plus haut niveau (comme pygame). Entre temps, l'interpréteur Ruby aura gagné en rapidité (utilisation de Parrot ?) et pourra enfin concurencer ses cousins interprétés :).
Bon, je m'arrete la, j'ai un peu pris plus de temps que j'avais prévu au début :)
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 1.
J'ai commencé l'informatique en apprenant l'UML et Java (et Perl) (en 1998 il me semble), mais déjà à l'époque on voyait les limitations de ces langages mais c'était déjà mieux que le bon codage pourri qui était encore de mise dans pas mal de boite d'informatique (méthodologie, structuration, maintenabilité ? on ne construit pas des voitures ici on fait du code !). Le problème, c'est que le premier langage objet à rentré dans l'industrie c'était Java et qui 7 plus tard commence à combler les manques qu'il pouvait avoir par rapport à des langages comme SmallTalk (début des années 80). Évidemment, Sun & co on fait de la pub sur la force de Java sur la notion de réutilisabilité, de maintenabilité, d'intéropérabilité qu'apportait leur langage ... mais c'était avant tout de la pub !
Le problème de l'informatique c'est la synergie des entreprises toujours frileuses à changer de technologie, finalement je défend Java car il a permis de faire évoluer les entreprises. Si tu veux découvrir la prochaine révolution niveau notion de programmation fait un petit tour sur les sites des laboratoires de recherche en génie logiciel, pour ma part la programmation orienté aspect ne me convainc pas plus que ça.
Enfin, pour ce qui est des librairies, j'ai eu exactement la même reflexion que toi, sauf qu'à mon époque c'était Perl qui détendait le maximum de fonctionnalités. Après mettre cassé la tête pour faire de l'objet sur ce langage, je suis passé à Ruby. Et vu l'évolution de ce langage, je pense que le retard par rapport à Python sera vite comblé. On est actuellement à la phase adaptation des librairies natives comme SDL, OpenGL ... arrivera ensuite les librairies plus haut niveau (comme pygame). Entre temps, l'interpréteur Ruby aura gagné en rapidité (utilisation de Parrot ?) et pourra enfin concurencer ses cousins interprétés :).
Bon, je m'arrete la, j'ai un peu pris plus de temps que j'avais prévu au début :)