Pourquoi ces tentatives d'édulcorer Scala avec Xtend et Kotlin? [fermé]

26

Alors maintenant, Eclipse a offert Xtend et JetBrains offre Kotlin - qui semblent tous deux être des versions édulcorées de Scala. Ma question est pourquoi? J'ai un peu joué avec Scala et ce n'est pas si difficile. S'agit-il simplement d'une réaction à la difficulté inhérente du passage de l'impératif au fonctionnel ou y a-t-il autre chose à l'œuvre ici?

EDIT: Excuses. En relisant la question telle que je l'ai publiée à l'origine, je peux voir où cela ressemble un peu à la pêche à la traîne. La façon dont j'ai formulé la question semblait être la meilleure façon de poser la question. J'ai vu des articles de blog selon lesquels "Scala est trop dur / Scala est trop complexe" et aussi "Kotlin est une tentative de faire Scala mais plus simple". Je vais laisser le libellé tel qu'il était à l'origine, mais honnêtement, je n'essayais pas de troll.

programming-languages scala Onorio Catenacci
la source
20
Il me semble assez fanatique de supposer simplement qu'une nouvelle langue qui a une certaine similitude avec Scala doit être une "version édulcorée de Scala" écrite par des gens pour qui Scala est trop dur. Vous êtes moins susceptible d'obtenir des réponses réfléchies en posant la question comme ça.
Michael Borgwardt
8
L'assemblage n'est qu'une version édulcorée du code machine, non?
Ben Brocka
6
@BenBrocka: Non, c'est isomorphe au code machine;)
4
Scala est super. Quant à moi, je crois que les gens devraient abandonner la nécromancie Java et réinventer les vélos (tous ces nouveaux langages, mentionnés ou non) et simplement utiliser et améliorer Scala. A MON HUMBLE AVIS.
Ivan
2
@MichaelBogwardt un point juste. Je fonde l'assertion sur ce que j'ai vu dans la blogosphère. «Scala est trop difficile» et «Scala est trop complexe» semblent être des plaintes relativement courantes.
Onorio Catenacci

Réponses:

39

À mon humble avis de quelqu'un qui a programmé en Java au cours des 7 dernières années et étant mon langage le plus fort, je trouve Scala assez étranger et j'ai du mal à m'y habituer.

Xtend ressemble plus à Java et a pu écrire une application simple avec elle beaucoup plus rapidement. Certes, je ne me suis pas donné assez de temps avec Scala, mais je comprends certainement pourquoi certains peuvent être désactivés par cela.

Cela étant dit, les gens choisiront un enfer familier plutôt qu'un paradis inconnu.

maple_shaft
la source
19
+1: "les gens choisiront un enfer familier plutôt qu'un paradis inconnu".
Giorgio
18

JetBrains a une page wiki comparant Scala à Kotlin, et il semble y avoir quelques choses que Kotlin fait et Scala ne fait pas:

  • Zero-overhead null-safety. Scala a Option, qui est un wrapper syntaxique et d'exécution
  • Moulages intelligents
  • Fonctions d'extension statiques. Au lieu d'envelopper à l'exécution
  • Les fonctions en ligne de Kotlin facilitent les sauts non locaux
  • Modèles de chaînes. Il existe un plugin de compilation tiers pour scala avec des fonctionnalités similaires: ScalaEnhancedStrings
  • Délégation de première classe. Également implémenté via un plugin tiers: modules Autoproxy

Donc, appeler Kotlin une descente d'eau Scala est probablement une simplification excessive. Quant à Xtend, je pense qu'il cible principalement les utilisateurs Xtext, plutôt qu'un public plus large. Une différence majeure avec Scala est que Xtend compile en Java plutôt qu'en bytecode.

Un autre langage "Java killer" que vous devriez ajouter à votre liste est le Ceylan de Red Hat , bien que je ne sache pas si et comment il se compare à Scala.

