Re[8]: FP is comming...
От: OCTAGRAM Россия http://octagram.name/
Дата: 26.06.08 08:23
Оценка:
(repost)
FR пишет:
>
> А обязательно все делать функциональным?

Сдаётся мне, чистое ФП будет такой же ерундой, как сейчас чистое ООП.
По–хорошему нужен смешанный подход. Но и не так, что "мы вам дали лямбды
— всё, теперь есть ФП".

--
ISO/IEC 8652:1995/Amd 1:2007
Posted via RSDN NNTP Server 2.1 beta
Re[9]: FP is comming...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.06.08 08:28
Оценка:
Здравствуйте, OCTAGRAM, Вы писали:

OCT>(repost)

OCT>FR пишет:
>>
>> А обязательно все делать функциональным?

OCT>Сдаётся мне, чистое ФП будет такой же ерундой, как сейчас чистое ООП.

OCT>По–хорошему нужен смешанный подход. Но и не так, что "мы вам дали лямбды
OCT>— всё, теперь есть ФП".

Для того, чтобы в D было ФП там делаются не только лямбды, но и иммутабельные типы, и специальный модификатор pure для определения функций/методов без побочных эффектов.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: FP is comming...
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.06.08 08:37
Оценка:
Здравствуйте, OCTAGRAM, Вы писали:

OCT>(repost)

OCT>FR пишет:
>>
>> А обязательно все делать функциональным?

OCT>Сдаётся мне, чистое ФП будет такой же ерундой, как сейчас чистое ООП.

OCT>По–хорошему нужен смешанный подход. Но и не так, что "мы вам дали лямбды
OCT>— всё, теперь есть ФП".

Ну если по-честному, то если к лямбдам (полноценному лямбда-исчислению) добавить механизмы ввода-вывода, то собственно это всё, что нужно для программирования
Правда это всё дело ещё надо наложить как-то хотябы на х86 (и вообще на архитектуру фон Неймана), плюс механизмы I/O должны покрывать туеву хучу оборудовния
P.S. Не хотелось бы флейма на эту тему, это просто одна из возможных точек зрения.
P.P.S. На вопрос FR яб ответил так: конечно не обязательно, только введение импертивной составляющей делает reasoning (блин, не знаю как это по-русски сказать) по поводу кода гораздо более сложным, если не нереальным, хотя и на императивных языках есть средства улучшения качества кода (модульность вроде как сильно от функциональности/императивности не зависит, когда реализована нормально)
Re[10]: FP is comming...
От: OCTAGRAM Россия http://octagram.name/
Дата: 26.06.08 11:44
Оценка:
Курилка пишет:
>
> Ну если по-честному, то если к лямбдам (полноценному лямбда-исчислению)
> добавить механизмы ввода-вывода, то собственно это всё, что нужно для
> программирования
> Правда это всё дело ещё надо наложить как-то хотябы на х86 (и вообще на
> архитектуру фон Неймана)

Да, вот я об этом. У меня субъективное чувство, что современные попытки
скрестить ФП с императивным — это постановка телеги впереди лошади.
Вроде нужно? — нужно — и добавляются деревья, но за этими деревьями не
видно леса.

У меня несколько раз было так, что я сначала, отталкиваясь от проблемы,
вижу очертания решения, и обнаруживаю, что решение существует. Логично
ожидать, что это и сейчас так. Что касается ФП, то я тут ещё слишком
слеп, но мои представления о том, как всё должно быть устроено, таковы:

Императивные куски и функциональные существуют как бы перпендикулярно.
Здесь
Автор: OCTAGRAM
Дата: 22.05.08

я оставил без внимания причину собственно пересчётов. Пересчёты делались
как бы сами собой. Так, конечно, не пойдёт, поэтому эта модель должна
быть дополнена чем–то императивным, и именно этот императивный кусок
должен быть причиной (пере)вычисления функций. Т. е. функциональная
часть — это лабиринт, а императивная часть — это описание, куда по этому
лабиринту идти.

Надо посмотреть, как в Haskell императивные приёмы выглядят. Буду
созревать пока что.

--
ISO/IEC 8652:1995/Amd 1:2007
Posted via RSDN NNTP Server 2.1 beta
Re[11]: FP is comming...
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.06.08 12:05
Оценка: +1
Здравствуйте, OCTAGRAM, Вы писали:

OCT>Курилка пишет:

>>
>> Ну если по-честному, то если к лямбдам (полноценному лямбда-исчислению)
>> добавить механизмы ввода-вывода, то собственно это всё, что нужно для
>> программирования
>> Правда это всё дело ещё надо наложить как-то хотябы на х86 (и вообще на
>> архитектуру фон Неймана)

