mayton2019

С практической точки зрения - надо смотреть план исполнения запроса. Там будет указан тип сканирования и предикат как БД фильтрует строки. Если план для
SELECT (1)
не отличается от
SELECT (*)
то тогда можно считать что это - одно и тоже.

Почему обсуждение теоретического SQL я считаю здесь вредным и бесполезным? Потому что ни я ни
кто либо из присуствтующих стандарт SQL не читал. Это - закрытый и платный документ. И
обычно нам достается не текст стандарта а текст самой реализации на Oracle/PG/MySQL.
Вот и говорим о реализации а не о стандарте. А реализации бывают разные. В оракле например
требуется фейковая табличка dual для пустых безтабличных запросов. В других dbms
- фейковая табличка не нужна. Синтаксис другой.

Если кто-либо из присуствующих читал стандарт SQL и знает как объявлено поведение count() - то прошу
привести хотя-бы цитату.

В целом - нет. Современное программирование - достаточно интуитивное. Если вы собиратесь делать сайты (фронт или back) то какая-то сильно продвинутая математика вам не нужна. Хватит сложения и умножения и взятия процентов. В остальном - знания достаточно гумантитарные. Знать иностранный язык. Быть polite и соблюдать code of conduct в корпорации.

А если планируете идти в data-science, машинное обучение - то там надо. Там надо чтобы отстаивать свою правоту перед заказчиком и коллегами. Мат-статистику и теорвер хотя-бы на уровне основ надо знать.

Тоже самое если идете в производство и технологии. Там нужны технологические знания.

Возможно ищется функция F следующего вида

J(n) = F(J(n-1))

Здесь предполагается что расчет F и J(n-1) будет значительно проще чем расчет J(n).

Есть ли литература в которой объясняется методика парсинга форматов типа pdf/doc/специфических бинарных форматов?

Единой методики нет. Для парсинга коммерческих форматов лучше брать коммерческие либы.
Так хоть будет гарантия что все сработает без ошибок.

Я использовал опенсорцсные библиотеки iText, Poi для pdf,doc. Но не столько для парсинга
сколько для генерации отчетов. А генерация обычно использует подмножество спеки.

https://poi.apache.org/

О том чтобы самому разбирать бинарный формат - забудь. Это будет просто пустая трата времени.
Можно разбирать простые бинарные форматы такие как BMP (bitmap) но для сложных нужно
потратить долгие месяцы и годы чтения спецификаций и то ты реализуешь не все а просто
какое-то подмножество формата. Сам создатель Microsoft форматов документа как-то писал
что они даже для него сложны.

Есть фреймворк Kaitai-Struct который пытается формализовать описание всех форматов
в виде некого DSL (в виде yaml). Я пробовал его использовать. Как по мне - он генерирует
слишком переусложеннные сериализаторы где много лишнего кода. Еслибы писать вручную
то очевидно что было-бы компактнее.

https://formats.kaitai.io/

Почти во всех языках разработки есть функция shuffle которая случайным образом тасует массив как колоду карт.
Вот как тут пишут https://www.geeksforgeeks.org/shuffle-an-array-in-... с помощью numpy.

Есть еще генераторы перестановок (permutations) там можно получить не случайные а последовательные и неповторяющиеся перестановки. Например для массива из 10 слов можно получить больше 3 млн новых массивов.

В Java мне часто не хватает некоторых методов для работы со строками и я подключаю commons-lang3. Кажется там есть всякие расширенные опции поиска и замены. И что характерно там не нужен формат регулярки. А просто можно строку заменять на строку. Я давно ничего не делал в Котлине и не знаю как там щас. Но мне кажется что они пошли по пути очень быстрой эволюции языка. Я не знаю хорошо это или плохо. Как мне кажется это всегда плохо
для изучающих язык. Язык богатый фичами языка - всегда будет сложен в разборе поведения. Яркий пример - неопределенное поведение в некоторых языках. Целые статьи на эту тему пишут. Чтоб объяснить почему инкременты с присвоениями конфликтуют в одном выржаении.

И вообще найти баланс между ядром языка и библиотеками - это большое искусство. Я в данном случае - за простоту языка.

На бумаге могут стоять водяные знаки в виде мелкой сетки желтых точек.
Глазами не видно. Но софт распознает как watermark. Технология такая есть.
Чтоб документы не тырили. Из секретных ведомств.

Зачем я это говорю. Просто поддерживаю автора в его параноидальных мыслях.
Ну а если-б не говорил было-б лучше? Предупрежден - вооружен!

Мне вспоминается мультсериал Футурама. Там профессор построил космо-корабль. И когда его спросили как он работает - профессор ответил что не помнит. Но потом как-то вспомнил. Оказывается корабль вообще не летает. Он стоит на месте и двигает всю вселенную вокруг себя.

Пл поводу графики в играх. Я кажется знаю откуда ты эту фразу слышал. Это проеобразование world координат во view. Это идет от точки зрения алгебры матриц которые используются в 3Д графике. Чтоб показать на экране какую-то объект (куб, тор или пирамиду) надо все его координаты сначала умножить на матрицу его базовых преобразований (повроты сдвиги и масштаб) и потом еще это умножить на матрицу камеры. Здесь кстати на уровне камеры и делают всякие искажения перспективы и изометрию. И мы получаем фактические координаты экрана. Там еще идет хитрая оптимизация что две матрицы -константы и их можно взаимно перемножить и тд.

