Kotlin - новый язык для JVM - Философия программирования

Здравствуйте, Klapaucius, Вы писали:

C>>>>Я не уверен насчёт возможность определить оператор "+?" (т.е. возможно придётся использовать plus?),
K>>>Проблема-то в том, что нужно специальный оператор определять, а нужна возможность обходиться импеющимся.
C>>Ну вмонтируют его в стандартную библиотеку. И что?

K>Да в какую стандартную библиотеку-то? Вы пишете, что использовать готовый оператор (в данном случае +) нельзя, надо будет определять другой.

Кстати, в котлине вроде как список операторов раширять нельзя. Но можно любую бинарную фукнцию как оператор (без приоритета) использовать. Так что +? не прокатит, если сами авторы его не встроят. А значит гарантированно, что всех случаев перекрыто не будет.

C>>всё пишем на каких-то мэйнстримовых языках
C>>Scala, Erlang

K>Вот уж мейнстрим так мейнстрим.

+1

K>Да не надо делать все что угодно, надо делать все что удобно. Ну, допустим, вам удобство написания программ не особо интересно — вы программисту деньги платите а он пусть изворачивается как хочет, но мне непонятна мотивация авторов Котлина — они хотят сделать язык, на котором им будет удобно писать IDEA, но делают они неудобно сами же для себя. Им что, при написании IDEA методы с параметрами не нужно будет вызывать?

Думаю, что они исходят из того, что с null-абл типами им придется иметь дело редко. Вот и наедятся, что встроенная защита от наступания на грабли закроет 99% проблем.

Идея поднимать работу с null в монады конечно красива, но боюсь что это приведет к серьезному снижению производительности при работе с null (а значит почти со всеми классами Явы). Тут нужно чтобы человек мог как-то осознанно выбирать подъем в монаду.

C>>>>А макросы меня откровенно пугают — я понимаю, что это очень мощная вещь, но я боюсь того, что накосячат на них Джамшуты Рамдисамрутаны.

K>Да, и кстати, разработчики языка-то кого боятся? Самих себя? IDEA Джамшуты разве пишут?

Хороший вопрос. Но макросов они реально боятся. Это факт.

K>Да обычными option и синтаксическим сахаром для любых монад/аппликативных функторов. С idiom brackets например, это будет выглядеть как-то так: z = (| x + y |)

+1

Надо будет к немерлу прикрутить

Klapaucius,

K>А я вот считаю, что любой сабтайпинг и след. отношение наследования — это грабли. В принципе. И как грабли не перекрашивай — астролябии из них не получить.

Я понимаю. Классы типов. Функциональные зависимости. Типы как первоклассные значения. Типы как теоремы. Нирвана.

Cyberax,

C>>>Diamond-проблема на практике во многом надумана, она встречается раз в пятилетку. Поэтому стоит ввести какое-то поведение для неё, но не трогать самые частые случаи использования наследования — частичные mixin'ы.
LCR>>Я бы сказал несколько иначе: мы научились жить в кандалах, однако раз в пятилетку очередная примерка новых кандалов вдруг переполняет чашу терпения.
C>Нет, сложный diamond, как и глубокие иерархии классов вообще, реально не нужны.

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

C>Обычно интерфейсы сравнительно небольшие по объёму, что не создаёт проблем с их полной реализацией.
Тоже спорное утверждение. Насколько необычны интерфейсы List, Collection, Map? А копнёшь в сторону BeanContextServices, так список методов и на экран не умещщается.

C>Вообще-то, описанное тобой — это антипаттерн. Если есть только одна реализация, то она просто и используется. При необходимости делается рефакторинг.
Да, именно так я сам и стараюсь поступать. Но проблема существует.

LCR>>3. Якобы best practice "никогда не наследуйте реализацию, используйте делегирование". Ребята, а в чём проблема-то, если можно всегда отпочковать наследника, подмешать нужный функционал из других классов, переопределить что надо и вперёд? Увы, с интерфейсами и одиночным наследованием такой фокус не провернёшь, вот и вылезла "бест практика".
C>При том, что имеем сильное связывание между классами. Реально сильное — и очень часто в предке начинает появляться код, специально заточенный на наследников.

Ну соглашусь, да, наследование — вид сильной связи, нужно уменьшать связность. МН делает возможность связать классы ещё крепче, это расплата за возможность комбинироать. Оставляем статус "бест" вышеназванному "практису".

