05.12.2021

Выпуск GNU Mes 0.23, инструментария для самодостаточной сборки дистрибутивов

 
  • 2.5, Ordu (ok), 10:08, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Схема — это попса ж чистой воды. Common Lisp для настоящих мужиков. Для фанатов Столламана есть elisp. А схема — это попытка функционализировать Lisp, лишающая его всей его прелести. На схеме аж целый SICP запилен, и целое поколение личинок программистов в MIT училось по нему. Как раз то самое поколение, которое сегодня с радостью забросило C в пользу rust’а и go.
     
     
  • 3.9, user90 (?), 10:14, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это уже частности, а так-то Lisp был попсой лет 50 назад ;) Речь о том, что не петон и пр.

    > Для фанатов Столламана есть elisp

    Для юзеров Emacs ты хотел сказать. Спасибо, знаю, написал на нем дочерта (для себя).

     
     
  • 4.13, Ordu (ok), 10:32, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Для юзеров Emacs ты хотел сказать.

    Нет, я хотел сказать то, что сказал: для фанатов Столлмана. Столлман принципиальный противник Common Lisp’а, и некоторые фишки и соглашения Common Lisp’а он из вредности не включает в elisp. Например, &key аргументы. Столлман считает, что это лишнее, и что вместо этого надо пользоваться лексическими биндами. То есть, грубо говоря, вместо

    (buffer-name :buffer some-buffer)

    по Столлману надо писать:

    (let ((current-buffer some-buffer))

        (buffer-name))

    Это не реалистичный пример, потому как реально функция buffer-name всё ж принимает аргумент-буфер, но как &optional аргумент, а current-buffer вовсе не глобальная переменная, а функция, но суть разногласий Столлмана с именованными аргументами передаёт.

    Помимо этого в Common Lisp есть CLOS, с его defclass и дженериками, то есть там где elisp реализует тип buffer на C, как встроенный тип, в Common Lisp’е возможно было бы сделать ровно то же самое, не вылезая из lisp’а, да ещё и таким образом, чтобы строковые функции работали бы и на буферах тоже. В elisp при большом желании тоже можно, но лишь при большом желании, и придётся переизобретать CLOS, по-крайней мере частично.

    Common Lisp стандартизован, а значит программы на Common Lisp можно гонять в разных реализациях Common Lisp’а с минимальными изменениями. elisp же — это столлмановский вендорлок, который прибил emacs к говнолиспу, уйти с которого теперь не представляется возможным. Все попытки так и закончились ничем.

    Настоящие мужики, предпочитающие Common Lisp, таскают с собой elisp’овый пакет, который некоторые фишки Common Lisp’а привносит в elisp.

     
  • 2.12, Последний из могикан (?), 10:29, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это потому что это нишевый продукт.При превышении определённого количества пользователей приползают,как слизни,как пиявки,вожделея крови,корпорации,и сначала поглощают,а затем и уничтожают продукт.Живой пример этого-Мозилла.Посмотрите во что она превратилась.
     

  • 1.3, ыы (?), 10:01, 15/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >может быть преобразован в исполняемый файл с использованием

    …скрытых закладок в любом из компонент.

     
     
     
  • 3.8, Qwerty (??), 10:09, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, у человека на слово «исполняемый» сработал триггер и запустил протокол Hysteric Squirrel.
     

  • 1.7, InuYasha (??), 10:09, 15/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Scheme -> MesCC -> TinyCC -> GCC -> Linux

    Это интересно, конечно. А насколько хорошо у TinyCC с оптимизациями? Не получится ли что скомпилированный им GCC будет тормозным?
     
     
  • 2.11, a (??), 10:25, 15/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, в приведённой вами последовательности скорее всего будет именно так, как вы предположили.

    Во-вторых:

    …-> TinyCC -> GCC -> GCC -> Linux
     

    Источник.