Re[16]: Философический вопрос про автоматический вывод типов - Философия программирования

Здравствуйте, VladD2, Вы писали:

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

Навскидку несколько нетехнических причин неприятия. Первая: если в "принципы" нужно поверить, то это уже не принципы а догмы. Вторая: объяснения зачастую состоят из передёргиваний и подмены понятий, а зачастую и из бессвязно-восторженных речей. Последнее свойственно, например, твоим постингам (уж извини). Третья: нередки попытки тем или иным образом унизить э... "представителей старого мира", что естественным образом провоцирует неприятие и оратора и того, о чём он орёт. Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает MS. Проследить это можно на примере шаблонов (Кто тут пел, что это нафиг не нужно и приведение от базового Object — рулез форева?). Интересно, если MS всё-таки вставит в C# x.0 множественное наследование, как изменятся куплеты в этой песне?

Вот это — действительно проблемы. Правда, в основном, для .Net-community. Из серии "нахрена нам враги, когда у нас есть такие друзья?". Хм. Кажется, когда-то я уже что-то подобное говорил.

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

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

Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения. Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать? Почему после попробования должна быть непременно одна и та же реакция? Там на мозг как-то влияют? Я вот попробовал — не торкнуло. Потенциал .Net — да, отлично понимаю. Будет ли он реализован в полной мере? Не уверен. Однако вижу, что C# медленно, но верно превращается в свалку идей, подходов и прочего, в точно соответствии с принципом "огонь и движение". То есть, налицо "раскрутка" в лучших традициях шоу-бизнеса. Прости, но я не отношусь к любителям современной попсы. Наверное, у меня полно э... "внутренних страхов" и моя э... "подсознательно понимает, что не прав". Можно, кстати, наплести и ещё чего-нибудь квазипсихоаналитического. Как я погляжу, тут мастеров по этой части пруд пруди.

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

VD>Вот такая получается фрэйдистская фигня.

Точно, фигня. А ещё — передёргивание и некорректный переход на личности.

Здравствуйте, eao197, Вы писали:

ГВ>>Это были неправильные задачи!
E>

E>Все мы жертвы цепи нелепых случайностей.

E>((С) К.Вонегут).

И заказчики у тебя неправильные! Они несут неправильный мёд. Так что, ты его не пей, козлёночком станешь. Давай, бросай всё и вливайся в ряды миллионов. Ты понял, нет? Миллионы тебя ждут. Мил-ли-о-ны!А ты, понимаешь, расчирикался! Ты ещё не понял, как надо компиляторы писать? Эх, и поимела же тебя матрица! По самое фрейдистское начало.

Здравствуйте, VladD2, Вы писали:

E>>Ну и кроме того, если ты программируешь на C# под Windows, то это совсем не значит, что твой опыт будет полезен мне в C++ под Unix. А мне платят именно за C++.

VD>Тебе не платят за С++ и темболее за то что что-то под Линукс.

Влад, это было сильно! Я в восторге. Можно на бис?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И заказчики у тебя неправильные! Они несут неправильный мёд. Так что, ты его не пей, козлёночком станешь. Давай, бросай всё и вливайся в ряды миллионов. Ты понял, нет? Миллионы тебя ждут. Мил-ли-о-ны!А ты, понимаешь, расчирикался! Ты ещё не понял, как надо компиляторы писать? Эх, и поимела же тебя матрица! По самое фрейдистское начало.

Гена, что-то ты злой сегодня.

Здравствуйте, eao197, Вы писали:

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

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Гена, что-то ты злой сегодня.

Да нет, Женя, это я ещё не злой.

Это, в общем, шуточный пост был.

Здравствуйте, VladD2, Вы писали:

VD>А у меня планирование занимает минуты, от силы часы. А вот реализация почему-то дни. Причем заранее извесно, что после того, как реализация хоть как-то заработает, то после анализа (а то и в процессе разработки) будут выявлены неучтенные предпосылки которые приведут к изменению плана, а стало быть и кода.

VD>Так мы плавно подходим к теме рефакторинга.

Я опять же делаю его в мощьной IDE, а ты в снова в своем уме и Нотпэде.

