Mi a lenyegi kulonbseg a script nyelv es a nem script nyelv kozott?

"Ma már nincs nagyon értelme ennek a megkülönböztetésnek, "

Igen, ez így van. Ezért is írtam, hogy nem vitázom ezzel a kiterjesztett meghatározással, mivel a technikai háttér és a körülmények, a felhasználás körülményei nagyon megváltoztak. A korábbi markáns határ mára elmosódott. A feladatkörök egymásba csúsztak.

A dolgot inkább az adott nyelv tervezési oldaláról lehetne vizsgálni, de kérdés, hogy érdemes-e?

"Szerintem ma már elég hülyeséget hallottunk"

Tőled.

Csavart be- vagy kicsavarni, szöget beverni lehet kombinált fogóval is, de ettől még nem lesz a kombinált fogóból se csavarhúzó, se kalapács.

11: (2023.09.20 02:14) Továbbra is látszik, hogy fogalmad sincs mit írsz. Főleg nem vagy tisztában az egész történetiségével mert ennek történeti alapjai vannak. Tudjuk, hogy a delfi az egyetlen egy üdvőzítő megoldás mindennek a megoldására de most kicsit vedd le a delfi szemüvegedet.

"A korábbi markáns határ mára elmosódott." Ilyen határ korábban sem volt. Sőt soha nem volt. A határ egyedül annyi volt, hogy a korai scriptnyelveket (ahogy korábban írtam helyesebb lenne ezeket batch vagy job nyelveknek nevezni ld. a már általam említett OS360 JCL) alapvetően vagy a shell vagy nem interaktív felhasználás esetén az ütemező hajtotta végre. Valójában arra voltak kitalálva, hogy a futtatáshoz beállítsuk azt, hogy melyik programot, milyen bemeneti adatokkal (fájlokkal), milyen bemeneti konstansokkal futassa, hova tegye a kimenetet, hogyan futassa. Valamint amikor elterjedtek az interaktív shellek (ld. pl. Unix) akkor valahol kellett az, hogy ha más nem a bejelentkezéskor beállítsa a "környezetemet" ld. pl. bash profile ne kelljen egy rakás parancsot minden bejelentkezéskor újra és újra begépelni. Illetve ezeknél is (és a mai napig is) lehetőség van non interaktív futtatásra (pl. linux környezetben cron, at) ekkor is érdemes olyat csinálni amit a parancsértelmező tud feldolgozni majd az szépen sorban indítja a többi akár már valami használható nyelven megírt (és lefordított) cuccot fordítani.

És, hogy miért volt "éles" a határ? Mert a korai script nyelvek nem voltak teljesek pl. hiányzott belőlük pl. a lebegőpontos aritmetika. Valami egész aritmetika volt bennük, mert elagázast, ciklust tudtak kezelni. Tényleg kb. arra volt jó, hogy kvázi össze állítsa azt a parancssort amit amúgy bepötyögnék esetleg több tucat paraméter megadásával (ld. pl. gcc fordítási opciói és a make esete). Amikor a "gépidő" és a "futásidő" illetve a memória "drága volt" (pl. mert nagyobb gépet kellett venni, vagy bérbe történt a futtatás azaz X cégnek volt gépe az Y-nak nem, de kellett valami feladathoz akkor az Y cég a felhasznált erőforrások alapján fizetett X-nek /egyébként innen van az account - számla elnevezés is, mert ezért kőkeményen ment az elszámolás, ki mit mire használt az oprendszer szépen "accountonként" gyűjtötte az adatokat majd a pénzügy a hó végén küldte a már USD vagy HUF számlát mert mgevolt, hogy T "tick" CPU, M összes memória használat, D összes diszk használat meg egy rakás dolognak mennyi a Ft/USD egységára egy szorzás és megvolt a hó végén a befizethető számla és lehetett mennei a pénztárhoz fizetni.../ ekkor érdemes volt a lehető leghatékonyabbra megírni a programot. Nem véletlen, volt hogy ebben az időszakban "osztódással szaporodtak" a programnyelvek, mert volt ami ebben volt erős, volt ami abban (ld. pl. Fortran - Algol vita). Sok esetben egy Algol program volt hatékonyabb de ha komplex számokat kellett kezelni esetleg bonyolut matekkal akkor arra ott volt a Fortran. És így tovább és így tovább. Majd jött az 1990-es évek vége, 2000-es évek eleje amikor relatív rövid idő alatt mind a processzor mind a memória ára (teljesítmény arányos ára) zuhanni kezdett de nagyon brutálisan. És egyre kevésbé kellett a HW irányból közelíteni a fejlesztést. Egyre inkább az kezdett számítani és ez a mai napig is így van (ld. pl. Python) hogy a TCO-ban ma már egyre nagyobb "szeletet kihasító" fejlesztési költség legyen csökkenthető, max. veszünk 2x akkora gépet, még mindig olcsóbban jövünk ki hosszú távon. És kerülnek előtérbe azok a könnyebben megfogható nyelvek és rendszerek ahol esetleg ugyan HW zabálóbb módon de a programozónak ezerszer kényelmesebben lehet eredményt elérni. Ezzel párhuzamosan fejlődtek nagyon sokat a korai "csak futtatásra kitalált" batch/job/script nyelvek. Mert egyre inkább elviselte ezt a HW. Ld. pl. hogyan nő magának a shellnek a mérete (parancsértelmező) hiszen ezeket a parancsértelmező dolgozta fel. Minél több funkció kerül bele a batch nyelvbe annál nagyobb parancsértelmező kell. És amikor volt összesen pl. 32 kByte memória a gépben és ebbe kellett elférnie az operációs rendszernek, a parancsértelmezőnek, a fordítónak és magának a programnak azért ott nem lehetett Python szintű script nyelvet kitalálni a futtatáshoz. És ebben a 32 kByte memóriában már tudtak egyszerre 3 feladatot végrehajtani! (a már említett OS360 esetén az ajánlott minimális memória 32kByte volt, azon már el tudott futni! 1960-as évek vége). Ezerszer egyszerűbb egy olyan fejlesztés amikor összerakom a scriptet és egy interpreter "megrágja, megemészti és kiköpi az eredményt" mint az, hogy forrásnyelv->fordít->linkel->futtat->hibakeresés->fordítás->linkelés... egy bizonyos alkalmazás méretig rengeteg idő megspórolható. Főleg ha egy amúgy interpretált script nyelv esetén lehetőség van akár futtatható binárist előállítani. A gép elég gyors, memória van bőven akár az is belefér, hogy az egész cuccot interpreterestül, könyvtárastul mindenestül egybe csomagoljuk és "ha megvette, hadd vigye" és kész a cucc.

Vö. akár egy egyszerű "állítsunk elő 1000 db. prím számot és irassuk ki a képernyőre" típusú alapfeladatnál. C-ben és Pythonban melyik esetén lesz hamarabb eredmény (esetleg ugyanazon a gépen), ha most kapod meg pl. egy versenyen a feladatot.

"De a script nyelvben is ugyan az megirhato?"

Bármilyen Turing-teljes nyelvben bármi megírható. Legfeljebb kicsit macerásabban, és nem olyan hatékonyan. De nem attól lesz valami szkriptnyelv vagy sem, hogy mit lehet benne megírni, meg mit nem. Ez pusztán annyi, hogy hogyan történik a program utasításainak feldolgozása: "röptében", beolvas egy sort, értelmezi, végrehajtja; vagy lefordítja binárissá, és azt futtatja. A nyelv képességei nem ezen múlnak, a különbségek sokkal inkább a gyakorlati felhasználásban vannak:

- Szkripteknél a forrás szükséges a futtatáshoz, így kereskedelmi szoftvereknél ezek használata kizárt.

- A szkriptek futtatásához a megfelelő értelmezőnek telepítve kell lenni a rendszeren, ezért sem ideális pl. kereskedelmi szoftverek készítésére.

- Lassabbak is, mint a natív binárissá fordított programok.

- Viszont maga a fejlesztés potenciálisan gyorsabb, mivel azonnal futtatható, nem kell minden egyes változtatáskor lefordítani binárisra, és úgy futtatni. (Bár ez azért manapság nem minden esetben jelent számottevő hátrányt, pl. gcc-ben lefordítani egy közepes méretű programot pár másodperc.)

- Ezek mellett ÁLTALÁBAN a szkriptnyelveket eleve úgy tervezik meg, hogy kevésbé hozzáértők számára is barátságosak legyenek, mivel ezeket nagyon gyakran olyanok (is) használják, akiknek nem fő területük a programozás. Ebből adódóan sok szkriptnyelv például elég lazán kezeli a változókat, és a programszerkezetet.

#7 "a Python hiába scriptnyelv, ugyanúgy bájtkódra fordít, amit egy virtuális gép futtat, mint pl. a Java vagy a C#"

Nem.

A Pythont a Python értelmező fordítja, méghozzá nem úgy, hogy előbb előállít a memóriában egy bájtkódot, és utána azt futtatja, hanem a klasszikus módon, sorról sorra feldolgozva. Ezt könnyen le is tesztelheted: írj egy szintaktikailag hibás kódsort a programba! Indítsd el! Ameddig oda nem jut a vezérlés, a programod futni fog... Ami előbb a RAM-ban létrehozza a natív kódot, és azt futtatja, az például a Perl.

Perszeee, vannak mindenféle mókolt fordítók, amik így vagy úgy, de mégis .exe-t csinálnak a szkriptből, de nem ez a jellemző.

"Ami előbb a RAM-ban létrehozza a natív kódot, és azt futtatja, az például a Perl."

A Perl nem csinál semmiféle natív kódot. A Perl ízig-vérig scriptnyelv, a scripteket pedig a saját VM-én (régen a parrot volt ez) futtatja.

"A Pythont a Python értelmező fordítja, méghozzá nem úgy, hogy előbb előállít a memóriában egy bájtkódot, és utána azt futtatja, hanem a klasszikus módon, sorról sorra feldolgozva. Ezt könnyen le is tesztelheted: írj egy szintaktikailag hibás kódsort a programba! Indítsd el! Ameddig oda nem jut a vezérlés, a programod futni fog"

Úgy tűnik, ezzel is lábon lőtted magad. A python is VM-en futtatja a scriptjeit, ráadásul esélyes, hogy a python VM-e is a parrot nevű regiszteres VM valamelyik forkja.

Az nem bizonyíték, hogy csak a hibás sorig fut.

14. “ A Pythont a Python értelmező fordítja, méghozzá nem úgy, hogy előbb előállít a memóriában egy bájtkódot, és utána azt futtatja, hanem a klasszikus módon, sorról sorra feldolgozva.”

Hát ez rohadtul nincs így, nézz utána kicsit. Kezdd ezzel: [link]

2023.09.20 09:38

Veled az a gond, hogy te nem érvelni, hanem inkább kötekedni szeretsz. Ahogy teszed ezt most is. Ráadásul, nem ritkán úgy állsz ebbe bele, hogy a tényeket egyszerűen meghamisítod. Az nem baj, ha valaki gondolkozik, fejtegetésekbe bocsátkozik. De az már igen, ha ez a valaki a saját agymenését, a képzelgéseinek, gondolat-kisérleteinek produktumát mindjárt a történelem részévé is teszi. :)

