Фраза о Лиспе...

> Ох уж мне эти аналогии...

А они не "доказательство", а наживка - думать и оценивать всё равно самому надо ;)

> Ни форму, ни обертку, ни рецепт ни Руби, ни Питон не копировали. Взяли то, что практично.

Взяли технологии, с успехом применяемые в языке вот уже более ... лет, некоторые из которых из этого языка и выросли.

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

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

> но волну интереса к динамическим и функциональным языкам подняли Python и Ruby

не путай причины и следствия. Появился интерес - появился и питон и раби и ещё другое.

> Появился интерес - появился и питон и раби и ещё другое.

Три раза "ха". Питон появился году в 1991-1992, Руби - в 1995. Может, они и не причина, но появились намного раньше, чем нынешняя волна интереса.

(мы уверенно движемся в Top 1 8))

>> Раскидать бы пакажи по дллам и лиспмашину в виде микроедра...

> А нафига dll, если кроме лиспа их никто использовать не сможет (если это не gcl/ecl, конечно; и то не уверен)?

Это конешно сложно осуществить сейчас, но принципиальных проблем не вижу. Больше нестыковок по причине малой совместимости в традиционных вариантах исполнения лиспа. Я имел в виду следующее: в некоей длл сидит лиспмашина с сборщиком помоев, которая может подключять другие дллы с пакажами. Без этой базовой библиотеки пакажи действительно будут неполезны. Лисп-прога компилицо в натив и линкуецо с этой базовой дллой динамически при исполнении. Этим хотябы можно избежать образования ПРЕОГРОМНОВО едра для каждой мелкой прожки. Также, не вижу больших проблем использования всево этово из например сей.

> Это конешно сложно осуществить сейчас, но принципиальных проблем не вижу. Больше нестыковок по причине малой совместимости в традиционных вариантах исполнения лиспа. Я имел в виду следующее: в некоей длл сидит лиспмашина с сборщиком помоев, которая может подключять другие дллы с пакажами. Без этой базовой библиотеки пакажи действительно будут неполезны. Лисп-прога компилицо в натив и линкуецо с этой базовой дллой динамически при исполнении.

А чем это отличается от ядра и *.fas файлов? :)

> Лисп-прога компилицо в натив и линкуецо с этой базовой дллой динамически при исполнении. Этим хотябы можно избежать образования ПРЕОГРОМНОВО едра для каждой мелкой прожки.

А мелкие прожки на лиспе - это как? И может их тем-более *.fas-ами оставить?

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

> Три раза "ха". Питон появился году в 1991-1992, Руби - в 1995. Может, они и не причина, но появились намного раньше, чем нынешняя волна интереса.

(занудно так) А Perl - ажно в 1987-ом... Вместе с Tcl.

>> Питон появился году в 1991-1992, Руби - в 1995. Может, они и не причина, но появились намного раньше, чем нынешняя волна интереса.

> (занудно так) А Perl - ажно в 1987-ом... Вместе с Tcl.

Знаю. И всё же волна интереса связана именно с Python/Ruby. Не с Lisp/Tcl/Perl.

Вспомнилась прикольная цитата: "TCL is Lisp on drugs".

> Ни форму, ни обертку, ни рецепт ни Руби, ни Питон не копировали. Взяли то, что практично.

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

Поправь последнее предложение ;)

> Либо мутировать окружение до уровня того, откуда их взяли, либо использовать готовое, уже отлаженное

Это называется "ложная альтернатива". На самом деле, остается еще до фига путей. Это как цвета и вкусы - их можно получить, комбинируя базовые, но в мире гораздо больше цветов, чем RGB, и гораздо больше вкусов, чем кислый/соленый/горький/сладкий. Может быть, что "базовых" языков программирования - 2 (Лисп и Фортран). Но мы будем использовать гораздо больше. Всегда. Так что нет никаого "перехода от первого ко второму", это путь _между_ ними.

Блин, и меня на аналогии потянуло :/

>Пустой - почти в два раза меньше (вроде) ~ 26 мег :)

Дык в архиве ядро SBCL ужимается до 4-5Мb, что вполне терпимо.

> Три раза "ха". Питон появился году в 1991-1992, Руби - в 1995. Может, они и не причина, но появились намного раньше, чем нынешняя волна интереса.

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

