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

Какое, однако, мощное обсуждение идет.

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

Например, какие? Пометка функции как чистой, все переменные по умолчанию thread-local, если shared — опять же явно помечать? А лучше вообще без shared.

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

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

I>>>Что бы чтото понять, одних умственных усилий обычно недостаточно.
S>>Там обошлось даже без усилий

I>Заметно.
Я не пытался это скрывать

I>>>Слабовато копал.
S>>У меня в 14 были и другие заботы

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

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

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

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

S>>Кроме того, в базисе СП нет ни слова про "возвращать значения". Базис СП опирается на стейтменты, суть которых — изменять состояние программы. А возвращать стейтменты ничего не обязаны.

V>Очередное заблуждение. Основными блоками СП-программы являются процедуры и ф-ии.
Бугога

S>>>>могут быть независимы. Но императив характеризуется не независимостью веток, а наличием изменяемного состояния. Кури определения.

V>>>Сам кури. Что курить — я уже говорил. Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.
S>>То что они могут не пересекаться — это твои личные проблемы.

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

S>>Наличие изменяемого состояния в тексте программы трактуется определением как императив.

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

V>Ну да. Это всё равно что ты настойчиво просил человека откликнуться, а когда спросили — "ну чего тебе?", в ответ — "да ничего...". Завязывай с травой, кароч.
Завязывай там не знаю с чем, у тебя приходы

S>>Во-первых ты забыл оперирование полями,

V>Ну и что у тебя не так с полями?
Работа с изменяемыми полями типична для ИП

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

V>1. Очередная брехня (не натягивай свой опыт на других).
что-тот ты подставляешься. Давно императивный код не видел?

V>2. Опять и снова курить теорию автоматов. Конечные автоматы детерминированы, увы. Даже грязная императивная программа, использующая только глобальные переменные — обязательно детерминирована, будучи однопоточна, либо при гарантиях, когда к каждой уникальной глобальной переменной обращается лишь один поток (С — declspec(thread), C# — ThreadStaticAttribute, Threadlocal<T>). Собсно, бери даже ООП и COM на нём же. STA-объекты можно рассматривать как независимые детерминированные программы из-за тех самых гарантий.
Остынь. Программа не перестает быть императивной лишь от того что она детерминирована.

V>Именно поэтому я откровенно ржу с таких заяв:
V>

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

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

V>Помнишь тот мой спор с Синклером насчет const и pure-модификатора в некоторых императивных языках? Не читал? Могу дать ссылку.
Я счел его малосодержательным

S>>Если в ФП такое оперирование сильно портит жизнь, то в ИП оно является фактически нормой. Так что, к чему ты собрался применять оценку до 90% — для меня неочевидно. Может быть для << 1% случаев, когда в программе действительно отсутствует оперирование глобальными и т.п. полями?

V>Еще раз для тех, кто в танке. Я действительно уже 100 лет не видел императивной программы с изменяемыми глобальными переменными. В статическом виде принято хранить лишь однократно-инициализируемые, то бишь иммутабельные, данные. Я же вижу, что у тебя какое-то левое представление о том, как оно обычно бывает.
Твоя проблема в том что ты "принято" считаешь за истину в последней инстанции. Многие императивные программисты о твоем "принято" даже не догадываются. А некоторые даже счетчики для for используют глобальные. Добро пожаловать в реальный мир, Нео.

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

V>Ах, ты об этом. Ну дык, я думал спор о том, что фП произошел от СП давно закончился моей полной и беззаговорочной победой.
V>Вот последнее сообщение на эту тему: http://www.rsdn.ru/forum/philosophy/4940409.1

Автор: vdimas
Дата: 24.10.12

Видишь ли, LISP и APL сложно считать СП-языками, учитывая то, что они произошли до появления работы Б/Я. И в ранних версиях APL даже не было управляющих конструкций... А ML — ну тут его родство с СП ограничивается тем, что ML таки слегка по-позже появился.

V>Из популярных ФП языков 100% являются не-СП языками вроде бы всего два: это Хаскель и Эрланг. Это слишком мало, чтобы хоть как-то влиять на статистику и они оба слишком молоды в сравнении с ФП-парадигмой, чтобы рассуждения о происхождении ФП на их примере не были бы слишком смешными. Смирись. ФП уже де-факто произошло от СП. Всё уже случилось и ты не переиграешь произошедшего. )))
Ну тогда назови хотя бы 100% СП языки, хоть буду знать, от чего ФП произошло )))

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

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

S>>Не говоря о том, что для типичных ИП программ ни твоя ни моя редакции этого тезиса не справедливы.

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

