Discussion :

[el_slapper]

+1 avec davcha.

en prépa, il y avait un prof de maths qui nous faisait passer les khôlles, on sentait le whisky avant de le voir. eh bien il ne loupait rien, et donnait des notes assez justes(quoiqu'avec plus d'amplitude que ses collègues). Et surtout, il savait expliquer là ou était l'erreur, et comment il aurait fallu procéder.

Evidemment, les mauvais le haïssaient(leurs notes étaient pires qu'avec les autres profs). Mais pour les moyens et les bons, il était très interessant. Et ça valait le coup de se pincer le nez.

Aucun prof n'est parfait. dans toute formation, on trouve une ou deux tanches, tous les autres ont beaucoup à faire partager, à condition de s'en donner la peine et de ne pas se braquer au premier défaut(de prononciation, d'alcoolisme, d'écriture, de pédagogie, etc.....)

[TropMDR]

Quelqu'un qui n'est pas capable d'utiliser les pointeurs facilement, rapidement et correctement, n'est pas informaticien. Quelqu'un qui n'utilise jamais la récursivité ou un style "à la fonctionnelle" quand c'est pertinent, parce que ces notions lui ont toujours semblé un peu "magiques", n'est pas informaticien. Quelqu'un qui est incapable de coder bas niveau n'est pas informaticien. Quelqu'un qui ne peut rien écrire sans utiliser de SGBDR n'est pas informaticien. Quelqu'un qui est perdu face à la POO, ou qui au contraire ne veut entendre parler que du paradigme objet, n'est pas informaticien. Quelqu'un qui peut coder une application qui marche, en assemblant des bouts de code JAVA trouvés à droite et à gauche, mais sans ne rien comprendre au détail du code, parce qu'il n'a même pas bien compris ce qu'est un appel de fonction ou une variable locale, et qui ne comprendra jamais rien à l'algorithmique, n'est pas un informaticien.

Ah merde, il faut être à la fois spécialiste du fonctionnel, de la POO, du C, de l'embarqué critique, de l'assembleur et de la mécanique quantique pour être informaticien. C'est chaud :-\ Euuuuh, tu en connais beaucoup des informaticiens finalement ?

le problème de la récursivité vois tu, c'est que c'est la solution de simplicité pour écrire un algo, et au passage, plomber les performances...
maintenant compare la suite de fibonacci écrite en récursif, (cela s'y prête, puisque ce n'est jamais que de la récursivité) et le même algorithme écrit en programmation dynamique... en itératif... et on en reparlera après.

Peut être qu'au lieu de te répéter à longueur de temps que le prof en face de toi est forcément un alcoolique incompétent, tu aurais pu l'écouter 5 minutes et te rendre compte que personne n'a jamais dit qu'il fallait programmer fibonnacci en récursif, parce qu'une complexité exponentiel n'est pas le bon choix face à une complexité logarithmique.

Et donc tu suggères aux programmeurs de ne pas "choisir la solution de simplicité" quand ils écrivent un programme ? C'est vrai que quelque part, c'est dangereux. Un algo implémenté simplement à plus de chance d'être correct, lisible, maintenable, modifiable. Mauvaise idée. Il vaut mieux tout de suite passer un temps fou à faire des micro-optims que le compilo aurait faites tout seul...

alors ne blâme pas une personne qui n'a que rarement recours à la récursivité sous prétexte que ca s'y prête, car ce quelqu'un est peut-être juste un peu plus malin que toi et a préféré employé un algorithme itératif, qui sera certainement (à part quelques cas particuliers bien précis) nettement plus performant...

Tu as des preuves de ce que tu avances ? Des benchs, des explications rationnelles ? Ou juste "algo récursif == langage fonctionnel == lisp == années 60 et interprété == lent" ?

d'ailleurs c'est étonnant quand on y pense... mais la première chose que fait un compilateur fonctionnel, lorsque tu lui colle un algorithme récursif "normal" c'est le rendre itératif...

L'autre option c'est qu'ils fassent ça pour que le programmeur puisse écrire des algos en récursif, mais qu'après en fait, ça s'exécute exactement aussi vite que la version iterative ?

mais bon les chercheurs qui ont développer le compilateur d'OCaml ont certainement due ce tromper, puisque tu viens d'énoncer toi même que si on utilisait pas la récursivité juste parce que c'est pertinent, on est pas programmeur...

Ouais, ils utilisent jamais la programmation récursives les développeurs d'ocaml

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
trop@mdr /tmp % cd ocaml-3.12.0+rc1
trop@mdr ocaml-3.12.0+rc1 % grep -R "let rec" * | wc
2119

[davcha]

Tu as des preuves de ce que tu avances ? Des benchs, des explications rationnelles ? Ou juste "algo récursif == langage fonctionnel == lisp == années 60 et interprété == lent" ?

L'autre option c'est qu'ils fassent ça pour que le programmeur puisse écrire des algos en récursif, mais qu'après en fait, ça s'exécute exactement aussi vite que la version iterative ?

Stack Overflow.

A noter que dans certains langages, l'ordre des opérations va influencer les performances, quand il s'agit d'un algorithme récursif. Et ce, sur des choses aussi simples que le calcul d'une factorielle (je veux dire : n*f(n-1) !== f(n-1)*n).

[chaplin]

Je suis un peu choqué sur l'histoire du prof/directeur alcoolique.

A voir où tu en es, cela n'a pas semblé influencer négativement ta vie professionnelle à ce point là. C'est donc qu'à défaut de faire son travail de façon impeccable (et encore, j'en sais rien, je décris le pire des cas), il faisait son boulot suffisamment bien pour ne pas démolir des carrières... Tout du moins la tienne.

Ce que je veux dire c'est que des défauts et difficultés d'ordre personnel, tout le monde en a. Et on aimerait, dans l'idéal, que ces défauts n'aient aucune influence sur notre vie professionnelle et sur la vie professionnelle de nos collègues. Cependant, on ne vit pas dans un monde fait exclusivement d'idées.

Autant dire qu'avant de parler d'humilité, il faudrait parler un peu d'empathie, voie de compassion, non ?...

Vous sentez pas grondés, je fais juste une remarque sur des propos qui m'ont un peu (juste un peu hein) choqués.

J'en ai aussi rencontré des profs alcooliques (3), ils avaient un bon sens de l'humour quand ils étaient saouls. Il y en avait même un qui n'avait plus de permis, un autre a été secouru dans sa voiture, lol. That's life.

Ensuite, il s'agit de mettre le filtre, c'est à dire apprécier leur sensibilité et ne pas se moquer d'eux comme certains se plaisaient à le faire. Ils étaient littéralement prisonnier de l'alcool.

[cinemania]

TropMDR... la réponse sur la récursivité se faisait en réponse à quelqu'un...

et effectivement davcha t'a répondu... le stackoverflow.

n'oublie pas que tous les OS ne fonctionnent pas pareil, et à part linux où la pile user est "extensible" sous windows elle est fixée au démarrage de l'application, et même pour être précis à la compilation, et crois moi elle n'est pas énorme... donc un algorithme récursif utilisant une profondeur de recherche trop élevé ou trop de paramètres à fournir à la méthode récursive va vite sur-encombrer la pile...

utiliser un algorithme récursif va également abuser des instructions processeurs de saut inconditionnels (en plus des sauts conditionnels), horriblement lentes en terme de cycles inutilement consommés, et tu va t'étonner qu'un algorithme itératif équivalent est nettement plus rapide.

c'est bien de savoir programmer, mais parfois connaitre les spécifications techniques de ce sur quoi on travail, ne fait pas de mal.

quand au fait que les langages fonctionnels recompilent en virant la récursivité lorsque c'est possible, ce n'est pas pour qui ou quoi, ou pour les développeurs, mais bien due à une utilité de performances et surtout de robustesse... avoir un stack overflow excuse du peu, mais en terme de robustesse j'ai déjà vu mieux.

de plus je n'ai jamais dit qu'il ne fallait pas systématiquement utiliser la solution de simplicité, malheureusement tu apprendras probablement trop tard que dans la vie... la solution de simplicité n'est pas toujours la meilleur...
preuve pour la récursivité.

et tu as toi même dit que personne n'a dit que l'on devait écrire fibonacci en récursif, pourtant si, la phrase à laquelle j'ai répondu le sous entendais, car même si c'est un problème d'explosion combinatoire, cela n'en reste pas moins un algorithme récursif...
tu vois toi même tu te contredit... l'écrire en récursif c'est la simplicité, et après pourquoi écrire un programme compliqué quand on peut écrire un programme simple qui sera plus sure... c'est ce que tu as dit... et on sais très bien que là en plus d'être moins sure (dépassement de pile) il sera plus lent. ( vu que le même problème écrit en itératif est en complexité O(n) au lieu de O(2^n) )

