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

> Можно конечно возразить, что это всё функции, а не элемент синтаксиса.

Нельзя. Большая часть (for, in-file, #P, using, #') элементы синтаксиса.

и да, почему Вы в перле забыли <, >, /, $, ++ ?

никакого намека на _строчку_

Да, это из области «некоторые специфичные трюки» perl, переменная по умолчанию ($_); Для удобного чтения кода с ней, нужно «заточить» мозг на perl, потом становится приятно читать.

и зачем вообще читающему об этом задумываться? а задумываться приходится =)

Если не нравится явный счётчик, можно писать как предложил idle:

scalar grep /^192\.168/, <$fh>;

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

sub readFile {
    my ($htdocsPath) = @_;

    my ($text, $line);
    open (TXT, '<', $cfg->{rootHtdocs} . $htdocsPath) or return undef;
    $text .= $line while ($line = <TXT>);
    close (TXT);

    return $text;
}

# эта функция получает на входе путь от корня htdocs, читает файл по пути и возвращает его в результате
sub readFile {
    my ($text);
    open (TXT, '<', $cfg->{rootHtdocs} . $_[0]) or return undef;
    $text .= $_ while (<TXT>);
    return $text;
}

В-третьих, да, я думаю, что когда я пишу open-source код я в любом случае делаю доброе дело для человечества.
А что хорошего для человечества делаете вы?

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

И лично про меня - тоже пишу open-source, пишу свободную документацию по GNU, его настройке, пишу патчи для свободного ПО. Совсем недавно, например, пофиксил 3 бага в vim (они уже в svn).

ну хорошо, что можно короче, я ж не админ, но даже cat grep wc проще, чем лисп машины запускать

> Но тогда вылазят две неприятные особенности: непонятно закрылся ли файл и кем, непонятно что возвращает функция в результате.

как всё в перле неоднозначно и непонятно оказывается... =)

Ну тем более. Получаем, что perl проще.

потому что это само собой разумеющиеся вещи, в отличие от мозговырывательных #'

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

Если бы чаще заходили на форум, то наверняка бы заметили, что я тут последние два месяца только тем и занимаюсь, что CL это вообще никакой на функциональный язык?

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

>в лиспе: iter, for, in-file, #P, using, #', unless, ppcre:scan в перле: open, while, unless, close

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

О чём и речь. И после этого нам говорят «Ну а то, что Perl вообще читать нельзя, так все давно знают, угу.»

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

Пишется хрень (через буст или ещё чё-нибудь вплоть до самостоятельного специализированного решения для конкретной задачи):
int CountRegExpInFile(const string& file_name, const string& regexp);

И потом все програмеры проекта наслаждаются всего 1 строкой:
int с = CountRegExpInFile(«file», «exp»);

>как всё в перле неоднозначно и непонятно оказывается... =)

На perl, как я показал выше, это решает программист выбором стиля. А вот на LISP такого наглядного кода я что-то не видел.

> потому что это само собой разумеющиеся вещи, в отличие от мозговырывательных #'

с каких пор и для кого?

>Если бы чаще заходили на форум, то наверняка бы заметили, что я тут последние два месяца только тем и занимаюсь, что CL это вообще никакой на функциональный язык?

Ты не спеши, успокойся, выдохни и попробуй сформулировать мысль ещё раз.

> Ну уже от подсчёта строк дошли до подсчёта использованных слов синтаксиса языка. Ну как дети малые.

где я переходил к подсчету количества слов синтаксиса? Вы меня с кем-то перепутали, я только указывал на неочевидность смысловой нагрузки

> Вообщем, в очередной раз потвердилось, что archimag

игнорирует очевидные факты, если они ему неприятны.

Хм. Какие? Славный анонимус предложил померяться на тривиальной задаче, в которой он, вероятно, надеялся получить очевидно преимущество с помощью Perl. Но, как оказалось, решение на CL и короче, и понять проще даже неподготовленному человеку. Но нет, мы пытаемся доказать что-то совсем обратное?

> в лиспе: iter, for, in-file, #P, using, #', unless, ppcre:scan в перле: open, while, unless, close

Вы понимаете, что такое синтаксис?

в лиспе: ( ) ' #
в перле: ( ) / < > { } ; $ , return

scalar grep /^192\.168/, <$fh>;

Вообще можно воспользоваться модулем Slurp (iterate тоже сторонняя библиотека, ага) и написать ещё проще:

 scalar grep ! /^192\.168/, slurp 'access.log' 

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

