[Javalist] ScriptBasic for Java 1.0.4 available

2013. Jan. 20., V, 14:40:18 CET

Azzal a reszevel nem ertek csak egyet, hogy egy embedded nyelvnek ne
lenne barmire szuksege, amire egy intepretalt nyelvnek.

Ezt annak fenyeben tartom kerdesesnek, hogy az embedded nyelvek donto
tobbsege mar letezo nyelv, azok teljes szintaxisaval implementalva.
Ott van a JRuby, a JPython, a Perl Java interpereteret nem tudom hogy
hivjak, a Quercus, mind-mind a nyelv teljes feature-keszletet
imlpementaljak, tobbe-kevesbe csorbitas nelkul. A JRuby es a JPython
teljes mertekben a Java sajat memoriamenedzsmentjere tamaszkodik,
erintolegesen tamogatva csak a memoriamenedzsmenthez kapcsolodo
sajatnyelvi elemeket.

A masik, amit a kikonfiguralhato utasitasokrol irsz: szerintem
egyreszt felesleges per utasitas definialni ezt, masreszrol pedig
kenyelmetlen is lehet.
Abban egyetertek, hogy nincs minden alkalmazasnak minden utasitasra
szuksege. Hogy a JRuby-nal vagy a JPython-nal van-e ekkora szintu
hatalom az interpreter felett, nem tudom, mindenesetre a cel jo es
egyetertek vele. Viszont ahogyan a Java sem utasitasokban meg
objektumokban gondolkodik a security ertelmezesekor, hanem bizonyos
korlatokban, ugy ez talan itt is kovetendo pelda lenne: pl. legyen/ne
legyen fajlkezeles, ha nincs, kapcsoljuk ki az
OPEN/CLOSE/PRINT#/INPUT#/GET# parancsok ertelmezeset. Egyszerubb is
implementalni, es konnyebb is megerteni.

Tehat: a koncepciot jonak tartom, hogy lehessen valasztani a fajlok
hozzaferesenek kikapcsolasat, azt azonban nem tartom jonak, hogy egy
letezo nyelv a feladatnak megfelelo szintaxisat ne implementaljuk csak
azert, mert ugy gondoljuk, hogy mi okosabbak vagyunk a nyelv
kitalaloinal. Meg az is lehet, hogy igy is van, mindazonaltal egy
ilyen csorbitas utan a nyelv maga nem lenne tobbe azonos az eredeti
nyelvvel, hiszen nem egy-ket fuggveny implementalasat hagyjuk ki,
hanem szintaktikai elemeket. Olyan, mintha lenne egy C-ben irt Java
interpereter, ahol nem lehet a 'class' kulcsszot alkalmazni, helyette
kulonfele hashtablakba kellene fuggvenyeket regisztralni, mert a C meg
igy oldja meg az osztalyok kezeleset, es minek mast hasznalni, mikor
ez egy nagyon jol bevalt megoldas.

Ha en, mint ScriptBasic fejleszto lepnek fel, engem nem erdekelne,
hogy a mogottes intepreter miben van irva, es hogyan dolgozik. Nekem
ki van adva, hogy olvassak be egyszeru szovegfajlokat, es egy
beregisztralt, adott parametersorrendu fuggvenynek adjam at oket. Nem
biztos, hogy ehhez en akarnam ismerni azt, hogy milyen interpeter van
a Basic scriptem mogott, es annak mi nyugje van. Olyan, mintha egy MVC
szemleletben fejlesztett programnal azert nem lehetne YAML fajlokat
parzolni a modell szintjen, mert a View-nak gondjai vannak bizonyos
objektumok atalakitasanal. Osszekeverednek a szintek.

Felreertes ne essek: tisztelem a munkadat, es orulok hogy egyaltalan
valaki valamilyen formatumban tamogatja a BASIC nyelvet ebben a modern
vilagban, nagyon kevesen vannak olyanok, akik barmit is latnak egy
ilyen oreg es kivenhedt nyelvben. Amit en szeretnek hozzaadni a
temahoz, az egy oreg es kivenhedt BASIC fejleszto szempontjai. Nem
sertodok meg, ha a vegen oda lyukadunk ki, hogy nincs igazam.

Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
MSN: hrgy at vipmail.hu
Skype: hron84

