Почему мы все еще программируем с плоскими файлами?

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

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

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

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

Еще одна идея - вставлять комментарии из обзоров кода прямо в код.

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

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

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

EDIT: 7 октября 2009 года.

Большинство из вас очень сильно повесили слово "двоичный" в моем вопросе. Я убираю его. Picture XML, очень минимально маркирующий ваш код. Перед тем, как передать его обычным препроцессорам или компилятору, вы удалите всю разметку XML и передайте только исходный код. В этой форме вы все равно можете делать все нормальные вещи в файле: diff, merge, редактировать, работать в простом и минимальном редакторе, загружать их в тысячи инструментов. Да, 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, вы можете просто пропустить комментарии.

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

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

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

Вот почему:

Чтение человеком. Это значительно облегчает обнаружение ошибки, как в файле, так и в методе анализа. Также можно прочитать вслух. Тот, который вы просто не можете получить с XML, и может иметь значение, особенно в поддержке клиентов.
Страхование от устаревания. Пока существует регулярное выражение, можно написать довольно хороший парсер только в нескольких строках кода.
Рычаги. Почти все, что есть, от систем контроля версий до редакторов для фильтрации, может проверять, объединять и работать с плоскими файлами. Слияние XML может быть беспорядком.
Возможность легко интегрировать их с инструментами UNIX, такими как grep, cut или sed.

Ответ 8

Это хороший вопрос. FWIW, мне бы хотелось увидеть инструмент управления кодом в стиле Wiki. Каждый функциональный блок будет иметь свою собственную страницу вики. Инструменты сборки объединяют исходный код из вики. Будет страница обсуждения, связанная с этой страницей, где люди могут спорить об алгоритмах, API и т.д.

Черт, было бы трудно взломать один из ранее существовавшей реализации Wiki. Любые участники...?

Ответ 9

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

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

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

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

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

Ответ 10

IMHO, XML и бинарные форматы были бы полным беспорядком и не принесли бы никакой существенной выгоды.

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

Ответ 11

Люди долгое время пытались создать среду редактирования, которая выходит за рамки плоского файла, и все в некоторой степени потерпели неудачу. Ближайший, который я видел, был прототипом для преднамеренного программирования Чарльза Симони, но затем он был понижен до визуального инструмента создания DSL.

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

Ответ 14

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

Ответ 15

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

Также XML по-прежнему является просто плоским файлом.

Ответ 16

Старые привычки умирают, думаю.

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

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

I < 3 SQLite.

Ответ 17

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

Ответ 18

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

Пик выше - это старая версия, но это лучший инструмент для Google.

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

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

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

Ответ 19

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

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

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

Ответ 20

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

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

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

Ответ 21

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

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

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

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

Ответ 22

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

Еще одна замечательная вещь, которую я недавно обнаружил, - subtext2 (видео демо).

Ответ 23

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

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

Ответ 24

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

Ответ 25

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

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

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

Ответ 26

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

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

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

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

Ответ 27

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

Ответ 28

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

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

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

Ответ 29

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

Ответ 30

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

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

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

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