OCT>Да, вот я об этом. У меня субъективное чувство, что современные попытки

OCT>скрестить ФП с императивным — это постановка телеги впереди лошади.
OCT>Вроде нужно? — нужно — и добавляются деревья, но за этими деревьями не
OCT>видно леса.

OCT>У меня несколько раз было так, что я сначала, отталкиваясь от проблемы,

OCT>вижу очертания решения, и обнаруживаю, что решение существует. Логично
OCT>ожидать, что это и сейчас так. Что касается ФП, то я тут ещё слишком
OCT>слеп, но мои представления о том, как всё должно быть устроено, таковы:

OCT>Императивные куски и функциональные существуют как бы перпендикулярно.

OCT>Здесь
Автор: OCTAGRAM
Дата: 22.05.08

OCT>я оставил без внимания причину собственно пересчётов. Пересчёты делались
OCT>как бы сами собой. Так, конечно, не пойдёт, поэтому эта модель должна
OCT>быть дополнена чем–то императивным, и именно этот императивный кусок
OCT>должен быть причиной (пере)вычисления функций. Т. е. функциональная
OCT>часть — это лабиринт, а императивная часть — это описание, куда по этому
OCT>лабиринту идти.

Знаешь, императивность/функциональность — есть по сути просто 2 взгляда на одно то же.
Представления у тебя какие-то очень туманные, честно скажу "не осилил", моё субъективное впечатление — за кучей разных слов ты в итоге сам себя запутываешь. Как говорил по-моему Цезарь "разделяй и властвуй", у тебяж всё в одну кучу "свалено".
Реально у тебя задача там описана вполне функциональная — преобразовать А в Б, фактически тебе нужна функция А->Б.
Безусловно это дело можно императивно решить. Выбор по сути дела за тобой, что конкретно тебе удобно, правда функциональное решение, скорее всего дало бы некоторое число полезных "фенечек", как возможность композиции функций, независимость по ссылкам и т.п.
Только вот потребует она также "перестройки сознания" чтоли, которая, вполне возможно, нафиг не нужна, если уже есть вполне хорошее решение.

OCT>Надо посмотреть, как в Haskell императивные приёмы выглядят. Буду

OCT>созревать пока что.
Может не нужны тебе эти монады, а?
Re[12]: FP is comming...
От: OCTAGRAM Россия http://octagram.name/
Дата: 26.06.08 13:24
Оценка:
Курилка пишет:

> Реально у тебя задача там описана вполне функциональная — преобразовать

> А в Б, фактически тебе нужна функция А->Б.

Фактически мне нужно, чтобы функция не только вычислялась, но и
перевычилялась. Чтобы при изменении А можно было бы отобразить эти
изменения на Б. Как раз здесь и появляется состояние архитектуры фон
Неймана. Состояние программы описывается содержимым промежуточных
вычислений и их вычисленностью. В конечном результате может вдруг
отпасть необходимость. А, может быть, делая перевычисление, нужно
сохранять и прошлый результат, потому что он ещё где–то нужен. Этим
управляет императивная часть.

> Безусловно это дело можно императивно решить. Выбор по сути дела за

> тобой, что конкретно *тебе *удобно

> Только вот потребует она также "перестройки сознания" чтоли, которая,

> вполне возможно, нафиг не нужна, если уже есть вполне хорошее решение.

За решить проблема не стала. Хочется формализовать неявные зависимости.

> OCT>Надо посмотреть, как в Haskell императивные приёмы выглядят. Буду

> OCT>созревать пока что.

> Может не нужны тебе эти монады, а?


А может, наоборот, это ключевой момент?

> моё субъективное впечатление — за кучей разных слов ты в итоге сам

> себя запутываешь

Возможно, это слабо изведанная территория, первопроходцам тяжело.
До Erlang был PLEX, и в нём были изъяны, но это выяснилось уже после.
Вот и сейчас, быть может, в мире FP есть только ФПшные PLEX'ы.

--
ISO/IEC 8652:1995/Amd 1:2007
Posted via RSDN NNTP Server 2.1 beta
Re[13]: FP is comming...
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.06.08 13:41
Оценка: 2 (1)
Здравствуйте, OCTAGRAM, Вы писали:

OCT>Курилка пишет:


>> Реально у тебя задача там описана вполне функциональная — преобразовать

>> А в Б, фактически тебе нужна функция А->Б.

OCT>Фактически мне нужно, чтобы функция не только вычислялась, но и

