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

Так этот пункт буквально все и покрывает.

Хелловорлды.

• Компьютерные игры (можно отнести к моделированию).

Обычно с ООП, но чаще на С, так что без средств из состава языка:

• Компиляторы и интерпретаторы.
• Ядро ОС.

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

ИМХО не критерий, есть много сложных открытых проектов на C.

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

Кем применяются? Когда применяются?

Какие дополнительные виды ПО можно добавить к указанному списку?

Можно - любые.

— Билет номер девять. Приём!

— Что вы сказали? Какой «Приём»?

— Я сказал не «Приём», а «При нём». Билет номер девять, а при нём задача.

Экзамены на носу штоле? :)

гугли преимущества ООП

приложения с графическим интерфейсом пользователя (GUI);

ООП здесь как пятая нога для слона

программы по вопросу моделирования;

а это что вообще такое?

Обычно с ООП, но чаще на С

Компиляторы и интерпретаторы

можно пример объектно-ориентированного компилятора на С?

ООП здесь как пятая нога для слона

видел я этот ваш гуй в функциональном стиле

а это что вообще такое?

видимо пересказ фразы «модель предметной области»

видел я этот ваш гуй в функциональном стиле

это ложная дихотомия. хотя даже функциональный гуй лучше объектно-ориентированного

пример объектно-ориентированного компилятора

Это компилятор, который создан с использованием ООП, что ли?

к любому ПО можно пременить, а теперь иди делать уроки

Это компилятор, который создан с использованием ООП, что ли?

это компилятор, при создании которого были применены объектно-ориентированные средства. не из состава языка C, поскольку их там нет

это компилятор, при создании которого были применены объектно-ориентированные средства

Например, редактор, написанный с применением ООП, не?

не из состава языка C, поскольку их там нет

Глупо пользоваться только лишь тем, что разрешено прямо.

Например, редактор

компилятор

разницу улавливаешь?

Глупо пользоваться только лишь тем, что разрешено прямо.

философские размышления не по теме лично мне не очень интересны. gv написал с ООП, но чаще на С, этот случай я и хотел бы обсудить

разницу улавливаешь?
объектно-ориентированные средства

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

философские размышления не по теме лично мне не очень интересны

Если для тебя выбор инструмента для работы - это философские размышления, мне жаль тебя и твоего работодателя.

Если ты программист, конечно, а не менеджер какой-нибудь.

gv написал с ООП, но чаще на С, этот случай я и хотел бы обсудить

Предлагаю тебе философски поразмышлять, чем GObject+C в твоём сознанании не является ООП на C. Можно вслух.

Nemerle?

можно пример объектно-ориентированного компилятора на С?

Именно так - нет, не знаю :)

ООП на C ведь растяжимое понятие. Я имею в виду, например, VFS в ядре и реализацию Tcl и Python. Из исходников компиляторов я смотрел только AST в clang, там ООП, но C++.

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

Не, речь о компиляторе, который написан на pure C, но написан в объектно-ориентированном стиле, например вручную реализованы полиморфизм или наследование. В каком редакторе писали код - не важно :)

Или ты что-то другое имел в виду?

забей

Именно так - нет, не знаю :)

жаль. было бы интересно посмотреть

реализацию Tcl

объекты там есть, но вот с ООП (в смысле позднего связывания) как-то не очень

Nemerle?

где здесь C?

приложения с графическим интерфейсом пользователя (GUI);

ООП здесь как пятая нога для слона

А можно пример GUI без ООП? И считаете ли вы за ООП большинство X-тулкитов (объекты - виджеты) и сам X11 (объекты - окна). Например, можно считать, что когда X-сервер посылает событие окну, а то его как-то обрабатывает, и каждое окно по-своему — реализацией полиморфизма.

объекты там есть, но вот с ООП (в смысле позднего связывания) как-то не очень

Ну как, например Tcl_ObjType.

например Tcl_ObjType

и где там позднее связывание? это просто словарь объектов - без наследования, без динамической диспетчеризации

ООП здесь как пятая нога для слона

Но ведь это чушь. Все популярные GUI-тулкиты являются объектно-ориентированными, а эффективный чистый ФП-тулкит невозможен.

даже функциональный гуй лучше объектно-ориентированного

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

ziemin

гугли преимущества ООП

ООП дает возможность создавать расширяемые системы (extensible systems). Это одно из самых значительных достоинств ООП и именно оно отличает данный подход от традиционных методов программирования. Расширяемость (extensibility) означает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе выполнения.

Добавляю к списку:

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

Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.

Одна из причин раздувания программного обеспечения.

И да, приведите пример «функционального гуя» с доказательством того, что он лучше объектно-ориентированного.

Cypher

программы по вопросу моделирования;

jtootf

а это что вообще такое?

Компьютерное моделирование

По теме. На сегодняшний день ООП — это парадигма, которая лучше всего (по совокупности различных метрик) справляется с задачами разработки ПО в совершенно разных областях. Это — ОС, СУБД, серверы приложений, веб-серверы, почтовые и IM-серверы, оптимизирующие компиляторы, среды разработки, embedded софт, desktop софт, вебсайты, enterprise-системы, middleware, telecom, CAD, CAM, CASE, SCADA, high-performance вычисления, игры и так далее. ООП оказалось удачной и гибкой парадигмой, способной справляться с решением задач во всех вышеперечисленных областях, отсюда и индустриальный успех.

Другие парадигмы, например, ФП, оказались неудачными и непригодными для эффективного решения большинства вышеперечисленных задач, как следствие — фиаско в промышленности.

когда X-сервер посылает событие окну, а то его как-то обрабатывает, и каждое окно по-своему — реализацией полиморфизма

хороший вопрос. с точки зрения определения товарища Кея - несомненно; но в исходном сообщении я имел в виду то ООП, о котором писали GoF

пример GUI без ООП

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

Обновленный список видов ПО

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

Другие парадигмы, например, ФП, оказались неудачными и непригодными для эффективного решения большинства вышеперечисленных задач, как следствие — фиаско в промышленности.

анонимус не тупи.

с доказательством

сам с собой ты можешь и самостоятельно побеседовать, без моей помощи

например. WPF, QML, HTML5

Ещё Glade/GtkBuilder. Но ведь всё это стало возможным исключительно благодаря ООП-подложке: C# в случае WPF, Qt/C++ в случае QML, Gecko/WebKit/etc. в случае HTML5.

Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца)

Полторы полудохлые поделки. Одним словом — маргинальщина at its best.

анонимус не тупи.

Что не так?

сам с собой ты можешь и самостоятельно побеседовать, без моей помощи

Т.е. ты ляпнул нечто («функциональный гуй лучше объектно-ориентированного гуя»), но обосновать это не можешь?

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

Я бы добавил «ПО уровня предприятия» (тот самый «enterpriZe», от которого у местных маргинальщиков резкая попоболь). Этот класс ПО обычно оперирует большим количеством сущностей (тысячи), большинство из которых персистентны (сохраняются в РСУБД транзактным образом), состоят из большого числа слабосвязанных модулей и интегрируются с внешними системами.

А Си-то и не заметил. Извините.

Но ведь всё это стало возможным исключительно благодаря ООП-подложке

не вижу противоречий

Полторы полудохлые поделки

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

перенос удачного решения на популярную платформу - вопрос времени

Лисперы тоже этим всех лечат. Уже 50 лет. Вот как перенесут — так и посмотрим.

вопрос не в распространённости, а в качестве решений

Почему reactive — более качественное решение, чем ООП-гуй? Докажите это.

обосновать это не можешь

тебе - не хочу. считай, что я слился

как перенесут — так и посмотрим

не тупи

считай, что я слился

Okay.

не тупи

И? С каких это пор adoption by Micro$oft у нас считается показателем качества?

Почему reactive — более качественное решение, чем ООП-гуй? Докажите это.

А чего доказывать-то, или по вашему неявное лучше явного? В frp видно какие сигналы и куда передаются, в ооп-гуе равиоли проявляются в худшем смысле.

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

Тут ещё дополнительное условие: программный продукт использует библиотеки и скорее всего не применяется во встраиваемых системах. Дабы устранить возражения про всем известное ядро.

но в исходном сообщении я имел в виду то ООП, о котором писали GoF

Гуф писали про паттерны. Сводить всё ООП к паттернам несерьёзно, это лишь шаблоны для написания логики программы в ООП стиле. Разумеется, паттерны для кодирования логики при декларативном задании GUI бесполезны.

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

Все указанные фреймворки не используют паттерны, но для связи с логикой используются как раз принципы ООП.

пример GUI без ООП

например. WPF, QML, HTML5, Phooey - шаги в правильном направлении. Reactive (если бы его разработку довели-таки до конца) был бы отличным событийным фреймворком для декларативного GUI

WPF без ООП? Ты серьезно?

Нет, конечно, я как-то экспериментировал. Писал на F#, используя приемы так называемого «реактивного функционального программирования» (у Томаша Петричека научился), когда подписываешь обработчик события через Async.Await, а само событие - это уже IObservable<_> (то ли это монада, то ли почти монада - там могут нарушаться законы; особо не задумывался). И большая часть кода становится неким вычислением (асинхронным). Даже не поймешь, на что это было у меня больше похоже, то ли на ФП, то ли на ООП, то ли на совершенно дикий гибрид. Причем, сделал простенький прототип редактора диаграмм на WPF, и это даже работало.

Но, в самом WPF всюду ООП. Я не говорю о xaml, я говорю о фреймворке.

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

например, банально проще воспринимается

Vector2 position (0, 0);
Vector2 speed (2.4, 2.2);
Vector2 next_position = position + speed;

Нежели запрогивание структуры, функции для инициализации (или ручной инициализации, или упаси макросов) и функций типа vector_add(Vector2 v1, Vector2 v2), хотя это всего лишь синтактический сахар по большому счёту. Но многим людям гораздо проще программировать и читать код.

Экзамены на носу штоле? :)

Может дисер пишет? Даже в топике язык в своеобразном стиле выдержан.

Приблизительный список таких видов ПО:

- софт написанный на Python, Ruby, C#, Java, прочие языки, на которых нельзя писать без использования ООП.