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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'utilisation d'un langage de programmation approprié permettrait une réduction considérable des dépenses
Un développeur recommande Haskell

Le , par Stéphane le calme

54PARTAGES

6  2 
Aaron Contorer, ancien employé Microsoft et fondateur de la compagnie FPComplete, une plateforme de développement Haskell, se fait promoteur de ce langage de programmation fonctionnel. Dans un petit exposé, il explique les avantages qu'offre Haskell aux entreprises.

« Des milliards de dollars sont gaspillés à cause de l'excès de défaillance des projets, corrections de bugs et maintenances cauchemardesques » explique Contorer qui rappelle que de nombreuses études ont démontré que les maintenances et corrections de bugs consomment à elles seules 50 à 75 % des projets informatiques. Pour lui, l'une des raisons de ces problèmes est l'utilisation de langages traditionnels à l'instar de Java, C/C++/C# , Python, ou encore Ruby pour ne citer que ceux-là. Il estime que l'approche est très sujette aux erreurs et génère du « code spaghetti qui dévore les coûts finaux. ».

Il explique que ce problème est relativement méconnu et perpétué parce que la grande majorité des programmeurs ne connaissent pas d'alternative viable et se contentent d'arrondir les angles de plusieurs façons : utilisation de meilleurs outils, développement Agile etc. Il précise que ce ne sont pas des solutions mais des contournements du problème.

Pourquoi Haskell serait une alternative viable ? Parce que son approche est fondamentalement différente des langages dominants d'aujourd'hui. Les programmes Haskell sont une série de fonctions généralisables de haut niveau qui définissent ce que le programme est censé faire. Le programmeur se concentre sur l'objectif, les meilleures conceptions et logiques pour apporter un résultat spécifique souhaité. Le compilateur produit du code propre, concis et correct. Contorer a d'ailleurs cité les nombreux avantages techniques de l'utilisation d'Haskell :

  • une réduction des lignes de code de 50 à 80 % ;
  • une réduction considérable des erreurs ;
  • une réduction considérable de la découverte et de la correction d'erreurs au moment de la compilation ;
  • maintenance du code facilitée et modification sans introduction d'erreurs ;
  • plus sécurisé car moins de failles exploitables.


Selon lui, tous ces avantages techniques auront pour conséquence d'accélérer le temps de mise sur le marché de 30 à 50 %, de réduire les coûts d'au moins 25 %, d'accroître la productivité du programmeur d'au moins 30 % mais surtout d'améliorer la qualité du produit.

« Ruby et Python sont populaires parce qu'ils permettent un prototypage rapide, surtout dans le développement d'applications web. Toutefois, ils sèment les graines de futurs problèmes dans les performances, la fiabilité, l'évolutivité et la dépendance qui rend la maintenance cauchemardesque. » affirme-t-il. D'ailleurs, selon lui, il est amplement prouvé que Haskell peut les résoudre.

A titre d'exemple pour illustrer ses dires, il cite Janrain qui, après avoir connu des taux élevés d'échec avec Ruby, a commencé à utiliser Haskell et a pu réduire de 75 % le temps qu'il consacrait à des corrections de bugs. D'ailleurs le NYT a déclaré utiliser Haskell pour présenter sa semaine de la mode qui est une application avec des quantités massives d'images et d'analyses.

Le rédacteur en chef Andrew Binstock de Dr. Dobb a tweeté récemment « J'ai remarqué plusieurs fois quand quelqu'un dit, "X a vraiment changé ma façon de penser sur la programmation," fréquemment X = Haskell. » Karthikeyan Mani, co-fondateur de Byteally en Inde a dit « C'est la façon naturelle de programmer. C'est la première fois que je suis en paix quand je code. Avec Ruby, c'est toujours des maux de tête et des énervements. Nous nous éloignons de la programmation traditionnelle ».

Source : Mozilla Open News, étude FPCompete, cas Janrain (au format PDF), blog FPCompete

Et vous ?

Avez-vous déjà utilisé Haskell ? Qu'en pensez-vous ?

