Нужны аргументы против ООП

Помогите мне холиварить =))) В общем я сегодня от друга слышал длинную лекцию о том как будущее за Джавой и дотнетом и что старые языки (е.г. С например =)) ) скоро умрут и никому нафиг не нужны. Ну это я отхоливарил быстро так как конечно с С ничего не случится.

И тут у нас начался холивар о том что ООП «единый праведный путь» (тм) и все что не ООП то плохой код.
Итак мои аргументы против ООП (С++ в чатсности) в большинстве свелись к изречения Торвальдса и Дейкстры:
1) На чистом С код быстрее
2) На самом деле код С++ нифига не портируется так просто (ну это отдельно про с++)
3) Библиотеки например Boost непроизводителны, так как дают слишком много удобной абстракции
4) ООП слишком далеко от реального представления информации и

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

Как видите мои аргументы не очень такие убедительные. Что еще можно сказать?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Реально существует только один аргумент — низкий IQ. Все остальные аргументы это следствие этого.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Извините Рома, а можно лучше Вашему другу помочь аргументы собирать?

Аргументы против?

Какова цель промышленной разработки ПО? Удовлетворение потребностей заказчика. Балансировка в треугольнике Быстро-Качественно-Дешево.

Рассмотрим на примере ithappens.ru/story/1003.

Если провести аналогии, то разработка в стиле ООП — это укладывание кабеля с помощью кабелеукладчика. Качественно. Дорого. Если есть опыт использования кабелеукладчика.

В то же время, не всегда в треугольнике выбираются только 2 параметра. Для клиента, возможно, важно получить результат Быстро и Качественно, и он готов за это платить. И не будет клиент ждать, пока разрабатывается каркас приложения в ООП-стиле: конкуренты в ФП-стиле сделают это быстрее. А если при этом параметр Дешево не выходит за рамки ожидаемого, то вообще супер...

Есть одна проблема.. Что такое быстро и дешево понятно. Возникает вопрос что такое качественно.

То что потом приводит к быстрому и дешевому изменению кода.

В общем случае да. Формулируется как стоимость сопровождения. Но не всегда оно вообще нужно. Иногда определение качества могут быть другими.

В качество входит понятие ошибок? Баги, как скрытые, так и явные? Глючность софта(как Windows Me)?

Смотря как задача стоит. Может пользователю плевать вообще что даже зависает. Он из 5 попыток один раз получает результат и его устраивает.

Баги, глючность, это дефекты. Количество дефектов коррелирует с уровнем качества, то не тождественно.
Глючность Windows Me — вообще не с той оперы. Для операционных систем над которыми рабатает куча стороннего ПО — качество вообще нужно измерять по другому.

Наиболее полно, по моему скромному ИМХО, это описал МакКоннелл в «Совершенном Коде»:
padaread.com/...book=335&pg=479.

А вот что такое «Качественно» для конкретного заказчика — определяется уже по ситуации...

Если код написан криво
и перформанс, блин, «не тот»
ООП тут виновато
только так, и нигребёт.

Итак первое сообщение было ответом на вопросы. Теперь собственно критика ООП.

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

В ООП нельзя писать «сверху-вниз» быстро вбивая текст.

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

ООП добавляет лишние абстракции. ООП в языках это все же те же функции, переменные. Чистый ООП, чисто объекты в современных языках нет. Посему вместе с процедурным методом появляется много новых ключевых слов, операторов.

ООП с множественным наследованием — это кошмар.

ООП требует все же дополнительных вычислительных мощностей. Инициализация объекта, RTTI, виртуальные функции, дполнительная память под this, обязательный вызов деструктора.

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

ООП в современных языках реализованно как попало. В теории все красиво, на практике все плачевно. Приходиться мешать ООП с ФП, ДП, ПП, ОП.

ООП усложняет компиляторы и их разработку.

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

Тестирование ООП сложнее чем ПП. Процедура это уже отдельная сущность, которую достаточно вызвать с набором данных и сравнения результатов. С объектом все немного сложнее. Объект надо создать и уничтожить. Вызвать методы в опредленном порядке. Проверить разный порядок. Например, метод begin надо вызывать до метода end. Каждый метод может меняет состояние объекта. Вариантов перебора масса. Тестировать метод отдельно от объекта нельзя. Объект может иметь кучу переменных, которые зависят друг от друга. Создавать класс ради одного int не всегда продуктивно.

Межязыковое взаимодействие ООП сложнее. Тебуются всякие COM и иже с ними.

Чтобы раздробить сущность в ПП много сил не надо. Достаточно просто сделать смещение, или указатель перенаправить. В ООП объект — минимальная неделимая сущность. Можно сделать объекты в объекте но это потребует дополнительный механизм. В ПП у вас есть блок данных, вы его обрабатываете как хотите. Хотите достучаться до второго элемента пожалуйста. Хотите его воспринимать как строку, просто напишите еще одну процедуру и блок останеться тем же. В ООП трудно представить как можно раздробить объект на мелкие кусочки во время выполнения программы. Потому что достучаться до private пременных класса через указатель — это уже грязный хак. А держать их открытыми — это уже не ООП, а антипаттерн «Паблик Морозов». В ПП можете представить что тажа 64 битная цыфра — это и набор битов, и набор байтов, набор 16 и 32 разрядных слов, это и буква, это float. У вас пределов нет. Пределы определяются железкой. И писать код дополнительный для этой сущности не надо. Сразу клиенсткий код использования.
В ООП кроме клиентского кода вы еще пишите всякие get(), set(), getHiWord(), toFloat(), data(), constData() и так далее.
Т.е, если вы электрик, в ООП вы отдельно делаете и вилку и разетку. В ПП, сишном например, вы делаете только вилку, а оголенные провода вы можете наматать и на вилку китайскую, на европескую, и даже заземление еще захватить. Можете на одну вилку намотать разные провода.
В ООП строго — вилка и розетка, должны подходить друг другу. Правда в ПП — оголенные провода небезопасны — пожары, поражение током, короткие замыкания, утечка энергии.

В ПП можно транслировать ООП, ФП, ОП. Из ПП в ООП трудно. Грубо говоря ООП — это такая странная реализация процедурного, но обратное не столь верно. Имеется ввиду грубость и громадность сущностей. В объектно-ориентированном программировании, кубики больше по размеру с них не соберешь мелкие детали. А вот процедурное, это конструктор в котором детальки малюсенькие, и сних можно собрать что угодно.

ООП обфусцировать немного труднее. Много надо учитывать. А вот с процедурным более все лучше. Посему всякие антиотладочные средства пишутся с уклоном в ПП.

Тестирование ООП сложнее чем ПП. Процедура это уже отдельная сущность, которую достаточно вызвать с набором данных и сравнения результатов.
В общем дальше можно не читать :)
Тестирование процедур проще когда у вас программа из 5 строк. Когда у вас большой модуль: ваша процедура вызывает еще 100500 процедур по цепочке, то тестировать такое счастье довольно проблематично, особенно в контексте юнит-тестирования. Тут как раз ООП самое оно, вы можете легко абстрагироваться от зависимостей.

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

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

Вам никогда не приходило в голову почему в C процедуры называются функциями?
Потому что они делают что-то одно и возвращают одно. И это одно можно протестить отдельно.
Вывод графики, логирование, исключение — это побочный продукт. И его быть не должно.
Точно также как с делением. Математическая операция деления делает одно — делит. А если у вас знаменателе ноль — это ваша ошибка, а не ошибка функции или процедуры. Это вы сдлали сбой в программе.
Вот поэтому библиотеки си могут не иметь каких-то глобальных переменных. И всякие memcpy могут не проверять перекрываемость множества. Это должны делать вы. Ее задача проста — бросать байты из одного вдругое. А вот границы массивов там даже не указываются. Просто переброска.

Это следствие плохого проектирования, а не процедурного подхода.

А в рамках ООП у вас есть объекты, которые содержат другие объекты в себе. И их состояние характеризуется совокупностей состояний всех агрегированных объектов. А то что объект не может посылать сообщения или вызывать методы по цепочке вы не рассматриваете такой вариант, неееее??? У вас все объекты без наследования, без агрегирования. Идеальный случай. Когда каждый класс можно прогнать отдельно.

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

Что значит читать дальше не надо?!
Не «не надо», а «можно не читать». :) Можно не читать чтобы не тратить время на поток сознания человека который делает дилетантскую ошибку в своих рассуждениях.
А то что надо сначала тестировать базовые процедуры, а потом переходить к более большим вы не слышали, да????
Слышал. А теперь задача:
a() {
  if (b()) {
    c1();
  } else {
    c2();
  }
}
b, c1, c2 уже протестированы и сами по себе требуют сложного сетапа (инициализации БД, глобального скоупа и тд). Как мне протестировать логику a? В случае с ООП, я просто укажу что объект у которого есть метод a принимает зависимости на объекты содержащие b, c1, c2.
В случае с процедурным Ц, «подмена» модулей/зависимостей происходит не на уровне языка (подмена объектов), а на уровне фантазии программиста (подключение других ДЛЛ, файлов и тд).

Для особо одаренных:

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

ПЕРЕДАВАТЬ, а не хранить не пойми где. П Е Р Е Д А В А Т Ь. Буквы умеете читать?
a(void * p);
b(void * p);
А то что вы написали это гавнокод. У вас куча глобальных объектов. ЧЕГО НЕ ДОЛЖНО БЫТЬ.

А что это за процедуры пустые без параметров и без возвращаемого результата??? Что это за черный ящик.

А если вы делаете сложный сетап в одной процедуре, то вы здесь мне рассказываете поток сознание. Потому что вы не программист. Вам на то и нужны процедуры, чтобы разбивать сложные программы на меленькие. А не делать гипперзадачу в одной процедуре с куче вызовов.

Вы должны в a() предать указатель на декриптор библотеки. А потом вызвать b() с аргументами.
Так делается в нормальных гнушных библотеках. Например, в той же Freetype2
Это у вас поток сознания. Вы несете чушь какуету.
Скачайте сами и убедитесь как там реализована работа с базой данных шрифтов, с прорисковкой каждого шрифта и вычисления его параметров.

В случае с ООП, я просто укажу что объект у которого есть метод a принимает зависимости на объекты содержащие b, c1, c2.
Вы сами себе противоречите.
Вызвали ДОПОЛНИТЕЛЬНО метод в которым вы указываете свои объекты. Вы сами ихо создали. Либо вы передали в метод a();

Вы демагогией занимаетесь.
На самом деле аналогичный код был бы другим в ООП

class b
{
};

class c1
{
};

class c2
{
};

class a
{
public:
method();
private:
b m_b;
c1 m_c1;
c2 m_c2 ;
};

a::method()
{
if (m_b.method()) {
m_c1.method();
}
else {
m_c2.method();
}
}

Эквивалентный код на ООП вашему на процедурном. Тоже самое. Логика непонятна. Тестить тяжело. Логика зависит от состояния агрегированных объектов. Как я узнаю внутрення состояние private объектов. КАК?

Состояния как в OpenGL не так много в процедурном подходе. Его не должно быть. Не должно быть такого. Это вот программирование в слепую. Вы что-то там вызвали и непонятно как проверить результат.
Но вы можете написать не так много тестов вокруг вызова одной несчатной процедуры. А для тестирования ОДНОГО ОБЪЕКТА вам нужно вызывать все его методы в различных порядках. И этот обеъкт, это единица программы обладает СОБСТВЕННЫМ СОСТОЯНИЕМ. И вы его не видите. А у процедуры ОДНОЙ нет такого состояния. Он выполняет свою работу и по идее должна вернуть результат или ошибку. Все.

А что это за процедуры пустые без параметров и без возвращаемого результата???
Здаетсо мне что кто-то не знает разницы между процедурным и функциональным программированием. (А пустые процедуры для того чтобы не загромождать пример)
Тестить тяжело.
Как я узнаю внутрення состояние private объектов. КАК?
Легко. Делаете конструктор который принимает m_b, m_c1, m_c2 и инициализируете их или моками/стабами или реальными объектами. Вы управляете состоянием и тестируете только поведение SUTа.
.
Вы должны в a() предать указатель на декриптор библотеки.
Но если у вас процедура с over 9000 параметрами, вы вообще программист???
3-5 зависимостей (указателей на дискрипторы библиотек) + 3-5 параметров == over 9000 параметров :)
А для тестирования ОДНОГО ОБЪЕКТА вам нужно вызывать все его методы в различных порядках.
Нет.
А у процедуры ОДНОЙ нет такого состояния.
Вы явно не в курсе чем процедурное программирование отличается от ФП.
.
И еще настоятельна просьба:
Ваши беснования конечно забавны, но оскорбления не мотивируют искать информацию в вашем возбужденном потоке сознания.
И еще настоятельна просьба:
Ваши беснования конечно забавны, но оскорбления не мотивируют искать информацию в вашем возбужденном потоке сознания.

Ну просто слова «дальше можно не читать» носить преимущественно пренебрежительный характер.
Тоже самое неуважительное «didnt readdd, lol». Призваны только спровоцировать человека, а не вести дискусию. Или же «не осилил/зачем писать так много?» — не уважение к собеседнику. Если вам не нравиться занудство персоны, или ее многословность — не читайте. Это ж так просто.
А как еще можно истолковать выпады «я не читал/всем пофигу» не иначе как провокацию на конфликт. Это троллинг. Зачем умышленно всем заявлять, что вам не понравилась статья или книга, или еще что-то. Все равно что придти к писателю на встречу и бросить фразу «не читал, но осуждаю!».
А фраза «поток сознания автора» явный переход на личности. Потому что вы критикуете ни процедурный подход и объективно-ориентированный, а личность самого говорящего.

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

Хорошую тему поднял. Я могу сказать в чем проблема глобально. Дело в том, что вопрос об истинности высказывания лежит на другом уровне семантической иерархии и не может в принципе решен в рамках самой программы как текста (или даже выполнения).. Это решается в момент выполнения.. Более подробно в работах логических типах Б. Рассела, или иерархической семантики Тарского. Что на практике мы имеем в отдельных регистрах процессора для анализа условных переходов..Находящихся как бы над выполнением операций в регистрах.. Типа мета представление.. Ну, я для решения это проблемы необходимо иметь язык позволяющий строить метавысказывания относительно выполнения программы.. Оператор IF это частный случай метаоператора..

И тут у нас начался холивар о том что ООП «единый праведный путь» (тм) и все что не ООП то плохой код.

Зависит от потребности. Если не важна потеря так 200-400% производительности, но крайне важна читабельность кода, то чистый ООП со всеми выкрутасами — идеальный подход. Если важна скорость то отказ от ООП правильный путь.

Истина где-то посередине. Лично я пишу библиотеку различных функций на чистых static и по большей части инлайню код. А потом уже более высокоуровневые результаты обработки заворачиваю в ООП. Область — компьютерное зрение.

Если не важна потеря так 200-400% производительности, но крайне важна читабельность кода, то чистый ООП со всеми выкрутасами — идеальный подход. Если важна скорость то отказ от ООП правильный путь.
Что за бред?! Откуда такие цифры? Пара переходов по ссылкам дает просадку производительности в 2-4(3-5) раза?

В принципе так. Даже от изменения направления прохода по двумерному массиву скорость алгоритма может изменится в 5-10 раз (по строкам или по столбцам). Если по двумерному массиву адресованному по строкам идти «против шерсти» вы это очень скоро почувствуете при работе с 20-100 Мпик-сельными массивами.

Даже от изменения направления прохода по двумерному массиву скорость алгоритма может изменится в 5-10 раз (по строкам или по столбцам).
Не надо подменять понятия. Пример с массивами неликвид, ибо не имеет отношения к ООП, это чисто проблема алгоритма и организации работы проца. Мало того ООП вам позволяет абстрагироваться (при желании) от того как происходит обход и если обход «против шерсти» будет тормозить переписать вся на более быстры обход (даже многопоточный, см джава8 :) )
.
Повторяю вопрос: откуда цифры?

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

Если я буду применять ООП, представляя каждую ячейку объектом, то будет бяда с производительностью раз так в 100.

Если я буду применять ООП, представляя каждую ячейку объектом, то будет бяда с производительностью раз так в 100.
«Будет». То есть цыфры взяты из необходимости доказать что ООП — это медленно :)

ООП — это не медленно, ООП — это подход уже как минимум для среднего звена приложения. На низком уровне нужно писать без ООП. А то после таких ООП-умельцев, годовые отчеты на 1C сутками считаются.

В общем, если потери в производительности на конкретном уровне обработки информации не более 15%, то нужно использовать ООП.

Кстати — поисковик Google написан на чистом C, а вот уже обертка, которая выдает результаты, на Java. Не могут же Гуглы ошибаться?

Кстати — поисковик Google написан на чистом C, а вот уже обертка, которая выдает результаты, на Java.
Пруфф на бочку.
Не могут же Гуглы ошибаться?
1) Могут.
2) Ц против джавы — это параллельный срач обсуждению ООП против процедурного стиля.

Google реализовал MapReduce на C++ с интерфейсами на языках Python и Java.

C++ там компилятор, а стиль там С-с-классами, вместо страктов

Google реализовал MapReduce на C++ с интерфейсами на языках Python и Java.
«Проект Apache Hadoop — бесплатная реализация MapReduce с открытым исходным кодом на языке Java.»
Но там наверное так же от джавы только компилятор.
C++ там компилятор, а стиль там С-с-классами, вместо страктов
И снова пруфф!
И снова пруфф!

За исходниками их движка обращайтесь к гуглу.

За исходниками их движка обращайтесь к гуглу.
Шикарно. А вы откуда-то знаете какой там стиль? Уже перешли из Aspose в Гугл?
.
Кстати, что там с «поисковик Google написан на чистом C», MapReduce — это не «поисковик Гугл»
MapReduce — это не «поисковик Гугл»

Это его движок.

MapReduce — это не «поисковик Гугл»
Это его движок.
Вообще-то MapReduce — это «программная модель» (парадигма, в некотором роде)
Ну и откуда инфа про стиль закрытых исходников гугла вы не скажете?

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

Окей, опишите вычисление дискретного 1D вейвлета Добеши с использование ООП. И что оно вам даст по сравнению с процедурным static. Нет его можно будет даже завернуть в интерфейс, но функция то будет работать по процедурному стилю?

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

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

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

Если говорить о математических вычислениях, то действительно наверное лучше использовать статичный код. Тем более, что и в java.lang.Math все функции статичны. Но обычно математические вычисления не требуют так уж много кода. А вот полный отказ от ООП ради скорости, это уже перебор.

2) На самом деле код С++ нифига не портируется так просто (ну это отдельно про с++)
Все зависит от компилятора. Если компилятор GCC. То там можно тупо поотключать все на свете. И сделать из плюсов обычный Си.
Можно использовать компиляторы которые игнорят многие конкструкции.
Порнтируется тяжело?! Наверное имеется ввиду исключения, выделения памяти, конструкторы и деструкторы.

Выделение памяти можно сделать через стек. Никто не мешает вставить в new дополнительный код проверки объема и выбросить ошибку. Неважно как выбросить, лишь бы видно было.
Вы ж не сможете на джаве написать код, который хавает 1 терабайт оперативки!? Тоже самое и со стеком. Он тоже не резиновый. Можно сделать так, чтобы был специальный буфер под new и delete. С этим разобрались.

Исключения. Это по сути тоже вызов функции, деконструкторы и все такое. Плюс еще и делается goto на нужный блок обработчика. Если проц не поддерживает прыжки, а только вызов функций, то ничто не мешает из блока catch сделать процедуру. По сути это и есть процедура, только внутри другой. В языке D я знаю точно можно процедуры объявлять внутри других процедур и вызывать. Тут разницы для проца нет ни какой. Области видимости разрешаются, если есть память для «глобальных» локальных переменных ячеек.

Конструкторы и деструкторы есть и так в Си, это инициализация. Ведь main это не первая процедурка. Она вторая и даже третья по счету. Прежде чем вызвать main идет код для вытаскивания аргументов argc, argv и т.д.

За остальное, типа виртуальные функции, RTTI, это все даже можно и на чистом Си делать без грязных хаков и вставок.

Код портируется, иначе как вы объясните что я C++ embedded developer?? :))))

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

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

1) На чистом С код быстрее
На чистом машинном языке быстрее. А Си зависит от компилятора. Но если нам нужна портируемость, то да, на сишке быстрее всего. И компиляция тоже быстрее.
Но это также актуально и для С++. Но вот загвоздка. сравнение то плохое. Дело в том что Си это трактор. А плюсы трактор с прицепом. Хочешь в гонках учавствовать — отцепи.
С++ может все тоже самое что и Си. Просто добавли нового.
Нельзя цепляться за мультипарадигменные языки. ООП это не язык, а целый подход к решению задачи, структурированию кода.
Это ниже.
4) ООП слишком далеко от реального представления информации и
И функциональщина тоже далека от представления информации. Изучения Хаскеля может прекратиться на монадах.

Аргументы старые. Не все модели укладываются в ООП. В том смысле что для создания объекта всегда нужно создавать соответсвующий класс. Для некоторых задач это напрягает. Но, это редко случается. Остальное проблема личной соображалки. Языки низкого уровня от ассемблера до всяких С нужны для небольших или системных задач. Аргумент что на С быстрее работает не факт. Чем выше уровень языка тем выше возможности оптимизаторов, ну и портирование проще. Ну, и наконец, главное. Это если речь идет об императивной парадигме. Есть и функциональные языки, логическое программирование. Есть задачи которые проще решать в этих парадигмах. Есть и еще кое-что..

Не все модели укладываются в ООП.
Например?
В том смысле что для создания объекта всегда нужно создавать соответсвующий класс.
Кто сказал?

Это принцип ООП. Для того что б создать объект нужно иметь класс. Есть прототипные языки. Там можно создавать объекты на основе объектов. Но, отсюда много проблем с эффективностью и обнаружением ошибок

Это принцип ООП. Для того что б создать объект нужно иметь класс.
Если не впадать в философию, то такого принципа нет (или же дайте ссылку на него).
Но, отсюда много проблем с эффективностью и обнаружением ошибок
Та пока проблем не особо проявляется.

Объе́ктно-ориенти́рованное программи́рование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов. В случае языков с прототипированием вместо классов используются объекты-прототипы.
Отсюда. ru.wikipedia.org/...рограммирование
За трудность обнаружения ошибок это касается прототипных языков. И это не трудности пользователя, а сложность реализации транслятора, связаные с опеределением описания объекта.

За трудность обнаружения ошибок это касается прототипных языков. И это не трудности пользователя, а сложность реализации транслятора, связаные с опеределением описания объекта.
Опять же не понял.
Чего VMT реализовать не сложно, двунаправленный список реализовать не сложно, а пройтись по цепочке прототипов в поиске первой реализации указанного метода — уже сложно?

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

область существования? какая? есть счетчик ссылок и garbage collector, который чутка поумнее простой проверки на равенство счетчика ссылок 0 и умеет обнаруживать циклические зависимости.

Да и там фишка в том, что новый объект может иметь свойства и методы дополнительные к тем отчего наследуется
И? vmt + static methods не напрягает же реализовывать.
может, я что-то недопонимаю?

Ты все понимаешь.. Все тоже самое только реализация того что я предлагаю проще..

отказаться от VMT — и все будет еще проще. В реализации транслятора.
Мне казалось, мы пришли к моменту, когда скорость разработки ценится выше, чем скорость работы. За исключением вполне определенных областей, где применяются вполне определенные языки программирования.

Ты хотел сказать стоимость разработки?

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

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

которой основными концепциями являются понятия объектов и классов.
1) Супер. И где тут сказано что
Это принцип ООП. Для того что б создать объект нужно иметь класс.
2)
Отсюда. ru.wikipedia.org/...рограммирование
en.wikipedia.org/...ted_programming
a programming paradigm that represents the concept of «objects» that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.
.
За трудность обнаружения ошибок это касается прототипных языков. И это не трудности пользователя, а сложность реализации транслятора, связаные с опеределением описания объекта.
В чем сложность?
Ну, по сравнению с отсутвием этого списка сложнее. Да и там фишка в том, что новый объект может иметь свойства и методы дополнительные к тем отчего наследуется.
Та же история что и с классами, только вы ходите не на магический класс, а на другой объект.
Та и никто вас не заставляет использовать наследование.

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

python, php позволяют добавлять произвольные члены в объект, при том используя именно «классовую» реализацию наследования.

Но, нюанс в том, что в классе должно содержаться описание создаваемого объекта, а не копия объекта
речь про RTTI?

Да нет. Немного другой подход. Попытаюсь объяснить..
Подход 1.
Есть объект (на каком-то языке). Никто не мешает считать его классом и выполнить НЕЧТО, которое создает новый объект (или объекты) из вот этого чего-то. По большому счету создание объекта заключается в создании свойств (или атрибутов в разных языках по разному называется). Ведь методы, функции и процедуры не нуждаются создании. К ним обращение идет через класс.. Ну, это понятно..Пропустим даже вопрос о статических переменных..
Подход 2.
Обойтись без этого «НЕЧТО», которое воспринимает класс (он же объект) как информацию для создания объекта. Получается что в таком случае класс должен иметь специальные (выполняетмые) операторы которые говорят что это не сам объект, а описание объекта..
Прочитал..Не думаю что понятно объяснил.. Но, где-то так.. Если подробно, то это уже много рассказывать.. Заранее извняюсь..

класс, как описание типа и не более — это struct на препроцессоре. Соответственно, никакой возможности выбирать класс runtime. и никакого RTTI. ради чего? ради скорости компиляции?
как часто критическим местом становится иерархия классов, а не алгоритм, работа с вводом-выводом или БД?

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

Что значит «у меня»? Речь о конкретном проекте, обобщении личного опыта или «в общем»? Остальное описание мало чего сказало мне. Речь о том, что нужен язык, на котором было бы удобно как реализовывать UI/работу с БД, так и алгоритмы обработки бинарных данных? Типа, требования едины? Ну, пожалуйста, используй монстра С++. В делфи тоже можно как использовать RTTI и виртуальные методы, так и фигачить олд-скул паскаль код без ООП вообще. И даже вставки на ассемблере(последняя версия, с которой работал — Delphi 7, может, на текущий момент все ищменилось)

Это мой собственный проект который я разрабатываю.

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

Никакой джавы и вообще ничего.. Все с нуля

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

А я не помню что б я возражал что прототипный подход сложнее дебажить. Более того, я это же и утверждал. Вопрос стоял насчет недостатков ООП.. Я и сказал свое мнение. Не помню чего за теорию уцепились. Больше не буду..

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

Всегда думал, что класс это описание типа объекта, то, что вы назвали объектом — это экземпляр. А это и переменная и константа и экземпляр класса.

Дело не в названиях. В разных языках может быть разное. Вопрос в сути. Пусть объект будет экземпляром это ничего не меняет по сути. Главное что есть описание класса и на основе этого класса создаются объекты (или экземпляры). Если правила (алгоритм) построения класса и объекта единый то в некоторых языках это так же можно назвать экземпляром класса. А вот насчет переменных и констант у меня другой взгляд. По моему это значения. Значения порождаются от типов, а не классов и сравнение (и другие операции) значений происходит не по ссылке, а по значению. Если каждый объект является уникальным, то одинаковых (равных) значений может быть сколько угодно.

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

Можно считать что класс и есть тип, а можно считать что есть разница.
По поводу значений я за принцип говорю а не метод обращения. Конечно, бывает удобнее, а иногда даже необходимо, обращаться через адрес. А за скорость.. это от многих факторов зависит. Даже от архитектуры процессора, и системы команд. Универсального решения нет. Надо смотреть по факту. И какие цели ставятся.

Главный аргумент против ООП — индусы, они пишут в противоестественном стиле на любом языке, используя объект как неудобное хранилище 100500 переменных. Не будьте индусом и все наладится.

Самый главный аргумент против ООП — это то, что его никто не понимает. В том числе и твой друг.

5) ООП вимагає багато коду.

====
А як відомо, не залежно від мови і парадигми, кількість помилок на 100 лінійок стабільна, тому
ООП більш глючний в реалізації

=====

9.1 Создание программ, управляемых данными

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

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

www.e-reading-lib.org/..._dlya_Unix.html

После II мировой войны Японии и Германии запретили заниматься авиационной промышленностью и разработками. И до сих пор у них ничего нет.

1 Так таки ничего?

2 А после I мировой Германии запретили заниматся танками и артиллерией...

На самом деле, всю не такую уж сложную концепцию ООП можно качественно реализовать лишь на уровне ниже ассемблера. Окончательное дно — комбинационная схема. Но это будет долго, и это оправдает себя лишь в некоторых критических случаях. Ну например, вам нужно в середину зрительного нерва расставить десяток пикопроцессоров, и конечно, там счет пойдет уже на байты, а в байтах счет пойдет на их минимальную разрядность, может 5, а может 3. Допустил математик (это уже будет не программист) лишних 10 тактов процессора в рабочем цикле, и уже пикопроцессор не потянет по питанию. А питается он, допустим, межклеточной разностью потенциалов.

Значит, ООП вовсе не про эффективность, не про оптимальность, и не про математически доказанную верность программы, особенно если ее вшили в пикопроцессор лично вам, и она обеспечивает ритм сердца или дыхания. ООП это просто записки программиста. Наброски, черновики, поля газеты, в которые селедку заворачивали.

В программировании выделить нужно две стороны и интерфейс между ними.

Процессор_над_памятью <-> текст программы <-> мышление человека.

Весь смысл ЯВУ, ООП, или концепции скриптоязыков типа Си или Бейсика, это отсечь из интерфейса ту часть, что смотрит в сторону процессора. И максимально облегчить соответствие:

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

Например, для блондинки лучше автомобиль тот, где нет педалей вообще, а спереди и сзади — по багажнику. Его ни заправлять не надо, ни парковать в узком месте, ни думать, что это, вообще-то, двухтонная дубина для пешеходов. ООП, и вообще ЯВУ, делает из программиста вот такую блондинку, с ее желаниями. То есть, она на вид хороша, и рассказ как она за рулем, и ветер в лицо, доставляет. Пока машина под ее управлением не поедет. А тогда и фотографии не надо, и так всё понятно, кому у нас ветер в лицо.

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

Потому что весь мир программирования только об одном: скорость исполнения.

Если вы сократите количество необходимых процессору операций вдвое, вы можете поставить в смартфон процессор не 800мГц, а 400. Поднимите руки, кто сумеет посчитать доп.прибыль на продаже пары десятков миллионов таких экземпляров. Или за те же деньги можно предложить вдвое большую продолжительность работы от той же батареи. Процессор потребляет, пока шагает, а скорость, как известно, это о времени в пути. Или в два раза уменьшите габариты, тепловыделение, и пр.

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

Какова цена, к примеру, сократить путь исполнения вдвое, если известно, что любой вызовов WinAPI это тысячи операций. Написать свой код. Что делает ООП? Ровно наоборот. Плодит API.

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

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

В итоге, резюмируя, против ООП аргумент всегда один: скорость в пути. Вычисляется просто: V = (скорость совершения шага)/(шаги процессора).

Против Си аргумент тот же. Скорость в пути.

И вообще, скорость против всех.

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

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

текст_программы <-> программист <-> бизнес 
И в отличие от болта для болида, здесь есть обратная связь, которая очевидна всем: чем быстрее скорость на участке
текст_программы <-> программист <-> бизнес
, тем медленнее скорость
процессор_над_памятью <-> текст программы <-> мышление человека
Обратная связь, а она здесь отрицательная, приводит к стабильности и стагнации. А рынок давит.

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

Что — то много букафф, а толку мало ИМХО. Языки программирования будут двигаться и развиваться в сторону противоположную от ассемблера — в сторону языково высокого и сверхвысокого уровня, типа ДСЛ, по той простой причине что труд программиста стоит куда дороже лишних 100 МГц. Язык руби тому прямое подтверждение. Его создатель Мацумото сказал, что язык должен быть ближе к человеку, а не к компьютеру. И оказался прав.

Самая большая проблема программиста, вернее две проблемы — сроки работы и бажность программ, но никак не скорость выполнения в 80% а то и больше случаев. Потому индустрия выбрала языки высокого уровня, типа джавы, шарпа, руби т т.д. И появляются ДСЛи и т.д. А процы и так подтянутся.

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

У Вас даже шанса на это нет (но не по причине отсутствия умственных способностей). Оставьте это МИТ или Гарварду. Ничего не попишешь, это следствие международного разделения труда, и столь же весомо, разрыва в процессе научно-исследовательской работы в CS, после развала научной системы СССР.

Разрыв страшная штука. Наука эволюционна. У нее последовательный, накопительный характер, обеспечиваемый только через одновременность нахождения разных поколений в ее сообществе. Ее нельзя временно «приостановить» без слома, потому что теряется коммуникация, а с ней процесс осознания, и вскрытия ошибок в эволюционном развитии науки.

Пример. После II мировой войны Японии и Германии запретили заниматься авиационной промышленностью и разработками. И до сих пор у них ничего нет. Элита тех стран, выносившая этот вердикт, в отличие от части сегодняшней, была весьма образованна и умна. Они понимали, что такое «приостановка» в научном плане и к чему это приведет.

Так что не заморачивайтесь, всё объективно. )))

Языки программирования будут двигаться и развиваться в сторону противоположную от ассемблера — в сторону языково высокого и сверхвысокого уровня, типа ДСЛ, по той простой причине что труд программиста стоит куда дороже лишних 100 МГц.
Проблема впирається у енергетичний поріг подолання електроном потенціоальної ями/бар«єра.
І розміри P/N переходів мають граничну межу, як і гранична швидкісті фотона у вакуумі. Як результат — верхня десь є межа по частоті процесора і енергоємності і вона вже відчутна, так як процесори не розганяють на десятки ГГц а роблять багатоядерні чіпи.
Але це також екстенсивний шлях хоча і силікон дешевий, але проблема енергоспоживання, тепловиділення і ряд інших існують, так як існують фізичні обмеження, а не абстрактні.
Але абстрактний код працює на фізичних пристроях, і, на відміну від необмежених рівнів абстракції, фізичні явища мають обмеження.
А процы и так подтянутся.
Підтягнуться, але вже не так швидко, як це передбачає «Закон Мура».

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

Скоро будем кушать радугу какать бабочками.
До того дойдут технологии.

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

Вот это Вас тыркнуло :) Рынок всё сделает за Вас, у него естественный отбор, просто держите нос по-ветру и бросайтесь только в одну крайность — высокий уровень отдачи в долларовом эквиваленте.

Рынок всё сделает за Вас, у него естественный отбор
>>>>> OFFTOP >>>>>>>
:)
Вы произносите эту порченую молью тезу так, будто призыв ею пользоваться как объективной, автоматически дает приемлемые результаты. Да вот беда, есть контрпримеры к такому обобщению: почти все воры и большая часть убийц следуют ей же. Они вполне «естественно отбирают» и жизни, и имущество )))

Вдобавок идея стяжательства (политкорректно: невидимая рука рынка) не используется в семейных отношениях, если это конечно, не мерзкая семейка )))

<<<<<<<<<<<<<<<

Вы прям генератор случайных

>>>>> OFFTOP >>>>>>>
Зачем Вы приплели убийц, воров, стяжательство?
Рассматривайте мою фразу в рамках рынка ИТ и разработки ПО в частности. А лучше, вообще, не рассматривайте, а то из Вас опять попрет рефакторинг нашего бытия с избыточным комментированием.

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

ООП призвана стать инструментом в интерфейсе «бизнес <-> текст_программ», чтобы побыстрее реализовать новую идею, которая почти всегда появляется взамен всё еще приемлемо работающей старой. Мотив этой идеи хорошо и давно известен, уже столетие, это Planned Obsolescence (запланированное устаревание). Посмотрите на youtube фильм «The Light Bulb Conspiracy: Planned Obsolescence», есть на русском, «Купить, выбросить, купить». Пример этой схемы в IT хорошо известен — Майкрософт вынуждает пользователей переходить на новые версии программ, хотя старые многих всё еще полностью устраивают. При этом трудно не прийти к выводу об очевидном сговоре Майкрософт с производителями компьютерных частей и устройств.

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

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

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

Мерзость и насмешка всей этой ситуации еще и в том, что идея стяжательства не ограничивается, как это может показаться, схемой бизнес <-> потребители лампочек. Дело в том, что сейчас сам бизнес оказался потребителем и заложником своего же принципа Planned Obsolescence от Майкрософта, Интела, Оракла, и прочих тех, кто на самой-самой верхушке производства ПО и компьютерных частей. Принцип это то, чему следуют во всех без исключения случаях. Распространение принципа возвращает его. И если принцип ложный и приносит зло, он обязательно вернется злом. Поэтому-то все религии и учат: принимай только те принципы в отношение к другим, которые истинны и в отношении тебя самого. Это, как ни странно, рационально и выводится чисто логически.

Есть и те, кто отлично понимает принцип Planned Obsolescence, и знает, что этот путь в отношении к нему есть зло, а потому сам он будет продолжать использовать IBM360/370, и продолжать писать ПО именно для нее, а оно часто на ассемблере. Остальным, невежественным и несообразительным бизнесменам и менеджерам, дело будет подано так, будто всё у них морально устарело, всё давно пора сдать в утиль, переписать заново на супер-пупер языке и новомодной полупрозрачной анимированной GUI. А рядом услужливо стоят толпы программистов, вооруженные ЯВУ и ООП, кивающие одобрительно головой.

Бизнесмены, которые вдруг стали потребителями от других бизнесменов, и при этом не осведомлены о схеме Planned Obsolescence для ПО, испытывают кто раздражение, а кто и опосредовано тихо ненавидит вас, разработчиков ПО. Почему такие деньги за непонятные цены? Что это за навязываемые мутные услуги, почему нельзя вовремя выполнить обещанное, гарантировать доказательством безошибочность, и наконец, откуда этот снобизм, и т.п. И если даже этот бизнесмен совершенно уверен, что его парк машин, принтеров и программ вполне еще справляется со всеми задачами, то существует давление еще и на его работников через рекламу и трескотню в коммерческих IT медиа, и затем эти работники требуют от работодателя последних версий, оболочек, и модных примочек, а всё это вместе потребует новых мощностей компьютеров. Всё надо купить и обновлять, а несовместимость версий и железа точечно и в нужном месте искусственно добавят, будьте уверены.

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

Так что аргумент, что ООП помогает в скорейшем выкатывании на рынок версий того же самого, предстает в другом свете, не так ли? Если отсечь в рассмотрении ООП экономию ресурсов (процессора).

-----------------------------------------
на этом позвольте завершить по этой теме :)))

Блинский....
Батенька, да Вы убежденный консерватор.
Не философия сделала из нас совершенные организмы, а естественная эволюция.
Я ж Вам не зря говорил про рынок. У него как и у природы есть жесткий закон спроса/предложения, который занимается селекцией лучших из лучших. И он как муха — практически никогда не ошибается, как бы Вам этого не хотелось.
Поэтому у нас в кармане лежит мобильник за 200 баксов, который в разы быстрее 20 летнего компа, а современные ноуты за 500 вечно зеленых в рюкзаке за спиной по производительности и функциям превосходят супер ЭВМ тех лет. Это всё благодаря «чрезвычайно зауженному кругозору» ИТ специалистов.

Это всё благодаря «чрезвычайно зауженному кругозору» ИТ специалистов.
Электроника быстрее развивалась, чем информатика.
Наверно благодаря проффесионалам от ИТ, и «чрезвычайно зауженному кругозору», с которым застряли на концепции 80х годов прошлого века (ООП).
java way выстрела в ногу
thedailywtf.com/...t-of-Trees.aspx
И че? Какое это имеет отношение к ООП?

никакого. просто пример как с ооп можно выстрелить в ногу

Это пример выстрела в ногу без ООП.

Можно подумать в других языках такое нельзя сделать.

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

Этож еще надо прицельно стрелять!

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

в идеале надо знать плюсы и минусы всех парадигм (инструментов) тогда можно выбирать подходящую под цели задачи
АШЫПКА. От поверхностного знания теории и отсутствия практики.
На практике, каждая из «парадигм» позволяет посмотреть на одни и «те же яйца», но в разных проекциях. И потому «выбирать парадигму из имеющихся в наличии» — просто глупость, потому что нужно посмотреть на предмет под всеми возможными углами, чтобы составить полное представление.

кто вам сказал что я отрицаю практику ?

Зачем нужно ООП — показать вот такой код и больше ничего не нужно
www.gamedev.ru/...orum/?id=160897

А потом такие Маркусы, Фаулера не помнящие, вот такой вот код пишут в реализации CreateBread
govnokod.ru/234

удалил, много места занимало

Какая няшечка... МЕГА СПАСИБО!!!
ООП головного мозга
В мемориз! :)

До того как люди изобрели мотыгу, они рыли всё руками, прелесть рукорытия — более тесное общение с природой, крепкие ногти, доскональное понимание процесса. Но когда люди задолбались рыть руками и мотыгой, они придумали экскаватор и динамит.
Про что это я? Да, функциональное программирование — это рукорытие, ООП — это мотыга, когда задолбаются придумают экскаватор, но, думаю, тогда программировать будем не мы, а какой-нибудь искусственный интеллект и компилить на каких-нибудь квантовых компах.

Да, функциональное программирование — это рукорытие

Вы ничего не путаете?

Вы имеете ввиду функциональное — процедурное — императивное. Там черт ногу сломит в парадигмах и их правильных трактованиях.

“You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
— Joe Armstrong
The Unreasonable Effectiveness of C
HN comments

Читайте комментарий внизу, Joe Armstrong не отличает объект от класса, о чем тут дальше говорить?

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

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

Я иногда вообще достаю школьный Сканави.

Я иногда вообще достаю школьный Сканави.
И пытаюсь снова войти в эту реку... LOL
А может какую-нибудь теорию кодирования надо почитать, криптографию? Чтобы не готовиться к поступлению в институт во второй раз? ;)

Это я и так читаю. А вот Сканави или задачник по матану за первый курс здорово оживляют мозг.

всегда стоит уточнять какая математика

описывающая предметную область. Математика без предметной области подходит разве что для упражнения ума, но ничего не имеет общего с реальностью. Обычно, та математика, которая преподается в украинских университетах, не имеет ничего общего с реальностью, поэтому и возникают такие споры: «Нужна ли программисту математика».

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

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

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

Вы меня успокоили, а то молятся, молятся на нее — а показать как применяют — не могут :)

и какая математика описывает предметную область «фейсбука»?
Например, статистика, data mining, алгоритмы на графах.
да вообще к подавляющему большинству предметных областей — математика даже не на подступах.
Обработка сигналов, разпознавание образов, статистика, дейта майнинг, геймдев, комп. зрение , процессинг естественного языка, крипография, шифрование ( без теор. вера не разобраться ) не говоря уже об анализе и синтезе алгоритмов, это довольно широкие предметные области.
Да, eбаны в рот, математику можно даже встретить в программировании тех же игровых автоматов — типичная задача это подобрать нужное распределение максимизирующее потери игрока.
Короче, в любом приложении отличающемся от CRUD’а ( даже очень большого, обслуживающего банки вроде барклая или там дойчбанка), математика может пригодиться.
геймдев
Если копнуть геймдев то в казуальном 2д геймдеве математика не особо сложная. В нормальном геймдеве намного по сложнее

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

статистика, data mining
Какой функционал фейсбука это использует?
или же речь о сторонних проектах, который использует FB как источник информации, а указанные дисциплины собственно «отвечают» за анализ?
алгоритмы на графах
отображение «общих друзей»? алгоритм на графах?

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

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

почему же не поверю? охотно верю.
это и есть data mining, основанный на сумасшедшего размера графах?

основанный на сумасшедшего размера графах?

у меня сослуживец в инвестконторе, в NY программист data mining Их тама трое программистов, остальные брокеры, аналитики и прочие швырятели миллионов и биржевые игроки.

В приезд его к родителям коснулись этой темы. Примерно сказал:
Знаешь, я думал «data mining» это О-О-О, а оказалось, такое дурацкое и тупое программирование, что только зарплата держит, чтобы бросить заниматься этой туфтой.

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

