JavaScript как праздник

    Эта пятничная статья будет ответом на статью JavaScript как явление, в которой автор изложил необоснованную критику на JavaScript. Лично я пишу на JavaScript уже 15 лет и искренне считаю его одним из самых мощных ЯП на сегодняшний день. В статье будет, по возможности, аргументированная позиция относительно основных тезисов критики, так как у новичков действительно часто возникают проблемы с JavaScript. Вводит в заблуждение приставка Script и несерьёзный имидж языка, а на деле обнаруживается, что язык применяется от front-end и back-end до дескопных и мобильных приложений, программирования интегральных микросхем, обработки видео и в множестве других сфер. Я давно хотел раскрыть частые заблуждения про JavaScript, а тут как раз появился повод, поэтому welcome под кат.

    На данный момент JavaScript — самый популярный ЯП на планете. Причина по которой JavaScript стал таким популярным (кроме монополии в веб) — его демократичность. Он позволяет программировать и в процедурном стиле, и в объектно-ориентированном и в функциональном. Он накладывает минимальные ограничения на разработчика, позволяя творить любую «глупость». Но ирония состоит в том, что то, что является глупостью применимо к одному классу задач, применимо к другому является более чем целесообразным. Легенда гласит, что JavaScript был создан за 2 недели. И опять ирония жизни, в таких условиях можно заложить в язык только самое главное, оставив за бортом всё лишнее, традиционное, «правильное». Первая версия языка получилась очень компактной и лаконичной. Все эти get/set, const и await появились гораздо позже. Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений. Конечно к этому были и негативные причины, политика Microsoft и Mozilla, многое другое, но, уверен, не многие из других популярных языков смогли бы пройти такое же испытание и подняться после этого. Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений. Причина по которой JavaScript выжил очень проста, он решает одну задачу и делает это идеально.

    JavaScript не претендует быть синтаксическим сахаром или набором клёвых фич, их программист может написать/подключить и сам. JavaScript скрывает от вас аппаратную часть устройства, даёт возможность делать что угодно с логикой и просто оставляет вас с этим. Хотите eval — пожалуйста, хотите переопределить любой объект — нет проблем, хотите передать в функцию то, что «нельзя» передавать — welcome, потому что это «нельзя» только в вашей голове. Программистам на Go или C# очень сложно понять почему это хорошо. Чтобы не вызвать на себя их хейт, это прекрасные языки, просто другие. Классически в языках ставятся барьеры, не дающие программистам отстрелить себе ногу, это и проверка типов, и различные обязательные best practices, и многое другое. В JavaScript этих барьеров нет, вы в праве стрелять куда угодно, и в 0.01% случаев стрельба в ногу тоже имеет смысл. Это можно сравнить со спортивным автомобилем, у многих языков заблокирована часть функций, а в JavaScript — нет. Если вы водите плохо — возможно это для вас минус, опасности и т.п., но если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти. Для частных — можно, для общих, универсального — объективно нет. Многие возразят, мол в Java тоже можно создавать словари, аналог JS-объектов, Python и Ruby тоже не типизованные, много где есть и eval и duck typing, но применять это так просто, как в JavaScript не получится нигде. В Java, например, словари это только дополнение, приделанное на типизованную класс-ориентированную основу, а в JavaScript — это основа языка, и создаётся всего двумя символами "{}". Это как если бы в спортивном автомобиле форсаж вызывался не тремя кнопками и рычажком, а одной кнопкой под большим пальцем правой руки. Свобода не просто возможна, она поощряется.

    Многих это вводит в ступор, потому что они привыкли, что им не дадут расшибить лоб. Это как переход с Windows на Linux. «Я ввёл sudo rm -Rf / и всё сломалось. Не система, а г… но». С такими рассуждениями путь до мастера будет очень долгим. Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались. Причём у человека может быть 20 лет опыта в Lisp, но по JavaScript он всё равно даже документацию не читал, типа и так умный. Этого достаточно, чтобы писать простые программы, но если человек хочет понять почему true < 2 === true, и почему это правильно и логично — прочитать про преобразования типов must have, а в идеале всю документацию (или хорошую полную книгу), это не долго.

    Теперь отвечу на критику по пунктам:

    Вопрос 1: однопоточный рантайм


    Это очень удобно, не возникает проблем с блокировками и владением объектами и других прелестей многопоточности. Зачем вам нужна многопоточность? Выполнять программу дальше пока ждёте выполнения долгой операции? Колбеки справляются с этим гораздо лучше. NodeJS на одной средней машинке может держать по 100 000 коннектов. Сколько бы их было при замене колбеков на поточный подход? На многопроцессорных машинках js прекрасно параллелится запуском локального кластера. 8 ядер — 8 процессов, 16 ядер — 16 процессов, каждый независим друг от друга и прост внутри. Это реальный пример из практики применения, как главной серверной технологии онлайн игры с 8 миллионами пользователей. Работа с ассинхронностью/потоками это не слабость, а одно из мощнейших преимуществ JavaScript. Это может требовать переучивания и изменения привычек, но поверьте, вы приобретёте очень многое.

    Вопрос 2: отсутствие единой системы / стандартов реализации модулей


    В JavaScript два основных варианта работы с модулями:
    • официальный, через import
    • и традиционный, через require

    Оба способа прекрасно работают, и полностью совместимы друг с другом. Вы можете выбирать тот способ, который вам больше нравится. Мне, например, больше нравится require, потому что его можно переопределить, и это больше соответствует философии JavaScript. Иногда это имеет смысл, например при написании своих препроцессоров. Почему я говорю, что два «основных» варианта, так это потому, что JavaScript сообщество открыто к любым новаторствам, и вы можете создать третью, четвёртую, тысячную систему работы с модулями (и многие уже создали). Другой вопрос, будут ли ей пользоваться за пределами вашего проекта. Описанные два способа являются де факто стандартом в веб-разработке, если вам интересны именно стандарты.

    Вопрос 3: отсутствие единых стандартов структуры проекта (все творят как хотят, в исходниках бывает очень сложно разобраться)


    Сочувствую вам с коллегами, которые «творят что хотят». Или коллегам с вами. В веб-разработке есть несколько типовых структур проекта, как правило используется одна из них, но это нигде не постулировано, и каждый действительно волен писать свою программу исходя из своего взгляда на целесообразность. А что вы хотели? Это самый популярный язык на планете, а не какой-то DSL. В разных сферах применения JS разные стандарты, и это правильно. Что касается практики, я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю. Нарабатывайте опыт и изучайте распространённые паттерны.

    Вопрос 4: слабые типы с неявными (и порой довольно странными) преобразованиями


    Странными для кого? Программистов Java, C#, PHP, Python, Lisp или Ams? Скажете asm не странный? А Lisp? Мир гораздо богаче вашего любимого языка и то, что для одних странно, для других норма. Посмотрите хотя бы на Haskell с его монадами и функторами (очень мощные штуки, кстати. В JS тоже используются, в jQuery). В институте этому не учили, правда? ООП это только малая часть мира, настолько малая и настолько заезженная, что даже скучно говорить. А типы в JavaScript не слабые, их принципиально нет (кроме примитивных). WeakMap и прочее ввели только для того, чтобы порадовать переселенцев из других языков. Перечитайте про duck typing и научитесь им пользоваться, проблем с типами у вас не возникнет.

    Вопрос 5: отсутствие нормальных классов / ООП


    Опять же, специально для переселенцев с других языков и для IDE уже довольно давно введены классы. Их поддерживают все основные браузеры, не говорю уже про NodeJS. ООП в JavaScript богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы. Во многих случаях правильного применения JavaScript прототипы оказываются быстрее, удобнее и логичнее, а программа компактнее и более читаемой. Но опять же, этому не учат в институте, а JavaScript сообщество должно потом доказывать, что так тоже можно.

    Вопрос 6: отсутствие единого вменяемого и работающего статического анализатора кода (добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function)


    Это общая проблема всех интерпретируемых языков с eval, и отказываться от этой мощи ради возможности ловить 5% самых глупых ошибок — сомнительная идея. А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.

    Вопрос 7: отсутствие вывода типов в самом языке или в каком-либо инструменте


    Это есть, изучайте синтаксис. Один из вариантов, в зависимости от ситуации:

    typeof myVar
    myVar.constructor
    

    Вопрос 8: этот чудесный контекст this (что это значит this в этом месте кода — объект? функция?)


    При правильном использовании проблем с this не возникает. Если вы вызываете функцию как myObj.func(), то можете быть уверены, что this будет равен myObj. При назначении колбеков или передаче функций как параметров, информация о myObj теряется и, если необходимо, следует задавать его явно через bind. Это логично и понятно знающим JS, так как вы, например, можете сделать так myObj2.func = myObj.func, и функция будет методом сразу нескольких сущностей. Не правильно назначать this равным myObj или myObj2, так как они симметричны. Не правильным было бы и использовать лексический контекст, так как это внесёт путаницу в миксины, прототипное наследование и многое другое. Поэтому this в таких случаях равен window или undefined, в зависимости от использования strict mode. Но это не должно вас волновать, и это принципиальный момент. Это один из типичнейших примеров стрельбы себе в ногу. На что вы надеетесь, вызывая this у функции, вызванной без контекста? Явно не на что-то хорошее. Есть много таких примеров, люди складывают массивы с числами, делят получившееся на объект и жалуются, что получают странные результаты. Во-многих странных вещах есть логика, но в особо странных это может быть просто произвол. JavaScript гибкий язык и позволяет вам делать то, с чем с C++ у вас программа даже не скомпилировалась бы, в надежде на то, что вы знаете, что делаете. Не нужно пренебрегать этим доверием и творить не весть что. Если вы хотите результат, то просто используйте this правильным логически обоснованным образом, а фразы а-ля «я воткнул себе нож в горло и у меня 2 раза потекла тёмная кровь, а 2 раза светлая, почему так?» оставьте для холиваров. И не надо хвастаться тем, что вы знаете чему в данной неочевидной ситуации равно this или как складываются несуммируемые типы. Профессионально правильной позицией будет, как ни странно, не знать это и не использовать, так как в разных браузерах и в разном контексте вы можете получить разный результат. Но JavaScript всё равно позволяет вам, если вы хотите это использовать, например для того, чтобы отличить PhantomJS c поддельным User-agent от настоящего Chrome — дорога открыта.

    Вопрос 9: абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined


    Два совета:

    1. не делайте логических ошибок. Ваши ошибки — не вина языка
    2. если хотите сделать регулярные выражения удобнее — используйте или напишите библиотеки. Похоже на то, что ругать C# за то, что он с Facebook не интегрирован. Руки есть, голова есть, напишите что хотите, или возьмите одну из многочисленных библиотек.

    Вопрос 10: отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async (если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку)


    И колбеки, и промисы, и async/await — нативные, поэтому код они не утяжеляют. Не знаю, что вы называете фьючерсами, я этим не торгую. И это прекрасно, что у вас есть выбор, что использовать. Колбэки это основа всего и ни промисы ни async/await без них не будут работать, это базовый кирпичик языка. Промисы и async/await прекрасно совместимы друг с другом и вы легко можете использовать await с любой функцией, возвращающей промис. Если же вы имели ввиду популярную библиотеку async для node, то сочувствую, ваши знания JS устарели. Библиотека хорошая, но используется всё реже ввиду появления вышеуказанного функционала в ES6. Но подтянуть её в зависимости на ноде тоже не страшно, серверные зависимости не отдаются пользователю и легко бекапятся, на случай удаления с npm (на моей практике такого не было ни разу). А ещё есть Fibers, и Sync, и много классных инструментов, используемых по назначению врача. Выбирайте тот, что больше подходит под конкретные задачи, и не жалуйтесь, что их слишком много.

    Вопрос 11: const ( который на самом деле НЕ const )


    Не знаю, почему вы так решили. Моя простая проверка в консоли показала обратное:

    const a = 5
    const a = 4
    VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
        at <anonymous>:1:1
    

    Но на самом деле так это или нет — не важно, const создан не для вас, а для интерпретатора. А вам не нужно без глубокого знания языка менять const. Тем более, что на разных движках/браузерах/устройствах этот функционал может работать по разному, и вполне возможно найти какой-нибудь холодильник, программируемый на диалекте JavaScript, в котором случатся ваши самые страшные кошмары. Язык то открытый и версий реализации великое множество. В браузерах данная ошибка не подтверждена.

    Вопрос 12: абсолютно безумный npm, с пакетами качества «братишка я тебе покушать принёс»


    Плата за свободу творчества и отсутствие премодерации. Проблема не большая, просто всегда смотрите на число скачиваний или звёзд на github. Качество топовых пакетов очень высокое. Мало популярные тоже бывают неплохие, бывают и такие, как вы нашли. Ответственность за используемые зависимости полностью на вас. Это открытое сообщество и никто вам жёванную пищу в клюв класть не будет. На мой взгляд, эта ситуация лучше, чем в решениях от одного поставщика/судьи, так как у библиотек сотни тысяч вендоров и тысячи из них очень достойные. Если хотите однообразия — посмотрите на решения, например, от Sencha. Они платные, но про них были вполне неплохие отзывы. В npm тысячи классных библиотек, но вам надо было найти плохую и выстрелить себе в ногу. Стреляйте, кто же вам запретит.

    В JavaScript нет защиты от дурака, поэтому эта категория граждан набивала шишки, набивает, и будет набивать. В этой статье я постарался больше раскрыть именно философию и принципы JavaScript. Часто люди ждут от него того-же, что привыкли ждать от своего старого языка программирования. Но JavaScript имеет свой характер, и подружится с ним не сложно. Надеюсь кому-то эта статья была полезна.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 255
    • +3
      Лично у меня только одна претензия к JS — дебажить его то еще удовольствие. И если на клиентской части у тебя есть DevTools браузера, то на сервере такой радости нет. И только по-этому я с опаской посматриваю на JS в качестве back-end инструмента.

      Я не против свободы, но как показывает практика, разработчику лучше ехать по «рельсам». Набрать команду хотя бы из 5 адекватных разработчиков, которые будут делать «все правильно» очень не просто.

      Ну и «миллионы мух не могут ошибаться — что-то в этом есть»…
      • +6
        Чтобы дебажить сервер можно использовать Node Inspector
        • 0
          Единственное что он не показывает контекст твоего скрипта. Т.е. я имею ввиду, что на фронте можно определить какую-нибудь переменную в глобальной области видимости, а потом в консоли браузера написать что-то в духе myVar и получить её значение. В Node Inspector так не работает, хотя, я допускаю, что я просто не знаю как ведь, на Ноде я написал пока только полприложения
          • 0

            Вообще глобальные переменные — зло. В ноде есть глобальный объект — global, к нему можно что-то подцепить, но смысла в этом я особо не вижу

        • +5

          VS Code с легкостью решает все проблемы дебага ноды

          • 0
            Опередил! :) Да, на VS Code это всё без проблем: сам удовольствие недавно получил: дебаг просто летает.
          • 0
            В Webstorm отличный дебаггер.
            • +2
              Для современных версий ноды
              node --inspect --debug-brk
              

              после чего пользуетесь любимыми DevTools :)
              • +2
                В ноде тоже есть DevTools:
                $ node --inspect --debug-brk server.js
                

                update: опоздал с комментарием
                • 0

                  Команду из "правильно пишущих" набрать сложно и в других ЯП. В каждом есть крайности. В принципе, большинство проблем решается грамотными гайдлайнами для разработчиков.

                • НЛО прилетело и опубликовало эту надпись здесь
                  • +7
                    Минус языка в том, что его невозможно на все 100% контролировать.

                    несколько офтоплю, но… а что можно контролировать на все 100%?

                    • +1
                      Aссемблер конечно же
                      • 0
                        Тогда уж не ассемблер, а машинные коды.
                        • 0
                          не, в кодах легче запутаться
                          • +1
                            Тут речь шла про максимальный контроль, а не про «легче». Максимальный контроль дают самые низкоуровневые инструменты.
                          • +1

                            Но ведь вы не контролируете где и на каком процессоре их будут запускать...

                        • +3
                          осмелюсь быть усыпанным минусами, но если под «контролировать» понимать «прогнозирование поведения программы», то имхо, к этому ближе всего java.

                          и это стоило очень больших больших усилий sun, а теперь стоит очень больших усилий ораклу.
                          и 100% обратная совместимость, и максимально возможная спека языка с требованиями к джава-машине с эталонным поведением.
                        • +10
                          Так не используйте сборщики, полифилы, трансплиттеры и прочую «камасутра кухню».
                          Одна из проблем JS, на мой взгляд — то что чьи-то фантазии и эксперименты, или узкоспециализированные штуки и точечные решения — на волне хайпа быстро поднимаются чут ли не до уровня стандартов и «ты обязан в этом разбиратся».
                          Кому-то мозолит отсутствие «его любимой фичи из другого языка потому что он привык кодить в таком стиле», и он обганяя стандарты ES запиливает трансплиттер. Кто-то терпеть не может скобочки или точки с запятыми. Есть любители «написать свой велосипед и назвать его фреймворком нового поколения».
                          По сути в последнее время развитие JS напоминает базар — кто громче кричит (за свой фреймворк) у того и покупают (берут как маст ноу).
                          Так это я о чем: JS сам по себе довольно шустрый и мошьный, но именно потому что его заставляют работать «как другой язык», загоняя в трансплиттеры и обвешивая фреймворками он так и тормозит.
                          Потому — не хотите терять клиентов — не насилуйте язык.
                          • 0
                            Придерживаюсь аналогичного мнения.
                            Только мой камень в огород фреймворков, сборщиков и транспилеров имеет немного иную форму:

                            Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.

                            Найти человека, который знает javascript намного проще, чем выискивать уникальную смесь из скиллов, типа Vue, Redux, Gulp, LESS и т.д. Сообщество слишком раздроблено и объединять его надо под флагом чистого JS.

                            Я не ратую за революцию… я за реставрацию)
                            • 0
                              Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк

                              Я бы сформулировал иначе: не бойтесь переделывать выбранный фреймворк под себя, и через год-другой у вас будет свой фреймворк, заточенный под ваш проект.
                              У нас от выбранного некогда JavaScriptMVC не осталось камня на камне, все его элементы постепенно заместились своими.

                              • 0
                                В таком случае проще сразу написать свой, чем переделывать чужое)
                                Там по сути не так уж много кода внутри: обсервер/медиатор и модули. Практически все фреймворки работают по этой схеме (правда некоторые предпочитают хранить стейт во внешней модели, а другие — внутри модуля в его замыкании, но это нюансы). Для CRUD-приложений еще может понадобиться некое подобие виртуального dom.
                              • +7
                                Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.


                                напишите, ага) только есть пара-тройка особенностой иусловий для вашего проекта, что бы он стал успешным на какое то время на js:

                                1. он не должен иметь долгий жизненный цикл. потому что есть over 100500 причин, что он перестанет работать с заменой ядра движка в следующем поколении браузеров. никто не обещает обратной совместимости.

                                2. он должен быть маленьким. вы не сможете написать свой продукт, потому что верхний порог логики и сложности, который вы сможете контролировать в условиях динамической типизации не даст вам развернуться. я не говорю о таких «сложных» системах как курсовая, проект jQuery, или пошаговая ммо-игрушечка. я говорю о действительно вещах типа СЭД, учетные системы с историяеской отчетностью, хранилище данных, олап, и тд и т.п.

                                3. вам не стоит к нему возвращаться что бы рефакторить и добавлять в него фичи. потому что если вы создадите большого монстра, со ложной бизнес-логикой, то как только вы начнете рефакторить и модифицировать свой продукт (под влиянием времени, и изменния требований окружения) — вы поймете что «не успеваете». ни оттестировать, ни предсказать влияние ваших изменний. потому что прогнозировать влияние изменний в языке с динамической типизацией сложно. и typescript не панацея. потому что… где стандартна тайпскрипт и гарантия обратной совместимости? (см проблему 1).

                                а так, да, js, вполне прикольный, для маленьких здесь и сейчас задач. как прослойка скриптовапия компонентами, для задач, где где бизнес-логика примитивна, задачи прозрачные, а ответственность минмальна — самое то.
                                (не в конце концов, никто же не умрет, аэс не взорвется, поезда с рельс не сойдут, если ваш мега сайтик с оvер 8миллионов конекшенов просто подохнет, после обновлепия или какого иного чиха.

                                просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
                                это глупо.

                                а так… хайп кончится, будет новая мода. visualbasic, delphi, php, python, ruby, javascript… что из этого продержалось на волне популярности долго?..

                                • 0
                                  никто не обещает обратной совместимости.

                                  Если бы не было обратной совместимости, мы бы давно имели нормальный современный язык.


                                  2.

                                  Нет возражений. Язык явно не для этого.


                                  3.
                                  typescript

                                  см пункт 1


                                  просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
                                  это глупо.

                                  Странно, что вы так думаете. никто не собирается никуда вытеснять ваши (наши) любимые плюсы.


                                  будет новая мода

                                  Казалось бы, "питон не брошу, потому что он хороший"? Да и пхп пока никто не списывает?

                              • 0
                                трансплиттер

                                транспилер наверное? (от англ. transpiler)
                              • +1
                                Второй минус, это производительность на стадии инициализации. Уже часто встречаются кривые сайты тормозящие при старте.

                                Я всегда думал что это разработчики должны контролировать – что 95% их кода при старте не нужно инициализировать.

                              • –12
                                Люто плюсую! JavaScript прекрасен. Зачем в него все таки классы притащили в упор не пойму. Прототипное наследование по-моeму в разы гибче и проще той же Java
                                • +12
                                  А чем классы от прототипа отличаются?
                                  Разве class не просто языковая конструкция, которая сводиться к тому же прототипному наследованию?

                                  • 0

                                    Синтаксический сахар по сути.

                                    • +1
                                      А чем классы от прототипа отличаются?

                                      Конструкция class декларирует семантику его экземпляров, а прототип является экземпляром и ничего более не декларирует. На практике это означает следующее:
                                      1. class позволяет организовать проверку типов, а прототипам доступна только утиная типизация
                                      2. class может наследовать семантику нескольких классов, прототипам множественное наследование не доступно (только миксины)
                                      3. class может наследовать только классы, прототипом же может выступать любой объект
                                      4. прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы
                                      продолжать можно долго.
                                      • 0
                                        class может наследовать только классы, прототипом же может выступать любой объект

                                        Это недостаток.


                                        прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы

                                        Мы пробовали. Не взлетело.

                                        • +2
                                          Это недостаток.

                                          Ну для кого то это недостаток, а для кого то существует паттерн Prototype, применимый в контексте class. Вопрос образования и опыта, только и всего.

                                          Мы пробовали. Не взлетело.

                                          Ну так я и говорю, что прототипам семантические объявления не доступны, можно было и не пробовать )
                                    • +1
                                      Прототипное наследование некуда не делось, class это просто сахар.
                                    • +1
                                      Забавно, исходные факты в обоих статьях одинаковые, а выводы абсолютно противоположные.
                                      • +1
                                        Зона комфорта. :) Для тех кому привычна среда — это плюс, для других как минимум не комфортно.
                                      • +17
                                        Вводит в заблуждение приставка Script

                                        А мне кажется, что в заблуждение вводит как раз таки Java в названии. Т.к. JavaScript к Java не имеет никакого отношения.

                                        • 0
                                          Это был мощнейший просчёт.

                                          Если в те самые времена был VBScript как упрощенный Visual Basic, то JavaScript по логике, это упрощённая Java.
                                          • 0
                                            Логика только у создателя была другая на этот счёт
                                            • +2
                                              то JavaScript по логике, это упрощённая Java.

                                              Да никакая это не упрощенная Java. Хотя бы потому, что в JavaScript прототипное наследование, а это существенная разница.


                                              А еще все почему-то забывают про язык ActionScript, который является одной из реализаций стандарта EcmaScript. С виду весьма неплохой язык (я на нём не программил) со статической типизацией (привет TypeScript), пакетами (привет ES6) и т.д. Если бы в своё время звёзды сошлись иначе, мы бы сейчас холиварили по поводу него, а не JavaScript, но нет)

                                              • 0
                                                По моему очучению ActionScript монополизирован Адобом.
                                                А люди, когда читают Java* подразумевают Java в основании, несмотря на то, что ничегошеньки общего (кроме сишных фигурных скобочек) с жабой язык не имеет.
                                                • 0
                                                  По моему очучению ActionScript монополизирован Адобом.

                                                  Так он и был. Наверное, если бы Adobe в своё время подсуетилась, сейчас писали бы по-другому.

                                                • +5
                                                  Вот кстати отличнейший язык был. Особенно его применение вместе с FLEX — я пару лет проработал на нем. Очень жаль что он загнулся. Там было все и строгая типизация, и классы с наследованием и модули и кастомные компоненты и соккеты… и все это в 2007м… без всяких трансплитеров, сборщиков и конверторов. Кросплатформенность и защищенность кода. Единй компилятор и мощьнейшие возможности… помнил… любим… скорбим…
                                            • +6
                                              Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений.

                                              C++ жил, жив и будет жить. Хотя стандарт очень долгое время оставался стабильным.

                                              • –7
                                                C++ это легенда, а ваш пост только подтверждает то, что хорошие вещи не требуют частых изменений.
                                                • +2

                                                  Отсутствие изменений — это стагнация.

                                                  • –4
                                                    В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам. Это не стагнация, а единственно правильный путь. В информатике ситуация похожая и есть программы и библиотеки, не меняющиеся десятилетиями, но так как дисциплина очень молодая, не прожила ещё и одного века, то таких решений очень мало. Поверьте, через 100-200 лет никто не будет переписывать языки каждый год, а сформируют единый стандарт, который достаточно хорош и самодостаточен.
                                                    • +3
                                                      В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам

                                                      Не-а. Почитайте, например, истории теории множеств. Там было несколько разных версий :) И так много где в математике. Просто оно менее заметно, чем в программировании, потому что там выпуск версии дольше тянется.

                                                      • +3

                                                        Молодой человек, в математике помимо теорем какбы вот… есть еще алгоритмы, которые время от времени ревизируются и меняются, разрабатываются новые версии, гибридизируются. Улучшать инструмент со временем — это нормально. Менять факты со временем — нет. Язык программирования — это не теория, подлежащая проверке или опровержению. Это инструмент решения задачи. Для него нормально периодически меняться. Вы же гвозди камнем не забиваете, верно? Камень, слава богу, успел за много лет развиться до молотка.

                                                        • 0
                                                          Простите за занудство, но очевидно, что молот(-ок) как орудие появился, раньше гвоздей. Таким образом факт забивания гвоздей камнем противоречит логике. Не самая удачная аналогия.

                                                          А так разделяю вашу позицую.
                                                        • +1
                                                          В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.

                                                          Не думаю, что сравнение корректно. Стандарт языка не подразумевает единственного правильного пути для решаемых задач, он разрабатывается так, чтобы быть удобным при решении этих задач. Где-то максимально эффективно, где-то максимально быстро (в плане времени разработки), где-то максимально элегантно. К тому же время меняется, сегодня все любят быстро, модно и сахарно. Вот и C++ и решил к растянутому свитеру добавить что-нибудь из модненького.


                                                          Я бы провёл аналогию не с математикой, а с естественными языками. Посмотрите на латынь и европейские языки, из неё вышедшие. Латынь красива, помпезна, но достаточно сложна, чтобы быстро и кратко донести мысль. Другие же европейские языки пошли по пути упрощения в силу различных обстоятельств. И они продолжают меняться, это неизбежно. Поэтому я уверен, к этому


                                                          Поверьте, через 100-200 лет никто не будет переписывать языки каждый год, а сформируют единый стандарт, который достаточно хорош и самодостаточен.

                                                          вряд ли всё идет. Языки программирования, подобно языкам естественным, развиваются практически безостановочно. Потому что возникают новые идеи, относительно того, как сделать разработку быстрее и проще, возникают новые предметные области и задачи, которых раньше не было.

                                                          • 0
                                                            В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.

                                                            Да, именно поэтому факт, что 0.(9) = 1 доказан только одним-единственным способо… А нет, не одним.

                                                    • +5
                                                      лучше языка чем JavaScript для общих задач вам не найти

                                                      Слова евангелиста, похоже. Вы видели тот же жирный Electron? Это всего лишь обёртка над Chromium, которая отжирает памяти мама не горюй.


                                                      Ну, а что до браузеров — так сложилось. Вместо JavaScript мог быть любой другой из семейства EcmaScript. При всём при этом я считаю JS нормальным языком. Сейчас на волне хайпа он еще обрастает новыми возможностями, так что писать становится приятнее)

                                                      • +3
                                                        Вопрос 11: const ( который на самом деле НЕ const )

                                                        Насколько я понял, там было про объекты. Мол, const не делает объекты неизменяемыми. Но мне всегда казалось это и так понятным.

                                                        • +1
                                                          const не даёт изменить сущьность, на которую ссылается переменная. Если это примитив — то const относится к value, соотвтетственно string или number изменить нельзя. В случае с объектом — reference. Переменную с объектом нельзя переопределить, но всё, что внутри объекта остаётся изменяемым. По-моему тоже логоично.
                                                          • +2

                                                            Собственно, я об этом и написал.

                                                            • +3
                                                              Да. я так и понял. Просто малость расширил для тех, кто «который на самом деле НЕ const»
                                                            • +1
                                                              Но по сути есть же Object.freeze, как по мне логично что const должен вести себя аналогичным образом когда применяется к объектам.
                                                              • 0
                                                                Вы имеете ввиду, что const к объектам должен применять, как Object.freeze и не давать изменять его поля?
                                                                • +1
                                                                  Ага)
                                                                  По крайней мере я именно так понимаю выражение «константный объект».
                                                                  Вроде так нигде не работает и это все мой воспаленный мозг, но все же хочется))
                                                                  • 0
                                                                    value и reference говорят, что логично как раз так, как это щас работает. Ну, а, если хочется, чтоб совсем const, то есть freeze. Да и тот при переопределении свойства объекта не ругнётся, а просто не переопределит (без стрикт мода) )
                                                                    Это ж философия js — дать возможность делать практически всё, что хочешь.
                                                                    Да и const же только в ES6 заехал. Раньше и того не было.
                                                                    • +1
                                                                      на какую глубину?
                                                                      • 0

                                                                        вот дельное замечание, кстати.
                                                                        я уж не спрашиваю про инициализацию и прочее, банально объясняющее такое поведение в любом языке, поддерживающем парадигму объекта и доступа к нему по ссылке

                                                                  • +3

                                                                    Нет. const означает константную ссылку на объект. Не более того.

                                                                    • –1
                                                                      Суть в том что переменная — это не объект. Переменная — это всегда указатель, преобразование «строка» -> «адрес в памяти». И const фиксирует это преобразование, а не данные.
                                                                  • 0

                                                                    А я так понял, что речь про ускорение с помощью const. Ну типа, в компилируемых языках const имеет только одно отличие от других переменных — компилятор на момент компиляции проверяет, не хочет ли кто его переопределить. Т е. по скорости никаких отличий.
                                                                    (или даже — где-то встречал, что const — это аналог #define, который считается в момент компиляции и подставляется препроцессором)


                                                                    В js же const ставит специальный флаг у переменной, и интерпретатор наоборот должен тратить доп. ресурсы и следить, чтобы эту переменную никто не изменил.

                                                                    • +1
                                                                      В js же const ставит специальный флаг у переменной, и интерпретатор наоборот должен тратить доп. ресурсы и следить, чтобы эту переменную никто не изменил.

                                                                      Не должен. Интерпретаторы js давно уже перестали выполнять инструкции "строчку за строчкой" — код сначала парсится в AST, потом преобразуется в удобную для интерпретации форму — и на этом этапе все "спецфлажки" заканчиваются: код проверен и пригоден для исполнения. Единственное исключение — если внутри есть вызов eval. Это одна из причин почему eval — зло.

                                                                  • +10
                                                                    Вопрос 11: const ( который на самом деле НЕ const )

                                                                    Не особо вы ответили на этот вопрос, ошибка у вас выпала о невозможности заново объявить переменную (если бы убрали const упала бы нужная ошибка).
                                                                    А имелось ввиду, что const не работает с объектами.
                                                                    Код ниже вполне ок работает без ошибок (в браузере по крайней мере):

                                                                    const a = { b: 1 }
                                                                    a.b = 2
                                                                    


                                                                    А вообще основная претензия к JS, то что он все разрешает, а основной аргумент автора данной статьи в том, что «сам дурак, не фиг в ногу стрелять».
                                                                    По такому принципу любой язык хорош, если в нем разобраться.
                                                                    Язык который ставит ограничения ЗАСТАВЛЯЕТ программиста писать как надо (либо бежать в ужасе), и тем самым повышает профессианализм самого программиста т.к. приходится решать задачи с ограниченным набором инструментов, которые позволяют сделать правильно (не факт, но все же).
                                                                    А т.к. JS позволяет делать все, программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто.
                                                                    • +9
                                                                      А имелось ввиду, что const не работает с объектами

                                                                      Ссылка на объект не изменилась, const работает как и должен.
                                                                      программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто

                                                                      Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
                                                                      • +1
                                                                        А имелось ввиду, что const не работает с объектами

                                                                        В другой ветке это обсуждают, там интереснее)))

                                                                        Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.

                                                                        Вообще не согласен.
                                                                        Можно прочитать все книги и мануалы по конкретной теме, но нифига в ней не разобраться.
                                                                        А можно делать правильные вещи, не зная что ты используешь какой-нибудь паттерн.
                                                                        Если человек не читал книги, но сам допер как нужно делать правильно, неужели он не является хорошим программистом?
                                                                        Немного странная логика

                                                                        Особенно веселят теоретики-отличники — это прям победа.
                                                                        Прочитали кучу книжек, типа умные, а вот руки к сожалению (или к счастью) не из того места растут.
                                                                        • +1
                                                                          Даже очень умный человек, который сам додумался до какого-нибудь паттерна, может почерпнуть в книгах идеи, о которых он и не думал, и начать их пробовать и применять. Мы ведь за этим и заходим на хабр.
                                                                          • +1
                                                                            Человек может подчерпнуть новые идеи не обязательно в книгах.
                                                                            Почему у всех книги это панацея?!
                                                                            Книга написано конкретным автором (иногда несколькими), у которых свой взгляд на вещи, и своя точка зрения.
                                                                            По вашей логике, чтобы было прям совсем круто, нужно прочитать книги нескольких авторов, с разной точной зрения, чтобы быть красавчиком, однако пока вы будете погрязать в чтении книг, некоторые/многие моменты уже устареют.

                                                                            Я не против изучения новой/другой информации, а против чтения книг ради этого.
                                                                            В чем проблема: в книге написано много всего, с кучей воды и, опять-таки, с одной точки зрения.
                                                                            Рассмотрим конкретный пример/случай из жизни: нужно изучить паттерны, чтобы разрабатывать «правильно».
                                                                            Я не бегу скачивать книгу Фаулера, я иду в гугл и вбиваю: «паттерны», «паттерны веб-разработка», «паттерны JS» и т.д.
                                                                            То есть я не трачу время на изучение всего подряд, что мне может-быть когда-нибудь пригодиться, я ищу конкретные вещи.
                                                                            Да я понимаю, что статьи и советы других людей это в большей степени аккумулирование книг, НО если после прочтения книги, мной будет усвоена часть информации (а так чаще всего и бывает, а пригодиться еще меньше (скажем 25% из книги мной было усвоено и пригодилось в жизни), то какой смысл мне читать ВСЮ книгу?
                                                                        • 0
                                                                          А как вы интересно относитесь к дистанционному обучению?
                                                                          GeekBrains или Hexlet?
                                                                          Окончание таких курсов тоже показатель крутости программиста и без наличия их сертификатов человек не может стать хорошим разработчиком?

                                                                          Че-то пришла гениальная мысль:
                                                                          Недостаточно читать книжки, чтобы быть хорошим программистом.
                                                                          Чтобы стать хорошим программистом, необходимо читать книжки/статьи/слушать советы опытных ребят.
                                                                          • +1
                                                                            Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.

                                                                            Чукча не читатель, чукча писатель, ага)

                                                                          • 0
                                                                            Это очень субективное мнение, как и критерий «правильности». Я вот, например, терпеть не могу когда язык нянчится и не дает мне сделать то, что я хочу. Если я знаю что делаю, то я не хочу бороться с компилятором.
                                                                            Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.
                                                                            По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.
                                                                            • +3
                                                                              Это очень субективное мнение, как и критерий «правильности». Я вот, например, терпеть не могу когда язык нянчится и не дает мне сделать то, что я хочу. Если я знаю что делаю, то я не хочу бороться с компилятором.

                                                                              Язык — это лишь инструмент. Не нравится, используйте другой. Но опять-таки, не нужно думать, что ограничения придуманы просто так.

                                                                              Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.

                                                                              Почему люди так критично относятся к ограничениям?
                                                                              Ограничения нужны не для того, чтобы как то ущемить программиста, а для того чтобы он не сделал себе больно.
                                                                              А написать пару лишних классов, которые в будущем облегчать вам возможность изменений (а точнее расширение функционала), для вас наверное моветон?

                                                                              По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.

                                                                              Про мануалы я погорячился, они как раз таки самый нормальный источник информации. А про книги тут.
                                                                            • +1

                                                                              Пожалуйста не кричите на меня. То, что не делается правильно, может делаться левельно (за счёт мастерства и глубокого понимания происходящего)(в основе юмора английское слово Level которое ты и так знаешь %username%). И это здорово — можно не вставлять квадратное в треугольное в угоду правильности и закостеневшим в мозгу паттернам.


                                                                              Я не пытаюсь сказать, что паттерны это плохо, а лишь намекаю на волновую структуру жизненного цикла [людей и программ]. Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу. Послезавтра, когда надоест танцевать на граблях, снова примешь чью-то новомодную методу. Далее по синусоиде, но уже с пониманием того почему ты использовал этот паттерн и почему именно таким образом. А дальше ночь, улица, фонарь, аптека…


                                                                              Автор соседнего поста ругает ES8 за низкий порог входа, но ПМЛМ это зря. Язык разрабатываемый десятком светил до которых не достать, может быть сколь угодно крутым, но что толку если программирует на нём всего сотня-другая людей?


                                                                              PHP в своё время взлетел и стал очень популярен из-за своей доступности. Достаточно было скачать бинарники, написать в командной строке php file.php в котором написано <?=6*7?> и получить ответ 42. Ну или можно поставить себе локальный денвер и байбай консоль, теперь можно результаты вписывать в разметку\оформление. Красиво. А до него был Perl.


                                                                              Сейчас вообще ничего скачивать не нужно и файлов создавать тоже. Жмёшь заветные ctrl + shift + i, пишешь 2**10 и получаешь 1024 в ответ! Даже знать о том, что пишешь на JSES не нужно. А стоит узнать о том, как пользоваться переменными и всё — ты программист. И тут я понимаю всё негодование тех кто отучился не один год, чтобы написать свой первый хеловорд. Такая щемящая несправедливость просто, обязана не давать им покоя.


                                                                              Интерпретируемые языки имеют отличную от компилируемых парадигму разработки. Если для компилятора ты готовишь свою программу, пишешь, потом ещё пишешь, потом исправляешь и только потом компилируешь и наслаждаешься результатом. То в интерпретируемых скриптах мелкоитеративный цикл разработки, в котором ты смотришь на результат во время программирования (привет LiveReload), сверяя его с тем чего ожидаешь.


                                                                              Сделав изменение в одну букву, можешь сразу посмотреть результат и убедиться, что всё идёт так как задумано. В таких условиях недостатки отсутствия строгой типизации вываливаются сразу, а не накапливаются и выдаются в качестве непредсказуемых результатов после компиляции. Если складываешь цифру со строкой, то заметишь, что в результате у тебя не цифра. И это здорово. Пишешь интуитивно и лаконично. Сразу получаешь результат.


                                                                              А если с типом накосячил в компилируемом языке, притом в не очевидном месте, то можно провести не один час в поисках ошибки которую допустил час назад и строгая типизация тут и вправду помочь может. Но что, тебе поможет если ты перепутал две очень похожие функции, тем более если они отличаются в названии всего одним символом‽ Статическая типизация, компиляция, строгие правила — не панацея. Если ты достаточно везуч и любознателен, ты найдёшь способ выстрелить себе в ногу, даже если разработчики языка всеми силами стараются этому помешать.


                                                                              Но если ты хочешь программировать здесь и сейчас то, JS твой почти безальтернативный выбор. И помни, что наговнокодить можно на любом языке и только годы практики и танцев на граблях отделяют тебя от чистого кода (совершенного кода кстати не бывает, это вектор, а не точка). И на чём бы ты ни писал, год за годом ты будешь смотреть на свой код, написанный год назад и мысль — «Что за говнокод?», тебя не покинет.


                                                                              ЗЫ всё это моё личное мнение, я не учился в институте и руководствуюсь только своим опытом разработки на PHP/JS. Ну а то, что я так и не написал своё первое приложение на C++ это потому, что [irony]С++ плохой и сразу не работает[/irony]

                                                                              • +1

                                                                                Похоже слишком простыня вышла, извините за то, что вам пришлось читать этот поток сознания.


                                                                                Если коротко:


                                                                                Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.

                                                                                • +2
                                                                                  Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.
                                                                                  • +3
                                                                                    Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу

                                                                                    Если вы выходите за границы паттерна, то это уже ошибка.
                                                                                    Паттерны не делают вас тупее, они говорят как надо делать правильно (никто не машает вам разобраться почему именно так правильно).
                                                                                    А если вы выходите за рамки паттерна, значит уже делаете что-то не так.

                                                                                    Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.

                                                                                    А каким образом это сделает мир лучше?
                                                                                    Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?
                                                                                    Сомнительная польза для мира, да и для разработчика.
                                                                                    • –2
                                                                                      Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?

                                                                                      Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.


                                                                                      Слово переменная для них будет ассоциироваться не с погодой, а цикл станет не менструальным. Что в конечном итоге даже если они будут писать калькуляторы сделает их жизнь чуть проще, а они хоть и не большая, но часть мира. И если чуть лучше им, то чуть чуть лучше миру.


                                                                                      И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.


                                                                                      Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.

                                                                                      Возможно если поставить себе цель стать программистом то есть более подходящие языки.


                                                                                      Но у меня такой цели не было например. А была цель не править шапку сайта с играми в локалке на каждой странице и для решения этой задачи подошёл PHP с его include(), а потом ещё были задачи и он тоже отлично подходил.


                                                                                      Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее. Это была чужая прога и в исходниках не сказал бы, что удалось разобраться. Вся остальная часть сайта продолжала работать на PHP/MySQL и с этими задачами язык продолжал прекрасно справляться. Потом для решения задач понадобился JS и сейчас на нём писать классно.


                                                                                      А низкий порог входа означает низкое качество кода в целом.

                                                                                      В целом конечно. Но кто вообще это целое видел и зачем?


                                                                                      Я полагаю среде JS хватает высококлассных программистов которые пишут качественный код и могут на ревью джунов подтянуть.


                                                                                      Но от того, что нубы марают светлое лицо языка кому от этого хуже кроме статистики?


                                                                                      Если есть софт который написан некачественно, и софт которого нет — какой лучше?

                                                                                      • +2
                                                                                        И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.

                                                                                        Как то вы слишком крутите и филосовствуете.
                                                                                        На хрен это надо?
                                                                                        Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.
                                                                                        Этакий язык Шредингер — может все в теории, пока не проверишь на практике.

                                                                                        Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.

                                                                                        Я могу показаться немного адольфиком, но все же.
                                                                                        Если уже есть куча говнокодеров, которые прошли курсы, прочитали пару статей и книг, и считают себя программистами, то это не значит, что нужно вносить свою лепту в эту кучу говна.

                                                                                        Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее.

                                                                                        PHP для веба, а не для highload.
                                                                                        Все почему то этим упрекают РНР и говорят, что он говно.
                                                                                        Но по факту РНР и не для highload.
                                                                                        Как по мне, то нода тоже вряд ли справиться с такой нагрузкой.
                                                                                        Но это, как говориться, не точно.

                                                                                        Если есть софт который написан некачественно, и софт которого нет — какой лучше?

                                                                                        Очень и очень плохая позиция.
                                                                                        Где то рядышком с «зачем трогать если работает?».
                                                                                        В некоторых, не побоюсь даже, во многих вопросах пусть уж лучше нет ничего, чем кривой табурет с педалями на одной ножке.
                                                                                        • –1
                                                                                          Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.

                                                                                          Соглашусь JS крутой язык (моё субъективное мнение). Насчёт остального не от меня информация. Можно действительно многое. Но я нынче фронтенд программист, поэтому не искушён в забраузерных возможностях. Но в браузере оно будет работать без установки, на любой платформе где есть браузер. Без компиляции и скачивания инсталяторов. Кроссплатформенность — это круто.


                                                                                          От себя скажу, что написав функциональность на клиенте со сборкой SVG, я конечно не мог принимать результат на бэкенде. Там пришлось написать нечто похожее, принимающее только исходные настройки и повторяющее из них то, что видел в браузере пользователь. Это было проще чем фантазировать как победить XSS. Если бы на бэкенде тоже был на JS, то мне не пришлось бы после каждой правки переписывать и тестировать обе версии.


                                                                                          Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.


                                                                                          Я могу показаться немного адольфиком, но все же.

                                                                                          Это не круто.


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

                                                                                          Для того кто его сделал быть может он нужен (мало ли шоу какое устраивает), а ты можешь его не замечать и для тебя его не будет.


                                                                                          Но ты предпочитаешь замечать и выбиваешь у шоумена табурет из под ног потому, что табурет не правильный. Надеюсь у шоумена не было петли на шее. Извини, опять филлосовствую.


                                                                                          А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.


                                                                                          Мне кажется вообще все мастера из всех областей начинали с «куска говна» который потом выбрасывали, чтобы сделать новый «кусок чего-нибудь».


                                                                                          Отрывать им руки за первый блин, по Адольфски.

                                                                                          • 0
                                                                                            Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.

                                                                                            Вот все про это говорят, а кто нибудь может привести пример?
                                                                                            Это мой реальный интерес, очень часто слышу как достоинство JS + Node.js, но по факту это маловероятно.
                                                                                            Frontend — это абсолютно событийно-ориентированное программирование. Только события, ничего более.
                                                                                            Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
                                                                                            Ваш пример про SVG вполне можно перенести, но вот часто ли такое случается?

                                                                                            А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.

                                                                                            Абсолютно согласен.
                                                                                            И это применимо ко всему.
                                                                                            Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
                                                                                            И это опять такие мое, и думаю не только, мнение.
                                                                                            • 0
                                                                                              Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.

                                                                                              И в результате получить 42


                                                                                              По мне так вызов метода API это уже событие. Да, что там вызов метода. Запуск программы это тоже событие! А передача ей входных данных, ещё какое событие! Наступление определённого времени? Достижение конца файла? Подключение с определённого IP? Без тех или иных событий смысл в программировании сомнителен.


                                                                                              Или вы под событиями только onClick понимаете?


                                                                                              Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
                                                                                              И это опять такие мое, и думаю не только, мнение.

                                                                                              Сложнее станет выбирать себе поверхность без наклона? Или от них место в интернете закончится? С мнением я не спорю. Спорю скорее с тем, что взывает вас к сжиганию всего, что расходится с вашим чувством прекрасного.

                                                                                              • 0
                                                                                                Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.

                                                                                                Смотрели CQRS + Event Sourcing?

                                                                                                • 0
                                                                                                  CQRS

                                                                                                  Это вообще не про события

                                                                                                  Event Sourcing

                                                                                                  Ну, а также есть другие способы работы без событий.
                                                                                                  Я к тому, что МОЖНО на событиях организовать и бизнес-логику, и весь бэкенд, вот только на сколько это адекватно?
                                                                                                  • 0

                                                                                                    Вполне адекватно для больших систем

                                                                                                    • 0
                                                                                                      Нуууу, большого опыта в разработке больших систем у меня нет, а который есть никуда не годиться, но все же я думаю когда на выполнении одного экшена цепляется 10-20 событий, то отлаживать это достаточно трудоемко.
                                                                                                      Не считая того, что события в моделях (бизнес-логике) я считаю вообще не должны быть.
                                                                                                      Но это отдельный разговор, и кто я такой чтобы навязывать свое мнение)))
                                                                                                      • 0
                                                                                                        Можно увидеть сорцы хотя бы одной крупной системы на ноде с Event Sourcing архитектурой?
                                                                                                        • 0

                                                                                                          Разве кто-то говорил про ноду? :)
                                                                                                          Ну и подозреваю что сорцов таких систем в открытом доступе нет.
                                                                                                          А то, что я читал по этой технологии — это все .net, если кто поделится примерами под другие платформы, буду только рад

                                                                                                          • 0
                                                                                                            А разве речь не про ноду? Если нет, то хороший пример такой системы это 1С. Правда терминология немного другая:
                                                                                                            * Регистраторы = Event
                                                                                                            * Регистры = Events Store
                                                                                                            * Агрегаторы = Snapshot

                                                                                                            Говорят еще Redux работает в том же духе.

                                                                                                            В остальном самому интересна эта тема, частично даже применяем, но есть много минусов.
                                                                                                            • 0
                                                                                                              Ну раз уж на то пошло: а какие минусы возникают?))
                                                                                                              • 0
                                                                                                                Чтобы было более понятно, на минусы этого решения надо смотреть с точки зрения идеальной реализации, а это:
                                                                                                                1. Довольно ресурсоемко — далеко не везде вам требуется хранить историю событий, приведших к текущему снимку состояния сущности, а значит, вы будете тратить ресурсы впустую
                                                                                                                2. Сложно в тестировании — возможно тут проблема больше в инструментарии, нежели в решении, но такую систему сложно тестировать модульными тестами, и просто сквозными
                                                                                                                3. Новичкам взрывает мозги — для работы с такой системой нужно быть теоретически подкованным, иначе становится довольно сложно разбираться во всех этих неявных связях (немного помогают графы состояний и взаимосвязей компонентов в виде схемы)
                                                                                                                4. Сложность в реализации — событийная модель накладывает одно серьезное ограничение на архитектуру, она: «асинхронна» — на деле это означает, что вы не сможете выполнять синхронные операции над доменом, к примеру: «пользователь заполняет тест и сразу получает результат анализа»

                                                                                                                Есть и другие пункты, я просто их не могу пока припомнить. В остальном решение интересное, если его хорошенько изучить и правильно применить. По сути это паттерн «Команда», только немного в иной обертке и с другой областью применения, но с теми же плюсами и минусами.
                                                                                                                • 0
                                                                                                                  Спасибо, за развернутый ответ.
                                                                                                  • 0
                                                                                                    Вот все про это говорят, а кто нибудь может привести пример?

                                                                                                    Лично сталкивался только с примером для SVG, но сферически могу предположить:


                                                                                                    • Балансировку нагрузки между клиентом и сервером;
                                                                                                    • Преобразования форматирования для вывода на сайте или отправки электронных писем с сервера;
                                                                                                    • Генерацию\верификацию открытых\закрытых ключей;
                                                                                                    • Можно рендерить страницы на сервере и отправлять в IPFS;
                                                                                                    • Писать проверки данных на клиенте и использовать тот же код на сервере, чтобы не дать клиенту на эти проверки повлиять, но не плодить запросы к серверу;
                                                                                                    • Давать клиентам возможность на себе выполнять абстрактные операции, а по подписке принимать их на сервер;
                                                                                                    • Comming soon…
                                                                                          • 0
                                                                                            Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.

                                                                                            С одной стороны, да. А с другой — рынок наводняется неквалифицированными специалистами, из-за чего общая ценность этого занятия падает.

                                                                                            • 0

                                                                                              Сомневаюсь, что это негативно повлияет на ценность высококвалифицированных специалистов.

                                                                                        • +1
                                                                                          Код ниже вполне ок работает без ошибок (в браузере по крайней мере):

                                                                                          const a = { b: 1 }
                                                                                          a.b = 2


                                                                                          Все верно, однако присваивание a = {} выдаст ошибку, что вполне очевидно, на мой взгляд. С объектами const гарантирует, что ссылка будет всегда указывать на заданный при объявении объект. Для объектов с неизменяемыми полями следует смотреть в сторору Object.freeze().
                                                                                          • 0
                                                                                            В JS можно сделать разные виды «правильности», очень непохожие друг на друга. Это зависит от задач. Сравните, например, Angular приложение, написанное на ES6 (или Angular2 на TypeScript), и какой-нибудь jQuery-Plugin пятилетней давности (ну для кастом-скролла, например), написанные в одном файле на прототипах. Это как абсолютно разные вселенные со своими, иногда очень строгими правилами, но работающие в том же пространстве JS как механизма, который позволяет «очень много». В этом и есть главная сила JS.
                                                                                            • 0
                                                                                              А имелось ввиду, что const не работает с объектами.
                                                                                              Можно спросить у автора, что имелось ввиду, он даже здесь отметился.
                                                                                              Я рискну предположить, что const должен быть константой на все время работы приложения. То есть это реально должна быть константа. Как например в языке C#. const же в javascript работает так как readonly в С#.
                                                                                              То есть в функции вы можете написать const a = weatherOnMars === 42? 4: 2; И при первом выполнении функции a будет 4, при втором 2. То есть, по сути своей это не константа вовсе. В функциональных языках именно так себя ведет var(могу ошибаться).
                                                                                              • 0

                                                                                                На любом языке можно написать фигню.


                                                                                                Например, мне может захотеться сделать в плюсах #define true false, и писать исходя из этого. Или я могу захотеть сортировать массив пузырьком, чтобы найти максимум.


                                                                                                Так что читать мануалы и книги действительно нужно. В любом языке.

                                                                                              • +3
                                                                                                имхо: у js много неочевидных особенностей, отличающихся от других языков. Но, если понимать, как работает язык, то можно писать вполне хороший код. Проблема в том, что не все хотят копать внутрь и разбираться. Ну и низкий порог входа пораждает множество низкокачественного кода. А налажать в js очень легко )
                                                                                                • 0
                                                                                                  Потому что в JS приходит много школьников-верстальщиков, которым не хватает возможностей jquery и bootstrap.
                                                                                                • +8
                                                                                                  Можете наследовать через классы, можете через прототипы.

                                                                                                  Тот неловкий момент, когда забыл, что классы в JS работают через прототипы...

                                                                                                  • +1

                                                                                                    Тут разница в подходах. Когда говорят про прототипное наследование предполагается, что можно наследовать один объект через другой без создания классов:


                                                                                                    const proto = {
                                                                                                      hello () {
                                                                                                        return `Hello, my name is ${ this.name }`;
                                                                                                      }
                                                                                                    };
                                                                                                    
                                                                                                    const george = Object.assign(Object.create(proto), { name: 'george' });
                                                                                                    
                                                                                                    console.log(george.hello());

                                                                                                    И это порой очень гибко и удобно. С таким подходом, например, вы можете сделать factory, которая будет отлично альтернативой классам (и многим это нравится из-за отсутствия необходимости писать new)


                                                                                                    
                                                                                                    const greeter = (name) => Object.assign(Object.create(proto), {
                                                                                                      name
                                                                                                    });
                                                                                                    
                                                                                                    const george = greeter('george');
                                                                                                    
                                                                                                    const msg = george.hello();

                                                                                                    И надо понимать, что именно это базовый подход в js для наследования. А классы, которые используют под капотом этот же механизм просто вариант для тех, кто не видит наследования без них.

                                                                                                    • 0

                                                                                                      Не исключено, что это именно то, что имел ввиду автор.

                                                                                                      • +2
                                                                                                        Я далеко не гуру js, но обращаться в методе hello к this.name, которого нет, подразумевая, что потом где-то дальше будет Object.assign, в котором будет объект со свойством name — это уж сильно неочевидно…
                                                                                                        • 0

                                                                                                          Да, это инерция объектного подхода к программированию. Мне тоже тяжело давалось (и до сих пор дается) понимание что javascript'овый this — это не надежный java'вский this, а что-то ближе к сишным указателям. Отметил тенденцию, что все чаще встречается мысль, что можно и совсем без this в JS'е обходиться. Не спрашивайте как — я тоже далеко не гуру в JS :)

                                                                                                          • 0

                                                                                                            Да тут уже была статья на этот счет, в комментах хором сказали «а собсно зачем»? Да, он не везде нужен и много где можно без него, но насильно отказываться смысла нет. ООП и в частности инкапсуляция придумана не дураками и имеет свои удобства. Серебряной пули нету, надо уметь сочетать парадигмы:)

                                                                                                    • +17
                                                                                                      Ну, что можно сказать?
                                                                                                      Автор повторил свои мантры 3-летней давности о том, какой JS замечательный, мощный и безграничный (в смысле отсутствия границ для программиста: хочешь — стреляй в колено, а хочешь — в лодыжку) язык. Конечно, если ты идеальный (сферический в вакууме) программист, каковым себя автор, похоже, и считает. Хотя в его первой статье на хабре его поймали на том, что он сам толком не знает деталей поведения языка.
                                                                                                      Я — не профессиональный программист. Но считаю, что ценность языка программирования должна заключаться не в том, что он позволяет тебе застрелиться бесконечным количеством способов, а в том, чтобы с его помощью можно было написать программу с минимальным количеством ошибок, привлекая для этого многочисленных разработчиков средней квалификации, а не редких и дорогих гуру, познавших дзен JS.
                                                                                                      • –3
                                                                                                        Популярность JS говорит о том, что возможность написать программу (привлекая для этого кого-попало), которая работает, невзирая на ошибки, ценнее возможности написать программу с минимальным количеством ошибок, привлекая для этого многочисленных разработчиков средней квалификации.
                                                                                                        • +2
                                                                                                          Только вот сфера применения таких программ будет весьма ограниченной. Ну, сломалась веб-страница — и фиг с ней. Она же не ядерный реактор и не ракета-носитель в конце концов.
                                                                                                          Но автор-то позиционирует язык как универсальный, пригодный для любых сфер применения.
                                                                                                          • –1
                                                                                                            Вы пишите, что не программист, и при этом ругаете язык. Любите критиковать то, в чём не разбираетесь? Автор написал тонну текста и сделал пару описок, это вы называете незнанием деталей языка, а вы что знаете? Кто вы, менеджер, дизайнер, кто-то ещё? Я руководил программистами на JavaScript и средние программисты с ним справляются прекрасно, достаточно дать им наставления как можно делать, как нельзя, и составить базовую архитектуру. У JS очень низкий порог входа, что даёт возможность посадить кого угодно и научить его делать хорошие вещи, вся сложность языка закрывается на уровне технического руководителя. Ваши жалобы идут или от теоретизирования, или от невежества, не можете руководить программистами — меняйте профессию.
                                                                                                            • +1
                                                                                                              Я руководил программистами на JavaScript и средние программисты с ним справляются прекрасно

                                                                                                              Понимаете, в данном контексте «прекрасно» это сравнительная характеристика. «Прекрасно» должно быть не само по себе, а по сравнению с чем-то. Если бы вы руководили программистами на других языках, и они справлялись менее «прекрасно» с аналогичными задачами, тогда можно было бы о чем-то говорить. А у вас получается аргументация «я пишу на JS, больше ничего не знаю и знать не хочу, но меня все устраивает». Лично для вас этот аргумент конечно работает, но для остальных выглядит неубедительно.
                                                                                                              • +5
                                                                                                                Вы пишите, что не программист, и при этом ругаете язык. Любите критиковать то, в чём не разбираетесь?

                                                                                                                Я пишу, что я не профессиональный программист (т.е. что не зарабатываю этим себе на жизнь), а не то что я не программист.
                                                                                                                А профессиональный программист (как, впрочем, любой инженер вообще) просто обязан пользоваться максимально точным языком. Хотя, возможно, долгое использование JS могло вызвать такой эффект.
                                                                                                                Так вот, я не менеджер и не дизайнер. Я инженер-системотехник, специальность «Вычислительные машиины, комплексы, системы и сети». Поэтому чуть-чуть разбираюсь в теме. И критикую я не язык, а необъективное его восхваление. Как уже было написано до меня, JS — замечательный язык для той сферы применения, для которой он был изначально создан. Не более того.
                                                                                                                Автор написал тонну текста

                                                                                                                Автор написал даже 2 тонны текста — 3 года назад и сейчас. И, по сути, ни одного аргумента почему JS восхитителен кроме «могу писать как хочу» так и не привел.
                                                                                                                и сделал пару описок

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

                                                                                                                Это не жалобы, и они, соответственно, никуда не идут. Это констатация фактов.
                                                                                                          • 0

                                                                                                            Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.

                                                                                                            • 0
                                                                                                              Автор вовсе не говорил, что возможность застрелиться большим количеством способов — непревзойдённое преимущество. Автор говорил именно о свободе действий — да, в том числе и свободе стреляться.

                                                                                                              Дабы не быть голословным, покажу код.
                                                                                                              Есть у меня библиотека для рисования на канвасе DeltaJS (ранее известная как Graphics2D.js, я даже писал о ней на Хабре). Сейчас она в фазе активного переписывания и дописывания, и её можно найти вот тут: https://github.com/keyten/Graphics2D

                                                                                                              В ней можно создать квадрат на канвасе:
                                                                                                              ctx.rect(10, 10, 200, 200, 'red');


                                                                                                              Каждая из координат прогоняется через функцию `Delta.distance`.
                                                                                                              Вдруг в какой-то момент разработчик вспомнил, что существует Ретина, и захотел рисовать квадраты с шириной не в px (пикселях), а в pt. Что ж, он делает так:
                                                                                                              var oldDistance = Delta.distance;
                                                                                                              Delta.distance = function (dist) {
                                                                                                               if (isPtDist(dist)) {
                                                                                                                return convertPtToPx(dist);
                                                                                                               }
                                                                                                               return oldDistance.apply(this, arguments);
                                                                                                              }
                                                                                                              


                                                                                                              И всё, благополучно можно писать
                                                                                                              ctx.rect('10pt', '10pt', '200pt', '200pt', 'red');
                                                                                                              

                                                                                                              Вообще-то все css-единицы итак поддерживаются в Delta, однако distance всё ещё может быть переопределение, чтобы добавить, например, полярные координаты или какие-нибудь специальные координаты в условиях специального Layout. По факту, distance специально вынесена как публичная функция, чтобы её можно было переопределить, тем самым вмешавшись в логику всей библиотеки, меняя лишь маленький кусочек. Требование при переопределении одно: возвращаться должно число. В пикселях.

                                                                                                              Если мне понадобится что-то более существенное, например, изменить порядок аргументов функции или добавить новые, я могу переопределить Delta.Context.prototype.rect.

                                                                                                              И подобных точек вмешательства несколько. Можно вмешаться в логику attr (Delta.Drawable.prototype.attr), добавив или изменив своё в attrHooks. Вмешаться в логику событий через eventsHooks. Через тот же attrHooks вмешаться в логику animate.

                                                                                                              Обсуждая это с людьми, пишущими на плюсах, я спросил, как с этим справляются они. Что, если захочется добавить дополнительный параметр в std:sort или научить новому методу std:string?
                                                                                                              Никак — ответили мне. Так ты можешь только выстрелить в ногу.
                                                                                                              Но… — попытался возразить я.
                                                                                                              Никаких но. Нога.

                                                                                                              Между тем, jQuery таким образом существует уже фиг знает сколько лет. Со своими плагинами и многим другим. Ты можешь добавить на страницу сто плагинов, которые вмешиваются во внутреннюю логику jQuery и меняют разные куски, и — внезапно окажется, что у кода на js настолько большой запас прочности, что это всё будет отлично работать и синхронизироваться друг с другом, делая ровно то, что ты от них ожидаешь. Даже если меняют ровно одно и то же (при этом сохраняя предыдущее переопределение функции и передавая ему управление, если нужно).

                                                                                                              Да, иногда плагины бывают несовместимы. Но это не отменяет того, что концепция крутая и работает.
                                                                                                              • 0

                                                                                                                Упс, прошу прощения, неправильно выразился.
                                                                                                                Стоило написать так: представь, что ты пишешь std:sort или std:string, и захотел разрешить в каком-то месте их расширять.
                                                                                                                Да, в определенных пределах, выход за которые грозит отстрелом ноги.

                                                                                                                • 0
                                                                                                                  Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.

                                                                                                                  Я не рискну выразить в двух словах что такое знание языка. Тем более, как я уже указал выше, я — не профессиональный программист. Но, IMHO, знание неочевидных особенностей этого языка туда входит.

                                                                                                                  Поясню на примере естественных языков. Мы говорим на русском и не считаем его сложным. Но на деле это такой себе JS среди естественных языков — очень много конкретных случаев, которые нужно знать вместо малочисленных четких правил. К примеру, ударения. В русском языке правил для них нет вообще! Нужно знать все(!) случаи. И это ад для любого человека, родной язык которого имеет правила для ударений.
                                                                                                                  Причем даже носители русского языка делают кучу ошибок в ударениях, причем даже в очень распространенных словах, типа «позвОнишь» вместо «позвонИшь».
                                                                                                                  Или можно взять случаи, когда носители делают ошибку в грамматическом роде существительных — «шампунью» вместо «шампунем».
                                                                                                                  В общем, большинству всей жизни не хватает для того, чтобы грамотно научиться говорить по-русски.
                                                                                                                  И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.

                                                                                                                  Автор вовсе не говорил, что возможность застрелиться большим количеством способов — непревзойдённое преимущество. Автор говорил именно о свободе действий — да, в том числе и свободе стреляться.

                                                                                                                  Только свобода застрелиться как раз и вытекает из свободы «вообще». Причем на практике (скорее всего) первое будет превращаться во второе.
                                                                                                                  Взять тезис о том, что если программа вместо аварийного прекращения продолжает стараться хоть как-нибудь работать дальше — это хорошо. Ну, на самом деле. Программа завершилась с ошибкой — это же кошмар. Надо же искать ошибку, исправлять ее, это ж лишняя работа. А так программа кое-как работает, пусть неправильно, ну и что? Ведь правильность не самое главное, верно? Зато разрабатывается быстро!
                                                                                                                  То же самое насчет системы типов, насчет статического анализа.

                                                                                                                  Я даже могу не знать вообще абсолютно ничего о языке. Если язык позволяет делать какую-то ошибку — люди обязательно ее сделают. И в случае с JS это означает, что люди делают гораздо больше ошибок, чем в других языках. Обязательно.

                                                                                                                  При этом доводы о том, что в JS можно сделать то, что в других языках сделать нельзя, меня не впечатляют.
                                                                                                                  Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
                                                                                                                  ctx.rect(10, 10, 200, 200, 'red', CSS_PT);
                                                                                                                  ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
                                                                                                                  

                                                                                                                  Тогда можно будет единообразно рисовать эти самые квадраты независимо от единиц измерения, например в цикле. В вашем же случае с «мощным переопределением» для px нужно передавать числа, а для pt — строки, которые нужно еще и сформировать. Нет, конечно же, можно сделать и переопределяемую функцию рисования квадратов в цикле… Но зачем???
                                                                                                                  Я допускаю, что раз в году найдется такой пример, который без переопределения никак нельзя сделать. Но, блин, на мой взгляд, вы используете не потому, что без этого никак или смертельно неудобно, а потому что можно и потому что привыкли. и иначе уже просто не мыслите.
                                                                                                                  • 0
                                                                                                                    Если задуматься, многие сегодняшние недостатки JS 20 лет назад были его достоинствами. Web ведь строился по Robustness принципу — «be conservative in what you do, be liberal in what you accept». Отчасти это и обеспечило ему взрывной рост. Невалидная разметка, некорректные заголовки, кривой код — браузер все проглотит и не поперхнется. В эпоху, когда джаваскрипт использовался для придания динамики веб-страничкам, это реально было плюсом.

                                                                                                                    Но время прошло, и JS превратился в промышленный язык. А от детских болезней избавиться так и не смог. Сообщество (за исключением некоторых фанатов, которых мы здесь наблюдаем) понимает его недостатки, но избавиться от них не могут из-за обратной совместимости.

                                                                                                                    В этом и состоит основной недостаток JS — сложившаяся экосистема не позволяет сломать обратную совместимость, вследствие чего детские болезни остаются в нем навсегда, а развитие происходит в основном за счет синтаксического сахара и костылей типа Symbol.
                                                                                                                    • –2
                                                                                                                      Я тоже хотел привести пример с естественными языками ). Но больше в том плане, что приходить в английский и говорить «у вас неправильно, потому что у вас перфекты, вот смотрите, у нас в русском всего 3 времени, и нам норм» (что, к слову, не так, перфекты в русском вроде бы вполне себе есть) — как минимум, не очень правильно.

                                                                                                                      И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.

                                                                                                                      Сравнивать языки программирования и естественные тоже не очень правильно по очевидной причине. Правильнее сравнивать ЯП с эсперанто, токи пона, ифкуилем, илакшем и иже с ними.

                                                                                                                      А так программа кое-как работает, пусть неправильно

                                                                                                                      А может, внезапно, работать правильно! Хотя бы чуть-чуть.
                                                                                                                      Вот я пишу-пишу в программе на Java, и вдруг там непойманный exception в одном из модулей, и вся программа вылетает. И мой несохранённый документ… тоже вылетает.
                                                                                                                      А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.

                                                                                                                      Если я правильно понял ваш пример.

                                                                                                                      Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
                                                                                                                      ctx.rect(10, 10, 200, 200, 'red', CSS_PT);
                                                                                                                      ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
                                                                                                                      

                                                                                                                      Напрашивается заметить, что все 4 параметра могут быть в разных системах координат, а там ещё есть и цвет, и делать ещё 5 доппараметров в функции как-то некрасиво, как минимум.

                                                                                                                      Но тут гораздо важнее иное: логика превращения каких-то единиц в пиксели может быть достаточно сложной (сложнее, чем взять константу и, например, умножить на число). Ну, например, я написал плагин для изометрии и хочу делать так (пример немножко утрированный):
                                                                                                                      var pointInIsometria = {
                                                                                                                       plane: planeObject,
                                                                                                                       rectOfPlane: [x, y, z]
                                                                                                                      };
                                                                                                                      
                                                                                                                      ctx.rect(pointInIsometria, pointInIsometria, 200, 200, 'red');
                                                                                                                      // или даже так:
                                                                                                                      ctx.rect(planeObject, [x, y, z], 200, 200, 'red');
                                                                                                                      

                                                                                                                      Кроме того, мне не нужно добавлять какие-то дополнительные параметры, чтобы позволять что-то расширять. Я по умолчанию разрешаю это делать практически со всеми своими объектами и методами (но с риском выстрелить в ногу, разумеется). И совершенно не забочусь, что пойдёт, если кто-то расширит как-то не так.
                                                                                                                      На ум пришла аналогия: это как продавать машину, разрешать на ней менять колёса, двигатель и дворники (компоненты, хочу заметить, вполне себе самостоятельные, и замена любого из них на делающий то же, но по-другому, и предоставляющий тот же io-интерфейс, не ломает систему в целом), но забивать на гарантию в случае нестоковой комплектации ).

                                                                                                                      P.S.
                                                                                                                      Признаться, я совершенно не думал о доппараметре в функции (хоть он тут и совсем не к месту). Из той же библиотеки у меня есть интересный пример, связанный с прототипным наследованием. Интересно, сможете ли вы реализовать подобное на C / C++, например? Да и на любом языке без прототипов, вообще говоря, было бы интересно.

                                                                                                                      У меня у объектов на канвасе есть функция attr. Она возвращает / изменяет значение во внутреннем хэше объекта:
                                                                                                                      rect.attr('x'); // -> 20; работает как getAttr
                                                                                                                      rect.attr('x', 200); // работает как setAttr
                                                                                                                      

                                                                                                                      Но кроме этого она проверяет наличие геттера / сеттера в объекте attrHooks в классе, и дёргает его. Например, на изменение координат прямоугольника дёргается перерисовка.

                                                                                                                      Фишка в том, что есть несколько классов (Rect, Circle, Path, Image, Text), которые наследуются от абстрактного класса Drawable. У Drawable есть свои общие attrHooks, и у каждого из классов есть свои специфические. При этом я хочу, чтобы при добавлении новых методов в attrHooks у Drawable они появлялись у всех его наследников (если они там не перезаписаны, естественно). Но не наоборот — специфические attrHooks у Rect не должны затрагивать attrHooks у Drawable.
                                                                                                                      На прототипах это реализовалось достаточно легко:
                                                                                                                      function drawableAttrHooks() {}
                                                                                                                      Drawable.prototype.attrHooks = drawableAttrHooks.prototype;
                                                                                                                      
                                                                                                                      Rect.prototype.attrHooks = new drawableAttrHooks();
                                                                                                                      
                                                                                                                      // теперь если я напишу
                                                                                                                      Drawable.prototype.attrHooks.someProperty = 5;
                                                                                                                      // то оно прокинется в Rect:
                                                                                                                      Rect.prototype.attrHooks.someProperty; // -> 5
                                                                                                                      // но в обратную сторону это не действует:
                                                                                                                      Rect.prototype.attrHooks.someAnotherProperty = 8;
                                                                                                                      Drawable.prototype.attrHooks.someAnotherProperty; // -> undefined
                                                                                                                      

                                                                                                                      • +2
                                                                                                                        А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.

                                                                                                                        Это если вам очень повезло. Довольно часто можно оказаться в ситуации, что сохранить-то удалось, а ошибка была в каких-нибудь внутренних структурах. В итоге сохранён мусор. Тихая порча данных засчёт проглоченной ошибки — куда более неприятная ситуация, чем просто падение.

                                                                                                                • 0
                                                                                                                  Вы знаете...Node популярна(я это и в той ветке написал)… Что её коэффициент Эффективность/Простота=Очень высок...java тоже эффективна, но не простая.(с Другими языками не знаком).
                                                                                                                  Есть вещи которые бы не рискнул разрабатывать на node(Это связанно с ООП и с глубоким наследованием)…
                                                                                                                  • –2

                                                                                                                    Респект автору, согласен на 200%. Хейтить то, чего не понимаешь — обычное человеческое свойство, но будучи инженером — ты, имхо, должен быть осторожее и объективнее. Легко называть всех вокруг идиотами, но будте готовы потом доказать что сами не идиот. Хейтеры, по моему опыту, доказать этого чаще всего не могут, а споры "о вкусах" тут не имеют смысла, ибо значение имеют только "pros/cons".

                                                                                                                    • +1
                                                                                                                      Тут дело немного в другом: JS позволяет делать ВСЕ что хочешь, с очень небольшими ограничениями, и множеством вариаций.
                                                                                                                      И сейчас «мир раскололся» на 2-3 лагеря:
                                                                                                                      1. те кто любят псевдосвободу и придерживаются позиции «сам дурак», а JS красавчег
                                                                                                                      2. те кто считают, что инструмент должен минимизировать ошибки разработчика.
                                                                                                                      3. все остальные

                                                                                                                      Основной аргумент 1 лагеря и автора статьи, это то что если программист нормальный, то все будет ок.
                                                                                                                      Но если программист норм, то проблем в принципе не должно быть.

                                                                                                                      JS (как инструмент) никак не уменьшает число ошибок, а наоборот местами способствует их появлению, зато имеет низкий порог
                                                                                                                      Но надо оговориться, порог вхождения в программки типа «Hello World» действительно низкий, а вот порог вхождения в мир качественной разработки, ни чуть не ниже чем у других «ограничивающих свободы» языков.
                                                                                                                      • 0
                                                                                                                        Я бы сказал даже выше. Как раз потому, что нет ограничений.
                                                                                                                        • +1
                                                                                                                          Зачем тогда люди так сильно до сих пор любят C/C++? Где в этом мире единорогов прекрасный паскаль? Почему так слабо популярен хаскель, который вроде как декларирует, что если программа собралась — значит, в ней нет ошибок?

                                                                                                                          ЗЫ Печально видеть, что JS всё больше тянут в сторону Java, нежели скажем Python.
                                                                                                                          • 0
                                                                                                                            Порог вхождения.
                                                                                                                            Популярность и эффективность/правильность/качество — это к сожаления далеко не одно и тоже.
                                                                                                                            Очень далеко.
                                                                                                                            И, опять таки к сожалению, низкий порог вхождения, как раз таки в большей степени и определяет популярность.
                                                                                                                            • 0
                                                                                                                              Потому что вокруг хаскеля ореол академичности, отсутствие поддержки крупных корпораций на уровне продакшена и, соответственно, курино-яйцевая проблема отсутствия людей для поддержки проектов на нем.
                                                                                                                              • 0

                                                                                                                                По моему скромному опыту хаскель требует невиданных теоретических познаний от простых разработчиков, которые являются основной целью найма.

                                                                                                                                • 0
                                                                                                                                  Невиданные теоретические познания нужны, чтобы писать библиотечный код, но вы в любом языке простых разработчиков вам библиотеки ваять сажать не будете.

                                                                                                                                  Чтобы писать не сильно performance-critical-код, даже семнатику ленивых вычислений не обязательно достаточно хорошо понимать.
                                                                                                                        • +1
                                                                                                                          Спор надо вести не о том, плох ЯП или хорош, но о том, готовы ли мы оплачивать свободу потенциальными ошибками, или безошибочность свободой. Мне кажется, для высококлассных разработчиков верно первое.
                                                                                                                          • +3
                                                                                                                            если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти.

                                                                                                                            Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались.

                                                                                                                            я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю.

                                                                                                                            Перечитайте про duck typing и научитесь им пользоваться

                                                                                                                            А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.


                                                                                                                            Общий посыл статьи понятен — язык великолепный, просто вы не умеете программировать)

                                                                                                                            const a = 5
                                                                                                                            const a = 4
                                                                                                                            VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared


                                                                                                                            А если попробовать так:

                                                                                                                            const a = 5;
                                                                                                                            a = 4;
                                                                                                                            


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

                                                                                                                              "use strict";
                                                                                                                              const a = 5
                                                                                                                              undefined
                                                                                                                              a = 3
                                                                                                                              VM156:1 Uncaught TypeError: Assignment to constant variable.
                                                                                                                                  at <anonymous>:1:3
                                                                                                                              

                                                                                                                              Хром умеет такое вылавливать, тут уже вопросы к разработчикам движков.
                                                                                                                              • 0

                                                                                                                                Uncaught TypeError: Assignment to constant variable.
                                                                                                                                я буду обновлять комментарии перед написанием своего

                                                                                                                              • +1
                                                                                                                                В большинстве случаев проблема не в языке (или каком-либо другом инструменте), а в том, кто им пользуется и что от него ожидает. Привычка — вторая натура и себе любимому проще сказать: «Это не ты не знаешь как пользоваться, это язык (инструмент) хреновый.» А заставить себя посмотреть критично и допустить возможность другого подхода часто бывает очень сложно. Думаю, все с этим сталкивались.
                                                                                                                                • +1
                                                                                                                                  В JavaScript два основных варианта работы с модулями:

                                                                                                                                  Ещё одно важное уточнение по поводу модулей. Их не 2, а больше. Первый действительно официальный и прописан в стандарте. Второй вариант называется common.js. А есть ещё amd. И говорить, что эти способы совместимы друг с другом неверно. Как минимум, commonjs и es6 modules не совместимы (про amd не в курсе, не использовал). Суть в том, что es6 modules асинхронны по своей природе, в то время как commonjs синхронны и модуль выполняется в момент подключения. Именно поэтому возникла большая проблема с интеграцией es6 модулей в ноду. Подробнее

                                                                                                                                  • 0
                                                                                                                                    • +1
                                                                                                                                      но согласитесь, до руби ещё далеко. тот ещё прекраснее.
                                                                                                                                      и дело даже не в наличии у джаваскрипта хоть какой-то ecma-спеки.
                                                                                                                                      как мне показывали, руби восхитителен вплоть до превращения класса в переменную типа стринг, с естественным «обломом» при попытке создать объект этого класса после такого финта ушами.
                                                                                                                                      особенно это прекрасно, если этот финт ушами проделал падаван в левом подключенном модуле, при попытке дополнить класс «очень нужными мегафичами».
                                                                                                                                      • 0
                                                                                                                                        class ololo { 
                                                                                                                                          constructor() { this.hello = 'Привет';}
                                                                                                                                        }
                                                                                                                                        class hohoho extends ololo {
                                                                                                                                          toString() { return this.hello; }
                                                                                                                                        }
                                                                                                                                        let bathert = `${new hohoho}`;
                                                                                                                                        console.log(bathert);

                                                                                                                                        JS может всё, или Ruby может так?


                                                                                                                                        class ruby {
                                                                                                                                         constructor() {this = 'Строка'}
                                                                                                                                        }

                                                                                                                                        JS второй пример не может

                                                                                                                                        • 0
                                                                                                                                          class ruby {
                                                                                                                                          constructor() {this = 'Строка'}
                                                                                                                                          }

                                                                                                                                          Страшно представить, что это

                                                                                                                                          • –1
                                                                                                                                            это был, сарказм, бро