Почему мы до сих пор программируем с помощью плоских файлов?[закрыто]

Question

Почему плоские текстовые файлы являются самым современным средством представления исходного кода?

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

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

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

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

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

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

Так почему же не существует IDE (во всяком случае, насколько мне известно), которые позволяют вам работать с кодом таким образом?

Редактировать: 7 октября 2009 года.

Большинство из вас сильно зациклились на слове "бинарный" в моем вопросе.Я беру свои слова обратно.Представьте XML-файл, очень минимально разметив ваш код.За мгновение до того, как вы передадите его своему обычному препроцессору или компилятору, вы удаляете всю XML-разметку и передаете только исходный код.В этой форме вы по-прежнему можете выполнять все обычные действия с файлом:различайте, объединяйте, редактируйте, работайте с ними в простом и минималистичном редакторе, загружайте их в тысячи инструментов.Да, diff, merge и edit непосредственно с минимальной XML-разметкой действительно становятся немного сложнее.Но я думаю, что ценность могла бы быть огромной.

Если бы существовала IDE, которая учитывала бы весь XML, вы могли бы добавить гораздо больше того, что мы можем сделать сегодня.

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

Когда кто-то хотел провести проверку кода, например Code Collaborator, он мог пометить исходный код на месте.

XML-файл может быть даже скрыт за комментариями.

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

И затем, если вы хотите использовать vi или emacs, вы можете просто пропустить комментарии.

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

Итак, это моя приблизительная идея.Это не "строительные блоки" из картинок, которые вы перетаскиваете на экран...Я не настолько чокнутый.:)

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Но самые большие жалобы тех, кто пробует smalltalk, связаны с тем, что он не использует файлы.От большинства имеющихся у нас файловых инструментов (vim, emacs, eclipse, vs.net, инструменты unix) придется отказаться в пользу собственных инструментов smalltalk.Не то чтобы инструменты, предоставляемые в smalltalk, были хуже.Это просто по-другому.

Answer 4

Почему эссе пишутся в виде текста?Почему юридические документы написаны текстом?Почему фантастические романы пишутся текстом?Потому что текст - это единственная лучшая форма - для людей - выражения своих мыслей.

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

Answer 5

Программы на Лиспе не являются плоскими файлами.Это сериализация структур данных.Этот код как данные - старая идея, и на самом деле одна из величайших идей в информатике.

Answer 6

<?xml version="1.0" encoding="UTF-8"?><code>Плоские файлы легче читать.</code></xml>

Answer 7

И вот почему:

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

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

• Кредитное плечо.Практически все, что существует, от систем контроля версий до редакторов для фильтрации, может проверять, объединять и работать с плоскими файлами.Слияние XML может привести к беспорядку.

• Возможность довольно легко интегрировать их с инструментами UNIX, такими как grep, cut или sed.

Answer 8

Это хороший вопрос.Черт возьми, я бы с удовольствием посмотрел инструмент управления кодом в стиле Wiki.У каждого функционального подразделения была бы своя собственная вики-страница.Инструменты сборки собирают исходный код из wiki.На этой странице была бы ссылка на страницу "обсуждения", где люди могли бы поспорить об алгоритмах, API и тому подобном.

Черт возьми, было бы не так уж сложно взломать его из уже существующей вики-реализации.Есть желающие...?

Answer 9

По иронии судьбы, существуют программные конструкции, которые используют именно то, что вы описываете.

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

С другой стороны, SSIS довольно сложно контролировать с версиями.Также довольно сложно встроить в него какую-либо сложную логику:если вам нужно немного больше "контроля", вам нужно будет ввести код VB.NET код в компонент, который позволяет нам Назад к тому, с чего мы начали.

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

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

Answer 10

ИМХО, XML и двоичные форматы были бы полным беспорядком и не дали бы никакой существенной пользы.

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

Answer 11

Люди долгое время пытались создать среду редактирования, выходящую за рамки плоского файла, и все в той или иной степени потерпели неудачу.Самым близким, что я видел, был прототип для Intentional Programming Чарльза Симони, но затем его понизили до visual DSL creation tool.

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

С плоскими файлами вы получаете это бесплатно, и будет работать любой обычный старый текстовый редактор (с правильной поддержкой кодировки символов).

Answer 12

Стив Макконнелл, как всегда, прав - вы пишете программы для других программистов (включая себя), а не для компьютеров.

Тем не менее, Microsoft Visual Studio должна внутренне управлять кодом, который вы пишете, в очень структурированном формате, иначе вы не смогли бы так легко выполнять такие действия, как "Найти все ссылки" или переименовать или перефакторизовать переменные и методы.Мне было бы интересно, если бы у кого-нибудь были ссылки на то, как это работает.

Answer 13

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

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

Его компания, IntentSoft до сих пор немного умалчивается о том, что они планируют поставлять на рынок, если вообще что-нибудь, но некоторые из ранних материалов, вышедших из MSR, были довольно интересными.

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

Answer 14

Почему правят текстовые файлы?Из-за теста Макилроя.Жизненно важно, чтобы выходные данные одной программы были приемлемы в качестве исходного кода для другой, а текстовые файлы - это самая простая вещь, которая работает.

Answer 15

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

Answer 16

Вы упомянули, что мы должны использовать "некоторую форму XML"?Как вы думаете, что такое XHTML и XAML?

Кроме того, XML по-прежнему остается всего лишь плоским файлом.

Answer 17

Наверное, от старых привычек трудно избавиться.

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

