:(
Я уж думал http://search.cpan.org/dist/Moose новый

на гнутом смолтолке работает?

и это в то время как ООП уже бъется в агонии...

Точно не знаю, но 99% что нет. Оно сделано на основе Pharo (всякие графы и пр. строятся в Morphic) и распространяется как сборка Pharo. Есть ещё что-то там для VisualWorks, но я не знаю, что =)

>http://www.moosetechnology.org этот ЛОР-эффект..

> Moose 4.0

под bolgenos пойдет?

да! но думаю пОпов этого не оценит!

Скоро в правила лора запишут «bolgenos» рядом с «банальный»

> Скоро в правила лора запишут «bolgenos» рядом с «банальный»

хотите сказать, что ваша аватара не стырена из интернета, как оформление в системе Попова, а вы ее сами сваяли?

Я тоже про перловый Moose подумал, а тут херь какая-то непонятного назначения.

Объясните Ъ: что это, как этим пользоваться?

А С++ оно поддерживает? Если нет, то не нужно.

Так уж и в агонии :)

все руки не доходили, посмотреть что за штука

очередная приблуда для разреба говнокода

> Скоро в правила лора запишут «bolgenos» рядом с «банальный»

И правильно сделают. Уже заколебало в каждой теме это слово видеть.

где скриншоты посмотреть?

в книге по ссылке будут скриншоты визуализаций

Судя по диалогу импорта поддерживает

> Скоро в правила лора запишут «bolgenos» рядом с «банальный»

И правильно сделают. Уже заколебало в каждой теме это слово видеть.

Тем кто сидит под мак осью не понять всех прелестей нижнетагильской ос.

«Не зли меня, Муууся!» (к)акой-то фильм :)))

> и это в то время как ООП уже бъется в агонии...

Бьются в агонии бездельники, не знающие, какую уже из 10 методологий применить! Профи продолжают писать на выбраном языке, вплоть до Си.

поставил, запустил, повисло на первом же диалоговом окне.

Хороший, годный вброс.

Скриншот

http://omploader.org/vNGh5NA

Это так у меня построилась диаграмма классов для Monticello.

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

>поставил, запустил, повисло на первом же диалоговом окне.

grustnoe (04.06.2010 11:54:27)

Ник смените, УМВР

>Так уж и в агонии :)

а то!

С продвижением F# даже вендовс платформа становится территорией с рабочей альтернативой ООП.

И, кстати, разбирать функциональные проекты по косточкам с помощью роботов куда как более полезное и благодарное дело...

>Бьются в агонии бездельники, не знающие, какую уже из 10 методологий применить! Профи продолжают писать на выбраном языке, вплоть до Си.

Есть только две методологии - императивная и функциональная и только одна из них верная.

Тот, кто нашел 10 методологий не бездельник, а безудержный фантазер...

>Есть только две методологии - императивная и функциональная и только одна из них верная.

Пять звезд, а так толсто.

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

Ну, это первое что попалось под руку, инструментов там по-больше доступно.

Покопаюсь поглубже как время будет, авось дельное применение и найду =]

Чем обзываться, просто назови третью...

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

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

Данная система позволяет оценить не то, что планировалось, а то, что получилось.

как бы «Муля, не нервируй меня».

>Чем обзываться

Я ещё не начинал =]

просто назови третью...

Третьего не дано (с) Просто как-то это не так, называть императивщину неверной

>Третьего не дано (с) Просто как-то это не так, называть императивщину неверной

Заметь, не я это сказал.

Императивщина рассово неполноценна. Вместе с тем, в тех случаях, когда чисто функциональный подход излишне громоздок, остается оператор do...

> Есть только две методологии - императивная и функциональная и только одна из них верная.

ООП не исключает ФП (OCaml, OO-Haskell...).

Впрочем, оно там скорее не очень-то и нужно...

> и это в то время как ООП уже бъется в агонии...

доооо, функциональный языки захватывают рынок.

>Есть только две методологии - императивная и функциональная и только одна из них верная.

Ларри со Стивом тебе сейчас весь телефон оборвут, будут звонить спрашивать, какая же методология правильная.

> С продвижением F# даже вендовс платформа становится территорией с рабочей альтернативой ООП.

Полный бред. Любая абстракция данных это уже ООП.

> Полный бред. Любая абстракция данных это уже ООП.

Вот что получается, когда в вузах начинают с изучения ООП: «Инкапсуляция, наследование, полиморфизм, абстракция!!!!!!!!!!!».

>Полный бред. Любая абстракция данных это уже ООП.

Даже добавить нечего. Действительно, полный бред.

В порядке ликбеза, не могли бы вы рассказать, как вообще можно написать алгоритм без абстракции данных? Или у нас в компах нынче литры и километры можно перелопачивать?

> ну тогда и отладчики и декомпиляторы не нужны. У большого проекта и так уже все отлажено.

разве?

Данная система позволяет оценить не то, что планировалось, а то, что получилось.

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

>разве?

сарказм

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

Все познается в сравнении. Без этого инструмента лучше не будет?

Я небольшой поклонник тупиковой ветки развития программерской мысли, коей является ООП, но уж визуализировать дерево объектов должно быть можно и небесполезно.

>> такая «механическая» диаграмма даже для поверхностного рефакторинга не особо полезна. или я не прав?

визуализировать дерево объектов должно быть можно и небесполезно.

ясно, т.е., это такие же самостоятельные догадки, как и мои слова.

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

сам же я пока предполагаю, что будет полезнее самому смотреть код в навигаторе (с гиперссылками, конечно, кои есть в любой нормальной IDE) и, максимум, в полуавтоматическом режиме выдёргивать названия значимых классов в отдельную схемку (или даже на бумажке в клеточку рисовать).

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

> тупиковой ветки развития программерской мысли, коей является ООП

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

Интересно, в чем оно для Java будет лучше http://www.jetbrains.com/idea/features/uml_class_diagram.html

Оно ж платное?

А что, цена - это единственный критерий при выборе инструмента?

Да и для серьезных open source проектов JetBrains раздает бесплатные лицензии.