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


_>>2.Отсутствие циклических структур данных или их эмуляция — это тоже достоинство?
G>Ну наконец кто-то начал говорить о настоящих проблемах ФЯ. Ок, побеседуем. Представляю, какие радостные крики сейчас начнутся.

_>>А вот с графом...Есть конечно fgl.Но это эмуляция графа деревом.Ну нет той чистой простоты
_>>По-видимому если две ссылки от двух вершин указывают на третью то они должны указавать на одну и ту же вершину.Это противоречит великому принципу ФЯ?
G>Нет конечно. Зачем, кстати, язвить? Вершины могут и будут разделяться, так что с ациклическими графами проблем нет. Настоящие циклические ссылки тоже возможны — но подграф с циклом должен быть создан сразу, модификацией такого не достичь. Есть соответствующие примеры на Хаскеле.

Да и насколько я понимаю это возможно только при помощи lazy evaluation
примерно так
List = Null | List Int List List -- List содержимое преведущий следующий
let A1= List 10 Null A2
A2= List 20 A1 A3
A3= List 30 A2 Null
in A1

G>Т. е. настоящая проблема (вернее, принципиальное ограничение) формулируется так. Невозможно менять состояние элементов функциональной циклической структуры по отдельности, она может быть изменена только целиком. Что не очень эффективно.
В этом и был вопрос.Хоть я и не очень понятно объяснил

G>1) Это является принципиальной проблемой только "чистых" ФЯ, которые не допускают побочных эффектов. А это только Clean и Haskell.
Haskell

G>2) При этом, это совершенно не смертельно. Для графа существует несколько вариантов эффективных по памяти и скорости представлений, не содержащих прямых циклических ссылок. В ФЯ мы будет переходить от одного представления к другому, в зависимости от того, какие операции доминируют в данный момент, чтения или модификации. Т. е. мы будем применять т. н. functional update. См. ниже, на примере массивов.

Ну да есть массив-индексы в массиве — те же ссылки -а двум числам никто не запретит быть одинаковыми
Неприятность — неизвестен заранее размер массива .Да GC в массиве придется делать самому

_>>У меня складывается впечатление что легко и быстро можно работать только с односвязными списками и деревьями всех мастей — здесь все для вас и конструкторы и pattern matching .. А вот уже массивы не вкладываютя в общую
_>>систему и необходима специальная поддержка компилятора чтобы доступ не стал O(n).
G>Неправда. Укладываются великолепно в сочетании с list и array comprehensions. Доступ к массивам всегда O(1). А на поэлементной модификации можно словить и O(N), если захотеть. А если не хочется, то:
G>1) Если модифицируется весь или большая часть массива, то он обычно пересоздается целиком один раз с уже измененными элементами (используя list или array comprehensions), и никакого N^2 там не будет. Без всякой поддержки компилятора — это так называемый functional array update, возможный в любом ФЯ. Записывается кратко и удобно. По вычислительной сложности не проигрывает обычному деструктивному изменению. Пример на Хаскелездесь

Автор: Gaperton
Дата: 15.06.04

.
Вы меня не поняли — массив не объявишь и не реализуешь стандартными средствами того же Haskell а встроен как Int.А не как data List a = Null | a:List a.


G>2) Чтобы получить деструктивное O(1) изменение массива в Хаскель, достаточно воспользоваться монадой ST.
Thanks.Не знал.

_>> И двусвязные списки тудаже.
G>С этим та же ситуация, что и с графами, т. е. такой список может быть изменен только будучи целиком созданным заново. Но меньше способов выкрутится. Тем не менее, они есть.
G>1) Первый (для чистых ФЯ) состоит в разворачивании однонаправленного списка по мере необходимости. Скажете, это не эффективно? Да, конечно. Но и не смертельно, мы ведь говорим о вычислительной сложности, так? Рассмотрим пример — надо реализовать очередь. Делаем ее на паре двунаправленных списков. Кладем поступающие элементы в первый список. Забираем элементы из второго списка. Если он пуст (!) присваиваем ему результат разворота первого списка, первый список делаем пустым. Эта структура известна как Okasaki Queue, и имеет средневзвешенную сложность операций put и get равную O(1).
Читал.

G>2) Второй (для чистых ФЯ) — использовать read-only двунаправленные списки, пересоздавать их используя групповые изменения, как с массивами.



