LINUX.ORG.RU

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

Можно начать с Practical Common Lisp г-на P. Siebel и компилятора SBCL.

mo3r
()

Там выше немного есть lisp-lor-faq. Попробуй сначала его прочитать.

Laz ★★★★★
()
Ответ на: комментарий от anonymous

А ещё анонимусы не переваривают локализацию?

AnDoR ★★★★★
()

Фунциональное программирование, самое полное ООП, единственная полноценная реализация метопрограммирования, идеальный язык обработки списков, динамическая типизация, интерпретатор/виртуальная машина, эффективность. Преимущества Лиспа чувствуешь в основном при решении реальных задач, ибо продуктивность возрастает несказанно. Если цель - hello-world, то изучать не советую.

xTERM ★★
()

Lots of Insane Silly Parentheses

jtootf ★★★★★
()
Ответ на: комментарий от anonymous

> А Пол Грэм вообще написал очень серьезный проект, который в итоге приобрела Yahoo.

И это доказывает... что именно? Что на Лиспе можно писать серьезные проекты? С этим никто и не спорил. Но вот фраза "продуктивность возрастает несказанно" - это реклама. Возрастает она на 30% (сравнение с Си++), и "это многое объясняет" (c)

tailgunner ★★★★★
()
Ответ на: комментарий от xTERM

>> Кому верить? %)

> В первую очередь себе (а не каким-то цифрам).

Предлагаешь выучить Лисп только для того, чтобы подтвердить мнение Габриеля? Дороговато получится.

P.S. "В наше время, верить нельзя никому, порой даже самому себе." (c)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> P.S. "В наше время, верить нельзя никому, порой даже самому себе." (c)

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

anonymous
()
Ответ на: комментарий от tailgunner

>Предлагаешь выучить Лисп

Да. Я предлагаю не захламлять ЛОР своими "догадками", а разобраться в предмете, о котором дискутируешь. Какое право Вы имеете что-то комментировать, если сами Лисп не знаете?

xTERM ★★
()
Ответ на: комментарий от xTERM

> Я предлагаю не захламлять ЛОР

Предложение отклонено.

> своими "догадками"

Покажи, где _моя догадка_.

> Какое право Вы имеете что-то комментировать, если сами Лисп не знаете?

Это комментарий ветерана Лиспа, одного из авторов CLOS, не ушибленного Си++-фобией. Привел я его для того, чтобы другие (не ты) знали, что есть разные точки зрения.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Это все замечательно, но было бы немного странным, если бы все языки, будучи самыми разными, начиная от низкого и кончая высоким уровнем, давали одинаковую продуктивность. Если даже самые высокоуровневые дают 30%, то может быть только два вывода 1) либо 30% - это очень много 2) либо пишите все на Си и ассемблере, раз разницы никакой

xTERM ★★
()
Ответ на: комментарий от tailgunner

>> Какое право Вы имеете что-то комментировать, если сами Лисп не знаете?

>Это комментарий ветерана Лиспа, одного из авторов CLOS, не ушибленного Си++-фобией.

А от имени Гослинга и Брэда Кокса я заявляю: С++ - говно!

xTERM ★★
()
Ответ на: комментарий от xTERM

> А от имени Гослинга и Брэда Кокса я заявляю: С++ - говно!

Не припомню таких заявлений от них, но не в этом дело... а в том, что весь из себя такой стройный и логичный Лисп (особенно в ипостаси CL, гг) выигрывает у корявого Си++ всего 30% в производительности труда.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>весь из себя такой стройный и логичный Лисп (особенно в ипостаси CL, гг) выигрывает у корявого Си++ всего 30% в производительности труда

на личном опыте проверено ? нет ? тогда лучше было бы промолчать, право

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> на личном опыте проверено ? нет ?

См. выше.

> тогда лучше было бы промолчать, право

Мне и так неплохо.

Если у тебя есть ссылки на другие данные о сравнительной производительности труда - опубликуй (не только Лиспа касается, про Хаскель тоже интересно).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Странная цифра. Во-первых, очевидно, возрастает/убывает она у разных людей по-разному. У гуру С++, не знающего лиспа (да, круглого и в вакууме) она упадёт раз в 100. У гуру лиспа, не знающего С++ она возрастёт раз в 100. Все промежуточные варианты дадут градацию. Т.е. даже если не учитывать индивидуальных особенностей разработчиков, всё будет зависеть, как минимум, от их знания языков и доступного инструментария.

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

Приведенная цитата - из главы "Productivity: Is There A Silver Bullet?". Ну и вообще интересная книга.

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

