JavaScript vs адекватность

В свете очередного фейла.

0

Сообщение от CoderHuligan Потому что классы на внутреннем уровне построены с их помощью, а иначе никак. Методы класса реализуются указателями на функции.

И какое отношение детали реализации имеют к качеству самой парадигмы, о котором вас спрашивают?

0

Сообщение от Катафалк И какое отношение детали реализации имеют к качеству самой парадигмы, о котором вас спрашивают?

Самое прямое. Нельзя ускорить то, что по природе неускоримо. Но это даже второстепенно(насчет скорости).. Насчет же самой парадигмы, то произошла подмена понятий. Об этом еще Алан Кэй говорил ("ООП для меня это сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP. ") . Наследование отсутствует в этом списке, но есть в традиционном понимании.
А лично я думаю, что вся эта "система из реального мира" приносит индустрии гораздо больше вреда, чем пользы..
Например возьмем концепцию общения объектов путем посылки сообщений. казалось бы элегантная идея, однако она является довольно опасной штукой, когда сообщение может и не дойти до адресата, и тогда допустим взорвется атомный блок фукусимы. Думаю все были свидетелями, как работает очередь сообщений в виндовс: очень часто сообщения просто теряются, не доходят до адресата. То есть что мы делаем: мы вводим дополнительный интерфейс между двумя объектами, интерфейс общения. А наследование? Это вообще джунгли. Программы с goto винили за спагетти -код, а во что мы превратили оопный код? в гораздо большее спагетти.
Я просто уверен, что придет время и люди вернуться к простым, быстрым и проверенным решениям.

0

Сообщение от CoderHuligan Я просто уверен, что придет время и люди вернуться к простым, быстрым и проверенным решениям.

Как там поживает морской бой на ваших простых и проверенных решениях?

0

Сообщение от Катафалк Как там поживает морской бой на ваших простых и проверенных решениях?

Начал все с 0 писать.

0

Сообщение от CoderHuligan Начал все с 0 писать.

Неужто в своей гото-нелапше через год не смогли разобраться?

0

Сообщение от Катафалк Неужто в своей гото-нелапше через год не смогли разобраться?

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

0

Сообщение от Катафалк Неужто в своей гото-нелапше через год не смогли разобраться?

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

Сообщение от XLAT это диктует сама парадигма недоопа: написанный проект никогда нельзя улучшить новыми фичами, акромя как полностью его переписать!

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

0

Сообщение от CoderHuligan Змея, так сказать закусила свой хвост (масонский кстати символ)

Ага, расскажи нам про масонов в Древнем Египте, например.

Сообщение от CoderHuligan а дальше история умалчивает про то, чем руководствовались отцы основатели

Если б ты читал не говнометодички по турбо-Паскалю, а нормальные книги, вроде SICP, то знал бы, что такое data-directed programming и какие проблемы оно решает.

0

Сообщение от CoderHuligan В том-то и дело что понимаю.

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

Сообщение от CoderHuligan Но javascript учить надо, так как это мэйнстрим, никуда от этого не деться.

Какой это мейнстрим? Веб - крупная часть индустрии, но сильно не единственная.

Сообщение от Катафалк Весело наверно жить в вашей вымышленной вселенной, где все с вами несогласные "баранки крутят".

Несогласные деляться на тех, кто в теме, и на диванных крикунов. Угадаете, кто вы?

0

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

Без ООП никак нельзя моделировать предметную область?

И ООП, само по себе, не даёт перегрузки процессора.

0

Сообщение от Curry Без ООП никак нельзя моделировать предметную область?

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

Сообщение от Curry И ООП, само по себе, не даёт перегрузки процессора.

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

0

Сообщение от Usaga Можно, но сложнее, чем без него.

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

Сообщение от Usaga ООП само по себе не бывает)

Бывает, когда рассматривается вне стандартных и распространённых ООП-библиотек. Или когда его не смешивают ещё с чем ни будь.

Сообщение от Usaga Бывают средства, его представляющие. Они дают оверхед.

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

0

Сообщение от Curry К моделированию чего либо это не имеет прямого отношения.

Не соглашусь. Это инструмент, который немного упрощает это самое моделирование.

Сообщение от Curry Бывает, когда рассматривается вне стандартных и распространённых ООП-библиотек. Или когда его не смешивают ещё с чем ни будь.

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

Сообщение от Curry Какой? Доступ к таблице виртуальных функций? В одних случаях виртуальных функций может не быть и всё заинлайнено. В других (в тех, когда в ООП необходимы виртуальные функции) и не ООП-шные варианты используют вызов функций через указатели.

Не только таблица виртуальных функций. Но и сам процесс аллокации памяти под объект.

0

