Comments 51
П.С. Комментарий без сарказма и попыток оскорбить кого-либо.
Ну что ж… Поздравляю, вы освоили основы ООП ссылочного типа.
Во всём этом смущают теги. high performance? Perfect code? Вы уверены?
Серия «я познаю мир». По-моему, такому место на medium.
Я не понимаю хабр. За что плюс автору но минус мне? Автор перевёл какую-то дичь но снимает с себя ответственность говоря что это перевод и статья не моя. Всё претензии к источнику. Так не надо переводить такое и тем более постить такой мусор на хабре.
На медиуме намного больше статей в абсолютных числах и попадаются очень даже неплохие, но средний уровень примерно как у этой.
На хабре, конечно, тоже уровень статей неуклонно падает, но пока еще уровня медуима не достиг.
Там недели не проходит, чтобы кто-нибудь не написал очередной гайд по map, filter и reduce
Возможно стоит разделять контент — для новичков, я учусь, для умников и т.п. Но вообще это не рокет сайнс, культурные люди могут догадаться и сами без подсказок.
Без базовых вещей закрыт путь к более сложным. На собесах часто попадаются ребята, рассуждающие про солид с эндофункторами, но не знающие базовых вещей — операции со строками, регэкспы и т.п. Ведь про такое у нас говорить не принято. Российское АйТи сообщество, при каждом случае стремящееся демонстрировать свою исключительность и илитарность на пустом месте, постепенно загоняет себя в мало привлекательную нишу.
Дело не в адекватности. Какой смысл писать статью о том, что до тебя уже тысячу раз написали в любом учебнике "Язык… для начинающих"? Тем более, что эта статья – пример того, как не надо объяснять материал. Почему не надо использовать присваивание пустого массива? А что, если мне как раз не надо затронуть остальные переменные, которые ссылаются на этот массив?
Нормальный учебник напишет в принципе о том, что есть условная передача по ссылке и по значению, а выводы типа этой статьи обучаемый должен сделать сам. В крайнем случае, можно задать наводящий вопрос. Иначе надо ждать следующую статью, "Почему не надо удалять все содержимое объекта, переназначая его на {}?", а то в этой статье как-то недостаточно подробно описан этот момент.
Какой смысл писать статью о том, что до тебя уже тысячу раз написали в любом учебнике «Язык… для начинающих»?
Думаю так люди развиваются. Читают учебник, потом пробуют применять, потом делятся мнениями в статьях, а потом кто-то даже пишет свой учебник. Без простых статей не будет и сложных. Написание технических статей и тех.перевод это практические скиллы, которые без практики не прокачиваются.
А что, если мне как раз не надо затронуть остальные переменные, которые ссылаются на этот массив?
Мне кажется, что раскрыв ответ на этот вопрос, у вас мог бы получиться конструктивный коментарий.
Написание технических статей и тех.перевод это практические скиллы, которые без практики не прокачиваются.
Согласен. Только если это выбранная наугад статья для тренировки навыков перевода, то, во-первых, стоит вспомнить такое понятие как "перевод в стол", а во-вторых, я считаю, что хабр – это не то место, где стоит рассчитывать на помощь в отработке навыков перевода как на первоочередную цель публикации статьи. Одно дело – корявый (в силу отсутствия опыта) перевод отличной технической статьи (на техническом ресурсе), другое дело – корявый же перевод посредственной статьи.
Другое дело, если переводчик считает, что это статья достойна того, чтобы поделиться ей с аудиторией хабра, а не просто вытащил ее наугад из рандомайзера медиума. Но в этом случае моя претензия сводится к другому – я считаю, что эта статья посредственная, она говорит о вещах, которые тысячу раз до этого освещались куда как лучше, и вообще делает акцент совсем не на том, что полезно для начинающего разработчика. Потому что правильный ответ на вопрос "Почему не надо удалять все элементы массива, переназначая его на []?" должен звучать так: потому что это не удаление элементов массива, а присвоение переменной нового значения.
А оценка переводных статей может показаться довольно неоднозначной. Ведь можно поставить минус плохому переводу хорошей статьи, а можно тот же минус хорошему переводу плохой статьи. И тут скорее второй случай, перевод-то более или менее неплохой.
Думаю так люди развиваются.
А почему обязательно на хабре?
потом делятся мнениями в статьях
Зачем? В статьях нужно чем-то достойным делиться, а не мнениями.
Я прекрасно понимаю подобных авторов: они сделали для себя открытие, узнали что-то новое и им хочется поделиться с аудиторией, но тут им наваливают комментарии в стиле «да это уже сто раз обсуждалось в учебниках/блогах/мануалах». При этом есть странная вещь: почему-то критики сами нечасто создают годные статьи, которые бы достаточно раскрывали тему.
Прекрасная логика. Не важно качество материала. Лишь бы было огромное количес во статей. А давайте я завтра опубликую статью в чем разница между var и let. Полезный вклад в сделаю в хабр?
Вы не поверите, но как раз по разнице между var и let недавно была статья на хабре.
Мне понравилась...
Я прекрасно понимаю подобных авторов: они сделали для себя открытие, узнали что-то новое и им хочется поделиться с аудиторией
А я не понимаю. Никому не интересно читать, как имярек изобретет очередной велосипед.
Вы думаете я мало велосипедов изобретаю? Уверяю, много. Я динозавр, и по жизни делаю много лишнего. Но я об этом не пишу, потому что понимаю, что хвастаться тут нечем.
почему-то критики сами нечасто создают годные статьи
Потому что годную статью создать трудно. Годных статей — крайне мало.
Я прекрасно понимаю подобных авторов: они сделали для себя открытие, узнали что-то новое и им хочется поделиться с аудиторией, но тут им наваливают комментарии в стиле «да это уже сто раз обсуждалось в учебниках/блогах/мануалах».
Для этого есть соц. сети вроде фейсбука или персональные блоги. С другой-то стороны, и хабр уже давно превратился в гибрид медиума и пикабу, хотя ценные технические статьи всё ещё появляются. Сложно винить человека, который не понял разницу.
Писать статьи это важно и полезно, просто нужно осознавать, куда, как и зачем. Можно написать полезную и интересную статью и на такую простую казалось бы тему, как ту, что затронул автор. Вопрос только в уровне материала. Судя по реакции аудитории, уровень ожидается слегка другой.
И да, пост-советская аудитория злее и жестче в общении и критике, чем западно-европейская или, скажем, североамериканская. То есть, мало кто будет вытанцовывать вокруг очередной "снежинки" вне зависимости от возраста, пола, цвета кожи и тому подобного. По крайней мере, по моим наблюдениям, на объективность не претендую.
При этом есть странная вещь: почему-то критики сами нечасто создают годные статьи, которые бы достаточно раскрывали тему.
Иррелевантно обсуждению.
Вот видите, это как раз-таки и демонстрирует то о чём я писал выше. Вы пытаетесь сказать "сам дурак" практически переходя на личности. Это "аргумент" из серии Ad hominem. Рекомендую изучить на досуге.
Случай из статьи (мутабельный массив, ссылки на который хранятся где-то ещё) – imho достаточно редок, обращаешься с таким массивом, как с полным ночным горшком, и тут уж знаешь, что на него ссылки держат и присваивать его нельзя.
На js и прочем не кодю(жу), но мне было интересно.
JSPerf уже давно не считает бенчмарки правильно.
Ну, например, https://www.youtube.com/watch?v=HPFARivHJRY
и какие альтернативы? нет их. кашу, которую jit нагенерил, сможет понять только разработчик этого jit + небольшая кучка гениев. а точность профилировщика в браузере недостаточна для микробенчмарков.
Все гораздо проще, чем вы думаете. Не надо юзать бенчмарки на jsperf, надо смотреть проблемные места конкретного приложения. В конкретном месте с конкретными условиями — и сразу все становится понятно, где и что надо оптимизировать. Профайлер в devtools показывает все очень наглядно.
Насчет benchmark.js, я, если честно, не помню, но там, на сколько я помню, суть не только в тестировщике, а скорее в самих тестах.
Прислушиваться к определенным техникам есть смысл, но не очень большой, если честно. Так как от релиза к релизу (v8) все это оптимизируется и выполняется по разному.
профилировщик, как я сказал выше, вещь неточная. проблемные места могут быть размазаны по всему приложению. не слишком удобно отлаживать. хотя измерять создание массива — это не самый удачный вариант использования jsperf. нужно добавить в тест доступ к элементам массива.
кроме того, есть обычное человеческое любопытство. или просто человек хочет выбрать один из двух способов (любую вещь можно сделать двумя способами, это проклятье программирования).
https://jsperf.com/array-splice-vs-array-length-0/30
Почему не надо удалять все элементы массива, переназначая его на [ ]?