...

Читатели кода жгут! Я имею честь хорошо знать оба языка и прекрасно видно как в каждом лагере совершенно тупо читают язык оппонента. Примерно как аборигены втыкают в СУ-37, как было написано выше. Но продолжайте, товарищи, это всё очень интересно!

> в лиспе: ( ) ' #

насчет for утверждать не берусь, но #P и using таки элементы синтаксиса

Как уже подсказали «grep -c xxx yyy» делает это исчо проще, чем Лиспы. А у С, С++, Перла, Питона есть огромнейшее количество библиотек, которые позволяют не изобретать велосипеды.

Обрисуйте вкратце как на Лиспе будет выглядеть перекодирование тэгов в файлах mp3 из СP1251 в УТФ-8. И как коммерсант сможет сэкономить на зарплате, если будет держать для таких задач 1 лиспера, а не 2 перлов с готовой библиотекой.

> Читатели кода жгут! Я имею честь хорошо знать оба языка и прекрасно видно как в каждом лагере совершенно тупо читают язык оппонента. Примерно как аборигены втыкают в СУ-37, как было написано выше. Но продолжайте, товарищи, это всё очень интересно!

было бы любопытно узнать авторитетное мнение независимого анонимуса

> Читатели кода жгут! Я имею честь хорошо знать оба языка и прекрасно видно как в каждом лагере совершенно тупо читают язык оппонента. Примерно как аборигены втыкают в СУ-37, как было написано выше. Но продолжайте, товарищи, это всё очень интересно!

Рады стараться! :) Должен же был кто-то показать анонимусу-перлисту как он предвзято расставлял комменты на Русском.

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

Оказалось, что решение на perl
1. в одну строку, самое короткое и удобное для вызова из ком. строки, ибо аналогичного варианта на LISP мы так и не увидели.
2. функция на perl может быть написана с выбором стиля, ибо приведены два варианта функции: короткий и непонятный аля LISP (в 2 строки, что короче LISP варианта) а также понятным и ясным (в 5 строчек).
3. понятнее и яснее варианта LISP неподготовленному человеку, ибо в любом варианте содержит меньше «страшных слов» а также его «страшные слова» куда более выразительны LISP'овых.

Заметим, что я везде аргументировал свои убеждения, в отличе от голословных и неподтверждённых слов archimag'а.

> насчет for утверждать не берусь, но #P и using таки элементы синтаксиса

Нет. Это не элементы синтаксиса языка.

> Обрисуйте вкратце как на Лиспе будет выглядеть перекодирование тэгов в файлах mp3 из СP1251 в УТФ-8.

Эта задача в PCL рассматривается. Рекомендую почитать.

Забыл в лиспе " и в перле '

Там рассматривается, как 1 лиспер заменит для таких задач 2 перлов?

>Обрисуйте вкратце как на Лиспе будет выглядеть перекодирование тэгов в файлах mp3 из СP1251 в УТФ-8. И как коммерсант сможет сэкономить на зарплате, если будет держать для таких задач 1 лиспера, а не 2 перлов с готовой библиотекой.

Коммерсанту с такими задачами не перлы/лисперы нужны, а пила «Дружба» - и на лесоповал.

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

> Нет. Это не элементы синтаксиса языка.

1) (get-dispatch-macro-character #\# #\P)

LispWorks вроде даже разворачивает #P"path" macroexpand'ом не помню во что, но так же, как и #' разворачивает в (function ...)

2) using — элемент синтаксиса iter (или for?) ибо вне этой конструкции не имеет никакого смысла.

> 3. понятнее и яснее варианта LISP неподготовленному человеку, ибо в любом варианте содержит меньше «страшных слов» а также его «страшные слова» куда более выразительны LISP'овых.

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

>Вообще можно воспользоваться модулем Slurp (iterate тоже сторонняя библиотека, ага) и написать ещё проще
Ах LISP'еры даже читят! Я то всё нативно писал, без библиотек. Ну тогда им слив защитан, без вариантов.

Вы что, не понимаете пропорций? Как такого рода мелочь смогут лисперы писать в 2 раза быстрее, чем перлы с соотвествующими библиотеками.

> ... а не 2 перлов с готовой библиотекой.

для задач, решенных 20 раз не нужны даже перловцы

> Ах LISP'еры даже читят! Я то всё нативно писал, без библиотек. Ну тогда им слив защитан, без вариантов.

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

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