Partagez-vous le point de vue de Aaron Contorer ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de
https://www.developpez.com
Le 14/10/2013 à 20:23
Les langages de programmations sont des outils créés pour répondre à des besoins. Chacun a ses qualités et ses défauts, et certains sont mieux conçus que d'autres.
Les programmeurs ont des outils de prédilection, des préférences. Mais aucun outil n'est LA solution universelle. Aucun outil n'est adapté à TOUS les problèmes.
Ce n'est pas parce qu'un homme (ou une équipe) a découvert un langage adapté à ses besoins et qu'il apprécie en tant que programmeur que ça en fait une solution universelle ! On peut trouver aux quatre coins du net des personnes qui te diront la même chose en remplaçant "Haskell" par "Python", par "Erlang", par "Go", par MetIciCeQuiTeFaitPlaisir…
19  0 
Avatar de phili_b
Expert éminent https://www.developpez.com
Le 14/10/2013 à 20:30
Mouais article complétement illogique.

Ça commence bien en parlant de langage approprié, c'est-à-dire un langage pour un problème donné, et ça part tout de suite en vrille en préconisant un langage qui peut faire le café et répondre à n'importe quel problématique.

Ce langage que je ne connais pas, le Haskell, est sans doute super génial mais c'est impossible qu'il puisse répondre aux besoins de bas niveau, comme aux besoin de haut niveau, comme à l'informatique de gestion qui se trouve entre les deux.

En fait le présenter comme un concurrent à la fois de java, C++, et Python est aussi risible car chacun a un domaine d'utilisation différent.
13  0 
Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 14/10/2013 à 21:02
Il faut donc utiliser un langage appropié selon le besoin, mais utiliser Haskell ! Ah bon, celui-ci répondrait donc à tous les besoins possibles ?

Ou bien "un développeur" qui parle est développeur Haskell et prêche pour sa paroisse parce qu'il n'y a pas beaucoup de boulot sur ce langage ?
8  1 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 14/10/2013 à 21:20
Pour avoir un peu joué avec, je pense qu'Haskell est un langage très intéressant d'un point de vue académique ; et c'est vrai qu'en général on a moins de surprises (et donc moins de bugs) qu'avec des langages plus traditionnels, c'est une des conséquences de l'approche fonctionnelle.

Par contre je suis un peu sceptique sur la possibilité de développer de "vraies" applications avec ce langage. Haskell est un langage fonctionnel pur, c'est à dire qu'il ne permet pas les effets de bord (du moins pas directement). Or, toute application concrète nécessite forcément des effets de bord : afficher un texte à l'écran est un effet de bord ! Evidemment, il est possible de le faire en Haskell, indirectement, via les monades ; mais comprendre le concept des monades, c'est tout sauf intuitif. Ca m'a pris très longtemps rien que pour comprendre à peu près en quoi ça consistait.

Bref, l'approche fonctionnelle a beaucoup de qualités, mais à mon avis un langage fonctionnel un peu plus pragmatique qu'Haskell (comprendre : pas purement fonctionnel) serait sans doute plus approprié pour faire de vraies applications concrètes. D'autant plus que la syntaxe de Haskell est relativement imbitable au début, avec plein d'opérateurs bizarres dont la signification n'est pas évidente du tout car ils représentent généralement à des fonctions d'ordre supérieur (higher-order functions, c'est à dire des fonctions qui manipulent des fonctions)

Cela étant dit, ce n'est pas une raison pour ne pas apprendre Haskell ; je l'ai fait il y a 2 ans par curiosité, et c'est vrai que ça ouvre l'esprit sur une façon très différente de programmer (surtout pour quelqu'un qui vient des langages procéduraux et orientés objet). Pour ceux que ça intéresse, je recommande vivement ce tutoriel : Learn You a Haskell for Great Good

Pour donner un avant-goût des possibilités, voilà à quoi peut ressembler un quicksort en Haskell :

Code Haskell : Sélectionner tout
1
2
3
4
5
6
quicksort :: Ord a => [a] -> [a] 
quicksort []     = [] 
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) 
    where 
        lesser  = filter (< p) xs 
        greater = filter (>= p) xs

Difficile de faire plus concis... l'implémentation correspond de très près à la description de l'algorithme.

(évidemment cette implémentation est un peu simpliste ; elle n'est pas "in-place", et utilise toujours le 1er élément comme pivot, ce qui n'est pas idéal)

Bref, pour conclure, c'est un langage super, mais je me vois mal développer des applis complètes avec ça... Ce qui peut être intéressant, par contre, c'est d'utiliser Haskell pour les parties métier où il y a des algorithmes complexes, et autre chose pour la partie UI.
6  0 
Avatar de spyserver
Membre confirmé https://www.developpez.com
Le 14/10/2013 à 21:12
Tiens c'est marrant ça me rappel le débat que j'ai eu avec un collègue pro-Haskell (et autre langage fonctionnel), ce que l'article oublie de dire c'est que la syntaxe du code Haskell est inbouffable et pas très user friendly, les puristes vont me dire qu'on s'en fou, un langage ça reste un langage blablabla mais bon voila, le fait est la, ça explique pourquoi il nécessite bien moins de ligne justement, et c'est pas le 1er langage à faire ça ! Mais comme tjrs les puristes de ces langages sont certes dans le vrai pour le niveau de performance de ces langages qui reste imbattable mais pour tous le reste, il faudra revoir la copie, comment ces langages s'embarquent ou s'imbriquent dans des architectures existantes, proposent-ils des frameworks adaptés à tous les contraintes "rééls" des projets actuels ? (drivers Oracle ou NoSQL proposés ? etc. etc.). Je pense pas que le Graal existe ds les langages de programmation, ils sont juste chacun bons dans un domaine mais ne peuvent l'être dans tous. Point.
6  1 
Avatar de azias
Membre éclairé https://www.developpez.com
Le 15/10/2013 à 1:06
J'y vois surtout un patron qui fait la promotion des technologies vendues par sa boîte, rien de plus logique.

J'ai jamais vraiment entendu parler d'haskell, en France il me semble que l'équivalent le plus utilisé est Caml (dont la syntaxe me paraît quand même un peu plus lisible qu'Haskell, mais c'est peut-être une question d'habitude).

