[RFC] Következő generációs programozási nyelv

Sok vita van arról kell-e még egy programnyelv, vagy bármi más. Sikerült alkotnom egyet több-kevesebb sikerrel, ami sok mindenben különbözik a meglévőektől. Majd idővel kiderül mennyire hasznos. Eredetileg csak egy ambiciózus gondolatkísérlet volt, mára kezd használható formát önteni. Végleges neve még nincs (kódnév: AI/Lang). Hátha érdekel valakit, vagy van jó gondolata merre kellene még fejlődnie.

Jellemzők:

  • nem valami ellen készült (pl. más programnyelv valamilyen hibája, problémája)
  • nem egy meglévő dolog klónja, de nincs újra feltalálva a melegviz
  • a core váz lecsupaszított klasszikus OO (C# és D-hez hasonló)
  • tervezési szemlélet: dinamikus és bővíthető ("lisp rugalmasság")
  • verzionált adatbázis központú, nincs klasszikus fordítási egység
  • szemantikus háló alapú címkézés/információk a humán és AI értelmezéshez (opcionális)
  • publikus AST és moduláris nyelvtan (DSL)
  • transzformációs lehetőségek
  • referencia számlált csomópontok meta hívásokkal (mindenhol alkalmazható: @name, @type, @string, ...)
  • mindenhez hozzárendelhető attribútumok
  • validáció és megszorítások (hasonló a xml schema-hoz)
  • erőforrás definiálás/lekérdezés (statikus adatokhoz és kódfeldolgozáshoz is)
  • absztrakt osztály a definíciókhoz/transzformációhoz/dokumentációhoz
  • célközönség: dev/devops (a funkcionalitás elsőrendű, sebesség kisebb prioritású)
  • Python és C++ konverziós lehetőség a gyors/stabil/telepíthető kódváltozathoz (végfelhasználás)
  • 'munkaterek': többverziós feldolgozás, mélyebb szeparáció a névterek mellett
  • implicit használható értelmezők/feldolgozok (*inline, *parser)

Előnyök/hátrányok:

  • nagyon moduláris és dinamikus, majdnem minden lecserélhető/helyettesíthető, kevés a megkötés
  • dinamikusan generált kód futtatás (biztonsági házirenddel letiltható)
  • esetenként a szokásosnál nagyobb overhead, viszont jobban automatizálható (tesztelés/validáció/verziókövetés/...)
  • a szabadság és megszorítás közötti egyensúlyt a DSL-eknél, projekteknél és a munkaterekben lehet hangolni

Megjegyzések:

  • csillag (*) a kulcsszavak előtt a nem végleges szintaxis miatt van
  • még nincsenek funkcionális elemek (lambda, ...)
  • a weboldalon egy eléggé korlátozott verzió fut
  • van hozzá értelmező is, binárist C++ nyelven keresztül fordít
  • nyílt forrás tervbe van véve, de még sok a "proof of concept" kód
  • néhány dolgot finomítani kell, de legalább működik
  • részletes dokumentáció még nincs készen
  • a tervezett képességek nagyjából 90%-a van működőképes formában

Feltettem egy kipróbálható változatot példakódokkal együtt.

Érdekelne a véleményetek róla, vagy csak a next-gen nyelvekről általában.

Hozzászólások

Szerkesztve: 2020. 10. 29., cs - 18:44

VM-only, vagy tud binárist is fordítani? (Vagy ez le volt valahol írva, csak kiszúrta a szemem?)

Sz*rk: Ok, látom, közben hozzáadtad, hogy C++-on keresztül fordít binárist.

subscribe

szélsőségesen idealista, fősodratú hozzászólás

Szerkesztve: 2020. 10. 29., cs - 19:23

Gratulálok hozzá, komoly dolog egy normális programozási nyelv kitalálása és implementálása. Egyszer ráveszem magam, de én csak egy történelmi FORTH gépezetet akarok elejétől végéig megalkotni. Remélhetőleg az nem lesz magas léc. :)
Programozási nyelv terén nálam a Rust szemlélete az utóbbi években mindent visz.

Köszönöm, igyekszem a lehető legjobban megvalósítani. A Rust tényleg nagyon hasít és gyorsan fejlődik, kiváló a numerikus feladatokhoz. Az általános feladatok mellett inkább a tudásreprezentációhoz és a hozzá kapcsolódó feldolgozási feladatokhoz szeretném inkább a szoftverem képességeit kidomborítani.

Talán mert fejlődik a világ? :)  A microservices is az ontológia irányába megy, az AI sem csak mélytanulásból áll, az internet is egyre inkább a szemantikus web fele tart. Miért ne lehetne egy új nyelv, ami ötvözi a klasszikus programozást és az új irányokat, technológiákat?

