Здравствуйте, Mr.Cat, Вы писали:
MC>А тут те, что с приписочкой mingw32 — это не оно разве? MC>ftp://ftp.gnu.org/pub/gnu/gcl/
Надо глянуть. Я сначала искал тут — тут — вообще нет, потом тут — тут не сразу нашел, почему-то последних версий нет под win32.
В результате нашел не самое свежее тут.
А вообще да, похоже я затупил
Здравствуйте, Marty, Вы писали:
M> Здравствуйте, коллеги!
M>Собственно, сабж. На офф. сайте нет такого, только цигвин. Может кто встречал нативную сборку GNU CLISP под винду?
Под виндой сейчас актуально Clozure CL. Быстрый компилятор, нативные треды.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Наверно это у меня непонимание Нашел материалы по лиспу, там примеры, пишут что используют GNU Common Lisp, и везде фигурирует команда clisp. Вот я и стал искать GNU clisp. А он на самом деле GCL. А что тогда есть clisp, который я нашел?
Здравствуйте, Marty, Вы писали: M>А он на самом деле GCL. А что тогда есть clisp, который я нашел?
Ну это просто разные имплементации коммонлиспа. Или ты про то, чем clisp от gcl отличается? Тут я хз — наверное, какими-то фичами вне стандарта (вроде реализация многопоточности между имплементациями разнится сильно).
Здравствуйте, Marty, Вы писали:
M> Спасибо, посмотрю. Но я хотя и работаю сейчас под виндой, хотел бы пользоваться переносимой реализацией. Вообщем, надо глянуть.
Он и есть кроссплатформенный.
Mac OS X (PowerPC and x86)
Linux (PowerPC and x86)
FreeBSD (x86)
Solaris (x86)
Microsoft Windows (x86)
Также доступны версии для 32 и 64-х битных платформ.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Marty, Вы писали:
M> Наверно это у меня непонимание Нашел материалы по лиспу, там примеры, пишут что используют GNU Common Lisp, и везде фигурирует команда clisp. Вот я и стал искать GNU clisp. А он на самом деле GCL. А что тогда есть clisp, который я нашел?
clisp — "си-лисп" — интерпретатор, написанный на си. Не полностью (CLOS и прочее реализовано на лиспе), но весьма значительная часть. Из известных мне FOSS реализаций наиболее адаптированная к винде — не использует posix-аналоги для системных вызовов. Не очень быстро работает, но довольно быстро загружается. По сравнению с прочими лиспами — не так требователен к памяти. Тредов пока нет (в работе)
Здравствуйте, cl-user, Вы писали:
CU>да, только требует WinXP (на 2k уже не работает) и SSE2 — на моём старом атлончике тоже не заработал
У меня на Висте и ХР работает вполне стабильно. Какой сейчас смысл в Win2k? Там кстати, где-то в вики авторы признавались, что под виндой, 64-х битная версия более тщательно протестирована, нежели 32-битная. Хоть я и использую 32-битную версию, ни одного бага пока не встречал.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, cl-user, Вы писали:
CU>clisp — "си-лисп" — интерпретатор, написанный на си. Не полностью (CLOS и прочее реализовано на лиспе), но весьма значительная часть. Из известных мне FOSS реализаций наиболее адаптированная к винде — не использует posix-аналоги для системных вызовов. Не очень быстро работает, но довольно быстро загружается. По сравнению с прочими лиспами — не так требователен к памяти. Тредов пока нет (в работе)
Добавлю, clisp — не только наиболее адаптирована к винде, но и ко всем остальным платформам тоже.
CLISP runs on most GNU and Unix systems (GNU/Linux, GNU/Hurd, FreeBSD, NetBSD, OpenBSD, Solaris, Tru64, HP-UX, BeOS, IRIX, AIX, Mac OS X and others) and on other systems (Windows NT/2000/XP/Vista, Windows 95/98/ME) and needs only 4 MB of RAM.
Еще бы добавил, про быструю длинную арифметику.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, VladD2, Вы писали:
VD>По поводу быстрого... Они там какую-то статическую типизацию вводят или язык все равно динамически-типизированным остается?
Язык-то динамически-типизирован, может они там внутри и пытаются типы вывести, я не знаю, во внутренностях их компилятора не копался.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Язык-то динамически-типизирован, может они там внутри и пытаются типы вывести, я не знаю, во внутренностях их компилятора не копался.
Это не возможно. Макра работает не с данными, а с кодом. Так как статический анализ кода невозможен, то и опираться на информацию о типах нельзя.
Но, так как типы по большому счету не так важны (динамика, все же), то и сожалеть об этом приходится редко.
По факту получается, что хороший макрос Немерле написать сложнее (именоо из-за того, что может потребоваться анализ типов), но при этом они выглядят более товарно (если так можно выразиться), так как в купе с доступом к компилятору и анализом типов их качество не отличается от решений реализованных в самом компиляторе. По факту макры Немерла — это полноценные плагины к компилятору завернутые в красивую обертку лисп-подобных макросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Y>>Язык-то динамически-типизирован, может они там внутри и пытаются типы вывести, я не знаю, во внутренностях их компилятора не копался. VD>Это не возможно. Макра работает не с данными, а с кодом. Так как статический анализ кода невозможен, то и опираться на информацию о типах нельзя.
Код и данные в Лиспе, это одно и то же. Как между собой связаны статический анализ кода и информация о типах? Статический анализ кода в Лиспе возможен. А как, от того, что статический анализ кода не возможен следует, что опираться на информацию о типах нельзя, мне не понять Информация о типах в момент компиляции или в рантайме? Ей богу, каша какая-то. Можешь более четко сформулировать свой вопрос?
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Код и данные в Лиспе, это одно и то же.
Не. Так не бывает. Код конечно может быть представлен в виде данных, но данные не могут быть представлены виде кода, просто потому, что данные есть исключительно в рантайме.
Простой пример. Имеем мы вызов функции:
(func a, 2, b)
Предположим, что этот вызов был передан в качестве параметра некому макросу. Макрос стал анализировать параметры...
Что он может понять на их основании? Ну, второй параметр — это константа целочисленного типа. Тут все ОК. А первый и третий? Усе что мы можем заключить о них, что это переменные которые должны быть доступны из контекста раскрытия макроса.
В немерле есть возможность в макросе дождаться того момента когда типы выражений "a" и "b" будут доступны и ужа на основании того какой у них будет тип сделать некие действия. В лиспе это невозможно, так как до момента выполнения сгенерированного макросом кода информация о типах параметров недоступна. А ведь при компиляции форм лиспа в машинный код выполнение еще не происходит.
Y>Как между собой связаны статический анализ кода и информация о типах?
Дык информация есть или нет. См. пример выше.
В статически типизированном языке информация о выражениях может быть получена и проанализирована во время компиляции. В динамически-типизируемых — нет.
Y> Статический анализ кода в Лиспе возможен.
Кода — да. Но как банальных списков. Информацию о типах ты не узнаешь.
Y> А как, от того, что статический анализ кода не возможен следует, что опираться на информацию о типах нельзя, мне не понять Информация о типах в момент компиляции или в рантайме? Ей богу, каша какая-то. Можешь более четко сформулировать свой вопрос?
Каша, каша. Но это каша в голове тех кто о них рассуждает. Думать о макрах вообще не просто. Мне по началу тоже крышу рвало. Сейчас уже привык.
Кстати, думать о макрах намного проще когда есть явно выделенная стадиях их компиляции. В лиспе с этим просто задница. Там даже при компиляции стадии перемешиваются. А уж при интерпретации вообще тяжело понять, что и откуда растет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По поводу быстрого... Они там какую-то статическую типизацию вводят или язык все равно динамически-типизированным остается?
Типизировать параметры функций и результат можно, нужно, и почти везде так и пишут (если хотят скорости). И это даёт ускорение, ибо убирает проверки при использовании типизированных данных (из мне известных только совершенно динамический clisp на типизацию почти не обращает внимания, но у него и компиляции в натив нет). НО — вывода типов [практически] нет, поэтому указывать тип приходится довольно часто. И в макрах тоже с типами "не поиграешь", если только не заставлять их явно указывать.
P.S. Всё это в том-же sbcl было фиг его знает сколько лет назад. И, не нарушая стандартов, подозреваю, что по другому с CL и не сделать.
P.P.S. И подозреваю, что вся вышеизложенная банальщина тебе известна, и отметился ты в топике с одной единственной целью...
Здравствуйте, 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