S>>Обсуждать ИП, усиленное требованием отсутствия влияний состояний, мне что-то не хочется.

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

S>>>>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.
V>>>Никоим образом не устремляюсь. В сниппетах показал — почему.
S>>И что же в них недетерминировано?

V>В них никакого ФП, но сплошная мутабельность. Причем, я показал вырожденные примеры. Эту мутабельность можно смело выносить за рамки методов, если сами методы снабдить модификаторами pure как в языке D или как я предлагал аналогичный модификатор clean для C++. Будет тоже самое, что в сниппетах — отсутствие скрытого влияния состояний друг на друга. Что и требовалось.
Походу ты опять не прочитал вопрос и ответил на какую-то фантазию.

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

I>>>>Слабовато копал.
S>>>У меня в 14 были и другие заботы

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

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

Ну хорошо, ты победил

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

ARK>Какое, однако, мощное обсуждение идет.
Ну дак тема-то эпическая!
ARK>Например, какие? Пометка функции как чистой, все переменные по умолчанию thread-local, если shared — опять же явно помечать? А лучше вообще без shared.
Ну, я не эксперт в оптимизирующих компиляторах, но в целом мне кажется, что экстремальные ограничения должны себя показать. Т.е. все функции — чистые; все передачи состояния — явные (то есть именно World PrintLn(World oldWorld, string line)); никакого shared.

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

S>Ну, я не эксперт в оптимизирующих компиляторах, но в целом мне кажется, что экстремальные ограничения должны себя показать. Т.е. все функции — чистые; все передачи состояния — явные (то есть именно World PrintLn(World oldWorld, string line)); никакого shared.

Да, целиком согласен. Пришел к таким же выводам. Предлагаю еще память copy-on-write (концептуально, оптимизации могут частные случаи свести к указателям).

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

V>>Для Схемы не может. Целое число там не ограничено.
S>Омг, омг. Это, конечно же, полностью перечёркивает мой аргумент.

Вообще, да. Как и любой другой слишком частный случай.

V>>В любом случае, если компилятор может делать какие-то частичные вычисления (путь даже вычислит первые 12 значений для Схемы), это никак не служит док-вом или даже иллюстрацией к общему случаю, когда компилятор таких вещей делать не может. А мне во всех этих рассуждениях любопытен именно второй вариант, ес-но.
S>Ну так речь как раз о том, где кончаются способности компилятора в общем случае. Императивный компилятор в общем случае вообще не может применять никаких оптимизаций — потому что хрен его знает, зачем программист так написал. Может, там другой поток крутится, который должен иногда наблюдать ровно вот такое изменение состояния, которое кажется бессмысленным. Современные императивные языки предлагают конвенции по управлению этим процессом — скажем, считается, что в локальном коде нет неявных зависимостей, пока я не указал volatile.

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


S>Но это — всего лишь локальный код. Как только мы выходим за пределы локального кода, начинаются туман и драконы.
S>Да, в исследования этого тумана вкачаны огромные средства — что и позволяет вам наблюдать эффекты оптимизации в императивных языках. Решаются некоторые частные проблемы.
S>Однако, скажем, мне неизвестен компилятор С++, способный превратить OutFirstNFib в O(n) алгорим автоматически:
S>

S>void OutFirstNFib(uint N)
S>{
S>  for(uint i=1; i<=N; i++)
S>    std:cout << Fib(N);
S>}


S>uint Fib(uint n)
S>{
S>   return n < 3? 1 : Fib(n-1) + Fib(n-2);
S>}
S>

А я не знаю ни одного ФП языка, который превратил бы эквивалентный исходный код в O(n).
А если изменишь семантику, то обратное портирование на императив породит совсем другой код.


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

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

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

Есть еще вариант — это строгие активные объекты. То бишь, чтобы в языке вообще не было возможности создать гонки. В этом плане стоит посмотреть на SmallTalk или Сингулярити с её Exchange Heap. Вот тебе системы, в которых гонки невозможны by design, хотя такие системы всё еще по-уши императивны.

Мы же получим классический клеточный атомат (только с более сложным поведением клеток, чем принято считать сегодня для клеточного автомата). А добавить детерминированности можно опять же через некие ограничения. Скажем, запретить изменять однажды созданные связи автоматов. То бишь, объектные связи должны быть инициализируемы однократно. В этом случае такой ООП-паттерн как "Стратегия" должен будет реализоваться не через перезапись ссылки на объект, реализующий текущую стратегию, а как мультиплексор по известным на этапе компиляции экземплярам объектов-автоматов. Это всё развяжет руки компилятору для любых произвольных анализов, т.к. даст ему все допустимые на этапе исполнения зависимости. Для реализации подобного потребуется на уровне языка отличать типы-данные от типов-объектов. (Т.е. предлагается иерархичная система типов, как минимум с 2-мя т.н. capability)