Можно заканчивать, или ещё есть что добавить?

VladD2,

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

Вообще от наследования люди ищут 2 вещи — унификации и повторного использования кода. Унификацию реализуется через интерфейсы, а макросы обладают намного большей гибкостью в смысле повторного использования кода. Где нет макросов, есть только три возможности для повторного использования — наследование кода, вызов кода и использование конструкций языка (для создания своего, тут как бы мы повторно используем if-ы и for-ы). Макросы добавляют четвёртый путь — трансформацию кода. Так что знаешь, Влад, я не удивлён, что тебе МН не понадобилось

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Вообще от наследования люди ищут 2 вещи — унификации и повторного использования кода. Унификацию реализуется через интерфейсы, а макросы обладают намного большей гибкостью в смысле повторного использования кода. Где нет макросов, есть только три возможности для повторного использования — наследование кода, вызов кода и использование конструкций языка (для создания своего, тут как бы мы повторно используем if-ы и for-ы). Макросы добавляют четвёртый путь — трансформацию кода. Так что знаешь, Влад, я не удивлён, что тебе МН не понадобилось

Не то что бы совсем не понадобилось, но острой необходимости не чувствуется.

В прочем, аппетит приходит во время еды. Когда есть фича, то и дизайн идет по-другому.

Здравствуйте, Klapaucius, Вы писали:

C>>Естественно, для оператора "+" не определено поведение с nullable-аргументом.
K>Как же так? А почему для метода blahBlahBlah(this, x, y) при таком вот использовании maybenull?.blahBlahBlah(x, y) вдруг — рраз! — и определено такое поведение для первого аргумента, а для всех прочих аргументов вдруг не определено?
Ещё как определено. "maybenull?.blahBlahBlah(isnull, y)" вызовет ошибку времени компиляции, аргументы методов по умолчанию тоже notnull — ровно как и аргумент "this". И для включения null'абельности нужно явно это указывать.

C>>Честно говоря, я не помню, чтобы у меня было много подобного кода. Оператор "?" вот сильно поможет.
K>Если есть общая установка, что такой вот код — это нормально, аналогичный бессмысленный код других видов также будет присутствовать, как же иначе-то?
Нету бессмысленного кода тут. Всё вполне стройно.

K>Котлин белает выбор между
K>z = (x!=null && y!=null) ? x + y : null
K>и
K>z = (| x + y |)
K>в пользу первого.
Варианта тут, как минимум, три. Я уже предложил "z = x ?plus? y", который лично мне более понятен и удобен.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Да, мне тоже нравится комбинировать код из небольших самостоятельных кусочков. Но долго оставаться на этом уровне не получится, слишком много ручной работы. Здравый смысл подсказывает вводить новые абстракции, объединять, унифицировать, а значит и строить иерархии. В некоторых предметных областях развесистые иерархии неизбежны. Вон, хотя бы попробуй конфигурацию разложить — сразу выявляются опции самых разных цветов и вкусов, общие куски, зависимости (подчас очень хитрые). Эклипс тот же, там от Reconciler-а столько детей, что...
Где именно там глубокие иерархии?

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

C>>Обычно интерфейсы сравнительно небольшие по объёму, что не создаёт проблем с их полной реализацией.
LCR>Тоже спорное утверждение. Насколько необычны интерфейсы List, Collection, Map? А копнёшь в сторону BeanContextServices, так список методов и на экран не умещщается.
А это всё из-за неправильного дизайна и отсутствия extension-методов. Очень часто можно реализовать небольшое ядро, на которое уже вешаются куча функций-утиллит. Ну и иногда, действительно, сложность бывает реально нужна.

C>>Вообще-то, описанное тобой — это антипаттерн. Если есть только одна реализация, то она просто и используется. При необходимости делается рефакторинг.
LCR>Да, именно так я сам и стараюсь поступать. Но проблема существует.
Это не повод делать антипаттерн проще в использовании.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Нирвана.

Это, я надеюсь, сарказм.

LCR>Классы типов.

