Czy system może być w 100% sterowany danymi?

Mój nowy szef pracuje nad tym projektem od wielu lat. Byłem tu tylko kilka tygodni, ale nie jestem pewien, czy to możliwe. Chciałby zaprojektować system, który będzie „w 100% sterowany danymi”.

Jeśli więc wprowadzimy wystarczającą ilość danych, możemy zdefiniować i wygenerować dowolną aplikację. Udało mi się przynajmniej skłonić go do przyznania pewnych rzeczy, takich jak użytkownicy, lub aplikacje powinny mieć predefiniowane wartości, ale podoba mu się koncepcja struktury systemu, interfejsu użytkownika i logiki przechowywanych jako dane.

Jest kilka pokazów prostych rzeczy i on w zasadzie odkrył na nowo kilka prostych pomysłów programowania obiektowego i twoich podstawowych systemów szablonów, ale ogólnie myślę, że ten cel może być w rzeczywistości niemożliwy.

Nie wiem, jak zdefiniować logikę za pomocą danych, a system nie stanie się tak skomplikowany, że i tak programujesz.

Myślę, że teoretycznie nie jest tak, ponieważ rzecz, która interpretuje dane, musi zostać ukończona, aby opisać aplikację, więc właśnie przesunąłeś problem o jeden poziom wyżej, bez żadnej korzyści netto.

Czy taka aplikacja oparta w 100% na danych jest możliwa?

Twój szef powinien przeczytać ten fragment: Bad Carma: Projekt „Wizja”, przestroga dotycząca efektu wewnętrznej platformy lub efektu drugiego systemu.

Abstrakcyjny

Wszyscy z nas, którzy pracują w informatyce (IT), pracują nad projektem, w którym coś ważnego jest po prostu nie tak. Wiemy o tym, większość o tym wie, ale nikt nie jest w stanie przekonująco przekonać palca do problemu.

Ta historia dotyczy takiego projektu informatycznego, najbardziej spektakularnej porażki, jaką kiedykolwiek spotkałem. Spowodowało to całkowite zwolnienie średniego działu IT, a ostatecznie doprowadziło do zniszczenia rozwijającej się firmy w rozwijającej się branży. Firma, którą nazwiemy „Upstart”, była udaną i dochodową działalnością w zakresie telewizji subskrypcyjnej.

Projekt powstał na początku lat dziewięćdziesiątych i była to specjalnie zbudowana aplikacja do zamawiania zamówień i obsługi klienta, która bardzo przypomina to, co obecnie nazywa się Zarządzaniem relacjami z klientem lub CRM. Podstawowa funkcjonalność systemu obejmowała:

• Wpis zamówienia i ekwipunek
• Obsługa klienta, dział pomocy technicznej
• Księga główna, należności, faktury i zobowiązania

Aplikacja nazywała się „Vision”, a jej nazwa była zarówno oficjalną obietnicą dla Upstart, jak i ukłonem w stronę architekta. Aplikacja była innowacyjna, ponieważ została zbudowana na tyle elastycznie, aby uwzględnić wszelkie przyszłe zmiany w firmie. Nie tylko wszelkie możliwe do przewidzenia przyszłe zmiany w firmie, ale absolutnie wszelkie zmiany w firmie, w dowolnej formie. Było to dość niezwykłe twierdzenie, ale Vision miał być ostatnią aplikacją, jaką kiedykolwiek zbudowano. Osiągnął tę całkowitą elastyczność , całkowicie sterowany danymi, zapewniając nieograniczoną abstrakcję i stosując techniki programowania obiektowego, które były wówczas najnowocześniejsze.

Podobnie jak wiele takich projektów, które miały na celu stworzenie aplikacji o kluczowym znaczeniu, prace rozwojowe trwały dwa lata, około rok dłużej niż pierwotnie przewidywano. Ale było to do przyjęcia, ponieważ była to aplikacja, która będzie trwać wiecznie, dostosowując się do wszelkich przyszłych wymagań, zapewniając nieograniczony zwrot z inwestycji (ROI). Kiedy aplikacja wreszcie została opublikowana, prawie wszyscy w firmie zainwestowali w nią tak wiele, że dosłownie los firmy zależał od jej sukcesu.

