LINUX.ORG.RU

[Лиспофлейм]Реализации common lisp и пакеты


0

0

Вот не пойму.

Вы хотите написать программу, использующую сторонние библиотеки в C, вы пишите

#include <foo.h> // препроцессор вставляет сдесь содержимое foo.h

В пистоне: import foo // Создается неймспейс foo, читается код из foo.py, все переменные/функции запихиваются в этот неймспейс.

В лиспе же вообще нет единой системы. Когда я сидел под дебианом в clisp'е там было что-то типа:

(require 'common-lisp-controller)
(common-lisp-controller:clc-require 'foo)

В sbcl для установки(!!) пакетов (вернее «систем», которые определяются с помощью defsystem) используется asdf-install:

(asdf-install 'foo)
(require 'foo)

Так вот вопрос: почему реализация берет на себя установку пакетов, контроль путей к пакетам итд.? Почему установку не доверить, например, пакетному менеджеру операционной системы?

Почему везде нельзя как в emacs (идеальный вариант):

(setq load-path (append load-path '(#p"/foo/bar" #p"/foo/buz")))
(require 'bar)
(require 'buz)

Или тупо (load «/foo/bar/buz»)?

Вопрос не совсем технический, поэтому в talks

Ответ на: комментарий от lester

вот так и получается - на С бесплатно и быстро, а на lisp - платно и медленее будет работать

Покажи библиотеку для метапрограммирования на С?

mv ★★★★★
()
Ответ на: комментарий от lester

> вот так и получается - на С бесплатно и быстро,

а на lisp - платно и медленее будет работать


Прикол: писать на CL код, который использует модули на C (via CFFI) значительно проще, чем аналогичный код на C++ (использующий тот же модуль на С).

archimag ★★★
()
Ответ на: комментарий от naryl

> Покажи рестарты на C. Можно в виде библиотеки.

ну сейчас начнется перечисление... тонны рабочего кода и программы на С сами за себя говорят - что надо на практике, а что надо для поднятия ЧСВ

lester ★★★★
()
Ответ на: комментарий от archimag

> Прикол: писать на CL код, который использует модули на C (via CFFI) значительно проще, чем аналогичный код на C++ (использующий тот же модуль на С).

ты еще скажи, что С++ с С не совместим

lester ★★★★
()
Ответ на: комментарий от lester

> ты еще скажи, что С++ с С не совместим

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

archimag ★★★
()
Ответ на: комментарий от archimag

> юзать С из CL таки проще... Я как бы имел достаточный опыт и того, и другого.

какие у вас были проблемы в С++?

lester ★★★★
()
Ответ на: комментарий от lester

Отсутствие рестартов - отличный способ создавать рабочие места и увеличивать стоимость разработки, что является ещё одной причиной наличия тонн рабочего кода и программ на C, которые сами за себя говорят, что C не нужен ;)

naryl ★★★★★
()
Ответ на: комментарий от lester

^_____^ Рад стараться.

Впрочем, аргументы остальных участников спора немногим лучше.

naryl ★★★★★
()
Ответ на: комментарий от Neksys

> Расширение возможностей перебора с откатом (бэктрекинга) >М.Л.Гасаненко 1997г

Считается? :-)

Я бы не рекомендовал приводить Форт, как пример языка программирования. В нём самом ничего нет, набор базовых примитивов над стековой машиной. И кстати, все «недостатки» опенсорсных реализаций Лиспа, которые здесь приводятся, обусловлены «фортообразным» применением Лиспа, когда каждый пишет библиотеку на свой вкус для реализации своей частной задачи. То, что сейчас делает archimag и некоторые другие товарищи, есть попытка систематизировать опенсорсные библиотеки и реализации Лиспа. В коммерческих Лиспах таковые системы давно уже есть.

GeoVit
()
Ответ на: комментарий от archimag

> ASDF позволяет описать как загружать лисп-систему в память и никакого отношения к установке пакетов не имеет. И SBCL тоже не при чём, ибо ASDF работает практически на всех реализациях.

просто скажи ему, что ASDF — это примерный аналог make в Си

ASDF-INSTALL - это другая система, в какой-то степени аналог CPAN, но не очень хорошая и лучше её не юзать, а использовать, например, clbuild.

хорошо, не make, а скорее, Maven c центральным репозиторием

Ну и да, почувствуй большую разницу между системами (пакетами с точки зрения дистрибутива) и пакетами в Common Lisp.

да, а пакеты в СL, то есть, модули в других языках тут вообще ортогональны системе сборки (ASDF,cl-build) и определяют пространство имён, но вручную, с ручным перечислением всех экспортируемых модулем-пакетом символов

anonymous
()
Ответ на: комментарий от lester

> какие у вас были проблемы в С++?

У меня было всё отлично с С++, дело не в минусах, а достоинствах. Цикл редактирование/компиляция/выполнение в С++ уже очень оказывается долгий.

Первый раз я сделал подобное наблюдение, когда работал над cl-libxml2 имея ещё совсем небольшой опыт с CL, но до этого я патчил для себя xmlwrapp (которая по идеям очень хороша, так называемый modern C++, но функционала ей не хватало). Так вот, REPL чудовищно упрощает разработку подобных биндингов. Кстати, насчёт хвалённой документации к С-проектам, вы пробовали разобраться с libxml2 по документации? Это г... библиотеку не понять без чтения исходников! А даже имеющаяся документации так просто местами не верна. И это ведь очень заслуженный проект. Я когда работал над cl-libxml2 просмотрел примерно 30% исходного кода libxml2, иначе ни как.

Другой раз, мне надо было из С++ поработать немного с MSSQL. FreeTDS тоже, тот ещё фрукт. Пришлось делать так: прочитал исходники pymssql, отладил нужный функционал на CL, переписал на C++.

archimag ★★★
()
Ответ на: комментарий от lester

а это вообще не языки. Особенно второе — собственно языковых фич в нём минимум, интерес вызывает всего лишь готовая уже платформа и наличие базовых объектов. Сам язычок-то довольно ограниченный, судя по простыням кода на нём, ему явно не хватает паттерн матчинга, подсистем-модулей, гибкой модели событий и полноценной adt системы типов. В первом примерно так же. Вот haxe — это язык, а Neko VM — рантайм. Который поддерживает разные стили, парадигмы программирования, и имеет для этого средства. А похапе в этом смысле ни разу не рантайм. Вышеупомянутые сабжи — это продукты отрыжки платфомы, но ни разу не язык, тем более — универсальный, мультипарадигменный.

anonymous
()
Ответ на: комментарий от archimag

> Цикл редактирование/компиляция/выполнение в С++ уже очень оказывается долгий.

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

lester ★★★★
()
Ответ на: комментарий от archimag

> Цикл редактирование/компиляция/выполнение в С++ уже очень оказывается долгий.

язык D в этом смысле поприятнее будет.

вы пробовали разобраться с libxml2 по документации? Это г... библиотеку не понять без чтения исходников! А даже имеющаяся документации так просто местами не верна. И это ведь очень заслуженный проект

надо было бы сначала не лезть в дебри, а разобраться с тем же XDuce, CDuce — и не по исходникам, а в рамках общей идеи. Глядишь, и с DOM XML попонятнее стало бы.

anonymous
()
Ответ на: комментарий от Rastafarra

> 1це — без вариантов. и это скорее не язык а платформа. очень неплохая, кстати.

вот только не надо про «неплохая» — ты вообще на ней писал что-нибудь объёмное и/или нетривиальное? Шаг влево-шаг вправо, и приходится писать компоненту на COM или своём велосипедном дотнет-аналоге. С профилированием кода под нагрузкой до конкретных транзакций — косяк, с прозрачностью платформы — косяк, с тестированием — косяк, но есть костыли, да.

решения на лиспе же, кстати, в этих нишах либо сосут либо вообще не представлены. в силу убогости/ненужности последнего, или как?

whom how, один немец вот на PicoLisp пишет что-то уже лет 25 «в этой нише». Даже свой интерпретатор лиспа вот написал, да. У мну есть безумная идея — обложиться парсерами языка и транслировать его в лисп, да. И метапрограммированием дальше, метапрограммированием — даёшь пролетарским кирпичным приветом по непрозрачности платформы и общей громоздкости быдлокода.

anonymous
()
Ответ на: комментарий от lester

> в MSVC можно изменить код и сразу применить изменения к запущенной в дебаггере программе

Во-первых, существуют ли свободные или бесплатные с поддержкой Линукса системы с этим костылём? Во-вторых, REPL служит не только для этого.

С++

ребилдом только изменных файлов - т.е. в большинстве случаев мгновенно



На C++ ничего не мгновенно. Даже Hello_World.cpp.

naryl ★★★★★
()
Ответ на: комментарий от anonymous

> язык D в этом смысле поприятнее будет.

Быстрой компиляцией :) Цикл никуда не денется.

naryl ★★★★★
()
Ответ на: комментарий от naryl

> Во-первых, существуют ли свободные или бесплатные с поддержкой Линукса системы с этим костылём?

спроси у mv - он утверждал, что opensource просто УГ и надо смириться с этим( я так не считаю - но при этом не считаю зазорным использовать msvc + удобный проприетарный профайлер )

lester ★★★★
()
Ответ на: комментарий от Rastafarra

> так это прекрасно! можно взглянуть на табличку сравнения языков по объективным критериям?

нельзя — они все субъективные, одному арбузы важнее, другому вот — свиной хрящик.

Табличка трёхмерная будет или поболе. Один вот индус статистически обработал результаты шутаута и вывалил scatter plot гистограмму, чтобы вывести «критерии». По реализациям, а не по объективным фичам. Кучкование результатов, и критерии, как и ожидалось — разные.

На это всё можно наложить второй график — личная продуктивность конкретного программиста на конкретном языке. Потом третий — платформа, инструменты, командная работа и критерии для командной работы (общие процессы и платформа, понятность и управляемость, а не какие-то там объективные фичи недоязыка).

Вы, батенька, путаете язык с лингвистическими атавизмами и платформу с инструментарием, как сравнивая *язык* Си с крестами и *платформу* Жабы. По закону больших чисел вторая зарулит всех именно по третьему графику. Поэтому она и полезна, а языки/системы с пустым третьим графиком просто сравнивать не с чем, они выпадают из контекста сравнения.

anonymous
()
Ответ на: комментарий от lester

$ time g++ hello.cpp
g++ hello.cpp 0.19s user 0.02s system 97% cpu 0.225 total

$ time dmd hello.d
dmd hello.d 0.07s user 0.02s system 100% cpu 0.091 total

С повышением числа файлов для gcc/g++ время компиляции растёт пропорционально примерно от n*log₂n до n². Для dmd - пропорционально n.

naryl ★★★★★
()
Ответ на: комментарий от lester

> в MSVC можно изменить код и сразу применить изменения

к запущенной в дебаггере программе


А после Segmentation fault? Но не суть, С++ не динамический язык и если ты исправляешь хиадер (например, определение класса), то так просто не получиться.

так что возможно все ваши проблемы были связаны именно с

иcпользованием не самых лучших инструментов



Самый лучший инструмент это Linux, а MSVC на нём не работает. Да и со студии на Emacs я ушел ещё когда работал под виндой, ибо 5 лет назад студия была унылое г... (как сейчас не знаю).

archimag ★★★
()
Ответ на: комментарий от naryl

С повышением числа файлов для gcc/g++ время компиляции растёт пропорционально примерно от n*log₂n до n². Для dmd - пропорционально n.

вы отождествляете язык и компилятор? есть еще icc, msvc, для того же C я уже приводил ссылку на tcc - который значительно быстрее:

Compiler	Time(s)	lines/second	MBytes/second
TinyCC 0.9.22 	2.27 	859000 	29.6

Measures were done on a 2.4 GHz Pentium 4. Real time is measured. Compilation time includes compilation, assembly and linking. 
lester ★★★★
()
Ответ на: комментарий от archimag

> «Какие языки используют лучшие программисты?»

длинные

anonymous
()
Ответ на: комментарий от lester

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

anonymous
()
Ответ на: комментарий от archimag

> А после Segmentation fault?

я уже забыл, что это такое :)

Но не суть, С++ не динамический язык и если ты исправляешь хиадер (например, определение класса), то так просто не получиться.


первое что попалось на глаза в гугле:

http://en.wikipedia.org/wiki/Ch_interpreter

Самый лучший инструмент это Linux, а MSVC на нём не работает

5 лет назад студия была унылое г...



улучшений с тех пор много - студия уже не такая «лысая» как была тогда

lester ★★★★
()
Ответ на: комментарий от lester

> вы отождествляете язык и компилятор?

Нет. Постоянное время компиляции в C/C++ больше благодаря функциональному метапрограммированию на шаблонах (только C++) и контекстно-зависимому синтаксису. Хотя второй больше влияет на сложность, чем быстродействие компиляторов. В D есть ctfe и императивные конструкции в шаблонах, что делает метапрограммирование на нём достаточно быстрым.

Нелинейная сложность же достигается C/C++ благодаря хедерам.

naryl ★★★★★
()
Ответ на: комментарий от Rastafarra

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

ОК, лови:

* поддержка разных парадигм программирования * поддержка модульности * устройство рантайма языка/зависимость от реализации * устройство системы типов, в частности, ** объектной системы ** статическая/динамическая типизация * поддержка исключений, рестартов, и т.п. * наличие, зрелость, доступность и лёгкость доработок/повторного использования стандартных библиотек * наличие и уровень поддержки инструментария (конкретные инструменты или платформа) * интеропрерабельность платформы с другими средами * прозрачность, интроспекция, рефлексия и т.п.

anonymous
()
Ответ на: комментарий от naryl

> Нелинейная сложность же достигается C/C++ благодаря хедерам.

и как же тогда tcc умудряется компилировать быстро? :)

lester ★★★★
()
Ответ на: комментарий от Rastafarra

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

ОК, лови:

* поддержка разных парадигм программирования
* поддержка модульности
* устройство рантайма языка/зависимость от реализации
* устройство системы типов, в частности,
** объектной системы
** статическая/динамическая типизация
* поддержка исключений, рестартов, и т.п.
* наличие, зрелость, доступность и лёгкость доработок/повторного использования стандартных библиотек
* наличие и уровень поддержки инструментария (конкретные инструменты или платформа)
* интеропрерабельность платформы с другими средами
* прозрачность, интроспекция, рефлексия и т.п.

тьптфу

anonymous
()
Ответ на: комментарий от lester

патамучта гладиолус ^W это си, а не плюсы. Go вон тоже быстро конпелирует, особенно 6g, а не gcc go

anonymous
()
Ответ на: комментарий от anonymous

> патамучта гладиолус ^W это си, а не плюсы

он писал и про С

lester ★★★★
()
Ответ на: комментарий от lester

> я уже забыл, что это такое :)

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

archimag ★★★
()
Ответ на: комментарий от lester

> и как же тогда tcc умудряется компилировать быстро? :)

Сравнение с dmd на аналогичных проектах с парой десятков (можно больше) файлов в студию. На одном файле с двумя строчками tcc быстрее. :)

