Розробка · 7 січня 2013, 19:48 9379

Роман Цюпа, Lead Dev в EPAM

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

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

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

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

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: development, Programming, ООП

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Найкращі коментарі пропустити

anonymous 07.01.2013 21:51

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

Перейти до дискусії

Ctrl + Enter

Ctrl + Enter

Serhii Kosyi Software developer в eBogholderen.dk and Revisor1.dk 01.05.2014 13:58

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

Відповісти

Підтримати

Vadym Liapin Oracle PL/SQL TechLead в Dukascopy Bank 29.04.2014 07:31

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

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

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

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

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

Відповісти

Підтримати

Михаил Кузьмин 29.04.2014 08:25

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

Відповісти

Підтримати

Ще 6 коментарів

undefined pointer 29.04.2014 09:27

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 10:45

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

Відповісти

Підтримати

undefined pointer

Настасий Петрович 29.04.2014 11:14

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

Відповісти

Підтримати

undefined pointer

Михаил Кузьмин 29.04.2014 11:40

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

Відповісти

Підтримати

Настасий Петрович

undefined pointer 30.04.2014 18:57

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

Відповісти

Підтримати

Настасий Петрович

Vadym Liapin Oracle PL/SQL TechLead в Dukascopy Bank 29.04.2014 14:37

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

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

Відповісти

Підтримати

Михаил Кузьмин

AlekseyB Berezan Coding в IDE 27.04.2014 12:33

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

Відповісти

Підтримати

Настасий Петрович 26.04.2014 22:01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 22:20

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

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

Відповісти

Підтримати

Настасий Петрович

Ще 6 коментарів

Настасий Петрович 26.04.2014 22:51

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

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

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

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

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 23:21

Что значит читать дальше не надо?!

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

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

Слышал. А теперь задача:

a() {
  if (b()) {
    c1();
  } else {
    c2();
  }
}

b, c1, c2 уже протестированы и сами по себе требуют сложного сетапа (инициализации БД, глобального скоупа и тд). Как мне протестировать логику a? В случае с ООП, я просто укажу что объект у которого есть метод a принимает зависимости на объекты содержащие b, c1, c2.
В случае с процедурным Ц, «подмена» модулей/зависимостей происходит не на уровне языка (подмена объектов), а на уровне фантазии программиста (подключение других ДЛЛ, файлов и тд).

Відповісти

Підтримати

Настасий Петрович

Настасий Петрович 26.04.2014 23:53

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 27.04.2014 00:41

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

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

Тестить тяжело.

Как я узнаю внутрення состояние private объектов. КАК?

Легко. Делаете конструктор который принимает m_b, m_c1, m_c2 и инициализируете их или моками/стабами или реальными объектами. Вы управляете состоянием и тестируете только поведение SUTа.
.

Вы должны в a() предать указатель на декриптор библотеки.

Но если у вас процедура с over 9000 параметрами, вы вообще программист???

3-5 зависимостей (указателей на дискрипторы библиотек) + 3-5 параметров == over 9000 параметров :)

А для тестирования ОДНОГО ОБЪЕКТА вам нужно вызывать все его методы в различных порядках.

Нет.

А у процедуры ОДНОЙ нет такого состояния.

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

Відповісти

Підтримати

Настасий Петрович

Настасий Петрович 27.04.2014 10:42

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

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

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

Відповісти

Підтримати

Михаил Кузьмин 28.04.2014 17:33

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

Відповісти

Підтримати

Alexandr Gavriluk 26.04.2014 19:18

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

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 19:59

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

Что за бред?! Откуда такие цифры? Пара переходов по ссылкам дает просадку производительности в 2-4(3-5) раза?

Відповісти

Підтримати

Alexandr Gavriluk

Ще 13 коментарів

Alexandr Gavriluk 26.04.2014 20:17

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:27

Даже от изменения направления прохода по двумерному массиву скорость алгоритма может изменится в 5-10 раз (по строкам или по столбцам).

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

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:33

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:41

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:44

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

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

Відповісти

Підтримати

Alexandr Gavriluk 26.04.2014 20:23

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:29

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

Пруфф на бочку.

Не могут же Гуглы ошибаться?

1) Могут.
2) Ц против джавы — это параллельный срач обсуждению ООП против процедурного стиля.

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:35

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

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:39

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

«Проект Apache Hadoop — бесплатная реализация MapReduce с открытым исходным кодом на языке Java.»
Но там наверное так же от джавы только компилятор.

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

И снова пруфф!

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:40

И снова пруфф!

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:43

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:45

MapReduce — это не «поисковик Гугл»

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:51

MapReduce — это не «поисковик Гугл»
Это его движок.

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

Відповісти

Підтримати

Alexandr Gavriluk

fizz buzz 26.04.2014 20:04

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

Відповісти

Підтримати

Alexandr Gavriluk

Ще 5 коментарів

Alexandr Gavriluk 26.04.2014 20:29

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:32

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

ООП не отрицает использование управляющих конструкций и локальных переменных.

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 26.04.2014 20:37

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 20:49

Если же процесс проще представить в виде функции, то использование ООП ведет к падению производительности.

Понятно. Веселого срача тут не получитсо, вы «сравниваете теплое с мягким».

Відповісти

Підтримати

Alexandr Gavriluk

fizz buzz 26.04.2014 21:40

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

Відповісти

Підтримати

Alexandr Gavriluk

Настасий Петрович 26.04.2014 17:51

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

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

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

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

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

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

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

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

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

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

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

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

И функциональщина тоже далека от представления информации. Изучения Хаскеля может прекратиться на монадах.

Відповісти

Підтримати

Михаил Кузьмин 26.04.2014 14:28

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.04.2014 15:39

Не все модели укладываются в ООП.

Например?

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

Кто сказал?

Відповісти

Підтримати

Михаил Кузьмин

Ще 30 коментарів

Михаил Кузьмин 28.04.2014 18:06

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 28.04.2014 18:15

Это принцип ООП. Для того что б создать объект нужно иметь класс.

Если не впадать в философию, то такого принципа нет (или же дайте ссылку на него).

Но, отсюда много проблем с эффективностью и обнаружением ошибок

Та пока проблем не особо проявляется.

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 06:35

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 29.04.2014 09:10

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

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 10:49

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 13:15

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

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

И? vmt + static methods не напрягает же реализовывать.
может, я что-то недопонимаю?

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 13:29

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 15:12

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 15:38

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 16:45

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 20:16

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

Відповісти

Підтримати

Євген Козлов

Bogdan Shyiak SE or Dev 29.04.2014 12:08

которой основными концепциями являются понятия объектов и классов.

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.

.

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

В чем сложность?

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

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 12:49

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 29.04.2014 13:18

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

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

речь про RTTI?

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 13:47

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 15:16

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 15:47

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 16:51

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 20:17

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 29.04.2014 23:47

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 30.04.2014 10:28

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 30.04.2014 10:51

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 30.04.2014 11:36

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 30.04.2014 12:02

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

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

Відповісти

Підтримати

Михаил Кузьмин

Євген Козлов Front-end developer в SoftServe 28.04.2014 18:28

обнаружением ошибок

например, какие сложности?

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 06:35

Ответил выше.

Відповісти

Підтримати

Євген Козлов

Иван Фонотов .Net developer 28.04.2014 19:15

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 06:44

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

Відповісти

Підтримати

Иван Фонотов

Иван Фонотов .Net developer 29.04.2014 08:53

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

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

Відповісти

Підтримати

Михаил Кузьмин

Михаил Кузьмин 29.04.2014 10:57

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

Відповісти

Підтримати

Иван Фонотов

Gabriel Angelos 26.04.2014 13:34

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

Відповісти

Підтримати

Горунов Антон Software Developer в LL 26.04.2014 12:56

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

Відповісти

Підтримати

flyman 06.03.2013 09:14

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

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

=====

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

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

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

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

Відповісти

Підтримати

Усачев Олег 17.01.2013 09:25

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

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

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

Відповісти

Підтримати

Кирилл Нечаев 16.01.2013 07:49

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

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

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

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

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

текст программы <-> мышление человека.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

текст_программы <-> программист <-> бизнес

И в отличие от болта для болида, здесь есть обратная связь, которая очевидна всем: чем быстрее скорость на участке

текст_программы <-> программист <-> бизнес

, тем медленнее скорость

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

Обратная связь, а она здесь отрицательная, приводит к стабильности и стагнации. А рынок давит.

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

Відповісти

Підтримати

anonymous 16.01.2013 11:29

-

Відповісти

Підтримати

Кирилл Нечаев

Ще 5 коментарів

Кирилл Нечаев 17.01.2013 08:19

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

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

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

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

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

Відповісти

Підтримати

flyman 18.01.2013 23:48

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

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

А процы и так подтянутся.

Підтягнуться, але вже не так швидко, як це передбачає «Закон Мура».

Відповісти

Підтримати

Кодерок Формошлепов 19.01.2013 19:58

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

Відповісти

Підтримати

flyman 19.01.2013 20:06

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

Відповісти

Підтримати

Кодерок Формошлепов

Иван Фонотов .Net developer 30.04.2014 14:04

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

Для программиста — да, но не для индустрии в целом.

Відповісти

Підтримати

Апполинарий Эмануилович 16.01.2013 15:15

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

Відповісти

Підтримати

Кирилл Нечаев

Ще 5 коментарів

Кирилл Нечаев 17.01.2013 09:00

Рынок всё сделает за Вас, у него естественный отбор

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

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

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

Відповісти

Підтримати

Апполинарий Эмануилович

Апполинарий Эмануилович 17.01.2013 12:52

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

>>>>> OFFTOP >>>>>>>

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

Відповісти

Підтримати

Кирилл Нечаев

Кирилл Нечаев 18.01.2013 15:08

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

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

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

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

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

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

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

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

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

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

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

Відповісти

Підтримати

Апполинарий Эмануилович

Апполинарий Эмануилович 19.01.2013 00:26

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

Відповісти

Підтримати

Кирилл Нечаев

flyman 19.01.2013 20:17

Это всё благодаря «чрезвычайно зауженному кругозору» ИТ специалистов.

Электроника быстрее развивалась, чем информатика.
Наверно благодаря проффесионалам от ИТ, и «чрезвычайно зауженному кругозору», с которым застряли на концепции 80х годов прошлого века (ООП).

Відповісти

Підтримати

Апполинарий Эмануилович

proger 15.01.2013 19:13

java way выстрела в ногу
thedailywtf.com/...t-of-Trees.aspx

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 15.01.2013 19:29

java way выстрела в ногу
thedailywtf.com/...t-of-Trees.aspx

И че? Какое это имеет отношение к ООП?

Відповісти

Підтримати

Ще 5 коментарів

proger 15.01.2013 21:04

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

Відповісти

Підтримати

reality_hacker 15.01.2013 21:08

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

Відповісти

Підтримати

proger 15.01.2013 21:19

ок. чисто java way

Відповісти

Підтримати

reality_hacker 15.01.2013 21:20

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 16.01.2013 06:37

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

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

Відповісти

Підтримати

Grez 15.01.2013 21:51

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

Відповісти

Підтримати

proger 11.01.2013 21:50

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

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 13.01.2013 05:50

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

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

Відповісти

Підтримати

Ще 1 коментар

proger 15.01.2013 19:03

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

Відповісти

Підтримати

Iaroslav Voitovych

Alexandr Gavriluk 11.01.2013 18:42

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

Відповісти

Підтримати

proger 11.01.2013 21:00

а зачем ненужно, показать такой
code.google.com/...l/db/Union.java

Відповісти

Підтримати

Alexandr Gavriluk

Mykhailo Troianovskyi Software Engineer в Grammarly 11.01.2013 13:30

Ещё бывает ООП головного мозга.
Как два программиста хлеб пекли

Відповісти

Підтримати

Alexandr Gavriluk 11.01.2013 17:59

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

Відповісти

Підтримати

Mykhailo Troianovskyi

Alexandr Gavriluk 11.01.2013 18:03

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

Відповісти

Підтримати

Mykhailo Troianovskyi

Iaroslav Voitovych ¡sí, señor! 13.01.2013 05:27

Какая няшечка... МЕГА СПАСИБО!!!

ООП головного мозга

В мемориз! :)

Відповісти

Підтримати

Mykhailo Troianovskyi

Апполинарий Эмануилович 11.01.2013 12:47

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

Відповісти

Підтримати

Alexandr Gavriluk 11.01.2013 17:51

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

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

Відповісти

Підтримати

Апполинарий Эмануилович

Ще 1 коментар

Апполинарий Эмануилович 11.01.2013 23:16

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

Відповісти

Підтримати

Alexandr Gavriluk

Mykhailo Troianovskyi Software Engineer в Grammarly 10.01.2013 19:44

“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

Відповісти

Підтримати

Sandro Zakusilov 11.01.2013 00:49

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

Відповісти

Підтримати

Mykhailo Troianovskyi

Alexandr Gavriluk 10.01.2013 17:46

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

Відповісти

Підтримати

Ivan Pomidorov 10.01.2013 18:37

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

Відповісти

Підтримати

Alexandr Gavriluk

Ще 3 коментарі

Blitz Senior .net Developer / Architect 10.01.2013 23:34

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

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 13.01.2013 05:59

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

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

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 15.01.2013 16:37

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

Відповісти

Підтримати

Iaroslav Voitovych

Dmytro Riabov 10.01.2013 21:13

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

Відповісти

Підтримати

Alexandr Gavriluk

Ще 46 коментарів

Alexandr Gavriluk 10.01.2013 21:24

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

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

Відповісти

Підтримати

Dmytro Riabov 10.01.2013 21:32

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

Відповісти

Підтримати

Alexandr Gavriluk

undefined pointer 10.01.2013 22:25

описывающая предметную область.

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

Математика без предметной области подходит

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

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

а-а-а, «прикладная», презираемая математиками...

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

ах вот почему я не видел чтобы ее применяли в программировании...

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

Відповісти

Підтримати

Alexandr Gavriluk

Ivan Pomidorov 11.01.2013 00:13

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

Например, статистика, data mining, алгоритмы на графах.

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

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

Відповісти

Підтримати

undefined pointer

Viacheslav 11.01.2013 00:52

геймдев

Если копнуть геймдев то в казуальном 2д геймдеве математика не особо сложная. В нормальном геймдеве намного по сложнее

Відповісти

Підтримати

Dmytro Riabov 11.01.2013 01:03

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 11.01.2013 01:07

статистика, data mining

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

алгоритмы на графах

отображение «общих друзей»? алгоритм на графах?

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

Відповісти

Підтримати

Dmytro Riabov 11.01.2013 01:09

Какой функционал фейсбука это использует?

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 11.01.2013 09:38

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

Відповісти

Підтримати

undefined pointer 11.01.2013 09:42

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

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

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

Відповісти

Підтримати

Євген Козлов

reality_hacker 11.01.2013 10:33

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 10:39

машинлернинг

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

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

???

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

Відповісти

Підтримати

reality_hacker 11.01.2013 10:42

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 11:11

Когда есть миллиард юзеров и 100 миллионов сигналов

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

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

Відповісти

Підтримати

reality_hacker 11.01.2013 11:14

не сталкивался

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 13:16

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

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

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

Відповісти

Підтримати

reality_hacker 11.01.2013 21:04

пусть ламеры и ходят на эти курсы.

Ну да, я поэтому тебе и посоветовал.

Словей понагулил, а «слышал звон да не знаешь где он»

С чего ты взял? У меня как раз вполне практические навыки и я их регулярно применяю на реальных задачах.

Відповісти

Підтримати

undefined pointer

Oleg Tyshchenko 14.01.2013 15:02

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

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

Відповісти

Підтримати

undefined pointer

Євген Козлов Front-end developer в SoftServe 14.01.2013 20:20

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

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 14.01.2013 20:26

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.01.2013 21:38

Логика и несколько аксиом.

Відповісти

Підтримати

Oleg Tyshchenko

Alexandr Gavriluk 11.01.2013 11:43

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 07:56

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

вот как раз это ПО и доводилось писать. Е*сь в рот дальше, там математика только в — рандомайезере.

Відповісти

Підтримати

Grez 11.01.2013 09:02

крипография, шифрование ( без теор. вера не разобраться )

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

Відповісти

Підтримати

undefined pointer 11.01.2013 09:11

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

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

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

Відповісти

Підтримати

Grez

Kirill Sablin Developer 11.01.2013 09:26

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 09:36

Зато при помощи математики можно получить оценку среднего/худшего случая.

уже писал — это можно и без математики :)

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

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

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

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

С какой — целью? Кому — доказать?
На философском диспуте блеснуть?
Ну этот, который математический?

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 09:45

С какой — целью? Кому — доказать?

Чтобы не искать алгоритм такого типа быстрее. Это мало?

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 09:53

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

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

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 09:56

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 09:57

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

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

строгое обоснование.

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

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 10:03

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 10:11

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

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

Я знаю как работает b-tree

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

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

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 10:19

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

поэтому там используется b-tree, а не что-то другое. Вы, видимо, не отличаете бинарное дерево от b-tree.

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 10:27

Вы, видимо, не отличаете бинарное дерево от b-tree.

аха.
на том и закончим.

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 10:29

Ок

Відповісти

Підтримати

undefined pointer

reality_hacker 11.01.2013 11:00

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

Тебе знание б три мало поможет, т.к. почти везде применяют б+ три, что немного другая штука.

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 11:21

b+ конечно.

Відповісти

Підтримати

Нестор Иванович 11.01.2013 10:10

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

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 10:22

вам череп не жмет

нет, все нормально

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 11.01.2013 10:24

ок, я волновался просто.

Відповісти

Підтримати

Ivan Pomidorov 11.01.2013 15:07

Профайлер в руки, расставляй счетчики и кури логи.

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 15:20

Ну дурак

вот спасибо, вот приятно что не нужна мне лоботомия :D

Відповісти

Підтримати

Kirill Sablin Developer 11.01.2013 15:59

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

Справедливости ради — в случае квиксорта средний случай не очевиден (если не знать заранее).

Відповісти

Підтримати

Alexandr Gavriluk 11.01.2013 01:15

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 08:00

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

Можно и по твиттеру.

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

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

Відповісти

Підтримати

Alexandr Gavriluk

undefined pointer 10.01.2013 22:22

повторюсь

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Ще 57 коментарів

Kirill Sablin Developer 10.01.2013 22:31

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 22:32

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

Программист может пользоваться такой абстракцией?

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

Відповісти

Підтримати

Kirill Sablin Developer 10.01.2013 22:39

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 22:52

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

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

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

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

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

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

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

Відповісти

Підтримати

Kirill Sablin Developer 10.01.2013 23:05

это формализованный термин

ну вот вам пример — математика добавляет общий язык

экспоненциального роста

это понятие видимо из археологии :)

займусь нахождением эвристик

Зная, что не известно более оптимального варианта:) Опять-таки это знание так или иначе пришло из математики:)

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 23:12

ну вот вам пример — математика добавляет общий язык

кому добавляет :)

это понятие видимо из археологии :)

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

Опять-таки это знание так или иначе пришло из математики:)

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

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

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

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

Відповісти

Підтримати

Kirill Sablin Developer 10.01.2013 23:21

кому добавляет :)

например двум взаимодействующим программистам

Не понял, погуглил:

Это был сарказм. Естественно понятие из математики.

без математики бытенько убеждается что программа то работает

И он не сделает попыток найти более оптимальное решение?

Какую еще математику привлекать

Она уже была использована

Відповісти

Підтримати

undefined pointer

Alexandr Gavriluk 11.01.2013 01:09

Экспоненциальный рост

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

Відповісти

Підтримати

undefined pointer

Dmytro Riabov 11.01.2013 01:10

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

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 11.01.2013 01:17

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

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

Відповісти

Підтримати

Grez 11.01.2013 09:22

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

Все всегда это объясняли без какой либо математики.

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 11.01.2013 01:13

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 07:53

Все эвристики подчиняются принципам комбинаторики.

важно не то чем они объясняются, а КАК они придумываются.

выделение признаков и построение целевой функции.

я еще не встречал людей и даже не слышал — кто так делает.

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

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

Привожу определения:

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

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Oleg Tyshchenko 14.01.2013 15:06

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

Відповісти

Підтримати

undefined pointer

Alexandr Gavriluk 11.01.2013 01:06

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 13:08

Вот так заказчик и поставит задание

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

вот только нет четкой формализованности

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

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

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

Відповісти

Підтримати

Alexandr Gavriluk

proger 11.01.2013 00:38

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 07:55

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

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

Відповісти

Підтримати

proger 11.01.2013 08:07

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 08:08

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

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

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

Відповісти

Підтримати

proger 11.01.2013 08:15

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 08:35

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

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

Відповісти

Підтримати

proger 11.01.2013 08:57

а «пространство понятия».

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 09:17

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

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

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

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

Відповісти

Підтримати

proger 11.01.2013 10:17

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 10:36

в результате вы не математику будете критиковать

вообще то я ее и не критиковал :D
речь была о степени ее применимости, полезности в компьютерном программировании.

ваш мозк решает вполне себе мат.задачу

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

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

Відповісти

Підтримати

Alexandr Gavriluk 11.01.2013 11:58

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

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

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

Відповісти

Підтримати

proger 11.01.2013 12:15

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

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 11.01.2013 12:42

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

Відповісти

Підтримати

undefined pointer 11.01.2013 12:20

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

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

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

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

Замечательно! Философию где изучали?

Відповісти

Підтримати

Alexandr Gavriluk

Alexandr Gavriluk 11.01.2013 12:38

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 12:48

Автоматизированная система оптимизации оптово-розничных продаж мебели на основе нечеткой логики

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

Форекс трейдинг вообще на математике весь построен

да что вы говорите! :D
математика уже научилась прогнозировать курсы валют???

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

А вообще оптимизация матмодели под предметку стоит от 10000$.

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Iaroslav Voitovych ¡sí, señor! 14.01.2013 02:52

А вся эта «математика с анализом» — выкидывается в корзину

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

Відповісти

Підтримати

undefined pointer

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 11:11

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

Відповісти

Підтримати

proger 11.01.2013 11:34

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

хаскель, sql вроде живы

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 11:45

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

Відповісти

Підтримати

proger 11.01.2013 11:53

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

вполне себе являются.

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

Відповісти

Підтримати

undefined pointer 11.01.2013 12:16

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

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

Відповісти

Підтримати

Alexandr Gavriluk 11.01.2013 12:39

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 12:50

но там тоже математика или гениальность дизайнера.

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

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

Существуют эвристические матметоды оценки

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

Відповісти

Підтримати

Alexandr Gavriluk

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 12:52

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

Відповісти

Підтримати

reality_hacker 11.01.2013 21:17

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

Это с какими?

Відповісти

Підтримати

proger 11.01.2013 21:39

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

Відповісти

Підтримати

reality_hacker 11.01.2013 21:45

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

Відповісти

Підтримати

Нестор Иванович 11.01.2013 22:03

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

Відповісти

Підтримати

