Discussion :

[Mac LAK]

Désolé Mac LAK d'éditer ton message.

Je viens de séparer la conversation faite dans le thread du 4eme défi pour mettre dans cette discussion tout ce qui ne concerne pas le défi.

Hihi^^
Bon je suis pas là pour faire l'apologie de la STL à quelqu'un qui sait certainement trés bien s'en passer. Sache seulement que j'ai commencé le C a 14 ans, et le C++ a 20, et que je suis pas du genre a codé qu'une fois de temps en temps.
Je suis d'accord qu'il FAUT savoir faire autrement et que la STL a ses limites. D'ailleur je serais tout a fait capable de (re)faire sans. Mais dans mon cas personel la STL/boost répondent a 99.9% a mais problème de structure de données, donc j'en use et j'en abuse avec joie. Et c'est surement de m'être galeré aussi longtemps en C qui me fait apprécier autant la STL. (Je précise que j'ai rien contre le C)

Sûr que pour des "petites" structures, sans contraintes particulières de performances lourdes, ou de consommation mémoire, la STL ou Boost répondent aux besoins. C'est souvent le cas dans pas mal de projets graphiques par exemple, où l'affichage est le plus gros consommateur de temps CPU, ou des programmes de communication pour lesquels le temps de propagation des trames est souvent bien supérieur au temps de traitement.

Mais là où je suis plus gêné, justement, c'est de "faire apprendre" à des débutants exclusivement via la STL / Boost sans leur en montrer les limites... Là, je parle par expérience, j'ai vu trop de débutants utiliser des trucs dix fois trop lourds dans des parties de code critique, ou pire, ne pas savoir utiliser des éléments "basiques" comme un simple "TYPE*" en guise de tableau, ne pas savoir faire un sizeof correct, etc.

Pour moi, un exemple de "mauvaise réponse" à un problème, c'est de dire d'utiliser telle fonction de telle librairie quand, manifestement, le posteur cherchait à comprendre comment le faire... Il est humain, et ira sûrement vers la facilité d'utiliser un truc tout prêt, mais du coup aura perdu le fait d'apprendre à le faire par lui-même.

Faut pas réinventer la roue à chaque programme, bien sûr, mais il faut savoir le faire au besoin.

[maxim_um]

Salut tout le monde,

Sûr que pour des "petites" structures, sans contraintes particulières de performances lourdes, ou de consommation mémoire, la STL ou Boost répondent aux besoins...

Tu t'avances dans un terrain miné, là!!!

La SL est une pierre angulaire du langage, Boost se confirme et le devient. Et c'est justement dans les aspects critiques qu'ils montrent toutes leurs puissances. Ils ne peuvent être reniés de la sorte. C'est comme tout, si tu donnes une Ferrari à quelqu'un qui ne sait pas conduire, s'il se plante, c’est pas la faute à la voiture. Et pourtant, tu conviendras qu'il avait un sacré bolide entre les mains. Eh ben, pour la SL et Boost, c'est pareil.

[Mac LAK]

Tu t'avances dans un terrain miné, là!!!

La SL est une pierre angulaire du langage, Boost se confirme et le devient. Et c'est justement dans les aspects critiques qu'ils montrent toutes leurs puissances. Ils ne peuvent être reniés de la sorte. C'est comme tout, si tu donnes une Ferrari à quelqu'un qui ne sait pas conduire, s'il se plante, c’est pas la faute à la voiture. Et pourtant, tu conviendras qu'il avait un sacré bolide entre les mains. Eh ben, pour la SL et Boost, c'est pareil.

Pas vraiment, hélas, et par expérience... Je dirais même que filer la STL comme "référence" à un débutant lui interdit souvent de comprendre comment elle fonctionne réellement en interne, ou ce que cela retire comme charge de développement. Comme je l'ai précisé un peu plus haut, je trouve "dangereux" (et j'en ai des preuves constamment hélas) de laisser des débutants croire que la STL est la panacée intégrale sans leur apprendre à le faire "à la main"... Déjà, parce que quand tu es tenu de compiler en C pour des raisons de contraintes de plate-forme (et non pas en C++), ça pleure. Ensuite, parce que même en C++, la STL n'est pas toujours une bonne idée.

