Common Lisp и UML.

UML для CL не нужен, т.к.:

1. методов у классов CL нет, то есть генерировать на оснвое диаграмм нечего

2. классы могут меняться в рантайме, что в EVL показать нельзя

3. и вообще, UML - слишком бедная и примитивная нотация, расчитанная на «классическое» ООП со всеми его недостатками, в применении к CLOS она слишком невыразительна.

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

> UML - слишком бедная и примитивная нотация, расчитанная на «классическое» ООП со всеми его недостатками, в применении к CLOS она слишком невыразительна.

А что тогда выразительно, в применении к CLOS?

> методов у классов CL нет, то есть генерировать на оснвое диаграмм нечего

дай угадаю, полей у классов CL тоже нет? и вообще они не классы вовсе?

дай угадаю, полей у классов CL тоже нет? и вообще они не классы вовсе?

Угадал. Тебе же сказали:

2. классы могут меняться в рантайме, что в EVL показать нельзя

С помощью MOP можно ещё не такое наворотить.

> А что тогда выразительно, в применении к CLOS?

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

Да ладно, в жабке тоже рисовать не нужно.

ИМХО, для CL больше подойдет IDEF0, а не UML. Хотя IDEF тоже не нужен.

> Исходный код.

Я так надеялся, что никто не спорет эту чушь. Ну хотя бы на первой странице. Искренне надеялся. Именно поэтому не стал писать в самом топике «пожалуйста, изучите UML, прежде чем вбрасывать мимо кассы», мне показалось, что это будет неуважительным по отношению к публике. Выходит, всё-таки стоило бы...

Вы только что показали, что совершенно не знакомы со стандартом UML. Это не вы ли в соседнем топике облажались, назвав нефункциональные требования «маркетоидными баззвордами»? Не удивлюсь если вы...

Впрочем, если вы утверждаете, что знакомы с UML, то не соизволите ли ответить на следующий вопрос. Как вы предполагаете по исходному коду восстановить:

• схему взаимодействий десятков акторов (sequence diagram и collaboration diagram)?
• декомпозицию на компоненты (component diagram)?
• размещение компонентов (deployment diagram)?
• возможные состояния объектов и допустимые переходы между ними (statechart diagram)?
• наконец, варианты использования системы (use case diagram)?

Спасибо за ответ.

> Да ладно, в жабке тоже рисовать не нужно.

Ну, с вами мы вроде всё выяснили в предыдущем топике, можете не повторяться - вы каменщик, максимум прораб, но никак не Архитектор ;) но тем не менее предыдущий ответ адресован и вам тоже, может что интересное в голову придёт.

А я вам еще раз повторю, что вы уделяете массу внимания вещам настолько тривиальным, что они проще написания логики и их можно доверить даже юниорам.

> вы уделяете массу внимания вещам настолько тривиальным

Например? Каким именно?

> Впрочем, если вы утверждаете, что знакомы с UML, то не соизволите ли ответить на следующий вопрос. Как вы предполагаете по исходному коду восстановить:

Речь шла о диаграммах классов (или по чему вы собрались «скелетные классы» генерить?). Другие диаграммы, те же юз-кейсы, вообще отношения к программированию не имеют, можете их рисовать хоть для моделирования шоколадки «марс». Вообще, диаграммы классов тоже можно нарисовать для CL - но это вредно в данном случае. Обычно вы когда диаграммы классов нарисовали, то сразу по ним можете восстановить классы в исходном коде (даже автоматически), в CL же вам придется эти диаграммы переводить на язык CLOS. Проще будет сразу написать в CLOS, чем этим заниматься.

>Другие диаграммы, те же юз-кейсы, вообще отношения к программированию не имеют

В цитатник! Для толстого троллинга нетипичных лисперов «типичным» лиспером.

> Архитектор

Я таки продолжают утверждать, что он тролль.

>Ну, с вами мы вроде всё выяснили в предыдущем топике, можете не повторяться - вы каменщик, максимум прораб, но никак не Архитектор ;) но тем не менее предыдущий ответ адресован и вам тоже, может что интересное в голову придёт.

Ну, чувак, нельзя в каждой теме троллить одним и тем же образом да еще и на одну и ту же тему. too obvious

> Речь шла о диаграммах классов (или по чему вы собрались «скелетные классы» генерить?)

Слово «например» видели?

Другие диаграммы, те же юз-кейсы, вообще отношения к программированию не имеют

Правильно. Они имеют отношение к моделированию, проектированию, документации и архитектуре. Что не так?

