Здравствуйте, Ikemefula, Вы писали:

I>Ты использовал для аргумента локальные функции == без пяти минут лямбды, это и есть функциональщина.
I>Указатель на функцию — снова поддержка ФП.

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

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


V>>Просто ты отрицаешь само наличие декомпозиции задачи в рамках процедурного подхода (или не понимаешь её, ХЗ). В процедурном подходе декомпозиция отталкивается от данных и алгоритмов их обработки.
I>Ага, а указатель на функцию это данные, да ?

Это указатель на алгоритм. Да, алгоритмы можно привязать к данным. А ты думал, ООП с луны свалилось? Оно уже вовсю использовалось в модульном программировании, только ручками.

Или тебя смущает именно указатель?
Ноу проблема, пронумеруй алгоритмы и диспатч их на switch/case. Та же фигня, вид в профиль. То бишь, появление адреса ничего не меняет в дизайне, просто дает более эффективный способ переключения алгоритмов.


>>Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн.
I>В твоей трактовке это так потому что в процедурное ты записываешь фичи из ФП.

Это с каких пор ФП оперирует адресом ф-ии??? В ФП ф-ия представлена малость сложнее, чем просто адрес. Собсно, всю механику я тебе уже показал.


V>>Боюсь, в ответ на мои обоснования тебе придется привести свои. Простое "нет" не канает.
I>Все аргументы я привел, возможно ты их не понял, это другой разговор.

Дай ссылку или процитируй те аргументы, которые еще не были опровергнуты. ))

V>>Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лямбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.
I>Нет, не имеет.

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


I>Тогда покажи аналог моего кода на языке СИ.

У тебя в коде используется обобщенное программирование, поэтому я тоже применил обобщенное программирование для аналога. Но я не использовал никакого ООП. Обобщенное программирование было применено к структурам и свободным процедурам/ф-ям. Если ваять на чистом С, то моя инфраструктура переползет на макросы. И то и то — кодогенерация, но обобщенное программирование типобезопасно, поэтому показалось мне более интересным для демонстрации.


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

Мне и не надо ничего захватывать. Захватить я могу явно.

I>1. описать структуру для захвата

Можно. А в 99% случаев хватит некоего обобщенного Tuple.

I>2. описать функцию которая будет работать с этой структурой

Дык и в ФП целевую ф-ию описывать надо.

I>3. выполнить захват, то есть создать экземпляр, инициализировать

В C/С++ это выполняется в человеческом синтаксисе:

struct { int a; int b; } context1 = { 42, 43 };
TUPLE((int, float)) context2 = { 42, 43.44 };

I>4. освободить память (хрен знает когда)

Да. Но техника GC, оп-па, тоже нейтральна к парадигмам.

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

Дык, в STL ф-ия qsort — это внешняя свободная ф-ия, а не метод объекта. И работает над любыми итераторами произвольного доступа и с любыми предикатами сравнения.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Ведь эту энергию поглотит "кто-то конкретный".
S>>Она не то что никуда не девается, она ниоткуда не берется.

V>Двойка по физике.
Эта твоя двойка для меня мало значит.

S>>Испускатель фотона не знает кто его получит.

V>Это аргумент за или против чего? я ХЗ чтоты имел ввиду, но его получит любой, вставший на пути следования фотона. И кто тебе мешает встать аналогично на "пути следования" любого события в WinForms?
Встать аналогично без идентичности не получится в случае событий WinForms.

S>>Предлагаешь поразговаривать с дверью-лампочкой по фотографии в интернете?

V>Предлагаю перестать юлить. ТЫ уже очень далеко убегаешь, но так и не сказал — зачем? Ты игноришь все прямые вопросы и откровенно юлишь. Поэтому отвечать тебе лишний раз неохота — ты мастер по замыливанию обсуждаемого.
Я не убегаю. Просто я не считаю что светящаяся дверь как-то меняет ситуацию. Даже светящаяся дверь ничего не знает о колбочках в твоем глазу. Ей на тебя все равно до лампочки.

S>>Покажи как вопрос от тебя доходит до двери

V>Я уже показывал более одного раза.
То что ты показывал — это способ дохода ответа от двери, и я не удовлетворен его близостью с ООП. А над близостью способа отправки запроса двери я еще не смеялся. Не, было конечно, что ты ставишь свой глаз в направлении двери. Но где там идентичность двери?

S>>Вот я тебе и талдычу о том что аналога в мире нет.

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

S>>Вместо того что бы натягивать реальный мир на ООП, программисты поступают ровно наоборот, только это не всем очевидно.

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

V>... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

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

S>>Типа вот если бы дверь была бы как бы компьютером, и мы могли бы ей посылать сообщение, вот было бы круто.

V>Я же говорю, у тебя пробелы в теории информации. Для тебя сообщение — это непременно набор байт. И если ты этого набора байт в жизни не видишь, то оп-па! Твоя программа не является моделью рж!!! Я такого откровеннго детсада уже 100 лет не видел. )
У меня действительно пробелы в теории информации и не надо мне об этом повторять в духе "ну я же говорил". Лучше поведай, что говорит теория информации об идентичности получателя фотона.