Сообщение от Usaga Не соглашусь.

Субъективно.

Сообщение от Usaga Не только таблица виртуальных функций. Но и сам процесс аллокации памяти под объект.

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

0

Сообщение от korvin_ Если б ты читал не говнометодички по турбо-Паскалю, а нормальные книги, вроде SICP

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

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

Главная проблема все же не в моделировании, а в сложности как реализации, так и понимания..
Современных программистов приучают отнюдь не все держать под собственным контролем.. ОС предоставляет API, которые не прозрачны. Языки также стали предоставлять собственные API. Речь вовсе не о библиотеках.. Тут дело в коммерции, закрытом/открытом коде, корпоративных законах, наконец в конкуренции. Инструменты усложняют, чтобы отсеивать конкурентов.. Но усложняя инструменты программисты постепенно становятся неспособными их полностью понять, а это приводит к ошибкам и пр.
Простой инструмент, навроде того же языка Си позволял практически представить что происходит на уровне машины. Сейчас же начинают прямо с Pithon..
Только супер-профи может осознать что происходит с его кодом на уровне машины используя тот же С++. Для этого ему необходимо энное количество времени провести за отладчиками. Но сейчас все спешат, только неизвестно куда, в каком направлении.. Во всяком случае в направлении от простого к сложному.. А этот процесс, как известно кончается хаосом.
Инструмент должен оставаться простым, чтобы его можно было держать под контролем.. Но, кто об этом сейчас думает..

0

Сообщение от Usaga Несогласные деляться на тех, кто в теме, и на диванных крикунов. Угадаете, кто вы?

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

Добавлено через 2 минуты

Сообщение от CoderHuligan А этот процесс, как известно кончается хаосом.

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

0

Сообщение от Usaga Это инструмент, который немного упрощает это самое моделирование.

Моделирование чего?

Далеко не каждая предметная область нуждается в ООП или моелируется им лучше какого-нибудь другого подхода. Например, в том же SICP (видео лекциях) в теме про ФП (streams aka ленивые списки) говорилось, что оно хорошо соотносится с обработкой сигналов. SQL — ни разу не ООП, а всякие ORM путаются натянуть сову на глобус, в результате получая недо-ООП недо-SQL. Для работы с графами и базами знаний, логическое программирование (Prolog) подходит больше, чем ООП. Для обработки больших данных, опять же, ФП сейчас более популярно (в виде того же Apache Spark).

Конечно это «ITшные» предметные области, но тем не менее. Думаю, в моделировании каких-нибудь физических систем, ООП если и присутствует, то лишь частично, и в очень упрощённом виде.

0

Проблема объектных языков в большой связности сущностей программных компонентов. Двигаться, я думаю, нужно в сторону декомпозиции по компонентному принципу. Каждый компонент (слово, процедура, функция) является независимым от других компонентов. Он не является участником какого-то класса связных сущностей. Мы знаем что на входе, что на выходе - это единственное что нужно знать. Мы не должны дополнительно держать в памяти к какому классу принадлежит сущность (возможно, что модулей это тоже касается..). Компонент самостоятельная сущность: ему плевать на всех остальных, он "вещь в себе", черный ящик. И другим компонентам нет нужды знать внутреннее устройство других, достаточно знать только интерфейс: что на входе и выходе. Усё.. Заигрались вы друзья, заигрались..
А класс это не компонент, а винегрет.
Если компонент можно изьять из системы, то должна нарушиться только часть её функциональности, но не грохнуться вся система, друзья..
И при добавлении компонента, должна увеличиться функциональность системы, желательно без зависимости от наличия других компонентов. Если мы меняем компонент на новый, то оставляем только старый интерфейс, тогда он зависит от окружения. Поэтому система должна делиться не на модули, не на классы, а на компоненты по функциональности. И все необходимое для создания таких систем в языках уже есть.

0

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

0

[quote="Curry;14581776"]Вне ООП тоже выделяется память под данные, например, под структуры. А ООП-ышный объект это данные+функции (от того что их назвать методами ничего не измениться). И память выделяется в любом случае под данные, в таком же кол-ве.
Разница может быть в том, что в ООП принято (в хорошем смысле, при активном использовании DDD) налегать на объекты сильнее, чем просто на структуры. Там, где можно было обойтись какими-то статическими\глобальными функциями с кучкой параметров, можно выделить какую-то концепцию в виде класса, который для использования надо инстанциировать. Может показаться избыточным так делать, но часто оверхед от этого не такой уж значимый, а улучшение структуры кода ценнее.

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

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

Сообщение от korvin_ Моделирование чего?

Большинства предметных областей конечно же. Я согласен, что не каждой это надо вообще или не надо в полной мере.

0