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

K>А затем, чтобы не тратить попусту память. Сделать при помощи list comprehension ленивый список (поток по схемовской терминологии) и перебирать его. Вообще-то foreach в немерле — это и есть своеобразный ленивый list comprehension. Но всё-таки сам list comprehension выглядит посиматичнее.

Здесь никакой памяти зря не тратится. Надо все таки понимать как работает GC. А вот зачем лишнее процессорное время тратить не ясно.

Ленивость можно достичь и специальным макросом Lazy. Вот только тут это совершенно не нужно. Здесь даже промежуточных объектов практически не создается (елси не счиать сам итератор). Список обрабатывается полность. Смысл в ленивости ровно нулевой.

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

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

K>>А затем, чтобы не тратить попусту память. Сделать при помощи list comprehension ленивый список (поток по схемовской терминологии) и перебирать его. Вообще-то foreach в немерле — это и есть своеобразный ленивый list comprehension. Но всё-таки сам list comprehension выглядит посиматичнее.

VD>Здесь никакой памяти зря не тратится. Надо все таки понимать как работает GC. А вот зачем лишнее процессорное время тратить не ясно.

Именно это я имел в виду. Зачем зря нагружать GC?

VD>Ленивость можно достичь и специальным макросом Lazy. Вот только тут это совершенно не нужно. Здесь даже промежуточных объектов практически не создается (елси не счиать сам итератор). Список обрабатывается полность. Смысл в ленивости ровно нулевой.

Может не совсем понятно. Попытаюсь объяснить. Вместо чего-то вроде:

foreach (x when x > 5 in list)
{
    doSomething();
}

мне приятнее запись:

foreach (x in [e | e in list, e > 5])
{
    doSomething();
}

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

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

VD>>Здесь никакой памяти зря не тратится. Надо все таки понимать как работает GC. А вот зачем лишнее процессорное время тратить не ясно.

K>Именно это я имел в виду. Зачем зря нагружать GC?

Мне кажется, что ты не понимашь ситуации. Здесь вообще ЖЦ не работает. Да и если бы работал, то все равно метрвые объекты ничего не стоят.

K>Может не совсем понятно. Попытаюсь объяснить. Вместо чего-то вроде:

K>

K>foreach (x when x > 5 in list)
K>{
K>    doSomething();
K>}
K>

K>мне приятнее запись:

K>

K>foreach (x in [e | e in list, e > 5])
K>{
K>    doSomething();
K>}
K>

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

Вообще-то ты просто не понял сути кода. Он не так прост как кажется. В нем происходит обновление хэш-таблицы. Это в принципе императивное действие. Причем оно усугубляется тем, что итератор хэш-таблиц не терпит изменения. Так вот обращение к свойству KeyValuePairs создает массив с копией элементов в следствии чего эта прблема исчезает.

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

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

K>>Именно это я имел в виду. Зачем зря нагружать GC?

VD>Мне кажется, что ты не понимашь ситуации. Здесь вообще ЖЦ не работает. Да и если бы работал, то все равно метрвые объекты ничего не стоят.

Странно. Мне казалось, что при обработке list comprehension создаётся набор пар в куче. А где же ещё?

Много мёртвых объектов просто напросто провоцируют частое срабатываение GC. А это значит нужно пройтись по графу объектов, затем делать дефрагментацию кучи. Т.е. так и так получаем доп. нагрузку, хотя и относительно небольшую в случае с мёртвыми объектами.

[skip]

VD>Вообще-то ты просто не понял сути кода. Он не так прост как кажется. В нем происходит обновление хэш-таблицы. Это в принципе императивное действие. Причем оно усугубляется тем, что итератор хэш-таблиц не терпит изменения. Так вот обращение к свойству KeyValuePairs создает массив с копией элементов в следствии чего эта прблема исчезает.

Да, если бы код не был императивным я бы вообще отказался от foreach и воспользовался map/filter/fold. А так я привык рассматривать foreach как "императивный map" или что-то вроде этого.

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

K>Может не совсем понятно. Попытаюсь объяснить. Вместо чего-то вроде:
K>мне приятнее запись:
А мне приятнее первая запись, и что? Это не аргумент. Тем более, что вторая явно избыточна. А в более сложном случае(таком как пример Влада, с которого это ветка и началась) будет вообще кошмар.

