Раньше код был более оптимизирован, не смотря на сумбурность
Небось процессор такой, сидит и думает "раньше меня кормили каким-то совершенно невнятным кодом с кучей переходов во все стороны, которых не предскажешь и которые срывают мой конвеер. И еще обижались, что дескать, позаботились обо мне, вручную заоптимизировани, а я почему-то всё равно торможу. А сейчас в коде команд хоть и побольше, но мой приятель-компилятор знает, как их расположить, чтобы мне удобно исполнять было, и в итоге получается побыстрее".
Опасно то, что доступ к нефильтрованной информации стал очень простым и дешёвым. Вот она и засирает населению мозги. А AI там или википедия, особой разницы нет.
При этом подчеркну, я не считаю интернет особо чем-то вредным. Но когда мы идем по улице и видим валяющийся на земле пирожок, нормальный же человек не подымет и не засунет в рот. А вот информационный пирожок, валяющийся в интернете, каждый примерно первый подымет и засунет себе в голову.
Я видел на линуксах такое, что видеодрайвер AMD попутал свою видеопамять с page cache и разнёс файловую систему. И это современное ядро на более-менее современном ноутбуке. Помогло выключить IOMMU, а до того регулярно разносил, и даже partition table один раз разнёс.
И видел, как на некоторых ноутах отваливается тачпад потому, что когда от него приходит прерывание, то никто из драйверов не признаётся, что это евонное прерывание, и ядро его на всякий случай запрещает, как ничейное, и тачпад остаётся без прерываний и перестаёт работать. И даже хотфикс для этой проблемы написал (https://github.com/alexpevzner/hotfix-kvadra-touchpad) и в соответствующую ядерную почтовую группу рассылки жаловался, никто мне не ответил, так все, кому надо, до сих пор моим хотфиксом и пользуются.
И много чего другого видел. На современных вполне линуксах.
Вообще, на линуксе 15-летней давности uptime по году был вполне нормой. А сейчас, месяц продержался без перезагрузки, уже хорошо. Вон, иные сотовые телефоны с андроидом просто профилактически перегружаются ночью раз в сутки по расписанию.
Насчет BSOD на венде не скажу, поскольку мои пересечения с вендой очень незначительны. Но замечу ехидно, что современный корпоративный стиль программирования заключается в том, чтобы assert-ы и прочие самопроверки, которые могут отправить программу в полёт, в релизных сборках принято выключать, и уговорить граждан так не делать очень сложно (типа, зачем ты тут программу убиваешь, она бы, глядишь, еще пожила, а у ней там пользовательские данные). Так что может потому и не вылетают, что самопроверки отключены мудрым менеджерским указанием.
У вас, кажется, есть по статье на Хабре на все случаи жизни :)
Опять же, не соглашусь с той статьёй, но для разнообразия отвечу сюда.
Вопрос о доказательном программировании, как мне кажется, ищет ответ не на наивный вопрос, "как программировать без ошибок?", а на гораздо более глубокий вопрос: на что мы опираемся, рассуждая о корректности наших программ. Т.е., это размышления о размышлениях, часть философии, а не науки о тестировании ПО.
Что до неэквиавалентности теории и практики, (1) в теорию надо уметь (2) не так уж и много областей в нашей деятельности (ИТ) имеют хорошую теоретическую базу (3) там, где эта база есть, теория очень надёжна. Но повторюсь, в неё надо уметь.
Мне много раз приходилось слышать от т.наз. практиков насмешливые высказывания в адрес т.наз. теоретиков. Но всё это - нытьё в стиле, "тут не думать надо, а грушу трясти".
Кроме трех видов алгоритмических конструкций (следования, ветвления и повторения) требуется еще механизм обработки ошибок (исключений), а иногда обработка прерываний и выполнение параллельных действий, без которых полноценная реализация отдельных алгоритмов будет невозможна.
В Go прекрасно обходятся без исключений. Это может кому-то нравится, кому-то нет, но жить с этим можно, и особых неудобств не доставляет.
Что до параллельных вычислений, их принято осмыслять, как результат взаимодействия последовательных процессов, на эту тему есть классические работы у Дейкстры и Хоара.
Кроме того, мне кажется, вы не до конца понимаете, что такое алгоритм. Рассмотрим два фрагмента кода:
if (flag) {
x = a;
} else {
x = b;
}
и
x = b;
if (aflag) {
x = a;
}
Эти два фрагмента кода логически эквивалентны, и очень вероятно, что современный оптимизирующий компилятор превратит их в одинаковый ассемблерный код, но это два разных алгоритма.
Поэтому, разумеется, спагетти-код не может быть закодирован структурно, в силу определения того и другого, но он может быть преобразован в эквивалентный алгоритм, который ,может быть закодирован структурно.
В этой связи ваш тезис о невозможности "полноценной реализации некоторых алгоритмов" без исключений и т.п. представляется мне недостаточно обоснованным.
Стиль, одним из основателей которого был Дейкстра, называется "структурным программированием", потому что следование ему придаёт коду определенную структуру, состоящую из простых блоков (циклы, операторы ветвления, присваивания, вызовы процедур и т.п.). При этом разнообразие типов таких блоков невелико и блоки исполняются последовательно, имея одну входную и одну выходную точку.
Это делает код пригодным для анализа, ручного и автоматизированного
Угу. А эти "много софта", они, конечно, сделали нашу жизнь отчасти удобнее, т.е., решили некоторое количество наших проблем. С этим не поспоришь.
Интересно было бы задать вопрос, в каком отношении облегчение нашей жизни находится к количеству произведенного софта и к количеству усилий, потраченных на его разработку?
Корпорации очень хотят построить процесс, в котором стоимость разработки и качество результата не зависит от исполнителей.
Смешно при этом то, что почти любой корпоративный продукт (исключения бывают, но они редки) состоит процентов на 80, если не больше, из открытого кода, взятого с гитхаба. Где его разрабатывали, следуя совсем другим процессам.
Ну, я не сказал бы. Следование всем этим ритуалам создаёт изрядную ментальную нагрузку, умение это делать - вполне себе требование, при том нетривиальное.
Так что я не соглашусь, что требования снизились. Но характер их определенно изменился.
Мы получили негласный запрет на goto, ООП, области видимости, строгую типизацию, immutable обекты, 100% тестовое покрытие, линтеры и статический анализ кода, встроенные прямо в компилятор, обязательные к исполнению code style guides, работу строго по таскам и обязательное code review.
Чего мы так и не получили, это заметного улучшения качества софта в результате внедрения всех этих изнурительных ритуалов.
Процессы нужны. Они помогают победить хаос и навести порядок. Жить и работать в хаосе невозможно.
Но при этом ошибкой было бы считать, что идеальные процессы неизбежно гарантируют успех, а процессы, сделанные "не по науке" - наоборот.
Майкрософт, находясь в идеальной стартовой позиции, умудрились профукать появление Интернета и рынок мобильников. Уверен, что с процессами у них было всё хорошо.
Opensource, часто организованный никто не знает, как (что не означает, что у них нет процессов, но означает, что эти процессы организованы не по книжке, и часто не кодифицированы) показывает весьма впечатляющую эффективность во многих областях.
да со слайсами nil можно делать все кроме взятия значения по индексу и сета нового значения по индексу, все остальное будет работать
Ровно как и со слайсами нулевой длинны. и len() от nil-слайса возвращает 0.
Для new да я не уточнил, что возвращается указатель
Все-таки, я бы поспорил с Вашей классификацией на reference/value types. Указатель - определенно reference, создаётся вызовом new (или литералом). Указатель на функцию - определенно reference, создаётся путем описания анонимной функции или упоминанием имени неанонимной функции (или метода объекта). Может прихватывать данные, в случае замыкания.
Но если кто-то начинает считать время за кофе - это уже какая-то явно нездоровая история.
Я бы уволился без разговоров, если бы мне предъявили время за кофе :)
Между прочим, мне приходилось работать по контракту с почасовой оплатой на иностранного заказчика. Отчётность выглядит так: я выставляю счет на N часов и почасовой рейт, мне оплачивают. Никто с кейлогером за плечами не стоял.
Как выглядит контроль при этой схеме? Да очень просто, если я выставляю какое-то непомерное количество часов, а толку никакого, никто не будет мне предъявлять, что я мухлюю. А просто контракт не продлят. Я заинтересован в оплате моей работы, заказчик заинтересован в результате. Пока все получают своё, сотрудничество продолжается. Если кто-то не доволен, спокойно расстаёмся.
Ну, еще товарищ Брукс говорил, что серебряной пули не существует. А товарищ Сталин ему вторил, говоря, что кадры (т.е., люди, а не процессы) решают всё.
Фактически, вы сейчас с математическими выкладками в руках (и с неплохим стилем изложения) доказали, что людоедский подход к людям плохо работает и не оправдывает себя :)
Потому, что в бровсерах нет вменяемого UI для установки этого параметра. Поэтому у пользователей он в среднем не настроен.
Небось процессор такой, сидит и думает "раньше меня кормили каким-то совершенно невнятным кодом с кучей переходов во все стороны, которых не предскажешь и которые срывают мой конвеер. И еще обижались, что дескать, позаботились обо мне, вручную заоптимизировани, а я почему-то всё равно торможу. А сейчас в коде команд хоть и побольше, но мой приятель-компилятор знает, как их расположить, чтобы мне удобно исполнять было, и в итоге получается побыстрее".
Опасно то, что доступ к нефильтрованной информации стал очень простым и дешёвым. Вот она и засирает населению мозги. А AI там или википедия, особой разницы нет.
При этом подчеркну, я не считаю интернет особо чем-то вредным. Но когда мы идем по улице и видим валяющийся на земле пирожок, нормальный же человек не подымет и не засунет в рот. А вот информационный пирожок, валяющийся в интернете, каждый примерно первый подымет и засунет себе в голову.
Я видел на линуксах такое, что видеодрайвер AMD попутал свою видеопамять с page cache и разнёс файловую систему. И это современное ядро на более-менее современном ноутбуке. Помогло выключить IOMMU, а до того регулярно разносил, и даже partition table один раз разнёс.
И видел, как на некоторых ноутах отваливается тачпад потому, что когда от него приходит прерывание, то никто из драйверов не признаётся, что это евонное прерывание, и ядро его на всякий случай запрещает, как ничейное, и тачпад остаётся без прерываний и перестаёт работать. И даже хотфикс для этой проблемы написал (https://github.com/alexpevzner/hotfix-kvadra-touchpad) и в соответствующую ядерную почтовую группу рассылки жаловался, никто мне не ответил, так все, кому надо, до сих пор моим хотфиксом и пользуются.
И много чего другого видел. На современных вполне линуксах.
Вообще, на линуксе 15-летней давности uptime по году был вполне нормой. А сейчас, месяц продержался без перезагрузки, уже хорошо. Вон, иные сотовые телефоны с андроидом просто профилактически перегружаются ночью раз в сутки по расписанию.
Насчет BSOD на венде не скажу, поскольку мои пересечения с вендой очень незначительны. Но замечу ехидно, что современный корпоративный стиль программирования заключается в том, чтобы assert-ы и прочие самопроверки, которые могут отправить программу в полёт, в релизных сборках принято выключать, и уговорить граждан так не делать очень сложно (типа, зачем ты тут программу убиваешь, она бы, глядишь, еще пожила, а у ней там пользовательские данные). Так что может потому и не вылетают, что самопроверки отключены мудрым менеджерским указанием.
У вас, кажется, есть по статье на Хабре на все случаи жизни :)
Опять же, не соглашусь с той статьёй, но для разнообразия отвечу сюда.
Вопрос о доказательном программировании, как мне кажется, ищет ответ не на наивный вопрос, "как программировать без ошибок?", а на гораздо более глубокий вопрос: на что мы опираемся, рассуждая о корректности наших программ. Т.е., это размышления о размышлениях, часть философии, а не науки о тестировании ПО.
Что до неэквиавалентности теории и практики, (1) в теорию надо уметь (2) не так уж и много областей в нашей деятельности (ИТ) имеют хорошую теоретическую базу (3) там, где эта база есть, теория очень надёжна. Но повторюсь, в неё надо уметь.
Мне много раз приходилось слышать от т.наз. практиков насмешливые высказывания в адрес т.наз. теоретиков. Но всё это - нытьё в стиле, "тут не думать надо, а грушу трясти".
Не согласен. Ответил туда.
В Go прекрасно обходятся без исключений. Это может кому-то нравится, кому-то нет, но жить с этим можно, и особых неудобств не доставляет.
Что до параллельных вычислений, их принято осмыслять, как результат взаимодействия последовательных процессов, на эту тему есть классические работы у Дейкстры и Хоара.
Кроме того, мне кажется, вы не до конца понимаете, что такое алгоритм. Рассмотрим два фрагмента кода:
и
Эти два фрагмента кода логически эквивалентны, и очень вероятно, что современный оптимизирующий компилятор превратит их в одинаковый ассемблерный код, но это два разных алгоритма.
Поэтому, разумеется, спагетти-код не может быть закодирован структурно, в силу определения того и другого, но он может быть преобразован в эквивалентный алгоритм, который ,может быть закодирован структурно.
В этой связи ваш тезис о невозможности "полноценной реализации некоторых алгоритмов" без исключений и т.п. представляется мне недостаточно обоснованным.
Стиль, одним из основателей которого был Дейкстра, называется "структурным программированием", потому что следование ему придаёт коду определенную структуру, состоящую из простых блоков (циклы, операторы ветвления, присваивания, вызовы процедур и т.п.). При этом разнообразие типов таких блоков невелико и блоки исполняются последовательно, имея одну входную и одну выходную точку.
Это делает код пригодным для анализа, ручного и автоматизированного
Угу. А эти "много софта", они, конечно, сделали нашу жизнь отчасти удобнее, т.е., решили некоторое количество наших проблем. С этим не поспоришь.
Интересно было бы задать вопрос, в каком отношении облегчение нашей жизни находится к количеству произведенного софта и к количеству усилий, потраченных на его разработку?
Корпорации очень хотят построить процесс, в котором стоимость разработки и качество результата не зависит от исполнителей.
Смешно при этом то, что почти любой корпоративный продукт (исключения бывают, но они редки) состоит процентов на 80, если не больше, из открытого кода, взятого с гитхаба. Где его разрабатывали, следуя совсем другим процессам.
Ну, я не сказал бы. Следование всем этим ритуалам создаёт изрядную ментальную нагрузку, умение это делать - вполне себе требование, при том нетривиальное.
Так что я не соглашусь, что требования снизились. Но характер их определенно изменился.
Что именно проверить/измерить?
Мы получили негласный запрет на goto, ООП, области видимости, строгую типизацию, immutable обекты, 100% тестовое покрытие, линтеры и статический анализ кода, встроенные прямо в компилятор, обязательные к исполнению code style guides, работу строго по таскам и обязательное code review.
Чего мы так и не получили, это заметного улучшения качества софта в результате внедрения всех этих изнурительных ритуалов.
Процессы нужны. Они помогают победить хаос и навести порядок. Жить и работать в хаосе невозможно.
Но при этом ошибкой было бы считать, что идеальные процессы неизбежно гарантируют успех, а процессы, сделанные "не по науке" - наоборот.
Майкрософт, находясь в идеальной стартовой позиции, умудрились профукать появление Интернета и рынок мобильников. Уверен, что с процессами у них было всё хорошо.
Opensource, часто организованный никто не знает, как (что не означает, что у них нет процессов, но означает, что эти процессы организованы не по книжке, и часто не кодифицированы) показывает весьма впечатляющую эффективность во многих областях.
Ровно как и со слайсами нулевой длинны. и len() от nil-слайса возвращает 0.
Все-таки, я бы поспорил с Вашей классификацией на reference/value types. Указатель - определенно reference, создаётся вызовом new (или литералом). Указатель на функцию - определенно reference, создаётся путем описания анонимной функции или упоминанием имени неанонимной функции (или метода объекта). Может прихватывать данные, в случае замыкания.
Довольно скользкое утверждение, поскольку new возвращает не значение, а указатель на значение.
Слайсы довольно осмысленно ведут себя, если они - nil. У них нулевая длина и к ним можно append.
Я бы уволился без разговоров, если бы мне предъявили время за кофе :)
Между прочим, мне приходилось работать по контракту с почасовой оплатой на иностранного заказчика. Отчётность выглядит так: я выставляю счет на N часов и почасовой рейт, мне оплачивают. Никто с кейлогером за плечами не стоял.
Как выглядит контроль при этой схеме? Да очень просто, если я выставляю какое-то непомерное количество часов, а толку никакого, никто не будет мне предъявлять, что я мухлюю. А просто контракт не продлят. Я заинтересован в оплате моей работы, заказчик заинтересован в результате. Пока все получают своё, сотрудничество продолжается. Если кто-то не доволен, спокойно расстаёмся.
Ну, еще товарищ Брукс говорил, что серебряной пули не существует. А товарищ Сталин ему вторил, говоря, что кадры (т.е., люди, а не процессы) решают всё.
Фактически, вы сейчас с математическими выкладками в руках (и с неплохим стилем изложения) доказали, что людоедский подход к людям плохо работает и не оправдывает себя :)
Конференции - полезная штука. Позволяют отращивать личный бренд, если на них осмысленно выступать.