Uniwersalny język programowania

Kilka razy zdarzało mi się, że tworzę program w jakimś języku czy jakiejś technologii, a jakiś czas później chcę mieć taki sam program w innej technologii. Czasami zdarza się, że już od początku chciałbym mieć dwa takie same programy, gdzie jeden jest na przykład w Java, a drugi w C#, a oba programy robią dokładnie to samo.

W biznesie to też się zdarza, np. jest portal webowy, a potem apka instalowana na telefonie (i nie jest to PWA, ani apka będąca pełnoekranową przeglądarką webową). Abo choćby przeglądarki internetowe, taka sama przeglądarka jest na PC, ale też jest na iOS (inny GUI, ale funkcjonalność podobna).

Moim zdaniem, w większości przypadków źródła programu można podzielić na dwie części, pierwsza to cześć "obliczeniowa", czyli cała logika, która jest taka sama, niezależnie od tego, w czym program jest zrobiony i to tak szacuję, jest 90% całego projektu. Dopiero pozostałe 10% to część "interfejsowa", czyli wytwarzanie GUI, odczytywanie zdarzeń z GUI, z bazy danych, połączenia sieciowe itp.

Taki przykład z życia wzięty: https://github.com/andrzejlisek/TextPaint
To są tak naprawdę dwa takie same programy w C#, jeden dostosowany do .NET Framework, drugi dostosowany do .NET Core. Część "interfejsowa" to tylko kilka plików (malowanie GUI, zdarzenia GUI, schowek systemowy, odczyt i zapis bitmap), a cała reszta to część "obliczeniowa", w której kody są identyczne w obu programach (ponieważ w tym przypadku, język jest ten sam). Ale załóżmy, że wymyślę sobie, że chciałbym mieć w C++ i Qt, to musiałbym napisać od nowa obie części programu. A potem, jak w części obliczeniowej coś zmienię, to zmiany musiałbym nanosić dwa razy osobno.

Pytanie jest takie: Czy istnieje "język programowania", w którym mogę napisać jakiś fragment programu, a najlepiej klasę obiektu, i ten kod byłby podstawą części obliczeniowej programu? To byłby taki uniwersalny transpilator (konwerter kodu źródłowego na kod źródłowy w innym języku). Jak chce mieć w C#, to robię transpilację do C#, Jak zapragnę mieć w Java, to nie muszę pisać ręcznie, tylko robię transpilację z tego uniwersalnego języka do Java i już mam 80% programu. Jak zapragnę mieć w JavaScript, to transpilacja i już jest.

Oczywiście nie oczekuję konwersji i transpilacji części interfejsowej, bo w każdej technologi obsługa GUI jest tak różna, że nie ma możliwości tego zautomatyzować. Np. chcąc mieć apkę desktopową i webową robiącą to samo, to sposób tworzenia okienka w powiedzmy Qt i sposób tworzenia GUI w HTML+CSS jest zupełnie odmienny i to bym ogarną ręcznie. A częśc obliczeniową to bym napisać w tym "uniwersalnym języku" i automatycznie konwertował do C++ i JavaScript. Potem i tak, większość zmian i ulepszeń jest w części obliczeniowej i wykonywałoby się jednokrotnie.

Ale konwersję klas obliczeniowych to chyba da się zautomatyzować, tym bardziej, że ręcznie da się przerobić niemalże 1:1. Konwerter Java -> C#, czy c#-> Java lub Java->JavaScript to chyba nie jest taka prosta rzecz, ale mając jakiś język uniwersalny, to chyba mógłby istnieć konwerter tego języka na co się chce. Coś na podobnej zasadzie, jak kompilatory GCC, który działa dwuetapowo, że w pierwszym etapie kompiluje program do LLVM, a w drugim etapie konwertuje z LLVM na postać docelową. JRE do Java i CLI do C# robi to samo, czyli konwersja do postaci pośredniej i ostateczna kompilacja w chwili uruchomienia. Jednak konwersja CLI->JRE i JRE->CLI nie jest możliwa.

andrzejlisek napisał(a):

