В emacs давно нет проблем с utf8 и шрифтами. Просто используйте emacs-23 (и выкиньте из конфига все, что относилось к настройке русского языка для прошлых версий) и добавьте в конфиг:
(set-default-font «DejaVu Sans Mono-11»)
(add-to-list 'default-frame-alist '(font. «DejaVu Sans Mono-11»))
Мне меняли южный мост два раза. В СЦ утверждают, что из-за хлипкого пластикового корпуса, из-за которого на материнку приходятся различные механические нагрузки. Так что проблема не в перегреве.
Где-то читал, что CMUCL/SBCL чуть ли не самые быстрые из всех лиспов, включая коммерческие (в исследования по компиляторам в CMU было вложено много DARPA'вских денег, поэтому над CMUCL усердно трудились).
Техники функционального программирования оказываются жутко полезными для массивно-параллельных программ. Например, функциональные структуры данных, позволяющие писать эффективные алгоритмы без блокировок (lock-free) или копирования данных (zero-copy). Так как эти вещи пришли из ФП, то оно тут при чем:)
Циклы с массивами — это только частный случай. В C или C++ проблему разрешения aliasing'а очень сложно (практически невозможно) решать (aliasing — это эффект, когда изменение чего-то одного затрагивает что-то другое, т.е. есть два имени (alias'а) у одной и той же ячейки памяти). В чистом ФП проблемы алиасинга в принципе не существует (так как значения не меняются), что создают определенные хорошие вещи для компилятора.
Разрешение алиасинга нужно для многих оптимизаций, в том числе для вытаскивания константных выражений за пределы цикла.
Мне питон нравится, я его иногда использую:) Правда, совсем не за быстродействие он нравится. И питоновский неограниченный int мне нравится — типичный пример, когда проектируется от потребностей, а не от железа.
Предложение «И не существует переносимого способа изменять код функции.» относилось к ANSI C. Вполне можно допустить существование реализаций C, в которых запись в тело функции игнорируется.
С тем, что это очевидный способ менять поведение, я согласен.
В стандартах/спецификациях не указывают, как именно надо реализовывать языки, но они пишутся таким образом, чтобы существовала возможность написать эффективный компилятор (никому не нужны замки из воздуха). Иначе почему в java и C# имеем 32-х битный int? Или же пишут не думая или из расчета на интерпретатор, но тогда получается нечто вроде питона, для которого написать эффективную реализацию практически невозможно.
>часто интерпретаторы более эффективны компиляторов
с «иногда» я бы согласился:)
>Или если у Вас код исполняется только однажды (например Вы проводите разовые вычисления) разница «эффективности» компиляции и интерпретации резко стирается
Если этот однократно выполняемый код содержит цикл, то может быть по-всякому.
Строго говоря, в стандарте языка C запись по указателям на функцию является неопределенным поведением. И не существует переносимого способа изменять код функции.
Нестрого говоря, в качестве примера динамизма можно привести библиотеку ffcall, которая позволяет создавать функции определенного вида («трамплины» для функций обратного вызова) в run-time.
Если под интерпретируемостью и компилируемостью понимать то, какая модель трансляции языка в машинные коды является основной, предпочтительной, учтенной, эффективной (например, в питоне практически не учтена компиляция в эффективный машинный код), то вполне можно рассматривать интерпретируемые и компилируемые языки.
Либо же можно ввести определения этих понятий на основе величины interpreter overhead.
В любом случае, разделение присутствует.
А для чего надом изменять AST программы? Для того, чтобы позволить записывать какие-то вещи более естественным образом. Но ведь это — суть DSL (http://ru.wikipedia.org/wiki/Предметно-ориентированный_язык_программирования: «DSL — язык программирования, специально разработанный для решения определённого круга задач»).
Часто под DSL подразумевается некий внешний, «скриптовый» язык, предметной областью (Domain'ом) которого является предметная область программы, и который слабо или никак не связан с языком программирования, на котором пишется программа. Если пользоваться таким определением, то, действительно, макросы и DSL — разные вещи.
Но если позволить себе включать в Domain у DSL код программы и язык программирования, то макросы как раз являются средством реализации DSL. Например, ваш пример — это DSL для описания сериализуемых классов (очень простой, но, тем не менее, DSL; кругом задач является добавление возможности сериализации к классу), nemerle.org/SQL_macros — DSL для написания частей программы, использующих БД (тут кругом задач являются запрос к БД).
А в Nemerle есть возможность посмотреть на AST после преобразования его макросом? В лиспе за это отвечают функции macroexpand-1 (применить раскрытие макросов, но только один раз, не рекурсивно) и macroexpand (раскрыть макросы рекурсивно). macroexpand и macroexpand-1 очень помогают в отладке, особенно когда macroexpand/macroexpand-1 можно применять из IDE.
Динамическая типизация и компилируемость — понятия ортогональные (хотя статическая типизация часто облегчает компиляцию). Например, common lisp является компилируемым языком с динамической типизацией.
Лисп, являясь компилируемым языком, позволяет менять код в рантайме. Например, можно переопределять функции, переопределять классы. Кстати, .net тоже позволяет это делать с некоторыми ограничениями (edit and continue в студии же работает).
Это дело техники — нужна достаточна развитая среду выполнения.
>Шаблоны C++ — хорошая технология, но у неё много родовых травм, например, она работает на уровне текста
Шаблоны C++ работают с типами, а не с текстом программы.
> создание своих DSL… не совместимы с идей языка Nemerle
Разве DSL не совместимы с идеями Nemerle? Наоборот, Nemerle подходит для создания DSL.
Создание DSL — это одна из главных задач макросов и метапрограммирования на уровне AST. По сути, изменение синтаксиса языка и включение в него конструкций, позволяющих более удобно решать поставленные задачи — это и есть создание DSL.
>но каждый перечисленный вариант реализации идей метапрограммирования обладает своими недостатками, которые не совместимы с идей языка Nemerle.
Извините, но вы не поняли макросы лиспа.
> Во-первых Nemerle компилируемый язык программирования, поэтому отпадают механизмы из Ruby, Tcl и LISP.
Лисп — компилируемый язык. И лисповские макросы, в отличие от существовавших ранее fexpr, созданы именно для компилируемых лиспов.
>Макросы распространяются не в виде исходного текста, а в виде откомпилированных сборок — плагинов к компилятору.
Использование макросов не сложнее использования библиотек.
Лисповские макросы распространяются в составе библиотек, которые могут распространяться как в виде исходного кода (который будет скомпилирован), так и в бинарном виде. Плюс есть возможность определять и использовать макрос в пределах одной единицы компиляции, а также определять локальные макросы.
Непонятно, почему в статье проводится дистанцирование макросов немерле от макросов лиспа. На самом деле, немерлевские макросы и лисповые макросы — вещи одинаковые (с той лишь разницей, что в лиспе синтаксис и стадии компиляции более удобные для работы макросов, а в немерле AST сложнее выглядит, т.к. встроенный синтаксис у немерле богаче).
(set-default-font «DejaVu Sans Mono-11»)
(add-to-list 'default-frame-alist '(font. «DejaVu Sans Mono-11»))
Разрешение алиасинга нужно для многих оптимизаций, в том числе для вытаскивания константных выражений за пределы цикла.
В линуксах можно использовать тайловые оконные менеджеры (awesome, xmonad). С ними необходимость в ручной настройке размеров окон уменьшаются.
С тем, что это очевидный способ менять поведение, я согласен.
>часто интерпретаторы более эффективны компиляторов
с «иногда» я бы согласился:)
>Или если у Вас код исполняется только однажды (например Вы проводите разовые вычисления) разница «эффективности» компиляции и интерпретации резко стирается
Если этот однократно выполняемый код содержит цикл, то может быть по-всякому.
Нестрого говоря, в качестве примера динамизма можно привести библиотеку ffcall, которая позволяет создавать функции определенного вида («трамплины» для функций обратного вызова) в run-time.
Либо же можно ввести определения этих понятий на основе величины interpreter overhead.
В любом случае, разделение присутствует.
Часто под DSL подразумевается некий внешний, «скриптовый» язык, предметной областью (Domain'ом) которого является предметная область программы, и который слабо или никак не связан с языком программирования, на котором пишется программа. Если пользоваться таким определением, то, действительно, макросы и DSL — разные вещи.
Но если позволить себе включать в Domain у DSL код программы и язык программирования, то макросы как раз являются средством реализации DSL. Например, ваш пример — это DSL для описания сериализуемых классов (очень простой, но, тем не менее, DSL; кругом задач является добавление возможности сериализации к классу), nemerle.org/SQL_macros — DSL для написания частей программы, использующих БД (тут кругом задач являются запрос к БД).
Лисп, являясь компилируемым языком, позволяет менять код в рантайме. Например, можно переопределять функции, переопределять классы. Кстати, .net тоже позволяет это делать с некоторыми ограничениями (edit and continue в студии же работает).
Это дело техники — нужна достаточна развитая среду выполнения.
Шаблоны C++ работают с типами, а не с текстом программы.
> создание своих DSL… не совместимы с идей языка Nemerle
Разве DSL не совместимы с идеями Nemerle? Наоборот, Nemerle подходит для создания DSL.
Создание DSL — это одна из главных задач макросов и метапрограммирования на уровне AST. По сути, изменение синтаксиса языка и включение в него конструкций, позволяющих более удобно решать поставленные задачи — это и есть создание DSL.
Извините, но вы не поняли макросы лиспа.
> Во-первых Nemerle компилируемый язык программирования, поэтому отпадают механизмы из Ruby, Tcl и LISP.
Лисп — компилируемый язык. И лисповские макросы, в отличие от существовавших ранее fexpr, созданы именно для компилируемых лиспов.
>Макросы распространяются не в виде исходного текста, а в виде откомпилированных сборок — плагинов к компилятору.
Использование макросов не сложнее использования библиотек.
Лисповские макросы распространяются в составе библиотек, которые могут распространяться как в виде исходного кода (который будет скомпилирован), так и в бинарном виде. Плюс есть возможность определять и использовать макрос в пределах одной единицы компиляции, а также определять локальные макросы.
Непонятно, почему в статье проводится дистанцирование макросов немерле от макросов лиспа. На самом деле, немерлевские макросы и лисповые макросы — вещи одинаковые (с той лишь разницей, что в лиспе синтаксис и стадии компиляции более удобные для работы макросов, а в немерле AST сложнее выглядит, т.к. встроенный синтаксис у немерле богаче).