Почему мы все еще программируем с плоскими файлами? [закрытый]
Я создал простой шаблонный класс streamable_enum, который использует операторы потока << и >> и основан на std::map<Enum, std::string>:
#ifndef STREAMABLE_ENUM_HPP
#define STREAMABLE_ENUM_HPP
#include <iostream>
#include <string>
#include <map>
template <typename E>
class streamable_enum
{
public:
typedef typename std::map<E, std::string> tostr_map_t;
typedef typename std::map<std::string, E> fromstr_map_t;
streamable_enum()
{}
streamable_enum(E val) :
Val_(val)
{}
operator E() {
return Val_;
}
bool operator==(const streamable_enum<E>& e) {
return this->Val_ == e.Val_;
}
bool operator==(const E& e) {
return this->Val_ == e;
}
static const tostr_map_t& to_string_map() {
static tostr_map_t to_str_(get_enum_strings<E>());
return to_str_;
}
static const fromstr_map_t& from_string_map() {
static fromstr_map_t from_str_(reverse_map(to_string_map()));
return from_str_;
}
private:
E Val_;
static fromstr_map_t reverse_map(const tostr_map_t& eToS) {
fromstr_map_t sToE;
for (auto pr : eToS) {
sToE.emplace(pr.second, pr.first);
}
return sToE;
}
};
template <typename E>
streamable_enum<E> stream_enum(E e) {
return streamable_enum<E>(e);
}
template <typename E>
typename streamable_enum<E>::tostr_map_t get_enum_strings() {
// \todo throw an appropriate exception or display compile error/warning
return {};
}
template <typename E>
std::ostream& operator<<(std::ostream& os, streamable_enum<E> e) {
auto& mp = streamable_enum<E>::to_string_map();
auto res = mp.find(e);
if (res != mp.end()) {
os << res->second;
} else {
os.setstate(std::ios_base::failbit);
}
return os;
}
template <typename E>
std::istream& operator>>(std::istream& is, streamable_enum<E>& e) {
std::string str;
is >> str;
if (str.empty()) {
is.setstate(std::ios_base::failbit);
}
auto& mp = streamable_enum<E>::from_string_map();
auto res = mp.find(str);
if (res != mp.end()) {
e = res->second;
} else {
is.setstate(std::ios_base::failbit);
}
return is;
}
#endif
Использование:
#include "streamable_enum.hpp"
using std::cout;
using std::cin;
using std::endl;
enum Animal {
CAT,
DOG,
TIGER,
RABBIT
};
template <>
streamable_enum<Animal>::tostr_map_t get_enum_strings<Animal>() {
return {
{ CAT, "Cat"},
{ DOG, "Dog" },
{ TIGER, "Tiger" },
{ RABBIT, "Rabbit" }
};
}
int main(int argc, char* argv []) {
cout << "What animal do you want to buy? Our offering:" << endl;
for (auto pr : streamable_enum<Animal>::to_string_map()) { // Use from_string_map() and pr.first instead
cout << " " << pr.second << endl; // to have them sorted in alphabetical order
}
streamable_enum<Animal> anim;
cin >> anim;
if (!cin) {
cout << "We don't have such animal here." << endl;
} else if (anim == Animal::TIGER) {
cout << stream_enum(Animal::TIGER) << " was a joke..." << endl;
} else {
cout << "Here you are!" << endl;
}
return 0;
}
34 ответа
- Вы можете разность их
- , можно объединить их
- , любой может отредактировать их
- , они просты и легки для контакта с
- , они универсально доступны для тысяч инструментов
Я задумчиво задался вопросом то же самое, как описано в ответе на: то, Какого tool/application/whatever Вы желаете, существовало?
, В то время как легко вообразить большое количество преимуществ, я думаю самое большое препятствие, которое должно было бы быть обращено, то, что никто не произвел жизнеспособную альтернативу.
, Когда люди думают об альтернативах хранению источника как текст, они кажутся часто, сразу думают с точки зрения графических представлений (я обращаюсь здесь к коммерческим продуктам, которые были доступны - например, HP-vee). И если мы смотрим на опыт людей как разработчики FPGA, мы видим, что программирование (исключительно) графически просто не работает - следовательно языки как Verilog и VHDL.
, Но я не вижу, что устройство хранения данных источника обязательно должно быть связано с методом записи его во-первых. Запись источника может быть в основном сделана как текст - что означает, что проблемы копирования/вставки могут все еще быть достигнуты. Но я также вижу, что, позволяя слияниям и откатам, которые будут сделаны на основе маркируемого метаисточника, мы могли достигнуть более точных и более мощных инструментов управления.
Тенденция мы занимаемся DSL's, является первой вещью, которая приходит на ум при чтении вопроса. Проблема состояла в том, что там не существует 1 к 1 отношения между моделями (как UML) и реализация. Microsoft среди других работает над получением там, так, чтобы можно было создать приложение как что-то подобное UML, затем кодировать, может быть сгенерирован. И важная вещь - поскольку Вы решили изменить свой код, модель, отразит это снова.
Windows Workflow Foundation является довольно хорошим примером. Из причины существуют плоские файлы и/или XML в фоновом режиме, но Вы обычно заканчиваете тем, что определили свою бизнес-логику в инструменте оркестровки. И это довольно прохладно!
Мы нуждаемся в большем количестве "взглядов" фабрик программного обеспечения и будем видеть более богатый опыт IDE в будущем, но пока компьютеры, на которых работают, обнуляет и, плоские текстовые файлы могут и (вероятно) всегда быть промежуточной стадией. Как указано уже будьте несколькими людьми, простые текстовые файлы очень гибки.
Visual FoxPro использует dbf структуры таблиц для хранения кода и метаданных для форм, отчетов, класс освобождает и т.д. Это двоичные файлы. Это также хранит код в prg файлах что фактические текстовые файлы...
единственным преимуществом, которое я вижу, является способность использовать созданный на языке описания данных VFP, чтобы сделать поиски кода на тех файлах..., кроме которых это - ответственность imo. По крайней мере, один раз в несколько месяцев, один из этих файлов станет поврежденным без видимой причины. Интеграция с управлением исходным кодом и diffs очень болезненный также. Существуют обходные решения для этого, но включают преобразование файла к тексту временно!
Для примера языка, который покончил с традиционным программированием текста, посмотрите Язык Лавы .
Другая изящная вещь, которую я просто недавно обнаружил, subtext2 ( демонстрационное видео ).
Отличная идея. Я самостоятельно задался вопросом в меньшем масштабе... намного меньшем, почему не может IDE X генерировать это или это.
я не знаю, способен ли я как программист уже для разработки чего-то столь же прохладного и сложный как разговор об или о чем я думаю, но я интересовался бы попыткой.
, Возможно, начинаются с некоторыми плагинами для.NET, Eclipse, Netbeans, и так далее? Представьте то, что может быть сделано, и запускать новую тенденцию в кодировании.
Код Вашей программы определяет структуру, которая была бы создана с xml или двоичным форматом. Ваш язык программирования является более прямым представлением структуры Вашей программы, чем XML или Двоичное представление были бы. Вы когда-либо замечали, как Word неправильно себя ведет на Вас, поскольку Вы даете структуру своему документу. WordPerfect, по крайней мере, 'показал бы коды', чтобы позволить Вам видеть то, что кладет под Вашим документом. Плоские файлы делают то же самое для Вашей программы.
Я думаю, что другой аспект этого - то, что код - то, что важно. Это - то, что будет выполняемым. Например, в Вашем примере UML, я думал бы вместо того, чтобы иметь UML (по-видимому, созданный в некотором редакторе, не непосредственно связанный с "кодом") включенный в Ваш "исходный блоб" будет почти бесполезно. Намного лучше должен был бы генерировать UML непосредственно от Вашего кода, таким образом, это описывает точное состояние, код находится в как инструмент для понимания кода, а не как напоминание того, каков код должен был быть.
Мы делали это в течение многих лет относительно автоматизированных инструментов документа. В то время как сгенерированные комментарии фактического программиста в коде могли бы выйти из синхронизации с кодом, инструменты как JavaDoc и т.п. искренне представляют методы на объекте, возвращают типы, аргументы, и т.д. Они представляют их, поскольку они на самом деле существуют, не как некоторый артефакт, который вышел из бесконечных встреч дизайна.
мне кажется, что, если бы Вы могли бы произвольно добавить случайные артефакты к некоторому "исходному блобу", они, вероятно, устарели бы и менее, чем были бы полезны сразу же. Если можно генерировать такие артефакты непосредственно от кода, то небольшое усилие заставить процесс сборки делать так значительно лучше, чем ранее упомянутые ловушки отодвигания от исходных файлов простого текста.
Связанный с этим, объяснение того, почему Вы хотели бы использовать простой текст инструмент UML ( UMLGraph), кажется, применяется почти одинаково хорошо к тому, почему Вы хотите исходные файлы простого текста.
Довольно очевидно, почему простой текст является королем. Но одинаково очевидно, почему структурированный формат был бы еще лучше.
Всего один пример: при переименовании метода инструмент разности/слияния/управления исходным кодом был бы в состоянии сказать, что только одна вещь изменилась. Инструменты, которые мы используем сегодня, показали бы длинный список изменений, один для каждого места и файла, что метод назвали или объявили.
(Между прочим, это сообщение не отвечает на вопрос, как Вы, возможно, заметили)
Современные программы состоят из плоских частей, но действительно ли они являются плоскими? Существуют использования, и включает, и библиотеки объектов, и т.д. Вызов обычной функции является быстрым взглядом в различное место. Логика не является плоской, из-за наличия нескольких потоков, и т.д.
Я думаю причина того, почему текстовые файлы используются в разработке, то, что они универсальны против различных средств разработки. Можно посмотреть внутри или даже зафиксировать некоторые ошибки с помощью простого текстового редактора (Вы не можете сделать этого в двоичном файле, потому что Вы никогда не знаете, как любой фиксирует, уничтожил бы другие данные). Это не означает, однако, что текстовые файлы являются лучшими во всех тех целях.
, Конечно, Вы можете разность и объединять их. Но это не означает, что инструмент разности/слияния понимает отличную структуру данных, закодированных этим текстовым файлом. Можно сделать разность/слияние, но (особенно замеченный в XML-файлах) различный инструмент не покажет Вам различия правильно, то есть, это покажет Вам, где файлы отличаются и какие части данных, инструмент "думает", являются тем же. Но это не покажет Вам различия в структуре XML-файла - это будет просто соответствовать строкам, которые выглядят одинаково.
Невнимательный, используем ли мы двоичные файлы или текстовые файлы, всегда лучше, что инструменты разности/слияния заботятся о структуре данных, которую этот файл представляет, а не строки и символы. Для C++ или файлов Java, например, сообщают, что некоторый идентификатор изменил свое имя, сообщите, что некоторый раздел был окружен дополнительным, если () {}, но, с другой стороны, игнорируют изменения в символах EOL или отступах. Лучший подход состоял бы в том, что файл читается во внутренние структуры и вывел использующие определенные правила формата. Таким образом, различный луг будет сделан через внутренние структуры, и результат слияния будет сгенерирован от объединенной внутренней структуры.
У меня есть то же видение! Мне действительно жаль, что это не было бы существовать.
Вы могли бы хотеть смотреть на Крепость, язык исследования Sun. Это имеет специальную поддержку формул в исходном коде. Кавычка ниже из Википедии
, Крепость разрабатывается с самого начала для имения нескольких синтаксических таблиц стилей. Исходный код может быть представлен как текст ASCII в Unicode, или как изображение prettied. Это будет допускать поддержку математических символов и других символов в представленном выводе для более легкого чтения.
основная причина персистентности текста, поскольку источник является отсутствием powertools, как, например, управление версиями, для нетекстовой даты. Это основано на моем опыте, работающем с Smalltalk, где простой байт-код сохранен в дампе ядра всем временем. В нетекстовой системе, с сегодняшними инструментами, разработка команды является кошмаром.
Кто-либо когда-нибудь пробовал Mathematica?
рис. выше от старой версии, но это был лучший Google, мог дать мне.
Так или иначе... сравнивают первое уравнение там с Математика. Интегрируйтесь (1 / (Математика. Голова ("x", 3)-1), "x") как Вы должен был бы записать, кодировали ли Вы с простым текстом на наиболее распространенных языках. Imo, который математическое представление намного легче считать, и это - все еще довольно маленькое уравнение.
И да, можно и ввести и вставка копии код как простой текст, если Вы хотите.
Посмотрите его как следующее поколение подсветка синтаксиса . Я держал пари, что существует много другого материала, чем математика, которая могла взять преимущество от этого вида представления.
Это не могло бы ответить точно на Ваш вопрос, но здесь является редактором, позволяет иметь более высокое представление кода: http://webpages.charter.net/edreamleo/front.html
Вы упоминаете, что мы должны использовать "некоторую форму XML"? Что Вы думаете, XHTML и XAML?
Также XML является все еще просто плоским файлом.
По-моему, любые возможные преимущества перевешиваются, будучи связанным с конкретным инструментом.
С источником простого текста (который, кажется, то, что Вы обсуждаете, а не плоские файлы по сути) я могу вставить блоки в электронное письмо, использовать простые системы управления версиями (очень важный!), запишите код в комментарии по поводу Переполнения стека, используйте один из тысячи текстовых редакторов на любом количестве платформ, и т.д.
С некоторым двоичным представлением кода, я должен использовать специализированного редактора, чтобы просмотреть или отредактировать его. Даже если основанное на тексте представление может быть произведено, Вы не можете тривиально откатывать изменения в каноническую версию.
Smalltalk является основанной на изображении средой. Вы больше не работаете с кодом в файле на диске. Вы работаете с и изменяете реальные объекты во времени выполнения. Это все еще - текст, но классы не хранятся в человекочитаемых файлах. Вместо этого целая объектная память (изображение) хранится на файле в двоичном формате.
, Но самые большие жалобы тех, которые испытывают smalltalk, то, потому что это не использует файлы. От большинства основанных на файле инструментов, которые мы имеем (энергия, emacs, затмение, vs.net, инструменты Unix) нужно будет отказаться в пользу собственных инструментов smalltalk. Не то, чтобы инструменты, обеспеченные в smalltalk в подчиненном. Это просто отличается.
Почему эссе записаны в тексте? Почему легальные документы записаны в тексте? Почему романы-фэнтези записаны в тексте? Поскольку текст является единственной лучшей формой - для людей - сохранения их мыслей.
текст - то, как люди думают о, представляют, понимают и сохраняются понятия - и их сложности, иерархии и взаимосвязи.
<? версия xml = "1.0" кодирование = "UTF-8"? > < code> Плоские файлы легче считать </code> </xml>
Вот то, почему:
-
Человекочитаемый. Это делает намного легче определить ошибку, и в файле и в методе парсинга. Также может быть считан вслух. Это - то, которое Вы просто не можете получить с XML и могли бы иметь значение, особенно в поддержке клиентов.
-
Страховка от устаревания. Целых regex существуют, возможно записать довольно хороший синтаксический анализатор во всего нескольких строках кода.
-
Рычаги. Почти все там, от систем управления версиями до редакторов для фильтрации, может осмотреть, объединиться и воздействовать на плоские файлы. Слияние XML может быть путаницей.
-
Способность интегрировать их скорее легко с инструментами UNIX, такими как grep, сокращение или sed.
Привычка - вторая натура я предполагаю.
До недавнего времени, не было многих хорошее качество, высокопроизводительные, широко доступные библиотеки для общего устройства хранения данных структурированных данных. И я был бы решительно не , помещает XML в ту категорию даже сегодня - слишком подробный, слишком интенсивный для обработки, слишком привередливый.
В наше время, моя любимая вещь использовать для данных, которые не должны быть человеческие-readableis SQLite и сделать базу данных. Так невероятно легко встроить полнофункциональную базу данных SQL в любое приложение... существует привязка для C, Perl, Python, PHP, и т.д...., и это - открытый исходный код и действительно быстрый и надежный и легкий.
я < 3 SQLite.
Это - хороший вопрос. FWIW, я хотел бы видеть инструмент управления кодом стиля Wiki. Каждый функциональный блок имел бы свою собственную страницу Wiki. Инструменты сборки сплачивают исходный код из Wiki. Была бы "обсуждать" страница, связанная с той страницей, где люди могут спорить об алгоритмах, API и такой как.
Heck, не случилось бы так что трудно изрубить один от существующей ранее реализации Wiki. Какие-либо берущие...?
По моему скромному мнению, XML и двоичные форматы были бы общей путаницей и не принесут значительной пользы.
OTOH, связанная идея состояла бы в том, чтобы записать в базу данных, возможно, одна функция на запись, или возможно иерархическая структура. IDE, созданный вокруг этого понятия, мог сделать перешедший источник более естественным, и легче скрыть что-либо не относящееся к коду, который Вы читаете в данный момент.
Люди пытались в течение долгого времени создать среду редактирования, которая идет вне плоского файла, и все перестали работать в некоторой степени. Самым близким, который я видел, был прототип для Намеренного Программирования Charles Simonyi, но тогда это было понижено до визуального инструмента создания DSL.
, Неважно, как код сохранен или представлен в памяти в конце, это должно быть презентабельным и модифицируемым как текст ( без форматирования, изменяющегося на Вас ), так как это - самый легкий способ, которым мы знаем для выражения большинства абстрактных понятий, которые необходимы для решения проблем путем программирования.
С плоскими файлами Вы получаете это бесплатно, и любой простой текстовый редактор (с поддержкой кодирования правильного символа) будет работать.
У Steve McConnell есть он правильный, как всегда - Вы пишете программы для других программистов (включая себя), не для компьютеров.
Однако Microsoft Visual Studio должен внутренне управлять кодом, который Вы пишете в очень структурированном формате, или Вы не были бы в состоянии сделать, такие вещи как "Находят Все Ссылки" или переименовывают или осуществляют рефакторинг переменные и методы так легко. Мне было бы интересно, если бы у кого-либо были ссылки на то, как это работает.
Программы Lisp не являются плоскими файлами. Они - сериализация структур данных. Этот код поскольку данные является старой идеей, и на самом деле одной из самой большой идеи в информатике.
На самом деле, примерно 10 лет назад, ранний прототип Charles Simonyi для намеренного программирования попытался переместиться вне плоского файла в древовидное представление кода, который может визуализироваться по-разному. Теоретически, специалист по проблемной области, премьер-министр и разработчик программного обеспечения могли все видеть (и соединить), код приложения способами, которые были полезны для них, и продукты могли быть основаны на иерархии декларативных "намерений", копнув к коду низкого уровня только по мере необходимости.
ЭТА (на запрос в вопросах) существует копия одна из его ранних бумаг на этом на веб-сайте исследования Microsoft. К сожалению, так как Simonyi оставил MS для запуска отдельной компании несколько лет назад, я не думаю, что прототип все еще доступен для скачивания. Я видел некоторые демонстрации назад, когда я был в Microsoft, но я не уверен, как широко его ранний прототип был распределен.
Его компания, IntentSoft все еще немного тих о том, что они планируют поставить рынку, во всяком случае, но часть раннего материала, который вышел из MSR, была довольно интересна.
модель хранения была некоторым двоичным форматом, но я не уверен, сколько из тех деталей было раскрыто во время проекта MSR, и я уверен, что некоторые вещи изменились начиная с ранних реализаций.
Почему текстовые файлы управляют? Из-за теста McIlroy. Жизненно важно иметь вывод одной программы быть приемлемым как исходный код для другого, и текстовые файлы являются самой простой вещью, которая работает.
Labview и Simulink две графических среды программирования. Они и популярны в своих полях (взаимодействующий через интерфейс к аппаратным средствам от ПК и моделирующий системы управления, соответственно), но не использовали много за пределами тех полей. Я работал с людьми, которые были большими поклонниками обоих, но никогда не входили в них сам.
Иронически там программируют конструкции, которые используют точно, что Вы описываете.
, Например, SQL Server Integration Services, которые включают поток логики кодирования путем перетаскивания компонентов на поверхность визуального проектирования, сохраняется как XML-файлы, описывающие точно тот бэкэнд.
, С другой стороны, SSIS является довольно трудным к управлению исходным кодом. Также довольно трудно разработать любой вид сложной логики в него: при необходимости в немного большем количестве "управления" необходимо будет кодировать код VB.NET в компонент, который приносит нам назад туда, где мы запустили.
я предполагаю, что, как кодер, необходимо рассмотреть то, что для каждого решения проблемы существуют последствия, которые следуют. Не все могло (и некоторые спорят, должен) быть представленным в UML. Не все могло быть визуально представлено. Не все могло быть упрощено достаточно для имения последовательного представления двоичного файла.
Однако я установил бы это недостатки понижения кода к двоичным форматам (большинство которых будет также иметь тенденцию быть собственным) далеко перевешивают преимущества наличия их в простом тексте.