Pytanie jest takie: Czy istnieje "język programowania", w którym mogę napisać jakiś fragment programu, a najlepiej klasę obiektu, i ten kod byłby podstawą części obliczeniowej programu? To byłby taki uniwersalny transpilator (konwerter kodu źródłowego na kod źródłowy w innym języku). Jak chce mieć w C#, to robię transpilację do C#, Jak zapragnę mieć w Java, to nie muszę pisać ręcznie, tylko robię transpilację z tego uniwersalnego języka do Java i już mam 80% programu. Jak zapragnę mieć w JavaScript, to transpilacja i już jest.

A nie lepiej robić odwrotnie?
Piszesz program w jakimkolwiek języku, a potem kompilujesz do low-levelowego targetu, które inne programy rozumieją?
np.

• kompilacja do natywnej libki
• do WebAssembly
• do innego języka będącego targetem (np. do JavaScript, C itp.)
• do JVM
• komunikacja w inny sposób np. przez HTTP, wtedy może to być pisane w różnych językach, ale programy i tak mogą ze sobą "gadać"

No i odpowiednie bindingi

Czyli osiągasz cel współpracy między różnymi językami, ale nie bezpośrednio, tylko przez wspólny standard + bindingi.

Albo jeszcze inaczej. Jeśli to język skryptowy (np. często używane są Lua, Python, JavaScript jako języki skryptowe do robienia np. wtyczek do programów), to można zamiast kompilować, po prostu osadzić wirtualną maszynę w programie docelowym. Więc logikę masz w języku skryptowym, który jest w różnych programach osadzany.

Java->JavaScript to chyba nie jest taka prosta rzecz, ale mając jakiś język uniwersalny, to chyba mógłby istnieć konwerter tego języka na co się chce.

Myślałem o tym, żeby zrobić konwerter Pythona na JavaScript. Ale myślę, że nie byłoby to takie proste - trzeba byłoby przekonwertować również bibliotekę standardową. Poza tym różne zewnętrzne biblioteki do Pythona (np. te do Machine Learning?) też nie zawsze są tylko w Pythonie pisane, ale częściowo w C++, więc pytanie co z nimi? (pewnie, C++ też da się kompilować do JS albo Wasm, ale to zwiększałoby komplikację problemu).

Jeszcze rozkminiam też, czy nie dałoby się zamiast kompilować Pythona na JS, to skompilować bajtkod Pythona (pliki *.pyc) na JS, może byłoby łatwiej. Chociaż ten bajtkod też wcale nie jest aż taki niskopoziomowy, więc nie wiem.

Czy istnieje "język programowania"

Taki uniwersalny język programowania albo musiałby być dużym przedsięwzięciem, albo musiałby być bardzo prosty, prymitywny wręcz, żeby łatwo się dało przekompilować.

Jest coś takiego jak język Fusion, zaprojektowany z myślą o tym żeby kod napisany w nim dało się transpilować do C, C++, C#, D, Javy, JavaScript, Python, Swift, TypeScript oraz OpenCL. Pewnie kolejne języki jeszcze dojdą.

W języku Fusion są tylko te elementy programistyczne (klasy, tablice, funkcje) które da się łatwo przemapować na odpowiedni element w obsługiwanym języku. Dla przykładu, nie ma liczb unsigned 32-bitowych, bo mimo że C i C++ je mają, to Java i JavaScript ich nie mają, więc liczby unsigned w Fusion są 31-bitowe, żeby dało się je zmapować do tych języków właśnie.

https://github.com/fusionlanguage/fut

Przede wszystkim żadne konwertery nie mają sensu bo rezultat będzie zawsze kiepski. Co do uniwersalności to jest bardziej kwestia technologii, a nie samego języka jako takiego. Możesz przyjrzeć się rozwiązaniom już istniejącym i może to działać na kilka sposobów:

• oddzielenie logiki od rzeczy platform specific, czyli masz wspólny core dla każdej platformy i dodatkowo musisz dopisać obsługę każdej platformy, w różny sposób. Tak działa np Kotlin Multiplatform: https://kotlinlang.org/docs/multiplatform.html i o ile kojarzę to chyba Xamarin też kiedyś próbował czegoś takiego

