Походу, сказав "А", нужно сказать и "Б". Правда, из-за того, что уже давно никаким боком не связан с системой образования, не берусь судить, насколько изложенные ниже мысли соответствуют современным реалиям.
У высшего образования, выстроенного в СССР, не было задачи выпускать из ВУЗов готовых специалистов, способных сразу же начать полноценно работать. Задачей ВУЗа было "научить человека учиться" плюс заложить в голову студента некий фундамент. Реальные профессиональные навыки и умения, выпускник, официально называвшийся молодым специалистом, приобретал уже на рабочем месте.
Надеюсь, что за прошедшие после краха СССР годы система образования еще не успела полностью перестроится на новый лад и подобный подход, т.е. "научить человека учиться", пока еще остается главенствующим.
Посему, ВУЗ должен периодически "разрывать шаблоны" в сознании студента при одновременной закладке в это самое сознание неких краеугольных камней для формирования будущего фундамента. И то, что при этом студенту будет сложно, что он чего-то не будет понимать, что в чем-то придется долго разбираться -- это нормально.
Это означает, что студента во время обучения нельзя натаскивать на что-то одно. Мол, если студенту после ВУЗа придется работать на Java с вероятностью в 80%, то давайте преподавать только Java. Нет, нужно знакомить студента с разными вещами, пусть даже ничего из этого ему не потребуется. Ведь дело не в конкретной информации, которая остается в голове выпускника ВУЗа, а в умении информацию получать и использовать.
Поэтому я думаю, что рекомендации "дайте студенту ООП на Python-е, или SmallTalk, или Ruby" -- это плохо. Если уж давать студентам представление об ООП, то не скрывая от студентов многообразия этого самого ООП: классовое ООП в динамически-типизированных языках SmallTalk/Ruby/Python, прототипное ООП в динамически-типизированных языках Self/JavaScript, ООП в статически типизированных языках вроде Eiffel/Java/C#, ООП в гибридных языках вроде C++/OCaml/Scala и т.д. и т.п. Пусть после этого студент не будет ООП гуру и не сможет писать софт ни на одном из этих языков. Главное не в этом, а в том, чтобы он осознал сложность и многообразность существующих вариантов.
Кроме того, выдавая рекомендации чему и как учить в ВУЗах, нужно отдавать себе отчет о ряде факторов, специфических для системы образования именно как системы.
Учебные программы не могут меняться быстро. Каждый учебный курс должен быть подготовлен и утвержден. Занятия должны вестись в соответствии с утвержденным планом. Поэтому преподаватель, который ведет сразу несколько курсов, не может кардинально менять их каждый год -- слишком уж это накладно для него.
Тем более, что благосостояние преподавателя не зависит напрямую от того, насколько передовые технологии он освещает в своих курсах. Зарплата преподавателя зависит от других вещей -- от учебной нагрузки в первую очередь, но так же и от показателей успеваемости студентов, от ученой степени, от исследований и договоров, в выполнении которых он участвует, репетиторстве и т.д. Актуальность учебных курсов и степень их соответствия современным реалиям в этом всем весьма вторична и опосредована. Как раз потому, что образование -- это система, жизнь в которой происходит по своим законам.
Кроме того, у ВУЗов и у ВУЗовских кафедр есть специализации. В соответствии с которыми в учебных программах появляются те или иные предметы. Соответственно, у кафедры вычислительной математики может быть свой взгляд на то, чему и как учить студентов, у кафедры промышленной автоматизации бывшего отраслевого института -- свой, а у кафедры информатики какого-нибудь гуманитарного ВУЗа, открывшего эту кафедру на волне массового спроса на программистов, -- свой собственный. Поэтому в одном ВУЗе на одной кафедре преподавание студентам первого курса C++ может быть так же нормально и оправдано, как и преподавание PHP в другом ВУЗе на другой кафедре.
Кроме того, не смотря на то, что ВУЗовские курсы, в большинстве своем не могут ориентироваться на самые передовые технологии, не могут они быть и слишком далеки от мейнстрима. Можно сожалеть, что в ВУЗах мало используют Scheme, Forth и Eiffel, но лучше было бы взглянуть на это дело прагматичнее: для большинства выпускников знание этих языков будут совсем уж бесполезными знаниями. Добавим сюда и то, что изучать языки/технологии, по которым больше информации и доступных ресурсов, все-таки проще, чем изучать какую-то маргинальщину. Преподавать, кстати, тоже проще. Ну и не будем забывать, что часть преподавателей в той или иной форме подрабатывают программированием, используя, скорее всего, что-нибудь из Visual Basic, Java или C++, а не SmallTalk, Scheme или OCaml.
Еще один важный фактор -- это послезнание. Мнения о том, чему и как нужно учить в ВУЗах, высказывают более-менее сложившиеся разработчики, смотрящие на это дело с высоты уже имеющихся у них структурированных знаний и некоторого практического профессионального опыта. И как раз то, что они уже знают и мешает им адекватно смотреть на проблему обучения людей, не обладающих этими знаниями.
Ну и еще одно. Преподаватели очень разные. Преподаватель, который является хорошим программистом, имеет большой практический опыт за плечами, умеет объяснять и создает творческую атмосферу, подозреваю, является большой редкостью. И тут большой вопрос, что лучше: хорошо преподавать что-нибудь из древнего, "не нужного", вроде C++ или Pascal, или плохо, но "актуальное", вроде Scala или Haskell-я.
Касательно же преподавания конкретно ООП в ВУЗе, то лично у меня такое мнение: это очень неоднозначная идея. Как по мне, так лучше учить конкретным языкам, в которых можно сначала вообще обходиться без ООП. А уже затем, по мере увеличения объема и сложности программ, которые нужно писать студентам, переходить к ООП, но опять же, в рамках одного-двух языков (но желательно сильно разных). И лишь затем, в рамках какого-то спецкурса можно подойти к ООП более серьезно, осветив все его многообразие.
Но это моя личная точка зрения, не проверенная на практике.
Комментариев нет:
Отправить комментарий