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

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

Я же уже скзал. Нужно сфорировать нормальный документ способный привлечь к проблеме тех кто пока не видит смысла в ФЯ. Форум для 5 человек сформировавшихся здесь мало интересен.

Принципиальное решение уже принято. И команда, и комьюнити за. Хотя команда далеко не единогласна.

Поверьте мне на слово, что без качественной затравки в виде статейки ничего хорошего не выйдет.

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

INT>Подумалось, кстати, что в этом смысле ФОП похоже на ООП. Т.е. в функциональом стиле, как и в объектном, можно программировать почти на всех неспециализированных языках. А ОО или ФО языки — это просто языки, семантика и прагматика которых ориентированы на соответствующий подход. Кстати, ООП и ФОП похожи еще в том смысле, что первый является эффективнысм инструментом манипулирования и инкапсулирования с точки зрения структур данных, а второй — с точки зрения алгоритмов.

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

Более того если приглядеться, то языки делаются интересными какими-то фичами и их сочетанием (сбалансированностью).

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

G>Ты уверен, что я до этой мысли додуматься не мог, а не до того, что Синклер понимает под "ленивостью" итератора?

А ты уверен, что понял? А то последующие посты твои наводят на обратную мысль.

G>Кстати, почему ты объясняешь мне после того, как я додумался, а не до? Сейчас объяснять уже ничего не надо

А ты поднимись по веточке вверх...

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

E>Так-то вот. Пожалуй пора и Фортран зачислять в функциональные языки...

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

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

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

http://caml.inria.fr/Examples/oc/camltk/addition.ml. Что-то мне подсказывает, что вариант C# будет все-таки попрощще. Что, в общем-то, неудивительно.

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

INT>Счет в целых числах, вывод error, если обе строчки — не целые числа или пустая строка, кнопка Quit, закрывающая приложение.

Если я правильно понял задачу (разобрать все эит кракозябры я так и не смог), то примерно так:

using System;
using System.Drawing;
using System.Windows.Forms;

class Form1 : Form
{
    private Label   _result      = new Label();
    private TextBox _textBoxVal1 = new TextBox();
    private TextBox _textBoxVal2 = new TextBox();
    private Label   _label2      = new Label();
    private Label   _label3      = new Label();
    private Button  _calc        = new Button();
    private Button  _quit        = new Button();

    public Form1()
    {
        _result.SetBounds(21, 24, 35, 14);
        _textBoxVal1.SetBounds(74, 24, 72, 20);
        _textBoxVal2.SetBounds(170, 24, 70, 20);
        _label2.SetBounds(56, 24, 11, 14);
        _label3.SetBounds(152, 27, 11, 14);
        _calc.SetBounds(247, 24, 66, 22);
        _quit.SetBounds(247, 54, 66, 22);
        ClientSize = new Size(354, 80);

        _textBoxVal1.Text = "1";
        _textBoxVal2.Text = "2";
        _calc.Text        = "&Calc";
        _quit.Text        = "&Quit";

        _quit.Click += delegate(object sender, EventArgs e) { Close(); };
        _calc.Click += delegate(object sender, EventArgs e)
        {
            try
            {
                _result.Text = (int.Parse(_textBoxVal1.Text)
                                + int.Parse(_textBoxVal2.Text)).ToString();
            }
            catch
            {
                _result.Text = "Error";
            }
        };

        Controls.AddRange(new Control[]
        {_quit, _calc, _label3, _label2, _textBoxVal2, _textBoxVal1, _result});
    }
}

Если не короче, то точно понятнее. А если учесть, что в рельной жизни все делается визуально и писать нужно только:

            try
            {
                _result.Text = (int.Parse(_textBoxVal1.Text)
                                + int.Parse(_textBoxVal2.Text)).ToString();
            }
            catch
            {
                _result.Text = "Error";
            }

то вообще говорить не очем.

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

G>Прикольно. Так работают все G-машины, или это зависит от реализации? Пришлешь ссылки?

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

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

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

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

Q>>Реально, императивные места встречаются редко и их легко отследить.

VD>Рельно и на Окамле, и на Шарпе можно нафигачить такой обратной связи на этих самых побочных эффектах, что "мама не горюй". Но если отбросить предположение, что программировать должны дебилы, то станет понятно, что это гипертрофированные страхи не имеющие ничего с рельной жизнью. Побочные эффекты в функциях это плохо и их избегают все грамотные люди. А побочные эффекты в методах — это то ради чего они созданы и глупо их баяться.

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

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

VD>Ты утверждаешь, что на ФЯ нельзя создать линивых вычислений. Вот тебе пример примитивного варианта:

VD>

VD>class A
VD>{
VD>    int _value = 0;
VD>    public void Next() { ++_value; }
VD>    public int Current() { return _value; }
VD>}

VD>...

VD>A a = new A();
VD>for (;;a.Next())
VD>{
VD>    ... a.Current() ...
VD>}
VD>

VD>Что это по твоему не линивые вычисления? Нужно обязательно создать список из всех допустимых значений?

VD>Ну, раз линивые, то закроем этот спор. Признай что сморозил глупость.

