La Scala 2.8 collections library est-elle une affaire de « la plus longue note de suicide dans l’histoire »

Question

Première remarque inflammatoires titre du sujet est une citation faite à propos du manifeste du royaume-UNI, le parti politique au début des années 1980. Cette question est subjective, mais c'est une vraie question, je l'ai fait CW et j'aimerais avoir quelques avis sur la question.

En dépit de mon épouse et de mes collègues me dit toujours, je ne pense pas que je suis un idiot: j'ai un bon niveau en mathématiques de l' Université d'Oxford et j'ai été à la programmation commercialement depuis presque 12 ans et Scala pour environ un an (également dans le commerce).

J'ai juste commencé à regarder la Scala collections de la bibliothèque de re-mise en œuvre qui est à venir, dans l'imminence de 2,8 libération. Ceux qui sont familiers avec la bibliothèque de 2,7 remarquerez que la bibliothèque, à partir de l'utilisation de la perspective, a peu changé. Par exemple...

> List("Paris", "London").map(_.length) 
res0: List[Int] List(5, 6)

...serait de travailler dans les deux versions. La bibliothèque est tout à fait utilisable: en fait, c'est fantastique. Toutefois, ceux qui avaient auparavant pas familier avec la Scala et de fouiller pour avoir une idée de la langue maintenant à donner un sens de signatures de méthode comme:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Pour la simple fonctionnalité, c'est un véritable signature de et une que je trouve moi-même du mal à comprendre. Non pas que je pense que Scala est plus que probablement la prochaine Java (ou /C/C++/C#) - je ne crois pas que ses créateurs étaient visant à ce marché, mais je pense qu'il est/était certainement possible pour Scala de devenir le prochain Ruby ou Python (c'est à dire d'acquérir une grande importance commerciale de l'utilisateur de la base)

• Est-ce que ça va repousser les gens à venir à la Scala?
• Est-ce que ça va donner Scala un mauvais nom dans le monde du commerce comme un universitaire jouet qui consacre uniquement les doctorants peuvent comprendre? Sont CTOs et les chefs de logiciel va les effrayer?
• A la bibliothèque de la re-conception d'une idée judicieuse?
• Si vous êtes à la Scala d'utilisation commerciale, êtes-vous inquiet à ce sujet? Envisagez-vous d'adopter 2.8 immédiatement ou d'attendre pour voir ce qui se passe?

Steve Yegge fois attaqué Scala (à tort à mon avis) pour ce qu'il considérait comme son extrêmement compliquées type de système. J'ai peur que quelqu'un va avoir une journée sur le terrain propagation de l'ics avec cette API (de la même manière que Josh Bloch peur le PLAN de l'ajout de fermetures à Java).

Remarque - je devrait être clair que, tandis que je crois que Josh Bloch a joué un rôle important dans le rejet de la BGGA fermetures proposition, je n'ai pas attribuer cela à rien d'autre que sa honnêtement croyances que la proposition représente une erreur.

Answer 1

J'espère que ce n'est pas une "note de suicide", mais je peux voir votre point de vue. Vous frappez sur ce qui est à la fois une force et un problème de la Scala: son extensibilité. Cela nous permet de mettre en œuvre la plupart des grandes fonctionnalités dans les bibliothèques. Dans quelques autres langues, des séquences avec quelque chose comme map ou collect serait construit dans, et personne n'y a qu'à voir tous les cercles le compilateur doit passer par la pour les faire travailler en douceur. En Scala, c'est tout dans une bibliothèque, et donc à l'air libre.

En fait, la fonctionnalité de l' map pris en charge par son complexe de type est assez avancé. Réfléchissez à ceci:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

Voir comment vous obtenez toujours la meilleure possible? Si vous mappez Ints pour Ints vous obtenez de nouveau un BitSet, mais si vous avez la carte Ints pour Strings, vous obtenez un général Set. À la fois le type statique et de l'exécution de la représentation de la carte du résultat dépend du type de résultat de la fonction qui est transmis. Et cela fonctionne même si l'ensemble est vide, donc la fonction n'est jamais appliquée! Autant que je sache, il n'y a pas d'autre cadre de collecte avec une fonctionnalité équivalente. Pourtant, à partir d'un point de vue utilisateur c'est la façon dont les choses sont censés travailler.

Le problème que nous avons est que toute la technologie intelligente, qui fait de ce lieu les fuites dans le type de signatures qui deviennent grand et effrayant. Mais peut-être qu'un utilisateur ne doit pas être affichées par défaut le type complet de la signature de l' map? Que diriez-vous si elle leva map en BitSet , elle a obtenu:

map(f: Int => Int): BitSet     (click here for more general type)

Les docs ne serait pas mentir dans ce cas, parce que d'un point de vue utilisateur, en effet, la carte est du type (Int => Int) => BitSet. Mais map dispose également d'un type plus général qui peut être inspecté en cliquant sur un autre lien.

Nous n'avons pas encore mis en œuvre la fonctionnalité de ce genre dans nos outils. Mais je crois que nous avons besoin de le faire, afin d'éviter d'effrayer les gens et de donner des informations plus utiles. Avec tous les outils qui, nous l'espérons smart cadres et les bibliothèques ne deviendra pas le suicide des notes.

Answer 2

Je n'ai pas un Doctorat, ni aucune autre sorte de degré ni dans CS, ni les mathématiques ni d'ailleurs dans tout autre domaine. Je n'ai pas d'expérience préalable avec Scala, ni toute autre formulation similaire. Je n'ai pas d'expérience avec, même à distance comparable type de systèmes. En fait, la seule langue que j'ai plus qu'une connaissance superficielle de ce qui même a un système de type est Pascal, pas exactement connue pour sa technologie de système de type. (Bien qu'il n' ont éventail de types, qui, autant que je sache à peu près pas d'autres langues, mais qui n'est pas vraiment pertinent ici.) Les trois autres langues que je connais sont à la BASE, Smalltalk et de Rubis, aucun de qui ont même un système de type.

Et pourtant, je n'ai aucune difficulté à tous la compréhension de la signature de l' map de la fonction que vous avez posté. Il me semble à peu près la même signature qu' map a dans toutes les autres langues que j'ai jamais vu. La différence est que cette version est plus générique. Il ressemble plus à un C++ STL chose que, disons, Haskell. En particulier, il les résumés loin du béton type de collection en n'exigeant que l'argument est - IterableLike, et également les résumés loin du béton type de retour en n'exigeant qu'une conversion implicite en fonction existe, qui peut construire quelque chose de cette collection de valeurs de résultat. Oui, c'est assez complexe, mais il est vraiment seulement une expression du général paradigme de programmation générique: ne présumez pas quelque chose que vous n'avez pas à.

Dans ce cas, map n'a pas réellement besoin de la collection pour avoir une liste, ou en cours de commande ou d'être sortable ou quelque chose comme ça. La seule chose qu' map se soucie, c'est qu'il peut accéder à tous les éléments de la collection, l'une après l'autre, mais en aucun ordre particulier. Et il n'a pas besoin de savoir ce que la collection est, il a seulement besoin de savoir comment le construire. Alors, qu'est ce que sa signature d'un type de besoin.

Ainsi, au lieu de

map :: (a → b) → [a] → [b]

qui est le type traditionnel de signature pour l' map, il est généralisé à pas besoin d'un béton List , mais plutôt juste un IterableLike structure de données

map :: (IterableLike i, IterableLike j) ⇒ (a → b) → i → j

qui est ensuite généralisée en n'exigeant qu'une fonction existe pour convertir le résultat quelle que soit la structure de données que l'utilisateur veut:

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

J'avoue que la syntaxe est un peu moins agiles, mais la sémantique est la même. Fondamentalement, il commence à partir de

def map[B](f: (A) ⇒ B): List[B]

qui est la signature traditionnelle pour map. (Notez en raison de l'orienté-objet de la nature de la Scala, la liste d'entrée paramètre disparaît, car il est maintenant l'implicite récepteur paramètre que chaque méthode en une seule expédition OO.) Puis il généralisée à partir d'un béton List générale IterableLike

def map[B](f: (A) ⇒ B): IterableLike[B]

Maintenant, il remplace l' IterableLike collection de résultat avec une fonction qui produit, bien, vraiment n'importe quoi.

def map[B, That](f: A ⇒ B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Qui je crois vraiment n'est pas que difficile à comprendre. Il n'y a vraiment que quelques outils intellectuels dont vous avez besoin:

1. Vous avez besoin de savoir (à peu près) ce que l' map . Si vous avez donné seulement la signature d'un type sans le nom de la méthode, je l'avoue, il serait beaucoup plus difficile de comprendre ce qui se passe. Mais puisque vous déjà savoir ce qu' map est censé faire, et vous savez quel est son type de signature est censé être, vous pouvez analyser rapidement la signature et de se concentrer sur les anomalies, comme "pourquoi est-ce que map prendre deux fonctions comme arguments, pas un?"
2. Vous devez être capable de lire le type de signature. Mais même si vous n'avez jamais vu Scala avant, cela devrait être assez facile, car il est vraiment juste un mélange de type syntaxes vous savez déjà de l'autre lanugages: VB.NET utilise des crochets pour polymorphisme paramétrique, et à l'aide d'une flèche pour indiquer le type de retour et de deux points pour séparer le nom et le type, est en fait la norme.
3. Vous avez besoin de savoir à peu près ce qu'programmation générique. (Ce qui n'est pas que difficile à comprendre, puisque c'est en gros tous les énoncés dans le nom: c'est littéralement juste de la programmation d'une façon générale).

Aucun de ces trois devrait donner à tous les professionnels ou même amateur programmeur un sérieux mal de tête. map a été d'une fonction standard dans presque toutes les langues, conçu dans les 50 dernières années, le fait que des langues différentes ont différentes syntaxe devrait être évident pour n'importe qui qui a conçu un site web avec HTML et CSS et vous ne pouvez pas vous inscrire à une même distance de programmation relative mailinglist sans quelques ennuyeux C++ fanboi de la chucrh de Saint-Stepanov expliquant les vertus de la programmation générique.

Oui, Scala est complexe. Oui, Scala est l'un des plus sophistiqués systèmes de type connu de l'homme, rivalisant avec et dépassant même les langages comme Haskell, Miranda, Nettoyer ou de Cyclone. Mais si la complexité ont un argument à l'encontre de la réussite d'un langage de programmation, C++ serait mort depuis longtemps et que nous serions tous writing. Il ya beaucoup de raisons pourquoi Scala sera très probablement pas être un succès, mais le fait que les programmeurs ne peuvent pas être pris la peine de tourner sur leur cerveau avant de s'asseoir devant le clavier est probablement pas la principale.

Answer 3

Même chose en C++ :

Answer 4

Eh bien, je peux comprendre votre douleur, mais, franchement, des gens comme vous et moi, ou à peu près n'importe quel Débordement de Pile utilisateur -- ne sont pas la règle.

Ce que je veux dire par là c'est que... la plupart des programmeurs se soucient pas de ce type de signature, parce qu' ils ne les verrez jamais! Ils ne lisent pas la documentation.

Aussi longtemps que ils ont vu un exemple de comment fonctionne le code, et le code n'a pas les échouent à produire les résultats qu'ils attendent, ils ne jamais regarder la documentation. Quand cela échoue, ils vont chercher à la documentation et s'attendre à voir des exemples d'utilisation dans la partie supérieure.

Avec ces choses à l'esprit, je pense que:

1. Quelqu'un (comme dans la plupart des gens) qui vient jamais à travers ce type de signature va se moquer de Scala pas de fin, si elles sont pré-disposée contre, et les considèrent comme un symbole de la Scala, à la puissance, s'ils aiment la Scala.

2. Si la documentation n'est pas améliorée afin de fournir des exemples d'utilisation et d'expliquer clairement ce qu'est une méthode et comment l'utiliser, il peut nuire à la Scala adoption un peu.

3. Dans le long terme, il ne sera pas question. Que la Scala peut faire des trucs comme ça va faire des bibliothèques écrites pour Scala beaucoup plus puissant et plus sûr à utiliser. Ces bibliothèques et les cadres d'attirer les programmeurs atracted à de puissants outils.

4. Les programmeurs qui aiment la simplicité et la franchise continuera d'utiliser le PHP, ou d'autres langues.

Hélas, les programmeurs Java sont beaucoup dans la puissance des outils, de sorte que, dans la réponse, j'ai juste révisé mon attente d'un courant de Scala adoption. Je n'ai aucun doute que la Scala va devenir une langue dominante. Pas de C-ordinaire, mais peut-être que Perl-ordinaire ou PHP-courant.

En parlant de Java, n'avez-vous jamais remplacer le chargeur de classe? Avez-vous jamais regardé dans tout ce que cela implique? Java peut être effrayant, si vous regardez les endroits cadre des écrivains faire. C'est juste que la plupart des gens ne le font pas. La même chose s'applique à la Scala, à mon humble avis, mais adopteurs précoces ont tendance à regarder sous chaque rocher qu'ils rencontrent, pour voir si il y a quelque chose y est caché.

Answer 5

Est-ce que ça va repousser les gens à venir à la Scala?

Oui, mais il sera également empêcher les gens d'être mis hors tension. J'ai considéré l'absence de collections que l'utilisation de meilleure kinded types de être une faiblesse majeure depuis Scala bénéficié du soutien du supérieur-kinded types. Il l'API docs plus compliqué, mais il a vraiment fait de l'utilisation plus naturelle.

Est-ce que ça va donner scala un mauvais nom dans le monde du commerce en tant qu'universitaire jouet qui consacre uniquement les doctorants peuvent comprendre? Sont directeurs techniques et chefs de logiciel va les effrayer?

Certains seront probablement. Je ne pense pas que Scala est accessible à de nombreux "professionnels" des développeurs, en partie en raison de la complexité de la Scala et en partie en raison de la réticence de nombreux développeurs à apprendre. Le Cto qui emploient ces développeurs à juste titre être effrayés.

A la bibliothèque de la re-conception d'une idée judicieuse?

Absolument. Il rend les collections vont beaucoup mieux avec le reste de la langue et le type de système, même si il y a encore quelques aspérités.

Si vous êtes à la scala d'utilisation commerciale, êtes-vous inquiet à ce sujet? Envisagez-vous d'adopter 2.8 immédiatement ou d'attendre pour voir ce qui se passe?

Je ne suis pas à l'utiliser dans le commerce. Je vais probablement attendre au moins deux ou trois tours dans la 2.8.x de la série avant même d'essayer de l'introduire, de sorte que les insectes peuvent être rincées. Je vais aussi attendre de voir comment beaucoup de succès l'EPFL dans l'amélioration de son développement un processus de diffusion. Ce que je vois, semble plein d'espoir, mais je travaille pour une conservatrice de la société.

Un le sujet plus général de la "Scala est trop compliqué pour les développeurs?"...

La plupart des développeurs, traditionnels ou non, le maintien ou l'extension des systèmes existants. Cela signifie que la plupart de ce qu'ils utilisent est dictée par les décisions prises il y a longtemps. Il y a encore beaucoup de gens qui écrit en COBOL.

Demain généraux du développeur travaillera maintenir et développer les applications qui sont en cours de construction aujourd'hui. La plupart de ces applications ne sont pas construites par la majorité des développeurs. De demain à intégrer les développeurs va utiliser la langue qui est utilisée aujourd'hui par plus de succès que les développeurs de nouvelles applications.