• dokładnie ten sam kod, który kompliluje się na wszytkie platformy. Np na desktop rezultatem kompilacji jest .exe, na web kod js+html, a na Androida plik apk. Tak działa Flutter: https://flutter.dev/ - w zasadzie to działa trochę analogicznie jak Kotlin, ale rzeczy specyficzne dla platformy są ograniczone do niezbędnego minimum i automatycznie generowane przez framework i jest to tylko minimalny launcher, który ma za zadanie uruchomić Fluttera, czyli kod pisany przez programistę. Więc teoretycznie możesz napisać swój program i niczym więcej się nie przejmować, kompilujesz program na taką platformę jak potrzebujesz (teoretycznie bo zawsze są pewne niuanse, które trzeba brać pod uwagę)

• jeden plik wynikowy możliwy po kompilacji do uruchomienia na kilku platformach, jak .jar z Javy. To w zasadzie nie wyszło i nie jest możliwe na każdej platformie, bo nie na każdej można zainstalować jdk

  Przy czym jak ostatnio sprawdzałem, to Kotlin jeszcze się nie nadawał do użycia, a Flutter zrobił spory postęp i na dzień dzisiejszy jest już stabilna obsługa wszystkich platform (Windows/Mac/Linux/Android/iOS/Web)

Dopiero pozostałe 10% to część "interfejsowa", czyli wytwarzanie GUI, odczytywanie zdarzeń z GUI, z bazy danych, połączenia sieciowe itp.

Na pewno? Mam wrażenie, że jest dokładnie odwrotnie. W moim odczuciu domena aplikacji i to, jaki problem rozwiązuje, to jest zdecydowanie mniejsza część kodu. Większość kodu to klej, który skleja tę logikę ze światem zewnętrznym.

kelog napisał(a):

Dopiero pozostałe 10% to część "interfejsowa", czyli wytwarzanie GUI, odczytywanie zdarzeń z GUI, z bazy danych, połączenia sieciowe itp.

Na pewno? Mam wrażenie, że jest dokładnie odwrotnie. W moim odczuciu domena aplikacji i to, jaki problem rozwiązuje, to jest zdecydowanie mniejsza część kodu. Większość kodu to klej, który skleja tę logikę ze światem zewnętrznym.

Zależy od aplikacji.

Jeśli robisz CRUD'a, to faktycznie. Jeśli robisz jakeś wąskie narzędzie branżowe, to może być tak że domena aplikacji to jest 90%.

LukeJL napisał(a):

Taki uniwersalny język programowania albo musiałby być dużym przedsięwzięciem, albo musiałby być bardzo prosty, prymitywny wręcz, żeby łatwo się dało przekompilować.

A dlaczego nie może być skomplikowany, szkoda Ci komputera, bo się zmęczy przy kompilowaniu?

andrzejlisek napisał(a):

Pytanie jest takie: Czy istnieje "język programowania", w którym mogę napisać jakiś fragment programu, a najlepiej klasę obiektu, i ten kod byłby podstawą części obliczeniowej programu? To byłby taki uniwersalny transpilator (konwerter kodu źródłowego na kod źródłowy w innym języku). Jak chce mieć w C#, to robię transpilację do C#, Jak zapragnę mieć w Java, to nie muszę pisać ręcznie, tylko robię transpilację z tego uniwersalnego języka do Java i już mam 80% programu. Jak zapragnę mieć w JavaScript, to transpilacja i już jest.

Pomysł dobry i możliwe że realizowalny w praktyce ale ja bym zadał sobie inne pytanie: czy jeśli mamy uniwersalny język oprogramowania to czy potrafimy do niego stworzyć uniwersalny zestaw testów?

Takim językiem musi być coś co:

• jest samowystarczalne, żadnych bibliotek linkowanych gdziekolwiek
• nie ma runtimu/minimalny runtime przez co nie ma problemu z łączeniem różnych modułów z wielu bibliotek w programie wynikowym
• ma prosty interfejs: proste struktury danych tj. tablica, struktura i w sumie to tyle czyli taka część wspólna wszystkich popularnych języków

Takim językiem mógłby być dowolny język kompilowany do kodu bajtowego LLVM np. C, C++ czy Rust wystawiający interfejs języka C. Takiego kodu można użyć:

