Уверен, хотя не думаю что смогу вам привести подробности 6-летней давности.
А на чём базируется ваша уверенность?! Я - грешным делом - с Erlang знаком хорошо. И ваше утверждение что проблема в "копировании binary" - лично для меня выглядит ну очень странно.
Binary (это вот "такое" <<>>... вы же про него?) - отдельный, специальный тип данных. Он - by desing - сделан так, чтоб избежать копирования в пределах VM. И то, для чего Erlang и был придуман, как бы и есть обработка "непрерывного потока" binary. Поэтому - "странно всё это" (с)
Или возьмите второй пример и сделайте так чтобы он работал в 5-10 раз быстрее. Это будет конструктивно и интересно
Дык вся "прелесть" в том, что вы - как иллюстрацию - почему-то взяли решение, которое - в принципе - в декларативном виде выглядеть будет плохо.
Три варианта сравнения я имел в виду эти: ==, === и сам equals, можно еще и Objects.equals добавить.
Да я-то понял, что вы имели в виду. Я пытаюсь до вас донести, что вы не правильно всё понимаете :-)
Вот, кстати, Objects.equals весьма показателен. Помните, как и, главное, почему этот "костыль со стразами"(tm) таки добавили в? Может не так уж всё "чётко и понятно"?
Каша получается особенно из-за того, что == и === имеет координально другой смысл от общепринятых. == устоканилось как проверка ссылки ...
Ну ок... допустим, вы правы и "== устоканилось как проверка ссылки". Так ведь и в Kotlin == - если специально ничего "такого" не делать - это будет "проверка ссылки". Нет? Что не так-то?! В чём "координально другой смысл"?
Но, на всякий... лучше, имхо, открыть таки спеку Java, и убедиться, что оно и там не "устоканилось". Ну и JEP почитать. Там много интересного и про "кашу", и про "чётко и понятно" в плане equality check в Java.
Я сравниваю котлин с джавой (и рассуждаю, почему один удобнее другого), для меня джава - основа, которую пытается улучшить котлин ...
Я вижу ваши эмоции. В конце концов, "равно-равно-фобия" и мне - в каком-то смысле - не чужда :-) Но, реально, видеть в == в Kotlin какой-то "координально другой смысл"?! Ну, такое, имхо.
Во-первых, это нормально для такого популярного языка ...
Вы гляньте, просто, насколько "оно" в отрыве по просмотрам от остальных вопросов по Java. Имхо, как-то НЕ нормально для того, что должно бы быть - по вашим словам - "чётко и понятно". Нет?
Строки, кстати, это хоть и, наверное, самый показательный case, но же далеко не единственный в этом плане.
Integer.valueOf(10) == Integer.valueOf(10); // Тут будет true
Integer.valueOf(1000) == Integer.valueOf(1000); // А тут - внезапно - нет
Правде же, всё "чётко и понятно"? :-) Это на вскидку, просто.
... у Котлина точно так же хрен догадаешься, что есть ===.
?!
a === b evaluates to true if and only if a and b point to the same object.
Какое именно слово вам не понятно в этой фразе?!
Ну допустим, вы первый раз увидели === в коде. Пойти глянуть в спеку на предмет "что это значит", имхо, стандартный же вариант. Нет?
Да и пост этот закрыт для редактирования, не могут там ничего дополнять каждый год.
Вы опять, похоже, не разобрались. Пост "закрыт" для редактирования "кем попало". Давно уже. Но, это не значит, что представители stackoverflow community не могут дополнять/редактировать уже данные ответы. Собственно, это и происходит. Последний раз ответ дополнялся в ноябре.
Каша со сравнением классов: в Джаве четкое и понятное разделение на == и equals, что очень удобно.
:-) "Каша", совсем не там, где вы думаете. В "Джаве" всё настолько "чётко и понятно", что на какой-нибудь JEP 401 - с его попытками скрестить ежа и ужа== и equals - смотреть без слёз, лично у меня уже не получается.
В Котлтне же появляется ещё и третье равно.
Ничего "третьего" в Kotlin, внезапно, нет. Это, конечно, если взять и разобраться.
Грубо говоря, в Kotlin == - это "инфиксный эквивалент" equals. Работает (в смысле, вызывает equals), внезапно, даже с Java классами :-)
Рабочая и логичная система просто заменена на отсебятину.
Если знать про ЯП чуть больше, то окажется, что в Java с equality "отсебятины" как бы не больше, чем у всех других вместе взятых :-) У неё с этим всё настолько "чётко и понятно", что "тот самый вопрос" в топе по просмотрам сколько я себя помню. И каждый год туда таки что-то да дописывают :-)
Путаницы в Джаве нет, потому что Джава для Котлина как основа, не наоборот.
Это, имхо, самое главное заблуждение относительно Kotlin. Java - как язык - если и оказала на Kotlin какое-то влияние - то в каких-то минимальных дозах - типа "блоки через скобочки" и т.п. (и то, потом окажется, что это не Java, а какие-нибудь "плюсы").
Несравнимо большее влияние на синтаксис Kotlin - по словам самого Бреслава - оказал "ML (через Scala)" - все вот эти "постфиксы", val'ы и прочие fun'ы - это как раз оттуда. Один из первых "лозунгов" Kotlin, емнип, как раз и было: "Лучше чем Java. Проще чем Scala".
По факту, единственное, что сейчас связывает Kotlin и Java - это интероперабельность и, собственно, JVM.
Ну а Kotlin - уже далеко не только (да и не столько) JVM.
P.S. По личным наблюдениям, раздражение от "не так, как в Java" возникает только у тех, у кого в background'е, собственно, только Java и есть. Для тех, для кого Kotlin не второй ЯП - с этим проблем вообще нет никаких.
Ну вот выше были "задачи сортировки" c - условного - leetcode. С "практикой" - более менее понятно. Что за "теория"?
Или это был риторический вопрос? Тогда прошу прощения, не понял
Нет. Это не риторический вопрос.
Вот "научился" я - например - десяти разным способам сортировок. Даже - предположим - я знаю и понимаю области применений этих - конкретно этих - "решений". Т.е. я без проблем смогу их воспроизвести, рассказать "что-по-чём" в рамках каждого конкретного "решения" и т.п. Я - типа - "мастер вот этих вот десяти способов сортировки".
Упустим, что это дает лично мне. Важно, что это дает "нанимателю"? Т.е. вот кроме того, что он теперь знает, что я могу и "так", и "сяк" и ещё восемь разных "-як".
Ну почему же? У вас есть два кандидата, оба показали все одинаковое, но в алгоритмической секции результаты разные ... :)
Ну ок. Вот есть я - "такой красивый". Но, не могущий "обобщить" свои "знания" до - допустим - задач поиска. А рядом - не менее красивый - "мастер вот этих вот пятнадцати способов поиска", который не умеет в сортировку.
Дальше что?
Плюс надо понимать, что задачки показывают ...
"Задачки"-то, может и показывают. "Алгоримы"-то - сиречь, конкретные решения - тут причем?
При всей "ремесленности" нашей области деятельности, т.н. "алгоритмические задачи" ведь даже не являются в ней типовыми.
Если он учится их решать - это развивает его "думалку" ...
Что значит "учится их решать"?! Как? На основе чего?
Есть разница между "протыкать" задачи сортировки (пусть даже - сложные) на каком-нибудь, условном, leetcode, и усвоить третий том Кнута? Нет?
Насмотренность тоже полезна ...
Разве кто-то с этим спорит?! Речь о её ценности. Если хотите, о её пригодности в использовании в качестве меры. Т.е. - даже если для "реципиента" есть какая-то польза (условное, "развитие думалки") - то пригодность такого рода "насмотренности" в качестве меры - имхо - около нулевая.
Вот мы, или они, ищем программиста. Вот как его проверить?
Если вот вам - т.е. непосредственно вам - нужен программист, вы разве не знаете как вам его проверить?! Проблема - которую затрагивает автор - она вообще не про это, имхо.
Вот я не применяют в работе напрямую - значит мне не надо. А то, что это сформировало твое мышление и ты уже полузуешься чем-то не особзнавая этого - это не важно.
Кто бы спорил за "мышление" и его "развитие"... вот только мой личный опыт мне "шепчет", что освоение - например - теории сложности вычислений - вполне может, если и не "сформировать твое мышление", то уж точно на это "мышление" повлиять. А вот знание (причем весьма условное "знание", в подавляющем большинстве случаев) конкретных решений конкретных задач - очень сильно вряд ли.
В этом смысле, "алгоритмы" - сугубое имхо - это такой аналог насмотренности у каких-нибудь, условных, "дизайнеров". Весьма условный, надо понимать, аналог... но, с ровно такой же "ценностью для".
А мне по сути статьи непонятно, чем же новый Gradle Declarative отличается от «классического» Gradle?
Всё достаточно просто... основная мотивация в том, что бы отделить "скрипты" от "конфигураций". Идея в том, что будет круто, если в "большинстве случаев" разработчики будут оперировать "конфигурацией" - исключительно понятными им "концептами" (приложение, библиотека, версия, тестовое окружение и т.п.). А в "меньшинстве случаев" - они станут т.н. "build инженерами" - ну или позовут таковых на помощь - и допишут всё что "им надо" через "скрипты".
Про build инженеров...
Gradle - исторически - делит всех своих пользователей на две большие группы. Разработчиков ПО и т.н. build инженеров. Первых сильно больше, чем вторых. Но для вторых, ценность "гибкости" Gradle сильно выше всего остального.
Далее, "конфигурация" (как набор описаний тех самых "концептов") - по своей сути - декларативна. И это приводит нас к мысли, что это "будет круто" не только для разработчиков, но и для всякого рода интеграций... например, с IDE - которой, при наличии такой "конфигурации" не нужно будет "парсить в уме" 100500 "скриптов", чтоб построить, условно, содержимое classpath для "вот этого модуля". Как-то так.
Если говорить о текущей реализации, то - на данный момент - это всё выражается в том, что появился ещё один DSL (в добавок к .gradle и .gradle.kts) - .gradle.dcl. В нём - таки да - запрещены всякие "императивные штучки" типа циклов, ветвлений и т.п.
То что tasks будут запрещены? Или что их теперь надо всегда в plagin реализовывать?
Формально - да, в .dcl - "таски" и "всё вот это вот" - нельзя.
Но, как обычно - в рамках проекта - эти (.gradle, .gradle.kts и .gradle.dcl) DSL можно "миксовать". Например, вполне норм, когда settings.gradle.dcl и - при этом - build.gradle.kts. Или в "корне" .gradle.kts, а в модулях .gradle.dcl. Ну и т.д. до штатного использования buildScr и build-logic.
По поводу самого .dcl - он всё-таки пока ещё "сыроват" - что не удивительно - но "играцца" уже вполне себе модно. Хотя сама по себе идея, имхо, годная.
Если сильно интересно, то можно "поискать по блогам"... как раз под конец прошлого года (когда был анонс DG) было весьма много статей как раз от "build инженеров", основной посыл которых сводился к "руки прочь" и т.п. Но на данный момент - когда всё это более мнее прояснилось - особых возражений за "ещё один DSL" вроде как нет.
Что DG, что Amper - есть результат последнего коллаба JB, Gradle и Google с целью: "... put most of our attention into declarative software definition".
Ну и standalone "движок" Amper'а - он же, практически, "вчера только" вышел. И чем оно закончится - подозреваю - и сами JB до конца пока не понимают. Весь MP "покрыть" - это не так просто, как кажется/хочется.
Так что, не буду сильно удивлен, если - в конце концов - у Amper под капотом окажется как раз DG...
Имя метода обычно содержится в сообщении, в той или иной форме.
Это только если какой-то аналог RPC делается. Сообщение это данные. Обычно, если там и есть имя - это тип этих данных. Но ни как не тип потребителя этих данных. Тем более, что обработчик - вообще говоря - может быть и не один.
Достаточны только завтипы, и то не факт.
С одной стороны, хочется уточнить: достаточно для чего? А с другой - формализмы зав. типов - это "охренеть как смело" (с) :-)
Кроме того, вы так и не показали, что ваш формализм лучше.
Мой это какой?! Я - вроде как - никаких новых формализмов не вводил.
Примерно соответствующий (в вашей аналогии) сигнатуре метода в ООП
Каким образом?! Я ещё могу представить, как из "здоровенной схемы, описывающую сообщение" выводятся функциональные типы. Это не сложно. Но, что они вам дадут?! Что бы "выйти" на методы нам нужны имена. А тут они - буквально - любые.
Ну так оно и формализовано в большинстве языков, в виде интерфейсов...
Только на уровне формализма подтипа. Его - чаще всего - не достаточно. Поэтому там где нужных формализмов в языке нет, возникают всякого рода "техники программирования", которые переносят их (недостающие формализмы) на уровень реализации.
Смотрите... вот у нас есть обычные типы (что бы это не значило). А есть функциональные типы. Какая между ними "разница"? Достаточно ли будет сказать, что функциональные имеют более высокий порядок? И в чём разница между типами разного порядка?
Или - с другой стороны заход - есть тип, а есть его экземпляры (что бы это не значило). Вот представьте себе эдакий НЕХ - экземплярами которого являются типы. Какая между ними разница? Мы на уровне типов даже выразить этот НЕХ (да... это про категорию типов) не сможем :-(
Т.е. эти вот "протоколы"/"поведения"/"классы типов" - это всё про "ограничения", которые накладываются не на уровне самих типов. Это про ограничения уровнем (я порой и не одним) выше, так сказать.
Когда вы реализуете "интерфейс", вы - фактически (через subtyping) - накладываете ограничения на [используемые] типы. С одной стороны, это вроде как "то, что нужно". А с другой - очень часто, это "не те" (либо слишком строгие, либо слишком слабые) ограничения, которые мы (на самом деле) хотим. По большому счету - это из-за того, что сам "интерфейс" - это тоже тип. Соответственно, он и описывается исключительно в "терминах" типов, со всеми их ограничениями. Даже если притащить сюда ещё и параметрический полиморфизм, то ограничения на параметры обобщенного типа - всё равно описываются в терминах типов. Не вырваться :-(
А если мы будет - по сути - тоже самое делать "уровнем выше", то никаких проблем такого рода у нас просто не будет.
Если идти дальше, то это уже какой-то "код" надо будет писать, чтобы показать "разницу". Оно надо?
Какой "объем знаний о получателе" это нам добавляет?
... плюс описание в документации, что этот получателе делать должен.
:-) А это точно нужно знать отправителю?!
Потому что если не знаем - то смысла посылать?
Например, потому что "что, куда и когда" определяется не отправителем (и не получателем), а протоколом. Точнее, контекстом, в котором сейчас находится отправитель, и протоколом, который этим самым контекстом задается.
Если вам удобнее смотреть на это (контекст и протокол) через призму "интерфейсов", то упрощенно это можно представить себе некоторый медиатор (в терминах GoF).
Так что знание таки всегда есть, пусть и не формализованное в языке.
Ну вот и представьте, что это таки может быть "формализованное в языке".
Ну то есть, исключительно такие, в которых можно спросить компилятор "а это всё вообще имеет смысл?" ...
Если я правильно понял о чём речь, то "компилятор" - сам по себе - тут вообще не при чем. Статический анализ применим и к языкам с динамической типизацией. Главное, чтоб она (типизация) строгой была.
Но я-то не про типизацию... я про связывание (binding). Оно - вообще говоря - ортогонально типизации.
На самом деле, это охренеть какое преимущество :-)
Всё же как программист вы обязаны знать хоть что-то о получателе ведь иначе с чего бы вам вообще пришло в голову посылать это сообщение?
Зачем?! Если "на пальцах": что вы "знаете" о получателе, когда отправляете сообщение, например, в какой-нибудь exchange AMQP брокера? Ну или, когда добавляете запись в какой-то topic kafka - вы много "знаете" о том, кто будет эту запись потом "читать"? А когда уже вы читаете запись и топика, вы что-либо "знаете" об "отправителе"? Зачем это вам?!
Кроме того, если такой свойство действительно необходимо - оно спокойно реализуется интерфейсами.
Ну, нет. "Интерфейсы" (а точнее, их реализация) - это просто "вот такая вот" форма subpyping'а. А protocol'ы smalltalk'а, behaviour 'ы erlang'а и прочая, и прочая - это не subtyping ни разу.
Я в одном, пожалуй, соглашусь... если рассматривать исключительно "статические" системы, то такого рода преимущество не совсем очевидно. Ну действительно - "зачем козе баян", если "всё, что может быть" мы и так уже описали "до того как".
Но как только вы перейдете к "динамическим" системам - полезность "такой штуки" становится более чем очевидна. Представьте себе, что у вас "рождаются и умирают" не только экземпляры типов, а сами типы - "рождаются и умирают".
Попробуйте посмотреть на ООП не как оно есть мейнстримно, а как оно было в оригинале - то, что Алан Кей сделал в Smalltalk.
Про "как" и "почему так", Алан "сделал в Smalltalk" лучше, имхо, почитать у самого Алана. Благо его The Early History of Smalltalk давно есть в сети. Очень познавательно.
Вот вам цитата. Это прям самое начало... даёт представление о "какую проблему решаем".
Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment ...
Но лучше самому почитать, имхо. Там не много...
Т.е. посылка сообщений.
"посылка сообщений" - aka message passing - это то, что, в конечно счете, станет решением для этой самой "small scale one". То, что он сам потом назовет "extreme late binding of all things".
А на чём базируется ваша уверенность?! Я - грешным делом - с Erlang знаком хорошо. И ваше утверждение что проблема в "копировании binary" - лично для меня выглядит ну очень странно.
Binary (это вот "такое" <<>>... вы же про него?) - отдельный, специальный тип данных. Он - by desing - сделан так, чтоб избежать копирования в пределах VM. И то, для чего Erlang и был придуман, как бы и есть обработка "непрерывного потока" binary. Поэтому - "странно всё это" (с)
Дык вся "прелесть" в том, что вы - как иллюстрацию - почему-то взяли решение, которое - в принципе - в декларативном виде выглядеть будет плохо.
Канонически, тут "поиск простых чисел" делается - вот буквально - на "решете" и ленивых последовательностях. И память не жрет, и работает быстро.
первые две строки :-)
При всём уважении, это - какой-то сумбур :-(
Начиная от "функциональный" и "довольно слабой" типизации c "присвоением", и до примеров кода, который ужасен. Даже разбирать не хочется.
Но...
Уверены, что проблема была именно в этом? Что bin_opt_info выдавало? Dialyzer что показывал?
Ну просто, чтоб заставить BEAM копировать binary - это прям специально стараться надо... и то, не факт, что получится.
Да я-то понял, что вы имели в виду. Я пытаюсь до вас донести, что вы не правильно всё понимаете :-)
Вот, кстати, Objects.equals весьма показателен. Помните, как и, главное, почему этот "костыль со стразами"(tm) таки добавили в? Может не так уж всё "чётко и понятно"?
Ну ок... допустим, вы правы и "== устоканилось как проверка ссылки". Так ведь и в Kotlin == - если специально ничего "такого" не делать - это будет "проверка ссылки". Нет? Что не так-то?! В чём "координально другой смысл"?
Но, на всякий... лучше, имхо, открыть таки спеку Java, и убедиться, что оно и там не "устоканилось". Ну и JEP почитать. Там много интересного и про "кашу", и про "чётко и понятно" в плане equality check в Java.
Я вижу ваши эмоции. В конце концов, "равно-равно-фобия" и мне - в каком-то смысле - не чужда :-) Но, реально, видеть в == в Kotlin какой-то "координально другой смысл"?! Ну, такое, имхо.
Вы гляньте, просто, насколько "оно" в отрыве по просмотрам от остальных вопросов по Java. Имхо, как-то НЕ нормально для того, что должно бы быть - по вашим словам - "чётко и понятно". Нет?
Строки, кстати, это хоть и, наверное, самый показательный case, но же далеко не единственный в этом плане.
Правде же, всё "чётко и понятно"? :-) Это на вскидку, просто.
?!
a === b evaluates to true if and only if a and b point to the same object.
Какое именно слово вам не понятно в этой фразе?!
Ну допустим, вы первый раз увидели === в коде. Пойти глянуть в спеку на предмет "что это значит", имхо, стандартный же вариант. Нет?
Вы опять, похоже, не разобрались. Пост "закрыт" для редактирования "кем попало". Давно уже. Но, это не значит, что представители stackoverflow community не могут дополнять/редактировать уже данные ответы. Собственно, это и происходит. Последний раз ответ дополнялся в ноябре.
:-) "Каша", совсем не там, где вы думаете. В "Джаве" всё настолько "чётко и понятно", что на какой-нибудь JEP 401 - с его попытками скрестить
ежа и ужа== и equals - смотреть без слёз, лично у меня уже не получается.Ничего "третьего" в Kotlin, внезапно, нет. Это, конечно, если взять и разобраться.
Грубо говоря, в Kotlin == - это "инфиксный эквивалент" equals. Работает (в смысле, вызывает equals), внезапно, даже с Java классами :-)
Если знать про ЯП чуть больше, то окажется, что в Java с equality "отсебятины" как бы не больше, чем у всех других вместе взятых :-) У неё с этим всё настолько "чётко и понятно", что "тот самый вопрос" в топе по просмотрам сколько я себя помню. И каждый год туда таки что-то да дописывают :-)
Имхо, если говорить о Kotlin Contracts, то сильно не хватает ссылки на соответствующий KEEP
Это, имхо, самое главное заблуждение относительно Kotlin. Java - как язык - если и оказала на Kotlin какое-то влияние - то в каких-то минимальных дозах - типа "блоки через скобочки" и т.п. (и то, потом окажется, что это не Java, а какие-нибудь "плюсы").
Несравнимо большее влияние на синтаксис Kotlin - по словам самого Бреслава - оказал "ML (через Scala)" - все вот эти "постфиксы", val'ы и прочие fun'ы - это как раз оттуда. Один из первых "лозунгов" Kotlin, емнип, как раз и было: "Лучше чем Java. Проще чем Scala".
По факту, единственное, что сейчас связывает Kotlin и Java - это интероперабельность и, собственно, JVM.
Ну а Kotlin - уже далеко не только (да и не столько) JVM.
P.S. По личным наблюдениям, раздражение от "не так, как в Java" возникает только у тех, у кого в background'е, собственно, только Java и есть. Для тех, для кого Kotlin не второй ЯП - с этим проблем вообще нет никаких.
Ну вот выше были "задачи сортировки" c - условного - leetcode. С "практикой" - более менее понятно. Что за "теория"?
Нет. Это не риторический вопрос.
Вот "научился" я - например - десяти разным способам сортировок. Даже - предположим - я знаю и понимаю области применений этих - конкретно этих - "решений". Т.е. я без проблем смогу их воспроизвести, рассказать "что-по-чём" в рамках каждого конкретного "решения" и т.п. Я - типа - "мастер вот этих вот десяти способов сортировки".
Упустим, что это дает лично мне. Важно, что это дает "нанимателю"? Т.е. вот кроме того, что он теперь знает, что я могу и "так", и "сяк" и ещё восемь разных "-як".
Ну ок. Вот есть я - "такой красивый". Но, не могущий "обобщить" свои "знания" до - допустим - задач поиска. А рядом - не менее красивый - "мастер вот этих вот пятнадцати способов поиска", который не умеет в сортировку.
Дальше что?
"Задачки"-то, может и показывают. "Алгоримы"-то - сиречь, конкретные решения - тут причем?
При всей "ремесленности" нашей области деятельности, т.н. "алгоритмические задачи" ведь даже не являются в ней типовыми.
Ну т.е. важно не само "решение". Так?
Что значит "учится их решать"?! Как? На основе чего?
Есть разница между "протыкать" задачи сортировки (пусть даже - сложные) на каком-нибудь, условном, leetcode, и усвоить третий том Кнута? Нет?
Разве кто-то с этим спорит?! Речь о её ценности. Если хотите, о её пригодности в использовании в качестве меры. Т.е. - даже если для "реципиента" есть какая-то польза (условное, "развитие думалки") - то пригодность такого рода "насмотренности" в качестве меры - имхо - около нулевая.
Если вот вам - т.е. непосредственно вам - нужен программист, вы разве не знаете как вам его проверить?! Проблема - которую затрагивает автор - она вообще не про это, имхо.
Кто бы спорил за "мышление" и его "развитие"... вот только мой личный опыт мне "шепчет", что освоение - например - теории сложности вычислений - вполне может, если и не "сформировать твое мышление", то уж точно на это "мышление" повлиять. А вот знание (причем весьма условное "знание", в подавляющем большинстве случаев) конкретных решений конкретных задач - очень сильно вряд ли.
В этом смысле, "алгоритмы" - сугубое имхо - это такой аналог насмотренности у каких-нибудь, условных, "дизайнеров". Весьма условный, надо понимать, аналог... но, с ровно такой же "ценностью для".
Всё достаточно просто... основная мотивация в том, что бы отделить "скрипты" от "конфигураций". Идея в том, что будет круто, если в "большинстве случаев" разработчики будут оперировать "конфигурацией" - исключительно понятными им "концептами" (приложение, библиотека, версия, тестовое окружение и т.п.). А в "меньшинстве случаев" - они станут т.н. "build инженерами" - ну или позовут таковых на помощь - и допишут всё что "им надо" через "скрипты".
Про build инженеров...
Gradle - исторически - делит всех своих пользователей на две большие группы. Разработчиков ПО и т.н. build инженеров. Первых сильно больше, чем вторых. Но для вторых, ценность "гибкости" Gradle сильно выше всего остального.
Далее, "конфигурация" (как набор описаний тех самых "концептов") - по своей сути - декларативна. И это приводит нас к мысли, что это "будет круто" не только для разработчиков, но и для всякого рода интеграций... например, с IDE - которой, при наличии такой "конфигурации" не нужно будет "парсить в уме" 100500 "скриптов", чтоб построить, условно, содержимое classpath для "вот этого модуля". Как-то так.
Если говорить о текущей реализации, то - на данный момент - это всё выражается в том, что появился ещё один DSL (в добавок к .gradle и .gradle.kts) - .gradle.dcl. В нём - таки да - запрещены всякие "императивные штучки" типа циклов, ветвлений и т.п.
Формально - да, в .dcl - "таски" и "всё вот это вот" - нельзя.
Но, как обычно - в рамках проекта - эти (.gradle, .gradle.kts и .gradle.dcl) DSL можно "миксовать". Например, вполне норм, когда settings.gradle.dcl и - при этом - build.gradle.kts. Или в "корне" .gradle.kts, а в модулях .gradle.dcl. Ну и т.д. до штатного использования buildScr и build-logic.
По поводу самого .dcl - он всё-таки пока ещё "сыроват" - что не удивительно - но "играцца" уже вполне себе модно. Хотя сама по себе идея, имхо, годная.
Если сильно интересно, то можно "поискать по блогам"... как раз под конец прошлого года (когда был анонс DG) было весьма много статей как раз от "build инженеров", основной посыл которых сводился к "руки прочь" и т.п. Но на данный момент - когда всё это более мнее прояснилось - особых возражений за "ещё один DSL" вроде как нет.
Что DG, что Amper - есть результат последнего коллаба JB, Gradle и Google с целью: "... put most of our attention into declarative software definition".
Ну и standalone "движок" Amper'а - он же, практически, "вчера только" вышел. И чем оно закончится - подозреваю - и сами JB до конца пока не понимают. Весь MP "покрыть" - это не так просто, как кажется/хочется.
Так что, не буду сильно удивлен, если - в конце концов - у Amper под капотом окажется как раз DG...
Это только если какой-то аналог RPC делается. Сообщение это данные. Обычно, если там и есть имя - это тип этих данных. Но ни как не тип потребителя этих данных. Тем более, что обработчик - вообще говоря - может быть и не один.
С одной стороны, хочется уточнить: достаточно для чего? А с другой - формализмы зав. типов - это "охренеть как смело" (с) :-)
Мой это какой?! Я - вроде как - никаких новых формализмов не вводил.
Каким образом?! Я ещё могу представить, как из "здоровенной схемы, описывающую сообщение" выводятся функциональные типы. Это не сложно. Но, что они вам дадут?! Что бы "выйти" на методы нам нужны имена. А тут они - буквально - любые.
Только на уровне формализма подтипа. Его - чаще всего - не достаточно. Поэтому там где нужных формализмов в языке нет, возникают всякого рода "техники программирования", которые переносят их (недостающие формализмы) на уровень реализации.
:-) Ну вот как это объяснить "на пальцах"?
Смотрите... вот у нас есть обычные типы (что бы это не значило). А есть функциональные типы. Какая между ними "разница"? Достаточно ли будет сказать, что функциональные имеют более высокий порядок? И в чём разница между типами разного порядка?
Или - с другой стороны заход - есть тип, а есть его экземпляры (что бы это не значило). Вот представьте себе эдакий НЕХ - экземплярами которого являются типы. Какая между ними разница? Мы на уровне типов даже выразить этот НЕХ (да... это про категорию типов) не сможем :-(
Т.е. эти вот "протоколы"/"поведения"/"классы типов" - это всё про "ограничения", которые накладываются не на уровне самих типов. Это про ограничения уровнем (я порой и не одним) выше, так сказать.
Когда вы реализуете "интерфейс", вы - фактически (через subtyping) - накладываете ограничения на [используемые] типы. С одной стороны, это вроде как "то, что нужно". А с другой - очень часто, это "не те" (либо слишком строгие, либо слишком слабые) ограничения, которые мы (на самом деле) хотим. По большому счету - это из-за того, что сам "интерфейс" - это тоже тип. Соответственно, он и описывается исключительно в "терминах" типов, со всеми их ограничениями. Даже если притащить сюда ещё и параметрический полиморфизм, то ограничения на параметры обобщенного типа - всё равно описываются в терминах типов. Не вырваться :-(
А если мы будет - по сути - тоже самое делать "уровнем выше", то никаких проблем такого рода у нас просто не будет.
Если идти дальше, то это уже какой-то "код" надо будет писать, чтобы показать "разницу". Оно надо?
Какой "объем знаний о получателе" это нам добавляет?
:-) А это точно нужно знать отправителю?!
Например, потому что "что, куда и когда" определяется не отправителем (и не получателем), а протоколом. Точнее, контекстом, в котором сейчас находится отправитель, и протоколом, который этим самым контекстом задается.
Если вам удобнее смотреть на это (контекст и протокол) через призму "интерфейсов", то упрощенно это можно представить себе некоторый медиатор (в терминах GoF).
Ну вот и представьте, что это таки может быть "формализованное в языке".
Если я правильно понял о чём речь, то "компилятор" - сам по себе - тут вообще не при чем. Статический анализ применим и к языкам с динамической типизацией. Главное, чтоб она (типизация) строгой была.
Но я-то не про типизацию... я про связывание (binding). Оно - вообще говоря - ортогонально типизации.
На самом деле, это охренеть какое преимущество :-)
Зачем?! Если "на пальцах": что вы "знаете" о получателе, когда отправляете сообщение, например, в какой-нибудь exchange AMQP брокера? Ну или, когда добавляете запись в какой-то topic kafka - вы много "знаете" о том, кто будет эту запись потом "читать"? А когда уже вы читаете запись и топика, вы что-либо "знаете" об "отправителе"? Зачем это вам?!
Ну, нет. "Интерфейсы" (а точнее, их реализация) - это просто "вот такая вот" форма subpyping'а. А protocol'ы smalltalk'а, behaviour 'ы erlang'а и прочая, и прочая - это не subtyping ни разу.
Я в одном, пожалуй, соглашусь... если рассматривать исключительно "статические" системы, то такого рода преимущество не совсем очевидно. Ну действительно - "зачем козе баян", если "всё, что может быть" мы и так уже описали "до того как".
Но как только вы перейдете к "динамическим" системам - полезность "такой штуки" становится более чем очевидна. Представьте себе, что у вас "рождаются и умирают" не только экземпляры типов, а сами типы - "рождаются и умирают".
Наверное тем, что для того, что послать сообщение получателю, про получателя не нужно знать вообще ничего?
Про "как" и "почему так", Алан "сделал в Smalltalk" лучше, имхо, почитать у самого Алана. Благо его The Early History of Smalltalk давно есть в сети. Очень познавательно.
Вот вам цитата. Это прям самое начало... даёт представление о "какую проблему решаем".
Но лучше самому почитать, имхо. Там не много...
"посылка сообщений" - aka message passing - это то, что, в конечно счете, станет решением для этой самой "small scale one". То, что он сам потом назовет "extreme late binding of all things".