reality_hacker 11.01.2013 22:06

CTE часть ANSI SQL 99: en.wikipedia.org/...cursive_queries

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 11.01.2013 22:30

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

Відповісти

Підтримати

Нестор Иванович 11.01.2013 22:05

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

Відповісти

Підтримати

proger 11.01.2013 22:10

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

Відповісти

Підтримати

Нестор Иванович

Oleg Tyshchenko 14.01.2013 15:08

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 15.01.2013 11:19

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

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 15.01.2013 11:24

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 12:24

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 13:03

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 13:11

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 13:14

Коментар порушує правила спільноти і видалений модераторами.

Igor Chornous 15.01.2013 13:24

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 13:54

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 13:53

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 14:23

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 14:34

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 14:53

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 15:02

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 15:03

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 16:12

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 16:22

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 16:29

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 16:30

Коментар порушує правила спільноти і видалений модераторами.

trimm Developer/Independent contributor в IDAP 15.01.2013 16:34

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 15.01.2013 16:37

Коментар порушує правила спільноти і видалений модераторами.

Oleg Tyshchenko 14.01.2013 15:03

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

Відповісти

Підтримати

undefined pointer

Євген Козлов Front-end developer в SoftServe 14.01.2013 20:18

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

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 14.01.2013 20:28

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.01.2013 21:39

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

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 14.01.2013 21:40

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 14.01.2013 23:55

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

Відповісти

Підтримати

Oleg Tyshchenko

Ivan Pomidorov 11.01.2013 00:20

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

Відповісти

Підтримати

Alexandr Gavriluk

Ще 5 коментарів

undefined pointer 11.01.2013 08:53

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

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

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

Відповісти

Підтримати

proger 11.01.2013 09:16

и шаманят, и лепят грязные хаки.

прелесть в том, что эти шаманства тоже есть математикой

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 10:41

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

Відповісти

Підтримати

proger 11.01.2013 11:01

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

Відповісти

Підтримати

undefined pointer

flyman 13.01.2013 11:05

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

Відповісти

Підтримати

Васисуалий Лоханкин 10.01.2013 11:42

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

Відповісти

Підтримати

undefined pointer 10.01.2013 12:48

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

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

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

Відповісти

Підтримати

Васисуалий Лоханкин

Ще 48 коментарів

Oleg Tyshchenko 10.01.2013 13:36

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 14:19

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

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

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

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

Відповісти

Підтримати

Oleg Tyshchenko

Alexandr Gavriluk 10.01.2013 17:34

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 22:16

Не сказал бы, математика это более высокий уровень абстракции чем ООП

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

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

обычно обходился — разнообразной профилиривкой при стресс-тестировании. Поиском и устранением оверхедов, реорганизацией алгоритмов, или, как привел пример — заменой ОО реализации критически нагруженных сущностей на более близкие к железу.
Можно и — перейти на ассемблерные вставки, или, в случае JVM, реализации на plain C и подключением с помощью JNI/JNA
Математика может от этого избавить? Буду признателен, чтобы впредь не тратить время озвученный выше немалый кусок работы и мыслительной деятельности.

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

Каких изображений, в какой базе, по каким критериям?
Не умею ставить «диагноз по фото» :)

поиска названий фирм по базе без единого справочника контрагентов

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

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

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

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

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

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

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

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

Відповісти

Підтримати

Alexandr Gavriluk

proger 11.01.2013 00:51

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

Відповісти

Підтримати

undefined pointer

Євген Козлов Front-end developer в SoftServe 11.01.2013 01:08

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

Відповісти

Підтримати

proger 11.01.2013 01:12

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

Відповісти

Підтримати

Євген Козлов

undefined pointer 11.01.2013 08:01

у вас некое извращенное понимание математики.

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

Відповісти

Підтримати

proger 11.01.2013 08:11

Весьма сожалею что в жизни почти не встречал математиков.

в зеркало посмотритесь :)

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 08:17

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

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

Відповісти

Підтримати

proger 11.01.2013 09:07

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 09:30

возможно в виду недостаточного знания теории

я уже сказал, почему мне нечто кажется :)

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

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

оптимизация является некоей эвристикой данной сверху,

не слышал — других эвристик :)

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

просто в виде формул никто не поймет.

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

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

Відповісти

Підтримати

proger 11.01.2013 10:09

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 11:22

язык программирования — это математическая абстракция

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

(языка программирования)

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

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

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

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

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

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

Відповісти

Підтримати

proger 11.01.2013 11:50

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

вы нет. ваш мозк — да

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 12:35

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

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

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

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

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 11:26

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

Відповісти

Підтримати

undefined pointer 11.01.2013 11:37

И кстати, математика != абстракция реального мира

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

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

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

Відповісти

Підтримати

proger 11.01.2013 11:39

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

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

Відповісти

Підтримати

undefined pointer 11.01.2013 11:49

а уж яп в свою очередь является абстракцией внутренностей компа

в общем случае — не является :D
Ни Lisp, ни Haskell, ни Prolog, :)

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

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

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

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

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

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

Відповісти

Підтримати

proger 11.01.2013 11:58

в общем случае — не является :D
Ни Lisp, ни Haskell, ни Prolog, :)

ой ли ? тогда программы на них не смогли бы запуститься на компе впринципе.
попробуйте стихи скомпилить\запустить :)

Программирование по сути — не математическая задача

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 12:25

ой ли ?

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

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

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

тогда программы на них не смогли бы

да, да, если б не Бог — не почесать мне затылок никак. стопицот процентов согласия!

я вам пенроуза уже советовал.

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

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

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

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 12:04

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 12:28

Так ведь критиканы ООП должны

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

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

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 11:51

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

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

Відповісти

Підтримати

proger 11.01.2013 12:02

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

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

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 12:25

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

Відповісти

Підтримати

undefined pointer 11.01.2013 12:33

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

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

Есть описание требуемого от вычислительной системы результата

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

Відповісти

Підтримати

Anton Hoffman отшельникъ в горахъ голливудскихъ 11.01.2013 13:18

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

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 13:32

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

да, согласен. особенно в случае когда ее и нет.

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

что веб-магазины являются моделью магазинов физического мира,

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

Не очень-то понял аналогию.

та и ладно, не суть она важна была :)

Відповісти

Підтримати

undefined pointer 11.01.2013 12:29

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

Відповісти

Підтримати

Oleg Tyshchenko 12.01.2013 00:36

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

Відповісти

Підтримати

undefined pointer

Oleg Tyshchenko 11.01.2013 12:29

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

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

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

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

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

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

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

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

Відповісти

Підтримати

undefined pointer

Oleg Tyshchenko 11.01.2013 12:35

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

Відповісти

Підтримати

Oleg Tyshchenko

undefined pointer 11.01.2013 13:40

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

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

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

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

Відповісти

Підтримати

Oleg Tyshchenko

undefined pointer 11.01.2013 13:37

Теории Категорий.

Аристотель.

Ну и сейчас этими проблемами занимается реляционная алгебра.

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

Рекурсия кстати тоже давно была известна математикам.

Рекурсия известна и высшим и приматам, и врановым.
Не надо приписывать математике функции Бога-Творца.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 11.01.2013 13:48

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 13:53

Рекурсия кстати тоже давно была известна математикам.

а еще давнее животным. они тоже математики?

как математика это теория

теория ап чем?
Огласите предмет изучения.

как математика это теория

у меня, просто обязательно :D
это все знают какой я упоротый ортодокс :D

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 11.01.2013 13:58

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

Відповісти

Підтримати

undefined pointer

undefined pointer 11.01.2013 14:00

Тебя уже ничего не спасет.

ну чего ж, лоботомия вполне :D

Відповісти

Підтримати

Oleg Tyshchenko

Євген Козлов Front-end developer в SoftServe 11.01.2013 14:28

К примеру, типы в программировании спросите вы? Все это давно уже было формализировано в Теории Категорий.

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

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

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

Відповісти

Підтримати

Oleg Tyshchenko

undefined pointer 11.01.2013 14:57

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

Відповісти

Підтримати

Євген Козлов

Oleg Tyshchenko 11.01.2013 15:07

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

Відповісти

Підтримати

undefined pointer

Oleg Tyshchenko 11.01.2013 15:05

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

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 11.01.2013 22:01

Лингвистика использует математику

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

физика так вообще без математики невозможна

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

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

отлично! математика помогла вывести новый алгоритм?

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 12.01.2013 00:32

да помогла.

Відповісти

Підтримати

Євген Козлов

anonymous 10.01.2013 13:41

-

Відповісти

Підтримати

undefined pointer

Ivan Pomidorov 10.01.2013 14:07

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

Відповісти

Підтримати

undefined pointer

proger 10.01.2013 13:57

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

Відповісти

Підтримати

Васисуалий Лоханкин

Ще 12 коментарів

Arthur Mubarakshyn Software Developer в Ciklum 10.01.2013 15:27

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

Відповісти

Підтримати

reality_hacker 10.01.2013 19:02

А KFC как пошел в массы!

Відповісти

Підтримати

Arthur Mubarakshyn

Grez 10.01.2013 21:50

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

Відповісти

Підтримати

reality_hacker 10.01.2013 21:51

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

Відповісти

Підтримати

Grez

Grez 10.01.2013 21:55

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

Відповісти

Підтримати

reality_hacker 10.01.2013 21:57

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

Відповісти

Підтримати

Grez

Oleg Tyshchenko 14.01.2013 20:50

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

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.01.2013 20:59

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

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 14.01.2013 21:04

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

Відповісти

Підтримати

Mike Gorchak Graphics Device Driver Developer в QNX Software Systems 14.01.2013 21:13

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

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

Відповісти

Підтримати

Oleg Tyshchenko

Grez 14.01.2013 23:41

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

Відповісти

Підтримати

Oleg Tyshchenko

trimm Developer/Independent contributor в IDAP 15.01.2013 11:21

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

Відповісти

Підтримати

Vitaliy Kupchynskyy DM 10.01.2013 11:26

ru.wikipedia.org/...рограммирование

Відповісти

Підтримати

anonymous 10.01.2013 10:51

-

Відповісти

Підтримати

Mykola Gurov тролль 10.01.2013 02:29

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

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 10.01.2013 06:02

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

Відповісти

Підтримати

Ще 17 коментарів

Bogdan Shyiak SE or Dev 10.01.2013 07:53

к DOD не имеет ни малейшего отношения.

Уже не забавно.

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 11.01.2013 04:04

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

Відповісти

Підтримати

Grez 11.01.2013 09:30

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

Відповісти

Підтримати

Iaroslav Voitovych

Mykola Gurov тролль 11.01.2013 11:09

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

Відповісти

Підтримати

Grez

Grez 11.01.2013 14:16

Та «мы» вкурсе.

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 13.01.2013 03:06

та троллит он нас

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 13.01.2013 04:50

а) выигрывает у ООП

Ваапшета параллелен ООП. Его вполне можно применять как внутреннюю архитектуру.

б) предотвращает ООПные фейлы

Фейлы или «перформенс-фейлы»?

в) крайне мало кому знаком,

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

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 13.01.2013 05:06

Ваапшета параллелен ООП. Его вполне можно применять как внутреннюю архитектуру.

Ещё раз — нет.
Я уже объяснял всё предельно просто и подробно, раза три здесь в ветке. Вы не дочитали? Не поняли? Блин, блин, блин. Я в ступоре. Я могу это сделать ещё раз, но такое ощущение, как будто объясняешь меметику сандеисту.

Фейлы или «перформенс-фейлы»?

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

Куда более эффективным было бы или дать ссылку

