Самое страшное, что люди с таким мнением могут оказаться моими нанимателями :)
Раскрою:
— когда знание инструментов важнее знания принципов
— когда копипаста — нормальное явление в проекте
— когда менеджерство и софт скиллы (управление тех. долгом и легаси кодом) — важнее элементов computer science.
Тогда «управление техдолгом» становится «нам нужно 4 спринта на рефакторинг» вместо «я тут в пятницу вечером написал анализатор нашего легаси, чтобы искать баги не заглядывая в IDE, можете гонять его перед тестами». Само собой это работа для «чистого программиста»
Процитирую бессмертное:
«Где же работает типичный настоящий программист? Какие программы достойны таких талантливых индивидумов? Вы можете быть уверены, что настоящий программист не умрет за написанием программы „Зарплата“ на Коболе или сортируя список почтовых отправлений журнала People. Настоящий программист желает задачи с важностью землетрясения.
Настоящие программисты работают на национальную лабораторию в Лос-Аламосе, создавая программы на супер ЭВМ Cray-1, моделирующие атомную бомбу. Они так же работают на Агенство по Национальной Безопасности, расшифровывая передачи русских.»
Если бы я сидел на кафедре информатики ПГТ «Верхние Грязи», да еще и с интернетом или просто хорошей библиотекой, то за 7 лет без отвлекающих факторов (вроде индустрии) я бы стал богоподобным инженером. Да еще и тестируя все идеи на студентах…
И при прочих равных я бы предпочел 30+ чем 23-летнего сеньора )
А чтобы понять насколько такой человек хорош я бы предложил ему прямо на собесе реализовать в своем компиляторе оператор, который был бы обратным к GOTO — человек без фантазии даже не сможет вообразить подобное. И если он справится — можно брать не раздумывая: его существование — это просто редкая флуктуация, такой человек в принципе может достичь практически любых целей
Человек, способный сам разобраться как написать компилятор или интерпретатор, или даже просто прочитавшивший SICP и успешно выполнивший все упражнения освоит гит и поймет http за пару часов.
В особенности ценно, если этот человек сделал это не потому что получил такую задачу, а из любопытства. Это показывает энтузиазм и умение достигать цели.
Совсем идеально, если при этом он достиг этой цели в области, где нельзя взять руководство и сделать все по нему. Есть еще места, куда мануалов не завезли.
Ну а если он по результатам написал этот мануал сам, и из него не только понятно как делать, но и почему именно так и с какими граблями можно столкнуться — я бы нанял такого просто чтобы он не усилил конкурентов. Не говоря уже о пользе дела.
-----.
Нанимать за знания бессмысленно, это требует точного попадания в предметку. Нанимать за способности извлекать, осваивать и применять знание — гораздо разумнее
Нет, это не писать типизацию самому, это интроспекция + паттерн-матчинг. Сравнительно немного кода, кстати.
Что касается примера:
При работающем код-волкере ошибка будет при попытке залить def a(b), потому что интроспекция обнаружит отсутствие метода b у класса B.
Или, если обновляется класс B — то ошибка возникнет при попытке залить его метод b — потому что есть неурегулированные вызовы к нему.
Таким образом все довольно надежно.
Это не compile-time и не run-time — а update-time. Ошибка в рантайме может случиться только если вызываемый метод, например b, вычисляется динамически, такое код-волкер не отловит (если его специально не неписали настолько умным). Но если вы вычисляете вызываемый метод, то код вычисления может сам проверить, есть ли то, что он собирается вызывать, благо метаобьектный протокол позволяет заглянуть.
Там вроде в британии железные дороги работают на лиспе, но я точно не помню. Не знаю сопоставимо ли это со спарком, но если между делом, то как лиспер, не могу понять зачем кому-то могли бы понадобиться еще языки, если есть лисп :)
> могу ли я как-то узнать об этой ошибке не нажимая на кнопку и не покрывая каждую функцию тестами
Да, если спросить интроспективно все места, где метод вызывается. Это можно сделать автоматически, если написать немного кода.
Например код-волкер может проходить по обновляемой функции, запрашивать все вызываемые функции и проверять их сигнатуру. Если она не совпадает — прерывать обновление. Не то чтобы мне такое было нужно когда-либо, но я бы написал если бы было необходимо.
Сценарий, как я понимаю такой:
— Пишем doFoo которая принимает аргументы
— Пишем main который вызывает doFoo.
— Исправляем doFoo, теперь она не принимает аргументов. Если в этот момент main будет вызыван — будет runtime-error.
— Поэтому перед тем как обновить doFoo следует найти все его вызов doFoo и исправить их, чтобы они не передавали аргументов. Это можно сделать интроспекцией или просто поиском по сорцам.
Но изначально вопрос был про объекты. Впрочем, я вроде бы уже ответил там.
С чего вдруг проблема останова? Интроспекция на уровне структур данных и CFG плюс удобные инструменты — все то же самое, что обычные программисты делают в IDE, только в рантайме, на живой системе.
Я сам нахожу те места, где он использовался (для этого есть специальный вызов в интроспекции). После этого удаляю их, нажимаю Ctrl+E (evaluate), а затем удаляю метод, нажимаю Ctrl+E (evaluate) — и все. Объекты будут изменены когда к ним произойдет следующее обращение
Раскрою:
— когда знание инструментов важнее знания принципов
— когда копипаста — нормальное явление в проекте
— когда менеджерство и софт скиллы (управление тех. долгом и легаси кодом) — важнее элементов computer science.
Тогда «управление техдолгом» становится «нам нужно 4 спринта на рефакторинг» вместо «я тут в пятницу вечером написал анализатор нашего легаси, чтобы искать баги не заглядывая в IDE, можете гонять его перед тестами». Само собой это работа для «чистого программиста»
Процитирую бессмертное:
И при прочих равных я бы предпочел 30+ чем 23-летнего сеньора )
А чтобы понять насколько такой человек хорош я бы предложил ему прямо на собесе реализовать в своем компиляторе оператор, который был бы обратным к GOTO — человек без фантазии даже не сможет вообразить подобное. И если он справится — можно брать не раздумывая: его существование — это просто редкая флуктуация, такой человек в принципе может достичь практически любых целей
В особенности ценно, если этот человек сделал это не потому что получил такую задачу, а из любопытства. Это показывает энтузиазм и умение достигать цели.
Совсем идеально, если при этом он достиг этой цели в области, где нельзя взять руководство и сделать все по нему. Есть еще места, куда мануалов не завезли.
Ну а если он по результатам написал этот мануал сам, и из него не только понятно как делать, но и почему именно так и с какими граблями можно столкнуться — я бы нанял такого просто чтобы он не усилил конкурентов. Не говоря уже о пользе дела.
-----.
Нанимать за знания бессмысленно, это требует точного попадания в предметку. Нанимать за способности извлекать, осваивать и применять знание — гораздо разумнее
Что касается примера:
При работающем код-волкере ошибка будет при попытке залить def a(b), потому что интроспекция обнаружит отсутствие метода b у класса B.
Или, если обновляется класс B — то ошибка возникнет при попытке залить его метод b — потому что есть неурегулированные вызовы к нему.
Таким образом все довольно надежно.
Это не compile-time и не run-time — а update-time. Ошибка в рантайме может случиться только если вызываемый метод, например b, вычисляется динамически, такое код-волкер не отловит (если его специально не неписали настолько умным). Но если вы вычисляете вызываемый метод, то код вычисления может сам проверить, есть ли то, что он собирается вызывать, благо метаобьектный протокол позволяет заглянуть.
Да, если спросить интроспективно все места, где метод вызывается. Это можно сделать автоматически, если написать немного кода.
Например код-волкер может проходить по обновляемой функции, запрашивать все вызываемые функции и проверять их сигнатуру. Если она не совпадает — прерывать обновление. Не то чтобы мне такое было нужно когда-либо, но я бы написал если бы было необходимо.
— Пишем doFoo которая принимает аргументы
— Пишем main который вызывает doFoo.
— Исправляем doFoo, теперь она не принимает аргументов. Если в этот момент main будет вызыван — будет runtime-error.
— Поэтому перед тем как обновить doFoo следует найти все его вызов doFoo и исправить их, чтобы они не передавали аргументов. Это можно сделать интроспекцией или просто поиском по сорцам.
Но изначально вопрос был про объекты. Впрочем, я вроде бы уже ответил там.
У меня наоборот есть вопросы к Java — допустим, у меня есть класс, и на работающей системе есть сотня объектов этого класса.
Если я добавлю в класс поле или пару методов — что мешает Java обновить объекты этого класса при следующем обращении к ним?
он будет автоматически перекомпилирован в момент следующего обращения (в CL)