JavaScript helyett Julia-ban és Python-ban is lehet majd írni a böngészős kódokat

JavaScript helyett Julia-ban és Python-ban is lehet majd írni a böngészős kódokat
2019-07-08T08:01:59+02:00
2019-07-15T15:31:41+02:00
2022-10-18T07:20:38+02:00
  • Ertem az erveidet, es el is fogadom, hogy ez lehet vele problema. En pedig kimondottan ezert szeretem, ugyanis teljesen jol debuggolhato, es ES6al mar szerintem teljesen felesleges a szigorubb tipuskezeles. Eleg nagy monolit AngularJSes kodban tok jol mukodik annak ellenere, hogy legalabb 10-20 fo fejlesztette napi szinten. Azert nem az Angulart hoztam fel, mert ott mar legtobben valtottak ES6rol TS-re, ami azert az egy dologert szimpatikus, mert konnyebb ravenni az OOP vilagbol erkezo fejlesztoket a hasznalatara, mint a JS fejlszestesre.
    A szoszatyarsag nekem nem okoz gondot, mert egy mai jo IDEvel szinte a fele kodot kell beirni, illetve en igy szoktam meg, es emiatt nekem jol olvashato.
    Tudom, ezek teljesen szubjektiv velemenyek, de jo olvasni a masik oldalrol is velemenyt.
    Egy biztos, en ameddig tudok, maradok az ES6 mellett, mert szeretem a rugalmassagat nagyon a nyelvnek.
    Mutasd a teljes hozzászólást!
  • Szerintem a js programnyelvnek a dinamikus típuskezelése miatt nem jó. Amíg csak pár soros scripteket csinálsz vele addig nem gáz, de ha kliens oldalra teszed a logikád egy részét mint egy komplerxebb angularos appnál, vagy esetleg a szerver oldali logikát is ebben akarod megcsinálni, akkor már szerencsésebb a szigorúbb típuskezelés. A typescript ezt ugyan megoldja, csak picit gány megoldásnak tartom a transpilereket, annál is inkább mert így a statikus típuskezelés előnyeit a fordító már nem tudja használni.

    Scriptnyelvnek viszont szerinte picit szószátyár, erre szerintem a python jobb.
    Mutasd a teljes hozzászólást!
  • én továbbra sem értem, hogy mi a probléma a JS nyelvvel a böngészőkben. tény, hogy más gondolkodás módot követel meg, de rugalmas és jól fejlődik. Inkább egy natív ES6 támogatásra lenne szükség szerintem, és sok jelenlegi probléma megoldódna.
    Nem igazán látom, hogy DOM manipulációra miért kellene ennél jobb nyelv
    Mutasd a teljes hozzászólást!
  • Mondjuk azért jó hír, hogy legalább az értékeknek van típusuk.

    Van egyáltalán olyan nyelv, ahol az értékeknek nincs típusuk? Olyan nyelv még lehet, ami csak egyfajta adattípust tud kezelni, de hogy nézne ki egy típus nélküli nyelv?

    Talán még az assembly áll a legközelebb egy típusmentes nyelvhez, mert ott általában csak egy regisztert vagy címet adsz meg operandusnak, és a műveletbe van "belekódolva", hogy azt a halom bitet hogy is kell értelmezni. Ha egész műveletet hajtok végre egy memóriacím tartalmán, akkor egész számként értelmezi, de aztán semmi nem tart vissza, hogy ugyanazon a memóriacímen következőnek már egy lebegőpontos műveletet hajtsak végre, ami teljesen másképp értelmezi ugyanazokat a biteket.

    akkor ezek szerint mégsem teljesen erősen típusos a Python, hanem valahol félúton van.

    Már leírtam, miért nem látom értelmét erős és gyenge típusosságról beszélni, azt most nem ismételném meg
    Mutasd a teljes hozzászólást!
  • Teljesen félrevezető dolog Pythonban, vagy bármi más dinamikus típuskezelésű nyelvben a változók típusáról beszélni.

    Látom, igen... akkor ezek szerint mégsem teljesen erősen típusos a Python, hanem valahol félúton van. (Mondjuk azért jó hír, hogy legalább az értékeknek van típusuk.)
    Mutasd a teljes hozzászólást!
  • A változóknak értékük van, és az értékeknek van típusa.
    Változó nélkül is működik a

    print(type(5)) print(type("hello"))
    és ugyanazt írja ki, mint változóval, így pont nem utal arra, hogy a "változóságnak" lenne szerepe.

    (Ja, ezt kicsit régebben kezdtem írni, csak próbáltam közben párhuzamos példát kigondolni más nyelvben, majd feladtam)
    Mutasd a teljes hozzászólást!
  • De pont ezért dinamikus típuskezelésű, mivel a változó futásidőben kapja meg van változtatja a típusát (nem?).

    Teljesen félrevezető dolog Pythonban, vagy bármi más dinamikus típuskezelésű nyelvben a változók típusáról beszélni. A változó értékének van típusa, és a type() is ezt adja vissza. Ezért is működik változó nélkül is, például ez:

    print(type("hi"))
    ugyanúgy kiírja, hogy "<class 'str'>".
    Mutasd a teljes hozzászólást!
  • OK, igazán nem izgat. :)

    Rendben, akkor ennyiben maradtunk.
    Mutasd a teljes hozzászólást!
  • Azért ez nem egészen így van, mivel az

    a = 5 print(type(a)) a = "hello" print(type(a))
    ... kidobja, hogy "<class 'int'>", "<class 'str'>". Ez nem automatikus típuskonverzió egyébként. De pont ezért dinamikus típuskezelésű, mivel a változó futásidőben kapja meg van változtatja a típusát (nem?).
    Mutasd a teljes hozzászólást!
  • OK, igazán nem izgat. :)

    Az erősen és statikusan típusos nyelvek az általános programnyelvek, amelyek nagy-komoly rendszerek vagy könyvtárak írására alkalmasak.
    Minden ami nem ilyen, az speciális, egyedi igényekhez kitalált célnyelv, egy szűk terület célszerű lefedésére.

    Ha ezen túlterjeszkedik (legjobb példa a JS, amit oldalanként pár tucat programsorra találtak ki, összescriptelni az események hatását), onnan csak a baj gyűlik és lehet takarítani a felhalmozódott fek-a-liát.
    Mutasd a teljes hozzászólást!
  • Erős típusosság = a változóknak van típusúk, akkor is, ha azt az interpreter automatikusan állapítja meg (type inference). A Python erősen típusos nyelv.

    Önmagadnak mondasz ellent.
    Az
    a=5 a="Hello"
    teljesen szabályos Python kód. Az 5-nek meg a "Hello"-nak van típusa, nem az a-nak.
    Szerintem az automatikus típuskonverzió szintje az, amire gondolsz (pl. a Python panaszkodik, ha számot adsz össze stringgel, és még a sorrendjük is számít, mert más lesz a kifogás).
    Mutasd a teljes hozzászólást!
  • Jól van, te nagyon örülsz a statikus típuskezelésnek, egészségedre. Ettől még érdemes egzakt kifejezéseket használni, az erős/gyenge pedig nem túl egzakt, ha típuskezelésről beszélünk. Van, aki a dinamikus típuskezelést érti alatta, mások szerint az implicit konverzióktól lesz gyenge a típuskezelés, és biztos vannak olyanok is, akik simán úgy gondolkodnak, hogy "nem úgy működik, ahogy a kedvenc nyelvemben van, szóval gyenge"...
    Mutasd a teljes hozzászólást!
  • Erős típusosság = a változóknak van típusúk, akkor is, ha azt az interpreter automatikusan állapítja meg (type inference). A Python erősen típusos nyelv. (Gyenge típusos nyelvek azt hiszem a JavaScript és a PHP 5.x-ig.)

    Az erős-gyenge típusosság mellett van a dinamikus-statikus típusosság. A dinamikusnál az interpreter futásidőben állapítja meg a változó típusát (illetve dob hátast), a statikusnál előre közölni kell a fordítóval (és már a fejlesztőeszközben hátast dob).

    A Python erősen-dinamikusan típusos nyelv.

    A Julia lényege viszont pont az, hogy egyrészt compilere van (nem interpretere), csak az a program indulásakor fordítja le forráskódra a kódot; másrészt viszont opcionálisan statikusan típusos nyelv, azaz megadhatod neki a típusokat előre és pont ezért tud a fordító optimalizálni.

    Az egyetlen dolog, hogy azt hiszem a Julia jelenleg nem tud előre fordítani, de ennek egyébként nincs technikai akadálya. Szóval a Julia nem scriptnyelv, csak scriptnyelv-szerű, de csak messziről nézve.
    Mutasd a teljes hozzászólást!
  • Az "erős típusosság" nem duma, hanem programminőségi kritérium nálam.
    Ugyanis ha egy függvény paraméterére van valami típus megkötésem, akkor mindenféle extra if kódok, hintek, assume() stb nélkül tudom, hogy az a típus jött a függvénybe.
    Ez bármilyen "programhelyesség bizonyításnál" (beleértve egészen a manuális tesztig) egy kritérium.
    És ez elvezet odáig, hogy új típust használsz, ami darabszám és csak egy intet tartalmaz, de inkább új típus, mert nem elég hogy nem stringet ad át neked valaki, de még az sem elég, ha valami más jelentésű intet. [*]
    Mert ez így egzakt!
    Nekem meg a programozás egyik kritériuma az egzakt kód!!
    És persze van amikor fel kell lazítani dinamikusság felé (pl. ismeretlen ill. aluldokumentált json/xml használata, ami már eleve egy biztonsági rés, [ha nem lehet egyértelműen serializálni/deserielizálni típusos óobjektumba], de hagyjuk), de ezek maximum a kivételes eljárás esetek lehetnek és külön réteget kell hogy nálam képezzenek, aminek a többi réteghez az interface már megintcsak erősen típusos.

    [*] és itt jön be a null, ami kis rést üt azon, hogy ne is kelljen ellenőrizni (ugye a billion dollar mistake), de pl. a C# ezen a területen is lép, a belengetett non nullable types elég erős húzás :)
    Mutasd a teljes hozzászólást!
  • Nem tudom mi a hivatalos megnevezése

    Dinamikus típuskezelés. Nem a változóknak van típusa, hanem az értékeknek, amikre a változók mutatnak.

    Ez az "erős típusosság"/"gyenge típusosság" megkülönböztetés így értelmetlen, illetve max. arra jó, hogy valamivel le tudd szólni azt a nyelvet, ami nem tetszik. Értelme arról lenne beszélni, hogy egy nyelvben statikus vagy dinamikus a típuskezelés, illetve hogy mennyire hajlamos implicit konverziókra.
    Mutasd a teljes hozzászólást!
  • Nem tudom mi a hivatalos megnevezése, @Sydra kolléga szerintem az ilyesmire gondolt:

    i = 42 # data type is implicitly set to integer i = 42 + 0.11 # data type is changed to float i = "forty" # and now it will be a string
    Ezt ha otvozzuk az értelmezovel, konnyu belátni, hogy amit kapunk az annyira erosen típusos, mint a hetes bakakaka.
    Mutasd a teljes hozzászólást!
  • "Ragasztó" alatt különféle natív kódú, vagy azzal támogatott könyvtárak összekötögetését értem. Ez az, ami böngészőben a pluginek kihalásával szimplán nincs, wasm szinten meg szintén nem nyilvánvaló. Pl. mert nincs dinamikus linkelés, szóval a Python interpreterrel egybe kell majd fordítani minden használni kívánt "natív" könyvtárat, illetve jelenleg több natív nyelv keverése esetén ez nem is mindig működik.
    Szóval eléggé jövőbemutató ez a projekt, és nem feltétlenül jó értelemben.
    Mutasd a teljes hozzászólást!
  • A Python-t ezen felül meg ragasztónak használják, csakhogy böngészőben nincs mit ragasztani.

    Ha nem lenne, akkor javascript sem lenne. Persze a js-ben is írnak hosszabb kódokat is, ahogy pythonban is, lásd django és vidéke. Viszont scriptnyelvnek szvsz a python sokkal jobb mint a js mert tömörebb, ráadásul legalább type hints van benne.

    Igazából szerintem az ideális az lenne, ha a böngészőkbõl alapból teljesen eltűnne a javascript, csak wasm lenne benne (esetleg picit bővítve dinamikus irányba, illetve kaphatna egy opcionális GC-t), a javascript, python, julia, stb. interpretereket pedig röptében töltené le, majd szépen elcachelné mint minden mást. Innentől kezdve nem lenne gond az sem, hogy a böngésződ épp nem támogatja a legutolsó js verziót, ráadásul a különféle nyelvek azonos eséllyel indulnának, és megszûnnek a js priorizált szerepe.
    Mutasd a teljes hozzászólást!
  • megírhatom a kódomat egy másik gyengén típusos, dinamikus, rosszul skálázódó nyelvben

    Mindkét nyelv erősen típusos, a Python is. A Julia ezen kívül statikusan típusos is (ez konkrétan a nyelv lényege). Dinamikus alatt nem tudom, mit értesz, de a Julia nem interpretált, hanem előre fordított nyelv, amely nem skálázódik rosszul. Az egyik legjobb nyelv manapság (a Julia).
    Mutasd a teljes hozzászólást!
  • Ja a Blazor jó lesz. Csak oldják meg, hogy ne 3 mega legyen az oldal! Meg a C# is erősíthetne kicsit static, const, compile time dolgok terén!
    Mutasd a teljes hozzászólást!
  • A WASM önmagában jó irány, de nem ilyenekre kellene használni!

    Valóban! Komoly nyelvhez :)
    Pl. a Blazor, az jó irány :)

    De gondolom a Julia-t sem a scriptek kiváltására kívánják bevetni, hanem valami háttér intelligenciára :)
    Mutasd a teljes hozzászólást!
  • Ezjo csak ez mar hanadiky szint?

    Ennél is rosszabb a helyzet.

    1. hardver
    2. mikrokód
    (virtualizáció, ha van)
    3. oprendszer (folyamatok, fájlrendszer, IPC, hálózat, stb.) 
    4. oprendszer grafikus rétege
    5. böngésző
    6. wasm
    7. wasm-ban írt interpreter/compiler
    8. Python/Julia/stb...

    De ha elkezdenénk rétegeket összevonni, attól legalább annyian fáznának, mint a mostani túlburjánzástól. A hardveren többféle oprendszert akarunk, az oprendszeren többféle grafikus shellt, abban többféle böngészőt, és abban többféle nyelven webalkalmazást fejleszteni.
    Mutasd a teljes hozzászólást!
  • De jó! Akkor mostantól az egyik gyengén típusos, dinamikus, rosszul skálázódó nyelv helyett megírhatom a kódomat egy másik gyengén típusos, dinamikus, rosszul skálázódó nyelvben is és még külön interpretert is szállítanom kell hozzá!
    Most, hogy már 2019-ben lassan mindenki mindent a weben csinál, elkezdhetnénk a webfejlesztést komolyan venni a szkriptekkel való bohóckodás helyett! A WASM önmagában jó irány, de nem ilyenekre kellene használni!
    Mutasd a teljes hozzászólást!
  • JavaScript helyett Julia-ban és Python-ban is lehet majd írni a böngészős kódokat

    Csak minek? Kutatásban mindkettőt számgyúrásra használják, a böngésző meg nem fogja kiváltani a végtelen memóriájú 1000 magos clustert. A Python-t ezen felül meg ragasztónak használják, csakhogy böngészőben nincs mit ragasztani.
    Mutasd a teljes hozzászólást!
  • Nem, mert az interpreter is generálhat WA kódot, ami szintén natív kóddá fordul végül a JIT révén mielőtt ténylegesen végrehajtásra kerül. Tehát ideális helyzetben végül éppen olyan, az adott processzorplatformon natív kód futhat majd, mint akármelyik előre fordított alkalmazás esetében. Logikai réteg meg ennél sokkal több van, ráadásul egy bármilyen előfordított natív alkalmazás esetében is.
    Mutasd a teljes hozzászólást!
  • Ezjo csak ez mar hanadiky szint?
    1 hardver
    2 mikrokod
    3 bongeszo wasm motor
    4 wasmos python interpreter
    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