То, что защищает Влад в лице ReSharper-а является в большей части удобным средством рефакторинга, когда решение о проведении того или иного типа рафакторинга уже принято разработчиком. Да, он умеет принимать кое-какие решения за разработчика (как то Extract method), они все основаны на статическом анализе кода.

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

Здравствуйте, eao197, Вы писали:

E>Все время не нужно. Только на момент проектирования. А это не так уж и сложно. Особенно, если нарезать систему на слои и не смешивать их без лишней надобности.
BDUF очень часто приводит "плохо пахнущему" дизайну. Современные процессы разработки ПО, а особенно гибкие итеративны и инкременты: проектирование выполняется на каждой итерации, все время. Модель Waterfall дискредетировала себя.

E>Всегда ли требуется рефакторинг, к примеру, 200 тысяч строк кода?
Вспоминается врезка от Рона Джеффриза 263 странице в книге Фаулера, о рефакторинге "Введение Null Object" в проекте C3 там этих рефакторингов немало, выполнялись они часто, да и сам C3 немаленький проект.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, IT

Данное сообщение не является попыткой покритиковать или опровергнуть что-нибудь в рассказе IT. Как я понимаю, Игорь просто поделился своим опытом. У меня же есть мой опыт, исходя из которого я смотрю на некоторые вещи чуть иначе. Так же я думаю, что мы с IT занимаемся разными задачами, что дает возможность нам использовать разные подходы к разработке.
Этот пост в некоторой степени является ответом и на сообщение VladGalkin, о хороших результатах инкрементальной разработки и дискредитировавшей себя модели Waterfall.

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

Степень точности зависит от уровня абстракции. На каком-то уровне нужно точно понять, что необходимо разработать инструмент SObjectizer (или ACE, или Spring, или BLToolkit, конкретное имя ничего не значит). Здесь мы можем более-менее расплывчато представлять себе конкретные возможности нового инструмента, но зато точно должны знать, чем этот инструмент отличается от конкурентов и зачем он нужем нам (либо потенциальным покупателям).

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

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

По моему мнению, здесь нет никакой модели Waterfall. На каждом уровне абстракции я нахожусь ровно столько, сколько нужно чтобы понять, что я точно представляю себе работу этого уровня. И что это знание позволяет мне двигаться дальше. Не на всех уровнях возможно написание кода, но если где-то возможно и это имеет смысл, то я пишу код. Но я предпочитаю пользоваться при проектировании именно бумагой, потому что:
* лично меня отвлекает большое количество мелких деталей общения к компьютером (хотя бы необходимость периодически сохранять изменения в документе);
* на компьютере для меня «хуже обзор», т.к. даже на мониторе с большим разрешением я вижу гораздо меньше деталей, чем на двух сложенных рядом листах формата A4;
* в большинстве случаев процесс поиска точного представления напоминает блуждание в тумане, когда перебираются десятки вариантов. Многие варианты отвергаются и затем принимаются к расмотрению по несколько раз, многократно перекраиваются и возвращаются затем к первоначальному варианту. Лично мне не хочется проделывать лишнюю работу и проделывать все это мышкой в Visio, поскольку на бумаге все это для меня гораздо проще.
Кстати, приведенный мной черновой вариант решения с timer_thread_t оказался не правильным. И я выбросил его не написав ни одной лишней строчки кода. У меня не возникло соблазна взять какую-то часть написанного кода для нового решения (не знаю как у кого, но у меня такой соблазн всегда был слишком велик).

И еще один важный момент по поводу проектирования. Неявно подразумевается, что проект все равно будет неоднократно пересматриваться, требования к нему будут изменяться и все равно его придется перекраивать и переделывать. В некоторых предметных областях только так и можно, но не везде. При разработке программного инструментария ситуация несколько иная. Если я разрабатываю объектную СУБД, то глупо, имхо, расчитывать на то, что требования к ней будут меняться раз в месяц. Нет, я сразу должен буду получить приемлимый результат. Более того, должен быть выбран такой API для СУБД, который бы позволил выпустить несколько версий СУБД не нарушая совместимости клиентских приложений. А в разработке СУБД есть области, в которых лично я не представляю себе написания кода без точного понимания того, как он будет работать. Например, механизм записи транзакционных изменений посредством write-ahead log. До написания кода я уже должен четко знать, какая метаинформация информация должна быть в log-е, как по этой информации определять актуальность log-а, как по log-у восстанавливать БД после сбоя, можно ли использовать log для организации on-line репликации и пр. Конечно, точный состав и форма представления метаинформации будет меняться по ходу реализации. Сама реализация может быть итерационной, где некоторые части метаинформации будут игнорироваться на разных итерациях. Еще более вероятно, что перед разработкой будет создано и выброшено несколько прототипов. Но суть в том, что лично я не представляю, как придти к механизму write-ahead log-а начав с программирования подсистемы write-ahead log-а.

