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

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

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

V>[скипнул 50 вопросов "а где идентичность?"]
Правильно что скипнул. Они предназначались не для того что бы ты на них отвечал, а что бы ты перестал пороть про подписку колбочек на получение фотонов. С 50-го раза походу тебя все-таки проняло, с чем и поздравляю.

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

V>Да двойка опять, се ля ви. Идентичность — это тоже элемент модели, то бишь тоже результат абстрагирования.
Ну надо же, вот и озарение наконец-то.

V>Кароч, ликбез: тела в рж могут состоять из разнородных элементов — частиц, те в свою очередь из более мелких и т.д... и даже на сегодня науке ХЗ из чего состоят кварки. Набор тел, в свою очередь, может образовывать некую макросистему. Задача "идентити" в модели — представить экземпляр некоей логической сущности как неделимое понятие, асбтрагировавшись от её устройства. Всё!
Ну вот видишь, какая хрень получается... В рж макросистемы частиц, а в модели неделимое понятие с идентичностью. И после этого ты мне будешь говорить как ООП модель близка к рж? Походу ты забил гол в свои ворота.

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

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

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

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

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

S>>Эк ты съехал-то... Для непонятливых повторяю, что я имел в виду нечистый код на хаскеле без бэкдоров. Теперь почитай, что ты мне отвечаешь. И кто тут юлит после этого?

V>Ес-но юлишь только ты, я готов подробно и терпеливо отвечать на что угодно.
Не вижу ответа на просьбу грязного кода
V>Конкретно здесь я тебе на это уже неоднократно возражал: если мы можем повторить все побочные эффекты без бэкдоров, то какая разница, что некий отдельный кусочек твоего кода чист? А вот ты, увы, на это ответить не смог ни разу. Ты лишь способен цепляться за тот факт, кто некая выделенная ф-ия в Хаскеле чиста. И, выждав паузу после очередного неотвеченного возражения, приводишь этот факт опять. Детсад... потому что дальше этого полный ступор в рассуждениях. Разве не видишь перехода от комбинации чистых ф-ий к точно таким же побочным эффектам, как в императиве? Это же простейший переход через трюк ассоциативности. Что здесь сложного? Этот трюк в наверняка используется в любой более-менее большой программе многократно.
Так код будет? Способен я или нет, потом обсудим.
Только и у тебя тут ясли намечаются. У чистого кода есть определение. В этом определении нет ничего о том, моделируется ли с помощью чистого кода грязный эффект или нет. Потому, даже моделирование грязных эффектов с помощью чистого кода формально будет чисто. Только в ФП моделирование грязи — это не единственный способ писать программы.

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

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

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

V>Ес-но пытался, но был пойман.
Не пытался и пойман не был. Хорош выдумывать.

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

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

Оператор if в Хаскеле НЕ является обычной чистой ф-ей, порядок вычисления аргументов который произвольный.

даже "НЕ" выделил.

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


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

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

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

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

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

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

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

V>Ну опять тебе двойка. Курить определение чистоты до просветления.
Сам кури, у тебя с ним проблемы.
V>Вот тебе пример мутабельной ф-ии на С++, которая абсолютно чиста:
V>

V>int sum(int a, int b, int c) {
V>  a += b;
V>  a += c;
V>  return a;
V>}
V>

Я не спорю что она чиста. Теперь покажи мне насколько эта чистая функция полезна внутри ветки if-а в качестве стейтмента. Покажи, как ты используешь ее результат.

V>Я уже где-то рядом ловил тебя на том, что ты не понимаешь, что есть чистота вычислений. Собственно, о чем ты тогда спорил?
Ты ловишь голоса в твоей голове. А то что я пишу — ты понимаешь от силы процентов 40... Возможно меньше, т.к. доходит раза с 50-го, как с идентичностью. И то уверенности нет что ты меня понял.

S>>Я показал ложность твоего утверждения.

V>Еще раз, приведи такой пример, который, по твоим же словам:
V>

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

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

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