• w innych natywnych językach poprzez interfejs C
• w Javie poprzez interfejs z C albo GraalVM i projekt Sulong
• w Pythonie poprzez bindingi
• JS poprzez WebAssembly i Emscripten

Problem jest taki, że taki interfejs byłby biedny, bo nie miałby wielu dostępu do wielu ficzerów takich jak złożone struktury danych.

Według mnie najlepszy rozwiązaniem jest użycie Rusta (samowystarczalny, wspaniały tooling, szybki) do napisania logiki i użycie jej poprzez biblioteki, które generują przyjemne interfejsy do języków docelowych np. https://github.com/dtolnay/cxx , https://github.com/PyO3/pyo3 , https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_Wasm

No a takim językiem nie jest w zasadzie C++ / Rust? Przecież możesz sobie w nich napisać główną logikę aplikacji i konsumować potem z praktycznie dowolnego języka w postaci libki.
Po co "uniwersalny język" skoro mamy już języki które mogą być używane w dowolnych innych.

No i w zasadzie C# jest takim uniwersalnym językiem poza embedded. Po co ci aplikacja w javie jeśli masz ją już w c#?

obscurity napisał(a):

No a takim językiem nie jest w zasadzie C++ / Rust? Przecież możesz sobie w nich napisać główną logikę aplikacji i konsumować potem z praktycznie dowolnego języka w postaci libki.

Dokładnie. I zapakować do libki natywnej + przekompilować do WebAssembly. A jak coś dalej nie śmiga, to łączyć się po socketach. I już.

Idąc tym tokiem rozumowania to możesz sobie napisać webserwis i konsumować go w dowolnym języku. Napisz sobie logikę aplikacji, wystaw webserwis i gui możesz mieć w dowolnym języku. Zamiast webserwisu można użyć dowolnej innej metody komunikacji, niekoniecznie po http

no i tak się robi, apki pisane w electronie czy uwp jako frontend a komunikują się z serwisem uruchomionym jako usługa i rpc. Dzięki temu nie mają żadnych ograniczeń w działaniu i sam "backend" może być napisany w dowolnym języku

Wiem że tak się robi. Nie rozumiem jednak sensu pomysłu uniwersalnego języka, który byłby tłumaczony na inne języki. Gdyby coś takiego powstało nawet, to właśnie logikę byłoby łatwiej przetłumaczyć niz gui, bo wtedy wystarczyłoby przetłumaczyć samą składnię. W przypadku gui, na różnych platformach wymagana może być inna konfiguracja, inne zasoby jak np pliki graficzne i inne pomocnicze itd. Gdyby nawet się udało to zrobić, to te tłumaczenie musiałoby działać w kontekście platformy i frameworka, a nie tylko języka

loza_prowizoryczna napisał(a):

andrzejlisek napisał(a):

Pytanie jest takie: Czy istnieje "język programowania", w którym mogę napisać jakiś fragment programu, a najlepiej klasę obiektu, i ten kod byłby podstawą części obliczeniowej programu? To byłby taki uniwersalny transpilator (konwerter kodu źródłowego na kod źródłowy w innym języku). Jak chce mieć w C#, to robię transpilację do C#, Jak zapragnę mieć w Java, to nie muszę pisać ręcznie, tylko robię transpilację z tego uniwersalnego języka do Java i już mam 80% programu. Jak zapragnę mieć w JavaScript, to transpilacja i już jest.

Pomysł dobry i możliwe że realizowalny w praktyce ale ja bym zadał sobie inne pytanie: czy jeśli mamy uniwersalny język oprogramowania to czy potrafimy do niego stworzyć uniwersalny zestaw testów?

Jeżeli owe testy i asercje mają dotyczyć tylko logiki obliczeniowej, to one mogłyby być zaimplementowane również w tym uniwersalnym języku, bądź w jednym z języków docelowych. Jeżeli testuje się jakiś algorytm obliczeniowy wraz z przypadkami brzegowymi, to nie ma żadnej różnicy, w jakim języku to będzie, działanie będzie identyczne. A jak testuje się GUI, to test musiałby być w każdym docelowym języku, bo i tak nie da się zrobić uniwersalnego języka do GUI.

Riddle napisał(a):

kelog napisał(a):