> А чем это отличается от ядра и *.fas файлов? :)

главным образом тем, что fas фаелы загружаюцо в едро, а не линкуюцо с им. ИМХО. Хотя я может и прогнал, ибо не очень сведущ в этих вопросах.

> А мелкие прожки на лиспе - это как? И может их тем-более *.fas-ами оставить?

Может и так. Но одна из моих мелких прожек строк на 200 подгружает гтк, предоооолго :( . core с грк нехотит загруженое работать, я писал по это ранее.

> но, имхо, сейчас это не главное... :)

А что потвоему?

> Знаю. И всё же волна интереса связана именно с Python/Ruby. Не с Lisp/Tcl/Perl.

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

> Вспомнилась прикольная цитата: "TCL is Lisp on drugs".

недавно пытался работать с тиклем. Есть много оббщего с лиспом но ужоснахъ.

> Поправь последнее предложение ;)

чё с им нетак?

> На самом деле, остается еще до фига путей.

Например?

> Это как цвета и вкусы - их можно получить, комбинируя базовые, но в мире гораздо больше цветов, чем RGB, и гораздо больше вкусов, чем кислый/соленый/горький/сладкий.

Можно. Но есть цвет и есть вкус. Сколько бы ты цветов не комбинировал, новово вкуса не получиш.

> Может быть, что "базовых" языков программирования - 2 (Лисп и Фортран). Но мы будем использовать гораздо больше. Всегда.

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

> А что потвоему?

Ох, дофига чего... Хотя это всё мои мысли, направленные на практическую область и касающиеся OS софта. Мало того, что в каждом лиспе свой TODO похож на роман с продолжениями... (в cLisp нет тредов - и не предвидется, в sbcl те же треды только на 2-3 платформах, виндовая в зачаточном состоянии, gcl и ecl очень далеки от стандарта). "Помирить" cffi и uffi (ну, местами оно уже так, но хотелось бы придти к более общему знаменателю), сделать в cffi возможной работу со строками в разных кодировках (думаю, это ещё долго актуально будет - что-то все на utf-8 не торопятся), то-же самое довести до ума в uffi (там зачатки есть, но совершенно бессистемные), после этого - биндинги, биндинги, биндинги (доработка существующих и разработка несуществующих) И есть огромное желание как-то систематизировать огромную кучу лисповых библиотек: многие упоминаются на cliki.net и иже с ним, другие идут в составе clocc, третьи - на сайтах авторов, четвёртые производители проприетарных лиспов выкладывают на своих сайтах; часть из них использует asdf, другие defsystem, третьи - вообще ничего не используют. Так что любой шаг в сторону превращается в исследовательскую работу ;)

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

в топ 1 более 3000 каментоф. ниасилим ИМХО :(

> gcl и ecl очень далеки от стандарта

Это принципиальные траблы или недоделато просто?

> но без кучи батареек, легко доставаемых одним щелчком пальцев, использовать это богатство "направо и налево" пока несколько неудобно.

Аха, предложенный мной подход ИМХО несколько помог бы в решении этой, но наверняка есть и более умные идеи, а стопорицо как всегда, из-за тово, что это всё нужно кому-то делать :(

> Дело не в езыках, а в концепциях, в их закладенных. Я вижу только две - "фортрановскую": декомпозиция задачи до уровня чисел (включяя строки как наборы кодов) с последующей их обработкой алгоритмически, и "лисповую": создание базиса для абстракций, и их конкретизация в проге до соответствующево задаче уровня. Первый путь короток и пройден до упора, а второй _массово_ только-только начинаецо, хотя для рада задачь применяецо давно и успешно.

algol family и fortran - это совершенно разные пути развития и семейства языков (ну, второе семейство состоит из фортрана, фортрана и фортрана - но это неважно).

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

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

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

А на практике удобнее использовать более узкозаточенные и простые инструменты. Типа C или Perl или Java.

> появились - я имею в виду появились в практической деятельности.

Ну, Питон в практике появился лет 10 как. Руби 0 не знаю, не следил за ним.

> Ведь есть ещё более 2000 наречий, не забывай.

Это совсем-совсем мертвые языки. Активно используемых - десятка два, от силы - три.

> в топ 1 более 3000 каментоф. ниасилим ИМХО :(

3000? Ааафигеть. Проклятые флудеры 8). Нам за ними не угнаться.

1024-й пост?

А вот теперь - точно 1024-й. Щасс придет модер и снесет... 8)

> algol family и fortran - это совершенно разные пути развития и семейства языков

семантика разная, да. Но растут они из одново корня: http://www.levenez.com/lang/ и подход одинаковый. В основу покладены разнообразные форматы чисел и некоторые примитивные операции со строками. Методы работы одинаковые: инфиксные и префиксные операторы, действующие на базовые типы и функции для работы с ними же, всё строго алогитмично. Я это уже писал ведь.

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

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

> совершенно не соответствуют тому, как работает ЭВМ

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

> При этом, кстати, никак нельзя доказать, что достижимый на C уровень абстракции ниже, чем лисповый.

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

> ИМХО, лисп круче всего остального только тем, что он уже 40 лет

ты опать путаеш причину со следствием? Поэтому он уже 40 лет, что круче.

> А на практике удобнее использовать более узкозаточенные и простые инструменты. Типа C или Perl или Java.

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

> Это совсем-совсем мертвые языки. Активно используемых - десятка два, от силы - три.

Дык и питоноруби савсем-савсем мьйортвый волялсо, пока не понадобился. Ты же не будеш отрицать чё лет скажем 5-6 тому питон юзался намного реже лиспа? Я и говорю, чё давно уже поизобретено многое, и некоторое доведено до совершенства, только вот откладено в сторону за ненадобностью. А когда надобно, обычно начинают изобретать заново, косо-криво с самого начяла, вместо того чтобы поглядеть в заначке.

> А вот теперь - точно 1024-й. Щасс придет модер и снесет... 8)

