Miért nincs a python?

13, Ez az auto-py-to-exe megint nem compiler, csak a python interpretert és a futtatni kivánt forráskódot gyömöszöli bele egy nagy fájlba.

Én olyan kompájlerre lennék kiváncsi, ami natív gépi kódot eredményez. Bemenet a python forrás, a kimenet meg egy futtatható állomány, ami csak a forráskódból gépi kódra fordított állományt tartalmazza, persze az exe formátum által megkivánt dolgokon kívül.

"A programnyelveket valamilyen céllal fejlesztik, és nagyon kevés kivétellel össze vannak nőve a platformjukkal."

Mi van??? Ne röhögtess már.

" A JavaScript JavaScript VM-en fut, a Java JVM-en, a C# a .NET platformon, a Go/Rust/C/C++ pedig natívra fordul."

Miféle baromságot hordasz össze itt, ember? Olyan buta vagy, mint a föld és még neked áll följebb? A JAVA JVM-en vagy natív JAVA processzoron fut, de csak addig, amíg nem írnak egy java compilert. Persze nem írnak, mert a java eleve olyan nyelv, amihez nem nagyon éri meg ilyet írni. Egyszerűbb más nyelvet választani.

A dot net nem platform, hanem egy sok mindent magába foglaló framework. A C# kódot pedig a CLR nevű virtuális gép (kb mint a JAVA VM) futtatja.

A C-nek létezik interpretere, nem is egy. Nem kéne neked ide befinganod a hülyeségeidet, ostoba, félművelt dilettáns vagy.Bár azzal, hogy félműveltnek neveztelek, még alaposan el is túloztam a képességeidet.

"nem tudsz olvasni"

"fogalmad sincs, mi az az AST"

"ne itt petézzétek már le a hülyeségeiteket"

"másik hülye duma, a te állításod"

"a hozzá nem értők szokásos faszkodása"

"tudom, hogy egy dilettánshoz van “szerencsém”"

"Miféle baromságot hordasz össze itt"

"Olyan buta vagy, mint a föld"

"Nem kéne neked ide befinganod a hülyeségeidet"

"ostoba, félművelt dilettáns vagy"

A hajdan volt #coders.hu IRC csatornát idéző eszmecsere... :)

Hozok popcornt...

Itt a c minusz minusz specifikációja. Ez írja le magát a nyelvet.

[link]

@15:14

"Ez az auto-py-to-exe megint nem compiler, csak a python interpretert és a futtatni kivánt forráskódot gyömöszöli bele egy nagy fájlba."

Nem írtam hozzá semmi megjegyzést, csak mint .py fájlból windwos-ra .exe linuxra ELF fájlra fordító.

Egyébként alapból nem egy nagy fájlba rakja bele, ez opcionális, hogy egybe rakja. Alapból a keretrendszert is köré rakja ami több fájlból áll. Így, ha a megfelelő fájlok ott vannak több végrehajtható fájlt (nevezzük exe-nek) is rakhatunk ugyanabba a mappába, így ugynanazon keretrendszerbeli fájlokat több exe is tud használni.

"Én olyan kompájlerre lennék kiváncsi, ami natív gépi kódot eredményez. Bemenet a python forrás, a kimenet meg egy futtatható állomány, ami csak a forráskódból gépi kódra fordított állományt tartalmazza, persze az exe formátum által megkivánt dolgokon kívül."

Mit tekintünk egyáltalán compiler-nek, ill. gépi kódra fordított állománynak? Ha egy .py fájlból készít egy .exe fájlt ezek szerint ahogy te értelmezed nem minden esetben compilert fájl. Viszont akkor ennyi erővel bármilyen .exe fájlt ami .NET keretrendszert használ ill. amelyikbe egyetlen nagy exe-be ez bele van fordítva azt nem comiler-nek tekinthejtjük. Meg egyáltalán hol a határ ami még comliler-olt meg ami már nem? Ha úgy veszem már ott bukott hogy nem natív kód, hogy egyáltalán függ az alap operciós rendszertől, az egyéb keretrendszer függőségekről még nem is beszélve. Ha akarom önkényesen mondhatom, hogy csak a csupaszgép programot tekintem igazi gépi kódú programnak, operációs rendszer nélkül közvetlenül a hardverhez hozzáférve működő. Persze még ebbe is bele lehet kötni, mert ez még nem zárja ki hogy implenetálva legyen benne egy python interpreter.