bien entendu un développeur qui n'a jamais vu comment fonctionnait un processeur ne risque pas de savoir ces choses, ou s'il ne s'est pas penché sur la question, de même un développeur qui n'a jamais vraiment sue comment fonctionnait son OS préféré (ou pas) ne risque pas de le savoir...
c'est pourquoi il est préférable quand même d'aller à l'école, car même si l'ensemble des matières enseignées peuvent paraitre inutiles, parfois on t'y apprend des trucs utiles...
comme par exemple qu'il est inutile de courir après une chimère et que si le programme qu'on te demande ressemble au problème du langage universel, il est inutile de commencer, car c'est un problème insoluble...
et parfois également on y apprend aussi toutes les références sur la récursivité et les problématiques que j'ai énoncé...

même de nos jours, avec des performances, de la mémoire en pagaille... connaitre ses classiques de l'optimisation ne fait pas de mal.
d'ailleurs beaucoup de soft ou de jeux pour ne cité que ceux là, tournerais mieux, et nécessiteraient des config nettement moins volumineuses, si ils étaient ne serait ce qu'un peu mieux écrits, et si les développeurs n'avaient pas systématiquement couru à la solution de simplicité, mais avaient aussi été un peu mieux formés ...

le challenge de ce débat, faut-il avoir été à l'école pour bien programmer, reste de savoir ce qu'on appel bien programmer.
l'algorithmique ca ne s'apprend pas sur le tas sans de solides bases théoriques qu'on apprend pas comme ça. pourtant l'algorithmique est souvent à la base même de tous les problèmes que l'on peut se poser ou que les développeurs vont devoir résoudre.
De même juste savoir que Quicksort ou HeapSort trient plus vite que bubblesort... c'est bien de le savoir mais ca ne règle en rien le problème, car souvent les gens ne les comprennent pas ces algorithmes, alors les réécrire si ce n'est du par coeur...
Il en est de même sur la base fondamentale de l'informatique, les structures de données, certes pour s'en servir on a pas forcément besoin de connaitre la complexité mathématique et les formules qui se cache derrière tel ou tel modèle, mais cela peut parfois aider à mieux choisir quelle structure utiliser.
l'école ici ne t'apprend pas à tout connaitre, surtout dans ses domaines, car c'est impossible...
non elle est là pour t'enseigner les bases fondamentales qui se cachent derrière afin de mieux appréhender ces problèmes.

maintenant si pour vous bien programmer, ca se cantonne à écrire un code propre, bien écrit et bien lisible, respectant des normes qui facilite le débogage... effectivement là, avoir été à l'école est un peu superflux.

[TropMDR]

et effectivement davcha t'a répondu... le stackoverflow.

n'oublie pas que tous les OS ne fonctionnent pas pareil, et à part linux où la pile user est "extensible" sous windows elle est fixée au démarrage de l'application, et même pour être précis à la compilation, et crois moi elle n'est pas énorme... donc un algorithme récursif utilisant une profondeur de recherche trop élevé ou trop de paramètres à fournir à la méthode récursive va vite sur-encombrer la pile...

Bon, déjà, il y a plusieurs choses... La première, c'est qu'il faut se rappeler qu'entre le code que tu écris et le code qui est exécuté, il y a un compilateur. Ce qui qui veut dire qu'il faut arrêter de penser "récursif => nouvelle stack frame à chaque appel". Ce n'est pas vrai. Les fonctions écrites en style récursif terminal, c'est quand même assez courant.

Ensuite, pour tes histoires de taille de pile, sous un linux installé normalement, j'ai une taille de pile limite de 8192 ko, comprendre 8MO (à une vache près, c'est pas une science exacte). Un programme caml compilé sous windows a une taille limite de pile de 8MO. A vu de pif, ça se ressemble.

utiliser un algorithme récursif va également abuser des instructions processeurs de saut inconditionnels (en plus des sauts conditionnels), horriblement lentes en terme de cycles inutilement consommés, et tu va t'étonner qu'un algorithme itératif équivalent est nettement plus rapide.

