Является ли библиотека коллекций Scala 2.8 «самой длинной заметкой о самоубийстве в истории»? [закрыто]

Scala имеет множество сумасшедших функций (особенно в том, что касается неявных параметров), которые выглядят очень сложными и академичными, но созданы для того, чтобы делать вещи легко использовать. Наиболее полезные из них получают синтаксический сахар (например, [A <% B] , что означает, что объект типа A имеет неявное преобразование в объект типа B) и хорошо документированное объяснение того, что они делают. . Но в большинстве случаев, как клиент этих библиотек, вы можете игнорировать неявные параметры и доверять им делать правильные вещи.

Я не знаю, как рассказать вам об этом, но у меня докторская степень в Кембридже, и я отлично использую 2.8.

Если серьезно, я почти не тратил время с 2.7 (он не будет взаимодействовать с библиотекой Java, которую я использую) и начал использовать Scala чуть больше месяца назад. У меня есть некоторый опыт работы с Haskell (небольшой), но я просто игнорировал то, что вас беспокоит, и искал методы, соответствующие моему опыту работы с Java (которые я использую для жизни).

Итак: я «новый пользователь», и меня это не оттолкнуло - тот факт, что он работает как Java, дал мне достаточно уверенности, чтобы игнорировать биты, которые я не понимал.

(Однако причина, по которой я частично смотрел на Scala, чтобы понять, стоит ли продвигать его в работе, и я пока не собираюсь этого делать. Сделать документацию менее пугающей, безусловно, поможет, но что меня удивило, так это то, насколько он все еще меняется и развивается (честно говоря, больше всего меня удивило то, насколько он потрясающий, но изменения были вторыми). Поэтому я предполагаю, что я говорю, что предпочел бы, чтобы ограниченные ресурсы были вложены в доведение его до конечного состояния - не думаю, что они ожидали, что так скоро станут настолько популярными.)

К сожалению, подпись для карты, которую вы указали, неверна для карты и действительно есть законная критика.

Первая критика заключается в том, что, подрывая подпись для карты, мы получаем нечто более общее. Распространенная ошибка полагать, что это добродетель по умолчанию. Это не так. Функция отображения очень хорошо определяется как ковариантный функтор Fx -> (x -> y) -> Fy с соблюдением двух законов композиции и тождества. Все остальное, что приписывается «карте», является пародией.

Данная подпись - это что-то еще, но это не карта. Я подозреваю, что это попытка быть специализированной и слегка измененной версией сигнатуры "траверса" из статьи "Сущность шаблона итератора". Вот его подпись:

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

Я конвертирую его в Scala:

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

Конечно, он не работает - он недостаточно общий! Кроме того, он немного отличается (обратите внимание, что вы можете получить карту, запустив traverse через функтор Identity). Однако я подозреваю, что если бы авторы библиотеки были более осведомлены об обобщениях библиотеки, которые хорошо документированы (прикладное программирование с эффектами предшествует вышеупомянутому), тогда мы бы не увидели эту ошибку.

Во-вторых, функция map - это особый случай в Scala из-за ее использования в for-complationings. К сожалению, это означает, что разработчик библиотеки, который лучше подготовлен, не может игнорировать эту ошибку, не жертвуя также синтаксическим сахаром понимания. Другими словами, если разработчикам библиотеки Scala пришлось уничтожить метод, то это легко проигнорировать, но, пожалуйста, не отображайте!

Я надеюсь, что кто-то заговорит об этом, потому что теперь будет сложнее обходить ошибки что Scala настаивает на создании, очевидно, по причинам, против которых я категорически возражаю. То есть решение «безответственных возражений среднего программиста (т. Е. Слишком жестких!)» Состоит не в том, чтобы «умилостивить их, чтобы облегчить им задачу», а вместо этого предоставить указатели и помощь, чтобы они могли стать лучше программистов. Я и Цели Scala спорят по этому поводу, но вернемся к вашей точке зрения.

Вы, вероятно, высказывали свою точку зрения, предсказывая конкретные ответы от «среднего программиста». То есть люди, которые будут утверждать «но это слишком сложно!» или что-то в этом роде. Это Ягги или Блохи, о которых вы говорите. Мой ответ этим людям из движения антиинтеллектуализма / прагматизма довольно резок, и я уже предвижу шквал ответов, поэтому опущу его.