Блин блин блин — 2.
Здесь в теме этих ссылок — ну штук пять...

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 13.01.2013 05:23

Вы не дочитали?

Конкретно в этой ветке не было. В других и не смотрел.
Повторяю:
Если ваша первоначальная цель была

я надеялся наглядно показать публике подход

то «нэ залык», по описанным мною причинам ( + вы еще первые комменты отвечали «погугли»)

Не просто «перформенс-фейлы», а такие фейлы, когда оверхед вызванный а) любовью к ООП и б) полным игнорированием производительности

А ну-ка, какое первое правило оптимизации?
Более подробно:
Какие проблемы вызывает «любовь к ООП»? В теме на 600 комментов аргументов не особо-то. Даже заезженная мутабольность — это не столько проблема ООП, сколько конкретных людей.

б) полным игнорированием производительности

А ООП требует этого?

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 14.01.2013 02:47

Конкретно в этой ветке не было.

Было. Но расписал ещё раз, вот чуть ниже. dou.ua/...comments#280028

Відповісти

Підтримати

Mykola Gurov тролль 13.01.2013 19:16

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

а) выигрывает у ООП

как уже тут было сказано, DOD — это не парадигма. Это просто техника. Ее применение никак не противоречит ООП. По крайней мере по краткому просмотру ссылок приведенных.

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 14.01.2013 02:44

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

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

Відповісти

Підтримати

Blitz Senior .net Developer / Architect 14.01.2013 09:22

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

Відповісти

Підтримати

Iaroslav Voitovych

Mykola Gurov тролль 14.01.2013 22:54

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

Відповісти

Підтримати

Iaroslav Voitovych

Grez 14.01.2013 23:48

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

Відповісти

Підтримати

Iaroslav Voitovych

Dmytro Riabov 15.01.2013 00:13

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

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

Відповісти

Підтримати

Grez

Mykola Gurov тролль 15.01.2013 00:49

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

Відповісти

Підтримати

Ivan Pomidorov 10.01.2013 02:15

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

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

Відповісти

Підтримати

Grez 10.01.2013 09:40

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

Відповісти

Підтримати

AAAA 10.01.2013 10:33

Коментар порушує правила спільноти і видалений модераторами.

AL AL 10.01.2013 00:07

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

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

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

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

Відповісти

Підтримати

Dmytro Riabov 10.01.2013 00:20

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

Відповісти

Підтримати

AL AL

Ivan Pomidorov 10.01.2013 02:20

під конкретну модель можна використати і ФП і DOD і ООП

Згоден, професіонал обере з наявних методологiй та инстументiв той який буде найбiльш привабливий йому, за якимись критерiями, будь це хоча б

бажанням попрактикуватися в новій технології

або бюджет.

Відповісти

Підтримати

AL AL

Кирилл Нечаев 10.01.2013 08:13

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

Відповісти

Підтримати

AL AL

Андрей Никишаев 09.01.2013 20:11

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

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

Відповісти

Підтримати

Arthur Mubarakshyn Software Developer в Ciklum 09.01.2013 23:57

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

Відповісти

Підтримати

Андрей Никишаев

Arthur Mubarakshyn Software Developer в Ciklum 09.01.2013 23:58

Но я с вами согласен =]

Відповісти

Підтримати

Андрей Никишаев

Вася Петечкин 09.01.2013 16:10

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

Відповісти

Підтримати

Alex Kot 09.01.2013 15:43

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

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

Відповісти

Підтримати

Yuri Bilyk swe 09.01.2013 14:11

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 09.01.2013 11:54

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

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 09.01.2013 12:03

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

Відповісти

Підтримати

Євген Козлов

Iaroslav Voitovych ¡sí, señor! 09.01.2013 05:03

(перепост)
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
Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной, если с рисования иерархий классов — нет. А если с первых строк начинают фигурировать словечки типа обджект фектори и синглетон — запасайтей попкорном, будет эпик фейл.

Відповісти

Підтримати

reality_hacker 09.01.2013 05:06

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.

Відповісти

Підтримати

Iaroslav Voitovych

Ще 4 коментарі

Iaroslav Voitovych ¡sí, señor! 09.01.2013 05:14

Все равно это сливает перед KFC

— Kill the Fucked Coder
— Krazzy Fucking Coding
— Kudos, Fucking Coder!
В любом варианте написания — сливает однозначно. LOL

Відповісти

Підтримати

reality_hacker 09.01.2013 05:15

В любом варианте написания — сливает однозначно. LOL

очевидно от пейсателя зависит

Відповісти

Підтримати

Iaroslav Voitovych

Sandro Zakusilov 09.01.2013 07:42

Может — Kill the Fucking Cycler?

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 10.01.2013 05:14

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

Відповісти

Підтримати

Sandro Zakusilov

undefined pointer 09.01.2013 08:24

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

я только одного не пойму — а что все вот это — наращивает??? ассемблер? «plain C»? «LISP»??

Если дизайн системы начинается с анализа потоков данных — у системы есть шанс стать успешной и даже эффективной

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

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

Я вот уж какой год не пойму, таких тезисов:
Немеряно ПО написано именно с ООП, сикось или накось, но — «эпик фейл»

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

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

Відповісти

Підтримати

Iaroslav Voitovych

Anton Hoffman отшельникъ в горахъ голливудскихъ 09.01.2013 12:18

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

Відповісти

Підтримати

Iaroslav Voitovych

Ще 4 коментарі

Iaroslav Voitovych ¡sí, señor! 10.01.2013 06:16

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

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

Відповісти

Підтримати

Eugene Koval developer в Yola 10.01.2013 07:11

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

Відповісти

Підтримати

Iaroslav Voitovych

Anton Hoffman отшельникъ в горахъ голливудскихъ 10.01.2013 12:51

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

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

...

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

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

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 11.01.2013 03:17

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

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

Відповісти

Підтримати

undefined pointer 09.01.2013 13:08

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!
;)

Відповісти

Підтримати

Iaroslav Voitovych

Ще 3 коментарі

Iaroslav Voitovych ¡sí, señor! 13.01.2013 04:14

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

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

Відповісти

Підтримати

undefined pointer

flyman 13.01.2013 11:37

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

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

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 14.01.2013 02:26

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

Відповісти

Підтримати

iddqd 09.01.2013 00:37

>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(..)» ?

Відповісти

Підтримати

Dmytro Riabov 09.01.2013 00:40

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

такое словосочетание как «позднее связывание» вам о чем-то говорит?

Відповісти

Підтримати

iddqd

Ще 7 коментарів

iddqd 09.01.2013 00:58

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

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

Відповісти

Підтримати

Вася Петечкин 09.01.2013 15:55

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

Відповісти

Підтримати

anonymous 09.01.2013 16:35

1. А, что собственно страшного в этом позднем связывании?

vptr. Переход на виртуальную таблицу и вызов конкретного метода очень часто заканчиваются кэш-миссами. На РС, где out of order, это не так страшно. Но, к примеру, консоли текущего поколения, являются in order и там такие вещи куда сильнее сказываются

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

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

Відповісти

Підтримати

Вася Петечкин

Вася Петечкин 09.01.2013 23:01

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

Да вы правы, с «часто» не поспоришь. Ведь кто его знает что-такое, к примеру 6%, это всего-лишь 6% или целых 6% :)

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

В множестве можно, а в множестве нельзя, опять-же разговор ниочем.

Відповісти

Підтримати

Dmytro Riabov 09.01.2013 20:45

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

Відповісти

Підтримати

Вася Петечкин

Вася Петечкин 09.01.2013 23:12

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

ну вы это фанатикам процедурного подхода расскажите

Зачем?

Відповісти

Підтримати

Dmytro Riabov 09.01.2013 23:13

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

Відповісти

Підтримати

Вася Петечкин

proger 09.01.2013 00:49

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

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

Відповісти

Підтримати

iddqd

Ще 17 коментарів

reality_hacker 09.01.2013 01:09

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

Відповісти

Підтримати

proger 09.01.2013 01:11

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

Відповісти

Підтримати

iddqd 09.01.2013 01:13

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

Відповісти

Підтримати

proger 09.01.2013 01:19

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

Відповісти

Підтримати

iddqd

iddqd 09.01.2013 10:52

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

Відповісти

Підтримати

reality_hacker 09.01.2013 01:14

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

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

Відповісти

Підтримати

proger 09.01.2013 01:21

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

Відповісти

Підтримати

reality_hacker 09.01.2013 01:26

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

Відповісти

Підтримати

iddqd 09.01.2013 01:11

У тебя как с английским? 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 годами с существования индустрии и говорить обратное — неприкрытый дебилизм.

Відповісти

Підтримати

proger 09.01.2013 01:18

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

Відповісти

Підтримати

iddqd

Dmytro Riabov 09.01.2013 01:22

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

Відповісти

Підтримати

iddqd 09.01.2013 11:13

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

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

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

* «я не очень хорошо понимаю что такое 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.

Відповісти

Підтримати

Grez 09.01.2013 12:16

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

После ООП еще рекомендуется поизучать ФП, для тех же целей.

Відповісти

Підтримати

iddqd

iddqd 09.01.2013 12:20

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

Відповісти

Підтримати

Grez

reality_hacker 09.01.2013 01:28

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

Відповісти

Підтримати

proger 09.01.2013 01:37

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

Відповісти

Підтримати

reality_hacker 09.01.2013 01:41

претензии ? я ?

О, старые добрые игры в непонимашку.

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

Т.е. ты упорно игноришь действительность что на С++ можно написать практически идентичный код как и на Си?

Відповісти

Підтримати

anonymous 09.01.2013 16:27

Откуда у C могут взяться превосходства в скорости?

restrict, к примеру.
Правда для этого есть контраргумент — хоть он и не в стандарте С++, но все нормальные С++ компиляторы имеют свои компайлер специфик рестрикт дерективы.

Відповісти

Підтримати

iddqd

anonymous 08.01.2013 21:42

-

Eugene Koval developer в Yola 08.01.2013 21:21

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

Відповісти

Підтримати

anonymous 08.01.2013 22:09

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 09.01.2013 10:59

Коментар порушує правила спільноти і видалений модераторами.

Bogdan Shyiak SE or Dev 08.01.2013 22:24

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

На ДОУ появилась своя личная совесть (минимум второй коммент указывающий всем как жить) :)

Відповісти

Підтримати

Sandro Zakusilov 08.01.2013 23:19

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

Відповісти

Підтримати

Васисуалий Лоханкин 09.01.2013 11:25

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

Відповісти

Підтримати

Denis Muratov 08.01.2013 20:44

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

Відповісти

Підтримати

Ivan Pomidorov 08.01.2013 19:51

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

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 08.01.2013 20:40

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

Відповісти

Підтримати

Ще 4 коментарі

Bogdan Shyiak SE or Dev 08.01.2013 22:26

А какая разница?

Відповісти

Підтримати

Нестор Иванович 09.01.2013 03:17

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

Відповісти

Підтримати

Ivan Pomidorov 09.01.2013 11:44

Так я вообще бэтмен.

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 09.01.2013 12:05

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 08.01.2013 17:23

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

Відповісти

Підтримати

Роман Цюпа Lead Dev в EPAM 08.01.2013 18:17

о парадигме

Відповісти

Підтримати

trimm

Ще 3 коментарі

trimm Developer/Independent contributor в IDAP 08.01.2013 18:23

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

Відповісти

Підтримати

Роман Цюпа

Роман Цюпа Lead Dev в EPAM 08.01.2013 22:34

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

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 09.01.2013 10:59

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

Відповісти

Підтримати

Роман Цюпа

Dmytro Riabov 08.01.2013 20:46