Это штука довольно неплохая, мне нравится, но тут все явно не без проблем. Во-первых, проблема многопараметричности более-менее решается только примерно через 15 лет экспериментов с ними с помощью ассоциированных типов, при том, что не понятно, насколько такое решение вопроса окончательное — потому что предыдущее окончательное решение уже, похоже, отправляется на свалку истории (см. ниже). Вернее все отправляется и отправляется уже который год, потому как полную реализацию TF никак не могут доделать, впрочем, в GHC 7.2, вроде как, реализация будет уже полной.
Во-вторых, все это непродуманное взаимодействие классов типов с системой модулей, из-за которого сейчас некоторые товарищи одно из главных преимуществ классов типов — неинтрузивность — вообще предлагают не использовать, т.е. orphan instances объявляют плохой практикой. И это так, навскидку, если подумать подольше можно и еще что-нибудь вспомнить.

LCR>Функциональные зависимости.

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

С другой стороны, тут хоть какие-то перспективы просматриваются, а сабтайпинг мучают десятилетиями, и всякий раз, когда кажется, что все в порядке, неожиданно появляется ручка грабель и больно бъет по незащищенному месту. (даже грабли без ручки — сабтайпинг без наследования реализации — как-то умудряются ударить, чудеса просто) по-моему, уже пора закапывать давно.

LCR>Типы как первоклассные значения.

Не понял даже, что под этим подразумевается. Исчисление конструкций?

LCR>Типы как теоремы.

Ну, это вообще к предмету обсуждения не относится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, VladD2, Вы писали:

VD>Кстати, в котлине вроде как список операторов раширять нельзя.

Это идея явно плохая, из-за этого приходится потом использовать привычные операторы в непривычных ролях, вроде как >> в C++ используется.

VD>Но можно любую бинарную фукнцию как оператор (без приоритета) использовать.

А вот к такому у меня отношение неоднозначное. Более правильные подходы — это когда можно или на этапе объявления определять, что будет использоваться как инфиксный оператор как в SML (или, скорее, как в алгол 68), или явно помечать инфиксное использование префиксных по-умолчанию функций с и менами из букв и префиксное использование инфиксных по-умолчанию операторов из спецсимволов.
И невозможность указать приоритеты и, видимо, ассоциативность — это точно плохая идея. От этого потом будет скобок как в лиспе.

VD>Думаю, что они исходят из того, что с null-абл типами им придется иметь дело редко.

Ну, я думаю, что они зря на это надеются. Если бы они писали с нуля все библиотеки — nullable был бы только там, где он нужен, а они-то будут вызывать методы джававских библиотек, которые будут им возвращать nullable всегда и везде.

VD>Идея поднимать работу с null в монады конечно красива, но боюсь что это приведет к серьезному снижению производительности при работе с null (а значит почти со всеми классами Явы). Тут нужно чтобы человек мог как-то осознанно выбирать подъем в монаду.

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

K>>Да, и кстати, разработчики языка-то кого боятся? Самих себя? IDEA Джамшуты разве пишут?
VD>Хороший вопрос. Но макросов они реально боятся. Это факт.

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

K>>С idiom brackets например, это будет выглядеть как-то так: z = (| x + y |)
VD>Надо будет к немерлу прикрутить

Да, это может быть полезно. При использовании всякого синтаксического сахара типа list comprehensions или там computation expressions достаточно часто встречаются простые случаи типа

$[f(x, y) | x in xs, y in ys]

maybe{ let! x = mx; let! y = my; return f x y }

При этом простые "извлечения" значений внутри контекста x in xs, y in ys — это просто мусорный код.
Idiom brackets позволяют писать просто (| f(xs, ys) |), обозначая скобками контекст и без всякого мусора.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Cyberax, Вы писали:

C>Ещё как определено. "maybenull?.blahBlahBlah(isnull, y)" вызовет ошибку времени компиляции

Вот я и говорю — не определено.

C> аргументы методов по умолчанию тоже notnull — ровно как и аргумент "this". И для включения null'абельности нужно явно это указывать.

Ну вот я и говорю, включить у первого аргумента можно легко, а понадобиться включить у второго и дальше — все, приехали.

C>Нету бессмысленного кода тут.

Еще раз. Бессмысленный код выделен жирным:

(x!=null && y!=null) ? x + y : null

Если вы его не видите — как вам удалось его написать?

C>Всё вполне стройно.

У вас в этом треде вечно оруэльщина какая-то. Двоемыслие. Удобство — это неудобство. Стройность — это кривость. И т.д.

