Минимизация бойлерплейта пойдет как критерий удобства?
Для кого-то да. А кому-то удобнее видеть всё прописанным явно.
В яве эксепшены надо обкладывать бойлерплэйтом
В Java тоже есть выбор: либо обрабатывать, либо объявлять, что твой метод тоже бросает определённые исключения. Другое дело, что бывают кривые API, которые проверяемыми исключениями делают ошибки программиста.
Котлин этого не запрещает делать, и вот ни разу не вынуждает
Верно. Проблема в другом. Я её уже и в статье, и в других комментариях подробно описал.
Я бы ни за один JVM-язык не стал браться без знания Java, а за Kotlin тем более, потому что стандартная библиотека там призвана дополнять стандартную Java, а не заменять её. Но пересесть на Kotlin со знанием Java, мне кажется, нет никакого труда. Правда, если предыдущий опыт был основан на Java 7 и раньше, к функциональным конструкциям придётся какое-то время привыкать.
«инструмент должен быть удобным в основных целевых сценариях использования» — это полноценный принцип разработки чего угодно, в том числе языка
Это утверждение верно, но оно примерно как теория, которая может описать что угодно. То есть формально теория верна, но предсказательная сила у неё в итоге нулевая. Так и тут: поскольку это верно в отношении всего, то и знание об этом ничего не даёт относительно какого-то конкретного языка.
аргумент создателей о том, что пакеты не защищены от добавления левых классов в другом модуле, не очень убедителен
Да и не актуален начиная с Java 9. Один модуль не может подложить классы в те же пакеты другому модулю. Поэтому, кстати, JetBrains и заменили kotlin-stdlib-jre7 и kotlin-stdlib-jre8 на kotlin-stdlib-jdk7 и kotlin-stdlib-jdk8: в первых двух один и тот же пакет был в обеих библиотеках.
Меня ещё огорчила в паре случаев работа с вариантностью и границами переменных типа, но это слишком уж узкие случаи, чтобы писать про это в статье. А если ждали, что я буду разносить язык в пух и прах, то это я и не стану делать, в нём ведь действительно решения в основном удачные.
Я же уже объяснил, почему удобство не может быть принципом. Для меня лично, например, Rust — намного более удобный язык для тех задач, для которых он предназначен, чем его альтернативы. В том-то и проблема, лаконичность может быть принципом, явность может быть принципом. Удобство — нет.
По сравнению с public частью — всё-таки "чуть".
А если у меня всего один модуль в проекте в силу каких-то причин? Тогда public и internal вообще никак отличаться не будут.
Да OOM может вылететь от каждого оператора new
Это всё ситуации, которые программа не должна обрабатывать. Я же говорю не про них.
я сам через это проходил
Если бы мне было просто непривычно, я бы ругался на гораздо большее, чем эти две особенности. Мне-то как раз Kotlin понравился сразу тем, что можно всё очень лаконично записать, и с функциональными возможностями мне очень комфортно, в частности, благодаря опыту с Rust и Haskell. И пишу я на нём уже давно. Но вот эти две вещи мешали всегда.
А чем их отсутствие в JS мешает проверять область видимости при компиляции Kotlin?
Там же нет и проверяемых исключений
Но если "это фича только языка", опять же, почему тогда они должны поддерживаться в JS?
Поэтому try-catch-finally надо писать не "для галочки", а там где реально надо сделить за потоком выполнения.
Верно, но вот как мне понять, где именно такие места находятся? И какого рода проблемы могут возникнуть, чтобы правильно написать обрабатывающий код? Иногда это очевидно, иногда нет.
Не знаю, сколько времени вы потратили на написание статьи
При чём тут написание статьи? Я использую инструмент, которым трудно решить определённые проблемы, и я их описал. А "годы исследований и обсуждений" — это, по сути, апелляция к авторитету.
Естественно, я не знаю так, как авторы языка, какие последствия повлёк бы тот или иной выбор. Но объяснение всё-таки хочется увидеть грамотное, а не основанное на избирательном цитировании известного автора и притянутом за уши примере. И хочется иметь какую-то альтернативное решение проблемы, раз авторы считают, что старое не годится.
А есть серьёзные языки, которые создаются как неудобные, что ли? Проблема в том, что принцип доверия-недоверия разработчику объективен, а удобство — это уже понятие субъективное. Можно либо руководствоваться какими-то принципами при принятие решений при разработке языка, либо нет. Удобство — это не принцип.
область видимости чуть больше
Если в каждом модуле пара пакетов, тогда «чуть». А если пакетов больше, то тогда уже не «чуть».
это другой язык
В этом другом языке есть проблема, которую я чётко обозначил: язык не позволяет мне понять, где нештатные ситуации могут возникнуть, а где нет. Если авторы придумают, как решить этот вопрос, например, через алгебраические типы данных, тем более что в Kotlin они есть, я ничего против не имею. Например, в Rust это очень хорошо сделано. В Haskell чуть менее в силу того, что язык чисто функциональный.
А вообще скатываться на личные аргументы некрасиво.
Я могу сказать, почему я перестал писать комментарии (этот сделаю исключением): потому что трудно заработать карму, так как для неё нужно постоянно рождать какие-то статьи, зато потерять её очень легко. Это неправда, что если писать корректно, она не тратится. Её могут снизить по множеству причин: не согласился с тобой в споре, посчитал, что в комментарии какой-то факт неверный, или просто у него плохое настроение. Или чуть в статье что-то пропустил, невнимательно прочитал или недопонял — всё, сразу набегают с минусами. Причём довольно редко кто-то поясняет, за что какой минус — просто ставят и всё. Тут не StackExchange, чтобы их было принято как-то обосновывать.
И в итоге получается, что если это какой-то содержательный разговор, то карма может только расходоваться, потому что несогласные с тобой сразу наставят тебе минусов. А заработать это всё обратно очень трудно. Нужно либо писать что-то оригинальное, что делать постоянно может очень мало кто, если только ты не представитель компании, либо делать переводы или писать новости. Лично мне последние два пункта не очень интересны. Да и когда пишешь, тут культура не такая, что статья неинтересна — прошёл мимо, а сразу некоторые хотят дать понять минусами, что им не понравилось, и, как я уже писал выше, даже безо всякого объяснения, что не так.
Наверное, тех, кто адекватно подходит к сложившейся системе, много, но, например, у меня лично даже нормальный комментарий может вызвать непонятные для меня минусы в карму. Раньше я перечитывал статьи, чтобы ни в коем случае чего-то не упустить, перечитывал текст комментария, который пишу (удалить комментарий, оставленный по ошибке, тоже нельзя). Когда понял, что карма будет расходоваться на комментарии и в этом случае, я просто зарёкся что-то писать. Мне надоело каждый раз при нажатии Enter думать и догадываться, смогу ли я завтра продолжать оценивать статьи или делать ещё что-нибудь.
И думаю, что таких, как я, немало. На Хабрахабр система сильно скошена в сторону кнута, и сообщество этот кнут не гнушается использовать по любой удобной причине — отсюда и такие результаты.
Это не так, проверка баланса через USSD там точно есть. На T-Mobile, например, проверяется через #BAL#. Сейчас ещё посмотрел справку AT&T, у них тоже, по ходу дела, есть аналогичные функции.
Это ограничение относится только к карте памяти, а во внутреннем хранилище срач, увы, так и останется. По мне, людей просто начинают исподтишка загонять в облачные сервисы. Конкуренции маловато, вот Google и распоясались.
Это совершенно нормально. Компания может не платить дивиденды или платить маленькие, а акционеры будут получать свой кусок торта за счёт роста капитализации компании. Например, Microsoft до 2003 года вообще дивиденды не платили. У того же Газпрома, кстати, после кризиса капитализация перестала расти стремительными темпами, и они увеличили выплату дивидендов.
Это не совсем так, например, для Nvidia 3D Vision такая развёртка как раз нужна. Правда, не каждый монитор, в котором есть частота 120 Гц, годится для Nvidia 3D Vision.
Я сам от хэш-таблиц ничего не хочу. Меня спросили, где массивы нужны — я и привёл доступный и очевидный для всех пример. Естественно, в силу распространённости этой структуры данных работу по укрощению массивов для неё конкретно уже кто-то провёл (причём, в функциональной версии от них решили отказаться). Но этим примером же всё применение массивов не ограничивается.
Так раз там IO или ST, то это уже не чисто функциональный код. Это «олдскульно-изменяемые массивы», и «непонятно, зачем писать на Хаскеле, если [они] нужны».
Для кого-то да. А кому-то удобнее видеть всё прописанным явно.
В Java тоже есть выбор: либо обрабатывать, либо объявлять, что твой метод тоже бросает определённые исключения. Другое дело, что бывают кривые API, которые проверяемыми исключениями делают ошибки программиста.
Верно. Проблема в другом. Я её уже и в статье, и в других комментариях подробно описал.
Мы же говорим не об инструментах вообще, а о языках программирования. Говорили бы мы о таких инструментах, как молоток — я бы всецело согласился.
Я бы ни за один JVM-язык не стал браться без знания Java, а за Kotlin тем более, потому что стандартная библиотека там призвана дополнять стандартную Java, а не заменять её. Но пересесть на Kotlin со знанием Java, мне кажется, нет никакого труда. Правда, если предыдущий опыт был основан на Java 7 и раньше, к функциональным конструкциям придётся какое-то время привыкать.
Это утверждение верно, но оно примерно как теория, которая может описать что угодно. То есть формально теория верна, но предсказательная сила у неё в итоге нулевая. Так и тут: поскольку это верно в отношении всего, то и знание об этом ничего не даёт относительно какого-то конкретного языка.
Да и не актуален начиная с Java 9. Один модуль не может подложить классы в те же пакеты другому модулю. Поэтому, кстати, JetBrains и заменили kotlin-stdlib-jre7 и kotlin-stdlib-jre8 на kotlin-stdlib-jdk7 и kotlin-stdlib-jdk8: в первых двух один и тот же пакет был в обеих библиотеках.
Я же уже объяснил, почему удобство не может быть принципом. Для меня лично, например, Rust — намного более удобный язык для тех задач, для которых он предназначен, чем его альтернативы. В том-то и проблема, лаконичность может быть принципом, явность может быть принципом. Удобство — нет.
А если у меня всего один модуль в проекте в силу каких-то причин? Тогда
publicиinternalвообще никак отличаться не будут.Это всё ситуации, которые программа не должна обрабатывать. Я же говорю не про них.
Если бы мне было просто непривычно, я бы ругался на гораздо большее, чем эти две особенности. Мне-то как раз Kotlin понравился сразу тем, что можно всё очень лаконично записать, и с функциональными возможностями мне очень комфортно, в частности, благодаря опыту с Rust и Haskell. И пишу я на нём уже давно. Но вот эти две вещи мешали всегда.
А чем их отсутствие в JS мешает проверять область видимости при компиляции Kotlin?
Но если "это фича только языка", опять же, почему тогда они должны поддерживаться в JS?
Верно, но вот как мне понять, где именно такие места находятся? И какого рода проблемы могут возникнуть, чтобы правильно написать обрабатывающий код? Иногда это очевидно, иногда нет.
При чём тут написание статьи? Я использую инструмент, которым трудно решить определённые проблемы, и я их описал. А "годы исследований и обсуждений" — это, по сути, апелляция к авторитету.
Естественно, я не знаю так, как авторы языка, какие последствия повлёк бы тот или иной выбор. Но объяснение всё-таки хочется увидеть грамотное, а не основанное на избирательном цитировании известного автора и притянутом за уши примере. И хочется иметь какую-то альтернативное решение проблемы, раз авторы считают, что старое не годится.
Если в каждом модуле пара пакетов, тогда «чуть». А если пакетов больше, то тогда уже не «чуть».
В этом другом языке есть проблема, которую я чётко обозначил: язык не позволяет мне понять, где нештатные ситуации могут возникнуть, а где нет. Если авторы придумают, как решить этот вопрос, например, через алгебраические типы данных, тем более что в Kotlin они есть, я ничего против не имею. Например, в Rust это очень хорошо сделано. В Haskell чуть менее в силу того, что язык чисто функциональный.
А вообще скатываться на личные аргументы некрасиво.
И в итоге получается, что если это какой-то содержательный разговор, то карма может только расходоваться, потому что несогласные с тобой сразу наставят тебе минусов. А заработать это всё обратно очень трудно. Нужно либо писать что-то оригинальное, что делать постоянно может очень мало кто, если только ты не представитель компании, либо делать переводы или писать новости. Лично мне последние два пункта не очень интересны. Да и когда пишешь, тут культура не такая, что статья неинтересна — прошёл мимо, а сразу некоторые хотят дать понять минусами, что им не понравилось, и, как я уже писал выше, даже безо всякого объяснения, что не так.
Наверное, тех, кто адекватно подходит к сложившейся системе, много, но, например, у меня лично даже нормальный комментарий может вызвать непонятные для меня минусы в карму. Раньше я перечитывал статьи, чтобы ни в коем случае чего-то не упустить, перечитывал текст комментария, который пишу (удалить комментарий, оставленный по ошибке, тоже нельзя). Когда понял, что карма будет расходоваться на комментарии и в этом случае, я просто зарёкся что-то писать. Мне надоело каждый раз при нажатии Enter думать и догадываться, смогу ли я завтра продолжать оценивать статьи или делать ещё что-нибудь.
И думаю, что таких, как я, немало. На Хабрахабр система сильно скошена в сторону кнута, и сообщество этот кнут не гнушается использовать по любой удобной причине — отсюда и такие результаты.