OCT>перевычилялась. Чтобы при изменении А можно было бы отобразить эти
OCT>изменения на Б. Как раз здесь и появляется состояние архитектуры фон
OCT>Неймана. Состояние программы описывается содержимым промежуточных
OCT>вычислений и их вычисленностью. В конечном результате может вдруг
OCT>отпасть необходимость. А, может быть, делая перевычисление, нужно
OCT>сохранять и прошлый результат, потому что он ещё где–то нужен. Этим
OCT>управляет императивная часть.

Ну вот тут-то и нужна тебе перестройка сознания. Ты думаешь что она нужна, т.к. не можешь себе представить варианта, как это может быть выражено без императивности. Чисто для затравки глянь вон на бумеранг к примеру, хотя, может быть это будет слишком жёстко.
Ну а так вообще имхо у тебя задача по сути состоит в манипулировании графами, а уж этого добра в ФП выше крыши.

OCT>За решить проблема не стала. Хочется формализовать неявные зависимости.

Если ты хочешь чёткие зависимости, то придётся имхо копать всёж в сторону ФП, правда для начала надо это дело на бумажке и в голове формализовать, прежде чем кодить

>> OCT>Надо посмотреть, как в Haskell императивные приёмы выглядят. Буду

>> OCT>созревать пока что.

>> Может не нужны тебе эти монады, а?


OCT>А может, наоборот, это ключевой момент?

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

>> моё субъективное впечатление — за кучей разных слов ты в итоге сам

>> себя запутываешь

OCT>Возможно, это слабо изведанная территория, первопроходцам тяжело.

OCT>До Erlang был PLEX, и в нём были изъяны, но это выяснилось уже после.
OCT>Вот и сейчас, быть может, в мире FP есть только ФПшные PLEX'ы.

Про плексы ничего не знаю, поэтму врать не буду. В мире же ФП есть только лямбды, а остальное лишь настройки над ними.
Re[14]: FP is comming...
От: OCTAGRAM Россия http://octagram.name/
Дата: 26.06.08 19:02
Оценка:
Курилка пишет:
>
> Ну вот тут-то и нужна тебе перестройка сознания. Ты думаешь что она
> нужна, т.к. не можешь себе представить варианта, как это может быть
> выражено без императивности.

Продемонстрирую, что я имел в виду на примере Пролога:

В Прологе есть предикат concat(A, B, C). У него

Собственно, конкатенация. (напрямую)
Проверить, является ли C конкатенацией A и B.
Проверить, начинается/заканчивается ли одна строка на другую.
Перебор разбиений строки в последующих предикатах.

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

Вот также и здесь, функциональное описание позволит не только
использование функций напрямую (вычисления), но и делать перевычисления.

> Чисто для затравки глянь вон на бумеранг

За линк спасибо

> к примеру, хотя, может быть это будет слишком жёстко.

танки грязи не боятся

>

> OCT>Возможно, это слабо изведанная территория, первопроходцам тяжело.
> OCT>До Erlang был PLEX, и в нём были изъяны, но это выяснилось уже после.
> OCT>Вот и сейчас, быть может, в мире FP есть только ФПшные PLEX'ы.
>
> Про плексы ничего не знаю, поэтму врать не буду.

PLEX — это предшественник Эрланга. В "History of Erlang" критиковалась
невозможность обработать сообщения не в том порядке, в каком они
приходили. Когда делался Erlang, было написано много строк кода на PLEX,
но когда не было ни самого PLEX, ни кода на нём, это неудобство не могло
быть очевидно создателям PLEX.

--
ISO/IEC 8652:1995/Amd 1:2007
Posted via RSDN NNTP Server 2.1 beta
Re[15]: FP is comming...
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.06.08 05:34
Оценка:
Здравствуйте, OCTAGRAM, Вы писали:

OCT>Продемонстрирую, что я имел в виду на примере Пролога:


OCT>В Прологе есть предикат concat(A, B, C). У него


OCT>Собственно, конкатенация. (напрямую)

OCT>Проверить, является ли C конкатенацией A и B.
OCT>Проверить, начинается/заканчивается ли одна строка на другую.
OCT>Перебор разбиений строки в последующих предикатах.

OCT>И из таких многофункциональных конструкций строятся более сложные

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

