Можно использовать распределённый поисковик, такой как YaCy. Поисковые запросы нигде (кроме Вашей машины) не сохраняются, а индекс сайтов распределён по сотням компьютеров — возможностей для цензуры или слежки просто не остаётся.
Правда результаты выдачи YaCy сейчас, откровенно говоря, не очень, но с ростом числа участников сети этот показатель улучшается.

Скорее всего просто не знают, что так можно. Для многих (да что уж греха таить, и для меня до недавнего времени) функции с переменным количеством аргументов в Haskell вроде printf воспринимаются как чёрная магия и нарушение законов языка. Возможно ситуация бы изменилась, если бы была какая-нибудь библиотека, реализующая эту возможность, или хотя бы популярная статья.

Да, это текстовое представление. Например, программа:

int add(int a, int b) {
    return a + b;
}
int main() {
    int sum;
    sum = add(1, 2);
    return sum;
}

компилируется в:

По структуре байткода есть хорошая книжка: Building a C-based processor

Такой ассемблер сам по себе достаточно высокоуровневый язык по сравнению с Brainfuck :-)
Можно ещё чуть-чуть доработать до ассемблера LCC и получить компилятор из C в Brainfuck абсолютно бесплатно.

О, сколько нам открытий чудных :-P
Одно только не понятно, тип toss:

toss :: [String] -> IO String

Но дальше по коду Вы применяете её к двум аргументам, например:

toss [] f = fmap show f

Как такое возможно?

Насколько я знаю, в The Powder Toy используется обычный подсчёт соседей. Может быть Golly использует БПФ как один из вариантов, хотя там вроде Hashlife главный алгоритм.

Любопытно, а какими «общеупотребительными знаниями» они собираются его снабдить? Нагружать такую мощную систему простыми вопросами как «Какая погода на завтра?» по моему не имеет смысла, тем более за серьёзные деньги.

Как я вижу, Вы сделали некоторые функции короче. Конечно можно и так, но цель моего «развёрнутого» кода в том, что можно проследить взаимосвязь между использованием продолжений как обычных функций, и как монад.
Сравните:

func_cps :: Int -> (Int -> r) -> r
func_cps x k = incr_cps x $ \inc ->
               square_cps inc $ \sq ->
               k sq

и

func_Cont :: Int -> Cont r Int
func_Cont x = do inc <- incr_Cont x
                 sq <- square_Cont inc
                 return sq

Да, эта программа не учитывает само значение факториала, просто для n>7 факториал больше 9000.

String тут потому, что в конце мы возвращаем show i, т.е. строковое представление числа.

getCC' — это вариант getCC, с помощью которого можно ещё и передать состояние. Грубо говоря, getCC' возвращает нам пару из текущего состояния вычисления (число в данном случае) и функции, которая берёт новое состояние и возвращает вычисление в заданную точку (как goto). В статье есть больше про getCC и getCC' + объяснение как они работают.

Как Вам будет угодно.
Правда, если бы я знал, где я «ввожу других и себя в заблуждение», то не стал бы спорить насчёт правильности моего высказывания.

Я надеялся, что смог объяснить его смысл :-P

Наверное не стоило заострять внимание на откладывании IO действий, к тому же FRP даёт выигрыш совсем в другом месте.

«В императивном языке намного проще реализовать такое поведение, ведь в нём мы можем изменять состояние программы, в то время как в чистом функциональном языке нам придётся оперировать специальным громоздким типом для состояния, передавая его из одной функции в другую.» — эта фраза достаточно ясна? Смысл совсем другой, но по-моему, она намного лучше отражает проблему, решаемую FRP.

Скорее всего я просто не смог правильно выразить свои мысли.

Я знаю, что любая функция может иметь тип IO, но сама по себе IO не выполнится. Чтобы увидеть хоть какой-нибудь эффект от неё, мы должны либо добавить её в main (unsafePerformIO и вызвать из ghci не рассматриваем).

Грубо говоря, идея моей фразы в том, что чтобы выполнить IO действие в Haskell, мы обязаны сделать это внутри монады IO, которая «оживёт» только в main.

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

Это и есть та хвалёная чистота Haskell. Так как IO действия и остальной код разделены, мы не можем поменять какую либо переменную прямо в ходе программы или считать что-либо извне. Значит функции будут всегда предсказуемы: на один аргумент всегда тот же ответ. Это сильно упрощает отладку, позволяет проводить мощные оптимизации компилятором, а также даёт возможность работать с кодом как с математическими выражениями. Вот тут про это немного рассказано: Чистота языка программирования

Скажем так — в Haskell действия делятся на IO и на все остальные. IO действие может прийти из любой точки программы, но выполнится оно только в main.

Попробую объяснить. В Haskell все IO действия выполняются только внутри монады IO (если мы не нарушаем запрет, конечно). И чтобы их выполнить, нам приходиться «нести» эти действия до main, ведь только там IO будет запущена. То есть, например в C, мы можем вывести строку на экран или считать её в любом месте программы, а в Haskell мы будем ждать до тех пор, пока не сформируем окончательное IO действие в main.

Ну, это же бесполезные движения :-)
solve os ns n = filter (\e -> calculateExpression e == n) $ generateExpressions os ns

Зачем в функции solve выводить список пар? Первый элемент каждой пары будет равен n после фильтрации.

Да, так оно и есть. Но ведь частично, не полностью.

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

В строгом языке это как раз таки и не выльется в min(список), поэтому никто и не будет сортировать его чтобы взять минимум.