Чи є бібліотекою колекцій 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 комерційно, чи хвилюєтесь ви з цього приводу? Плануєте прийняти 2.8 негайно або чекаєте, що з’явиться?

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

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

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

Зауважимо, що запальна тема теми - це цитата, викладена про маніфест політичної партії Великобританії на початку 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 параметр списку вхідних даних зникає, оскільки це тепер неявний параметр приймача, який має кожен метод в системі одноосібної передачі OO.) Потім він узагальнився від конкретного 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 має одну з найскладніших типів, відому людині, яка конкурує і навіть перевершує такі мови, як Haskell, Miranda, Clean або Cyclone. Але якби складність була аргументом проти успіху мови програмування, C ++ давно б помер, і ми всі писали схему. Є багато причин, чому 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. Будь-хто (як і більшість людей), хто коли-небудь стикається з таким підписом, буде знущатися над Скалою без кінця, якщо вони будуть попередньо проти неї, і вважатиме це символом сили Скали, якщо їм подобається Скала.

2. Якщо документація не вдосконалена, щоб надати приклади використання та чітко пояснити, що таке метод і як його використовувати, це може трохи погіршити прийняття Scala.

3. Зрештою, це не має значення. Якщо Scala може робити такі речі, зробить бібліотеки, написані для Scala, набагато потужнішими та безпечнішими у використанні. Ці бібліотеки та фреймворки залучають програмістів, націлених на потужні інструменти.

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

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

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

Це збирається позбавити людей приїжджати до Скали?

Так, але це також заважатиме людям бути відкладеними. Я вважав, що відсутність колекцій, які використовують типи вищого типу, є головною слабкістю з тих пір, як Scala отримала підтримку для вищих типів. Це робить документи API складнішими, але це дійсно робить використання більш природним.

Чи це дасть Scala поганий ім'я в комерційному світі як академічна іграшка, яку можуть зрозуміти лише віддані аспіранти? Чи будуть ОГО та керівники програмного забезпечення лякатись?

Деякі, мабуть, і будуть. Я не думаю, що Scala доступна багатьом "професійним" розробникам, частково через складність Scala і частково через небажання багатьох розробників вчитися. ОГС, які використовують таких розробників, справедливо будуть відлякані.

Чи була перепроектована бібліотека розумною ідеєю?

Абсолютно. Це дозволяє колекціям набагато краще підходити до решти мови та системи типів, навіть якщо вона все ще має грубі краї.

Якщо ви використовуєте scala комерційно, чи хвилюєтесь ви з цього приводу? Плануєте прийняти 2.8 негайно або чекаєте, що з’явиться?

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

Ще одна загальна тема "Скала занадто складна для розробників?" ...

Більшість розробників, основні чи інші, підтримують або розширюють існуючі системи. Це означає, що більшість того, що вони використовують, продиктовано давно прийнятими рішеннями. Ще багато людей пише COBOL.

Завтра основний розробник працюватиме над підтримкою та розширенням додатків, які будуються сьогодні. Багато з цих програм не розробляються розробниками. Завтра основні розробники будуть використовувати мову, якою користуються найуспішніші розробники нових програм сьогодні.

Одним із способів того, як спільнота Scala може допомогти полегшити страх перед новими в Scala програмістами, є зосередитись на практиці та навчати на прикладі - чимало прикладів, які починаються з малих та поступово зростають більше. Ось кілька сайтів, які використовують такий підхід:

• Щоденний Scala
• Навчання Scala невеликими укусами
• Просто Скала

Провівши деякий час на цих сайтах, можна швидко зрозуміти, що Scala та її бібліотеки, хоч, можливо, важко розробити та впровадити, але не так вже й складні у використанні, особливо у звичайних випадках.

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

Тим більше, що IntelliJ випустив свій прекрасний IDE з тим, що IMHO на даний момент є найкращим плагіном Scala, розробка Scala є відносно безболісною:

• Я вважаю, що я можу використовувати Scala як "Java без крапки з комою", тобто пишу подібний на вигляд код, що я б робив на Java, і трохи виграв від синтаксичної стислості, такої, яку отримував за допомогою виводу типу. Поводження з винятками, коли я це взагалі роблю, зручніше. Визначення класу набагато менш довершене без котла getter / setter.

• Час від часу мені вдається записати один рядок, щоб виконати еквівалент декількох рядків Java. Там, де це застосовано, ланцюжки функціональних методів, такі як карта, складання, збирання, фільтрування тощо.

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

Як новачок, я продовжую боротися з лайливим та ідіоматичним синтаксисом. Виклики методів без параметрів не потребують дужок, за винятком випадків, коли вони є; випадки в заяві про матч потребують жирної стрілки ( =>), але також є місця, де вам потрібна тонка стрілка ( ->). Багато методів мають короткі, але досить виразні назви, наприклад, /:або \:- я можу зробити свої речі, якщо перегортаю достатньо сторінок вручну, але частина мого коду виглядає як шум Perl або рядка. За іронією долі, один із найпопулярніших біт синтаксичної стенограми відсутній у дії: я продовжую бути покусаним тим, що Intне визначає ++метод.

Це лише моя думка: я відчуваю, що Скала має силу C ++ у поєднанні зі складністю та читальністю C ++. Синтаксична складність мови також робить документацію API важкою для читання.

Scala дуже добре продумана і багато в чому блискуча. Я підозрюю, що багато академіків хотіли б програмувати в ньому. Однак він також сповнений кмітливості та готівки, він має набагато вищу криву навчання, ніж Java, і важче читати. Якщо я сканую форуми і побачу, як багато розробників досі борються з більш точними пунктами Java, я не можу уявити, що Scala коли-небудь стає мовою основного . Жодна компанія не зможе виправдати надсилання своїх розробників на 3-тижневий курс Scala, коли раніше їм потрібен був лише тиждень 1 курсу Java.

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

Я думаю, що просто «повинна бути неявним об'єкт в області дії , bfщо забезпечує будівельник для об'єктів типу Bв тип повертається значення That» допоміг би кілька, але це свого роду п'янких концепцій , коли все , що ви дійсно хочете зробити це карта A«з до B's. Насправді я не впевнений, що це правильно, тому що я не знаю, що Reprозначає тип , і документація Traversableнапевно не дає ніякого підказки.

Отже, мені залишаються два варіанти, жоден з них не приємний:

• Припустимо, це буде просто працювати як стара карта і як карта працює на більшості інших мов
• Покопайте ще у вихідному коді

Я розумію, що Скала по суті розкриває кишки того, як ці речі працюють, і що в кінцевому підсумку це є способом зробити те, що описує 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]

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

По-друге, функція карти є особливим випадком у Scala через її використання для розуміння. Це, на жаль, означає, що краще обладнаний дизайнер бібліотек не може проігнорувати цю помилку, не пошкодивши також синтаксичний цукор розуміння. Іншими словами, якщо дизайнери бібліотеки Scala повинні були знищити метод, то це легко ігнорувати, але, будь ласка, не картайте!

Я сподіваюсь, що хтось про це заговорить, тому що, як це є, важче буде вирішити помилки, на яких наполягає Скала, очевидно, з причин, на які я маю сильні заперечення. Тобто рішення "безвідповідальних заперечень середнього програміста (тобто занадто важко!)" Полягає не в тому, щоб "заспокоїти їх, щоб їм було простіше", а натомість надати покажчики та допомогу стати кращими програмістами. Цілі "Я" та "Скала" суперечать цьому питанню, але повертаємось до вашої точки зору.

Ви, напевно, задумалися, передбачивши конкретні відповіді від "середнього програміста". Тобто люди, які будуть претендувати "але це занадто складно!" або дещо таке. Це Єгеґени чи Блохи, до яких ви посилаєтесь. Моя реакція на цих людей антиінтелектуалізму / прагматизму є досить різкою, і я вже передчуваю заперечення відповідей, тому я опущу це.

Я щиро сподіваюсь, що бібліотеки Scala покращаться, або, принаймні, помилки можна спокійно приховати в кут. Java - це мова, де "намагатися зробити що-небудь корисне" настільки неймовірно дорого, що часто цього не варто, тому що величезної кількості помилок просто не уникнути. Я закликаю Скалу не йти тим самим шляхом.

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

Здебільшого люди читають скаладок, щоб дізнатись, якими методами вони можуть викликати тип та які параметри вони можуть пройти. Ми як би перевантажуємо користувачів занадто багато деталей, як саме IMHO.

Ось ще один приклад ...

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

Тепер, якщо ми приховали декларацію генерики, її легше читати

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

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

Я не знаю, як зв'язати це з вами, але в мене є доктор наук з Кембриджу, і я використовую 2,8 просто чудово.

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

Отже: я "новий користувач" і мене не відкладали - той факт, що він працює як Java, дав мені достатньо впевненості, щоб ігнорувати біти, які я не розумів.

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

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

Чи це дасть Скалі невірне ім'я в комерційному світі як академічна іграшка, яку можуть зрозуміти лише віддані аспіранти? Чи будуть ОГО та керівники програмного забезпечення лякатись?

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

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

Чи була перепроектована бібліотека розумною ідеєю?

Безумовно.

Якщо ви використовуєте Scala комерційно, чи хвилюєтесь ви з цього приводу? Плануєте прийняти 2.8 негайно або чекаєте, що з’явиться?

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

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

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

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

   Однією критикою, яку я читав про Scala, є те, що її простіше написати, ніж прочитати код, який написали інші. І я вважаю, що це періодично відповідає різним причинам (наприклад, багато способів написання функції, автоматичне закриття, блок для DSL тощо), але я не визначуся, якщо це головний фактор. Тут використання неявних параметрів функції має плюси та мінуси. З іншого боку, це знижує багатослів’я та автоматизує вибір об’єкта будівельника. На прикладі Одерськогоперетворення з BitSet, тобто Set [Int], у набір [String] неявне. Незнайомий читач коду може не легко знати, що таке тип колекції, якщо тільки вони не можуть добре обґрунтувати всі потенційні невидимі неявні кандидати-конструктори, які можуть існувати в поточному обсязі пакету. Звичайно, досвідчений програміст і автор коду буде знати, що BitSet обмежений Int, таким чином, карта до String повинна перетворити на інший тип колекції. Але який тип колекції? Це не вказано прямо.

2. ПРОЕКТУВАННЯ КОЛЕКЦІЇ AD-HOC: Після написання цього розділу я прочитав коментар Тоні Морріса і зрозумів, що я беру майже те саме. Можливо, моє більш багатослівне викладення зробить точку більш зрозумілою.

   У "Боротьбі з бітовою гнитлю з типами" Odersky & Moors представлені два випадки використання. Вони є обмеженням BitSet елементами Int та Map для пари елементів кортежу, і вони є причиною того, що загальна функція відображення елементів, A => B, повинна бути в змозі створити альтернативні типи колекцій призначення. Однак afaik це недолік з точки зору теорії категорій. Щоб бути послідовними в теорії категорій і, таким чином, уникати кутових випадків, ці типи колекцій є функторами, в яких кожен морфізм, A => B, повинен відображати між об'єктами в одній категорії функторів, Список [A] => Список [B], BitSet [A] => BitSet [B]. Наприклад, Варіант - це функтор, який можна розглядати як набір множин одного Some (об'єкта) та None. Немає загальної карти від "Опції" Ні "," Ніл "списку до інших функторів, які не мають"

   Тут зроблений компромісний вибір дизайну. При розробці бібліотеки колекцій моєї нової мови я вирішив зробити все функтором. Це означає, що якщо я реалізую BitSet, він повинен підтримувати всі типи елементів, використовуючи внутрішнє представлення небітного поля, коли воно представлене з не- параметр типу integer, і ця функціональність вже є в наборі, від якого вона успадковується в Scala. І Map у моєму дизайні повинен відображати лише його значення, і він може надати окремий нефункціональний метод для відображення його (ключ, значення) кортежів пари. Одна з переваг полягає в тому, що кожен функтор тоді зазвичай також є додатком і, можливо, також монадою. Таким чином, всі функції між типами елементів, наприклад A => B => C => D => ..., автоматично переносяться на функції між піднятими типами додатків, наприклад Список [A] => Список [B] => Список [ C] => Список [D] => .... Для відображення від функтора до іншого класу колекції я пропоную перевантаження карти, яка приймає моноїд, наприклад, Nil, None, 0, "", Array () тощо. Отже, функція абстрагування будівельника - це метод додавання моноїда та надається явно як необхідний вхідний параметр, таким чином, без невидимих ​​неявних перетворень. (Дотична: цей вхідний параметр також дозволяє додавати до не порожніх моноїдів, чого не може зробити дизайн картки Scala.) Такі перетворення є картою та складкою в одному ітераційному проході. Також я надаю в сенсі категорії "Прикладне програмування з ефектами" McBride & Patterson, яке також дозволяє зіставити карту + скласти в один прохід ітерації з будь-якого пройденого в будь-який додаток, де більшість класів колекції є обома.

   Тож афаїки колекції Scala є "спеціальними" в тому сенсі, що вона не ґрунтується на теорії категорій, а теорія категорій є сутністю денотаційної семантики вищого рівня. Незважаючи на те, що неявні будівельники Scala спочатку виглядають "більш узагальненими", ніж функторна модель + моноїдний конструктор + перехідна -> застосовна, вони, як відомо, не відповідають вимогам будь-якої категорії, і тому ми не знаємо, яких правил вони дотримуються в Найбільш загальний сенс, і те, що буде надано наріжні випадки, вони можуть не підкорятися жодній моделі категорії. Просто не вірно, що додавання більшої кількості змінних робить щось більш загальне, і це було однією з величезних переваг теорії категорій: вона передбачає правила, за допомогою яких зберігається загальність, піднімаючись до семантики вищого рівня. Колекція - категорія.

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

