(noob rant) А вот Питон. Никогда раньше на нем не писал, но тут приходят клиенты и говорят: хотим ваше чудо чудесное в своем приложении на питоне использовать, да на винде, не где-нибудь. Я им говорю, ща, демку вам набросаем. Про себя думаю, это ж Питон, там батарейки, аккумуляторы, богатая экосистема, напишешь import antigravity и полетел. А там... Вот есть технология, которая примерно ровесница самому питону, и до сих пор вполне себе работает во всех виндах - Video for Windows. Какие есть в питоне средства с ней работать? Я так понял, вообще никаких. Ну ладно, может это слишком виндово для гзмеев. Для сжатия видео все равно будет моя DLL-ка вызываться. Но потом мне надо сжатое видео в файл записать. Что там у вас в библиотеках для записи AVI, сравнительно простого и старинного формата? Да как-то тоже практически ничего, про видео видно лишь пару оберток над ffmpeg. Вызывать стороннее приложение - вот все, на что питонисты способны тут. В итоге плюнул, сделал свою простенькую писалку AVI в 128 строк, для небольших файлов. В итоге все заработало как хотелось, даже в процессе получилось в моей DLL-ке баг найти: в одном месте 64-битный указатель обрезался до 32 бит при передаче в мою виртуальную машинку, ИЧСХ при загрузке DLL-ки из моих тестовых прог и при загрузке кодека в приложения вроде VirtualDub все раньше работало, т.е. указатель тот всегда оказывался нулем в верхних битах. А вот при вызове из питона не оказался, так получилось это обнаружить. Для работы с DLL использовал модуль ctypes. Они там берутся контролировать типы передаваемых данных, и, как я понял, для передачи бинарных данных вроде BYTE* предполагается использовать массивы вроде c_ubyte * size, причем тип указывается при объявлении прототипа ф-ии, и если у меня при разных вызовах передается разное количество данных, то получается фигня: массив другой длины это уже другой тип, его ctypes не дает передать. Это что же, перед каждым вызовом надо заново определять тип вызываемой функции? Или, видимо, надо объявлять там POINTER(c_ubyte), а при вызовах делать cast()... И в то же время этот их строгий контроль типов спокойно разрешил целое число вместо указателя на void передать (ненамеренно). С непривычки тяжело, конечно, пока писал скрипт на 200 строк успел несколько раз словить в рантайме "а вот тут число аргументов не то", "а вот эту переменную я не знаю" и другие прелести недотипизированных интерпретируемых языков.
Питер Норвиг зачем-то написал на Питоне интерпретатор небольшого подмножества Схемы в 90 строк кода. Дабы слегка посрамить этот гадкий питон, я перевел Норвиговский интерпретатор на Руби и заодно добавил туда поддержку продолжений, важной фичи Схемы, которую в питоний интепретатор должно быть вставить заметно сложнее. Такой вот пример
(begin
(define fact (lambda (n)
(if (<= n 1) 1 (* n (fact (- n 1))))))
(define f (lambda (return)
(begin
(return 2)
1)))
(display (f (lambda (x) x)))
(display (callcc f))
(fact 5)
)
выдает 1, 2, 120. Здесь return - не конструкция языка, а имя переменной, получающей текущее продолжение. Выложил здесь.
Получилось всего 60 строк. Let the срачь begin! ;)
Не знаю, я не в курсе трендов статистики. Недавно слышал про очередной опрос, там было что-то вроде 35% копенгагена и меньше 20% у каждой из остальных.
Регулярно проводятся опросы физиков, какой интерпретации квантовой механики они придерживаются. У меня сложилось впечатление, что за последние 10 лет доля саппортеров ММИ существенно снизилась.…
Вот именно, надо просто использовать инвариантные переменные. А "обычная" квантовая механика на своём уровне справляется, даёт приблизительное решение. Неинвариантное.
Вообще-то у нас вроде как есть ещё квантовая теория поля. В ней не используется уравнение Шредингера. И там делаются очень, очень продвинутые предсказания насчёт того, как будут взаимодействовать…
Comments
Но и, повторяю, квантовая…
Вместо ур. Шредингера там есть его родственник - оператор эволюции…