Опубликован релиз GNU Guile 3.0.10, свободной реализации функционального языка программирования Scheme, поддерживающей возможность встраивания кода в приложения на других языках программирования. Guile может быть использован как язык для разработки расширений для приложений, определения конфигурации или разработки компонентов для связи различных примитивов, предоставляемых приложением. Guile является официальным языком разработки расширений для операционной системы GNU...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61430
Пока что единственный нормальный гнутый язык.
как? есть же питон
Питон не гнутый, он PSFL.
это что за зверь?
Это пример как бздненужно. Подробно на секретном сайте https://ru.m.wikipedia.org/wiki/Python_Software_Foundation_L...
Анонимоненужно, а БСД нормальная лицензия, со своими минусами и плюсами.
мне тоже больше по душе BSD по сравнению с GPL, а ещё больше нравитца MIT
Ровно до тех пор, пока ты не прекратишь мечтать и не начнешь писать код.
Большая часть кода, которая вываливается на гитхабчик, и так лицензирована всякими пермиссивными лицензиями. От этого весь этот код не становится нужнее.
Думаю, он всё-таки иронизировал
Он тягучий.
Не надо так, он хищный
> Питон не гнутый, он PSFL.Professional Spring Football League?
Когда мне в голову приходит мысль, что мне придётся пересаживаться с крутых технологий на пейфон, я впадаю в уныние.Пейфон модный, это факт. Но там ни одного преимущества не вижу. Даже перед водой, не говоря уже про дотнет
А крутые технологии это которые?
> А крутые технологии это которые?Смотря для каких целей. Для бека - дотнет. Для мобилок - нативное, для веб-фронтенда js.
о да. расскажите про крутые технологие которые Вы упямянули
> о да. расскажите про крутые технологии которые Вы упомянулиЛюбые, у которых есть осязаемые техническое преимущества:
Например:
- строгая типизация и как следствие
- расширенные оптимизации производительности
- статический анализ исходя из типов
- ошибки времени компиляции а не рантайма
- скорость. экономия оперативки и цпу
- отсутствие GC
- многопоточка
- расширенный ООП или ФП,
- нативная АОТ компиляция
- нормальный синтаксис "примерно как у всех"Например, голанг, дотнет, c++, js. Да что угодно кроме пейфона на мой взгляд можно брать.
Что из этого есть у golang: отсутствие GC, расширенный ООП, нативная АОТ компиляция?
Что из этого есть у js: начиная со строгая типизация; отсутствие GC, ошибки времени компиляции а не рантайма, многопоточка, статический анализ исходя из типов?
Если нужно удовлетворить часть пунктов, то в Common Lisp есть расширенный ООП, расширенный ФП само собой, он компилируемый, есть нативная АОТ компиляция, сильная (динамическая) типизация. То есть кроме привычного синтаксиса он целиком удовлетворяет требованиям?
Между прочим именно в Lisp первым изобрели GC, который есть в перечисленных тобой и мейнстримных языках.
> - отсутствие GCНа самом деле само по себе наличие GC -- это не минус. Всё зависит от реализации. Сделать хороший многопоточный GC -- это задача на докторскую, как минимум, да. На данный момент существуют две таковые: в JVM и в OCaml.
> - расширенный ООП
ООП кстати штука не обязательная. Он прекрасно заменяется теорией категорий. За примерами можете обратиться к Haskell и OCaml.
> - скорость. экономия оперативки и цпу
> - нативная АОТ компиляцияЕсли писать 12-factor-приложения, без этого можно обойтись, но если оно есть, это конечно хорошо.
По остальным пунктам -- просто да, без уточнений.
PS:
> Например, голанг, дотнет, c++, js.
Примеры сомнительные. Вашим критериям скорее удовлетворяют некоторые языки семейств Lisp и ML. Ну кроме "синтаксис как у всех". Обратите внимание, например, на Racket Scheme и OCaml. Особенно на последний. А так, приведённые вами критерии говорят о том, что вы движетесь в верном направлении.
>> - отсутствие GC
> На самом деле само по себе наличие GC -- это не минус.
> Всё зависит от реализации. Сделать хороший многопоточный GC -- это задача
> на докторскую, как минимум, да. На данный момент существуют две таковые:
> в JVM и в OCaml.Вариант GC для OCaml лежит у меня на гитхапе, вместо родного консервативного, уплотняющий. Не помню в оригинале "хорошей моногпоточности".
Проще говоря: потрудись подтвердить ссылкой на исходники.
Кстати, сообщения от Анонима тебе не запретили удалять? ;)
JS: строгая типизация, расширенные оптимизации производительности, скорость. экономия оперативки и цпу, нативная АОТ компиляция :))
В JS свои приколы, которые его делают конкурентным. Например, единый язык на фронте и беке.Для любителей типов есть TS, а по производительности он значительнее шустрее пейфона
> Когда мне в голову приходит мысль, что мне придётся пересаживаться с крутых технологий на пейфон, я впадаю в уныние.Уныние — грех
Преимущество в том, что это реально язык, который поймёт любой школьник, а не только ученик физматшкол, входящих в топ-100 России. Это идеальный язык для обучения.
Почти идеальный для обучения, всё же - это Pascal. Python очень далёк от идеала в этом плане.
Паскаль хорош для обучения, потому что для обучения ему ничего не надо менять. Вот преподаватели-пенсионеры, они уже есть, они могут преподавать паскаль условно до смерти.Ему ещё подыгрывает оторванность образования от реальности. Нет нацеленности на подготовку реальных работников - можно учить любым языкам. Обучающийся всё стерпит, его время бесплатно, а потом он внезапно может даже защищать такое обучение (землянам приятнее считать, что они делали что-то полезное и осмысленное, это полезно для их психики).
Pascal хорош для обучения, потому что:
1. Простой синтаксис.
2. Строгая типизация.
3. Компилируемый.
4. Работает с указателями.
5. Отсутствует (или там очень мало) UB.
6. Модули.Да, он сейчас мало где применяется, это правда. Но для обучения принципов программирования - очень даже хороший язык. После него уже можно переходить к другим, более современным языкам.
Ну это несерьёзно. Вот примерим эти пункты на ALGOL 68-R, Pascal и C#. Одинаково хорошо ложатся. Но выставить вперёд надо Pascal. Почему? Потому что на самом деле важны другие пункты: система из преподавателей-старичков, из написанных и принятых учебных программ и учебников, из такой родной и привычной негибкости системы образования. Всё это приправляется некоторым принятием в обществе - "я сам же ж так учился", "я сам же ж потом на Delphi писал", а общество это со своими тёплыми чувствами может ещё пунктов помимо этих шести накидать для рационализации.На практике из диалектов могут преподавать PascalABC.NET, то есть монстра с доступом ко всему дотнету, который прикостыляли к паскалю.
>Вот примерим эти пункты на ALGOL 68-R, Pascal и C#. Одинаково хорошо ложатся.Пошли попытки натянуть сову на глобус. Нет, не одинаково хорошо. Особенно, если мы говорим про пункт 1.
>Но для обучения принципов программирования - очень даже хороший язык. После него уже можно переходить к другим, более современным языкам.Видимо прохожему плевать на время других людей. Паскаль хороший язык, но если мне нужен чистый Си или Джава, я не буду тратить своё время на Паскаль.
>Видимо прохожему плевать на время других людей.Всё ровно наоборот. Когда мы говорим о Паскале, речь идёт об обучении студентов или даже школьников. Человеку для начала важно понять основные принципы программирования, а потом уж переходить к деталям. Так вот для изучения этих самых принципов Паскаль очень даже хорош. До сих пор, как бы странно это ни было.
> Pascal хорош для обучения, потому что:
> 1. Простой синтаксис.
> 2. Строгая типизация.
> 3. Компилируемый.
> 4. Работает с указателями.
> 5. Отсутствует (или там очень мало) UB.
> 6. Модули.
> Да, он сейчас мало где применяется, это правда. Но для обучения принципов
> программирования - очень даже хороший язык. После него уже можно переходить
> к другим, более современным языкам.Любой другой язык делает тоже самое, и паскаль прекрасно заменяется питоном, шарпом, плюсами, джавой, та хоть го.
Golang для обучения лучше, только при обучении надо выкинуть (или замести под ковер) все кейсы с interface{}. Статически типизированный (с учётом поправки выше), простой синтаксис с минимумом вариативности, явная обработка ошибок, форсированный стиль кода. И С понять потом будет легко - поняв слайсы, легко поймёшь указатели
> Преимущество в том, что это реально язык, который поймёт любой школьниквставьте сюда ЛЮБОЙ современный язык.
Haskell, C++, Rust. Мало кто из школьников с нуля, не зная азов, сможет их освоить. Что уж там говорить, далеко не все профессионалы могут.
Если бы он был нормальным его бы сам GNU из своих проектов не выпиливал.В gdb он признан устаревшим
Каждому овощю свой фрукт.
>В gdb он признан устаревшимЭто потому что пропал калабуховской дом и Столлман уже лисп не пиарит.
А чего же его в Guix выбрали для описания сборки пакетов, для самого пакетного менеджера?
Лисп-подобные языки удобны для DSL.
> А чего же его в Guix выбрали для описания сборки пакетов, для
> самого пакетного менеджера?А гуикс это что-то популярное и повсеместно используемое? Насколько я помню это поделка маргинальных васянов которая никому не нужна.
>В gdb он признан устаревшимЧто за бред.
Как по мне так дофига многословный. На таком только копилоту писать удобно.
> по границе 500 символов, а не 80Интересный коэффицент. Если язык не менялся, а перестало хватать 80, то менялись использования.
Мониторы внезапно перестали быть текстовыми. Это как на пути нашего радиоканала внезапно построили дом.
исходники должны влазить в два вертикальных сплит редактора IDE, 80 символов для этого в самый раз, остальное неважно
Выкинь уже свой 15 дюймовый квадратный монитор уже. Прошу тебя. .
Больший монитор - возможность поместить больше текстовых областей. Отказ от 80 символов сводит это преимущество на нет. Хотя на C++ действительно сложно уложиться в 80, а в Java/C# так совсем. На Python, Bash, D - вообще спокойно
Писать в пределах 80 колонок можно, просто выглядеть это будет ужасно (эстетически). Особенно это касается XAML с его нивротбольшими названиями атрибутов и байндингами.
Писать краткий код, легко читаемый код, на хорошем языке - это спутники таланта.
В 2024 году и 120 влазит
для 3-way diff и мерджа хорошо бы даже 3 колонки сразу видеть
> Добавлена поддержка упрощённого синтаксиса wisp, позволяющего писать более читаемый кодВо, уже даже сами лисперы признают, что (((с(ко))б(((к)))и) -- это нечитаемо.
Глядишь, когда-нибудь и обратную польскую нотацию признают нечитаемой.
(насчет (с соглашусь (твоей позицией)) (польской нотации))
мне больше по душе О-нотация
Так у них же не обратная польская(1 3 +), а префиксная запись(+ 1 3)
Питоновская нотация ещё более не читаемая.
Давно ты конфиг емакса не открывал
Есть два типа программистов: те, кто понял Лисп, и те, кто так и не научился программировать. По реакции)))))) на скобочки можно очень легко отделить первых от вторых.
Турчин не понял Лисп и потому сделал в Рефал три вида скобочек? Я серьёзно спрашиваю. Если превосходно читаемый код приходится особым образом форматировать, это первый звоночек. Не про Лисп, а вообще.
> Если превосходно читаемый код приходится особым образом форматировать, это первый звоночек.Программу на любом языке программирования приходится особым образом форматировать, иначе она превращается в нечитаемое месиво чаров. Например, C позволяет писать без переводов строк вообще, но попробуй такую программу прочитай.
> Турчин не понял Лисп и потому сделал в Рефал три вида скобочек?
Что за турчин, и что за рефал? Какая-то никому не нужная маргинальщина? Раз маргинальщина, значит не понял.
>> Турчин не понял Лисп и потому сделал в Рефал три вида скобочек?
> Что за турчин, и что за рефал? Какая-то никому не нужная маргинальщина?
> Раз маргинальщина, значит не понял.Зачем же ты влез с своим сверхценным мнением, если не понял? Тем более, что о тебе тем более никто ничего не слышал.
>> Если превосходно читаемый код приходится особым образом форматировать, это первый звоночек.
> Программу на любом языке программирования приходится особым образом форматировать, иначе
> она превращается в нечитаемое месиво чаров. Например, C позволяет писать без
> переводов строк вообще, но попробуй такую программу прочитай.Аноним ничего не слышал про индукцию и наивно полагает, что частный случай доказывает общее правило. Тем более он не слышал про ЯП, очень похожие на обычный текст.
Да чего там понимать. Лисп - это язык по сути без синтаксиса, с программированием в AST напрямую (прямолинейный маппинг s-expr на AST синтаксисом назвать сложно). Понятно-то оно понятно, но программировать напрямую в AST - это удовольствие на любителя. Ну кому-то нравится.
да все равно, чтобы нормально поставить все эти точки и двоеточия, надо понимать, где у тебя скобочки
не знаю, я вот с лиспом не знаком, но вариант со скобочками понял что делает, а висп вариант - нет (пока скобочки не подглядел).
> Реализован экспериментальный интерфейс для использования сторонних бэкендов.Ждём натив и VOP.
Так и не понял в чём смысл лиспов, если по скорости они отстают от других языков. Даже джава быстрее.
Во первых это красиво.
Зависит от шрифта. В некоторых скобочки смотрятся убого.
Собственно, на этом и всё :) Причём это красиво КОНЦЕПТУАЛЬНО, а не синтаксически. Лисп потому и остался в академической ***опе, что не вывезет нормальные серьёзные приложения.
Смысл лиспов в макросах, что позволяют просто создавать dsl: для примера в guix пакеты описываются тоже на схеме. Также это позволяет имея небольшой набор базовых сущностей все сводить к ним или легко добавлять нужный тебе синтаксис. Например, добавить unless в питон без модификации компилятора ты не сможешь, а в лисп пожалуйста.По скорости он, конечно, сильно быстрее питона, но с примерно той же скоростью разработки (в отличие от джавы).
Ещё один немаловажный фактор - это простота языка. Спецификация r6rs занимает всего 90 страниц. Что позволяет просто реализовать язык самому. Пусть он и не будет таким же быстрым как существующие реализации, но будет корректным. Благодаря этому схема выбрана проектом GNU Mes для бутстрапинга компилятора gcc.
Т.е. вы хотите сказать, что можно взять и относительно быстро написать на Lisp транслятор в С++, потом скормить этом транслятору код приложения на LISP и получить корректный код на С++, потом все это скормить компилятору С++ и получить работающее приложение, тем самым сократив время разработки?
> Т.е. вы хотите сказать, что можно взять и относительно быстро написать на
> Lisp транслятор в С++, потом скормить этом транслятору код приложения на
> LISP и получить корректный код на С++, потом все это скормить
> компилятору С++ и получить работающее приложение, тем самым сократив время разработки?Нечто подобное в Naughty Dog для данных (https://www.youtube.com/watch?v=oSmqbnhHp1c), только использовали racket.
Есть одна маленькая проблемка: DSL в лиспе тоже являются лиспом! Если я правильно понимаю, ты можешь наопределять функций, но они всё равно должны подчиняться синтаксису лиспа - те же скобочки, "цитаты" и т.п. Нафига оно тогда мне?? Сравни с Nemerle - там ты можешь ЛЮБОЙ синтасис задвинуть, хоть вообще из одних знаков препинания! :) Это и есть настоящий DSL - когда нет никаких ограничений.
> но они всё равно должны подчиняться синтаксису лиспаНе обязательно, например, в Racket можно кастомизировать reader https://beautifulracket.com/explainer/lang-line.html
> Есть одна маленькая проблемка: DSL в лиспе тоже являются лиспом!Преобразуй свой синтаксис в лисп подобный (s-expr) и потом работай с ним привычными средствами.
> Нафига оно тогда мне??
А чтобы сразу работал подсветка в редакторе и привычный тулинг. А также чтобы можно было использовать встроенные в язык функции, так, например, в описании guix пакетов.
Код это данные, данные это код. Это очень мощный подход для метапрограммирования. И новый синтаксис это ломает. Это как json формат, но json это только данные. По поводу скобочек до сих пор не могу понять претензий разве в JavaScript их меньше, с той лишь разницей что скобочки пишутся после вызова имени функции, а не до.
Сравни (defun foo (a b) (boo a b)) и function foo(a, b) { return boo(a, b); } скобочек ровно столько же. Более того в js встречаются конструкции колбеков с их громадой скобочек }) }) }).
В JavaScript скобочки разные.
Какая разница. В Clojure вот скобочки разные например, но почему )))) - это "ой боюсь, страшно", а }) }) }) - это нормальный синтаксис? Одинаковые скобочки может IDE легко закрывать по хоткею например. Да и в js одинаковые подряд тоже бывают foobar(foo(bar())).
Потому что люди разные и восприятие различается. Одному удобнее одинаковые )), поскольку не надо думать, где какую поставить. Другому }), поскольку видно, какая что закрывает.
Стандарт схемы позволяет использовать разные виды скобок, так например в racket и chezscheme много используются квадратные скобки для читабельности.
Так и претензия к одинаковым скобочкам. Не удивлюсь, что во время зарождения LISP других скобочек и не было. Сделали же в Си триграфы ??( для [ и ??< для {.
разновидностей лиспов есть много.
и не сказал бы что какой-то SBCL отстаёт от явы по скорости. Скорее наоборот совсем
Считается, что функциональные языки более надёжны, в них можно динамически конструировать (и модифицировать) процедуры, отсутствие жёсткой структуры у данных и алгоритмов облегчает сопровождение.
А ещё можно менять программу прям в проде, и ничего не сломается.
вы путаете lisp-подобные языки с функциональными, то, что lisp отчасти (но не полноценно) функциональный - это просто следствие его дизайна, а вот слабость типов - это сам дизайнhaskell функциональный, причем полноценно (в отличие от lisp), но статически типизирован.
> Так и не понял в чём смысл лиспов, если по скорости они отстают от других языков. Даже джава быстрее.В краткости решения задач на этом языке, для которых язык предназначен?
вполне можно получать близкую к Си производительностьhttps://github.com/digego/extempore
https://gist.github.com/marcoheisig/a17ece641cbdd39de5cf1ea2...работая при этом с запущенной программой: например, можно писать игрушку, пока она запущена
ну и всякие там непревзойдённые возможности по выразительности языка. например, ничего круче
https://groups.csail.mit.edu/mac/users/gjs/6946/refman.txt
для работы с классической физикой я не видел. где ещё можно писать лагранжианы и сразу получать модели движения?
ниша lisp-ов: когда нужно делать нечто логически сложное, не жертвуя особо производительностью.
> для разработки расширений для приложенийРебят, объясните мне как проф. программисту, С КАКОГО ПЕР-ЕП-ОЯ скриптота внезапно стала нужной для "расширений"? Концепция "динамических библиотек" (которые можно загружать в рантайме и которые и есть РАСШИРЕНИЯ) существует несколько десятков лет, это те же *.so или *.dll (а может и ещё раньше - см. Smalltalk).
Спрашивается - нафига мне тормозная, нетипизированная, убогая скриптота, когда у меня есть ровно ТАКОЙ ЖЕ язык главного приложения (Си, C#, D, etc) на котором я ТОЖЕ могу делать расширения, только при этом зная ОДИН язык и не жертвуя ни на процент скоростью!??!
Распространение расширений, которые не зависят от бинарного представления на конкретной платформе. Не всегда стоит доверять скомпилированным кем-то программам/расширениям. Не всегда важна производительность ЯП, когда описывается какой-то сценарий.
Если программа УЖЕ скомпилена для Линукса, то какая на%рен разница, чё там с представлением? Просто поставляешь so-шку и программа её загружает! Для венды канпеляешь DLL. Всё. Тут нет никакой "зависимости", бинарный шмот основной программы будет такой же, как и расширения.Про доверие бинарям - извини, это уже к параноикам. Ты ставишь линукс, где скомпилены ТЫСЯЧИ программ. Не тобой. Как ты им доверяешь?? :))
Производительность ещё как важна! Ты же пишешь расширение - откуда тебе знать, как глубоко оно влезет? А если оно по каждому нажатию клавиши проверяет всю таблицу юникода? Скорость ВСЕГДА важна.
> мне как проф. программистута странная портянка, что ты накатал, делит на ноль тебя как профессионала
Ты бесконечно вырастил его в собственных глазах.
При делении на 0 генерируется исключение, а не бесконечность.
В матане нет исключений.
В матане нет и деления на ноль.
В матане есть пределы, в которых когда приходят к константным значениям при раскрытии, таки подставляют значения 0 или лежачую восьмёрку.
Но это не деление на ноль.
Далёк матан от программирования.
Потому что в этом мире далеко не все являются профессиональными программистами. Поэтому и Visual Basic и Python встроены в Excel, а не чистый Си.
Извини, но ты напишешь полное г***но хоть на пестоне, хоть на Си - разницы нет. Для работы с пестоном, прикинь, тоже нужна квалификация! В нём нет НИЧЕГО, чтобы домохозяйка со знанием Икселя могла на нём писать. Это тебе не "язык черепашки"!
Так что аргумент мимо. Ещё есть?
>Так что аргумент мимо. Ещё есть?Он тебе дураку пытается сказать, что Эксель и Питон лёгкие для освоения языки. Их и домохозяйка освоит, при сильном желании конечно же.
>Их и домохозяйка освоит, при сильном желании конечно же.Не освоит. Потому что такое желание у неё никогда не возникнет. Даже несмотря на то, что языки простые, сам процесс программирования таковым не является. Сужу исходя из жизненного опыта. Когда-то давным-давно работал в весьма крупной корпорации с многомилиардными долларовыми оборотами. Там был огромный штат экономистов и бухгалтеров. Все поголовно использовали Excel. При этом никто не умел программировать на доступном тогда и как бы простом Visual Basic. И даже мысли научиться не возникало. Хотя у всех было высшее образование. Так что не надо фантазировать на тему кто что гипотетически может.
> я ТОЖЕ могу делать расширения, только при этом зная ОДИН язык и не жертвуя ни на процент скоростьюДелай. Тебе никто не запрещает писать расширения к emacs'у на C. Или расширения к firefox'у на C++. Да, будут определённые неудобства, типа необходимости перекомпиляции сорцов, после каждого изменения расширения, но я не думаю, что это какая-то серьёзная проблема.
И я на полном серьёзе тебе рекомендую попробовать. Если ты не понимаешь зачем нужен отдельный язык для расширений с динамической типизацией и сборкой мусора, то возьми и попробуй обойтись без этого. Собственный опыт -- лучший учитель.
Фигню не говори! Не нужно ничего ПЕРЕкомпилировать, ты видимо давно не писал программ - освежись. Аддоны прекрасно загружаются, даже если ты сменил сто версий основной программы. Просто в этом и суть внешних библиотек (вернее, модулей) - они не зависят от основного кода, так и было задумано.
> Аддоны прекрасно загружаются, даже если ты сменил сто версий основной программы.Ну-ка покажи мне пример, как ты подгружаешь аддон писанный на C к emacs'у без перекомпиляции emacs'а.
> Ребят, объясните мне как проф. программисту, С КАКОГО ПЕР-ЕП-ОЯОрать не надо, «программист».
> Спрашивается - нафига мне тормозная, нетипизированная, убогая скриптота, когда у меня есть
> ровно ТАКОЙ ЖЕ язык главного приложения (Си, C#, D, etc)«Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.»
Смотря какие расширения. Если расширения - скрипты, то скриптовый язык лучше. Скрипты это несложные программы которые по назначению надо постоянно менять. Представь программу-качалку с разных сайтов или программу-переводчик использующую какие-то сайты как сервисы или их апи. Сайты постоянно ломаются, соответственно расширения на скриптах намного удобнее, чем писать и компилить нормальный код.
какие сайты, какие апи? сходи накопай картошки и скрипт не нужен
> Если расширения - скрипты...Боже, что ты несёшь?? :)))
Расширения - это функциональность, причём тут скрипты? Пишешь внешний модуль, даёшь программе - она работает.
И нет, расширения НЕ простые программки! (иначе они нахрен не нужны) Там целая связь с API основной программы + свои функции. И нет, их не надо постоянно менять - с чего ты это взял???
Иногда - да, нужен апдейт. Просто перезаписал старый модуль - всё, расширение новое! Сорсы для этого не нужны.
Если сайты постоянно ломаются, это вообще не проблема расширений, они по-прежнему могут быть написаны на Си. А такие сайты идут на *****.
"Скриптоту" можно модифицировать налету (live coding), в простых случаях - без использования среды разработки. А скорость работы сценариев может быть неважна, когда они редко выполняются (например, только раз во время старта приложения), или когда значительное время занимает не сама обработка данных, а, скажем, системные вызовы (I/O). Кроме того язык скриптов может более намного проще и удобнее для разработки логики внутри приложени, за счет лучшей абстракции, большей независимости от платформы (ОС и железа).
О! Оптимистов подвезли :) Скажи, ТЫ ЛИЧНО много модифицировал расширений? :) Даже элементарный адблок (который на JS) - там чёрт ногу сломит, ты неделю будешь разбираться, кто там и что вызывает. Доступ к сорсам тебе НИЧЕМ не поможет, для начала ты должен чётко понимать всю логику аддона и только потом модифицировать. Что примерно сродни написанию этого аддона. :) Готов к таким вызовам?
Никто расширения не модифицирует, просто прими это. Принято жаловаться автору, тот фиксит (намного быстрее тебя, потому что знает его весь) и выкладывает апдейт. Всё.Без среды разработки? Хм... а зачем вообще лезть в программинг БЕЗ СРЕДЫ? :) Кто ты, воин?
Скорость важна. Просто спроси любого юзера Тундербёрда. :) Это для перделок неважно, сколько они работают. Важные и полезные расширения - они нетривиальны и могут вызываться по сотне раз за секунду - что ты им предложишь? Снова переписать всё с JS на Си? :)
Я не про то, что давайте совсем откажемся от скриптов, я про то, что расширения можно И НУЖНО писать на нормальных языках и скрипты тут ВООБЩЕ НЕ НУЖНЫ (не требование).Язык скриптов не может быть проще - хотя бы потому, что расширению нужен API главной программы + это должен быть ЯОН, позволяющий выразить ЛЮБОЙ алгоритм. Соотв. ты по-любому съедешь обратно к тому, что тебе нужен Си (к примеру). Чем тупее и высокоуровневее язык, тем МЕНЬШЕ ты можешь на нём выразить, так что зачем он для расширений??
Вот тебе пример: Бейсик (в самой его тривиальной реализации а-ля БК-0010 или GWBASIC). Много ты на нём напишешь? Ты даже "словарь" не сможешь использовать - его там попросту нет. :) Ну и смысл в этой простоте и "независимости от платформы"?? Нет зависимости - значит НЕТ ВОЗМОЖНОСТИ использовать нативные средства. Скажем, "моргнуть иконкой в трее" или создать задачу по расписанию. Получается, все твои выразительные средства - посчитать факториал, да месыдж бокс показать. Кому нужен такой "скриптонит"??
Quake работал на железках в 100 раз медленнее нынешних.Тем не менее, вся логика, а также многое из отрисовки, была написана на интерпретируемом языке QuakeC.
Казалось бы, зачем? Зачем терять скорость выполнения на и так уже не быстрых компьютерах? Зачем нужна была ещё одна прослойка от фантазии разработчика до процессора?
Подумай над этим.
Потому что ты пишешь программу для оператора, а оператор не проф. программист(как и ты, судя по твоим умозаключениям), он не может, и не должен знать плюсы, для того чтобы прикрутить к своей программе что либо. Оператору нужен язык который может понять человек, а не программист. Именно по этой причине существует, питон, луа, автолисп, 1С, матлаб и прочее. Чтобы человек, которому нужно больше функциональности, мог дописать эту функциональность, не имея 6 лет кампутер саенс вышки за плечами. И страдать жручи С++, шарпы или джаву он тоже не должен.
> скриптота внезапно стала нужной для "расширений"?Попытка отдать пользователю описание логики работы, нужной пользователю.
Для простых вещей неплохо. Взлетело ж? Значит, хорошо подходит.
Но если человеку не рассказать про остальное богатство инструментов и возможностей, то некоторые начинают программировать на скриптоте, что была под рукой. Что плохо, да.
А чем плоха логика, написанная на Си? :) Даёшь юзеру скелет, он его наполнил, сканпелял - вот тебе быстрый, компактный аддон. В чём тут ТРЕБОВАНИЕ именно скриптоты?? Она кстати ничуть не легче тех же Си или C#. Просто ЯОН в принципе не может быть "простой" - все конструкции того же Си обязаны присутствовать, иначе ты просто не сможешь выражать все алгоритмы.Взлетели скрипты?? Хм... куда и какие именно? :) Не, ну то, что куча программ стала тормознее в тысячу раз - да, это я заметил. Тот же Тундербёрд на JS - это вообще пи_____ц. Но "взлетело" - я б так не говорил. Нет на сегодня успешных проектов, где "скриптота" - основа расширений. То, что куча леммингов ест какой-то кактус - это вовсе не "взлетело", это называется "на безрыбье и рак - карась".
Моя мысль в чём: если есть какая-то серьёзная программа с ядром, вовсе не нужно тащить в неё скрипты - они только загадят экосистему (вместе с дилетантами-скриптописаками). Можно и нужно давать API для того же языка, на котором написана прога. И такие аддоны будут идеальным решением, т.к. будут почти как "родные". Скрипты не будут родными никогда, да и не нужны они: аддоны - это тоже серьёзная работа, её не должны делать те, кто вчера написал на жабоскрипте хелловорлд.
> Просто ЯОН в принципе не может быть "простой"
> - все конструкции того же Си обязаны присутствовать, иначе ты просто
> не сможешь выражать все алгоритмы.Не проецируй на других свои знания и способности. Лучше почитай "мем с тырнета" под названием "тезис Чёрча-Тьюринга".
На их сайте всё написано:Using any of the supported scripting languages, users can customize and extend applications while they are running and see the changes take place live!
Users can easily trade and share features by uploading and downloading the scripts, instead of trading complex patches and recompiling their applications
Не убедил. Зачем мне live?? Как разработчик, у меня и так есть IDE со всеми плюшками. Запустил, отладил, опубликовал. Конечному юзеру ТЕМ БОЛЕЕ не нужно - он просто положил аддон рядом и он работает.Скрипт - это просто файл. Скачать файл и записать его в /addons/ - не бóльшая трудозатрата, чем скачать ТАКОЙ ЖЕ ФАЙЛ в виде .so и положить туда же. Какие ещё "complex patches and recompiling"??? Авторы явно не в курсе, что динамические либы для того и придумали, что не нужны никакие recompiling. Скриптовое дилетантство - вот что мешает разрабам трезво взглянуть на ненужность и ущербность скриптов как "языка расширений".
Неужели ты не отличаешь динамическую типизацию от динамических библиотек.
Смотря для каких целей. Для каждого инструмента своя цель. Для прототипирования или если нужно накидать быстро скрипт на один раз. Пока ты ещё будешь с указателями разбираться, они уже будут кофе попивать.
> Неужели ты не отличаешь динамическую типизацию от динамических библиотек.Он и 10-е правило Гринспена назвал "мем с тырнета". ;)
>Кроме языка Scheme, для которого реализована поддержка спецификаций R5RS, R6RS и R7RS, в рамках проекта Guile разработаны компиляторы и для других языков, таких как ECMAScript, Emacs Lisp и LuaА насколько разнятся Scheme и Emacs Lisp?
Полностью, начнём с того что схема не лисп вообще.
Но скобочки?
Emacs lisp - расширение Лиспа, а Scheme - не лисп, но похож.
Довольно серьёзно. Схема -- это вылизанный лисп, из которого выкинут весь этот исторический треш, типа символов, которые имеют имя, значение, функциональное значение и список свойств. Практически никто этим не пользуется, достаточно имени и значения, но elisp, и всякие там common lisp'ы продолжают насиловать стюардессу. Уже из этого одного отличия вытекает пачка синтаксических различий, типа вместо семейства defun/defvar/defparameter и тп в схеме есть только define.Но есть ещё одно отличие, схема вся на лексических биндах, оригинальный же лисп и его упёртые последователи никак не могут отделаться от динамических биндов. elisp особенно: у Столлмана был бзик по этому поводу; насколько я знаю, он не лечился, и думаю до сих пор страдает от него. Динамические бинды тормозные (их разрешать приходится в динамике, а не на этапе компиляции), они могут приводить к интересным проблемам, которые решаются через naming conventions, и глобалы имеют имена типа *глобальная-переменная*, или если константа то +глобальная-константа+. Такие соглашения, я думаю, решают все проблемы, типа того, что у тебя имя аргумента функции совпало с именем глобального символа (который может быть создан после того, как твоя функция скомпилировалась, он может быть создан в рантайме), и после этого твой код творит какую-то пургу и чтобы разобраться в этом надо реально быть бородатым лиспером. Но даже если эти проблемы уходят, всё ж неприятно иметь такую граблю под ногами. Ты в REPL решил что-то посчитать по-бырому, создал символ через defvar или даже через setq, и библиотечному коду сорвало крышу. В Common Lisp'е для этого есть неймспейсы, но elisp ущербен в этом отношении, глобальное пространство имён глобально.
Короче, они очень разнятся. Основные идеи одинаковы, но всё что не схема содержит в себе горы ненужного legacy из середины XX века, которое тогда казалось хорошей идеей, а со временем оказались отстоем. Зачем его сегодня лисперы держат мне не понятно, может чтобы чувствовать идейную связь с допотопными поколениями программистов? Только про Столлмана можно понять, зачем ему это, у него аутизм усугублённый синдромом вахтёра, поэтому он будет держаться того как было до последнего.
>Основные идеи одинаковы, но всё что не схема содержит в себе горы ненужного legacy из середины XX века, которое тогда казалось хорошей идеей, а со временем оказались отстоем.Я правильно понял, имелось ввиду "Elisp содержит в себе горы ненужного legacy из середины XX века", а не Scheme?
Оставьте Столмана, он передал бразды правление Емаксом ещё с какой-то 24 версии. И теперь за новым сопровождающим решения по необходимости модернизации Elisp, если сочтёт нужным.
> И теперь за новым сопровождающим решения по необходимости модернизации Elisp, если сочтёт нужным.Уже давно анрил. Вся конфигурация emacs'а делается через динамические бинды. Ты можешь открыть любой аддон к emacs'у и увидеть там сразу вначале грядку defconst и defvar.
>>Кроме языка Scheme, для которого реализована поддержка спецификаций R5RS, R6RS и R7RS, в рамках проекта Guile разработаны компиляторы и для других языков, таких как ECMAScript, Emacs Lisp и Lua
> А насколько разнятся Scheme и Emacs Lisp?Очень и очень сильно.
Emacs Lisp сильно тяготеет к Common Lisp. У него все переменные имеют динамическую область видимости. Лексическую в него добавили году эдак в 2018м, если мне память не изменяет. В Scheme -- всё изначально на лексической: если тебе вдруг нужна динамическая, надо указывать это явно. Это сильно улучшает безопасность кода, а также позволяет применять множество оптимизаций на этапе компиляции. И это ещё не затрагивая тему читаемости кода и "ушек" у символов.
Плюс к тому, схемы имеют систему модулей. Начиная с R6RS -- описанную в стандарте. Emacs Lisp же ничего подобного не имеет, что вкупе с динамической областью видимости отягощает разработчиков писать весьма длинные имена переменных: каждую с префиксом по имени модуля. Впрочем, это не большой косяк, многие языки этим страдают. Например, у Ansible -- всё точно так же, и никого это не смущает. Во всяком случае я в свои регламенты к написанию ролей для Ansible утянул этот подход именно из Emacs Lisp.
У Scheme общее пространство имён для всех символов, у Lisp-ов -- функции живут в отдельном пространстве. Это упрощает жизнь.
Впрочем, есть и ухудшения. Основная сила лиспов -- в макросах. Они позволяют менять синтаксис языка на лету. Схемы разработали свою систему "гигиенических макросов". Если ими пользоваться, то ты гарантировано получаешь корректный синтаксис. Однако читать их определения -- без поллитра не разберёшься. В CL и EL же -- классический топорный defmacro. Он позволяет разработчику выстрелить себе в ногу, но зато он понятный и удобный. Впрочем, многие схемы "не рекомендуют", но имеют defmacro тоже.
Словом, различия есть, и их много. Если вы выбираете себе лисп для изучения -- я рекомендую смотреть сначала на Racket Scheme, как на наиболее живого представителя схем. Emacs Lisp -- это если захотите глубоко работать с Emacs. На диалекты Common Lisp смотреть не рекомендую, разве что в целях расширения кругозора. CL в итоге стал пристанищем для социофобов (и на сии мысли меня навёл их код и их экосистема, ибо я честно написал магистерскую на SBCL), лучше бы их не беспокоить.
>У Scheme общее пространство имён для всех символов, у Lisp-ов -- функции живут в отдельном пространстве. Это упрощает жизнь.Так что упрощает: общее для всех или отдельное для функций?
>Если вы выбираете себе лисп для изучения -- я рекомендую смотреть сначала на Racket Scheme, как на наиболее живого представителя схем.
Я выбираю пакетный менеджер Guix, поэтому выбор очевиден :) Ну поглядываю в его сторону пока.
>> У Scheme общее пространство имён для всех символов, у Lisp-ов -- функции живут в отдельном пространстве. Это упрощает жизнь.
> Так что упрощает: общее для всех или отдельное для функций?Общее для всех. Проще говоря, внутри схемы просто одна большая таблица, которая связывает символы со значениями, а в CL -- их две. И таким образом вместо defvar и defun -- только define, а вместо #' и ' -- только '. Вот вроде бы мелочь, но хорошо, когда она не отвлекает.
>> Если вы выбираете себе лисп для изучения -- я рекомендую смотреть сначала на Racket Scheme, как на наиболее живого представителя схем.
> Я выбираю пакетный менеджер Guix, поэтому выбор очевиден :) Ну поглядываю в его сторону пока.Ваше право. Но осмелюсь заметить, что на Racket или Clojure вы работу найти сможете, а на Guile -- ну проблематично. Поэтому я Guile не могу рекомендовать.
> я рекомендую смотреть сначала на Racket Scheme, как на наиболее живого представителя схемНет такого языка -- Racket Scheme.
Есть просто Racket.
Который вырос из PLT Scheme.
И был переименован в Racket именно потому,
что в какой-то момент перестал быть схемой.
>> я рекомендую смотреть сначала на Racket Scheme, как на наиболее живого представителя схем
> Нет такого языка -- Racket Scheme.
> Есть просто Racket.
> Который вырос из PLT Scheme.
> И был переименован в Racket именно потому,
> что в какой-то момент перестал быть схемой.Да, Racket это не чистая Scheme. Но разница не сильно велика. Перейти с Racket на чистую Scheme в случае необходимости не составит большого труда.
> Добавлена поддержка упрощённого синтаксиса wisp, позволяющего писать более читаемый кодЕсли это более читаемый код, то я тогда мать Тереза.
Избыток скобочек засоряет взор индейца. Без скобок вариант читаемый легче (быстрее - с меньшей тратой внимания).
со скобками быстрее прочитать получилось
а мне понравилось, запомнить: 1) строки, которые начинаются с точки, оборачивать в скобки не надо, 2) двоеточие, наоборот - заключить в скобки, 3) новая строка и отступы - и так понятно
зато как итог, никакой тебе кучи смайликовпонятно, что это синтаксический сахар, без знакомства с традиционным синтаксисом лиспа вряд ли будет восприниматься
>зыком разработки расширений для операционной системы GNU.что это за ОС такая?
GNU is an operating system that is free software—that is, it respects users' freedom. The GNU operating system consists of GNU packages (programs specifically released by the GNU Project) as well as free software released by third parties. The development of GNU made it possible to use a computer without software that would trample your freedom....
GNU is a Unix-like operating system. That means it is a collection of many programs: applications, libraries, developer tools, even games. The development of GNU, started in January 1984, is known as the GNU Project. Many of the programs in GNU are released under the auspices of the GNU Project; those we call GNU packages.
GNU's own kernel, the GNU Hurd, was started in 1990 (before Linux was started). Volunteers continue developing the Hurd because it is an interesting technical project.
где скачать исошку?
на реальном железе работает?
Скорее всего, придётся всё самому собирать from scratch.
>где скачать исошку?На сайте GNU.
>на реальном железе работает?
Да, но оно 32-х битное, не 64 битное.