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

VD>Дык выигрыша в продуктивности (программистов) я и так добьюсь во многих областях (особенно в бизнес-софте) взяв вместо С++ тот же C#. С++ язык довольно сложный и низкоуровенвый...

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

Например на C#: Есть у нас некоторый алгоритм со сложными вычислениями, выдает множество данных. Дальше еще 2 алгоритма данные обрабатывают. Хороший прием изоляции алгоритмов это векторизовать — один алгоритм считает и выдает ArrayList, другие два по очереди пробегаются по нему делают свое дело, затем этот ArrayList выбрасывается за ненадобностью.

Вот при этом начнет голова пухнуть когда будешь думать об оптимизации.
1) Можно промежуточные данные в ArrayList не сохранять, тогда все в одном месте считать — и все будет жутко криво.
2) Если же его использовать то получишь боксинг на численных типах, и затраты памяти на большом количестве данных (не известно хватит ли памяти вобще).
3) Сделать функцию вычисления произвольного элемента данных (виртуальный ArrayList). Получим жуткие тормоза при произвольном доступе — если природа итеративна и есть стартап код перед итерациями.
4) Сделать callback через делегат в цикле вычисления, либо итератор. Тогда прийдется писать специальный итератор который вперед забегает и буферизует 3 рассчитаных значения если понадобится кроме текущего элемента иметь доступ к предыдущему и следующему (не пересчитывать же одно и тоже по 3 раза). И при втором проходе прийдется снова все заново пересчитывать. А вот хочется мне в несколько проходов использовать — алгоритм упростится.

И какое отношение имеют к решаемой задаче эти вопросы. Никакого. И где тут высокий уровень?
Этим должен оптимизатор заниматься. Вобще то синтаксису ИЯ такая оптимизация не противоречит.
Увидит там компилятор бесконечный цикл заполняющий ArrayList, посмотрит а нахрена он вобще нужен? Наружу модуля не выдается, пускай выкидывает его и все использования собирает в один цикл нужной длины.

S>Итого: FP подходит только для небольших частей современных программ. Пока что не видно возможности построения языка общего назначения на основе FP.
Так таки и не видно? Если уж ты начал говорить о языках без побочных эффектов (а большинство ФЯ их допускают), то Haskell и Clean — языки общего назначения, хотя там нет ничего кроме чистых функций. При этом Clean-овский IDE целиком написан на Clean, а он, при всей своей простоте, будет посложнее нотепада .

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

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

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

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

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

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

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

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

F>>Я же говорю, в статье есть пример, очень простой, правда. Producer-у не нужно знать, когда прекращать producing данных. Соотвественну, consumer-у не нужно ничего знать о producer-е. В качестве средства коммуникации между ними служит (потенциально) бесконечный список (иногда его называют stream). Откуда он взялся, consumer-у все равно, он возьмет из него только то, что нужно. Producer-у это списка тоже неинтересно, сколько данных генерировать и когда останавливаться.

VD>Ну, и чем это ушучшает модульность по сравнению с тем же энумератором, стримом, системой передачи сообщений и т.п.?

F>>Если я не ошибаюсь, в Unix подобным образом работает кострукция program1 | program2.

VD>А в виндовс program1 > program2 и что?

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

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

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

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

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

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

Вобщем интересные штуки, классная интеграция с XML, спорная немного интеграция с SQL, и так далее. Последнее время на лицо просто повальное привлечение функциональных средств в императивные языки, те же самые атрибуты, дженерики с темплейтами, аспекты тоже рассматриваются как накладываемые функциональные блоки, происходит обогащение декларативными средствами. Да и в традиционном программинге в той же бизнес логике идеи FL проникают и туда, вот к примеру рассмотрим эту схему:

BusinessEntities.ppt

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

Теперь что касается мотивации по применению FL, опять же на мой взгляд. Если рассмотреть наше современное программирование, то чем постоянно занимается программист, это адаптацией структур данных из одного вида данных в другой, к примеру адаптация из данных в RDB в обьект нашего приложения, из обьекта приложения в визуальный интерфейс который описывает этот же обьект в терминах UI элементов, то есть речь идет об адаптации под любой вид ввода-вывода. Доколе будет делаться все это руками, вот мой вопрос. Ну разве не достаточно было бы описать структурно функциональную модель нашего персона, где было бы определено что поле name является одним из значений, представленных в реестре имен государства, и спроецировать ( проинтерпретировать ) эту функциональную модель на DB, понятно каким образом и с какими связями, или к примеру на UI, где понятное дело что поле Person.name исходя из функциональной модели представлено комбиком со списком всех имен с выбранным именем нашего персон. Программист же, вместо того что бы описать это единожды на уровне структуры данных своего персон переносит в ручную эти функциональные особенности своей структуры во все части приложения, в WinForms, в SQL Server, в HTML+java script, в XML, в Report, и так далее. И мало того, при разработке обьектной модели программист еще постоянно определяет новый протокол общения между модулями и обьектами своей программы, получается что его обьекты просто не совместимы своими интерфейсами с обьектами другого программиста из другого отдела или фирмы, хотя функционально эти модули могут быть вполне дополняющими друг друга, в функциональном подходе такого не может быть, протокол общения между функциональными единицами определен изначально, для того что бы одну функцию насадить на другую не нужно имплементировать какие то дивные интерфейсы с кучей абстрактных методов, из которых только может один метод тебя и интересует, тут кто то проводил аналогию с программами в Unix shell, для императивных языков такая совместимость невозможна. И потом, если мы говорим о продвинутых средствах моделирования (программирования ) сложных систем, то все упирается в средства визуального проектирования, и если представить графически кубиком на экране какой то функциональный блок я еще могу, то как представить на экране класс, который имеет свой протокол общения с окружающим миром, а может и несколько таких протоколов, и как научить наши средства визуального программирования распознавать эти протоколы для того что бы создавать программу декларативно, кубиками и стрелочками, настраивая конечную функциональность.

