50 лет языку LISP

> напиши компилятор Явы на яве, паскаля на паскале, с++ на С++ (или C++0x, чего уж там), D на D, лиспа на лиспе, и сравни код.
> И кто после этого "язык всех языков"?

forth

>>Решает только проблему наличия самой себя

>она упрощает проектирование, отбивая тебе руки при попытках сделать "как-нибудь".

Да те кто пишет "как-нибудь" чихали на Хаскелл. Они про него не слышали вообще.

>> треды-треды.. а потом локи, семафоры, критические секции.. вот нафига?

> Хм, вы можете предложить универсальный механизм параллельной работы программ[ы] на компьютере с X процессорами и X*Y ядрами без всего перечисленного?

См. MPI, Erlang. А вот вы можете предложить механизм параллельной работы программ[ы] на Z компьютерах, использующий только локи, семафоры, критические секции?

2 Absurd (*) (22.10.2008 0:30:09)

> Да те кто пишет "как-нибудь" чихали на Хаскелл. Они про него не слышали вообще.

В этом - согласен. Как и в том, что о нём (ну, по крайней мере) следовало бы знать! А о Lisp (да, хотя бы о пародигмах) - следовало бы иметь хоть общие знания... За сим, прощаюсь... Алыверды.

Ну, ну. Один тут написал, что в Лисп нет ООП и еще после этого делает выводы о пригодности сего языка в Ынтерпрайзе. Т.е. ты считаешь, что этот человек еще что-то знает о Лиспе после таких логических посылов? На мой взгляд, чтобы говорить о предмете, надо хотя бы знать его. Лично я в своей компании программирую на джаве - сделал своей фреймворк для решения кое-каких проблем. Если бы я знал тогда Лисп, то делал бы именно на Лиспе, так как java, на мой взгляд, плохой язык. У java лишь несколько хороших достоинств - это хорошие библиотеки, поддержка, и более или менее хорошие интегрированные среды (правда, тормознутые по самые нихачу). Но как язык до Лиспа он не дотягивает. Тоже самое можно сказать о Си, С++. Эти языки в какой-то степени случайно стали популярными. Другими словами, если язык популярен, то это не значит, что он лучший. Кстати, сейчас подумываю о переводе своего фреймворка на Лисп. В этом вижу массу достоинств.

Ну уморил. Можно на любом языке написать тормознутый архиватор. К примеру, добавь в конец бесконечный цикл на любом языке и получишь бесконечно тормознутый архиватор. Отсюда ведь не следует, что тот или иной язык плохой или хороший. Хороший язык ведь нужно еще уметь использовать. Что касается Лиспа, то очень много средств для оптимизации. Можно, например, явно указывать типы переменных, компилировать, а не интерпретировать код, указывать разные параметры для оптимизации и т.д.

+1. Только у меня на питон писано

> Поковырялся немного в CCL, реализацию DIRECTORY мне лень осиливать, но open и probe-file получилось заставить работать с юникодными именами. Вот http://trac.clozure.com/openmcl/ticket/358#comment:1 объяснение, почему оно само не работает пока что.

Оно или всё работает, или всё не работает :) - если правильно сделано. В офтопике системные вызовы со строками идут в двух вариантах - с кодировкой текущей локали и в уникоде (UCS-2). Используя вторые на локаль можно даже не смотреть...

>См. MPI

в связке с GCL упоминается... надо будет глянуть.

> Erlang

ну мы же не о нём? :)

>А вот вы можете предложить механизм параллельной работы программ[ы] на Z компьютерах, использующий только локи, семафоры, критические секции?

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

> Вообще-то Си старше структурного программирования.

Приплыли... В Си есть все конструкции структурного программирования, как и в прочих детях Алгола.

> Что-нибудь еще есть?

Про тернарный оператор тебе уже говорили.

> Лямбда - это вообще математика. С тем же успехом можно сказать, что арифметику все языки позаимствовали из Фортрана.