S>>Все, дальше выдумывать ничего не надо.

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

V>Читать Кея надо было не позже 3-го курса. А теперь всё, опоздал. Он тебе уже не поможет.
Я полагаю что это тебе поможет понять философию ООП.

S>>Только я вижу, что тебя таращит от твоей теории настолько, что ты не пытаешься понять, что тебе пишут в ответ.

V>Угу... Смотрю, ты готов юлить бесконечно... Дело твоё...
Действительно мое.

S>>>>Это ты убегал и зарывался в тонкости. Я лишь наблюдал за этим и подтролливал.

S>>А у тебя-то!

V>Дык, ты не показал еще ни одной ошибки. Одно юление и манера отвечать вопросами на вопросы.
Показывал. Проблема в том, что ты их не считаешь за ошибки или перекидываешь тему куда-нибудь в другое русло.

S>>>>Необоснован твой абзац с подпиской на фотоны.

V>Обоснуй!
V>Ы?
идентичность

S>>А не ты мне хотел показать, как близко ООП к рж,

V>Я и показал.
Обломался

S>>но потом написал что на самом деле аналога нет?

V>Не надо меня перефразировать. Я говорил сугубо о ролях в модели. Но сама модель — из жизни, увы. Ты опять попался!

V>Просто ты не видишь, где проходят границы абстракций и что такое вообще модель.

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

V>... нам в любом случае придется вводить фиктивный объект, который будет делать это ВМЕСТО двери.

V>Плюс еще сама дверь! Не понял?

V>Смотри раза внимательней: для целей моделирования происходящего, упомянутого "фиктивного объекта, который будет делать это ВМЕСТО двери" — будет более чем достаточно, это ж модель!. то бишь, сама дверь нам не нужна, ууупс! А что остается? Чем будет являться этот "фиктивный объект"? А может он и будет моделью двери, коль именно через него мы получаем о двери необходимую информацию и взаимодействуем с дверью через него?

V>Хочешь того или нет, но всё это время ты спорил о том, что модель не есть реальная жизнь. Детсад, сорри за повторение. Модель и не должна быть рж, на то она и модель. Но она, тем не менее, модель реально происходящего.
Детсад здесь в том, что ты решил подменить предмет спора. Я спорил не с этим.


S>>Давай так, твоя модель — ты и обосновывай ее близость к рж.

V>Я уже сделал это бесконечное кол-во раз и ты так и не привел контраргументов.
Ты бесконечное число раз проигнорировал контраргументы и согласился что модель далека. Так что я даже не знаю, о чем уже спор, походу ты просто остановиться не можешь.

S>>А единичный фотон — различает, ага

V>Откуда ты вообще сейчас взял "единичный" фотон? Что за флуктуации мыслительной активности? По теме есть что сказать?
Ты рассуждал о фотоне, его же не я придумал.

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

V>>>Ну дык, вектор фотонов движения — такой же точно конкретный их адрес. А на пути этого "адреса" ты можешь расположить свои рецепторы.
S>>Что за на пути адреса?

V>Именно, это проекция на первые две составляющих полярных координат в 3-хмерном пространстве.
Так что там с идентичностью рецепторов?

S>>Расскажи мне о том как у рецептора есть свой адрес и как рецептор подписывается на сообщение от вектора.

V>Я уже рассказывал — как. Если конспектом — без фокусировки никак.
Верно, только и с фокусировкой тоже никак.

S>>В ООП нет произвольного адреса, есть только конкретные.

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


V>>>Тебе начать рассказывать с фокусного расстояния или с еще более ранних азов оптики?
S>>На твое усмотрение

V>ОК, Геометрическая оптика
Причем тут идентичность, казалось бы?

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

S>>Походу ты пропустил начало темы. Речь шла о другом.

V>Ну побегай, побегай.
А ты потопчись

S>>Ты так и не привел ни одного нечистого куска без использования бэкдоров.

V>Я могу нечистую программу целиком привести, пойдет? Без каких-либо бэкдоров. Могу еще все побочные эффекты императива повторить на ассоциативном контейнере в Хаскеле, такое пойдет? Я даже могу тебе на С++ привести ф-ию, которая вся сплошь мутабельная в КАЖДОЙ строчке, но при этом будет абсолютно чиста, как слеза младенца. Приводить?
Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?

S>>А я тебе 10-ый пост объясняю что я не оспариваю твоего права раздавать роли как угодно. Я оспариваю то утверждение, что как угодно разданные роли естественным образом соответствуют рж.

V>Они "не как угодно". Опять и снова курить "информацию". И еще курить цели и задачи моделирования. У меня как раз в модели "нечто, используемое вместо реального объекта", на то она и модель. Глупо с твоей стороны оспаривать право модели быть моделью.
Опять подмена тезиса

S>>Ну ты же высосал из пальца то что возражений нет. Есть возражения. Энергичные вычисления тоже могут быть чистыми.

V>Чистыми могут быть даже вычисления в каждой мутабельной строчке на С++, это не аргумент. Речь была сугубо о последовательности вычислений. Я утверждал, что гарантии очередности вычислений важны. Именно это ты опровергнуть и не сможешь, ес-но, бо это фундаментально.
Я не пытался это опровергнуть. Хорош спорить с голосами.