машинлернинг
Машинное обучение (англ. Machine Learning) — обширный подраздел искусственного интеллекта, изучающий методы построения алгоритмов, способных обучаться. Различают два типа обучения. Обучение по прецедентам, или индуктивное обучение, основано на выявлении закономерностей в эмпирических данных. Дедуктивное обучение предполагает формализацию знаний экспертов и их перенос в компьютер в виде базы знаний. Дедуктивное обучение принято относить к области экспертных систем, поэтому термины машинное обучение и обучение по прецедентам можно считать синонимами.

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

???

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

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

математика правда не в состоянии даже шахматную партию анализировать, без мощнейших эвристик, Человеческих (хотя, Каспаров одну партию проиграл потому что комп выбрал — рандомайзно ход, эвристики не помогли отсеять. по признанию одного из программистов IBM), но — придется поверить что 64 клеточки и 32 фигуры — ей не по зубам, а вот — миллиард юзеров и 100 миллионов сигналов, та, делов то :)

не сталкивался
Ну ты же хвастался что страдаешь курсерой, там вроде был курс по машинному обучению от Andy Ng, и базовые вещи для ламеров там рассматривались на примере распознавания рукописных знаков.
базовые вещи для ламеров там рассматривались на примере распознавания рукописных знаков.
пусть ламеры и ходят на эти курсы.
Мне как-то попалась статья, как работает FineReader. Очень даже замечательно, набор эвристик и — словарь языка который распознается.

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

пусть ламеры и ходят на эти курсы.
Ну да, я поэтому тебе и посоветовал.
Словей понагулил, а «слышал звон да не знаешь где он»
С чего ты взял? У меня как раз вполне практические навыки и я их регулярно применяю на реальных задачах.

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

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

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

А с чем по вашему математика имеет дело, как не с интуитивными знаниями?

Примерно сказал:
Знаешь, я думал «data mining» это О-О-О, а оказалось, такое дурацкое и тупое программирование

Собственно любое программирование тупое, даже AI. Вот к примеру теорема байеса, которая в большом количестве используется в data mining, что в ней веселого?
ru.wikipedia.org/.../Теорема_Байеса

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

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

Да, eбаны в рот, математику можно даже встретить в программировании тех же игровых автоматов — типичная задача это подобрать нужное распределение максимизирующее потери игрока.
вот как раз это ПО и доводилось писать. Е*сь в рот дальше, там математика только в — рандомайезере.
крипография, шифрование ( без теор. вера не разобраться )

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

Самое интересное, что многие алгоритмы, разработанные математиками, в том числе и для нас с вами, программистов — придуманы вовсе не «математически» :)
Они потом, математически обосновали свои озарения, доказали что не туфта им взбрендилась. Но часто — туфта, и после лет и лет попытки обоснования сам математик признает — во блин на какие галлюцинации кусок жизни потратил то. С Пуанкаре даже такое было :)

А быстрая сортировка вообще, меня всегда удивляла — ну как такое можно было придумать??? а недавно узнал что:
Алгоритм был придуман Хоаром во время его пребывания в Советском Союзе, где он обучался в Московском университете компьютерному переводу и занимался разработкой русско-английского разговорника.

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

А быстрая сортировка вообще, меня всегда удивляла — ну как такое можно было придумать???
Зато при помощи матаматики можно получить оценку среднего/худшего случая.
А затем, на основе полученных результатов — добавлять различные улучшения.
Или, например, при помощи математики можно доказать нижнюю границу для сортировок сравнением.
Зато при помощи математики можно получить оценку среднего/худшего случая.
уже писал — это можно и без математики :)
А затем, на основе полученных результатов — добавлять различные улучшения.
и это программисты делают — без математики.
Профайлер в руки, расставляй счетчики и кури логи.
Может вы расскажете как математика от этой немалой работы может избавить?

а сами улучшения — поделитесь как придумываются. Ну вот выявиили проблему, математически. А улучшения — как придумываются математически? С удовольствием послушаю.

например, при помощи математики можно доказать нижнюю границу для сортировок сравнением.
С какой — целью? Кому — доказать?
На философском диспуте блеснуть?
Ну этот, который математический?
С какой — целью? Кому — доказать?
Чтобы не искать алгоритм такого типа быстрее. Это мало?

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

То есть, даже если убрать существующие строгие обоснования:
сошлись вот на форуме:
Слышь народ, у меня тута такая вот бяка получается! Кто чё подскажет?
-о-о-о, я несколько дней убил, гонял разные варианты, и вот шо тебе подскажу...

Я предпочту строгое обоснование.

в теме «Оптимизация SQL запросов» поищите. :D

Там все замечательно видно, каким лесом идет математика :)

строгое обоснование.
для табунов сферических коней в энмерном ваккууме.
А когда садишься программировать реальную задачу... ну... поищите, поищите строгое обоснование, а не инженерное шаманство :)

Я знаю как работает b-tree — мне легче понять работу индекса. Математика выходит помогает?

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

не помню чтобы для чтения и понимания алгоритма — мне нужна была математика.

Если, конечно этот алгоритм не является решением математической проблемы.
Но также и алгоритм списания денег и распределения по налоговым счетам вы не поймете, если не прочли хотя бы введение в бух учет.

Я знаю как работает b-tree
я уже писал и об этом, я не вижу не только в его использовании, а в алгоритмах балансировки деревьев — математики.
само дерево — названо деревом по очень простой, совсем не абстрактной причине :D

Но и о — знаете как работает, не буду проверять.
Просто упомяну, что реализация деревьев в БД — немало шаманская и еще дальше от математики — потому что разработчикам приходится думать и об ОЗУ, куда индекс бы должен влезть. И о том — что если не влез, как бы поменьше читать его части с меееедленного носителя.
В БД — ну очень инженерные деревья, в отличие от красивеньких в бесконечных адресных пространствах :)

потому что разработчикам приходится думать и об ОЗУ, куда индекс бы должен влезть.
поэтому там используется b-tree, а не что-то другое. Вы, видимо, не отличаете бинарное дерево от b-tree.
Вы, видимо, не отличаете бинарное дерево от b-tree.
аха.
на том и закончим.
Я знаю как работает b-tree — мне легче понять работу индекса. Математика выходит помогает?
Тебе знание б три мало поможет, т.к. почти везде применяют б+ три, что немного другая штука.

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

вам череп не жмет
нет, все нормально
Профайлер в руки, расставляй счетчики и кури логи.
Ну дурак, нормальному человеку достаточно пары минут чтобы оценить сложность сортировки в худшем и лучшем случае, а сидеть как баран с профайлером чтобы оценить простейший алгоритм, это как минимум пустая трата времени.
Ну дурак
вот спасибо, вот приятно что не нужна мне лоботомия :D
достаточно пары минут чтобы оценить сложность сортировки в худшем и лучшем случае
Справедливости ради — в случае квиксорта средний случай не очевиден (если не знать заранее).
и какая математика описывает предметную область «фейсбука»?

А можно по твитеру, так как по фейсбуку искать долго.
A Big Graph-Processing Library
engineering.twitter.com/...ng-library.html

А можно по твитеру, так как по фейсбуку искать долго.
Можно и по твиттеру.

Только я не понял, что вы мне какую-то частность прислали?

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

повторюсь

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

А сентеции выдавать — дело нехитрое :)

Ну вот, например, граф — понятие из математики. Программист может пользоваться такой абстракцией? Или это бесполезное знание?

вы на лист дерева посмотрите :)
на дельту реки
на вены собственные на руке :)

Программист может пользоваться такой абстракцией?
программист может пользоваться любой абстракцией которая помогает ему делать его работу.
как и любой другой человек, любой другой профессии.
При чем тут — математика?

Я о том, как математика может помогать — например, понятием «граф». Граф может иметь прямое выражение в коде, а может использоваться как абстракция для объяснения работы процесса.

вы не поняли :)

«граф» — это формализованный термин того что присуще человеческому разуму с времен когда по следам охотник выслеживал антилопу :)

а прямое выражение в коде и бухгалтерский счет имеет. И?

а может использоваться как абстракция для объяснения работы процесса.
почему ж нет? Может. Даже иногда, можно и остальные раздумья над графами применить, а не придумывать их по новому. так же как и с закономерностями из теории графов.

Вот только... парочка цитат из википедии:
Проблема четырёх красок — была сформулирована в 1852 году, но неклассическое доказательство получено лишь в 1976 году (достаточно 4-х красок для карты на сфере (плоскости).
...
... еще одна NP полная задача...
К теории графов также относится целый ряд математических проблем, не решенных на сегодняшний день.

а мне сегодня программировать нужно. Заказчику до этих проблем — дела нет. Мне ему сообщить что математика пока не доросла до избавления от — брутфорса, перебора, экспоненциального роста вариантов? Вот уж не подумаю, а займусь нахождением эвристик для задачи. Без математики, а основываясь на ее, задачи, частностях.
Причем, так поступаю не только я. А известные всему миру программисты и коллективы программистов :)

это формализованный термин
ну вот вам пример — математика добавляет общий язык
экспоненциального роста
это понятие видимо из археологии :)
займусь нахождением эвристик
Зная, что не известно более оптимального варианта:) Опять-таки это знание так или иначе пришло из математики:)
ну вот вам пример — математика добавляет общий язык
кому добавляет :)
это понятие видимо из археологии :)
Не понял, погуглил:
Экспоненциальный рост (включая показательный распад, когда темп роста отрицателен) происходит, когда темп роста ценности математической функции пропорционален текущей стоимости функции.
Опять-таки это знание так или иначе пришло из математики:)
Вообще-то, когда программист сталкивается с такой задачей, он и без математики бытенько убеждается что программа то работает, но как-то вот результата от нее дождаться не получается.

А он — нужен. А математик ему важно объясняет — задача не решена в самой математике, в чистых абстракциях.

Замечательно — аванс получен, заказчик ждет, а ему ажно целый математик объяснил что — не решена в математике эта задача. Как и тьма других :)

И шо делать? Какую еще математику привлекать, если она сама сказала — не могу, не умею, не знаю?

кому добавляет :)
например двум взаимодействующим программистам
Не понял, погуглил:
Это был сарказм. Естественно понятие из математики.
без математики бытенько убеждается что программа то работает

И он не сделает попыток найти более оптимальное решение?
Какую еще математику привлекать
Она уже была использована
Экспоненциальный рост

Вот попробуйте объяснить программисту преимущества стрингбилдера перед сложением строк, если он не знает математики. А это понятно на принципе элементарной арифметической прогрессии, школьного курса.

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

а зачем для этого знать математику? это примитивные знания

Это примитивные знания, которые преподаются вроде в 7 или 8 классе на предмете алгебра, но большинство этого не знают. Называется арифметическая прогрессия.

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

Все эвристики подчиняются принципам комбинаторики. И человеку, который знает математику, не нужно объяснять понятия: выделение признаков и построение целевой функции. Конечно знание математики не даст набор эвристик на все случаи жизни, но ускорит перебор эвристик для нахождения оптимальной.

Все эвристики подчиняются принципам комбинаторики.
важно не то чем они объясняются, а КАК они придумываются.
выделение признаков и построение целевой функции.
я еще не встречал людей и даже не слышал — кто так делает.

Даже то что читал о Deep Blue — нанимались шахматисты не ниже гроссмейстера.
И так везде — никакой невежда в предметной области — не выделит в ней ключевые признаки.

Конечно знание математики не даст набор эвристик на все случаи жизни
Привожу определения:

Эвристика (от др.-греч. ευρίσκω (heuristiko), лат. Evrica — «отыскиваю», «открываю») — отрасль знания, изучающая творческое, неосознанное мышление человека.
Эвристика связана с психологией, физиологией высшей нервной деятельности, кибернетикой и другими науками, но сама как наука ещё полностью не сформировалась.
...
Эвристика — эмпирическое правило.

Математика занимается мышлением человека? Или с каких это пор она стала — эмпирической дисциплиной?

В надцатый раз — адепты математики — вы уверены что знаете что такое математика?

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

вы на лист дерева посмотрите :)
на дельту реки
на вены собственные на руке :)

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

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

Вот так заказчик и поставит задание
Ну так у вас же есть мат. модель!
Какие проблемы, разложите по мат модели хотелки заказчика, просчитайте их — и опа, все будет точненько и аккуратненько всем на радость :)
вот только нет четкой формализованности
Матема́тика (от др.-греч. μάθημα — изучение, наука) — наука о структурах, порядке и отношениях, которая исторически сложилась на основе операций подсчёта, измерения и описания форм реальных объектов. Математические объекты создаются путём идеализации свойств реальных или других математических объектов и записи этих свойств на формальном языке.

...и имеет отношение к математике. Не формализовано, но отношение к математике — имеет!

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

тут все просто — любой программист — математик, и любой математик — программист
ибо любая программа — это «функция» выписанная в императивной форме (либо в функциональной, если фп) .

поэтому математика не помогает, но без математического склада ума делать в программеже нечего

я уже тоже не раз спрашивал — что такое «математический склад ума». Ну чтобы хотя про себя выяснить.

Муть какую-то отвечают. психологи — и то поточней говорят.

ну например так — математический склад ума — умение создавать и мыслить абстракциями и их причинно-следственным взаимодействием.

вообще-то это — философский склад ума :D

Как и «здравый смысл» — издревле предмет исследования философии.
Как и вообще — поиски смыслов :)

Перефразируя историю о Диогене:
«Ищу математика!»
Ау-у-у-у!!!!

вообще-то это — философский склад ума :D
ну-ну. философия много времени уделяет иррациональному и не причинно-следственному всякому.

у иррационального — не меньше выделяются и причинно-следственные связи, и иерархичность абстракций.
Рациональные методы просто для этого частенько не пригодны. И с формализацией — проблемы. Поэтому применяется то что можно по бытовому видеть в юриспруденции (она пожалуй самое практичное дитя философии) — используется не аксиоматический набор, не строго выстроенные термины и иерархическое их соотношение, а «пространство понятия».

но вы верно подметили особенность направления философии под названием математика:
Математика занимается только измеряемыми абстракциями. Ее вообще говоря и не волнует является ли некая абстракция рациональной или иррациональной — важно измеряема ли теоретически, имеет ли однозначные отношения с другими абстракциями.

а «пространство понятия».
в математике есть такой подраздел, fuzzy-logic — многомерная-нечеткая логика, как-то так
как-раз и занимается пространствами решений
используется очень активно для описания таких вот нечетких правил.
есть еще стохастика, та много их

там много чего есть. интересного и завлекательного.

например недавно я похоже самостоятельно переоткрыл интуиционистскую логику

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

но стопицот раз согласен с кажется Вейерштрассе
когда тому сказали, что один из его учеников бросил математику и стал известным поэтом:
— Не сомневался. У него всегда было мало фантазии чтобы заниматься математикой.

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

я очень рекомендую пенроуза (не срача для) — тени разума, новый ум короля.

там очень неплохо на тему что может и не может математика (компьютер), а что решается интеллектом , ну и база соответствующая внятно описанная.

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

в результате вы не математику будете критиковать
вообще то я ее и не критиковал :D
речь была о степени ее применимости, полезности в компьютерном программировании.
ваш мозк решает вполне себе мат.задачу
ну да, богословие, там тоже так:
ты чешешь себе затылок, потому что Бог тебе позволил, а то и надоумил нежно. Значит Он — есть, раз ты чешешь себе затылок!

вот такие вы, «адепты математики», даже не философы :)
Ничего личного :)

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

Там немного другое, она всего лишь говорит что под любой факт можно подвести бесконечное множество теорий, в том числе и математических.

Ну тоесть не существует абсолютного интеллекта или абсолютно правильной теории, а есть их бесконечное множество.

какое-то необычное прочтение у вас

Это следствие к вопросу невозможности построения абсолютной и единственной системы формальных правил.

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

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

или абсолютно правильной теории, а есть их бесконечное множество.
Замечательно! Философию где изучали?
торговлю скандибобиками, с учетом заманушек покупателя
работы диллерского отдела

Вот к примеру:
Автоматизированная система оптимизации оптово-розничных продаж мебели на основе нечеткой логики
otherreferats.allbest.ru/...00142794_0.html

Форекс трейдинг вообще на математике весь построен, кто выигрывает на форексе во всяких кластерных анализах и марковских сетях как рыба в воде.

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

Автоматизированная система оптимизации оптово-розничных продаж мебели на основе нечеткой логики
Расскажете кто из известных, успешных мебельщиков стал успешен — благодаря этой, или другой подобной системе?
Форекс трейдинг вообще на математике весь построен
да что вы говорите! :D
математика уже научилась прогнозировать курсы валют???

Черт, стопицот нобелевок вам, и супер-кресло на биржах мира.

А вообще оптимизация матмодели под предметку стоит от 10000$.
ну тогда понятно, почему я без работы не останусь. Стою дешевле делая тож самое :D

Поварился я в машиностроении, читывал, да... до сих пор нет матмодели производства, но люди да, пытаются срубить и иногда получается за «оптимизацию»
Хотя лучше это получается у балаболов бизнес-аналитиков, чем у математиков.
А вся эта «математика с анализом» — выкидывается в корзину после презентации «чудес» и подписания договора, и начинается сооовсем другая работа.
Хотя не, не всегда, хорошие презентации — сохраняются, и для нового клиента туда вписываются цифирки какие он хочет услышать.

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

Не так уж и просто.
Попробуйте-ка опишите программу в стиле f(x1, x2, ... , x100500) = ...
Сломаетесь быстро.
Обратно — как бы гениально математик не описал задачу, комп «не поймет», как ее решать.
Поэтому программирование в некотором роде является движением в обратную сторону от математики.

Попробуйте-ка опишите программу в стиле f(x1, x2, ... , x100500) = ...
Сломаетесь быстро.
хаскель, sql вроде живы

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

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

п.с. у вас разве курса типа «теория алгоритмов» не было ? тьюринг, предикаты все такое ?

п.с. у вас разве курса типа «теория алгоритмов» не было ?
а вы считаете что компьютерная программа алгоритмом и исчерпывается? ;)
как дом — кирпичами из которых он состоит?

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

но там тоже математика или гениальность дизайнера.
мдя, еще один догматик.
Вот уж дизайнеры бы удивились... Они думали что художники немножко, с эстетическим вкусом — а оказывается...

и в MS удивились, мучивши пользователей сотнями — вам так нравится? а вот так? а сяк?
чистая математика!

Существуют эвристические матметоды оценки
забавно, забавно, эвристичиские — матметоды.
Сухая вода да, тоже существует.

Причем здесь это?
Тьюринг-полнота ЯП делает его математическим описанием?
А что тогда делать с не turing-complete вычислительными языками? :)

А что тогда делать с не turing-complete вычислительными языками? :)
Это с какими?

в которых нельзя реализовать бесконечный цикл, типа xslt, sql

Для тьюринговой полноты достаточно три операции — 0, +1, и условную рекурсию, вроде все это есть и в xslt и sql.

там есть серьезная оговорка. SQL тюринг полный только если использовать recursive CTE. А SQL 92 таки не полный, тк там бесконечной рекурсии получается и нет.

угу а я о чем. sql был не полным, но теперь не актуально

www.unidex.com/turing/utm.xsl вот вам Тьюринг машина на xslt и статья о ней :)
www.unidex.com/...m.htm#Obtaining the Universal Turing Machine Stylesheet

гы. у меня глаза вытекли, так что верю на слово
круть

в программировании не нужен математический склад ума, и программирование != математика.

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

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

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

ну дык, кому вообще эта математика нужна? Зачем вообще ее в школе преподают, бесполезная наука.

ого! ничего себе, какие откровения!
то вы просто не умеете её использовать, раз считаете «в бухучете не применяется — значит, бесполезна»
расширю идею. есть куча областей знаний, где математика используется намного более полно. самый яркий пример — физика. еще сходу же — экономика(в частности, статистика там применяется).
есть куча сфер промышленности, которая без математического аппарата — никуда. машиностроение, к примеру. понятно, что для вытачивания на станке не нужно тригонометрию применять, но при конструировании, к примеру, лопатки турбины, очень не лишним будет понимать, как форма влияет на поток жидкости/газа. а математика — для определения оптимальных параметров.
а есть же куча областей, где математика — практически не используется.
например, хирургия, психология, бухучет.

Кроме математики вам еще и незнаком сарказм. Пропащий вы человек. :)

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

Программирование нормально живет и без математики, но действительно охyeнное программирование возможно только при ее использовании.

но действительно охyeнное программирование возможно только при ее использовании.
Цитата:
Чтобы понять, какого рода проблемы ставят наводки перед разработчиками, рассмотрим следующий упрощенный пример: пусть наш e-ink-дисплей имеет разрешение 4×4:
...
Для ответа на ... вопрос следует решить небольшую систему линейных уравнений:
...
Для e-ink-диплея с обычным разрешением (800×600) количество уравнений в системе составит 480 тысяч.
ko.com.ua/...n_slozhno_70079

Так что да, от 480 тысяч линейных уравнений вначале оху*шь, а потом, если жив останешься...
поэтому их не решают и для описанных в статье случаях, а нафик ТАКУЮ математику — и шаманят, и лепят грязные хаки.

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

я уже вас понял, как у истинного верующего все есть Бог, если в Бога верует, и все есть математика, если в математику :)

почему же, не все есть математика. нематематические методы включают:
— угадывание\случайность (притом угадывание чистое, монеткой , а лучше квантовым генератором случайных значений)
— озарение — решил NP задачу без перебора

1)
Еволюційний розвиток бере до уваги математику, чи тупо перебирає варіанти, які виникають під час мутацій і закрпляють в генетичному коді найбільш пристосовані для даних умов?
2)
Математика — лише набір абстракцій, для аналізу і формалізації даних і процесів.
(це щоб людина розумна могла якось розуміти, що відбувається навколо)
3)
Математика не є наукою, так як для неї недоступний експеремент
4) математика лише нструмент для інших наук. Який напрям, така математика, в бухобліці одна, в стохастичних процесах інша, в логіститиці також., у компінженерії ще інша.
Нема єдиної математики, як галузі знань.
Яку математику тре знати?

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

Да проблема не в доу.

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

А эмбедщики — особая категория. Они не понимают, что это у них есть воплощенные в железе сущности — байты, адреса, CPU и GPU и им НЕ нужно их моделировать, а только -работать с ними.
Они не понимают, что у большинства программистов мира нет воплощенных в железе прав пользователя, склада, медикаментов, двутавровой балки, бронирования столика и самого столика, визирования менеджера, ..., ..., и что большинству программистов приходится описывать в коде эти сущности.
Натурально так — не врубаются, что большинство программистов вначале описывает в коде эти сущности, эмулирует, а потом уж начинает писать код чтобы с ними работать.
Они ж не занимаются описанием CPU и его кеша :) вот навыка мыслить абстракциями повыше — и не вырабатывается.

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

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