модераторский налог? Кажный 1024й пост в пользу заведения?

> Это принципиальные траблы или недоделато просто?

Я думаю, что если их довести до стандарта - что-то вроде sbcl получится :)

Точно не помню - вроде corman lisp с сырцами идёт - я его не тестировал, но он _очень_ компактный по сравнению с sbcl. Правда, только под офтопик.

> При этом, кстати, никак нельзя доказать, что достижимый на C уровень абстракции ниже, чем лисповый.

Нет конечно. Но аналогичный уровень будет выглядеть кошмарно. Или нужен очень навёрнутй препроцессор... gcl например ;)

> "традиционные" языки управляют тоже по большей части или только состояниями переменных примитивных типов

Причем здесь язык? Создай сложные объекты и управляй _их_ состоянием. Языки (Си/Си++, Питон) это позволяют и, более того, поддерживают.

Вот этим предложением:

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

ты противоречишь этому:

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

Для протокола: "приходицо разбирать задачу на байты, целые, строки, итд вручную полностью, и программить операции с байтами, строками итд" - я просто плачу над этой злой судьбиной. Надо же, "приходится". Средств определения новых объектов и понятий - ну просто нет (нигде, кроме Лиспа).

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

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

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

>> Это совсем-совсем мертвые языки. Активно используемых - десятка два, от силы - три.

>Дык и питоноруби савсем-савсем мьйортвый волялсо, пока не понадобился.

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

Мертвые языки - это всякие Algol-6[08], RTL, Clu, Jovial, Chill, Self и т.д.

> Ты же не будеш отрицать чё лет скажем 5-6 тому питон юзался намного реже лиспа?

Если бы ты сказал 10 лет - я бы не стал спорить. А 5 лет назад - спорить не стану только потому, что нет цифр на руках (но Питон наверняка обошел Лисп к тому времени).

> > Ты же не будеш отрицать чё лет скажем 5-6 тому питон юзался намного реже лиспа?

> Если бы ты сказал 10 лет - я бы не стал спорить. А 5 лет назад - спорить не стану только потому, что нет цифр на руках (но Питон наверняка обошел Лисп к тому времени).

Ну, такое сравнение не совсем корректно. Если учесть, что лиспов, как у бобика блох...: что схема - тоже лисп, а это sicp, а это MIT со студентами, а ещё есть биглу (или бигло? :) и прочие схемы, что есть AutoLisp - а это все, кто пытался автоматизировать кады разной направленности, что это elisp со всем, кто хоть чуть-чуть разобрался в емаксе, если попытаться вспомнить все остальные ниши, куда проник лисп - я думаю только с более-мение широким распространением zope питон возможно догнал лисп. Хотя точных цифр и у меня нет :)

