так в самом дсл синтаксисе магии то и нет. у меня лично проблемы с автокомплитами/типами

так в самом дсл синтаксисе магии то и нет. у меня лично проблемы с автокомплитами/типами

+

а в чем проблема писать на чём удобно?)

в том что это пока нестабильно работает)

ну раз не стабильно работает, то играйся дома, нефиг такое тащить на работу

тоесть дома будешьь писать пет проджекты пару часов в день на том что удобно а потом приходить и 10 часов ковырятся в том что неудобно?)

я начал разбираться с GKD, для меня он такая же магия как грувёвый)

тоесть дома будешьь писать пет проджекты пару часов в день на том что удобно а потом приходить и 10 часов ковырятся в том что неудобно?)

ну да, стабильность тут для меня дороже.

на работе у меня maven простой как рельсы, а дома балуюсь с gradle)

я начал разбираться с GKD, для меня он такая же магия как грувёвый)

везде магия, код - это магия

везде магия, код - это магия

скорее недостаток знания

а сам котлин собирается на kts)

О видно что прогрес, я видел ужас

Я бы посмотрел щас на грувиста, который согласился бы с тем, что tasks.withType<KotlinCompile>.all { выглядит красивее, чем compileKotlin { :D (но понятнее, конечно же, так что ИМО всё равно плюс)

Нет, я не пойму этого хайпа))

Да нет никакого хайпа. Просто статически типизированные языки удобнее в принципе, так как: 1. Они отсекают целые классы ошибок, связанных с несовместимостью типов. В динамически типизированных (python, groovy и т.п.) ошибки несовместимости типов никуда не деваются, просто ловятся они в рантайме, в неожиданных местах, и в некоторых случаях, когда некорректный по типам код вызывается. 2. Статически типизированные языки гораздо лучше анализируются IDE, в результате в предлагаемых автодополнениях гораздо меньше нерелевантных вариантов => меньше шанса сделать ошибку, выбрав не то.

а вот вопрос, в gradle есть 2-е возможности добавлять плагины, в этом примере который ? (apply plugin: 'name' ?)

Как результат: меньше шансов на ошибку => меньше ошибок => дешевле поддержка и баг фикс

Я бы посмотрел щас на грувиста, который согласился бы с тем, что tasks.withType<KotlinCompile>.all { выглядит красивее, чем compileKotlin { :D (но понятнее, конечно же, так что ИМО всё равно плюс)

В целом красивее ?‍♂️

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

а вот вопрос, в gradle есть 2-е возможности добавлять плагины, в этом примере который ? (apply plugin: 'name' ?)

это который по id

Я бы посмотрел щас на грувиста, который согласился бы с тем, что tasks.withType<KotlinCompile>.all { выглядит красивее, чем compileKotlin { :D (но понятнее, конечно же, так что ИМО всё равно плюс)

Тут понятно откуда растет этот compileKotlin, можно сразу понять что происходит. Тоже самое с mainClassName. Вот смотришь ты на билд, и не знаешь что делает application плагин, как понять новичку зачем и откуда mainClassName?

Тут понятно откуда растет этот compileKotlin, можно сразу понять что происходит. Тоже самое с mainClassName. Вот смотришь ты на билд, и не знаешь что делает application плагин, как понять новичку зачем и откуда mainClassName?

Да я же в шутку. Я всеми руками за gradle.kts и с нетерпением жду, когда с ним будет дружить kotlin-multiplatform :)

Да нет никакого хайпа. Просто статически типизированные языки удобнее в принципе, так как: 1. Они отсекают целые классы ошибок, связанных с несовместимостью типов. В динамически типизированных (python, groovy и т.п.) ошибки несовместимости типов никуда не деваются, просто ловятся они в рантайме, в неожиданных местах, и в некоторых случаях, когда некорректный по типам код вызывается. 2. Статически типизированные языки гораздо лучше анализируются IDE, в результате в предлагаемых автодополнениях гораздо меньше нерелевантных вариантов => меньше шанса сделать ошибку, выбрав не то.

Ну это субъективно. Я сколько не говорил это javascript программистам, они в корне не согласны

Ну это субъективно. Я сколько не говорил это javascript программистам, они в корне не согласны

да бывает, а потом наблюдаешь как человек 10 минут пытается понять что функция возвращает и когда

Ну это субъективно. Я сколько не говорил это javascript программистам, они в корне не согласны

Немалое количество джаваскриптеров кроме категории "хайпово" / "не хайпово" оценивать больше ничем не могут, потому с ними нередко без толку технологии обсуждать. :)

Как результат: меньше шансов на ошибку => меньше ошибок => дешевле поддержка и баг фикс

Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне).

Ну это субъективно. Я сколько не говорил это javascript программистам, они в корне не согласны

То-то они в проект всякие Lint, TypeScript и прочее тащат. Специально, чтоб типы не проверять.

Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне).

не верится что то

Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне).

Ссылку на исследование

Я вот видел статью на хабре, где народ на Haskell перешёл, так как надоело питоновские баги отлавливать.

Ссылку на исследование

https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html

https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html

Они баги считали по числу коммитов с фиксами, да ещё и по комментам к коммиту типы багов прикидывали? O_o

ну а как еще?

Ну и можно еще сразу на Gradle Kotlin DSL перейти попробовать https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

Если так сделать, вероятно, будет гореть не только ноут. 2 раза пытался втащить это в проект, но в итоге переписывал на груви. Теперь жду релиза, а там будет и 3-я попытка)

Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне).

вот только в конце статьи саммари противоположное тому что ты сказал?

https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html

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

вот только в конце статьи саммари противоположное тому что ты сказал?

+

The data indicates that functional languages are better than procedural languages; it suggests that disallowing implicit type conversion is better than allowing it; that static typing is better than dynamic; and that managed memory usage is better than unmanaged. ФП лучше процедурного программирования, неявное преобразование типов хуже явного, статическа типизация лучше динамической, автоматическое управление памятью лучше ручного.

Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне).

аж слезу пустил

The data indicates that functional languages are better than procedural languages; it suggests that disallowing implicit type conversion is better than allowing it; that static typing is better than dynamic; and that managed memory usage is better than unmanaged. ФП лучше процедурного программирования, неявное преобразование типов хуже явного, статическа типизация лучше динамической, автоматическое управление памятью лучше ручного.

Оно там размытое, стат. типизация исправляет костыли процедурно-ооп-языков ? Одно можно сказать - в ФП ошибок не гораздо меньше.

стат типизация с выводом типов и где компилятор сам все догадывается - идеально

TypeScript не от хорошей жизни на фронте появился

Оно там размытое, стат. типизация исправляет костыли процедурно-ооп-языков ? Одно можно сказать - в ФП ошибок не гораздо меньше.

процедурное программирование очень далеко от ООП. Вы сравниваете достаточно низкоуровневую парадигму с парадигмой, которая расширяет ФП.

стат типизация с выводом типов и где компилятор сам все догадывается - идеально

А программисту, читающему код, тоже все типы выводить?

стат типизация с выводом типов и где компилятор сам все догадывается - идеально

Вам в Haskell дорога.

А программисту, читающему код, тоже все типы выводить?

IDE подсказывать умеет

А программисту, читающему код, тоже все типы выводить?

Да зачем вообще читать дальше сигнатур функций?.. Скомпилировалось - значит работает.

> Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне). найс исследование, а потом еще неверное цитирование выводов

А программисту, читающему код, тоже все типы выводить?

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

— Правда ли, что шахматист Петросян выиграл в лотерею тысячу рублей? — Правда, только не шахматист Петросян, а футболист «Арарата» Акопян, и не тысячу, а десять тысяч, и не рублей, а долларов, и не в лотерею, а в карты, и не выиграл, а проиграл.

IDE подсказывать умеет

Скоро IDE за программиста думать будет)

> Было же исследование, что в проектах на динамических языках было меньше багов (там в кложе/питоне). найс исследование, а потом еще неверное цитирование выводов

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

IDE подсказывать умеет

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

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

питон у нас статическим стал?

Скоро IDE за программиста думать будет)

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

Скоро IDE за программиста думать будет)

тайные поклонники VIM?)

питон у нас статическим стал?

сорян я думал что ты про то что в джаваскриптах\питонах подскажет

Скоро IDE за программиста думать будет)

за меня идея много думает

греет проц знатно

особено когда на котлине пишешь

тайные поклонники VIM?)

У VIM тоже есть плагины с анализом синтаксиса и автодополнениями.

сорян я думал что ты про то что в джаваскриптах\питонах подскажет

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

тайные поклонники VIM?)

Vim норм умеет в lang server

ERROR: S client not available

греет проц знатно

i9?)

тайные поклонники VIM?)

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

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

пока с этим проблем не было. и как тебе помогут тут прописанные типы явно?

i9?)

ды не i5 4460 и i7 4xxx, после котлина начинаешь писать на джаве все так сразу резко становится и четко, но конечно не сахарно:(

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

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

ды не i5 4460 и i7 4xxx, после котлина начинаешь писать на джаве все так сразу резко становится и четко, но конечно не сахарно:(

не замечал таких проблем. наверное что-то делается не так)

не замечал таких проблем. наверное что-то делается не так)

а что за проц у тебя? у меня отзывчивость при написании котлина куда хуже

2.7 GHz Intel Core i7, сижу на EAP

2.7 GHz Intel Core i7, сижу на EAP

какое поколение?

я в андроид студии canary в основном

я думаю это не сильно важно) скорее важно размер проекта, кол-во библиотек подключенных и тд

я думаю это не сильно важно) скорее важно размер проекта, кол-во библиотек подключенных и тд

ну такое, там производительность в два раза отличается между 1 и 8 поколениями вроде

ну а если ноутбучная модификация то темболее будет слабее

какое поколение?

i7-6700HQ вообще никаких проблем нету. Могу 10 проектов от реально больших до с десятком классов открыть одновременно.

kaby lake если память не изменяет, прошка 2017года

ну это да, посвежее чем у меня

вот бы в fps ометр в идею встроить

и мериться

я в ktor сорсах немного тусил, и их тесты гонял. без проблем

НО скажу так что на динамических языках IDE куда больше тупит?

я в ktor сорсах немного тусил, и их тесты гонял. без проблем

на jmh там все ложится)

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

Ну таки, тесты никто не отменял (даже в хаскеле)

Ну таки, тесты никто не отменял (даже в хаскеле)

А, ну да. Тесты же должны покрывать, что ты вместо списка вдруг слона передал, конечно же.

Даёшь в разы больше тестов без уверенности в корректности.

Ну так 99% код-кавередж это идел

или вместо списка слонов, список хрен пойми чего)

Ну так 99% код-кавередж это идел

100% покрытие ничего не даст. Всё работает отлично для любых списков, множеств, строк. На слонах вот валится, но кто же на них додумался проверить?

в общем немного странное обсуждение в котлин чатике?

Их же даже в логике алгоритма нету нигде.

100% покрытие ничего не даст. Всё работает отлично для любых списков, множеств, строк. На слонах вот валится, но кто же на них додумался проверить?

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

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

Снаружи прилетело. Из библиотеки, которую писали не вы.

пока с этим проблем не было. и как тебе помогут тут прописанные типы явно?

В котлине то, что доступно в области видимости какой-нибудь лямбды, иногда не совсем очевидно