Приходилось ли вам писать на Лиспе?

>Или анонимусы вообще на опенсорс не работают, а заняты только деланием денег?

Анабиоз у Вас был долгий с 180 года и под личным контролем Столлмана. Ну все же уже знают, что ОпенСорс давно делается за зарплаты на полном рабочем дне. Есть конечно энтузиасты, но всё уже давно схвачено серьёзными дядями.

> Нет, unless это часть стандарта. Просто её можно было бы реализовать в библиотеки, видимо это имелось в виду, когда было сказано, что это библиотека.

Именно так. В sbcl ЕМНИП (archimag поправит если не так) unless и реализована в библиотеке, а не встроена в компилятор.

Совсем забыл. Патчи в опенсурсном JavaTest'е мои есть.

>Приветствуются развернутые ответы и верифицируемые пруфлинки

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

> Автор Kuka, открывший тему, наверняка уже много раз получил

глубочайшее удовлетворение развёрнутостью ответов.

От меня он их кажется получил. За других говорить не привык.

Вот практическая задача прочитать ХМЛ файл и записать в него факториалы там, где поле результата не заполнено, есть только поле данных. Расскажите про мощь Лиспа или Хаскела, которые уделают по скорости разработки и скорости выполнения всякие там Явы с Диезами. Или тоже самое с реляционной БД, где вместо файла ХМЛ таблица.

using System.Xml;

namespace App
{
    class Program
    {
        static int Fact(int x)
        {
            if (x <= 1) return 1;
            int result = 1;
            for (; x > 1; x--)
                result *= x;
            return result;
        }

        static void Main()
        {
            var doc = new XmlDocument();

            doc.Load("input.xml");
            XmlNode mainNode = doc.GetElementsByTagName("factorials")[0];

            foreach (XmlNode node in mainNode)
                if (string.IsNullOrEmpty(node.InnerText))
                    node.InnerText = Fact(int.Parse(node.Attributes["x"].Value)).ToString();

            doc.Save("output.xml");
        }
    }
}

На входе имеем

<?xml version="1.0"?>
<factorials>
  <field x="2"></field>
  <field x="4"></field>
  <field x="7"></field>
</factorials>

на выходе

<?xml version="1.0"?>
<factorials>
  <field x="2">2</field>
  <field x="4">24</field>
  <field x="7">5040</field>
</factorials>

>А анонимусы признаваться не будут?
Я про себя уже выше отписал.

Просто, коротко и легко читаемо. Как же теперь лисперы будут отмазываться?

Отмазываться? Гы...

(defun factorial (n)
  (iter (for x from 1 to n)
        (multiply x)))

