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

Scala Java Discussion :

Quel avenir pour Scala depuis l'arrivée de Java 8, venez partager votre expérience


Sujet :

Scala Java

  1. #1
    Responsable Java & Kotlin

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    juillet 2005
    Messages
    14 954
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : juillet 2005
    Messages : 14 954
    Points : 72 903
    Points
    72 903
    Par défaut Quel avenir pour Scala depuis l'arrivée de Java 8, venez partager votre expérience
    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
    Responsable Java de Developpez.com (Twitter et Facebook)
    Besoin d"un article/tutoriel/cours sur Java, consulter la page cours
    N'hésitez pas à consulter la FAQ Java et à poser vos questions sur les forums d'entraide Java
    --------
    Ingénieur de Recherche en informatique au LIAS / ISAE-ENSMA
    Page de Developpez.com : mbaron.developpez.com
    Twitter : www.twitter.com/mickaelbaron
    Blog : mickael-baron.fr
    LinkedIn : www.linkedin.com/in/mickaelbaron
    DBLP : dblp.uni-trier.de/pers/hd/b/Baron:Micka=euml=l

  2. #2
    Membre éprouvé

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2005
    Messages
    588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juin 2005
    Messages : 588
    Points : 1 227
    Points
    1 227
    Par défaut
    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

  3. #3
    Membre éclairé
    Homme Profil pro
    nop
    Inscrit en
    mars 2015
    Messages
    436
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : nop
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2015
    Messages : 436
    Points : 651
    Points
    651
    Par défaut
    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.

  4. #4
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2014
    Messages : 8
    Points : 11
    Points
    11
    Par défaut
    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.

  5. #5
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 517
    Points : 10 144
    Points
    10 144
    Par défaut
    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.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  6. #6
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 388
    Points
    2 388
    Par défaut
    Citation Envoyé par Adraor Voir le message
    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.

  7. #7
    Membre habitué
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    juillet 2011
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant

    Informations forums :
    Inscription : juillet 2011
    Messages : 75
    Points : 163
    Points
    163
    Par défaut
    Merci pour ces précisions. Vous qui semblez maîtriser le sujet, auriez-vous de bons tutoriels/cours/livres à conseiller?

  8. #8
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2014
    Messages : 8
    Points : 11
    Points
    11
    Par défaut
    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.

  9. #9
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    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 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par Adraor Voir le message
    Citation Envoyé par Tharoth2
    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)
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  10. #10
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 517
    Points : 10 144
    Points
    10 144
    Par défaut
    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.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  11. #11
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    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 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par sjrd Voir le message
    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


    Citation Envoyé par sjrd Voir le message
    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)
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  12. #12
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 517
    Points : 10 144
    Points
    10 144
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    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 ?
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  13. #13
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    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 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par sjrd Voir le message
    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 ?
    • effectivement le classique isEven/isOdd
    • toutes les traductions naïves d'une formule mathématique, qu'on nous apprend juste après à transformer en récursion terminale (fibonacci, etc.) avec des astuces type accumulateurs ; afin de ne jamais attendre le résultat de l'appel récursif pour faire des calculs dans la fonction, mais qu'elle termine soit directement, soit par l'appel récursif
    • on mangeait pas mal de graphes en prépa, et assez rarement tail recursive ; seule l'algorithmie comptait (le hic pour les étudiants qui voulaient faire de gros exemples en TIPE)


    Sauf erreur de traduction tail-recursive = récursif terminal ; on apprend souvent aux débutants à reformuler en récursif terminal les formules traduites naïvement depuis l'approche mathématique (dite plus naturelle)... on ne mange presque que cela en sup (cela date un peu, mais quand même ). c'est très scolaire, mais cela a le mérite d'éliminer les stack overflow pour la spé. C'est peut-être spécifique à l'enseignement d'il y a 15 ans en France
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  14. #14
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2014
    Messages : 8
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par sjrd Voir le message
    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.

  15. #15
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Salut,


    Je programme régulièrement en Java, et je n'ai pas vraiment de problème avec le type-erasure.
    Et surtout je n'ai jamais eu de problème de confusion sur le type d'une collection.


    Sinon il y a bien des avantages à utiliser le type-erasure :
    • C'est évolutif : il est possible de "générifié" une classe sans "casser" le code existant.
    • C'est compatible avec des langages qui ne possède pas de notion de Generics : ils peuvent quand même utiliser les types paramétrés sans paramétrages.
    • Cela permet une variance/covariance bien plus complète (malgré une syntaxe un peu lourde en Java - mais ceci n'est pas lié au type-erasure).
    • Une seule version du code est partagé par toutes les instances, ce qui implique moins de travail pour le compilateur JIT, et moins d'utilisation mémoire (car on n'a pas à stocker les duplications de classes).



    Tout ceci pour des désavantages plutôt anecdotique mais tellement décrié !!!



    Sinon coté performances je doute qu'il y ait une réelle différence avec la réification... tant qu'on reste sur des références (or les Generics de Java ne s'appliquent qu'aux références).
    Le gros intérêt de la réification vient de son utilisation avec les types primitifs/values !
    C'est là tout l'intérêt de la réification, car on peut alors s'adapter aux spécificités du types, et en particulier son empreinte mémoire.

    Et justement le projet Valhalla qui a pour but d'apporter des types-values dans Java prévoit d'intégrer des "Generic-reified"... mais uniquement pour les types primitifs/values.
    Car il y a peu d'intérêt pour les références !


    a++

  16. #16
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2014
    Messages : 8
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par JavaBean Voir le message
    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 .

  17. #17
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2014
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Conseil

    Informations forums :
    Inscription : juillet 2014
    Messages : 8
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Salut,

    Sinon il y a bien des avantages à utiliser le type-erasure :
    • C'est évolutif : il est possible de "générifié" une classe sans "casser" le code existant.
    • C'est compatible avec des langages qui ne possède pas de notion de Generics : ils peuvent quand même utiliser les types paramétrés sans paramétrages.
    • Cela permet une variance/covariance bien plus complète (malgré une syntaxe un peu lourde en Java - mais ceci n'est pas lié au type-erasure).
    • Une seule version du code est partagé par toutes les instances, ce qui implique moins de travail pour le compilateur JIT, et moins d'utilisation mémoire (car on n'a pas à stocker les duplications de classes).



    Tout ceci pour des désavantages plutôt anecdotique mais tellement décrié !!!

    D'accord, ça à l'air intéressant en effet, je vais donc me renseigner un peu plus pour savoir ce qui à motivé les 'créateurs' a implémenter cela, merci des précisions.

  18. #18
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 517
    Points : 10 144
    Points
    10 144
    Par défaut
    Citation Envoyé par gorgonite Voir le message
    • toutes les traductions naïves d'une formule mathématique, qu'on nous apprend juste après à transformer en récursion terminale (fibonacci, etc.) avec des astuces type accumulateurs ; afin de ne jamais attendre le résultat de l'appel récursif pour faire des calculs dans la fonction, mais qu'elle termine soit directement, soit par l'appel récursif
    Exactement. On apprend à transformer la récursion naïve en récursion terminale (tail recursive) précisément parce que seule la récursion terminale peut être optimisée en boucle. Ceci n'est pas spécifique à Scala ni à la JVM. Tous les langages fonctionnels fonctionnent de la même façon. Dans tous ces cas, Scala peut optimiser aussi bien que n'importe quel langage fonctionnel.

    La récursion en générale (qui n'est pas tail call), telle qu'on en trouve dans des parcours de graphes ou d'arbres, n'est jamais optimisée en boucle. Et ce peu importe le langage utilisé. Scala n'est pas "moins fort" que d'autres en ce domaine.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  19. #19
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    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 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par Adraor Voir le message
    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...

    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.

    A l'époque où Java avait des vm pour des systèmes embarqués extrêmement petit, tout ce qui pouvait être éliminé du code de la vm ou du bytecode optimisé était bon à prendre
    (on pouvait faire tourner des benchmarks complets avec un vm consommant moins de 100Ko, il n'y a pas si longtemps... tant qu'on avait assez de mémoire pour gérer les données produites )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  20. #20
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    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 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par sjrd Voir le message
    Exactement. On apprend à transformer la récursion naïve en récursion terminale (tail recursive) précisément parce que seule la récursion terminale peut être optimisée en boucle. Ceci n'est pas spécifique à Scala ni à la JVM. Tous les langages fonctionnels fonctionnent de la même façon. Dans tous ces cas, Scala peut optimiser aussi bien que n'importe quel langage fonctionnel.
    Clairement, Scala est plus limité par la JVM que par la qualité de son compilateur

    Citation Envoyé par sjrd Voir le message
    La récursion en générale (qui n'est pas tail call), telle qu'on en trouve dans des parcours de graphes ou d'arbres, n'est jamais optimisée en boucle. Et ce peu importe le langage utilisé. Scala n'est pas "moins fort" que d'autres en ce domaine.
    Justement, le reproche que je faisais à l'enseignement en prépa à mon époque est de ne pas avoir souligné le besoin de se concentrer également sur les stratégies de parcours de graphes/arbres au lieu de juste étudier la complexité temporelle des problèmes présentés... Perso, j'avais vu arriver cette notion dans un cours de Prolog, puis lorsque j'ai entamé les compilateurs & analyseurs statiques. Du coup, un élève souhaitant faire un projet perso un peu sympa était obligé d'apprendre par lui-même des choses pas toujours évidentes (enfin, c'est formateur )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

Discussions similaires

  1. Réponses: 18
    Dernier message: 28/01/2016, 14h34
  2. Réponses: 105
    Dernier message: 01/12/2015, 15h25
  3. Quel avenir pour le Framework.NET ?
    Par Louis-Guillaume Morand dans le forum Général Dotnet
    Réponses: 139
    Dernier message: 16/07/2009, 18h06
  4. Quel avenir pour les informaticiens ?
    Par ghita269 dans le forum Emploi
    Réponses: 25
    Dernier message: 09/12/2005, 09h21
  5. Quel avenir pour les outils de génération de code ?
    Par Bruno75 dans le forum Débats sur le développement - Le Best Of
    Réponses: 5
    Dernier message: 05/11/2003, 18h30

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