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

Нет никаких "приемов программирования", нет и не может быть из принципа, ибо программирование есть просто выражение текстом определенной логики.

Какие при этом используются закорючки -- не суть важно.

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

Приёмы программирования -- это как приёмы конструирования. Вал садят в отверстие так-то. В таких-то местах применяют болт, а в таких-то -- заклёпку. Понимаете? Чтобы человек не парил мыслями в эмпиреях "логики", а знал конкретно, как однотипно решать однотипные небольшие задачки, из которых и состоят большие программы. Плюс навыки управления сложностью! Это структурирование самой программы, данных и алгоритма. Программы неимоверно сложны, потому что на их создание не требуется тратить металл:)

Программирование к "конструированию" никакого отношения не имеет. "Конструировать" программы -- все равно, что "конструировать" художественный роман.

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

Вы меня поражаете! Осознание единства программирования и всей иной инженерной деятельности было существеннейшим прорывом 70х годов в понимании обсуждаемой проблемы! Структурированнное программирование и проектирование программ помните?
А штампы нужны. Даже необходимы. В любой области деятельности. Надо только подходить ко всему диалектически. Без абсолютизации и фанатизма:)

Отнюдь.

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

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

Как хотите. Я жил и работал в то время, и видел, какое положительное влияние структурный подход оказал на многих "программистов". Хотя в советской школе программирования (Липаев) это делали ещё c 50х годов.

Есть веняемая способность элементарно мыслить, но для этого "подходы" не срабатывают, к сожалению.

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

Слишком уж многие используют "приемы" как заменитель способности мыслить.

На мой взгляд, пусть уж лучше помучаются без "приемов", так будет лучше для всех в итоге.

На изобретение приемов даже мыслящему человеку требуется время. Время жизни и наживания опыта. Хорошо бы и думать уметь и приёмы знать. Противопоставлять нельзя.

Нет никаких "приёмов обращения с лопатой", из принципа, поскольку копание есть просто перемещение земли из одного места в другое.

Аналогия понятна?

всё программирование можно свести к перемещению байтов из одной ячейки памяти в другую?

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

А с человеческой психикой мы иметь дело вынуждены, поскольку пока что кроме человека писать программы некому.

Ваш пост ошибочен -- "копание лопатой" неравнозначно "перемещению земли из одного места в другое". Например, полтонны динамита тоже легко перемещает "землю из одного места в другое".

Пользуйтесь логикой и не балуйтесь аналогиями, короче.

Я, видите ли, пытался воспроизвести ваш (явно абсурдный) ход рассуждений. Приёмы программирования - не для компьютеров (которым, действительно, достаточно логики); приёмы программирования - для людей, которые с их помощью пытаются заставить своё несовершенное мышление справляться с присущей этому виду деятельности сложностью. Я допускаю, что лично вы в такой ерунде не нуждаетесь; но большинство людей не является такими вот терминаторами.

Аналогия понятна. Называется Ваша мысль так: "Смелость неведенья".

Я не очень понял, какой тезис вы защищаете. Вы хотите сказать, что приёмов программирования не существует или не должно существовать? Я утверждаю, что существуют, и, более того, необходимы.

Чтение Ваших новых постов делает неуместным моё саркастическое хмыканье. Я с Вами согласен полностью. ПО психике и по приёмам программирования.

Хотя по вашим другим ответам вижу, что наши мнения здесь совпадают.

>...наши мнения здесь совпадают

Да, абсолютно. Я уже где-то тут высказался по этому поводу. Что совпадают, в смысле:)

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

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

И "программа", и "данные" в ровной степени точно такая же чистая логика, как и "алгоритм". (Разница между тремя минимальна -- в том, как именно определяется понятие "времени". При высоком уровне абстракции все три сливаются в одно и то же.)

Естесственно, если язык неудобен, то он будет мешать работе; но на логику программирования он повлиять никак не может. Поэтому выбор языка программирования есть чисто эстетический выбор. (Проще говоря, кому на каком языке удобней вражаться.)

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

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

Скоро мы сблизимся во мнениях:) Поразмышляйте ещё.

Дурное дело не хитрое.

Любой язык, даже какой-нибудь недоделанный С++, представляет собой минимальный и довольно органичный набор аксиом. И нельзя сказать, что набор аксиом "С++" так уж плох -- просто те, кто этим языком ползуются, не могут их хоть как-то вменяемо применить.

В итоге получается, как в басне про мартышку и очки. Даже если заменить завтра весь С++ на Паскаль, проблема не исчезнет; такое не решается заменой марки очков.

Кроме очков и глаз нужно ещё понимать куда глядеть. Вы удивительно не хотите мыслить диалектически. Видимо, годы математического образования сказываются:). Речь не идёт просто о замене "Си" на Паскаль или Оберон. Речь идёт о преподавании искууства писания хороших программ. И о языке для такого преподавания, который был бы ориентирован на правильное исание. Можно и из языка "Си" выделить подмножество, которое будет способствовать правильному писанию. Но лучше, если язык в целом будет таким.

{+}

Но я лично вообще против "написания программ".

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

Вы правы по-крупному. Но в технике надо всё-таки писать программы. Я имею в виду программы для управляющих, боевых ЭВМ.

У меня сейчас, кажется, истерика начнется.

Сложность программирования НЕ в логике. НЕ в том, чтобы придумать и правильно записать алгоритм. Это - как раз занятие простое и интеллектуально приятное, многие готовы этим заниматься бесплатно и еще приплачивать.

Сложность - во взаимодействии с множеством подсистем, которые писали не боги, а обычные люди. "Обучение программированию", которое не учит взаимодействию с чужими глупостями и ошибками, ПРАКТИЧЕСКИ БЕСПОЛЕЗНО.

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

чтд, в общем.