S>>Разница лишь в том, что для вычислимости на энергичных вычислений нужна особая форма if-а.

V>Какая еще особая? Я тебе уже разложил её в I/K базисе и показал, что для преобразования в конечный код необходимо значение предиката при if. Это всё! неужели до тебя не дошла суть этого разложения? Это уже какой-то полный П.
Походу ты не знаешь что такое особая форма, раз ты уже спалился с тем что в хаскеле if функцией не записать.

S>>В теореме об СП нет ни строчки об эффективности. Поэтому отсыл к эффективности в качестве аргумента не принимается.

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

S>>Факт упорядочивания ЧИСТЫХ вычислений в СП никому не интересен.

V>Здрастье, приплыли! Ты без этого упорядочивания даже факториал не вычислишь. Причем, это утверждение доказывается ровно в одну строчку. Предлагаю подумать самому.
Ты опять что-то придумал за меня. Я не говорил что порядок вычислений не важен. Я утверждаю что он в отношении побочных эффектов не интересен, в отличии от нечистых вычислений.

S>>Они упорядочивают побочные эффекты. И не в некотором смысле побочные, а в самом прямом.

V>if упорядочивает вычисления как таковые. Это фундаментально по своей природе. А чистые они или нет — дело как раз десятое, когда речь идет о конечном вычислителе.
Нет, не десятое. Чистый statement в СП никому не нужен, ибо единственный эффект от него — счета за электричество.

V>>>Ну а остальное уже подытоживал:
V>>>

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

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

V>Я не вижу, чтобы ты это показал для чистого ФП.
Я показал ложность твоего утверждения.

S>>Упорядочивание вычислений не является побочным эффектом в общеизвестном смысле.

V>Дык, я и так знаю, что придирание шло исключительно к словам... Просто кривое это придирание... или покажи у меня "побочным эффектом в общеизвестном смысле".
V>Я ж говорю: натуральный звездный час блеснуть эрудицией, не? В общем, кому как, а мне порция фана.
Это не новость для меня, почему-то многие для блеска эрудиции и фана употребляют общеизвестные термины в каком-то скрытом и одним им известном смысле. Странный фан, как по мне. В итоге стало ясно что ты употребляешь термины невпопад.

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

V>Дык, если я чего-то недопонял, я переспрашиваю, в каком таком "смысле". Но ты же бодро кинулся отвечать! И даже нагнал пурги сходу в плане отрицания упорядоченности... потом сдулся, правда, бо это было совсем уж нелепо.
Я не отрицал упорядоченность.

S>>Тебе придется убедить меня что туплы/стракты с функциями/указателями на функции не использовались до засилия ООП.

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

S>>>>Что за "экземпляр" монады?
V>>>Это такой функциональный объект.
S>>Что за функциональный объект?

V>Это пара { ф-ия, контекст }.
Выглядит как замыкание

S>>>>Из того что мы можем что-то проэмулировать совсем не следует что мы должны что-то эмулировать.
V>>>Дык, а кто тебя спросит, должен ты или нет? Работа с dictionary в ФП именно так и ведется и я тебе лишь демонстрирую, что "протягивая" последовательность смены состояний некоего объекта (например, dictionary) в ФП можно запросто получить все те же самые эффекты, что в мутабельном мире. Какая нафик разница самим этим эффектам, на каком уровне абстракции они возникли?
S>>Ты ответил на какой-то шум в своей голове, а не на мое утверждение.

V>Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
Значит опять невпопад.
V>Мы и так эмулируем по той лишь причине, что мы пишем модель. Т.е. у нас каждая строчка кода заведомо эмуляция.
Ну так в ФП мы пишем модель (забавно звучит), а не эмулируем побочные эффекты. Вообще, наверное кто как. На тебя не хочется обобщать это утверждение.

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

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

S>>И видишь ли, меня интересует не только сама конечная программа.

V>Дык, это я же тебе и говорю, что тебя боле интересуют догмы. А меня интересует исключительно кач-во конечной программы. Поэтому я закоренелый циник. Мне все ср-ва хороши, если они работают.
Работают практически все средства. Но не все одинаково хороши. Во всяком случае для меня.

V>>>Я уверен — случайно, но ведь попал! В Паскале с рождения присутствует замыкание локальных (вложенных) процедур на контекст вышестоящих. Причем, отменить это поведение нельзя.
S>>Вообще-то я рассчитывал что тебя возмутит идея о происхождении паскаля от лямбда счисления.

V>Да тут и школьнику было понятно, на что ты расчитывал. У тебя в каждом втором посте основной аргумент: "О нет! Неужели?!!" и далее в лицах расписывается трагизм происходящего. Имею полное морального право посшибать лулзов с такого абсолютно неадекватного на техническом форуме подхода к обсуждению.
Имеешь. Сшибай. Только не приписывай мне прозрения в твоих наблюдениях.

S>>Но раз она тебя не возмутила и ты воспринял ее с воодушевлением, то пора завязывать. Я лишь хотел сказать что возможность эмуляции не доказывает родство более близкое чем вычислительная эквивалентность ЛС и МТ.

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

