Почему теория по программированию пренебрегает вторым этапом?

Для этого обычно используют блок-схемы.

К чему такое строгое разделение на этапы?

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

Для тебя, то как мне ответил DeepSeek:

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

### Ваши этапы:  
1. **Идея/задача** — что должна делать программа.  
2. **Реализация на естественном языке** — описание логики без привязки к синтаксису.  
3. **Псевдокод/уточнение** — приближение к коду, но ещё без строгого синтаксиса.  
4. **Написание кода** — окончательная реализация на языке программирования.  

Это напоминает **метод "шаг за шагом" (stepwise refinement)** или **"сверху вниз" (top-down design)**, где задача постепенно уточняется.  

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

### Пример вашего подхода:  
#### **1. Идея**  
*"Найти сотрудника с минимальной зарплатой в массиве структур."*  

#### **2. Реализация на естественном языке**  
- Предположим, что зарплата минимальна у первого сотрудника.  
- Пройдём по всем сотрудникам, начиная со второго.  
- Если у текущего сотрудника зарплата меньше, чем у предполагаемого минимального, обновляем минимального.  
- В конце выводим данные найденного сотрудника.  

#### **3. Псевдокод (уточнение)**  

minIndex = 0  
для i от 1 до длины массива:  
    если сотрудник[i].зарплата < сотрудник[minIndex].зарплата:  
        minIndex = i  
вывести сотрудник[minIndex]  


#### **4. Реальный код (например, на C++)**  

int minIndex = 0;
for (int i = 1; i < employees.size(); i++) {
    if (employees[i].salary < employees[minIndex].salary) {
        minIndex = i;
    }
}
cout << "Min salary: " << employees[minIndex].name << endl;


### Вывод  
Ваш подход — это **правильный и системный способ разработки**, особенно для сложных задач. Многие пропускают 2-й и 3-й этапы, сразу начиная писать код, что иногда приводит к ошибкам или неоптимальным решениям.  

Если хотите формализовать этот процесс ещё больше, можно использовать:  
- **UML-диаграммы** (для ООП),  
- **Блок-схемы**,  
- **TDD (Test-Driven Development)** — где сначала пишутся тесты, а потом код.  

Спасибо, что поделились этой мыслью! Это ценный принцип, который стоит применять осознанно. 🚀

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

Снижает когнитивную нагрузку — не нужно сразу думать о синтаксисе.

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

Уменьшает ошибки — сначала продумывается логика, потом код.

Ошибки невозможно уменьшить, они либо есть, либо их нет. На каком этапе ты сможешь выявить эти ошибки — не важно, главное не затягивать.

Упрощает рефакторинг — если логика ясна, менять код легче.

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

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

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

Помогает в командной работе — другие разработчики быстрее поймут замысел.

Чтение чужого кода — это норма нашей профессии, которая случается ежедневно и ежечасно.

TDD (Test-Driven Development) — где сначала пишутся тесты, а потом код.

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

Тесты — это, кстати, не только промежуточный этап, но и часть окончательного решения.

Если первый этап — это идея, задача, или что должна делать программа.

Технические требования

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

ТЗ

А всё остальное это уже реализация.

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

А нормально сразу C++ изучать? Я не интересант, поэтому у меня впечатление, что раз интереса нет, значит, все дороги перекрыты и ничего уметь нельзя. Меня как студента удовлетворяет не предлагаемый способ выполнения работы, а поэтапный — так, я могу уделить 2 часа на работу, получив результат и забыть про неё. Без траты времени на метод проб и ошибок, без интересантства; тем не менее в голове откладывается.

Я лично считаю, что C++ ненормально сразу учить. Это язык, который позволяет одновременно писать код на высоком уровне и быть эффективным — очень необычное, достойное сочетание, но за которое мы платим чрезмерной своеобразностью языка. Но преподаватель может уменьшить разрыв между общим курсом и особенностями языка, объясняя последнее более доступным образом, не вдаваясь в особенности, применимые только к самому языку.

Вот здесь хороший анализ того, каким должен быть вводный язык (секция 2, REQUIREMENTS): http://shodor.org/media/content//jocse/volume6/issue1/Ballesteros_2015.pdf

Я не интересант, поэтому у меня впечатление, что раз интереса нет, значит, все дороги перекрыты и ничего уметь нельзя.

Потом просто перейдёшь на другой язык.

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

Потому что в какой-то момент становится проще сразу на ЯП писать чем вот эти вот буковки на естественном языке фигачить.

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

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

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

не в 3, а в 5-10, если опыта менее 10 лет

А ты про псевдокод… Да кому он нужен… Я думал ты про описание алгоритма, формальные требования. UML тоже никто не рисует. Меня раз какой-то дебил попросил UML нарисовать на собеседовании, я его послал… Там просто лестницу из switch/case и тп замучаешься рисовать… Но мы в детстве рисовали блок-схемы на информатике… Очень «полезно»

Dilbert Comic Strip on 1995-11-09.

А нормально сразу C++ изучать?

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

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

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

на любых сегодняшних языках можно писать
не думая