А так и есть - подход к реализации арифметики (а он далеко был не единственно возможным) сформировался именно в Фортране.

> Заимствования. Покажи заимствования.

Сборка мусора, хотя бы.

> Вот это и есть место Лиспа в эволюции языков программирования.

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

> для меня, по крайней мере

Думаешь, кого-то это колышет, что там "для тебя"?

И макры.

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

> Кстати, советую обратить внимание на секцию "Example", можно ли такое делать на лиспе?

На Лиспе можно много более сложные вещи делать, причём в compile time (про Template Haskell знаю, претензии к нему изложены выше).

На NewLisp такой код:

(begin (context 'MyNamespace) (set 'x 1 'y "test" 'z (x y)) (dotree (s 'MyNamespace) (print s)) )

делает примерно то же самое, что и следующий код на C#:

using System; using System.Collections; using System.Reflection; namespace ReflectionTest { public class MyNamespace { public int x = 1; public string y = "Test"; public ArrayList z = new ArrayList(); public static void Main() { MyNamespace obj = new MyNamespace(); FieldInfo[] s_list = obj.GetType().GetFields(); obj.z.AddRange(new object[] { obj.x, obj.y }); foreach (FieldInfo s in s_list) { Console.Write(s.Name); } } } }

Как можно C# код сделать короче? А то чето дофигищи букаф. (Как сделать lisp код длиннее, не предлагать :) )

>(begin (context 'MyNamespace)
>  (set 'x 1 'y "test" 'z (x y))
>  (dotree (s 'MyNamespace) (print s)))

В C# и во всех остальных лиспах, где нет библиотечной функции dotree,
код будет больше по той простой причине, что в них нет библиотечной
функции dotree(). Пример некорректен, напиши библиотечную функцию,
и все будет одинаково.

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

>> Вообще-то Си старше структурного программирования.

>Приплыли... В Си есть все конструкции структурного программирования,

"Все" - это какие? IF и DO .. WHILE? Эти конструкции есть в куче языков. И еще раз повторяю - структурное программирование появилось гораздо позже и Лиспа, и Алгола, а структурно прогарммировать можно на любом языке.

> как и в прочих детях Алгола.

Ну то есть Си таки дитя Алгола.

> Про тернарный оператор тебе уже говорили.

Это Алгол68 с его выражениями.

>> Заимствования. Покажи заимствования.

>Сборка мусора, хотя бы.

ОК, хотя это не столько фича языка, сколько исполняющей системы.

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

Я всё время учусь. Тебе тоже не мешало бы подучиться, кстати.

>> для меня, по крайней мере

>Думаешь, кого-то это колышет, что там "для тебя"?

Вообще не думаю об этом.

Есть ли на ЛОРе пользователи коммерческих ЛИСПов? Что пользуете, почем и почему? Просто интересно.

class MyClass
{ 
	public static int x = 1; 
	public static string y = "Test";
	public static object[] z = new object[] { x, y };
	
	public static void Main()
	{
		foreach (var s in typeof(MyClass).GetFields()) 
			System.Console.Write(s.Name); 
	} 
}

usingи забыты и заброшены :) Без пабликов будет еще чуть короче + static object x=1,y="test"; ну и вроде как дальше - да, практически чистое излишество синтаксиса сшарпа в абсолютной велечине :) Спасибо)

А они в моем примере, заметте, не нужны. Он отлично компилируется и выполняется без них. Без пабликов не получим списка полей. Нужно будет задать дополнительный параметр в GetFields - System.Reflection.BindingFlags.NonPublic.

Излишество синтаксиса? Нет. Это дополнительная обязательная семантика. Ваш код можно будет вызвать повторно в том виде, в котором вы его написали? А чем определена область его видимости? А куда выведет значения оператор print? Как вы можете быть уверены, что переменная x у вас не будет типа long long long ... long int?

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

>>Сборка мусора, хотя бы.
> ОК, хотя это не столько фича языка, сколько исполняющей системы.

без неё невозможны полноценные замыкания. Так что фича языка.

> Это Алгол68 с его выражениями.

тогда varargs в Си и списки в лиспе. Или в Алголе были открытые массивы переменной длины?

>Это Алгол68 с его выражениями.

алгол - это тоже лисп, да. См. R-Lisp http://www.zib.de/Symbolik/reduce/infopool/rlisp88.html
а в первом лиспе не было S-выражений, были M-выражения

Мне тут еще один вариант в голову пришел :)

class MainClass { 
	public static void Main() {
		var c = new { x = 1, y = "Test", z = new System.Collections.ArrayList() };
		c.z.Add(c.x); c.z.Add(c.y);
		foreach (var s in c.GetType().GetProperties()) 
			System.Console.Write(s.Name); 
	} 
}

http://animelook.ru

А на Python можно еще проще:

z = (x, y) = (1, "Test")
print dir()

Ура Питону.

>Ура Питону. -- Пашол учыть пайтон

>еще один вариант нууууэтааа 3й шипр уже. Хотя оценяю: симпотный код, камрад :)

>>>Сборка мусора, хотя бы.

>> ОК, хотя это не столько фича языка, сколько исполняющей системы.

> без неё невозможны полноценные замыкания. Так что фича языка.

Замыкания (которые только и являются фичей языка) возможны и без сборки мусора (а "полноценность" - это вопрос скользкий). Но всё это не имеет отношения к Си - в нем ни сборки мусора, ни замыканий нет ;)

"Mostly, of course, C is Thompsonized BCPL (that is, B) with types. You don't have to look too hard to find PL/1 and Fortran, either. " (c) D.Ritchie. И заметь - никакого Лиспа. Это не делает Лисп хуже, но уж точно ставит крест на попытках фанбоев сделать его "отцом всех приличных языков".

> тогда varargs в Си и списки в лиспе.

Круто O_o Т.е. переменный список аргументов - это аналог лиспового списка? Натяжка, мягко говоря. Единственное, что можно делать с va_list - это пройти по его элементам, причем об их типах придется догадываться самому; "половина" va_list - это уже не . А если принять во внимание, что в конце 60-х и начале 70-х компиляторы многих языков программирования просто не проверяли типы передаваемых аргументов, то получиться, что они все сделаны под влиянием Лиспа %)

>> Это Алгол68 с его выражениями.

> алгол - это тоже лисп, да.

А, ну тогда ой. Как всё просто, оказывается - все влияьельные/интересные языки являются Лиспами, и никаких гвоздей %) Мелочи типа статической типизации, отсуствия замыканий и лямбд, да той же сборки мусора - какая фигня :D

