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


873

Я только начал смотреть на повторную реализацию библиотеки коллекций 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, и я хотел бы получить некоторые мнения по этому вопросу.


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

32
Этот вопрос был упомянут в первом разговоре Одерски по адресу Scala Days 2010 days2010.scala-lang.org/node/136
Binil Томас

7
Что мне нравится в Scala, так это то, что вам не нужно понимать систему сложного типа, чтобы делать простые и элегантные вещи. его синтаксис может быть пугающим, но он уверяет вас в одном: в нем нет «магии», например, магия является частью языка, это очень смелый и умный подход, я думаю, у вас есть язык, который может создавать новые DSL и новые мини языки внутри себя, да, не с той руки, Scala может быть прекрасным дополнением к вашему итальянскому ужину, но как только вы к этому привыкнете, это удивительный язык
Eran Medan

87
Как этот вопрос может быть «неконструктивным», если он привел к тому, что @MartinOdersky переоценил юзабилити Scala и заставил свою систему документации скрывать детали системы типов, не говоря уже о ярком обсуждении?
Jerry101

14
В самом деле, SO предназначен только для техничности с правильным форматом. Если у вас есть что-то деликатное, интригующее и далеко идущее, пожалуйста, посмотрите в другом месте. Да здравствует бюрократический менталитет.
Седьмого

Ответы:


892

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

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


107
Я чувствую себя непослушным школьником! Большое спасибо, что нашли время, чтобы ответить здесь. Я думаю, что баланс ответов показал мне, что мне не нужно беспокоиться; будет достаточно людей, которые вообще не запуганы.
oxbow_lakes

164
Нет, я думаю, что вы были абсолютно правы в этом вопросе. И другие люди будут напуганы, если мы не сделаем что-нибудь с этим.
Мартин Одерски

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

18
Я думаю, что решение, которое будет работать по крайней мере так же хорошо, это больше объяснений в документах. Я не нахожу подписи такими пугающими, если бы не тот факт, что большинство методов (и даже большинство классов) содержат не более одного предложения, описывающего их назначение и действие.
Ник Джонсон

98
Обновление: финальная версия Scala 2.8 имеет механизм, подобный тому, который я описал. Если вы посмотрите BitSet в скалярных документах, то обнаружите: def map [B] (f: (Int) ⇒ B): BitSet [B] [вариант использования] Создает новую коллекцию, применяя функцию ко всем элементам этого набора битов.
Мартин Одерски

226

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


36
@Jorg - это отличный ответ; благодарю вас. Независимо от того, имеете ли вы ученую степень или нет, вы являетесь человеком более ярким, чем я. Единственное, что я имею в виду , так это то, что я понимаю общую картину того, что происходит в сигнатуре метода. Тем не менее, детали по-прежнему сбивают с толку: как Thatвыводить и связывать с типом Bявляется один вопрос, который приходит на ум. Откуда берутся следствия от того, чтобы быть другим? Даже без этих подробных наблюдений я все еще лично чувствую, что это сложная подпись. Но, очевидно, есть такие люди, как вы, которые совсем не смущаются этим!
oxbow_lakes

50
Хорошее объяснение, но вы еще больше убедили меня, что сигнатура метода «map» в Scala 2.8 очень сложна.
Дерек Махар

11
Язык, который выглядит так: def map [B] (f: (A) ⇒ B): IterableLike [B] гораздо более привлекательный, чем тот, который выглядит следующим образом: def map [B, That] (f: A ⇒ B ) (неявный bf: CanBuildFrom [Repr, B, That]): То
Марк Эссель

215
Мне кажется довольно интересным, что вы начинаете с утверждения, что знаете только основы, ruby ​​и smalltalk, и продолжаете, что у вас нет академического образования по предмету. ... а затем требовать знания о сложности систем типов в таких языках, как Miranda и Clean; языки в основном известны только среди серьезных языков программирования, гиков и академиков.
Сами

14
У вас есть правильная точка зрения, что сравнение с Haskell неверно в том, что «map :: (a -> b) -> [a] -> [b]» относится только к спискам. Однако обобщенная версия класса Functor по-прежнему намного проще, чем версия Scala: класс Functor f, где fmap :: (a -> b) -> fa -> fb
Orclev

175

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

105
... и они говорят, что Скала неясна. Duh!
фактор

24
Только представьте, как бы это выглядело, если бы вместо произвольных заглавных букв использовались правильные идентификаторы с самоописанием. :-)
Ti Strga

14
Полезно увидеть это сравнение, но было бы более справедливо, если бы реализация была опущена.
Аарон Новструп

2
Я не большой поклонник обязательной функции указателя. Очевидно, тип funcдолжен быть параметром шаблона, и вы должны использовать result_ofи is_callableдля получения других типов и соответствующим образом ограничить набор перегрузки :-)
Kerrek SB

1
мои глаза болят !!!
Ашкан Х. Назарий

71

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

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

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

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

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

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

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

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

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

Говоря о Java, вы когда-нибудь заменяли загрузчик классов? Вы когда-нибудь изучали, что это включает? Java может быть страшной, если вы посмотрите на места, которые делают авторы фреймворка. Просто большинство людей этого не делают. То же самое относится и к Скале, ИМХО, но ранние последователи имеют тенденцию заглядывать под каждый камень, с которым они сталкиваются, чтобы увидеть, что там что-то скрывает.


10
As long as they saw some example of how the code works, and the code doesn't fail them in producing the result they expect, they won't ever look at the documentation. When that fails, they'll look at the documentation and expect to see usage examples at the top.Грустно, но верно.
Гамлиела

9
@ gamliela, я не думаю, что нам будет грустно об этом. У знания всегда может быть более одного уровня, и работа и доверие других (проверенные коллегами) в любой системе всегда могут быть использованы, как если бы мы ежедневно использовали арифметику и полностью игнорировали страшные алгебры, работающие за ним.
июля

55

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

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

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

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

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

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

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

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

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

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

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


31
«Это также предотвратит отстранение людей». это. абсолютно. scala - первый язык, который делает разработку с чем-то сравнимой с haskell (в силу системы типов) для многих из нас. я не смог бы убедить работу использовать haskell, но у scala действительно есть шанс, и за это я люблю его и буду (когда я думаю, что это имеет смысл) попытаться принять его или, по крайней мере, принять, на работе.
Эндрю Кук

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

16
«Завтрашние мейнстрим-разработчики будут использовать язык, который используют самые успешные на сегодняшний день разработчики новых приложений». +1. Блестяще сказано.
Васил Ременюк

46

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

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


43

У меня есть степень бакалавра в дешевом американском университете «массового рынка», так что я бы сказал, что попал в середину шкалы интеллекта пользователей (или, по крайней мере, образования) :) Я баловался со 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.


9
Извините за все комментарии. 1 неделя - это шутка практически для любого языка, но это не мешает менеджерам применить эту шутку на практике. Однажды мне дали 3 дня, чтобы «обучить» группу разработчиков C ++ на Java. Я просил в течение 5 дней, но был закорочен по бюджетным причинам.
Карл Смотриц

22
Для моей первой работы в конце интервью мне дали книгу на языке C ++, чтобы выучить ее до начала работы в понедельник. Вы все умники.
Том Хотин - tackline

12
@ Tom @Erik Вы, ребята, легко. Мне дали компьютерные схемы (без процессора), и я сказал, что у меня есть два часа, чтобы исправить ошибку во время интервью.
Даниэль С. Собрал

33
@Daniel @Tom @Erik Однажды мне дали 0 и 1 и попросили использовать их для решения проблемы ранца в линейном времени во время интервью. Я дал ему шанс, но, к сожалению, у меня было только время, чтобы создать Eclipse (который, я подозреваю, сводится к ранцу). #tall_tale
Алекс Миллер

10
@ Алекс Это показывает недостаток воображения. Поместите один большой ноль влево и два других меньших нуля справа: один над другим, верхний немного слева. Поместите единицу между этими двумя меньшими нулями, начиная с нижнего левого до верхнего правого. Скажем, это шанс разгадать рюкзак за линейное время. Вот и все. :-) +1 за приравнивание Затмения и Рюкзака, хотя. :-)
Даниэль С. Собрал,

33

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

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

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

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

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


2
Reprявляется проходимым представлением, т.е. Listили Setили Map. Я думаю, что в качестве основы, если вы собираетесь начать смотреть на сигнатуры методов (а не просто использовать методы путем копирования примеров), вы должны сначала понять общий дизайн. ИМХО Скаладок должен быть полон примера использования
oxbow_lakes

10
Итак, как бы я определил, что Reprзначит? Я ожидал бы объяснения в скаладоке, но оно было для меня неочевидным. Я думаю, что это обычный шаблон в скаладоке (посмотрите Actor.reactи Actor.receive- мне сказали, и я видел, что они делают совершенно разные вещи, но их скаладок идентичен).
davetron5000

7
Я согласен с davetron5000. Я хорошо знаком со Scala, но неявные определения все еще вызывают у меня головную боль. И причина не сама по себе, а в том, как они используются. Должна быть определенно лучшая документация и поддержка инструментов для понимания типов Scala. Тем не менее, я думаю, что система типов действительно может предложить что-то важное. Но мы все еще только в начале пути разумного программирования.
egaga

22

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

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

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


20

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

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


3
Привет Тони - спасибо за ваш вдумчивый вклад здесь. Я бы сделал 2 ответа на это. Во-первых, я не упомянул «среднего программиста» и не считаю, что Scala обязательно нацелена на одного. Независимо от того, тщеславен ли он от меня или нет, я считаю, что я выше среднего; однако, я все еще чувствую, что сигнатура типа устрашает! Другими словами, я все еще беспокоюсь о том, что программисты выше среднего уровня, целевой рынок Scala, могут быть изгнаны.
oxbow_lakes