C'est là que le cours d'architecture des ordinateurs t'aurais aidé à ne pas raconter n'importe quoi, puisque tous les processeur modernes ont un pipeline d'instruction et font de la prédiction de branchement. Et dans le cas du saut inconditionnel, la prédiction se fait plutôt bien !

Ensuite j'aimerais savoir d'où tu sors qu'un programme écris en style récursif a plus de saut inconditionnel. Tu peux justifier un peu ? Parce que moi à l'école, on m'a appris qu'un programme tail-rec, il est compilé par une boucle, et que donc ça change rien.

Il y a un résultat assez intéressant en fait : tout programme itératif a espace mémoire constant peut être écris en style récursif terminal. Dit autrement, tant que ton programme impératif n'a pas besoin d'une structure de backtrack (typiquement une pile. Oh bah tient, dans ce cas, la pile d'appel fait le même boulot !), tu peux l'écrire en récursif, et il sera compilé comme le programme itératif.

Après qu'on ne s'y trompe pas. Je ne dis pas qu'il ne faut jamais utiliser de boucle. Juste que l'argument "non mais c'est lent le récursif" est abscons.

c'est bien de savoir programmer, mais parfois connaitre les spécifications techniques de ce sur quoi on travail, ne fait pas de mal.

Ah là on est d'accord. Par exemple avoir de vague notion de ce que fait ton compilo pour ne pas raconter n'importe quoi

quand au fait que les langages fonctionnels recompilent en virant la récursivité lorsque c'est possible, ce n'est pas pour qui ou quoi, ou pour les développeurs, mais bien due à une utilité de performances et surtout de robustesse... avoir un stack overflow excuse du peu, mais en terme de robustesse j'ai déjà vu mieux.

T'es en train d'expliquer que si un compilateur fait des optimisations, ce n'est pas pour le développeur qui écris des applications, c'est juste pour euh... en fait non je comprends pas.

et tu as toi même dit que personne n'a dit que l'on devait écrire fibonacci en récursif, pourtant si, la phrase à laquelle j'ai répondu le sous entendais, car même si c'est un problème d'explosion combinatoire, cela n'en reste pas moins un algorithme récursif...
tu vois toi même tu te contredit... l'écrire en récursif c'est la simplicité, et après pourquoi écrire un programme compliqué quand on peut écrire un programme simple qui sera plus sure... c'est ce que tu as dit... et on sais très bien que là en plus d'être moins sure (dépassement de pile) il sera plus lent. ( vu que le même problème écrit en itératif est en complexité O(n) au lieu de O(2^n) )

Et moi je t'écris un algo en récursif (exponentiation rapide) en complexité O(log n). Donc ta version itérative est minable à coté. Est ce que j'en déduis qu'il ne faut jamais écrire en itératif ?

Je crois que ce que tu n'as pas bien compris, c'est que le temps cerveau d'un développeur est une denrée rare, et que l'économiser est une bonne chose. Si notre développeur doit à un moment calculer la taille d'un arbre, il écrit en quelques secondes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
let rec height = function
| Leaf -> 0
|Node (l, _, r) -> 1 + max (height l) (height r)

Et après il peut se concentrer sur ce qui compte vraiment, la structure de son projet, l'algorithme central dont il aimerait abaisser la complexité, se demander où il devrait ajouter un cache ou de la mémoization. Et si un jour son profiler lui dit qu'il passe trop de temps dans height, il sera grand temps de l'améliorer.

L'autre option est de se créer à la main une structure de backtrack, soit par inversion de pointeurs, soit avec une pile. Il y passera de longues minutes, voir heures, aura de bonnes chances de se tromper, et aura des performances identiques, et si meilleur, d'epsilon.


Mais c'est peut être un des travers de l'école justement. Faire croire à des étudiants qu'écrire la fonction de calcul de la hauteur est une fin en soit. En TP, on leur dit "écrivez cette fonction" pour chaque fonction, et ils risquent d'en déduire que cette fonction est aussi importante que toutes les autres puisqu'on lui a demandé de l'écrire (si vous êtes arrivés à la fin de cette phrase et que vous l'avez comprise en une seule fois, chapeau).

Bref, il est probable que l'école ne soit pas ce qui permettent d'apprendre à avoir une vision d'ensemble d'un projet, puis de dépenser son temps de façon intelligente.

En revanche l'école permet de donner les outils permettant de comprendre où il faut dépenser son temps, comme le calcul de complexité, la compréhension de ce que fait et ne fait pas un compilo (combien d'heures perdues par des développeur qui veulent "optimiser" leur code alors que le compilo l'aurait fait mieux qu'eux ?), les bonnes structures de données, les bon algos, etc.

C'est le manque par certains de ces outils qui engendre une telle perte de temps et génère souvent des codes obscurs parce que "optimisés" de façon absurde, par exemple en fuyant le style récursif parce qu'on a lu dans WaRloRdZ MaG qu'un Véritable ne l'utilise jamais...

[el_slapper]

Après qu'on ne s'y trompe pas. Je ne dis pas qu'il ne faut jamais utiliser de boucle. Juste que l'argument "non mais c'est lent le récursif" est abscons.
(.../...)Je crois que ce que tu n'as pas bien compris, c'est que le temps cerveau d'un développeur est une denrée rare, et que l'économiser est une bonne chose. Si notre développeur doit à un moment calculer la taille d'un arbre, il écrit en quelques secondes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
let rec height = function
| Leaf -> 0
|Node (l, _, r) -> 1 + max (height l) (height r)

Et après il peut se concentrer sur ce qui compte vraiment, la structure de son projet, l'algorithme central dont il aimerait abaisser la complexité, se demander où il devrait ajouter un cache ou de la mémoization. Et si un jour son profiler lui dit qu'il passe trop de temps dans height, il sera grand temps de l'améliorer.

L'autre option est de se créer à la main une structure de backtrack, soit par inversion de pointeurs, soit avec une pile. Il y passera de longues minutes, voir heures, aura de bonnes chances de se tromper, et aura des performances identiques, et si meilleur, d'epsilon.(.../...)

+1(même si je suis pas sur de comprendre cette syntaxe, moi je bosse sur des langages verbeux). early optimization is the root of evil est une phrase importante. Dans certains cas, on peut penser 2-3 petits trucs à l'avance pour éviter des horreurs(genre une boucle qui s'arrête à une case vide sur EXCEL au lieu d'aller jusqu'à la ligne 65535), mais ça s'arrête là.

