Может ли система быть на 100% управляемой данными?

Мой новый начальник работал над этим проектом много лет. Я был здесь всего несколько недель, но я не уверен, что это возможно. Он хотел бы спроектировать систему, которая будет «на 100% основана на данных».

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

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

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

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

Возможно ли такое приложение, управляемое данными на 100%?

Ваш босс должен прочитать эту статью: Bad Carma: проект "Vision", предостерегающая история о влиянии внутренней платформы или эффекте второй системы.

Аннотация

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

Эта история о таком IT-проекте, самом впечатляющем провале, который я когда-либо испытывал. Это привело к полному увольнению ИТ-отдела среднего размера и в конечном итоге привело к разрушению растущей компании в растущей отрасли. Компания, которую мы назовем «Upstart», была успешной и прибыльной подпиской на телевизионный бизнес.

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

• Ввод заказа и инвентарь
• Обслуживание клиентов, служба поддержки
• Главная книга, дебиторская задолженность, выставление счетов и кредиторская задолженность

Приложение называлось «Vision», и оно было как официально заявленным обещанием для Upstart, так и самоотверженным поклоном его архитектору. Приложение было инновационным в том смысле, что оно было разработано так, чтобы быть достаточно гибким, чтобы приспособиться к любым будущим изменениям бизнеса. Не только любые предсказуемые будущие изменения в бизнесе, но абсолютно любые изменения в бизнесе, в любой форме. Это было довольно примечательное утверждение, но Vision должен был стать последним приложением, когда-либо созданным. Он достиг этой максимальной гибкости , полностью управляя данными, обеспечивая безграничную абстракцию и используя передовые в то время методы объектно-ориентированного программирования.

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

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

Смотрите также

http://en.wikipedia.org/wiki/Inner-platform_effect

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

Программа, полностью управляемая данными, - это программа, в которой вся логика и конфигурация обрабатываются значениями, хранящимися таким образом, что в другом контексте они будут рассматриваться как данные. В 1980-х годах было выпущено много продуктов 4GL, которые предоставляли возможность создавать отчеты, формы, таблицы и логику, используя элементы данных, введенные во множество форм, хранящиеся в таблицах и доступные через отчеты. Раньше я называл такие системы «рисованием по номерам», но теперь вижу, что это стало известно как эффект «внутренней системы». Доброе имя.

Люди, которые создают эти системы, пытаются (знают ли они это или нет) создать новый язык программирования. Так как у них нет навыков, они делают это плохо. С точки зрения JVM / CLR, скомпилированная программа Java / C # - это просто данные. В этом случае это было сделано хорошо. В любом случае, программисты должны использовать язык, каким бы он ни был.

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

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

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

На данный момент вы только что внедрили новый 4GL. Если вам это удалось, сделайте это успешно, пожалуйста, дайте мне знать. Большинство людей терпят неудачу. Я буду первым, кто поздравит вас с вашим достижением.

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

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

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

Если я хочу напечатать SO сообщение, я просто хочу напечатать его. Я вполне способен вместо этого написать программу на С ++ для ее вывода, но я бы не стал использовать веб-браузер, в котором вместо обычного текстового поля отображался редактор программ на С ++. Люди, которые не знают C ++, не только не будут использовать браузер, но и не смогут.

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

Поэтому, если вы собираетесь использовать систему, основанную на 100% данных, которая может делать все, что нужно, с правильными данными, у вас есть два вопроса:

1. Мы в изобретении языков программирования, или мы должны быть?
2. Будет ли наш новый язык программирования лучше (для наших целей), чем тот, который у нас уже есть, и будем ли мы поддерживать и развивать его по мере необходимости?

Иногда ответы да, и вы пишете какой-то предметно-ориентированный язык. Или даже настоящий язык программирования общего назначения, если вы Sun / Microsoft / Stroustrup / van Rossum / многие другие. Иногда ответов нет, и вы получаете эффект «внутренней платформы» - после долгих усилий, проб и ошибок вы что-то получаете. Если вам повезет, он лишь немного уступает языку программирования, на котором вы его написали, и не проще в использовании.

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

Для игр часто используется хитрость, заключающаяся в том, чтобы привязать Lua к игровому движку. Это позволяет дизайнерам программировать на относительно простом языке, но при этом привлекать «настоящего» программиста, где это необходимо для производительности или для доступа к определенным функциям движка или платформы. Результирующие сценарии Lua являются «данными» для движка. Им не обязательно включать большую часть того, что вы бы назвали «логикой», в отличие от данных конфигурации, и часто они в значительной степени определяют весь сюжет и среду, но не весь игровой процесс. Это не на 100% на основе данных и, конечно, не на 100% без ошибок, но это интересный практический компромисс.

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

«Управляемое данными программирование» является результатом фундаментального отсутствия понимания того, что мы делаем как программисты; любые данные, которые способны реализовать алгоритм, на самом деле являются «программированием», даже если вам каким-то образом удалось смешать (исказить?) две идеи в пользовательском интерфейсе. Теперь, это не значит, что вы не можете объединить две идеи с другой стороны, так что весь код является данными; это предпосылка за lisp, которая обеспечивается его гомо-звуком и эксплуатируется его макросистемой. Да, эти понятия звучат одинаково, но их последствия и применения на практике сильно различаются.

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

Вы имеете в виду, что ваш босс хочет, чтобы вы написали это:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Чтобы сгенерировать это:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

Первый - JSON, а второй - JavaScript .

Clearification

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

Возможно ли такое приложение, управляемое данными на 100%?

Это где я только начал. Своим ответом я пытаюсь согласиться с оригинальным постом: « Это возможно, но вы правы, это просто сдвинет проблему на один уровень выше без [очевидной] выгоды» .

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

Конечно, это не упрощает или упрощает создание приложений в Интернете, на самом деле это делает их намного сложнее.

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

¹ Хорошо, если вы игнорируете плагины, JavaScript и HTML5 .

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

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

Что касается 100% данных, управляемых, если компилятор или интерпретатор могут понимать оболочку, то вычисления приводятся в действие. Если данные имеют ту же базовую структуру, что и оболочка или интерфейс, которые есть, данные также могут управляться компилятором или интерпретатором. Я думаю, что Mathematica - хорошее объяснение того, почему я отвечаю вам «да».