Вот смотрите...
Пишу я сюда.
"От себя отрываю". Что-то удачно, что-то - не очень. По моему собственному мнению.
Но мотивация - поделиться идеями, которые родил за 25-ть лет программирования.
Вроде хорошая мотивация...
Ещё раз - "поделиться", а не "проевангелировать".
Вроде хорошая мотивация...
И код я вроде бы привожу. И идеи. И решения. И диаграммы.
Но что я слышу в ответ в "основном"?
Код - "говно". Идеи - "надуманны". Решения - "противоречивы". Диаграммы - "не нужны". Собственные фреймворки - "это велосипеды".
Ведь так?
По-моему - так. :-)
Какой из этого стоит сделать вывод?
Наверное я зря пишу?
Нет понимания...
И казалось бы - я "никого никуда не тяну". Наоборот - "берите - пользуйтесь". Не нравится - "не пользуйтесь"...
Но!
Код - "говно". Идеи - "надуманны". Решения - "противоречивы". Диаграммы - "не нужны".
Смотрю вокруг. Пост - "как сделать рамку вокруг TLabel" - комментарии - "ах спасибо, ах вы нас так выручили".
Мне же - "Александр, а какая ваша мотивация" :-)
Хотите постов "как сделать рамку вокруг TLabel"? Их есть у меня. Миллионы.
Они правда интереснее?
P.S. Это я к чему? Да просто так... Мысли вслух.. "аплодисментов" - я не жду и не ждал. Но если уж пишете "код - говно" (например - http://18delphi.blogspot.ru/2013/09/blog-post_4485.html?showComment=1381143520224#c2080311922311651444), ну как-то - обосновывайте. "Код - говно", про СВОЙ код - это я МОГУ сказать без обоснования (ЧУЖОЙ код, я с давних пор - стараюсь не трогать). Но если уж вы ГОВОРИТЕ - будьте добры обосновывать.
А то ведь вот какие суждения на "просторах интернетов" встречаются:
"Да, прошел бессмысленный бум. Это же сугубо служебная технология для облегчения проектирования с помощью формализованных диаграмм.
Но сами диаграммы остались прежде всего в SQL-сервере.
Не представляю себе программиста, который бы НЕ ЛЮБИЛ пользоватся диаграммами в SQL2005.
Что касается сложных иерархий классов - и их проектирования на UML - то есть такие инструменты в VS2008 (в версии для архитектора) - но на мой взгляд - сама эта идея - строить матрешки из классов - это гораздо более глючная идея чем даже GOTO. Матрешки из классов очень затрудняют проектирование и фантастически затрудняет отладку.
Обьектное программирование в его полной концепции - когда пишешь класс, а затем модифицируешь его работу НЕ ПАРАМЕТРОМ, а наследованием от базового класса - это исключительно глючнейшая концепция - чисто теоретическое измышление. Игра ума, жутко неудобная на практике. Если уж даже GOTO ругают - эта концепция наследования - тыцсячекратное усложнение ветвлений относительно GOTO.
По этой причине не представляю себе программиста, который бы строил эти падарастические матрешки из классов с помощью UML-диаграмм в каком-то серьезном проекте.
Это все измышления для студентов и для лаборатоных работ...
Что касается применения UML в проектировании общих концепций взаимодействия распределенных систем - то многие вещи делаются просто UML-диаграммами VISIO, ну и в продуктах Rational тоже конечно можно. Только этот сегмент проектирования (относительно проектирования баз данных c помощью UML-подобных диаграмм) - вряд-ли даже 1% составляет.
Поэтому, на мой взгляд - концепция UML осталась в виде диаграмм в готовых рыночных продуктах -прежде всего в SQL- сервере. И в VISIO и проч (для остальных 1% задач)"
http://www.sql.ru/forum/605052-4/kto-chto-dumaet-ob-uml-moda-proshla
P.P.S. Думаете вообще не стоит писать? "национальное индейское жилище". По-моему всё же - СТОИТ.
Пишу я сюда.
"От себя отрываю". Что-то удачно, что-то - не очень. По моему собственному мнению.
Но мотивация - поделиться идеями, которые родил за 25-ть лет программирования.
Вроде хорошая мотивация...
Ещё раз - "поделиться", а не "проевангелировать".
Вроде хорошая мотивация...
И код я вроде бы привожу. И идеи. И решения. И диаграммы.
Но что я слышу в ответ в "основном"?
Код - "говно". Идеи - "надуманны". Решения - "противоречивы". Диаграммы - "не нужны". Собственные фреймворки - "это велосипеды".
Ведь так?
По-моему - так. :-)
Какой из этого стоит сделать вывод?
Наверное я зря пишу?
Нет понимания...
И казалось бы - я "никого никуда не тяну". Наоборот - "берите - пользуйтесь". Не нравится - "не пользуйтесь"...
Но!
Код - "говно". Идеи - "надуманны". Решения - "противоречивы". Диаграммы - "не нужны".
Смотрю вокруг. Пост - "как сделать рамку вокруг TLabel" - комментарии - "ах спасибо, ах вы нас так выручили".
Мне же - "Александр, а какая ваша мотивация" :-)
Хотите постов "как сделать рамку вокруг TLabel"? Их есть у меня. Миллионы.
Они правда интереснее?
P.S. Это я к чему? Да просто так... Мысли вслух.. "аплодисментов" - я не жду и не ждал. Но если уж пишете "код - говно" (например - http://18delphi.blogspot.ru/2013/09/blog-post_4485.html?showComment=1381143520224#c2080311922311651444), ну как-то - обосновывайте. "Код - говно", про СВОЙ код - это я МОГУ сказать без обоснования (ЧУЖОЙ код, я с давних пор - стараюсь не трогать). Но если уж вы ГОВОРИТЕ - будьте добры обосновывать.
А то ведь вот какие суждения на "просторах интернетов" встречаются:
"Да, прошел бессмысленный бум. Это же сугубо служебная технология для облегчения проектирования с помощью формализованных диаграмм.
Но сами диаграммы остались прежде всего в SQL-сервере.
Не представляю себе программиста, который бы НЕ ЛЮБИЛ пользоватся диаграммами в SQL2005.
Что касается сложных иерархий классов - и их проектирования на UML - то есть такие инструменты в VS2008 (в версии для архитектора) - но на мой взгляд - сама эта идея - строить матрешки из классов - это гораздо более глючная идея чем даже GOTO. Матрешки из классов очень затрудняют проектирование и фантастически затрудняет отладку.
Обьектное программирование в его полной концепции - когда пишешь класс, а затем модифицируешь его работу НЕ ПАРАМЕТРОМ, а наследованием от базового класса - это исключительно глючнейшая концепция - чисто теоретическое измышление. Игра ума, жутко неудобная на практике. Если уж даже GOTO ругают - эта концепция наследования - тыцсячекратное усложнение ветвлений относительно GOTO.
По этой причине не представляю себе программиста, который бы строил эти падарастические матрешки из классов с помощью UML-диаграмм в каком-то серьезном проекте.
Это все измышления для студентов и для лаборатоных работ...
Что касается применения UML в проектировании общих концепций взаимодействия распределенных систем - то многие вещи делаются просто UML-диаграммами VISIO, ну и в продуктах Rational тоже конечно можно. Только этот сегмент проектирования (относительно проектирования баз данных c помощью UML-подобных диаграмм) - вряд-ли даже 1% составляет.
Поэтому, на мой взгляд - концепция UML осталась в виде диаграмм в готовых рыночных продуктах -прежде всего в SQL- сервере. И в VISIO и проч (для остальных 1% задач)"
http://www.sql.ru/forum/605052-4/kto-chto-dumaet-ob-uml-moda-proshla
P.P.S. Думаете вообще не стоит писать? "национальное индейское жилище". По-моему всё же - СТОИТ.
Не, Александр, конечно же пишите! Я вот с удовольствием читаю, хотя не всегда с первого раза въезжаю. Перечитывать приходится. Но я чую, что то, о чём вы пишите - это пригодится. И не мне одному.
ОтветитьУдалитьВ частности, к "своему фреймворку" я пришёл сам. А когда искал всякие материалы (ну чтобы не изобретать велосипед), очень часто натыкался на то, что люди приходят к тому же самому - делают свои фреймворки. И не потому, что свой - он самый правильный, а потому, что универсального, который бы был полезен абсолютно всем (и подошёл бы под любые задачи) - нет. (Сейчас я вот хочу из нашего "фреймворка" выделить самый такой ни на что не завязанный слой и завернуть его в BaseForms, кое-что уже опубликовано и Вы это видели в блоге.)
Касательно UML - я уже давно подумываю над тем, что пора подняться над кодом на этаж выше. Потому что даже имея _свой_ фреймворк, всё равно от дублирования кода не уйти. Думаю, Вы понимаете о чём я.
Итогового мнения об UML у меня пока не сложилось. Я перелопатил много статей, и на текущий момент, мне пока так думается, что UML это не самый лучший вариант для _наших_ задач, ну или скажем так - не для всех наших задач. Но есть задачи, где оно точно подойдёт.
Вот про DSL тоже интересно. Хотя бы посмотреть, как люди это используют.
"Не, Александр, конечно же пишите!"
ОтветитьУдалитьСпасибо, но речи конечно не было о том, чтобы "не писать".
"В частности, к "своему фреймворку" я пришёл сам."
Понимаю :-)
"Сейчас я вот хочу из нашего "фреймворка" выделить самый такой ни на что не завязанный слой и завернуть его в BaseForms, кое-что уже опубликовано и Вы это видели в блоге."
Я знаком с этим не только по блогу :-) Есть у меня определённая "инсайдерская" информация :-)
" Потому что даже имея _свой_ фреймворк, всё равно от дублирования кода не уйти"
Вот вот.. Не уйти.. Его можно лишь "шаблонизировать"...
"Думаю, Вы понимаете о чём я."
Понимаю.
"UML это не самый лучший вариант для _наших_ задач"
Я бы смотрел не в сторону UML. А в сторону кодогенерации из "квадратиков и стрелочек".
"Вот про DSL тоже интересно. "
DSL ведь имеет "миллион" применений. Вы в каком разрезе "к нему пришли"?
"Я знаком с этим не только по блогу :-)"
Удалить-- и мне НРАВИТСЯ - то, что вы делаете.
"Сейчас я вот хочу из нашего "фреймворка" выделить самый такой ни на что не завязанный слой"
Удалить-- я такое пытался сделать.. :-( раз десять... три как минимум - для блога.. пока - не получилось.. :-(
> Есть у меня определённая "инсайдерская" информация :-)
УдалитьОго, какой поворот.. )
> DSL ведь имеет "миллион" применений. Вы в каком разрезе "к нему пришли"?
а) были мысли в разрезе локализации. Но, похоже, что там оно вовсе не нужно и даже излишнее усложнение получится
б) есть мысли в разрезе, так сказать, пользовательских скриптов. Когда пользователь сам формирует словарь, на основе которого в определённых точках вычисляются условия для ветвления... это пока очень обощённо. Может быть DSL тут тоже не нужен..
в) вообще мне это интересно для самообразования. "Чистый код" - к этому сам шёл, "шаблоны проектирования" - оказывается тоже их использовал, но не знал как это называется. Теперь вот приходит понимание, что абстрагироваться от кода (код можно и сгенерить) - тоже полезно.
Может стоит "про редактор" попытаться рассказать? Там много аспектов.. С кодом.. Правда он вряд ли будет компилируемым... Зато можно показать "приёмы проектирования"... Ну прям как GoF...
Удалитьмм.. Знаете, редактор - как пример, используется в этой книге: http://www.ozon.ru/context/detail/id/2457392/
УдалитьХотя, там конечно, не Delphi..
Вообще, просто вот почитать (в последнее время меня больше на лирику пробивает) Ваш путь, в том числе и о редакторе - это интересно. Как бы не закидали злыми комментариями ))
"были мысли в разрезе локализации. Но, похоже, что там оно вовсе не нужно и даже излишнее усложнение получится"
Удалить-- думаю - да. С "наскока" - излишне. Хотя у вас же используется PascalScript.
"есть мысли в разрезе, так сказать, пользовательских скриптов. Когда пользователь сам формирует словарь, на основе которого в определённых точках вычисляются условия для ветвления..."
-- это - да. По крайней мере мы так делаем. Более или менее удачно.
"вообще мне это интересно для самообразования. "Чистый код" - к этому сам шёл, "шаблоны проектирования" - оказывается тоже их использовал, но не знал как это называется. Теперь вот приходит понимание, что абстрагироваться от кода (код можно и сгенерить) - тоже полезно."
:-) далеко не все (пока) это понимают :-) к сожалению..
Этот комментарий был удален автором.
Удалить"Знаете, редактор - как пример, используется в этой книге: http://www.ozon.ru/context/detail/id/2457392/"
Удалить-- это GoF И есть. Gang of Four.
"Ваш путь, в том числе и о редакторе - это интересно."
-- ПУТЬ ("до") - ДЕЙСТВИТЕЛЬНО - СВОЙ. Хотя и в некоторых вещал и ПОВТОРЯЕТ GoF. Что мне краёне - ЛЕСТНО.
"Как бы не закидали злыми комментариями"
-- да уж.. "закидывателей" - хватает... что делать.. "интернеты"...
О как. "Банда четырёх" это и есть GoF? )) Посмеялся над собой ))
УдалитьЯ почему для себя не расшифровывал эти три буковки, и считал, что это некий стандарт, просто описывающий шаблоны (ну как справочник, без примеров)... ну т.е. вот есть книга, доступная и с примерами, а вот есть сухой такой GoF, как выжимка "банды"...
;-)
Удалить