И на С можно писат в ООП — стиле

а как же наследование, полиморфизм и инкапсуляция?

Відповісти

Підтримати

trimm

Ще 6 коментарів

Mikhail Boiko SE в NVIDIA 08.01.2013 20:51

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

Відповісти

Підтримати

Dmytro Riabov 08.01.2013 20:58

жесть :)

Відповісти

Підтримати

anonymous 09.01.2013 21:56

Нет, сынок, это Классика.

Відповісти

Підтримати

proger 08.01.2013 21:15

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

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

Відповісти

Підтримати

Dmytro Riabov 08.01.2013 21:23

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 09.01.2013 11:02

Реализуемо.

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

Відповісти

Підтримати

Роман Цюпа Lead Dev в EPAM 08.01.2013 14:21

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

Відповісти

Підтримати

Igor Chornous 08.01.2013 15:21

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

Відповісти

Підтримати

Роман Цюпа

Ще 4 коментарі

Роман Цюпа Lead Dev в EPAM 08.01.2013 15:43

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 08.01.2013 22:29

ну почему, там пишет что система не идеальная, а это один с его аргументов.

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

Відповісти

Підтримати

Роман Цюпа

Dmytro Riabov 08.01.2013 20:45

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

Відповісти

Підтримати

Igor Chornous 08.01.2013 21:42

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

Відповісти

Підтримати

Mikhail Boiko SE в NVIDIA 08.01.2013 17:47

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

Відповісти

Підтримати

Роман Цюпа

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 08.01.2013 18:31

Ужассс !!! Посмотрел эту пдф-ку , это капец , как человек пишет на С++ -
class Object { //--------------- char *n_name; Object *m_parent; };

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

Відповісти

Підтримати

Роман Цюпа

Ще 12 коментарів

Igor Chornous 08.01.2013 19:53

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

Відповісти

Підтримати

Anton Mykhailov SSE 08.01.2013 20:16

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

Відповісти

Підтримати

Igor Chornous 08.01.2013 22:40

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

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

Відповісти

Підтримати

Anton Mykhailov

Anton Mykhailov SSE 08.01.2013 23:55

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

Відповісти

Підтримати

Igor Chornous 09.01.2013 00:53

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

И поэтому stl и прочее является плохим аргументом с вашей стороны.

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

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

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

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

Відповісти

Підтримати

Anton Mykhailov

Bogdan Shyiak SE or Dev 09.01.2013 01:01

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

Краткая версия: Библиотека меняется не так быстро как клиентский код.

Відповісти

Підтримати

Anton Mykhailov SSE 09.01.2013 08:52

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

Відповісти

Підтримати

Denis Muratov 08.01.2013 20:57

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

Відповісти

Підтримати

Igor Chornous 08.01.2013 22:36

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

Відповісти

Підтримати

Anton P Software Engineer в Roku 09.01.2013 14:23

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

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

Відповісти

Підтримати

ScorpZ Lapshov C++/C# && other programmer в AMC Bridge 09.01.2013 15:11

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

Відповісти

Підтримати

Anton P Software Engineer в Roku 09.01.2013 15:49

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

Відповісти

Підтримати

Макс Матюхин программист в Badoo 08.01.2013 13:20

о том как будущее за Джавой и дотнетом

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

Відповісти

Підтримати

undefined pointer 09.01.2013 19:37

будущее за JVM и .NET

потому что там — автоматическая сборка мусора :)

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

Відповісти

Підтримати

Макс Матюхин

anonymous 08.01.2013 13:18

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

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

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

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

Відповісти

Підтримати

anonymous 08.01.2013 13:22

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

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

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

Відповісти

Підтримати

Ще 2 коментарі

anonymous 08.01.2013 13:33

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

Відповісти

Підтримати

Eugene Koval developer в Yola 08.01.2013 13:52

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 08.01.2013 14:35

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

Ну это же 100% ООП.

Відповісти

Підтримати

reality_hacker 08.01.2013 20:00

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

Відповісти

Підтримати

Ще 6 коментарів

anonymous 09.01.2013 10:16

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

Відповісти

Підтримати

reality_hacker 09.01.2013 10:28

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

Відповісти

Підтримати

anonymous 09.01.2013 10:46

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

Відповісти

Підтримати

reality_hacker 09.01.2013 10:48

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 09.01.2013 11:08

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

Відповісти

Підтримати

Viacheslav 09.01.2013 22:01

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

Відповісти

Підтримати

trimm

Anton Kopylov Developer, whatever required 08.01.2013 20:58

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

IDE слабая. Это все легко решается средой для других языков (кроме темплейтов, нет их там). Если честно, то для меня студия для С++ сейчас выглядит как мамонт, совершенно не приспособленный к работе.

Никто в книгах не пишет, что абстракция это опасно, потому имеем деревья наследования глубиной в 10-20, кучи фабрик и прочей абстрактной хрени.

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

Відповісти

Підтримати

Кодерок Формошлепов 08.01.2013 22:23

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

Відповісти

Підтримати

Ще 32 коментарі

anonymous 09.01.2013 10:20

Вон винда и другие продукты МСа нормально поживают с миллионами строк кода.

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

Відповісти

Підтримати

Кодерок Формошлепов

Anton Kopylov Developer, whatever required 11.01.2013 09:18

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

Відповісти

Підтримати

anonymous 11.01.2013 10:16

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 11.01.2013 10:33

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

Вас обманули.

С ниразу не подходит под них.

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

Відповісти

Підтримати

reality_hacker 11.01.2013 10:37

Вас обманули.

Меня значит тоже. Просвети пожалуйста, а то википедия тоже вроде пишет в том же направении: en.wikipedia.org/...es_and_concepts

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 11.01.2013 11:08

Просвети пожалуйста, а то википедия тоже вроде пишет в том же направении: en.wikipedia.org/...es_and_concepts

Так там многое написано, вы читайте внимательнее (можете еще по ссылочкам походить)

Відповісти

Підтримати

reality_hacker 11.01.2013 11:09

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

Відповісти

Підтримати

Anton Kopylov Developer, whatever required 12.01.2013 12:06

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

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

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 12.01.2013 12:10

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

Відповісти

Підтримати

trimm Developer/Independent contributor в IDAP 14.01.2013 13:57

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

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

Відповісти

Підтримати

anonymous 09.01.2013 18:40

Я работал в успешном проекте на C# с 6 млн строк (~300Mb *.cs файлов, без ресурсов и прочего).

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

Я по прежнему думаю что проблема не в OOP, а в том как применяют...

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

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

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

Відповісти

Підтримати

Кодерок Формошлепов

undefined pointer 09.01.2013 18:53

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

Вам сделать
быстро
качественно
дешево

выберите любые 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ов радеоновоских. Разучились программировать? И после такой дисквалификации — ООП критиковать?

Відповісти

Підтримати

anonymous 09.01.2013 20:41

вы напишите за 2-3 месяца магазинчик продажи пиццерии. Не за «пару десятков лет», а за 2-3 месяца, причем когда каждые 2 недели в процессе написания заказчика будут посещать новые идеи.

И? Выбор парадигмы (а именно это мы обсуждаем) здесь никак не повлияет. Мои слова были о том, что в будущем выбор ООП аукнется.

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

Насрать в стек можно на любом языке. Я говорил не об этом

То есть вы как истый программист записали в хрень — бОльшую часть реальности?

Видимо, у нас разные реальности.

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

Вы впутываете в разговор другие вещи. Мы же обсуждали ООП, а не С\С++\whatever. Выстрелить себе в ногу можно на любом языке. В одном это сделать проще, в другом тяжелее. Без сомнения С и С++ относятся к тем языкам с которыми отстрелить ногу невероятно просто

Ничего личного, просто интересно, в ООП дело?

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

2. и чего такие крутые «Сишники» от портирования на С Wii U отказались?

Не стоит переводить мое личное мнение в разряд официальной позиции компании.

Так давайте поговорим об «игроделах»

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

ООП критиковать?

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 09.01.2013 21:17

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

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

Видимо, у нас разные реальности.

О, начинаете смекать, что не «геймдевом единым»?
Я то в курсе, боролся и за фпсы, нарезал на ассемблере по битовым плоскостям чтобы в память GPU напрямую писать.
Так что давайте обсудим — реальности ;)

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

Аха, но когда «SAP» опережает всех — ну это говнокод! Ну конечно! ;)

Вы впутываете в разговор другие вещи. Мы же обсуждали ООП, а не С\С++\whatever.

С точностью до наоборот — это я говорю об ООП, а вот вы, и многие как раз дальше C vs С++ не продвинулись. Узость задач видать, и спец опыт «вылизывания 200 строк Си в NASA годами». Верю. Отработав в такой специфике лет 5+ - ничего другого о программировании, какое оно желтое, соленое, и гладкое бывает — знать не знаешь. Все оно либо круглое либо квадратное ;)

Не стоит переводить мое личное мнение в разряд официальной позиции компании.

Я и не переводил :) Просто так, немножко пытался потроллить, ради — «а подумать»? Ну немножко — подумать, ну хоть о том же форумном движке доу.

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

О да! Вот тут — стопицот процентов — с 90ых годов — геймер только апдейтом железа и занимается, раз в год, два. Да, оптимизаторы-игроделы — ну что вы говорите. Первейшие!
У меня никак из первых EEE 901 умирать не хочет, на гиге запускается и Офис, и Eclipse, и хромы с файрфоксами последними.
Но из игрушек... Казаки, 2001го выпуска. Атом знаете ли ;)

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

Вы писали магазинчик пиццы и вам ООП не понравилось?
Или все же — расширите сознание? ;)

Переход на личности не делает вам чести.

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

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

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

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

Відповісти

Підтримати

anonymous 09.01.2013 21:45

Сколько уже написали магазинчиков, чтобы просто — прочувствовать специфику этой разработки? Ну чтобы — думать о кеше процессора при этом? ;)

Я не пишу магазинчики. Любой большой софт, а не магазинчики, как раз нуждается в оптимизациях и размышлениях о кеше, стратегиях выделения памяти и т.д. Возьмем приведенный вами ниже Офис. Вот вам пример — 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 фпс, но для того, что бы получить такой же ФПС ему нужен на порядок мощнее РС.

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 07:47

Я не пишу магазинчики. Любой большой софт, а не магазинчики,

То есть не зная и «магазинчиков» вы беретесь рассуждать о большом софте для магазиниЩ и их сетей?

как раз нуждается в оптимизациях и размышлениях о кеше,

??? большой софт — о кеше думать??
я тут недавно общался... вобщем SAP у Дерипаски в Норильске обслуживает только складских рабочих мест около 29 тыс . Какой еще кеш процессора?

Может, это вам стоит «подумать»?

да, это я не умею, я уже понял, вы видели, слышали о большом софте, а мне да, такой неведом.
Удачи!

Відповісти

Підтримати

Sandro Zakusilov 09.01.2013 20:13

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

С таким успехом другой человек может сказать, что он ненавидит разделения кода на .h и .c/.cpp, потому что это затрудняет навигацию, заставляет бегать туда обратно, заставляет при изменении интерфейса — лезть и править в двух местах.
Но что собственно в данном случае требуется? Взглянуть на интерфейс класса не прокручивая весь код? Для этого давно существует решение и инструментарий. Вообще проблемы навигации решаются за счет IDE. Хотя точно также и решаются проблемы редактирования интерфейса сразу в двух файлах, и перемещение между ними.
Но вопрос, какую реально решает задачу, такое разделение? Мне кажется разделение на .h и .cpp файлы — не для удобной навигации по коду, существует.

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

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

Но как можно писать эффективный код без знания железа?!

