?

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:
[User Picture]From: grundik
2011-01-16 10:34 am (UTC)
Я понял твой вопрос сразу, да :)

Просто я-то как раз с лиспом дружу, а с хаскелем - не особо. Как раз потому, что в лиспе путь от "надо что-то сделать" до "что-то сделано" гораздо быстрее (даже в случае, когда я не знаю лиспа), чем в хаскеле. Конкретно в моём случае. Как оно в общем случае, мне пофигу.

Ну то есть мне насрать на то, как оно там с академической точки зрения, у меня есть практика в реальной реальности, и просто по факту в этой моей реальной реальности лисп используется мною, а хаскель - нет.

При этом никакого предубеждения к хаскелю у меня нету (вот к джаве и C++ - есть предубеждение). Просто лисп проще, вот и всё.

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

PS: под лиспом я понимаю "лисп вообще", а не common lisp. Конкретно я юзаю Racket.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-16 10:58 am (UTC)
>Конкретно в моём случае. Как оно в общем случае, мне пофигу.

Тогда зачем ты об этом говоришь в общественно доступных местах? Как я понимаю, дискуссия не может изменить твоё мнение, поскольку "жизнь такова, какова она есть, и больше никакова". Данную нам в ощущениях реальность мы, типа, изменить не в силах.

Здесь по-моему явный логический промах. С одной стороны, тебя на словах не заботит "как оно в общем случае", с другой стороны, твои комментарии направлены на поддержание твоего собственного статус кво и за счёт ограничения действий других в том числе (см. Зачем ты наезжаешь на такой прекрасный инженерный язык, как лисп, я не понимаю).

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

И критерии такой задачи?..

>PS: под лиспом я понимаю "лисп вообще", а не common lisp. Конкретно я юзаю Racket.

Вот опять. Почему твоё определение Лиспа отличается от определений других? Почему ты не используешь названия CL, Scheme, Racket и Emacs Lisp, как это делают другие, отмечая различия между языками?

Racket, кстати, отличается от Схемы настолько, что его даже переименовали.
(Reply) (Parent) (Thread)
[User Picture]From: grundik
2011-01-16 12:27 pm (UTC)
Дискуссия моего мнения изменить не может, да, потому что моё мнение основано не на размышлениях, а на действиях (ну то есть я пробовал ДЕЛАТЬ, а не думать ;) ).

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

Критериев задачи, где хаскель оптимален, я не знаю. Одна такая была - надо было проверить, что через операции с новой моделью BL возможно выразить все операции, которые были возможны на старой модели BL. Но она отпала. Появится другая - я почувствую. Статический анализатор кода мне было удобнее сделать на racket-е, хотя возможно, что на haskell было бы лучше.

Определения Лиспа не существует. Под словом Лисп каждый понимает своё. Чаще всего common lisp. Но нередко и "семейство языков". Когда я имею в виду CL, Scheme и прочих - я так и говорю: CL, scheme и прочие. Когда я говорю "лисп" я имею в виду "семейство языков".

Racket - это pure scheme плюс куча библиотек. То есть он не отличается, а сильно расширяет. GHC тоже предоставляет чуть больше, чем требует стандарт хаскеля, верно же?
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-16 12:31 pm (UTC)
>Дискуссия моего мнения изменить не может, да, потому что моё мнение основано не на размышлениях, а на действиях (ну то есть я пробовал ДЕЛАТЬ, а не думать ;) ).

Слушай, ты сегодня в ударе. Ты пьян, что ли?

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

Последний приобретается и в дискуссии тоже (один из каналов, действия другой, более затратный).
(Reply) (Parent) (Thread)
[User Picture]From: grundik
2011-01-16 01:21 pm (UTC)
Тебе что, слив защитывать, раз ты на мою личность перешёл? ;)

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

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

Конкретно в этой же дискуссии вообще ничего проверяемого не говорится, посему откуда взяться предпосылкам для изменения моего мнения? Даже если мы приведём грамматики common lisp (а лучше scheme) и haskell-я, то и это не даст возможности чётко сказать, чей синтаксис сложнее.