La STL (et les templates de façon générale d'ailleurs) sont infects à débugger, ont une fâcheuse tendance à augmenter significativement la taille du code binaire produit (souvent gênant en embarqué), et cèdent systématiquement devant le code "manuel" lorsque l'on gère d'énormes quantités de données fréquemment modifiées (ex : buffers de communication), ou que l'on a besoin de vitesses d'exécutions particulièrement contraintes (gestionnaires temps réel par exemple)...

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.
Et si c'est pour finir par transformer des std::map en collections de std::vector de tailles statiques, autant utiliser un bon mieux "new", tu ne crois pas ?

Après, sur des données de type configuration, peu lues / modifiées et en dehors du chemin critique d'exécution, ou mieux, exécutées en dehors de la partie embarquée, ces librairies ne posent aucun problème, bien au contraire. Il est quand même rare que ce qui "arrange" le développeur "arrange" aussi le temps CPU consommé et/ou le footprint... La STL / Boost pour ce qui est à l'échelle de temps de l'utilisateur, OK. Pour ce qui est à l'échelle de temps de la machine, ça dépend.

Certes, je parle là de conditions "aux limites", en dehors du cadre d'utilisation de beaucoup de développeurs, et que beaucoup ne verront JAMAIS. Mais il faut être conscient que ces limites existent et que STL / Boost ne sont pas forcément le meilleur choix possible.
Pour ma part, quand j'ai un problème de performances dans un code utilisant la STL, ça se résout 80% du temps en éjectant ladite STL du chemin critique... Amusant, non ?

[Luc Hermitte]

<totalement HS>

a- Pas vraiment, hélas, et par expérience... Je dirais même que filer la STL comme "référence" à un débutant lui interdit souvent de comprendre comment elle fonctionne réellement en interne, ou ce que cela retire comme charge de développement. Comme je l'ai précisé un peu plus haut, je trouve "dangereux" (et j'en ai des preuves constamment hélas) de laisser des débutants croire que la STL est la panacée intégrale sans leur apprendre à le faire "à la main"...
b- Déjà, parce que quand tu es tenu de compiler en C pour des raisons de contraintes de plate-forme (et non pas en C++), ça pleure. Ensuite, parce que même en C++, la STL n'est pas toujours une bonne idée.

c- La STL (et les templates de façon générale d'ailleurs) sont infects à débugger,
d- ont une fâcheuse tendance à augmenter significativement la taille du code binaire produit (souvent gênant en embarqué), et cèdent systématiquement devant le code "manuel" lorsque l'on gère d'énormes quantités de données fréquemment modifiées (ex : buffers de communication), ou que l'on a besoin de vitesses d'exécutions particulièrement contraintes (gestionnaires temps réel par exemple)...

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.

e- Et si c'est pour finir par transformer des std::map en collections de std::vector de tailles statiques, autant utiliser un bon mieux "new", tu ne crois pas ?

a- Le débutant, quand il débute avec l'Ada, on ne lui demande pas de comprendre comment le compilo met en oeuvre les in/out, ou comment il gère les tableaux contraints. Par contre, il arrive un moment où il cesse d'être débutant et passe à d'autres langages où il est important de comprendre ces mécanismes. Pourquoi il devrait en être autrement en C++?
Je préfère passer derrière un code robuste et maintenable pour l'optimiser (quand et où cela s'avère nécessaire), que de passer derrière un code instable qui tient tout juste les perfs.

b- c'est pour cela que je ne me considère pas comme un développeur C, même si je saurai m'en sortir.

c- A iso-fonctionnalité, je préfère débugguer des templates aux macros.

d- autant que si le service utilisé avait été implémenté à la main. C'est particulièrement vrai pour les vecteurs comparés aux tableaux. Pour les structures plus complexes, il y a toujours moyen d'encapsuler un std::leconteneurquivabien<void*> dans une structure qui recaste automatiquement (ce que fait le Java). J'estime que quand on sait faire ça en C, on devrait aussi savoir le faire en C++.

e- (s/new/new[]/)
Certainement pas. Si on n'a pas besoin de la réallocation ou du RAZ sur allocation, on peut toujours encapsuler new dans un scoped_array, mais le résultat restera chez moi une classe template, et surtout RAII. Un new[] seul, jamais!
Et à propos de reallocation, en temps réel, je préfère mon std::vector::resize à realloc. Non seulement je tiens les perfs, mais en plus le code est plus simple à maintenir qu'avec realloc -- combien savent s'en servir correctement ?

</>

[Mac LAK]

a- Le débutant, quand il débute avec l'Ada, on ne lui demande pas de comprendre comment le compilo met en oeuvre les in/out, ou comment il gère les tableaux contraints. Par contre, il arrive un moment où il cesse d'être débutant et passe à d'autres langages où il est important de comprendre ces mécanismes. Pourquoi il devrait en être autrement en C++?

Mauvaise comparaison. Je dirais plutôt qu'avant d'utiliser algorithm::sort() ou qsort() pour un tri, c'est utile de savoir l'implémenter soi-même. Voire de s'être cassé les dents avec un tri à bulles qui n'en finissait pas. Quelques bonnes bases d'algo ou de processus "élémentaires" n'ont jamais été nuisibles, bien au contraire.