V>Акцент был на том, что это упорядочивание вычислений ОБЯЗАТЕЛЬНО, невзирая на всю чистоту. Поэтому и говорилось, что происходящее при ветвлении в ПП и ФП фактически не отличается (ньюансы мы уже обсуждали, в т.ч. ньюансы во время ленивости). Ты прекрасно вначале уловил акцент и оспаривал именно его в течении нескольких постов, пока не понял свою ошибку. Но теперь пытаешься вернуться к самому началу и пытаться начать цепляться к словам. Поздно, все ходы записаны. Я обещал показать аналогичное происходящее в ФП и ПП? — я показал. Будешь опять здесь юлить — попрошу "помощь зала" рассудить, делов-то. Увидишь во всей красе новую тему со всеми твоими цитатами в хронологическом порядке...
Помощь зала — ну что же, я не возражаю. Но раз ты заговорил о зале, погляди сначала сколько минусов ты наковырял в этой теме. Да, и перечитай мои сообщения внимательно раз по 50. Возможно поймешь о чем я, но не факт.


S>>Я не отрицал упорядоченность.

V>Кто-то вскрыл твой аккаунт и писал от твоего имени?
ссылку

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

V>Легко. Курить историю IDL-языков.
V>Кстате, для начала даже саму аббревиатуру. ))
пруф-то будет? Ты приведи пруф, а там я покурю что сочту нужным.


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

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


V>>>Я ответил на твой вопрос "должны мы или нет?". Перечитывать до просветления.
S>>Значит опять невпопад.

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

S>>Лично для меня неспециально плодить грабли в грязном коде куда проще.

V>О! Таки перешел уже от утверждения абсолюта к обсужденю оттенков?
V>Молодец. Не прошло и сотни постов.

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

S>>Работают практически все средства. Но не все одинаково хороши. Во всяком случае для меня.

V>Про компроммисы в ФП я уже устал писать. Пока что в реально существующем ФП всё скорее плохо, чем хорошо. Не знаю, что там для себя ты увидел... Как велосипед для ума — ну ОК, одобряю. Как практически применимую вещь — только в виде инструмента написания некоммерческих утилит. И то не всех, бо даже утилиты разные бывают. В общем, только для кода, к которому нефункциональные требования отсутствуют как класс.
Спасибо за мнение, но твоя система оценок скомпрометирована.

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

V>Не надо меня упрощать. Я претендовал на то, что у меня есть некая статистика по ошибкам из очень многих проектов. Так вот, доля ошибок по причине приписываемых императиву ужасов настолько ничтожна в общей массе вылавливаемых ошибок, что их обсуждение попахивает откровенным нубством на проф-форуме. А как усиление комичности ситуации выступает тот высмеиваемый мною факт, что ФП некоторыми преподносится как панацея. А какая это может быть панацея от логических ошибок, совершаемых программистом? Да никакая. Когда-то я тщательно спорил с thesz именно вокруг этой темы, а он, скажем прямо, намного более сильный функциональщик, чем многие из моих нынешних оппонентов из ФП лагеря на рсдн. И этим "оппонентам" я уже устал повторять, что не надо вестись как дети на фразы, что мол "чистый код декларативен". Это условности, это недоступные разработчику плюшки, а лишь сугубо св-во досутпных компилятору преобразований... бо реально в современном ФП необходимо описывать ту же степень подробности решения, что и в императиве (ООП). И как раз из-за равенства уровней описания обе техники провоцируют равное кол-во ошибок в реальных проектах с точностью до несущественных погрешностей. Вот и всё кино. Остальное — не более чем религия и дань моде.
Тот факт что ты спорил с thesz говорит лишь о том, что thesz был с тобой не согласен и только. И никак не доказывает твою правоту в чем-либо. Скорее наоборот.

V>Рядом я обсуждал, что именно было бы неплохо добавить в императивный ЯП, чтобы делать меньше тех самых ошибок. Я предлагал для С++ аналог pure из D. И заметь, что ФП в данном случае вообще никаким боком, бо функция/метод может быть чистым, он даже может изменять внешние (поданные по ссылке) данные, но при этом быть абсолютно pure. То бишь, легким движением руки я показывал, как можно преодолевать все "ужасы" императива, не плятя при этом высокую цену в виде ограничений, присущих "чистому ФП".
Одной рукой ты говоришь что в чистом языке ошибки те же самые, а другой тут же говоришь что при помощи аналога pure для императивного ЯП ты собираешься преодолевать ужасы императива. И это в одном и том же сообщении в соседних абзацах!!!
Ну и как к этому еще относиться? Извини, но тут у меня лишь ирония.

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

