mayton2019

Я уже устроился на работу по специальности в крупную официальную компанию по специальности и успешно прошёл стажировку

Ну вот если устроился и работаешь - то тебе вроде как оно и не надо. За образованием идут в двух случаях. Первое - это корочка которую требуют родители например или консервативное общество. Или гос-контора обязательно спросит ксиву при попытке туда устроиться (я-бы эту возможность не отбрасывал). И второе - эт собственно технический пласт знаний. Люди по разному учатся. Я-бы не смог учится УЖЕ работая. Это как мне кажется такой разрыв смыслов. Вот на работе тебя поставят за станок с ЧПУ и ты будешь знать досконально как ДАННЫЙ станок работает. Может даже станешь мастером по наладке. Но вот принципы на которых этот станок работает - тебе никто никогда на работе не расскажет. И не потому что это тайна. Просто всем некогда. На работе е6ошить надо как говорил мой шеф. А не книжки читать.

Вот и думай себе. Кумекай что тебе на самом деле надо. Я знаю очень многих людей которые только в 40 лет осознали как много они не знают и что им реально нужно было когда-то ... давно получить это самое образование. Кусали локти потом. Но уже была семья.. дети.

Если автор знает Python - это очень хорошо. Мне кажется что под него щас проще искать работу. В том смысле что он - широкоформатный. Есть и девопс и электронная коммерция и дата-саенс и автоматизация тестирования и нейросети с роботами и железяки.

У багов есть разный impact. Или степень влияния на качество продукта. Вот какое влияние сдвинутых иконок?
Я думаю их увидели только жители стран которые используют перевод с английского и этот перевод оказался на несколько символов длинее оригинала из-за чего произошел развал дизайна. Можно сказать что аудитория некоторых стран ощутила легкое неудобство.

Тоесть impact - так себе.

А что будет если программист 3Д графики допустил ошибку, которая приводит к крашу игры? Тут влияние посильнее. Я-бы сказал что это провал релиза. Как такое пропустили тестировщики (автоматизаторы или ручники) неважно) - ХЗ. Но тут важно срочно бежать в студию и выкладывать на steam экстренное обновление игры. И счет идет не на недели а на считанные дни. Кое-кому из отдела разработки и тестирования придется провести несколько безсонных ночей перед багфиксом.

Вот в этом и есть практический смыл тестирования. Тестировать важные части логики.

Для проведения уроков хочу написать простенький симулятор процессора

Нужно делать тот минимум который нужен для уроков. Если например это арифметика - то
сойдет процессор без регистров. Можно считать что разрабатываем систему команд для
стековой машины. Как Java.

Можно почитать Макконелла - Соверешнный код.
Но применительно к предметной области автора (js/php) очень сложно что-то говорить про архитектуру.
Сегмент PHP - это обычно не сильно сложные задачи. В плане lifecycle - не очень.

Обычно архитектура (А) это совокупность практик. Растешь. Практикуешься. Набиваешь шишки. Но самое
ценно в архитектуре - это не то как ты классы по пакетам разложил, а какие ты вопросы бизнесу задавал.
Насколько они точные? Насколько ни к месту? Какие получил ответы? Как их понял? И какой ценой применил?
И какой эффект получил. Нет толку от А. которая написана в ящик стола. Или которая - просто фетишизирует
фреймворк. Или которая безумно дорога в реализации. Или которая так сложная что команда ее
на поняла, разочаровалась и просто разбежалась.

А. это - как хорошее вино. Подается вовремя к столу. И за нужные деньги.

Насколько я понимаю, каррирование - это плод математических исследований. Математики не интересовались программированием а их больше интересовало некое механическое преобразование мат-функций с целью доказательства какого-то их свойства. Вот. Значит если есть сложная функция у которой сотня аргументов но ее с помощью преобразований удается свести к сотне функций с 1 аргументом - то это успех.

Где это практически применяется я щас не скажу. Но вот Haskell компиллятор видит все функции как каррированные. При этом на output функция будет вести себя как обычная.