La STL implémente des choses que j'appelle "élémentaires" en terme de stockage de données. J'ai vu un peu trop de débutants croire que mettre une std::string comme "index" d'une std::map était une bonne idée parce que c'était "pratique", que ça ressemblait à ce que l'on voit couramment en langages interprétés, et hélas sans vraiment voir ce que ça impliquait derrière en terme de performances...
Pour maintenir en mémoire une configuration utilisée 2 à 3 fois par seconde, c'est pas gênant. Ça l'est plus dans un chemin critique. Toujours se méfier de ce qui semble faciliter un peu trop le développement...

c- A iso-fonctionnalité, je préfère débugguer des templates aux macros.

Ni l'un, ni l'autre pour ma part. Pour ma part, les deux sont à réserver à des cas très précis où la nature de l'implémentation (template et/ou macro) ne risque pas d'impacter la maintenabilité.

d- autant que si le service utilisé avait été implémenté à la main. C'est particulièrement vrai pour les vecteurs comparés aux tableaux. Pour les structures plus complexes, il y a toujours moyen d'encapsuler un std::leconteneurquivabien<void*> dans une structure qui recaste automatiquement (ce que fait le Java). J'estime que quand on sait faire ça en C, on devrait aussi savoir le faire en C++.

Attends de tomber un jour sur un code où gagner des indirections de pointeurs aura une incidence notable...

Quant ta STL ne te sert plus qu'à utiliser des std::vector parce que c'est le seul truc à peu près sans aucun overhead, quelle en est l'utilité ? Surtout quand les tableaux sont alloués à l'initialisation du programme, de taille fixe, et qu'ils ne sont détruits qu'en fin de processus...

Et à propos de reallocation, en temps réel, je préfère mon std::vector::resize à realloc. Non seulement je tiens les perfs, mais en plus le code est plus simple à maintenir qu'avec realloc -- combien savent s'en servir correctement ?

Realloc ? Temps réel ? Gni ?
Nan, buffers dimensionnés au maximum systématiquement : perdre du temps à réallouer de la mémoire, c'est du suicide de temps CPU... J'avais bien précisé : "tailles statiques".


Chacun voit midi à sa porte, bien entendu, mais pour moi le C++ n'est qu'une façon pratique d'éviter de passer des pointeurs de structures à chaque fonction, et/ou de truffer le code de pointeurs fonctionnels.
Bref, assouplir la POO en C "pur" (qui est une vraie usine à gaz), mais j'utilise ce qui me sert dans le langage sans prendre ce qui me complexifie le boulot et/ou alourdit le résultat final (footprint, code source, temps CPU, ...). Il m'est même arrivé de péter du C++ pour le passer en "C-like" juste pour gagner du temps de compilation, les performances étant similaires entre les deux implémentations dans ce cas précis...

Je ne suis un "intégriste" ni du C, ni du C++, ni du 100% procédural, ni du 100% objet. J'utilise les uns ou les autres indifféremment en fonction de mes besoins, mon code a toujours été maintenable, documenté, et en général bien optimisé. Sûrement parce que je fais souvent soit du code très transversal (faire communiquer des modules n'ayant parfois rien en commun : ni le langage, ni la plate-forme), soit du code vertical (communication du haut niveau vers le bas niveau et réciproquement). Ce qui se résume souvent à faire communiquer des modules en C++ très haut niveau avec des trucs collés au hard, écrits en C "système".

Dans ce genre de situation, on s'adapte assez vite, et sur des compilateurs C/C++, rejeter l'autre langage m'a toujours semblé être une balle que l'on se tire soi-même dans le pied... Je préfère construire un module "hybride" moitié C, moitié C++ mais très efficace plutôt que faire le "puriste" et commencer à vouloir faire communiquer les deux par une socket sur la boucle locale (véridique, déjà vu une telle proposition, hélas...).

[maxim_um]

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.

.../...

La STL / Boost pour ce qui est à l'échelle de temps de l'utilisateur, OK. Pour ce qui est à l'échelle de temps de la machine, ça dépend.

Certes, je parle là de conditions "aux limites", en dehors du cadre d'utilisation de beaucoup de développeurs, et que beaucoup ne verront JAMAIS. Mais il faut être conscient que ces limites existent et que STL / Boost ne sont pas forcément le meilleur choix possible.
Pour ma part, quand j'ai un problème de performances dans un code utilisant la STL, ça se résout 80% du temps en éjectant ladite STL du chemin critique... Amusant, non ?

Propose un exemple concret, parce que là ton histoire tient du roman de fiction inachevé. Franchement, avec les compilateurs actuels, même l'assembleur n'est plus requis. Pour ce qui est du module embarqué qui gère des millions de données en quelques millisecondes, à l'«ESA» ils ne connaissent pas. Ne le prends pas mal, mais je me demande si tu n'as pas regardé «Matrix» avant de poster. Enfin, la seule chose qui pourrait entrer dans ce contexte c'est une «mainframe», mais dans tous les cas, ça n'a rien à voir avec ce que tu sembles décrire. Pour moi, la meilleure des optimisations se fait au niveau de l'algorithme, le reste, comme le «décalage de bits» par exemple, ce n'est que de la micro-optimisation. Là vraiment, sans un exemple concret, je ne vois pas où tu veux en venir.