А как можно писать эффективный код без знания computer science? Есть задачи которые гораздо эффективней решают за счет «высокоуровневой херни», за счет алгоритмов, за счет математики, чем за счет оптимизации на уровне железа. При этом экономится время на разработку, при этом за счет высокоуровневых абстракций понижается сложность (для человека). Абстракции это то что позволяет от одного транзистора прыгнуть к современным CPU и GPU. Так что не нужно тут этого снобизма.

Відповісти

Підтримати

anonymous 09.01.2013 20:48

С таким успехом другой человек может сказать, что он ненавидит разделения кода на .h и .c/.cpp, потому что это затрудняет навигацию, заставляет бегать туда обратно, заставляет при изменении интерфейса — лезть и править в двух местах.

Это дело вкуса, не больше. В С++ точно так же можно почти весь код написать в хедере.

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

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

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

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

Відповісти

Підтримати

Sandro Zakusilov

Grez 09.01.2013 21:05

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

А вот тут — поясните-обоснуйте.

Відповісти

Підтримати

undefined pointer 09.01.2013 21:35

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

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

И в критических местах надо знать железо.

Молодым программистам в ынтырпрайзе я давно говорю — вся твоя оптимизация этого цикла — впустую потраченное время, потому что вот у тебя лишний запрос вне нода — съест 99,9 % перфоманса. Его — придумай как убрать.

к абстракциям сможет быть эффективным во всех случаях.

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

Відповісти

Підтримати

Sandro Zakusilov 09.01.2013 22:03

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

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

Відповісти

Підтримати

Blitz Senior .net Developer / Architect 09.01.2013 20:45

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

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

Відповісти

Підтримати

anonymous 09.01.2013 20:50

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

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 09.01.2013 20:52

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

Відповісти

Підтримати

Sandro Zakusilov 09.01.2013 22:13

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

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 09.01.2013 23:40

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

Відповісти

Підтримати

Sandro Zakusilov

Dmytro Riabov 09.01.2013 21:22

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

Відповісти

Підтримати

anonymous 09.01.2013 21:32

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

Відповісти

Підтримати

Dmytro Riabov 09.01.2013 21:38

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

Відповісти

Підтримати

Viacheslav 09.01.2013 22:04

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

Відповісти

Підтримати

Sandro Zakusilov 09.01.2013 22:30

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

Відповісти

Підтримати

Blitz Senior .net Developer / Architect 09.01.2013 23:42

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

Відповісти

Підтримати

undefined pointer 08.01.2013 12:14

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

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

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

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

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

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

скорее в контексте ядра линукса и системных библиотек.

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

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

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

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

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

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

Відповісти

Підтримати

Oleg Tyshchenko 08.01.2013 19:34

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

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

Відповісти

Підтримати

undefined pointer

Ще 2 коментарі

undefined pointer 09.01.2013 08:53

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

Вообще-то — да.

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

Например можно смотреть на реку — меняет ли река свое состояние?

Для моделирования на ЯП — недостаточно данных — давать ли «реке» состояние или нет.
Мне даже — с «смотреть» не все понятно. Кто смотрит, откуда смотрит, на карту местности смотрит с «синими линиями»?

Тут с какой стороны посмотреть, вода протекла — значит поменяла, а по существу нет,

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

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

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

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

Не конкурирует также как и с ФП. ООП — это другой уровень абстракции.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 13:32

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

Відповісти

Підтримати

undefined pointer

iddqd 09.01.2013 00:21

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

Відповісти

Підтримати

undefined pointer

Ще 1 коментар

undefined pointer 09.01.2013 09:39

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

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

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

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

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

Відповісти

Підтримати

iddqd

Iaroslav Voitovych ¡sí, señor! 09.01.2013 03:47

ООП говорит о проектировании, и отображении в коде сущностей появившихся на этапе — проектирования. Но не надо спешить и кодировать эти сущности в ООП.

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

Відповісти

Підтримати

undefined pointer

Ще 1 коментар

undefined pointer 09.01.2013 08:56

Если хоть один человек понял чёрную сторону ООП после этого обсуждения — это уже хорошо.

Да при чем тут черная сторона??

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

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

Відповісти

Підтримати

Iaroslav Voitovych

Андрей Никишаев 09.01.2013 20:15

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

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

Відповісти

Підтримати

undefined pointer

Ще 9 коментарів

Grez 09.01.2013 20:29

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

Відповісти

Підтримати

Андрей Никишаев

Mikhail Boiko SE в NVIDIA 09.01.2013 20:36

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

Відповісти

Підтримати

Grez

Grez 09.01.2013 21:02

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

Відповісти

Підтримати

Андрей Никишаев 09.01.2013 21:22

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

Відповісти

Підтримати

Grez

Grez 09.01.2013 21:58

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

Відповісти

Підтримати

Андрей Никишаев

Андрей Никишаев 09.01.2013 22:09

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

Відповісти

Підтримати

Grez

Grez 09.01.2013 22:44

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

не знаю как вам это удается. Я кочергой убил уже 3 гадалки и два экстрасенса.

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

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

Відповісти

Підтримати

Андрей Никишаев

Андрей Никишаев 09.01.2013 23:07

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

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

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

Відповісти

Підтримати

Grez

reality_hacker 09.01.2013 22:58

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

Какие такие фабрики фабрик в век dependency injection.

Відповісти

Підтримати

Grez

Усачев Олег 08.01.2013 12:04

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

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

Відповісти

Підтримати

Васисуалий Лоханкин 08.01.2013 11:46

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

Відповісти

Підтримати

proger 08.01.2013 21:20

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

Відповісти

Підтримати

Васисуалий Лоханкин

Ще 2 коментарі

Васисуалий Лоханкин 10.01.2013 10:06

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

Відповісти

Підтримати

proger 10.01.2013 11:30

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

ну єто ваше понимание, вам с ним жить :)

Відповісти

Підтримати

Васисуалий Лоханкин

Васисуалий Лоханкин 08.01.2013 11:36

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

Відповісти

Підтримати

NewType 08.01.2013 11:23

4) ООП слишком далеко от реального представления информации

Absolute bullshit.

Update:
Хотя, смотря что понимать под «реальным».

Відповісти

Підтримати

Valentyn Myroshnichenko Delivery Manager в Infopulse, Part of Tietoevry Create 08.01.2013 11:18

blogerator.ru/...cts-have-failed

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 08.01.2013 05:21

UPD: Вот старое обсуждение сабжа: dou.ua/...-senora/#183442

Відповісти

Підтримати

NewType 08.01.2013 11:27

Почему объектно-ориентированное программирование провалилось?

Прошло ровно 10 лет с публикации известной и классической в мире программирования статьи, написанной Ричардом Гэбриелом, название которой стало уже нарицательным и вынесено в заголовок моей заметки.

А мужики-то и не знали.
Всё пишут и пишут на Java, на C# да на C++ и прочих ОО языках.
Шо ж они окаянные всё не проваливаюцца никак?...
:-)

Відповісти

Підтримати

Iaroslav Voitovych

Ще 6 коментарів

Iaroslav Voitovych ¡sí, señor! 09.01.2013 02:58

Всё пишут и пишут на Java, на C# да на C++ и прочих ОО языках.

Писать на ОО языках, и ООП — две большие разницы.
— Можно технично использовать области видимости, структурировать код с помощью классов, отделять интерфейс от имплементации.
— А можно нагородить вышибающую мозг структуру наследования из ненужных сущностей, а за одно пихать обджект фектори всюду куда надо и не надо. ;)

Відповісти

Підтримати

undefined pointer 09.01.2013 09:10

А можно нагородить вышибающую мозг структуру наследования из ненужных сущностей

я не только на Си, а и на ассемблере писал.
Вы Ярослав хотите сказать что там нельзя нагородить???
Хотя бы указателя на указатель, который смещением полученным по другому указателю получаем указатель на адрес, по которому будет вызываться call или function?
Или что такой код — читается легко и непринужденно?

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 10.01.2013 05:42

я не только на Си, а и на ассемблере писал.

Не вы один. :)

Хотя бы указателя на указатель, который смещением полученным по другому указателю получаем указатель на адрес, по которому будет вызываться call или function?

Ой как страшно! :)
А вот как насчёт:
— темплейт шестерной вложенности подибагать за индусами?
— разобраться в восьмиуровневой лозанье из врапперов?
— объяснить паттернописцам, что для управлления водонагревателем по показаниям термопары ОБДЖЕКТ ФЕКТОРИ НЕ НУЖНЫ!!
;)

Відповісти

Підтримати

undefined pointer

undefined pointer 10.01.2013 07:51

Ой как страшно!

Ярослав — геймдевочные и эмбэд штучки и подходы — останутся там же. они в нескольких других областях — неприменимы — за ненадобностью.

А вот как насчёт:

не подбирайте
не разбирайтесь
не объясняйте.

другого выбора у вас нет ООП — нерушимо. никакие доды ему в ближайшее десятилетие не угрожает. Так что вам решать — либо асилить его, либо программировать в область где ему не место, где оно лишнее.

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 11.01.2013 03:43

ООП — нерушимо

Как сказал мне один пафосный персонаж, «Закон Гука — ЭТО ДОГМА!»... Так почему же тогда рвутся струны на гитаре, подумал я ;)

никакие доды ему в ближайшее десятилетие не угрожает.

Ленин — всегда живой! LOL
Но таки да, ООП/ООД включает в себя слишком много конструктивных-позитивных-продуктивных практик, чтобы его можно было пошатнуть.
В частности — энкапсуляция, SOC — от них никуда не денешься.

Так что вам решать — либо асилить его

Пока Вы тут мне рассказываете про «асилить», у меня уже пару лет как висят 2 штатовских патента на софтвер архитектуру (в линкдине моём ссылки есть кстати), и дивайсов продано как минимум несколько сотен... 8-Р

Відповісти

Підтримати

undefined pointer

NewType 09.01.2013 11:21

Да. И виноват в этом не язык, а программист.

Відповісти

Підтримати

Iaroslav Voitovych

Кодерок Формошлепов 08.01.2013 02:12

Я так понимаю автор ожидал что мы поможем отстоять процедурное программирование — другими словами гoвнокод на ООП языках. Настоящий ООП кодерок должен понимать почему метод на 100 строк это плохо, и что такое coupling и cohesion.

А по поводу ФП: один друг подсказал тему — реализуйте на ФП класс Date или DateTime =) Интересно на это посмотреть...

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 08.01.2013 04:40

Настоящий ООП кодерок должен понимать почему метод на 100 строк это плохо

Нука-нука, и почему же? ;)

и что такое coupling и cohesion

Некоторые даже энкапсуляцию не понимают... :(

Відповісти

Підтримати

Кодерок Формошлепов

anonymous 08.01.2013 09:48

-

Відповісти

Підтримати

Кодерок Формошлепов

Bogdan Shyiak SE or Dev 08.01.2013 11:37

А по поводу ФП: один друг подсказал тему — реализуйте на ФП класс 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");

При наличии макросов, все выглядит куда приятнее (смотрим КЛОС)

Відповісти

Підтримати

Кодерок Формошлепов

Ще 11 коментарів

anonymous 08.01.2013 12:13

-

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 08.01.2013 12:24

А зачем именно нужен класс даты?

Модуль объединяющий функционал по работе с датами.

Відповісти

Підтримати

anonymous 08.01.2013 12:44

-

Відповісти

Підтримати

undefined pointer 08.01.2013 12:53

а с ООП всегда так — привести простой пример его пользы, преимуществ похоже вообще невозможно :)
На маленьких примерах — оно явно избыточное, как в старом анекдоте кто как решал задачу — вывести «Hello world!»