Крім того, я маю на увазі неповну думку про те, що деякі збитки Scala пов'язані з намаганням бути одночасно незмінною та незмінною мовою, на відміну від Haskell або мови, яку я розвиваю. Це узгоджується з коментарем Тоні Морріса щодо розуміння. У моїй мові немає циклів і змінних конструкцій. Моя мова буде сидіти на вершині Scala (поки що) і багато чого їй завдячує, і це було б неможливо, якби Scala не мала б загальної системи типу та змінності. Це, можливо, не відповідає дійсності, тому що я думаю, що Odersky & Moors ("Боротьба з бітовою гниллю з типами") невірно стверджувати, що Scala є єдиною мовою OOP з вищими типами, тому що я перевірив (сам і через Боб Харпер), що Стандарт ML має їх. Також видається, що тип типу SML може бути настільки ж гнучким (починаючи з 1980-х років), що може бути легко оцінено, оскільки синтаксис не настільки схожий на Java (і C ++ / PHP), як на Scala. У будь-якому випадку, це не критика Скали, а скоріше спроба представити незавершений аналіз компромісів, що, сподіваюсь, є важливим для цього питання. Scala і SML не страждають від нездатності Хаскелла зробитибагатократне успадкування алмазів , що є критичним, і я розумію, чому стільки функцій у прелюдії Haskell повторюються для різних типів.

Тут видається необхідним визначити ступінь бакалавра: бакалавр політичних наук та бакалавр наук з інформатики.

До речі:

Це збирається позбавити людей приїжджати до Скали?

Скала складна, тому що її основна парадигма програмування є складною. Функціональне програмування лякає багатьох людей. Можна створити закриття в PHP, але люди рідко роблять це. Тож ні, не цей підпис, але все інше приведе людей у ​​відставку, якщо вони не матимуть конкретної освіти, щоб змусити їх цінувати силу основної парадигми.

Якщо ця освіта є, кожен може це зробити. Минулого року я будую шаховий комп’ютер із купою школярів у SCALA! У них були свої проблеми, але вони врешті-решт зробили добре.

Якщо ви використовуєте Scala комерційно, чи хвилюєтесь ви з цього приводу? Плануєте прийняти 2.8 негайно або чекаєте, що з’явиться?

Я б не хвилювався.

У мене теж ступінь математики в Оксфорді! У мене знадобився певний час, щоб "отримати" нові речі з колекцій. Але мені це дуже подобається зараз, коли я це роблю. Насправді, введення «карти» було однією з перших великих речей, яка заробила мене в 2.7 (можливо, оскільки перше, що я зробив, був підкласом одного з класів колекції).

Читання статті Мартіна про нових колекціях 2.8 справді допомогло пояснити використання імпліцитів, але так, саме документація потребує кращого завдання щодо пояснення ролі різного роду імпліцитів у підписах методів основних API.

Моя головна проблема - це більше: коли буде випущено 2.8? Коли звіти про помилки перестануть надходити для цього? команда Scala відкусила більше, ніж вони можуть жувати з 2.8 / спробувала змінити занадто багато відразу?

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

Що з повідомленнями про помилки на сайті використання?

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

Дуже добре знати, що в основному це просто, але це не обов'язково достатньо. Принаймні, повинен бути один хлопець, який знає цей матеріал, якщо планується розробити широку бібліотеку.