Как говорится в одной грубой пословице, то что мы(программисты) жуем, математика давно высрала. :)
математика ни сном ни духом о множестве видов работ, которые выполняет программист.
Так что дарю пословицу:
То чем программисты занимаются ежедневно — математика не то что еще в рот не положила, а даже не увидела.
предметные области разные, но фундаментальные принципы везде одинаковые.
И — какие же, эти фундаментальные принципы :) Я вот задумался, и растерялся, если честно. Либо это нечто такое элементарное, что просто — забыл, или оно сгинуло в бессознательном :)
То чем программисты занимаются ежедневно — математика не то что еще в рот не положила, а даже не увидела.

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

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

Не сказал бы, математика это более высокий уровень абстракции чем ООП
Да, однозначно считаю математику — одной из вершин человеческого мышления.
Но, как и апофатическое богословие и буддийская логика — так же оперируют более сложными абстракциями чем ООП — это не означает их полезность для программирования. Как гимнастика для ума — вполне.
Но о математике я уже высказывался в теме «Чему не учат в ВУЗах». Прикидывал даже после более продуманную аргументацию, но получается книга «Что такое компьютерное программирование», минимум за сотню страниц. А значит — большинство программистов ее читать не будет, особенно тему кому стоило бы. Поэтому не буду утруждаться и сейчас, кроме повтора: математику на самом деле большинство программистов не любят, не знают, И не используют. Но она как божество, как культ карго, как талисман — непререкаема для большинства программистов. Перед ней нужно падать ниц, иначе окажется программист один на один — с реальностью. А это, просто по человечески страшно. Вот потому и сотворен такой кумир. Мне не страшно — поэтому мне божок «математика» для работы инженером-программистом не нужен. А кое что — конечно как инженер и использую. Но как на чайник я не молюсь, хотя пользуюсь ежедневно, так и с математикой.
позволяет оптимизировать подходы решения высоко-нагруженных задач.
обычно обходился — разнообразной профилиривкой при стресс-тестировании. Поиском и устранением оверхедов, реорганизацией алгоритмов, или, как привел пример — заменой ОО реализации критически нагруженных сущностей на более близкие к железу.
Можно и — перейти на ассемблерные вставки, или, в случае JVM, реализации на plain C и подключением с помощью JNI/JNA
Математика может от этого избавить? Буду признателен, чтобы впредь не тратить время озвученный выше немалый кусок работы и мыслительной деятельности.
Вот к примеру без математики как вы сможете реализовать задачу, скажем поиска изображений по базе
Каких изображений, в какой базе, по каким критериям?
Не умею ставить «диагноз по фото» :)
поиска названий фирм по базе без единого справочника контрагентов
ну, это то — обычнейшее дело даже когда есть справочник контрагентов.
ООО Солнышко
Солнышко ООО
Солнышко, ООО
«Солнышко»
и еще с десяток вариаций.
Никакой математики не припомню. Набор эвристик — и вперед.
Интересней другая задача, когда юридически контрагенты — разные. А физически — это холдинг.
И нам, для управленческого учета нужно его вычислить, потому что нас интересуют отношения с действующим субъектом,
а не с его головами в виде юр лиц, как у дракона.
И тоже — никакой математики — эмпирические правила в коде.

И тут, буду признателен, если расскажите как математика может решить эту задачу — чтобы не писать перебор.
Я вам даже больше скажу — математика программисту кроме перебора в таких ситуациях — ничего и не предлагает.
Будь это шахматы, контрагенты, и прочее. До эвристик, чтобы бороться с комбинаторным взрывом — приходится доходить собственным умом,
учитывая частности, и кодируя опыт специалистов в предметной области.
И даже великий и могучий Пролог — основан на перебирающей «пролог-машине», и только программист сокращает количество вариантов,
опять же — используя эмпирические данные о задаче.
Не разбирался правда с алгоритмом Rete, что применяется в JBoss Drools. Но, и про него уже известен недостаток — очень память кушает, на той же базе фактов и правил, в отличие от пролог-машины.

Может математика заменить этот труд, а также частенько дорогих(!) экспертов в предметной области?
Так дайте ее сюда! Удешевим и ускорим разработку ПО, с одновременным повышением качества и эффективности программ!

Без математики только обезьянок нанимать чтобы вручную сравнивали и искали.
И это бывало — клиент отказывался от автоматизации, «девочки с трехмесячными курсами бухгалтера» стоят дешевле, а время — терпит.

Повторюсь, мне настолько интересно как математика поможет в упомянутых вопросах, что давайте вообще отдельную тему заведем?
Понимаете, я не могу ни от кого добиться поделиться опытом применения математики в программировании :) не в computer science (честь им хвала, очень полезные знания. Хотя ту же табличку O() для разных алгоритмов сортировки я бы получил просто и тупо — тщательно протестив и сравнив время выполнения — и получил бы те же соотношения эффективности, а может и обнаружил бы эффект кэш мисс, математики как, учитывают что есть у процессора — кэш и его предзагрузка, без затрат тактов CPU? Кстати, как понял алгоритм в нынешнем Питоне, а теперь или скоро и в JDK так и получен — эмпирические размышления, тестирование и экспериментальный подбор коэффициентов. Ссылки на описание не сохранял.
и балансировка деревьев, начиная от красно-черной, до splay — это не математика. Это — интуитивное озарение авторов, а затем — тщательное рассмотрение всех вариантов и алгоритмов действий для каждого. Как в задачке о «3ех взвешиваниях 12ти монет для определения фальшивой». Ни капли математики — перебор всех вариантов)

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

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

у вас некое извращенное понимание математики.
математика это не только какая-то там степенная функция или дробь,
ибо математика — это абстракция реального мира , например любая программа — это уже математика

а любая математика — философия, лол.

но не любая философия — это математика

у вас некое извращенное понимание математики.
да, не ортодоксально догматическое.
Весьма сожалею что в жизни почти не встречал математиков. Очень нравится мне математика.
А вот разбивающие лоб о пол во время молитвы на нее — нет.
Весьма сожалею что в жизни почти не встречал математиков.
в зеркало посмотритесь :)

то что вы не владеете математической теорией , не делает из вас нематематика

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

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

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

покажите мне как ВЫ применяете математику в программировании.

я никак не встречу программиста — применяющего математику.

оптимизация является некоей эвристикой данной сверху,
не слышал — других эвристик :)

Даже, недавно, обсуждали тестовое задание от гугла, и, вполне с приличным математическим багажом программист выдал — эвристическое ее решение :D

просто в виде формул никто не поймет.
недавно я освежал свои знания по «оптимальности раскроя». Формулы, системы уравнений, читаю дальше. Добираемся до программирования этого дела и — ПЕРЕБОР вариантов в коде.
Так на кой черт нужны были эти все формулы, системы уравнений и прочие умничания?

А скажу — ну конечно потому что философам всегда интересно думать. Ну этим, математики которые.
Второе — умная книжка должна быть с мат формулами. Это Хоккинг дурак, специально пишет книжки без формул, а «Умный» должен их вставить, иначе ж — ну несерьезная книга.
Третье — тьма задач давно решается — численными методами. Потому что даже дифференциальное исчисление уже с времен Ньютона уперлось в парочку неразгрызаемых орешков. А спутники то к Юпитеру нужно слать — вот и запускается на годик два программа перебора, на кластере суперкомпов, пока инженеры сам спутник ваяют.
отсюда — 4ое. Многие, и очень многое из матаппарата рассчитано на ручные расчеты. На докомпьютерную эру.

я никак не встречу программиста — применяющего математику.
ну если он написал-понял хоть одну программу — он уже применил математику
язык программирования — это математическая абстракция
программирование — єто выражение реального мира при помощи математической абстракции (языка программирования)
ну и т.д.

численные методы (и перебор) это тоже математические методы

язык программирования — это математическая абстракция
почему — математическая? У вас абстрагированием как способом мышления — математика человека одарила? До этого никак хомо сапиенс не соображал?
Что интересно, эскперементы показывают что и многие животные обладают этой способностью, математике они где обучались?
(языка программирования)
вообще-то — языки программирования — это синтетическая лингвистика. Математики там на грош, поэтому то что сами языки — при сдаче скажем тестов по спеке — «это понять невозможно, а только запомнить», что при использовании... вы программист или ник у вас такой? ну мне рассказывать о том как пишутся компьютерные программы, и почему гуано частенько получается?
... (и перебор) это тоже математические методы
да, да, и когда в туалет хожу, я тоже занимаюсь математикой просчитывая напор струи и динамику его снижения, ну чтобы не мимо унитаза.

не нужно повторяться, я вас прекрасно уже понял :D

P.S.
Каков математик то написал:
Налево пойдешь — коня потеряешь,
Направо пойдешь — жизнь потеряешь,
Прямо пойдешь — жив будешь, да себя позабудешь.

Без математики ну никак бы не допер в сказку такое затруднение богатырю на камне вытесать.

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

Бог! это все — Бог!

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

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

Ну или о том — почему же человек устает когда даже просто стоит?
Не, не думали?

Из того, что и математика и программирование являются способами описания не исходит то, что математика = программирование.
(И кстати, математика != абстракция реального мира).
И уж если совсем строго подходить к вопросу, то программирование — абстракция процессов внутри компьютера, а не реального мира.

И кстати, математика != абстракция реального мира
так народ бросаясь на «защиту математики» (хотя я на нее и не нападал, «святошам» любое слово не по канону — как богохульство и святотатство слышится), не в курсе, что из точных наук она единственная — НЕэмпирическая. Это физики, химики и т.д. строят модели реального мира. И конкретные математики древности и современности иногда этим занимаются. Но сама то область знания — вовсе не об том.

вообще, с «адептами математики» точно как у Ницше:
«Редко встретишь истинно религиозного в храме». По другому — не спрашивай бабульку в храме о Боге, она тебе таааакого понаговорит.

Так вот и с рьяными защитниками математиками. В отличие от самих математиков, светлейших и острейших умов обычно.

И уж если совсем строго подходить к вопросу, то программирование — абстракция процессов внутри компьютера, а не реального мира.
если строго то программирование это преобразование абстракций реального мира в абстракции яп , а уж яп в свою очередь является абстракцией внутренностей компа
а уж яп в свою очередь является абстракцией внутренностей компа
в общем случае — не является :D
Ни Lisp, ни Haskell, ни Prolog, :)

самое замечательное что и не — обязаны, поэтому ЯП развиваются в сторону человека — а не компьютера.

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

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

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

Та даже вона, эмдедщики, электронщики троллят. Вы думаете только в этой теме?

Проблемка только в том, что вся история программирования мне видится как все бОльшее удаление от математики :)

в общем случае — не является :D
Ни Lisp, ни Haskell, ни Prolog, :)
ой ли ? тогда программы на них не смогли бы запуститься на компе впринципе.
попробуйте стихи скомпилить\запустить :)
Программирование по сути — не математическая задача
я вам пенроуза уже советовал. рекомендую. без понимания прикладного смысла второй теоремы геделя вам будет сложно изъяснятся
ой ли ?
ну, я конечно не так молод, чтобы знать все, просто немножко интересовался устройством компьютера.
Там ни списков, ни синтаксических деревьев, ни предикатов — нету.

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

Японцы убухали денег — пытаясь Prolog-машину в железе воплотить.
Но конечно, вам то уж точно все понятней ;)

тогда программы на них не смогли бы
да, да, если б не Бог — не почесать мне затылок никак. стопицот процентов согласия!
я вам пенроуза уже советовал.
Мне он известен давно. Отрывки читал, и отложил. список прочтенной аналогичной литературы потому что у меня немаленький.
без понимания прикладного смысла второй теоремы
вы с компьютером разобрались вначале, как это он умудряется буковки из ЯП выполнять.
Какой там гедель с пенроузом :D
Ни Lisp, ни Haskell, ни Prolog, :)
самое замечательное что и не — обязаны, поэтому ЯП развиваются в сторону человека — а не компьютера.

Так ведь критиканы ООП должны при упоминании этих языков кровью харкать, потому что всё, что здесь вменяется в недостатки ООП, в них множится на 10.

Низкоуровневая оптимизация в Haskell? Нет, не слышал...
Саппортабельность программы на Lisp? Whaat?

Так ведь критиканы ООП должны
дык для этого либо IQ, либо душевное расстройство нужно полечить :)

но мой список был не об том, не о саппортабельности и прочем :)
А о том что обычно в ЯП нетути абстракций железа, за исключением ассемблера, немножко в Си, и некоторых типов данных в Java и C# и прочих :)

если строго то программирование это преобразование абстракций реального мира в абстракции яп

Только в частных случаях.
А если стоит задача сделать «сайт по продаже пиццы», то о каких абстракциях реального мира идет речь?

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

Так ведь в реальном мире нет ни «конструкторов пицц», ни «заказов». Как сущностей. Зато есть повар, продукты, развозчик пиццы и тараканы на кухне.
Так что в абстракции реального мира присутствовали бы классы Cook, Сourier, Pizza как контейнер объектов Tomato, Cheese и over 9000 других, а также классы Cockroaches ( Cook.Kill(Cocroaches[] targets) ) .
Ничего подобного в этой задаче нет.
Есть описание требуемого от вычислительной системы результата, получаемого путем интеракций с пользователем. Все.

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

Обратный от абстрагирования процесс хорошо отражен в дзен-изречении:
Когда ты смотришь на дерево, ты видишь дерево, или у тебя в уме всплывает — «вот, это дерево»?

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

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

Мне дом нужен а не вот это кодло!

Не очень-то понял аналогию. Но дом — это в любом случае не модель «хорошей жизни».

Моя идея в том, что при программировании «магазина пиццы» не нужно строить матмодель физического магазина
да, согласен. особенно в случае когда ее и нет.

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

что веб-магазины являются моделью магазинов физического мира,
тут да, вообще интересны возможности программирования.
Первый этап — тупо кодируем все как есть в реальности. То бишь получается — «дублируем»
а вот второй то — даем такой инструмент, который позволяет изменить эту реальность. избавиться от некоторых вещей в ней. реорганизовать деятельность.
Не очень-то понял аналогию.
та и ладно, не суть она важна была :)

сайт, продажа, пицца :)
вот об этих :)

Сергей видимо не встречал программистов того, что связано с 3д графикой. :) Да им не нужна математика ни разу. ;)

Я не буду спорить и доказывать, скажу лишь, что программирование вообще-то вышло с математике(вроде как очевидный факт). К примеру, типы в программировании спросите вы? Все это давно уже было формализировано в Теории Категорий.

Ну и понятие Алгоритм было формализовано и развито математиками, когда математики занялись в плотную проблемами вычеслений.

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

Математика не избавляет ни от чего в программировании — к примеру, она может помочь оценить эффективность того или иного метода до того как вы его реализуете.

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

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

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

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

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

вообще-то математика и занимается по большей мере эвристичными задачами.
она не может ими заниматься по ОПРЕДЕЛЕНИЮ
ну без обид, ну осильте хотя бы определения в википедии.

Ну методология математического анализа так устроена — никакой эмпирики, никаких «карт на руках», а только — все фигуры на доске, и тогда и только тогда.

Математика НЕ является естественной наукой. какие еще эвристические задачи??

Теории Категорий.
Аристотель.
Ну и сейчас этими проблемами занимается реляционная алгебра.
гы. вообще-то в SQL — множество вещей — нереализовано. :)
И кроме теории, там множество презабавных штучек типа управления индексами. Ни в какой такой теории множеств индексов нету. :) И порядка вычислений — нету в теории множеств.
Вопрос для собеседования — GROUP BY и HAVING BY — в чем отличия? По теории — никаких существенных. По тому как в действительности выполняется запрос -... ;)
Рекурсия кстати тоже давно была известна математикам.
Рекурсия известна и высшим и приматам, и врановым.
Не надо приписывать математике функции Бога-Творца.

Называется пукнул в лужу. :) Функции «бога-творца» лол, что. Православие головного мозга? Никто не молится на математику, ты путаешь боже с праведным, говоришь о практике в то время как математика это теория, спорим о шкафах, когда речь о молотке. :)

Рекурсия кстати тоже давно была известна математикам.
а еще давнее животным. они тоже математики?
как математика это теория
теория ап чем?
Огласите предмет изучения.
как математика это теория
у меня, просто обязательно :D
это все знают какой я упоротый ортодокс :D

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

Тебя уже ничего не спасет.
ну чего ж, лоботомия вполне :D
К примеру, типы в программировании спросите вы? Все это давно уже было формализировано в Теории Категорий.
окей. а слова, которые, вдруг, использует ЯП для записи кода, изучаются и анализируются лингвистикой. значит, программирование — немного лингвистика.
а уж скопилированный код «выполняется» в виде последовательности электромагнитных импульсов, преобразуемых логикой интегральных схем. значит, программирование — немного электроника, микросхемотехника и уж всяко — физика.
а дело в том, что без знания математики мы изобретаем каждый раз велосипеды
ага, а без знания предметной области невозможно оптимизировать даже «математический алгоритм», если, к примеру, программисту не известны ограничения на входные данные.
если математика позволяет анализировать алгоритм — это еще не значит, что алгоритмика — раздел математики. точно так же, как применимость статического анализа в экономике не означает, что экономика — частный случай статистики.

в дополнение:
Почему студенты, изучающие вычислительную технику, должны изучать экономику? Потому что тот программист, который понимает основы бизнеса, будет более ценным программистом для бизнеса, чем тот программист, который их не понимает. И это всё. Я даже не могу назвать сколько раз я был в замешательстве, от выдвигаемых программистами сумасшедших идей, которые имели смысл в коде, но не имели никакого смысла в капитализме. Если Вы понимаете всю эту кухню, то Вы — более ценный программист, и Вы будете за это вознаграждены, по причинам, которые Вы узнаете, если возьметесь изучать микроэкономику.
...
вычислительная техника (computer science) — это не то же самое, что разработка программного обеспечения. Если Вам действительно очень повезет, институт может иметь достойный курс разработки программ, хотя, скорее всего этого не будет, потому что элитные школы думают, что обучение практическим навыкам лучше оставить професионально-техническим училищам и тюремным реабилитационным программам. Вы можете изучить море программирования везде. Мы — Йельский Университет, мы Формируем Будущих Лидеров Мира. Вы думаете, что Ваша $160000 плата за обучение дает вам право изучать циклы while? Вы думаете, что мы здесь, безответственный Java-семинар в гостинице Marriott в аэропорту? Фи!
Беда в том что у нас нет профессиональных школ по разработке программного обеспечения, поэтому, если Вы хотите быть программистом, то Вашей профилирующей дисциплиной, вероятно, является вычислительная техника. Это отличное высшее образование, но это другой предмет, это не разработка программ.
Joel Spolsky Совет студентам изучающим вычислительную технику

Разработка программного обеспечения != программирование. Потому что это куда более комплексная проблема. Ведь важно не только запрограммировать, а еще и правильно спроектировать.

Лингвистика использует математику(язык базируется на алфавите и состоит из объединений множеств комбинаций алфавита, что можно записать как если S = {a,b,c...}, то язык это S’=S1′ U S2 ’U S3’...S’n), физика так вообще без математики невозможна. Теория алгоритмов вообще-то раздел математики.

Тут он Сергей говорил, что оптимизирует асмовыми вставками, когда известно, что это последнее что нужно делать при оптимизации. Я сам с таким сталкивался, у нас кусок игры тормозил при определенных проверках(unity3D c#), там уже программист городил приколы в стиле Сергея, подгрузка C библиотек и прочего, когда простая замена алгоритма проверок ускорила программу на несколько порядков.

Лингвистика использует математику
«использует» и «является» — совсем не одно и то же. ну, почему же в который раз одно подменяется другим?
физика так вообще без математики невозможна
история астрономии смеется над подобным заявлением.
когда простая замена алгоритма проверок ускорила программу на несколько порядков
отлично! математика помогла вывести новый алгоритм?

Ембедщик который считает что его умения манипулировать битами, знания о прерываниях портах, и прочитанный Intel Architectures Software Developer Manual это что-то фундаментальное и супер крутое являет собой еще более жалкое зрелище чем джавист который понтуется знанием EJB и Hibernate.

та лан. годная тема. я успел за оба лагеря выступить , гг

А я постоять в сторонке и насмеяться вдоволь от уместного троллинга. =]

Кстати да, был сегодня в оушен плазе, а там народу в этом KFC звездонутся просто. Макдональдс столько давно не видел.
С чем я тебя и поздровляю.

Ну хватит уже петросянить по поводу совпадения названий. Не уподобляйся велосипедисту.

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

Это не назовешь здоровой пищей, но иногда когда хочется жесткого фастфуда вполне Ок, но ИМХО оно сливает en.wikipedia.org/...uisiana_Kitchen по полной.

я там недавно был, травонулся на 2 дня. Больше туда не ногой. При том, что я ем табаско спокойно, мой желудок не потянул местные острые крыльца. :)

Так табаско ведь слабенький. Кайенский перец сильнее около 7-10 раз по остроте чем табаско habanero. Попробуйте на досуге соус из красного амазонского перца в такой же бутылочке, как и табаско :)

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

Это тот соус, в котором рекурсивный рецепт :) ?
Hot Sauce — Ingredients: Water, Hot Sauce.

Как на мой вкус они где-то равны по остроте.

так табаско ж кислющ. Из мощных соусов помню был «100% pain»

А еще лучше — перчик пили-пили. И жизнь вам покажецца адом.

ООП как способ организации кода и собственно логики в приложении прижился прекрасно. Да, он не является панацеей, но в рамках систем больших чем встроенные он явно побеждает как минимум процедурный подход. Если теперь сравнивать с ФП, то ФП имеет безусловно свои плюсы, но я подозреваю ентерпрайз софт будет трудновато написать используя чисто ФП подходы — все равно стейт где — то хранить придется. А где стейт — там или монады или ООП. От монад у ентерпрайз синьоров глаза на лоб лезут, остается только ООП.

