А как вообще так получилось? Как до этого дошло?
Почему никто не пытается ее оспорить? Чревато ведь. И санкциями, и прочей херней - вон не дай Б-г там случится войнушка с Китаем, так всей индустрии электроники придет трындец.
Теперь у библиотеки есть полноценная документация, что выгодно отличает ее от поделий на голанге, жопоскрипте и прочих питонах. Таким макаром, скоро лисп-экосистема дорастет до жабовской, или хотя бы, опять же, дотнетной.
https://github.com/Lovesan/bike/blob/master/doc/README.md
Кроме документации, доделал классы, которые могут вызываться из .NET. Вот в частности пример, как реализовать интерфейс IReadOnlyList<object> для лисповых коллекций:
https://github.com/Lovesan/bike/blob/master/examples/callable-classes.lisp
Также, добавил полноценную поддержку ECL. Единственная проблема с ECL в том, что он компилируется через Си, а так как библиотека активно использует компиляцию и кодогенерацию в рантайме(как на стороне .NET, так и в лиспе), то ECL постоянно вызывает компилятор сишечки, например GCC.
Также добавил функциональность по типу apropos, но для .NET классов, неймспейсов и членов классов.
Так, например, такой код:
(type-apropos "xml")
Выведет имена .NET классов, содержащие «xml» (сраную гору их просто; я даже сам не знал что их так много в стандартной библиотеке).
Также, обновление содержит кучу мелких багфиксов и улучшений, о некоторых из них можно почитать в CHANGELOG:
Как видно из бенчмарков, это сейчас вообще самый быстрый сервер структур данных на всём диком западе:
https://microsoft.github.io/garnet/docs/benchmarking/results-resp-bench
Парктически полностью совместим с Redis на уровне API, но при этом:
Последний пункт особенно забавен, надеюсь хоть это у крестолюбцев в голове что-либо прочистит, и вот это дебильное мнение что «сипласплас эта быстра», а также глупые наезды на GC, наконец канут в лету. Кресты в современном мире нахер не нужны, и никакой даже особой производительности не дают. Да и Си, в принципе, тоже нигде не нужен выше уровня ядра.
Я кстати, в свое время написал на C# видеостриминг-сервер, и клиент, практически не используя кресты(было немного C++/CLI для связи с COM итд), и проблем с производительностью там не было. Но что я - вон целый MS Research делает продукты вон какого уровня.
Вобщем, причесал тут свои конфиги Емакса, и выложил на гитхаб.
https://github.com/Lovesan/.emacs.d
Для работы потребуется более-менее новый Emacs, такой как 29.1
Ну и SBCL (но в init.el можно раскомментить строчку и прописать свою реализацию, типа ecl). Если еще этого не сделали, также рекомендую загрузить в SBCL quicklisp чтобы библиотеки можно было вообще в пару кликов ставить.
Как только Emacs с такой конфигурацией запускается, он открывает:
Дальше можно писать код, или нажать например в REPL запятую(,), и вводить команды SLIME-repl(для начала можно набрать help). inb4 побочные окошки, типа хелпа, закрываются кнопкой q на клавиатуре.
Вощем, включены SLIME, Magit(это интерфейс для гита в емаксе) и всякая мелочь для удобства. Тулбар выключен, менюха оставлена.
Для структурного редактирования кода на лиспе(включая Emacs Lisp), установлен пакет Lispy. Я раньше пользовался parinfer, но он меня окончательно достал. Lispy удобнее и к тому же легче конфигурируется.
SLIME там уже в принципе прилично настроенный, в частности даже есть немного подсветки синтаксиса для моей библиотеки bike
Но самая основная проблема которую я решил за вас(не благодарите), это поменял кейбиндинги Емакса на нормальные.
Дело в том что дефолтные биндинги, на самом деле были предназначены для клавиатур древних лисп-машин, а для современных клавиатур не годятся вообще от слова совсем, и если вы слышите что кто-то пользуется дефолтом и умудряется этим гордиться - гоните его в шею, насмехайтесь над ним, и всячески унижайте, потому что он просто позер.
Итак, что я сделал, это я с помощью библиотеки rebinder.el, перенаправил префикс-сочетания C-x и C-c на C-e и C-d соответственно.
Это позволило сделать из емакса нормальный редактор кода. Да, в принципе, не хватало бы еще табов и прочих GUI-плюшек, но зато зацените, без всяких кривых CUA-mode, им наконец-то можно пользоваться.
Биндинги такие:
Ctrl+Q - выход из Емакса.
Меню/Apps (это такая кнопка рядом с правым контролом) - вызов расширенной команды по имени(типа то что в емаксе называют M-x)
Редактирование:
Также, я немного похакал так называемый killring и систему выделения текста, что еще больше приблизило Emacs к нормальным редакторам.
Управление буферами(такое обобщение понятия файла в емаксе):
Поиск:
Также в окошке поиска можно перемещаться стрелками, так стрелки вправо-влево управляют поиском вперед/назад по тексту, а стрелки вверх-вниз - просмотр история поиска.
Мышку кстати тоже в некоторой степени перебиндил, в частности доп. кнопки mouse-4 и mouse-5 (их обычно в современных ОС вешают на вперед/назад) управляют навигацией по буферам. В принципе, они позволяют выбирать следующий/предыдущий буфер, как Alt+влево/вправо, но с некоторыми нюансами, описанными ниже.
Кейбиндинги для Emacs Lisp и для SLIME:
(+ 1 2 3), курсор нужно ставить сразу после закрывающей скобки.Кейбиндинги специально для SLIME:
Пока что больше кастомных кейбиндингов нет, и все остальные на своих местах, но еще раз, надо помнить, что префикс-сочетание С-x перевешано на С-e, а С-c на С-d, так что меняйте это в уме, если где-то в документации по тому же Magit это видите. Но кстати с такими префиксами, работать со всем дефолтом даже удобнее, не так устают пальцы. А, еще в Lispy отрубил клавишу e, чтобы не мешалась, и еще там несколько мелочей в нем отрубил или поправил.
Ксатит вот где можно еще почитать по SLIME, Lispy и Magit:
C# официально устарел и отправляется в помойку, т.к. теперь веб-фреймворк Asp .Net Core MVC доступен из Common Lisp.
Можно так писать:
;; Asp.Net MVC controller
(define-dotnet-callable-class (example-controller
(:base-type . ControllerBase))
()
;; Echo the 'Hello' message to client
(:method index :string ((name :string))
(format nil "Hello~:[~;, ~:*~a~]!" name)))
https://github.com/Lovesan/bike/blob/master/examples/aspnet-mvc.lisp
На линуксе работает на SBCL и на CCL, проверял.
Конечно, нужно немного дополнительных телодвижений, т.к. .NET прокси-классы генерируются в рантайме, и поэтому их надо руками указывать в качестве контроллеров, но это в принципе все при желании автоматизируется макросами и другими средствами метапрограммирования.
Также, пока bike не поддерживает аттрибуты, но это наверное добавлю позже.
Ну и с extension-методами пока не придумал что делать, пока их классы надо руками писать.
В сфере SE/SA/IT существует только три вменяемых вида оплаты труда. Первый это почасовка, которая применяется для разовых задач(настроить сервак, перекрасить кнопку, итд). Второй вариант это фиксированная сумма, опять же для разовых задач(или этапов задач). Третий вариант это «зарплата в месяц».
Комбинации, особенно первого и последнего - это признак галерного рабовладельческого трешака, от которого надо бежать к херам (трудодни таймшиты, и прочая).
Что касается сроков: и в первом, и во втором случае, заказчик имеет право ставить конкретные сроки решения задачи. В последнем случае право, конечно, имеет, но вот рассчитывать на конкретный результат может только в том случае, если сроки решения задачи измеряются энным количеством месяцев(с округлением, допустим) и требования фиксированы и детально обговорены заранее.
Из чего следует, что схема «зарплата в месяц» эффективна только в следующих случаях:
Отсюда вывод - чтобы не угореть от безысходности и корпоративного ада, нужно становиться ИП/самозанятым и делать разовые заказы. Вопрос, почему такое не так уж часто встречается даже там где надо делать какие-то задачи, а не просто уныло поддерживать старье, и почему все хотят тебя посадить на зарплату по ТК? Из-за специфики ТК и вообще законодательства? Из-за лишней бюрократии?
Давайте я вам поясню про язык Go, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.
Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.
Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.
Но дело вот в чем. В гугле, на самом деле, над каждой командой гошников стоит тимлид, или целая группа, который/которая вот этим взаимозаменяемым роботам-гошникам расписывает всю систему, чуть ли не вплоть до состояния конечного автомата, до if-ов, и показывает куда и что писать. Поэтому же Go на корню режет всю креативность, поэтому там нет практически никаких средств абстракции, и поэтому он не дает делать вообще ничего сложного. Дабы программисты на нем вообще ничего лишнего не думали, а кодировали все чуть ли не побуквенно по указаниям умных людей.
Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.
Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?
А тут надо понимать, как внутри устроены огромные корпорации типа гугла.
Их давно пожрал рак бюрократии. Там у менеджерских и околоменеджерских должностей один из главных критериев промоушнов, или вообще даже ассесмента(усидения на должности), это количество людей у тебя в подчинении. И количество говнокода в вакууме которая твоя команда написала. И вот все эти люди, сидящие на более-менее средне-высоких должностях, постоянно бодаются за эти промоушны и ассесменты. Это их главная и единственная цель. Поэтому, ни о какой эффективности тут речи не идет вообще от слова совсем. Тут главное - корпоративные игры, количество голов в твоем стаде и количество и размер высеров, которые это твое стадо произвело(причем буквально, важны SLOC).
Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.
Если у вас в компании такой «модели управления» нет, и более того, у вас нет возможности нанимать крайне высококвалифицированных людей за крайне много денег, единственное назначение которых будет расписывать стаду гошников(которые тоже стоят немало денег просто из-за количества) систему до уровня конечного автомата, то вам этот язык и вся его экосистема нахрен не сдалась.
Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.
Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.
В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.
Вобщем, я тут в своей библиотеке для интероперабельности Common Lisp и .NET - запилил мега-фичу - прокси-классы.
Это такие классы, лисповые, которые с помощью магии метаобъектного протокола CLOS и немного System.Reflection.Emit - прикидываются .NET классами, а их объекты, соответственно - .NET объектами.
Это позволяет бесшовно интегрироваться с .NET кодом, например реализовывать .NET интерфейсы или вон, идиоматически писать на WPF, с MVVM, биндингами, командами и всем прочим.
Вон пример приложения, это браузер пакетов(лисповых неймспейсов) CL: https://files.catbox.moe/77wdbn.png
https://github.com/Lovesan/bike/blob/master/examples/wpf.lisp (потом как-нибудь еще добавлю пример с Avalonia, чтобы было кроссплатформенно вообще).
Вот соответствующий XAML. Как видно, вьюха напрямую биндится к свойствам вью-моделей, как будто у нее под капотом C#. https://github.com/Lovesan/bike/blob/master/examples/WpfUserControl.xaml
Код в принципе там понятен, особенно тем кто имел дело с WPF/Avalonia. Но документацию надо бы написать, да, работаю над этим. Докстринги это хорошо но мало.
После пары лет наконец выпустил новый релиз своей библиотеки для интероперабельности Common Lisp и .NET
https://github.com/Lovesan/bike/tree/0.13.0
Там есть серьезная issue, касающаяся линукса, с которой вообще нужна была бы помощь. Что-то опять с сигналами не так, на этот раз с SIGFPE.
https://github.com/Lovesan/bike/issues/10
Если для Ъ - после загрузки рантаймов последних версий .NET в лисп(тестировал на SBCL и CCL), лисповый процесс грохается с SIGFPE.
Выглядит это обычно примерно так:
CORRUPTION WARNING in SBCL pid 151 tid 163:
Received signal 8 @ 7f00cbeb2c3b in non-lisp tid 163, resignaling to a lisp thread.
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
Floating point exception (core dumped)
Началось такое с релиза .NET 6 и продолжается до сих пор. Т.е. .NET 5 работает, и .Net Core до него работали тоже.
Проблемы с сигналами на линуксе уже раньше были(так и хочется сказать - потому что сигналы это кривое говно by design), но мы с одним из разработчиков SBCL их закостылили - переписываем дотнетовские сигналы лисповыми, кроме тех которые дотнет нормально обрабатывает.
Для SBCL и в этот раз есть костыль, правда, кривой. Вырубить отлов исключений операций с плавающей точкой. Но тогда, вместо вызова исключений, в случае операций по типу (/ 1.0 0.0) будут возвращаться значения типа +inf, -inf, и всякие там NaN. Что вобщем-то не по стандарту CL и вообще криво.
Возможен ли подобный костыль для CCL и других реализаций - непонятно. Как и непонятно, что вообще в дотнете сломали и поменяли. Сорцы я его смотрел, но они ужасны, огромны, и написаны как говно, особенно в низкоуровневой области, там где C++, работа с ОС и вот это вот все.
Будете смеяться, но я только сейчас начал понимать, о чем на самом деле все это время говорил Столлман и сотоварищи.
Всем понятна аналогия о том что «free as in beer» это неправильное понимание свободного ПО, несмотря на то что множество людей его так и понимает, особенно в постсовке.
Свобода ПО это в первую очередь свобода от использования ПО в качестве инструмента принуждения, в том числе инструмента массовой слежки.
И вот что мы видим на примере OpenAI? Куда оно отправляет все данные и все диалоги? А вот хрен знает куда. И как это всё потом используется? Код-то закрыт.
Ну, с прошлой темы прошло достаточно времени, но вот теперь я задался вот этим вопросом. Ну, он куда сложнее. С одной стороны Megadeth часто куда техничнее, чего стоит один Holy Wars, но с другой стороны, Metallica часто имеет куда более внушительные элементы Thrash-метала. Что думаете?
А есть такая штука вообще? Помоему, было бы круто для кросс-компиляции или вообще нативно.
Под винду, под MinGW, собирается и работает куча софта, но руками такое делать довольно муторно. К тому же у библиотек есть куча опций сборки, так что можно было бы задействовать use-флаги и так далее.
Может я проспал, и такое есть, гентой давно не пользовался, но вдруг стало интересно.
А то пилю потихоньку свои скрипты, но вдруг это кривой велосипед, и оно уже сделано?
https://github.com/Lovesan/mingw-xc/
Кстати некоторые вещи(например как собирать NSS) - скопипастил именно из гентовских ебилдов.
Я не понимаю уже, это ЛОР или форум для тринадцатилетних девочек-анимешниц? Че удалять то? Не дают парням поговорить нормально, не то слово сказал, так все, подгорает снизу, жаловаться идут в некорректные сообщения.
Че за дела вообще? Че за синдром вахтера? Хватит уже на мат триггериться.
Че круче? Как думаете?
Я склоняюсь к Metallica \m/
https://programming-language-benchmarks.vercel.app/problem/spectral-norm
Немного лучше него, буквально на десяток миллисекунд, справляется rust.
Назовите теперь хоть одну причину использовать плюсы вообще?
Перемещено xaizek из development
Сабж.
Супер крутая игруха, только что вышла в Early Access в стиме. Багов, конечно, море, но потенциал огромен. Круче Space Engineers и подобного всего вместе взятого. Редактор космических кораблей - натурально не уступает CAD для авиации.
В фичах - программируемость всего и вся, на специальном басикоподобном языке YOLOL. Чуваки на нем запилили даже GPS-систему навигации. https://isan.to/isan.pdf
Продуманность и детальность системы сборки кораблей просто детальнейшая. Балки свариваем, потом на них заклепками что-то прикрепляем, ко всему надо кабели, а куда-то там и трубы, вообщем хардкор.
Да, также можно грабить корованы.
И зачем они это делают до сих пор, не считая поддержки легаси?
Перемещено Shaman007 из development
Тащемто, для полного счастья в bike, кроме прочего, не хватало ридер-макросов, которые бы уменьшали количество круглых скобок, квотирования и прочего текста при вызове дотнета.
Тащемто теперь есть. Вот так можно вызывать методы:
(use-namespace 'System)
[:Console WriteLine "Hello, World!"]
Вот так можно получить текущее время в стринге: (ни одной круглой скобки! может это tcl/tk?)
[[:DateTime %Now] ToString]
А вот так получить значение максимального int32, из специального статического поля соответствующего класса:
[:int $MaxValue]
Более того, можно стучаться в индексеры дикшнрей и прочих объектов, даже круче чем в Clojure:
(let ((dict (new '(Dictionary :string :string))))
(setf #[dict "Hello"] "World!")
dict)
И создавать Enum-ы не обременяя себя расставлением запятых:
(use-namespace 'System.Reflection)
#e(BindingFlags Public Static)
На закуску, для любителей ковыряться в байтах, добавил и такую возможность, прямо как в C# только лучше:
(use-namespace 'System.Text)
(let ((dotnet-array [[:Encoding %UTF8] GetBytes "Hello, World!"]))
(with-fixed (raw-pointer dotnet-array)
(cffi:mem-ref raw-pointer :uint8)))
;; ==> 72
Не хватает батареек? Тогда мы идем к вам!
Вобщем, дошли руки потыкать палочкой.
Я вот что не пойму - зачем и кому он нужен, ну правда?
Это же новый C++. То есть, чрезмерно переусложненный язык, в котором, как говорил Луговский, разобраться может разве что хорошая зубрилка, а не хороший программист, но при этом не дающий никаких бонусов к продуктивности, и никакими киллер-фичами не обладающий.
Close to metal? Нет, извините, мне когда надо будет close to metal - я пойду сишку возьму. Которая реально, и Close To Metal, и со стабильным ABI, так важным для низкоуровневого программирования, и так далее. А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность до нужного уровня, при этом не стреляя себе в ногу.
Продуктивность разработчика? Я сильно в этом сомневаюсь. Потому что вот есть языки программирования, предлагающие наибольшую продуктивность, не ограничивающие пользователя практически никак, и, конечно, вместе с тем, довольно сильно нагружающие межушной нервный узел, довольно нетривиальные для изучения. Как пример, лиспы всевозможные. Но Rust в их число не входит. Там на каждом углу костыли, подпорки, железные двери с замками, и чуть что так обухом по голове можно получить.
Наконец, ну безопасность чтоли, хваленая? Ну, опять нет. Взять тот же unsafe. Если вам нужна прямо таки безопасность-безопасность - берите что-нибудь вроде хаскеля(или какого-нибудь Coq, или что-нибудь подобное, с зависимыми типами, если совсем упоролись), ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.
Вобщем, не вижу зачем этот язык нужен, нам и C++ хватает, если надо не ехать, а шашечки(т.е. тупо позадротствовать, да).
| следующие → |