naryl ★★★★★
()
Ответ на: комментарий от lester

ты не поверишь, я вот на Ди смотрел — и дежа вю в этом смысле. Но пользоваться всё-таки можно!

anonymous
()
Ответ на: комментарий от naryl

Сравнение с dmd на аналогичных проектах с парой десятков (можно больше) файлов в студию. На одном файле с двумя строчками tcc быстрее. :)

ты ж доказываешь, что компиляция в С медленная - ты и приводи сравнение, а насчет «На одном файле с двумя строчками tcc быстрее» - я еще раз тебе скопипастю:

Compiler   Time(s)   lines/second   MBytes/second 
TinyCC 0.9.22    2.27    859000    29.6 
 
Measures were done on a 2.4 GHz Pentium 4. Real time is measured. Compilation time includes compilation, assembly and linking.  

это компиляция links - не один файл, и не две строчки

lester ★★★★
()
Ответ на: комментарий от anonymous

> ты не поверишь, я вот на Ди смотрел — и дежа вю в этом смысле. Но пользоваться всё-таки можно!

D первой ветки достаточно стабилен. Если библиотека работала в момент форка D2, то работает и сейчас.

naryl ★★★★★
()
Ответ на: комментарий от dragonfly

> Моё мнение: Лисп не нужен не потому, что на нём мало программ, а потому, что существуют лучшие решения тех проблем, которые решает лисп. Как-то так

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

anonymous
()
Ответ на: комментарий от naryl

> В случае с C++ тормозят и g++ и ld.

тоже мне новость. ld не gold? пачиму? ld просто по определению тормозит на плюсах, почитай блог автора gold

anonymous
()
Ответ на: комментарий от anonymous

п%ц - можно подумать это я к нему пристал и доказываю, что компиляторы на С тормозные :)

lester ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.