Обычно вы когда диаграммы классов нарисовали, то сразу по ним можете восстановить классы в исходном коде (даже автоматически), в CL же вам придется эти диаграммы переводить на язык CLOS.

Почему? Для какой-то Java можно, а для CLOS - нет? В нормальном инструменте поддержка конкретного языка - это дело наличия соответствующих шаблонов и скриптов. Собственно, в этом топике я и пытался узнать, может у кого есть готовые шаблоны для какого-нибудь конкретного инструмента, например Rational Rose.

> Я таки продолжают утверждать, что он тролль.

Да ну скорее просто молодой и неопытный :) Я когда писал диплом то тоже держал в голове все пятнадцать сущностей... подозреваю, что у юноши задачки тоже такого же масштаба... но ничего, всё ещё впереди :)

Если вы не поняли, я пытаюсь исследовать вопрос применения CL+CLOS в промышленном программировании. Что тут странного, что возникает много вопросов на смежные темы? А если вас это почему-то задевает... ну не знаю, извините

> Почему? Для какой-то Java можно, а для CLOS - нет?

Потому что семантически диаграмма классов повторяет ООП java, там ничего переводить не надо, по сути, т.к. сущности диаграммы классов напрямую отображаются на сущности программы. У CLOS совершенно иная семантика, так что задача становится сравнимой с переводом с одного языка на другой.

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

Угу, если семантика ЯП ложится на семантику этого «инструмента». В случая CLOS - не ложится, вообще никак. Проще будет переделать ООП в CL, чем заниматься таким переводом. И это, опять же, мы уже не учитываем динамичности CLOS и CL в целом, которую в рамках UML нереально выразить. В CL ранатйм - система, которая динамически меняет свое поведение, UML для выражения подобных вещей не предназначен, он предназначен для моделирования систем с устойчивым поведением. Нет, можно, конечно, и штаны через голову надеть - но зачем?

>Да ну скорее просто молодой и неопытный :) Я когда писал диплом то тоже держал в голове все пятнадцать сущностей... подозреваю, что у юноши задачки тоже такого же масштаба... но ничего, всё ещё впереди :)

Если ты не понял, то троллем назвали тебя.

>Если вы не поняли, я пытаюсь исследовать вопрос применения CL+CLOS в промышленном программировании. Что тут странного, что возникает много вопросов на смежные темы? А если вас это почему-то задевает... ну не знаю, извините

Дело не в общей тематике твоих тем, а в том что и как ты спрашиваешь и как реагируешь на ответы.

Ты уже в который раз применяешь ту же тролльскую схему.

> для моделирования систем с устойчивым поведением

воистину, никто не обосрет лисп круче, чем сами лисперы

Ты эти вопросы не в том месте задаешь (если, конечно, ты реально интересуешься, а не троллишь). Задавать нужно на каком-нибудь зарубежном форуме, где тусуются лисперы. Там уж точно опытнее люди будут.

Я таки продолжают утверждать, что он тролль.

вряд ли. скорей недавний студент с комплексом неполноценности, помноженном на попадание в enterprise-среду

Спасибо, наконец-то единственный ответ по-существу. Теперь многие вещи встали на свои места. К вам тогда ещё вопрос как к специалисту...

В CL ранатйм - система, которая динамически меняет свое поведение, UML для выражения подобных вещей не предназначен, он предназначен для моделирования систем с устойчивым поведением.

Если я правильно понимаю, то ничто не помешает программисту Васе из соседнего отдела в рантайме удалить или изменить метод/класс/функцию из моего когда или библиотеки. Таким образом система может повести себя непредсказуемо, или хотя бы вразрез с тем, что написано в документации или проектных материалах. Причём узнаю я об этом только когда система вывалится в рантайме, или клиент узнает об этом по пропаже денег с его лицевого счёта, или мы не узнаем вообще. Сомнительное достоинство, не находите ли?

Поэтому хочу спросить как специалиста. Для каких задач вы считаете оправданным применение «неустойчивой» системы наподобие CLOS? Когда вы однозначно предпочтёте динамику «устойчивому поведению»? Спрашиваю не из праздного интереса, мне скоро предстоит обосновывать применимость Common Lisp перед техническим комитетом

> Если ты не понял, то троллем назвали тебя.

Заговорил о применении CL на практике - сразу тролль? Хорошо хоть сумасшедшим не обзывают :)

Дело не в общей тематике твоих тем, а в том что и как ты спрашиваешь и как реагируешь на ответы.

Что я спрашиваю не так? Потрудитесь привести примеры? А то может я и вправду был невежлив где-то, и сам того не заметил, обидел кого-нибудь

