Здравствуйте, AndrewVK, Вы писали:
ГВ>>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения.
AVK>Черта с два. Я сам начинал всерьез программировать как раз когда на просторах необъятной стали популярны объектные TP 5.5 и TC 2. И тогда неприятие ООП было таким мощным, что сегодняшние войны против .NET ни в какое сравнение не идут. Запомнил я это хорошо потому что тогда сам испытал самую мощную ломку сознания за свою жизнь в попытке освоить ООП (а говорят — наоборот, мозги костенеют с возрастом).
Не совсем понял, если ты только начинал программировать, то откуда ломка сознания? И второе, чем ООП в интерпретации С++ отличается от Виртовской формулы " Алгоритмы+структуры данных=программы".
ГВ>> Почему для объяснения преимуществ "новых принципов" их нужно всенепременно попробовать?
AVK>Потому что иначе рискуешь попасть в плен к собственным предрассудкам.
Здравствуйте, VladD2, Вы писали:
VD>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.
VD>Если твое проектирование ириводит к тому, что мне прийдется мыться не в ванне, а под душем, то ну его на фиг такое проектрование.
Это мне напоминает истории про физиков и математиков. Типа, как погасить горящий газ — повернуть ручку плиты. Как погазить газ, если он не горит — зажигаем газ, и сводим эту задачу к предыдущей.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не совсем понял, если ты только начинал программировать, то откуда ломка сознания?
Читай внимательнее. Я написал всерьез программировать.
ANS> И второе, чем ООП в интерпретации С++ отличается от Виртовской формулы " Алгоритмы+структуры данных=программы".
Дизайном программ.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
IT>Я думаю, что это ещё связано и с тем, что это выглядит как будто проектирование как стадия совсем отсутствует. Но это не так. Оно точно также присутствует, только инструментами является не листок бумаги или какая-нибудь рисовалка, а сам компилятор и среда. А вот для БД ничего такого пока нет, поэтому приходится по старинке рисовать в Визио.
ИМХО PowerDesigner гораздо продвинутее Visio и подходит под "средство проектирования для БД", а не рисовалка
...Ei incumbit probatio, qui dicit, non qui negat...
Re[16]: Философический вопрос про автоматический вывод типов
IT>Таким образом, первое из перечисленных выше преимуществ проектирования становится не актуальным.
IT, отличный рассказ и я практически со всем согласен. С чем не согласен — проекты бывают разных масштабов и на них меняются разработчики (проект на 2-3 года скажем, люди могут уходить-приходить). Чтобы проект развивался обязательно должны быть зафиксированы структура проекта и т.п., это все забывается, не успевается передать и т.д.
Потом еще бывают ситуации с (мягко говоря) не самыми умными разработчиками, код которых приходится дорабатывать. Например, у меня была ситуация, когда я пришел в проект, половина которого была написана человеком за месяц до увольнения. Можно себе представить что там написал человек, котор. И сколько я промучался разбираясь в его коде (не было проектирования как такового по тому проекту, было только задание: сделать то-то и то-то).
...Ei incumbit probatio, qui dicit, non qui negat...
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Надо или не надо наполнять полную ванную не зависит от советов прохожих. Я хочу мыться в ванне, значит я буду мысться в ванне. Считай это незыблемым входным условием.
VD>>Если твое проектирование ириводит к тому, что мне прийдется мыться не в ванне, а под душем, то ну его на фиг такое проектрование.
ANS>Это мне напоминает истории про физиков и математиков. Типа, как погасить горящий газ — повернуть ручку плиты. Как погазить газ, если он не горит — зажигаем газ, и сводим эту задачу к предыдущей.
А мне твои слова напоминаю влезанием в середину разговора не разобрашись. К чему ты это сказал то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ> . . . могу сказать что ХП . . .
GZ>Для тестирования и documentation writers в основном полезны прецеденты написанные аналитиками а не архитекторами.
О, кстати, а как XP и выделенные аналитики и архитекторы сочетаются между собой? По моему представлению это вещи, не вполне совместимые...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[18]: Философический вопрос про автоматический вывод типов
Здравствуйте, VladD2, Вы писали:
VD>Такой смысл создавать письмо на 4 экрана если вся его суть заключается в мысли — "все ламеры, а я тут один на белом коне..."?
Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".
Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.
Гена утрирует, но что-то в этом есть. Действительно, на многих "популярных" задачах достаточно ныне нажать кнопку "пуск" и все работает само в этом дотнете. Единственно что потребуется изучать — это расположение самой этой кнопки.
Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
Re[20]: Философический вопрос про автоматический вывод типов
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, vdimas, Вы писали:
V>>Помню свой ступор, когда обнаружил, что они используют правила о name conventions событий PropNameChanging и PropNameChanged для обеспечения работы биндинга.
AVK>Это не байндинг, это особенности работы ReflectPropertyDescriptor.
Может быть, но используется именно в биндинге (и я пока не нашел, где еще).
Такие подходы — неявные шаманства по своей сути.
Re[22]: Философический вопрос про автоматический вывод типов
порассуждал для Wolfhound, как бы могли выглядеть "внешние" связи объектов и как бы работала система, построенная на этих внешних связях. Перекликается с биндингом и оповещением об изменении состояния.
Re[21]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
И это хорошо. Зачем заниматься всякими примитивными нюансавми если можно занятся настоящим делом?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?". V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.
А ты, если хочешь и дальше носить титул специалиста, должен подняться на планку выше и включать эту самую кнопку силой мысли попивая вино на канарах. В противном случае, это будет называться "живем старым жиром".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Философический вопрос про автоматический вывод типов
Здравствуйте, vdimas, Вы писали:
VD>>Такой смысл создавать письмо на 4 экрана если вся его суть заключается в мысли — "все ламеры, а я тут один на белом коне..."?
V>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".
Ну вот, Дима, наконец-то я понял главную мысль твоего ответа
. А то в ответ у меня очень объёмные какие-то рассуждения получались.
Короче говоря, здесь ты ошибаешься. Я имел ввиду не столько своё собственное "отличие от других", сколько "добавленную сложность" продукта. ИМХО, использование технологий вроде .Net/Java способствеут снижению этой самой ДС.
V>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.
Опять же, иллюстрация удачная, но только не к моей мысли, а к твоей. А ещё к тезису о том, что всякая сложная проблема имеет простое неправильное решение.
V>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
Так вот, ошибка как раз в том, что особенности C++ (в том числе и специфические комбинаторные приёмы) нужны не только для преодоления сугубо технических сложностей (кстати, а какие именно сложности ты имеешь ввиду как "технические"?). Да, они помогают, но не более того. Главное-то, ИМХО, другое — это возможность использовать приёмы C++ для реализации прикладной функциональности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: Философический вопрос про автоматический вывод типов
Здравствуйте, AndrewVK, Вы писали:
ГВ>> Четвёртая: подозрительная корреляция рассуждений провозвестников нового с тем, что делает MS. Проследить это можно на примере шаблонов (Кто тут пел, что это нафиг не нужно и приведение от базового Object — рулез форева?).
AVK>Влад? Не припоминаю.
Сейчас некогда копаться, поищу как-нибудь на досуге. Может быть, и ошибаюсь.
ГВ>>Для того, чтобы понять преимущества объектного подхода перед структурным "пробовать" как правило, нужды не было. Достаточно было простого объяснения. AVK>Черта с два. Я сам начинал всерьез программировать как раз когда на просторах необъятной стали популярны объектные TP 5.5 и TC 2. И тогда неприятие ООП было таким мощным, что сегодняшние войны против .NET ни в какое сравнение не идут. Запомнил я это хорошо потому что тогда сам испытал самую мощную ломку сознания за свою жизнь в попытке освоить ООП (а говорят — наоборот, мозги костенеют с возрастом).
Интересно. У меня такой ломки не было, хотя тоже, опыт структурного программирования на момент появления ОО-языков в наших пенатах уже был. С окружающими — да, были стычки. Правда уже попозже... но это уже совсем другая история.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Философический вопрос про автоматический вывод типов
V>>Не все, а многие, юзающие "удобные" технологии. Что не так? В этом Гена был прав, а акцент-то был в другом: "не получится ли так, что я, как специалист хорошими навыками, перестану выделяться на общем фоне... и если да, зачем мне это надо?".
ГВ>Ну вот, Дима, наконец-то я понял главную мысль твоего ответа
. А то в ответ у меня очень объёмные какие-то рассуждения получались.
ГВ>Короче говоря, здесь ты ошибаешься. Я имел ввиду не столько своё собственное "отличие от других", сколько "добавленную сложность" продукта.
Да поняли мы это, разумеется. Вообще-то, в чем и можно было выделяться, так это в ДC
(остальные характеристики, типа "общей эрудированности" как-то не очень меня интересовали)
V>>Действительно, представь, что некий экскаваторщик виртуозно владел своим экскаватором и в бригаде экскаваторщиков легко делал, предположим 500% плана. Потом привезли автоматические экскаваторы, где роль экскаваторщика стала заключаться в нажатии кнопки "пуск" утром в начале работы. Разумеется, все его прежние навыки стали ненужны.
ГВ>Опять же, иллюстрация удачная, но только не к моей мысли, а к твоей. А ещё к тезису о том, что всякая сложная проблема имеет простое неправильное решение.
Я позволил себе утрирование, и оно, имхо, напрямую обращено к твоей ДС.
V>>Просто настало интересное время, чтобы начать искать себе более интересные задачи, чем всякие технические подробности, которые мы раньше виртуозно решали и которые ныне решать не нужно.
ГВ>Так вот, ошибка как раз в том, что особенности C++ (в том числе и специфические комбинаторные приёмы) нужны не только для преодоления сугубо технических сложностей (кстати, а какие именно сложности ты имеешь ввиду как "технические"?).
Кто-то кого-то тоже прочитал невнимательно... Я не сказал, что С++ для этого НУЖЕН (более того, я так не считаю), я в этих постах выше говорил о том, что на нем ПРИХОДИТСЯ это делать, из-за слабой прикладной базы.
Что такое техническая сложность на мой взгляд? Это некий эквивалент силы умственных напряжений (не путать с количеством), которое оно от меня требует. Иногда такие задачи попадались. Помнишь, я как-то говорил тебе, что обнаружил за собой, что последние лет 5-6 работаю "не думая"? Может быть, потому я так легко тратил время и на другие технологии, что банально давно не встречал "сложных" задач, для которых С++ был бы хорош.
ГВ>Да, они помогают, но не более того. Главное-то, ИМХО, другое — это возможность использовать приёмы C++ для реализации прикладной функциональности.
Отличные приемы, никто не спорит. Но я еще 2-мя постами сверху ставил на одну чашу весов выразительность С++, а на другую — отсутствие тонны мелочей, на которые ПРИХОДИТСЯ отвлекаться, работая на С++.
Мне бесконечно жаль, что на данный момент времени эти весы реально существуют. Это произошло потому что за последние буквально лет 7-10 взрывообразно возросла информационная емкость проектов, но не были сформированы языки, фреймворки и среды, отвечающие этим потребностям. Тот факт, что люди ВЫНУЖДЕНЫ использовать гораздо менее выразительные языки лишь из-за наличия платформы, показывает всю глубину (и позор, не побоюсь этого слова) этого отставания.
Я ведь не столько спорю с кем-то, сколько делюсь личными ощущениями и реальным опытом и там и там.
----------
Разумеется, такая ситуация не продлиться вечно. Никто в здравом уме не будет отказываться от предыдущих наработок, они будут возвращены в индустрию, но, я уверен, в новом качестве. В общем, в любом случае, пора привыкать к мысли, что помимо С++ могут быть еще языки, и, возможно, они лет через 5 его переиграют даже на его собственном поле (эффективность и выразительность).
----------
Помнишь мой пост на sql.ru 3-х летней давности, с которого мы познакомились. Я считал, что С++ позволяет наиболее близко подходить в описании абстракций к интересующей прикладной области. Оно по прежнему так. (Например, в дотнете есть кое-какая перегрузка операторов, но невозможность перегрузить операторы: =, +=, -=, <<= и т.д. убивает добрую половину выразительных трюков, в общем, поэтому перегрузкой операторов там почти не пользуются )
Re[20]: Философический вопрос про автоматический вывод типов
Здравствуйте, Anton Batenev, Вы писали:
AB>А ты, если хочешь и дальше носить титул специалиста, должен подняться на планку выше и включать эту самую кнопку силой мысли попивая вино на канарах. В противном случае, это будет называться "живем старым жиром".
)
