программистское: о красивом коде

[avva]

Прочитайте вот это, коллеги.

Там - Горькая Правда.

A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance.

(но стоит прочитать полностью)

Comments

[avva.livejournal.com]

Нет, ну я фигею от количества специалистов, окончательно решивших всех проблемы, блин, софтвер инженеринга.

От магического слова "декомпозиция" вся сложность проблемы съеживается и улетучивается, а если его повторить три раза, с использованием процессов, так просто тридцать три богатыря выходят из моря и все делают за полчаса.

[msh.livejournal.com]

Различные варианты фразы "ты чо тут, самый умный?" меня не обижали даже в средней школе ;-)

Сложность проблемы от декомпозиции не съеживается, а скорее наоборот, раздувается. Просто ее становится возможным grasp. Вот и все. Остается декомпозицию из магического слова превратить в обыденный инструмент software development

Опять же, автомобилестроение прошло этот путь в обозримом прошлом - от какого-нибудь гениального
August Horch, в одиночку проектировавшего автомобили, до современных платформ и компонентов

[trueblacker.livejournal.com]

Это всё верно... но знаете ли вы, что такое системный анализ? Знакомы ли вам понятия, например, дефекта массы атомного ядра? Принцип, согласно которому "целое" не есть "сумма частей" ?

Практическое решение сложной задачи и шедевр инженерной мысли на ту же тему - совершенно разные вещи. Декомпозиция однозначно необходима для формализации первого. Но второму, при всей её необходимости, она, безусловно, в том числе и наносит вред. Баги - это, зачастую, обитатели пустот, оставшихся при сборке декомпозированных узлов.

[sply.livejournal.com]

Все инжениринговые проблемы и правда решены. Есть только одна нерешаемая, но это уже не инжениринг, а бизнес - максимизировать прибыль, минимизировав затраты.

[plakhov.livejournal.com]

Ну это очевидная глупость. Вот из своей области пример приведу. Простая проблема - переправить по команде пользователя в realtime stragegy wargame волка, козу и капусту 20 танков по узкому мосту через речку так, чтобы данный процесс у пользователя не вызывал раздражения. Ну, понятно, речь не только о мосте, речь о pathtracking вообще.

Ее не смог решить Westwood, ее не умеет решать EA, Blizzard, THQ, Nival, etc etc.

Вообще, адресовать человеку из Google комментарий, что все инженерные проблемы уже решены - немного смешно. Свое бизнес-преимущество эта компания получила именно потому, что ее сотрудники решили довольно много инженерных проблем, которые до них решены не были.

[sply.livejournal.com]

Обожаю комментарии, начинающиеся с "очевидная глупость". Вы просто торопитесь писать или всегда так думаете?

Про проблему танков я ничего не слышал, а пример слишком непонятный, чтобы что-то доказать. Впрочем, даже если эта проблема действительно существует и действительно так важна, возможно, вы знаете универсальный ответ: любую проблему можно решить с помощью неограниченных ресурсов, а реальная решаемость заключена в том, чтобы стоимость затраченных ресурсов была адекватна выгоде от решения.

P.S. Писать о том, что кому смешно адресовать - это смешно само по себе. Не находите?

[plakhov.livejournal.com]

Прошу прощения, если обидел - но что думал, то и написал.
"Решены все инженерные проблемы" - позиция настолько не согласующаяся с тем, что я вижу ежедневно, что непонятно даже, с чего ее начать опровергать.

"Можно решить, если затратить много денег" - это, согласитесь, совсем не то же самое, что "все проблемы уже решены". Но ведь даже и так неверно.

Где поиск по фотографиям (не по подписям к, а по самим фотографиям)?
Где вообще распознавание образов общего назначения?
Где технология, позволяющая удобно задействовать паралеллизм hardware в индустриальных императивных языках?
Где технология, позволяющая разрабатывать браузерные UI так же удобно, как Windows Forms позволяет разрабатывать клиентские?
Где синтез речи с нормальным, человеческим произношением и интонациями?
Где автоматический шофер?

P.S. Не нахожу, а почему вы так думаете?

[sply.livejournal.com]

Ок, по полочкам:

Краеугольный камень - это наличие или отсутсвие возможности решать проблему. В исходном посте проблема с пониманием сложных структур была названа главной причиной, делающей чуть ли ни невозможным реализацию сложных проектов. На что было справедливо замечено, что уже давно реализуются сложные непрограммные проекты и есть уже отработанные методы работы со сложными проектами.

Ваш пример с танками здесь вообще ничего не иллюстрирует. Или проблема танков труднее постройки космического корабля?


Ну а поиска по фотографиям нет лишь потому что есть куча других дел, которые по чьему-то мнению более нужны/важны/интересны/прибыльны и т.п. Меня, например, брайзерные UI вообще не интересует - это средство, а не цель. Вот сделать так, чтобы при мысленном запросе ответ из "всемирного информаториума" сразу же появлялся в сознании - это вполне себе цель.

[plakhov.livejournal.com]

Я считаю неверной посылку "уже давно реализуются сложные непрограммные проекты и есть уже отработанные методы работы со сложными проектами". В половине моих комментариев здесь я пытался проиллюстрировать как раз ту мысль, что _структурно_ программные продукты уже стали сложнее любых непрограммных.
Согласен, это пока еще не очевидно; космический корабль сложнее, чем Longhorn, по крайней мере на вид.

Но понятно, что даже если сейчас это не так, это скоро окажется так.

Ибо программирование - это единственная индустрия, в которой чертеж детали является одновременно и заводом, изготавливающим ее за $0. Где любой может встроить в свой трейлер ядерную электростанцию, чтобы зажигать единственную лампочку, и это считается хорошим тоном (отличная scalability!)

