Pull to refresh
39
0
Борис Ванин @fogone

Пользователь

Send message
минус не ставил, но могу сказать свои мысли по этому поводу. Тут много можно было бы написать, но одного только заключения вашего комментария хватит, чтобы понять, что вы вообще не в теме, статью не поняли и отвечаете на какую-то фантазию о том что там написано, а потому начинать дискуссию просто бессмысленно.
Я уже было подумал, что хорошее начало статьи, когда она закончилась.
Т.е. статью можно было сократить до следующего утверждения: если вы хотите использовать функции (лямбды), которых нет в стандартной библиотеке, функциональные интерфейсы для них придется сделать самим.
Метод apply мог бы назваться горшком и это ничего ты не поменяло. Именно из за этого документация умалчивает об этой «магии». Просто никакой магии тут нет. Ещё раз: не надо назвать метод apply, чтобы интерфейс стал функциональным. Даже аннотация не нужна. Т.е. статья вцелом совершенно непонятно о чем.
Забавно, на днях как раз пытался подключить блютуз-наушники к своему асус-н на убунте. После длительного шаманства музыка все же заиграла, но стабильность примерно никакая. Чтобы отключиться и подключиться опять приходится ресетить девайс целиком. Не знаю можно ли с такими артефактами жить в профессиональной области.
С фатальными я полагаю?
// котлин-вей (как я себе его представляю)
generateSequence(x) { (it - 1) and it }.takeWhile { it > 0 }.forEach { 
      // todo
}

// для тех кто экономит на итераторах
var i = x ; while (i > 0) { 
    i = (i - 1) and i
    // todo
}

// если очень хочется в три блока как в старые добрые
inline fun <T> oldScoolFor(initValue: T, 
                           condition: (T) -> Boolean, 
                           next: (T) -> T, 
                           body: (T) -> Unit) {
    var i = initValue
    while (condition(i)) {
        i = next(i)
        body(i)
    }
}

oldScoolFor(x, { x > 0 }, { (it - 1) and it }) {
    // todo
}
с котлином для грейдла удобство в первую очередь в написании билда, а не в его чтении. С груви никогда точно не знаешь что от тебя ждёт api, с котлином всё однозначно для ide и разработчика, это дорогого стоит
Не понимаю, честно говоря, зачем вы предлагаете причесывать оптимизированный код? И вообще сути дискуссии не могу уловить — все отлично всё понимают, что размер тут оказался камнем преткновения, хотя суть только в том, чтобы сделать монструозные функции более читаемыми, изменяемыми и вообще приятными глазу. Это применимо для разросшегося метода бизнес-логики или для ситуации, когда есть смысл вынести какой-то процесс в отдельную абстракцию, но оптимизированные функции делать более приятными глазу никто не будет — их специально сделали такими, чтобы они работали быстрее и не вижу смысла пытаться проворачивать фарш обратно.
В другом комментарии писал о том, что оптимизации это совершено отдельная тема и к ним очень сложно применить правила хорошего кода, потому что их смысл часто как раз в том, чтобы увеличить производительность за счет не очень красивых приемов вроде разворачивания циклов.
Возможно меня забросают тряпками натерпевшиеся от этих, которые всё бьют и бьют, но вот ни разу не сталкивался с этим в таком масштабе, чтобы это было проблемой. Кто-то сделал не очень удачную композицию, на ревью обсудили. Сам нашел в своем коде неудачное решение, перегруппировал, разделил. А вот так, чтобы приходишь, а весь код в нелепых однострочных функциях — такого вот не видал.
О чем угодно можно сказать: делай это с умом и будет тебе счастье. Но как я уже написал чуть выше, размер — это симптом, он подсказывает, что возможно этот метод можно упростить, вынести в функции куски, которые занимаются более низкоуровневыми вещами. Особенно если ты начинающий разработчик, то это очень хороший повод обратить внимание на тот код, что ты написал. Опытный обычно или делает на автомате такие вещи или новым трюкам его уже не научишь.
На практике, одна функция на 90 строк часто читается в несколько раз быстрее, чем 6 функций по 15.

