mayton2019

Можно почитать Макконелла - Соверешнный код.
Но применительно к предметной области автора (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 это вообще другое.

Deprecated не так страшен. Для java экосистемы такой стикер может висеть по много лет. За это время вы успеете поменять проект.

Более хуже ситуация когда разработчик завязался на недокументированное поведение а его (поведение) в новых версиях исправили. Шок трудно описать :)

Нужно писать программу так чтобы она была легко читаема для человека. И чтобы другие читающие
быстро поняли что имелось в виду. Методы против функций - это холивар. В нем нет смысла.
Лучше приведи свой код и попроси сделать code-review.