_>>Фундаментальной структурой данных ИЯ является массив — ФЯ дерево?
G>Для ФЯ — скорее список.
Maybe

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

_>Ну да есть массив-индексы в массиве — те же ссылки -а двум числам никто не запретит быть одинаковыми
_>Неприятность — неизвестен заранее размер массива .Да GC в массиве придется делать самому
Графы из стандартной либы не подходят? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Graph.html

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

Q>На интерпретаторе (!) ghci под Windows на моей не самой быстрой машине первые 5000 (до 48619) чисел вычислились за 40 секунд, что примерно в 2 раза быстрее, чем на твоей программе .
Ну если тебе надо 5000 то...

number = 2 x = 1 count = 1 time = 6.56336e-06
number = 3 x = 2 count = 2 time = 0.00123109
number = 5 x = 3 count = 3 time = 0.00220563
number = 7 x = 5 count = 4 time = 0.00318859
number = 11 x = 8 count = 5 time = 0.00425005
number = 17 x = 13 count = 7 time = 0.00521524
number = 23 x = 21 count = 9 time = 0.0062029
number = 37 x = 34 count = 12 time = 0.00726603
number = 59 x = 55 count = 17 time = 0.00827418
number = 97 x = 89 count = 25 time = 0.00942301
number = 149 x = 144 count = 35 time = 0.0104404
number = 239 x = 233 count = 52 time = 0.0114785
number = 379 x = 377 count = 75 time = 0.0132433
number = 613 x = 610 count = 112 time = 0.0142888
number = 991 x = 987 count = 167 time = 0.0155076
number = 1601 x = 1597 count = 252 time = 0.0165676
number = 2591 x = 2584 count = 377 time = 0.0177834
number = 4201 x = 4181 count = 575 time = 0.0188863
number = 6779 x = 6765 count = 872 time = 0.0201199
number = 10949 x = 10946 count = 1330 time = 0.021233
number = 17713 x = 17711 count = 2034 time = 0.0225363
number = 28661 x = 28657 count = 3122 time = 0.0237418
number = 46381 x = 46368 count = 4795 time = 0.0249562
total = 5136 time = 0.0262307

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

//Это ограничительная константа(твоя программа раньше сдохнет.)
//На 64х битных платформах ее можно со спкойной совестью еще поднять.
//Но у меня 32х битная машина :(
size_t const max_number=2*1024*1024*1000;
//Этой константой можно играться для тонкой настройки производительности алгоритма
size_t const buf_count=4*1024*1024;
size_t const buf_size=buf_count/CHAR_BIT;

struct prime_numbers
{
    size_t cur_number;
    size_t state;
    size_t offset;
    size_t next_offset;
    std::vector<byte> buf;
    std::vector<size_t> numbers;

    prime_numbers()
        :state(8)
        ,offset(0)
        ,next_offset(buf_count)
        ,buf(buf_size+100)
    {
        numbers.reserve(2*1024*1024);
    }
    void set_bit(size_t n)
    {
        n-=offset;
        size_t pos=n/CHAR_BIT;
        size_t ofs=n%CHAR_BIT;
        buf[pos]|=1<<ofs;
    }
    bool get_bit(size_t n)
    {
        if(n>=next_offset)
        {
            offset=next_offset;
            next_offset+=buf_count;
            std::fill(buf.begin(), buf.end(), 0);
            //вычеркивать начинаем с 7 ибо числа кратные 2, 3, 5 нам всеравно не попадутся :))
            for(size_t i=3, c=numbers.size();i<c;++i)
                remove_number(numbers[i]);
        }
        n-=offset;
        size_t pos=n/CHAR_BIT;
        size_t ofs=n%CHAR_BIT;
        return buf[pos]&(1<<ofs);
    }
    void new_number(size_t i)
    {
        numbers.push_back(i);
        remove_number(i);
    }
    void remove_number(size_t i)
    {
        for(size_t n=(offset/i+1)*i;n<next_offset;n+=i)
            set_bit(n);
    }
    size_t get_next()
    {
        size_t i=cur_number;
        switch(state)
        {
            case  8:    new_number(2);    state= 9;    return 2;
            case  9:    new_number(3);    state=10;    return 3;
            case 10:    new_number(5);    state=11;    return 5;
            case 11:    i=1;
            case 0:
            for(;i<max_number;)
            {
                    i+=6;    if(!get_bit(i))    {new_number(i);    state=1;    return cur_number=i;}
            case 1:    i+=4;    if(!get_bit(i))    {new_number(i);    state=2;    return cur_number=i;}
            case 2:    i+=2;    if(!get_bit(i))    {new_number(i);    state=3;    return cur_number=i;}
            case 3:    i+=4;    if(!get_bit(i))    {new_number(i);    state=4;    return cur_number=i;}
            case 4:    i+=2;    if(!get_bit(i))    {new_number(i);    state=5;    return cur_number=i;}
            case 5:    i+=4;    if(!get_bit(i))    {new_number(i);    state=6;    return cur_number=i;}
            case 6:    i+=6;    if(!get_bit(i))    {new_number(i);    state=7;    return cur_number=i;}
            case 7:    i+=2;    if(!get_bit(i))    {new_number(i);    state=0;    return cur_number=i;}
            }
            state=12;
            case 12:;
        }
        return -1;
    }
};
#include "1.h"
int main()
{
    prime_numbers numbers;
    timer.reset();
    for(;;)
    {
        size_t n=numbers.get_next();
        if(n==-1)
            break;
        on_prime_number_print(n);
    }
    std::cout<<"total = "<<count<<" time = "<<timer.time()<<std::endl;
    return 0;
}

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