Хм.

У моего комментария по крайней мере была цель. Донести некую мысль. А у вас?

Займитесь прокачкой скилла чтения на русском и не морочте людям голову, ок?

"Вдобавок" пишется слитно, а "морочьте" - с мягким знаком. Кстати, у вас есть парень? По журналу неясно - там только одна запись, и в ней ничего не написано.

Придумать алгоритм - простое занятие?
Ну-ну...

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

Придумайте алгоритмик, сравнимый хоть с одним из этой книжки (http://www.ozon.ru/context/detail/id/83808/).
Это ни чуть не проще, чем поиск ошибки в ядре FreeBSD. Правда FreeBSD - хорошо написана. С плохо написанными я сталкивался несколько меньшего объема...

Одна из моих любимых книг, кстати =)

Давайте проведу аналогию, чтобы было понятнее.

- сидеть дома за пианино и писать песни легко и приятно, гораздо легче и приятнее, чем разгребать дерьмо лопатой

- а вы напишите-ка мне "Очи черные" или что-нибудь сравнимое, тогда и посмотрим

Ядро FreeBSD - не вполне удачный пример =)

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

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

То, что Вы описали пишется через "О". Это -- ужОс!. Я бы посоветовал всё выбросить и создать снова по уму... А то получается, как Вы и говорите "дерьмо, лопата". Или даже прямо руками? :).
Искренне сочувствую. Правда.

Только это не программирование. Речь в докладе идёт о том, чтобы описанных Вами ситуаций не было вообще.

{+}

Подтверждаю. Это самый настоящий ужОс. Причем стоящий бешеных бабок, использование которых проверить почти невозможно - широкое поле для откатов.
С нуля никто переделывать не даст - уже затраченные деньги никто потерять не хочет.
Вот тут (http://www.nestor.minsk.by/sr/2004/01/40106.html) хорошо написано.

Я у себя в дневнике давал вот такую ссылку (http://www.relevancellc.com/blogs/?p=36#comment-545) на ту же тему =)

Я бы переделал. Дешевле будет, уверяю:)

Решение о переделке принимают не программисты, а менеджеры. Разделение труда. Менеджерам сложно принять такое решение - вот, например, по каким причинам.

1) У менеджмента нет оснований верить оценкам сроков/стоимости, которые дают программисты. На практике эти оценки всегда неверны, и всегда в одну и ту же сторону - но неизвестно, во сколько раз =)

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

3) Представьте, что Вы торопитесь занять новую рыночную нишу. Аналогичные аргументы.

4) Представьте, что сроки и стоимость оговорены контрактом.

5) Представьте, что нужно как можно скорее произвести впечатление на заказчика в условиях тендера.

6) После выпуска очередной версии задачи техподдержки перекладываются на программистов с более низкой зарплатой (maintenance mode), а более высокооплачиваемые (developers) переходят на следующий проект. Прямой резон не тратить зря время дорогостоящих разработчиков.

7) Переработка даже одной небольшой подсистемы может задержать развитие всего проекта, если с этой подсистемой многое взаимодействует.

И так далее.

Я всё это знаю из американской литературы по программированию 70х годов:). "Капитализм -- говно"(с)Лозунг анархистов.

{+}

Но какая-то система координации нужна, иначе мы никогда не напишем программу, которая будет больше, чем отдельная личность.

>...Но какая-то система координации нужна, иначе мы никогда не напишем программу, которая будет больше, чем отдельная личность

Собственно, в Вашей фразе -- вся суть знаменитой книги Брукса. Конечно, нужна координация. Это самое главное. Просто в старых инженерных областях всё это отработано веками. Прежде всего в строительстве (задумайтесь, например, о постройке киевской Святой Софии в X веке), кораблестроении, а потом уже в авиации, радиотехнике, ракетостроении...

Почему-то только "программисты" упорствуют в своём стремлении плодить и разгребать дерьмо:).

{+}

"Почему-то"... Когда мы построим сотню операционных систем уровня сложности, сравнимого с Windows или Linux, мы будем хорошо понимать, как построить сто первую.


Да не робей за отчизну любезную...
Вынес достаточно русский народ,
Вынес и эту дорогу железную -
Вынесет всё, что господь ни пошлет!

Вынесет всё - и широкую, ясную
Грудью дорогу проложит себе.
Жаль только - жить в эту пору прекрасную
Уж не придется - ни мне, ни тебе.

А я бы ещё пожил:) Жаль, что пора прекрасная очень далека ещё.

Невозможно выбросить - нет ресурсов для "создания снова по уму". Вы ведь не теоретик, а инженер, не можете этого не понимать.

Чтобы не было вообще - ну, хорошо бы. Просто данная ветка дискуссии началась в ответ на нелепое утверждение "приёмов программирования не существует". Они существуют, так же как и в любой человеческой деятельности существуют приёмы.

Я всё понимаю. Ресурсы, конечно, есть, но их не выделяют. Хотят мучаться. На здоровье. Именно потому, что я инженер, я бы переделал. Мне приходилось переделывать казавшееся неподъёмным. Манагер, конечно, ни за что не согласится, ясно дело. Слава КПСС, у меня нет манагеров:).

По приёмам мы с Вами полностью солидарны. Глупо отрицать их необходимость.

{+}

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

Амбивалентоность проявляете. И нашим, и Вашим... Есть-таки абсолютные истины. Надо их не стесняться.

Я имею ввиду компромисс.
"Абсолютная истина" в данном вопросе состоит в том, что нужно совмещать теорию и практику, но теория стремится быть академической, а практика - тупо прагматической. Отсюда и проблема.

remark: Всё в мире относительно (если не принимать в расчёт Бога в разных проявлениях).

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

Согласен. Причём "тупо" -- очень важное слово:)

Синтез нужен.