Почитал претензии к PHP от человека, которого просто по-человечески жалко - http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
Видать хлебнул он PHP :)

Я, к счастью, не пишу на PHP и не собираюсь.
Если надо будет - возьму Clojure.

Но как человеку, которому приходится админить несколько серваков с PHP поделками на борту, становится не по себе.
"Невежество - это блаженство..." (с)

Нет, я уже сталкивался с php-кодерами, которые правят код прямо на боевом сервере, без какой-либо VCS.
И кучей "модов" под phpBB, от кода которых оставшиеся волосы встают дыбом.
Но каждый раз думал, что это мне не с теми людьми приходится общаться.

Это ж не язык. Просто быдло-поделка. И притягивает таких же баранов на нем "программировать". И весь инет под ней. Фукусима, готовая к употреблению.
А я думал, что это SQL - это для баранов. Нет, оказывается есть еще достойные соперники.

Очень серьезное выступление на конференции CUSEC 2012.
Bret Victor "Inventing on Principle" (английский)
http://vimeo.com/36579366
или у меня на сервере - ftp://iqs-mvs.dyndns.org/pub/Video/Documentary/Programming/Bret%20Victor%20-%20Inventing%20on%20Principle.mp4

Людям, никогда не программировавшим на функциональных языках, нужно смотреть обязательно...
...и горько плакать о времени, потраченном на писанину на C/C++, Java и пр. хламе.

Брэт сделал свою презентацию на JavaScript'е, со своим редактором/IDE.

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

Себе на заметку.

С недавнего времени глючит Опера. Не работает flash.
В firefox и chrome работает.

Найдено на forums.gentoo.org.

Запускаем Opera:
$ OPERA_PLUGINWRAPPER_DEBUG=5 opera

При попытке включить youtube в лог вываливается:
Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported

Пролетело в одном из RSS какого-то лиспера.
Статья называется - A Hacker's Introduction to Partial Evaluation.
http://wry.me/misc/peval.html

Больше как памятка себе.
То есть идея безусловно крутая, но пока сиюминутных применений для себя не видно.

Вот общем, сама по себе идея состоит в том, что интерпретатор Лиспа может (при минимальной поддержке программиста) генерировать код более специализированный на основе более общего.

Например, можно взять реализацию какого-нибудь численного алгоритма и специализировать его для заданных аргументов констант. То есть на кривом мат.диалекте - для функции f(x,y,z) специализировать параметр z равным 5 и получить функцию f2(x,y)=f(x,y,5). Фишка здесь в том, что раз функция более специализированная, то и ее реализация может быть более оптимизированной, быстрой и т.д.

Но это даже не самое интересное.
Самое интересное, что интерпретатор Лиспа может сам выплевывать такие специализированные функции, сам их оптимизировать и в конце концов сам компилировать в маш.код.

И это все в ран-тайме. То есть _все_ статически компилируемые языки курят в сторонке по масштабу возможных оптимизаций.

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

А библиотека регулярных выражений на Common Lisp использует подобный подход для компиляции регулярных выражений непосредственно в маш.код. Именно поэтому регулярные выражения в CL работают молниеносно :)

Что тут еще можно придумать из применений?
Первое, что приходит на ум - это все-таки нормальный язык запросов к БД на основе Лиспа вместо дебильного SQL. Нечто похожее пилит товарищ Chris Granger под названием Korma под Clojure. 
/Похоже, что все-таки Лисперы наиболее адекватные среди имеющихся программистов.
Korma вещь приятная (уже попробовал), но пока молодая.

Понадобилось тут недавно потестить один полудохлый винтик после
низкоуровневого форматирования. Само форматирование вроде убрало
все(!!!) бэды. А их там было дофига и трошки. Видимо ремап в Maxtor'ах
птица гордая - не пнешь, не полетит.

Примечание. Все манипуляции проводились под Линуксом с загрузочного
livecd диска.

В теории задачка элементарная, а вот на практике оказалось все немного посложнее.

И так, условие задачи:
-нагенерировать кучу ненулевого мусора, чтоб забить всю поверхность диска;
-по мере генерации мусора (на лету) считать контрольную сумму и в конце процесса
выдать ее на экран;
-и обратная задача: прочитать данные с диска, подсчитать контрольную
сумму и выдать на экран.