C>Варианта тут, как минимум, три.

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

C>Я уже предложил "z = x ?plus? y", который лично мне более понятен и удобен.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Cyberax,

LCR>>Да, мне тоже нравится комбинировать код из небольших самостоятельных кусочков. Но долго оставаться на этом уровне не получится, слишком много ручной работы. Здравый смысл подсказывает вводить новые абстракции, объединять, унифицировать, а значит и строить иерархии. В некоторых предметных областях развесистые иерархии неизбежны. Вон, хотя бы попробуй конфигурацию разложить — сразу выявляются опции самых разных цветов и вкусов, общие куски, зависимости (подчас очень хитрые). Эклипс тот же, там от Reconciler-а столько детей, что...
C>Где именно там глубокие иерархии?
В Эклипсе то?! Ну ладно, если тебя забанили в поиске по докам, то держи
org.eclipse.core.commands
org.eclipse.emf.mapping [/utl]<br />
[url=http://help.eclipse.org/galileo/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/exporter/package-tree.html] org.eclipse.emf.exporter
org.eclipse.emf.importer
org.eclipse.gmf.codegen.gmfgen
Глубина иерархии везде как минимум = 4. Что касается реконсилера, то каждый мало-мальски полезный редактор должен IReconcilingStrategy и IReconcilingStrategyExtension, и чаще всего это один и тот же класс. Вот, собственно, и ромб.

C>>>Обычно интерфейсы сравнительно небольшие по объёму, что не создаёт проблем с их полной реализацией.
LCR>>Тоже спорное утверждение. Насколько необычны интерфейсы List, Collection, Map? А копнёшь в сторону BeanContextServices, так список методов и на экран не умещщается.
C>А это всё из-за неправильного дизайна и отсутствия extension-методов. Очень часто можно реализовать небольшое ядро, на которое уже вешаются куча функций-утиллит. Ну и иногда, действительно, сложность бывает реально нужна.
Неправильный дизайн? Ну я знаю библиотеку коллекций с правильным дизайном: scala collections. Чтобы построить такую библиотеку, extension-методов явно недостаточно. В Скале, как ты скорее всего знаешь, higher-kinded типы появились не из блажи создателей, а из-за потребности подавить дублирование кода, сохранив при этом остальные свойства библиотеки.

Extension-методы есть довольно слабый инструмент абстрагирования. Вот простейший пример:

class A {
  void m1() {}
  void m2() {}
  void m() { m1(); m2() }
}
class B extends A {
  void m1() {}
  void m2() {}
  void m() { m2(); m1() }
}

Метод m() в обоих классах зависит от публичного контракта, но выделить extension нифига не выйдет. Trait-ы мощнее.

C>>>Вообще-то, описанное тобой — это антипаттерн. Если есть только одна реализация, то она просто и используется. При необходимости делается рефакторинг.
LCR>>Да, именно так я сам и стараюсь поступать. Но проблема существует.
C>Это не повод делать антипаттерн проще в использовании.
Логики не понял. МН не делает антипаттерн проще в использовании — он исключает этот антипаттерн. Рефакторинг — это тоже костыль, по большому счёту.

Klapaucius,

Вообще, мой предыдущий пост был немного саркастическим

, но коли уж ты решил взять серьёзную ноту, то это тоже хорошо.

K>С другой стороны, тут хоть какие-то перспективы просматриваются, а сабтайпинг мучают десятилетиями, и всякий раз, когда кажется, что все в порядке, неожиданно появляется ручка грабель и больно бъет по незащищенному месту. (даже грабли без ручки — сабтайпинг без наследования реализации — как-то умудряются ударить, чудеса просто) по-моему, уже пора закапывать давно.

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

LCR>>Типы как первоклассные значения.
K>Не понял даже, что под этим подразумевается. Исчисление конструкций?
Я неграмотно выразился. Я имел ввиду, что можно вообразить типы как значения для функций над типами (type functions).

LCR>>Типы как теоремы.
K>Ну, это вообще к предмету обсуждения не относится.
Да, действительно, мы о выразительности вели речь.

Здравствуйте, VladD2, Вы писали:

VD>А что ты так нервно моргаешь то? Исходно студия была целиком анменеджед.

Не совсем. Некоторые куски, например тулбокс или окно свойств, изначально были managed.