Search in topic

Как вы считаете, что будет с программированием в недалеком-далеком будущем?

“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.

Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.

МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять? У CIO на это в сутках есть максимум 30%, а у них 100%. И их на порядок больше.
Итог - задача нерешаема.

МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять?

1. не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))

2. “перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.

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

Гораздо правильнее - принять как данность, что вы (не зависимо от опыта и заслуг) - не самый крутой программист (пока общественность не потребует вас предъявить свой крутой код 😈). И сконцентрировать внимание на работе, на достижениях конкретных поставленных целей 😃

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

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

… от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”.

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

…можно специально сделать обычный код практически нечитаемым, например, в целях защиты…

Это называется обфускация, если вы вдруг не знали 😃
Как и многие другие методы “защиты”, помогает лишь условно. От китайских ре-инженеров ничего не спасает 😃

На самом деле - это соответствие уровня кода - решаемой задаче.

ничего подобного. Вы опять не поняли.
Мы на разных языках что ли говорим?

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

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

Это называется обфускация, если вы вдруг не знали

ну почему ж не знал? Сам делал обфускаторы, которыми даже другие пользовались ))
В частности, для незабвенной платформы 1С был у меня обфускатор под названием “Кирпичный заводик”. Ставший, кстати, потом очень популярным в народе ))
Код такими кирпичами укладывал - хрен прочитаешь.

1. не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))

2. “перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.

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

вспомнилось: в литературе почти не описывается один редко встречающийся (в силу своей сложности), но изощренный вид обфускации. Он применим только к процессорам, имеющим команды переменной (разной) длины. Суть его в том, что переход может осуществляться не на начало команды, а на её середину, что, в свою очередь приводит к выполнению совершенно другой команды, код которой является операндом “правильной” команды. В эпоху ЕС ЭВМ мы иногда баловались этим, тем более, что мой собственный дисассемблер раскладывал код на три параллельных цепочки именно с учетом такой возможности.

Технология выглядела так:

1. на ассемблере писался обычный кусок кода, который стандартным образом собирался в объектный код

2. по объектному коду проходились 3-х цепочечным дисассемблером и отыскивали в нем вторичные и третичные более или менее осмысленные куски

3. исходный код слегка модифицировался так, чтобы эти куски реально что-то делали и имели выход (передачу управления) в обычный “первичный” код

На неподготовленные умы результат всегда производил очень сильное впечатление ))

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

1. речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)

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

3. для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))

использовать конструкции “for” или “while” - это его личное дело.

Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать 😃

…большое количество “goto” сразу вызывает сомнения ))

Одно единственное “goto” - вызывает сомнения 😃

Не всегда. Если это цикл поиска (единственного элемента) по массиву - за for можно сразу пинка под зад отвешивать

не принципиально, т.к. оптимизировать всё равно будет компайлер ))

Одно единственное “goto” - вызывает сомнения

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

Загнать цикл - в функцию, вываливаться через return 😃

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

Загнать цикл - в функцию, вываливаться через return

тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”. Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.
К тому же, вывалиться совсем наружу - это частный случай. Может понадобиться вывалиться в один из внешних вложенных. Об этом я и написал до того, как заметил опечатку.

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

Андрей, я вот из цикла про баранов вывалился.😃
Или вывалили…

Андрей, я вот из цикла про баранов вывалился

да, с баранами и дворниками (на лобовом стекле?) там было мощно задвинуто…
Еще б немного - и в бесконечный цикл впало )))

мощно задвинуто…

тут у Вас опечаточка, которую я сначала не заметил: не “цикл”, а “все вложенные циклы”.

Да, имелось ввиду это самое. 😃

Тогда действительно можно вывалиться через return. Но можно и огрести проблемы с параметрами, если их много. Однозначного решения нет и goto остаётся допустимым.

На самом деле тут ситуация несколько тоньше и глубже: если внезапно получается аномальное нагромождение вложенных циклов (аналогично - с большим нагромождением вложенных условий) - то примерно в ~70% случаев стоит задуматься о целесообразности реализуемого таким способом алгоритма. Чтобы в итоге раскидать эту кучу на несколько последовательных или даже вовсе не связанных блоков.
И это бывает в самых разных конкретных задачах.

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

да не надо “аномально”…
Достаточно иметь всего 4 вложенных цикла и выход из самого внутреннего внутрь внешнего. Потребуются либо if c дополнительной переменной и break, либо goto. Самый тривиальный пример.

1. речь идет не об “описании”, а о самодокументировании кода. Это совсем другое. (Хотя, общее описание, конечно, тоже нужно)

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

3. для проверки работы кода существует альфа и бета-тестирование. Если его результаты удовлетворительны при условии, что исходники оформлены в соответствии с требованиями и не вызывают вопросов - код принимается. При этом, не так важно, предпочитает программист использовать конструкции “for” или “while” - это его личное дело. Но, например, большое количество “goto” сразу вызывает сомнения ))

Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.
Ни альфа, ни бета тестирование это не выявят, если это не будет у программера в бошке зашито.
Давно это было, но на заре становления посещал Индийские софтверные гиганты с уровнем 6 сигм по многим классификациям. Так вот, чтобы добиться 6-ки, на одного ишачка кодера, приходилось до 4 проверяющих его код. И это только проверяющих именно код.
А была куча просто сотрудников, которые подготавливали “почву” для кодера, ну и потом все, согласно жизненного цикла.
И это в Индии - откуда ноги берёт добрые 70% именно говнокода.

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

Львиная доля говнокода вытекает от: не предусмотрел, забыл, переполнил и забыл обнулить, забыл предусмотреть и т.п.

Так это целая наука. Грамотно спланировать структуру проекта, чтобы не пришлось ни в одной месте не вставлять потом костыли (т.е. чтобы структура сразу учитывала ВСЕ, что потом будет в проекте), а после этого грамотного планирования (с первого раза никогда не получается, особенно если задача - нова для программиста) - попробовать сделать невероятное: обеспечить вменяемые сроки разработки этого грамотно структурированного монстра 😈
Умные могут сказать: учите паттерны проектирования и т.д., но без конкретного практического опыта толку от этого будет не много. Пока сам лично как следует не влипнешь по колено - не поймешь.

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