[Mac LAK]

Propose un exemple concret

Je te parle de circuits presque complètement câblés, où des FPGA / ASIC effectuent la plus grosse partie du traitement séquentiel, et où un processeur "normal" embarqué doit effectuer la prise de décision impliquant telle ou telle option câblée, ce qu'il ne peut faire qu'en prenant tout ou partie des informations dans sa propre mémoire tout en les conservant plus ou moins longtemps à disposition pour du monitoring.

Comme par exemple l'acquisition / stockage simultanés de plusieurs liens gigabits Ethernet. Ou, dans la même veine, l'acquisition / stockage de dizaines (pour ne pas dire "centaines") de bus de terrain.

Voilà pourquoi je dis que la plupart des développeurs ne verront jamais ce cas.

Il existe cependant, et ça me gave toujours autant de voir un débutant ou stagiaire arriver, être infoutu de faire une allocation sans aller jardiner le thread d'à côté parce qu'il n'a pas son garbage collector et/ou "sa" librairie pour assistés habituelle.

Et tout ça parce qu'un prof déconnecté de la réalité lui a un jour dit qu'avec Java, on faisait tout et qu'il n'y avait plus besoin d'apprendre des bases d'informatique comme la gestion des pointeurs, les algos élémentaires et autres "fioritures" qui n'existent pas forcément sur toutes les plate-formes. Sans même parler du fait qu'un langage de très haut niveau n'est absolument pas adapté à tout et n'importe quoi, bien entendu.

[Jean-Marc.Bourguet]

Voilà pourquoi je dis que la plupart des développeurs ne verront jamais ce cas.

Il existe cependant, et ça me gave toujours autant de voir un débutant ou stagiaire arriver, être infoutu de faire une allocation sans aller jardiner le thread d'à côté parce qu'il n'a pas son garbage collector et/ou "sa" librairie pour assistés habituelle.

Les profs n'ont déjà pas le temps de voir tout ce que la plupart des développeurs rencontreront, et tu voudrais qu'ils abordent des situations que la plupart ne rencontreront pas? J'ai une bonne série de choses à voir avant.

Il y a une chose qui me gave plus que des débutants arrivant en croyant tout savoir et en se prétendant experts, ce sont ceux qui s'attendent à ce que les débutants sachent réellement tout et soient de vrais experts.

Entre l'attitude "il faut réutiliser LAPACK" pour faire une multiplication de deux matrices d'ordre 2 et "il faut tout redévelopper soi-même à commencer par la libc", il y a un juste milieu; et celui-ci va dépendre du contexte dans lequel on est.

