język, który opisuje wszystko za pomocą danych w formacie json lub xml - co to zmienia?

Załóżcie, że macie język, który po zainstalowaniu biblioteki umożliwia jej użycie, ale tylko wyłącznie poprzez wydanie polecenia zapisanego w xml / json. Prawdopodobnie padaka, ale proszę was o szczyptę wyrozumiałości. Spróbujcie się wczuć w tą sytuację i odpowiedzieć na pytanie do jakich potencjalne korzyści bądź zagrożeń może doprowadzić taka zmiana w języku?

To jakie znaczniki, bądź klucze/wartości można użyć jest określone w bibliotece i każda biblioteka interpretuje polecenie zapisane w xml / json i zwraca wynik/odpowiedź również jak xml/json.

Pytanie do was co taki ekosystem w języku zmienia?

Ja tutaj widzę pewne plusów np:

• efekty uboczne są opisane jako dane (więc pewnie łatwiej takie rzeczy dałoby się testować)

• skoro po obu stronach są dane to czy takie środowisko nie byłoby idealne do uprawiania FP?

• oprogramowanie można podzielić na bardzo ogólnego cienkiego klienta i konkretny serwer, gdzie klient nie musi w praktyce mieć zainstalowanej żadnej biblioteki z serwera tylko coś do samego przetwarzania tych danych w xml / json, podczas gdy serwer ma zainstalowane konkretne bibloteki

• zapewne skoro pisanie w języku oznaczałoby pracę z xml/json to wiele działań na tym dałoby się wyodrębnić do wspólnej puli operacji, być może te operacje dałoby się łatwo składać z poziomu wizualnego kreatora

Skąd założenie, że programowanie w XMLu miałoby jakkolwiek przybliżać nas do FP? Popatrz na to: https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/config/etc/jetty.xml Pisanie Javy w XMLu żadnego bezpieczeństwa nie dodaje, a przynajmniej ja tego nie widzę.

Niespecjalnie przychodzą mi do głowy zalety programowania w XMLu. Prawdopodobnie są podobne do zalet wstrzykiwania zależności przez XMLa - można coś pozmieniać w aplikacji bez jej ponownej kompilacji. Czy to coś nam realnie dało? Nie, nie w naszym modelu. Nie programujemy Javy w XMLu na produkcji. Wszystko i tak musi przejść przez ten sam proces - kompilacja, testy, deploy, kolejne testy i dopiero release nowej wersji na proda.

Wadą programowania w XMLu jest to, że trzeba do tego jakichś specjalnych sprytnych wtyczek, żeby było sensowne wsparcie od IDE. Ja czegoś takiego nie miałem, gdy programowałem w XMLu i dlatego poprawianie błędów składniowych to była mordęga. Poprawka, restart, grzebanie w logach, znowu poprawka, znowu restart, znowu grzebanie w logach, i tak do postradania zmysłów.

Natomiast jeśli chcesz zobaczyć przykład funkcyjnego języka programowania (przynajmniej tak się twórcy chwalą, nie drążyłem tematu) z edytorem wizualnym oraz reprezentacją tekstową to jest: https://www.luna-lang.org/ (twórcy są w trakcie przepisywania silnika z Haskella do Scali chodzącej na GraalVMie: https://github.com/enso-org/enso https://medium.com/@enso_org/help-test-enso-2-0-sign-up-for-the-pre-release-distribution-69b37048b4bc )

Ja bym uogólnił pytanie (bo XML / JSON to szczegół implementacyjny), popatrzył na zagadnienia dzieląc na:

• deklaratywne
• algorytmiczne

Czyste deklaratywne jest ograniczone do tego, co fabryka przygotowała.
W praktyce wiele/większość ma "wyciekającą abstrakcję" z elementami algorytmicznymi.

Nie rozumiem tej koncepcji....

ale Możesz zobaczyć XSLT - to język do transformacji XML - deklaratywny i nawet ciekawy. Formalnie nie jest funkcyjny - ale nie jest też imperatywny. Jakkolwiek nie polecem nigdzie indziej niż do pisania transformacji XML (do czego został stworzony).

Skąd założenie, że programowanie w XMLu miałoby jakkolwiek przybliżać nas do FP?

1. Bo program ciągle miałby dane na wejściu i dane na wyjściu, program klienta który tylko przetwarza tylko xmle mógłby być pozbawiony efektów ubocznych.
2. Bo dane łatwiej ze sobą składać niż obiekty.

Nie rozumiem tej koncepcji....

Wiem dziwne.. , ale to nie jest tak bardzo odległe jak mogłoby się wydawać. To trochę zbliżona postać do tego co mamy między mikroserwisami. Tam nie współdzielimy obiektów, a przesyłamy/odbieramy dane zapisane np. w json/xml :)

pan_krewetek napisał(a):

Skąd założenie, że programowanie w XMLu miałoby jakkolwiek przybliżać nas do FP?

1. Bo program ciągle miałby dane na wejściu i dane na wyjściu, program klienta który tylko przetwarza tylko xmle mógłby być pozbawiony efektów ubocznych.
2. Bo dane łatwiej ze sobą składać niż obiekty.

