All streams
Search
Write a publication
Pull to refresh
11
0
Send message
Да, недостатки те же, что и у async/await:
1. Если какая-то функция внизу стека стала async-await (или yield), то все вызывающие функции, и весь граф вызовов, надо также менять на async-await. Я считаю это неправильно, когда программист должен отвлекаться на такие вещи.
2. Несовместимо с некоторыми браузерами (только через babel)
это должно решаться автоматически, т.е. компилятор видит, что функция асинхронна и всегда «подставляет» awai

Согласен, именно так и должно быть. Вместо этого разработчики языка всем парят, что генераторы/промисы/async/await это круто и теперь надо всем учится программировать по-новому: массивы перебирать рекурсией, желательно хвостовой, и вообще переходить на ФП. Приходится за них это делать то, что должно было быть сделано много лет назад.
Промисы не сильно помогают если их нужно связать логикой, и выбор последующего шага зависит от данных с предыдущего.
А async/await все еще не доступен на многих браузерах, особенно в крупных компаниях. Ну не отказывать же им, если они требуют совместимости с IE…
Хайп насчет const сильно преувеличен, так как он не запрещает изменять внутренности объекта. Т.е. не совсем получается и const.

filter и map хороши на циклах с совсем уж простенькой логикой. Если нужно что-то сложное и/или быстрое, то for может быть более к месту.
Эх, спасибо за путешествие в прошлое. С этого компа у меня начался путь веб-программирование: был такой Zeus Assembler, которому как-то сделал систему хелпа: через комбинацию горячих клавиш показывалось попап-окно, в котором можно было курсором выбирать гиперлинки и переходить в другие топики. При этом был реализован шрифт с буквами переменной ширины с собственной кодировкой, так как об ASCII и KOI8R я тогда не знал. Для редактирования шрифта и топиков пришлось запилть проги на встроенном бейсике. В общем этакий прообраз HTML.
Еще, помню, в рамках курсовой, написал на бейсике отображение трехмерных сцен с удалением невидимых линий. Производительность на 20 треугольниках была примерно 5FPH (frames per hour).
Эх, были времена…
У меня один знакомый заставляет своих дочек 10 и 13 лет изучать Java, RUP, UML и прочий ентерпрайз. Требует от них понимания наследования, инкапсуляции и полиморфизма. Пока не ясно, какой будет результат. Но видимо могут быть разные пути как стать спецом в ИТ.
Мне тоже приходили в голову мысли о том, что многое, что приходится кодить можно на самом деле генерировать. В итоге написал скрипт, который по структуре БД генерирет вспомогательный код на разных языках, чтобы потом было комфортно писать бизнес-логику в разных IDE. В моем случае это:
— классы на PHP и JavaScript с описанием структуры, аннотациями, сеттерами, геттерами и другими операциями, чтобы в PHPStorm заработали автоподсказки и автодополнения,
— фрагменты на HTML и JavaScript в соответствии с типом полей
— серилиализаторы
— SQL-функции, процедуры и макросы для различных манипуляций с записями, с тем чтобы избегать перечислений полей.
Свой язык придумывать не стал (за исключением макро расширения для MySQL), так как 1) их уже и так полно 2) хотелось бы писать в IDE, c автоподсказками и нормальным дебагом.
Вообще интересно, кто и что использует для такой вот автоматизации.
Такие системы используют на хайвеях чтобы засечь время, за которое машины его проезжают, и отобразить его на инфощитах Traffic Conditions. Так что это необязательно шпионская слежка.
В свое время пришлось поработать на коболе несколько лет. Имхо: отличный язык для описания бизнес логики в финансовой или учетной сфере. Кобол кстати, сам по себе, достаточно легкий для изучения, в нем можно разобраться за несколько дней. Проблема в том, что системы, которые на нем написаны и еще используются, как правило ну очень большие, и вот с ними разбираться намного труднее. Так что дяде платят не за язык, а за его опыт в финсистемах, и умение с ними разобраться за конечное время.
MongoDB популярнее Oracle? Хм… Ну если только в стартаперско-фрилансерской среде…
Викинги ушли, но пришли другие, и до сих пор прибывают. Об этом я и написал.
Для большинства читателей вопрос «были-небыли» — это вопрос веры, а не знания. Нужно быть ракетным инженером чтобы иметь свое на чем то основанное мнение. Обычные люди вынуждены читать статьи типа этой, робеть от потока формул и выглядящих логичными умозаключений, и выбирать какой теории поверить.

