TheShock
0
Ну это, в целом понятно. Но даже чисто теоретически интересно, как var помогает работать с «неизвестным» типом данных? Это ж не dynamic.

И уж тем более интересно чем отличается получение null в переменную с var в сравнении с получением null в переменную с явным указанием типа.
TheShock
+1
Для выполнения вредоносного кода в поражённой системе требуется всего одна строка кода.

simple.create_pipe("/path/to/target.so")

Что это означает? Что для использования этой уязвимости необходимо запустить код на целевой машине?
TheShock
0
Еще иногда сканеры работают через Самбу
TheShock
+3
Одна строчка кода на LINQ сразу возвращает набор данных, состоящий из 1000 клиентов, вместо перебора 100 000 объектов. Работать одновременно с 1000 значений более эффективно, чем перебирать 100 000.

Предполагаю, что автор в уме себе правильно представляет, но написано довольно мутно и вызывает ощущение: WTF? Грубо говоря, конечно 1000 — более эфективно, но мне надо перебрать все 100 000. Если автор говорил о распаралеливании или еще чем-нибудь, то стоит уточнить.

LINQ для работы с коллекциями. В большинстве случаев тип получаемых данных неизвестен.

Что? Не знаю, у меня в большинстве случаев при использовании Linq результат вполне известен. О чем автор?

В этом случае оператор «var» помогает избежать ошибок при выполнении кода, в случае, если результатом является NULL или неожиданный тип данных.

WTF? Как? Будет ровно тот же NRE при null, а как работать с неожиданным типом данным — вообще слабо представляю. И это какое-то замалчивание ошибки. Как можно использовать var для работы с неизвестным типом данных? Я слаб в C#, объясните мне это, пожалуйста.

public decimal Total {get; protected set;}


В данном случае только сам класс или производные от него классы смогут его использовать

Изменять, а не использовать! А читать (тоже использовать, кстати), могут все. Автор, будьте внимания к формулировкам. Ваша статья просто вводит в заблуждение!
TheShock
0
Вы правы, простите, что ввел в заблуждение)
TheShock
+5
Ожидал хорошей технической статьи. К интервью профессионалы вообще-то готовятся, основные вопросы имеют заранее и могут найти на них хорошие, интересные ответы.
TheShock
+21
Статья называется «Невероятный JavaScript — трюки, недоразумения и необычные возможности», а внутри три банальности, иногда вредных:
* использование ~array.indexOf (сомнительный подход) и contains в качестве замены ему
* использование всякой ереси вроде "~~float" вместо Math.* функций с целью «оптимизации».
* использование yourArray[position] != null как единственно-правильной проверки на неопределенную переменную, конечно, правильно, но на что-то «невероятное» не тянет.

На этом история про JS закончилась и остальные 90% статьи — непонятная вода, где авторы просто пишут что-то абы что-то написать вместо того, чтобы давать какую-то полезную информацию. В итоге напрасно время потеряли:
— Тот, то брал интервью
— Тот, кто давал интервью
— Тот, кто перевел статью
— Все, кто ее прочитали
— Я, пока писал этот комментарий
TheShock
0
Вы думаете я не знаю про DefinitelyTyped? Вот только оно, обычно поддерживается сообществом, не всегда есть, те, что есть не обязательно полные, а те, что полные — не обязательно на последнюю версию. Я уже молчу про всякие беты.

И, обычно, на такое получаешь бредовый ответ из разряда: «ну так помоги сообществу, напиши сам». Напишу, конечно, куда я денусь, но это рак JS, что авторы библиотек не спешат их типизировать и почему это меня не должно возмущать?

Я как раз разрабатываю на React и TS, так что прекрасно знаю «состояние сообщества».
TheShock
0
И часто вы видите типизированный код в мире JS? Я как раз TS очень даже пользуюсь. Да вот только хипстеры, которые пишут add(1)(2) обычно считают типизацию порождением сатаны.
TheShock
0
Недостаточно, потому что встречая в коде func(a)(b) ты не будешь знать — это уже итоговое значение, или всё ещё функция, которая ждет недостающий аргумент
TheShock
–2
Та я ж тут чисто достаю всех, а сам даже FizzBuzz не напишу)

Ты предлагаешь такую функцию написать в императивном стиле с умершим for?
TheShock
–3
А пример из Рамбды, когда выходит после N элементов, ума которых больше 20?
TheShock
+1
и совсем нехороша: через пару месяцев, взглянув на нее, сможете ли вы с ходу сказать, что inc — функция?

А вы правда думаете, что люди, которые пишут такой код — поддерживают его целых два месяца?
TheShock
0
А еще можно поставить бряку и увидеть, какой результат в него записался.
TheShock
–1
Возможно, я ошибся с первопричинной и основная нагрузка — создание и наполнение новых массивов на каждой итерации, а не вызов функции?
TheShock
0
Это нативный код без фреймворков. Но если вы хотите — можете протестировать и фреймворки)
TheShock
0
Согласен. Ожидаемо, корректно и так, как должно быть. Я рад, что теперь знаю это наверняка))
TheShock
0


Если присмотрется (иногда, правда, зависит от монитора), то можно увидеть 15 «ступенек» идущих слева направо. Это довольно известный художникам факт, и у Лебедева было.

На самом деле даже на скриншоте с Юнити (без постобработки) видно:


Именно по этой лесенке потом изменяется яркость. То есть 256 градаций, обычно, достаточно (особенно если есть текстура — их вообще не заметить), но иногда вылезают такие неприятные лесенки, потому что в целом переход с (128) на (129) глазом заметить можно.
TheShock
0
8 бит на цвет — заглаза

