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

[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

[liksu.livejournal.com]

А можно вариант на русском? :)

[andrzejn]

А ведь Вернор Виндж говорил. А ведь Виндж предупреждал!

Без сверхинтеллектов ничего не получится.

[averros.livejournal.com]

На что есть наш пролетарский ответ: Keep It Simple, Stupid!

[sleeping-death.livejournal.com]

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

[gaius-julius.livejournal.com]

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

[plakhov.livejournal.com]

Мне кажется, все не так мрачно. То есть в итоге, конечно, мы упремся в пределы человеческого разума и тп, но пока что дело, имхо, чаще всего совсем не в этом.

1) Я не совсем понял, откуда возникает противопоставление "beauty vs straightforwardness and conventionality". Дизайн imo красив именно тогда, когда не переусложняет систему неоправданно, и не дает возможности "глупо ошибиться". Собственно, когда соблюден баланс coupling vs cohesion, и хороша система раннего обнаружения ошибок (строгая типизация, testability и тп).
2) Но этого совсем недостаточно; надо еще и формулировать требования к системе в такой форме, и таким способом, чтобы излишняя сложность не была заложена в самих исходных требованиях.

У нас в программировании игр второй пункт в разы важнее первого, хотя без первого тоже нельзя.

Я об этом как-то написал статью для гейм-дизайнеров (это аналог аналитиков в разработке игр). Некоторые люди, которые ее потом перепечатывали, писали, что область ее применимости шире, чем я думал.

С добрым утром!

[plumqqz.livejournal.com]

Вообще-то это издревле формулируется как "на всякого мудреца довольно простоты".

[plakhov.livejournal.com]

Это только начало.

Потом выясняется, что в похожих ситуациях мы вынуждены писать одно и то же. Почти copy-paste (а иногда и не "почти"). Досадно, но оказывается, что таких ситуаций примерно миллион.

Чтобы писать такие места быстрее и с меньшим числом опечаток, мы объединяем часто встречающиеся последовательности и выносим общую функциональность в отдельные сущности (функции, классы, макросы, шаблоны, generic'и, или даже тьфу-тьфу не дай бог аспекты).

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

Появляется некоторый язык настройки этих сущностей второго рода. Аггрегация вместо наследования, декораторы, общие интерфейсы вместо общего предка.

Тут в проект приходит новый программист, и...

Re: С добрым утром!

[cmm.livejournal.com]

да-да, в Святом Писании уже всё давно сказано.

[plakhov.livejournal.com]

У Винджа встречаются гениальные детали именно в том, что касается программирования.

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

[msh.livejournal.com]

Представляются инженеры Тойоты, рыдающие над чертежами нового автомобиля "the human mind can not grasp the complexity of a compact car, much less the Lexus SUV we build today"

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

Re: С добрым утром!

[plumqqz.livejournal.com]

Ну вот - сами же все знаете.

[avva.livejournal.com]

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

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

[cmm.livejournal.com]

> 18-й век уже окончился

в программировании — от силы тринадцатый: по каким именно границам декомпозицию производить не всегда понятно,
а большая часть процессов недалеко ушла от камлания.

сараи для дров строить уже научились, впрочем.  и тачки.

[trurle.livejournal.com]

Насчет тачек это иллюзия на самом деле.

[msh.livejournal.com]

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

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

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

[msh.livejournal.com]

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

[cmm.livejournal.com]

к идее-то пришли изначально, чай не бином-ньютона.
физика такой роскоши до последнего времени не позволяла, да и сегодня ещё далеко не везде позволяет.  и закон Мура сломался на самом интересном месте.

[sply.livejournal.com]

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

[plakhov.livejournal.com]

Да, пожалуй, многие пришли, да, да.

TCP/IP, SQL, нет, это слишком сложно. Threads, new/delete, garbage collection, нет, что там, это тоже слишком advanced. Высокоуровневые языки программирования, file system, OS вообще как таковые, etc etc. Даже и это не болты-гайки, это концепты куда как сложнее. Болты-гайки - это уровень стандартизации character encoding'ов, наверное.

Ну и еще насчет болтов-гаек - знаете, как устроен аналог С-шного strcmp в C#? А это ведь болт болтее некуда, казалось бы?

[plakhov.livejournal.com]

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

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

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

[msh.livejournal.com]

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

Если я решил, что здесь в программе будет thread, проектирование только начинается - а какие у меня threads? pthreads? Windows? Какая-то библиотека с своей семантикой?

Я уж не говорю про SQL ..

[plakhov.livejournal.com]

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

Да поправят меня шарпники, если последующее вдруг является глупостью, ибо я только догадываюсь, и не знаю в точности.

Так вот, насколько подозреваю, в C# это O(1) операция, что достигается совершенно другой стратегией хранения строк (у которой, соответственно, есть свои неприятные побочные эффекты). Тогда как в С/С++ это О(length).

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

[plakhov.livejournal.com]

И никто, кроме избранных, не догадался, что надо просто стандартизировать и эти детали тоже?

[sply.livejournal.com]

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

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

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