Ну да, Bioreactor и зеркала Лурка приписывают это высказывание ПроФФесору. Проверить это затруднительно, поскольку sql.ru, на который ссылаются, прекратил существование.
Теоретически, да. Использовать что-то вроде сегментной модели памяти. И сегмент определять текущей функцией. Тогда компилятор лиспа будет тривиален, а в компиляторе Си придётся хранить указатели в замыканиях.
А чем мешает одно другому? В CL и C++ эти два стиля тоже хорошо уживаются.
Про CL не скажу точно, но тот код, который я видел, функциональщиной даже не пах.
В C++ функциональщину тоже мало использует. Нет, передача лямбды или std::function аргументом – это не функциональный стиль. В противном случае можно сказать, что ведро лялекса написано в функциональном стиле, ведь там половина структур содержат указатели на функции.
Для плюсов есть отдельные библиотеки типа ftl, но это чисто поржать. Если ты хочешь увидеть дичайшую смесь ФП и ООП, полную чада кутежа и угара, посмотри как на Scala пишут. Там половина чуваков пишут на этакой мегаджаве (особенно до выхода Kotlin было популярно так делать), а вторая – на недохачкеле. В итоге на проект на скалке возрастом больше пары лет без крови из глаз не посмотришь.
Чтобы уравнять их возможности к одному, предсказуемому уровню, на который можно опираться в долгосрочной стратегии. Не гадать, как быстро проект сделают в зависимости от квалификации разрабов, а прикидывать примерно наверняка. Бизнесу так намного спокойнее планы строить./imho
Неправда. Правдой было бы «в C++ такие же лямбды по сравнению с лисповыми, как макросы C по сравнению с лисповыми». В JS,go лямбды не хуже. А в Python, я бы сказал, в чём-то даже лучше, т.к. не позволяют менять значения захваченных переменных - минимально добавляют лямбдам вменяемости.
ну и кстати defmethod вообще к ФП отношения не имеет, да
Не, это речь про смесь ООП и ФП в коде. Есть ли опенсорсные проекты на CL, написанные в функциональном стиле на полную катушку? Я не видел. Как минимум, лишпу не хватает иммутабельности для этого.
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), а приток масс в разработку неизбежно роняет общий уровень квалификации.
Видел. На Си++ можно написать кандидатскую на тему «как правильно сделать класс, чтобы его можно было использовать в условии».
А код того boost’а не то что писать, его читать больно.
А на лиспе легко писать «как на руби» (пакет на 200 строк с ООП на сообщениях), «как на питоне» (пакет на 200 строк и вместо скобок отступы), …
В результате чуть ли не каждый изучающий лисп вместо того, чтобы досконально его изучить и писать как принято, как сделал lovesan, дописывает то, чего, по его мнению, здесь не хватает (так как он так привык). И плодятся парадигмы ООП, синтаксические расширения, типизаторы, … Но всё в рамках одной VM. И получается примерно такая же картина, как на JVM, но с поправкой на то, что компилятор в JVM всё-таки нетривиален, а новый ни-на-что-непохожий синтаксис для лиспа пилится за неделю.
С одной стороны, наличие правил и ограждений уменьшает количество дичи в коде и на дорогах; но чтобы от правил была польза, нужно, чтобы их соблюдали.
контроль за соблюдением правил возложен на компилятор, и попробуй не соблюсти хоть одно из них.
я вот на с++ пишу на расслабоне. если правильно делать классы, компоненты и прочее, с нужными интерфейсами и ограничениями, весь последующий код уже практически невозможно написать с багами. вытаскиваешь автокомплитом нужный метод, подставляешь нужные параметры, и можно не напрягаться вообще.
В Lisp один тип для namespace - symbols.
Терминология что ввели профессоры Scheme, абстрактная. Наверно это облегчило им работу, вот есть переменные, вот есть функции.
Lisp это symbols.
В Racket есть модули. В отличие от пакетов, они позволяют давать префиксам короткие имена. И гарантируют, что компиляция одного модуля не ломает другой модуль. Для лиспа есть XCVB, но для настоящих лисперов это «дичь» и потому не прижилось.
Там много вещей явно не для лабораторных работ: модули (в том числе параметризуемые), контракты (что позволяет очень быстро локализовать ошибку до модуля), хранители ресурсов (что позволяет писать долго работающие серверные приложения с гарантией от утечки файловых дескрипторов или соединений).
Нет, symbol и есть значение.
В Lisp о символе представление как о стандартной «C» структуре.
В Scheme это скрыли для студентов и возникли проблемы с пониманием Lisp macros.