Я искренне надеюсь, что библиотеки Scala улучшат или, по крайней мере, исправят ошибки. можно безопасно убрать в угол. Java - это язык, в котором «попытки сделать что-нибудь полезное» обходятся настолько дорого, что часто не стоит того, потому что подавляющего количества ошибок просто невозможно избежать. Я умоляю Scala не идти по тому же пути.

У меня есть степень бакалавра в дешевом "массовом" университете США, так что я бы сказал, что попал в середину шкалы пользовательского интеллекта (или, по крайней мере, образования) :) Я ' Я баловался Scala всего несколько месяцев и работал над двумя или тремя нетривиальными приложениями.

Особенно теперь, когда IntelliJ выпустила свою прекрасную IDE с тем, что IMHO в настоящее время является лучшим плагином Scala, разработка Scala относительно безболезненна:

• Я обнаружил, что могу использовать Scala как «Java без точек с запятой», т. Е. Я пишу код, похожий на тот, который я бы сделал на Java, и немного выигрываю от синтаксической краткости, такой как полученная путем вывода типов. Обработка исключений, когда я вообще это делаю, удобнее. Определение класса гораздо менее подробное без шаблона getter / setter.

• Время от времени мне удается написать одну строку, чтобы выполнить эквивалент нескольких строк в Java. Там, где это применимо, цепочки функциональных методов, таких как map, fold, collect, filter и т. Д., Интересно составлять и элегантно созерцать.

• Лишь изредка я получаю выгоду от более мощных функций Scala: замыканий и частичных (или каррированных) ), сопоставление с образцом ... и тому подобное.

Как новичок, я продолжаю бороться с кратким и идиоматическим синтаксисом. Для вызовов методов без параметров скобки не нужны, за исключением тех, где они нужны; Для случаев в операторе соответствия нужна толстая стрелка ( => ), но есть также места, где вам нужна тонкая стрелка ( -> ). Многие методы имеют короткие, но довольно загадочные имена, например /: или \: - Я могу закончить свою работу, если перелистаю достаточно справочных страниц, но часть моего кода в конечном итоге выглядит как Perl или шум строк. По иронии судьбы, один из самых популярных фрагментов синтаксических сокращений отсутствует в действии: меня постоянно укушает тот факт, что Int не определяет метод ++ .

Это это просто мое мнение: мне кажется, что Scala обладает мощью C ++ в сочетании со сложностью и удобочитаемостью C ++. Синтаксическая сложность языка также затрудняет чтение документации API.

Scala очень хорошо продуман и во многих отношениях великолепен. Я подозреваю, что многим ученым хотелось бы заниматься на нем. Тем не менее, он также полон смекалки и ошибок, у него гораздо более высокая кривая обучения, чем у Java, и его труднее читать. Если я просканирую форумы и увижу, сколько разработчиков все еще борются с тонкостями Java, я не могу представить, чтобы Scala когда-либо стал основным языком . Ни одна компания не сможет оправдать отправку своих разработчиков на трехнедельный курс Scala, тогда как раньше им требовался только недельный курс Java.

Один из способов, с помощью которого сообщество Scala может помочь снизить страх программистов, плохо знакомых со Scala, - это сосредоточиться на практике и учить своим примером - множество примеров, которые начни с малого и постепенно увеличивайся. Вот несколько сайтов, использующих этот подход:

• Daily Scala
• Изучение Scala небольшими частями
• Simply Scala

Проведя некоторое время на этих сайтах,

Помешает ли это людям перейти на Scala?

Да, но это также предотвратит отталкивание людей. Я считал отсутствие коллекций, в которых используются высокодобные типы, серьезной слабостью с тех пор, как Scala получила поддержку высокодородных типов. Это усложняет документацию по API, но на самом деле делает ее использование более естественным.

Не сделает ли scala плохой репутацией в коммерческом мире как академической игрушкой, понятной только преданным студентам PhD? Не испугаются ли технические директора и руководители программного обеспечения?

Некоторые, вероятно, испугаются. Я не думаю, что Scala доступна для многих «профессиональных» разработчиков, частично из-за сложности Scala, а частично из-за нежелания многих разработчиков учиться. Технические директора, которые нанимают таких разработчиков, справедливо испугаются.