> Причем здесь язык? Создай сложные объекты и управляй _их_ состоянием. Языки (Си/Си++, Питон) это позволяют и, более того, поддерживают.

Хм. Задачя: составить структуру данных для хранения информации о том, в каких директориях находицо файл. Одинаковый файл может храницо в нескольких. Файлы щитаецо одинаковым если совпадает и имя и размер. Создать код, который 1) поштучно добавляет информацию (имя файла, размер, директория) в структуру, 2) составляет отдельно списки имён файлов, которые есть в равном N количестве, больше или меньше. Для каждово имени нужно передать также информацию о том, в каких директориях он. Возмёшся? Потом присовокуплю код на лиспе.

> Средств определения новых объектов и понятий - ну просто нет (нигде, кроме Лиспа).

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

> "создать понятия, соответствующие задаче, и опрерировать в дальнейшем ими" - этому учит любая нормальная книга по программированию. Керниган и Плоджер, например - хотя они используют Ратфор и Паскаль.

Дык полвопроса в сложности этово _создать_ понятия. А вторая, большая ево половина в том, чем потом с этими работать.

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

Дык приходицо. Только обычный стиральный порошёк^W^W^Wбыдлойазыг работает с примитивными данными, и кроме группирования приходицо ещё мапить элементарные действия на ещё более элементарные операции с примитивными типами. Опять, см. выше.

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

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

> Если бы ты сказал 10 лет - я бы не стал спорить. А 5 лет назад - спорить не стану только потому, что нет цифр на руках (но Питон наверняка обошел Лисп к тому времени).

Ну ладно, тогда не будем. Просто например про лисп, что такое в принципе бывает, я услыхал в конце 80х - начяле 90х впервые, а про рубипитон - всево лет пять тому. Хотя конешно, это не показатель и не доказательство.

2redvasily

>Был уже апдейт:

И что, скажете читабельность повысилась ?

>1. Не припомню в английском слова "cons"

construсt... Дальше лучше припоминается ? Ну можно на pair заменить, если уж так глаз режет.

>2. Слова в лиспе английские, но вот предложений как-то не >образуется. > Или Йода мастер лиспе сказал это на?

Йода мастер сказал: "Кто не может даже в таком очевидном случае увидеть предложений, те идут это на".

>3.Надо поменять опрос, сменить его на: "какая из этих программ более > читаемая?"

Это не опрос. Это риторический вопрос. IMHO не может быть чтоб код с [1:],[:i],[i:], xrange, yield читался лучше кода без этих значков человеком, который не знает оба языка.

>4.COBOL ваще от английского не отличить. И что?

Наверное поэтому он для левых людей читается получше, чем Перл ;-)

> Задачя: ... Возмёшся?

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

[ но всё же хочется уточнить условия задачи - каталоги могут быть вложенными? и почему такое странное определение идентичности - имя и размер? давай уже введем inode number, как в приличном Unix. Или в определении равенства по 2-м атрибутам, один из которых - строка, есть какой-то сакральный смысл? ]

> в том дело что средства езыка не позволяют потом с ними эффективно работать.

Этого просто не понял. Давай конкретно о Питоне или Си++ - с какими определенными программистом понятиями они не позволяют эффективно работать, и в чем это проявляется? И как определяется "эффективность"?

>> "создать понятия, соответствующие задаче, и опрерировать в дальнейшем ими" - этому учит любая нормальная книга по программированию. Керниган и Плоджер, например - хотя они используют Ратфор и Паскаль.

>Дык полвопроса в сложности этово _создать_ понятия. А вторая, большая ево половина в том, чем потом с этими работать

Опа. Полезли идеологические разногласия. Видишь ли, я считаю, что именно _создать_ понятия гораздо сложнее и важнее, чем потом ими манипулировать. И я не стану даже спорить по этому поводу - замечу только, что в "хорошесть" созданного понятия (программной абстракции) входят такие вещи, как сопротивление ее неправильному использованию, то есть то, что ни компилятор, ни мегапродвинутая макросистема отследит не в состоянии.

> обычный стиральный порошёк^W^W^Wбыдлойазыг работает с примитивными данными

Еще раз - он работает с теми данными, которые ты определишь. Кстати, "быдлойазыг" - это что такое? У него имя есть, или он просто рекламная^Wфигура речи?

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