2013/1/20 Peter Verhas <peter at verhas.com>:
> Különböző célra készült 1996-tól a ScriptBasic Classis, és 2012-től a
> ScriptBasic for Java. Az első C környezetbe való integrálást tesz lehetővé,
> míg a második Java környezetbe.
>
> Ugyanakkor a C-ben írt alkalmazásokba illesztett scripting megoldások által
> megkívánt és a Java alkalmazásokban használt scripting mást követel. C-ben
> nincs olyan egyszerű library illesztési lehetőség, mint Java-ban. Ezért,
> hogy egyáltalán használható legyen a nyelv sok rendszer közeli függvényt meg
> kellett valósítani, és ha már a nyelv implementációs része kellett, hogy
> legyen, akkor a legjobb megoldásnak az tűnt, hogy a nyelv szintaktikának is
> a része legyen, hasonlítson minél jobban a megszokott BASIC-ra.
>
> A ScriptBasic for Java esetében a Java jellegzetességéből adódóan kevésbé
> fontos, hogy fájlokat lehessen direktben elérni nyelvi szinten. Amikor egy
> alkalmazás scripting megoldáshoz nyúl nagyon ritkán kell a script kódnak
> fájlokkal dolgozni. Általában a scripting részek magas szinten üzleti
> logikát írnak le, és ennek megfelelően üzleti objektumokkal dolgoznak. Ez
> igen messze van a fájlok direkt kezelésétől. Sőt: egyenesen kellemetlen
> lenne a legtöbb alkalmazás számára, ha a scriptek hozzáférnek a
> fájlrendszerhez, és műveleteket tudnak végezni. A classic implementációban
> is kikapcsolhatóak ezek az utasítások (tulajdonképpen minden egyes utasítás
> kikonfigurálható API-n keresztül), de ezt mind le kellett programozni a
> körbeölelő programnak, amelyikbe a classic verzió belekerült.
>
> A classic használatának egy nagy gátja volt mindig is, hogy az üzleti
> objektumokat, más szavakkal a ScriptBasic-ből meghívható függvényeket
> interfész függvényeken keresztül lehetett és kellett meghívni, és ezt minden
> meghívandó függvényhez le kellett gyártani. Az interfész függvényeknek
> speciális hívási, argumentum struktúrája van a classic verzióban, meg van
> adva, hogy milyen értéket kell visszaadnia egy ilyen függvénynek. Összetett,
> bonyolult, és annak ellenére, hogy az interfész függvények írását nagyon sok
> C preprocesszor makró segíti nem sokan vették a fáradtságot, hogy ilyent
> írjanak. Ezen kívül minden ilyen kiegészítésnek a ScriptBasic Classic
> interpreter memória menedzsmentjét kellett használnia, tehát ezt is meg
> kellett tanulni. (Amúgy a többi C-ben írt scripting nyelv is hasonló utat
> követ, például a Perl egyenesen saját preprocesszort használ hogy a C
> interfész függvényeket előállítsa az XS fájlokból, aminek az írását
> természetesen ugyancsak meg kell tanulni. Ha valakit ez a rész mélyebben
> érdekel, akkor fent vannak a slide-ok amiket egy fél év alatt adtam le a
> BME-n 2003-ban talán, Pongor Gyurival közös tárgyban. Ha valaki nem bízik
> bennem, akkor a Python hasonló interfésze is jó példa: tiszta, világos,
> érthető. Majdnem ugyanaz a struktúra, mint a ScriptBasic, és egyrészt
> megerősített, hogy jó úton jártam, amikor megismertem, másrészt átkoztam
> magam, hogy miért kellett kitalálnom a meleg vizet, amikor már megvolt.)
>
> A Java környezet a reflection-nel lehetővé teszi, hogy ne kelljen semmilyen
> interfész függvényt írni, és a memória menedzsmentet is nagyon jól ellátja a
> Java, azt sem kell implementálni. Mivel a Java esetében az alkalmazások
> várhatóan inkább nem használnak fájl kezelést, mint igen, ezért logikusnak
> tűnik az a döntés, hogy alapból NE legyen benne fájl kezelés, de külső
> modulként igen. A külső modul pedig függvényeket tud definiálni,
> utasításokat (egyelőre) nem.
>
> Kicsi azoknak a tábora, akik mind a kettőt használni akarják, és akiket
> ezért zavar, hogy a két megvalósított nyelv nem kompatibilis.
>
> Mivel széleskörű felhasználói tábora a sb4j-nek nincs, ezért a fentiek, már
> ami azokat a dolgokat illeti, hogy a felhasználóknak mire van/lesz
> szükségük, nagyrészt csak a megérzéseim a szakmai tapasztalatom alapján: én
> mint Java fejlesztő mire használnék egy beillesztett scripting lehetőséget.
> Aztán, mint a classicnál is, majd az idő megmondja.
>
> --
> Verhás Péter
> peter at verhas.com
> +36(30)9306805
> skype: verhas
>
>
>
>
> On 2013.01.19., at 11:09, Gábor Garami <gabor.garami at hron.me> wrote:
>
> sb4j nyelvi szinten
> nem kompatibilis az elodjevel? Miert jo ez?
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>