Bonjour à tous et Bonne Année !  
Je suis nouveau sur ce forum, et d'après le peu que j'ai pu lire, vous m'avez l'air bien callé )
 
le post "malloc en C" ou quelquechose s'y rapprochant(rha je commence mal mon entrée   )m'a amené à me poser des questions, voilà je programme depuis bientôt 2 ans en C++ sous VC6, et je me demande s'il vaut mieux connaitre très bien un seul langage plutôt que de connaitre un peu de tout les langages.
sinon, un truc me chiffonne encore, dans 10-20 ans, les pc auront bien évolué(waa trop fort !) mais qu'en sera-t-il des langages de prog, les langages "bas niveau"(ASM,C) seront-ils toujours utilisés ? ou bien il nous faudra compter que sur du C+%#* ou "java 2GO" à très fort niveau d'abstraction, restera-t-il toujours une place pour le bas niveau ?
bien sûr, on ne peut pas prévoir l'évolution des pcs, mais le hardware grimpant très vite, il nous faudra des langages évolué tirant parti des spécifications techniques des derniers processeurs ou bien, on aura droit à des révisions des langages existants. encore une chose, de plus en plus, on mets en avant la portabilité des programmes(ce qui n'est pas un mal), mais à force, ne risque-t-on pas de surcharger l'interface utilisateur-machine de couches superflues ?(oula je me demande si qq1 va comprendre ce que je raconte )la portabilité va t elle annihiler la rapidité d'exécution d'un programme, qui sera compensé par des processeurs toujours plus puissants. pourra-t-on coder comme des porcs, et au final avoir un code super rapide ? En fait toutes ces questions, car j'aime travailler près de la machine, l'optimisation d'un code propre...et...bon je vais p'tet m'arrêter moi. Je crois que je suis fou de me torturer l'esprit comme ça  
 
bon je retourne me faire des galettes, c'est moins dur, et y'a de l'avenir dans la galette  
 
J'attends vos remarques et points de vue, ++A

 
quelques points :  

• Ceux qui ne conaissent que peu de langages on tendance à dire qu'en apprendre un nouveau est long et qu'il faut former les utilisateurs etc. donc on change pas. Donc y'a pas de raisons d'en apprendre d'autres et pas raisons que ça change d'ici 20 ans (ça fait déjà 20 que le C est en place). C'est la majorité.

Y'a une autre partie qui considère que plus tu connais de langages plus tu prends de la distance et plus tu t'améliores dans toutes les directions donc avec ceux-là au moins le C et la compatibilité du C++ avec le C auraient sauté il y a déjà 5-6 ans (si ce n'est tout le langage) et le crénau que tentent d'occuper C++ et java (qui aurait ses templates depuis 96) serait pris par Eiffel.
 

• Concernant l'abstraction que portent java et C++, ne t'emballe pas, on est encore assez loin des fonction d'ordre supérieur (à peu-près tous les langages courrament qualifiés de fonctionels, mais aussi smalltalk, self et d'autres), du "pattern matching" (règles de réécritures, caml et ses amis dérivées de ML essentiellement), de l'exécution fainéante ("lazy", l'exemple classique est l'évaluation d'un opérateur booléens dans un if en C, mais généralisié, comme Haskell, clean et des trucs plus exotiques), on est encore loin des fonctions non-déternimistes, qui "renvoient" plusieurs résultats d'un coup (clean est le seul exemple que je conaisse), des variables libres de clean des langages logiques etc. Sachant qu'il reste du boulot pour les chercheurs pendant encore un bon bout de temps dans ces domaines.

Mais attention, car lorsqu'un langage offre de la puissance, en général, les techniques de compilation et les stratégies d'exécution (de réduction) avancent, ce qui fait qu'aujourd'hui, un programme codé proprement dans un langage de haut niveau aura des perfs se rapprochant d'un de celles d'un langage de bas niveau, avec une maintenance plus aisée et une meilleure réutilisabilité. L'exemple typique est le problème du partage des pointeurs dans les langages à mémoire non gérée (C, C++), ils donnent lieu à des magouilles, qui finalement les rendent fragiles (calcul statique du graphe d'objet), gourmands en mémoire (copie profonde systématique), lents (pointeurs intelligents) ou énormes à l'écriture et la maintenance (inclusion d'un gestionnaire de mémoire "maison" dans l'application). Alors que dans le cas d'une mémoire gérée par un GC, la seule verrue au-delà du code de l'application est un éventuel réglage des paramètres du GC.
 
Comme je ne suis pas trop un futurologue illuminé, je ne spéculerais pas trop sur le reste de tes remarques.

et bien déjà merci, je ne savais pas qu'il existait un langage qui pouvait retourner plusieurs résultats, donc j'ai déjà appris qqchose )

merde, je me suis planté, c'est curry à la place de clean partout.
 
dans le cas de curry, c'est un "calcul" intermédiare qui peut retourner plusiseurs résultats, http://www.informatik.uni-kiel.de/ [...] torial.pdf
page 16-17 (18-19 dans acrobat).

Waaaouuuuuu, il dechire le nom de ton sujet. A l'avenir essaye de mettre un titre plus parlant, parce que si tout le monde met des sujets comme: "bonjour" ou "j'ai un probleme", on peut pas savoir a l'avance ceux qu'on va lire ou pas.

ouais, désolé, en même temps, ça résumait bien qd même, sinon je pense que mon sujet aurait été un peu long