Действительно ООП как он был описан в 80х в чистом виде имеет много изъянов. Есть мнение, что DDD — это улучшенный и модернизированный ООП, где глагол (действие) выходит на должное место, таким образом подход перенимает некоторые свойства функционального программирования, пусть и не всегда так приятно как хотелось бы в языках типа Java. Вообще, как говорят тут умные люди — главное это квалификация, а парадигмы они все важны и полезны примененные к месту. Мультипарадигменность рулит.

DDD, если почитать его описание — это паттернизированный генератор врапперов, такой себе ООПокалипсец — к DOD не имеет ни малейшего отношения.

к DOD не имеет ни малейшего отношения.
Уже не забавно.

Да ну? Перепутать DDD и DOD? :)

дод не слишком известен в широких кругах.
А ддд какраз потихонечку рекламируется.

та троллит он нас, и вполне успешно при том :)

та троллит он нас
Вот это неожиданный, но яркий поворот этой дискуссии.
Начиная отвечать по теме я надеялся наглядно показать публике подход, который а) выигрывает у ООП б) предотвращает ООПные фейлы, в) крайне мало кому знаком, хотя и вполне логически очевиден.
Я подобным подходом подобным ДОД бользовался давно интуитивно, и лишь в попытках объяснить фейлерам причины из фейла полез искать и нашёл ДОД,
а) выигрывает у ООП
Ваапшета параллелен ООП. Его вполне можно применять как внутреннюю архитектуру.
б) предотвращает ООПные фейлы
Фейлы или «перформенс-фейлы»?
в) крайне мало кому знаком,
И бросив просто аббревиатуру вы сделали его мегапопулярным? Куда более эффективным было бы или дать ссылку (раз уж вы знали что подход малоизвестный), или хоть написать полное название.
Ваапшета параллелен ООП. Его вполне можно применять как внутреннюю архитектуру.
Ещё раз — нет.
Я уже объяснял всё предельно просто и подробно, раза три здесь в ветке. Вы не дочитали? Не поняли? Блин, блин, блин. Я в ступоре. Я могу это сделать ещё раз, но такое ощущение, как будто объясняешь меметику сандеисту.
Фейлы или «перформенс-фейлы»?
Не просто «перформенс-фейлы», а такие фейлы, когда оверхед вызванный а) любовью к ООП и б) полным игнорированием производительности — становится таким, что вся затея кончается фейлом — фейлом (суб)проекта, увольнением фейлеров, переделыванием всего заново.
Куда более эффективным было бы или дать ссылку
Блин блин блин — 2.
Здесь в теме этих ссылок — ну штук пять...
Вы не дочитали?
Конкретно в этой ветке не было. В других и не смотрел.
Повторяю:
Если ваша первоначальная цель была
я надеялся наглядно показать публике подход
то «нэ залык», по описанным мною причинам ( + вы еще первые комменты отвечали «погугли»)
Не просто «перформенс-фейлы», а такие фейлы, когда оверхед вызванный а) любовью к ООП и б) полным игнорированием производительности
А ну-ка, какое первое правило оптимизации?
Более подробно:
Какие проблемы вызывает «любовь к ООП»? В теме на 600 комментов аргументов не особо-то. Даже заезженная мутабольность — это не столько проблема ООП, сколько конкретных людей.
б) полным игнорированием производительности
А ООП требует этого?
Конкретно в этой ветке не было.
Было. Но расписал ещё раз, вот чуть ниже. dou.ua/...comments#280028

ок, то есть сам используешь типа DOD? Как долго, в чем мощь и в чем слабости? Какая индустрия? Введение для новичков. Своими словами. Можно отдельным топиком. Ссылки не очень интересны и как-то все больше вокруг гейминга.

а) выигрывает у ООП
как уже тут было сказано, DOD — это не парадигма. Это просто техника. Ее применение никак не противоречит ООП. По крайней мере по краткому просмотру ссылок приведенных.
ок, то есть сам используешь типа DOD? Как долго, в чем мощь и в чем слабости? Какая индустрия? Введение для новичков. Своими словами.
Окей, это уже не в первый раз, но сделаю над собой усилие.
DOD — моделирование системы исходя из потоков данных. Именно «моделирование», так как подход может быть использован как для синтеза, так и для анализа системы, её архитектуры. И, более того, синтез архитектуры — это итерационный процесс, когда каждая попытка синтеза проходит через анализ, для выявления несостоятельности-неэффективности-боттлеков-и-др-фейлов, и после анализа итерация повторяется.
Любая информационная система может быть представлена как набор потоков данных и оброаботчики на их пути. Клиент-сервер — два «кубика» и два потока между ними. MVC — три кубика и потоки.
Может показаться, что такой подход порождает «плоскую» структуру, в которой отсутствует иерархия, однако, каждый «кубик» имеет внутреннюю структуру, с внутренними обработчиками и внутренними потоками данных.
Очевидно, что этот подход близок к электронике, однако программные системы моделируются им столь же успешно.
Даже если система спроектирована с помощью ООД, её можно «перерисовать» и по ДОД, и тогда становятся ясны некоторые интересные вещи, а именно
— где ООД модель добавляет ненужные сущности
— где есть потоки данных и ботлнеки в них.
Вот как то так.
ЗЫ. Синтез архитектуры с помощью ДОД интересен тем, что крайне трудно добавить ненужные сущности — один обработчик — один «кубик», и ненужные потоки данных — избыточность сразу видна.

Не впечетлило. Эти самые «лишние» сущности, как правило, служат для уменьшения связности, что в свою очередь приводит к уменьшению сложности системмы и её сопровождения. Если «лишние» сущности к этому не приводят — значит системма спроектированна неверно, но ООД тут не причём.

За разъяснение спасибо. Хотя особенно не видно почему это противоречит ООП в сути. Согласен с другими участниками дискусии в том, что те же результаты можно получить и грамотным ООП.

Так это не «альтернатива» ООП. Это скорей как альтернатива ДДД.
При проэктировании с использованием ДДД — максимально ориентируемся на предметную область.
При проэктировании на ДОД — максимально ориентируемся на потоки данных.
Причем оба этих подхода могут быть использованы как с ООП парадигмой, так и с любой другой.

да с кем вы спорите :) он говорит, что архитектура в ДДД развалится при малейшем изменении требований заказчика и как альтернативу предлагае ДОД

ну и ДДД без ООП как-то сложно представить

Все имеют право на заблуждение

Плохо это не когда ООП, плохо это когда вместо разработчика — обезьяна в одежде, методология превращена в религию, а парадигма в набор догматов.
Умный (или мудрый) человек в большинстве случаев наинженерит рациональное решение используя тот подход, методы и оценивая свою работу по тем критериям которые посчитает целесообразными в данной ситуации, в то же время дурак будет пускать слюни на всякие аббревиатуры будь-то KFC, DOD, RUP, SCRUM, DESIGN PATTERNS, MONAD TRANSFORMERS и т.д. высирая очередное SCALABLE ROBOUST COHERENT ENTERPRISE DECISION, а потом пойдет на ДЕЙЛИ-СТЕНДАП на котором выскажет свой КОНСЕРН ПО ПОВОДУ ПЕРФОРМАНС ИШШЮЗ. Но, итог всего этого безобразия далек от положительного.

p.s. Во избежание злобных комментариев от агрессивных буратин, хочу заметить что моя позиция по отношению к тому же скраму или паттернам не является негативистской, все это имеет свое место и право на жизнь, при определенных условиях. Плохо, я отношусь к «кадрам» сакрализирующим данные знания и не способным к аналитическому их осмыслению, например в итоге получаем вместо разумного и обоснованного их использования, карго культ.

Да все споры в интернете по технологиям, яп, и даже женам из филлипин — один сплошной карго культ.

Насправді просто дивує холівар якому без маленького вже років 70...
Були спочатку комбінаційні схеми, які могли здійснювати обчислення, більш складне обчислення — більш велика (в просторі) комбінаційна схема, інше обчислення — інша в просторі комбінаційна схема..Потім з’явилася пара інженерів з Нейманом з боку і о чудо- з’явилася ЕОМ з програмним управлінням — комбінаційна схема з пам’яттю (станом) — а насправді та сама схема тільки з комутаціями в часі а не на платі, ще трохи пізніше (1970) стара ідея комбінаційної схеми в новій обгортці оформилася в Dataflow architecture (правда, щось нагадує ?)

Будьте певні, що в 40-х були «чувачки» з тестерами в руках які говорили — Що от «пофіксати» комбінаційну схему їм ну, що два пальці — а ось той новий апарат з якимись регістрами і комірками ну ніяк (бо те що в ньому відбувається визначається в великій мірі рантаймом)...

В 70-80 з об’ємами пам’яті в кіло байти, сотні кілобайт цілком вистачало структурного програмування, з подальшим ростом можливостей машин природнім розвитком структурного програмування стало ООП, не існує ніякого непереборного антагонізму між ООП і структурним програмуванням, окрім одного — код написаний (РОЗУМНО) в рамках ООП парадигми простіше писати, читати і просто втримати в голові. Далі — пам’ять вимірюється гігабайтами — чому б знов не побавитись з комбінаційними схемами (ФП) і DOD (Dataflow architecture) і тд...

Насправді є величезне різноманіття самих різних задач — в межах кожної з них є корисні не дуже моделі предметної області (корисність — дуже широке поняття — починається з бюджету, баченням майбутньої еволюції системи і закінчуючи бажанням попрактикуватися в новій технології) — під конкретну модель можна використати і ФП і DOD і ООП (хоча навіть цей перелік не є переліком якихось протилежних альтернатив)

может быть хотя бы вы расшифруете аббревиатуру DOD?

під конкретну модель можна використати і ФП і DOD і ООП
Згоден, професіонал обере з наявних методологiй та инстументiв той який буде найбiльш привабливий йому, за якимись критерiями, будь це хоча б
бажанням попрактикуватися в новій технології
або бюджет.

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

Для каждой задачи есть свои подохы. Есть где нужен ООП, но есть и те где нужен функиональный язык, АОП и многое другое.. Решать все задачи исходят от одного знания это низкий профессионализм и не более.

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

Простите, но пользователям крайне редко нужно лезть и понимать код...

Забыли самый главный аргумент в пользу С — ОН ТЕПЛЫЙ И ЛАМПОВЫЙ. И ниипет.

Можете ще спитати у товариша
— Приклади проектів (гарних і живих) — з використанням множинного віртуального наслідування
— Технологію дебагу коду з солідним використанням темплейтів (особливо якщо багато переозначень операторів)

Думаю він вас відправить далеко гуляти і ваш спор закінчиться :)

boost и stl это не ооп, во всяком случае внутри них наследование практически не применяется. вобще программирование на современном с++ предполагает куда меньшее использование парадигм ооп чем было раньше, в основном из за того, что честный полиморфизм удобней чем subtype

как тут офигенно смешалось "проектирование-дизайн"(разработка архитектуры, анализ требований) и "программирование"(как имплементация предыдущих двух в коде).
OOProgramming vs DODesign
а, давайте, еще компиляторов в обсуждении добавим?

Компиляторов? М-м-м, ну давайте компиляторы обсуждать
GCC now uses C++ as its implementation language [2012-08-14]
gcc.gnu.org/.../cxx-conversion

(перепост)
UML направляется в Лету: www.itjobswatch.co.uk/jobs/uk/uml.do
ООП как правило вреден. Например вот одно неплохое объяснение: thread.gmane.org/...643/focus=57918
и ещё www.devx.com/...icle/26776/1954
Вкратце: Раскладка методов по классам — как правило хорошо, хоть и не всегда. Но в реале ООП наращивает непредметную сложность, снижает эффективность, снижает маинтайнабельность и реюзабельность — в противоположность заявленным целям.
Паттерны — апофеоз фанатичного, карго-культного ООП. Даже не читал критику, видел лишь несколько гранд фаилур.
Противоположность ООП — Data Oriented Design.
www.asawicki.info/...d_thoughts.html
research.scee.net/...ing_GCAP_09.pdf
Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной, если с рисования иерархий классов — нет. А если с первых строк начинают фигурировать словечки типа обджект фектори и синглетон — запасайтей попкорном, будет эпик фейл.

UML направляется в Лету: www.itjobswatch.co.uk/jobs/uk/uml.do
ООП как правило вреден. Например вот одно неплохое объяснение: thread.gmane.org/...643/focus=57918
и ещё www.devx.com/...icle/26776/1954
Вкратце: Раскладка методов по классам — как правило хорошо, хоть и не всегда. Но в реале ООП наращивает непредметную сложность, снижает эффективность, снижает маинтайнабельность и реюзабельность — в противоположность заявленным целям.
Паттерны — апофеоз фанатичного, карго-культного ООП. Даже не читал критику, видел лишь несколько гранд фаилур.
Очевидно по всем пунктам дело в прямоте рук а не в ООП.
Противоположность ООП — Data Oriented Design.
www.asawicki.info/...d_thoughts.html
research.scee.net/...ing_GCAP_09.pdf
Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной, если с рисования иерархий классов — нет. А если с первых строк начинают фигурировать словечки типа обджект фектори и синглетон — запасайтей попкорном, будет эпик фейл.
Все равно это сливает перед KFC.
Все равно это сливает перед KFC
— Kill the Fucked Coder
— Krazzy Fucking Coding
— Kudos, Fucking Coder!
В любом варианте написания — сливает однозначно. LOL
В любом варианте написания — сливает однозначно. LOL
очевидно от пейсателя зависит

От борцов с реальностью — всего можно ожидать... о_О

Но в реале ООП наращивает непредметную сложность, снижает эффективность, снижает маинтайнабельность и реюзабельность — в противоположность заявленным целям.
я только одного не пойму — а что все вот это — наращивает??? ассемблер? «plain C»? «LISP»??
Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной
Это какой системы? «Продаются чайники, красненькие и беленькие. На беленькие скидка!» Нарисуйте потоки данных. Да так чтобы потом, когда начнут продаваться и кастрюли, и скидки рождественские появятся — такое представление модели (в потоках данных) не пришлось все выбросить, и не начинать все с начала. А придется — потому что моделирование в потоках данных — это даже не способ проектирования. Это описание модели некоторых внутренних задач ИТ. будь потоки идущие через «киску», или потоки идущие от NY биржи.
А если с первых строк начинают фигурировать словечки типа обджект фектори и синглетон — запасайтей попкорном, будет эпик фейл.
Я вот уж какой год не пойму, таких тезисов:
Немеряно ПО написано именно с ООП, сикось или накось, но — «эпик фейл»

Это примерно как:
Если бы у людей были крылья и они были бессмертны, то да, есть шанс на счастливое человечество. Но так как люди смертны и о двух ногах и руках только — все, эпик фейл

Ну ей Богу Ярослав, критики ООП частенько вот такое и говорят. Что наводит даже не размышление об их IQ, а о каком-то душевном расстройстве, какой глубокой мировой скорби такой силы — что живя в мире ООП — они его не видят. в упор. Что оно — кругом. Годами работает, обрастает фичами, и все равно — работает.

Сравнивать DOD и ООП в пользу первого — эквивалент утверждения «Ford Focus лучше грузовиков», сравнение частного подхода и класса. Да, в конкретном классе задач лучше, но на дереве парадигм программирования это не один уровень.

Сравнивать DOD и ООП в пользу первого — эквивалент утверждения «Ford Focus лучше грузовиков»,
АШЫПКА.
И DOD и OOD — подходы анализа/моделирования/синтеза архитектуры.
Различия же между OOD и OOP — лежат вне скоупа нашего холивара.

Тема про ооП, тим не менш у всіх коментах Ви протиставляєте доД ооП. Потім Ваш колега приплів KFC — взагалі інший рівень як з’ясувалось :)

Не, в скоупе холивара лежит как раз ООП, а не ООД. Это даже в названии темы написано и все равно умудрились попутать.

Но в реале ООП наращивает непредметную сложность, снижает эффективность, снижает маинтайнабельность и реюзабельность

...

И DOD и OOD — подходы анализа/моделирования/синтеза архитектуры.

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

И DOD и OOD — подходы анализа/моделирования/синтеза архитектуры.
... и в качестве таковых спокойно могут сосуществовать в одном проекте, я подозреваю... ;)
Более того, дополняют друг друга. ООД стремится к красоте, ДОД — к успеху проекта, грубо говоря. :)
ДОД не даёт ООДу зациклится на генерации ненужных сущностей и проигнорировать данные как таковые, ООД... ну, присутствует, как неизбежное зло, даже трудно себе представить что-то без него. ;)
Data Oriented Design.
Посмотрел презентации.

Это конечно... как бы это...

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

Но что интересно, там же в одной ссылке написано:
Object Oriented Programming is a methodology, a design principle, programming paradigm, a concept, a practice, etc. It is not a language!

То есть я не понял — а кто, что мешает и сейчас иногда думать о байтах и кеше процессора? Как в моем примере. DOD — это всего лишь — «а давайте иногда думать», а не — замена OOD. Это всего лишь — низкоуровневый тюнинг алгоритмов при кодировании.

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

И там то да, ох смертельная критика ООП:
virtual functions are slow when iterating over large collections of heterogeneous types because of cache misses

Вот только геймдевом мир программирования не ограничивается. И бывает, не поверите — когда есть мноооого но маленьких коллекций, и порядок их обработки зависит НЕ от программиста. И программист не может задать его на этапе разработки.
И гигабайты из БД в кеш процессора — тоже как-то вот, честное слово, бывает не запихнешь. Даже всю БД в ОЗУ поднять — ну вот чего-то — не получается.

А так Ярослав, да, все сходится, смерть ООП близка, в лице DOD!
;)

Посмотрел презентации.
Это конечно... как бы это...
Идея вобщем такая:
забудем про реальный мир!
Ведь у нас нет ничего кроме байт и — кеша процессора! Вот главное о чем нужно думать!
Меня всегда удивляло, зачем люди делают неэффективные программы, ЗАЧЕМ? Ведь для создания оверхеда надо приложить дополнительные усилия, и, более того, если эффективный алгоритм логичен и самоочевиден, то для построения неэффективного алгоритма нужно применить некий креативный идиотизм, или даже целенаправленно внести в программу вредоносный код, который её замедляет...
:)
ЗЫ. Но недавно я встретил взрослого опытного синьора, который не знает, какова вычислительная сложность алгоритмов поиска по массиву, и в чём разница в поиске по сортированному и несортированному массиву, и какая вычислительная сложность у алгоритмов быстрой сортировки и сортировки пузырьком. Я БЫЛ В ПОЛНОМ АУТЕ! ОО
И теперь, внимание, ВОПРОС: А знаете ли Вы, Сергей, какова вычислительная сложность перечисленных алгоритмов, и вообще — что такое вычислительная сложность (algorithmic complexity)?
для построения неэффективного алгоритма нужно применить некий креативный и-ди-отизм
Каргокульт у виконанні ініціативного і-ді-ота.
В ІТ все ті ж самі люди. Більшість з них в щось мають вірити, щоб мати точку опори, то в Бога, то в те що його нема, то в ООП...
Для прихильності богів тре виконувати певні дії, які прийшли до них часів від попередників.
Мало хто візьме сміливість критично осмислити «традицію» і не бути єретиком.
Крім того, у випадку фейла — можна зслатися на те, що все зроблено по уставу. І що винні форсмажор і нештатні ситуації які не передбачені ООП і на яких не знайшлолся патерна, тому я не винен.

Жестоко. Но неистово плюсую! :)

>1) На чистом С код быстрее

Размещение данных в памяти можно контроллировать одинаково точно как на C так и на C++. Алгоритмы разрабатываются на фактически одном и том же языке. Откуда у C могут взяться превосходства в скорости?

>2) На самом деле код С++ нифига не портируется так просто (ну это отдельно про с++)

Портирование — это абстрагирование системных сервисов. Поддержка абстрагирования — суть C++/OOP. По импликации получаем что C++/OOP лучше подходят для такой задачи.

>3) Библиотеки например Boost непроизводителны, так как дают слишком много удобной абстракции

Почти все абстракции в boost — header-only. Все policy, etc применяются при компилации, и в конечном коде присутствует только то, что нужно для конкретно вашего использования boost. Компилятор имеет все возможности оптимизировать код так как он весь доступен при компиляции каждого object file. В результате время компиляции довольно большое, но нет никаких причин для того, чтобы результирующий код был менее производителен, чем одноразовая ручная реализация аналогичной специализации на C/C++. Иными словами:

— на «чистом» C или C++ ты будешь тратить время на реализацию своих контейнеров и алгоритмов
— с boost ты будешь специализировать только то что тебе нужно из базовых абстракций и тратить время на a) написание специализации (policy) b) время компиляции.

Есть масса разработчиков для которых второй путь (boost) займёт больше времени чем первый из-за отсутсвия опыта или низкого iq.

>4) ООП слишком далеко от реального представления информации

В сравнении с чем? C-шными структуракми, макросами и функциями типа «widget_x_handle_right_mouse_click_with_alt_depressed(..)» ?

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

* Ничто меня не обязывает использовать позднее связывание при реализации критичного кода. Пример сложнейшей абстракции без единого виртуального метода: std::shared_ptr.
* Никакой сложный проект не обходится без абстрагирования.
* Любые попытки реализации абстракций в C приводят к использованию function pointers, switch-like диспатчерам, macros и тд.
* Позднее связывание в C++ было реализовано как один из базовых элементов абстрагирования поведения объектов, оно чище и эффективней чем C-шные дикости из предыдущего пункта.

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

Пара вопросов:
1. А, что собственно страшного в этом позднем связывании?
2. И самое главное. Как Вы думаете можно-ли те задачи для которых оно нужно решить на C эффективнее?

1. А, что собственно страшного в этом позднем связывании?
vptr. Переход на виртуальную таблицу и вызов конкретного метода очень часто заканчиваются кэш-миссами. На РС, где out of order, это не так страшно. Но, к примеру, консоли текущего поколения, являются in order и там такие вещи куда сильнее сказываются
2. И самое главное. Как Вы думаете можно-ли те задачи для которых оно нужно решить на C эффективнее?
Может, стоит решить эти вещи и на С++, но без виртуальных функций? В множестве случаев можно избавиться от интерфейсов, абстракций и т.д. никак не навредив читаемости, понимаемости и гибкости кода
vptr. Переход на виртуальную таблицу и вызов конкретного метода очень часто заканчиваются кэш-миссами.
Да вы правы, с «часто» не поспоришь. Ведь кто его знает что-такое, к примеру 6%, это всего-лишь 6% или целых 6% :)
Может, стоит решить эти вещи и на С++, но без виртуальных функций? В множестве случаев можно избавиться от интерфейсов, абстракций и т.д. никак не навредив читаемости, понимаемости и гибкости кода
В множестве можно, а в множестве нельзя, опять-же разговор ниочем.