A példák bővülni fognak nemsokára, a WebAssembly portolás kötötte le az energiámat. Eléggé korlátozott verziót tudtam először feltenni, sok minden nem fut még. Ha kiteszek binárist, akkor biztosan kevesebben telepítik, mint amennyien a weboldalt próbálgatják. Első körben nem akartam olyan példát kitenni, ami nem próbálható ki. Kis türelmedet kérném.

Most én vagyok vaksi, vagy az tényleg nincs benne a példakódokban, hogy hogyan kell egy függvény deklarációjában paramétereket megadni?

Az

*entrypoint main ()
{
    //akármi
};

nekem kicsit redundánsnak tűnik, nem elég annyi, hogy:

*entrypoint
{
    //akármi
};

A több fájlban lévő forráskódot hogyan tervezed megoldani? (Tehát mi lesz: import, #include, vagy saját megoldás?)

Egyébként nekem tetszik, gratulálok.

Psszt, elárulom az IP-címemet: 192.168.0.14

Még kevés példa van kint, azok is egyszerűek. A 'Tömb' nevűben van egy függvény deklaráció, lényegében semmi extra nincs benne. A belépési pont neve akkor nem számít, ha csak egy fájlban (vagy stringben, mint a weboldalon) levő dolgot kell végrehajtani. Javítottam a kommentet. Megoldható lett volna, hogy más-más néven az összes példa betöltődik, és a névvel lehet meghívni őket. De így nem kell kitalálni hogy hívják az indítót. Inkább szemantikai jelentősége van, jelenleg annyi a megkötés, hogy érték nélkül kell meghívni az üres belépési pontot. Természetesen az általános típus string tömb (Store::Vector<Data::String>).

A több fájl betöltése elég más, mint a többi nyelvnél. Tárolók (System::Repository) vannak, ezekbe kell betölteni egyenként, vagy akár .zip fájból. A teszt oldalon egy context, egy raktár és egy értelmező van, minden futás után törlődnek. Lehet túlságosan modulárisra sikerült, egy feltöltött raktár futtatható, validálható, módosítható, transzformálható, kereshető, elmenthető, másolható (majdnem mint egy git repó). Egyszerűbb példát tettem fel 'tároló és futtatás' néven.

Valami ilyet tegyél a nyitóba és akkor nincs megállás :)

 

Hello everybody out there writing code -

I'm doing a (free) next gen programming language (just a hobby, won't be big and
professional like C or Java). This has been brewing for a while now, and is starting to get ready.

Sokat nem gondolodtam rajta, írtam ami eszembe jutott. A valóság az, hogy hobbinak indult, nagy lett, használható is, szerintem van jövője, időm most nem sok, másnak lehet, professzionális is lehet még, engem is jobban érdekel ha mást is. Ezt már nehezebb szépen megfogalmazni. De tetszik amit írtál.

Csak a Furornak van egyedül jövője, kár erőlködni....

Hivatásos pitiáner
neut @

Laikusként, miért dupla kettőspont, eggyel nem lehet megoldani?

Store::Vector<Data::String>

Teljen jogos kérdés, szintén soknak gondolom. Viszont az esztétika és az egyértelműség is fontos szempont. Valóban a C++ nyelvből jött az ötlet. Kibővítve a kérdés így hangzik: hogyan lehet az alábbi kódot egyszerűsíteni? Dupla kettőspont helyett lehetne pont (mint a Jávánál), de akkor összefolyik pár dolog és nincs szinkronban a sima kettősponttal. Nekem picit furcsa az egy kettőspont, de még bármin lehet változtatni.

*alias Prefix::Namespace:{workspace}: other;

[std:id="ID"]
*function bool func1 ([std:out] Store::Vector<Data::String> list) {
    :other::Class source;
    list = source.getList();
    *return !list.empty();
};

Csak egy belső munkatér van importálva mindenhol. Jelenleg megoldatlan probléma, hogy a beolvasott kód nem megy át típusellenőrzésen mielőtt a raktárba kerül, csak végrehajtáskor. Kereséskor meg elég költséges megoldás a típusfeloldás, ezért vannak még mindig teljes típusok megadva amiket aliassal lehet egyszerűsíteni.

Szerkesztve: 2020. 10. 31., szo - 16:11

Hogy szemléltessem minek ez a cécó, minek megint egy +1 dolog, mi ez az egész? Kitaláltam egy kissé bugyuta példát. Mit csinál az alábbi C++ kód?

class ZvgT {
    public:
    char* UunuGIitz;
    void Hubtouzh (const char *jHbzztv);
    void loKuHujJju (const char *IJ7zh77);
    void dfnvdH (const char *jEzGFzfbs);
};

int main (int, char*[]) {
    ZvgT Iugz;
    Iugz.Hubtouzh("Ijhuugt2");
    char kiKbgtC[] = {0x32, 0x32, 0x64, 0x32, 0x64, 0x64, 0x32, 0x64};
    Iugz.dfnvdH (kiKbgtC);
    Iugz.loKuHujJju ("lerCOsiiuNjub");
    return 0;
}

Nagyjából ennyit lát a fordító, a hibakereső meg mennyiségi minta hiányában jópár AI dolog.

*triplets {
    ZvgT gfx:type gfx:Class;
    ZvgT::UunuGIitz gfx:type gfx:canvasBuffer;
    ZvgT::UunuGIitz gfx:canvasSize "127x127";
    ZvgT::Hubtouzh procCpp:callType gfx:createCanvas;
    ZvgT::Hubtouzh procCpp:callType gfx:loadBackgroundFromFile;
    ZvgT::Hubtouzh procCpp:callType procCpp:initialization;
    ZvgT::loKuHujJju procCpp:callType gfx:finishCanvas;
    ZvgT::loKuHujJju procCpp:callType gfx:saveCanvasToFile;
    ZvgT::loKuHujJju procCpp:callType procCpp:finalization;
    ZvgT::loKuHujJju procCpp:require procCpp:initializedState;
    ZvgT::dfnvdH procCpp:callType gfx:drawBox;
    ZvgT::dfnvdH procCpp:require procCpp:initializedState;
};

A fentiekkel együtt sokkal világosabb a kép. Van egy egyszerű C++ kódtöredék, meg némi RDF adat. A sorrendiség ellenőrzését is könnyű megoldani. Eddig szépen hangzik. Amikor a fentiekhez hasonlóan egy valós méretű szoftvert kellene ellenőrizni/kiértékelni, akkor jön a komoly fejfájás. Mindegyik általános nyelv nagyon komplex.

C-re gondoltam. Tapasztalatom az, hogy ha valami nem elérhető, akkor az átlag programozó szemet huny az ilyen "apróság" felett, a sérülékenység (hibás számítás lehetősége) pedig szépen megbúvik a kódban.
Legalábbis kevés akarja végigolvasni a stackoverflow oldalon az erről szóló értekezést és megkeresni hogy melyik a legkisebb erőforrás igényű:
    https://stackoverflow.com/questions/199333/how-do-i-detect-unsigned-int…
    https://stackoverflow.com/questions/1815367/catch-and-compute-overflow-…
    ...
 

> Tapasztalatom az, hogy ha valami nem elérhető, akkor az átlag programozó szemet huny az ilyen "apróság" felett, a sérülékenység (hibás számítás lehetősége) pedig szépen megbúvik a kódban.

Ez a programozó hibája és nem a nyelvé. A C-t kár a Rusttal (vagy akár a C++-szal) összehasonlítani, mert olyan, mint ha a szerszámraktárat hasonlítanád össze egy specializált, programozható ipari robottal; a kettő nem ugyanarra való.

A linkeket köszi, majd alaposabban is átnézem őket.

Mert a C nyelv egy lowlevel nyelv, amiben elemi műveletek és komponensek vannak. Ennyi erővel felvehetnénk a C nyelv típusai közé a stringet és a vektort, a műveletek közé meg a konkatenációt és a vektorműveleteket, továbbá az autoallokációt és az objektumorientált programozást is, hiszen ezek sem vennének el a C erényeiből, viszont hozzáadnának. Csak egy a baj: ezen már rég túl vagyunk és a kapott eredményt C++-nak hívják. C++-ban volna (van?) értelme egy ilyen nyelvi megoldásnak, C-ben viszont nincs se értelme, se keresnivalója. Ott, ha ez kell, akkor megírod függvényben.

A baj az, amit a C szabványosításáért felelős testület gondol a C nyelvről. Elég beszédes a wikipedia rész a C18-ról:

It introduces no new language features, only technical corrections, and clarifications to defects in C11.

https://en.wikipedia.org/wiki/C_(programming_language)#C18

Külső könyvtárként még megvalósítható, de már nem várható érdemi bővítés a C nyelvhez. A C23 várható változásai nagyrészt a C++ kompatibilitáshoz köthetőek.

Köszi, ez jó ötlet. Így elsőre a saturation és az assertion (túlcsordulás esetén kivétel) jöhet szóba csoportos műveleteknél, de egy-egy műveletre korlátozva nehezen kivitelezhető jelenleg. Olyan nyelvet igyekszem alkotni, aminek a komplexitását szükség esetén lehet csökkenteni, könnyen lehet keresni, meg transzformálni. Szeretném bevezetni a szemcsézettség fogalmát (complexity level), ahol pont a hasonló részletes dolgok lennének szabályozva.