I>Цель у человека это не написание библиотеки

Если человек художник или повар — то цель у него, конечно, не написание библиотеки. Даже если человек программист, то цель у него, скорее всего не написание библиотек и даже не программирование как таковое. Но чтоб добится всех этих целей, программисту нужны, например, деньги, которые он зарабатывает. Как? Программированием! А программирование — это написание библиотек и/или "склеивание" их между собой. не обработка видео. Да, возможность хорошо "склеивать" библиотеки — это даже еще более важное свойство языка (есть же скрипты, которые для написания библиотек подходят плохо, а заточены исключительно на склеивание).

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

Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).

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

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

K>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>ну вот, "можем себе позволить" ты определил через "можем себе позволить"

Какие проблемы с пониманием смысла "что может себе позволить"? Допустим, что кто-то имеет желание купить дом, но не имеет возможности. Но имеет возможность купить козу, но не имеет желания. В вашем мире уже не надо пить за то, чтоб желания совпадали с возможностями, потому что вы их и так не различаете.

I>Передача вниз нужна для упрощения связывания

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

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

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

I>Зеваю — лямбда-лифтинг в общем случае не поможет.

А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.

I>>>Внятно сказано — стек был и до алгола
K>>Где?

I>Мне не интересно, я показал тебе слова автора алгола, а ты думай сам.

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

K>>"Легко" — это зависит от хаскелла как языка. "Эффективно" — это зависит от качества его реализации, которой еще далего до нужного уровня. Т.е. мы останавливаемся на пункте 2, до сравнения языков еще далеко.
I>То есть, хаскель непригоден для решения таких задач, ЧТД.

Не подходит его имплементация. Вот авторы имплементаций C++ отлично понимали в чем тут разница, поэтому сейчас его имплементации для этих задач вполне подходят.

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

Вы тут противоречия не видите? Например, между "одно и то же" и "есть разница"?

I>>>Пустой контекст это просто конкретный случай а не новое понятие.
K>>Новое понятие, которое вы вводите, для объединения замыкания с "не замыканием" — действие не только бесполезное, но и вредное, согласно вашему же обоснованию.
I>Выделеное прочесть не алё?

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

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

K>>Никто не изобретает языки, например, для разработки компиляторов,
WH>Я изобретаю.

Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет. Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.

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

Стоп. Вы пишете ДСЛ на языке общего назначения. Чем это эффективнее написания ДСЛ на языке общего назначения?

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

K>Если человек художник или повар — то цель у него, конечно, не написание библиотеки. Даже если человек программист, то цель у него, скорее всего не написание библиотек и даже не программирование как таковое. Но чтоб добится всех этих целей, программисту нужны, например, деньги, которые он зарабатывает. Как? Программированием! А программирование — это написание библиотек и/или "склеивание" их между собой. не обработка видео. Да, возможность хорошо "склеивать" библиотеки — это даже еще более важное свойство языка (есть же скрипты, которые для написания библиотек подходят плохо, а заточены исключительно на склеивание).

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

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

K>Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).

Это совершенно не важно.

>>>Поэтому все языки в одной "нише" и конкурируют друг с другом. Никто не изобретает языки, например, для разработки компиляторов, но для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего.
I>>Зайди в форум немерле
K>Чтоб увидеть, как "для конкретного языка можно разработать инструментарий для написания компиляторов, влючающий набор библиотек, дсл-ей и прочего"?

Что бы увидеть как люди изобретают языки для разработки компиляторов.

K>>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>>ну вот, "можем себе позволить" ты определил через "можем себе позволить"

K>Какие проблемы с пониманием смысла "что может себе позволить"?

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

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

K>Передача-то безвредна. Зато стек, который для этого нужен вреден. Про его переполнение слыхали? Ну так и замыкания по такой логике не вредны — вредна куча.

Куча тоже безвредна. Вредны конкретные способы использования этой кучи.

I>>Зеваю — лямбда-лифтинг в общем случае не поможет.

K>А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.

Это все общие слова, неинтересно.