Ага, и поторить этот эксперимент хотя бы 100 раз. Но скатываться в маразм и наукоподобие не обязательно.

tailgunner ★★★★★
()
Ответ на: комментарий от xTERM

Вроде, пока по делу обсуждение идет (удивлен, честно говоря) -- позволю и я свое ИМХО декларировать :)

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

Хорошенько забытые Основы гласят, что так оно и есть: кодирование в _правильном_ проекте _должно_ занимать не более 10% времени разработки. Разработка и кодирование на едином языке (за что лисперы обычно ратуют) есть ИМХО очевидный нонсенс.

> ...Если даже самые высокоуровневые дают 30%,...

Даже странно, что лисперы сошлись на всего лишь 30%. Обычно они под 90 требуют...

ИМХО есть DSL (Domain Specific Lang.), применение которого всегда оправдано, _если_ он _есть_ для данного domain'а; и есть попытки притянуть за уши любимый DSL для решения нехарактерных задач.

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

ИМХО LISP -- нормальный язык для неторопливой работы со списками. Всякие ФП ООП и метапрограммирование -- примерно как поползновения ЦеПП на бытность Единственного Истинного ОО Языка -- эклектика и гонор.

Да, еще раз -- ВСЕ ЭТО ИМХО.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> ВСЕ ЭТО ИМХО... гальванизируемое

Всё что _можно_ извлечь из поста

yyk ★★★★★
()
Ответ на: комментарий от Die-Hard

интересно, на основании чего такие ИМХО были выдуманы?

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

ott ★★★★★
()
Ответ на: комментарий от Burbaka

>> ... приобрела Yahoo.

> И переписала на Си++

Если возьмут толкового менеджера-болтолога, убеждённого фаната brain fuck, то будьте уверены...

mv ★★★★★
()
Ответ на: комментарий от xTERM

> Коммерческий Лисп стоит от 1000$ http://www.scieneer.com/s/index.html . Никто не будет платить за воздух.

Проприетарщина md. Проприетарщина без документации md два раза.

mv ★★★★★
()
Ответ на: комментарий от ott

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

ну надо же чота новое пропихивать... да и на лиспе можно очень даже императивно писать :)

shild
()
Ответ на: комментарий от ott

> метапрограммирование и ООП в лиспе были введены много лет назад

Не скажу насчет метапрограммирования, но ООП - не изобретение Лиспа (Simula67, Smalltalk).

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

Речь об F#? Он статически типизирован и ни разу не похож на Лисп.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

а никто и не говорит, что ООП - выдумка Лиспа, хотя Лисповский ООП достаточно сильно отличается от привычных языков - C++, Java, etc.

я не говорил что микрософт адоптировал Лисп, я говорил про тенденции - что подходы ФП внедряются в популярные языки, поскольку позволяют улучшить качество кода и т.п. Лисп как один из ФЯ, пусть и не чистый, тоже имеет право на существование и использование. Многие вещи, присутствующие в Лисп - макросы, ООП, restarts/conditions, etc. делают его очень привлекательным для использования в разработке.

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

ott ★★★★★
()
Ответ на: комментарий от ott

> а никто и не говорит, что ООП - выдумка Лиспа

> я не говорил что микрософт адоптировал Лисп

Тогда я не понял, причем тут ООП и пиар MS.

> подходы ФП внедряются в популярные языки, поскольку позволяют улучшить качество кода и т.п. Лисп как один из ФЯ, пусть и не чистый, тоже имеет право на существование и использование

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

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

Выбирают инструменты, которые знаю достаточно людей.

> Вот отсюда и получаются C++ для отказоустойчивых приложений и т.п.

Ага, отказоустойчивые приложения надо писать на динамическом Erlang. Или исключительно на Ada.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ага, отказоустойчивые приложения надо писать на динамическом Erlang. Или исключительно на Ada.

На PHP, только на PHP!

mv ★★★★★
()
Ответ на: комментарий от mv

>> Ага, отказоустойчивые приложения надо писать на динамическом Erlang. Или исключительно на Ada.

> На PHP, только на PHP!

Дадада, так и делай! %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Дадада, так и делай! %)

