C'est rigolo, l'opposition JackosKing/la plupart des autres participants me rappelle l'opposition chercheur/ingénieur.

Je suis persuadé que pas mal de chercheurs ne feraient pas de bons ingénieurs, et vice-versa. Pourquoi ?
Parce que le but n'est pas le même.

Le chercheur travaille sur de la formalisation, où le but est d'être le plus rigoureux et précis possible.
L'ingénieur travaille sur de la pratique, où le but est qu'à la fin, le truc marche.

Mon boulot est dans la deuxième catégorie, donc je connais surtout des exemples qui font qu'un truc peut marcher sur le papier et pas "en vrai" :
- ça nécessite des ressources (mémoire, puissance de calcul...) trop importantes
- ça nécessite une connaissance ou un contrôle précis de l'environnement, alors que c'est impossible en pratique
- ce n'est pas suffisamment robuste face aux variations extérieures
- etc.

Des personnes qui écrivent des papiers comme ça, j'en ai vues (à commencer par certains enseignants-chercheurs d'école d'ingénieurs, qui n'ont pas dû mettre les mains dans le cambouis depuis longtemps). À l'inverse, je connais aussi des gens qui sont très bons en pratique, mais qui se retrouvent bloqués lorsque les problèmes nécessitent de sortir la théorie (traitement de signal, etc.).

Ça doit sûrement être intéressant pour un programmeur en entreprise de connaître les design patterns, ne serait-ce que pour savoir ce qui a déjà été fait et éviter de réinventer laborieusement la roue. Ce n'est pas une raison non plus pour vouloir y adhérer de façon rigide.

C'est d'ailleurs assez étonnant comme débat. Je pense que la majorité des gens ici connaissent les algos et structures de données classiques (Quicksort, arbres...). Je ne pense pas qu'on dise que c'est un avantage de ne pas les connaître. Mais si ça ne correspond pas bien au problème que vous avez à résoudre, vous n'allez pas vouloir les utiliser à tout prix, non ?