V>Как насквозь мутабельная в каждой строчке ф-ия на С++ может быть чиста... А что толку? Львиная доля современных ошибок (или неожиданных эффектов, не позволяющей программам полноценно работать, например, "пространственный дедлок" двух ендпоинтов в TCP-стеке) случается от недостаточного понимания программистами механики инструмента, включая особенность работы низлежащей аппаратуры (и сети). Как раз по работе много лечу подобного кода... Отсюда столько цинизма, бо повидал достаточно...
Это не цинизм, это банальности. Извини, но мысли вроде "все равно ошибки будут" и "все программы грязны" немногого стоят.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

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

V>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>которое не ограничено временем выполнения внешней функции.

V>Для Паскаля именно временем выполнения внешней ф-ии и было ограничено.
Да не может быть

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

V>Замыканию вообще фиолетово, как переменные располагаются. Локальный контекст одних вычислений доступен в контексте других. Это всё.
V>Вот определение из вики:
V>

V>Замыкание (англ. closure) в программировании — процедура или функция, в теле которой присутствуют ссылки на переменные, объявленные вне тела этой функции и не в качестве её параметров (а в окружающем коде). Говоря другим языком, замыкание — это процедура или функция, которая ссылается на свободные переменные в своём лексическом контексте.

V>Паскалевские локальные процедуры/ф-ии в точности соответствуют.
Читаем дальше

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

туманно, но паскаль отпал. А в английской вики про паскаль прямо и написано что не поддерживает. Да, и не только в ней. На haskell.org тоже написано. Уж там-то наверное в замыканиях знают толк? Хотя, может они не знают толк в паскале
Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь. Как именно — это видно из контекста вокруг определения. Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:

I>>>

I>>>     type
I>>>          pProc = procedure(s:string);
I>>>     function X(s:string):pProc;far;
I>>>          procedure X1;far;
I>>>          begin;
I>>>               WriteLn(s);
I>>>          end;
I>>>     begin;
I>>>          X := @X1;
I>>>     end;
I>>>

S>>Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

I>Тип pProc можно использовать для параметра, но нельзя для возвращаемого значения, это можно обойти хаком.

I>>>Ну и мануал, там есть подсказка
S>>Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

I>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.
По хорошему нужно писать X := X1; Тогда те компилер скажет, что возвращать ссылку на вложенную процедуру — очень плохо. как только ты взял указатель на процедуру — то с ним ты естественно волен делать что хочешь, указатель — это всего лишь указатель..

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, Sinclair, Вы писали:

I>>>>

I>>>>     type
I>>>>          pProc = procedure(s:string);
I>>>>     function X(s:string):pProc;far;
I>>>>          procedure X1;far;
I>>>>          begin;
I>>>>               WriteLn(s);
I>>>>          end;
I>>>>     begin;
I>>>>          X := @X1;
I>>>>     end;
I>>>>

S>>>Отличный пример. А что мешает ему скомпилиться? Извини, у меня TP для проверки нету.

I>>Тип pProc можно использовать для параметра, но нельзя для возвращаемого значения, это можно обойти хаком.

I>>>>Ну и мануал, там есть подсказка
S>>>Ну вот в подсказке вроде очень похожий пример. Неужели TP умеет escape-analysis и запрещает передавать адреса вверх по стеку, разрешая вниз?

I>>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

J>Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
J>Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.
J>По хорошему нужно писать X := X1; Тогда те компилер скажет, что возвращать ссылку на вложенную процедуру — очень плохо. как только ты взял указатель на процедуру — то с ним ты естественно волен делать что хочешь, указатель — это всего лишь указатель..
И при вызове функции по такому указателю начнуться проблемы. Конкретно в этом примере может всё и прокатит,
поскольку Х1 не использует глобальных переменны, но тогда в чём смысл делать эту функцию локальной?
А вся прелесть лямбд в том, чтобы передать указатель на лямбду в качестве параметра некоторого алгоритма,
который принимает указатель на функцию. Так вот в Паскале и в Дельфи брать указатели на вложеные функции НЕЛЬЗЯ.

Здравствуйте, vdimas, Вы писали:

V>Я уже рядом объяснял — как. Например, эмулируешь явно на ассоциативной памяти некую регистровую память — и отгребай сколько угодно. Т.е. достаточно, чтобы "объекты" дизайна ссылались друг на друга не прямо, а косвенно — через такую ассоциативную память (через некий ключ). То бишь, эмулируешь ту самую косвенную адресацию из-за которой всё и происходит в императиве, и получай сколько угодно точно такие же побочные эфекты, ноу проблема.

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

V>Я и говорю, что в строгом смысле разницы вообще нет.

В любом смыле разница есть. И в теории и на практике.

V>Вся разница в том, что случайные побочные эффекты в случае ФП можно огрести не на уровне строчек исходника, а на уровне происходящего м/у оперируемыми абстракциями.

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

V>Как тут рядом правильно хватались за соломинку: "но ведь код эмулятора чист!"
V>О да! Код эмулятора чист.

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

V>Думаю, ты ошибаешься. В строгом чистом языке вообще нет никакого требования, чтобы if возвращало действие.