number = 2 x = 1 count = 1 time = 0.011247
number = 3 x = 2 count = 2 time = 0.0224944
number = 5 x = 4 count = 3 time = 0.0287227
number = 11 x = 8 count = 5 time = 0.0357256
number = 17 x = 16 count = 7 time = 0.0404335
number = 37 x = 32 count = 12 time = 0.0475099
number = 67 x = 64 count = 19 time = 0.0526
number = 131 x = 128 count = 32 time = 0.059383
number = 257 x = 256 count = 55 time = 0.0659315
number = 521 x = 512 count = 98 time = 0.0716429
number = 1031 x = 1024 count = 173 time = 0.0795682
number = 2053 x = 2048 count = 310 time = 0.0849316
number = 4099 x = 4096 count = 565 time = 0.0922635
number = 8209 x = 8192 count = 1029 time = 0.0975916
number = 16411 x = 16384 count = 1901 time = 0.103196
number = 32771 x = 32768 count = 3513 time = 0.113651
number = 65537 x = 65536 count = 6543 time = 0.124821
number = 131101 x = 131072 count = 12252 time = 0.133369
number = 262147 x = 262144 count = 23001 time = 0.140619
number = 524309 x = 524288 count = 43391 time = 0.146233
number = 1048583 x = 1048576 count = 82026 time = 0.153858
number = 2097169 x = 2097152 count = 155612 time = 0.164312
number = 4194319 x = 4194304 count = 295948 time = 0.258359
number = 8388617 x = 8388608 count = 564164 time = 0.376738
number = 16777259 x = 16777216 count = 1077872 time = 0.637997
number = 33554467 x = 33554432 count = 2063690 time = 1.21231
number = 67108879 x = 67108864 count = 3957810 time = 2.65548
number = 134217757 x = 134217728 count = 7603554 time = 6.5156
number = 268435459 x = 268435456 count = 14630844 time = 17.9281
number = 536870923 x = 536870912 count = 28192751 time = 54.6199
number = 1073741827 x = 1073741824 count = 54400029 time = 180.671
total = 102754101 time = 608.485

Q>Кстати, OCaml, думаю, вообще не проиграл бы в производительности, поскольку на него твою программу можно перенести 1 в 1.
Если писать императивно. Кстати напиши. И сравним производительность

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

G>"Оптимизацией" являются такие вещи, например, как single threadness analyzis, который программистом явно не контроллируется, частью языка не является, и способен в ряде случаев радикально улучшить производительность функциональной программы. Считаем это жульничеством, божественным вмешательством, и оптимизацией.

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

А пузырьковая сортировка более декларативна чем быстрая. Декларативность это пожалуй минимум избыточности в логике при описании задачи.
Хотя в идеале декларативное описание сортировки должно выглядеть так:

Sort(Array A)
{
  for(x in A.IndexSet and y in A.IndexSet)
   if(x>y) 
     Assert(A[x]>A[y])
}

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

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

Какой вариант должен работать быстрее, конкретный алгоритм сортировки на C# или такой декларативный алгоритм:

declarative void Sort(int[] A)
{
  for(int i=0;i<A.Length;i++)
   for(int j=0;j<A.Length;j++)
    if(i<j)
     assert(A[i]<A[j]);
}

Естейственно декларативная форма должна работать быстрее.
Кстати, не путать ее с функцией на C# проверки отсортированности массива, это именно функция сортировки массива, у нее другая семантика из-за ключевого слова declarative хоть она и выглядит похоже.

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

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

В Си есть на этот случай ключевое слово restrict.

N_>Зачислять фортран в функциональные языки наверное не стоит, но по уровню абстракции он немного выше языка Си.

Си — возможно. Но не Си++.

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

G>У меня предложение попроще, способное на порядок поднять культуру общения. Давайте Чистякоа перестанет хамить и переходить на личности.

То что ты называешь хамством другие называют называть вещи своими именами. Или говорить правду. Что же до хамства, то не тебе об этом говорить. Кажется не я поднял вопрос о быдляцких манерах (или что там было быдляцкого?).

G>Объясни это Чистякову. Я ему недавно объяснял подробно, он видимо не понимает.

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

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

VD>>Значит не понял. Ну, тут ничего не поделашь.
G>А ты еще чего нибудь скажи, зачем так сразу сдаваться.

Сказал "чего-нибудь".

G> Про демагогию, например, что-то давно слушно не было.

А ты разведи и я скажу. Поговори о умственных способностях собеседника. Унизь его прау раз. И я обязательно скажу.

G> Усомнись в моей профпригодности, в способности понимать русский язык.

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

G> Побей себя копытом в грудь — скажи, что у тебя на дефект уходит 5 — нет, 3 минуты.

А что мне бить то? У кого копыта тот и должен себя (других?) бить.
А про то насколько быстро находятся и устраняются ошибки в Шарпе ты можешь задать вопрос в соотвествующем форуме. Моих скилов в нете тебе явно не достаточно. Пусть тебе другие скажут. А еще лучше изучи дотнет и пол годика по программируй на том же Шарпе. Тогда вопрос будет исчерпан сам собой. Забавно будет послушать тебя после этого... как ты расскажешь, что нужно сделать чтобы ловить ошибку мемяцы на пролет.

G> Ну как ты там еще объясняешь? О, тяжелая артилерия. Попроси меня поверить тебе на слово. Все это разбавь безграмотными рассуждениями.

Твоими? Или это ты наглядно демонстрируешь как ты не хамишь?

G>Репутацию свою ты уже не испортишь, а, как говорил поручик Ржевский, "можно и впердолить".

Ну, о моей репутации слава богу не тебе судить. Ты ее тут даже не сумел заработать. Так что Ржевский — молчать. (с)

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

VD>>2Lloyd: У тебя конвульсии или ты случайно на минус все время попадаешь? Это уже как-то не серьезно.

INT>Рефлекс на нарушение пятого пункта полиси

Явно какой-то заклинивший. Нечто вроде тика. Да и дело модератора следить за нарушениями. А то как-то следит только за моими. Причем мерещатся они везде. Вроде даже голосование создал. Его все послали куда полдальше...

Да мне даже забавно. Но итересны мотивы.

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

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

VD>>2Lloyd: У тебя конвульсии или ты случайно на минус все время попадаешь? Это уже как-то не серьезно.

L>2VladD2: нет, это не конвульсии и не случайность. это адекватная реакция на твое хамское неуважение к аппонентам.

Ну, предположим назовем мои слова "хамское неуважение к аппонентам" хотя звучит довольно смешно. "Хамское неуважение". Но что такого хамского ты нашел, например, в этом: Re[12]: Сильные стороны функционального программирования

Автор: VladD2
Дата: 04.09.04

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

Почему я не видел ни одного твоего минуса даже на окровенные оскарбления тем же Gaperton других участников форума?

Re[10]: ФЯ

Автор: Gaperton
Дата: 20.08.04

Re[10]: Сильные стороны функционального программирования

Автор: Gaperton
Дата: 01.09.04

Re[8]: Сильные стороны функционального программирования

Автор: Gaperton
Дата: 01.09.04

