Пожалуйста, ответьте один за другим.
Если вы объясните, почему это не так, попробуйте избежать общих утверждений и предоставить конкретные примеры.
Пожалуйста, ответьте один за другим.
Если вы объясните, почему это не так, попробуйте избежать общих утверждений и предоставить конкретные примеры.
Что все круглые скобки делают код нечитаемым. Примерно через две недели и с достойным текстовым редактором вы просто перестанете их замечать.
[ETA - только что нашел цитату давнего лидера Кенни Тилтона: "Круглые скобки? Какие круглые скобки? Я не заметил никаких круглых скобок с моего первого месяца программирования Lisp. Мне нравится спрашивать людей, которые жалуются на круглые скобки в Lisp, если их беспокоят все пробелы между словами в газете..." ]
Lisp является интерпретированным языком и, следовательно, он очень медленный.
Посмотрите на функцию дизассемблировать в Common Lisp Hyper Spec.
Общая реализация Lisp под названием SBCL содержит эффективный внутренний компилятор для нескольких платформ.
Мое любимое заблуждение: это "функциональный язык", который препятствует итерации или ООП или любому типу программирования, который вы можете назвать.
Ничто не может быть дальше от истины.
Прежде всего, "Lisp", в зависимости от значения, намеченного говорящим, на самом деле не является языком вообще, кроме языковой семьи. Есть несколько более или менее известных и широко распространенных членов этого семейства: Scheme, Общие Lisp, Emacs- Lisp и AutoLisp являются традиционными; в настоящее время существует также Nu, newLISP (что на самом деле больше напоминает "oldLISP", чем современный), Arc и Clojure.
Конечно, верно, что Schemers, похоже, предпочитают функциональный стиль и препятствуют итерации в пользу рекурсии. Однако, насколько я могу судить, Schemers на самом деле являются меньшинством в мире Lisp, по крайней мере, при рассмотрении практического использования Lisp в качестве инструмента программирования, в отличие от предмета исследования или исследования.
Я не знаю много о AutoLisp или всех других диалектах Lisp рядом с Scheme и Common Lisp, но я знаю, что Common Lisp определенно не является языком одной парадигмы, который избегает императивных или даже объектно-ориентированного программирования. Фактически, Common Lisp содержит самую мощную объектную систему на основе классов, о которой я знаю, включая ядро, основанное на аспектах.
Lisp кажется мне действительно языковой семьей, которая больше всего поощряет эксперименты в новых направлениях и с большей легкостью включает в себя парадигмы программирования, которые не поддерживаются с помощью get-go. Это включает в себя обязательное программирование. Общий Lisp даже получил GOTO!
Что он для искусственного интеллекта
Я не знаю о любимом заблуждении... но я часто вижу, что программисты говорят о "LISP" и почему им это не нравится/не подходит/академично/он никогда не будет работать для проекта X. Что было бы хорошо, если бы они сказали "LISP" они означают "Схема", в которой они действительно означают "подмножество Схемы", в котором они действительно означают "наполовину запоминающееся подмножество Схемы из этого ИИ или языковой курс 5 лет назад, что им не понравилось".
Похоже, что с этого направления существует довольно много иррациональных предрассудков против Lisp (s). Рациональные предрассудки - это нечто иное.
многие считают, что lisp - это список-ориентированный язык (что бы это ни значило).
широко распространенное мнение даже среди осечек о том, что одна великая и самая важная вещь в lisp - это ячейка cons и отдельные списки, которые можно создать с помощью них (sexp's). люди, которые считают, что не понимают реальных причин, которые делают lisp более продуктивным языком, чем другие основные языки (это только мое субъективное мнение!), и не понимаю, что lisp может быть в значительной степени тем, чем он без наличия в игре минусовки.
случайный выбор вещей, которые важны для того, чтобы сделать lisp тем, что он есть, и которые легко выполнимы без sexp:
несколько пояснений:
просто введите, динамическое типирование означает, что не имеют тип места, а значения времени выполнения. это важная помощь, если вы не знаете заранее все свои требования, и ваше приложение постоянно трансформируется по мере развития проекта. по моему опыту, это, безусловно, в большинстве случаев - только с гораздо большим количеством препятствий, когда статическая печать на картинке.
возможно, многие утверждают, что cons-cell и sexp имеют решающее значение для гибкой макросистемы. решающее значение имеет простой синтаксис и простое управление структурой данных, в которую он разбирается. синтаксис sexp и списки вместе являются хорошим кандидатом, но есть много других.
Я доволен Parens, но я не доволен другой частью, а именно, используя cons'd-списки для представления программного кода, потому что у него есть важный недостаток: вы не можете аннотировать его случайным материалом без нарушая данные, которые уже представлены с ним. например я не могу комментировать такой список cons, представляющий программный код, с тем фактом, что он был отредактирован Джо два дня назад, не превращая эту форму в бессмыслицу для компилятора lisp. эти аннотации становятся все более важными, поскольку ваш DSL становится более сложным, и поскольку ваши макросы превращаются в небольшие компиляторы, компилирующие ваш DSL в lisp.
Мое избранное lisp заблуждение: CL действительно означает CthuLhu!
Шутки в сторону; безусловно, наиболее распространенное заблуждение относительно всех видов диалектов lisp заключается в том, что синтаксис s-выражений, основанный на скобках, наносит вред читабельности, когда на самом деле именно эта особенность помогает сделать код lisp намного более кратким, понятным и читабельны, чем большинство других языков программирования.
У меня нет "любимого" заблуждения, потому что большинство заблуждений, а не только Lisp, просто раздражает. Но у меня есть одно неправильное представление о Lisp, которое действительно шокировало меня, когда я читал историю Lisp (в частности История Lisp и Эволюция Lisp).
Lisp, как известно, является медленным интерпретируемым языком многих моих людей, но на самом деле у него был компилятор примерно через год после первого рабочего интерпретатора, я думаю, и следующая история - длинный список работа, нацеленная на оптимизацию, которая привела к некоторым реализациям Lisp, избивающим Fortran при измельчении числа!
Наиболее вероятным источником мифа является то, что многие люди узнают только Lisp из курса CS о Схеме, где они пишут себе переводчика. И, вероятно, многие из них ненавидят этот курс, потому что он учит их красивым, но сложным концепциям вычислимости или рекурсии, и затем они ассимилируют свои проблемы с курсом своими проблемами с помощью Lisp.
"Вселенная написана в Lisp". Но видимо, это не.
Все в Lisp - это список, нет других эффективных сложных структур данных.
Не верно. В Common Lisp существуют классы, структуры, хеш-таблицы, многомерные массивы, изменяемые строки и т.д. Каждый из них реализуется эффективно. Например, компилятор SBCL испускает оптимизированный встроенный собственный код для доступа к массиву.
Lisp не может предоставлять автономные исполняемые файлы.
Используя SBCL, вы можете сохранить текущее состояние вашей lisp VM в один исполняемый файл с помощью простого вызова . Когда вы запустите этот исполняемый файл, он начнется с исходного состояния и вызовет функцию или лямбда, которые вы предоставили, когда она была сохранена.
Lisp не имеет IDE, поэтому вы должны использовать блокнот и непрерывно подсчитывать все лишние скобки.
На самом деле их довольно много. Для Common Lisp лучше использовать Emacs с SLIME как под окнами, так и с linux. Он предоставляет слушателю (для оценки), инспектор (для просмотра результатов), отладчик (с степпингом), очень настраиваемый редактор (в конце концов это Emacs). SLIME поддерживает 10 различных реализаций.
Это язык программирования. Сегодня Lisp - это семейство языков программирования, включая Общие Lisp и Scheme, которые являются стандартами с различными реализациями каждый, а также Clojure, Arc и многие другие.
Это "CLOS" - это язык программирования, а Lisp - интерпретируемый, функционально-единственный язык. Действительно, я слышал это от профессоров CS. И я думаю, что в одной из этих книг по программированию на языке программирования была какая-то вводящая в заблуждение диаграмма, которая предположила, что.
Сегодня преподаватели CS в колледжах и университетах (особенно молодые) получили образование на Java, C и С++, и они, вероятно, изучили либо схему, либо общую Lisp в курсе под названием "сравнительные исследования языка программирования" или "программирование" парадигмы ", который, вероятно, преподавал кто-то, кто не любит какой-либо язык Lisp, и научил их функциям, спискам, символам и функциям более высокого порядка. Период. Затем они заканчивают тем, чему научились:Я даже видел очень умного профессора, дающего пример матричного умножения в Common Lisp - представляя матрицы как списки, конечно!
Чтобы люди решали жесткие проблемы с помощью Lisp, сам язык должен быть сложным.
Рекурсия жесткая. Неподвижные точки функций сложны. Но они едва охватывают главу 1 Структура и интерпретация компьютерных программ. Это не потому, что Scheme сложно - на самом деле, потому что это так просто, тяжелый материал - это все, что осталось сделать!
Люди обвиняют lisp в скобках. Я бы хотел, чтобы они сказали, как они будут реализовывать ориентированный на список массивы язык без них...
Любое достаточно продвинутое приложение неотличимо от линейного шума.