[begemotv2718.livejournal.com]

Неужто поиск по фотографиям и распознавание образов только инженерная проблема? Т.е. неужто уже понятны принципы по которым это надо делать, остается только написать код?

[plakhov.livejournal.com]

Коль скоро этого еще не сделано, уверенно даст утвердительный ответ только очень глупый человек :)

И все-таки я рискну предположить, что в данной задаче проблема именно в структурной сложности, а не в базовых принципах. Принципов, по которым это можно было бы делать, предложено уже в достатке, и в частных задачах они работают. В классической книжке Norvig'а & Russell'а изложены архитектуры распознавания образов общего назначения (в главе 20, Statistical Learning Methods). Не исключено, что по какой-то причине выяснится, что они "не работают" в больших масштабах, например, не тот порядок быстродействия - но до той точки, в которой можно было бы сделать такой вывод, ни одна система в своей разработке не дошла.

[e2pii1.livejournal.com]

""
Где поиск по фотографиям (не по подписям к, а по самим фотографиям)?
Где вообще распознавание образов общего назначения?
Где синтез речи с нормальным, человеческим произношением и интонациями?
""


эти проблемы не инженерные, a нayчные.


""
Где автоматический шофер?
""

этo инженернaя проблемa - нo не из программирования, а из прикладной области.
Про остальное вами перечисленное - не специалист.

[plakhov.livejournal.com]

Насчет научных vs инженерных проблем уже ответил и выше и ниже по треду.

Автоматический шофер - это проблема прежде всего программирования. Остальное в ней более-менее просто. Конечно, ее можно решить и по-другому, приняв основной удар на инфраструктуру: обвесить все машины обязательными датчиками, перестроить дороги, поменять ПДД и тп; но я, конечно, не это имел в виду.

Вот, например, ссылка по теме (какая именно проблема решается): http://www.darpa.mil/grandchallenge/overview.asp

Насчет "остальное - не специалист" - жаль, потому что это как раз проблемы, "инженерность" которых сомнений не вызывает.

[e2pii1.livejournal.com]

""
Автоматический шофер - это проблема прежде всего программирования. Остальное в ней более-менее просто.
""

Нет. Трудность именно в отсутствии надежно работающих алгоритмов распознания и в том что, в отличии от игр где все объекты самими же и придуманы, тут реальность, в которой появляются разнообразные непредсказыемые эффекты и их комбинации.

этo инженернaя проблемa - нo не программирования, а computer vision.

[plakhov.livejournal.com]

Честно говоря, не люблю делить на "программирование" и "алгоритмы распознавания", "алгоритмы ранжирования", "алгоритмы еще чего-то", "CS" и тп. Имхо, если мы уберем из программирования все остальные перечисленные пункты, останется непонятный сферический конь в вакууме, совсем неинтересный.

А алгоритмы распознавания уже есть: большая часть частных задач распознавания как дороги, так и автомобиля по данным видеокамеры решены. Мой бывший сослуживец работает во вполне коммерческой конторе, в частности распознающей автомобили (с номерами) на стационарной полицейской камере. Проблема в том, что качественное решение даже частного случая оказывается структурно очень сложным. Базовые принципы не то что понятны - очевидны.

[e2pii1.livejournal.com]

Тут специфика в том, что если программирование игр - на 100% логика (ну и эффективная работа с хардвером), то здесь появляется еще и физика, высшая математика и.т.д.

Базовые алгоритмы распознавания известны, проблема какие из них будут/не будут работать для данной специфики и их адаптация. С грамотно подобранными алгоритмами распознавания программа не будeт очень большой и структурно сложной.

[plakhov.livejournal.com]

В программировании игр довольно много физики (ньютоновская механика и все, что касается распространения света). Высшей математики, конечно, нет, но с другой стороны, где она появляется в распознавании - мне тоже не очевидно (ну за пределами формулы Байеса, разве что). Я не то чтобы совсем профан, мехмат закончил, и в аспирантуре некоторое время изображения "распознавал"; но, может, что-то упустил?

Грамотный подбор и комбинирование отдельных базовых методик (в том числе автоматизированные), соответствующие test framework'и и т.п. - это и есть путь, которым надо двигаться. Но разве это не программирование? Или не инженерная задача? :)

[alexott.livejournal.com]

то, что вы перечислили - это не инженерные проблемы, а скорее научные. я могу привести пример из моей научной практики - низкотемпературную плазму получать научились, но предсказывать процессы в ней, за 50 лет так и не научились, и все диссертации на эту тему сводятся к теме "что если повернуть на лапоть влево, то получим то-то, а если вправо, то другое..."
Поиск по фотографиям одно время был популярен, особенно в теме борьбы с порнографией, но потом как-то незаметно все продукты с этого рынка испарились - я этим вопросом озадачивался в силу своей профессиональной деятельности

[plakhov.livejournal.com]

Можно, конечно, отнести большую часть упомянутых проблем к научным, большую часть оставшегося - к менеджменту.

Все же, кажется, вот эти два пункта "технология, позволяющая удобно задействовать паралеллизм hardware в индустриальных императивных языках и
технология, позволяющая разрабатывать браузерные UI так же удобно, как Windows Forms позволяет разрабатывать клиентские" - инженерные проблемы в любой классификации.

Да и оставшиеся пункты списка я для себя считаю инженерными, а не научными, поскольку они не требуют изучения каких-то явлений, или открытия каких-то новых фактов - вся сложность именно в проектировании. Хотя это, конечно, вопрос таксономии.