K>Просто в более чистых ФЯ я бы использовал map и локальную функцию, чтобы не писать каждый раз ненужную рекурсию. А Немерле более императивный, потому в нём следует писать по-другому.
Действительно по-другому, на мой взгляд VladD2 в этом примере показал как раз как в нем стоит писать.

K>Однако, если есть вохможность создать ленивый list comprehension, то первый и второй фрагменты скомпилировались в идентичный код. Тогда почему бы не использовать вторую запись? Или даже
Причем здесь ленивость, если ты хочешь идентичный код для первого и второго? При реальной ленивости добиться этого нереально, да и накладные расходы на нее будут скорее всего превышать накладные расходы на создание временного списка.

Что для этого нужно, так это дополнительный сахар в макросе foreach, вроде того что ввели для промежутков(foreach(i in [1..10])), так как list comprehensions в общем-то и так превращаются в самые обычные императивные циклы, а временный список можно и не создавать. Например уже сейчас можно делать так:

$[e | e in lst, e > 5, { doSomething(); false } ]

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

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

K>Странно. Мне казалось, что при обработке list comprehension создаётся набор пар в куче. А где же ещё?

В исходном коде нет никакого list comprehension. Да и если бы был, то примитивные случае часто арзворачиваются в циклы.

K>Много мёртвых объектов просто напросто провоцируют частое срабатываение GC.

"Много" понятие отнтсительное. Много тут просто нет в принципе. А сборка нулевого поколения быстра и если объетов нет, то и времени не отнимает почти.

K> А это значит нужно пройтись по графу объектов,

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

K> затем делать дефрагментацию кучи.

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

Тут же отсуствует предмет разговора.

K>Да, если бы код не был императивным я бы вообще отказался от foreach и воспользовался map/filter/fold.

Где код работает со писками там так и есть. А с хэш-таблицей это бессмысленно и даже вредно. Так то все лаогично.

K> А так я привык рассматривать foreach как "императивный map" или что-то вроде этого.

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

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


ГВ>Дим, как только вокруг нашего дела стали крутиться бабки (даже не так: БАБКИ), сюда столько мусора натащило и ещё натащит, что мама, не горюй.


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

ГВ>Меня, в принципе, одно успокаивает. Сколько бы всяческая шелупонь не надувала щёки, в любом случае сложность задачи и сложность её реализации никуда не денутся — хоть ты галстук надень, хоть распишись в корпоративной верности до третьего колена, хоть сертификатами, как обоями обклейся. Отсюда, собственно, принципиальная невозможность свести программирование к обезъянничанью, как бы этого кому бы то ни было не хотелось. Ну не полетит самолёт с крыльями от Ан-2 (для дешевизны) и двигателем от Ту-144 (для скорости)...


Озвучивал уже как-то, что небольшое количество типов задач наряду с существующими тоннами неуниверсальных решений под них говорит лишь о том, что развитие ПО безбожно отстает от потребностей рынка. Так на уровне библиотек и хелперов и топчемся десяток-другой последних лет. Тут мне говорят иногда, что видите ли, бизнессс-логика-то у всех разная. Гут. Почему же трудоемкость программирования и отладки этой бизнес-логики в реальных проектах дай бог 20%-30% (очень оптимистично)? Не потому ли, что сами проекты пишутся обезьяним методом, по принципу повторного применения в похожих случаях одних и тех же либ похожим образом, вместо попыток сделать качественный шаг вперед?


ГВ>PS.: Проголосовал за выделение твоего сообщения в отдельную ветку. 2All: присоединяйтесь.

Да ну его. Сто раз уже обменивались любезностями по аналогичному поводу.

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

IT>Проблема в том, что мозги императивного программиста повёрнуты на решение задач без всяких делегатов. А дибильные (простите, други, но другого слова не подобрать) примеры из серии list.ForEach() только усугубляют ситуацию, т.к. в импертивном стили они решаются не менее эффективно, а для императивщика выглядят куда проще и понятнее.

IT>Тут надо искать примеры, которые действительно показывают силу ФП, где ФП резко устраняет дублирование кода и делает его намного проще. В принципе, если есть интерес, то такие примеры можно привести.

С удовольствием посмотрел бы на такие примеры. Особенно на C# 2.0.

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

IT>>Тут надо искать примеры, которые действительно показывают силу ФП, где ФП резко устраняет дублирование кода и делает его намного проще. В принципе, если есть интерес, то такие примеры можно привести.

EC>С удовольствием посмотрел бы на такие примеры. Особенно на C# 2.0.

Один пример я приводил здесь

Автор: IT
Дата: 03.10.06

. Вкратце, на анонимных делегатах можно писать многопоточный код синхронизации UI практически линейно:

public delegate void InvokeDelegate();

public void Invoke(InvokeDelegate call)
{
    if (InvokeRequired)
        base.Invoke(call);
    else
        call();
}

string LongProcess(string text)
{
    Thread.Sleep(1000);
    return text;
}

void button1_Click(object sender, EventArgs e)
{
    string   text     = textBox1.Text;
    WaitForm waitForm = new WaitForm();

    new Thread(delegate() // 1
    {
        Exception exception = null;
        string    result    = null;

        try
        {
            result = LongProcess(text);
        }
        catch (Exception ex)
        {
            exception = ex;
        }

        Invoke(delegate() // 2
        {
            waitForm.Close();

            if (exception == null)
                textBox2.Text = result;
            else
                MessageBox.Show(exception.Message);
        });
    }).Start();

    waitForm.ShowDialog();
}

Стандартный путь — объявление отдельных методов для каждого случая. Для этого примера таких методов понадобится два. На практике их обычно оказывается несколько больше. Достаточно сюда добавить код показа состояния работы длительного процесса, например, в StatusBar и всё станет немного сложнее. В WinForms 2.0 появился компонент BackgroundWorker, но его использование мне кажется ещё более неочевидным, запутанным и тяжеловестным для такой простой операции как выполнение длительной задачи в фоновом потоке.

Данный пример также демонстрирует захват контекста анонимными функциями. Так, например, первая анонимная функция захватывает переменную text из основного метода, вторая — waitForm из основного метода, exception и result из первой анонимной функции.

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

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

void FindAndExpand(string name)
{
    // алгоритм обхода дерева.

    // критерий поиска.
    if (node.Name == name)
    {
        // выполняем какие-то действия с найденным узлом.
    }
}

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

void FindAndExpand(Dictionary<string,MyClass> dic)
{
    // алгоритм обхода дерева.

    // критерий поиска.
    if (dic.ContainsKey(node.Name))
    {
        // выполняем какие-то действия с найденным узлом.
    }
}

Что можно сделать, чтобы этого не делать? Можно попробовать использовать в качестве параметра делегат:

void FindAndExpand(Predicate<NodeType> checkNode)
{
    // алгоритм обхода дерева.

    // критерий поиска.
    if (checkNode(node))
    {
        // выполняем какие-то действия с найденным узлом.
    }
}

Варианты использования:

string nodName = "...";