Egyébként pedig olyan compiler-t nemigen fogsz látni, maximum az eredeti python működéséből valamit fel kell adni hozzá. Bizonyos megszorításokkal, adott peremfeltételekkel lehetne beépített python interpreter nélküli exe-t fordítani belőle. Viszont az hogy garantáltan az legyen a működése mindig olyan nem lesz. Csak abba gondoljunk bele hogy egy változó típusa dinamikusan változhat a python-ban. Ennek működése során is a megfelelő kivételeket kell dobnia a megfelelő esetekben, a type-vel mindig elérhetőnek kell lennie és konvertálhatónak kell lennie string-é. Az osztályok dinamikusan újra definiálhatóak futási időben, ha korábbi osztály példányosításából megmaradt objektum annak konzisztensen kell tovább működnie stb. Nem is sorolom tovább, egyszerűen kizárt hogy erre olyan szintű compiler létezzen valaha. Ahhoz előbb helyességbizonyítsd hogy interpreter nélkül is konzisztensen ugynaz lesz. Ennél sokkal egyszerűbb dolog is túl bonyolult ahhoz, hogy számítható legyen.

Aki tanult mélyebben informatikát az kellett, hogy halljon a busy beaver magyarul elfoglalt hód. Ami az elméleti informatikában egy játék melynek célja, egy adott méretű befejező program megtalálása, ami a lehető legtöbb kimenetet produkálja. Mivel könnyen lehet végtelen ciklust csinálni, így örökké futó programot írni, ezért ezen programok ki vannak zárva a versenyből. A részletekbe nem belemenve megemlítem, hogy mindössze csak 5 állapotú gép esetében már nem ismert melyik program a hódbajnok. jelöljük Σ(n)-el az n állapotú gép hódbajnok amennyi kimenetet produkált. Ekkor ez a Σ(n) függvény létező függvény, de matemaitai értelemben is kiszámíthatatlan és aszimptotikusan gyorsabban nő bármely kiszámítható függvénynél.

Aki nem sokat értett ebből, akkor még hozzáteszem hogy python-ban van olyan, hogy exec és eval. Ezt ,hogy az életbe oldanád meg hogy konzisztensen működjön python interpreter nélkül a compiler-olt kódban? Az input string a standard inputról is jöhet ami előre nem ismert.

Sajnos te is írsz olyan dolgokat, amiket nem kéne.

A natív kód az natív kód. Az bármiféle oprendszertől függetlenül az. Meghívhat oprendszer szintjén külső kódot (file megnyitása, lezárása, hozzáfűzés, vagy valamilyen API függvény, memória igénylés), de a futtatható állomány akkor is natív.

Amit a .net keretrendszerről írsz, az sem áll helyt. Az, amit bepakolnak egy exe-be, még nem lesz natív kód. Ha így lenne, minden kód ami végrehajtás alá kerül vagy kerülhet, natív kód lenne. De ez nincs így.

Natív kódnak azt lehet nevezni, amit nem egy VM hajt végre, vagy egy sorértelmező interpreter, hanem a gép processzora, módosítás nélkül.

Az, hogy egy változó tipusa megváltozhat, nem tesz semmit. Szinte minden ma népszerű nyelvben létezik variant. A tipusvizsgálathoz, konverzióhoz szükséges kód bekerül, belefordítódik a futtatható állományba. Ahogy belekerül a Garbage collector is, miegyéb is, aztán ha szükség van rá, akkor meghívódik.

Ugyanez igaz az osztályok példányosítására, a futásidőben létrehozott objektumokra, egyebekre.

Amúgy ezt a vitát rövidre lehetne zárni annyival, ha az emberek vennék a fáradtságot és utánajárnának, hogy mi az a compiler meg az interpreter. De hogy megspóroljam a kérdezőnek meg a többi lustának az időt:

* A compiler egyik nyelvről egy másikra fordít. Jellemzően egy magasabb szintű nyelvről egy alacsonyabbra.

* Az interpreter elolvas egy valamilyen nyelven írt programot és végrehajtja.

Nem, nem csak az a compiler, ami valamilyen fizikai processzort targetel (a `javac` nevü programot nem véletlenül hívják java compilernek) és igen, a cpython tud compilerként viselkedni, hisz python kódot olvas és python bytekódot ír.

Fun fact: a processzor egy interpreter a gépi kódhoz.

Igen, mind értettük, hogy mire kíváncsi a kérdező. A kérdést így kellett volna helyesen feltennie: "Miért nincs a pythonhoz olyan compiler, ami valamilyen fizikai processzor natív utasításkészletére fordít?"

Erre meg az a válasz, hogy ezt csak úgy lehet megoldani, hogyha a python interpretert is az exe részévé teszed. Ennek az egyik oka pl az `eval` nevű függvény, ami tetszőleges, akár futásidőben létrejövő python programot végrehajt.