IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Le langage Haskell est-il suffisamment populaire ?

  1. #21
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    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.

  2. #22
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : juin 2005
    Messages : 8 575
    Points : 11 801
    Points
    11 801
    Par défaut
    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]

  3. #23
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 698
    Points
    9 698
    Par défaut
    Citation Envoyé par amaury pouly Voir le message
    Avec les languages fonctionnels, je trouve que c'est plutôt le cas. Un argument que j'entend souvent est qu'il inutile de donner le type des arguments, des variables car il est inféré. Mais personne n'est dupe, les types existe en grande partie pour les développeur. Le fait qu'ils soient écrit, de facon redondante dans de nombreux language contribue à la lisibilité, on voit le type au premier coup d'oeil. Je pense que c'est un fait à ne pas négliger car dans un gros projet, on doit relire le code de quelqu'un d'autre très souvent et on a pas envie de passer des heures à fait tourner le code mentalement juste pour inférer les types parce que le code n'est pas documenter.
    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...

  4. #24
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 322
    Points : 18 478
    Points
    18 478
    Par défaut
    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)
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  5. #25
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    prenez les langages de la famille Lisp & Scheme, ils sont à la programmation fonctionnelle ce que Ruby est à C++
    J'ai pas bien saisi le rapprochement… ?
    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.

  6. #26
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 698
    Points
    9 698
    Par défaut
    Ce point là me paraît très important :
    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).
    Les 2 seules questions qui intéressent le client sont :

    1. combien ça va coûter ?
    2. 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...

  7. #27
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 322
    Points : 18 478
    Points
    18 478
    Par défaut
    Citation Envoyé par Florian Goo Voir le message
    J'ai pas bien saisi le rapprochement… ?

    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  8. #28
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 677
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 972
    Points
    30 972
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    (.../...) 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... (.../...)
    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.

  9. #29
    Membre éclairé
    Avatar de Florian Goo
    Profil pro
    Inscrit en
    septembre 2008
    Messages
    680
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2008
    Messages : 680
    Points : 858
    Points
    858
    Par défaut
    @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.

  10. #30
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : juin 2005
    Messages : 8 575
    Points : 11 801
    Points
    11 801
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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.
    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...

  11. #31
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : février 2003
    Messages : 433
    Points : 1 538
    Points
    1 538
    Par défaut
    Citation Envoyé par Alp Voir le message
    Dans la boîte d'info moyenne oui.
    Ce sont ces boites qui représentent la très grande majorité des besoins.

  12. #32
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 698
    Points
    9 698
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    @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.
    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...

    Citation Envoyé par el_slapper Voir le message
    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.
    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)

    Citation Envoyé par Alp Voir le message
    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 puisse 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...
    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...)

    Citation Envoyé par Florian Goo Voir le message
    @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 ? »…
    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...

  13. #33
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 677
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 972
    Points
    30 972
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    (.../...)
    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)
    (.../...)

    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.

    « Pourquoi le Java et consort sont-ils si populaires en industrie ? »…
    ...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 .
    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.

  14. #34
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 698
    Points
    9 698
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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.
    C'est pas faux...

    La "solution magique pas chère" résume bien ce qui a été dit auparavant.

    Citation Envoyé par el_slapper Voir le message
    ...je fais essentiellement du COBOL... ou , au choix.
    Je compatis...
    "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...

  15. #35
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 677
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 677
    Points : 30 972
    Points
    30 972
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Citation Envoyé par moi-même
    ...je fais essentiellement du COBOL...
    Je compatis...
    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.

  16. #36
    Membre averti
    Profil pro
    Inscrit en
    mars 2006
    Messages
    319
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : Belgique

    Informations forums :
    Inscription : mars 2006
    Messages : 319
    Points : 351
    Points
    351
    Par défaut
    Citation Envoyé par Alp Voir le message
    Haskell n'a été fait ni par des mathématiciens, ni pour des mathématiciens. Il a été créé par des chercheurs en informatique, tout comme la plupart des langages qui existent.
    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.

    Citation Envoyé par Alp Voir le message
    Ensuite, les langages fonctionnels ne sont pas moins lisibles.
    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.


    Citation Envoyé par Alp Voir le message
    [...]le cerveau de 99.99999% des gens ici est formaté à l'OO ou au procédural. Et à des types de syntaxe très proches. Là ça change, et du coup faut se réadapter, c'est vrai que c'est beaucoup demander à un grand nombre d'entre vous. Pour les types, tu ne sais pas vraiment combien c'est important avant de programmer avec OCaml ou Haskell, leurs systèmes de type sont bien plus complet que les bêtes systèmes de type d'OO de Java, C# et compagnie.
    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...

    Citation Envoyé par Alp Voir le message
    [...]De toute manière ça servirait à rien de trop développer le sujet ici bien que j'aurais beaucoup à dire, parce que 99.9999% d'entre vous sont trop fermés pour ne serait-ce qu'être réceptifs à une explication détaillée des avantages et défauts ***REELS*** d'Haskell, et non pas les bêtises balancées ici par 2 ou 3 clampins qui n'y connaissent rien.
    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é...

    Citation Envoyé par Alp Voir le message
    [...]Il faut être motivé. C'est la curiosité intellectuelle, la passion pour les langages de programmation, qui doit te motiver.
    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 !

  17. #37
    zul
    zul est déconnecté
    Membre éclairé Avatar de zul
    Profil pro
    Inscrit en
    juin 2002
    Messages
    498
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2002
    Messages : 498
    Points : 668
    Points
    668
    Par défaut
    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.
    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)

    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

  18. #38
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : février 2003
    Messages : 433
    Points : 1 538
    Points
    1 538
    Par défaut
    Citation Envoyé par zul Voir le message
    Si l'OO était une approche si efficace, pourquoi 90% des projets informatiques continuent d'échouer ?
    Parce qu'en général, les raisons des échecs sont à des années lumières de la technique

  19. #39
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : juin 2005
    Messages : 8 575
    Points : 11 801
    Points
    11 801
    Par défaut
    Citation Envoyé par zaventem Voir le message
    Parce qu'en général, les raisons des échecs sont à des années lumières de la technique
    Non, justement ils parlent de l'échec des logiciels, sur l'aspect technique, si je ne m'abuse. On trouve des logiciels bourrés de bugs partout... (j'parle pas d'un p'tit bug bien planqué qui était indétectable pendant les tests, mais bien de pleiiins de bugs à la con)

  20. #40
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : juin 2005
    Messages : 8 575
    Points : 11 801
    Points
    11 801
    Par défaut
    Citation Envoyé par Oscar Hiboux Voir le message
    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.
    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...

    Citation Envoyé par Oscar Hiboux Voir le message
    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.
    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.

    Citation Envoyé par Oscar Hiboux Voir le message
    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...
    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.

    Citation Envoyé par Oscar Hiboux Voir le message
    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.
    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à.

    Citation Envoyé par Oscar Hiboux Voir le message
    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 !
    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.

Discussions similaires

  1. Réponses: 31
    Dernier message: 21/02/2018, 19h15
  2. Le langage Haskell est-il suffisamment populaire ?
    Par Idelways dans le forum Haskell
    Réponses: 8
    Dernier message: 09/08/2010, 18h07
  3. JSp est il encore populaire?
    Par berceker united dans le forum Servlets/JSP
    Réponses: 7
    Dernier message: 02/10/2006, 14h28
  4. Réponses: 12
    Dernier message: 10/08/2006, 10h44
  5. [langage] "@$" Quel est ce type de variable?
    Par YanK dans le forum Langage
    Réponses: 4
    Dernier message: 21/04/2005, 19h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo