Discussion :

[Philippe Vialatte]

Bah quoi...

C'est pas trivial, la transformation de Fourier ?


...je croyais

[kdmbella]

ah si tu ne comprends pas le second degré je ne peux rien faire pour toi !

et maintenant tu parle de compréhension au second dégré! mon interpellation c'est pour te faire comprendre que pour faire une transformation de Fourier ça demande un certain temps d'apprentissage et surtout beaucoup de connaissances antérieurs alors même si on a tous fait maths Sup et écol d'Ing et autre il faut une certain temps au delà de quelque heure pour comprendre et pouvoir appliqué correctement les concepts

[ALT]

Euh... Justement, c'est ça, le second degré !

[Mat.M]

et maintenant tu parle de compréhension au second dégré! mon interpellation c'est pour te faire comprendre que pour faire une transformation de Fourier ça demande un certain temps d'apprentissage et surtout beaucoup de connaissances antérieurs alors même si on a tous fait maths Sup et écol d'Ing et autre il faut une certain temps au delà de quelque heure pour comprendre et pouvoir appliqué correctement les concepts

ok je suis d'accord avec toi relax c'était de l'humour

[Philippe Vialatte]

...te faire comprendre que pour faire une transformation de Fourier ça demande un certain temps d'apprentissage et surtout beaucoup de connaissances antérieurs alors même si on a tous fait maths Sup et écol d'Ing et autre il faut une certain temps au delà de quelque heure pour comprendre et pouvoir appliqué correctement les concepts

.Replace("faire une transformation de Fourier", "développer corretement")

[Gouyon]

- Programmer : c'est une philosophie, que pratiquent habituellement les cuisiniers, les ébénistes, les chefs d'entreprises. C'est organiser ses idées en fonction des moyens et des domaines. C'est imaginer,ordonner, et prévoir. Cela s'apprend-il ?

Oui ça s'apprend à l'école et surtout par l'expérience.

- Informatique : savoir expliquer à une machine particulièrement débile comment faire les choses les plus élémentaires.

Pour moi c'est la meilleure définition qu'on puisse faire de l'informatique.

- Langue, et non langage, de programmation : il est certain que la maîtrise "parfaite" d'une langue nécessite une longue expérience. On peut se débrouiller avec quelques mots pour les besoins de base, mais la performance complète pour une bonne transmission des idées demandera de nombreuses années, dont on ne disposera pas car entre temps la mode passera à une nouvelle langue si le hasard des embauches ne vous y a pas forcé avant.

Ah la mode Mais c'est vrai un nouveau langage (ou langue ) apparait tout les ans et évidement il faut absolument développer avec ça. C'est le chef qui l'a dit

[BenoitM]

C'est le chef qui l'a dit :

Heuresement que le manager qui est là pour dire qu'on a commencé il y a 20 ans avec Cobol et qu'il y a pas besoin de changer de langage

[el_slapper]

C'est le chef qui l'a dit :

Heuresement que le manager qui est là pour dire qu'on a commencé il y a 20 ans avec Cobol et qu'il y a pas besoin de changer de langage

Pour certains cas précis(en gros, du traitement de fichier en masse), le cobol est toujours le plus adapté. En dehors de celà, je suis d'accord : dès qu'on le sort de sa niche, il devient tout à fait inadapté. C'est le souci de tous les langages spécialisés.

Quel est votre métier? (si il y a la moindre interface utilisateur dedans, je compatis).

[BenoitM]

J'ai pris au hasard Cobol, dans mon cas c'est souvent du VB6 que je dois me farcir et où les responsables ne voit pas l'utilité de changer de technologie...

Je suis trop jeune pour le cobol

[el_slapper]

Après, il faut regarder les couts de migration. Le nouveau langage papote-t-il bien avec l'ancien? Se convertit-il? J'ai vu du Cobol converti java, mais c'est plus du jobol qu'autre chose(buerk). Et il parait que convertir VB6 ==> VB.NET , c'est un casse-tête abominable(j'ai pas essayé).

Pour un projet nouveau, le risque est moindre, sauf si il faut utiliser des composants existants. Dans ce cadre, passer de VB.NET à C# ne pose pas trop de problèmes. Dans d'autres cas......

[Franck SORIANO]

J'ai pris au hasard Cobol, dans mon cas c'est souvent du VB6 que je dois me farcir et où les responsables ne voit pas l'utilité de changer de technologie...

Cela dit, c'est bien souvent vrai...
Les développeurs ont tendance à croire que parce qu'une techno est nouvelle et quelle est à la mode, elle est forcément meilleure.

Mais dans la pratique pour une entreprise, changer de techno ne changera pas le fonctionnel des applis pour autant. Donc ça ne rapporte pas forcément grand chose. Ca fait plaisir aux jeunes développeurs qui veulent être à la mode, et ça mécontente les anciens qui doivent tout réapprendre et qui vont probablement régresser en compétences...

[BenoitM]

Mais ca permet aussi aux developpeurs de penser à leurs avenir.
Perso je pense que j'ai plus de chance de trouver un boulot si je dis que je connait WPF , WCF, Linq que si je dis que je suis toujours en VB6 parce que l'entreprise ne voit pas l'intérêt de changer

Mais je comprend qu'une entreprise ne voit pas le bénéfice de changer un programme d'une technologie à l'autre

Part contre je me demande à quel age on devient un vieux developpeur qui ne veut pas changer de technologie

