Почему грамотное программирование не является основным направлением? [закрыто]

У грамотного программирования есть хорошие идеалы. Почему вы думаете, что это не мейнстрим? Это потому что он не смог доставить?

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

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

Кроме того, люди могут написать длинные и убедительные аргументы в пользу того, что код выполняет X, тогда как фактически выполняет Y, и я столкнулся с моей долей вводящих в заблуждение комментариев. Я разработал любовь к чтению кода, чтобы увидеть, что он делает довольно рано. Грамотное программирование является антитезой этому.

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

Это отталкивает людей от чего-то вроде cweb / noweb, потому что их использование потребует от вас изучения TeX и специфического синтаксиса программы поверх языка программирования, который вы используете для проекта. Это может быть расценено как огромная трата времени, особенно если они не нуждаются в математическом наборе текста, который является таким большим отрывом для TeX. (И для многих разработчиков приложений они действительно не нуждаются в этом.) Вместо этого они предпочитают что-то вроде XML-комментариев Visual Studio, потому что это уже популярно и устоялось.

Места, где я видел грамотное программирование, берут начало в научных / статистических вычислениях, где большинство программистов имеют значительную подготовку (или доктора наук) по математике, CS или статистике и, таким образом, уже знакомы с LaTeX. Документация, которую они пишут, скорее всего будет включать в себя множество сложных формул, которые лучше всего написаны на TeX, и они с большей вероятностью будут программировать на R. Доля программистов на R, которые знают о SWeave, определенно намного выше, чем, скажем, доля программистов на C, которые знают о cweb.

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

Система Literate Programming, разработанная Кнутом, сделала многое, гораздо больше, чем сразу бросается в глаза, а именно она преодолела многие недостатки в базовом языке программирования, который инструмент генерирования кода сгенерировал из исходного документа Knuths, а именно стандартного Pascal.

Для тех, кому посчастливилось не попробовать Стандартный Паскаль, вот некоторые из основных моментов.

• Чтобы упростить использование однопроходного компилятора, в спецификации языка сказано, что все объявления должны быть в определенном порядке. Со страницы википедии: «Каждая процедура или функция может иметь свои собственные объявления меток, констант, типов, переменных и других процедур и функций goto, которые должны быть в таком порядке». Это означало, что вы не могли логически сгруппировать ваши вещи в исходном файле.
• Работа со строками была более утомительной, чем в простой C.
• Идентификаторы не могут иметь произвольную длину.
• Еще много вещей, которые я не могу вспомнить.

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

Большинство современных языков могут делать эти вещи без особых усилий, поэтому удаляют БОЛЬШУЮ часть работы, которую должно было решить грамотное программирование.

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

Итак, что осталось? Возможность генерировать набранную форму документации из исходного кода, и ЭТО существует сегодня.

Подумайте только о JavaDoc - API времени выполнения Java, пожалуй, самый большой элемент грамотного программирования, доступный сегодня (за исключением того, что код фактически не представлен, но он МОЖЕТ быть, если бы Java была с открытым исходным кодом с самого начала). Смотрите, например, презентацию структуры коллекций на http://download.oracle.com/javase/6/docs/api/java/util/Collection.html

Я считаю, что подобные системы существуют для .NET и других основных программ.

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

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

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

Кодеры пишут код не на английском.

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

Кодеры не умеют писать документацию, потому что это плохая среда для выражения своих идей.

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

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

Люди воспринимают ЛП как: (а) метод документации (б) метод написания полированных эссе, требующий особых навыков или талантов (в) просто не имеют понятия - как создатель редактора программ Лео, по его собственному признанию и тд и тп

LP, однако, это просто: (1) написание программ на смеси кода и фраз на (= любом) человеческом языке, где последние обозначают другие фрагменты кода и / или включенные фразы. Это именно то, что делают авторы бесчисленных учебников по программированию ... и (2) это простой препроцессор, который расширяет эти фразы в человеке (которые стали как бы именами включенных подпрограмм), чтобы раскрыть результат В ПОРЯДКЕ, ТРЕБУЕМОМ КОМПИЛЕРОМ (или переводчика). В противном случае можно расширить письменный текст другой небольшой утилитой, включив символы форматирования, чтобы превратить «грамотный источник» в красивый хорошо отформатированный читаемый текст.

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

В основном основная идея программирования «в псевдокоде» написана на человеческом языке, а затем расширена с помощью простой утилиты препроцессора ПОМОГАЕТ ВНИМАНИЕ УПРАВЛЕНИЯ (ограниченная, основная трудность для любой длинной программы), почти как свертывание кода или разделение потока вашей программы. в функции / подпрограммы, необходимые для того, чтобы вы не теряли себя в деталях, но совершенно не нужны для выполнения машины.

Есть 2 аспекты грамотного программирования , что я бы желание были включены в основное русло программирования - встроенные изображения (например, проектирование диаграммы) и указатели на предыдущие и альтернативные попытки (например, «Причина это так, потому что я попробовал этот другой путь и это не сработало, потому что ... "). Оба эти аспекта могут быть обработаны с помощью doc-комментариев и URI.

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

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

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

В заключение: мой Java-код сам по себе более грамотный, каким хочет быть любое «грамотное» программирование.

Я пришел к грамотному программированию с другой стороны - я мечтал о том, чтобы код был организован так, как ему удобно, а не так, как того требует компилятор. Я нашел Лео почти идеальным для этой цели. Он также поддерживает отслеживание файлов, измененных снаружи. Эти файлы не должны содержать какой-либо специальной разметки, поэтому я могу использовать Leo для себя без необходимости знать об этом других в команде. Эта функция - "@shadow trees" - очень многообещающая, хотя все еще немного ошибочная, требует большего количества глазных яблок. И это также устраняет проблему «о, нет, все в одном большом файле» как путем организации всего в виде дерева, так и путем поддержки внешних файлов.

Для меня, вопреки названию, «грамотное программирование» вообще не касается документации. У меня нет больше документации, чем раньше. Речь идет о структуре, которая помогает мне не потеряться . Я клянусь им особенно, когда управляю огромными JSP-файлами (и что, несмотря на то, что Leo изначально предназначался в первую очередь для Python и не поддерживает язык JSP - я должен разделить файл на дерево Leo вручную!).

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

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

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