Как вам язык Lisp?

[MasterGH]

Рис. 1 Как выглядит консоль "Common Lisp "

 

Почитал я тут про Lisp и как будто я обрел "крылья", но как только я что-то начал писать тут "же упал камнем вниз".

 

Вы представляете, на Lisp можно обращаться с кодом как с данными и с данными как с кодом. Это такое пьянящее чувство, когда все можно, когда все дозволено, когда программа может писать код как данные и затем исполнять его... Когда программа может строить код с условиями, а этот код будет строить по другим условиям еще код и так далее... Но как только ты начинаешь что-то писать, то у тебя реальность отбирает все, что ты представлял. Все мгновенно "выключается кнопкой". А именно, программист все равно должен задавать начальные алгоритмы и условия, как бы они потом не ветвились.   Т.е. ну никак, как бы ты не хотел, все равно задача получается из набора правил, заданных программистом, а не как самообучение. 

 

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

 

Мне кажется, что C++/С# ни чем не хуже Lisp. Где-то нащупать границу между кодом и данными. Например, данные в массиве будут и кодом, и данными... Но я не очень уверен.

 

Во всяком случае, я полагаю, на Lisp-е пишут меньше людей чем на C++, меньше чем на C#. Да и в вакансиях мне не попадался программист Lisp. Но все равно Lisp, чем-то захватывает.

 

1. Считаете ли вы язык Lisp чем-то интересным ? 

 

2. Уверены ли вы, что на C++/C# (или других) можно сделать альтернативу Lisp (очередями сообщений, делегатами, кортежами и прочими)? 

[Coder]

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

Python - http://habrahabr.ru/post/168083/

LUA - http://habrahabr.ru/post/237503/

 

Так зачем же вообще нужен Lisp, если есть Python и LUA?

 

 

2. Я думаю, то что на С++ реализовать можно абсолютно все, но окупится ли потраченное время.

 

P.S. Для WarCraft 3 Blizzard разрабатывали свой скриптовый язык JASS - https://ru.wikipedia.org/wiki/Jass

[keng]

1. Считаю интересным, но соглашусь с Кодером в том, что каждый язык - под свою задачу. Статистики популярности данного языка у меня нет.

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

[MasterGH]

Напишу, еще немного

 

1. На Лиспе хорошо пишут только те, кто пишут на нем большое количество времени. Несколько лет и более.

 

2. Лисп довольно сложен. Его специфичный синтаксис это первая причина, которая отталкивает от него. Язык практический мертвый, его никто не любит. Синтаксис большое препятствие.

 

3. Бот написанный на Лисп выиграл соревнование Google AI Challenge с большим отрывом. 3765 очков против второго места  3565

 

Язык Лисп снова жив. Многие им должно быть заинтересовались, но и должно быть многие забили на Лисп после нескольких часов разбора синтаксиса.

 

4. Генетический алгоритм space.invaders занял всего лишь 277 место по соревнованиям ботов...

 

5. Когда у автора бота, который на лисп работал 6 лет, спросили может ли учиться его бот. он ответил "Нет. Я могу!".

 

Цитата одно из пользователей про Лисп

>>Как то Лисповые программы более громоздко выглядят

Это ещё мягко сказано.

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

открытия/закрытия скобок при написании кода.

То есть.

Надавил "(" и сразу дави ")" и клавишу влево и потом и пиши. Потому что разобраться в этих

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

Уууууу.....

[gmz]

1 LOL

2 .....

 

5 мин искал код который он генерит.. даже идиот на масм и то круче кодит

хотя может плохой пример был xD

 

 

и до ОС для орбитальной станции.

типа такой? lol

[RockHammer]

Если нужен "язык программирования" в масштабе скриптов - то лучше использовать AutoIT. [Подробнее тут], ссылки есть в шапке и даже примеры использования. Мало ли кому пригодится...

Изменено 13 июля, 2015 пользователем RockHammer