ну для вас разве не очевидно, что на это позднее связывание уходит какое-то время?
ну вы это фанатикам процедурного подхода расскажите

Разумеется очевидно, на вызов функции из массива указателей уходит какое-то время. Вопрос так-уж ли это страшно.
ну вы это фанатикам процедурного подхода расскажите
Зачем?

они вам расскажут как это страшно :)

Алгоритмы разрабатываются на фактически одном и том же языке. Откуда у C могут взяться превосходства в скорости?

ну вот как-то так выходит
benchmarksgame.alioth.debian.org/...g=gcc&lang2=gpp

И где там опревосходство в скорости? Только давай в непонималку больше не играй.

у тебя врожденное непонимание табличных данных ?
открыть ссылку и почитать слабо

У тебя помоему не хватает IQ понять что и как там сравнивается, и какое отношение это имеет к оригинальному вопросу. 20yo seniour?

переход на личности это привилегия только 20летних . так что следи за собой

Связать мой вопрос, этот бенчмарк и твой вывод может разве что ignorant 20yo senior с низким IQ.

у тебя врожденное непонимание табличных данных ?
открыть ссылку и почитать слабо
НУ я и открыл, и вижу что на одном тесте С сливает в 6 раз, а на остальных либо равно либо разница в 30% в обе стороны с переменным успехом, где ты увидел там превосходство С в скорости? Может это ты у нас альтернативно одаренный?

а я вижу что в 8 из 11 случаев си вариант получился быстрее.

Из них 5 в рамках какой то статистической погрешности, на том же сайте счет выведен как 2 против трех.
А вот слив в 6 раз не спряшешь никак

У тебя как с английским? Disclaimers читал?

«These are not the only compilers and interpreters. These are not the only programs that could be written. These are not the only tasks that could be solved. These are just 10 tiny examples.»

«Remember — those are just the fastest C gcc and C++ g++ programs measured on this OS/machine.»

Пару девелоперов написали два десятка каких-то маленьких программ на C и C++ и сравнили свои результаты. Возможно кто-то использовал худший вариант хеширования, выравнивания данных, хуже использовал l1 cache. Это НИКАК не отвечает на мой вопрос — «Откуда у C могут взяться превосходства в скорости?».

На практике подавляющее большенство сложных проектов реализуются, сопровождаются и адаптируются эффективней и быстрее с использованием OOP нежели чем без. На эту тему написана масса книг, подтверждается ~20-30 годами с существования индустрии и говорить обратное — неприкрытый дебилизм.

там можно контрибутить свои варианты.
что мешает пойти и доказать на 10 маленьких примерах что с++ быстрее си

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

>если вы будете использовать столпы ооп на всю катушку — то вы проиграете в производительности

Вот это утверждение совершенно не очевидно и требует доказательств.

Помоему обычный поток мысли тут происходит примерно так:

* «я не очень хорошо понимаю что такое OOP»
* «плохо знаком с C++ и особенностями использования этого языка»
* «поэтому мне легче написать свой микро-код с структурками, макросами и функциями на C»
* «сравнить его с C++/OOP у меня нет возможности»
* вывод: «C++/OOP inherently slower чем C»

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

Получаем например очень своеобразного "senior«-девелопера который к 30-и годам вместо испрльзования RDBMS предпочитает написать «своё», в проекте в котором эта функциональость вообще очень второстепенна.

Ещё есть индивидуумы которые переписывают libpq «потому что мне вся эта библиотека не нужна и если я напишу сам то будет быстрее потому что я лучше знаю как хранить и передвигать байты». Код работает на сервере с 16-96gb RAM, где масса других процессов и так подгружают полноценную libpq.

Ещё пишут коммерческие проекты в которых например каждая из тысяч функций получает 5-10 параметров-указателей, проверяет половину из них на != NULL и через них имеет доступ ко ВСЕМ данным в памяти и может их модифицировать. Fun times!

Детальное изучение OOP для C-шников помоему нужно просто для того чтобы мозг работал эффективней. Достигнув этой цели отпадает нужда сравнивать apples and oranges.

Детальное изучение OOP для C-шников помоему нужно просто для того чтобы мозг работал эффективней. Достигнув этой цели отпадает нужда сравнивать apples and oranges.
После ООП еще рекомендуется поизучать ФП, для тех же целей.

Конечно.
Речь тут шла о людях которые ни того ни того толком не знают и не понимают.

Ну иди пофиксь слив с в 6 раз на последнем тесте, а потом выдвигай претензии. Как говориться языком болтать не мешки ворочать.

претензии ? я ?
та меня как раз результаты вполне устраивают, в среднем си (на 10 маленьких программах написанных непонятно кем) получается быстрее, а то что это не всегда — ну дык серебрянной пули не существует

претензии ? я ?
О, старые добрые игры в непонимашку.
та меня как раз результаты вполне устраивают, в среднем си (на 10 маленьких программах написанных непонятно кем) получается быстрее
Т.е. ты упорно игноришь действительность что на С++ можно написать практически идентичный код как и на Си?
Откуда у C могут взяться превосходства в скорости?
restrict, к примеру.
Правда для этого есть контраргумент — хоть он и не в стандарте С++, но все нормальные С++ компиляторы имеют свои компайлер специфик рестрикт дерективы.

Загальне зауваження:
Чому більшість з присутніх — молодих, розумних людей не вміють поговорити по темі як дорослі — без образ і дурних жартів ? Самі ж перетворюємо будь-яку тему у повний срач.
Невже вам це приємно ?

Тому що рівень такий. По суті соціальне явище тимчасової феєричної ситуативної бульбашки успішності. Бульбашка лопне — життя все розставить на свої місця.

Чому більшість з присутніх — молодих, розумних людей не вміють поговорити по темі як дорослі — без образ і дурних жартів ? Самі ж перетворюємо будь-яку тему у повний срач.
Невже вам це приємно ?
На ДОУ появилась своя личная совесть (минимум второй коммент указывающий всем как жить) :)

Вы с человеком обыкновенным, по картинкам из книжек знакомы, и в интернете первый раз? Люди это злобные существа. Вы только просмотрите популярные темы на ДОУ за последнее время. И это ещё более менее культурные и образованные экземпляры.

карма либо наци-модерация спасут мир

ООП в кривых руках — это как «Silent hill», только в программировании.

<obvious> ООП плохо тем, что в этой парадигме пишет очень много программистов «ниже среднего», врочем это будет касаться любой парадигмы, будь-то процедурная или функциональная.</obvious>

Вы когда такое пишете, себя к какой группе относите, «выше среднего» или «ниже среднего»?

к студентам он относится. , т.е в рейтинге не участвует.

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

ООП — это подход. Парадигма. И на С можно писат в ООП — стиле. Уточните более конкретно ,о чем вы спорите. О том, что ява всех задавит? Или таки о применимости парадигмы?

Ок. Тогда какую парадигму адвокатируете вы? Процедурную? Фукциональную?

Никакую =) Я просто холиварю что ООП не «one true way» (tm)

Для каких конкретно задач?

И на С можно писат в ООП — стиле
а как же наследование, полиморфизм и инкапсуляция?

Посмотрите программы на Си, там все есть.
Кстати, вот даже книгу нашел посвященную данному вопросу www.planetpdf.com/...ts/pdfs/ooc.pdf

жесть :)

COM, CORBA нормально в си жили.
наследования там правда не было.

тоже ядро линукса вполне оопешное — каждый модуль это обьект

да выше товарищ уже кинул книжку, где описывается как реализовать наследование в ansi c.

Реализуемо.

Только вот эти фичи к ООП отношения не имеют: userpage.fu-berlin.de/.../doc_kay_oop_en

Спасибки всем ))) Словом холивор я выиграл =))
Особенно блогодаря research.scee.net/...ing_GCAP_09.pdf
=)

Я так понимаю, вы распечатали презентацию на 500 страницах и стукнули этой пачкой оппонента по голове? Тут же ни одного аргумента против ООП нету!

ну почему, там пишет что система не идеальная, а это один с его аргументов. Я в принципе все отзывы по чуть чуть ему процитировал =)

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

ну человек же утверждал, что всё, что не ООП — то плохо. Не надо ведь доказывать, что всё, что не ООП — хорошо. Достаточно доказать, что что-то процедурное лучше, чем ООП

Вы меня запутали. Мой комментарий относился к ничтожности приведённого аргумента: презентации, в которой автор описывает подводные камни написания производительного кода на языке C++. Никаких аргументов ни «за», ни «против» ООП там не было приведено

Там не про ООП, там про С++. Ко всему прочему, на описанные с статье грабли, можно наступить используя любой другой язык, например Си. Да и рассматривается там достаточно узкая предметная область.

Ужассс !!! Посмотрел эту пдф-ку , это капец , как человек пишет на С++ -

class Object
{
//---------------
char *n_name;
Object *m_parent;
};

Капец, никих умных указетелей, голые С — строки (хотя std:string уже не первый год стандартизовано) и это называется С++ !!!
Такое ощущение , что человек писал 10 на чистом С, потом ему сказали что есть 3 страшных слова — class , C++, OOP. И еще через час человек написал ПДФку о том, что все ООП — гамно...

Даже закрыв глаза на то, что это всего лишь пример, боюсь представить какой разрыв шаблона вас постигнет, когда вы просмотрите реализации контейнеров стандартной библиотеки: сплошь и рядом голые указатели! А библиотеки алгоритмов и СД? Страх и ужас — повсюду неучи. Инфа 100%.

Речь не о том, чтобы не использовать голые указатели, а о том, чтобы не использовать их в высокоуровневом продакшн коде без необходимости. Библиотека, конечно, тоже может быть продакшн кодом. Но это скорее исключение.

Библиотека, конечно, тоже может быть продакшн кодом. Но это скорее исключение.
Я ничего не понял. Вы полагаете исключением то, что библиотека может быть частью поставляемого приложения?

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

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

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

Существует огромное количество ситуаций, в которых не оправдано использование умных указателей. Вот например, отношение родитель-наследник, в котором родитель создаёт и содержит наследника проблематично реализовать в терминах shared-weak_ptr так, чтобы клиент родителя не знал детали реализации этой связи. Это следует, кстати, из того, что умные указатели нарушают принцип единой ответственности ООП.

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

P.S.
Если бы мне давали доллар, каждый раз, когда я видел, как обманутые ложной безопасностью «умных» указателей коллеги теряли целые структуры данных в памяти..

Интересно, чем, по-вашему так отличается библиотечный код от клиентского, что только в нём допустимо использовать голые указатели?
Краткая версия: Библиотека меняется не так быстро как клиентский код.

Ни один клиент не даст вам тратить на пользовательское приложение столько времени и денег, сколько нужно потратить на хорошую библиотеку. Умных указателей достаточно много типов, чтобы не использовать те, которые нарушают политику единого владения, но сохранять, например, память. Тот же unique_ptr — пальчики оближешь. И да, разумеется все нужно использовать с умом и не грести под одну гребенку. Разные могут быть приложения и разные библиотеки.

Ну std::string и умные указатели только еще раз усложнят его простой пример.

Верно. Умные указатели добавили бы N*4 слов в кэш и увеличили бы фрагментацию памяти, что идёт в разрез с советом автора использовать аллокаторы

в геймдеве специалист обычно развивается за 3 этапа:
— не уметь использовать
— уметь использовать
— уметь не использовать
в играх большая часть данных очень сильно предсказуема, поэтому часто не нужны безразмерные контейнеры.
самый простой пример, массив рендеркомманд часто выбирают равным 1к, если не влезает, то нужно хорошо подумать что лучше увеличить в 2 раза или все таки переделать модели, если не влезает в рантайме то лишние просто скипаются. есть легенда что 4к батчей хватит всем и на все, но все что больше 2к это плохо — нужно думать еще. часто ограничение диктует аппаратура, время кадра 16мс, если за это это время видюха рендерит только 1к батчей, то как-то глупо кормить ей больше и надеяться на хороший фпс, единственный вопрос который нужно решать — как узнать что можно не рисовать и сделать это дешево.
если хотите перейти на новый уровень рекомендую посмотреть лекции КРИ за 2006-2008 год (дальше КРИ превратился в пиписькомерку для менеджеров), ну и всякое DOD
а вообще код в статье касался консолей, там влобное ООП часто вообще не заводится. Есть примеры, говорят что движок сталкера не завелся на консоли из за повального stl и shared_ptr. то же самое было и с CryEngine2 и UnrealEngine2, их 3 версии были сильно переписаны чтоб влезть на консоли
ну и чтоб написать такую пдфку на С++ нужно было писать не один год

вот еще вброс, который вызывает лютый батхерт у нубов (у меня тоже в свое время) macton.smugmug.com/...709&k=ZX4pZ
со временем он проходит, так как понимаешь что по другому не работает.

Я с программингом на конслоли не сталкивался, но могу предположить, что там , из за жестких ограничений по ресурсам, ООП не свистит, так же как и в эмбэддед. Но нельзя же из за 2х областей делать вывод — что все ООП такое вот тормознутое гумно...
Тот же гэйм дэв, для x86 выглядит так ,что пишутся всякие движки (физики , графики) и в них есть и голые указатели и «злая» адрессная арифметика и т.д. но снаружи это все компануется в вылизаный ООП код, с наследованием, защищенным доступом, обертками и виртуальными методами...

не всегда возможно а часто просто неэффективно давать вылизанный ООП интерфейс.
дпустим мне больше нравится Cstyle интерфейсы, а я уже сам заверну в тот интерфейс который мне нравится. ну а вообще да, любой движок именно этим и занимается. но работа с этими интерфейчасами — самая скучная часть геймдева (ИМХО), все веселье там где такты погоняют байты...
поэтому среднестатическая история неудачного создания игры выглядит так:
мы решили писать свой мегауниверсальный движок с правильной архитектурой, 100500 универсальных классов связянные десятками уровней наследования и тп все для удобства...
либо есть еще вариант:
мы взяли CE/UE/Unity и 90% времени боролись с универсальными интерфейсами которые не давали построить то что мы хотим так как мы хотим...
Причина конечно не в ООП а в головах и попытках работать ту работу которая интереснее.

о том как будущее за Джавой и дотнетом
Я бы сказал по другому: будущее за JVM и .NET (именно за платформами а не языками) на основе которых появятся новые языки. Причем это могут быть как OOP так и FP языки или даже смесь парадигм, cкорее всего ориентированы они будут на parallelism and concurrency. Фактически уже сейчас на этих платформах появляются новые перспективные языки (scala, clojure, kotlin, F#, nemerle)
будущее за JVM и .NET
потому что там — автоматическая сборка мусора :)

«Сишники» взвоют о полезности детерминированности освобождения памяти еще больше.
А мне как-то пришлось свой хлопский менеджер хипа писать, чтобы malloc не дергать. Ну тормоза, когда у операционки десяточек байт запрашиваешь.
Хлопский, как-то пару лет тому смотрел GTKовский — хорош однако!
Но только — сборка мусора — лучше, за исключением:
эмбедед
геймдева
бортового ПО авиа и космических аппаратов

research.scee.net/...ing_GCAP_09.pdf

Ну и поработай над большим (> 1 млн строк кода) проектом — скоро поймешь, почему ООП плохое.

ООП софт невозможно понять чтением исходников — надо дебажить. Т.е. вам никогда не понять flow только чтением кода. А все динамические радости, которые привносят в нашу жизнь ООП языки только значительно усложняют все. В итоге сопровождение ООП системы это большой труд.
Рефакторинг проекта усложняется. Пример. Был в классе метод Update, но его переименовали, добавили параметров. Вызовы этого метода разбросаны по всему проекту, но беда в том, что увас еще 100500 классов с методами Update. Ну и, конечно же, многие из них вызываются через указатель на парента, спрятаны под каким-то хитрым макросом, являются параметром шаблона или еще чего. Называли бы методы в С стиле — UpdateWorld, UpdateCamera, т.д. проблемы не было бы — поиск с заменой все разрулил бы.
Навигация по проекту так же усложняется по вышеописанным причинам. Сложно понять, у какого именно класса вызовется метод.
Ну и проблемы оверинжениринга с ООП обретают ужасающих масштабов. Никто в книгах не пишет, что абстракция это опасно, потому имеем деревья наследования глубиной в 10-20, кучи фабрик и прочей абстрактной хрени.

Я люблю ООП, но стараюсь писать ООП код в С стиле

Был в классе метод Update, но его переименовали, добавили параметров. Вызовы этого метода разбросаны по всему проекту, но беда в том, что увас еще 100500 классов с методами Update.

Это не ООП. Это пи...ц.

ООП это парадигма, это кодекс чести, это зов ктулху, а не new везде где только можно.

Согласен, это не ООП. Это результат ООП головного моска

Чому не ооп ? Автор про те, що автоматичний пошук не знайде що треба замінити в такому випадку.

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

23-ех летние синьёры похоже не в курсе что ООП и Ц++ это разные вещи.

Надеюсь, столь почтенная персона, reality_hacker, сможет хоть одним аргументом подтвердить свои слова

твой пример с update характерен исключительно для программирования Ц++ в виме, и не является проблемой например для джава программистов, для которых конфликты успешно разруливаются IDE как и переименования, перемещения и т.д. и т.п., т.е. он ортогонален ООП.

т.е. именно по этой причине С++ не ООП язык?

А я где то писал что С++ это не ООП язык?

Нет, он не ООП язык, как и ява с шарпом, т.к. не реализует принципов ООП, которые были вложены в понятие ООП создателем термина ООП: userpage.fu-berlin.de/.../doc_kay_oop_en

Таки обжектив-си ближе к каноничному ООП

Рефакторинг проекта усложняется. Пример. Был в классе метод Update, но его переименовали, добавили параметров. Вызовы этого метода разбросаны по всему проекту, но беда в том, что увас еще 100500 классов с методами Update.
IDE слабая. Это все легко решается средой для других языков (кроме темплейтов, нет их там). Если честно, то для меня студия для С++ сейчас выглядит как мамонт, совершенно не приспособленный к работе.
Никто в книгах не пишет, что абстракция это опасно, потому имеем деревья наследования глубиной в 10-20, кучи фабрик и прочей абстрактной хрени.
Пишут. По крайней мере классический GoF, описывая фабрику и прочую абстрактную хрень пишет минусы каждого паттерна. Про опасность наследования не кричал только ленивый.

Я работал в успешном проекте на C# с 6 млн строк (~300Mb *.cs файлов, без ресурсов и прочего). Вон винда и другие продукты МСа нормально поживают с миллионами строк кода. Я по прежнему думаю что проблема не в OOP, а в том как применяют...

Вон винда и другие продукты МСа нормально поживают с миллионами строк кода.
Вон винда ни разу не ООП, чистый С. Вот пример того, как там пишут sim0nsays.livejournal.com/31460.html

Видел кернел мод винды — ООП. То что она написанна на С, не избавляет от того, что подход там ООПшный. То что функция возвращает (XXX)RESULT, первым параметром принимает ссылку на структуру(а не находится внутри класса) не освобождает её от того, что она является методом.
В общем действительно не стоит называть программы «не-ООП», только за то, что они написанны на С.

Основные столпы ООП — инкапсуляция, наследование и полиморфизм. С ниразу не подходит под них.

Основные столпы ООП — инкапсуляция, наследование и полиморфизм.
Вас обманули.
С ниразу не подходит под них.
А он и не должен подходить, ООП-шность — это свойство не языка, а кода. Помнитсо в универе один эстет, делал курсач по комп графике на ассемблере, при этом вполне в ООП стиле.
Вас обманули.
Меня значит тоже. Просвети пожалуйста, а то википедия тоже вроде пишет в том же направении: en.wikipedia.org/...es_and_concepts
Просвети пожалуйста, а то википедия тоже вроде пишет в том же направении: en.wikipedia.org/...es_and_concepts
Так там многое написано, вы читайте внимательнее (можете еще по ссылочкам походить)

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

ООП — подход к написанию программ. На каких-то языках писать в ООП стиле можно легко, на каких-то сложнее.

stackoverflow.com/...lymorphism-in-c

И да, то что в программе не применяется наследование не делает её «не-ооп программой». Советую подумать почему джаваскрипт считается ООП языком :-)

а что в javascript не так с наследованием? о_0

Кто такой Кей знаете? userpage.fu-berlin.de/.../doc_kay_oop_en

C++ также не подходит под это понятие.

Я работал в успешном проекте на C# с 6 млн строк (~300Mb *.cs файлов, без ресурсов и прочего).
Все дело в том, сколько усилий вкладывается в успешность проекта. Лично я ненавижу C# за то, что там нету разделения на объявление класса его методов и их реализацию. Это очень затрудняет навигацию и чтение этого самого кода.
В ядре линукса свыше десятка миллионов строк С кода. Оно живет и развивается уже не один десяток лет. Все дело в усилиях, прилагаемых для развития проекта...
Я по прежнему думаю что проблема не в OOP, а в том как применяют...
Я по прежнему думаю, что проблема ООП в том, что оно с легкостью разрешает применять себя не правильно. Скотта Мейерс пишет, что программист должен проектировать свои классы так, что бы их было невозможно использовать не правильно. Но вот в сама парадигма ООП позволяет насрать громадную кучу под себя и еще не меньшую вокруг себя. Безусловно, можно писать элегантно с применением любой парадигмы.

Оперирование абстракциями и прочей высокоуровневой хренью не предполагает знания железа. Но как можно писать эффективный код без знания железа?! Вот еще одна проблема ООП.

З.Ы. Я надеюсь 6 млн строк было написано компанией, которая разрабатывала проект, и в это число не входит неисчислимое число библиотек ;)

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

выберите любые 2 пункта, НО только — 2.

Очень, очень, и очень мало проектов имеют возможности развиваться «не один десяток лет»

