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

Я только начал смотреть на повторную реализацию библиотеки коллекций Scala, которая появится в готовящемся выпуске 2.8 . Те, кто знаком с библиотекой из 2.7, заметят, что библиотека, с точки зрения использования, мало изменилась. Например...

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

... будет работать в любой версии. Библиотека в высшей степени удобна в использовании : на самом деле она фантастическая. Тем не менее, те, кто раньше не был знаком с Scala и разбирался в нем, чтобы почувствовать язык, теперь должны понимать сигнатуры методов, такие как:

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

Для такой простой функциональности это сложная подпись, которую я с трудом понимаю. Не то, чтобы я думал, что Scala когда-либо, вероятно, станет следующей Java (или / C / C ++ / C #) - я не верю, что его создатели нацелены на этот рынок - но я думаю, что это было / было возможно для Scala стать следующий Ruby или Python (то есть, чтобы получить значительную коммерческую пользовательскую базу)

• Это оттолкнет людей от посещения Скалы?
• Это даст Scala плохую репутацию в коммерческом мире как академическая игрушка, которую могут понять только преданные аспиранты? Будут ли напуганы CTO и руководители программного обеспечения?
• Была ли ре-дизайн библиотеки разумной идеей?
• Если вы используете Scala на коммерческой основе, вас это беспокоит? Планируете ли вы немедленно принять 2.8 или подождать, чтобы увидеть, что произойдет?

Стив Йегге однажды напал на Скалу (ошибочно, на мой взгляд) за то, что он видел как ее слишком сложную систему типов. Я беспокоюсь, что у кого-то будет полевой день, распространяющий FUD с помощью этого API (аналогично тому, как Джош Блох напугал JCP из-за добавления замыканий в Java).

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

Несмотря на то, что моя жена и коллеги постоянно говорят мне, я не думаю, что я идиот: у меня хорошее высшее образование по математике в Оксфордском университете , и я занимаюсь коммерческим программированием почти 12 лет, а в Scala - около год (также коммерчески).

Обратите внимание, что подстрекательское название темы является цитатой из манифеста политической партии Великобритании в начале 1980-х годов . Этот вопрос субъективен, но это подлинный вопрос, я сделал его CW, и я хотел бы получить некоторые мнения по этому вопросу.

Я надеюсь, что это не «предсмертная записка», но я понимаю вашу точку зрения. Вы сталкиваетесь с тем, что является одновременно силой и проблемой Scala: его расширяемость . Это позволяет нам реализовать большинство основных функций в библиотеках. В некоторых других языках, последовательности с чем-то вроде mapили collectбудут встроены, и никто не должен видеть все циклы, через которые должен пройти компилятор, чтобы они работали плавно. В Scala все это в библиотеке, и поэтому открыто.

На самом деле функциональность map, поддерживаемая его сложным типом, довольно продвинута. Учти это:

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!)

Видишь, как ты всегда получаешь самый лучший тип? Если вы сопоставляете Ints с Ints, вы снова получаете a BitSet, но если вы сопоставляете Ints с Strings, вы получаете общее Set. И статический тип, и представление результата выполнения во время выполнения зависят от типа результата функции, которая ему передана. И это работает, даже если набор пуст, поэтому функция никогда не применяется! Насколько я знаю, нет другого фреймворка для коллекций с эквивалентной функциональностью. Тем не менее, с точки зрения пользователя, именно так все и должно работать.

Проблема, которую мы имеем, состоит в том, что все умные технологии, которые делают это, просачиваются в сигнатуры типов, которые становятся большими и пугающими. Но, может быть, пользователю не следует показывать по умолчанию полную подпись типа map? Как насчет того , что она посмотрела mapна BitSetона получила:

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

В этом случае документы не будут лежать, потому что с точки зрения пользователя действительно карта имеет тип (Int => Int) => BitSet. Но mapтакже имеет более общий тип, который можно проверить, нажав на другую ссылку.

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

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

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

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

Итак, вместо

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

это традиционная сигнатура типа map, она обобщена так, что не требует конкретной, 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]

которая является традиционной подписью для map. (Обратите внимание, что из-за объектно-ориентированной природы Scala входной параметр списка исчезает, потому что теперь это неявный параметр-приемник, который есть у каждого метода в ОО-системе с одной диспетчеризацией.) Затем он обобщается из конкретного Listв более общий.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есть. Признаю, что если вы дадите только сигнатуру типа без имени метода, выяснить, что происходит, будет намного сложнее. Но поскольку вы уже знаете, что mapпредполагается делать, и знаете, какой должна быть его сигнатура типа, вы можете быстро отсканировать сигнатуру и сосредоточиться на аномалиях, например: «Почему для mapаргументов используются две функции, а не одна?»
2. Вы должны быть в состоянии действительно прочитать сигнатуру типа. Но даже если вы никогда раньше не видели Scala, это должно быть довольно просто, поскольку на самом деле это просто смесь синтаксисов типов, которые вы уже знаете из других языков: VB.NET использует квадратные скобки для параметрического полиморфизма и использует стрелку для обозначения возвращаемый тип и двоеточие для разделения имени и типа, на самом деле является нормой.
3. Вы должны примерно знать, что такое общее программирование. (Который не , что трудно понять, так как это в основном все прописано в названии: это буквально только программирование в общем виде).

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

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