Еще КМК каррированные функции очень удобно оптимизировать. Если мы можем часть аргументов зафиксировать (константы) - тогда остаточное туловище функции будет быстрым. Мы ведь уже выбросили
часть аргументов и компиллятор может доказать больше инвариантов. Для обычных императивных ЯП
кажется такое невозможно.

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

Как построенн язык программирования, например: Как понять, как устроенны ключевые слова; Препроцессорные процессы: define, include и др.; - Я правильно понимаю, нужно опустится на ещё более низкий уровень до ассемблера? - Ассемлер является той фундаментальной сущностью в программировании (не считая машинный код, который и так человек не должен понимать)?

Лет 50 назад так было. Программист был физик-математик. И он обязан был знать как работает транзистор. Этот был "тот" уровень понимания требований к профессии. Сегодня знания ассемблера уже не являются обязательными. Можно прожить бурную и интересную жизнь будучи синьором-помидором разработчиком но так и не написать ни строчки на асмах. Профессия разделилась на узкие специализации и знать весь стек уже стало настолько трудно что это перестало быть необходимым.

По второму пункту - я не понял что хотел автор. Хотел достичь какого-то дзена?

Ну и вообщем, какие-то фундаментальные знания - на чём базуется/построенна програмированние и IT, тоже не помешало. Например рекомендуют SICP почитать, правильно ли я тогда пойду или это не то. Если да, можете ещё набросать ваши варианты? Буду признателен.

Кажется один из авторов SICP сказал примерно следующее. Что современный инженер - это уже не создатель алгоритмов. Он - интегратор. Просто сама индустрия подталкивает к тому чтобы популярным стал язык Go а не Scheme. Хотя c моей кочки зрения Scheme интереснее и умнее, но увы. Прагматизм все решает. Для меня Scheme останется в разделе забавных мозговых экспериментов вроде брейн-фака. Ты решаешь задачу и получаешь от этого эндорфин. Как codewars. Вот такого эндорфина от Go нету. Хотя в резюме такое вписывать бесполезно наверное. Кому нужен Lisp-овед или Schem-щик?

Кстати кто знает какие курсы в MIT сейчас читают? Поделитесь.

Такой должности нету. Но это иногда делают архитектор, системный аналитик или просто технический лидер.

1) A OR В И В OR А;
2) A AND ВИ В AND A;
3) (A OR В) OR С И A OR С;
4) (A AND В) AND С И A AND (В AND С);

Это не надо доказывать. Это законы коммутативности и ассоциативности булевых операций AND/OR.

Даллее по тексту там - похоже на закон дистрибутивности но надо проверить.

Движение по кругу задается параметрически. Задаешь параметр fi (фи) пробегающий от 0.0 до 2*Pi радиан.
Далее косинус фи дает тебе иксовую координату. А синус игрековую. Координаты нормированы от -1.0 до 1.0
и их еще надо умножить на пол поперечника окна и сдвинуть на центр координат окна.

Как это делается в WinGDI я не помню. Но тригонометрия - это хитрая штука для ассебмлера. И я тебе советую
сделать макет на языке С и сгенерировать ассемблерный выход и посмотреть что так и как.

А потом уже интересующие тебе функции перенести в твой исходник.

Судя по .exe - речь идет о Windows-разработке. Поэтому надо отбросить все сомнения и читать документацию от производителя. Вот что пишет производитель. Есть API:

https://learn.microsoft.com/en-us/windows/win32/ap...

Вот есть функция полезная CryptProtectData

И это будет лучше решение из всего питонского и кросс-платформенного.

Я полностью поддерживаю использование УЛУЧШАТОРОВ типа SonarQube, PMD и прочие которые просто позволяют указать мне на явные ошибки типа potenrial null pointer de-referencing.

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

