А г… нокодом, значит, называют не конкретные личности?
Ваш опыт основам на дискуссиях о Вашем коде? Если да, не допускаете ли Вы мысли, что дело в Вашем коде, а не в таксичных программистах?
Всё познаётся в сравнении. 3% это мало если мы говорим про доли метра, к примеру. А в данном случае мы говорим о компании с стоимостью сотни миллионов долларов, и проценты тут исчисляются, по меньшей мере, в сотнях тысяч долларов.
А радиоактивный распад открыли ради развития энергетики, а не создания оружия, ну да.
Радиоактивный распад просто открыли, не для чего-то. Потом оказалось, что из этого выделяется энергия, и появились две дороги развития: применение в энергетике, и применение в качестве оружия. Люди, оплачивавшие весь тот банкет, решили, что им в данный момент важнее оружие, а не энергетика.
Иначе мы тут договоримся, будто колесо открыли чтобы танки делать.
Я вовсе не утверждал, что конкретно этот код можно заменить сотней строк, просто выразил неудовольствие подходом «раз сделано сложно, значит так было надо». Я слишком часто вижу, что сложный код для работы с простым проблемным доменом (а проблема возвратить [0; n) элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.
Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методов getLength<Property> и getElement<Property>(index). Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.
Думаю, стоит всё же объяснить — в чём же сложность решения проблемы потенциального наличия во многих свойствах [0..n) значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?
Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.
К сожалению, самостоятельно исторические данные найти не смог, но согласно вот этой статье, в том же индексе Kotlin за один год вырос с ~65 места до 36-го, а это более чем двукратный рост. А учитывая что пока что Гугл старается как можно больше разработчиком переместить с Java на Kotlin, укрепление позиций среди задаваемых вопросов на StackOverflow может будет продолжаться как минимум до поры когда в Гугле найдут новую игрушку.
Грубовато, зато честно — прямо указывается, какой именно элемент bathroom тебе интересен в данный момент. Иначе разница примерно как между вопросами «где тут туалет?» и «где я могу припудрить носик?», и закономерную возможность в ответ на второй вопрос получить указания по пути до ближайшего зеркала.
То есть логичная и развитая система типов это больше про академические задачи, а не про практическиe.
"Это не про практические задачи" — это такой тонкий способ сказать что конкретно? Вот язык Kotlin — по вашей логике, он решает больше академические задачи? Ведь там нет исключений, и число является объектным типом первого класса. Только заточен ли Kotlin под академические задачи, или всё же он ближе "к станку", раз уж его в Гугле полюбили настолько, что пытаются заменить им Java, в котором исключения из системы типов присутствуют? Достаточно ли Kotlin императивен и мейнстримен?
А я вот исхожу. Потому что в логичной и развитой системе типов не должно быть произвольных исключений, вроде «это вот имеет интерфейс, а вот это не имеет». Число — это тип, не хуже любого другого типа. И у него тоже есть интерфейсы, обычно даже больше одного, в зависимости от самого числа.
Тем более типы тут ни при чём, такие вещи должны отлавливаться на приёмочном тестировании. И всего-то достаточно однострочного теста myFunction(0);
чтобы проект перестал компилироваться, и кто нужно разобрался как следует и наказал кого попало.
Динамические слабые языки хороши обычно во всяких сценариях, когда ошибочный результат не так уж сильно заметен. Типа нарисовали врага на полпикселя левее — ну и хрен бы с ним. Поэтому они почти всегда используются как скриптовые языки в игровых движках и редакторах карт.
Может моё мнение непопулярное, но нечего делать операциям XOR и AND на типе, представляющем число, потому что это будет ограничивать возможную реализацию самого числа и требовать, чтобы число было расширением типа BitSet.
А если интерфейс BitSet из интерфейса числа исключить, то остаётся так уж много способов проверить на неотрицательность, и уж с ними компилятор как-нибудь справится.
Перефразируйте вопрос.
«неотрицательный» — это value >= 0
«положительный» — это value > 0
От понимания двух этих слов человеком (равно как от отсутствия понимания) в коде программы ничего не зависит.
Вообще говоря, если определить функцию doTimes(положительный times),
а потом Вася попытается её вызывать как doTimes(0);
doTimes(-1);
и его код не скомпилируется, то виноват Вася, а не компилятор.
Просто нужно определиться, что дороже — потенциальная невозможность откатить изменение схемы, или необходимость конкретное изменение поддерживать в течение некоторого времени, пока не станет ясно, что точно ничего не сломалось.
Разумеется, здесь каждый будет решать по себе, серебряных пуль не завезли.
А г… нокодом, значит, называют не конкретные личности?
Ваш опыт основам на дискуссиях о Вашем коде? Если да, не допускаете ли Вы мысли, что дело в Вашем коде, а не в таксичных программистах?
… и услужливо предоставят ссылочку на установщик.
Всё познаётся в сравнении. 3% это мало если мы говорим про доли метра, к примеру. А в данном случае мы говорим о компании с стоимостью сотни миллионов долларов, и проценты тут исчисляются, по меньшей мере, в сотнях тысяч долларов.
Радиоактивный распад просто открыли, не для чего-то. Потом оказалось, что из этого выделяется энергия, и появились две дороги развития: применение в энергетике, и применение в качестве оружия. Люди, оплачивавшие весь тот банкет, решили, что им в данный момент важнее оружие, а не энергетика.
Иначе мы тут договоримся, будто колесо открыли чтобы танки делать.
[0; n)элементов — это простая проблема) это скорее признак недостаточного понимания, чем признак того, что проблема на самом-то деле сложна.Конкретно по этому коду моё лично впечатление от представленных кусочков — это, банально, легаси-код. Сначала там всегда был один элемент и ошибка если его нет, но просят. Потом оказалось, что значений бывает несколько, но старый код для одного значения решено было оставить для краевых случаев (надеюсь, с ошибкой если просят один, а на самом деле там несколько). Потому были добавлены семейства методов
getLength<Property>иgetElement<Property>(index). Идея позволить доступ обычной итерацией тогда никому в голову не пришла, а когда пришла — уже был написан код, ломать который просто так никто не захотел, и прежние два метода с доступом по индексу убирать не стали.[0..n)значений? Первопричина этого мне понятна — там действительно может много значений, а может не быть ни одного. Но настолько ли эта причина глубокая?Если проблема кажется простой, но простой на самом деле не является, то стоит объяснять, почему она не простая, а не спрыгивать тут же на «лучшие умы целым отделом полгода думали, как лучше сделать, так что нечего лезть со своими предложениями». А иногда простые проблемы — это действительно простые проблемы, с простыми решениями.
"Это не про практические задачи" — это такой тонкий способ сказать что конкретно? Вот язык Kotlin — по вашей логике, он решает больше академические задачи? Ведь там нет исключений, и число является объектным типом первого класса. Только заточен ли Kotlin под академические задачи, или всё же он ближе "к станку", раз уж его в Гугле полюбили настолько, что пытаются заменить им Java, в котором исключения из системы типов присутствуют? Достаточно ли Kotlin императивен и мейнстримен?
addElement, как вот тутmyFunction(0);чтобы проект перестал компилироваться, и кто нужно разобрался как следует и наказал кого попало.
Да, а потом происходит вот так: https://habr.com/post/417435/
А если интерфейс BitSet из интерфейса числа исключить, то остаётся так уж много способов проверить на неотрицательность, и уж с ними компилятор как-нибудь справится.
«неотрицательный» — это
value >= 0«положительный» — это
value > 0От понимания двух этих слов человеком (равно как от отсутствия понимания) в коде программы ничего не зависит.
Вообще говоря, если определить функцию
doTimes(положительный times),а потом Вася попытается её вызывать как
doTimes(0);doTimes(-1);
и его код не скомпилируется, то виноват Вася, а не компилятор.
Разумеется, здесь каждый будет решать по себе, серебряных пуль не завезли.