Я по прежнему думаю, что проблема ООП в том,
вы напишите за 2-3 месяца магазинчик продажи пиццерии. Не за «пару десятков лет», а за 2-3 месяца, причем когда каждые 2 недели в процессе написания заказчика будут посещать новые идеи.
Тогда — попустит — «думать об ООП», а начнете думать о — задаче, условиях ее выполнения, требованиях формальных и неформальных. и различать.
Но вот в сама парадигма ООП позволяет насрать громадную кучу под себя
Я как начинавший профессиональную карьеру с Си — не пойму, кто кого хочет обдурить???
А насрать в стек гигабайтов по указателю — низя? Парадигма адресной арифметики значится — препятствует???
Оперирование абстракциями и прочей высокоуровневой хрень
То есть вы как истый программист записали в хрень — бОльшую часть реальности?
С ее любовью, бухгалтерскими счетами, допусками металоконструкций, логикой связи возраста пользователя с его предпочтениями?
У вас как и у истого кроме байтов ничего нету, да? может как и кроту вам глаза для своих «нор» не нужны?

P.S.
С начала 90ых я много слышал участвовал в спорах об ООП
Но бОльшая часть аргументов в этой теме похоже рассчитана и правда на «phpистов» и «формошлепов». Которые, так уж временно случилось, пока больше ничего о программировании не знают.

Но им то простительно, я не понял как называть авторов такого уровня аргументации:
Асилившими Си?

а мнение одного из авторов Си — Си как опасная бритва, можно филигранно побриться, а можно отпаханать полщеки до зубов — они ни Асилили?

P.S.
Crytek Ukraine
Да, кстати, а почему все игрообзоры говорят что только «бублик волосатый» больше дымить видеокарту заставляет чем «Кризис»?
Ничего личного, просто интересно, в ООП дело? в Crytek им слишком увлекаются?
2. и чего такие крутые «Сишники» от портирования на Wii U отказались?
ну и BioWare (Mass Effect 3) — тоже. Но вот Ярослав говорил что ресурсы ООПшники не жалеют, не умеют мол программировать «не жирно». «Потоки данных» не раскладывают. Так давайте поговорим об «игроделах», чего им сотни CUDA нужны, или в разы больше SIMDов радеоновоских. Разучились программировать? И после такой дисквалификации — ООП критиковать?

вы напишите за 2-3 месяца магазинчик продажи пиццерии. Не за «пару десятков лет», а за 2-3 месяца, причем когда каждые 2 недели в процессе написания заказчика будут посещать новые идеи.
И? Выбор парадигмы (а именно это мы обсуждаем) здесь никак не повлияет. Мои слова были о том, что в будущем выбор ООП аукнется.
А насрать в стек гигабайтов по указателю — низя? Парадигма адресной арифметики значится — препятствует???
Насрать в стек можно на любом языке. Я говорил не об этом
То есть вы как истый программист записали в хрень — бОльшую часть реальности?
Видимо, у нас разные реальности.
а мнение одного из авторов Си — Си как опасная бритва, можно филигранно побриться, а можно отпаханать полщеки до зубов — они ни Асилили?
Вы впутываете в разговор другие вещи. Мы же обсуждали ООП, а не С\С++\whatever. Выстрелить себе в ногу можно на любом языке. В одном это сделать проще, в другом тяжелее. Без сомнения С и С++ относятся к тем языкам с которыми отстрелить ногу невероятно просто
Ничего личного, просто интересно, в ООП дело?
Наверное, дело в том, что Крайзис по своей технологичности очень сильно опережает абсолютно всех. Красивая картинка с риалтайм освещением требует много ресурсов.
2. и чего такие крутые «Сишники» от портирования на С Wii U отказались?
Не стоит переводить мое личное мнение в разряд официальной позиции компании.
Так давайте поговорим об «игроделах»
«игроделы» как раз одни из не многих кто сильно оптимизирует свой продукт, в отличии от всяких пхпэшников, явистов и т.д.
ООП критиковать?
Человек попросил рассказать о недостатках парадигмы, я поделился тем, что мне не нравится. Выбор все равно остается за каждым.

З.Ы. Переход на личности не делает вам чести. Расскажите мне о себе и я тоже смогу запросто набросать камней в вашу сторону, ведь это же залог победы в споре, так ведь?

Выбор парадигмы (а именно это мы обсуждаем) здесь никак не повлияет.
Ого, прямо переворот совершаете в моем сознании :D
Сколько уже написали магазинчиков, чтобы просто — прочувствовать специфику этой разработки? Ну чтобы — думать о кеше процессора при этом? ;)
Видимо, у нас разные реальности.
О, начинаете смекать, что не «геймдевом единым»?
Я то в курсе, боролся и за фпсы, нарезал на ассемблере по битовым плоскостям чтобы в память GPU напрямую писать.
Так что давайте обсудим — реальности ;)
Наверное, дело в том, что Крайзис по своей технологичности очень сильно опережает абсолютно всех.
Аха, но когда «SAP» опережает всех — ну это говнокод! Ну конечно! ;)
Вы впутываете в разговор другие вещи. Мы же обсуждали ООП, а не С\С++\whatever.
С точностью до наоборот — это я говорю об ООП, а вот вы, и многие как раз дальше C vs С++ не продвинулись. Узость задач видать, и спец опыт «вылизывания 200 строк Си в NASA годами». Верю. Отработав в такой специфике лет 5+ - ничего другого о программировании, какое оно желтое, соленое, и гладкое бывает — знать не знаешь. Все оно либо круглое либо квадратное ;)
Не стоит переводить мое личное мнение в разряд официальной позиции компании.
Я и не переводил :) Просто так, немножко пытался потроллить, ради — «а подумать»? Ну немножко — подумать, ну хоть о том же форумном движке доу.
«игроделы» как раз одни из не многих кто сильно оптимизирует свой продукт,
О да! Вот тут — стопицот процентов — с 90ых годов — геймер только апдейтом железа и занимается, раз в год, два. Да, оптимизаторы-игроделы — ну что вы говорите. Первейшие!
У меня никак из первых EEE 901 умирать не хочет, на гиге запускается и Офис, и Eclipse, и хромы с файрфоксами последними.
Но из игрушек... Казаки, 2001го выпуска. Атом знаете ли ;)
Человек попросил рассказать о недостатках парадигмы, я поделился тем, что мне не нравится.
Вы писали магазинчик пиццы и вам ООП не понравилось?
Или все же — расширите сознание? ;)
Переход на личности не делает вам чести.
Недавно на собеседовании эйчару так и ответил, на
«А какие свои недостатки можете назвать»:
Для меня мнение человека и сам человек — две большие разницы. И в мой адрес естественно. Но, большинство людей не различают свое мнение и себя самих, а я об этом — забываю. Поэтому могу разгромить чье-то мнение прилюдно, и потом не понимать, почему же у человека стал врагом до его гроба...

Так что да, «чести» мне не делает такое различие — я знаю что подумав крепко, я же стану завтра умней. А большинство людей считают что если сегодня они фигню сморозили — то это у них навсегда.

P.S.
Кстати, а вы в курсе что один из главных схемотехников AMD-Radeon не так давно сказал что игроделы зажрались с директиксами и опенжелями? Что с таким подходом к программированию — никакое железо не угонится?
Свести бы вообще хотя б в этой теме — игроделов и эмбэедщиков. Ох бы тоже было на что посмотреть — кто умеет программировать а кто нет. Ну и о парадигмах ;)

Перечитайте «Пять миров» Спольски. Там небольшая статья.

Сколько уже написали магазинчиков, чтобы просто — прочувствовать специфику этой разработки? Ну чтобы — думать о кеше процессора при этом? ;)
Я не пишу магазинчики. Любой большой софт, а не магазинчики, как раз нуждается в оптимизациях и размышлениях о кеше, стратегиях выделения памяти и т.д. Возьмем приведенный вами ниже Офис. Вот вам пример — www.nedprod.com/...able/nedmalloc
Цитата:
nedmalloc can patch itself into existing binaries to replace the system allocator on Windows — for example, Microsoft Word on Windows XP is noticeably quicker for very large documents after the nedmalloc DLL has been injected into it!
Я был уверен, что автор приводил реальные цифры по времени выполнения нескольких приложений после инъекции, но не смог их найти.
Я и не переводил :) Просто так, немножко пытался потроллить, ради — «а подумать»?
Может, это вам стоит «подумать»? Или, на крайняк, заценить Крайсис 2 в 3Д и 720р разрешении на дохленькой, устаревшей PS3? А потом уже говорить, кто ни черта не оптимизирует ;)
Кстати, а вы в курсе что один из главных схемотехников AMD-Radeon не так давно сказал что игроделы зажрались с директиксами и опенжелями?
Читаем мой комментарий про Крайсис 2. Мы имеет громадный оверхед драйвера железа. Вот эти AMD-Radeon пацаны дают лоу левел доступ к своему железу на консолях, а на РС — громадный оверхед из-за ихнего драйвера. Именно из-за этого Рейдж бегает на старых консолях на 60 фпс, но для того, что бы получить такой же ФПС ему нужен на порядок мощнее РС.
Я не пишу магазинчики. Любой большой софт, а не магазинчики,
То есть не зная и «магазинчиков» вы беретесь рассуждать о большом софте для магазиниЩ и их сетей?
как раз нуждается в оптимизациях и размышлениях о кеше,
??? большой софт — о кеше думать??
я тут недавно общался... вобщем SAP у Дерипаски в Норильске обслуживает только складских рабочих мест около 29 тыс . Какой еще кеш процессора?
Может, это вам стоит «подумать»?
да, это я не умею, я уже понял, вы видели, слышали о большом софте, а мне да, такой неведом.
Удачи!
Лично я ненавижу C# за то, что там нету разделения на объявление класса его методов и их реализацию. Это очень затрудняет навигацию и чтение этого самого кода.
С таким успехом другой человек может сказать, что он ненавидит разделения кода на .h и .c/.cpp, потому что это затрудняет навигацию, заставляет бегать туда обратно, заставляет при изменении интерфейса — лезть и править в двух местах.
Но что собственно в данном случае требуется? Взглянуть на интерфейс класса не прокручивая весь код? Для этого давно существует решение и инструментарий. Вообще проблемы навигации решаются за счет IDE. Хотя точно также и решаются проблемы редактирования интерфейса сразу в двух файлах, и перемещение между ними.
Но вопрос, какую реально решает задачу, такое разделение? Мне кажется разделение на .h и .cpp файлы — не для удобной навигации по коду, существует.
Оперирование абстракциями и прочей высокоуровневой хренью не предполагает
Но и не предполагает отсутствия знания железа. Ничто не мешает человеку — знать железо, но писать на языке высокого уровня, и оперировать высокоуровневыми абстракциями, когда ему не нужно тратить усилия и контролировать что там на нижнем уровне.
Но как можно писать эффективный код без знания железа?!
А как можно писать эффективный код без знания computer science? Есть задачи которые гораздо эффективней решают за счет «высокоуровневой херни», за счет алгоритмов, за счет математики, чем за счет оптимизации на уровне железа. При этом экономится время на разработку, при этом за счет высокоуровневых абстракций понижается сложность (для человека). Абстракции это то что позволяет от одного транзистора прыгнуть к современным CPU и GPU. Так что не нужно тут этого снобизма.
С таким успехом другой человек может сказать, что он ненавидит разделения кода на .h и .c/.cpp, потому что это затрудняет навигацию, заставляет бегать туда обратно, заставляет при изменении интерфейса — лезть и править в двух местах.
Это дело вкуса, не больше. В С++ точно так же можно почти весь код написать в хедере.
Но и не предполагает отсутствия знания железа. Ничто не мешает человеку — знать железо, но писать на языке высокого уровня, и оперировать высокоуровневыми абстракциями, когда ему не нужно тратить усилия и контролировать что там на нижнем уровне.
Человек никогда не познает железо, работая только на высоком уровне.
Есть задачи которые гораздо эффективней решают за счет «высокоуровневой херни», за счет алгоритмов, за счет математики, чем за счет оптимизации на уровне железа. При этом экономится время на разработку, при этом за счет высокоуровневых абстракций понижается сложность (для человека).
Но она не всегда уместна. И в критических местах надо знать железо. Человек, который начинал свое становление с железа к абстракциям сможет быть эффективным во всех случаях. Человек начавший с абстракций — вряд ли.
Но она не всегда уместна. И в критических местах надо знать железо. Человек, который начинал свое становление с железа к абстракциям сможет быть эффективным во всех случаях. Человек начавший с абстракций — вряд ли.
А вот тут — поясните-обоснуйте.
Человек никогда не познает железо, работая только на высоком уровне.
Человек никогда не познает «кровавый ынтырпрайз» программируя только аффинные преобразования, загружая шейдеры мегабайтами текстур.
и как следствие не поймет — зачем оно ваапче — ООП.
И в критических местах надо знать железо.
Молодым программистам в ынтырпрайзе я давно говорю — вся твоя оптимизация этого цикла — впустую потраченное время, потому что вот у тебя лишний запрос вне нода — съест 99,9 % перфоманса. Его — придумай как убрать.
к абстракциям сможет быть эффективным во всех случаях.
Ничуть. Если в обычном, форумно-пивном разговоре «познавший железо» не в состоянии понять о чем речь — то в реале думаю будет ишо хуже :) Переучиваться придется уж точно.
Но она не всегда уместна. И в критических местах надо знать железо. Человек, который начинал свое становление с железа к абстракциям сможет быть эффективным во всех случаях. Человек начавший с абстракций — вряд ли.

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

Лично я ненавижу C# за то, что там нету разделения на объявление класса его методов и их реализацию. Это очень затрудняет навигацию и чтение этого самого кода.
То есть создать абстрактный класс с абстрактными методами и унаследовать от него религия не позволяет?

We need to go deeper.jpg
Зачем усложнять код ненужными наследованиями?
К тому же вы путаете декларацию и реализацию интерфейса и класса — что является довольно разными вещами

Я ничего не путаю. Вы ведь хотите декларацию а ля С++? Я привёл простейший способ её эмулировать.

Тут ближе partial class, так как в С/С++ это просто особенность организации кода, и после компиляции это разделение исчезает. Точнее не исчезает, но в терминах ООП никак себя не проявляет. Это по сути аналог метаданных из .net сборки, только которые нужно каждый раз ручками править. И вообще, это чисто вещь для удобства компиляции, и она никак не для удобства навигации была сделана.

Блеск! Вечно про них забываю.

а какие плюсы от такого разделения?
чем это лучше партиал классов?

Это сугубо дело вкуса. Открыл хедер, пробежался глазами по списку методов, нашел куда добавить новый, что бы он находился в логичном порядке или в 300 строк получить представление о функциональности данного класса. Мне это очень удобно

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

В крайтеке нету денег на Visual Studio ?

Для бедных есть ещё Eclispe CDT, там есть outline панелька.

Тогда чем не устраивает «свёртывание» методов студией? Ну или псевдо директива #region.

Аргументов против много.

Вот только один ЗА — их перевешивает:
ООП значительно, ощутимо лучше всех позволяет проектировать в терминах предметной области.

Остальное — следствие этого. Например расплата эффективностью работы ПО (по скорости-памяти), или ненужность ООП когда предметная область — те самые потоки данных, то есть никаких сущностей кроме перегоняемых байт из одной области памяти в другую — нет. Тогда — С! без плюсов!

ООП архитектура рушится как карточный домик при малейшем изменении требований заказчика
Тю, наоборот :) Как раз Сишное ПО сыпется куда лучше :) Ответом то и было ООП.

А ФП — не имеет возможности проектирования — в терминах предметной области. Поэтому тоже — ни в жизть ООП не заменит. Только — на уровне кодирования на ЯП, и дизайна.
Ну и опять же, как и С — там, где сама предметная область очень близка к тому что предлагает парадигма ФП.

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

P.S.
Примерчик, для OОП vs эффективность.
Есть у нас фигуры, с площадью, задаются с помощью декартовых координат.
Нужно сравнивать их наложение.

ООП реализация:
Ну значится будет класс PointXY с полями x ,y, а фигуры задаем сортированными коллекциями этих PointXY.
Тормоза при сравнении — будут куда выше, чем если
используем не коллекции объектов PointXY, а отсортированный массив long’ов в котором старшие 32 разряда — x младшие — y
а PointXY хранит этот самый long, и при сравнении мы никак не используем PointXY а двоичным поиском бегаем по массиву.

Но, ООП никуда не делось — коллекции снаружи выглядят как хранилища PointXY, и сами эти хранилища — имеют атрибуты фигур — например углы прямоугольника в который вписаны, полезная площадь, и т.д.

А вот реализация да — не ООПшная, а приближенная к железу, к его работе.

Того, ИМХО и холивары как-то и правда с IQ связаны...
ООП говорит о проектировании, и отображении в коде сущностей появившихся на этапе — проектирования. Но не надо спешить и кодировать эти сущности в ООП.

ООП и функциональная парадигма — не конкурирующие. Так что никто никого не заменяет. Есть еще такая тема как функциональное ООП. Например можно смотреть на реку — меняет ли река свое состояние? Тут с какой стороны посмотреть, вода протекла — значит поменяла, а по существу нет, получилась новая река со своим состоянием, как в изречении, что нельзя зайти в одну реку дважды.

А вот конкурирует ли ООП с процедурными языками, тоже вопрос.

ООП и функциональная парадигма — не конкурирующие.
Вообще-то — да.

Потому что ООП — это более высокий уровень абстракции чем — императивная и декларативная записи кода.

Например можно смотреть на реку — меняет ли река свое состояние?
Для моделирования на ЯП — недостаточно данных — давать ли «реке» состояние или нет.
Мне даже — с «смотреть» не все понятно. Кто смотрит, откуда смотрит, на карту местности смотрит с «синими линиями»?
Тут с какой стороны посмотреть, вода протекла — значит поменяла, а по существу нет,
я потому и говорю о вреде математики — как о воспитательнице вот этих абсолютных подходов.
Что значит «по существу»? Я — не пониманию. Не понимаю и «на самом деле», и прочем — Абсолютном.

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

И тут то — если требования к будущей программы жесткие по эффективности, а модель требует жирных ресурсов — чем-то приходится жертвовать, эти два условия — несовместимы.
А общего правила нет. Чем жертвовать — на то и Голова программисту. Думать надо, а не молиться на «потоки данных», «ООП», «ФП», «TDD», .... ,,,...,,,.

А вот конкурирует ли ООП с процедурными языками, тоже вопрос.
Не конкурирует также как и с ФП. ООП — это другой уровень абстракции.

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

Компилятор C++ имеет все возможности уложить std::vector<pointxy> именно в таком виде как ваш вариант с long[]. Возможны ньюансы с alignment но их можно решить — или аттрибутами для данных или хранить внутри класса такой же long и использовать accessors — get_x() const, get_y() const.

да дело в не компиляторе.

я просто быстро набросал пример разницы между:
ОО проектированием модели
ОО и неОО реализациями модели

в мире энтерпрайза есть и другой пример
Rich vs Anemic

Обе — ООПшное проектирование
Но вот реализация, а вернее даже — композиция программы — разные
Rich — ООПшная, а вот Anemic нет. Она скорей как раз из разряда «потоков данных», жесткого разделения на — данные и код их обработки, а не совмещении в объекте.

То есть, и тут имеем — преимущества проектирования в ООП, но при кодировании — не обязательно и писать в ООП, есть и другие подходы написания кода, когда сохраняется и модель в нем, но программист волен думать и об эффективности программы, которая будет создана транслятором по этому коду (неважно это компилятор или интерпретатор).

ООП говорит о проектировании, и отображении в коде сущностей появившихся на этапе — проектирования. Но не надо спешить и кодировать эти сущности в ООП.
Коллега, браво! :)
Если хоть один человек понял чёрную сторону ООП после этого обсуждения — это уже хорошо.
Если хоть один человек понял чёрную сторону ООП после этого обсуждения — это уже хорошо.
Да при чем тут черная сторона??

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

Война с ООП — это война «луддитов против машин».
Луддиты должны бы предложить что-то взамен.
Но они предлагают взамен то, что и породило ООП как следующий шаг развития программирования. То есть — долой электричество, долой — айда назад в пещеры, и на свежий воздух! свежая дичь, а не выкормленные химией геномутанты, туалеты без бачков, — супер а не жизнь!

ООП архитектура рушится как карточный домик при малейшем изменении требований заказчика
Еще как рушется, если применена допустим в функциональном языке)

Та оно везде рушится.
Просто в большом проэкте на СИ, даже грамотно спроэктированном — смерть и вынос, взять и переписать и никак иначе.
В грамтно спроэктированном ООП проэкте (особенно если там ДДД) — ситуация куда мение плачевная, и менять и рефакторить до какойто степини вполне можна.

А если будет ООП на Си с ДДД, то все-равно смерть и вынос?

ООП на си — это называется «костылявый паттерн, заклеивающий недостатки языка». Но я бы посмотрел примеры реализвции ООП на си с ДДД, да еще желательно в большом проэкте.

Если что то падает это нормально, не нормально когда не ясно что.
Грамотный проект всегда позволяет найти баг довольно быстро. + это же позволяет понимать что происходит в данный момент

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

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

Я всегда учитываю направление развития, и обхожусь без фабрик.
 не знаю как вам это удается. Я кочергой убил уже 3 гадалки и два экстрасенса.
Как по мне то лучшая концепция это конвеер, где каждый блок делает свою задачу, и где каждый блок можно изменить/убрать/добавить.
ООП в меру, оно не должно учитывать все, но блочная струкура позволяет не переписывать все, а переписать только пару блоков, что вопервых быстро, во вторых проще, и в третьих не создает деревья всякой хрени типа фабрик, инжекшенов и прочей мути, которую потом хрен прочитаешь.
Да это не универсальный подход. Изменения бывают таковыми, что нужно не один блок поменять, а все сразу, вместе с данными. С ростом кода, и приходом на проэкт новых людей, блоки все мение и мение независимыми становятся. Итд итп. Универсальных подходов нету. Лучее что я концептуального видел (но на практике еще не работал) — ДДД. Где мы пытаемся спеку разложить на модель, и модель привести к коду 1 к 1.

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

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

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

Оттуда и начинают расти фабрики фабрик адаптеров синглтонов, и прочий оверинджениринг.
Какие такие фабрики фабрик в век dependency injection.

Нужны аргументы против ООП?

То есть аргументы за функциональное программирование не нужны?

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

