LINUX.ORG.RU
ФорумTalks

SBCL уделывает C++(и шланг, и G++) по производительности

 , , ,


0

5

https://programming-language-benchmarks.vercel.app/problem/spectral-norm

Немного лучше него, буквально на десяток миллисекунд, справляется rust.

Назовите теперь хоть одну причину использовать плюсы вообще?

Перемещено xaizek из development

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

Говно у тебя в штанах, джавапетух.

С точки зрения внешнего наблюдателя проблемы нет, так как деплоится лисп-система целиком, обычно.

Внутри лисп системы понятия версий и библиотек нет. Есть пакеты, это фактически неймспейсы, но вообще говоря просто объекты, являющиеся коллекцией символов. С символами могут быть связаны функции и прочие объекты. Есть понятие скомпилированного файла, который можно подгружать.

Таким образом, в лисп-систему не встроено понятие версии как таковой, потому как среда динамическая и может изменяться по ходу дела, то есть вопрос версионности кода и объектов внутри лисп-системы не имеет по сути смысла. Имеет смысл разве что версия самой лисп-системы, например скажем SBCL 2.1.8 в котором пофиксили то-то и то-то, добавили то-то и это. В случае апгрейда или замены оной версии действительно имеет смысл перезагружать ее, точно так же как имеет смысл необходимость перезагружать конплюхтер когда ты обновил ведро прыщей(или винды).

Что же тогда имеет смысл? Имеет смысл версии библиотек. Начнем с определения, что такое библиотека, потому что стандарт ANSI CL нам ни о чем таком не говорит напрямую.

Допустим что библиотека это некоторый набор файлов связанных с лиспом, скомпилированные эти файлы или нет уже не такой важный вопрос.

Существует de-facto стандарт управления подгрузкой библиотек в лисп, называется ASDF, в ней уже есть понятие версии компонента, причем компонент это может быть как отдельный файл с кодом, который можно скомпилировать и загрузить согласно стандарту ANSI CL, свой кастомный компонент, например какой-то внешний сишный бинарник, так и модуль(коллекция компонентов), так и вся отдельно взятая asdf-система.

Как ASDF ищет, настраивает, и загружает эти компоненты, и как это кастомизировать - можно почитать по ссылкам в документации.

Далее, над ASDF существуют надстройки. Самая популярная это quicklisp - менеджер репозиториев такой.

В нем обычно фиксируется некоторый конкретный рабочий набор версий asdf-систем, обычно из какого-либо курируемого дистрибутива quicklisp(собственно quicklisp, ultralisp, собственного какого-то и так далее). Всегда можно откатиться и перезагрузить на лету, удалив существующее.

Ну и конечно, всегда можно указать где и как искать зависимости непосредственно самому ASDF.

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

Так и скажи что ничего не понял, потому как ты тупой.

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

А npm, и прочие выкатыватели «Единственно Верных» путей решения проблем зависимостей, насирают, как обычно единственно неверное.

Правда, в последних версиях они додумались до того чтобы дать пользователю хоть какую-то свободу действия. Не прошло и 10 лет, блять. Ждем когда дойдет до пользователей go get и иже с ним, а то на последних вообще смотреть страшно.

https://npm.github.io/how-npm-works-docs

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

Как твой говнолишп решает проблему DLL Hell?

А хрен его знает. Ни разу не сталкивался с проблемой DLL Hell в лиспе, поэтому абсолютно не знаю как это решается (поговаривают, что проблемы вообще нет).

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

Конечно проблемы нет. Но лавсанчик сначала сказал что она есть, потому сказал что лисп ее решает, а потом начал нести пургу то про Эрланг, то потом вообще о кастомизации

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

Еще раз, есть два решения.

Первое - (ql:quickload "library") - просто работает в 99.99% случаев

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

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

Настоящее решение в том чтобы дать разработчику кастомизировать разрешение зависимостей

Я предпочту пользоваться работающим софтом, а не «кастомизировать разрешение зависимостей». По мере роста сложности продукта уже никакого времени на хватит на такую кастомизацию для либ на десятки миллионов строк кода.

А npm, и прочие выкатыватели «Единственно Верных» путей решения проблем зависимостей, насирают, как обычно единственно неверное

NPM ничего работающего не умеет выкатывать — это умеет делать только yarn, за счет фиксирования версий зависимостей. Фиксация зависимостей и проверка работоспособности этого снимка — это единственный способ сделать что-то рабочее. Все дистрибутивы линукса именно этим и занимаются, если что.

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