Это требуется для того, чтоб язык был чистым.

V>См. хотя бы язык Схема — покатит как пример чистого языка?

Нет. Схема чистым языком не является.

V> Чтобы вернуть из ветки if ПФ в Схеме, это надо описать явно. Но ветка в любом случае вычисляется энергично, просто результатом вычисления ветки будет ПФ.

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

K>>Да какие проблемы с аргументами? Если у нас язык строгий, то аргументы вычисляются перед тем, как они передаются в функцию.

V>Я лишь показываю, что для ветвления — важен. То бишь показываю, что if НЕ является обычной ф-ией.

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

V>Даже если ты приведешь на Хаскеле ф-ию, которая будет работать как if... То она будет работать исключительно из-за ленивости Хаскеля. В энергичном языке ты никак не сможешь заменить if некоей равноправной остальным ф-ией.

Правильно. но при чем тут чистота?

V>Если бы был вычислитель, выполняющий бесконечный цикл за секунду, работали бы оба твоих варианта, ес-но. ))

Достаточно тайпчекера, который бесконечный цикл не пропустит.

V>То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения

Это описание ленивости как она есть.

Поэтому вот это вот:
V>будь он хоть ленивым, хоть энергичным.
вовсе не уместно.

V>Ладно, в эту сторону бодаться бесполезно, бо в этой стороне спорим об ощущениях.
V>Лично мне ничего не мешает понять ни то, ни другое. То бишь, запросто смог бы писать компиляторыы ФП-языков, как энергичных, так и ленивых.

Ну давайте ссылки на ваши реализации строгого и ленивого чистых ФЯ. А пока это разговор об ощущениях.

V>Я вижу такую фундаментальную вещь, что в императиве и ФП приходится описывать алгоритмы ровно с одной и той же степенью подробностей. (Именно поэтому я не люблю, когда ФП награждают эпитетом "деларативный").

Декларативность — это не про степень подробности, а про ссылочную прозрачность.

S>>>>>>Что за "экземпляр" монады?
V>Это пара { ф-ия, контекст }.

Ну ладно, допустим, что "экземпляр монады" — это замыкание (хотя это и не так), но где тут идентичность? Идентичности у замыкания нет. Для замыканий вообще эквивалентность не определена, даже структурная.

K>>Наблюдать результат работы программы можно 1) непосредственно, не наблюдая никаких "эффектов".
V>Это не ответ. (С)

Упрощенно говоря, результат программы это байт X по адресу Y — его можно пронаблюдать непосредственно. А производимый для этого эффект — это смена байта X' на байт X по адресу Y на такте N. В большинстве случаев мы эффект не наблюдаем, да и не нужно нам это — достаточно результата.

K>>2) Наблюдая эффекты, но с какой стати они должны быть "побочными"? Эффект побочный, когда он не отражен в сигнатуре функции — но в чистых ФЯ так не бывает — все эффекты отражены в сигнатуре — побочных нет.

V>По определению побочных эффектов, ввод-вывод — это тоже побочный эффект. Поэтому, программа без побочных эффектов — это фантом, а не программа.

-- ввод-вывод - побочный эффект:
writeLine :: String -> ()
readLine :: () -> String

-- ввод-вывод - прямой, а не побочный эффект:
writeLine :: (World, String) -> World
readLine :: World -> (World, String)

Здравствуйте, Jack128, Вы писали:

I>>В этом месте в турбопаскале большая дыра, почти ничем не прикрытая.

J>Сразу говорю — ничего не знаю про класический паскаль, говорю про дельфи(начиная с D3, не знаю, что там раньше было).
J>Так вот, в дельфи — ты сам лично заткнул глотку компилятору, вызвав оператор @.

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Да, соглашусь что именно в этом я попался. Но в остальном притягивании ФП к СП ты так и не отмазался.

V>Ну дык, я же не виноват, что ты не поспеваешь за мной. )
V>Итого:
V>1. аргумент-предикат вычисляется тогда, когда надо будет вычислить одну из веток then-else.
V>2. аргумент-предикат обязательно вычисляется перед вычислением удачной выбранной ветки.

V>Уффффф... ))
ну да

S>>Ты уже задолбал делать выводы по вычислителю.

V>Дело не в выводах, а в том, что все рассуждения должны сойтись на всех моделях, соответствующих рассматриваемому (в данном случае — чистому ФП). ИМХО, полезно крутить в голове семантику собственного кода в случае его ленивого и не ленивого исполнения, верифицируя её идентичность — это как проверка уравнения после решения... поможет, в случае чего, найти ошибки в неверном решении.
О неверном решении чего ты говоришь?

S>>Аргумент был не только в ленивости if-а, если ты внимательно читал. Аргумент был еще и в том, что вычисление ветки чисто.

V>Это НЕ принципиально. В насквозь императивном языке вычисление ветки тоже может быть чисто, даже если будет мутабельность в каждой строчке кода. И прямо отсюда тебе надо искать еще аргументы в разнице происходящего.
Да, вычисление стейтмента может быть чисто. Но толку в этом чистом вычислении не больше чем в Sleep(xxx);

S>>отличие в том, что каждый императивный statement несет побочный эффект, иначе без него можно обойтись.

