Зачем новичкам впаривают ООП, а не процедурного прог-ния?

[мат-ламер]

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

[arseniiv]

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

А использовать процедуры, объекты, метапрограммирование и функциональное (нелепо сконструированный списочек, к тому же многое пропущено) нужно по возможности в естественных для этого задачах. Например, простую консольную (кстати, ведь и интерфейсы тоже имеют свои так же пересекающиеся области "хорошего применения") утилиту бывает часто [правильно и] удобно сделать из нескольких процедур, и объекты там совершенно ни к чему как элемент синтаксиса. С другой стороны, даже если программа простая, но ожидается расширение её функций (и увеличение количества кода), лучше её сразу структурировать. Объекты для этого удобны, не зря же появились, но этому служат так же и модули/файлы и пространства имён.

[creative]

AlexDem в сообщении #329209 писал(а):

Есть такая книга "Алгоритмы + структуры данных = программы", и это правильно

Это же Вирт :) Спасибо, обязательно почитаю.

[Профессор Снэйп]

ООП концептуапльно с философской точки зрения. Класс с унаследованными методами --- модель живого организма.

Отсюда мораль --- ООП надо преподавать философам. А математикам --- фортран и машину Тьюринга.

[vek88]

Только щас заметил эту тему. Ну да лучше поздно ... .

ИМХО проблемы ООП, GOTO и т.д. отражают концептуальное изменение природы программирования за последние десятилетия прошлого века.

Что было, скажем, в 70-х годах прошлого века? Вот некий программер работает, скажем, на ЕС ЭВМ. Как стать ему корифеем? Да элементарно: прочитал пару десятков руководств по ЕС ЭВМ, изучил несколько языков (Фортран, Ассемблер, ПЛ/1, ...), прочитал несколько хороших книг (Донован, Кнут, Жоголев и Трифонов, ...). Попрактиковался. И все? И все - ты корифей, т.к. знаешь почти все о программировании.

А что произошло в 80-90-х? Дык хоть тресни, а сколько ни изучай, ты никогда не узнаешь и одного процента от всего навороченного в программировании. Грубо говоря, теперь нужно было научиться успешно работать в обстановке, когда ты ничего не знаешь. И что интересно, значительная часть программистов старой закалки не вписалась в эту новую парадигму.

Да плюс еще этот Дэйкстра со своим структурным программированием. Как же, к примеру, без GOTO? И ООП это дурацкое? Как же тут программировать?

А те, кто смог перестроится, вполне оценили и ООП и отказ от GOTO. Я писал на самых разных языках (Ассемблер, Фортран, ПЛ/1, С, С++, VBA, ...). Не отношу себя к профессиональным программистам - пишу мало. За последние лет двадцать написал всего тысяч десять строк, но ни разу не использовал GOTO. Подтверждаю, что отказ от GOTO действительно существенно повышает наглядность программ, упрощает отладку. И это особенно ценно при коллективной работе программистов над большим проектом.

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

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

Так вот, ООП и структурное программирование - это средства улучшения структуры программы, особенно полезные при создании и развитии сложных проектов.

Другой вопрос, что педагоги должны быть грамотными и не должны нарушать основные педагогические принципы, в частности, принципы "от простого к сложному" и "объясняй зачем и для чего".

[Alexu007]

vek88 в сообщении #353885 писал(а):

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

Непонимаю причину такой ненависти к $goto$. Допустим безусловный переход из конца в начало программы действительно её запутывает и скорее всего не нужен, но зачем отказываться от использования внутри относительно небольших функций или процедур - если того требует логика? Функции то всё равно писать приходится, несмотря на ООП - теперь они называются "функции-члены"? Не приходится ли дополнительно усложнять (и запутывать) программу ради единственной идеи-фикс обойтись вообще без $goto$?

Кстати, $jmp$ - команда процессора и системные программисты по этому поводу вроде не комплексуют...

[vek88]

Alexu007 в сообщении #353912 писал(а):

vek88 в сообщении #353885 писал(а):

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

(1) Непонимаю причину такой ненависти к $goto$. Допустим безусловный переход из конца в начало программы действительно её запутывает и скорее всего не нужен, (2) но зачем отказываться от использования внутри относительно небольших функций или процедур - если того требует логика? (3) Функции то всё равно писать приходится, несмотря на ООП - теперь они называются "функции-члены"? (4) Не приходится ли дополнительно усложнять (и запутывать) программу ради единственной идеи-фикс обойтись вообще без $goto$?

(5) Кстати, $jmp$ - команда процессора и системные программисты по этому поводу вроде не комплексуют...

1. Вы ошибаетесь - ненависти не было и нет. А вот равнодушие и пренебрежение за последние 20 лет вполне оформилось. Хотя раньше был как все - использовал GOTO.

2. О какой логике Вы говорите? Логики бывают разные. Например, когда Колмогорова спросили, есть ли женская логика, он ответил, есть - если это мне нравится, значит это истинно.

Разумеется, пришлось созреть для отказа от GOTO - это было не просто - а теперь для меня естественна логика без GOTO.

3. Видимо, я не точно выразился - уточняю. Я не смешиваю ООП и отказ от GOTO - это разные вещи, хотя и направленные на одно и то же - на повышение качества ПО. И хотя писал немного в стиле ООП на C++, но скорее с целью освоения методологии. Последние 10 лет пишу на VBA в обычном стиле, но категорически без GOTO.

4. Настаиваю, что в результате отказа от GOTO программа упрощается.

5. Разумеется, говоря об отказе от GOTO, мы имеем в виду языки высокого уровня. А в машинных кодах или в языке Ассемблера этот отказ был бы самоубийством.

ЗЫ. На моем сайте дана ссылка на программу здорового питания - порядка 1000 строк на VBA. Правда, она запаролена. Однако готов выложить в качестве без GOTO-шного примера какую-нибудь ее часть, если это интересно.

[Alexu007]

Самый простой пример: мы получаем случайное число, но оно по какой-либо причине нас не устраивает:

met_10: 

  X = random (100);
  if (Arrow[X] != 0) goto met_10;

Можно конечно и без goto, например запустить бесконечный цикл, выходить из которого оператором break, но ведь это одно и то же.

[EtCetera]

Alexu007

Alexu007 в сообщении #353938 писал(а):

met_10: 

  X = random (100);
  if (Arrow[X] != 0) goto met_10;

Можно конечно и без goto...

Действительно, к чему оно тут?...

do
    X = random(100);
while (Arrow[X] != 0);

[Dandan]

языки программирования развиваются в сторону декларативности, потому что декларативное описание намного понятнее человеку, чем императивное. Отказ от оператора goto - это сааамый первый шаг на пути от императивного к декларативному программированию.

[Alexu007]

Большой разницы нет - те же три строки. Но условие перехода к метке met_10 может быть намного сложнее и этих условий может быть много, засунуть все внутрь скобок оператора while() довольно проблематично... и будет совершенно нечитаемо.

А главное - одно и то же, не даёт никакого вклада в эффективность программы, только дань моде.

[vek88]

Alexu007 в сообщении #353967 писал(а):

Большой разницы нет - те же три строки. Но условие перехода к метке met_10 может быть намного сложнее и этих условий может быть много, засунуть все внутрь скобок оператора while() довольно проблематично... и будет совершенно нечитаемо.

О чем Вы говорите? Вот известная Вам задача "о двух мудрецах". См. post349425.html#p349425

А вот условие проверки того, что два целых числа $m,n$ удовлетворяют условию этой задачи. Здесь четыре функции reply...(...) - булевы функции проверки условий $A,B,C,D$.

if( reply1(m*n) && reply2(m+n) && reply3(m*n) && reply4(m+n) )

Это условие предельно просто и наглядно. И выражает в точности то, что нам нужно - что два числа $m,n$ удовлетворяют неким четырем условиям. А сложность условий определяется конкретными фунциями reply...(...).

И ныкаких GOTO.

[EtCetera]

Alexu007

Alexu007 в сообщении #353967 писал(а):

Но условие перехода к метке met_10 может быть намного сложнее и этих условий может быть много, засунуть все внутрь скобок оператора while() довольно проблематично...

Ничуть:

do
    X = random(100);
while
    (
        (Arrow[X] != 0) &&
        (<условие 2>) &&
        (<условие 3>) &&
        <...>
    );

Или Вы не это имели в виду?

[Maslov]

Ограничение использования оператора GOTO к ООП особого отношения не имеет: это часть подхода к повышению читаемости и сопровождаемости кода под названием структурное программирование, появившегося лет 40 назад. В соответствии с этим подходом, программа представляет собой линейную последовательность блоков определённых типов (следование, if ... then ... else, цикл типа while). Каждый блок имеет один вход и один выход. Поток управления всегда направлен сверху вниз.
Кроме этого, структурное программирование определяло нисходящее программирование и декомпозицию как основные приёмы построения программ.
Вот такая вот книжка была в свое время весьма популярна: Хьюз Дж. Структурный подход к программированию

Dandan в сообщении #353944 писал(а):

декларативное описание намного понятнее человеку, чем императивное

На мой взгляд, это довольно спорное утверждение.

[vek88]

Maslov в сообщении #353991 писал(а):

Dandan в сообщении #353944 писал(а):

декларативное описание намного понятнее человеку, чем императивное

На мой взгляд, это довольно спорное утверждение.

Это утверждение не вполне точно, но оно бесспорно.

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

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