О преподавании Computer Science
Jul. 13th, 2010 06:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kaipaЯ несколько раз сетовал о проблемах в преподавании математики (см. Плач математика или And then he became Enlightened). На днях ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
fregimus обратил мое внимание на статью о преподавании Computer Science (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html), которая вызвала у меня ответную реакцию.
Суть статьи в том, что в университетах традиционные способы преподавания программирования, основанные на классических учебных языках, заменяются на преподавание на простых распространенных языках, например, Java. С одной стороны, составителей университетских программ можно понять, Java язык достаточно простой, но функционально оснащенный, да и еще пригодится, наверняка, в будущей работе. Но с другой, на Java нельзя или неудобно объяснить и научить таким базовым вещам, как работа с указателями, рекурсии и т.д. А без понимания основ, образование неполно. Автор утверждает, что хороший программист, знающий, скажем, C/C++ и LISP, куда более ценен, и сможет за пару дней освоить Java, чем "программист", которого научили Java и все. И я его понимаю.
На мой взгляд, Java (С#, PHP) -- это лишь распространенный инструмент. Этакий современный Фортран, для которого написано большое количество библиотек. И как инструмент -- вполне оправдывает себя. Однако, инструмент от знания предмета отличается очень существенно. Любой инструмент, он, во-первых, не совершенен, во-вторых, ограничен. Но беда в том, что многие программисты, находясь внутри инструмента, не понимают этих отличий. Молотком можно отлично забивать гвозди, но нельзя закрутить шуруп. Забить, можно, но это вряд ли оптимальный способ.
Фундаментальное образование, будь-то Computer Science или другая наука, дает именно знание, на основании которого можно выбрать тот или иной инструмент. LISP или Schema учат думать рекурсиями и функциями, и писать компактные программы минимумом выразительных средств. Функции высоких порядков -- это мощнейший инструмент, который отсутствует или неудобен в не-функциональных языках. С/C++, а лучше даже рафинированный Pascal, -- прекрасный инструмент для работы с классическими структурами данных: списками, деревьями и т.п. И не важно, что эти структуры и операции над ними входят в современные библиотеки. Всегда может найтись задача, когда придется придумать что-то свое, и надо знать, как это делается. Forth -- уникальный язык для глубокого понимания, что такое стек, без необходимости опускаться до ассемблера. Smalltalk -- идеальный язык для того, чтобы почувствовать ООП (чуть хуже -- С++). На классическом С, удобно изучать механизмы IPC, благо на нем они в Юниксе изначально реализованы. И т.д. Чем больше кругозор, тем лучше программист сможет решить ту или иную задачу. Важен не сам язык, а умение применить правильный инструмент и правильную методологию для конкретной задачи. И понимать, почему она правильная, и как это работает.
Вообще, отсутствие функционального программирования в программе Computer Science сродни отсутствию логики или геометрии в школьной программе. Именно функциональная парадигма учит думать строго, концентрироваться на сути, а не коде.
Другая беда, которую я часто наблюдаю в последнее время, -- это непонимание элементарных вещей, влияющих на быстродействие программ. Быстрый рост вычислительной мощности компьютеров в последние 20 лет привел к тому, что программисты просто разучились писать быстрые и короткие программы. Нередки проекты, в которых делают "все правильно", используют всякие разные универсальные паттерны и замечательные библиотеки, но при запуске оказывается, что программа еле-еле работает на реальной нагрузке. Стеки библиотек и языков высокого уровня прячут от программиста то, что на самом деле происходит в недрах процессора, операционной системы или СУБД, и провоцируют неоптимальный код. Не понимая основ, программисты часто просто не задаются вопросом, а почему это медленно, и как сделать быстрее и лучше. Это выходит за рамки применимости их инструмента.
Радует то, что в последнее время как раз вырос интерес и к функциональным языкам (Haskell, Scala), и к высокопроизводительным масштабируемым системам (многие проекты в NoSQL движении, язык Erlang). Индустрия переживает некоторый ренессанс. Надеюсь, образовательная система заметит этот тренд и вернется к основам. Как говорили наши бабушки -- поживем-увидим.
fregimus обратил мое внимание на статью о преподавании Computer Science (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html), которая вызвала у меня ответную реакцию. Суть статьи в том, что в университетах традиционные способы преподавания программирования, основанные на классических учебных языках, заменяются на преподавание на простых распространенных языках, например, Java. С одной стороны, составителей университетских программ можно понять, Java язык достаточно простой, но функционально оснащенный, да и еще пригодится, наверняка, в будущей работе. Но с другой, на Java нельзя или неудобно объяснить и научить таким базовым вещам, как работа с указателями, рекурсии и т.д. А без понимания основ, образование неполно. Автор утверждает, что хороший программист, знающий, скажем, C/C++ и LISP, куда более ценен, и сможет за пару дней освоить Java, чем "программист", которого научили Java и все. И я его понимаю.
На мой взгляд, Java (С#, PHP) -- это лишь распространенный инструмент. Этакий современный Фортран, для которого написано большое количество библиотек. И как инструмент -- вполне оправдывает себя. Однако, инструмент от знания предмета отличается очень существенно. Любой инструмент, он, во-первых, не совершенен, во-вторых, ограничен. Но беда в том, что многие программисты, находясь внутри инструмента, не понимают этих отличий. Молотком можно отлично забивать гвозди, но нельзя закрутить шуруп. Забить, можно, но это вряд ли оптимальный способ.
Фундаментальное образование, будь-то Computer Science или другая наука, дает именно знание, на основании которого можно выбрать тот или иной инструмент. LISP или Schema учат думать рекурсиями и функциями, и писать компактные программы минимумом выразительных средств. Функции высоких порядков -- это мощнейший инструмент, который отсутствует или неудобен в не-функциональных языках. С/C++, а лучше даже рафинированный Pascal, -- прекрасный инструмент для работы с классическими структурами данных: списками, деревьями и т.п. И не важно, что эти структуры и операции над ними входят в современные библиотеки. Всегда может найтись задача, когда придется придумать что-то свое, и надо знать, как это делается. Forth -- уникальный язык для глубокого понимания, что такое стек, без необходимости опускаться до ассемблера. Smalltalk -- идеальный язык для того, чтобы почувствовать ООП (чуть хуже -- С++). На классическом С, удобно изучать механизмы IPC, благо на нем они в Юниксе изначально реализованы. И т.д. Чем больше кругозор, тем лучше программист сможет решить ту или иную задачу. Важен не сам язык, а умение применить правильный инструмент и правильную методологию для конкретной задачи. И понимать, почему она правильная, и как это работает.
Вообще, отсутствие функционального программирования в программе Computer Science сродни отсутствию логики или геометрии в школьной программе. Именно функциональная парадигма учит думать строго, концентрироваться на сути, а не коде.
Другая беда, которую я часто наблюдаю в последнее время, -- это непонимание элементарных вещей, влияющих на быстродействие программ. Быстрый рост вычислительной мощности компьютеров в последние 20 лет привел к тому, что программисты просто разучились писать быстрые и короткие программы. Нередки проекты, в которых делают "все правильно", используют всякие разные универсальные паттерны и замечательные библиотеки, но при запуске оказывается, что программа еле-еле работает на реальной нагрузке. Стеки библиотек и языков высокого уровня прячут от программиста то, что на самом деле происходит в недрах процессора, операционной системы или СУБД, и провоцируют неоптимальный код. Не понимая основ, программисты часто просто не задаются вопросом, а почему это медленно, и как сделать быстрее и лучше. Это выходит за рамки применимости их инструмента.
Радует то, что в последнее время как раз вырос интерес и к функциональным языкам (Haskell, Scala), и к высокопроизводительным масштабируемым системам (многие проекты в NoSQL движении, язык Erlang). Индустрия переживает некоторый ренессанс. Надеюсь, образовательная система заметит этот тренд и вернется к основам. Как говорили наши бабушки -- поживем-увидим.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-07-13 05:45 pm (UTC)Программа была написана _ужасно_ неэффективна. Много лишних копирований, выделений памяти и т.п. Сначала я начал мучительно переписывать, не помогло. Потом я заметил, что используемый алгоритм -- квадратичный, и заменил его на линейный (ну, почти). А первоначальные изменения откатил чтобы не тестировать заново кучу кода. На больших объёмах скорость увеличилась в 50 раз. Можно сделать ещё раз в шесть, если подумать и превратить почти линейный в строго линейный. Но видимо уже не надо.
И только после этого имеет смысл оптимизировать на более низком уровне.
no subject
Date: 2010-07-13 09:18 pm (UTC)no subject
Date: 2012-09-07 09:48 pm (UTC)no subject
Date: 2012-09-08 08:50 pm (UTC)