Дело за малым — поддержка в компиляторах с текстовых ЯВУ. ))
Или же есть специальные императивные графические языки, которые заведомо избавляют конечный бинарный образ от всех обсуждаемых ужасов императива: http://ru.wikipedia.org/wiki/SFC


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

Боюсь, это опять начались точно такие же умозрительные спекуляции, как и обычно. Реально возможности суперкомпиляции ФП-кода очень бедны, т.к. система типов служит ограничителем, который не переплюнуть на этапе подразумеваемой тобой бета-редукции. Жиденько это всё... Т.е. что касается трансформации кода, то гораздо большую свободу трансформаций можно получить уже на регистровом уровне (даже на виртуальных регистрах). Как только убираешь типы, то эффективность суперкомпиляции возрастает многократно, потому что система типов уже не мешает распознавать "похожие" на регистровом уровне вычисления и делать более агрессивные предвычисления, коль эти предвычисленные значения могут пригодиться в большем кол-ве мест.

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

S>Вопросы о том, увидим ли мы прорыв в области ФП до нашей смерти, существенно зависят от банального финансирования.

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

Под ФП разрабатывают специальные вычислители (data-flow), но и они суть компроммис. Например, такой вычислительно не способен понять, где можно делать спекулятивные вычисления, а где нельзя, ведь на уровне простейших операций не видно, сопровождается ли данная операция побочным эффектом или нет. Ведь побочный эффект — это умозрительная штука только для абстракций программиста, процессору-то до фени.

Я бы использовал ФП-подобные языки сугубо как язык описания асинхронных автоматов, тут их якобы "декларативность" (в исходном его толковании) будет к месту.

Просто область асинхронных автоматов очень сложна, и мейнстримовая электроника её старательно шугается... Это что-то вроде Хаскеля в программировании, только еще в 10 раз сложнее. Но потенциально выжимает бОльшую вычислительную мощь с каждого вентиля, т.к. способна работать без "холостых" временных участков, которые есть в тактах синхронных автоматов и которые (уууупс!!!!), очень недетерминированы, на самом-то деле... Бо длительность такта выбирается из предположения, что переходные процессы будут успевать завершаться к началу следующего такта... но это ни разу не гарантировано. Зато этот момент гарантирован в асинхронных автоматах (асинхронный это тот, все состояния которого устойчивы).

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

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

Ага, зачем мне кеды, если я не курю?

Повтор для тех кто в танке:
V>>>>Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.
S>>>То что они могут не пересекаться — это твои личные проблемы.
V>>Смысл вообще спорить, если ты даже не вдумываешься, что тебе пишут?

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

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

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

V>Ага, зачем мне кеды, если я не курю?

Не куришь, а других заставляешь. И кеды не тебе.

V>Повтор для тех кто в танке:
Вылазь уже из танка

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


I>>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.

DG>начинай сразу с объяснения машины тьюринга — там концепций еще меньше..

DG>ps
DG>Если серьезно — то необходимо не минимальное кол-во концепций, а возможность за минимальное кол-во усилий решить реальную задачу стоящую перед пользователем. На основе лишь концепций массив, переменная, if и goto — это сделать очень и очень непросто.

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

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

V>>Если честно, забодал подменой темы обсуждения. Речь была о упорядочивании вычислений, а не о чистоте. 99% ф-ий в современном императиве тоже чисты и что с того? Императива не существет?
A>Если бы в качестве предиката было (x>1), то во втором примере возникла бы упорядоченность вычислений?

Вот тут: http://www.rsdn.ru/forum/philosophy/4931862.1

Автор: vdimas
Дата: 17.10.12

В предпоследнем абзаце.

Отбросив слова-сорняки:

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

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

I>>А что насчет циклов for?
I>> 1.Переменные
I>> 2.Массивы
I>> 3.Оператор if
I>> 4.Команды перехода (goto или jump)
I>>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.
LVV>Можно без массивов, операторов if и goto...

LVV>

LVV>повторять 10 раз
LVV> что-то делаем

вово

10.times do 
  something
end

гораздо проще циклов for.

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

Z>вово
Z>

Z>10.times do 
Z>  something
Z>end
Z>

Z>гораздо проще циклов for.

Чем проще ? Кому проще ? Если кому то проще, то кому то и сложнее. Кому сложнее ?
Мне вот понятее так, как в естественном языке:
{ something } repeat { 10 times }
{ something } repeat { each morning } until { symptoms disappear }
{ something } repeat when { pain returns }