Я прекрасно понимаю алгоритмичесую сложность, но мутировать в что-то лишний раз, тем более в reduce, не буду:
Это плохой пример другим. Товарищи решат, что так можно везде, и начнут, например, удалять элементы из массива по которому проходят. А потом товарищи перейдут на бакенд, который многопоточный. И про "memory model" не прочитают. Оптимизировать безопасный код проще, чем вылавливать плохо повтояемые баги.
Итак, у меня 1000 элементов, для которых описанная оптимизация имеет значение. А они точно нужны на клиенте? Может, в качестве первой оптимизации, их не присылать, а взять только те 20, которые пользователь видит.
Ну хорошо, в этот раз у меня канвас на UHD и элементов правда нужно много. А использовать библиотеку с дополнительными структурами данных не разрешили. Я ведь могу написать свой минимальный "util.js", в котором внутри всё будет в стиле "for(;;)" и "let", а снаружи чисто.
Есть линтеры, которые заставляют помечать небозопасные конструкции. Возможно есть/будет и для js такой инструмент. И я стараюсь писать код так, чтобы легко интегрировать его в будущем.
История #1: ":empty", это не "основы", а одна из 100500 фичей CSS. Просто есть два человека, первый придумал ":empty", и был ближе к комитету по стандартам, поэтому фичу затащили в браузер, а другой придумал хуки, или еще что-то, но был в другой тусовке. Основы -- программирование (функции в реактивность в данном случае). И поведение разработчиков смотрится вполне нормально. А то, что мимо шел человек-энциклопедия по CSS -- приятный бонус.
История #2: Ввести правила: Пихать "script" в конец, а не куда попало. Запускать действия по событиям (не запускать вне функций). Низкоуровневые подробности гуглить, если припрет.
А так получим людей, которые "тупо" используют массивы, а паяльника с транзистором в руках не держали. Тут вопрос, кого мы хотим получить в итоге. В идеале выходит супергерой, который сможет разрабатывать свой СУБД. Но, боюсь, получится наоборот: Страница циклов с квадратичной сложностью, зарытой ошибкой "+1" и Го-шными "if err!=nil", вместо пары строк с готовым словарем и groupBy.
С точки зрения карьеры на западе — вроде разумный шаг.
Далее идут мои выдумки:
Технически ИТМО, вероятно, круче.
Вот, предположим, есть универ в провинции.
Большинство студентов — никакие.
Но выгнать их нельзя, т. к. других нет, и ради оставшихся факультет содержать не будут.
Преподов тогда разгонят.
А если препод тоже никакой, то и с практической работой у него будет не особо.
Вот так все и живут.
А в центральный престижный универ студенты будут съезжаться, создавать давление.
И отсев будет, и нагрузка, и результат.
Активный студент выбирает, куда ему ехать.
На это влияют языковой и финансовый барьеры.
Москва/Питер образуют крупный центр в рамках языкового барьера.
Таллинн/Тарту тоже образуют центр в рамках языкового барьера,
но критическая масса не набирается.
Поэтому единственный вариант создать какое-то давление — сделать на английском и бесплатно.
Если бы в английских центрах было бесплатно — шанса бы не было.
Студенту-инженеру может быть вполне интересно.
Вот сидит он такой тихо под Псковом, чувствует, что уродился не там.
Но мечты его туманны.
А тут ему раз, и показали, как всё развернуть можно.
Это не просто девушка, это девушка из ИТМО.
ИТМО — топовый российский ВУЗ для девелоперов.
По личному опыту:
Соискателю из ИТМО можно поручить с разбега что угодно сделать, хоть СУБД кастомную.
А студенты ТалТеха (я сам его заканчивал) заваливаются часто на задачке на 10 строк с парой циклов.
PHP всегда был практичным инструментом.
В каком еще языке программа, выводящая "Hello", пишется как Hello.
Это ж гениально.
Но вот согласованным он не был никогда, и даже не пытался.
Жители разных планет, не имея общего языка, закомитили переменные и константы так, что имена одних регистрозависимые, а других — нет.
Есть переменные, константы и final, но указать, что присвоение можно производить только один раз — никак. В PHP8 будут аннотации и подобные проверки удобно будет поручить линтеру.
У меня в js-коде 98% const и 2% let.
Есть подозрение, что «герметичный» контекст у функций потому, что удобный было делать лень, а потом уже совместимость и никак. Но вот, наконец, это решились починить стрелочными функциями.
Новшество с аргументами конструктора — вообще праздник.
Я понимаю, что в джаве, чтоб сделать поле foo полагалось для солидности написать 'foo' минимум 4 раза — поле, аргумент конструктора, и присвоение, а еще геттеры, сеттеры и т. п.
Там всё так, но зачем в другие языки было это копировать?
При том, что в 90% случаев аргумент конструктора попадает в поле без изменений, a в остальных случаях можно сделать фабрику.
В котлине:
class Person(firstName: String)
val customer = Person("Joe Smith")
иммутабилен — это плюс, когда бэкенд весь иммутабилен,
и не надо туда-сюда голову перекючать ради 5% кода на js;
чем более примитивен инструмент, тем проще понять, как он внутри работает;
mobx работает как-бы _интуитивно_, но понять, как он _точно_ работает скорее всего будет сложней;
не все модные возможности JS хочется раскрывать, начиная от слетающего «this», и заканчивая прокси, когда написано одно короткое выражение, а отрабатывает хитрая магия.
Ну, если писать на mobx ежедневно, то возможно есть смысл со всем этим хорошенько разобраться и печатать на 25% символов меньше.
Или тут какие-то принципиальные бонусы?
Если что, я сам пока ни того, ни другого не выбрал.
Я прекрасно понимаю алгоритмичесую сложность, но мутировать в что-то лишний раз, тем более в reduce, не буду:
Это плохой пример другим. Товарищи решат, что так можно везде, и начнут, например, удалять элементы из массива по которому проходят. А потом товарищи перейдут на бакенд, который многопоточный. И про "memory model" не прочитают. Оптимизировать безопасный код проще, чем вылавливать плохо повтояемые баги.
Итак, у меня 1000 элементов, для которых описанная оптимизация имеет значение. А они точно нужны на клиенте? Может, в качестве первой оптимизации, их не присылать, а взять только те 20, которые пользователь видит.
Ну хорошо, в этот раз у меня канвас на UHD и элементов правда нужно много. А использовать библиотеку с дополнительными структурами данных не разрешили. Я ведь могу написать свой минимальный "util.js", в котором внутри всё будет в стиле "for(;;)" и "let", а снаружи чисто.
Есть линтеры, которые заставляют помечать небозопасные конструкции. Возможно есть/будет и для js такой инструмент. И я стараюсь писать код так, чтобы легко интегрировать его в будущем.
История #1: ":empty", это не "основы", а одна из 100500 фичей CSS. Просто есть два человека, первый придумал ":empty", и был ближе к комитету по стандартам, поэтому фичу затащили в браузер, а другой придумал хуки, или еще что-то, но был в другой тусовке. Основы -- программирование (функции в реактивность в данном случае). И поведение разработчиков смотрится вполне нормально. А то, что мимо шел человек-энциклопедия по CSS -- приятный бонус.
История #2: Ввести правила: Пихать "script" в конец, а не куда попало. Запускать действия по событиям (не запускать вне функций). Низкоуровневые подробности гуглить, если припрет.
А так получим людей, которые "тупо" используют массивы, а паяльника с транзистором в руках не держали. Тут вопрос, кого мы хотим получить в итоге. В идеале выходит супергерой, который сможет разрабатывать свой СУБД. Но, боюсь, получится наоборот: Страница циклов с квадратичной сложностью, зарытой ошибкой "+1" и Го-шными "if err!=nil", вместо пары строк с готовым словарем и groupBy.
С точки зрения карьеры на западе — вроде разумный шаг.
Далее идут мои выдумки:
Технически ИТМО, вероятно, круче.
Вот, предположим, есть универ в провинции.
Большинство студентов — никакие.
Но выгнать их нельзя, т. к. других нет, и ради оставшихся факультет содержать не будут.
Преподов тогда разгонят.
А если препод тоже никакой, то и с практической работой у него будет не особо.
Вот так все и живут.
А в центральный престижный универ студенты будут съезжаться, создавать давление.
И отсев будет, и нагрузка, и результат.
Активный студент выбирает, куда ему ехать.
На это влияют языковой и финансовый барьеры.
Москва/Питер образуют крупный центр в рамках языкового барьера.
Таллинн/Тарту тоже образуют центр в рамках языкового барьера,
но критическая масса не набирается.
Поэтому единственный вариант создать какое-то давление — сделать на английском и бесплатно.
Если бы в английских центрах было бесплатно — шанса бы не было.
Студенту-инженеру может быть вполне интересно.
Вот сидит он такой тихо под Псковом, чувствует, что уродился не там.
Но мечты его туманны.
А тут ему раз, и показали, как всё развернуть можно.
Это не просто девушка, это девушка из ИТМО.
ИТМО — топовый российский ВУЗ для девелоперов.
По личному опыту:
Соискателю из ИТМО можно поручить с разбега что угодно сделать, хоть СУБД кастомную.
А студенты ТалТеха (я сам его заканчивал) заваливаются часто на задачке на 10 строк с парой циклов.
По Тарту не скажу, статистики нет.
PHP всегда был практичным инструментом.
В каком еще языке программа, выводящая "Hello", пишется как
Hello.Это ж гениально.
Но вот согласованным он не был никогда, и даже не пытался.
Жители разных планет, не имея общего языка, закомитили переменные и константы так, что имена одних регистрозависимые, а других — нет.
Есть переменные, константы и
final, но указать, что присвоение можно производить только один раз — никак. В PHP8 будут аннотации и подобные проверки удобно будет поручить линтеру.У меня в js-коде 98%
constи 2%let.Есть подозрение, что «герметичный» контекст у функций потому, что удобный было делать лень, а потом уже совместимость и никак. Но вот, наконец, это решились починить стрелочными функциями.
Новшество с аргументами конструктора — вообще праздник.
Я понимаю, что в джаве, чтоб сделать поле
fooполагалось для солидности написать 'foo' минимум 4 раза — поле, аргумент конструктора, и присвоение, а еще геттеры, сеттеры и т. п.Там всё так, но зачем в другие языки было это копировать?
При том, что в 90% случаев аргумент конструктора попадает в поле без изменений, a в остальных случаях можно сделать фабрику.
В котлине:
иммутабилен — это плюс, когда бэкенд весь иммутабилен,
и не надо туда-сюда голову перекючать ради 5% кода на js;
чем более примитивен инструмент, тем проще понять, как он внутри работает;
mobx работает как-бы _интуитивно_, но понять, как он _точно_ работает скорее всего будет сложней;
не все модные возможности JS хочется раскрывать, начиная от слетающего «this», и заканчивая прокси, когда написано одно короткое выражение, а отрабатывает хитрая магия.
Ну, если писать на mobx ежедневно, то возможно есть смысл со всем этим хорошенько разобраться и печатать на 25% символов меньше.
Или тут какие-то принципиальные бонусы?
Если что, я сам пока ни того, ни другого не выбрал.