Új programozási nyelv komplexitása

Címkék
Új programozási nyelv komplexitása
2022-06-03T12:34:20+02:00
2022-06-11T13:02:56+02:00
2022-10-17T04:05:51+02:00
  • Nincs azzal baj, ha nem tetszik valami ugy ahogy van, vagy tetszik, de latsz benne egyszerusitesi lehetoseget.
    Fejlesztes kozben is, tulajdonkepp folyamatosan elrejtunk egy vagy tobb komplexebb funkcionalitast es magasabb szinten, mondjuk, 1 db metodus lesz belole.

    Ha nagyon divatos akarsz lenni, irhatnal egy latvanyos "egerrel huzkodom" teszteloi rendszert pl electronjs segitsegevel.
    Kivancsi lennek, hogy mennyi idon belul kapnad magad azon, hogy mar letezo komponenseket hasznalsz fel, bebujtatva a csilli-villi alkalmazasodba. Ha csak arrol van szo, hogy be kene olvasni egy file-t, akkor felhasznalnal-e egy meglevo komponenst, vagy vadi ujat lefejlesztenel, 0-rol.

    Szamomra meg nem derult ki, hogy:
    - uj programnyelvet akarsz kifejleszteni
    - uj teszteloi rendszert akarsz kifejleszteni
    - vagy csak ujakat megismerni

    ?
    Mutasd a teljes hozzászólást!
  • Tippre azt mondanam, h egy Tricentis Tosca letrehozasa nem one man show, de fixme!

    De inkább most még újabb rendszereket akarok megismerni.

    Ez onszorgalom? Ahova mentel ott nincs mar kialakult, bevezetett eszkoz? Esetleg te fogod bevezetni, es ezert nezelodsz?

    Ahogy látom, a tiszta Seleniumnak leáldozóban van.

    Ahogy meg en latom, akarom mondani, hallom: nem. Termeszetesen itt is ervenyes, hogy a megfelelo szerszam a megfelelo feladathoz.
    Mutasd a teljes hozzászólást!
  • Jó nagyokat ugrálsz gondolatban. Egy ilyen tesztrendszenek mint a Tosca - amit láttam belőle https://www.youtube.com/watch?v=f6aBpa95kLc
    kb. semmi köze egy programnyelvhez.
    Mutasd a teljes hozzászólást!
  • Nem Junit szerű teszt rendszerre, hanem magasabb szintűre gondolok, lásd pl. (Tricentis) Tosca.
    De inkább most még újabb rendszereket akarok megismerni.
    Ahogy látom, a tiszta Seleniumnak leáldozóban van.
    Mutasd a teljes hozzászólást!
  • Úgy is van, komolyabb helyen, ha valaki elvégez egy fordítóprogramok kurzust, annak beadandó feladat egy új nyelv megalkotása és a fordítóprogram megírása hozzá. Ma már online, ingyenes formában is léteznek ilyenek.
    Mutasd a teljes hozzászólást!
  • erű: https://hu.m.wikipedia.org/wiki/Brainfuck

    Egyébként volt a hup.hu oldalon egy proliverzum nevű, fél-autista (aspergeres?)gyerek, az írt saját nyelvet. ?

    ---------------------
    Kivételesen és utoljára, komolyan hozzászólva: kb negyven éve (16-17 évesen, munka mellett) tanultam PL/I-t és COBOL-t. Előbbit iskolában, utóbit magamtól.
    Egyik sem tetszett igazán, mellé jött még a FORTRAN ami elhozta a brainfuck effektet.
    Ugyan nem akartam új programnyelvet kitalálni, csak kíváncsi lettem a compilerek működésére és beszereztem pár szakkönyvet (basszus, a '80-as években már létezett ehhez magyar nyelvű szakirodalom is!) részben az akkor még létező a Országos Műszaki Könyvtárból, részben a munkahelyiből. (Csepel Művek ISZI).
    Elég rövid ideig tartott a lelkesedésem. Iszonyatosan bonyolult feladat, ha az ember komolyan gondolja és nem zseni.
    Pedig akkoriban szinte csak a kopasz nyelvek voltak használatban, nem voltak mindenféle library-k.
    Mutasd a teljes hozzászólást!
  • Új nyelvet vagy nyelvi kiegészítést viszont ki nem írt nap mint nap?
    Mutasd a teljes hozzászólást!
  • Azt szokták mondani két dolog van ami k...a bonyolult a programozásban. Operációs rendszert meg fordítót írni.
    Mutasd a teljes hozzászólást!
  • A lehetoseg ott van, hogy modult csereljunk, csak nem gondoltam, hogy valaki ezt elesben is megteszi. Ugy ertsd, hogy nem gondoltam, hogy vannak ahol eleg batrak ehhez. En azt tapasztaltam az eddig munkahelyeimen, hogy eles rendszerben meg egy szimpla szerverujrainditashoz is sok-sok jovahagyas kell "nagy" emberektol. De ezt megelozoen meg van par ora remeges
    Mutasd a teljes hozzászólást!
  • Hát elvileg az eclipse pluginok is ezt csinálják az equinox OSGi-val nem? Mármint hogy ne kelljen újraindulni mindenképpen az IDE-nek.

    Elvileg lehet, de a gyakorlatban én még nem láttam olyat, hogy egy plugin feltelepítése után ne kérte volna az újraindítást. Az OSGi csak lehetővé teszi a menet közbeni kódcserét, de ha maga a kód nincs felkészítve arra, hogy a függőségek jönnek-mennek, a komponensek leállnak és újraindulnak, akkor megette a fene.

    (OSGi környezetben fejlesztek, és lokális fejlesztésnél tök jó hogy csak egy bundle-t frissítesz és nem kell az egész JVM-et újraindítani. De megvan az ára is, ahogy írtad a szálbiztonság és a dinamikusság kezelése.)
    Mutasd a teljes hozzászólást!
  • Nem gondoltam volna, hogy vannak a vilagon olyanok, akik kepesek OSGi modulokat cserelgetni runtime :)


    Hát elvileg az eclipse pluginok is ezt csinálják az equinox OSGi-val nem? Mármint hogy ne kelljen újraindulni mindenképpen az IDE-nek.

    Meg viszonylag jól kezelhető vele a rendelkezésre állás szegmentálása is: Ha elment egy service a backend-en akkor amúgy pl. a PC app megfelelő funkciói kiszürkültek, de a többi részét használni tudtad. Meg ugye lehet olyan, hogy nincs hálózat, de a hálózattól nem függő dolgokat addig pufferelve intézgeted amennyire még lehet, aztán ha visszajön, akkor aktiválódik a send gomb  

    Szóval azért szép dolgokat is tudott az a rendszer. Ha a projekt nem 2 év késésben van amikor elkezdjük akkor nem az ilyen pró megoldások keveredtek volna pár gánnyal, hanem valszeg csak ilyen szép dolgok lennének, de azért vállalható lett így is  


    ...persze kulonbozo verzio. Naivan azt hittem...

    Na igen. Ezt jól megoldja.

    Egyébként nálunk semmi app szerver nem volt. Az OSGi konténerbe mi magunk húztuk meg a megfelelő apikat (orm, db, amq, stb.). Egy webszervert is beraktunk talán jetty-t, hogy az egész kerek történet legyen, mert amúgy ezt nem webapp volt, hanem kliens-szerver PC progi (plugin-alapú vasúti forgalomirányítási rendszer). Csak pár dolognak kellett minimál web access és azt jobb lett volna OSGi-n kívül külön deployolni amúgy, de beletettük azt is.
    Mutasd a teljes hozzászólást!
  • Nem gondoltam volna, hogy vannak a vilagon olyanok, akik kepesek OSGi modulokat cserelgetni runtime :)
    Nekem azt tetszett benne pl, hogy tobb kulonbozo JBoss MQ brokerhez kellett kapcsolodni, persze kulonbozo verzio. Naivan azt hittem, hogy mint ActiveMQ eseteben a legmagasabb verzioju kliens lib majd megoldja, de kozben nem. Igy akkor kulonbozo kliens jar-okat kellett telepiteni ahol utkoztek az osztalyok. Viszont mivel OSGi-ban lehet verziozni a java package-eket, igy konnyu volt egy bundle-ben letrehozni a connectionfactory-t, mert a relevans class-okat toltotte be. Tokre tetszett az is, hogy mindezt ki lehetett ajanlani OSGi service-kent es erre referenciat lehetett szerezni mas modulokban. Valamint az is, hogy maven repo-bol lehetet telepiteni feature file segitsegevel es meg abban is lehetett varazsolni.
    Szerintem az akkori kollegaimnak az nem tetszett benne, hogy eleg sokat kell vele pepecselni, en pedig nagyra ertekeltem, hogy ennyi energiat fektettek abba, hogy ilyen, masoknak talan jelentektelennek tuno dolgok alapbol meg legyenek oldva.
    Mutasd a teljes hozzászólást!
  • Van még egy "köztes megoldás" is, ahol csak egy már létező nyelvet bővítenek ki új kulcsszavakkal (és/vagy bővített szintaktikával), szemantikával, de nem alkotnak teljesen új nyelvet.

    Esetleg ebben is lehet gondolkodni, ha ez az eredeti cél irányába mutat.
    Mutasd a teljes hozzászólást!
  • Nem kellett sok extra. Az architect annyit kert tolem, hogy teljesen hulye biztosra irjam, mivel indiaiak fogjak hasznalni.

    Ja mi is ay AOP-al bolondbiztosra csináltuk, de eleve azért, mert már kiderült, hogy az alvállalkozók nem figyelnek a resource-ok lezárására - se a szálbiztosságra.

    A pure OSGi-nak van olyan hátránya, hogy ha tényleg dinamikusan jönnek-mennek komponensek, akkor ott a thread safety-t is magadnak kell csinálni. Ezt pattern-szerűen lehet szépen tartani az esetek többségében (pl. write lock-al védeni a bind/unbind metódusokat és read-lock-al a szolgáltatásod normális függvényeit), de erre marhára nem figyeltek, így azt megvizsgálva mit és hol rontanak el, AOP-al rátettem nekik egy bolondbiztos automatikát, hogy semmiképpen se lehessen elrontani.

    De se erőforrásunk, se időnk, se mentális energiánk nem lett volna ezt kézzel végig írni, mint azt te csináltad, mert 2 mloc volt csak a mi kódbázisunk. Szerintem az AspectJ-re azért nézz rá, mert nem csak (sőt, jellemzően nem) OSGi alatti cucc ez és tényleg ilyen esetekre van kitalálva mint ezek az esetek.

    Az OSGi-al a tesztelés inkább azért volt pró, mert a dinamikus plugin rendszer miatt - ugyanis tényleg plugin architektúrában használtuk a németekkel - szóval a dinamikusság amely moduloknál tényleg meg volt írva, ott a valós szerveren le lehetett cserélni a modulokat és komponenseket trace-elgetősre hogy kibogozd mi akad el. Na ehhez kell OSGi (meg a szálas szívás is vele már), de az AspectJ az önmagában is hasznos.

    OSGi-t mar lattam, hogy tobbszor emlitetted. Amikor 9-10 eve meglattam, akkor en is nagyon szerettem. Tulajdonkepp egyedul voltam a csapatban ezzel :), tok hulyenek neztek miatta. Sokaig nem is akartam mast hasznalni, egyszeruen annyi feature volt benne, hogy nem ertettem miert ennyire nepszrutlen.

    Hát az OSGi-nak az előnye egyben hátrány: dinamikus... Marhára kényelmetlen ez onnantól, ahol már szálak is játszanak hidd el és nem csak a kevésbé ehhez konyítgató alvállalkozó, de a németek maguk is elrontották folyton (pl. a konstruktorból szivárogtattak this referenciát és én mint leszármazott azt mindig megszívtam... reversálnom kellett a kódjuk és újrafordítani javítva...). Szóval az OSGi előnye, hogy marhára megtanít szervezni a kódot, mert hogy objektumok mellett ott van a komponens (életciklussal stb.) amiket keverheted a modulokba, amiket product-okba, de nem kizárólagosan, stb. stb. Ez jó, de én egy hasonlót olyat csinálnék, ahol pont ugyanez van, de a fordításkor / deploynál eldől mik a komponensek - vagy legalább csak induláskor dőlhet el.

    Hidd el az sokkal jobb volna...

    MÁS: Az eredeti kérdezőnek pedig - a'la miről is beszélünk végülis mi itt? Mert kapcsolódik ám ahhoz amit akar...

    Itt fel is merül viszont bennem, hogy ha pl. java-ban ilyen "Dynamic Proxy" van, mindenféle nyelven reflection csodák vannak, rust-ban, factorban macro-k vannak, meg amúgy C/C++ esetén is lehet néha X-macrokkal trükközgetni össze nagyon komoly dolgokat, akkor neki teszt framework-höz tényleg miért is kell külön nyelv. Mondom ezt annak ellenére, hogy én egyébként mindenképpen akarok új programnyelvet - ez az egyik "folyamatosan folyamatban lévő projektem"

    Szóval a nagy kérdés: megpróbálkoztál-e eredeti kérdező azzal, hogy mondjuk dynamic proxy-val, makrókkal, template-el, reflection-el vagy ami elérhető a létező nyelveken próbáld ezt megoldani? Mert meglepő sokszor milyen kényelmes dolgokat lehet csinálni! Ott az egész JEE aminek a fele dynamic proxy és reflection legalább és majdnem külön nyelvnek érzed néha már...
    Mutasd a teljes hozzászólást!
  • Ez esetben, nem lehetseges, hogy megis arra gondolsz, amit Csaboka2 ajanlott az elso hozzaszolasaban, csak meg nem esett le a tantusz?
    Mutasd a teljes hozzászólást!
  • Nem lehet, hogy te egy bot vagy aki csak forgalmat próbál generálni az oldalon? :)
    Mutasd a teljes hozzászólást!
  • Pl. ha vesszük a Java+Selenium kombinációt, szerintem egy új eszközzel  egyszerűbben meg lehet írni a teszteket. Tudom, van például a Katalon Stúdió, de az meg túl bonyolult, és ha jól tudom, csak groovy kódot generál. Van a Cypress, ami jó, de ott is pl. a javascriptet ki lehetne váltani egy esetleg objektum orientált szerű eszközzel
    Mutasd a teljes hozzászólást!
  • Tenyleg nem tudom eldonteni, hogy komolyan gondolod-e, hogy te egy uj programnyelvvel jelennel meg a piacon.

    Annyi, hogy lennenek benne ososztalyok?

    Na de ha ott vannak mar a funkciok, akkor nem kell mindenaron szarmaztatni, ha az ami ott van pont megfelel, nem? Csak peldanyositani. Miert kene minden tesztnel a tesztironak valamibol szarmaztatni es kodolni rengeteget mielott elkezd tesztelni?
    Mutasd a teljes hozzászólást!
  • Akkor én is leírom, hogy szerintem mire gondolhattál, mi után kutatsz.
    A Ruby-hoz készült egy RSpec nevű tesztelési nyelv. Különösen akkor hasznos, ha nem csak Ruby scripteket akarsz teszelni, hanem hozzájuk kapcsolódó, azokban előforduló Java osztályok is vannak.
    Még inkább érdekes, ha a JRuby-t használod, az ugyanis közös JVM-ben tud futni a Java-val.
    Szépen működik benne például a reflection is. Meg egyéb nyalánkságok.
    Mutasd a teljes hozzászólást!
  • Java-n alapult. Annyi kellett, hogy meg tudjak tolni a microservice-eket es ellenorizni a vegeredmenyt, db-ben, file rendszerben, queue-ban, mikor-hol.
    Nem kellett sok extra. Az architect annyit kert tolem, hogy teljesen hulye biztosra irjam, mivel indiaiak fogjak hasznalni. Tehat barmi, ami felreertest okozhat, azt rejtsem el, felhasznaloi szempontbol legyen minimalisztikus, de kellokepp "intuitiv".
    Nem teljesen builder pattern-re epult, csak ranezesre, inkabb metodus hivasi lanc volt benne. Annyi volt a lenyeg, hogy ha meghivjak a e2e.db().mysql().query("") vagy e2e.jms().activemq().queue().....send()/receive() vagy e2e.ftp()... stb metodusokat, akkor az adott metodus hivas utan ott ne lgyen semmi masra lehetoseg, csak arra ami az adott kontextusra ervenyes. Ha pl epp a jms()-ben vagyok, akkor onnan mar csak brokert lehessen valasztani, aztan onnan mar csak queue/topic nevet definialni es uzenetet kuldeni/fogadni.  pl volt oracle es mysql adatbazis is, sok tablaval. De semmi orm nem volt ebben, csak mogotte egy DbUtils queryrunner futott, amibe be volt kotve egy pooled datasource. Beirta a lekerdezest ,visszajott az object[] lista, azt mar lehetett assert-alni, hamcrest-ben konnyen. Ennyi. Vagy pl classpath-rol file-t beolvasni, jms queue-ba betenni, aztan ellenorizni a vegeredmenyt a "tuloldalon" XMLUnit-al vagy ami eppen kellett az adott dologhoz, tok mindegy. Mindent nagyjabol igy kell elkepzelni. Lenyegeben csak konfiguralni kellett aztan metodusokat hivogatni, 1-2 sor, aztan assert.

    OSGi-t mar lattam, hogy tobbszor emlitetted. Amikor 9-10 eve meglattam, akkor en is nagyon szerettem. Tulajdonkepp egyedul voltam a csapatban ezzel :), tok hulyenek neztek miatta. Sokaig nem is akartam mast hasznalni, egyszeruen annyi feature volt benne, hogy nem ertettem miert ennyire nepszrutlen.
    Mutasd a teljes hozzászólást!
  • Nálam az ötlet ott csúszna el, hogy a funkcionális programozást kedvelem, így tesztelésre biztos nem csinálnék osztályokat, főleg nem egy X. nyelvet.
    Az FP mellett TDD fejlesztést is követem ( épp azért FP inkább mint OOP, mert sokkal könnyebb tesztelni ), TS/JS esetében elég egyszerű egy Jest-et használni például a tesztek megírására. Amiben pont az a lényeg, hogy az adott nyelven megírt függvényeket lehessen minél egyszerűbben tesztelni, ezért praktikus pure function-okat használni ahol lehet, mert az már önmagában biztosít arról, hogy elég a különböző bemeneteket letesztelni, a válasznak ott egyértelműnek kell lenni. Ellenben egy OOP megoldásnál az adott class eleve belső állapottal rendelkezik, és ahhoz relatíve lehet tesztelni a funkcióit.
    Mutasd a teljes hozzászólást!
  • Ismételni fogom magam: nézz körül a meglévő eszközök között, mielőtt nekiállsz sajátot csinálni. A JUnit például évtizedes múlttal rendelkező teszt framework, mindenféle külsős és beépített bővítménnyel. Még csak nem is kellett új nyelvet feltalálniuk, a Java teljesen alkalmas a feladatra, ha sok-sok annotációval megtámogatod.

    De ha a JUnit nem szimpatikus, akkor vannak alternatívái is, amik szintén tesztelésre kihegyezett framework-ök. Ezek közül is mindenképp érdemes egyet-kettőt megnézni, mielőtt feltalálod újra a meleg vizet.
    Mutasd a teljes hozzászólást!
  • Egy tesztelés orientált nyelv szerusegre gondoltam. Mondjuk lennének benne ős teszt osztályok, amik minden tesztben benne vannak. És akkor a teszt írója ebből az ős teszt osztályból tudna származtatni. De még nem gondoltam át eléggé a dolgot.
    Mutasd a teljes hozzászólást!
  • Mi  lenne a célod ezzel az új programnyelvvel? Mert például a Rust-ban ott van a macro amivel ha akarsz egy szinte tetszőleges "nyelvet" létrehozhatsz. Plusz a rust elég sok mindenre le tud fordulni, többek közözött webAssembly-ra is.
    Mutasd a teljes hozzászólást!
  • Java-nak hangzik amit írsz. Esetleg egy AspectJ-vel nem lett volna érdemes megfűszerezni?

    Gyakorlatilag tudsz vele olyanokat, hogy minden (vagy minden jelölt) függvény hívás elé-mögé automatikusan kódot tesz ahol eléred a paramétereket stb.

    Azért mondom, mert még olyan dolgokra is használtuk, hogy JEE-szerű tranzakció-kezelést, meg automatikus connection lezárást / cache-elést adtunk egy nem-JEE (OSGi) java kódhoz, de ilyen logolás / tesztelés pont a kézenfekvő területe az aspektus orientált programozásnak nem?
    Mutasd a teljes hozzászólást!
  • Par eve az egyik feladatom az volt, hogy irnom kellett egy test harness-t, hogy megkonnyitsuk az end2end tesztek irasat. Kb 1 honapig "szuttyogtem" vele.
    Szabad kezet adtak, nem kell semmi extrara gondolni, meglevo framework-okben elerheto dolgokat bewrap-eltem builder pattern-el, mai divatos kifejezessel azt hiszem ez a fluent interface api. Igy vegeredmenyben minden 1 sorbol vegezheto volt: jms uzenet kuldes, fogadas, ftp, email, http, xpath, file beolvasas pl stringbe, file-ba iras, sql, stb, aztan mar csak asserteket kellett irni. Hamcrest-et es cucumber-t hasznaltunk.
    Nem emlekszem mindenre, eleg sok komponens volt benne. Sok mindenrol talan elsore nem is gondolnad, hogy mar ugy is mennyire kompakt, ahogy egy framework szolgaltatja, es ezen meg tudsz csavarni egyet. Egy builder osztalyban eleg sokmindent el lehet rejteni es frappansan inicializalni, igeny szerint. 

    Nem kell neked sem nagy dolgokban gondolkodni. Kezdetben irj valamit, ami megkonnyiti a munkadat (esetleg). Aztan kesobb raersz nagyban gondolkodni.
    Mutasd a teljes hozzászólást!
  • Amúgy a HolyC-nek vannak király elemei is - kifejezetten kevésbé húbortos dolog, mint a TempleOS úgy magában
    Mutasd a teljes hozzászólást!
  • Ez mind igaz.
    Mutasd a teljes hozzászólást!
  • nem-tudom-hogyan-kell-belinkelni-azt-a-gifet-amin-michael-jackson-pattogatott-kukoricat-majszol
    Mutasd a teljes hozzászólást!
  • Bocsanat, de nem biztos, hogy ertem mi tortenik.
    Multkor meg heti 40 ora foallas + 20 ora mellekallas volt a kerdes, ezzel parhuzamosan 3 kulfoldi munkan valo vacilalas, most pedig framework iras? Nem tudom most hirtelen, hogy 1 het eltelt-e ezek kozott
    Mutasd a teljes hozzászólást!
Címkék
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd