Здравствуйте, LaptevVV, Вы писали:


LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев):
LVV>а) полный перебор;
LVV>б) поиск по заданному условию;
LVV>Для этих вариантов нужно написать шаблон цикла и сказать ученику: делай так!
LVV>А потом ему давать задачи на циклы и чтобы он распознавал, какого типа задача передним: перебор или поиск.
LVV>Например, поиск максимума в массиве — это полный перебор.
LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while.
LVV>Остальные операторы цикла — дополнительные удобства.

LVV>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.

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

Здравствуйте, LaptevVV, Вы писали:

LVV>Вот например, в шахматах есть такое правило для новичков: конь на краю доски — плохо. Но гроссы его запросто нарушают. А для новичков — ПЛОХО!

Техника это не методология и свод правил В шахматах под техникой обычно понимают способ реализации перевеса. При этом у каждого шахматиста (да и у музыканта, каратиста) техника своя. В программировании тоже

LVV>Вот например, написал чел цикл:
LVV>

LVV>while (true) 
LVV>{ // ...
LVV>   if(некое условие) break;
LVV>  // ...
LVV>}
LVV>

LVV>Это "хороший" цикл? Или такой цикл для новичков лучше запретить? А профи могут им пользоваться, ибо понимают, что и зачем...

А почему надо такой цикл запрещать? Хорошая конструкция

Здравствуйте, Аноним, Вы писали:

А>У музыкантов и спортсменов под техникой понимается некоторая физическая составляющая деятельности, коей является доведенная до автоматизма последовательность сокращения мышц.

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

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".

Свод правил это все-таки методология. "Непрерывно меняющиеся" звучит достаточно расплывчато. Все в нашем мире меняется, что медленнее, что быстрее. "Индивидуальные" это особенность. Но главное, такое определение не позволяет сказать: техника программирования этого студента хромает. Не включено сюда сравнение

Здравствуйте, LaptevVV, Вы писали:

LVV>Вот возьмем циклы. По сути есть только два варианта использования цикла (Ф.В. Ткачев):
LVV>а) полный перебор;
LVV>б) поиск по заданному условию;

Ну... есть еще организация метки:

  repeat
    if Something then Break;
    if SomethingElse then Break;
  until True;

LVV>Соответственно удобны две разных ФОРМЫ цикла: для перебора — for, а для поиска — while.

А вообще такой подход лично мне не нравится. Для меня цикл это повторяющиеся вычисления. Есть только один цикл: for(;), а все остальное синтаксический сахар вокруг него. Собственно говоря, такой подход реализован в Ada: так есть один основной цикл:

loop
  -- инструкции тела цикла
  -- Внутри можно юзать exit (выход из цикла) и
  -- exit when (выход из цикла, если выполняется определенное условие)
end loop;

А все остальное просто синтаксический сахар вокруг:

while логическое_выражение loop
    -- инструкции тела цикла
end loop;

for счетчик in диапазон_значений_счетчика loop
    -- инструкции тела цикла
end loop;

Мне такой подход более симпатичен.

Здравствуйте, 31415926, Вы писали:

3>Во-первых, 99% контор просто не стоят, чтобы в них работать. Кроме того, я не утверждал, что преподаватели никогда не умели программировать. Хотя, "операционная система в восьмеричных кодах" — звучит диковато, если Вам конечно не крепко за 60.
Это было в 80-е. Писали на ассемблере, естественно, а отлаживались на встроенном восьмеричном отладчике. Тогда только появился тетрис...
LVV>>Я ж вам сказал, что в этой области — не спец. Хотя если потребуется, разберусь и смогу написать, что нужно.
3>А это ничего, что преподаватель ИТ в 21 веке "не спец" в основах Интернет-программирования? Какой процент Ваших выпускников будет реализовывать ассемблер? Сильно подозреваю, что нулевой (разве что пойдут по Вашим стопам). А вот с HTTP все они сталкиваюся каждый день, и очень прискорбно ИМХО, что даже их преподаватель пока что не считает нужным разобраться с тем, как это работает.
Очевидно, вы ОЧЕНЬ ДАЛЕКИ от преподавания... Интернет-технологии у нас тоже преподают... Только это отдельный годовой курс. Преподает наш же выпускник 2004 года, бывший дипломантом 1 степени конкурса "Цифровой ветер". Вполне квалифицированный товарисчь...
LVV>>А то критикуете по принципу: Не читал, но осуждаю.
3>Я и не думал читать Вам мораль. Просто хотел напомнить об ответственности перед Вашими выпускниками — судя по всему то, чему Вы их учите, современному промышленному программисту не очень-то и нужно. И "клиент-серверная приблуда для проверки студенческих лабораторных по паттерну Template Method" у любого профессионала ничего, кроме усмешки вызвать не может.
3>А насчет "прочитать" — я уже ранее говорил, что у меня нет времени на ознакомление с маргинальными течениями.
Пока все это похоже на гнутие пальцев...
Я пытаюсь выяснить мнение профи о постановке техники программирования, а вы пальцы гнете... Что ж гните их и дальше...
А "мы пойдем другим путем"...

Здравствуйте, Sergey Chadov, Вы писали:

LVV>>И про остальные типовые задачи тоже так нужно сделать. Только я чего-то не видал подхода именно от такой печки. В учебниках изучают язык, а не технику программирования. Такого слова даже не встречается.

SC>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели.
SC>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо.
Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать. А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.
Тенниссист же не задумывается о каждом ударе в партии — он делает это на автомате. А думает он о комбинациях, которые будет проводить... Такой же автоматизм ИМХО нужен и при написании отдельных конструкций...

Здравствуйте, LaptevVV, Вы писали:



SC>>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели.
SC>>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо.
LVV>Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать.

Не мыслить, а делать — это само получится, не надо этому учить

LVV> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.

На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается.
К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы.

Здравствуйте, LaptevVV, Вы писали:

LVV>Пока все это похоже на гнутие пальцев...
LVV>Я пытаюсь выяснить мнение профи о постановке техники программирования, а вы пальцы гнете... Что ж гните их и дальше...
LVV>А "мы пойдем другим путем"...

Так я Вам и пытаюсь сказать — нужно разбирать как можно больше конкретных примеров из реальной программистской практики с использованием современных рабочих (т.е. широко используемых) языков программирования.
Это и студентам интереснее будет, как мне кажется. Вот например, упонянутый ранее GUI event dispatcher. По Вашему это — rocket science. Я же считаю, что будущий программист должен как можно раньше познакомиться с этим. По крайней мере, будут отдавать себе отчет, что происходит, когда GUI приложение "виснет". А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP. Да собственно и для Вас, судя по Вашей реакции, то обстоятельство, что имеется отдельный от Вашего курс, который читает "квалифицированный товарисчь" является оправданием Вашего собственного дремучего невежества в простейших вопросах связанных с самым широко используемой на сегодня технологией. Хочется надеяться, что этот "квалифицированный товарисчь" способен самостоятельно написать цикл, а не ссылается в таких случаях на Вас.
А Вас все в теорию тянет, да в какие-то ветхозаветные материи вроде ассемблера. Или же наоборот — в какую-то экзотику, которой увлечен некий гражданин из Тьмутараканьского НИИЧАВО или дипломанты каких-то загадочных премий. И какие-то странные туманные мечтания о стерильных языках для обучения. Впрочем, похоже, что все это говорить бесполезно. Так и будете преподавать — программирование как набор абстрактных принципов отдельно, Интернет — отдельно, БД — отдельно. А то что люди, получившие подобное "образование" (и, возможно, за него заплатившие) будут потом вынуждены начинать практически с нуля — неважно. Все равно от людей с Астраханским дипломом никто особых чудес не ожидает. Зато преподаватели — все сплошь ученые, которых аж сам Нуралиев по лысине погладил... Ладно хватит воздух сотрясать. Еще раз творческих успехов!

Здравствуйте, Sergey Chadov, Вы писали:

SC>Здравствуйте, LaptevVV, Вы писали:



SC>>>Попытки строго формализовать процесс программирования, да и любую другую инженерную деятельность, то есть фактически исключить из этой деятельности непосредственно инженера, предпринимались неоднократно и пока ни к чему хорошему не привели.
SC>>>Собственно задача этого самого инженера и заключается в том, чтобы из множества вариантов, каждый из которых имеет свои достоинства и недостатки, в условиях неоднозначно определенных критериев качества получившегося результата, сделать-таки свою работу хорошо.
LVV>>Речь не о формализации деятельности инженера. А о формировании определенных типовых шаблонов мышления — техники программирования — некоторого определенного уровня. Чтобы на рутинном уровне не мыслить, а делать.