FindAndSetCurrent(delegate(NodeType node) { return node,Name == nodeName; }

Dictionary<string,MyClass> dic = ...;

FindAndSetCurrent(delegate(NodeType node) { return dic.ContainsKey(node,Name); }

Predicate<> — это стандартный делегат, объявленный в System. Там же ещё имеются делегаты Action<T>(T t), Comparison<T>(T x, T y), Converter. Естественно, никто не запрещает использовать таким же образом свои собственные делегаты.

Это пожалуй пока наиболее типичный способ использования анонимных функций в C# 2.0.

Следует заметить, что избавиться от дублирования кода в нашем примере можно и другим, объектно-ориентированным способом:

abstract class FinderExpander
{
    protected abstract bool CheckNode(NodeType node);
    
    void FindAndExpand(Predicate<NodeType> checkNode)
    {
        // алгоритм обхода дерева.

        // критерий поиска.
        if (CheckNode(node))
        {
            // выполняем какие-то действия с найденным узлом.
        }
    }
}

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

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

bool GetNodes(List<NodeType> parents, List<NodeType> nodes, Predicate<NodeType> checkNode)
{
    foreach (NodeType node in nodes)
    {
        if (checkNode(node) || GetNodes(parents, node.Nodes, checkNode)
        {
            parents.Insert(0, node);
            return true;
        }
    }
}

void FindAndExpand(Predicate<NodeType> checkNode)
{
    List<NodeType> parents = new List<NodeType>();

    GetNodes(parents, _tree, checkNodes);
    
    // обходим дерево найдённых узлов parents и раскрываем все ветки.
}

Тоже самое в исполнении Nemerle будет выглядеть примерно следующим образом:

FindAndExpand(checkNode : Predicate[NodeType]) : void
{
    def parents = List<NodeType>();

    def getNodes(nodes)
    {
        foreach (node in nodes)
        {
            when (checkNode(node) || GetNodes(node.Nodes)
            {
                parents.Insert(0, node);
                return true;
            }
        }
    }

    getNodes(_tree);
    
    // обходим дерево найдённых узлов parents и раскрываем все ветки.
}

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

Как я уже заметил выше, иногда в процессе разработки размеры такого метода становятся таковы, что просятся в отдельный класс, что является вполне закономерным решением. Но для небольших методов — приведённый выше пример гораздо предпочтительнее.

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

IT>Тем не менее данный пример не является наиболее часто используемым подходом. Чаще всего лямбды используются в качестве... скажем так, "виртуальных параметров".
Такой подход как раз и использую, бывает, что один и тот же код должен работать с участием пользователя
(показывать MessageBox'ы) и без него, концептуально красиво, но текущий синтаксис тяжеловат — жду C# 3.0.

IT>Тоже самое в исполнении Nemerle будет выглядеть примерно следующим образом:
Коль уж ты его упомянул хочу спросить. У меня сложилось впечатление, что ты человек исключительно практичный:
не страдаешь излишним академизмом и не бросаешься на всё новое и блестящее. Тем не менее ты участвуешь в проекте
по интеграции Nemerle в студию и вообще интересуешься этим языком.
Это просто любопытство/куча свободного времени или ты действительно веришь что у него есть будущее?

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

EC>Это просто любопытство/куча свободного времени или ты действительно веришь что у него есть будущее?

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

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

EC>>Это просто любопытство/куча свободного времени или ты действительно веришь что у него есть будущее?

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

Ты верно процитировал (что обнадёживает), но видимо неправильно понял вопрос и как следствие не ответил на него.
Hint: даже если я попробую и втянусь это не гарантирует Nemerle светлое будущее.
И ещё момент (не восприми превратно): с твоим мнением по данному поводу здесь все уже неоднократно ознакомились ,
интересует мнение именно IT — его подход мне видится более прагматичным.

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

EC>интересует мнение именно IT — его подход мне видится более прагматичным.

+1

ИМХО:
* именно такие люди, как IT и Oyster (жалко, что его не видно в последнее время, на заре обсуждения Nemerle оно очень интересные примеры приводил) и определяют реальное будущее языка. Если уж они за него взялись, значит дело серьезно;
* да, у Nemerle может быть вполне серьезное и достойное будущее на платформе .NET, если только он не превратится в долгострой, как D. Или не станет экпериментальной академической разработкой.

Если бы я работал на .NET, то стал бы использовать Nemerle сразу после выпуска стабильной версии 1.0 (по крайней мере во внутренних проектах).

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

E>* да, у Nemerle может быть вполне серьезное и достойное будущее на платформе .NET, если только он не превратится в долгострой, как D. Или не станет экпериментальной академической разработкой.
Мне кажется, что проблема не в долгостроительстве, а в поддержке корпорацией-монстром.
И я в упор не вижу какой может быть интерес например, у Microsoft, чтобы его двигать.
У них и так зоопарк языков под .NET неплохой.
Плюс Nemerle IMHO слишком навороченный для mainstream'а, а монстры ориентируются именно на него — живут за счёт эффекта масштаба.
Единственный вариант это небольшая компания, двигающая его, дающая платный саппорт.
Типа как со SmallTalk'ом — есть несколько вендоров, сообщество разработчиков для которых это отличный инструмент,
т.е. есть какие-то гарантии с позиции бизнеса в том, что продукт будет жить и в случае возникновения проблем есть к кому обратиться.

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

E>>* да, у Nemerle может быть вполне серьезное и достойное будущее на платформе .NET, если только он не превратится в долгострой, как D. Или не станет экпериментальной академической разработкой.
EC>Мне кажется, что проблема не в долгостроительстве, а в поддержке корпорацией-монстром.
EC>И я в упор не вижу какой может быть интерес например, у Microsoft, чтобы его двигать.

В случае хорошей идеи и реализации поддержка корпораций-монстров не обязательна. Примеры Perl, Python, Ruby, Lua и пр. это подтверждают. Можно вспомнить еще и Linux, в который IBM начала вкладывать миллиарды уже после того, как Linux доказал свое право жизни под солнцем.

EC>У них и так зоопарк языков под .NET неплохой.

Имхо, это их главное преимущество перед Sun. Ведь Sun сейчас старается сделать JVM платформой для других языков, для этого они и JRuby под свое крыло берут.

EC>Плюс Nemerle IMHO слишком навороченный для mainstream'а, а монстры ориентируются именно на него — живут за счёт эффекта масштаба.

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

EC>Единственный вариант это небольшая компания, двигающая его, дающая платный саппорт.

Такой вариант так же возможен.

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

EC>>>Это просто любопытство/куча свободного времени или ты действительно веришь что у него есть будущее?

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

EC>Ты верно процитировал (что обнадёживает), но видимо неправильно понял вопрос и как следствие не ответил на него.
EC>Hint: даже если я попробую и втянусь это не гарантирует Nemerle светлое будущее.
EC>И ещё момент (не восприми превратно): с твоим мнением по данному поводу здесь все уже неоднократно ознакомились ,
EC>интересует мнение именно IT — его подход мне видится более прагматичным.

Хочешь посмеяться? Тогда прочти то что я тебе написал. Прочти процетированное, а потом прочти то что написал ты.

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

EC>>интересует мнение именно IT — его подход мне видится более прагматичным.

E>+1

E>ИМХО:
E>* именно такие люди, как IT и Oyster (жалко, что его не видно в последнее время, на заре обсуждения Nemerle оно очень интересные примеры приводил) и определяют реальное будущее языка. Если уж они за него взялись, значит дело серьезно;
E>* да, у Nemerle может быть вполне серьезное и достойное будущее на платформе .NET, если только он не превратится в долгострой, как D. Или не станет экпериментальной академической разработкой.

E>Если бы я работал на .NET, то стал бы использовать Nemerle сразу после выпуска стабильной версии 1.0 (по крайней мере во внутренних проектах).

Одно не пойму, если по твоим же словам твое мнение никого не интересует (тут я с тобой согласен), то что ты его высказываешь?

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

EC>Единственный вариант это небольшая компания, двигающая его, дающая платный саппорт.
EC>Типа как со SmallTalk'ом — есть несколько вендоров, сообщество разработчиков для которых это отличный инструмент,

Бог даст такого не случится. Судба СТ явно не завидная.

EC>т.е. есть какие-то гарантии с позиции бизнеса в том, что продукт будет жить и в случае возникновения проблем есть к кому обратиться.

Такой проблемы нет в принципе. Обратиться и так есть куда. В "Декларативном программирований" добрая половина вопросов по этому языку. Плюс на английском можно обращаться к самим разработчикам. Да и кроме них там специалистов высогого класса хватает. А открытость проекта и отличная лицензия позвляют быть спокойным за судьбу кода.

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

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Есть. Ты забываешь про лес и выделяешь деревья. Win2K очень много дельного говорит (как и камрад Kolhoz). Не знаю, зачем это ему нужно. Может быть, его тоже достал "майнстрим" со своими амбициями? Я вот ничего оскорбительного в его словах не вижу
S>а ты сходи постинги его почитай. Квалификация у чувака есть, но от так тщательно маскирует ее за ведрами помоев, что трудно разглядеть. И уж успешность его в жизни — не знаю, личной там или профессиональной, — вызывает обоснованные сомнения. Влад верно заметил — те, кто чувствует себя комфортно и достиг успеха, не бегают на форумы собеседников в умственной отсталости обвинять.
Да нет, просто есть категория людей которых прикалывает стебаться.
Вот они намеренно и провоцируют людей — это есть тролли. И грамотные тролли как раз высказывают подчас верные (ну или по крайней мере имеющие право на существование) мысли но в провокационной форме и тем самым провоцируют флейм.

Ну а у неграмотных не получается

Автор: quadrochups
Дата: 05.10.06

(не соблюдают баланс между содержанием и провокационностью) — над ними просто смеются и ставят "-".

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

EC>Это просто любопытство/куча свободного времени или ты действительно веришь что у него есть будущее?

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

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

Что касается самого языка, то именно как у языка у него сейчас конкурентов просто нет (ИМХО, конечно). Это для меня самого было большим сюрпризом, и чем больше я на нём пишу, тем больше готов это утверждать. И это ещё даже не воспользовавшись ни разу тяжёлой артиллерией в виде макросов. А уж с макросами...