?

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-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)