Вот есть функция. У неё есть аргументы. Есть код, который вызывает это функцию и передаёт какие-то переменные.
Вопрос - а что по факту передаётся в функцию?
Ответ - по факту это всегда некий адрес в памяти. Массив, int, объект, и т.д. - это всё просто некий адрес в памяти, а дальше уже компилятор разруливает как вызвать метод объекта по этому адресу памяти или как трактовать это как элемент массива.
На заре программирования думали-думали и решили сделать два способа передачи параметров (забавный факт - в компуктерах PDP-11 было аж 42 способа адресовать аргумент) :
1) По ссылке - когда функция получает ровно тот же адрес переменной, который был когда вызвали функцию. В данном случае компилятор просто копирует адрес переменной.
2) По значению - когда функция получает совершенной другой адрес переменной при вызове. В данном случае компилятор выполняет полное копирование переменной.
После это стали думать ещё. А вдруг аргумент функции не изменяется, а мы передаём его по значению. Если это огромный массив - то мы зря делаем полную копию массива.
Пришла гениальная идея - а давайте не будем делать полную копию, вместо этого передадим по факту по ссылке, дождёмся пока код решит что-то записать в эту переменную, и только тогда сделаем полную копию (ну и подвиснем ещё на некоторое время). В итоге компилятор вставляет дополнительный код чтобы разруливать такие сценарии.
Итого: передача аргумента (в более широком смысле - адресация переменных) и стратегия cope-on-write разные вещи, но существуют в одном контексте. Поэтому их часто употребляют как взаимозаменямо. Но их гораздо больше!
ОДИНАКОВЫЕ!!!! Не разные!!! Буква в букву! Если в базе у вас в таблице user есть поле userName, то в энтити user у вас должно быть userName, и в userDto у вас должно быть поле userName.
Поддерживаю, нет ничего сложного в накате миграции для изменения схемы. В крайнем случае, если нет механизма автонаката, можно руками быстро на проде выполнить - по моему опыту даже если у юзеров какие-то реквесты упадут, то ничего страшного, просто выполнят ещё раз.
2. 20 строк в методе, 200 строк в классе
Я бы ещё убрал тупое правило каждый класс в отдельном файле.
Автор правильно пишет про преждевременную оптимизацию и маленькие классы. Если у меня простенький контроллер на 1 экшен, DTO из двух полей и простой CRUD то всё это лучше положить в одном файле User, чем городить UserController, UserDto, etc.
В идеале так вообще один класс, который имплементит все нужные интерфейсы и содержит всю реализацию в себе.
Когда логика усложнится, можно и тесты добавить, и подумать над разделением.
Было бы интересно, если бы Apple выдала доступ к своему API для сторонних организация для управления своими кредитами. Тогда нативно в телефоне можно увидеть все свои кредиты.
По поводу доступа к финансовым данным - в США и так абсолютно все твои кредиты уходят в кредитные агентства типа Equifax / Experian, тут разве что добавляется Apple
Скорее всего индийцы работают по контракту, их уволить можно за один месяц без выходного пособия. Сотрудники из ЕС/США оформлены в офис по договору. Увольнение минимум 3 месяца плюс сложные долгие процедуры сокращения.
Далее — сложение, самая часто выполняемая операция, которую сильно тормозят переносы из разряда в разряд — в случае двоичной системы они происходят в 50 % случаев, а в троичной (симметричной) системе — в 8 случаях из 27, т. е., примерно в 29,6% случаев. Большая скорость и меньшее количество элементов повышают быстродействие троичной машины примерно в 1,6 раза, и, соответственно, уменьшают энергопотребление.
ЕМНИП сложение выполняется за один такт, быстрее уже некуда
Готов поспорить в скором времени мы увидим быструю зарядку по подписке.. Что-то типа $0.5 в месяц (например, под предлогом того, что более быстрая зарядка требует бОльших токов, а это негативно влияет на оборудование и надо чаще ремонтировать электрические сети да и вообще это влияет на глобальное потопление)
Ну это спорно, смотря какая отрасль. Прикладные науки изначально заточены были на освоение большого объёма знаний, теоретические - под многолетние исследовательские труды. Гуманитарные науки, МГИМО и прочее - да, под связи.
Сейчас, на мой взгляд, тенденция такая, как я описал до этого. Судя по тому, что половина комментариев в стиле "плохие лекции", "препод ниочём", "плохо учат" - у многих есть проблема в понимании этого.
Надо ждать S99 (или какое-нибудь другое сакральное число). Всё будут ждать от S100 чего-то принципиально нового амазинг.
А серьёзно, что принципиального нового можно ожидать от смартфона в 2023? Всякие камеры/экраны упираются в текущие технологические возможности. Всё, что можно улучшить - только софтом.
Мы так в ГУАПе писали лабы в эмуляторе pdp-11. Сначала пишешь на асме, потом вручную по табличке переводишь в хекс коды, потом вручную забиваешь байт за байтом.
Ссылку на видео я вам уже привёл, рекомендую посмотреть
Вот пример попроще (взято из википедии):
Я говорил про корень из отрицательных чисел, а вы сейчас пишете про корень из обратного к операции сложения в кольце вычетов. С последним проблем нет. А вот первое (арифметически корень) не существует по определению.
1 и 2 элементы различных числовых множеств с введёнными операциями и аксиоматикой. Например, с операцией умножения.
i не принадлежит этому множеству, но употребляется наравне с этими элементами. Например, можно применять оператор умножения, что технически противоречит определению умножения и ломает кучу определений/теорем.
Может у меня получится прояснить разницу.
Вот есть функция. У неё есть аргументы. Есть код, который вызывает это функцию и передаёт какие-то переменные.
Вопрос - а что по факту передаётся в функцию?
Ответ - по факту это всегда некий адрес в памяти. Массив, int, объект, и т.д. - это всё просто некий адрес в памяти, а дальше уже компилятор разруливает как вызвать метод объекта по этому адресу памяти или как трактовать это как элемент массива.
На заре программирования думали-думали и решили сделать два способа передачи параметров (забавный факт - в компуктерах PDP-11 было аж 42 способа адресовать аргумент) :
1) По ссылке - когда функция получает ровно тот же адрес переменной, который был когда вызвали функцию. В данном случае компилятор просто копирует адрес переменной.
2) По значению - когда функция получает совершенной другой адрес переменной при вызове. В данном случае компилятор выполняет полное копирование переменной.
После это стали думать ещё. А вдруг аргумент функции не изменяется, а мы передаём его по значению. Если это огромный массив - то мы зря делаем полную копию массива.
Пришла гениальная идея - а давайте не будем делать полную копию, вместо этого передадим по факту по ссылке, дождёмся пока код решит что-то записать в эту переменную, и только тогда сделаем полную копию (ну и подвиснем ещё на некоторое время). В итоге компилятор вставляет дополнительный код чтобы разруливать такие сценарии.
Итого: передача аргумента (в более широком смысле - адресация переменных) и стратегия cope-on-write разные вещи, но существуют в одном контексте. Поэтому их часто употребляют как взаимозаменямо. Но их гораздо больше!
Поддерживаю, нет ничего сложного в накате миграции для изменения схемы. В крайнем случае, если нет механизма автонаката, можно руками быстро на проде выполнить - по моему опыту даже если у юзеров какие-то реквесты упадут, то ничего страшного, просто выполнят ещё раз.
Я бы ещё убрал тупое правило каждый класс в отдельном файле.
Автор правильно пишет про преждевременную оптимизацию и маленькие классы. Если у меня простенький контроллер на 1 экшен, DTO из двух полей и простой CRUD то всё это лучше положить в одном файле User, чем городить UserController, UserDto, etc.
В идеале так вообще один класс, который имплементит все нужные интерфейсы и содержит всю реализацию в себе.
Когда логика усложнится, можно и тесты добавить, и подумать над разделением.
Зачем это на десктопе? Чтобы запустить fdisk с дискетки?
Возникает вопрос - зачем современному десктопному CPU режим совместимости не то, чтобы с x86, а даже с реальным режимом x86?
ФГДС отдельно требуется, а стоматолог - нет?
Это включает в себя кучу репортов, обосновывающих необходимость сокращения и невозможность перераспределения сотрудников в другие отделы.
Плюс выплата выходного пособия.
Плюс в странах типа Франции просто безумные меры соцподдержики которые работодатель обязан выполнять
Это сотрудникам кажется, что их просто сократили одним днём.
Было бы интересно, если бы Apple выдала доступ к своему API для сторонних организация для управления своими кредитами. Тогда нативно в телефоне можно увидеть все свои кредиты.
По поводу доступа к финансовым данным - в США и так абсолютно все твои кредиты уходят в кредитные агентства типа Equifax / Experian, тут разве что добавляется Apple
уточнение - начнут с n-мерных многообразий
Скорее всего индийцы работают по контракту, их уволить можно за один месяц без выходного пособия. Сотрудники из ЕС/США оформлены в офис по договору. Увольнение минимум 3 месяца плюс сложные долгие процедуры сокращения.
Напомнило мета-программирование на шаблонах в Boost
ЕМНИП сложение выполняется за один такт, быстрее уже некуда
Вся математика - это костыль. Изучение целых / вещественных чисел начинается с ввода аксиоматики. Потому что не можем доказать.
А уж если у нас целые числа строятся на наборе правил, в которые мы просто верим , что уж говорить про всё остальное.
Готов поспорить в скором времени мы увидим быструю зарядку по подписке.. Что-то типа $0.5 в месяц (например, под предлогом того, что более быстрая зарядка требует бОльших токов, а это негативно влияет на оборудование и надо чаще ремонтировать электрические сети да и вообще это влияет на глобальное потопление)
Вы из какого года это пишете?
Ну это спорно, смотря какая отрасль. Прикладные науки изначально заточены были на освоение большого объёма знаний, теоретические - под многолетние исследовательские труды. Гуманитарные науки, МГИМО и прочее - да, под связи.
Сейчас, на мой взгляд, тенденция такая, как я описал до этого. Судя по тому, что половина комментариев в стиле "плохие лекции", "препод ниочём", "плохо учат" - у многих есть проблема в понимании этого.
Образование, если не говорить про узковысокотехнологичные отрасли, по большей части стало местом генерации нужных связей.
Надо ждать S99 (или какое-нибудь другое сакральное число). Всё будут ждать от S100 чего-то принципиально нового амазинг.
А серьёзно, что принципиального нового можно ожидать от смартфона в 2023? Всякие камеры/экраны упираются в текущие технологические возможности. Всё, что можно улучшить - только софтом.
Мы так в ГУАПе писали лабы в эмуляторе pdp-11. Сначала пишешь на асме, потом вручную по табличке переводишь в хекс коды, потом вручную забиваешь байт за байтом.
Ссылку на видео я вам уже привёл, рекомендую посмотреть
Вот пример попроще (взято из википедии):
Я говорил про корень из отрицательных чисел, а вы сейчас пишете про корень из обратного к операции сложения в кольце вычетов. С последним проблем нет. А вот первое (арифметически корень) не существует по определению.
1 и 2 элементы различных числовых множеств с введёнными операциями и аксиоматикой. Например, с операцией умножения.
i не принадлежит этому множеству, но употребляется наравне с этими элементами. Например, можно применять оператор умножения, что технически противоречит определению умножения и ломает кучу определений/теорем.
Так же, как и символ бесконечности.