А вот на примере:
Есть пиццерия, которой нужно ПО для — управления запасами ингредиентов, ассортимента, учета затрат на выпечку, клиентами с их скидками, и отчетами в налоговую..., и, ..., ... и чтобы по интернету заказать можно было, и ... ,..
уже можно. Только описание даже абстрактной пиццерийки — займет не один абзац.

А вот когда закодить это все на plain C, а потом добавлять функционал — ну тут и посмотрим, как «архитектура рушится как карточный домик при малейшем изменении требований заказчика»

или на ФП — когда там архитектура — write only — ибо — чистые функции и прочие прелести, и ничего общего сущности в коде с сущностями задачи не имеют.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 08.01.2013 12:55

Ну так модуль же а не класс.

Ну так а я «класс» и не создавал. Я так понял, человек хотел именно функционал модуля, ведь если оно ему не надо, то «класс» Дата реализуется и в ФП и в процедурном очевидным способом.

Відповісти

Підтримати

anonymous 08.01.2013 14:45

-

Відповісти

Підтримати

Grez 08.01.2013 14:58

Видимо имеллось ввиду не написать клас даты в фп языке (так как ООП термин «клас» непременим к ФП), а реализовать функционал близкий к оному.

Відповісти

Підтримати

Кодерок Формошлепов 08.01.2013 22:34

Ну если это реализовать на ФП, то будет просто пачка функций, или одна функция со свитчем. А учитывая что все функции будут работать с timestamp... то cohesion очевиден, разве нет? ;) ООП — это о данных и поведении, а в случае с датами функции — это поведение, а timestamp — данные.

Відповісти

Підтримати

Grez

Valeriy Zamaraiev (junior lisper) 15.01.2013 23:43

CLOS имеет только то отношение к ФП, что Common Lisp иногда не совсем корректно называют функциональным ЯП. CLOS — это как раз самое ООПистое ООП, с продвинутым рефлекшеном в виде метапротокола, и веселым generic dispatch (который кстати можно настраивать и даже заменять).

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 16.01.2013 06:52

CLOS — это как раз самое ООПистое ООП

Какбэ не спорю.

CLOS имеет только то отношение к ФП

Стоп, когда я последний раз на него смотрел, то реализовано оно было на макросах/функциях (смотрел довольно поверхностно, так что могу ошибаться).

Common Lisp иногда не совсем корректно называют функциональным ЯП.

Аргументы? Ибо все кто такое утверждал, обычно сводили разговор к «расовой чистоте хаскелла».

Відповісти

Підтримати

Valeriy Zamaraiev

Valeriy Zamaraiev (junior lisper) 16.01.2013 10:38

В CL только аллокация регистров и GC сделан не на функциях/макросах, а на асме или C. Все остальное на нем же самом, причем CLOS оттуда уже никак не выкусить, он даже на экране ничего не сможет напечатать без CLOS. А насчет ФП — вопрос терминологии, если CL — это ФП, то там же и javascript и питон, не смотря на некоторую кривизну замыканий. Но как-то последние два не принято называть функциональными.

Відповісти

Підтримати

anonymous 08.01.2013 00:11

-

Відповісти

Підтримати

Blitz Senior .net Developer / Architect 07.01.2013 23:56

ООП vs Процедурное программирование? Не пройдёт, вас сольют.
Вот ООП vs ФП — совсем другое дело!

Кстати

4) ООП слишком далеко от реального представления информации

ООП как раз очень хорошо подходит для моделирования объектов реального мира.

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 08.01.2013 01:39

Противовес ООП есть только один — DOD.

Відповісти

Підтримати

Blitz

Ще 24 коментарі

reality_hacker 08.01.2013 01:43

Нет, еще есть KFC

Відповісти

Підтримати

Iaroslav Voitovych

двадцатитрёхлетний сениор 08.01.2013 01:46

Kentucky Fried Chicken?

Відповісти

Підтримати

reality_hacker 08.01.2013 01:47

Фууу, тебе должно быть стыдно. Хотя тебе не привыкать.

Відповісти

Підтримати

двадцатитрёхлетний сениор

Anton Hoffman отшельникъ в горахъ голливудскихъ 08.01.2013 18:19

Универсальный противовес ООП? Везде-везде, во всех его традиционных областях применения?

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 09.01.2013 02:50

Попытаюсь объяснить просто и популярно.
ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.
Уверовавшие же в эту (###) олухи начинают мостить ООП куда надо и, в основном, куда не надо. Эта практика очень хорошо известна как Cargo Cult Programming, и является его частным случаем.
ООП, при правильном применении, не так уж плох.
НО!!!
Для того, чтобы понимать граници применимости ООП нужно
— на практике увидеть эпик фейлы проектов на неразумном применении ООП
— понимать, что в ООП хорошо, а что — плохо.
Если Вас действительно интересует вопрос, прочтите что про ООП сказал Линус Торвальдс, google: «C++ bullshit»

Відповісти

Підтримати

Eugene Koval developer в Yola 09.01.2013 06:59

Смєшалісь в кучу коні, люді...

«C++ bullshit»

С++ == ООП ?
Крім того, Лінус з радістю множить на 0, наприклад, всі системи контролю версій крім створеної власне їм :) Вірити йому ?

ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.

По-перше, всі визнають, що є класи задач, для яких ООП не дуже підходить. По-друге, чим краща Ваша універсалізація ДОД ?

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 10.01.2013 05:27

О, нарешті адекватний коментар від опонента! :)

С++ == ООП ?

Звичайно ні, але Лінус критикує не стільки плюси скільки ООП в цьому опусі.

Крім того, Лінус з радістю множить на 0, наприклад, всі системи контролю версій крім створеної власне їм :)

Так, дуже влучне спостереження! :)

є класи задач, для яких ООП не дуже підходить

Звучть дуже слабенько. ООД є неякісним підходом, тому він призводить до фейлів. ДОД — це альтернатива ООД, але і те і інше — спосіб аналізу і синтезу систем.
Відкрию Вам секрет: Поєднання обох методів, аналіз системи з обох точок зору — дає найкращий результат. :)
І навпаки. Ігноруючи потоки даних, любителі ООП-ООД плодять непотрібні сутності, і натрапляють на граблі, от навіть вчора був епічний приклад.

Відповісти

Підтримати

Eugene Koval developer в Yola 10.01.2013 07:17

О ! Так прийняти (але не погодитись) Вашу думку я згоден. Але не цю:

Yaroslav Voytovych
Possible TL/Architect в [undisclosed] позавчера #
***
Противовес ООП есть только один — DOD.
***

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 11.01.2013 04:37

Так прийняти (але не погодитись) Вашу думку я згоден. Але не цю:
Противовес ООП есть только один — DOD.

Спробую пояснити ще раз.
ООП в своєму прагненні до суцільної об’єктно-орієнтованості — відриває нещасного ООПера від реальності і уводить до країни мрій і фейлу.
І лише ДОДівський погляд на речі може повернути нещасного до реальності, ООП-ООД йому ну ніяк не допоможе.

Відповісти

Підтримати

undefined pointer 10.01.2013 09:54

ДОД — це альтернатива ООД

алфавит не может быть альтернативой юриспруденции

ассемблер не может быть альтернативой SQL

Ярослав, вы потеряли иерархичность абстракций :)
ДОД — это вышивание крестиком, или еще какая ручная работа.
А ООП — это промышленный выпуск километров ткани.

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 11.01.2013 04:18

ДОД — это вышивание крестиком, или еще какая ручная работа.
А ООП — это промышленный выпуск километров ткани.

ЭТО ЧУШЬ.
Вы повторяете это уже не раз, и не Вы один. Даже смешно слушать.
Оба подхода могуть быть применены и применяются в архитектурном деле, причём о одной и той же целью — построить архитектуру, желательно успешную — это важно. ;)
Их можно успешно применять по отдельности, и тогда выигрывает ДОД.
Можно же понимать их оба, и тогда выигрывает понимающий. :)
НО.
Как показывает практика, зафейлившиеся ООПеры обвиняют в своих бедах кого угодно, но только не ООП, и не свою глупость. :)

Відповісти

Підтримати

undefined pointer

Anton Hoffman отшельникъ в горахъ голливудскихъ 09.01.2013 12:26

ООП (как и многое другое в этой жизни) подаётся его апологетами/проповедниками/евангелистами/фанатами как некий универсальный рецепт счастья.

Я с тем же успехом могу заменить в этой цитате «ООП» на ваш любимый DOD или KFC, который тут называли или любую другую трехбуквенную аббревиатуру.

Если Вас действительно интересует вопрос, простите что про ООП сказал Линус Торвальдс, google: «C++ bullshit»

Ссылка на авторитет? Good, good..

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 10.01.2013 05:35

Я с тем же успехом могу заменить в этой цитате «ООП» на ваш любимый DOD

Я «продаю» здесь ДОД — как альтернативу ООД, но не как рецепт всеобщего счастья.
Успешная архитектура — єто не ДОД и не ООД, это, в основном, не падайте — ЗДРАВЫЙ СМЫСЛ, и опыт конечно.

Ссылка на авторитет? Good, good..

Ну если моя логика не воспринимается мозгами оппонентов, приходится авторитетами припугнуть, чтоб не галдели.

Відповісти

Підтримати

undefined pointer 10.01.2013 09:44

Ну если моя логика не воспринимается мозгами оппонентов,

Ярослав, дело не в Вашей логике, а в отсутствии того самого здравого смысла :)
Я почитал то что вы предложили о ДОД. Это вообще никаким боком не альтернатива ООД. Это просто низкоуровневая хрень для написания драйверов или перегонки между данных между ОЗУ и памятью GPU.

То есть, отсутствие здравого смысла — это когда НЕ объявляется круг задач для которых нечто лучше, чем другое. Без этого получается — догма.
ООП — не серебрянная пуля, и не будет ею. Особенно в случаях когда предметная область — сам компьютер, его работа. Незачем творить класс — CPU, у которого поле, объекта класса Cache, и есть объект класса Memory, и у всех методы для записи байтика туды сюды. Это будет просто — масло маслянное. Машинные команды и так отражают эти сущности и связи между ними, чтобы на них, еще нечто надстраивать.

Я «продаю» здесь ДОД — как альтернативу ООД

Кому именно, разработчикам драйверов? Они еще не научились писать драйвера в «потоках данных»?

Огласите — целевую аудиторию :)

Відповісти

Підтримати

Iaroslav Voitovych

Anton Hoffman отшельникъ в горахъ голливудскихъ 10.01.2013 13:00

Ну, не обязательно драйверов, в интерпрайзе тоже есть место для DOD.. Но достаточно узкое и я подозреваю, что намастрячить несапортабельный кодец или устроить metadata hell там будет никак не труднее последовательного применения OOD.

Відповісти

Підтримати

undefined pointer

Blitz Senior .net Developer / Architect 09.01.2013 00:52

Data Oriented Design? Это оптимизационный паттерн, если я не ошибаюсь. ООП — явление гораздо более глобальное.

Відповісти

Підтримати

Iaroslav Voitovych

Dmytro Riabov 09.01.2013 01:03

driven, а не oriented. не понимаю, как можно не видеть разницу.
ну и если первое д — это дата, а не домэйн — то это скорее отсутствие дизайна, чем дизайн

Відповісти

Підтримати

Blitz

Iaroslav Voitovych ¡sí, señor! 09.01.2013 03:04

Data Oriented Design? Это оптимизационный паттерн, если я не ошибаюсь.

С точки зрения законченного ООПиста — да, именно так.
С точки зрения же здравого смысла, DOD — наиболее осмысленный подход:
— Деление целого на части
— Выяснение взаимосвязей (потоков данных) между частями
Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно. А вот мантра «Everything Is An Object!» — у меня всегда вызывала подозрения, даже в те дни, когда я просто жаждал принять ООП всем сердцем, и думал что это только по началу кажется слегка идиотичным, а потом пройдёт и раскроется во всей своей райской красоте... ;)

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 09.01.2013 11:04

С точки зрения законченного ООПиста — да, именно так.

Я поклоник гибридных ООП-ФП языков. А вот вы, судя по каментам в топике — фанатик.

Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно.

А мне интуитивно понятен ООП, ну и что?

А вот мантра «Everything Is An Object!» — у меня всегда вызывала подозрения, даже в те дни, когда я просто жаждал принять ООП всем сердцем, и думал что это только по началу кажется слегка идиотичным, а потом пройдёт и раскроется во всей своей райской красоте... ;)

А вы работали с языками, где эта мантра таки реализованна? Потому что в вашем профиле таковых нет. Для ясности — С++ - не каноничная реализация ООП, о чём Кёртис заявил прямым текстом.

Відповісти

Підтримати

Iaroslav Voitovych

Iaroslav Voitovych ¡sí, señor! 10.01.2013 06:12

А вот вы, судя по каментам в топике — фанатик.

Я много раз мог бы дать классификацию Вам, но сдерживался. Но теперь дам.
Вы, батенька — хам.

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 10.01.2013 09:29

Ну до вас мне...

Вернёмся к теме разговора. Вы хоть раз работали с тру ООП языком? С Смалтолком или Обжект Си, что бы было понятнее.

Відповісти

Підтримати

Iaroslav Voitovych

trimm Developer/Independent contributor в IDAP 10.01.2013 11:59

Руби, как вариант, да?

Відповісти

Підтримати

Blitz

Blitz Senior .net Developer / Architect 10.01.2013 13:06

Я с ним особо не знаком, не знаю.

Відповісти

Підтримати

trimm

undefined pointer 10.01.2013 09:51

Мне, как электронщику с более чем 15-летним стажем DOD понятен интуитивно.

а что там непонятного И для неэлектронщика?

Вот только вам как электронщику нифига непонятно как писать «магазинчики» с «оперденями» :D

когда я просто жаждал принять ООП всем сердцем,

а зачем оно электронщику? Оно ему напрочь не нужно — у него есть все нужные абстракции для программирования. байты, адреса, порты.
ООП электронщику как корове седло :)

Відповісти

Підтримати

Iaroslav Voitovych

Павел Борисов Писатель в Неизвестности™ 07.01.2013 23:03

Спор аналогичен наличию/нет бардака в личной/публичной библиотеке, он бесполезен.

Відповісти

Підтримати

boo 07.01.2013 22:59

Гуглиться легко. Тема старый баян. Хотя в последние годы идут немалые подвижки в сторону фп и она опять набирает актуальность.
en.wikipedia.org/...mming#Criticism , можешь закопипастить другу в скайп.

Відповісти

Підтримати

Роман Цюпа Lead Dev в EPAM 07.01.2013 23:12

спасибки

Відповісти

Підтримати

boo

Dmitriy Seryy engineer в Samsung R&D Institute Ukraine 07.01.2013 22:42

Если в систему нужно легко добавлять новые типы, не меняя интерфейс — то нужно юзать ООП. А если нужно добавлять новые функции, для работы с фиксированным набором объектов, то нужен процедурный подход.

Відповісти

Підтримати

anonymous 07.01.2013 21:51

Реально существует только один аргумент — низкий IQ. Все остальные аргументы это следствие этого.

Відповісти

Підтримати

Iaroslav Voitovych ¡sí, señor! 08.01.2013 01:37

Ну и какую практическую ценность имеет этот аргумент? ;)

Відповісти

Підтримати

Ще 1 коментар

anonymous 08.01.2013 02:17

Он как бы возвращает спорщиков к более простому варианту «Что лучше ВАЗ или КАМАЗ?»

Відповісти

Підтримати

Iaroslav Voitovych

Bogdan Shyiak SE or Dev 07.01.2013 21:35

А теперь мини трейнинг :):

1) На чистом С код быстрее

Доказательство всеобщности необходимо тут.

2) На самом деле код С++ нифига не портируется так просто (ну это отдельно про с++)

Новость ЦПП — такое же унылое гуано как и Ц. А вот как с «портированостью» программ на джава?

3) Библиотеки например Boost непроизводителны, так как дают слишком много удобной абстракции

Для всех Удобно(х) следует Непроизводительно(х)
Так что ли? Так это не правда. Нэ залык!

4) ООП слишком далеко от реального представления информации и

А мужики-то и не знают.

Відповісти

Підтримати

Роман Цюпа Lead Dev в EPAM 07.01.2013 22:21

thread.gmane.org/...643/focus=57918

Відповісти

Підтримати

Ще 5 коментарів

Mikhail Boiko SE в NVIDIA 07.01.2013 22:38

там срач Си против Си++, а не ООП против неООП

Відповісти

Підтримати

Роман Цюпа

Bogdan Shyiak SE or Dev 07.01.2013 22:45

И че?

Відповісти

Підтримати

Роман Цюпа

reality_hacker 07.01.2013 22:48

Как че, согласно Толоконникову, Линус Торвальдс — ниасилятор.

Відповісти

Підтримати

Grez 09.01.2013 12:19

Так он вроде сам и писал, что так и есть.

Відповісти

Підтримати

reality_hacker 09.01.2013 12:20

Кто он, Торвальдс или Толоконников?

Відповісти

Підтримати

Grez

trimm Developer/Independent contributor в IDAP 08.01.2013 17:36

>А вот как с «портированостью» программ на джава?

Write once, debug everywhere?

>Новость ЦПП — такое же унылое гуано как и Ц.

Но до явы с шарпом по унынию ему еще плестись и плестись.

Відповісти

Підтримати

Ще 32 коментарі

Роман Цюпа Lead Dev в EPAM 08.01.2013 18:17

С интереса, а что вам нравится =)?

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 08.01.2013 18:22

C, Objective-C, Ruby, Smalltalk.

Відповісти

Підтримати

Роман Цюпа

Oleg Tyshchenko 08.01.2013 19:38

До уныния Objective-C любому языку ползти, нет ничего унылее чем эта надстройка над компилятором С.

Відповісти

Підтримати

trimm

Непростой Чувак 09.01.2013 10:45

там очень даже не скучно, если вы про это.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 13:35

После 1000 квадратной скобки я был готов застрелится. Благо уже не приходится с ним работать.

Відповісти

Підтримати

Непростой Чувак

trimm Developer/Independent contributor в IDAP 09.01.2013 13:45

Т.е. круглые скобки вас не парят в других языках? Или мусье — говонокодер и «стиль кода» — это не о нем?

Відповісти

Підтримати

Oleg Tyshchenko

trimm Developer/Independent contributor в IDAP 09.01.2013 11:38

Какой язык мусье предпочитает? Вы скажите, чтобы я вас предметно обосрал.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 13:34

Бинарный код.

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 09.01.2013 13:44

Ну не надо же обманывать. Вы же фомошлеп, вас же издалека видно.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 14:03

что такое фомошлеп?

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 09.01.2013 15:46

Это вы. Очевидно же.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 16:33

кто я?

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 09.01.2013 16:48

dou.ua/...=comment#278631

>> Вы же фомошлеп, вас же издалека видно.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 17:23

я так и не понял, что значит фомошлеп, извините. :( Потому и переспросил, кто я?

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 09.01.2013 17:29

Не переживайте, рано или поздно прийдет понимание того, кто вы. Тогда и обжектив уже не будет казацца унылым из-за гoвнокода и квадратных скобочек.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 09.01.2013 17:49

А ну да, я забыл, что objective-c программисты 90 процентов времени проводят в xcode cocoa designer, тогда видимо вы правы, я был формошлепом. :( Убежал в стыде.

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 10.01.2013 11:02

Objective-C проггеры пишут код, блеать. Ну а вы, будучи указанной выше сущностью ( dou.ua/...=comment#278631 ) , таки сидели в каком-то там кокоа дизайнере, а остальное время гoвнокодили, что и приводило к сотням квадратных скобочек в одну строку.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 10.01.2013 13:34

До взлета iOS формошлепства никто в здравом уме не использовал objective-C для нормальных проектов, популярность настала после того, как всем захотелось фигачить очередные формочки для iOS. Замечу с появлением кучи альтернатив Objective-C для разработки приложений на iOS, популярность по статистике Objective-C снова упала.

Ruby тоже самое, до взлета RoR формошлепства, никто в здравом уме не использовал этот язык.

Если я захочу поупражнятся в наборе текста я установлю Соло на клавиатуре.

Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.

Так что да, вам лучше знать, что такое формошлеп и кто им является. ;)

Відповісти

Підтримати

trimm

Blitz Senior .net Developer / Architect 10.01.2013 14:01

Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.

Ошибаетесь. Смалтолк был придуман для формошлёпства.

Відповісти

Підтримати

Oleg Tyshchenko

trimm Developer/Independent contributor в IDAP 14.01.2013 14:07

>До взлета iOS формошлепства никто в здравом уме не использовал objective-C для нормальных проектов, популярность настала после того, как всем захотелось фигачить очередные формочки для iOS.

Естессно, его нигде не использовали, т.к. стандартная библиотека есть только на маке, а он не самая распространенная система. Да и намного сложнее, чем формошлепские шарп и ява, ибо нормальные проекты в понимании вас и вашей братии предполагают легкую заменяемость персонала и весьма примтивную работу.

>Замечу с появлением кучи альтернатив Objective-C для разработки приложений на iOS, популярность по статистике Objective-C снова упала.

Не удивительно. Только объясняецца это тем, что появилась возможность разработки на других платформах, т.е. не маках, т.к. далеко не у всех есть доступ к макам, а многие просто не в состоянии освоить обжектив в те сроки, аз которые им надо выполнить свои задачи. Да и опять же, набежало формошлепов, пишущих тормозное и бажное гoвно на js, рзабавили статистику.

>Если я захочу поупражнятся в наборе текста я установлю Соло на клавиатуре.

Вы это к чему сказали? Неужто у вас настолько несвязное мышление, что вы не можете формулировать свои мысли без отрыва от контекста? Тогда неудивительно, что вы обжектив не потянули.

>Для smalltalk не придумали задач по формошлепству, потому он как был мертвым так им и остается.

Браво! Вы сейчас пытаетесь доказать, что большинство задач формошлепские и стоит их выполнение мало денег, т.к. есть обезьяны почти бесплатные? Я в курсе, вы меня не удивили, что вашей братии больше, чем тех, кто делает что-то сложное и интересное, ибо соотношение 4:1 всегда верно.

>Так что да, вам лучше знать, что такое формошлеп и кто им является. ;)

Да что там знать? Вы. Очевидно же.

Відповісти

Підтримати

Oleg Tyshchenko

Oleg Tyshchenko 14.01.2013 14:43

Удивительно, разработка не на Objective-C все еще требует Mac. Многие просто не хотят тратить свое время на унылый язык.

И да, большинство задач таки формошлепсткие, потому у тебя сейчас есть работа. Но ты не беспокойся время RoR и iOS когда-то пройдет, так что уже можешь привыкать к метле, подметать парадное.

Відповісти

Підтримати

trimm

trimm Developer/Independent contributor в IDAP 15.01.2013 11:29

>Удивительно, разработка не на Objective-C все еще требует Mac. Многие просто не хотят тратить свое время на унылый я