Чтот чем дальше, тем больше у меня ощущение, что ты "плаваешь" в предмете.
Пролог — это не функциональный язык, а логический, парадигма там несколько другая, поэтому не стоит смешивать.
В функциональных языках перебор ты будешь задавать более или менее явно (хотя никто не мешает создать eDSL как некий аналог Пролог-машины, на хаскеле вроде не один пример есть, но это и на имеративе можно сделать).
А программисты не всегда помнят как обрабатывается программа (иначе бы багов вообще не было ), ну и оптимизаторы есть везде, императивность/функциональщина тут особо не при чём (тот же ГЦ по сути есть оптимизатор нацеленный на то чтоб программер "забил" на ручное управление памятью).
Что такое "многофункциональные конструкции" я вообще как-то не понимаю.
В ФП функция — вещь однозначная и 1 функция выполняет ровно 1 функцию, пусть возможно и не особо тривиальную.
Термин "перевычисления" тоже как-то мне непонятен (если речь про перебор, то это, повторюсь не ФП).
Ну и на ФП нет предикатов и такая задача будет решаться каким-нибудь аналогом императивных алгоритмов сравнения. А функция перебора (если таковая нужна) будет вызывать вот эту функцию сравнения. Ну тупо "разделяй и властвуй", каждая единица программы должна выполнять чётко ограниченную свою функцию (по-моему это универсальный принцип вменяемого программирования)

>> Чисто для затравки глянь вон на бумеранг

OCT>За линк спасибо
Обращайся, у меня их много

>> к примеру, хотя, может быть это будет слишком жёстко.

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

>>

>> OCT>Возможно, это слабо изведанная территория, первопроходцам тяжело.
>> OCT>До Erlang был PLEX, и в нём были изъяны, но это выяснилось уже после.
>> OCT>Вот и сейчас, быть может, в мире FP есть только ФПшные PLEX'ы.
>>
>> Про плексы ничего не знаю, поэтму врать не буду.

OCT>PLEX — это предшественник Эрланга. В "History of Erlang" критиковалась

OCT>невозможность обработать сообщения не в том порядке, в каком они
OCT>приходили. Когда делался Erlang, было написано много строк кода на PLEX,
OCT>но когда не было ни самого PLEX, ни кода на нём, это неудобство не могло
OCT>быть очевидно создателям PLEX.

Об этом-то я читал, только вот из таких фактов и без наличия самого PLEX или хотяб спецификации я бы побоялся делать какие-либо выводы.
Для эрланга же есть компилятор/интерпретатор/рантайм, достаточно полная документация и даже спеки какие-то были. Сравнивать "тёплое с мягким" я как-то не вижу смысла, учитывая многолетний успешный опыт использования Эрланга по миру (включая не очень серъёзный собственный опыт). Тем более на прошлой работе я фактически участвовал в написании аналога эрлангового рантайма на Яве и знаю не по наслышке разницу между относительно простыми отработанными решениями эрланговыми и по сути "самопальными" (хоть и под эгидой JSR) решениями.
Re[10]: FP is comming...
От: FR  
Дата: 03.09.08 18:59
Оценка: 20 (1)
Здравствуйте, eao197, Вы писали:

E>Для того, чтобы в D было ФП там делаются не только лямбды, но и иммутабельные типы, и специальный модификатор pure для определения функций/методов без побочных эффектов.


Похоже для противовеса теперь решили и к стороне C++ подтянуть http://www.digitalmars.com/d/2.0/struct.html#Struct-Constructor похоже станет "D'шные струкуры" == "С++ классы"
Re[11]: FP is comming...
От: FR  
Дата: 21.10.08 12:54
Оценка: 17 (1)
Для компенсации теперь в D 2.020 реализовали immutable http://www.digitalmars.com/d/2.0/changelog.html#new2_020
Re[12]: FP is comming...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 21.10.08 13:00
Оценка: +1
Здравствуйте, FR, Вы писали:

FR>Для компенсации теперь в D 2.020 реализовали immutable http://www.digitalmars.com/d/2.0/changelog.html#new2_020


И в очередной раз нарушили совместимость для написанного ранее кода за счет разделения на druntime и phobos Это я не к поддержке ФП, а к стремности использования D в чем-то серьезном.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: FP is comming...
От: FR  
Дата: 04.11.08 16:12
Оценка:
Здравствуйте, eao197, Вы писали:

E>И в очередной раз нарушили совместимость для написанного ранее кода за счет разделения на druntime и phobos Это я не к поддержке ФП, а к стремности использования D в чем-то серьезном.


Угу жаль что он никак ни народится
Тут недавно был разговор про выразительность, и там всплыл неэффективный qsort на хаскеле, который вроде из-за этого бессмысленен, но мне в голову пришло что он вполне применим для compile-time метапрограммирования на шаблонах, решил попробовать на D сделать, оказалось на удивление просто:

Сначала вспомогательные вещи:

template filter(alias F, alias Arr) if(Arr.length < 1)
{
    const filter = Arr;
}           

