Інтервью з Одерським

Отож, почнемо з простих питань.

  1. Чому операторів break та continue нема в оригінальній Scala? Вони так подобались користувачам… (00:30)

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

    У нас багато імперативних конструкцій, таких як  for або С-style while. Але от break та continue – це навіть більш імперативні конструкції ніж інші імперативні, це фактично go-to оператори, що вказують на місце у програмі, тому ми вважаємо що їм не місце у функціональній мові. Замість використовування break та continue, ваш алгоритм слід побудувати у більш функціональному вигляді. Ну і наостанок – якщо вам він дійсно потрібний, то в стандартній бібліотекі є оператор break (scala-lang.org/api/current/scala/util/control/Breaks.html – прим. перекладача), що використовує генерацію виключень (винятків)  для досягнення подібної функціональності.

  1. Чому так багато нових ключових слів у dotty, в той час як анотації недостатньо використовуються. Які у вас критерії для вибору між новим ключовим словом та анотацією? (01:34)

   Я зараз точно не скажу, скільки ключових слів у dotty, але більшість з них – це так звані м’які ключові слова (“soft keywords”). Ми стали використовувати такі слова що мають зміст тільки в окремих місцях програми (раніше у Scala такого не було), так що код не потрібно переписувати при додаванні більшості нових м’яких ключових слів – їх все рівно можна буде використовувати як ідентифікатори. Чому не анотації – я думаю що анотації і так занадто багато використовуються. На мою думку, анотації – це шлях для винаходу нових мов на базі вже існуючих. Загалом, з анотаціями можна робити що завгодно, і у цьому й полягає проблема. Ви можете зробити мову дуже заплутаною за допомогою анотацій, так як їх створювати дуже легко. Я думаю правильна ідея наступна: анотація не повинна впливати на систему типів програми, хоча вона й може впливати на “забезпечення сумісності” (interop) або на якісь інші аспекти. Однак, якщо анотації будуть впливати на процес виводу типів, то я буду сильно проти такого використання анотацій. Ми можемо піти далі і сказати, що анотації не повинні змінювати основну семантику мови, але ми вже й так порушуємо цей принцип з @volatile: в даному випадку анотація змінює оперативну семантику, але не зачіпає систему типів.

А чи можна сказати що анотація не впливає на те як проходить компіляція? (03:24)

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

Добре, а тепер час на запитання від аудиторії. Хтось хоче щось запитати у Мартіна?

  1. Привіт, Мартін. Я прийшов у Scala з Kotlin, а не навпаки, і для мене Kotlin виглядає як “вкрадена мова”, це моя персональна думка. Кожен раз, коли моя компанія влаштовує конференцію Kotlin, люди з Kotlin говорять що за цією мовою майбутнє, а Scala помирає. Ключові гравці, такі як Twitter чи Wix, покидають Scala. То що ви можете сказати про нову Scala і про її майбутнє, тому що я справді покладаюся на вас? (04:00)

Є різниця між Scala і Kotlin; Kotlin це корпоративна мова, у них є дуже агресивний відділ корпоративного маркетингу. Вони знають що таке реклама, вони знають як її розповсюджувати, однак я такого не схвалюю. А Scala  це open source, у нас немає навіть таких співробітників, які би займалися маркетингом. У нас є певні дані, ми бачили дані з використання завантажених компіляторів. І дані, які у нас є, вказують на те, що використання Scala зростає на 20% щороку. Отже,  дана мова точно не відмирає. Якщо ви подивитеся на інші індикатори, такі як статистика курсів, то ви також побачите що Scalf займає сильне положення. Також, я очикую велике зростання, коли ми перейдемо до версії Scala 3, тому що дана мова буде кращою ніж старі версії Scala а також ніж Kotlin.  

Вже було схоже питання про Kotlin раніше, тому в мене виникло питання до аудиторії – чи багато з вас пробували працювати з мовою Kotlin? А скільки людей любить Kotlin більше ніж Scala? Ніхто не підняв руки, отож ми маємо повністю справедливий баланс між цими двома мовами. (5:49)