Если функции сделаны прилично, то вместо 90 строк обычно нужно прочесть одну из 6 и потом еще 15 (в случае, если нужны детали реализации), а то и верхнего уровня достаточно бывает. Даже не знаю, что быстрее прочесть 90 строк или 21?
Эти ф-и по 15 строк могут просто не выполнять какого-либо действия, которое было бы осмысленным вне общего алгоритма

Строки которые не содержат никакого законченного осмысленного действия, не нужно выносить в функцию, это написано в любой книге, где может упоминаться негативное влияние размера на удобство чтения и изменения. Только эта статья почему-то размышляет о функциях в контексте их размера, хотя как тут уже много раз замечали, размер лишь симптом плохо спроектированной функции, но не всегда является причиной для дробления. Опыт подсказывает, что для сложной логики бывает, что последовательность вполне равноправных действий может занимать существенное количество строк. Речь скорее о ста, чем о тысячи, конечно, второй случай с почти сто процентной вероятностью это плохой дизайн или последствия оптимизаций (этот случай обычно отмечается специальными комментариями, чтобы не было соблазна «привести в порядок», но случай очень редкий).
Не понимаю, зачем делать столько конструкторов у KTextView, когда можно было сделать один дефолтный и к нему несколько фабричных фукнций? Не котлинвей получился немного на мой взгляд.
По большому счету, конечно, дискутировать здесь особо не о чем, это вопрос выбора. Разработчик выбирает на чем ему писать, архитектор выбирает на чем будет сделан проект и так далее. Я как и вы пытаюсь поделиться субъективными ощущениями от языка и причинами, почему я не пока не могу выбрать этот язык ни как разработчик, ни как архитектор. Я много раз слышал про «относиться к ошибкам так же как любым другим значениям», проблема только в том, что ошибки они не такие же как другие. И это очень быстро становиться ясно, когда начинаешь писать на гоу. «Неуважение к ошибкам» — это тоже такая вещь, которую язык не исправит. На гоу их будут просто игнорировать, в случае с эксепшенами их будут бездумно прокидывать. Что к слову лучше, чем просто проигнорить, так хотя бы какая-то инфа есть, хотя и эксепшн можно просто по-тихому заткнуть по большому счету особой разницы нет. Вот в джаве тоже пытались заставить разработчика обрабатывать исключения принудительно и что из этого вышло? Повсеместного появления бойлерплейта и перманентного игнорирования эксепшенов. Лично для меня такой подход несет больше проблем, чем их решений. Конечно любой язык это некоторый баланс между доверием мастерству разработчика и недоверием — и гоу по моему ощущению перекошен в «недоверие».
гораздо более серьезных проблем

Что-то мне подсказывает, что вы недооцениваете масштаб этой проблемы. Лично для меня при всей моей симпатии к гоу, есть пара нюансов (один из которых обилие кода, который бы я хотел написать в одном месте, но не могу из за этой особенности языка) которые лично мне не дают расслабиться когда я пишу на нем код, потому выбирать его для продакшена я пока не тороплюсь.
Создатели раста понимают необходимость решения проблемы возвращаемых ошибок и работают над тем, чтобы использовать их было удобно и не создавать лишнего бойлерплейта. Помимо unwrap-а как минимум есть варианты использовать цепочки обработки результата, как это обычно делают с Optional, и использовать макрос try! (?), который автоматически пробросит ошибку на верх.
Ну это же самый популярный аргумент сторонников эксепшенов, который звучал и будет звучать тысячи раз

Так это вы отвечали тем самым людям, что тысячи раз озвучивали этот аргумент или мне? Обычно если ваш комментарий под моим с отступом — это означает, что вы отвечаете мне, а я (если мне не изменяет память) ничего такого не писал. Я лишь сказал, что для меня это неудобно — про музыкальных кумиров и тупых разработчиков — это вы уже похоже сами додумали.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity