Каково Ваше любимое неправильное представление о Lisp? [закрытый]
Размер структуры больше, чем сумма ее частей из-за того, что называется упаковкой. У конкретного процессора есть предпочтительный размер данных, с которым он работает. Большинство современных процессоров предпочитают размер, если 32 бит (4 байта). Доступ к памяти, когда данные находятся на этом типе границы, более эффективен, чем те, которые охватывают эту границу размера.
Например. Рассмотрим простую структуру:
struct myStruct
{
int a;
char b;
int c;
} data;
Если машина является 32-разрядной машиной, а данные выровнены по 32-битной границе, мы видим немедленную проблему (при отсутствии выравнивания структуры). В этом примере предположим, что данные структуры начинаются с адреса 1024 (0x400 - обратите внимание, что младшие 2 бита равны нулю, поэтому данные выравниваются с 32-разрядной границей). Доступ к data.a будет работать нормально, потому что он начинается на границе - 0x400. Доступ к data.b также будет работать нормально, поскольку он находится по адресу 0x404 - еще одна 32-разрядная граница. Но неуравновешенная структура поставит data.c по адресу 0x405. 4 байта данных.c находятся в 0x405, 0x406, 0x407, 0x408. На 32-битной машине система считывала data.c в течение одного цикла памяти, но получала бы только 3 из 4 байтов (четвертый байт находится на следующей границе). Таким образом, системе потребуется второй доступ к памяти для получения 4-го байта,
Теперь, если вместо того, чтобы поместить data.c по адресу 0x405, компилятор заполнил структуру на 3 байта и поместил данные. c по адресу 0x408, тогда системе потребуется всего 1 цикл, чтобы прочитать данные, сократив время доступа к этому элементу данных на 50%. Заполняет эффективность памяти для эффективности обработки. Учитывая, что компьютеры могут иметь огромные объемы памяти (много гигабайт), компиляторы считают, что своп (скорость над размером) является разумным.
К сожалению, эта проблема становится убийцей при попытке отправить структуры по сети или даже записать двоичные данные в двоичный файл. Прокладка, вставленная между элементами структуры или класса, может нарушить данные, отправленные в файл или сеть. Чтобы написать переносимый код (тот, который будет использоваться для нескольких разных компиляторов), вам, вероятно, придется обращаться к каждому элементу структуры отдельно, чтобы обеспечить надлежащую «упаковку».
С другой стороны, разные компиляторы имеют разные возможности для управления упаковкой структуры данных. Например, в Visual C / C ++ компилятор поддерживает команду #pragma pack. Это позволит вам настроить упаковку и выравнивание данных.
Например:
#pragma pack 1
struct MyStruct
{
int a;
char b;
int c;
short d;
} myData;
I = sizeof(myData);
Теперь я должен иметь длину 11. Без прагмы я мог бы быть чем угодно из 11 до 14 (а для некоторых систем - до 32), в зависимости от стандартной упаковки компилятора.
17 ответов
Это все круглые скобки делает код нечитабельным. Приблизительно после двух недель, и с достойным текстовым редактором, Вы просто прекращаете замечать их.
[ETA - просто нашел кавычку давним lisper Kenny Tilton: "Круглые скобки? Какие круглые скобки? Я не заметил круглых скобок со своего первого месяца программирования Lisp. Мне нравится спрашивать людей, которые жалуются на круглые скобки в Lisp, если они побеспокоены всеми пробелами между словами в газете..."]
Любое достаточно усовершенствованное приложение неотличимо от шума в линии.
Люди обвиняют шепелявость в круглой скобке. Я хотел бы, чтобы они сказали, как они реализуют ориентированный язык массива списка без них...
Lisp не имеет никакого IDE, таким образом, необходимо использовать блокнот и непрерывно считать всю лишнюю круглую скобку.
На самом деле существуют довольно многие. Для языка Common LISP, лучше использовать Emacs со СЛИЗЬЮ и под окнами и под Linux. Это обеспечивает Слушателя (для оценки), Инспектор (для наблюдения результатов), Отладчик (с продвижением), высоконастраиваемый Редактор (это - Emacs, в конце концов). СЛИЗЬ поддерживает 10 различные реализации.
То, что это - язык программирования. Сегодня Lisp является семейством языков программирования включая язык Common LISP и Схему, которые являются стандартами с различными реализациями каждый, и также Clojure, Дуга и многие другие.
Мое любимое неправильное представление шепелявости: CL действительно означает CthuLhu!
Шутки в стороне; безусловно самое широко распространенное неправильное представление относительно всего способа диалектов шепелявости, то, что уверенность синтаксиса s-выражений в круглой скобке вредит удобочитаемости, когда на самом деле это - эта самая черта, которая помогает сделать код шепелявости намного более кратким, ясным и читаемым, чем большинство других языков программирования.
Lisp не может обеспечить автономные исполняемые файлы.
Используя SBCL, можно сохранить текущее состояние шепелявости VM в единственный исполняемый файл с простым вызовом функции. При запуске этого исполняемого файла он начнет с исходного состояния и вызовет функцию или лямбду, которую Вы обеспечили, когда он был сохранен.
Все в Lisp - список, нет никаких других эффективных сложных структур данных.
Не верно. В языке Common LISP существуют классы, структуры, хеш-таблицы, многомерные массивы, изменяемые строки, и т.д. Каждый из тех реализован эффективно. Например, компилятор SBCL испускает оптимизированный встроенный собственный код для доступа к массиву.
У меня нет "любимого" неправильного представления, потому что большинство неправильных представлений, и не только о Lisp, является просто раздражениями. Но и у меня есть одно неправильное представление о Lisp, который действительно потряс меня, когда я прочитал историю Lisp (конкретно История Lisp и Эволюция Lisp).
Lisp, как известно, является медленным интерпретируемым языком мои многие люди, но в действительности он имел компилятор что-то о меньше чем одном годе после наличия его первого рабочего интерпретатора, я думаю, и следующая история является длинным списком работы, предназначенной для оптимизации, которая привела к некоторым реализациям Lisp, бьющим Фортран в сокрушительном числе!
Самый вероятный источник мифа - то, что многие люди добираются только для знания Lisp от курса CS о Схеме, где они пишут себе интерпретатор. И вероятно многие из них добираются для ненависти курса, потому что он преподает им красивые но сложные понятия исчисляемости или рекурсии, и они затем ассимилируют свои проблемы с курсом с их проблемами с Lisp.
многие думают, что шепелявость является списковым языком (независимо от того, что это означает).
это - широко распространенное мнение, даже среди lispers, что одной большой и самой важной вещью о шепелявости является ячейка недостатков и отдельно связанные списки, что можно создать использование их (sexp's). люди, которые верят этому, не понимают настоящих причин, которые делают шепелявость более продуктивным языком, чем другие основные языки (это - только мое субъективное мнение!), и не понимают, что шепелявость могла в значительной степени быть тем, что это, не имея ячейки недостатков в игре вообще.
случайный выбор вещей, которые важны для создания шепелявости, что это, и которая является легко выполнимой без sexp's:
- REPL
- компилятор, доступный во времени выполнения
- динамический контроль типов
- синтаксические абстракции (макросы)
- закрытия
- простой синтаксис, который легко отредактировать (и "проанализировать" мозгом)
несколько объяснений:
проще говоря, динамический контроль типов означает, что не места имеют тип, но значения во время выполнения. это - важная справка, если Вы не знаете заранее всех своих требований, и Ваше приложение постоянно преобразовывает, поскольку проект развивается. на основе моего опыта это - безусловно большая часть случая - только с намного большим количеством препятствий, когда статический контроль типов находится в изображении.
вероятно, многие утверждали бы, что ячейка недостатков и sexp's крайне важна для гибкой макро-системы. решающей вещью является простой синтаксис и простое для управления структурой данных, в которую она анализируется. sexp синтаксис и списки вместе являются хорошим кандидатом, но существуют многие другие.
я доволен parens, но я не доволен другой частью, а именно, с помощью cons'd списки для представления кода программы, потому что это имеет важный дефицит: Вы не можете аннотировать его случайным материалом, не нарушая данные, которые уже представлены с ним. например, я не могу аннотировать такой код программы представления списка cons'd тем, что он был отредактирован Joe два дня назад, не превращая ту форму в ерунду для компилятора шепелявости. эти аннотации все более важны, поскольку Ваш DSL's становится более сложным, и поскольку Ваши макросы превращаются в маленькие компиляторы, компилирующие Ваш DSL в шепелявость.
Я не знаю о наличии любимого неправильного представления..., но один я часто вижу, что программисты говорят о "LISP" и почему им не нравится academic/it'll inappropriate/it it/it, никогда не работают на проект X. Который был бы прекрасен кроме, когда они говорят "LISP", они имеют в виду "Схему", которой они действительно имеют в виду "подмножество Схемы", которой они действительно имеют в виду "половину помнившего подмножества Схемы от того, что AI или курс языков 5 лет назад, что им не нравилось".
Кажется, существует довольно мало иррационального предубеждения против Lisp от этого направления. Рациональные предубеждения - что-то еще полностью.
Lisp является интерпретируемым языком, и таким образом это действительно медленно.
Посмотрите на функцию, демонтируют в языке Common LISP Спецификацию Hyper.
Реализация языка Common LISP под названием SBCL идет с эффективным собственным бэкендом компилятора для многих платформ.
Мое любимое неправильное представление: то, что это - “функциональный язык”, который препятствует повторению или ООП или безотносительно стиля программирования, можно назвать.
Ничто не могло быть более далеко от истины.
В первую очередь, “Lisp”, в зависимости от значения, предназначенного динамиком, не является действительно языком вообще, но языковой семьей. Существует несколько более или менее известных и широко распространенных членов этого семейства: Схема, язык Common LISP, Emacs-Lisp и AutoLisp являются традиционными; в наше время существует также Ню, newLISP (который на самом деле больше похож на “oldLISP”, чем современный, но так или иначе), Дуга и Clojure.
Это, конечно, верно, что Интриганы, кажется, одобряют функциональный стиль и препятствуют повторению в пользу рекурсии. Однако насколько я могу сказать, Интриганы являются на самом деле меньшинством в мире Lisp, по крайней мере, при рассмотрении практического использования Lisp как инструмент программирования в противоположность предмету исследования или исследования.
Я не знаю много о AutoLisp или всех других диалектах Lisp около Схемы и языка Common LISP, но что я действительно знаю, то, что язык Common LISP является определенно языком ни одной парадигмы, который сторонится императива или даже объектно-ориентированного программирования. На самом деле язык Common LISP показывает самую мощную основанную на классах объектную систему, о которой я знаю, включая материал как аспектно-ориентированное программирование из поля.
Lisp, кажется, мне на самом деле языковая семья, что большинство поощряет эксперименты в новых направлениях и наиболее легко включает парадигмы программирования, которые не поддерживаются с самого начала. Это включает императивное программирование. Язык Common LISP даже получил GOTO!
Этот "CLOS" - это язык программирования, и Лисп - это интерпретируемый, функциональный язык. На самом деле, я слышал это от профессоров CS. И я думаю, что в одной из этих книг по концепциям языков программирования была некоторая вводящая в заблуждение диаграмма, которая предполагала это.
Сегодня преподаватели CS в колледжах и университетах (особенно молодые) получали образование с использованием Java, C и C ++, и они, вероятно, изучали либо Схема или Common Lisp в курсе под названием «сравнительные исследования языков программирования» или «парадигмы программирования», который, вероятно, преподавал кто-то, кому не нравится какой-либо язык Lisp, и рассказывал им о функциях, списках, символах и функциях высшего порядка. . Период. Затем они учат тому, чему научились:
- Lisp - это один язык программирования
- Lisp интерпретируется
- Lisp медленный
- Lisp - это язык AI (в последний раз я проверял Роберта В книге Себесты это все еще утверждалось - но есть новое издание, поэтому он, возможно, исправил это)
- Lisp не поддерживает объектно-ориентированный объект (!!!)
- Lisp является функциональным языком (в отличие от минимально поддерживаемого любая другая парадигма)
- В Лиспе нет типов данных
- Лисп не имеет структур данных, кроме списков (и, следовательно, не полезен для обработки чисел)
- «Лисп больше не используется, а используется только в этом конечно, потому что это самый важный функциональный язык »
. Я даже видел очень умного профессора, который приводил пример умножения матриц в Common Lisp - конечно, представляя матрицы в виде списков!
Это потому, что люди решают сложные проблемы, используя Lisp , сам язык должен быть сложным.
Рекурсия сложна . Неподвижные точки функций жесткие . Но они едва охватывают главу 1 Структура и интерпретация компьютерных программ . Это не потому, что Scheme сложен - это на самом деле потому, что это так просто, все, что осталось сделать, - это сложные вещи!