ибо аналогичного варианта на LISP мы так и не увидели.

Только благодаря особенностям однострочных скриптов на Perl. При попытке оформить решение в виде функции Perl сразу же сливает. Т.е. просто сливает для реальных программ, а не однострочников, в которых он безусловно силён. Но и то. однострочник на перл сливает простому вызову grep.

функция на perl может быть написана с выбором стиля,

ибо приведены два варианта функции

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

понятнее и яснее варианта LISP неподготовленному человеку

Издеваетесь? Решение на CL написано фактически на английском языке, его можно просто прочитать по словам и всё понять. А решение на Perl использует его весьма специфичный синтаксис и мне вот понять его тяжело, даже при том, что когда то я написал на нём некоторое колличество скриптов, а если человек вообще Perl никогда не видел, то по этому коду он вообще не поймет даже о чём он.

Ты бы вернулся к задаче с XML. Мне было бы интересно посмотреть на код архимага, ну и пелрлом посравнивать.

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

Чем это open, close, while, unless и return дальше от английского в сравнении с #P, #', ppcre:scan?

> Как такого рода мелочь смогут лисперы писать в 2 раза быстрее,

чем перлы с соотвествующими библиотеками.

Можно подумать, для лисперов нет библиотек, угу.

>LISP'еры даже читят!

А что от лисперов ожидать. А если использовать библиотеки, то Жаба Перл С++ могут невероятное количество всего и очень быстро. Где никакой синтаксис лиспа не поможет увеличить скорость разработки

>> Ах LISP'еры даже читят! Я то всё нативно писал, без библиотек. Ну тогда им слив защитан, без вариантов.

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

Дык perl'e для таких простых задач и библиотеки не нужны. Если уж тут понадобились модули, то для серьёзных задач всё придётся писать самому.
И вообще про библиотеки заикаться вам не стоит. Заходим на http://www.cpan.org/ и видим 7930 authors 17386 modules. А сколько модулей у LISP в самом толстом cpan-аналоге?

> Чем это open, close, while, unless и return дальше от английского в сравнении с #P, #', ppcre:scan?

лол, давай так: чем for, in, using, read-line, unless, count дальше от английского в сравнении с <, >, /, $, ++, {, } ?

>А что от лисперов ожидать.

А ты таки чего-то ждал? Ты ещё не окончательно потерян для цивилизации...

> И вообще про библиотеки заикаться вам не стоит.

вот и кто теперь читер? =)

>Заходим на http://www.cpan.org/ и видим 7930 authors 17386 modules.

Это что-то про перестановки? =]

Я вообще не понимаю, нахера сравнить CL и perl на простых задачах?

Лучше расскажите про преимущества CL при решении крупных задач.

Значит лиспер с библиотекой могёт усё в 2 раза быстрее сделать, чем перл с библиотекой и плюсанутый с библиотекой? По синтаксису это почему-то не заметно.

> Ах LISP'еры даже читят! Я то всё нативно писал, без библиотек.

awk '/^192\.168/ {FOREIGN++} END {print FOREIGN}' access_log

Всем срочно учить замечательный Тьюринг-полный язык awk и переписывать на нём webkit, mplayer и Линукс.

>Но и то. однострочник на перл сливает простому вызову grep.
Прошу обосновать этот голословный фарс. Я лишь заметил, что grep без wc даже посчитать строки не смог.

Издеваетесь? Решение на CL написано фактически на английском языке, его можно просто прочитать по словам и всё понять. А решение на Perl использует его весьма специфичный синтаксис и мне вот понять его тяжело

Это вы издеваетесь, см. http://www.linux.org.ru/forum/development/4513948/page14?lastmod=126523660656...
А то, что «мне вот понять его тяжело, даже при том, что когда то я написал на нём некоторое колличество скриптов» как раз и относится к категории (цитата другого лиспера):
«Это как велосипед: ездить на велосипеде чрезвычайно просто, но в начале обучения все падают. И те, кто после первого падения решил на велосипеде больше не ездить, либо вообще перед перспективой сделать себе больно зассал даже в седло садиться, также изливают на форумах понос про какой-нибудь фристайл.»

>Лучше расскажите про преимущества CL при решении крупных задач.

Присоединяюсь. Как там с корпоративной разработкой с десятками программеров, миллионами строк и текучками кадров. И задачами «Это надо вчера сделать».