И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная. Например, если речь идет о вспомогательных библиотеках. Я думаю, что для программиста, использующего ACE, не так уж много пользы даст код метода ACE_Event_Handler::handle_input или ACE_Reactor::run_reactor_event_loop. А в некоторых случаях кода используемой библиотеки нет вовсе. На первое место в таких условях выходит документация, написанная в комментариях к методам и классам. Но чтобы ее написать, довольно часто нужно представлять себе всю картину в целом. Картину, которая открывается мне после предварительного проектирования на бумаге. Поэтому, когда я приступаю к программированию, я приступаю и к документированию. При этом написание doxygen комментариев к коду является, наверное, более трудоемкой и длительной операций, чем кодирование. Зато на выходе получается еще и довольно объемный и актуальный Reference Manual. Конечно, не иногда он не нужен. Но, поскольку я всегда старался заниматься разработкой инструментария, то практически постоянно мне приходилось делать еще и документацию. И предварительное проектирование на бумаге существенно облегчало этот процесс.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения. Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать?

Потому что нет новых принципов. Есть менее выразительный язык. Разумеется, требуется уговаривать переходить с более выразительного языка на менее выразительный. Что именно предлагается попробовать?

ХАЛЯВУ!!! Горы, целые кладези бесплатной функциональности. Это действительно зачастую торкает и сильно. Факт: распределение усилий программиста м/у низкоуровневыми и высокоуровневыми задачами стало другим.

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

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

ГВ>Почему после попробования должна быть непременно одна и та же реакция?

Это зависит от степени потребности в халяве.

ГВ>Там на мозг как-то влияют? Я вот попробовал — не торкнуло.

Значит, твои задачи не были реализованы на 90% в нем.

Я как-то рассуждал о надежности в ответ тебе: http://www.rsdn.ru/Forum/Message.aspx?mid=1609434&only=1

ГВ>Потенциал .Net — да, отлично понимаю. Будет ли он реализован в полной мере? Не уверен. Однако вижу, что C# медленно, но верно превращается в свалку идей, подходов и прочего,

Ну... почему в свалку? В полигон для испытаний. Такой набор готовой функциональности в сочетании со св-вами самой среды (в числе прочих — прощение ошибок и неточностей), превращает .Net в готовую программную лабораторию. Затраты на маленькие и не очень эксперименты как никогда низки. А всякие IDE + рефакторинг позволяют превратить результаты экспериментов в готовый продукт... Не хочу прямо здесь и сейчас обсуждать "готичность" подобных подходов. Напомню лишь, что подобный подход неплохо сочетается с концепцией программного эксперимента и, местами, принципами групповой организации разработки (не кодинга, а именно разработки... помнишь про заглушки у Фисуна

?).

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

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

ГВ>Прости, но я не отношусь к любителям современной попсы. Наверное, у меня полно э... "внутренних страхов" и моя э... "подсознательно понимает, что не прав".

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

VD>>Так что похоже все эти попытки бесполезны. Вот Паша у нас до сих пор придумывает себе аутотренинг на тему "почему мне не нравится C#".

ГВ>Точно, фигня.

Да не, не фигня. Просто трудно признаться самому себе, что для себя УВАЖАЕМОГО, такой момент, как объем и качество халявы, является значимым аргументом, по сравнению с провалом выразительных ср-в инструментария, коим придется пользоваться. Это требует в какой-то мере переступить через себя.