Dopiero pozostałe 10% to część "interfejsowa", czyli wytwarzanie GUI, odczytywanie zdarzeń z GUI, z bazy danych, połączenia sieciowe itp.

Na pewno? Mam wrażenie, że jest dokładnie odwrotnie. W moim odczuciu domena aplikacji i to, jaki problem rozwiązuje, to jest zdecydowanie mniejsza część kodu. Większość kodu to klej, który skleja tę logikę ze światem zewnętrznym.

Zależy od aplikacji.

Jeśli robisz CRUD'a, to faktycznie. Jeśli robisz jakeś wąskie narzędzie branżowe, to może być tak że domena aplikacji to jest 90%.

Przykładowy projekty
https://github.com/andrzejlisek/Cobra1 - emulator polskiego prymitywnego komputera "Cobra 1".
https://github.com/andrzejlisek/XorFile - program generujący pakiety plików (przewidywana mała liczba dużych plików w pakiecie) i generujący dwa pakiety redundatne, gdzie po zgubieniu dowolnych dwóch pakietów da się odtworzyć brakujące.
https://github.com/andrzejlisek/TextPaint - wielofunkcyjny program będący dość nietypowym edytorem tekstu, przeglądarką ANSI-art i terminalem Telnet/SSH.

W przypadku C++ korzystam z Qt, a w przypadku C# korzystam z WinForms i Avalonia. Wszystkie projekty są tak wymyślone, żeby było jak najmniej plików współpracujących z GUI. W razie czego, jak mi się odwidzi i będe chciał zastapić Qt WxWidgets, a WinForms zastąpić MAUI, to wystarczy przerobić te parę funkcji, czyli od początku zrobić formatki i dopisać zdarzenia GUI i tyle, cała reszta, czyli lwia część kodu zostaje bez zmian. Te programy to w mojej opinii raczej są "branżowe" niż zwykłe CRUDy.

Dokładnie taki był zamysł wirtualnej maszyny javy (JVM) i środowiska uruchomieniowego "wspólnego języka" - CLR czyli Javy i .NET
Piszesz raz, a CLR / JVM zajmuje się przetłumaczeniem tego na kod maszynowy.

Dobrze rozumiem że chcesz stworzyć uniwersalny język żeby przenosić kod między dwoma uniwersalnymi językami?
Po co ci aplikacja w JavaFX skoro masz już w MAUI? Możesz przejść na np uno i wspierać jednym kodem iOS, Android, Windows UWP, MacOS, MacOS-Catalyst, Windows WPF, WinUI, WebAssembly i Linux GtK. Nie tylko logika aplikacji będzie wspólnym kodem ale część odpowiedzialna za GUI też.

andrzejlisek napisał(a):

Ale zawsze mozna ręcznie zrobić klasę będącą bitmapą, która ma takie same pola i metody w obu językach, a w sobie miałaby prywatne pole bitmapy typu właściwego dla danej technologii.

Właśnie to robi MAUI / Uno

andrzejlisek napisał(a):

Taki przykład z życia wzięty: https://github.com/andrzejlisek/TextPaint
To są tak naprawdę dwa takie same programy w C#, jeden dostosowany do .NET Framework, drugi dostosowany do .NET Core. Część "interfejsowa" to tylko kilka plików

Nie przeglądałem kodu ale nie tak się to robi. Po to powstał .NET Standard - wspólny interfejs między Core i Framework. Potem tylko targetujesz oba frameworki na raz i masz wyjściowe projekty ze wspólnej bazy kodu. Ewentualnie w kodzie czasem może być potrzebny jakiś #IF. Masz też polyfille - https://github.com/Sergio0694/PolySharp/

andrzejlisek napisał(a):

gajusz800 napisał(a):

Wiem że tak się robi. Nie rozumiem jednak sensu pomysłu uniwersalnego języka, który byłby tłumaczony na inne języki. Gdyby coś takiego powstało nawet, to właśnie logikę byłoby łatwiej przetłumaczyć niz gui, bo wtedy wystarczyłoby przetłumaczyć samą składnię. W przypadku gui, na różnych platformach wymagana może być inna konfiguracja, inne zasoby jak np pliki graficzne i inne pomocnicze itd. Gdyby nawet się udało to zrobić, to te tłumaczenie musiałoby działać w kontekście platformy i frameworka, a nie tylko języka

Od początku podkreslam, że uniwersalny język do napisania całego programu i tak nie jest możliwy. Mi chodzi tylko o uniwersalny język do samej logiki obliczeniowej. Chce mieć apkę w C#+MAUI i w Java+JavaFX. Osobno robię tylko GUI i zdarzenia, a klasy zawierające kod niezależny od GUI robię w tym "uniwersalnym języku" i tylko kopiuję kod wytworzony przez narzędzie transpilujące. Nawet ręcznie pisząc, można "szablonowo" przerobić taką klasę z Java na C# i odwrotnie.

Nawet, taka rzecz, jak bitmapy, to co technologia to ma inne funkcje i inaczej wygląda malowanie na nich. Ale zawsze mozna ręcznie zrobić klasę będącą bitmapą, która ma takie same pola i metody w obu językach, a w sobie miałaby prywatne pole bitmapy typu właściwego dla danej technologii.

Ale po co sobie utrudniać gdy są technologie, gdzie piszesz cały program raz i kompilujesz na każdą platformę ten sam kod, łącznie z GUI? Po co ci potrzebne C# i JavaFX? Potraktuj to jako uniwersalny język programowania, w którym napiszesz cały program.

Jak dotąd to wygląda na to, że walczysz z problemami, które sobie sam wymyśliłeś

andrzejlisek napisał(a):

Jeżeli owe testy i asercje mają dotyczyć tylko logiki obliczeniowej, to one mogłyby być zaimplementowane również w tym uniwersalnym języku, bądź w jednym z języków docelowych. Jeżeli testuje się jakiś algorytm obliczeniowy wraz z przypadkami brzegowymi, to nie ma żadnej różnicy, w jakim języku to będzie, działanie będzie identyczne. A jak testuje się GUI, to test musiałby być w każdym docelowym języku, bo i tak nie da się zrobić uniwersalnego języka do GUI.

No ale jeśli uniwersalny język jest wewnętrznie sprzeczny to jak testy w nim napisane udowodnią że są wewnętrznie sprzeczne? To tautologia.

Przypomnę tylko że Scala miała być takim językiem. Czyli kompilowanym zarówno do JVMa jak i do bytecodu .NET. I sprawa rozbiła się o odmienne działanie generyków. Przynajmniej oficjalnie.

KamilAdam napisał(a):

Przypomnę tylko że Scala miała być takim językiem. Czyli kompilowanym zarówno do JVMa jak i do bytecodu .NET. I sprawa rozbiła się o odmienne działanie generyków. Przynajmniej oficjalnie.

No widzisz, wychodzi na to że cechą uniwersalnego języka są niedopowiedzenia. Weź takie C - w cholerę undefined behaviour, różnic w zachowaniach stdlib na różnych archi a to chyba najbardziej uniwersalny język w użyciu.

KamilAdam napisał(a):

Przypomnę tylko że Scala miała być takim językiem. Czyli kompilowanym zarówno do JVMa jak i do bytecodu .NET. I sprawa rozbiła się o odmienne działanie generyków. Przynajmniej oficjalnie.

To zabawne. Bo scala native działa (bez szału, ale działa), a na x86 wsparcie dla generyków jest nawet gorsze niż w JVM :-)

Ale co do tematu to Scala jest całkiem wieloplatformowa:
a) jvm
b) scalajs - to normalna Scala i jeśli chodzi o język niczego jej nie brakuje (kompilowana do JS), całkiem zresztą się sprawdza (jako alternatywa dla TS)
c) scala native - działa, ale wyraźnie odstaje jakościowo od powyższych

Korzystałem ze Scali, żeby np. mieć te same API na front i na serwerze, takie same walidacje danych i nawet te same obliczenia (kalkulator ubezpieczeń).

jarekr000000 napisał(a):

KamilAdam napisał(a):

Przypomnę tylko że Scala miała być takim językiem. Czyli kompilowanym zarówno do JVMa jak i do bytecodu .NET. I sprawa rozbiła się o odmienne działanie generyków. Przynajmniej oficjalnie.