> а, какая йухан разницо, если к продакшну он пока близко не подошед?

Определение "живого языка" - в студию! С количественными параметрами.

> от делфей тож кучя скубентов фанатеют

Как тебя корежит от Делфи и студентов... Ты скажи прямо - Дельфи плох, потому что его студенты любят, или студенты плохи, потому что любят Дельфи?

> хотя ни один не может внятно объеснить чем оный дельфи лучше тех же сей например

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

>>Был уже апдейт:

>И что, скажете читабельность повысилась ?

Я скажу - да, повысилась. Ясный и даже красивый код.

>>1. Не припомню в английском слова "cons"

>construсt...

Ну тогда в Питоньей программе вообще все слова английские

> Кто не может даже в таком очевидном случае увидеть предложений, те идут это на

Достойный ответ, да

> IMHO не может быть чтоб код с [1:],[:i],[i:], xrange, yield читался лучше кода без этих значков

range, yield - это слова, отражающие назначение соотетствующих конструкций. [1:] и т.д. - достаточно близки математической нотации.

> Методы работы одинаковые: инфиксные и префиксные операторы, действующие на базовые типы и функции для работы с ними же,

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

> всё строго алогитмично.

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

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

> Ну и чем это по твоему отличяецо? Особенно в свете того, что "традиционные" языки управляют тоже по большей части или только состояниями переменных примитивных типов?

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

> > При этом, кстати, никак нельзя доказать, что достижимый на C уровень абстракции ниже, чем лисповый.

> Никак нелзя. В конечнои итоге оно совершенно одинаково, ибо аппаратные процессы, решающие задачу, одни и те же.

Ты, блин, отличаешь эквивалентность программы от уровня абстракции исходного кода?

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

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

> > ИМХО, лисп круче всего остального только тем, что он уже 40 лет

> ты опать путаеш причину со следствием? Поэтому он уже 40 лет, что круче.

Нет, я уверен, что это ты путаешь ;). К Си не пытались приделать coroutines и continuation (эти слова на русский вообще переводятся) потому, что на практике системного программирования это ненужно. А к лиспу (в разных инкарнациях) приделали - поэтому теперь лисперы (ну, схемеры) могут хвалиться, что оно у них есть. И так я могу перечислить еще два десятка длинных английских слов, с ровно тем же комментарием.

> > А на практике удобнее использовать более узкозаточенные и простые инструменты. Типа C или Perl или Java.

> Дык я про чё и говорю, что удобнее. [skip] Вот в этом случяе лисп и адекватен - позволяет создать вострозаточенный и простой струмент прямо по ходу пьесы.

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

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

> а, какая йухан разницо, если к продакшну он пока близко не подошед?

Это петон-та? Ой, это ты гонишь. Нет, я понимаю, что gmail в вечной бете - но все же... ;-)

Вот рядом со мной человек пишет кусок баннерной системы на Python (у нее есть еще куски на C++, plain C, Perl и javascript) - и ниччо, работает. В "продакшне".

А перл так вообще из этого продакшна выпадает постепенно. Что печально, но естественно - мало кто может осилить строчку (написано мною сегодня, правда для отладки и навыброс:

@matches = map {substr($str, $-[$_], $+[$_]-$-[$_]} 1..$#-;

> Вряд ли. По

ну вот. А на лиспе каждое из этих делаецо в одну (нормальной длины) строку.

> каталоги могут быть вложенными?

конешно, это дерево каталохов обычное.

> и почему такое странное определение идентичности - имя и размер? давай уже введем inode number, как в приличном Unix. Или в определении равенства по 2-м атрибутам, один из которых - строка, есть какой-то сакральный смысл?

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

> Этого просто не понял. Давай конкретно о

Давай чтобы менее голословно и более очевидно было, с кодом этой задачи закончим, и на её примере (надеюсь) это будет очевидно.

> И как определяется "эффективность"?

логическим размером кода в основном. Если на одном языке например я хочу расширить набор например целых чисел их квадратами, на лиспе я пишу (отобразить множество а на множесво б функцией: (список: число, ево квадрат)) и не парюсь. А на например сях мне нужно 1) вычислить сколько места отвести под результат 2) выделить место 3) создать цикл перебора всех (причём в это входит нескко логических операций!) 4) присвоить элементу результата число 5) присвоить след. элементу результата число 6) после работы не забыть очистить выделенное. Это неэффективное использование труда программера. Хотя этой эффективности просто не замечают. По аналогии, жители высокогорного плато не замечают что жывут высоко, пока не подойдут к краю плато.