Был ли редизайн библиотеки разумной идеей?

Абсолютно. Благодаря этому коллекции намного лучше соответствуют остальному языку и системе типов, даже если у нее все еще есть шероховатости.

Если вы используете scala в коммерческих целях, беспокоитесь ли вы об этом? Планируете ли вы сразу перейти на 2.8 или подождать, чтобы увидеть, что произойдет?

Я не использую его в коммерческих целях. Я, вероятно, дождусь хотя бы пары оборотов в серии 2.8.x, прежде чем даже пытаться представить ее, чтобы ошибки можно было вымыть. Я также подожду, чтобы увидеть, насколько успешны EPFL в улучшении процессов разработки и выпуска. То, что я вижу, выглядит обнадеживающим, но я работаю в консервативной компании.

Одна из наиболее общих тем: «Не слишком ли сложен Scala для основных разработчиков?» ...

Большинство разработчиков, как основных, так и других, поддерживают или расширяют существующие системы. Это означает, что большая часть того, что они используют, продиктована давно принятыми решениями. Есть еще много людей, пишущих COBOL.

Основной разработчик завтрашнего дня будет работать над поддержанием и расширением приложений, которые создаются сегодня. Многие из этих приложений создаются не основными разработчиками. Основные разработчики завтрашнего дня будут использовать язык, который используется наиболее успешными разработчиками новых приложений сегодня.

Ну, я могу понять вашу боль, но, откровенно говоря, людям нравится мы с вами - или почти любой обычный пользователь Stack Overflow - не правила.

Я имею в виду, что ... большинству программистов наплевать на сигнатуру этого типа, потому что они ' Я никогда их не увижу ! Они не читают документацию.

Пока они видели какой-то пример того, как работает код, и код не подводит их к результату, который они ожидают , они никогда не будут смотреть в документации. Когда это не удается, они ' Я посмотрю документацию и ожидаю увидеть примеров использования вверху.

Имея в виду эти вещи, я думаю, что:

1. Любой (как и большинство людей), кто когда-либо сталкивался с этим подпись типа будет бесконечно издеваться над Scala, если они заранее настроены против нее, и будет считать ее символом силы Scala, если им нравится Scala.

2. Если документация не расширена, чтобы предоставить примеры использования и четко объяснить, что такое Метод предназначен и как его использовать, он может немного отвлечь от принятия Scala.

3. В конечном итоге это не имеет значения. То, что Scala может делать подобные вещи, сделает библиотеки, написанные для Scala, более мощными и безопасными в использовании. Эти библиотеки и фреймворки привлекут программистов, привлеченных к мощным инструментам.

4. Программисты, которым нравится простота и непосредственность, будут продолжать использовать PHP, или подобные языки.

Увы, Java-программисты очень любят мощные инструменты, поэтому, отвечая на этот вопрос, я только что пересмотрел свое ожидание массового принятия Scala. Я не сомневаюсь, что Scala станет основным языком программирования. Не C-mainstream, но, возможно, Perl-mainstream или PHP-mainstream.

Кстати о Java, вы когда-нибудь заменяли загрузчик классов? Вы когда-нибудь изучали, что это значит? Java может быть пугающей, если вы посмотрите на то, чем занимаются писатели фреймворков. Просто большинство людей этого не делают. То же самое применимо и к Scala, IMHO, но ранние последователи имеют тенденцию заглядывать под каждый камень, с которым они сталкиваются, чтобы увидеть, не скрывается ли там что-то.

Кстати о Java, вы когда-нибудь заменяли загрузчик классов? Вы когда-нибудь изучали, что это значит? Java может быть пугающей, если вы посмотрите на то, чем занимаются писатели фреймворков. Просто большинство людей этого не делают. То же самое относится и к Scala, IMHO, но ранние последователи имеют тенденцию заглядывать под каждый камень, с которым они сталкиваются, чтобы увидеть, не скрывается ли там что-нибудь.

Кстати о Java, вы когда-нибудь заменяли загрузчик классов? Вы когда-нибудь изучали, что это значит? Java может быть пугающей, если вы посмотрите на то, чем занимаются писатели фреймворков. Просто большинство людей этого не делают. То же самое относится и к Scala, IMHO, но ранние последователи имеют тенденцию заглядывать под каждый камень, с которым они сталкиваются, чтобы увидеть, не скрывается ли там что-нибудь.

