Szoftver a programban, hogyan?

Szoftver a programban, hogyan?
2021-05-23T13:04:23+02:00
2021-07-02T20:05:42+02:00
2022-10-17T09:00:33+02:00
  • Sziasztok! Sikerült megoldani a problémát teljes mértékben és elkészült a program is. Végül Lua-t használtam a scripteléshez és egyáltalán nem bántam meg, simán meglehetett vele valósítani minden elképzelésem. Csak ajánlani tudom C/C++ alkalmazásokhoz. :)
    Mutasd a teljes hozzászólást!
  • Forth helyett implementálhatsz Lisp-et is, vagy csak Lisp szintaxisú, de nem Lisp runtime-ú megoldást. Azt elég könnyű implementálni akár teljesen nulláról is.
    Mutasd a teljes hozzászólást!
  • 1.  C-ben megírni egy tényleg minimális FORTH-ot, rendesen tokencompilerrel.

    C++-ban, nem?
    Mutasd a teljes hozzászólást!
  • Na, örülök, hogy érthető volt a dolog.

    A LUA azért nagyon nem így épül fel. A stack ott leginkább a C/C++ interfészeléshez van használva, de konkrétan a nyelvben nem jelenik meg egzakt módon. A másik hogy ott egy szintaxisfás nyelvről van szó, amihez írhatsz egy "rekurzív leszállásos" fordítót, vagy egy LALR parzert. Ezeknél a forth sokkal egyszerűbb. Amit én felvetettem forth-ot lejjebb fapadosan, az is lényegében dinamikus típusos dolog lett, mert éppen így alakult, így ebben közös megint a lua-val, de semmiféle GC meg oop, meg ilyesmi külön nem került bele.

    A LUA sem egy eszeveszetten bonyolult dolog az implementációját tekintve. Lehet talán 20-50 kLOC kódja, de azért egy kis forth az mondjuk tized akkora és semmi függőség nem kell a kódodba. Tehát gmano mikrokontrollerhez is simán implementálhat valami ilyesmit, csak valószínűleg mikrovezérlőn lehet hogy még faék egyszerűbbet csinál az ember és már hashmap sincs, csak egy tömb szó-pointer párokkal meg ilyesmi és lineáris, vagy logaritmikus kereséssel (ha rendezem legalább, vagy nem tömb, de kupac) keresem a szót belőle...
    Mutasd a teljes hozzászólást!
  • Köszi ezt is.
    Részben ismerem a FORTH-ot, néhány nagyon rövid programot hobbiból megírtam benne.
    A logikája megfogott, eltér a hétköznapi C-s taposómalomtól. :)

    Ami a kitűzött hobbicél lenne:

       1.  C-ben megírni egy tényleg minimális FORTH-ot, rendesen tokencompilerrel.
       2.  Többi utasítását pedig ": utasítás  egy kettő három ;" módon már FORTH-ban tovább írni.

    Azaz a C-ben implementálandó legminimálisabb szükséges szókészlet megtalálása a célom. Aztán a többit egy a user program előtt betöltődő FORTH-ban írt parancskészlet építené fel.
    Mutasd a teljes hozzászólást!
  • Én értettem, jól leírtad. :D Így már tényleg nem tűnik nehéznek az alap felépítés/logika. A Lua is lényegében így épül fel, az is egy veremre pakol/vesz le róla
    Mutasd a teljes hozzászólást!
  • Jah a Thinking Forth meg amúgy teljesen ingyen és bérmentve elérhető itt:

    Thinking Forth

    Klasszikus alapmű - tényleg azoknak is, akik nem forth-ban programoznak, szerintem sokat ad a tudásához - ha másban nem, hát abban, hogy rájön mennyire sokan adják el mindenféle módszertanként a spanyolviaszt amit már ezerszer feltaláltak mondjuk kód olvashatóság / szervezés terén stb.

    A minimum word set-ek nagyon kevésből megoldhatók, például:

    Minimal Word Set [Forth-eV Wiki]

    ^^De praktikusan ennél azért sokkal több beépített szóval érdemes azért egy forth-ot bootstrap-elni szerintem. Más dolog, hogy ha mániákus vagy és ez csak arra kell, hogy FORTH-ban utána írhass egy jobb, másik forth compiler-t mondjuk ahol több foglalt szó van, mert van valami fpga-d egy saját kis játék-cpu-val ahol csak ASM van a forth alatt, vagy akár csak gépi kód, de "normális" esetben tuti kényelmesebb alappal kezdenék azért, mint ezek a kutatóknak érdekes minimál szótárak.

    Még egy hasznos link:
    Write Yourself a Forth

    Nézd meg amit lentebb írtam, az inkrementális fejlesztéses példánál. Úgy is neki lehet állni.

    Szerk.: Leki2000-nek: Azzal sincs semmi bajom, ha behúzol alá egy Lua-t vagy egy embeddált python-t, de ezt írtam már a legelején is. A forth-on csak azért "rugózok" ha valaki magának akar írni egy kis saját fordítót, akkor ennél rövidebben és egyszerűbben szinte lehetetlen értelmesen használható interpretert / fordítót / nyelvet csinálni. De a 3rd party dolog integrálásából is sokat tanulsz, meg ebből is és tök más dolgokat tanulsz közben, szóval mondhatni teljesen mindegy.
    Mutasd a teljes hozzászólást!
  • A Forth-hoz meg annyit, hogy azért így kommentekből leszűrve az még bőven nem nekem való.

    Hát ha jobban akarod érteni mit csinál egy interpreter, akkor ez egy tényleg könnyen megvalósítható saját nyelv. Ilyen ezer soros terjedelemre kell gondolni tényleg, max kétezer szerintem és már használhatót kapsz.

    A lényeg tényleg csak annyi, hogy minden egy "szó" benne. Tehát beolvasod a fájlt és egy nagy ciklussal átfutsz rajta, amivel "tokenizálod" a "szavakat", amiket szóköz, tab, sorvége, kocsivissza és ezekből több választ el egymástól.

    Kell továbbá egy "szótár" ami lényegében egy szó->függvény hash mapot mondjuk most az egyszerűség kedvéért.

    Kell továbbá egy "stack". Ez egy sima verem adatszerkezet, a veremre tud tenni és onnan levenni minden szó.

    Ha valami nincs a szótárban, akkor még lehet szám, vagy lehet táblázat cellának hivatkozása (B1, stb.) Ha ilyen tokent talász, akkor tedd fel a stack-re a számot, vagy a hivatkozott cella számított (előző) értékét.

    Ezután egy cellába tudsz ilyet írni (mondjuk a C1 cellába, A1 legyen 40 és B1 legyen 2): "=A1 B1 +"

    Mit fog csinálni a forth interpreter? Az '=' itt nem része a forth programnak, csak mutatja, hogy számítani kell valamit - csakúgy mint excelnél mutatja.

    A verem kezdetben üres amikor a cellát kiértékeled, program interpretálás indul, mert = jel volt (szóval nem csak egy szám, vagy szöveg)
    -> [ ]
    A1 - nincs ilyen szó, ennek hatására megkeresed az A1 mezőt és az értékét felteszed a verem tetejére.
    -> [40]
    B1: nincs ilyen szó, ennek hatására megkeresed a B1 mezőt és az értékét felteszed a verem tetejére
    -> [2,40]
    + : Van ilyen szó, hurrá! Megkeresed a hash table-ben milyen C++ függvény tartozik hozzá. Ezt egy beépített függvénynek írtad meg még C++ban és annyit csinál, hogy fogja a verem / stack tetején lévő két számot és összeadja - illetve kiír valami hibát a konzolra, ha "nem szám" az érték (ha egyáltalán vannak a celláknak típusai nálad) és az eredményt teszi a stack-re (a két ott lévőt leveszi onnan).
    -> [42]
    (Megj.: A szögletes zárójelek közt a verem állapotát mutatom - bal oldalt a teteje / friss elem, jobb oldalt az alja)


    Mi történik eztán? Vége, mert nincs több, szóközzel elválasztott token. Az '=' jellel kezdődö celláknál a verem tetején lévő érték lesz a cella "értéke". Ha a cellák egymást körbehivatkozzák, akkor egy nagy ciklussal több menetet számolsz és mindig az előző értékből számolod a következőt és legyen valami gomb amit nyomkodhatsz hogy a számított mezők végig frissüljenek és ez még mindig faék egyszerű.

    Figyeld meg, hogy ezzel a módszerrel nincs szükség zárójelezésre:

    50*(5.5 + 14.5) / 10
    ebben a felírásban:
    5.5 14.5 + 50 * 10 /

    Miért is?

    [] 5.5 -> [5.5] 14.5 -> [14.5] + -> [20] 50 -> [50 20] * -> [1000] 10 -> [10 1000] / -> [100]
    Ez az, ami miatt kritizálják a forth-ot, hogy az ember jobb szeret persze hagyományosan zárójelezett képletet írni, mint ilyen fordított lengyelformásat, ahol zárójelek nem kellenek, mert ugyebár azt szoktad meg. Ez igaz is ezt lent se tagadtam. Arra gondolj, hogy a forth olyan programnyelv, ahol nem kell a függvényhívás paramétereit megadni se híváskor, se pedig amikor a függvény törzsét megírod, minden függvény lényegében a "vermet" használja, amire pakolhat annyit amennyit akar és leszedhet annyit amennyit akar.

    Az interpretered C++ kódjában ilyen függvényre való pointer kell a hash tábládba egyébként amikor a foglalt szavakat (mint például DUP, SWAP, +, *, /, stb.) implementálod:

    std::unordered_map<std::string, std::function<int(std::stack<Value> &, Io &)>> dictionary;
    Ebbe meg az elején egy inicializációval beleteszed a "kezdetben foglalt szavakat", mint mondjuk a +, *, dup, swap, drop, vagy éppen a : és ; szavak.

    Azok kezdeti C++ foglalt szavas implementációja pedig ilyesmi lesz:

    static int add(std::vector<Value> &stack, Io &stdio) { if(stack.size() < 2) { stdio.error += "Error: Too few arguments for the '+' operator!"; return 1; } auto a = stack.top(); stack.pop(); auto b = stack.top(); stack.pop(); if(!a.isNum() || !b.isNum()) { stdio.error += "Error: Cannot add non-numbers together!"; return 1; } double c = a.asDouble() + b.asDouble(); Value retVal(c); stack.push(retVal); return 0; // indicate there were no errors and result is on the stack }
    Feltételezem a szorzást meg tudnád írni, ahogy a "dup" műveletet is, amivel mondjuk megkettőzöd a verem tetején lévő "akármit". Kvázi lemásolod a value-t és push-olod. A swap megcseréli a két legfelsőt.

    Azt, hogy mely műveletek kellenek minimálisan egy forth rendszerhez azt már sokan leírták sok helyen, de igazából kiindulhatsz abból, ami első körben a saját igényed a cellák kiszámításához.

    Ha ezt a fenti pár dolgot megcsinálod, akkor lesz egy cellák kiszámítására alkalmas megoldásod ami teljesen saját. Még faék egyszerű, pár soros az egész, de persze még kissé korlátolt, de már akár élesben is szórakozhatsz vele a programodon belül, mert arra már lesz elég értelme. Szóval ezen a ponton már van egy sikerélményed.

    Viszont idővel rájössz, hogy nem igazán tudsz így "ciklust, elágazást" csinálni, továbbá a scriptben így még nem tudod bővíteni a szavakat, csak ugye ha a C++ kódba belefírkálod új foglalt szónak ugyebár.

    A vezérlési szerkezeteket, mint az IF, vagy egy ciklus - beletehetsz mondjuk úgy, hogy amikor a szavak határait (hol van vége a space-eknek) felismered a bemeneti szövegben, akkor a szó oda eltehessen egy "kövecskét". Például erre is használhatsz egy stack-et, mint a Value-k esetén, csak ebben a "hol tart az olvasás, a bemenet hányadik karakterén?" számot tárolod el - de csak ha valaki ezt ugye oda fel is teszi. Ezzel tudsz csinálni egy "DO" szót és egy "WHILE" szót. A "DO" szó lerakja ezt a kis jelzőizét, a WHILE szó meg felszedi a legutolsót a másodlagos, vezérlési veremről. A vezérlési verem minden beépített függvénynek átadandó és egy "InterpreterAction &" paramétert is adni érdemes, amivel az interpreternek szólhatsz, hogy "folytasd az x-y karakterpozícióról". Ennek fényében tudsz csinálni egy DO-WHILE ciklust, de nem érdemes előre szaladni miként. Az InterpreterAction-nak kell lennie továbbá mondjuk egy "readWord()" függvénye, ami egy stringet, az olvasott következő szót visszaadja, anélkül, hogy azt az interpreter végrehajtaná. Ez miért jó? Gyűjtheted egy kis saját listába ezeket amíg egy THEN törzse tart, majd egyenként meghívod rá a "run(cmdStr)" műveleted amivel lookup-olod a hash-ből és megcsinálod a dolgait amíg END nem jött - de csak ha igaz volt a feltétel - mert a vermet látod, tehát csak akkor, ha a verem tetején mondjuk nem nulla volt.

    Ezzel majd tudsz ilyeneket:
    = B1 A4 < THEN 42 ELSE "Nem kisebb" END

    Szóval ha a B1 kisebb, mit az A4, akkor legyen 42, amúgy az a szöveg lesz, hogy "Nem kisebb". Meg tudsz ciklust írni már. Igazából ez utóbbiak akkor lesznek világosabbak, ha előbb a fapadosat már megírtad, ami semmi vezérlést nem csinál, csak a vermet feldolgozza a foglalt szavakkal, ha az a kód előtted van, ilyen módokon már nagyon könnyen kiterjesztheted.

    Majd fontos lesz implemtálnod a ":" szót és ahhoz kapcsolódó "ENDWORD" lezárót. Ez arra teszi majd alkalmassá a nyelvet, hogy "szavakat" definiálhass - tehát kb. függvényeket, de akár annál próbb dolgokat is. Ehhez az kell, hogy ha ':' jön (ez ugye beépített szó lesz), akkor egy listába gyűjtsed össze az össze ENDWORD előtt és ":" utáni szó után talált szót. A : utáni legelső szó az újonnan definiált szó neve lesz, a többi a "törzse". Az END-ig tart mit csinál ez a dolog.

    : a_negyzeten DUP * ENDWORD
    Használat:

    5 a_negyzeten
    -> [25]

    Ehhez szükséged lesz egy a beépített szavakhoz hasonló std::function-ra, ami "lefuttatja" a gyűjtött listában lévő szavakat és ezt kell beregisztrálnod a hash-táblába.

    Innen meg már bármerre továbbfejlesztheted a nyelvet ahogy tetszik. Ha akarsz tehetsz bele támogatást normális infix (tehát nem lengyelformás) kifejezésekre, mondjuk úgy, hogy erre a '(' és a ')' új szavakat definiálod. A kettő között beraksz valami olyasmit, mint amit hosza linkelt, vagy egy annál egyszerűbb expression to RPN nyelvtant és akkor már arra se panaszkodhat a felhasználó, hogy nem érti a fordított lengyelformát (ami viszonylag jogos, hogy ne kelljen azért legalább a legegyszerűbb cellás számításhoz, hogy értse azt).

    Sajnos ezt sokkal-sokkal egyszerűbb vizuálisan, papíron rajzolgatva elmagyarázni és sajnos nem tudom mennyire jó a C++ előképzettséged, így feltételezésekbe bocsátkoztam, továbbá egy vidiben, vagy papíron ezt könnyebb lerajzolgatni hogy mennyire faék egyszerű az egész, de azért remélem legalább 1-2 ember nagyjából követi ezt akkor is, ha nem pont neked lesz ez hasznos.

    A megértéshez közelebb visz talán ez a végső példa:
    5 4 +
    -> [9]

    5 4+
    -> syntax error: Word named "4+" not found.

    Szóval tényleg az egész parzer annyira buta, hogy nagyon fontos hova teszed a space-t. Ha kihagyod a 4 és a + karakterek között, akkor bután egy "4+" szót fogsz a dictionary szótárban keresni, mert "ezt írták be".

    ui.: Aki szeretné szétcincálni a példát, hogy mivel lehetne minimálisabb forth-ot csinálni még kevesebb sorból, vagy kevesebb problémával, vagy akinek nem tetszik, hogy nem gforth kompatibilis így a cucc, annak azért jelezném, hogy direkt "parasztosan" álltam most ehhez. Ott vannak a korábbi linkek ha valaki látni akarja hogy csinálják mások. Ez egy iteratív megközelítés - ahol először tényleg csak annyit kódolsz le, ami nem több egy fordított lengyelformás számologépnél foglalt szavakkal és egy veremmel, majd ezt okosítod programnyelvvé. Azért, mert ha nem így csinálod, akkor bonyolultnak fogod látni. Lehet hogy két kommentbe kellett volna ezt szednem így is, de most lusta vagyok a didaktikához így egy átmelózott nap után
    Mutasd a teljes hozzászólást!
  • LUA szkript C-be integrálása terén az alábbitól kezdődően a végéig a példák tuti segíteni fognak:
        Embedding Lua in C - Extending your tools and apps with Lua scripts

    @senki: köszi a FORTH példát, nézem.
    Mutasd a teljes hozzászólást!
  • Linkeltem lejjebb pár dolgot, az egyik kb. ezer soros C-kód tokkal vonóval, persze lehet itt-ott bele kell tákolni.
    Mutasd a teljes hozzászólást!
  • "Senki" kommentjére is reagálva egyben: tényleg nem egy Excel killer programot szeretnék összehozni, csak egy gyakorló projektet csinálok, hogy valamennyire megragadjanak azok a dolgok amiket az elmúlt hónapokban tanultam a C++-ról. Szóval több okból sem egy Excel volumenű program megírása a célom, egyelőre még felhasználói felületet se kap a dolog, hanem minden konzolban van megformázva. Szóval csak magamnak írom. :)

    Egyébként jogos a kérdés. Őszintén nem igazán gondoltam bele a dologba, eleve nem is nagyon tudok sokat a script nyelvek működéséről. Az tűnt hirtelen a legelsajátíthatóbb megoldásnak, mert a linkelt könyvtárat hirtelen ötletem sincs, hogy hogyan is kéne kezelni a Luahoz meg találtam anyagot. Amit mellékeltek txt-t az nekem elsőre kicsit kínai, mert bár fel van sorolva minden előre megírt függvény és a műveletek is, de például hogyan tudok egy változónak úgy értéket adni, hogy a bemenetről beolvasom mondjuk a "5+12" stringet? Vagy ott hogyan lehet meghívni mondjuk a beállítCella() függvényt az inputon megadott A1+A4-re?

    Amúgy tényleg nem tudok érdemben válaszolni, ehhez én még amatőr vagyok. Nem tudom, hogy pontosan hogy kommunikál egymással a C++ és a Lua, gondoltam tanulás közben majd csak meglátom. :D 

    A Forth-hoz meg annyit, hogy azért így kommentekből leszűrve az még bőven nem nekem való.
    Mutasd a teljes hozzászólást!
  • @senki: Régebben foglalkoztam RPN-nel és a FORTH-tal. Tudsz bármit mellékelni nekem a legminimálisabb FORTH-ról, ahonnan már "beindul" a nyelv és nyelvi szinten bővíthető?
    Célom, hogy teljesen saját FORTH-ot felépítsek a semmiből például mikrovezérlőre és ehhez elsőre egy tényleg minimumot szeretnék.
    Mutasd a teljes hozzászólást!
  • Az FKeres nem azon a szinten van, amiről itt beszélünk. Amiről beszélünk az a beépített Visual Basic interpreter

    Ha tényleg az UX vezérel, akkor sokkal többet számít majd az elnevezések ismerőssége, mint a nyelv ismerőssége.

    Az, hogy a Fort mennyire gyorsan vagy nem gyorsan tanulható, ez egy másik kérdés.

    A fontosabb kérdés - tekintve, hogy az ilyen scriptnyelveket jellemzően "casual programmerek" használják és a legtöbb esetben nem hivatalos hardcore coderek.

    Azt nem sikerült cáfolni, hogy nincs ember, aki Fort-hoz értene.

    r/Forth - Is Forth gaining interest in 2021? Why or why not?

    Egyébként én is látok egy hobbi-felfutást pont a faék egyszerűsége miatt. Nyilván nem nagyon sok helyen találsz forth-os állást, de egy beágyazott scriptnyelv célközönségét tekintve ez mint mondtam nem is fontos

     Ha pedig egy normális programozási nyelvet integrál be, akkor miért is ne használja az ahhoz tartozó összes, már mások által megírt könyvtárakat.

    Én csak azt mondom, hogy nehéz lesz biztosítani az egységes look&feel élményt az ilyen összelegózott megoldással. Például akarsz ilyen csupa nagybetűs, excel kompatibilis függvényeket, meg saját függvényeket mondjuk, közben meg ott lesznek mindenféle a "nyelvvel jött" megoldások is. Ez egy professzionális fejlesztőnek nem zavaró, sőt örülsz is neki, hogy tudsz mondjuk numpy-t használni, de valakinek aki táblázatkezel, mentálisan fura lesz és megszokandó, hogy miért sokféle névadási konvenció, stílus keveredik összevissza. Ezért eleve a legjobb ha ezen az úton indul el valaki, hogy pl. az excel dolgaitól look&feel felé jobban el kell szakadni a python / lua stílusa felé (ez jellemzően jó dolog amúgy szerintem, de ez is behoz egy ismeretlen-faktort)

    Itt nem arról van szó, hogy neked, mint fejlesztőnek mi a jó, vagy mi a kényelmes, hanem arról, hogy a felhasználó számára mi a jó.


    Hát neked mint fejlesztőnek az a "jó", hogy fogsz és behúzol egy kész embedded python-t vagy Lua-t nem? Mármint ha gyorsan és lustán kész akarsz lenni és terméket akarsz mondjuk. Ez a usernek nem "jó", mert az excel felhasználói köre és a Lua nyelvet ismerők köre (vagy akár talán a python-t ismerők köre) közel olyan kicsi metszet, mint az excel felhasználói célközönsége és a forth-ot ismerők... Azért ne gondoljuk már azt, hogy a táblázatkezelőkben eltöltött időt ha megnézzük globálisan akkor ott a fejlesztői társadalom valami hatalmas túlsúllyal szerepelne a nem-fejlesztőkhöz képest - sőt! Igazából én kevés "hardcore fejlesztőt ismerek", aki ne akarná lepasszolni másnak az ilyen excel scriptelést, vagy kifejezetten élvezi azt és sok esetben casual programmerek csinálnak szétmakrózott, meg "szétVB-zett" excel táblákat. Szóval ennyi erővel a felhasználónak lehet hogy sokkal jobb, ha valaki ért a prognyelvekhez és ír egy teljesen a munkára szabott, kényelmes nyelvet, rosszabb ha a táblázatkezelős cégnél nem értenek ehhez, de legalább egy értelmes nyelvet embeddálnak és persze ennél is rosszabb, ha nem értenek a prognyelvekhez de implementálnak egyet. De ha mindenképp implementálni akar valaki egy sajátot, legyen már valami könnyen implementálható és nehezen elrontható dolog, mint a FORTH - és eközben legalább megtanul az ember ezt-azt



    Szerk: Egyébként hosza nálam jobban leírta mi a véleményem az egységes look&feel nehézségeiről, ami fejlesztőként nem tűnik zavarónak, de ha az end-user le kell írjon valami "eval"-t az neki csak még egy magolandó dolog lesz kb. sajnos és mire megérti az mire kell annyi idő alatt tényleg az egész forth-ot tokkal-vónóval el tudnád mesélni neki (Mert ugye ott egy eval azért kell, mert behúztál egy embedded nyelvet és "így jött össze" a dolog)
    Mutasd a teljes hozzászólást!
  • Nincs igazán célközönség, mert magának írja. De az igaz, hogy valamennyivel több értéket adhat a demóhoz, ha olyan nyelvet támogat, amit a néző is ismer. (Bár, ha egzotikus a nyelv, az néha még többet ad hozzá, de nem mindig.)

    De ne felejtsük el, hogy ez az egész arról szól, hogy elsősorban a cellákba képleteket akar beírni a kérdező, és erre használná a nyelvet. A többi csak nyalánkság. Ilyen szempontból melyik a jobb? Python, Lua, VBA, Forth?

    Vegyünk egy példát:
    (Python)   A1 + B1 if C1 > D1 else FA25
    Itt A1, B1, C1, stb. cella hivatkozások. Hogy kellene ezeket feloldani a fenti nyelvekben, anélkül, hogy külön kellene még kezelni a hivatkozásokat a kifejezés kiértékelése előtt? Valamiylen eval, plusz az összes cellához változók felvétele? Vagy hogyan máshogy?

    A Lua és a többiek esetén ugyanez a kérdésem (és nem csak hozzád, hanem azokhoz is akik e nyelveket javasolták.)

    Amit én ajánlottam, abban ez "out of the box" működik.
    Mutasd a teljes hozzászólást!
  • Igen, ez egy sokkal jobb érv, bár amennyire én tapasztalom, egy korábban sose programozó embernek a FORTH-ot megérteni sok esetben egyszerűbb, mint mondjuk egy C-szerű nyelvet és inkább arról van szó, hogy azokra igaz amit mondasz, akik már jó ideje nyomnak valami programnyelvet.

    Ezt csak amolyan saját kísérletekből szűrtem le: Nagyon kevés dolgot kell elmagyarázzál egy FORTH-ból és annak a teljességét elmondtad a másiknak. A másik érdekesség, hogy amennyire látom pár évvel fiatalabban lehet megértetni a forth-ot mondjuk a C-hez képest (tehát 1-4 osztályos ember is simán megértette, C-nél nemigen jellemző bár nem vagyok tanár, hogy tömegesen próbálkozzak, csak ha úgy van érdeklődés ismerősi körben elmagyarázgatok dolgokat). Érdekes, hogy a BASIC is valamiért sokkal hamarabb érthető, pedig az tökre más... Nem pontosan értem ennek a mechanikáját.

    Inkább az aggaszt, hogy: oké, ezt a felismerést legalábbis az alapján amit láttam igaznak gondolom, de ezekben az esetekben mindig volt egy mentorálás, elmagyarázás - na most kiadni egy szoftverbe azért egészen más... Mármint praktikusan hacsak nem ad hozzá az ember valami igen pró tanulási anyagokat, akkor is hátrányban lehet mondjuk egy python-al szemben, ha amúgy egy casual programozónak esetleg kézre is állna, mert a pythonról lesz egy tonna youtube tutorial erről meg lesz egy nagy semmi  

    De mint mondtam nem látom az excel-killer célzatot ebben a fejlesztésben, csak a hobbiprogramozást, szóval ennyi erővel Malbolge is lehetne a nyelve, ellenben a forth interpreter írásból tényleg azért jókat lehet tanulni.

    ui.: Factorhoz írtam is infix támogatást, sőt nyelven belül simán implementáltam egy basic-szerű nyelvet, de leginkább csak poénból.
    Mutasd a teljes hozzászólást!
  • Nyilván nem arra gondoltam hogy 0, azaz nulla ember van aki tud fort-ban programozni, de akkor tessék: a célközönség tekintetében minimális azok száma akik tudnak fort-ban programozni, ezért nem látom értelmét annak, hogy olyan nyelvet erőltessen bárki, ami mögé nem tud ember tömeget rakni. Tanulási szempontból (CV szempontból) is több értelme van annak, ha azt mutatja, hogy tessék, csináltam egy C++ programot, amihez egyébként X népszerű nyelven lehet scriptet írni.
    Mutasd a teljes hozzászólást!
  • A Forth-szal egy jelentős probléma, hogy a postfix szintaxis nem fexik az embereknek, nagyon sokat kell gyakorolni bárkinek, aki folyékonyan szeretne írni-olvasni Forth nyelven. Ez valóban akkora probléma, hogy többen is próbáltak olyan eszközt létrehozni hozzá, ami infix formában írt, "Forth-szerű" programokat alakít át valódi Forth nyelvre.
    Mutasd a teljes hozzászólást!
  • Azt nem sikerült cáfolni, hogy nincs ember, aki Fort-hoz értene

    Pedig ez egyszerű: "nincs ember, aki Fort-hoz értene" pontosan akkor hamis, ha "létezik (legalább egy) ember, aki a Forth-hoz ért" igaz. Mivel "senki" (a user, tahát valójában valaki) egy ember, és "senki" ért a Forth-hoz, ezért az utóbbi állítás igaz, tehát az eredeti állítás hamis, azaz sikerült cáfolni azt.
    Mutasd a teljes hozzászólást!
  • Azt nem sikerült cáfolni, hogy nincs ember, aki Fort-hoz értene. Én ezt állítottam. Az, hogy a Fort mennyire gyorsan vagy nem gyorsan tanulható, ez egy másik kérdés.

    Az FKeres nem azon a szinten van, amiről itt beszélünk. Amiről beszélünk az a beépített Visual Basic interpreter, ami már messze messze túlmutat a függvényeket egymásba fűzünk témától. Ha pedig egy normális programozási nyelvet integrál be, akkor miért is ne használja az ahhoz tartozó összes, már mások által megírt könyvtárakat. Itt nem arról van szó, hogy neked, mint fejlesztőnek mi a jó, vagy mi a kényelmes, hanem arról, hogy a felhasználó számára mi a jó.
    Mutasd a teljes hozzászólást!
  • - Nagyon kevés (close to 0) ember tud fort-ban programozni

    Ez batár nagy hazugság. Főleg ha scriptnyelvnek használod, akkor nagyon egyszerű beletanulni, az emberek többsége nem is nagyon fogja megérezni, hogy FORTH, vagy mi az amit ír, csak a foglalt szavakat fogja magolgatni kb. (lásd "FKERES" és társai - sőt szerintem ezeknek az excel-hez hasonló nevei sokkal fontosabbak lesznek, mint maga a nyelv).

    - Elveszik a könyvtár támogatást, amit bármelyik ismert rendszer ad (lua, python, js, whatever)

    Aki scripteket ír majd a táblázatkezelőnek, az megint csak jellemzően nem használja ezeket a könyvtárakat. Őt majd az ilyen "FKERES" jellegű függvények érdeklik majd - sőt bajod lehet belőle, hogy ha használod a python saját cuccait és az mondjuk nem "seamless" egységes feeling-et ad a saját apiddal mondjuk... Na úgy egy nagy kalamajkának fog tűnni - főleg azoknak, akik előtte sose programoztak... nem értik majd miért nem egységes a dolog.

    Jah, a foglalt szavakat meg nyilván C++on belül írnád meg (tehát pl. az FKERES-t) - legalábbis az alapokat.

    - Nem túl esélyes, hogy editor-t találjon valaki hozzá, amit embeddelni lehet

    Nem túl esélyes, hogy bármi "editor" kell egy FORTH egyszerűségű nyelvhez. Kb. a dmenu alól kilopod a szótár-alapú lookup kódját és kész is vagy, mert csak szavakat kell lookupolni prefix alapján ha egy kódkiegészítést akarsz mondjuk. De a nyelv lényege, hogy kvázi nem kell semmit "integrálnod". Amúgy sok esetben táblázat cellákba akar majd a user írni 4-5 szó hosszú dolgokat. Ott én max egy infix expression támogatást tennék be, de azt már forth szinten is lehet akár...

    - Rakás plusz effort saját nyelv megfelelő implementálása, miközben ő nem nyelvet akar írni, csak scriptelhetőséget

    Azért mondtam a FORTH-ot, mert azt egy hétvége alatt fullosra le tudod implementálni. Ha nagyon benne vagy, akkor egy délután alatt, de ezt nem feltételeztem. Ha eközben még a C++ nyelvet is tanulod, akkor is le tudod implementálni a FORTH-ot egy hét alatt és az illető legalább tudja mi történik.

    Egyébként én nem olvastam sehol, hogy excel killert akar írni az illető, olyat amit tömegek használnak, hanem azt feltételeztem, hogy tanulni akar belőle. Szerintem a FORTH-os vonalon tanulná a legtöbbet az egészből.

    Plusz néhány érv: Sokkal kevesebb függősége lesz. Én szeretem az ilyen programokat, amiknek szinte semmi függősége nincs és kvázi bárhol le tudod fordítani - mondjuk a mobiltelefonomra is, mindenféle más procira is stb. A projekt környezetet is kényelmesebb lesz így karbantartani és legalább meglátja milyen előnyei vannak egy suckless.org jellegű filozófiának ha ezt az utat követi.

    De amúgy előre szóltam, hogy "nem leszek népszerű" - nem megmondtam?
    Mutasd a teljes hozzászólást!
  • Ha lua akkor ajánlom ezt: ThePhD/sol2
    Ha python: pybind/pybind11
    Mutasd a teljes hozzászólást!
  • Helyzete válogatja persze, de egy C++ alkalmazást alapvetően valami performancia igényes hw közeli témakörhöz közelítenék és itt bizony számít egy script nyelv futtatásához szükséges plusz pár msec is. Magát a számítást nem, de a típusokat és műveleteiket ki kell vezetni script szintre is és ez  mind plusszmunka. Ráadásul ha valami módosul, akkor a scrit és az alatta lévő C++ réteget is karban kell tartani más-más nyelven és szemlélettel. 

    Plugin írásához a C++ fejlesztőt lehet nehezebb megtalálni, de ez már inkább management kérdés, egyáltalán külön ember írja e az üzleti logikát, vagy ugyanaz, mint azalatta lévő réteget.

    Mai gépeken és főleg a modern C++20 tól számítvamár a fordítási idő sem olyan vészes,cserében már sok hiba fordítási időben is kiderül és így a plugint futás közben nem is engedi újratölteni.

    Üzleti logika szintjén teljesen platformfüggetlen a kód nyelvtől függetlenül az API meg úgyis C++, ha python-al fejleszt valaki, ha nem. Legtöbb C/C++ library-t teljesen platformfüggetlenül lehet használni.
    Mutasd a teljes hozzászólást!
  • Hát egyelőre a Lua mellett döntöttem, mert viszonylag könnyű beemelni C++ mellé, hiszen alapból C-hez íródott. Szóval legalább a scriptelésbe is bele kóstolok picit. De a többit is megnéztem amit írtatok :)
    Mutasd a teljes hozzászólást!
  • Erre is érdemes lehet nézelődni.
    A fickónak van egy elég jó vlog-ja is c++ weekly. Sokat lehet tanulni belőle.

    Ez a projekt meg, ha jól tudom játék motorhoz készült, illetve Modern C++ -T demonstrálni.

    ChaiScript - Easy to use scripting for C++.
    Mutasd a teljes hozzászólást!
  • A nem elterjedt scriptnyelvek behozatalával nem értek egyet, és elmondom, hogy miért:

    - Nagyon kevés (close to 0) ember tud fort-ban programozni
    - Elveszik a könyvtár támogatást, amit bármelyik ismert rendszer ad (lua, python, js, whatever)
    - Nem túl esélyes, hogy editor-t találjon valaki hozzá, amit embeddelni lehet
    - Rakás plusz effort saját nyelv megfelelő implementálása, miközben ő nem nyelvet akar írni, csak scriptelhetőséget
    Mutasd a teljes hozzászólást!
  • Én mindenképp azt mondanám, hogy a kettő között nem vagy, hanem és kapcsolat van.

    A plusz lassító rétegnek valójában nincs jelentősége, ez ilyen átlag programozói félelem. Amikor valaki egy scriptet ír (legyen az excel makró, python script, stb.) azt általában azért teszi, mert van valamilyen manuális munkája, amelyet gyorsítani akar. Nem igazán érdekli, hogy az most 1 vagy 2 vagy 10 másodperc alatt fut le, mert onnan indul, hogy ezzel megspórol több órányi kézzel végzett munkát.

    Beépített editor/debugger: szerintem erre nem feltétlenül van szükség, bár alapvetően hasznos. Ha szerencséje van a kérdezőnek, akkor talál komponenst, amit csak behúz a programjába.

    A magasszintű (pl. python) nyelvnél nem neked kell megírnod a mátrix számolást, hanem erre vannak külön könyvtárak (numpy pl. python esetében). Azt kell biztosítani, hogy ezek betölthetőek legyenek.

    A bindingre szükség van, de ami a legfontosabb szerintem, az a tiszta API. Ez mind script, mind pluginek esetén fontos egyébként.


    A plugin (főleg ha C++-ról beszélünk) a következő hátrányokkal rendelkezik:

    - Jóval komplexebb fejlesztői/build környezet

    - Jóval magasabb beugrási küszöb (minden C++ fejlesztőre jut 1000 python fejlesztő)

    - Fordítási idő

    - Jóval nehézkesebb több platform támogatás (linux, windows, macos, arm illetve x86, stb.)
    Mutasd a teljes hozzászólást!
  • A script hatranya tul azon hogy bevisz egy plusz lassito reteget, esetleg meg kulon editort/debuggert is kell hozza fejleszteni, illetve ket eltero kornyezetben kell parhuzamosan dolgozni, az, hogy mindent bindolni kell. Ha peldaul matrixokat kell atadni, szanolni vele, akkor a tiipus es osszes muvelete ott kell legyen a scriptnel is es ez nem kis munka. A pluginnal ilyen hatranyok nincsenek es hot reload ugyanugy megoldhato.
    Mutasd a teljes hozzászólást!
  • De amúgy forth-ra is vannak kész embeddálható cuccok - csak szerintem jó ujjgyakorlat magadnak megírni persze:

    howerj/libforth

    Egy minimálabb implementáció:
    A minimal Forth compiler in ANSI C
    Mutasd a teljes hozzászólást!
  • TL;DR:

    1.) Használhatsz valami kész cuccot. Lua-t vagy python-t javaslok beágyazni a progidba.

    2.) Nézd meg a FORTH-ot és abból írhatsz egy sajátot teljesen egy hétvége alatt.

    3.) Olvasd ki a formnyelvek, fordprog 1-2 jegyzeteket és mondjuk a nyelvek típusrendszere anyagok jegyzeteit, majd írj egy "rekurzív leszállásos" fordítot valami jól tervezett nyelvhez amit szeretnél.



    Lehet hogy nem leszek népszerű, de ha saját nyelvet akarsz, akkor szerintem nézz utána a "FORTH" nyelvnek. Ahhoz nagyon-nagyon könnyű interpretert vagy fordítóprogramot írnod és mégis iszonyatosan magas szintű nyelvnek és iszonyatosan "faék egyszerűnek" egyaránt használhatod. A FORTH-ban minden dolog egy "szó", vagyis az egész parzert majdnem annyival megoldhatod, hogy meg tudod különböztetni a whitespace-t és a nem whitespace-t. Vannak alapszavak és definiálhatsz saját szót. A szavak vermen kommunikálnak, amire tudsz pakolni, meg levenni onnan dolgokat. Minden magára valamit is adó "Igazi" FORTH-ban továbbá van valami mód "fordítási idejű szót" is definiálni - ezek kb. nem függvényhívás szerűen interpretálódnak, hanem magát az interpretert vezérlik. Például ilyesmivel, hogy "olvass addig be mindent egy stringbe, amíg a következő string nem jön a bemeneten" - ezzel pedig kb. bármilyen bonyolult programnyelvet tudsz csinálni úgy, hogy magán a nyelven kódolod le a fordító többi, maradék részét.

    Szerintem nézd meg a "Thinking Forth" könyvet. Az amúgy is nagyon tanító jellegű és sok mindent megtanulsz belőle ami hasznos bármely más nyelven programozva is. A fordítóját szerintem utána magadtól is simán meg fogod írni, de közben rá is érzel miért "király" az egész, meg hogyan kell használni.

    További jóság, hogy lehet a te alkalmazásodhoz még kifejezetten előnyös is - annyi, hogy én beletennék azért egy nem-lengyelforma expression támogatást az aritmetikai dolgokra - de ez utóbbi már könnyen lehet hogy a forth kód része volna eleve.


    A koncepció továbbfejlesztésén időről időre egyébként dolgozok egy keveset - de más miatt. Ha gyorsan akarsz valami jól használható saját dolgot, ajánlom. Párszáz sorban meg lehet akár írni!!!

    Azért mondom ezt, mert sok programnál látom azok mindenféle gányolt scriptnyelveit - például MAXSCRIPT anyámborogassa aki tervezte!!! Ezt elkerülendő, vagy nem kéne megspórolni a formál nyelvek, fordprog 1, 2 tantárgyak legalább alap ismereteit egyetemen, vagy használjanak valami kész cuccot (Lua, vagy akár egy programba ágyazott python - lásd Blender esetén mondjuk) vagy egy olyasmit kódoljon le az illető, mint a Forth, mert azért azt tényleg meg lehet írni akár egy hétvége alatt jóra ha sajátot akarsz.
    Mutasd a teljes hozzászólást!
  • Igen, felsőoktatásban legtöbb helyen szó esik a formális nyelvek, fordítóprogramok témakörben arról, hogyan működik a (script) programozási nyelvek elemzése, értelmezése, fordítása. Intézményenként eltérő mélységben merülnek el benne persze.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd