Comments | livelight: Что-то вроде итогов года (рабочего)

livelight

Что-то вроде итогов года (рабочего)

Dec 28, 2020 23:17

При всех недостатках этого года, в него я окончательно перестал ездить в офис. Команда была и так вся удалённая, так что разницы вообще никто не заметил.
Под конец года дауншифтнулся по работе (с сохранением зарплаты) из тимлида обратно в пещерные гении разработки. Дрючат теперь других, от меня опять никому ничего особо не надо, или надо, но не ( Read more... )

дыбр, рабочее, физматпрог

Comments 10

raoul_duke23 December 29 2020, 06:54:06 UTC

>>дауншифтнулся по работе (с сохранением зарплаты) из тимлида обратно в пещерные гении

Давно уже поступил точно также, о чем ни разу не пожалел

livelight December 29 2020, 08:22:26 UTC

А ещё лучше -- быть архитектурным космонавтом (по Джоэлу Спольски) :)

raoul_duke23 December 29 2020, 12:19:07 UTC

Не вспомнил, кто такие, погуглил. Получается, что не очень хорошо быть таким )

livelight December 29 2020, 13:14:53 UTC

Смотря для кого :)
Себе-то прикольно: сидишь такой в башне из слоновой кости и проектируешь сферических слонов в стратосфере :)

Thread 5

beldmit December 29 2020, 12:13:23 UTC

Формулировка про палки - огонь!

livelight December 29 2020, 13:16:02 UTC

Да уж, жизнь такая :)

justy_tylor December 29 2020, 13:05:01 UTC

Функциональщина хороша появлением замыканий в мейнстримных языках. Однако, когда в материалах технологий/фреймворков обсуждают прелести functional programming, то упирают не на эту и прочие фичи "оттуда", а на ситуативный marketing bullshit.

Реактивщина - зло практически всегда. Это работающий инструмент с крайне малой сферой применения. И если недоумки пихают его туда, где нужны транзакции (например, UI), то неминуема ситуация "палки положить забыли, говно разваливается".

А решение "обратно в джедаи" выглядит правильно. Тимлидство без архитексторства - слишком значительное расхождение ответственности и возможностей, осмысленно только на "потренироваться".

livelight December 29 2020, 13:31:28 UTC

Замыкания - палка (это если палки положить не забыли) о двух концах. В случае чисто функционального языка с чистыми значениями всем пофиг на всё (включая производительность), но когда мы работаем в императивном языке с модифицируемыми объектами, то всегда надо чётко понимать, какое выражение в какой момент и при каком состоянии объектов замкнётся и вычислится. А судя по тому, что я в коде увидел, это понимают не все и не всегда.

Пихали реактивщину, я так понимаю, в надежде сэкономить на тредах там, где их всё ещё не научились готовить. Не, я понимаю, сам видел случай, когда в ОС закончились треды после разведения огромных тред-пулов на входящие запросы, но после того, как я неделю разворачивал выражения вида
реактивно дождаться ответа then императивное выражение then императивное выражение then императивное выражение then return something
в обычный честный императивный код -- нафиг-нафиг вот это всё, лучше оптимизировать где-то в другом месте.

justy_tylor December 29 2020, 14:27:08 UTC

Тут несколько проблем:

1. Культура. Если человек познакомился с замыканиями на том же уровне восприятия, что с функциями и классами, то далее он свободно их читает. Если же он познакомился с действием "вставь then между здесь и здесь, потому что асинхронная магия", то в какой-то момент магия призовёт зверя Пицзеци.

2. Языки. Когда оформление кода в асинхронную таску используется только чтобы не тратить ресурсы на тред, то преобразовать синхронный код в асинхронный может сам компилятор. К сожалению, в существующих мейнстримных языках используются костыли async/await и прочее непотребство.

3. Средства отладки. Просто недоразвитые.