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

B>По моему Sinclair немного перепутал, речь идет о Coemga, это новый диалект C#, который уже сегодня можно опробывать, компилятор все успешно компилирует без изменений в IL

по-моему он всё правильно говорит, вот тут почитай — http://msdn.microsoft.com/msdnmag/issues/04/05/c20/ — чётко сказано: C# 2.0

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

G>Здравствуйте, Gaperton, Вы писали:
G>>Ага. "Если бы это была вещь стоящая, она за границей давно уже распространена была бы. Значит ты, дружок, ерунду придумал". Я понял принцип. Что удобно, думать не надо. Совсем. Вот, например, что я придумал, и хочу своей гениальной мыслью поделиться:
G>Думать как раз надо — а то потом придется всем вокруг и самому себе доказывать удобство и страшную экономическую выгоду ФЯ
Приятно наверно считать себя умнее, а других глупее, не разбираясь при этом в предмете разговора. Но никого кроме себя ты не обманешь, потому как есть одна неувязочка, которую сложно скрыть. Ты понятия не имеешь что такое ФЯ, а в разговоре поучавствовать хочется. Именно поэтому, за отсутствием возможности поговорить о ФЯ предметно, ты переводишь разговор на МС. В общем, оставляю тебя дальше рассуждать об МС, слонах и китах капитализма, и кто кого победит. Вышепомянутые слоны идут в пеший тур в Таиланд. Надоело.

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

S>Здравствуйте, Silver_s, Вы писали:
S_>> Увидит там компилятор бесконечный цикл заполняющий ArrayList, посмотрит а нахрена он вобще нужен? Наружу модуля не выдается, пускай выкидывает его и все использования собирает в один цикл нужной длины.
S> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.
Сомнительно. Если этот yield будет иметь ленивую семантику, это будет означать неопределенный порядок вычислений. Что не является граблями только в случае, если программа состоит из чистых функций (если побочные эффекты отсутствуют). Вот собственно и все — ленивые вычисления безопасны только при отсутствии побочных эффектов, а это и есть основная отличительная характеристика ФЯ.

Здравствуйте, Gaperton, Вы писали:
S>> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.
G>Сомнительно. Если этот yield будет иметь ленивую семантику, это будет означать неопределенный порядок вычислений. Что не является граблями только в случае, если программа состоит из чистых функций (если побочные эффекты отсутствуют). Вот собственно и все — ленивые вычисления безопасны только при отсутствии побочных эффектов, а это и есть основная отличительная характеристика ФЯ.
Ну, я так понял, что нифига там ленивые вычисления не безопасны. Надо самому следить за порядком вычислений, либо за отсутствием побочных эффектов у yield. Yield всего лишь облегчает реализацию итераторов, которые и в императивном случае вполне ленивы.
Никто мне не мешает и на C# 1.0 написать итератор, который возвращает числа Фибоначчи. Вместе с классом Fibonacci :IEnumerable, который этот итератор возвращает.
А также написать алгоритм, который получает на вход IEnumerable и проверяет, больше ли сумма ряда предопределенной константы. yield просто делает код короче.
Конечно, честные функции высшего порядка мы так не получим.

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

S>Здравствуйте, Gaperton, Вы писали:
S>>> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.
G>>Сомнительно. Если этот yield будет иметь ленивую семантику, это будет означать неопределенный порядок вычислений. Что не является граблями только в случае, если программа состоит из чистых функций (если побочные эффекты отсутствуют). Вот собственно и все — ленивые вычисления безопасны только при отсутствии побочных эффектов, а это и есть основная отличительная характеристика ФЯ.
S>Ну, я так понял, что нифига там ленивые вычисления не безопасны. Надо самому следить за порядком вычислений, либо за отсутствием побочных эффектов у yield. Yield всего лишь облегчает реализацию итераторов, которые и в императивном случае вполне ленивы.

Т.е. ничего практически строгого не получается и весь груз ответственности ложится на программера, а не на компайлер?
Что-то как-то такое решение мне не кажется особо хорошим...

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


К>>>Т.е. для каждой такой заплатки ждём новую версию? Тебе нравится такое решение подобных проблем?

ПЛ>>Это смотря как посмотреть, для ИЯ это скорее "расширение". Ты ведь не станешь утверждать, что ИЯ — это недоделанный ФЯ?

