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

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

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

все еще хуже? в лиспе куча вариантов и все нерабочие?

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

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

> про соурсфордж и 80% всем известно.

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

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

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

Реально много по факту неподдерживаемого мусора (в любом большом дистрибутиве).

С точки зрения разработчика всё ещё хуже. Причём, хуже даже не из-за используемого языка, а из-за того, как opensource функционирует. У меня был случай (с C++), когда умерла машина, и по своей наивности в svn держал только свои исходники, надеясь в случае краха скачать сторонние библиотеки с интернета. И вот, момент настал, и я с ужасом обнаружил, что автор нужной библиотеки кардинально её переделал, старые версии с сайта удалил, репозитория нет. Спас кэш Гугля.

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

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

> У меня был случай (с C++), когда умерла машина, и по своей наивности в svn держал только свои исходники, надеясь в случае краха скачать сторонние библиотеки с интернета. И вот, момент настал, и я с ужасом обнаружил, что автор нужной библиотеки кардинально её переделал, старые версии с сайта удалил, репозитория нет. Спас кэш Гугля.

название библиотеки конечно забыл?

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

название библиотеки конечно забыл?

shmem. Который потом boost::interprocesses стал.

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

> две чисто лисповые реализации. Одна не умеет расжимать, другая глючит

очень мило. это лиспу в «+» надо засчитать?

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

Еще лисп от franz имеет библиотеку для работы с zip, lispworks, наверняка тоже что-то свое дают.

cvb
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от lester

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С++

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



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

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

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

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

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

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

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

lester ★★★★
()
Ответ на: комментарий от 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 ★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от naryl

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

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

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

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

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

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

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

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

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

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

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

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

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

naryl ★★★★★
()
Ответ на: комментарий от 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 ★★★★
()
Ответ на: комментарий от naryl

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

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

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

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

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

«xfBuild has been tested on projects with 300+ modules and achieves build times of around 2–3 seconds when just a few modules need to be recompiled therein (on a 1.7GHz Intel Centrino CPU with DMD-Win).»

Сейчас проверю на DWT.

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

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

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

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

Сейчас проверю на DWT.

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

именно этого слова нет, но оценку опенсорса вы дали

Опять приписывание своих неверных выводов другим людям. Этому специально на каких-то курсах по C++ учат?

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

> Опять приписывание своих неверных выводов другим людям.

т.е. «смирись» - это радость и восхищение качеством опенсорса?

Этому специально на каких-то курсах по C++ учат?


конечно

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

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

однородный синтаксис решает. Почему, к примеру, в Google Go есть gofmt, а в D из аналогов только более толстый languagemachine c d-to-d translator'ом? Сложность разная

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

т.е. «смирись» - это радость и восхищение качеством опенсорса?

Это констатация факта возможности выбора: использовать то, что есть, либо воспользоваться наличием исходников в свободном доступе.

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

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

тогда приношу извинения

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