• Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –1
    Если вы не планируете её менять, зачем писать код с учетом этого?

    потому что я не планирую запрещать её дальнейшее использование, оно ничего не ломает. Мне кажется я повторил это уже раз 20. Вы точно попытались осмыслить?


    В 90% (оценочное суждение из головы) случаев никто ваш код трогать не будет никогда. В 9.5% случаев его удалят целиком не читая

    у меня другой опыт: пишется один раз, дорабатывается 10 раз, читается 100 раз. Вы реально постоянно всё с нуля переписываете?

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –2
    Зачем?

    для дальнейшей доработки кода.


    На дальнейшее я могу ответить только в том же духе, но не хочу.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Повсеместно да, в ООП он нужен либо на самом верхнем уровне модуля, либо в редчайших исключительных случаях внутри функций. Я как бы с первого комментария об этом говорю.
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Вооот), замыканий исчезающе мало либо вообще нет, а значит что? Значит если взять любую переменную в любом методе, то перейдя в место после её последнего использования можно делать с ней всё что угодно, хоть слона туда засовывай, ничего гарантированно не сломается. Правильно? То есть на первый взгляд вообще пофигу let или const. Но не совсем, const при дальнейшей доработке кода будет постоянно заставлять заменять его на let бесполезно тратя наше время. Пользы же он будет давать ровно ноль. В результате приходим к варианту повсеместного использования только let, кроме самого верхнего уровня. То есть const где-то ещё совсем не должен встречаться, а если встречается, то скорей всего с кодом что-то не так.
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Если изменить любую в одном методе, то соседний может сломаться, с этой точки зрения вполне себе)
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0

    Ага:


    const PATH = require('path');
    const FS = require('fs');
    const GULP = require('gulp');
    const GULP_DATA = require('gulp-data');
    const NUNJUCKS_RENDER = require('gulp-nunjucks-render');
    const { t as T } = require('@riim/gettext');

    Как-то так себе получается.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –2

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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Ну как бы и я про тоже, что замыканий с не константами в ООП получается совсем мало. Или я неправильно вас понял?
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    больше восьми, ну максимум десяти

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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –1

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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    А замыкания в JS используются часто.

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


    class SomeView extends View {
      onBtnClick() {
        let btn = $('btn');
        btn.disable();
        request.get(...).then(res => {
          btn.enable();
          // ...
        });
      }
    }

    вроде замыкание, но такого в коде по-хорошему вообще не должно быть. Вот как мне теперь переопределить только обработку ответа при наследовании? Соответственно переписываем так:


    class SomeView extends View {
      initialize() {
        this.btn = $('btn');
      }
      onBtnClick() {
        this.btn.disable();
        request.get(...).then(this.onResponse);
      }
      @autobind
      onResponse(res) {
        this.btn.enable();
        // ...
      }
    }

    Опа-на и нет замыкания)). Причём избавлялись от него не ради избавления от замыкания, а по совершенно другой причине и такая причина в ООП всегда находится.
    Плюс есть async/await, то есть даже если точно не нужно выносить обработку в отдельный метод, то так:


    class SomeView extends View {
      async onBtnClick() {
        let btn = $('btn');
        btn.disable();
        let res = await request.get(...);
        btn.enable();
        // ...
      }
    }

    В результате в примерно 35 просмотренных крупных файлов въюшек и стора я не увидел ни одного замыкания с не константой. В файлах сборки тоже не нашёл такого, в основном колбеки в виде чистых функций. Максимум встречаются замыкания с константами:


    const gulp = require('gulp');
    
    gulp.task('some-task', () => {
      return gulp. // ...

    но это опять же к нашей ситуации не относится.
    В результате


    Если ссылка никогда не меняется — её безопасно использовать в любых замыканиях.

    совсем слабенький аргумент получается. По крайней мере для не функционального стиля, но я про это сразу написал:


    Моё мнение — const по умолчанию хорош только при чисто функциональном стиле программирования. В остальных случаях лучше воспользоваться правилами из той же статьи:

    В любом случае это пока единственный хоть сколько-то весомый аргумент за повсеместный const из тех что пока прозвучали.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –1
    из легаси

    ну в легаси всё что угодно может твориться, здесь сложно что-то оценивать.


    не затрёте ссылку, которую коллега решил сделать неизменяемой

    как не затру, вот я нахожусь в каком-то месте кода, вижу $element, вижу, что это константа, если const расставлялся осмысленно, то да, не затру, ведь мне явно сказано не трогать, а так я лишь знаю, что пока ещё не менялась и всё, скорей всего можно менять просто заменив const на let. Ладно, я проверю точно ли можно так делать, но вот что там делает коллега с его хотфиксом я не знаю. А дальше получаем:


    из легаси
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0

    У меня линтер заставляет обёртывать такое в дополнительные скобки:


    if ((a = b)) {

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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Верно, и всё же пользы от этого на мой взгляд явно меньше.
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –1
    Он значит неизменность ссылки. Это может быть полезно и, как минимум, не хуже let.

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


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

    помечено константой — не трогай, создай новую привязку, польза остаётся. Если же нужно как-то поработать именно с этой константой, то да, нужно будет оценить остался ли запрет на изменение.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –3

    Есть там альтернативный смысл или нет, но кода может быть просто много:


    const $element = $(...);
    
    // много кода
    
    $element.on("foo", e => {
        $element.bar();
    });
    
    // много кода
    
    // а здесь вам стала интересна константа $element

    имя для новой переменной придумывать не хочется, может эта сгодится? Как вы это поймёте? Ведь const при его повсеместном использовании не значит ровно ничего.


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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0

    Так там как раз пример правильного использования const. Там константа и кто-то правильно запретил её менять. Вы привели пример к этому тексту:


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

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

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –2
    const на let можно менять только после анализа всех мест использования.

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


    не следует считать что все вокруг так же делают.

    как вы делаете такие выводы? Вы блондинка? Окей, разжую, я имел ввиду, что при обдуманном изменении let-переменной действительно ничего не сломается.


    Вы так пишете, как будто всегда можно поменять let-переменную и ничего нигде от этого не поломается...

    Да, ничего не сломается если всё сделано правильно и это действительно была переменная, а не константа.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –3
    Как мило, адепты повсеместного const минусят также бездумно как и ставят const)). Уверен, большинство даже не пыталось осмыслить написанное.
  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    0
    Ага, если бездумно менять код, то он сломается, const от этого не спасёт, ведь при повсеместном его использовании вы как обычно просто замените const на let и он точно так же сломается. А было бы использование const осмысленным, может это и помогло бы.

  • Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]
    –3
    всегда используйте const, кроме случаев когда не можете, тогда используйте let

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


    Цитата из этой статьи:


    Действительно ли вы хотели сообщить, что ответ никогда не должен меняться, или просто так совпало, что вы нигде его не меняли?

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

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

    Простой пример: я написал код в котором всё неизменяемое бездумно отмечено константами, кто-то чуть доработал мой код и теперь одна из привязок стала реальной константой, дальше я дорабатываю этот код начиная менять эту переменную и что-то где-то ломаю. У автора предыдущего изменения просто не было возможности сообщить о том, что он теперь против изменения этой привязки. Ну не писать же ему так:


    const a = 5; // точняк константа

    Выглядит как-то глупо. Да и я не виноват в этой поломке, ведь при повсеместном использовании const замена его на let, при доработке кода, становится обычной практикой. Ну не устраивать же каждый раз полный анализ близлежащего кода пытаясь выяснить не является ли эта привязка реальной константой. Виноват здесь исключительно человек навязавший использование const по умолчанию.


    Моё мнение — const по умолчанию хорош только при чисто функциональном стиле программирования. В остальных случаях лучше воспользоваться правилами из той же статьи:


    1.Используйте const только в самой верхней области видимости
    За всю жизнь не припомню случая, чтобы привязка, созданная внутри функции, расстроилась от своего изменения.

    2.Старайтесь не использовать let в самой верхней области видимости
    С другой стороны, если вам понадобился let в самой верхней области видимости, это знак, что у вас что-то типа глобального синглтон-состояния, от которого могут быть проблемы.
  • Почему в основе каждого нового веб-приложения в PayPal лежит TypeScript?
    +2
    Прикручивал типы к текущему проекту, начитавшись статей о крутом выводе типов в flow выбрал его. Типизировав примерно четверть отказался от flow в пользу typescript. Причина ровно та же, что и в статье, мне просто не удалось заставить его стабильно работать, постоянно какое-то неадекватное поведение исправляемое только перезапуском. С инструментом приходится буквально нянчиться как с ребёнком, бесконечно уделяя ему время. Это, конечно, интересно когда только осваиваешь инструмент, но в какой-то момент хочется уже получать с него профит, а не продолжать нянькаться. С typescript тоже бывают подобные проблемы, но редко. Например, можно создать в проекте большое кол-во ошибок, скажем удалением node_modules, и после их исправления в редакторе всё станет нормально, а вот сборка продолжит показывать ошибки, помогает только перезапуск. Но это уже скорее проблема пакета awesome-typescript-loader или webpack-а, а не самого typescript.
  • Самое краткое введение в Reactive Programming
    0
    Код я генерирую обычно за ЗП, здесь я вам ничего не должен, а холивар здесь только от вашего нежелания признать очевидное.
  • Самое краткое введение в Reactive Programming
    0

    всё правильно, это мои слова, для меня это действительно не сложная задача, но я же не говорил, что хочу потратить ещё пол часа своего времени.


    Я как раз тут проблему вижу

    в чём проблема, в задаче? Вы действительно считаете её нерешаемой без потоков, серьёзно? Что там в потоках по вашему, божественный эфир? Или проблема в вас? Тогда это тем более в ваших интересах, потренируетесь. А то на собеседованиях уже страшно просить что-то простейшее написать.

  • Самое краткое введение в Reactive Programming
    0
    можно отменить «все»

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

  • Самое краткое введение в Reactive Programming
    0
    Вы использовали готовый метод сделанный именно под вашу задачу, на это не нужно много времени и умения, я же предлагаю вам решить эту интереснейшею задачу на чистом js. Мне кажется будет честно, если мы будем тратить одинаковое время впустую, а иначе вы начнёте перечислять другие возможности highland или конкретно этого метода, а мне сидеть и переписывать всё это на чистом js? Нет уж), либо признайте, что потоки в данном примере не обязательны, либо давайте по очереди.
  • Самое краткое введение в Reactive Programming
    0
    в вашем коде навскидку 70 cтрок
    в моем 10

    причём тут количество строк? Ок, представьте другую библиотеку внутри которой ratelimit на основе моего кода. Представьте в lodash завтра появляется ratelimit реализованный без потоков. Как теперь докажете необходимость РП?


    буду рад если вы укажите ссылки на лучшие примеры

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

  • Самое краткое введение в Reactive Programming
    0
    понимайте о чем я?

    понимаю, так ещё оптимальнее, но не вижу проблемы написать и это без потоков, навскидку, мне кажется, даже кода меньше получится (чем сейчас в примере выше). Только давайте по очереди? Мне просто не особо интересно такие задачки решать. Попробуйте сами, а я уже попробую сделать ещё проще.

  • Самое краткое введение в Reactive Programming
    0
    Вы считаете, что складывать задержку и самый долгий запрос не нужно, а просто использовать самое долгое из них? Да, так оптимальнее. Доработать пример до этого минутное дело.
  • Самое краткое введение в Reactive Programming
    0
    В общем, самый долгий запрос из пачки плюс задержка. Если самый долгий 1 сек. и задержка 1 сек., то 2 секунды.
  • Самое краткое введение в Reactive Programming
    0
    вы предлагаете написать штуку которая решает одну задачу

    почему нет?


    Хотя вопрос риторический, мне не нужно объяснять зачем объединять что-то в библиотеки, речь не про это, я говорю, что приведённый вами пример в статье никак не показывает плюсов реактивного программирования, а его ключевая часть легко переносится в другие библиотеки никак не связанные с РП. Если бы мне так объясняли РП я бы сказал "круто", но никогда бы не стал его использовать для себя.

  • Самое краткое введение в Reactive Programming
    0
    Ошибся в комментарии, через 6 конечно, в коде этот момент правильно сделан.
  • Самое краткое введение в Reactive Programming
    0
    Через 5, там Promise.all внутри, почитайте код, там же мало совсем, 3 минуты разобраться ;)
  • Самое краткое введение в Reactive Programming
    0

    да)), про это я и написал:


    UPD: накосячил конечно немного, но суть я думаю понятна.

    Поотлаживать конечно не помешает, считайте, что это псевдокод демонстрирующий как это делать без потоков.

  • Самое краткое введение в Reactive Programming
    0
    Вы согласны с тем что эта задача не настолько тривиальна, как кажется на первый взгляд?

    честно, нет, для меня сложность сразу ясна.


    давайте исходить из того что в красивый интерефейс можно что угодно завернуть

    вы же не хотите сказать, что внутри highland что-то более простое чем я предложил?

  • Самое краткое введение в Reactive Programming
    0
    Потому что их там всего 5 и они разделены на пачки по 3. Сперва отправляются 3 запроса, после ответа на все (там случайная задержка подставляется) отправляются ещё 2, после ответа на оба выводятся все результаты. В общем, в выводе всё видно.
  • Самое краткое введение в Reactive Programming
    0

    Набросал:


    <script>
    
    function LimitQueue(limit, timeout) {
        this.limit = limit;
        this.timeout = timeout;
    
        this.jobs = [];
        this.pending = 0;
    
        this.results = [];
    
        this._run = this._run.bind(this);
    }
    
    LimitQueue.prototype.push = function(jobs) {
        Array.prototype.push.apply(this.jobs, jobs);
    };
    
    LimitQueue.prototype._run = function(results) {
        if (results) {
            this.pending = 0;
            Array.prototype.push.apply(this.results, results);
    
            setTimeout(this._run, this.timeout);
    
            if (!this.jobs.length) {
                this.callback(this.results);
            }
    
            return;
        }
    
        let promises = [];
    
        for (;;) {
            if (this.pending == this.limit || !this.jobs.length) {
                Promise.all(promises).then(this._run);
                break;
            }
    
            promises.push(this.jobs.shift()());
            this.pending++;
        }
    };
    
    LimitQueue.prototype.onDone = function(cb) {
        this.callback = cb;
        this._run();
    };
    
    // ========
    
    let q = new LimitQueue(3, 1000);
    
    q.push(
        [{ name: 'Max1' }, { name: 'Max2' }, { name: 'Max3' }, { name: 'Max4' }, { name: 'Max5' }].map(
            data => () => {
                console.log(1, data.name);
    
                return new Promise((resolve, reject) => {
                    console.log(2, data.name);
    
                    setTimeout(() => {
                        console.log(3, data.name);
                        resolve(data.name);
                    }, Math.ceil(Math.random() * 3000));
                });
            }
        )
    );
    
    q.onDone(results => {
        console.log(4, results);
    });
    
    </script>

    В консоли следующее:


    1 "Max1"
    2 "Max1"
    1 "Max2"
    2 "Max2"
    1 "Max3"
    2 "Max3"
    [задержка]
    3 "Max3"
    [задержка]
    3 "Max1"
    [задержка]
    3 "Max2"
    [задержка 1000ms]
    1 "Max4"
    2 "Max4"
    1 "Max5"
    2 "Max5"
    [задержка]
    3 "Max5"
    [задержка]
    3 "Max4"
    4 (5) ["Max1", "Max2", "Max3", "Max4", "Max5"]

    Завернуть всё это в красивый интерфейс уже не проблема и как видите нет никаких потоков.


    UPD: накосячил конечно немного, но суть я думаю понятна.

  • Самое краткое введение в Reactive Programming
    +2
    Реактивное программирование — парадигма программирования, ориентированная на потоки данных и распространение изменений.

    где здесь потоки данных и распространение изменений?
    Статья демонстрирует возможности метода ratelimit, такой метод можно и в какой-нибудь lodash запихать, работать будет ничуть не хуже.

  • Каррирование функций в JavaScript
    +1
    Всё понятно)).
  • Каррирование функций в JavaScript
    0
    Логика в том, что на тех задачах, которые умеют обе функции, приведенная тут функция partial таки быстрее.

    так вы согласны, что функции можно сравнивать?


    light-curry использует arguments вместо spread operator, а это известный убийца производительности.

    вы думаете если переписать без arguments это что-то сильно поменяет? Хорошо, попробуйте! Предлагайте ваш вариант, который создаёт более быстрые каррированные функции. Будет интересно посмотреть.