Ответы для темы «Почему Go это плохо....»

В общем-то, да, похоже на злоупотребление.

Ну да, Bioreactor и зеркала Лурка приписывают это высказывание ПроФФесору. Проверить это затруднительно, поскольку sql.ru, на который ссылаются, прекратил существование.

Ладно. Убедил. Я давно SICP читал.

Теоретически, да. Использовать что-то вроде сегментной модели памяти. И сегмент определять текущей функцией. Тогда компилятор лиспа будет тривиален, а в компиляторе Си придётся хранить указатели в замыканиях.

Они клепают лисп без скобок. Rhombus называется.

Так Racket и есть хаскель со скобками и макросами. Идеология написания программ вообще совпадает.

Это именно базовые элементы мышления.

А можно эту мысль как-то развернуть. Привести примеры, скажем на emacs lisp, так как это есть у всех. Можно взять, как пример идеи вот этот код

(defun f-F-a (lst1 lst2)
  (if (or (null lst1) (null lst2))
      ""
    (let ((current (format "%s * %s" (car lst1) (car lst2)))
          (rest (f-F-a (cdr lst1) (cdr lst2))))
      (print (list 'current current))   ; печать текущего значения
      (print (list 'rest rest))         ; печать остатка
      (if (string-empty-p rest)
          current
        (format "%s %s" current rest)))))

(print (f-F-a '("- F1" "+ F2" "- F3")  '("a1" "a2" "a3")))

Не могу преобразовать string (комментарий)

Остаётся надеятся, что это многим будет интересно.

emacs lisp … есть у всех

Пока ещё нет, к сожалению. Но мы работаем над этим.

А чем мешает одно другому? В CL и C++ эти два стиля тоже хорошо уживаются.

Про CL не скажу точно, но тот код, который я видел, функциональщиной даже не пах.

В C++ функциональщину тоже мало использует. Нет, передача лямбды или std::function аргументом – это не функциональный стиль. В противном случае можно сказать, что ведро лялекса написано в функциональном стиле, ведь там половина структур содержат указатели на функции.

Для плюсов есть отдельные библиотеки типа ftl, но это чисто поржать. Если ты хочешь увидеть дичайшую смесь ФП и ООП, полную чада кутежа и угара, посмотри как на Scala пишут. Там половина чуваков пишут на этакой мегаджаве (особенно до выхода Kotlin было популярно так делать), а вторая – на недохачкеле. В итоге на проект на скалке возрастом больше пары лет без крови из глаз не посмотришь.

Чтобы уравнять их возможности к одному, предсказуемому уровню, на который можно опираться в долгосрочной стратегии. Не гадать, как быстро проект сделают в зависимости от квалификации разрабов, а прикидывать примерно наверняка. Бизнесу так намного спокойнее планы строить./imho

Вообще говоря, после долгой практики разработки на плюсах, в другие ЯП и в разработку на них как-то сходу влетаешь.

После кактуса нормальную человеческую еду глотать тоже приятнее, не поспоришь.

Про CL не скажу точно, но тот код, который я видел, функциональщиной даже не пах.

Практически во всех библиотеках рядом defmethod и mapcar.

Ну возьмём этот пример. Здесь рекурсивный обход двух списков. В языках с итераторами ты бы делал цикл с параллельным обходом типа

for(auto i1 = lst1.begin(), i2 = lst2.begin(); i1 < lst1.end() && i2 < lst2.end(); i1++, i2++) ...

В языках с ООП у тебя нет car, который специально для списков, а был бы единый код для обхода любой последовательности.

В языках с сопоставлением по шаблону ты бы вместо этой функции написал три её частных варианта

f _ [] = ""
f [] _ = ""
f (h1:r1) (h2:r2) = ...

В языках с состоянием типа Форт вместо локальных переменных current и rest у тебя был бы стек.

Неправда. Правдой было бы «в C++ такие же лямбды по сравнению с лисповыми, как макросы C по сравнению с лисповыми». В JS,go лямбды не хуже. А в Python, я бы сказал, в чём-то даже лучше, т.к. не позволяют менять значения захваченных переменных - минимально добавляют лямбдам вменяемости.

Про CL не скажу точно, но тот код, который я видел, функциональщиной даже не пах.

Практически во всех библиотеках рядом defmethod и mapcar.

mapcar – это конечно лютая функциональщина, да. Ты бы ещё foreach какой-нибудь приплёл.

ну и кстати defmethod вообще к ФП отношения не имеет, да

ну и кстати defmethod вообще к ФП отношения не имеет, да

Не, это речь про смесь ООП и ФП в коде. Есть ли опенсорсные проекты на CL, написанные в функциональном стиле на полную катушку? Я не видел. Как минимум, лишпу не хватает иммутабельности для этого.

lovesan, однозначно профи в Лисп и весьма полезны были бы треды от него типа «Почему Лисп это хорошо и как его использовать».

CL не поощряет программирование в функциональном стиле. Там даже всякие with-* сделаны макросами, а не функциями с функциональным аргументом. И оптимизация хвостовых вызовов не гарантирована стандартом.

На Racket такие есть. Даже Hackett есть с монадами и классами типов.

Да. Всё мною сказанное относится к языкам без сборщика мусора.

Вы уже приступили к погружению в Соммоп Лишр, как собирались?

Пока нет, да и интересует не сам Лисп, а native архитектура работы с объектами в run-time.

lovesan хвалю потому, что его треды о разработке, а не «балабольство».
Может быть многие и не согласны с его суждениями, но хорошо то, что профи делится своим опытом разработки.

Кстати, согласен.

Его мнение ещё ценно тем, что, в отличие от многих других лисперов (меня, den73, авторов hu.dwim.*, François-René Rideau, …), он не пытается сделать из Common Lisp другой язык, а использует именно стандартную библиотеку и её подходы.

Не знаю какие вы там лисперы, вот den73 походу вообще кодер на delphi.

Я не пишу «как в стандартной библиотеке», я пишу так как принято в CL. Мой код это нормальный код на CL. Стандарты написания кода на CL родились не вчера, и даже наверное не в 80х(т.к. были всякие maclisp/spicelisp/etc), и эти стандарты используются всеми нормальными людьми.

А то что вон перечисленные делают - это пишут хероту какую-то, не знаю от больной головы наверное. Потому что у них в свое время какой-нибудь BASIC/Delphi/C++/Haskell вызвал Brain Damage, неизлечимое.

Да, CL позволяет писать дичь, но вообще говоря это позволяет любой язык - и то что делают те люди это примерно как если бы в Си - писали бы не как пишут на Си, а создавали бы массивы, туда херачили байты, и кастовали к указателю на функцию и выполняли это. Ну типа, а херли - можно ведь?

Беда в том, что если из множества лисперов убрать всех, кто пишет хероту, то останется десяток человек. На ЛОР я кроме тебя вообще ни одного не знаю.

Поэтому твои статьи о Лиспе наиболее ценные.

Проблема Лиспа в том, что он позволяет удобно писать дичь. В результате, достаточно много народу пишет не на Лиспе, а на своëм уникальном языке на виртуальной машине Лиспа.

Из других языков такое свойство разве что у Форта есть.

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

вот и вопрос - где дичи будет больше?

вопрос - где дичи будет больше

Дичи будет в среднем больше там, где квалификация писателя ниже. А будет дичь строго типизированной или нет — какая разница?

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

у авторов примерно равной «квалификации». «примерно равной» потому, что у квалификации нет метрики.

Как будто у дичи она есть.

Можно взять одного и того же автора и попросить его написать одно и то же на разных языках. Его квалификация при написании отдельных образцов будет примерно одинаковой.

Правда, он может владеть разными языками по-разному, и это тоже будет влиять на уровень дичи. Опять не складываются замеры, что ты будешь делать.

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

это все равно что утверждать, что езда без ПДД и всей инфраструктуры, навроде светофоров, разметок, развязок, шлагбаумов и прочего… не дает никакого эффекта в плане безопасности и пропускной способности дорожного движения???

смело!

Проблема Лиспа в том, что он позволяет удобно писать дичь. В результате, достаточно много народу пишет не на Лиспе, а на своëм уникальном языке на виртуальной машине Лиспа.

Из других языков такое свойство разве что у Форта есть.

Ты C++ вообще видел? Там бесконечное количество вариантов, начиная от «Си-с-классами» и заканчивая «недохачкеллом-на-темплейтах». Иногда даже в одном проекте.

намекаете, что проверка компилятором инвариантов, ограничений, правил … не дает никакого результата, ни в разработке, ни финальной корректности изделия?

что езда без ПДД и всей инфраструктуры … не дает никакого эффекта в плане безопасности и пропускной способности

Да хрен его знает. Без метрик и замеров остаётся только предполагать наличие разных причинно-следственных связей, которые могут работать в противоположные стороны и эффекты которых мы не можем оценить количественно. (Вот это интересная область для исследования, как по мне — построение причинно-следственных моделей и количественная оценка эффектов связей.)

С одной стороны, наличие правил и ограждений уменьшает количество дичи в коде и на дорогах; но чтобы от правил была польза, нужно, чтобы их соблюдали. С кодом нарушение некоторых правил можно сделать невозможным физически — но не стоит недооценивать человеческую изобретательность.

С другой стороны, недостаток квалификации вынуждает выдумывать невероятные решения для давно решённых элементарных проблем и тащить куски кода отовсюду, чтобы как попало слепить минимально работающего франкенштейна. Количество дичи в таких решениях можешь сам представить.

В общем, кто кого сборет — слон или кит? Ответов нет, только предположения. И правила вроде бы нужны, и квалифицированные разработчики; но реальность такова, что ограничения не всегда работают как задумано (вспомним жабьи checked exceptions), а приток масс в разработку неизбежно роняет общий уровень квалификации.

И с этим нужно как-то учиться жыть.

Два крайних контрпримера:

1. Питон, где дичь (не идиоматический код) крайне редок

2. C++, где есть Александреску и boost.

Видел. На Си++ можно написать кандидатскую на тему «как правильно сделать класс, чтобы его можно было использовать в условии».

А код того boost’а не то что писать, его читать больно.

А на лиспе легко писать «как на руби» (пакет на 200 строк с ООП на сообщениях), «как на питоне» (пакет на 200 строк и вместо скобок отступы), …

В результате чуть ли не каждый изучающий лисп вместо того, чтобы досконально его изучить и писать как принято, как сделал lovesan, дописывает то, чего, по его мнению, здесь не хватает (так как он так привык). И плодятся парадигмы ООП, синтаксические расширения, типизаторы, … Но всё в рамках одной VM. И получается примерно такая же картина, как на JVM, но с поправкой на то, что компилятор в JVM всё-таки нетривиален, а новый ни-на-что-непохожий синтаксис для лиспа пилится за неделю.

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

говорят стандарт камонлиспа занимает 5000 страниц. даже больше чем стандарт с++(впрочем я не читал ни то, ни это)…

да прочитав 5000 страниц досконально, можно освоить любую профессию на планете.

сомнительно, что лавсан читал более 200 из них. :0)

С одной стороны, наличие правил и ограждений уменьшает количество дичи в коде и на дорогах; но чтобы от правил была польза, нужно, чтобы их соблюдали.

контроль за соблюдением правил возложен на компилятор, и попробуй не соблюсти хоть одно из них.

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

и можно не напрягаться вообще

Правильно, силы нужно поберечь для ЛОР!

C++, где есть Александреску

Он что, вернулся на C++ с D?

Он что, вернулся на C++ с D?

Ну ладно, был. Я к тому, что C++ привлекает людей, любящих программные извращения.

https://en.wikipedia.org/wiki/Common_Lisp#The_function_namespace

В Lisp один тип для namespace - symbols.
Терминология что ввели профессоры Scheme, абстрактная. Наверно это облегчило им работу, вот есть переменные, вот есть функции.
Lisp это symbols.

Racket родился как учебный, но нынче полнофункциональный язык общего назначения.

Racket только учебный. Но когда увидели что получилось, решили просто перевести курс на Python.

говорят стандарт камонлиспа занимает 5000 страниц. даже больше чем стандарт с++(впрочем я не читал ни то, ни это)…

Нет. Всего 680. http://quimby.gnus.org/circus/cl/ansi-cl.tar.gz

да прочитав 5000 страниц досконально, можно освоить любую профессию на планете.

Школьные учебники за один год примерно 2000 страниц.

Терминология что ввели профессоры Scheme, абстрактная. Наверно это облегчило им работу, вот есть переменные, вот есть функции.

???

Так переменные и функции в разных пространствах имён не в Scheme, а в Common Lisp.

В Lisp есть только пространство для symbols.(и в Scheme тоже)
Разные «пространства имён» в Lisp это packages, которых в Scheme нет или не было.

Racket только учебный.

Зачем учебному языку полноценный web-сервер, LDAP, ZeroMQ и клиент к Apache Kafka?

Racket такой же учебный как Pascal.

В Lisp есть только пространство для symbols.(и в Scheme тоже)

Вот у символа cons два значения:

(setf cons 1)
(cons cons #'cons) ; будет (1 . #<SYSTEM-FUNCTION CONS>)

которых в Scheme нет или не было

В Racket есть модули. В отличие от пакетов, они позволяют давать префиксам короткие имена. И гарантируют, что компиляция одного модуля не ломает другой модуль. Для лиспа есть XCVB, но для настоящих лисперов это «дичь» и потому не прижилось.

Зачем учебному языку полноценный web-сервер, LDAP, ZeroMQ и клиент к Apache Kafka?

Может лабораторные работы аспирантов. Это не значит что это хуже или не лучше чем другое. Но сам язык какой-то неуместный.

Но сам язык какой-то неуместный.

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

Вот у символа cons два значения

Нет, symbol и есть значение.
В Lisp о символе представление как о стандартной «C» структуре.
В Scheme это скрыли для студентов и возникли проблемы с пониманием Lisp macros.