Процедурное программирование vs Объектное

[Tango]

Вопрос несколько холиварный, но всё же.
Есть проект http://www.freepascal.ru/forum/viewtopic.php?f=10&t=9517, в рунтайм рождаются и умирают формы, живут, принимают события, сами их рождают, в общем так.
Написан процедурным стилем, объектные вещи добавлены туда были уже недавно.
Появилась тяга переписать всё на объекты, а имеет ли смысл? Максимум что получу, какую-то более структурированность и всё. Или не так?

[MiniQ]

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

[Лекс Айрин]

Есть задачи где ООП излишне, а вот процедурное программирование очень даже в тему.

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

[Vapaamies]

Советчики, млин. Кто из вас исходники смотрел?

Мне кажется, что портянку под названием uDCL стоит отрефакторить в любом случае, разбив на какие-то логические элементы. Модули по 700 КБ при разработке одним человеком -- очень редкое исключение. В компаниях -- да, там есть чьим глазам за кодом следить.

Всё сказанное справедливо только в том случае, если планируется дальнейшее развитие и выпуск новой мажорной версии. В этом я согласен с коллегой MiniQ.

агентно-ориентированный подход.

Агентно-ориентированные языки не подскажете?

[Лекс Айрин]

Советчики, млин. Кто из вас исходники смотрел?

Вопрос, как я понял, скорее теоретический.

Агентно-ориентированные языки не подскажете?

Сам бы хотел действующую среду программирования такого типа увидеть. Собственно АОП, насколько я знаю, это скорее особенность не языка, а библиотек объектов.

А давай сами напишем? Там изменения, по сравнению с объектным паскалем, не такие уж и большие.

Убрать директивы типа Virtual, Protected ets... а вместо них ввести потоки и директиву own. Добавить класс типа процесс.

[Mikhail]

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

ИМХО то что сейчас называют ООП, часто им не является. Применение object или class не делает код ОО. И еще, считаю что ООП ограниченно применим.

[Vapaamies]

Вопрос, как я понял, скорее теоретический.

Опытный разработчик обычно отличается осведомленностью о частичной применимости теорий, поэтому стремится получить как можно больше контекста. Автором темы был задан конкретный вопрос по конкретному проекту, была дана ссылка на публичный репозитарий.

Собственно АОП, насколько я знаю, это скорее особенность не языка, а библиотек объектов.

Вот и не надо подменять тему. Появятся языки -- можно будет ставить их в один ряд. А пока нефиг.

Убрать директивы типа Virtual, Protected ets...

Да-да, все с этого начинают. Аппетит приходит во время еды... Язык должен быть самобытным, чтобы был хотя бы теоретический смысл его изучать и пользовать. Поэтому сомневаюсь, что удастся просто так взять и поменять Паскаль и получить результат. Менять придется сложно.

ИМХО то что сейчас называют ООП, часто им не является. Применение object или class не делает код ОО. И еще, считаю что ООП ограниченно применим.

ППКС. Для неограниченного применения ООП нужен язык с принудительной реализацией SOLID.

[Лекс Айрин]

Появятся языки -- можно будет ставить их в один ряд. А пока нефиг.

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

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

Не совсем просто, но список изменений не какой уж и большой. По крайней мере полученный язык имхо окажется проще в использовании, но чуть сложнее в реализации. И как раз операторы самого Паскаля трогать не обязательно. Только часть добавленную в объектном Паскале. В принципе, я уже просчитал большую часть изменений.

ИМХО то что сейчас называют ООП, часто им не является.

Подпишусь.

[Tango]

Про object и class: без них не обойтись было, это для назначения событий.
Переписывать всё это, я уже пытался, получалось тупиковые ветви. Сейчас выбрана стратегия сверху вниз (циклично), переписывания от мелкого к крупному, а не наоборот, когда рубится корень и всё что было выше падает.
Буду потихоньку спускаться вниз, как дойду до низа, поднимусь и опять вниз с другой абстракцией, других объектов. Так я считаю, самое неразгромное решение.

[Vapaamies]

По крайней мере полученный язык имхо окажется проще в использовании

Что бывает с маргинальными диалектами Паскаля -- можно увидеть на примере Оберона. По-любому, идея -- ничто, реализация -- всё. Дорабатывать существующий компилятор Паскаля (тот же FPC) -- убиться можно, разрабатывать собственный -- тоже убиться, но об другое.

[Лекс Айрин]

Vapaamies, а что Оберон? Его "крах" чисто бизнес. Да и используется он для программирования. Другое дело что, допустим, я не смог найти компилятора под линукс. Возможно, что плохо искал.

Дорабатывать существующий компилятор Паскаля (тот же FPC) -- убиться можно, разрабатывать собственный -- тоже убиться, но об другое.

прямо таки убиться... Дорабатывать (форкать) имхо бессмысленно. Делать так с нуля. Это легче.

[hinst]

ну так сделай лал

[Лекс Айрин]

hinst, учусь, ищу информацию. Возможно, что когда-то и созрею.

[Vapaamies]

Лекс Айрин, у меня есть ответ на предыдущее сообщение, но посчитал неэтичным флудить в чужой теме.

[Mirage]

Написан процедурным стилем, объектные вещи добавлены туда были уже недавно.
Появилась тяга переписать всё на объекты, а имеет ли смысл? Максимум что получу, какую-то более структурированность и всё. Или не так?

А зачем переписывать таки? Структурированность она зачем? Какую проблему решает? Надо поддерживать и сейчас это сложно?
А тягу можно реализовать написав, например, что-то новое.