K>У алгола больше авторов чем в "словах автора алгола" слов. Закавыченные слова без ссылки не интересны, реальный контрпример — наоборот — может изменить ход дискуссии.

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

I>>То есть, хаскель непригоден для решения таких задач, ЧТД.

K>Не подходит его имплементация. Вот авторы имплементаций C++ отлично понимали в чем тут разница, поэтому сейчас его имплементации для этих задач вполне подходят.

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

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

K>Вы тут противоречия не видите? Например, между "одно и то же" и "есть разница"?

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

K>В выделенном весь и юмор. Вы вводите новое понятие...
>(замыкание-и-не-замыкание-одновременно, толи-лысый-толи-с-волосами и т.д.) для того, чтоб сделать что-то частным случаем.

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

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

I>Цель у программиста как специалиста — это решение конкретных задач бизнеса. Человеческие цели не нужно рассматривать, а бизнес не ставит задачу "написать библиотеку".

А примеры "конкретных задач бизнеса", которые решает программист можно? Потому что программист вообще-то решает конкретные задачи программирования — а конкретные задачи бизнеса решают другие люди, в том числе и ставя программистам конкретные программистские задачи и организуя их решение.

K>>Но язык общего назначения — не инструмент для обработки видео. Это инструмент для написания библиотек (в том числе и для обработки видео).
I>Это совершенно не важно.

Тогда о чем мы вообще спорим?

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

K>>>>4) Выбираем самый "продвинутый" язык из тех, что можем себе позволить.
I>Есть понятные любому инженеру термины. Вот их и хочется видеть, а не продираться через твои "рекурсивные" понятия.

Ну, допустим, что вот это "любому инженеру" не понятно:

Отсекаем все языки, для которых вы не найдете программистов.

Потому, что работников не инженеры ищут.
Но тут-то какие вопросы:

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

Вот то, что остается после этих отсечений мы и можем себе позволить. А что не остается — не можем. Что тут непонятного?

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

И? Что вы выводите из этого?

I>>>Зеваю — лямбда-лифтинг в общем случае не поможет.
K>>А вы не зевайте. Статик чейн помогает в еще более частном случае, но с ним по-вашему все ок.
I>Это все общие слова, неинтересно.

ну так не сводите сами обсуждение конкретных средств к общим словам.

K>>У алгола больше авторов чем в "словах автора алгола" слов. Закавыченные слова без ссылки не интересны, реальный контрпример — наоборот — может изменить ход дискуссии.
I>Ну так найди его, этот контрпример. Или ты хочешь что бы я сам искал и примеры и контрпримеры ?

Это шутка? Я утверждал буквально следующее:

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

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

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

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

I>Текущая реализация хаскеля не пригодна для решения многих насущных задач. Ждать идеальной реализации в своем уме никто не станет

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

I>"свойства различные если по разному использовать" — то есть разница в способах использования а не в сущностях.

Ага. Теперь вы уже разделяете технику (которую мы обсуждаем) на "сущность" и технику-штрих. Т.е. сравниваем поедание и прочищение. Добавляем пустой контекст — вилку. Получаем прочищение вилкой и поедание вилкой. Раз "пустой контекст" или там "сущность" в обоих случаях одно и то же — вилка — вы делаете вывод, что поедание и прочищение или там замыкание и отсутствие замыкания — это одно и то же. Теперь ошибка в рассуждениях понятна?

K>>В выделенном весь и юмор. Вы вводите новое понятие...
>>(замыкание-и-не-замыкание-одновременно, толи-лысый-толи-с-волосами и т.д.) для того, чтоб сделать что-то частным случаем.
I>Я показываю, что одно из понятий в твоей системе лишнее и ничего не меняется, если его выбросить оттуда.

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

I>Я не ввожу понятие нуля, оно введено задолго до меня. Я его всего лишь использую.

Ага. Используете умножение на ноль для доказательства того, что 42 = 24.

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

K>А примеры "конкретных задач бизнеса", которые решает программист можно?

Например Saas

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

Разумеется, задачи это программирование. ТОлько цель и задача это разные вещи, ты их путаешь.

I>>Это совершенно не важно.

K>Тогда о чем мы вообще спорим?



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