[GPPro]

Mais ca permet aussi aux developpeurs de penser à leurs avenir.
Perso je pense que j'ai plus de chance de trouver un boulot si je dis que je connait WPF , WCF, Linq que si je dis que je suis toujours en VB6 parce que l'entreprise ne voit pas l'intérêt de changer

Mais je comprend qu'une entreprise ne voit pas le bénéfice de changer un programme d'une technologie à l'autre

Part contre je me demande à quel age on devient un vieux developpeur qui ne veut pas changer de technologie

Quand on est devenu REELLEMENT compétent avec une techno ? Un prérequis étant la capacité à reconnaître la compétence ...

[Gouyon]

Mais dans la pratique pour une entreprise, changer de techno ne changera pas le fonctionnel des applis pour autant. Donc ça ne rapporte pas forcément grand chose. Ca fait plaisir aux jeunes développeurs qui veulent être à la mode, et ça mécontente les anciens qui doivent tout réapprendre et qui vont probablement régresser en compétences...

Ça c'est bien vrai #%$!§* de jeunes

[Gouyon]

Part contre je me demande à quel age on devient un vieux developpeur qui ne veut pas changer de technologie

Après un ou deux ans de boite pourquoi???

[Franck SORIANO]

Mais ca permet aussi aux developpeurs de penser à leurs avenir.

Je suis bien d'accord . Mais l'intérêt du développeur (son employabilité) n'est pas forcément le même que celui de l'employeur (la productivité).

Perso je pense que j'ai plus de chance de trouver un boulot si je dis que je connait WPF , WCF, Linq que si je dis que je suis toujours en VB6 parce que l'entreprise ne voit pas l'intérêt de changer

Pas forcément. Les technos à la mode changent tellement vite... Les entreprises ne peuvent pas suivre. Donc ça veut bien dire qu'il y en a un certain nombre qui recherchent autre chose.
J'aurai même tendance à dire que c'est la majorité. Le problème, c'est que cet autre chose, ce n'est pas forcément la compétence du développeur qui cherche du travail pour autant. Car même si l'entreprise met du temps avant de ce décider à changer de techno, elle fini bien par le faire un jour ou l'autre...

[ALT]

J'aurais tendance à penser qu'une entreprise ne cherche pas nécessairement (en priorité) un spécialiste de tel ou tel langage ou méthode de développement, mais quelqu'un qui soit capable de s'adapter, d'évoluer. Et il faut reconnaître que c'est souvent là que le bât blesse...
Quel candidat va le plus intéresser le recruteur : un spécialiste du C# qui n'a pratiqué que ça depuis qu'il a commencé à apprendre la programmation ou quelqu'un qui aurait fait du CoBOL, du ForTran, du Lisp, du Modula, le tout sur VMS & MVS & DOS (bon, d'accord, je lui en mets une couche, là, dans le style antiquités ) ? L'un ne sait (peut-être très bien) faire qu'une chose, certes moderne, mais sera peut-être sclérosé. L'autre, pour des raisons historiques personnelles ne sera pas à la pointe du progrès, à l'évidence, mais aura su évoluer au long de sa carrière.
La réponse n'est naturellement pas unique, puisqu'elle dépend des besoins du recruteur. Et du candidat !

Mais de toute façon, ça nous éloigne un poil du sujet initial, non ?

[BenoitM]

Vu que le premier ne connait pas la POO , je prendrai surement le 2ème

Puis bon tout dépend de ce que tu veux faire avec le candidat.

Tu n'as pas forcé le temps et l'envie de le former pendant 6 mois avant qu'il ne puisse rejoindre une équipe.

Part contre celui qui a fait du Cobol, ... à surement plus d'expérience que celui qui n'a fait que du c# quoique maintenant même le c# commence à devenir "vieux"

[NBBIZOU]

Je programme depuis 1975
Diplôme AFPA d' analyste programmeur en 1985.
COBOL..
GAP ( RPG ) d' IBM
BASIC ( Basica, Bal, GWBasic )
C
C++
C#
Pascal ( Delphi, Lazarus ) mes chéris
PHP
JAVA
Assembleur X86
Et le reste....
Cela évolue tout le temps...
Alors courage, la première langue à apprendre c'est la plus difficile, le reste n' est qu'une question de syntaxe, les FOR, WHILE c'est toujours pareil.
Le Problème c'est le langage objet, Là il y a vraiment des différences, mais le principe est le même, seuls les "mots" changent et on met les déclarations ailleurs.
Apprendre en 3 mois ou quelque jours quelle bêtise!
Les "vieux" savent des choses que les nouveaux programmeurs ignorent, la connaissance de l' assembleur est déterminant!

[ALT]

Encore une fois, que met-on sous le mot "apprendre" ?
Les bases ?
Sans doute.
Avoir une connaissance approfondie du langage ?
Sûrement pas !

Alors on peut apprendre à écrire un programme en quelques heures. C'est bien l'objet affiché des ouvrages. Je ne crois pas qu'ils prétendent qu'on puisse connaître toutes les ficelles du métier en si peu de temps.

De même qu'on peut apprendre à souder en quelques heures aussi. De là à savoir réaliser rapidement une belle soudure... Et il est encore moins question d'avoir le savoir-faire d'un vieux soudeur, qui peut traiter n'importe quel alliage, vite & très bien.

Tout le reste n'est que littérature.