Алгоритм изучения ЯП

Попробуйте изучить нотную грамоту и синтаксис табулатуры - это самое простое в музыке))

это как-то противоречит словам Urban Nomad?

Мне кажется да. Потому что очевидные вещи для одного человека не очевидны для другого.
Синтаксис в изучении сложен. Например в Go много способов объявления и определения переменных - как объяснить для чего так сделано и зачем вообще оно надо? - риторический вопрос

Синтаксис - это всего лишь способ выражения мысли. Если нет мысли - никакой синтаксис не поможет.

С чего вообще разработка начинается?
Вот есть задача - обработать 40млн записей (отобранных по ряду условий). Ок. Сразу думаем - "40млн в один поток многовато - долго будет, раскидаем на 10 заданий". Это значит что делаем головное задание, которое запускать 10 фоновых заданий-обработчиков. Затем делает выборку того, что подлежит обработке, упаковывает в пакеты (ну, скажем, по 100 элементов) и выкладывает на конвейер. Обработчики берут пакет с конвейера и обрабатывают.
Дальше смотрим - ага, конвейер на это платформе можно реализовать на очереди, пайпе, юникссокете. Дальше смотрим как проще/удобнее.
Затем думаем - ага, пайпы это низкоуровневое, его проще на С/С++ сделать (или готовое что-то подцепить). А вот для бизнес-логики лучше другой язык, более подходящий, использовать.
Дальше больше. Процедуру отбора в головной задаче лучше на скуле сделать (встроенном) - запрос будет готовиться один раз, потом пойдет массовая выборка. А вот внутри обработчика нам нужно какие-то записи из таблицы дергать. Там уже одна таблица - одна запись по уникальному ключу. Тут скуль излишне использовать - он ресурсов много жрет и требует времени на подготовку запроса, это проще и быстрее делать прямым доступом к таблице.
Вот примерно так должен думать разработчик...
Язык тут достаточно фрагментарно присутствует. Больше алгоритмизация.

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

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

Что-то я задумался... Тема конечно очень интересная и ее бы обсудить за кружкой "чая" ))
Наверное синтаксис и алгоритмы, логику, следует изучать совместно, потому как не имеет смысла разрисовывать схемы не имея возможности их тут же описать программно

А сложные напрочь отбивают желание заниматься программированием

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

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

Ну для сортировки пузырьком malloc не нужен - там могут быть и статические массивы

А строки - они разные бывают. Я вот сейчас пишу на С/С++ (меньше, только низкоуровневые вещи) и RPG (бизнес-логика).

Так вот в С строки null-terminated, а в RPG их два типа - обычный char заданной длины ("пустая" строка забивается пробелами, если размер содержимого меньше объявленного размера строки, "хвост" забивается пробелами) и varchar который по факту есть структура - первый элемент - 2 (или 4 в зависимости от того как объявишь) байта длины, затем собственно строка (массив байт)...

И вот это все сразу учить? А еще учить что у строки опционально может быть объявлен CCSID? И что если вы для строки объявили CCSID(*utf8), то при присвоении ей чего-либо оно автоматически конвертируется в UTF8 (это еще ладно - может быть CCSID(*hex) - там вообще оно превращается в 16-чное представление).

Такие вещи только запутают окончательно неокрепший мозг...
Не говоря уже о более тонких вещах типа разницы между clear и reset для переменной... Или вот таких фишках:

dcl-s str1 char(10) inz('0123456789');
dcl-s str2 char(5);
dcl-s str3 char(5);

str2 = str1;
eval-r str3 = str1;

после чего str2 = '01234', а str3 = '56789' :)

Кстати, после clear str1 она будет пустой (забита пробелами), а после reset str1 вернется к значению инициализации - 0123456789

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

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

Потому что, например, есть некая UDTF, которая возвращает строку с трех представлениях - as is, в кодировке utf8 и в виде hex строки. На С там придется писать всю эту конвертацию руками (ну или библиотеку какую подтягивать), а в RPG все есть:

dcl-s Data char(64000);
dcl-s DataUTF8 char(64000) ccsid(1208);
dcl-s DataHEX char(64000) ccsid(*hex);

DataUTF8 = Data;
DataHEX = Data;

и все!

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

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

Причем, на С (а потом С++) я пишу с 90-го года примерно. А с 17-го, со сменой работы, еще RPG освоил. И не могу сказать какой из них мне нравится больше - и там и там есть свои плюсы и минусы. С лаконичнее, зато в RPG намного мощнее описание структур данных - явное позиционирование полей внутри структуры, возможность частичного или полного перекрытия полей, инициализация полей в описании...
Зато в С намного проще с указателями работать... Ну и так далее...

Но все равно в основе всего умение думать алгоритмически. А это не то чтобы написать ту же сортировку пузырьком на каком-то языке, а просто "видеть" в голове как оно работает. Не просто реализовать дерево или список, а сразу себе в голове представлять как оно выглядит.
Это, чему надо в первую очередь учить. И, кстати, на техсобесе всегда, если прошу что-то реализовать, то никогда не привязываюсь к языку, всегда прошу на словах (ну или на бумажке эскизно) как это будет реализовываться, на что внимание обратить и т.п.

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

Что-то я не пойму проблему с utf8 на Си... UTF8 это же просто 8ми битное число.
Разъясни пожалуйста)
20 лет на Си не писал, да и не видел его. Очень любопытно)