Вы не в ту сторону воюете, я не противник статической типизации. Но и обманывать себя не надо. Статическая типизация не делает код надежней или безопасней, все, что вы получаете — это автокомплит и авторефакторинг + возможность оптимизации кода до рантайма. Это и нужно держать в голове, за надежность отвечают другие инструменты. Автотесты и в крайних случаях верификация. Да в Го вы не смоете присвоить строке число по ошибке, но зато легко можете прочитать побитые данные не из того файлика и упасть там, где не ожидаете, потому что нарушена логика. Логические ошибки куда более частые, чем попытка взять квадратный корень из строки.
Если мы говорим опять же про современный мир, то ну да наверно какой-то монолит писать на джаве удобней, чем на питоне, но если у вас зоопарк микросервисов, тут на Го, тут на Эрланге, тут на Скале, там на R, а сверху обвязка на торнадо, то вам тут не поможет статическая типизация. У вас должна быть документация по как минимум API взаимодействия. А еще лучше, если документация описывает философию проекта. Сферический стажер в вакууме без присмотра вам сломает любую систему на любом языке программирования (вы обязаны ревьюить его код, а в идеале любой коммит должен кто-то принимать и не тот, кто его писал).
Языки программирования тут вообще не при чем. Мне приходилось программировать на всем от асма до пролога, от сайтика до петофлопного суперкомпьютера. Но мерения органами тут делу не помогут и я как раз не люблю спускаться на личности и разговариваю с вами заведомо как с равным, проблема как раз не в языке, что я и пытаюсь показать.
К статье у меня нет вопросов, чуваки создали стартап прототипировали прототипировали да не выпрототипировали, решили, что им не хватает авторефакторинга и автокомплита — флаг им в руки, ни на что не претендуют. Вы же пишете про более концептуальные вещи, взгляд на которые у вас не одинок, при этом он дико предвзятый.
Никогда не порекомендую питон для высоко нагруженного сервиса с высокой стоимостью отказа.
Понятно, что быстрое преобразование фурье на голом питоне писать не надо и Си отлично тут подойдет, а вот для оркестрации сокетов и асинхронных низкоуровневых вызовов питон отлично подходит за счет гибкости, так как для этого он и создавался. Информационную трубу с кучей соединений с юзерами, базой и тд я бы писал на питоне или эрланге скорее, чем на с++ или голых сях.
Что такое «высокая стоимость отказа»? Может быть высокая цена ошибки? Аля космос медицина? Или высокая доступность? Опять непонятно.
Высокая надежность кода достигается например верификацией в той же медицине или космосе. Привет пролог.
Написание отказоустойчивых распределенных систем — это опять же не про стек свистелок и перделок, это математика в первую очередь. Со всякими прикольными моделями типа конечных автоматов, сетей петри и прочими крутыми штуками. Большинство программистов сейчас даже сформулировать определение алгоритма не смогут.
Тестирование? И тут опять математика со своими минимальными тестами. И кстати с точки зрения тестирования — типизация будет избыточной. В этом нет ничего плохого кроме того, что программист подсознательно начинает считать код с большим числом тестов более надежным, и вместо реального тестирования системы хорошими интеграционными тестами, все тестирование скатывается в тривиальные бессистемные дублирования вроде f(x) = x + x тестируем f(2) == 4; f(3) == 6; f(-1) = -2. Отлично, только вот с точки зрения надежности мы ничего не получили. В идеальном мире тестирование — это минимальный набор данных с ответами, которые в случае прохождения гарантируют корректность системы. Только вот проблема чаще всего бывает не в самих тестах, а в интерпретации и переводе спецификации с человеческого языка в структурный. И тут опять привет пролог. Попробуйте как нибудь на досуге дать строгое определение хотя бы списку. Слишком просто? Окей, а теперь графу.
Я это все к чему? Вместо того, чтобы поднимать качество концептуальных знаний, техники программирования и общей грамотности программистов, мы раз к разу спускаемся до разговоров про «а если я случайно инту строку присвою что тогда?». Это так же смешно, как разговор про велосипедные шлемы, если нет вело инфраструктуры и велосипедист вынужден выезжать на тротуары и обочины, он неизбежно будет убивать себя и других участников движения, и пенопластовая шапочка тут не поможет.
«Сломалось во время выполнения» сломаться может что угодно и когда угодно и почему угодно, типы или ЯП последнее, что тут важно.
Причем как раз очень опасно думать, что условно статическая типизация повышает качество кода, это очень опасное заблуждение. Это как с велосипедными шлемами: люди думают, что велосипедный шлем повышает их безопасность и ездят более быстро/агрессивно. Тут можно было бы развить аналогию дальше…
менее предсказуем на этапе эксплуатации
Это же обычный bias. И вообще, что такие предсказуемость? Отказоустойчивость я могу понять: можно посчитать скажем отношение общего времени работы к даунтаймам или число ошибок на число всех запусков и т.д. Отказоустойчивые системы можно писать на любом языке программирования, вон взять тот же Erlang с его знаменитыми девять-девяток. А предсказуемость это что-то из области самовнушения.
У меня вот обратная проблема, я наоборот слишком усложняю решения задач там, где можно оператору написать в инструкции «вот в этом случае не нажимать». Все зависит от размера компании и бюджета.
Например, вместо пандусов и лифтов в пешеходных переходах можно инвалидам за счет города выделить бесплатное такси за счет муниципалитета. Возможно это в разы дешевле, хотя инженерно пандусы и лифты выглядят куда круче. (Я кстати не утверждаю, что так будет правильно, я не урбанист и не архитектор, я лишь привел другой вариант, который может оказаться в определенных условиях лучше, и я думаю, что именно это делает меня инженером, а не знание алгоритмов и стеков технологий)
Мастер не тот, кто все знает, а тот — кто знает то, чего он не знает. Имхо если на собеседовании спрашивать «что бы вы хотели изучить, и что даже трогать не станете по крайней мере сейчас», то можно куда полнее картину о кандидате построить.
… наркоманом, равна 0,01 (базовое значение). Если выбранный человек – наркоман, то существует 100% вероятность того, что у него будут свежие отметки от иголок на руке (элемент чувствительности). Однако, есть вероятность в 0,19% ...
Разобраться становится труднее, когда непроцентные вероятности перемежаются с процентными. Сходу вообще непонятно, что тут происходит.
UPD: Прочитав дальше понял, что первая вероятность в %, но просто знак % пропущен.
Ну у них наверно KPI завязан на число собеседуемых, а то что компания от этого деньги теряет, никого не волнует. И так во всем. А все почему, потому что нанимают не тех, кто будет отстаивать интересы компании и быть «в доле» с компанией, а нанимают абы как абы кого лишь бы мог «очередь реализовать двумя стеками с амортизационной сложностью О(1)». Остальные специальности наверно так же нанимают… И тут вы скажете «как ты смеешь критиковать компанию, которая стоит триллиард долларов», а я возражу, что система сломана не только внутри компаний, но и снаружи. Самые умные люди в мире в среднем это все-таки ученые, но в среднем они не самые богатые. Хотя без ученых эти триллиард как цифра не существовала бы :)
Ну тут тот же эффект как в инвестировании: инвестировать в компании, которые еще не прибыльные опасно, но им очень нужны инвестиции, а инвестировать в компании, которые уже вышли на прибыль сложно, потому что все хотят туда инвестировать, а инвестиции этим компаниям уже могут быть и не нужны.
Чаще всего компания хочет тех сотрудников, которых не может получить. Поднимает ставки, и на их место начинают ломиться те, кто на все согласен ради бесплатных обедов и пуфиков.
Вообще на вопрос о мотивации — если человек на собеседовании приходит с низкой мотивацией, а потом его удается «разогреть» это как раз лучше, чем нанять «гуглофана», потому что в голову-то не залезешь, этот гуглофан может быть кем угодно от инсайдера до интервьюкракера. А вот если человек не очень-то хочет работать в гугле, то это не просто же так. На интервью его наверняка соблазнил HR. Всегда было интересно, что бы ответил интервьюер, которому кандидат скажет: «мне че-то лень печатать, давай я тебе продиктую код, а ты сам запишешь»…
Ага, а еще это неплохой способ съездить, скажем, в Норвегию на рыбалку за чужой счет. Ищем подходящую компанию, а дальше дело техники.
И это еще одна «грань» вышеупомянутого айсберга. Способности потенциального работника ставятся выше его мотивации, хотя без должной мотивации сотрудник будет больше вреда приносить, чем пользы, вне зависимости от его навыков.
Вы «защищаетесь» не с той стороны, с которой я «нападаю».
А на счет домашней заготовки, ну это еще не факт, что хорошо. Есть люди, которые хорошо проходят интервью, а есть те, кто хорошо работают, и это далеко не одни и те же люди. Зайдите на любой сайт, посвященный теме интервью, первое, что вы там увидите «I will teach you to be good at programming interviews» написанное разными словами. То есть это как минимум говорит о том, что проходить интервью и работать это две большие разницы. Это УЖЕ должно наводить на мысль о том, что система сломана.
Интервью в гуглоподобных компаниях и их подражателях давно сломаны, и никто не хочет их чинить (а многие даже признать, что они сломаны). Проблем очень много и о них можно было бы статью написать, но если выделить самое основное, то компании вроде гугла, майкрософта, амазона и т.д. пытаются принять решение о найме пианиста по его способности играть на скрипке (это если повезло и борщ не заставили варить).
Хочется верить, что тот, кто изначально использовал задачи-головоломки на собеседовании действительно умел ставить по процессу решения правильный диагноз, но потом все сразу сломалось, как только собеседующие стали оценивать правильность ответа, вместо процесса размышления. Тут я поступлю нечестно и не буду ничего доказывать. Скажу лишь, что все-таки есть адекватные собеседующие, которым не все равно, кого наймут, а кого нет (обычно это в не очень популярных компаниях с точки зрения HR бренда, например, мне лично понравилось интервью в JP Morgan, хотя это вообще банк).
Те, кто в теме, мне возразят, что в гугле уже не задают задачи-головоломки, но на самом деле ничего не поменяется от того, что вы спрашиваете задачи вроде «поиска подотрезка с максимальной суммой». Если не знать решения на эту задачу, то вам явно не хватит 30 минут, чтобы ее решить. И даже показать, как вы думаете. Максимум вы всунете туда какой-то NlogN трюк, и не факт, что такой спец будет хуже «звезы», который знает решение, и не факт, что он будет лучше человека, который «почти» придумает линейное решение, но не успеет за 30 минут.
Если гуглу нужен «крутой алгоритмист», то вопросов нет, но гугл же утверждает, что они инженера нанимают. И вот тут можно вспомнить про борщ, о котором я говорил выше. Я не отрицаю сильную корреляцию между инженирингом и алгоритмами (математикой в общем случае). Человек, который знает алгоритмы и, например, еще участвует в контестах, может быть заодно еще и хорошим разработчиком софта. Но все таки разработка софта — это марафонский бег, и спринтер, даже самый лучший может не добежать до финиша в нужной кондиции.
Описанный кейс лишь одна маленькая грань большого айсберга системы найма, которая кстати заодно разгоняет скорость текучки и снижает комфорт и фан от работы. Да и качество конечного продукта давно оставляет желать лучшего.
Можно еще сначала наклеить одну большую хорошую наклейку на нормальном клее, что-то нейтральное, а сверху наклеить че хочешь, если придется продавать ноут, то достаточно будет содрать «базу»
Подобные фабричные методы можно превращать в асинхронные функции, что абсолютно невозможно провернуть с __init__.
Все еще хуже. Возможно. Буквально недавно тут даже было видео Юрия Селиванова с PyCon Russia. Как минимум наследование уже будет адом, особенно множественное.
В 2016 году Росстат опубликовал данные о состоянии автомобильных дорог в стране – оказалось, стандартам качества не отвечают 62% из них.
Интересно, как это посчитали? (без сарказма, правда интересно, как такое считают) По моим ощущениям для российских реалий эта цифра кажется заниженной.
хотя...
… если они считают так: 62% дороги — это ямы и трещины, значит остальные-то 38% все еще формально соответствуют стандартам качества. Хотя по факту вся дорога непригодна для использования.
Я конечно знаю, что росстат завышает свои оценки, но даже эти цифры чудовищны…
BTW заметил, что некоторые физики говорят «час киловатт» или даже «часов киловатт».
Такой стиль чем-то напоминает мастера Йоду или старую с/с++ фишку писать «if (0 == x)» вместо «if (x == 0)».
Скорее всего они так говорят для студентов, но аналогия из с++ мне подсказывает, что, возможно, это страховка для себя же чтобы не забыть :)
А в случае, если что-то пойдет не так, Миша будет отвечать в своем стиле: «Проблемы есть только у тех, кто их видит», или «Мы проанализировали статистику и она в пределах нормы».
Миша, ты правда такой, или у тебя забрали паспорт?
Список означает, что вы используете дополнительную память. Задачу можно решить за O(n) операций и O(1) дополнительной памяти. Фактически кроме пары переменных и выключателей в вагонах ничего не нужно.
Мое решение (псевдокод)
class Train:
set(on/off) # включить/выключить свет в текущем вагоне
test(on/off) # свет горит/не горит
left() # идем налево
right() # идем направо
function get_train_length:
k = 1
set(on)
while test(on):
k = k*2
for i in 0..k:
right()
set(off)
for i in 0..k:
left()
# теперь свет нигде не горит, и мы в вагоне, в котором начали
set(on)
right()
count = 1
while test(off):
count = count + 1
right()
return count
В моем решении в худшем случае придется сделать не более 9n переходов между вагонами (т.е. все равно О(n)), и кроме пары счетчиков дополнительной памяти не нужно, то есть O(1) дополнительной памяти. Возможно, можно оптимальней.
Если мы говорим опять же про современный мир, то ну да наверно какой-то монолит писать на джаве удобней, чем на питоне, но если у вас зоопарк микросервисов, тут на Го, тут на Эрланге, тут на Скале, там на R, а сверху обвязка на торнадо, то вам тут не поможет статическая типизация. У вас должна быть документация по как минимум API взаимодействия. А еще лучше, если документация описывает философию проекта. Сферический стажер в вакууме без присмотра вам сломает любую систему на любом языке программирования (вы обязаны ревьюить его код, а в идеале любой коммит должен кто-то принимать и не тот, кто его писал).
К статье у меня нет вопросов, чуваки создали стартап прототипировали прототипировали да не выпрототипировали, решили, что им не хватает авторефакторинга и автокомплита — флаг им в руки, ни на что не претендуют. Вы же пишете про более концептуальные вещи, взгляд на которые у вас не одинок, при этом он дико предвзятый.
Понятно, что быстрое преобразование фурье на голом питоне писать не надо и Си отлично тут подойдет, а вот для оркестрации сокетов и асинхронных низкоуровневых вызовов питон отлично подходит за счет гибкости, так как для этого он и создавался. Информационную трубу с кучей соединений с юзерами, базой и тд я бы писал на питоне или эрланге скорее, чем на с++ или голых сях.
Что такое «высокая стоимость отказа»? Может быть высокая цена ошибки? Аля космос медицина? Или высокая доступность? Опять непонятно.
Высокая надежность кода достигается например верификацией в той же медицине или космосе. Привет пролог.
Написание отказоустойчивых распределенных систем — это опять же не про стек свистелок и перделок, это математика в первую очередь. Со всякими прикольными моделями типа конечных автоматов, сетей петри и прочими крутыми штуками. Большинство программистов сейчас даже сформулировать определение алгоритма не смогут.
Тестирование? И тут опять математика со своими минимальными тестами. И кстати с точки зрения тестирования — типизация будет избыточной. В этом нет ничего плохого кроме того, что программист подсознательно начинает считать код с большим числом тестов более надежным, и вместо реального тестирования системы хорошими интеграционными тестами, все тестирование скатывается в тривиальные бессистемные дублирования вроде f(x) = x + x тестируем f(2) == 4; f(3) == 6; f(-1) = -2. Отлично, только вот с точки зрения надежности мы ничего не получили. В идеальном мире тестирование — это минимальный набор данных с ответами, которые в случае прохождения гарантируют корректность системы. Только вот проблема чаще всего бывает не в самих тестах, а в интерпретации и переводе спецификации с человеческого языка в структурный. И тут опять привет пролог. Попробуйте как нибудь на досуге дать строгое определение хотя бы списку. Слишком просто? Окей, а теперь графу.
Я это все к чему? Вместо того, чтобы поднимать качество концептуальных знаний, техники программирования и общей грамотности программистов, мы раз к разу спускаемся до разговоров про «а если я случайно инту строку присвою что тогда?». Это так же смешно, как разговор про велосипедные шлемы, если нет вело инфраструктуры и велосипедист вынужден выезжать на тротуары и обочины, он неизбежно будет убивать себя и других участников движения, и пенопластовая шапочка тут не поможет.
Причем как раз очень опасно думать, что условно статическая типизация повышает качество кода, это очень опасное заблуждение. Это как с велосипедными шлемами: люди думают, что велосипедный шлем повышает их безопасность и ездят более быстро/агрессивно. Тут можно было бы развить аналогию дальше…
Это же обычный bias. И вообще, что такие предсказуемость? Отказоустойчивость я могу понять: можно посчитать скажем отношение общего времени работы к даунтаймам или число ошибок на число всех запусков и т.д. Отказоустойчивые системы можно писать на любом языке программирования, вон взять тот же Erlang с его знаменитыми девять-девяток. А предсказуемость это что-то из области самовнушения.
Например, вместо пандусов и лифтов в пешеходных переходах можно инвалидам за счет города выделить бесплатное такси за счет муниципалитета. Возможно это в разы дешевле, хотя инженерно пандусы и лифты выглядят куда круче. (Я кстати не утверждаю, что так будет правильно, я не урбанист и не архитектор, я лишь привел другой вариант, который может оказаться в определенных условиях лучше, и я думаю, что именно это делает меня инженером, а не знание алгоритмов и стеков технологий)
Мастер не тот, кто все знает, а тот — кто знает то, чего он не знает. Имхо если на собеседовании спрашивать «что бы вы хотели изучить, и что даже трогать не станете по крайней мере сейчас», то можно куда полнее картину о кандидате построить.
Разобраться становится труднее, когда непроцентные вероятности перемежаются с процентными. Сходу вообще непонятно, что тут происходит.
UPD: Прочитав дальше понял, что первая вероятность в %, но просто знак % пропущен.
Чаще всего компания хочет тех сотрудников, которых не может получить. Поднимает ставки, и на их место начинают ломиться те, кто на все согласен ради бесплатных обедов и пуфиков.
Вообще на вопрос о мотивации — если человек на собеседовании приходит с низкой мотивацией, а потом его удается «разогреть» это как раз лучше, чем нанять «гуглофана», потому что в голову-то не залезешь, этот гуглофан может быть кем угодно от инсайдера до интервьюкракера. А вот если человек не очень-то хочет работать в гугле, то это не просто же так. На интервью его наверняка соблазнил HR. Всегда было интересно, что бы ответил интервьюер, которому кандидат скажет: «мне че-то лень печатать, давай я тебе продиктую код, а ты сам запишешь»…
И это еще одна «грань» вышеупомянутого айсберга. Способности потенциального работника ставятся выше его мотивации, хотя без должной мотивации сотрудник будет больше вреда приносить, чем пользы, вне зависимости от его навыков.
А на счет домашней заготовки, ну это еще не факт, что хорошо. Есть люди, которые хорошо проходят интервью, а есть те, кто хорошо работают, и это далеко не одни и те же люди. Зайдите на любой сайт, посвященный теме интервью, первое, что вы там увидите «I will teach you to be good at programming interviews» написанное разными словами. То есть это как минимум говорит о том, что проходить интервью и работать это две большие разницы. Это УЖЕ должно наводить на мысль о том, что система сломана.
Интервью в гуглоподобных компаниях и их подражателях давно сломаны, и никто не хочет их чинить (а многие даже признать, что они сломаны). Проблем очень много и о них можно было бы статью написать, но если выделить самое основное, то компании вроде гугла, майкрософта, амазона и т.д. пытаются принять решение о найме пианиста по его способности играть на скрипке (это если повезло и борщ не заставили варить).
Хочется верить, что тот, кто изначально использовал задачи-головоломки на собеседовании действительно умел ставить по процессу решения правильный диагноз, но потом все сразу сломалось, как только собеседующие стали оценивать правильность ответа, вместо процесса размышления. Тут я поступлю нечестно и не буду ничего доказывать. Скажу лишь, что все-таки есть адекватные собеседующие, которым не все равно, кого наймут, а кого нет (обычно это в не очень популярных компаниях с точки зрения HR бренда, например, мне лично понравилось интервью в JP Morgan, хотя это вообще банк).
Те, кто в теме, мне возразят, что в гугле уже не задают задачи-головоломки, но на самом деле ничего не поменяется от того, что вы спрашиваете задачи вроде «поиска подотрезка с максимальной суммой». Если не знать решения на эту задачу, то вам явно не хватит 30 минут, чтобы ее решить. И даже показать, как вы думаете. Максимум вы всунете туда какой-то NlogN трюк, и не факт, что такой спец будет хуже «звезы», который знает решение, и не факт, что он будет лучше человека, который «почти» придумает линейное решение, но не успеет за 30 минут.
Если гуглу нужен «крутой алгоритмист», то вопросов нет, но гугл же утверждает, что они инженера нанимают. И вот тут можно вспомнить про борщ, о котором я говорил выше. Я не отрицаю сильную корреляцию между инженирингом и алгоритмами (математикой в общем случае). Человек, который знает алгоритмы и, например, еще участвует в контестах, может быть заодно еще и хорошим разработчиком софта. Но все таки разработка софта — это марафонский бег, и спринтер, даже самый лучший может не добежать до финиша в нужной кондиции.
Описанный кейс лишь одна маленькая грань большого айсберга системы найма, которая кстати заодно разгоняет скорость текучки и снижает комфорт и фан от работы. Да и качество конечного продукта давно оставляет желать лучшего.
Все еще хуже. Возможно. Буквально недавно тут даже было видео Юрия Селиванова с PyCon Russia. Как минимум наследование уже будет адом, особенно множественное.
Интересно, как это посчитали? (без сарказма, правда интересно, как такое считают) По моим ощущениям для российских реалий эта цифра кажется заниженной.
Я конечно знаю, что росстат завышает свои оценки, но даже эти цифры чудовищны…
Такой стиль чем-то напоминает мастера Йоду или старую с/с++ фишку писать «if (0 == x)» вместо «if (x == 0)».
Скорее всего они так говорят для студентов, но аналогия из с++ мне подсказывает, что, возможно, это страховка для себя же чтобы не забыть :)
Миша, ты правда такой, или у тебя забрали паспорт?
В моем решении в худшем случае придется сделать не более 9n переходов между вагонами (т.е. все равно О(n)), и кроме пары счетчиков дополнительной памяти не нужно, то есть O(1) дополнительной памяти. Возможно, можно оптимальней.