Введение

Почему не 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

Насколько формально?

Подход "Проектирование по Контракту" позволяет в "мягкой дозе" познакомить студентов с "формальными" методами разработки ПО.

Формальные методы необходимы при разработке ПО. Любой серьезный учебный план должен включать, по крайней мере, один курс, полностью посвященный математическим основам разработки ПО, математическому языку задания спецификаций. Эти идеи должны оказывать влияние на весь учебный план, хотя, как обсуждалось ранее, нежелательно использовать для начинающих полностью формальный подход. Проблема в том, чтобы практические навыки и формальные методы представить как дополняющие друг друга аспекты, тесно связанные и в равной степени обязательные. Подход "Проектирование по Контракту" позволяет решить эту задачу.

Начиная с первых примеров спецификации интерфейсов, методы обладают предусловиями и постусловиями, а классы — инвариантами. Как и должно, эти концепции обсуждаются и вводятся в походящем контексте. Следует отметить, что многие программисты все еще боятся их, и большинство языков программирования не поддерживает контракты как естественный способ рассуждения о программах. Не пугая студентов тяжело воспринимаемыми формальными методами, мы открываем простой способ их введения, который полностью будет оценен по мере приобретения соответствующего опыта программирования.

Введение формализации может хорошо сочетаться с практическим подходом. Например, при изучении циклов они рассматриваются как механизм аппроксимации, вычисляющий решение на расширяющемся подмножестве данных. В этом случае понятие инварианта цикла становится естественным, как ключевое свойство поддержания аппроксимации на каждом шаге цикла.

Эта ставка на практичность отличает "Проектирование по Контракту" от полностью формальных методов, используемых в некоторых вводных курсах, в которых преподаватели исходят из того, что вводный курс по программированию является математическим курсом. Иногда дело доходит до того, что студенты не работают с компьютером в течение семестра или всего учебного года. Есть риск, что вместо желаемого эффекта будет достигнут противоположный результат.

Студенты, в частности, те, кто программировал ранее, осознают, что они могут создавать программы — несовершенные, но работающие — без всякого тяжелого математического аппарата. Если вы скажете им, что это невозможно, то можете просто потерять контакт с ними, и в результате они могут просто отвергать формальные методы как неподходящие, не желая пользоваться как простыми идеями, которые могли бы им помочь непосредственно сейчас, так и более продвинутыми, полезными позже. Лесли Лемпорт (Leslie Lamport), — которого никак нельзя обвинить в недооценке формальных методов, — указывал [6]:

[В американских университетах] математика и инженерия полностью разделены. Я знаю уважаемый американский университет, в котором студенты на первом программистском курсе должны доказывать корректность каждой маленькой программы, которую они пишут. На их втором программистском курсе они все доказательства полностью забывают и просто учатся писать программы на С. Они не пытаются применить то, что они выучили на первом курсе, к написанию реальных программ.

Наш опыт подтверждает это. Студенты первого курса, хорошо воспринимающие Проектирование по Контракту, не готовы к полностью формальному подходу. Для выработки реального осознания преимуществ необходимо ощутить сложности разработки индустриального ПО. Но, с другой стороны, не следует допускать на первом курсе полностью неформальный подход, а годами спустя неожиданно показывать, что программирование нечто большее, чем хакерство. Подходящая методика, верю я, заключается в постепенности: вводить Проектирование по Контракту с первых шагов, сопровождая утверждением, что программирование основано на математическом стиле доказательств, и позволять учащимся овладеть практикой разработки ПО на основе умеренного формального подхода. Позже в учебном плане нужно предусмотреть курсы по таким темам, как формальная разработка и семантика языков программирования. Этот цикл может повторяться, так, чтобы теория и практика сменяли и дополняли друг друга.

Такой подход помогает студентам воспринимать концепции корректности не как академические химеры, а как естественный компонент процесса конструирования ПО.

В том же духе ведется обсуждение высокоуровневых функциональных объектов (агенты, глава 17, и их приложения к событийно управляемому программированию в главе 18). Такой подход обеспечивает возможность простого введения в лямбда-исчисление, включая карринг - математические разделы, редко включаемые в вводные курсы, но имеющие приложения на всем протяжении изучения программирования.