Двойные стандарты?

ЗЫ

Чесное слово. Просто любопыткно.

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

VD>>Тяжело говорить с людьми не умеющими понять, что собеседник демострирует абсурдность их логики.
G>...не зная при этом Хаскеля, о чем открыто заявляет. Браво.

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

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

VD>>Ну, то есть мы сошлись на едином мнении о том, что все слова об ужасах побочных эффектов — это притянутая за уши фигня?

Q>Нет.

Странно.

Q>Не в этом дело.

А...

Q> Я писал одну немаленькую программу на SML (часть компилятора) и, хотя я использовал там императивные фичи, проблем с ними я не имел. Поскольку они были изолированы в коде и привести к ошибкам не могли, поскольку их использование носило вспомогательный характер. Соответственно проблемы с side-effects не было.

А я вот писал на Шарпе где 90% импиративно, и проблем с ними так же не имел. Это является достаточным чтобы развить теорию о приемуществе ИЯ? Нет? А почему тогда ты считашь, что твоих доводы достаточны?

Q>В HAskell'e сторонние эффекты недопустимы, поскольку там должно выполнятся правило, что при вызове функции с одними и теми же аргументами должно возвращаться одно и то же значение.

Рад за него. В С++ тоже есть слова const не доупускающее побочных эффектов. Но намного более надежным С++ от этого не становится. В Шарпе подобной фичи нет. А надежность на нем намного выше. Вывлд — надежность кода слабо связано с наличием возможности создания побочных эффектов. Идиология Хаскеля делает упор на одно. Иделогия Шарпа на другое. В итоге оба достигают своего. Кстати, главной фичей приводящей к полвышению надежности в обоих языках видится отсутствие прямой работы с указателями. Это куда более весомый аспект. Ну, еще типобезопасность. Эти фактор постоянно ухудшают надежность С++-приложений. И именно из-за них надежность С++-програм низка. Так что если ты перенесешь свои сравнения с С++ на C#, то процентов 80 твоих доводов улитучится сами собой.

Q> Но при обмене данными с внешним миром такое правило, очевидно, выполняться не может.

Что ж тут очевидного? Тут очевидна слабая доказательная база.

Q> Поэтому создатели языка исхитрились и придумали довольно забавный способ обойти это ограничение — монады. Они пригодны не только для ввода-вывода, но, если говорить только о нем, то они обладают тем свойством, что если что-то вошло в IO монаду, то выйти из нее уже не сможет. Т.е. все что имеет IO довесок в типе, потенциально небезопасно и компилятор обрабатывает эти значения по особому. В тоже время основная часть программы написана в чистом стиле и компилятор может этим пользоваться как хочет в целях оптимизации. В C# это не пройдет. Ведь то, что функция не имеет никаких сторонних эффектов знает только программист, да и мало, я думаю, таких функции.

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

Q>В OCaml ситуция другая. Там принят другой способ вызова функций — по значению, а не по имени (т.е. когда параметры функции вычисляются только в случае необходимости) и поэтому проблем с императивщиной там меньше. Компилятор может сам понять, есть ли side-effects в данной функции. Но в целом они там нужны только для ввода-вывода, каких-то вычислительных задач типа сортировки и хранения глобального состояния программы, чтобы не таскать его по всему коду в качестве аргумента.

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

У ФЯ есть много других приемуществ, чтобы не пытаться превознести их на столь второстипенных вещах. Функции высшего порядка и патерн-матчинг намного более интересные явления. Согласись, что нет особых проблем встроить в ИЯ средства контроля за побочными эффектами и передачу параметров в стиле макросов. Это все фигня.

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

Q>Естественно, в С# можно эмулировать ленивые вычисления, точно так же, как на ассемблере можно писать в объектно ориентированном стиле. Вопрос насколько это красиво, удобно и понятно.

Хороший вопрос. Можно его обсудить. Шарп — это язык относящийся к ООЯ. А этот класс языков основной своей задачей ставит (в твоей терминалогии) эмуляцию любой функциональности на основе инкапсуляции и полиморфизма. Есть давольно бесхистросные паттерны позвляющие работать с довольно сложными понятиями и сущностьями так как будо бы они встроены в язык.

Q> Ленивые вычисления в Haskell'е врожденная черта. Чтобы ими пользоваться не нужно предпринимать никаких дополнительных действий, думать как да что.

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