Кстати, нельзя ли получить полный список Лиспов? ;)

> а в первом лиспе не было S-выражений, были M-выражения

В первом Лиспе были именно S-выражения. М-выражения планировались к реализации, но реализованы никогда не были (после реализации синтаксиса на S-выражениях, M-выражения стали не нужны).

> Кстати, сейчас подумываю о переводе своего фреймворка на Лисп.
+1 только с perl-а

http://faramir.ugent.be/dungeon/histtalen2.gif

>http://faramir.ugent.be/dungeon/histtalen2.gif

у них там Haskell с ошибкой написан :( да и схема вообще кривая какая-то: ни тебе Gopher, ни Miranda, ни Lazy...Haskell как прямой потомок Scheme - жесть какая-то

> http://faramir.ugent.be/dungeon/histtalen2.gif

Хаскел в виде потомка Схемы - это жесть %)

Подбросить дров в дискуссию, что-ли? Ладно.

"Complex CISC instructions may not match Lisp well" [RAM93]
heap со сборщиком мусора - не наш способ (наиболее эффективного программирования современных машин - stock hardware).
Реал-тайм, embedded, строго контролируемое поведение вплоть до контроля количества тактов на операцию, ограниченные ресурсы, и вместе с тем - перемалывание сколь угодно огромных массивов данных, не копируя эти данные, а лишь манипулируя пойнтерами - вот Ъ путь. Лиспы, хаскели, жавы - это heap + GC. C - единственно Ъ.