Вообще то тебе WH внятно ответил

K>Ну, допустим, что вот это "любому инженеру" не понятно:
K>

K>Отсекаем все языки, для которых вы не найдете программистов.

K>Потому, что работников не инженеры ищут.
K>Но тут-то какие вопросы:
K>

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

K>Вот то, что остается после этих отсечений мы и можем себе позволить. А что не остается — не можем. Что тут непонятного?

Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

I>>Куча тоже безвредна. Вредны конкретные способы использования этой кучи.
K>И? Что вы выводите из этого?

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

I>>Это все общие слова, неинтересно.
K>ну так не сводите сами обсуждение конкретных средств к общим словам.

ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

K>Это шутка? Я утверждал буквально следующее:
K>

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

K>И какой тут должен быть контрпример от меня?

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

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

Все ровно наоборот.

Дальше я сделал более сильное утверждение
K>

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

Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

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

Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.

I>>Текущая реализация хаскеля не пригодна для решения многих насущных задач. Ждать идеальной реализации в своем уме никто не станет

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

Вот-вот. Как только ушли от терминов "можем себе позволить", сразу стало все предельно понятно.

I>>"свойства различные если по разному использовать" — то есть разница в способах использования а не в сущностях.

K>Ага. Теперь вы уже разделяете технику (которую мы обсуждаем) на "сущность" и технику-штрих.

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

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

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

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

I>>Я не ввожу понятие нуля, оно введено задолго до меня. Я его всего лишь использую.

K>Ага. Используете умножение на ноль для доказательства того, что 42 = 24.

Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

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

SV.>Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.

Вопрос — а нужно ли? Доля кода, описывающего предметную область в проекте, как правило, не очень велика. Реальные программы совсем не похожи на объектные модели предметной области. К тому же, для этого есть куда более удачное решение — DSL.
Основная масса кода в проекте, как правило, что-то делает, выполняет обработку данных. Для решения таких задач не нужны смешные средства моделирвоания предметной области, которые предоставляют языки вроде Java или C++. Для таких задач нужна возможность свободно комбинировать между собой простые вещи вроде итераторов или функций. Возьмем к примеру итераторы, в python или C#, не важно. Мы можем взять итератор по какой-нибудь коллекции, и сделать на его основе еще один итератор, который не просто ходит по коллекции, но еще и выполняет какую-то функцию. Мы можем скомбинировать несколько итераторов в один, функциями вроде zip или product. Мы можем получить итератор на блокирующую очередь, который будет блокировать вызывающий поток, если в очереди ничего нет. Как подобные примитивы связаны с предметной областью? Нужно ли тут что-то сложное моделировать или достаточно одной сущьности — итератор?
Можно привести в качестве примера что-нибудь еще, например асинхронные коллекции из Rx framework или futures/promises. Эти штуки тоже очень здорово умеют комбинироваться между собой, позволяя описывать очень сложные вещи, которые описываются в терминах ООП очень просто и.. бесполезно.
Мало того, ООП, оно про то, как имея набор примитивов — объектов, создать все множество необходимых поведений, правильно комбинируя эти примитивы между собой, а вовсе не про могучие таксономические иерархии, построенные на наследовании и что-то там описывающие в предметной области.

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

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

K>Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет.

Это еще почему ?

>Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.

Нет такого домена как С++

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

K>>А примеры "конкретных задач бизнеса", которые решает программист можно?
I>Например Saas

Ну и в этом случае программист тоже задачи бизнеса не решает.

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

Ну, теперь еще и цели какие-то появились.

K>>Тогда о чем мы вообще спорим?
I>

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

I>Вообще то тебе WH внятно ответил

Нет, не ответил.

I>Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

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

I>Нужно учитывать свойстваи конкретных явлений и способов их использования.

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

I>ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

Это что, "общие слова" так выглядят?

K>>Это шутка? Я утверждал буквально следующее:
K>>

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

K>>И какой тут должен быть контрпример от меня?

I>Я показал слова одного из авторов Алгола, который утверждает что стек они всего то использовали а не изобретали.

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

K>>

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

I>Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

Потому, что MIX-ассемблер изобретен позже чем алгол — что тут удивительного?

I>Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.

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