У меня нет докторской степени, или какой-либо другой степени ни в области компьютерных наук, ни в математике, ни в какой-либо другой области. У меня нет опыта работы со Scala или другими подобными языками. У меня нет опыта работы с системами даже отдаленно сопоставимого типа. Фактически, единственный язык, который у меня есть больше, чем просто поверхностные знания, который даже имеет систему типов, - это Паскаль, не совсем известный своей сложной системой типов. (Хотя у есть типы диапазонов, которых, по сути, нет ни у одного другого языка, но это здесь не имеет значения.) Три других языка, которые я знаю, - это BASIC, Smalltalk и Ruby, ни один из которых даже есть система типов.

И все же у меня нет проблем с пониманием сигнатуры функции map , которую вы разместили. Мне кажется, что это почти такая же подпись, что и у map на всех других языках, которые я когда-либо видел. Разница в том, что эта версия более общая. Это больше похоже на C ++ STL, чем, скажем, на Haskell. В частности, он абстрагируется от конкретного типа коллекции, требуя только, чтобы аргумент был IterableLike , а также абстрагируется от конкретного возвращаемого типа, требуя только наличия неявной функции преобразования, которая может строить что-то из этой коллекции значений результатов. Да, это довольно сложно, но на самом деле это всего лишь выражение общей парадигмы универсального программирования: не предполагайте ничего, что вам на самом деле не нужно.

В этом случае map делает на самом деле не нужно , чтобы коллекция была списком, или быть упорядоченным или сортируемым, или что-то в этом роде. Единственное, что заботит map , - это то, что она может получить доступ ко всем элементам коллекции, один за другим, но в произвольном порядке. И ему не нужно знать, что такое результирующая коллекция, ему нужно только знать, как ее построить. Итак, это то, что требуется для его сигнатуры типа.

Итак, вместо

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

, которая является традиционной сигнатурой типа для карты , она обобщается, чтобы не требовать конкретного List а скорее просто структура данных IterableLike

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

, которая затем дополнительно обобщается, требуя только существования функции, которая может преобразовать результат в любую структуру данных, которую хочет пользователь:

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

Я допускаю, что синтаксис немного сложнее, но семантика такая же. В основном, он начинается с

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

, который является традиционной сигнатурой для карты . (Обратите внимание, как из-за объектно-ориентированной природы Scala параметр входного списка исчезает, потому что теперь он является неявным параметром получателя, который есть у каждого метода в ОО-системе с одной отправкой.) Затем он был обобщен на основе конкретного списка. на более общий IterableLike

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

Теперь он заменяет набор результатов IterableLike функцией, которая производит , ну, на самом деле почти все.

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

Я действительно верю, что это не , что трудно понять. На самом деле вам понадобится всего пара интеллектуальных инструментов:

1. Вам нужно знать (примерно), что такое map . Если вы дали только подпись типа без имени метода, я допускаю, Было бы намного сложнее понять, что происходит. Но поскольку вы уже знаете , что должна делать карта , и знаете, какой должна быть сигнатура ее типа, вы можете быстро сканировать сигнатуру и сосредоточиться на аномалиях, например " почему эта карта принимает две функции в качестве аргументов, а не одну? »
2. Вы должны иметь возможность читать сигнатуру типа. Но даже если вы никогда раньше не видели Scala, это должно быть довольно легко, поскольку на самом деле это просто смесь синтаксисов типов, которые вы уже знаете из других языков: VB.NET использует квадратные скобки для параметрического полиморфизма и стрелку для обозначения тип возвращаемого значения и двоеточие для разделения имени и типа на самом деле является нормой.
3. Вам нужно примерно знать, что такое универсальное программирование. (Что не t , что трудно понять, поскольку в основном все это прописано в названии: это буквально простое программирование в общем виде). ​​

Ни один из этих трех не должен серьезно относиться к профессиональному программисту или даже программисту-любителю. Головная боль. map была стандартной функцией практически во всех языках, разработанных за последние 50 лет, тот факт, что разные языки имеют разный синтаксис, должен быть очевиден для любого, кто разработал веб-сайт с HTML и CSS, и вы можете ' Я подписываюсь на список рассылки, посвященный даже удаленному программированию, без того, чтобы какой-нибудь надоедливый фанат C ++ из церкви Св. Степанова объяснил достоинства обобщенного программирования.