Здравствуйте, Курилка, Вы писали:
S>> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.

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

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

S>Здравствуйте, Курилка, Вы писали:
S>>> Там вроде бы yield придумали в версии 2. Специально для ленивых циклов.

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

А Silver_s тебе не проблему описал чтоли?
yield не является её заплаткой? Т.е. фичей, которая решает проблему (с т. зр. программиста, не пользователя, естественно) в пред. версии фреймворка?

Здравствуйте, Курилка, Вы писали:
К>А Silver_s тебе не проблему описал чтоли?
А-а, ну описал.
К>yield не является её заплаткой?
Нет. yield является развитием языка.
К>Т.е. фичей, которая решает проблему (с т. зр. программиста, не пользователя, естественно) в пред. версии фреймворка?
Не фреймворка, а языка. Не надо все в кучу валить.

Вообще, при таком подходе, темплейты С++ являются заплаткой в третьей версии плюсов, которые решают некоторые проблемы предыдущей версии языка. А Windows NT являются заплаткой, решающей проблемы доса. Нехреновая такая заплаточка.

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

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

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

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

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

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

S>Здравствуйте, Курилка, Вы писали:
К>>А Silver_s тебе не проблему описал чтоли?
S>А-а, ну описал.
К>>yield не является её заплаткой?
S>Нет. yield является развитием языка.
К>>Т.е. фичей, которая решает проблему (с т. зр. программиста, не пользователя, естественно) в пред. версии фреймворка?
S>Не фреймворка, а языка. Не надо все в кучу валить.

S>Вообще, при таком подходе, темплейты С++ являются заплаткой в третьей версии плюсов, которые решают некоторые проблемы предыдущей версии языка. А Windows NT являются заплаткой, решающей проблемы доса. Нехреновая такая заплаточка.

Ну тогда получаем, что при возникновениии проблемы переделываем нафиг язык чтоли? (Ну не совсем нафиг, но переделываем точно)
А кстати как с этим самым yield у васика? Если нету его, то как там это решается? И как соотносится с самим фреймворком (т.е. с реализацией в IL)?
Просто ключ. вопрос был в том, что в ФЯ это изначально предусмотрено и ни языка ни рантайма переделывать НЕ НАДО.

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



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

Думать как раз надо — а то потом придется всем вокруг и самому себе доказывать удобство и страшную экономическую выгоду ФЯ

G>А почему МС не использует CVS? А почему МС не юзает Java? А почему у МС серваки не под Линухом, раз ваш линух такой крутой?? А??? Ацтой ваш линух патамучта. А что это МС не испозьзует ИБМ-овские мэйнфреймы? Сейчас, соберусь с мыслями, и пойду в форумы Java и Unix.

А кто сказал что МС на юзает юникс ))) Может у них там серваки все под *никсами стоят ))) Кстати первой ос которую они разрабатывали была unix-based операционка.

G>И что прикольно, стоит МС (гипотетически) перевести разработку на ФЯ, и вообще, изменить курс как Биллу за обедом по приколу в голову взбредет, так придется говорить то же самое, но с противоположным знаком. Придется, эта, быть в курсе!

ДА пусть переводят хоть на пролог — я не на них смотрю а на то что продаваемо. По факту — на рынке программеров программист С++ ценится и востребован выше чем программер на хаскеле. Все. Программить для души на ФЯ никто не запрещает — но кормиться-то надо...И лично я, не будучи идеалистом, не поверю что все мы тут затуманены чарами пиар-отдела МС, который вкидывает бабло в С++. Рынок рано или поздно все расставит на свои метса. Вот и хаскель он поставил — в угол и на колени. Ну не продаваемый он — почему? — хрен его — может потому что реально неэффективно на нем работать. Я других причин не вижу. Все ведь в бабки упирается

G>Удивительно, а вы правда считаете, что успех продуктов микрософта как-нибудь связан с языками программирования, на которых они созданы?