(Ceci dit, suivant le cursus, je m'attends à ce qu'un programmeur ait des notions de gestion de mémoire plus poussée que "on laisse faire le GC" même si c'est une attitude raisonnable dans plus en plus de cas).

(En passant, la gestion des charsets, c'est certainement pas un sujet que j'aurais mis comme pierre angulaire d'un défi -- et je suis d'accord avec ceux qui pensent que c'était le seul point où une recherche était nécessaire --, plus je regarde, plus je trouve que la situation normalisée est confuse.)

[koala01]

Les profs n'ont déjà pas le temps de voir tout ce que la plupart des développeurs rencontreront, et tu voudrais qu'ils abordent des situations que la plupart ne rencontreront pas? J'ai une bonne série de choses à voir avant.

Il y a une chose qui me gave plus que des débutants arrivant en croyant tout savoir et en se prétendant experts, ce sont ceux qui s'attendent à ce que les débutants sachent réellement tout et soient de vrais experts.

Entre l'attitude "il faut réutiliser LAPACK" pour faire une multiplication de deux matrices d'ordre 2 et "il faut tout redévelopper soi-même à commencer par la libc", il y a un juste milieu; et celui-ci va dépendre du contexte dans lequel on est.

(Ceci dit, suivant le cursus, je m'attends à ce qu'un programmeur ait des notions de gestion de mémoire plus poussée que "on laisse faire le GC" même si c'est une attitude raisonnable dans plus en plus de cas).

(En passant, la gestion des charsets, c'est certainement pas un sujet que j'aurais mis comme pierre angulaire d'un défi -- et je suis d'accord avec ceux qui pensent que c'était le seul point où une recherche était nécessaire --, plus je regarde, plus je trouve que la situation normalisée est confuse.)

+1

Et j'irais même plus loin...

Bien sur, tous les aspects liés à la gestion dynamique de la mémoire sont particulièrement importants à connaitre en C++, tout comme ils le sont en C.

Mais il n'empêche que, grâce aux mécanismes qui prévalent en C++, il est possible que cela se passe de manière tout à fait transparente pour le programmeur, et cela nous permet de n'envisager le recours à la gestion dynamique de la mémoire que dans des cas bien particuliers.

Or, l'expérience montre que, si un débutant entend parler "trop tot" de la gestion dynamique de la mémoire, il aura souvent tendance à y recourir de manière beaucoup trop systématique, sans s'inquiéter des alternatives, et souvent de manière tout à fait aberrante...

L'idée généralement suivie sur le forum est de prendre le problème dans l'autre sens, et de faire prendre conscience à la personne qui pose une question qu'il a largement intérêt à user et abuser des autres mécanismes offerts par le C++ de telle manière à ne s'inquiéter de la gestion dynamique de la mémoire que lorsqu'il n'a pas d'autre choix... ou lorsqu'il a réellement intérêt, pour question de performances, à s'en préoccuper effectivement.

Il devient alors "beaucoup plus simple" pour tout le monde d'arriver à faire quelque chose "de qualité"

[Mac LAK]

Les profs n'ont déjà pas le temps de voir tout ce que la plupart des développeurs rencontreront, et tu voudrais qu'ils abordent des situations que la plupart ne rencontreront pas? J'ai une bonne série de choses à voir avant.

Un débutant, pour moi, possède au minimum un Bac+4, souvent un Bac+5. J'aurais peut-être dû le préciser, mais nous n'employons pas de développeurs avec Bac+3 ou moins...

Je trouve tout simplement inadmissible qu'un débutant n'ait jamais vu ces notions pendant au minimum deux années d'études spécialisées, voire quatre ans pour beaucoup.

A mon époque, pas si éloignée que ça (1999), on avait non seulement le temps de le voir, mais on en voyait même encore plus que ça. Je suis sorti de la fac en connaissant plus d'une dizaine de langages de programmation, ayant tous une mentalité de fonctionnement bien différente les uns des autres, et d'excellentes bases mathématiques et logiques. Ça ouvre l'esprit. Maintenant, ils sortent en en connaissant tout au plus deux, et souvent de façon très superficielle, et sont mauvais en maths.

Tu trouves normal, toi, qu'un soi-disant ingénieur débutant avec Bac+5 ne connaisse même pas la différence entre la syntaxe et la sémantique ?
Qu'il ne sache pas ce qu'est une précondition ? Ou un graphe ? Qu'il ne sache pas vérifier par lui-même que sa boucle peut ne pas se terminer ? Qu'il ne sache pas se débrouiller avec un chiffre en base 2 ou 16 ? Qu'il ne comprenne pas pourquoi le sizeof d'un pointeur ne renvoie pas la taille du tableau ? Et j'en passe !!!

Alors oui, je me contrefiche qu'il sache modifier une JVM ou faire de beaux dessins avec AWT, ou encore qu'il connaisse bien UML. Le haut niveau, ça sert quand on a les bases, pas avant.

Il y a une chose qui me gave plus que des débutants arrivant en croyant tout savoir et en se prétendant experts, ce sont ceux qui s'attendent à ce que les débutants sachent réellement tout et soient de vrais experts.

Ce sont des débutants : je ne m'attends pas à ce qu'ils soient des experts. Je fais parfaitement la distinction, ne t'inquiètes pas.

Par contre, je m'attends à ce qu'ils sachent APPRENDRE (chose qui devient difficile, les jeunes sortent de plus en plus des écoles en croyant tout savoir...), et qu'ils connaissent les BASES de notre métier. Point barre, le reste, ça s'apprend sur le tas.

Et c'est de moins en moins souvent le cas... Et c'est là le problème principal. Je ne dis pas forcément que c'est la faute des profs qui ont souvent des "ordres", mais c'est quand même une situation pitoyable.

[Jean-Marc.Bourguet]

Un débutant, pour moi, possède au minimum un Bac+4, souvent un Bac+5. J'aurais peut-être dû le préciser, mais nous n'employons pas de développeurs avec Bac+3 ou moins...

...

Tu trouves normal, toi, qu'un soi-disant ingénieur débutant avec Bac+5 ne connaisse même pas la différence entre la syntaxe et la sémantique ?
Qu'il ne sache pas ce qu'est une précondition ? Ou un graphe ? Qu'il ne sache pas vérifier par lui-même que sa boucle peut ne pas se terminer ? Qu'il ne sache pas se débrouiller avec un chiffre en base 2 ou 16 ? Qu'il ne comprenne pas pourquoi le sizeof d'un pointeur ne renvoie pas la taille du tableau ? Et j'en passe !!!

Ce genre là ne passe pas l'étape des entretiens d'embauche (oui, j'en ai vus; je suppose -- j'espère -- qu'ils sont surreprésentés aux entretiens parce que les autres n'ont pas besoin d'en passer autant avant d'être engagés; si les 50% les moins bons passent trois fois plus d'entretiens que les 50% les meilleurs, ils représentent 75% des gens passant des interviews...).

Alors oui, je me contrefiche qu'il sache modifier une JVM ou faire de beaux dessins avec AWT, ou encore qu'il connaisse bien UML. Le haut niveau, ça sert quand on a les bases, pas avant.

Tout dépend aussi de ce que tu appelles les bases. Suivant le domaine d'application, les bases nécessaires peuvent être très différentes. Malgré mon expérience, je n'ai pas les bases pour postuler à certaines offres d'emploi.

Par contre, je m'attends à ce qu'ils sachent APPRENDRE (chose qui devient difficile, les jeunes sortent de plus en plus des écoles en croyant tout savoir...),

Mon grand père disait la même chose... sans parler de Caton l'ancien... Quand j'étais assistant, j'étais horrifié de voir la mentalité d'étudiants qui n'avaient que quelques années de moins que moi. Quelqu'un de plus expérimenté m'a fait remarquer qu'il y avait exactement les mêmes cas et dans le même type de proportion dans mon année; simplement, qui se ressemblent s'assemblent et je ne les fréquentais simplement pas.

Je ne dis pas forcément que c'est la faute des profs qui ont souvent des "ordres", mais c'est quand même une situation pitoyable.

L'établissement d'un programme (d'une formation, pas informatique), ce n'est pas simple. Je ne crois pas qu'il y ait des "ordres" empêchant de faire ce qu'il faut, mais des contraintes contradictoires (certaines administratives et relativement absurdes, mais j'ai l'impression que les pires d'entre elles sont contournées sans états d'âmes) et les divers établissements bâtissent un programmes offrant des compromis différents -- suivant les activités dans la région ou suivant les lubies plus ou moins réalistes d'une personne influente.

En écrivant ceci, je me demande aussi dans quelle mesure vous ne filtrez pas assez ceux qui ont suivi un cursus inadapté à vos besoins -- mais pas nécessairement mauvais pour autant, il est peut-être adaptés à d'autres entreprises.

[ram-0000]

Un débutant, pour moi, possède au minimum un Bac+4, souvent un Bac+5. J'aurais peut-être dû le préciser, mais nous n'employons pas de développeurs avec Bac+3 ou moins...

Dommage, avec mon bac + 0, je n'aurais jamais dû/pu travailler. Et pourtant, cela fait 20 ans que je bosse dans l'info (dev en SSII puis intégrateur puis consulting) et mes employeurs n'ont jamais eu à se plaindre (voire même le contraire)

[Jean-Marc.Bourguet]

Dommage, avec mon bac + 0, je n'aurais jamais dû/pu travailler.

Il y a des gens sans diplômes qui sont nettement meilleurs que certains qui en ont (une des personnes les plus douées que j'ai jamais rencontré n'en avait pas). Mais faire passer un entretien d'embauche coûte déjà une petite fortune (le déplacement, parfois l'hôtel si la personne vient de loin, les salaires et le temps passé de ceux qui font passer les entretiens). Ceci considéré, le diplôme reste un des filtres ayant un des meilleurs rapport qualité/coût.

[Mac LAK]

Ce genre là ne passe pas l'étape des entretiens d'embauche (oui, j'en ai vus; je suppose -- j'espère -- qu'ils sont surreprésentés aux entretiens parce que les autres n'ont pas besoin d'en passer autant avant d'être engagés; si les 50% les moins bons passent trois fois plus d'entretiens que les 50% les meilleurs, ils représentent 75% des gens passant des interviews...).

Le problème, c'est aussi que ça devient la "norme" de sortie des filières de formation... Et que l'on n'écoute pas assez souvent l'avis des techniques lors des embauches ou des prises d'assistants.

Tout dépend aussi de ce que tu appelles les bases. Suivant le domaine d'application, les bases nécessaires peuvent être très différentes. Malgré mon expérience, je n'ai pas les bases pour postuler à certaines offres d'emploi.

Informatique industrielle, temps réel, embarqué, développement système...
Ceci étant dit, j'ai toujours vu un développeur "comme moi" se mettre plus vite à une techno de haut niveau qu'un "spécialiste" du haut niveau réussir à se mettre dans le cambouis...

Je ne dis pas qu'une des deux manières de voir l'informatique est supérieure à l'autre, mais ce qui est certain, c'est que je vois plus de gens psychorigides et imbus d'eux-même dans le haut niveau que dans le bas niveau.

les divers établissements bâtissent un programmes offrant des compromis différents -- suivant les activités dans la région ou suivant les lubies plus ou moins réalistes d'une personne influente.

Ni l'une, ni l'autre dans mon cas. La région toulousaine est plutôt orientée informatique industrielle, et je continue de voir des débutants sortir des filières du coin avec une connaissance nulle (voire négative) des problématiques industrielles... Je ne te parle même pas des contraintes de production en série, là ça leur passe carrément au dessus de la tête.

Et t'as donc toujours des "p'tits jeunes" qui trouvent que programmer en C un micro contrôleur, c'est pas cool et qu'on ferait mieux de mettre un Pentium 4 bi-cœur dessus et le programmer en Java. Le fait que le prix de la série est multiplié par 20 ne semble pas les déranger, pas plus que les problèmes de performances...

En écrivant ceci, je me demande aussi dans quelle mesure vous ne filtrez pas assez ceux qui ont suivi un cursus inadapté à vos besoins -- mais pas nécessairement mauvais pour autant, il est peut-être adaptés à d'autres entreprises.

On filtre. C'est pour ça qu'on est surchargés, d'ailleurs : on trouve très difficilement.
Et oui, on se contrefiche complètement de faire du web, là par contre il n'y a pas pénurie...
Ce qui fait qu'au final, on est obligés parfois de "prendre de la viande", et leur faire faire du code qu'ils comprennent à peine. Bac+5 pour faire l'analyste programmeur, ça c'est du progrès dans l'éducation...

Dommage, avec mon bac + 0, je n'aurais jamais dû/pu travailler. Et pourtant, cela fait 20 ans que je bosse dans l'info (dev en SSII puis intégrateur puis consulting) et mes employeurs n'ont jamais eu à se plaindre (voire même le contraire)

Ram, c'est 20 ans derrière, ça... Je te parle de débutants, ceux qui ont eu leur diplôme l'année dernière ou au pire celle d'avant.

Ceci considéré, le diplôme reste un des filtres ayant un des meilleurs rapport qualité/coût.

Avec l'épluchage des fautes d'orthographe sur le CV, de la lettre de motivation, et vérifier que le candidat sait utiliser les outils informatiques et n'indente pas son texte à l'espace sous Word...

[pfeuh]

Salut,

Ceci étant dit, j'ai toujours vu un développeur "comme moi" se mettre plus vite à une techno de haut niveau qu'un "spécialiste" du haut niveau réussir à se mettre dans le cambouis...

Je ne dis pas qu'une des deux manières de voir l'informatique est supérieure à l'autre, mais ce qui est certain, c'est que je vois plus de gens psychorigides et imbus d'eux-même dans le haut niveau que dans le bas niveau.

Et t'as donc toujours des "p'tits jeunes" qui trouvent que programmer en C un micro contrôleur, c'est pas cool et qu'on ferait mieux de mettre un Pentium 4 bi-cœur dessus et le programmer en Java. Le fait que le prix de la série est multiplié par 20 ne semble pas les déranger, pas plus que les problèmes de performances...

Ben dis donc! En tout cas, ça me fait plaisir de constater que je ne suis pas le seul à penser que le niveau a lamentablement baissé ces dernières années.

A+

Pfeuh

[Jean-Marc.Bourguet]

Le problème, c'est aussi que ça devient la "norme" de sortie des filières de formation... Et que l'on n'écoute pas assez souvent l'avis des techniques lors des embauches ou des prises d'assistants.

Ça, c'est un problème chez vous, pas un problème de formation...

Informatique industrielle, temps réel, embarqué, développement système...

Je chercherais dans les gens ayant une formation d'électronique ou d'automatique avant de chercher des informaticiens.

Ceci étant dit, j'ai toujours vu un développeur "comme moi" se mettre plus vite à une techno de haut niveau qu'un "spécialiste" du haut niveau réussir à se mettre dans le cambouis...

J'ai vu aussi des spécialistes de bas niveau incapables de penser autrement qu'en terme de bits.

Je ne dis pas qu'une des deux manières de voir l'informatique est supérieure à l'autre, mais ce qui est certain, c'est que je vois plus de gens psychorigides et imbus d'eux-même dans le haut niveau que dans le bas niveau.

J'ai aussi trop vu des compteurs de nano secondes sur des processus qui de toute manière étaient bornés par les IO. Et j'ai pas une population assez grande pour conclure dans un sens ni dans l'autre.

Salut,
Ben dis donc! En tout cas, ça me fait plaisir de constater que je ne suis pas le seul à penser que le niveau a lamentablement baissé ces dernières années.

Non, on a retrouvé des tablettes sumériennes se plaignant de ça également...

[Mac LAK]

Je chercherais dans les gens ayant une formation d'électronique ou d'automatique avant de chercher des informaticiens.

On a des électroniciens, rassures-toi. Mais ils ne sont pas capables (et c'est normal) de programmer un contrôleur, un processeur ou tout ce qui est au dessus du VHDL, tout comme nous (softeux) ne descendons pas en dessous des registres matériels.
Quant aux automaticiens... No comment, c'est pas en Grafcet que l'on bosse à ce niveau, c'est sûrement un des pires choix que l'on pourrait faire pour ce genre de boulot.

J'ai vu aussi des spécialistes de bas niveau incapables de penser autrement qu'en terme de bits.

Certes. Mais moi, je te parle de proportions générales, et côté psychorigidité, c'est plus fréquent à haut niveau qu'à bas niveau. Très très largement plus fréquent...

J'ai aussi trop vu des compteurs de nano secondes sur des processus qui de toute manière étaient bornés par les IO. Et j'ai pas une population assez grande pour conclure dans un sens ni dans l'autre.

J'ai trop vu des "développeurs" haut niveau ne pas se rendre compte de ce qu'était une nanoseconde... Pas même une micro ou une milliseconde, d'ailleurs : tant que "à l'œil" ça va assez vite, ça leur suffit, peu importe si ça met le CPU à 100% et/ou que c'est dix mille fois plus lent que les sous-systèmes qui attendent désespérément pendant ce temps.

Non, on a retrouvé des tablettes sumériennes se plaignant de ça également...

Sauf que... C'est hélas vrai. Que ce soit à haut ou bas niveau, il y a des fondamentaux à connaître (ne serait-ce que la logique et l'algorithmique !!!), et c'est de moins en moins connu.
Et tu ne me feras pas croire qu'il est normal, même (surtout ?) pour un programmeur Java ou C#, d'ignorer les concepts élémentaires de programmation parallèle, de BDD ou de communication réseau...

Utiliser du haut niveau ? OK. Ils sont concentrés dans les fonctions de haut niveau, alors ? Même pas. Ils en font quoi alors de leur langage ? Bonne question... Ça me fait penser à ceux qui ont Linux chez eux, et qui à part mettre à jour / customiser leur OS et le recompiler, ne l'utilisent jamais réellement pour une application concrète : ça fait joli sur le papier, mais ça ne sert à rien.

[Invité]

Un débutant, pour moi, possède au minimum un Bac+4, souvent un Bac+5. J'aurais peut-être dû le préciser, mais nous n'employons pas de développeurs avec Bac+3 ou moins...

Marrant, nous c'est l'inverse... Le raisonnement étant qu'un Bac +trop est soit hors de prix (pour ce montant on a quelqu'un qui a une longue expérience et un revers de carrière, ou un surdiplomé à l'étranger, et y'a juste pas photo), soit a la tête mal faite (du mal à comprendre la différence entre un livre et la vraie vie, ou le genre qui, avec ses souvenirs approximatifs de prépa intégrée ou d'école à cent balles le point, se croit habilité à te donner des leçons de maths en entretien...)

Du coup, on choppe des IUT et on les forme, ou alors, des quinquas, ou alors on refuse du boulot.

Perso, je n'encouragerai pas mes gosses à faire des études longues à la fac (ou dans de petites écoles), professionnellement, le jeu n'en vaut pas la chandelle. C'est bien sur un peu dommage qu'un système, en essayant de s'ouvrir, devienne en fait plus élitiste, mais bon, c'est de la politique, ca...

Sérieusement, je crois que le jeunisme ambiant, et un certain discours des écoles sur le salaire d'embauche, font qu'on attend beaucoup trop des débutants aujourd'hui. Les employeurs leur prêtent trop (et les payent en conséquence), et eux même ont une idée irréaliste de la valeur de leur formation. Ca ne peut pas bien finir.

Il y aura donc une génération perdue, mais j'ai la sensation que celle qui la suit (diplomés cycle court actuels, donc une petite vingtaine maintenant) est un peu plus raisonnable, et que les papys commencent à organiser la résistance.

Faut pas avoir 30 ans par les temps qui courent, quoi...

Francois

[coyotte507]

Après tout ce que vous dites, on a l'impression que tous les jeunes que vous embauchez n'y connaissent que dalle ... Rassurez-moi, vous en trouvez quand même des biens???

[nicolas.sitbon]

Après tout ce que vous dites, on a l'impression que tous les jeunes que vous embauchez n'y connaissent que dalle ... Rassurez-moi, vous en trouvez quand même des biens???

Je répond à ta question, ça fait plus d'un an que l'on recherche un développeur C/sécurité/linux dans ma boite, à raison d'un candidat par jour en moyenne (et je n'exagère pas), on a toujours rien trouvé de potable, et ce qui se rapprochait le plus d'un développeur était souvent des autodidacte et non des ingénieurs. Dans le domaine du C, le niveau est catastrophique, c'est le cas de le dire, il y a un réel problème dans l'enseignement de ce langage. J'en ai vu des vertes et des pas mures je peux dire.