> Задавать нужно на каком-нибудь зарубежном форуме, где тусуются лисперы. Там уж точно опытнее люди будут.

Я пробовал. Зарубежное коммьюнити очень агрессивно и недружелюбно. Такое впечатление что они там живут в каком-то уютном розовом мирке из анафоричечских лямбд и аппликативных функторов, а попытку применить лисп на практике воспринимают как личное оскорбление. До сих пор самым информативным для меня был и остаётся ЛОР. Тут конечно тоже много яйцеголовой братвы с зигохистоморфными параморфизмами, но и практики попадаются, как ни странно.

Например, только здесь Love5an и ещё один анонимус разжевали мне вопрос загрузки больших массивов в память, за что им большое спасибо, а на остальных ресурсах был сразу послан «обратно в уютную сишечку»

Слушайте, если есть что по существу, то выкладывайте... если по-существу нечего сказать - лучше проходите мимо, может сойдёте за воспитанного человека...

Или вас задевает то, что я не стесняюсь открыто говорить о проблемах и неоднозначностях лиспа? Тогда лучше признаться в этом, причём в первую очередь себе, легче станет... зачем хамить-то?

задевает то, что я не стесняюсь

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

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

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

Но и вы свою очередь воздержитесь от необоснованных выводах о возрасте и квалификации человека, с которым вы не знакомы.

Эммм. Что-то я не понял. Вопрос вроде для серьезного использования, а тот факт что по сути CL - динамически типизированный язык (со всеми вытекающими) узнаете только сейчас. Может не надо строить решения на языке который не знаете?

> тот факт что по сути CL - динамически типизированный язык (со всеми вытекающими) узнаете только сейчас

С чего вы это взяли? И потом, я бы хотел услышать не рекомендации по применению или неприменению (это я всё-таки буду решать сам, с позволения). А ответ по существу на вопрос, который я озвучил выше: о задачах, в которых применение динамического языка 100% оправданно. Если есть соображения, то выслушаю и скажу «спасибо»

>С чего вы это взяли

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

не рекомендации по применению или неприменению

Да что вы, я просто некоторое недоумение выражаю.

А генерить код из UML я считаю очень непродуктивным занятеим (но не моделирование на UML). Если строить модели на уровне абстракций исходного кода - то текст программы и читать и писать удобнее. А для того, что находится на уровень абстракций выше - универсального генератора не существует, все зависит от задачи. Так что общие соображения - да, можно - UML не привязан к языку, но вот кодогенерации его я бы не рекомендовал пользоваться ни для какого языка (для которых вроде и генераторов дофига).

>о задачах, в которых применение динамического языка 100% оправданно.

Задача: cделать прототип быстро.

> Так что общие соображения - да, можно - UML не привязан к языку, но вот кодогенерации его я бы не рекомендовал пользоваться ни для какого языка (для которых вроде и генераторов дофига).

Не факт, для той же Java бывает очень удобно сгенерировать маппинг для ORM, кучу всяких DAO, TO и session facade-ов

>Java бывает очень удобно сгенерировать маппинг для ORM, кучу всяких DAO, TO

Удобнее возить мышкой и кликать по формочкам чем писать текст? о_О Да и у UML нет нормальных средств что бы _полностью_ выразить сколько-то сложные конструкции «реального» мира. Так что удобно разве что в теории и на несложных примерах. Атрибуты к атрибутам он не умеет, стереотипами сыт не будешь.

>о задачах, в которых применение динамического языка 100% оправданно.

Задача: cделать прототип быстро.

То что динамика тут выигрывает - скорее распространенное заблуждение. Тут вопрос не в динамичности языка да и вообще не в языке в первую очередь, а в фреймворке/библиотеке которая используется, ну и во-вторых в локаничности языка. И то и то прекрасно реализуется в статических языках.

>ну и во-вторых в локаничности языка

а лаконичность это разве не следствие динамичности?

> Если я правильно понимаю, то ничто не помешает программисту Васе из соседнего отдела в рантайме удалить или изменить метод/класс/функцию из моего когда или библиотеки.

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

В общем любые динамические изменения можно динамически же и запретить.

Когда вы однозначно предпочтёте динамику «устойчивому поведению»?

CL не завязан на чисто динамическое поведение. В нем одновременно присутвует и статика и динамика и контролируемая неустойчиваость.

мне скоро предстоит обосновывать применимость Common Lisp перед техническим комитетом

Стесняюсь спросить, но насколько вы знаете матчасть CL что бы обосновывать применимость перед кем-либо?