SC>Не мыслить, а делать — это само получится, не надо этому учить
В том-то и дело, что "само" — не получается... Учить приходится...
LVV>> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.
SC>На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается.
SC>К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы.
Вот вы не поверите, приходится останавливаться. Циклы и функции — два краеугольных камня попервоначалу. Потом — указатели...
То, о чем вы говорите — это уже студенты постарше. А начинающих — именно циклам и функциям учить приходится...
Поэтому и собираю опыт, кто как учит или учил...

Здравствуйте, LaptevVV, Вы писали:


SC>>Не мыслить, а делать — это само получится, не надо этому учить
LVV>В том-то и дело, что "само" — не получается... Учить приходится...

Получится. побольше практики и разбор кода творят чудеса.

LVV>>> А размышлять на более высоком уровне — на архитектурном, например. А циклы пусть пишутся правильно на автомате.
SC>>На автомате пишется то, что часто используется. Все. Никакими другими средствами автоматизм не достигается.
SC>>К тому же, что-то мне не кажется, что особенности написания простейших циклов — то, чему стоит уделять много внимания. Лучше сконцентрироваться на том, чтобы объяснять студенту, почему он неправ в каждом конкретном куске кода, какие могут быть с ним проблемы.
LVV>Вот вы не поверите, приходится останавливаться. Циклы и функции — два краеугольных камня попервоначалу. Потом — указатели...
Я преподавал программирование у студенток-первокурсниц специальности "документоведение", не надо мне рассказывать

LVV>То, о чем вы говорите — это уже студенты постарше. А начинающих — именно циклам и функциям учить приходится...
Пусть сразу привыкают к принятию инженерных решений, а не к решению "задач на цикл"

Здравствуйте, Mystic, Вы писали:

M>Техника есть у шахматистов, у математиков и т. п. Так что сокращение мыщц можно заменить на последовательность действий (необязательно физических).

У меня вот тут под рукой книжка по шахматам. Первый раздел называется "шахматная азбука", второй — "элементы шахматной партии", третий — "основы шахматной тактики". И это всё основы, и это не есть "техника" в том понимании, которое существует у спортсменов, музыкантов и художников. Не подменяйте понятия.

Здравствуйте, Mystic,

ГМ>>Я бы определил технику программирования как свод непрерывно меняющихся правил программирования, индивидуальный для каждого программиста. IMHO, ключевые слова здесь — "непрерывно меняющиеся" и "индивидуальные".

M>Свод правил это все-таки методология. "Непрерывно меняющиеся" звучит достаточно расплывчато. Все в нашем мире меняется, что медленнее, что быстрее. "Индивидуальные" это особенность. Но главное, такое определение не позволяет сказать: техника программирования этого студента хромает. Не включено сюда сравнение
--
IMHO, вполне можно сравнивать изменение техники программирования одного и того же студента с течением времени, наблюдая (или не наблюдая) изменение "хромоты" его кода, нет?

C уважением,
Геннадий Майко.

Здравствуйте, 31415926, Вы писали:

3>А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP.

А вот это как раз и результат чистого "практического" подхода. Когда человек прогуливает лекции и вместо них кодит на похапе ("современном рабочем", по вашей классификации, языке программирования) дорвеи-магазины-порталы (на этом же можно заработать "много бабла", и время — деньги, некогда менять его на малозначимую ерунду, да?), изобретая на ходу велосипеды или решая попутно "неразрешимые" для него задачи, открывая каждый раз америку. Это тот результат, когда человек научился пользоваться поиском готового кода в гугле и готовыми классами HttpRequest и подобными.

Да-да, именно такие "практики" считают, что отличие протоколов только в параметрах инициализации сокета. А уж если надо, чтобы человек различал по-нормальному, извольте прочитать ему курс сетевых протоколов, в котором отражаются базовые принципы, стоящие за тем и за другим, извольте рассказать про модель OSI, про её уровни, рассказать, что TCP работает на совершенно другом уровне, нежели тот же HTTP и т.д. Вот только к программированию всё это относится чуть более, чем никак (открытие, да?) И, кстати, о чудо — взору откроется так же и то, что подобные принципы работают даже там, где и не пахнет никакими протоколами. А без этого наш глупыш-практик, нахватавшийся знаний по верхам, никогда не заметит настоящих решений, ведь он будет считать это излишней тупой ботвой.

Ведь вы же не такой "практик"? Зачем тогда писать глупости?

Здравствуйте, LaptevVV, Вы писали:
LVV>ВО! Очень показательно! Нынче " в моде...". А правильно ли это? Обработка исключений — это, между прочим, нелокальный переход... Который нарушает один из принципов, указанных Робертом Мартином в книге "Чистый код":
Значит, этот принцип применим только в частных случаях. Исключения — это все-таки распространенная "хорошая практика" (в отсутствии противопоказаний), и писать код без них не всем нравится. Это еще не идет речь о более мощной нелокальности, навроде call/cc.

