Однако в наше время в большинстве стран мира укоренилась армейская дисциплина, когда нижестоящий начальник просит разрешения присутствующего вышестоящего обратиться к третьему лицу, а не наоборот — вышестоящему не требуется просить разрешения. Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
Зав.отделом устраивает обсуждение текущего хода проекта. Все собрались, и рядовой программист докладывает: «для решения данной подзадачи литературный сетевой поиск выявил подходы А, Б, В. Мы использовали А». Зав.отделом: «почему не Б? Выглядит гораздо привлекательнее.» Рядовой, кивает на непосредственного начальника: «Иван Иваныч так сказал...» Иван Иваныч: «ну, в прошлом и позапрошлом проекте этот подход себя зарекомендовал...» Зав.отделом, рядовому: «У меня личная просьба, попробуйте Б и завтра лично мне доложите».
Зав.отделом не прав?
Сложный вопрос. Исторически вассалитет устарел. Странно будет, если в рамках одной современной фирмы или учреждения директор не будет иметь прав говорить с рядовыми сотрудниками. Как еще он сможет выявить негодных руководителей среднего звена?
Думаю, что родители могут только подготовить к столкновениям в реальном мире. А столкновения происходят в школе, в ВУЗе, на работе. Пока человек сам не набьет шишек — ему не понять чужих советов.
Может быть, не всем так повезло, как Вам? И м.б. Вы еще не знаете, что может пригодиться в будущем. Кроме того, есть еще косвенные факторы. Допустим, какой-то студент делал диплом по решению систем диффуров, а на работе занимается СУБД, и эти диффуры кажутся ему зря потраченным временем. Но он не осознает, что на них он научился хорошо программировать. Может быть и так, что по диффурам был отличный препод, а по БД посредственный.
Я не защищаю мусор. Я о другом: науку кто только не использует, но все норовят за бесплатно. Чем богаче компания — тем меньше ей хочется платить. А еще во всем мире наживаются даже на научных публикациях: за статью в переводном журнале РАН пара соавторов получит около $80US каждый, а на сайте издателя будут брать по $40US за каждую электронную (!) копию. Конечно, многие проблемы специфичны для нас, но есть проблемы всего мира, а мы думаем, что это чисто наши проблемы. Такова упомянутая Вами проблема сотрудничества науки с бизнесом.
Что касается мусора, то на мой взгляд, в темах, за которыми слежу, его, к сожалению, и в солидных международных журналах хватает. То, что в наших мусора сильно больше, меня не утешает. Интересно, что сталкивался и с другой крайней точкой зрения — некоторые западные коллеги всерьез утверждали, что все наши публикации — мусор. Не поверил бы, если бы сам не услышал.
Примером небезпроблемной жизни западных университетских профессоров может служить Питер Грогоно (Peter Grogono). Несколько лет назад его признали одним из лучших преподавателей Канады. Предложенный им ОО язык программирования Dee появился раньше Явы и мог бы составить серьезную конкуренцию. Но на этот язык у корпораций не нашлось денег… Нашим читателям Грогоно знаком по книге Программирование на языке Паскаль, М.: Мир, 1982. Фактически это был первый учебник по Паскалю на русском — изданное незадолго до того сообщение Вирта все же не было подробным учебником.
По моим многолетним наблюдениям, такого сотрудничества науки с бизнесом, какого хотелось бы науке, нет нигде в мире. Во многом это миф о сотрудничестве. Конечно, лидирующие компании очень заинтересованы в научных достижениях, но, как и везде, пытаются сэкономить. На это можно возразить множеством примеров, на что найдется не меньше контр-примеров, особенно из сфер фундаментальных наук.
В советские времена в той же Бауманке преподавателям очень неплохо платили. Всем, конечно, по-разному, но в лекторы престижных учебных заведений рвались даже академики. Сам наблюдал, как в одном ведущем НИИ АН СССР очень успешный академик (успешный даже среди академиков), стоящий во главе одной из лучших лабораторий этого НИИ, пытался получить по совместительству лектора на одном из факультетов МГУ. Не пустили — своим мало. Это было проблемой: признанных ученых далеко не всегда пускали преподавать. А очень многие рвались. То, что сейчас не рвутся — катастрофично.
есть разница между «иметь представление о теории» и «знать теорию»?
Полностью знать теорию невозможно. Жизни не хватит, чтобы изучить все направления, и суток не хватит, чтобы уследить за всем новым, что ежедневно публикуется по всем направлениям. Специалисты прилично знают и следят за темами, над которыми работают, и пытаются иметь представление о других темах по остаточному принципу. ВУЗ не должен делать каждого студента специалистом по какой-то теме теории графов, а должен всего лишь дать общий обзор наиболее удачных ее методов, типовых задач и подходов к их решению.
Вот олимпиады по программированию меня вообще никак не интересовали, я про работу говорю.
Олимпиады во многом способствуют осознанному выбору школьником будущей специальности. Олимпиады для взрослых способствуют расширению кругозора и росту проф.уровня. Практически любой программист обречен постоянно изучать новые подходы и технологии, если он хочет быть на переднем крае.
… а с тем же успехом можно набрать в гугле «теория графов» в момент, когда она понадобится, разве нет?
Только нужно сообразить, что данная задача (или похожая) решалась методами теории графов. А для того, чтобы это сообразить, нужно иметь некоторое представление о данной теории и ее методах. Кроме того, изучать теорию с нуля может оказаться слишком долго.
Еще есть опасность: в числе прочего гугл может выдать «Граф Монте-Кристо», и неискушенный программист попытается найти решение своей задачи в этом источнике…
Опять-таки, теория графов, она, наверное, большая.
Конечно, большая. Что и сколько из нее нужно школьникам для участия в олимпиадах по программированию, можно судить по книге С.Окулов, Программирование в алгоритмах. ВУЗовские курсы подробнее (я о мировой практике).
Зачем графы в программировании? Или зачем нужна теория сложности? — Да, можно запросто получить ответы, т.к. на эти темы написано много книг. Набираем в гугле «графы в программировании» и получаем множество обоснований. И т.д.
В большинстве случаев так и поступают. Если всё работает на приемлемом уровне — хорошо. Если тормозит — начинают оптимизацию, вспоминают про вычислительную сложность и т.п. Но в большинстве случаев просто возьмут другую функцию сортировки. В общем будут решать проблемы по мере поступления, а не вспоминать про полиномы перед тем как написать алгоритм сортировки каких то данных.
Да, увы. Во многих подобных случаях искусственные тестовые примеры удается решить на удовлетворительном уровне. А столкнувшись с реальность, программа отказывается работать, и начинается перелопачивание большой части кода с выискиванием доморощенных сортировок и прочих «так сойдет». В результате затраты на проект многократно возрастают. Конторам, которые занимаются подобной разработкой, совсем не нужны хорошие программисты, но очень нужны ловкие юристы, которые ухитряются делать такие контракты, что все затраты ложатся на заказчика.
Как минимум, школьные курсы арифметики, алгебры, геометрии. Линейную алгебру, мат. анализ, тервер, аналитическую геометрию, теорию графов, комбинаторику, теорию сложности вычислений. Плюс алгоритмику по перечисленному. Плюс сортировка и поиск. Это неполный список для начинающего программиста-универсала. Но если требуется программист только для систем простейшего бух.учета в конторах с численностью работников несколько десятков человек (такая система может служить примером достаточно простой системы, если ее минимизировать и не усложнять дополнительными опциями), то можно его этому не учить, а ограничиться трех-шестимесячными курсами, на которых напомнить нужные вещи из общеобразовательной школьной программы.
Тривиальный код и простые задачи (в математическом плане) — 90% кода и рутины программиста. Это хорошо видно на открытых исходных кодах крупных проектов.
Многие знания применяются неосознанно. Нпр., знание об экспоненте и полиномах при выборе алгоритма по вычислительной сложности. Если у «кодера» нет подобных знаний, то можно опасаться, что примитивную сортировку он осуществит посредством полного перебора.
мне в программировании пригодились только две теорема Пифагора и теорема синусов
Ага! Значит, работали в действительных числах и учитывали их специфику (ошибки округления и т.д.)
Зав.отделом не прав?
Научные работники, нпр., в сферах математики, физики, CS и т.д. Или здесь речь только о разработках, где таких не требуется?
Заранее спасибо.
Но это безусловно ценное знание, вернее — опыт.
Что касается мусора, то на мой взгляд, в темах, за которыми слежу, его, к сожалению, и в солидных международных журналах хватает. То, что в наших мусора сильно больше, меня не утешает. Интересно, что сталкивался и с другой крайней точкой зрения — некоторые западные коллеги всерьез утверждали, что все наши публикации — мусор. Не поверил бы, если бы сам не услышал.
Примером небезпроблемной жизни западных университетских профессоров может служить Питер Грогоно (Peter Grogono). Несколько лет назад его признали одним из лучших преподавателей Канады. Предложенный им ОО язык программирования Dee появился раньше Явы и мог бы составить серьезную конкуренцию. Но на этот язык у корпораций не нашлось денег… Нашим читателям Грогоно знаком по книге Программирование на языке Паскаль, М.: Мир, 1982. Фактически это был первый учебник по Паскалю на русском — изданное незадолго до того сообщение Вирта все же не было подробным учебником.
Олимпиады во многом способствуют осознанному выбору школьником будущей специальности. Олимпиады для взрослых способствуют расширению кругозора и росту проф.уровня. Практически любой программист обречен постоянно изучать новые подходы и технологии, если он хочет быть на переднем крае.
Еще есть опасность: в числе прочего гугл может выдать «Граф Монте-Кристо», и неискушенный программист попытается найти решение своей задачи в этом источнике…
Конечно, большая. Что и сколько из нее нужно школьникам для участия в олимпиадах по программированию, можно судить по книге С.Окулов, Программирование в алгоритмах. ВУЗовские курсы подробнее (я о мировой практике).
Ага! Значит, работали в действительных числах и учитывали их специфику (ошибки округления и т.д.)