Парадигмы подходят для программирования пользовательского интерфейса

Это более конкретный вопрос (или на самом деле два, но они связаны) из комментариев о смерти технологии ООП, где кто-то заявил, что ООП не является подходящей парадигмой для программирования GUI.

Читая комментарии там и здесь, я все еще чувствую, что есть чему поучиться: какие парадигмы программирования считаются подходящими и почему они лучше других (возможно, с примерами для иллюстрации?)

Я удалил tk-пример из заголовка и вопроса

object-oriented paradigms

— инка
источник

@Inca - имейте в виду, что SK-логика (которая создала этот комментарий) борется с ООП при каждом возможном случае - например, если у него была фанатичная миссия. Я сильно сомневаюсь, что он действительно может доказать, что тк вообще не имеет отношения к ООП.

— Andreas_D

-1: для цитирования личного мнения, как будто это факт. «ООП - это не правильная парадигма для программирования с использованием графического интерфейса», - это бросает вызов C # и Objective C, которые, кажется, очень сильно зависят от ООП для программирования с использованием графического интерфейса. Если это не правильная парадигма, то всей огромной доли рынка Apple на самом деле не существует или что-то в этом роде.

— С.Лотт

@ S.Lott это не правильная парадигма, хотя GUI должен быть декларативным. Вы, кажется, путаете популярность с тем, что правильно.

— Рэйнос

@Raynos: «декларативный». Как в некоторых связанных объектах? Я не понимаю, как декларативно не связка между кучей объектов. А также. Это кажется не по теме для этого вопроса. Вопрос, похоже, о ОО, а не о лучших способах написания GUI. Название кажется вводящим в заблуждение по сравнению с настоящим вопросом. Ни один из них не очень хорош.

— С.Лотт

@ Инка: Подумайте о том, чтобы полностью игнорировать это как гиперболу.

— С.Лотт

Ответы:

Обычно я не сторонник ООП, но я бы сказал, что программирование с использованием графического интерфейса предоставляет одни из лучших возможностей использовать сильные стороны ООП. Реализация различных виджетов значительно упрощается благодаря использованию полиморфизма ООП и наследования. Библиотека графического интерфейса PLT Racket является хорошим примером.

— Ларри Коулман
источник

Функционально-реактивное программирование, похоже, лучше подходит.

— SK-logic

@ SK-logic: Вы могли бы сделать очень хороший пример для этого, и некоторая интересная работа в Common Lisp (вы слышали о Cells?) Была проделана в этом направлении. Я отредактирую свой ответ, чтобы сделать его более точным.

— Ларри Коулман

Типичный графический интерфейс, созданный из виджетов и их макета, полностью декларативен. Виджеты сами по себе не будут взаимодействовать друг с другом, поэтому понятие объектов и сообщений здесь несколько чуждо. Иерархические декларативные DSL в настоящее время являются своего рода мейнстримом, один из ранних примеров - Tk, а WPF - более современный подход к тому же. Функциональное реактивное программирование - еще один интересный (но не очень распространенный) подход.

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

— SK-логика
источник

По моему опыту, виджеты действительно должны взаимодействовать друг с другом, чтобы создать лучший графический интерфейс, и более декларативные системы, с которыми я сталкивался (некоторые основанные на XML, в том числе HTML + CSS), безусловно, не имеют возможностей в части взаимодействия. Кроме того, мой опыт использования пользовательского интерфейса, использующего декларативный (пролог) и функциональный (Хаскелл), не произвел впечатления, что это было легко. У вас есть источники, на которые я мог бы обратить особое внимание, чтобы обсудить больше этого? Я только придумал очень абстрактные (или очень простые) примеры, которые мало объясняют, почему некоторые подходы работают лучше

— Инка