Здравствуйте, turbocode, Вы писали:
T>Только как так получается что такие не могут даже class спроектировать, не говоря уже о либах и более сложных вещах.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Kesular, Вы писали:
K>>Возможно. Но сам озвученный в том сообщении подход — крайне нездоровый.
S>Тут Вам некий аноним простыню написал и попросил, чтобы я опублиоквал. С содержимым я более-менее согласен, поэтому публикую.
S>[/q]
Блин, вот программисты вроде — в массе своей умные, образованные люди, а также как и все кидаются в крайности.
Знание всех эзотерических деталей языка/технологии никак не коррелирует с умением решать задачи.
Очень полезный навык, несомненно, но отнюдь не достаточный. Много раз приходилось приводить в порядок код таких эзотериков, как с точки зрения читабельности, так и архитектуры. Код должен быть максимально простой, чтобы его мог читать и понимать джуниор, не владеющий никакой эзотерикой.
Так и наоборот, "умение решать задачи" без определенного уровня владения инструментария — также приводит к хреновому коду в продакшне (тот самый куяк-куяк), уродским велосипедам итп. Так что тут важен баланс.
В зависимости от стоящей задачи — баланс может сдвигаться в разные стороны. Как раз в тот же JetBrains может и нужны знатоки деталей, ибо сам инструментарий и является предметной олбластью. А при написании софта для DSP, например, знатие тонкостей языков определенно вторично, по сравнению с бэкграундом в обработке сигналов. Итд итп.
Здравствуйте, Faland, Вы писали:
F>В зависимости от стоящей задачи — баланс может сдвигаться в разные стороны. Как раз в тот же JetBrains может и нужны знатоки деталей, ибо сам инструментарий и является предметной олбластью. А при написании софта для DSP, например, знатие тонкостей языков определенно вторично, по сравнению с бэкграундом в обработке сигналов. Итд итп.
Я не специалист в DSP, только учусь Но, кмк, пример не очень удачный, ибо там требуется делать все быстро и эффективно, т.е. надо понимать
что,куда и как будет копироваться(желательно только один раз), всяческие побитовые низкоуровневые трюки и т.д.
Выхлоп компилятора для embedded очень даже понимать надо. Понять его можно, когда понимаешь что пишешь на ЯВУ.
Теория компиляторов тут вероятно ни к чему, но знакомство с компилятором С или С++ крайне желательно, на мой взгляд.
У вас некорректные логические посылы и заключения.
Умение спроектировать конкретный класс на самом деле никак не связано с отсутствием у вас знаний эзотерических деталей. Более того знание эзотерических деталей несомненно является полезным знанием, которое способствует правильному проектированию класса. Например, знание того, как работают конструкторы и операторы перемещения в C++ поможет вам создать более универсальный и гибкий класс.
То есть само знание эзотерических деталей никак не противоречит умению проектировать класс. А, вот, отсутствие таких знаний часто является причиной неправильного проектирования классов.
За доказательствами далеко ходить не надо. Просто загляните на любой форум программистов, как, например, Stackoverflow, и посмотрите вопросы начинающих программистов. Именно отсутствие у них знаний об эзотерических деталях является причиной возникновения у них вопросов и обычно совершенно некорректных программ, представленных в их вопросах.
Приведу банальный, но наглядный один из сотен тысяч подобных вопросов на Stackoverflow от начинающего программиста, заданного совсем недавно.
Вопрос озаглавлен как "why printf with %d specifier giving wrong result?"
Этот начинающий программист не знает одной из "эзотерических деталей", что если спецификатор преобразования не соответствует типу соответствующего аргумента, то функция scanf имеет неопределенное поведение.
Это неопределенное поведение к счастью сразу же обнаружилось в программе начинающего программиста, так как компилятор разместил объект с именем num после объекта с именем ch. Поэтому когда данные записывались вызовом функции scanf в объект ch, то тем самым произошло обращение за пределы этого объекта в виду несоответствия спецификатора преобразования и произошло неявное обращение к объекту num, данные которого были затерты.
Однако стандарт языка C не определяет, в какой последовательности компилятор размещает локальные переменные. Поэтому если компилятор поместит объект num перед объектом ch, то программа может выдать корректный результат.
То есть те, кто не знает эзотерических деталей, но "может решать любую задачу", может написать программу с неопределенным поведением, которая даже пройдет все подготовленные для нее тесты, но в один прекрасный день в самый критический момент для клиента может либо аварийно завершиться, либо выдать неверный результат, который порой очень сложно обнаружить.
То есть "умение решать любую сложную задачу" как раз противоречит отсутствию у программиста эзотерических знаний о деталях. Так как получение эзотерических знаний о деталях как раз и является одной из главных и сложных задач, которую программист постоянно решает на протяжении своей карьеры.
PS Анониму: так бывает, что дискуссии на rsdn разрастаются Регистрация не отнимет много времени
Здравствуйте, Sharov, Вы писали:
S>Я не специалист в DSP, только учусь Но, кмк, пример не очень удачный, ибо там требуется делать все быстро и эффективно, т.е. надо понимать S>что,куда и как будет копироваться(желательно только один раз), всяческие побитовые низкоуровневые трюки и т.д. S>Выхлоп компилятора для embedded очень даже понимать надо. Понять его можно, когда понимаешь что пишешь на ЯВУ. S>Теория компиляторов тут вероятно ни к чему, но знакомство с компилятором С или С++ крайне желательно, на мой взгляд.
Так я и говорю — нормальный, хороший уровень С/C++ — конечно необходим, тонкости типа SFINAE — нафиг не нужны. Если идет работа в команде — то можно соблюдать баланс на уровне команды, у кого-то больше уклон в предметную область (DSP), у другого — в инструментарий. Сейчас работаю с такими смешанными командами — очень эффективно народ подтягивает друг друга со временем, через code review итп.
Да и вообще, суть не в конкретном примере, а в том что всегда надо ориентироваться в первую очередь на то какая задача стоит.
Во всяких Pilot Engineering отделах задача вообще может быть — набросать по быстрому прототип для заказчика, тут даже мастера куяк-куяка пригодятся. В других местах — может быть динамически изменяемый зоопарк технологий, и в деталях знать все никто не сможет — нужен человек который может быстро осваивать новые технологии в некотором объеме.
А причем тут пенсионные фонды? Думаете РеактивныеМозги — стартап? Мне кажется давно и хорошо прибыльная компания (впрочем инфой не владею). Еще мне кажется, что они сами (владельцы и тп) стали уже инвестировать в разные новые проекты. JetBrains-таки походу пример очень хорошего и успешного продуктового бизнеса. Жаль что на наших просторах таких продуктов рождается мало (правда и они вроде не российские уже).
Мой коммент был об опыте одного конкретного коллеги на одном конкретном проекте. И причем он (мой коллега) не говрил что плохо. А говрил что обычно, что отличалось от его ожиданий от данной позиции и от тех конкретных людей как профессионалов, с которыми он работал. Вполне возможно, были завышенные ожидания.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Faland, Вы писали:
S>Я не специалист в DSP, только учусь Но, кмк, пример не очень удачный, ибо там требуется делать все быстро и эффективно, т.е. надо понимать S>что,куда и как будет копироваться(желательно только один раз), всяческие побитовые низкоуровневые трюки и т.д. S>Выхлоп компилятора для embedded очень даже понимать надо. Понять его можно, когда понимаешь что пишешь на ЯВУ.
Да, я имел в виду Digital Signal Processing в целом (а не только Processor), сюда же входит написание десктопного софта для обработки сигналов — там Embedded совсем не нужен.
S>Сказать, что "написал кучу крупнейших проектов", будет очевидной ложью, так как один человек не в состоянии даже один крупный проект написать.
Если посмотреть на boost, то у большинства больших либ один автор.
Написать законченную программу для энд-юзера одному и правда не очень под силу. Просто невозможно быть одновременно и гуру предметной области, и низкоуровневым программистом, и дизайнером, и специалистом по юзабилити.
А вот большие проекты, не выходящие за рамки предметной области — очень даже.
Здравствуйте, Faland, Вы писали:
F>Здравствуйте, Sharov, Вы писали:
S>>Здравствуйте, Faland, Вы писали:
S>>Я не специалист в DSP, только учусь Но, кмк, пример не очень удачный, ибо там требуется делать все быстро и эффективно, т.е. надо понимать S>>что,куда и как будет копироваться(желательно только один раз), всяческие побитовые низкоуровневые трюки и т.д. S>>Выхлоп компилятора для embedded очень даже понимать надо. Понять его можно, когда понимаешь что пишешь на ЯВУ.
F>Да, я имел в виду Digital Signal Processing в целом (а не только Processor), сюда же входит написание десктопного софта для обработки сигналов — там Embedded совсем не нужен.
Я понял, но для десктопа особо парится не надо -- батарейки и проц. там вполне ок. А вот DSP в embedded, которого оченно не мало, уже к этому чувствителен.
Кодом людям нужно помогать!
Re[7]: Подскажите как сейчас принято искать работу
Здравствуйте, Sharov, Вы писали:
S>Сказать, что "написал кучу крупнейших проектов", будет очевидной ложью, так как один человек не в состоянии даже один крупный проект написать.
Я написал совсем другое слово:
и написали кучу крутейших проектов
Обращаю внимание, что о размере проекта здесь нет ни слова.
S>А, вот, "знание всех эзотерические деталей спецификации назубок" говорит многое о человеке, как о специалисте.
Похоже, что оно совершенно не говорит о наличии элементарной внимательности.
S>Знание эзотерических деталей говорит о человеке, что он — профессионал
Оно говорит о том, что человек — зануда, который тратит свое время на эзотерические детали вместо решения непосредственной задачи. А при решении непосредственной задачи может легко оказаться, например, что в реализации использованных библиотек — баг, а спецификацией в этом случае можно только подтереться.
Re[9]: Подскажите как сейчас принято искать работу
Здравствуйте, StatujaLeha, Вы писали:
SL>Вопрос озаглавлен как "why printf with %d specifier giving wrong result?"
Понимание того, как работает преобразование приведение типов — это элементарщина, а не "эзотерические знания". Никакое глубокое знание спецификации для этого не требуется.
Здравствуйте, Faland, Вы писали:
F>Блин, вот программисты вроде — в массе своей умные, образованные люди, а также как и все кидаются в крайности. F>Знание всех эзотерических деталей языка/технологии никак не коррелирует с умением решать задачи.
Блин, вот программисты вроде — в массе своей умные, образованные люди, а также как и все кидаются в крайности.
Задачи, они разные бывают. И чем крупнее проект, тем разнообразнее задачи.
Здравствуйте, msk78, Вы писали:
M>Да, Акиньшин нафик, думаю, никому не нужен будет M>Голимый теоретик. Знаний, типа, вагон, а работать руками уже не помнит как M>Сядет за задачу и будет полдня тупить, накой он здесь и с чего начать. потом встанет и уйдёт
K>Понимание того, как работает преобразование приведение типов — это элементарщина, а не "эзотерические знания". Никакое глубокое знание спецификации для этого не требуется.
Антон, не могли бы вы опубликовать мой ответ @Kesular на его сообщение "Re[9]: Подскажите как сейчас принято искать работу "
--------------------------------------------------------------
Это для человека, который уже это знает, может быть элементарщиной. А для начинающего программиста — это знание эзотерических деталей.
Я вам приведу простой пример для языка C.
Допустим, есть объявления.
unsigned int x = 0;
long int y = 0;
и sizeof( unsigned int ) равен sizeof( long int ). Спращиается: какой тип будет иметь выражение x + Y?
Задайте этот вопрос себе, если вы имеете дело с языками C или C++, или своим знакомым программистам, и я уверен, что немало из них будет иметь трудности, чтобы правильно назвать тип выражения.
Чего вы не понимаете, это то, что это касается не только начинающих программистов. Это касается программистов на всех уровнях квалификации. То есть то, что для вас может быть эзотерической деталью. для более квалифицированного программиста это может быть элементарщиной.
А чтобы это было элементарщиной, требуется как раз постоянно осваивать эти эзотерические детали, то есть повышать свою квалификацию.
Здравствуйте, turbocode, Вы писали:
T>>>А что профайлеры уже отменили? S>>Далеко не все из них бесплатны. Легкая в использовании тулза -- написал прототип, проверил как работает.
T>Даже в голову не приходило такую либу искать, потому что каждый прогер должен знать о PerformanceCounter.
Ну так это тоже самое по сути, без них никуда. Только инструментирование и обратная связь быстрее чем валандатся с perf. counter'ами.
Здравствуйте, turbocode, Вы писали:
T>А что профайлеры уже отменили?
В твоем сообщении выше было утверждение, что либу он не спроектирует.
По факту же вот она, либа Он, конечно, не один ей занимается, но по коммитам один из самых активных.
Да и при чем тут профайлеры?
Человек взял и запилил либу.
Своего пользователя, как я понимаю, она нашла.
А профайлеры живут своей жизнью
Но, кмк, пример не очень удачный, ибо там требуется делать все быстро и эффективно, т.е. надо понимать 
Регистрация не отнимет много времени 
