• ИИ научился создавать видео с одного кадра. Старые картины теперь можно сделать живыми
    0
    Я уже давно и много мечтаю об этом. Но тут есть проблема: вы откроете фильм, а там персонаж выглядит совсем не так, как вы представляли. И вообще у него усы (ну а что, автор же не говорил, что усов нет, а сети показалось, что они тут логичны).
    Так что рисовать персонажей руками и анимировать затем их — гораздо лучше.
  • ИИ научился создавать видео с одного кадра. Старые картины теперь можно сделать живыми
    +1
    А, так-то да, не спорю. Но, весьма вероятно, в будущем можно будет вбухивать туда сразу много разных кадров или куски видео. С умершим 100 лет назад предком, от которого одно фото, положим, так не получится, но большинство остальных реквестов вполне.
  • Нужно ли чистить строки в JavaScript?
    –1
    Имхо, это мелочи, которые не доставляют никаких проблем. А возвращать undefined на несуществующий ключ объекта это и вовсе полностью валидная логика, что с ней не так? о_О
  • ИИ научился создавать видео с одного кадра. Старые картины теперь можно сделать живыми
    0
    Со временем качество будет становиться всё лучше и лучше.
  • ИИ научился создавать видео с одного кадра. Старые картины теперь можно сделать живыми
    +4
    Довольно скоро можно будет создавать мультфильмы, анимируя каждого персонажа из одного-единственного рисунка.
  • Нужно ли чистить строки в JavaScript?
    +1
    То есть попытка сделать из JS нечто подобное статически типизированному языку — только медленее и с большим расходом памяти.

    Можно подробнее? Откуда у вас взялась такая интересная неправильная информация, что TS медленнее и больше ест памяти, чем JS?
  • Нужно ли чистить строки в JavaScript?
    +2
    Очень много вещей, который в C++ просто не пропустит компилятор в JS породят… нечто
    Ровно и наоборот. Напишите #define true false, и у вас это благополучно скомпилируется.
    Скажете, такой код сознательно не напишешь? Я тоже сознательно не пишу {} - [], ну ничего себе :)

    Конечно. Чем больше «странного» и «дурацкого» кода является валидным и как-то работает и что-то таки делает — тем сложнее попасть в узкое подмножество «хорошего» кода…
    Опять киваю на дефайн. И миллион других возможностей выстрелить в себе ногу, например, переопределение операторов.

    На самом деле нет, скажу совершенно непопулярное мнение: да, js очень гибкий, и я считаю это плюсом. В моём опыте было море случаев, когда это спасало. Чаще в целях отладки, конечно (например, чтобы посмотреть, что делает библиотека на канвасе, не копаясь долго в её коде, можно руками переопределить прототип CanvasRenderingContext2D, встроив туда логгирование), хотя однажды залезающий в приватные поля чужого прототипа код даже думали выкатить в прод, потому что это был просто единственный вариант.
    Но я не говорю, что такое должно оказываться в продакшене и вообще в коде. Это скорее дополнительная возможность, которая иногда облегчает жизнь — как тот же самый дефайн у плюсовых разработчиков. А чтобы писать именно для продакшена именно хороший код, у нас есть многочисленные правила и многочисленные линтеры включая тайпскрипт (который по сути тоже продвинутый линтер).

    И я понимаю, почему это плохо. Привычная функция может оказаться работающей непривычно (опять киваю на дефайн), или же просто логика одного объекта будет раскидана по всему проекту, по разным модулям, и её сложно будет собрать в одно. Но, кажется, это более общая проблема, проблема организации проекта и т.п.: в любом языке я могу раскидать класс и его методы по всему проекту, и будет непонятная запутанная схема. Никакой возможности переопределять прототипы Number мне для этого не нужно.
  • Нужно ли чистить строки в JavaScript?
    0
    Но все эти оптимизации всё равно не позволяют достичь скорость написанной на статически типизированном язуке — однако требуют кучу дополнительных ресурсов.

    Странный аргумент. Давайте писать на ассемблере, раз нам важна в первую очередь скорость.
    К слову, программисты гугла считают иначе, и ровно по этой причине они не захотели поддерживать asm.js

    А вот версия, в которой за последние лет 10 перенесли кучу всего с C++ на JavaScript — совсем другое дело.

    Аргумент был бы валиден если бы это было единственное, что изменилось в движке за 10 лет. Но нет, как вы понимаете, там хренова туча всего.

    Высоконагруженные сервера (сотни тысяч и миллионы QPS) до сих пор пишут на C++. На js пишут сервера, при создании которых хочется использовать армию дешёвых JS-программистов — а потом начинаются приседания, когда оказывается, что железо-то всё-таки небесплатное…

    И на плюсах тоже пишут. Например, все сообщения в вк на сервере, кажется, работают на ноде. Попробуйте сказать, что это малонагруженный сервис.
    Что касается армии дешёвых js-программистов: а у вас есть какие-то достоверные данные, что всё происходит именно так, и что js-программисты дешевле остальных? Вы говорите так, будто претендуете на объективность, но при этом само мнение звучит как нечто очень сомнительное, как мнение совершенно поверхностно разбирающегося человека.
  • Восстановление циркуляции в мозге через несколько часов после смерти
    0
    Не могу не спросить, а обратная градация есть? Пусть не в жизни, но хотя бы в теории есть идеи, как будет выглядеть человек, по сравнению с которым обычный человек по уму — как ребёнок?
  • Как подружить латекс, формулы и Хабр?
    +2
    Долго-долго ждали латех на хабре, пилили разные свои решения, а в итоге пришли опять к картинкам.
  • Нужно ли чистить строки в JavaScript?
    +1
    Допустим, но как вы докажете, что большинство проектов на js едят много памяти и тормозят? :) По моим данным, всё совершенно наоборот — на js пишут высоконагруженные штуки вроде сервера сообщений вк, и вообще js наверное самый оптимизированный из динамически типизированных интерпретируемых языков.
    И более того, если у вас кушает много памяти что-то в браузере или в electron — почему вы уверены, что проблема в языке, а не в том самом Chrome, который вообще-то известен своей прожорливостью? К слову, на чём он там написан, на плюсах? Давайте ругать плюсы за прожорливость хрома и гмейла в частности).

    ANSYS, кажется, и памяти ел больше, чем хром в брачный период. Но я точно не скажу, это было давно и в страшном сне.

    Про Lua совершенно очевидно напрашивается вывод: это трейдофф память -> скорость. Разработчики V8, вероятно, решили, что работать быстро важнее, чем есть мало памяти. Это мои домыслы, но тем не менее. И высоконагруженные сервера пишут не на требующем малых ресурсов Lua, а, как ни странно, на js.
  • Нужно ли чистить строки в JavaScript?
    0
    Классика. Говорить, что язык объективно плохой, за то, что некоторые пишут на нём плохой код :)

    Это вообще ооооочень странно — выдавать медлительность Gmail / Slack за аргумент, почему js плохой. Я вот работал с ANSYS, такой очень распространённый инженерный софт. Он умеет подвисать на минуту при right-click (нет, там точно не нужны сложные расчёты чтобы открыть контекстное меню с тремя пунктами) и тому подобных действиях. А ведь он написан, кажется, на C++. На сильно статически типизированном! И даже без Qt и т.п. штук.

    Почему Slack или Gmail столько кушает — я не знаю. Правда. Всё, что я когда-либо писал, в принципе не могло столько есть. Я серьёзно не представляю, как можно написать такой простой интерфейс очень тяжёлым.

    Вот это всё, надеюсь, проиллюстрирует то, что я хочу сказать.

    Ну а про сторонников — нет, просто вы говорите про наличие критических всем мешающих недостатков как про что-то объективное, и с чем никто не спорит, мне интересно, что именно вы имеете в виду :). И одно дело если с этим не согласны два с половиной джуниора, другое — много процентов разработчиков.
  • Нужно ли чистить строки в JavaScript?
    0
    Я разумеется не имею в виду, что все 100% разработчиков должны быть согласны, а какой-нибудь несогласный стажёр всё ломает. Я имею в виду, что не нужно выдавать субъективность за объективность, а открытые вопросы за решённые. Вы не можете выдать за объективную истину «пробелы лучше табов» или «статическая типизация лучше динамической» или «прототипы лучше классов», потому что примерно 50% (или 30% или 20% или 10%) с вами не согласятся, и однозначного ответа, почему одно лучше другого, не найдено.

    количество попыток прикрутить в JavaScript'у статическую типизацию показываает, что режим тяп-ляп-и-в-продакшн уже многих не устраивает

    Ага, а количество попыток затащить JS на сервер показывает, что все остальные серверные языки уже многих не устраивают.

    Ничего это не показывает. Только количество разработчиков, которые попытались пересесть со статически типизированных языков на js, и ощутили, что им не нравится писать без типов. Это даже легко доказать: если человек изучает программирование начиная с js, ему и в голову не придёт тащить в него типы :)
  • Нужно ли чистить строки в JavaScript?
    0
    Запишем в не очень мешающее жить решение.
    Я спросил, что (очень мешает жить) && (все согласны, что это плохо).
  • Нужно ли чистить строки в JavaScript?
    +1
    Когда забываешь слово var? Кажется, за всё, вообще всё время это ни разу ничего у меня не ломало :). Более того, такие штуки видно сразу, а если в вашем коде видно их не сразу, например, двадцать вложенных функций каждая со своими локальными переменными, то у вас в любом случае проблемы.
    Нет, я согласен, что есть море неудачных решений, которые при определённых обстоятельствах делают всё плохо, но кажется, что это вот примерно настолько же плохо, как typeof null.
  • Нужно ли чистить строки в JavaScript?
    0
    А какие есть неудачные решения есть в JavaScript, которые однозначно всем сильно мешают жить, и все однозначно согласны, что они плохие и лучше бы их не было?

    Например, typeof null на практике сильно не мешает, а прототипы или динамическая типизация — вы не сможете сказать, что все разработчики однозначно против.
  • Stadia — революция в игровой индустрии?
    –3
    Всего лишь десятая секунды
  • Парадоксы о сжатии данных
    0
    О, я понял. Мы не можем за конечное время вычислить то самое минимальное число.
    Спасибо)
  • GitHub полностью «удалил» репозиторий утилиты для обхода блокировок и весь аккаунт создателя
    0
    Очень знакомый ник. ValdikSS
  • Парадоксы о сжатии данных
    0
    Хмм, а почему нельзя произвольную программу разбить на атомарные операции? Давайте возьмём машину Тьюринга, там атомарные операции вполне очевидны, и программа разбивается на них просто по определению. Нет?

    Возможно, я сейчас спрашиваю о каких-то банальных вещах, которые рассказывают в институте на Computer Science, но я, к сожалению, учился на немного другом направлении.
  • Парадоксы о сжатии данных
    0
    Или не завершится? Ведь среди всех программ, которые будут испробованы, встретится while True: pass (и её функциональные аналоги) — и дальше проверки такой программы дело уже не пойдёт!

    Вообще не обязательно.
    Давайте сделаем так: разобьём каждую программу на некие атомарные операции и сделаем очередь программ. Затем будем каждую итерацию добавлять в список следующую программу и исполнять по одной атомарной итерации из каждой программы списка.
    Таким образом, любая программа будет запущена через некоторое конечное время.

    (что конечно же не сработает на практике, но ведь мы не об этом говорим?)
  • Вы не сможете решить эту задачу на собеседовании
    +30
    Если у вас есть массив из 4 элементов, и вы по кнопке его сортируете, то сортируйте хоть перебором, 24 перестановки комп переберёт почти так же быстро, как и отсортирует пузырьком. Место не критичное.

    Медленно работающий гмейл — это результат того, что плохой код в критичном месте, понимаете? Критичные места — это то, что нужно оптимизировать.
  • Вы не сможете решить эту задачу на собеседовании
    +19
    Если вы хороший разработчик, вы оптимизируете правильные места.

    Это поиск баланса между читаемостью и эффективностью. Если вам нужно реверснуть небольшую строку, то сплит-реверс-джоин работает так же быстро, как и что угодно ещё — там разница на уровне пары миллисекунд. При этом смысл кода понимается беглым взглядом, меньше, чем за секунду. Давайте напишем цикл:
    var str = '12345';
    var reversed = '';
    var l = str.length;
    while(l--){
     reversed += str[l];
    }
    

    — и чтобы понять, что делает этот код, понадобится секунд 5.

    И так везде. Если вы пишете очень критичное место (вроде сравнения v-dom в таблице на миллион пунктов), то да, его нужно оптимизировать всеми силами и средствами, потому что какая–нибудь мелочь может привести к разницы в полсекунды. Если разницы нет, то и смысла нет — выбирайте, что читаемее.
  • 12 приемов работы с JavaScript, которых нет в большинстве туториалов
    0
    Ну тут всё просто.

    Во-первых, хаки с ~indexOf, ~~ и |0 действительно удобны когда ты пишешь код на коленке, или тебе нужно например по-быстрому что-то проверить или что-нибудь такое. Вставить в конец |0 гораааздо быстрее и проще, чем писать Math.floor(, затем переносить кусок в конец кода и ставить ). И |0 это одна из самых удобных вещей, что я вообще использую когда пишу код по-быстрому на коленке для себя :)
    Это случай, когда над кодом работаешь только ты, и всё в нём понимаешь, хочу заметить.

    Во-вторых, на самом деле писать !!value или +value или value|0 вместо Boolean(value) / Number(value) / Math.floor(value) совсем не ухудшает читаемость если ты знаешь, что это. Думаю, что про !!value, +value и value + '' знают примерно все, а вот использовать |0 в каком-то реальном коде естественно содержит много минусов вроде того, что тебе придётся предупреждать всех читающих код, что такие конструкции значат.
  • 12 приемов работы с JavaScript, которых нет в большинстве туториалов
    0
    ({toString: () => []}) + ''

    Кинет ошибку
  • 12 приемов работы с JavaScript, которых нет в большинстве туториалов
    0
    Вместо forEach можно юзать some и every, они брейкаются возвращением true / false. Но в остальном согласен.
  • Семь мифов в области исследований машинного обучения
    +2
    Миф 1: TensorFlow – это библиотека для работы с тензорами
    На самом деле, это библиотека для работы с матрицами, и эта разница весьма существенна.

    Матрица — это тензор, частный случай
  • 20 привычек для гигиены внимания: как пользоваться технологиями, но не позволять им отбирать свое время и внимание
    –1
    А что же делать с привычкой в любую свободную минутку проверить, не написал ли тебе кто-нибудь?
  • Каждый может с легкостью выучить английский язык
    0
    Согласен с ответом wearethevoid выше. Да, именно так, другой язык — другое мышление, прямого соответствия нет.

    Если хотите примеров, то вот что-то такое например:
    — Когда ты завтра придёшь, я могу в этот момент быть перепачкан в краске
    — Почему?
    — К моменту твоего прихода я буду уже некоторое время рисовать

    Но я бы сказал, что вот эта вот табличка из 12 времён — это неудачная попытка формализовать язык. Люди просто общаются, иногда объединяя конструкции will, have, be, это просто несколько часто используемых выражений вместе, а потом кто-то пришёл и сказал «давайте каждую такую комбинацию считать отдельным tense». Вот вам и все возможные комбинации, 12 штук
    Ещё типичнейший пример это Future in the Past, которое зачем-то отдельное время, хотя на самом деле это просто использовали глагол will в прошедшем. «Я ему сказал, что я буду рисовать» — «I told him I would draw». А некоторые таблички ещё выделяют be going to и разные модальные глаголы как отдельные tense, ещё прибавляют сюда пассивы, и времён становится чуть ли не под полсотни.
  • Изучение английского: a geeky way
    0
    Да, видел что-то подобное.
    Ээ, а что сложного в пассиве? Он отличненько существует и в русском ведь. И построение вроде тоже долго объяснять не нужно, все пассивы строятся как be + Ving в активе
  • Каждый может с легкостью выучить английский язык
    0
    Здесь тоже море стереотипов, только с обратной стороны. Увы, возводить этот подход в абсолют тоже ни к чему хорошему не приводит, на своём опыте знаю.

    Типичнейший стереотип — про детей или вот это вот:
    Future Perfect Continuous (я сам не имею ни малейшего понятия, как оно строится),

    Вы ведь поймёте, если я скажу I will have been painting, верно? Более того, в определённой ситуации вы и сами сможете такое составить. Потому что есть своя внутренняя взаимосвязь между словами will, have, be, -ing, свой смысл, который они составляют вместе, и вы можете не иметь никакого понятия, что это называется Future Perfect Continuous, но запросто понимать и даже строить такие конструкции.
  • Изучение английского: a geeky way
    0
    Я в общем-то всё перечисленное и называл результатом. Ещё он бывает косвенный, это Perfect Continuous.

    Интересно, расскажите
  • «ВКонтакте» выпустил мессенджер для ПК, очень похожий на Telegram
    +19
    верить Mail.ru
    Ха-ха.
  • «Черное зеркало» или реклама Picooc?
    0
    Для кого лучше, рекламодателя или зрителя?
  • Объясняем код с помощью ASCII-арта
    0
    --MEOW--/>  フ
         |  _  _|
         /`ミ _x 彡
         /      |
        /  ヽ   ノ
     / ̄|   | | |
     | ( ̄ヽ__ヽ_)_)
     \二つ
  • Корпоративный туалет
    +1
    Последние полгода хожу со свободными 5-10 мегабайтами на телефоне, всё реалистично
  • Перевод политкорректной лексики с английского на русский
    +1
    Только «причём» слитно
  • Redux. Простой как грабли
    0
    Точно так же изучал в своё время redux — просто прочитав исходники и написав свою совместимую версию на ts github.com/keyten/redux-ts/blob/master/index.ts

    Только вот жаль, это не очень прояснило обычные паттерны его использования.
  • Двенадцать способов понять, что находишься в виртуальной реальности
    –2
    А если кубик будет с миллионом граней, такой шанс будет гораздо меньше.
  • 3blue1brown и MIT на русском
    0
    А почему не смотреть английский вариант намеренно? :)