Так вот, первый наивный вариант:
# md5sum <(dd if=/dev/random bs=1M count=100 | tee /dev/sda)
... заканчиваться не захотел.

Хм. Покурим мануалы. Ага, так это ж очень надежный алгоритм генерации
мусора! Без активной генерации энтропии, как запуск процессов, работа
с диском и т.д., ничего у нас не выйдет. Засада.

Продолжаем курить мануалы. Они говорят: "Братан, используй
/dev/urandom !" Ага. Попробуем.

# md5sum <(dd if=/dev/urandom bs=1M count=100 | tee /dev/sda)
100+0 записей считано
100+0 записей написано
скопировано 104857600 байт (105 MB), 10.4909 c, 10.0 MB/c
b8e6df9b6b40a4b263ba01db1f85bcac /dev/fd/63

Мдя. 10 Мб/c. И это на ноутбуке! Core Duo и пр. хня.
А на моем стареньком сервере и того меньше - 3 Мб/с! Это ж сколько я
буду ждать 40Гб мусора?!

Продолжаем мучать гугл. Все умники советуют то взять /dev/frandom - а
нет его на livecd ядре, то использовать самописную хню на Си (ага, им бы
Вижуал студию еще на livecd с дотнетом... Придурки :)). Мдя, печально.

Правда вот попался совет использовать openssl :) Хм, это интересно. И
на livecd эта утилитка нашлась. И что-то в этом есть. Пробуем:

# md5sum <(openssl rand 1000000000 | dd bs=1M count=100 | tee /dev/sda)
0+100 записей считано
0+100 записей написано
скопировано 815104 байта (815 kB), 0.073029 c, 11.2 MB/c

Хм. Опять какая-то засада. Чего это за 815кб? А где 100Мб? Опять курим
мануалы. Ага. Похоже бедный openssl просто не успевает за запросами
dd! Ну прямо как бедный студент не успевает за запросами столичных баб
:)

Меняем тактику. Забираем от openssl по-немногу, но часто :) Стиль - "хитро..пая
жена" :)
# md5sum <(openssl rand 1000000000 | dd bs=1024 count=100000 | tee /dev/sda)
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 10.9588 c, 9.3 MB/c

... работает, но опять еле-еле генерируется мусор. Видимо openssl тоже генерирует
какой-то сильно модный мусор! Интиллигент, гребанный...

Ладно, говорю. По-раскинем мозгами. Нам нужен быстрый поток
данных. Где его взять? Ну, есть /dev/zero. Быстрее вроде некуда. Но
это просто нули. Некошерно. Но это уже что-то. С другой стороны у нас есть утилита openssl,
которая может шифровать/расшифровывать что хочешь. Хм, и в этом что-то
есть...

А если взять да зашифровать поток нулей каким-нибудь быстрым
алгоритмом шифрования? От нулей избавимся враз и распределение мусора
будет блатное. Пробуем blowjob... Кхм... то есть blowfish :).

Сначала в /dev/null:
# md5sum <(cat /dev/zero | openssl enc -bf -k 123 2> /dev/null | dd bs=1024 count=100000)
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 1.48378 c, 69.0 MB/c
95e0434d2fa76f5fbf534cec7a3406bd /dev/fd/63

О! Вот оно - дерево! -k 123 - это ключ шифрования :), а т.к. шифрование
может идти вечно, то для игнора воплей openssl, что ему обломали
малину вечного шифрования используем "2> /dev/null".

Ну и наконец, затираем винт мусором на вполне приличной скорости
(старенький винт больше 50Мб/c все равно не выдает).
# md5sum <(cat /dev/zero | openssl enc -bf -k 123 2> /dev/null | dd bs=1024 count=38000000 | tee /dev/sda)

Ну, а обратная операция элементарна:
# dd if=/dev/sda bs=1024 count=38000000 | md5sum

Ура. Мы победили :)

P.S. Сирые и убогие (пользователи Windows), а как вы бы решили эту
задачку? :)

Решил слегка попиарить проект Марка Тарвера - Shen.
Новый сайт проекта - http://www.shenlanguage.org/
Это тот товарищ, который практически в одиночку создал Qi, Qi II.
Монстр. Просто монстр.