Увы, не владею... :( Мечтаю осилить. Может быть, когда в следующий раз с велосипеда упаду...

mv ★★★★★
()
Ответ на: комментарий от ott

> интересно, на основании чего такие ИМХО были выдуманы?

Лисп -- один из первых мною осиленных языков. Я давно за ним наблюдаю, и имею собственное мнение.

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

Говорит! В первую очередь это говорит о том, что Лисп -- академический язык, удобный для исследователей.

ИМХО очевидно, что то, что подходит специалисту-ИТшнику, не годится для широкого употребления. Не то, что в индустрии, но даже собратьями-учеными. Вспомним противостояние Алгола и Фортрана! Фортран и поныне жив, а где сейчас "правильный" Алгол?

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

M$ всегда была падка на все "в высшей степени научное", и потом какое это отношение имеет к Лиспу?

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

>> а где сейчас "правильный" Алгол?

>Во всех Ц-подобных языках?

Гы! Они, вообще-то, называются "алголоподобные"!

Я про это и говорю: языка нет, а наследие осталось. То же самое ИМХО и Лисп ждало БЫ, если бы не Грэм.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Я про это и говорю: языка нет, а наследие осталось. То же самое ИМХО и Лисп ждало БЫ, если бы не Грэм.

А причем здесь Грэм? Просто железо эволюционировало очень значительно и Лисп очень дешев на нём. Лисп жил, Лисп живет, Лисп будет жить. Аминь.

anonymous
()
Ответ на: комментарий от anonymous

> А причем здесь Грэм?

Он _прежде_всего_ талантливый эссе-писатель. И он Лисп активно распропагандировал, заработав на этом кучу денег.

>Просто железо эволюционировало очень значительно

Ну да! Поэтому всякие васики, жабки и питоны и зацвели буйным цветом. Лисп -- из этой же серии.

> Лисп жил, Лисп живет, Лисп будет жить.

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

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

;;; The Lisp defined in McCarthy's 1960 paper, translated into CL.
;;;  (c) by Paul Graham 

(defun null. (x)
  (eq x '()))

(defun and. (x y)
  (cond (x (cond (y 't) ('t '())))
        ('t '())))

(defun not. (x)
  (cond (x '())
        ('t 't)))

(defun append. (x y)
  (cond ((null. x) y)
        ('t (cons (car x) (append. (cdr x) y)))))

(defun list. (x y)
  (cons x (cons y '())))

(defun pair. (x y)
  (cond ((and. (null. x) (null. y)) '())
        ((and. (not. (atom x)) (not. (atom y)))
         (cons (list. (car x) (car y))
               (pair. (cdr x) (cdr y))))))

(defun assoc. (x y)
  (cond ((eq (caar y) x) (cadar y))
        ('t (assoc. x (cdr y)))))

(defun eval. (e a)
  (cond
    ((atom e) (assoc. e a))
    ((atom (car e))
     (cond
       ((eq (car e) 'quote) (cadr e))
       ((eq (car e) 'atom)  (atom   (eval. (cadr e) a)))
       ((eq (car e) 'eq)    (eq     (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'car)   (car    (eval. (cadr e) a)))
       ((eq (car e) 'cdr)   (cdr    (eval. (cadr e) a)))
       ((eq (car e) 'cons)  (cons   (eval. (cadr e) a)
                                    (eval. (caddr e) a)))
       ((eq (car e) 'cond)  (evcon. (cdr e) a))
       ('t (eval. (cons (assoc. (car e) a)
                        (cdr e))
                  a))))
    ((eq (caar e) 'label)
     (eval. (cons (caddar e) (cdr e))
            (cons (list. (cadar e) (car e)) a)))
    ((eq (caar e) 'lambda)
     (eval. (caddar e)
            (append. (pair. (cadar e) (evlis. (cdr e) a))
                     a)))))

(defun evcon. (c a)
  (cond ((eval. (caar c) a)
         (eval. (cadar c) a))
        ('t (evcon. (cdr c) a))))

(defun evlis. (m a)
  (cond ((null. m) '())
        ('t (cons (eval.  (car m) a)
                  (evlis. (cdr m) a)))))

anonymous
()
Ответ на: комментарий от anonymous

Можно и я напишу своё частное мнение?

С++ я начал изучать лет 8 назад, кое-что иногда на нём пописываю. Лисп (CL и Scheme) начал изучать примерно лет 5 назад, тоже иногда кое-что на нём пишу. Точных дат не помню, но не суть.

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

Вот моё мнение, основанное на практике, на моих способностях и на моих вкусах:

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

От лиспа впечатления гораздо более положительные. Да, и в CL не всё можно сделать как хочется. Стандарт получен путём близкородственного кровосмешения и он получился местами похож на гибрид коня и трепетной лани, а местами оказался немножко кастрированным. Но, в основном, желаемое сделать можно, и не через то, на чём сидят, а естественным путём.

2. Тут кто-то написал про МП, что, дескать, оно не органично для лиспа. Видимо, человек не знает лиспа. МП - это наиболее естественное свойство лиспа. Именно за него мы, лисперы, готовы терпеть изобилие круглых скобок. У нас нет извращённого пристастия к скобкам. Просто мы понимаем, что другие способы представления кода плохо скажутся на способности языка к МП. Код=данные (но это скорее нужно понимать как "данные можно легко интерпретировать как исходный текст"). А МП, в силу своей общности, делает лисп мультипарадигменным. Кому лень это учить - извините, но другого пути, кроме как выучить, не существует. There is no royal road in Mathematics... Попробуйте поискать туториалы, стандарт действительно тяжеловесен и читать его тяжело, книги я сам не читал, в первой попавшейся из них (это были финны) МП отложено где-то на конец книги, а это абсолютно неправильно, как я считаю, особенно, если предполагать, что читающий уже знает кое-что о языках программирования.

Если совсем лень что-либо учить, то ближайший аналог лиспа, с точки зрения МП - это языки семейства shell. МП в них не уступает лиспу по богатству возможностей, но в них нельзя свободно оперировать с "пространственными" структурами - есть только плоские одноуровневые списки. Тем не менее, легко сгенерить код на лету. Также имеется и квазицитирование, как в лиспе. Ещё аналог лиспа - это язык Forth. В нём есть "компилирующие слова" - аналог defmacro. Чем-то похож m4, но он является "экстремальным МП" - в нём возможно МП, но затруднено "нормальное" программирование. То же можно сказать и про Пролог - в нём есть полноценное МП, но нет полноценного императивного программирования. Возможно, чем-то похож tcl, но я про него лишь когда-то читал (много лет назад) и ничего не помню уже. Других аналогов лиспу я не встречал. Т.е., perl, python, ocaml, c, c++, pascal, basic, java не являются аналогами лиспа и между ними пролегает пропасть. Если Вы не знаете ни одного из вышеперечисленных аналогичных лиспу языков - то идите и выучите хотя бы один, тогда Ваше мнение о лиспе сможет быть хоть сколько-то осмысленным.

3. CL и Scheme - это два совершенно разных языка. Scheme - академический язык, CL - промышленный. Промышленный настолько, что уже лет десять как умеет держать десятки мегабайт исходников и сотни мегабайт хипа в одном исполняемом файле. Может быть, это и не модно в наше время и держать нужно соответственно, сотни мегабайт и десятки гигобайт, но может ли подобным похвастаться тот же Хаскель? Соответственно, CL и используется в промышленности, например, в системах бронирования авиабилетов (со стороны авиакомпании), или, к примеру, в системах документооборота военных организаций США. Если Вы про это не знаете - то это значит, что Вы про это не знаете, но это не значит, что лисп - это академический язык. Я уже молчу про емакс и автокад, которые, правда, используют не CL, а более простые диалекты лиспа.

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

den73 ★★★★★
()
Ответ на: комментарий от den73

все правильно написал, стоит добавить ограничение области применения лиспа из-за скорости и памяти

ELF ★★
()
Ответ на: комментарий от ELF

> все правильно написал, стоит добавить ограничение области применения лиспа из-за скорости и памяти

тогда стоило добавить, что ресурсные характеристики очень сильно меняются от реализации к реализации. Монстр SBCL жрёт много памяти но очень быстр, особенно при типизации кода (ну да, да - не быстрее с[++] ;), clisp не так требователен к памяти но и слегка "тугодумнее" (хотя с другими байт-компилируемыми языками с динамической типизацией надо бы ещё по-сравнивать). Про версию схемы stalin проскакивали числодробильные тесты, на которых С[++] сливал - из-за хорошей оптимизации алгоритмов (что мы видим и на примере LLVM). Т.е. просто быть "ближе к железу" для скорости уже мало - нужно уметь хорошо оптимизировать алгоритмы.

yyk ★★★★★
()
Ответ на: комментарий от yyk

На самом деле, я допустил несколько ошибок вчера (я вообще невежественен, а вчера был ещё и пьян), ну да Бог с ними.

Касаемо сравнения скорости, памяти и компактности кода - есть такой сайт (уже устал его рекламировать).

http://shootout.alioth.debian.org/

Вы с удивлением можете увидеть, что по некоторым вроде бы "низкоуровневым" тестам на первом месте по скорострельности идёт Ява, а Лисп отстаёт от неё, но всё ещё находится впереди С.

den73 ★★★★★
()
Ответ на: комментарий от yyk

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

почему уже? раньше это как раз было актуальнее на слабых машинах, а теперь - "память дешевая", "купите нормальное железо", тьфу...

ELF ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.