К>Да нет разницы как это ты назовёшь, сути-то не меняет:

Слово за слово, глядишь а бабушка уже совсем не бабушка, а дедушка. Заплатки характерны для разработки "сверху-вниз", ИЯ исконно идет снизу-вверх.

К>есть дыры и их решают или "заплатками" или "расширениями", т.е. переделкой/доделкой изначальной функциональности

Дык Haskell или Erlang, если я не ошибаюсь, тоже не с неба свалился. Тут есть один момент. Ценность теории, модели, разработки тем больше, чем больше точек зрения рассматривалось при создании и тем они более объемны нежели плоски. Сколько человек участвовало в разрабтки Erlang?

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

S>Здравствуйте, Gaperton, Вы писали:
S>>> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.
G>>Сомнительно. Если этот yield будет иметь ленивую семантику, это будет означать неопределенный порядок вычислений. Что не является граблями только в случае, если программа состоит из чистых функций (если побочные эффекты отсутствуют). Вот собственно и все — ленивые вычисления безопасны только при отсутствии побочных эффектов, а это и есть основная отличительная характеристика ФЯ.
S>Ну, я так понял, что нифига там ленивые вычисления не безопасны. Надо самому следить за порядком вычислений, либо за отсутствием побочных эффектов у yield.
Я тоже понял именно так. Грабли это серьезные, имхо, хоть и действительно кажется заманчивой идеей. Тяжело писать на С# в функциональном стиле, и еще тяжелее доказать безопасность побочных эффектов. А уж гарантировать ее в затяжной разработке — будет вообще кошмар. Кто-то сделает безобидное изменение, а трое других будут неделю искать возникший глюк.

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

А так — вовсе они не ленивы.

S>Никто мне не мешает и на C# 1.0 написать итератор, который возвращает числа Фибоначчи. Вместе с классом Fibonacci :IEnumerable, который этот итератор возвращает.
Ну, в общем случае — да. Никто не мешает так писать, и это в целом хороший стиль.

S>А также написать алгоритм, который получает на вход IEnumerable и проверяет, больше ли сумма ряда предопределенной константы. yield просто делает код короче.
Возможно.

S>Конечно, честные функции высшего порядка мы так не получим.
Nemerle. Получите, если захотите взять

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

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

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

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

S>>>Yield всего лишь облегчает реализацию итераторов, которые и в императивном случае вполне ленивы.
G>>Итераторы были-бы ленивыми, если бы значение элемента контейнера вычислялось в момент доступа к нему по итератору, т. е. было отложенным до момента чтения.
S>Это так и есть. Не очень понимаю, зачем итератору вычислять элементы в какой-то другой момент.
Не совсем так. Допустим, у тебя одна функция заполняет вектор значений, нетривиально вычисляя каждое значение.

И вот ты хочешь пробежаться по нему итератором. В "ленивой" реализации у тебя по крайней мере "ленивые" конструкторы элементов массива, так что элементы не будут на самом деле вычислены, пока ты не обратишься к ним через итератор. Вычисление будет отложено до момента чтения, который может вообще не случиться. Понимаешь разницу? Это позволяет тебе определять бесконечные (или ну очень большие) структуры данных, например.

В строгой реализации все элементы контейнера будут вычислены сразу, а итератор — ну это просто итератор. Он никакой, ни ленивый, ни строгий. Это просто акцессор, интерфейс, способ доступа. А вот контейнер — строгий.

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

S>Здравствуйте, Silver_s, Вы писали:
S_>> Увидит там компилятор бесконечный цикл заполняющий ArrayList, посмотрит а нахрена он вобще нужен? Наружу модуля не выдается, пускай выкидывает его и все использования собирает в один цикл нужной длины.
S> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.

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

Здравствуйте, Павел Леонов, Вы писали:

Опечатался.

ПЛ>Не, они просто хотели выделить еще одно свойство типов, про себя я ее назвал "связность". По типу доступа она либо последовательная, либо произвольная (индексированная). Они видимо решили, поскольку произвольную легче сделать и при определенной природе индекса индексированную можно привести к последовательной, то взялись за нее и ввели индексаторы. А теперь вот и до последовательной дошло.

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

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

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

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

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

S>>>>Yield всего лишь облегчает реализацию итераторов, которые и в императивном случае вполне ленивы.
G>>>Итераторы были-бы ленивыми, если бы значение элемента контейнера вычислялось в момент доступа к нему по итератору, т. е. было отложенным до момента чтения.
S>>Это так и есть. Не очень понимаю, зачем итератору вычислять элементы в какой-то другой момент.
G>Не совсем так. Допустим, у тебя одна функция заполняет вектор значений, нетривиально вычисляя каждое значение.

Хотя, чтобы добиться такого же эффекта, ты на самом деле можешь фактически обойтись без контейнера, но заставить объект выглядеть снаружи как контейнер. Согласен, в этом смысле итераторы "ленивые".

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

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

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

S>>>>>Yield всего лишь облегчает реализацию итераторов, которые и в императивном случае вполне ленивы.
G>>>>Итераторы были-бы ленивыми, если бы значение элемента контейнера вычислялось в момент доступа к нему по итератору, т. е. было отложенным до момента чтения.
S>>>Это так и есть. Не очень понимаю, зачем итератору вычислять элементы в какой-то другой момент.
G>>Не совсем так. Допустим, у тебя одна функция заполняет вектор значений, нетривиально вычисляя каждое значение.

G>Хотя, чтобы добиться такого же эффекта, ты на самом деле можешь фактически обойтись без контейнера, но заставить объект выглядеть снаружи как контейнер. Согласен, в этом смысле итераторы "ленивые".

Хм, но в этом случае ты не получишь автоматического кэширования результатов (что ты имеешь бесплатно с ленивыми типами данных), это придеться делать руками. В общем, сделать "ленивый" контейнер на C# можно, но надо смотреть в оба. Как бы потом не получилось в духе "я тебя породил, я тебя и убью".

From: Glоbus
>Он не как-нибудь — он связан так же плотно как и с маркетингом, как и с их юзабилити и т.п. Блин, товарищ, ну ты ваще как не от мира сего! Откуда беруться ворд эксел и мс скл сервер? Программеры их пишут. На чем оин их пишут? Уж не на хаскеле точно.

Hejlsberg: Parts of Word, internally, use a p-code engine because it's more compact.
http://windows.oreilly.com/news/hejlsberg_0800.html

Наверняка это не p-code языка C++.

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

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

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

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

Хочешь узнать истинную причину отсутствия аргументов? Мне просто не интересно с тобой трепаться. Се ля ви.

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

S>Здравствуйте, Gaperton, Вы писали:
G>>Да... Тут еще про ядерный реактор пример приводили, типа конечный автомат на ФЯ невозможно сделать. Называется, не бросайте меня в терновый куст. Так вот, мне лично было бы спокойнее, если бы управляющая программа этого реактора целиком была написана на ФЯ, и корректность ключевых модулей была-бы доказана . Я уже насмотрелся на прелести программирования "с помощью эффекта" за последние 10 лет, достало. А как вам — не знаю.
S>Я просто к тому, что написано в статье. В статье написано, как сделать кусок игровой программы. Не спорю, самый сложный и интересный кусок. По крайней мере, для шахматно-шашечного типа. Однако из отсутствия остальных частей программы складывается именно такое впечатление — если программа выходит за рамки stdin и stdout, то пишите ее на IL и встраивайте вызов функций, определенных на FL.
Сам по себе ввод-вывод по природе своей императивен — там важна последовательность операций. Не стоит ждать от ФЯ чего-нибудь волшебного и волнующего, читая данные из файла. Максимум — будет необычно .

In this example, a Haskell program copies one file to another:

main = do fromHandle <- getAndOpenFile "Copy from: " ReadMode
          toHandle   <- getAndOpenFile "Copy to: " WriteMode 
          contents   <- hGetContents fromHandle
          hPutStr toHandle contents
          hClose toHandle
          putStr "Done."

getAndOpenFile          :: String -> IOMode -> IO Handle

getAndOpenFile prompt mode =
    do putStr prompt
       name <- getLine
       catch (openFile name mode)
             (\_ -> do putStrLn ("Cannot open "++ name ++ "\n")
                       getAndOpenFile prompt mode)

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

[skipped]

Другой новый вид клея, который используют функциональные языки, допускает склеивать целые программы. Напомним, что функциональная программа — просто функция из входных данных в её выходные данные. Если F и G — такие программы, то (G . F) — программа которая, вычисляет G (F input). Программа F вычисляет свой вывод, который используется как ввод, для программы G. Традиционно,это можно осуществить, сохраняя вывод F во временный файл. Проблема состоит в том, что временный файл может занять так много памяти, что непрактично склеивать программы подобным образом.

Это конечно не совсем по-существу вопроса, более шутка, но все же...

"Традиционно,это можно осуществить, сохраняя вывод F во временный файл", в смысле:
Modul1.Out >> TempFile(Googol Mb) >> Modul2.In
А каким эзотерическим способом (на обыкновенном процессоре и памяти) данные попадают из G в F в Фя?
G — это кусок маш. кода, и F тоже. Через какой астрал кусок кода F получает (Googol Mb) из G, как это нельзя сделать "традиционно"?

Сказка ложь, да в ней намек...

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

B>Кстати, может быть народу будет интересно глянуть уже сейчас на предполагаемый C# 3.0:
B>Comega project

Сдается мен, что этот ресерч вряд ли в таком виде сможет стать третьей версией Шарпа.

B>Там кстати и стрим в роли возвращаемого значения функции применяется и ассинхронное выполнение методов, короче очень много элементов функциональных языков:

B>

B>  virtual string* Foo(){
B>    yield return "Hello world1";
B>    yield return "Hello world2";
B>    yield return "Hello world3";  }
B>

Откровенно говоря использование синтаскиса указателя для таких целей просто маразм. Да и зачем нужны все эти извраты когда во второй версии Шарпа уже есть итераторы выплняющие такую же функцию. Вот код из того же R#-а:

        /// <summary>
        /// Возвращает энумератор позволяющий перебрать элементы коллеции 
        /// в обратном порядке.
        /// </summary>
        public IEnumerator<T> GetReverseEnumerator()
        {
            for (int i = _len - 1; i >= 0; i--)
                yield return _ary[i];
        }

Чем эти "стримы" будут отличаться от энумераторов я лично не понимаю.

B>возвращаемое значение накапливается в выходном стриме, string* как раз и представляет собой этот стрим, судя по всему это будет комбинироваться с асинхронными вызовами, которые будут получая часть возвращаемого значения на время принимать управдения на себя и при окончании данных передавать управление снова в Foo. А вот и ассинхронные методы:


B>

B>public class Buffer {
B>   public async Put(string s);
B>   public string Get() & Put(string s) { return s; }
B>} 
B>

Опять таки. Сто лет как есть ассинхнонные делекаты.

B>Вобщем интересные штуки, классная интеграция с XML, спорная немного интеграция с SQL, и так далее.

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

B> Последнее время на лицо просто повальное привлечение функциональных средств в императивные языки,

Что-то не очень заметно.

B> те же самые атрибуты,

И с каких это пор атрибуты стали относиться к функциональным языкам?

B> дженерики с темплейтами,

Дженерики тоже к функциональным языкам отношения не имеют. Что-то ты уж больно много приписываешь ФЯ.

B> аспекты тоже рассматриваются как накладываемые функциональные блоки,

Ерунда какая-то. Причем тут ФЯ? Аспекты и АОП — это отдельная концепция. Может она и реализуема на ФЯ, но уж точно никаких заслуг ФЯ в АОП нет.

B> происходит обогащение декларативными средствами.

Здорово! Т.е. декларативные средства == ФЯ?! Ну, тогда записывай R# в ФЯ, хотя в нем не ФЯ и намека нет.

B> Да и в традиционном программинге в той же бизнес логике идеи FL проникают и туда, вот к примеру рассмотрим эту схему:

B>BusinessEntities.ppt

B>Если почитать спецификацию Business Entities модуля, то наиболее распространенное и рекомендуемое представление этого модуля это DataSet, и посмотрим на обмен стримами между функциональными блоками программы написанной на FL!

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

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


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

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

ЗЫ

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

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

К>Ага, а если потом ещё что-нибудь подобное обнаружится, надо будет думать что ни 1.0 ни 2.0 не было, а только 3.0

Ну, вот нет линивых вычислений в половине ФЯ. Но ты же первый упоро причисляешь их к фичам ФЯ в целом. Так что если в МЛ их нет, то Хаскель это встоено как поганая надстройка и все ФЯ вместе с Хаскелем никуда из-за этого не годны?