K>>Идеальных реализаций не бывает. А пригодных для решения конкретной насущной задачи будут в том смысле, что пока задачу имеющаяся реализация решать не позволяет — ее и использовать не будут. Если решатели насущной задачи, конечно, "в своем уме".
I>Вот-вот. Как только ушли от терминов "можем себе позволить", сразу стало все предельно понятно.

Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?

I>Нет, не правильно. Это у тебя понятия разделены. Я же говорю о том, что достаточно одного понятия + способы его использования. Передавать вверх, передавать вниз — это только способы. Ну да, могут быть оптимизации под конкретный способ, это нормально. Но это вилка все равно остаётся вилкой.

Еще раз: вред от того, что замыканием называются разные вещи вы и сами описали. а польза от этого обобщения какая? Вот и опять — "сущности" у них якобы одинаковые, вот только одна "сущность" позволяет ее использовать так, а другая якобы такая же — не позволяет. Так почему тогда это вилкой называть — если в одном случае грабли, а вдругом — астролябия?

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

Не правда, с ущербом, который вы сами же и описали.

I>Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

Ага, а если человек ничего не украл — он все равно вор, просто потому что так проще.

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

K>>Языком для разработки компиляторов может быть ДСЛ. А язык общего назначения нет.
I>Это еще почему ?

По определениям DSL и "язык общего назначения".

>>Но мой оппонент, похоже, не верит в то, что существуют языки общего назначения. Он считает что есть только ДСЛ-и. Но домен C++ называть по какой-то причине не хочет.
I>Нет такого домена как С++

"Домен C++" тут "домен языка C++". Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?

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

K>>>А примеры "конкретных задач бизнеса", которые решает программист можно?
I>>Например Saas

K>Ну и в этом случае программист тоже задачи бизнеса не решает.

Ну да, балду гоняет, ага.

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

K>Ну, теперь еще и цели какие-то появились.

Они всегда были По крайней мере я их уже упоминал.


I>>Это определение через само себя, то есть порочный круг. Не ясно, чем это лучше термина "пригодность".

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

Снова теория заговора какая то выходит. Реально ЯП

I>>ты ж сам начал своим лямбда-лифтингом без уточнения деталей и тд и тд и тд.

K>Это что, "общие слова" так выглядят?

Ну ты просто брякнул про лямбда лифтинг без конкретики. Я тебе ответил в том же духе.

I>>Я показал слова одного из авторов Алгола, который утверждает что стек они всего то использовали а не изобретали.

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

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

I>>Интересно, как это Кнут на своем придуманом ассеблере показывал рекурсию, если его ассеблер не умеет стека ?

K>Потому, что MIX-ассемблер изобретен позже чем алгол — что тут удивительного?

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

I>>Очень простй — я показал слова одного из авторов Алгола. Хочется увидеть нечто, которое хоть как то опровергает его слова.
K>"Слова автора алгола" опровергаются делами авторов алгола. Есть реальность данная в ощущениях и есть заковыченные слова.

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

K>Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?

Нет. Язык по прежнему не имеет смысла в отрыве от задач.

K>Еще раз: вред от того, что замыканием называются разные вещи вы и сами описали. а польза от этого обобщения какая? Вот и опять — "сущности" у них якобы одинаковые, вот только одна "сущность" позволяет ее использовать так, а другая якобы такая же — не позволяет.

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

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

K>Не правда, с ущербом, который вы сами же и описали.

Нет никакого ущерба.

I>>Если функция не захватывает ни одной переменной — это все равно замыкание, просто потому что так проще.

K>Ага, а если человек ничего не украл — он все равно вор, просто потому что так проще.

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

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

K>"Домен C++" тут "домен языка C++". Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?

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

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

K>>Вы утверждаете, что все L — DS. А D — не можете назвать. Как же так?
I>Это __враньё__.

Это чистая правда.
Вот тут

Автор: Ikemefula
Дата: 22.08.12

вы написали:

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

Это и означает, что у языка есть домен, что он не общего назначения. Дальше в той подветке вы в ответ на мои возражения о том, что "язык спокойно может быть пригоден для решения самых разных задач" все дальше разрабатываете тему всеобщей дээсэльности и доходите до того, что приводите в пример SQL — т.е. для вас все языки — DSL.

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

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