> Сомнительное достоинство, не находите ли?

Программист Вася из соседнего отдела может точно так же взять и изменить исходники в любом %langname%.

Для каких задач вы считаете оправданным применение «неустойчивой» системы наподобие CLOS?

Вас, на самом деле, никто менять классы в рантайме силой не заставляет, просто присутствует такая возможность и вы ее можете применить, если вдруг окажется, что это в данном случае удобно. А можете не применять. Собственно, в 90% случаях оно и не применяется, разве что если задача какая-то нетривиальная.

> А ответ по существу на вопрос, который я озвучил выше: о задачах, в которых применение динамического языка 100% оправданно.

Оно оправдано в тех же задачах, в которых оправдано применение статически типизированного языка. Кроме систем с зависимыми типами, разве что.

> И то и то прекрасно реализуется в статических языках.

Зато человеческий репл и инкрементальная разработка не реализуются.

>инкрементальная разработка не реализуются.

Инкрементальная разработка (итеративная разработка)? Какое оно вообще имеет к языку отношение?

Зато человеческий репл не реализуются.

Это почему? У того же хаскела репл вполне присутствует.

>а лаконичность это разве не следствие динамичности?

Вы путатете импликацию с эквиваленцией :) Следствие, но не необходимое требование. Статика при определенных обстоятельствах может быть локаничнее (например, не надо как в питоне self писать постоянно, хотя это врядли реально снижает производительность программиста). Хороший type inference позволит избежать постоянного определения типов. Кстати, тот же duck typing почему то все считают, что существует только с динамике, однако он прекрасно работает в статическом OCaml.

Нашли что сравнивать - питон с коммон лиспом. Очень разные вещи. Например, в коммон лиспе есть опциональная статическая типизация, которой я пользуюсь. я уж не говорю о макросах или репл.

>Нашли что сравнивать - питон с коммон лиспом.

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

Что вы кстати так к репл то привязались? Вон в питоне тоже репл есть. И для многих языков он есть. И вообще к языку он отношения не имеет - это инструмент.

>опциональная статическая типизация

Кстати, заодно расскажите про статическую типизацию в _коммон лиспе_, которая именно статическая типизация а не хинты JIT-у.

На sbcl и ccl нормально работает (я под виндоус использую). В основном использую sbcl, но иногда ccl. Ловлю так ошибки типизации.

Ну, например, сходу

INSTALLATION> (defun foo (x) (declare ((or null integer) x)) x) FOO INSTALLATION> (foo nil) NIL INSTALLATION> (foo 3) 3 INSTALLATION> (foo 3.5)

The value 3.5 is not of type (OR NULL INTEGER). [Condition of type TYPE-ERROR]

Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*PROCESS-INPUT] Continue reading input. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection. 4: [ABORT] Exit debugger, returning to top level.

Backtrace: 0: (FOO 3.5)[:EXTERNAL] 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO 3.5) #<NULL-LEXENV>) 2: (EVAL (FOO 3.5)) --more--

которая именно статическая типизация а не хинты JIT-у.

чего-чего? какому нахрен JIT-у?

CL-USER> (defun add (a b)
           (declare (fixnum a b)
                    (optimize speed (debug 0) (safety 0)))
           (the fixnum (+ a b)))
ADD
CL-USER> (compile 'add)
ADD
NIL
NIL
CL-USER> (disassemble 'add)
200AB2DA:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      8B7D08           move  edi, [ebp+8]
       6:      03C7             add   eax, edi
       8:      FD               std   
       9:      C9               leave 
      10:      C20400           ret   4
      13:      90               nop   
NIL
CL-USER> (add 3 4)
7
CL-USER> 

На sbcl и ccl нормально работает (я под виндоус использую). В основном использую sbcl, но иногда ccl. Ловлю так ошибки типизации.

Ну, например, сходу

INSTALLATION> (defun foo (x) (declare ((or null integer) x)) x)

FOO

INSTALLATION> (foo nil)

NIL

INSTALLATION> (foo 3)

3

INSTALLATION> (foo 3.5)

The value 3.5 is not of type (OR NULL INTEGER). [Condition of type TYPE-ERROR]

Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*PROCESS-INPUT] Continue reading input. 2: [ABORT] Return to SLIME's top level. 3: [CLOSE-CONNECTION] Close SLIME connection. 4: [ABORT] Exit debugger, returning to top level.

Backtrace: 0: (FOO 3.5)[:EXTERNAL] 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO 3.5) #<NULL-LEXENV>) 2: (EVAL (FOO 3.5)) --more--