Проектирование ПО, ступор и творческий хак
Software Design, Mental Blocks and Creative Hacking

февраль 2000

From: Gary Mason

Я много раз слышал термин хакер-программист (hacker), который обозначает не крэкера (cracker) (человека, который обожает вламываться в компьютерные системы), но эксперта в программировании, который быстро решает проблемы, на деле они живут, чтобы решать проблемы. Также читал в статьях о хакерах, что они обожают расширять возможности машины, которую они программируют, подобно первым хакерам из Лаборатории искусственного интеллекта МИТ (MIT AI lab). В наше время программист, который просто обожает решать проблемы, всесторонне ее рассматривая, но не расширяя возможности на нижнем (машинном) уровне, по-прежнему считается хакером.

Я программирую, чтобы решать проблемы, и обнаружил, что определенные мысли блокируют все остальные мысли и творческие цели, которые у меня есть. Это мысли об эффективности в то время, когда я пытаюсь решить проблему. Мне кажется, что гораздо логичнее концентрироваться полностью на проблеме, решить ее, а затем творчески запрограммировать, затем, если решение медленное (что затрудняет работу с ним), то... Было бы неплохо услышать ваши теории по этому поводу.

From: Robert White

Gary Mason wrote:

Я много раз слышал термин хакер-программист

Я уже старый человек, и помню время, когда этот термин только входил в повседневный лексикон. Сначала как ругательство, использовавшееся специалистами по мэйнфреймам по отношению к тем, кто не был компьютерным специалистом, но осмеливался программировать компьютер. Слово "хак" (hack) само по себе обычно означает нечто уродливое, но все равно работающее. Хакеры приняли его с гордостью и обожали показывать этим костюмам, чья игра еще продолжается.

Я программирую, чтобы решать проблемы, и обнаружил, что определенные мысли блокируют все остальные мысли и творческие цели, которые у меня есть. Это мысли об эффективности в то время, когда я пытаюсь решить проблему. Мне кажется, что гораздо логичнее концентрироваться полностью на проблеме, решить ее, а затем творчески запрограммировать, затем, если решение медленное (что затрудняет работу с ним), то... Было бы неплохо услышать ваши теории по этому поводу.

Эффективность во многом зависит от контекста. Я применяю относительно медленный и жадный до памяти язык, Perl, поскольку на нем я фантастически продуктивен. В наше время быстрых процессоров и огромной памяти эффективность - другой зверь. Большую часть времени я ограничен вводом/выводом и не могу читать данные с диска или из сети так быстро, чтобы нагрузить процессор. Раньше, когда контекст был другим, я писал очень быстрые и маленькие программы на C. Это было важно. Теперь же важнее быстро писать, поскольку оптимизация может привести к столь малому росту быстродействия, что он просто не заметен.

From: Alan Carter

Robert White wrote:

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

$ gcc -O3 hopalong.c -o hopalong
^
|
-- Activate FSF go faster stripe with ley line jet assist.

From: Gary Mason

Я ни в коей мере не причисляю себя к хакерам. Из книги "Хакеры" Стивена Леви (Steven Levy's Hackers) я получил ощущение, что хакеры не занимаются проектированием, но скорее прыгают прямо в программирование практически без всякого проектирования.

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

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

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

1) Заставить работать (Модульная Компактная Структура - Modular Tight Structure)
2) Сделать быстрее, если работает правильно (используя профилировщик - profiler).

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

Хоть кто-то из вас думал над этим? И если да, очень бы хотелось что-то услышать.

From: Joss Earl

Gary Mason wrote:

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

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

Я действительно стремлюсь почти сразу начинать программировать, поскольку часто - это наиболее эффективный путь изучить проблемную область. Часто, написав код, можно быстрее убедиться, что проект имеет смысл, чем ковыряясь с Rational Rose.

Еще один аспект: нечто сложное, что работает, почти всегда получается из чего-то простого, но работающего, в противоположность чему-то сложному, но не работающему.

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

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

Ты вынужден вставать на позицию, из которой ты выберешься с тем, что людям действительно нужно, а не с тем, что они тебя просят. Обычно происходит так, что проблему разбивают на части и некоторые ее аспекты предоставляются программистам как спецификация. В результате у тебя оказывается спецификация, в которой говорится о разработке стойки, в которой можно установить 100 свечей. Другому дадут спецификацию для разработки системы вентиляции, которая способна вытянуть дым от 100 свечей. Если ты достаточно кровожаден, то в конце концов придешь к ним с электрической лампочкой.

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

From: Nathan Hartzell

Joss Earl wrote:

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

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

Что я мог бы предложить как баланс - разработка некоего прототипа, чтобы немного лучше почувствовать проблему, затем проектирование, а потом опять кодирование с нуля (from scratch). Очень неплбольшую его часть, они бы уже завершили проект.

Если ты сначала не продумаешь все, что собираешься сделать

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

From: Alan Carter

Joss Earl wrote:

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

Интересный момент - пока люди не используют слово в техническом смысле, как "правильное движение" ("proper motion") в астрономии, они никогда не смогут сформулировать, что они имеют в виду, когда используют слово "правильный" ("proper")! Они становятся агрессивными (с демонстрациями презрения/угрозы), но на деле не смогут сказать, что они имеют в виду. То, что, по-моему, означает это слово каждый раз, когда я его слышу, - "в согласии с M0". И причина, почему они не могут его определить, - в том, что они даже не осознают, что попались в ловушку патологического поведения.

Проверьте!

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

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

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

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

From: Alan Carter

Nathan Hartzell wrote:

Что я мог бы предложить как баланс - разработка некоего прототипа, чтобы немного лучше почувствовать проблему, затем проектирование, а потом снова кодирование с нуля ( from scratch). Очень неплохо это сделать хотя бы один раз.

Да. Как сказал Фредерик Брукс (Fred Brookes), "стройте на выброс" ("build one to throw away"). Или сделайте процедурный клудж, а затем определите классы, как мы обсуждали на прошлой неделе. Неспособность это понять стоит удачи в организациях, которые не понимают, что Гради Буч (Grady Booch) подразумевает под "отрицательной производительностью" - точку, где число строк кода в продукте начинает уменьшаться, в то время как функциональность растет.

From: Gary Manson

Просто чтобы еще раз рассмотреть проблему Эффективности и Проектирования ПО, поскольку было бы здорово собрать от вас всех столько информации по этому вопросу, сколько смогу. Поскольку это тема (т.е. предсказание, насколько быстр алгоритм или сколь хорош имеющийся дизайн для решения проблемы), в которой я не силен. Один аспект Проектирования ПО, который я нахожу чрезвычайно трудным, заключается в предсказании, насколько эффективным (эффективное исполнение не эффективно по памяти, хотя подкачка (swapping) и виртуальная память могут оказывать неблагоприятное влияние на время исполнения) является имеющееся у меня решение.

Такие авторы, как Carl French, Roger Pressman, Steve McConnell и MA Jackson, пишут, что наиболее желателен практический подход. Они утверждают, что начальными целями проектирования должно быть создание корректной, функционально связанной структуры, ключевые требования к которой - надежность, поддерживаемость и робастность, затем, когда проект становится семантически корректным, его нужно запрограммировать. Если после этого система заработала, и если она оказывается медленной, следует с помощью профайлера найти потенциальные узкие места. Суть в том, что легче модифицировать хорошо написанную (хотя и медленную) программу, чем программу, которую оптимизировали на каждой стадии процесса (и, возможно, немного замысловатую). Похоже, они предлагают высокоуровневый процедурный подход. Это тот подход, который я сейчас использую и которому научился в университете, изучая программотехнику.