I>Следоваетельно говорить о домене в таком случае мягко говоря не получится.

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

Здравствуйте, Ikemefula, Вы писали:
K>>Ну и в этом случае программист тоже задачи бизнеса не решает.
I>Ну да, балду гоняет, ага.

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

K>>Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.
I>Снова теория заговора какая то выходит. Реально ЯП

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

I>Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола. Есть чего возразить ? Или может и рекурсию изобрели тоже а алголе ?

Рекурсия появилась в лиспе, но там для ее организации нужна была куча и сборщик мусора. А стек, как техника автоматического управления памятью для организации рекрусии без кучи и ГЦ — да, именно в алголе и появился. Что я тут уже месяц и растолковываю.

K>>Т.е. проблема была только в формулировке? И сейчас вам понятно, почему ваша модель в которой язык появляется в ответ на задачу — фантастическая?
I>Нет. Язык по прежнему не имеет смысла в отрыве от задач.

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

I>Если сущности одинаковые, то отсюда следует, что использовать можно одинаково.

О чем я и говорю. А вы утверждаете что замыкание и не замыкание — это одно и то же — "замыкание". Хотя использовать их одинаково нельзя.

K>>Не правда, с ущербом, который вы сами же и описали.
I>Нет никакого ущерба.

Есть, по вашему же собственному утверждению:

Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

Т.е. детально расписано, почему различать замыкание и не замыкание полезно, а не различать — вредно.

I>Имущество по определению не может быть пустым местом, следовательно твоя аналогия неверна.
Замыкание тоже не может — следовательно аналогия адекватна.

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

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

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

K>>>Ничем не лучше — это то же самое. Вопрос в том, как эта пригодность определяется. Вы утверждали, что под задачу выбирают язык. Я утверждаю, что до этого языки отфильтровываются по причинам со свойствами языка связанным в лучшем случае — косвенно. так что до выбора языка как такового, дело обычно вообще не доходит или число альтернатив крайне ограничено. Поэтому в большинстве случаев используют малое количество популярных языков и для самых разных задач.
I>>Снова теория заговора какая то выходит. Реально ЯП

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

I>>Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола. Есть чего возразить ? Или может и рекурсию изобрели тоже а алголе ?

K>Рекурсия появилась в лиспе, но там для ее организации нужна была куча и сборщик мусора. А стек, как техника автоматического управления памятью для организации рекрусии без кучи и ГЦ — да, именно в алголе и появился. Что я тут уже месяц и растолковываю.

Еще раз — один из авторов алгола с тобой не согласен, он утверждает что всего то заюзали стек и сделали поддержку в процессоре. Всё.
До этого стек и рекурсию организовывали ровно так же, как это делает Кнут в своем ассемблере.

I>>Нет. Язык по прежнему не имеет смысла в отрыве от задач.

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

На одну задачу конечно же никто язык обычно не пишет

I>>Если сущности одинаковые, то отсюда следует, что использовать можно одинаково.

K>О чем я и говорю. А вы утверждаете что замыкание и не замыкание — это одно и то же — "замыкание". Хотя использовать их одинаково нельзя.

Наоборот — можно. А если нельзя, то это не замыкание. Мне реально интересно, как ты ухитряешься выворачивать мои слова буквально наизнанку ?


K>Есть, по вашему же собственному утверждению:
K>

K>Для явного контроля нужно всегда четко знать, что именно ты вызываешь, какие при этом используются ресурсы, какие побочные эффекты и явно указываешь когда что должно освобождаться. Передача функий вверх очевидно ухудшает этот расклад, тк контекст будет хрен знает где. Передача функции вниз ничего не ухудшает — всегда виден локальный контекст.
K>Простой пример — замыкания в C#. В большинстве случаев, где нужен ручной контроль ресурсов нужно быть в курсе, что именно захватывается, когда освободися и освободится ли вообще. Проявляется это так — одна простая строчка а в памяти висит граф объектов в полтора гигабайта весом и занимает всё АП процесса.
K>Отсюда понятно, что задачи реалтайма, особенно жосткого, решать очень и очень тяжело, т.к. нужно бороться с основными свойствами замыканий. Многие задачи обработки данных тоже просто так не получится выполнять, замыкания придется обкладывать костылями или отказаться от них вообще.