Jednak w przypadku całkowitej awarii projektu aplikacjom o kluczowym znaczeniu, prowadzącym podstawową działalność międzynarodowych korporacji, nie zezwala się na luksus takiego typu szybkiego wybuchu demonstrowanego przez tysiące firm typu „dot-com” w erze bańki internetowej. W ciągu miesiąca od pojawienia się „Wizji” Vision dla wszystkich, z wyjątkiem tych, którzy byli najbardziej zaangażowani w jej budowę, było oczywiste, że była to porażka.

Zobacz też

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

Odpowiedź brzmi: tak, możliwe jest stworzenie systemu w pełni opartego na danych i tak, to zwykle bardzo zły pomysł.

Program w pełni sterowany danymi to taki, w którym cała logika i konfiguracja są obsługiwane przez wartości przechowywane w taki sposób, że w innym kontekście byłyby one traktowane jako dane. W latach 80. wyprodukowano wiele produktów 4GL, które umożliwiały generowanie raportów, formularzy, tabel i logiki przy użyciu elementów danych wprowadzanych do wielu formularzy, przechowywanych w tabelach i dostępnych za pośrednictwem raportów. Kiedyś nazywałam takie systemy „malowaniem cyframi”, ale widzę, że teraz stał się znany jako efekt „wewnętrznego systemu”. Dobre imię.

Ludzie, którzy tworzą te systemy, próbują (czy wiedzą o tym, czy nie) stworzyć nowy język programowania. Ponieważ nie mają umiejętności, robią to źle. Z punktu widzenia JVM / CLR skompilowany program Java / C # to po prostu dane. W tym przypadku zostało to zrobione dobrze. W obu przypadkach programiści są zobowiązani do używania języka, bez względu na to, jaki on jest.

Jest jeden konkretny sposób na wykonanie tej pracy, o którym wiem. Budujesz szkielet każdego z potrzebnych komponentów: formularza, raportu, tabeli itp. Zapewniasz mechanizm konfigurowania różnych części tych komponentów poprzez ustawienie elementów danych. W przypadku wybranego zestawu funkcji podejmujesz decyzje i zamrażasz je w systemie, a konkretnie odmawiasz możliwości skonfigurowania tych funkcji.

Wdrażasz również język, który ma zdolność do kodowania operacji logicznych. Radzę używać istniejącego języka, takiego jak lua lub Python. Osadzasz fragmenty tego kodu wszędzie tam, gdzie potrzebne są operacje logiczne.

W ten sposób znacznie zmniejszasz ilość pisania wymaganą do wdrożenia każdego formularza, raportu, tabeli i tak dalej. System wydaje się być oparty na danych, ale tylko do pewnego stopnia.

W tym momencie właśnie wdrożyłeś nowy 4GL. Jeśli tak się stanie, zrób to skutecznie, daj mi znać. Większość ludzi ponosi porażkę. Będę pierwszy pogratulować ci osiągnięcia.

Myślę, że zasadniczo masz rację. Środowisko wykonawcze języka jest już w pełni elastycznym systemem opartym na danych. Pobiera jeden kawałek danych (program) i używa go do określenia, jak powinien działać na innych danych. Może nawet mieć schemat dla wielu użytkowników do przechowywania kodu do ponownego wykorzystania przez inne programy (od ścieżki dołączania do właściwego zarządzania instalacją).

„Język skryptowy”, z grubsza mówiąc, to środowisko wykonawcze języka, w którym ten kod jest czytelny dla człowieka. Kompilator umieszcza dodatkowy krok między użytkownikiem a środowiskiem wykonawczym. Języki „żartów”, takie jak Malbolge i APL, nie muszą być czytelne dla ludzi w żadnej formie. Ale to wszystko to samo na jednym poziomie, a mimo to czytelne dla człowieka nie oznacza, że ​​wszyscy potencjalni użytkownicy mają umiejętności czytania lub pisania, lub można oczekiwać, że je rozwiną.

Istnieją dobre powody, dla których zwykle nie udostępniasz środowiska uruchomieniowego języka bezpośrednio użytkownikom końcowym. Główną jest to, że usunięcie elastyczności zwiększa wygodę.

Jeśli chcę napisać wpis SO, chcę go tylko wpisać. Jestem w stanie napisać program C ++, aby go wyprowadzić, ale nie użyłbym przeglądarki internetowej, która pokazywałaby edytor programów C ++ zamiast zwykłego pola tekstowego. Ludzie, którzy nie znają C ++ nie tylko nie używaliby przeglądarki, nie mogli.

Jeśli chcę skonfigurować pewne parametry biznesowe, to niekoniecznie chcę to zrobić przy użyciu języka specyfikacji Turing-complete, a nawet jeśli to zrobiłem, prawdopodobnie nie można odróżnić od „zakodowania na stałe” tych samych parametrów biznesowych w żadnym innym programie język. Nadal musisz się zastanowić, czy to, co piszesz, oznacza, co chcesz, aby to oznaczało. Nadal musisz sprawdzić, czy zmiany są prawidłowe. Oznacza to, że trzeba jeszcze umiejętności programowania dla wszelkich zadań, które są nietrywialne i nie zablokowane przez kogoś, kto ma mieć umiejętności programowania, który przygotował specjalistyczną podsystem ( „Aplikacja”) na skonfigurowanie ( „use”).

Więc jeśli masz zamiar wprowadzić system oparty w 100% na danych, który może zrobić wszystko, biorąc pod uwagę odpowiednie dane, masz dwa pytania:

1. Czy zajmujemy się wymyślaniem języków programowania, czy powinniśmy?
2. Czy nasz nowy język programowania będzie lepszy (dla naszych celów) niż ten, który już mamy i czy będziemy go wspierać i rozwijać w miarę potrzeb?

Czasami odpowiedzi są twierdzące i piszesz jakiś język specyficzny dla domeny. Lub nawet prawdziwy język programowania ogólnego przeznaczenia, jeśli jesteś Sun / Microsoft / Stroustrup / van Rossum / wiele innych. Czasami odpowiedzi są przeczące i masz efekt „wewnętrznej platformy” - po wielu wysiłkach i próbach i błędach kończysz się czymś. Jeśli masz szczęście, jest tylko nieco gorszy od języka programowania, w którym go napisałeś, i nie jest łatwiejszy w użyciu.

Niektóre języki są trudniejsze lub łatwiejsze w użyciu niż inne, w szczególności jeśli są wyspecjalizowane w takim celu, jak R, to niektórzy użytkownicy znajdą je znacznie łatwiej. To, czego prawdopodobnie nie zrobisz, to zasadniczo ułatwienie programowania aplikacji ogólnych. W dowolnym momencie na świecie prawdopodobnie jest kilka osób / organizacji, które mogą to zrobić, ale twój szef / firma musi uczciwie rozważyć, czy to obejmuje go / ciebie.

W grach często stosuje się sztuczkę polegającą na ujawnieniu powiązań Lua z silnikiem gry. Pozwala to projektantom programować w stosunkowo prostym języku, ale nadal angażować „prawdziwego” programistę tam, gdzie jest to konieczne dla wydajności lub dostępu do określonej funkcjonalności silnika lub platformy. Powstałe skrypty Lua są „danymi”, jeśli chodzi o silnik. Nie wszystkie muszą zawierać wiele tego, co nazwalibyście „logiką”, w przeciwieństwie do danych konfiguracyjnych, i często w zasadzie definiują całą fabułę i środowisko, ale nie całą rozgrywkę. Nie jest to w 100% oparte na danych i na pewno nie jest w 100% wolne od błędów, ale jest interesującym praktycznym kompromisem.