(xtree:with-parse-document (doc #P"/path/to/input.xml")
  (iter (for node in-child-nodes (xtree:root doc) with (:type :xml-element-node))
        (setf (xtree:text-content node)
              (write-to-string (factorial (parse-integer (xtree:attribute-value node "x"))))))
  (xtree:serialize doc #P"/path/to/output.xml"))

perl с C уже не справляются? Подтянули C#? Если Лисп достаточно хорош в тех случаях, когда без него приходится использовать три совершенно разных языка, то он действительно является отличным инструментом.

Подтянули C#?

Пишу на том, что знаю.

И где тут читаемость? Где там проверка на пустой текст? Оно же не читаемо. А места занимает столько же.

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

Где преимущество лиспа?

Мдя, 94 символа в ряд, лишь бы только не добавить новую строку...

xtree - это опять всё внешнее? Оно цепляется автоматом или нужно какие-то include'ы делать? Если да, то пишите всю программу полностью, как писали для perl, для C#.

>> Подтянули C#?

Пишу на том, что знаю.

Это не вам упрёк, а анонимусам, которые сейчас начнут «доказывать» ущербность Лиспа в обработке XML. Ещё бы написали специальный язык (вроде HQ9+), с ровно одним оператором «расставить факториалы в XML файле» и брызгали слюнями, что в их замечательном языке эта задача в один символ решается, а Лисп по этой причине не нужен.

> И где тут читаемость? ... Оно же не читаемо.

Что не так с читаемостью? Читается на самом деле отлично. При чём, опять можно читать как просто текст на английском и всё понять.

Где там проверка на пустой текст?

Да, извиняюсь, забыл, поверите что это надо добавить одну строку?

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

> Где преимущество лиспа?

На этой задаче? Ну, например, могу обратить на универсальное использование конструкции iterate, которая позволяет перебирать и узлы DOM-дерева без каких-либо дополнительных действий, при чём, сам макрос iterate об этом совершенно не в курсе.

Но задача слишком проста, и xml входной слишком прост. Как насчёт того, что бы написать расширение, например новую XPath-функцию или новый элемент для XSLT-процессора?

Ну так приведите полный законченный текст, с проверкой пустоты, со вмеми включениями типа include using или что там в Лиспе есть.

Что не так с читаемостью? Читается на самом деле отлично

Неправда. Я, как сторонний наблюдатель (с опытом C++ (но не C#), справедливости раде замечу), C# вариант выглядит понятнее и читабельнее. Конкретно в твоём коде неясность оставляют строки:

  (iter (for node in-child-nodes (xtree:root doc) with (:type :xml-element-node)) 
        (setf (xtree:text-content node) 

Где преимущество C#?

За 17 страниц анонимусам так и не удалось доказать ненужность Лиспа, как не удалось доказать и заменяемость всех языков им, несмотря на все их старания. Поэтому, советую всем последовать совету одного из них: http://www.linux.org.ru/jump-message.jsp?msgid=4513948&cid=4516202

Да возрадуются лисперы за шарпистов, а шарписты за лисперов и мирно пойдут спать!

> Я, как сторонний наблюдатель (с опытом C++

У вас предвзятое мнение. Мне оба примера показались одинаково читаемыми, но в Лиспе явно используются более мощные абстракции.

Так xtree это ж похоже что Ваша собственная разработка. Что за обманы??

>За 17 страниц анонимусам так и не удалось доказать ненужность Лиспа, как не удалось доказать и заменяемость всех языков им, несмотря на все их старания. Поэтому, советую всем последовать совету одного из них: http://www.linux.org.ru/jump-message.jsp?msgid=4513948&cid=4516202

Да возрадуются лисперы за шарпистов, а шарписты за лисперов и мирно пойдут спать!

+1. Предлагаю закончить дискуссию и пойти спать.

На этой задаче? Ну, например, могу обратить на универсальное использование конструкции iterate, которая позволяет перебирать и узлы DOM-дерева без каких-либо дополнительных действий, при чём, сам макрос iterate об этом совершенно не в курсе.

Не знаю, что значит в лиспе iterate, но подозреваю, что то же самое (или почти то же самое), что foreach в шарпе. И, да, foreach позволяет перебирать узлы DOM-дерева, как ты написал, да и вообще любой коллекции... да и вообще чего угодно, что реализует интерфейс IEnumerable, т.е. по сути отвечает некоторым требованиям и возвращает итератор. Это может быть и встроенная конструкция (например, массив, генератор, сопрограмма), что-то из стандартной библиотеки (BCL), пользовательский тип. К тому же foreach - это мелочь по сравнению с такой прелестью как Linq. Описывать слишком долго, потому лучше глянь в википедии, если интересно.

Но задача слишком проста, и xml входной слишком прост. Как насчёт того, что бы написать расширение, например новую XPath-функцию или новый элемент для XSLT-процессора?

Я, к сожалению, не знаю ни XPath, ни XSLT.

Забавно, что каждая сторона принимала точку зрения оппонента за более радикальную, чем она есть на самом деле.
Анонимусы: «Лисп - не панацея», что было воспринято как «Лисп не нужен».
Лисперы: «Лисп нужен», что было воспринято как «Лисп - панацея».

Если бы оппоненты внимательнее читали друг друга, то можно было бы за пару страниц сойтись на мнении, что «Лисп нужен, но не является решением *всех* проблем». :)

Можно какой-нить парсер написать для эксперимента.

Хотя, справедливости ради, стоит упомянуть, что как минимум один анонимус таки пытался утверждать, что «Лисп не нужен».

> Так xtree это ж похоже что Ваша собственная разработка.

Что за обманы??

В чём обман?

да и вообще чего угодно, что реализует интерфейс IEnumerable

Вот это мне никогда не нравилось, ради каждого чиха интерфейсы плодить.

Я, к сожалению, не знаю ни XPath, ни XSLT.

А я думал что в ентерпрайз любят XML. Вообще, тут хотелось бы понять, позволяет ли C# писать расширения для XPath и XSLT?

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

Привлеките Waterlaz'а с Хаскелем и меня со Схемой. Парсер - это всегда интересно.

Вот это мне никогда не нравилось, ради каждого чиха интерфейсы плодить.

А как твой iterate определит, что и как обходить? Для того и нужен интерфейс, чтобы это было определено. foreach знает, что у любой сущности, реализующей IEnumerable, есть метод возвращающий итератор - и этого достаточно.

Ну что сказать. Объём текста одинаковый. Но C# гораздо читаемее. Соответствует человеческому языку.
Но если xtree это Ваша разработка, то тогда круче всего С++:

int main(int, char**)
{
   FillFactorials("input.xml", "output.xml");
   return 0;
}

А я думал что в ентерпрайз любят XML. Вообще, тут хотелось бы понять, позволяет ли C# писать расширения для XPath и XSLT?

XML использовал, XSD тоже. В больщем потребности не возникало. Так получилось.

> А как твой iterate определит, что и как обходить?

Для того и нужен интерфейс

А туда можно передать дополнительные опции? У меня в in-child-nodes есть раздел в котором можно указать несколько различных критериев для фильтрования, типа пространства имён, имени тэга или произвольного условия. Достигается это один макросом, который определяет не интерфейс, а синтаксическую конструкцию in-child-nodes, которая может быть произвольно степени сложности.

XML использовал, XSD тоже. В больщем потребности не возникало.

Так получилось.

Вы серьёзно? Как можно работать с более-менее серьёзным XML без XPath? Это же адский труд...

> Но если xtree это Ваша разработка, то тогда круче всего С++:

Хм. Общедоступная (и включённая например в gentoo-lisp-overlay) высокоуровневая обёртка над libxml2 под запретом?

Приведите, пожалукйста, весь текст на Лиспе вместе с вашим xtree. Интересно посмотреть, во сколько раз там будет больше строк и оценить во сколько раз потребовалось бы больше времени на написание этого кода, чем на С#. Ведь сливает ваш Лисп в данном примере с ХМЛ.

>бщедоступная (и включённая например в gentoo-lisp-overlay) высокоуровневая обёртка над libxml2 под запретом?

Значит в затраты на разработку этого кода (и в текст) для факториалов надо включить затраты на написание вашего xtree.

Так и я могу написать вызов своей функции FillFactorials(file1, file2) вообще одной строкой и за несколько секунд. Для проекта она будет общедоступная и написанная ранее.

А туда можно передать дополнительные опции? У меня в in-child-nodes есть раздел в котором можно указать несколько различных критериев для фильтрования, типа пространства имён, имени тэга или произвольного условия. Достигается это один макросом, который определяет не интерфейс, а синтаксическую конструкцию in-child-nodes, которая может быть произвольно степени сложности.

Никаких опций передать нельзя. Единственное, что можно сделать, это получить итератор, а потом его дёргать, получая последовательно элементы коллекции. А что делать, если нужно фильтровать? Нужно фильтровать!

Пример #1. Массив из пяти элементов. Создаём его и выводим в консоль.

var arr = new[] {2, 4, 6, 8, 10};
foreach (int x in arr) Console.WriteLine(x);

Пример #2. Генератор, чудесным образом создающий пять чисел. Тоже выводим на консоль.

Сам генератор:

static IEnumerable<int> Generator()
{
    yield return 2;
    yield return 4;
    yield return 6;
    yield return 8;
    yield return 10;
}

Выводим:

foreach (int x in Generator()) Console.WriteLine(x);

Пример #3. Фильтруем. Получим последовательность чисел, не делящихся нацело на три.

var result = from x in Generator()
    where x % 3 != 0
    select x;

foreach (int x in result) Console.WriteLine(x);

Ну и т.д.

Вы серьёзно? Как можно работать с более-менее серьёзным XML без XPath? Это же адский труд...

Я не работаю с более-менее серьёзным XML. Я работаю с примитивным XML вроде того, что приведён выше.

> Приведите, пожалукйста, весь текст на Лиспе вместе с вашим xtree.

Издеваетесь? Могу разве что предложить сравнить функционал и размер исходного кода cl-libxml2 и питоновского lxml, на который я во много ориентировался при разработке.

Значит в затраты на разработку этого кода (и в текст) для

факториалов надо включить затраты на написание вашего xtree.

Я не пойму, я не могу использовать open-source библиотеки, которые я разрабатываю или когда-либо патчил? Или вы также предлагаете включить в C# версию исходники XmlDocument?

> А что делать, если нужно фильтровать? Нужно фильтровать!

Ну вот здесь и начинают проявляться преимущества CL :)

Я работаю с примитивным XML вроде того, что приведён выше.

Хм. А зачем такие нужны?

Ну вот здесь и начинают проявляться преимущества CL :)

Не вижу преимуществ. Другой подход, но результат тот же.

Хм. А зачем такие нужны?

Хранить настройки приложения, пары ключ-значения для переводов на разные языки, etc. Вобщем, ничего серьёзного.

>Я не пойму, я не могу использовать open-source библиотеки, которые я разрабатываю или когда-либо патчил?

А на Жабе или С++ или C# в проекте разве нельзя использовать библиотеки самого проекта?

Тогда задача с факториалами решается элементарно одной строкой с 1 вызовом из библиотеки. Круче быть просто не может. И так со всем остальным. Адреса посчитать в файле? Тоже одна строка, вызов функции int r = CountAddress(«log», «3.3.3.3»); Проще быть не может.

Господа, что приутихли? У меня ещё 3 пачки чипсов. Побольше эмоций, агрессии.

Если бы оппоненты внимательнее читали друг друга, то можно было бы за пару страниц сойтись на мнении, что «Лисп нужен, но не является решением *всех* проблем». :)

Если бы оппоненты стремились за пару страниц сойтись на мнении, то это был бы и близко не ЛОР.

Нет, и не собираюсь

Включая запятую и центы. Понел?