Category: лытдыбр

Category was added automatically. Read all entries about "лытдыбр".

satyr

Мемуары

Наткнулся в инете на некий материал на мерзком хабрахабре, с которым я, тем не менее, согласен.

Внизу там обнаружился следующий комментарий:
... Реализация какой-то (лент искать) задачи на CL порадовала. Алгоритм был реализован точно, но предварительно генерировался высокопроизводительный машинный код в зависимости от конкретных входных параметров. :3 Работала за 0.7 времени gcc, при том что время компиляции включалось в рантайм, в отличие от gcc. Помечена альтернативной. В других случаях алгоритм вообще слабо напоминает официальный — альтернативным не помечается.


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

К сожалению, энтузиазм у меня быстро угас, когда сначала сняли мой fannkuch-redux, а затем не приняли мою версию mandelbrot.

В первом случае история была такая: пришел автор жабьего варианта и засабмитил "аналог" моего решения, только на жабе. Разумеется, никакого DSL там не было -- все циклы он нарисовал и раскрыл руками, причем только вплоть до некоторого предела (вроде бы до N=12). Коментарий к решению был примерно следующий: "Я не против, если это решение уйдет в альтернативные, но, блядь, в лиспе-то щас то же самое ведь!".

На это прибегает админ shootout и пишет мне: "Это че, правда?". Я типа: "Нет, конечно. Я ничего не делаю руками, да и, вообще, мое решение может посчитать N=13 и дальше, в отличие от жабьего.". Админ ничего не понял и переспросил: "Кто циклы-то расклеивает, ты или компилятор?". Я такой: "Компилятор ессно, там же макрос! Ты глазами листинги сравни.". Тем не менее, через день мое решение было снято и перенесено в альтернативные варианты.

Ну ладно, я здесь даже попытался понять админа -- типа того, что решение обязательно должно реализовывать честный цикл. Хотя все равно неясно, почему, когда компилятор gcc его оптимизирует анроллом, то это нормально, а когда это же самое делает мини-компилятор моего собственного DSL -- это типа нарушение правил?

Тем не менее, мое терпение лопнуло, когда админ забраковал мой mandelbrot из-за того, что я там воспользовался псевдо-ассемблером SBCL (vop-ами) для доступа к SSE. Ну еб вашу мать -- у вас же рядом в рейтинге лидирует сишная версия, которая делает то же самое, только специальными конструкциями GCC?!

Короче, в итоге я просто тупо плюнул и забил на это дело вообще. Куда-то бежать бычить я не стал, потому что позиция админа предельно ясна и симпатична мне: "Не нравится -- сделай свой бенчмарк-портал со своим блэкджеком".

Вот как-то так все было :)
satyr

common lisp @ serious business


Я уже вроде рассказывал, что кое-что на CL мне повезло программировать на "реальной работе" ™ Вкрадце, это некий генератор проектов для внутренних нужд, который по заданному описанию (простенький dsl) генерирует sql-схему базы данных, библиотечку для несложной обработки данных, клиентские биндинги на сях и веб-морду для управления базой. Отдельный упор там на простоту замены бекендов (базы данных, в текущем проекте postgres и mysql, но в перспективе хоть plaintext) и API (сейчас только си, но мало ли потребуется еще что-то, навроде перла).


Веб-морду я сделал на Weblocks, и собственно об этом фреймворке хочу немного поделиться впечатлениями.


Во-первых, это continuation-based web framework, а это означает, что основные подходы к разработке кардинально отличаются от привычных в вебе. Но зато очень похоже на программирование desktop-ных приложений :) Религия weblocks такова: в процессе можно с чистым сердцем забыть про http (а это значит, что никаких сессий, разборов request'ов и пр.), и практически отстранится от написания html/js, при этом ничем не жертвуя. Чем-то отдаленно смахивает на гугловский GWT, но с CL вместо джавы и call/cc.


Из всего этого получается, что порог въезжания в тему достаточно высок, благо надо многое переосознать. Но имхо оно того явно стоит :) Weblocks -- очень хороший фреймворк, в котором многие недостатки continuation-based фреймворков были исправлены. Например, необходимость постоянной полной перерисовки страницы залечена активным использованием Ajax-a. Javascript-ом подсасывается только те виджеты, которые нужно отрендерить заново. Практически полное сходство с десктопной программой :) При этом (о чудо), веб-приложение будет работать даже с отключенном джаваскриптом и нормально индексироваться поисковиками.