P.S. In Lisp, writing a slow program is easy.
In C writing a slow program is almost impossible. (C)
C programming is difficult.
Lisp programming is easy, but only to a point. (C)
P.P.S. Учите C, господа

>перемалывание сколь угодно огромных массивов данных, не копируя эти данные, а лишь манипулируя пойнтерами - вот Ъ путь.

Это подразумевает что данные будут храниться таки в хипе. Что до работы без GC, то этот аспект в Си не проработан. Оптимально было бы сделать cactus stakes из хипов разного назначения.

>In Lisp, writing a slow program is easy. In C writing a slow program is almost impossible.

"Ты прав. Перепишу-ка я своего хомяка на асме" (С) анонимус с ЛОР

>C programming is difficult.

Ничего сложного на самом деле. Но долго.

Тогда уж лучше http://oreilly.com/pub/a/oreilly/news/languageposter_0504.html

>> перемалывание сколь угодно огромных массивов данных, не копируя эти данные, а лишь манипулируя пойнтерами - вот Ъ путь.

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

Ничего такого это не подразумевает.

> Что до работы без GC, то этот аспект в Си не проработан.

Ой, правда? %)

>> Что до работы без GC, то этот аспект в Си не проработан.

>Ой, правда? %)

Твой стиль общения действительно можно определить как "подпёздывание". malloc() / free() это слишком рудиментарно и при этом дорого. Не позволяет для разнородного кода индивидуально подбирать стратегии.

>malloc() / free() это слишком рудиментарно и при этом дорого. Не позволяет для разнородного кода индивидуально подбирать стратегии.

это только так кажется. Стратегии выбираются на ином уровне. Это заинтересованные (в той или иной степени) стратеги-теоретики вешают лапшу в журналах про сферических коней в вакууме, безопасность и прочее. На практике оказывается что самый тормозной и баговый софт - написан на самых безопасных и самых высокоуровневых абстракциях, а самый стабильный софт (включая почти весь софт для хардваре, большинство кода линукса и всё остальное - _работающее_) - пишутся на "наименее защищённом" и наиболее приземлённом к железу C а то и ассемблере. Может проблема всё-же с голов^опытом?
Заставьте шеф-повара готовить не страшным с точки зрения обывателя ножом-тесаком, а пилочкой, которой и дети не порежутся - посмотрим что он Вам скажет :) (нет среди знакомых поваров? ну обсудите с ним - безопасность его пальцев и чем ему резать :)

а malloc/free совсем не дорогие - если вы всё контролируете, и уж тем более - если ими не пользуетесь ;)
Обрабатывайте всё в стеке, не копируя потоки/файлы в heap. Благо почти всему есть разумный предел, в отличие от сферических коней...
Ну сделаете свой менеджер памяти, оптимизированный под задачу, если надо. Это же фан - когда знаешь, что более эффективно под задачу написать уже нельзя ;)

