Вообще протокол чаще зависит от хостинга или настройки сервера. Обычно запросы не приходят напрямую в node js. То есть node может даже сервить даже http 1 и не факт, что так же будет на публичном домейне.
Да, я тоже заметил. В целом мог просто делать фильтр по k совпадениям на каждом шагу. Хотя не знаю всегда будет не хуже 10 шагов или нет. Худший случай, который я видел, это когда 3 слота имеют одинаковые значения, а остальные 2 имеют все возможные 10x10 комбинации. Это требует 10 угадываний. В статье вроде и нет строгого доказательства, что алгоритм решит за 10 ходов, для этого надо либо перебирать все варианты (что вероятно нереалистично), либо математически доказать. В принципе задача похожа на мой решатель игры mastermind. Там схожий алгоритм по k совпадениям.
JS язык динамический, значительная часть проблем обусловлена отсутствием многих статических проверок. Зато он невероятно гибкий. Почти то же самое можно сказать и про Python. Я, кстати, написал о некоторых странностях JS.
Вообще многие языки со временем "обрастают мхом", очень сложно создавать идеальные языки программирования. Все равно, то требования меняются / усложняются, то со временем выявляются косяки в проектировании языка. Исправить все это, не сломав совместимость, часто невозможно. Например, та же самая хваленая энтерпрайзская Java страдает проблемой null safety. В Java даже не можем нормально (идиоматически используя оператор ==) сравнивать два числа. Дилемма: либо улучшаем язык, но ломаем совместимость, либо не ломаем, но сохраняем все болезни и костыли. Вот и неудивительно, что теперь Котлин рулит во многих отраслях. Хотя и Котлине уже свои проблемы...
Вот кстати про http запросы, браузеры все ещё поддерживают синхронный XMLHttpRequest, но грозят удалить (оставив только в воркерах), типо это плохо для UX. Хотя я не спорю, что это плохо для UX, но иногда это оправдано. Допустим огромный легаси код, который был написан синхронно, или какая-то функция в библиотеке, где часть логики перенесена в бэкенд. Некоторые фрейморки тоже используют это.
Я думаю нельзя так агрессивно впихать асинхронность и решать все за разработчиков, так как опытные разработчики понимают последствия и компромиссы всех своих решений.
Если используются полифиллы, то некоторые вещи плохо транслируемые, или вообще не транслируемые. Например, Proxy и Map/WeakMap/Set/WeakSet, так как для их полноценной / производительной работы нужна поддержка со стороны движка. Если транслятор будет ругаться из-за таких ES6+ апи, то это проблема. Хотя обычно проблема больше в понимании синтаксиса в устаревших системах сборки в легаси проектах.
Когда читал заголовок думал это о записи значения внутри поля/подполя объекта, который может быть null / undefined или вообще не существовать. То есть аналог оператора ?. . В PHP что-то подобное есть для массивов, когда не объявлена переменное или поле, но автоматически создаются все необходимые переменная и поля/подполя.
Стоит сказать, что в JS объекты, Map/WeakMap и Set/WeakSet под капотом уже используют хэш таблицы. И работают быстро, поскольку они реализованы нативно. Поэтому вряд ли есть смысл писать свой собственный HashMap, если, конечно, не в целях обучения. А так, остальные алгоритмы пригодятся при больших данных.
Да, я работал на приложениях без этой переусложненной архитектуры, и все нормально со стабильностью и сопровождаемостью кода. Для большинства приложений такой оверинженеринг не нужен. Обычно приложения тонкие клиенты. Для глобального стейт менеджмента (в основном это данные профиля пользователя) использовал InheritedWidget, стейт нет уж и часто меняются, чтобы вызвать серьезные проблемы с производительностью. Если даже и возникнут в некоторых местах, есть и другие механизмы стейт менеджмента, там уже можно отдельно оптимизировать эти "бутылочные горлышки". Но в целом не очень много глобального стейта, большинство инкапсулировано в компонентах, и как раз так легче отлаживать и понять, что пошло не так.
Может быть для некоторых приложений такая сложная архитектура оправдана, но я лично на работе не видел такого проекта. Для многих проектов это больше вреда чем пользы, так как существенно замедляет разработку и повышает порог вхождения. Для всего есть баланс, крайности только вредят.
Те же самые мысли. На работе мне как раз достался такой проект. И даже при небольших изменениях такое впечатление, что больше борешься с архитектурой и хочешь обойти ее. Коллега же только хвалит, типо оно круто, scalable, testable, UI изолированно от "логики" итд. Говорит в каком-то проекте один очень крутой профессиональный флаттер разраб использует его поэтому и мы решили на него перейти. Ну тогда может и Ангуляр приложения писать в таком стиле ради того, чтобы "UI было изолированно от логики"?! Для ~95% приложений вряд ли такая сложность оправдана, она только существенно замедляет разработку и поднимает порог вхождения.
В JS вроде примитивные значения "заварачиваются" в специальный объект (может кто-то объяснит что на самом деле происходит), когда происходит доступ к методу или любму свойству.
Я пробовал это Number.prototype.myFunc = function () {return this} var t = 2 t.myFunc() === t.myFunc() // false
То есть кажется, что каждый раз создается новая обертка. Да и числа могут храниться по-разному, например в массиве движки могут оптимизировать, например так.
Вообще протокол чаще зависит от хостинга или настройки сервера. Обычно запросы не приходят напрямую в node js. То есть node может даже сервить даже http 1 и не факт, что так же будет на публичном домейне.
Скорее mastermind или быки и коровы.
Да, я тоже заметил. В целом мог просто делать фильтр по k совпадениям на каждом шагу. Хотя не знаю всегда будет не хуже 10 шагов или нет. Худший случай, который я видел, это когда 3 слота имеют одинаковые значения, а остальные 2 имеют все возможные 10x10 комбинации. Это требует 10 угадываний. В статье вроде и нет строгого доказательства, что алгоритм решит за 10 ходов, для этого надо либо перебирать все варианты (что вероятно нереалистично), либо математически доказать. В принципе задача похожа на мой решатель игры mastermind. Там схожий алгоритм по k совпадениям.
JS язык динамический, значительная часть проблем обусловлена отсутствием многих статических проверок. Зато он невероятно гибкий. Почти то же самое можно сказать и про Python. Я, кстати, написал о некоторых странностях JS.
Вообще многие языки со временем "обрастают мхом", очень сложно создавать идеальные языки программирования. Все равно, то требования меняются / усложняются, то со временем выявляются косяки в проектировании языка. Исправить все это, не сломав совместимость, часто невозможно. Например, та же самая хваленая энтерпрайзская Java страдает проблемой null safety. В Java даже не можем нормально (идиоматически используя оператор ==) сравнивать два числа. Дилемма: либо улучшаем язык, но ломаем совместимость, либо не ломаем, но сохраняем все болезни и костыли. Вот и неудивительно, что теперь Котлин рулит во многих отраслях. Хотя и Котлине уже свои проблемы...
Вот кстати про http запросы, браузеры все ещё поддерживают синхронный XMLHttpRequest, но грозят удалить (оставив только в воркерах), типо это плохо для UX. Хотя я не спорю, что это плохо для UX, но иногда это оправдано. Допустим огромный легаси код, который был написан синхронно, или какая-то функция в библиотеке, где часть логики перенесена в бэкенд. Некоторые фрейморки тоже используют это.
Я думаю нельзя так агрессивно впихать асинхронность и решать все за разработчиков, так как опытные разработчики понимают последствия и компромиссы всех своих решений.
Если используются полифиллы, то некоторые вещи плохо транслируемые, или вообще не транслируемые. Например, Proxy и Map/WeakMap/Set/WeakSet, так как для их полноценной / производительной работы нужна поддержка со стороны движка. Если транслятор будет ругаться из-за таких ES6+ апи, то это проблема. Хотя обычно проблема больше в понимании синтаксиса в устаревших системах сборки в легаси проектах.
Да. Я думал что-то подобное в JS хотели добавить. Была бы очень годной вещью (аналогом записи optional chaining (?.)).
Не, не про это. В PHP можно написать такое даже если $arr не объявлена
Я думал о схожей фиче в JS.
Когда читал заголовок думал это о записи значения внутри поля/подполя объекта, который может быть null / undefined или вообще не существовать. То есть аналог оператора ?. . В PHP что-то подобное есть для массивов, когда не объявлена переменное или поле, но автоматически создаются все необходимые переменная и поля/подполя.
В JS получилось так:
function findDifferentBinaryString(nums) {return ((nums.map(x => parseInt(x, 2)).find((num, i, arr) => num > 0 && !arr.includes(num - 1)) ?? (1 << nums[0].length)) - 1).toString(2).padStart(nums[0].length, '0');};Моя любимая БД =)
Да, и половина экономики США держится на COBOL.
Стоит сказать, что в JS объекты, Map/WeakMap и Set/WeakSet под капотом уже используют хэш таблицы. И работают быстро, поскольку они реализованы нативно. Поэтому вряд ли есть смысл писать свой собственный HashMap, если, конечно, не в целях обучения. А так, остальные алгоритмы пригодятся при больших данных.
Да, я работал на приложениях без этой переусложненной архитектуры, и все нормально со стабильностью и сопровождаемостью кода. Для большинства приложений такой оверинженеринг не нужен. Обычно приложения тонкие клиенты. Для глобального стейт менеджмента (в основном это данные профиля пользователя) использовал InheritedWidget, стейт нет уж и часто меняются, чтобы вызвать серьезные проблемы с производительностью. Если даже и возникнут в некоторых местах, есть и другие механизмы стейт менеджмента, там уже можно отдельно оптимизировать эти "бутылочные горлышки". Но в целом не очень много глобального стейта, большинство инкапсулировано в компонентах, и как раз так легче отлаживать и понять, что пошло не так.
Может быть для некоторых приложений такая сложная архитектура оправдана, но я лично на работе не видел такого проекта. Для многих проектов это больше вреда чем пользы, так как существенно замедляет разработку и повышает порог вхождения. Для всего есть баланс, крайности только вредят.
Те же самые мысли. На работе мне как раз достался такой проект. И даже при небольших изменениях такое впечатление, что больше борешься с архитектурой и хочешь обойти ее. Коллега же только хвалит, типо оно круто, scalable, testable, UI изолированно от "логики" итд. Говорит в каком-то проекте один очень крутой профессиональный флаттер разраб использует его поэтому и мы решили на него перейти. Ну тогда может и Ангуляр приложения писать в таком стиле ради того, чтобы "UI было изолированно от логики"?! Для ~95% приложений вряд ли такая сложность оправдана, она только существенно замедляет разработку и поднимает порог вхождения.
Не знаю, даже думаю уволиться с этой компании.
Кстати, есть возможность заранее загрузить модули, особенно помогает, когда есть цепочка зависимостей. Не знаю насколько поможет.
В JS вроде примитивные значения "заварачиваются" в специальный объект (может кто-то объяснит что на самом деле происходит), когда происходит доступ к методу или любму свойству.
Я пробовал это
Number.prototype.myFunc = function () {return this}var t = 2
t.myFunc() === t.myFunc() // false
То есть кажется, что каждый раз создается новая обертка.
Да и числа могут храниться по-разному, например в массиве движки могут оптимизировать, например так.
Так по мне семантически это верно. Думаю так легче новичкам объяснять чем заморачивать им такими деталями. Хотя очень полезно такое знать.