Q>Вот, например, вычисление простых чисел методом решета:

Честно говоря порядком надоело смотреть на все эту очужденную от жизни фигню. Ты в своей работе часто получаешь список простых чисел? Я вот ни разу не получал. А если и получал, то мне хватало обычного цикла. Зачем эмлировать последовательность из примитивного алгоритма? А вот где в жизни действительно нужны эти ленивые вычисления? Я вот припоменаю только потоковый вод/вывод вроде передачи данных по сокетоам. Но там есть объект типа стрим который решает все проблемы.

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

WH>Подавляющие время занял вывод.

А зачем ты его измерял?

WH>легко...

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

Q>>Кстати, OCaml, думаю, вообще не проиграл бы в производительности, поскольку на него твою программу можно перенести 1 в 1.
WH>Если писать императивно. Кстати напиши. И сравним производительность

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

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

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

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

G>Никто не говорил про "нельзя".

Да? А это чьи слова:

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

G> Речь о том, что ленивые вызовы опасны при наличии побочных эффектов. Может ты начнешь наконец тратить время на чтение сообщений?

Речь о том, что кто-то поняв что был не прав начал выкручиваться и переключать контекст обсуждения.

Что до опасности, то я уже как-то говорил (раз 30), что сотни тысяч прграммистов использующих Шарп и Яву как-то не замечают этих опасностей. Иными словми имеет место намеренное завышение опасности.

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

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

VD>>Рад за тебя. Вот только кроме тебя были и другие люди пишущие код. И у некоторых из них он таки работал.
G>Эта система успешно работает более 10 лет . Четыре фермы серверов, самая крупная — в Чикаго.

Зачем тогда приводеть ее в качестве негативного примера? Или есть такая же система написаная на чистом ФЯ работающая 10 лет и не имевшая никаких проблем при разработке?

G>Я эксперт по С++ .

Скромно и очень доказательно.

G> И ведущий специалист компании по архитектуре данного приложения, sardonix не даст соврать.

Я в общем то верю и так. Хоя ссылка на какого-то sardonix-а явно выглядит смешно.

G> Работает оно великолепно, Влад, для приложения такого объема написанного на С++. Опыт у нас исключительно положительный.

Тогда сейчас ты сильно себе противоречишь.

G> И за последние 5 лет накоплена большая статистика по дефектам production-а, чтобы можно было достоверно говорить о причинах этих дефектов. Через меня и мою группу их прошла примерно тысяча (часть которых была вызвана тем, что SQA запутались в требованиях) — точно посмотреть не могу, т. к. пишу из дома.

Откровенно говоря 1000 для стольк масштабного продукта — это очень не много.

Ну, да фиг с ним. Какое это отношение имеет к ФЯ? Еще раз спрашиваю, почему при столь "явных" приемуществах ФЯ вы не выкинули С++ к чертям собачим и не переписали все на том же Хаскле?

G>Не сложнее, чем на С#,

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

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

G> если конечно умеешь пользоваться языком.

Сдается мне, что мои знания С++ не меньше твоих. По крайней мере проработав на этом языке 10 лет я имею право рассуждать о его достоинствах и недостатках. Так что предлагаю избежать измерения пенисов.

G> Вот уж с чем нет проблем, так это с управлением памятью, если руки растут откуда надо (если придерживаться строгой ownership policy). Ну, и работая с С++ не стоит увлекаться COM-объектами. И все будет в порядке.

В порядке может и будт. Но приложения будут получаться очень похожие на мамонтов. Для серверов мамонто-подобность может и ничего, но вот одна беда. Серверы на плюсах выходят очень ненадежными и отлаживаются очень долго. Собственно дотнет в первую очередь и проектировался для простого и быстрого создания серверных решений. Вот этот сайт, кстати, работает на дотнете и почти весь код написан на Шарпе. Много ты сможешь назвать веб-серверов чей прикладной код написан на С++? А на Хаскеле? Хотя последнее конечно уже из другой оперы.

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

G>Поправлю. Не отладки, а сложность поддержки и цену внесения изменений. Не путай, это совсем разные вещи.

