кажется с точки зрения реализации нет особой разницы строить дерево или считать сразу. Дерево лучше тем что если будет поддержка переменных это можно один раз разобрать а потом подставлять.
> у вас грамматика из четырех элементов, без возвратов.
с возвратом конечно, там есть peek это на самом деле то же самое, что вытащить элемент и его вернуть потом.
На самом деле когда я это писал меня интересовало примерно следующее, только что придумана задача на сколько программист который не знает теорию компиляторов сможет это решить и сколько это времени займет. Выяснилось, что вроде решаемо.
Я в статье перечислил правильные способы это сделать, но сам не сделал т.к. для меня это означало бы сначала почитать теорию.
> Вы создаете новые типы.
Где это, std::auto_ptr это очень даже стандартный тип, плюс по-моему это почти единственный способ их функции что-то вернуть по указателю а не значением, и не уточнять кто теперь главный за освобождение этого указателя.
Можно сравнить чем голый указатель опасен, или shared_ptr опасен.
> Если я решу задачу в 50 строк, прицепив к продукту нужные библиотеки
На само деле в больших проектах прицепление библиотек — по талонам. В смысле большая часть таго что вроде как есть работающее на самом деле на наших данных ломается, есть некоторое количество проверенных.
> веб-сервер на С++, способный решить предыдущую задачу
а чем не подойдет консольную программу в init.d вписать добавив заголовок? web сервер на C++ чтобы написать это более менее объемное решение, в простом варианте сравнимое с самой задачей. Т.е. можно но это эффективно увелдичение времени на разработку в 2 раза.
Практика(и наша и гугла) показала, что математики, которые не могут написать код чтобы проиллюстрировать свою идею почти совсем бесполезны(production код они могут не писать, но прототипы обязаны). Двигают прогресс все-таки программисты-математики.
Ну вот у меня есть мнение что через 5 лет исследовательскими задачами будут заниматься люди которые сейчас только, что закончили вуз и возможно пишут генераторы json-а и задачки по machine learning на coursera.org
если что то в моем решении как раз тест с длиннющей генеренной формулой вместо ввода данных, и комментарии(но комментарии я скорее для хабра написал, если бы сам делал задание не стал бы)
Тезисы ответа на него такие:
1) Мы технологическая компания. (Под этим имеется ввиду, что вот макдональдс не технологическая компания, может у них есть программисты которые занимаются внутренними системами, но на бизнес компании они не влияют. У нас если программист сделал алгоритм ранжирования лучше чем у гугла или ускорил программу работающую на 20000 серверах на 10% это на бизнесе уже очень конкретно отражается)
2) К сожалению все простые способы технологически повлиять на бизнес компании уже сделаны, остались сложные. Для их реализации нужны очень умные люди. Да этих людей нужно не много, но сейчас их у всех компаний сильно меньше, чем надо.
3) Нанять этих людей почти нельзя, но их можно вырастить, люди которые сейчас руководят разработкой ранжирования пришли 8-10 лет назад студентами, и наверное в своей карьере писали json-о подобное что-то.
4) Так вот, чтобы у тебя через 5-10 лет были люди которые двигают бизнес компании вперед надо прямо сейчас нанимать людей у которых их потолок сильно выше написания json файлов. Даже если сейчас нужно в том числе и json делать.
5) Да часть из этих людей свой потолок не реализуют, по разным причинам(в сильной мере от них зависящих) и останутся недовольны, зато другая часть будет делать реально клевые штуки.
6) Если же нанять людей которые ничего кроме генерации json-а делать не смогут, то тягаться с ребятами типа Гугла будет достаточно грустно.
Ну просто «разработать веб-сервис, который позволяет узнать курсы валют» это тоже не практическая задача, в смысле вы ее так же викинете, если вам только не нужно 50 разных сервисов которые отдают курсы валют.
Что касается нас, то у нас специфика в том, что мы хоть и интернет компания, у нас почти нет web разработчиков в нормльном понимании. Т.е. человек будет решать практические проблем уже в некоем стандартном окружении и поднимать web сервис самому ему наврядли пригодится. А вот уметь разбираться в алгоритмах средней сложности — вполне.
Я знаю что такое legacy код. Я попросил автора комментария уточнить, что он имел ввиду, вдруг это как-то касается Яндекса. Код у индусов мы вроде не покупаем, весь код в рабочем состоянии.
Если вы можете написать синтаксический парсер, зачем работать над кодом который написали люди которые не могут?
Ну в чем проблема, освойте язык и приходите, мы пару недель то уж собеседования подождем :)
p.s. Глобально вы конечно правы. Для хорошего программиста знание языка программирования ничто. Проблема в том что есть много людей которые за много лет вообще ни одного языка не освоили хорошо, и чтобы их отсечь про язык надо таки спрашивать.
В результате прогона решета у вас будет все простые числа до 2^24, но между 2^24 и 2^48 тоже наверняка встречаются простые числа и их тоже будет нужно найти, для этого достаточно будет поделить их на все простые числа из решета. «Вот тут то мышка и пригодилась....» (с) анекдот. В смысле куда деть несколько CPU теперь понятно(да и решето на них можно считать, если аккуратно).
Ход мыслей imho очень правильный, хотите к нам в Яндекс?
Мы аккуратно обращаемся с объемными задачами на дом, ровно потому, что понимаем что хорошие разработчики обычно более-менее заняты.
Могу вам посочувствовать, и предложить мне мне anatolix@yandex[-team].ru заслать вашу реализацию про поиск 48-битных простых чисел, на которую вам не ответили, если хорошо написано мы вам ее зачтем ее в карму на собеседовании.
На самом деле все люди которые учатся в университете, делают задания на coursera.org пишут много вещей которые в реальной жизни не используются. Притом иногда несколько лет подряд. Кажется в том, чтобы поделать это еще пару часов нет ничего страшного.
Нам хочется увидеть что человек умеет писать код, это можно попросить сделать написав маленький кусочек кода. Найти что-то что при этом можно куда-о применить на практике достаточно сложно, плюс еще применить на практике это все равно нельзя если только с кандидатом не подписывать контракт о правах на код.
Но вообще если вам задача конструктивно не нравится, т.е. вы готовы предложить что-то еще, что интересней написать — с удовольствием послушаем — мы открыты к предложениям.
Да считалось бы. Более того это помоему каноническое решение и самое быстрое.
Собственно выше про него было написано: en.wikipedia.org/wiki/Shunting-yard_algorithm
Его ограничение то, что нужно знать про обратную польскую нотацию, соответственно оно не обладает свойством что его может написать любой кто умеет программировать. Но как я говорил, если знаешь теорию то становится проще.
с возвратом конечно, там есть peek это на самом деле то же самое, что вытащить элемент и его вернуть потом.
На самом деле когда я это писал меня интересовало примерно следующее, только что придумана задача на сколько программист который не знает теорию компиляторов сможет это решить и сколько это времени займет. Выяснилось, что вроде решаемо.
Я в статье перечислил правильные способы это сделать, но сам не сделал т.к. для меня это означало бы сначала почитать теорию.
Где это, std::auto_ptr это очень даже стандартный тип, плюс по-моему это почти единственный способ их функции что-то вернуть по указателю а не значением, и не уточнять кто теперь главный за освобождение этого указателя.
Можно сравнить чем голый указатель опасен, или shared_ptr опасен.
Такие задачи мы тоже даем. В основном устно.
Ну вот я менеджер использовавший auto_ptr, скажите мне «ая-яй-яй», за что кстати?
На само деле в больших проектах прицепление библиотек — по талонам. В смысле большая часть таго что вроде как есть работающее на самом деле на наших данных ломается, есть некоторое количество проверенных.
> веб-сервер на С++, способный решить предыдущую задачу
а чем не подойдет консольную программу в init.d вписать добавив заголовок? web сервер на C++ чтобы написать это более менее объемное решение, в простом варианте сравнимое с самой задачей. Т.е. можно но это эффективно увелдичение времени на разработку в 2 раза.
Ну вот у меня есть мнение что через 5 лет исследовательскими задачами будут заниматься люди которые сейчас только, что закончили вуз и возможно пишут генераторы json-а и задачки по machine learning на coursera.org
Тезисы ответа на него такие:
1) Мы технологическая компания. (Под этим имеется ввиду, что вот макдональдс не технологическая компания, может у них есть программисты которые занимаются внутренними системами, но на бизнес компании они не влияют. У нас если программист сделал алгоритм ранжирования лучше чем у гугла или ускорил программу работающую на 20000 серверах на 10% это на бизнесе уже очень конкретно отражается)
2) К сожалению все простые способы технологически повлиять на бизнес компании уже сделаны, остались сложные. Для их реализации нужны очень умные люди. Да этих людей нужно не много, но сейчас их у всех компаний сильно меньше, чем надо.
3) Нанять этих людей почти нельзя, но их можно вырастить, люди которые сейчас руководят разработкой ранжирования пришли 8-10 лет назад студентами, и наверное в своей карьере писали json-о подобное что-то.
4) Так вот, чтобы у тебя через 5-10 лет были люди которые двигают бизнес компании вперед надо прямо сейчас нанимать людей у которых их потолок сильно выше написания json файлов. Даже если сейчас нужно в том числе и json делать.
5) Да часть из этих людей свой потолок не реализуют, по разным причинам(в сильной мере от них зависящих) и останутся недовольны, зато другая часть будет делать реально клевые штуки.
6) Если же нанять людей которые ничего кроме генерации json-а делать не смогут, то тягаться с ребятами типа Гугла будет достаточно грустно.
Я ответил на ваш вопрос?
Что касается нас, то у нас специфика в том, что мы хоть и интернет компания, у нас почти нет web разработчиков в нормльном понимании. Т.е. человек будет решать практические проблем уже в некоем стандартном окружении и поднимать web сервис самому ему наврядли пригодится. А вот уметь разбираться в алгоритмах средней сложности — вполне.
Если вы можете написать синтаксический парсер, зачем работать над кодом который написали люди которые не могут?
p.s. Глобально вы конечно правы. Для хорошего программиста знание языка программирования ничто. Проблема в том что есть много людей которые за много лет вообще ни одного языка не освоили хорошо, и чтобы их отсечь про язык надо таки спрашивать.
Ход мыслей imho очень правильный, хотите к нам в Яндекс?
Могу вам посочувствовать, и предложить мне мне anatolix@yandex[-team].ru заслать вашу реализацию про поиск 48-битных простых чисел, на которую вам не ответили, если хорошо написано мы вам ее зачтем ее в карму на собеседовании.
Нам хочется увидеть что человек умеет писать код, это можно попросить сделать написав маленький кусочек кода. Найти что-то что при этом можно куда-о применить на практике достаточно сложно, плюс еще применить на практике это все равно нельзя если только с кандидатом не подписывать контракт о правах на код.
Но вообще если вам задача конструктивно не нравится, т.е. вы готовы предложить что-то еще, что интересней написать — с удовольствием послушаем — мы открыты к предложениям.
Собственно выше про него было написано: en.wikipedia.org/wiki/Shunting-yard_algorithm
Его ограничение то, что нужно знать про обратную польскую нотацию, соответственно оно не обладает свойством что его может написать любой кто умеет программировать. Но как я говорил, если знаешь теорию то становится проще.
А что вы предлагаете написать, чтобы показать способность решать практические задачи?