Ez az egyik baj veled. A másik, hogy sokszor magadnak is ellentmondasz. Itt egy példa: Először azt állítod, hogy nem volt semmiféle határ, aztán három mondattal lejjebb meg te magad hivatkozol arra a bizonyos határra, ami, korábban szerinted nem létezett, soha nem is volt.

Idézlek:

"Ilyen határ korábban sem volt. Sőt soha nem volt."

Később, szintén te ezt állítod:

"És, hogy miért volt "éles" a határ? Mert a korai script nyelvek nem voltak teljesek pl. hiányzott belőlük pl. a lebegőpontos aritmetika. "

Az meg valami csodálatos, amikor úgy mondasz nekem ellent, hogy két sorral odébb már ugyanazt kukorékolod, amit én korábban leírtam.

A scriptnyelvek, meg a batch.

A scriptnyelvek nem a batch-ből feljődtek ki és nem is azért, mert úgy gyorsabb a fejlesztés. Szerencsére vannak helyes megállapításaid is, mint pl az, hogy a turing teljes nyelveken bármit meg lehet írni. Ennek mentén érdemes tovább lépni. A scriptnyelvek, ahogy te - szintén helyesen - megjegyzed, jobbára csökevényes, erősen célorientált nyelvek, ahol is a fejlesztő nem tartotta szükségesnek, hogy bizonyos nyelvi jellemzőket, eszközöket (pl. OOP, garbage Collector, lebegőpontos aritmetika, string műveletek, változó és függvény deklaráció, fejlett tipus támogatás, stb.) a produktumába beépítsen, hiszen az nem csak fölös munka lett volna, de még lassította volna a nyelv interpreterét.

Ez egy nagyon jó, megállapítás. A célorientáltság. Ez olyan, ami a scriptnyelveket abszolút jellemzi!

Na de nézzük már meg, hogy pl. a python, vagy a php, a soroltak közül miben szenved hiányt? Hát bizony, azt találjuk, hogy kb. semmiben!

Kinek jut eszébe, hogy egy általános célú nyelv helyett, egy interpretált, csökevényes nyelven fejlesszen nagy terhelhetőségű applikációkat? Néhány hülyén kívül, nyilván senkinek. Ebből következik, hogy a scriptnyelvek nem arra készülnek, hogy azokban alkalmazásokat, legalábbis, nagy-alkalmazásokat készítsenek. Hogy ez esetleg mégis megtörténik, az nem oszt, nem szoroz. Ott csak hibás eszközválasztás a dolog eredménye, vagy más szempont.

Ez a szempont meg, már ha van ilyen, az internet esetében a transzparencia.

Mert, hogy is nézne már ki, hogy Puang Bang Lee nekiül, ír valamit, valamilyen nyelven, a világ másik végén, azt lefordítja binárisra, az itt tanyázó usereknek meg le kellene tölteniük és lokálisan futtatniuk azt a valamit? Aztán vagy történik nem kivánt esemény, vagy nem.

Hát ezért nyertek teret az interpreteres nyelvek, és nem a TCO miatt, amire te tévesen hivatkozol.

Az interpreteres, vagy inkább interpretált nyelvek, nem azonosak a scriptnyelvekkel, mert nem ugyanolyan célból készültek. A scriptnyelvek, ahogy te magad is mondod, könnyen tanulható és tanítható, egyszerű nyelvek, az interpretált nyelvek meg, lehetnek bonyolultak (perl), és eszközeikben, paradigma támogatásban sokoldalúak (python).