LVV>программа должна читаться сверху вних без прыжков в разные места.
Ну это разве что очень маленькая программа. Автору этого высказывания предлагаю почитать, например, исходники линукса. Ага, сверху вниз.

LVV>Различие заложено в конструкции машины: выполнение команд управления принципиально отличается от выполнения других команд.
Не возьмусь спорить о различных архитектурах и системах команд, но у того же x86 в системе команд нет разделения на "стейтмент" и "экспрешн" в том понимании, в котором оно имеется в императивных языках. Я бы даже сказал, что все суть стейтмент. Так что никакой вины системы команд в разделении нет.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, 31415926, Вы писали:

3>>А то попросишь на собеседовании J2EE team lead`а расписать, что происходит в сети от момента ввода URL до показа страницы — а он глазами хлопает и мычит что-то невнятное. Это чудо, если человек, 5+ лет разрабатывающий Интернет приложения способен объяснить разницу между TCP и UDP.

А>А вот это как раз и результат чистого "практического" подхода. Когда человек прогуливает лекции и вместо них кодит на похапе ("современном рабочем", по вашей классификации, языке программирования) дорвеи-магазины-порталы (на этом же можно заработать "много бабла", и время — деньги, некогда менять его на малозначимую ерунду, да?), изобретая на ходу велосипеды или решая попутно "неразрешимые" для него задачи, открывая каждый раз америку. Это тот результат, когда человек научился пользоваться поиском готового кода в гугле и готовыми классами HttpRequest и подобными.

А>Да-да, именно такие "практики" считают, что отличие протоколов только в параметрах инициализации сокета. А уж если надо, чтобы человек различал по-нормальному, извольте прочитать ему курс сетевых протоколов, в котором отражаются базовые принципы, стоящие за тем и за другим, извольте рассказать про модель OSI, про её уровни, рассказать, что TCP работает на совершенно другом уровне, нежели тот же HTTP и т.д. Вот только к программированию всё это относится чуть более, чем никак (открытие, да?) И, кстати, о чудо — взору откроется так же и то, что подобные принципы работают даже там, где и не пахнет никакими протоколами. А без этого наш глупыш-практик, нахватавшийся знаний по верхам, никогда не заметит настоящих решений, ведь он будет считать это излишней тупой ботвой.

А>Ведь вы же не такой "практик"? Зачем тогда писать глупости?

Надеюсь, что не такой. Вот только как нарисованная Вами картина соотносится с моими высказываниями — убейте, не пойму. Я где-нибудь призывал к отказу от изучения основ или агитировал заменить систематическое образование халтурой? По-моему, я возражал против беспредметного теоретизирования (типа классификации циклов) при обучении и призывал обучать программированию на практических примерах. Зачем приписывать мне противоположную крайность? Я не знаю PHP, но подозреваю, что и на его основе можно дать человеку неплохую основу. Хотя, как мне кажется, языки со строгой типизацией для начального образования все-таки предпочтительней.

Здравствуйте, LaptevVV, Вы писали:

LVV>Что следует понимать под техникой программирования и как ее надо "ставить"?

Сегодня спросили А. Степанова, что он думает по этому поводу. Вкратце (надеюсь он не обидится за моё вольное переложение) так: при обучении очень важна традиционность. В частности был камень в огород американских ВУЗов, где сменилось 4 или 5 базовых языка. В этом отношении в России, по его мнению, очень правильная программа: сначала Паскаль с алгоритмами (Вирт + Кнут), потом ассемблер, а затем С (+ классы). Дальше, чем больше используется стандартных компонент — тем лучше.

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

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

Здравствуйте, frogkiller, Вы писали:

LVV>>Что следует понимать под техникой программирования и как ее надо "ставить"?

F>Сегодня спросили А. Степанова, что он думает по этому поводу. Вкратце (надеюсь он не обидится за моё вольное переложение) так: при обучении очень важна традиционность. В частности был камень в огород американских ВУЗов, где сменилось 4 или 5 базовых языка. В этом отношении в России, по его мнению, очень правильная программа: сначала Паскаль с алгоритмами (Вирт + Кнут), потом ассемблер, а затем С (+ классы). Дальше, чем больше используется стандартных компонент — тем лучше.
Прекрасно! Взгляд со стороны — свежим ветерком повеяло.
F>А ещё он говорил такое (мы как-то не очень согласились, и это, кажется, его расстроило) — важна принадлежность к сообществу, т.е. принятие (в том числе и на веру - вот тут мы спорили) прошлых достижений — разумеется, без фанатизма, так чтоб это не мешало развитию. (Например, он очень сожалел, что из-за стремления к поддержанию всех имеющихся фич в STL, я так понял, речь в основном шла о неявных кастах, не успели проработать концепты, и их не включат в новый стандарт)
О! Тут я с ним полностью согласен! Иначе получается по принципу революции: старый мир разрушим до основания, новый — наш — построим.
F>А ещё, по его мнению, важно постоянно помнить о производительности кода — что не надо приносить эффективность в жертву обощению. И если есть эффективные частные реализации, не надо от них отказываться в пользу красивых обобщений. (Тут бы некоторый камень в огород функционального программирования)
Во! С этим тоже спорить не приходится. Каждая конкретная программа должна проходить две стадии: работает без ошибок, эффектив6нно работает без ошибок...
Большое спасибо!

Здравствуйте, 31415926, Вы писали:

3>Надеюсь, что не такой. Вот только как нарисованная Вами картина соотносится с моими высказываниями — убейте, не пойму. Я где-нибудь призывал к отказу от изучения основ или агитировал заменить систематическое образование халтурой? По-моему, я возражал против беспредметного теоретизирования (типа классификации циклов) при обучении и призывал обучать программированию на практических примерах. Зачем приписывать мне противоположную крайность? Я не знаю PHP, но подозреваю, что и на его основе можно дать человеку неплохую основу. Хотя, как мне кажется, языки со строгой типизацией для начального образования все-таки предпочтительней.

Изначально мне бросилось в глаза ваше недовольство образовательным подходом, выраженное в ряде фраз и в частности в данной фразе:
3>Так и будете преподавать — программирование как набор абстрактных принципов отдельно, Интернет — отдельно, БД — отдельно.

С этим я позволил себе не согласиться, а потом уж я случайно понаписал лишнего, не имея целью приписать вам некие крайности. Извините. Тем более, что по остальным пунктам с вами нельзя не согласиться.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Mystic, Вы писали:

M>>Техника есть у шахматистов, у математиков и т. п. Так что сокращение мыщц можно заменить на последовательность действий (необязательно физических).

А>У меня вот тут под рукой книжка по шахматам. Первый раздел называется "шахматная азбука", второй — "элементы шахматной партии", третий — "основы шахматной тактики". И это всё основы, и это не есть "техника" в том понимании, которое существует у спортсменов, музыкантов и художников. Не подменяйте понятия.

Ну так надо взять книги для более продвинутого уровня. Я не подменяю понятия, я просто говорю, что слово "техника" применяется к шахматам. Например, Карлсен и Крамник шахматисты с высокой техникой. А у такого-то шахматиста техника хромает. Например:

Филигранная техника седьмого чемпиона мира (Смыслова) до сих пор является эталонной. Внимательное изучение его партий – лучший способ научиться играть окончания. Контуры эндшпиля Смыслов видел задолго, еще с дебюта. При этом он вовсе не сушил игру, не стремился любой ценой к разменам.

или

Главная особенность стиля Таля-комментатора заключается в самоиронии. Вместо серьезного, вдумчивого вещателя истин мы в его примечаниях видим невероятно живого, остроумного человека, который очень доброжелательно относится к шахматистам и постоянно подшучивает над самим собой. Всем известна его фраза к неудачно проведенным окончаниям своих партий: «А далее в бой вступила моя прославленная техника!»

или

Благодаря сотням партий, сыгранным в матчах между двумя «К», был совершен прорыв во многих дебютных вариантах, созданы десятки превосходных партий с образцовой игрой во всех стадиях. Подобно Алехину, который перед матчем в Буэнос-Айресе поставил перед собой и успешно решил задачу догнать Капабланку в позиционной игре, Гарри сумел прямо по ходу первого матча – титанического безлимитного марафона – усилить свою игру. Молодой и горячий южный парень научился хорошо играть скучные технические позиции, терпеливо обороняться, лавировать и быстро перестраиваться по ходу партии. Играя в стиле Карпова, он сумел устоять на поле соперника! А в своей стихии – дебютной подготовке и комбинационной игре – Гарри оказался сильнее, что и позволило ему, в конечном счете, стать новым чемпионом мира. А затем отстоять титул в новых матчах.

(с) МГ, Сергей Шипов