Un code, ça doit marcher. Une fois que ça marche, que c'est validé, toussa, on peut réfléchir à d'autres trucs - si on a le budget pour. Si changer d'écran prend 10 secondes, le budget viendra très vite. Si le batch de nuit peut être amélioré de 10 secondes, le budget ne viendra jamais.

[Franck SORIANO]

Bref, il est probable que l'école ne soit pas ce qui permettent d'apprendre à avoir une vision d'ensemble d'un projet, puis de dépenser son temps de façon intelligente.

Ca ça dépend de l'école et de ce qu'on t'y enseigne.
Si tu vas dans une école qui t'apprend le langage X ou Y... tu apprendras à être un pisseur de code qui ne voit pas plus loin que le bout de code qu'on lui a demandé de coder.
Dans la mienne, les TP c'était plutôt : on te donne un cahier des charges tel qu'un client pourrait te le donner (et le plus souvent c'était des cas réels auxquels les profs avaient déjà été confrontés) , on te donnait une date de livraison, et à toi de te débrouiller :
- Analyser le CdC pour bien comprendre le sujet, identifier les points flous et aller demander des précisions aux profs.
- Identifier les tâches à faire
- se répartir les tâches avec tes co-TP
- suivre l'avancement et rendre le projet à la date demandée.

Quand tous les projets et tout les TPs se passent comme ça pendant 3 ans, lorsque tu sors de la formation, tu sais ce qu'est un projet, sur quoi passer du temps, et comment travailler en équipe.

early optimization is the root of evil est une phrase importante.

Le problème là dedans c'est de savoir à partir de quand on peut parler d'optimisation et quand doit on parler d'exigence non fonctionnelle.
Pour faire Paris-Lyon, tu peux commencer par faire Paris-Rome, suivi de Rome-Lyon.
Mais lorsque tu te rendras compte qu'il vaudrait mieux faire Paris-Lyon directement en ligne droite, je ne suis pas sûr qu'on puisse appeler ça de l'optimisation !

L'optimisation fine est quelque chose de couteux dont on peut parfois s'interroger sur son utilité.
Mais a force de se dire : "Les perfs on s'en fout, du moment que ça marche c'est bon, on verra ensuite si on peut optimiser", on en arrive vite à écrire absurdité sur absurdité. On pose un bout de code n'importe comment, puis on le secoue dans tous les sens jusqu'à ce qu'il tombe en marche. Et une fois que ça marche... surtout ne plus y toucher, si on casse quelque chose, on ne sait pas si on saura le remettre en marche.

Pourtant les performances c'est avant tout un problème de conception.
Ca commence par choisir le bon algorithme et la bonne architecture pour résoudre le problème. Quand on y fait attention dès le départ, ça ne coûte pas grand chose et les gains sont bien plus important que ce qu'on pourra faire a posteriori.
Lorsque la première version de l'appli sera écrite, que les utilisateurs refuseront de l'utiliser à cause de ses mauvaises perfs, les seules optimisations que tu pourras réellement faire se limiteront à de la cosmétique. Tu ne pourras plus te permettre de changer l'architecture, tu ne pourras pas remettre en cause les choix de conceptions qui brident les perfs...

Si changer d'écran prend 10 secondes, le budget viendra très vite.

A condition qu'on te fasse encore confiance, que le projet ne soit pas abandonné parce que la consommation de ressources de l'appli est incompatible avec le modèle économique et que tu ne prennes pas la porte pour qu'on donne le job à quelqu'un qui sait écrire du code qui marche de façon efficace.

[el_slapper]

@Franck : c'est bien pour ça que je précise "Dans certains cas, on peut penser 2-3 petits trucs à l'avance". Il ne s'agit pas d'écrire n'importe quoi non plus. Simplement, entre (attention COBOL, ça fait mal aux yeux des moins de 30 ans) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
IF A=B
   PERFORM T1
ELSE
   IF A=C
      PERFORM T2
   ELSE
      IF A=D
         PERFORM T3
      ELSE
         PERFORM T4.

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
EVALUATE TRUE
   WHEN A=B   PERFORM T1
   WHEN A=C   PERFORM T2
   WHEN A=D   PERFORM T3
   WHEN OTHER PERFORM T4
END-EVALUATE
.

Certains m'ont maintenu que la première version était un chouilla plus rapide, en tous cas sur les vieux compilateurs obsolètes depuis 20 ans. Moi je les envoie chier, même si il s'avère qu'ils ont raison. La deuxième version est tellement plus lisible et compréhensible. Après, evidemment, il ne faut pas tomber dans l'excès inverse, et refaire tout un traitement quand on a besoin que d'une seule donnée sur les 18 calculées de manière linéaire mais indépendante, juste parceque ça évite de rajouter un bloc spécifique à la donnée demandée.

Et, dans ma vie professionelle, j'ai bien plus vu d'optimisations peu utiles que de non-optimisations à régler au plus vite(j'en ai vu, mais pas beaucoup).

[Nebulix]

Pour faire Paris-Lyon, tu peux commencer par faire Paris-Rome, suivi de Rome-Lyon.

Mais avec beaucoup de compagnies aériennes il est moins cher de prendre un aller retour qu'un aller simple...
Elles ont sûrement des programmes bien optimisés

[1337cclean]

Bah c'est une question amusante...

A-t-on vraiment besoin d'avoir été à l'école pour bien programmer ?

1/ L'école de quoi ? (Où en est l'enseignement à ce sujet?)

2/ Que signifie l'idée abstraite [bien programmer] ? (Interprétation complètement subjective...)

J'ai juste lu en diagonale quelques réponses.

Je me permets juste de faire quelques remarques générales:

La notion de qualité de programmation (rarement pertinente en entreprise) est absolument indépendante des choix de langages. Les choix de langages doivent se faire en amont d'un développement. Bienqu'il est évident que très rarement les entreprises tiennent comptent sérieusement d'aspects techniques pour le choix de la plateforme, de l'OS et finalement du ou des langages.

J'espère simplement que pour la programmation lié au contrôle de processus, au coeur d'une centrale nucléaire soit sérieusement adaptée. réflexion identique en matière de programmation embarquée, pour l'aviation, le contrôle de réseaux ferroviaires, etc.

Certaines écoles sont de très bon accélérateurs d'études et de compréhension de méthodologies de programmation, conception de structure de données, exploitation raisonnablement "rationnelle" de la machine cible, /etc.

Mais quelques-fois des autodidactes sont remarquables.
Ont les Happellent souvent des hackers (à ne pas confondre avec les pirates ) [...]



PS: L'essentiel (comme en mathématiques) c'est de se faire vraiment plaisir.
- Sinon il y a tout simplement un gros problème de choix de vie -

[camus3]

En général suivre des cours donne de bonnes bases en modélisation et en analyse. C'est ça le plus important , pas connaitre tel ou tel langage.
On peut très bien connaitre SQL et pas être foutu de monter un MCD.
Si l'on apprend sur le tard , il est important de focaliser une grosse partie de son apprentissage les théories et méthodes de modélisation.
Je parle pour l'informatique de gestion en tout cas.
Bref la réponse a la question est non si on a pris le temps d'apprendre soit même les techniques de modélisation. Surtout qu'aujourd'hui des cours sont dispo partout sur le net.

[arthuro45]

Mais quelques-fois des autodidactes sont remarquables.

+1

PS: L'essentiel (comme en mathématiques) c'est de se faire vraiment plaisir.

+15

Bonne soirée

[gene69]

Il y a 10 sortes d'informaticiens.

• Ceux qui seront moyens grâce à l'école et qui représente 80% des étudiants que j'ai rencontré sur le campus.
• Ceux qui sont géniaux sans l'école et qui y sont quand même parce qu'ils apprennent des choses quand même à l'école.

L'école n'a pas comme seul but d'apporter une somme de connaissance. Il permet aussi à l'informaticien d'être civilisé et de savoir programmer (puisque c'est le thème) de façon un minimum ordonnée, d'apprendre à travailler en groupe, ce que ne permet pas l'autodidaxie. Et aussi de savoir qu'un projet ne s'évalue pas en nombre de ligne mais en litres de bières.

