?

Log in

Почему LISP? - Жить не можем без проблем! [entries|archive|friends|userinfo]
Жить не можем без проблем!

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Почему LISP? [Jan. 13th, 2011|02:05 pm]
Жить не можем без проблем!

ru_lisp

[aralex]

Как говорил Ворошилов, вопрос к Знатокам (к знатокам LISP-а в данном случае)! Почему таки LISP? Или, если конкретнее, вопроса три:

  1. Для каких именно задач LISP подходит больше, чем другие языки?
  2. За счёт чего для них он подходит больше?
  3. В чём именно выражается его преимущество?

Если не в лом, приведите, pls, коротенькие иллюстрации на LISP-е (или ссылочку на них). Заранее благодарен!

Исходно данный пост был размещён в сообществе ru_programming, но там Знатоков, способных ответить внятно и по сути, увы, не нашлось :(

linkReply

Comments:
From: (Anonymous)
2011-01-16 06:17 pm (UTC)
1)"Ресурсная семантика" на высоту порога вхождения принципиально не влияет, а значит к теме разговора не относится.
2)Сложнее она потому, что непривычна.
(Reply) (Parent) (Thread)
From: nivanych
2011-01-16 06:33 pm (UTC)
Всё-таки, когда из-за недостаточной оптимизации (а для Тьюринг-полных ленивых языков она нетривиальна) что-то не может выполниться только потому, что памяти не хватает, это влияет на порог вхождения. Хотя и, в целом, несильно.
Второй вопрос мне интереснее ;-)
Я бы сказал, что "потому, что непривычна" - это не так.
Главным образом, из-за сиильного отличия между её семантикой и машинками, где исполняется.
Можно составить ресурсную семантику для какой-нибудь ленивой Тьюринг-полной лямбды, чтобы можно было рассуждать об использовании памяти и CPU. Даже можно будет сказать, что она не более сложна (уверен, что будет даже более проста), а только непривычна.
Но только, к исполнению на реальных машинках это не будет иметь никакого отношения ;-(
Вот так.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-17 10:08 am (UTC)
"Всё-таки, когда из-за недостаточной оптимизации что-то не может выполниться только потому, что памяти не хватает, это влияет на порог вхождения"

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

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

Ну так в том и смысл языка программирования, чтоб его семантика отличалась от машинной. Иначе все и писали бы машкод, раз это проще. Ресурсную семантику и усложняют ради простоты использования языка. Вот ГЦ значительно усложняет "ресурсную семантику", а на языках с ГЦ писать проще. Все равно профайлером пользоваться - так какая разница насколько сложна "ресурсная семантика"?
(Reply) (Parent) (Thread)
From: nivanych
2011-01-17 02:21 pm (UTC)
> переполнение стека

Это уже немало.
Или же, скажем, читаешь про ленивость и пытаешься вычислить [1..1000000000] (миллиард).
А оно оппа
И это тоже может повлиять на порог вхождения.

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

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

> ГЦ значительно усложняет "ресурсную семантику"

Насчёт "значительно" - не соглашусь.
У ручного выделения памяти куча тонкостей.
Вот что делает многие ручные оптимизации сложными, это да.

> Все равно профайлером пользоваться

Совсем необязательно.
Например, часто в haskell проще поставить аннотацию строгости, чтобы проще предсказать поведение.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-17 04:40 pm (UTC)
"Это уже немало"
Ну я и говорю. В ленивом языке код работает. В строгом - стек переполнен.
"Или же, скажем, читаешь про ленивость и пытаешься вычислить [1..1000000000] (миллиард). А оно оппа"
Не понял. Что оппа?

"Например, часто в haskell проще поставить аннотацию строгости, чтобы проще предсказать поведение"

Не согласен. Семантика от аннотаций строгости только усложнится, а профилировать всегда надежнее, чем прикидывать "ресурсную семантику" в уме.
(Reply) (Parent) (Thread)
From: nivanych
2011-01-18 06:48 am (UTC)
> Что оппа?

ghci жрёт жутко памяти, когда пытается суммировать такой список.
4 гига оперативки не хватает. Когда-то, мне на это пожаловались.

> Не согласен.

В общем, конечно, нельзя так говорить, согласен.
Во многих конкретных случаях удобнее, но и много исключений.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 09:21 am (UTC)
"ghci жрёт жутко памяти, когда пытается суммировать такой список.
4 гига оперативки не хватает."
0) Про аут оф мемори я уже говорил. В строгом языке один список безо всякого суммирования уже даст аут оф мемори. Хотя это проблема не столько ленивости/строгости, сколько 32-х разрядов. Потому что не хватает не оперативной памяти, а адресного пространства.
1) Смотря как суммировать. Я согласен, что foldl в том виде в каком он есть сейчас в прелюдии (да и sum, разумеется, тоже) это ошибка и одна из самых известных засад для начинающего. Но это ошибка в библиотеке.
2) И самое главное - проблема тут не из-за ленивости, а из за строгости. (+) строгий по двум аргументам и форсирует список в миллиард санков.
(Reply) (Parent) (Thread)
From: nivanych
2011-01-18 11:54 am (UTC)
В общем, согласен, что дело в библиотеке, хотя некоторых и отпугнуло.
(Reply) (Parent) (Thread)