Про Питон: если делать это на NumPy обрабатывая картинку целиком или сегментами, может получится быстрее чем на C++. В NumPy не будет цикла по пикселам, а будет векторизация.

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

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

isItemInContainer ?

При прототипировании уже накосячили. Счётчики могут переполнятся. Полагаю, молча.

Портирование не всегда проще оптимизации внутри языка. Пример вообще неудачный - у Питона неограниченные целые, код работает всегда. При портировании типы стали ограниченные - источник ошибок при написании (уже одну нашли) и при использовании (головная боль начнётся на больших входах). Такой себе quick&dirty.

С Новым Годом!

Зато программировать проще: не надо данные туда-сюда гонять между GPU/CPU memory. Часто это позволяет запихнуть большую задачу в небольшую память. Я не про игры говорю а про обработку видеопотока например.

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

... сложить все яйца в одну корзину? Я не понял зачем.

Ограниченные машинные типы есть. Я написал про вещи, которых мне не хватает в C++ после Питона. Генераторы позволяют отделить итерацию от обработки данных - удобная абстракция, влияет на дизайн кода. Великолепные библиотеки написаны на C/C++, но всю свою мощь проявляют в сочетании с удобным синтаксисом языка.

Наличие генераторов в Python, полноценные замыкания, великолепные библиотеки (numpy, pandas), неограниченные целые из коробки.

Великолепно!

Тут есть разбор методов, в том числе и последовательность Люка:
https://stackoverflow.com/questions/14661633/finding-out-nth-fibonacci-number-for-very-large-n

Никогда не видел чтобы оптимизатор переупорядочивал вещественные операции. Именно по причине неассоциативности операций из-за округления. Покажите пример.

Тот пример, что вы привели - это вариант обмена корректности программы на скорость исполнения. Выигрыш обычно не велик, баги чудовищны.

Я привык думать что "детерминированные вычисления детерминированы". Нарушение этого правила - жуткая головная боль.

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

Ах, да, вывод: приведите компилятор в соответствие с IEEE-754, имейте представление когда вычисления с плавающей запятой точные, когда нет (из-за округления) и будет вам счастье.

Ещё надо с утра повторять десять раз: "Эпсилон - часть входных данных. Я никогда не буду вписывать фиксированный эпсилон в код моей программы.".

С третьим пунктом не согласный я. Есть ситуации в которых сравнение вещественных чисел на равенство - осмысленное и хорошо определённое действие.

Испытываю стыд.

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

Y Combinator :

lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(*args)))

Факториал совместимый с комбинатором (или любая рекурсивная функция):

lambda f: lambda n: (1 if n<2 else n*f(n-1))

Запускаем:

@>>> (lambda f: (lambda x: x(x))(lambda y: f(lambda *args: y(y)(args))))(lambda f: lambda n: (1 if n<2 else nf(n-1)))(10)
3628800

Лямбда-исчисление позволяет записать любой алгоритм в одну строку.