Лично я не могу ни подтвердить, ни опровергнуть практически ничего, что изложено в статье, так как не обладаю достаточными знаниями. Но чисто из здравого смысла мне кажется странным, что побывав однажды где-то, человек там перестал появлятся. Жизнь учит наоборот, что человек, прибыв, уже не уходит (Америка, Арктика, подводный мир, космос, т.п).
У меня как-то еще в студеньчества была следующая задача: необходимо было сделать анимацию, показывающую картинку попиксельно, причем пиксели должны были зажигаться в случайном порядке, и зажечься все за конечное время. Решено было следующим образом:
— в цикле все пиксели перебирались последовательно
— порядковый номер пикселя прогонялся через самодельную функцию шифрования, о которой ниже
— функция шифрования выдавала номер пикселя, который нужно зажечь.
Функция шифрования принимала параметром число в некоем диапазоне, а результатом выдавала другое число в том же самом диапазоне. Главное требование к функции: одному входному значению соответсвует одно выходное, и соответственно, наоборот. Примеры таких функций:
— операции сложения, вычитания, XOR с фиксированным параметром
— циклические сдвиги
— перестановки битов
— функция маппинга 1->1 по заранее рассчитанной случайной таблице
— любые другие подобные обратимые операции, которые не теряют биты
— их комбинации
В моем случае функция состояла из нескольких таких шагов, чтобы визуально анимация воспринималась без повторений, все работало быстро, естественно, без использования SQL, NoSQL и прочих излишних вещей.
Ваша задача могла бы быть решена подобным образом.
Может стоило объяснить заказчику, что хранить 700 млн записей, которые и данных то не содержат, это как бы моветон? Тут и требования, и компетенция того, кто их составлял, вызывают вопросы…
айтишники растут в маленьких региональных компаниях, а закостеневают в больших… В большой компании за яркими офисами нередко скрывается болотце

В больших компаниях обычно и системы большие и сложные настолько, что один отдел (тем более, один человек) уже их целиком знать не может.
В таких условиях на первый план выходит эффективное взаимодействие между командами, а это управление и бюрократия. Это не плохо и не хорошо, просто другие условия и приоритеты.
Нет смысла проверять стратегию через счет брокера, так как очень долго нужно ждать данных для статистически надежного подтверждения или опровержения. Гораздо проще и быстрее будет прогнать ее на тех же исторических данных, но за более поздний (по сравнению с обучением) период. Счет у брокера вообще на этом этапе не нужен.
К сожалению, у меня нет опыта работы с микросервисами
Опыт бы не помешал, особенно суппорта, статья получилась бы несколько другой.
Обычно администраторы не пишут код, и часто ограничены в выборе решений. Например, какое-то покупное приложение может требовать работы под апачем или IIS, а под nginx разработчик не тестировал, и гарантий не дает. В этой ситуации админ скорее должен знать из каких кубиков-компонентов и как собрать инфраструктуру, чтоб «все работало» и без явных узких мест: может nginx стоит поставить перед апачем в качестве reverse proxy, или как сконфигурировать high-availability, или какие бэкап-решения подходят под требования, и т.п.
В тесте adding to hash если заменить
array['s'+i] = 's';

на
array[''+i] = 's';

то результат улучшается с 877.773ms до 203.794ms, а если на
array[i] = 's';

то до 34.362ms
Интересно почему…
У меня из командной строки получился обратный результат:

>c:\php\php test.php
PHP v7.0.4: concatenation 1000000 times: 132.97ms
PHP v7.0.4: addition 1000000 times: 174.055ms
PHP v7.0.4: adding to array 1000000 times: 154.771ms
PHP v7.0.4: adding to hash 1000000 times: 249.67ms

>node test.js
Node.js v6.9.4: concatenation 1000000 times: 50.109ms
Node.js v6.9.4: addition 1000000 times: 2.692ms
Node.js v6.9.4: adding to array 1000000 times: 22.845ms
Node.js v6.9.4: adding to array hash 1000000 times: 877.773ms


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

Information

Rating
Does not participate
Registered
Activity