То же самое в 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;
}

Ну, я могу понять вашу боль, но, честно говоря, такие люди, как вы и я - или почти любой обычный пользователь 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 получил поддержку типов с более высоким родом. Это делает API документы более сложными, но на самом деле делает использование более естественным.

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

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

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

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

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

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

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

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

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

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

• Ежедневно Скала
• Изучение Скалы в маленьких укусах
• Просто Скала

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я новичок в 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")

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

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

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

Первая критика состоит в том, что, подрывая подпись для карты, мы получаем нечто более общее. Распространено заблуждение полагать, что это достоинство по умолчанию. Это не так. Функция отображения очень хорошо определена как ковариантный функтор 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 из-за ее использования в целях понимания. К сожалению, это означает, что разработчик библиотеки, который лучше подготовлен, не может игнорировать эту ошибку, не жертвуя при этом синтаксическим сахаром понимания. Другими словами, если разработчики библиотеки Scala должны были уничтожить метод, это легко игнорируется, но, пожалуйста, не отображайте!

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

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

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

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

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

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

Чтобы взять пример в скаладок ...

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. Ковариантный и контравариантный типы в дженериках также добавляют много шума, который, я думаю, может быть гораздо проще для пользователей.

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

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

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

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

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

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

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

Это оттолкнет людей от посещения Скалы?

Я не думаю, что это главный фактор, который будет влиять на то, насколько популярным станет Scala, потому что у Scala много возможностей, и его синтаксис не такой чуждый программисту на Java / C ++ / PHP, как Haskell, OCaml, SML, Lisps, так далее..

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

Это даст Scala плохую репутацию в коммерческом мире как академическая игрушка, которую могут понять только преданные аспиранты? Пугают ли CTO и руководители программного обеспечения?

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

И для массового рынка первое изучение Scala - это не «глоток свежего воздуха», когда сразу пишут программы, такие как сначала использование HTML или Python. Скала имеет тенденцию расти на вас, после того, как вы узнаете все детали, на которые вы наткнулись с самого начала. Однако, возможно, если бы я читал Программирование в Scala с самого начала, мой опыт и мнение о кривой обучения были бы другими.

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

Определенно.

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

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

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

В коллекциях 2.8 Scala использование абстракции строителя - это принцип продуманного дизайна. Я хочу исследовать два компромисса дизайна ниже.

1. КОД ДЛЯ ТОЛЬКО ЗАПИСИ: После написания этого раздела я прочитал комментарий Карла Смотрица, который согласуется с тем, что я считаю компромиссом. Комментарии Джеймса Страчана и davetron5000 сходятся во мнении, что смысл Того (даже не Того [B]) и механизма неявного не легко понять интуитивно. Посмотрите, как я использую моноид в выпуске № 2 ниже, что, на мой взгляд, более явно. Комментарий Дерека Махара о написании Scala, а о чтении Scala других, что не «в общих случаях».

   Одна критика, которую я читал о Scala, заключается в том, что ее легче написать, чем прочитать код, написанный другими. И я нахожу, что это иногда верно по разным причинам (например, множество способов написать функцию, автоматическое замыкание, модуль для DSL и т. Д.), Но я не знаю, является ли это основным фактором. Здесь использование параметров неявной функции имеет свои плюсы и минусы. С положительной стороны, это уменьшает многословие и автоматизирует выбор объекта строителя. В примере Одерскогопреобразование из BitSet, то есть Set [Int], в Set [String] неявно. Незнакомый читатель кода может не знать, что это за тип коллекции, если только он не сможет хорошо продумать все потенциальные невидимые кандидаты в неявные компоновщики, которые могут существовать в текущей области пакета. Конечно, опытный программист и создатель кода будет знать, что BitSet ограничен Int, поэтому карта в String должна быть преобразована в другой тип коллекции. Но какой тип коллекции? Это не указано явно.

