Здравствуйте, IT, Вы писали:
FR>>Это если возвращать в качестве замыкания обычные сишные указатели на функции, но кто запретит возвращать просто объекты функторы? Или просто делать переменные участвующие в замыкании живыми до завершения программы(выделять через new POD структуру).
IT>Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.
А ты не возвращай указатель. И то что все рассыплется это нормально для C++
FR>>Кстати на шарпе проще эмулировать замыкания чем на C++ не из-за того что там есть GC, а потому что делегат это объект.
IT>И это тоже, что лишь доказывает, что если язык/среда выполнения не позволяют, то никакой сахар не уже поможет.
Позволяют, так же как и шарп, но как и всегда при работе на C++ требуется быть осторожным.
IT>>>Тогда вопрос. Чем это будет принципиально отличаться от варианта реализации замыканий с помощью объектов? Только тем что алгоритм сложнее и оптимизация вшита в сам компилятор?
FR>>Только тем что реализовать можно по разному, даже в NET при желании можно сделать не через объекты, а как в окамле или питоне. И поэтому код из рефлектора никак ни катит в качестве доказательства того что те же замыкания являются синтаксическим сахаром.
IT>Код из рефлектора не просто не "не катит", он явно и наглядно демонстрирует, что это всё сахар. Не видеть этого нужно очень очень сильно хотеть. Вот примерно как ты
Ладно похоже пора закруглятся, похоже мы так и будем кругами ходить.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.
VD>Все относительно. Для языка вроде ассемблера сахаром будет почти что угодно. А для С, например, уже нет.
Нет сахар это только косметика.
VD>В общем, можешь называть это как угодно. Можешь фичами, можешь сахаром, можешь трехэтажным словосочетанием. Главное смысл. А смысл в том, что у ООП или ФЯ нет и не может быть оверхэда так как это паттерны. Нет реализации этих паттернов в языке и писать в этом стиле становится громоздко и неуклюже. Есть — и все становится куда лушче. Использовать возможности языка не по назначеню можно независимости от того ООЯ он или ФЯ. Каждый из типов языков хорош в одном и плох в другом.
А с этим согласен. А для того что вы называете сахаром лучше придумать свое новое (или найти старое) слово, и не путать людей.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
VD>>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?
FR>>А у тебя?
VD>Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?
Нет, к сожалению не являюсь представителем этой многоуважаемой нации
Кстати задавая этот вопрос ты занимался именно уходом от ответа
Вообще пора закруглятся.
Здравствуйте, FR, Вы писали:
IT>>Ключевое слово я выделил. Смысл в том, что без стопроцентной поддержки со стороны runtime — это всё только разговоры. Мне достаточно вернуть не объект функтор, а указатель на него и вся твоя стройная теория рассыпется.
FR>А ты не возвращай указатель. И то что все рассыплется это нормально для C++
Это нормально для C++, но не нормально для FP.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>На самом деле все очень зависит от точки зрения. Но непонимание того смысла в который вкладывается в слово сахар в данном случае скорее демонстративное. Оно нужно лишь для того чтобы уйти от основного вопроса "Существует ли ОО-оверхэд?". Доказательств обсурдности этого вопроса тут было предостаточно. Но оппонетны решили сосредоточиться на борьбе с терминами.
ОО-оверхэд зависит от задачи, для некторых да существует, для других задач ровно наоборот.
Но если брать так скажем локальный код, то ФЯ стиль для этого случая почти всегда лучше, компактнее и яснее. (В общем это Гаптерон уже лучше меня объяснял).
Здравствуйте, FR, Вы писали:
VD>>>>У тебя хобби такое "разговоры не по существу"? Или работа программиста убивает разумное абстрактное начало?
FR>>>А у тебя?
VD>>Месье блюдет национальные традиции или отвечая вопросом на вопрос он пытается уйти от ответа?
FR>Нет, к сожалению не являюсь представителем этой многоуважаемой нации FR>Кстати задавая этот вопрос ты занимался именно уходом от ответа FR>Вообще пора закруглятся.
То есть на вопрос я ответ не получу? Тогдя я не считаю нужным отвечать на твои вопросы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>То есть на вопрос я ответ не получу? Тогдя я не считаю нужным отвечать на твои вопросы.
А вопрос то был?
Я на твою реплику что нет языков без ФВП привел несколько примеров таких языков, после чего ты резко начал обвинять меня в разговорах не по существу, конечно классный способ ухода, но тут уж не моя вина.
Здравствуйте, VladD2, Вы писали:
L>>Я, наверное, лучше знаю, что просил:
VD>
Причем тут Си? Мои слова "Применение ФВП же вместо классов относится к выразительности формализма, а не кода". Это раз. Во вторых, из того, что замыкания и лямбды делают применение ФВП слаще, не следует, что само ФВП становится сахаром
Эти слова как то доказывают, что я не знаю, чего просил??
Почитай на что отвечал WolfHound, и что ему ответил FR.
Почитаю, спасибо.
VD>Просто вам подсевшим на ФЯ не вызвает проблем говорить о недостатках не ФЯ м не хочется признать что ФЯ сами не предоставляют тучи сахара (не реализуют паттернов). Только это ОО-сахар, ОО-паттерны.
А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.
L>>Вы показали, что их можно сэмулировать. Поздравляю!
VD>Их можно вырзить другими средствами языка. Никакой эмуляции.
Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то. Так что это другое что то ведет себя как первое.
Здравствуйте, VladD2, Вы писали:
L>>А на фига мне это видеть??
VD>Ты споришь с очевидным. Не очевидно это для тебя только потому, что ты упорно не хочешь видеть.
Нет, я стараюсь быть объективным. Из определения сахара следует, что лямбда не сахар.
L>>Влад, то что это можно добавить, я как бы догадываюсь. Спор был о том является ли лямбда сахаром.
VD>Средствами языка выражается? Да. Добавить можно не меня ничего? Несомнно. О чем тут можно спорить? VD>Лябда есть реализация паттерна который и так можно получить, но при этом будет больше кода и каждый раз прийдется следить за саблюдением паттерна. Встраивание паттера в язык увеличивает количество сахара.
Ага. Значит, если некий паттерн, который мы рисуем на языке, мы будем выражать с помощью новой конструкции, то эта конструкция становится сахаром. Я имею в виду — не было раньше ФВП, мы эмулировали их объектами, появились — мы стали ими пользоваться. Это называется сахаром, потому что раньше мы могли их выразить другими средствами языка. Про семантическую эквивалентность и выразительную мощь забудем.
Хорошо, пусть это будет определением твоего понятия сахара.
VD>В общем, не хотел снова влезать в этот бесцельнысй сопр. Логика все равно в нем давно отсуствует. А религия меня не интересут. Наверное зря я все таки влез. Ну, да ладно...
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, FR, Вы писали:
FR>>>С этим можно согласится, но здесь утверждают что всё (кажется кроме GC это похоже некая священная корова) сахар.
VD>>Все относительно. Для языка вроде ассемблера сахаром будет почти что угодно. А для С, например, уже нет.
FR>Нет сахар это только косметика.
VD>>В общем, можешь называть это как угодно. Можешь фичами, можешь сахаром, можешь трехэтажным словосочетанием. Главное смысл. А смысл в том, что у ООП или ФЯ нет и не может быть оверхэда так как это паттерны. Нет реализации этих паттернов в языке и писать в этом стиле становится громоздко и неуклюже. Есть — и все становится куда лушче. Использовать возможности языка не по назначеню можно независимости от того ООЯ он или ФЯ. Каждый из типов языков хорош в одном и плох в другом.
FR>А с этим согласен. А для того что вы называете сахаром лучше придумать свое новое (или найти старое) слово, и не путать людей.
Есть такое понятие — лингвистические абстракции (lingustic abstractions). Изначально у нас есть некий базовый язык — по сути описание вычислительной модели. Как правило хорошо поддающийся теоритическим исследованиям, но мало пригодный для программирования на нем человеками. Для повышения удобства начинаем расширять базовый язык, при этом расширения транслируются в простой базовый синтаксис. Так вот эти расширения и разделяют на лингвистические абстракции и синтаксический сахар. Основное отличие — лингвистические абстракции не привязаны к конкретному языку, примеры — оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п. Синтаксический же сахар это расширение синтаксиса базового языка не вносящее новых абстракций, просто служащее сокращению кода и повышения его читабельности. При этом сахар специфичен для каждого языка и более того среди разных групп разработчиков имеются свои представления о кратком и читабельном коде
ты ведешь речь об ФВП, но реально подразумеваешь замыкания и лямбды. Иначе твои слова бессмысленны. Ведь ФВП по их классическому определению есть почти в любом языке. Тогда о каких приемущесвах и ФП идет речь. В других языках просто не делают мантру из повседневных вещей. Мне лично по фигу называется ли нечто умным словом ФВП или просто колбэками.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Затем, что ты это утверждал.
Я утверждал что сахар — это замыкания и лямбды.
Так же утверждал что слова "оверхэд ООП" — это бессмыслица.
В общем-то ты не привел ни одного аргумента против кроме того что тебе кажется что это не так.
L>А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.
А я ни на что не подсаживался. Я рассматриваю все не более чем как приемы программирования, а наличие средств поддержки этих приемов в языке как полезный сахар этого языка упрощающий мне жизнь. Только и всегт. Так что когда я познакомился с ООП, то с удовольствием стал применять его приемы в работе. Когда познакомился с ФП, то и его приемы стал с удовольствием применять. И паттерны тоже. И все остальное тоже. Так что я за более богатые языки позволяющие выражать мысли кратче и с использованием большего количества выразительных средств.
Это ты тут доказываешь какой-то выдуманный оверхэд ООП. А я просто использую ООП там где от него есть реальная польза. А на термины мне в обще-то начхать. Сахар, паттерны, фичи. Все равно. Лиш бы было они были.
L>Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то.
А где ты видишь имитацию? Это оно и есть ФП. Только выражается без нужных фич (встроенных паттернов или сахара, как тебе удобнее).
Так что ты просто не верно смотришь на проблему. Ты считаешь эмитацией банальное использование паттерна не встроенного в язык явно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mikl Kurkov, Вы писали:
MK>Есть такое понятие — лингвистические абстракции (lingustic abstractions). Изначально у нас есть некий базовый язык — по сути описание вычислительной модели. Как правило хорошо поддающийся теоритическим исследованиям, но мало пригодный для программирования на нем человеками. Для повышения удобства начинаем расширять базовый язык, при этом расширения транслируются в простой базовый синтаксис. Так вот эти расширения и разделяют на лингвистические абстракции и синтаксический сахар.
До этого момента вопросов практически нет. Согласен с определениями. Разве что хочу заметить, что для разных языков список таких абстракций может быть разным. И еще что одни бстракции могут выражаться другими. Так что разумнее вести речь о неком минимальном наборе абстракций через которые можно вырзить другой более широкий набор абстракций. Вот он то и будет являться сахаром.
MK>Основное отличие — лингвистические абстракции не привязаны к конкретному языку, примеры — оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п.
А вот тут уже не согласен. Конструкции вроде "оператор условного перехода, list comprehensiions, карринг, оператор for, foreach и т.п." могут отсуствовать в языке и тогда они будут синтаксическим сахаром для этого языка, а могут являться его базой.
Отличным примером этого служит Немерле где понятие базы языка четко выделено. В языке нет "операторов условного перехода if, list comprehensiions, карринга, оператор for, foreach, а так же, return, continue, break и т.п.". За-то есть замыкания, локальные функции, лябды, изменяемые переменные, оператор match, и блоки (позволяющие прервать нормальный ход выполнения функции (замена return, continue и break), классы, варианты (алгеброические типы), перечисления, методы, свойства и атрибуты (расширение методанных как в C#). На этой базе те самые отсуствующие сущности: "операторов условного перехода if, list comprehensiions, карринга, оператор for, foreach, а так же, return, continue, break и т.п." реализуются с помощью маросов. Причем сам факт реализации на макросах говорит отом, что сущности являются тем самым сахаром.
Так вот на самом деле набор базовых фич может быть и другим. В общем-то замыкания и лямбды тоже можно заменить на более базовые вещи — классы. Но это будет уже другой язык.
MK> Синтаксический же сахар это расширение синтаксиса базового языка не вносящее новых абстракций, просто служащее сокращению кода и повышения его читабельности. При этом сахар специфичен для каждого языка и более того среди разных групп разработчиков имеются свои представления о кратком и читабельном коде
Вот именно об этом я и говорю! Забвно, что lomeo поставил тебе оценку, но при этом во всю спорит со многими тем о чем ты тут сказал.
MK>Очень хорошо и подробно об этом написано в CTM.
Осталось выяснить что такое CTM.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ты ведешь речь об ФВП, но реально подразумеваешь замыкания и лямбды. Иначе твои слова бессмысленны. Ведь ФВП по их классическому определению есть почти в любом языке. Тогда о каких приемущесвах и ФП идет речь. В других языках просто не делают мантру из повседневных вещей. Мне лично по фигу называется ли нечто умным словом ФВП или просто колбэками.
Влад ты ошибаешься, я веду речь именно об ФВП. (map display list) — это применение ФВП map.
Преимущество ее по сравнению с циклом foreach в отсутсвии дополнительной сущности — идентификатора элемента списка, а по сравнению со списком for — ещё и счётчика цикла. И я не вёл речь о языке, поэтому то, что ФВП есть в любом языке — это не ко мне.
Когда я говорю что главные отличительные черты функционального подхода — это ФВП и отсутствие сайд-эффекта, то под ФВП я понимаю именно ФВП. А не лямбды и замыкания. И пусть ты называешь их колбэками.
Повторяю — во всех своих сообщениях, говоря об ФВП, я подразумевал ФВП. Даже если от этого мои слова казались тебе бессмысленными.
Здравствуйте, VladD2, Вы писали:
L>>А вам, подсевшим на ОО, тяжело смириться с тем, что ФВП — не сахар.
VD>А я ни на что не подсаживался.
Я тоже. Но ты начинаешь развешивать ярлыки.
VD>Это ты тут доказываешь какой-то выдуманный оверхэд ООП.
Да, ОО более многословен. Он использует больше сущностей.
VD>А я просто использую ООП там где от него есть реальная польза.
Аналогично. Может я на ОО тоже подсел?
L>>Это одно и то же. Эмуляция — это имитация поведения (функционирования) чего то с помощью другого чего то.
VD>А где ты видишь имитацию? Это оно и есть ФП. Только выражается без нужных фич (встроенных паттернов или сахара, как тебе удобнее). VD>Так что ты просто не верно смотришь на проблему. Ты считаешь эмитацией банальное использование паттерна не встроенного в язык явно.
Не хочу. А то будем выяснять что такое эмуляция и что такое имитация
Да и с твоим определением сахара вроде разобрались, чего уж там дальше?
Здравствуйте, lomeo, Вы писали:
L>Когда я говорю что главные отличительные черты функционального подхода — это ФВП и отсутствие сайд-эффекта, то под ФВП я понимаю именно ФВП. А не лямбды и замыкания. И пусть ты называешь их колбэками.
А, ну, мы плавно вернулись обратно к главенствованию неизменямости данных. Ясно.
- А где вы деньги берете?
— В тумбочке.
— А в тумбочке откуда деньги берутся?
— Жена кладет.
— А жена где берет?
— Я даю.
— А вы где берете?
— Я же уже говорил!...
Вот в С есть и ФВП и "айдэфеты". И что? И никаких проблем по этому поводу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Я тоже. Но ты начинаешь развешивать ярлыки.
Погоди. А кто о мифическом ООП-оверхэде говорил? Я?
VD>>Это ты тут доказываешь какой-то выдуманный оверхэд ООП.
L>Да, ОО более многословен. Он использует больше сущностей.
Значит таки подсаживлася.
VD>>А я просто использую ООП там где от него есть реальная польза.
L>Аналогично. Может я на ОО тоже подсел?
А ты его используешь? Это видимо из-за того что он более многословный, а вам за количество символо платят. Да?
L>Да и с твоим определением сахара вроде разобрались, чего уж там дальше?
Интересный у вас подход к разбирательству. А еще о ярлыках веч ведете...
Мы тут с полностью мифически ОО-оверхэдом разобраться то не можем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