Возможно, С++/CLI способен временно послужить в качестве компроммисса, пока для дотнета не создадут достаточно выразительного языка (языков). Мне вот Nemerle показался интересным направлением. Действительно, что-то от философии макросов Lisp-а в нем есть, т.е. имеется полный контроль над кодогенерацией. Но в отличие от Лиспа — все это в сочетании с типизированным языком. Правда, к сожалению, сам код этих макросов еще не столь декларативен, как хотелось бы (так же как и в Лиспе, кстати), но это вопрос времени, вернее — наработок готовых библиотек этих макросов, в т.ч. и обслуживающих задачи программирования макросов. Нечто типа шаблонов С++ вполне можно будет написать.

----------------
Для себя я свою позицию уже давно определил: тонны отлаженной (то бишь — высоконадежной) функциональности — это всегда гут. Бедноватый язык (поначалу действительно трудно было с этим кастратом, порой до психа... потом привык) воспринимается как плата за халяву. С другой стороны, тешу себя мыслью, что развитие самих языков идет весьма шустро. Действительно, C#2.0, например, на порядок удобнее, чем предыдущая версия. Да и всякие Nemerle и прочие функциональные языки на подходе... И все это в сочетании с действительно гладкой стыковкой в рамках фреймворка... Ведь и у тебя и у меня достаточно опыта по стыковке разных по парадигмам языков и технологий в одном проекте... В общем, это всегда были уникальные решения "по месту"... Сейчас, очевидно, все не так.

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, eao197, Вы писали:

E>>О каких системах ты говоришь?

IT>Кто-то мне тут недавно приводил в качестве примеров Вижуал Студии, MS Офисы и прочие IE, Мазилы и Оперы

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

1.1.4 stable rev. 510

Sinclair,

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

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

Интересно, что вы спорите с совершенно другой позицией, чем озвучиваемая вашим оппонентом... Т.е. при критике его позиции у вас идет речь о полном vs. итерационное проектирование/разработка, в то время, как ИТ и Влад озвучивали позицию отсутствия выделенного этапа проектирования до кодирования, а eao197 настаивал на его полезности (по крайней мере, для себя). Наличие выделенного этапа проектирования вполне возможно на каждой итерации. Более того, это вполне согласуется с рекомендациями всевозможных RUP, XP etc.

Posted via RSDN NNTP Server 2.0

Здравствуйте, eao197, Вы писали:
E>Кстати, приведенный мной черновой вариант решения с timer_thread_t оказался не правильным. И я выбросил его не написав ни одной лишней строчки кода. У меня не возникло соблазна взять какую-то часть написанного кода для нового решения (не знаю как у кого, но у меня такой соблазн всегда был слишком велик).
Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая. И вот ты получил лист A4, и сэкономил несколько строк кода.
Я пока еще не достиг нужного уровня просветления, но довольно давно предпочитаю проектировать в терминах кода. Раньше мне это было не очень удобно, потому что я писал на дельфи, а там еще и изменения в интерфейсе не очень хорошо отображались в имплементейшн. Не говоря уже о внешних ссылках.
Сейчас в студии я пишу код не задумываясь. При этом получается у меня быстрее, чем на бумажке:
— когда я описываю интерфейс или делегат, мне вообще не нужно делать лишних нажатий. За меня почти все дописывает автокомплит.
— когдя я меняю сигнатуру, у меня под рукой рефакторинг, который мгновенно согласованно меняет весь солюшн.
Поэтому мне не страшно сделать ошибку. Я не пользуюсь решарпером, т.к. он еще недостаточно стабилен. Но даже встроенный рефакторинг VS2005 позволяет мне думать кодом.
При этом самое милое — в том, что когда я хочу нарисовать картинку, дизайнер диаграмм делает это гораздо быстрее и аккуратнее, чем карандаш и бумага. И, в отличие от бумаги, эти картинки не теряются под столом, а идут в SVN. И они бесплатно сохраняют актуальность, если я что-то поменял в коде!
Я выбрасываю довольно много кода. Зачастую придуманные мной интерфейсы/классы не переживают очередного витка рефакторинга. Но я отношусь к ним так же, как к бумажкам на столе — периодически выкидываю их из SVN.
Получается, что мне проектировать в студии дешевле, чем на бумаге!