вообще не хочется опять спорить - старо как мир. Обсосали уже в середине 90-х (когда жава появилась), и основные флеймы закончились (уже в этом веке?). А C (и даже фортран) как мы учили когда-то - так и стоит, и пишется благодаря линуксу на нём всё больше. Жаль что универы не стековые калькуляторы/шашки/базы данных/хеши и менеджеры памяти первокурсников заставляют на C и асме писать, не shanting-yard Дейкстры штудируют (а ведь машины по-прежнему - стековые) а больше прививают привычку демагогии на темы семантического сахара в функциональных языках, вместо того чтобы делом заниматься и мочь написать, например, начинку какого-то блока замолёта или мед. оборудования. А функциональными языками и ИИ увлекались и 15-20 лет назад как и сейчас. Мне один капиталист рассказывал как в своё время они увлеклись ИИ и сколько денег проср^фукали, пока не поняли, что всё это - сферические кони и безусловно когда-то придёт, но кушать надо сегодня (15 лет назад, между прочим). Нам основы Лиспа и Пролога вообще-то тоже читали (даже экспертную систему авто-поломок писал на курсовик). Ну и где сегодня приложения, после почти 2 десятилетий? (хотя Пролог уважаю, конечно, как и Лисп). Спуститесь на землю, господа. И посмотрите на свои гаджеты.

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

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

Для кого ты вообще эту речь заготовил? Для меня? Я говорил про "дорого" а не "безопасно". Я на безопасности вообще не циклюсь.

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

Перепиши своего хомяка на асме.

>а malloc/free совсем не дорогие - если вы всё контролируете, и уж тем более - если ими не пользуетесь ;)

Ну напиши Фаерфокс с применением только стека и статических переменных а не то он жрет как средняя JVM.

PS: Для malloc()'а можно придумать тучу реализаций, но одни будут быстрыми но фрагментировать память а другие фрагментировать память не будут, но будут иметь O(N) - лукапы. Еще тут можно приплести многотредовость, которая в одних частях проекта нужна, а в других не нужна. А куча в Си одна.

>Мне один капиталист рассказывал как в своё время они увлеклись ИИ и сколько денег проср^фукали, пока не поняли, что всё это - сферические кони и безусловно когда-то придёт, но кушать надо сегодня (15 лет назад, между прочим).

Учитывая какой сейчас прогресс на распознавании и синтезе речи, распознавании образов и прочих близких к "волшебству" вещах, можно предположить что ситуация с AI будет раскручиваться экспоненциально в "Thе Next Big Thing", после кризиса конечно. Самый долбаный ноутбук сейчас имеет сканер отпечатков пальцев.

>Перепиши своего хомяка на асме.

для разных задач - различные языки.
Я не предлагаю писать хомяки на C (хотя в принципе можно. только дорого). ПХП и ява - самое то. Но никак не на ЛИСПе конечно (если большие хомяки).

>Ну напиши Фаерфокс с применением только стека и статических переменных а не то он жрет как средняя JVM.

Фаерфокс - тоже - не одного программера задача, а следовательно - Ц++ там больше подойдёт.
Зачем всё под одну гребёнку?
Просто не надо нападать на C (некоторые здесь этим экстремизмом страдают).

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

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

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

>Но никак не на ЛИСПе конечно (если большие хомяки).

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

>>Ну напиши Фаерфокс с применением только стека и статических переменных а не то он жрет как средняя JVM.

>Фаерфокс - тоже - не одного программера задача, а следовательно - Ц++ там больше подойдёт.

Ц++ не решил проблему с управлением памятью, поэтому мы и имеем аппетиты Фаерфокса.

>Просто не надо нападать на C (некоторые здесь этим экстремизмом страдают).

На Си никто не нападает - это замечательный кроссплатформенный ассемблер.

А скольких человеко-минут в глобальном масштабе (и ошибок) можно было-бы избежать - если бы оракловый девелопер не выё^Wпендривался с лиспом в tnsnames а написал просто и ясно:

OLAPDEV.ADDRESS.PROTOCOL = TCP
OLAPDEV.ADDRESS.HOST = ABRACADABRA
OLAPDEV.ADDRESS.PORT = 1521
OLAPDEV.CONNECT_DATA.SERVER = DEDICATED
OLAPDEV.CONNECT_DATA.SID = OLAPDEV


вместо

OLAPDEV =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ABRACADABRA)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = OLAPDEV)
)
)

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

А вы найдёте людей - кто кроме вас сможет этот хомяк раширять?