PS: я пьяный, но это влияет только на то, что я продолжаю тут писать. Трезвый я бы про спор со словом "lisp" никогда бы не влез, ибо пустая трата времени это, даже лулзов не получить.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-16 01:25 pm (UTC)
Да я ничего, кроме личностей лисперов и не рассматривал, если уж на то пошло.

"If you want to know what God thinks about money, look at the people He gave it to" в применении к Лиспу.

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

Так что засчитывай, что угодно. Я материала набрал достаточно.
(Reply) (Parent) (Thread)
[User Picture]From: grundik
2011-01-16 02:15 pm (UTC)
Да какой из меня лиспер? У меня вообще сертификат PHP5 есть, и использую я только scheme (точнее, racket), да и то для своих нужд только.

Если судить об инструменте по его пользователям, то о хаскеле можно много неверного насудить.

А устроить флуд на ровном месте - это несложно, если есть слова haskell или lisp.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-16 03:13 pm (UTC)
Я тебе только из этой дискуссии такое количество неадеквата на ровном месте наберу, мало не покажется.

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

Если серьёзно и только об инструментах, то инструмент программиста должен помогать как можно более раннему устранению ошибок. Это единственное, что от него действительно требуется.

Типы здесь помогают. Как и сборка мусора, функции высших порядков, макросы, REPL и тому подобное. Но типов - как логики для рассуждения о программах, средства метаконтроля программ, - в Лиспе нет и это единственное упущение Лиспа. Что делает его провальным инструментом, с моей точки зрения, по сравнению со многими другими инструментами.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-16 04:37 pm (UTC)
> Но типов - как логики для рассуждения о программах, средства метаконтроля программ, - в Лиспе нет и это единственное упущение Лиспа.

По-моему, гораздо полезнее обнаружения ошибки возможность быстро ее найти и исправить (потому что ошибки в любом случае будут, если только мы не доказывали корректность руками или не использовали что-то вроде Агды), а с этим у лиспа все в порядке. Ну и зависит многое от задач, конечно. Если мы имеем четкую спецификацию, то логично использовать язык с развитой системой типов, если же у нас спецификация сильно плывет, то особого профита система типов, наверное, не даст. Ну и, опять же, в лиспе есть возможность написать под спецификацию дсл, а потом доказать корректность этого дсл, что будет горазло проще доказательства корректности голого кода.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-16 05:00 pm (UTC)
>По-моему, гораздо полезнее обнаружения ошибки возможность быстро ее найти и исправить

Великолепно!

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

Наоборот. При наличии спецификации можно обложиться тестами и тогда система типов не большой помощник. А вот когда спецификации нет, или когда она изменяется, то типы позволяют не допускать глупых ошибок при её создании, а при изменении спецификации - распространять изменения всюду, где это необходимо.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-17 04:33 am (UTC)
> Великолепно!

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

> При наличии спецификации можно обложиться тестами и тогда система типов не большой помощник.

В какой вселенной тесты стали гарантией корректности? Ее даже 100% покрытие путей не дает.

> то типы позволяют не допускать глупых ошибок при её создании, а при изменении спецификации - распространять изменения всюду, где это необходимо

А зачем нам делать изменения всюду, где это необходимо, если потом спецификация изменится, и нам все это, что мы меняли, придется менять снова? Наша цель - корректность готового подукта (под готовым понимается то, что он идет в эксплуатацию), ведь так? С чего бы нас должна волновать его корректность на стадии разработки? Есть ошибки? Пусть будут - процессу разработки они ничуть не мешают, а значит, и исправлять их смысла нет.
То есть я вот к чему - типы позволяют доказать, что наша программа соответствует некоторому подмножеству спецификации. Если спецификации пока нет - доказывать нечего. Если спецификация меняется - то мы тратим ресурсы на зряшнюю работу, потому что актуально только последнее доказательство. Все предыдущие нам ничего не дали. Возникает вопрос - зачем эти траты? Мы можем получить тот же результат, добавив типы _в конце_, но при этом экономим на начальной и средней стадии. Где в моих рассуждениях ошибка?
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-17 08:36 am (UTC)
>Я имел в виду не конкретную одну ошибку, а в общем, конечно же. то есть полезнее уметь быстро локализовывать и исправлять любую ошибку, чем уметь обнаруживать некий узкий класс ошибок на раннем этапе.

