А, так-то да, не спорю. Но, весьма вероятно, в будущем можно будет вбухивать туда сразу много разных кадров или куски видео. С умершим 100 лет назад предком, от которого одно фото, положим, так не получится, но большинство остальных реквестов вполне.
Имхо, это мелочи, которые не доставляют никаких проблем. А возвращать undefined на несуществующий ключ объекта это и вовсе полностью валидная логика, что с ней не так? о_О
Очень много вещей, который в C++ просто не пропустит компилятор в JS породят… нечто
Ровно и наоборот. Напишите #define true false, и у вас это благополучно скомпилируется.
Скажете, такой код сознательно не напишешь? Я тоже сознательно не пишу {} - [], ну ничего себе :)
Конечно. Чем больше «странного» и «дурацкого» кода является валидным и как-то работает и что-то таки делает — тем сложнее попасть в узкое подмножество «хорошего» кода…
Опять киваю на дефайн. И миллион других возможностей выстрелить в себе ногу, например, переопределение операторов.
На самом деле нет, скажу совершенно непопулярное мнение: да, js очень гибкий, и я считаю это плюсом. В моём опыте было море случаев, когда это спасало. Чаще в целях отладки, конечно (например, чтобы посмотреть, что делает библиотека на канвасе, не копаясь долго в её коде, можно руками переопределить прототип CanvasRenderingContext2D, встроив туда логгирование), хотя однажды залезающий в приватные поля чужого прототипа код даже думали выкатить в прод, потому что это был просто единственный вариант.
Но я не говорю, что такое должно оказываться в продакшене и вообще в коде. Это скорее дополнительная возможность, которая иногда облегчает жизнь — как тот же самый дефайн у плюсовых разработчиков. А чтобы писать именно для продакшена именно хороший код, у нас есть многочисленные правила и многочисленные линтеры включая тайпскрипт (который по сути тоже продвинутый линтер).
И я понимаю, почему это плохо. Привычная функция может оказаться работающей непривычно (опять киваю на дефайн), или же просто логика одного объекта будет раскидана по всему проекту, по разным модулям, и её сложно будет собрать в одно. Но, кажется, это более общая проблема, проблема организации проекта и т.п.: в любом языке я могу раскидать класс и его методы по всему проекту, и будет непонятная запутанная схема. Никакой возможности переопределять прототипы Number мне для этого не нужно.
Но все эти оптимизации всё равно не позволяют достичь скорость написанной на статически типизированном язуке — однако требуют кучу дополнительных ресурсов.
Странный аргумент. Давайте писать на ассемблере, раз нам важна в первую очередь скорость.
К слову, программисты гугла считают иначе, и ровно по этой причине они не захотели поддерживать asm.js
А вот версия, в которой за последние лет 10 перенесли кучу всего с C++ на JavaScript — совсем другое дело.
Аргумент был бы валиден если бы это было единственное, что изменилось в движке за 10 лет. Но нет, как вы понимаете, там хренова туча всего.
Высоконагруженные сервера (сотни тысяч и миллионы QPS) до сих пор пишут на C++. На js пишут сервера, при создании которых хочется использовать армию дешёвых JS-программистов — а потом начинаются приседания, когда оказывается, что железо-то всё-таки небесплатное…
И на плюсах тоже пишут. Например, все сообщения в вк на сервере, кажется, работают на ноде. Попробуйте сказать, что это малонагруженный сервис.
Что касается армии дешёвых js-программистов: а у вас есть какие-то достоверные данные, что всё происходит именно так, и что js-программисты дешевле остальных? Вы говорите так, будто претендуете на объективность, но при этом само мнение звучит как нечто очень сомнительное, как мнение совершенно поверхностно разбирающегося человека.
Не могу не спросить, а обратная градация есть? Пусть не в жизни, но хотя бы в теории есть идеи, как будет выглядеть человек, по сравнению с которым обычный человек по уму — как ребёнок?
Допустим, но как вы докажете, что большинство проектов на js едят много памяти и тормозят? :) По моим данным, всё совершенно наоборот — на js пишут высоконагруженные штуки вроде сервера сообщений вк, и вообще js наверное самый оптимизированный из динамически типизированных интерпретируемых языков.
И более того, если у вас кушает много памяти что-то в браузере или в electron — почему вы уверены, что проблема в языке, а не в том самом Chrome, который вообще-то известен своей прожорливостью? К слову, на чём он там написан, на плюсах? Давайте ругать плюсы за прожорливость хрома и гмейла в частности).
ANSYS, кажется, и памяти ел больше, чем хром в брачный период. Но я точно не скажу, это было давно и в страшном сне.
Про Lua совершенно очевидно напрашивается вывод: это трейдофф память -> скорость. Разработчики V8, вероятно, решили, что работать быстро важнее, чем есть мало памяти. Это мои домыслы, но тем не менее. И высоконагруженные сервера пишут не на требующем малых ресурсов Lua, а, как ни странно, на js.
Классика. Говорить, что язык объективно плохой, за то, что некоторые пишут на нём плохой код :)
Это вообще ооооочень странно — выдавать медлительность Gmail / Slack за аргумент, почему js плохой. Я вот работал с ANSYS, такой очень распространённый инженерный софт. Он умеет подвисать на минуту при right-click (нет, там точно не нужны сложные расчёты чтобы открыть контекстное меню с тремя пунктами) и тому подобных действиях. А ведь он написан, кажется, на C++. На сильно статически типизированном! И даже без Qt и т.п. штук.
Почему Slack или Gmail столько кушает — я не знаю. Правда. Всё, что я когда-либо писал, в принципе не могло столько есть. Я серьёзно не представляю, как можно написать такой простой интерфейс очень тяжёлым.
Вот это всё, надеюсь, проиллюстрирует то, что я хочу сказать.
Ну а про сторонников — нет, просто вы говорите про наличие критических всем мешающих недостатков как про что-то объективное, и с чем никто не спорит, мне интересно, что именно вы имеете в виду :). И одно дело если с этим не согласны два с половиной джуниора, другое — много процентов разработчиков.
Я разумеется не имею в виду, что все 100% разработчиков должны быть согласны, а какой-нибудь несогласный стажёр всё ломает. Я имею в виду, что не нужно выдавать субъективность за объективность, а открытые вопросы за решённые. Вы не можете выдать за объективную истину «пробелы лучше табов» или «статическая типизация лучше динамической» или «прототипы лучше классов», потому что примерно 50% (или 30% или 20% или 10%) с вами не согласятся, и однозначного ответа, почему одно лучше другого, не найдено.
количество попыток прикрутить в JavaScript'у статическую типизацию показываает, что режим тяп-ляп-и-в-продакшн уже многих не устраивает
Ага, а количество попыток затащить JS на сервер показывает, что все остальные серверные языки уже многих не устраивают.
Ничего это не показывает. Только количество разработчиков, которые попытались пересесть со статически типизированных языков на js, и ощутили, что им не нравится писать без типов. Это даже легко доказать: если человек изучает программирование начиная с js, ему и в голову не придёт тащить в него типы :)
Когда забываешь слово var? Кажется, за всё, вообще всё время это ни разу ничего у меня не ломало :). Более того, такие штуки видно сразу, а если в вашем коде видно их не сразу, например, двадцать вложенных функций каждая со своими локальными переменными, то у вас в любом случае проблемы.
Нет, я согласен, что есть море неудачных решений, которые при определённых обстоятельствах делают всё плохо, но кажется, что это вот примерно настолько же плохо, как typeof null.
А какие есть неудачные решения есть в JavaScript, которые однозначно всем сильно мешают жить, и все однозначно согласны, что они плохие и лучше бы их не было?
Например, typeof null на практике сильно не мешает, а прототипы или динамическая типизация — вы не сможете сказать, что все разработчики однозначно против.
Хмм, а почему нельзя произвольную программу разбить на атомарные операции? Давайте возьмём машину Тьюринга, там атомарные операции вполне очевидны, и программа разбивается на них просто по определению. Нет?
Возможно, я сейчас спрашиваю о каких-то банальных вещах, которые рассказывают в институте на Computer Science, но я, к сожалению, учился на немного другом направлении.
Или не завершится? Ведь среди всех программ, которые будут испробованы, встретится while True: pass (и её функциональные аналоги) — и дальше проверки такой программы дело уже не пойдёт!
Вообще не обязательно.
Давайте сделаем так: разобьём каждую программу на некие атомарные операции и сделаем очередь программ. Затем будем каждую итерацию добавлять в список следующую программу и исполнять по одной атомарной итерации из каждой программы списка.
Таким образом, любая программа будет запущена через некоторое конечное время.
(что конечно же не сработает на практике, но ведь мы не об этом говорим?)
Если у вас есть массив из 4 элементов, и вы по кнопке его сортируете, то сортируйте хоть перебором, 24 перестановки комп переберёт почти так же быстро, как и отсортирует пузырьком. Место не критичное.
Медленно работающий гмейл — это результат того, что плохой код в критичном месте, понимаете? Критичные места — это то, что нужно оптимизировать.
Можно подробнее? Откуда у вас взялась такая интересная неправильная информация, что TS медленнее и больше ест памяти, чем JS?
#define true false, и у вас это благополучно скомпилируется.Скажете, такой код сознательно не напишешь? Я тоже сознательно не пишу
{} - [], ну ничего себе :)Опять киваю на дефайн. И миллион других возможностей выстрелить в себе ногу, например, переопределение операторов.
На самом деле нет, скажу совершенно непопулярное мнение: да, js очень гибкий, и я считаю это плюсом. В моём опыте было море случаев, когда это спасало. Чаще в целях отладки, конечно (например, чтобы посмотреть, что делает библиотека на канвасе, не копаясь долго в её коде, можно руками переопределить прототип CanvasRenderingContext2D, встроив туда логгирование), хотя однажды залезающий в приватные поля чужого прототипа код даже думали выкатить в прод, потому что это был просто единственный вариант.
Но я не говорю, что такое должно оказываться в продакшене и вообще в коде. Это скорее дополнительная возможность, которая иногда облегчает жизнь — как тот же самый дефайн у плюсовых разработчиков. А чтобы писать именно для продакшена именно хороший код, у нас есть многочисленные правила и многочисленные линтеры включая тайпскрипт (который по сути тоже продвинутый линтер).
И я понимаю, почему это плохо. Привычная функция может оказаться работающей непривычно (опять киваю на дефайн), или же просто логика одного объекта будет раскидана по всему проекту, по разным модулям, и её сложно будет собрать в одно. Но, кажется, это более общая проблема, проблема организации проекта и т.п.: в любом языке я могу раскидать класс и его методы по всему проекту, и будет непонятная запутанная схема. Никакой возможности переопределять прототипы Number мне для этого не нужно.
Странный аргумент. Давайте писать на ассемблере, раз нам важна в первую очередь скорость.
К слову, программисты гугла считают иначе, и ровно по этой причине они не захотели поддерживать asm.js
Аргумент был бы валиден если бы это было единственное, что изменилось в движке за 10 лет. Но нет, как вы понимаете, там хренова туча всего.
И на плюсах тоже пишут. Например, все сообщения в вк на сервере, кажется, работают на ноде. Попробуйте сказать, что это малонагруженный сервис.
Что касается армии дешёвых js-программистов: а у вас есть какие-то достоверные данные, что всё происходит именно так, и что js-программисты дешевле остальных? Вы говорите так, будто претендуете на объективность, но при этом само мнение звучит как нечто очень сомнительное, как мнение совершенно поверхностно разбирающегося человека.
И более того, если у вас кушает много памяти что-то в браузере или в electron — почему вы уверены, что проблема в языке, а не в том самом Chrome, который вообще-то известен своей прожорливостью? К слову, на чём он там написан, на плюсах? Давайте ругать плюсы за прожорливость хрома и гмейла в частности).
ANSYS, кажется, и памяти ел больше, чем хром в брачный период. Но я точно не скажу, это было давно и в страшном сне.
Про Lua совершенно очевидно напрашивается вывод: это трейдофф память -> скорость. Разработчики V8, вероятно, решили, что работать быстро важнее, чем есть мало памяти. Это мои домыслы, но тем не менее. И высоконагруженные сервера пишут не на требующем малых ресурсов Lua, а, как ни странно, на js.
Это вообще ооооочень странно — выдавать медлительность Gmail / Slack за аргумент, почему js плохой. Я вот работал с ANSYS, такой очень распространённый инженерный софт. Он умеет подвисать на минуту при right-click (нет, там точно не нужны сложные расчёты чтобы открыть контекстное меню с тремя пунктами) и тому подобных действиях. А ведь он написан, кажется, на C++. На сильно статически типизированном! И даже без Qt и т.п. штук.
Почему Slack или Gmail столько кушает — я не знаю. Правда. Всё, что я когда-либо писал, в принципе не могло столько есть. Я серьёзно не представляю, как можно написать такой простой интерфейс очень тяжёлым.
Вот это всё, надеюсь, проиллюстрирует то, что я хочу сказать.
Ну а про сторонников — нет, просто вы говорите про наличие критических всем мешающих недостатков как про что-то объективное, и с чем никто не спорит, мне интересно, что именно вы имеете в виду :). И одно дело если с этим не согласны два с половиной джуниора, другое — много процентов разработчиков.
Ага, а количество попыток затащить JS на сервер показывает, что все остальные серверные языки уже многих не устраивают.
Ничего это не показывает. Только количество разработчиков, которые попытались пересесть со статически типизированных языков на js, и ощутили, что им не нравится писать без типов. Это даже легко доказать: если человек изучает программирование начиная с js, ему и в голову не придёт тащить в него типы :)
Я спросил, что (очень мешает жить) && (все согласны, что это плохо).
Нет, я согласен, что есть море неудачных решений, которые при определённых обстоятельствах делают всё плохо, но кажется, что это вот примерно настолько же плохо, как typeof null.
Например, typeof null на практике сильно не мешает, а прототипы или динамическая типизация — вы не сможете сказать, что все разработчики однозначно против.
Спасибо)
Возможно, я сейчас спрашиваю о каких-то банальных вещах, которые рассказывают в институте на Computer Science, но я, к сожалению, учился на немного другом направлении.
Вообще не обязательно.
Давайте сделаем так: разобьём каждую программу на некие атомарные операции и сделаем очередь программ. Затем будем каждую итерацию добавлять в список следующую программу и исполнять по одной атомарной итерации из каждой программы списка.
Таким образом, любая программа будет запущена через некоторое конечное время.
(что конечно же не сработает на практике, но ведь мы не об этом говорим?)
Медленно работающий гмейл — это результат того, что плохой код в критичном месте, понимаете? Критичные места — это то, что нужно оптимизировать.