Au jour d'aujourd'hui, et ce depuis de longues années, la dictature du C est indiscutable. Promu "langage de référence", il constitue depuis longtemps déjà LE langage pour programmer, et ce quelque soit l'orientation du programme final (OS, bas/haut niveau, etc...)
Avec l'expansion des langages WEB, et de ce que je suis tenté d'appel les "petits" langages type Python, Perl ou autre PHP ; avec la prolifération des RAD auprès des codeurs débutants, quel avenir pour le C/C++ ?
D'après vous, bien que le choix du langage relève du gout de chacun, quel langage va-t-il "s'imposer" dans les années à venir ? Ou alors quel langage aimeriez-vous voir "s'imposer" ?
On avait parlé du Java il fut un temps, mais je pense que ce futur-là appartient déjà au passé...
Journal Le langage du futur ?
1
jan.
2004
# Re: Le langage du futur ?
Posté par Ramso . Évalué à 1.
indice : on se posait déjà la question il y a 10 ans, haut-niveau, RAD (c'était la grande mode) et tout ça.
# Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à 0.
Pour ce qui est de s'imposer, pour java c'est déjà fait.
Je verais bien ensuite C#.
Maintenant, ce que je voudrais comme langage c'est du plus haut niveau que ces truc la. Des truc que tout le monde connaitra dans 10 ans quoi.
[^] # Re: Le langage du futur ?
Posté par Vincent Richard (site web personnel) . Évalué à 1.
Le langage de script de MultideskOS ? :-)
PS : le C/C++ n'existe pas : c'est soit C, soit C++ qui sont deux langages différents (ou plutôt, à part entière).
[^] # Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à -2.
Je vais pas réexpliquer ce que veut dire langage haut niveau.
Y a qu'a suivre l'évolution C ->C++ -> Java. Quoi que de C a C++ l'évolution est pas énorme. D'ou le couple qui va bien ensemble.
[^] # Re: Le langage du futur ?
Posté par tanguy_k (site web personnel) . Évalué à 2.
ba nan tient...
Entre le C et le C++ on change juste de concept de programmation, rien que ca !
[^] # Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à -3.
Entre le C et le C++ y a pas beaucoup de différence.
Oui, y a un début de concept objet que l'on peut utiliser.
Mais en contrepartie on a une grande quantité de saloperie.
Donc, l'évolution en terme de haut niveau / bas niveau est pas énorme.
On se prend toujours la tête avec des choses qui n'ont rien a voir avec le problème. Et même plus qu'en C.
[^] # Re: Le langage du futur ?
Posté par tanguy_k (site web personnel) . Évalué à 3.
Et ben c'est que tu n'as pas du utiliser beaucoup C++
> Oui, y a un début de concept objet que l'on peut utiliser.
Juste un debut... et tu peux me donner la definition de la fin ?
C'est marrant mais meme avec un "debut de concept objet" le GOF a ecrit LE bouquin sur les design patterns.
> Mais en contrepartie on a une grande quantité de saloperie.
l'heritage multiple ?
les references ?
les exceptions ?
la surcharge des operateurs ?
les templates ?
les namespaces ?
la surcharge des methodes ?
les parametres par defaut ?
la STL ? ...
Evidemment tout ca c'est de la merde bas niveau, c'est bien connu.
> On se prend toujours la tête avec des choses qui n'ont rien a voir avec le problème.
> Et même plus qu'en C.
Parceque tu n'as pas compris a quoi servait ces choses, tout simplement.
Franchement tu viens d'ecrire un tissu d'anneries c'est assez impressionnant !
[^] # Re: Le langage du futur ?
Posté par xilun . Évalué à 2.
[^] # Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par free2.org . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à 1.
Mais le C++ et l'objet c'est deux choses différentes.
C'est comme parler des voitures en se limitant aux lada.
# Re: Le langage du futur ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 4.
Laisse moi rire :)
Regarde le nombre d'offres d'emplois pour du J2EE (websphere, Jonass, Jboss ...) comparé a celles en C/C++.
Et pour avoir frequente pas mal de labo acces sur la recherche & developpement scientifique, un des langages le plus utilisé est le Java (ben oui, comme niveau machines c'est tres hétérogenes (Sun, SGI, Windows, Linux ...), c'est tres interessant d'utiliser le Java vu que ca evite des adaptations tres couteuses pour chaque OS)
(surtout au niveau des GUIs)
Apres, Le langage n'est pas au gout de chacun, c'est surtout a la nature du besoin ...
On va pas faire des calculs scientifiques en PHP comme on va pas faire en site web en C++ ...
[^] # Re: Le langage du futur ?
Posté par Nÿco (site web personnel) . Évalué à 6.
[^] # Re: Le langage du futur ?
Posté par bmc . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
C'est peut-être aussi parce que les gens qui bossent dans le J2EE en ont vite marre, et qu'il faut les remplacer en permanence, non ?
[^] # Re: Le langage du futur ?
Posté par MagicNinja . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par fragbait . Évalué à 1.
# Re: Le langage du futur ?
Posté par kapouik . Évalué à 4.
Conceptuellement, Java n'est pas si mal. Dans la pratique, ce qui a fait du tort à Java à mon avis, c'est l'implémentation Java de Microsoft. Microsoft a proposé des "extensions" qui n'étaient disponibles que sous Windows, amoindrissant ainsi la caractéristique multi-plateforme de Java, d'autant que Windows est quand même le système le plus répandu.
En fait, le "standard" Java a souffert de la même manière que les "normes" HTML et JavaScript pour lesquelles Microsoft a développé des extensions sur leur plateforme Windows et dont les implémentations n'étaient pas forcément en conformité avec les standards.
Quant au langage qui va s'imposer, la question ne devrait pas vraiment se poser pas car il y a plusieurs langage adaptés à divers besoins, même s'il y a des "doublons". Certains s'imposeront évidemment dans leur domaine de prédilection mais je doute personnellement que l'un d'entre eux atteingne un jour la popularité et la "polyvalence" du langage C ... qui reste le langage de notre OS favori :)
[^] # Re: Le langage du futur ?
Posté par Buto . Évalué à 2.
Le standard n'a jamais vraiment souffert, puisque la majorité des développeurs actuels savent que le Java c'est Sun, et que Microsoft ne fait plus de Java, ils maintiennent leur machine virtuelle le minimum syndical (trous de sécurité).
En revanche, ca a posé un problème pour l'utilisation du Java sur le Web, puisque 95% des navigateurs sont sous Windows/Internet Exploseur.
Aujourd'hui on ne retrouve en général que des petites applets sur des pages persos.
[^] # Re: Le langage du futur ?
Posté par fragbait . Évalué à 1.
Non ça ne peut pas jouer, non.
# Re: Le langage du futur ?
Posté par pinky . Évalué à 0.
Mon avis:
- Je pense que le C continuera longtemps pour le bas niveau
- Python est va dominer pour le haut niveau. Pas tellement grâce au langage en lui-même (car certains langages sont aussi puissant voir plus, ex: ruby) mais plutôt grâce à tout ce qui l'entoure. (tout est clean, bcp de librairies, grosse appli, devel actif, ...)
- Même si je ne l'utilise pas, je trouve C# vraiment bien. Pour .NET je n'ai lu que les specs du toolkit et c'est pas mal. (l'approche properties me plait)
Je pense que les langages fonctionnels, logiques ou autres folkloriques (OZ-MOZART, ...) sont utiles pour faire de la recherche dans des nouveaux domaines de la programmation mais ils n'ont aucun avenir. Rien de tel que la programmation objet ou itérative. Mais ils permettent de développer la recherche dans certains domaines: la programmation par contrainte, la prog objet concurrente, ...
Je pense que les langages fontionnels ou logiques sont morts ou vont mourir. Les langages itératifs implémenteront leurs fonctionnalités (lambda fct, prog logique) ou les librairies vont les remplacer. C'est nettement moins contraignant.
Pour le web:
J'imagine difficilement PHP disparaître même si le langage et les librairies sont pourries.
Y'aura tjs des entreprises stupides pour utiliser les JAVA beans, J2EE et autres stupidités du genre.
Autrement, je pense que ZOPE a énormément d'avenir. Ils se peut que de nouveaux framework prennent le dessus (j'aime bien l'approche de albatross (http://www.object-craft.com.au/projects/albatross/(...)) et je ne connais pas d'autres
appli web qui ont cette approche machine à état. C'est bien pour les petits sites).
A part ZOPE, je trouve qu'il y a peu de bons gros CMF et framework web.
[^] # Re: Le langage du futur ?
Posté par Emmanuel NAVARRO . Évalué à 3.
[^] # Re: Le langage du futur ?
Posté par pinky . Évalué à 6.
- supporte peu de techniques de prog actuelles: properties, lambda calcul, ...
- les types de base ne sont pas des objets !
- déficiences importantes: par exemple, pas d'exceptions,
- les fonctions pour manipuler les types de base sont males pensées, ...
Mais le pire, c'est que ce n'est pas clean. Il n'y a pas une nomenclature comune à toutes les fonctions. C'est comme si on avait fait 100 librairies sans jamais se concerter et mettre tout ensemble. J'ai parfois l'impression que les fonctions/méthodes sont mal pensées.
Regarde la gestion des chaines de caractères et des tableaux, ce serait nettement plus puissant si ces types étaient des objets.
Au niveau des librairies:
- pas de nomenclature commune. Par exemple, Python a défini DB2 API, une interface pour interfacer avec des DB SQL et les librairies SQL supportent cette recommandation. Cette recommandation est bien faites et aucune des librairies PHP (mysql et postgres) n'est aussi bien faites. De plus, tu peux changer de mysql à postgresql sans problèmes. Pas (du moins moins bien) en PHP)
- les signatures des fonctions sont généralement mauvaises
- il manque encore bcp de librairies
Au niveau des programmes:
- ils possèdent tous des miliers de lignes de code et ils ne sont pas du tout flexibles.
(généralement, un programme bien écrit se voit au nombre peu élévé de lignes)
J'ai déjà chipoté dans: PHP Nuke, POST Nuke, OSCommerce, PHPauction
Tous ces programmes ont plus de 5000 lignes. Essaie d'y modifier qqch, t'es parti pour quelques heures/jours.
Mauvais principe de base:
alors que l'idéal dans la conception d'un site web c'est de séparer la forme du contenu, (templates) PHP incite à faire le contraire et à mélanger le code avec le HTML.
Le seul grand avantage de PHP c'est qu'il est installé partout et qu'il est très simple à maintenir. Quand je fais des petits sites (3/4 pages), j'utilises encore PHP.
[^] # Re: Le langage du futur ?
Posté par Moby-Dik . Évalué à -2.
- les types de base ne sont pas des objets !
Ca suffit à en faire un langage "pourri" ?
Regarde la gestion des chaines de caractères et des tableaux, ce serait nettement plus puissant si ces types étaient des objets.
Ah bon ??
- les signatures des fonctions sont généralement mauvaises
Mauvaises ?? Ca te dirait de préciser un peu ?
- il manque encore bcp de librairies
PHP est conçu pour le Web...
Au niveau des programmes:
- ils possèdent tous des miliers de lignes de code et ils ne sont pas du tout flexibles.
(généralement, un programme bien écrit se voit au nombre peu élévé de lignes)
Hein ?? Si pour toi un bon programme fait moins de quelques milliers de lignes de code, je doute de ton expérience en programmation...
(au fait, tu connais le noyau Linux ? il fait quelques millions de lignes à ce qu'on m'a dit)
[^] # Re: Le langage du futur ?
Posté par Gabriel . Évalué à 2.
Je suis assez d'accord mais c'est le html qui à la base mélange alègrement présentation et données. L'idée de xmliser tout ça par xhtml et le web sémantique peut apporter quelquechose mais quand même - à l'aulne du peu que je sais,
ça ne semble pas ultra formalisé, ni trop formalisable, puisque là on parle www c'est-à-dire plein de gens, ce qui demande pas mal de tolérance. Bref..
PS: : juste une question alors: pour les "plus gros sites" tu vas préfèrer python? pq pas Java - à part que c'est pas libre mais si mais non mais si ..
[^] # Re: Le langage du futur ?
Posté par Buto . Évalué à 2. Dernière modification le 04 décembre 2021 à 20:14.
Regarde la gestion des chaines de caractères et des tableaux, ce serait nettement plus puissant si ces types étaient des objets.
Le PHP reprend ce qu'il y a de plus pratique du C et du Perl pour ca.
Mauvais principe de base:
alors que l'idéal dans la conception d'un site web c'est de séparer la forme du contenu, (templates) PHP incite à faire le contraire et à mélanger le code avec le HTML.
Un ou deux exemples :
http://smarty.php.net(…)
http://templeet.org (NdM: remplacé en 2021 par un lien archive.org)
J'ai parfois l'impression que les fonctions/méthodes sont mal pensées.
C'est pour ca que PHP est si impopulaire. 2004 sera l'année de la mort de PHP ;-)
J'ai déjà chipoté dans: PHP Nuke, POST Nuke, OSCommerce, PHPauction
Tous ces programmes ont plus de 5000 lignes. Essaie d'y modifier qqch, t'es parti pour quelques heures/jours.
Pour conclure tu as fait un mauvais copier-coller avec bouts d'argumentations trouvés ca et là. Apprends d'abord à te servir du langage avant de faire des critiques gratuites.
[^] # Re: Le langage du futur ?
Posté par drac . Évalué à 0.
On peut faire du lambda calcul en C ?
Ca va commencer à m'interesser dans ce cas la ;)
[^] # Re: Le langage du futur ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
Avec toutes les decisions a la con comme garder par defaut et meme promouvoir la syntaxe <?, laisser volontairement des fonctions produire du cote completement invalide (nl2br(), toute la gestion des sessions avec trans_id, etc) et plein d'autre petites choses encore...
Je parle meme pas du fait que ya des features qui sont volontairement laissées comme telles, en sachant l'implementation pourrie, histoire de mieux vendre les trucs genre Zend optimiser...
[^] # Re: Le langage du futur ?
Posté par tanguy_k (site web personnel) . Évalué à 5.
Un exemple criant: chaque base de donnees a ses propres fonctions incompatibles. C'est crade et resulte d'un mauvais design, on dirait du bricolage. Il faut donc se coder soi-meme un wrapper parceque PHP fait mal son boulot.
> Y'aura tjs des entreprises stupides pour utiliser les JAVA beans, J2EE et autres stupidités du genre.
Tu peux argumenter ? (le sujet m'interesse et je n'ai pas de connaissance sur J2EE).
Je programme en Java (J2SE) des applications pour desktop, ma conclusion: le resultat (robustesse, maintenance, lisibilite, temps de developpement...) est sans comparaison avec C/GTK/GNOME.
J'aime beaucoup C++/Qt parceque c'est tres tres bien foutu, mais Java donne tout de meme de meilleures resultats de maniere globale.
Le language du futur proche pour le desktop ?
J'aimerai bien un Java/GCJ/SWT :) Bref un Java completement libre et aussi rapide que du C++.
[^] # Re: Le langage du futur ?
Posté par Pierre Tramonson . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par MagicNinja . Évalué à 1.
Le wrapper existe deja depuis un bout de temps :
http://pear.php.net/package/DB(...)
Par contre, c'est vrai que des exceptions en php ce ne serait pas un luxe.
[^] # Re: Le langage du futur ?
Posté par Talou (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
Pourquoi dis tu ca ?
Je connais plutot pas mal les deux langages mais franchement, j'ai vraiment eu du mal a voir en quoi Ruby est plus puissant que Python.
Ok, les notions objets sont plus poussées meme si c'est pas au niveau de Java/C# mais a part ca, c'est bonnet blanc/blanc bonnet les deux de ma vision.
Pour php, ca a ete evoque au dessus, mais je te trouve tres (trop categorie).
Ok, les fonctions sont mal pensées dans leur globalité. Exemple :
- mixed str_replace ( mixed search, mixed replace, mixed subject [, int &count])
- int stripos ( string haystack, string needle [, int offset])
Dans str_replace, la chaine que l'on va utiliser est le 3 eme parametre
dans stripos, c'est le premier.
C'est un détail comme ca a premiere vue, mais quand on dev bcp en PHP, c'est vraiment lourd a chaque fois (et c'est pas que ce cas là malheureusement)...
Apres, pour la non uniformatisation des acces aux bases de données, tu as les libs Pear qui font ca en php depuis pas mal de temps ...
Et bon, le passage rapide Mysql => Postgresql, c'est un reve ...
les syntaxes étant differentes tu dois repasser derriere pour revoir la syntaxe (rien que LIMIT x,y avec mysql qui devient LIMIT x OFFSET y en postgresql et je parle pas des group by, having, subselect et co ...)
Y'aura tjs des entreprises stupides pour utiliser les JAVA beans, J2EE et autres stupidités du genre.
Essaye, tu verra que c'est pas si stupide que ca (surtout quand ca apporte des tools genre Struts)...
[^] # Re: Le langage du futur ?
Posté par Erwan . Évalué à 2.
Ruby est completement objet, aussi objet que Java ou Smalltalk (je ne connais pas C#). Ca fait toute la difference. Avec Python si on ne fait pas gaffe on fait trop facilement du bidouillage.
Pour finir, Ruby a des approches fonctionnelles sur pas mal de point et ca aussi c'est un vrai bonheur. Le fait de pouvoir passer un bloc d'instruction en parametre d'une fonction aussi, c'est un vrai bonheur. Ca permet une conception tellement plus belle.
Au Japon Ruby est plus populaire que Python. Souhaitons-lui le meme succes dans le reste du monde...
[^] # Re: Le langage du futur ?
Posté par Marc (site web personnel) . Évalué à 0.
[^] # Re: Le langage du futur ?
Posté par Pascal Terjan (site web personnel) . Évalué à 0.
[^] # Re: Le langage du futur ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
Heu, je me rappelle ne pas les avoir trouvé et je viens de reverifier dans l'excellente documentation Ruby et je vois nul part ecrit quelque chose a propos des Interfaces et Abstract au sens java du terme... Qui sont quand meme bien utile dans la programmation objet...
[^] # Re: Le langage du futur ?
Posté par Fabimaru (site web personnel) . Évalué à 4.
Tout est clean ? Comme le "réference counting" pour gérer les objets (d'où le nettoyage de la dépendance entre objets à la main parfois, faibles perfs en multithread), ou alors l'impossibilité d'avoir deux interpréteurs dans un même process.
J'aime beaucoup python (je l'utilise à tours de bras), mais tout n'est pas génial.
# Re: Le langage du futur ?
Posté par Tutur . Évalué à 7.
Le C est adapté pour la programmation de systéme, mais dans presque tout les autres cas, ce n'est pas le bon choix. Nombre de programme gagnerais a être reécris dans d'autres languages. Le gain apporté en rapidité d'execution (ce qui n'est pas toujours vrai) et souvent trop important par rapport aux differents emmerde crée par ce language. C'est aussi l'un des languages où reprendre du code fait par d'autre est le plus chiant.
En fait le probléme c'est que l'apprentissage d'un language n'est pas seulement un question de mots clefs et de grammaire. C'est aussi une philosophie. On ne programme pas en perl comme on programme en C, idem pour les autres languages.
[^] # Re: Le langage du futur ?
Posté par Tutur . Évalué à 1.
s/souvent trop important/négligeable/
[^] # Re: Le langage du futur ?
Posté par jigso . Évalué à 8.
Transcrire un algo dans un langage donné n'est qu'un exercice technique, mais inventer un algo ou imaginer une architecture efficace est la partie rééllement productive et interressante du travail d'un informaticien. Malheureusement les formations insistent plus souvent sur tel ou tel langage et non sur les concepts...
Nombre de programme gagnerait a être reécris dans d'autres languages.
Non, nombre de programme gagnerait a être reécris par d'autres programmeurs !
"Il n'est pas de langage avec lequel on ne puisse faire de mauvais programmes" (anonyme)
[^] # Re: Le langage du futur ?
Posté par Moby-Dik . Évalué à -4.
Nombre de programmes gagneraient surtout à être moins réécrits... Combien d'éditeurs de texte sous Linux ?
[^] # Re: Le langage du futur ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Le langage du futur ?
Posté par Nÿco (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par bmc . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Nico . Évalué à 2.
[^] # Re: Le langage du futur ?
Posté par Ramso . Évalué à 3.
[^] # Re: Le langage du futur ?
Posté par wismerhill . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Erwan . Évalué à 1.
Et surtout, chaque langage a son approche (on va dire qu'il y a des familles de langages, et que certains concepts sont mis en avant) donc il ne vaut mieux pas programmer independament du langage.
Tu peux faire de l'objet en C, mais c'est plutot galere. De la meme facon tu peux faire de la programmation imperative en Lisp/Scheme (plein de variable, des boucles while au lieu de recursivite...) mais c'est vraiment bete.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à -1.
C'est moi ou c'est une énorme connerie ?
[^] # Re: Le langage du futur ?
Posté par Yusei (Mastodon) . Évalué à 2.
On peut faire de l'objet en C, ça demande juste de la discipline et un paquet de macros. Cf. GTK par exemple, qui implémente un modèle objet en C.
[^] # Re: Le langage du futur ?
Posté par tanguy_k (site web personnel) . Évalué à -1.
GTK par exemple, qui implémente un modèle objet en C... est une énorme connerie !
Et pour avoir longtemps essayer GTK puis d'autres solutions je confirme.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à 0.
D'ailleur je me pose une question toute conne : mais pourquoi ceux qui ont codé GTK n'ont pas penser à utiliser C++ ? Même si c'est pas entirèrement objet ca aurait suffit à leur besoins puisque de toute façon le résultat est le même (du pseudo-objet qui n'en sera jamais puisque le concept objet est une notion propre au langage et à la SYNTAXE)
[^] # Re: Le langage du futur ?
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Obsidian . Évalué à 3.
Je trouve - personnellement - et sans attaque personnelle qu'assimiler la programmation orientée objet en langage C à une énorme connerie est une erreur de débutant. Ce genre d'activité peut même être très bénéfique parce qu'elle permet de dissocier le concept même de programmation objet du langage lui-même. C'est vrai dans les deux sens d'ailleurs: les mauvais programmeurs C++ ont souvent tendance (pour les listings que j'ai pu lire) à instancier un objet de leur création simplement pour pouvoir invoquer les méthodes qu'il contient, séquentiellement.
Depuis que l'informatique s'est démocratisée et que la programmation est enseignée - plus ou moins - sérieusement dans les écoles, il y a un (trop) grand nombre d'élèves programmeurs qui se bornent à apprendre leur cours sans se poser de question, ce qui est problématique dans un milieu où le métier change d'aspect tous les six mois. Pour la plupart: C=Langage procédural C++=Orienté Objet et la frontière entre les deux est infranchissable.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à 0.
[^] # Re: Le langage du futur ?
Posté par Obsidian . Évalué à 1.
Non, c'est une erreur. C'est un peu comme dire que la poésie ne peut s'exprimer qu'avec des vers, et réciproquement.
class Toto
{
public:
int x;
private:
int y;
}
int main (void)
{
Toto t;
int x;
for (x=0;x<sizeof(t);++x) *(((char *)&t)+x)=0; // Ecrase tout.
return 0;
}
Et voila, j'accède aux membres privés de l'objet "t".
La seule chose qui puisse m'empêcher de faire cela est un typage fort. Cela n'a rien à voir avec l'orienté objet. La POO est une vue d'esprit. Il ne faut jamais oublier que les différents appels aux méthodes d'un objet en particulier seront résolus en sauts vers des fonctions, évidement en exemplaire unique en mémoire, et qui recevront implicitement un pointeur ou une référence sur les données de l'objet qui se résume à une simple structure de données. D'ailleurs il me semble même qu'en Python, l'équivalent de "this" est passé explicitement (je ne fais pas de python).
En ce sens, GTK+ et même la X-lib ont une approche orientée objet de la chose. Il peut exister plusieurs entités appartenant à une même catégorie, et sur lesquels peuvent par conséquent s'appliquer toute une batterie de fonctions destinées à la gestion des objets de cette catégorie. Exemple: les Drawables. Le fait que l'on invoque ces facilités à l'aide d'une méthode d'un symbole donné, ou que l'on se réfère à cette entité un utilisant un handler sous la forme d'un entier transmis à l'appel de la fonction revient au même.
D'autre part, il faut également toujours garder à l'esprit que tout le code écrit sera au final traduit en langage machine. La programmation ne s'aborde pas comme un problème mathématique dans lequel la finalité ne consiste qu'à résoudre une équation. Chaque action consomme des ressources en temps système et en mémoire, et il appartient au programmeur de connaître ses spécificités, et éventuellement d'utiliser des raccourcis si cela est profitable à l'utilisateur final. D'une manière générale, l'optimisation d'un programme devrait à mon goût occuper autant de temps que la rédaction et le débuggage de ce programme. C'est spécialement vrai lorsque l'on utilise un langage interprété ou un système de byte-code.
Tout cela pour dire que l'approche objet est un framework comme un autre. L'utilisation d'un langage orientée objet est une chose naturelle lorsque tout un projet est axé autour de ce concept, mais c'est loin d'être une nécessité.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Tu prends un environnement d'exécution qui intègre des notions objets comme .NET et alors là tu peux te toucher pour espérer accéder à une fonction private depuis un objet externe en C#, VB.NET ou Java. Sauf bien sûr en allant toi même faire la bidouille avec des pointeurs en C++ par exemple. Celà dis ton code ne sera alors plus sécurisé et tu devras le déclarer explicitement au compilateur.
Tu remarqueras aussi qu'une autre notion de la programmation objet, l'héritage (et tout ce qui touche la réutilisation) est possible quelque soit le langage sur la plate-forme .NET. Tout ça parcque les langages ont une seule contrainte : implémenter certaines notions objet.
Evidemment, si tu programme en natif, tout code sera au final traduit en code machine et vu que la machine autorise à peu près tout et n'importe quoi (à l'intérieur d'un même programme j'entend, l'OS est là pour limiter les débordement éventuels). Mais l'informatique a évoluer. Et certain ont su tirer partie justement de la sémantique de ces nouveaux langages dits "orientés objets" pour améliorer la sécurité ou tout simplement l'interopérabilité et l'intégration en implémentant une machine virtuelle qui utilise ces informations.
Tu peux continuer à insister que la POO est un simple concept dans la tête, moi je suis persuader que la POO va plus loin et fournit des informations supplémentaire à la machine que des langages comme C ne peuvent exprimer. Juste pour le fun, j'aimerai savoir avec quelle simplicité tu vas réussir à instancier un pseudo-objet en C de GTK en Java, sans bien sûr refaire une surcouche qui te demanderas des heures et la nécessaire compréhension du mécanisme pseudo-objet de GTK...
Pour ce qui est des optimisations je ne suis pas du tout d'accord avec toi. Pour moi ce n'est pas au programmeur de connaître les spécificités de la machine pour laquelle il code, sauf peut-être si celui-ci code en assembleur. Le programmeur doit pouvoir utiliser le langage pour exprimer ses idées et algorithme, c'est au compilateur d'optimiser pour une machine spécifique. Et c'est là qu'un langage objet s'avère plus utile que le langage C par exemple : le langage purement objet introduit des informations supplémentaires au compilateur qui peut effectuer plus de vérifications, d 'optimisation.
Pour ce qui est des optimisations par le programmeur, celles-ci ne doivent s'effectuer qu'au niveau de l'algorithme en diminuant la complexité de celui-ci si nécessaire. Bref, modifier son idée. Mais en aucun cas il ne doit bidouiller et utiliser des "raccourcis" pour que celà soit profitable à l'utilisateur. Tout d'abord c'est une perte de temps vu le gain final, et ensuite la plupart des machines actuelles ont suffisament de puissance pour faire tourner la plupart des algorithmes utilisés par le commun des programmeurs.
Après il y a deux niveaux de programmation : il y a la programmation système ou un langage bas-niveau comme le C est utilisé, par soucis d'optimisation. Mais c'est limité aux programmeurs expérimentés qui maîtrise les pointeurs à merveille (le pointeur c'est comme un scalpel, dans des mains expertes il fait des merveilles, mais donner les au programmeur de base...)
Si on veut programmer par "objet" dans ce contexte (par soucis de structuration et de lisibilité), on utilisera le C++.
Si on veut utiliser toute la sémantique qu'introduit les notions objets et qu'on veut notamment appuyer les notions l'interopérabilité ou de sécurité, on prendra un vrai langage objet, et si possible une machine (virtuelle) qui exploite justement ces notions...
[^] # Re: Le langage du futur ?
Posté par Obsidian . Évalué à 2.
SU-PER. Tu prends exemple sur le langage C++ qui comme tout le monde le sait n'est pas un langage 100% objet et qui permet de faire tout et n'importe quoi (grâce -- ou à cause -- des pointeurs). Tu prends un environnement d'exécution qui intègre des notions objets comme .NET et alors là tu peux te toucher pour espérer accéder à une fonction private depuis un objet externe en C#, VB.NET ou Java.
C'était un EXEMPLE ! L'exemple bête de ce qu'il ne faut pas faire justement, mais qui met bien en évidence le fait que ta « protection » n'en est pas une. Je ne pensais vraiment pas être obligé de te l'expliquer.
Ensuite et surtout: Encore une fois, il s'agit de la force du typage de ton langage ! Cela n'a rien à voir avec le fait qu'il soit orienté objet ou pas.
Tiens, de la même façon, et puisque l'on parle du C++, tu as l'air de penser que l'une des grandes forces de « l'orienté objet » réside dans la répartition public/private. Soit. En C++, il existe une troisième catégorie: protected. Révolution ou hérésie ? Cela te poserait-il un problème si les différentes catégories de données membres se multipliaient ?
Tu remarqueras aussi qu'une autre notion de la programmation objet, l'héritage (et tout ce qui touche la réutilisation) est possible quelque soit le langage sur la plate-forme .NET. Tout ça parcque les langages ont une seule contrainte : implémenter certaines notions objet.
Ok, vu tes lectures, je commence à comprendre. Il n'y a pas que du mauvais chez Microsoft, mais si c'est là ta référence de base pour assimiler les autres langages, tu risques d'avoir une vision quelque peu déformée du fonctionnement d'un ordinateur.
Evidemment, si tu programme en natif, tout code sera au final traduit en code machine et vu que la machine autorise à peu près tout et n'importe quoi (à l'intérieur d'un même programme j'entend, l'OS est là pour limiter les débordement éventuels). Mais l'informatique a évoluer. Et certain ont su tirer partie justement de la sémantique de ces nouveaux langages dits "orientés objets" pour améliorer la sécurité ou tout simplement l'interopérabilité et l'intégration en implémentant une machine virtuelle qui utilise ces informations.
1) Je te file une VCS2600 avec une cartouche vierge de 4Ko et je te demande de réécrire Space Invader et de le faire tenir dans le médium fourni. Si tu ne peut pas le faire alors que tes prédécesseurs l'ont fait vingt ans avant toi et sans langage objet, c'est que ce n'est pas une évolution.
2) Si tu utilises une JVM comme garde-fou parce que tu estimes que ton programme ne pourra fonctionner de façon sûre que dans ce genre d'environnement, c'est toi qu'il faut remettre en cause. Pas ta machine. Comment feras-tu le jour où tu devras à ton tour écrire une machine virtuelle ?
3) Parlons-en de la portabilité: Un programme écrit dans un langage de haut-niveau fonctionnera sur toutes les machines ... sur lesquelles la librairie standard et la machine virtuelle du langage auront été portées ! Ce qui limite déjà les différents modèles. Ensuite, il fonctionneront exactement de la même façon: A quoi cela sert-il d'avoir des machines différentes alors ? Une machine peut très bien être en avance sur ses concurrentes parce qu'elle apporte une killer-feature, comme on dit. Le programmeur Java/.Net est-il condamné à ne jamais en profiter ? Enfin, et là c'est le concept même de .Net que je remet en cause: A quoi diable cela sert-il de créer une machine virtuelle qui ne tourne que sur un seul système d'exploitation (Windows) et 99,99% du temps sur un PC ? Autant revenir directement à l'assembleur s'il y a si peu de variété.
Juste pour le fun, j'aimerai savoir avec quelle simplicité tu vas réussir à instancier un pseudo-objet en C de GTK en Java, sans bien sûr refaire une surcouche qui te demanderas des heures et la nécessaire compréhension du mécanisme pseudo-objet de GTK...
Pourquoi « pseudo » ?
- Sous GTK+ en C, c'est:
window1 = gtk_window_new (GTK_WINDOW_TOPLEVEL);
- En Java, ce sera
window1 = new gtk_window (GTK_WINDOW_TOPLEVEL);
L'un sera un handler, l'autre une référence, ce qui pour un langage comme le Java revient exactement au même compte-tenu du fait que l'adresse mémoire effective est gérée par la seule JVM, au dessous encore du niveau du bytecode.
Pour ce qui est des optimisations je ne suis pas du tout d'accord avec toi. Pour moi ce n'est pas au programmeur de connaître les spécificités de la machine pour laquelle il code, sauf peut-être si celui-ci code en assembleur. Le programmeur doit pouvoir utiliser le langage pour exprimer ses idées et algorithme, c'est au compilateur d'optimiser pour une machine spécifique.
Non, non, non et non. D'abord, c'est à se demander si tu as effectivement jamais écrit une ligne d'assembleur. Que le programmeur choisisse le langage le mieux adapté à son projet est une évidence (et c'est vrai dans les deux sens: Je programme un microcontrôleur en assembleur et une librairie graphique en C++), tout comme un compilateur se doit de générer le code le plus efficace possible. PAR CONTRE: connaître le fonctionnement d'un ordinateur, c'est précisément le métier du programmeur ! Tu ne peux pas faire de code propre si tu n'as aucune idée de la manière dont ta machine va exécuter tes ordres, de même que ton compilateur ne pourra jamais sérieusement optimiser un code plombé de naissance.
Et c'est là qu'un langage objet s'avère plus utile que le langage C par exemple : le langage purement objet introduit des informations supplémentaires au compilateur qui peut effectuer plus de vérifications, d 'optimisation.
Cela n'a aucun sens.
En quoi le fait que ton langage soit « objet » apporte des informations supplémentaires au compilateur ? Au contraire, la plupart des langages objet, C++ en tête d'ailleurs, ont la fâcheuse réputation de consommer plus de mémoire pour un même résultat.
Pour ce qui est des optimisations par le programmeur, celles-ci ne doivent s'effectuer qu'au niveau de l'algorithme en diminuant la complexité de celui-ci si nécessaire. Bref, modifier son idée. Mais en aucun cas il ne doit bidouiller et utiliser des "raccourcis" pour que celà soit profitable à l'utilisateur. Tout d'abord c'est une perte de temps vu le gain final, et ensuite la plupart des machines actuelles ont suffisament de puissance pour faire tourner la plupart des algorithmes utilisés par le commun des programmeurs.
o/* PAF !
Encore une idée reçue qui a la dent dure et c'est probablement ce qui nous oppose le plus. La puissance d'une machine doit profiter à son utilisateur et pas servir la paresse du programmeur (paresse qui n'est, chez ce programmeur, une qualité que lorsqu'elle le pousse à utiliser sa machine pour accélérer son travail, mais pas au dépit de l'utilisateur). D'abord, tu oublies que contrairement aux machines familliales des années 80, les ordinateurs actuels sont multitâches, et qu'il suffit de faire tourner quatre ou cinq programmes écrits par des gens qui ont la même mentalité que toi pour mettre une machine en carafe.
Lorsqu'un codeur écrit avec les pieds un programme utilisant un langage de trop haut niveau (spécialement lorsqu'il est interprété, ou sous forme de bytecode), 80% de la puissance de la machine est consommée dans les conversions successives entre ces couches, dans un sens puis dans l'autre, et cette puissance ne profite:
- ni au programmeur, qui ne se soucie plus de son programme une fois livré,
- ni à l'utilisateur qui passe ses journées entières à attendre son logiciel.
D'autre part, optimiser un programme ne se limite pas à « simplifier l'algorithme utilisé », mais aussi à parler le langage de ta machine. Tu oublies qu'un compilateur est avant tout un traducteur. C'est comme si tu me disais qu'il est inutile d'apprendre une langue étrangère parce que les traducteurs logiciels le font pour nous. As-tu déjà jaugé la qualité des traductions de Babelfish ? Il m'est arrivé de multiplier la taille d'une ligne de C par 5 pour qu'elle soit au final compilée de la meilleure manière possible.
C'est bien la mentalité Microsoft, ça. On sort un produit tordu à la base, et on applique des patches successifs plutôt que de revoir le concept.
Enfin, le « gain final » dont tu parles est à mesurer avec la plus grande circonspection. Il suffit que tu intègres le code concerné au sein d'une boucle pour que le gain en question ne soit plus une durée fixe mais un pourcentage du temps consommé. Ainsi, si tu écris ton programme en assembleur, et que tu l'optimises pour passer de 10 cycles machines par boucle à 5 cycles (soit 2ns de gain sur une machine moyenne), tu doubles la vitesse de ton programme. Un travail réalisé initialement en deux mois le sera désormais en un seul.
Après il y a deux niveaux de programmation : il y a la programmation système ou un langage bas-niveau comme le C est utilisé, par soucis d'optimisation. Mais c'est limité aux programmeurs expérimentés qui maîtrise les pointeurs à merveille (le pointeur c'est comme un scalpel, dans des mains expertes il fait des merveilles, mais donner les au programmeur de base...)
Personnellement, je n'ai jamais eu de problème à manipuler un pointeur. Peut-être parce qu'à la base je savais ce qu'est une adresse mémoire. Tout le problème est là: On n'écrit pas un programme (du moins pas professionnellement) pour adapter une équation tout comme on utiliserait Mathlab pour résoudre un problème de maths, de la même façon que, si puissant qu'il soit, mathlab ne te sera d'aucune utilité si à la base tu es nul en maths ...
Et puis surtout, la disponibilité des données est un problème qui se retrouve sur tous les langages:
- En C/C++ le programmeur se tape des segfaults;
- En Java, le programmeur se tape des NullPointerException.
« Ah bon ? Mais Monsieur, je croyais qu'y'avait pas d'pointeurs en Java ... »
C'est quand même inouï. L'informatique est quand même le seul métier où non seulement « le néophite complet se sent en mesure de vous apprendre votre métier dans le quart d'heure qui suit le montage de sa bécane », mais c'est également le seul où on l'on trouve des gens qui aspirent à devenir professionnels sans vouloir apprendre le métier. Un programmeur qui ne sait pas comment fonctionne un microprocesseur - et qui en plus le revendique - est pour moi un paradoxe.
Si on veut utiliser toute la sémantique qu'introduit les notions objets et qu'on veut notamment appuyer les notions l'interopérabilité ou de sécurité, on prendra un vrai langage objet, et si possible une machine (virtuelle) qui exploite justement ces notions...
Là encore, et pour la dernière fois, machine virtuelle et orienté objet sont deux choses distinctes, même si on les trouve souvent livrés ensemble. D'ailleurs le concept de machine virtuelle n'est pas nouveau, il est utilisé depuis les années 70 mais pas en microinformatique. Plutôt sur gros systèmes, tels que ceux que l'on trouve dans les aéroports.
Ton post me laisse perplexe, pour le moins. J'ai l'impression que tu confonds plusieurs notions, notament typage, sécurité, et approche objet, de la même façon que Jayce the Crazychild confondait mode texte et langage interprété (là, 'faut quand même le faire, soi dit en passant) ou, plus sérieusement, comme beaucoup de monde assimilait programmation 32 bits et mode protégé lors des débuts de Win32.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Comme je le disais, tu as pris exemple sur un langage qui n'est pas 100% objet et qui justement te permet de faire ce genre de conneries. D'où l'intérêt d'un langage qui tend à utiliser au maximum les notions objets.
Que ce soit le typage qui me permette de résoudre ce problème dans mon langage, Ok. Et alors ? Si ça me permet de mieux respecter un principe objet d'encapsulation ? Pourquoi s'en passer ?
Pour le protected moi perso ça ne me dérange pas, il peut avoir une utilité. D'ailleur tu verras que d'autres langages utilisent encore d'autres mot supplémentaire : internal par exemple ;) (je te laisse trouver le langage puisque tu as une expérience bien plus élevée que moi en la matière)
Ok, vu tes lectures, je commence à comprendre. Il n'y a pas que du mauvais chez Microsoft, mais si c'est là ta référence de base pour assimiler les autres langages, tu risques d'avoir une vision quelque peu déformée du fonctionnement d'un ordinateur.
Tu crois franchement que j'ai commencé à code sur .NET alors que ca ne fait qu'à peine 2 ans que ca existe ?
1) Je te file une VCS2600 avec une cartouche vierge de 4Ko et je te demande de réécrire Space Invader et de le faire tenir dans le médium fourni. Si tu ne peut pas le faire alors que tes prédécesseurs l'ont fait vingt ans avant toi et sans langage objet, c'est que ce n'est pas une évolution.
Et ? tu cherches à montrer quoi là ?
2) Si tu utilises une JVM comme garde-fou parce que tu estimes que ton programme ne pourra fonctionner de façon sûre que dans ce genre d'environnement, c'est toi qu'il faut remettre en cause. Pas ta machine. Comment feras-tu le jour où tu devras à ton tour écrire une machine virtuelle ?
Je ne dis pas que j'utilise une VM (y'a pas que JVM ;) ) comme garde-fou mais comme machine capable d'exprimer et de respecter au mieux les informations introduite par les notions objets. J'utilise également une VM pour pouvoir utiliser le langage le plus adapté selon la partie de l'application que je rédige, sans avoir à me soucier de l'interopérabilité entre les composant de mon appli.
Oui j'avoue je programme avec .NET, mais parcque ils ont introduit un CLR (Common Langage Runtime) dédié à faire tourner n'importe quel langage, pourvu qu'il soit OBJET (parcque justement la VM en tire partie) et parcqu'elle introduit des un ensemblre de types de bases autre que le simple mot mémoire.
Pour le jour où j'aurai à rédiger une machine virtuelle, désolé je dois être con mais je vois pas ce que tu veux dire.
3) Parlons-en de la portabilité: Un programme écrit dans un langage de haut-niveau fonctionnera sur toutes les machines ... sur lesquelles la librairie standard et la machine virtuelle du langage auront été portées ! Ce qui limite déjà les différents modèles. Ensuite, il fonctionneront exactement de la même façon: A quoi cela sert-il d'avoir des machines différentes alors ? Une machine peut très bien être en avance sur ses concurrentes parce qu'elle apporte une killer-feature, comme on dit. Le programmeur Java/.Net est-il condamné à ne jamais en profiter ?
Au niveau de la machine physique, ces killer-features comme tu dis ne peuvent pas apporter grand chose directement au programmeur. Les optimisations peuvent se faire au niveau de la VM qui apportera tout de suite le gain à lappli qui tourne au dessus... Et puis franchement, une VM apporte beaucoup plus de "killer-features" qu'une simple architecture processeur... d'ailleur un des autres intérêt des machine virtuelles c'est aussi de favoriser la diversité des architectures processeurs, il n'y a pas besoin de recompiler tous les progs, juste la VM et les biblio qui vont avec.
Encore une fois, je ne vois pas trop l'intérêt, en dehors de l'assembleur et parfois du C de programmer pour un processeur spécifique. A part peut être pour coder sur un proc très lent avec très peu de mémoire, mais c'est loin tout ça maintenant...
Pourquoi « pseudo » ?
- Sous GTK+ en C, c'est:
window1 = gtk_window_new (GTK_WINDOW_TOPLEVEL);
- En Java, ce sera
window1 = new gtk_window (GTK_WINDOW_TOPLEVEL);
nan t'as pas compris ma question. Je ne te parle pas des différence de syntaxe mais du passage de l'un à l'autre Je voulais justement te demander comment tu passes du C à Java sans perdre ton temps à réécrire un wrapper intermédiaire tout ça parcque ton langage de base simulait l'objet. Le langage C exprimerait des notions objets, elles auraient pu être directement wrapper automatiquement pour être utilisables en Java...
Non, non, non et non. D'abord, c'est à se demander si tu as effectivement jamais écrit une ligne d'assembleur.
Du 68k dans ma jeunesse et du x86 pendant mes études.
http://c2team.fr.st/(...) (matte les screenshots pris sur une TI89) pour voir ce que j'ai fait. C'est modeste mais j'ai fait tout le moteur graphique en 3D iso, alors les optimisations, voilà quoi... mais bon c'est peut-être pas un niveau suffisant pour toi...
Pour ce qui est du x86, j'avoue que je suis moins doué en la matière, je me contente de ce que j'apprends en cours. Enfin j'ai déjà rédigé quelques lignes de code (genre un noyau de syncrhonisation en asm avec une passerelle en C, et là d'ailleur on applaudit la manipulation des données en passant d'un langage à un autre, pourtant réputés comme très proche...)
J'ai également à travers mes études eu l'occasion de rédiger 2 compilateurs, pour 2 machines virtuelles (question de pratique, on ne peut pas avoir pleins de machines sous la main) complètement différente, une à pile, une autre basé sur du code 3 adresses.
Tu remarqueras que je ne remets nullement en doute tes compétences.
connaître le fonctionnement d'un ordinateur, c'est précisément le métier du programmeur. Connaître le principe de fonctionnement général de la plupart des ordinateurs (surtout si tu te limites aux ordinateurs), oui, c'est le boulot du programmeur. Connaître les spécificités de chaque machine, non, ça n'est pas son taf. Sauf pour le programmeur système. Si la machine virtuelle (ou le compilateur) fait bien son taf, c'est à elle de tirer partie des différente architecture.
En quoi le fait que ton langage soit « objet » apporte des informations supplémentaires au compilateur ? Au contraire, la plupart des langages objet, C++ en tête d'ailleurs, ont la fâcheuse réputation de consommer plus de mémoire pour un même résultat.
Comme je l'ai expiqué plus haut, les informations apportés au compilateurs sont justement celles liées aux notions objets. J'ai pris exemple sur l'encapsulation. Effectivement si le compilateur transforme le code en natif, toutes ces informations seront perdues et tu pourras faire n'importe quoi comme en C++ dans l'exemple que tu m'as donné. Si c'est une VM qui tourne dessous, et qu'elle est conçu pour justement exploiter toutes ces informations, alors elle prend tous son sens : tu pourras t'arracher à essayer d'accéder à un membre private si tu n'y est pas autorisé depuis un autre langage que le langage dans lequel tu as écris ta classe de base.
Lorsqu'un codeur écrit avec les pieds un programme utilisant un langage de trop haut niveau
Si le programmeur code avec les pieds dans un langage de haut niveau, il est à peu près certain qu'il codera encore plus avec les peids dans un langage de bas-niveau, ou alors il y met de la mauvaise volonté.
80% de la puissance de la machine est consommée dans les conversions successives entre ces couches
T'as déjà utilisé une VM bien foutue ? Si je prend exemple sut la machine virtuelle .NET elle compile le programme en natif avant la première exécution sur l'architecture cible. Pour avoir fait des tests basique, je n'ai pas vu de différence de rapidité entre du C++ natif et du C# sur .NET. Aller, je prend exemple sur Quake2.NET (http://www.codeproject.com/managedcpp/Quake2.asp(...)) qui tourne à 90% de la vitesse en natif.
Je crois qu'il va falloir abandonner ce mythe qui a la vie dur qu'une machine virtuelle ralenti considérablement une application... (évidemment, quand on parle VM, tout le monde penses Java, forcement...) :-p
D'autre part, optimiser un programme ne se limite pas à « simplifier l'algorithme utilisé », mais aussi à parler le langage de ta machine. Tu oublies qu'un compilateur est avant tout un traducteur.
On est bien d'accord, sauf sur les rôles. Simplifier l'algorithme utilisé c'est au programmeur de le faire. Opitmiser le code machine, c'est au compilateur ou à la machine virtuelle de le faire.
Pour ton exemple foireux de traducteur, tu remarqueras qu'il y a une différence entre un langage naturelle (parlé) et un langage informatique : il y en as un que l'ont peut exprimer sur ordinateur, et pas l'autre, un qui est exprimable par une grammaire, pas l'autre. C'est pour celà que les traducteurs de langages naturelles ne sont pas parfaits.
C'est bien la mentalité Microsoft, ça. On sort un produit tordu à la base, et on applique des patches successifs plutôt que de revoir le concept
Y dit qu'il voit pas le rapport (???)
Il suffit que tu intègres le code concerné au sein d'une boucle pour que le gain en question ne soit plus une durée fixe mais un pourcentage du temps consommé. Ainsi, si tu écris ton programme en assembleur, et que tu l'optimises pour passer de 10 cycles machines par boucle à 5 cycles (soit 2ns de gain sur une machine moyenne), tu doubles la vitesse de ton programme.
Ton exemple demande à être rédigé noir sur blanc pour plus de compréhension, mais si je ne m'abuse, tu as utilisé une astuce d'algorithmie pour diminuer la complexité de ton problème... tu n'as pas du tout fait d'optimisation propre à la machine...
Personnellement, je n'ai jamais eu de problème à manipuler un pointeur. Peut-être parce qu'à la base je savais ce qu'est une adresse mémoire.
Merci moi aussi je sais ce que c'est. Mais pour moi les pointeurs doivent être utilisé avec prudence, et seulement par un programmeur expérimenté et qui effectivement connaît bien les mécanismes internes à la machine. Seulement on parlait de programmation objet qui le plus souvent se passe également de la notion de pointeur, donc ne changeont pas de sujet.
- En C/C++ le programmeur se tape des segfaults;
- En Java, le programmeur se tape des NullPointerException.
Tu vois que le C++ a des inconvénients ;)
Pour le Java, désolé, j'aime pas Java, donc je ne peut que aller dans ton sens et dire que c'est tout à fait crétin d'obtenir ce genre de messages...
Un programmeur qui ne sait pas comment fonctionne un microprocesseur - et qui en plus le revendique - est pour moi un paradoxe.
Si ça m'est adressé, mdr. Sinon je suis d'accord que certains programmeurs "pro" ferais mieux de regarder de plus près le ofnctionnement interne de la machine. Mais pas forcement de toutes les machines qu'il utilise, notamment s'il utilise un langage de haut niveau. Et puis s'il est futé et qu'il utilise une machine virtuelle, il n'aura besoin d'apprendre le fonctionnement que d'une seule machine qui elle regroupe la plupart des concepts des architectures processeurs ;)
Ton post me laisse perplexe, pour le moins. J'ai l'impression que tu confonds plusieurs notions, notament typage, sécurité, et approche objet, de la même façon que Jayce the Crazychild confondait mode texte et langage interprété (là, 'faut quand même le faire, soi dit en passant) ou, plus sérieusement, comme beaucoup de monde assimilait programmation 32 bits et mode protégé lors des débuts de Win32.
Je confond surement certaines notions, mais pour la bonne raison que pour moi elles sont complémentaire et le plus souvent liées quand toi tu préfères les dissocier entièrement. C'est sans doute là la grande différence...
PS : ouh ca va commencer à faire long tous ces posts ;)
# Re: Le langage du futur ?
Posté par Yusei (Mastodon) . Évalué à 4.
Un langage qui apporte vraiment quelque chose à la manière dont on écrit le programme, pas une pseudo-nouveauté comme Java qui n'apporte pas grand chose par rapport au C++ (au niveau du langage, pas des bibliothèques ou de la machine virtuelle, hein).
[^] # Re: Le langage du futur ?
Posté par Erwan . Évalué à 1.
Developper dans un langage de script est tellement plus rapide ! C'est une evolution naturelle: avant on considerait que le bas niveau c'etait l'assembleur et le haut niveau le Pascal, voire le C/C++. Maintenant plus personne ne programme en assembleur.
[^] # Re: Le langage du futur ?
Posté par Tonton Th (Mastodon) . Évalué à 2.
Si tu apprécie ce genre de sport, regarde Lua, qui est fait pour ça.
http://www.lua.org/(...)
[^] # Re: Le langage du futur ?
Posté par Ramso . Évalué à 3.
Heu si en électronique... ha non raté, ils se mettent au Basic.
[^] # Re: Le langage du futur ?
Posté par Ackira . Évalué à 2.
Sinon moi je pense que le langage du futur c le pike :
http://pike.ida.liu.se/(...)
Je vous laisse découvrir les arguments sur le site officiel .
[^] # Re: Le langage du futur ?
Posté par Moby-Dik . Évalué à 1.
Personnellement, j'en pense qu'ils ont au moins dix ans de retard :
"the idea has been to remove the extra layers between different parts of software, which complicate programming and create bugs."
Oui, l'abstraction, c'est pourri.
"However, the overall application programming design is intended for easy 32 bit asm programming. The GUI is extremely easy to handle with assembly language."
C'est portable ça dis donc. Comment ils font ceux qui veulent passer en x86-64 (aka AMD64) ?
[^] # Re: Le langage du futur ?
Posté par fragbait . Évalué à 2.
Pas terrible en terme de crédibilité.
"L'abstraction c'est pourri " : non ce qui est souvent pourri c'est la façon de l'implémenter ou une nouvelle version de "l'important c'est pas la chute, c'est l'aterrissage".
Mon expérience toute relative de la programmation m'incite à penser que la grande qualité de l'abstraction c'est de permettre de ne pas programmer.
Donc l'abstraction a un intérêt si elle permet à des idiots, plus ou moins, de programmer à la place de celui qui la produit.
Le langage du futur ? C je suppose. A moins que l'assembleur 32bit ou 64 bit ne soit devenu lisible et maitrisable...
Je peux prédire l'avenir de la programmation objet : le mème que celui de la programmation structurée ==> la chute aprés son apogée.
Le problème principal de la programmation, dans le temps, c'est la maintenance, au cas ou ce truisme permettrait à quelqu'un de situer de quoi je parle.
Dés lors qu'on évolue culturellement, et en ce moment ça va assez vite, toute programmation basée sur des contraintes culturelles, conceptuelles ou trivialement abstraites, est vouée à disparaitre dans les sables du temps.
Le langage du futur ne sera pas objet, pas particulièrement en tout cas (on peut faire de l'objet avec tout langage, comme la programmation structurée ne nécessitait pas un langage qui la facilitait pourtant ),
le langage du futur permettra une utilisation performante sur des plates formes trés petites, Java se porte sur les mobiles, il est probable qu'on ira encore plus bas.
Avec des agents de plus en plus petits, de moins en moins cher, dont la programmation sera de plus en plus répandue dans la population, ce qui implique un niveau d'abstraction minimal, l'objet dans sa forme actuelle est trés trés loin de ça.
Purée mais j'aime les coups moi.
# Re: Le langage du futur ?
Posté par Jerome Herman . Évalué à 7.
Pour faire un peu plus long et avec plus d'arguments :
Le language du futur ca a ete Pascal. Le lenagage a apprendre absolument. Partout dans le monde on hurlait de grands bravos a la disparition du GOTO, personne en doutait qu'il allait y avoir la disparition complete des autres langages de programmation classique pendant que les bibliotheques Pascal allait croitre dans des proportions rares pour satisfaire els besoins en Math et en graphisme.
Plaf.
Quand Microsoft a annonce fin 95 debut 96 pendant une conference privee pour les studios de devollepement que bientot les devellopeurs feraient tous leurs jeux en win32 en utilisant l'API DirectX Microsoft et non plus en DOS, il y a eu un eclat de rire general dans la salle. D'ailleurs quelques mois plus tard Quake sortait en verison DOS pure et personne ne croyait a quoi que ce soit d'autre.
Le dev oriente objet etait une blague tres prisee des programmeurs il y a de cela 20 ou 25 ans, quand a la modelisation des donnees c'etait pour le moins chaotique (et le cobol n'y etait pas pour rien).
A mon humble avis personne ne sait quel tete aura un ordinateur demain. Victoire totale des PDAs ? Mini-stations ? Ordinateur central Tele/Multimedia+familial+bureautique+domotique+assistant personel ? On ne sait meme pas vers ou vont les processeurs ? Generalisation ? Multipuces avec specialisation ? Quantique pourquoi pas ?
Quels systemes tourneront dessus ? On s'oriente de plus en plus vers des VMs (Java, .Net, on Dye Python...) mais les VMs vont-elles continuer a chercher a coller au processeur (avec uen compilation JIT), va-t-on aller vers des solutions hybride (VMs+Porc morphant a la transmetta) ou au contraire les CPUs vont-ils integrer en dur le bytecode des VMs ?
Bien malin qui peut repondre.
Parcontre une chose est sure, la betise faite avec Cobol il y a 20 ans a ete refaite recamment. Si tu veux etre sur d'avoir un emploi assez longtemps et d'etre tres bein paye, etudie le langage/systeme que l'on met partout dans les grosses boites, pour faire tout et n'importe quoi et dont on va avoir du mal a se debarrasser dans dix ans, etudie SAP !
Kha
[^] # Re: Le langage du futur ?
Posté par pinky . Évalué à 0.
Car, maintenant, ce qui fait un bon langage n'est plus tellement le langage en lui même. C'est surtout dû à tout ce qui va à côté. (par contre, un mauvais langage est la faute du langage). Il est très facile de faire un bon langage, meilleur que tous les autres (surtout avec la connaissance de ceux-ci) seulement il est très diffiicile d'égaler les langages déjà très avancés. Par avancé, je veux dire: qui possèdent bcp d'utilisateurs, des sociétés de services autour du langage, des librairies travaillées et en nombre, de nombreux programmes, ...
Pour faire une comparaison rapide: Il y a 10 ans, on ne pouvait pas dire quel serait l'OS ou les OS d'il y a 5 ans. Aujourd'hui, on peut dire quels seront les OS de dans 5 ans: Windows et Linux. Et il y a pourtant des OS meilleurs que Windows et Linux, mais ca ne suffit plus. Je pense que c'est la même chose pour les langages.
Dans 5 ans, on aura donc: python et peut-être C#. (pour C#, ca dépend de MS.)
[^] # Re: Le langage du futur ?
Posté par Moby-Dik . Évalué à 2.
C'est vrai que Python est beaucoup plus connu et répandu (utilisateurs, sociétés de services, programmes, bibliothèques) que C, Java ou Perl. Ton argumentaire ne se contredit pas du tout...
[^] # Re: Le langage du futur ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2.
je suis actuellement en DESS(bac+5) en Ingénérie des systemes distribués. On avait un projet XML-RPC (par 2) a faire, tous les groupes ont pris Java To Java sauf 2 :
- C++ / Java pour un autre groupe
- Ruby / Python pour notre groupe.
Les gens de ma promo, et meme le prof qui est competent et plutot pro linux, quand ils ont entendu parler de Python, ils savaient vaguement que c'etait un langage de prog quant a Ruby, personne ou presque connaissait...
Alors que bon, les gens de ma promo sont dans l'ensemble vraiment compétents (une bonne partie avec 3/4 ans d'alternance en informatique dans de grandes boites).
Comme quoi (loin de moi l'idée de faire d'un cas particulier une généralité), faut etre realiste, OK, dans les PME, on va utiliser ces langages, mais dans les grandes entreprises, ils s'en tapent royal (et bon, mon binome et moi, on passe pour des révolutionnaires/associables a tourner sous Linux) :)
[^] # Re: Le langage du futur ?
Posté par Nicolas Tramo . Évalué à 2.
SAP / Java / Oracle / Microsoft. (en gros, y en a 2 ou 3 autres mais bon, pour le moment c'est surtout SAP).
Perl, y en a qui connaissent le nom.
Python, personne sait de quoi je parle.
Ruby, on commence a me parler de bijoux...
[^] # Re: Le langage du futur ?
Posté par Tonton Th (Mastodon) . Évalué à 4.
Cool, on va pouvoir faire de la programmation de goret en langage évolué :)
[^] # Re: Le langage du futur ?
Posté par Torquemada . Évalué à 1.
Parcontre une chose est sure, la betise faite avec Cobol il y a 20 ans a ete refaite recamment. Si tu veux etre sur d'avoir un emploi assez longtemps et d'etre tres bein paye, etudie le langage/systeme que l'on met partout dans les grosses boites, pour faire tout et n'importe quoi et dont on va avoir du mal a se debarrasser dans dix ans, etudie SAP !
super! un boulot sûr et bien payé pour tous dans 10 ans ;-)
Je vais bientôt finir mes études et je me disais justement qu'il fallait que je me mette à SAP.
Mais y a-t-il vraiment des alternatives open-sources à SAP?
Et par quoi pourrait-il être remplacé dans 10 ans?
# Re: Le langage du futur ?
Posté par Buto . Évalué à 2.
Celui qu'on apprend à l'école ca serait déjà un bon début...
[^] # Re: Le langage du futur ?
Posté par Marc (site web personnel) . Évalué à 0.
[^] # Re: Le langage du futur ?
Posté par Black Fox . Évalué à 1.
Je me sers fréquement de freepascal et delphi (Selon les besoins) et à part que je passe pour un extraterestre devans ma prof de BTS (VB / VB.Net Only) aucun problème. (J'ai installé delphi 6 Personnal Edition et Freepascal)
Le langage continue et passe à .Net pour la prochaine version et moi je sens que je vais passer à freepascal totalement carbien que .Net soit de qualitée j'ai pas envie de me bloquer sous MS.
[^] # Re: Le langage du futur ?
Posté par supergab . Évalué à 1.
Je ne suis pas vraiment programmeur mais, il me semble, que Pascal ne devrait pas être rejeté. Il offre des possibilités équivalentes à d'autres langages. En plus, il est souvent enseigné dans les écoles.
Pour ce qui est de VB, c'est un langage que je déteste et que je ne cesse de qualifier de "defficient".
# Le langage du futur ?
Posté par Lee Nux . Évalué à 3.
Plusieurs languages devront cohexister parce que chacun d'eux aura sa spécificité.
Je n'imagine pas, personnelement, le développement d'un window manager en PHP, de la même manière les CGI en C deviennent de plus en plus rares et dépassés.
Il est indéniable que les scripts web coté serveur sont dominés par PHP, Perl et dans une moindre mesure Python. Il est difficile de dire quel langage sortirait du lot, si cela devait arriver. En effet, PHP permet à tout débutant de créer facilement une page avec des scripts, alors que Perl sera plus difficile à aborder. Perl possède, par contre, un très grand respect de la part des professionnels. Pour Python, je serais moins catégorique, parce que moins facile d'accès que PHP pour les débutants, moins reconnus et supporté par les professionels.
Pour le développement d'application sur un système (ou ensemble de systèmes comme les Unices), je parierais toujours sur le C ou C++ selon le besoin d'utilisation de concepts objets ou pas. La raison est qu'aucun langage existant n'a réussi à les déloger jusqu'à présent. La raison me semble simple: Le nombre de développeurs et le nombre d'applications sous ce langage est si important qu'il faudrait développer un langage qui apporte un véritable avantage par rapport à C / C++ pour remettre en question ce parc de dévelopeurs et d'applications.
Pour de la programmation multi-environnement (principalement des clients), nous avons les langages de scripts (Perl principalement) mais surtout Java. Perl permet de s'affranchir des incompatibilités de compilation sur différents systèmes, mais Java possède une API très complète pour les fonctions d'affichage, de réseau, mathématiques, ... Sans parler de sa popularité et qu'il est plus fréquemment enseigné dans les écoles que Perl.
Je ne parlerai pas des langages fonctionnels, n'ayant pas de connaissances à ce sujet. Je peux simplement dire qu'ils permettent de faire des projets complexes : l'application la plus connue reste MLDonkey. Cependant, le choix d'un tel langage dans une application libre devrait être reconsidéré par deux fois. Le nombre de développeurs connaissant l'OCaml (pour l'exemple de MLdonkey) étant très faible, le nombre de contributeurs (pour participer au projet ou simplement patcher un bug) sera réduit à son strict minimum. Ceci peut également mener des utilisateurs ne pas utiliser une telle application, car le code source bien qu'étant disponible ne peut pas être déchiffré facilement sans apprentissage d'un nouveau langage.
De même, je ne parle pas de Visual Basic ou C#, car n'existant que sur plateformes MS.
Que reste-t-il donc aux langages comme Pascal, Ada, Objective C, Fortran, Cobol, ... Je dirais simplement les miettes. En ce qui concerne leur avenir, j'ose penser qu'ils existeront toujours, en grande partie grace à la communauté du libre qui continue à dévelloper ces compilateurs alors que le milieu du non-libre les ont complétement abandonnés. Mais ils ne se démarqueront plus et resteront marginaux, utilisés à des fins éducatives, pour le support d'anciennes applications originaires dans ces langages ou par curiosité de geeks.
Mon tiercé gagnant reste donc:
- PHP / Perl pour web scripting
- C / C++ pour applications sur un environnement
- Java pour applications portables (souvent clients)
# Re: Le langage du futur ?
Posté par Epsos . Évalué à 2.
Nosica ? http://www.nosica.net(...)
--- PUB EHONTE ---
# Re: Le langage du futur ?
Posté par manatlan (site web personnel) . Évalué à 0.
(c mon humble avis, et c ce que j'aimerai le plus ;-)
rien qu'à voir l'étendu des domaines que couvre python (... on ne peut vraiment pas en dire autant de ruby ... et consorts (sauf perl))
voici une url qui couvre partiellement tout ce que python peut faire : http://www.python-eggs.org/links.html(...) ... c'est impressionnant !
j'ai pratiqué : (outre le langage, et ses puissantes fonctionnalités d'introspection/reflectivité)
- faire de jolies applications graphiques avec wxpython
- faire des jeux avec pygame
- faire des applets/du java avec jython
- toucher du xml avec libxml2 (3x plus rapide qu'avec msxml4)
- faire du reseau avec twisted
- et livrer le tout en "exe" avec py2exe
et le tout multi-plateformes ... et très facilement ! et avec des temps d'execution plus que correct ... Que demande le peuple ?!
à un point où l'on peut presque dire ; que faire du python équivaut à faire du rad ... (habitué à powerbuilder/visual studio.net)
j'aime pas qu'on dise que ruby est mieux que python ;-)
ruby est très très loin de faire tout ça ... OK les type de base sont objets, mais dans la réalité (la vraie vie); ça ne sert à rien, à part à complexifer le travail de l'interpréteur/compilateur ... (ce n'est pas un troll, certes ça y ressemble)
cependant, il est vrai que chaque language a ses spécificités ... mais python touche vraiment à tout ... et plutot bien je trouve ... il mérite cette place assurément
[^] # Re: Le langage du futur ?
Posté par Matthieu BENOIST . Évalué à 2.
^_^ Banané !
[^] # Re: Le langage du futur ?
Posté par Erwan . Évalué à 0.
C'est pourtant vrai...
[^] # Re: Le langage du futur ?
Posté par Laurent Sansonetti . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Yusei (Mastodon) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
[^] # Re: Le langage du futur ?
Posté par Anonyme . Évalué à 1.
http://www.google.fr/statsq=ruby+exe&ie=UTF-8&oe=UTF-8&(...)
il y a vraiment beaucoup afficionados de ruby ici :)
[^] # Re: Le langage du futur ?
Posté par Laurent Sansonetti . Évalué à 1.
Je n'ai jamais essayé ni l'un ni l'autre mais ce dernier semble plus connu.
[^] # Re: Le langage du futur ?
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
# Re: Le langage du futur ?
Posté par Pierre Tramonson . Évalué à 3.
Et puis "dictature du C" muhahahahahah.
# Re: Le langage du futur ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Par contre ce qui est sur, du coté du développement des interfaces d'applications, c'est que celles-ci ne reposeront plus sur une API classique, mais sur des fichiers XML comme XUL dans Mozilla.
Il n'y a qu'à voir les dizaines de bibliothèques déjà disponibles en Java, en C/C++ etc, qui offrent une surcouche à GTK, swing ou AWT etc... (y a même un moteur pour PHP/GTK). Voir une liste exhaustive sur http://xul.sourceforge.net(...) . D'ailleurs MS l'a compris avec d'Avalon, le système graphique du futur windows, qui reposera entièrement sur XAML, un concurrent de XUL, mais aussi Macromedia, avec sa techno Flex, 100% pompé sur XUL.
L'avantage de ces interfaces à base de fichier XML, c'est que c'est utilisable pour une application web. Et XUL/Mozilla offrent déjà une belle plateforme pour faire ce genre d'appli. Cela permettra enfin de faire des trucs utilisables et ergnomiques (HTML est plutôt limité pour faire des interfaces digne de ce nom, de toute façon, il est pas fait pour ça).
Et puis, grâce à ce système de fichier XML, on pourra voir apparaitre des outils générateur d'interface graphique qui soient "universel" (à la limite, un coup de XSL pour transformer du XUL en XAML par exemple, ou l'inverse..).
Seul hic : il faudrait un standard, une normalisation de XUL ou equivalent afin ne pas avoir à réapprendre la roue à chaque passage d'une techno à une autre.
# Re: Le langage du futur ?
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
Mais peut-être que nous verrons bientot apparaitre des langages totalement innovant et plus adaptés à nos besoins.
[^] # Re: Le langage du futur ?
Posté par Pierre Tramonson . Évalué à 2.
[^] # Re: Le langage du futur ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.