"Язык программирования является низкоуровневым, если он требует внимания к незначимым вещам"
"...
Почему не Java?
Так как в курсах в настоящее время часто применяется Java или C#, следует пояснить, почему мы не следуем такой практике. Язык Java, наряду с языками C#, C++ и C, следует знать, но он не подходит на роль первого языка обучения. Слишком большой багаж знаний требуется накопить, прежде чем студенты смогут думать о своих задачах. Это можно видеть на примере "Hello World" - первой программы на Java:
class First {
public static void main(String args[])
{ System.out.println("Hello World!"); } }
Появляются концепции, каждая из которых мешает обучению. Почему "public", "static", "void"? (Конечно, я могу сделать мою программу общедоступной - public, если вы настаиваете, но как понять, что в результате моих усилий возникнет пустота - void?) Эти ключевые слова не имеют ничего общего с целью моей программы, и студенты начнут понимать их смысл, по меньшей мере, через несколько месяцев, но должны включать их в свои тексты как магические заклинания, чтобы их программы работали. Для преподавателей это означает, что они должны давать некоторые конструкции без понимания их смысла. Как отмечалось ранее, стиль "Вы поймете, когда подрастете" - не лучший из педагогических приемов. Eiffel защищает нас от этого: мы можем объяснить каждую используемую конструкцию языка при первом ее появлении.
ОО-природа языка и его простота играют роль. Есть некоторая ирония в том, что каждая Java-программа, начиная с простейшего примера, как показано выше, использует как главную функцию статическую функцию (static), что нарушает принципы ОО-стиля программирования. Конечно, есть люди, которым не нравится идея использовать ОО-стиль для начального курса. Но уж если вы выбрали работу с объектами, будьте добры быть последовательными. В какой-то момент студенты поймут, что фундаментальная схема - та, которую, как вы говорили, следует использовать, - вовсе не является ОО-схемой. С каким лицом вы будете отвечать на этот неизбежный вопрос?
Синтаксис, как отмечалось, имеет значение. В первом примере на Java студент должен управлять странными скоплениями символов, подобно финальным ""); } }". Они приводят глаз в замешательство, и роль их не очевидна. В этом скоплении точный порядок символов важен, но его трудно объяснить и запомнить. Почему следует ставить точку с запятой между закрывающими скобками - круглой и фигурной? Есть ли пробел после точки с запятой, а если да, то нужен ли он? Вместо того чтобы сконцентрироваться на концепциях программирования, студент должен обнаруживать тривиальные ошибки, приводящие к загадочным для него результатам.
Еще один постоянный источник недоразумений - это использование знака равенства "=" для присваивания, наследованного от языка Фортран через С. Как много студентов, начинающих обучение с Java, удивляются, почему имеет смысл a = a + 1 и, как отмечал Вирт [15], почему a = b не то же самое, что и b = a?
Несогласованности создают трудности. Почему, наряду с полными словами подобно "static", используются аббревиатуры, такие как "args" и "println"? Студенты из первого знакомства с программированием извлекают урок, что согласованность не требуется, что количество нажатий на клавиши может быть важнее ясности имен (в базисной библиотеке Eiffel операция перехода на новую строку называется put_new_line). Если позднее мы введем методологическое правило, требующее от студентов выбирать ясные и согласованные имена, то едва ли они будут воспринимать нас со всей серьезностью. "Делай, как я говорю, а не так, как я делаю" - сомнительный педагогический принцип.
Приведу еще один пример. При описании (глава 17) необходимости механизма, рассматривающего операции как объекты, подобно агентам Eiffel или замыканиям в других языках, мы должны были объяснить, как справляются с этой проблемой в языках типа Java, где такие механизмы отсутствуют. Так как мы использовали итераторы в качестве мотивационного примера, мы были счастливы обнаружить, что на странице Sun, описывающей "внутренние классы" Java, приведен код для проектирования итератора, который можно было бы прекрасно использовать в качестве модели.
Смотри tinyurl.com/c4oprq (архив java.sun. com/docs/books/tuto-rial/java/javaOO/innerclass-es.html, Oct. 2007; теперь страница использует другой пример).
Но тогда он включал следующее объявление:
public StepThrough stepThrough() {
return new StepThrough();
}
Вероятно, я смог бы объяснить его закаленным трудностями программистам. Но нет способа, позволяющего мне объяснить его начинающим студентам, - и я восхищаюсь тем, кто смог бы сделать это. Почему StepTrough появляется три раза? Означает ли это каждый раз одно и то же? Является ли изменение буквенного регистра (StepThrough vs stepThrough) значимым? Вообще, что это все может означать? Очень быстро вводный курс программирования превращается в болезненное толкование языка программирования, оставляя немного времени для настоящих концепций. По словам Алана Перлиса:
"Язык программирования является низкоуровневым, если он требует внимания к незначимым вещам".
Эпиграмма #8, доступная на www-pu.informa-tik.uni-tuebin-gen.de/users/klaeren/epigrams.html. Свой вклад в трудности использования языка Java в начальном курсе вносит та свобода, с которой язык оперирует с ОО-принципами. Например:
если x обозначает объект и a - один из атрибутов соответствующего класса, то по умолчанию разрешается писать x.a = v, чтобы присвоить новое значение полю a объекта. Это нарушает сокрытие информации и другие принципы проектирования. Для управления этим необходимо скрывать атрибут, дополняя его специальными модификаторами. Для преподавателя в такой ситуации возникает выбор: либо заставлять студентов на первых шагах добавлять текст, носящий для них характер шума, либо разрешать на первых порах плохой стиль проектирования, а потом с трудом их переучивать;
Java строго разделяет полностью абстрактные модули, называемые интерфейсами, от полностью реализованных - классов. Одно из преимуществ механизма классов, введенное еще в Simula 67, состоит в существовании полного спектра возможностей между этими двумя полюсами. Эта идея является центральной в обучении ОО-методу, в частности, обучению проектированию. Можно начинать определение некоторого понятия с полностью отложенного (deferred) абстрактного класса, затем вы постепенно уточняете его, используя наследование, приходя к полностью эффективному классу. Классы на промежуточном уровне в этом процессе частично отложены, частично эффективны. Java не позволяет использовать такой подход. Если вам нужно скомбинировать несколько абстракций, все они, за исключением максимум одной, должны быть интерфейсами.
Можно привести еще много примеров подобного влияния языка Java на процесс обучения. Типичную реакцию при переходе на Eiffel выразил один из программистов в своем письме: "Я много писал на С++ и Java и тратил уйму усилий на изучение груза скучной компьютерной чепухи. С Eiffel не замечаешь программирования, и я трачу свое время на размышления о задаче".
Причина, по которой во вводном курсе часто используется С++ и Java, состоит в том, что рынок требует программистов, работающих на этих языках. Это разумный аргумент, но он применим к учебному плану в целом, а не к первому курсу. Программирование на уровне, требуемом современными стандартами, достаточно сложно, а потому следует использовать наилучшие обучающие инструменты. Если бы рынок диктовал требования к обучению, мы бы никогда ранее не использовали Паскаль (многие годы служивший языком начального обучения), не говоря о языке Scheme. Если при обучении следовать тенденциям, существующим в программистском мире, то мы бы проходили периоды Fortran, Cobol, PL/I, Visual Basic, C, и программисты, закончившие обучение, обнаруживали бы, что их знания устарели, при каждом повороте великого колеса моды - через несколько лет. Наша задача - выпускать тех, кто решает задачи и может быстро адаптироваться к эволюциям нашей дисциплины.
Не следует позволять кратковременным требованиям рынка управлять принципами обучения. Скажем так: если вы считаете С++ или Java идеальными обучающими средствами, используйте их. Вероятно, в этом случае данная книга вам совсем не будет по душе. Но если вы согласны с ее подходом, не позволяйте себя запугать высказываниями некоторых студентов или их родителей, что вы исповедуете "академический" подход. Объясните им, что вы используете лучший подход из того, что вы знаете, что тот, кто поймет суть программирования, получит эти навыки на всю жизнь, и что любой неплохой инженер ПО может быстро освоить новый язык за завтраком, даже если он не прошел его в других курсах учебного плана. Что же касается характеристики "академический подход", то сошлитесь на сайт http://eiffel.com, где приведен впечатляющий список критически важных коммерческих приложений, реализованных на Eiffel в различных компаниях, часто в ситуациях, когда их попытки реализации на других языках потерпели неудачу.
Языки Java, C#, C++ и C являются на ближайшие несколько лет багажом инженера ПО, они важны, что и нашло отражение в четырех приложениях к данной книге. Эта цель, однако, никак не связана с теми методиками, которые следует использовать в вводном курсе.
По нашим опросам [13], примерно 50% студентов уже использовали Java или C++ до изучения вводного курса.
В какой-то момент студенты познакомятся с этими языками; в наши дни редкий учебный план не знакомит, по крайней мере, с одним из них. Но, насколько я знаю, ни один из вводных курсов не рассказывает обо всех средствах, так что придется все равно изучать разные языки вне зависимости от начального языка обучения.
Языки программирования и культура программирования, связанная с каждым из них, сами по себе являются интересным объектом изучения. Наша группа в ETH, которая учит вводному курсу на Eiffel, имеет на старших курсах опыт преподавания специальных языков: "В глубины Java", "В глубины C#". Когда вы понимаете концепции программирования, вы готовы к овладению различными языками, изучение Eiffel и его объектной модели помогает вам стать лучшим С++ или Java-программистом.
Я работаю одновременно как в индустрии, так и в академической сфере, и мне ежемесячно приходится читать десятки резюме. Все их обладатели гордятся одними и теми же навыками, включающими опыт работы на С++ и Java. Это уже никого не поражает и не позволяет выделить претендента из толпы ему подобных. Действительным преимуществом может служить знание ОО-подхода и его применения в ПИ, о чем мог бы свидетельствовать учебный план по Eiffel и Проектированию по Контракту. Вполне можно представить учебный план, основанный на С++ и не содержащий настоящего понимания ОО-концепций; с Eiffel это менее вероятно. Компетентные работодатели понимают, что, помимо непосредственных навыков, важна глубина понимания проблем ПО и способность к профессиональной разработке в течение длительного времени. Все усилия, предпринятые в этой книге, и использование Eiffel направлены на эти цели.
Здесь стоит еще раз процитировать Алана Перлиса: "Язык, который не воздействует на способ вашего размышления о программировании, не стоит изучения". Эпиграмма #19..."
Из книги БЕРТРАНА МЕЙЕРА "Почуствуй класс".
Почему не Java?
Так как в курсах в настоящее время часто применяется Java или C#, следует пояснить, почему мы не следуем такой практике. Язык Java, наряду с языками C#, C++ и C, следует знать, но он не подходит на роль первого языка обучения. Слишком большой багаж знаний требуется накопить, прежде чем студенты смогут думать о своих задачах. Это можно видеть на примере "Hello World" - первой программы на Java:
class First {
public static void main(String args[])
{ System.out.println("Hello World!"); } }
Появляются концепции, каждая из которых мешает обучению. Почему "public", "static", "void"? (Конечно, я могу сделать мою программу общедоступной - public, если вы настаиваете, но как понять, что в результате моих усилий возникнет пустота - void?) Эти ключевые слова не имеют ничего общего с целью моей программы, и студенты начнут понимать их смысл, по меньшей мере, через несколько месяцев, но должны включать их в свои тексты как магические заклинания, чтобы их программы работали. Для преподавателей это означает, что они должны давать некоторые конструкции без понимания их смысла. Как отмечалось ранее, стиль "Вы поймете, когда подрастете" - не лучший из педагогических приемов. Eiffel защищает нас от этого: мы можем объяснить каждую используемую конструкцию языка при первом ее появлении.
ОО-природа языка и его простота играют роль. Есть некоторая ирония в том, что каждая Java-программа, начиная с простейшего примера, как показано выше, использует как главную функцию статическую функцию (static), что нарушает принципы ОО-стиля программирования. Конечно, есть люди, которым не нравится идея использовать ОО-стиль для начального курса. Но уж если вы выбрали работу с объектами, будьте добры быть последовательными. В какой-то момент студенты поймут, что фундаментальная схема - та, которую, как вы говорили, следует использовать, - вовсе не является ОО-схемой. С каким лицом вы будете отвечать на этот неизбежный вопрос?
Синтаксис, как отмечалось, имеет значение. В первом примере на Java студент должен управлять странными скоплениями символов, подобно финальным ""); } }". Они приводят глаз в замешательство, и роль их не очевидна. В этом скоплении точный порядок символов важен, но его трудно объяснить и запомнить. Почему следует ставить точку с запятой между закрывающими скобками - круглой и фигурной? Есть ли пробел после точки с запятой, а если да, то нужен ли он? Вместо того чтобы сконцентрироваться на концепциях программирования, студент должен обнаруживать тривиальные ошибки, приводящие к загадочным для него результатам.
Еще один постоянный источник недоразумений - это использование знака равенства "=" для присваивания, наследованного от языка Фортран через С. Как много студентов, начинающих обучение с Java, удивляются, почему имеет смысл a = a + 1 и, как отмечал Вирт [15], почему a = b не то же самое, что и b = a?
Несогласованности создают трудности. Почему, наряду с полными словами подобно "static", используются аббревиатуры, такие как "args" и "println"? Студенты из первого знакомства с программированием извлекают урок, что согласованность не требуется, что количество нажатий на клавиши может быть важнее ясности имен (в базисной библиотеке Eiffel операция перехода на новую строку называется put_new_line). Если позднее мы введем методологическое правило, требующее от студентов выбирать ясные и согласованные имена, то едва ли они будут воспринимать нас со всей серьезностью. "Делай, как я говорю, а не так, как я делаю" - сомнительный педагогический принцип.
Приведу еще один пример. При описании (глава 17) необходимости механизма, рассматривающего операции как объекты, подобно агентам Eiffel или замыканиям в других языках, мы должны были объяснить, как справляются с этой проблемой в языках типа Java, где такие механизмы отсутствуют. Так как мы использовали итераторы в качестве мотивационного примера, мы были счастливы обнаружить, что на странице Sun, описывающей "внутренние классы" Java, приведен код для проектирования итератора, который можно было бы прекрасно использовать в качестве модели.
Смотри tinyurl.com/c4oprq (архив java.sun. com/docs/books/tuto-rial/java/javaOO/innerclass-es.html, Oct. 2007; теперь страница использует другой пример).
Но тогда он включал следующее объявление:
public StepThrough stepThrough() {
return new StepThrough();
}
Вероятно, я смог бы объяснить его закаленным трудностями программистам. Но нет способа, позволяющего мне объяснить его начинающим студентам, - и я восхищаюсь тем, кто смог бы сделать это. Почему StepTrough появляется три раза? Означает ли это каждый раз одно и то же? Является ли изменение буквенного регистра (StepThrough vs stepThrough) значимым? Вообще, что это все может означать? Очень быстро вводный курс программирования превращается в болезненное толкование языка программирования, оставляя немного времени для настоящих концепций. По словам Алана Перлиса:
"Язык программирования является низкоуровневым, если он требует внимания к незначимым вещам".
Эпиграмма #8, доступная на www-pu.informa-tik.uni-tuebin-gen.de/users/klaeren/epigrams.html. Свой вклад в трудности использования языка Java в начальном курсе вносит та свобода, с которой язык оперирует с ОО-принципами. Например:
если x обозначает объект и a - один из атрибутов соответствующего класса, то по умолчанию разрешается писать x.a = v, чтобы присвоить новое значение полю a объекта. Это нарушает сокрытие информации и другие принципы проектирования. Для управления этим необходимо скрывать атрибут, дополняя его специальными модификаторами. Для преподавателя в такой ситуации возникает выбор: либо заставлять студентов на первых шагах добавлять текст, носящий для них характер шума, либо разрешать на первых порах плохой стиль проектирования, а потом с трудом их переучивать;
Java строго разделяет полностью абстрактные модули, называемые интерфейсами, от полностью реализованных - классов. Одно из преимуществ механизма классов, введенное еще в Simula 67, состоит в существовании полного спектра возможностей между этими двумя полюсами. Эта идея является центральной в обучении ОО-методу, в частности, обучению проектированию. Можно начинать определение некоторого понятия с полностью отложенного (deferred) абстрактного класса, затем вы постепенно уточняете его, используя наследование, приходя к полностью эффективному классу. Классы на промежуточном уровне в этом процессе частично отложены, частично эффективны. Java не позволяет использовать такой подход. Если вам нужно скомбинировать несколько абстракций, все они, за исключением максимум одной, должны быть интерфейсами.
Можно привести еще много примеров подобного влияния языка Java на процесс обучения. Типичную реакцию при переходе на Eiffel выразил один из программистов в своем письме: "Я много писал на С++ и Java и тратил уйму усилий на изучение груза скучной компьютерной чепухи. С Eiffel не замечаешь программирования, и я трачу свое время на размышления о задаче".
Причина, по которой во вводном курсе часто используется С++ и Java, состоит в том, что рынок требует программистов, работающих на этих языках. Это разумный аргумент, но он применим к учебному плану в целом, а не к первому курсу. Программирование на уровне, требуемом современными стандартами, достаточно сложно, а потому следует использовать наилучшие обучающие инструменты. Если бы рынок диктовал требования к обучению, мы бы никогда ранее не использовали Паскаль (многие годы служивший языком начального обучения), не говоря о языке Scheme. Если при обучении следовать тенденциям, существующим в программистском мире, то мы бы проходили периоды Fortran, Cobol, PL/I, Visual Basic, C, и программисты, закончившие обучение, обнаруживали бы, что их знания устарели, при каждом повороте великого колеса моды - через несколько лет. Наша задача - выпускать тех, кто решает задачи и может быстро адаптироваться к эволюциям нашей дисциплины.
Не следует позволять кратковременным требованиям рынка управлять принципами обучения. Скажем так: если вы считаете С++ или Java идеальными обучающими средствами, используйте их. Вероятно, в этом случае данная книга вам совсем не будет по душе. Но если вы согласны с ее подходом, не позволяйте себя запугать высказываниями некоторых студентов или их родителей, что вы исповедуете "академический" подход. Объясните им, что вы используете лучший подход из того, что вы знаете, что тот, кто поймет суть программирования, получит эти навыки на всю жизнь, и что любой неплохой инженер ПО может быстро освоить новый язык за завтраком, даже если он не прошел его в других курсах учебного плана. Что же касается характеристики "академический подход", то сошлитесь на сайт http://eiffel.com, где приведен впечатляющий список критически важных коммерческих приложений, реализованных на Eiffel в различных компаниях, часто в ситуациях, когда их попытки реализации на других языках потерпели неудачу.
Языки Java, C#, C++ и C являются на ближайшие несколько лет багажом инженера ПО, они важны, что и нашло отражение в четырех приложениях к данной книге. Эта цель, однако, никак не связана с теми методиками, которые следует использовать в вводном курсе.
По нашим опросам [13], примерно 50% студентов уже использовали Java или C++ до изучения вводного курса.
В какой-то момент студенты познакомятся с этими языками; в наши дни редкий учебный план не знакомит, по крайней мере, с одним из них. Но, насколько я знаю, ни один из вводных курсов не рассказывает обо всех средствах, так что придется все равно изучать разные языки вне зависимости от начального языка обучения.
Языки программирования и культура программирования, связанная с каждым из них, сами по себе являются интересным объектом изучения. Наша группа в ETH, которая учит вводному курсу на Eiffel, имеет на старших курсах опыт преподавания специальных языков: "В глубины Java", "В глубины C#". Когда вы понимаете концепции программирования, вы готовы к овладению различными языками, изучение Eiffel и его объектной модели помогает вам стать лучшим С++ или Java-программистом.
Я работаю одновременно как в индустрии, так и в академической сфере, и мне ежемесячно приходится читать десятки резюме. Все их обладатели гордятся одними и теми же навыками, включающими опыт работы на С++ и Java. Это уже никого не поражает и не позволяет выделить претендента из толпы ему подобных. Действительным преимуществом может служить знание ОО-подхода и его применения в ПИ, о чем мог бы свидетельствовать учебный план по Eiffel и Проектированию по Контракту. Вполне можно представить учебный план, основанный на С++ и не содержащий настоящего понимания ОО-концепций; с Eiffel это менее вероятно. Компетентные работодатели понимают, что, помимо непосредственных навыков, важна глубина понимания проблем ПО и способность к профессиональной разработке в течение длительного времени. Все усилия, предпринятые в этой книге, и использование Eiffel направлены на эти цели.
Здесь стоит еще раз процитировать Алана Перлиса: "Язык, который не воздействует на способ вашего размышления о программировании, не стоит изучения". Эпиграмма #19..."
Из книги БЕРТРАНА МЕЙЕРА "Почуствуй класс".