Он не как-нибудь — он связан так же плотно как и с маркетингом, как и с их юзабилити и т.п. Блин, товарищ, ну ты ваще как не от мира сего! Откуда беруться ворд эксел и мс скл сервер? Программеры их пишут. На чем оин их пишут? Уж не на хаскеле точно. Все подчинено выгоде — я уже затрахался это повторять . Ты ж пойми — МС — это в первую очередь менеджмент. Грамотный менеджмент решает все. Какими бы гениальными не были программеры без организации их кпд стремиться к нулю. И в свою очередь даже с привлечением посредственностей можно добиться успеха, если их правильно организовать. Менеджерам в МС крупно посрать на всякие там сильные/слабые стороны языков и тонкости с ними связаные. Люди мыслят такими категориями: надо выпустить продукт. Для этого надо набрать программеров. Каких программеров? Которых много — то есть из которых есть что выбрать. Исторически сложилось что это программеры на плюсах. Технический консультант скажет им, можно ли на плюсах в приемлисмые сроки выпустить нужный продукт. Если бы он сказал что нельзя они бы быть может посмотрели в сторону хаскеля. Так же это могли быть программеры на паскале и т.п. Но в силу объективных причин это не программеры на хаскеле — так что ты уж прости

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

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

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

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

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

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

Да нет разницы как это ты назовёшь, сути-то не меняет:
есть дыры и их решают или "заплатками" или "расширениями", т.е. переделкой/доделкой изначальной функциональности

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


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

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

G>А слоны идут, известно куда. На север. Кстати, если кит на слона налезет — кто победит? ?

Вах, старик, ну ты пошутил Гаааааа — рЭальные пацаны улыбаются

From: INTP_mihoshi
>функциональная надстройка над базой данных

Обычная реляционная БД это одна большая глобальная переменная.
В нормализованной БД таблицу можно рассматривать как "Лямбда ключ. ключ поле2 поле3 поле4".
Для ФЯ нужна ФБД. Вместо Лямбды сделать БетуДельту: БетаДельта = (Лямбда БД).

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

К>Ну тогда получаем, что при возникновениии проблемы переделываем нафиг язык чтоли? (Ну не совсем нафиг, но переделываем точно)
Ну естественно. А что, на попу сесть и плакать?
К>А кстати как с этим самым yield у васика?
Никак
К>Если нету его, то как там это решается?
Никак
К>И как соотносится с самим фреймворком (т.е. с реализацией в IL)?
Никак.
Это же фича языка!
К>Просто ключ. вопрос был в том, что в ФЯ это изначально предусмотрено и ни языка ни рантайма переделывать НЕ НАДО.
Представь себе, что у тебя нету C# 1.0. А есть сразу C#2. В нем это предусмотрено изначально, и ни языка ни рантайма переделывать не надо.

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

ON>From: INTP_mihoshi
>>функциональная надстройка над базой данных

ON>Обычная реляционная БД это одна большая глобальная переменная.
ON>В нормализованной БД таблицу можно рассматривать как "Лямбда ключ. ключ поле2 поле3 поле4".
ON>Для ФЯ нужна ФБД. Вместо Лямбды сделать БетуДельту: БетаДельта = (Лямбда БД).

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

Смотри список решений здесь и одно из решений тут.

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

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

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

К>>И как соотносится с самим фреймворком (т.е. с реализацией в IL)?
S>Никак.
S>Это же фича языка!
Как это никак?
на IL полюбому фича ложиться должна, т.е. генерировать код в итоге, иначе смысл-то её?

К>>Просто ключ. вопрос был в том, что в ФЯ это изначально предусмотрено и ни языка ни рантайма переделывать НЕ НАДО.
S>Представь себе, что у тебя нету C# 1.0. А есть сразу C#2. В нем это предусмотрено изначально, и ни языка ни рантайма переделывать не надо.
Ага, а если потом ещё что-нибудь подобное обнаружится, надо будет думать что ни 1.0 ни 2.0 не было, а только 3.0

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

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

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

К>>>И как соотносится с самим фреймворком (т.е. с реализацией в IL)?
S>>Никак.
S>>Это же фича языка!
К>Как это никак?
К>на IL полюбому фича ложиться должна, т.е. генерировать код в итоге, иначе смысл-то её?

К>>>Просто ключ. вопрос был в том, что в ФЯ это изначально предусмотрено и ни языка ни рантайма переделывать НЕ НАДО.
S>>Представь себе, что у тебя нету C# 1.0. А есть сразу C#2. В нем это предусмотрено изначально, и ни языка ни рантайма переделывать не надо.
К>Ага, а если потом ещё что-нибудь подобное обнаружится, надо будет думать что ни 1.0 ни 2.0 не было, а только 3.0

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

там же можно стянуть бинарники Cw compiler preview. Поговаривают что возможно этот диалект станет основой для C# 3.0.

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


B>По моему Sinclair немного перепутал, речь идет о Coemga, это ...

Ага, даёшь новый язык "Сёмга"