Другие подходы

Рассматривая учебные планы университетов, обсуждая с преподавателями, анализируя учебники, приходишь к заключению, что существуют четыре подхода к преподаванию вводного курса программирования:

1. сфокусированный на языке;
2. функциональный (в духе функционального программирования);
3. формальный;
4. структурный, стиль Паскаля или Ады.

Важно понять преимущества каждого из стилей и их ограничения.

Первый подход сегодня наиболее часто встречается. Он фокусируется на конкретном языке программирования, обычно Java или С++. Преимущество — в практичности и легко создаваемых упражнениях (есть риск использования студентами приема Google-and-Paste). Недостаток в том, что слишком много внимания уделяется выбранному языку в ущерб фундаментальным концептуальным навыкам.

Второй подход демонстрирует известный курс в МТИ (Массачусетском технологическом институте), который основан на схемном языке Sheme — функциональном языке программирования [1], устанавливающем некоторый стандарт для амбициозного учебного плана. Делаются также попытки использовать такие языки, как Haskell, ML или OCaml. Этот метод хорош для обучения навыкам логического вывода, лежащим в основе программирования. Мы стараемся сохранить эти преимущества, так же как и отношение к математике, используя логику и Проектирование по Контракту. Но, по моему мнению, ОО-технология дает студентам лучший способ справляться с проблемами конструирования программ. Не только потому, что ОО-подход соответствует практике современной индустрии ПО, высказывающей мало интереса к функциональному стилю программирования; более важно, что он лучше соответствует приемам построения систем и архитектуре ПО, а это является центральной задачей образования.

Хотя, как мы отмечали, учебный план не должен быть рабом доминирующих технологий, просто потому, что они доминируют, использование приемов и методик, далеких от практики, может привести нас к уже упомянутому риску потери связи со студентами, особенно продвинутыми. Алан Перлис высказал это менее дипломатично: "Чисто функциональные языки плохо функционируют".

Эпиграмма #108.

Я полагаю, что операционный, императивный аспект разработки ПО — это фундаментальный компонент дисциплины программирования, без которого исчезают наиболее трудные проблемы. В функциональном программировании он недооценивается и рассматривается как помеха реализации. Мне кажется, мы не особенно поможем студентам, защищая их от этих аспектов в начале образования. Им придется полагаться на собственные силы, когда они встретятся с ними позднее (добавьте к этому, что функциональное программирование в наши дни требует знакомства с монадами, — коль есть выбор, то я предпочитаю учить присваиванию, а не теории категорий).

Стоит отметить, что ОО-программирование математически вполне респектабельно благодаря теории абстрактных типов данных, на которой оно основано, а в Eiffel -благодаря контрактам. Как и в любом другом подходе, здесь хватает интеллектуальных вызовов. Рекурсия, один из замечательных механизмов функционального программирования, широко освещается в данной книге (глава 14).

Некоторые комментарии к функциональному программированию также применимы и к третьему подходу к обучению, покоящемуся на формальных методах. Как обсуждалось выше, формальные методы на начальном этапе преждевременны. Практическим эффектом такого подхода может быть возникающая у студентов уверенность, что академическая компьютерная наука не имеет ничего общего с практикой инженерии ПО.

Четвертый широко используемый подход, пионером введения которого был ETH, корнями уходит в семидесятые годы — годы становления структурного программирования. Этот подход распространен и до сих пор. Поддерживающим языком программирования является обычно Паскаль или один из его потомков — Modula-2, Oberon или Ada. Подход нашей книги является наследником этой традиции, в котором объектная технология рассматривается как естественное расширение структурного программирования, фокусируясь на рассмотрении масштабируемого программирования, отвечающего вызовам 21-го века.

Благодарности

Некоторые элементы предисловия для преподавателей взяты из ранних публикаций: [7], [8], [9], [10], [12].