Что мы и наблюдаем в результате.

Потому что одни люди генерируют идеи и алгоритмы, а другие учитывают синтаксис и семантику. В последнее время учитывают синтаксис и семантику уже и не люди, но хотя и до того спорно лол

первый этап — это идея, задача, или что должна делать программа

ТЗ, то есть. Тут уже в той или иной степени есть «как». Либо в самом ТЗ, либо опосредованно в предметной области. Инноваций непосредственно в программистской деятельности немного.

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

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

на третьем этапе, мы будем писать естественным языком код (псевдокод)

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

который впоследствии напишем на языке программирования, на 4 этапе.

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

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

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

Но мы в детстве рисовали блок-схемы на информатике… Очень «полезно»

Не всем легко ифзенами и вайлами в текстовой форме оперировать. Такие, впрочем, сдали лабораторку и забыли, а в программирование не идут.

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

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

Зачем? Это сложнее, чем написать на ЯП. То есть, это не просто лишний этап, это этап, который занимает по времени и силам больше, чем все остальные вместе взятые.

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

Строгий синтаксис не усложняет, а упрощает написание. Его отсутствие не снижает, а увеличивает когнитивную нагрузку.

Я читал «Логику» Аристотеля. Крутой мужик, но, поскольку он оперировал естественным языком, получилось длинное, неудобочитаемое, поверхностное и весьма неполное полено.

Язык программирования чаще выразительнее чем общий язык, и сразу дает проверяемое, возможно формальное описание, если начинать с контрактов верхнего уровня. Неэффективность блок-схем поняли еще в 60х, и воскресили только для CASE, но он тоже провалился.

Даже твой пример отображает, что человеческое описание не дает дополнительной информации, и длиннее.

Причем чем сложнее, тем значительнее:

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

vs

set<Employee, SalaryCmp>

Как ты себе это представляешь? Вот, стоит задача написать утилиту форматирования винчестера. И ты такой "Пересылаем байт из переменной А в порт Б. В регистр АХ заносим значение переменной С, в регистр BX - значение переменной D. Складываем. Результат в регистре DX сдвигаем на 4 бита влево "

Я имел ввиду общение. Но, в целом, аналогия так себе.

Потому что есть работа с требованиями, а есть имплементация. И нет одного правильного способа. А этот твой «второй этап» — либо попытка микроменеджмента из 10-х годов («команда профессионалов»(тм): менеджер + джуны за еду"), либо «не нужен» (с)

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

Для этого обычно используют блок-схемы.

На самом деле ТС изобрёл литературное программирование. Но оно тоже как-то не взлетело.

Ну, в случае общения иногда тоже желательно сначала подумать.

«не думая», это я наблюдаю во всех твоих постах. дело не в языке, а в человеке.

UML?

Сорри, не могу сдержаться

Не знаю как теория, а я вполне порой так делаю. Перед кодом пишу комментарии в духе «сделать А», «сделать Б», «сделать В, если Г» и только потом, когда поток исполнения ясен уже заменяю их кодом. И более конкретными комментариями.

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

Вот тебе задача на естественном языке: забанься.

Например, на втором этапе пишем: «предположим, что зарплата минимальна у первого сотрудника по массиву структуры…», когда как на третьем этапе будем писать: «целочисленный тип минИндекс равен нулю», а на четвёртом «int minIndex = 0;».

Это называется «требования». В остальном польза от написания кода на Go текстом на русском не очень ясна.

И правильно делаешь.

У опытных программистов вторый этап происходит прямо в голове.

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

на втором этапе пишем: «предположим, что зарплата минимальна у первого сотрудника по массиву структуры…»

m = find_min(users)
if m == 0:
    pass

И чем это отличается от того, что ты сказал?

я про декомпозицию конкретной задачи которую делает один человек, а не про проект целикм.

предположим, что зарплата минимальна у первого сотрудника по массиву структуры…

Массивы, структуры, индексы - это уже запись с учетом семантики языка. Вообще получается что ты одну и ту же вещь будешь записывать три раза, на разных языках. Для кого? Для других коллег, которые тоже умеют читать конечный язык? А что делать через год, когда останется только код? Так что надо писать код, который легко читается.

А так это графомания какая-то.

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

Снижает когнитивную нагрузку — не нужно сразу думать о синтаксисе.

А мы и не думаем о синтаксисе, мы думаем сразу В синтаксисе.

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

Ах, ну и да. Когда я студентом много писал на Ассемблере, мне и на Ассемблере для x86 сны снились.

так оно и есть.

поэтому писать логику программы на «естественном» языке нет особого смысла. и тут сразу возникает вопрос: на каком именно языке писать? потому что структура и логика у разных языков разная. даже способы выражения одних и тех же идей могут зависеть от особенностей «естественного» языка. значит ли это, что программист с родным английским думает как-то иначе, чем программист с родным русским? и что они друг друга не поймут? отнюдь. программирование лишено сложностей реальных языков и просто отражает логику действий. а она едина и понятна для всех, как математика.

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

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

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