mayton2019

Соревнования и Олимпиады помогают для поступления в университет. Но они они не способствуют поступлению на работу в большую корпорацию. Скорее наоборот. Олимпиадник - опасен и создает проблемы для проектов которые работают по 20-30 лет. Олимпиадник также будет раздражать других командных игроков. Его оценки (эстимации) задач будут слишком отличаться от других. Олимпиадник плохо понимает необходимость эстетики программного кода и SOLID-философии. Дай бох что за 5 лет учебы в университете этот гений слегка поостынет и начнет думать как team-player.

К сожалению комметарии всегда не формализованы. И разработчик не являясь техно-писателем не может их написать настолько грамотно чтобы они представляли интерес для заказчика. Поэтому для заказчика пишутся отдельно сопроводительные документы по софту. А комментарии в коде разрабы пишут для самих себя типа "todo: оптимизировать".

Более того если насильно заставлять разрабов писать комментарии то получается как в той поговорке где заставили дурака богу молится. Будет тонна безсмыслленного текста которая тоже заказчику будет неинтересна. Кроме того у комментариев в коде есть другая беда. Обычно код эволюционирует быстрее и независимее от комментариев. Поэтому часто бывает ситуация когда коммент не соотвествует коду или просто устарел.

Существуют системы авто-генерации документации типа Javadoc, Doxia, но они не получили распространения как в области техно-писательства именно по причинам которые я описал выше.

Matplot умеет много чего сохранять https://matplotlib.org/stable/api/_as_gen/matplotl...

Сделано это для быстрого чтения кода программой.

Это неверный вывод. Такая практика существовала во 2 половине 20-го века когда комьютеры
были слабые и память в несколько килобайт была роскошью. Тогда разработчики на ассемблере
и фортране придумывали всякие хитрости чтобы исходный код был как можно компактнее
чтоб компиллятор его мог обработать.

Сегодня нет вообще никакого смысла сокращать переменные. Здесь есть хороший афоризм от великих. Что-то типа "программы пишут люди для людей и лишь в редких случаях для компиллятора". Минимизаторы для JS у меня вызывают удивление. Браузеры поддерживают gzip-сжатие контента и я думаю надо очень сильно постараться чтоб была какая-то ощутимая разница.

Непонятно зачем в теме вопроса добавлено уточнение про GIL. Это специфика Python?

Добавлю что понятие процесса и потока может уж очень сильно отличаться в разных средах. Процесс в Erlang/OTP - это по сути актор который существует в сильной изоляции от всего остального мира и шарит память с другими процессами только через систему месседжей. Поток в Java - вообще не мапится в поток операционной системы.

Тоесть когда говорим о процессах и потоках то желательно сужать это определение до конкретной ОС и системы разработки.

Любая библиотека с поддержкой arbitrary-precission подойдёт.

Но мне кажется что автору это не надо. Физические величины (расстояния) невозможно менять настолько точно чтобы уже 40 младших знаков имели смысл.

Непонятно зачем автор обсуждает глифы и шрифты? Данная задача состоит из двух частей.
1) Преобразование двоичного числа (например int) в строковое представление двоичного числа.
2) Печать этой строки на экране используя (или не используя) явное указание шрифтов и прочее.

И мне кажется что автор не решил пункт (1) этой задачи. Этот пункт является обязательным на первых уроках информатики. Он называется "Системы счисления". Позиционные. Непозиционные. Перевод из одних систем в другие и прочее. Вот с этого надо начать обсуждение.

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор PNG полезен тем что инфа лежит плотно и в случае "гладкого" характера информации сжимается. Наподобие архиватора.

SVG - не подходит т.к. векторный и расточительный.
JPG - тоже не подходит т.к. повреждает информацию. Ее потом нельзя будет извлечь из файла без потерь.

По поводу дополнения файла до размера кратного длине строки (padding). Там не 00 не FF не подходит. Так как в оригинальном файле тоже могут быть эти константы и алгоритм даст сбой. Надо почитать как делается в криптографии. Там есть специальный workaround. Если его не реализовать правильно то при обратном декодировани картинки в файл мы можем получить ложное удлиннение файла на размер хвостика последней строки пикселов. Насколько это большой дэмедж для исходного файла - ХЗ. Но лучше конечно его не нелать чтоб обратное декодирование было надёжным с точки зрения длины файла.

Изучение Go, Rust я поддерживаю. Это развитие. Это хорошо.

Во фриланс особо не рвись. Я за свою жизнь не видел качественных продуктов в основе которых стоял бы фриланс.

Информатика и вычислительная техника и ЭВМ это немного архаичное название современных it наук таких как собственно программирование, FP, GA, NN, MV.

Старые слова можно много где встретить в старых книгах. У того же Дональда Кнута есть отсылки к алгоритмам сортировки на магнитных лентах.

Это в школе называется - построить уравнение прямой по двум точкам.

В 99% случаев программисты являются пользователями чужого кода. А для этого им не нужно погружаться в имплементацию. По хорошему нужно понять назначение библиотеки. Ее API. И посмотреть модульные тест-кейсы как она тестируется. Там будет очевидно применение.

Поэтому автору не нужно разбирать код. Тем более что для современных проектов код перевалил за сотни мегабайт (на минуточку Война и Мир занимает едва-ли 5 мегабайт) и изучать его весь безсмысленно.

По конкретно формату mkv. Это аналог xml только бинарный. Его не надо крякать или ломать или реверс-инжинерить код. Это совершенно открытый формат. Его спецификация опубликована. И чтение ее даст больше пользы чем ковыряние кода. Поймешь спеку - и сразу будет понятно что код делает.