Естественно, в С# можно эмулировать ленивые вычисления, точно так же, как на ассемблере можно писать в объектно ориентированном стиле. Вопрос насколько это красиво, удобно и понятно. Ленивые вычисления в Haskell'е врожденная черта. Чтобы ими пользоваться не нужно предпринимать никаких дополнительных действий, думать как да что. Вот, например, вычисление простых чисел методом решета:

nums = [2..] -- бесконечный список чисел начиная с 2 
sieve (head:tail) = head : sieve (filter (\x -> if x `mod` head = 0 then False else True) tail) 
-- просеивание списка, (\x -> if x `mod` head = 0 then False else True) - это функция, которая
-- возвращает False, если x делится нацело на head и True иначе. filter - это функция, которая
-- фильтрует список tail c помощью указанной функции. После чего просеивание производится по отношению
-- к новому списку, из которого удалены все элементы, делящиеся на head,
primes = sieve nums -- все простые числа

Во всех этих 3-х строках кода неявно подразумевается ленивость вычислений. В реальности ни списки не будут бесконечно большими, ни filter не будет обрабатывать весь список и sieve тоже.

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

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

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

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

From: Gaperton http://www.livejournal.com/users/gaperton
>Так работают все G-машины, или это зависит от реализации? Пришлешь ссылки?

А можно ссылку на G-машину?

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

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

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

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

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

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

X>>Безотносительно к теме спора, конкретно вот это высказывание напоминает споры C/С++/Pascal vs assembler несколько лет назад — "на ассемблере и макросах можно сделать все то же, что и на С++, даже лучше"

VD>Если ты заметил я даже не заикался об удобстве. Просто раздражает откровенный гон о том, что можно и чего нельзя.
Ты как в очередной раз споришь сам с собой, выдумывая что говорит собеседник. Это на самом деле начинает уже раздражать. Никто не говорил про "нельзя". Речь о том, что ленивые вызовы опасны при наличии побочных эффектов. Может ты начнешь наконец тратить время на чтение сообщений?

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

ON>From: Gaperton http://www.livejournal.com/users/gaperton
>>Так работают все G-машины, или это зависит от реализации? Пришлешь ссылки?

ON>А можно ссылку на G-машину?

Припоминаю только описание STG-машины
http://citeseer.ist.psu.edu/peytonjones92implementing.html
Есть еще обзорная статья по абстрактным машинам
http://citeseer.ist.psu.edu/diehl00abstract.html

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

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

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

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

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

G>>Дорогой Влад, последние 6 лет я в составе команды человек в 20 занимался разработкой и поддержкой клиент серверного приложения объемом ~60 мегабайт кода (это 3-5 миллионов строк, не считая комментариев и пустых) написанного на С++, из которых 18 — моя зона ответственности. И это не какой-нибудь простой препроцессор, а сервер своей базы данных, интерпретатор всроенного языка, обработка потока котировок в реальном времени, и еще куча всего.

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

G>>Поверь мне, я знаю, какие проблемы бывают на практике, а каких не бывает. И каждый, кто учавствовал в проектах размером от 100 тыщ строк, знает, какие интересные эффекты начинаются. И неделя на один дефект — это ерунда, Влад, это типичная ситуация. А бывает месяц вдвоем на один дефект. А бывает два месяца — и никакого результата.
VD>Ну, прям обучение неумелого щенка не тыкаться носом в стену. Поверь участвал я в более менее больших проектах. Не 60 мег но все же. И проблемы видел. То что ты все время говоришь о плюсах и о своем неудачном опитые всего лишь говорит о том, что твои скилы на плюсах меньше чем нужно чтобы решить данную проблему.
Я эксперт по С++ . И ведущий специалист компании по архитектуре данного приложения, sardonix не даст соврать. Работает оно великолепно, Влад, для приложения такого объема написанного на С++. Опыт у нас исключительно положительный. И за последние 5 лет накоплена большая статистика по дефектам production-а, чтобы можно было достоверно говорить о причинах этих дефектов. Через меня и мою группу их прошла примерно тысяча (часть которых была вызвана тем, что SQA запутались в требованиях) — точно посмотреть не могу, т. к. пишу из дома.

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

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

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

VD> Сложность заключалась в том, чтобы понять ситуацию. А вот с побочными эффектами и прочей лабудой о которой ты все время толдычешь пролем нет! Дольше 5 митут на отладку подобных проблем у меня не уходит. Так что оставь эти песни для других.
Понятно. На поддержке никогда не сидел. Функционала в чужой старый код большого объема не добавлял.

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

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

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

VD>Ну, прям обучение неумелого щенка не тыкаться носом в стену. Поверь участвал я в более менее больших проектах. Не 60 мег но все же. И проблемы видел. То что ты все время говоришь о плюсах и о своем неудачном опитые всего лишь говорит о том, что твои скилы на плюсах меньше чем нужно чтобы решить данную проблему. Собственно я даже не спорю, что писать большие проекты на С++ задача не простая. И что С++ вообще не самый лучший язык с точки зрения простоты и отладки. Но на плюсах свет клином не сошелся. Есть и дуругие языки у которых нет такого вороха проблем и такой сложности. Ты все время давишь на сложность отладки. А я за последние годы за отладкой больше двух часов к ряду (над одной проблемой) не сидел. Причем если засиживался дольше минуты, то это были сложные зависимости в алгоритмах. Сложность заключалась в том, чтобы понять ситуацию. А вот с побочными эффектами и прочей лабудой о которой ты все время толдычешь пролем нет! Дольше 5 митут на отладку подобных проблем у меня не уходит. Так что оставь эти песни для других.

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