вообщето ядро линукса частично оопешное , покрайней мере модули, хотя и без с++

я так понимаю, оопешные модули плохи, корявы, глючат и скоро умрут ?

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

смерть ООП — это как крах доллара

4) ООП слишком далеко от реального представления информации

Absolute bullshit.

Update:
Хотя, смотря что понимать под «реальным».

UPD: Вот старое обсуждение сабжа: dou.ua/...-senora/#183442

Почему объектно-ориентированное программирование провалилось?

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

А мужики-то и не знали.
Всё пишут и пишут на Java, на C# да на C++ и прочих ОО языках.
Шо ж они окаянные всё не проваливаюцца никак?...
:-)

Всё пишут и пишут на Java, на C# да на C++ и прочих ОО языках.
Писать на ОО языках, и ООП — две большие разницы.
— Можно технично использовать области видимости, структурировать код с помощью классов, отделять интерфейс от имплементации.
— А можно нагородить вышибающую мозг структуру наследования из ненужных сущностей, а за одно пихать обджект фектори всюду куда надо и не надо. ;)
А можно нагородить вышибающую мозг структуру наследования из ненужных сущностей
я не только на Си, а и на ассемблере писал.
Вы Ярослав хотите сказать что там нельзя нагородить???
Хотя бы указателя на указатель, который смещением полученным по другому указателю получаем указатель на адрес, по которому будет вызываться call или function?
Или что такой код — читается легко и непринужденно?
я не только на Си, а и на ассемблере писал.
Не вы один. :)
Хотя бы указателя на указатель, который смещением полученным по другому указателю получаем указатель на адрес, по которому будет вызываться call или function?
Ой как страшно! :)
А вот как насчёт:
— темплейт шестерной вложенности подибагать за индусами?
— разобраться в восьмиуровневой лозанье из врапперов?
— объяснить паттернописцам, что для управлления водонагревателем по показаниям термопары ОБДЖЕКТ ФЕКТОРИ НЕ НУЖНЫ!!
;)
Ой как страшно!
Ярослав — геймдевочные и эмбэд штучки и подходы — останутся там же. они в нескольких других областях — неприменимы — за ненадобностью.
А вот как насчёт:
не подбирайте
не разбирайтесь
не объясняйте.

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

ООП — нерушимо
Как сказал мне один пафосный персонаж, «Закон Гука — ЭТО ДОГМА!»... Так почему же тогда рвутся струны на гитаре, подумал я ;)
никакие доды ему в ближайшее десятилетие не угрожает.
Ленин — всегда живой! LOL
Но таки да, ООП/ООД включает в себя слишком много конструктивных-позитивных-продуктивных практик, чтобы его можно было пошатнуть.
В частности — энкапсуляция, SOC — от них никуда не денешься.
Так что вам решать — либо асилить его
Пока Вы тут мне рассказываете про «асилить», у меня уже пару лет как висят 2 штатовских патента на софтвер архитектуру (в линкдине моём ссылки есть кстати), и дивайсов продано как минимум несколько сотен... 8-Р

Да. И виноват в этом не язык, а программист.

Я так понимаю автор ожидал что мы поможем отстоять процедурное программирование — другими словами гoвнокод на ООП языках. Настоящий ООП кодерок должен понимать почему метод на 100 строк это плохо, и что такое coupling и cohesion.

А по поводу ФП: один друг подсказал тему — реализуйте на ФП класс Date или DateTime =) Интересно на это посмотреть...

Настоящий ООП кодерок должен понимать почему метод на 100 строк это плохо
Нука-нука, и почему же? ;)
и что такое coupling и cohesion
Некоторые даже энкапсуляцию не понимают... :(
А по поводу ФП: один друг подсказал тему — реализуйте на ФП класс Date или DateTime =) Интересно на это посмотреть...
ФП? класс? Веселый у вас друг :)
А по поводу ФП: один друг подсказал тему — реализуйте на ФП класс Date или DateTime =)
Про CLOS слышали?
Краткая (упрощенная) заглушка даты:
var MyDateClass = function (millis) {
return function (method) {
if(method == "dateClassMethod") {
return "calc dateClassMethod from" + millis;
}
if(method == "otherDateClassMethod") {
return "calc otherDateClassMethod from" + millis;
}
};
};
var myDateObj = MyDateClass(1654847874848454);
myDateObj("dateClassMethod");
При наличии макросов, все выглядит куда приятнее (смотрим КЛОС)

Тут сам вопрос провокационный. А зачем именно нужен класс даты?

А зачем именно нужен класс даты?
Модуль объединяющий функционал по работе с датами.

Ну так модуль же а не класс.

а с ООП всегда так — привести простой пример его пользы, преимуществ похоже вообще невозможно :)
На маленьких примерах — оно явно избыточное, как в старом анекдоте кто как решал задачу — вывести «Hello world!»

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

А вот когда закодить это все на plain C, а потом добавлять функционал — ну тут и посмотрим, как «архитектура рушится как карточный домик при малейшем изменении требований заказчика»

или на ФП — когда там архитектура — write only — ибо — чистые функции и прочие прелести, и ничего общего сущности в коде с сущностями задачи не имеют.

Ну так модуль же а не класс.
Ну так а я «класс» и не создавал. Я так понял, человек хотел именно функционал модуля, ведь если оно ему не надо, то «класс» Дата реализуется и в ФП и в процедурном очевидным способом.

В том то и дело что с ООП носятся сейчас все и суют его где нужно и не нужно. Проблема не в том что оно хорошее или плохое а в том что люди говорят вещи типа: в языке Х нельзя сделать объект или накостылять патерн У то он плохой. Какой смысл ставить цель написать класс даты на ФП-языке? :) Сейчас как будто само ООП является целью. Я не удивлюсь если скоро увижу в вакансиях для программистов на asm требование «знать и уметь использовать на практике» патернов из GoF и ООП. В каждом лагере есть свои подходы и приемы.

Видимо имеллось ввиду не написать клас даты в фп языке (так как ООП термин «клас» непременим к ФП), а реализовать функционал близкий к оному.

Ну если это реализовать на ФП, то будет просто пачка функций, или одна функция со свитчем. А учитывая что все функции будут работать с timestamp... то cohesion очевиден, разве нет? ;) ООП — это о данных и поведении, а в случае с датами функции — это поведение, а timestamp — данные.

CLOS имеет только то отношение к ФП, что Common Lisp иногда не совсем корректно называют функциональным ЯП. CLOS — это как раз самое ООПистое ООП, с продвинутым рефлекшеном в виде метапротокола, и веселым generic dispatch (который кстати можно настраивать и даже заменять).

CLOS — это как раз самое ООПистое ООП
Какбэ не спорю.
CLOS имеет только то отношение к ФП
Стоп, когда я последний раз на него смотрел, то реализовано оно было на макросах/функциях (смотрел довольно поверхностно, так что могу ошибаться).
Common Lisp иногда не совсем корректно называют функциональным ЯП.
Аргументы? Ибо все кто такое утверждал, обычно сводили разговор к «расовой чистоте хаскелла».

В CL только аллокация регистров и GC сделан не на функциях/макросах, а на асме или C. Все остальное на нем же самом, причем CLOS оттуда уже никак не выкусить, он даже на экране ничего не сможет напечатать без CLOS. А насчет ФП — вопрос терминологии, если CL — это ФП, то там же и javascript и питон, не смотря на некоторую кривизну замыканий. Но как-то последние два не принято называть функциональными.

о том как будущее за Джавой и дотнетом и что старые языки (е.г. С например =)) ) скоро умрут и никому нафиг не нужны.
Можно поинтересоваться сколько (и каких) языков знает/имеет_опыт_работы ваш собеседник?

ООП vs Процедурное программирование? Не пройдёт, вас сольют.
Вот ООП vs ФП — совсем другое дело!

Кстати
4) ООП слишком далеко от реального представления информации
ООП как раз очень хорошо подходит для моделирования объектов реального мира.

Противовес ООП есть только один — DOD.

Фууу, тебе должно быть стыдно. Хотя тебе не привыкать.

Универсальный противовес ООП? Везде-везде, во всех его традиционных областях применения?

Попытаюсь объяснить просто и популярно.
ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.
Уверовавшие же в эту (###) олухи начинают мостить ООП куда надо и, в основном, куда не надо. Эта практика очень хорошо известна как Cargo Cult Programming, и является его частным случаем.
ООП, при правильном применении, не так уж плох.
НО!!!
Для того, чтобы понимать граници применимости ООП нужно
— на практике увидеть эпик фейлы проектов на неразумном применении ООП
— понимать, что в ООП хорошо, а что — плохо.
Если Вас действительно интересует вопрос, прочтите что про ООП сказал Линус Торвальдс, google: «C++ bullshit»

Смєшалісь в кучу коні, люді...

«C++ bullshit»
С++ == ООП ?
Крім того, Лінус з радістю множить на 0, наприклад, всі системи контролю версій крім створеної власне їм :) Вірити йому ?
ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.
По-перше, всі визнають, що є класи задач, для яких ООП не дуже підходить. По-друге, чим краща Ваша універсалізація ДОД ?
О, нарешті адекватний коментар від опонента! :)
С++ == ООП ?
Звичайно ні, але Лінус критикує не стільки плюси скільки ООП в цьому опусі.
Крім того, Лінус з радістю множить на 0, наприклад, всі системи контролю версій крім створеної власне їм :)
Так, дуже влучне спостереження! :)
є класи задач, для яких ООП не дуже підходить
Звучть дуже слабенько. ООД є неякісним підходом, тому він призводить до фейлів. ДОД — це альтернатива ООД, але і те і інше — спосіб аналізу і синтезу систем.
Відкрию Вам секрет: Поєднання обох методів, аналіз системи з обох точок зору — дає найкращий результат. :)
І навпаки. Ігноруючи потоки даних, любителі ООП-ООД плодять непотрібні сутності, і натрапляють на граблі, от навіть вчора був епічний приклад.

О ! Так прийняти (але не погодитись) Вашу думку я згоден. Але не цю:

Yaroslav Voytovych
Possible TL/Architect в [undisclosed] позавчера #
***
Противовес ООП есть только один — DOD.
***

Так прийняти (але не погодитись) Вашу думку я згоден. Але не цю:
Противовес ООП есть только один — DOD.
Спробую пояснити ще раз.
ООП в своєму прагненні до суцільної об’єктно-орієнтованості — відриває нещасного ООПера від реальності і уводить до країни мрій і фейлу.
І лише ДОДівський погляд на речі може повернути нещасного до реальності, ООП-ООД йому ну ніяк не допоможе.
ДОД — це альтернатива ООД
алфавит не может быть альтернативой юриспруденции

ассемблер не может быть альтернативой SQL

Ярослав, вы потеряли иерархичность абстракций :)
ДОД — это вышивание крестиком, или еще какая ручная работа.
А ООП — это промышленный выпуск километров ткани.

ДОД — это вышивание крестиком, или еще какая ручная работа.
А ООП — это промышленный выпуск километров ткани.
ЭТО ЧУШЬ.
Вы повторяете это уже не раз, и не Вы один. Даже смешно слушать.
Оба подхода могуть быть применены и применяются в архитектурном деле, причём о одной и той же целью — построить архитектуру, желательно успешную — это важно. ;)
Их можно успешно применять по отдельности, и тогда выигрывает ДОД.
Можно же понимать их оба, и тогда выигрывает понимающий. :)
НО.
Как показывает практика, зафейлившиеся ООПеры обвиняют в своих бедах кого угодно, но только не ООП, и не свою глупость. :)
ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.

Я с тем же успехом могу заменить в этой цитате «ООП» на ваш любимый DOD или KFC, который тут называли или любую другую трехбуквенную аббревиатуру.

Если Вас действительно интересует вопрос, простите что про ООП сказал Линус Торвальдс, google: «C++ bullshit»

Ссылка на авторитет? Good, good..

Я с тем же успехом могу заменить в этой цитате «ООП» на ваш любимый DOD
Я «продаю» здесь ДОД — как альтернативу ООД, но не как рецепт всеобщего счастья.
Успешная архитектура — єто не ДОД и не ООД, это, в основном, не падайте — ЗДРАВЫЙ СМЫСЛ, и опыт конечно.
Ссылка на авторитет? Good, good..
Ну если моя логика не воспринимается мозгами оппонентов, приходится авторитетами припугнуть, чтоб не галдели.
Ну если моя логика не воспринимается мозгами оппонентов,
Ярослав, дело не в Вашей логике, а в отсутствии того самого здравого смысла :)
Я почитал то что вы предложили о ДОД. Это вообще никаким боком не альтернатива ООД. Это просто низкоуровневая хрень для написания драйверов или перегонки между данных между ОЗУ и памятью GPU.

То есть, отсутствие здравого смысла — это когда НЕ объявляется круг задач для которых нечто лучше, чем другое. Без этого получается — догма.
ООП — не серебрянная пуля, и не будет ею. Особенно в случаях когда предметная область — сам компьютер, его работа. Незачем творить класс — CPU, у которого поле, объекта класса Cache, и есть объект класса Memory, и у всех методы для записи байтика туды сюды. Это будет просто — масло маслянное. Машинные команды и так отражают эти сущности и связи между ними, чтобы на них, еще нечто надстраивать.

Я «продаю» здесь ДОД — как альтернативу ООД
Кому именно, разработчикам драйверов? Они еще не научились писать драйвера в «потоках данных»?

Огласите — целевую аудиторию :)

Ну, не обязательно драйверов, в интерпрайзе тоже есть место для DOD.. Но достаточно узкое и я подозреваю, что намастрячить несапортабельный кодец или устроить metadata hell там будет никак не труднее последовательного применения OOD.

Data Oriented Design? Это оптимизационный паттерн, если я не ошибаюсь. ООП — явление гораздо более глобальное.

driven, а не oriented. не понимаю, как можно не видеть разницу.
ну и если первое д — это дата, а не домэйн — то это скорее отсутствие дизайна, чем дизайн

Data Oriented Design? Это оптимизационный паттерн, если я не ошибаюсь.
С точки зрения законченного ООПиста — да, именно так.
С точки зрения же здравого смысла, DOD — наиболее осмысленный подход:
— Деление целого на части
— Выяснение взаимосвязей (потоков данных) между частями
Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно. А вот мантра «Everything Is An Object!» — у меня всегда вызывала подозрения, даже в те дни, когда я просто жаждал принять ООП всем сердцем, и думал что это только по началу кажется слегка идиотичным, а потом пройдёт и раскроется во всей своей райской красоте... ;)
С точки зрения законченного ООПиста — да, именно так.
Я поклоник гибридных ООП-ФП языков. А вот вы, судя по каментам в топике — фанатик.
Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно.
А мне интуитивно понятен ООП, ну и что?
А вот мантра «Everything Is An Object!» — у меня всегда вызывала подозрения, даже в те дни, когда я просто жаждал принять ООП всем сердцем, и думал что это только по началу кажется слегка идиотичным, а потом пройдёт и раскроется во всей своей райской красоте... ;)
А вы работали с языками, где эта мантра таки реализованна? Потому что в вашем профиле таковых нет. Для ясности — С++ - не каноничная реализация ООП, о чём Кёртис заявил прямым текстом.
А вот вы, судя по каментам в топике — фанатик.
Я много раз мог бы дать классификацию Вам, но сдерживался. Но теперь дам.
Вы, батенька — хам.

Ну до вас мне...

Вернёмся к теме разговора. Вы хоть раз работали с тру ООП языком? С Смалтолком или Обжект Си, что бы было понятнее.

Руби, как вариант, да?

Я с ним особо не знаком, не знаю.

Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно.
а что там непонятного И для неэлектронщика?

Вот только вам как электронщику нифига непонятно как писать «магазинчики» с «оперденями» :D

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

Спор аналогичен наличию/нет бардака в личной/публичной библиотеке, он бесполезен.

Гуглиться легко. Тема старый баян. Хотя в последние годы идут немалые подвижки в сторону фп и она опять набирает актуальность.
en.wikipedia.org/...mming#Criticism , можешь закопипастить другу в скайп.

Если в систему нужно легко добавлять новые типы, не меняя интерфейс — то нужно юзать ООП. А если нужно добавлять новые функции, для работы с фиксированным набором объектов, то нужен процедурный подход.

Реально существует только один аргумент — низкий IQ. Все остальные аргументы это следствие этого.

Ну и какую практическую ценность имеет этот аргумент? ;)

Он как бы возвращает спорщиков к более простому варианту «Что лучше ВАЗ или КАМАЗ?»

А теперь мини трейнинг :):
1) На чистом С код быстрее
Доказательство всеобщности необходимо тут.
2) На самом деле код С++ нифига не портируется так просто (ну это отдельно про с++)
Новость ЦПП — такое же унылое гуано как и Ц. А вот как с «портированостью» программ на джава?
3) Библиотеки например Boost непроизводителны, так как дают слишком много удобной абстракции
Для всех Удобно(х) следует Непроизводительно(х)
Так что ли? Так это не правда. Нэ залык!
4) ООП слишком далеко от реального представления информации и
А мужики-то и не знают.

там срач Си против Си++, а не ООП против неООП

Как че, согласно Толоконникову, Линус Торвальдс — ниасилятор.

Так он вроде сам и писал, что так и есть.

Кто он, Торвальдс или Толоконников?

>А вот как с «портированостью» программ на джава?

Write once, debug everywhere?

>Новость ЦПП — такое же унылое гуано как и Ц.

Но до явы с шарпом по унынию ему еще плестись и плестись.

С интереса, а что вам нравится =)?

C, Objective-C, Ruby, Smalltalk.

До уныния Objective-C любому языку ползти, нет ничего унылее чем эта надстройка над компилятором С.

там очень даже не скучно, если вы про это.

После 1000 квадратной скобки я был готов застрелится. Благо уже не приходится с ним работать.

Т.е. круглые скобки вас не парят в других языках? Или мусье — говонокодер и «стиль кода» — это не о нем?

Какой язык мусье предпочитает? Вы скажите, чтобы я вас предметно обосрал.

Ну не надо же обманывать. Вы же фомошлеп, вас же издалека видно.

Это вы. Очевидно же.

dou.ua/...=comment#278631

>> Вы же фомошлеп, вас же издалека видно.

я так и не понял, что значит фомошлеп, извините. :( Потому и переспросил, кто я?

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

А ну да, я забыл, что objective-c программисты 90 процентов времени проводят в xcode cocoa designer, тогда видимо вы правы, я был формошлепом. :( Убежал в стыде.

Objective-C проггеры пишут код, блеать. Ну а вы, будучи указанной выше сущностью ( dou.ua/...=comment#278631 ) , таки сидели в каком-то там кокоа дизайнере, а остальное время гoвнокодили, что и приводило к сотням квадратных скобочек в одну строку.

До взлета iOS формошлепства никто в здравом уме не использовал objective-C для нормальных проектов, популярность настала после того, как всем захотелось фигачить очередные формочки для iOS. Замечу с появлением кучи альтернатив Objective-C для разработки приложений на iOS, популярность по статистике Objective-C снова упала.

Ruby тоже самое, до взлета RoR формошлепства, никто в здравом уме не использовал этот язык.

Если я захочу поупражнятся в наборе текста я установлю Соло на клавиатуре.

Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.

Так что да, вам лучше знать, что такое формошлеп и кто им является. ;)

Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.
Ошибаетесь. Смалтолк был придуман для формошлёпства.

>До взлета iOS формошлепства никто в здравом уме не использовал objective-C для нормальных проектов, популярность настала после того, как всем захотелось фигачить очередные формочки для iOS.

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

>Замечу с появлением кучи альтернатив Objective-C для разработки приложений на iOS, популярность по статистике Objective-C снова упала.

Не удивительно. Только объясняецца это тем, что появилась возможность разработки на других платформах, т.е. не маках, т.к. далеко не у всех есть доступ к макам, а многие просто не в состоянии освоить обжектив в те сроки, аз которые им надо выполнить свои задачи. Да и опять же, набежало формошлепов, пишущих тормозное и бажное гoвно на js, рзабавили статистику.

>Если я захочу поупражнятся в наборе текста я установлю Соло на клавиатуре.

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

>Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.

Браво! Вы сейчас пытаетесь доказать, что большинство задач формошлепские и стоит их выполнение мало денег, т.к. есть обезьяны почти бесплатные? Я в курсе, вы меня не удивили, что вашей братии больше, чем тех, кто делает что-то сложное и интересное, ибо соотношение 4:1 всегда верно.

>Так что да, вам лучше знать, что такое формошлеп и кто им является. ;)

Да что там знать? Вы. Очевидно же.

Удивительно, разработка не на Objective-C все еще требует Mac. Многие просто не хотят тратить свое время на унылый язык.

И да, большинство задач таки формошлепсткие, потому у тебя сейчас есть работа. Но ты не беспокойся время RoR и iOS когда-то пройдет, так что уже можешь привыкать к метле, подметать парадное.

>Удивительно, разработка не на Objective-C все еще требует Mac. Многие просто не хотят тратить свое время на унылый язык.

Аргументация в стиле "«миллионы мух не могут ошибацца»? Свежо, но неправильно, ибо большинство просто слишком тупы, ибо высокоуровневые обезьяны — формошлепы, неспособные на умственный труд. Посему, как появилась возможность лабать на своем любом жсике, на него и сбежали.

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

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

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

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

>Но ты не беспокойся время RoR и iOS когда-то пройдет, так что уже можешь привыкать к метле, подметать парадное.

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

Разработка на Objective-C это формошлепство чистой воды

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

Из того, чем занимался я или мои знакомые: гейдев, ЦОС, машинное зрение, трейдинг.

Мы же взрослые люди. Зачем отрицать очевидное?

И как часто заходят подобные проекты, формочки для трейдинг систем не учитываем ?

Формочки остаюцца формочками вне зависимости от того, куда мы их пишем.

Я не могу сказать частоту в глобальном масштабе. Мне на весь 2012 хватило. Формочки клепал только раз и то потому, что клиент хотел визуальную обертку дял морфирования, чтобы были код-семплы для его рзарабов.

Трейдинг на ObjectiveC? Извращенненько.

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

Только ФП, только хардкор!

Помогите мне холиварить =)))
Не умеешь не лезь © :)
О, отличный топик-кунсткамера.
1) На чистом С код быстрее

пруфов бы