C'est certain que le typage fort réduit par définition tous les problèmes liés au typage dès la compilation. Ajouté à ça l'absence de pointeurs, pas d'effet de bords... et on vient effectivement de régler une grande proportion des bugs qu'on trouve dans les programmes C.

La programmation fonctionnelle permet effectivement de programmer plus rapidement... mais pas forcément les mêmes choses. Dans un autre style de programmation, Prolog permet aussi de programmer plein de choses beaucoup plus rapidement et sans bugs, mais pas les mêmes choses non plus.

Quoi qu'il en soit, aucun langage ne protégera jamais des erreurs fonctionnelles, qui incombent au développeur, et encore quand les bugs ne sont pas déjà présents dès les spécifications!

Pour moi un code maintenable est d'abord un code bien commenté et documenté, quel que soit le langage. Et si possible développé par un développeur maison, pas par un prestataire de service qui a tout intérêt à ce qu'on lui demande de retravailler le code, ou une "ressource" envoyée par une SSII qui n'en à rien à faire puisqu'il sera ailleurs dans 3 semaines... Bref, on devrait superposer les graphiques de l'évolution du nombre de bugs et de la recrudescence des SSII et je pense qu'on aura trouvé la source d'une bonne partie des problèmes.

Par expérience, il me semble que le mauvais code provient surtout de l'impératif de rapidité de codage à laquelle nous sommes souvent soumis, tout est à faire pour la veille, alors pas le temps pour documenter le code, pas le temps de faire les test unitaires... alors quand j'entend que tel langage, tel EDI ou telle nouvelle techno est censée accélérer le temps de développement ça ne me rassure pas.

Il existe effectivement des méthodes (méthodes formelles) qui permettent de réduire considérablement (ou même de supprimer) les bugs ainsi que les erreurs fonctionnelles, mais qui imposent un travail supplémentaire en amont, ce qui peut finalement rallonger le temps de développement global.

On ne peut pas avoir le beurre et l'argent du beurre, mais c'est de bonne guerre qu'un discours commercial comme celui-ci essaie de nous le faire croire.
4  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 15/10/2013 à 9:26
Tous ces opérateurs cabalistiques, moi, je lâche. J'avais lâché le CAML pour la même raison. Si un jour je me mets au fonctionnel, alors ça sera du LISP : y'a des parenthèses partout, mais au moins il n'y a pas de [<%µ*$£¨+ pour passer l'aspirateur. Celà étant dit, j'approuve la plupart des messages ci-dessus : un bon langage est un langage adapté. Et ça ne peut pas toujours être Haskell(ou quoi que ce soit d'autre)
4  0 
Avatar de Carhiboux
Expert éminent sénior https://www.developpez.com
Le 15/10/2013 à 9:45
Bon, ce monsieur vends son produit, c'est très bien.

Par contre, entre tout son blabla, il cite quand même des chiffres intéressant.

