Je suis entièrement d'accord avec toi!Envoyé par kourkoul
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
Je suis entièrement d'accord avec toi!
@lavock,
Quand je dis autodidacte, c'est parce que j'ais beaucoup plus apris en 25 années de travail qu'en 1 années a plein temps de l'etude du language C et d'un peux d'assembleur. Surtout qu'as l'epoque internet n'existait que sur les sited Digital avec les reseaux de proxi. Je ne suis pas non plus plus surdoué qu'un autre j'ais juste appris l'essentiel, TCP IP, LEs datagrammes, tubes, socket, IPC, semaphire et j'en passe, surtout les primitive, les Processus exct.
M'enfin je n'ais pas fait d'école d'ingénieur c'est tout, donc dans se monde je suis plutot considérer comme autodidacte. Au fait j'ais eu la chance d'avoir un excelent professeur durant cette année.
<HS>
Si seulement c'était vrai ... qu'est-ce que cela serait bien.
<moins HS>
Car, quand il s'agit d'apprendre un outil (en support d'une théorie), autant apprendre à s'en servir correctement...
</moins HS>
Oui, je préfère clairement voir utiliser une implémentation de la lib standard, que de devoir utiliser une bibliothèque programmée par quelqu'un pensant faire mieux que les autres (peut-être à raison) que ses collègues ne sauront jamais maintenir (il ne faut pas se leurrer, développer une lib de TAD et assembler des TAD dans une optique métier, ben ... c'est pas le même métier ni les mêmes compétences qui sont attendues).
Tu m'as l'air d'avoir eu une mauvaise expérience avec une mauvaise implémentation de la lib standard. Si le bug est avéré et non une incompréhension de principe basiques (au sens C++-STLien) du C++ (valeur vs entité, et autre dangling pointeurs qui découlent des copies qui n'auraient jamais dû avoir lieu), alors il suffit d'acheter une autre SL si STLport n'est pas une option, se procurer le patch du compilo, voir la corriger (après tout les sources sont accessibles -- et pas si compliqués si on sait vraiment implémenter une alternative), etc.
</HS>
luc hermite j'ai pensé à un moment corrigé l'implantation, mais bon... vu que j'avais un système déjà fait, plus léger, qui lui fonctionnait très bien, que je m'était cassé les pieds à faire quelques années auparavant... pourquoi s'acharner, surtout que j'avais juste à changer le namespace et parfois quelques noms de fonctions.
et comme je disais c'était sous linux
les autres bugs qui eux étaient aléatoire selon l'os venait du code de personnes qui effectivement aurait mieux fait de s'abstenir d'utiliser la STL, et en fait aurait mieux fait se s'abstenir de programmer tout cours...
pour ce qui est de .NET, dès que tu ne cherche pa à faire usage de WCF et WPF tous deux sous brevets logiciels, tu peux faire tourner une appli .NET sous linux, avec mono.
(bien qu'une partie de la WCF Silverlight soit implanté dans Moonlight)
de toute façon, la plupart de ceux que j'ai vu soit disant rompu à C++ savait à peine ce qu'est un pointeur ou une référence et la différence (aussi ténue soit elle) entre les deux... alors le reste de la question ne se pose plus...
en tout cas ya des BTS et des DUT que je peux clairement fusiller sur la place publique pour avoir eu des développeurs qui en sortait et qui savaient à peine programmer en C alors la POO juste la théorie et encore... meme java ca leur passait au dessus de la tete.
De toute façon temps que tu trouvera des profs qui enseigne Java au lieu de C++ et qui trouve le moyen de pas expliquer que le petit mot protected en Java n'a pas du tout la même signification que dans les autres langages hérités de C++ pour la syntaxe et le lexique... mais qu'il correspond à l'internal de C#... ca ira mal...
quelle ne fut pas ma surprise en voyant un développeur sorti fraichement de son BTS s'exclafer quand l'autocompletion lui retournait un membre qui aurait due rester privé (mais visible par les héritières)...
et de le voir se grater la tete et ne plus comprendre... normal, cela dit.
ca en serait risible si ce n'était pas si ... habituel... de nos jours.
je parle meme pas des développeurs qui n'apprennent pas à aérer et à commenter et encore moins à indenter leur code pour garder quelque chose de propre et lisible...
sans parler de ceux qui meme après 10 savons bien comme il faut et avoir due recommencer autant de fois, ne comprennent toujours pas que quand on leur impose des règles de codage sur un projet (genre les noms et les commentaires en anglais) c'est pas fait pour les chiens et qu'ils n'ont ni à les remettre en question ni même à demander pourquoi...
(en plus quand on demande ce genre de règles... généralement c'est que le projet est destiné à etre lu par autre chose que des francais...)
Franchement pour avoir suivi un cursus informatique en IUT, on ne peut pas mettre en cause la qualité de la formation. Cette dernière donne de bonnes bases si on prend la peine de suivre correctement les cours et de faire sérieusement les projets et autres TDs.luc hermite j'ai pensé à un moment corrigé l'implantation, mais bon... vu que j'avais un système déjà fait, plus léger, qui lui fonctionnait très bien, que je m'était cassé les pieds à faire quelques années auparavant... pourquoi s'acharner, surtout que j'avais juste à changer le namespace et parfois quelques noms de fonctions.
et comme je disais c'était sous linux
les autres bugs qui eux étaient aléatoire selon l'os venait du code de personnes qui effectivement aurait mieux fait de s'abstenir d'utiliser la STL, et en fait aurait mieux fait se s'abstenir de programmer tout cours...
pour ce qui est de .NET, dès que tu ne cherche pa à faire usage de WCF et WPF tous deux sous brevets logiciels, tu peux faire tourner une appli .NET sous linux, avec mono.
(bien qu'une partie de la WCF Silverlight soit implanté dans Moonlight)
de toute façon, la plupart de ceux que j'ai vu soit disant rompu à C++ savait à peine ce qu'est un pointeur ou une référence et la différence (aussi ténue soit elle) entre les deux... alors le reste de la question ne se pose plus...
en tout cas ya des BTS et des DUT que je peux clairement fusiller sur la place publique pour avoir eu des développeurs qui en sortait et qui savaient à peine programmer en C alors la POO juste la théorie et encore... meme java ca leur passait au dessus de la tete.
De toute façon temps que tu trouvera des profs qui enseigne Java au lieu de C++ et qui trouve le moyen de pas expliquer que le petit mot protected en Java n'a pas du tout la même signification que dans les autres langages hérités de C++ pour la syntaxe et le lexique... mais qu'il correspond à l'internal de C#... ca ira mal...
quelle ne fut pas ma surprise en voyant un développeur sorti fraichement de son BTS s'exclafer quand l'autocompletion lui retournait un membre qui aurait due rester privé (mais visible par les héritières)...
et de le voir se grater la tete et ne plus comprendre... normal, cela dit.
ca en serait risible si ce n'était pas si ... habituel... de nos jours.
je parle meme pas des développeurs qui n'apprennent pas à aérer et à commenter et encore moins à indenter leur code pour garder quelque chose de propre et lisible...
sans parler de ceux qui meme après 10 savons bien comme il faut et avoir due recommencer autant de fois, ne comprennent toujours pas que quand on leur impose des règles de codage sur un projet (genre les noms et les commentaires en anglais) c'est pas fait pour les chiens et qu'ils n'ont ni à les remettre en question ni même à demander pourquoi...
(en plus quand on demande ce genre de règles... généralement c'est que le projet est destiné à etre lu par autre chose que des francais...)
Non, le problème vient qu'il est tout à fait possible pour quelqu'un qui ne programmera jamais durant sa formation d'obtenir son diplôme. Cela grâce aux projets durant lesquels sa seule contribution se limitera à rajouter son nom dans le rapport de projet et en assurant un minimum aux matières non-informatiques.
Je suis bien mal placé pour donner mon avis sur la formation des informaticiens dans l'enseignement français, n'ayant fais rien d'autre que 6 ans de philosophie et un certificat webmaster en un an au CNAM.
Je vais donc donner mon opinion sur ce sujet à partir de mon "analyse" des personnes "sorties" des écoles, universités etc. Bref, à partir des informaticiens.
Il me semble que les informaticiens, les informaticiens de tous pays, ont de sérieuses lacunes en histoire de l'informatique. Combien d'approximations (internet une invention de militaires), d'erreurs (le mac est le premier OS disposant d'une GUI), d'absence totale de connaissance de langages importants, ou de concepts fondamentaux (LISP, Smalltalk, programmation fonctionnelle, méta-programmation, réflexivité, intercession, s-expression, homoiconicité etc.).
Par exemple l'absence de connaissance de la notion d'homoiconicité (la syntaxe est une structure de donnée du langage ; dit autrement : langage et structure de donnée sont identiques.) fait manquer complètement tout l'intérêt des parenthèses en LISP (à moins de les saisir "intuitivement" et sans a-priori).
Ainsi en lisp le langage n'est rien d'autre qu'une liste :
(pomme poire animaux) -> simple liste
(setq or 20) -> simple liste... et affectation de 20 à or.
Ce qui offre des possibilités assez étonnantes. Ainsi Paul Graham nous montre-t-il dans son très bel article "The Roots of LISP" comment la syntaxe de LISP permet d'écrire à partir des primitives quote, atom, eq, car, cdr, cons et cond une fonction "eval" de 33 lignes bien aérées qui ne fait rien d'autre qu'implémenter le langage... Impossible sans cette syntaxe si particulière.
Je ne crois pas que l'homoiconicité ou l'intercession ne sont que des objets d'étude de chercheurs en informatiques. La multiplication des cœurs dans les processeurs, la complexification des applications qui en résulte, impose aujourd'hui l'apprentissage des problématiques de la programmation concurrente. Ça n'est pas un hasard si le nouveau langage de Microsoft (F#) est "fonctionnel" ; ça n'est pas un hasard si le langage pour la JVM le plus efficace pour gérer la concurrence est Clojure, un ... LISP.
Pensez également au ramasse-miette. Aujourd'hui, depuis Java, c'est une évidence. Ce ne fut pas toujours le cas. Le premier ramasse-miette, si je ne fais pas erreur, c'est celui du LISP au début des années soixante. Java c'est 1994. 30 ans avant qu'une techno considérée comme un truc de chercheurs devienne une nécessité.
30 ans, c'est court.
La réalité ? Nos chers programmeurs vont devoir sérieusement se pencher sur la progra fonctionnelle, sur le problème lié aux procs multi-cœurs, à l'intercession etc. dans les années qui viennent. Et sans une toute petite connaissance de ce qui se fait en programmation en-dehors de Java, C++, et C# (dans un cadre "classique"), la douche risque d'être froide
Le problème ne se situe donc pas dans l'opposition des chercheurs et des industriels. Un bon enseignement de l'informatique c'est un enseignement qui ouvre sur des problèmes théoriques, sur des questions historiques, tout en prenant continuellement en compte les nécessités pratiques, "concrètes".
L'informatique est une technique. C'est un outil. Mais c'est un outil extraordinairement "abstrait". C'est un outil fondamentalement paradoxal.
L'informatique c'est un marteau qui se manipulerait comme une fonction mathématique.
Ce fait impose un enseignement double : un enseignement à la fois technique et théorique. En informatique, les deux vont fondamentalement ensemble. À la fois dans le monde de la recherche (une informatique coupée de son application concrète ne vaut rien), et dans le monde de l'entreprise (une informatique qui se sclérose dans la pure technicité se rend incapable de répondre à la complexification croissante des problèmes qui se pose à elle).
Ce fait impose un enseignement fondé sur trois composantes devant continuellement dialoguer entre elles : une histoire approfondie et réfléchie de l'informatique ; une étude sérieuse des théories ; et une constante application pratique.
je ne sais pas s'il est important pour un développeur, actuellement, de savoir que les fondements d'internet sont le fruit de recherches de l'ADARPA...
même si c'est toujours intéressant de le savoir, je ne suis pas fondamentalement convaincu que ce soit "primordial"...
maintenant effectivement la recherche n'est pas là pour rester dans son coin gentillement, et il est important que l'enseignement soit en adéquation avec le monde des entreprises d'un coté, mais ne zappe pas complètement ces notions que l'on voit surtout en recherche.
effectivement les langages fonctionnels sont loins d'etre totalement inutile au grand désespoire de beaucoup.
même s'il est impensable d'écrire un GUI en prog fonctionnelle, gérer un problème typiquement mathématique comme une implantation aisée d'un algorithme de parcours de graph sera forcément plus efficace en prog fonctionnelle...
pour ce qui est de la progra fonctionnelle, je ne sais pas si elle est au programme de BTS ou DUT
mais pour ceux qui se sont sentis blessés par mes propos face à DUT et BTS, il faut vous dire qu'il n'y a pas de normalisation des programmes à l'échelle nationale, et que chaque établissement dispose de son autorisation et donc de sa filière, de son programme... qui peut etre radicalement différent.
c'est pourquoi je peux dire que tous les développeurs que j'ai vu sortir d'un IUT en particulier connaissent à peine le C et vaguement la POO, ils connaissent MERISE (et encore même là, pas de façon approfondie) et UML est pour eux encore quelque chose de relativement abstrait et ils n'ont que de vagues connaissance de java...
bref rien de précis, que du vague, que du moyen, pas d'approfondie, meme dans un domaine, ce qui fait qu'au final à chaque fois j'ai due compléter moi meme leur formation en plus des besoins, mais comme on me demandais pas mon avis sur les personnes recrutées...
de meme j'en ai vu sortir de ce meme DUT ou BTS local qui étaient bons, mais la raison étaient simple, ils n'ont pas eux attendus d'entrer en BTS ou DUT pour apprendre à programmer, ces cursus ont complété leurs connaissances "théoriques"... le problème est donc toujours le meme...
et il vient du décalage entre les besoins des sociétés qui ont besoin de développeurs fonctionnels dès qu'ils sortent de l'école, et le cursus soit trop pratique, soit trop théoriques...
non, le premier GUI que j'ais utilisé était sur ATARI en 1986 je pense qu'il devait aussi tourner sur Amstrad et Commodore(pas sur). M'enfin ca date j'aivais 22 ans a l'époque. D'ailleurs je crois avoir dans une boite cher ma mére, la disquette car a l'époque il fallait se debrouiller avec une mémoire vive de 512 Kilo octet et des diskette 1,2 mega aux max.
M'enfin pour les nouveaux informaticienx, c'est clair que beaucoup son dépassé et en fait ne comprennent rien, mais ca a été tellement vite. De toute façon si tu connais pas le shell Unix dans le détail, c'est difficille de pouvoir comprendre se qu'il se passe vraiment aux coeur de l'ordinateur. Quand a la programmation C++ j'ais eu l'occasion de récuperer une appli develloper par d'autre, si tu n'as pas les base t'es perdu vite fait, par contre si tu sait bien debuger, c'est faisable, ca prends juste un peux de temps. M'enfin lorsque que tu as programmer en assmbleur tu as appris a suivrent du code
A mon avis il faut au moins 15 ans d'experience en devellopement et surtout en degugage pour pouvoir s'y retrouver facilement avec n'importe qu'elle langage, m'enfin il faut aimer ca, sinon ca prends vite la tête.
Perso si vous avez un jour l'occasion de tomber sur les source de mon Soft, je vous promet un sacré mal de crane, 20 ans d'expérience pour faire en sorte que personne a par moi même puisse être capable de suivre. C'est malheureusement mais c'est grace a cela que l'on survie dans le monde informatique.
Je ne sais pas si vous avez debuger les sources de SPRING mais il ont fait fort eux aussi en protection et en halenbication.
Et oui a une époque ont avait pas d'autre choix de faire lisible organiser et éfficace par manque de place mémoire. Aujourd'hui ont peut multiplier par 10 le code cela ne se ressent même pas a l'excecussion.
Se n'est pas prés de s'arranger, tout le monde veux rester en place quitte a faire de l'in-maintenable. Ou uniquement maintenable par lui même.
Bon courage aux jeunes informaticiens qui font tout leur possible pour ne pas parraitre trop nul. C'est pas leur fautes surtout que dans beaucoup de cas leur supérieur sont encore plus mauvais. C'est 25 années d'expérience. M'enfin se que je préfere le plus sont les fonctionnels, c'est a se tordre de rire lorsqu'il se la remmene informaticien.
J'ai fait un DUT informatique et suis actuellement en première année d'école d'ingénieur et je vois cette année que d'autres qui ont aussi fait un DUT informatique mais pas dans la même université que moi ont fait des choses très différentes : Alors que là où j'étais il était enseigné quasiment que le C++ (avec une approche par le C au début puis en y rajoutant les classes et la POO), d'autres ont fait du C, du C++ et du Java (et certains pensent effectivement tout savoir sur tous ces langages mais passons).
Je trouve qu'en deux ans il est difficile d'apprendre un langage de manière correcte, surtout que bien souvent on n'est pas vraiment confronté à des problèmes que l'on sera ammené à rencontrer en entreprise. Bon d'accord il y a les projets (et heureusement) mais j'ai toujours l'impression de ne pas savoir coder en C++, même après en avoir fait pendant 2 ans à l'iut, plus en en ayant fait par moi même. Il doit donc être encore plus difficile de maitriser l'ensemble des langages que l'on aurait vu en 2 ans de DUT, qui plus est si l'on en a abordé plusieurs. Enfin, comme il a déjà été dit, les programmes sont différents de partout, il est donc difficile de juger de la qualité générale de l'enseignement en DUT.
Personnellement j'essaye d'être assez actif dans mon apprentissage du C++, allant chercher dans des livres et sur internet des notions dont je ressent l'utilité mais qui ne m'ont soit pas été enseignées, soit qu'elles n'étaient pas assez approfondies. Pour l'instant je ne me sens pas du tout prêt à développer en entreprise et même s'il me reste encore deux ans et demi, ça va surement passer vite et même à la fin de mes études, je ne serais surement pas un expert en C++, l'expérience du terrain et du dévelloppement en entreprise me manquant toujours (m'enfin bon, on ne peut pas non plus rester indéfiniment à l'école, même s'il y a toujours des tonnes de trucs à apprendre).
Bref, je me trompe peut-être mais j'ai l'impression que rien ne peux remplacer l'expérience en entreprise (à moins peut-être de participer à des projets d'envergure, pas seulement de faire des projets de développement en groupes de 4). De plus que faut-il marquer sur le CV ? Alors que les profs de com nous encouragent à mettre l'ensemble des choses que nous avons abordées j'ai l'impression que si j'étais ammené à travailler sur certaines des choses que j'ai faites à l'iut, je devrais dabord commencer par me former correctement sur le sujet (ça rejoint ce que disait cinemania en voyant arriver les étudiants fraichement sortis des universités). Je manque cependant de recul sur la question, ayant encore la tête plongée dans ces études...
Pas seulement l'université qui a son chemin à faire
Il n'y a pas que l'université qui a un bout de chemin à faire pour effectuer un rapprochement entre la théorie enseignée à l'université et les besoins appliqués en entreprise. Pour répondre à cette exigence, il faudrait que les entreprises elles même reviennent sur terre. Pour l'heure, il n'y a plus de plafond!
L'entreprise tente constamment d'utiliser l'informatique à contre nature pour se mettre à l'avant garde, ou pour suivre ceux qui le sont devenus à ce prix; on aime utiliser des marteau modifiés pour visser des planchers, faute d'avoir le temps d'inventer le tournevis. Les languages et standards ne sont pas encore au point qu'on a déjà poussé leur utilisation largement au-delà de ce qui était prévu initialement. Auparavant, un programmeur génial était quelqu'un qui trouvait des solutions nouvelles à des limitations nouvelles. Je prend comme exemple l'invention de UNIX suite au plafonnement de Multics. Maintenant, on louange le programmeur qui excelle dans les trucs et astuces pour accomplir l'impossible. Les webmasters sont passés maître dans l'art. Lorsque ces tours deviennent la norme, alors on ajuste la technologie en conséquence: le truc devient la norme. Le HTML est rendu un language à astuces, qui peux demander beaucoup d'essais-erreurs avant de produire le résultat voulu. Ses fonctions les plus utiles sont souvent longues à découvrir, car on est trop habitué de tricher avec lui pour imaginer qu'il y a un remède.
Jamais le HTML n'avait été prévu pour devenir une interface légère pour applications tiers complexes. Peut-être aurait-il fallu prévoir un standard distinct qui aurait permis de libérer le HTML de ce fardeau. À la place, on a préféré satisfaire l'impatience de l'entreprise en inventant le AJAX, une extension de plus qui rendra obsolète toutes les applications web (ça coûtera combien au fait?) L'outil des années 2010 et celui qui fait tout. À quand le SQhtmLScript?
Qui est responsable d'une évolution aussi chaotique? Qui d'autres que tous ces gestionnaires d'entreprises qui ont une compréhension de maigre à nul de l'informatique, mais qui en sont malgré tout devenu les orienteurs? Combien de fois m'a-t-on servi une longue liste d'épicerie de requêtes discutables sans en discuter avec moi ou d'autres experts de notre équipe? La faisabilité désirée se résume à savoir combien ça coûte et combien de temps supplémentaire sera requis pour livrer en septembre prochain. Il faut dire que les évaluations effectuées par les médias ne font rien pour améliorer la situation en privilégiant la quantité plutôt que la qualité.
Une fois, j'ai refroidi un client en lui expliquant comment sa requête était impossible avec la technologie utilisée. Sa voie est devenue toute faible de déception: il s'était mis dans la tête une idée. De devoir en trouver une autre ou y renoncer lui semblait haut comme une montagne. Je me sentais quasi coupable. Évidement, j'ai du lui expliquer le pourquoi et le comment de l'infaisabilité, ce qui n'est pas toujours évident avec un novice. Mais si je ne l'aurait pas fait, il ne m'aurait tout simplement pas cru. C'était lui, l'orienteur IT. Pour qui «non» n'est pas une réponse valable.
Où je travaille, c'est plutôt rare que les décideurs viennent s'assoir à notre table pour discuter des choix qu'ils s'apprêtent à faire. Ils feront leurs choix en dépit de nous, et nous devrons trouver le moyen de les mettre en oeuvre dans des délais raisonnables. Bien peu sont intéressés de savoir qu'en développant à la hâte, l'étude de faisabilité, les commentaires dans le code, la documentation et les tests sont négligés. Ils ne le réalisent que lorque nous éprouvons des problèmes sérieux (coûteux) en production. Ironiquement, ils sont aussi léger avec les solutions apportées par la suite. Résultat: maintenant on documente et on teste, mais la documentation est complètement inutilisable et les tests plutôt superficiels et très lourds à maintenir. Des patates chaudes. Mon travail consiste donc un peu à justifier les coûts entrepris en donnant l'impression que les tests sont suffisants.
Ceci démontre bien que quand les gestionnaires ne comprennent pas l'informatique moderne; ils se contentent de gérer les apparences. Malheureusement pour eux, avec la complexité de l'informatique, avec la quantité croissante de languages, de protocoles et de normes disponibles, ça ne va pas aller en s'améliorant.
Voici l'autre problème de l'entreprise: la complexité des nouveaux standards comme le J2EE. En soit, le Java est peut-être plus simple à maîtriser que le C++. Mais je ne suis pas convaincu que ça soit encore vrai rendu au niveau de l'application d'entreprise.
Le J2EE spécifie des structurations d'équipes pour bien séparer les tâches entre chaque travailleur, et des blueprint pour bien structurer le code. Un programmeur Java n'a plus besoin de connaître la machine sur laquelle il travaille. Sauf que jai toujours perçu le programmeur comme une personne qui a pour mandat d'exploiter le potentiel de la machine pour traiter des informations. Avec le Java, le programmeur moderne peut être moins compétent, et c'est exactement la raison pour laquelle le Java est apparu: les besoins ont explosés par rapport aux nombre d'informaticiens compétents disponibles - habituellement des pros du C++ ;-)
Les programmeurs sont de plus en plus des 9 à 5 qui n'apprennent que le strict minimum et ne veulent pas aller plus loin. Ceux-ci sont très dépendants des plus compétents, qui héritent du lourd mandat d'avoir à apprendre le J2EE.
Un autre volet du problème, c'est la mode du logiciel à la carte (je l'ai abordé plus haut avec l'histoire de la liste d'épicerie). C'est simple d'exiger des nouvelles fonctionnalités, mais concrètement, quand il y en a trop, l'application devient tout simplement impossible à tester dans son ensemble. Conséquence: une grande parti des bogues seront trouvés en production et fixés d'urgence.
Tout ceci est simple à comprendre pour un programmeur, mais beaucoup moins pour le gestionnaire qui connait surtout son budget et les délais exigé pour impressionner son client. En fait, il s'en doute, mais ça ne lui sert à rien de l'entendre: il préférera marcher sur la corde raide et rester concurrenciel avec les autres en espérant que ça ne lui sautera pas au visage.
Pourquoi donc tout mettre sur le dos des universités? Elles n'ont pas à accomplir l'impossible, elles ont simplement à enseigner des bases de programmation et de design de logiciel convenables, fournir des expérience de travail en équipe de développeurs (ce qui doit inclure des activités para-scolaire, dans le développement du libre par exemple) et à développer en collaboration avec l'entreprise des idées nouvelles pour faire face aux problèmes modernes de l'informatique, qui sont principalement: des ordinateurs personnels difficiles à maintenir pour des gens ordinaires, des applications web limitées par le média utilisé et la sécurité défaillante entre les deux.
Je ne pense pas que nombreux soient ceux qui mettent "tout" sur le dos de l'enseignement supérieur >< !
Les principales reproches qui sont fait de la par de BS, c'est que d'une part l'enseignement est trop théorique, et d'autre par on les formes de manière rétrogradement théorique >< !
Le reproche que je fais, c'est que l'enseignement supérieur français, bien que conscient de se mal être, à du mal à se positionner. La problématique n'est évidemment pas simple, car il ne forme non pas pour le "présent" mais pour l'avenir. Seulement, il n'est pas facile ne savoir ce qui sera fait prochainement.
Le fait est que je considère que c'est à ce dit enseignement de forger "l'esprit futur", par l'analyse fort complexe des besoins et des évolutions possibles. Mais ça fait peur, du coup, personne se mouille, sa hésite, et sa flanche... En donnant souvent de "mauvais résultat", ou en ayant un intérêt que peu certain (exemple : compter sur le potentiel autodidactique de ses élèves).
@Camille_B
Dans un milieu professionnel, la culture informatique, c'est surtout une question d'esprit et d'intégration. Néanmoins, tu exposes là un travail qui doit se faire dans les bureaux des universités et des entreprises.
Tu parles de la programmation concurrente, et tu as bien raison. Après tout, même les machines utilisateurs commence à avoir 4 coeurs possiblement hyper-threadés, la nouvelle norme c++ intègre de la programmation concurrentiel, et de plus en plus de plateforme se mette à la programmation fonctionnel.
Malheureusement, se besoin commence tout juste à s'exprimer. Du coup, elle est à peine abordé...
Il en est de même pour la méta-prog... Les bibliothèque les plus raffiné l'utilise pleinement, mais elle n'est pas très enseigné ><! (Remarque bien que les deux peuvent être abordé autour de la programmation fonctionnelle...)
A qui la fautes ? Aux entreprises qui ne s'appersoient de rien, ou aux université qui n'essayent pas de leur montrer ? Chacun à sa part de responsabilité, toutefois je ne pense que se soit mal de demander d'abord à l'université d'être le "héros" de l'histoire.
@Camille_B : on a besoin de plus de philisophes manifestement
@Lavock : certes, C++ introduit des éléments de concurrences, mais uniquement un modèle lock-based à priori, qui a prouvé qu'il est très difficile à maitriser par les développeurs (et non composables entre autre). Il existe d'autres modèles de concurrence (agent-based, STM entre autre) qui ne sont le standard d'aucun langage mainstream.
Concernant la méta-prog C++, le sous-ensemble MP est clairement un langage turing-complet fonctionnel non-typé, avoir des bases en programmation fonctionnelle aiderait beaucoup. La notion de fonction pure (rediscutée entre autre dans le thread sur D) est aussi une notion importante pour les problèmes de concurrence.
De manière plus général, je pense qu'il manque une base mathématique / théorique assez importante à la formation de base, même la POO n'est enseigné que très partiellement : typiquement, parler du principe de Liskov (1987 quand même, 23 ans déjà), et c'est le grand désarroi en face.
Merci Zul
Le langage Clojure, qui n'est pas un langage mainstream mais tourne sur une VM mainstream (Java. Ce qui est déjà pas mal) gère plusieurs mécanismes :
software transactional memory system (STM)
agents system
atoms system
vars system
En plus des techniques propres au langage Java.
Plus d'infos ici : http://clojure.org/concurrent_programming
J'arrête le hors-sujet ici
C'était surtout pour appuyer le faite que celle-ci "débarquer".
Je sais pas trop. Personne ne sait ce que sait, mais tous le monde l'applique (ou presque). C'est un peu pareil avec les autres fondements. Y-a-t'il un intérêt autre que social à savoir leur nom ?
@Camille_B : Oui on a besoin de plus de philosophe, surtout dans les sphères "décisionnelle"...
Une partie en moi me dit que tu as raison. Une autre partie me dit que le meilleur mécanicien quand il monte et démone un moteur ne connait peut être pas grand chose à la thermodynamique. Et ça ne l'empêche pas de faire du bon boulot. Quelque part c'est la richesse de l'informatique : un marteau pour ceux qui aiment construire; qui se manipule comme une fonction mathématique pour ceux qui aiment jouer avec la théorie (merci camille).
C'est volontaire il me semble. Le bagage "théorique" n'est-il pas ce qui est censé distinguer les formations "de base" des études > 3 ans ?
Dans les grandes lignes, ce que j'ai retenu des discussions c'est :
- le problème des universités, c'est leur incapacité / réticence à se mettre au goût du jour
- le problème des entreprises, c'est leur incapacité / réticence à se mettre au goût du jour
Je me demande alors : qui s'occupe de faire évoluer le goût du jour ?
L'offre matériel et la demande de "sortie" cliente. Ainsi que des personnes qui réfléchisse à ce genre de problème. Un peu comme en économie quoi.Je me demande alors : qui s'occupe de faire évoluer le goût du jour ?
Heuu... tu t'avances peut être un peu beaucoup...
Qu'il te suffise de remarquer le nombre de discussions sur le forum où un héritage a été utilisé alors qu'une agrégation aurait été bien plus intéressante
Qu'il te suffise de remarquer, toujours sur le forum, le nombre de discussions où l'on met en évidence l'inutilité d' accesseurs ou mutateurs et où l'on conseille de s'intéresser de préférences aux services (je parle, entre autres, de demeter)
Nous pourrions continuer la liste
Ne sous estimes pas l'intérêt social de la chose...C'est un peu pareil avec les autres fondements. Y-a-t'il un intérêt autre que social à savoir leur nom ?
N'oublie pas que toute discussion ne peut se faire que parce que l'on respecte certaines conventions pour présenter un concept donné.
Si tu venais à être le seul à utiliser une convention qui utiliserait le terme "couteau" au lieu du terme "cuiller", les gens auraient énormément de mal à te comprendre
Enfin, à par la fois où il s'agit de présenter le principe de liskov, la loi demeter ou les différentes formes canonique de coplien, il est beaucoup plus facile d'utiliser ce terme en partant du principe qu'il est connu que de commencer à parler "de ce principe qui dit que toute propriété valide pour une classe de base doit l'être pour les classes dérivées", ou "du principe qui veut que si une classe A utilise la classe B et que la classe B utilise la classe C, il n'y a aucun intérêt à ce que la classe A connaisse la classe C"...
Et bien sur, ce ne sont ici que des exemples choisis
D'autant plus que, si tu as la sensation que le principe énoncé n'est pas connu de ton interlocuteur, tu risques de devoir l'expliquer, et parfois le justifier...
D'où la remarque de Dijkstra : l'université n'est pas la pour fournir aux entreprise ce qu'elles veulent mais ce dont elles ont besoin. (traduction par mes soins).
C'est vrai... Mais la bonne question, c'est : le fait elle?
Quand on voit :
- l'ignorance que la quasi totalité des enseignants ont du monde de l'entreprise
- ce qu'arrivent à produire certaines facs d'informatique après 5 à 7 ans d'étude (ne serait ce qu'en terme de "culture générale informatique")
Il est parfois difficile de répondre par l'affirmative...
Francois
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