K>Т.е. детально расписано, почему различать замыкание и не замыкание полезно, а не различать — вредно.

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

I>>Имущество по определению не может быть пустым местом, следовательно твоя аналогия неверна.
K>Замыкание тоже не может — следовательно аналогия адекватна.

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

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

K>Это чистая правда.
K>Вот тут

Автор: Ikemefula
Дата: 22.08.12

вы написали:
K>

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

K>Это и означает, что у языка есть домен, что он не общего назначения.

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

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

K>Вы не в первый раз сами себе противоречите, часто в одно посте. Но я, разумеется, спорю с теми утверждениями, которые не совпадают с моими.

Нет, тебе хочется видеть какую то особенную трактовку.

I>>Следоваетельно говорить о домене в таком случае мягко говоря не получится.

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

Это надо понимать что мне надоедает ловить тебя на передергиваниях. БОлее подробно смотри выделеный текст.

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

I>Это тебе хочется назвать это доменом.

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

I>Я специально использовал слово "задачи" да во множественном числе что бы дистанцироваться от конкретного домена.

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

Это все нас возвращает к вопросам:
Из предложения

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

следует связь: задача A -> язык A, задача B -> язык B. Но практике такого не наблюдается.
Под какие задачи проектировался C++? Под все, для решения которых он применяется? Если нет, то почему применяется и для тех, под которые он не проектировался? И почему для решения тех, под которые он проектировался, применяют и другие языки? Как получается, что фичи подбираются под задачу, а для решения одной и той же задачи применяют языки с разными фичами?

I>НАпример в С++ можно управлять ресурсами,

Это та самая вышеупомянутая задача бизнеса, надо полагать?

I>обрабатывать данные — опаньки

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

I>один язык для минимум для двух разных доменов. При этм "определенные задачи" смысла не теряет в отличие от "домен".

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

Т.е. фактически ваш тезис теперь можно без потери смысла записать

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

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

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

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

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

I>Бизнес ставит задачи. Как ты их решишь, напишешь ли библиотеку или возьмешь имеющуюся или скажем сконфигуришь готовое решение — не важно. Главное что бы требования были выполнены.

На этом уровне и никаких языков программирования нет. Они появляются на том уровне, когда важно именно "Как ты их решишь".

I>Еще раз — один из авторов алгола с тобой не согласен

Со мной не согласен Ikemefula, который автором алгола не является и который привел вырванный из контекста заковыченный текст.

I>, он утверждает что всего то заюзали стек и сделали поддержку в процессоре. Всё.
I>До этого стек и рекурсию организовывали ровно так же, как это делает Кнут в своем ассемблере.

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

Для опровержения твоей теории достаточно одной рекурсивной процедуры написаной до выхода алгола.

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

I>На одну задачу конечно же никто язык обычно не пишет

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

I>>>Если сущности одинаковые, то отсюда следует, что использовать можно одинаково.

K>>О чем я и говорю. А вы утверждаете что замыкание и не замыкание — это одно и то же — "замыкание". Хотя использовать их одинаково нельзя.

I>Наоборот — можно.

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

I>А если нельзя, то это не замыкание.

Отлично, и по этому вопросу договорились.

I>"Передача функий вверх", "Передача функий вниз" — тебе это о чем то говорит ? У меня и то и другое — замыкание. А у тебя — замыкание и незамыкание.

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

I>Для того, что бы вводить отдельное понятие нужны основания. Их нет.

Основания вводить "незамыкание" есть — вы их сами и привели.
Основания вводить "замыкание-штрих", которое равно замыкание и "незамыкание" — нет.
Оснований переименовывать "замыкание-штрих" в замыкание — тоже нет.

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

I>>Это тебе хочется назвать это доменом.

K>Ну разумеется. Это естественное стремление перейти к какой-то общеупотребимой терминологии, чтоб можно было лучше понимать о чем вообще спор.

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


K>Это все нас возвращает к вопросам:
K>Из предложения
K>

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

K>следует связь: задача A -> язык A, задача B -> язык B. Но практике такого не наблюдается.

ЗАДАЧИ домен А(....... ), Б(....... ), ... -> язык А

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