представьте, что какой-то разраб через 20 лет будет в нём разбираться, и, пожалуйста, постарайтесь сделать жизнь этого чувака хоть чутоку легче
Мне кажется ваши статьи и через 20 лет будут читаться так же легко. Вы показываете абсолютно обыденные вещи, с которыми разработчики сталкиваются по сто раз на дню, но всегда удивительно красиво и романтично. Как если бы Бианки или Паустовский писали свои записки о природе IT.
Если из него убрать фишки программирования, отставив только функции разметки, достаточные для форматирования текста как в HTML, то думаю получится RTF.
А разработка - это не про языки или фреймворки. Это прежде всего алгоритмы и данные. Парадигмы разработки. Язык выучивается быстро - достаточно на нем сделать пару-тройку задач и начало уже есть, дальше уже только в тонкости вникать.
Разработка это борьба со сложностью. Языки, фреймворки, алгоритмы это по сути взгляд на проблему под разными углами. Какой способ выстрелит зависит от конкретной задачи - здесь нет лучших, есть только подходящие.
Учиться сложно. Причем, чем глубже, тем сложнее. Это чем-то похоже на дженгу, только наборот - каждый новый кирпичек знаний норовит разломать ваши представления о прекрасном ко всем нулям.
Быстрое изучение языков это маркетинг, в стиле курсов изучения английского (и результат на выходе аналогичен). Пару слов связать получится, но только нормально писать - спустя годы.
Редко требуется начинать велосипедить с нуля, потому что даже если в компании сильный NIH синдром (not invented here), на момент прихода соискателя в компанию там уже есть пара-тройка миллионов строк собственного библиотечного кода, покрывающего большинство кейсов
Если в компании NIH синдром, то вы скорее всего будете пилить свое, даже если внутри тех миллионов строк. Бюджет сам себя не обоснует, а пытаться строить из себя нормального в дурдоме это плыть против денег в направлении за ворота, под дружное улюлюкание санитаров руководства.
ML(AI), который генерит код по ТЗ. В его задачу, скорее всего, не будет включено "читаемость человеком".
На практике требуется не только читаемость, но и понятность, иначе такое решение никому не нужно. Может код помимо ТЗ по ночам биткойны майнит или котиков обижает, или нет - чём докажете?
Когда специалист экстра класса понимает конечную задачу своего руководителя, то руководителю приходится с ним либо на полном серьёзе делиться, либо прощаться. 0.01% это видимо те, руководители которых застыли в ожидании чуда (но это быстро проходит).
При использовании стека у вас гарантировано есть вся история вычислений "сверху до низу". В случае PTC это просто хвост - последние N вызовов. А все что раньше - тишина.
Например rxjs, ramda и fp-ts, активно использует код в стиле continuations, которые Safari благополучно лианеризирует. Если между точкой возникновения проблемы и ее эффектом больше 128 шагов где все хорошо - приятной отладки. Для сравнения, в Chrome максимальная глубина стека когда последний раз смотрел была около 10к, в Firefox - почти на порядок больше. Этого хватает с лихвой.
PTC это не TCO. Например здесь нет рекурсии, но есть PTC:
const foo() => bar('hi')
const bar(s) => console.log(s)
В стандарте с PTC две проблемы.
Во первых в названии есть "tail call" и люди естественно путают с TCO. Может это был такой маркетинговый ход, чтобы протолкнуть революцию под видом простой фичи, пока толком ни кто не понял о чём речь?
TCO это локальная оптимизация. Вы просто переписываете код функции статически.
В PTC нет речи ни про рекурсию, ни про оптимизацию. Т.е. улучшения производительности фича явным образом не предполагает. А что тогда?
PTC говорит нам, что если в конце функции идет вызов другой, то ее нужно вызвать без использования стека. Вообще всегда - глобально.
Фактически, в стандарт добавили требование, которое вынуждает разработчиков интерпретатора отказаться от модели исполнения с использованием стека и перейти на другую - continuations (call/cc как в scheme).
В каком-то смысле это предложение вернуться к истокам. Но Microsoft/Intell/Google оптимизируют с оглядкой на стек и чтобы call/cc работала так же быстро нужно переделывать всю инфраструктуру снизу: от библиотек и компиляторов, поскольку "кто вызывал функцию, тот и подчищает" уже не работает. И до процессоров - которые умеют быстро развернуть стек в случае исключений, но спотыкаются о long jump.
Если человек не знает, что такое бинарное дерево - то мы вполне достоверно можем утверждать, что он в целом обладает околонулевыми знаниями CS (потому что человек, который хотя бы базовыми знаниями обладает, знает и что такое бинарное дерево и инвертировать его с легкостью сможет).
Вот практика и показывает, что это утверждение в некоторых случаях не верно.
Тесты на собеседовании дают ответ на другой вопрос - может-ли кандидат дать ответ в условиях ограниченного времени на некий рандомный вопрос первому встречному?
По сути это аналог игры "Кто хочет стать миллионером?" Ни кто же не воспринимает игру как проверку знаний. Хотя знания и там играют определенную роль.
людям нужен был специалист, а не деревенский самоучка
Я не отрицаю сам метод. Но не считаю, что он даёт 100% точность. Могут быть ошибки и это нужно учитывать, занимаясь экстраполяцией результатов.
без проблем можно в историю коротко записать, что и где рекурсия.
Вы пробовали отлаживать такой код в Safari? Я имею ввиду на практике. У меня был опыт как со своим кодом, так и с чужим. В итоге свой код переписывал без этих выкрутасов - здесь это делается чисто механически. С чужим же разбирался дальше в Chrome где все нормально видно.
Хвостовая рекурсия есть в JS со времен ES6 и поддерживается в Safari
Proper tail call (PTC) и tail call optimization (TCO, ака оптимизация хвостовой рекурсии) это не одно и то же. PTC добавили в стандарт какие-то фантазёры, когда она не была реализована ещё ни в одном браузере. Я полагаю, что это сделали как раз с подачи разработчиков Webkit (Safari), которые через примерно год ее предоставили.
Остальные не то, чтобы не осилили - там работы на вечер. Добавили, не понравилось, убрали. PTC убивает историю вызовов функции в стек трейсах - при ошибке вы видите только последний вызов, словно всех остальных ни когда не было. А стек трейсы и обработка ошибок это ещё несколько глав того же самого стандарта, где требования оказываются формально поломанными.
Webkit искусственно сохраняют последние 128 вызов, чтобы показывать в отладчике. Но в итоге совместили худшее - память по прежнему тратится, а стек получается обрезанным. Сколь-нибудь заметного выигрыша в производительности у них тоже не получилось.
При этом когда человек приходит в автосервис устраиваться - от него не требуют уметь собрать формулу один и чинить феррари за 30 минут без бумажки
Тут скорее как если повар, автор нескольких кулинарных бестселлеров, устраивается в приличный ресторан, а ему на интервью предлагают, допустим почистить вручную морковку на скорость.
Он успевает вычистить из двух только полторы и получает отказ - потому, что не умеет говорить. На вопрос:
- У вас повора чистят морковку вручную? - те дают честный ответ.
- Нет, к нам привозят уже чищенную, мы же приличное заведение.
- Может поворам приходится чистить, когда поставщик лажает и привозит грязную?
- Нет, у нас есть машинки для чистки - они справляются быстрее.
- Тогда почему предлагаете такое задание на собеседовании?
- Потому, что нам это стоит всего лишь две морковки.
Если у вас уже есть какой-нибудь паспорт с латиницей, то сделают как было там - паспорт в списке.
Но если получаете первый раз и у вас обратный билет на самолёт уже куплен, где вы записаны иначе, и куча договоров где вы сами себя записали латиницей - это не работает и билет с договорами мне пришлось переделывать.
В добавок теперь ни кто из носителей не может нормально произнести прочитаное - люди ещё удивляются почему у русских такие сложно произносимые имена. Я теперь завидую индусам. У них имена реально сложные, но фонетически достоверно прочитать с литиницы обычно получается с первого раза.
Ух ты, високосный год.
Мне кажется ваши статьи и через 20 лет будут читаться так же легко. Вы показываете абсолютно обыденные вещи, с которыми разработчики сталкиваются по сто раз на дню, но всегда удивительно красиво и романтично. Как если бы Бианки или Паустовский писали свои записки о природе IT.
TeX это Тьюринг полный язык.
Если из него убрать фишки программирования, отставив только функции разметки, достаточные для форматирования текста как в HTML, то думаю получится RTF.
Расскажите немного про проект. Сколько человек над ним вообще работало, сколько заняло времени и какие роли были в вашей команде?
Разработка это борьба со сложностью. Языки, фреймворки, алгоритмы это по сути взгляд на проблему под разными углами. Какой способ выстрелит зависит от конкретной задачи - здесь нет лучших, есть только подходящие.
Учиться сложно. Причем, чем глубже, тем сложнее. Это чем-то похоже на дженгу, только наборот - каждый новый кирпичек знаний норовит разломать ваши представления о прекрасном ко всем нулям.
Быстрое изучение языков это маркетинг, в стиле курсов изучения английского (и результат на выходе аналогичен). Пару слов связать получится, но только нормально писать - спустя годы.
Если в компании NIH синдром, то вы скорее всего будете пилить свое, даже если внутри тех миллионов строк. Бюджет сам себя не обоснует, а пытаться строить из себя нормального в дурдоме это плыть против денег в направлении за ворота, под дружное улюлюкание
санитаровруководства.На практике требуется не только читаемость, но и понятность, иначе такое решение никому не нужно. Может код помимо ТЗ по ночам биткойны майнит или котиков обижает, или нет - чём докажете?
Когда специалист экстра класса понимает конечную задачу своего руководителя, то руководителю приходится с ним либо на полном серьёзе делиться, либо прощаться. 0.01% это видимо те, руководители которых застыли в ожидании чуда (но это быстро проходит).
Как вариант там импортные Orange, либо в тех ящиках лежит местное Ядерное Оружие.
У них есть OneDrive - остальное в топку. Сейчас вообще протоколов, с которых начинался Интернет, почти не осталось. Чем дальше, тем все корпоративнее.
При использовании стека у вас гарантировано есть вся история вычислений "сверху до низу". В случае PTC это просто хвост - последние N вызовов. А все что раньше - тишина.
Например rxjs, ramda и fp-ts, активно использует код в стиле continuations, которые Safari благополучно лианеризирует. Если между точкой возникновения проблемы и ее эффектом больше 128 шагов где все хорошо - приятной отладки. Для сравнения, в Chrome максимальная глубина стека когда последний раз смотрел была около 10к, в Firefox - почти на порядок больше. Этого хватает с лихвой.
PTC это не TCO. Например здесь нет рекурсии, но есть PTC:
В стандарте с PTC две проблемы.
Во первых в названии есть "tail call" и люди естественно путают с TCO. Может это был такой маркетинговый ход, чтобы протолкнуть революцию под видом простой фичи, пока толком ни кто не понял о чём речь?
TCO это локальная оптимизация. Вы просто переписываете код функции статически.
В PTC нет речи ни про рекурсию, ни про оптимизацию. Т.е. улучшения производительности фича явным образом не предполагает. А что тогда?
PTC говорит нам, что если в конце функции идет вызов другой, то ее нужно вызвать без использования стека. Вообще всегда - глобально.
Фактически, в стандарт добавили требование, которое вынуждает разработчиков интерпретатора отказаться от модели исполнения с использованием стека и перейти на другую - continuations (call/cc как в scheme).
В каком-то смысле это предложение вернуться к истокам. Но Microsoft/Intell/Google оптимизируют с оглядкой на стек и чтобы call/cc работала так же быстро нужно переделывать всю инфраструктуру снизу: от библиотек и компиляторов, поскольку "кто вызывал функцию, тот и подчищает" уже не работает. И до процессоров - которые умеют быстро развернуть стек в случае исключений, но спотыкаются о long jump.
Рестораный бизнес и поварское искусство это разные вещи. Классные специалисты не обязательно хорошие предприниматели.
Вот практика и показывает, что это утверждение в некоторых случаях не верно.
Тесты на собеседовании дают ответ на другой вопрос - может-ли кандидат дать ответ в условиях ограниченного времени на некий рандомный вопрос
первому встречному?По сути это аналог игры "Кто хочет стать миллионером?" Ни кто же не воспринимает игру как проверку знаний. Хотя знания и там играют определенную роль.
Я не отрицаю сам метод. Но не считаю, что он даёт 100% точность. Могут быть ошибки и это нужно учитывать, занимаясь экстраполяцией результатов.
Вы пробовали отлаживать такой код в Safari? Я имею ввиду на практике. У меня был опыт как со своим кодом, так и с чужим. В итоге свой код переписывал без этих выкрутасов - здесь это делается чисто механически. С чужим же разбирался дальше в Chrome где все нормально видно.
А были какие-нибудь хитрые алгоритмы за последний год?
Proper tail call (PTC) и tail call optimization (TCO, ака оптимизация хвостовой рекурсии) это не одно и то же. PTC добавили в стандарт какие-то фантазёры, когда она не была реализована ещё ни в одном браузере. Я полагаю, что это сделали как раз с подачи разработчиков Webkit (Safari), которые через примерно год ее предоставили.
Остальные не то, чтобы не осилили - там работы на вечер. Добавили, не понравилось, убрали. PTC убивает историю вызовов функции в стек трейсах - при ошибке вы видите только последний вызов, словно всех остальных ни когда не было. А стек трейсы и обработка ошибок это ещё несколько глав того же самого стандарта, где требования оказываются формально поломанными.
Webkit искусственно сохраняют последние 128 вызов, чтобы показывать в отладчике. Но в итоге совместили худшее - память по прежнему тратится, а стек получается обрезанным. Сколь-нибудь заметного выигрыша в производительности у них тоже не получилось.
Тут скорее как если повар, автор нескольких кулинарных бестселлеров, устраивается в приличный ресторан, а ему на интервью предлагают, допустим почистить вручную морковку на скорость.
Он успевает вычистить из двух только полторы и получает отказ - потому, что не умеет говорить. На вопрос:
- У вас повора чистят морковку вручную? - те дают честный ответ.
- Нет, к нам привозят уже чищенную, мы же приличное заведение.
- Может поворам приходится чистить, когда поставщик лажает и привозит грязную?
- Нет, у нас есть машинки для чистки - они справляются быстрее.
- Тогда почему предлагаете такое задание на собеседовании?
- Потому, что нам это стоит всего лишь две морковки.
Если у вас уже есть какой-нибудь паспорт с латиницей, то сделают как было там - паспорт в списке.
Но если получаете первый раз и у вас обратный билет на самолёт уже куплен, где вы записаны иначе, и куча договоров где вы сами себя записали латиницей - это не работает и билет с договорами мне пришлось переделывать.
В добавок теперь ни кто из носителей не может нормально произнести прочитаное - люди ещё удивляются почему у русских такие сложно произносимые имена. Я теперь завидую индусам. У них имена реально сложные, но фонетически достоверно прочитать с литиницы обычно получается с первого раза.
Можете привести примеры из практики работы с GraphQL, когда испозовали алгоритмы работы с деревьями и что это были за алгоритмы?