Было бы здорово услышать от вас мысли по этому поводу, поскольку мне не удалось найти книг на эту тему, за исключением математических книг, в которых обсуждаются тайные письмена типа О-большое и тета-анализ (Big O and Theta analysis), которые мне показались слишком сложными и превышающими мои математические способности. И, между прочим, я пытался читать "Искусство программирования" Кнута (Knuth's Art of Programming), и его Понимание слова Искусство отличается от Моего.

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

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

По моему мнению, способность программировать не связана со способностями к математике, должно быть достаточно много программистов во всем мире, у которых тоже есть трудности с такими инструментами, как О-большое и тета-анализ и которые предпочли бы подождать, пока не смогут воспользоваться профайлером (profiler).

И я прочитал множество отчетов об учебных планах обучению программотехники в США (например, один отчет был сделан в Boeing - Стив МакКоннел "После золотой лихорадки" - Steve McConnell "After Gold Rush"), где они сокрушаются над многими учебными планами, поскольку эти планы не ведут к выпуску специалистов с правильными навыками, пригодными для реального проектирования программного обеспечения.

Я говорил со многими людьми, изучавшими информатику (Computer Science) в Штатах, и похоже, что некоторые курсы на 40-50% состоят из математики, и потому там не изучают такие темы, как анализ систем (Systems Analysis), проектирование крупных программных систем (Large scale Software Design), ER-Modelling, проектирование потоков данных (Data Flow Design) и т.п., что мне кажется немного странным.

Итак, может показаться, если посмотреть с другой точки зрения, что специалистов теоретической информатики (Computer Science) не учат нюансам программной Инженерии (software Engineering), в которой, как предполагается, они будут работать по окончании учебы.

From: William Wechtenhiser

On Sun, 13 Feb 2000, Gary Mason wrote:

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

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

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

У меня это происходит так: если я начинаю писать программу "с чистого листа" и раздумываю, за что сперва взяться (забывая об описанном выше подходе к проектированию), то впадаю в полный ступор. Это происходит потому, что я настаиваю на НЕделании работы до получения единственного решения проблемы целиком, когда я знаю, что я еще не понимаю ситуацию, и из-за этого я знаю, что упускаю в своем проекте важные моменты. Поскольку я не хочу начинать работу, пока не пойму проблему целиком, и не могу понять проблему целиком не выполняя некоторую работу, я оказываюсь в тупике. С этим связаны проблемы большого стека, о которых говорил Алан. Когда у меня на очереди стоит слишком много задач, я чувствую, что должен спешить. Спешка, по моему опыту, почти всегда вызывает проблемы, поскольку ведет к мысли, что у меня нет времени на переписывание программы, над которой работаю, поэтому ее нужно написать правильно сразу. Конечно же, это немедленно приводит к описанной выше проблеме [тупика]. Хотя, как сказал Алан, раз одна или две проблемы решены, то гораздо легче расслабиться и начать решать остальные проблемы по одной. Лучший способ быстро что-то сделать - отдать этому свое время!

From: Alan Carter

Gary Mason wrote:

Такие авторы, как Carl French, Roger Pressman, Steve McConnell и MA Jackson, пишут, что наиболее желателен практический подход. Они утверждают, что начальными целями проектирования должно быть создание корректной, функционально связанной структуры, ключевые требования к которой - надежность, поддерживаемость и робастность, затем, когда проект становится семантически корректным, его нужно запрограммировать. Если после этого система заработала, и если она оказывается медленной, следует с помощью профайлера найти потенциальные узкие места. Суть в том, что легче модифицировать хорошо написанную (хотя и медленную) программу, чем программу, которую оптимизировали на каждой стадии процесса (и, возможно, немного замысловатую). Похоже, они предлагают высокоуровневый процедурный подход. Это тот подход, который я сейчас использую и которому научился в университете, изучая программотехнику.

Этому есть интересное выражение в книге Вернора Винжа "Пламя над бездной" (Vernor Vinge's "A Fire Upon The Deep"), моей любимой на этот момент фантастической книжке. Там есть создания, названные наездниками (Skroderiders), которые представляют собой комбинацию из разумного растения, у которого нет кратковременной памяти, и колесной тележки (Skrode), которая обеспечивает им кратковременную память и мобильность. Тележки наездникам дал некто в далеком прошлом.

Винж говорит, что тележки "с очевидностью трасцендентного дизайна... не иерархическая структура..." , и очень, очень эффективны. ("Трансцендентного" здесь означает интеллект, значительно превышающий человеческий).

Возвращаясь к дням, когда мы играли с кубиком Рубика, появлялось упоминание о "божественном алгоритме" (God's Algorithm), который всегда давал наикратчайший возможный путь к собранному кубику из любой позиции. Мы полагали, что "божественный алгоритм" не состоит из иерахической комбинации 7 базовых поворотов, которые многие из нас открыли и построили на их основе свой собственный "смертельный алгоритм" (Mortal Algorithms).

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

Так все же: самое эффективное решение - это путаница или иерархия? Я могу показать интересный способ не отвечать на этот вопрос с помощью такого наблюдения. Недавно я игрался с генетическими алгоритмами для оптимизации раскладки клавиатуры для людей с ограниченной подвижностью (парализованных и т.п.). Генетические алгоритмы эксплуатируют глубокую структуру "бессознательно". Они эксплуатируют тот факт, что хорошее решение очень сложной проблемы связано с другими хорошими решениями, поскольку глубокая структура - хорошие решения не беспорядочно рассеяны среди плохих решений. Взаимосвязи выявляют глубокую структуру. Теперь, имея хорошее решение, можно исследовать решение и увидеть, почему это решение хорошее. При этом можно узнать что-то о проблемной области. Можно узнать, Что Действительно Имеет Значение (What Really Matters), и при получении этого знания, решение становится очевидным - сначала не было так очевидно, что действительно были критические проблемы, и что они выявились.

Поэтому элегантное решение и эффективное решение - это на самом деле одно и то же, но элегантное решение - это вовсе не то, что изрыгает ныне модная "методология". Веруя в то, что существует Правильный Способ Достижения Результата (Correct Way To Proceed), а затем заявляя, что раз следовали этой процедуре, то результат обязан быть оптимальным - это заблуждение M0. Вместо того, чтобы использовать обратную связь в познании и позволить проблеме научить правильному способу смотреть на нее. Вот это истинно эффективная мета-методология.

Конечно, в общепринятой физике нет ничего, что говорит, почему это истинно в этой вселенной. Для этого нужна Взаимная Космология (Reciprocal Cosmology), либо какая-то другая теория, которая дает подобные наблюдаемые свойства вселенной. Вместо этого у нас есть вера общества M0 в то, что правильный способ достигать результата - определить процедуру, не задумываясь о ней, не важно, насколько она сырая, и затем бездумно ей следовать.

From: Robert White

Gary Mason wrote:

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

хм........... возможно, я занимаюсь этим слишком долго, но я ничего такого не делаю.

Хотя! ... не совсем так.

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

Все остальное - это нечто почти очевидное.
GIGO, Garbage In, Garbage Out. Мусор на входе, мусор на выходе.

Данные некоторого вида поступают, ты их массируешь, что-то с ними делаешь, и как-то массируешь выходные данные. Трудности обычно возникают из-за некоторого рода фальшивых требований. Например - работая на IBM этому идиоту нужно послать данные из HP на мэйнфрейм через PC,,,,, требуя от меня использовать APL.
Ох. Реальный мир стал нормальнее (несколько :-)

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

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

Microsoft могла бы сделать операционную систему гораздо лучше, но ей приходится иметь дело с двумя дьяволами: наследством DOS и должно-быть-с-графическим-интерфейсом. Linux делает гораздо более симпатичные операционные системы, но это главным образом инструменты и текст (plumbing and text). Дерьмо, я мог бы сделать это сам. (А у них до сих пор нет приличного браузера, а GUIs просто... ладно, не будем :-)

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

Rob
http://bangkokwizard.com/perl.html
"Я не думаю", сказал Декарт и тут же исчез.

From: Gary Manson

Alan Carter wrote:

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

Я понимаю, когда ты говоришь: "позволить проблемной области построить (структурировать) настоящее решение". И чем глубже понимаешь проблему и проблемную область, тем более эффективным будет решение, но так ли это на самом деле. Я действительно пытаюсь полностью исследовать и понять проблему до начала процесса написания программы, но можем ли мы отобразить глубокое знание проблемной области на создаваемое решение и, таким образом, на используемые ресурсы (память и вычислительную мощность).

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

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

Я действительно согласен с теми из вас, кто утверждает, что любит Проектирование, я тоже. Я не знаю, как это звучит, но я люблю создавать полные сложные диаграммы, затем концентрироваться на них, но я не могу сознательно учитывать эффективность, что медленно или быстро, поскольку я не нашел способа ее измерять, и потому это кажется бессмысленным. Было бы здорово услышать от вас, как на деле вы делаете Проектирование, каковы ваши цели, как вы решаете проблему Эффективности. Причина, по которой я пытаюсь понять этот аспект проектирования ПО, состоит в том, что я программирую уже 10 лет, и меня учили эффективности совсем недавно. Похоже, в университете каждый мог бы оценить, что он мог заставить программу делать и насколько понимает проблемную область, но не построение суперэффективного ПО, поэтому сейчас я продолжаю думать, что я совсем не понимаю проектирования ПО, но мне кажется, что с появлением быстрых процессоров и дешевой памяти, депрессия в ПО возникает из-за дефектов ПО. Мне просто любопытно, как это делают другие программисты.

From: Alan Carter

Gary Mason wrote:

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

Я сознательно учитываю эффективность, по крайней мере с точки зрения представления данных и т.п. Не лучший путь создавать решение, требующее n^2 времени, когда у природы есть ждущее вас решение log(n). Это ключевое разногласие между ритуалистами и творцами (ritualists and creatives).

Элегантность. Необходимая достаточность. Плато Качества. Как сказал Роберт Персиг в "Дзен, или искусство ухода за мотоциклом" (Robert Pirsig "Zen and the Art of Motorcycle Maintenance"), "Ты узнаешь, когда увидишь."

From: Alan Carter

Gary Mason wrote:

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

Как можно измерить эффективность, если не знаешь, как быстро можно сделать работу? Чтобы это узнать, нужно уже иметь элегантный, необходимый и достаточный проект. Метрический ритуализм - для тех, кто рассуждает исходя из ложных предпосылок, что это "правильный" ("proper"), т.е. совместимый с M0, способ делать вещи, и никогда не задумываясь, если в контексте их идеи бессмысленны. Видеть себя исполняющим ритуалы - вот и все.

Ты научишься большему в создании эффективного поддерживаемого ПО на уроках рисования (Arts foundation) ("Если любой элемент композиции убрать или изменить, но изменится и вся композиция."), чем из книг, где выясняется, что к проблеме целиком можно подходить механистично, поскольку это именно то, что хотят слышать читатели.

Мы знаем, что есть некоторые области, к которым необходимо подходить творчески. Я утверждаю, что проектирование ПО - одна из них. Это очевидно. Те, кто это отрицают, также заявляют, что нет таких областей, к которым нужно подходить творчески, что очевидная ложь, или что к ПО нельзя подходить творчески, поскольку они не смогут администрировать творчество. Именно поэтому коммерческое ПО стагнирует, а свободное ПО развивается.

From: Alan Carter

Gary Mason wrote:

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

Ты прав. Редукционисткие механистические "метрики" не применимы. Необходимый и достаточный дизайн - это многозначная сделка (tradeoff) многих элементов. Тебе приходится находить решения одновременно во множестве измерений (dimensions). Чем ты более опытен в использовании мозга таким образом, тем лучше у тебя это получается. Главное - думать, ходить, ходить, ходить вокруг проблемы, пока ее внутренняя структура сама не откроется перед тобой.

Замечательный факт, который не могут понять ритуалисты, но который знает каждый творческий программист, - у природы всегда есть элегантное решение, которое тебя ждет, если ты просто долго и упорно смотришь. В общепринятой физике нет ничего (за исключением наблюдений, касающихся фрактальной геометрии природы, алгоритмической избыточности вселенной и т.п.), что говорило бы, что это так. Вместо того, чтобы отрицать это наблюдение, мы должны принять, что физика еще не полна. Это не долно быть сюрпризом. "3: Reciprocal Cosmology" - это попытка расширить наше понимание физики, чтобы объяснить то, что мы наблюдаем.

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

Большинство метрик ПО мелочны и глупы. Они предназначены для того, чтобы пользователям было комфортно выполнять ритуал. См. обсуждение метрик ПО в "The Programmers Stone".

From: Gary Manson

Alan Carter wrote:

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

Когда ты противопоставляешь Ритуалистов и Творцов с точки зрения использования эффективных структур данных, чем руководствуются Творцы и Ритуалисты?

Я думаю, что концепция применения анализа алгоритмов и обязательный поиск готовых структур данных или алгоритмов превратил бы программирование и творческое проектирование в скучный процесс, по крайней мере для меня, как пример, я помню как в первый год обучения в университете меня спросили, как в текстовом файле с полями через запятую (Text file of Comma Seperated Fields) размером 60MB найти число повторов (дубликатов), вместо того, чтобы лезть за самым эффективным алгоритмом в книгу по алгоритмам и структурам данных, я создал метод, основанный на ISAM структуре (простой последовательный файл для ключей и файл с произвольным доступом) куда помещал слова и для каждого подсчитывал, сколько раз оно встречалось, некоторые же брали готовые алгоритмы хэширования и поиска (но мне это не глянулось), не уверен, что это делает меня плохим программистом, но это доставляет больше удовольствия.

Не уверен, что это делает меня Ритуалистом или Творцом, есть какие-нибудь соображения?

И еще одно примечание, я бы не смог вычислить О-большое для алгоритма, поскольку это показалось трудным, поэтому не зная, на что может быть похоже O(lg n), даже не стоит пытаться его вычислить.

Элегантность. Необходимая достаточность. Плато Качества. Как сказал Роберт Персиг в "Дзен, или искусство ухода за мотоциклом" (Robert Pirsig "Zen and the Art of Motorcycle Maintenance"), "Ты узнаешь, когда увидишь."

Что такое элегантность? Для меня элегантность - это сложность, сложность проблемы и сложность решения.

Я также часто думал, что через сложность может быть найдена Простота.

From: Alan Carter

Gary Mason wrote:

Когда ты противопоставляешь Ритуалистов и Творцов с точки зрения использования эффективных структур данных, чем руководствуются Творцы и Ритуалисты ?

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

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

Но предполагая, что просто потому что я "Использовал Ерундовину", чем бы ни была Ерундовина, результат обязан быть лучше размышления - часть лжи, содержащейся в коммерческом ПО. Вы должны знать этот эффект. Некий Причесанный Тип приходит к тебе, и притворяясь, что он руководит таким простаком как ты, говорит, "Ты Применил CORBA?", на что единственным ответом может быть, "Я написал скрипт резервного копирования в Korn. Для чего здесь нужна CORBA?" Тогда он говорит, "Но ты должен Применять CORBA для эффективности!"

Фальш на фальши.

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

Что такое элегантность? Для меня элегантность - это сложность, сложность проблемы и сложность решения.

Я также часто думал, что через сложность может быть найдена Простота.

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

То, с чем мы сталкиваемся в маркетоидной программотехнике - это подход, который говорит, просто засовывай все больше и больше замечательной сложности (сложность == умность) в горшок - a la икебана - и любой ценой избегай думать. Затем делай вид, что удивился, когда резко падает эффективность времени исполнения и экспоненциально растет число ошибок.

From: Alan Carter

Jacob O'Reilly wrote:

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

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

From: Bill Kress

Gary Mason wrote:

Поиск эффективности всего кода во время проектирования - это очень "Плохая Идея".

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

Основы:

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

Любое узкое место следует проанализировать и попытаться оптимизировать:

Сетевые коммуникации нужно проектировать в минималистстком ключе.

Если приложение работает с большими объемами данных, используй хорошо оптимизированную готовую базу данных.

Если ты используешь новый инструмент и думаешь, что он может стать узким местом (CORBA), протестируй его на тех объемах данных, которые будешь использовать до принятия каких-либо решений.

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

Иначе, даже не думай об оптимизации во время кодирования, сделай сказанное выше при проектировании, плюнь на остальное и напиши все правильно!

--------

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

Я сказал то же самое.

Проблема в том, что в группе правильной численности (команда разработчиков от 8 или более человек, в моем понимании), был бы чрезвычайно полезен отдельный разработчик с очень "Общими" навыками кодирования.

Он мог бы быть координатором ("Workflow coordinator"), но только не менеджером.

Если есть такая кандидатура, пожалуйста, дайте знать!
:)

From: Bill Kress

Gary Mason wrote:

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

Каково ваше определение хорошего проектировщика ПО и хорошего дизайна.

Хороший проектировщик ПО - картостроитель. Человек с интуитивным подходом к поиску "Правильного" решения. Большинству из них требуется умение чрезвычайно хорошо визуализировать решение. Я не знаю, как это описать, вероятно, можно найти что-то в PS.

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

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

Я проектирую и/или прототипирую интерфейс пользователя и вывод результатов. Это дает нечто для проверки (верификации) и приличную спецификацию требований.

По мере того как я этим занимаюсь, я постоянно думаю об уровнях ПО (software layout). Я пересматриваю их, временами забывая об этом на несколько дней, а потом заново все изобретая. Работа над проблемой делает размышление над решением "Интересным".

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

Между прочим, критическая информация здесь - какие существуют модули (units) и как выполнить интерфейс между этими модулями максимально простым и очень хорошо определенным (VERY WELL DEFINED).

Теперь я смотрю на каждый кусок. Если я могу увидеть решение, я говорю "Решено" и кладу его на программатор (back burner). Если нет - почему? Если я не вижу, что он работает, обычно здесь я быстро пишу прототип. Если я все еще не уверен, я заношу это в список "Приоритетно", чтобы реализовать в первую очередь. Именно здесь я часто замечаю, что данные проходят не совсем правильно, и мне нужно уточнить интерфейс.

Часто приходится делать резервную копию одного или более шагов.

Если все "Решаемо", каждый кусок следует рекурсивно разбить до уровня "Функция/Метод" или, по крайней мере, "Класс/Файл (на C)".

Наконец, я беру самый сложный кусок -- Если возможно, то, что я никогда не делал -- и пишу набросок на псевдо-коде. Каждая строка обычно соответствует одной функциональной области (functional area) (скорее всего 5-10 строк кода)

Я помещаю этот набросок в комментарии и начинаю добавлять под ним код.

Я извиняюсь, если что-то непонятно, я не знаю, как объяснить процесс визуализации без непосредственного общения.

Также я не знаю, как объяснить процесс "Нормализации" базы данных или структуры класс/метод. Ты это просто видишь.

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

From: William Wechtenhiser

Gary Mason wrote:

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

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

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

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

Фокус в том, чтобы осознать, что нет двух соображений (как написать программу и как сделать ее эффективной), но скорее есть единственное соображение (как написать эффективную программу).

From: Gary Mason

Alan Carter wrote:

Как можно измерить эффективность, если не знаешь, как быстро можно сделать работу? Чтобы это узнать, нужно уже иметь элегантный, необходимый и достаточный проект. Метрический ритуализм - для тех, кто рассуждает исходя из ложных предпосылок, что это "правильный" ( "proper"), т.е. совместимый с M0, способ делать вещи, и никогда не задумываясь, если в контексте их идеи бессмысленны. Видеть себя исполняющим ритуалы - вот и все.

Я подразумевал алгоритмический анализ эффективности времени исполнения (Runtime Algorithmic Efficiency analysis). Считаешь ли ты математические модели, а также использование метрик типа анализа стожности по МакКейбу (McCabes Complexity Analysis), ритуалистическими методами?

Ранее я не предполагал неявно, что творческие решения всегда менее эффективны, чем математически определенные алгоритмы, взятые на полке.

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

Ты научишься большему в создании эффективного поддерживаемого ПО на уроках рисования (Arts foundation) ("Если любой элемент композиции убрать или изменить, но изменится и вся композиция."), чем из книг, где выясняется, что к проблеме целиком можно подходить механистично, поскольку это именно то, что хотят слышать читатели.

Почему искусство может научить большему, чем CS/Software Engineering, в создании эффективного и поддерживаемого ПО? Я согласен до определенной степени, но хотелось бы развить эту тему.

Мы знаем, что есть некоторые области, к которым необходимо подходить творчески. Я утверждаю, что проектирование ПО - одна из них. Это очевидно. Те, кто это отрицают, также заявляют, что нет таких областей, к которым нужно подходить творчески, что очевидная ложь, или что к ПО нельзя подходить творчески, поскольку они не смогут администрировать творчество. Именно поэтому коммерческое ПО стагнирует, а свободное ПО развивается.

Я голосую за творческий метод, для меня программирование подобно Искусству, у тебя есть чистый лист и проблема, и ты создаешь (творишь) нечто, а не применяешь формальные математические подходы, хотя на самом деле я следую Джексону (Jackson) для структурирования своих мыслей перед программированием, но я не считаю, что JSP гарантирует хороший дизайн, скорее это инструмент, который я применяю для создания хорошей структуры.

From: Gary Manson

Alan Carter wrote:

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

Вовсе нет, я не верю, что раз решение разработано творчески, оно автоматически менее эффективно, чем алгоритм, взятый на полке.

Но предполагая, что просто потому что я "Использовал Ерундовину", чем бы ни была Ерундовина, результат обязан быть лучше размышления - часть лжи, содержащейся в коммерческом ПО. Вы должны знать этот эффект. Некий Причесанный Тип приходит к тебе, и притворяясь, что он руководит таким простаком как ты, говорит, "Ты Применил CORBA?", на что единственным ответом может быть, "Я написал скрипт резервного копирования в Korn. Для чего здесь нужна CORBA?" Тогда он говорит, "Но ты должен Применять CORBA для эффективности!"

Фальш на фальши.

Я согласен, большинство людей, от которых я это слышал - люди от маркетинга.

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

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

Расскажи мне о своей интерпретации Творческих программистов, я читал книгу Стивена Леви "Хакеры" (Hackers by Steven Levy), где он говорил о программистах, которые работали в Лаборатории Искусственного интеллекта МИТ (MIT AI lab), он утверждал, что некоторые из них при решении проблемы скорее отталкивались бы от своих идей, чем использовали бы формальные методы разработки ПО, они скорее создали бы алгоритм интуитивно и инстинктивно, чем использовали бы алгоритмы с полки, это ли ты подразумеваешь под Творческой Разработкой ПО?

То, с чем мы сталкиваемся в маркетоидной программотехнике - это подход, который говорит, просто засовывай все больше и больше замечательной сложности (сложность == умность) в горшок - a la икебана - и любой ценой избегай думать. Затем делай вид, что удивился, когда резко падает эффективность времени исполнения и экспоненциально растет число ошибок.

From: Bill Kress

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

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

Итак, если число особенностей требует выбора архитектуры, влияющей на производительность, то это предмет другой дискуссии (но по крайней мере у тебя есть место, которое можно будет потом оптимизировать). Этот момент нужно отметить во время проектирования и, если действительно не уверен, спроектировать и протестировать систему.

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

Сейчас я работаю над информационной системой для вертикального рынка, и за 6 месяцев исследовал эту индустрию и проблемную область достаточно полно и спроектировал решение для проблемы, теперь у меня нет представления, насколько быстрым или медленным оно будет, и я не думал об эффективности при проектировании, но я чувствую, что у меня есть глубокое понимание проблемной области, как совместить эти две стороны ?

Создай хорошую имитацию своей системы -- прототип. Проследи данные из конца в конец. Никаких бубенчиков, бантиков или результатов, но следуй "Колее данных" ("Data Trail"). Тогда ты узнаешь, сколько времени тебе потребуется для обработки данных.

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

From: Jacob O'Reilly

Gary Mason wrote:

William Wechtenhiser wrote:
Фокус в том, чтобы осознать, что нет двух соображений (как написать программу и как сделать ее эффективной), но скорее есть единственное соображение (как написать эффективную программу).

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

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

В процессе разработки я встаю на множество точек зрения. Я переключаюсь (alternate) между проектированием, программированием и тестированием (quality assurance) -- каждое из которых получило бы выгоду от эффективности. Я предпочел бы думать, что проблема - это не просто требования к программе. Я думаю, что тебе приходилось делать ошибки в проекте, что при этом оказываешься не способен решить проблемы быстродействия (например). Я считаю, что инструменты, которые я применяю, становятся узким местом гораздо чаще, чем остальное -- и обычно это вне моего контроля.

Я замечаю, что выполняю мысленную рекурсию в компоненты ПО, которое я разрабатываю, я делаю выбор на более высоком уровне, основываясь на потребностях высокого уровня, и потребности снижаются. Мне кажется, что в противном случае ты делаешь слишком много предположений. Лично я верю, что если ты сохраняешь вещи простыми, то у тебя остается очень мало места для неэффективности. Не применяй готовые компоненты, если не принимаешь их недостатки. Не прекращай уточнение (refining). Самое важное, если это тебе не нравится, то, с большой вероятностью, ты создаешь не самое лучшее.

From: Jo Giraerts

Alan Carter wrote:

Большинство метрик ПО мелочны и глупы. Они предназначены для того, чтобы пользователям было комфортно выполнять ритуал. См. обсуждение метрик ПО в "The Programmers Stone".

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

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

From: Alan Carter

Gary Mason wrote:

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

Чтобы поверить в обратное, пришлось бы сказать, что хотя печатаемые счета (или что-то еще) - это часть проблемной области, компьютер, который необходим для выполнения печати - нет! Это раздвоенный, диадический, дуалистический, переусложненный способ смотреть на вещи. Это не "очевидно очень умно", поскольку запутывает рассуждения!

Расскажи мне о своей интерпретации Творческих программистов, я читал книгу Стивена Леви "Хакеры" (Hackers by Steven Levy), где он говорил о программистах, которые работали в Лаборатории Искусственного интеллекта МИТ ( MIT AI lab), он утверждал, что некоторые из них при решении проблемы скорее отталкивались бы от своих идей, чем использовали бы формальные методы разработки ПО, они скорее создали бы алгоритм интуитивно и инстинктивно, чем использовали бы алгоритмы с полки, это ли ты подразумеваешь под Творческой Разработкой ПО ?

Это не вопрос изучения по книгам против интуиции. Ты не можешь быть интуитивным не поучившись основательно по книгам. Тебе придется изучить своего Леффлера, своего Буча, своего Кнута. То, чем на самом деле являются "формальные методы" - это способ избежать ответственности. Говорить, что делаешь одно, хотя на самом деле делаешь другое. "Быть очень умным."

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

Производительность для скольких особенностей (Runtime for how many features)? Вопрос должен звучать так: "Насколько быстро эта работа может быть сделана", где "рвбота" - это все те особенности, которые ты решил включить [в систему].

Для программирования не существует процедурного рецепта. Это суть. Ты должен знать математику и думать. Исполнение ритуала из книжки не работает при создании ПО - только при спихивании ответственности при круговой поруке.

Сейчас я работаю над информационной системой для вертикального рынка, и за 6 месяцев исследовал эту индустрию и проблемную область достаточно полно и спроектировал решение для проблемы, теперь у меня нет представления, насколько быстрым или медленным оно будет, и я не думал об эффективности при проектировании, но я чувствую, что у меня есть глубокое понимание проблемной области, как совместить эти две стороны ?

Если ты действительно понимаешь проблемную область, твоя программа не будет кодировать груды фальшивых ложных представлений - правд (pravdas) - и будет элегантной. Так что она вынуждена быть эффективной.

Почему тебя так заботит эффективность? У меня есть ощущение, что в своем вопросе ты что-то упускаешь (не договариваешь)!

From: Alan Carter

Gary Mason wrote:

Я всегда чувствовал, что инструменты МакКейба утверждают очевидное. Они могут преподнести сюрпризы лишь людям, которые используют вещи типа детекторов утечки памяти (memory leak detectors), поскольку они не знают, что делают их собственные программы.

Ранее я не предполагал неявно, что творческие решения всегда менее эффективны, чем математически определенные алгоритмы, взятые на полке.

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

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

Именно этому посвящен The Programmers Stone!

Почему искусство может научить большему, чем CS/Software Engineering, в создании эффективного и поддерживаемого ПО? Я согласен до определенной степени, но хотелось бы развить эту тему.

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

Абсолютно!

From: Alan Carter

Jo Giraerts wrote:

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

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

From: Gary Manson

Alan Carter wrote:

Если ты действительно понимаешь проблемную область, твоя программа не будет кодировать груды фальшивых ложных представлений - правд ( pravdas) - и будет элегантной. Так что она вынуждена быть эффективной.

Почему тебя так заботит эффективность? У меня есть ощущение, что в своем вопросе ты что-то упускаешь (не договариваешь)!

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

Чтобы пролить свет на это, и почему менеджер и я терпеть не могли друг друга, нужно немного сказать о моем образовании и складе ума. Я начал программировать в возрасте 17 лет (10 лет назад) выполняя BTEC по программированию, в основном это было программирование на Cobol, Pascal, что было замечательно.

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

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

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

Эффективность никогда не обсуждалась, или, может быть, я спал, когда это делали. Потом было обучение программотехнике в университете. Там напирали на формальные методы (доказательства Корректности и Эффективности), но потом я разработал свой собственный подход к программированию, который делал меня продуктивным и мне всегда нравилось начинать с чистого листа, подобно Художнику, и создавать нечто с нуля.

Я вседа применял JSP и язык программирования для структурирования своих мыслей о проблеме и программировании есественным путем, но когда я пытался сменить свою технику на более строгие подходы, то возвращался к своей стратегии через месяц.

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

В течении ряда лет мне хотелось просто находить замечательные сложные проблемы для решения (Мне особенно нравились сложные запутанные проблемы типа машин вывода (forward/chaining/Mixed mode inference engines), экспертных систем) и затем оказаться способным создать работающую и структурированную программу.

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

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

Мне кажется, это причина, почему я задаю эти вопросы.

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

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

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

Но размышления над формальными аспектами приводят меня в растерянность, и я не вижу выхода.

Я пытался читать Кнута, но прекращал после 8-10 страниц, поскольку просто не могу его понять, тоже и с другими книгами по алгоритмам, я пытался, но происходило то же самое.

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

From: Alan Carter

Gary Mason wrote:

Чтобы пролить свет на это, и почему менеджер и я терпеть не могли друг друга, нужно немного сказать о моем образовании и складе ума. Я начал программировать в возрасте 17 лет (10 лет назад) выполняя BTEC по программированию, в основном это было программирование на Cobol, Pascal, что было замечательно.

На пути к Программистскому камню я имел обыкновение говорить о программисте-ремесленнике (Artisan Programmer) - творческом и прилежном работнике, подобно мастеру прошлого.

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

Тебе очень повезло учиться такому здоровому и эффективному способу работы в академической среде!

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

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

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

Здорово!

Эффективность никогда не обсуждалась, или, может быть, я спал, когда это делали. Потом было обучение программотехнике в университете. Там напирали на формальные методы (доказательства Корректности и Эффективности), но потом я разработал свой собственный подход к программированию, который делал меня продуктивным и мне всегда нравилось начинать с чистого листа, подобно Художнику, и создавать нечто с нуля.

В доказательствах корректности присутствует реальная опасность. Приятель делал курс с PRG в Оксфорде (Oxford), группа Хоара (Tony Hoare's group) - родина Z. Он наблюдал, как парень выполнял замечальный анализ с помощью Z, а затем сделал ошибку транслитерации во время квазиисчисления для превращения в код. Ох!

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

Как и все вещи, Z великолепна, как помогающая тебе думать дисциплина, но смертельна, когда рассматривается как панацея.

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

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

В течении ряда лет мне хотелось просто находить замечательные сложные проблемы для решения (Мне особенно нравились сложные запутанные проблемы типа машин вывода (forward/chaining/Mixed mode inference engines), экспертных систем) и затем оказаться способным создать работающую и структурированную программу.

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

Это тот способ, который я рекомендовал в PS! Он очень хорошо работает.

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

Если ты - хакающая машина вывода, то ты - не нематематичен. Ты просто не занимаешься абстракгированием и манипуляцией символами ради них самих. Если ты взглянешь на "1: M0", ты увидишь предположение, что превозносимое основанное на символах мышление заменяется на превосходящее его мышление, основанное на смысле. Мыслители на основе смысла могут применять символы, они просто поддерживают осознание того, что означают символы. Поэтому их внутренние мониторы могут поддерживать проверку на здравомыслие. Символические фундаменталисты всегда подвержены опасности сделать ошибку и заявить, что толщина атмосферы Земли меньше 10 метров. Я такое видел. Вспомните, как недавно в NASA перепутали метры с футами!

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

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

Взгляните на Специальное Введение в верху страницы:

http://www.melloworld.com/Reciprocality

где я утверждаю, что уныние может привести через некоторое время к CFIDS (ME). Не позволяйте ублюдкам вас сломать!

Но размышления над формальными аспектами приводят меня в растерянность, и я не вижу выхода.

Я пытался читать Кнута, но прекращал после 8-10 страниц, поскольку просто не могу его понять, тоже и с другими книгами по алгоритмам, я пытался, но происходило то же самое.

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

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

Удачи тебе! Факт - коммерческое программирование чрезмерно и по-дурацки восторженно в тот момент, когда не способно помочь, но эй - ты прав, а они нет. IMHO :-)

Тебе может также понравиться культура freeware/Linux. Например, поищи в Сети Эрика Рэймонда (Eric S. Raymond)!

From: Gary Manson

Alan Carter wrote:

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

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

Если ты - хакающая машина вывода, то ты - не нематематичен. Ты просто не занимаешься абстракгированием и манипуляцией символами ради них самих. Если ты взглянешь на "1: M0", ты увидишь предположение, что превозносимое основанное на символах мышление заменяется на превосходящее его мышление, основанное на смысле. Мыслители на основе смысла могут применять символы, они просто поддерживают осознание того, что означают символы. Поэтому их внутренние мониторы могут поддерживать проверку на здравомыслие. Символические фундаменталисты всегда подвержены опасности сделать ошибку и заявить, что толщина атмосферы Земли меньше 10 метров. Я такое видел. Вспомните, как недавно в NASA перепутали метры с футами!

Я не использую никакой математики при создании машин вывода (inference engines), хотя Prolog в глубине своей - это поисковая машина, я бы сказал, что математика была самым последним, что было у меня на уме, когда я ее создавал. Похоже, это трудно объяснить, но при программировании я стараюсь думать о сложности, полон мыслей о том, что программа может делать, и, похоже, это работает, но даже при создании системы вывода смешанного режима (mixed mode reasoning system), которую было очень интересно построить, я не думал об эффективности и стандартных алгоритмах, я просто хотел ее решить (построить), как решить кроссворд или головоломку, я не уверен, что это за стиль программирования.

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

Когда мне приходится решать действительно сложную проблему, типа системы вывода смешанного режима, я бы не хотел лезть в Кнута или подобные книги. Я бы просто решил ее, думая о возможностях (features), я бы всегда добавлял возможности или пытался бы заставить ее делать большее, так работает мой ум. Так что, раз я не лезу в Кнута и подобные книги, означает ли это, что я не творческий человек? Кнут действительно проводит исчерпывающий глубокий математический анализ, но не в реальной проблемной области, но анализ решения со всей математической строгостью, это книга не по мне. Я бы предпочел просто понять. У меня есть ощущение, что лучше решать проблему или добавлять в программу новые возможности, или обобщать решаемую проблему и т.п.

Как бы ты классифицировал такое программирование или отношение, мне посто любопытно услышать твое мнение?

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

Удачи тебе! Факт - коммерческое программирование чрезмерно и по-дурацки восторженно в тот момент, когда не способно помочь, но эй - ты прав, а они нет. IMHO :-)

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

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

Тебе может также понравиться культура freeware/Linux. Например, поищи в Сети Эрика Рэймонда ( Eric S. Raymond)!

Кто такой Эрик Рэймонд и каковы идеалы культуры Linux, они разделяют те же идеалы или методы?

Твои ответы были самыми полезными

From: Alan Carter

Gary Mason wrote:

Я не использую никакой математики при создании машин вывода ( inference engines), хотя Prolog в глубине своей - это поисковая машина, я бы сказал, что математика была самым последним, что было у меня на уме, когда я ее создавал. Похоже, это трудно объяснить, но при программировании я стараюсь думать о сложности, полон мыслей о том, что программа может делать, и, похоже, это работает, но даже при создании системы вывода смешанного режима ( mixed mode reasoning system), которую было очень интересно построить, я не думал об эффективности и стандартных алгоритмах, я просто хотел ее решить (построить), как решить кроссворд или головоломку, я не уверен, что это за стиль программирования.

То, что ты делал, было математикой. Реальной, живой математикой. Я вспоминаю о Гадком утенке (Ugly Duckling).

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

Беда в том, что люди, которые предпринимают усилия, очень самокритичны и всерьез воспринимают критику. Несчастье, когда они сталкиваются с людьми, чьи демонстрации презрения/угрозы - гамбиты в "быть очень умным" и "играть игру". Воспринимать вещи всерьез - это не "слабость". Реальный мир не во всем враждебен. Враждебны только подобные говенные люди (asshole humans). Говенные люди рассуждают о "слабости" и т.п., что означает делать усилие.

Alan

P.S. Если полное отсутствие стыда у некоторых людей в программистской среде тебя огорчает, подумай, что хуже могут быть только адвокаты. Для адвокатов нет такой вещи как истина - только игры в слова.

From: Jacob O'Relly

Gary Mason wrote:

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

Хотя я бы не сказал, что у меня плохо с математикой, она никогда не была моей сильной стороной. Я бы сказал, что она редко появляется в программировании (в моем случае!) Если ты создаешь ПО, выполняющее расчеты, то это другая, но обычно не трудная задача.

Я не использую никакой математики при создании машин вывода ( inference engines), хотя Prolog в глубине своей - это поисковая машина, я бы сказал, что математика была самым последним, что было у меня на уме, когда я ее создавал. Похоже, это трудно объяснить, но при программировании я стараюсь думать о сложности, полон мыслей о том, что программа может делать, и, похоже, это работает, но даже при создании системы вывода смешанного режима ( mixed mode reasoning system), которую было очень интересно построить, я не думал об эффективности и стандартных алгоритмах, я просто хотел ее решить (построить), как решить кроссворд или головоломку, я не уверен, что это за стиль программирования.

Так же.

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

Я не думаю, что это слабость. Это суть опыта. Недавно у меня был случай, когда я потерял уверенность в себе. Я забыл, что люди не разумны и обычно корыстны. Мой идеализм часто берет верх, но я научился бороться с собой. Проблема с жизнью в том, что ты вынужден защищать себя.

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

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

Кто такой Эрик Рэймонд и каковы идеалы культуры Linux, они разделяют те же идеалы или методы ?

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

Реализация сервера LDAP - это было бы круто.

From: Matt Samudio

Jacob O'Reilly wrote:

Я не думаю, что это слабость. Это суть опыта. Недавно у меня был случай, когда я потерял уверенность в себе. Я забыл, что люди не разумны и обычно корыстны. Мой идеализм часто берет верх, но я научился бороться с собой. Проблема с жизнью в том, что ты вынужден защищать себя.

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

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

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

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

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

From: Erik Meade

Matt,

Я хотел бы поблагодарить тебя, что ты поделился этим с нами. Я обвинил бы тебя в том, что ты выхватил слова из моего рта, если бы не сомневался, что смог бы высказать их столь же элегантно. Это звучит так, будто мы "хлебали одну и ту же грязь". ( Слэнг воевавших на одной войне ). В результате оказалось, что когда мне пришлось заняться практикой Xp, я столкнуться с теми же проблемами, которые упоминал и ты.

Позднее я перестал размахивать Флагом Xp, и просто начал его применять. ( Хорошо, почти применять. ) Жители Xp (GrassrootsXp)

Сначала у меня, как казалось, была репутация Ковбоя от кодирования (CowboyCoder), но однажды люди увидели тесты моих модулей (unit tests), ( что обычно не происходит, пока кто-то не прибежит ко мне, заявляя, что мой код "сломался" ), и им стало трудно считать меня "опрометчивым". Я воспринял это как возможность предложить "помощь" ( читайте - Парное Программирование (PairProgramming) ).

Хорошо, это не совсем Парное Программирование, но это действительно дает мне шанс помочь моим партнерам сделать Простейшую Вещь, Которая Будет Работать ( так что я не теряю ни их, ни свое время ( хорошо, я так утверждаю )). Это также дает мне шанс упомянуть, что Тебе Это Нафиг Не Нужно ( по крайней мере на этот раз ), если у них есть несколько новых возможностей, которые мы можем добавить, раз уж мы занялись этим [модулем]. Если они решили, что они им действительно нужны, я прекращаю сессию Парного Программирования ( "Мне нужно вернуться к своему коду, дайте знать, когда устраните эту ошибку." ). Если дела идут хорошо, это удачное время приняться за формализованное тестирование модулей (UnitTesting). Если нет, я обычно произношу что-то типа: "Было бы здорово, если бы у нас был какой-то способ узнать, что этот код работал."

Я стараюсь, чтобы люди принимали практики Xp добровольно. Я не говорю им, что это такое, я не излагаю методологий, я просто пытаюсь помочь им сделать их работу проще.

Результаты были восхитительны. Перестали "сидеть на коде", другие разработчики пишут Тесты (UnitTests), у людей, которые работали в Паре со мной, исчезли Вуду-Ошибки (VoodooBugs) ( или VoodooFixes ). Поскольку мы не так много времени боремся с пожарами, система стала действительно документированной, документация настолько проработана, что пользователи ее расхватывают и присылают отзывы и запросы на расширение возможностей, и т.д.

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

From: Alan Carter

Erik Meade wrote:

Результаты были восхитительны. Перестали "сидеть на коде", другие разработчики пишут Тесты (UnitTests), у людей, которые работали в Паре со мной, исчезли Вуду-Ошибки ( VoodooBugs) ( или VoodooFixes ). Поскольку мы не так много времени боремся с пожарами, система стала действительно документированной, документация настолько проработана, что пользователи ее расхватывают и присылают отзывы и запросы на расширение возможностей, и т.д.

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

При условии, что это происходит каждый раз, когда люди прекращают глупую имитацию деятельности и воссоединяются с реальностью - будь это мышление Xp, PS, Деминга (Deming) или какое-то другое, всегда возникает вопрос: "Почему этого не понимают?"

В проекте Reciprocality делается предположение, что существует скрытый в нейрохимии / социологии M0 конкретный эффект, который направляет группы в иррациональном направлении.

From: Alan Carter

Subj: [progstone] Programming, Maths, Knuth

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

Истинная (real) математика - это понимание и исследование паттернов, стоящих за явлением, и (для людей практического склада ума) применение (leveraging) этого понимания для достижения своих целей. Упорство в размышлении о мире тем или иным предетерминированным (предопределенным) способом, даже не взглянув прежде на проблемную область, просто потому, что этот подход назвали "математикой" - это вовсе не математика. Это просто распространение бездумного процедурализма на абстрактные концепции.

Еще один пример подобного образа мышления можно обнаружить в химии. С какого то времени химией стали "заниматься" выписывая химические уравнения. Всякий, кто это делал, был химиком, и выписывание химических уравнений назвали "занятием химией" ("doing chemistry"). Затем несравненный Линус Полинг (Linus Pauling) - который захотел узнать, что делают атомы и молекулы - решил, что больше это не эффективный способ, и начал соединять шарики и палочки, чтобы облегчить себе визуализацию того, о чем он думал. Никто не посмел продемонстрировать Полингу презрение/угрозу, поэтому вместо этого стадо ослабило напряженность, подражая ему. Сейчас тот, кто соединяет вместе шарики и палочки (в наши дни это делают с помощью замечательной программы RasMol), "занимается химией".

Химическая интуиция Полинга была потрясающей. Чтобы вывести новые истины, он не выполнял последовательности преобразований над представлениями молекул. Вместо этого он Узнавал Молекулы (Knew Molecules). Он был способен это делать потому, что за многие годы строгого исследовательского размышления, он сделал пути атомов неотъемлемой частью феномена Линуса Полинга.

Насколько же далеко отходит от истины профессор программотехники Имперского колледжа в Лондоне (Software Engineering Prof. at Imperial College, London), который - я цитирую - утверждает, что "дисциплина, чтобы ей можно было обучить, должна быть процедурализируемой". Что за чепуха! Как художники, скульпторы, музыканты, менеджеры страховых фондов учат своих учеников? Нам вовсе не нужно вступать в дикуссию, можно ли процедурализировать эти дисциплины, чтобы заметить, что до сего дня это не сделано - но им все еще учат. Этот профессор - ведущий защитник концепции "Программной Фабрики" в Великобритании. Я утверждаю, что одно интеллектуальное банкротство отражает другое.

Что касается сложности Кнута, да, Кнут действительно труден. Но как только кто-то понял суть того, что он говорит о чем-то, все становится ясным и красивым. Приход к пониманию нескольких страниц Кнута - это сжатое Алхимическое Путешествие (Hermetic Journey), которое превратит тебя в того, для кого предмет становится самоочевидным, скорее, чем фильтрование процедурой, которой ты следуешь без интеграции ее в свое сознание. Трудность - нарастающая боль - все. И ты никогда не забудешь.

Как я уже говорил, Кнут глубоко теоретичен и практичен в одно и то же время. Вот повторение этой мысли в документации GNU. В Linux наберите:

$ man srand

В книге "Численные рецепты на C: Искусство научных вычислений" (Numerical Recipes in C: The Art of Scientific Computing (William H. Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New York: Cambridge University Press, 1990 (1st ed, p. 207)), сделаны следующие комментарии:

"Если вам нужно сгенерировать случайные целые в интервале от 1 до 10, то всегда следует делать так с помощью

j=1+(int) (10.0*rand()/(RAND_MAX+1.0));

и никогда с помощью чего-то вроде

j=1+((int) (1000000.0*rand()) % 10);

(где используются младшие биты)."

Генерация случайных чисел - сложная задача. Книга "The Numerical Recipes in C book" (см. ссылку выше) содержит великолепное обсуждение вопросов практической генерации случайных чисел в главе 7 (Случайные числа - Random Numbers).

За более теоретическим обсуждением, которое также охватывает более глубоко многие практические вопросы, отсылаем к главе 3 (Случайные числа - Random Numbers) в книге Дональда Кнута "Искусство программирования" (Donald E. Knuth's The Art of Computer Programming, volume 2 (Seminumerical Algorithms), 2nd ed.; Reading, Massachusetts: Addison-Wesley Publishing Company, 1981).

From: Chistopher Marshall

Алан

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

Еще один момент - не так давно большинство математиков проводили много времени программируя. Автоматизированное доказывание теорем прошло длинный путь, и программы типа Otter решили проблемы в абстрактной алгебре, которые до сих пор бросали вызов человеку.

Происходит то, что все больше и больше доказательств, которые мы хотели получить, чрезвычайно длинные. Кто-нибудь слышал о гигантской теореме, которая классифицирует все конечные группы? Я думаю, потребовалось 10,000 страниц и усилий многих людей, работавших над ее маленькими кусочками.

Как результат, прграммирование проникает в жизнь обычных математиков двумя путями. С одной стороны, 10,000-страничное доказательство, проведенное сотней математиков, содержало бы множество ошибок, если во время работы не использовать верификаторы доказательства. Верификаторы доказательства позволяют нам с уверенностью продвигаться в огромных доказательствах. С другой стороны, получилось так, что программы доказательства теорем способны справляться с определенными задачами доказательства, которые превышают человеческие возможности. Так что доказательство теорем будет состоять в некоторой части в запрягании доказывающих программ (подумайте об этом как исследовании путей, обследовании неудач программ, выяснению того, чему научились, а затем повтор).

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

Почему там много людей учатся программировать, и так (сравнительно) мало учатся теории множеств или анализу? Я думаю, что частично ответ заключается в том, что копьютеры дают непосредственную обратную связь. Программа дает тебе возможность узнать, когда она падает. Программы поощряют к игре [в смысле "поиграться с чем-то, чтобы понять" - С.К.]. Попытки прочитать книгу по теории множеств или анализу даже близко не дают столько обратной связи, если только у тебя не весьма специфичный склад ума. Занятия математикой с помощью верификатора доказательств, с другой стороны, походят на обучение программированию.

Еще одна причина состоит в том, что большинство книг по формальной логике паршивые без причины. Я имею в виду, что они ужасны (для целей самообучения). Мне удалось найти одну фантастическую книгу (Калиш, Монтегю и Мар "Логика: методы формального вывода" - Kalish, Montague, and Mar, "Logic: Techniques of Formal Reasoning" [Montague - это, на самом деле Монтекки, фамилия Ромео из "Ромео и Джульетты" Шекспира - С.К.]) и с тех пор у меня начался прорыв в математике.

Хорошо, почти. Мимо проскочила маленькая штучка под названием Linux, и я забросил на время математику, чтобы удовлетворить свое любопытство. Я долгое время был снисходителен к операционной системе, которую я не понимаю (Windows), так что я не могу остановиться читать и экспериментировать с Linux. Есть столько много хороших книг о Linux, и так мало хороших книг о Windows!

Надеюсь, что через год или два, мне удасться справиться с обаянием Linux, и я вернусь к математике. Определенно, я скучаю о ней.

Перевод: Prog.Stone

Русский сайт Programmers' Stone / Reciprocality http://progstone.narod.ru/

22 октября 2001

Используются технологии uCoz

Проектирование ПО, ступор и творческий хак Software Design, Mental Blocks and Creative Hacking

Проектирование ПО, ступор и творческий хак
Software Design, Mental Blocks and Creative Hacking