Инстанцируем java.lang.Class

Согласен с вами, лейаут хипа испорчен. Объект ClassLoader, переданный в конструктор, записался в чью-то чужую память и стал бомбой замедленного действия.
Но даже если бы я выделил правильное количество байт, всё равно почти любые манипуляции с этим объектом приводили бы к краху. В JVM ведь по факту никакого нового класса нет, а методы в java.lang.Class почти все нативные.

Понятное дело, что приведённая задача решения не имеет. Вся 6-я часть может восприниматься как шутка.

Тьюринг-полнота Generic типов Java

Верно, любой <? extends X> можно заменить введением дополнительного типа в сигнатуру метода, но я такой подход считаю менее удобным.

Тьюринг-полнота Generic типов Java

В каком то смысле информация действительно теряется, но в данном контексте она и не нужна. Если нужно сохранение типа, то можно написать такой код:

<T extends Number> T firstNum(List<T> xs) {
    return xs.get(0);
}

Но я приводил пример не с этой целью. Рассмотрим такой код:

void query(Map<String, Object> parameters) { ... }

Метод принимает ассоциативный массив "параметров", значения которых могут иметь произвольные типы. Но если вдруг у нас в коде есть объект типа Map<String, String>, то мы не сможем передать его в метод query (типы не совпадают).

При этом если изменить сигнатуру метода на void query(Map<String, ? extends Object> parameters), то в него легко можно будет передать Map с любым типом значений, включая Map<String, String>.

Тьюринг-полнота Generic типов Java

Всё верно, там должен быть индекс n. Спасибо!
EDIT: поправил формулу в публикации

Тьюринг-полнота Generic типов Java

Результат интересен именно как исследование. В реальной работе же полезно знать о ковариантности и контравариантности, всё остальное для души.

Решето Эратосфена, попытка минимизировать память

Смущает данный код:

while (p.lastCrossed < candidate) {
    p.lastCrossed += p.prime;
}
if (p.lastCrossed == candidate) {
    //restart
    candidate+=2;
    i=-1;
}

Чем он лучше такой банальной проверки?

if (candidate % p.prime == 0) {
    candidate += 2;
    i = -1;
}

Странности Generic типов Java

В целом я с вами согласен, сырыми типами пользоваться не стоит.
Но, к сожалению, класс Class (как минимум) слишком часто используется без параметра. Получается, что компилятор вынуждает нас писать <?> в месте неизвестного типа вместо того, чтобы разрешить вообще игнорировать параметр.

Странности Generic типов Java

Вот почему стирание типа T должно тянуть за собой стирание совершенно с ним не пересекающегося типа A? Я не считаю это логичным.
И да, обстоятельства бывают разные и часто в проектах можно встретить raw types

Странности Generic типов Java

Я не утверждаю, что это не по спецификации. Просто сама спецификация местами странная очень.
Например, в случае 3, на мой взгляд, спецификация идёт вразрез со здравым смыслом, да и в случае 1 тоже.
А в последнем, если поменять местами ограничения, то отвалятся референсы для другого типа, так что хорошим решением это тоже не назовёшь.

Как ошибся Белл (если статья привела правильный пример)

По этому и существует только Теория относительности.

Теория Относительности тут совсем непричём.

Теория вероятности говорит о вероятности.
…
И на практике, с человеческим везением можно получить совершенно разные результаты даже в бесконечно долгий промежуток времени.

Настоятельно советую ознакомиться с законом больших чисел, ну или просто почитать основы мат статистики. Получиться то всё может, но вероятность этого настолько ничтожно мала, что её никто не рассматривает.

Как ошибся Белл (если статья привела правильный пример)

а в квантовых экспериментах получается 1/2?

Задаюсь тем же вопросом :)

Как ошибся Белл (если статья привела правильный пример)

У вас ошибка в том, что изначально предполагается наличие 2-х дверей разных цветов, то есть вариант RR отпадает

Как ошибся Белл (если статья привела правильный пример)

Белл всё это дело придумал достаточно давно, и вряд-ли всё мировое сообщество физиков не заметило бы столь простую ошибку. Скорее всего в статье приведён кривой пример.
Обязательно отпишитесь, когда дочитаете «оригинальную статью»!

Как ошибся Белл (если статья привела правильный пример)

Вычисление вероятностей в статье, безусловно, верное.
Вызывает сомнение тот факт, что эксперимент показывает 50% в том случае, когда ответ «классического физика» равен 66% (то есть при выборе возможно совпадающих дверей, абсолютно случайных). Я не нашёл ссылку на научную публикацию, в которой подтверждалась бы такая вероятность, а просто оригиналу статьи (https://www.wired.com/2014/01/bells-theorem) я верю с трудом.

Быстрое вычисление факториала — PrimeSwing

Интересно вышло, алгоритм PrimeSwing был опубликован в 2008-м, автор уже мог знать о более оптимальном способе умножения чисел.
Если я верно понял, автор производил вычисления факториалов примерно до 1000000, то есть результаты были не настолько большими, чтобы использовать Алгоритма Фюрера (если верить википедии). А так да, теоретическую оценку наверняка можно улучшить.
На практике я не заморачивался и использовал то умножение, какое было реализовано за меня в BigInteger.
Спасибо за замечание.

Быстрое вычисление факториала — PrimeSwing

Извиняюсь, действительно у меня в этом моменте ошибка. Вычисление с помощью PrimeSwing имеет трудоёмкость как у простого перемножение двух чисел порядка n!, а не вычисления n! стандартным способом. Сейчас внесу обновление в статью.
Спасибо!

Быстрое вычисление факториала — PrimeSwing

Не совсем, понадобится таблица простых чисел от 2 до n.
Решето Эратосфена составляется за O(n * log log n), это меньше, чем время вычисления факториала. Отдельного способа проверки на простоту алгоритм не требует.

Быстрое вычисление факториала — PrimeSwing

Боюсь, что это вопрос не ко мне. Вероятнее всего различные алгоритмы вычисления факториала имеют соревновательный характер.
Хранить массив может быть очень затратно по памяти, особенно если нужны значения порядка 1000000! (вдруг они кому-то нужны). На практике я такого не встречал и сам всегда хранил кэшированные значения в обычном массиве (во время решения задач по программированию).

Быстрое вычисление факториала — PrimeSwing

Простых чисел от 1 до n всего O(n / log n), вычисление l_p происходит за O(log n).
Сложностью же перемножения простых чисел в соответствующих степенях будет O(n (log n)² log log n) — это уже не очевидная оценка, её доказательство есть по второй ссылке.

Лямбда-исчисление на JavaScript

Это уже написание интерпретатора внутри хаскеля. Можно, конечно, но это не тот результат, который хотелось бы иметь)