верно, эти три строчки будут преобразованы в один и тот же JavaScript
но это будет не тот JavaScript, который бы написал человек. Я взял ваши функции, прогнал через миллиард циклов и скормил TS-транспайлеру, а копию запустил просто как JS. Версия из транспайлера оказалась быстрее за счет оптимизаций — функция не вызывается в цикле, а просто записана как ряд операторов.
Кроме того, const в TS для данных практически всегда означает подстановку этих данных по месту использования, что дает крохотный, но не гарантированный бонус, особенно если константа используется во множестве алгоритмов — так как вызов локальных переменных в функции происходит быстрее, чем обращение к глобальным.
вы подняли хорошую тему. Действительно, TS должен превращаться в аналогичный JS. И все-таки разница в скорости появляется — из-за того, что транспайлер TypeScript пытается оптимизировать производительность кода. Я написал одинаковый код на TS и JS, и первый оказался быстрее. Причина — в инлайнинге функций.
PS: если вам понравился фрагмент про лягушку, то вы должны также узнать, что такое разделение специализаций в зрении характерно именно для лягушек.
У лягушек и подобных животных очень «умные» и высокоспециализированные глаза. Но у человека и других высших животных глаз более тупой сам по себе — он служит только как приемо-передатчик, а распознаванием занимается мозг (а не обслуживающая непосредственно датчики система нервов)
давайте лучше спросим, чего мы ждем, как это измерить (оценить) и тогда быть может, появится понимание, как это делать
на базовом уровне зрение живых существ работает как современные нейронные сети. Есть нейроны, которые участвуют в распознавании границ объектов, есть нейроны, которые участвуют в распознавании прямых линий. Кроме того, есть огромное количество первичных датчиков, которые были открыты очень давно
«Есть, например, поля ганглиозных клеток, которые впервые были обнаружены американским физиологом X. Хартлайном, впоследствии Нобелевским лауреатом. В 1932 г. он исследовал сетчатку лягушки и с удивлением увидел, что каждое волоконце в ее зрительном нерве несет сигналы не от одного фоторецептора, а от нескольких. Одни «линии связи» передавали сигналы, когда на подключенное к ним поле падал свет. Другие, наоборот, когда освещение сменялось тьмою.» (с) книга "Как мы видим то, что мы видим" Вячеслав Демидов
При этом есть куча более высоких слоев, отвечающих за дальнейшую обработку информации от зрения. Вот еще одна цитата из той же книги:
начало цитаты — «А при поражениях теменной коры правого полушария исчезает – из-за потери механизма оценки пространственных отношений между подобразами – возможность «склеивания» из зрительных фрагментов полноценного образа того, что видит глаз. Сами фрагменты человеку видны, а формирование сложных признаков в левом полушарии оказывается ущербным (описание по Меллину, как мы помним, требует «перекачать» в левое полушарие конкретный образ из правого), нет прохода по «дереву признаков» и речевой ответ выглядит случайным, гадательным. «Это гусь», – говорит больной, увидев на картинке, как акробат стоит вверх ногами. Торчащие накрест лыжи превращаются в ножницы, а висящее на длинной ножке яблоко – в кастрюлю.
Речь как таковая не нарушена, однако восприятие страдает грубыми отклонениями от нормы: попытки зрительно представить себе что-либо оканчиваются для пациента неудачей. «Больная, хорошо объяснявшая на словах, как пройти из палаты в лабораторию, не могла запомнить коридор, по которому много раз ходила… Она узнавала комнату не по конкретному пространственному образу – определенному расположению предметов, а лишь по отдельным словесно описываемым признакам (например, лабораторию – по красной папке в стеклянном шкафу, свою палату – по номеру и т.д.)», – фрагменты не сцеплялись в образ.»
— конец цитаты
Ясно, что каждый из этих этапов — это не могучий интеллект, с которым можно беседовать, как с личностью. Но если вы хотите получить сущность, с которым можно беседовать, который может подсказывать, который может сам придумывать новые сущности — в идеале даже программировать по придуманным им ТЗ! — то такую формулировку и следует произнести вслух громко и отчетливо.
При этом следует помнить о «классовом аргументе» — разные категории людей по-разному способны к разным видам интеллектуальной деятельности. Есть риторики, которые задавят любого оппонента в беседе, даже не имея сильного представления об области спора. Есть композиторы, менеджеры, программисты, дизайнеры, архитекторы. Каждая из этих категорий может выдвинуть свои определения «искусственного интеллекта». Гуманитарий скажет — нет, это калькулятор, это не интеллект. А технарь откажет в интеллекте самому гуманитарию.
Шутка. На самом деле я недавно услышал, что в спорах, кто лучше — «гуманитарии» или «технари» — чаще всего участвуют гуманитарии, т.к. это больше их область. Это выглядит как завуалированный комплимент технарям и возможно автор этого тезиса имел в виду именно это. Но сейчас я подумал, а что если и тут работает «классовый аргумент»? В спорах чаще всего участвуют те, кто больше любит общаться и выяснять отношения?
Но по такому тезису — я тоже люблю общаться, как вы видите, следовательно, если это обвинение, то я обвиняю сам себя. Следовательно, я не хочу никого обвинить.
я недавно встречался с таким багом. Его отличие от описанного в статье в том, что он повторяется постоянно и это сразу ломает идею. Такое даже не всегда доходит до внутренних тестеров, не говоря уже о «спеланки-ученых» ))
нет, там что-то более сложно, как правильно заметили выше, сочетание нескольких факторов.
// посмотрите на эти лица 2014 года
// сгенерированные лица от октября 2017 года уже труднее идентифицировать
будет интересно почитать Хабр в 2020 и 2023 году соответственно
думаю, кстати, что уже в 2025 появятся первые хорошие статьи на русском, написанные при помощи нейросетей (не на Хабре, хотя возможно и на нем)
да, в реальности приходится любить большие фреймворки
я не совсем точно выразился, и скорее хотел сказать — «если в фреймворке еще и есть утилиты по работе со строками или массивами, не спешите использовать еще и эту фичу — лучше избегать дополнительных зависимостей».
как пишет Роберт Мартин, авторам фреймворка интересно привязать вас ко всему, им очень интересно, что вы внедрите фреймворк во все слои своей архитектуры и будете зависеть от него во всех областях. Но взамен вы не получите никаких обязательств, ведь автор фреймворка может в любой момент сломать совместимость с обратными версиями и вы будете чертыхаться, переписывая все слои, от админки до работы с базы данными
Особенно няшно смотрятся еще фреймворки, которые до кучи вставляют в себя утилиты для работы со строками, массивами и тд. Поясняю: к примеру, есть такой движок Phaser для разработки игр на HTML5/JS. В нем есть свой набор утилит для работы с массивами, ну там взять выборку, отсортировать и прочее. У меня был очень большой соблазн использовать эти утилиты в блоке логики. К счастью, я воздержался и не зря — скоро вышла третья версия, в которой нахрен были поломаны все совместимости с предыдущей. Я пересел на третью ради плюшек в графическом движке. Но если бы я использовал утилиты для работы с массивами — мне пришлось бы переписывать и логику, и вообще кучу классов, где использовались утилиты из предыдущей версии.
Авторы фреймворков, которые пытаются сделать из себя God framework, словно не осознают, что они создают очень плохой паттерн архитектуры. Фреймворк должен быть модульным, по сути в нем должен соблюдаться принцип единственной ответственности. То есть не берите God framework в работу — наплачетесь потом, когда он сломает совместимость. Берите мелкие, модульные библиотеки, отвечающие за какие-то отдельные области — вью, базы данных, реактивность.
Scratch по сути предлагает те же языковые конструкции, только ты их не набираешь, а перетаскиваешь мышкой.
Пробовал (в конструкторе игр Stencyl), в итоге пошел писать обычный код, т.к. с некоторого момента перетаскивание мышкой сильно начинает тормозить процесс
по книжке Catch me if you can герой путешествовал по всему миру и дурил кучу корпораций — для молодого человека это вполне может казаться супер-жизнью. Просто он не подводил под это идеологическую базу, честно говорил, что любит деньги.
про прекращение производства — игровые автоматы в таком виде все равно были обречены, т.к. на рубеже 90х в стране наконец-то начал закрываться дефицит восьмибитных компьютеров, и уже на их базе было проще собрать систему, а еще проще было — поставить сами компьютеры с массой игр и брать деньги за игру. Кто-нибудь помнит?
Ведь появились же такие компьютерные игровые комнаты на 8битках на вокзалах еще в СССР. В 1988 году я видел платные игровые компьютерные комнаты на железнодорожном вокзале в Риге. Вообще для меня 88 был годом, когда я заметил появление 8-битных компьютеров в магазинах электроники. Стоили они от 500 рублей, то есть намного дороже, чем даже магнитофоны (который мы подбирали и на который семья уже выделила бюджет). Жаль, я не догадался тогда уговорить отца купить компьютер. Правда, без кассетника тогдашний компьютер все равно был бы бесполезен )) Особенно в таежном поселке.
не претендуя на должность, просто хочу обратить внимание на возможный акцент продвижения — для Kotlin намного больше, чем для Java, подходит лозунг "written once run anywhere"
Особенно это относится к ядру «чистой архитектуры», о которой так любят вспоминать. Конкретно — к базовым бизнес-правилам, отвязанным от конкретной платформы. Вот их точно, написав один раз на Kotlin, можно перетаскивать с платформы на платформы, благодаря подключению реализаций на JS, JDK и Native.
Кроме бизнес-правил, уникальных для проекта, таким кроссплатформенным кросс-проектным компонентом будут и библиотеки, отвечающие за что-то, не привязанное к конкретным реализациям — к примеру, математические либы или для работы со строками (валидация, проверка введенного пользователем и тд)
Я собираюсь сделать подобный эксперимент на базе простой мини-игры — сделать ядро логики на Kotlin и подключить его к разным реализациям — на JS, на Java (LibGDX) и Android. Необходимость в таком подходе зреет давно — как только я понял, что Java+LibGDX генерирует быстрые производительные игры для мобилок и десктопа, но слабо производительные версии для web, а JS-фреймворк Phaser наоборот (круто для веб, тормоза и глюки на мобилках). Если получится, напишу об этом на Хабр
Ну что же, впредь мне наука — проверяй гипотезы тщательнее и не спеши писать посты поздно ночью!
но это будет не тот JavaScript, который бы написал человек. Я взял ваши функции, прогнал через миллиард циклов и скормил TS-транспайлеру, а копию запустил просто как JS. Версия из транспайлера оказалась быстрее за счет оптимизаций — функция не вызывается в цикле, а просто записана как ряд операторов.
Кроме того, const в TS для данных практически всегда означает подстановку этих данных по месту использования, что дает крохотный, но не гарантированный бонус, особенно если константа используется во множестве алгоритмов — так как вызов локальных переменных в функции происходит быстрее, чем обращение к глобальным.
Подробности, код и скриншоты — в короткой заметке
habr.com/post/433230
Буду рад, если вы проверите тесты, и убедитесь сами.
У лягушек и подобных животных очень «умные» и высокоспециализированные глаза. Но у человека и других высших животных глаз более тупой сам по себе — он служит только как приемо-передатчик, а распознаванием занимается мозг (а не обслуживающая непосредственно датчики система нервов)
давайте лучше спросим, чего мы ждем, как это измерить (оценить) и тогда быть может, появится понимание, как это делать
на базовом уровне зрение живых существ работает как современные нейронные сети. Есть нейроны, которые участвуют в распознавании границ объектов, есть нейроны, которые участвуют в распознавании прямых линий. Кроме того, есть огромное количество первичных датчиков, которые были открыты очень давно
«Есть, например, поля ганглиозных клеток, которые впервые были обнаружены американским физиологом X. Хартлайном, впоследствии Нобелевским лауреатом. В 1932 г. он исследовал сетчатку лягушки и с удивлением увидел, что каждое волоконце в ее зрительном нерве несет сигналы не от одного фоторецептора, а от нескольких. Одни «линии связи» передавали сигналы, когда на подключенное к ним поле падал свет. Другие, наоборот, когда освещение сменялось тьмою.» (с) книга "Как мы видим то, что мы видим" Вячеслав Демидов
При этом есть куча более высоких слоев, отвечающих за дальнейшую обработку информации от зрения. Вот еще одна цитата из той же книги:
начало цитаты — «А при поражениях теменной коры правого полушария исчезает – из-за потери механизма оценки пространственных отношений между подобразами – возможность «склеивания» из зрительных фрагментов полноценного образа того, что видит глаз. Сами фрагменты человеку видны, а формирование сложных признаков в левом полушарии оказывается ущербным (описание по Меллину, как мы помним, требует «перекачать» в левое полушарие конкретный образ из правого), нет прохода по «дереву признаков» и речевой ответ выглядит случайным, гадательным. «Это гусь», – говорит больной, увидев на картинке, как акробат стоит вверх ногами. Торчащие накрест лыжи превращаются в ножницы, а висящее на длинной ножке яблоко – в кастрюлю.
Речь как таковая не нарушена, однако восприятие страдает грубыми отклонениями от нормы: попытки зрительно представить себе что-либо оканчиваются для пациента неудачей. «Больная, хорошо объяснявшая на словах, как пройти из палаты в лабораторию, не могла запомнить коридор, по которому много раз ходила… Она узнавала комнату не по конкретному пространственному образу – определенному расположению предметов, а лишь по отдельным словесно описываемым признакам (например, лабораторию – по красной папке в стеклянном шкафу, свою палату – по номеру и т.д.)», – фрагменты не сцеплялись в образ.»
— конец цитаты
Ясно, что каждый из этих этапов — это не могучий интеллект, с которым можно беседовать, как с личностью. Но если вы хотите получить сущность, с которым можно беседовать, который может подсказывать, который может сам придумывать новые сущности — в идеале даже программировать по придуманным им ТЗ! — то такую формулировку и следует произнести вслух громко и отчетливо.
При этом следует помнить о «классовом аргументе» — разные категории людей по-разному способны к разным видам интеллектуальной деятельности. Есть риторики, которые задавят любого оппонента в беседе, даже не имея сильного представления об области спора. Есть композиторы, менеджеры, программисты, дизайнеры, архитекторы. Каждая из этих категорий может выдвинуть свои определения «искусственного интеллекта». Гуманитарий скажет — нет, это калькулятор, это не интеллект. А технарь откажет в интеллекте самому гуманитарию.
Шутка. На самом деле я недавно услышал, что в спорах, кто лучше — «гуманитарии» или «технари» — чаще всего участвуют гуманитарии, т.к. это больше их область. Это выглядит как завуалированный комплимент технарям и возможно автор этого тезиса имел в виду именно это. Но сейчас я подумал, а что если и тут работает «классовый аргумент»? В спорах чаще всего участвуют те, кто больше любит общаться и выяснять отношения?
Но по такому тезису — я тоже люблю общаться, как вы видите, следовательно, если это обвинение, то я обвиняю сам себя. Следовательно, я не хочу никого обвинить.
нет, там что-то более сложно, как правильно заметили выше, сочетание нескольких факторов.
// сгенерированные лица от октября 2017 года уже труднее идентифицировать
будет интересно почитать Хабр в 2020 и 2023 году соответственно
думаю, кстати, что уже в 2025 появятся первые хорошие статьи на русском, написанные при помощи нейросетей (не на Хабре, хотя возможно и на нем)
это возможно потому, что блоки внутри if возвращают значение
я не совсем точно выразился, и скорее хотел сказать — «если в фреймворке еще и есть утилиты по работе со строками или массивами, не спешите использовать еще и эту фичу — лучше избегать дополнительных зависимостей».
большое нарушение баланса Силы чувствую я
Особенно няшно смотрятся еще фреймворки, которые до кучи вставляют в себя утилиты для работы со строками, массивами и тд. Поясняю: к примеру, есть такой движок Phaser для разработки игр на HTML5/JS. В нем есть свой набор утилит для работы с массивами, ну там взять выборку, отсортировать и прочее. У меня был очень большой соблазн использовать эти утилиты в блоке логики. К счастью, я воздержался и не зря — скоро вышла третья версия, в которой нахрен были поломаны все совместимости с предыдущей. Я пересел на третью ради плюшек в графическом движке. Но если бы я использовал утилиты для работы с массивами — мне пришлось бы переписывать и логику, и вообще кучу классов, где использовались утилиты из предыдущей версии.
Авторы фреймворков, которые пытаются сделать из себя God framework, словно не осознают, что они создают очень плохой паттерн архитектуры. Фреймворк должен быть модульным, по сути в нем должен соблюдаться принцип единственной ответственности. То есть не берите God framework в работу — наплачетесь потом, когда он сломает совместимость. Берите мелкие, модульные библиотеки, отвечающие за какие-то отдельные области — вью, базы данных, реактивность.
Вот почему, когда ломается коммунистический режим, ломаются и дома юных талантов?
Пробовал (в конструкторе игр Stencyl), в итоге пошел писать обычный код, т.к. с некоторого момента перетаскивание мышкой сильно начинает тормозить процесс
IArticleFullData — это полный аналог IData из предыдущего примера
Ведь появились же такие компьютерные игровые комнаты на 8битках на вокзалах еще в СССР. В 1988 году я видел платные игровые компьютерные комнаты на железнодорожном вокзале в Риге. Вообще для меня 88 был годом, когда я заметил появление 8-битных компьютеров в магазинах электроники. Стоили они от 500 рублей, то есть намного дороже, чем даже магнитофоны (который мы подбирали и на который семья уже выделила бюджет). Жаль, я не догадался тогда уговорить отца купить компьютер. Правда, без кассетника тогдашний компьютер все равно был бы бесполезен )) Особенно в таежном поселке.
Особенно это относится к ядру «чистой архитектуры», о которой так любят вспоминать. Конкретно — к базовым бизнес-правилам, отвязанным от конкретной платформы. Вот их точно, написав один раз на Kotlin, можно перетаскивать с платформы на платформы, благодаря подключению реализаций на JS, JDK и Native.
Кроме бизнес-правил, уникальных для проекта, таким кроссплатформенным кросс-проектным компонентом будут и библиотеки, отвечающие за что-то, не привязанное к конкретным реализациям — к примеру, математические либы или для работы со строками (валидация, проверка введенного пользователем и тд)
Я собираюсь сделать подобный эксперимент на базе простой мини-игры — сделать ядро логики на Kotlin и подключить его к разным реализациям — на JS, на Java (LibGDX) и Android. Необходимость в таком подходе зреет давно — как только я понял, что Java+LibGDX генерирует быстрые производительные игры для мобилок и десктопа, но слабо производительные версии для web, а JS-фреймворк Phaser наоборот (круто для веб, тормоза и глюки на мобилках). Если получится, напишу об этом на Хабр
всегда, когда есть выбор «заставить людей» или «изменить технику» — можно уверенно полагаться только на второе