Для них сделали общую викторину в стиле «Кто хочет стать миллионером?»
можно предположить, что количество вариантов ответов могло быть больше двух. Собственно, там далее по тексту сразу следует пример с тремя вариантами ответа.
Если у вас такие жесткие требования, то на кой черт вы вообще используете кучу?
Мы не используем кучу в своём прикладном коде.
Если у вас неизвестен размер данных и позарез нужна куча - то делается свой аллокатор
Да, у нас есть свой аллокатор (блоков фиксированных размеров), для аллокации из своих же статичных пулов.
Если у вас образовался потенциальный намек на то, что у вас double free, use after free или банальное деление на ноль - это сигнал, что программой дальше пользоваться нельзя.
Всё так. Такое отлавливается при тестировании, если косяк именно в нашем коде. Но он не всегда именно там.
Как я уже говорил, кучу использует ось, используют либы. И если либы мы можем переписать, избавившись от использования динамической памяти (делаем по мере сил, но это не единомоментно, на это нужно время), с осью всё сильно сложнее (и ей же обычно больше доверяешь, сертификаты, все дела).
Могу привести пару конкретных примеров из жизни, почему внезапно падала программа, и как мы это исправляли.
Комплекс исправно работал на самолёте, но в какой-то момент появилась информация, что вычислители стали перезагружаться в процессе работы. Логи показали, что в какой-то момент ОСь не может выделить ресурс (создать семафор).
Оказалось, перед этим пилоты обновили полётную базу (xml- файл). И в этот раз база стала сильно больше размером. Соответственно, парсер XML (это был MiniXML) выделил в этот раз сильно больше памяти чем ранее. ПО кучу не использует, но остатка свободного места не хватило оси под свои объекты, в реалтайме.
Решение - сначала доработали MiniXML, чтобы аллоцировал из отдельного пула, не трогая системный. А потом написали свой парсер, который динамическую память не использует вовсе (а код оказался на порядок проще и быстрее, что очень кстати, т.к. MiniXML был крайне тормозной и сильно увеличивал время загрузки).
Аналогично, стала кончаться куча. Поймать утечку долго не удавалось. Оказалось, косяк был в самой ОС (в её штатной библиотеке поддержки SPE для PowerPC). Потокам, которые работают с floating-point, вешаются хуки на события переключения потоков, которые должны записывать и восстанавливать состояние FP-регистров. Для этого, при создании потока, система выделяет структуру. А вот на завершение потока хук просто не вешался, и, в итоге, структура оставалась не освобождённой. Оказалось, что временные сервисные потоки (создаваемые самой осью) забирали себе весь системный пул.
До сих пор не понимаю, как производители ОС такой косяк могли пропустить. Могу только предполагать, что аппаратную плавающую точку на SPE прочие заказчики не использовали, довольствуясь soft-fp, и мы просто оказались первыми.
Из моей практики. Watchdog, конечно, есть. И вычислители дублируются физически. Но время перезагрузки программы по нормативу - 30 сек. Мы укладываемся, но запас остаётся не большой. Если вычислитель не будет функционировать даже 20 секунд, это, вообще говоря, очень плохо, слишком много всего может случиться. Поэтому, если можно не падать, предпочитаем не падать. Естественно, все ошибки и потенциальные неисправности при этом логгируются, куда нужно отправляются, и ведётся сбор статистики. При достижении определённых условий может приниматься решение, что данному вычислителю доверять нельзя, и управление перейдёт резервному. Но это будет именно процедура, а не просто перезагрузка вычислителя в рандомный момент времени.
программа, в которой что-то дважды очистилось будет выдавать плохие данные
Как раз тогда, когда двойное освобождение/закрытие ресурса реализовано так, что ничего не портит (повторная операция игнорируется), плохих данных скорее всего не будет. Я это имел в виду.
Это приложение может оказаться прошивкой, управляющей, например, самолётом. Вы уверены, что предпочли бы в этом случае именно завершение приложения? Да, конечно, в таких случаях требования к коду обычно жёстче, а динамическую память часто и вовсе использовать запрещено. Но по факту она используется, пусть даже и не в самом прикладном коде, но в библиотеках, которые им используются, и в операционной системе. А ошибки в них тоже есть.
Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).
SVN, например, проще и интуитивно понятнее для не-программистов, которым объяснить идею и научить пользоваться системой контроля версий бывает достаточно сложно. А ещё у него очень удобные идентификаторы коммитов - простые и понятные всем числа, а не хэши. Идущие последовательно, так что по номеру ревизии сразу понятно, какая версия новее, какая старее, и т.п. Когда всё это дело активно используется, а репозиториев десятки и сотни, уйти на другую систему может быть достаточно сложно — взвешиваешь плюсы и минусы перехода, и плюсов оказывается меньше.
...LG запустила программу обновляемой техники. Президент компании объявил, что эта программа должна будет бросить вызов представлениям о том, что дорогая бытовая техника разрабатывается с учётом запланированного устаревания.
Я почему-то вижу тут некое противоречие. На моей практике, по крайней мере, всё хардовое и необновляемое — устаревало разве что морально (и то, с оговорками). А вот всё онлайново-обновляемое, наоборот устаревает как-то даже быстрее, иногда моментально (и, часто, именно по воле производителя). Старые плееры, консоли, телефоны, вот это вот всё, пусть даже этим девайсам десятки лет уже, но их включаешь, и оно работает. А с момента прихода в эти девайсы интернета и обновлений — уже не факт. Зависимость от серверов и сервисов рано или поздно превращает девайс в тыкву. И бытовуху, вроде стиральной машины, я хочу "тупую", насколько это возможно. Ещё мне не хватало в телефон лезть, чтобы стирку запустить, вместо того, чтобы просто кнопку нажать. Вообще, как по мне, вся эта нынешняя тенденция по "упрощению" физических интерфейсов посредством переноса их на тачскрины (в автомобилях) или на смарты (в бытовой технике) это просто удешевление производства под модным соусом "умности" и "современности".
Вот да, всё так и есть. Я поэтому стараюсь новичкам привить мысль, что в процессе разработки всегда нужно задумываться — а зачем именно мы делаем то, что делаем? Какова цель написания данного кода? Но всё равно, не всегда получается достигнуть понимания. Даёшь, допустим, несложную задачку на пару часов (ну там, скриптик написать, перекладывающий поток данных из COM-порта в сокет). Через неделю интересуешься, как там дела; отвечают, что нужно ещё полгода разработки ) Ээ, окей, а зачем? А вот, чтобы построить универсальную расширяемую архитектуру, красиво всё на паттернах запилить, и всё в таком духе... В очередной раз пытаешься объяснить, что здесь всё это совершенно не нужно, потому что задача вообще не в этом, а нужен простой скриптик на пол-страницы. На этом моменте, бывает, даже обижаются, что я ничего не понимаю и рушу их идеалы )
И ещё вот что интересное замечаю. Многие, видя большой, сложный, запутанный код, проникаются уважением к автору — мозг! Во какое написал! (разбираться в этом мы, конечно, не будем)). А когда встречают простой, короткий и понятный код от более опытного коллеги, думают — банальщина, неинтересно. И, наверное, так получается, что подсознательно хочется быть похожим на "мозга", чтобы и от твоего кода все "ахали".
Про "код — это пассив" — чистая правда. Но как же трудно бывает объяснить это новичкам. Что цель на самом деле — решить задачу, а не писать код. Я думаю, что частично понимаю причины такой ситуации — когда ты молод, позитивен, не "побит жизнью", когда ты всерьёз любишь кодить, когда голова свеженагружена шаблонами проектирования, бест-практиками, книжками, курсами и всем таким прочим по вкусу, то хочется быстрее применить всё это дело на практике. Но до чего это бывает гипер-выражено, это-ж словами не передать. Чем дальше, тем больше начинаю считать, что умелое удаление кода — даже более важный навык, чем его написание.
Думаю, конкретно такое сравнение некорректно. То, что происходит, больше похоже на эпоху индустриализации, когда станки стали заменять рабочие руки. И то, сравнение будет не совсем верным. Тогда заменяли руки, а мозги-то как раз становились нужнее, потому что машины нужно разрабатывать и обслуживать. Теперь же заменяют как раз мозги. А таких процессов и в таких масштабах я в истории не припомню. Это новое.
Быть может, замена условным гуглом мозгов не так и страшна была бы, если бы это хорошо работало где-то кроме шаблонных ситуаций вроде решения примера из домашки. Я стал замечать странную тенденцию - в моменты, когда поисковик решил бы проблему, люди его просто не используют (не умеют? не хотят? непонятно). Всё чаще сталкиваюсь с ситуациями, когда людям что-то нужно, причём ответ на вопрос чуть ли не первых строках выдачи будет, но они просто не ищут. И это я про программистов, если что.
Десятков тысяч, а так всё верно. Как только люди начали сильнее социализироваться, а потом от охоты/собирательства к земледелию постепенно переходить, так мозги скорее всего на спад и пошли, что вполне объяснимо - для успеха в деле выживания больше не нужно было быть условным мастером на все руки, ибо началось разделение труда и появились специализации.
Начиная со второй картинки статьи и дальше, сюжет всё сильнее напоминал мне сказку про кашу из топора. Первоначальная структура постепенно обвешивается, обвешиватся и обвешивается сторонними сервисами, децентрализация с каждым шагом уходит, и в конце оказывается, что собственно блокчейн это всего лишь один из многих квадратиков на схеме, не очень понятно зачем вообще теперь нужный.
У меня крепнет ощущение, что я был неправильно понят. Я ни в коем случае не предлагаю использовать final ни "для оптимизации", ни "на всякий случай". Только для того, для чего оно предназначено. Например, чтобы явно указать поддерживающему программисту, у которого по какой-то причине возникнет желание метод перегрузить, что он идёт в неверном направлении, и автором предполагалось, что работать оно должно не так, как он считает. Да, действительно, хорошо бы и комментарий иметь от автора, где сказано, почему оно так. Но один комментарий сам по себе делу может и не помочь, его могут не заметить; final же гарантирует, что не пропустят. А вероятность того, что код, возможно, станет чуточку быстрее, можно воспринимать просто как приятный бонус.
Для общего случая - целиком и полностью согласен. Всерьёз оптимизировать нужно там, где наличествуют бутылочные горлышки, а их покажут только замеры. Но здесь не тот случай. Я считаю, что добавление ключевого слова, которое придаст коду больше однозначности - само по себе полезно. Поэтому и считаю "бесплатным". Спецификатор override тоже ведь можно не писать (и я его поначалу его не использовал), но с ним код становится понятнее (и когда я это заметил, то стал стараться его использовать).
И не совсем оптимизация - ассемблерный выход с final и без может быть одинаков.
Да, и я именно это и имел в виду, когда писал, что "хуже не сделает". Если final делает код (или, может, видение автора кода) понятнее, и при этом даёт хотя бы малую вероятность, что станет чуть быстрее, почему бы его не использовать?
У меня ребёнок фоткает на свой кнопочный телефон домашние задания и не только, видосики снимает (оно там очень так себе, но его устраивает).
Судя по фразе
можно предположить, что количество вариантов ответов могло быть больше двух. Собственно, там далее по тексту сразу следует пример с тремя вариантами ответа.
Мы не используем кучу в своём прикладном коде.
Да, у нас есть свой аллокатор (блоков фиксированных размеров), для аллокации из своих же статичных пулов.
Всё так. Такое отлавливается при тестировании, если косяк именно в нашем коде. Но он не всегда именно там.
Как я уже говорил, кучу использует ось, используют либы. И если либы мы можем переписать, избавившись от использования динамической памяти (делаем по мере сил, но это не единомоментно, на это нужно время), с осью всё сильно сложнее (и ей же обычно больше доверяешь, сертификаты, все дела).
Могу привести пару конкретных примеров из жизни, почему внезапно падала программа, и как мы это исправляли.
Комплекс исправно работал на самолёте, но в какой-то момент появилась информация, что вычислители стали перезагружаться в процессе работы. Логи показали, что в какой-то момент ОСь не может выделить ресурс (создать семафор).
Оказалось, перед этим пилоты обновили полётную базу (xml- файл). И в этот раз база стала сильно больше размером. Соответственно, парсер XML (это был MiniXML) выделил в этот раз сильно больше памяти чем ранее. ПО кучу не использует, но остатка свободного места не хватило оси под свои объекты, в реалтайме.
Решение - сначала доработали MiniXML, чтобы аллоцировал из отдельного пула, не трогая системный. А потом написали свой парсер, который динамическую память не использует вовсе (а код оказался на порядок проще и быстрее, что очень кстати, т.к. MiniXML был крайне тормозной и сильно увеличивал время загрузки).
Аналогично, стала кончаться куча. Поймать утечку долго не удавалось. Оказалось, косяк был в самой ОС (в её штатной библиотеке поддержки SPE для PowerPC). Потокам, которые работают с floating-point, вешаются хуки на события переключения потоков, которые должны записывать и восстанавливать состояние FP-регистров. Для этого, при создании потока, система выделяет структуру. А вот на завершение потока хук просто не вешался, и, в итоге, структура оставалась не освобождённой. Оказалось, что временные сервисные потоки (создаваемые самой осью) забирали себе весь системный пул.
До сих пор не понимаю, как производители ОС такой косяк могли пропустить. Могу только предполагать, что аппаратную плавающую точку на SPE прочие заказчики не использовали, довольствуясь soft-fp, и мы просто оказались первыми.
Из моей практики. Watchdog, конечно, есть. И вычислители дублируются физически. Но время перезагрузки программы по нормативу - 30 сек. Мы укладываемся, но запас остаётся не большой. Если вычислитель не будет функционировать даже 20 секунд, это, вообще говоря, очень плохо, слишком много всего может случиться. Поэтому, если можно не падать, предпочитаем не падать. Естественно, все ошибки и потенциальные неисправности при этом логгируются, куда нужно отправляются, и ведётся сбор статистики. При достижении определённых условий может приниматься решение, что данному вычислителю доверять нельзя, и управление перейдёт резервному. Но это будет именно процедура, а не просто перезагрузка вычислителя в рандомный момент времени.
Как раз тогда, когда двойное освобождение/закрытие ресурса реализовано так, что ничего не портит (повторная операция игнорируется), плохих данных скорее всего не будет. Я это имел в виду.
Это приложение может оказаться прошивкой, управляющей, например, самолётом. Вы уверены, что предпочли бы в этом случае именно завершение приложения? Да, конечно, в таких случаях требования к коду обычно жёстче, а динамическую память часто и вовсе использовать запрещено. Но по факту она используется, пусть даже и не в самом прикладном коде, но в библиотеках, которые им используются, и в операционной системе. А ошибки в них тоже есть.
Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).
Под какую корку? ) Наверное всё-таки "уйдёт в подкорку", это же про вполне конкретные отделы мозга выражение, которые в обиходе "подкоркой" именуют.
SVN, например, проще и интуитивно понятнее для не-программистов, которым объяснить идею и научить пользоваться системой контроля версий бывает достаточно сложно. А ещё у него очень удобные идентификаторы коммитов - простые и понятные всем числа, а не хэши. Идущие последовательно, так что по номеру ревизии сразу понятно, какая версия новее, какая старее, и т.п. Когда всё это дело активно используется, а репозиториев десятки и сотни, уйти на другую систему может быть достаточно сложно — взвешиваешь плюсы и минусы перехода, и плюсов оказывается меньше.
По-моему, Интернет в списке лишний. Это не научное, и не открытие. Это технология, плод труда инженеров. Вакцина(ы) от Covid-19 — аналогично.
Я почему-то вижу тут некое противоречие. На моей практике, по крайней мере, всё хардовое и необновляемое — устаревало разве что морально (и то, с оговорками). А вот всё онлайново-обновляемое, наоборот устаревает как-то даже быстрее, иногда моментально (и, часто, именно по воле производителя). Старые плееры, консоли, телефоны, вот это вот всё, пусть даже этим девайсам десятки лет уже, но их включаешь, и оно работает. А с момента прихода в эти девайсы интернета и обновлений — уже не факт. Зависимость от серверов и сервисов рано или поздно превращает девайс в тыкву. И бытовуху, вроде стиральной машины, я хочу "тупую", насколько это возможно. Ещё мне не хватало в телефон лезть, чтобы стирку запустить, вместо того, чтобы просто кнопку нажать. Вообще, как по мне, вся эта нынешняя тенденция по "упрощению" физических интерфейсов посредством переноса их на тачскрины (в автомобилях) или на смарты (в бытовой технике) это просто удешевление производства под модным соусом "умности" и "современности".
Вот да, всё так и есть. Я поэтому стараюсь новичкам привить мысль, что в процессе разработки всегда нужно задумываться — а зачем именно мы делаем то, что делаем? Какова цель написания данного кода? Но всё равно, не всегда получается достигнуть понимания. Даёшь, допустим, несложную задачку на пару часов (ну там, скриптик написать, перекладывающий поток данных из COM-порта в сокет). Через неделю интересуешься, как там дела; отвечают, что нужно ещё полгода разработки ) Ээ, окей, а зачем? А вот, чтобы построить универсальную расширяемую архитектуру, красиво всё на паттернах запилить, и всё в таком духе... В очередной раз пытаешься объяснить, что здесь всё это совершенно не нужно, потому что задача вообще не в этом, а нужен простой скриптик на пол-страницы. На этом моменте, бывает, даже обижаются, что я ничего не понимаю и рушу их идеалы )
И ещё вот что интересное замечаю. Многие, видя большой, сложный, запутанный код, проникаются уважением к автору — мозг! Во какое написал! (разбираться в этом мы, конечно, не будем)). А когда встречают простой, короткий и понятный код от более опытного коллеги, думают — банальщина, неинтересно. И, наверное, так получается, что подсознательно хочется быть похожим на "мозга", чтобы и от твоего кода все "ахали".
Про "код — это пассив" — чистая правда. Но как же трудно бывает объяснить это новичкам. Что цель на самом деле — решить задачу, а не писать код. Я думаю, что частично понимаю причины такой ситуации — когда ты молод, позитивен, не "побит жизнью", когда ты всерьёз любишь кодить, когда голова свеженагружена шаблонами проектирования, бест-практиками, книжками, курсами и всем таким прочим по вкусу, то хочется быстрее применить всё это дело на практике. Но до чего это бывает гипер-выражено, это-ж словами не передать. Чем дальше, тем больше начинаю считать, что умелое удаление кода — даже более важный навык, чем его написание.
А почему "белый дварф"? Аж глаз режет. По-русски такие звёзды "белыми карликами" всю жизнь были.
Думаю, конкретно такое сравнение некорректно. То, что происходит, больше похоже на эпоху индустриализации, когда станки стали заменять рабочие руки. И то, сравнение будет не совсем верным. Тогда заменяли руки, а мозги-то как раз становились нужнее, потому что машины нужно разрабатывать и обслуживать. Теперь же заменяют как раз мозги. А таких процессов и в таких масштабах я в истории не припомню. Это новое.
Быть может, замена условным гуглом мозгов не так и страшна была бы, если бы это хорошо работало где-то кроме шаблонных ситуаций вроде решения примера из домашки. Я стал замечать странную тенденцию - в моменты, когда поисковик решил бы проблему, люди его просто не используют (не умеют? не хотят? непонятно). Всё чаще сталкиваюсь с ситуациями, когда людям что-то нужно, причём ответ на вопрос чуть ли не первых строках выдачи будет, но они просто не ищут. И это я про программистов, если что.
Десятков тысяч, а так всё верно. Как только люди начали сильнее социализироваться, а потом от охоты/собирательства к земледелию постепенно переходить, так мозги скорее всего на спад и пошли, что вполне объяснимо - для успеха в деле выживания больше не нужно было быть условным мастером на все руки, ибо началось разделение труда и появились специализации.
Начиная со второй картинки статьи и дальше, сюжет всё сильнее напоминал мне сказку про кашу из топора. Первоначальная структура постепенно обвешивается, обвешиватся и обвешивается сторонними сервисами, децентрализация с каждым шагом уходит, и в конце оказывается, что собственно блокчейн это всего лишь один из многих квадратиков на схеме, не очень понятно зачем вообще теперь нужный.
У меня крепнет ощущение, что я был неправильно понят. Я ни в коем случае не предлагаю использовать final ни "для оптимизации", ни "на всякий случай". Только для того, для чего оно предназначено. Например, чтобы явно указать поддерживающему программисту, у которого по какой-то причине возникнет желание метод перегрузить, что он идёт в неверном направлении, и автором предполагалось, что работать оно должно не так, как он считает. Да, действительно, хорошо бы и комментарий иметь от автора, где сказано, почему оно так. Но один комментарий сам по себе делу может и не помочь, его могут не заметить; final же гарантирует, что не пропустят. А вероятность того, что код, возможно, станет чуточку быстрее, можно воспринимать просто как приятный бонус.
Для общего случая - целиком и полностью согласен. Всерьёз оптимизировать нужно там, где наличествуют бутылочные горлышки, а их покажут только замеры. Но здесь не тот случай. Я считаю, что добавление ключевого слова, которое придаст коду больше однозначности - само по себе полезно. Поэтому и считаю "бесплатным". Спецификатор override тоже ведь можно не писать (и я его поначалу его не использовал), но с ним код становится понятнее (и когда я это заметил, то стал стараться его использовать).
Да, и я именно это и имел в виду, когда писал, что "хуже не сделает". Если final делает код (или, может, видение автора кода) понятнее, и при этом даёт хотя бы малую вероятность, что станет чуть быстрее, почему бы его не использовать?
Пусть даже оптимизация в конкретном случае окажется и не шибко эффективная, но если она "бесплатная", то почему бы нет? Хуже-то точно не сделает.