Для тех, кто не в теме.
Все эти языки монументальный труд по добавлению в лисп всех последних достижений в области программирования за последние 30 лет. А именно:
- _Необязательная_ статическая типизация. Не просто какая-нибудь, а похоже одна из самых навороченных, включая Хаскел, Агду и пр. мат.выеб..ы.
-Type inference (автоматический вывод типов). То есть то, за счет чего рулят Окамл и Хаскел.
-Pattern matching (сравнение с образцом). На удивление простая конструкция, но такая мощная.
-Ленивые вычисления.
-и т.д. и т.п.

Лично мне вполне хватило бы и первых двух :)
Ну и конечно, все за счет рулит Лисп - гомоиконность, макросы, интерактивная разработка и т.д.
Все в коробке, все на месте. Короче - мечта.

И главное - автор все это построил на базе Common Lisp!
Да, не нужно мучительно писать новый компилятор/интерпретатор для нового языка.
Все есть - бери и делай. Это Лисп!
Пока официальная поддержка только CLisp, буквально на днях - SBCL!

Ложка дегтя - проект очень молодой, баги есть, библиотек практически нет, FFI (линковка с C-библиотеками) пока только в стадии проектирования.

В общем, проекту надо продержаться пока сдохнут C#, Java и прочий быдло-хлам :)

Частичный перепост с freepascal.ru/forum


Короче, маркетоиды из Embarcadero решили "оптимизировать расходы".
Теперь Дельфи для Айфонов, Айпадов и пр. гламурной х-ни (iOS) на базе ARM-архитектуры будет использовать компилятор FreePascal.
Пруф-линки здесь - http://lists.freepascal.org/lists/fpc-devel/2011-August/025330.html


Ну, конечно, маркетоиды заявили, что это временное решение - "пока мы свой компилятор под ARM не напишем".


Что-то вспомнилось сколько времени бездельники из Борланд win64 пилили. 
Чувствую, что надорвутся их индусы в кризис-то чего-то дельное сваять.
Короче, пинают труп. Некрофилы, мля...
Эх, такой проект умудрились загубить...


P.S. А тем временем, команда FPC к куче поддерживаемых платформ, еще и JVM выкатила.

В очередной раз убеждаюсь, что вовремя я на FPC/Lazarus перелез.

Закинул bugs.gentoo.org/show_bug.cgi ебилды для Sepia ( cpansearch.perl.org/src/SEANO/Sepia-0.97/Sepia.html )
Это довольно удобный Perl REPL для Emacs. Так с Perl гораздо удобнее общаться.
То есть Perl становится практически очень мощным функциональным языком.

Ну вот.
Не прошло и нескольких недель, как я случайно нашел книгу с описанием _реального_ опыта разработки больших программных продуктов.

Итак, встречайте - The Architecture of Open Source Applications Amy Brown and Greg Wilson (eds.) -  http://www.aosabook.org/en/index.html

Что внутри?

• Открытая (Creative Commons) книга (то есть даром) - ставим жирный плюс. Авторам солидный респект и уважуха.
• Все проекты-примеры описаны самими авторами, а не какими-то коммерческими деятелями-маркетоидами.
• Все проекты-примеры - открытые open-source! Это уже серьезно, это не пальцы гнуть на презентациях и пр.понто-сейшенах, зная какое быдло-кодерское говно у вас в коде проекта на самом деле.
• Все проекты-примеры - не просто поделки в 2 тысячи строк, а серьезные продукты с серьезной историей и которые используются тысячами бойцов.
• Спектр проектов-примеров весьма широк - от компиляторов до видео-игр.
• Внутри есть код, бля! А не просто водичка о том, сколько раз в день надо преданно смотреть в глаза своему менеджеру, и как часто надо повторять о лояльности очередной все-решающей "методологии".

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

Пока что, это лучшее, что я видел.

P.S. Да-да, Eclipse присутствует, к сожалению.

 Хм.
Вроде такая реально нужная вещь. Но похоже в стандартной поставке нету.
Погуглим, найдем.

~/.gitconfig

...

[alias]
conflicts = !sh -c \"git ls-files -u | cut -f 2 | sort -u\"
conflicts-resolved = !sh -c \"git add \\$(git conflicts)\"

И все пашет.
Теперь git conflicts выдает список всех конфликтных файлов, а git conflicts-resolved - добавляет все ранее конфликтные файлы в индекс для коммита.

С башевым автодополнением параметров - все это просто сказочно.

(с) Что еще нужно, чтобы спокойно встретить старость?