Вы считаете, что эти две вещи мешают друг другу? Серьёзно?

>А зачем нам делать изменения всюду, где это необходимо, если потом спецификация изменится, и нам все это, что мы меняли, придется менять снова?

Почему мы будем менять "всё это, что мы меняли"?

Уберите квантор всеобщности, у вас даже вопроса не получится.

>Если спецификация меняется - то мы тратим ресурсы на зряшнюю работу, потому что актуально только последнее доказательство. Все предыдущие нам ничего не дали.

Наоборот. Дали. Очень много дали. Они показали нам, что программы, правильно реализующие все предыдущие спецификации, не удовлетворяет каким-то критериям.

Все предыдущие спецификации не содержали чего-то важного, что должна содержать следующая.

Мы более уверены, что это не ошибка программы, чем если бы типов не было.

Собственно, именно по этому критерию я и выбрал когда-то Хаскель. Как язык для написания прототипов, инструмент для исследования пространства решений, дающий при этом максимальные (на тот момент) гарантии правильности (соответствия задуманному) реализации решения.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 09:33 am (UTC)
> Вы считаете, что эти две вещи мешают друг другу?

Нет, конечно, с чего вы взяли?

> Уберите квантор всеобщности, у вас даже вопроса не получится.

Хорошо:
А зачем нам делать изменения всюду, где это необходимо, если потом спецификация изменится, и нам то, что мы меняли, придется менять снова?

> Наоборот. Дали. Очень много дали. Они показали нам, что программы, правильно реализующие все предыдущие спецификации, не удовлетворяет каким-то критериям.

А зачем нам это знание?

> Мы более уверены, что это не ошибка программы, чем если бы типов не было.

Не понял. Что именно не ошибка программы?
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-18 08:34 pm (UTC)
>> Вы считаете, что эти две вещи мешают друг другу?
>Нет, конечно, с чего вы взяли?

Они у вас противопоставляются. "то есть полезнее уметь быстро локализовывать и исправлять любую ошибку, чем уметь обнаруживать некий узкий класс ошибок на раннем этапе."

"Полезней достичь одного, чем другого." Если нельзя достичь этих целей вместе, значит, они как-то мешают друг другу.

Не так? Я неправ?

>Хорошо: А зачем нам делать изменения всюду, где это необходимо, если потом спецификация изменится, и нам то, что мы меняли, придется менять снова?

Потому, что следующая спецификация обязательно будет результатом переработки предыдущей.

Если это не так, то спецификации нам спускают сверху, мы работаем в Индии и получаем $20 в сутки.

>> Наоборот. Дали. Очень много дали. Они показали нам, что программы, правильно реализующие все предыдущие спецификации, не удовлетворяет каким-то критериям.
>А зачем нам это знание?

Для того, чтобы двигаться в правильном направлении. Всем проектом в целом.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-19 03:21 am (UTC)
> Не так? Я неправ?

Не так. Вы не правы. Я хотел сказать, что если у нас есть первое, то ценность второго резко падает. То есть - если мы можем легко найти и исправить ошибку, то цена ее необнаружения на ранней стадии уменьшается.

> Потому, что следующая спецификация обязательно будет результатом переработки предыдущей.

Это ответ на какой-то другой вопрос.

> Для того, чтобы двигаться в правильном направлении.

