Comments 63
можно ли писать код без хаоса(goto)?
Э. Дейкстра писал не про отказ от оператора goto, а про улучшение стиля программного кода и автоматизации доказательства правильности программ за счет отказа от инструкций, меняющих ход алгоритма, и это не только goto, но и операторы присвоения: "Оператор goto позволяет нам посредством перехода назад повторить часть программы, тогда как оператор присвоения может создать необходимое различие в состоянии между последовательными повторениями."
Вот только почему-то никто не предлагает отказаться от операторов присвоения (кроме промежуточного представления SSA), впрочем, как и goto использовать не прекратили :-).
Стиль, одним из основателей которого был Дейкстра, называется "структурным программированием", потому что следование ему придаёт коду определенную структуру, состоящую из простых блоков (циклы, операторы ветвления, присваивания, вызовы процедур и т.п.). При этом разнообразие типов таких блоков невелико и блоки исполняются последовательно, имея одну входную и одну выходную точку.
Это делает код пригодным для анализа, ручного и автоматизированного
Это делает код пригодным для анализа, ручного и автоматизированного
К сожалению, все немного не так: https://habr.com/ru/articles/784238/
Не согласен. Ответил туда.
Довольно очевидная вещь, которую сходу можно доказать минимум 2я способами (сверху и снизу).
И если в качестве "исторической точности" ещё могут быть вопросы (ну типа они там доказали с большими дырками), то с точки зрения принципиальной возможности избавления - вообще не понятно в чём проблема.
1.
Частично-рекурсивные ф-ии <=> машине тьюринга.
Частично-рекурсивные ф-ии можно реализовать при помощи "присваиваний-ветвлений-циклов".
Доказано.
2.
В любом коде можно последовательно избавиться от:
- рекурсии
- exception.
- на SSA-представлении нормализовать циклы (привести в каноническую форму) => избавиться от goto.
(способ избавления а также что такое SSA-форма предоставляем как самостоятельное упражнение для любознательного читателя).
Перевести в псевдо-процедурный язык.
Это еще что, люди раньше руками ели, а сейчас нас ограничивают всякими ложками и вилками :)
Мы получили негласный запрет на goto, ООП, области видимости, строгую типизацию, immutable обекты, 100% тестовое покрытие, линтеры и статический анализ кода, встроенные прямо в компилятор, обязательные к исполнению code style guides, работу строго по таскам и обязательное code review.
Чего мы так и не получили, это заметного улучшения качества софта в результате внедрения всех этих изнурительных ритуалов.
Но мы получили большое снижение требований к писателям софта
это вероятно следствие снижения требований к качеству sw, что стало в большой части ширпотребом, чего не было в те далекие времена, типа из ресторана сделали fast food, дешево и сердито, интересные проекты никуда не делись, но их на всех не хватает
Ну, я не сказал бы. Следование всем этим ритуалам создаёт изрядную ментальную нагрузку, умение это делать - вполне себе требование, при том нетривиальное.
Так что я не соглашусь, что требования снизились. Но характер их определенно изменился.
А следствием этого стало распухшее до гигабайтов ПО которое могло занимать килобайты. И еще одно следствие: железо становится мощнее а воспринимаемая скорость работы с компьютером, как и прежде, как из мема названия ПК "супертормоз 2000".
ритуалы сами по себе пустой звук, качество кода зависит от исполнителей, какой толк от разнообразного инструмента, если врач не умеет его использовать,
начинал работать супер давно, могу сказать, что программисты точно были не глупее
Корпорации очень хотят построить процесс, в котором стоимость разработки и качество результата не зависит от исполнителей.
Смешно при этом то, что почти любой корпоративный продукт (исключения бывают, но они редки) состоит процентов на 80, если не больше, из открытого кода, взятого с гитхаба. Где его разрабатывали, следуя совсем другим процессам.
есть такое противоречие, привыкли считать людей типа мебелью, везде так где ширпотреб делают
Довольно сильное заявление про 80 процентов открытого кода, взятого с гитхаба) Более того, "выложенный на гитхабе" != "разработан по другим процессам", т.к. там уйма открытого кода, написанного теми самыми корпорациями ;)
А как можно проверить, или хотя-бы измерить?
Зато мы получили много софта.
Это же классика - улучшением инструментов мы не начинаем работать меньше, мы начинаем выполнять больше работы.
Зато мы получили много софта.
Угу. А эти "много софта", они, конечно, сделали нашу жизнь отчасти удобнее, т.е., решили некоторое количество наших проблем. С этим не поспоришь.
Интересно было бы задать вопрос, в каком отношении облегчение нашей жизни находится к количеству произведенного софта и к количеству усилий, потраченных на его разработку?
вопрос интересный - облегчение жизни и пр. это из области общественных интересов, изготовление sw теперь большей частью бизнес, side effect - кто знает, что более опасно CO2 или AI
кто знает, что более опасно CO2 или AI
Опасно то, что доступ к нефильтрованной информации стал очень простым и дешёвым. Вот она и засирает населению мозги. А AI там или википедия, особой разницы нет.
При этом подчеркну, я не считаю интернет особо чем-то вредным. Но когда мы идем по улице и видим валяющийся на земле пирожок, нормальный же человек не подымет и не засунет в рот. А вот информационный пирожок, валяющийся в интернете, каждый примерно первый подымет и засунет себе в голову.
в основном согласен, но хочу обратить Ваше внимание, что обработка мозгов рекламой с начала ХХ века стала одним из двигателей экономики, как-то быстро сообразили, если тратить 30% доходов на рекламу, можно втюхать что угодно, и повышать качество не обязательно, за сотню лет это довели до совершенства,
до появления smart phones, трудно было предположить такую степень зависимости какая появилась у людей, не уверен что есть достаточный запас прочности выдержать AI
Разве википедия является источником "нефильтрованной информации"? Ровно наоборот. То же самое и с AI.
А?
Я и не говорил, что это сделало или должно было сделать нашу жизнь лучше (хотя вероятно чуть сделало).
Я говорю как этим инструментом воспользовались.
Чего мы так и не получили, это заметного улучшения качества софта
Не соглашусь. Ещё в конце 2000-х баги и вылеты были скорее досадной нормой для софта, в том числе и системного, включая сами операционные системы. А сейчас кто и когда в последний раз видел BSOD на Винде или панику ядра на Линуксах?
Я видел на линуксах такое, что видеодрайвер AMD попутал свою видеопамять с page cache и разнёс файловую систему. И это современное ядро на более-менее современном ноутбуке. Помогло выключить IOMMU, а до того регулярно разносил, и даже partition table один раз разнёс.
И видел, как на некоторых ноутах отваливается тачпад потому, что когда от него приходит прерывание, то никто из драйверов не признаётся, что это евонное прерывание, и ядро его на всякий случай запрещает, как ничейное, и тачпад остаётся без прерываний и перестаёт работать. И даже хотфикс для этой проблемы написал (https://github.com/alexpevzner/hotfix-kvadra-touchpad) и в соответствующую ядерную почтовую группу рассылки жаловался, никто мне не ответил, так все, кому надо, до сих пор моим хотфиксом и пользуются.
И много чего другого видел. На современных вполне линуксах.
Вообще, на линуксе 15-летней давности uptime по году был вполне нормой. А сейчас, месяц продержался без перезагрузки, уже хорошо. Вон, иные сотовые телефоны с андроидом просто профилактически перегружаются ночью раз в сутки по расписанию.
Насчет BSOD на венде не скажу, поскольку мои пересечения с вендой очень незначительны. Но замечу ехидно, что современный корпоративный стиль программирования заключается в том, чтобы assert-ы и прочие самопроверки, которые могут отправить программу в полёт, в релизных сборках принято выключать, и уговорить граждан так не делать очень сложно (типа, зачем ты тут программу убиваешь, она бы, глядишь, еще пожила, а у ней там пользовательские данные). Так что может потому и не вылетают, что самопроверки отключены мудрым менеджерским указанием.
Вообще, на линуксе 15-летней давности uptime по году был вполне нормой
Я бы даже поверил, если бы сам не пользовался Линуксом 15 лет назад. Всё было намного хуже, чем сейчас.
как на некоторых ноутах отваливается тачпад
15 лет назад он бы безусловно завёлся и работал без проблем, правда ведь? XD
На ноутах и прочем bleeding edge железе было хуже, но терпимо. Рекомендовалось при покупке железа задумываться заранее на предмет совместимости с линухом.
Вот мой пост примерно этой давности про особенности инсталляции Федоры на современный, на тот момент, ноут: https://pzz.livejournal.com/12102.html
Эта машинка прожила под линухом долго и счастливо всю свою нотбучную жизнь, состарилась и была готова уйти на пенсию в качестве детской машинки для детей, но ее неудачно уронила с подоконника на пол собака, запутавшись в проводе, существенно повредив матрицу. До этого момента в машинке работало всё.
Раньше код был более оптимизирован, не смотря на сумбурность. Используя классы, прикомпилируются полно проверок и информации о классах. По поводу суперкомпьютера в кармане. Если в начале развития Android, java-разработчики были против статиков, то сейчас их генерируют полно библиотек, приложения занимают много памяти и тормозят, но зато синтаксический сахар, ООПэ и всё такое.
Большой размер кода не от самого ООП, а от способов его применения. Базовые объекты, не наследованные от кучи "предков" с еще большей кучей виртуальных методов должны компилироваться достаточно компактно.
Раньше код был более оптимизирован, не смотря на сумбурность
Небось процессор такой, сидит и думает "раньше меня кормили каким-то совершенно невнятным кодом с кучей переходов во все стороны, которых не предскажешь и которые срывают мой конвеер. И еще обижались, что дескать, позаботились обо мне, вручную заоптимизировани, а я почему-то всё равно торможу. А сейчас в коде команд хоть и побольше, но мой приятель-компилятор знает, как их расположить, чтобы мне удобно исполнять было, и в итоге получается побыстрее".
странно, что никто не увидел, что это всё таки эволюция, развитие, изменения, а не разбор "почему гоу ту такой плохой" \хотя да сам факт события был тем самым pivot
хорошо что есть кто фиксирует вехи развития
А я не вижу ничего особо плохого в goto.
Его даже сравнительно недавно добавил php.
И тех проблем которые ранее с ним были сейчас нет.
Плохо разве то, что не все IDE поддерживают переход к метке.
goto добавляет слегка сложности. Но без него реализация не факт что была бы проще.
Я обычно использую его чтобы пропустить какую-то часть кода. Например если в кеше нашли данные, то перепрыгнуть их получение из базы, чтобы if/else занимал меньше строк. Вернее чтобы else вообще не было.
Короткую программу ака х-як и в продакшн можно писать как угодно.
Но как только программу надо развивать, долго сопровождать, появляется командная работа то вот все жёсткие правила и появляются.
После четверти текста читать бросил
LLM статью написала? Или джун, страдающий резонерством (что одно и то же)
Опять? Да блин!
Это ограничение только в голове у кодеров. У разработчиков и инженеров все средства хороши, особенно если нужно не абстракциями обмазываться а последний такт выжимать из железа, и последний байт.
Эдсгер Дейкстра в 1968-м вынес приговор: «Goto considered harmful».
А потом маркетологи такие - https://gotopia.tech/, а в IT уже и забыли, что goto в IT, это harmful и почти ругательство.
холивар про goto разводят только такие как автор, кому он нужен применяют и дальше...
автор что курит когда обсуждает опечатки в коде? И причем тут ООП?
не осилил этот бред, извините)
Про goto.
Если уж отказываться от goto, то тогда надо убирать его и из ассемблера (jmp).
Логично же... Или нет?
И код, конечно же станет просто конфеткой! \s
От лабиринтов из goto, перешли к грудам процедур и функций, которые мутировали в хаос метедов и нагромождение классов с объектами.
Кто-то говорит, что порог вхождения снизился, но это иллюзия. Написать свою первую программу стало очень легко, по побочной причине - из-за увеличения доступности техники, однако, что-либо серьезное написать всё ещё сложно, и эта сложность имеет тенденцию к росту. (см. вакансии джунов с километровыми списками требований)
Передача проекта другой команде, всё ещё, может вызывать муки, трудно совместимые с жизнью, поскольку далеко не везде выделяют время, не только на ведение документации, но и на поддержку читабельности кода. Кроме того, у разных команд могут быть различные представления об этом, что частенько приводит к переписыванию половины всей системы (допустим, новые тимлиды решили, что проще написать с нуля, чем разбираться, но где-то споткнулись и бросили).
А насколько далеко ушли Android-разработчики, со своими паттернами, ООП, SOLID, coroutines, Compose от проблемы NPE и лавирования между жизненными циклами активностей и фрагментов для достижения ожидаемого певедения приложения?
«Я так и знал что дискуссии будут только по последнему вопросу»
«Почему это важно? Потому что сегодня ваш код управляет не калькулятором, а:
Ракетами, которые садятся на плавучие платформы,
Банками, где один null — это чей-то дом, проданный за долги,
Умными холодильниками, которые внезапно решают, что вы веган и переводят вас на спаржу с одуванчиками»
Ваш код НЕ управляет ракетами и прочим. Программу для Аппалона писали в машинных кодах и смогли пропадчить за сотни тысяч километров от Земли.
Большинство программ управления спутниками писались/пишуться на Fortran о котором у среднего посетителя Хабра нет ни малейшего представления ( автор комментария к ним тоже относится, но по крайней мере он о нем слышал)
В банках, страховках компаниях тонны кода написанного на COBOL который работает до сих пор, поскольку скрипт Килли с JS +аджай не в состоянии даже понять половины финансовых расчётов
По поводу торговых роботов на Basic- прочитайте про Investor’s Exchange /Isalnd/ Archopelag - как простой парень написал биржевой движок - кстати код опубликован, писал он по-моему на Foxpro. - для тех кто не в курсе, это практически Excel VBA.
О походу скрипт кидди набежали… давайте кто тут из отметившихся в комментариях написал код для управления спутником? Вы хоть рассчитать орбиту для запуска ракеты на Луну сможете?
Да это веб-программисты.
Если у некоторых ПХПшников (по слухам) случается нервный срыв от контакта с Битриксом...
Фиг с ним, с Коболом, они от портянки, написанной на C в обморок падать будут пачками.
"Банками, где один null — это чей-то дом, проданный за долги"
Максимальный эффект от неожиданного null - это "при нажатии на кнопку ничего не происходит" или "при нажатии на кнопку вылезла мутная ошибка". Для того, чтобы совершилось какое-то качественное действие, это действие необходимо прописать.
Хотя повсеместное распространние убогой реактивщины на фронтенде приблизило нас к опасной границе, после пересечения которой "фатальная ошибка" может возникнуть из-за того, что кто-то забыл, что какая-то часть стейта влияется где-то еще на что-то. Увеличение когнитивной сложности в веб-прогграммировании можно отрицать сколько угодно, но оно настигнет нас и больно укусит.
И да, постепенный отказ от императивщины в финансовой сфере - это катастрофа. Эти "дети" все-таки сломают что-нибудь важное рано или поздно.
Главное - это не подпускать их, с этими декларативно-реактивными подходами, к ядерным объектам .
На ядерных объектах фильтр стоит на входе: надо хотя бы слегка в. Физике/математики рубить
У гугла в интерфейсе со списком доменов для рекапчи кнопка под списком с текстом "Да" удаляла аккаунт. Баг пофиксили, но моему замешательству не было предела.
В одной большой финансовой компании, услугами которой пользовались большинство читателей хабра, в интерфейсе иногда возникал баг, показывающий что у тебя на счету лишних полтора миллиона. Клиенты пытались вывести, процессинг конечно же не пропускал, но было забавно.
А вот в другой компании, которой мало кто пользовался, баг отобразил исчезнувшие полтора миллиона евро и клиент натурально отъехал на скорой. И вроде реальных потерь нет, а вот здоровье и срок жизни немного уменьшился.
Реактивщина не увеличивает сложность а уменьшает.
Учетная система британской почты, разорившая и отправившая под суд больше тысячи человек, и нескольких из них доведшая до самоубийства, была написана тогда, когда мамки этих ваших скрипт кидди ещё в девках ходили. Безо всякой реактивщины-декларативщины.
Прочитал с интересом, ибо я вот тот самый программист, хоть не из 60-х, но из 2000-х. :) Так получилось, что все это время программировал "в одного", для себя и не принимал участия в программерских тусовках. Есть опыт использования и ассемблера, и даже машкода pdp-11, но последние четверть века это только c++(ардуино), php, js, mysql и, недавно, python.
Так вот, к чему я: разумеется, я использую современные библиотеки и, порой, когда "что-то идет не так", лезу в исходный код и разбираюсь, как оно там работает. И, нередко, матерюсь от чрезмерной избыточности и, одновременно, бестолковости. Обновить бит в байте по последовательному интерфейсу (для 8 сегментного дисплея) - обновляем бит в буфере, буфер заливаем в интерфейс - ок, все правильно. Обновить одновременно 8 бит - проделываем то же самое 8 раз! И такое сплошь и рядом...
Самое забавное: я читаю и понимаю код, в том числе современный. Но попытки читать статьи современных программистов (тут, на хабре) очень сложно - это какой то другой язык, другая терминология.
"Старую собаку новым трюкам не обучить" - это, видимо, про меня. :) Программирование как было хобби, так и останется...
Как раз сегодня ехал на работу и думал, как хорошо было на дорогах в начале 1900-х, никто не диктует "как дышать" - едь с какой хочешь скоростью, проезжай перекрёстки как хочешь, разворачивайся как хочешь. А теперь никакой свободы, обязательно нужно учить странные правила "о 200 пунктах" и зачем-то их слушаться.
85% проектов ВПК США выходили за бюджет и сроки
А в ВПК софт - это точно главная часть?
Эволюция программирования: как парадигмы украли нашу свободу