В настоящее время мое любимое средство для обработки данных, которые не обязательно должны быть удобочитаемыми для человека, - это SQLite - файл и создайте базу данных.Встроить полнофункциональную базу данных SQL в любое приложение невероятно просто...существуют привязки для C, Perl, Python, PHP и т.д...и это с открытым исходным кодом, действительно быстрый, надежный и легкий.

Я <3 SQLite.

Answer 18

Кто-нибудь когда-нибудь пробовал Математика?

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

В любом случае ... сравните первое уравнение там с Математика.Интегрируем(1/(Math.Pow("x",3)-1), "x") как вам пришлось бы писать, если бы вы кодировали обычным текстом на большинстве распространенных языков.Имо, математическое представление намного легче читать, и это все еще довольно маленькое уравнение.

И да, вы можете как вводить, так и копировать-вставлять код в виде обычного текста, если хотите.

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

Answer 19

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

Только один пример:Если вы переименуете метод, ваш инструмент diff / merge / source control сможет определить, что изменилось только одно.Инструменты, которые мы используем сегодня, показали бы длинный список изменений, по одному для каждого места и файла, в котором был вызван или объявлен метод.

(Кстати, этот пост не дает ответа на вопрос, как вы, возможно, заметили)

Answer 20

Тенденция, которую мы наблюдаем в отношении DSL, - это первое, что приходит на ум при чтении вашего вопроса.Проблема заключалась в том, что не существует отношения 1 к 1 между моделями (такими как UML) и реализацией.Microsoft, среди прочих, работает над тем, чтобы вы могли создать свое приложение как нечто UML-подобное, после чего можно будет сгенерировать код.И что важно - когда вы решите изменить свой код, модель снова отразит это.

Windows Workflow Foundation - довольно хороший пример.Конечно, в фоновом режиме работают плоские файлы и / или XML, но обычно в конечном итоге вы определяете свою бизнес-логику в инструменте оркестровки.И это довольно круто!

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

Answer 21

Я с тоской задавался вопросом о том же самом, как описано в ответе на:Какой инструмент / приложение / что бы вы ни хотели, чтобы существовало?

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

Когда люди думают об альтернативах хранению исходного кода в виде текста, они, похоже, часто сразу же думают в терминах графических представлений (я имею в виду здесь коммерческие продукты, которые были доступны - например.HP-vee).И если мы посмотрим на опыт таких людей, как разработчики ПЛИС, мы увидим, что программирование (исключительно) графически просто не работает - отсюда такие языки, как Verilog и VHDL.

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

Answer 22

Visual FoxPro использует структуры таблиц dbf для хранения кода и метаданных для форм, отчетов, библиотек классов и т.д.Это двоичные файлы.Он также хранит код в prg-файлах, которые фактически являются текстовыми файлами...

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

Answer 23

Пример языка, который устраняет традиционное текстовое программирование, см. В Язык Лавы.

Еще одна замечательная вещь, которую я совсем недавно обнаружил, это подтекст2 (демонстрационное видео).

Answer 24

Код вашей программы определяет структуру, которая будет создана с помощью xml или двоичного формата.Ваш язык программирования является более прямым представлением структуры вашей программы, чем XML или двоичное представление.Вы когда-нибудь замечали, как плохо ведет себя Word по отношению к вам, когда вы придаете структуру своему документу?WordPerfect, по крайней мере, "раскроет коды", которые позволят вам увидеть, что лежит под вашим документом.Плоские файлы делают то же самое для вашей программы.

Answer 25

Отличная идея.Я сам задавался вопросом в меньшем масштабе ...гораздо меньше, почему IDE X не может сгенерировать то или иное?

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

Может быть, начать с каких-нибудь плагинов для .NET, Eclipse, Netbeans и так далее?Покажите, на что вы способны, и положите начало новому тренду в кодировании.

Answer 26

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

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

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

В связи с этим, объяснение, почему вы хотели бы использовать простой текстовый инструмент UML (Умлграф), похоже, почти в равной степени применим и к тому, почему вам нужны исходные файлы в виде обычного текста.

Answer 27

Возможно, это не совсем ответ на ваш вопрос, но вот редактор, позволяющий получить более полное представление о коде:http://webpages.charter.net/edreamleo/front.html

Answer 28

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

Конечно, вы можете различать и объединять их.Но это не означает, что инструмент diff / merge понимает четкую структуру данных, закодированных этим текстовым файлом.Вы можете выполнить diff / merge, но (особенно это видно в XML-файлах) инструмент diff не покажет вам различия корректно, то есть он покажет вам, где файлы отличаются и какие части данных инструмент "считает" одинаковыми.Но он не покажет вам различий в структуре XML-файла - он просто сопоставит строки, которые выглядят одинаково.

Независимо от того, используем ли мы двоичные файлы или текстовые файлы, всегда лучше, чтобы инструменты diff / merge заботились о структуре данных, которую представляет этот файл, а не о строках и символах.Например, для файлов C ++ или Java сообщайте, что какой-то идентификатор изменил свое имя, сообщайте, что какой-то раздел был окружен дополнительным if(){}, но, с другой стороны, игнорируйте изменения в отступах или символах EOL.Наилучшим подходом было бы, если бы файл считывался во внутренние структуры и выгружался с использованием определенных правил форматирования.Таким образом, различие будет произведено через внутренние структуры, и результат слияния будет сгенерирован на основе объединенной внутренней структуры.

Answer 29

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

Answer 30

У меня такое же видение!Я действительно хочу, чтобы это существовало.

Возможно, вы захотите взглянуть на Fortress, исследовательский язык Sun.Он имеет специальную поддержку формул в исходном коде.Приведенная ниже цитата взята из Википедии

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

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