Une bonne partie du budget informatique part en correction de bugs.

Là dessus on est d'accord.

Mais je suis prêt à parier un petit billet que si les entreprises qui étaient confrontés à ce problème se contentaient juste de changer le langage de programmation, le problème seraient exactement le même.

Ce que ma (petite) expérience m'a permis de remarquer, c'est que les entreprises ne savent pas s'impliquer dans les phases de conception.

Que ce soit l'entreprise qui réalise, ou l'entreprise qui à émis le besoin.

Le plupart du temps, quand on projet se termine mal, c'est du au fait que la phase de conception à été bâclée. Pour diverses raisons :

  • Parce que le client ne s'impliquait pas, disait oui à tout et à eu ce qu'il a validé, ce qui n'était évidement pas ce qu'il voulait...
  • Parce que du point de vue de la direction du réalisateur, la phase de conception est dure à vendre, souvent faite en avant-vente, donc c'est souvent grossier et incomplet
  • Parce que parfois, les architectes parlent bien... mais une fois devant leur feuille blanche, ya plus personne...
  • Parce que le client à entendu parler de Cloud++FX32 et qu'il veut absolument l'avoir dans son projet alors que ça n'a aucun sens de le faire. Mais c'est le client donc on le mets...


A mon sens, le problème des surcouts de la maintenance et de la correction des bugs vient tout simplement d'une défaut de conception et d'anticipation. Mais bon, les architectes expérimentés coutent chers, les devs juniors pas cher. Donc...
4  0 
Avatar de Sirus64
Membre éclairé https://www.developpez.com
Le 15/10/2013 à 14:31
Avez-vous déjà utilisé Haskell ? Qu'en pensez-vous ?
Non jamais utilisé, mais j'ai déjà utilisé du fonctionnel pour faire de l'informatique graphique : les performances sont là, ce type de language est adapté à ce qui se traduit facilement en équation, n'est pas facile à apprendre pour des gens qui ont une approche moins fonctionnelle / mathématique des problèmes. Sur ce dernier point, on élimine beaucoup de développeurs, surtout ceux qui n'ont pas fait d'algorithmique.

Partagez-vous le point de vue de Aaron Contorer ?
Ce qui est dérangeant dans l'article c'est, comme dit plus haut, que le but semblait de dire qu'il y a un ou plusieurs langages adaptés à chaque classe de problèmes. Et à la fin, on parle d'utiliser exclusivement Haskell (WTF ?!).

Que le langage soit meilleur ou pas, l'important est qu'il soit adopté, et il sera adopté seulement s'il y a des développeurs pour l'utiliser. Or les langages fonctionnelles sont toujours boudés par les développeurs. Même F# (copie d'OCaml) ne décole pas alors qu'il est supporté par MS. On peut voir un début d'ouverture avec JavaScript et les quelques bibliothèques qui poussent les mécanismes du fonctionnels. Peut-être est-ce la solution pour modifier la facon de voir des développeurs ?
4  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 15/10/2013 à 17:07
Au départ quand j'ai lu

L'utilisation d'un langage de programmation approprié permettrait une réduction considérable des dépenses
Puis ensuite "Haskell". Là je me suis dit, ok effectivement les dépenses diminuent parce qu'on économise déjà la licence de l'obfuscator qui n'est plus nécessaire. .

Non sérieusement ce qui m'effraie avec un tel langage, même si la puissance est évidente c'est la possibilité de relire le code des autres dans une équipe de niveau inégal, surtout quand derrière "autres" j'entends aussi bien le geek talentueux que le jeune stagiaire.

J'ai pu me frotter à scala, d'inspiration fonctionnelle, et ma hantise c'est la relecture parce qu'on peut vraiment finir avec du ascii art compilable. Ces one-liners, myriades d'opérateurs que même le compilateur a du mal à comprendre (enfin vu la lenteur du compilateur scala on ose imaginer que le langage est complexe à comprendre, tout comme son type system) Ou alors on peut vraiment se former le cerveau à force d'expérience pour que ça coule autant de source que de lire du java...
J'aimerai parfois essayer sur un vrai projet, mais c'est risqué. Traroth dit que les gens se bornent à ce qu'ils connaissent, pas forcément aux meilleures solutions. Vrai que parfois lorsque les délais sont short on préfère utiliser des technos dont on connaît d'avance les pièges, pas se lancer sur un champ de mine sans avoir de carte.
4  0