Добрый день. Прошу прощения за некропостинг, но сегодня мне пришел чек на 50 рублей от Газпром межрегионгаз Пермь.
Суть в том, что я в РФ был последний раз более года назад, а имущества там не имел никогда. И да, жил я в Перми. Т.е. с газпромом не имел дел вобще никаких. И тоже авансовый платеж
Для этого есть финты в виде every и some...Но все равно это кривость...
Я, когда на сайте реакта читал о хуках и для чего они их сделали, жестко приуныл и уже тогда начать думать куда мылить лыжи из фронтенда: ползти в бакенд или уходить в С++ софт/игры...
Соглашусь с вами: очень много людей думает, что они так копируют объект. Сколько уже исправлений этого мной написано - не пересчитать.
Я пришёл в js из софта, потому такие ошибки часто бросаются в глаза.
forEach недолюбливаю за невозможность остановки по break. Понятно, что есть every или some, но, как показывает практика, многие с такой конструкцией не знакомы
С вами я тоже полностью соглашусь.
Организация управления в голанге или Си\Си++ требует более высокого управления очереди исполнения на основе той же многопоточности (мьютексы, потоки, каналы, атомарность и т.д.).
Однако определенная «правильная» архитектура кода не всегда решает в виде исполнения, поскольку поток исполнения не настолько контролируемый в JS, поэтому и появились все эти недокостыли в виде Promise и setTimeout. Как таковая, по сути, многопоточность отсутствует, ну существует жесткая асинхронность, которая порождает проблемы той же race condition, что и приводит нас к данному результату.
По сути, той же фигни можно достигнуть на том же голанге — суть именно в архитектуре. И тут мы приходим к тому, что даже неожиданное говно можно получить на любом языке.
P.S.: мне пришлось внедрить систему lock/unclock для того, чтобы освобождать/блокировать поток исполнения определенной функции. Более того, эта проблема даже в виде 2 инстансов на один код, тут пришлось добавлять код в виде
Где система синхронизации может одновременно сохранять только один контракт, потому что делает пересчет структуры. А фишка в том, что пользователь может параллельно делать изменения, т.е. его следующее изменение должно быть вызвано после завершения функции.
Я бы, конечно, реализовал это по другому, но суть такова.
Да в любом месте, где реализуется более одной функции операции и участвуют хоть чуток промисы и setTimeout можно получить неуправляемый код, который будет менять и перебивать очередь исполнения как захочет.
Даже из недавнего: обнаружил баг в интерпретаторе javascript для react.native, когда два вызова вобще работали в одном scope.
А то, что вы описали в обычных языках решается простыми атомарными операциями.
У вас просто нормального race condition в js не было.
Просто внутри функции test должно быть не один x=x+1 а несколько вызовов функций и т.д. И в этот момент начинается гонка вызовов
Я соглашусь с вами только в одном: принцип — никогда не доверяй входящим переменным. Только это всегда защищало мой код от всех вмешательств. Да, тесты избегали изменения функции, но также можно поменять и тесты (как и функцию — довольно часто это наблюдаю в бизнес разработке). Если поддерживать принцип «не доверяй входящим переменным» в рамках функции (и возврату из других), то все сразу становится на свои места и код становится нереально чистым и читабельным. И это сразу покрывает тесты и документацию (потому что стараешься чтобы код не был монструозным). Итого код защищен, а тесты чаще для того, чтобы было
На самом деле есть и у растений и у животных, как логика, так и сознание. Просто они есть в тех рамках, которые нужны им для существования и полностью не схожы с человеческими
А насчет очеловечивания: давая животным права, давайте и обязанности.
Есть знакомая веганка. О том, что она веганка я узнал случайно через месяц, когда мы обсуждали аллергии и она узнала, что у мня аллергия на курицу: Тебе самое то быть вегетарианцем.
Сказал, что не потяну и они часто агрессивные, на что она ответила, что вроде нет, т.к. она такая. Вот так и ухнал.
Ага, я включил двухфакторную авторизацию и Gmail не мог собрать почту (mail.ru требовал вход через браузер). Отключил — сразу научился.
В итоге плюнул — все самое важное уже давно перенес на gmail. mail.ru как история того, чего делать не надо)
Добрый день. Прошу прощения за некропостинг, но сегодня мне пришел чек на 50 рублей от Газпром межрегионгаз Пермь.
Суть в том, что я в РФ был последний раз более года назад, а имущества там не имел никогда. И да, жил я в Перми. Т.е. с газпромом не имел дел вобще никаких. И тоже авансовый платеж
Короче, половина бонусов и половина зарплаты. Почти наполовину в Польше
это не я предлагаю, а они.
Для этого есть финты в виде every и some...Но все равно это кривость...
Я, когда на сайте реакта читал о хуках и для чего они их сделали, жестко приуныл и уже тогда начать думать куда мылить лыжи из фронтенда: ползти в бакенд или уходить в С++ софт/игры...
Соглашусь с вами: очень много людей думает, что они так копируют объект. Сколько уже исправлений этого мной написано - не пересчитать.
Я пришёл в js из софта, потому такие ошибки часто бросаются в глаза.
forEach недолюбливаю за невозможность остановки по break. Понятно, что есть every или some, но, как показывает практика, многие с такой конструкцией не знакомы
Дайте пруф пожалуйста
Обожаю эти пункты «он должен хотеть в нашу компанию не ради денег». Ребят, у меня 10+ лет опыта. На работу я хожу зарабатывать деньги
Еще один…
Организация управления в голанге или Си\Си++ требует более высокого управления очереди исполнения на основе той же многопоточности (мьютексы, потоки, каналы, атомарность и т.д.).
Однако определенная «правильная» архитектура кода не всегда решает в виде исполнения, поскольку поток исполнения не настолько контролируемый в JS, поэтому и появились все эти недокостыли в виде Promise и setTimeout. Как таковая, по сути, многопоточность отсутствует, ну существует жесткая асинхронность, которая порождает проблемы той же race condition, что и приводит нас к данному результату.
По сути, той же фигни можно достигнуть на том же голанге — суть именно в архитектуре. И тут мы приходим к тому, что даже неожиданное говно можно получить на любом языке.
P.S.: мне пришлось внедрить систему lock/unclock для того, чтобы освобождать/блокировать поток исполнения определенной функции. Более того, эта проблема даже в виде 2 инстансов на один код, тут пришлось добавлять код в виде (почти передал, но вы поняли)
Где система синхронизации может одновременно сохранять только один контракт, потому что делает пересчет структуры. А фишка в том, что пользователь может параллельно делать изменения, т.е. его следующее изменение должно быть вызвано после завершения функции.
Я бы, конечно, реализовал это по другому, но суть такова.
Да в любом месте, где реализуется более одной функции операции и участвуют хоть чуток промисы и setTimeout можно получить неуправляемый код, который будет менять и перебивать очередь исполнения как захочет.
Даже из недавнего: обнаружил баг в интерпретаторе javascript для react.native, когда два вызова вобще работали в одном scope.
А то, что вы описали в обычных языках решается простыми атомарными операциями.
Просто внутри функции test должно быть не один x=x+1 а несколько вызовов функций и т.д. И в этот момент начинается гонка вызовов
А насчет очеловечивания: давая животным права, давайте и обязанности.
Сказал, что не потяну и они часто агрессивные, на что она ответила, что вроде нет, т.к. она такая. Вот так и ухнал.
В итоге плюнул — все самое важное уже давно перенес на gmail. mail.ru как история того, чего делать не надо)