Il y a aussi le livre Real World Haskell, dont l'introduction donne vraiment envie de s'y mettre : http://book.realworldhaskell.org/read/
L'intégralité du livre est accessible gratuitement sur internet et également édité chez O'Reilly.
Il y a aussi le livre Real World Haskell, dont l'introduction donne vraiment envie de s'y mettre : http://book.realworldhaskell.org/read/
L'intégralité du livre est accessible gratuitement sur internet et également édité chez O'Reilly.
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Il y a aussi http://www.learnyouahaskell.com/ qui va moins loin mais est plus "ludique".
Au fait, pour ceux que ça intéresse, Tim Sweeney parle de Haskell ici : [ame="http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney"]The Next Mainstream Programming Language: A Game Developer's Perspective by Tim Sweeney[/ame]
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Sauf que l'intérêt principal de l'inférence de type, ce n'est pas juste de réduire la taille du code ou le nombre de frappes au clavier...
Non.
L'un des intérêts que je vois dans l'inférence de type, c'est la vérification de la cohérence des types tout au long du programme. Pour faire simple, si le compilateur n'arrive pas à inférer un type (ou si le type inféré n'est pas le type attendu), c'est qu'il y a un problème quelque part (pour caricaturer, c'est comme si on voulait faire rentrer le rond dans le carré).
Un autre intérêt de l'inférence de type est la possibilité de spécialiser une fonction à partir d'une fonction plus générale. Un peu à la manière des templates du C++ ou des generics de Java/C#... mais en plus élégant. C'est d'ailleurs dans ce cadre qu'on peut spécifier les types des paramètres explicitement.
Bref (et sans vouloir être méchant envers toi), quand on déclare que l'inférence de type sert principalement à réduire la taille du code, c'est qu'on a une vision très réduite de la programmation fonctionnelle.
Et malheureusement, ce sont souvent les gens qui n'y connaissent rien et n'ont strictement aucune ouverture d'esprit qui font le plus de commentaires du genre: "ouais, la programmation fonctionnelle, c'est nul !" (c'est une constatation générale, ne le prend pas à titre personnel)
Comme l'a très bien dit Alp, la programmation fonctionnelle (pas seulement en Haskel) c'est une manière différente de penser et si on veut bien comprendre... ben il n'y a pas de secret, c'est comme tout : il faut passer du temps dessus.
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
pour infos, l'inférence de types n'a rien d'obligatoire dans la programmation fonctionnelle... prenez les langages de la famille Lisp & Scheme, ils sont à la programmation fonctionnelle ce que Ruby est à C++. par exemple apply détruit tous les systèmes d'inférences classiques (un peu de lecture en anglais pour les curieux)
J'ai pas bien saisi le rapprochement… ?prenez les langages de la famille Lisp & Scheme, ils sont à la programmation fonctionnelle ce que Ruby est à C++
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Ce point là me paraît très important :
Les 2 seules questions qui intéressent le client sont :Correctness. Most companies don’t give a **** about correctness. They don’t care about quality. They just want to shovel code out the door as fast as possible and earn wads of cash. If there are bugs, they’ll charge the customer money to fix them. Getting code right is of no interest; getting code fast is what counts. Haskell is a language that rewards those who sit back and deeply analyse the problem, and then produce a beautiful solution. Most companies don’t care for this approach; let’s just hack something together as fast as possible, and worry about fixing it later (i.e., never).
- combien ça va coûter ?
- quand est-ce qu'on est livré ?
Le reste, il s'en fout.
En effet, essayez donc de dire à votre client : "je peux vous faire votre projet, mais ça prendra un peu plus de temps et coûtera donc un peu plus cher. En contrepartie, le programme sera mieux écrit et plus correct", comme ça, juste pour rigoler. Il y a de fortes chances que votre client confie le projet à un concurrent...
Le client ne voit quasiment jamais à long terme. Il choisit l'offre la moins chère, et quand les problèmes arrivent, il paye des correctifs.
Le client ne sait pas définir ses besoins, il veut "un truc qui marche" mais il ne sait pas dire comment. Et puis il change tout le temps d'avis, donc ça sert à rien de faire un truc bien pensé dès le départ.
Le client se fout de la flexibilité. Si le produit ne peut pas s'adapter au besoin, et bien on facturera une fonctionnalité supplémentaire.
Sachant tout cela, autant faire un truc "vite fait, mal fait" et pas cher. Une fois qu'il est coincé avec votre architecture bancale, vous pouvez le saigner avec des correctifs et des mises à jour.
Le "vite fait, mal fait" fait vivre pas mal de monde :
- le consultant qui arrive tel le chevalier blanc en criant fièrement: "pour améliorer la qualité logiciel, on n'a qu'à faire plus des tests" (et par "on", il veut dire "VOUS"). Les tests, c'est bien, mais ça ne fait pas tout. De plus, cela implique de détecter les erreurs à l'exécution... c'est-à-dire un peu tard. Ne serait-il pas mieux de réfléchir à un moyen de détecter plus d'erreurs à la compilation ? Surtout pas ! Réfléchir, c'est perdre du temps sur l'implémentation, t'arriveras pas à atteindre les objectifs du sprint...
- le ScrumMaster, qui fixe les objectifs à atteindre pour la fin du sprint. Ce qui compte, c'est ce que ça marche (même mal) à la fin du sprint. Le reste on verra après. Pas le temps de réfléchir, code !
- le responsable Software Quality Assurance qui vous dit comment bien coder... avec de mauvais langages. Il explique aussi comment faire de la documentation, des procédures, des contrôles... On vous explique même "la programmation pour les nuls", c'est à dire comment coder pour que même un gros nul ait une chance de vous comprendre (au détriment de tout le reste bien sûr: qualité de code, performances, etc.). Parce que des nuls, il y en a beaucoup... et même des fois ce sont ceux qui vous expliquent comment gérer votre projet...
On dirait que toutes les méthodes liées à la gestion de projet convergent vers le même objectif : produire du code en masse, ainsi que toute la documentation, les tests et les procédures qui vont avec. C'est à croire que tout ce beau monde est payé au poids !
C'en est à un point où lors d'un entretien d'embauche, on entend parfois la question: "et quelle est le plus gros projet sur lequel vous ayez travaillé en terme de nombre de lignes de code ?". Autant dire que je n'ai pas donné suite.
Je suis désolé, mais le "nombre de lignes de code" n'a jamais été une unité pour mesurer ni la complexité d'un programme, ni l'état d'avancement d'un projet, et surtout pas la qualité logicielle ! Le "nombre de lignes de code" ne sert à mesurer qu'une chose : le facteur "ce programme est une vraie usine à gaz".
Cependant le "nombre de lignes de code" est une unité mesurable, alors que la "qualité logicielle" peut difficilement être mesurée. Or pour récompenser les gens, on a besoin de quantités mesurables, comme la production de code, de tests, de documentation, de procédures... L'ère du Stakhanovisme logiciel est en marche !
Maintenant, émettons une hypothèse : "et si le développement logiciel était exactement l'inverse de ce qui a été dit précédemment ?", c'est-à-dire :
- prendre le temps de réfléchir au problème plutôt que produire bêtement du code (produire mieux plutôt que produire plus)
- fournir le même nombre de fonctionnalités avec un code avec un code réduit (small is beautiful !)
- factoriser : rendre chaque fonction aussi générale que possible, plutôt que d'écrire des fonctions hyper-spécialisées
- détecter un maximum d'erreurs avant qu'elles ne puissent se produire (à la compilation plutôt que dans les tests)
Quand on voit sur quels critères se base toute l'industrie informatique, on réalise que ceci n'est qu'une douce utopie.
Dans ces conditions, un langage qui ne ressemble à aucun autre, qui oblige à s'arrêter pour réfléchir et qui freine l'obtention d'une promotion parce qu'on ne produit pas assez de code/documentation/procédure... n'a effectivement aucune chance de percer dans l'industrie.
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
ben le dynamisme du typage dans une certaine mesure... contrairement à un code C++ non truffé de if (dynamic_cast<T>(o) != 0)
@pcaboche: tu rêves je crois... Le problème est encore plus profond que cela, tu n'as fait que décrire ses conséquences. Le monde de l'industrie n'est en fait géré que par des financiers/responsables marketing vaseux/commerciaux payés au % du CA et non au bénéfice dégagé au final sur un projet. A partir de là, la quantité de faible qualité prendra le pas sur la qualité, car elle génère beaucoup d'argent "après le projet initial". Il n'y a qu'à voir, dans tout ce qui est grand public, le nombre d'ingénieurs payés pour s'assurer de l'usure d'un produit après (2 x durée de garantie) pour comprendre que le prêt-à-jeter a de beaux jours devant lui... et d'autant plus dans l'informatique où un bogue aberrant n'est pas considéré comme un vice caché du produit
Outre l'excellente réponse de gorgonite, j'aimerais revenir sur ce point : dans le monde du travail, on ne code pas pour soi. On code pour une organisation qui a besoin d'un code. Et il y a des gens qui passeront derrière. et parfois même des non-informaticiens assumés(même pas des gens qui croient savoir, non, j'ai eu des codes repris par des gens ouvertement non-programmeurs). Et ce, d'autant plus que les besoins en termes de développement sont trop importants pour être couverts par les doués seuls.
Et là, les critères de qualité changent. J'ai appris à faire un code plus simple, moins élégant, avec des finesses seulement sur les parties fondamentales, celles qui ne changent pas, mais qui sont appelées par des système basiques, compréhensibles par une huitre. J'ai appris à créer une couche initiale qui se lit exactement comme la spec, au cas ou la spec change et qu'il faille réagir brutalement(mon record, 9 versions de specs sur un seul samedi. Faut dire, ils avaient pas eu le temps de fignoler, et ils corrigeaient au fur et à mesure de mes executions). J'ai aussi appris à faire ceinture et bretelle, au cas ou un gnou appelle mes services de traviole, que le service reste stable, et réponde quand même au mieux.
Emmerdant? Certes. Moche? Souvent. Mais très utile, surtout quand on se retrouve avec le feu aux fesses dans la situation du gnou..... C'est pourquoi j'ai posé mes questions précédentes. Mon expérience, c'est qu'un langage reservé aux doués n'a pas d'avenir. La vraie vie, c'est la maintenance, les urgences et les modifications à chaud.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
@pcaboche (et gorgonite + el_slapper)
Excellent exposé…
En plus de répondre à la question « Pourquoi le Haskell ne peut pas percer ? », elle en fait de même pour « Pourquoi le Java et consort sont-ils si populaires en industrie ? »…
Heureusement qu'on compte quelques exceptions qui confirment la règle. Surtout hors de France, d'après ce que j'ai entendu dire…
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Dans la boîte d'info moyenne oui. Après, en te défonçant à fond, il y a de fortes chances pour que tu puisses accéder à un emploi bien plus sympa où on te demandera plus de qualité... Tout dépend de ce que les gens veulent, car je connais pas mal de gens qui se contentent d'un poste tel que décrit dans les messages précédents...
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Oui je sais, je suis un doux rêveur... sinon j'aurais pas fait informaticien. J'aurais vendu des assurances, par exemple.
Et oui, je ne fais que décrire les conséquences, parce que les conséquences sont bien visibles et plus faciles à saisir. Mais même ainsi, le constat est déjà bien lourd...
J'ai bien conscience de tout cela. Je faisais juste une constatation.
Je n'ai pas la prétention de vouloir changer les choses (autant se battre contre des moulins à vent), mais je trouve qu'on tend vers de plus en plus de médiocrité.
Le plus gênant, c'est que si le client veut du code médiocre mais lisible, qu'il l'écrive noir sur blanc dans ses specs (quand il y en a ). Si au contraire il veut de la qualité, pareil -> dans les specs. S'il veut à la fois qualité, lisibilité et performance, rapidité de développement, ce n'est pas toujours conciliable -> qu'il fixe des priorités dans les specs ! (sachant que les specs font partie du contrat entre le donneur d'ordre et l'exécutant)
Et oui, parfois on se contente d'un poste médiocre pour payer le loyer. Mais généralement cette situation ne peut pas durer éternellement et on finit soit par craquer, soit par aller voir ailleurs... (et souvent l'un, puis l'autre...)
Merci !
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
Le plus gênant, c'est que le client ne sait pas ce qu'il veut. Il veut une solution magique et pas chère qui lui règle tous ses soucis d'un claquement de doigts, et nos exigences de techos(machines, délais, charges, tests, spécifications, questions précises) ne font rien qu'à l'embêter.
...je fais essentiellement du COBOL... ou , au choix. En même temps, quand je vois les niveaux d'emmnuis auxquels font face les javaïstes et autres Businessobjectistes, je ne me plains pas .« Pourquoi le Java et consort sont-ils si populaires en industrie ? »…
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
en fait, c'est pas forcément pire que d'autres. Quand je vois les gens qui bossent sur les nouvelles technos, qui mettent 4 heures à ouvrir leur projet(authentique), ou qui sont obligés de se battre pendant deux heures pour monter leur évolution d'un environnement(la durée officielle est de 90 minutes, souvent dépassée), là ou moi il me faut respectivement 5 et 45 secondes, je deviens soudain plus indulgent vis-à-vis des faiblesses inhérentes à un aussi vieux langage(faiblesses bien réelles pourtant)..... Mais j'ai quand même du mal avec les codes spaghetti d'il y a trente ans.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
La plupart des informaticiens dignes de ce nom ayant étudié en informatique et l'informatique, notamment la programmation, étant une discipline impliquant largement les mathématiques on en est quand même assez proche... D'autant plus que Haskell, comme d'autres langages marginaux, fait encore pas mal figure de jouet de laboratoire.
Pourtant la pratique le démontre souvent. Prends par exemple un script ECMA écrit par un programmeur moyen, transforme le avec ton esprit si brillant et mets-y quelques fonctions anonymes, fermetures & compagnie. Quand le reste de l'équipe jetteront un œil à ton travail ils seront très probablement atteint d'irritation oculaire aigüe... Eh ouais, leur cerveau n'est pas prêt à assimiler ton génie.
Rassure toi, on n'est pas tous allergiques à l'effort. Et si c'est comme ça que tu tentes de séduire la communauté tu risques d'y laisser quelques dents...
Tu m'as vraiment mis en haleine là !
Effectivement, les concepts manipulés dans les langages fonctionnels s'avèrent assez abstraits et difficiles à maîtriser, donc mettre en œuvre. La douce logique procédurale et l'OO sont bien plus accessibles au commun des mortels, n'en déplaise à l'élite, et par ce fait même sont choyés par l'industrie.
Bref, et passons sur la pureté...
Voilà, c'est là où le bât blesse. Ça le classe presque immédiatement, et sans doute malheureusement, dans une catégorie proche des loisirs.
Quant à la réalité, elle est plutôt bien décrite ensuite à partir de pcaboche. C'en est même comique !
Tu peux prouver ça (que l'OO est plus "accessible") ? Si l'OO était une approche si efficace, pourquoi 90% des projets informatiques continuent d'échouer ? L'OO n'est il pas intuitif parce que la seule façon de penser enseignée dans les écoles d'informatique ? Connais-tu et applique-tu le principe de Liskov ? (question piège)Effectivement, les concepts manipulés dans les langages fonctionnels s'avèrent assez abstraits et difficiles à maîtriser, donc mettre en œuvre. La douce logique procédurale et l'OO sont bien plus accessibles au commun des mortels, n'en déplaise à l'élite, et par ce fait même sont choyés par l'industrie.
Qu'est qui te parait si abstrait dans les concepts manipulés en fonctionnel ? Les fonctions ?
Si la curiosité intellectuelle te fait passer dans la section loisir, personnellement je n'aimerai pas travailler avec toi
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Le problème c'est qu'aujourd'hui les gens de l'info, en majorité, veulent s'éloigner des maths, ne comprenant pas que l'info est très proche des maths. Donc c'est pas prêt d'arriver...
Oui mais comme je le disais je pense que c'est juste une question de conditionnement de l'esprit. Je connais pleins de gens qui ont commencé la programmation avec OCaml, Lisp, Haskell, Erlang et autres, et ils galèrent pour comprendre du code C++, Java, C#, tout ça tandis que du code dans un langage fonctionnel qu'ils ne connaissent pas hé bien ça va. Je pense que le conditionnement de l'esprit joue beaucoup.
Ce qui est bien avec la communauté Haskell, justement, c'est que les gens ne sont pas là à vouloir à tout prix séduire tout le monde. S'y intéresse qui veut et voilà. Je suis pas contre conscient que ça limite pas mal niveau marketing mais ce n'est pas plus mal finalement.
Bof... Encore une fois je pense au conditionnement. Certains Design Patterns sont "chiants" à comprendre quand tu débutes en OO, parce qu'ils sont immergés dans ce monde OO auquel il faut s'habituer. Je pense qu'il y a juste des choses similaires mais dans le monde fonctionnel, qu'il faut prendre le temps de se familiariser avec, et voilà.
D'accord pour les posts à partir de celui de pcaboche.
Pas d'accord pour le reste. Personnellement, je préfère bosser avec un langage que j'aime. Et pour l'instant j'ai toujours réussi à m'en sortir à ce niveau là. Enfin, j'trouve ça naturel de s'intéresser à des choses dans l'info, et, si on accroche, à vouloir les utiliser dans notre boulot quotidien.
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
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.
Partager