Модного нынче де-факто MVC тут нету, взамен предоставляется другая идеология. Дизайнерам предлагается сосредоточится на CSS (а изменить им в веблоковской странице можно почти все -- каждый минимальный элемен торчит в своем div-e), верстальщикам предлагается выучить CL и писать методы render-widget к виджетам (точнее не так -- CL-программистам выучить html, хотя бы по-минимуму, на уровне CL-WHO). Прослойка для доступа к данным представлена интерфейсом "store" с уже готовыми бекендами для clsql, cl-elephant, prevalence и просто memory. Ну а остаток добра честно пишет программист, комбинируя на странице виджеты и создавая собственно код для обработки.


Из всего вышенаписанного становится понятно, что фреймворк достаточно объемный и сложный. И вот на этом месте моментально появляется большой и толстый минус -- в сети практически нет никакой документации. Единицы туториалов, отзывов, tinaa-описание, кое-что можно нарыть в maillist'e, но на этом все. Поэтому путь для освоения следующий: заценивание экзамплов и чтение кода -- очень много чтения кода, благо он понятный и хорошо прокомментирован.


Сразу могу обнадежить будущих адептов: weblocks -- потрясающая по своей гибкости штуковина. Все задуманные в мозгу идеи сделать МОЖНО, даже если для этого не было заранее подстелено соломки разработчиками фреймворка. Не надо городить никаких workaround'ов, надо просто еще раз поисследовать исходники веблоксов на предмет места, которое надо достаточно стройненько перегрузить. Для примера можно посмотреть как в /snippets реализуются такие мега-модные вещи, как suggest или isearch. Существует даже такой экстремальный маневр: если не удается втиснуть текущее ТЗ в рамки уже существующих инструментов (готовых виджетов или интерфейса store), совершенно спокойно можно на них плюнуть и рядом написать с нуля свои. Практически никаких бонусов weblocks от этого потеряно не будет.


Теперь о еще кой-каких минусах. Их почти нет, но кое-что меня тревожит. Например, это производительность. Я не тестировал все добро на нагрузки, но код фреймворка явно написан в пользу читаемости, а не производительности. С другой стороны, направления действий тут видны достаточно явно: nginx на фронтенд для раздачи картиночек, и различные кэширования данных на разных уровнях, благо это continuation-based, и никаких костылей вроде memcached не нужно. Но есть одна штука, с которой я пока сходу ничего придумать не могу -- как масштабировать приложение на несколько машин. В случае с традиционным request/response + sessions тут все ясно, а как это делать прозрачно в сервере на продолжениях -- понятно смутно. Надо же как-то шарить кучу мелких данных по всему кластеру. Возможно, отца русской демократии спасет некого-рода балансировщик нагрузки на фронтенде, который по id сессии будет раскидывать отдельных пользователей на отдельные самостоятельные сервера.


В общем, резюме таково: если у меня будет свой стартап, связанный с веб, программировать мы будем на weblocks :) При определенных навыках эта платформа может дать просто катастрофический бонус в производительности труда.

satyr

"Why I Hate Frameworks" by Joel

Хоть я этого товарища недолюбливаю, но от сабжа я просто рыдал из-под стула :))))))

Для многих боян, конечно, но я настолько сейчас солидарен с автором, что не поленился перевести на русский (очень рекомендую всем асилить):
Collapse )
  • Current Music
    Rage / Speak Of The Dead