Ты говорил и конкретно об отладке. Не нужно перепрыгивать. Но даже если говорить о "цену внесения изменений" и поддержке, то тут тоже твой любимый Хаскель вряд ли сможет тягаться с Шарпом или Явой просто потому, что для них создан целый ворох приложений, утилит, и мощьнейших IDE которые делают эти процессы простыми как три копейки. Хотя конечно без должного проектирования можно все превратить в кашу. Тебе как архитектору это должно быть известно. И нет проблем превратить в кашу самый что не наесть функциональный код. Как говорится с дуру можно и ... сломать.

G>Потому, что сидел над своим кодом, который тебе знаком.

Ошибашся. К сожалению мне приходилось сидеть и за чужим кодом. Но на Шарпе отладка настолько проста и код насктолько хорошо читается, что о дне отладки, а уж темболее о неделе или месяце говорить не приходится. Просто ты отстал от жизни. Сосредоточился на ФЯ, а кроме них и другие области вперед продвинулись.

G>Понятно. На поддержке никогда не сидел. Функционала в чужой старый код большого объема не добавлял.

Я тебе уже несколько раз говорил. Код пишишь только ты. И знаешь тоже только ты.
В общем, убрал бы ты свое самомнение. Изходи из того, что с тобой разговаривают не менее опытные люди чем ты сам. А то просто противно разговаривать. Сенсей, блин.

G>Подобные проблемы имеют обыкновение выглядеть как сложные зависимости в алгоритмах.

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

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

Не всегда. Как раз на плюсах очень часто возникают ошибки которые не свзаны с ошибкой непосредственно. Возмем к приеру проход по памяти. Да если ты все понял и нашел тот участок что портит память, то все ОК. Но логически вычислить такую ошибку нельзя. Так как ошибка в одном месте порождает ошибку высшего порядка в других. Тут уже нужно мастерство и шаманство. То что в народе называют скилами. Я как раз очень долго занимался тем, что отлавливал ошибки не буеручки сделанные другими (на плюсах). С некоторым чутьем и набором отладочного софта эти проблемы тоже решаем, хотя не так быстро. Так вот когда я начал программировать на Шарпе, то понял насколько проще отлаживаться когда принципиально нет подобных проблем. Код попросту не может содержать то, что не ненаписано в коде. Ошибок высшего порядка добиться очень сложно, а от того обычные ошибки вылавливаются быстро и просто.

G> И при неопределенном порядке вычислений и наличии побочных эффектов это очень сложно.

Еще раз повторю. Не нужно рассказывать сказки. 20 минут на самую сложную ошибку. При создании того же парсера для R#-а намного сложнее было создать верную граматику, нежели найти мелкие ошибки. При более-менее человеческом дизайне они отлавливаются в секунды.

G> Часто приходится встраивать в программу trace, ждать несколько дней, когда ситуация повторится, а потом долго разбирать trace, сопоставляя с кодом (чаще всего чужим, и правленным несколькими людьми), и пытаясь сообразить, как такое могло получиться.

Твой плюсовый опыт уже начинает надоедать. Поверь есть люди живущие по другому. Именно по тому многие мнее опытные и выбирают Шарп, что в нем не нужно сидеть недели на пролем с трэйсом.

G> И ты знаешь, иногда (редко) понять не получается, и приходится применять симптоматическое лечение — клиенты ждать не хотят!

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

G>Кстати, может прекратим "меряться пиписьками"? А то ты меня провоцируешь.

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

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

hrg>Чувааааак. Это же DOOM! Возможно даже 1-й. А это как минимум 8 лет назад

Даже если брать второй, то уже 9. Второй дум вышел в 95-ом. Ух и резались мы тогда в него.

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

L>Влад, а можно вопрос личного характера?

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

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

Точнее три. Собственно сайту примерно столько лет.

L> Судя по пикче, которая у тебя в профайле же, тебе не очень много лет.

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

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

Ну, тут есть разные варианты. Первное лучше меньше думать. А то можно, например, нашего Алекса Фетодова на соновании вот этого линка http://gzip.rsdn.ru/Info/Team.aspx записать черти в кого.

Во вторых можно быть молодым и серьезным. Или взрослым, но не серьезным. А можно быть взрослым серьезным, но не человеком.

L> По моим прикидкам тебе вряд ли получается больше чем 25-27 лет.

Получается немного больше. Мне сейчас 30. Но не думаю, что это может повлиять на серьезность или не серьезность.

