Почему мы все еще программируем с плоскими файлами? [закрытый]
почему плоские текстовые файлы-это современное состояние для представления исходного кода?
конечно-препроцессор и компилятор должны видеть плоское файловое представление файла, но это легко создать.
Мне кажется, что некоторая форма XML или двоичных данных может представлять множество идей, которые очень трудно отслеживать, в противном случае.
например, вы можете вставлять UML-диаграммы прямо в свой код. Они смогли быть произведены полуавтоматно, и аннотируется разработчиками, чтобы выделить важные аспекты дизайна. В частности, диаграммы взаимодействия. Черт, встраивание любого пользовательского рисунка может сделать вещи более ясными.
другая идея заключается в том, чтобы вставлять комментарии из обзоров кода прямо в код.
могут быть всевозможные средства для облегчения слияния нескольких ветвей.
то, что я увлечен, - это не только отслеживание покрытия кода, но и просмотр частей кода, покрытых автоматизированный тест. Трудная часть-отслеживать этот код, даже при изменении источника. Например, функция из одного файла в другой и т. д. Это можно сделать с помощью GUID, но они довольно навязчивы для вставки прямо в текстовый файл. В богатом формате они могут быть автоматическими и ненавязчивыми.
Итак, почему нет IDEs (насколько мне известно, во всяком случае), которые позволяют вам работать с кодом таким образом?
EDIT: 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, вы можете просто пропустить комментарии.
Если я хочу использовать современный редактор, я вижу это примерно дюжиной различных полезных способов.
Итак, это моя приблизительная идея. Это не "строительные блоки" изображений, которые вы перетаскиваете на экран... Я не настолько спятил. :)
30 ответов
- вы можете отличить их
- вы можете объединить их
- любой может редактировать
- они просты и легки для того чтобы общаться с
- они универсально доступны для тысяч инструментов
на мой взгляд, любые возможные преимущества перевешиваются привязкой к определенному инструменту.
с текстовым источником (это, кажется, то, что вы обсуждаете, а не плоские файлы per se) я могу вставлять куски в электронную почту, использовать простые системы контроля версий (очень важно!), пишите код в комментарии на переполнение стека, используйте один из тысячи текстовых редакторов на любом количестве площадок и т. д.
с некоторым двоичным представлением кода мне нужно использовать специализированный редактор для просмотра и редактирования. Даже если текстовое представление может быть создано, вы не можете тривиально откатывать изменения в каноническую версию.
Smalltalk-это среда на основе изображений. Вы больше не работаете с кодом в файле на диске. Вы работаете с реальными объектами и изменяете их во время выполнения. Это все еще текст, но классы не хранятся в удобочитаемых файлах. Вместо этого вся память объекта (изображение) хранится в файле в двоичном формате.
но самые большие жалобы тех, кто пытается smalltalk, потому что он не использует файлы. Большинство файловых инструментов, которые у нас есть (vim, emacs, eclipse, vs.net, Unix tools) придется отказаться в пользу собственных инструментов smalltalk. Не то чтобы инструменты, предоставляемые в smalltalk, уступали. Просто все по-другому.
Почему эссе написаны в тексте? Почему юридические документы написаны в тексте? Почему фантастические романы написаны в тексте? Потому что текст-это единственная лучшая форма - для людей-настаивания на своих мыслях.
текст-это то, как люди думают, представляют, понимают и упорствуют концепции
программы Lisp не являются плоскими файлами. Это сериализация структур данных. Этот код как данные-старая идея, и на самом деле одна из величайших идей в информатике.
вот почему:
удобочитаемое. Это значительно упрощает обнаружение ошибки как в файле, так и в методе синтаксического анализа. Также можно прочитать вслух. Это тот, который вы просто не можете получить с XML, и может иметь значение, особенно в поддержке клиентов.
страхование от устаревания. Пока существует регулярное выражение, можно написать хороший парсер в несколько строк кода.
кредитное плечо. Почти все, что есть, от систем контроля версий до редакторов для фильтрации, может проверять, объединять и работать с плоскими файлами. Слияние XML может быть беспорядком.
возможность довольно легко интегрировать их с инструментами UNIX, такими как grep, cut или sed.
Это хороший вопрос. FWIW, я бы хотел увидеть инструмент управления кодом в стиле Wiki. Каждый функциональный блок будет иметь свою собственную страницу wiki. Инструменты сборки объединяют исходный код из wiki. На этой странице будет" обсуждаться " страница, связанная с этой страницей, где люди могут спорить об алгоритмах, API и тому подобное.
черт, было бы не так сложно взломать один из ранее существовавшей реализации Wiki. Любые согласные...?
по иронии судьбы есть программные конструкции, которые используют именно то, что вы описываете.
например, службы SQL Server Integration Services, которые включают поток логики кодирования путем перетаскивания компонентов в визуальную область разработки, сохраняются в виде XML-файлов, описывающих именно эту обратную сторону.
с другой стороны SSIS довольно сложно контролировать источник. Также довольно сложно разработать какую-либо сложную логику: если вам нужно немного больше "контроля", вы будете нужно кодировать VB.NET код в компонент, который приносит нам назад туда, где мы начали.
Я думаю, что, как программист, вы должны учитывать тот факт, что для каждого решения проблемы, есть последствия, которые следуют. Не все может (а некоторые утверждают, должно) быть представлено в UML. Не все можно было изобразить визуально. Не все может быть достаточно упрощено, чтобы иметь последовательное двоичное представление файла.
Это, как говорится, я бы предположим, что недостатки отнесения кода к двоичным форматам (большинство из которых также, как правило, являются собственностью) намного перевешивают преимущества их наличия в обычном тексте.
IMHO, XML и двоичные форматы были бы полным беспорядком и не дали бы никакой значительной выгоды.
OTOH, связанной идеей было бы записать в базу данных, возможно, одну функцию на запись или, возможно, иерархическую структуру. IDE, созданная вокруг этой концепции, может сделать навигацию по источнику более естественной и проще скрыть что-либо, не относящееся к коду, который Вы читаете в данный момент.
люди долгое время пытались создать среду редактирования, которая выходит за рамки плоского файла, и все в какой-то степени потерпели неудачу. Ближе всего я видел прототип преднамеренного программирования Чарльза Симони, но затем он был понижен до визуального инструмента создания DSL.
независимо от того, как код хранится или представлен в памяти, в конце концов он должен быть презентабельным и изменяемым как текст (без изменения форматирования на вас) так вот самый простой способ выразить большинство абстрактных понятий, необходимых для решения задач с помощью программирования.
с плоскими файлами вы получаете это бесплатно, и любой простой старый текстовый редактор (с правильной поддержкой кодировки символов) будет работать.
Стив Макконнелл прав, как всегда-вы пишете программы для других программистов (включая себя), а не для компьютеров.
тем не менее, Microsoft Visual Studio должна внутренне управлять кодом, который вы пишете в очень структурированном формате, или вы не сможете делать такие вещи, как "найти все ссылки" или переименовать или перефакторные переменные и методы так легко. Мне было бы интересно, есть ли у кого-нибудь ссылки на то, как это работает.
на самом деле, примерно 10 лет назад, ранний прототип Чарльза Симони для преднамеренного программирования попытался выйти за пределы плоского файла в древовидное представление кода, которое можно визуализировать по-разному. Теоретически эксперт по домену, PM и инженер-программист могли видеть (и соединять) код приложения способами, которые были им полезны, а продукты могли быть построены на иерархии декларативных "намерений", копаясь до низкоуровневого кода только как необходимый.
ETA (по запросу в вопросах) есть копия одна из его ранних работ об этом на веб-сайте Microsoft research. К сожалению, поскольку Simonyi покинул MS, чтобы начать отдельную компанию несколько лет назад, я не думаю, что прототип все еще доступен для загрузки. Я видел несколько демонстраций, когда был в Microsoft, но я не уверен, насколько широко был распространен его ранний прототип.
его компании, IntentSoft еще немного тихо о том, что они планируют доставить на рынок, если что, но некоторые из ранних вещей, которые вышли из MSR, были довольно интересными.
модель хранения была некоторым двоичным форматом, но я не уверен, сколько из этих деталей было раскрыто во время проекта MSR, и я уверен, что некоторые вещи изменились с ранних реализаций.
Labview и Simulink две графические среды программирования. Они оба популярны в своих областях (сопряжение с аппаратным обеспечением с ПК и моделирование систем управления, соответственно), но не используются много за пределами этих областей. Я работал с людьми, которые были большими поклонниками обоих, но никогда не попадал в них сам.
вы упомянули, что мы должны использовать "некоторую форму XML"? Как вы думаете, что такое XHTML и XAML?
также XML по-прежнему является просто плоским файлом.
старые привычки умирают трудно, я думаю.
до недавнего времени не было много качественных, высокопроизводительных, широко доступных библиотек для общего хранения структурированных данных. И я бы решительно не поместите XML в эту категорию даже сегодня-слишком многословный, слишком интенсивный для обработки, слишком разборчивый.
В настоящее время, моя любимая вещь, чтобы использовать для данных, которые не должны быть людьми-readableis SQLite и создать базу данных. Это так невероятно легко внедрите полнофункциональную базу данных SQL в любое приложение... существуют привязки для C, Perl, Python, PHP и т. д... и это с открытым исходным кодом и очень быстро, надежно и легко.
I
Почему текстовые файлы правят? Из-за теста Макилроя. Очень важно, чтобы выход одной программы был приемлемым в качестве исходного кода для другой, а текстовые файлы-это самая простая вещь, которая работает.
кто-нибудь когда-либо пытался Mathematica?
рис выше из старой версии, но это было лучшее, что google мог мне дать.
в любом случае...сравните первое уравнение с математика.Интеграция(1 / (Math.Pow ("x", 3)-1),"x") как вам пришлось бы писать, если бы вы кодировали простым текстом на большинстве распространенных языков. ИМО математическое представление намного легче читать, и это все еще довольно мало уравнение.
и да, вы можете как вводить, так и копировать-вставлять код как обычный текст, если хотите.
смотрите его как следующее поколение синтаксис. Бьюсь об заклад, есть много других вещей, кроме математики, которые могли бы извлечь выгоду из такого представления.
Это довольно очевидно, почему простой текст является королем. Но столь же очевидно, почему структурированный формат был бы еще лучше.
только один пример: если вы переименуете метод, ваш инструмент управления diff/merge/source сможет сказать, что изменилось только одно. Инструменты, которые мы используем сегодня, покажут длинный список изменений, по одному для каждого места и файла, который был вызван или объявлен.
(кстати, этот пост не дает ответа на вопрос, как вы могли бы заметил)
тенденция, которую мы видим о DSL, - это первое, что приходит на ум при чтении вашего вопроса. Проблема заключалась в том, что между моделями (например, UML) и реализацией не существует отношения 1 к 1. Microsoft среди других работает над тем, чтобы вы могли создать свое приложение как что-то вроде UML, а затем сгенерировать код. И самое главное - когда вы решите изменить свой код, модель снова отразит это.
Рабочий Процесс Windows Фонд-довольно хороший пример. Причина есть плоские файлы и / или XML в фоновом режиме, но вы обычно в конечном итоге определяете свою бизнес-логику в инструменте оркестровки. И это довольно круто!
нам нужно больше "фабрик программного обеспечения", и в будущем мы увидим более богатый опыт IDE, но пока компьютеры работают на нулях и единицах, плоские текстовые файлы могут и (вероятно) всегда будут промежуточным этапом. Как уже говорилось, несколько человек, простые текстовые файлы очень гибкие.
Я с тоской подумал о том же, как описано в ответе на: какой инструмент / приложение / что вы хотите, чтобы существовали?
хотя легко представить себе большое количество преимуществ, я думаю, что самое большое препятствие, которое нужно было бы решить, заключается в том, что никто не создал жизнеспособную альтернативу.
когда люди думают об альтернативах хранению источника в виде текста, они, похоже, часто сразу думают в терминах графических представлений (я имею в виду здесь к коммерческим продуктам, которые были доступны-например. HP-vee). И если мы посмотрим на опыт таких людей, как дизайнеры FPGA, мы увидим, что программирование (исключительно) графически просто не работает - следовательно, такие языки, как Verilog и VHDL.
но я не вижу, что хранение источника обязательно должно быть связано с методом его написания в первую очередь. Запись источника может быть в основном выполнена как текст - это означает, что проблемы копирования / вставки все еще могут быть достигнутый. Но я также вижу, что, разрешая слияния и откаты на основе токенизированного метаисточника, мы могли бы достичь более точных и более мощных инструментов манипуляции.
Visual FoxPro использует структуры таблиц dbf для хранения кода и метаданных для форм, отчетов, библиотек классов и т. д. Это бинарные файлы. Он также хранит код в файлах prg, которые фактические текстовые файлы...
единственное преимущество, которое я вижу, - это возможность использовать встроенный язык данных VFP для поиска кода в этих файлах... кроме того, это ответственность ИМО. По крайней мере один раз каждые несколько месяцев, один из этих файлов будет поврежден без видимых причин. Интеграция с источником контроль и diffs очень больно, а также. Существуют обходные пути для этого, но включают в себя преобразование файла в текст временно!
код вашей программы определяет структуру, которая будет создана с помощью xml или двоичного формата. Ваш язык программирования является более прямым представлением структуры вашей программы, чем XML или двоичное представление. Вы когда-нибудь замечали, как Word плохо себя ведет, когда вы даете структуру своему документу. WordPerfect, по крайней мере, "откроет коды", чтобы вы могли видеть, что лежит под вашим документом. Плоские файлы делают то же самое для вашей программы.
отличная идея. Я сам задавался этим вопросом в меньшем масштабе ... гораздо меньше, почему IDE X не может генерировать то или иное.
Я не знаю, способен ли я как программист еще разработать что-то такое крутое и сложное, как ваши разговоры или то, о чем я думаю, но мне было бы интересно попробовать.
может быть, начать с некоторых плагинов для .NET, Eclipse, Netbeans и так далее? Покажите, что можно сделать,и начните новую тенденцию в кодировании.
Я думаю, что еще один аспект этого заключается в том, что код-это важно. Это то, что будет исполнено. Например, в вашем примере UML я бы подумал, что вместо UML (предположительно созданного в каком-то редакторе, не связанного напрямую с "кодом"), включенным в ваш "исходный blob", было бы почти бесполезно. Гораздо лучше было бы иметь UML, созданный непосредственно из вашего кода, поэтому он описывает точное состояние кода как инструмент для понимания кода, а не как напоминание о том, каким должен быть код.
мы делаем это в течение многих лет в отношении автоматизированных инструментов doc. В то время как фактический программист сгенерировал комментарии в коде может выйти из синхронизации с кодом, такие инструменты, как JavaDoc и тому подобное, точно представляют методы на объекте, возвращаемые типы, Аргументы и т. д. Они представляют их такими,какие они есть на самом деле, а не как некий артефакт, возникший в результате бесконечных дизайнерских совещаний.
Мне кажется, что если бы вы могли произвольно добавьте случайные артефакты в какой-то" исходный blob", они, вероятно, устарели и менее полезны сразу. Если вы можете создавать такие артефакты непосредственно из кода, то небольшие усилия, чтобы заставить ваш процесс сборки сделать это, намного лучше, чем ранее упомянутые подводные камни перехода от текстовых исходных файлов.
связанные с этим объяснение того, почему вы хотите использовать текстовый инструмент UML (UMLGraph), кажется, применить почти так же, как и почему вы хотите текстовые исходные файлы.
Это не ответ именно на ваш вопрос, но вот редактор позволяет иметь более высокий вид код: http://webpages.charter.net/edreamleo/front.html
Я думаю, что причина, по которой текстовые файлы используются в разработке, заключается в том, что они универсальны для различных инструментов разработки. Вы можете заглянуть внутрь или даже исправить некоторые ошибки с помощью простого текстового редактора (вы не можете сделать это в двоичном файле, потому что вы никогда не знаете, как любое исправление уничтожит другие данные). Однако это не означает, что текстовые файлы лучше всего подходят для всех этих целей.
конечно, вы можете различать и объединять их. Но это не означает, что инструмент diff/merge понимает четкая структура данных, закодированных в этом текстовом файле. Вы можете сделать diff / merge, но (особенно в XML-файлах) инструмент diff не покажет вам различия правильно, то есть он покажет вам, где файлы отличаются и какие части данных инструмент "думает" одинаковы. Но он не покажет вам различий в структуре XML-файла - он будет просто соответствовать строкам, которые выглядят одинаково.
независимо от того, используем ли мы двоичные файлы или текстовые файлы, всегда лучше что инструменты diff / merge заботятся о структуре данных, которую представляет этот файл, а не о строках и символах. Например, для файлов C++ или Java сообщите, что какой-то идентификатор изменил свое имя, сообщите, что какой-то раздел был окружен дополнительными if () {}, но, с другой стороны, игнорируйте изменения в отступах или символах EOL. Лучший подход заключается в том, что файл считывается во внутренние структуры и сбрасывается с использованием определенных правил формата. Таким образом, различие будет производиться через внутренние структуры и результат слияния будут сгенерированы из Объединенной внутренней структуры.
современные программы состоят из плоских частей, но являются ли они плоскими? Есть директивы и включает в себя и библиотеки объектов и т. д. Обычный вызов функции-это взгляд в другое место. Логика не плоская, из-за наличия нескольких потоков и т. д.
У меня такое же видение! Я действительно хочу, чтобы это существовало.
возможно,вы захотите взглянуть на крепость, исследовательский язык Sun. Он имеет специальную поддержку формул в исходном коде. Цитата ниже из Википедии
крепость проектируется из начало иметь несколько синтаксических таблица стилей. Исходный код может быть отображается как текст ASCII в Юникоде или как улучшены изображения. Это позволит для поддержки математических символов и другие символы в визуализации выход для более легкого чтения.
основной причиной сохранения текста в качестве источника является отсутствие powertools, например, контроль версий, для нетекстовой даты. Это основано на моем опыте работы с Smalltalk, где простой байт-код хранится в core-dump все время. В нетекстовой системе, с сегодняшними инструментами, командное развитие-это кошмар.