> Однако, на ЦеПП я напишу интерпретатор любого языка в одну строку. Конечно, сторока может оказаться довольно длинной... :)
Implementation quantities [limits]
1 Because computers are finite, C++ implementations are inevitably
limited in the size of the programs they can successfully process...
--Characters in one logical source line [65536]
:)
Не катит за отмазку 8) Что-то большее, иначе не употрблялись бы слова "императивщина" (с легким презрением) и "функциональщина" (с оттенком превосходства).
Лично я думаю, что упоминание знания Лиспа (Хаскеля, Окамла) - это просто способ выделиться, поэтому и раздражает. Нет?
Ибо воистину. Первый Язык, жемчужина посреди простых камней, и нет языков кроме Него. Скобки, в которых пустота - тело Его, мистическое двуединство кода и данных - дух Его, божественная рекурсия - сердце Его. Истинно говорю вам, избегающий света Его есть безумец, вот, свершается кара над главой его, и убогостью отмечены поделия его, подобные пустым глиняным горшкам рядом с хрустальным сосудом благодати Его. Принявший же и постигший истинный свет Его подобен прямой и отточенной стреле, чисты помыслы его и крепка рука его, и благословенны творения его, дарующие радость и утоляющие печали, ибо одухотворены духом Его и отмечены благодатью Его. А вас, поц иент, любитель недоязыков, ничего не ждт, кроме серой стены за окном, липкой остывшей каши и вечного аминазина.
Во-первых, я бы не стал обобщать, навешивая ярлыки. Во-вторых, расширение кругозора, это не отмазка. За всех я никогда не брался говорить, а за себя скажу, у меня не стоит проблема выбора языка для изучения или что-то в подобном роде - я вполне себе спокойно работаю, не первый год, и уже не первый в России. Всю жизнь писал на С++, теперь же, на C#/Java. Постепенно интерес к языку, который мне больше всего нравился - С++ падает, а к функциональным языкам растт. Интерес же к Лиспу, при том, что он не функциональный язык, обусловлен тем, что я прочитал о наличием в нм мощных средств метапрограммирования. Хочу ознакомиться.
> Лично я думаю, что упоминание знания Лиспа (Хаскеля, Окамла) - это просто способ выделиться, поэтому и раздражает. Нет?
Вероятно, для кого-то - да, после того как Луговской в наибезобразнейшей форме устроил пиар функциональным языкам здесь на ЛОРе, наверно, для кого-то это просто стало бессознательной модой. Как стало модным говорить о том, что С всегда лучше С++ теми, кто знает только один С. Я же от выступлений здесь воздерживаюсь, предпочитая более дружественную атмосферу. :)
> Интерес же к Лиспу, при том, что он не функциональный язык, обусловлен тем, что я прочитал о наличием в нм мощных средств метапрограммирования. Хочу ознакомиться.
То есть ты не лиспер пока, а интересующийся. Я тоже был интересующимся, прочитал все книги по Lisp в пределах досягаемости, потом попробовал программировать на нем (на guile). Оказалось, что это страшно неудобно. В результате вместо Lisp использовал Python и ни разу не пожалел. Однако червячок вс-таки грызет, поэтому и спрашиваю - что в нем другие нашли.
> Как стало модным говорить о том, что С всегда лучше С++ теми, кто знает только один С.
Ох, друг. Eсли бы те фортрановские быдлопрограммы, в которых мне приходилось ковыряться на прошлой работе, были написаны не на фортране, а на лиспе, может, я бы оттуда и не уволился. ;)
последние примеры смотрятся коряво, со скобками было лучше: код с таким уровней вложенности трудно читать -- именно поэтому на питоне так не пишут. парные скобки в редакторе хоть подсвечиваются..
Нет, не стандарт, но никто не запрещает этим пользоваться, если не нравятся скобки. Простенькая реализация на scheme занимает 25 килобайт (http://www.dwheeler.com/readable/sweet.scm). Ну и чужой код, если сильно хочется, очень просто перегоняется в такую форму и обратно.
> Быдлопрограммы можно написать на любом языке, увы...
Твоя правда, брат. Вот только быдлопрограмм на Лиспе значительно меньше, чем на Фортране. :D
Чем же это? Вы случайно не путаете с вендузятнегами?
> Да, доктор! Объясните мне, что они нашли в этом Лиспе ?!
спокойно, без паники. Бригада уже выехала.
Во-первых, он весьма прост. Назови языки и наречия, которые бы включали в себя сравнимое или меньшее количество базовых концепций, а потом давай сравним простоту испрользования названых на реальных задачах. Особенно будем обращать внимание, насколько гиморно и отлично от "канонов" будет таково решение.
Во-вторых, весьма универсален. Может быть есть такие задачи, решать которые на другом наречии было бы проще или результат получался бы лучше, но для лиспа круг задач, которые можно было бы решать с приемлемым качеством и за более чем приемлемое время, ИМХО наиболее широк.
В третьих, весьма читабелен. Вместо зверинца из всяких разнообразных : ; {} () :: . -> = используется (), и только там, где логически необходимо выделить определнную последовательность, из-за чего как число служебных элементов, требуемых синтаксисом языка а не описанием логики, так и их ассортимент, сведены к минимуму.
В четвртых, допускает весьма высокий уровень абстракции данных. Т.е. требует наименьшего числа телодвижений при описании задачи и ещ меньшего дл изменения проги если задача немного поменялась.
В пятых, нунах, запарилсо. Вот некоторые экзамплы, которые желающим предлагаю переписать на другом наречии, и потом посравнивать исходники с лисповыми. Обращаем внимание, юзается ли специально нарожднная для этого библиотечная функция, или решение построено в основном на базовых концепциях языка или наречия.
Да, да!!! (аж пена с зубов капает... Буен, sorry!!! Дайте мне лиспера с румяной попой! Как я в него направлю свой медный зуб!!! Ш-ш-ш-ш)
Покажите мне, пожалуйста, что ЛИСП стоИт бОльшего, чем ГЕНИАЛЬНЫЕ извращения наподобие Емакса, Редьюса и Байесрвских фильтров...
(Во ВСЕХ вышеперечисленных случаях ЛИСП сыграл ТОРМОЗЯЩУЮ роль!! На любом другом языке оно б круче проканало ИМХО :-) )
Я в прострации, честно говоря... Вас Дядя Грэм на бабки развел, и вы смеете нас учить, как на эти самые бабки не залететь... Что ж, каждый выбирает по себе!
Причм тут Дядя Грэм и баппки? Да, лично мне плотют за С, но знание лиспа позволяет зарабатывать более эффективно. Потому что мне он позволяет решать и автоматизировать разное вспомогательное. Возможно, как вариант, он не так хорош "в большем", как на малых задачах, не было повода сравнивать, но и повода для таких подозрений тоже пока небыло.
Всякие дельфи, васики и сиглюки тормозят гораздо круче. Потому что на сво изучение и внедрение требуют ресурсов, а отдачи и повышения эффективности по сравнению с ортодоксальными средствами - никакой, даже проявляют себя намного хуже. И больше, чем пара лет, не живут.
Чтобы данное обсуждение вышло за рамки пустого трпа, предлагаю отрешать хотя бы приведнное выше <на чм тебе понравится> и сравнить, а ещ лучше произвести функциональный аналог того же емакса, только круче.
>Всякие дельфи, васики и сиглюки тормозят гораздо круче. ...
Ты об этом моей жене скажи, а также тем трем сотням леммингов, что наш универ ежегодно выпускает с факультета информатики (считается одним из самых крутых в Европе!)... Уже пару лет они по выпуске не Жабу (как раньше) боготворят, а ВыжуалВасик в дотНет инкарнации:(
>> Всякие дельфи, васики и сиглюки тормозят гораздо круче. ...
> Ты об этом моей жене скажи,
А ты сам скажи, твоя же жена. Я своей сказал уже.
> а также тем трем сотням леммингов,
Вот им и нужно лисп вместо, чтобы отличали жабу от дотнетиненады. Иначе, на другом форуме обсуждали с моим участием, получается, что всякие варварские наречия-однодневки от подлых мсей и их друга и соратника багланда типо Революционный Шаг В Развитии, а чем он лучше того же лиспа, никто не знает. Начали выяснять - оказалось что всем хуже, несмотря на более чем солидную разницу в возрасте этих наречий. Ато млина, устроили из прикладной науки информатики сексуально-богословскую дисциплину с пророком-мелкосовтом и апологетами, возжелавшими розовой попки :E Вс от безграмотности. Ты вот тож на лисп крысишся, и (сполгода помойму назад) мы с тобой этот вопрос обсуждали. А чем именно не угодил - не сказал и сейчас не говориш. Пс с им, Грэмом, ну ненравицо он тебе, девушку там увл или тршку занял не отдат, это ваше с ним личное дело, но зачем на лисп крыситься? Это ведь неодушевлнное и такова всплеска эмоций ну никак не заслуживает. Если уж знаеш чем он так плох, говори, не томи. Не забудь примеры привесть какие сыщутся.
Я просто против крайностей. Я не бросаюсь в ноги Sussman'у и не молюсь на икону Graham'а. Тем не менее подход к обучению, когда первым выбирается язык, предрасполагающий к метапрограммированию, считаю весьма эффективным. Конечно он должен быть простым. Как scheme. На нем можно написать с нуля простенькую объектно-ориентированную систему или, как уже заметили, интерпретатор себя же. После этого понимание объектно-ориентированной, функциональной и других парадигм и обучение другим языкам становится гораздо проще.
>Чем же это? Вы случайно не путаете с вендузятнегами?
Не путаю. Виндузятнегов я понимаю, а лисперов - нет. Это меня беспокоит. Вроде все умные люди, а так носятся с этой игрушкой.
> Во-первых, он весьма прост.
Описание Common Lisp - это толстенный том (или 2?), о какой простоте речь?! Или ты имеешь в виду Маккартниевский Lisp 1.5 50-летней давности? Или Scheme?
> Назови языки и наречия, которые бы включали в себя сравнимое или меньшее количество базовых концепций
Так о каком Лиспе мы говорим? Что именно включаем в базовые концепции - пару, список? А навороты Common Lisp? А так - в ассемблере, Си, Паскале базовых концепций тоже не особо много.
> а потом давай сравним простоту испрользования названых на реальных задачах.
На _каких именно_ задачах? Я занимаюсь системами реального времени, куда там Лисп с его сборкой мусора воткунть? Если задача сводится к обработке списков - тогда Лисп рулит, поскольку для этого и сделан.
> весьма читабелен. Вместо зверинца из всяких разнообразных : ; {} () :: . -> = используется ()
Я уже писал - вс слишком однообразно, глазу не за что зацепиться. Вспоминается brainfuck ;)
> допускает весьма высокий уровень абстракции данных
Настолько субъективно, что...
> В пятых, нунах, запарилсо. Вот некоторые экзамплы
При всем уважении, это сферические кони в вакууме. В реальных задачах Лисп за 50 лет распространения не получил - это говорит о многом.
А вообще, хороших редакторов много (мой фаворит - MultiEdit, хотя я вне уже лет 10 не работал). Emacs - он не лучший, просто за счет почтенного возраста и открытости он накопил огромное количество модулей расширения.
> Виндузятнегов я понимаю, а лисперов - нет. Это меня беспокоит.
Первых понять проще, чем вторых? ;)
> Вроде все умные люди, а так носятся с этой игрушкой.
1. Выс забыли спросить, с чем носиться. 2. У Вас какие игрушки?
> Описание Common Lisp - это толстенный том (или 2?), о какой простоте речь?!
Описание какого языка (с описанием всех библиотек, необходимых для покрытия аналогичной функциональности) займт меньше? А прост, потому как код есть список и ничего более.
> Я занимаюсь системами реального времени, куда там Лисп с его сборкой мусора воткунть?
Написать свой для "систем реального времени" :)
> Я уже писал - вс слишком однообразно, глазу не за что зацепиться. Вспоминается brainfuck ;)
"Настолько субъективно, что..." :)
> В реальных задачах Лисп за 50 лет распространения не получил - это говорит о многом.
Ни о чм не говорит.
Даже если мух и не вспоминать, Вы же не будете настаивать, что всю историю человечества побеждали только лучшие идеи... ;)
> А вообще, хороших редакторов много (мой фаворит - MultiEdit, хотя я вне уже лет 10 не работал). Emacs - он не лучший, просто за счет почтенного возраста и открытости он накопил огромное количество модулей расширения.
И я лет ...надцать тому был "без ума" от ME. Так вот, если представить его OS + более приятный язык макросов - получим emacs ;) (ну а кто-то получит vi :)
> Во-первых, он весьма прост. Назови языки и наречия, которые бы включали в себя сравнимое или меньшее количество базовых концепций, а потом давай сравним простоту испрользования названых на реальных задачах. Особенно будем обращать внимание, насколько гиморно и отлично от "канонов" будет таково решение.
io ;-)
Но вообще говоря, концептуальная простота нафик не сдалась на практике. Тот же CL, при том, что он весь на себе же, нихрена не простой; а весьма простой Scheme за пределами кампусов никто не использует.
> Во-вторых, весьма универсален. Может быть есть такие задачи, решать которые на другом наречии было бы проще или результат получался бы лучше, но для лиспа круг задач, которые можно было бы решать с приемлемым качеством и за более чем приемлемое время, ИМХО наиболее широк.
Эээ. Про C++ или Java можно сказать то же самое теми же словами. "Можно сделать что угодно, ну и что, что перректально" - это не аргумент.
> В третьих, весьма читабелен. Вместо зверинца из всяких разнообразных : ; {} () :: . -> = используется (), и только там, где логически необходимо выделить определнную последовательность, из-за чего как число служебных элементов, требуемых синтаксисом языка а не описанием логики, так и их ассортимент, сведены к минимуму.
Это дело вкуса. Имхо, как раз наоборот, синтаксическая бедность затрудняет чтение. После Perl или C++ смотреть в прогу на CL - как читать по-русски без знаков препинания и заглавных букв. Для метопрограммирования это плюс, но оно всегда будет уделом подавляющего меньшинства, которое пишет библиотеки и трансляторы.
> В четвртых, допускает весьма высокий уровень абстракции данных. Т.е. требует наименьшего числа телодвижений при описании задачи и ещ меньшего дл изменения проги если задача немного поменялась.
И какие же абстрактные структуры данных нельзя сформулировать на C++ или Python? Ну, в плюсах синтаксис корявый - но и только; ну бедт треугольных скобочек столько же, сколько в лиспе прямых ;)
>> Виндузятнегов я понимаю, а лисперов - нет. Это меня беспокоит.
> Первых понять проще, чем вторых? ;)
Мне - да. Первые хотят комфорта, и ниипет. Чего хотят вторые - не понимаю.
>> Вроде все умные люди, а так носятся с этой игрушкой.
>1. Выс забыли спросить, с чем носиться.
8(
> 2. У Вас какие игрушки?
Linux 8) Моя игрушка в данный момент - Python. Но в основном работаю на Си/ассемблере/Си++
>> Описание Common Lisp - это толстенный том (или 2?), о какой простоте речь?!
> Описание какого языка (с описанием всех библиотек, необходимых для покрытия аналогичной функциональности)
Э, нет. То, о чем я говорил - это описание именно _языка_. Причем здесь библиотеки? Примеры языков с компактным описанием - Паскаль, Оберон/Оберон-2.
>> В реальных задачах Лисп за 50 лет распространения не получил - это говорит о многом.
> Ни о чм не говорит.
Ты просто не умеешь слушать ;( Практически у всех языков есть своя ниша - вычисления у Фортрана, системное программирование у Си, скриптование у Perl, бизнес-серверы у Java. А Lisp своей ниши не имеет. Точнее, она исчезла еще до всеобщего разочарования в AI.
Даже на несколько байт короче. Сервер писать неохота, но замечу, что используется "адаптированный" интерфейс к select. Ежели я возьму IO::Select и IO::Socket - то тоже получится быстрее и проще.
> Но вообще говоря, концептуальная простота нафик не сдалась на практике.
Опять "за всех"? :)
> Тот же CL, при том, что он весь на себе же, нихрена не простой; а весьма простой Scheme за пределами кампусов никто не использует.
Если не лезть сразу в макры/лупы/readtable и тому подобное - совсем простой :)
> Это дело вкуса. Имхо, как раз наоборот, синтаксическая бедность затрудняет чтение. После Perl или C++ смотреть в прогу на CL - как читать по-русски без знаков препинания и заглавных букв. Для метопрограммирования это плюс, но оно всегда будет уделом подавляющего меньшинства, которое пишет библиотеки и трансляторы.
Первым предложением сам вс сказал. :) А если при выборе языка на одном из первых мест стоит "вкус" кодера -... ну, значит такой кодер :) Опять же, не использование лиспа большинством говорит о большинстве, а не о лиспе :)
> > В четвртых, допускает весьма высокий уровень абстракции данных. Т.е. требует наименьшего числа телодвижений при описании задачи и ещ меньшего дл изменения проги если задача немного поменялась.
> И какие же абстрактные структуры данных нельзя сформулировать на C++ или Python? Ну, в плюсах синтаксис корявый - но и только; ну бедт треугольных скобочек столько же, сколько в лиспе прямых ;)
"уровень абстракции данных" != "абстрактные структуры данных" (как минимум - те себя уже огрничил - структуры ;)) Ну и речь в первую очередь о работе с этими данными, а не о них самих.
Чем лично мне "дался" лисп - наименьшим количествои ограничений на синтаксис :) Причм, именно после Python-а. А, ещ tcl был ("был" - в моей истории)
>> Но вообще говоря, концептуальная простота нафик не сдалась на практике.
> Опять "за всех"? :)
Концептуальная простота полезна только для написания и отладки абстракций "начального" уровня - того, что в "нормальных" языках собственно входит в язык - управляющих конструкций и стандартной библиотеки. Этим занимается (профессионально) очень мало людей, и мне, грубо говоря, пофик, насколько сложно было написать libc, и сделал ли это один человек за месяц или 100 за год - по сравнению с трудом по ее использованию это все равно ничтожные цифры.
>> Тот же CL, при том, что он весь на себе же, нихрена не простой; а
> Если не лезть сразу в макры/лупы/readtable и тому подобное - совсем простой :)
А нах он такой "простой" нужен-то? Accumulator passing style оттачивать? Велосипеды по 10 на день строить? Нах, нах.
>> Это дело вкуса. Имхо, как раз наоборот, синтаксическая бедность затрудняет чтение.
> Первым предложением сам вс сказал. :) А если при выборе языка на одном из первых мест стоит "вкус" кодера -... ну, значит такой кодер :) Опять же, не использование лиспа большинством говорит о большинстве, а не о лиспе :)
О да, все те же "миллионы мух". Тебе никогда не приходило в голову, что надо инструмент подбирать под человека, о не наоборот (ну, в пределах одного класса)? Споры о читабельности языков - это как спор "из чего правильнее делать рукоятку стамески - из дерева или из пластмассы". Если 90% столяров привыкли к пласстмассовым - зачем тратить лес?
> "уровень абстракции данных" != "абстрактные структуры данных" (как минимум - те себя уже огрничил - структуры ;)) Ну и речь в первую очередь о работе с этими данными, а не о них самих.
Главная сила лиспа - в возможности формировать сложные структуры и их удобно обрабатывать. А большинство алгоритмов более-менее одинаково записывается при одинаковых структурах на любом языке.
> Чем лично мне "дался" лисп - наименьшим количествои ограничений на синтаксис :) Причм, именно после Python-а. А, ещ tcl был ("был" - в моей истории)
Ты чего-то с чем-то путаешь. В Лиспе как раз огромное количество ограничений на синтаксис, в нем даже префиксный или инфиксный оператор определить нельзя по-человечески, и вообще имеется ровно один синтаксический элемент - список (ну, еще quoting, да); everything is a value, даже statement-ов нету нифига (не, не то, чтобы очень надо - но это таки ограничение).
> Мне - да. Первые хотят комфорта, и ниипет. Чего хотят вторые - не понимаю.
:)))) Ну, почти того-же :) Хотя вторых кое-что вс-же... того :)
> Моя игрушка в данный момент - Python.
Когда перестанет устраивать (именно как язык) - посмотрите ещ раз на лисп :)
> Э, нет. То, о чем я говорил - это описание именно _языка_. Причем здесь библиотеки? Примеры языков с компактным описанием - Паскаль, Оберон/Оберон-2.
Э нет. Там описание 1) языка; 2) интерпретатора; 3) компилятора (частично) [или 2+3 - среды]; 4) функций, которые во многих других языках вынесены в библиотеки; 5) сразу и не вспомню :) Ах, да - организации пар, списков и прочее
> Ты просто не умеешь слушать ;( Практически у всех языков есть своя ниша - вычисления у Фортрана, системное программирование у Си, скриптование у Perl, бизнес-серверы у Java. А Lisp своей ниши не имеет. Точнее, она исчезла еще до всеобщего разочарования в AI.
На данный момент из существующих реализаций лиспа получается хороший "клей" и инструмент для макетирования (создания прототипов). На встраиваемых (ecl, newlisp, может ещ что есть) можно писать логику и для монолитных программ.
Трудно говорить об отсутсвии ниши для лиспа, ибо "лисп" - это только синтаксис. CL - уже более жсткий стандарт. Конкретные реализации более годны для той или иной сферы, и не пригодны в других.
Я не говорю, что все _должны_ вс писать на лиспе. Я лишь предлагаю ознакомиться с языком :) От этого будет только польза.
> Когда перестанет устраивать (именно как язык) - посмотрите ещ раз на лисп :)
Для меня он игрушка в том смысле, что он мне нравится, хотя сам я на нем пишу немного. Но я в команде работаю, и когда я представляю, что прихожу и говорю: "С сегодняшнего дня переходим на CL", мне просто жалко ребят... Они начнут переходить, но будут меня тихо ненавидеть 8)
> из существующих реализаций лиспа получается хороший "клей" и инструмент для макетирования (создания прототипов).
Лисп может вс, вопросов нет. Но в любой области есть для него более удобная в использовании альтернатива.
> Трудно говорить об отсутсвии ниши для лиспа, ибо "лисп" - это только синтаксис. ... Конкретные реализации более годны для той или иной сферы, и не пригодны в других.
И это большая проблема, вытекающая (ИМХО) из минималистичности Лиспа. В результате имеем десятки несовместимых Лиспов, и это длится десятилетиями.
> Я лишь предлагаю ознакомиться с языком :)
С каким из многочисленных? ;) Имею (небольшой) опыт использования Guile.
> Концептуальная простота полезна только для написания и отладки абстракций "начального" уровня - того, что в "нормальных" языках собственно входит в язык - управляющих конструкций и стандартной библиотеки.
Вот именно наличие разнообразных управляющих конструкций и невозможность создания своих (кроме функций) и воротит от остальных языков (большинства из них).
> А нах он такой "простой" нужен-то?
Ха, а зачем нужен C/Pascal/etc без единой библиотеки? Значит, языком одним не ограничишься...
> Споры о читабельности языков - это как спор "из чего правильнее делать рукоятку стамески - из дерева или из пластмассы". Если 90% столяров привыкли к пласстмассовым - зачем тратить лес?
Очень правильно заметил - "привыкли". Единственная "достойная" причина :)
> Главная сила лиспа - в возможности формировать сложные структуры и их удобно обрабатывать. А большинство алгоритмов более-менее одинаково записывается при одинаковых структурах на любом языке.
Брр... "описание алгоритма... на языке" зависит от ограничений языка и может быть совсем не одинаково.
> В Лиспе как раз огромное количество ограничений на синтаксис, в нем даже префиксный или инфиксный оператор определить нельзя по-человечески, и вообще имеется ровно один синтаксический элемент - список
Зыть... В лиспе _единственное_ ограничение - единица кода есть список. Фактически требуется только... обозначить границы единицы кода (где это не требуется? :). Вс! Что значит "по-человечески"? Перепешите readtable и делайте что хотите :)
Что такое statement? (забыл - давно не пользовался... ;)
> Вот именно наличие разнообразных управляющих конструкций и невозможность создания своих (кроме функций) и воротит от остальных языков (большинства из них).
А _зачем_?
>> А нах он такой "простой" нужен-то?
> Ха, а зачем нужен C/Pascal/etc без единой библиотеки? Значит, языком одним не ограничишься...
Пилять, некоторые лисперы не могут запомнить ход дискуссии на два шага назад. Еще раз, изначальный агрумент: лисп простой, и это хорошо. Контраргумент: просто он только "без ничего", а "со всем" - такой же сложный, как все остальное. И где преимущетсво?
> Очень правильно заметил - "привыкли". Единственная "достойная" причина :)
Ровно то же самое, что выше: _что_ мы получим от перехода кроме гемора в процессе перехода?
> > Вот именно наличие разнообразных управляющих конструкций и невозможность создания своих (кроме функций) и воротит от остальных языков (большинства из них).
> А _зачем_?
Зачем инструкции есть? Не знаю... :) Зачем свои - чтобы было удобнее.
> Пилять, некоторые лисперы не могут запомнить ход дискуссии на два шага назад. Еще раз, изначальный агрумент: лисп простой, и это хорошо. Контраргумент: просто он только "без ничего", а "со всем" - такой же сложный, как все остальное. И где преимущетсво?
Ок. Лисп "без ничего" - проще некуда. А дальше - дальше сахар. Правда, иногда в виде монолитного куска - надо грызть, потом сладко станет :) И лисп "со всем" - это как плюсы с STL, BOOST и лысым хреном. ИМХО - проще разобраться с первым :) (могу быть и неправ)
> Ровно то же самое, что выше: _что_ мы получим от перехода кроме гемора в процессе перехода?
Вы - скорее всего ничего. Другие _могут_ получить свободу и выразительность. Но это не для "индусского" программирования.
> > Ровно то же самое, что выше: _что_ мы получим от перехода кроме гемора в процессе перехода?
> Вы - скорее всего ничего. Другие _могут_ получить свободу и выразительность. Но это не для "индусского" программирования.
Вам нужны программы красивые или работающие?
У меня все больше складывается впечатление, что большинство лиспофилов не сталкивалась с "промышленным" программированием больших долгоживущих проектов большими командами, а либо студенты, либо исследователи, т.е. люди, пишушие крутые сложные программы, но в одиночку и одноразово, написал-запустил-выкинул.
А такие мелочи, что кому-то вдруг может понадобиться понять и интегрировать кусок кода, написанный три года назад человеком, который два года как в Австралии, или что вам вдруг придется срочно искать замену трем коллегам, которые вдруг толпой ушли в другую контору - их не волнуют. Это все "индусское программирование".
Смотря для чего :) Убогий интерфейс иной проги делает е практически неработающей (ибо с ней никто не работает).
> У меня все больше складывается впечатление, что большинство лиспофилов не сталкивалась с "промышленным" программированием больших долгоживущих проектов большими командами, а либо студенты, либо исследователи, т.е. люди, пишушие крутые сложные программы, но в одиночку и одноразово, написал-запустил-выкинул.
А зачем архитектору по стройке ползать? :) Да, в данный момент лисп для "промышленного кодинга" не годится по той простой причине, что вы не найдте большую команду профессионалов. А "кодеры" почему-то лисп не осваивают - только джаву и инкарнации бэйсика. А вс остальное, что Вы написали - "от лукавого".
> А такие мелочи, что кому-то вдруг может понадобиться понять и интегрировать кусок кода, написанный три года назад человеком, который два года как в Австралии, или что вам вдруг придется срочно искать замену трем коллегам, которые вдруг толпой ушли в другую контору - их не волнуют. Это все "индусское программирование".
А этот бред вообще ни коим боком к языку (любому) не лежит. Если один урод написал пусть работающий но дурацкий код без комментариев и сопроводительной документации - чем вас другой язык спаст?
Про количество профессионалов я уже упомянул. Так Вас никто и заставляет вс писать на лиспе. Вам просто предлагают ознакомиться. А если вы сейчас заведте песню - "Нафиг мне лишняя сущность", то можете даже и накомиться - не поможет.
1) про интерпретатор - речь идет о реализации самого eval'a a не его тупом вызове, я буду стоя апплодировать человеку который сможет это сделать для руби например :)
2) LISP был языком системного программирования когда фортрана и С/С++ еще в проекте не было :)
3) когда системы на С++ становятся сложными - начинают пользовать boost и прочие темплейтные подпрыгивания чтоб сделать то что в функциональных языках есть с самого начала
> А этот бред вообще ни коим боком к языку (любому) не лежит. Если один урод написал пусть работающий но дурацкий код без комментариев и сопроводительной документации - чем вас другой язык спаст?
У меня есть мнение, что написать непонятный код на Java, и даже на C++ сложнее, чем на CL. Взрывчатки меньше, соглашений больше.
> Про количество профессионалов я уже упомянул. Так Вас никто и заставляет вс писать на лиспе. Вам просто предлагают ознакомиться. А если вы сейчас заведте песню - "Нафиг мне лишняя сущность", то можете даже и накомиться - не поможет.
Я знакомился, мне даже кое-что понравилось. Более того, я вам скажу, что в конторе, где я работаю, примерно половина людей знают лисп и/или хаскелль. Но не пишут на нем, по крайней мере по работе. А пишут на быдлоперле и быдлосиплюсплюс, и, даже, что ужасно, на яве.
И мне так и непонятно, почему мегалиспропрограммеры, которые столь горазды пропагандировать, не соберутся и не напишут нужную-и-крутую-прогу-на-лиспе-для-всех. А то я вот, навскидку, ничего на лиспе не знаю, кроме собственно реализаций CL и модов к емаксу. Вот для чего мне - гипотетически начинающему кодеру - учить лисп? Зная плюсы (условно говоря), я могу наваять себе перделку для KDE, а на перле - гостевуху на домашнюю страничку. А на лиспе? Аддон к GNUS? Нафик надо...
> Вс это можно сказать одной фразой: "Проггеров на Лиспе слишком мало".
Дело не только в этом. Все Java программисты нормальны одинаково, все лисповые программисты безумны по-разному, почти (С) Толстой. Т.е. шансы, что средний жавист разберется в произвольном куске кода выше, чем у лисперов. Имхо.
> Описание Common Lisp - это толстенный том (или 2?),
а описание жабы есть в сотнях тысячь разнообразных "асилим жабу за пару лет", "жаба бля полных дауноф" итп. Будем и дальше сравнивать сложность по объму сопутствующей мукулатуры?
> Или ты имеешь в виду Маккартниевский Lisp 1.5 50-летней давности? Или Scheme?
Common Lisp. С остальными незнаком пока.
>> а потом давай сравним простоту испрользования названых на реальных задачах.
> На _каких именно_ задачах?
Ну я привл выше пару примеров, достаточно общих ИМХО. Не нравятся - приведи свои.
> Я занимаюсь системами реального времени, куда там Лисп с его сборкой мусора воткунть?
Да фих ево знает. Я в РВ постольку поскольку, но слыхивал даже жабу туда примостить пытаюцо.
> Если задача сводится к обработке списков - тогда Лисп рулит, поскольку для этого и сделан.
Ну если уж ты сводиш задачи на "обработка списков", "обработка байтов" и тд...
> Я уже писал - вс слишком однообразно, глазу не за что зацепиться.
Ну глаз не зацепицо - значит не поцарапаецо, луче видеть будеш. Чем плохо?
> Настолько субъективно, что...
Порешай приведнное выше по перестановкам, чтобы отличить.
> При всем уважении, это сферические кони в вакууме. В реальных задачах Лисп за 50 лет распространения не получил - это говорит о многом.
А получил распространение висуалвасик. Это, да, говорит о многом. Но видимо ты услышал не то, про что это говорит.
Ты - доктор? Да ты (в лучшем случае) санитар. А скорее всего - больной, который где-то слямзил белый халат и теперь пудрит мозги честным пациентам.
>>> Во-первых, он весьма прост.
>> Описание Common Lisp - это толстенный том (или 2?),
> а описание жабы есть в сотнях тысячь разнообразных "асилим жабу за пару лет", "жаба бля полных дауноф" итп. Будем и дальше сравнивать сложность по объму сопутствующей мукулатуры?
Причем здесь общее количество макулатуры? Сравнивался объем описаний _языка_, всего одной книги для каждого языка.
> Ну если уж ты сводиш задачи на "обработка списков", "обработка байтов" и тд...
> Ну глаз не зацепицо - значит не поцарапаецо, луче видеть будеш. Чем плохо?
> Порешай приведнное выше
> А получил распространение висуалвасик.
Набор трескучих штампов. Нечего ответить - не отвечай.
> Ты чего-то с чем-то путаешь. В Лиспе как раз огромное количество ограничений на синтаксис, в нем даже префиксный или инфиксный оператор определить нельзя по-человечески, и вообще имеется ровно один синтаксический элемент - список (ну, еще quoting, да); everything is a value, даже statement-ов нету нифига (не, не то, чтобы очень надо - но это таки ограничение).
какая лажа млина! Пожалста определи на любом наречии синтаксис выражовывания типо "a<b=c<d..." где abcd... число а меж ими операции сравнения, и выражовывание значение true тогда и только тогда если выполняецо условие меж любой парой значений. Вот для лиспа:
> Контраргумент: просто он только "без ничего", а "со всем" - такой же сложный, как все остальное. И где преимущетсво?
А ты сравни лисп "без ничево" и <чтонибудь другое> "без ничево". Очевидно, ч сложность остатков при одинаковой функциональности будет примерно одинаковая, потому что не зависит от языка.
> Ты - доктор? Да ты (в лучшем случае) санитар. А скорее всего - больной, который где-то слямзил белый халат и теперь пудрит мозги честным пациентам.
:D
> Причем здесь общее количество макулатуры? Сравнивался объем описаний _языка_, всего одной книги для каждого языка.
Да потому что понаписать можно всякое. Дано на этом форуме кто-то заметил, что учеблики по лиспу начинаются с примеров написания интерпретаторов, а остальных - с хеловорда. Лично я освоил лисп в минимально необходимом объме для практического применения по паре страниц текста описания.
> Набор трескучих штампов. Нечего ответить - не отвечай.
>> учеблики по лиспу начинаются с примеров написания интерпретаторов, а остальных - с хеловорда.
> Мало в какие языки встроен интерпретатор их самих. И не такое уж это большое преимущество, ИМХО.
так дело не в интерпретаторе (кстати в питоне вроде есь подобная возможность) а в разнице уровней учебников. И поэтому не очень хорошая идея сравнивать два тома описания лиспа с книшкой "паскаль для всех" (непомню автора, в студенческие годы листал. Там с полсотни страниц наверное)
>> не очень хорошая идея сравнивать два тома описания лиспа с книшкой "паскаль для всех"
> Сравнивают не с "Паскаль для всех", а с "Сообщение о языке программирования Паскаль" Н.Вирта, которое _стандарт языка_.
И зря. Подход принципиально иной. Что есть в Паскале?
функции
процедуры
константы
"тело программы"
переменные
операторы работы с переменными
массивы
множества
блоки операторов (которые меж begin и end)
операторы для работы с ими (условные, цыклы многих видов, ...)
работа с файлами (выделяю отдельно ибо слишком уж отличается)
объектов и работы с памятью там вроде нету
Что есть в лиспе?
функции
переменные
списки
операторы работы с перемеными (связывание, итд)
операторы работы с списками (car, cdr, cons, итд)
вс?
>> Интересное ссылко, спасибо.
> Это не мне 8)
тебе тоже немного. Прочитал, понравилось. Но не во всм согласен. Например, вина за столь неэффективный програмж на всякой [ерунде] ложится ИМХО в основном на безграмотных "преподавателей", которые практики создания хотябы небольшой проги неимеют а о существовании лиспа просто не знают.
> какая лажа млина! Пожалста определи на любом наречии синтаксис выражовывания типо "a<b=c<d..."
Ну, ээ. То, что ты написал с (cmp) - это туфтень. это обычая higher order function, и инфиксными операторами тут и не пахнет.
А вот, скажем, у Haskell есть честный парсер с приоритетом операций, причем настраиваемый, и можно добавлять свои. Так что нефиг тута. А 'source filter' с 'eval' я могу и на перле и на питоне настрогать. Только вот это нафиг не нужно.
> Такое не следует говорить, если не видел хотя бы десяток-полтора Лисп-программеров _в работе_. Ты видел? Лично я не видел и одного :(
Полтора десятка лисп-программеров сразу? Это где такое?
Двух видел. Они еще и лингвисты при этом. Код их на лиспе я не читал, но перловый к внедрению непригоден - только методом "прийти с листочком, записать алгоритм со слов автора, переписать по-нормальному".
> так дело не в интерпретаторе (кстати в питоне вроде есь подобная возможность) а в разнице уровней учебников.
Ну вот, скажем, один из самых известных учебников по CL - это "Practical Common Lisp". И не сказать, чтоб в нем приводились шибко сложные программы (mp3 streaming server, насколько я помню, там самый большой проект). И есть учебники по C++, в которых за одну главу пишут интерпритатор бейсика (и, я думаю, интерпретатор Scheme нифига не сложнее, а наоборот - там парсер сильно проще. Даже если делать настоящий garbage collector).
А крутые книги типа SICP - они не про Лисп, они про программирование. Вы же не пишете все подряд на MIX только потому, что на нем примеры в AoCP?
> И поэтому не очень хорошая идея сравнивать два тома описания лиспа с книшкой "паскаль для всех" (непомню автора, в студенческие годы листал. Там с полсотни страниц наверное)
> У меня есть мнение, что написать непонятный код на Java, и даже на C++ сложнее, чем на CL. Взрывчатки меньше, соглашений больше.
У меня есть другое мнение. Итого - два разных мнения. Дальше? :)
> Я знакомился, мне даже кое-что понравилось. Более того, я вам скажу, что в конторе, где я работаю, примерно половина людей знают лисп и/или хаскелль. Но не пишут на нем, по крайней мере по работе. А пишут на быдлоперле и быдлосиплюсплюс, и, даже, что ужасно, на яве.
Познакомился, но "плюсов" не видишь (кое-что - не в счт)? "Не верю" :) Ну я тоже сижу в офисе под офтопиком - судьба такая.
> И мне так и непонятно, почему мегалиспропрограммеры, которые столь горазды пропагандировать, не соберутся и не напишут нужную-и-крутую-прогу-на-лиспе-для-всех. А то я вот, навскидку, ничего на лиспе не знаю, кроме собственно реализаций CL и модов к емаксу. Вот для чего мне - гипотетически начинающему кодеру - учить лисп? Зная плюсы (условно говоря), я могу наваять себе перделку для KDE, а на перле - гостевуху на домашнюю страничку. А на лиспе? Аддон к GNUS? Нафик надо...
"Пропагандировать" - это ты к свидетелям иеговы иди. Тебе просто предлагают поглубже узнать. Авось и пригодиться.
По поводу ссылки на РСДН - трындец! Пока народу не покажешь красную тряпку - нихрена не ведтся! Т.е. самому почитать, попробовать, составить мнение - анунах. А вто кто-то скажет - "Мля, да я на этом лям заработал" - все уже в очереди. НАФИГ! Не хотите - не читайте. Не знаете "зачем" - не читатйте. Прочитали и не поняли - забудьте! А то и так в comp.lang.lisp каждый nn-й пост - как бы хорошо поменять в лиспе синтаксис и прочий бред! <<Не нужен кодеру лисп - ни разу!>>
Да-да и для скольки языков? А вс остальное что есть в емаксе где? А если сам язык свой заделал насколько быстро модуль с поддержкой языка ты сделаешь? Не говоря уже про другие использования емакса. А вообще как там с автоматизацией?
Сообщение удалено tailgunner по причине '3.1 Дубль'
Ответ на: Re: Фраза о Лиспе... от yyk 28.09.2006 1:27:19
Re: Фраза о Лиспе...
>> Но ссылки на использование Лиспа в качестве языка системного программирования - в студию!
>А погуглить на тему лисп-машин?
Мне не надо по этому поводу гуглить - я это читал 15 лет назад. Но Лисп-машины - это слишком уж специфическое системное программирование. В самом деле - что еще может быть языком системного программирования Лисп-машины, кроме Лиспа? Интересуют ссылки на использование Лиспа для системного программирования машин с традиционной архитектурой (BitC - не предлагать, это не Лисп).
>> Но ссылки на использование Лиспа в качестве языка системного программирования - в студию!
>А погуглить на тему лисп-машин?
Мне не надо на эту тему гуглить - я это читал 15 лет назад. Но Лисп-машины - это слишком уж специфическое системное программирование. В самом деле - что еще может быть языком системного программирования Лисп-машины, кроме Лиспа? Интересуют ссылки на использование Лиспа для системного программирования машин с традиционной архитектурой (BitC - не предлагать, это не Лисп).
> По поводу ссылки на РСДН - трындец! Пока народу не покажешь красную тряпку - нихрена не ведтся! Т.е. самому почитать, попробовать, составить мнение - анунах.
Понимаешь ли, доверие спецу-практику, особенно практику в близкой тебе области, куда выше, чем к просто "Тебе просто предлагают поглубже узнать. Авось и пригодиться".
> А вто кто-то скажет - "Мля, да я на этом лям заработал" - все уже в очереди.
По ссылке как раз сказано, что не заработаешь на Лиспе, но тем не менее его надо знать (что само по себе заставляет предполагать искренность автора).
А Пол Грэм писал, как он заработал на Лиспе - и где очередь?
>Интересуют ссылки на использование Лиспа для системного программирования машин с традиционной архитектурой (BitC - не предлагать, это не Лисп).
1. Первые версии Лиспа работали близко к железу и были своего рода ассемблером (откуда пошли например car, cdr - по сути названия регистров одной древней машины :)
2. Common Lisp - это фактически оперционная система. Точка. Имея работающий интерпретатор можно решать любые задачи не покидая его. Вплоть до написания драйверов :).
3. BitC тоже лисп как и многие более экзотические диалекты - S-expressions и лямбда-исчисление - вот главные критерии. А типизация, объекты и прочая лабудень при необходимости добавляется макросами или добавлением встроенных функций в рантайм.
Какие "первые версии"? Lisp 1.5? Не исрользовали его для системного программирования, AFAIK.
> и были своего рода ассемблером
"Своего рода", я плакал. Все ЯВУ - "своего рода" ассемблеры. Для Smalltalk, Pascal, Java, Python - даже машины есть (виртуальные, правда).
> Common Lisp - это фактически оперционная система.
И Java тоже. И Smalltalk.
> Вплоть до написания драйверов :)
Не подскажешь, как там MMIO делается? DMA? Как прерываниями управлять? :-P
> BitC тоже лисп
Не Лисп это ни разу, только синтаксис похож. Но спорить не стану.
> типизация, объекты и прочая лабудень при необходимости добавляется макросами
Статическая типизаци - макросами? С этого места, пожалуйста, подробнее. Примеры есть? А то что-то мне кажется, что это то же самое, что сказать: "В Си можно добавить лямбды средствами Си" (ага, дописать написанный на Си компилятор).
> Познакомился, но "плюсов" не видишь (кое-что - не в счт)? "Не верю" :) Ну я тоже сижу в офисе под офтопиком - судьба такая.
Почему? Плюсы вижу. CLOS это клево, да и "местами функциональное" программирование - это удобно. Просто нет никакой связи между теми концепциями, которые реализованы в CL, и собственно CL. Я все то же самое могу и на перле делать, в синтаксисе, который мне ближе и роднее.
А по поводу пропаганды - судя по последнему абзацу, LISP для тебя - произведение искусства, которое не ценят и лапают грязными руками. Ну, ээ, это твои проблемы.
> очему? Плюсы вижу. CLOS это клево, да и "местами функциональное" программирование - это удобно.
Макры намеренно забыл? Их ты на чм будешь делать? Да и не уверен я - CLOS c MOP-ом точно на перле повторишь? CLSQL видел? И это сделаешь? (это я про readtable) И на что это вс вместе будет похоже? :)
> А по поводу пропаганды -...
Был несколько неправ - каюсь :) Хотя это был стб с подколом: "от противного" - ну не хотят лапать как не расписывай, вот и подумал - может хоть запретный плод будет сладок?... :) А раз ты не распознал, значит затея удалась ;)
> А Пол Грэм писал, как он заработал на Лиспе - и где очередь?
Ну, это очень уникальная ситуация - повторение невозможно :)
> Понимаешь ли, доверие спецу-практику, особенно практику в близкой тебе области, куда выше, чем к просто "Тебе просто предлагают поглубже узнать. Авось и пригодиться".
Да не об этом я. Автора статьи многое не устраивало в его работе, и он отправился на поиски решений своих проблем. А найденное его воодушевило на написание статьи. Но статья не поможет тем, кто не собирается ничего искать/иенять. А кто собирается - вс равно пойдт своим путм, пусть и с поправкой на ветер.
Частично по-этому я чуть раньше и "окрысился": если вы не знаете, зачем вам это - вам это не надо :)
> Но статья не поможет тем, кто не собирается ничего искать/иенять.
Таким нельзя помочь
> А кто собирается - вс равно пойдт своим путм, пусть и с поправкой на ветер.
Тот пост на RSDN ценен еще и тем, что в нем описан отказ от изобретения велосипеда. А те, кто "вс равно пойдут своим путем", могут наизобретать таких велосипдеов, что мало не покажется.
> Короче - примеры ОС (не для Лисп-машин), написанных на Лисп - в студию!
Ну какого лиха юзать высокоуровневое наречие там, где С справляецо гораздо лучше? Там разве есь необходимость в высокоуровневом? Кстати, Кроме С что ещ для осостроения юзают? Я знаю только в беосе пытались С++, причм неудачно.
>...ничего вс равно не наизобретают. Ибо бестолочи
Обычно они умные ребята, но не умеют оценивать сложность проекта, выгорают, слишком эмоционально относятся к результатам своей работы (если ее заканчивают)...
Но иногда из этого получается GCC/Linux/Python/SQLite 8)
> Я все то же самое могу и на перле делать, в синтаксисе, который мне ближе и роднее.
Вс правильно, на любом Тьюринг-полном можно, хоть на браинфаке. Кому какой синтаксис роднее - дело сугубо интимное, никто не заставляет. Это видимо твой пример сверху на перле? Извини, сразу не ответил, что задумался о превратностях судеб этого мира и позабыл.
Согласен, короче. Возможно даже работать будет быстрее или оперативы меньше отъест. Однако выглядит ИМХО довользо замысловато. Однако, запишем задачу о перестановках на (формализованном) человечьем языке:
совокупность из последовательностй, в которой каждый элемент - последовательность, составленная из одного из элементов исходной и набора перестановок оставшихся.
Корявая довольно фраза, и не всем сразу понятная (напишите луче кто сумеет, я сейчас изрядно не выспамшись :P), но зато практически 1:1 переводится в лисп-программу. Нет необходимости в $i, а переменные - не "хранилово данных" а символьное представление информации, т.е. их сущность ближе к математическому а не программистскому мировоззрению. Поэтому я утверждаю, что лиспологика ближе к человекологике, чем у например перла, а значит и переход от мыслей программиста к срокам кода - легче, и разница тем ощутимее чем сложнее задача.
>> жики плакали, кололись, но продолжали писать на плюсах.
> жики плакали, кололись, но продолжали хвалить Лисп.
жики всегда будут плакать и колоцо, потому что они жики. Такая уж их судьба, что вс сущее служит для их истязания и огорчения. Неважно, лисп это, плюсы, виндовсь или линух, важно, что они - жики. Быть уколотыми и заплаканными для них - их святой долг и вечная обязаннось, modus vivendi, единственно возможное состояние, основополагающий принцип, альфа и омега, причина и оправдание их бытия, настолько же неизбежный и фатальный, как и непогрешимость для миллионов мух.
> Макры намеренно забыл? Их ты на чм будешь делать? Да и не уверен я - CLOS c MOP-ом точно на перле повторишь? CLSQL видел? И это сделаешь? (это я про readtable) И на что это вс вместе будет похоже? :)
На перле есть source filters и парсер-перл-на-перле. Т.е., в сумме, тот же самый readtable. А MOP на перле есть готовый, даже несколько, IIRC, в т.ч. и с multiple dispatch. Тока в повседневной жизни это ненужно.
> На перле есть source filters и парсер-перл-на-перле. Т.е., в сумме, тот же самый readtable.
Примочки сбоку есть почти для всех. В CL это в самом языке и в любой момент. Да и генерить списки на языке для его обработки естественнее, чем генерить на перле перловый код. Или и здесь будешь спорить? :)
> Согласен, короче. Возможно даже работать будет быстрее или оперативы меньше отъест. Однако выглядит ИМХО довользо замысловато.
Это, блин, дословный перевод той лисповой программы на Perl. Прям совсем дословный, ну и слегка Perl Golf-овый - поэтому выглядит страшно. А если декомпозицию нормально сделать, то будет вполне красиво, будет две функции, правда.
> совокупность из последовательностй, в которой каждый элемент - последовательность, составленная из одного из элементов исходной и набора перестановок оставшихся.
Угу. Именно это там и написано, на перле. А $i там нужна только по сугубо исторческим причинам - вот такой странный в перле map (он использует переменную $_, поэтому при написании вложенных map-ов приходится заводить алиас, в данном случае - $i).
И ты забыл еще "а перестановка пустого списка одна - пустой список".
Цитата со ссылки: "Хотя мож от таково кода тож ктото проблюцо" - я среди этих "кто-то". Так писать может только лиспер, которого невозможность писать на любимом языке довела до тяжелой формы мизантропии.
Это наиболее приемлемый случай лапши. Я примерно так и делаю - и вс равно, с исключениями код выглядел бы проще, был бы короче, и менее error-prone - можно забыть проверку, и программа будет загадочно глючить, но необработанное исключение валит ее с хорошей диагностикой.
я в перле не шарю, однако глядя на перловый код в первую очередь бросается в глаза большое количество замысловатых символов, разнообразных скобок (хотя наезды на скопки свойственны обычно противникам лиспа) и использование индексов ([]?), явных числовых индексов (0..) и непонятных $i, $_, $#. Всего этого безобра прога на лиспе лишена. Кстати, как поместить в список в проге на перле один из элементов - тоже список? В лисповой проге тип значений в списке практически не влияет.
Этот код я произвл задолго до начала изучения лиспа. С исключениями в с++ были связаны какие-то траблы, которые в том числе не позволяли юзать исключения в с++ коде в беосе. Подробности щяс не помню, завтре найду ссылку если хош.
> я в перле не шарю, однако глядя на перловый код в первую очередь бросается в глаза большое количество замысловатых символов, разнообразных скобок (хотя наезды на скопки свойственны обычно противникам лиспа)
Я не против скобок. Я против того, чтобы все скобки были одинаковые, как раз.
> и использование индексов ([]?), явных числовых индексов (0..) и непонятных $i, $_, $#.
Ну непонятны они только незнающим язык. Что такое mapcar и lambda нелисперу тоже трудно понять с первого взгляда.
> Всего этого безобра прога на лиспе лишена.
Вы считаете элементы списка не с нуля? И, кстати, запоминание индекса эффективнее, чем запоминание значения. И вообще, моя программа не требует наличия оператора эквивалентности для целевого типа.
Хотя можно и по значению, в общем-то, сложность только в том, что в перле нету универсального оператора эквивалентности. Для строчек - вот так:
sub permute(@) { @_ ? map { my $e = $_; map {[$e, @$_]} permute(grep {$_ ne $e} @_); } @_ : []; }
Ну, можно передавать лишний параметр - функцию эквивалентности.
> Кстати, как поместить в список в проге на перле один из элементов - тоже список? В лисповой проге тип значений в списке практически не влияет.
Данная перловая прога оперирует списками списков внутри (ну, на самом деле они массивы массивов - но это ортогонально теме совершенно, как mutable списки они тоже работают).
Короче, если ты ничего кроме лиспа толком не знаешь - молись на него дальше.
Ну блин все ядро так написано. А код с исключениями, имхо, не проще, а наоборот вовсе.
Вот каков будет скелет для "получить три ресурса, каждый из которых может бросить исключение, поработать, освободить все по порядку, вернуть результат-или-код-ошибки", с использованием явной обработки исключений?
Если нету классов, деструкторов и стековой дисциплины - то обработка исключений дает тот еще спагетти, я на Java этого насмотрелся.
нет, элементы списка не нумерованы. Это ведь не массив.
> И, кстати, запоминание индекса эффективнее, чем запоминание значения.
не факт, что индексы вообще нужны в большинстве случяев. Когда нужны - можно поюзать массивы, но они нужны по-нстоязему редко.
> Для строчек - вот так:
И вс-таки, приведи код на перле, осуществляющий перестановку наборов произвольных типов данных. В том числе и смешанных (когда внутре и строки, и символы, и целое, и с плавающей точкой, и другие наборы данных)
> Короче, если ты ничего кроме лиспа толком не знаешь - молись на него дальше.
Приятно было побеседовать. Только не расстраивайся так, что слил, может в другой раз не сольш...
Сообщение удалено redvasily по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от bugmaker 29.09.2006 3:54:46
Re: Фраза о Лиспе...
Прошу прощения за опоздание :-)
Но вот тебе код на питоне, разумеется длиннее, чем на перле или
лиспе, но зато имхо лчуше читается, и возвращает не список, а
генератор и работает для списков гетерогенных :-) объектов
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
new = list(p)
new.insert(i, e[0])
yield new
> И вс-таки, приведи код на перле, осуществляющий перестановку наборов произвольных типов данных. В том числе и смешанных (когда внутре и строки, и символы, и целое, и с плавающей точкой, и другие наборы данных)
Пилять, твоя функция тоже нихрена не работает, насколько я помню CL: она сломается, если у тебя будет в исходных данных два элементы, которые eq между собой (набор типа "1 1 1 2 2 2 3 3 3"), нет?
А моя исходная программа с индексами таки работает со списками чего угодно изначально. В том числи и смешанными.
Прошу прощения за опоздание :-)
Но вот тебе код на питоне, разумеется длиннее, чем на перле или
лиспе, но зато имхо лчуше читается, и возвращает не список, а
генератор и работает для списков гетерогенных :-) объектов
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
new = list(p)
new.insert(i, e[0])
yield new
И что на лиспе решение лучше?
> Вот каков будет скелет для "получить три ресурса, каждый из которых может бросить исключение, поработать, освободить все по порядку, вернуть результат-или-код-ошибки", с использованием явной обработки исключений?
Ну, во-первых, RAII. Усли нет деструкторов:
try {
Resource r1 = new Res(), r2 = new Res2();
// используем ресурсы
}
finally {
if (r1 != null)
r1.dispose();
if (r2 != null)
r2.dispose();
}
По-моему, это лучше, чем куча goto. И с нами остается главное преимущество исключений - необработанное исключение нельзя пропустить, а проверку кода ошибки - элементарно. К тому же не надо постоянно возвращать код ошибки - это тоже легко упустить.
> Если нету классов, деструкторов и стековой дисциплины - то обработка исключений дает тот еще спагетти, я на Java этого насмотрелся.
> Пилять, твоя функция тоже нихрена не работает, насколько я помню CL: она сломается, если у тебя будет в исходных данных два элементы, которые eq между собой (набор типа "1 1 1 2 2 2 3 3 3"), нет?
А ты проверь :P
> А моя исходная программа с индексами таки работает со списками чего угодно изначально. В том числи и смешанными.
как поменять изходник, приведнный тобой, чтобы проверить?
ИМХО намного. По тем же причинам, что и перловое. Использование индексов и циклов делает решение менее гибким и более низкоуровневым. Т.е. вместо понятия "скомбинировать каждый элемент списка с перестановками оставшихся" получяем "для каждого элемента из перестановок всех элементов, кроме первого ... (продолжи сам)". Не в том дело, что код получяется короче/длиннее (в разумных пределах), а то, что он понятийно более чужд и требует большего числа "подробностей".
В 2.4 - еще нет. Но, по мнению многих, это ни разу не трабл. Я склонен с ними согласиться - слишком необычным должен быть usage pattern, чтобы это вызывало реальные проблемы. По линку я не нашел внятного объяснения, какие проблемы вызывало такое поведение. "Неаккуратненько" - да, пожалуй.
> Использование индексов и циклов делает решение менее гибким и более низкоуровневым.
Дейкстра писал: "Ненавижу, бл#, людей, которые вместо цикла пишут рекурсию, потому что computer scinence говорит, что рекурсия круче" ;) Мораль в том, что в циклах нет ничего плохого или "низкоуровневого@&
> Дейкстра писал: "Ненавижу, бл#, людей, которые вместо цикла пишут рекурсию, потому что computer scinence говорит, что рекурсия круче" ;) Мораль в том, что в циклах нет ничего плохого или "низкоуровневого@&
Ну нету так нету. По моему мнению, нужна очень веская причина чтобы вводить переменную - счтчик цыкла (да, чясто такая причина есть, но приведнный пример, как мы видим на примере лисп-кода, не тот случяй) и понятие "i-тый элемент". Так можно договориться до того, что на асме битики перебирать ни разу не низкоуровнево.
Начнм с того что с моей точки зрения питон ведт себя нормально. В 99.999999% случаев эта прооблема не возникает и никак не дат о себе знать.
А во вторых этот парень наступил на грабли и стал на ломаном английском доказывать разработчикам питона что они мудаки. Его послали, а он в отместку написал статью что питон гавно, а разрвботчики казлы вкючая Тима Питерса, автора Zen of Python.
В то время как если ещ погуглить на эту тему, то найдтся страница какого-то иностранного программиста (не помню точно откуда), и вот он тоже наступил на эти грабли, но вместо того чтобы плакаться всему миру в жилетку он написал патч который эту фигню исправляет и собачился на списке рассылки, чтобы его патч приняли.
> Начнм с того что с моей точки зрения питон ведт себя нормально. В 99.999999% случаев эта прооблема не возникает и никак не дат о себе знать.
Станеш ли ты юзать <чтонибудь другое> если оно в xx% случаев ведт себя нормально, а в оставшихся в произвольный момент времени может внезапно всбеситься и отрвать тебе яйтсы?
> Дык а я потом поинтересовался, ч _конкретно_ в м нетак и как надо было?
Тот вопрос я прохлопал, сорри. Что не так - выглядит уродски и понять трудно. Как надо - там проскакивал фрагмент, я его назвал "наиболее приемлемым вариантом лапши". Его еще называют "отвал по отсосу", "goto по отсосу@ 8)
> а в оставшихся в произвольный момент времени может внезапно всбеситься и отрвать тебе яйтсы?
Во-первых, отнюдь не в произвольный момент - точно известно, что приводит к такой ситуации. Во-вторых, оно не бесится и не отрывает яйца - оно всего лишь занимает область виртуальной памяти в (оправданной, ИМХО) надежде, что она тебе понадобится. А не понадобится - уйдет в swap-файл. А на корректность функционирования это не влияет.
Сообщение удалено redvasily по причине ''
Ответ на: Re: Фраза о Лиспе... от bugmaker 29.09.2006 14:20:13
Re: Фраза о Лиспе...
А ты не мог бы пояснить как именно у тебя комбинитурется первый
элемент списка с остальными элементами, а то я хоть убей не пойму как
работает версия на лиспе.
А на лиспе можно вернуть не список перестановок, а генератор?
А свое решение я сделал ещ до того как сказали здесь алгоритм, я
просто подумал что если это лисп то должна быть рекурсия, вот и
сделал тоже рекурсию :-)
def permutations(elems):
if not elems:
yield []
else:
for p in elems:
for lo in permutations(elems[:].remove(p)):
yield [p] + lo
Вот решение более похожее на твой алгоритм, но мне оно меньше
нравится, т.к. требуется чтобы над элементами списка была определена
операция сравнения, и чтобы не было элементов которые были бы "равны".
Соптимизировал сво оригинальное решение (с коллегами по работе :-)
выкинул две строки. Теперь получается вот что:
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
yield p[:i] + [e[0]] + p[i:]
А ты не мог бы пояснить как именно у тебя комбинитурется первый
элемент списка с остальными элементами, а то я хоть убей не пойму как
работает версия на лиспе.
А на лиспе можно вернуть не список перестановок, а генератор?
А свое решение я сделал ещ до того как сказали здесь алгоритм, я
просто подумал что если это лисп то должна быть рекурсия, вот и
сделал тоже рекурсию :-)
def permutations(elems):
if not elems:
yield []
else:
for p in elems:
for lo in permutations(elems[:].remove(p)):
yield [p] + lo
Вот решение более похожее на твой алгоритм, но мне оно меньше
нравится, т.к. требуется чтобы над элементами списка была определена
операция сравнения, и чтобы не было элементов которые были бы "равны".
Соптимизировал сво оригинальное решение (с коллегами по работе :-)
выкинул две строки. Теперь получается вот что:
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
yield p[:i] + [e[0]] + p[i:]
хм, почему? переписать на готы - так он вдвое длиннее будет как минимум. И готы в большом количестве и никак чтение проги не облегчают, это уж не только мо мнение.
> точно известно, что приводит к такой ситуации
главное, что точно неизвесно как избежать.
> оно всего лишь занимает область виртуальной памяти в (оправданной, ИМХО) надежде, что она тебе понадобится. А не понадобится - уйдет в swap-файл. А на корректность функционирования это не влияет.
не, ну хорош прог на питоне пока большая редкость. А если запустить хотя бы пяток, и каждая станет виртуалку подгребать "на всякой случяй" и в своп е класть за ненадобностью... нунах! Да и сама суть траблы не позволяет с доверием относиться к.
>> Станеш ли ты юзать <чтонибудь другое> если оно в xx% случаев ведт себя нормально, а в оставшихся в произвольный момент времени может внезапно всбеситься и отрвать тебе яйтсы?
Речь идт не о "яйтсы", а о неосвобождении памяти.
В данном конкретном случае я не вижу никаких проблем. Меня это устраивает. Не перводи разговор в другую плоскость.
Кстати, чего это ты про память в питоне вспомнил? Это типа заместо "Да питон ацки крут, базара нет, лисп отсасывает, но зато у вас память не освобождается" :-)
Судя по твоей ремарке "может, хто и сблюванет", ты и сам разделяешь это субъективное мнение 8)
>> понять трудно
> хм, почему? переписать на готы - так он вдвое длиннее будет как минимум.
Не вдвое - у тебя там до фига строк, на которых только '||' или скобки. Код с goto будет плотнее.
> И готы в большом количестве и никак чтение проги не облегчают, это уж не только мо мнение.
"Не только мое" - это отсылка к "GOTO statements considered harmful"? Там речь шла о других goto - когда с их помощью переходят в тело цикла, или организуют цикл, или используют для организации подпрограмм в подпрограмме. В длинном флэйме, который последовал, было здравое предложение отделить мух от котлет - есть "плохие" goto, а есть "хорошие". И использование goto для того, чтобы имитировать обработку исключений в Си - это, ИМХО, "хорошие" goto. Во всяком случае, там обработка ошибок отделена от "нормального случая", что есть гуд.
если рассуждать "низкоуровневыми" терминами: mapcan применяет функцию поочердно к каждому элементу списка, а результат выполнения затем присовокупляет к списку-результату. Пример:
входной список - (1 10 100), функция - формирует список их двух элеметов, x*2 и x*3. Результат:
(2 3 20 30 200 300)
mapcar делает в сущности то же самое, только если функция возвращает список, он присовокупляется к результату как список, а не просто добавляются элементы результата. Пример
в проге перестановки mapcar перебирает элементы входного и скармливает их по одному первой lambda (e). Она в свою очередь вызывает функцию перестановки для входново списка с выкинутым элементом е (это (permutations (remove e x :count 1 :test 'eq))). Получает оттуда список, состоящий из списков-вариантов перестановок. Затем к каждому из этих списков присобачивает в начало выкинутый элемент е. Т.е. lambda (p) получает в качестве аргумента список p который является одним из вариантов перестановок исходного списка из которово выкинули элемент е. В результате, на выходе из mapcar - список из перестановок исходного списка, из которого выкинули е и затем добавили его к началу каждого. А на выходе из mapcan - все варианты данного действа, совершнного с каждым элементом входного списка поочердно.
> твой алгоритм
дело не в алгоритме, а в используемых понятиях. Один и тот же алгоритм можно записать на асме, и на сях и на чм угодно и работать он будет одинаково. Только на асме тебе придтся перестанавливать байтики, на сях - значения переменных, а на лиспе - применять функции к множеству. И, соответственно, на асме запись алгоритма для набора целых и для набора строк будет отличятся весьма и весьма, на сях - так, немного, а на лиспе - ровно настолько, насколько сама задача этого требует. Например если вместо 'eq записать '=, это будет работать только с целыми, а 'string= только с строками.
> а асме запись алгоритма для набора целых и для набора строк будет отличятся весьма и весьма, на сях - так, немного, а на лиспе - ровно настолько, насколько сама задача этого требует.
> Речь идт не о "яйтсы", а о неосвобождении памяти.
Следует ли это понимать как "ну не ослободилась память, да и йух с ей"?
> В данном конкретном случае я не вижу никаких проблем.
Потому что непосредственно йайтсы не рискуют?
> Не перводи разговор в другую плоскость.
Почему? Я достаточно объмен чтобы весть разговор в нескольких плоскостях единовременно. Ты нет?
> Кстати, чего это ты про память в питоне вспомнил? Это типа заместо "Да питон ацки крут, базара нет, лисп отсасывает, но зато у вас память не освобождается" :-)
Ну да, типо такого. С небольшими поправками. ИМХО траблы с оперативой - вещ достаточно суровая, чтобы юзать подверженное ей в продакшне. Когда за подобное действие проги разработчику вполне могут закащики йайтсы поотрвать. Это только не считая того, что я не вижу _принципиальной_ разницы меж питоном и тем же пхп например. А лиспом - вижу.
>> а асме запись алгоритма для набора целых и для набора строк будет отличятся весьма и весьма, на сях - так, немного, а на лиспе - ровно настолько, насколько сама задача этого требует.
> ИМХО траблы с оперативой - вещ достаточно суровая, чтобы юзать подверженное ей в продакшне.
@#$%, это НЕ трабл с оперативой. Просто программа будет занимать тот объем (виртуальной!) памяти, который ей _максимально_ нужен. И если ты запустил 5 задач, и сразу увидел, что у тебя не хватило памяти - это гораздо лучще, чем пускать 5 задач у себя и видеть, что вс ОК, а у заказчика эти 5 задач будут иногда отправлять систему в глубокий своп. Просто из-за того, что там фишка ляжет по-другому. А с текущим питоновским распределением памяти фишка _всегда_ ложиться одинаково и _предсказуемо_. Так что это не трабл ни разу.
> Судя по твоей ремарке "может, хто и сблюванет", ты и сам разделяешь это субъективное мнение 8)
Я просто признаю и соглашаюсь, что таковое мнение может иметь место. Раз уж я понаписал такое, значит и субъективно считаю приемлемым, и объективных проблем не вижу.
> Не вдвое - у тебя там до фига строк, на которых только '||' или скобки. Код с goto будет плотнее.
Какой смысел пустые/полупустые строки щитать? По символам ИМХО минимум вдвое длиньше будет.
> goto
А ты вс-таки попробуй переписать приведнный мной участок с готами, и сравним. Ч зря езыками трепацо? утя сво ИМХО умя сво, и пока кина не будет можно долго сопли жувать по этому поводу.
Ну, принято так - даже полупустая строка считается строкой кода.
> По символам ИМХО минимум вдвое длиньше будет.
Ну, это несерьезно. Если считать по символам (== литерам), то программа вывода на печать письма Татьяны к Онегину будет сложнее твоего кода престановок. Считать пос символам (== токенам языка) - вряд ли будет преимущество у любого из вариантов. Считать надо по "времени понимания средним программистом", но как это посчитаешь?
> росто не представляю, как в их в одном списке и целое и строка и например структура уживцо
Если _список_ полиморфный, то да, трабла... Хотя через указатели, с нужными операторами - должно получиться.
Но (как я понял) ты говорил об _алгоритмах_, определенных на НЕ-полиморфных множествах ("если вместо 'eq записать '=, это будет работать только с целыми, а 'string= только с строками.").
> не тхреадсейфное. фтобку
Разве? Какие-то древние версии - не были, а современные - уже вполне.
Мы коллеги redvasily по работе :-)
После часа изысков удалось сократить функцию до одной строки:
def permutations(e):
if len(e) == 1 or e.insert(0, reduce(lambda x, y: x + y, [[list(p)[:i] + [e[0]] + list(p)[i:] for i in xrange(len(e))] for p in permutations(e[1:])])) is None: return list(e[0])
(для нашего уважаемого коллеги)
Невозможное возможно!!!!!
> Ну, принято так - даже полупустая строка считается строкой кода.
лиспопрогу я могу всю в одну строку записать, а на сях - всякие #include и #ifdef есь. Вот ещ тогда преимущество лиспа: любая прога на сях длиннее любой проги на лиспе!
> дык по ссыле у чела трабла есь или он выдумал е?
В его голове - точно есть. Он ее объяснить не может/не хочет. Из всего нытья я понял одно: "Python неаккуратненький, плохаааая змея!"
> любая прога на сях длиннее любой проги на лиспе!
Ну, если мерять так, как выгодно - оно конечно ;)
Я тут стал внималтельно смотреть на твой фрагмент кода с целью переписать - не понял, зачем там присваивания "i = get_uid", "i = d_mode", "i = d_sock"? В них какой-то эзотерический смысл, которого я не догоняю?
> Но (как я понял) ты говорил об _алгоритмах_, определенных на НЕ-полиморфных множествах
Я совсем иное имел в виду. В лиспе _я_ решаю, полиморфное или нет. Если например я щитаю что в этом списке должны быть только строки, могу ввести такое ограничение "естественным" способом, без применения проверки к каждому элементу.
>> не тхреадсейфное. фтобку
> Разве? Какие-то древние версии - не были, а современные - уже вполне.
Ну тогда ладно, замнм. вс равно в лиспе ООП настолько лучше реализовано, что с++ никакой stl не спаст.
> Я тут стал внималтельно смотреть на твой фрагмент кода с целью переписать - не понял, зачем там присваивания "i = get_uid", "i = d_mode", "i = d_sock"? В них какой-то эзотерический смысл, которого я не догоняю?
i - этап выполнения этого. Этапы маркированы get_uid, d_mode итд. На каждом этапе выполнения есь набор заюзаных ресурсов. Если где-то посередине ашыпко, можно потом сообщить где именно ч нетак и походу освобождать ресурсы типо
Потому что в лиспе есь возможность определить, с каким типом связана переменная. А в с++ нету возможности определить, на куда указывает тот же void* например.
> Потому что в лиспе есь возможность определить, с каким типом связана переменная.
Динамическая типизация, вс понятно. Но и многие вкусности CLOS - они от динамической типизации и динамической природы самого языка.
А статическая типизация - очень полезная вещь, особенно при рефакторинге (ненавижу это слово :( ). Убил бы за возможность статической типизации в Python.
> На каждом этапе выполнения есь набор заюзаных ресурсов
Ну... то есть фрагмент, который ты привел - не полон?
почти полон. Я потом внутро if() связанное с i дописывал, но это не суть важно. Если твой аналог будет давать информацию на каком этапе и по какой причине глюк (например, нет прав доступа или ещ что), т.е. устанавливать i в корректное значение, этого вполне достаточно будет.
>>После часа изысков удалось сократить функцию до одной строки:
> Ребята, вам на конкурс Obfuscated Python. Не думал, что даже на Python можно писать настолько непонятно 8)
Да уж отожги так отожгли. Хотя справедливости ради надо сказать что по части Obfuscated Code Перл вне конкуренции, например в этой ветке перл вообще больше смахивал на brainfuck :-)
> ошибкам нинакой компилер не помеха, проверето неоднократно
Ааааа.... вот оно в чем дело :) Статическая типизация - это как раз _помеха_ ошибкам. А ты перепутал ее с _гарантией_ от ошибок. Никакой компилятор не является гарантией - но они даже и не претендуют.
> А динамическая типизация _обычно_ не нужна. И уж точно - она позволяет оставаться в программе ошибкам, которые элементарно отлавливаются компилятором.
Ты не видел boo?
Язык с закосом под Python но со статической тиизацией, но для переменной можно сказать что у не тип duck и именно эта переменная становится динамически типизованой. Прикольно.
> Язык с закосом под Python но со статической тиизацией
Не видел. Мне нужно именно в Питоне, с его инструментальной поддержкой и библиотеками. В принципе, мне хватило бы даже checker'а вроде Си-шного lint. Но ни pychecker, ни pylint такого не умеют :(
Сообщение удалено tailgunner по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от bugmaker 29.09.2006 17:23:28
Re: Фраза о Лиспе...
> А ты вс-таки попробуй переписать приведнный мной участок с готами, и сравним.
Не могу поверить, что повелся на это 8)
#define BAIL_OUT(l, errmsg...) do { fprintf(stderr, errmsg); goto l; } while (0)
s = -1;
dpy = getenv("DISPLAY");
if (!dpy)
BAIL_OUT(err, "DISPLAY variable is not set\n");
else if ((pwd = getpwuid(geteuid()) == NULL)
BAIL_OUT(err, "You're homeless, pasportless, jobless :D\n");
snprintf(dstdir, UNIX_PATH_MAX, "%s/%s%s-%s", tmpdir, COMM_DIR, dpy, pwd->pw_name);
/* это должно быть отдельной функцией */
if (stat(dstdir, &fs) == -1)
if (errno = ENOENT) {
if (mkdir(dstdir, S_IFDIR | S_IRWXU) == -1)
BAIL_OUT(err_d_create, "can't create %s\n", dstdir);
if (stat(dstdir, &fs) == -1)
BAIL_OUT(err_d_stat2, "can't stat created %s\n", dstdir);
}
else
BAIL_OUT(err, "stat %s failed", dstdir);
if (geteuid() != fs.st_uid)
BAIL_OUT(err_get_uid, "EUID/FS_UID mismatch (%d/%d)\n", geteuid(), fs.st_uid);
else if (getegid() != fs.st_gid)
BAIL_OUT(err_get_gid, "EGUID/FS_GUID mismatch (%d/%d)\n", getegid(), fs.st_gid);
else if (S_IFDIR != (S_IFDIR & fs.st_mode))
BAIL_OUT(err_d_isdir, "%s not a directory\n", dstdir);
else else if (S_IRWXU != (0777 & fs.st_mode) && chmod(COMM_DIR, S_IRWXU) == -1)
BAIL_OUT(err_d_mode, "wrong mode %o, and chmod failed\n", fs.st_mode); )
snprintf(sa.sun_path, UNIX_PATH_MAX, "%s/%s", dstdir, COMM_SOC);
DEBUG_MSG(printf ("sock is %s\n", sa.sun_path));
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s == -1)
BAIL_OUT(err_d_sock);
/* странный какой-то код - либо мы присоединяемся к серверу, либо становимся им */
connect(s, (struct sockaddr *) &sa, sizeof (sa));
Кстати - чтобы это переписать, мне понадобился почти час. Если считать меня средним Си-программистом, делай выводы о том, каково сопровождать твои программы ;)
Сообщение удалено tailgunner по причине '3.4 Пустое сообщение'
Ответ на: Re: Фраза о Лиспе... от bugmaker 29.09.2006 17:23:28
Re: Фраза о Лиспе...
> А ты вс-таки попробуй переписать приведнный мной участок с готами, и сравним.
Не могу поверить, что повелся на это 8)
#define BAIL_OUT(l, errmsg...) do { fprintf(stderr, errmsg); goto l; } while (0)
s = -1;
dpy = getenv("DISPLAY");
if (!dpy)
BAIL_OUT(err, "DISPLAY variable is not set\n");
else if ((pwd = getpwuid(geteuid()) == NULL)
BAIL_OUT(err, "You're homeless, pasportless, jobless :D\n");
snprintf(dstdir, UNIX_PATH_MAX, "%s/%s%s-%s", tmpdir, COMM_DIR, dpy, pwd->pw_name);
/* это должно быть отдельной функцией */
if (stat(dstdir, &fs) == -1)
if (errno = ENOENT) {
if (mkdir(dstdir, S_IFDIR | S_IRWXU) == -1)
BAIL_OUT(err_d_create, "can't create %s\n", dstdir);
if (stat(dstdir, &fs) == -1)
BAIL_OUT(err_d_stat2, "can't stat created %s\n", dstdir);
}
else
BAIL_OUT(err, "stat %s failed", dstdir);
if (geteuid() != fs.st_uid)
BAIL_OUT(err_get_uid, "EUID/FS_UID mismatch (%d/%d)\n", geteuid(), fs.st_uid);
else if (getegid() != fs.st_gid)
BAIL_OUT(err_get_gid, "EGUID/FS_GUID mismatch (%d/%d)\n", getegid(), fs.st_gid);
else if (S_IFDIR != (S_IFDIR & fs.st_mode))
BAIL_OUT(err_d_isdir, "%s not a directory\n", dstdir);
else else if (S_IRWXU != (0777 & fs.st_mode) && chmod(COMM_DIR, S_IRWXU) == -1)
BAIL_OUT(err_d_mode, "wrong mode %o, and chmod failed\n", fs.st_mode); )
snprintf(sa.sun_path, UNIX_PATH_MAX, "%s/%s", dstdir, COMM_SOC);
DEBUG_MSG(printf ("sock is %s\n", sa.sun_path));
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s == -1)
BAIL_OUT(err_d_sock);
/* странный какой-то код - либо мы присоединяемся к серверу, либо становимся им */
connect(s, (struct sockaddr *) &sa, sizeof (sa));
Кстати - чтобы это переписать, мне понадобился почти час. Если считать меня средним Си-программистом, делай выводы о том, каково сопровождать твои программы ;)
> А ты вс-таки попробуй переписать приведнный мной участок с готами, и сравним.
Не могу поверить, что повелся на это 8)
#define BAIL_OUT(l, errmsg...) do { fprintf(stderr, errmsg); goto l; } while (0)
s = -1;
dpy = getenv("DISPLAY");
if (!dpy)
BAIL_OUT(err, "DISPLAY variable is not set\n");
else if ((pwd = getpwuid(geteuid()) == NULL)
BAIL_OUT(err, "You're homeless, pasportless, jobless :D\n");
snprintf(dstdir, UNIX_PATH_MAX, "%s/%s%s-%s", tmpdir, COMM_DIR, dpy, pwd->pw_name);
/* это должно быть отдельной функцией */
if (stat(dstdir, &fs) == -1)
if (errno = ENOENT) {
if (mkdir(dstdir, S_IFDIR | S_IRWXU) == -1)
BAIL_OUT(err_d_create, "can't create %s\n", dstdir);
if (stat(dstdir, &fs) == -1)
BAIL_OUT(err_d_stat2, "can't stat created %s\n", dstdir);
}
else
BAIL_OUT(err, "stat %s failed", dstdir);
if (geteuid() != fs.st_uid)
BAIL_OUT(err_get_uid, "EUID/FS_UID mismatch (%d/%d)\n", geteuid(), fs.st_uid);
else if (getegid() != fs.st_gid)
BAIL_OUT(err_get_gid, "EGUID/FS_GUID mismatch (%d/%d)\n", getegid(), fs.st_gid);
else if (S_IFDIR != (S_IFDIR & fs.st_mode))
BAIL_OUT(err_d_isdir, "%s not a directory\n", dstdir);
else else if (S_IRWXU != (0777 & fs.st_mode) && chmod(COMM_DIR, S_IRWXU) == -1)
BAIL_OUT(err_d_mode, "wrong mode %o, and chmod failed\n", fs.st_mode); )
snprintf(sa.sun_path, UNIX_PATH_MAX, "%s/%s", dstdir, COMM_SOC);
DEBUG_MSG(printf ("sock is %s\n", sa.sun_path));
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s == -1)
BAIL_OUT(err_d_sock);
/* странный какой-то код - либо мы присоединяемся к серверу, либо становимся им */
connect(s, (struct sockaddr *) &sa, sizeof (sa));
if (errno == ECONNREFUSED)
BAIL_OUT(err_d_connrefused, "connection to %s refused", sa.sun_path);
errno = EADDRINUSE;
unlink(sa.sun_path);
if (bind(s, (struct sockaddr *) &sa, sizeof (sa)) == -1)
BAIL_OUT(err_d_bind, "can't bind %s", sa.sun_path);
else if (listen(s, 1) == -1)
BAIL_OUT(err_d_listen, "can't listen on %s\n", sa.sun_path);
return s;
err_d_connrefused:
err_d_bind:
err_d_listen:
// ....
if (s != -1)
close(s);
return -1;
Кстати - чтобы это переписать, мне понадобился почти час. Если считать меня средним Си-программистом,
делай выводы о том, каково сопровождать твои программы ;)
Почему мои? твои. Согласись, твой вариант более многабукф... Да ещ скобок маловато, а любой продвинутый редактор умеет парность скобок проверять и текст выделять меж ими итд...
Мой вариант пока что никто не пытался понять и переписать. На переписывание твоего варианта я потратил около часа - из них на набор текста минут 10-15.
> Согласись, твой вариант более многабукф
Насчет букф - согласен. Насчет симолов/токенов - не согласен.
Фишка-то именно в том, чтобы понять из _кода_. Когда в реальности кто-то полезет разбираться, тебя может уже не быть под рукой 8)
> Там вродн прозрачно вс.
Но это записано так, как я за 15 лет ни разу не видел. Похоже на работу студента, который открыл для себя оператор "," и то, что "||" и "&&" вычисляют/не вычисляют свои правые операнды при нужде.
> Мне нужно именно в Питоне, с его инструментальной поддержкой и библиотеками. В принципе, мне хватило бы даже checker'а вроде Си-шного lint. Но ни pychecker, ни pylint такого не умеют :(
А как ты себе вообще представляешь Питон со статической типизацией? Это уже не питон будет вовсе...
P.S. Интересно, а почему здесь уже 187 сообщений, а мы вс ещ не в десятке? :-)
> Интересно, а почему здесь уже 187 сообщений, а мы вс ещ не в десятке?
это несомненно заговор. Но мы так просто не сдадимся, правильно?
Итак, в нашей дальнейшей программе...
Ну вот например, кусок кода, взятый из
http://en.feautec.pp.ru/store/fun-of-newlisp.html
куда он попал в свою очередь из лоровского же флейма
(do-select ((CustomerName CustomerEmail)
:from Customers
:where (> CustomerAge 100))
(send-email CustomerEmail
:subject "Congratulations!"
:body (format nil
"Dear ~A, you won a prize! Call ~A."
CustomerName company-phone)))
Выбирает из дазы банных всех пиплов с возрастом более 100 лет
и отсылает им емайл. Ну-ка, как это будет выглядеть на перле/питоне?
> Кстати, в рамках PyPy есть нечто, называемое RPython. Мне _кажется_, это Питон со статической типизацией.
PyPy жесть. Причм насколько я понимаю в RPython даже настраивается сколько ты позволяешь динамизма в коде. Но вот будет ли он при этом отлавливать ошибки как компилятор и что вообще из этого получится непонятно.
Я надеюсь на Python для .NET или Java c возможностью загрузки бинарных расширений от CPython-а, или все писатели расширений перейдут на rctypes и тогда будет мне счасте.
Да я уже и не знаю 8/ По работе-то я драйверы пишу, да проги управления большими шкафами с железом. В основном - Си/Си++, ассемблер. Питона там относительно немного - тесты, морды. Питон - это больше для души. Поэтому и участвую во флэймах вроде этого (плюс полезные линки попадаются :))
Пишешь модуль расширения на питоне с использованием ctypes, а затем их
extension compiler компилирует то что ты написал в натуральный машинный код и заменяет вызовы ctypes на нативные вызовы этих функций.
Таким образом модуль расширения написанный на ctypes сможет быть использован (по идее) на любой сборке PyPy в том числе и .NET и Java, когда такие появятся. Имхо должны появиться.
Заодно я так понимаю что они могут сделать Питон без GIL (OMFG, ПИТОН БЕЗ GIL!!!)
Он мне кажется (субъективно) таким неуклюжим, всякие эти многочисленные xrange xlat [a:b]... А ништяков вроде комплексных чисел и rationalize нету совсем.
Ну нифига себе, если xrange и [a:b] неуклюжие, то можно попросить пример уклюжих вещей, которые решают те-же задачи.
Например:
for i in xrange(10): pass
Здесь xrange(10) возвращает итератор, который пробегает от 0 до 10, не включая 10.
В C ты пишешь:
for (int i = 0; i < 10; ++i) ;
Имхо С версия гораздо более неуклюжая.
[a:b] это слайс, т.е. для списка это новый список состоящий из элементов от а до b, исключая b. Единственный язык где я видел что-то подобное это Matlab, там это сделано точно так же, но вкючая b. Имхо в питоне лучше, т.е существует инвариант:
Само собой, но зачем сравнивать с макроассемблером? У С совершенно иная ниша ведь. Лиспаналог: (dotimes (x 10) ...тут х меняецо от 0 до 9...)
>[a:b] это слайс, т.е. для списка это новый список состоящий из элементов от а до b, исключая b
(subseq x a b). b можно упустить, и тогда вернтся подпоследовательнось от а до конца
> Где это сделано лучше?
Это вс простые вещи, их трудно сделать как лучше так и хуже. Видиш, в лиспе есть их полные аналоги. Разница в том, что, как мы убедились на примере перестановок, эти далеко не всегда нужны и их применение - оптимальный способ. Поэтому то и сложно челу, незнакомому с лиспом, объяснить, чем этот самы лисп лучше. Так же сложно, как например вендузятнегу объяснить ч такое виртуальные рабочие столы и почему без них неудобно.
> Чем это не устраивает?
Да фих ево знаит, злой я какойто сдня.
>>> from math import sqrt
>>> sqrt(2)
1.4142135623730951
>>> sqrt(-2)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: math domain error
>>>
Так получается что в питоне два разных корня?
>>[a:b] это слайс, т.е. для списка это новый список состоящий из элементов от а до b, исключая b
>(subseq x a b). b можно упустить, и тогда вернтся подпоследовательнось от а до конца
В питоне тоже возможны записи x[:], x[:b], x[a:], что означает слайс по всему списку, от начала до b, и от a до конца соответственно.
Пользователь может определить такие опреаторы для своего класса.
А как дела с полиморфизмом у (subseq x a b) в Лиспе?
> Это вс простые вещи, их трудно сделать как лучше так и хуже. Видиш, в лиспе есть их полные аналоги. Разница в том, что, как мы убедились на примере перестановок, эти далеко не всегда нужны и их применение - оптимальный способ.
На данном примере я не увидел никакого преимущества Лиспа над Питоном.
Как нибудь надо будет асилить Common Lisp, пока что я могу написать Hello World на Схеме. :-)
А по поводу sqrt, что тебе не нравится. Есть пакет cmath работающий с комплексными числами, есть пакет math работающий с действительными числами. Имхо правильно, я думаю что в большинстве случаев люди хотят чтобы sqrt(-1) вызывал исключение, а не возвращал j. Хочешь j импортируй cmath
> А как дела с полиморфизмом у (subseq x a b) в Лиспе?
это как?
> На данном примере я не увидел никакого преимущества Лиспа над Питоном.
Так я про ч и говорю, если есть желание заморачиваться с байтиками, шпынять их туда-сюда поштучно, преимощества нету. Просто в лиспе в отличие от бейсикоподобных наречий эти шпыняния-добровольны и факультативны.
> я думаю что в большинстве случаев люди хотят чтобы sqrt(-1) вызывал исключение, а не возвращал j
>> я думаю что в большинстве случаев люди хотят чтобы sqrt(-1) вызывал исключение, а не возвращал j
>странное мягко говоря желание, ну да ладно.
Нормальное желание. То, что sqrt бросает исключение на -1, позволяет отлавливать ошибки в вычислительном коде, который работает с действительными числами. Хочешь комплексных - cmath.
> Если алгоритм принципиально требует вещественных, ашыпка позже выскочит вс равно
Ну, не специалист по вычислениям - но, ИМХО, ты просто получишь на выходе комплексное число. Или ошибка выскочит много позже, соответственно искать будет труднее. Насчет лишних граблей - не понял.
Не спорю, очень хороший язык Лисп. Легок в освоении -- я лично осваивал его три раза ;-).
Однако, как программиста-практика интересует вот одна хрень. Даже две. Не, три. Ну в общем, как там насчет биндингов, ну, хотя бы к GTK? Или, хотя бы Qt, если кому по вкусу. Хотя я боюсь, что если скрестить Лисп и С++, то получится смесь почище гремучей. Возможно, как вопрос номер раз с половиной -- как там насчет биндингов к MySQL (PostgreSQL, SQLite, Oracle, MSSQL по вкусу)?
Ладно, в более общем виде: как оно ничего оптимизировать Лисп-программу за счет реализации отдельных особо тормознутых участков на С/С++/Фортране? Можно считать это вопросом номер два, хотя он всего лишь развивает вопрос номер раз: как оно ничего, не факториал высчитать, а системку из 10000 (диф)уравнений решить? Хватит мощи? Ну а если матрицы аналогичного размера перемножить? Как оно? А ежели задача еще хорошо распараллеливается? Есть какой-нибудь аналог ПарСи или ПарФора, какой-нибудь ПарЛисп? Или чистых теоретиков такой инструмент не интересует?
Ну а вопрос номер три меня, как практикующего программиста, особенно интересует: для Апача уже сделали Лисп-модуль? Или, как все настоящие мущины, исключительно через CGI? И много ли сайтов слабали на таком Лиспе?
Если корень от отрицательного числа бертся неправомерно, очевидно что ашыпка произошла намного раньше, чем взятие корня. Поэтому, ексепшн в таком случае по-любому малоинформативен. Проще либо проверять данные на валиднось либо уж отлаживать с самово начяла, получив комплексное там, где ево не должно быть. При желании, можно нащлать строчку кода, переопределив sqrt так, чбы он генерил еррор при комплексном результате. И это будет проще и при обучении и при кодинге, чем иметь два набора дублирующих друг друга функций.
> Однако, как программиста-практика интересует вот одна хрень. Даже две. Не, три. Ну в общем, как там насчет биндингов, ну, хотя бы к GTK? Или, хотя бы Qt, если кому по вкусу.
> очевидно что ашыпка произошла намного раньше, чем взятие корня.
Во-первых, не очевидно. Во-вторых, это ближайшая к ошибке точка (из известных). В-третьих, не будь максималистом - пусть решение работает не в 100% случаев, оно вс равно _облегчает_ жизнь.
> Зачем, если даже ооп в лиспе реализовано намного луче?
Речь не идет об "луче". Речь идет о "быстрее". А в данном случае -- так вообще намек на попытку скрестить "ужа" с "ежом" в виде Lisp/Qt.
За ссылки спасибо. Рад видеть, что прогресс на месте не стоит :-).
Раз уж зашла такая речь, может еще подскажете стандартные аналоги Lex/Yacc для Lisp? Я понимаю, что налабать свой собственный транслятор с нуля на Lisp -- самое оно для "настоящих мущин". Но хотелось бы без особого геморроя и, по возможности, в рамках известной технологии.
совершенно очевидно. Иначе откуда взялось отрицательное там, где не должно быть. Насчт ближайшей точки, верно. Но как я указал, для таких редких случяев проще переопределить sqrt чем париться с кучей дубликатов. Как оно может облегчить? Ну, вобщем, вопрос конечно спорный, в окамле например даже арифметические операторы для вещественных и для целых разные. ИМХО не очень удобно, хотя наверное немного наджнее. Окупает ли такое неудобство такой скудный прирост к наджности - пс ево знает, ИМХО нет.
> А в данном случае -- так вообще намек на попытку скрестить "ужа" с "ежом" в виде Lisp/Qt.
А то, что tomcat запущен на линуксе, у которого ядро на сях - это попытка скрестить жабу с сями, чтоли?
> За ссылки спасибо. Рад видеть, что прогресс на месте не стоит :-).
Наздоровье. Пока не стоит. Вопрос лиш в том, в правильном ли направлении движецо.
> Раз уж зашла такая речь, может еще подскажете стандартные аналоги Lex/Yacc для Lisp?
ИМХО никаких шансов, потому что метапрограммирование в лиспе достаточно развито, чтобы не нуждаться в костылях, таких же какие юзаются в наречиях, этого лишнных. Однако пошарся здесь http://www.cliki.net/index , мож и найдш подходящее ибо я достоверно не ведаю.
> Неужели в твом представлении работа обязательно должна быть связана с немеряным гемором?
Насчет геморроя сказал не я, работа же должна доставлять удовольствие. А в том ответе я имел в виду, что все нужные тому человеку средства есть в Питоне, причем с бОльшим выбором, чем в Лиспе, более "вылизанные", более активно _используемые_, поддерживаемые и развиваемые.
Э, нет. Примеры широкого использования Web-фремворков, привязок к GUI, интерфейсов к БД, сделанных на Лиспе - в студию!
У меня на машине (FC4) программ на Лиспе - только Emacs. Программ и библиотек, требующих Python - 51. Из них специально я поставил 2 - python-numeric и matplotlib, вс остальное - по умолчанию. ИМХО, это говорит о том, что Лиспом пользуется куда меньше людей, чем Питоном -> отсюда менее вылизанные, поддерживаемые и развиваемые инструменты. Потому что это вс напрямую зависит от количества пользователей.
Сейчас почти в каждой серьезной библиотеке есть привязка к Питон, но я не помню ни одной с привязками к Лисп. Признай - Лиспом пользуется _намного_ меньше народа.
>> причем с бОльшим выбором, чем в Лиспе, более "вылизанные", более активно _используемые_, поддерживаемые и развиваемые.
>Например?
GUI: wxPython, PyQt, PyGtk
WEB: Django, Pylons, Turbogears, Zope
DB: DB-API, SQLAlchemy, SQLObject
Scientific: Numeric, Scipy, NumPy, matplotlib(лучшая диба в свом классе вообще, для любых языков), интеграция с MatLab
Кстати, Фортран, вс таки быстрее Лиспа будет, без вопросов.
Middleware: Corba, ICE, Pyro
Интеграция с С/C++: SWIG, Pyrex, Boost::Python, ctypes
XML: ElementTree и много чего ещ
Что из этого есть в Лиспе?
Да и вообще в Питоне есть модули на все случаи жизни. Когда мне что-то надо я даже не задумываюсь есть такой модуль или нет, я _знаю_ что он есть, его осталось только найти :-)
В Питоне, кстати, тоже не видел. Но знаю, что есть. Просто пока пользуюсь более привычным и строгим Эйфелем. Впрочем, не исключаю, что когда-нибудь перепишу на Питоне. Just for fun :-).
> А то, что tomcat запущен на линуксе, у которого ядро на сях - это попытка скрестить жабу с сями, чтоли?
Вы правильно поняли ход моей мысли :-).
> ИМХО никаких шансов, потому что метапрограммирование в лиспе достаточно развито, чтобы не нуждаться в костылях, таких же какие юзаются в наречиях, этого лишнных.
Я это знаю. Однако, есть вот хорошая lex/yacc-грамматика для SQL не мною и до меня. Не, ну понятно, для своих целей подрихтовать чуть-чуть нужно. Однако, только ради чистоты идеи заново собирать аналогичный лисапет -- это уже почти декаданс какой-то.
я тамо выше приводил пример юсажа доступа к бд. Нарисуй аналогичный код на пистоне, сравним.
> Что из этого есть в Лиспе?
Я там выше приводил ссылы на cliki.net. Полистай, увидиш ч там намнозе больше всево, а качество _на_порядки_ выше. Причм пользоваться намного проще.
> Кстати, Фортран, вс таки быстрее Лиспа будет, без вопросов.
Ну будет. А лисп быстрее питона, причм в разы.
> Да и вообще в Питоне есть модули на все случаи жизни. Когда мне что-то надо я даже не задумываюсь есть такой модуль или нет, я _знаю_ что он есть, его осталось только найти
Для большинства случяев жизни к лиспу просто _не_нужен_ модуль, ибо в полстроки делаецо. Для остальных модули понаписаны годы назад.
> только ради чистоты идеи заново собирать аналогичный лисапет
ну, фих ево знаит. Заново переписывать конешно смысла нету, ранше надо было думать. С другой стороны, зачем ради чистоты идеи от намного более качественного отказываться?
> Заново переписывать конешно смысла нету, ранше надо было думать.
Ну, я тоже так подумал: вот если бы прожить жизнь сначала... Даже сказка такая была. Вот интересно, если бы и в самом деле начали делать IT с нуля, так SQL тоже бы не понадобился? Или его таки Лиспом не заменить?
И еще, простите уж новичка. Разворачивать весь фреймворк и колупаться небольшая охота. Если уж нашли биндинг к GTK, можно показать, в сколько строк пишется на Лиспе классический Hello в оконном варианте? Или, чтобы не отклоняться от темы, такая вот приблуда: окно, в окне строка ввода и справа кнопка "Вычислить", под строкой с кнопкой текстовый редактор. Когда в строке вводишь Лисп-выражение и нажимаешь кнопку "Вычислить", в редакторе появляются результаты вычисления.
Не, ну я понимаю, что это извращение то еще, ибо emacs рулит. Но все же, в учебных целях. А то ведь целый сервер не поленились написать, неужели такую ерунду не напишете?
Кстати, кто-нибудь знает, есть ли в emacs фильтры на текст a-la vim: выделаяем фрагмент, вызываем некую команду, в минибуфере вводим строку внешнего фильтра, подтверждаем, после чего выделенный фрагмент заменяется результатом фильтрации?
>> широкого использования Web-фремворков, привязок к GUI, интерфейсов к БД, сделанных на Лиспе
> Там я чюток повыше ссылу на cliki.net/web давал
Ты отвечаешь не на тот вопрос, который я задал. Меня не список инструментов интересует, а то, насколько широко их используют.
>> У меня на машине (FC4) программ на Лиспе - только Emacs.
>А у намнозе большей кучи народу венда с висуалвасиком
Ну, это аргумент уровня "миллионы мух". Причем здесь VB? Закрытая реализация кривого языка на закрытой платформе, которую я не использую (ты, я так понимаю, тоже).
>> менее вылизанные, поддерживаемые и развиваемые инструменты
>которые даже оперативы ослободить не могут?
Если ты и в самом деле вс еще считаешь, что то поведение Питона - это "оперативы ослободить не могут", то я не стану пытаться тебя переубеждать снова.
> на лиспе полностью отладили лет 5 или 10 тому.
Сборку мусора на Лиспе отладили всего 10 лет как? По-моему, это у 20-30 лет работает. Если не 40.
>> Просто пока пользуюсь более привычным и строгим Эйфелем.
> Неужели на нем пишут реальные программы?
Ну, я немного пишу. Знаю, что во Франции его очень любят в оборонке -- он у них там заменяет американскую Аду. Как я понял, в основном, из соображений патриотизма. Ну и безопасности, конечно же. :-)
> Какой компилятор?
Ну лично я пользую GNU SmartEiffel (точнее, его предка -- SmallEiffel). Есть и коммерческие компайлеры, в мейнстриме что-то типа ISE Eiffel. Но неинтересно.
> IDE?
GNU Emacs ;-). В демоверсии лет десять назад видел ISE Eiffel, еще под Windows 3.11. Неплохо сделан, но тоже не вдохновил :-).
Для себя. Точнее, собираюсь после доводки выбросить это в OpenSource. Просто пока времени не хватает довести до ума. Пять лет назад писал "на заказ", но это было прототипирование: сугубо research, и моя инициатива. После того, как был достигнут proof-of-concept, начальство приказало переписать все на "правильном" C++. Причины те же, что уже тут обсуждались. И вот, в процессе переписывания все застряло в районе GC. А потом я уволился.
> в сколько строк пишется на Лиспе классический Hello в оконном варианте?
В одну можно уложиться при желании
> А то ведь целый сервер не поленились написать
Дык он мне для работы нужен был, вот и понаписал. Сдесь запостил потому гпл.
> неужели такую ерунду не напишете?
Почему бы и не размять кловеатуру?
#-:gtk (use-package :gtk)
(clg-init)
(defun calc (entry buffer)
(text-buffer-insert-at-cursor
buffer
(write-to-string (eval (read-from-string (entry-text entry))))))
(let* (
(entry (make-instance 'entry))
(edi (make-instance 'text-view :border-width 5 :visible t :wrap-mode :word))
(button (make-instance
'button
:label "do it"
:signal (list 'clicked #'(lambda () (calc entry (text-view-buffer edi)))))))
(make-instance
'window
:title "Hyu"
:border-width 5
:width-request 640
:height-request 480
:visible t
:show-children t
:child (make-instance
'v-box
:homogenous nil
:child (list (make-instance 'h-box
:child entry
:child (list button :expand nil)) :expand nil)
:child (make-instance
'scrolled-window
:hscrollbar-policy :automatic
:vscrollbar-policy :automatic
:child edi))
:signal (list
'delete-event
#'(lambda (event)
(declare (ignore event))
(quit)))))
Это clg2 юзает.
На самом деле там есь гораздо больше. Но не в этом суть. Ещ раз повторюсь, лисп - более высокоуровневый чем бейсик/питон/и тем более С, посему сравнивать, что там есть внутре - занятие бессмысленное, мощь лиспа не только и не столько в библиотеках, встроеных функциях и операторах, а в грамотной конструкции самого языка.
> Меня не список инструментов интересует, а то, насколько широко их используют.
Какого лиха ты думаеш я знаю это? Я всево-навсево глюкодел а не социологическое бюро. Ну, предполагаю что меньше чем висуалвасик, а достоверно вс одно никто не ведает.
> я не стану пытаться тебя переубеждать снова.
ИМХО всодно не сможеш, даже и не пытайся.
> Сборку мусора на Лиспе отладили всего 10 лет как? По-моему, это у 20-30 лет работает. Если не 40.
Помойку, да, отладили. Но как я понял ты не только про помойку говориш?
Если будет время и желание -- напишите на eugine dot kosenko at gmail dot com. Хочется получить консультацию по библиотеке. А то clisp в gentoo нашелся, а вот с биндингом не сложилось. То есть, я даже не понял, о каком clg из заявленных идет речь :-(.
>И еще, простите уж новичка. Разворачивать весь фреймворк и колупаться
небольшая охота. Если уж нашли биндинг к GTK, можно показать, в
сколько строк пишется на Лиспе классический Hello в оконном варианте?
Вот примерчик для lambda-gtk. Рисуется окошко, там кнопочка Hello
World. Нажимаешь на кнопочку -- в REPL появляется "Hello World". На
закрывание окошка окошка -- в REPL пишется "bye!". В программе три
обработчика событий.
(gtk:define-signal-handler bye1 :void (widget data)
widget data ; stop unused var compiler nagging
(format t "bye!~%")
(gtk:main-quit))
(gtk:define-signal-handler delev1 :int (widget event data)
widget event data
(format t "delete-event ocurred~%")
gtk:+false+)
(gtk:define-signal-handler hellomsg :void (widget data)
widget data
(format t "Hello world!~%"))
(defun hello-world ()
(gtk:init-ensure) ; make sure gtk is initialized before calling api
(let ((window (gtk:window-new gtk:window-toplevel))
(button (gtk:button-new-with-label "Hello World!")))
(gtk:container-add window button)
(gtk:container-set-border-width window 10)
(gtk:widget-show button)
(gtk:widget-show window)
(g:signal-connect button "clicked" (g:callback hellomsg)
(g:nullptr))
(g:signal-connect window "delete-event" (g:callback delev1)
(g:nullptr))
(g:signal-connect window "destroy" (g:callback bye1)
(g:nullptr))
(gtk:main)))
Если не нравится 1:1 стиль порта lambda-gtk, то какой-то товарищ
сделал биндинг lambda-gtk к объектно-ориентированному CLOS.
Для работы lambda-gtk нужет CFFI. Не знаю, как там дело обстоит с
UFFI. Если будет, то пойдет на реализациях Common Lisp, которые
обладают UFFI. Сейчас у меня это работает на SBCL.
А вот простой хрестоматийный примерчик для LTK -- биндинга к Tk.
Рисуется окошко, в нем кнопочка "Press Me". Нажимаешь ее -- в REPL
печатается "Hello World"
(defun hello-1()
(with-ltk ()
(let ((b (make-instance 'button
:master nil
:text "Press Me"
:command (lambda ()
(format t "Hello World!~&")))))
(pack b))))
LTK отличное средство для быстрого создания интерфейсов. мне очень
нравится, насмотря на то, что многие не любят, как выглядит Tk (хотя
эта ситуация, наверное, скоро изменится. Некоторые же видели скрин с
патченым tk8.5a. Да и переносимость отличная. Морда будет работать
и на маках, и на виндах, и в Linux.
>Раз уж зашла такая речь, может еще подскажете стандартные аналоги Lex/Yacc для Lisp? Я понимаю, что налабать свой собственный транслятор с нуля на Lisp -- самое оно для "настоящих мущин". Но хотелось бы без особого геморроя и, по возможности, в рамках известной технологии.
Без проблем. Причем генерация всяких LALR, LR и пр. парсеров -- это задача красивейшим образом решаемая на LISP без отсылки к другим средствам. Если для C Lex, Yacc -- это внешние костыли, то в LISP парсинг делается без отсыла куда-либо еще. Сам генератор парсеров сделан на LISP, грамматика описывается на LISP, лексические формы описываются на LISP, и генерируется готовая LISP-программа парсера по твоей грамматике.
>Именно это и погубило его в моих глазах. А как фанател от него в свое время...
А чего в нем страшного? В виндах, насколько я знаю, он выглядит неотличимо от нативного интерфейса. В Маках тоже использует их кнопочки. а в Linux вот чего ребята тут демонстрировали:
Они пишут, что это какая-то тестовая ветка Tk8.5a3. Выглядит очень прилично. Думаю, что будет красиво. Да и некрасивый Tk можно красиво оформить. Главное -- это вкус иметь :)
> А можно поинтересоваться: Лисп -- это единственный грамотно сконструированный язык?
ИМХО нет. Например я считаю достаточно грамотно сконструированной жабу, но предпосылки, заложенные в ней (примитивность и ограничения), мне не нравятся. С также достаточно хорош для свох задач, имеет минимум "роялей в кустах", хотя ещ есть куда, но весьма низкоуровнев, увы. С++ наоборот неудачен.
Вообще, ИМХО попытки сочетать традиционные разделения на примитивные типы (целое, вещественное итд) и обекты и затем использовать для операций с частью из них традиционные записи операторов, инфиксные +-*/ совместно с функциями, а для объектов функции - корявое и неудачное. Создатели лиспа сделали смелый шаг - отказались от традиционных нотаций, которые в программировании неудобны. Из-за чего появился хороший язык, и кучя народу, которому он не нравицо из-за непривычности.
Ладно, напишу. Однако два clg я знаю, древний для гтк1 и второй, clg-0.9... Который пашет с гтк2. Насколько я помню, clg неработает с clisp. Нужен cmucl которое я юзаю или sbcl.
> Они пишут, что это какая-то тестовая ветка Tk8.5a3.
Три года назад он все еще выглядел кошмарно. А в прошлом году я уже успел присесть плотно на gtk. И не вижу причин отказываться от него. Только, пожалуйста, без флейма. Просто сейчас это мой выбор.
И это радует. Для меня Лисп прошел сугубо по касательной. А функциональную парадигму я изучал по айверсоновскому APL/J. Об этом языке тоже ходили легенды. Например, что модель ядра OS/360 может быть записана на этом языке в 120 символов ;-). Сам я этого не видел, зато сам написал программу поиска простых чисел в 17 символов и решение задачи о 8 ферзях где-то в десяток строк. Хотя у товарища на прологе все-равно получилось короче :-(. Я даже умудрялся писать на этом языке неплохие инструментальные штучки, с SQL-биндингдами к Access и обработкой текста. А потом бросил.
Примерно тогда мы с товарищами сошлись во мнении, что любой алгоритм имеет фиксированную информационную емкость, а его запись на различных языках отличается только уровнем энтропии. Отсюда следствие, что на написание любой программы определенной сложности необходимо примерно одно и то же время. Различается только способ разработки. В "низкоуровневых" языках (то есть, с высокой энтропией, или, как любят здесь говорить, "быдлоязыки"), мысль разворачивается согласно канонам классической литературы: экспозиция, завязка, кульминация, развязка. Такой стиль близок большинству людей, поэтому эти языки популярны. А вот в "высокоуровневых" языках (с низкой энтропией) мысль может быть выражена весьма четко и ясно, фактически, с лапидарностью афоризма. Тут само решение рождается с помощью некого "мысленного скачка", когда автор долго думает, а потом программа рождается, как будто из ничего. Это, конечно же, завораживает, и не может не привлекать. Однако, Вы можете представить себе человека, который говорит исключительно афоризмами? Вот и получается, что в любом, даже самом функциональном языке, есть куски императивной парадигмы, чтобы хоть как-то дать разработчику костыли для привычного мышления. Что-то вроде строительных лесов. И Лисп, насколько я знаю, тут не исключение -- кроме рекурсии в нем есть и циклы и ветвления. Другое дело, что это считается моветоном, и в законченной программе должно быть устранено. А вот за что мне нравится Питон, так это за то, что в нем, начав писать императивно, несложно отрефакторить окончательное решение в чисто функциональном стиле.
> Создатели лиспа сделали смелый шаг - отказались от традиционных нотаций, которые в программировании неудобны.
Вообще-то они еще не были традиционными _в программировании_ (программирования как профессии еще практически не существовало). А против нотации Лиспа люди "проголосовали ногами".
Сообщение удалено bugmaker по причине '3.1 Дубль'
Ответ на: Re: Фраза о Лиспе... от eugine_kosenko 02.10.2006 10:57:22
Re: Фраза о Лиспе...
> Ну да. Банан велик, а кожура еще больше :-).
Я не совсем понял что тебя так удивляет или расстраивает. Ну, за исключением того что банан вкуснее лиспа.
> Отсюда следствие, что на написание любой программы определенной сложности необходимо примерно одно и то же время.
Это неправильное следствие. В какой-то степени. Потому что одна и та же задачя, выраженная в одних терминах, решается легче, чем выраженная в других терминах. Я приводил примеры - нахождение множества всех перестановок и доступ к бд. Если решать чисто низкоуровневым способом - при помощи циклов, получится конкретная бяка. С помощю контейнеров, предоставляемых С++, уже намного легче. Питольим способом - с рекурсиями и возможностью выделения подпоследовательностей - наименее сложный из низкоуровневых вариантов. А вот лисп - предоставляет возможность описания терминов и оперирования ими, из-за чего для решения задачи можно использовать наиболее оптимальную терминологию, без привлечения лишних сущностей, каковыми в мом примере являются индексы элементов. Таким образом, если задачу ослободить от ненужной шелухи, конечно, она может решиться намного быстрее и проще.
> В "низкоуровневых" языках (то есть, с высокой энтропией, или, как любят здесь говорить, "быдлоязыки"),
Ты вс напутал. "быдлоязыками" тут называют низкокачественные наречия, которые _неоправданно_ широко используются по безграмотности, независимо от их уровня. Самый низкоуровневый из массовых - С, но я ни разу не видел чтобы ево называли "быдлоязык".
> Вот и получается, что в любом, даже самом функциональном языке, есть куски императивной парадигмы, чтобы хоть как-то дать разработчику костыли для привычного мышления.
Не совсем так. Просто ряд действий, например ввод-вывод, принципиально не описываются адекватно в функциональном стиле.
> И Лисп, насколько я знаю, тут не исключение -- кроме рекурсии в нем есть и циклы и ветвления. Другое дело, что это считается моветоном, и в законченной программе должно быть устранено.
Тоже не совсем так. Моветоном считается зряшное использование "деструктивных" действий, которые имеют побочные эффекты. Как раз из-за того, что злоупотребление ими чревато своими последствиям. В тех случяях, когда это нужно и полезно, такая возможность есь и ей можно пользоваться. Другое дело, что это бывает крайне редко, и их использование зачастую (не всегда!) говорит о недостаточной квалификации разработчика.
Сообщение удалено bugmaker по причине '3.1 Дубль'
Ответ на: Re: Фраза о Лиспе... от eugine_kosenko 02.10.2006 10:57:22
Re: Фраза о Лиспе...
> Ну да. Банан велик, а кожура еще больше :-).
Я не совсем понял что тебя так удивляет или расстраивает. Ну, за исключением того что банан вкуснее лиспа.
> Отсюда следствие, что на написание любой программы определенной сложности необходимо примерно одно и то же время.
Это неправильное следствие. В какой-то степени. Потому что одна и та же задачя, выраженная в одних терминах, решается легче, чем выраженная в других терминах. Я приводил примеры - нахождение множества всех перестановок и доступ к бд. Если решать чисто низкоуровневым способом - при помощи циклов, получится конкретная бяка. С помощю контейнеров, предоставляемых С++, уже намного легче. Питольим способом - с рекурсиями и возможностью выделения подпоследовательностей - наименее сложный из низкоуровневых вариантов. А вот лисп - предоставляет возможность описания терминов и оперирования ими, из-за чего для решения задачи можно использовать наиболее оптимальную терминологию, без привлечения лишних сущностей, каковыми в мом примере являются индексы элементов. Таким образом, если задачу ослободить от ненужной шелухи, конечно, она может решиться намного быстрее и проще.
> В "низкоуровневых" языках (то есть, с высокой энтропией, или, как любят здесь говорить, "быдлоязыки"),
Ты вс напутал. "быдлоязыками" тут называют низкокачественные наречия, которые _неоправданно_ широко используются по безграмотности, независимо от их уровня. Самый низкоуровневый из массовых - С, но я ни разу не видел чтобы ево называли "быдлоязык".
> Вот и получается, что в любом, даже самом функциональном языке, есть куски императивной парадигмы, чтобы хоть как-то дать разработчику костыли для привычного мышления.
Не совсем так. Просто ряд действий, например ввод-вывод, принципиально не описываются адекватно в функциональном стиле.
> И Лисп, насколько я знаю, тут не исключение -- кроме рекурсии в нем есть и циклы и ветвления. Другое дело, что это считается моветоном, и в законченной программе должно быть устранено.
Тоже не совсем так. Моветоном считается зряшное использование "деструктивных" действий, которые имеют побочные эффекты. Как раз из-за того, что злоупотребление ими чревато своими последствиям. В тех случяях, когда это нужно и полезно, такая возможность есь и ей можно пользоваться. Другое дело, что это бывает крайне редко, и их использование зачастую (не всегда!) говорит о недостаточной квалификации разработчика.
Я не совсем понял что тебя так удивляет или расстраивает. Ну, за исключением того что банан вкуснее лиспа.
> Отсюда следствие, что на написание любой программы определенной сложности необходимо примерно одно и то же время.
Это неправильное следствие. В какой-то степени. Потому что одна и та же задачя, выраженная в одних терминах, решается легче, чем выраженная в других терминах. Я приводил примеры - нахождение множества всех перестановок и доступ к бд. Если решать чисто низкоуровневым способом - при помощи циклов, получится конкретная бяка. С помощю контейнеров, предоставляемых С++, уже намного легче. Питольим способом - с рекурсиями и возможностью выделения подпоследовательностей - наименее сложный из низкоуровневых вариантов. А вот лисп - предоставляет возможность описания терминов и оперирования ими, из-за чего для решения задачи можно использовать наиболее оптимальную терминологию, без привлечения лишних сущностей, каковыми в мом примере являются индексы элементов. Таким образом, если задачу ослободить от ненужной шелухи, конечно, она может решиться намного быстрее и проще.
> В "низкоуровневых" языках (то есть, с высокой энтропией, или, как любят здесь говорить, "быдлоязыки"),
Ты вс напутал. "быдлоязыками" тут называют низкокачественные наречия, которые _неоправданно_ широко используются по безграмотности, независимо от их уровня. Самый низкоуровневый из массовых - С, но я ни разу не видел чтобы ево называли "быдлоязык".
> Вот и получается, что в любом, даже самом функциональном языке, есть куски императивной парадигмы, чтобы хоть как-то дать разработчику костыли для привычного мышления.
Не совсем так. Просто ряд действий, например ввод-вывод, принципиально не описываются адекватно в функциональном стиле.
> И Лисп, насколько я знаю, тут не исключение -- кроме рекурсии в нем есть и циклы и ветвления. Другое дело, что это считается моветоном, и в законченной программе должно быть устранено.
Тоже не совсем так. Моветоном считается зряшное использование "деструктивных" действий, которые имеют побочные эффекты. Как раз из-за того, что злоупотребление ими чревато своими последствиям. В тех случяях, когда это нужно и полезно, такая возможность есь и ей можно пользоваться. Другое дело, что это бывает крайне редко, и их использование зачастую (не всегда!) говорит о недостаточной квалификации разработчика.
> Если решать чисто низкоуровневым способом - при помощи циклов, получится конкретная бяка.
Зато эту бяку проще развернуть во времени, что более естественно для человеческого мышления. В функциональном подходе это тоже можно сделать с помощью серии последовательных приближений, но каждый раз это будет "решение целиком", то есть, преодоление "смыслового разрыва" одним скачком. Это не до всех доходит. Лично я всегда вначале выписываю цикл, а потом сворачиваю его в функциональный вызов. То есть, преодолеваю ту же пропасть в два шага. Грубо говоря, есть также подозрение, что процедурная декомпозиция намного более естественна, чем функциональная. Правда, меня можно обвинить в том, что я не крутой перец. С другой стороны, а почему бы мне не предположить, что Вы делаете то же самое, только прячете от меня промежуточные результаты?
Кстати, а как обстоит дело с пошаговой отладкой в Лисп-средах? То есть, я догадываюсь, что она, скорее всего, не нужна. Однако, я подозреваю, что в практической жизни человек все же чаще мыслит алгоритмически, "шаг за шагом", а функции использует только для оптимизации. Так проще. Отсюда и более высокая популярность императивных языков.
> А вот лисп - предоставляет возможность описания терминов и оперирования ими, из-за чего для решения задачи можно использовать наиболее оптимальную терминологию, без привлечения лишних сущностей, каковыми в мом примере являются индексы элементов. Таким образом, если задачу ослободить от ненужной шелухи, конечно, она может решиться намного быстрее и проще.
На самом деле, Вы просто умело прячете эту шелуху "под коврик". А выработка "оптимальной терминологии" -- не более, чем разработка "оптимальной библиотеки/фреймворка" в императивных языках. Вот и получается, что все то время, пока Вы придумываете "оптимальную терминологию", вполне можно успеть изготовить приличную императивную штуку, решающую поставленную задачу. Это я и имел ввиду, когда говорил об "информационной емкости". То есть, пока одни думают, другие пилят. Иногда выигрывают одни, иногда другие -- это зависит от степени фанатизма (помните "Записки жены программиста"? ;-). В среднем же получается паритет, что и было выражено в виде гипотезы.
Правда, это все не касается возможностей повторного использования кода. Создание "оптимальной терминологии" позволяет эффективно повторно использовать код. Так же, как и написание качественной библиотеки. Однако, создать уникальную библиотеку для уникальной задачи, а потом вычесть из общего времени решения создание библиотеки -- это, согласитесь, передергивание. У нас в таких случаях обычно вспоминают знаменитое "Лучше день потерять, но потом за пять минут долететь" ;-).
> Зато эту бяку проще развернуть во времени, что более естественно для человеческого мышления.
> Лично я всегда вначале выписываю цикл, а потом сворачиваю его в функциональный вызов.
Попробуй перестановки наборов произвольной длины, без контейнеров и рекурсий, только циклами. Результат сюды пожалста.
> С другой стороны, а почему бы мне не предположить, что Вы делаете то же самое, только прячете от меня промежуточные результаты?
здравая мысль. Как говаривал один извесный философ, откуда нам знать что стулья не корчат нам рожи когда мы отворачиваемся и не смотрим на них?
> Кстати, а как обстоит дело с пошаговой отладкой в Лисп-средах?
Весьма неплохо. Есть трассировка и ещ всякое.
> На самом деле, Вы просто умело прячете эту шелуху "под коврик".
Тут мы вступили на зыбкую почву предположений и догадок. Предлагаю вернуться к этому вопросу когда предоставите код для перестановок чисто императивными методами.
> Если для C Lex, Yacc -- это внешние костыли, то в LISP парсинг делается без отсыла куда-либо еще. Сам генератор парсеров сделан на LISP, грамматика описывается на LISP, лексические формы описываются на LISP
То есть "внешнекостыльность" Lex и Yacc проявляется в том, лексемы описываются как регулярные выражения, а грамматика описывается не на Си, а как БНФ ?
> Попробуй перестановки наборов произвольной длины,
без контейнеров и рекурсий, только циклами. Результат
сюды пожалста.
Самое смешное, что мы решали эту задачку на олимпиадных
сборах по информатике еще в лохматом 1988 году ;-). Сейчас
уже и не вспомню суть, но, кажется, решения было чисто
императивным, писали мы его на РАЯ ;-). Помню только, что
решение было изящным и остроумным, я потом по блату раздавал
знакомым в институте. Почему, собственно, меня и заинтриговал
пример. Впрочем, могу и ошибаться. Попробую вечером добраться
до своих школьных тетрадок, посмотрю.
Кстати, если Вам еще не надоело, то раз уж зашла речь о
рекурсиях, то вот еще один вопрос: какую глубину выдерживает
вычисление функции Аккермана, ну, например, в Common-Лиспе? В
принципе, интерпретатор у меня есть. Можете написать здесь
корректное решение?
Вообще говоря, в подавляющем большинстве случаев рекурсия
нормально заменяется циклами. Взять хотя бы такую задачку.
Функция f(n) для целых неотрцательных n определена так: f(0)=0,
f(1)=1, f(2n)=f(n), f(2n+1)=f(n)+f(n+1). Для данного N найти и
напечатать f(N). Обязательное услове: N столь велико, что
недопустимо заводить массив, длина которого растет с ростом
числа N).
Задачу нужно было решить на Фортран-77, где принципиально нет
рекурсии. А дополнительное условие специально запрещало создавать
стек. Я долго не мог решить ее именно в таком виде. И решил на
удивление быстро в рамках исчисления Дийкстры: самым сложным
оказалось найти подходящий инвариант. Поверьте, кайфу было не
меньше, чем от перестановок на Лиспе!
О! Сейчас посмотрел в условия олимпиады 1980 года, там оказывается
есть Ваша задача! Вот ядро решения на Паскале:
for i:=m-1 downto 1 do
if (P[i]<P[i+1]) then
begin
n:=P[i];
for j:=m downto i do if (n<P[j]) then
begin
P[i]:=P[j];P[j]:=n;
k:=1;
while i+k<m-k+1 do
begin
n:=P[i+k];
P[i+k]:=P[m+1-k];
P[m+1-k]:=n;
k:=k+1;
end;
j:=i;
end;
Достаточно длинно, не спорю, целых 17 строк. На C короче -- ядро
уместилось в восемь строк ;-). На Бейсике -- десять. Длиннее всего
на Фортране -- около 25 строк. А вот и описание:
Чтобы по данной перестановке P=(p1, p2,
..., pm) чисел 1, 2, ..., m построить не-
посредственно следующую мы будем просмат-
ривать числа p1, p2, ..., pm с конца. И
остановимся, когда впервые попадется член
pi, меньший стоящего правее него
(pi<pi+1). Если такого члена нет, то пе-
рестановка P имеет вид (m,m-1,...,1), то
есть является последней. Ясно, что члены
pi+1>pi+2>...>pm образуют убывающую пос-
ледовательность. Найдем среди них первый
(если их рассматривать с конца) член pj,
уже больший чем pi, и поменяем их местами.
Остается переставить члены pi+1, pi+2,
..., pm в порядке возрастания, и искомая
перестановка (назовем ее Q=(q1,...,qm))
будет получена.
> Кстати, если Вам еще не надоело, то раз уж зашла речь о рекурсиях, то вот еще один вопрос: какую глубину выдерживает вычисление функции Аккермана, ну, например, в Common-Лиспе? В принципе, интерпретатор у меня есть. Можете написать здесь корректное решение?
Вы имели в виду cLisp? Это "СИ-лисп", поскольку большая часть его внутренностей написана на си. Много не выдержит - несколько сотен или тысяч. Аккерман "плох" тем, что не сворачивается в хвостовую рекурсию. Но если "развернуть" его, то у вас памяти не хватит для вычисления хотя-бы от (4, 2) :)
> Сейчас уже и не вспомню суть, но, кажется
Ну вот тема императивщины и раскрыта наконец. Вместо того, чтобы
записать нормальную человечью фразу используя синтаксис машинного
языка, оказывается можно проявлять чюдеса изобретательности и остроумия
:D
> какую глубину выдерживает вычисление функции Аккермана,
ну, например, в Common-Лиспе?
Как и в любом другом наречии, зависит от метода вычисления
и от доступной оперативы.
> Можете написать здесь корректное решение?
Не спец по функциям Аккермана. Вот что произвелось,
но не утверждаю то мо оптимально
(declaim (optimize (speed 3) (safety 0)))
(defun ack (m n &optional (hash (make-hash-table :test #'equal)))
(let* (
(arg (list m n))
(val (gethash arg hash)))
(if (null val)
(setf (gethash arg hash)
(cond
((= 0 m) (+ 1 n))
((= 0 n) (ack (- m 1) 1 hash))
(t (ack (- m 1) (ack m (- n 1) hash) hash))))
val)))
(compile 'ack)
> в подавляющем большинстве случаев рекурсия нормально
заменяется циклами.
Заменяется, да.
> Достаточно длинно, не спорю, целых
Какая фих разница сколько строк? Главное что это решение явно
гиморнее для человека. С ним и сложнее разобраться,
и сложнее выдумать. И противоестественнее. Решение же на лиспе -
попросту запись _человечьего_ определения
в терминах и синтаксисом лиспа.
Сообщение удалено redvasily по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от bugmaker 02.10.2006 14:45:40
Re: Фраза о Лиспе...
> Попробуй перестановки наборов произвольной длины, без контейнеров и рекурсий, только циклами. Результат сюды пожалста.
А почему без контейнеров? Списки неотъемлимая часть Питона, они
находятся даже не в стандартной библиотеке, а в самом ядре языка.
К тому же, как без контейнеров передать аргумент (список значений
для перестановки) в функцию?
Я же не требую чтобы ты писал на лиспе без списков.
Есть задачи для которых рулит рекурсия. Перестановки очевидно одна
из таких задач. Никто против рекурсии и не возражает. А если решать
задачу с переставновками без рекурсии, понятно что фигня получится.
Недавно писал сочетания без рекурсии. Получилось страшно:
while True:
# print combination
yield combination
index = n - 1
while True:
combination[index] += 1
if combination[index] < m - (n - index - 1):
break
else:
if index > 0:
combination[index] = combination[index - 1] + 2
else:
return
index -= 1
val = combination[index] + 1
for i in xrange(index + 1, n):
combination[i] = val
val += 1
Но опять таки религия рекурсией пользоваться не запрещает, и
если надо в Питоне всегда е можно использовать.
Сообщение удалено redvasily по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от bugmaker 02.10.2006 14:45:40
Re: Фраза о Лиспе...
> Попробуй перестановки наборов произвольной длины, без контейнеров и рекурсий, только циклами. Результат сюды пожалста.
А почему без контейнеров? Списки неотъемлимая часть Питона, они
находятся даже не в стандартной библиотеке, а в самом ядре языка.
К тому же, как без контейнеров передать аргумент (список значений
для перестановки) в функцию?
Я же не требую чтобы ты писал на лиспе без списков.
Есть задачи для которых рулит рекурсия. Перестановки очевидно одна
из таких задач. Никто против рекурсии и не возражает. А если решать
задачу с переставновками без рекурсии, понятно что фигня получится.
Недавно писал сочетания без рекурсии. Получилось страшно:
while True:
# print combination
yield combination
index = n - 1
while True:
combination[index] += 1
if combination[index] < m - (n - index - 1):
break
else:
if index > 0:
combination[index] = combination[index - 1] + 2
else:
return
index -= 1
val = combination[index] + 1
for i in xrange(index + 1, n):
combination[i] = val
val += 1
Но опять таки религия рекурсией пользоваться не запрещает, и
если надо в Питоне всегда е можно использовать.
> Попробуй перестановки наборов произвольной длины, без контейнеров и рекурсий, только циклами. Результат сюды пожалста.
А почему без контейнеров? Списки неотъемлимая часть Питона, они
находятся даже не в стандартной библиотеке, а в самом ядре языка.
К тому же, как без контейнеров передать аргумент (список значений
для перестановки) в функцию?
Я же не требую чтобы ты писал на лиспе без списков.
Есть задачи для которых рулит рекурсия. Перестановки очевидно одна
из таких задач. Никто против рекурсии и не возражает. А если решать
задачу с переставновками без рекурсии, понятно что фигня получится.
Недавно писал сочетания без рекурсии. Получилось страшно:
def generate_combination(m, n):
combination = range(n)
while True:
# print combination
yield combination
index = n - 1
while True:
combination[index] += 1
if combination[index] < m - (n - index - 1):
break
else:
if index > 0:
combination[index] = combination[index - 1] + 2
else:
return
index -= 1
val = combination[index] + 1
for i in xrange(index + 1, n):
combination[i] = val
val += 1
Но опять таки религия рекурсией пользоваться не запрещает, и
если надо в Питоне всегда е можно использовать.
Исключительно чтобы проверить тезис о том что низкоуровневое программирование с меньшей степенью абстракций более естественно.
> Списки неотъемлимая часть Питона, они находятся даже не в стандартной библиотеке, а в самом ядре языка.
А в сях нету
> как без контейнеров передать аргумент (список значений для перестановки) в функцию?
Как массив+длина
> Я же не требую чтобы ты писал на лиспе без списков.
И правильно. Хотя можно вполне без них обойтись, потому что в лиспе есть и массивы и хеши и ещ всякое. Только если не использовать более абстрактные конструкции, код на лиспе станет питоноподобным. А раз уж разговор тут перетк в тему "высокоуровневое vs низкоуровневое программирование", дальнейшее обсуждение потеряет смысл.
> понятно что фигня получится.
Дык я и говорил что если конструировать код не в направлении из общих абстракций к частностям, а наоборот, фигня получится.
> Но опять таки религия рекурсией пользоваться не запрещает, и если надо в Питоне всегда е можно использовать.
Дело то не в рекурсии а в разных уровнях абстракции. Насколько питон отличается от асма или С благодаря заимствованиям из лиспа, таким как контейнеры, настолько и лисп отличяется от питона, так как включает больше высокоуровневых конструкций и применение их более просто, так как сама семантика языка на их основана.
Что-то я уже перестал понимать, о чм спор идт. Мы про высокоуровневое vs низкоуровневое программирование или про функциональщину vs императивщину? Или просто LISP против всех? :)
> функциональном подходе это тоже можно сделать с помощью серии последовательных приближений, но каждый раз это будет "решение целиком", то есть, преодоление "смыслового разрыва" одним скачком. Это не до всех доходит. Лично я всегда вначале выписываю цикл, а потом сворачиваю его в функциональный вызов. То есть, преодолеваю ту же пропасть в два шага. Грубо говоря, есть также подозрение, что процедурная декомпозиция намного более естественна, чем функциональная.
Правда, меня можно обвинить в том, что я не крутой перец. С другой стороны, а почему бы мне не предположить, что Вы делаете то же самое, только прячете от меня промежуточные результаты?
> Вот и получается, что все то время, пока Вы придумываете "оптимальную терминологию", вполне можно успеть изготовить приличную императивную штуку, решающую поставленную задачу.
Вот я и удивился. А так, пока вроде лисп против питон получается. На функциональщину против императивщину не тянет потому что под словом лисп я имею ввиду коммон лисп, а он не функциональный ниразу. Если есть ещ идеи, присоединяйся. Повестка дня ещ не утверждена и круг обсуждаемых вопросов можно расширить.
> Вместо того, чтобы записать нормальную человечью фразу используя синтаксис машинного языка, оказывается можно проявлять чюдеса изобретательности и остроумия.
Дыкть, пишется все это ровно один раз ;-).
> Главное что это решение явно гиморнее для человека. С ним и сложнее разобраться, и сложнее выдумать. И противоестественнее.
Неочевидно, что с решением на Лиспе проще разобраться. Лично для меня оно тоже противоестественно :-).
> Решение же на лиспе - попросту запись _человечьего_ определения
в терминах и синтаксисом лиспа.
Я Вам тоже дал _человечье_ определение, которое оказалось достаточно записать в терминах и синтаксисом Паскаля. Кстати, можете повторить свое "человечье" определенье? Или хотя бы ссылку напомнить?
А мне еще особенно интересно послушать серию "Lisp против Forth". А че? Метапрограммирование в Форте есть? Есть. Простота структур данных есть? Есть? Языком системного программирования является? Является. Синтексис извращенный предлагает? Предлагает. Маргинален? Очень даже маргинален. Ну и, чем же Лисп лучше Форта?
;-)
> Ну как же! А на первое место мы попасть не собираемся?
А то! Мы еще тему логического программирования не затрагивали... ;-)
> Маргинален? Очень даже маргинален. Ну и, чем же Лисп лучше Форта?
Дык тем, что он _еще_ маргинальнее 8)
А вообще хотелось бы увидеть пример и/или ссылку на примеры метапрограммирования в Лисп (или Питон 8) ). А то я слышу "метапрограммирование", "синтаксис, идеальный для метапрограммированя", а что это - никто внятно не объясняет. И в Сети внятных примеров пока не нарыл.
дык если вс требуемое по разу но цельную неделю...
> Неочевидно, что с решением на Лиспе проще разобраться. Лично для меня оно тоже противоестественно :-).
достаточно очевидно ИМХО. Потому что намного меньше подробностей есть. Другое дело, что непривычно может быть. Но отрицать что запись с меньшим количеством незначащих подробностей читаецо луче ИМХО глупо.
> Я Вам тоже дал _человечье_ определение, которое оказалось достаточно записать в терминах и синтаксисом Паскаля.
Вс правильно. Только вот разница в длине и замысловатости определений преогромна. Мо можно сыскать в этом же треде пару страниц назад.
Кажется, начинает брезжить тусклый свет понимания... То есть: если макросы могут использовать всю мощь языка для генерации кода, то это уже метапрограммирование? (у нас в PL/I такое было :))
> А вообще хотелось бы увидеть пример и/или ссылку на примеры метапрограммирования в Лисп (или Питон 8) ). А то я слышу "метапрограммирование", "синтаксис, идеальный для метапрограммированя", а что это - никто внятно не объясняет. И в Сети внятных примеров пока не нарыл.
В comp.lang.python не раз обсуждалась необзодимость макросов в Питоне, как правило это получается диалог типа:
Lisp Lover (LL): В питоне нужны макросы для того чтобы сделать ...
Python Bydlockoder (PB): Это можно сделать при помощи стандартных возможностей языка (классы, замыкания, динамическое создание классов и т.д.).
Т.е. не было приведено вменямых use-case-ов где нужны макросы.
Гвидо придерживается позиции создания специального синтаксиса для закрытия таких use-case-ов, например List comprehensions, with (ну вс фанаты Руби больше не будут приставать со своим chdir-ом :-)
А по поводу того что Питон (да и все остальные языки) со временем вс больше и больше становится похож на Лисп (как говорит Грэм, да и в этой ветке эта мысль уже прозвучала) есть такая ссылка:
"Graham demonstrates the "power" of Lisp compared to Python by comparing tiny code snippets." - сразу видно, практик писал 8) Вот и мне обмен небольшими кусочками кода в этом треде кажется... несерьезным.
Лисп, конечно, был революционным языком, но сегодня его фишками никого не удивишь. Хотя я хочу многострочные ламбды в Питоне! 8)
> Как бы ты реализовал http://groups.google.com/group/comp.lang.lisp/msg/4fe888b58ffa83b8 ?
Вот так:
class Parser:
pattern_length = 4
def __init__(self, *readers):
self.readers = {}
for r in readers:
self.readers[r.pattern] = r
def parse(self, data):
for line in data:
reader = self.readers.get(line[:self.pattern_length], None)
if reader is not None:
yield reader.parseString(line)
class LineReader:
def __init__(self, pattern, class_, fields):
self.pattern = pattern
self.fields = fields
self.class_ = class_
def parseString(self, s):
obj = self.class_()
for field in self.fields:
setattr(obj, field[2], s[field[0]:field[1] + 1])
return obj
class SystemObject:
def __str__(self):
return self.__class__.__name__ + ' ' + str(self.__dict__)
class ServiceCall(SystemObject):
pass
class Usage(SystemObject):
pass
def main():
service_call_reader = LineReader('SVCL', ServiceCall, [
(4, 18, 'customer_name'),
(19, 23, 'customer_id'),
(24, 27, 'call_type_code'),
(28, 35, 'date_of_call_string')])
usage_reader = LineReader('USGE', Usage, [
(4, 8, 'customer_id'),
(9, 22, 'customer_name'),
(30, 33, 'cycle'),
(31, 36, 'read_date')])
data = """
SVCLFOWLER 10101MS0120050313.........................
SVCLHOHPE 10201DX0320050315........................
SVCLTWO x10301MRP220050329..............................
USGE10301TWO x50214..7050329..........................""".splitlines()
parser = Parser(service_call_reader, usage_reader)
for obj in parser.parse(data):
print obj
if __name__ == '__main__':
main()
Суть таже самая. Формат строки объявляем декларативно.
Вот тебе и DSL в Питоне :-)
Т.е. получилось длинее чем у них, но у меня код много чище (ИМХО):
1. Отдельный класс на парсер. У них просто разбирают строки в main-e
У меня есть возсожность использовать Parser повторно
2. Отдельный классы на SystemObject, ServiceCall, Usage. Т.е. возможность объявить разные методы у разных классов.
3. Переопределнный __str__. У них насколько я понял, используется
стандартное строковое представление объектов.
4. Четврка у меня именнованная константа, у них magic number
5. И какой код будет легче поддерживать? :-)
> Лисп, конечно, был революционным языком, но сегодня его фишками никого не удивишь.
Да, не удивишь. Но догнать его так никто и не смог...
Или уже есть язык, в котором всю его мощь можно использовать для кодогенерации, причм в теле основной программы, а не внешним/сторонними трансляторами?
Кто-то недавно ссылался на парсер перла на перле... Ну напишите макрос, который будет использоваться _при_ (а не _в_) определении другого макроса, который будет... И так столько, сколько надо. Причм в одном файле, а не клепая левую либу. И чтобы это не было костылм... Потом покажите, как это можно отлаживать. И как можно посмотреть, во что итоговый макрос раскручивается при тех или иных данных.
Хотя, зачем вам такие сложности? Подом сиди и ломай голову - что ты вызываешь, ибо если функцию, то сначала, как и положено, вычисляться параметры, а потом сама функция, а если макро - фиг его знает будут ли параметры вычисляться вообще. А ещ есть макро для компиляции, и результат их "раскрутки" может быть несколько иной, чем в интерпретаторе (где это вообще может быть функцией). Спотыкайся о то, что типы не есть классы, а классы не есть типы. Да, один loop чего стоит, ибо похож больше на питон, чем на лисп (хотя питону такое и не снилось). Опять же, разобрать чужой код, написанный правильно, иногда сродни ребусу: одни макросы вызываются при построении других, а последние просто вызываются один раз при инициализации каких-то данных, причм повторить этот трюк в интерпретаторе просто так нельзя, ибо на эти данные завязана работа самой среды... Охренеть можно. А выкрунтасы с readtable - это даже не макросы (это может быть как макро в си, а может быть интерпретатор другого языка - SQL например, или XML/HTML/всего чего угодно...) Что ещ? Internal type/class могут не наследоваться. А разные области имн для функций и переменных - вообще сказка - как вам такое:
(setf (slot-value foo 'foo) (foo 'foo :foo foo))
И чем дальше в лес, тем толще партизаны... Нафиг, бросайте вы эту дурную затею ;)
Ага, страница кода конечно лучше, чем два десятка строк - вопросов нет!.. :)
> 1. Отдельный класс на парсер. У них просто разбирают строки в main-e
У меня есть возсожность использовать Parser повторно
А на лиспе кто-то запрещает код использовать повтороно? Там только пример. Переделать на функции - больше кода не станет :)
> 2. Отдельный классы на SystemObject, ServiceCall, Usage. Т.е. возможность объявить разные методы у разных классов.
Ну а там лепи себе defmapping под свои нужды - и всех делов. Хоть ещ для десятка типов. В чм тво преимущество?
> 3. Переопределнный __str__. У них насколько я понял, используется
стандартное строковое представление объектов.
Вот тут я тебя не понял.
> 4. Четврка у меня именнованная константа, у них magic number
Это даже не смешно. Это же был пример на скорую руку. Ещ одна строка кода - всего-то. Или более того - вынести не 4-ку, а (subseq line 0 4) (а то и вместе с internal) в функциональную переменную, и определяй себе тип как твоей душе угодно.
> 5. И какой код будет легче поддерживать? :-)
Не твой - 100% :) Если конечно ты не знаешь лисп, ну тогда ССЗБ ;)
> Гвидо придерживается позиции создания специального синтаксиса для закрытия таких use-case-ов, например List comprehensions, with (ну вс фанаты Руби больше не будут приставать со своим chdir-ом :-)
Вот-вот, какой Гвидо решил создать синтаксис, таким вы пользоваться и будете. А тут пиши себе свой хоть по одному на каждый день недели... ;)
> Ну, это слишком круто пока, и по советам людей двигаться как-то проще. Кроме того, мой основной интерес - Python.
Очень хорошо. Попрактикуйся основательно в питоне (при этом лисп не забывай). И весьма вероятно, что в один прекрасный день (или чрный - кому как) ты пошлшь этот питон со всеми его ограничениями к едреней фене... Не факт, что после этого посмотришь на лисп... Дык, я и говорил, каждый на поле образования, устланного граблями, ходит по собственной траектории...
> если макросы могут использовать всю мощь языка для генерации кода, то это уже метапрограммирование?
Не. Всю свою мощ макросы и в сях могут юзать, вот только мощи-то там... Метапрограммирование - это когда создаш наречие специально для решения данной задачи и затем прогу, написанную на этом наречии обращаеш в код на извесном языке, например лиспе.
> Ага, страница кода конечно лучше, чем два десятка строк - вопросов нет!.. :)
Кода у меня больше, но как раз из-за того что у меня это написано как нормальный production код, а у них грязыный хак.
>> 1. Отдельный класс на парсер. У них просто разбирают строки в main-e У меня есть возможность использовать Parser повторно
> А на лиспе кто-то запрещает код использовать повтороно? Там только пример. Переделать на функции - больше кода не станет :)
Сделаешь функцию, появится лишняя строка. Я могу использовать функцию parse(), а не клас Parser, на этом я сэкономлю строки 4, но я этого делать просто не хочу.
>> 2. Отдельный классы на SystemObject, ServiceCall, Usage. Т.е. возможность объявить разные методы у разных классов.
> Ну а там лепи себе defmapping под свои нужды - и всех делов. Хоть ещ для десятка типов. В чм тво преимущество?
Они создают пустой класс, в том что у меня используются _разные_ классы ServiceCall и Usage объявленные отдельно (4 строки), у них же в макросе создатся пустой класс, т.е. нет возможности добавить к разным классам разные методы и т.д. Конечно, можно объявить класс отдельно, и передать его в макрос вместе с параметрами строки для разбора, но это опять таки приведт к росту кода.
>> 3. Переопределнный __str__. У них насколько я понял, используется стандартное строковое представление объектов.
> Вот тут я тебя не понял.
В Питоне, если ты отправишь на печять объект для которого не определн __str__(), просто напишет что это объект такого-то класса по такому-то адресу, а значения атрибутов объекта не выведет. Я этот метод определил для своих объектов (3 строки). В том примере, насколько я понял, используется стандартный вывод Лисповых объектов.
>> 4. Четврка у меня именнованная константа, у них magic number
> Это даже не смешно. Это же был пример на скорую руку. Ещ одна строка кода - всего-то. Или более того - вынести не 4-ку, а (subseq line 0 4) (а то и вместе с internal) в функциональную переменную, и определяй себе тип как твоей душе угодно.
Ну не скажите Фдор Михалыч, десять старушек --- рубль.
Вот, так у них там сэкномили пару строк, здесь сэкономили. Вот и получился код компактный. На питоне, тоже можно довести этот пример до одной строки (см. Obfuscated Python выше :-), но я просто не хочу и не буду этого делать. Readability Counts
> Кода у меня больше, но как раз из-за того что у меня это написано как нормальный production код, а у них грязыный хак.
Хак на лиспе? Это что-то новенькое... ;)
> Я могу использовать функцию parse(), а не клас Parser, на этом я сэкономлю строки 4, но я этого делать просто не хочу.
Т.е. на голом месте добавил новую сущность и рад по уши? :)
Ладно, "нравится" тебе питон - используй его. А раз маленькие примеры тебя "не вдохновляют" (хотя может и дейсвительно ты ещ не увидел чему здесь вдохновляться) - посмотри что-нибудь по-больше. Не хочешь loop смотреть - посмотри на CLSQL. Он понятнее :)
2. Если ты встретил гоязный хак на лиспе, смотри пункт 1 o_O
> Ладно, "нравится" тебе питон - используй его. А раз маленькие примеры тебя "не вдохновляют" (хотя может и дейсвительно ты ещ не увидел чему здесь вдохновляться) - посмотри что-нибудь по-больше. Не хочешь loop смотреть - посмотри на CLSQL. Он понятнее :)
Да надо будет как-нибудь посмотреть...когда время будет.
А какой реализацией Лиспа лучше пользоваться, чтобы работал на Win32, были ебилды и чтоб был байндинг к Qt или wx, и желательно open-source?
> Ты действительно думаешь что критерий качества кода только один --- минимальный размер?
Я считаю что критерием качества кода является минимальный _логический_ размер. см. те же перестановки. Для осуществления пришлось применять ряд сущностей, которые не нужны для решения задачи но являются необходимыми чтобы объяснить компу, что от него собственно требуется.
> грязных хаков
если под грязым хаком понимать использование не предусмотренной конструкторами языка возможности или особенности, в лиспе грязных хаков не бывает. Потому что операции там слишком абстрактны от природы чтобы не подходить изначально для чего-нибудь.
> А какой реализацией Лиспа лучше пользоваться, чтобы работал на Win32, были ебилды и чтоб был байндинг к Qt или wx, и желательно open-source?
Если есть ебилды cLisp - бери его. Если не страшно заниматься сборкой sbcl под винду (он там вроде собирается только сам собой - надо тянуть с sf.net бинарник не самой свежей версии и собирать) - бери его: скорость порадует (особенно по сравнению с питоном :))
"байдинги" ищи отдельно на cliki.net common-lisp.net www.cl-user.net
Раз уж затеяли сей импровизированный PR для лиспа, еще два вопроса:
1. Есть ли какие региональные lisp community (user groups) в России или Украине?
2. Есть ли нормальные русскоязычные ресурсы по лиспу?
По аналогии с питоном тыкнулся в lisp.ru и lisp.org.ru. Первый 'Under construction' ;-), а второй -- англоязычен. По гуглу нашел вот это: http://lisp.ystok.ru/ru/links.html. Как я понял, это только набор ссылок, хотя и не плохих.
Более конкретно, чем пользуются лисперы (совсем конкретно -- уважаемые yyk и bugmaker) для междусобойчиков? Или от недостатка ресурсов живут на общих типа ЛОР?
> Более конкретно, чем пользуются лисперы (совсем конкретно -- уважаемые yyk и bugmaker) для междусобойчиков?
Лично я не вижу необходимости в "междусобойчиках". Лисп настолько простая штука, как полено, что обсуждать безсмысленно а все проблемы решены годы и десятилетия назад. Впрочем иногда не прочь поболтать на канале #lisp в irc.freenode.net.
Вот здесь есь стартовый пакет, с учебниками, факами и прочим:
Особое внимание ИМХО стоит уделять HyperSpec и http://cliki.net. Первое - справочное пособие которое лучше всегда держать под рукой, второе - хорошо коментированный набор ссылок на разнообразные штуковины, полезные для разработчика: библиотеки, реализации лисп-машин и прочее.
>А какой реализацией Лиспа лучше пользоваться, чтобы работал на Win32, были ебилды и чтоб был байндинг к Qt или wx, и желательно open-source?
Пока рекомендую CLISP, если желательно open-source. SBCL для Windows имеет только экспериментальную поддержку в CVS. Это означает, что запустить, наверное, что-то сможешь, но полную поддержку пока не получишь. Будешь сам собирать? Компилятор SBCL на 99% сам на себе написан. Я пока не рисковал этим заниматься. Я только колупался в исходниках из любопытства, чтобы посмотреть, как SBCL генерирует машинные коды и как оптимизирует. :)
A very basic attempt based on the dynamic Qt capabilities (see QMetaObject). Currently it's (maybe) more of a toy and still in planning phase. To extend it you need some Qt knowledge.
Should work with any CFFI enabled Lisp (currently FreeBSD, Linux, Win32) Tested with CLISP (Linux, Win32), ECL (Linux, Win32) and SBCL (FreeBSD, Linux).
> 1. Есть ли какие региональные lisp community (user groups) в России или Украине?
Мне такие не известны.
> 2. Есть ли нормальные русскоязычные ресурсы по лиспу?
Что есть "нормальные"?
есть fido7.ru.lisp. Народу там не много, и тишина почти всегда, но за эхой следят и отвечают на вопросы почти всегда :)
> Более конкретно, чем пользуются лисперы (совсем конкретно -- уважаемые yyk и bugmaker) для междусобойчиков? Или от недостатка ресурсов живут на общих типа ЛОР?
Если сил перевести свой вопрос на английский нет - в указанную эху. А так чаще в форуме конкретного лиспа либо на comp.lang.lisp со всем непрофильным :)
> Да, не удивишь. Но догнать его так никто и не смог...
Мне одному вспомнился анекдот про неуловимого Джо? 8)
> Или уже есть язык, в котором всю его мощь можно использовать для кодогенерации, причм в теле основной программы, а не внешним/сторонними трансляторами?
Мне упорно приходит на ум PL/I. Что-то очень похожее там было. Но я на PL/I уже почти 15 лет не работаю.
>... Охренеть можно.
Это было перечисление заботливо разложенных подводных камней и граблей Лиспа? Или Перла? По-моему, в Лиспе макросы можно вдурную использовать - как два байта переслать.
> хотя питону такое и не снилось
> какой Гвидо решил создать синтаксис, таким вы пользоваться и будете. А тут пиши себе свой хоть по одному на каждый день недели...
Ну да, в понедельник пишем синтаксис, в пятницу - вспоминаем, что там что значит 8)
> Мне одному вспомнился анекдот про неуловимого Джо? 8)
Ах ты блин... Как по одному, так "этим никого не удивишь", а как вс вместе - "а нафиг кому надо"... Неа, не нужен вам лисп :)Ь
> Это было перечисление заботливо разложенных подводных камней и граблей Лиспа? Или Перла? По-моему, в Лиспе макросы можно вдурную использовать - как два байта переслать.
Лиспа. А "вдурную" - это не к языку, а к кодеру :)
> Ну да, в понедельник пишем синтаксис, в пятницу - вспоминаем, что там что значит 8)
Ок, в надцатый раз: loop, CLSQL, etc...
> В Питоне тоже можно сделать расширяемый синтаксис...
> Э нет... loop - это стандарт, CLSQL - тоже, в общем-то. А речь шла о _своих_ синтаксисах, разве нет?
Значит, отбрасываем XML, HTML, прочие структурные форматы... Конечно, каждый день и для каждой проги свой синтаксис не нужен. Но по анологии с with-open-file свои with-XXX пишутся практически в каждой второй проге. В любом случае, это млжно сделать в любой момент "здесь и сейчас", а потом подгрузить при надобности. А не писать патч к самому языку (компилятору/интерпретатору) или макрокомпилатор к нему и потом тащить это от версии к версии и использовать через... ну, вы в курсе :)
> Ибо не тру, ибо не Лисп.
Ибо не предусмотрено стандартом языка, и, как следствие, это уже не питон, а "грязный хак" и нечто питонообразное... :)
>> В Питоне тоже можно сделать расширяемый синтаксис
> А лисп сам по себе расширяемый синтаксис. Чуем разницу?
Честно говоря, нет (некоторые, кстати, считают, что в Лиспе вообще отсуствует синтаксис).
Как в Лиспе определить, например, Си-шный синтаксис для for? Чтобы с ';' и фигурными скобками? Или Питоновский синтаксис для list comprehensions? Да хоть что-нибудь, _не_ являющееся правильным Лисповым списком? По-моему, _синтаксис_ Лиспа не расширяем вообще - вс в прокрустовом ложе списков.
Там выше по треду есь ссыло на sweet-code. Эта приблуда позволяет лиспобыдлокодить в более привычном синтаксисе - открывающяяся скопка после имени функции, инфиксные оператоы итп. Посмотри как там сделано.
Так это просто парсер, написанный на лиспе. Такое можно и на Питоне сделать, и на Си. Правда, сложнее получиться, да.
Интересная вещь - кучу инструментов, написанных на Лиспе, его любители засчитывают как возможности _самого языка_. При этом аналогичные инструменты, написанные на других языках - "кастыли".
>Как в Лиспе определить, например, Си-шный синтаксис для for? Чтобы с ';' и фигурными скобками? Или Питоновский синтаксис для list comprehensions? Да хоть что-нибудь, _не_ являющееся правильным Лисповым списком? По-моему, _синтаксис_ Лиспа не расширяем вообще - вс в прокрустовом ложе списков.
Первое, что я хочу сказать: Мсье извращенец? Во-первых, это просто не нужно. Но если очень нужно, то
Второе. Можно! Все лисповые функции читаются функцией read, которая и есть парсер. Изначально он "натаскан" на LISP-программы в виде s-expressions). И вот этот самый read настолько параметризуем (в самой же LISP-программе!), что ты можешь даже Lisp не узнать. То есть у тебя будет тот же самый REPL, но ты сможешь пользоваться новым синтаксисом, но он внутри LISP после эвалуации превратится в нормальный лисповый объект.
Пример:
REPL> #c(0 1)
Это не s-expression. Внутри себя видит как (complex 0 1). В onlisp естьпримерчик реализации
REPL> #[2 7]
(2 3 4 5 6 7)
Насчет реализации синтаксиса C и Python через read я не слышал (только психу это может понадобиться). Однако есть проект, в котором реализован python. Он называется CLPython. Прямо в REPL программируешь на питоне, а он тебе в результате LISP-объекты создает и работает. Недавно где-то саныч новость об этом постил.
Вау! На Лиспе можно написать парсер! Да, такое не каждому языку под силу. А потом результат работы прасера можно скормить интерпретатору Лиспа? Ну афигеть, вау!
Нет, постой... Это ж такое на любом интерпретируемом языке жожно сделать. А! _Любой_ язык имеет расширяемый синтаксис! Вот что хотели сказать лисперы!
Для тех, кто в танке - насколько можно расширить синтаксис Лиспа, не прибегая к написанию специальных парсеров? Не переопределяя read, read-table, или еще что-нибудь такое.
Ты не повериш, даже на асме можно. И на любом тьюринг-полном. Это же не причина вс бросать и юзать всякие брайнфак, уайтспейс и питон. Хотя на сях, бывает, имеет смысл делать. Эзотерический смысл, добавил по совету супруги.
> Правда, сложнее получиться, да.
Не суть важно что сложнее, а суть _почему_ сложнее.
>Не суть важно что сложнее, а суть _почему_ сложнее.
Если синтаксис будет отличаться от Лиспового, то написать парсер на Лиспе - не проще, чем на Питоне. А то, что в Лиспе парсер входного языка интегрирован в runtime и может быть заменен - интересная фишка, которая ни на что особо не влияет.
Фактически, в лиспе два языка с одинаковым синтаксисом - язык исполняемый и язык макросов. Интерпретатор можно на любом езыке произвести, а вот для метапрограммирования нужен достаточно мощный язык макросов, тьюринг-полный. Метапрограммирование - это не написание интерпретатора и не настройка парсера, а как раз преобразование исходников.
> По-моему, _синтаксис_ Лиспа не расширяем вообще - вс в прокрустовом ложе списков.
Ну, строки-то они как-то умудрились расширить. Правда, совершенно не представляю себе, как можно реализовать текстовые фильтры, где обычно рулят sed/awk/sort/perl, исключительно с помощью средств Лиспа.
Ну вот, скажем такая задачка: во сколько строк на Лиспе реализуется нечто, аналогичное sed, awk или sort?
Кстати, никто так и не ответил мне, есть ли в emacs строково-системные фильтры в стиле vi?
> Лисп настолько простая штука, как полено, что обсуждать безсмысленно а все проблемы решены годы и десятилетия назад.
Аха. Особенно проблемы биндинга к gtk. Особенно для меня ;-).
Новичков нужно любить -- они могут оказаться потенциальными лисперами. Будьте проще -- и люди к вам потянутся.
Может быть, проблема маргинальности лиспа именно в этом? В том, что каждый лиспер -- сам себе мудрец в башне из слоновой кости? Впрочем, по стилю yyk в это легко поверить ;-).
> Аха. Особенно проблемы биндинга к gtk. Особенно для меня ;-).
Извиняй, что не отписался щ как обещял. Меня не будет в сети ближайшие нескко суток, я ращитывал по возвращению. А какая может быть трабла с биндингом? Там вроде вс просто совсем. Прям в форум можеш вопросы запостить, может быстрее хто ответит.
> В том, что каждый лиспер -- сам себе мудрец в башне из слоновой кости?
На ирц нормальный пипл тусуецо, нефих бочку катить. А так, да, лисп-дзен извесное явление, нужное и полезное.
>Ну, строки-то они как-то умудрились расширить. Правда, совершенно не представляю себе, как можно реализовать текстовые фильтры, где обычно рулят sed/awk/sort/perl, исключительно с помощью средств Лиспа.
Ну никто тут не бросится писать awk или sed на лиспе (вопрос здравого смысла: "а зачем реализовывать awk на лиспе?". Спортивный интерес?). Максимум, что можно сделать -- это ткнуть куда-нибудь новом в то, что кто-то сделал.
> вопрос здравого смысла: "а зачем реализовывать awk на лиспе?". Спортивный интерес?
Ответ очень простой: практический интерес. Ежедневная рутина по обработке логов. Или (о ужас!) правоверные лисперы признают, что кроме Лисп нужно знать еще что-то?
*** - USE-PACKAGE: There is no package with name "GTK"
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
ABORT :R2 ABORT
ABORT :R3 ABORT
То есть, я понимаю, что у меня gtk нет, не тупой. Но что делать? Где взять и куда положить, чтоб поехало? Вообще, есть какая-то step-by-step howto? Или, как всегда у лисперов -- сплошной дзен?
>Ответ очень простой: практический интерес. Ежедневная рутина по обработке логов. Или (о ужас!) правоверные лисперы признают, что кроме Лисп нужно знать еще что-то?
Я сейчас начну объяснять, а ты взамен начнешь мне предлагать что-то реализовать. :) Гы.
Объясняю. Выше я дал ссылку на проект реализации быстрых регэкспов (заявляют, что быстрее перловых. подкреплено внизу тестами). Есть фильтрация. Как делается она понятно? Создаешь функцию, которая что-то делает, когда срабатывает регэксп (примеры выше). Чтение/запись из файлов есть. Функции по работе со строками есть. Вместо awk выступает сам Common Lisp. Вот я и спрашиваю: зачем awk, когда есть все? Самодостаточная система же.
> Вот я и спрашиваю: зачем awk, когда есть все? Самодостаточная система же.
Аха. Самодостаточная система. Как Лего. "Собери сам себе велсипед" называется ;-). Не, ну чо. Я однажды даже роликовые коньки из Лего собранные видел. Ничо так...
>Аха. Самодостаточная система. Как Лего. "Собери сам себе велсипед" называется ;-). Не, ну чо. Я однажды даже роликовые коньки из Лего собранные видел. Ничо так...
Бугога. А awk сам пишет программы? а sed сам скрипты генерирует? Регэкспы сами рисуются? Разве GNU -- это не строительные блоки? Здесь же ты имеешь один и тот же инструмент для такого рода работы, который уместнее сравнивать не с awk/sed/... , а с perl! Тебя не возмущает, что ему awk не нужен? :)
Когда-то я угробил уйму времени на выбор любимого языка. Потом -- любимой СУБД. Недавно закончил выбор любимого ГИП-тулкита. Теперь у меня появилась новая игрушка -- выбор любимого диалекта Lisp.
Кажется, жизнь опять начинает приобретать смысл!
Народ, а не забодяжить ли нам ветку clisp vs sbcl vs gcl? Может, и слаку переплюнем?
> Как в Лиспе определить, например, Си-шный синтаксис для for? Чтобы с ';' и фигурными скобками? Или Питоновский синтаксис для list comprehensions? Да хоть что-нибудь, _не_ являющееся правильным Лисповым списком? По-моему, _синтаксис_ Лиспа не расширяем вообще - вс в прокрустовом ложе списков.
Ну ты же знаешь ответ - посмотри loop и CLSQL :)))))
А на деле - это никому нафиг не надо. Хотя можно.
А что не является _правильным лисповым списком_? Списком можно обозвать вс (и соответственно обработать на лиспе) у чего есть начало и конец. И за твоим "прокрустовым ложем" списков очень сильно проглядывает "затрахали ваши скобочки", хоть ты и стараешься от этого уйти. Ну, ты уже понял, что список - это не скобочки? :)
> Интересная вещь - кучу инструментов, написанных на Лиспе, его любители засчитывают как возможности _самого языка_. При этом аналогичные инструменты, написанные на других языках - "кастыли".
Ну ты ниже уже понял - потому что вс, что написано на лиспе, можно использовать "внутри" самого лиспа, у которого "снаружи" просто нет :) Посему нет и костылей.
> Для тех, кто в танке - насколько можно расширить синтаксис Лиспа, не прибегая к написанию специальных парсеров? Не переопределяя read, read-table, или еще что-нибудь такое.
Блин, ты ещ попроси отказаться от скобок не переопределяя readtable...
Посмотри HyperSpec - там все формы описаны без скобок, типа:
Syntax:
subsetp list-1 list-2 &key key test test-not => generalized-boolean
Как можно расширить синтаксис вот таких простых фраз? Куда его расшираять? Тебе ближе A=B? Ну посмотри же loop!
> А то, что в Лиспе парсер входного языка интегрирован в runtime и может быть заменен - интересная фишка, которая ни на что особо не влияет.
О, ты уже кое-что начал понимать... Осталось понять, почему это не просто интересная фишка, а имеющая очень большое значение, наряду с макрами, которые можно применять и использовать в любой период "жизни" программы: load eval compile. И почему эту фишку так легко реализовать и использовать в лиспе, а для других это просто непосильная задача... :)
> Может быть, проблема маргинальности лиспа именно в этом? В том, что каждый лиспер -- сам себе мудрец в башне из слоновой кости? Впрочем, по стилю yyk в это легко поверить ;-).
А куда уж проще? Мне делать больше нечего, кроме как уговаривать тебя "ну посмотри поближе на лисп... не понял - посмотри ещ раз", а в ответ "папа - что это было?" :) Какая к хреням маргинальность, если в ответ я только и слышу - "это на любом языке сделать можно". Так делайте на том, на чм хотите! Вы хотите _меня_ убедить, что лисп вам не нужен? Не надо - я уже верю :)
По поводу "мудреца в башне из слоновой кости" - "я не волшебник, я только учусь" :)
По поводу стиля - опять вы к скобочкам придираетесь... ;)
Ал, люди, я не собираюсь никому ничего навязывать или доказывать - докажите себе сами. Правда сначала вам придтся разобраться в том, что собираетесь доказывать/опровергать :)
> То есть, я понимаю, что у меня gtk нет, не тупой. Но что делать? Где взять и куда положить, чтоб поехало? Вообще, есть какая-то step-by-step howto? Или, как всегда у лисперов -- сплошной дзен?
Не смотрел. А в самом пакете неужели никакой доки нет? А на сайте?
Дзен - не дзен, но скорее всего пакет требует asdf и cffi (или что-то вроде того), и автор соответственно предполагает, что ты всем этим уже умеешь пользоваться... :)
> Аха. Самодостаточная система. Как Лего. "Собери сам себе велсипед" называется ;-).
лки зелные, тут некоторые орут, что стандарт CL и так не в одни ворота не влазит, а ты хочешь, чтобы туда ещ и соломки после каждой ступеньки настелили? На что это станет похоже? Следующее издание БСЭ?
> А в самом пакете неужели никакой доки нет? А на сайте?
Беда в том, что я вообще не понял, что это за пакет :-(. На сайте их штук пять, пробовать их все по очереди?
> Дзен - не дзен, но скорее всего пакет требует asdf и cffi (или что-то вроде того), и автор соответственно предполагает, что ты всем этим уже умеешь пользоваться... :)
А хрен его знает. Только что нашел в ебилдах cl-lambda-gtk. Оно как, нормальное? Или лучше что-нибудь другое выбрать? Замаскировано как нестабильное, а после установки опять нихрена не понятно. Пытаюсь действовать по инструкции, получаю исключение.
Видимо, придется ждать следующего приступа фанатизма. Ну что же, не в первый раз...
> А хрен его знает. Только что нашел в ебилдах cl-lambda-gtk. Оно как, нормальное? Или лучше что-нибудь другое выбрать? Замаскировано как нестабильное, а после установки опять нихрена не понятно. Пытаюсь действовать по инструкции, получаю исключение.
> Видимо, придется ждать следующего приступа фанатизма. Ну что же, не в первый раз...
Ну, да, как и везде - есть проекты, в которых авторы не утруждают себя подробной документацией. Скорее всего - тебя ждут :)
> Хз. Может быть, на Питон? А вообще-то я хотел всего лишь awk...
Т.к. лисп - это не один язык, а семейство, то тут вылезает много сопутствующих проблем, в том числе и лицензионных. У разных лиспов она разная, и у разных пакетов она разная. Посему получить один комплект "с батарейками", но "кошерный" практически не представляется возможным :(
Можешь посмотреть clocc - там много есть интересного.
Исхожу из того, что ASDF установлен вместе с SBCL. Если у тебя Gentoo
или Debian, то просто установи common-lisp-controller. ASDF вместе
с ним поставится.
$ mkdir sbcl
Распаковываешь в ~/sbcl
http://common-lisp.net/project/cffi/releases/cffi_0.9.2.tar.gz
Распаковываешь в ~/sbcl
ftp://common-lisp.net/pub/project/lambda-gtk/lambda-gtk-0.1.tar.gz
$ cd ~
$ mkdir .sbcl
$ mkdir .sbcl/systems
$ cd .sbcl/systems
$ ln -s /home/.../sbcl/cffi_0.9.2/cffi.asd cffi.asd
$ ln -s /home/.../sbcl/lambda-gtk-0.1/lambda-gtk.asd lambda-gtk.asd
$ ln -s /home/.../sbcl/lambda-gtk-0.1/lambda-gtk-examples.asd lambda-gkt-examples.asd
Запускаешь SBCL.
REPL> (asdf:operate 'asdf:load-op 'lambda-gtk-examples)
Завари кофе. И смотри. Сначала по цепочке скомпилируется cffi, потом
lambda-gtk, потом lambda-gtk-examples. После всего запускаем
примерчики:
REPL> (scribble-simple)
REPL> (hello-world)
REPL> (radio-buttons)
REPL> (sliders)
Надеюсь,ч то ничего не забыл и не пропустил. По ходу поймем.
Я юзаю http://www.cliki.net/clg . По ссыле оттуда идм на страницу проекта, загружаем самый свежий из http://sourceforge.net/project/showfiles.php?group_id=9574 , разворачиваем и читаем README. Поступаем как там написато. Если что непонятно/неполучяецо вежливо задам конкретный вопрос на ЛОР в раздел Development или создам топик "ну гадось ваша заливная рыбо нифига нич не работаит" на ЛОР в раздел Talks. Соответственно вас либо поправляют, что нужно сделать или во всех подробностях объясняют ч у их вс работает, кто вы такой и почему от своих родителей произошли. Казалось бы, что может быть проще?
Я объяснял почему у меня код длиннее. Вот пожалуйста,
прямой аналог лиспового кода, хотя таки пришлось оставить фишку,
которой нет в примере у лисперов, переопределнный __str__()
Итого: Питон --- 37 строк, Лисп --- 33 строки
И никакие макросы не нужны.
Давай сойдмся на том, что Лисп на 10% выразительнее чем Питон? :-)
class SystemObject:
def __init__(self, name):
self.name = name
def __str__(self):
return self.name + ' ' + str(self.__dict__)
class LineReader:
def __init__(self, pattern, name, fields):
self.pattern = pattern
self.fields = fields
self.name = name
def parseString(self, s):
obj = SystemObject(self.name)
for field in self.fields:
setattr(obj, field[2], s[field[0]:field[1] + 1])
return obj
data = """SVCLFOWLER 10101MS0120050313.........................
SVCLHOHPE 10201DX0320050315........................
SVCLTWO x10301MRP220050329..............................
USGE10301TWO x50214..7050329..........................""".splitlines()
readers = {'SVCL': LineReader('SVCL', 'ServiceCall', [
(4, 18, 'customer_name'),
(19, 23, 'customer_id'),
(24, 27, 'call_type_code'),
(28, 35, 'date_of_call_string')]),
'USGE': LineReader('USGE', 'Usage', [
(4, 8, 'customer_id'),
(9, 22, 'customer_name'),
(30, 33, 'cycle'),
(31, 36, 'read_date')])}
for line in data:
reader = readers.get(line[:4], None)
if reader is not None:
print reader.parseString(line)
Сообщение удалено redvasily по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от redvasily 04.10.2006 8:04:23
Re: Фраза о Лиспе...
> Итого: Питон --- 37 строк, Лисп --- 33 строки
Извинясь, нагнал. В лиспе я считал только непустые строки, а в питоне все. Плюс у меня одна строка лишняя (self.pattern = pattern), получается:
Итого: Питон --- 32 строки, Лисп --- 33 строки
> Давай сойдмся на том, что Лисп на 10% выразительнее чем Питон? :-)
Упс, надо было соглашаться. Теперь я предлагаю сойтись на том что Питон на 3% выразительнее чем Лисп :-)
А также теперь моя очередь задавать вопросы о лишних сущностях, возьмм напрмер...ммм...макросы!
Макросы это намного более сложная концепция чем классы/объекты и зачем привносить сложную сущность, если можно обойтись простой?
А если серьзно, то для этой задачи Лисп рулит из-за того и только из-за того что в нм можно определить list literal из гетерогенных объектов и динамически добавлять к объектам атрибуты, Питон для этой задачи рулит точно по этой же причине, только в Лиспе используются макросы, а в Питоне классы.
Точно так же можно было использовать вместо класса LineReader замыкание, наверное даже получилось бы короче, т.к. не надо было бы запоминать self.fields = fields, self.name = name --- они бы "запомнились" бы интерпритатором.
Эту задачу можно легко и изящно (ну, разумеется похуже чем на Питоне ;) решить на любом языке где можно записать list literal из гетерогенных объектов и можно задавать атрибуты у объектов динамически (или в языке есть словари/хеши), т.е. это наверняка Perl, Ruby, наверное PHP.
> Итого: Питон --- 37 строк, Лисп --- 33 строки
Извинясь, нагнал. В лиспе я считал только непустые строки, а в питоне все. Плюс у меня одна строка лишняя (self.pattern = pattern), получается:
Итого: Питон --- 32 строки, Лисп --- 33 строки
> Давай сойдмся на том, что Лисп на 10% выразительнее чем Питон? :-)
Упс, надо было соглашаться. Теперь я предлагаю сойтись на том что Питон на 3% выразительнее чем Лисп :-)
А также теперь моя очередь задавать вопросы о лишних сущностях, возьмм напрмер...ммм...макросы!
Макросы это намного более сложная концепция чем классы/объекты и зачем привносить сложную сущность, если можно обойтись простой?
А если серьзно, то для этой задачи Лисп рулит из-за того и только из-за того что в нм можно определить list literal из гетерогенных объектов и динамически добавлять к объектам атрибуты, Питон для этой задачи рулит точно по этой же причине, только в Лиспе используются макросы, а в Питоне классы.
Точно так же можно было использовать вместо класса LineReader замыкание, наверное даже получилось бы короче, т.к. не надо было бы запоминать self.fields = fields, self.name = name --- они бы "запомнились" бы интерпритатором.
Эту задачу можно легко и изящно (ну, разумеется похуже чем на Питоне ;) решить на любом языке где можно записать list literal из гетерогенных объектов и можно задавать атрибуты у объектов динамически (или в языке есть словари/хеши), т.е. это наверняка Perl, Ruby, наверное PHP.
> Макросы это намного более сложная концепция чем классы/объекты и зачем привносить сложную сущность, если можно обойтись простой?
Классы/обекты более сложная ссущнось чем биты. Зачем привносить сложную, если то же самое можно на асме слабать?
>в Лиспе используются макросы, а в Питоне классы.
в лиспе есь _и_ макросы _и_ классы. Хотя ооп в лиспе реализовано намного грамотнее чем в с++ например, классы используются намного реже. Угадай с трх раз почему?
> Эту задачу можно легко и изящно
легко и изящно можно решить любую задачу на чм угодно, как тут уже демонстрировался пример с перестановками на паскале.
> на любом языке где можно записать
станет ли асм языком всоково уровня если в нм есь возможность вызывать из внешних библиотек те же самые хеши и списки?
> И решение будет СУТЬ ТОЖЕ САМОЕ что и на лиспе.
Не будет. При использовании низкоуровневого языка никуда не деться от низкоуровневых понятий.
И строки считать тут ни к чему. Если пример укладывается в 30 строк, съживать его просто некуда. А на более крупных легко можно добиться разницы в обме кода до 10 (!) раз, причм одновременно с улучшением читабельности а не в ущерб ей.
> в лиспе есь _и_ макросы _и_ классы. Хотя ооп в лиспе реализовано намного грамотнее чем в с++ например, классы используются намного реже. Угадай с трх раз почему?
У меня есть три предположения:
1. Потому что макросы это тру, а классы это быдло-мейнстрим
2. Чтобы отличаться
3. Потому что макросы это тру, а классы это быдло-мейнстрим
Я не буду спорить про лисп вообще, давай поговорим об этом конкретном примере. Ты считаешь что решение на Питоне более низкоуровневое чем приведнный пример на Лиспе? Почему?
Кстати о высокоуровневых и низкоуровневых конструкциях. Если классы в Лиспе написаны на макросах, то это означает что классы это более высокоуровненвые конструкции?
ИМЗО так оно и есть. Макросы это конечно мощная вещь (как асм, на асме можно сделать вс) но более низкоуровневая чем классы. Это просто возможность заменить кусок исходника результатом работы функции.
Так что ты определись что ты любишь больше, мощные конструкции или высокоуровневые?
>> И решение будет СУТЬ ТОЖЕ САМОЕ что и на лиспе.
> Не будет. При использовании низкоуровневого языка никуда не деться от низкоуровневых понятий.
А какие понятия являются низкоуровневыми?
Класс это высокоуровневое понятие?
Словарь это высокоуровневое понятие?
Макросы это высокоуровневое понятие?
И какой у них уровень высокоуровневости?
А то без общих терминов и определений мы ни до чего не договоримся...
> 1. Потому что макросы это тру, а классы это быдло-мейнстрим
> 2. Чтобы отличаться
> 3. Потому что макросы это тру, а классы это быдло-мейнстрим
Какой-то ты чрно-белый... :) Ну и "пальцем в небо".
> Кстати о высокоуровневых и низкоуровневых конструкциях. Если классы в Лиспе написаны на макросах, то это означает что классы это более высокоуровненвые конструкции?
Не _на_ макросах, а с их использованием. Точно так-же макры могут использовать классы. Они там не "одно над/под другим", а "рядом, взаимодополняя друг друга". Так что сравнение их "уровней" - бред. И не надо совать классы везде, в том числе и там, где они нафиг не нужны (подозреваю, что переписав лисповый код на классы мы получили бы гораздо больше кода ;)
И если на питоне по-другому никак (не уверен в этом), то делать точно-также на лиспе - "моветон" :)
> У меня есть три предположения:
неугодал. У тя есь щ три попытки
> Ты считаешь что решение на Питоне более низкоуровневое
чем приведнный пример на Лиспе? Почему?
повторение мать заикания мля :D давай начнм с более простого примера
тогда уж. Вот такое заимплементь на любом низкоуровневом и сравним
ч получилось:
http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1592749
раз уж более сложный пример ниасиливаем.
> Если классы в Лиспе написаны на макросах, то это означает что
классы это более высокоуровненвые конструкции?
если класс Б в оопе унаследован от класса А, значит по твоей логике
класс Б более абстрактен, так? Можеш рассматривать классы в лиспе
как унаследованное от макров. Только вот макры полезные,
они код генерят. А объекты только мешаюцо.
> классы это более высокоуровненвые конструкции?
классы это никаковоуровневые неконструкции, это стройматериалы для
консрукций. Классы предполагают ограничения: что часть модели может
быть обособлена как класс, что у этой части модели есть независимые
параметры и возможно описать операторы трансыормации, применимые к,
итд. Для эффективного использования ооп у части единиц модели должны
иметься общие свойства/операторы итп. Короче это длинная и печальная
история. Так вот, все эти многочисленные ограничения на большей
чясти практических задач мешаюцо очень сильно, особенно когда нету
множественного наследования. У макров таких ограничений нету, посему
с их помощю при желании можно народить более абстрактные => более
высокоуровневые конструкции.
и ещ, это существенно разные вещи - макры и обекты.
Первое - средство создания кода, второе - представление
модели задачи. Противопоставлять их друг другу безсмысленно,
ибо одно не исключяет другого. На практике же, если
юзать макросы неоправдано - не юзаеш.
Если неоправдано юзать обекты - в многих наречиях
вс равно приходицо.
> Так что ты определись что ты любишь больше, мощные конструкции
или высокоуровневые?
А мощность никак с высокоуровневостью в общем случае
никак не связана. :P
> А какие понятия являются низкоуровневыми?
любая конкретика, не относящяяся напрямую к сути вопроса. В задачае
про перестановки это привлечения понятия нумерованности, и, как
следствие, использование индексов.
> Словарь это высокоуровневое понятие? Макросы это высокоуровневое
понятие? И какой у них уровень высокоуровневости?
Это вс средства. Ими же можно нагенерить и низкоуровневый код на
лиспе, если умеючи. Пример низкоуровневого кода на лиспе,
почти буквальная, с минимумом отступлений от, трансляция
питоньей проги из
http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1591778
(defun perm (e)
(if (>= 1 (length e))
(list e)
(let (
(f (subseq e 0 1))
(r (subseq e 1))
(q nil))
(dolist (p (perm r))
(dotimes (i (length e))
(setq q (cons (append (subseq p 0 i) f (subseq p i)) q))))
q)))
ужоснахъ, да? Это потому что лисп не очень подходит для
низкоуровневого кода напрямую, вот пипл, привыкший к наречиям
наподобие васика, уайтспейса, или их помеси питона, нефтыкает.
Потому что уровни абстракций совершенно разные, а если
использовать одинаковые принципы построения кода и в лиспе
и в васике, лисп конечто будет конкретно отсасывать, ибо нефих.
> а если использовать одинаковые принципы построения кода и в лиспе и в васике, лисп конечто будет конкретно отсасывать
Ну надо же, на пятом году непрерывного срача у лиспоидов таки просыпаются остатки разума...
Бейсик это суть описание алгоритма. Как блок-схема, только текстовая и более приближенная к человеческому языку. А свою очередь алгоритмы эти взяты тоже не с потолка - это "человеческая" логика с поправкой на математику и применнная к компу. Это очень просто и естественно практически для кого угодно, т.е. трудности с реализацией решения той или иной задачи будут исключительно технические. В то время как лисп и ему подобные языки требуют от программиста вывернуть наизнанку и извратить до неузнаваемости логику _у себя в голове_. Что довольно тяжело и далеко не всем доступно. Так вот мне интересно - ради чего надо затрачивать эти самые усилия по изменению логики в голове? Какие преимущества программист получит при решении тех или иных задач? Как тут уже упоминали, и не один раз, покажите где какая-нибудь супер-нужная и полезная программа на лиспе/хаскеле и т.д.?
> Бейсик это суть описание алгоритма. Как блок-схема, только текстовая и более приближенная к человеческому языку. А свою очередь алгоритмы эти взяты тоже не с потолка - это "человеческая" логика с поправкой на математику и применнная к компу. Это очень просто и естественно практически для кого угодно, т.е. трудности с реализацией решения той или иной задачи будут исключительно технические. В то время как лисп и ему подобные языки требуют от программиста вывернуть наизнанку и извратить до неузнаваемости логику _у себя в голове_.
...для тех, кто начинал учиться с бейсика/паскаля. Тем - да, надо слегка ставить мозги на место. Другие начинали с sicp - у тех вс в порядке :)
> Так вот мне интересно - ради чего надо затрачивать эти самые усилия по изменению логики в голове?
Не видишь? Я тоже уже не раз говорил - значит тебе и не надо. Ну нафига человеку усилитель+колонки с верхней частотой >20кГц, если он их вс-равно не может услышать?
for customer in Cutomer.select(Customer.c.age > 100):
send_email(cutomer.email,
subject='Congratulations!',
body='Dear %s, you won a prize! Call %s.' %
(customer.name, company_phone))
Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет
немного по другому
> Вот такое заимплементь на любом низкоуровневом и сравним
> ч получилось:
>
> http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1592749
> раз уж более сложный пример ниасиливаем.
Пожалуйста:
for customer in Cutomer.select(Customer.c.age > 100):
send_email(cutomer.email,
subject='Congratulations!',
body='Dear %s, you won a prize! Call %s.' %
(customer.name, company_phone))
Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет
немного по другому
Достаточно высокоуровнево?
for ... in ... совершенно необходимо для выполнения задачи? Переменная customer? почему .c. в (Customer.c.age > 100)? Как изменится код если вдрух понадобицо ну left join например?
> Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет
немного по другому
Ну, что сам питон ещ не готов для продакшна, мы уже обсуждали. На многих языках промышленного уровня ещ пара лишних действий появицо.
> Так вот в том-то и оно, там ЧЕЛОВЕЧЕСКАЯ логика. Нет, понятно что можно привыкнуть к чему угодно, вопрос только в том - зачем?
Ну тогда либо я и ещ многие другие - не люди, либо ты - производитель газировки. Не понятно? Это она для _тебя_ "человеческая". За всех не говори, да? :)
> for ... in ... совершенно необходимо для выполнения задачи?
Да. В переводе на руский язык это означает вытащить из базы всех клиентов, у которых возраст > 100 и для каждого вытащенног выполнить заданное действие. Не вижу принципиальной разницы от do-select
> почему .c. ?
Вот тут ты прав, .с. действительно лишнее, Customer.c.age это на самом деле колнка таблицы customers в которой хранятся объекты класса Customer, для которой определены операторы типа >, которые и генерят правильный SQL. Если бы в Питоне были макросы, я бы наверное мог бы написать что-то типа select('age' > 100), но сейчас я этого сделать не могу, т.к. для переменных класса str и int сравнение не определено, а если бы и было определено, оно явно не имело бы никакого отношения к SQL
Лишняя одна буква .c. не катастофа.
> Как изменится код если вдрух понадобицо ну left join например?
Не сильно. Типа customer.addr.street
>> Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет немного по другому
> Ну, что сам питон ещ не готов для продакшна, мы уже обсуждали. На многих языках промышленного уровня ещ пара лишних действий появицо.
Вот тут не понял. sqlalchemy это либа написанная на Питоне и для Питона, как раз е существование это очко в пользу того что Питон готов для продакшна.
Ты же в свом примере использовал какую-то либу для работы с БД, для отправки email. Эта же функциональность явно не в ядре Лиспа.
В данном конкретном случае (и во многих других, где в лиспе используются макры) - для упрощения как самого кода, так и процесса его создания, отладки и сопровождения.
Только если ты скажешь, что для тебя макры сложнее и, как следствие, это для тебя не причина - я позову инну... ;)
Сообщение удалено monk по причине '3.3 Некорректное форматирование'
Ответ на: Re: Фраза о Лиспе... от bugmaker 03.10.2006 15:05:16
Re: Фраза о Лиспе...
> Лично я не вижу необходимости в "междусобойчиках". Лисп настолько простая штука, как полено, что обсуждать безсмысленно а все проблемы решены годы и десятилетия назад. Впрочем иногда не прочь поболтать на канале #lisp в irc.freenode.net.
(defmacro test () `(list ,*test*))
(defvar *test* 2)
(test) ; = 2
(defun test2 () (setq *test* 3) (test))
(test2) ; в CMU CL = 2
; в CLisp = 3
Кто прав? И почему?
> Лично я не вижу необходимости в "междусобойчиках". Лисп настолько
простая штука, как полено, что обсуждать безсмысленно а все проблемы
решены годы и десятилетия назад. Впрочем иногда не прочь поболтать на
канале #lisp в irc.freenode.net.
(defmacro test () `(list ,*test*))
(defvar *test* 2)
(test) ; = 2
(defun test2 () (setq *test* 3) (test))
(test2) ; в CMU CL = 2
; в CLisp = 3
Кто прав? И почему?
А как это у тебя при такой последовательности в CLISP (3) получилось? Получается (2). И в SBCL тоже (2). Поэтому непонятно, что объяснять. И почему. :)
У тебя в CLISP получилось (3) потому что ты по случайности передифайнил (defun test2 () (setq *test* 3) (test)) второй раз. А когда она прошла эвалуацию второй раз, то макрос (test) развернулся в (3).
Могу тебе только объяснить результат. Ты создал макрос со свободной переменной (небиндиной никаким значением). потом конкретизировал переменную *test*. Теперь ты должен понять, что все, что ты делаешь уже начинает выполнятся, как программа. Ты проэвалюировал марку (test) в первый раз и она у тебя развернулась в код (2), так как на момент эвалюации *test* была 2. Теперь ты дефайнишь test2. На момент вычисления макрос test у тебя уже *конкретизирован*, поэтому (test2) снова будет выдавать (2). Считай, что макрос высекает свой код в камне в соответсвии с окружением на момент вычисления. Но теперь ты присвоил значение переменной (setq *test* 3). Но хочешь ты того или нет, но пока макрос в памяти существует в виде (defmacro test (2)), пока его не перевычислишь. И функция в памяти лежит, как (defun test2 (setq *test* 3) (2)). Теперь опять делаешь (test). Макрос у тебя перевычисляется и получишь (3). Но функция уже высечена в камне, поэтому (test2) выдасть (2). А вот если ты возмешь и опять сделаешь повторно (defun test2 () (setq *test* 3) (test)), то функция высечется уже с новым макросом. И в память разложится, как (defun test2 (setq *test* 3) (3)).
Вот тебе наглядно, что происходит с моим комментарием:
Определяем макру, но переменная "висит" в воздухе. Макра будет зависеть от окружающей среды значит :)
[1]> (defmacro test () `(list ,*test*))
TEST
Среда *test* принимает значение 2
[2]> (defvar *test* 2)
*TEST*
Вычисляем макру. Теперь она в памяти превратилась в макру, которая
генерирует код (2), пока не будет перевычислена с новой средой
[3]> (test)
(2)
Определяем новую функцию, в которой часть кода разворачивается макрой.
Макра не перевычисляется. Берется ее текущий код. И все это дело
в памяти висит как (defun test2 () (setq *test* 3) (2))
[4]> (defun test2 () (setq *test* 3) (test))
TEST2
[5]> (test2)
(2)
Но теперь после работы (test2) у тебя новая среда *test* = 3. Определю
новую функцию test3. На момент вычисления она поэтому превращается в
(defun test3 () (setq *test* 4) (3))
[6]> (defun test3 () (setq *test* 4) (test))
TEST3
Смотрим результаты.
[7]> (test3)
(3)
[8]> (test2)
(2)
[9]> (test)
(4)
Поправлюсь, что везде не (defun test3 () (setq *test* 4) (3)),
(defun test3 () (setq *test* 4) (list 3)). Спать хочу потому что. :)
На очевидный твой вопрос, а почему же тогда переменной (setq *test* 3) ты значение присваиваешь, а значение макры следом идущей (test) не изменяется. А я тебе отвечу, что на то она и макра, а не функция. Сначала Lisp формирует код функции, а потом выполняет, а не формирует по мере выполнения. То есть (list 2) подставляется вместо (test) до того, как функция вычисляется.
Сообщение удалено Zubok по причине ''
Ответ на: Re: Фраза о Лиспе... от monk 05.10.2006 0:27:47
Re: Фраза о Лиспе...
Если ты хотел получать макру с другим значением все время в теле
функции, то тебе надо определить ей переменную. Например,
(defmacro test (b) `(list ,b))
А функцию определять так:
(defun test2 (a) (setq c (- a 10)) (test (* c c)))
тогда у тебя будет ожидаемое условное ракрытие макроса.
(test2 20)
(100)
(test2 30)
(400)
Спать пошел.
Если ты хотел получать макру с другим значением все время в теле
функции, то тебе надо определить ей переменную. Например,
(defmacro test (b) `(list ,b))
А функцию определять так:
(defun test2 (a) (setq c (- a 10)) (test (* c c)))
тогда у тебя будет ожидаемое условное ракрытие макроса.
(test2 20)
(100)
(test2 30)
(400)
Спать пошел.
Дык и лисповый прототип выборки из бд и перестановки без этого обошлись прекрасно. Хотя там тоже можно было (loop for ...) зделать.
> Лишняя одна буква .c. не катастофа.
Конешно нет. Дело то не фбукве а в том, что нужно лишние ссущности привлекать. Если погуглиш, увидиш что на достаточно больших проектах разница в обме кода может быть вдесятеро в пользу лиспа.
> Типа customer.addr.street
непонял? адвансед питон сам узнает с какой табличкой как и по какому условию джоинить?
> очко
Очко это хорош. Только вот факт, что и либа доступа к бд и само наречие постоянно мутирует, никак на продакшне положительно не сказывается. Прикинь, через пару лет закащик изволит юзать бд версии 10.1.1 вместо 0.1.9, на которой вы прогу делали/отлаживали. Е поддерживает вышедшая к тому времени либа алхеми 185.6.3, а 0.17 не поддерживает и не будет никогда. В версии либы 185.6.3 вс немного подругому, а в проге полтыщщи модулей по полтыщщи функций по полтыщщи строк по полтыщщи символов в каждой. Арихметика...
> непонял? адвансед питон сам узнает с какой табличкой как и по какому условию джоинить?
Ты должен заранее сказать ему об этом. В одном месте. И ему больше повторять не надо будет. Есть мод к sqlalchemy который позволяет ему вообще ничего не говорить, а питон сам распарсит где какие объекты и что с чем связаны. Но я использую ручное отображение таблиц базы на классы.
> Очко это хорош. Только вот факт, что и либа доступа к бд и само наречие постоянно мутирует, никак на продакшне положительно не сказывается. Прикинь, через пару лет закащик изволит юзать бд версии 10.1.1 вместо 0.1.9, на которой вы прогу делали/отлаживали. Е поддерживает вышедшая к тому времени либа алхеми 185.6.3, а 0.17 не поддерживает и не будет никогда. В версии либы 185.6.3 вс немного подругому, а в проге полтыщщи модулей по полтыщщи функций по полтыщщи строк по полтыщщи символов в каждой. Арихметика...
Это просто бред. По пунутам:
1. Если заказчик изволить юзать БД, версия которой не укзазана
в ТЗ/ТУ и т.д. то это его личные сексуальные трудности.
2. sqlalchemy работает через DB-API это что-то типа ODBC для питона.
Поэтому достаточно будет проапгрейдить все соостветствующие модули, "драйверы" соответствующих БД.
А что в лиспе волшебным образом есть либы для работы со всеми будущеми версиями всех БД?
3. То что питон быстро меняется это преимущество. Читал Грэма? (это риторический вопрос, ты его 100 пудов читал :-)
Good design is redesign. Рулят вещи, которые развиваются эволюционным путм, а не те что сразу сделаны совершенными (точнее их попытались сделать совершенными, но ясно дело облажались).
Проблем от быстрого развития питона нет, люди которые его делают не идиоты, при изменении чего-либо ты сперва получишь deprecation warning и у тебя бужет пара лет прежде чем обратная совместимость поломается.
Грэм, да и ты тоже, наверное, считает что питон ассимптотически приближается к лиспу и рано или поздно все языки а процессе развития станут лиспами. Имхо, он не прав, на основании того что мейнстрим языки приближаются к лиспу нельзя сделать такой вывод.
Язык программирования это точка в многомерном пространстве и питон, например может двигаться в точку идеального языка (ИЯ), пока сближаясь с лиспом (хотя, имхо, он уже отдаляется) а потом будет отдалятся.
И учитывая что питон с каждым релизом становится вс лучше, шансов у него превратиться в идеальный язык больще чем у лиспа, который некуда не движется, т.к. его фонатеги считают что у них уже есть идеальный язык.
Кстати, а ты на чм на работе пишешь? На лиспе? Я лично пишу на свом любимом языке (на питоне, если кто не догадался), и очень по этому поводу рад.
Ладно, не буду больше флеймить, что-то новое про лисп я узнал, а спорить с лисперами бесполезно.
Да-да-да, это именно то, что хочется сказать по поводу вашего письма ;)
> Рулят вещи, которые развиваются эволюционным путм, а не те что сразу сделаны совершенными (точнее их попытались сделать совершенными, но ясно дело облажались).
Сразу совершенными? Это ты о чм? Ты историю лиспа смотрел? Да пиши ты на чм хочешь, но такое тво _невежество_ убивает всякое желание конструктивно с тобой дискутировать. (еле удержался от ругани и мата ;)
> Грэм, да и ты тоже, наверное, считает что питон ассимптотически приближается к лиспу и рано или поздно все языки а процессе развития станут лиспами. Имхо, он не прав, на основании того что мейнстрим языки приближаются к лиспу нельзя сделать такой вывод.
То, что приближаются - факт, ты сам этого не отрицаешь (это хоть что-то тебе говорит о лиспе?). Все станут лиспами - где ты такое нашл? Между строк? url, если только это не твои полуночные фантазии.
> Язык программирования это точка в многомерном пространстве и питон, например может двигаться в точку идеального языка (ИЯ), пока сближаясь с лиспом (хотя, имхо, он уже отдаляется) а потом будет отдалятся.
Твоя "картина мира", мягко говоря, отдат дилетантством и плоскостью мысли. Ну да я в учителя не набивался... :(
> И учитывая что питон с каждым релизом становится вс лучше, шансов у него превратиться в идеальный язык больще чем у лиспа, который некуда не движется, т.к. его фонатеги считают что у них уже есть идеальный язык.
"Это просто бред." - я про идеальные языки, кто куда двигается. А фанатичностью больше всего отдат именно твой пост.
> Я лично пишу на свом любимом языке (на питоне, если кто не догадался), и очень по этому поводу рад.
Так какого хера ты здесь делаешь? Пришл человек, спросил что-то про лисп - какого рожна вас, "не фанатиков", сюда столько припрло, требуя доказательств что лисп не дерьмо и зачем вам им пользоваться? Не нужен он вам - идите от сюда куда подальше и пишите на своих любимых языках! Ну ладно бы просто кинул свой пример, сказал бы "смотрите, как круто, а вам слабо?". Зыть, злюсь... :)
> Ладно, не буду больше флеймить, что-то новое про лисп я узнал, а спорить с лисперами бесполезно.
(дикий рогот в зале) Что? Что ты узнал? Что ты мог узнать из _флейма_? Блин, vsl-я на тебя нет... (не к ночи будь помянут... ;)
> Bugmaker, ты фонате^Wbiased
А ты, redvasily, "тзка" произведения Достоевского (догадаешься какого?)
> Но иногда хочется подставить именно значение переменной на момент вызова (dynamic scope).
Так вот именно `(list *test*) и есть правильная форма в таком случае, ибо макры "разворачиваются" на этапе компиляции, а не исполнения (в таком виде обя языка выдают (3)).
Разница в первом варианте в том, что sbcl (не уверен) сначала компилирует все формы, а потом выполняет. defvar выполняется на этапе компиляции, "развртка" let - тоже на этапе компиляции, а присвоение внутри let - на этапе выполнения. Вот поэтому получаются разные результаты.
>Вот пример, который точно работвет (или точней не работает)
>(defmacro test () `(list ,*test*)) (defvar *test* 2) (let ((*test* 3)) (test))
>В cmu cl = (2), в clisp = (3)
Это особенность CMU/SBCL vs. CLISP:
>The problem stems from a peculiar quirk of SBCL's design: it is a
compiler-only implementation. It has no interpreter at all.
Expressions entered at the REPL are wrapped in a lambda which is then
compiled before execution.
>In normal Lisp implementations, macros get expanded at compile time
or execution time. Macros in interpreted code are (usually)
reevaluated each time that code is run. But in SBCL, compile time is
the same as as read time. So, effectively, macros get expanded at read
time.
Выход -- это заставить макрос еще раз вычислиться:
REPL> (let ((*test* 3)) (eval (macroexpand `(test))))
(3)
Это весьма полезно, когда макросы тестируешь, чтобы посомтреть, во что
он превратился. Однако можно увидеть, что после вычисление
предыдущего выражения:
REPL> (macroexpand `(test))
(LIST 2)
T
> Ага, сплю и вижу "фонатегов" на кольях - целыми лесами :)
"Снится мировая революция, победа технофашизма, мегатонны метана от расставленных по всей стране биореакторов..." (C) Чую, близится второе пришествие Профессора! :D
> "Снится мировая революция, победа технофашизма, мегатонны метана от расставленных по всей стране биореакторов..." (C) Чую, близится второе пришествие Профессора! :D
LOL! :) "Улыбнуло". IMHO, его "эха" в истории отечетсвенных конференций прошла: его лично "воспитание" уже "не заводит", да и условия стали везде жще - мат (хотя он и без мата неплохо обходился;) очень мало где "проходит", а второй кандидатуры пока не предвидется - у него было уникальное сочетание человеческих качеств в одном лице :)
Что мне загнать в mymacro, чтобы результат был эквивалентен
(html (:html (:body (:p "Значение title"))))
По сути, нужен аналог eval, но макросом.
В clisp внутрь macro можно пихнуть свободные переменные с динамической областью видимости, а в cmucl не работает (кстати, это undefined behavior по стандарту или где-то косяк реализации?).
> Не _на_ макросах, а с их использованием. Точно так-же макры могут использовать классы. Они там не "одно над/под другим", а "рядом, взаимодополняя друг друга".
Мне всегда казалось, что CLOS таки реализован _на_ макросах, в том смысле, что сама по себе "пустая" лисп-машина (без стандартной библиотеки) про макросы знает (ибо ей же как-то надо отличать compile-time от run-time), а про "объекты" - нет. И даже про MOP - тоже не знает.
Поэтому можно смело сказать, что ОО-система - более "высокоуровневая" вещь, чем макры, ибо она призвана оперировать абстракциями предметной области, а макры - кодом.
> Проблем от быстрого развития питона нет, люди которые его делают не идиоты, при изменении чего-либо ты сперва получишь deprecation warning и у тебя бужет пара лет прежде чем обратная совместимость поломается.
мне кажется очевидным, что довольно быстрые изменения свидетельствуют о касяках, которые нужно исправлять. И как следствие, что нет гарантии что после "исправления" будет существенно лучше.
> процессе развития станут лиспами. Имхо, он не прав
ИМХО тоже. Есть чткая тенденция примитивить (именно, а не упрощать) язык, а как можно большую часть функционала переностить в библиотеки. ИМХО это достаточно порочная практика, потому что сплош и рядом встречяюцо ситуации когда приходицо делать большие объмы кода и библиотеки нифига не помогают. В этих случяях грамотный дизайн языка намного важнее чем большое количество наворотов.
> и питон, например может двигаться в точку идеального языка
ево, как и многих других наречий, языковые конструкции слишком негибки и "в отрыве" от остальных. Т.е. как и в случае с другими наречиями, вместо языка стараются подсунуть набор готовых фраз. Конечно, это намного проще чем дизайнить хороший язык. И достаточно "крньюктурно" потому что _на_простых_ примерах разница минимальна, а если не знать куды смотреть, вообще незаметна. А потом ужо поздно.
> И учитывая что питон с каждым релизом становится вс лучше, шансов у него превратиться в идеальный язык больще чем у лиспа, который некуда не движется, т.к. его фонатеги считают что у них уже есть идеальный язык.
питон уже упустил свой шанс. Возможно, он станет неплохим средством разработки для шаблонных случяев, как жаба сейчас, но как именно язык а не набор готовых фраз и предложений, небудет. Для этого нужно было изначально дизайнить.
> Кстати, а ты на чм на работе пишешь? На лиспе?
по большей чясти на сях. Давно уже, задолго жо того что бывает лисп.
> Bugmaker, ты фонате^Wbiased
нифига. Я просто пытался обяснить ч есть _принципиальная_ разницо меж языками высоково и низково уровня, и если из асма использовать многочисленные библиотеки, от этого им не проще будет выразить _свою_ мысль. Но на простых примерах очень сложно понять разницы, а количество строк одинаковое :D
>то мне надо, чтобы macroexpand уже возвращал только значение, а не
'(eval ....) которое при вычислении даст это самое значение.
REPL> (defmacro test () `(list ,*test*))
TEST
REPL> (defvar *test* 4)
*TEST*
REPL> (let ((*test* 5)) (macroexpand `(test)))
(LIST 5) ;
T
> Мне всегда казалось, что CLOS таки реализован _на_ макросах, в том смысле, что сама по себе "пустая" лисп-машина (без стандартной библиотеки) про макросы знает (ибо ей же как-то надо отличать compile-time от run-time), а про "объекты" - нет. И даже про MOP - тоже не знает.
Зависит от реализации. В cLisp/sbcl CLOS "вшит" намертво и является неотъемлемой частью (зависит ли от него реализация макр - не знаю).
> Поэтому можно смело сказать, что ОО-система - более "высокоуровневая" вещь, чем макры, ибо она призвана оперировать абстракциями предметной области, а макры - кодом.
Ну а макры могут оперировать кодом, оперирующим абстракциями любого уровня и любой предметной области.
> Макро. Мне с чем угодно. Я только исходник макроса html не могу править.
А библиотека другой интерфейс не предоставляет? Править не надо - посмотреть что делает и реализовать функциональный интерфейс. Ну или (eval (macroexpand `(html (:html (:body (:p "Text1" ,title "Text2"))))))
>Что бы написать в defmacro test (или где-нибудь ещ), чтобы из
>* (let ((*test* 3)) (taketest ...)) получить (LIST 3)
Ну так у тебя макра находится вне зоны let ((*test*)). Либо передавай
параметры в taketest, либо глобально (SBCL):
* (defmacro test () `(list ,*test*))
TEST
* (defvar *test* 2)
*TEST*
* (taketest (test))
(LIST 2)
* (setq *test* 3)
3
* (taketest (test))
(LIST 3)
> Функциональный интерфейс там очень неудобно делать...
:))
А в исходники посмотреть?
(defmacro html (&rest forms &environment env)
(post-process-html-forms
(process-html-forms forms env)))
И post-process-html-forms и process-html-forms - функции.
Ну, сам разбершься что делать? Только не горячись - отдохни, расслабся. Потом начинай думать. Надумаешь - покажи. Не надумаешь - свистну после обеда :)
Чтобы сильно не мучиться с макрами, их можно в slime раскрывать. Там все для людей сделано. Наводишь курсорчик на первую скобочку, где макра вызывается и жмешь C-c RET. Открывается буферок, а там macroexpand-1 готовый.
>> Ладно, не буду больше флеймить, что-то новое про лисп я узнал, а спорить с лисперами бесполезно.
> (дикий рогот в зале) Что? Что ты узнал? Что ты мог узнать из _флейма_?
Флейм начался относитнльно недавно. До этого был довольно информативный разговор (и, по меркам LOR, вполне корректный). Я тоже узнал про Лисп кое-что новое.
>> Я лично пишу на свом любимом языке (на питоне, если кто не догадался), и очень по этому поводу рад.
>Так какого хера ты здесь делаешь? Пришл человек, спросил что-то про лисп - какого рожна вас, "не фанатиков", сюда столько припрло, требуя доказательств что лисп не дерьмо и зачем вам им пользоваться?
Никто не _требовал_ доказательств что Лисп - _не дерьмо_. Спрашивали (в корректной форме), чем он хорош - почуствуй разницу. Лисперы (как всегда, увы) в _основном_ выдавали эффектные, но не очень понятные фразы в духе "Лисп - это язык высокого уровня, а вс осталное - низкоуровневые язычки".
> не нужен он вам - идите от сюда куда подальше
"Не говорите нам, куда нам идти - и мы не будем говорить вам, что делать" -- (С) Почти народное.
> и пишите на своих любимых языках!
Мы пишем. Кстати, хотел спросить - кто-нибудь из участвующих в этой дискуссии лисперов использует Лисп в реальной работе (не для инструментов "только для себя"). А то у меня впечатление, что народ поставил себе Common Lisp, и роется в нем ради удовольствия и самообразования, отсюда и уровень ответов.
> питон уже упустил свой шанс. Возможно, он станет неплохим средством разработки для шаблонных случяев, как жаба сейчас, но как именно язык а не набор готовых фраз и предложений, небудет.
Говорить такое, не имея значительного опыта работы на Питон - это всего лишь глубокомысленный треп.
> Для этого нужно было изначально дизайнить.
Ох да, Лисп _изначально_ сдизайнили, аха, щасс. Сколько (несовместимых между собой!) диалектов Лиспа было за 50 лет? Десятки или сотни? Лисп (как и _любая_ программная система) развивался методм проб и ошибок. Учите историю, она рулез.
2. Единственное, что здесь можно было "узнать" - ссылки на ресурсы. "Читайте первоисточники". А узнавать / составлять мнение о языке по флейму - вы меня простите... Заинтересоваться из флейма - да, можно.
> Спрашивали (в корректной форме), чем он хорош - почуствуй разницу.
Вам в корректной форме давали ссылки.
> Лисперы (как всегда, увы) в _основном_ выдавали эффектные, но не очень понятные фразы в духе "Лисп - это язык высокого уровня, а вс осталное - низкоуровневые язычки".
И это вс, что ты прочитал? А что же ты тогда новое узнал? Лукавишь... :) Ладно-ладно, вижу: "в _основном_". Ну так это, как правило, были ответы на совершенный бред "с обратной стороны" :)
Ладно, ещ раз без эмоций. Спрашивали - что есть хорошего. Ответили? Ответили. Но отдельные личности начали настаивать на _доказательстве_ того, что это "хрошее" действительно хорошо, что оно лучше, чем "хорошее" в других языках, типа "покажи на пальцах". Вот с этого момента вс - туфта. Вам ссылки дали? Идите, изучайте, сравнивайте, делайте выводы. Если что непонятно - спрашивайте. А учить вас здесь, "разжвывать материал" никто не обязан.
> Ну не лиспе, но говорят в потрохах там что-то подобное.
В общем, да, Математика - почти Лисп, только она основана на M-выражениях. Но при этом для многих вещей есть удобный синтаксис, в том числе и для инфиксных операторов. То есть, например, выражение a + b * c + d имеет внутреннее представление Plus[a, Times[b, c], d]. По-моему, очень удачно вс сделано: с одной стороны, это ближе к стандартной математической записи, чем S-выражения, а с другой стороны, возможности метапрограммирования такие же, как в Лиспе. Разве что всякие извраты с переопределением read там не предусмотрены. :)
> > питон уже упустил свой шанс. Возможно, он станет неплохим средством разработки для шаблонных случяев, как жаба сейчас, но как именно язык а не набор готовых фраз и предложений, небудет.
> Говорить такое, не имея значительного опыта работы на Питон - это всего лишь глубокомысленный треп.
Значительного нет. Кое-какой - есть. Речь о том, что в питоне нет (и не предвидется) _встроенных_ полноценных макр и средств изменения синтаксиса. Не обсуждая - надо это или нет и на сколько это хорошо/плохо - это ограничение. Т.е. только по этим параметрам питону не догнать лисп _никогда_.
> Ох да, Лисп _изначально_ сдизайнили, аха, щасс. Сколько (несовместимых между собой!) диалектов Лиспа было за 50 лет? Десятки или сотни? Лисп (как и _любая_ программная система) развивался методм проб и ошибок. Учите историю, она рулез.
Смотря какой "лисп" вы имеете в виду. Если CL - это одно. А если набор (T NIL CONS CAR CDR QUOTE), благодяря которому за прошедшие десятилетия в лисп добавили почти вс, что придумали (в том числе и макры, и CLOS) - это совсем другое. И CL - это стандарт. А конкретные реализации продолжают развиваться.
Да, многообразие приводит к распылению сил. В результате на сегодняшний день питон очень трудно догнать "по батарейкам в одном флаконе".
> То есть, например, выражение a + b * c + d имеет внутреннее представление Plus[a, Times[b, c], d]. По-моему, очень удачно вс сделано: с одной стороны, это ближе к стандартной математической записи, чем S-выражения, а с другой стороны, возможности метапрограммирования такие же, как в Лиспе.
Честно признаюсь - лень прямо сейчас смотреть. Если "не в лом" - пример (не для критики - для ознакомления) метапрограммирования в таком синтаксисе (не просто подстановка, а консруирование кода).
>> питон уже упустил свой шанс. Возможно, он станет неплохим средством разработки для шаблонных случяев, как жаба сейчас, но как именно язык а не набор готовых фраз и предложений, небудет.
> Говорить такое, не имея значительного опыта работы на Питон - это всего лишь глубокомысленный треп.
бугога. а учебникоф значит не читаем, и написатому там неверим? Вс только на свом опыте. Нуну...
>> Для этого нужно было изначально дизайнить.
> Ох да, Лисп _изначально_ сдизайнили, аха, щасс. Сколько (несовместимых между собой!) диалектов Лиспа было за 50 лет? Десятки или сотни? Лисп (как и _любая_ программная система) развивался методм проб и ошибок. Учите историю, она рулез.
ну и чем они в сущности различяются? Да только между уайтспейсом и его родственником питоном меньше различий чем между всеми когда-либо существовавшими диалектами лиспа, потому что у тех принцип один
> Спрашивали (в корректной форме), чем он хорош - почуствуй разницу. Лисперы (как всегда, увы) в _основном_ выдавали эффектные, но не очень понятные фразы в духе "Лисп - это язык высокого уровня, а вс осталное - низкоуровневые язычки".
ну да, непонятные. Как объяснить слепому от рождения, чем отличяецо свет от тьмы?
> мне кажется очевидным, что довольно быстрые изменения свидетельствуют о касяках, которые нужно исправлять. И как следствие, что нет гарантии что после "исправления" будет существенно лучше.
Т.е. быстрые изменения свидетельствуют о том что проект плохой. Медленные свидетельствуют о том что проект загнулся.
Что же свидетельствует о том что проект успешно развивается?
> питон уже упустил свой шанс. Возможно, он станет неплохим средством разработки для шаблонных случяев, как жаба сейчас, но как именно язык а не набор готовых фраз и предложений, небудет. Для этого нужно было изначально дизайнить.
Питон дизайнился. Большое отличие Питона от других языков, то что это уже второй язык у папы Питона и помимо дизайна он эволюционирует. Но очень аккуратно, что попало в Питон не тащат, в отличие от многих других распространнных языков :-)
А что ты думаешь по поводу такой цитаты из Грэма? (LISP-FAQ)
Q: I like Lisp but my company won't let me use it. What should I do?
A: Try to get them to let you use Python. Often when your employer won't let you use Lisp it's because (whatever the official reason) the guy in charge of your department is afraid of the way Lisp source code looks. Python looks like an ordinary dumb language, but semantically it has a lot in common with Lisp, and has been getting closer to Lisp over time.
They might even let you use Ruby, which is even more Lisp-like.
То что "далеко не лисп" - не спорю. Хотя, вспоминая питон и тикль, питоний синтаксис "нравится" больше, хотя, имхо, у тикля возможностей и батареек больше, только что объектная система кривовато выглядит.
Вот флейм "питон vs. тикль" почитал бы с удовольствием :)
> я отрицаю. Хотя претензий болше не к самому наречию а к реализации, но всодно это далеко нелисп.
А что не в порядке с реализацией?
Круто. Теперь пофлеймите между собой.
На самом деле все разговоры про питон были ловушкой. Я сразу понял что таких ветеранов как bugmaker и yyk перефлеймить не удасться, и искал повод чтобы стравить их между собой :-)
С реализацией мнозе ч нетак. Траблы с оперативой например и легендарные тормозы. Даже несмотря на то, ч многие фрагменты нутра питона написаты на сях а cmucl (?почти?) полносью на се самом, питон намного тормознее в целом.
зачем перефлеймивать? Я-то думал мы тут обсуждаем а не флеймируем.
А стравливать ИМХО безполезно. Два умных чела всегда поймут друх друха.
тикль я пожувал недавно. Непонравилось, выплюнул. Хотя вроде не такая кака как питон но карявостей многовато... Хотя мож просто ниасилил, он сложнее лиспа.
> С реализацией мнозе ч нетак. Траблы с оперативой например и легендарные тормозы. Даже несмотря на то, ч многие фрагменты нутра питона написаты на сях а cmucl (?почти?) полносью на се самом, питон намного тормознее в целом.
Про оперативку уже разобрали. Это non-issue
Питон тормозит из-за динамической типизации. Python + psyco (JIT) может работать до ~100 раз быстрее, но основная надежда на PyPy, питон написаный на питоне и который переводится в статически типизованый код, там где код действительно типизован статически. Сейчас у них питон работает в 3.5 раза медленне чем C.
Динамическая. И на си-подобном участке кода будет тормозить по сравнению с тем-же си. Но в _некоторых_ реализациях компилятор при указании типов данных и соответствующих опций компилятору может генерить код практически идентичный си-шному.
> Справедливости ради, надо сказать, что и для Питона есть Pyrex. :)
(ожидая волну народного гнева) Справедливости ради надо сказать, в cmucl/sbcl это есть "в любое время в любом месте", а для питона - кастыль! (me прячется от тухлых помидоров)
Угу, и с большими числами он неплохо работает (одна из "голубых мечт" - прикрутить к sbcl для больших чисел gmp+mpfr, но когда я ещ с vop-ами, оптимизацией и прочим разберусь... :( Да и нафиг это не надо - прикрутить через ffi - и вс :-Е
Давайте я вам еще тему подкину для флейма.Вы народ исконно православному РЕФАЛу обучайте а то какой-то не кошерный lisp.Там еще и супер-пупер-компиляция имеется:)
> То есть программа, написанная на одном, не работала на другом. Такая вот мелочь.
А есть ещ такие быдлоязычки С и С++. Так там тоже есть тонкие моменты, зависящие от реализации. Во гавнище, правда? Потому эти маргинальные язычки и не получили широкого распространения.
> Давайте я вам еще тему подкину для флейма.Вы народ исконно православному РЕФАЛу обучайте а то какой-то не кошерный lisp.Там еще и супер-пупер-компиляция имеется:)
А можно в двух словах для чайников, что это за чудо?
> А можно в двух словах для чайников, что это за чудо?
Можно в четырех :) - советский язык функционального программирования. "РеФ" - этог от "рекурсивная функция". Отличается от Лиспа тем, что использует вместо круглых скобок угловые ;)
> А можно в двух словах для чайников, что это за чудо?
В двух нельза. Иди читай. У него есть большой плюс для местных - русские писали.
Что меня остановило от дальнейшего изучения после прочтения тех FAQ-ов, что есть на сайте: уже пол дюжины версий, суперкомпиляция будет давать эффект не на всех классах задач (мягко сказано). Ну и комьюнити там по сравнению с лиспом как у лиспа по сравнению с жабкой... :\
Ну да, а ещ жощще доказывать ч лисп ненужен только потому ч питон из-за некоторых заимствований из лиспа получился ненамного хуже. ИМХО всравно не тянет.
> Ну, сам разбершься что делать? Только не горячись - отдохни, расслабся. Потом начинай думать. Надумаешь - покажи. Не надумаешь - свистну после обеда :)
Типа
(defun html-fun (&rest forms) (eval (post-process-html-forms (process-html-forms forms nil))))
?
И писать что-то вроде (html-fun '(:html (:body (...))))
Основные возможности: регулярный синтаксис и семантика, практически неограниченное множество производных понятий. По духу сильно ЛИсп напоминает (в смысле, уйма возможностей, заставляет мыслить под более широким углом, но довольно труден для изучения).
> CлабО привести ссылку на пост в этом треде, где утверждалось, что Лисп не нужен?
ну я пришл к такому мнению по ходу всево обсуждения, из-за многочисленных противопоставлений примеров на питоне и указаний на особенности питона, сходные с лисповыми. Если я неправильно понял (как видно не я один кстати) и в действительности мнение было другим, приношу извинение и ожидаю разяснений по этому вопросу.
> А вообще вот это: "питон ... ненамного хуже", оно дорогого стоит, да ;)
> Ну да, а ещ жощще доказывать ч лисп ненужен только потому ч питон из-за некоторых заимствований из лиспа получился ненамного хуже. ИМХО всравно не тянет.
Ща дотяну.
Питон непосредственно из лиспа ничего и не взаимствовал (ну лямбду стырили, но Гвидо осознал свою ошибку, раскаивается и сожалеет). Грэм проталкивал телегу что вс то что было в лиспе изначально, языки фортано-алголовской группы приобрели эволюционно. Питон это не передирка лиспа, а вершина (или рядом с ней) развития алголовской группы.
> я пришл к такому мнению по ходу всево обсуждения
То есть - ссылок нет. Потому что никто такого не утверждал. Фраза про "ипподром для сферических коней" не в счет - redvasiliy'я спровоцировали. Даже Die-Hard, которому мы обязаны этим флеймом, такого не говорил ;)
> Если я неправильно понял ... ожидаю разясненийе
Я могу изложить свое мнение (я уже его излагал, но, так сказать, на бис 8)): когда-то давно (лет 15 назад) я прочитал "Мир Лиспа" и был впечатлен. Потом было еще несколько книг, в которых о Лиспе говорилось в превосходной степени. Поэтому, когда у меня появился шанс использовать Лисп в деле, я попробовал (Guile, встраиваемая реализация Scheme). Впечатления - сугубо отрицательные, после месяца упорной грызни кактуса переделал все в Питон, о чем еще ни разу не пожалел. Но червячок сомнения гложет - может, я что-то недопонял? ниасилил? Вот и пытаю встречных лисперов - "в чем ваша лисповая тайна, лисперы?" 8) Может, постигну ее и в следующий раз вс получится. Но встречные лисперы либо говорят "попробуй, полюбишь", либо "Лисп - круче всех, он тока для крутых перцев" :/
>> А вообще вот это: "питон ... ненамного хуже", оно дорогого стоит, да ;)
>Это как?
Лично мне приятно услышать от лиспера, что Питон "ненамного хуже".
1. Если обязательно нужен _функциональный_ стиль (ты не собираешься вс писать в лоб) - что-то вроде этого (каюсь, дальше определения html не разбирался). Единственное замечание - '(:html (:body (...))) - это список, и для его построения можешь использовать всю мощь лиспа :) В том числе `(:html (:body ,(list :p title)))
2. Если хочешь отказаться от eval - тогда написать свою макро по аналогии с html, которая берт значение из глобальной переменной (как ты и спрашивал). Но это ужасно криво и я тебе это не советовал :)
3. Подписаться на рассылку lml2 и спросить - как тот-же результат получить функциями (или через параметры/подстановку/как угодно)
> Потом было еще несколько книг, в которых о Лиспе говорилось в превосходной степени. Поэтому, когда у меня появился шанс использовать Лисп в деле, я попробовал (Guile, встраиваемая реализация Scheme). Впечатления - сугубо отрицательные, после месяца упорной грызни кактуса переделал все в Питон, о чем еще ни разу не пожалел.
1. Одного чтения мало. Я не хочу сказать, что полный тормоз, но "на досуге" "врубался" в лисп довольно долго, пока перестал тупить при виде первого попавшегося исходника. Вот потом "засосало". И и менно с тикля/питона/иже с ними.
2. Схема мне мение "по душе", но теперь это уже не имеет значения (с самого начала подкупило то, что CL такой большой :)
3. Ещ раз подтвержу: да, у питона сейчас больше "батареек из корбки"
возможно не непосредственно, а из других языков и наречий. Но в лиспе многое появилось впервые и там же доведено до совершенства.
> Питон это не передирка лиспа
ладно, поправлюсь.
s/некоторых заимствований из лиспа/некоторых ссущностей, которые давно есть в лиспе но либо отсосутствуют в других наречиях либо менее эффективны в них из-за более враждебново им синтаксиса этих наречий
>Мне кажется, что просто отключена проверка типов, и, если на входе
процедуры - значение неправильного типа, на выходе - мусор. Нет?
По идее -- да. Я практически с этой стороной не возился плотно. На
уровне игрушки потыркал -- смотрел, как он с FPU работает и пр.
Однако сейчас проверил кое-что:
* (defun foo (a b)
;; optimized addition procedure; much leaner assembly
(declare (optimize (speed 3) (safety 0) (debug 0)))
(declare (type fixnum a b))
(the fixnum (+ a b)))
FOO
* (foo 3 5)
8
* (foo "d" "f")
#<unknown immediate object, lowtag=#b110, widetag=#xC6 {14FE6CC6}>
*
Ругается. Так что, возможно, если при пользовании функциями
неправильный тип нарисовался, то сообщит что-то.
У меня по этой ссылке открылось начало обсуждения, в котором Die-Hard _не_ говорит о том, что Лисп не нужен :-P
>> "в чем ваша лисповая тайна, лисперы?"
> Видимо вс-таки нужно но сложно переучивацо с алгоритмического стиля мышления на более абстрактный.
Вот-вот, и я о том же. Лисперы достигли такого уровня абстракции, что понятиями мельче "стиль мышления" не оперируют. Может, отсюда и подозрения в шарлатанстве? КОНТРОЛЬНЫЙ СМАЙЛИК: ";)"
>> Лично мне приятно услышать от лиспера, что Питон "ненамного хуже".
>Чесно говоря я таково не утверждал.
Прочтано в твоем посте... Да ладно, оговорка по Фрейду, дело житейское - с кем не бывает ;) Подумаешь, тайный серпентофил - вс нормально, добро пожаловать в клуб 8)
>Тогда это не может компилироваться в одну инструкцию "add" %)
Ну если подумать, то, скорее всего, он ругается на более раннем этапе. Ведь еще же есть цепочка событий, которая идет от REPL. :) Как только я в REPL написал (foo "2" "3"), он пытается засунуть эти вещи в регистры, которые в сложении учавствуют. Видит, что тип не тот (неупаковываемый в понятие fixnum), и раппортует. Я попробовал не REPL, а вызов foo из другой функции. При указании чисел с плавающей точкой SBCL также ругнулся. Так что думаю, ругается он еще до вызова функции, а в самой функции проверок нет, как видишь. Ничего более точного сказать не могу. Этой стороной я плотно не занимался пока.
> А есть интерфейсы Lisp --- .NET, Lisp --- Java, этим пользуются?
ч за тырфейсы? сокеты чли? сокеты есь. Для взаимодействия с другими наречиями - http://www.cliki.net/compatibility%20layers . Есь Kawa - схема, диалект лиспа, работающяя в JVM. для дотнетиненады - никогда не интересовался. Наверное нету потомушто дотнетиненадо - ЛАЖА а лисперы ЛАЖУ не любют.
> 1. Как вы подcели на лисп?
Читал статью "побеждая посредственнось". На то время умя выдалась на редкось тупая работа, и я, пока увольнялся, решил проверить, действительно ли правда ч там писано, просто со скуки. Ожидал нескко большево, но вобщем-то и так неплохо.
> 2. Какой самый крупный проект вы на нм написали?
Достаточно крупный - никакой. Для своих целей много всякой хни до нескольких сотен строк длиной. Есь задумки для пары проектов, но не уверен ч когданть приступлю к реализации.
> А есть интерфейсы Lisp --- .NET, Lisp --- Java, этим пользуются?
Интерфейсы есть. Кому надо - пользуются. Но таких - меньшинство даже среди лисперов.
> 1. Как вы подcели на лисп?
Да вот маялся между всякими питонами/тиклями/уже не помню чем. Везде что-то не устраивало. Ну и когда задавал вопросы в эхах - как сделать то, как сделать это - периодически посылали: это тебе лисп нужен... :) Поверил :) Вернее - полез знакомится. И чем больше знакомился - тем меньше пользовался всем остальным.
> 2. Какой самый крупный проект вы на нм написали?
In public - никакой :) Те реализации CL, которые меня устраивают по некоторым критериям (мультиплатформенность, ОС) - не устраивают своим "содержанием". Да и многие "батарейки" далеки от рабочего состояния. Приходится принимать участие в доводке всего этого до ума.
P.S. Я не профессиональный программист - это хобби, помогающее по работе :)
> Как насчет проверки типов параметров макроса?
не трабла, хоть одново, хоть половины хоть всех скопом
[1]> (defmacro tst (a b) `(format t "~S ~S~%" (the fixnum ,a) ,b))
TST
[2]> (tst 1 2)
1 2
NIL
[3]> (tst 1 "2")
1 "2"
NIL
[4]> (tst "1" "2")
*** - THE: "1" при вычислении возвратила следующие значения ("1"), не принадлежащие типу FIXNUM
Break 1 [5]>
> но является ли это фишкой _всех_ CL?
не.
> Тут один товарищ рядом почитал этот флейм и сказал: "И какой идиот сказал что язык программирования это точка в идеальном пространстве!" :-)
Не правда!!! Я не упоминал Достоевского. А точкой в идеальном пространстве можно назвать что угодно... А можно еще оболочки и срезы начать рассматривать. Worse is Better!
как ты представляеш себе макрос с переменными? их же значение может быть неопределено на момент компиляции ну ваще. Макросы код на лиспе генерят еслич...
ХЗ. Я вообще Лисп плохо знаю. Твоими руками я пытаюсь решить такую задачу: обернуть некую функцию в макрос, который выдавал бы ошибку (на этапе трансляции!), если аргумент функции имеет не тот тип. Понятно, что аргумент может быть как аргументом, так и литералом. Можно ли такое сделать?
> Твоими руками я пытаюсь решить такую задачу: обернуть некую функцию в макрос, который выдавал бы ошибку (на этапе трансляции!), если аргумент функции имеет не тот тип.
Ох уж эта динамическая типизация... Статическая типизация и ocaml рулят.
> Понятно, что аргумент может быть как аргументом, так и литералом.
Во время выполнения макры некоторую обработку параметров можно вести, но, как правило, это касается только значений или списков. С литералами хуже: текущее пространство имен и т.п. Не видел. Попробуйте... :)
Кстати о статической типизации, недавно нашл один интересный лисп: http://lush.sourceforge.net/. В нм есть офигенно эффективный компилятор для статически типизированного кода. Если быть точным, генерируется код на C, и код получается обычно такой же, как я бы руками написал. Ну и что меня вообще добило, в программу на лиспе можно запросто делать вставки на С. :) Кто там хотел лисп с ассемблерными вставками? Да лехко! :D
> Исхожу из того, что ASDF установлен вместе с SBCL. Если у тебя
> Gentoo или Debian, то просто установи common-lisp-controller. ASDF
> вместе с ним поставится.
У меня Gentoo. common-lisp-controller был установлен по зависимостям sbcl.
$ emerge --search cffi
Searching...
[ Results for search key : cffi ]
[ Applications found : 1 ]
* dev-lisp/cl-cffi
Latest version available: 0.9.1
Latest version installed: 0.9.1
Size of files: 144 kB
Homepage: http://common-lisp.net/project/cffi/ Description: The Common Foreign Function Interface (CFFI)
License: BSD
Пойдет? Для верности, сделал и так, как ты сказал.
$ sbcl
This is SBCL 0.9.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (asdf:operate 'asdf:load-op 'lambda-gtk-examples)
; loading system definition from
; /usr/share/common-lisp/systems/lambda-gtk-examples.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM LAMBDA-GTK {1002695F91}> as LAMBDA-GTK
debugger invoked on a SIMPLE-TYPE-ERROR: Argument Y is not a REAL: NIL
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(defun foo (a b)
(declare (optimize (speed 3) (safety 0) (debug 0)))
(declare (type fixnum a b))
(+ a b))
(defmacro bar (x y) `(foo ,x ,y))
(format t "~D~%" (bar "a" "b"))
потомушто сначяло макром сгенерицо код а потом код будет компилицо
если типы, передаваемых в функцию не совпадут, будет ругацо,
без разницы, функция вызвата из другой функции или из макра.
Ты про такое спрашивал?
> разворачиваем и читаем README. Поступаем как там написато. Если что непонятно/неполучяецо вежливо задам конкретный вопрос на ЛОР в раздел Development
Дальше цитаты из README
===================================================================
> 2. Compile the Alien Function package and save a new sbcl.core image:
> $ cd sbcl-af
> $ sbcl --load "system"
$ sbcl --load "system"
This is SBCL 0.9.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
debugger invoked on a SIMPLE-ERROR:
Error during processing of --eval option (LOAD #P"system"):
"system.lisp" does not exist.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Ignore and continue with next --eval option.
1: [ABORT ] Skip rest of --eval options.
2: Skip to toplevel READ/EVAL/PRINT loop.
3: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
=================================================================
> - Make sure ASDF finds the system definition files:
>
> (push
> #+sbcl(truename #p"clg:systems")
> #+cmu(concatenate 'string (unix-namestring #p"clg:systems") "/")
> asdf:*central-registry*)
$ sbcl
This is SBCL 0.9.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (push
#+sbcl(truename #p"clg:systems")
#+cmu(concatenate 'string (unix-namestring #p"clg:systems") "/")
asdf:*central-registry*)
debugger invoked on a SB-INT:SIMPLE-FILE-ERROR:
The file "CLG:SYSTEMS" does not exist.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(TRUENAME #P"CLG:SYSTEMS")
0]
====================================================================
> 3. Compile and load the system:
>
> (asdf:oos 'asdf:load-op :gtk)
$ sbcl
This is SBCL 0.9.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (asdf:oos 'asdf:load-op :gtk)
debugger invoked on a ASDF:MISSING-COMPONENT: component "gtk" not found
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(ASDF:FIND-SYSTEM :GTK T)
0]
====================================================================
> Казалось бы, что может быть проще?
> Да, никто так и не вспомнил про maxima, замечательную алгебраическую систему, написанную на Lisp.
Я вспоминал. Как вторую (после emacs) систему с Лиспом на моей машине. Еще вспоминали reduce, но я с ним знаком исключительно заочно. А вот столь нужная мне система формального логического вывода HOL, с которой я работаю чуть ли не каждую неделю, написана отнюдь не на Лиспе.
Если уайтспейсом ты называешь Питон, то по сравнению с Лиспом он мэйнстрим. По сравнению с VB - не очень распространенный язык (но уже не маргинальный, как лет 8-10 назад).
Поправьте меня, если ошибаюсь, но обе системы родом из 70-х годов, времен, когда Лисп считался единственным языком, пригодным для символических вычислений. Но это же 30 лет прошло...
Упс! Не сделал. Но теперь другая беда (собственно, это и было сразу,
просто когда писал на форум, уже вышел из каталога):
~/src/sbcl-0.8.21-af $ sbcl --load "system.lisp"
This is SBCL 0.9.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
; compiling file "/home/eugine/src/sbcl-0.8.21-af/static-vector.lisp" (written 20 APR 2005 10:37:40 PM):
; compiling (IN-PACKAGE "SB-ALIEN")
; compiling (EXPORT (QUOTE #))
; compiling (DEFSTRUCT (STATIC-VECTOR #) ...)
debugger invoked on a SIMPLE-ERROR:
Error during processing of --eval option (LOAD #P"system.lisp"):
Lock on package SB-INT violated when globally declaring the ftype of
MAKE-STATIC-VECTOR.
See also:
The SBCL Manual, Node "Package Locks"
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [IGNORE-ALL ] Ignore all package locks in the context of this operation.
1: [UNLOCK-PACKAGE] Unlock the package.
2: [CONTINUE ] Ignore and continue with next --eval option.
3: [ABORT ] Skip rest of --eval options.
4: Skip to toplevel READ/EVAL/PRINT loop.
5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process).
можно попробовать unlock (ввести туда ":1") если непоможет проигнорировать (ввести ":0") если совсем нич не помогло, прочитать инструкцию :D http://www.sbcl.org/manual/
Вообще, ИМХО с cmucl траблей меньше. Я ранее сравнивал и решил таки cmucl юзать.
> Кстати о статической типизации, недавно нашл один интересный лисп: http://lush.sourceforge.net/. В нм есть офигенно эффективный компилятор для статически типизированного кода. Если быть точным, генерируется код на C, и код получается обычно такой же, как я бы руками написал. Ну и что меня вообще добило, в программу на лиспе можно запросто делать вставки на С. :) Кто там хотел лисп с ассемблерными вставками? Да лехко! :D
Не, нам такого не надо. Макр нет, объектная система - хуже чем у тикля. А код на си генерируют gcl и ecl - почти полноценные CL-и :)
Я исправил ошибку с путем после своего поста. Вот где лежат исходники
сейчас:
http://ignas.pov.lt/lambda-gtk_0.1.tar.gzhttp://common-lisp.net/project/cffi/releases/cffi_0.9.2.tar.gz
Я не знаю, как конфигурируется в Генту, поэтому снеси
поставленные тобой из ПОРТЕЖЕЙ lambda-gtk и cffi. Сделай, как я
написал.
$ls ~/sbcl
lambda-gtk_0.1/
cffi_0.9.2/
$ls -l ~/.sbcl/systems
cffi.asd -> /home/<user>/sbcl/cffi_0.9.2/cffi.asd
lambda-gtk.asd -> /home/<user>/sbcl/lambda-gtk/lambda-gtk.asd
lambda-gtk-examples.asd -> /home/<user>/sbcl/lambda-gtk/lambda-gtk-examples.asd
Проверь обязательно правильность линков на *.asd-файлы в каталоге. Эти
линки -- это что-то вроде make-файлов (только на Лиспе). Там
зависимости пакетов и пр. информация. Не ошибись в именах. Я в
инструкции тебе опечатался и назвал пакет lambda-gkt-examples.
Заходи в sbcl и набери тогда уж (require 'lambda-gtk-examples). Должно
пойти. Я только что проверил у себя. Все отлично работает.
После компиляции запускай простую рисовалочку (scrible-simple) и др.
примеры (см. выше). Это примеры из онлайн-учебника с gtk.org, кажется.
Вс там есть, только называется ни defmacro, а dm почему-то. :)
> А код на си генерируют gcl и ecl - почти полноценные CL-и. :)
Знаем мы, какой они код генерируют, это убиться проще! :D Ну и сишные вставки им и не снились, понятно.
Короче, lush - это такой лисп для задач с элементами числодробления. :) Там в комплекте и привязки к соответствующим библиотекам есть: GSL, FFTW, BLAS, LAPACK, MPI и т. д. По количеству баратеек для околонаучных расчтов он явно рулит.
>3. возьми clg2 (он поновее) или cells-gtk - вроде наиболее динамичный на данный момент.
Я пробовал давно cells-gtk. Мне не понравилось. Там ему какой-то .so файл зачем-то нужен, который нормально не скомпилировался из C. Мрак. какой-то. Хотя сама идея cells мне нравится.
Вот только gtk-cells с clisp не очень получяецо. Если в виджет передавать строки с кириллицей, будет "невозможно отконвертировать к инородному типу FFI:UCHAR". А с cmucl дык в самый раз.
Тут была речь об инлайне? И в Лиспе есть. В компиляторах. :)
(declaim (inline f))
(defun f ...)
Кто-то спрашивал, во всех-ли реализациях оптимизация и типы? Все эти
параметры оптимизации стандартом оговариваются. Реализовано не везде, а
там, где это нужно: CMUCL, SBCL, Allegro CL, LispWorks. Это я знаю.
по-моему, еще в Corman Lisp. Последнии три -- коммерческие, но есть
бесплатные версии для личного пользования (по-моему). Насчет GCL и ECL
не знаю. Не интересовался.
Первый вариант -- (asdf:operate 'asdf:load-op 'lambda-gtk-examples) -- тоже сработал, и тоже ни один из примеров не запускается. Кроме того, в упор не вижу, где здесь "по цепочке скомпилируется cffi, потом
lambda-gtk, потом lambda-gtk-examples".
> Кто-то спрашивал, во всех-ли реализациях оптимизация и типы? Все эти параметры оптимизации стандартом оговариваются. Реализовано не везде, а там, где это нужно: CMUCL, SBCL ...
Я правильно понимаю, что можно писать статически типизированный код на Common Lisp, если использовать CMUCL или SBCL, и этот код - стандартен и воспринимается остальными реализациями CL (пусть даже проверки типов и не работают в остальных реализациях) ?
> Я правильно понимаю, что можно писать статически типизированный код на Common Lisp, если использовать CMUCL или SBCL, и этот код - стандартен и воспринимается остальными реализациями CL (пусть даже проверки типов и не работают в остальных реализациях) ?
Наверное тебе пора заглянуть в HyperSpec. А отличия от стандарта описаны в каждой реализации.
Посыпаю голову пеплом! У меня версия lambda-gtk 0.2! Возможно, что 0.1 с cffi неправильно работает. Давай почту - я тебе залью, потому что я не помню, где взять исходники. По-моему, битая ссылка на common-lisp.net туда и вела. А сейчас что-то там не так. Сейчас вышлю и все должно заработать.
Спасибо, теперь поехало! В принципе, хотелось бы в таком же духе и по другим животрепещущим вопросам. Ну да ладно, попробую пока так поковыряться. Глядишь, и освоюсь...
Ну можешь тогда еще на clg взглянуть. Сам я не пробовал. Мне пока морды нужны во вторую очередь. lambda-gtk -- это фактически 1:1 биндинг к GTK. А вот clg умеет xml файлы Glade жрать. А это означает, что ты можешь морды накидать в Glade, потом сохранить в xml. и Lisp их сожрет. :) То есть в теории решение более продвинутое для интерфейсов на GTK.
> А это означает, что ты можешь морды накидать в Glade, потом сохранить в xml. и Lisp их сожрет. :) То есть в теории решение более продвинутое для интерфейсов на GTK.
А мне всегда казалось, что XML - это костыль для недоязыков типа жабы. :) А родные S-выражения тогда на что?
Потом также распаковываешь в ~/sbcl, делаешь линк на ltk.asd в
~/.sbcl/systems и запускаешь (require 'ltk). Все в миг скомпилится (весь биндинг -- один файл). И запускаешь примерчики (ltk::ltk-eyes) и (ltk::ltktest). Второй понавароченнее. Там колесо крутится. :))
Причем LTK можешь и в CLISP попробовать. Работает изумительно. (если только от LTK не тошнит. Меня -- нет :)
>Если грамотно завернуть, то код стройнее получается. По крайней мере, компоненты легче видны.
Точно. Грамотный лиспер-энтузиаст пишет свой DSL для описания интерфейсов. Высокоуровневый. А еще в этом DSL можно использовать всю мощь LISP, потому что этот DSL тоже будет LISPом. И никаких там, понимаешь, Глэйдов. Чего там нам Глэйд даст? статиченскую картинку с названиями и свойствами объектов? А тут тебе и описание морды (можно спереть у Глэйд формат, но только в виде s-выражений сделать нормальных, и как, и что происходит при нажатии, клацании мыкой, клавиатурой. И тебе тут и макры, и функции. Это и называется -- грамотно завернуть :) Чтобы потом красиво разворачиволось непосредственно в GTK. :)
> Насчет статической типизации - аминь, а Ocaml - он еще маргинальнее Лиспа.
Tailgunner, никак не могу понять как ты можешь совмещать в себе любовь к статической типизации и Питону одновременно? Для меня это загадка посильнее будет чем лисперы :-)
Если тебе _так_ нужна статичемкая типизация и ты пршься от Питона, то тебе сюда: http://boo.codehaus.org/
Хелло ворлд на Boo:
print 'Hello, world!'
На нм можно написать достаточно большую программу и на первый взгляд может показаться что это Питон, но на самом деле это язык с сильной статической типизацией для .NET. Пашет на Mono, в портаже есть.
> как ты можешь совмещать в себе любовь к статической типизации и Питону одновременно?
Я люблю Питон не за его динамизм (который иногда очень полезен), а за мощные, но при этом удобные средства работы с данными - списки, итерацию. Вообще, Питон - это уникальная комбинация мощности и простоты использования. Но, ИМХО, динамическая типизация здесь большой роли не играет.
Вот вопрос: как ты проведешь рефакторинг большой проги на Питоне? Переименованы классы, добавлены/удалены поля, измемены сигнатуры методов. На Си/Си++ делается рекомпиляция, и компилятор сам показывает, где несовпадения. На Питоне придется искать самому, и не факт, что вс найдешь. Остается полагаться на тесты, но 100% test coverage не бывает.
Кстати, здесь проскакивали интересные ссылки на работу по type inference для Питона: Starkiller и Aggressive Type Inference.
Я бы не сказал, что я прусь. Некоторые вещи в нем меня сильно раздражают - например, отсуствие try-except-finally (наконец-то добавили в 2.5, знаю), отсуствие многострочной лямюды, или то, что неотделим от огромной библиотеки ("поставляется с батарейками" - а они не всегда нужны). Но по совокупности возможностей Питон - лучшее в своем классе.
Ты уже гооврил :) Я зашел по ссылке - совершенно не впечатлился. Это на Питон похоже только отдаленно, пользует .NET, и, похоже, оффтопик-ориентироано. А мне нужно "real thing", под линух, и легкая интеграция с native-кодом (да, и заверните мне Numeric Python и Matplotlib). Boo - игрушка для энтузиастов (так же, как Лиспы ;)). Если я захочу поиграть в такие игры, буду играть с PyPy, или Haskell/Ocaml.
> Насчет статической типизации - аминь, а Ocaml - он еще маргинальнее Лиспа.
Фигасе.
Язык, позволяющий быструю и эффективную разработку и результат сравнимый по скорости исполнения с хорошо написанным руками С, называется маргинальным?
А если речь о распространенности, что гроша выеденного не стоит шкала "маргинальный" -- "немаргинальный".
> гроша выеденного не стоит шкала "маргинальный" -- "немаргинальный".
Распространенность => это широкий выбор инструментов и их хорошая отлаженность. И можно сколько угодно говорить о "быстрой и эффективной разработке", "результат сравнимы с написанным руками Си", но закон Райзера никто не отменял. Не говоря уже о том, что в случае проблем - спросить не у кого (потому что почти все - хоббисты), нет литературы/документации в Сети... это вс и есть маргинальность. Для _тебя_ это может не стоить и гроша, а для меня это важно.
> Вот вопрос: как ты проведешь рефакторинг большой проги на Питоне? Переименованы классы, добавлены/удалены поля, измемены сигнатуры методов. Остается полагаться на тесты, но 100% test coverage не бывает.
Ты прав, это проблема. Это надо делать аккуратнее чем на языке со статической типизацией. Но это вообще проблема не только динамической типизации но и позднего связывания, даже в зяыках со статической типизацией.
Ещ pychecker / pylint могут помочь. И стремиться к 100% test coverage
> Но это вообще проблема не только динамической типизации но и позднего связывания, даже в зяыках со статической типизацией.
Там она стоит отнюдь не так остро - поэтому я бы убил ради статически типизированного Питона :)
> Ещ pychecker / pylint могут помочь.
pylint - вещь, ИМХО, бесполезная. pychecker - да, помогает, но мало.
> Dylan
В отличие от Boo, Dylan мне активно не понравился. Вообще, такое впечатление, что значительная часть language designer'ов просто недовыпендривались в детстве, и компенсируют это в разрабатываемых языках.
>> Если я захочу поиграть в такие игры, буду играть с PyPy, или Haskell/Ocaml.
> Да Haskell это круто, а он динамически библиотеки загружать научился?
Ты как будто писать на нем собрался ;) Если "на поиграть" - то пох динамические библиотеки :)
> Язык, позволяющий быструю и эффективную разработку и результат сравнимый по скорости исполнения с хорошо написанным руками С, называется маргинальным?
а только такой и называецо. Понятие "маргинальный язык" вообще появилось одновременно с недоацтоем вроде делфей и висуалвасика, потому что это понятие срочно понадобилось для пересадки разработчиков на недоацтои, а размных аргументов никаки не нашлось.
> в случае проблем - спросить не у кого (потому что почти все - хоббисты), нет литературы/документации в Сети...
В случае с лиспом всево этово ну просто завались. Во всяком случае больше чем с например тем же питоном. Да и самостоятельно разобраться проще, ибо вс не такое извращнное.
>Понятие "маргинальный язык" вообще появилось одновременно с недоацтоем вроде делфей и висуалвасика
Ты определись - с Делфями и Визивасиком? Они в разное время появились. Впрочем, ты этого не помнишь.
> для пересадки разработчиков на недоацтои, а размных аргументов никаки не нашлось.
"Пересадки", я плакал. Марш историю учить! 1) И Дельфи, и Визивасик были существенным шагом вперед по сравнению с предшественниками - TurboPascal и QuickBasic 2) лисперы и прочие знатоки "неацтойных" языков были в дефиците, и высокомерно плевали на рынок PC.
Delphi - достойная и удачная система. То, что ее использовали стада быдлокодеров - это не ее вина.
Это закон такой. Программисты знают, а остальным не нужно.
>> в случае проблем - спросить не у кого (потому что почти все - хоббисты), нет литературы/документации в Сети...
> В случае с лиспом всево этово ну просто завались.
Чего "этого"? Литературы - да, за 50 лет накопилось. Спросить? Ни фига, все либо хоббисты, либо с таким самомнением, что лучше бы и не отвечали. Мои слова о распространенности ты просто проигнорировал - а ведь из этого почти вс остальное и вытекает.
> Да и самостоятельно разобраться проще, ибо вс не такое извращнное.
Если спросить 10 случайно выбранных программистов, не знакомых ни с Лиспом, ни с Питоном, что им понятнее - текст на Лиспе или на Питоне, все 10 скажут - на Питоне. Но ты-то знаешь, что они все извращенцы...
> Delphi - достойная и удачная система. То, что ее использовали стада быдлокодеров - это не ее вина.
Быдлокодер пишуший на delphi останется быдлокодером. В отличие от. Уже за это создателей делфи должно судить в Нюрнберге за преступления против человечества.
> Быдлокодер пишуший на delphi останется быдлокодером. В отличие от. Уже за это создателей делфи должно
За то, что он не делает из быдлокодера - суперкодера? За это же нужно судить создателей Си, Паскаля, SQL и т.д. Да и создателей Лиспа - тоже. В общем, "всех убью - один останусь".
Или быдлкодер, вынужденный писать на Лисп, волшебным образом совершенствуется? "Не верю" (C) Станиславский.
> Ты определись - с Делфями и Визивасиком? Они в разное время появились. Впрочем, ты этого не помнишь.
Да примерно в одинаковое, в конце 9х дето. Действительно худо помню, не особо мя этот вопрос волнует.
> "Пересадки", я плакал. Марш историю учить! 1) И Дельфи, и Визивасик были существенным шагом вперед по сравнению с предшественниками - TurboPascal и QuickBasic 2) лисперы и прочие знатоки "неацтойных" языков были в дефиците, и высокомерно плевали на рынок PC.
вобщето тогда можно было свободно на сях работат, ч я и делал. По сравнению с сями эти во всех отношениях, как в быдлопесне поцо "Стоша Говнозад тихо на пальцах...". А для лиспа и прочих аппаратура писихек слабовата была и тормоза немеряные, отчево и плювали, всодно бесполезно.
> Delphi - достойная и удачная система. То, что ее использовали стада быдлокодеров - это не ее вина.
> Это закон такой. Программисты знают, а остальным не нужно.
ч тада умоминаеш если те всодно ненужный?
> Спросить? Ни фига, все либо хоббисты, либо с таким самомнением, что лучше бы и не отвечали
давай ссылу в студию, де ты спрашивал а там лучебы не отвечяли
> распространенности
пох распространнось. Пять годов тому про дотнениненадо никто и не знал, а щяс если не распространный, то по крайней мере многие знают ч такое бывает хотябы. Хотя он во всех отношениях хуже не то што лиспа но даже висуалвасика.
> Если спросить 10 случайно выбранных программистов, не знакомых ни с Лиспом, ни с Питоном, что им понятнее - текст на Лиспе или на Питоне, все 10 скажут - на Питоне. Но ты-то знаешь, что они все извращенцы...
А если просить 10 случяйно выбратых бомжей, не знакомых ни с лиспом ни с питоном, все 10 скажут - нам пох. Ич?
> Что, каждый лиспер - свой DSL? Какое разбазаривание умственной энергии.
Скорее не "каждый лиспер - свой DSL" а "каждый лиспер в каждой задаче - свой DSL (если он там к месту)" :) "Лучше день потерять, потом за час долететь". Ну ты же пишешь кучу функций в любом проекте на других языках. Это практически тоже самое, только пользоваться проще :)
> В отличие от Boo, Dylan мне активно не понравился. Вообще, такое впечатление, что значительная часть language designer'ов просто недовыпендривались в детстве, и компенсируют это в разрабатываемых языках.
У Грэма об этом хорошо сказано. Смысл в том что учным надо писать статьи, а ситема типов языка программирования, это благодатная область.
Соответственно про язык с динамической типизацией, столько статей не напишешь, вот и плодятся всякие академические языки со статической типизацией, вместо того чтобы доделать один до юзабельного состояния или заниматься JIT в динамических языках.
Что для тебя важно?
Программист 1С может поднимать неплохие деньги. Сравнимые, видимо, с получаемыми мной. Но это не делает 1С пристойным занятием с моей точки зрения.
Один раз попробовал - не получилось. Чтобы попробовать второй раз, мне нужны веские причины. Я работаю над их сбором (в том числе - в этом треде), но пока не густо...
> вот и плодятся всякие академические языки со статической типизацией
Пусть плодятся. Это же исследования - они не обязаны приносить немедленную практическую пользу. Вдруг додумаются, как доказывать правильность хоть умеренно сложных фрагментов программ - уже большое подспорье.
> вместо того чтобы доделать один до юзабельного состояния
Это не задача исследователей
> или заниматься JIT в динамических языках.
Тоже не их задача. И вообще - JIT в принципе менее мощен, чем статическая компиляция. Не зря разработчик Psyco сейчас в команде PyPy.
А JIT'ы плодят как раз корпорации и вольные прогеры - Java (несколько вариантов), .NET (и Mono), Psyco, Parrot.
> Один раз попробовал - не получилось. Чтобы попробовать второй раз, мне нужны веские причины. Я работаю над их сбором (в том числе - в этом треде), но пока не густо...
Зыть: вспомнил дурацкое определние рекурсии: "чтобы понять рекурсию нужно понять рекурсию" :) Так вот, чтобы понять, зачем тебе изучать лисп, нужно понять, что это такое. Для этого надо изучить лисп :)
> Тоже не их задача. И вообще - JIT в принципе менее мощен, чем статическая компиляция. Не зря разработчик Psyco сейчас в команде PyPy.
А нифига, JIT может давать больше ускорения чем статическая компиляция, т.к. во время рантайма есть больше информации о программе чем во время компиляции. И в доке к psyco примерно такая телега и прогоняется.
Это конечно, не снимает проблемы со статической проверкой типов, но тоже юмор.
>> Ты определись - с Делфями и Визивасиком? Они в разное время появились. Впрочем, ты этого не помнишь.
>Да примерно в одинаковое, в конце 9х дето.
Ага, 31-го декабря 1999 года 8/ Для справки: VB 1.0 - 1991, VB 2.0 - 1992, Delphi - 1994.
> вобщето тогда можно было свободно на сях работат, ч я и делал.
Естественным путем миграции с TurboPascal был Delphi, с QuickBasic и dBASE-клонов - VB. Кроме того, ни в одном из Си не было такого мощного и удобного в использовании инструментария работы с компонентами, как в Delphi и VB.
> По сравнению с сями эти во всех отношениях, как в быдлопесне поцо
Быдлопесен не слушаю, поэтому твою мысль не понял
> А для лиспа и прочих аппаратура писихек слабовата была и тормоза немеряные, отчево и плювали, всодно бесполезно.
Какая чушь. 486-е, появившиеся в 1989, и Пентиумы, появившиеся в 1992, были всяко мощнее процессоров VAX и 680[023]0 рабочих станций, на которых разрабатывался Common Lisp. Так что - не надо о слабости аппаратуры. Рынок _просрали_. Конечно, не рядовые лисперы в этом виноваты, но это не меняет факта.
>> Delphi - достойная и удачная система. То, что ее использовали стада быдлокодеров - это не ее вина.
> бугога. Ч же в ей удачново?
Мощный и простой в использовании конструктор интерфейсов. Неплохой язык программирования.
>> Спросить? Ни фига, все либо хоббисты, либо с таким самомнением, что лучше бы и не отвечали
>давай ссылу в студию, де ты спрашивал а там лучебы не отвечяли
Ты хоббист ;) (не хотел тебя задеть, извини). Но "вс-таки нужно но сложно переучивацо с алгоритмического стиля мышления на более абстрактный" звучит высокомерно, нет?
>> распространенности
> пох распространнось. Пять годов тому про дотнениненадо никто и не знал, а щяс если не распространный, то по крайней мере многие знают ч такое бывает хотябы. Хотя он во всех отношениях хуже не то што лиспа но даже висуалвасика.
И что? Для него уже до чертиков инструментов. Кроме того, я имел в виду системы с открытыми исходниками.
Кстати, какой именно из уймы языков .NET хуже Визивасика? F# ? 8)
> А если просить 10 случяйно выбратых бомжей, не знакомых ни с лиспом ни с питоном, все 10 скажут - нам пох.
Что-то тебя в сторону уносит - Whitespace, бомжи...
Ну фих их знаит, я имел в виду более-менее извесны стали к концу 90х.
> Естественным путем миграции с TurboPascal был Delphi
ну хтож вас туды загнал, в трупопаскаль-то? Я на 286х на м работал потомушто компилер намного более производительный был. Ифсио. На 386х уже смысла не было с им связывацо, там и ся были и ся++.
> Какая чушь. 486-е, появившиеся в 1989, и Пентиумы, появившиеся в 1992, были всяко мощнее процессоров VAX и 680[023]0 рабочих станций, на которых разрабатывался Common Lisp.
вот только вах тянул кучю юзверей, а 286 макимум как печятная машинка годилась. При появлении 486х и пентиумов туда резво перескочили недоподелия с доса, а полноценных систем и средств, соотвецтвующих моще просто не успели сготовить - место ужо занято. И это тянецо ещ до сих пор: хотя виндовсь ниасиливает всех возможностей сдняшнего железа, выгонять ево ещ долго будут.
> Рынок _просрали_
аха :( Вот только не из-за конкурентоспособного, а как раз методами давления на моск, как я и говорил о появлении типо понятия "маргинальный"
> Мощный и простой в использовании конструктор интерфейсов.
чем лучше того же борландовского owl?
> Неплохой язык программирования.
Чем лучше тех же сей с плюсами?
>>> Спросить? Ни фига, все либо хоббисты, либо с таким самомнением, что лучше бы и не отвечали
>> давай ссылу в студию, де ты спрашивал а там лучебы не отвечяли
> Ты хоббист ;) (не хотел тебя задеть, извини). Но "вс-таки нужно но сложно переучивацо с алгоритмического стиля мышления на более абстрактный" звучит высокомерно, нет?
ИМХО нет. Это - факт. Я сам много труда на это затратил. Мои первые проги на лиспе были длинны, карявы и весьма уродливы ибо составлялись более алгоритмически. По мере обучения я их переписывал, отчего они вконце стали вдвое-втрое короче первоначяльных и вдесятеро более понятными. Также "обычного" чела достаточно трудно обучить алгоритмическому.
> И что? Для него уже до чертиков инструментов. Кроме того, я имел в виду системы с открытыми исходниками.
ивот. Несмотря на множественные недостатки.
> Кстати, какой именно из уймы языков .NET хуже Визивасика? F# ? 8)
сама концепция хуже. а уж про с# и слов нету.
>> А если просить 10 случяйно выбратых бомжей, не знакомых ни с лиспом ни с питоном, все 10 скажут - нам пох.
> Что-то тебя в сторону уносит - Whitespace, бомжи...
ну меня твоя фраза о том, что десятеро программистов на схеме единодушно сочтут питоний код более понятным чем лисповый, тоже здорово рассмешила.
Значит неправильно пробовал. Для начала возьми sicp и прорешай его. Потом попробуй решить на лиспе какую-нибудь большую задачу. Например напиши систему, способную упрощать логические выражения.
> нo пoкa нe гycтo...
Думаю, дело в том преимущества лиспа проявляются во всей красе на больших задачах. А задачки уровня "найти в массиве самый большой и самый маленький элемент и поменять их местами" просто решаются и на лиспе, и на питоне, и на турбо-бэйсике.
>Ну фих их знаит, я имел в виду более-менее извесны стали к концу 90х.
Тоже нет. VB мгновенно стал хитом, Delphi тоже быстро набрал популярность.
>> Естественным путем миграции с TurboPascal был Delphi
> ну хтож вас туды загнал, в трупопаскаль-то?
Нас - никто, я юзал {Turbo,Borland} C++. Но TurboPascal был популярен, и с пришествием Windows народу надо было на что-то мигрировать.
> вот только вах тянул кучю юзверей
аха, MicroVAX в рабочей станции 8)
> а 286 макимум как печятная машинка годилась.
аха, но я-то говорил о 486+. Кстати, времена 386-х были, пожалуй, даже лучше для вторжения "взрослых" технологий.
> полноценных систем и средств, соотвецтвующих моще просто не успели сготовить - место ужо занято.
>> Рынок _просрали_
>аха :( Вот только не из-за конкурентоспособного, а как раз методами давления на моск, как я и говорил о появлении типо понятия "маргинальный"
Вот - ключевой момент. Если Лисп настолько лучше, чем вс остальное, пригоден для использования быдлокодерами и даже (по мнению некоторых) превращает быдлокодеров в суперкодеров - почему мощный десант CommonLisp'ов не смел все быдлоподелия? Мир стал бы куда лучше.
>> Мощный и простой в использовании конструктор интерфейсов.
>чем лучше того же борландовского owl?
OWL - это библиотека, а не конструктор интерфейсов.
>> Неплохой язык программирования.
>Чем лучше тех же сей с плюсами?
Не лучше, но гораздо проще. Мало кому нужна вся моща Си++
>> Кстати, какой именно из уймы языков .NET хуже Визивасика? F# ? 8)
>сама концепция хуже
Хуже чем что? Чем хуже? Мне вообще-то нравится концепция .NET - многоязыковая среда, позволяющая легкую интероперабельность между языками, managed code с возможностью прямого преобразования в "родной".
> а уж про с# и слов нету.
Не очень язычок, конечно. И развивается в какого-то монстра.
> ну меня твоя фраза о том, что десятеро программистов на схеме
На какой схеме? Где ты там это увидел? =8-0 Я сказал - "не знающих ни Питона, ни Лиспа"
Не уверен, что понял тебя правильно, но - меня волнует, чтобы программы, за которые я отвечаю, работали. Поэтому я опробую новые технологии с осторожностью - сначала на относительно небольших подзадачах. Поэтому "написание больших программ на Лисп" откладывется, пока он не зарекомендует себя на маленьких и средних.
> Тоже нет. VB мгновенно стал хитом, Delphi тоже быстро набрал популярность.
Я говорю ч сам видел. До виндовся 95 юзали lattice c, watcom, борландовский с/с++, ещ какуюто хрень. мсявый компилер был вроде анегдода, все над им смяялись и никто не юзал. До года примерно 98 тырфейсы под виндовсь делалисть восновном на борландовом с++ с овл, кроме прямово винапи, м которым было хоть сложнее, но проще. Потом эта нечисть попрла, делфи и прочее, причм по снгам токо. В буржуинстве делфи досих пор сравнительно раритет.
> TurboPascal был популярен
восновном скубенты на м лабы кропали. Эх, знать бы чем вс кончицо, луче бы поотчисляли всехнахъ.
> мощный десант CommonLisp'ов
Как ты се это представляеш? лисперы работают, а мси с борландом пеаряцо, это их заработок. Благо в компах мало кто шарил, им массовый дурятник и лохотрон сходил с рук. До сих пор сходит, но щяс ситуяйца уже выправляцо начяло.
> OWL - это библиотека, а не конструктор интерфейсов.
какая на йух разницо, если ей прользовацо проще а результат луче?
> Не лучше, но гораздо проще. Мало кому нужна вся моща Си++
Чем же оно проще? {} на begin end заменеты и... вс вроде? Откуда кстати в с++ моща?
> Хуже чем что? Чем хуже? Мне вообще-то нравится концепция .NET - многоязыковая среда, позволяющая легкую интероперабельность между языками, managed code с возможностью прямого преобразования в "родной".
Там, где можно просто скомпилить - выросла вм на пустом месте. В жабе есть хоть какая-то причина для вм, может быть даже не совсем оправданная, а тут... Вс предоставляемое дотнетиненадом намного лучше и проще решается традиционными средствами. Вобщем, достаточно посмотреть как оно работает.
>> ну меня твоя фраза о том, что десятеро программистов на схеме
> На какой схеме? Где ты там это увидел? =8-0 Я сказал - "не знающих ни Питона, ни Лиспа"
Почему программер на схеме не может попадать под это определение?
> Не уверен, что понял тебя правильно, но - меня волнует, чтобы программы, за которые я отвечаю, работали. Поэтому я опробую новые технологии с осторожностью - сначала на относительно небольших подзадачах. Поэтому "написание больших программ на Лисп" откладывется, пока он не зарекомендует себя на маленьких и средних.
Тогда тебя скорее волнует конкретная реализация CL, а не технология инкрементальной компиляции, которой "сто лет в обед" и которая сама по себе скорее всего не принест тебе никаких неудобств :)
>> OWL - это библиотека, а не конструктор интерфейсов.
>какая на йух разницо, если ей прользовацо проще а результат луче?
Речь не о тебе, а о среднем программисте (типа меня). Мне - удобнее пользоваться конструктором интерфейсов, чем набирать код руками (я считаю недостойным делать руками то, что автоматизировано ;) ). Насчет "результат лучше" - мне работать с OWL (на OS/2) никогда не нравилось.
>> Не лучше, но гораздо проще. Мало кому нужна вся моща Си++
>Чем же оно проще? {} на begin end заменеты и... вс вроде?
Ну и по мелочи - шаблоны, перегрузка операций, свое управление памятью, множественное/виртуальное наследование.
> Откуда кстати в с++ моща?
Вс, что есть в Си + см. выше. Хотя если моща - в крутых макрах, тогда ой.
>> мощный десант CommonLisp'ов
>Как ты се это представляеш? лисперы работают, а мси с борландом пеаряцо, это их заработок. Благо в компах мало кто шарил, им массовый дурятник и лохотрон сходил с рук.
А Лиспом коммерческие компании не знаимались, нет? Еще раз - если они считали, что у них на руках продукт, который превосходит вс имеющееся на порядок - почему они не ломанулись на завоевание? Я так думаю, они не считали Лисп настолько лучшим решением, чтобы хоть попробовать. Ты читал "Good news, bad news, how to win big"? Специально для тебя нарыл ссылку: http://www.shootybangbang.com/weenix/good-news-bad-news.txt
>> На какой схеме? Где ты там это увидел? =8-0 Я сказал - "не знающих ни Питона, ни Лиспа"
>Почему программер на схеме не может попадать под это определение?
>Получать удовольствие от работы, обеспечивающей приемлемый уровень жизни.
Я тоже.
Эта работа не связана практически с программированием, разве что в крайних точках. Но вот чтоб мозг не заплывал жиром, попрограммливаю по-мелочи. Так сказать, ради академической красоты. И вот ее в ocaml в N раз больше чем в delphi и vb, вместе взятых.
PS. Лисп мне не нравится. Чисто синтаксисом. Все эти скобочки.... Вон в ocaml скобочек нет почти.
Я ни слова не сказал о компиляции. Насчет реализаций - тоже пока не важно. К тому времени, когда у меня появится второй шанс попробовать Лисп в деле, многое может быть иначе.
> работа не связана практически с программированием, разве что в крайних точках. Но вот чтоб мозг не заплывал жиром, попрограммливаю по-мелочи. Так сказать, ради академической красоты.
А моя работа - сплошное программирование, и мозги не то, чтобы жиром не заплывают, а выгорают потихоньку. И, хоть я и ценю академическую красоту, наличие библиотек, инструментальных средств, отлаженность и интегрируемость в существующие программы, легкость освоения командой - вс это более важно.
> PS. Лисп мне не нравится. Чисто синтаксисом. Все эти скобочки...
> я считаю недостойным делать руками то, что автоматизировано
А тот факт, ч в делфях _до_сих_пор_ нету layout manager и приходицо вручную делать обработчики ресайзов, тя не смущяет? К концу 90х в других тулах оно вроде было ужо? (могу ашыбацо)
> Ну и по мелочи - шаблоны, перегрузка операций, свое управление памятью, множественное/виртуальное наследование.
сборщика помойки ни там ни сям небыло, а остальное в с++ такое же только лучше.
> Вс, что есть в Си + см. выше. Хотя если моща - в крутых макрах, тогда ой.
Ну, такая моща, от которой больше траблеф...
> почему они не ломанулись на завоевание?
Потому что на раскрутку лохотрона денюх больше нужно чем на разработку полезной тулзы. Одновременно и то и с тянуть сложно. LispWorks вроде неплохо жывт... Виш, я думаю даже ч у них прибыли с солидных клеентов не меньше, чем у борланда от прыщявых скубентов, которые щитают нарисовать мышом кнопку в формочьке верхом крутизны. Вендовые платные лиспы жывы до сих пор, а борланд, виш, скопытилсо.
>>> На какой схеме? Где ты там это увидел? =8-0 Я сказал - "не знающих ни Питона, ни Лиспа"
>>Почему программер на схеме не может попадать под это определение?
>Потому что Scheme - это такой Лисп.
аха, а питон это такой уайтспейс. Только что называюцо поразному, к чему бы это?
Непривычно просто. Зато удобно. Если с сями сравнивать, скопки заменяют всякие {},; и остаюцо в таком же количестве при вызовах функций. Так что у лиспа фактически служебных символов числом меньше.
>> я считаю недостойным делать руками то, что автоматизировано
>А тот факт, ч в делфях _до_сих_пор_ нету layout manager и приходицо вручную делать обработчики ресайзов, тя не смущяет?
[Сразу скажу - сам в Delphi не работал, хотя поработал в C++Builder.]
Отсуствие layout cмущает, хотя и не сильно. И в Delphi есть anchors, которые выполняют похожую на layout функцию. Вообще, layout - штука полезная и обычно удобная, но... без нее вполне можно обойтись.
> Вендовые платные лиспы
То есть Лиспы для Винды были, но никакого распространения не получили? И виноват в этом пеар от M$? А по-моему, все причины хорошо описаны в "Good news, bad news". И основная из них - Лисп не настолько лучше, чем вс остальное.
>>Потому что Scheme - это такой Лисп.
>аха, а питон это такой уайтспейс
Это твое личное мнение?
> Только что называюцо поразному, к чему бы это?
Ты лиспер. тебе виднее. Цитата из Габриэля (знаешь такого? ;): "Among these Lisps were Scheme, Interlisp, Franz Lisp ..."
> lambda-gtk в Gentoo отлично ставится и работает из portage
В 2006.1 для amd64 оно намертво замаскировано. А в самих исходниках не хватает половины файлов из пакета, который таки у меня пошел.
Во вранье обвинять не буду, потому как с помощью напильника в конце-концов работает все. Однако если под "отлично ставится и работает из portage" понимать хотя бы отсутствие маски "~amd64", то утверждение явно неверно.
Опять же, там лямбда версии 0.1, а запустить удалось только 0.2.
> Правда с CMUCL
А это вообще ни в одной версии под amd64 успешно не собралось.
Как говорится, выживает самый приспособленный. Пока что останусь на SBCL.
Нет, не пригоден. Человек либо научится программировать, либо не будет использовать лисп. Так или иначе но быдлокодер не будет программировать на лиспе.
> Нет, не пригоден. Человек либо научится программировать, либо не будет использовать лисп. Так или иначе но быдлокодер не будет программировать на лиспе.
Почему нет? Не вижу никаких причин, почему бы у быдлокодера это невышло. Правда и причин, по которым понадобилось бы быдлокодеру работать на лиспет - тоже.
> He вижy никaкиx пpичин, пoчeмy бы y быдлoкoдepa этo нeвышлo.
Да язык предплоагает к работе с высокими уровнями абстракции. Человек это либо может, либо нет.
С другой стороны можно писать на cl в убищно-императивном стиле. Тогда получится обычный алголоподобный язык, только со скобками и префикскной нотацией. Но это уже клиника.
> А тот факт, ч в делфях _до_сих_пор_ нету layout manager и приходицо вручную делать обработчики ресайзов, тя не смущяет? К концу 90х в других тулах оно вроде было ужо? (могу ашыбацо)
+1
GUI без layout manager это полный отстой
> аха, а питон это такой уайтспейс. Только что называюцо поразному, к чему бы это?
-1
Или ты в самом деле не можешь отличить вайтспейс от питона?
Клиника. Сам на делфятину год убил и ничему не научился. Но это будет _привычная_ клиника. Тогда как только префикскная нотация сама по себе убът мозг быдлокодера.
Что - вот прям-таки полный, GUI просто использовать нельзя, да? По-моему, layout manager просто облегчает обработку resize. И _вс_.
Кроме того - ну почему вы так уверены, что в Delphi нет layout manager? У вас большой опыт разработки GUI с использованием Delphi? Может, они там есть, но называются по-другому.
> на, покури. Смотри цены, почитай истории. Сравни с делфм потома.
Что это должно доказать? Что CL жив? Так я и не спорю, и не сомневаюсь. Или что Лисп - это выгодно коммерчески? Об этом там данных вроде нет, но я уверен, что Borland принес своим основателям/акционерам куда больше денег.
Хе-хе: Copyright Gold Hill Co. 2000 All rights reserved.
Но вс равно - ОК, существует куча Лиспов и Лисп-машин. Но все вместе они даже и не претендуют на мэйнстрим (уже 20 лет). Как это согласуется со всеми заявлениями о подавляющем превосходстве Лиспа?
>Лично у меня после этого башню сорвало и я понял, что до sicp'а совершенно не умел программировать.
Я уже почти 16 лет (круглая цифра, хе-хе) работаю программистом, мою башню так легко не сорвать! 8) Я прочитал первые главы SICP - осталось чувство легкого разочаровния: "и это то, о чем столько говорят?". Может, если бы на 2/3-м курсе...
>> Пoтoмy чтo Scheme - этo тaкoй Лиcп.
> Знаешь сколько копий было сломано во время обсуждения этого вопроса?
Честно говоря, нет. Эту страницу истории я как-то упустил. А кто с кем спорил? Нигде в литературе я не встречал, что Scheme - это не тру, наоборот - все пишут, что Scheme - это диалект Лиспа. И чем Scheme не Лисп?
> Что - вот прям-таки полный, GUI просто использовать нельзя, да? По-моему, layout manager просто облегчает обработку resize. И _вс_.
Я бы сравнил разработку GUI c layout manager (LM) против разработки без них как LaTeX и Ворд. Ну типа в ворде можно (в принципе) получить вс тоже самое, но только ты загребшься, и если надо будет что-то переделать, то в ворде надо исправлять съехавшую нумерацию и т.д. а с латехом только внести нужные изменения и заново прогнать латех.
Так и гуями, с LM тебе надо чуть-чуть поправить и вс остальное подстроиться само, а без LM надо опять вручную вс переставлять, выделять элементы, работать алайнмент-палитрой...брр...не могу вспоминать без содрогания.
Причм даже банальное изменение надписи на кнопки может привести к необходимости ручного перерасположения элементов. Поэтому во многих виндовых прогах в русских версиях надписи не влезают на кнопки, размеры то --- фиксированные.
И это даже не говоря о том, что бинарные файлы формочек, натасканных мышкой плохо поддаются системам контроля версий, а если писать в ручную с LM, то вс ништякъ
> Кроме того - ну почему вы так уверены, что в Delphi нет layout manager? У вас большой опыт разработки GUI с использованием Delphi? Может, они там есть, но называются по-другому.
C++ Builder. До питона +wxPython я писал на билдере (а делфи и билдер это, имхо, близнецы братья), и отлично понимаю почему окна во многих программах, написанных на билдере/делфи не ресайзятся. Это просто тяжело, нудно и долго, проще запретить ресайз окна.
> принес своим основателям/акционерам куда больше денег.
если бы продолжал приносить, фих бы обанкрутили наверное?
> даже и не претендуют на мэйнстрим
если под мейнстримом подразумевать прщявых скубентов, дружно кропающих хеловорды, то ЗАЧЕМ ЛИСП В МЕЙНСТРИМЕ? в смысле, кто станет тратить денюх чбы туда ево запихать? Для работы, да, вещ незаменимая. Я сам это прочувствовал, весьма мнозе времени и сил экономит. А скубенты хай возяцо с делфами/дотнетиненадом/питоном/прочим, им это вс равно.
я ужо отметился тут, у их даже парадигмы разные вот. Схема - это чисто функциональное, с гигиеническими тампаксами^Wмакросами, ещ всяким, короче мало ч общево.
> Я бы сравнил разработку GUI c layout manager (LM) против разработки без них как LaTeX и Ворд.
С Вордом знаком поверхностно, с Латехом - не знаком совсем. У _меня_ разработка с layout manager занимает больше времени, чем без него. Ибо с ним - надо думать, без - просто класть контролы на форму. Правда, с ним результат лучше.
> даже банальное изменение надписи на кнопки
Да, в этом случае тоже полезно.
> бинарные файлы формочек, натасканных мышкой плохо поддаются системам контроля версий
Серьезный недостаток, да. Но они же не обязаны быть бинарными - это артефакт реализации.
>> Может, они там есть, но называются по-другому.
>C++ Builder.
Отлично. Если ты хорошо знаешь Билдер - что там за хрень, называемая anchor? Вроде как ее можно использовать для задания взаимного расположения контролов. Типа layout manager. А?
> Можно и на ты :-)
Дык всегда :) Под "вы" я имел в виду тебя и глюкодела ;)
>> принес своим основателям/акционерам куда больше денег.
> если бы продолжал приносить, фих бы обанкрутили наверное?
Я говорю о доходах, которые он _успел принести_. И разве его обанкротили? Мне казалось, они просто продают свое подразделение по разработке софта, переориентируясь на консалтинг или что-то такое.
>> даже и не претендуют на мэйнстрим
> если под мейнстримом подразумевать прщявых скубентов, дружно кропающих хеловорды
По мэйнстримом подразумеваем массовое программирование. Что тебя так на студентах переклинило? Причем обязательно прыщавых.
> Для работы, да, вещ незаменимая.
Стоп, стоп. Ты вроде говорил, что не используешь Лисп для работы?
В чм то ты прав. Если показать быдло кодеру лисп и больше ничего не показывать, то он будет кодить на нм, также как сейчас кодит на бэйсике. И если ему покажут альтернативу он также будет говорить о е неудобности/нелогичности/страшности синтаксиса/etc, как сейчас он говорит это о лиспе.
Но ведь скорее всего лисп не будет его первым языком. Опять же отсутствие литературы типа lisp за 24 часа для анацефалов ....
фих ево знаит. Ты не ведаеш и я не ведаю. Вполне может быть ч принс, но лохотрон вещ рискованая, вот и накрылся бедолаго
> разве его обанкротили? Мне казалось, они просто продают свое подразделение по разработке софта, переориентируясь на консалтинг или что-то такое.
да, оный прошл чз процедуру банкрутства.
> Стоп, стоп. Ты вроде говорил, что не используешь Лисп для работы?
щ как юзаю. Я тамо выше код сервяка приводил, самый ч нинаесь рабочий. Готовые проги клиентам отдаю, те на сях, да. Но лисп весьма помогает сделать их быстрея и качественнея.
> Отлично. Если ты хорошо знаешь Билдер - что там за хрень, называемая anchor? Вроде как ее можно использовать для задания взаимного расположения контролов. Типа layout manager. А?
Эта хрень может привязать позицию элемента к какой-либо границе родителя (TOP, LEFT, BOTTOM, RIGHT), т.е. это абстракция очень низкого уровня ;-)
Anchor заботится о положении индивидуального элемента, а не группы элементов, как LM. С LM ты задашь логическую структуру интерфейса, а он сам делают визуальную раскладку индивидуальных виджетов.
Даже MS признал необходимость LM в новой версии LM, хотя ещ недавно в MSDN можно было найти статью о том что LM у нас нет, и нам это не надо, т.к. мы не тупые линупсоиды и нам нет неоходимости затачивать интерфейс под переводы.
> Но вс равно - ОК, существует куча Лиспов и Лисп-машин. Но все вместе они даже и не претендуют на мэйнстрим (уже 20 лет). Как это согласуется со всеми заявлениями о подавляющем превосходстве Лиспа?
Ал, ну может хоть здесь не будем гнать пену про крутость мэйнстрима и ущербность всего остального, а? :-Е
> Ал, ну может хоть здесь не будем гнать пену про крутость мэйнстрима
Ал, меня хорошо слышно? Я не говорю, что мэйнстрим - это круто. Мэйнстрим выбирает то, что оправдано экономикой и массовой психологией. И я спрашиваю (подчеркиваю - не гоню пену, а спрашиваю): если Лисп столь очевидно и намного превосходит все существующие ЯП, и, следовательно, выгоден экономически и психологически, почему он не используется в мэйнстриме?
Заметь слова "очевидно" и "намного". Если Лисп превосходит другие языки _в чем-то_ и/или _не намного_, я понимаю почему он остается (и, очевидно, всегда останется) маргинальным.
> Ал, меня хорошо слышно? Я не говорю, что мэйнстрим - это круто. Мэйнстрим выбирает то, что оправдано экономикой и массовой психологией. И я спрашиваю (подчеркиваю - не гоню пену, а спрашиваю): если Лисп столь очевидно и намного превосходит все существующие ЯП, и, следовательно, выгоден экономически и психологически, почему он не используется в мэйнстриме?
Пилят, ну что за!...
"превосходит все существующие ЯП, и, следовательно, выгоден экономически и психологически" - с какого такого... бугра вс, что лучше, выгодно экономически? Большинство питается экологически чистыми продуктами, а не сидит в тошниловках типа MD?
Для того, чтобы хорошо писать на лиспе, надо (опять пойдут банальности) "уметь думать абстракциями высоких порядков", проще - просто придтся чаще думать, чем долбить по клаве или елозить мышью. Многих от этого тошнит, у других случаются колики в животе, третьи просто впадают в депрессию... Так вот кое-кто решил таких вместо того, чтобы отправить красить коровники или писать женские романы, обозвать "программистами", продать им лажу, а продуктами их "жизнедеятельности" восхищаться как венцом творения человеческого... Тьфу, паскудство!..
> Мэйнстрим выбирает то, что оправдано экономикой и массовой психологией
"мейнстрим" не может выбирать, это слишком неопределнное. Ктото выбирает ч ему выгодно, ктото ведцо на пиар, ктото пристраиваецо к общему потоку, ктото... Компы и ПО появились слишком недавно, и обществом ещ не "переработаны", наиболее эффективные модели пока не выработаны. И ещ не будут выработаны десятилетия как минимум. Знаеш сколько было разновидностей велосипеда сразу после изобретения? Хотя казалось бы вещ незамысловатая - два колеса и руль. И пришли к практически одной форме, на это понадобилось время. А с компами сложнее гораздо, это ведь целая зарождающяяся индустрия.
> если Лисп столь очевидно и намного превосходит все существующие ЯП, и, следовательно, выгоден экономически и психологически, почему он не используется в мэйнстриме?
Да потому ч рынок ПО далеко не уравновешен. Определнным кругам безусловно невыгодно если будут использовацо более эффективные средства, и на теперешном этапе развития рынка ПО именно оне рулят пока, ужель неочевидно?
tailgunner, я, например, знаю кучу групп которые наголову превосходит то убожество, которое крутят по радио/тель-авизору. Причм их превосходство очевидно любому человеку обладающему слухом и вкусом. Но их почему-то ни в быдлоящике, ни на радио нет. Почему?
> Я этого (что _вс_ что лучше, выгодно экономически) не утверждал. Специально просил заметить слова "очевидно" и "намного" - видно, ты их не заметил.
Вот упртый попался... :)
"если Лисп столь очевидно и намного превосходит все существующие ЯП" ну не все, но ладно - превосходит, но только КАК ИЗ ЭТОГО СЛЕДУЕТ, что "выгоден экономически и психологически"?
Что в вопросе не понятно?!!!! Никак из первой части вторая не следует по той простой причине, что само человечество не совершенно.
Угодай в последнее время убеждается, что рынок вообще весьма далк от равновесия. Причм это началось где-то с 70-ых годов позапрошлого века. А рыночная экономика хорошо работает только в равновесных системах. И вследствие этого человечество тратит уйму усилий крайне неэффективно.
P.S. Это я к тому, что полемическую базу флейма нужно расширить. А то мы русских физиков никогда не догоним.
> "если Лисп столь очевидно и намного превосходит все существующие ЯП" ну не все, но ладно - превосходит
Если не все - то вопрос снимается, вс ясно. Если не намного - тоже снимается по тем же причинам.
> КАК ИЗ ЭТОГО СЛЕДУЕТ, что "выгоден экономически и психологически"?
Как следует, что выгоден экономически: ты делаешь намного больше (он же намного превосходит!) за то же время; исследования показывают, что переход на новый инструмент происходит, когда он дает 37% выгоды. При этом ему особо не нужна реклама - он уже сам себя продает, все остальные ему не конкуренты.
Как следует, что выгоден психологически - всем хочется иметь мощную и быструю тачку/мотоцикл/комп/дельтаплан, так вот это - из той же серии.
И меня интересует ответ - почему этого не происходит с Лиспом? Это объективные законы.
> Да ну, запросто - достаточно tailgunner ещ 1000 раз спрсить, чем лисп лучше других языков :)
Я уже понял, что не получу ответа на _этот_ вопрос ;( Кроме того - я не стану спрашивать 1000 раз, мне скучно будет. Давайте так - я 500 раз спрашиваю, вы 500 раз отвечаете, и мы навсегда в Top 10? 8)
tailgunner, ты неисправимый идеалист и романтик. Твоя схема работает только в случае маленьких улучшений, когда новым станком/автомобилем/яп можно легко овладеть не ломая груз старых знаний. В случае революционно лучших технологий вс иначе.
Ещ пример: электронный документооборот на два-три порядка (а не на несчастные 37%) быстрее и удобнее бумажного. Однако поди ж ты, все официальные документы распечатаны и снабжены подписями и печатями. Отчего такое?
> я, например, знаю кучу групп которые наголову превосходит то убожество, которое крутят по радио/тель-авизору. Причм их превосходство очевидно любому человеку обладающему слухом и вкусом
Вкус - это сильно неформальная категория. Я вот - старый фанат "Ласкового мая", а ты наверняка его не любишь. И кто из нас прав? Я к тому, что производительность труда прогаммиста - это более-менее объективная категория, и не надо таких сравнений с попсой.
> Твоя схема работает только в случае маленьких улучшений, когда новым станком/автомобилем/яп можно легко овладеть не ломая груз старых знаний
Ну, она не моя... Кроме того, в 37% учитывается и затраты на ломку старых знаний. Я имею в виду - если Лисп на порядок лучше, то он вс окупит. Освоить новый ЯП (пусть даже Лисп) - не так уж сложно, даже если перейти на "более высокий уровень абстрактного мышления". Другое дело, что (ИМХО) даже такие затраты не будут оправданы, потому что Лисп не _настолько_ лучше.
> электронный документооборот ... Отчего такое?
Опять аналогии... Может, дело в многовековой инерции, которой в программировании просто нет?
Предыдущая такая революция стоила жизни моему деду, и чуть не стоила жизни другому деду, обоим бабушкам и отцу с матерью. Нет, слишком высокая цена за Лисп.
> И какими объективными критериями ты пользуешься для оценки производительности программистов?
Время, за которое он выполняет задание
> музыкальный слух является абсолютно формализуемым понятием.
Знаю. Поэтому и говорил о вкусе (художественном ;)), а не о слухе.
Кстати, с точки зрения музыкального слуха всякие там Высоцкие, Бернстайны, Диланы, Шевчуки и прочие Хетфилды с Янками и Летовыми - они же ацтой полный?
Для многих (похоже и для тебя тоже) это совершенно непосильная задача.
> Oпять aнaлoгии...
А вот ещ одна аналогия. В морских сражениях пароходы гораздо сильнее чем парусные суда. Ты думаешь, что как только научились создавать достаточно хорошие пароходы началось повальное перевооружение? Наивный.
> Moжeт, дeлo в мнoгoвeкoвoй инepции, кoтopoй в пpoгpaммиpoвaнии пpocтo нeт?
Ага, в программисты идут особые люди с безынерционным мышлением.
> Непонятно как это затраты на ломку привычек учли с точностью до процента.
Ну, умеют они как-то... И не затраты на ломку, а общую прибыль от мероприятия.
> Ты думаешь, что как только научились создавать достаточно хорошие пароходы началось повальное перевооружение?
Насколько я помню историю оружия, повальное перевооружение началось после того, как в боевых столкновениях пароходы убедительно уделали парусники.
>> Moжeт, дeлo в мнoгoвeкoвoй инepции, кoтopoй в пpoгpaммиpoвaнии пpocтo нeт?
> Ага, в программисты идут особые люди с безынерционным мышлением.
Во-первых, ты удобно проигнорировал слово "многовековой". Во-вторых, преучивание - это часть профессии программиста. Я работал в 7-8 операционках, с кучей инструментальных пакетов. Я привык переучиваться. Конечно, хотелось бы, чтобы следующая осваиваемая технология была более интересной.
Т.е. в вашей конторе все программисты выполняют одну и ту же работу, а в конце месяца смотрят кто кого обогнал и в зависимости от этого выплачивают зарплату? Жстко.
> Знaю. Пoэтoмy и гoвopил o вкyce (xyдoжecтвeннoм ;)), a нe o cлyxe.
Женская красота является ещ менее формализуемом понятием, однако мужчины легко делят женщин на красавиц и крокодилов. (0.0001% геронтофилов, некрофилов, педофилов и прочих уродов роли не играют)
> Т.е. в вашей конторе все программисты выполняют одну и ту же работу, а в конце месяца смотрят кто кого обогнал и в зависимости от этого выплачивают зарплату? Жстко.
Нет. Не приписывай мне того, чего я не говорил.
>> Знaю. Пoэтoмy и гoвopил o вкyce (xyдoжecтвeннoм ;)), a нe o cлyxe.
> Женская красота является ещ менее формализуемом понятием
Бог ты мой... ну кто тебе сказал такое? Женская красота довольно хорошо формализуется. Прочитай лекцию Гирина из Ефремовского "Лезвия бритвы", она в начале книги. Женская привлекательность - формализуется совсем плохо, потому что тут замешана индивидуальная психология. Но красота в понимании "сосуд она, в котором пустота" - всем ясна уж тысячи лет.
Похоже на развод лохов на бабки. Типа после применения нашей туши объм ресниц увеличиваются на 68%.
> Hacкoлькo я пoмню иcтopию opyжия, пoвaльнoe пepeвoopyжeниe нaчaлocь пocлe
тoгo, кaк в бoeвыx cтoлкнoвeнияx пapoxoды yбeдитeльнo yдeлaли пapycники.
Не совсем так. В николаевской России продолжали строить парусники вплоть до Крымской войны. (Да и после нее от них отказались не сразу и не полностью) Хотя до этого пароходы уже показывали в мелких войнах сво превосходство.
> Bo-пepвыx, ты yдoбнo пpoигнopиpoвaл cлoвo "мнoгoвeкoвoй".
А оно тут не главное. Главное что есть привычка и е фиг поменяешь.
Хорошо. Есть проект, в котором заняты человек 10-15 народа. Каждый делает свою часть. Как вы их отсортируете по пользе, которые они приносят?
> Пpoчитaй лeкцию Гиpинa из Eфpeмoвcкoгo "Лeзвия бpитвы"
Это формализация? Это очень нестрогия рассуждения на тему. Формализация это когда можно будет написать программу, скормить е картинки и она рассортирует женщин.
Я думаю, это из Бома, который уж точно не кидала. Хотя этот курс нам читали очень давно, и на прктике это не пригодилось.
> В николаевской России продолжали строить парусники вплоть до Крымской войны.
Ну ты и пример привел.
>> Bo-пepвыx, ты yдoбнo пpoигнopиpoвaл cлoвo "мнoгoвeкoвoй".
> А оно тут не главное. Главное что есть привычка и е фиг поменяешь.
Здесь бессмысленно спорить: если тебя не убедили революции, которые ты видел, то куда уж мне. "Пути меняются, Стилгар. Ты и сам их менял." -- Ф.Херберт, "Дюна"
>>Я пpивык пepeyчивaтьcя.
>А давай ты на лиспера переучишься.
Я один раз попробовал - не получилось. Пока не соберу достаточно информации - пробовать больше не буду, да и времени нет сейчас. А если соберу положительную информацию и будет шанс - попробую еще раз.
> Есть проект, в котором заняты человек 10-15 народа. Каждый делает свою часть.
Я - скорее всего по сложности работы, которую они выполняют (ты сейчас спросишь, как определить сложность работы? 8)). А вообще - это работа начальника отдела. Сотни тысяч людей ее делают. "Тоже мне, бином Ньютона." -- (C) Кот Бегемот
>> Пpoчитaй лeкцию Гиpинa из Eфpeмoвcкoгo "Лeзвия бpитвы"
> Это формализация? Это очень нестрогия рассуждения на тему. Формализация это когда можно будет написать программу
И это придет. Может, это и сейчас возможно - но никому не нужно (люди вполне справляются сами ;)). И даже если это сейчас не запрограммируешь - и что с того? Машины пока не понимают текстов и не умеют их переводить, не видят нормально, да мало ли чего еще.
> жсто задал критерий отбора --- умение попадать в разные высокие и низкие ноты.
Ну, раз пошли формальности - умение _точно_ попадать в _назначенные_ ноты. Не важно, высокие или низкие.
> Я ответил на твой вопрос. ---- Высоцкий в этом деле далеко не самый лучший.
Не-а, ты сказал "ацтой полный" ;) Точнее, сказал я, а ты согласился.
> А ты из этого сделал вывод, будто я сказал, что Высоцкий кретин, тексты у него тупые и слушать его невозможно.
_Я_ сделал вывод только о том, что слушать невозможно. Остальное ты мне снова приписал :( Кстати, в списке было много народа - и есть люди, которые считают, что у Леонарда Бернстайна хороший голос (уж никак не "ацтой полный").
> Ну куда это годится?
Непонимание и ошибки - неизбежны. Надо просто находить их и устранять.
Я не говорю о "революциях в ПО" (их было 1-2 за вс время вообще), я говорю о революциях в производстве/потреблении ПО. Я видел их 2 - переход на ПК и переход на Windows. Возможно, и третью вижу - переход на FOSS.
> Я к тому, что производительность труда прогаммиста - это более-менее объективная категория
А я к тому, ч производительность труда программисат никому неинтересна (кроме крайне редких исключений когда она интересна самому программисту). Ещ одна аналогия фкопилку - рабовладение существовало тысячелетия, если не десятки тысячелетий, хотя оно экономически невыгодно для общества.
Хм, судя по некоторым вопросам ты задавал здесь, ты не уверен даже ч лисп вообще бывает. Без обид, но действительно, прежде чем пытаться переучиваться, нужно хотя бы иметь представление, на што переучиваешся. Ато дествительно неполучицо.
> Погуглил, в delphi 2006 появились TFlowLayout и TGridLayout. О чм это говорит?
ИМХО о том ч ЛАЖА начинает проходить вс реже и поставщики традиционно отсталых и убогих технологий, пропихивемых только за щт пиара, хотябы в мелочях начяли задумываться о качестве.
Между прочим, так определяются в математике бесконечные множества - в них (собственная) часть равномощна всему множеству. Целые равномощны натуральным, действительные - рациональным.
> производительность труда программисат никому неинтересна (кроме крайне редких исключений когда она интересна самому программисту).
Ты это серьезно? Тогда позволь спросить - ты с какой планеты?
> Ещ одна аналогия фкопилку
Ещ раз повторю: доказательство по аналогии - мошенничество
> рабовладение существовало тысячелетия, если не десятки тысячелетий, хотя оно экономически невыгодно для общества.
Ну а эта фраза выдает всего лишь невежество^Wнезнание истории. Рабство появилось всего несколько тысяч лет назад, и появилось именно потому, что было _экономически_ выгодно.
>> производительность труда программисат никому неинтересна (кроме крайне редких исключений когда она интересна самому программисту).
> Ты это серьезно? Тогда позволь спросить - ты с какой планеты?
тутошние мы :( а на вашей прогесс дальше зашл?
> Ещ раз повторю: доказательство по аналогии - мошенничество
ну как хош
> невежество^Wнезнание истории
интересно, чь? тысячелетия ?= нескко тыщ лет? did you know what паровой движок был изобретн вон когда а начял использовацо вон когда? Впрочем, это простительно незнать тем, кто утверждает ч он уроженец иных планет.
В первый раз, наверное, со времен РФВС, прочитал _весь_ топик с удовольствием - много интересных мыслей, интересных ссылок, интересных мнений.
Вставлю свое скромное О(pinion). Безусловно прочтенный мною наполовину SICP (с выполненными упражнениями!) также вкорне изменил мой взгляд на программирования. _Нормальные_ программисты должны взращиваться именно на таких учебниках, я бы еще добавил хороший курс дискретной математики, алгебры (конечно-порожденные полугруппы) и математической логики. Что, как я понимаю, и изучается на Западе на специальности computer science. По нелепой иронии судьбы, в России, где так много талантливых людей, "программистами" называют именно (было)кодеров - людей, которые решают конкретные прикладные задачи с помощью компьютеров. Чтобы аналогия стала более прозрачной, сравните, например, бухгалтера и математика. И для того, и для другого математика - их хлеб. Но какова дистанция в стиле мышления и решаемых задачах! Так вот, хочу сказать, что будущих программистов попросту калечат, заставляя мыслить так, как выполняет работу вычислительная машина. Ведь как учат программированию - именно в терминах "а как это делает машина" (сам помню еще свою учительницу в школе, между прочим отличный педагог). И это происходит в ВУЗах(!). Посмотрите: за исключением нескольких ведущих ВУЗов страны на остальных на специальностях "программирование" изучают конкретные программы и языки, что в действительности, конечно, тоже нужно, но уже человеку, который более-менее специалист. Таким образом, без должной подготовки, растут не специалисты, а ремесленники, пусть и весьма искусные. Конечно, после "12 лет" такого существования, Delphi (паскаль) покажется "логичной", а scheme - странной. Не удивителен, также тот факт, что лучшие программисты часто выходят из стен математических и физико-математических факультетов - они могут и умеют думать абстрактно.
Таким образом, "mainstream" сейчас - это все более изощренные орудия труда для ремесленников от программирования (коих тут называют "быдлопрограммерами"), а не то, что составляет действительно computer science в приложении к практическим проблемам.
Скажу еще раз, чтобы не было недоразумений: безусловно, конечная цель любой науки - практика. Но она не должна быть единственной довлеющей силой, не должна _заменять_ эту самую науку. Иначе все станут ремесленниками, а не специалистами. Быть может и искусными, но не видящими решение дальше, чем того позволяют их инструменты и переданные учителем знания.
Ну не удержусь еще раз (на этот раз - точно последний, честно-честно)...
> хороший курс дискретной математики, алгебры (конечно-порожденные полугруппы) и математической логики
Нас, кстати, этому учили (наша программа была чем-то средним между американскими reference-программами по CS и SE). Дискретная математика и матлогика, в общем-то, пригодились, но алгебра...
> будущих программистов попросту калечат, заставляя мыслить так, как выполняет работу вычислительная машина.
А по-моему, это очень полезное качество (правда, я системный программист по специальности). Когда что-то идет не так, _приходится_ опускаться до того, "как это делает машина". Вообще, это умение "перейти на уровень ниже" очень полезно для программиста _практика_, того, кто пишет и отлаживает код.
Другое дело, что необходимо и умение перейти "на уровень выше" и увидеть лес, а не деревья. Здесь нужен какой-то другой предмет - теория систем, ТРИЗ, инженерная философия, если хотите :) Возможно, Scheme пригодится как язык лабораторных занятий по такому предмету.
Настоящий программист должен уметь представить работу системы на разных уровнях.
> лучшие программисты часто выходят из стен математических и физико-математических факультетов - они могут и умеют думать абстрактно.
Они умеют действовать на своем абстрактном уровне, но они часто (не всегда) с пренебрежением относятся к технической стороне дела - к тому, как их понимание задачи и ее решения ложится в код. В результате имеем полный швах в плане SE.
А то, что подготовка программистов сейчас - не обучение, а натаскивание, это, ИМХО, следствие деградации системы образования.
> Ну не удержусь еще раз (на этот раз - точно последний, честно-честно)...
хороший флейм согревает душу и тело :)
> Нас, кстати, этому учили (наша программа была чем-то средним между американскими reference-программами по CS и SE). Дискретная математика и матлогика, в общем-то, пригодились, но алгебра...
алгебра - это рекурсия, формальные языки (про конечно-порожденные полугруппы я не зря написал) и вообще одна из наиболее зрелых областей, воспитывающих абстрактное мышление.
> А по-моему, это очень полезное качество (правда, я системный программист по специальности). Когда что-то идет не так, _приходится_ опускаться до того, "как это делает машина". Вообще, это умение "перейти на уровень ниже" очень полезно для программиста _практика_, того, кто пишет и отлаживает код.
Полезно _представлять_, как делает это машина, да и то только в тех случаях, когда это действительно необходимо (непосредственная работа с железом, низкоуровневое программирование, агрессивная оптимизация), а не "думать как машина", тем более, в решении _проблемы_ это как раз мешает, бо нужно уметь абстрагироваться и использовать наиболее выразительные на этом этапе вещи.
И самое страшное, когда такой образ мышления неотделим от самого понимания человеком занятия "программирования". Есть у меня приятель - у него программа на любом языке (а он знает их немало, в смысле синтаксиса) - это программа на ассемблере - прямой перевод задачи на "машинный" язык :О
> Они умеют действовать на своем абстрактном уровне, но они часто (не всегда) с пренебрежением относятся к технической стороне дела - к тому, как их понимание задачи и ее решения ложится в код. В результате имеем полный швах в плане SE.
SE - это что? А про техническую сторону дела - так математику главное - решить. :)
Активный пеар местных лисперов сподобил меня в очередной раз взяться за покорение Лиспа. Вытащил из кладовки финнов, стряхнул пыль и приступил...
Прежде всего, обнаружил листок формата А4, на котором я, тогда еще студент, старательно расшифровывал мнемоники MicroLisp. Это та реализация, которую я таки с трудом нашел для ZX Spectrum, и которая занимала всего 6 килобайт кода. Правда, больше половины финских примеров не работало. Посему листок был аккуратно сложен в книгу, а книга поставлена на полку. До лучших времен. А вместо Лиспа был взят Форт, интерпретатор которого хоть и занимал аж целых 8 килобайт, зато все примеры из учебников в нем работали. Даже Лисп-машина ;-).
Ну да ладно. Вот другой момент: пролистывая лирику о Лиспе, натолкнулся на список серьезных систем, которые были на нем написаны. Так вот, никто не вспомнил о хите середины-конца 90-х -- Автокаде. С его чудным наречием Автолисп. Некоторые злопыхатели тут конечно скажут, что это все хлам и старье. Однако ж, знаю (заочно, правда) одного человека, который все это юзает, и даже отказывается ради него сползать с Windows 98. В общем, местами весьма актуальная система получается...
Впрочем, я опять не об этом. Я об том, что я добрался у финнов до главы о том, как списки в памяти хранятся. Тогда, в студенчестве, меня как-то эта глава не вдохновила. Ну списки и списки. Я в Паскале такие списки в то время левой задней за одну пару ваял. Аха. Без индексов и на рекурсии. Типа крута. Я тогда даже факториал на Паскале рекурсивно писал. Аха. Пробовал даже на третьем курсе рекурсивно написать метод Рунге-Кутта, что на численных методах требовалось. Но преподаватель решения ниасилил :-(. Впрочем, времена были тяжелые. Преподаватель, например, так и ниасилил мой чудный архиватор, который реализовывал упаковку хаффмен-методом на... Прологе. И как наш препод по трансляторам многочисленно кивал на мой парсер Паскаля, писанный на том же Прологе. Оба покемона, правда, безбожно тормозили, а парсер еще и вылетал с переполнением стека. Зато это было круто, концептуально чисто и, что особенно важно, -- высокоуровнево и абстрактно. В общем, лисперы должны меня понять.
Но речь опять не об этом. Речь о том, что я сейчас с высоты своего программистского пьедестала (чего бы там ни говорили всякие yyk'и) отлично знаю, чем массив отличается от списка. И хорошо понимаю, зачем, например, в GOBO для абстракции последовательности определены две реализации. Ибо вставка в середину массива в худшем случае имеет сложность O(n), а поиск -- не ниже O(log n), а то и вообще O(1). Для тех лисперов, которые не понимают -- это я о таких "лишних сущностях", как индексы ;-). С другой стороны, связанные списки имеют сложность вставки O(1), зато поиск -- не лучше O(n). По сортировке не скажу точно. Кажется, у Вирта можно найти алгоритмы O(n log n) и для тех и для других.
В общем, возвращаюсь к теме. Можно ли на Лиспе нативно (или, как любят говорить наши друзья-лисперы, "без кастылей") оперировать с абстракциями массивов? Ну то есть, еще более конкретно:
а) какова реальная сложность функции nth и предиката member (или что там есть аналогичного в CL)?
б) можно ли по необходимости выбирать одну из двух моделей хранения последовательностей, если не по именам функций, то хотя бы какими-нибудь ключами?
Ну а если кто из лисперов начнет задавать вопрос класса "нафиг нужно?", скажу прямо: нужна абстракция хэш-множеств. То есть, в задаче говорится, что упорядоченный набор данных ну ни разу не нужен, зато нужна скоростная выборка. Скажем, если хранить элементы в виде упорядоченного (отсортированного) списка, то вставка будет O(n) (как для массивов, так и для списков), а вот поиск, как я уже писал, порядка O(log n). А с использованием хэш-таблиц так вообще можно получить и вставку и выборку O(1). Правда, не всегда. Хэши, особенно для структур имеют дурную привычку деградировать, и мы тогда быстренько получаем выборку O(n). Посему я в свое время и не рискнул использовать Python (правда, тогда это был Ruby) для прототипирования. Ибо хз, как там эти хэш-функции считаются. Для надежности пришлось писать свои. А чтобы избежать геморроя со сборкой мусора, то единственным выбором для простоты разработки остался Эйфель.
Если кто еще не понял, нафига мне этот огород, спрошу еще прямее: нужна эффективная работа с BDD/MDD. Ибо на отдельных эпизодах приходилось поддерживать в кэше до 200000 узлов, на на стресс-тестах, которые так и не прошли -- до миллиона. В MoscowML работа с BDD реализована через внешние библиотеки на С. Вот такой кастыль, да. Ибо язык не строит из себя функциональную целку и допускает простую (ну, не такую простую, как в Эйфеле, конечно же) интеграцию с ассемблером. А как оно в Лиспе? Нативно можно сделать? Или опять с помощью "кастылей" придется?
Вот, а если кто меня еще не понял, то для лисперов-гуманитариев, которые нам так складно поют про "единственный высокоуровневый язык программирования", советую почитать о Законе Дырявых Абстракций: http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html. Особенно советую обратить внимание на примеры с SQL и C++. Думаю, приведенный мною пример тоже можно было бы поставить рядом. Впрочем, так же, как и пример tailgunner о дырке в абстракции автоматического освобождения памяти и ее роли в реалтайм системах.
Там же, кстати, можно найти и рассуждения о том, почему нельзя ограничиться знанием одного лишь Лиспа, а начинать изучение всегда придется с ассемблера. Ну в крайнем случае, C.
Вот, проникшись религией Лиспа об уменьшении сущностей, совершенно нифига не понимаю, почему в CL для определения значений и функций используется совершенно разный синтаксис: в одном случае -- через set, в другом -- через defun? Накуа такая лишняя сучность? Чо эт за дискриминация на "код" и "данные", которые правоверные лисперы должны всячески порицать? Где хваленная обработка "кода аки данных"? Какой догмат запрещает использование вот такой штуки:
* (set 'a '(lambda (x y) (+ x y))
* (a 2 3)
?
И почему, если уж примем богопротивность сего на веру, то почему вот это:
* (set 'a '(lambda (x y) (+ x y))
* (defun add 'a)
* (add 1 2)
Выдает совершенно эзотерический NIL вместо логичного 3? Не говоря уж о кошерном исключении, если таковое богохульство недопустимо религией?
Кстати, у финнов написано, в секте FranzLisp функции и переменные -- это единая сучность в двух лицах. Получается, что FranzLisp -- более богоугодное наречие?
Мля, и эти люди еще собираются учить нас про программирование...
Это крик души. И одновременно плач по невинно загубленной бурной молодости ;-).
> Заодно оглашаю весь список имеющихся в коммон лиспе:
Спасибо. Извиняюсь за провокацию. Однако ж, это таки уже не чистый лисп, похоже? Я в том смысле, что это все барахло из классического лиспа не выводится, а является частью реализации, так ведь? Или можно позырить на реализацию сих абстракций на девственно чистом Лиспе?
Кроме того, так сходу не увидел в документации оценок сложности. Впрочем, я их нигде, кроме как в GOBO и не видел.
> до кучи упомяну, ч есть операции pop и push, т.е. список может хорош работать как стек.
А вот это точно никому, кроме декадентов не нужно.
Как так? Это спецификация коммон лиспа. Конешно, е неоднократно осквернили грязные взгляды подлых вендузятнегоф, но я уверен ч ей вполне можно ещ пользовацо.
> Или можно позырить на реализацию сих абстракций на девственно чистом Лиспе?
Я не понимаю ч ты хош. Если хош глядеть, как реализовано - зри в изходники того же cmucl или sbcl.
> А вот это точно никому, кроме декадентов не нужно.
> Полезно _представлять_, как делает это машина, да и то только в тех случаях, когда это действительно необходимо (непосредственная работа с железом, низкоуровневое программирование, агрессивная оптимизация), а не "думать как машина", тем более, в решении _проблемы_ это как раз мешает, бо нужно уметь абстрагироваться и использовать наиболее выразительные на этом этапе вещи.
Дыкть, так и делают. На первом курсе учат Паскаль, на втором -- ассемблер. А ближе к четвертому-пятому -- всякую экзотику типа Лиспа или (как у нас) -- Пролога и прочих GPSS. Другая беда, что многие студиозусы к этому моменту уже видят себя крутыми программерами, потому как уже устроились пристойными лабателями GUI в более-менее приличной конторе "Остап и программисты Ltd". Ну а кто виноват?
Кстати, сегодня на OSDN выступал один преподаватель из Львова, зашла речь о языках, которые преподаются в школе. Препод жаловался, что под Linux нет хороших сред для обучения программированию. Народ выпал на измену. Подошли после доклада, начали наперебой предлагать решения: Питон, Паскаль. Вспомнили Лого. Классный язык, я балдел в свое время. Ведь Лого -- это прямая подсадка незрелых детских умов на функциональщину. В общем, наше фсио. Так вот, выяснилось, что успешно внедрить Лого удалось только полякам которые стырили часть реализации у чехов. Если преподавать Лого нашим отечественным школярам, то тут же занимают четвертую позицию. А Вы говорите -- образование...
Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.
> Конешно, е неоднократно осквернили грязные взгляды подлых вендузятнегоф, но я уверен ч ей вполне можно ещ пользовацо.
Кстати, не подскажешь по быстрячку, где можно надыбать сабж под оффтопик? Бо искать влом.
> Если хош глядеть, как реализовано - зри в изходники того же cmucl или sbcl.
Вопрос в том, на каком языке написаны эти исходники в части массивов? На кошерном Лиспе или некошерном С?
> _Нормальные_ программисты должны взращиваться именно на таких учебниках, я бы еще добавил хороший курс дискретной математики, алгебры (конечно-порожденные полугруппы) и математической логики.
> ну прецтафь ч лисп - это такой паровой движк а ты - enterprise slave. Про остальное сам догодайся.
Как говорится, "два солдата из стройбата заменяют экскаватор". У нас тут недавно тестеров тока-тока перевели на автоматическое тестирование гуевины посредством соответствующих роботов. Аха. Тестеры роботов днем ваяют, а те ночью, пока тихо и спокойно -- тестят. И то было на три месяца споров на предмет "а нафига нам это?". И главный аргумент начальства был на тему: "Если мы научим девочек-тестеров писать роботов, то они возомнят себя крутыми программерами. И платить им придется, как программерам. И станет их дом -- полная чаша. И станут они жить не нашей жизнью".
> Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.
Можно, без проблем. Вот я и говорю, посмотри в сырцах как оно выражено или в учебниках. Оно несложно выражаецо, но спецификация лиспа требует чбы оно было готовое. Это типа функции ну например возведения в степень в любом наречии. Хоть е несложно сделать самому, но она почти везде есь готовая.
> оффтопик
непатрикоунодно. clisp работает и кое-каке из коммерческих есь возможнось скачать халявно для личного пользования. Некоторые с ограничениями.
> Вопрос в том, на каком языке написаны эти исходники в части массивов? На кошерном Лиспе или некошерном С?
В разных реализациях по разному. Могу предположить ч в clisp возможно на С а в cmucl и sbcl на лиспе.
>Вопрос в том, на каком языке написаны эти исходники в части массивов?
На кошерном Лиспе или некошерном С?
clisp на C написан, а sbcl на 99% процентов самина себе. Даже
где-то в юзнете были замеры объема кода на LISP vs. C. На Си там
написано минимальное ядро, зависимое от ОС и архитектуры. Здесь никуда
не денешься -- ОС торчит в мир сишной жопой. Ну там потоки и пр.
Массивы? Массивы оптимизируются хорошо. Как настоящие. Вот тут
кусочек маленький вырванный случайно из кода sbcl. Это кусок
кодогенератора для нативного x86-64. вот видишь там (inst ...) ?
Это ассемлер:
http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/compiler/x86-64/array.lisp?revisio
n=1.10&view=markup
А тут арифметика.
http://sbcl.cvs.sourceforge.net/sbcl/sbcl/src/compiler/x86-64/arith.lisp?revisio
n=1.19&view=markup
Еслиинтересно, то можешь походить по исходникам. Сишная часть лежит
в runtime.
> Дыкть, так и делают. На первом курсе учат Паскаль, на втором -- ассемблер. А ближе к четвертому-пятому -- всякую экзотику типа Лиспа или (как у нас) -- Пролога и прочих GPSS. Другая беда, что многие студиозусы к этому моменту уже видят себя крутыми программерами, потому как уже устроились пристойными лабателями GUI в более-менее приличной конторе "Остап и программисты Ltd". Ну а кто виноват?
Так я про то и вещаю, что так делать НЕ НАДО, бо калечатся юные умы особенностями ассемблера x86, после чего никакие другие архитектуры без ломки не воспринимаются. Слова "стековый процессор" или иная нестандартщина в лучшем случае вызывают реакцию: "гыы, а что, прикольна... но нафиг не надо".
Кнут, безусловно, рулит. Но все-таки имеет смысл разделить эти предметы во времени и по преподавателям, а не так как в книге - все в одну кучу. Это позволит оформить "вкусизмы" - предпочтения отдельных личностей к тем или иным аспектам - проще профориентироваться. Кто-то пойдет в писателей компьютерной графики, кто-то - БД, кто-то займется написанием компиляторов. А "неасилившие" станут прикладными программистами :)
> Асм x86 и Qbasic это была, есть и будет основа основ любого писишного программера. Без этого никуда, окромя дискуссий на лоре
Ага, и профессия шорника была есть и будет востребована людьми! Уважаемый, студентов-халтурщиков тут, кажется, не просили высказываться. У вас вообще кроме x86 никаких архитектур не существует. И не было. И до васика люди только счеты программировали.
> Скажу еще раз, чтобы не было недоразумений: безусловно, конечная цель любой науки - практика. Но она не должна быть единственной довлеющей силой, не должна _заменять_ эту самую науку. Иначе все станут ремесленниками, а не специалистами. Быть может и искусными, но не видящими решение дальше, чем того позволяют их инструменты и переданные учителем знания.
IMHO, computer science "не бывает" (С) ПНвС. Это раздел математики, и заниматься им должны математики (не даром ВМиК так называется, да?).
А программист - это инженерная специальность. И как среднему инженеру-механика сопромат нужнее, чем физика твердого тела, так и программисту хорошее владение инструментарием (языковыми средствами, ОС, "классическими" алгоритмами, "паттернами") нужно больше, чем конечно-порожденные полугруппы.
Опять же, не слудует забывать про "пирамидальное" строение здания науки и техники - чтобы довести до практического применения одну новую идею, нужно затратить тысячи часов на решение технологических и внедренческих проблем. Поэтому то, что "быдлокодеров" больше, чем "программистов" - это логично и правильно.
Быдлокодер, работающий рядом с настоящими программистами,
Во-первых VB никто не отменял, во-вторых таки да оно помогает ПРАВИЛЬНО вникнуть во вс остальное. Примеры неправильного вникания мы можем в изобилии наблюдать в этом топике.
> А программист - это инженерная специальность. И как среднему инженеру-механика сопромат нужнее, чем физика твердого тела, так и программисту хорошее владение инструментарием (языковыми средствами, ОС, "классическими" алгоритмами, "паттернами") нужно больше, чем конечно-порожденные полугруппы.
Возможно Вы и правы. Однако, опираясь на Вашу аналогию, скажу, что даже инженер должен _представлять_ себе, например, откуда берутся комплексные числа, а иначе - это кошмар.
К слову: вчера был в Доме технической книги, что на Ленинском (Москва). Лежит на полке книга, рядом с солидными учебниками - типичный представитель паранауки, кою с таким остервенением создают разные к.т.н. О том, дескать, что вся квантовая механика создана, чтобы запудрить мозги "настоящим физикам" и по заказу кайзера Вильгельма (не шучу, так написано в предисловии)
> Если не секрет, какую пользу ты вынес из топика?
Пару ссылок - на "жизненную историю" (на RSDN), на статьи по Type Inference в Питон. Совет _прорешать_ SICP. И смутное предположение, что изучение Lisp - это как изучение иностранного языка: хорошая тренировка для мозгов, новый взгляд на родной язык, но... все языки примерно равны по выразительной мощности (что-то лучше выразить на одном, что-то - на другом). Не обязательно начинать _думать_ на иностранном языке.
VB - никто, то ты помянул Qbasic! И вот он - абсолютно бесполезен сегодня. Об этом и речь - конкретные системы быстро устаревают, знания более высокого порядка - нет.
> таки да оно помогает ПРАВИЛЬНО вникнуть во вс остальное
Во _ВС_ ? Вс == VB? Или Qbasic помогает вникнуть в Lisp? Или rule-based системы? В Си++ и его generic programming?
Не трудись отвечать мне. Себе ответь.
Прежде чем обвинишь меня в маразме и нарциссизме - я 16 лет работаю программистом и много всякого повидал/использовал.
> Возможно Вы и правы. Однако, опираясь на Вашу аналогию, скажу, что даже инженер должен _представлять_ себе, например, откуда берутся комплексные числа, а иначе - это кошмар.
Ну нам в МГТУ ч-то такое читали, да. Хотя я и учился на кафедре, связанной скорее с электроникой и АСУ - была у нас и теоретико-множественная алгебра (забытая напрочь), и логика (с Прологом, хотя и плоховато прочитанная); а на "чиста программистских" этого всего было больше, и было там и "построение компиляторов", и прочая и прочая.
Так что есть это все, просто в наше тяжелое время студенты живут по принципу "сдал-забыл", и вынуждены совмещать учебу с работой. А программы расчитаны на "9-ти часовой учебный день" (С) какой-то там официальный документ.
> К слову: вчера был в Доме технической книги, что на Ленинском (Москва). Лежит на полке книга, рядом с солидными учебниками - типичный представитель паранауки, кою с таким остервенением создают разные к.т.н. О том, дескать, что вся квантовая механика создана, чтобы запудрить мозги "настоящим физикам" и по заказу кайзера Вильгельма (не шучу, так написано в предисловии)
Ну запретить издавать паранаучный бред было бы недемократично, а ожидать, что товаровед книжного магазина способен отличить торсионное поле от суперструны - нереалистично ;)
> все языки примерно равны по выразительной мощности
весьма сранное на мой взгляд утверждение, сродни тому что язык жестов и устная речь равны по выразительности только потому что и тем и другим можно одинаково успешно послать йухан. Вот тут пипл утверждает ч питон - это такой меееедленный но очень сильно недоделатый лисп: http://nostoc.stanford.edu/Docs/whylisp.html
цытато:
> Python, which is more-or-less lisp w/o the parens, is missing several critical features to do what we do in BioBike, esp. true macros, which enable you to manipulate expressions, create sub langauages, and engage in applicative programming. Someday the Python crowd will realize that uniform syntax is a good thing, and will re-adopt parens (or something like them), and then Python will just be Lisp again, and much the better for it!
Ужель ты _действительно_ думаеш, ч если что-то есть дополнительное, из этово нельзя извлехчь дополнительную пользу?
> VB - никто, то ты помянул Qbasic! И вот он - абсолютно бесполезен сегодня. Об этом и речь - конкретные системы быстро устаревают, знания более высокого порядка - нет.
QB от VB отличается только гуем. Что вам там наплл Гейтс никого не интересует. VB это суть QB под винды и с гум и с классами и точка. А всяких vbrussian.com, которые пытаюстя на VB писать как на Си надо убивать было при рождении - ТАК поганить ТАКУЮ гениальную вещь как Бейсик это форменное извращение.
> родни тому что язык жестов и устная речь равны по выразительности
> Вот тут пипл утверждает ч питон - это такой меееедленный но очень сильно недоделатый лисп
Вот чтобы на такое не отвечать, я и попрощался. Тебе отвечу :) - насчет языков ты передергиваешь (и сам это знаешь), насчет статьи - можно найти таких статей с обратным знаком. И примеров миграций людей с Lisp на Python (с Python на Lisp - не встречал, но и не искал особо). Так что это вс доказывает только то, что мнения есть разные (прикольная цитата со ссылки: "those who don't know Chinese think it's hard too, but the Chinese don't!").
Я бы с удовольствием послушал людей, которые имеют значительны опыт и в Лиспе, и в Питоне. Но как их отличишь от зашоренных ветеранов/неофитов Лиспа?
> кобол видал/юзал?
Кобол - нет. На PL/I - работал.
> Когдато мейнстрим был...
И что? Никогда не был хорошим языком (разработан слишком рано), устарел, но вполне жив за счет огромной кодовой базы.
[и не надо говорить, что Лисп из тех же времен: отличия Lisp 1.5 от CommonLisp - как разница между первой версией Си (1973) и Си++98]
Кстати, если к тебе прилипнет lambda-gtk, то как-то давно в их рассылке было сообщение, что кто-то сделал обвязку для CLOS. Нашел. Лежит (гы-гы) на народе: http://borigen.narod.ru/gtk-on-clos/ То есть получаем что-то аналогичное gtkmm все для того же CL. Объектно-ориентированое.
Работает или нет -- не знаю. Не пробовал. Но похоже на то, что обвязка генерируется автоматически, что весьма интересно.
я бы почитал для приколу если бы закинули пару ссыл.
> мнения есть разные
дык мя именно и интересует, почему склалось такое мнение. Посему и спрашиваю. Если бы мя интнресовал сам лисп/питон/... я бы книшку читал про это а не с жывым пиплом общялся бы.
> значительны опыт
дык опыт не главное. Например, умя нету опыта работы с дотнетиненадом, и не будет никогда. Но я совершенно точно и обективно знаю ч он кака, потому что затратил немало времени только на то, чтобы понять, следует с им связывацо или нет.
> Никогда не был хорошим языком
но зато был майнстримом, котороно ты пытаешся держацо.
> и не надо говорить, что Лисп из тех же времен
дык я и не говорю. Это просто на тему размышлений о превратностях судеб, в том числе и судеб наречий.
> вполне жив за счет огромной кодовой базы
Скорее, ево так медленно хоронют. Ведь ни средств разработки не видать, в отличие от десятка как минимум лиспмашин, ни коммунити, хотябы малого. Никакого влияния на современные наречия. А так, да, не закопали а продолжают обонять неописуемый аромат из-за того ч дофига слишком закапывать. Еслибы делфи/висуалвасик были пораспространннее, вполне могли бы разделить ево судьбу. Вот дотнетиненадо наверное сможет.
> я бы почитал для приколу если бы закинули пару ссыл.
Пары нет (ну не интересует меня это), но по ссылкам из топика набрел на это: http://www.prescod.net/python/IsPythonLisp.html оттуда есть линк на интересную статью Норвига, в которой он обвиняет Питон в тормознутости, при этом не упоминая psyco.
>> мнения есть разные
>дык мя именно и интересует, почему склалось такое мнение.
Я и сам не знаю. В конкретном случае BioBike - там просто рекламный треск. Думаю, их основная претензия к Питону - то, что он не Лисп.
>> Никогда не был хорошим языком
> но зато был майнстримом, котороно ты пытаешся держацо.
8-O Я не стараюсь держаться мэйнстрима (это LOR, Linux.org.ru, да?), я стараюсь держаться технологий, которые я считаю "правильными". И вот если есть выбор из _таких_ технологий - я выбираю ту, которая мэйнстрим.
> умя нету опыта работы с дотнетиненадом, и не будет никогда.
Не зарекайся
> Но я совершенно точно и обективно знаю ч он кака
8-O впрочем, уже говорили об этом
> Ведь ни средств разработки не видать, в отличие от десятка как минимум лиспмашин, ни коммунити, хотябы малого.
Ты просто не в теме. Я тоже не особо, но IDE на основе Eclipse (это значит, довольно свежая) - есть, новые диалекты - создаются (NetCOBOL, ObjectCOBOL), а коммюнити просто keeps a low profile.
Ну для CLOS там стоит 2006 год. А для lambda-gtk там все автоматически генерится. файл gtk.api сгенерен прямо из хидеров сишных. А так как GTK2.x у нас бинарно совместимы, то проблем нет. Должен же когда-то проект портирования иметь свой конец. Невозможно же постоянно решать такую задачу! У нее есть четкое логическое завершение -- реализация порта GTK. Порт работает? Работает! Другой вопрос, что нет такого Q&A, которого бы хотелось, чтобы быть уверенным, что проект не подохнет или просто не исчезнет к тому времени, когда появится, например, GTK3. Но тут никто дать гарантии не может. И для cells-gtk, и для clg тоже. lambda-gtk хорош тем, что это просто тупой 1:1 биндинг (atk, pango, glib, gtk) без наворотов. И он работает.
ково же они рекламируют? какой им смысел? У них же на паге есь ссыло на в какой-то мере противоположную (как мне показалось при беглом досмотре и довольно ИМХО обективное http://www.norvig.com/python-lisp.html)
> Я не стараюсь держаться мэйнстрима
вроде ты единственный кто в этом топике начал ссылацо на майнстрим?
> я стараюсь держаться технологий, которые я считаю "правильными"
все стараюцо. Только критерий правильности разный.
> И вот если есть выбор из _таких_ технологий - я выбираю ту, которая мэйнстрим.
Я вообще скверно представляю себе, чтакое майнстрим. Но есть впечатление, что достаточно "правильная" технология сейчас майнстримом неприемлема.
Кстати, а зачем тебе вообще майнстрим?
> Не зарекайся
рабовладение запрещено в большинстве стран мира и осуждаецо ООН.
> Ты просто не в теме.
Возможно. Как я говорил по большей части официально моя работа связата с сями. Но я в огромных количествах просматриваю резюмы. Там не проблема найти чела знающего лисп, даже питон пару раз попадался и руби единова. А вот про кобол даже никаких упоминаний.
Вообще, если взглянуть на проблему биндингов шире, то видно, что очень много сил распыляется впустую. Это даже не только проблема Лиспа, но и комьюнити. Человеки -- это тоже ресурс. При растущем числе проектов, число разработчиков растет не так быстро.
Считаю, что все биндинги в Лиспе должны генерироваться автоматически. Я не говорю о высокоуровневых реализациях типа cells-gtk. Я говорю о простых 1:1. Должен инспектирваться хидер, генерироваться независимый от языка файл, а потом преобразовываться в биндинг. Примерно так сделано в lambda-gtk. gtk.api сгененирован из хидеров программой ffigen (http://www.ccs.neu.edu/home/lth/ffigen/), а при запуске lambda-gtk он этот gtk.api в CL переводит. Вот так примерно или даже лучше должно быть в принципе. Тогда и нововведения отслеживать не надо будет.
они называют конкретные причины, по которым. И я не вижу чем можно ответить на их аргументы. Ну, кроме того, что сказать "да тамо реклама одна, нефих читать", конешно.
> Есть не менее эффективные методы принуждения 8)
пускай попробуют
> Или, например, предложат тебе писать компилятор CommonLisp для .NET - откажешься?
Может и нет. Только вот работать на дотнетиненаде и генерить для нево код - существенно разное вещи вс-таки.
> Извини за нескромный вопрос - тебе лет сколько?
значит других аргументов нету?
> Как раз сейчас ситуация выправляется, спасибо FOSS (Линуксу в первую очередь)
меняецо, но не выправляецо. Вернее, она будет выправляцо, но очень медленно. Нынешний всплеск интеререса к лиспу - одна маненькая ступенька на пути.
> А ты где работаешь?
А без разницы.
> Хочешь сказать, что людей, знающих Лисп - больше, чем знающих Питон? Хм...
По количеству возможно и нет. Русский матерный по россии знают больше народу, чем английский, но в резюмах первый встречяецо намного реже второго.
> Считаю, что все биндинги в Лиспе должны генерироваться автоматически
Не очень удачная идея, хотя положительные стороны у е есь. Главный ИМХО недостаток - первоначально "чужеродный" принцип построения тулзов, из-за этого код, построенный с применением, будет каряв, а работать - сложно.
> clisp на C написан, а sbcl на 99% процентов самина себе.
Да я уже понял. Хотя с хэшами для BDD проблема остается, однако это уже, скорее DSP, конечно, если не ввести BDD в базу языка (то бишь, "кастылем"). Думаю, для ее решения в любом языке придется писать свои хэш-множества, но для их хорошей реализации таки нужны структуры со временем выборки по индексу O(1). И вот ведь беда: если простота С-машины позволяет мне убедиться в том, что массивы в С таким свойством обладают, то для Лисп мне это кажется магией, потому как при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк. Мне вообще вот интересно, есть ли хоть какие-то (полу)формальные методы оценик эффективности Лисп-программ? Впрочем, так глубоко мне не надо. Я готов просто поверить на слово человеку, знающему Лисп, если он просто скажет мне, что массивы таки в самом деле обеспечивают эффективность доступа по индексу O(1). В доке я этого не нашел. У финнов тоже. Может, плохо искал...
Кстати, таки асилил первый том финнов. Я понял, почему у меня не получилось это в студенчестве: там 75% нужно читать по диагонали. Или вообще не читать. Аха. Если так делать, то освоить Лисп становится не страшнее, чем ту же Жабу. Более того, скажу по большому секрету лисперам-гуманитариям: если бы они меньше философствовали и больше писали по делу, то книжки типа "Как освоить Лисп за 24 часа" не были бы сейчас такой редкостью. Можно было бы этот совет адресовать непосредственно финнам, если бы не sicp, который тут усиленно рекомендовали _прорешать_. Скажу сразу: основной текст этой книги тоже можно не читать. Можно сразу начать с задачек. Больше половины решаются в уме. Результаты получаются изумительные: 124 страницы из 600 только лишь за один вечер. Не знаю, кого там и чему учит эта книга, но я бы скорее отнес рекомендовал ее для детского сада с углубленным изучением программирования. Ну, может последние главы -- для начальных классов средней школы.
Но это все так, лирика. Главный практический вывод: Лисп, это, оказывается, такой ассемблер. Аха. Совсем, как Брейнфак. Только Лисп -- это еще и макроассемблер. Потому, видимо, высокоуровневый. Правда, есть еще более высокоуровневый язык -- машинный код. Аха. Имеет всего две базовые конструкции: 0 и 1. Базовый стандарт задан еще в лохматом году фон-Нейманом. На сегодняшний день имеет десятки распространенных реализаций, самой распространенной из которых является x86. И единственный язык, в котором есть все и без кастылей, как, например, в том же Лиспе. Который, кстати, тоже своего рода DSL.
Ну ладно, это я, может быть, и утрировал. На самом деле, я теперь знаю, почему Лисп не получил распространения. Потому что его повсеместно вытеснил другой высокоуровневый макроассемблер. Если кто еще не догадался, то это я о C. Тоже имеет только два базовых типа: числа и указатели. Тоже имеет мощные средства функционального программирования и макрорасширения. В частности, и объектно-ориентированные. Правда, в отличие от Лиспа, у него меньше "батареек из коробки". В частности, поставляется без намертво вшитого сборщика мусора. С другой стороны, из-за мощности С на нем реализована уйма DSL, в том числе и C# и Jaba и Python. И даже большинство современных реализаций Lisp. А Эйфель, так тот вообще является чистым макрорасширением С, ибо после всех макроподстановок получается программа на чистом С, которая потом и интерпретируется системой.
Ну а если без стеба, то если Лисп силен своими макрорасширениями DSL, которые каждый лиспер якобы пишет по пять штук на неделю, то такой вопрос: почему нет ни одной приличной реализации хотя бы той же JVM или Python-машины на Лиспе? Почему нет ни одного приличного транслятора с Java или Python в тот же самый Лисп-код? Даже Эйфель, для которого генерация в высокоуровневые ассемблеры -- это фирменная фишка (СмартЭйфель генерит и С и JVM-код, причем оба переносимы минимум под три платформы), не имеет генератора для Лисп. Может, потому, что и нафик не нужно?
Впрочем, идейка реализации Эйфеля на Лиспе с промежуточной генерацией в Лисп-код мне кажется весьма привлекательной :-). Может быть, на пенсии попробую заняться. :-))
> У меня нет ни седой бороды (вообще никакой), ни крутого диплома.
Ну и нефих тогда левые сущности. Я не так давно на другом форуме типа видел который типо в крутой юниксовой конторе работал, на motif что кропал, а про layout manager вообще не вкурсе был, ч такое бывает :D
Правда, меня таки попутал эпиграф, датированный 1980 годом (потому я и написал осторожно -- "кажется"). На самом деле, статейка весьма свежая, датирована 2000 годом. То есть, даже если и померла, то трупик еще явно не остыл.
Впрочем, Дийкстра таки поставил это утверждение под вопрос, и явно с ним спорит. Однако, общая тенденция все же хорошо проглядывается. Да и Дийкстры уже нет...
> Хотя с хэшами для BDD проблема остается, однако это уже, скорее DSP, конечно, если не ввести BDD в базу языка (то бишь, "кастылем").
А можно узнать, ч за трабла с хешами? И зачем свои писать, если готовое есь?
> при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк
ч же там такого страшново? :D
> Я готов просто поверить на слово человеку, знающему Лисп, если он просто скажет мне, что массивы таки в самом деле обеспечивают эффективность доступа по индексу O(1).
Можно проверить, или спросить на канале #lisp в irc.freenode.net. Тестовая прога же с полстранички будет. Если несправишся, давай я накрапаю.
> почему нет ни одной приличной реализации хотя бы той же JVM или Python-машины на Лиспе? Почему нет ни одного приличного транслятора с Java или Python в тот же самый Лисп-код?
А зачем если лисп-код в десятки-сотни раз проще сделать чем жавовский или питоний?
>> У меня нет ни седой бороды (вообще никакой), ни крутого диплома.
> Ну и нефих тогда левые сущности.
Я никогда и не говорил, что у меня седая борода и крутой диплом. Только о том, что 16 лет работаю - ну так это правда, а научился я чему полезному или нет - суди сам, если можешь.
ну и вот. Щитаю что в обсуждениях неуместны и не должны затрагиваться вопросы, касающиеся опыта работы, полученново образования, размера зряплаты, етц, тем более принципиально непроверяемы.
> А можно узнать, ч за трабла с хешами? И зачем свои писать, если готовое есь?
Там хрень в том, что там три ключа для входа в таблицу. Два из них представляют уникальные идентификаторы структур (как правило, числовое представление ссылок на структуры в памяти) и код операции. В реализациях на С три этих числа хэшируют (как правило, двукратный сдвиг-сложение), после чего полученное число используют как ключ для входа в хэш-таблицу.
У финнов сказано, что ключом в хэш-массиве является ссылка на структуру в памяти, но здесь этого недостаточно. Кстати, можно ли в Лиспе получить числовое значение указателя на структуру? Тогда бы можно было, по аналогии, захэшировать три значения в одно и воспользоваться ассоциативным массивом. Но это только при условии, то ассоциативный массив имеет то же время доступа -- O(1). Ну или, если не имеет, то можно уже полностью развернуть структуру на обычных массивах но при том же условии. Правда, фиговость таких решений в том, что они очень чувствительны к настройкам: размеру ядра хэш-массива и виду хэш-функции. В своих наработках приходилось тюнить, были дажи мысли по автотюнингу. С контейнерами "из коробки" таких проблем, конечно же, нет. Но и уверенности в том, что там все сделано оптимально, тоже нет.
Кстати, сейчас посетила мысль, что задачу можно было бы решить за счет иерархического хэш-массива. То есть, типа массива массивов массивов. Уже и не вспомню, почему тогда этим не воспользовались. Кажется, потому что все-равно нужна таблица, а не массив.
> ч же там такого страшново?
Количество вспомогательных сучностей. И объемы. Не знаю, может для кого тыща строк на Лиспе -- это "изящное и простое решение". К тому же, поговаривают, что на Лиспе, как пишется, так и читается. Можно объяснить вкратце, каким волшебным образом обеспечивается требуемое условие -- быстрый доступ по индексу? Можно предположить, что все это многообразие кода сворачивается загадошно сворачивается ну очень умным оптимизатором? И мне предлагают довериться этой железяке? Или там какое-то особое представление используется?
Ну вот, чтобы хоть как-то объяснить, чего мне нужно, то как массивы представляются внутри Лисп-машины? В виде линейных массивов? Тогда как в чистом Лисп-коде эффективно преодолевается разрыв между базовым представлением в виде списков и представлением в виде линейного массива? Или там над списками какие-то индексы надстроены?
> Можно проверить, или спросить на канале #lisp в irc.freenode.net.
Увы мне, совершенно не умею пользоваться irc.
> Тестовая прога же с полстранички будет. Если несправишся, давай я накрапаю.
А что тестировать? Что при линейном росте размера время доступа к произвольному элементу не меняется? А где гарантия, что это не обусловлено фазами луны?
Впрочем, на прогу посмотреть было бы интересно. Сам ниасилю, бо там нужна обработка времени вычисления, а я такое в Лиспе еще не освоил. Ну и вообще, в плане обучения было бы интересно. Кстати, а в Лиспе есть приличный профайлер "из коробки"?
> А зачем если лисп-код в десятки-сотни раз проще сделать чем жавовский или питоний?
Во-первых, для новичков. Которые могли бы поэкспериментировать и убедиться, что лисп-код и в самом деле в десятки-сотни раз проще, чем жавовский или питоний.
А во-вторых, а зачем в таком случае вообще писать на лиспе DSL-расширения? Если на самом Лиспе все в десятки-сотни раз проще сделать?
> не должны затрагиваться вопросы, касающиеся опыта работы
Не согласен. Если человек высказывает резкие и необычные суждения, наличие у него большого опыта - это еще одно основание вс же задуматься над его словами. Если же есть обоснованное подозрение, что о наличии опыта он лгал (часто это заметно) - это основание в будущем игнорировать его слова, не задумываясь. Кроме того, иногда речь идет о том, что может видеть _только_ человек с опытом.
Лично мне интересно послушать более опытных людей. У них почти всегда другой взгляд на вещи, и/или они уже дошли до того, до чего мне еще идти и идти.
> полученново образования
Не согласен. Позволяет лучше понять собеседника.
> размера зряплаты
Согласен. Об этом и не спрашиваю никогда.
В любом случае, ты можешь не отвечать (ты и не ответил).
А можно узнать, почему именно хэши? А не деревья? ИМХО, AVL-дерево или RB-дерево вполне подошли бы. Время доступа там тоже O(logN), IIRC, зато поведение в худшем случае - гораздо лучше.
> Если человек высказывает резкие и необычные суждения, наличие у него большого опыта
Смысел то каков в опыте, самом по себе? Практически вся теория программирования была разработана аж в 50х-70х годах прошлого века ещ, с математической точностью. Что может дать опыт дополнительно? А вот к аргументам я бы прислушался. Иначе получается "давление авторитетом". По жизни замечал, люди, склонные к таковому давлению авторитетом - недалкие и безграмотные, больше всево боящиеся что их безграмотность выявится, отчего и неспособные к нормальному диалогу.
> Если же есть обоснованное подозрение
А зачем терзать себя сомнениями? Проверить вс равно не получицо.
>> полученново образования
> Не согласен. Позволяет лучше понять собеседника.
если собеседнику нечего сказать, кроме как похвастацо крутым дипломом, на йух таково собеседника.
> В любом случае, ты можешь не отвечать (ты и не ответил).
И не собираюсь впредь. Потому что, опять таки, и нормальное обсуждение теряецо, и некоторое неадекватное восприятие слов может быть, и вс равно проверить никак нельзя. А для обсуждения высказанных мнений и аргументов в защиту своей точки зрения - более чем достаточно.
> А можно узнать, почему именно хэши? А не деревья? ИМХО, AVL-дерево или RB-дерево вполне подошли бы.
Из деревьев знаю только двоичные и B-деревья. Об AVL и RB просто в первый раз слышу. Где можно почитать?
> Время доступа там тоже O(logN), IIRC, зато поведение в худшем случае - гораздо лучше.
Там основной алгоритм имеет сложность где-то O(n^2). Если еще умножить это на logN, то получится не очень хорошо. Кроме того, в авторской реализации тоже были хэши. Да и реализуются хэши проще, как мне кажется.
> Это же дерево, нет?
Ну, если массив массивов считать деревом, тогда да. Но это довольно таки специфическое дерево, не так ли?
> вся теория программирования была разработана аж в 50х-70х годах прошлого века ещ, с математической точностью
ROTFL Что, вот прям-таки ВСЯ? Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(
> Что может дать опыт дополнительно
Ну, это кому как. Обычно опыт дает знания. Я, например, 10 лет назад был гораздо худшим программистом, меньше знающим, более самоуверенным. А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?
>>> полученново образования
>> Не согласен. Позволяет лучше понять собеседника.
>если собеседнику нечего сказать, кроме как похвастацо крутым дипломом
Кажеться, ты путаешь диплом и образование.
>> Если же есть обоснованное подозрение
> А зачем терзать себя сомнениями? Проверить вс равно не получицо.
Терзать - конечно, не надо. Проверять - тоже, мы же не суд. Если человек говорит, (например) что он читал "Джонни-Мнемоник", и тут же называет его главную героиню "Джейн", то с ним вс ясно. Или говорит, что он давно и с интересом следит за FOSS, и говорит, что GNU Manifesto написал Эрик Реймонд.
>Из деревьев знаю только двоичные и B-деревья. Об AVL и RB просто в первый раз слышу. Где можно почитать?
Есть еще деревья со штрафами, splay tree, interval tree. А! вот еще Radix Tree есть. Кстати, последнее применено в ядре Linux в подсистеме VM для поиска страниц.
> об AVL и RB просто в первый раз слышу. Где можно почитать?
AVL-деревья обсуждаются у Кнута (в 3-м томе, неподалеку от B-деревьев), это "почти сбалансированные" двоичные деревья. RB-деревья (red-black trees) - IIRC, то же, но "почти балансируются" по-другому. Почитать - думаю, у Седжвика есть. Реализация RB-деревьев есть в GNU C++ STL.
Если MDD - это Mukti-Dimensional Data, для работы с ними есть какие-то свои деревья (R-деревья, кажется).
> Если еще умножить это на logN, то получится не очень хорошо
Ненамного хуже (там log по основанию 2, а то и больше). Кроме того, у хэшей (почти всех) плохой худший случай (хуже log(N)).
> Ну, если массив массивов считать деревом, тогда да.
Там говорилось о каком-то "иерархическом хэш-массиве" ;)
вся, абсолютно. А ты припоминаеш более свежие сурьзные наработки в этой области, кроме всяково шаманства типо ХР?
> Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(
Надо было спросить.
> Ну, это кому как. Обычно опыт дает знания. Я, например, 10 лет назад был гораздо худшим программистом, меньше знающим, более самоуверенным. А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?
Знания дат (само)обучение. Если нету - и через 40 годов будеш писать код навроде boolean lol (boolean x) {if (x == true) return false; else if (x == false) return true; else return !false && !true; }
>> если собеседнику нечего сказать, кроме как похвастацо крутым дипломом
> Кажеться, ты путаешь диплом и образование.
если чел рассуждает о дипломе вместо предмета обсуждения - у нево нету образования. А если образование есть - диплом упоминает в резюмах а не на форуме.
> Терзать - конечно, не надо. Проверять - тоже, мы же не суд. Если человек говорит, (например) что он читал "Джонни-Мнемоник", и тут же называет его главную героиню "Джейн", то с ним вс ясно. Или говорит, что он давно и с интересом следит за FOSS, и говорит, что GNU Manifesto написал Эрик Реймонд.
Ну фих ево знает, мож очепяталсо или позабыл мелкий по ево мнению факт. А по ходу обсуждения зачастую бывает заметно, ч и главную героиню правильно назвал, и манифест наизусть зачитывает, а потом вдрух выдаст, ч функциональные наречия отличяюцо от всех других тем, что в них нету понятий из реальново мира например :D
>Не очень удачная идея, хотя положительные стороны у е есь. Главный ИМХО недостаток - первоначально "чужеродный" принцип построения тулзов, из-за этого код, построенный с применением, будет каряв, а работать - сложно.
Тулзов преобразования хидеров? Ну этот недостаток можно исправить, написав его на самом CL. :) Нет, серьезно. Только его надо научить не только функции из хидеров хватать, но и макросы сишные развертывать, которые в хидерах тоже встречаются. А некоторые и m4 засовывают (извращенцы). Если таким образом получится быстро создавать биндинги к LISP, то остальное уже -- вопрос техники. Вот CLOS-обвертка вокруг lambda-gtk тоже сгенерирована автоматически уже (я сам не смотрел, но так пишет автор), а это уже повод хвастаться перед другими средствами! :) Выгода в простых биндингах -- это то, что переучиваться не надо будет. Занешь, как программировать на GTK -- делаешь также и тут.
Если же ты имеешь в виду то, что само обращение к C -- это чужеродное, то и тут есть ортодоксальные подходы к графике: (i) LTK -- обмен через сокет строками с wish (Tk), (ii) GTK-сервер (http://www.gtk-server.org/index.html), (iii) CLIM/McCLIM и другие, которые используют CLX (соответственно, получаем на выходе чистый X-протокол без биндингов к xlib) ну и т. д. И никаких *FFI. :)
Сообщение удалено tailgunner по причине '3.2 Неверная кодировка'
Ответ на: Re: Фраза о Лиспе... от bugmaker 09.10.2006 2:22:04
Re: Фраза о Лиспе...
>> ROTFL Что, вот прям-таки ВСЯ?
>вся, абсолютно. А ты припоминаеш более свежие сурьзные наработки в этой области
Не слежу за этим. Я далек от науки - я инженер.
>> Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(
>Надо было спросить.
Мне, пожалуйста, ссылки на выполненные в 50-70-х годах работы, в которых предлагались осуществимые на практике методы доказательства корректности параллельных программ.
> А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?
Ты не ответил на вопрос, спрятавшись за банальностями.
> мож очепяталсо или позабыл мелкий по ево мнению факт.
Ну да, "Джейн" вместо "Молли", хорошая такая опечатка. И имя главной героини - это мелкий факт, конечно. А на самом деле он не читал "Джонни-Мнемоник" - он смотрел одноименный фильм.
> по ходу обсуждения зачастую бывает заметно, ч и главную героиню правильно назвал, и манифест наизусть зачитывает, а потом вдрух выдаст, ч функциональные наречия отличяюцо от всех других тем, что в них нету понятий из реальново мира например
Это значит, что он разбирается в творчестве Гибсона и истории FOSS, но не разбирается в функциональных языках.
>вся, абсолютно. А ты припоминаеш более свежие сурьзные наработки в этой области
Не слежу за этим. Я далек от науки - я инженер.
>> Если это кто-то и сделал, то нам, быдлокодерам, не сообщили, и мы мучаемся 8(
>Надо было спросить.
Мне, пожалуйста, ссылки на выполненные в 50-70-х годах работы, в которых предлагались осуществимые на практике методы доказательства корректности параллельных программ.
>> А ты? Не 10, ну так 5 лет, 3 года назад - неужели ты не изменился с тех пор?
> Знания дат (само)обучение.
Ты не ответил на вопрос, спрятавшись за банальностями.
> мож очепяталсо или позабыл мелкий по ево мнению факт.
Ну да, "Джейн" вместо "Молли", хорошая такая опечатка. И имя главной героини - это мелкий факт, конечно. А на самом деле он не читал "Джонни-Мнемоник" - он смотрел одноименный фильм.
> по ходу обсуждения зачастую бывает заметно, ч и главную героиню правильно назвал, и манифест наизусть зачитывает, а потом вдрух выдаст, ч функциональные наречия отличяюцо от всех других тем, что в них нету понятий из реальново мира например
Это значит, что он разбирается в творчестве Гибсона и истории FOSS, но не разбирается в функциональных языках. Соответственно, его мнение о функциональщине - не интересно. Об остальном - вполне.
дело не в функциях и макросах, а ином представлении. Например,
народить диалог в clg:
(dialog (make-instance 'dialog
:title "йух" :default-width 200
:child box
:button (list "gtk-ok" #'(lambda (x) (go-to-south arg)) :object t)
:button (list "gtk-cancel" #'widget-destroy :object t)
:signal (list 'destroy #'(lambda () (setq dialog nil)))
:show-children t)))
представь, скоко функций будет вместо если сохранить гткшное
представление диалога?
> Выгода в простых биндингах -- это то, что переучиваться не надо
> будет. Занешь, как программировать на GTK -- делаешь также и тут.
сомнительная выгода. Преимущества лиспа не используюцо,
а недостатки гтк наследуюцо. Выучить за раз можно, а с корявостями
пожизненно парица придцо.
> Если же ты имеешь в виду то, что само обращение к C
> -- это чужеродное
не само обращение, а сохранение методов работы и структур
представления данных при переходе к языку, где они другие совсем.
боюсь, веб-серваки тех годов подзаржавели, хреново совсем работают :(
> Ты не ответил на вопрос, спрятавшись за банальностями.
хм, я бы сказал что менялся неравномерно. Несколько лет практически оставался одинаковым, а временами приобретал свои взгляды довольно быстро. Так что время влияло неоднозначно.
> Ну да, "Джейн" вместо "Молли", хорошая такая опечатка. И имя главной героини - это мелкий факт, конечно. А на самом деле он не читал "Джонни-Мнемоник" - он смотрел одноименный фильм.
Мож и так, бывает. Однако на основании одново-двух подобных фактов рано делать выводы ИМХО.
> Это значит, что он разбирается в творчестве Гибсона и истории FOSS, но не разбирается в функциональных языках. Соответственно, его мнение о функциональщине - не интересно. Об остальном - вполне.
А для меня это прежде всево означает что ему извесны многие факты, но он не может ими оперировать, в частности, делать логически обоснованные заключения или корректно определять область свой компетентности.
>боюсь, веб-серваки тех годов подзаржавели, хреново совсем работают :(
То есть - не можешь. Потому что эта задача не была решена (и не решена до сих пор). В 50-70-х годах было разработано множество классических алгоритмов и структур данных, _с математической точностью_, конечно. Но это такая малая часть "теории программирования", что просто смешно. А XP - это один из современных экспериментов, которые опираются на теорию программирования - только не математическую ее часть, а социально-психологическую.
> Однако на основании одново-двух подобных фактов рано делать выводы ИМХО
А мы не суд - в тюрьму не сажаем. Просто понижаем уровень доверия. Заслужит - повысим.
>представь, скоко функций будет вместо если сохранить гткшное представление диалога?
Ну так это уже совсем другой уровень! Это более высокоуровневая и заумная обертка, которую, увы, надо сопровождать, так как в случае изменения API придется чинить инструмент. Что несложно, так как API кардинально нигде не меняется.
Я же говорю только о биндингах типа 1:1, чтобы можно было работать уже. С таким же успехом может и clg умереть когда-то. Если говорить о долгожителях, то тут только CLIM/McCLIM приходит на ум. Даже стандарт есть, изложенный на бумаге (Common Lisp Interface Manager II specification), которого стараются придерживаться разные вендоры CL. Скоро в MCCLIM должен появится GTK/Cairo-бэкенд. Обещают, что в версии 0.9.3 уже что-то будет. А сейчас там есть PostScript, OpenGL, CLX и beagle (в первый раз слышу. по-моему, это что-то у эппл такое).
И разница в том, что CLIM идет сверху. От более общего к частностям, а clg (возможно) построен, отталкиваясь от GTK. Но в принципе все равны перед судом разработчика. Главное -- это чтобы лицензия была открытая :) Как говорил Джоэль Спольски: "В серьезной разработке пользуйтесь только тем инстументом, который можно починить". Поэтому даже lambda-gtk несложно будет починить, если очень потребуется. :)
> Но это такая малая часть "теории программирования"
благодаря этой малой чясти вс современное ПО работает.
> доверия
дык а зачем вс переводить в вопросы веры? Если интересно ч говорит собеседник - проверь или опроверги независимыми источниками, если не - ну и хай ляшет. Доверие - это совсем не то, что нужно на форуме.
> Называется "переход количества в качество" 8) Диалектика, мать наша.
Вовсе нет. Если работа терпимая - занимаешся ей и особенно от этого не прибавляется ничего. Иногда бывает сложная, много осваивать приходится. Или наоборот претупая и со скуки хочется чнть разумное, по какой причине, как я говорил, лисп выучил.
>> Но это такая малая часть "теории программирования"
> благодаря этой малой чясти вс современное ПО работает.
Мы помним это и благодарны классикам за их работу. Только в современных условиях того, что есть, уже не хватает.
> дык а зачем вс переводить в вопросы веры?
Не веры, а доверия, причем в "техническом" смысле, нечеткая логика и вс такое. Почему - потому что кроме ответов "да" и "нет" есть еще "не знаю" и "может быть". Выбор в условиях неопределенности, извиняюсь за выражение.
> Только в современных условиях того, что есть, уже не хватает.
Вообще, многие наработки тех времн ИМХО как следует не используюцо.
> Не веры, а доверия
А не один член?
> в "техническом" смысле, нечеткая логика и вс такое. Почему - потому что кроме ответов "да" и "нет" есть еще "не знаю" и "может быть"
В техническом смысле всегда можно попросить аргументировать и выдвигать свои контраргументы. Вера и доверие же означают ч принимаеш чью-то точку зрения без должных е обоснований.
> В техническом смысле всегда можно попросить аргументировать
Попросить - можно, если не пора спать (как сейчас :)). Если получишь ответ. Если тебе на понимание ответа и выдвигание контраргумента не требуются часы или дни. Да много всяких "если"...
Пойду я спать. Не хватает здоровья спорить с молодежью в других часовых поясах 8)
>дык их нагенерить нехитро, конешно. Вот только практической пользы с них поменее соответственно.
Не все библиотеки, к которым вынужденно приходится цепляться, требуют какой-то переорганизации. Предположим, какая-нибудь libssl, libstroke (на вскидку) и т. д. Из хидера функции вытащил, в пакет SSL засунул и все. Что в C, что в CL -- вызовы будут плоские. Не такие псевдо-объектно-ориентированые, как в GTK. Так что в общем смысле утверждение "вот только практической пользы с них поменее" не совсем истинное. :)
ну, возможно не все. Многие вс-таки ИМХО луче переработать. Например libcurl - вызовы все плоские, но в лисповом варианте намного благопристойнее будет.
>И вот ведь беда: если простота С-машины позволяет мне убедиться в том, что массивы в С таким свойством обладают, то для Лисп мне это кажется магией, потому как при попытке изучения array.lisp из SBCL мне поплохело уже от первых же строк.
Я код просто для справки дал. Разбираться в нем -- дело тяжелое. В любом коде большого проекта сразу не разберешься. Вот дадут тебе коды MySQL, и ты фиг чего там поймешь. Это для любого языка. Я сейчас тут контрибьюшн в Xorg пытаюсь делать -- драйвер одной старой видеокарточки для поддержки EXA переписываю. Так я уже неделю въезжаю в код (документации на карточку нет). А это только драйвер. :)
Между прочим, авторы SBCL завели хороший ресурс, куда делают коммиты. Не бросают. Он специально сделан для тех, кто хочет поскорее въехать во внутреннее строение SBCL: http://sbcl-internals.cliki.net/index
> А это вообще ни в одной версии под amd64 успешно не собралось.
Как говорится, выживает самый приспособленный. Пока что останусь на SBCL.
Про amd64 ничего сказать не могу. Я сижу на x86 и пока перелезать не собираюсь, слишком многие нужные мне весчи под amd64 в лучшем случае в стадии глубокой беты.
Это было ясно любому здравомыслящему _всегда_, ибо нет и не может быть серебрянной пули. Лиспом не заменишь узко-специализированные языки (скажет так - заменить можно, но нерационально): тот-же SQL, си как портабельный ассемблер тоже заменить трудновато будет, всякие перлы с шеллами скорее всего тоже не надо (пока :) на лисп переводить прямо сейчас - тяжеловат он для этого. Нормальных vm на лиспе на данный момент я не знаю :(
> Если не намного - тоже снимается по тем же причинам.
По тем же самым причинам специализированным языкам лисп может проигрывать по тем или иным характеристикам. Сводную объективную оценку получить трудно :)
> Как следует, что выгоден экономически: ты делаешь намного больше (он же намного превосходит!) за то же время...
Если рабы-кодеры практически бесплатны и легко возобновляемы, то комбайнам-лисперам трудно получить превосходство на полях софтостроения :)
> Как следует, что выгоден психологически - всем хочется иметь мощную и быструю тачку/мотоцикл/комп/дельтаплан, так вот это - из той же серии.
А ещ дешвую, экономичную и легкоуправляемую, а то все бы ездили на болидах ф1 и летали на стелсах или чм там ещ... :)
Для того, чтобы автоматические производственные линии стали массово применяться в промышленности, мало наладить выпуск автоматов - нужны толпы наладчиков. Но, надеюсь, время придт... :)
> > рабовладение существовало тысячелетия, если не десятки тысячелетий, хотя оно экономически невыгодно для общества.
> Ну а эта фраза выдает всего лишь невежество^Wнезнание истории. Рабство появилось всего несколько тысяч лет назад, и появилось именно потому, что было _экономически_ выгодно.
Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)
> Ну, тут где-то пробегало (в версии от yyk), что чистый лисп -- это (T NIL CONS CAR CDR QUOTE). А все остальное -- или от лукавого или можно выразить через эти божественные сучности.
Херасе... А вы читать умеете? Там-же: CL - стандарт. А большинство лиспов объединяет вот этот вот набор... Из которого таки вс остальное _можно_ вывести, но это будет неоптимально.
Вы сначала укажите, какой именно лисп вы имеете в виду, а потом уже устраивайте здесь плачь Ярославны...
> Считаю, что все биндинги в Лиспе должны генерироваться автоматически. Я не говорю о высокоуровневых реализациях типа cells-gtk. Я говорю о простых 1:1. Должен инспектирваться хидер, генерироваться независимый от языка файл, а потом преобразовываться в биндинг. Примерно так сделано в lambda-gtk. gtk.api сгененирован из хидеров программой ffigen (http://www.ccs.neu.edu/home/lth/ffigen/), а при запуске lambda-gtk он этот gtk.api в CL переводит. Вот так примерно или даже лучше должно быть в принципе. Тогда и нововведения отслеживать не надо будет.
Так эти 1:1 составляют малую часть, ибо чаще нужно именно привести ипользование биндинга "в человеческий вид". Вот здесь и расходятся пути: аж три (если не больше) магистральных биндинга к gtk. Простейшие так не плодяться :)
> Аха. Если так делать, то освоить Лисп становится не страшнее, чем ту же Жабу.
Вы наступаете на старые грабли - _какой_ лисп? Фины описывают тот лисп, который вписывается в десяток основных понятий и форм. CL - стандарт, включающий в себя намного больше, и он вам так быстро не "дастся", хотя он, имхо, больше готов для "продакшн", чем какая-либо другая "реинкарнация" лиспа.
> Главный практический вывод: Лисп, это, оказывается, такой ассемблер.
Угу, только динамически-типизируемый, что вытекает из его "позднего свзяывания" конкретных значений с символами (именно которыми он в большей части и оперирует) - оптимизацию конкретных реализаций мы опустим, ибо она "не обязательна".
> мощные средства функционального программирования и макрорасширения.
Если с первым ещ можно согласиться (это я о функциональном программировании, хотя оно и будет выглядеть коряво), то о макрорасширениях лучше и не вспоминайте.
> почему нет ни одной приличной реализации хотя бы той же JVM или Python-машины на Лиспе? Почему нет ни одного приличного транслятора с Java или Python в тот же самый Лисп-код?
Это тебя куда-то не туда понесло. Ладно бы ещ спросил почему нет vm на лиспе. Или лиспа для jvm (есть какие-то, но до полноценного CL ни один не дотягивет).
> Если MDD - это Mukti-Dimensional Data, для работы с ними есть какие-то свои деревья (R-деревья, кажется).
Не, это Multiple Decision Diagrams.
> Ненамного хуже (там log по основанию 2, а то и больше).
При тех алгоритмах и на тех объемах, что там используются, замедление в два раза уже заметно. А логарифм 100000 по основанию 2 уже дает 17-кратное замедление.
> Кроме того, у хэшей (почти всех) плохой худший случай (хуже log(N)).
Это понятно, потому и приходится тюнить эти таблицы вручную или заниматься эвристическим автотюнингом. Что, понятно, в стандартных реализациях весьма проблематично. Хотя в большинстве случаев оно работает и так, если не допускать грубых ошибок в функции.
> Там говорилось о каком-то "иерархическом хэш-массиве" ;)
Не совсем так. Это типа хэш-таблицы, элементами которой опять являются хэш-таблицы, элементами которой опять являются опять хэш-таблицы, а уже ее элементами являются искомые объекты.
О, вспомнил, почему это неприменимо. Для общего случая MDD глубина такой вложенности пропорционально числу ветвлений в вершине. И даже в наиболее важных практических случаях это уже не 3, а 5 и 10 вложений соответственно.
> Фины описывают тот лисп, который вписывается в десяток основных понятий и форм. CL - стандарт, включающий в себя намного больше, и он вам так быстро не "дастся", хотя он, имхо, больше готов для "продакшн", чем какая-либо другая "реинкарнация" лиспа.
Как и в sicp. Речь не идет о продакшн. Речь идет о быстром обучении. В учебниках типа "Java за 24 часа" тоже ведь весь стандарт и передовые продакшн-фичи не дают.
> то о макрорасширениях лучше и не вспоминайте.
Исключительное ИМХО, как я понял. Ибо макросы в Сях есть, и они позовляют его изуродовать до полной неузнаваемости так же, как и макросы Лиспа.
> Или лиспа для jvm (есть какие-то, но до полноценного CL ни один не дотягивет).
Вот это как раз и не нужно. Ибо эмулировать один ассемблер на другом -- это извращение. Все равно, как жаловаться, что нет приличного С для JVM.
> _Здесь_ - не получишь. По многочисленным ссылкам при наличии желания - запросто :)
Диалога ничем не заменишь
>> Если не все - то вопрос снимается, вс ясно.
>Это было ясно любому здравомыслящему _всегда_, ибо нет и не может быть серебрянной пули.
"Серебряная пуля" - это совсем из другой оперы. Языки, которые были некоторое время стандартами разработки _во всей отрасли_ - были (Си, Си++, Java). И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?
>> Рабство появилось всего несколько тысяч лет назад, и появилось именно потому, что было _экономически_ выгодно.
> Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)
Демагогия. Существует определение рабства, и определены довольно точные сроки его возникновения. Спорить не о чем.
> Существует определение рабства, и определены довольно точные сроки его возникновения. Спорить не о чем.
С этим согласен. Но вопрос был - "выгодно для общества", а не для государства, страны, хрена лысого. Для вас это одно и то же? Так вот, с выгодой "для общества" возникают сложности :)
> И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?
Почему не лисп, а си - потому что лисп вопреки вашему утверждению не является портабельным ассемблером (ладно, оговорюсь, CL не является). Хотя с самого начала лисп разрабатывался для "символьных вычислений" и на роль "асма" не годился.
Почему не все остальные языки из вашего списка? Так по той-же причине, что и фаст-фуда и женских романов продатся больше, чем нормальной еды и литературы :) Нужна аналогия с производством, а не потреблением? Ну, паровые двигатели тоже очень долго в промышленность прорывались ;) А мы вс ещ на стадии кустарных ремесленников находимся...
> Так вот, с выгодой "для общества" возникают сложности :)
Не возникает никаких сложностей. Рабство тогда способствовало прогрессу _общества_ (благодаря которому оно потом было проклято и запрещено - но потом, гораздо потом).
>> И мой вопрос был - если Лисп _настолько_ хорош, то почему он не стал таким стандартом?
> Почему не лисп, а си - потому что лисп вопреки вашему утверждению не является портабельным ассемблером
Это не я утверждал, а юджин_косенко 8)
> Нужна аналогия с производством, а не потреблением? Ну, паровые двигатели тоже очень долго в промышленность прорывались
Я не припомню каких-то сильных препон на пути прорыва паровых машин - как они стали приемлемо эффективными, так и стали применяться в промышленности. Кроме того - _такие_ аналогии с промышленностью в компьютерной области не катят - на одном и том же компе одинаково хорошо (и одновременно!) могут работать Си, Лисп и Жаба. И, наконец, у Лиспа было 40 лет на то, чтобы прорваться. Огромный срок по меркам нашей отрасли.
Число дочерних вершин в MDD -- это ведь тоже граф. Видимо, мы друг друга не понимаем.
Суть BDD/MDD в том, что это компактные ациклические графы, свернутые из деревьев. То есть, если взять дерево и выбросить из него все повторяющиеся фрагменты и замкнуть соответствующие связи на оставшиеся уникальные, то получится BDD/MDD. Разница в том, что BDD бинарны, то есть у каждого промежуточного узла только два потомка, а у MDD их может быть больше.
Типичный алгоритм над BDD принимает две структуры, в каждом узле производятся примерно следующие действия:
1. Выполняется рекурсивный вызов обработчика для левых ветвей, получается левый результат.
2. Выполняется рекурсивный вызов обработчика для правых ветвей, получается правый результат.
3. Если левый и правый результаты идентичны, то любой из них считается результатом операции.
4. Если они не идентичны, то строится новое дерево с левым и правым результатами, как потомками. Однако тут срабатывает фишка, что если такой узел уже был построен раньше (например, в другой ветви вычислений), то нужно не строить новый узел, а возвращать ссылку на уже существующий. Именно на этом этапе необходим кэш узлов, и ключом в нем должна быть не просто ссылка на объект, а тройка "левый результат"-"правый результат"-"код вершины".
На самом деле, все немного сложнее (в частности, иногда один из результатов может не вычисляться, кроме того, я опустил завершение рекурсии), но суть именно в четвертом шаге -- эффективном поиске в кэше узла, эквивалентного создаваемому.
> IIRC, и у AVL-деревьев, и у RB-деревьев оно == 2.
Кстати, похоже, что деревья неприменимы по той причине, что они требуют линейно упорядоченного уникального ключа для доступа. Здесь, как я понял, это тоже невозможно.
> "Вложений" или уровней дерева?
Вложений таблиц. Но на мой взгляд, это не имеет значения.
> Не возникает никаких сложностей. Рабство тогда способствовало прогрессу _общества_ (благодаря которому оно потом было проклято и запрещено - но потом, гораздо потом).
Только при условии _невключения_ рабов в определение этого самого общества. Рабам прогресс принесла только отмена этого самого рабства.
> Это не я утверждал, а юджин_косенко 8)
Принимается... :)
> Я не припомню каких-то сильных препон на пути прорыва паровых машин - как они стали приемлемо эффективными, так и стали применяться в промышленности.
Достаточно. Во-первых, препоны были (бунты, если не восстания цеховиков против "фабрикантов"). Во-вторых, не "приемлемо эффективными", а эффективнее одиночных ткачей с ручными станками/на ослиной тяге :). Пока "софтопряды" считают, что толпа легкозаменяемых кодеров - выгоднее, чем небольшое количество долгоподготавливаемых профессиналов высокого уровня (речь уже даже не о языке). Но это "пока" длится ровно до того момента, пока на первый план не выступит требование _качества_ кода. А там уже вс должно будет поменяться. Правда ,что там будет - я не знаю :)
> Кроме того - _такие_ аналогии с промышленностью в компьютерной области не катят - на одном и том же компе одинаково хорошо (и одновременно!) могут работать Си, Лисп и Жаба.
А вот здесь вы уже говорите о "потреблении", а не о "производстве" :)
> И, наконец, у Лиспа было 40 лет на то, чтобы прорваться. Огромный срок по меркам нашей отрасли.
У лиспа было 40 лет для того, чтобы обкатать большинство технологий, которые только сейчас (или недавно) стали внедряться в другие языки. А для прорыва не хватило желающих сделать из него "мэйнстрим" любой ценой :)
>> _Здесь_ - не получишь. По многочисленным ссылкам при наличии желания - запросто :)
> Диалога ничем не заменишь
ну тогда просто непонятно, какой бы ты хотел ответ. Можно было бы просто ответить "патамушта!" и это было бы правильно. Остальные аргументы, навроде того, что лисп позволяет описывать более абстрактные вещи ибо обладает наиболее богатым набором средств и самой простой и удобной семантикой, тебя ведь не впечатлили. Какого рода аргументация тебя бы устроила?
>> Это зависит от того, включать или нет рабов в понятие "общества", ибо речь шла о "невыгодно для общества" :)
> Демагогия. Существует определение рабства, и определены довольно точные сроки его возникновения. Спорить не о чем.
Это какие же сроки? Наиболее ранние официальныо признанные источники относяцо если не ашыбаюсь, к VII-V вв. до н.э., зарождению древнево египта. Достоверных более ранних просто нету.
> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?
Иными словами, почему он не является "портабельным ассемблером"? Потому что изначально он был нацелен на работу с символами, а не адресами. Да, в его синтаксис можно загнать и работу с сылками, но в итоге вы не получите конечной гибкости. А работа с символами - некоторый "оверхед".
хм. did you know what рабство жестоко ограничивало применение разного рода механизмов? Или ты будеш утверждать, что механизмы нейдут на пользу прогресса?
> как они стали приемлемо эффективными, так и стали применяться в промышленности.
наоборот, они стали эффективными как только понадобились. До этого просто никто (со времн Нерона!) не работал над их эффективностью.
> И, наконец, у Лиспа было 40 лет на то, чтобы прорваться.
Прорваться куды? Я приводил кучю ссылок только на коммерческие реализации, стоимостью до нескко килобаксев. А сколько ты можеш назвать разных компилеров сей, с++ и жабы? Это приблизительно всодно ч говорить "самолты и вертолты маргинальны и не получили распространения потому что по гаражам у всех лисапеды и жигулнки"
> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?
http://www.cons.org/cmucl/FAQ.html 8й вопрос. ИМХО главным образом из-за того, что высокоуровневые абстракции нужно привязывать к конкретной модели жылеза и оси. Для портабельного макроассемблера навроде сей это намного проще, потому что в неоптимизированной форме ево операторы более-менее однозначно соответствуют группе асмовых комманд.
уточню, требование _огромного_количества_пресложново_высококачественново_кода_ . Ибо на мелких задачах даже большой в процентах выйгрыш сравнительно невелик по сравнению с накладными расходами.
> Это понятно, потому и приходится тюнить эти таблицы вручную или заниматься эвристическим автотюнингом. Что, понятно, в стандартных реализациях весьма проблематично. Хотя в большинстве случаев оно работает и так, если не допускать грубых ошибок в функции.
А что можно тюнить в хеше, кроме собственно хэш-функции и количества (политики аллокации) этих, как их по русски, "ведер"?
У плюсового hash_map первое - параметр шаблона. Наверняка есть и реализации, где второе настраивается через policy.
Сообщение удалено tailgunner по причине '3.1 Дубль'
Ответ на: Re: Фраза о Лиспе... от bugmaker 09.10.2006 15:39:55
Re: Фраза о Лиспе...
> Какого рода аргументация тебя бы устроила?
Что-нибудь вроде
> Наиболее ранние официальныо признанные источники относяцо если не ашыбаюсь, к VII-V вв. до н.э., зарождению древнево египта.
Я люблю ЛОР, блин! Куда нас занесло, а? 8) VII-V вв. до н.э. - это период распада и упадка Египетского царства. Зарождение, IIRC - это примерно 3-4 тысячелетие до н.э. Официально зафиксированное рабство - примерно 5 тысячелетие до н.э. Правда, это курс истории 5-го класса, могу немного ошибаться (на тысячу лет :))
> Достоверных более ранних просто нету.
Есть в изобилии. К тому времени, что ты упоминаешь, были давно (тысячи лет назад) построены битком набитые папирусами пирамиды, доживало свое Новое Царство. А до него были еще Древнее и Среднее.
Что-нибудь вроде: "Лисп не получил распространения, это факт. Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"
> Наиболее ранние официальныо признанные источники относяцо если не ашыбаюсь, к VII-V вв. до н.э., зарождению древнево египта.
Я люблю ЛОР, блин! Куда нас занесло, а? 8) VII-V вв. до н.э. - это период распада и упадка Египетского царства. Зарождение, IIRC - это примерно 3-4 тысячелетие до н.э. Официально зафиксированное рабство - примерно 5 тысячелетие до н.э. Правда, это курс истории 5-го класса, могу немного ошибаться (на тысячу лет :))
> Достоверных более ранних просто нету.
Есть в изобилии. К тому времени, что ты упоминаешь, были давно (тысячи лет назад) построены битком набитые папирусами пирамиды, доживало свое Новое Царство. А до него были еще Древнее и Среднее.
>> Зыть, я же о том, что рабство самим рабам никакого прогресса не принесло
>А я о том, что и остальным тоже сравнительно никаково.
Да ты что! До 500 г.н.э (примем, что именно тогда рабство стало невыгодным) не было никакого прогресса? Древние Египет, Ассирия, Персия, Греция, Рим - это нифига не прогресс? "Водопровод, сработанный еще рабами Рима" - не прогресс?
хм. did you know what рабство жестоко ограничивало применение разного рода механизмов? Или ты будеш утверждать, что механизмы нейдут на пользу прогресса?
Это где такое было? Это больше похоже на городские цеха веках так в 8..13-ом.
> наоборот, они стали эффективными как только понадобились. До этого просто никто (со времн Нерона!) не работал над их эффективностью.
Не было у паровых машин непрерывной истории от Нерона до этого, как его (смотрит в яндекс), Ватта, да. В Риме это была игрушка, и на тех задачах, которые решались тогда (сельское хозяйство+ремесло), она была сильно хуже, чем рабы/тягловые животные. А потом ее переизобрели заново в 18-м веке. И когда Ватт приделал к ней автоматический регулятор - тут же завоевала практически всю энергетику (ж/д и морской транспорт, фабричные и рудничные приводы - а больше тогда ничего и не было).
А это уже половые проблемы CMUCL. :) Поэтому и сделали от него fork под названием SBCL, чтобы перестроить по-нормальному код, который портируется куда веселее, чем CMU. Думаю, что скоро планомерно возьмутся все высоты. Это и было основной целью проекта SBCL, который теперь своей жизнью зажил.
>хм. did you know what рабство жестоко ограничивало применение разного рода механизмов?
Ключевое слово - "тогда" (речь, напомню, о Древнем Египте). И, естественно, со временем рабство превратилось в тормоз прогресса, и в основном исчезло, а потом вообще было объявлено вне закона.
И еще: по-моему, в таких случаях нужно писать "did you know THAT", не "what". Нет?
> Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"
У всех есь недостатки. С недостатками мы боремсо.
> Куда нас занесло, а?
пт! мя глюкнуло. Я имел введу 5-7 тыс лет до н.э. вместо 5-7 века :( нуфс, я аблажался и теперя мне никто не поверитнахъ :'(
> Да ты что! До 500 г.н.э (примем, что именно тогда рабство стало невыгодным) не было никакого прогресса? Древние Египет, Ассирия, Персия, Греция, Рим - это нифига не прогресс? "Водопровод, сработанный еще рабами Рима" - не прогресс?
А какой там прогресс? Ну строили что, выращивали, киляли друх друха. Или ты знаеш там были НТР про котороя я не ведаю?
> До 500 г.н.э (примем, что именно тогда рабство стало невыгодным)
Ну это неправда же ни разу, это еще даже не расцвет средиземноморских рабовладельческих империй. В 500-м году еще ни Александр Македонский, ни Пунические войны даже в планах не значились (правда, Золотой Век Афин уже наступал потихоньку).
Рабство стало невыгодным эдак чуть позже Цезаря (Гая Юлия), да и то больше из-за истощения африканских земель.
А в Конфедерации оно оставалось выгодным до середины 19-го века, и сохранилось бы и дольше - но северяне не позволили.
И, кстати, выгодность политического строя для общества имеет смысл мерить по высшим достижениям этого общества - нет никаких сомнений, что Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов...
паровой движок был изобретн в древней греции. А вот паровоз - нет. Потому что использование механизмов невыгодно людишкам при рабовладении. Это ведь не означяет ч их использование невыходно опчеству?
> И еще: по-моему, в таких случаях нужно писать "did you know THAT", не "what". Нет?
Я ужо говорил, ч перепечятал это из толи борландовской толи мсявой проги и ч багрепорты луче направлять к им.
> пт! мя глюкнуло. ... я аблажался и теперя мне никто не поверитнахъ :'(
Ни за чьто!
> А какой там прогресс? Ну строили что, выращивали, киляли друх друха.
Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "что". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием вс более совершенного оружиея и тактики - тоже ни разу не прогресс.
Ну а греческие театр и изобразительное исскуство, греческая и римская философия - они даже упоминания не стоят - это же не НТР. Только НТР стоит нашего просвещенного внимания!
> А если серьезно, то хотелось бы поконкретнее узнать, в чем именно заключается непортабельность Лиспа?
Не непортабельность, а более сложный процесс. Если взять CLISP, то у него с платформами все просто, так как он есть байт-код интерпретатор, написанный на C. Где скомпилится, там и пойдет. А вот с компиляторами LISP сложнее, так как поимио обеспечения нативной кодогенерации, надо еще иметь привзяку к операционной системе.
Если ты внимательно посомтришь на исходник SBCL в разделе runtime, то там все увидишь. Большой набор C-файлов, зависящих от ОС (в названиях) и архитектуры. Они там так и встречаются: alpha-osf1-os.c, alpha-linux-os.c, и т. д. :
А если ты о непортабельности кода на CL в разных реализациях, то и такое случается. Если взглянешь на серьезный проект, то увидишь там условные дела: #+sbcl #+allegro, #+openmcl и т. д. Это от того, что когда речь заходит о вещах, не описаных в стандарте, то у многих реализаций развязаны руки. Делают свое. А ты должен иметь в виду, что если ты используешь библиотеку sb-posix в SBCL, например, то ее не будет в другой реализации или она совсем другая. Или sb-bsd-sockets, например.
> Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "что". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием вс более совершенного оружиея и тактики - тоже ни разу не прогресс.
ну сравни с 19-20 веками.
> Только НТР стоит нашего просвещенного внимания!
в рамках данново топика, да. Ибо в противном случяе придцо всякое типо методики ХР за прогесс признать.
> Что-нибудь вроде: "Лисп не получил распространения, это факт. Потому что его огромные и несомненные были скомпенсированы следующими недостатками: <здесь перечень недостатков>"
Ни кто не говорит, что у лиспа (CL?) нет недостатков _как у ЯП_. (И когда-то он таки был довольно распространн в процентном соотношении). Но он не получил массового распространения в большей степени не из-за своих недостатков. Лисп тоже не сразу стал CL-м. И макры в нм появились не сразу. И CLOS. И т.д., и т.д. С учтом оверхеда на "символьные вычисления" и ограниченности ресурсов можно было найти/создать более эффективный (в машинном плане) язык для конкретной области (си, кобол и т.д.). А с появлением писишек на рынок вылезли совсем другие "правила игры". К моменту появления железа, на котором на оверхед лиспа можно было не смотреть, у него была куча "конкурентов", которые имели уже довольно "широкие слои комьюнити", через которые не так-то легко пробиться, учитывая, что очень многие стали руководствоваться личными предпочтениями/привязанностями, а не строгой оценкой и прочее. Опять же мифы и предвзятое отношение...
>> До 500 г.н.э (примем, что именно тогда рабство стало невыгодным)
> Ну это неправда же ни разу, это еще даже не расцвет средиземноморских рабовладельческих империй. В 500-м году еще ни Александр Македонский, ни Пунические войны даже в планах не значились (правда, Золотой Век Афин уже наступал потихоньку).
У тебя проблемы с датами или чтением? А.Ф.Македонский умер в 325 г до н.э, Пунические войны закончились (IIRC) к 210 г. до н.э. А к 500 г н.э. готы уже 4 года как взяли Рим.
> Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов
При этом зижделись на использовании рабского труда.
>> Да, Вавилон, Персеполис, Афины, Александрия, Рим - это так, "что". Мореплавание - какя мелочь. Ирригационные системы - тоже фигня. То, что "киляли друх друха" с ипользованием вс более совершенного оружиея и тактики - тоже ни разу не прогресс.
> ну сравни с 19-20 веками.
Ну заметь разницу в 3-4 тысячи лет.
Или сравни 20-й век с 50-м :-P
>> Только НТР стоит нашего просвещенного внимания!
>в рамках данново топика, да
Кстати, о топике... уже анонимные братья подтягиваться начали. Нехороший знак.
> Ибо в противном случяе придцо всякое типо методики ХР за прогесс признать.
>А если серьезно, то хотелось бы поконкретнее узнать, в чем именно
заключается непортабельность Лиспа?
Проще приведу пример из произвольного кода:
#+lispworks
(eval-when (:compile-toplevel :load-toplevel :execute)
(require "comm"))
#+sbcl
(eval-when (:compile-toplevel :load-toplevel :execute)
(require :sb-bsd-sockets))
;; managing processes
(defun current-process ()
"Return the object representing the current process"
#+lispworks mp:*current-process*
#+abcl (ext:current-thread)
#+openmcl ccl:*current-process*
#+sb-thread sb-thread:*current-thread*
#+allegro sys:*current-process*
#-(or lispworks abcl openmcl sb-thread allegro) nil)
(defun kill-process (process)
"Kill the process represented by the object process"
#+lispworks (mp:process-kill process)
#+abcl (ext:destroy-thread process)
#+openmcl (ccl:process-kill process)
#+sb-thread (sb-thread:terminate-thread process)
#+allegro (mp:process-kill process)
#-(or lispworks abcl openmcl sb-thread allegro) process)
Тут видно, что тредные библиотеки в разных реализациях разные. Это не
оговорено стандартом и очень зависит от реализации, поэтому
не взаимозаменяемо.
> За 2-3 века было прогрессу больше чем за тыщелетия.
Не в том дело, когда развитие было быстрее (я бы не взялся оценивать). Главное - развитие было всегда, и некоторое время рабовладение было его двигателем.
> Я предпочитаю сам создавать то, ч лет чз 10 смотреть будут.
Доведешь до юзабельного состояния - запости ссылку
С чтением. Прочитал, что рабство стало невыгодным к "500 г. до н.э.".
Но про 500 г.н.э. - это, положим, тоже неправда, слишком поздно. Разложение рабовладелия в Риме началось гораздо раньше. Насколько я помню школьный-институтский курс истории, основная масса земли к этому времени уже обрабатывались прикрепленными крестьянами-собственниками (которые, однако, не были лично свободны) - т.е. вполне "феодально", по марксистской классификации.
> > Египет и Микены, Рим и Карфаген были большим шагом вперед по сравнению с племенными кланами пастухов
> При этом зижделись на использовании рабского труда.
Ну дык и я о том же. Впрочем, это уже совсем жесточайший оффтопик.
почему? как раз в этом дело. Иначе, почему ты думаеш европейцы открыли америку а не наоборот? Потому что у тех даже колеса неиспользовались в хозяйстве, хотя были изобретены.
> Главное - развитие было всегда,
ну, совсем ево не может не быть, полюбому.
> и некоторое время рабовладение было его двигателем.
Вс правильно, вопрос только в мощности двигателя. Автоматизация например на период рабства недоступна и невозможна, сам понимаеш почему. А между применением техники и толпой рабов разница принципиальная, многое, что недоступно толпе рабов, техникой делаецо.
> Доведешь до юзабельного состояния - запости ссылку
Ладно. А как доказать, что это именно то, на что будут смотреть?
> Да? Школьный курс истории утверждал, что "индейцы не знали колеса".
Не совсем так. Они отлично знали колесов, но не использовали их в практической деетельности, в т.ч. по религиозным соображениям, подобно тому как современное програмисты неюзают лиспа.
> Мне без разницы - будут, не будут. Мне _самому_ взглянуть любопытно.
ну на лисп глянь сперва, там многое на ево основе.
> Потому что изначально он был нацелен на работу с символами, а не адресами. Да, в его синтаксис можно загнать и работу с сылками, но в итоге вы не получите конечной гибкости. А работа с символами - некоторый "оверхед".
Это все лехко решается на уровне виртуальной машины. Я больше поверю аргументам о том, что оно непортабельно из-за слишком малого ядра языка. Дыкть, С с библиотеками тоже не совсем портабелен. Речь ведь шла о языках, а не о библиотеках.
Совершенно верно. Стандартом ANSI он стал только в 1994 году. Вся история LISP -- это борьба реализаций и подходов. То есть настоящий эволюционный процесс. И CLOS в одночасье не появился. До этого были абсолютно разные реализации: LOOPS от Xerox, FLAVORS от симболикса и др. AFAIK, именно версия от Xerox легла в основу стандарта. Ну или по большей части.
>Совершенно верно. Стандартом ANSI он стал только в 1994 году.
Не знаю насчет стандарта ANSI, но "Common Lisp was defined and a book published in 1984 called 'Common Lisp: the Language'". Так что сам язык - ровесник Си++.
> Это все лехко решается на уровне виртуальной машины. Я больше поверю аргументам о том, что оно непортабельно из-за слишком малого ядра языка.
На сколько легко? И как давно? Вы про сегодняшний день, или про всю историю лиспа?
"непортабельно из-за слишком малого ядра языка" - расшифруйте пожалуйста :) И опять же, мы о лиспе "CAR-CDR" или о CL? В CL-е ядро маленьким никак не назовшь. А со всеми необходимыми типами и т.п. - это уже почти CL получится. Вывести всю систему типов из списка можно, но это будет очень неэффективно (если вы только не предложите спец. процессор :)
>Не знаю насчет стандарта ANSI, но "Common Lisp was defined and a book published in 1984 called 'Common Lisp: the Language'". Так что сам язык - ровесник Си++.
Ну я сейчас не готов говорить, почему у этих языков в результате такая разная судьба. Этот период надо пережить. Я могу только говорить за себя. Когда я учился в бауманке, то моей тематикой были около-ИИ-шные темы. Ну и первое, что попадалось на глаза были LISP и Пролог. В результате в качестве среды для реализации был выбран Пролог. Инфраструктура была более развитая. Он чаще попадался на глаза. А еще интернета толком не было тогда. Только некоторые счастливчики на работе имели. Поэтому узнать более подробно, а тем более получить что-то подобное на руки для LISP было нереально. А вот с Прологом было все гораздо лучше (всюду был как минимум компилятор Borland Turbo Prolog). А как появился Интернет, то средство было выбрано. Потом был голландский SWI Prolog (его я использовал наиболее активно), Quintus Prolog и т. д. Считаю, что я много потерял, не имев возможности обратить внимание на LISP тогда. C++ был сразу подхвачен индустрией для массового внедрения. А LISP большей частью был в университетской среде. Кто первый встал, того и тапки. Вот и все мысли неглубокие. Говорить о том, что не произошло, не имеет смысла. Говорить уместно о том, что произойдет :)
P.S. А эффективные реализации Пролога есть и на LISP. :)
(defun permutations-my (x)
(if x
(loop for e in x append
(loop for p in (permutations (remove e x :count 1 :test 'eq))
collect (cons e p)))
'(nil)))
Дубль два.
>Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?
В тапки индустрии. Крутился вокруг исследовательских проектов относительно небольшого количества людей (типа посвященных). Ну еще внутри корпораций для своих нужд использовался и до тех пор, пока были люди, его знающие. И главное -- не было тмогущественных компаний, которые его продвигали и совершенствовали. Был симболикс, были подразделения в Texas Instruments (CLX там и был написал в 1987 году, LISP-машины делали), была LMI, для которой старался RMS. Но это не тот масштаб. И слава богу, что так. Мне не хочется, чтобы Lisp стал мэйнстримом. Поэтому и убеждать не хочу никого. :)
> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?
Опять про море? ;)
Где ему тапки не достались? На писишках? Так он там первым и не был (если не считать лисп-машины, но те по цене... кусались слегка ;) да и к писишкам те компьютеры никакого отношения, разве что кроме габаритов, не имеют), а посему и тапки не его.
Ещ вопросы есть?
P.S. Не устали нам доказывать, что лисп вам незачем? :)Ь
>> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?
>Опять про море? ;)
А у него я еще не спрашивал ;)
> Где ему тапки не достались? На писишках? Так он там первым и не был
Да нигде - ни на мини-машинах, ни на рабочих станциях. "Встал первым" == "первым ассимилировал в себя кучу передовых идей".
> Ещ вопросы есть?
А ответы?
> P.S. Не устали нам доказывать, что лисп вам незачем? :)Ь
??? "Доказывать" ? Я сказал в самом начале - _сейчас_ Лисп мне не нужен, что тут доказывать? А мнения лисперов о том, почему их язык при всех достоинствах остался уделом немногих - мне интересны. "Мне не хочется, чтобы Lisp стал мэйнстримом." - это интересное мнение. Еще бы услышать обоснование :)
> Первым-то встал как раз Лисп. Почему же раз за разом тапки доставались не ему?
За песюки война токо-токо начинается. Ну ненужно было раньше на писишках таково рода наречий. И двух-трхкратный проигрыш в производительности жалко было отдавать, и задачи сравнительно простые и прог мало делалось => можно было нанять нужное число человек и вс на с/с++ сделают. Именно в последнее время проснулся интерес к интерпретируемым/байткодным. Начяли появляцо всякие руби с питонами. А подход к программированию пока старый остался, с/с++-образный. Нового не выработали ещ. Скоро случицо кризис в айти, потом ужо вс по своим местам расползцо.
Новости с полей (между делом). Если кому интересно, то появился инсталлятор SBCL 0.9.17 для Windows. У меня таковых нет. Так что пофиг. А кому-нибудь будет интересно. Сборка официальная, но статус еще носит "экспериментальный". Скоро SBCL пополнится полноценно еще одной платформой.
> "Встал первым" == "первым ассимилировал в себя кучу передовых идей".
Ну и? На тот момент эти идеи нафиг никому не упрлись - вот и тапок нет. Что поделаешь, если до людей сразу не доходит, а только после нескольких десятков лет хождения по граблям... Так что вы это у себя спросите - почему же у лиспа до сих пор тапок нет ;)
> А ответы?
А-а-а-а.... чукча не читатель... Понятно ;)
> А мнения лисперов о том, почему их язык при всех достоинствах остался уделом немногих - мне интересны.
Потому что он многим и не нужен. На постсоветском пространстве вообще натуральное хозяйство ещ очень даже в ходу... и это в 21-м веке. Что уж удивляться, что лисп многим не нужен... Мотыгой сподручнее ;)
К сожалению, "полноценной" - не скоро. В этом году собираются выпустить 1.0, но носом чую - полноценной поддержки винды ещ не будет (хотя здесь чего об этом горевать?.. ;)
> надеюсь, венда исдохнет намного раньше чем оно появицо.
Если б этого можно было ожидать хотя бы в следующем году... А так уж пусть лучше доделают. В нынешней ситуации это только пойдт на пользу лиспу (а венду вс-равно не спаст :)
Аха, давай. Жаль ч лисп бинари выполнябельные не делает :( А ещ фигня такая в cmucl - загрузил gtk-cells, фсио работает. Схрнил core. Загружаю с сохраннным, он при загрузке пытаецо компилить lambda, ругаецо, и потома "Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #xB7FB085C." Нушозанах?
А в clisp если в cells пытаешс уникожий текст запихать в виджет, ругаецо "1103 невозможно отконвертировать к инородному типу FFI:UCHAR" хотя оный clisp компилен с поддержной уникода и в cmucl тоже самое работает. Вот ацтой!
> Именно в последнее время проснулся интерес к интерпретируемым/байткодным.
Мне всегда казалось ошибкой на грани слабоумия то, что в них выделяют именно эту черту. По мне, так это лишь деталь реализации. Были байткодные интерпретаторы Си - и кому они интересны? То же и с Фортом - байткодный (ну ладно, косвенно-шито-кодный), интерпретируемый.
Причм ограничение принципиальное видимо. На случяй eval. Хотелось бы иметь возможнось скомпилить минимальный бинарь без возможности eval в м ибо всодно невсегда нужный.
Ну ч делать, да, сасут. И макры тоже. Подождм, когда в питоне такое появицо. Тогда в лиспе сразу сасать перестанут. А так - пока будем получять удовольствие.
> Причм ограничение принципиальное видимо. На случяй eval. Хотелось бы иметь возможнось скомпилить минимальный бинарь без возможности eval в м ибо всодно невсегда нужный.
Штука в том, что сие не оговаривается стандартом. Далее брехать не буду, ибо не знаю :)
Есь мнение, что у юзающево то, ч сасьйот, высасывает моск в конце концов. Это мнение иногда подтверждаецо, например в случяе с юзверями венды и питона, а иногда нет, как в случяе с скопками. Хотя, возможно, скопки вс-таки не...
А вопрос вида компилированного кода рано или поздно встанет у всех, кто начал уже писать программы. Когда-нибудь придет человек и скажет: "А если я не хочу делать программу в виде огромного core? А также не хочу отдавать программу в fasl, так как они очень медленно загружаются?" И тут будет еще нечего ответить (хотя не знаю, как там дело в коммерческих реализациях обстоит). Рано или поздно проблема решится, но сейчас, например, сохраненное ядро save-lisp-and-die с монстром MCCLIM, простейшей рисовалкой clim-fig и основным ядром уже занимает 50 Мб! Бинарный монолит: весь компилятор, REPL, CLOS, все библиотеки функций стандартного CL, графический тулкит, программа. При большом проекте все это дело займет уже больше.
А еще пока нет fasl-совместимости между разными версиями SBCL. поэтому при каждом обновлении все компилируется заново. Вот такие вот в этом плане недостатки есть.
>Если спросить 10 случайно выбранных программистов, не знакомых ни с >Лиспом, ни с Питоном, что им понятнее - текст на Лиспе или на >Питоне, все 10 скажут - на Питоне. Но ты-то знаешь, что они все >извращенцы...
А что это:
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
new = list(p)
new.insert(i, e[0])
yield new
читается намого лучше, чем:
(defun permutations-my (x)
(if (null x)
(loop for e in x append
(loop for p in (permutations-my (remove e x :count 1 :test 'eq))
collect (cons e p)))
'(nil)))
Пример на Лиспе IMHO больше смахивает на английский язык.
Полный core Lispworks в архиве около 5 метров получается, Corman Lisp - около трех. Если выкидывать компилятор, eval, а также неиспользуемые функции, то на практических приложениях EXE для Lispworks ужимается до 1.5М в архиве, Corman Lisp до 2-х метров добивал.
Так что при современных линиях связи это даже для Shareware уже не проблема. SBCL конечно толст, но для серьезных приложений это тоже не проблема, подумаешь какие-то 50 метров, даже в смартфон влезет запросто ;-) Если семейство приложений распространять, то одно ядро можно как .NET Runtime прикладывать один раз на все, уже экономия получится.
Вот тут говорили, чем мол Лисп лучше, Питоне не хуже, зачем нужны макры и т.д.
А где например для Питона аналог CELLS взять ?
http://common-lisp.net/project/cells/
Пример кода:
(defmodel motor ()
((status :cell t :initarg :status :accessor status :initform nil)
(fuel-pump :cell t :initarg :fuel-pump :accessor fuel-pump
:initform (c? (ecase (^status) (:on :open) (:off :closed))))
(temp :cell t :initarg :temp :accessor temp :initform (cv 0))))
(def-c-echo status ((self motor))
(trc "motor status changing from" old-value :to new-value))
(def-c-echo fuel-pump ((self motor))
(trc "motor fuel-pump changing from" old-value :to new-value))
(def-c-echo temp ((self motor))
(trc "motor temperature changing from" old-value :to new-value))
(defparameter *motor1* (to-be (make-instance 'motor
:status (c? (let ((filtered-temp (^temp self (fsensitivity 0.05))))
(if (< filtered-temp 100) :on :off))))))
(dotimes (x 2)
(dotimes (y 10)
(let ((newtemp (+ 99 x (random 0.04) -.02)))
(setf (temp *motor1*) newtemp))))
Результат:
0> motor temperature changing from NIL :TO 0
0> motor temperature changing from 0 :TO 98.99401
0> motor temperature changing from 98.99401 :TO 99.01954
[snipped 8 intermediate readings]
0> motor temperature changing from 99.00016 :TO 100.00181
0> motor status changing from :ON :TO :OFF
0> motor fuel-pump changing from :OPEN :TO :CLOSED
0> motor temperature changing from 100.00181 :TO 100.0177
0> motor temperature changing from 100.0177 :TO 99.98742
0> motor temperature changing from 99.98742 :TO 99.99313
[snipped 6 intermediate readings]
>Полный core Lispworks в архиве около 5 метров получается, Corman Lisp - около трех. Если выкидывать компилятор, eval, а также неиспользуемые функции, то на практических приложениях EXE для Lispworks ужимается до 1.5М в архиве, Corman Lisp до 2-х метров добивал.
Ситуации с коммерческими CL-ями я не знал. Это хорошо. Я обязательно взгляну.
>Так что при современных линиях связи это даже для Shareware уже не проблема. SBCL конечно толст, но для серьезных приложений это тоже не проблема, подумаешь какие-то 50 метров, даже в смартфон влезет запросто ;-) Если семейство приложений распространять, то одно ядро можно как .NET Runtime прикладывать один раз на все, уже экономия получится.
Ну если говорить о sbcl, то ядро 25 метров. Это я еще с MCCLIM посчитал. Да вся проблема в том, что вот не шарится ядро sbcl между приложениями. Каждое приложение сейчас с ним должно быть собрано. Как запустить одновременно несколько приложений, используя одно ядро, как runtime, я ума не приложу (пока). Просто этим вопросом не занимался. Сейчас все больше математику смотрю. Как-то временно отошел от вопросов инфраструктуры и графических интерфейсов, как второстепенных.
Для серьезных приложений действительно получится, что большая часть развитых возможностей CL, которые не нужны для hello world, но есть в core окажутся задействованными.
Ты так написал, будто кто-то сразу поймет, что такое CELLS. Тут надо разъяснять. В чужеродные вещи мало, кто погружается.
CELLS -- это такая надстройка над CLOS, но с таким функционалом, что позволяет делать вычисляемые слоты. Создаешь объект, у которого есть набор слотов (тут температура, статус (датчика?) и состояние нагнетателя топлива (on/off)). А потом определяются правила (rules) для экземпляра этого объекта "мотор1" от внешних воздействий. Когда температура датчика переваливает за 100, то датчик сообщает статус off, а когда меньше 100, то -- on. А в самом объекте "мотор" написано, что если status (наверное, датчика) перескочил в в cостояние on, то fuel-bump открывается. И, наоборот, если off, то закрывается. А дальше в (dotimes...) запускается некая модель внешних воздействий на систему, состоящую из объекта "мотор1". В данном случае игра температурой. В результате -- лог поведения системы.
Пример классической объектной rule-based системы. Такие в большом количестве создавались в рамках экспертных систем. Cells наглядный пример, как это изящно и красиво делается на LISP. Отлично подходит для всяких симуляций и т. п.
Очень интересно и для интерфейсов, поэтому Cells-Gtk очень интересная вещь получается. Если задать поведение какого-то чекбокса правилами от того, что происходит снаружи, то он при происхождении событий будет включаться или выключаться сам. Ну то есть получается интерфейс, построенный на правилах.
А, ну еще и диапазон нечувствительности к колебаниям 0.05 градуса задан, чтобы слабые случайные колебания температуры вокруг отметки 100 не переключали fuel-bump.
Сообщение удалено redvasily по причине '3.1 Дубль'
Ответ на: Re: Фраза о Лиспе... от anonymous 10.10.2006 1:46:33
Re: Фраза о Лиспе...
Был уже апдейт:
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
yield p[:i] + [e[0]] + p[i:]
А по поводу похожести на английский:
1. Не припомню в английском слова "cons"
2. Слова в лиспе английские, но вот предложений как-то не образуется.
Или Йода мастер лиспе сказал это на?
3. Надо поменять опрос, сменить его на какая из этих программ более
читаемая?
4. COBOL ваще от английского не отличить. И что?
Был уже апдейт:
def permutations(e):
if not e:
yield []
else:
for p in permutations(e[1:]):
for i in xrange(len(e)):
yield p[:i] + [e[0]] + p[i:]
А по поводу похожести на английский:
1. Не припомню в английском слова "cons"
2. Слова в лиспе английские, но вот предложений как-то не образуется.
Или Йода мастер лиспе сказал это на?
3. Надо поменять опрос, сменить его на: "какая из этих программ более
читаемая?"
4. COBOL ваще от английского не отличить. И что?
> Когда-нибудь придет человек и скажет: "А если я не хочу делать программу в виде огромного core? А также не хочу отдавать программу в fasl, так как они очень медленно загружаются?"
В сад! А если он ещ попросит охрененный портал на php 10-летней давности? "Хочу/не хочу" - не "катит". Будут обоснованные ТУ, в которые данная схема не вписывается - будем думать ;) И таки fasl не так уж и медленно загружаются.
> А еще пока нет fasl-совместимости между разными версиями SBCL. поэтому при каждом обновлении все компилируется заново. Вот такие вот в этом плане недостатки есть.
...и в ближайшем будущем не планируется. Это как откомпилированные модули от одного ядра к другому ;)
"Пример на Лиспе IMHO больше смахивает на английский язык."
Ты слово _больше_ видишь? А смысл понимаешь? Он в том, что "код на лиспе больше смахивает на английский язык чем код на питоне". Или ты будешь доказывать, что код на питоне похож на английский больше?
А о том, что лисп таки отличается от английского - так это ты пальцем в небо ;)
Шутка, повторенная дважды, причем неуместно... причем очень старая шутка
> Или ты будешь доказывать, что код на питоне похож на английский больше?
Вообще-то это не надо доказывать - это очевидно. По крайней мере в обновленной Питоньей версии меньше не-слов (это "def" и "xrange"), не говоря уже о том, что синтаксис ближе к естественному языку.
> А о том, что лисп таки отличается от английского - так это ты пальцем в небо ;)
ЕМНИП, "попасть пальцем в небо" - это значит "сильно ошиьится". Ты хочешь сказать, что лисп _не_ отличается от английского? :-O
> > Именно в последнее время проснулся интерес к интерпретируемым/байткодным.
> Мне всегда казалось ошибкой на грани слабоумия то, что в них выделяют именно эту черту.
Ну, собственно, фишка с ними, имхо, в "запускаемом исходнике". Т.е. нету выделенного (интерфейсно) этапа компиляции => упрощается цикл разработки. И с поддержкой/внедрением проще - можно "править по живому", если надо, не парясь со сборкой. И переносимость, все же, выше - я одну и ту же перловую программу пускаю линуксе/amd64 и freebsd/x86, и даже могу делать вещи типа
open F, '| ssh runner\@other_os perl > local_result.txt');
Ну, в интересах поддержки захиревшего флейма и доведения числа постов до 1024: а почему библиотекописатели не лабают к своим либам биндинги к Lisp? Вот я хочу поставить Ogre3d "на поиграться", а у него нет биндингов к Лисп! :-P А к Питону - есть ;) Где вообще SWIG для Lisp?
2Zubok
> CELLS -- это такая надстройка над CLOS, но с таким функционалом, что позволяет делать вычисляемые слоты.
Ты, наверное, не вс говоришь. В чем проблема сделать вычисляемый слот средствами самого CLOS, зачем там еще и надстройка?
> Пример классической объектной rule-based системы.
Ну, не знаю. Как-то просто, непонятно, зачем аж целая надстройка. И где Rete? ;)
Кстати, раз уж речь зашла об ИИ и rule-based... Нет ли у тебя каких-либо ссылок на материалы о сабжах? Я когда-то этим тоже интересовался (через них и с Лисп познакомился), но текущего положения дел ни с теорией, ни с инструментарием не знаю.
> а почему библиотекописатели не лабают к своим либам биндинги к Lisp?
"Элементарно..." - по причине недостаточно широкой распространнности лиспа для возникновения интереса к клепанию биндингов. И, имхо, скорее комьюнити языка должно "клепать биндинги" к либам, нежели производители самх либ.
> Где вообще SWIG для Lisp?
А что, его уже из SWIG-a выкинули?.. 8-О :)
> В чем проблема сделать вычисляемый слот средствами самого CLOS, зачем там еще и надстройка?
Чтобы ты не заморачивался с этим каждый рах сам, а взял котовый пакет :)
>> > Именно в последнее время проснулся интерес к интерпретируемым/байткодным.
>> Мне всегда казалось ошибкой на грани слабоумия то, что в них выделяют именно эту черту.
>Ну, собственно, фишка с ними, имхо, в "запускаемом исходнике". Т.е. нету выделенного (интерфейсно) этапа компиляции
Ты сказал "интерпретируемый" другими словами :-P
По-моему, фишка именно в более высоком уровне при больше простоте использования - там, где на Си++ (тем более Java) нужна нудная писанина, на Питон/Ruby всего пара строк
> Ты сказал "интерпретируемый" другими словами :-P
Отсутствие _выделенного (интерфейсно) этапа компиляции_ не означает отсутствие компиляции (в натив) вообще. А это уже к интерпретируемым не относиться (имхо)
> По-моему, фишка именно в более высоком уровне при больше простоте использования - там, где на Си++ (тем более Java) нужна нудная писанина, на Питон/Ruby всего пара строк
Так было уже - с лиспом имеем и простоту использования, и компиляцию в натив (инкрементальную), да - в некоторых реализациях.
> В SWIG у меня на машине - 2 диалекта Scheme: Guile и какой-то MzScheme. Ни одного из многочисленных Common Lisp'ов :-P
Что-то у тебя не так... И даже упоминания о cffi и uffi нет? Обновись ;)
> Не согласен ни разу. Биндинг - вещь тонкая, требует понимания внутренней механики либы. Кому, как не авторам, это знать?
Нафига "внутренняя механика либы" - достаточно (должно быть) доки и описания интерфейса. А вот "тонкости" уже надо знать со стороны языка, дабы влить в него либу наилучшим образом. В противном случае производителю либы надо как свою либу знать все языки, к которым он собирается делать биндинги
> > Воот, но волну интереса к динамическим и функциональным языкам подняли Python и Ruby :-P
> Угу, это сродни "научно-популярной литературе" :)
Хотя нисколько не умаляю их вклада в это дело - сам пришл к лиспу "через"питон :) Надо лишь отдать себе отчт, что это не "венец творения", а робкая попытка приблизиться ;)Ь
>> В SWIG у меня на машине - 2 диалекта Scheme: Guile и какой-то MzScheme. Ни одного из многочисленных Common Lisp'ов :-P
> Что-то у тебя не так... И даже упоминания о cffi и uffi нет? Обновись ;)
А у тебя есть такое? Какая версия SWIG?
> Нафига "внутренняя механика либы" - достаточно (должно быть) доки и описания интерфейса.
"Теоретически, теория и практика - одно и то же. Практически они разные." (C) незнаюкто. А если учесть, что дока может быть неадекватно (или ее может не быть)...