JOURFIXE

Я тут несколько часов трахался, искал решение к обновлению байндинга в Сильверлайте, и наконец все решилось несколькими строчками и одним эвентом. Приятно!

Эдит: собсно сабж, приводите примеры вкусного кода из собственного опыта.

((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))

эхх эта современная молодежь... когда доходит до траханья то предпочитаю то традиционное а не на экране - намного приятней

Во времена старинные, когда деревья были большими... Преподавали на Физтехе курс PL/I. Так лектору (а был неплохой математий и програмист) крышу снесло (а вашему покорному слуге и того раньше). Была там в языке возможность перехвата и обработки ошибок: можно было прописать для каждого их типа либо "системную" реакцию либо свою (и продолжить исполнение!). Оказалось что можно написать такое - добрые люди на "базе" показали:
Уже не помню, не нужны ли там были скобки...
Ну машина и изображала "fatal error" в случае математической ошибки, все по взрослому, а после этого програмулина (после коррекции) продолжала работать. Мануалы о таком сидении на двух стульях умалчивали...

Помнится, в прошлой жизни как-то долго бился над SQL запросом, который работал где-то с полчаса.
Оптимизация всякая особо не помогала.
Дней через несколько осенило - есть простейший критерий, который отсекает 90% ненужных записей и надо сделать запрос по нему, а нужный запрос делать уже по его результатам.
Работать все это стало несколько секунд.

Oleksiy
Операторных скобок в PL/I не было - были BEGIN; и END;
А обработкой исключений нынче никого не удивить, это только в те далекие времена было круто...

Было несколько изящных решений в анализе графов, расписывать муторно.

Была ситуация, когда рутинная обработка клиентом данных с сервера заканчивалась перегрузом. Сильно умный клиент анализировал асинхронно получаемые данные и создавал корреляционные зависимости. Обычно это работало нормально, но иногда, во время пиковых нагрузок, клиент захлёбывался. Оказалось - консюмер (клиент) не успевал за продюсером (сервером). Оптимизация, если и была возможна, проблемы не решала, максимум отодвигала. После некоторых раздумий решил просто прекращать обработку при превышении неких критических величин, а потом, когда пик пройдёт, ресетом воссоздавать упущенные данные. Наверное, оно в той конторе и по сей день так работает.

Была хитрая ситуация, когда добавление ресурсов вместо ускорения приводило к замедлению системы. Оказалось - ещё один элемент в full mesh пересекал критическую черту.

Были решения, в которых задача многократно упрощалась за счёт того, что удавалось поделить казалось бы неделимое на ещё более мелкие составляющие. Имхо, "разделять и властвовать" для анжЫнера - один из главных навыков.

Код на С++:

for (i=0; i < 1000; ++i)
for ( j = 0; j < 1000; ++j)
get_a_tree_and_emulate_an_array[i][j] = 0;

Казалось бы, делов-то - проинициализировать двухмерный массив. Но не всё так просто, это ж С++... Структура данных представляла собой что-то вроде дерева массивов, первый индекс был реализован через оччень хитрый operator [], в общем, вся эта инициализация занимала порядка 20 минут. Всё (очень тяжёлое) остальное занимало порядка 40 минут, итого час. Добавил пару строчек - и оно как побежало... Инициализация - полторы секунды, всё остальное - а что я сделаю? Так и осталось 40 минут.

Я бы сделал примерно так, по обычаю отцов и дедов:

Ну дык... Обычаи - дело крепкое У меня там было "p[j]=0", а остальное то же самое.