[MasterGH]

Если нужен "язык программирования" в масштабе скриптов - то лучше использовать AutoIT

 

AutoIT интересный язык для работы с WinAPI.

 

Я не нашел инфы, что AutoIt может писать код, который пишет другой код в режиме рантайм, без перекомпиляции. А вот Lisp умеет.

Так зачем же вообще нужен Lisp, если есть Python и LUA?

Я что-то сразу не смог ответить на этот вопрос, т.к. он сформулирован так, что на него сложно прямо ответить. Все равно что сказать, зачем "нужен вилка, когда есть ложка и нож?". Вилка нужна чтобы было удобнее есть пищу, которую неудобно есть ложкой. А ложка для жидкой пищи. А нож чтобы разрезать, но не есть им. Где-то по аналогии и с языками. Языки могут выполнять одну и ту же задачу (например сложение, умножение, деление), а могут и не выполнять её (например, выполнять то, что нельзя сделать на другом языке). А могут выполнять удобнее в разной степени  - Lisp очень не удобен, поэтому его считают как мертвым языком. Но иногда я вижу определение, что это язык Бога. Там есть такие конструкции, как считать или не считать код кодом, а также списки, которые можно редактировать, а потом исполнять. Очень интересно. Однако синтаксис тяжелый.

[Coder]

Если нужен "язык программирования" в масштабе скриптов - то лучше использовать AutoIT. [Подробнее тут], ссылки есть в шапке и даже примеры использования. Мало ли кому пригодится...

 

Лучше бы ты не писал этого....

 

 

--------

 

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

Но все же, по-моему лучше использовать проверенную связку boost + python. Очень интересно, в чем будет лисп эффективнее питона в данном случае к примеру.

[keng]

В количестве скобок, я уверен.

[MasterGH]

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

 

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

 

 

Для сравнения.

 

1. Жесткая компиляция

 

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

 

2. Динамическое построение условий

 

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

 

Это был практический пример, который я испытал на ГУИ на делегатах, на C# по работе. Но если на C# я тосую функции в делегате, удаляю нужные и не нужные по разовым событиям, то в Lisp можно еще и условия в списках составлять и выполнять списки как код. По крайне мере я так понял. Т.е. сложные условия по простым выстраивать гораздо реже, а то и вообще разы, чем эти условия будут по циклу проходить.

[Гость]

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

[MasterGH]

А какая разница, что код сам себя строить будет

 

1. Построить код другим кодом легче, быстрее чем выстроить свитч кейсы (особенно имеет смысл когда свитч-кейс сильно ветвящийся)

2. Короткий код построения другого кода. Быстрее напишешь. Вызывается разово по ситуации.

3. Короктий код в активном частом цикле. Меньше тактов за время

 

 

>> А какая разница, что код сам себя строить будет, либо будет пробегать по одному "жесткому" (как ты сказал) циклу, если код все-равно не сможет себя построить так, как ты этого не задумывал (не предвидел) изначально - на этапе разработки. 

 

В случае который я привел с гуи меню, код я заранее знаю, но я не знаю как пользователь будет перемещаться по меню, чтобы его показывать. Меню очень вложенное было. Мне проще вклинивать условия в цикл без одной большой иерархии свитч кейс. Кликнул на кнопку - кусок кода поставил на отрисовку по указтелю на функцию - меню рисуется. Кликнул на другую - опять код поменялся (последовательность уаказателей на функции) - рисуется по-другому. Выходишь и входишь в разные уровни меню без запоминания всего пути и сравнения всех вариатов условий. А свитч кейс придется аккуратно ручками выстраивать по каждой кнопке и вложенности на ленте меню.

 

В случае Lisp программист может знать меньшее чем ему надо, а остальное более сложное будет формироваться по действиям в игре или по действиям пользователя.

 

 