Да, Scala сложен . Да, Scala имеет одну из самых сложных систем типов, известных человеку, которая может конкурировать и даже превосходить такие языки, как Haskell, Миранда, Клин или Циклон. Но если бы сложность была аргументом против успеха языка программирования, C ++ давно бы умер, и мы все писали бы Scheme. Существует множество причин, по которым Scala, скорее всего, не добьется успеха, но тот факт, что программисты не могут позаботиться о том, чтобы включить свой мозг перед тем, как сесть за клавиатуру, вероятно, не будет основной.

Я думаю, что основная проблема этого метода заключается в том, что (неявный bf: CanBuildFrom [Repr, B, That]) не требует объяснения. Хотя я знаю, что такое неявные аргументы, нет ничего, что указывало бы на то, как это влияет на вызов. Погоня за скалярным документом только сбивает меня с толку (некоторые из классов, относящихся к CanBuildFrom , даже имеют документацию).

Я думаю, что простой "должен быть неявный объект в области видимости для bf , который предоставляет конструктор для объектов типа B в возвращаемый тип Это "может несколько помочь, но это своего рода головокружительная концепция, когда все, что вам действительно нужно, это map от A до B . На самом деле, я не уверен, что это правильно, потому что я не Я не знаю, что означает тип Repr , а документация для Traversable определенно не дает никаких подсказок.

Итак, у меня осталось два варианта, ни один из них приятный:

• Предположим, он будет работать так же, как работает старая карта и как карта работает на большинстве других языков.
• Покопайтесь еще немного в исходном коде.

Я понимаю, что Scala, по сути, раскрывает основы того, как эти вещи работают и что в конечном итоге это способ сделать то, что описывает oxbow_lakes. Но в подписи это отвлечение.

• Предположим, он будет работать так же, как работает старая карта и как карта работает на большинстве других языков.
• Покопайтесь еще немного в исходном коде.

Я понимаю, что Scala, по сути, раскрывает основы того, как эти вещи работают и что в конечном итоге это способ сделать то, что описывает oxbow_lakes. Но в подписи это отвлечение.

• Предположим, он будет работать так же, как работает старая карта и как карта работает на большинстве других языков.
• Покопайтесь еще немного в исходном коде

Я понимаю, что Scala, по сути, показывает, как эти вещи работают и что в конечном итоге это способ сделать то, что описывает oxbow_lakes. Но в подписи это отвлечение.

Я полностью согласен как с вопросом, так и с ответом Мартина :). Даже в Java чтение документации javadoc с помощью универсальных шаблонов намного сложнее, чем должно быть, из-за дополнительного шума. Это объединено в Scala, где используются неявные параметры, как в примере кода вопросов (в то время как имплициты делают очень полезные вещи по преобразованию коллекций).

Я не думаю, что это проблема языка как такового - я думаю, что это скорее проблема с инструментами. И хотя я согласен с тем, что говорит Йорг В. Миттаг, я думаю, что, глядя на scaladoc (или документацию типа в вашей IDE), нужно как можно меньше умственных способностей, чтобы понять, что такое метод, что он принимает и что возвращает.Не нужно копаться в алгебре на листе бумаги, чтобы получить это :)

Наверняка IDE нуждаются в хорошем способе показать все методы для любой переменной / выражения / типа (что, как и в случае с В примере Мартина могут быть встроены все дженерики, так что его легко и удобно нащупывать). Мне тоже нравится идея Мартина скрывать имплициты по умолчанию.

Чтобы взять пример в scaladoc ...

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

Глядя на это в scaladoc, я бы хотел, чтобы общий блок [B, That] был скрыт по умолчанию, а также неявный параметр (возможно, они отображаются, если вы наведите курсор на маленький значок с помощью мыши) - в качестве дополнительного материала для чтения, который обычно не так важен. например представьте, если бы это выглядело как ...

def map(f: A => B): That

красиво, ясно и очевидно, что он делает. Вы можете задаться вопросом, что такое «Это», если навести указатель мыши или щелкнуть по нему, он может развернуть текст [B, That], выделив, например, «Это».