E>И еще один важный момент по поводу проектирования. Неявно подразумевается, что проект все равно будет неоднократно пересматриваться, требования к нему будут изменяться и все равно его придется перекраивать и переделывать. В некоторых предметных областях только так и можно, но не везде. При разработке программного инструментария ситуация несколько иная. Если я разрабатываю объектную СУБД, то глупо, имхо, расчитывать на то, что требования к ней будут меняться раз в месяц. Нет, я сразу должен буду получить приемлимый результат. Более того, должен быть выбран такой API для СУБД, который бы позволил выпустить несколько версий СУБД не нарушая совместимости клиентских приложений.
API — пожалуйста. А внутреннее устройство можно пересматривать как угодно. Более того, обычно этого не делают не потому, что не надо, а потому, что очень дорого.
E>А в разработке СУБД есть области, в которых лично я не представляю себе написания кода без точного понимания того, как он будет работать. Например, механизм записи транзакционных изменений посредством write-ahead log. До написания кода я уже должен четко знать, какая метаинформация информация должна быть в log-е, как по этой информации определять актуальность log-а, как по log-у восстанавливать БД после сбоя, можно ли использовать log для организации on-line репликации и пр. Конечно, точный состав и форма представления метаинформации будет меняться по ходу реализации. Сама реализация может быть итерационной, где некоторые части метаинформации будут игнорироваться на разных итерациях. Еще более вероятно, что перед разработкой будет создано и выброшено несколько прототипов. Но суть в том, что лично я не представляю, как придти к механизму write-ahead log-а начав с программирования подсистемы write-ahead log-а.
А что ты начинаешь делать при проектировании? пишешь текст? Ну так я просто набиваю // и тайпаю. Возникла какая-то сущность типа LogRecord? Ок, пишем:

internal struct LogRecord
{
  Guid Id;
    DateTime TimeStamp;
    |
}

E>И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная. Например, если речь идет о вспомогательных библиотеках. Я думаю, что для программиста, использующего ACE, не так уж много пользы даст код метода ACE_Event_Handler::handle_input или ACE_Reactor::run_reactor_event_loop. А в некоторых случаях кода используемой библиотеки нет вовсе. На первое место в таких условях выходит документация, написанная в комментариях к методам и классам. Но чтобы ее написать, довольно часто нужно представлять себе всю картину в целом. Картину, которая открывается мне после предварительного проектирования на бумаге.
Гм. К моменту, когда у тебя завершено проектирование на бумаге с текстами, у Влада и IT уже готов набор заглушков на все методы этой библиотеки. Все мало-мальски существенные мысли записаны не карандашом, а в блоках ///. Поэтому в конце достаточно просто просмотреть эту документацию на предмет корректности, понятности и полноты.
E>Поэтому, когда я приступаю к программированию, я приступаю и к документированию. При этом написание doxygen комментариев к коду является, наверное, более трудоемкой и длительной операций, чем кодирование. Зато на выходе получается еще и довольно объемный и актуальный Reference Manual. Конечно, не иногда он не нужен. Но, поскольку я всегда старался заниматься разработкой инструментария, то практически постоянно мне приходилось делать еще и документацию. И предварительное проектирование на бумаге существенно облегчало этот процесс.

1.1.4 stable rev. 510

Здравствуйте, Sinclair, Вы писали:

S>Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая.

Строки отлаженного кода штука дорогая.

Вообще, я никому не навязываю свой способ работы. Не доказываю, что чей-то способ работы ущербен.

Я просто рассказал, как я работаю. И к этому механизму я пришел не сразу, а за 15 лет, которые занимаюсь программированием. Если кому-то не нравится -- это его дело. Если кто-то не верит, то может посмотреть на RuCodeGen, Mxx_ru, ObjESSty, SObjectizer. Это все проекты, которые развивались практически в свободное от основной работы время. Для меня это служит доказательством эффективности моего подхода (примененного ко мне).

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

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Sinclair, Вы писали:

S>>Гм. Ты как бы неявно предполагаешь, что строчки кода — штука дорогая.

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

E>Я просто рассказал, как я работаю. И к этому механизму я пришел не сразу, а за 15 лет, которые занимаюсь программированием. Если кому-то не нравится -- это его дело. Если кто-то не верит, то может посмотреть на RuCodeGen, Mxx_ru, ObjESSty, SObjectizer. Это все проекты, которые развивались практически в свободное от основной работы время. Для меня это служит доказательством эффективности моего подхода (примененного ко мне).