>>А если это так (а оно так, иначе - это громадный минус языка, т.к. вообще неясно, как он себя построит, и как это скажется на оптимизации), то что мешает писать сценарии выполнения программы, вместо использования тех же свитчей?

 

На C# на делегатах все выстраивалось. Функции в делегатах перестраивались по тому пути, по какому был проход по меню пользователем и оно рисовалось по циклу без большого количества других условий в свитч кейс. Говоря простым языком, это были вызовы по указателям функций с историями указателей на функции. Последний указатель шел в цикл на рисование. Нужно было знать из какого меню в какое зашли и вернулись. Т.к. были меню, в которые можно было зайти из разных.

 

В случае с меню я привел - это единственный пример на практике. Все остальные условия я прописывал ручками

[Гость]

Честно говоря, я до сих пор не оценил "мощь" Lisp-а. Мне всегда нравилось, когда я вижу весь код, а не его обломки, и не то, что сочтет нужным показать мне сам язык. И при отладке это - значительный плюс. Что до циклов и условий - все зависит от конструкции кода, можно построить код как угодно, и проверка (по факту) будет всего одна.

Что там за случай с GUI меню, и зачем там "самостроящийся код" Lisp - я не знаю, но очень интересно узнать (а лучше - увидеть), как это меню живет, и имело-ли смысл втюхивать в него самостроящийся код.

[Coder]

Андрей, расскажи насчет компиляции, LISP же интерпретируется (как и Python/LUA), я немного не понимаю о чем ты.

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

Но очень хотелось бы увидеть на практике это или хотя бы что можно в теории при помощи этого сделать.

[MasterGH]

Про компиляцию ни чего не скажу, т.к. гуглить.

 

 

C# пример с GUI я привести не могу у меня даже нет проекта на руках, т.к. код я писал на заказ и не один день. Писать пример с нуля на C# не хочется, лень.

В данный момент времени, например надо использовать

 

Примерно так было бы без управления делегатами в цикле

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

Делагат это как массив из указателей на функции. Функции можно выполнять все сразу последовательно или определенную из набора. Я выполнял последнюю или убирал её при возврате из меню на кнопку. Так я избавился от огромного switch-а.

Объяснил как смог.

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

Я не могу быть уверенным что C# + делегаты хоть какое-то подобие Lisp, но я предполагаю, что это практический пример чтобы хоть чуть-чуть показать, что писать весь код программисту может быть невыгодно (и даже представьте не интересно). Т.е. на C# я могу тосовать функции и вести их иерархичность, а также вытаскивать и вставлять в иерархию и меню будет рисоваться, и обрабатываться без огромных свитчкейсов.

Возможно мой пример C# и делегаты неверны в качестве примера, который можно было бы успешно сделать в Lisp. Мне Lisp видеться куда мощнее, но куда девать эту мощь? Именно, на создание ботов. Я пытаюсь сделать бота для файтинга эмулятора под Super Nintendo. Удерживание клавиш по времени по данным из памяти избегая огромные свитчкейсы. Увеличение количество комбо ударов служит обратной связью. Чтобы программа искала условия и действия на эти условия. Вот почему Lisp мне интересен

Такие дела.

switchN (){	...	case N: 			// уровеньN ленты меню		switch1 ()		// уровень1		{		  case C:		// уровень2			switch2 ()			{			  case F:	// уровень3			  // Обрабтка попадания в область из ряда областей (зависит от вложения)			  // Визуальное Поведение кнопки			  // Реакции кнопки			  break;			}		  }		}	}}

switchN ()	...	case N:		switch1 ()		{		  case A:			switch2 ()			{			  case D:			  break;			  case E:			  break;			  case F:			  break;			}		  break;		  case B:			switch2 ()			{			  case D:			  break;			  case E:			  break;			  case F:			  break;			}		  break;		  case C:			switch2 ()			{			  case D:			  break;			  case E:			  break;			  case F:			  break;			}		  break;		}	...}