2. ДИЗАЙН AD-HOC COLLECTION: После написания этого раздела я прочитал комментарий Тони Морриса и понял, что я делаю почти то же самое. Возможно, мое более подробное изложение прояснит этот вопрос.

   В «Борьбе с гнилой битой с типами» Odersky & Moors представлены два варианта использования. Они являются ограничением элементов BitSet для Int и Map для сопряжения элементов кортежа и являются причиной того, что общая функция отображения элементов, A => B, должна иметь возможность создавать альтернативные типы целевых наборов. Однако, на самом деле, это ошибочно с точки зрения теории категорий. Чтобы быть последовательными в теории категорий и, таким образом, избегать угловых случаев, эти типы коллекций являются функторами, в которых каждый морфизм A => B должен отображаться между объектами в одной и той же категории функторов, List [A] => List [B], BitSet [A] => BitSet [B]. Например, Option - это функтор, который можно просматривать как совокупность наборов одного Some (объекта) и None. Нет общей карты от Option's None или List's Nil к другим функторам, которые не

   Здесь сделан компромиссный выбор дизайна. В проекте библиотеки для коллекций моего нового языка я решил сделать все функтором, что означает, что если я реализую BitSet, он должен поддерживать все типы элементов, используя внутреннее представление без битовых полей при представлении без параметр целочисленного типа, и эта функциональность уже находится в наборе, от которого она наследуется в Scala. И Map в моем дизайне должен отображать только его значения, и он может предоставить отдельный нефункциональный метод для сопоставления своих пар (ключ, значение) пары. Одним из преимуществ является то, что каждый функтор обычно также является аппликативным и, возможно, также монадой. Таким образом, все функции между типами элементов, например, A => B => C => D => ..., автоматически переносятся в функции между поднятыми аппликативными типами, например, List [A] => List [B] => List [ C] => Список [D] => .... Для отображения функтора в другой класс коллекции я предлагаю перегрузку карты, которая принимает моноид, например, Nil, None, 0, "", Array () и т. Д. Таким образом, функция абстракции построителя является методом добавления моноида и предоставляется явно как необходимый входной параметр, поэтому не имеет невидимых неявных преобразований. (Касательный: этот входной параметр также позволяет добавлять непустые моноиды, чего не может сделать дизайн карты Scala.) Такие преобразования - это карта и складка за один итерационный проход. Также я предоставляю обходной, в смысле категории, «Аппликативное программирование с эффектами» McBride & Patterson, которая также позволяет map + fold за один проход итерации от любого пройденного до любого аппликативного, где большинство каждого класса коллекции являются обоими.

   Таким образом, коллекции Scala являются «специальными» в том смысле, что они не основаны на теории категорий, а теория категорий является сущностью денотационной семантики более высокого уровня. Хотя неявные компиляторы Scala на первый взгляд «более обобщенные», чем модель функторов + моноидный компоновщик + traversable -> аппликативный, они на деле не соответствуют какой-либо категории, и поэтому мы не знаем, каким правилам они следуют в наиболее общий смысл и то, что будут даны угловые случаи, они могут не подчиняться какой-либо модели категории. Это просто неправда, что добавление большего количества переменных делает что-то более общее, и это было одним из огромных преимуществ теории категорий, поскольку она предоставляет правила, с помощью которых можно поддерживать общность, одновременно поднимая семантику более высокого уровня. Коллекция это категория.

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

Кроме того, я имею в виду неполное представление о том, что некоторые из компромиссов Scala связаны с попытками быть изменчивым и неизменным языком, в отличие, например, от языка Haskell или языка, который я разрабатываю. Это совпадает с комментарием Тони Морриса о понимании. В моем языке нет циклов и изменяемых конструкций. Мой язык будет на вершине Scala (на данный момент) и многим обязан, и это было бы невозможно, если бы у Scala не было общей системы типов и изменчивости. Это может быть не так, потому что я думаю, что Odersky & Moors («Борьба с гнилой битой с типами») неверно утверждать, что Scala - единственный язык ООП с более высокими типами, потому что я проверил (сам и через Боба Харпера), что стандарт У ML есть они. Также кажется, что система типов SML может быть эквивалентно гибкой (с 1980-х годов), что не может быть легко оценено, потому что синтаксис не так похож на Java (и C ++ / PHP), как Scala. В любом случае, это не критика Scala, а попытка представить неполный анализ компромиссов, который, я надеюсь, уместен в этом вопросе. Scala и SML не страдают от неспособности Хаскелламножественное наследование diamond , что очень важно, и я понимаю, почему так много функций в Haskell Prelude повторяются для разных типов.

Здесь необходимо указать степень: бакалавр политологии и бакалавр компьютерных наук.

К точке:

Это оттолкнет людей от посещения Скалы?

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

Если это образование доступно, каждый может это сделать. В прошлом году я строил шахматный компьютер с группой школьников в SCALA! У них были свои проблемы, но в конце они справились.

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

Я бы не волновался.

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

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

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

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

Как насчет сообщений об ошибках в использовании сайта?

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

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