Цікавий результат…

Так, і Kotlin з цим нічого не може вдіяти…

Знаю. Але послухайте, Kotlin знову ж таки… Існує вислів, що імітація – це найвища форма підлабузництва, тому якщо Kotlin дійсно стане потужною мовою, то я точно це підтримаю. Kotlin же взяв багато ідей зі Scala, взагалі-то більшість ідей, за винятком лише двох помітних відмінностей: у Scala існує більше видів типів та імпліцитів. Існують також і подальші спроби додати ще до Kotlin і зробити цю мову завершеною. Загалом, я думаю що Kotlin включає в себе більше випадкових рис ніж Scala, яка є більш цілісною та меншою за розмірами мовою ніж Kotlin, та й потужнішою теж саме завдяки більшій кількості типів та імпліцитів. Однак якщо Kotlin привабить Java програмістів три четверті яких перейдуть згодом до Scala – то це добре, і я не бачу в даній ситуації конкуренції.

Отож нічого страшного не буде, якщо деякі програмісти почнуть з Kotlin а потім перейдуть до Scala?

Саме так, чому б і ні.

  1. Також було питання щодо типового програмування в середовищі dotty – в ніші у якій Kotlin слабший, я би сказав значно слабший за Scala. Питання таке: співставлення типів (match types:  https://dotty.epfl.ch/docs/reference/new-types/match-types.html – прим. перекладача) в наш час обмежені, наприклад, вони не підтримують рекурсивних визначень, та й функції переписування  знаходяться у розробці. Чи можете ви пояснити своє бачення вищезгаданого та типового програмування у середовищі dotty загалом? (07:29)

Співставлення типів точно підтримують рекурсивні визначення, ми опублікували снапшот порівняно недавно,  який в принципі могла й не бачити людина що задавала дане питання. Вони точно можуть підтримувати рекурсивні визначення. Отож типи співставлення – це головна характеристика типового програмування…

А ви б не могли коротко пояснити для тих слухачів які не знають як типи відповідностей будуть використовуватися?

Гаразд, отож співставлення типів – це коли у вас для типів є співставлення (match) по типу, і  спрацьовування відповідност (case клауза) задає вихідний тип. Кожен випадок – окремий тип, якщо ні одна case клауза не спрацювала – результуючого типу не існує. Кожен випадок розглядається коли тип перевірки є підтипом загального типу; ви можете реально відібрати один з наборів альтернатив в залежності від вашого типу перевірки. Там можуть бути рекурсивні вирази, що означає що ви можете використовувати їх щоб робити цікаві речі які у Scala2 робились імпліцитами: такі як shapeless HList (https://github.com/milessabin/shapeless/wiki/Feature-overview:-shapeless-2.0.0#heterogenous-lists ) – у dotty тип подібний до HList є стандартним типом кортежу (tuple) у Scala3. Отож якщо ви напишете кортеж (1,2,3) то ви можете розглядати його тип як HList, і тією річчю, завдяки якій це все виконається буде співставлення типів (match types). Ви можете об’єднувати кортежі в своїх операціях або обмежувати їх конкретними типами, можете вибрати елемент і так далі. Всі ці операції будуть побудовані на основі співставлення типів, і оскільки кортежи можуть бути як завгодно довгими – звичайно вам потрібна буде для цього рекурсія.

І це буде швидко.

І це буде, сподіваємося, швидко: поки що ми не бачили випадків, де б швидкість операцій над типами була-би  слабкою ланкою у ефективності (performance bottleneck). 

Чудово. Ще є питання. Джефф Майк – запитуйте.

  1. Дякую, Мартіне за найкращу мову програмування яку я використовував у своєму житті, за те що ви досі працюєте над нею і робите свій внесок. Моє питання буде про dotty: можливо воно й працює як і очікувалось, однак я бачив одну фічу, яка планувалась бути у dotty, хоч вона і розробляється далі і досі незавершена. Це – система ефектів.   Ви розглядаєте інтеграцію з cat-effects (https://github.com/typelevel/cats-effect ) чи ZIO (https://github.com/scalaz/scalaz-zio ) чи з чимось іншим корисним і як це вплине в подальшому на Scala? (10:01)

Дякую за запитання. Вся річ у часі – ми дуже близько від  Scala 3 і для даного релізу ми свідомо обмежили себе і хочемо досягти чіткої простоти або значного обмеження в речах які ми не використовували досі щоб не зловживати ними у майбутньому. Мотивацією для цього може стати той факт, що Scala 3 – це великий скачок від Scala 2, і буде кілька речей які зміняться. Відповідно зрештою усі книжки та посібники (якщо вони не самі-самі прості) будуть переписані, так як зараз існує багато кращих способів робити те що в scala2 було по-іншому. Приміром, багато простих ієрархій класів можуть зараз бути виражені перелічуваними типами даних (https://dotty.epfl.ch/docs/reference/enums/enums.html) , які не існували у Scala2. Відтак, навіть книжки для початківців повинні бути переписані; ми хочемо розповісти людям про ці перелічувані типи, так як це набагато простіший спосіб – виразити ті ж самі речі класами. Все це значить що головні речі, спрощення та важливі обмеження повинні бути у Scala 3. . Зараз у нас і так багато речей які треба зробити у Scala версії 3.0, а решта ввійде у стандарт в пізніших версіях і вплине на подальший розвиток мови. У цьому ми дуже зацікавлені, і я думаю, що наш шлях багатообіцяючий, і ми ще будемо працювати над цим. Однак всі ці речі не з’являться у Scala 3.0, вони будуть у, скажімо, Scala 3.5 чи Scala 4.

Я гадаю що було ще питання коли вийде реліз dotty? (12:40)

Так, гаразд. Отож, по плану у нас заморозка функціоналу цього року, ми сподіваємось літом цього року. Зараз розробники на стадії метапрограмування та типового програмування, вони продовжують працювати, просто щоб все опрацювати нам треба більше часу. Незважаючи на це, решта мови вже в порядку, допрацьована і нам треба десь 1 рік для стабільного релізу. А це, в свою чергу, означає роботу над реалізацією, роботу над помилками, роботу над портуванням бібліотек, роботу над технічною документацією і тд. Це означає, що реліз буде в 2020 році, а коли точно ще невідомо. З оптимістичної точки зору, ця подія має відбутися знову ж таки влітку 2020 року, але може і зміститися на трохи пізніше. Побачимо як воно буде. І ще одне – заморозка функціоналу означає що у нас вже з цього літа буде досить стабільна попередня версія для розробників, тому якщо ви хочете підготуватися до неї та випробувати, портувати бібліотеку чи випробувати мову у додатках то знайте – ми не будемо вносити зміни в мову в останній момент. Екосистема потребує часу для переходу, тому якщо ви, скажімо, залежите від інших бібліотек, то у вас буде можливість працювати з ними через рік.

Гаразд, наступне питання з середини аудиторії, візьміть будь ласка мікрофон

  1. Чи можливо додати вивід типів для локальних чи внутрішніх функцій щоб не 

писати типи для аргументів функцій та зворотніх типів, хоча би для внутрішніх та локальних функцій? Чи можна це зробити у dotty або хоча б зробити якийсь вид typed holes? Дякую. (14:26)

Вже була дискусія на цю тему, чи добре це чи погано, так як зробити це доволі легко. Комітет зі стандартизації (SIP комітет: https://docs.scala-lang.org/sips/minutes-list.html) не переконали що це хороша затія, і ми зрештою вирішили, що цього ми не чіпатимемо, тому що якщо спитати початківця чи нову людину чи взагалі будь-кого – вони скажуть що краще писати типи параметрів. Звичайно, це більше рядків коду, але це й зрозуміліше. В інших же ситуаціях де постає таке питання нам треба більше часу для рішення. Впровадити зміни можна доволі легко, але не зовсім зрозуміло чи взагалі варто це робити. З цим і погодилися члени SIP комітету, і хоча дехто думав: “а чому б і ні?”, як я вже сказав, ми повинні всі погодитися щоб такі речі були впроваджені.

Тобто ця ідея не повністю відкинута?

Так, не повністю, але цього не буде у версії 3.0

  1. Невелике питання – чи не могли б ви його сховати за прапорцем чи зробити щось подібне? (15:58)

SIP комітет вирішить чи це буде здійснено.

Так.

Це просто пропозиція.

Далі питання від людини у жовтому.

  1. Привіт, Мартіне. Повертаючись до нашого порівняння з Kotlin, що ви думаєте  про співпрограми і чи є плани зробити щось подібне у Scala? (16:15)

Так, співпрограми це непогано і я думаю що нам варто це зробити. Тут я би заохочував людей збиратися разом і щось робити. Насправді існує дуже вдалий спосіб створювати співпрограми у Scala, однак я не впевнений чи він не застарів і чи можна це буде перенести на dotty. Це робота Алекса Прокопека  ( http://storm-enroute.com/coroutines/). Він дуже добре ввів ці співпрограми, і можливо ми можемо їх адаптувати, хоча я особисто зараз фокусуюся на самі мові програмування, а от такі співпрограми виглядають більше як змішування середовища виконання та бібліотек, підтримки середовищ та бібліотек. Як би там не було, я підтримую такі починання тому що мати хороший спосіб читання асинхронних розрахунків дуже важливо, а ще так можна уникнути плутанини при додаванні нових функцій у майбутньому, тощо.

  1. Добре, ще є злегка таємниче питання яке нам прислали раніше. Мартіне, чи має фраза “стабільна рівновага” якесь важливе значення для тебе? Якщо так, то що конкретно це значить? Стабільна рівновага. (17:38)

Фраза стабільна рівновага може означати багато чого…

Так, думаю, вам варто читати між рядків. Чи є зараз у аудиторії людина, яка задала це питання? Марко, ти міг би уточнити? Дайте йому мікрофон.

Привіт, Мартіне, дякую тобі за твою працю. Моє питання таке: чи будуть у Scala чисто залежні типи?

Вибачте, я хотів би щоб Марко спочатку уточнив про його питання щодо стабільної рівноваги, а вже потім ми перейдемо до вашого питання. Вибачте.

Добре. Я чув що ти використовував фразу “стабільна рівновага” більше одного разу, а іноді вона йшла і від аудиторії що задавала тобі питання, тому я подумав: а чи значить ця фраза для тебе взагалі щось конкретне?

Я не пам’ятаю точно коли я таке говорив і у якому контексті, це могло значити багато речей. Однак зараз я не можу пригадати нічого конкретного.

Так, тому я і сказав що це питання таємниче.

А тепер ми можемо повернутися до того неочікуваного питання, будь ласка. Три ряди назад, озвучте ваше питання ще раз.

  1. Моє питання було про залежні типи у Scala – чи будуть вони у dotty чи наступних релізах? (19:36)

Тобто це чисто dependent types, а не path-dependent які на даний момент у нас є. Якщо зайти трохи далі ніж сучасна Scala у сенсі залежних функціональних типів, то ми можемо використовувати в роботі методи які залежать від типів параметру і віднести їх до функціональних типів. Це переносить нас трохи далі, до чисто залежних типів, але це не є кінцевою метою, бо це дуже широка категорія. Існує багато способів збагатити чисто залежні типи, і звичайно дослідження таких речей має бути на порядку денному. Тепер таке варто досліджувати, а це означає що у вас не буде чіткого плану дій і ви не будете нічого обіцяти; однак це точно це чим цікавляться люди, зокрема люди у моїй лабораторії. Я б сказав що дуже цікавими є і залежні {dependent} і уточенні {refinement} типи. Останні є такими типами до яких можна додати чи прикріпити предикати. Це ніби контракти але реалізовані через компільовані типи а не через середовище. Отож, ці два види досить цікаві і взагалі-то взаємозв’язані у Scala 3.

Дякую, Мартіне. Чи хтось скаже мені, скільки часу у нас лишилося? Руслан, ти не знаєш? Близько десяти хвилин? Добре, отож давайте наступне запитання.

  1. Привіт Мартіне і Юрію, моє питання про майбутнє SBT у контексті dotty. Я використовую Gradle для створення Scala додатків так як у багатьох випадках так швидше та простіше. То що ви скажете про майбутнє SBT? (21:36)

Мені важко сказати так як існує велика кількість професійних інструментів, а це лише один з них, хоч і найбільш використовуваний. Я вважаю, що нам треба залишатися нейтральними, а не схилятися на чиюсь сторону. Якщо так швидше – гаразд, це чудово. Були спроби центру Scala підтримати ідею Gradle щодо інкрементної компіляції та втілити її в життя. Тим не менше, я вважаю що нам важливо лишатися безпристрасними. Наприклад, багато підприємств використовують Basel, а це теж дуже хороший спосіб, це непогана альтернатива SPT. Я би сказав, сьогодні цей напрямок розвивається, і можливо у майбутньому щось визначне з’явиться взагалі з забутого, приміром fury, і завоює світ. Тому я наполягаю на об’єктивності.

Дякую, Мартіне, я це ціную. Я гадаю, що сьогодні ще говоритимуть про Basel, і згодом я сам говоритиму про fury. На цій конференції говоритимуть і про інструменти Bill, і ви можете відвідати такі розмови. Але давайте повернемося до запитань.

  1. Привіт, Мартіне, мене звати Володимир. На початку розмови ви говорили що зловживання анотаціями це погана річ, тому у новій Scala у вас багато ключових слів. А як щодо метапрограмування – перевикористання метапрограмування це також погана практика чи ні? (23:19)

Так, я сказав би що у більшості випадків не варто цього робити, це очевидно. Питання лише у використанні найпростішого інструменту що може виконати те що потрібно. У мене таке враження, що метапрограмування часто використовується там, де треба використати прості інструменти. Іноді до цього треба вдаватися, однак я думаю що метапрограмування відноситься до тієї ж сфери як і імпліцитні конверсії, які на перший погляд виглядають зручними, хоча насправді часто їх використання є зловживанням, тому потрібно робити це якось інакше. Ось таке моє ні разу не професійне бачення даної ситуації, я просто так відчуваю. Відтак я сказав би що ми повинні намагатися використовувати менше абстракцій у метапрограмуванні і зберігати мову більш послідовною, тому що в іншому випадку ми ризикуємо повестися на те, що люди іноді називають list curse. Це ситуація, коли кожен пише своєю власною мовою, у кожного є своя власна купа інструментів, але водночас люди не можуть знайти між собою спільні точки дотику.

Дякуємо за рівновагу у вашій точці зору.

  1. Давайте я зараз запитаю те, що нам прислали раніше. Це питання трохи відрізняється від попередніх. Хтось цікавиться, чи ти слухаєш музику коли пишеш код, і якщо це правда, то яку музику ти слухаєш (якщо це, звісно, не секрет)? (24:52)

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

  1. Зрозуміло. А це питання заглядує трохи далі у майбутнє – яким буде твій наступний крок після dotty? (25:21)

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

А коли ми отримаємо специфікації мови Scala 3?

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

Гаразд. Чи є ще питання з аудиторії? Так, ви на задньому ряду.

  1. Привіт. Я думаю що всі прибічники Scala багато використовують монади, тому моє питання таке: чи маєте ви плани щодо покращення for синтаксису чи хоча б зробити його ближчим до Haskell do-нотації? (26:33)

А у вас є якісь конкретні пропозиції як for синтакс може бути вдосконалений ?

Ну наприклад, зробити підкреслення необов’язковими у випадку якщо нас не цікавить результат монади.

Так, маю на увазі що процес SIP відкритий, кожен може внести свою пропозицію, люди повинні працювати над специфікаціями і впровадженням таких речей. звичайно, ми відкриті для цього, однак наш план дій досить негнучкий, тому я думаю що розширення for синтаксиса точно не спростить мову.  Кожна нова функція поставить таке питання: чи дасть мені нова функція те, що уможливить простіше пояснення для новачка що таке Scala чи це просто додатковий функціонал. Якщо це додатковий функціонал, то його ми додамо у версії 3.1, 3.2 чи 3.3, але не у версію Scala 3.0. А покращення for  якраз і відносяться до подібних речей, і в нас буде час щоб пізніше їх додати, але не зараз.

  1. Дякую, Мартіне. Здається, у нас залишилось лише кілька хвилин, тому давайте прозвучить ще одне питання яке напевне потребує глибокої технічної відповіді. Мартіне, що ти думаєш про когерентність типових класів, чи повинні вони бути когерентними, або у нас має бути можливість залишити типові класи некогерентними? (28:05)

Зрозуміло. Ми багато думали над цим питання, і зрештою наша відповідь це тверде ні, ми не хочемо когерентність тайпклассів. Зараз у новій мові у нас є чудова схема щоб усувати локальну неоднозначність, а це означає що ви більше не повинні зациклюватися на речах які є у монадах та аплікативах – коли якщо в вас map неоднозначний, то ви нічого з цим не можете зробити. Я вважаю, що тотальна когерентність явно антимодульна, так як вона припускає лише одну реалізацію тайпклассу у всій програмі.  Відтак, якщо ви вже написали хоч слово у програмі, ви вже досягли антимодульності, такий спосіб не є модульним. У модульному же способі немає програми але є компоненти, які можна скласти у більші сутності, тому це щось на кшталт метаданих. Іншою дуже практичною річчю є той факт, що Haskell, на мою думку, має свою культуру, яку ми можемо оминати завдяки великій кількості нових типів. В Haslell, якщо ми хочемо змінити функціональність але не маємо типу щоб це зробити, то ми додаємо новий тип BR та дуже складні речі, які треба впорядкувати і  зберегти якомога більше операцій по даному типу без надлишкової шаблонності. І звичайно ж, таким чином досягається локальна оптимальність. Одначе я вірю, що по своїй суті, така ситуація не є сприятливою для Scala тому що, знову ж таки, це антимодульність. Ви повинні відокремити такий тип від операцій по ньому, а от Haskell не дає такої можливості, так як Haskell не має модульної системи. Відтак, вони змушені діяти інакше, але рух у такому напрямку є природнім для них. Ми ж не повинні це копіювати.

Гаразд, тут все зрозуміло. Чи залишились ще питання в аудиторії? Десь мікрофон пропав… а, ось і він. Я думаю що це буде останнє питання та й будемо закінчувати. Прошу.

  1. Привіт, Мартіне. Зазвичай коли людина працює над певним проектом багато часу, то вона стає спокійнішою чи щось таке. Тому мені й цікаво, де ви берете енергію для всіх ваших починань? (30:28)

Чудове питання щоб закінчити сьогоднішню розмову.

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

Дякую, думаю це була чудова відповідь. О, ще щось є у Віктора.

  1. Привіт, Мартіне. Чи маєш плани відвідати Київ наступного року, року Scala? (31:13)

Можливо.

Можливо. Дякую, Мартіне що був з нами і вибач що все вийшло так спонтанно.

Без проблем, мені з вами сподобалося, добре що ми поспілкувалися.

І вибач що аудиторія змусила тебе чекати, це мій прорахунок. Дуже тобі дякую ще раз, і давайте всі востаннє подякуємо Мартіну аплодисментами.

 

Умовні позначення шрифтами:

Коментарії/репліки/питання ведучого

Питання/репліки з аудиторії

Відповіді/коментарії Мартіна

 

Leave a Reply

Your email address will not be published. Required fields are marked *