Может быть, для объявления [] и (неявного ...) блока можно было бы использовать маленький значок, чтобы было ясно, есть ли небольшие фрагменты заявления? Для этого сложно использовать токен, но я буду использовать. на данный момент ...

def map.(f: A => B).: That

Так что по умолчанию «шум» системы типов скрыт от 80% основных вещей, на которые нужно обратить внимание - имени метода, его типов параметров и его возвращаемого типа в красивой простой и лаконичной форме. - с небольшими расширяемыми ссылками на детали, если вам это действительно интересно.

В основном люди читают scaladoc, чтобы узнать, какие методы они могут вызывать для типа и какие параметры они могут передавать. Мы как бы перегружаем пользователей слишком большим количеством деталей, как ИМХО.

Вот еще пример ...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Теперь, если мы спрятали объявление дженериков, его будет легче читать

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Тогда, если люди наведут курсор на, скажем, A1, мы сможем показать, что объявление A1 является A1 <: A. Ковариантные и контравариантные типы в дженериках тоже добавляют много шума который, я думаю, может быть отрендерен гораздо проще для пользователей.

Совершенно не знаю Scala, однако несколько недель назад я не мог читать Clojure. Теперь я могу прочитать большую часть этого, но пока не могу ничего написать, кроме самых упрощенных примеров . Я подозреваю, что Scala ничем не отличается. Вам нужна хорошая книга или курс, в зависимости от того, как вы учитесь. Просто прочитав объявление map выше, я получил , может быть, 1/3 его.

Я считаю, что самые большие проблемы заключаются не в синтаксисе этих языков, а в принятии и усвоении парадигм , которые делают их пригодными для использования в повседневном производственном коде. Для меня Java не была большим скачком по сравнению с C ++, который не был большим скачком по сравнению с C, который вообще не был скачком от Pascal, Basic и т. Д. Но кодирование на функциональном языке, таком как Clojure , - это ] огромный скачок (по крайней мере для меня). Думаю, в Scala можно писать код в стиле Java или Scala. Но в Clojure вы создадите настоящий беспорядок, пытаясь сохранить свои императивные привычки от Java.

То же самое в C ++:

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}

Я новичок в Scala и, честно говоря, не вижу проблем с этой сигнатурой типа. Параметр - это функция, которую нужно сопоставить, и неявный параметр, который построитель возвращает правильную коллекцию. Понятно и читабельно.

На самом деле, все это довольно элегантно. Параметры типа построителя позволяют компилятору выбрать правильный тип возвращаемого значения, в то время как механизм неявных параметров скрывает этот дополнительный параметр от пользователя класса. Я пробовал это:

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

Это правильно сделанный полиморфизм.

Конечно, это не мейнстримная парадигма, и она многих отпугнет. Но он также привлечет многих, кто ценит его выразительность и элегантность.

Что насчет сообщений об ошибках на используемом сайте?

А как насчет варианта использования, когда нужно интегрировать существующие типы с настраиваемым типом, подходящим для DSL. Нужно хорошо разбираться в вопросах ассоциации, приоритета, неявных преобразований, неявных параметров, высших типов и, возможно, экзистенциальных типов.

Приятно знать, что в основном это просто, но этого не всегда достаточно. По крайней мере, должен быть один парень, который разбирается в этом, если мы хотим разработать широко распространенную библиотеку.

У меня тоже есть степень по математике в Оксфорде! Мне потребовалось время, чтобы «разобраться» с новыми коллекциями. Но теперь мне это очень нравится. Фактически, типизация «map» была одной из первых серьезных вещей, которые беспокоили меня в 2.7 (возможно, с тех пор, как я первым делом создал подкласс одного из классов коллекции).

Чтение статьи Мартина о новых коллекциях 2.8 действительно помогло объяснить использование имплицитов, но да, сама документация определенно должна лучше объяснять роль различного рода имплицитов в сигнатурах методов основных API.

Меня больше всего беспокоит: когда выйдет 2.8? Когда перестанут поступать сообщения об ошибках? команда scala откусила больше, чем они могут прожевать с 2.8 / пыталась изменить слишком много сразу?

Я действительно хотел бы увидеть 2.8, стабилизированный для выпуска в качестве приоритета перед добавлением чего-либо еще нового, и задайтесь вопросом (наблюдая со стороны), можно ли внести некоторые улучшения в способ управления дорожной картой разработки для компилятора scala.