yannis
la source
13
Les lancers automatiques semblent effrayants.
Jonas
14
L'industrie connaît ces révolutions cycliques où les développeurs vont aller d'un extrême à plusieurs reprises. Les langages de codage de puissance riches en fonctionnalités étaient bons, puis les idiots ont écrit du mauvais code et nous avons trouvé les dangers afin que les gens affluent vers la sécurité perçue de Java, maintenant de retour aux codeurs de puissance. Regardez comment Javascript et le navigateur étaient bons, puis les applets sont arrivés et RIA avec les plugins du navigateur étaient bons et Javascript mauvais, puis les frameworks AJAX modernes sont arrivés et les plugins étaient peu sûrs et mauvais, puis Silverlight est venu et les gens ont dit que AJAX était mort, MAINTENANT HTML5 est à la mode et les plugins sont mauvais à nouveau! :)
maple_shaft
3
@Jonas Je ne sais même pas si je suis d'accord, mais c'est un phénomène que j'ai remarqué. Certes, à chaque révolution vient une solution plus sophistiquée, mais chaque solution a toujours un talon d'Achille. Résoudre le problème du talon amène certains à regarder en arrière sur les solutions d'idées précédentes, mais au fil du temps, les gens oublient pourquoi ces anciennes solutions ont été abandonnées à l'origine. Au fil du temps cependant, à chaque révolution, le talon devient de plus en plus petit. Java + XTend n'est certainement pas aussi sophistiqué que Scala, mais les problèmes sont plus petits que l'investissement pour passer complètement à un nouveau langage.
maple_shaft
2
@Jonas Eh bien, seule une simplification extrêmement élevée de l'évolution technologique pourrait tenir dans un commentaire. Je suis d' accord avec maple_shaft cependant, l' évolution technologique ne itérative une sensation .
yannis
3
@Jonas ces cast ne sont pas des castings automatiques mais intelligents: si vous regardez, vous verrez que ce n'est pas la même chose: kotlinlang.org/docs/reference/typecasts.html
cy6erGn0m
11

J'utilise Scala comme langue principale depuis l'année dernière (avec Java en seconde position, tous deux dans une grande base de code Java héritée.) Je dois encore rechercher des fonctionnalités assez basiques si je ne les ai pas utilisées dans un tandis que. Bien sûr, vous pouvez écrire du Scala rapidement, mais c'est un langage extrêmement riche en fonctionnalités, et cela prend beaucoup de temps à maîtriser.

De plus, sa complexité n'est pas seulement un problème pour les humains, mais aussi pour les IDE et les compilateurs. Celyon et Kotlin se compilent directement pour JavaScript assez propre. Scala peut produire du JavaScript, via GWT, mais y arriver est compliqué et la sortie GWT n'est ni lisible ni conçue pour jouer correctement avec JavaScript ou HTML externe.

Je suis nettement plus productif en Scala qu'en Java, et le code est plus compact et lisible (une fois que vous connaissez un peu Scala.) Mais sa complexité me fait hésiter à le recommander à d'autres. Une langue avec 20% de la complexité mais 80% de la capacité serait une alternative bienvenue.

[Modifié pour supprimer la mention du code hérité, voir le commentaire ci-dessous.]

[Addendum 2017: Scala prend désormais en charge JavaScript comme cible de génération, tandis que Kotlin a continué d'ajouter des fonctionnalités qui ont du sens pour un remplacement Java / Groovy / JavaScript de type Scala. Ce sont maintenant des langues plus distinctives que lorsque j'ai écrit cela pour la première fois.]

David Leppik
la source
Pourriez-vous s'il vous plaît élaborer un peu plus sur la "partie du retard"? Par exemple, quelles méthodes voulez-vous dire qui prennent des listes plutôt que des séquences?
kiritsuku
Je vais éditer cela, car après réflexion, la bibliothèque standard de Scala fait rarement cela. JSONArray prend une liste, mais la plupart des constructeurs ne le font pas. Quoi qu'il en soit, il existe toujours un biais dans la documentation en faveur des listes, d'autant plus que la programmation dans Scala, 2e édition, ne couvre que Scala 2.8, qui est antérieur aux vecteurs. Et ses exemples de code ont tendance à avoir des constructeurs qui prennent List où Seq serait mieux.
David Leppik
Ouais, pour 2.10 certaines choses sont meilleures ( +:extracteurs par exemple). J'espère que la programmation à Scala sera mise à jour dans un proche avenir. Pour 2.11, certaines choses s'améliorent encore. Le stdlib est déjà libéré des dépréciations et va également rétrécir un peu. Peut scala.util.parsing-être sera - t - il déplacé en dehors de stdlib également. Nous verrons ...
kiritsuku
1
Je dois ajouter que mon vrai problème avec les listes par rapport aux vecteurs est que l'ajout d'éléments à une liste (c'est-à-dire Seq dans Scala) est une opération très basique, et il existe trop de façons équivalentes de le faire, toutes avec des symboles amusants qui sont difficiles à rappelles toi. La manière canonique est ::, ::=ou +:=qui précède, mais la plupart des gens veulent :+=ce qui est ajouté, mais ce n'est pas efficace pour une liste.
David Leppik
10

JetBrains a clairement énoncé ses objectifs pour Kotlin :

Nous voulons devenir plus productifs en passant à un langage plus expressif. Dans le même temps, nous ne pouvons accepter de compromis en termes d'interopérabilité Java (le nouveau langage va être introduit progressivement et doit interagir en douceur avec la base de code existante) ou de vitesse de compilation (notre base de code prend assez de temps pour être compilée avec javac, et nous ne pouvons pas nous permettre de le ralentir). La prochaine chose est également assez simple: nous nous attendons à ce que Kotlin stimule les ventes d'IntelliJ IDEA.

Michael Borgwardt
la source
8

J'ai utilisé Scala quelques mois dans Eclipse avec Play Framework. J'aime la langue mais il y a aussi des choses que je n'aime pas.

Pour moi, la raison de passer de Java à un autre langage est d'être plus productif.

Jusqu'à présent, je n'ai pas été plus productif avec Scala. L'une des raisons est le manque de bonne prise en charge de Scala dans Eclipse, le plug-in Scala est mauvais (par exemple, l'indentation échoue) et n'a pas encore beaucoup de fonctions (par exemple pas de "hiérarchie des appels ouverts"). Le compilateur Scala est également lent, ce n'est peut-être pas un problème, mais j'utilise Scala avec Play Framework, qui compile le code pour chaque demande, et là, la vitesse du compilateur est importante.

