LINUX.ORG.RU

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


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

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

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от quickquest

> В 1983 году разработчики космического корабля Буран обратились в Институт [прикладной математики] с просьбой помочь в разработке бортового программного обеспечения и программного обеспечения наземных испытаний корабля. По их оценкам для этой работы требовалось несколько тысяч программистов.

Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

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

Создание DSL - означает решение задачи «снизу-вверх».

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

Прослойка обеспечила проблемно-ориентированный интерфейс к оборудованию.

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

Они сделали инструмент (a`la driver), своеобразное приспособление для решения поставленной задачи.

anonymous ()
Ответ на: комментарий от anonymous

>Как правило, у них есть теоретические обоснования и наработки по технологической базе.

А вот это уже зависит. От многих факторов.

Понятие формализация задачи было ключевым.


Кстати, UML как раз для этого придумали. Уж лучше такой формализм, чем никакого. Опять же. Буч — хреновый пиарщик, его вообще к написанию книг по UML нельзя было допускать. И установка «мы говорим UML, подразумеваем RUP» совсем не способствует.

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

Macil ★★★★★ ()
Ответ на: комментарий от tailgunner

>А еще он не существует, настоящий.

Я как-то раз видел. ;)

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

или прикинь - диагнозы всех болезней. Я что - медицинский должен был ещё заканчивать? Да и после него буду сырым новичком, так как надо ещё в госпиталях десятилетия отпахать. А задача, например - сделать регрессионный анализ и предиктить что-то. Или статистику посчитать. Я даже не знаю что от чего зависит, т.е. не могу даже ламерские решения принять: могу ли использовать линейную регрессию итд. Это всё спецы должны делать, а не я кодер. А я отвечаю за технологии и чтобы работало не 2 дня, а 2 часа.

anonymous ()
Ответ на: комментарий от anonymous

> Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

сверху-вниз конечно же. Опять двадцать пять. Я не против планирования. Планирование всего-лишь не должно включать планирование классов!

anonymous ()
Ответ на: комментарий от Macil

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

Ильич тоже наверное хотел как лучше.

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

anonymous ()
Ответ на: комментарий от anonymous

>бывает старая документация

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

Возвращаясь в онтопик, скажу что система типов ЯП в какой-то мере пытается это сделать. Изоморфизм Карри-Ховарда еще никто не отменял.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

> Кстати, UML как раз для этого придумали.

Я знаю UML и даже всеми (7ю?) диаграммами пользуюсь, рисуя на доске для важности, когда надо. Я зол на то, как его используют и для чего. И кто.

Помянем IDL, корбу (тоже поработал когда-то). Теперь ждём когда наконец загнутся ejb, jms, xml и далее бесконечный список который пишут сегодня в резюме.

anonymous ()
Ответ на: комментарий от anonymous

>> Как полагаешь, это подход «сверху-вниз» или «снизу-вверх»?

сверху-вниз конечно же.

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

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

Опять двадцать пять. Я не против планирования. Планирование всего-лишь не должно включать планирование классов!

Ну, планирование, по определению, как процесс, подразумевает подход «сверху-вниз». :)

anonymous ()
Ответ на: комментарий от anonymous

>я воюю исключительно с пионерами

У пионерии есть одно замечательное свойство: проходит со временем. Все мы ломаем массу дров. Я вот до сих пор ломаю, пытась по-пионерски закидать шапками сложную проблему, не видя полной несостоятельности своих действий ;)

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

Страшно не то что кто-то наломал дров. Страшно что кто-то не понял, что наломал дров. Или как это обычно бывает, не захотел понять или признать или исправить.

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

> Кстати, UML как раз для этого придумали.

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

Macil ★★★★★ ()
Ответ на: комментарий от Macil

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

я проработал все 2000е на контрактах (кроме последних 3х лет). Много где был, включая в штатах. По моему опыту - таких было подавляющее большинство. Серьёзные люди только островками.

что творится сейчас - даже боюсь себе представить

anonymous ()
Ответ на: комментарий от Macil

Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

не дождётесь (C) :) (легаси же, да и реляционная алгебра как она есть с точности до переименования операторов)

anonymous ()
Ответ на: комментарий от Macil

> У пионерии есть одно замечательное свойство: проходит со временем.

Есть остаточный эффект. Вдруг говорят: «да, плохо. Но стандард же уже!» А ты: «как? когда? когда успели?» И надо разгребать...

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от Macil

забыл послать коммент на это

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

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

думаю, у этого направления большое будущее.

anonymous ()

Всё, пошёл Вейля читать (этот топик подтолкнул, кстати). Пока не прочитаю - постить не буду.

anonymous ()
Ответ на: комментарий от Macil

> Лично я жду, когда загнется SQL и будет использоваться Datalog ;))

Может надо ждать более активно?

А то я у тебя спрашивал хорошую книжку по даталогу, желательно в эл. виде, а ты (вроде) и не ответил ;-)

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Ага, щас только галоши надену...

А то я у тебя спрашивал хорошую книжку по даталогу


У меня? Я что-то запамятовал. Хорошей книжки по даталогу я не знаю. Скажем так, нечто описано в Д. Ульман, Д. Уидом «Основы реляционных баз данных» aka First Course in Database Systems. Но достаточно походя. Зато есть ссылки на другие труды.

Есть различные исследовательские проекты. Язык OverLog, даталог-подобный язык для описания оверлейных (P2P) сетей. Что-то вроде есть в Racket (PLT Scheme). Есть библиотечка на Clojure.

Macil ★★★★★ ()
Ответ на: комментарий от Meerkat

> Поддерживаю. Особенно второе - за все время парадигма ООП реализована всего парой языков (трудоемкий это процесс, хотя бы среду общения объектов сколько надо прописывать, чтобы они могли обмениваться сообщениями). Очень интересно! Продолжай! Что это за языки? Дай я предположу. С++ по-боку. Его модель — это «грязная» модель ООП, которую Страуструп изобрёл пытаясь скрестить низкоуровневый ассемблер C и высокоуровневые концепции ООП. (дада, мне тоже смешно, он бы ещё ООП макросы для fasm написал бы.) Java тоже идёт лесом: жалкая попытка «вычистить» C++. Python тоже отсеяли, потому что в нём нет слова private. Предположу, что самым ООП языком будет Lisp: его CLOS, с классами, метаклассами, generic функциями, да и ещё всё это помноженное на мощнейший макроязык даёт не только минимум заявленный ООП (полиморфизм, наследование, инкапсуляция), но более того гибкость при выборе средств, которую никто кроме лиспа предложить не в состоянии. Так что с одним из языков мы определились. Но кто второй? Может ruby? Или в ruby тоже нет слова private? Давно на нём не писал ничего, не помню.

anonymous ()

«Когда C++ твой молоток, все остальное начинает выглядеть как большой палец»

Karapuz ★★★★★ ()
Ответ на: комментарий от Macil

> А что за книга?

Герман Вейль «Математическое мышление». Конкретно интересна аргументация Вейля против аксиоматизма и какой конструктивизм он сам-то предлагает.

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

Ещё не дочитал (ещё минимум пару вечеров) но пока не в восторге.

Интересны обоснованные аргументы того же Степанова против Бурбакизма. Где в полу-популярной форме можно экстерном ознакомится с аргументацией математиков (не чистых философов!) в пользу неаксиоматического построения того же анализа? Может кто-то подскажет?

Вот мне, в частности, не понятно: если алгоритмы и всякие топологические преобразования, или статистика - находятся на противоположной стороне фронта к аксиоматизму-Бурбакизму - то разве написание алгоритмов и подбор клеточных автоматов - это не формализм в чистой воде? (именно то что меня напрягало выше! т.е. получаем ещё менее обоснованный формализм и становишься ещё на более крупный конвейер завода быдлокдинга). Или каким может быть не-Кошивское определение непрерывности и нужна ли та непрерывность вообще? не более ли консистентно её определить в рамках точности данной машины и соседнего пиксела? Не правильнее ли разложения Тейлоров-Маклоренов давать в конечной точности, и не до бесконечности? Ведь в компьютерах вообще нет действительных чисел, только целые, в точности до умножения на константу, пусть это будет даже большая константа. Бесконечный генератор не катит потому что он никогда не завершается. Если завершится - это уже какой-то (вернее реальный!) квантованный мир. Итд.

anonymous ()
Ответ на: комментарий от anonymous

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

Где в полу-популярной форме можно экстерном ознакомится с аргументацией математиков (не чистых философов!) в пользу неаксиоматического построения того же анализа? Может кто-то подскажет?

Весь Арнольд (дифуры, топология), лекции Босса (матан 1-4 курса), лирические отступления у Акимова (введение в группы).

Там не столько аргументация против аксиоматиков, сколько конкретные примеры эффективности конструктивизма.

mclaudt ()
Ответ на: комментарий от anonymous

кстати, у Вейля встречаются 2 определения категории (типа), которые я привёл выше: б)набор аттрибутов (всегда под аттрибут можно запрятать и скрипт, поведение, поэтому здесь опущено) и в)область определения + область значений. (http://www.linux.org.ru/forum/development/5377010/page12#comment-5386483) А определение а (как грамматика) очевидно: будь то хоть в виде человеческого, неформального языка (т.е. спецификация заказчика, если она непротиворечива), а лучше - в виде формального. Т.е. после прочтения полкниги - могу уже подтвердить ссылокой на Вейля - равнозначность и полноту каждого из 3х приведённых мной определения типа/категории. (Под куском памяти можно подразумевать физические ограничения на размер данных, локальность данных и можно опустить либо считать энвиронментом, аксиомой).

P.S. А кто-то тут меня упрекал в приведении определения типа максимум для 1го курса. Может и 1го курса современного преподавания быдлоООПязыков, но таки не первого курса математиков уровня Вейля, Гильберта.

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

anonymous ()
Ответ на: комментарий от mclaudt

о, спасибо. (Арнольда я имею 3 книги и читал, но не всё осилил. Буду пробиваться дальше. Босса и Акимова буду искать)

anonymous ()
Ответ на: комментарий от mclaudt

Кстати, вот книга, в которой практически весь современных компутер сайенс в сжатой форме (без конкретных алгоритмов, численных методов). Один из труднейших курсов для CS студентов (обычно на MSc), потому что всё надо доказывать, после каждого параграфа: Davis, Sigal, Weyuker «Computability, Complexity, and Languages, Second Edition: Fundamentals of Theoretical Computer Science (Computer Science and Scientific Computing)»

Пример конструктивизма (в постоении математики) в чистом виде.

anonymous ()
Ответ на: комментарий от anonymous

Надо почитать будет.

Вообще-то типы определяют через изоморфизм Карри-Говарда. Типа математики ленивые :) Лень им чего-то разрабатывать. Придумали изоморфизм и ладушки.

набор аттрибутов


Ээээ. Набор аттрибутов чего? Какого-то объекта (в широком смысле этого слова)?

Я не знаю мейнстрим языков, где это именно так. Конечно, может быть есть какие-то исследовательские языки.


А пойнтеры, пойнтеры на пойнтеры итд, как я сказал - к типу не имеют отношения.


Имеют. Пойнтер — это тип, параметризованный типом того объекта на который он указывает. В языках типа ML они имеют место быть, причем в разных инкарнациях. Кстати, доставляют попытки разработчиков на C++ сделать класс Pointer со всякими плюшками.

Macil ★★★★★ ()
Ответ на: комментарий от anonymous

>Видишь ли, нам как нематематикам впаривали

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

Математика — игрушка. К ней нельзя относиться серьезно. Увы, никто мне это не объяснил, а я дурак, пытался найти некие «математические» правила, сродни тех которые имеются в языке или литературе. В математике ты сам их создаешь. Ты в них не упираешься лбом, не используещь их как ориентир.

Как результат, стал с ней знакомиться совсем недавно. Какой @$%#! сказал, что математика — точная наука? Математика ­— свой собственный мир, не имеющий никакого отношения к реальности. И если какие-то математические положения применяют в реальности, то это не проблемы математиков.

аргументация Вейля против аксиоматизма


Если честно, то пока мне аксеоматизма хватает за глаза.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

> У меня как у нематематика есть жуткое желание дать в морду всем своим учителям-математикам и преподавателям-математикам в независимости от пола и возраста.

Математика ­— свой собственный мир, не имеющий никакого отношения к реальности.

ROTFL

tailgunner ★★★★★ ()
Ответ на: комментарий от Macil

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

Я не знаю мейнстрим языков, где это именно так. Конечно, может быть есть какие-то исследовательские языки.

В компьютерах - аттрибуты широко используются в ИИ. Начиная с фреймов Минского - знания в эксперных системах, базах знаний итд стали хранить в иерархических структурах с абстрактыми пропертями-аттрибутами (frame languages). Слоты несут стринги, а как эти стринги будут интерпретированы - уже задача функции, поведения. Т.е. слоты не типированы. Тип можно считать «зашитым» в будущем интерпретирующем коде (так как в ИИ смысл не ясен и скорее будет выводиться позже). В семантическом вэбе, дата-майнинге - всё тоже стринги.

anonymous ()
Ответ на: комментарий от tailgunner

>> У меня как у нематематика есть жуткое желание дать в морду всем своим учителям-математикам и преподавателям-математикам в независимости от пола и возраста.

Математика ­— свой собственный мир, не имеющий никакого отношения к реальности.

ROTFL

Чего смеешься? Плакать надо.

Как-то так:

ROTFC

pathfinder ★★★ ()
Ответ на: комментарий от Macil

> Имеют. Пойнтер — это тип, параметризованный типом того объекта на который он указывает. В языках типа ML они имеют место быть, причем в разных инкарнациях. Кстати, доставляют попытки разработчиков на C++ сделать класс Pointer со всякими плюшками.

пойнтер - это не тип. Это тип внутри языка си или другого какого-то.

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

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

anonymous ()
Ответ на: комментарий от anonymous

s/Число, выражающее зарплату служащего/размер памяти и её структура для хранения числа, выражающего зарплату/

anonymous ()
Ответ на: комментарий от anonymous

> Т.е. после прочтения полкниги - могу уже подтвердить ссылокой на Вейля - равнозначность и полноту каждого из 3х приведённых мной определения типа/категории.

В алгебре постоянно доказывают изоморфизм одной фигни, определенной предикативно, другой фигне, определенной конструктивно. (начиная от школьной фигни {x | a*x*x+b*x+c=0}, а в универе — допустим, жорданова нормальная форма матриц)

Но все это не делает то определение (кстати, его вроде высказал тейлганнер?) хорошим.

Попробуй, например, опиши множество операций над обычным четыерхбайтовым int. А я посмеюсь.

З.Ы. Чтобы несколько уравнять ситуацию, предложу свое опеределение типа: тип — это подмножество множества предикатов от: результатов операций над типом и строк, именующих сам тип и эти операции. В случае включения Т1 в Т2 (включения как множества) Т2 часто (всегда?) считается тем же типом, что Т1.

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

>> Математика — свой собственный мир, не имеющий никакого отношения к реальности.

ROTFL

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

заодно, кстати, можешь потрудиться охарктеризовать множестов операций типа int

и если мы через dlopen подгружаем новую функцию int f(int) — допустим даже без побочных эффектов — становится ли тип int другим?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

пойнтер - это не тип. Это тип внутри языка си или другого какого-то.

или внутри явы

вообще, количество внешних ссылок на объект равное 1 или большее 1 объективно проверяется:

void f(A a)
{ 
  A a_saved=a.clone();
  g(.... выражение, куда не входит а и не входит a_saved ....)
  if( a.notEqual(a_saved) )
    // значит ссылок на а было больше 1
  else
    // ну тут сказать ниче не можем
}
www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

>>> Математика — свой собственный мир, не имеющий никакого отношения к реальности.

ROTFL

зря смеялся; такая точка зрения вполне имеет право жить

Я не по уровню смеялся, а по фронту %) Точка зрения имеет право на жизнь, безусловно. Но, если не прогуливать лекции, то нужно знать термин «верификация модели» - проверка на то, как абстракции соответствуют реальному миру.

tailgunner ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> если мы через dlopen подгружаем новую функцию int f(int) — допустим даже без побочных эффектов — становится ли тип int другим?

У int есть набор атомарных операций (можно спорить, каким именно он должен быть, но он есть); не думаю, что какая-то f сможет расширить этот набор :)

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

> У int есть набор атомарных операций (можно спорить, каким именно он должен быть, но он есть); не думаю, что какая-то f сможет расширить этот набор :)

Значит в определение типа таки надо добавить слово «атомарных»?

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

Хм. Наверное, те, которые не выразимы через другие атомарные операции. Или, может быть, не выразимы эффективно.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

> Но, если не прогуливать лекции, то нужно знать термин «верификация модели» - проверка на то, как абстракции соответствуют реальному миру.

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

Ну так отправляем старое определение на свалку (которое оно давно заслужило) и берем новое со словом «атомарные» или нет?

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.