Это в теории. Как реализовано в OpenGL/Vulkano - я щас не знаю. Но думаю что основа - таже.

Вот. Поэтому да. С точки зрения камеры - она стоит неподвижно. И вся вселенная точек, полигонов и спецэффектов крутится бешено вокруг камеры чтоб занять именно то положение которое должен видеть игрок когда играет например в 3Д шутер.

Коммит - это просто текстовое сообщение которое добавляется командой

git commit -m "Message text here..."

Сделай

git log
для обоих проектов и посмотри как текст выглядит внутри.

Я думаю что ничего интересного там нету.

Серверную часть можно писать на чем угодно. Какие-то древние сайты писались на Perl, Bash, Tcl и еще бог
знает на чем. С++ тоже поддерживается но с моей точки зрения фиксить баги сложнее и не так оперативно.
Веб-сервер Apache настраивался так что можно было любой "экзешник" использовать как CGI скрипт
(оракловый sqlplus можно было настроить). Ну Python на сервере и так норм работает.

По поводу браузера.
Python не поддерживается браузером. Поэтому клиентский скриптинг - отпадает.
Хотя я где-то читал что на заре создания браузеров обсуждалась идея вместо
JS использовать Lisp :) Забавно было бы на это посмотреть. Но... многие
академические идеи на практике не взлетали.

В качестве content-type браузер поддеживает text/plain поэтому можно отдавать плоский текст.
Я так часто делал для отчетов. Поэтому без html/css можно обойтись. Хотя выглядит прозаично.

Бизнес должен понимать что вы ему предлагаете. По сути эту идею можно продвинуть только под соусом разработки новой фичи. В противном случае у вас будет сильное непонимание. Все что вы предлагаете - это NFR. Не-функциональные требования. Шестая версия дотнет. Асинки. Обжекты. Бизнес не понимает как ему это дальше продавать.

Я-бы сказал что просто так взять всё и переписать - это гиблое дело. Пойдут баги и бизнес попросит либо срочно исправлять либо откатить это назад до старой версии. Это - фиаско. Очень часто бывает так что старый и плохой код завязывается на какое-то странное поведение API которое плохо документировано и чёрт-пойми-как-работает. Но работает. Я много таких аномалий видел. И ты его исправляешь по фень-шую как должно быть и становится ... (!) еще хуже. Особенно большая беда с мультипоточкой и интеграцией например с операционкой или сторонними нативными либами.

Если вы имеете силы и смелость - то пишите план (желательно на пол-года) на рефакторинг. Шаг-за шагом. Сначала - покрытие всего тестами. Потом миграция версий тоже мелкими шажками. И все это (!) параллельно с разработкой новой фичи которую бизнес одобрит. Только так.

Типы проксей разные бывают. HTTP/Socks4/5. Несовместимые между собой.

По сегодняшним меркам технологии устарели. Так автор ставит
testImplementation 'junit:junit:4.+'

Каким сегодняшним меркам? Да эти зависимости еще 20 лет будут работать. Ты разобрался как знак "+" работает
в данном контексте? Поставь конкретную версию junit (старую!) с которой все работало раньше и пускай так себе
работает. А то у тебя как в анекдоте "лапы вытянул - хвост увяз".

Это как в автомобиле. Если что-то застучало или загремело - срочно на СТО. Учитывая что это HDD механического типа - далее ситуация будет ухудшаться. Я-бы сделал сразу полный бекап всего. Чтоб потом не плакать слезами. И в ремонт.

Непонятно что вы хотите увидеть в этой табличке? Кейсы в которых надо брать ООП или не-ООП?

Мы живем в эпоху мультикультурализма в разработке. Языки такие как C++/Scala в принципе - мультипарадигменные. Они являются одновременно ООП и ФП. И эта диффузия продолжается.
И другие языки тоже идут в этом направлении.

Есть хороший доклад Брагилевского где он просто напримере геометрических фигур (круг, квадрат)
показвывает что ФП и ООП - это просто две ортогональные технологии которые одинаково ведут
к успеху.

По реализациям. 99% зависит от платформы. Например языки C#/F# будут скорее всего использовать
платформу .Net и ее реализацию типов и классов. Языки Java/Kotlin/Scala - соотв будут опираться
на JVM-представление классов и ее типы. Erlang/Elixir - своя реализация типов в beam-машинке.
Нативные языки - кто во что гаразд.

Когда использовать не-объектные языки. Ну не знаю. Я-бы опять уточнил - когда вам не стоит
внедрять пользовательские типы/классы. Вот я щас пишу утилиту для копирования данных
с продуктового ftp на тестовый. Там нужно файлы выбирать по датам. Код на scala. Состоит
из 1 объекта Main и порядка 40 штук функций. Пользовательских типов нет. Вот мне как-то
так хватило и этого. Если писать notebooks под Databricks то там тоже идет такой себе
стиль программирования где нет явной декларации классов.

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

В родительском ресурсе https://habr.com/ есть очень хорошие статьи на эту тему. Поищи с тегами tile, textures, game e.t.c.