> Опа. Полезли идеологические разногласия. Видишь ли, я считаю, что именно _создать_ понятия гораздо сложнее и важнее, чем потом ими манипулировать. И я не стану даже спорить по этому поводу - замечу только, что в "хорошесть" созданного понятия (программной абстракции) входят такие вещи, как сопротивление ее неправильному использованию, то есть то, что ни компилятор, ни мегапродвинутая макросистема отследит не в состоянии.

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

> Еще раз - он работает с теми данными, которые ты определишь.

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

> Кстати, "быдлойазыг" - это что такое? У него имя есть, или он просто рекламная^Wфигура речи?

Ну, это в какой-то степени собирательный образ "майнстримовых" наречий.

> Определение "живого языка" - в студию!

ну лисп например

> С количественными параметрами.

адын штук

> Как тебя корежит от Делфи и студентов... Ты скажи прямо - Дельфи плох, потому что его студенты любят, или студенты плохи, потому что любят Дельфи?

Больше всево меня расстраивает "стадность" и отсутствие критического взгляда на вещи.

> А ты сам не знаешь?

не

> ObjectPascal лучше Си тем, что в нем есть ООП и обработка исключений.

ну в с++ тож есь такое. Дык скубенты и не смогут объяснить чем делви луче с++ тоже.

> Дельфи лучше Си тем, что в его IDE интегрирован мощный конструктор GUI (не в каждом Си есть IDE), и эта IDE хорошо поддерживает разработку компонентов конструктора GUI (лучше, чем любая Си IDE, которые я видел).

А он там нужен ваще, тем более такой ацтойный? Ну напишеш в строке компиляции например -lgtk и будет в сях не хуже нискоко.

> Неужели это трудно понять?

весьма

> Что тебя так раздражает - то, что _ты лично_, _сейчас_ не считаешь это достоинствами?

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

> Имхо, он избыточен. Он, при отсутсвии собственного синтаксиса и грамматики (в широко-лингвистическом смысле, как структура уровнем выше синтаксиса, а не в смысле "формальная грамматика")

Ну, ээ. Эт я прогнал, что грамматика - это структура над синтаксисом. Штука просто в том, что у естественного языка на уроень больше, и то, что для С мы назовем грамматикой, для русского - морфология, а сишный синтаксис соотвествует русской грамматике, грубо говоря.

> Ясный и даже красивый код.

Ты читал код, который получился, когда я перевёл ЭТО 1:1 на лисп и сравнил с первоначяльно лисповым?

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

Гм. Учтя, что у "протолиспа" из перечисленного есть только функции (хотя и чуть более продвинутые - потому что тпизация изначально динапическая, точнее "символьная") - то что?

И почему сишные функции "предполагают работу с примитывными типами"? Вон на gtk (хотя уродец тот еще) посмотри - какие там примитивные типы? Или ты считаешь, что если объект доступен как opaque handle, который typedef int - то он не сложнее int-а?

> А он там нужен ваще, тем более такой ацтойный? Ну напишеш в строке компиляции например -lgtk и будет в сях не хуже нискоко.

Таки VCL+борляндческий гуередактор - это хорошо (можно, кстати, и на плюсах писать, хотя исходник самой библиотеки - на паскале). Просто им, как и всем остальным, нужно уметь пользоваться, и включать мозг на этапе проектирования. А если в программе присутствует Button432, то переход на gtk таких индивидуумов не спасет.

> Если на одном языке например я хочу расширить набор например целых чисел их квадратами, на лиспе я пишу (отобразить множество а на множесво б функцией: (список: число, ево квадрат)) и не парюсь. А на например сях мне нужно 1) вычислить сколько места отвести под результат 2) выделить место 3) создать цикл перебора всех (причём в это входит нескко логических операций!) 4) присвоить элементу результата число 5) присвоить след. элементу результата число 6) после работы не забыть очистить выделенное. Это неэффективное использование труда программера. Хотя этой эффективности просто не замечают.

Откройте для себя Бейсик и не трахайте людям моск...