E>Если кто-то использует другие способы работы, то мне интересно про них узнавать и брать что-то на вооружение. Но я не собирась на навязывать свое мнение, ни реагировать на навязывание мне чужого мнения.
Ну, я надеюсь, что ни о каком навязывании речи не идет.
Я вообще всю жизнь хотел как можно больше проектировать. Но меня постоянно сдерживала тщетность моих усилий — бумагу в SVN не положишь, и в какой-то момент все равно надо набить этот код руками. Пробовал UML, но постоянно бесило отсутствие round-trip и поддержки полной модели языка. В какой-то момент я пришел к проектированию в коде, и использованию плагина в Розе для визуализации — благо Delphi позволял довольно шустро педалить интерфейсы (студия в те времена в качестве автокомплита предлагала вообще все, что ей известно, включая макросы. Се ля ви — плюсы язык такой, никогда заранее не знаешь, что удастся привести к чему

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

Теперь вроде как есть кульный кульман. Все как встарь, только в углу кнопка "построить здание по этому чертежу"

1.1.4 stable rev. 510

О!

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

Вообще, все эти разговоры о скорости написания кода мне достаточно смешны. Просто лично у меня на кодирование и отладку (!) в общей сложности уходило (раньше — пока занимался именно програмингом) примерно полтора часа в день. Все остальное — проектирование и выстраивание концептуальной модели. И если бы я даже сэкономил что-то из этих полутора часов, это была бы не сильно существенная экономия.
Пожалуй мне была бы полезнее (в плане итоговой эффективности) какая-нибудь хорошая среда написания use case, чем навернутая среда разработки с авторефакторингами. А еще лучше — интеграцю idef с теми же use case и ментальными картами. Но такой пока не нашел (по "рейшеновские" продукты можно не говорить — достали).

Здравствуйте, Sinclair, Вы писали:

E>>Строки отлаженного кода штука дорогая.
S>Так никто и не предлагает отлаживать этот код. Ты же не занимаешься отладкой идей на бумаге? Вот и этот код начинает отлаживаться только в том случае, если дожил до реального использования.

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

Приведенный мной пример с timer_thread_t как раз стал яркой тому иллюстрацией. На тот момент мне представлялось, что я четко представляю себе, как будет работать не только timer_thread_t, но и необходимый ему ACE_Event_Handler. И если бы я взялся за программирование, то написал бы код, заставил бы его работать, прикрутил бы к нему тесты. Проблема была бы в том, что в очень эпизодических ситуациях (когда вызов destroy_all_agent_msg() совпал бы с определенным моментом времени при обработке периодического сообщения этого агента) происходила бы порча памяти. Я сильно сомневаюсь, что такую ошибку удалось бы отловить в автономных тестах. И в реальном использовании она бы возникала очень нестабильно. Зато при проектировании, когда кода не было написано вообще, эта ошибка стала очевидной как только я взялся расписывать обработчик handle_timeout. Иначе как отладкой идей на бумаге я назвать это не берусь.

Может быть кто-то и может при программировании помнить детали проекта, но это не я.

От:	eao197	http://eao197.blogspot.com
Дата:	12.02.06 08:14
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	12.02.06 08:48
Оценка:	44 (4) +1 -1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	12.02.06 09:00
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	12.02.06 09:05
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	12.02.06 09:52
Оценка:

От:	Андрей Коростелев	http://www.korostelev.net/
Дата:	12.02.06 10:56
Оценка:	+1

	От:	VladGalkin
	Дата:	12.02.06 11:09
	Оценка:	28 (1)

	От:	vdimas
	Дата:	13.02.06 13:17
	Оценка:	22 (2) -1

От:	Sinclair	https://github.com/evilguest/
Дата:	13.02.06 13:27
Оценка:	+2

	От:	Павел Кузнецов
	Дата:	13.02.06 14:11
	Оценка:	+1 -1

От:	EXO	http://www.az.inural.ru
Дата:	13.02.06 15:01
Оценка:

От:	IT	linq2db.com
Дата:	13.02.06 15:37
Оценка:	+4