Источником для этой книги послужил, как отмечалось, читаемый в ETH курс "Введение в программирование", постоянно поддерживаемый всем окружением ETH. Особую благодарность приношу Ректорату (который помог реализовать начальную разработку библиотеки Traffic, благодаря предоставленному FILEP гранту), а также факультету информатики, в частности его главе Питеру Видмайеру (Peter Widmayer), кто первый предложил мне прочесть вводный курс и приложил много усилий для координации моего и его собственного курса.

Я вел этот курс в первом семестре, начиная с 2003 года, и признателен выдающейся команде ассистентов за эффективную организацию зачетов, консультирование студентов, продумывание упражнений и вопросов для экзамена, опросов студентов, организации студенческих проектов, создания поддерживающих документов и учебных материалов, а также за замену меня на лекциях в случаях моего отсутствия. Это позволило мне сконцентрироваться на разработке педагогических концепций и основном материале, будучи уверенным, что все остальное будет работать. Я также благодарен сотням студентов, принявших этот курс вместе с моими пробами и ошибками и обеспечивших лучшую обратную связь, о которой можно только мечтать, — великолепные проекты ПО.

Смотри, например: http://games.ethz.ch

Ассистентами курса в 2003-2008 годах были: Волкан Арслан, Стефания Бальцер, Тилл Бэй, Карин Безаулт, Бенно Баумгартен, Рольф Брудерер, Урсина Калуори, Роберт Карнеки, Сюзанна Превитали, Стефан Классен, Йорг Дерунгс, Илинка Кьюпа, Иво Коломбо, Адам Дарвас, Питер Фаркас, Майкл Гомец, Себастьян Грубер, Беат Херлиг, Маттиас Конрад, Филипп Крэхенбюл, Герман Лехнер, Андреас Лейтнер, Рафаэль Мак, Бенджамин Моранди, Ян Мюллер, Мари-Элен Ниеналтовски, Петер Ниеналтовски, Мишела Педрони, Марко Пич-чиони, Конрад Плано, Надя Поликарпова, Маттиас Сала, Бернд Шоллер, Вольфганг Швед-лер, Габор Сабо, Себастьян Ваукулер, Джи Вэй и Тобиас Видмер.