> Не, быдлойазыги _обязаны_ исдохнуть.

Бейсик что-то с 64ого года никак не издохнет... И используется он значительно шире лиспа. Потому что туда заложены вполне практически полезные идеи и фишки (как можно больше вещеё по умолчаний и простой для человека, а не для машины синтаксис), а не маразматичные рассуждения и упивание "красотой" и "правильностью" языка. Результат можете лицезреть в любой школе/инсте где преподают информатику. Там почему-то не Цэ, не фортран, не жаба, не хаскель, а именно он самый...

> так читабельнее и привычнее

только в случяе с числами. Поэтому я и говорю, такие наречия - это для программируемого калькулятора.

> Вполне можно переписать любую сишную прогу таким образом, чтобы операторов там не было вообще

А вместо них?

> На нем все алгоритмично ровно настолько же. Как известно, лямбда-исчисление эквивалентно исчислению машины Тьюринга.

А как с например функциями (map... ?

> И таки что, на фортране есть указатели?

А какая разница? Понадобились бы - были бы.

> Ты, блин, отличаешь эквивалентность программы от уровня абстракции исходного кода?

А ты не?

> структуры (не дай бог - классы!)

Ну разобрали чёто на байты, а потом сгруппировали опять, удобства для. Ичё?

> нет никаких проблем "создать понятия, соответствующие задаче, и опрерировать в дальнейшем ими". В терминах функций и структур.

Я там приводил задачку, запость сюды код на сях, сравним.

> Имхо, он избыточен.

От задачи зависит. Иногда как бы и недостаточен может быть.

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

Асм ево тоже вполне предоставляет. Принципиальная возможность решения != лёхкость и простота решения, так то вот.

> В конце концов - обходимся же мы 7-ю падежами и десятком глагольных форм, и не изобретаем грамматические конструкции по ходу разговора.

Вот именно. А ты утверждаеш

> нет никаких проблем "создать понятия, соответствующие задаче, и опрерировать в дальнейшем ими". В терминах функций и структур.

Это читал?

http://www.paulgraham.com/quotes.html

Это ведаеш?

> "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

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

Оно нам нужно всякий раз лисапед изобретать? Да ещё далеко не факт что самый лучший.

> Бейсик что-то с 64ого года никак не издохнет... И используется он значительно шире лиспа. Потому что туда заложены вполне практически полезные идеи и фишки (как можно больше вещеё по умолчаний и простой для человека, а не для машины синтаксис), а не маразматичные рассуждения и упивание "красотой" и "правильностью" языка. Результат можете лицезреть в любой школе/инсте где преподают информатику. Там почему-то не Цэ, не фортран, не жаба, не хаскель, а именно он самый...

а) троллить нехорошо, пусть даже и умело ;) Мы тут, все же, обсуждаем "промышленные" языки, т.е. предназначенные для использования профессиональными разработчиками ПО, имующими профильное (ну, более-менее) образование. А вы тут со своими красными тряпками в виде VB.

б) таки про институты - вообще неправда. Бейсик на информатике я могу себе представить разве что на плохом гуманитарном факультете. У нормальных людей это (первый ЯП, в смысле) Pascal или Java, за бугром, говорят, Python или Scheme бывает иногда.

> Это петон-та?

аха

> Ой, это ты гонишь.

Дану? А скопки там доделали? А макросы? А лямбды многострочные? А траблы с оперативой отрешали? А превеликие тормозы?

> и ниччо, работает. В "продакшне".

ну и виндовсь на серверах типо "впродакшне". толко луче бы ваще никак чем так вот.

> А перл так вообще из этого продакшна выпадает постепенно. Что печально, но естественно

Ну чё делать, Должен Остаться Только Один!

> Гм. Учтя, что у "прото

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

> Вон на gtk (хотя уродец тот еще) посмотри - какие там примитивные типы?

gint, gpointer, gchar*, GtkWidget* ну и прочие

> Или ты считаешь, что если объект доступен как opaque handle, который typedef int - то он не сложнее int-а?

Какая разница? Это ведь средствами языка недоступно. Это же пришлось делать кому-то. А в лиспе всё готовое, стандартизованное и вышшего качества.

> А если в программе присутствует Button432, то переход на gtk таких индивидуумов не спасет.

А если на кажный чих _вручную_ писать обрабочик ресайза, предлинный, и на кажный чих ево переделывать/переотлажывать?