Тогда давайте зададим вопрос. А что собсно надо автору? Приведу пример который я часто использую. Решения задач на codewars. Они разные. Но обычно в топе висят 2-3 штуки которые поражают своей краткостью и различностью парадигм. Например в топе висит одно решение с хвостовой рекурсией а другое с циклом. И я не могу решить которое мне больше нравится. Нравятся оба. Но скорее всего при разработке code beautifier я-бы не стал вообще копать 2 направления. Достаточно было-бы просто поставить задачу сделать код меньше. Я думаю что все согласятся что меньше строк - меньше надо будет скроллить вниз. Особенно эти дело любят Джависты. Как накидают своих бинов с геттерами-сеттерами ойойой. 80% кода - нечитаемый шлак. Ну да ладно. А насколько меньше? Есть обфускация. Это сознательне выпиливание смыслов из всех идентификаторов. Вобщем переменные можно называть $1,$2 e.t.c. и это тоже работает. Но ... согласитесь это путь в никуда.

Поэтому. Чтобы улучшать мы должны САМИ задать вектор улучшения. Парадигмы например. Мы хотим код тяготеющий к функциям или к объектам с методами? Мы хотим код с детальным дебагом (каждый оператор в своей строчке) или нам пойдет исходник как у Джона Кармака. Весь С++ исходник в 1 длинную строку. Мы хотим код на конечных автоматах? Или на комбинаторах? Мы хотим больше перформанс но хуже читаемость (вспоминаем знаменитую Кривую Шипилёва) или наоборот?

Вобщем думайте над вектором улучшения.

По математики не силен ((

Не переживай сильно. Для 80% современных задач разработки тебе понадобиться только школьная математика.
Сложить умножить и процент посчитать. Всё остальное - технический дискурс что делать и как делать.

Высокая наука ушла в области datascience, AI, quantum-computing, и всякие формальные логические (тьфу) системы где теоретики занимаются онаниз.... эээ короче фигнёй страдают.

Что тебе понадобиться на самом деле. Структуры python. Библиотеки. Основы мульипоточки. Работа с файлами и сетью. Там не бох весть какая наука. Школьники разбираются. Вот... тут каждый день кодят дискорд и телеграм ботов.

Еще обрати внимание на операции со строками. Строки - основа современного бизнес-кода. Сравнение строк. Подстроки. Замены. Поиск по регулярке. Это должно быть выучено как молитва. Очень часто программист хорошо умеющий работать со строками выкрутится из любой ситуации. Распарсит json и так далее вручную.

Нужен ноутбук для программирования на java, c++, c#.

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

В остальных случаях лучше взять Dell или HP и еще лишние деньги будут. Прикупить хороших гаджетов.

Тут наверное главный вопрос не язык а ОС и платформа. Подозреваю что клуб работает на Windows десктопах. И нужно искать тот инструмент который ближе (нативнее) по отношению к этой ОС. Разумеется глупо выбирать Java/Python. Надо брать технологии которые опираются на .Net. VB/C#/F#. Да много их.

По поводу Java int.

Java создавалась до 1996 года. Это было абсолютное царство 32х разрядных машин. Даже первые Pentium адресовали мало. И никто не думал о том что когда-то разрядная сетка адреса будет удвоена. Тем более что основная целевая архитектура для JVM была микроволновками, кофеварками пультами ДУ и банковскими карточками. Поэтому выбор индекса массива в 32 бита со знаком был норм. Представте что всю память 4G занимает массив целых чисел. И в этом случае достаточно максимального индекса элемента равного 1 073 741 823, больше нет смысла.

По поводу беззнаковости. На битовых операциях signed int ведет себя также как и беззнаковый. Это декларировано на уровне стандарта JVM. Лишь только два логических сдвига различают знаковый бит.

Хотя скажу честно что для меня до сих пор странно иметь компаратор который неверно работает при переполнениях. Конечно хотелось в JVM иметь семантику uint, ulong e.t.c. Есть много величин которые принципиально неотрицательные. Время. Вес. И прочие величины из физики.

Мы не можем точно дать определение термину ИИ. А без этого вопрос не имеет смысла.

Попробуйте сузить вопрос до конкретного применения ИИ. Например ИИ в распознавании лиц это одно. А Co-Pilot это вообще другое.