Discussion :

[Mickael Baron]

L'équipe Java vous propose un débat sur la pertinence d'utiliser le langage fonctionnel Scala depuis que la nouvelle version de Java supporte désormais la programmation fonctionnelle. En effet si l'on regarde le forum dédié à Scala sur Developpez.com, on remarque que ce dernier ne contient que très peu de discussions. De même, avec la concurrence féroce du langage JavaScript et de Node.JS pour le développement web, les langages basés sur la JVM y compris Scala, sont en perte de vitesse.

Nous souhaiterions que vous profitiez de cette discussion pour donner votre point de vue quant à votre utilisation de Scala.

Utilisez-vous seul Scala ou conjointement avec le langage Java permettant selon les circonstances de tirer réellement parti des avantages respectifs des deux langages.

Merci d'avance

Mickael pour l'équipe Java

[Philippe Bastiani]

Bonjour Mickael... effectivement il n'y a pas beaucoup d'activité sur ce forum !

A y regarder de plus prêt le forum Groovy n'est pas plus actif ! Et, pourtant ce langage est plus populaire...

IMHO, en France il y a peu d'opportunités de job en rapport avec ces langages...

Le fonctionnel à la Java8 est-il si adopté après bientôt 2ans ?

Le gros fein de Scala (du moins dans l'industrie) ce n'ai pas Java mais Scala lui même avec ses incompatibilités de version en version...

a+
Philippe

Si on regarde des indicateurs comme TIOBE (ils valent ce qu'ils valent...) finalement Scala et Groovy ne semblent pas vraiment impactés par Java8 !
A part un sursaut, lors de la levée de fond en 2011, sur TIOBE Scala n'a jamais dépassé la 25ième places !
Sur Redmonk
Janvier 2014 Scala = 13 / Groovy = 20
Juin 2015 Scala 14 / Groovy 19

[MichaelREMY]

mon point de vue de chercheur d'emploi de longue durée :

ça fait longtemps que je vois et lis des annonces d'emploi pour du Java mais ce n'est jamais dans la dernière version (7), il ya tjrs qq versions en dessous...

Je me dis qu'il faudra 5ans pour que les entreprises décident de mettre à jour (énorme coût je suppose) leur architecture autour de java.

Par contre je vois passer régulièrement des annonces qui demandent du Scala en compétence.

Ma déduction: les ayant-besoins préfèreront maintenir leur archi plutôt que de l'évoluer et engendrer des gros changements (et des gros coûts).
En plus maintenant avec la virtualisation, maintenir une archi d'une techno rare est largement possible à long terme à moindre coût.

Ce qui pèsera peut-être (et surement), ce sera si qq découvre une faille de sécurité grave (ou un gros bug) liée à Scala, là les DSi penseront peut-être autrement.

[Adraor]

Bonjour à tous,

Je réagis à cette discussion pour donner mon avis sur la question, et je vais vous expliquer pourquoi, selon moi, la question posée n'a pas de sens.
Tout d'abord un fait :
Java (peu importe la version) ne supporte pas la programmation fonctionnelle... le fait de pouvoir faire des lambdas n'est pas tout, (le fonctionnel est un paradigme à part entière! )
Je n'ai aucunement la prétention de donner un cours mais même si je n'ai pas une expérience très significative en programmation fonctionnelle,
je sais que les 3 principes fondamentaux sont:

-L'immutabilité: on ne réaffecte pas de valeur à une 'variable' qui est ducoup une constante
Les langages fonctionnels encouragent la déclaration d'objets et collections immuables pour un code plus safe.

-Le pattern matching : à ne surtout pas confondre avec les switch cases, le pattern matching permet de conditionner sur la structure des objets, collections, leurs types etc...

-La récursivité : ça existe en Java mais c'est pas très conseillé a cause de StackOverFlow (tout le monde la connais celle là) ,
En Scala (entre autre) on a la notion de tail-récursivité c'est une optimisation qui va permettre de pouvoir TOUT coder de maniérè récursive sans dépasser les limites du Stack.

Surtout corrigez moi si je me trompe mais je pense que JAVA (8) n'en implémente aucun...

-L'immutabilité n'est absolument pas au cœur des préoccupations des développeurs Java, certains mécanisme du langage encouragent même l'utilisation des effets de bords.
-Le pattern matching : nop
-Et pas de tail récursivité en Java

Mis à part ces principes généraux, d'autres bien plus subtils font toute la richesse du paradigme fonctionnel, je pense en premiers aux types implicites, au monades, aux fonctions d'ordre supérieur... et bien d'autre.
Sans même parler des collections en Scala qui proposent énormément de fonctionnalités.
Il n'y a cependant qu'un seul moyen de vraiment comprendre l'interêt de faire du Scala : faire du Scala, vous comprendrez par la même occasion l’intérêt de ne plus faire de Java.
Bref Java n'est absolument pas un langage fonctionnel, et il ne le sera probablement jamais ; Scala , en revanche est un langage multi-paradigme super sympa qui souffre malheureusement des défauts de la JVM.

[sjrd]

Je suis assez d'accord avec l'opinion d'Adraor. Avoir des lambdas n'est pas la clef de la programmation fonctionnelle. C'est bien sûr un des points nécessaires d'un langage visant à être fonctionnel, mais en aucun cas il n'est suffisant.

Au-delà de tout, c'est l'immuabilité qui conditionne le paradigme fonctionnel. Bien qu'il soit possible de programmer de manière immuable en Java, il faut littéralement se battre contre le langage pour y parvenir. Des final à tous les coins de rue, éviter les collections natives de java.util, à moins de tout wrapper avec des Collections.unmodifiableXYZ(). Ce n'est tout simplement pas une vie.

Scala, comme les autres langages fonctionnels, encourage au contraire l'immuabilité. Et c'est ça qui fait toute la différence !

Quant aux autres fonctionnalités du langage telles que le pattern matching ou les tail recursive calls, ce sont bien sûr des plus, mais ils sont loin derrière l'immuabilité comme caractéristiques d'un paradigme fonctionnel. Par exemple, les LISP n'ont pas de pattern matching dans le langage, et sont pourtant unanimement reconnus comme fonctionnels. Inversement, C a depuis longtemps des tail recursive calls, mais je ne pense pas que quiconque avancerait que C est un langage fonctionnel.

Pour la même raison, JavaScript ne deviendra pas fonctionnel de si tôt. Et pourtant JS avait des fonctions anonymes/lambdas depuis le début.

[Traroth2]

Scala , en revanche est un langage multi-paradigme super sympa qui souffre malheureusement des défauts de la JVM.

J'avais poucé ton commentaire, jusqu'à cette phrase. De quels défauts de la JVM parle-tu ?

Le rôle de la JVM n'est pas de favoriser la programmation fonctionnelle. Si on devait la faire évoluer, ça serait vers toujours plus d'agnosticisme par rapport aux langages de programmation.

[Philippe Bastiani]

Enfin celà s'anime par ici

Surtout corrigez moi si je me trompe mais je pense que JAVA (8) n'en implémente aucun...

La récursion terminale et le pattern matching ne sont pas des spécificités qui font d'un langage un langage fonctionnel... par contre la notion de fonction et d'immuabilité oui...

Je me demande pourquoi, les optimisations sur la tail resursion n'ont pu être implémentées dans Java...
Le pattern matching tout comme l'immuabilité... tu peux très bien l'obtenir avec Java8 ! Mais comme le dit Sébastien c'est au prix d'efforts ! Mais bon, on peut les avoir
Pour les monades en + (ou plustôt qui manquent on ne sait pas pourquoi...) et autres extensions : il faut suivre, entre autres, les projets https://github.com/aol/cyclops et http://javaslang.com

Pour le reste Scala est-il fonctionnel ? Java est-il fonctionel ? c'est une question de curseur... certains diront que Scala ne peut être dans cette catégorie du fait qu'il accepte l'impurété ! Java doit-il être fonctionnel ? impossible (voire pas souhaitable... autant proposer un Haskell sur la JVM) par contre le curseur peut encore être déplacé... tout en gardant l'essence même de Java !

a+
Philippe

[JavaBean]

Merci pour ces précisions. Vous qui semblez maîtriser le sujet, auriez-vous de bons tutoriels/cours/livres à conseiller?

[Adraor]

Merci pour ces précisions. Vous qui semblez maîtriser le sujet, auriez-vous de bons tutoriels/cours/livres à conseiller?

http://shop.oreilly.com/product/0636920026914.do ce livre à l'air pas mal dutout pour apprendre scala, il parle tout aussi bien de l'orienté objet que du fonctionnel, et les livres oreilly sont super bien écrit!
il y a cependant, d'autres langages fonctionnels :
F#(une implémentation de oCaml sur le framework .NET) , oCaml/Caml, Haskell, Lisp... Je ne saurais te dire avec certitude lequel est le mieux pour commencer, probablement pas Haskell (qui ce veux très 'puriste'), j'ai commencé avec Scala je le vis bien .

[JavaBean]

Je vais donc me plonger dans le tutoriel officiel.

C'était une mauvaise idée, le truc est mal expliqué et plein de coquilles... Je suis passé au tuto de Twitter qui est bien mieux.
On verra plus tard pour le «cookbook», pour l'instant je voudrais comprendre les concepts.

[_skip]

Bonjour,
J'ai déjà suffisamment trollé (de façon un peu constructive j'espère) par le passé sur Scala et les raisons pour lesquelles je pense que ce n'est pas une solution idéale pour du développement en équipe malgré mon grand souhait d'utiliser un "meilleur java" (temps de compilation abominable, auteurs de librairies tierces incapables de se contrôler, abus des DSL induits par les largesses syntaxiques etc...) En gros pour résumer ce langage serait parfait pour moi si j'avais besoin de ne lire que mon propre code.

Je sais que c'est un débat de longue haleine de savoir si c'est le langage qui doit poser les limites ou le développeur, c'est arrivé sur les alias de type en C++, sur la redéfinition d'opérateur et sur plein de choses. Et à chacun son avis.

Une fois, l'auteur de Scala avait donné son point de vue sur la question en interview, admis que la grande extensibilité de scala pouvait parfois le déservir et évoqué l'idée d'un Scala 3 qui pourrait revenir à un juste milieu, je me demande si c'est toujours à l'ordre du jour.

[sjrd]

_skip, si tu cherches un "meilleur Java" qui soit plus rigide que Scala, avec moins de fonctionnalités, je te suggère de jeter un oeil à Kotlin. C'est littéralement leur but. À noter particulièrement, leur comparaison avec Scala.

Les perspectives pour "Scala 3", plus connu sous le nom de "dotty", sont plutôt de simplifier les fondements du langage. Mais il devrait rester (pratiquement) aussi flexible que Scala 2.

[_skip]

_skip, si tu cherches un "meilleur Java" qui soit plus rigide que Scala, avec moins de fonctionnalités, je te suggère de jeter un oeil à Kotlin. C'est littéralement leur but. À noter particulièrement, leur comparaison avec Scala..

Merci, je suis déjà ce projet depuis de nombreuses années, tout comme Ceylon. Le truc c'est que dans ma situation c'est un plus difficile pour moi de le "vendre" à mon équipe, déjà parce qu'il est jeune et pas encore en version 1.0. Alors que côté Scala, c'est production-ready depuis un certain temps, en plus je nous ai fait utiliser play2 pour une application d'interface administrateur et là c'était l'occasion rêvée pour introduire ce nouveau langage.
Souvent je me dis que le meilleur ambassadeur d'un langage outre son élégance et ses qualités brutes, c'est un framework de grande qualité qui donne l'impulsion en milieu pro.

Les perspectives pour "Scala 3", plus connu sous le nom de "dotty", sont plutôt de simplifier les fondements du langage. Mais il devrait rester (pratiquement) aussi flexible que Scala 2

Ah oui, ben j'étais mal renseigné j'espérais qu'ils en auraient profiter pour limiter certaines des choses qui peuvent rendre scala pratique pour certains usages (DSL) mais rapidement obfuscants. N'importe quoi qui permettrait de limiter le risque que des gens pondent des codes qui s'écrivent mais qui ne se lisent pas.

[Philippe Bastiani]

Merci pour ces précisions. Vous qui semblez maîtriser le sujet, auriez-vous de bons tutoriels/cours/livres à conseiller?

Pour les livres

Un livre en français pour bien débuter
http://www.editions-ellipses.fr/prod...oducts_id=9877

Sinon le bouquin de Odersky c.f ma critique

Mais
Scala in action
ou
Scala for the Impatient
me semblent plus adapté pour débuter...

Bonne lecture...
Philippe

[Adraor]

De quels défauts de la JVM parle-tu ?

Le rôle de la JVM n'est pas de favoriser la programmation fonctionnelle. Si on devait la faire évoluer, ça serait vers toujours plus d'agnosticisme par rapport aux langages de programmation.

Absolument, je suis tout a fait conscient que la JVM ne peut tout optimiser, et ce n'est pas ce que je lui reproche...
Quand je parle d’inconvénients, j'évoque en premier l’effacement de type, cela ne facilite pas la vie des programmeurs utilisant les types génériques de manière un peu
poussée et provoque des incohérences, lors des comparaisons de type.

[gorgonite]

De quels défauts de la JVM parle-tu ?

Le rôle de la JVM n'est pas de favoriser la programmation fonctionnelle. Si on devait la faire évoluer, ça serait vers toujours plus d'agnosticisme par rapport aux langages de programmation.

Absolument, je suis tout a fait conscient que la JVM ne peut tout optimiser, et ce n'est absolument pas ce que je lui reproche...
Quand je parle d'inconvenants, j'évoque en premier l’effacement de type, cela ne facilite pas la vie des programmeurs utilisant de manière un peu
poussée les types génériques et provoque des incohérences, lors des comparaisons de type...

On peut parler d'un défaut majeur : l'impossibilité d'avoir la tail-call optimization (reference), ce qui oblige à passer entre autres par l'annotation @tailrec ou à avoir des récursions extrêmement simples (le compilateur s'est peut-être amélioré sur ce point, je n'ai pas testé depuis un moment)

[sjrd]

Il ne s'agit pas de "récursion extrêmement simple". Il s'agit de fonctions tail-recursive (par opposition aux tail calls en général). L'annotation @tailrec n'est pas nécessaire; elle est une aide au programmeur, qui lui permet d'être certain qu'une fonction est effectivement tail-recursive. Le compilateur optimisera les fonctions tail-recursive qu'elle soient annotées avec @tailrec ou pas.

D'après mon expérience (et je code en Scala tous les jours depuis 3 ans), les tail calls généralisés sont extrêmement rarement nécessaires/utiles. Et même les tail-recursive calls, je n'en utilise pas tant que ça (on s'en sort généralement avec les méthodes des collections). Dans les rares cas où les tail calls sont vraiment nécessaires, on peut faire du trampolining.

Quant à l'effacement de type (type erasure), c'est un faux reproche. Il y a des inconvénients, mais aussi des avantages. S'il n'y avait pas de type erasure, les développeurs se rendraient compte de tous les cas où la type erasure est bénéfique, et reprocheraient au langage de ne pas l'avoir. Pour les inconvénients, on peut généralement les solutionner avec des ClassTag ou, au besoin, des TypeTag.

[gorgonite]

Il ne s'agit pas de "récursion extrêmement simple". Il s'agit de fonctions tail-recursive (par opposition aux tail calls en général). L'annotation @tailrec n'est pas nécessaire; elle est une aide au programmeur, qui lui permet d'être certain qu'une fonction est effectivement tail-recursive. Le compilateur optimisera les fonctions tail-recursive qu'elle soient annotées avec @tailrec ou pas.

D'après mon expérience (et je code en Scala tous les jours depuis 3 ans), les tail calls généralisés sont extrêmement rarement nécessaires/utiles. Et même les tail-recursive calls, je n'en utilise pas tant que ça (on s'en sort généralement avec les méthodes des collections). Dans les rares cas où les tail calls sont vraiment nécessaires, on peut faire du trampolining.

Ben justement c'est simple comme récursion... d'un point de vue théorique ou comparé aux exemples naïfs qu'on montre habituellement aux étudiants débutant en programmation fonctionnelle.
Au passage, j'ai souvenir qu'à une époque (entre 2007 et 2009, de tête), cela optimisait quand même moins que cela

Après je ne dis pas que ce n'est pas suffisant pour la plupart des cas

Quant à l'effacement de type (type erasure), c'est un faux reproche. Il y a des inconvénients, mais aussi des avantages. S'il n'y avait pas de type erasure, les développeurs se rendraient compte de tous les cas où la type erasure est bénéfique, et reprocheraient au langage de ne pas l'avoir. Pour les inconvénients, on peut généralement les solutionner avec des ClassTag ou, au besoin, des TypeTag.

+1, le but d'une machine virtuelle est d'exécuter rapidement un programme, voire parfois aussi de gérer au mieux la mémoire... pas de faciliter le travail de retroingénierie, l'analyse statique du bytecode & cie

D'ailleurs le même reproche peut être fait à .Net dans une moindre mesure (pas les generics, mais le bytecode est bien simplifié à un moment, sinon on ne s'en sortirait pas... ex : essayez le reverse-engineering de bytecode compilé depuis des sources utilisant des dynamics ; idem avec IL et ILX)

[sjrd]

Ben justement c'est simple comme récursion... d'un point de vue théorique ou comparé aux exemples naïfs qu'on montre habituellement aux étudiants débutant en programmation fonctionnelle.

Huh ? Dans mon souvenir, tous les exemples qu'on voit quand on étudie la programmation fonctionnelle sont tail-recursive, et n'ont pas besoin des tail calls généralisés. À part l'exemple canonique mais artificiel de `isEven` et `isOdd` qui s'appellent récursivement l'une l'autre, mais c'est une mauvaise implémentation de toutes façons.

À quel exemple nécessitant les tail calls généralisés penses-tu ?

[Adraor]

Quant à l'effacement de type (type erasure), c'est un faux reproche. Il y a des inconvénients, mais aussi des avantages. S'il n'y avait pas de type erasure, les développeurs se rendraient compte de tous les cas où la type erasure est bénéfique, et reprocheraient au langage de ne pas l'avoir. Pour les inconvénients, on peut généralement les solutionner avec des ClassTag ou, au besoin, des TypeTag.

Peut être y à t'il des avantages en effet.
Mais je programme régulièrement en C# (qui n'utilise pas le type erasure), et je n'ai absolument pas été surpris (pas dans le mauvais sens du terme)...
Je pense qu'un développeur utilisateur de la JVM étant donc habitué à utiliser des patterns pour contourner les 'travers' de l’effacement de type (ce que je trouve déjà anormal), sera surpris lors de l'utilisation d'un langage qui ne confond pas une collection de patate et de carottes...
Alors si il y a effectivement des avantages que l'on ne retrouve que dans les langage utilisant le type erasure je ne demande qu'a apprendre...

+1, le but d'une machine virtuelle est d'exécuter rapidement un programme, voire parfois aussi de gérer au mieux la mémoire... pas de faciliter le travail de retroingénierie, l'analyse statique du bytecode & cie

D'ailleurs le même reproche peut être fait à .Net dans une moindre mesure (pas les generics, mais le bytecode est bien simplifié à un moment, sinon on ne s'en sortirait pas... ex : essayez le reverse-engineering de bytecode compilé depuis des sources utilisant des dynamics ; idem avec IL et ILX)

Hum... Si encore la JVM était plus rapide que la CLR cela pourrait avoir du sens... type erasure n'a pas pour vocation d'améliorer les performances, et ne facilite pas forcément la traduction du langage en assembleur (bytecode).
Et à mon avis, c'est d'autant plus condamnable pour un langage fortement typé tel que Java... ( et tout les rejetons de la JVM) de supprimer les types lors de la compilation.