To zabawne. Bo scala native działa (bez szału, ale działa), a na x86 wsparcie dla generyków jest nawet gorsze niż w JVM :-)

Tak. Błędem było to że chcieli użyć .netowe generyki. Trzeba było je olać i napisac własne od poczatku obok. Z drugiej strony nie wiem co na to M$ który zdaje się na poczatku sponorował projekt. Może taka propozycja padła i dlatego przestał sponsorować ?

jarekr000000 napisał(a):

Korzystałem ze Scali, żeby np. mieć te same API na front i na serwerze, takie same walidacje danych i nawet te same obliczenia (kalkulator ubezpieczeń).

Trafiłem na sytuację gdy domyślny toString był inny na ScalaNative :P A że użyłem tego w teście to albo test przechodził na JVM/JS, albo dla Native :D

Z dawnych lat pamiętam https://haxe.org, znałem człowieka co się tego uczył w czasach Flasha i ActionScriptu. Ale czy to jest dobre to nie wiem, bo nie korzystałem.

Dla najpopularniejszych języków takich jak C, Java, C#, Python możesz sobie wyrysować logikę w Enterprise Architect i wygenerować kod. Jakość jest „średnia”, ale o dziwo działa. Przy czym dużo zależy jak „głębokie” UMLe chcesz rysować. Jakieś 99% użytkowników kończy na wyrysowaniu zależności i zdefiniowaniu listy metod i własności. Wtedy dostajesz kod z pustymi ciałami, które trzeba wypełnić. Da się jednak wejść głębiej i rozrysować logikę działania poszczególnych metod. Wtedy wygenerowany zostanie bardzo paskudny kod.
Możesz wziąć Web Methods IS, w którym wyklikasz flow i maszyneria wygeneruje odpowiednie klasy. Przy czym tutaj jesteś ograniczony do standardowych komponentów, bo WMIS ma trochę inne zadania.

Przy czym takich narzędzi, które potrafią sobie poradzić z UMLem i przetłumaczyć go na taki czy inny język programowania jest trochę. Stety, niestety kod generowany będzie zawsze paskudnie wyglądać i będzie miał niską czytelność. To przekłada się na koszty związane z utrzymaniem takiego czegoś. A w przypadku błędnego działania trzeba szukać odpowiedzi, czy błąd jest gdzieś w metajęzyku, czy jednak w transpilatorze, a może głębiej w kompilatorze konkretnego języka.

Kiedyś ktoś chciał stworzyć coś takiego jak uniwersalny język którym mieliby komunikować się wszyscy, a przynajmniej więdzkość ludzi na tej planecie. Ów język nazwali esperanto. Dziś mało kto pamięta o takim tworze. Dlaczego takowy nie ma sensu to można książki o tym pisać.

Mi memoras

BTW teraz mamy de facto 5 czy 6 różnych esperanto Walczących o dominację na świecie. Angielski, hiszpański, rosyjśki, mandaryński, arabski klasyczny (?), i może francuski w paru dziwnych miejscach Afryki.

I podobnie z językami programowania. Na Tiobe 5 topowych języków zgarnia ponad połowe rankingu. Gdzie ranking jest ustalany według ilości informacji w wyszukiwarkach internetowych. Na PyPL wygląda to podobnie, z jeszcze większą dominacją Pythona.
Wniosek - trzeba by zrobić generator z typowanego Pythona żeby to miało szanse chwycić

BurgundowyKangur napisał(a):

Kiedyś ktoś chciał stworzyć coś takiego jak uniwersalny język którym mieliby komunikować się wszyscy, a przynajmniej więdzkość ludzi na tej planecie. Ów język nazwali esperanto. Dziś mało kto pamięta o takim tworze. Dlaczego takowy nie ma sensu to można książki o tym pisać.

To Chomsky jeszcze dycha?

Uniwersalizm to pewien koncept filozoficzny który od czasów pradawnych jest wdrażany w róznych dziedzinach życia. Właściwie nigdy i nigdzie się nie sprawdził. W naszej branży moda na języki uniwersalne, platformy low code / no code sięga lat 80 ubiegłego wieku. Temat wraca mniej albo bardziej co dekadę. Autorzy popełniają te same błędy co ich poprzednicy.