Pokaż przykład takiego kodu funkcyjnego w XMLu, który łatwiej składać niż obiekty. Na razie to nie wiadomo co masz na myśli, a nie będziemy się przecież domyślać jak przy czytaniu lektur szkolnych.

Weź też pod uwagę, że unifikacja kodu i danych to bardzo stary pomysł, bo opiera się na nim Lisp, w którym programowali nasi dziadowie: Lisp S-expressions

• efekty uboczne są opisane jako dane (więc pewnie łatwiej takie rzeczy dałoby się testować)

Jakie rzeczy? wywołania biblioteki mogę sobie naklepać w czystym języku, w dodatku jeśli jest to język statycznie typowany to trudniej popełnić błąd, bo mam sprawdzanie podczas kompilacji, a nie podczas testów

• skoro po obu stronach są dane to czy takie środowisko nie byłoby idealne do uprawiania FP?

Niekoniecznie. Lisp wyszedł z założenia, że dane i kod będą reprezentowane tak samo, ale:

• w Scheme się udało i jest to język funkcyjny
• w Common Scheme się nie udało i język ten posiada wiele imperatywnych rozszerzeń
• Haskell i Ocaml są funkcyjne mimo że kod nie wygląda jak dane

• oprogramowanie można podzielić na bardzo ogólnego cienkiego klienta i konkretny serwer, gdzie klient nie musi w praktyce mieć zainstalowanej żadnej biblioteki z serwera tylko coś do samego przetwarzania tych danych w xml / json, podczas gdy serwer ma zainstalowane konkretne bibloteki

Czyli jak ElasticSearch. Nie lubię ElasticSearcha wywoływanego po RESTcie za pomocą gołego Jsona i zawsze używam nakładki Javovej. W zasadzie wtedy też nie lubie, ElasticSearcha, ale mniej

• zapewne skoro pisanie w języku oznaczałoby pracę z xml/json to wiele działań na tym dałoby się wyodrębnić do wspólnej puli operacji, być może te operacje dałoby się łatwo składać z poziomu wizualnego kreatora

Nie po to uczę się Javy i Scali, żeby być programistą XMLa. Zwolniłbym się od razu jakbyś mi kazał coś takiego robić w pracy. Już to przerabiałem i nie jest to miłe.

Jaką ja widzę zaletę? Jeśli użytkownik końcowy może sobie oskryptować działanie aplikacji. Czasem to jest dobre. Ale wtedy trzebaby zaimplementowac pełny język w tym Jsonie z ifami i pętlami/rekurencją (taki minimalistyczny Scheme np)

Jakie rzeczy? - myślę, że logikę. Program podejmuje decyzje i generuje xmla z zadaniem do wykonania. Ty możesz wtedy skoncentrować się na testowaniu podejmowanych decyzji, testujesz wynik decyzji, i myślę, że jest to łatwiejsze, a i też prostsze niż korzystanie z mocków.

Czyli mówisz że miałbym testować użycie twojej biblioteki bez uzycia biblioteki, ale zamiast tego testować czy XML jest dobry? Trochę mi się to nie składa. Ale ja nie lubię testóœ jednostkowych. Zawsze jeśli się da to testuję integracyjnie. Jeśli twoja biblioteka nie łączy się ze swiatem zewnętrznym to na 95% będę ją testować integracyjnie

Pracowałem w XML Scripcie (ale wersja in-house).
Nie wiem jak można wpaść na taki pomysł. Jedynie ktoś kto nigdy nie napisał nawet grama kodu tokenizującego może wpaść na taki pomysł.

Ból d*&y jest tak duży przy takim rozwiązaniu, że jedyne co przychodzi do głowy to Zofia Naukowska:
"Ludzie ludziom zgotowali ten los." - Medaliony

Alternatywy:

• osadzenie istniejących enginów: Python, JavaScript
• napisanie swojego języka od biedy bazującego na Lispie

Edit: problemy:

• brak możliwości używania znaków które muszą być escapowane w kodzie (np. "&", ">"), w związku z czym warunki wyglądają tak: "a > b && c > 2"
• brak podstawowych struktur programistycznych - w zależności od wykonania - zawsze będzie czegoś brakować, np. pętli, funkcji, lambdy
• bardzo utrudnione debugowanie (o ile w ogóle możliwe)
• brak wsparcia dla reużywania kodu (np. biblioteki kodu)
• kod zaśmiecony tagami

I proszę mi nie wyjeżdżać z XSLT bo używałem i uważam też za chory pomysł - ze względu na nieintuicyjny flow programu.

Problem jaki widzę jest taki, że siła ekspresji czegoś takiego będzie bardzo niska. Są zresztą przecież juz takie rozwiązania, np. PLC można programować za pomocą Function-Block-Diagram który efektywnie jest opisany XMLem. Podobnie jest wiele Workflow Engine które bazują na opisie w XMLu. Zobacz sobie jak wygląda np. BPMN w postaci XMLa.
No i nie wiem jak dokładnie wygląda sprawa ze wsparciem takich rzeczy jak schema szczególnie jak chcesz robić akcje w stylu rekurencja.