Jonas
la source
2
Peut-être n'avez-vous pas suffisamment appris les idiomes de la Scala. J'ai utilisé Scala pour de petits projets (outils) et je suis de loin plus productif en Scala qu'en Java, même si j'ai beaucoup plus d'expérience en Java (> 10 ans) qu'en Scala (<2 ans).
Giorgio
4

Je ne sais pas pour Kotlin, mais Scala et Xtend sont deux bêtes très différentes.

Contrairement aux dictons courants, Scala n'est PAS un meilleur Java. Scala est un langage beaucoup plus en vedette que Java, avec sa propre syntaxe et sémantique, et son propre pack de bibliothèques de base.

Xtend EST un meilleur Java. Il conserve la sémantique Java et améliore sa syntaxe. Chaque ligne de code Xtend peut être directement traduite en un tas de lignes de code java. Il n'y a pas non plus d'exécution supplémentaire.

Je pense que les deux approches sont bonnes, bien que différentes. Je n'aime pas Scala (en tant que langue), mais je n'aime pas avoir des pots Scala ajoutés à mes projets. Je ne peux pas utiliser Scala correctement dans Android non plus (cela ajoute des problèmes de poids et de performances). Xtend n'est pas autant présenté, mais c'est ok pour moi (ça vaut le coup de l'utiliser que le langage Java) et il fonctionne sur toutes les plateformes comme si j'écrivais directement en Java.

Je crois que les deux langues couvrent des niches différentes et peuvent coexister sans interférer l'une avec l'autre. À mon humble avis, Scala est tout simplement trop complexe, n'ajoutant rien de nouveau. Si vous voulez devenir plus fonctionnel et moins OO, choisissez simplement l'un des nombreux langages fonctionnels plus simples, comme Clojure ou JHaskell. Si vous voulez juste Java avec une meilleure syntaxe et un peu de programmation fonctionnelle, Fantom serait aussi bon que Scala (il ressemble beaucoup à C #).

Mais je trouve que Xtend est à un point doux entre toutes ces langues. Il ajoute tous ces modèles syntaxiques que je voulais pour Java, en gardant les bonnes parties de Java (sa sémantique). Pensez-y comme Coffescript pour Java.

Et le support Eclipse est superbe ...

Ivan Hernandez
la source
… Et il n'est pris en charge que dans Eclipse. Droite? Et Eclipse est un enfer…
Sarge Borsch
Xtend dispose d'un runtime supplémentaire. À propos de 3MB la dernière fois que j'ai vérifié.
mm2001
@ mm2001 Oui il y a des dépendances: environ 300 Ko pour xtend et 2 Mo pour goyave sur mon petit projet de test ( github.com/pdemanget/examples/tree/master/xtend/message-send ) Mais ce n'est pas un runtime, ce sont classes supplémentaires pour quelque chose comme InputOutput, les annotations supplémentaires. Cela ne supprime pas le point principal pour moi que Scala et Xtend sont 2 langues très différentes comme dit dans cette réponse.
pdem