Вести разговор с людьми пытающимися сорвать аплодисменты на экстравагантности хамства мне интереса не представляет.
Подсказка: Если ты хочешь, чтобы тебя слушали оппоненты и относились к твоим словам с уважением, то не стоит вести разговор в снисходительном тоне и давать направо и налево "хинты".
Если хочешь обсудить мои слова, то исходи из предпосылок, что твое мнение не имеет никакого преимущества перед чужим. Я с удовольствием послушаю конструктивную критику своих слов и отвечу на нее. Но я не желаю выступать в роли оправдывающегося. В конце концов я, и что характерно, многие не последние люди на RSDN-е использую этот подход уже не мало времени и для себя определился в его высокой эффективности. Доказывать это тем, кто всеми силами противится принятию новых идей дело не благодарное. Жить они смогут и при самых экстенсивных подходах к разработке. Так что счастливо оставаться при своем мнении.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ты не подумай, я не агитирую за то, чтобы отказаться от библиотек. Ни в коем случае. Меня интересуют только те сложности, которые находятся "в промежутке" между готовыми библиотеками и целевым продуктом.
Есть такое. Поверь, сложностей хватает. Ведь все эти шаблоны и пр. вещи в С++ — они же не концептуально-другого плана (типа как С++ отличается от Пролога), они лишь элемент некоторой выразительности. Выразительность экономит нам время... Которое на С++ частенько приходится терять на всевозможные остальные мелочи. На мой взгляд то на то и выходит... поэтому я более склоннен делить задачи сейчас по нишам (технологическим).
ГВ>"Хрен здесь думать, это же не шахматы!". Ну ёжкин хвост, прям как дети!
А вот тут ты не прав. Да я ТЕ ЖЕ САМЫЕ ЗАДАЧИ И НА БЕЙСИКЕ сделаю. После того, я как ОСОЗНАЛ как именно надо решать задачу, я решу ее на большинстве современных популярных императивных языков. Т.е. я выразительность весьма цинично рассматриваю лишь как фактор, экономящий время. А на последних замерах времени учитывается, разумеется, суммарный результат.
Сразу после начала знакомства с дотнет (3 года назад) меня удерживало примерно то же, что и в Java — я не знал еще о ср-вах адекватного взаимодействия с имеющимися технологиями. В Java действительно, удобного способа нет, но вот в дотнет — проще простого. Это тоже один из немаловажных моментов... Ибо на С++ действительно можно все, что угодно, и начинает казаться, что на инструментах вроде дотнета подобной "бинарной" свободы нет... Да есть она и точно такая же...
ГВ>Да, конфетка-то в виде тонн халявы есть, но цена её — ухудшение стиля проектирования и реализации, переориентация с "сделать и забыть" на "сделать и переделать".
Это ты уже обобщаешь не свой и не мой опыт
У той хрени, что вместе писали, даже если бы сервак был на С++ ничего принципиально не поменялось бы с высоты птичьего полета. Разница видна только когда речь заходит о деталях имплементации... На дотнете удобно пользоваться всеми наработками дотнета, разумеется. Почему это должно означать плохой стиль?
Гена, средний уровень программистов постоянно и сремительно падает. Но не надо мне приводить этот уровень в пример. Большая часть этого уровня вообще способна существовать как программисты только на технологиях типа дотнета или VB. Это не значит, что у дотнета ограниченный потенциал, это лишь значит, что очень большую часть его функциональности (примерно 20-30%) могут легко освоить и даже с некоторой пользой для общества эксплуатировать даже новички.
Все это у тебя немного смахивает на обособление от "прокаженных". Мне глубоко пофиг, где конкурировать с "остальными". На любом поле у меня это неплохо выходило. Тут ведь речь не столько в поле, сколько в игроках. Талантливые будут заметны везде, так что если тебя волнует этот вопрос — не боись.
ГВ>Так, например, исключение МН вроде бы, значит не много, но на самом деле оказывает сильнейшее влияние на подход к проектированию.
Практически не оказывает, если ты про проектирование, ибо с т.з. абстракций в распоряжении есть МН интерфейсов. Однако да, оказывает сильнейшее влияние на кодирование имплементации. В принципе, ничего нового не придумали, в основном через агрегацию и делегирование все делается. Существенно облегчает жизнь особенность реализации конрактов-интерфейсов в классе-имплементаторе. Ты бы поинтересовался, из любопытства. У них вышла весьма "дружественная модель".
ГВ>"решарпер читает мои мысли!", это, как ты понимаешь, признак не высоты полёта решарпера, а кое-чего обратного.
Да нет. Просто в отсутствии include и макросов С# получился весьмадетерминированным языком и решарпер предлагает только то, что не будет являться ошибкой в данном месте. Иногда таких вариантов всего единицы, вероятность регулярного попадания решарпером в "нужный вариант" постоянно высока, особенно если взять крейсерскую скорость — 1 автокомплит в секунду .
ГВ>А с учётом сомнительных нововведений в C# положение будет усугубляться. Либо... либо C# превратится в подобие C++.
Нет, в подобие С++ он не превратиться. Заимствование идет на уровне концепций, но реализация будет носить специфичный, разумеется, оттенок. К тому же, мне глубоко пофиг насчет будущих тонкостей синтаксиса в новых языках. Это смешной объем информации для освоения. Гораздо важнее другие осязаемые моменты, типа: лаконичности, мощной кодогенерации и статической типизации. В Nemerle это уже отчасти можно пощупать.
ГВ>Ну и сразу возникает вопрос: а на хрена крюки выписывать? Апелляции к наличию большой библиотеки сразу отметаются по факту того, что для C++ этих библиотек хоть бульдозером греби.
Да гребли мы их неоднократно. У С++ных библиотек сложная судьба. У всех. Даже у STL. И эти библиотеки зачастую не переваривают друг друга, или требуют длительных уговоров для совместной работы. Ты же не от хорошей жизни свою библиотечку писал? А там же, в принципе, роперы над основными примитивами...
ГВ>Притом любую из них при желании можно выкинуть.
Д не так это просто. У С++ нет объединяющего центра в техническом плане. Либы взаимонезаменяемы. Если что-то где-то не пошло, то пишешь сам. И так всю жизнь. Я один лишь могу отметить плюс (по своим личным наблюдениям) — иногда подобная работа приносит удовольствие... Да, вместо того, чтобы тупо кодить функциональные требования, гораздо интересней разрабатывать фреймворки. Использование ТОЛЬКО ЛИШЬ С++ гарантирует такой вид занятости пожизненно.
ГВ>Не-а. Всё точно также. Главная проблема при стыковке языков с разными парадигмами именно в самом по себе совмещении парадигм. Технические мелочи в виде API разной степени корявости, методов обработки указателей и прочей ерунды на этом фоне просто теряются.
Не знаю, не знаю... В одном из енжинов пролога требовалось вручную корректировать указатель стека после вызова из АПИ и возврата ошибки. И такая хрень не сразу отыскивается... Я ведь говорю сейчас о все том же циничном факторе — затраченном времени. Время, потраченное на совмещение концепций не зависит от среды, в отличие от времени, угробленного на техническую сторону стыковки.
ГВ>Согласен, всё это можно. Беда только в том, что программист всё равно остаётся в рамках убогой выразительности C#. Кому-то это безразлично, а мне это остро не нравится. Точь-в-точь то же самое, что у меня когда-то было с Java. С проблемами single inheritance я нахлебался по уши ещё в Turbo Pascal 5.5/6.0... И плевать мне на мегатонны Java-библиотек. Я же не библиотеки собираюсь продавать, верно?
Но и не трудодни, Гена... А готовые рабочие решения.
Я ведь не призываю бросить С++. Сам для души вожусь с математикой, обработкой сигналов и системными вещами... На С++ разумеется. И на основном месте тоже опять плотно за него сел
Просто сейчас действительно пора бы и ознакомиться с другими подходами. Владеть одним из подходов — это как футболисту уметь бить только с одной ноги... Из-за этого иногда пропускаются хорошие комбинации.
-------------
Хочу добавить еще одно свое наблюдение. Действительно, шумиху раздули очень сильную вокруг дотнета. Разумеется, на кое-кого подобная "ненавязчивая" реклама возымела резко-отрицательное действие, мешающее трезво смотреть на вещи. В общем, ты понял
Re[18]: Философический вопрос про автоматический вывод типов
Здравствуйте, VladD2, Вы писали:
VD>Подсказка: Если ты хочешь, чтобы тебя слушали оппоненты и относились к твоим словам с уважением, то не стоит вести разговор в снисходительном тоне и давать направо и налево "хинты".
1. Насколько я понял, это был хинт?
2. А прибедняться зачем? Я лишь придерживаюсь общего тона нашей беседы:
Есть такая теория по которой use-cases-диаграмы — это не более чем обман и очковтирательство.
Еще раз повторюсь, что лично у меня обычно нет проблем с продумыванием большей части функциональности.
1. прИдумывание функциональности — это из области анализа, а не проектирования.
2. никто не жаловался на трудности в прОдумывании реализации
Вот возможность быстренько ошибиться и переделать, а не трястись на священностью процесса планирования и является сутью подхода.
Никто не трясется. Просто людям любобытно хотя бы примерно понять, что именно придется делать и хотя бы примерно спланировать затраты (временные — они же финансовые в нашей отрасли)
--------
И кстати, предыдущий мой пост перед критикуемым был вполне нейтральным.
VD>Если хочешь обсудить мои слова, то исходи из предпосылок, что твое мнение не имеет никакого преимущества перед чужим.
Угу, не слова хотелось бы обсуждать, но мысли. Бесконечно сожалею, что подобранные сторонами слова этому мешают...
VD>Я с удовольствием послушаю конструктивную критику своих слов и отвечу на нее.
Критику слов и услышал. А по смыслу, если не придираться к словам — все вполне по существу.
VD>В конце концов я, и что характерно, многие не последние люди на RSDN-е использую этот подход уже не мало времени и для себя определился в его высокой эффективности.
Если ты об поддержке твоей позиции IT, то я возражаю. IT очень долго собирал требования, вел обсуждения, вносил изменения в предыдущую версию. Стадия проектирования последней версии его детища ИМХО была черезчур длинной.
Хотя, если предположить, что мы все трое говорим о разных вещах... Например, IT имеет ввиду взаимоотношение конкретных классов в своем фреймворке и раскиданную м/у ними функциональность... На подобной стадии, поверь, я поступаю точно так же. Здравый смысл и решарпер в руки. До таких подробностей мало кто проектирует на бумаге сейчас.
VD>Доказывать это тем, кто всеми силами противится принятию новых идей дело не благодарное. Жить они смогут и при самых экстенсивных подходах к разработке.
К сожалению, твои идеи (вернее привычки) — не новые. Они инстинктивные и от них старательно отучают в некоторых местах. Тон в этой области задают люди, которые руководили проектами ценой в сотни человеко-лет.
------------ VD>Вести разговор с людьми пытающимися сорвать аплодисменты на экстравагантности хамства мне интереса не представляет.
Извини если задел
Че-то действительно рубанул сгоряча... Хотя, не сказал и десятой части чего хотел по теме. Проектирование во все времена будет болезненным вопросом. Для того, чтобы обеспечить действительно некую универсальность своим наработкам необходимо учесть такое потрясающее кол-во требований, что сама разработка прикладного фреймворка встает отдельной и очень достойной задачей. Тут рядом Гена хорошо про время жизни наработок сказал.
Ладно, завязываем
Re[18]: Философический вопрос про автоматический вывод типов
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>И в завершении хотелось бы сказать про документацию. IT указал, что самая точная документация – это программный код. Но эта информация не всегда самая полезная.
IT>Код — это как раз самая точная и достоверная информация. Когда уже не помогают хелпы, то остаётся только код. Да простит меня Бил Гейтс, но чтобы разобраться как работает баиндинг в WinForms, мне пришлось декомпильнуть фреймворк. Это уже после изучения всех MSDN'ов и прочих гуглей.
Да... биндинг в дотнете — это вообще пестня...
Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.
А ТРИЖДЫ запрашиваемые данные при загрузке и отображении формы??? Именно, если "ничего не делать" — трижды... Если кое-что в базовых классах делать, то можно снизить до двух раз... пестня...
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
V>Да... биндинг в дотнете — это вообще пестня... V>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.
Там ещё есть соответствующий интерфейс.
V>А ТРИЖДЫ запрашиваемые данные при загрузке и отображении формы??? Именно, если "ничего не делать" — трижды... Если кое-что в базовых классах делать, то можно снизить до двух раз... пестня...
Трижды? По-моему, там стрельба идёт как из пулемёта. А если учесть, что стандартный TypeDescriptor не отличается остротой ума и скоростью сообразительности, то картина совсем становится печальная.
Но если это всё правильно приготовить, то вполне может получиться деликатесная вещь
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Философический вопрос про автоматический вывод типов
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"?
По сравнению с традиционным проектированием, которое не просто не гарантирует отсутствие ошибок, а делает их значительно опаснее из-за невозможности своевременного выявления.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Философический вопрос про автоматический вывод типов
IT,
> ПК> Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше" и "уровень планирования выше"?
> По сравнению с традиционным проектированием, которое не просто не гарантирует отсутствие ошибок, а делает их значительно опаснее из-за невозможности своевременного выявления.
Что такое традиционное проектирование? (Напоминаю, что мы договорились
, что в обоих обсуждаемых случаях речь идет об итеративных процессах.)
> Паш, если ты с нами согласен, и придерживашся тех же подходов, то так и скажи. А то шифрушся тут.
Я разницу своих предпочтений по сравнению с озвучиваемым тобой подходом уже давно упомянул
Что-то вас господа занесло. Один апологет XP, другой водпадов.
Напишу о том как я проетирую в случае, если это не групповая разработка в которой нужно писать кучу, иногда не нужной, документации. Здесь упоминается только то, как я работаю один.
Этап 1. Думаю.
Я думаю над тем что я хочу сделать. Во первых, нужно ли это делать. Процентов 90 именно на этом этапе и заканчивается. И во вторых, что это должно быть. Это не архитектура. Это действия пользователей(будем говорить сценарии). При этом я придумываю эти действия пользователей. Чаще все рождается и остается в голове, если не умещается и вещь непростая в тетрадке. (кои всегда с собой). Но я не в коем случае не думаю как я это сделаю. Не дай бог, хотя бы одним нейроном подумать об архитектуре. Тогда картина вырисовывается, и получается решение которое легко сделать. А оно ошибочное, лучше думать о действиях пользователя или системы, или утилиты. Как только подумал об архитектуре не доработав действия, то можно считать проект пропал. Это самое сложное для меня. И за этим занятием я провожу большую часть проекта.
Этап 2. Сажусь за компьютер. С первыми строчками кода, типа void main(){} в голове уже лежит архитектура. Я ее как-то уже давно не придумываю. Она сама рождается. Я примерно представляю как это строить. И начинаю писать. Сначало пишу процедуру. Потом пишу для нее тест. Поскольку процедура обычно получается большой и здоровой, а по пацански сходу я красиво писать не умею, разбиваю ее на различные процедуры и объекты(то бишь рефакторинг). Потом следующую процедуру. Потом для нее тесты. Потом чувствую что эти две процедуры можно будет совместить в одну, но в два вызова с разными параметрами. Сново рефакторинг. Третья процедура уже будет построена на предыдущих. И т.д. Рефакторинг у меня идет все время. Пока пишу код.
Этап 3. Документирование. Нет ничего хуже чем понимать как все это работает через код. Ну фигово разбираться в классах и бегать по всяческим Class View да мотать колесика у мышки в поиске что тут имелось ввиду. Сам такое делал неоднократно, поэтому злорадно пытаюсь не делать документации. Пускай знают почем килограмм байтов. Но если тебя взяли за грудки и сказали что лишат премии, то пишешь некоторую концепцию. Этого и еще желательно тестов, вполне достаточно чтобы разобраться что там и как работает. Остальное все фигня, и лично мне мало помогало.
Насчет итераций. Нету у меня их. Потому как каждая процедура есть итерация.
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, Геннадий Васильев, Вы много писали писали...
Посмотришь вот так на подобные рассуждения, послушаешь... и думашь какие глубокие мысли, и какие филосовские идеи. Потом вглядишься по внимательнее и понимаешь... это же очередные понты.
Мужики, что-то в последнее время на этом форуме стала слишком часто проявляться нездоровая тенденция вместо осбуждения чего-то интересного, критики основанной на аргументации и предложении интересных примеров все больше и больше появляются откровенные залихватские понты. Причем оскорбительные по форме и пустые по содержанию.
Такой смысл создавать письмо на 4 экрана если вся его суть заключается в мысли — "все ламеры, а я тут один на белом коне..."?
В общем, видимо надо сносить такие "филосовские" темы во флэйм. Конструктива в них — 0.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так фокус-то в том, что при хорошем проектировании сразу многие вещи становятся ясными. И не надо наливать полную ванну воды, если вполне достаточно принять душ.
Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.
Если твое проектирование ириводит к тому, что мне прийдется мыться не в ванне, а под душем, то ну его на фиг такое проектрование.
VD>>Точно так же я могу спроектировать систему намного (я бы даже сказал радикально) быстрее если не буду "дышать" над каждым пунктом и если опущу тонкости до того момента когда они действительно потребуют проработки.
ГВ>На самом деле, всё зависит от того, что подразумевается под "финишем". Если появление прототипа — это одно. Если же появление всей запланированой функциональности — это уже совсем другое.
Всей запланированой функциональности.
ГВ>То-то я смотрю, плюхи в Янусе исправляли чуть не пару лет, или сколько он там существует.
Когда создашь хотя быть один открытый проект с хотя бы очень приблизительно сравнимой функциональностью я с удовольствием сравню результат и вместе с тобой сделаю выводы о том, какой из проектов сделан лучше. А пока что давай даже не будем обсуждать этот вопрос. Темболее, что основные проектные решения в Янусе были сделаны людьми не принимющими участия в этой дискуссии.
VD>>А быстрая и безболезненная модификация кода позволяют устранить появлющиеся в следствии этого перекосы. В итоге ошибаюсь я конечно чаще, но добираюсь до финиша первым, так как иду на полных парах и коректируюсь только когда это не обходимо. "Стандартный" же способ проектирования предлагает сразу спланировать маршрут без ошибко. Но это невозможно так как многие его тонкости становятся известны только когда ты реально с ними сталкнешся.
ГВ>Ещё раз: проектирование как раз и предполагает, что большая часть трудностей будет выловлена на его этапе.
Позволь обратить твое внимание, на то что одним из основных посылов наших повествований как раз был посыл говорящий о том, что к сожалению на стадии проектирования (если конечно речь не идет о 225-ой итерации допроектирования в итерациооном процессе) болшая часть трудностей просто щее не известна. Полное проектирование с нуля и целиком в таких условиях скорее самхивает на профанацию.
Так что рассказ о грамотном проектировании предовтвращающем большую часть проблем заранее для меня выглядит сказачно.
ГВ> Я не раз сталкивался с тем, что правильное проектирование (это не настолько трудная задача, как может показаться на первый взгляд) даёт на выходе ну очень большую сложность проекта, которую и показывать-то страшно, а потому приходится бросаться в программирование либо заведомо недопроектировав, либо заведомо занижая сроки, либо заведомо обрезая функциональность. Причина здесь вовсе не в какой-то порочности проектирования как такового, а в наличии у заказчиков банального психологического барьера.
Кстати, почему все время говорится о заказчике так как-будто все проекты на свете делаются для дяди. Причем для копризного дяди и еще к тому же слабо вменяемом?
А коробочные продукты уже не существуют? А вменяемые заказчики пологющиеся на опыт разработчиков?
ГВ> Например, нельзя заложить срок реализации 10 месяцев, а можно назвать не более, чем 5 месяцев. Хотя ясно, что при этом первоначальные 10 месяцев превратятся в ~14-15 с учётом времени, потраченного на реализацию прототипов.
Я как-то обычно видел обратную ситауцию. Те кто должен был реализовывать проекты сами занижали время нужное на реализацию проекта, или назвав реальное время откровенно про...вали часть этого времени.
То о чем говришь ты это уже откровенный бессовесный обман. Конечно и такое бывает, но это даже обсуждать не хочется. Да и офтоп это.
ГВ>Так что, ты уж поверь, очень давно и очень хорошо известна цена "быстрого программирования" и "проектирования в коде".
Извини, не поверю. И вообще, что-то не очень верится, что большинство из тех с кем приходится общаться в этой вертке вообще являются архитекторами и имеют в подчинении энное количество программистов исполнителей. Это все больше похоже на бунт кухарок пытающихся перекричать друг-друга в споре о том кто лучше знает как управлять страной.
В общем, нужно завязывать это соревнование. Все равно конструктива тут не будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Философический вопрос про автоматический вывод типов
Здравствуйте, Павел Кузнецов, Вы писали:
>> 2. Кто говорил об отсуствии этой самой стадии проектировани? Она есть, но намного короче, так как объем планируемых действий меньше, а уровень планирования выше.
ПК>Конкретно, по сравнению с чем и за счет чего "объем планируемых действий меньше"
За счет того, что планирование производится на более абстрактном уровне. Многие детали при этом намеряно опускаются до тех пор пока они не станут очтетливо ясны в следствии уточнения других деталей.
Ну, и за счет того, что в неясных моментах можно просто авантюристически выбрать первый глянувшися вариант в рассчете на то, что в последствии можно будет легко изменить код исправив просчет планирования. При обычном подходе, когда стоимость модификации очень высока такое себе никто позволить не может, считая, что лучше потратить лишний день на проработку деталей. К сожалению зачастую деталей становится столько, что все начинат банально рассыпаться.
ПК> и "уровень планирования выше"?
Все потому же. Проработка на начальной стадии менее глубокая, и более абстрактная. А детали уже уточняются по ходу дела, в том самом итеративном процессе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Этап 2. Сажусь за компьютер.
Я ещё такую вещь стал практиковать последнее время. Если кажется, что какой-то код может стать универсальным и его можно будет повторно использовать, то я его... правильно, никуда не выношу, никак отдельно не оформляю и никаких повторно-используемых модулей не создаю. Всё остаётся как есть. Но закладку в голове нужно положить. Когда возникает написать подобный код второй раз, то это будет... правильно копипейст И только на третий раз, а может даже на четвёртый, когда уже чётко видно сформировавшийся паттерн, он выносится в отдельный метод.
Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования. А значит требуется больше времени над ним подумать. То, что этот код где-то ещё несколько раз пригодится именно в таком виде — не факт. По-этому, кроме потери времени можно ещё и понаделать кучу одноразовых-повторно-используемых методов и классов. В результате мы имеем как выигрышь по времени, так и достаточно продуманную и полезную повторно-используемую часть подсистемы.
При чём тут рефакторинг и почему я так раньше не делал? Потому что это было долго и чревато багами, т.е. было неэффективно. Лугче было сразу продумывать и писать повторно-испольуемые вещи.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так что, ты уж поверь, очень давно и очень хорошо известна цена "быстрого программирования" и "проектирования в коде".
"Проектирование в коде" без современных средств, повышающих скорость набора кода, его модификацию и манипуляцию им — это псевдонаучная фантастика. Скорее всего оно тебе именно в таком виде и известно.
Кстати, следующей вещью повышающей скорость разработки скорее всего станут системы, позволяющие расширять компиляторы, что совместно с декларативностью даст возможность повторно использовать очень сложные паттерны.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Философический вопрос про автоматический вывод типов
Здравствуйте, IT, Вы писали:
IT>Что это даёт? Во-первых, к повторно используемому коду должны предъявляться повышенные требования. А значит требуется больше времени над ним подумать. То, что этот код где-то ещё несколько раз пригодится именно в таком виде — не факт. По-этому, кроме потери времени можно ещё и понаделать кучу одноразовых-повторно-используемых методов и классов. В результате мы имеем как выигрышь по времени, так и достаточно продуманную и полезную повторно-используемую часть подсистемы.
IT>При чём тут рефакторинг и почему я так раньше не делал? Потому что это было долго и чревато багами, т.е. было неэффективно. Лугче было сразу продумывать и писать повторно-испольуемые вещи.
Когда пишешь код на бумаге получается точно такой же эффект.
Вообще, написание кода сначала на бумаге напоминает парное программирование, только силами одного человека.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Мужики, что-то в последнее время на этом форуме стала слишком часто проявляться нездоровая тенденция вместо осбуждения чего-то интересного, критики основанной на аргументации и предложении интересных примеров все больше и больше появляются откровенные залихватские понты. Причем оскорбительные по форме и пустые по содержанию.
Ты не прав, IMHO. Мне было очень интересно и полезно почитать некоторые из здешних сообщений.
Я даже отфорвардил линк ребяам из команды, с предложением вынести эту тему на очередную "философскую пятницу" (периодическое собрание-обсуждение ситуации в отрасли... в вольном формате).
VD>Такой смысл создавать письмо на 4 экрана если вся его суть заключается в мысли — "все ламеры, а я тут один на белом коне..."?
А можешь предположить, что все остальное ты просто не видишь?
Мне глубоко пофиг, где конкурировать с "остальными". На любом поле у меня это неплохо выходило. Тут ведь речь не столько в поле, сколько в игроках. Талантливые будут заметны везде, так что если тебя волнует этот вопрос — не боись. 
Если нам не помогут, то мы тоже никого не пощадим.