template filter(alias F, alias Arr) if(Arr.length >= 1)
{
    static if(F(Arr[0]))
        const filter = [Arr[0]] ~ filter!(F, Arr[1 .. $]);
    else 
        const filter = filter!(F, Arr[1 .. $]);
}           

bool less_n(int N)(int x)
{
    return x < N;
}

bool not_less_n(int N)(int x)
{
    return x >= N;
}


Теперь сам qsort:

template qsort(alias Arr) if(Arr.length < 2)
{
    const qsort = Arr;
}

template qsort(alias Arr) if(Arr.length >= 2)
{
    const qsort = 
        qsort!(filter!(less_n!(Arr[0]), Arr[1 .. $]))
        ~ [Arr[0]] ~
        qsort!(filter!(not_less_n!(Arr[0]), Arr[1 .. $]));
}


На C++ я не рискну повторить
Re[14]: FP is comming...
От: Курилка Россия http://kirya.narod.ru/
Дата: 04.11.08 16:30
Оценка:
Здравствуйте, FR, Вы писали:

FR>Тут недавно был разговор про выразительность, и там всплыл неэффективный qsort на хаскеле, который вроде из-за этого бессмысленен, но мне в голову пришло что он вполне применим для compile-time метапрограммирования на шаблонах, решил попробовать на D сделать, оказалось на удивление просто:


[cut]

А теперь попробуй в 2 словах пояснить, что за тильды, алиасы и факториалы?
Как-то по ходу D от си/плюсов далеко ушёл
Или может это я тупой
Re[15]: FP is comming...
От: FR  
Дата: 04.11.08 16:46
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А теперь попробуй в 2 словах пояснить, что за тильды, алиасы и факториалы?

К>Как-то по ходу D от си/плюсов далеко ушёл
К>Или может это я тупой

Тильды просто конатекция массивов, у автора языка вжик на тему что "+" для этого не
годится
Факториалы это инстанцирование шаблонов
Алиасам аналогов в C++ нет в общем это ссылочный параметр в шаблонах http://www.digitalmars.com/d/2.0/template.html#aliasparameters
Re[8]: FP is comming...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.11.08 04:36
Оценка:
Здравствуйте, FR, Вы писали:

VD>>А кто мешал перед созданием "улучшенного C++" изучить не только С++, но еще и тот самый ОКамл? Даже Степанов это проделал. Не в его силах, конечно, было улучшить С++, чтобы получилось красиво, но тем не менее STL получился весьма функциональным (насколько это возможно в С++).


FR>А обязательно все делать функциональным?


Нет. Но ФП-фичи, будучи грамотно встроенными в язык, дают реальное увеличение его мощности. Это дает возможность выбирать реализацию отталкиваясь от своих предпочтений, а не от ограничений и расположения граблей вокруг тебя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: FP is comming...
От: FR  
Дата: 26.11.08 04:35
Оценка:
Здравствуйте, eao197, Вы писали:

E>И в очередной раз нарушили совместимость для написанного ранее кода за счет разделения на druntime и phobos Это я не к поддержке ФП, а к стремности использования D в чем-то серьезном.


В 2.021 продолжили начатое нарушение совместимости, this в структурах стал ссылкой, и дальнейшие изменения в runtime.
Зато ввели флажок -safe
Re[14]: FP is comming...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.11.08 07:58
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>В 2.021 продолжили начатое нарушение совместимости, this в структурах стал ссылкой, и дальнейшие изменения в runtime.

FR>Зато ввели флажок -safe

Блин, Брайту нужно объяснить смысл пословицы "Лучшее враг хорошего".


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: FP is comming...
От: FR  
Дата: 16.02.09 06:07
Оценка:
Здравствуйте, eao197, Вы писали:

E>Блин, Брайту нужно объяснить смысл пословицы "Лучшее враг хорошего".


Смотрю я на последнюю http://www.digitalmars.com/d/2.0/changelog.html#new2_025 версию и вижу что ничего ни добавили, начинает появлятся надежда
Re[16]: FP is comming...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.02.09 07:21
Оценка:
Здравствуйте, FR, Вы писали:

E>>Блин, Брайту нужно объяснить смысл пословицы "Лучшее враг хорошего".


FR>Смотрю я на последнюю http://www.digitalmars.com/d/2.0/changelog.html#new2_025 версию и вижу что ничего ни добавили, начинает появлятся надежда


С другой стороны, вместо того, чтобы завершить работу над спецификацией языка D2.0 добавили в DMD частичную поддержку Max OSX... (Walter Bright: Expect bugs. Thread local storage isn't working on OSX, neither are sockets and memory mapped files (for unknown reasons).)


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.