6
Второй момент заключается в том , что я в корне не согласен с вами о том, что Scala является : Scala прагматический язык - не теоретически чистой один. Почему еще это было разработано на вершине JVM? Это чисто прагматичное решение - оно нацелено на разработчиков "в реальном мире" - выбор, который мог потребовать компромиссов! Также обратите внимание, что Блох и Йегге далеки от обычных программистов - но это моя точка зрения. Даже очень уважаемые и умные люди могут иметь мнения о сложности и чистоте, которые отличаются от ваших. К сожалению для вас, они также очень влиятельны.
oxbow_lakes

3
Здравствуйте, oxbow_lakes, Scala ставит своей целью успокоить типичных программистов, даже за счет точности и практичности. Программисты выше среднего изгоняются (у меня есть несколько анекдотов), но не потому, что сигнатуры типов устрашают, а из-за характера некоторых ошибок. Я не говорил, что Скала прагматична или не теоретична. Кроме того, я даже не согласен с (общей?) Идеей, что такая дихотомия существует. Библиотеки Scala прикрутили подпись карты. Я работаю над ошибками Скалы уже много лет; особенно библиотеки. Время сделать это снова.
Тони Моррис

5
Я не считаю Блоха или Йегге уважаемыми или умными, но они действительно весьма влиятельны. Да, это неудачно.
Тони Моррис

9
Почему вы относите траверс к расширенной подписи Scala? Карта Scala для монофункторов является стандартным fmap. Но ни BitSet, ни Map [A, B] не являются монофункторами, хотя map имеет значимое определение. Это мотивация подписи Scala, и траверс не решает эту проблему. Почему общность плохая вещь? Аппликативные функторы отслеживают эффекты, в чем их смысл в Scala? Наконец, я считаю, что универсальная карта Scala может быть реализована в виде обобщенного обхода, принимая CanBuildFrom и возвращая потенциально другой Traversable: не нужно жертвовать для понимания!
Blaisorblade

15

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


5
Но что означает «То» в качестве типа результата?
Blaisorblade

11

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

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

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

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


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

2
Хаха: трогательно! Ну, я сказал, что Scala 2.8 прост в использовании - мой вопрос был больше о том, как будет выглядеть кто-то, просматривающий API, чтобы увидеть, нравится ли ему это, предполагая, что у него нет предыдущего опыта работы с Scala.
oxbow_lakes

1
@andrew - судя по внешнему виду вашего веб-сайта ( acooke.org ), вы не испытываете неудобств из-за визуально пугающих понятий
oxbow_lakes

Любой, кто занят программированием на Malbolge, даже если это «просто» Hello World, вряд ли будет чем-то запуган.
Карл Смотриц

10

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

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


5
Речь никогда не идет о нотации (или, скажем, 10-15% о нотации), а о концепциях. И если вы достаточно умны и не увязли в знаниях за десятилетия от различных, возможно, противоречивых моделей (как я, вероятно, есть), то, как правило, понять эти вещи не так уж сложно. Но если вы научились думать и делать что-то одно, то, по крайней мере, нужно приложить некоторые усилия, и многие отреагируют на такие изменения. Это просто человеческая психология / природа. (Интересно, как психология компьютерного программирования Вайнберга выдерживает почти 40 лет?)
Рэндалл Шульц,

1
@Randall Schultz и Jeff G: Синтаксис / запись достаточно проста для умного человека. В основном разные названия для одних и тех же понятий. Быстрое освоение нового языка - это вопрос практики. ОДНАКО, шаг от процедурного к функциональному программированию ... пугающе широк. Это действительно другой способ мышления. Я несколько месяцев баловался с Clojure и считаю его относительно «простым» приятным языком FP. Но мне все еще нужно слишком много времени, чтобы разобраться с вещами, которые были бы просты в процедурном программировании.
Карл Смотриц

7

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


Да, синтаксис представления ускоряет понимание.
egaga

6

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

Я не думаю, что это главный фактор, который будет влиять на то, насколько популярным станет 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. Одно из ключевых отличий заключается в том, что trait разделен на интерфейс и миксин, где интерфейс содержит только сигнатуры методов, а не реализацию. И только интерфейс может быть указан как тип. Последствия устранены, а классы типов обрабатываются в интерфейсе SPOT. Вот черновик деталей. Сотрудники приветствуются. Некоторый код для библиотеки здесь . Это работа, извиняюсь за упоминание паровар. Просто делюсь мыслями.
Шелби Мур III

5

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

К точке:

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

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

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

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

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


4

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

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

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

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


-1

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

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

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


Но одним из основных моментов является различие между библиотекой с точки зрения пользователя и создателей. Очевидно, что создатели нуждаются во впечатляющем понимании требуемых языковых особенностей (например, типы с более высоким родом, неявный приоритет) - вопрос: «пользователи?»
oxbow_lakes
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.