Je vais donner une courte durée de déjeuner (30 à 40 minutes) sur Scala au personnel technique de ma société. Je voudrais des suggestions pour ce qui serait le contenu le plus approprié. La plupart des personnes participant auront de l'expérience dans Java et / ou C # (plus diverses autres langues).
Quelles sont les choses essentielles à couvrir? J'aimerais donner une brève introduction à la syntaxe Scala afin que les gens ne se sentent pas perdus lors de l'examen des exemples de code. Je couvrirai aussi une partie de l'histoire de la langue et de ses concepteurs. Qu'est-ce qui aiderait les gens à tirer le meilleur parti de la conversation?
5 Réponses :
Les gens viennent presque certainement de parler pour avoir une réponse à la question "Pourquoi devrais-je utiliser Scala?" Tout ce que vous pouvez fournir pour les aider à répondre qui sera précieux.
Gardez la discussion de l'histoire et des personnalités derrière Scala au minimum.
Une tournée tourbillonnante de la syntaxe est utile, mais gardez-la courte.
Passez une bonne partie de la conversation démontrant des exemples et des comparaisons à Java. Montrer des cas où Scala brille. Vous devez littéralement courir et exécuter du code afin que les gens obtiennent une sensation pratique et pratique pour la façon dont les choses fonctionnent.
Assurez-vous de couvrir les faiblesses aussi! Fournir une vue d'ensemble objective et équilibrée.
Je pense que le pedigree de Martin Odersky est pertinent. Ce n'est pas une langue qui est sortie du bleu - elle a été conçue par l'auteur du compilateur générique Java
@OXBOW_LAKES: Je pense que c'est pertinent aussi, mais dans une conversation de 30 minutes, il n'ya pas de temps pour une discussion approfondie des origines de Scala et de la façon dont elle est arrivée. Quelques phrases courtes suffiront avant de continuer. Les gens sont là pour apprendre comment cela leur est pertinent, et c'est tout.
Je ne suis vraiment pas sûr d'être d'accord. Un des premiers "Pourquoi devrais-je apprendre scala?" Les préoccupations sont que la langue n'est pas là pour rester. Soulignez ceux qui sont derrière cela (si brièvement) contribue grandement à apaiser ces préoccupations
dur. Il faut équilibrer le nouveau et le familier. Par exemple:
parler de traits, comment ils diffèrent des interfaces et de multiples héritage. Notez que la plupart des méthodes de toutes les collections Scala peuvent réellement être trouvées sur le trait parler de fonctions et de fonctions partielles, montrez parler de motif correspondant - montrer comment avant tout éviter tout sujet qui pourrait être difficile à comprendre rapidement, ou vous risquez de perdre du temps dessus. Par exemple, de grands sujets, je ne parlerais pas de: types auto-types, variance, compréhensions.
Choisissez plus de sujets que vous n'avez le temps. Laissez le public diriger la conversation vers les topcis, ils sont plus intéressés. Si quelqu'un commence à faire trop de sujet sur un sujet, vous dites que vous serez ravi de l'expliquer plus loin, et demandez-leur si vous vous dérangeez si vous vous dérangeez si vous vous dérangeez si vous vous dérangeez un autre sujet. D'autre part, si tout le monde semble ramasser sur une chose en particulier, restez avec elle. Sinon, cela pourrait avoir envie de vous cacher quelque chose. Traversable , qui a une seule méthode abstraite: foreach .
mappe / Filtre / / foreach et comment ils utilisent des fonctions. < / p>
unapply est utilisé pour activer l'indépendance de la représentation, tandis que dans le même temps, les classes de cas facilitent le cas commun.
J'ai trouvé le motif correspondant à une autre pierre d'achoppement pour les personnes avec des antécédents Java / C qui se mettent enlisé avec des détails. Je l'introduit superfiquement comme «si / sinon» sur les stéroïdes, dans lesquels l'action prise peut accéder à des valeurs de réutilisation trouvées lors de l'évaluation du prédicat, mais omettez les détails sur les extracteurs.
J'ai donné une conversation similaire - surtout à celles avec un fond Java. Je sentais que prendre un morceau de véritable Java (environ 30 lignes) et que l'ajout de fonctionnalités Scala a bien fonctionné. Les 30 lignes de Java ont finalement fini par 6 (six!) De Scala. Le point étant (bien sûr) que 6 lignes sont plus lisibles et maintenues à 30.
J'ai converti le scala en équivalent Java à ligne à ligne et ensuite introduit:
J'ai constaté que ce segment a pris beaucoup de temps car le public était très intéressé par la syntaxe de Scala (en particulier autour des expressions de fonction). Avant d'entreprendre le morceau de patterns, j'avais une diapositive expliquant les différentes choses que vous pourriez utiliser dans une correspondance.
Vous pouvez faire pire que de courir dans la présentation de Jonas Bonér, Pragmatique Real-World Scala . Peut-être sauter des sujets avancés dedans sur différentes applications de traits et d'annotations de type auto-type.
J'ai donné une présentation lors de la réécriture de classes Java à Scala. Il a beaucoup d'exemples de Java -> Scala et (espérons-le) rend les gains évidents. N'hésitez pas à emprunter tout contenu que vous voulez ... La présentation a pris 1 heure 10 minutes afin que vous puissiez vous couper.
Présentation: http://www.colinhowe.co .uk / téléchargements / réécriture-java-in-scala.ppt
Vidéo: http://skillsmatter.com/podcast/java-jee/re-Orting-java-classes-in-scala-et-making-Your-Code-lovely