Хочется особо отметить Мануля Ориоля за его участие в наших исследованиях, Тилла Бэя (за разработку библиотеки EiffelMedia, лежащей в основе студенческих проектов, библиотеки EiffelVision, разработанной при написании диплома, проекта Origo и сайта http://origo.ethz.ch как части его PhD диссертации), Карину Безаулт, Илинку Кьюпа, Андреаса Лейтнера, Ми-шелу Педрони и Марко Пиччиони (все они старшие преподаватели и принесли неоценимую пользу во многих начинаниях). Клаудиа Гюнтхарт обеспечивала выдающуюся административную поддержку.

ПО Traffic сыграло особо важную роль в подходе, развиваемом в этой книге. Текущая версия разрабатывалась в течение нескольких лет Мишелой Педрони, начавшей с оригинальной версии, которая была написана Патриком Шёнбахом под руководством Сюзанны Превитали; несколько студентов внесли свой вклад в разработку под руководством Мишелы Пе-дрони в разных семестрах в своих магистерских работах, в частности (в хронологическом порядке): Марсель Кесслер, Рольф Брудерер, Сибилла Арегер, Валентин Вюсгольц, Стефан Даниэль, Урсина Калуори, Роджер Кюнг, Фабиан Вюст, Флориан Гельдмахер, Сюзанна Ка-спер, Ларс Крапф, Ганс-Герман Джонас, Майкл Кэзер, Николя Бизирианис, Адриан Хель-фенштейн, Сара Хаузер, Мишель Крочи, Алан Фехр, Франциска Фритчи, Роджер Имбах, Матиас Бюхлман, Этьен Рэйхенбах и Мария Хьюсман. Их роль была неоценимой в привнесении пользовательского взгляда на продукт, учитывая, что они уже прослушали курс с ранней версией системы Traffic. Мишела Педрони занималась оркестровкой согласования ПО и книги, а также принимала участие в разработке педагогического подхода — обращенного учебного плана, подхода "извне — внутрь", поддерживающего инструментария (смотри http://truc-studio.origo.ethz.ch). Мари-Элен Ниеналтовски также принимала участие в наших педaгоги-ческих работах, создав систему TOOTOR, помогающую студентам осваивать материал; она попыталась привнести наш подход в Биркбек колледж университета Лондона (Birkbeck College, University of London).

Я благодарен моим коллегам по факультету Computer Science Department (Departement Informatik) в ETH за вдохновляющие дискуссии попроблемам обучения; я должен поблагодарить за критику и предложения Уолтера Гандера (кто помог мне улучшить важные примеры), Густаво Алонсо, Уэля Маурера, Юрга Гюткнехта, Тома Гросса, Питера Мюллера и Питера Видмайера.

Вне ETH я извлек много пользы от общения с преподавателями, включая Кристину Мингинс, Джонатана Острофф, Джона Поттера, Рихарда Патисса, Джин-Марка Джезекуэля, Владимира Биллига, Анатолия Шалыто, Андрея Терехова и Юдифь Бишоп.

Для всех моих публикаций за последние годы, включая и эту книгу, огромную ценность представляет выдающаяся работа по созданию библиотек и среды разработки EiffelStudio, созданной в фирме Eiffel Software всей командой разработчиков и ведущей ролью Эммануэля Стапфа.

Я также благодарен комитету по стандартам ECMA International TC49-TG4, взявшему на себя заботы о стандарте ISO Eiffel, принимавшему участие во всех рассмотрениях по улучшению и расширению языка проектирования и учету потребностей начинающих студентов. Свой вклад внесли Эммануэль Стапф, Марк Ховард, Эрик Безаулт, Ким Уолден, Зоран Симик, Пауль-Георг Крисмер, Роджер Осмонд, Пауль Кохен, Кристина Мингинс и Доминик Колнет.

Обсуждения на форуме Eiffel Software: http://groups.eiffel.com также были полезны.

Перечисление даже подмножества людей, оказавших на меня влияние, заняло бы несколько страниц. Многие из них цитируются в тексте, но один — нет: в теме "представление рекурсии" заимствованы некоторые из идей онлайновых записей лекций Андриеса ван Дама из университета Брауна.

Многие люди представили свои комментарии к черновым вариантам книги. Я должен отметить в частности Bernie Cohen (хотя его принципиальное влияние начало ощущаться задолго до написания книги, когда он предложил концепцию обращенного учебного плана), Филиппа Кордела, Эрика Безаулта, Огниана Пишева и Мухаммеда Абд-Эль-Разика, также как студентов и ассистентов ETH: Карин Безаулт, Йорга Дерунгса, Вернера Диетла, Мориса Диетше, Лючин Доблис, Марка Эгга, Оливера Джегера, Эрнста Лейзи, Ханну Рёст, Рафаэля Швейцера и Элиаса Юсефи. Герман Лехнер предложил несколько упражнений. Трюгве Реинскауг внес важные комментарии в главу по событийно управляемому программированию. Я особо благодарен за внимательное чтение и поиск ошибок в последней редакции, выполненных Марко Пиччиони и Стефану ван Стадену.

Особая благодарность создателям материалов, вошедших в приложения по отдельным языкам программирования: Марко Пиччиони (Java, приложение A), Бенджамину Моранди (C#, приложение B) и Наде Поликарповой (C++, приложение C). Конечно, на мне лежит вся ответственность за любые дефекты в окончательном варианте их представления.

Не могу найти нужных слов, чтобы описать всю ценность чрезвычайно упорной и профессиональной работы по чтению финальной версии Анни Мейер и Рафаэлю Мейеру, приведшую к сотням (фактически тысячам) коррекций и улучшений.

Так много людей помогло мне, что я боюсь, что кого-то пропустил, Поэтому оставляю список открытым.

Смотри http://touch.ethz.ch/acknowledgmentsonline,

Я хотел бы закончить благодарностью за помощь и советы Монике Рипл из издательского отдела в Лейпциге за помощь и советы в подготовке книги к изданию, Герману Ингессе-ру и Дороти Глаунзингер из издательства Шпрингер за теплую и эффективную поддержку в процессе публикации.

БМ

Санта-Барбара / Цюрих, Апрель 2009