Life

Я тут почитываю Lisp in Small Pieces. Крайне интересная книжка, рекомендую.

Решил поделиться следующим фактом.

Для того, чтобы реализовать всю семантику контроля потоком вычислений Common Lisp, включая в том числе обработку исключений CL, нужно чтобы язык поддерживал Escape Continuations.

А конкретнее, необходимо реализовать процедуру call/ep, или аналогичный макрос let/ep

call/ep имеет тот же интерфейс, как и call/cc, с тем лишь отличием, что процедура-продолжение, передаваемая в параметр функции становится невалидной сразу после выхода из фрейма активации этой функции. То есть, мы можем "выйти" из функции/блока, но зайти в него снова, как мы могли бы это сделать с полноценными продолжениями - мы не можем.

Вот как эта процедура пишется на CL.



Фактически, для полноценных escape-продолжений нам необходимо лишь реализовать базис в виде двух операторов/функций - throw и catch(или, что то же самое - block и return-from). Желательно, конечно, чтобы в базисе был еще и unwind-protect, но имея упомянутые два оператора, мы можешь написать его и сами.

Как несложно догадаться, все это вместе поддается реализации на любом языке, поддерживающем замыкания и исключения(или же setjmp+longjmp). Замыкания, впрочем, можно заменить объектами, но в таком случае всё это дело будет смотреться более громоздко.

Кстати, тут в Juick напомнили про Си, и я решил написать, что я про Си думаю.
Вообще, получилось не только про Си, но, все таки.

Так вот, то что Си еще жив это, если подумать, вершина идиотизма около-ITшных масс.
( Read more... )

Совершенно от нефиг делать: https://github.com/Lovesan/Microlisp

Буду коммитить на гитхаб по ходу разработки, вобщем. Кому интересно написание интерпретаторов и компиляторов Common Lisp-подобных языков — фоловите.

Планы такие - дописать XI(кросс-интерпретатор, написанный на CL), потом написать компилятор на самом микролиспе, потом им скомпилировать рантайм, стандартную библиотеку и самого себя.
Ну то есть, без всяких там Си.

Продолжаем серию постингов "C++ - говно". На этот раз у нас в гостях C#, а тема - написание COM-компонентов.

В интернете, да и не только в интернете, я много раз слышал, что COM - крайне неудобная в использовании технология, громоздкая и переусложненная. А теперь еще к этому добавляются реплики о том, что и устаревшая.

На самом деле это не так. COM в своей основе крайне прост, и является одной из самых удобных технологий для интероперабельности между различными платформами, рантаймами языков программирования и программами. Для случая RPC же, COM вообще является чуть ли не самой простой и удобной из всех таких технологий, и одной из наименее затратных по памяти и производительности(особенно в сравнении со всякими XML-RPC).
( Read more... )

Устал от того, что люди путают динамическую типизацию со слабой или называют лисп бестиповым.
Поэтому нарисовал вот такую картинку.


(*) Java, C# и Obj-c обладают возможностями динамической типизации. Например, боксинг в Object в Java и C#. Кроме того, в C# 4.0 ввели новое ключевое слово dynamic.
(**) В CL и Clojure присутствуют опциональные декларации типов, так что можно считать, что в них есть немного статической типизации. Современные реализации Common Lisp проводят агрессивный вывод типов при компиляции.
(***) Форт и языки ассемблера принято считать бестиповыми. Но, машинные слова разного размера это ведь тоже типы какие-никакие.

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

Upd: вот еще jtootf подкинул ссылку: blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html

Почему мне так активно не нравится питон и люди, его активно защищающие?

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

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

Это не только к питону и питонистам относится, естественно. Другой пример - жабаскрипт, HTML5 и векторная графика через XML. Третий - опять тот же XML, так любимый большинством жабакодеров и дотнетчиков.

Люди, приводящие аргумент о неважности производительности, как по мне, так не только ничего крупного и серьезного не писали(ничего серьезнее мелких веб-поебеней, как минимум), так и вообще даже не читали об этом.

Вот пример - взять компьютерную графику. Существует такая замечательная технология - трассировка лучей(ray tracing). Она позволяет создавать очень реалистичные изображения, потому как позволяет очень просто и естественно рисовать освещение, тени, отражения и сложные поверхности.

Но с ней есть одна такая "небольшая" проблема - эта техника крайне ресурсозатратна. Настолько, что даже крупнейшие студии компьютерной анимации, типа PIXAR, которые могут позволить себе задействовать целый кластер для отрисовки одного кадра, и то используют ее крайне редко и избирательно - а что уж там говорить про реалтайм рендеринг на современных десктопах - разработчики игр тужатся изо всех сил, выдумывая сложнейшие техники с труднопроизносимыми названиями, вроде Parallax Occlusion Mapping или K-буферов, чтобы добиться хоть какой-нибудь фотореалистичности при сохранении приемлимой производительности. И GPU тут не волшебная таблетка - даже в AAA-тайтлах, ориентированных на пользователей high-end видеокарт, многие вещи в графике, например вычисление World/View/Projection матриц или кватернионов, общих для отдельных частей моделей, приходится делать на процессоре, потому что количество матричных преобразований в отдельной вершине, полигоне или, тем более, пикселе, необходимое чтобы снизить FPS до нуля, не так уж высоко даже для суперсовременных графических процессоров.

Другой пример - хранение и обработка данных. Покуда у вас не кластер на тысячи машин, то если вы делаете что-то крупнее статистики по успеваемости в отдельно взятой студенческой группе, вам надо очень много думать над моделью хранения данных в памяти, и над архитектурой доступа к ним - 8-16 гигабайт в 64-битных машинах, или, тем более, 2-4 в 32-битных это совсем не так много, как может показаться на первый взгляд, но вместе с тем, достаточно много для того, чтобы дико тормозить даже на современнейших системах, если у вас доступ к этим 2-4-8-16 гигабайтам не продуман до мельчайших деталей.

Закон Мура никто не отменял, но он совсем не о том, что мы можем растрачивать ресурсы компьютеров на какое-то говно. Одно дело, когда программа на C отрабатывает за 1 миллисекунду, а программа на X - за 300. Но другое дело когда программа на Си выполняется час, а аналогичная на X - две недели.

Или, "почему Python - говно".
( Read more... )