V>Неверно. Не каждый. А в языке D можно задать гарантии, что ф-ия будет pure, то бишь не будет производить побочных эффектов. При этом будет оставаться мутабельной.
Не каждый, но стейтменты без побочных эффектов бесполезны

S>>Да, я вижу что сводимость вычислителей к МТ дает тебе право не только искать, но даже утверждать об императивности всего что шевелится вплоть до языков высокого уровня. Неясно только, почему Пролог оттуда выбился.

V>Потому что Пролог выполняет высокоуровневый дополнительный алгоритм, вносящий собственную семантику, а ФП и ИП — нет. ФП и императивные языки они описывают одни и те же вычисления ровно с одной и той же степенью подробности (при прочих остальных равных, например при наличии GC). Просто описывают в разном базисе. Из-за идентичной степени подробности мы получаем такой эффект, что если ветвление присутствует в императивном варианте, то оно будет и в ФП-варианте аналогичного кода. Именно такое взаимное обязательное отображения дает мне право назвать эту практику (ветвление) фундаментальной практикой, которая не только имеет аналогичную семантику для ФП и императива, но даже без всякого вреда для этой семантики может быть одинаково реализована что там что там, например когда ФП работает в энергичной манере. А теперь поднимись на пару абзацев выше, и посмотри, что я говорил про проверку семантик на различных моделях.
У пролога есть высокоуровневый дополнительный алгоритм, и потому в нем нет ветвлений.... Отдыхай

S>>Тебе уже намекали что у тела цикла нет результата, потому цикл без побочных эффектов способен лишь греть атмосферу.

V>Мне намекали неграмотные коллеги и я уже на это отвечал. Курите, для начала, определение чистоты функций. В абсолютно чистой ф-ии запросто может быть обычный императивный "мутабельный унутре" цикл.
В чистой функции цикл быть может. А цикл с чистым телом быть может, но не может влиять на вычислимость. Он бесполезен. Читай, на что отвечаешь.

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

S>>А мне прикольно как ты опять влез на МТ

V>Я влез только для демонстрациия обязательного взаимного аналогичного отображения. А то некоторые порой забываются...
Ты опять из отображения сделал какие-то нелепые выводы

S>>Твоя аргументация убивает

V>Опять показываешь всю степень трагизма? )
V>А меня убивает твоя оторванность от понимания работы ФП, хотя ты выступаешь последнее время со стороны этого "лагеря".
А меня твоя отрованность от ФП, ИП, ООП, базовых понятий и прочего.

V>В общем, рядом более грамотный в ФП-лагере товарищь мне вторит: http://www.rsdn.ru/forum/philosophy/4853976.1.aspx

Автор: Klapaucius
Дата: 14.08.12

V>

V>>"в некотором смысле побочный эфект" — я назвал упорядочивание вычислений, на которые можно полагаться в программе.
V>В императивных языках — упорядочивание неявное. В чистых ФЯ — явное. Вот такая вот разница.

V>И далее почитай ветку, там более-менее по-делу.
А я с ним согласен. Это ты что-то вбил себе в голову будто я отрицаю порядок вычислений в ФП.

V>И, хотя я несогласен с формулировкой о неявном упорядочиваниия в императивне (оно дается сверху как обязательно присутствующее в каждой строчке программы), но с явным упорядочиванием на if в ФП он не только не спорит, он даже показывает в след. по ветке посте

Автор: Klapaucius
Дата: 17.08.12

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

V>>>На самом деле вы тут фигней маетесь, но мне было лень расписывать, думая, что вы и так знать должны. Само использование сочетания комбинаторов I/K таково, что упорядочивание происходит как упорядочивание вызовов ф-ий I(K/KI?(x,y)), то бишь происходит такое же упорядочивание как на монаде IO, технически реализуемое как вложение вызовов ф-ий друг в друга. То бишь, даже если в синтаксисе выражения if-then-else все аргументы выглядят как аргументы одного уровня иерархии вычислений, на самом деле одни из них вкладываются в низлежащие вызовы, при росписи этого дела на комбинаторах. И хорошо видно, что для того, чтобы раскрыть цепочку комбинаторов, СНАЧАЛА надо определиться с составом самой этой цепочки (K/KI?), то бишь с аргументом при if — true или false, иначе дальнейшие комбинаторные преобразования в конечный исполняемый код будут невозможны. Я так-то не собирался грузить всей этой догматической чепухой, полагая очевидным здравому смыслу, что аргумент при if, если он вычисляется, он вычисляется всегда РАНЬШЕ нужной ветки (даже если ветка не вычисляется вовсе затем), т.е. считал, что такое де-факто упорядочивание очевидно здравому смыслу в любой технике исполнения ФП, что в энергичной, что в ленивой.

S>>Что-то много букав.