> пусть даже и умело

ИМХО неуклюже очень.

> А вы тут со своими красными тряпками в виде VB.

Типо питонобейсик луче?

> > так читабельнее и привычнее

> только в случяе с числами. Поэтому я и говорю, такие наречия - это для программируемого калькулятора.

Ну, ээ. В Си и Паскале операторы только для чисел и есть. А для всего остального - функции. Как и в лиспе, да, только в нем инфиксной нотации для чисел нету...

> > Вполне можно переписать любую сишную прогу таким образом, чтобы операторов там не было вообще

> А вместо них?

inline int ints_add(int a, int b) { /* inline asm goes here */ }

На плюсах можно просто sum - там перегрузка есть. И будет тебе префиксная нотация, причем более "математическая" - скобочки у функций, все же, математики не так ставят, как лисперы ;)

> На нем все алгоритмично ровно настолько же. Как известно, лямбда-исчисление эквивалентно исчислению машины Тьюринга.

> А как с например функциями (map... ?

В смысле? Ну мап и мап. На си тоже можно функции высших порядков писать - просто они типизированные, поэтому "просто" map-а там нету "из коробки". А, скажем, по массивам (или спискам) определенного типа так сделать - данивапрос, 10 строчек (для связных списков типа BSD queue - вообще в один макрос (дада, страшный и убогий cpp-шный) можно уложиться). Если мне оно больше двух раз в программе понадобится - я напишу.

На плюсах же все это есть generic в STL (map == transform, конкретно).

transform(source.begin(), source.end(), insert_iterator<target_type>(target, target.begin()), source_to_target_functor());

Ну да, многа букаф - зато typesafe.

> "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

s/Common Lisp/C++ and STL/

Тогда правда. См. исходники гнома/гтк.

И да, спасибо, я понимаю по английски. Письменно - так даже весьма неплохо.

> Ну разобрали чёто на байты, а потом сгруппировали опять, удобства для. Ичё?

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

> > Ой, это ты гонишь.

> Дану? А скопки там доделали? А макросы? А лямбды многострочные? А траблы с оперативой отрешали? А превеликие тормозы?

А теперь давай логическую цепочку от "нету многострочных лямбд" до "неприменимо в продакшене". В С вон вообще никаких лямбд нету - однако ж на нем написаны все сколько-нибудь промысшленные OS общего назначения. Не говоря уже о куче другого софта.

А питон активно применяется как язык-клей, для реализации сложной, часто изменяемой логики. Особенно удобно при этом вынести простые-но-затратные части (типа "пересортировать вон те 30 гигов по вот этому полю") в сишный код, чтобы быстро было.

> ну и виндовсь на серверах типо "впродакшне". толко луче бы ваще никак чем так вот.

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

Ну-ка, давай-ка пример мегасервиса на лиспе?

> А для всего остального - функции. Как и в лиспе, да, только в нем инфиксной нотации для чисел нету...

г. А щё в лиспе есь макросы, замыкания, лямбды, 1st class functions и другие страшные слова.

> На плюсах можно просто sum - там перегрузка есть. И будет тебе префиксная нотация, причем более "математическая" - скобочки у функций, все же, математики не так ставят, как лисперы ;)

а как будет пощитать например сумму квадратов произвользово числа чисел произвольново численново типа? в лиспе просто (reduce #'(lambda (x y) (+ x (* y y))) '(2 3 4) :initial-value 0), где '(2 3 4) - сами агрументы, можно туда переменную.

> На си тоже можно функции высших порядков писать - просто они

Просто они, а писать сложно, а без них скушно.

> 10 строчек (для

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

> зато typesafe.

Зато для каждово типа заново. А в лиспе типасейф тоже есть, опционально.

> s/Common Lisp/C++ and STL/

> Тогда правда. См. исходники гнома/гтк.

воистину бугога. Какая разница, начём лисапед, на с++/stl или на с/фортране? Просто цытата древняя, пора обобщить на питонос++ тоже.

> И да, спасибо, я понимаю по английски. Письменно - так даже весьма неплохо.

Наздоровье, только ты не один тута

> Блин. Давай ты не будешь передергивать.

Давай. Я тамо немного повыше задачку про файлы запостил, кажи код её решения, тогда и порассуждаем.