Здравствуйте, Пономарёв Иван, Вы писали:
ПИ>1. Про общий вопрос про перспективы языков он говорит, что сейчас требуется разработать язык, в синтаксис которого был бы изящно встроен параллелизм. Причем критерием достижения этой цели он считает лёгкость обучения студентов. Т. е. это должен быть такой язык с параллелизмом в синтаксисе, которому было бы легко обучать.
ПИ>2. Я спросил его, а не нужен ли в таком случае язык, в синтаксис которого были бы изящно встроены идеи паттернов проектирования. Он сказал, что не является специалистом по паттернам проектирования, но знает, что некоторые люди принимают их, а некоторые -- не принимают. Посему он смотрит на паттерны как на новшество, которое его пока не заботит. Говоря вообще, он -- скорее за свободу для программиста, чем за какие-то предопределенные "паттерны".
Похоже, он просто не понимает, что такое "паттерн"
ПИ>3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"
Здравствуйте, Трурль, Вы писали:
Д>>Что такое UML, он тоже не понимает. Мдя. Грустно Т>Похоже, он понимает это гораздо лучше, чем многие другие.
Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) наблюдал какую-то странную шаблонизированность мышления у поклонников этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие программисты умели это всё и до появления этого суржик-лексикона.
Что до UML — я как-то не видел ни одного доводу в пользу его удобства. Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны. У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того.
Здравствуйте, Zdreni, Вы писали:
Z>Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) наблюдал какую-то странную шаблонизированность мышления у поклонников этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие программисты умели это всё и до появления этого суржик-лексикона.
если уж сказал "а", скажи заодно и "б".
и кто вообще сказал, что "шаблонизированность" — это плохо?
Z>Что до UML — я как-то не видел ни одного доводу в пользу его удобства.
Значит, понимание у тебя еще впереди.
Z>Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны.
Rational != UML
Z>У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того.
Для этой цели он тоже подходит. Хотя лично я использую его в других целях.
Здравствуйте, Трурль, Вы писали:
Т>Похоже, он понимает это гораздо лучше, чем многие другие.
Если он объединяет UML и блок-схемы по тому принципу, что и то и другое — это диаграммы, то тут он безусловно прав
надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Zdreni wrote:
> Д>>Что такое UML, он тоже не понимает. Мдя. Грустно > Т>Похоже, он понимает это гораздо лучше, чем многие другие. > Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) > наблюдал какую-то странную шаблонизированность мышления у поклонников > этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие > программисты умели это всё и до появления этого суржик-лексикона.
"Суржик-лексикон" позволяет говорить "синглтон", а не "объект,
существующий в единственном экземпляре"; "фасад", а не "объект,
проедоставляющий удобный для использования объектный интерфейс для
какой-то другой системы" и т.п.
> Что до UML — я как-то не видел ни одного доводу в пользу его удобства. > Уже не говоря о том, что продукты Rational сами по себе подчёркнуто > неудобны.
А причем здесь Rational? Или у вас UML==Rational?
> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать > начальству, чтоб оно видело, что работа кипит. И не более того.
Здравствуйте, Дарней, Вы писали:
Д>надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Судя по тому снисходительно-ироническому тону, с которым здесь в последнее время говорят про Вирта, вероятно, так оно и есть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >> начальству, чтоб оно видело, что работа кипит. И не более того.
C>Ну и вы не понимаете что такое UML....
Здравствуйте, eao197, Вы писали:
E>Судя по тому снисходительно-ироническому тону, с которым здесь в последнее время говорят про Вирта, вероятно, так оно и есть.
Не знаю, что думают остальные.
Я не считаю нужным соглашаться с кем-то только потому, что он — авторитет. А некоторые его высказывания выглядят так, будто их сделал человек, который не видит ни на сантиметр дальше собственного носа. Более того — не хочет видеть, и не считает это нужным. Вот собственно и всё.
ironwit wrote:
>>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >>> начальству, чтоб оно видело, что работа кипит. И не более того. > C>Ну и вы не понимаете что такое UML.... > Расскажите?
Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших
систем, так как UML — это единый графический язык описания структур и их
взаимодействий.
UML — не серебряная пуля, конечно, но очень удобен так как его понимают
все. Примерно та же ситуация, что и с XML
Здравствуйте, Cyberax, Вы писали:
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
не только при создании. Очень удобен, чтобы быстро составить представление о структуре незнакомой системы, например. Правда, тут всё упирается в убогость существующих UML-систем. Если построить диаграммы из кода Java или C# еще можно более-менее нормально, то ситуация с С++ — это просто тихий ужас
Здравствуйте, Cyberax, Вы писали:
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
не только при создании. Очень удобен, чтобы быстро составить представление о структуре незнакомой системы, например. Правда, тут всё упирается в убогость существующих UML-систем. Если построить диаграммы из кода Java или C# еще можно более-менее нормально, то ситуация с С++ — это просто тихий ужас
Здравствуйте, Cyberax, Вы писали:
C>ironwit wrote:
>>>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >>>> начальству, чтоб оно видело, что работа кипит. И не более того. >> C>Ну и вы не понимаете что такое UML.... >> Расскажите?
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
C>UML — не серебряная пуля, конечно, но очень удобен так как его понимают C>все. Примерно та же ситуация, что и с XML
можно ли какой то маленький пример большой системы и конкретный пример ее облегчение проектирования\разработки?
Дарней wrote:
> C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших > C>систем, так как UML — это единый графический язык описания структур > и их > C>взаимодействий. > не только при создании. Очень удобен, чтобы быстро составить > представление о структуре незнакомой системы, например. Правда, тут > всё упирается в убогость существующих UML-систем. Если построить > диаграммы из кода Java или C# еще можно более-менее нормально, то > ситуация с С++ — это просто тихий ужас
Ага, да и сами по себе диаграммы из кода тоже не очень-то удобны (хотя
иногда полезны).
Поэтому мы используем UML для описания разделения системы на модули и их
взаимодействия. В реализациях модулей UML используется только в
документации для иллюстрации каких-нибудь сложных по структуре подсистем.
ironwit wrote:
> C>UML — не серебряная пуля, конечно, но очень удобен так как его понимают > C>все. Примерно та же ситуация, что и с XML > можно ли какой то маленький пример большой системы и конкретный пример > ее облегчение проектирования\разработки?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Похоже, он понимает это гораздо лучше, чем многие другие.
Д>Если он объединяет UML и блок-схемы по тому принципу, что и то и другое — это диаграммы, то тут он безусловно прав
Собственно так и есть. Это вообще свойственный для него подход — обобщать и классифицировать по поверхностным признакам. Потому у него и произведения получаются столь же поверхностными — что Паскаль, что Оберон. Вроде как всё есть, а при этом какое то оно всё не как у людей. Как до практики доходит, так начинаются всякие хаки как в турбо-паскале или системных библиотеках.
Д>надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Здравствуйте, Дарней, Вы писали:
Д>Не знаю, что думают остальные. Д>Я не считаю нужным соглашаться с кем-то только потому, что он — авторитет.
Соглашаться не обязательно. Но, имхо, принимать к сведению его мнение все же стоит. Как раз на основании того, что он -- авторитет. Ведь авторитетами становятся как раз те, кто что-то замечает чуть-чуть раньше, чем все остальные. Либо вообще говорит что-то, о чем другие раньше не задумывались. Либо делает то, что другим кажется невозможным.
Может быть и сейчас такая же ситуация? Есть мейнстрим. Есть масса зашоренных этим мейнстримом людей. Когда движешься в толпе, то не видишь дальше затылков нескольких впереди идущих попутчиков. В таком движении можно даже не заметить извилистости пути, поскольку весь путь -- это непрерывная последовательность мелких шажков вперед. Только в стороне от потока можно составить более полную картину происходящего.
Вот Вирт, имхо, как раз в стороне и находится. И у него есть возможность замечать то, с чем нам придется столкнуться чуть позже. Конечно же, Вирт может сильно заблуждаться в отношении того, _как должно быть_. Но вот то, _что-то не так_ он наверняка видит лучше многих из нас. Я бы даже сказал лучше подавляющего большинства из нас. Может быть даже гораздо лучше подавляющего большинства из нас.
Д> А некоторые его высказывания выглядят так, будто их сделал человек, который не видит ни на сантиметр дальше собственного носа. Более того — не хочет видеть, и не считает это нужным.
Не уверен, что мы можем себе хотя бы вообразить тот поток информации, с которым сталкивается Вирт. Позволю себе привести цитату из Страуструпа, но думаю, что она в тему:
It is common to hear generalizations along the line “C++ is used like this”. Such statements are typically wishful thinking based on very limited experience. We are playing “blind men and the elephant” with a very large creature. There are people who have read more than a million lines of C++ code, written hundred of thousands of lines of C++, read all the articles in C-vu, C/C++ Users Journal, etc., read all the good C++ books and dozens of the bad ones, read all the academic papers relating to C++, and “lived” on the C++ newsgroups for years. There are not many such people, and even they have only scratched the surface.
(предисловие к японскому изданию книги "Дизайн и эволюция языка C++").
Имхо, аналогичные слова можно отнести и к разработанным Виртом языкам. И уж если кто-то и может себе составить более-менее объективную картину использования Pascal-производных языков, так это сам Вирт. Поскольку к нему стекается информация о проблемах языка в одних предметных областях, о достоинствах в других, о пожеланиях в третьих и т.д., и т.п. Но объем этой информации должен быть просто огромен. Поэтому я думаю, что возможностей видеть намного дальше своего носа у Вирта предостаточно.
Проблема Вирта (если вообще уместно об этом говорить), имхо, состоит в том, что тот вектор развития, который пытается указать Вирт, не совпадает с тем направлением, в котором нам бы хотелось пойти. Но важно другое -- то, что Вирт говорит, что двигаться в прежнем направлении не правильно, нужно по-другому. И лично я склонен предполагать, что так оно и есть. Только, в отличии от меня, Вирт хоть какое-то направление может предложить. Более того, это направление вполне работоспособно (давайте вспомним успешность Паскаля и то, что Оберон даже сейчас применяется в реальных и весьма важных проектах).
Вот ты говоришь:
ПИ>3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"
Что такое UML, он тоже не понимает. Мдя. Грустно
А что, если Вирт прав? Предположим, что история развивается-таки по спирали. В конце семидесятых годов применяли блок-схемы для описания программных систем. И этот подход был оправдан до тех пор, пока сама сложность систем позволяла делать такие блок-схемные описания. Сложность выросла -- блок-схемы стали историей. Прошло время. Махровым цветом расцвело ООП, которое чуть облегчено создание современного ПО. Появилась еще одна, чуть более продвинутая графическая нотация -- UML. И оказалось, что сложность разрабатываемых сейчас систем допускает их описание с помощью данной нотации. Это именно та точка, на которой мы находимся сейчас. Так вот, имхо, Вирт говорит: "Еще чуть-чуть и сложность задач возрастет настолько, что UML уже не в состоянии будет их описывать. Поэтому с UML произойдет то же самое, что с блок-схемами". Лично я не сомневаюсь, что сложность ПО будет только возрастать. И поэтому я вполне могу согласиться с предположением Вирта о будущем UML.
Я бы добавил еще немного от себя. Время от времени в разработке ПО происходят прорывы, которые становятся знаковой вехой и которые не утрачивают своей актуальности с течением времени. Ассемблер. Языки высокого уровня, процедурное программирование. Структурное и модульное программирование. Объектно-ориентированное программирование. Так вот, имхо, UML совсем не из их числа. Просто потому, что все перечисленные мной вехи способствовали повышению производительности программиста. UML, имхо, к этому никакого отношения не имеет -- это всего лишь язык записи уже сгенерированных идей. Но самому процессу генерации идей он никак не способствует. Не открывает новых горизонтов, не расширяет сознания. Это просто инструмент. А у любого инструмента есть свой срок эксплуатации. Вот и все.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>если уж сказал "а", скажи заодно и "б". Д>и кто вообще сказал, что "шаблонизированность" — это плохо?
Я видел случаи, когда это очень плохо. Человек (в должности тим лида, кстати) выдавал такие предложения из области "паттернов", что волосы дыбом вставали. "Нет, мы не будем использовать smart pointers, я в них не очень разбираюсь, мы нагромоздим тут менеджер таких обьектов и менеджер таким, и навернём десяток интерфейсов для визиторов и пр.".
Z>>Что до UML — я как-то не видел ни одного доводу в пользу его удобства. Д>Значит, понимание у тебя еще впереди.
Например, сколько не программировал, но понимания "преимущества блок-схем" так и не появилось — наоборот, появилось понимание того, что это нежизнеспособная концепция. Почему с UML должно быть по-другому?
Z>>Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны. Д>Rational != UML
Да, но разве не Rational его продвигает пуще всех? И разве не в Rational работает собственно изобретатель этого самого RUP?
Я думал, что Rose — это и есть первоочередной продукт для UML. Мои коллеги пользовались также Visio, но это не сильно изменило моего мнения о UML.
Z>>У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того. Д>Для этой цели он тоже подходит. Хотя лично я использую его в других целях.
Не знаю, я обычно пользуюсь plain-text описаниями ролей классов и принципов их функционирования. Этого достаточно, причём можно не расписывать каждый метод. Достаточно написать, что "такой-то класс является менеджером таких-то обьектов", и всё становится куда понятнее, чем простое перечисление методов, интерфейсов и т.д..
Здравствуйте, Cyberax, Вы писали:
C>"Суржик-лексикон" позволяет говорить "синглтон", а не "объект, C>существующий в единственном экземпляре";
Ну, положим, "синглетон" существовал ещё до появления той книги.
C>"фасад", а не "объект, C>проедоставляющий удобный для использования объектный интерфейс для C>какой-то другой системы" и т.п.
А что, трудно написать "менеджер" или "переходник" (последнее — для бриджа)?
А сколько по-сути однотипных применений для "ОО-коллбека" предоставлено в книге под видом разных шаблонов — я был немало удивлён. Interpreter, Iterator, Strategy, Visitor... И везде — читаешь книжку — прям-таки Америку открывают, хотя идеи-то простые и уже использовались до того.
Кроме того, эти шаблоны не учитывают, например, специфику С++ из разряда той, которую использовал Александреску — с шаблонными шаблонными параметрами, передачей стратегий и т.д. В результате горе-проектировщики, обчитавшиеся таких книжек, дальше интерфейсов ничего не видят и громоздят что попало. Я такое видел.
C>А причем здесь Rational? Или у вас UML==Rational?
В предыдущем сообщении ответил. Rational — основные "продвигатели" UML, AFAIK.
>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >> начальству, чтоб оно видело, что работа кипит. И не более того. C>Ну и вы не понимаете что такое UML....
Видите ли... текст я набираю явно быстрее, чем возюкаю мышой в любом из UML-пейнтов. И мне проще текстом обьяснить и себе, и другим, что конкретно требуется от каких классов. Это во-первых.
Кроме того, plain text отлично обрабатывается системой контроля версий — лучше, чем бинарные форматы с диаграмками. Кроме того, по plain text лучше работает поиск. Кроме того, в plain text лучше видно, как согласовывался и менялся дизайн. Единственное, для чего plain text хуже — как я и сказал, это в демонстрации начальству "кипучести работы".
Может, я чего-то действительно не понимаю — ну так обьясните.
Ну а что -- их швейцарский институт явно же может позволить себе решать те задачи, которые им нравятся 
Хотя лично я использую его в других целях.
