Здравствуйте, cl-user, Вы писали:
CU>Типизировать параметры функций и результат можно, нужно, и почти везде так и пишут (если хотят скорости). И это даёт ускорение, ибо убирает проверки при использовании типизированных данных (из мне известных только совершенно динамический clisp на типизацию почти не обращает внимания, но у него и компиляции в натив нет). НО — вывода типов [практически] нет, поэтому указывать тип приходится довольно часто. И в макрах тоже с типами "не поиграешь", если только не заставлять их явно указывать.
Сообщения, в теме, лучше читать последовательно. Речь не о Лисп или Комон Лисп вообще, а о конкретной реализации — Clozure
Здравствуйте, cl-user, Вы писали:
CU>А это значит не "Ерниченье":
VD>>Они там какую-то статическую типизацию вводят или язык все равно динамически-типизированным остается?
CU>когда указание типов описано в стандарте фиг знает в каком году, на совести реализаторов лишь использование этой информации?
Язык все же называется не Комон Лисп, а Кложур. Не на ходишь, что они могли просто наплевать на стандарт Комон Лиспа?
Мне действительно интересно что скрывается под словами "быстрый компилятор". Ведь если тупо генерировать байткод который будет заниматься рантайм-проверками и конвертацями типов, то скорости особо не прибавится. Вот мне и стало интересно, может ребята что-то новенькое, интересное придумали...
CU>Встречное предложение: ну не надо очередной раз подчёркивать своё отношение к языкам !N.
У тебя какой-то синдром больного самолюбия. Даже не САМОлюбия, а ЛИСПОлюбия.
Спокойно! Не все вопросы пытаются задеть твой любимый язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Язык все же называется не Комон Лисп, а Кложур. Не на ходишь, что они могли просто наплевать на стандарт Комон Лиспа?
Хм, странно. http://www.clozure.com/clozurecl.html "Clozure CL is a fast, mature, open source Common Lisp implementation"
Или ты таки имел в виду не Clozure а Clojure? Так и там можно и нужно всё типизировать
VD>Мне действительно интересно что скрывается под словами "быстрый компилятор".
Я всегда думал, что быстрый компилятор и компилятор, порождающий быстрый код — "две большие разницы". Не?
VD>Ведь если тупо генерировать байткод который будет заниматься рантайм-проверками и конвертацями типов, то скорости особо не прибавится.
А если понасовывать типов во все места, то рантайм-проверки и конвертации типов останутся только на стыке "динамика-статика".
VD>Вот мне и стало интересно, может ребята что-то новенькое, интересное придумали...
Интересное кратко написано на вышеуказанной странице. Из бросающегося в глаза — одна из немногих свободных реализаций CL с поддержкой тредов под Windows. Практически всё остальное есть у древнего SBCL (разве что кроме поддержки маков, и то не уверен)
VD>У тебя какой-то синдром больного самолюбия. Даже не САМОлюбия, а ЛИСПОлюбия.
Да нет такого. Это было простое "зуб за зуб" О недостатках семейства CL я и сам знаю. В том числе и о тех, которые "преодолены" в твоём любимом N =P
Здравствуйте, cl-user, Вы писали:
CU>Хм, странно. http://www.clozure.com/clozurecl.html "Clozure CL is a fast, mature, open source Common Lisp implementation"
Да в них сам черт ногу сломит .
CU>Или ты таки имел в виду не Clozure а Clojure? Так и там можно и нужно всё типизировать
Замечательно, что можно. Не очень здорово, что нужно.
Интересно, а есть реализации лиспа поддерживающие вывод типов и без аннотаций обеспечивающие генерацию быстрого машинного кода?
VD>>Мне действительно интересно что скрывается под словами "быстрый компилятор".
CU>Я всегда думал, что быстрый компилятор и компилятор, порождающий быстрый код — "две большие разницы". Не?
Нда, не могу не согласиться . Я, конечно, имел в виду второе.
CU>А если понасовывать типов во все места, то рантайм-проверки и конвертации типов останутся только на стыке "динамика-статика".
А приятно ли программировать когда нужно "понасовывать типов"?
CU>Интересное кратко написано на вышеуказанной странице. Из бросающегося в глаза — одна из немногих свободных реализаций CL с поддержкой тредов под Windows. Практически всё остальное есть у древнего SBCL (разве что кроме поддержки маков, и то не уверен)
А что же вместо потоков под виндой применяется то (в других реализациях)?
VD>>У тебя какой-то синдром больного самолюбия. Даже не САМОлюбия, а ЛИСПОлюбия.
CU>Да нет такого. Это было простое "зуб за зуб" О недостатках семейства CL я и сам знаю. В том числе и о тех, которые "преодолены" в твоём любимом N =P
Про зуб не понял. Видимо я его как-то незаметно отхватил .
На самом деле всего не охватишь. Но я без шуток считаю лисп "знаковой фигурой" и уважаю этот язык (или языки?) за чистоту концепций. Но жить в мире потерянных скобок мне как-то тяжело. Да и динамику я не люблю.
Собственно в N =P (с) я как раз и увидел те самые концепции лиспа но базирующиеся на современной высокопроизводительной платформе и языком с приятным синтаксисом (главное с синтаксисом!).
Так что не надо думать, что когда я спрашиваю про лисп, то обязательно хочу поколебаться над аксакалом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
CU>>Так и там можно и нужно всё типизировать
VD>Замечательно, что можно. Не очень здорово, что нужно.
Ну... да =)
VD>Интересно, а есть реализации лиспа поддерживающие вывод типов и без аннотаций обеспечивающие генерацию быстрого машинного кода?
ещё нет (ну или я не знаю о такой)
CU>>А если понасовывать типов во все места, то рантайм-проверки и конвертации типов останутся только на стыке "динамика-статика".
VD>А приятно ли программировать когда нужно "понасовывать типов"?
когда пишу — больших неудобств не испытываю (всё равно в голове типы "где-то рядом"). Когда читаю — некоторая избыточность "несколько утомляет"
VD>А что же вместо потоков под виндой применяется то (в других реализациях)?
А чем можно заменить многопоточность? В том смысле когда нужна именно _многопоточность_ =)
VD>На самом деле всего не охватишь. Но я без шуток считаю лисп "знаковой фигурой" и уважаю этот язык (или языки?) за чистоту концепций. Но жить в мире потерянных скобок мне как-то тяжело. Да и динамику я не люблю.
После того как "въехал", про потерянные скобки хочется спросить "А что это?" Ну да — notepad тут не помощник
VD>Собственно в N =P (с) я как раз и увидел те самые концепции лиспа но базирующиеся на современной высокопроизводительной платформе и языком с приятным синтаксисом (главное с синтаксисом!).
"N =P" — это N и =P ака :-P
К синтаксису я довольно равнодушен. "Типизированный AST" — это приятно. К стати, а mbase ты "щупал"? Если "да" — что скажешь? (кроме скобок )
А вот "современная высокопроизводительная платформа" оставила для меня N "за бортом" (ну или меня "за бортом" N)
VD>Так что не надо думать, что когда я спрашиваю про лисп, то обязательно хочу поколебаться над аксакалом.
Ок. Возможно я увидел дракона там, где его не было
Здравствуйте, cl-user, Вы писали:
VD>>А что же вместо потоков под виндой применяется то (в других реализациях)?
CU>А чем можно заменить многопоточность? В том смысле когда нужна именно _многопоточность_ =)
А что за слова были про поддержку нэйтив-средов?
CU>"N =P" — это N и =P ака :-P
Не, дурак, понял. Я просто тебя так же подкалывал.
CU>К синтаксису я довольно равнодушен. "Типизированный AST" — это приятно. К стати, а mbase ты "щупал"? Если "да" — что скажешь? (кроме скобок )
А ты и Метопрограммер — это не одно лицо?
Как и все тут собравшиеся я в основном варюсь в своем мире изредка заглядывая в другие.
MBase я поглядел, но не глубоко. Он меня интересовал в первую очередь тем, что в нем был реализован PEG-Пакрат-парсер. Но оказалось, что эффективность этой реализации оставляет желать лучшего. В последствии оказалось, что она и не могла быть эффективной в следствии того что чистый Пакрат — это никуда не годный алгоритм имеющие очень высокие накладные макросы (хотя и линейные в тоерии, но с очень высокой "константой"). Кроме того там конечно было интересно наличие встроенного пролога (до него я так и не дошел). Ну, и конечно, сама идея фрэймворка для создания языков.
Шутки шутками, а скобки (точнее чтение кода в S-выражениях вместо синтаксиса) и остановили (в первую очередь) от изучения исходников. Хотя они были доступны, что очень приятно.
Тебе MBase скорее всего тоже не понравится так как он как и Немерле заточен на "ссовременную высокопроизводительную платформу".
Идеологически MBase — это очень интересная и перспективная разработка. Но путь Немерла мне нравится значительно больше. Все же MBase — это фрэймворк для разработки языков, а Немрле — это гибкий и расширяемый язык. Большую часть задач на нем можно писать вообще не расширяя язык и не создавая макросов. Но если надо, то можно использовать всю мощь "путя лиспа".
Следующую версию Немерла мы будет делать с учетом подхода проработанного в MBase, т.е. будет использовать PEG-парсер (правда не на основе алгритма Пакрат).
CU>А вот "современная высокопроизводительная платформа" оставила для меня N "за бортом" (ну или меня "за бортом" N)
Не понимаю что в ней плохого. Ну, да это уже твои тараканы... Тебе с ними и жить.
Собственно лично я буду не против если кто-то создаст нэйтив-бэкэнд к компилятору немерла. Учитывая, что в следующей версии мы видимо откажемся от системных библиотек читающих и записывающих метаинформацию сборок, то это будет относительно не сложно сделать. Хотя надо будет воспрозвести GC и компиляцию учитывающую его наличие, что само по себе не просто.
CU>
И тебе того же.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что за слова были про поддержку нэйтив-средов?
ну некоторые используют под windows библиотеку pthread. Некоторые вообще не поддерживают многопоточность.
CU>>К синтаксису я довольно равнодушен. "Типизированный AST" — это приятно. К стати, а mbase ты "щупал"? Если "да" — что скажешь? (кроме скобок )
VD>А ты и Метопрограммер — это не одно лицо?
Нет =)
VD>Тебе MBase скорее всего тоже не понравится так как он как и Немерле заточен на "ссовременную высокопроизводительную платформу".
и поэтому тоже
CU>>А вот "современная высокопроизводительная платформа" оставила для меня N "за бортом" (ну или меня "за бортом" N)
VD>Не понимаю что в ней плохого. Ну, да это уже твои тараканы... Тебе с ними и жить.
Ну куда уж без тараканов. А в платформе "плохо" то, что свободная реализация под не-win платформы (mono) по возможностям отстаёт не только от "прародителя" (.NET), но и от "ближайшего конкурента" (JVM).
VD>Собственно лично я буду не против если кто-то создаст нэйтив-бэкэнд к компилятору немерла. Учитывая, что в следующей версии мы видимо откажемся от системных библиотек читающих и записывающих метаинформацию сборок, то это будет относительно не сложно сделать. Хотя надо будет воспрозвести GC и компиляцию учитывающую его наличие, что само по себе не просто.
Судьба D несколько намекает, что это таки не так просто и, скорее всего, ни кто за это не возьмётся.
VladD2 wrote: > Не. Так не бывает. Код конечно может быть представлен в виде данных, но > данные не могут быть представлены виде кода, просто потому, что данные > есть исключительно в рантайме.
Влад, ну просто как противопоставление твоим, на мой взгляд, тоже не
очень очевидным размышлениям. Чисто теоретически.
LISP умеет в рантайме компилировать код, т.е. его генерировать из данных.
НУ И В ЧЁМ ТОГДА ТВОЯ ПРОБЛЕМА ?
> параметров недоступна. А ведь при компиляции форм лиспа в машинный код > выполнение еще не происходит.
Это заблуждение. Происходит, только не того кода.
Три раза код в лиспе выполняется (даже четыре):
при компиляции, при загрузке, и при выполнении. Ещё -- при чтении до всего.
> Кстати, думать о макрах намного проще когда есть явно выделенная стадиях > их компиляции. В лиспе с этим просто задница. Там даже при компиляции > стадии перемешиваются. А уж при интерпретации вообще тяжело понять, что
Да ? А мне казалось, всё предельно ясно. Ты о каком лиспе говоришь ?
Здравствуйте, cl-user, Вы писали:
CU>Ну куда уж без тараканов. А в платформе "плохо" то, что свободная реализация под не-win платформы (mono) по возможностям отстаёт не только от "прародителя" (.NET), но и от "ближайшего конкурента" (JVM).
Это не соответствует действительности. Возможности у Моно вполне себе приличные. У них стандартные библиотеки не такие объемные как в дотнете. Но они все равно не меньше чем в том же Питоне. Так что вопрос спорный.
VD>>Собственно лично я буду не против если кто-то создаст нэйтив-бэкэнд к компилятору немерла. Учитывая, что в следующей версии мы видимо откажемся от системных библиотек читающих и записывающих метаинформацию сборок, то это будет относительно не сложно сделать. Хотя надо будет воспрозвести GC и компиляцию учитывающую его наличие, что само по себе не просто.
CU>Судьба D несколько намекает, что это таки не так просто и, скорее всего, ни кто за это не возьмётся.
Было бы просто, давно бы сделали. Но Ди — это плный компилятор, т.е. полнопроектный велосипед. Сделать только бэкэнбд все же намного проще. Тем более, что можно взять за основу уже имеющийся (gcc, LLVM или тот же дишный/марсовский).
Так что если и не возьмется никто, то скорее не из-за сложности зщадачи, а просто из лени и отсутствия материальной заинтересовонности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MasterZiv, Вы писали:
MZ>LISP умеет в рантайме компилировать код, т.е. его генерировать из данных. MZ>НУ И В ЧЁМ ТОГДА ТВОЯ ПРОБЛЕМА ?
Да все что угодно можно научить в рантайме код компилировать. Запусти себе компилятор и радуйся.
Тут речь о дргом. Раскрытие макросов происходит пред компиляцией, а выполнение не может начаться до компиляции. Таким образом на стадии раскрытия макросов, макрос не может анализировать данные которые будут обрабатываться тем кодом который получается в результате раскрытия макросов. Посему и анализировать ему не чего.
>> параметров недоступна. А ведь при компиляции форм лиспа в машинный код >> выполнение еще не происходит.
MZ>Это заблуждение.
Это неоспоримый факт. И об этом можно прочесть в любом вменяемом учебнике по CL.
MZ>Происходит, только не того кода.
Очень загадочная фраза. Ну, да не тогда, значит не тогда.
MZ>Три раза код в лиспе выполняется (даже четыре): MZ>при компиляции, при загрузке, и при выполнении. Ещё -- при чтении до всего.
К чему эти рассуждения?
Доступны макросу данные которые будут при выполнении передаваться в сгенерированный макросом код или не доступны?
>> Кстати, думать о макрах намного проще когда есть явно выделенная стадиях >> их компиляции. В лиспе с этим просто задница. Там даже при компиляции >> стадии перемешиваются. А уж при интерпретации вообще тяжело понять, что
MZ>Да ?
Да.
MZ> А мне казалось, всё предельно ясно.
Бывает. Крестись в следующий раз.
Если бы все было действительно так очевидно, то за 50 лет он набрал бы несколько больше сторонников.
MZ>Ты о каком лиспе говоришь ?
Без разницы. В этом плане все одинаково.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MasterZiv, Вы писали:
MZ>НУ И В ЧЁМ ТОГДА ТВОЯ ПРОБЛЕМА ?
Да, вот еще что... Судя по крикам проблему явно у тебя. Может не стоит так близко принимать все к сердцу? И уж если принимаешь, то может сначала разобраться в том на что отвеваешь. Тогда глядишь и нервничать не придется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: CU>>Интересное кратко написано на вышеуказанной странице. Из бросающегося в глаза — одна из немногих свободных реализаций CL с поддержкой тредов под Windows. Практически всё остальное есть у древнего SBCL (разве что кроме поддержки маков, и то не уверен) VD>А что же вместо потоков под виндой применяется то (в других реализациях)?
Вероятно, в каком-то виде green threads внутри одного потока windows?
Здравствуйте, VladD2, Вы писали:
VD>Это не соответствует действительности. Возможности у Моно вполне себе приличные. У них стандартные библиотеки не такие объемные как в дотнете. Но они все равно не меньше чем в том же Питоне. Так что вопрос спорный.
Т.е. библиотеки у моно таки меньше и, самое главное и что именно я имел в виду, результирующий код (натив) отличается по качеству от .NET (иначе с чего бы ему тормозить по сравнению с тем-же "нетом") — и всё равно "Это не соответствует действительности"? Я чего-то не понимаю...
И причём здесь Питон? Указаны были 2 "конкурента". Под win mono просто не видно в тени .NET, а под не-win есть JVM, которая может "технологически" и отстаёт в чём-то, но "вылизана" за истекшее время так, что mono надо ещё долго (и за большие деньги) стараться.
CU>>Судьба D несколько намекает, что это таки не так просто и, скорее всего, ни кто за это не возьмётся.
VD>Было бы просто, давно бы сделали. Но Ди — это плный компилятор, т.е. полнопроектный велосипед. Сделать только бэкэнбд все же намного проще. Тем более, что можно взять за основу уже имеющийся (gcc, LLVM или тот же дишный/марсовский). VD>Так что если и не возьмется никто, то скорее не из-за сложности зщадачи, а просто из лени и отсутствия материальной заинтересовонности.
А я думаю, что скорее из-за отсутствия "фана" "возиться" с N у тех, для кого это не представляет чрезмерной сложности
Здравствуйте, cl-user, Вы писали:
CU>Т.е. библиотеки у моно таки меньше и, самое главное и что именно я имел в виду, результирующий код (натив) отличается по качеству от .NET (иначе с чего бы ему тормозить по сравнению с тем-же "нетом") — и всё равно "Это не соответствует действительности"? Я чего-то не понимаю...
Код в среднем тормознее. Но возможностей это не умоляет. Он все равно получается компилируемым в нэйтив. Так что для большинства применений подойдет.
Или давай определимся с понятием "возможности".
CU>И причём здесь Питон? Указаны были 2 "конкурента".
Э... Яву припоминаю. Кто еще?
Что до Явы, то она в среднем уж точно не эталон производительности. Боксинг у них — это нормальное явление. А где боксинг, там скорсоти не жди. Это на фоне высоко-оптимизированной версии 3.5-го фрэймворка Моно выглядет не идеально. А на фоне Явы, очень даже...
CU> Под win mono просто не видно в тени .NET,
В каком смысле? Ежу понятно, что если есть хоть немного лучшая альтернатива, то народ выберет именно ее. Но использовать Моно на винде можно спокойно. Лично я только так его и использовал.
CU>а под не-win есть JVM, которая может "технологически" и отстаёт в чём-то, но "вылизана" за истекшее время так, что mono надо ещё долго (и за большие деньги) стараться.
Дык, под Яву нет столь же мощных языков. Ява даже на фоне Шарпа позором выглядит. А на фоне Немерле ее кроме как издевательством и назвать то язык не повернется.
Ты лучше опиши, что за задачи у тебя такие?
VD>>Так что если и не возьмется никто, то скорее не из-за сложности зщадачи, а просто из лени и отсутствия материальной заинтересовонности.
CU>А я думаю, что скорее из-за отсутствия "фана" "возиться" с N у тех, для кого это не представляет чрезмерной сложности
Ну, и это конечно так. Ведь те для кого — это не представляет чрезмерной сложности уже занимаются GCC, Mono или D .
Мой опыт последних годов показывает, что людей для "для кого это не представляет чрезмерной сложности" очень мало. Катастрофически мало. А те что есть обычно могут только взяться за дело и при первых же результатах (когда становится видно, что задача в общем-то решаемая, но нужно много и упорно работать) тихо сваливают.
Так что, конечно, для таких проектов нужно хорошее финансирование. А на энтузиазме их очень тяжело поднимать. Моно ведь тоже Новелом спонсируется...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Код в среднем тормознее. Но возможностей это не умоляет. Он все равно получается компилируемым в нэйтив. Так что для большинства применений подойдет.
Я и не говорил, что "не пойдёт", я говорил — "отстаёт". Что не так?
VD>Или давай определимся с понятием "возможности".
Я уже раньше поправился, что имел в виду скорость выполнения конечного кода (при наличии "плюшек" указанных платформ). Ну и про отставание стандартной библиотеки ты сам сболтнул
CU>>И причём здесь Питон? Указаны были 2 "конкурента".
VD>Что до Явы, то она в среднем уж точно не эталон производительности. Боксинг у них — это нормальное явление. А где боксинг, там скорсоти не жди. Это на фоне высоко-оптимизированной версии 3.5-го фрэймворка Моно выглядет не идеально. А на фоне Явы, очень даже...
Есть факты? С "игрой" параметрами JVM? Да и боксинг необходим только при "параметризации типами" классов/методов.
VD>В каком смысле? Ежу понятно, что если есть хоть немного лучшая альтернатива, то народ выберет именно ее. Но использовать Моно на винде можно спокойно. Лично я только так его и использовал.
Можно и тикль использовать. Или JavaScript. Есть даже интерпретаторы С/С++. Толку? Оправданием для использования моно под виндой может быть только лицензия, иначе — не понятно.
VD>Дык, под Яву нет столь же мощных языков. Ява даже на фоне Шарпа позором выглядит. А на фоне Немерле ее кроме как издевательством и назвать то язык не повернется.
По сравнению с явой/шарпом немерла просто НЕТ. Поддержка/документация/стандартизация/книги/комьюнити/прочее — НЕТ. Ява/шарп не под виндой — уже выбор: смотря какие "плюшки" больше нужны. Ну и есть скала — для аналогичного синтаксиса. Если-же рассматривать "экзотику" а-ля N (не по синтаксису, а по распространённости), то есть пачка "скобочкообразных", хотя у них у всех существенный минус — все дают "просадку" по скорости кода (ещё один плюс N).
VD>Ты лучше опиши, что за задачи у тебя такие?
Помнишь/знаешь легенду, как макросы получили своё имя? Вот приблизительно те-же задачи
VD>Так что, конечно, для таких проектов нужно хорошее финансирование. А на энтузиазме их очень тяжело поднимать. Моно ведь тоже Новелом спонсируется...
Как-то "грустно" спонсируется. Особых результатов пока не видно.
О недостатках семейства CL я и сам знаю. В том числе и о тех, которые "преодолены" в твоём любимом N =P