И как оно помогает двигаться? Вообще для меня очень неожиданна мысль о том, что программа может обладать некоторыми соответствиями спецификации, о которых нам неизвестно. Откуда эти соответствия взялись-то? "Случайно вышло"? Изначально программа ничему не соответствует и только потом мы доказываем, что определенные соответствия есть, так? По-моему, можно считать, что нету никаких других соответствий, кроме доказанных, потому что вероятность такого "случайно вышло" пренебрежимо мала.
(Reply) (Parent) (Thread) (Expand)
(no subject) - (Anonymous) Expand
From: (Anonymous)
2011-01-17 05:09 am (UTC)
Кстати, еще хотелось бы узнать - что за бред вы несете на счет спецформ? Языков без спецформ не существует, даже в обычном лямбда-исчислении есть спецформа - сама лямбда. И у вас в хаскеле полно спецформ - do, let, class, type etc., причем их больше чем в лиспе, и никого не возмущает, что они не передаются в функцию. Спецформа ничем не отличается от кейворда в обычном языке.
(Reply) (Parent) (Thread)
[User Picture]From: thesz
2011-01-17 08:42 am (UTC)
>Спецформа ничем не отличается от кейворда в обычном языке.

Она выглядит, как функция.

Как и макрос.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 09:40 am (UTC)
Во-первых - какие проблемы с тем, что она выглядит как функция?
Во-вторых - в хаскеле тоже так, вот "type a = b" это выглядит в точности как определение функции type с одним аргументом: "f a = b"
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 10:15 am (UTC)
"Во-вторых - в хаскеле тоже так, вот "type a = b" это выглядит в точности как определение функции type с одним аргументом: "f a = b""
Malformed head of type or class declaration
Может вам составить какое-то представление о хаскеле сначала? Это может положительным образом сказаться на уровне дискуссии.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 03:05 pm (UTC)
> Может вам составить какое-то представление о хаскеле сначала?

f x = 5
type T = Char

все работает, чяднт?
(Reply) (Parent) (Thread) (Expand)
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
[User Picture]From: thesz
2011-01-18 08:51 pm (UTC)
>Во-вторых - в хаскеле тоже так, вот "type a = b" это выглядит в точности как определение функции type с одним аргументом: "f a = b"

Как я понимаю, вы не знаете Хаскель вообще никак.

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

Эта область обещает быть чрезвычайно плодовитой. Её основание, положенное учеником Колмогорова Мартином Пером Лёфом, не содержит противоречий, в отличии от систем типов большинства языков программирования (и Хаскеля в том числе). Используя её, я могу заставить программиста доказать существование определённого объекта, чтобы он построил доказательство его существования, написав программу. Я говорю "заставить" потому, что у него не будет шансов допустить ошибку.

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

Так что, если не хотите всю жизнь писать "type a = b" в спорах "Лисп супротив Хаскеля, Лисп играет белыми", посмотрите на Coq или Agda2 (или на Qi, он на Лиспе, но на последний не советую - фигня-с, судя по всему). Эти языки могут сэкономить кучу времени при создании действительно сложных систем.

Как сейчас мне экономит время Хаскель, но ещё лучше.
(Reply) (Parent) (Thread) (Expand)
(no subject) - (Anonymous) Expand
(no subject) - (Anonymous) Expand
[User Picture]From: freiksenet
2011-01-18 11:53 am (UTC)
Вообще существует. Например kernel language.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-18 03:10 pm (UTC)
И еще комбинаторное исчисление. Но мы же говорим о чем-то, что можно практически использовать? кстати, само определение функции в хаскеле - тоже спецформа, которая синтаксически не отличается от аппликации. f x = 5 - применяем функцию f к аргументам x, =, 5.
(Reply) (Parent) (Thread)
[User Picture]From: freiksenet
2011-01-18 09:43 pm (UTC)
Ну kernel language, если бы у него был рабочая имплементация, вполне был бы юзабельным.
(Reply) (Parent) (Thread)
From: (Anonymous)
2011-01-16 04:24 pm (UTC)
> Racket - это pure scheme плюс куча библиотек.

Вот не надо. Racket (имею в виду именно язык Racket) не имеет обратной совместимости со схемой. Схема хостится в Racket (сейчас я имею ввиду фреймворк) под #lang, но так в нем может хоститься все, что угодно. И, кстати, с использованием сторонних схемобиблиотек там, по-моему, были какие-то траблы, хотя я на этот счет не уверен.
(Reply) (Parent) (Thread)