И кстати, к сожалению, 8 бит на цвет — это таки маловато. Иногда на объектах без текстур становятся заметны лесенки. Именно потому в фотошопе используется или дизеринг на градиенте или 16 бит на цвет. Вот тогда точно достаточно)
TheShock
+1
Решил проверить на практике, как в Unity работает HDR+Tonemapping (простите, что в теме про Анрил). Создал сцену, где есть очень легкий градиент с лесенкой, создаваемый светом:



Теперь tonemapping-ом добавляю контрасности. Без HDR изменения происходят именно по границе старого градиента, то есть все — эта форма навеки и переход может быть только более заметен


Вот результат с включенным HDR и теми же найстройками ToneMapping:


Видно, что HDR отвечает не только за значения больше 1, но и добавляет огромное количество между 0 и 1.
TheShock
0
Очень темная сцена, в итоге используется только часть диапазона и потом он растягивается до полного, во время tone mapping

Да!

да, не будет с этим проблем. там же float. у него либо маленькое точное значение, либо большое не точное.

Окей, просто в большинстве статтей указывается только на то, что hdr отвечает за значения больше 1, но нигде я не видел явного указания, что увеличивается количество градаций между 0 и 1.
TheShock
0
Для пост-обработки ведь. Если я работаю в линейном пространстве — необходимо потом расширять темные участки. И вот у меня первые 16 градаций растянутся на все 128.

Так что я искренне надеюсь, что HDR не только расширяет, но и уточняет.
TheShock
0
Я правильно понимаю, что в HDR не только значения больше 1 могут быть, но и градаций между 0 и 1 — значительно больше? И так в т.ч. в Unity?
TheShock
+3
У автора талант из нормального кода писать неподдерживаемое говнище. Кто еще не заходил — вам загадка. Что делает эта функция и как она могла бы быть названа? Только засеките время на разгадывание этого ребуса.

const FUNC_NAME = (limit, predicate, list, i = 0, newList = []) => {
    const isDone = limit <= 0 || i >= list.length
    const isMatch = isDone ? undefined : predicate(list[i])
  
    return isDone  ? newList :
           isMatch ? FUNC_NAME(limit - 1, predicate, list, i + 1, [...newList, list[i]])
                   : FUNC_NAME(limit, predicate, list, i + 1, newList)
}


А потом сравните с промышленным, а не хипстерским кодом:

Скрытый текст
const FUNC_NAME = (limit, predicate, list) => {
  const newList = []
  
  for (var i = 0; i < list.length; i++) {
    if (predicate(list[i])) {
      newList.push(list[i])
  
      if (newList.length >= limit) {
        break
      }
    }
  }
  
  return newList
}
TheShock
0
В таком случае пробелы — лучше.

В таком случае лучше другие разработчики, а не пробелы. Это вроде «не всегда можно научить мастера не стучать молотком по машине, потому у нас всегда резиновые молотки, пусть ими гвозди забивают».
TheShock
0
Давно пора перевести браузеры на Lua.

Это полумера ;)
TheShock
0
Две физически разных страницы для фп-стиля и классического, результат — тот же, разница в сто раз, проверьте сами.

TheShock
–1
Ну выше есть и в консоли и в jsperf. И там, и там одинаковый результат. Можете еще на jsfiddle попробовать. Тот же результат будет
TheShock
0
Предполагаю, что вы где-то прочитали и запомнили некорректную информацию. Я выше показал, что в JS все очень однозначно.
TheShock
0
Дааамс. Пока легче руками развернуть)
TheShock
0
21 очко на колоде карт?

Объясните
TheShock
–1
Симпатично.

К сожалению, я знаком с такой штукой для Java, которую они добавили в восьмой версии.

Почему «К сожалению»?
TheShock
–1
<Target backgroundColor={this.state.color} {...this.props}/>

Кстати, я такую запись так и не смог нормально типизировать на TS. Как вы это разруливаете?
TheShock
+2
Простите, в fp-варианте количество прогонов в три раза больше, чем в классическом варианте, а не в сто раз.

Я лишь стараюсь убедить, что утверждение ложно:
Код в примере использует map и filter, вместо одного for, вероятно, что он работает в 2 раза медленнее.

Основной источник увеличения нагрузки не три цикла for вместо одного (это как раз совершенно не страшно), а «три тяжеловесных вызова функции + три операции» вместо «три операции» на каждую итерацию. То есть у нас сам вызов функции занимает в сто раз больше времени, чем операция, которую эта функция выполняет.

И это особенность именно JS, а не FP в целом.
TheShock
0
Хорошо, давайте обсудим ваше условие — «нужно найти первый такой элемент в цикле». Ну или «найти максимум 5 элементов, удовлетворяющих результатам поиска».

В случае, если ФП сделано правильно

А если ФП у нас JS?
TheShock
+2
А если брейк по результатам вычисления, а не до результатов?
TheShock
+2
Как скажете. Получилось… разница в 100 раз. Увеличил число, чтобы было видно, что количество цифр одинаковое и уж слишком мало получалось в классическом варианте:
TheShock
0
Потому что кроме самой операции (каждая итерации очень дешевая) допольнительно происходит вызов функции, который очень тяжелый. В браузерах это проявляется точно так же, см. выше.
TheShock
+8
Да, вы правы, кто меня минусует. Я ошибся с порядком. Не на порядок, а на два порядка, то есть в сто раз. Функциональный вариант ровно в сто раз медленнее, чем классический: