Стоило ли делать все это ради неявного async/await с переусложненным интерфейсом? В современном javascript не используются коллбэки, насколько мне известно — их место заняли Promise, которые, в свою очередь, пишутся в псевдосинхронном стиле через await.
А вот перечисленное вами — еще одна из причин, почему "программисты не могут программировать".
Речь не только об отсечении тех, кто никогда строчки кода не набрал, речь еще и о тех, кто в размышлениях на тему "а что если деление на 3 будет в будущем реализовано как длительное обращение к базе данных, надо предусмотреть механизм для этого", "а вдруг у заказчика появится необходимость добавить новые условия, и еще настраивать их через конфиг-файл, давайте сделаем декларативный DSL для определения делителей и требуемого действия", и т.д. заходит в дебри полного паралича, т.к. никогда не получится сделать идеально гибкое решение, которое предусмотрит все возможные будущие юзкейсы, которые, возможно, никогда не наступят.
Отвечу вам контрпримером. Если нужно будет добавить новое условие, по которому в случае деления на 7 без остатка надо выводить "Piss" — сколько изменений потребуется в моем коде и сколько в "менее хрупком"?
Уважаемый, вы не поняли суть. Это не проверка умения быстро составлять "алгоритмы" (алгоритмы у fizzbuzz, серьезно?). Это своеобразный smoke test, чтобы отличить программиста (любого уровня) от человека, который умеет с умным видом говорить баззворды.
И только если кандидат проходит эту элементарную проверку, уже имеет смысл спрашивать о чем-то другом.
Но если у меня правильно работает интерпретатор bash в голове, то это код не будет ждать между выводами значений — вместо этого он подождет 50 мс только при запуске, а потом выплюнет все сразу, т.к. sleep происходит вомножестве подпроцессов одновременно. Нужно, чтобы паузы были между выводами, но при этом чтобы каждый вывод был асинхронным.
Но пока никто не сделал на ассемблере асинхронный пример :) Ждем того самого смельчака, который напишет на асме реализацию кооперативной многозадачности.
Бесплатного ничего не бывает — скорее всего, несколько итераций цикла у движка займет анализ того, что поведение функции не меняется, т.к. не сорвется ни одна проверка на деоптимизацию (я не помню, как называются эти внутренние assert-ы, увы). Если бы fizzbuzz выполнялся на хотя бы тысячах итераций, возможно, это было бы заметно.
Ну дык в AST будет тот же самый конечный автомат?
Не-а, именно в AST будет ровно то же, что видно глазами. Вы имели в виду IR, Intermediate Representation — там, возможно, мог бы быть конечный автомат, но не факт, т.к. async-функции имеют более сложную семантику, чем одна перезапускающаяся функция с параметром, равным состоянию автомата. Но я понимаю, к чему вы — async-функции можно выразить через генераторы, а генераторы в свою очередь можно выразить через конечные автоматы. Результат будет монструозным, и с повсеместным введением поддержки ES5 в нем больше нет необходимости.
Позвольте вас вызвать на поединок — я хочу посмотреть, как вы выполните условие с асинхронностью (каждый print в отдельном потоке), уложившись в 250 знаков без учета whitespace. Только без читерства с созданием одной огромной строки из смеси пробелов и tab-ов, в которой закодирована остальная реализация :)
для того, чтобы за 10 секунд набрать приблизительно 400 знаков, не считая пробелы, вы должны просто необыкновенно быстро печатать. Но несколько минут — да, реалистичная оценка.
ну, на практике т.к. тут нет closure в function sleep, поэтому новый анонимный метод не будет создаваться каждый раз — вместо этого движок один раз скомпилирует шаблон функции и будет использовать его в дальнейшем. Но да, в этом была суть моего комментария чуть ниже вашего.
И в данном случае тут async/await ни во что не превращается, т.к. node 7.9.0 уже умеет async/await из коробки. Ну и в принципе в ES6 окружении это уже скорее были бы генераторы… не знаю даже, что хуже :)
Вы еще x <= 100 в проверки посчитайте, будет шесть. Какой смысл экономить на сравнениях, когда в функции используется передача управления в event loop? Это называется "микрооптимизация", или "экономия на спичках".
Цель проверки — сделать быстро и читабельно. Посильную помощь оптимизатору, явно указав результат сравнений как константы, я оказал. И я могу быть не прав, но на мой взгляд, мой пример кода на порядок читабельнее решений типа этого.
Нет, не смущает, потому что log в данном случае имеет греческое происхождение от λόγος, "говорю". А вот "square" в значении "площадь фигуры" — это банальная безграмотность и надмозг, сродни "I count that you..." = "Я считаю, что ты..."
Казалось бы, именно ради этого и был написан babel...
Стоило ли делать все это ради неявного async/await с переусложненным интерфейсом? В современном javascript не используются коллбэки, насколько мне известно — их место заняли Promise, которые, в свою очередь, пишутся в псевдосинхронном стиле через await.
А вот перечисленное вами — еще одна из причин, почему "программисты не могут программировать".
Речь не только об отсечении тех, кто никогда строчки кода не набрал, речь еще и о тех, кто в размышлениях на тему "а что если деление на 3 будет в будущем реализовано как длительное обращение к базе данных, надо предусмотреть механизм для этого", "а вдруг у заказчика появится необходимость добавить новые условия, и еще настраивать их через конфиг-файл, давайте сделаем декларативный DSL для определения делителей и требуемого действия", и т.д. заходит в дебри полного паралича, т.к. никогда не получится сделать идеально гибкое решение, которое предусмотрит все возможные будущие юзкейсы, которые, возможно, никогда не наступят.
И это уже называется "оверинжиниринг".
Отвечу вам контрпримером. Если нужно будет добавить новое условие, по которому в случае деления на 7 без остатка надо выводить "Piss" — сколько изменений потребуется в моем коде и сколько в "менее хрупком"?
Уважаемый, вы не поняли суть. Это не проверка умения быстро составлять "алгоритмы" (алгоритмы у fizzbuzz, серьезно?). Это своеобразный smoke test, чтобы отличить программиста (любого уровня) от человека, который умеет с умным видом говорить баззворды.
И только если кандидат проходит эту элементарную проверку, уже имеет смысл спрашивать о чем-то другом.
Абсолютно уверен, посмотрите дискуссию в этом посте :) Просто пауза перед выводом любых значений не добавляет в задачу сложности.
Но если у меня правильно работает интерпретатор bash в голове, то это код не будет ждать между выводами значений — вместо этого он подождет 50 мс только при запуске, а потом выплюнет все сразу, т.к. sleep происходит вомножестве подпроцессов одновременно. Нужно, чтобы паузы были между выводами, но при этом чтобы каждый вывод был асинхронным.
Ну так и на JS смысла от задержки нет никакого, как, впрочем, и у самой задачи нет особого смысла. Просто нужно так сделать :)
Но это не C++ :)
Но пока никто не сделал на ассемблере асинхронный пример :) Ждем того самого смельчака, который напишет на асме реализацию кооперативной многозадачности.
И задержки нет :) Правда, я даже не знаю, как сделать задержку в T-SQL, разве что через UDF?
Бесплатного ничего не бывает — скорее всего, несколько итераций цикла у движка займет анализ того, что поведение функции не меняется, т.к. не сорвется ни одна проверка на деоптимизацию (я не помню, как называются эти внутренние assert-ы, увы). Если бы fizzbuzz выполнялся на хотя бы тысячах итераций, возможно, это было бы заметно.
Не-а, именно в AST будет ровно то же, что видно глазами. Вы имели в виду IR, Intermediate Representation — там, возможно, мог бы быть конечный автомат, но не факт, т.к. async-функции имеют более сложную семантику, чем одна перезапускающаяся функция с параметром, равным состоянию автомата. Но я понимаю, к чему вы — async-функции можно выразить через генераторы, а генераторы в свою очередь можно выразить через конечные автоматы. Результат будет монструозным, и с повсеместным введением поддержки ES5 в нем больше нет необходимости.
Позвольте вас вызвать на поединок — я хочу посмотреть, как вы выполните условие с асинхронностью (каждый print в отдельном потоке), уложившись в 250 знаков без учета whitespace. Только без читерства с созданием одной огромной строки из смеси пробелов и tab-ов, в которой закодирована остальная реализация :)
Продумывание да, 10 секунд от силы, согласен.
Многопоточность завезли в виде Worker-ов.
для того, чтобы за 10 секунд набрать приблизительно 400 знаков, не считая пробелы, вы должны просто необыкновенно быстро печатать. Но несколько минут — да, реалистичная оценка.
ну, на практике т.к. тут нет closure в
function sleep, поэтому новый анонимный метод не будет создаваться каждый раз — вместо этого движок один раз скомпилирует шаблон функции и будет использовать его в дальнейшем. Но да, в этом была суть моего комментария чуть ниже вашего.И в данном случае тут async/await ни во что не превращается, т.к. node 7.9.0 уже умеет async/await из коробки. Ну и в принципе в ES6 окружении это уже скорее были бы генераторы… не знаю даже, что хуже :)
Вы еще
x <= 100в проверки посчитайте, будет шесть. Какой смысл экономить на сравнениях, когда в функции используется передача управления в event loop? Это называется "микрооптимизация", или "экономия на спичках".Цель проверки — сделать быстро и читабельно. Посильную помощь оптимизатору, явно указав результат сравнений как константы, я оказал. И я могу быть не прав, но на мой взгляд, мой пример кода на порядок читабельнее решений типа этого.
паузы и асинхронные вызовы забыли. В bash это было бы с
&иwaitpid.Ровно пять минут, и то это долго. В гугл не смотрел, т.к. без необходимости. Запускать в
node --harmony.Нет, не смущает, потому что log в данном случае имеет греческое происхождение от λόγος, "говорю". А вот "square" в значении "площадь фигуры" — это банальная безграмотность и надмозг, сродни "I count that you..." = "Я считаю, что ты..."