В 1985 году учёный Питер Нур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Нура: «программа — это не её исходный код».
Теория кода
Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться. Исходный код же является лишь письменным представлением этой теории, и, подобно любому другому представлению, не может передать её полноценно. Важнейшая информация о замысле, дизайне, компромиссах и рассуждениях, лежащих в основе тех или иных архитектурных решений, существует лишь в умах создателей системы.
Когда такие люди уходят, вся эта теория утрачивается. Код остаётся, но программа — живая, дышащая система со всеми её предпосылками и контекстом — исчезает.
Кризис из-за утраты теоретического фундамента
Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ. В чём конкретно это выражается?
В бездумном использовании ИИ, которое уже стало нормой. Разработчики инстинктивно обращаются к генерируемым LLM решениям, не прилагая никаких когнитивных усилий, без которых получить должное понимание невозможно. Как я уже писал, это «бездумное использование ИИ» лишает нас возможности роста — тех ситуаций, когда ты оказался в тупике, взглянул на ситуацию со стороны, поборолся с задачей и, наконец, достиг этого заветного момента «Ага!», став более опытным инженером.
В генерации беспредметного кода. Здесь всё ещё печальней. Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания области задачи, концептуальной модели системы или тонких компромиссов, которые эксперты заложили в её архитектуру. Этот код может пройти тесты, но существует он в теоретическом и предметном вакууме. Не имея возможности найти крайнего с помощью
git blame, мы оказываемся сильно стеснены в своём стремлении понять «как?» работает тот или иной код, а самое главное «зачем?» он был написан.В проблемах интеграции. Когда разработчики принимают сгенерированный ИИ код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения. В лучшем случае такой код будет: 1) работать и 2) не делать ничего опасного. Заложенные в нём решения могут противоречить модели предметной области, нарушать устоявшиеся паттерны или вносить едва уловимые несоответствия, которые обнаружатся, только когда система окажется под нагрузкой.
И что в результате? А в результате мы получаем кодовые базы, которые поначалу вроде работают, но по мере роста становятся всё менее согласованными. Системы, в которых код перестаёт отражать язык предметной области. Технический долг, который только накапливается, так как никто не понимает теоретических основ, когда-то придававших системе её целостность.
Хотя этот кризис далеко не новость. Помню того несчастного стажёра в предыдущей компании, где я работал, который авторизовался в продакшене и выполнил rm -rf /, так как на StackOverflow ему сказали, что это решит его проблемы с symlink.
Но сейчас мы наблюдаем всё это уже в других масштабах! Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта. (Если сюда прибавить ещё и рисковых вайб-кодеров, то эти числа станут куда более пугающими). А теперь вооружите этих неопытных программистов ИИ-инструментами, которые мгновенно генерируют целые функции, и вы получите катастрофу: невиданное число джуниоров, вооружённых мощнейшими инструментами копи-паста и минимальным пониманием процесса.
Упомянутому выше стажёру хотя бы нужно было найти, прочесть и вручную ввести свою деструктивную команду. А сегодняшние разработчики получают генерируемые ИИ функции по нажатию клавиши, импортируют важные решения, которые не проверяют (не говоря уже об откровенно опасном коде).
Почему опытные разработчики стали ценны как никогда
И всё это подводит нас к рассуждению о том, почему бывалые инженеры стали крайне важны для индустрии. Эти люди:
Разрабатывают теорию предметной области. Старшие разработчики не просто пишут код — они выстраивают и поддерживают теоретическую схему, которая соединяет бизнес-области с программной архитектурой. Они понимают не только то, что делает код, но и почему он существует, как моделирует бизнес-область и как должен развиваться с углублением понимания процесса. Это те люди, которые обеспечивают, чтобы код говорил на языке экспертов предметной области.
Следят за соблюдением заложенной в архитектуру теории. Когда джуниор или LLM создают код, старший разработчик выступает проводником между его сырой реализацией и согласованным дизайном системы. Он способен оценить, соответствует ли написанный код теоретическим основам архитектуры — причём не только технически, но и концептуально. Эти люди понимают разницу между кодом, который работает, и кодом, который подходит к общей структуре.
Сознательно используют ИИ. Старшие разработчики используют ИИ сознательно, а не рефлекторно. Они понимают всё, что в итоге интегрируют, ставят под сомнение предложения моделей и следят, чтобы сгенерированный код поддерживал теоретическую согласованность системы, а не подрывал её. Если они используют ИИ, то обычно для каких-то шаблонных задач, оставляя на самостоятельное решение те части, которые требуют здравого человеческого суждения. (Если вы застряли в ситуации, где вам нужно, скажем, написать двадцать с лишним фабричных методов, делающих одно и то же, но для разных сервисов или свойств, то это можно с чистой совестью поручить Claude Code или какой-то другой модели).
Учат теории и мастерству. Пожалуй, самая важная роль старших разработчиков в том, чтобы передавать теоретические знания и навыки другим. Они учат молодых специалистов не только использованию синтаксиса или паттернов, но и глубокому пониманию, которое позволяет превратить разрозненный код в согласованные программы. Эти люди обучают искусству решения задач, объясняют, в чём ценность когнитивных усилий, а также прививают дисциплину, чтобы реализации всегда предшествовал вдумчивый анализ и понимание.
Человек незаменим
Нур в своей работе также напоминает нам, что программирование по своей природе относится к интеллектуальной активности человека. Его реальным продуктом является не код, а теория, понимание и ментальная модель, которые придают системе согласованность. Да, LLM могут генерировать синтаксически корректный код, но они не могут создавать теории. Они не могут понять бизнес-контекст, осмыслить необходимые компромиссы или поддерживать концептуальную целостность, которая отделяет качественное ПО от просто рабочего кода.
Несмотря на то, что хорошая документация, запись архитектурных решений и чистый, разборчивый код всегда кстати, всё это лишь слова, которые не могут полноценно отразить то, чем наши программы являются, что делают и какой смысл несут.
Наибольшего успеха добьются те команды, которые осознают фундаментальную разницу. LLM могут быть полезны для конкретно механистических задач (генерации шаблонного кода, написания простых тестов, создания тех самых двадцати с лишним почти идентичных фабричных методов). Но сама суть программирования — выработка теории, которая преобразует бизнес-требования в согласованные программные модели — должна оставаться строго в руках человека.
Сохранение теории
Организации, ценящие качество своего ПО, должны вкладывать усилия в сохранение теоретической базы:
Создавать документацию, которая будет отражать сам смысл ПО, а не только его реализацию.
Вводить практики обмена знаниями, в ходе которых люди будут делиться ментальными моделями, а не просто знакомиться с голыми процессами.
Использовать код-ревью для оценки не только корректности программы, но и её соответствия теоретическим основам.
Развивать программы наставничества, чтобы вырабатывать у новичков навыки построения теорий.
Искусство создания теорий
Питер Нур ещё в 1985 году понял то, что мы заново открываем для себя сегодня. Речь о том, что программы — это созданные человеком конструкты, для развития которых необходимо их глубокое понимание. По мере вхождения в эпоху безудержной генерации кода всё большую ценность начинают обретать разработчики, которые умеют выстраивать, сохранять и передавать теории, придающие коду его осмысленную и целостную форму.
И это не про отказ от ИИ или отстаивание каких-то устаревших практик. Это про сохранение важнейших аспектов разработки, присущих именно человеку: понимания предметной области, архитектурной согласованности и тонкостей создания систем, которые не просто работают, но и имеют смысл. Это про сохранение способности эффективно бороться с задачами, вникать в них прежде, чем реализовывать, и обеспечивать, чтобы код отражал богатые ментальные модели, которые делают программные системы по-настоящему обслуживаемыми.
Вопрос не в том, могут ли LLM писать код — очевидно, могут. Вопрос в том, можем ли мы сохранить создаваемые людьми теоретические структуры, которые превращают этот код в согласованные, предметно-ориентированные, долговечные программы.
В эпоху стремления к бездумному использованию ИИ, старшие разработчики, которые применяют ИИ сознательно (если вообще это делают) с сохранением всех необходимых принципов программирования, становятся хранителями качественного ПО. Они единственные, кто обеспечивает, чтобы наши системы оставались понятными для людей, соответствовали своим предметным областям и строились на основе твёрдой теории.
Когда пыль, поднявшаяся в суетливой погоне за «халявным кодом», осядет, спрос на старших разработчиков снова возрастёт.
Комментарии (44)
samizdam
06.07.2025 09:55Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.
avost
06.07.2025 09:55Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы
А в каком месте печатный станок избавил от интеллектуальной работы? Избавил от тупой работы. Интеллектуальной даже прибавил (ответственности) - там, где при ручном переписывании ошибка оказывалась в одном экземпляре, при печати тиражировалась на сотни-тысячи-миллионы.
samizdam
06.07.2025 09:55А в каком месте печатный станок избавил от интеллектуальной работы?
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.
Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.
Печатный станок дал возможность большему кол-ву мнений (и авторам-интеллектуалам) доходить до широкой аудитории (Реформация, просвещение, национальные революции и т.д.). И как любое массовое производство снизил стоимость и требуемую квалификацию. Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве, говорю как специалист издательского дела))
где при ручном переписывании ошибка оказывалась в одном экземпляре
Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)
Fedorkov
06.07.2025 09:55Автор неявно исходит из того, что нас не ждут никакие новые революции в ИИ.
Я бы просто посоветовал пропустить нынешний раунд хайпа и продолжить следить за появлением новых технологий.
GarfieldX
06.07.2025 09:55Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют. По сути это новый уровень поиска с агрегацией, анализом и генерацией ответа.
Зато нас точно ждут проблемы из-за потери контроля над кодом. По сути в статье это и описано. Например, когда мой код косячит, то практически в 99% могу предсказать где этот косяк. Потому что код писал сам и знаю его структуру особенности, нюансы и вообще все о нем. А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Но с предложением следить дальше полностью согласен. Тем более что нам ничего другого не остаётся. Лишь выбор откуда смотреть. Изнутри или снаружи.
PerroSalchicha
06.07.2025 09:55Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют.
Занудства ради, БЯМ - это и есть именно то, что мы называем термином искусственный интеллект, в соответствии с распространёнными его определениями. Просто некоторые люди ошибочно считают, что называться термином "искусственный интеллект" имеет право лишь нечто, как минимум, эквивалентное по возможностям интеллекту человеческому, но только сделанное из деталек. Но это не так, требования к ИИ куда более простые, он должен лишь имитировать некоторые аспекты интеллектуальной деятельности, с чем БЯМ прекрасно справляются.
blind_oracle
06.07.2025 09:55Нет.
Интелле́кт (от лат. intellectus «восприятие»; «разуме́ние», «понимание»; «понятие», «рассу́док»[1]) или ум[2][3] — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой
(Ц) википедия
Почти ничем из этого LLM не обладают.
PerroSalchicha
06.07.2025 09:55Да. Искусственный интеллект != интеллект.
Искусственный интеллект - комплекс технологических решений, позволяющий имитировать когнитивные функции человека (включая самообучение и поиск решений без заранее заданного алгоритма) и получать при выполнении конкретных задач результаты, сопоставимые, как минимум, с результатами интеллектуальной деятельности
Всем этим LLM обладают
Areso
06.07.2025 09:55А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Что с БЯМ, что без БЯМ, бОльшая часть кода была написано до человека, и да, надо как-то прочесть и понять, что за код, что он делает, и где бага. Писать код, в общем случае, давно не является сложной задачей.
Zerik
06.07.2025 09:55>А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
На самом деле нет. Тот же claude через cursor при достаточно чёткой постановке задачи может указать места потенциально приходящие к той или иной проблеме.
Да и про понимание кода сгенеренного через LLM-тут ведь тоже зависит от того как именно пользоваться, и насколько подробно задачу ставить. Если просто впизтвать в ту или иную агенту систему текст таски и ждать что оно само как нибудь там накодит-да, будут проблемы. Если же рассказать модели что именно она должна сделать-всё намного более предсказуемо и читабелбно получается.
dersoverflow
06.07.2025 09:55Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система...
Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания...
Гмм... А ведь мы это видели!
На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, продуктивнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать... https://ders.by/pp/ps/index.html
Да, речь снова про Камень! Без понимания и люди и машины обречены вести себя как дураки:
Все мы разделены Природой на два подмножества: понимальщики и запоминальщики.
Ни понимальщики, ни запоминальщики даже не догадываются о существовании друг друга!
sinerslb
06.07.2025 09:55Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ
Это если целью является создание кода, подкреплëнного теоретическими основами, но ведь нет. Вокруг капитализм, и в 95+ процентах случаях целью является прибыль, и пока прибыль есть, заказчику пофиг, какой-там код. Катастрофой будет отсутствие прибыли, вот тогда забеспокоятся, и начнут искать новые подходы.
VladimirFarshatov
06.07.2025 09:55
Никогда такого не было, и вот опять снова.. на память Стругацкие "Понедельник начинается в субботу":
-"Нам нужен программист". Внезапно сказал тот, что сидел справа.
-"Программисты сейчас всем нужны". Ответил я.
-"Вы не поняли. Нам нужен отличный программист". Поддержал разговор сзади.
-"Ну .. это вообще дефицит". Парировал я.:)
LinkToOS
06.07.2025 09:55Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта? Те же LLM-GPT - это больше предмет для скандалов и споров, чем требование современности. Даже эта статья, опять о проблемах использования ИИ в программировании.
Не пришло ли время здорового soft-консерватизма? Законсервируем новые разработки, и перепишем винду на ассемблере. Вообще все на ассемблере перепишем.
sic
06.07.2025 09:55Ну а как "прекратить писать новый софт"? Сказать конкурентам - не пишите похожее, я сам допишу и будет все классно?
Проблема не в коде, проблема в капитализме. Это нормально, когда все-что-угодно "а за деньги да", и что при этом создается тонна хлама, часть из которого чуть более, чем полностью вредна, и еще бесконечная масса однотипных и околоодноразовых поделий. То есть именно это и есть основная масса продуктов.
Мне нередко снится один и тот же сон. Что мол прилетают пришельцы на планету Земля, и думают, чтобы такого тут сделать, чтобы люди никогда не стали им потенциально опасны. И дарят им идею Интернет. Вообще, чем он хорош, думаю понятно, но чем он плох тоже предельно очевидно, и вот интересно, как пошли дела у нашей планеты, в мультивселенной, где Интернет почему-то не эволюционировал/не прижился.
vkni
06.07.2025 09:55И дарят им идею Интернет.
+
Проблема не в коде, проблема в капитализме.
Ну действительно же — Интернет и программирование — это же просто технологии следующего строя. Поэтому текущий их не может использовать нормально, и просто гадит.
Если вы посмотрите локусы следующего строя — OSS, то там вполне хорошо и с программированием, и с Интернетом. Когда люди делают для себя, появляются прекрасные TUI интерфейсы, замечательные сайты с минимумом спама.
Кстати, туда же, в технологии следующего строя, относятся всеобщее образование, всеобщее здравоохранение. Просто мы сейчас живём в эпоху Реставрации.
VladimirFarshatov
06.07.2025 09:55Вы упустили одну базовую лемму программирования: Главный недостаток любого кода - то что он написан не тобою. Следствие в бизнесе: главный недостаток любой программы - она не твоя, а конкурента.
LeVoN_CCCP
06.07.2025 09:55Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта?
Надо было сразу с козырей заходить - зачем нам столько дистрибутивов Linux?
max-daniels
06.07.2025 09:55Это где-то в мире розовых пони. Сейчас после 35 не берут на работу, всем подавай молодых рабов, авось разберутся вместе с нейросетями.
blind_oracle
06.07.2025 09:55У меня куча коллег-погромистов старше 45-50, со всякими PhD и подобным. Да и я уже не молод :)
Так что нет, не везде так.
OlegZH
06.07.2025 09:55Почитаешь, сразу захочется в сеньоры. Жалко, что никто не возьмёт. Надо медленно пройти все уровни. А... так.. теория... Что может быть интереснее построения теории кода?
PerroSalchicha
06.07.2025 09:55Что может быть интереснее построения теории кода?
Быть начальником чуваков, которые занимаются построениями теории кода.
pnmv
06.07.2025 09:55разработчики, высшей квалификации, ну или хотя-бы "выше средней" (middle+), возможно, ещё и нужны, но далеко не все, а только те, кто умеет проходить hr-фильтры.
если человек с опытом не умеет проходить фильтры (ну или случайно не смог, что равносильно отсутствию навыка), а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr.
PerroSalchicha
06.07.2025 09:55а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr
Эйчары людей на работу не берут. Эйчары, это просто первичный фильтр, понравиться которому, конечно, полезно просто для того, чтобы не улететь в корзину на самом первом этапе. Но вот поспособствовать трудоустройству эйчар не в состоянии.
anarchomeritocrat
06.07.2025 09:55Промпт в ChatGPT:
"прочитай статью по ссылкеhttps://habr.com/ru/companies/ruvds/articles/924616/и предложи свой комментарий"Ответ:
Мои мысли1. Полностью согласен с подходомВы, как крипто‑энтузиаст и поклонник минималистичных архитектур, точно подметили бы: без чётких ментальных моделей быстро возникающие компоненты (особенно сгенерированный ИИ‑код) ведут кархитектурным пузырям— видно снаружи, но непонятно, как это устроено внутри.2. Уместное использование ИИИспользовать LLM можно, но только какассистента для шаблонов— бэкенд‑скелет, boilerplate, тесты. При этом senior должен:Разобраться в сгенерированном коде,Адаптировать его под свою доменную логику,Убедиться, что он сочетается с остальной системой.
Это прямо перекликается с вашими принципами: функциональный, ясный, минимальный код управляется человеком, а не ИИ.3. Практики для поддержки теорииАвтор предлагает:Документировать не реализацию, асмысл: зачем этот компонент, какие компромиссы были.Через code review обсуждать не просто «исправь стиль», а «как это отражает модель?».Наставничество — именно как вы делаете: делиться пониманием, не только синтаксисом.
Эти практики стоит применять регулярно — в виде архитектурных сессий, обсуждений trade‑off и прототипов — в командах, где есть пулы джуниоров.Правда там прослеживается влияние на контекст предыдущего общения со мной, но в целом суть такая - нейронка мнение автора одобряет ))
VladimirFarshatov
06.07.2025 09:55Перплексити:
Моё мнение: статья очень актуальна и глубока, она подчёркивает важность интеллектуальной составляющей в программировании, которая не сводится к механическому написанию кода. В эпоху массового внедрения ИИ и автоматизации именно опыт и понимание старших разработчиков обеспечивают сохранение качества и смысловой целостности ПО. Это важное напоминание индустрии о том, что технологии — лишь инструменты, а основа успешной разработки — человеческий интеллект и теория.
LinkToOS
06.07.2025 09:55Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта.
Прям "Закон Мура" какой-то.
Сразу можно проблему обозначить - количество разработчиков растет, а суммарный IQ остается постоянным.
Anton_Timofeev
Программирование - это инженерная дисциплина. Единственное отличие, что инженеров-механиков в полёте фантазии ограничивает суровая реальность, т.к. нельзя протянуть сто рычагов через весь самолёт, а у программистов таких отрезвляющих рамок реальности нет - код всё стерпит.
Farongy
Нет, не стерпит.
Anton_Timofeev
Читатель кода через некоторое время не стерпит, а коду всё равно
Rive
Процессор тоже читает код в некотором смысле.
vkni
Только он читает перевод перевода.
apcs660
бывает кодирование модели чипа, писать ядра на VHDL, Verilog - чип не стерпит и оптимизация на 10 процентов очень заметна, в том числе денежно.
AlexanderS
VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.
apcs660
Да, это сравнение на другой стороне глобуса, просто железо ошибок не прощает - как правило, либо работает код модели, либо нет. И не факт что в реальном чипе будет работать после фпга, и как вы заметили, запустится на фпга не любой код который формально работает в симуляторе.
Но в enterprise программировании иногда не понимают что к примеру, на java изображения лучше не обрабатывать, для этого есть более эффективные языки или библиотеки - но нет, прут напролом и в итоге ставят 500 нодов вместо 100 в кластере и при этом с библиотекой на java, которую пересли с библиотеки на С! Потому что родная жрала памяти раз в 10 больше и медленнее раз в 5 чем клон сишной на жабе... На средних картинках. Вот тебе и эффективность.
Несколько лет клиент жжет электричество используя заведомо неэффективное решение.
В java даже определить хватит тебе памяти или нет чтобы развернуть изображение, нет нормальных способов. Вернее можно но очень ненадежно, с большим запасом. Ловят оом периодичеси., он кладет веб сервер...
Почему вспомнил - попал на поддержку такого чуда. Там бы архитектуру поменять а не заплатки лепить...
Код все стерпит, это точно, в enterprise так точно
Kergan88
Разница между программистами и другими инженерами принципиальная - программисты пишут тексты для людей
Anton_Timofeev
Исходный код - это конструкторская документация.
Сборка исполняемого файла - это изготовление на заводе.
Исполнение программы - это работа устройства.
Так что принципиальной разницы не вижу. КД тоже люди читают и правят при необходимости.
victor_1212
не совсем, КД - описание алгоритма, программирование, отладка, сборка и пр. - скорее этапы исготовления, по опыту так было, хотя возможно есть новые госты, стоило бы проверить
Anton_Timofeev
Отладка - это скорее что-то типа опытного производства, когда по предварительной КД изготавливают опытные экземпляры, тестируют, вносят изменения в КД, и так по кругу, пока не получится что-то жизнеспособное.
victor_1212
отладка разная бывает, и дело не в том на что именно похоже, а как определен рабочий цикл - ТЗ, ЭП, ТП, КД, изготовление, по старому программирование и тд. это изготовление, этап КД это алгоритмы, которые тоже конечно не на пустом месте делаются
Anton_Timofeev
Если бы программирование было частью изготовления - разве его не надо было бы повторять для каждой сборки?
VladimirFarshatov
Точно. Люди читают код и исполняют его, а комтьютер - это такая коробчка, где они живут месяцами и бессменно лопатят код.. )