Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 161
клёво
Если будем обсуждать, отгружу свои пять копеек.
ИМХО, преувеличение, вызванное недостаточным знанием других языков программирования. Конечно, встроенный в язык AST, списки и сборщик мусора это хорошо — но это не какое-то фатальное преимущество. Большую группу задач можно решить на LISP более коротким кодом, нежели на C — но, основываясь на своем опыте, не могу сказать что там будет разница как между пинцетом и вакуумной пушкой. Ну будет
Еще более спорное утверждение. ИМХО, единственное отличие современного C++ от Lisp в плане встроенных в язык функций — это отсутствие доступа к AST. Но, как показывает практика, это не очень часто и надо. И те задачи, для которых это надо, вполне себе решаются другими способами.
Могу предположить, что автор статьи, как и многие другие, рассматривает программирование исключительно в разрезе решения академических задач — технически простые программы, которые занимаются математическими рассчетами. Область, конечно, хорошая — но, ИМХО, очень нишевая.
И тут на сцену выходит Lisp. Lisp для ума, как рычаг для руки. Он увеличивает вашу силу и делает возможным работу над проектами, которые за пределами возможностей таких языков как C. Писать на C — это как собирать мозаику из чечевицы используя пинцет и клей. Lisp — это как обладать пневматическим оружием, сильным и точным. Он открывает целые миры, недоступные другим разработчикам.
ИМХО, преувеличение, вызванное недостаточным знанием других языков программирования. Конечно, встроенный в язык AST, списки и сборщик мусора это хорошо — но это не какое-то фатальное преимущество. Большую группу задач можно решить на LISP более коротким кодом, нежели на C — но, основываясь на своем опыте, не могу сказать что там будет разница как между пинцетом и вакуумной пушкой. Ну будет
(append list1 list2)вместо какого-нибудь
apr_list_add( list1, list2 )Это не настолько большое преимущество, как кажется на первый взгляд. ИМХО.
Подход C/C++ совсем другой. Так трудно сделать что-нибудь с пинцетом и клеем, что любой результат является достижением. Тебе хочется это задокументировать. Тебе придется искать помощи, для более-менее больших проектов. Нужно быть социальным, и работать с другими если хочешь чего-то достичь.
Еще более спорное утверждение. ИМХО, единственное отличие современного C++ от Lisp в плане встроенных в язык функций — это отсутствие доступа к AST. Но, как показывает практика, это не очень часто и надо. И те задачи, для которых это надо, вполне себе решаются другими способами.
Могу предположить, что автор статьи, как и многие другие, рассматривает программирование исключительно в разрезе решения академических задач — технически простые программы, которые занимаются математическими рассчетами. Область, конечно, хорошая — но, ИМХО, очень нишевая.
> ИМХО, преувеличение, вызванное недостаточным
> знанием других языков программирования
А у вас кажется не хватает знаний о CL ))
> динственное отличие современного C++ от Lisp в плане встроенных в язык
> функций — это отсутствие доступа к AST.
Ну что вы такое говорите. Как насчёт мультиметодов, рестартов, динамических переменных, MOP? Поверьте, разница огромна.
> знанием других языков программирования
А у вас кажется не хватает знаний о CL ))
> динственное отличие современного C++ от Lisp в плане встроенных в язык
> функций — это отсутствие доступа к AST.
Ну что вы такое говорите. Как насчёт мультиметодов, рестартов, динамических переменных, MOP? Поверьте, разница огромна.
А у вас кажется не хватает знаний о CL ))
Все может быть, на звание гуру не претендую.
Как насчёт мультиметодов
Большинство практических применений мультиметодов в C++ решаются шаблонами. Да, compile time вместо runtime — но с точки зрения кода какая разница?
рестартов
В каком контексте? Если для контроля ошибок и отладки, то как бы в C++ есть исключения.
динамических переменных
Если очень надо, то есть QVariant / boost::variant
MOP
Qt signals and slots / boost::signal?
Поверьте, разница огромна.
Я с этим и не спорю. Трудно спорить с тем, что один язык полностью динамический со сборщиком мусоры и открытым AST, а в другом большинство вещей делается на этапе компиляции. Но практика показывает, что для большинства прикладных задач это не так уж и важно :(. Что для прикладных задач важно? Удобная работа с объектами, набор контейнеров и алгоритмов, потоки, хороший набор библиотек, удобные макроархитектурные механизмы позднего связывания. А то, что в Ruby есть method missing — ну да, клево конечно, DSL писать так же удобно как на LISP — но это нишевая функциональность. А мейнстрим для прикладного ПО — одинаковые как братья-близнецы C++, Java и C# O_O.
>> динамических переменных
> Если очень надо, то есть QVariant / boost::variant
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
> Если очень надо, то есть QVariant / boost::variant
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Сори, ответ сорвался (
> Большинство практических применений мультиметодов
> в C++ решаются шаблонам
Нет. Нормальной реализации мультиметодов для С++ даже Александреску не смог сделать.
> Если для контроля ошибок и отладки, то как бы в C++ есть исключения.
Рестарты намного круче исключений.
>> динамических переменных
> Если очень надо, то есть QVariant / boost::variant
Это вообще не из той области.
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Я больше 7 лет писал C++ и около 3 на Python, плюс были ещё разные другие языки в меньших масштабах. Сейчас я пишу только на двух — JavaScript и Common Lisp. И по моим ощущения преимущества CL совершенно не оспоримые.
> DSL писать так же удобно как на LISP
А при чём тут DSL?
> Большинство практических применений мультиметодов
> в C++ решаются шаблонам
Нет. Нормальной реализации мультиметодов для С++ даже Александреску не смог сделать.
> Если для контроля ошибок и отладки, то как бы в C++ есть исключения.
Рестарты намного круче исключений.
>> динамических переменных
> Если очень надо, то есть QVariant / boost::variant
Это вообще не из той области.
> Но практика показывает, что для большинства прикладных
> задач это не так уж и важно :(.
Я больше 7 лет писал C++ и около 3 на Python, плюс были ещё разные другие языки в меньших масштабах. Сейчас я пишу только на двух — JavaScript и Common Lisp. И по моим ощущения преимущества CL совершенно не оспоримые.
> DSL писать так же удобно как на LISP
А при чём тут DSL?
Нет. Нормальной реализации мультиметодов для С++ даже Александреску не смог сделать
Так я и не говорю, что шаблонами полностью эмулируется лисп. Но для решения практических задач-то хватает? Обратите внимание, я не говорю что C++ полностью покрывает функциональность лисп. Я говорю о том, что сравнение автора статьи «пинцета и вакуумной пушки» как бы сильно преувеличено. На, без доступа к AST мультиметоды в том объеме что и в лиспе в C++ не будет. Но того, что можно реализовать сравнимым объемом кода с помощью шаблонов хватает для большинства практических задач.
динамических переменных
Если очень надо, то есть QVariant / boost::variant
Это вообще не из той области.
Русские термины вижу в первый раз, поэтому давайте уточним — под «динамическими переменными» вы имеете в виду
(setf var 1) (setf var "text")
или
(defvar *var* 10)
Если второе, то как бы глобальные переменные, thread local переменные и синглтоны к вашим услугам. И, опять же, это не полный аналог — но полностью подходящий для решения большинства практических задач.
Я больше 7 лет писал C++ и около 3 на Python, плюс были ещё разные другие языки в меньших масштабах. Сейчас я пишу только на двух — JavaScript и Common Lisp. И по моим ощущения преимущества CL совершенно не оспоримые.
У меня по C++ и питону немного побольше, но особого желания использовать лисп пока нету :(. Видимо, у нас с вами совсем разные области? Я вот коробочными продуктами для конечных пользователей занимаюсь :). А вы, если я правильно понимаю, веб сервисами? Для веб сервисов C++ как бы не очень, это общеизвестный факт. Там руби, питон, лисп и прочая сильная динамика живет — вполне естественная специализация для нишевых задач.
А при чём тут DSL?
Это был пример специфического применения редкоземельного синтаксиса Ruby в разрезе method missing. Видимо, неудачный :).
> Но для решения практических задач-то хватает?
Отвечу только на это (не хочу сильно увлекаться дискуссией) — нет. То, что в CL делается легко и изящно в С++ приходится решать через боль и мучения. Вообще, аргументация про то, что «хватает», она ущербна по своей сути. Хватает для всех зада и ассемблера, ведь все языки тьюринг-полные.
На эту тему могу порекомендовать вот эту статью: www.nestor.minsk.by/sr/2003/07/30710.html, там где про парадокса Блаба.
Отвечу только на это (не хочу сильно увлекаться дискуссией) — нет. То, что в CL делается легко и изящно в С++ приходится решать через боль и мучения. Вообще, аргументация про то, что «хватает», она ущербна по своей сути. Хватает для всех зада и ассемблера, ведь все языки тьюринг-полные.
На эту тему могу порекомендовать вот эту статью: www.nestor.minsk.by/sr/2003/07/30710.html, там где про парадокса Блаба.
Вы, как сторонник CLisp, должны были видеть статьи Стива Егга на эту тему. Вспомните его же сравнение этого языка с Ходячим Замком Хоула :)
Язык большой, огромный, невероятно гибкий… И я это отлично понимаю как емаксер, лиспер, еще в универе в качестве хобби изучал разные языки, больше всего — функциональные.
Но… Гибкость и многогранность — это проблема. Средства должны быть а) ограниченные б) простые в) универсальные. Иначе в больших проектах программисты просто-напросто перестают понимать друг друга.
Я согласен с вами в том смысле, что богаче и выразительней Лиспа языков нет. Однако же, уверен, что вы все эти цветастые средства не используете в работе. Если вообще работаете с этим языком на дневной работе!
С другой стороны, ваш оппонент, нахваливая гибкость С++ на примере boost замалчивает тот факт, что boost не только не входит в сам язык, но и изрядно усложняет и без того непростую базу. А уродливые макросы… А незабвенные извращения Александреску… И приличные программисты очень, о-о-о-очень, ОЧЕНЬ аккуратно ко всему этому относятся.
Язык большой, огромный, невероятно гибкий… И я это отлично понимаю как емаксер, лиспер, еще в универе в качестве хобби изучал разные языки, больше всего — функциональные.
Но… Гибкость и многогранность — это проблема. Средства должны быть а) ограниченные б) простые в) универсальные. Иначе в больших проектах программисты просто-напросто перестают понимать друг друга.
Я согласен с вами в том смысле, что богаче и выразительней Лиспа языков нет. Однако же, уверен, что вы все эти цветастые средства не используете в работе. Если вообще работаете с этим языком на дневной работе!
С другой стороны, ваш оппонент, нахваливая гибкость С++ на примере boost замалчивает тот факт, что boost не только не входит в сам язык, но и изрядно усложняет и без того непростую базу. А уродливые макросы… А незабвенные извращения Александреску… И приличные программисты очень, о-о-о-очень, ОЧЕНЬ аккуратно ко всему этому относятся.
> Если вообще работаете с этим языком на дневной работе!
Если бы не работал, то вообще бы ничего не говорил на эту тему.
Если бы не работал, то вообще бы ничего не говорил на эту тему.
С другой стороны, ваш оппонент, нахваливая гибкость С++ на примере boost замалчивает тот факт, что boost не только не входит в сам язык, но и изрядно усложняет и без того непростую базу
Тут попрошу. В lisp как в язык кроме car и cdr вообще мало что входит :). CLOS и прочие радости жизни — это уже как бы «библиотеки», нэ? Которые будут разные в common lisp, emacs lisp, autocad lisp, iron bank что-то-там lisp и прочих.
Язык, на мой взгляд, имеет смысл рассматривать вместе с экосистемой. Библиотеки, приемы работы, средства разработки и отладки, поддерживаемые операционные системы — все это очень сильно влияет на популярность языка для разных задач.
> В lisp как в язык кроме car и cdr вообще мало что входит :).
Так было 50 лет назад.
> CLOS и прочие радости жизни — это уже как бы «библиотеки», нэ?
Нет.
> Которые будут разные в common lisp, emacs lisp, autocad lisp, iron bank что-то-там
> lisp и прочих
Разные лиспы очень сильно между собой отличаются, схожесть между ними в основном за счёт «скобочек», да старых унаследованных команда. Они похожи между собой не больше, чем C/C++/Java/C#.
Так было 50 лет назад.
> CLOS и прочие радости жизни — это уже как бы «библиотеки», нэ?
Нет.
> Которые будут разные в common lisp, emacs lisp, autocad lisp, iron bank что-то-там
> lisp и прочих
Разные лиспы очень сильно между собой отличаются, схожесть между ними в основном за счёт «скобочек», да старых унаследованных команда. Они похожи между собой не больше, чем C/C++/Java/C#.
Вы даже не представляете, на сколько я признателен за ссылку!
PS
В статье используется понятие «мощности» языка. Из всего, о чем я слышал самым мощным был Форт. Неужели Лисп мощнее?
PS
В статье используется понятие «мощности» языка. Из всего, о чем я слышал самым мощным был Форт. Неужели Лисп мощнее?
Думаю да, я попробовал форт и лисп и остановился на лиспе.
Во-первых вам респект, не ожидал что так быстро найдется человек пробовавший оба эти языка.
Во-вторых это просто невероятно! Если уж Форт со своей гибкостью, изумительной встраиваемостью, возможностями интерпретации/компиляции и расширения на лету оказывается под вопросом, то следующий проект буду делать на Лиспе.
Кстати, что бы вы посоветовали CL или Clojure?
Во-вторых это просто невероятно! Если уж Форт со своей гибкостью, изумительной встраиваемостью, возможностями интерпретации/компиляции и расширения на лету оказывается под вопросом, то следующий проект буду делать на Лиспе.
Кстати, что бы вы посоветовали CL или Clojure?
CL
Попробуйте scheme 8)
а что если устроить такой поединок:
eyeofhell выбирает для него типичную задачу, даже не задачу а приложение или часть приложения, но чтобы там присутствовала бизнес логика, а не просто алгоритм. Строк так на 1000. Делает реализацию.
А господин archimag, реализует ту же задачу уже на common lisp.
код обнародуем и каждый для себя сделает вывод: действительно в lisp делается все легко и изящно или его возожности несколько преувеличены
eyeofhell выбирает для него типичную задачу, даже не задачу а приложение или часть приложения, но чтобы там присутствовала бизнес логика, а не просто алгоритм. Строк так на 1000. Делает реализацию.
А господин archimag, реализует ту же задачу уже на common lisp.
код обнародуем и каждый для себя сделает вывод: действительно в lisp делается все легко и изящно или его возожности несколько преувеличены
Согласен.
Моя специализация: desktop, end-user applications, user interface, network. Язык возьму C++ с Qt — тут у меня более десяти лет опыта.
Предлагаю что-нибудь простое, задевающее несколько типичных областей. Например, GUI приложение, которое позволяет ввести веб адрес, по нажатию на кнопку подключается к указанному компьютеру, забирает что отдают и выводит скролящийся список HTML тэгов, где каждый элемент — строка вида «наименование тега — его количество». С сортировкой либо по имени, либо по количеству.
Моя специализация: desktop, end-user applications, user interface, network. Язык возьму C++ с Qt — тут у меня более десяти лет опыта.
Предлагаю что-нибудь простое, задевающее несколько типичных областей. Например, GUI приложение, которое позволяет ввести веб адрес, по нажатию на кнопку подключается к указанному компьютеру, забирает что отдают и выводит скролящийся список HTML тэгов, где каждый элемент — строка вида «наименование тега — его количество». С сортировкой либо по имени, либо по количеству.
> Предлагаю что-нибудь простое
Ну что-то вы совсем просто предложили ))
Ну что-то вы совсем просто предложили ))
Ну я как бы не хочу на написание, отладку и комментирование тратить больше нескольких часов. Мне семью кормить надо.
> Ну я как бы не хочу на написание, отладку и комментирование тратить
> больше нескольких часов.
Я вас умаляю, вот код, который считает колличество разных тэгов на этой странице:
> больше нескольких часов.
Я вас умаляю, вот код, который считает колличество разных тэгов на этой странице:
(html:with-parse-html (doc #U"http://habrahabr.ru/blogs/lisp/114981/")
(let ((map (make-hash-table :test 'equal)))
(iter (for node in-xpath-result "//*" on doc)
(incf (gethash (xtree:local-name node) map 0)))
map))Угу. А если страницу загрузить не получилось — возвращает ошибку :). Так я тоже могу:
Увы, ни тот ни другой код не показывает как язык решает прикладные, а не академически-однострочные задачи. Демонстрация пользователю ожидания загрузки? реакция на ошибку? взаимодействие частей программы друг с другом и с GUI? Обработка ожидаемых ошибок? Обработка unexpected ошибок? Perl или bash ту же задачу решат в одну строку и куда меньшее количество символов. Но разве это делает их лучшими языками общего назначения? :)
QWebView web;
web.load( QUrl( "http://habrahabr.ru/blogs/lisp/114981/" ) );
QEventLoop waiter;
connect( & web, SIGNAL(loadFinished(bool)), & waiter, SLOT(quit()) );
waiter.exec();
QMap< QString, int > results;
waiter.exec()
foreach( QWebElement item, web.page()->mainFrame()->findAllElements("*") )
{
results[ item.tagName() ] ++;
}
Увы, ни тот ни другой код не показывает как язык решает прикладные, а не академически-однострочные задачи. Демонстрация пользователю ожидания загрузки? реакция на ошибку? взаимодействие частей программы друг с другом и с GUI? Обработка ожидаемых ошибок? Обработка unexpected ошибок? Perl или bash ту же задачу решат в одну строку и куда меньшее количество символов. Но разве это делает их лучшими языками общего назначения? :)
Здесь что на C++, что на CL по порядку повызывать библиотеки и вывести результат в окно. Придумайте что-нибудь, оценивающее язык.
Хотя и с этой задачей проблем не возникнет, но тов. Архимаг не любит специальные олимпиады.
Хотя и с этой задачей проблем не возникнет, но тов. Архимаг не любит специальные олимпиады.
В сравнение (С++)QT и CL бесспорно победит CL.
Потому что код на CL гораздо легче читается и быстрее пишется, и легко отлаживается.
А сравнивать батарейки (в контексте какой язык «лучше») a не семантику языка ИМХО глупо.
Если у вас есть батарейка к асемблеру которая разгадывает гугло капчу. А к javascript у вас такой батареи нету, тогда ассемблер вырулит у java script.
Если и стоит сравнивать батарейки то надо сравнивать на каком языке вы эффективнее напишите батарейку, или сравнивать исходники уже написанных батареек.
Батарейку если ее нету всегда кто-то может написать, и тогда выруливает только семантика конкретного языка под конкретную задачу.
Потому что код на CL гораздо легче читается и быстрее пишется, и легко отлаживается.
А сравнивать батарейки (в контексте какой язык «лучше») a не семантику языка ИМХО глупо.
Если у вас есть батарейка к асемблеру которая разгадывает гугло капчу. А к javascript у вас такой батареи нету, тогда ассемблер вырулит у java script.
Если и стоит сравнивать батарейки то надо сравнивать на каком языке вы эффективнее напишите батарейку, или сравнивать исходники уже написанных батареек.
Батарейку если ее нету всегда кто-то может написать, и тогда выруливает только семантика конкретного языка под конкретную задачу.
Динамический язык при реализации академичкской задач (вида «отсортируйте массив») как правило помеждает не динамический. Семантика языка как таковая в CL отсутствует — там есть только списки и операции над ними :). У него вообще очень простая база/ Все навороты — CLOS, globals, dispatch — это операции над списками.
Соответственно любое сравнение будет синтаксиса языка C++ и библиотек (Qt) с «библиотеками» LISP (операциями над списками).
На мой взгляд, имеет смысл сравнивать как раз как решаются практические задачи с разбиением программы на модули, использованием GUI, многопоточности и сетки. Тогда будет видно, как происходит взаимодействия языка и библиотек для достижения результата.
Соответственно любое сравнение будет синтаксиса языка C++ и библиотек (Qt) с «библиотеками» LISP (операциями над списками).
На мой взгляд, имеет смысл сравнивать как раз как решаются практические задачи с разбиением программы на модули, использованием GUI, многопоточности и сетки. Тогда будет видно, как происходит взаимодействия языка и библиотек для достижения результата.
> Все навороты — CLOS, globals, dispatch — это операции над списками.
Ну что за невежество.
Ну что за невежество.
Мда, я думал интереснее будет, чего нового про лисп узнаю. Но аргументы как обычно — «да ти праграмиравать сам ни умииш и ничаво не знаиш!!!» :(. Посмотрите ради интереса создание класса на plain c, на common lisp и на c++. Ничего не напоминает?
int PointClass = class_new( pool );
(defclass PointClass () (slot))
class PointClass {};
> Мда, я думал интереснее будет, чего нового про лисп узнаю
> «да ти праграмиравать сам ни умииш и ничаво не знаиш!!!»
Я не знаю, чего у вас там за обычная аргументация, но говорить, что в лисп есть только списки списки, а всё остальное это операции над списками, это абсолютно полное невежество. Так было 50 лет назад. С тех пор лисп очень сильно изменился.
> Посмотрите ради интереса создание класса на plain c, на common lisp
> и на c++.
Где в этом коде вы увидели создание класса на plain C? Когда он создаёт объект?
> Ничего не напоминает?
Определение класса? о_О
> «да ти праграмиравать сам ни умииш и ничаво не знаиш!!!»
Я не знаю, чего у вас там за обычная аргументация, но говорить, что в лисп есть только списки списки, а всё остальное это операции над списками, это абсолютно полное невежество. Так было 50 лет назад. С тех пор лисп очень сильно изменился.
> Посмотрите ради интереса создание класса на plain c, на common lisp
> и на c++.
Где в этом коде вы увидели создание класса на plain C? Когда он создаёт объект?
> Ничего не напоминает?
Определение класса? о_О
но говорить, что в лисп есть только списки списки, а всё остальное это операции над списками, это абсолютно полное невежество. Так было 50 лет назад. С тех пор лисп очень сильно изменился.
Еще раз посмотрел табличку hyperpolyglot.org/lisp
Ну где вы там нашли элементы, отличные от операций над списками? Звездочку? :(. Насколько я помню, LISP (как и C++) как раз и отличался тем, что расширял себя сам, «вводя новые ключевые слова» через задание новых операций над списками. C++ делал то же самое через задание новых библиотечных классов. И тут мне неожиданно говорят, что де за 50 лет все изменилось и CL теперь имеет столько же синтаксического сахара, сколько Ruby. И что внутри там появилось что-то, отличное от списокв.
Вы бы показали, чтоли, старику новые веяния. А то как-то не верится в собственное невежество и вашу избранность :).
> И что внутри там появилось что-то, отличное от списокв.
Структуры, массивы, хэш-таблицы, FFI. Посмотрите ассембленый код, который генерирует SBCL. Списки используются для синтаксиса и являются часто используемым типом данных, но не более того.
> что расширял себя сам, «вводя новые ключевые слова» через
> задание новых операций над списками
У вас всё в голове перемешалось.
Структуры, массивы, хэш-таблицы, FFI. Посмотрите ассембленый код, который генерирует SBCL. Списки используются для синтаксиса и являются часто используемым типом данных, но не более того.
> что расширял себя сам, «вводя новые ключевые слова» через
> задание новых операций над списками
У вас всё в голове перемешалось.
Структуры, массивы, хэш-таблицы, FFI
Тоесть то, что Common Lisp Extensions для emacs реализует структуры, массивы и хэш таблицы один в один используя только операции над списками вас не смущает?
И что такое FFI? Если Foreign Function Interface — то какое он имеет отношение к синтаксису языка? Это вообще библиотека которая везде реализована, даже в питоне.
> Тоесть то, что Common Lisp Extensions для emacs реализует структуры, массивы и хэш таблицы один в один используя только операции над списками вас не смущает?
А вот GObject для C реализует ООП используя только структуры и макросы. Значит в C++ ничего не изменилось за 35 с лишним лет. Всё по прежнему ворочаем байтами используя адреса, указатели и смещения и никаких классов так и не появилось.
А вот GObject для C реализует ООП используя только структуры и макросы. Значит в C++ ничего не изменилось за 35 с лишним лет. Всё по прежнему ворочаем байтами используя адреса, указатели и смещения и никаких классов так и не появилось.
Вы совершенно напрасно сравниваете C и C++ — это еще более разные языки, чем Common Lisp и Scheme.
BTW, вы во многом правы. Классы в C++ эволюционно развились из структур в C. Но при этом добавились две важные вещи:
1. Поддержка синтаксиса. Методы, поля, защита, наследование, полиморфизм, шаблоны — все это реализовано на уровне синтаксиса.
2. Внутренняя реализация таких вещей как полиморфизма времени исполнения и определения типа объекта.
А так да. Любую концепцию C++ можно реализовать на C, прсто большим количеством кода. Что несколько коррелирует с моей позицией о том, что Lisp это не такой уж wanderwaffe как его показывает автор статьи :)
BTW, вы во многом правы. Классы в C++ эволюционно развились из структур в C. Но при этом добавились две важные вещи:
1. Поддержка синтаксиса. Методы, поля, защита, наследование, полиморфизм, шаблоны — все это реализовано на уровне синтаксиса.
2. Внутренняя реализация таких вещей как полиморфизма времени исполнения и определения типа объекта.
А так да. Любую концепцию C++ можно реализовать на C, прсто большим количеством кода. Что несколько коррелирует с моей позицией о том, что Lisp это не такой уж wanderwaffe как его показывает автор статьи :)
> Вы совершенно напрасно сравниваете C и C++ — это еще более разные языки, чем Common Lisp и Scheme.
Серьёзно?
> все это реализовано на уровне синтаксиса.
При чём тут синтаксис?
> А так да. Любую концепцию C++ можно реализовать на C, прсто большим количеством кода.
Архимаг выше уже говорил что всё можно реализовать и на Ассемблере только большим количеством кода, ибо Тьюринг-полнота.
> Что несколько коррелирует с моей позицией о том, что Lisp это не такой уж wanderwaffe как его показывает автор статьи :)
wanderwaffe не существует и автор ни одной показать не пытался.
Серьёзно?
> все это реализовано на уровне синтаксиса.
При чём тут синтаксис?
> А так да. Любую концепцию C++ можно реализовать на C, прсто большим количеством кода.
Архимаг выше уже говорил что всё можно реализовать и на Ассемблере только большим количеством кода, ибо Тьюринг-полнота.
> Что несколько коррелирует с моей позицией о том, что Lisp это не такой уж wanderwaffe как его показывает автор статьи :)
wanderwaffe не существует и автор ни одной показать не пытался.
Конкурс забавный, но там академические задачи на написание алгоритмов. Это очень малая толика того, что делается программистами :). Хотя, пожалуй, самая интересная.
BTW, там первые места заняли C# и Visual Basic :)
BTW, там первые места заняли C# и Visual Basic :)
Задачи как раз таки пытались быть приближенными к реальности, не слишком тривиальные и не слишком объемные.
Попытаюсь переформулировать — это задачи на написание алгоритмов. К сожалению, если посмотреть на типичные задачи, решаемые большинством разработчиков (веб, десктоп, автоматизация), то количество как раз алгоритмов там стремится к нулю :(. Для большинства задач уже есть готовые решения. Основная масса кода — это GUI, простая обработка данных, взаимодействие с базой данных.
В достаточно сложной системе NAT пенетрации, архитектурой которой я занимался недавно, был всего один алгоритм, который вывелся на доске за два часа и реализовался в двадцать строк кода :(. Все остальное — работа с логикой и данными — потоки, сокеты, протоколы, взаимодействие модулей и так далее. И этого всего остального там KLOC под 100. Включая серверные компоненты, развертывание, тесты и биндинги. И 20 строк алгоритма O_O.
И это была сложная задача. Про текучку вида «Advanced IP Scanner» я молчу, там вообще алгоритмов нет.
Смысл делать конкурс, где вся мощь языка применяется к задаче, которая крайне редка в прикладном (не академическом/спортивном) программировании?
В достаточно сложной системе NAT пенетрации, архитектурой которой я занимался недавно, был всего один алгоритм, который вывелся на доске за два часа и реализовался в двадцать строк кода :(. Все остальное — работа с логикой и данными — потоки, сокеты, протоколы, взаимодействие модулей и так далее. И этого всего остального там KLOC под 100. Включая серверные компоненты, развертывание, тесты и биндинги. И 20 строк алгоритма O_O.
И это была сложная задача. Про текучку вида «Advanced IP Scanner» я молчу, там вообще алгоритмов нет.
Смысл делать конкурс, где вся мощь языка применяется к задаче, которая крайне редка в прикладном (не академическом/спортивном) программировании?
> а что если устроить такой поединок:
Нет, спасибо, я такой ерундой не занимаюсь. Если что, то мой открытый код на CL здесь: github.com/archimag
Нет, спасибо, я такой ерундой не занимаюсь. Если что, то мой открытый код на CL здесь: github.com/archimag
> Если второе, то как бы глобальные переменные,
Нельзя поменять значение глобальной переменной только для данного конкретного execution context — в лиспе dynamic scope (к сожалению, не знаю, как это переводится все на русский язык).
> thread local переменные и синглтоны к вашим услугам. И, опять же, это не полный аналог — но полностью подходящий для решения большинства практических задач.
Нельзя поменять значение глобальной переменной только для данного конкретного execution context — в лиспе dynamic scope (к сожалению, не знаю, как это переводится все на русский язык).
> thread local переменные и синглтоны к вашим услугам. И, опять же, это не полный аналог — но полностью подходящий для решения большинства практических задач.
ИМХО, python вполне соответствует характеру «ТДС, который взялся за ум».
Троллить западло, но хотелось бы услышать от вас аргументы за лисп в гипотетическом флэйме lisp vs pyhon.
Троллить западло, но хотелось бы услышать от вас аргументы за лисп в гипотетическом флэйме lisp vs pyhon.
> lisp vs pyhon.
> Троллить западло
Я сначал писал на Python, потом познакомился с CL и перешёл на него. При чём, это было в рамках задачи, для которой я работал на Python, но в итоге процесс разработки стал слишком тяжёлым: медленный язык и нет полноценного REPL. В итоге я полностью отказался от Python в пользу CL. Вот и вся моя аргументация )
> Троллить западло
Я сначал писал на Python, потом познакомился с CL и перешёл на него. При чём, это было в рамках задачи, для которой я работал на Python, но в итоге процесс разработки стал слишком тяжёлым: медленный язык и нет полноценного REPL. В итоге я полностью отказался от Python в пользу CL. Вот и вся моя аргументация )
Вы хотите сказать, что коммьюнити Python чаще доводит проекты до конца? Возможно. Но это не исправляет недостатки языка, добровольно добавленные Ван Россумом.
Думаю, что AST (или макросы) и есть та вакуумная пушка. Мне даже удалось один раз ей стрельнуть (придумал абстракцию, которую на actionscript только криво удалось реализовать, а на лиспе легко).
Побольше бы примеров хотелось в на хабре увидеть как ей пользоваться
Побольше бы примеров хотелось в на хабре увидеть как ей пользоваться
> Думаю, что AST (или макросы) и есть та вакуумная пушка
Нет, макросы всего лишь один из элементов CL. Это делают жизнь лучше. Но даже без них CL был бы лучше больше современных языков.
Нет, макросы всего лишь один из элементов CL. Это делают жизнь лучше. Но даже без них CL был бы лучше больше современных языков.
ИМХО, это достаточно специфическая функциональность. А на практике что чаще всего нужно? Удобный GUI / доступ к файлам / потоки / библиотеки для взаимодействия со всем что движется. А как в языке в список элемент добавляется — становится уже не очень важной деталью. Главное чтобы не как в visual basic script :).
я на практике каждый раз вижу у себя повторяющийся код (специфический для этого приложения). Даже не код а абстракции во многих местах, с помощью макросов я бы смог его сократить, а так(я программирую на actionscript3) нужно размножать т.к. иначе неполучается
Ну как бы javascript он не то чтобы очень feature full ^_^. Я больше про C++ говорил. На javascript с объектами не очень хорошо, поэтому многие подходы к разработке либо не работают, либо работают не так хорошо как хотелось бы :(. В том же С++ есть десятки способов решить проблему дублирования функциональности — начиная от классов и заканчивая шаблонами и макросами.
Основное преимущество Lisp над C это то что этот язык функциональный а такие вещи которые возможны в функциональных ЯП не возможны в структурных и у вас не хватает знаний в плане основ программирования. Советую почитать SICP
Угу. То-то я читал SCIP в оригинале, программирую уже более десяти лет и в данный момент руковожу отделом по разработке софта. Конечно я программировать не умею и из языков только бейсик знаю :).
Если вы читали SICP то должны отлично понимать преимущества Scheme над C. Саарказм ваш я понимаю, но не понимаю почему вы считаете что Lisp немногим лутше C.
Если вы читали SICP то должны отлично понимать преимущества Scheme над C. Саарказм ваш я понимаю, но не понимаю почему вы считаете что Lisp немногим лутше C.
Я, видимо, не совсем ясно выразил свою позицию в комментарии. Мне по работе приходится использовать десятки языков, поэтому мне глубоко пофиг что там лучше а что хуже. Что для заачи лучше подходит и удовлетворяет критериям время-размер-поддержка — то и использую. А бейсик это или эрланг как то все равно, увы.
В чем заключается позиция. Автор оригинальной статьи утверждает, что lisp имеет глобальное преимущество над C/C++. При этом используются сравнения вида «пинцет и вакуумная пушка» и «один программист эквивалентен десяти». Я придерживаюсь позиции что автор чуток преувеличил и на практике роль синтаксиса конкретного языка не так важна. Да, многие языки заточены под специфические задачи. Тот же DSL на руби делать намного удобнее, чем на PHP. Но для языков общего назначения и практических задач, решаемых программистами, разница между лиспом и тем же C на мой взгляд не такая огромная, как старается показать автор.
Я никак не придерживаюсь позиции автора статьи, я придерживаюсь только того что Lisp предоставляет больше возможностей и человек с прямыми руками и работающим мозгом напишет на Lisp-е более короткое и элегантное решение всякой задачи чем на C/C++.
придерживаюсь только того что Lisp предоставляет больше возможностей и человек с прямыми руками и работающим мозгом напишет на Lisp-е более короткое и элегантное решение всякой задачи чем на C/C++.
А по поводу длины кода я и не спорю. Динамические языки по определению позволяют писать более короткий и насыщенный код :). Только вот играет ли длина решающую роль?
А легантность — это вообще отдельная тема. Человек с прямыми руками и работающим мозгом это, конечно, хорошо — но что делать компании после того, как такой человек уволился, потому что ему стало скучно заниматься автоматизацией бизнеса? Он-то уволился, а код остался. BTW, у нас на рынке труда не так много разработчиков с прямыми руками и работающим мозгом :).
Это я так, в плане оффтопика.
Когда автор сравнивал 1 программиста с 10ю, он не совсем языки сравнивал, а людей их способности, и возможности языков этим способностям соответствовать. Если 10 человек — то это уже большая задача, не уверен что там все типично.
> Я придерживаюсь позиции что автор чуток преувеличил и на практике роль синтаксиса конкретного языка не так важна.
Совершенно верно, синтаксис не так важен. У лиспа (CL, scheme, clojure) как раз множество интересных свойств в самой семантике.
> Но для языков общего назначения и практических задач, решаемых программистами, разница между лиспом и тем же C на мой взгляд не такая огромная, как старается показать автор.
На самом деле автор не очень любит CL :) И как рза разница есть и действительно очень большая, это совсем разные языки. Начиная с типизации, сборщика мусора, синтаксиса, ООП и прочим.
Совершенно верно, синтаксис не так важен. У лиспа (CL, scheme, clojure) как раз множество интересных свойств в самой семантике.
> Но для языков общего назначения и практических задач, решаемых программистами, разница между лиспом и тем же C на мой взгляд не такая огромная, как старается показать автор.
На самом деле автор не очень любит CL :) И как рза разница есть и действительно очень большая, это совсем разные языки. Начиная с типизации, сборщика мусора, синтаксиса, ООП и прочим.
> Основное преимущество Lisp над C это то что этот язык функциональный
Опять же лисп совсем разный бывает. CL — не функциональный, а вот Scheme, clojure — да, все из себя функциональные.
> а такие вещи которые возможны в функциональных ЯП не возможны в структурных
Это весьма спорно, учитывая еще к тому же и аргумент от тьюринг полноты.
Опять же лисп совсем разный бывает. CL — не функциональный, а вот Scheme, clojure — да, все из себя функциональные.
> а такие вещи которые возможны в функциональных ЯП не возможны в структурных
Это весьма спорно, учитывая еще к тому же и аргумент от тьюринг полноты.
> ИМХО, преувеличение, вызванное недостаточным знанием других языков программирования. Конечно, встроенный в язык AST, списки и сборщик мусора это хорошо — но это не какое-то фатальное преимущество.
Помимо макросов, в CL, например, есть еще система рестартов, которая мощнее просто исключений, CLOS с мультиметодами, множественным наследованием, богатой системой классов; метаобъектный протокол (MOP), возможность возвращать несколько значений функцией, динамические переменные, символы и прочее.
> LISP
Так назывался первый лисп в 50ых годах.
> Могу предположить, что автор статьи, как и многие другие, рассматривает программирование исключительно в разрезе решения академических задач — технически простые программы, которые занимаются математическими рассчетами. Область, конечно, хорошая — но, ИМХО, очень нишевая.
Автор — Марк Тарвер — да, потому что он ученый. Но лисп (CL) — это все-таки промышленный язык, на которым в конце концов была написана операционная система и уйма софта к ней — всякие кады, редакторы и т. д.
Помимо макросов, в CL, например, есть еще система рестартов, которая мощнее просто исключений, CLOS с мультиметодами, множественным наследованием, богатой системой классов; метаобъектный протокол (MOP), возможность возвращать несколько значений функцией, динамические переменные, символы и прочее.
> LISP
Так назывался первый лисп в 50ых годах.
> Могу предположить, что автор статьи, как и многие другие, рассматривает программирование исключительно в разрезе решения академических задач — технически простые программы, которые занимаются математическими рассчетами. Область, конечно, хорошая — но, ИМХО, очень нишевая.
Автор — Марк Тарвер — да, потому что он ученый. Но лисп (CL) — это все-таки промышленный язык, на которым в конце концов была написана операционная система и уйма софта к ней — всякие кады, редакторы и т. д.
Толсто.
отлично! меня заинтересовал lisp. доктор, что со мной?
вы легко поддаетесь на лесть
и это все? я и сам это знаю.
К черту все — бери и делай.
rigidus.ru
lisper.ru
Изучить лисп на базовом уровне несложно, а открытий в нем хватит на всю жизнь
rigidus.ru
lisper.ru
Изучить лисп на базовом уровне несложно, а открытий в нем хватит на всю жизнь
Вот описание парня того, точно про меня. Такой же. Только не пишу на Lisp… Наверное пока не пишу)
Описание «того парня» чем-то мне напомнило астрологический прогноз. Насколько я могу судить, сказать «это про меня» может добрая половина посетителей Хабра.
Но кое-какие критерии обьективные. Например, что в школе тебе все легко давалось.
С другой стороны а могут ли это скзать про себя те кто вне хабра?
С другой стороны а могут ли это скзать про себя те кто вне хабра?
Это называется Эффект Барнума
ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%91%D0%B0%D1%80%D0%BD%D1%83%D0%BC%D0%B0
ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%91%D0%B0%D1%80%D0%BD%D1%83%D0%BC%D0%B0
А если почитать блог добрых психиатров, то можно заметить, что это довольно популярное увлечение — ставить себе диагнозы (:
я уже наверное не буду писать — мы все умрем! :(
На самом деле, (не хочу никого огорчать и обижать — сам такой), но это описание — почти классический случай маниакально-депрессивного психоза на ранних стадиях или, как его сейчас более мягко и толерантно называют, биполярного расстройства.
Раскройте поподробнее пожалуйста — мне интересна эта тема
ну, проще говоря, это когда человек склонен к тому, что у него последовательно сменяются две фазы: периоды то повышенной активности, энтузиазма, вдохновения, творческой работоспособности и т.д. (маниакальная фаза), то — подавленности, слабости, заторможенности (соответственно, депрессивная фаза).
вот, оч. познавательно — magazines.russ.ru/ural/2005/1/da14.html (классическое описание мдп, на примере жизни николая васильевича гоголя).
вот, оч. познавательно — magazines.russ.ru/ural/2005/1/da14.html (классическое описание мдп, на примере жизни николая васильевича гоголя).
Присоединяйтесь к нам. У нас есть макропеченьки.
Позавчера устроился на работу джава-кодером и столкнулся именно с такой аргументацией со стороны босса. Не в пользу Clojure.
T_T Студента жалко. T_T
Не печалься, мой друг, мы погибли.
Быть может напрасно отказавшись мельчить
И играть с Пустотой в «что-почём».
Но я помню вершину холма,
Ветку вишни в руке,
И в лучах заходящего солнца
Тень от хрупкой фигурки с мечом.
Мы погибли мой друг.
Я клянусь, это было прекрасно!
Быть может напрасно отказавшись мельчить
И играть с Пустотой в «что-почём».
Но я помню вершину холма,
Ветку вишни в руке,
И в лучах заходящего солнца
Тень от хрупкой фигурки с мечом.
Мы погибли мой друг.
Я клянусь, это было прекрасно!
www.320-8080.ru — интернет-магазин, написанный мной полностью на Common Lisp, слухи о смерти которого несколько преувеличены :)
Вы получили карт-бланш на выбор платформы или в ТЗ было? Если первое, то пришлось обосновывать выбор CL перед руководством АльфыЦиFры?
P.S. www.320-8080.ru/partners — только у меня картинок нет?
P.S. www.320-8080.ru/partners — только у меня картинок нет?
Я обосновал преимущества и получил разрешение на использование платформы.
Про картинки — это статические страницы, размещаемые контент-менеджерами, которые иногда путают пути к файлам. Я им сейчас сброшу — должны быстро поправить
Про картинки — это статические страницы, размещаемые контент-менеджерами, которые иногда путают пути к файлам. Я им сейчас сброшу — должны быстро поправить
Эммм… не могли бы вы пояснить, о каких конкретно преимуществах речь? Не для вас, для владельцев интернет-магазина?
1. Скорость работы под нагрузкой
2. Простота добавления новых возможностей
3. Оперативность поддержки
4. Контроль за возникновением ошибок на ранних стадиях
5. Простота архитетектуры => быстрое понимание для новичков-программистов,
6. Малое количество кода при широкой функциональности => меньше wtf и ошибок.
пока достаточно, потом может что-то еще вспомню
2. Простота добавления новых возможностей
3. Оперативность поддержки
4. Контроль за возникновением ошибок на ранних стадиях
5. Простота архитетектуры => быстрое понимание для новичков-программистов,
6. Малое количество кода при широкой функциональности => меньше wtf и ошибок.
пока достаточно, потом может что-то еще вспомню
Ну, как и ожидалось, ни одного преимущества кроме того, что вам так захотелось, вы предоставить не смогли.
Пункт 1 — бездоказательно. Сделайте такой же магазин на чистом Си и предъявите результаты тестов. Тогда будем говорить.
Пункт 2 — простота для кого? По базе job.ru в default city ищут работу 2221 программиста РНР и всего 54 программиста на Lisp. Переучивание с первого на второе есть процесс долгий и никак не соотносится с «простотой добавления новый возможностей» (с точки зрения владельца магазина). Аналогично с пунктами 5 и 6 — вы просто подсадили заказчиков на себя, любимого, лишив их права себя уволить. Потому что заменить вас некем. «Вы» в данном случае — это вы двое, вместе с вашим помощником.
Пункт 3 почти никак не зависит от платформы разработки, это всего лишь функция от количества нанятых программистов и графика их работы. Если вы взяли рюкзак и умотали на месяц кормить комаров в тайге, а ваш напарник заболел — все, в случае ошибки сайт встал. Независимо от платформы.
Пункт 4, возможно, облегчает жизнь лично вам, но ни на что не влияет для заказчика.
Я ни в коем случае не нападаю на Лисп или что-либо еще. Я выступаю против использования самопальных программ, на чем бы они не были написаны, там, где есть обкатанные, проверенные и работающие решения.
Ваш пункт 5 — это прямой обман. Вы просто подставили своего работодателя, заставив платить вам за поддержку и развитие сайта в будущем. Вы любите скрытые платежи от вашего сотового оператора? Здесь то же самое.
Уникальные решения нужны в уникальных проектах. Интернет-магазины к ним не относятся. Простите, что немного жестко вышло в ваш адрес, просто не надо забивать гвозди микроскопами. Хотите делать микроскопы — так идите работать в соответствующую организацию.
Пункт 1 — бездоказательно. Сделайте такой же магазин на чистом Си и предъявите результаты тестов. Тогда будем говорить.
Пункт 2 — простота для кого? По базе job.ru в default city ищут работу 2221 программиста РНР и всего 54 программиста на Lisp. Переучивание с первого на второе есть процесс долгий и никак не соотносится с «простотой добавления новый возможностей» (с точки зрения владельца магазина). Аналогично с пунктами 5 и 6 — вы просто подсадили заказчиков на себя, любимого, лишив их права себя уволить. Потому что заменить вас некем. «Вы» в данном случае — это вы двое, вместе с вашим помощником.
Пункт 3 почти никак не зависит от платформы разработки, это всего лишь функция от количества нанятых программистов и графика их работы. Если вы взяли рюкзак и умотали на месяц кормить комаров в тайге, а ваш напарник заболел — все, в случае ошибки сайт встал. Независимо от платформы.
Пункт 4, возможно, облегчает жизнь лично вам, но ни на что не влияет для заказчика.
Я ни в коем случае не нападаю на Лисп или что-либо еще. Я выступаю против использования самопальных программ, на чем бы они не были написаны, там, где есть обкатанные, проверенные и работающие решения.
Ваш пункт 5 — это прямой обман. Вы просто подставили своего работодателя, заставив платить вам за поддержку и развитие сайта в будущем. Вы любите скрытые платежи от вашего сотового оператора? Здесь то же самое.
Уникальные решения нужны в уникальных проектах. Интернет-магазины к ним не относятся. Простите, что немного жестко вышло в ваш адрес, просто не надо забивать гвозди микроскопами. Хотите делать микроскопы — так идите работать в соответствующую организацию.
Очень идеализировано и бесконечно далеко от практики. Говорить о взаимозаменяемости программистов на PHP имеет смысл только для больших организаций, с развитым IT-подразделением, или даже только для IT-компаний.
На деле оказывается, что когда PHP-программист увольняется, то надо делать выбор из 2000 кандидатов, большинство из которых совершенно не компетентны (не потому что, PHP, а потому что ищут работу). Кого в итоге возьмут — вопрос удачи (ведь контора не софтверная, с небольшим IT-подразделением).
Новый разработчик обнаруживает, что проект это куча говна. И начинает это говно разребать, но обычно лучше не становится, просто одно говно заменяется на другое. Ну ему-то в своем говне сидеть приятней, чем в чужом. А потом он увольняется и на его место приходит другой, и всё по новой.
В итоге, с точки зрения бизнеса, риски связанные с выбором CL просто меркнут на фоне рисков, связанных с постоянной ротацией якобы взаимозаменяемы PHP-программистов. Да, они взаимозаменяемы, но только для перемешивания говна, а бизнесу то надо совсем другое.
Теперь насчёт уникальных решений. Да, интернет-магазин задача типовая и можно использовать типовое решение. Только это вопрос вообще не имеет отношения к разработке, а исключительно к бизнесу. Если бизнес не хочет типового решения, а имеет амбиции и хочет развиваться, то он не будет делать ставку на типовое решение. У него есть набор своих требований, которые плохо ложатся на типовые решения.
Касательно конкретно этого магазина. Насколько я понимаю, там и был php до прихода автора. И, очевидно, описанная выше ситуация «круговорота говна в природе» настолько достала владельцев, что они согласились с аргументацией и дали возможность использовать CL. Да, риски велики. Но это дало шансы на изменения развития в сторону реальных интересов бизнеса. Собственно, это и есть задача бизнеса — оценивать риски, а программисты пускай лучше пишут код.
На деле оказывается, что когда PHP-программист увольняется, то надо делать выбор из 2000 кандидатов, большинство из которых совершенно не компетентны (не потому что, PHP, а потому что ищут работу). Кого в итоге возьмут — вопрос удачи (ведь контора не софтверная, с небольшим IT-подразделением).
Новый разработчик обнаруживает, что проект это куча говна. И начинает это говно разребать, но обычно лучше не становится, просто одно говно заменяется на другое. Ну ему-то в своем говне сидеть приятней, чем в чужом. А потом он увольняется и на его место приходит другой, и всё по новой.
В итоге, с точки зрения бизнеса, риски связанные с выбором CL просто меркнут на фоне рисков, связанных с постоянной ротацией якобы взаимозаменяемы PHP-программистов. Да, они взаимозаменяемы, но только для перемешивания говна, а бизнесу то надо совсем другое.
Теперь насчёт уникальных решений. Да, интернет-магазин задача типовая и можно использовать типовое решение. Только это вопрос вообще не имеет отношения к разработке, а исключительно к бизнесу. Если бизнес не хочет типового решения, а имеет амбиции и хочет развиваться, то он не будет делать ставку на типовое решение. У него есть набор своих требований, которые плохо ложатся на типовые решения.
Касательно конкретно этого магазина. Насколько я понимаю, там и был php до прихода автора. И, очевидно, описанная выше ситуация «круговорота говна в природе» настолько достала владельцев, что они согласились с аргументацией и дали возможность использовать CL. Да, риски велики. Но это дало шансы на изменения развития в сторону реальных интересов бизнеса. Собственно, это и есть задача бизнеса — оценивать риски, а программисты пускай лучше пишут код.
Я правильно понимаю, вы — автор части описываемого в этой ветке комментов велосипеда? И вы только что назвали 2000 незнакомых вам человек говном только за знание РНР?
> вы только что назвали 2000 незнакомых вам человек
> говном только за знание РНР
Вы что, читать не умеете?
Во-первых, я не называл никого говно, я говорил только о коде. Во-вторых, я специально подчеркнул, что некомпетентность большинства ищущих работу не связана с фактом использования PHP. Есть процент разработчиков, которым бы лучше было наверное заниматься чем-то другим. Это приводит к тому, что они постоянно ищут работу (либо не имеют работы в данный момент, либо имеют проблемы на текущей). в итоге, 95% кандидатов на рынке труда принадлежат именно к таким, хотя их общий процент на фоне всех разработчиков совсем не велик. И сделать правильный выбор небольшой не-IT компании очень трудно.
> говном только за знание РНР
Вы что, читать не умеете?
Во-первых, я не называл никого говно, я говорил только о коде. Во-вторых, я специально подчеркнул, что некомпетентность большинства ищущих работу не связана с фактом использования PHP. Есть процент разработчиков, которым бы лучше было наверное заниматься чем-то другим. Это приводит к тому, что они постоянно ищут работу (либо не имеют работы в данный момент, либо имеют проблемы на текущей). в итоге, 95% кандидатов на рынке труда принадлежат именно к таким, хотя их общий процент на фоне всех разработчиков совсем не велик. И сделать правильный выбор небольшой не-IT компании очень трудно.
Вы так уверенно говорите, как будто вы сотрудник специализирующегося на ИТ кадрового агентства.
А я лично немного в теме, так уже года три нанимаю людей на работу по специальности веб-программист. Кандидатуры без знания РНР я просто не рассматриваю, я просто не верю, что можно разбираться в вебе и совсем не знать РНР. При этом я никого не заставляю его любить, пожалуйста, для себя пишите на чем хотите — хоть на асме вприсядку.
Так вот, из этих 2200 резюме порядка 2000 на данный момент работают, просто хотят или зарплату повыше, или ждут предложений от какого-нибудь яндекса. Да, половина из них ничего не умеет, но все оставшиеся — вполне годные программисты, а 10% даже хорошие.
А я лично немного в теме, так уже года три нанимаю людей на работу по специальности веб-программист. Кандидатуры без знания РНР я просто не рассматриваю, я просто не верю, что можно разбираться в вебе и совсем не знать РНР. При этом я никого не заставляю его любить, пожалуйста, для себя пишите на чем хотите — хоть на асме вприсядку.
Так вот, из этих 2200 резюме порядка 2000 на данный момент работают, просто хотят или зарплату повыше, или ждут предложений от какого-нибудь яндекса. Да, половина из них ничего не умеет, но все оставшиеся — вполне годные программисты, а 10% даже хорошие.
Вот такие, как вы, и плодят нелепые мифы о Common Lisp.
1) Ваше предложение сделать интернет-магазин на C просто смехотворно. Это почти то же самое, что предложить повару нарезать овощи скальпелем под джаз.
2) С вашим подходом в своё время не были нужны ни Python, ни Ruby — вакансий тоже было гораздо меньше, чем для PHP.
3) ок
4) Вы про какие «решения», на уровне языка или на уровне архитектуры в целом? Во втором случае вообще непонятно, с чем вы спорите, так как архитектуры REST и MVC, к примеру, достаточно обкатаны и реализуемы, в том числе, на Common Lisp.
5) Погодите-ка, то есть, в случае PHP поддержка и развитие сайта бесплатны? И PHPшники настолько суровы, что разбираются в любом проекте мгновенно? Да это же просто песня какая-то.
Извините, если был резок, но я с вашей позицией не согласен, и мне кажется, что вы питаете необоснованную неприязнь к CL и подобным решениям. Впрочем, я давно пишу на C++ и не раз замечал, как коллеги ни во что не ставят работы Андрея Александреску или Джеффа Элджера, так что уж говорить о Common Lisp, в котором большинство видят только функции и скобки.
1) Ваше предложение сделать интернет-магазин на C просто смехотворно. Это почти то же самое, что предложить повару нарезать овощи скальпелем под джаз.
2) С вашим подходом в своё время не были нужны ни Python, ни Ruby — вакансий тоже было гораздо меньше, чем для PHP.
3) ок
4) Вы про какие «решения», на уровне языка или на уровне архитектуры в целом? Во втором случае вообще непонятно, с чем вы спорите, так как архитектуры REST и MVC, к примеру, достаточно обкатаны и реализуемы, в том числе, на Common Lisp.
5) Погодите-ка, то есть, в случае PHP поддержка и развитие сайта бесплатны? И PHPшники настолько суровы, что разбираются в любом проекте мгновенно? Да это же просто песня какая-то.
Извините, если был резок, но я с вашей позицией не согласен, и мне кажется, что вы питаете необоснованную неприязнь к CL и подобным решениям. Впрочем, я давно пишу на C++ и не раз замечал, как коллеги ни во что не ставят работы Андрея Александреску или Джеффа Элджера, так что уж говорить о Common Lisp, в котором большинство видят только функции и скобки.
:) С моей точки зрения, писать интернет-магазин что на Си, что на Лиспе — занятие исключительно для знающих толк в извращениях.
Правда жизни в том, что сегодня писать интернет-магазин вообще извращение, независимо от языка. Примерно как писать свой Ворд или Эксель, когда вам поставлена задача сделать из компьютера «офисную пишущую машинку».
Коробочные решения сегодня достигли того уровня, когда их нужно просто настроить и натянуть дизайн; ну максимум, в сложных ситуациях, дописать какой-нибудь плагин или очень слегка доработать напильником.
И да, я не теоретик, моя студия запускает магазины за 10-15 часов работы с момента утверждения дизайна, силами одного «грамотного верстальщика».
И вот среди наших клиентов очень многие — жертвы велосипедистов с сайтами не пойми на чем.
С одной стороны, эти пострадавшие меня кормят, с другой — я все же всячески агитирую любителей изобретать велосипеды уйти из профессии и устроиться куда-нибудь, где их желания будут в тему. Мне чисто по-человечески жалко людей, которые полезли в интернет-бизнес и сразу же напоролись на такие детские грабли. Вроде и заплатили нормально, но не тем.
Правда жизни в том, что сегодня писать интернет-магазин вообще извращение, независимо от языка. Примерно как писать свой Ворд или Эксель, когда вам поставлена задача сделать из компьютера «офисную пишущую машинку».
Коробочные решения сегодня достигли того уровня, когда их нужно просто настроить и натянуть дизайн; ну максимум, в сложных ситуациях, дописать какой-нибудь плагин или очень слегка доработать напильником.
И да, я не теоретик, моя студия запускает магазины за 10-15 часов работы с момента утверждения дизайна, силами одного «грамотного верстальщика».
И вот среди наших клиентов очень многие — жертвы велосипедистов с сайтами не пойми на чем.
С одной стороны, эти пострадавшие меня кормят, с другой — я все же всячески агитирую любителей изобретать велосипеды уйти из профессии и устроиться куда-нибудь, где их желания будут в тему. Мне чисто по-человечески жалко людей, которые полезли в интернет-бизнес и сразу же напоролись на такие детские грабли. Вроде и заплатили нормально, но не тем.
Каков был размер комманды? Или вы работали вообще в одиночку?
Первоначально я был единственным программистом, кроме меня был верстальщик, дизайнер и руководитель проекта. Потом начальство наняло еще одного программиста без опыта программирования на лиспе, но с опытом веб-разработки и интеллектуально одаренного. Мне была поставлена задача обучить его, чтобы он мог меня заменить, если что. Это и было сделано.
Какая БД и фреймворки использованы, если это не NDA?
На каком железе работает и какова нагрузка?
На каком железе работает и какова нагрузка?
Для второй версии магазина я отказался от БД — этот слой оказался излишним при нашем количестве данных. Все данные хранятся в файлах, во время работы подгружаются в виде объектов в лисп-образ.
Использованный фреймворк — RESTAS за авторством присутствующего в треде Архимага.
Веб-сервер — hunchentoot.
Первая версия магазина работала с базой и без фреймворка — необходимую функциональность я написал сам.
По нагрузке так сразу не скажу, надо уточнять, железо теперь вроде бы довольно неплохое, но и с первой версией тормозов не было — лисп компилируемый язык, работает на порядок быстрее руби и пхп, и в ряде случаев быстрее джавы, насколько мне известно.
Использованный фреймворк — RESTAS за авторством присутствующего в треде Архимага.
Веб-сервер — hunchentoot.
Первая версия магазина работала с базой и без фреймворка — необходимую функциональность я написал сам.
По нагрузке так сразу не скажу, надо уточнять, железо теперь вроде бы довольно неплохое, но и с первой версией тормозов не было — лисп компилируемый язык, работает на порядок быстрее руби и пхп, и в ряде случаев быстрее джавы, насколько мне известно.
Цитата:
Подход C/C++ совсем другой. Так трудно сделать что-нибудь с пинцетом и клеем, что любой результат является достижением.
По себе людей не судят :)
Подход C/C++ совсем другой. Так трудно сделать что-нибудь с пинцетом и клеем, что любой результат является достижением.
По себе людей не судят :)
хороший текст, но думаю, это в большей степени достоинство статьи. и необходимо учитывать специфику языков при переводе. общая тенденция пунктуационного обеднения английских текстов не должна сказываться на русском.
например, оформление прямой речи в тексте через двоеточие: Я часто задавал себе вопрос: А существует ли типичный Lisp-разработчик? — и завершающее тире; обрамляющие кавычки также невозбранны
Lisp-разработчик — сложносоставное слово пишется через дефис, а не тире
доуниверситетский — приставки не отделяются дефисом
зы: а ещё бы поменьше союзов в начале предложения
=;)
например, оформление прямой речи в тексте через двоеточие: Я часто задавал себе вопрос: А существует ли типичный Lisp-разработчик? — и завершающее тире; обрамляющие кавычки также невозбранны
Lisp-разработчик — сложносоставное слово пишется через дефис, а не тире
доуниверситетский — приставки не отделяются дефисом
зы: а ещё бы поменьше союзов в начале предложения
=;)
фуу бл*ть!!!
фуу на*уй!!!
фуу на*уй!!!
В пятом абзаце объясняется причина появления мема «британские ученые».
Прочитав комментарии, расстроился — столько людей ничего не знают Common Lisp и делают о нём совершенно нелепые выводы на основе каких-то слухов. Прислушайтесь к уважаемому archimag — он является автором web-фреймворка RESTAS, написанного на Common Lisp. Почитайте замечательную книгу Питера Сибела «Practical Common Lisp»; здесь находится оригинал, а вот отличный русский перевод.
Сам изучаю CL около месяца и просто поражён его гибкостью и красотой. Это мультипарадигменный язык, не функциональный: он позволяет писать в функциональном стиле, но ни в коем случае не заставляет. А его система макросов позволяет легко расширять язык и заниматься метапрограммированием, и это не нужно приклеивать изолентой, как в большинстве популярных языков.
Сам изучаю CL около месяца и просто поражён его гибкостью и красотой. Это мультипарадигменный язык, не функциональный: он позволяет писать в функциональном стиле, но ни в коем случае не заставляет. А его система макросов позволяет легко расширять язык и заниматься метапрограммированием, и это не нужно приклеивать изолентой, как в большинстве популярных языков.
Хорошо бы, чтобы такие люди как автор, преподавали у нас в универе.
>Lisp-разработчик имеет острый ум
Правда? Чтож этот ваш ЛNSП не используется то нигде, кроме как в мокрых фантазиях этих умных парней?
Правда? Чтож этот ваш ЛNSП не используется то нигде, кроме как в мокрых фантазиях этих умных парней?
> Чтож этот ваш ЛNSП не используется то нигде, кроме как в мокрых фантазиях этих умных парней?
Вы не поверите, но используют.
Вы не поверите, но используют.
Узнаю вас. Лично вам уже много раз показывали где он ещё используется. Воспользуйтесь поиском, если память подводит. Также позволю себе посоветовать вам задавать впредь корректные вопросы, ознакомившись предварительно с предметной областью.
Затевая некоторое время назад конференцию по функциональному программированию в своём городе, я и не подозревал, сколько человек, оказывается, пишут на языках вроде CL, APL, J, Haskell и Erlang — пишут вполне успешно, и весьма неигрушечный софт.
Вопрос расчёта рисков при выборе языка решается одним успешным проектом. Успешный проект выполняется одним хорошим программистом (и его коммандой) с неплохо подвешенным языком для убеждения начальства. Как-то так прогресс и происходит, вообще говоря.
Вопрос расчёта рисков при выборе языка решается одним успешным проектом. Успешный проект выполняется одним хорошим программистом (и его коммандой) с неплохо подвешенным языком для убеждения начальства. Как-то так прогресс и происходит, вообще говоря.
Мне кажется, LISP не стал мейнстримом и никогда им не станет по одной простой причине: этот язык создан для того, чтобы на нем можно было легко писать код. Проблема в том, что в большинстве случаев код нужно еще и легко читать. То, что на Лиспе можно решить определенную задачу сотней разных способов, а на Джаве всего двумя, иногда являеться преимуществом Джавы: когда вы решаете эту задачу — вам так не кажется, но когда через 10 лет в вашей системе на пару миллионов строк будет разбиратся другой разработчик, он эти два способа поймет намного быстрее, чем сотню Лисповских.
Все больше склоняюсь к мнению, что вопрос здесь лишь в хорошей модульности и документации.
Еще ни разу я не сталкивался с проблемами чтения чужого кода на лиспе. Для справки — я использую множество библиотек (могу перечислить) и обращаюсь сразу к коду, т.к. документацию часто просто лень читать. Код на лиспе, если он специально не хитрозаморочен (кому бы это могло понадобиться?) читать просто и быстро — он лаконичен. А вот в других языках тяжело разобраться даже с помощью нэтбинса и всяких других сред, которые облегчают нахождение нужных фрагментов.
Однажды я видел библиотеку-обвязку Google App Engine для Clojure. Чёрт возьми, насколько же она была сурова — двухслойные макросы для генерации внутрикложевых ООП-конструкций. В таком коде даже прожженый лиспер без поллитры не разберется.
При желании я могу и на джаве написать такое, что можно будет диссер защитить на расшифровке этого кода.
А мне показалось, что Clojure сильно отличается от Common Lisp. Я бы не стал экстраполировать опыт, полученный в процессе чтения Clojure-кода, на семейство Lisp'ов в целом.
Clojure почти не отличается от Common Lisp'а в плане лисповости. Clojure, в целом, немного читабельнее за счет скобочек для векторов, множеств и хэшей; более коротких имен; запятых; тильд для записи макросов; встроенных регулярок и консрукций для многопоточности; то что это LISP-1; хэшей для генерации имен символов, и прочее…
> Проблема в том, что в большинстве случаев код нужно еще и легко читать.
Я регулярно читаю достаточно большие объёмы кода на разных языках и смею вас уверить, что код на CL читать и понимать гораздо проще. Правда, да, есть не совсем психически здоровые люди, которые налегают на мета и прочие амфитамины, и тут может быть засада. Но если код пишут вменяемые разработчики, то работать с ним очень и очень просто.
Я регулярно читаю достаточно большие объёмы кода на разных языках и смею вас уверить, что код на CL читать и понимать гораздо проще. Правда, да, есть не совсем психически здоровые люди, которые налегают на мета и прочие амфитамины, и тут может быть засада. Но если код пишут вменяемые разработчики, то работать с ним очень и очень просто.
Я чем дольше живу, тем больше убеждаюсь, что вменяемый разработчик — это вообще большая редкость. Кроме того, я уверен, что среди лисперов процент вменяемых больше, чем в среднем по больнице — просто потому, что для того, чтобы его осилить нужно иметь определенные способности. Что-то мне подсказывает, что среднестатистический джавист или сишарпер с возможностями Лиспа в руках — это как обезьяна с гранатой. А если на Джаве или Сишарпе пишет — так вроде и ничего, нормальный разработчик, если за ним иногда присматривать и подчищать огрехи.
Из этого есть несколько замечательных следствий
— Если нанимать людей, знающих лисп даже для работы на других языках — вероятность нанять плохого во много раз меньше.
— Если дать возможность лисперу писать на любимом языке — он будет верен проекту значительно дольше, чем средний разработчик. Верность проекту — это не просто работа с 10 до 19, это еще и размышления над ним в нерабочее время, а это дорогого стоит.
— Если нанимать людей, знающих лисп даже для работы на других языках — вероятность нанять плохого во много раз меньше.
— Если дать возможность лисперу писать на любимом языке — он будет верен проекту значительно дольше, чем средний разработчик. Верность проекту — это не просто работа с 10 до 19, это еще и размышления над ним в нерабочее время, а это дорогого стоит.
Следствия, конечно, замечательные, вот только никак не отменяют того факта, что на рынке труда есть 99 джавистов, из которых 20 толковых и один лиспер. И если мне нужно набрать комманду в 10 человек, то столько лисперов я просто не найду, а вот 10 толковых джавистов найти можно, если постаратся. И нет, не надо меня убеждать, что один лиспер стоит десятка джавистов — я не поверю.
Да, с этим проблемы. Но не все потеряно — современные лисперы как правило и есть джависты. Ибо Clojure.
Стоит посмотреть с другой стороны — если есть необходимость выбрать из 99 джавистов и среди них есть один лиспер — однозначно стоит брать его и экономить на поиске среди других 98 :)
Предоставив ему пространство для работы можно внезапно обнаружить, что он действительно стоит десятка джавистов, особенно, если он разрабатывает на своем любимом языке. Потому что человек, работающий ради более высокой цели чем просто зарплата, да еще и снабженный хорошими инструментами, такими как CL вкладывают в проект гораздо больше чем средний разработчик, работающий чтобы жить, а не живущий ради интересной работы.
Предоставив ему пространство для работы можно внезапно обнаружить, что он действительно стоит десятка джавистов, особенно, если он разрабатывает на своем любимом языке. Потому что человек, работающий ради более высокой цели чем просто зарплата, да еще и снабженный хорошими инструментами, такими как CL вкладывают в проект гораздо больше чем средний разработчик, работающий чтобы жить, а не живущий ради интересной работы.
А почему вы думаете, что джависты не любят джаву и не считают свою работу интересной? Я, например, пишу на C# и очень люблю этот язык. И интересность работы для меня имеет столь же большое значение, как и размер зарплаты.
С другой стороны, я четко понимаю, что конечной целью моей работы есть готовый продукт, отвечающий требованиям. Если по пути к этой цели у меня есть возможность применить красивые решения, которые принесут мне эстетическое удовлетворение — я их обязательно применю и получу удовольствие от элегантности кода, например. Но если я понимаю, что взять, к примеру, готовую компоненту и встроить ее в код будет надежнее и быстрее, то компонента будет встроена в код.
Лисп — инструмент художника. А промышленное кодописательство — это в своем большинстве довольно нетворческая работа. Творчество тут начинается на высоком уровне, когда нужно проектировать архитектуры систем и взаимодействие между ними. Но это уже другая история, в которой зачастую приходишь к выводу, что язык вообще не имеет значения.
С другой стороны, я четко понимаю, что конечной целью моей работы есть готовый продукт, отвечающий требованиям. Если по пути к этой цели у меня есть возможность применить красивые решения, которые принесут мне эстетическое удовлетворение — я их обязательно применю и получу удовольствие от элегантности кода, например. Но если я понимаю, что взять, к примеру, готовую компоненту и встроить ее в код будет надежнее и быстрее, то компонента будет встроена в код.
Лисп — инструмент художника. А промышленное кодописательство — это в своем большинстве довольно нетворческая работа. Творчество тут начинается на высоком уровне, когда нужно проектировать архитектуры систем и взаимодействие между ними. Но это уже другая история, в которой зачастую приходишь к выводу, что язык вообще не имеет значения.
> Лисп — инструмент художника.
Я не знаю про какой Лисп вы говорите, но CL это именно промышленная платформа, созданная по заказу МО США (финансированием проекта занималась DARPA). Я не знаю какой язык предпочитаю в Пентагоне сейчас, но в своё время для него было создана два языка — Ada (о чём все знают) для системного программирования, и CL (о чем знают уже не все) для всего остального. Т.е. CL изначально создавался именно как промышленный стандарт для широкого круга задач.
Я не знаю про какой Лисп вы говорите, но CL это именно промышленная платформа, созданная по заказу МО США (финансированием проекта занималась DARPA). Я не знаю какой язык предпочитаю в Пентагоне сейчас, но в своё время для него было создана два языка — Ada (о чём все знают) для системного программирования, и CL (о чем знают уже не все) для всего остального. Т.е. CL изначально создавался именно как промышленный стандарт для широкого круга задач.
Учитывая вашу мотивацию к работе и умение ставить верные цели и достигать их, я рекомендовал бы вам попробовать использовать в своих проектах Common Lisp. На самом деле, я чувствую вы — наш человек.
Кстати, в аниме часто рассказывают о таких студентах. У таких людей не состыковка между их внутренними представлениями мира, и настоящим миром. Также можно сказать, что человек видит все только в черном и белом свете. В литературе это часто описывается как юношеский максимализм, тяга к чему-то совершенному, прекрасному, попытка уйти от реальности. Очень хорошо этим нашпиговано «Солярис» Торковского.
К слову, чувство меланхолии, сильную влюбленность (без видимых причин) переходящую в депрессию, очень часто можно испытать при частых приступах язвы двенадцатиперстной кишки (т.к. язва может болеть месяцами, от сюда и склонность человека к меланхолии).
К слову, чувство меланхолии, сильную влюбленность (без видимых причин) переходящую в депрессию, очень часто можно испытать при частых приступах язвы двенадцатиперстной кишки (т.к. язва может болеть месяцами, от сюда и склонность человека к меланхолии).
Однако подстегивает. Ушел изучать CL. Каждый человек в силу своей привычки или каприза, а еще больше в силу того, что диктует ему рынок выбирает порой не то, что ему действительно по душе. Автору топика спасибо! Было приятно читать, как впрочем и многочисленные споры.
lisper.ru
rigidus.ru
pcl.catap.ru/doku.php?id=pcl
Если будут вопросы — пишите в личку, постараюсь помочь в изучении
rigidus.ru
pcl.catap.ru/doku.php?id=pcl
Если будут вопросы — пишите в личку, постараюсь помочь в изучении
Всегда интересовал такой вопрос, я думаю, в присутствии лисперов на него дадут точный ответ.
Насколько язык Haskell по отношению к LISP:
а) проще?
б) мощнее (скорость разработки)?
в) быстрее (скорость исполнения)?
г) имеет более читабельный исходный код?
Насколько язык Haskell по отношению к LISP:
а) проще?
б) мощнее (скорость разработки)?
в) быстрее (скорость исполнения)?
г) имеет более читабельный исходный код?
Есть разные мнения по этому вопросу, чтобы не устраивать холивар ограничусь советом попробовать оба языка и сделать вывод для себя.
На любом языке можно писать на фортране. Любые подобные метрики очень сильно зависят от использующего язык программиста — тем более при сравнении настолько разных языков.
Некоторое сравнение можно пронаблюдать здесь:
rosettacode.org/wiki/Welcome_to_Rosetta_Code
langref.org/
по второй ссылке CL, к сожалению, нет — есть только Clojure.
Некоторое сравнение можно пронаблюдать здесь:
rosettacode.org/wiki/Welcome_to_Rosetta_Code
langref.org/
по второй ссылке CL, к сожалению, нет — есть только Clojure.
Очень здорово, особенно второй ресурс понравился.
А есть что-то такое, но на русском? По-моему на Хабре когда-то проскакивала ссылка на похожий проект.
А есть что-то такое, но на русском? По-моему на Хабре когда-то проскакивала ссылка на похожий проект.
Уже отыскал: progopedia.ru/.
Стоит, пожалуй, отметить, что автор данной статьи (Марк Тарвер) — автор статически типизированного функционального языка Qi, работавшего поверх CL в первой и второй версии. От использования CL для третьей версии Qi Тарвер отказался:
groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87
www.lambdassociates.org/shen.htm
groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87
www.lambdassociates.org/shen.htm
Хороший дебют.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lisp разработчик: две стороны одной медали