V>Блин, хорош прикалываться. А так и будем ни о чем.
V>Я думал, что очевидно было это: для преобразования вычислений в код необходимо выяснить вид комбинации:I(K(x,y)) или I(KI(x,y)). Если предикат при if невозможно вычислить в compile-time, то такое выяснение оставляется на run-time. То бишь, как ни крути, но получаетсяч фундаментальное требование сначала найти значение true/false (именно уже само значение, а не ленивую ф-ию), и только потом получить правильный хвост выражения, будь он хоть ленивым, хоть энергичным. А все мои якобы "провокационные" заявления об идентичности происходящего что в ФП, что в императиве исходили из того, что в энергичной технике исполнения ФП будет ровно аналогичное (почему так — уже доказал), а семантика ленивого вычисления не должна отличаться от семантики энергичных. Всё!
Много букв, а требование это вовсе не требование, см. ниже.

S>>Да, конкретно в хаскеле K/KI будет вычислено раньше.

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

S>>понимаешь, в СП можно написать как "a;b;", так и "b;a;". В результате мы будем иметь разный мир (т.к. результатов у стейтментов нет).

V>Ээээ... а причем тут это и ветки if?
Притом что структурный if управляет выполнением именно стейтментов

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

if (condition)
{
    5;
}
else
{
    3;
}

Кому это нужно, если if это стейтмент, а не выражение?

Здравствуйте, vdimas, Вы писали:

I>>Ты использовал для аргумента локальные функции == без пяти минут лямбды, это и есть функциональщина.
I>>Указатель на функцию — снова поддержка ФП.

V>Блин, да ты код из 5 строк прочесть уже не в состоянии?
V>Ты сейчас имел ввиду локальные ф-ии наподобии паскалевских вложенных? Покажешь в моих примерах аналогичное, не? )))
V>Ес-но в Паскале вложенные ф-ии являются полноценными замыканиями сами по себе. Но из-за b[ ограничений в подробностях Паскаля хрен ты подашь AddressOf этой вложенной ф-ии куда-то вне вышестоящей ф-ии, в которой она объявлена — будет маленький бумц с большими последствиями.

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

V>Это указатель на алгоритм. Да, алгоритмы можно привязать к данным. А ты думал, ООП с луны свалилось? Оно уже вовсю использовалось в модульном программировании, только ручками.

То есть, указатель на функцию не есть данные, потому что не хватает привязки. Опаньки !

V>Или тебя смущает именно указатель?
V>Ноу проблема, пронумеруй алгоритмы и диспатч их на switch/case. Та же фигня, вид в профиль. То бишь, появление адреса ничего не меняет в дизайне, просто дает более эффективный способ переключения алгоритмов.

Со свичем тебе понадобится кода почти в 100 раз больше

>>>Сравни с ООП — это совсем другая вселенная. В этом смысле ФП фундаментально недалеко ускакало от процедурного подхода, что я и заметил упомянув дизайн.
I>>В твоей трактовке это так потому что в процедурное ты записываешь фичи из ФП.

V>Это с каких пор ФП оперирует адресом ф-ии??? В ФП ф-ия представлена малость сложнее, чем просто адрес. Собсно, всю механику я тебе уже показал.

ФП реализовано в С чз указатели на функции.

V>>>Гы, ты еще и контекст теряешь... Имеет значение там, где ты говорил о разнице в 10-100 раз для последнего своего примера на лямбдах, будь он переписан без них. Сорри, но такой прогноз можно дать только от непонимания механики работы ФП.
I>>Нет, не имеет.

V>Будь мужиком, скажи прямо — насчет своей оценки в 10 раз ты откровенно лажанул.

Ни в коем случае. Ниже ты подтвердил именно то, о чем я говорил в самом начале
1. тебе надо описывать структуру для захвата + делать поддержку этого в инфраструктуре
2. описывать функцию для работы со структуриной — кода в любом случае больеш чем для лямбды
3. выполнять сам захват
4. эмулировать GC

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

V>Такое резкое сокращение кода вообще способны дать только макросы или обобщенное программирование, но не разница в парадигмах. Они им перпендикулярны.

Макры и обобщенное программирование это тоже парадигмы.

I>>Тогда покажи аналог моего кода на языке СИ.

V>У тебя в коде используется обобщенное программирование, поэтому я тоже применил обобщенное программирование для аналога. Но я не использовал никакого ООП. Обобщенное программирование было применено к структурам и свободным процедурам/ф-ям. Если ваять на чистом С, то моя инфраструктура переползет на макросы. И то и то — кодогенерация, но обобщенное программирование типобезопасно, поэтому показалось мне более интересным для демонстрации.

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

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

V>Мне и не надо ничего захватывать. Захватить я могу явно.

Чушь. Покажи полноценный пример, который можно скомпилировать. Я сделаю тоже самое, результат сравним. Идёт ?

I>>1. описать структуру для захвата

V>Можно. А в 99% случаев хватит некоего обобщенного Tuple.

ФП тебе не помогло, ты решил взять в помощь парадигму обобщенного программирования ?

I>>2. описать функцию которая будет работать с этой структурой

V>Дык и в ФП целевую ф-ию описывать надо.

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

I>>3. выполнить захват, то есть создать экземпляр, инициализировать

V>В C/С++ это выполняется в человеческом синтаксисе:
V>

V>struct { int a; int b; } context1 = { 42, 43 };
V>TUPLE((int, float)) context2 = { 42, 43.44 }; 
V>

А у меня здесь будет одно лямбда выражение.

I>>4. освободить память (хрен знает когда)

V>Да. Но техника GC, оп-па, тоже нейтральна к парадигмам.

То есть, тебе и здесь надо руками пихать ?

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

V>Дык, в STL ф-ия qsort — это внешняя свободная ф-ия, а не метод объекта. И работает над любыми итераторами произвольного доступа и с любыми предикатами сравнения.

STL это ни структурное, ни процедурное, это совершенно иная парадигма, точнее целых три — ООП + ФП + обобщенное.

Здравствуйте, vdimas, Вы писали:

I>>То есть, ты только что удесятерил минимально необходимое количество кода.

V>Ты так и не показал удесятирение. А разговаривать ярлыками со мной бесполезно.

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

У тебя варианты — 1 вилять и уклоняться 2 показать код

I>>А это именно то о чем я говорил — ручное связывание.

V>Не вседа это связывание (пытаюсь опять обратить на этот ВАЖНЫЙ аспект твоё внимание). Зачастую выгодней или надежней создать копию значения для замыкания. Но тебе как об стенку горох. Да, в процедурном программировании способ передачи данных в процедуры — это часть дизацна и часть работы программиста.

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

V>Т.е. да, я ручками тебе показал то, что в лямбдах происходит автоматом. Я именно это и обещал показать.

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

I>>Ты бил себя пяткой в грудь что это не надо.

V>Фантазии. Ветка на месте, можно освежить, коль забыл.

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

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

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

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

V>Прочитав это предложение я уже малость сомневаюсь, что же ты имел ввиду под "локальными ф-ями"? Я имел ввиду обычные ф-ии, которые имеют некую ограниченную область видимости, чтобы не засорять ими глобальную видимость из всего проекта.

Локальные функции == вложеные функции.

Здравствуйте, SV., Вы писали:

SV.>Просто потому, что мы мыслим объектами.

Надо хорошо засрать мозги, чтобы начать "мыслить" объектами.

Это видел?

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

Здравствуйте, igna, Вы писали:

I>Надо хорошо засрать мозги, чтобы начать "мыслить" объектами.

I>Это видел?

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

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

Здравствуйте, samius, Вы писали:

S>Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь.

Она позволит этого достичь только в связке с GC. Это там же было написано? Разве нет? ))

