То есть, другими словами, консюмеризм нас окончательно одолеет, а сколько-нибудь полезные вещи сместятся в область профессиональных и дорогих решений? Хотелось бы верить в иное, хотя…
Вы склонны переоценивать возможности JVM и .Net. Их тоже люди пишут. Хуже того: их пишут корпоративные программисты. Так что повторюсь: может != делает.
Может != делает. Сложность этого процесса такова, что разработка вменяемой VM стоит сумасшедших денег. Но и тогда в приоритете — надёжность, что не позволяет внедрять самые агрессивные способы оптимизации. Так что в реальности всё намного грустнее, чем в теории…
Здесь, говоря об инструментах (ЯП и их парадигмах), почему-то забыли о тех, кто ими пользуется (программистах). А ведь они, люди, важнее всего.
Программа — это изложение мыслей. И у каждого человека свой образ мышления. Кому-то удобнее облекать свои мысли в форму объектов и сообщений. Кому-то — в функции, монады, предикаты или даже списки.
Так что помимо пригодности инструмента для решения задач, нужно ещё помнить об умениях. Умения куда полезнее теорий в нашем программистском деле. Вполне может так получиться, что используя не самый «пригодный» для задачи инструмент, мастер сделает дело быстрее и лучше, чем «понимающий» программист, использующий «самый подходящий» инструмент.
Нет, не учитывал. Может, в этом и дело. Но в наборах 6 и 7, тесты на которые провалились, буквы по два раза не повторяются. Может, просто проверялось на другом наборе тестовых данных.
Так в том-то и дело, что прогнал, выяснил, что буквы должны считаться по одному разу, а иначе ответы не сходятся, исправил, прогнал снова — и тогда всё заработало. Есть подозрение, что на странице с задачей у них были одни ответы, а на сервере — другие.
Мда, интересно, а это общее правило иметь недоговорённости в постановке задач, или просто мой английский настолько плох? Да и странные результаты какие-то. Дважды проверил, что все тесты проходят, а в результатах — тесты провалены. где я накосячил?
Да не делают технологии нас ни умнее, ни глупее сами по себе. Технологии лишь предоставляют возможности. А уж как ими человек распорядится — зависит от человека.
В частности, если человек ленив и пассивен, не привык думать своей головой, то информационные технологии дают ему возможность не думать своей головой и дальше, тем самым усугубляя его лень и пассивность. Зачем думать и принимать решения, если можно посмотреть в интернете? Об этом речь ведут адекватные «критики», а не о том, что технологии-зло.
А нельзя просто проект добавить в портфолио, без картинок, но с названием и описанием? Есть же кроме GitHub способы свои проекты публиковать. Например, собственный сайт. И на этом сайте много текста и нет картинок например…
Не знаю, откуда у вас взялось такое ощущение. Я нигде не говорил, что не пишу тесты. Я никогда не говорил, что не делаю проверок. Напротив, я не доверяю ни себе, ни другим, а потому стараюсь писать код таким образом, чтобы предотвратить ошибки или по крайней мере выявить и исправить их как можно раньше. Однажды я выгнал перфекциониста с проекта (так же, как выгнал лентяя). Даже зная что программист этот лучше, чем я. Но неспособность давать результат вовремя — непростительна. Результат — вот мой приоритет. И в понятие результата я вкладываю больше, чем вам хотелось бы думать, не скатывайтесь в банальности на этот счёт. И да, я не знаю что такое «так себе качество». Есть стоимость написания, есть стоимость поддержки, есть стоимость ошибок. Идеальный код — это код, который минимизирует их сумму. Всё!
Нет, не наводит. Ибо перфекционизмом страдал и сам. Вылечился, чего и вам желаю. Вполне может оказаться, что я пишу код быстрее, качественнее и надёжнее, чем вы. Мы ведь этого не знаем, верно? Ведь ни вы, ни я всех своих практик здесь не обсуждали. Может, мои методы работы ничем не уступают вашим? Да, я гораздо терпимее к тому, что вам не нравится, и терминов типа «говнокод» не использую. Я просто заставляю работать то, что не могут довести до ума ни халтурщики (потому что им это не надо), ни перфекционисты (потому что их переводят на «более важные» проекты, а по факту — они уже отъели слишком много времени и ресурсов, а результата так и нет).
Думаю, обсуждать нам больше нечего. У нас разные приоритеты, аксиоматика, если вы понимаете о чём я. Так что даже убедительные доказательства не помогут нам договориться…
Не придирайтесь к словам. Вы прекрасно поняли о чём речь в выражении «ошибка вследствие попытки использования нулевого указателя». Если всё ещё прикидываетесь: Речь не об использовании, а об ошибке, то есть ошибочном использовании.
Почему, собственно, вряд ли?
Потому что это правда. Мало кто делает подобные проверки во внутренней логике. Как максимум — в публичном API, да и то не всегда. Почему? Да потому что работу делают, а не маятся чесотошным перфекционизмом.
Я уже ответил о причинах выбора NPE — для null, IAE — для неверных значений. Ситуации, приводящие к возникновению того и другого — совершенно разные (неполученные данные/неверные данные). А значит и анализ, и разбор ошибок будут разными.
Свои предпочтения я основываю на практике. И на практике я встречал разные подходы. Никаких принципиальных предпочтений у меня на этот счёт нет — есть оценка практической полезности того или иного подхода. Я не увидел у вас убедительного обоснования использования IAE для null с точки зрения практической полезности — вы столь же субъективны, как и я. Но я, в отличие от вас, этого не скрываю (хуже, если вы руководствуетесь мнением «просветлённых мужей», а не своим собственным опытом).
Отвечу на 3., если вам ещё не понятна моя позиция: нет, не странно. Логика выбора NullPointerException — очень простая и прямолинейная, и следует из названия — ошибка вследствие попытки использования нулевого указателя.
Что касается использования assert, то они и служат для отлова ситуаций на стадии тестирования и отладки. Ситуация с возникновением null, в частности, как правило означает ошибку именно в логике программы, а не случайную флуктуацию данных. Если последняя возникает, то врядли на пути распространения её последствий окажется нужная проверка. Если только это не пользовательские данные, которые обычно проверяются куда более дотошно, чем внутренняя логика. Легко сказать, что это неправильно, но что поделать? В реальном мире живём.
Как-то сложно всё это для меня. Когда я вижу NullPointerException, то знаю, что это попытка использования нулевого указателя. Не очень важно: содержится ли в этом исключении дополнительная информация. Совершенно не важно: исключение выкинуто явно или автоматически. null! Нужно найти причину. И причина наверняка не там, где это исключение возникло, и даже не в стеке вызова — она где-то выше по коду. Этого мне достаточно для начала поиска ошибки.
4. При проверке параметров запросов на веб-страницах на исключения никогда не полагаюсь.
5. Предпочту не связываться с исключениями в данной ситуации. Метод будет возвращать результат, в котором будет содержаться признак успешности. Если это невозможно, а сигнал о потенциальном переполнении стека посылать придётся — то да, использую StackOverflowError.
Я считаю использование NPE логичным и полезным для ситуации с null. И плевать, если кто-то считает это неправильным (логично, но неправильно — это вообще как?).
А вообще предпочитаю использовать
assert param != null :
"Param not specified";
и включать -ea:my.package... для тестов, и, иногда, для отладки.
И ещё одно. Я не видел, чтобы кто-то явно передавал null в метод, в который null передавать нельзя. Скорее это означает, что null вернулся откуда-то ещё. Что-то пошло не так, как ожидалось. В этом случае NPE в логе гораздо информативнее IAE, особенно если это IAE не содержит толкового объяснения что не так.
Программа — это изложение мыслей. И у каждого человека свой образ мышления. Кому-то удобнее облекать свои мысли в форму объектов и сообщений. Кому-то — в функции, монады, предикаты или даже списки.
Так что помимо пригодности инструмента для решения задач, нужно ещё помнить об умениях. Умения куда полезнее теорий в нашем программистском деле. Вполне может так получиться, что используя не самый «пригодный» для задачи инструмент, мастер сделает дело быстрее и лучше, чем «понимающий» программист, использующий «самый подходящий» инструмент.
В частности, если человек ленив и пассивен, не привык думать своей головой, то информационные технологии дают ему возможность не думать своей головой и дальше, тем самым усугубляя его лень и пассивность. Зачем думать и принимать решения, если можно посмотреть в интернете? Об этом речь ведут адекватные «критики», а не о том, что технологии-зло.
Думаю, обсуждать нам больше нечего. У нас разные приоритеты, аксиоматика, если вы понимаете о чём я. Так что даже убедительные доказательства не помогут нам договориться…
Потому что это правда. Мало кто делает подобные проверки во внутренней логике. Как максимум — в публичном API, да и то не всегда. Почему? Да потому что работу делают, а не маятся чесотошным перфекционизмом.
Свои предпочтения я основываю на практике. И на практике я встречал разные подходы. Никаких принципиальных предпочтений у меня на этот счёт нет — есть оценка практической полезности того или иного подхода. Я не увидел у вас убедительного обоснования использования IAE для null с точки зрения практической полезности — вы столь же субъективны, как и я. Но я, в отличие от вас, этого не скрываю (хуже, если вы руководствуетесь мнением «просветлённых мужей», а не своим собственным опытом).
Отвечу на 3., если вам ещё не понятна моя позиция: нет, не странно. Логика выбора NullPointerException — очень простая и прямолинейная, и следует из названия — ошибка вследствие попытки использования нулевого указателя.
Что касается использования assert, то они и служат для отлова ситуаций на стадии тестирования и отладки. Ситуация с возникновением null, в частности, как правило означает ошибку именно в логике программы, а не случайную флуктуацию данных. Если последняя возникает, то врядли на пути распространения её последствий окажется нужная проверка. Если только это не пользовательские данные, которые обычно проверяются куда более дотошно, чем внутренняя логика. Легко сказать, что это неправильно, но что поделать? В реальном мире живём.
4. При проверке параметров запросов на веб-страницах на исключения никогда не полагаюсь.
5. Предпочту не связываться с исключениями в данной ситуации. Метод будет возвращать результат, в котором будет содержаться признак успешности. Если это невозможно, а сигнал о потенциальном переполнении стека посылать придётся — то да, использую StackOverflowError.
Я считаю использование NPE логичным и полезным для ситуации с null. И плевать, если кто-то считает это неправильным (логично, но неправильно — это вообще как?).
А вообще предпочитаю использовать
и включать
-ea:my.package...для тестов, и, иногда, для отладки.