Il est vrai que 90% des connaissances d'un informaticien, école ou pas, proviennent de ses propres recherches sur internet. Apres tout, l'informatique est la seule science qui a organisé un système de renouvelement des élites et de formation via ses propres canaux. Chaque informaticien a écrit un jour son petit site avec ses observations et ses découvertes, rien que parce qu'il est plus simple d'avoir un bloc note sur internet, ça permet de conserver l'info à un endroit connu.

Avant pour devenir un bon médecin, il fallait lire des livres puis découper des cadavres puis faire des stages.

Pour faire de l'informatique, il suffit de savoir lire et d'avoir une connexion internet. Du coup pour apprendre l'informatique, il suffit de rester devant un ordinateur. Il n'y a pas de plus court chemin entre la pratique et la théorie qu'en informatique.

[TropMDR]

Pour faire de l'informatique, il suffit de savoir lire et d'avoir une connexion internet. Du coup pour apprendre l'informatique, il suffit de rester devant un ordinateur. Il n'y a pas de plus court chemin entre la pratique et la théorie qu'en informatique.

Il y a un truc que je ne comprends pas bien. Sachant qu'en France, une immense majorité des gens sait lire, et que la couverture ADSL du territoire est plutôt bonne, comment arrive-t-on à récupérer des sites de voyages ferroviaires (dont nous ne citeront pas le nom) aussi pourris ? Pourquoi y a-t-il autant de logiciel qui plantent dès qu'on clique sur trois boutons un peu trop rapidement ? Pourquoi continue-t-on à voir des logiciels pourtant codé dans des langages prétendument ultra rapide et pourtant ultra lent, avec une consommation mémoire monstrueuse ?

Croire que sous prétexte que l'information est disponible, alors elle est accessible est un doux rêve !

Et résumer l'informatique à la programmation, et la programmation à "il suffit d'avoir un ordinateur", c'est un peu comme dire "tout le monde peut être écrivain, il suffit de savoir lire et écrire"...

[spax]

On peut bien sur apprendre a programmer sans école d'ailleurs cela s'applique a tout autre domaine il faut juste de la motivation.

Après faut savoir qu'a l'école ou l'université on apprend d'autres choses en parallèle que du code, que ca soit de la gestion , de la communication , de l'architecture, le travail en groupe ... ce qui donne une vision un peu plus large et avec recule sur les problèmes qu'un autodidacte n'a pas forcement sans expériences professionnelles.

Maintenant faut aussi regarder l'avenir professionnel : tu sais développer ? Oui , tu as un diplôme (ing ou univ) ? NON => galère pour trouver le travail , sous payer (a compétences égales ou même supérieurs avec un diplômé) et évolution +ou - impossible (sinon ca prend une éternité).

[TropMDR]

On peut bien sur apprendre a programmer sans école d'ailleurs cela s'applique a tout autre domaine il faut juste de la motivation.

C'est sûr, hier encore, je me disais que si j'y avais mis un peu plus de motivation, j'aurais pu être chirurgien du cerveau ! Je n'avais qu'à acheter les bon bouquins, et wikipedia aurait fait le reste.

Un truc qui m'a toujours fasciné avec l'informatique : c'est un des rares domaine que je connaisse où tant de gens pensent que sous prétexte que l'on peut faire un peu, il suffit de persévérer pour faire beaucoup.

Plein de gens sont capable de changer un joint de culasse, personne n'en déduit qu'avec un peu de persévérance, n'importe qui peut devenir mécano auto-didacte pour rafale ou formule 1.

Toute personne ayant passé la seconde a déjà vu la loi de la gravitation. Peu en déduisent qu'en bossant le soir en rentrant du taff, ils arriveront à fusionner la mécanique quantique et la physique relativiste en une théorie unifiée.

La plupart des gens savent que pour se débarrasser du tartre, une bonne lampé d'acide chlorhydrique (ou à défaut, de vinaigre) fait l'affaire, pourtant ils ne se disent pas qu'ils vont inventer le prochain polymère révolutionnaire.

N'importe qui peut comprendre l'énoncé de la conjecture de Syracuse, pourtant peu s'attaquent à la démonstration de l'hypothèse de Riemann pour autant.

Mais l'informatique a ce statut à part, cette espèce de situation de sous science, d'activité secondaire. Sous prétexte que n'importe qui peut lire PC-expert ou faire un site web pourri en PHP, l'informatique devient un domaine "accessible pour peu que l'on persévère et qu'on lise des tutos sur internet".
Je ne comprends pas.

Si c'est si simple, où sont les OS sans faille de sécurité, les navigateurs qui ne crashent jamais ? Pourquoi ne sait-on toujours pas si P est égal ou non à NP ? Pourquoi n'y a-t-il pas 42 google-like ?

Je n'arrive toujours pas à comprendre pourquoi l'informatique a cette image si pauvre.

[maske]

Je n'arrive toujours pas à comprendre pourquoi l'informatique a cette image si pauvre.

Parce que t'as pas compris : l'informatique c'est faire des tableaux sous excel et programmer des ordinateurs pour afficher des "hello world". C'est pas un vrai métier.

C'est un domaine trop récent et trop associé "au jeu (vidéo)" pour être pleinement reconnu par la masse. Quand on voit des documentalistes de lycée crier au scandale et se battre dès qu'on parle d'un éventuel enseignement de l'informatique, parce que on va leur voler leur travail : oui, c'est leur rôle d'enseigner la bureautique aux élèves ! :/

Pourquoi ne sait-on toujours pas si P est égal ou non à NP ?

Cf. la remarque sur les documentalistes au dessus : les gens croient que ça se limite à windows et outlook. Forcément va leur parler de complexité ! Dis leurs en plus que si tu résouds ce problème, tu gagnes un million de dollars, et tu passes pour un con.

[blaiso]

Bonjour,

Tout dépend du genre de développement et des utilisations.

si vous développez pour un usage personnel, vous pouvez apprendre seul et vous en sortir. Pour être professionnel, vous pouvez bien vous tirer avec du VBA.

Mais si vous devez gagner votre vie comme développeur, honnêtement, je pense qu'il faut aller à l'école.

D'abord pour le recrutement, on vous demandera vos références dans le domaine. Ensuite parce qu'à ce moment là, ce n'est pas simplement du code qu'on vous demandera. Vous serez dans une équipe, où on pourra vous confier une des étapes d'un développement de logiciel (analyse, conception, implémentation).

Mais au-delà de tout, il faut être un passionné pour bien développer... comme dans tout ce que l'on veut bien faire dans la vie.

[william44290]

Mon in-culture au sujet des outils de modélisation est un élément qui me laisse à penser qu'une formation scolaire aurait été la bienvenue.
Travaillant seul, cela ne me gène pas. Mais la transmission, la gestion des développements réalisés, manquent furieusement de support. Je ne suis pas mauvais dans ce que je fais mais je serais sûrement meilleurs si mon cursus avait été différent.