У тебя в профайле написано, что ты являешься техническим редактором журнала и насколько я помню, это у тебя в профайле по крайней пере пару лет уже записано. Судя по пикче, которая у тебя в профайле же, тебе не очень много лет. Думаю вряд ли взрослый серьезный человек будет в качестве своего фото пихать картинку из компьютерной игры. По моим прикидкам тебе вряд ли получается больше чем 25-27 лет. Вычтем из этого возраста 2 года, что ты являешься техническим редактором журнала. Получается, плотно программированием ты занимался максимум до 23-25 лет, т.к. после этого ты был уже не программистом. Думаю, наверняка у тебя высшее образование, т.е. плотно работать ты начал в лучшем случае где-то в 22 года. Путем насложной арифметики получаем, что плотно программирование ты занимался не больше 3-х лет.

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

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

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

VD>>>И сколько ты их собрал за свою жизнь?
G>>Штук 20, начиная от самых простых (маленький магазин), до достаточно сложных (магазин с полным набором торгового оборудования, оптовая торговля, производство). Примеры — Stentor, фабрика спортивных изделий Leco, издательский дом IST. Занимался этим три года, с 1997 по 1999. Еще вопросы?

VD>Что-то не верится судя по словам. Я этим занимался лет 7 и прекрасно знаю, что создать достойную учетную систему задача непростая.
Ну кто-то может и двадцать лет этим заниматься, и так и не понять, как такие вещи делать просто. А там на самом деле существует простая технология. Я бы с тобой поделился, но ...
VD> В прочем... похоже ты просто любишь "крикнуть" какую-нибудь глупость по громче, чтобы другие по возмущались.
...после такого, не считаю возможным продолжать беседу. Потому как ты совсем охренел.

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

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

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

VD>>>>И сколько ты их собрал за свою жизнь?
G>>>Штук 20, начиная от самых простых (маленький магазин), до достаточно сложных (магазин с полным набором торгового оборудования, оптовая торговля, производство). Примеры — Stentor, фабрика спортивных изделий Leco, издательский дом IST. Занимался этим три года, с 1997 по 1999. Еще вопросы?

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

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



О как у вас все запущено.

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

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

У меня появилось нестерпимое желание вставить свои пять копеек в этот очень интересный разговор, что я сейчас и сделаю

Вот несколько мыслей о жизни, все ИМХО, и если я не прав, поправте меня.

Начну из далека. Как всем хорошо известно, совпеменное ПО характеризуется высокой сложностью. Разрешить сложность таких систем можно с помощью декомпозиции их на мелкие и следовательно простые части. Эту самую декомпозицию можно проводить различными способами, причем задача декомпозиции сама по себе весьма нетривиальна. Исторически первым подходом к решению данной проблемы была структурная декомпозиция. Поначалу всё было хорошо, и все были довольны. Но время шло и ПО становилось все сложнее и сложнее. Выяснилось, что сделать эффективную декомпозицию сложной системы с помощью структурного подхода крайне трудно. Поэтому, был предложен объектно-ориентированный сбособ декомпозиции сложной системы, имеющий ряд весомых преимуществ по сравнению со стуктурным. На данный момент, ООД является доминирующим подходом, что будет дальше неизвестно. Напомню вкраце основные принципы ООП. Система состоит из объектов и каждый объект имеет изменяемое состояние. Он может посылать сообщения другим объектам и тем самым вызывать изменение их состояния.

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

Читая эту ветку, у меня сложилось впечатление, что основной лейтмотив защитников ФЯ таков: "ввиду наличия состояний программы написанной на императивном языке, её труднее отлаживать и сопровождать, поэтому надо перейти к ФЯ, лишенных этих недостатков". Можно провести аналогию с таким утверждением: "Автомобили загрязняют атмосферу, поэтому надо перейти на велосипеды". Эти утверждения выглядят вполне логично, но есть одно "НО". Можно ли применять велосипеды в той же мере, в какой применяются автомобили? Очевидно, что не всегда. Но можно говорить о рамках применимости. Это же касается и ФЯ. Так, например, я считаю, что ФЯ плохо подходят для разработки мощного текстового редактора, типа ворда (я не имею ввиду "экстремальный спорт", понятно что "раком" можно и до Китая доскакать).

И еще пара замечаний.

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

2) Человек мыслит императивно. Если у Вас спросить, как приготовить чай, что вы ответите? Вы опишете последовательность действий: налить в чайник воду, вскипятить и пр. Врядли кто-то опишет набор функций,каскадный вызов которых приведет к появлению чая. То есть ИЯ ближе к человеческому мышлению, и, следовательно,более доступны ему.