Вообще мне после России довольно странно наблюдать местное возмущение полицией, когда к тебе даже за нарушения часто говорят "больше так не делай" и уходят вместо выписывания штрафа.
Актуальные модели ноутбуков и смартфонов на витрине предназначены, чтобы изнашиваться. Если их потом кому и продают, то с большущей скидкой за износ. И износ одной модели отлично окупается покупкой тысяч других, которые купили пощупавшие их люди. Если бы не окупались, их бы не было.
Будет ли разработчик из дешёвого места таким же качественным? Вспомним, что в среднем хорошие разработчики чаще переезжают из дешёвых мест в дорогие, чем наоборот. Подумаем о том, что в большинстве хорошие разработчики, переехавшие в более дешёвое место, не будут соглашаться на более дешёвую зарплату.
Даже если такого возможно найти, всё равно риски гораздо выше + разработчику нужно время вникнуть в проект и начать работать (сравниваем с существующим разработчиком, который уже работает, работает хорошо, а раз работает — не трогай). А ведь риски это не просто "один день поработал и уволился", это всё потраченное время и силы на онбоардинг, через которое вы узнаете, что вот этот разработчик из глубинки вам не подходит.
В TypeScript у людей всегда соблазн писать максимально строгие типы.
"А вот это поле бывает [number, number] если в соседнем поле лежит string, а бывает [string, number, string], если в другом соседнем поле лежит boolean, а оба соседних поле зависят от чего-то ещё, давайте все это типизируем чтобы оно соответствовало, сделаем цепочку из 20 наследований, где у каждого типа в цепочке ещё и по 20 дженериков".
В итоге у тебя сверхзапутанная система типов, которые не помогают примерно никогда, с трудом читаются и требуют неделю вносить в них изменения при 5-минутных правках кода. Я не шучу, столько раз об это спотыкался.
Из живых примеров — недавно редактировал код, где у компонента Table в Props захотели сделать, чтобы Cols.length == Rows[any index].length. Как-то сделали. Я часа два над этими типами медитировал, так до конца и не понял, как это должно работать.
А в итоге по всему коду проекта раскидано as Rows<rowLength>, потому что у явно заданного массива ts почему-то длину не распознаёт, а у динамически полученного в рантайме понятно почему не распознаёт. При этом, очевидно, не проверяет такая проверка абсолютно ничего – во всех живых кейсах данные для таблицы получаются в рантайме.
Проблема абсолютно такая же, как с динамической типизацией. Есть динамическая типизация — люди ей злоупотребляют и стреляют себе в ногу. Есть статическая — аналогично. Только злоупотреблять ей можно иначе.
Околоэмфатически или с желанием как-то что-то стилизовать, мы до сих пор можем сказать "они суть n", "я есть робот" или что-нибудь такое. При этом даже не особо осознавая, что "суть" это исторически глагол.
Из первого извлекаем вывод, что по-видимому, бывает процесс в языках, когда слово начинает только подразумеваться в самом используемом кейсе (в копилку примеров I got вместо I've got и ещё миллион других).
Подозрительно смотрим на второе и обращаем внимание, что оно очень-очень похоже. Если у нас нет никаких исторических источников, которые бы объяснили, что это не так, то очень легко предположить, что для "I speak English" полная форма это "I do speak English". Если у смотрящего ещё и естественно-научное образование и стремление к поиску общих случаев, то путём этого мы можем заявить, что вспомогательный глагол в английском есть вообще всегда, просто в конкретном случае (двух) он элиминировался, чтобы удобнее говорить, и остался как эмфатическая форма. Тогда и грамматика становится более стройной и красивой.
Ну и третье тоже аналогия конечно, да.
Это я пересказываю процесс мысли себя несколько лет назад, когда я про историю английского не знал примерно ничего.
3 времени, 4 аспекта и разные согласования. Это совсем не сложно: 3 времени мы и так понимаем, 4 аспекта и согласования нужно понять.
А 36 это всего лишь разные возможные их комбинации. А так говорить, что в английском 36 времён это всё равно что насчитать 108 форм глагола "идти" в русском во всех временах, аспектах, родах, числах, лицах и способах склонения и заявить, что в русском 108 времён.
Тут кстати интересно, если не знать историю, можно посмотреть на emphatic do и решить, что именно это первичная форма, из которой do ушёл в настоящем (подобно нашему быть), но остался в других случаях (подобно нашему быть) и в качестве emphatic (и опять подобно нашему быть).
У вас был <div class="menu open" /> и он менялся на <div class="menu close" />.
А должно стать <menu class="open" />, меняющийся на <menu class="close" />.
Если же вы хотите превращать <menu-open /> в <menu-close /> или <open class="menu" /> в <close class="menu" />, то это по меньшей мере странно.
Всегда воспринимал такие вещи как бессмысленное сопоставление литературного перевода с оригиналом. Правда, тогда придётся сказать, что у слова smiled есть значение «превозмогая смерть, улыбнулся».
Или же давайте всё-таки примем идею, что у другого языка другие коллокации и другие устойчивые сочетания, и нам не придётся изобретать 150 дополнительных смыслов, чтобы точно всему соответствовать. Тогда мы поймём, что слух может уходить (his hearing is going), съесть всё можно за один поход (to eat the whole thing in one go), двигатели в английском бегают, а не работают (engine running), места берут, а не занимают (take seats), дату свадьбы можно установить, а не запланировать (set a date), декорация это то же самое, что и набор (film set), новости можно получать, а не узнавать (get news), молок получать, а не покупать (get milk), кофе может становиться холодным, а не остывать (get cold), а take up в take up all issues at once и вовсе фразовый глагол.
И тогда нам не придётся придумывать, что go может значить ухудшаться, а get — остывать.
Помимо вышеупомянутого, создать мануал по языку можно и при наличии достаточного количества текстов на нем с переводами. Лингвисты это скорее всего прямо в первый год обучения учатся делать на какой-нибудь общей лингвистике.
Когда-то объяснял эксперимента ради линейные уравнения 4-летней сестре. Вполне успешно: когда ты умеешь складывать и вычитать на пальцах, понять концепцию «что за число прячется за облачком? давай вычтем с обоих сторон и поймём» оказывается по силам.
Так это про антиковидные меры.
Вообще мне после России довольно странно наблюдать местное возмущение полицией, когда к тебе даже за нарушения часто говорят "больше так не делай" и уходят вместо выписывания штрафа.
Нет, положение женщины, сидящей с ребёнком дома – это ожидаемое изменение. Более того, желаемое изменение.
Разница в этом.
Актуальные модели ноутбуков и смартфонов на витрине предназначены, чтобы изнашиваться. Если их потом кому и продают, то с большущей скидкой за износ. И износ одной модели отлично окупается покупкой тысяч других, которые купили пощупавшие их люди. Если бы не окупались, их бы не было.
Если не изменяет память, в Яндексе налог на еду тоже вычитался.
Будет ли разработчик из дешёвого места таким же качественным? Вспомним, что в среднем хорошие разработчики чаще переезжают из дешёвых мест в дорогие, чем наоборот. Подумаем о том, что в большинстве хорошие разработчики, переехавшие в более дешёвое место, не будут соглашаться на более дешёвую зарплату.
Даже если такого возможно найти, всё равно риски гораздо выше + разработчику нужно время вникнуть в проект и начать работать (сравниваем с существующим разработчиком, который уже работает, работает хорошо, а раз работает — не трогай). А ведь риски это не просто "один день поработал и уволился", это всё потраченное время и силы на онбоардинг, через которое вы узнаете, что вот этот разработчик из глубинки вам не подходит.
В TypeScript у людей всегда соблазн писать максимально строгие типы.
"А вот это поле бывает [number, number] если в соседнем поле лежит string, а бывает [string, number, string], если в другом соседнем поле лежит boolean, а оба соседних поле зависят от чего-то ещё, давайте все это типизируем чтобы оно соответствовало, сделаем цепочку из 20 наследований, где у каждого типа в цепочке ещё и по 20 дженериков".
В итоге у тебя сверхзапутанная система типов, которые не помогают примерно никогда, с трудом читаются и требуют неделю вносить в них изменения при 5-минутных правках кода. Я не шучу, столько раз об это спотыкался.
Из живых примеров — недавно редактировал код, где у компонента Table в Props захотели сделать, чтобы Cols.length == Rows[any index].length. Как-то сделали. Я часа два над этими типами медитировал, так до конца и не понял, как это должно работать.
А в итоге по всему коду проекта раскидано
as Rows<rowLength>, потому что у явно заданного массива ts почему-то длину не распознаёт, а у динамически полученного в рантайме понятно почему не распознаёт. При этом, очевидно, не проверяет такая проверка абсолютно ничего – во всех живых кейсах данные для таблицы получаются в рантайме.Проблема абсолютно такая же, как с динамической типизацией. Есть динамическая типизация — люди ей злоупотребляют и стреляют себе в ногу. Есть статическая — аналогично. Только злоупотреблять ей можно иначе.
А в WebGL у вас и так параллельный рендеринг. Шейдеры на видеокарте запускаются.
Спасибо! Пост интересный, и да, был рад, когда увидел пост от вас на главной :)
В русском:
В английском:
Околоэмфатически или с желанием как-то что-то стилизовать, мы до сих пор можем сказать "они суть n", "я есть робот" или что-нибудь такое. При этом даже не особо осознавая, что "суть" это исторически глагол.
Из первого извлекаем вывод, что по-видимому, бывает процесс в языках, когда слово начинает только подразумеваться в самом используемом кейсе (в копилку примеров I got вместо I've got и ещё миллион других).
Подозрительно смотрим на второе и обращаем внимание, что оно очень-очень похоже. Если у нас нет никаких исторических источников, которые бы объяснили, что это не так, то очень легко предположить, что для "I speak English" полная форма это "I do speak English". Если у смотрящего ещё и естественно-научное образование и стремление к поиску общих случаев, то путём этого мы можем заявить, что вспомогательный глагол в английском есть вообще всегда, просто в конкретном случае (двух) он элиминировался, чтобы удобнее говорить, и остался как эмфатическая форма. Тогда и грамматика становится более стройной и красивой.
Ну и третье тоже аналогия конечно, да.
Это я пересказываю процесс мысли себя несколько лет назад, когда я про историю английского не знал примерно ничего.
3 времени, 4 аспекта и разные согласования. Это совсем не сложно: 3 времени мы и так понимаем, 4 аспекта и согласования нужно понять.
А 36 это всего лишь разные возможные их комбинации. А так говорить, что в английском 36 времён это всё равно что насчитать 108 форм глагола "идти" в русском во всех временах, аспектах, родах, числах, лицах и способах склонения и заявить, что в русском 108 времён.
У вас был
<div class="menu open" />и он менялся на<div class="menu close" />.А должно стать
<menu class="open" />, меняющийся на<menu class="close" />.Если же вы хотите превращать
<menu-open />в<menu-close />или<open class="menu" />в<close class="menu" />, то это по меньшей мере странно.Или же давайте всё-таки примем идею, что у другого языка другие коллокации и другие устойчивые сочетания, и нам не придётся изобретать 150 дополнительных смыслов, чтобы точно всему соответствовать. Тогда мы поймём, что слух может уходить (his hearing is going), съесть всё можно за один поход (to eat the whole thing in one go), двигатели в английском бегают, а не работают (engine running), места берут, а не занимают (take seats), дату свадьбы можно установить, а не запланировать (set a date), декорация это то же самое, что и набор (film set), новости можно получать, а не узнавать (get news), молок получать, а не покупать (get milk), кофе может становиться холодным, а не остывать (get cold), а take up в take up all issues at once и вовсе фразовый глагол.
И тогда нам не придётся придумывать, что go может значить ухудшаться, а get — остывать.
Помимо вышеупомянутого, создать мануал по языку можно и при наличии достаточного количества текстов на нем с переводами. Лингвисты это скорее всего прямо в первый год обучения учатся делать на какой-нибудь общей лингвистике.