L> Вычтем из этого возраста 2 года, что ты являешься техническим редактором журнала.

Уж незнаю зачем вычитать (хотя конечно было бы не плохо )...

L> Получается, плотно программированием ты занимался максимум до 23-25 лет, т.к.

Ну, точнее 28.

L> после этого ты был уже не программистом.

Это от чего же? Что-же со мной такое произолшо?

L> Думаю, наверняка у тебя высшее образование, т.е. плотно работать ты начал в лучшем случае где-то в 22 года.

Могу назвать год — 94. Было это ровно 10 лет назад.

L> Путем насложной арифметики получаем, что плотно программирование ты занимался не больше 3-х лет.

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

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

О... Мне даже не кажется что мои выводы безапеляционны. А уж прво на выводы я точно считаю главным завоеванием демократии.

ЗЫ

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

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

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

G>Ну кто-то может и двадцать лет этим заниматься, и так и не понять, как такие вещи делать просто. А там на самом деле существует простая технология. Я бы с тобой поделился, но ...

Срадостью полсушал бы. А пока...

VD>> В прочем... похоже ты просто любишь "крикнуть" какую-нибудь глупость по громче, чтобы другие по возмущались.
G>...после такого, не считаю возможным продолжать беседу. Потому как ты совсем охренел.

К сожалению "такое" имеет быть на практике. Ты постоянно делаешь завяления вроде того, что на ИЯ невозможны линивые вычисления, а потом, после того как тебе несколько человек обяснит вто ты не прав, начинаешь доказывать что такого не говорил и вообще тебя все неверно поняли.

Я понимаю, что ФЯ для тебя болеш чем просто парадигма. Понимаю, что человек ты не равнодушный. Это здорово. Но те методы которыми ты пыташся доказать другим свою правоту явно неадекватны и вызвают в слушателях сильное раздражение. Забвно, что я как раз не являюсь противником, но после общения с табой почему-то начинаю их тихо недолюбливать. Странно правда. Более того, я предлагал перейти к человеческим формам популяризации ФЯ. Но дальше чем на одну ветку и маленький и крайне не убедительный документ вас не хватило. Моим словам об окончании флэйма ты с сотоварищами не внял и продолжаешь довольно некачетственную пропоганду. Когда же я называю вещи свими именами ты откровенно обижашся. Ну, уж извините. Я вот такой прямолинейный. Если я вижу рекламу и пропаганду под видом несения в массы разумного, доброго и вечного я так и говрою — реклама и пропаганада.

Заметь как реагируют на твои слова те многие кто видит в ФЯ рациональное зерно, но не является полным приверженцем ФЯ. Через некоторое время они встречаются с безапеляционными спорными заявлениями и попросу уходят. Те немногие что остались уже устали спорить.

ЗЫ

В общем, все эти "базары" действительно нужно прекращать. Если есть желание помочь другим в постижении принципов ФЯ и популяризации идй ФЯ, то нужно сосредоточиться на документе о котором мы говорили. Если у вас не получается создать его самостоятельно, то давайте делать это в интерактивном режиме. Но чур не обижаться на критику, а воспринимать ее как цель создания полноценного убидительного документа. Исходите из того посыла, что если текст покажется убедительным мне, то он будет убедительным и для 80% других императивщиков.

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

G>Знаю. Только известные мне SDL тулзы очень дорогие (кинь ссылки, если знаешь халяву, плз). Но в любом случае, иногда приходится делать КА и руками.

Какие-то тулы перечислены тут http://www.sdl-forum.org/Tools/Shareware.htm
Хотя я не думаю, что они лучше комерческих продуктов. (Что представляют собой комерческие тулы я знаю,у нашего отдела контракт с Telelogic-ом ).
На общественных началах можно разработать front-end к SDL (парсер, внутренее представление, боле-менее приемлемый semantic checker), но все остальное (GUI, code generators, run-time system, etc) делается с большим трудом.Особенно, принимая во внимание требование кроссплатформенности.


G>Да вроде я и так это умею. Но за ссылку все равно спасибо, не знал, что на такие темы книги пишут.

Пишут, но не у нас. И до нас они не доходят, приходится на amazon-е заказывать. Блин, полно литературы для "чайников", но чего-либо серьезного, выходящего за рамки автоматизации бизнес-процессов, практически нема.