А может, потому что конкретный эффект, на который ты ссылаешься, действительно никак без GC не работает? А может, никто в зравом уме не захотел подставляться и приписывать такую хрень, что замыкания и GC неразрывно связаны?

ИМХО, там привели лишь один из возможных эффектов, который можно достигнуть в этой технике. Не надо делать из этого такие далекоидущие выводы.


S>Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

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

Здравствуйте, samius, Вы писали:

V>>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

S>На бумажке в клеточку. Там же была документация по паскалю, срисованная с доски. Время на писюках предоставляли лишь с 3-го курса, и то его хватало лишь на вбить код и получить результат. Т.е. возможности для глумления над паскалем не было.

Т.е. специальность непрофильная...
Наверно, поэтому не хватает здравого цинизма во взгляде на вещи ))

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Мое мнение здесь такое, я его уже писал. Замыкание — это конкретная техника, а в определении написано что она позволяет достичь.

V>Она позволит этого достичь только в связке с GC. Это там же было написано? Разве нет? ))

V>А может, потому что конкретный эффект, на который ты ссылаешься, действительно никак без GC не работает? А может, никто в зравом уме не захотел подставляться и приписывать такую хрень, что замыкания и GC неразрывно связаны?
Чушь, в делфи работает на подсчете ссылок

V>ИМХО, там привели лишь один из возможных эффектов, который можно достигнуть в этой технике. Не надо делать из этого такие далекоидущие выводы.


S>>Я согласен с тем что паскаль реализовывал эффект, описанный в определении, но называть это замыканием не считаю верным.

V>Странная у тебя манера ведения пора — половинчатая. Несогласие ты высказал, но я не увидел твоих альтернатив. Как же назвать технику, на которой работают вложенные ф-ии Паскаля?
Я ее называю "указатель на фрейм стека".

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Интересно, а на чем ты делал лабораторки по программированию в ВУЗе?

S>>На бумажке в клеточку. Там же была документация по паскалю, срисованная с доски. Время на писюках предоставляли лишь с 3-го курса, и то его хватало лишь на вбить код и получить результат. Т.е. возможности для глумления над паскалем не было.

V>Т.е. специальность непрофильная...
Ну как, специальность — математик. С компами тогда напряженка была.

V>Наверно, поэтому не хватает здравого цинизма во взгляде на вещи ))
Я вижу, твой здравый цинизм ни к чему хорошему пока не привел.

Здравствуйте, vdimas, Вы писали:

V>Как же назвать технику, на которой работают вложенные ф-ии Паскаля?

Техника называется "static chain", изобрели ее около 1964-го года Рэндалл и Рассел, описана в Algol 60 Implementation — B.Randell & L.J.Russell, Academic Press, 1964.
А технику "замыкание" изобрел в том же году Ландин и реализовал впервые в SECD.

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

Здравствуйте, Klapaucius, Вы писали:

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

K>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.

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

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

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