Pracowałem w firmie, w której taki był cel. Fragmenty kodu SQL były przechowywane w tabelach bazy danych, odczytywane w czasie wykonywania i wykonywane. Wydajność była okropna, jak można sobie wyobrazić, a błędy były częste. Debugowanie było również niemożliwe, bez śladów na stosie lub czegokolwiek innego, co ułatwi życie.

„Programowanie oparte na danych” wynika z fundamentalnego braku zrozumienia tego, co robimy jako programiści; wszelkie dane, które są zdolne do wywołania algorytmu, są w rzeczywistości „programowaniem”, nawet jeśli jakoś udało się połączyć (pomieszać?) dwa pomysły w interfejsie użytkownika. Nie oznacza to, że nie można łączyć dwóch pomysłów z drugiej strony, tak aby cały kod był danymi; takie jest założenie seplenienia, które jest możliwe dzięki homoikoniczności i wykorzystywane przez jego system makro. Tak, te koncepcje brzmią podobnie, ale ich implikacje i zastosowania są bardzo różne w praktyce.

To może być redakcja, ale miejsca, które spotkałem, które chcą programowania „całkowicie opartego na danych”, naprawdę nie cenią swoich programistów. Myślą o kodzie jako o centrum kosztów, czymś, co należy zlecić na zewnątrz lub zignorować.

Masz na myśli, że twój szef chce, żebyś to napisał:

[
  {
    "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"
          ]
        }
      ]
    }
  }
]

Aby wygenerować to:

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

Pierwszy to JSON, a drugi to JavaScript .

Wyjaśnienie

Myślę, że teoretycznie nie jest tak, ponieważ rzecz, która interpretuje dane, musi zostać ukończona, aby opisać aplikację, więc właśnie przesunąłeś problem o jeden poziom wyżej, bez żadnej korzyści netto.

Czy taka aplikacja oparta w 100% na danych jest możliwa?

Właśnie tam zacząłem. Z moją odpowiedzią staram się zgodzić z oryginalnym postem, że: Jest to możliwe, ale masz rację, po prostu przeniesie problem o jeden poziom wyżej, bez [oczywistych] korzyści .

Sądzę, że można przekonująco argumentować, że każdą aplikację przeglądarki można uznać za opartą w 100% na danych ¹ .

Oczywiście nie czyni to łatwiejszym lub łatwiejszym do budowania aplikacji w Internecie, w rzeczywistości czyni je znacznie trudniejszymi.

Poinformuj swojego szefa, że ​​tworzy nową przeglądarkę internetową i że w końcu będzie musiał wymyślić JavaScript, aby zbudować coś dość skomplikowanego.

¹ Cóż, jeśli zignorujesz wtyczki, JavaScript i HTML5 .

Tak. O ile mi wiadomo, system taki jak Mathematica , który jest tak zwanym potężnym językiem programowania, ale zasadniczo jest powłoką, jest zbudowany na podobnej idei, której oczekiwał twój szef. Wolfram Mathematica staje się teraz na tyle skomplikowany, że można w nim łatwo wykonać wiele zadań obliczeniowych.

Oparte na danych to koncepcja. Jeśli my, programiści, zamierzamy manipulować danymi w prosty sposób, potrzebujemy powłoki, która jest dla nas łatwa do grania z danymi. Spróbuj zrozumieć, że kiedy zaczniemy mówić o nauce języka programowania opartego na składni, w rzeczywistości uczymy się interfejsu aplikacji lub po prostu jego powłoki. Jeśli rozumiemy powłokę, możemy sterować programami.

Jeśli chodzi o dane oparte w 100% na danych, jeśli kompilator lub interpreter może zrozumieć powłokę, obliczenia są sterowane. Jeśli dane mają taką samą strukturę podstawową jak powłoka lub interfejs, który ma, dane mogą być również sterowane przez kompilator lub interpreter. Myślę, że Mathematica jest dobrym wytłumaczeniem, dlaczego odpowiadam wam tak.