Még jó ideig velünk fog maradni a JavaScript
2012-03-16T01:31:17+01:00
2012-03-17T09:18:45+01:00
2022-07-24T04:47:20+02:00
  • "A language is typed if the specification of every operation defines types of data to which the operation is applicable, with the implication that it is not applicable to other types. For example, the data represented by "this text between the quotes" is a string. In most programming languages, dividing a number by a string has no meaning. Most modern programming languages will therefore reject any program attempting to perform such an operation. In some languages, the meaningless operation will be detected when the program is compiled ("static" type checking), and rejected by the compiler, while in others, it will be detected when the program is run ("dynamic" type checking), resulting in a runtime exception.

    In contrast, an untyped, such as most assembly languages, allows any operation to be performed on any data, which are generally considered to be sequences of bits of various lengths. High-level languages which are untyped include BCPL and some varieties of Forth.

    In practice, while few languages are considered typed from the point of view of type theory (verifying or rejecting all operations), most modern languages offer a degree of typing."

    (forrás)

    Azt hiszem ez megválaszolta mindkét kérdésed.
    Mutasd a teljes hozzászólást!
  • Te már találkoztál olyan nyelvvel, ahol semmilyen típuskezelés nincs a Te definíciód alapján? Egyébként ezt sting találta ki, vagy egy általános szakmai körökben elfogadott definíció?
    Mutasd a teljes hozzászólást!
  • A C++ STL ... se lenne pici ha a nulláról kellene megtervezned és a két kezeddel kellene begépelned

    Ez éppen nem jó példa, mert pont, hogy C++ nál szokott az ember mindent saját kézzel megírni kezdve a String osztálytól a tárolókig mindent, nem mintha az STL olyan hú de sok mindenre alkalmas lenne önmagában. (akkor már inkább a boost, vagy újabban a WinRT, amiket viszont szintén nem lehet minden platformon használni, tehát speciális eseteket leszámítva szintén irreleváns a használatuk)

    De egyébként is, ha a script nyelveket magában nem használnak semmi komolyra, mint, ahogy állítottad, akkor nincs is igazán szükség bizonyítgatni azt, hogy mennyire használható, vagy sem bármire is, hiszen az össz kódot tekintve elhanyagolhatónak tekinthető.
    Mutasd a teljes hozzászólást!
  • Mondjuk úgy hogy az átlag webfejlesztő nem készít nagyméretű kódot. Azért mondjuk a jquery se és a jquery ui sem pici, ha neked a két kezeddel kellene legépelned. És ha még meg is kellene tervezned a nulláról, akkor meg aztán tényleg nem pici.

    A C++ STL vagy MFC, a Delphi VCL, a .NET CLR és a Java J2SE se lenne pici ha a nulláról kellene megtervezned és a két kezeddel kellene begépelned - mégse kezdi el senki osztani az észt, hogy C++-ban, C#-ban meg Java-ban nem írunk nagyméretű kódokat, mert hogy körülményes és nehéz programozni őket. Sőt, pont ezek az amúgy valóban nehezen megírható és bonyolult architektúrájú alapkönyvtárak azok amik egyszerűvé teszik az adott platformok programozását. A magasabb szintű, még több kódot tömörítő és még összetettebb rétegekről és keretrendszerekről nem is beszélve.

    Hasonló módon az, hogy a jQuery vagy a Prototype mennyire bonyolult és hányfajta - esetleg ronda - trükköt alkalmaz teljesen lényegtelen a JavaScript-ben dolgozó alkalmazásfejlesztő számára, mert ő ebből semmit sem lát és a munkáját sem befolyásolja. Ő már egy a baseline JavaScript interpreterhez képest magasszintű, egységes absztrakciós réteggel dolgozik - pontosan úgy, ahogy teszi azt egy C++-ban, C#-ban, Delphi-ben vagy Java-ban dolgozó fejlesztő is, aki programja kódjának >95%-át nem a ténylegesen általa írt, hanem a platform által biztosított infrastruktúra kódja adják.

    Ugyanez mondható el egyébként PHP-ről, Perl-ről és szinten minden más dinamikus nyelvről is, amiket ugyancsak jellemzően nem az elemi nyelvi elemek szintjén, hanem valamilyen átfogó keretrendszerre építve szokás programozni.

    A típusosságban viszont nem értem az érvelésed. Ha összeakarsz adni egy "1.1" + 1-et, akkor kapsz egy 1.11-et amiről még továbbra sincs fogalmam hogy szám vagy sztring

    Már hogy ne lenne? Az egy sztring, és azért 1.11 lett az eredmény, mert - a nyelv szabályai értelmében - sztringgé lett "kiterjesztve" a második operandus.

    alert(typeof ('1.1'+1)); // 'string' alert('1.1'+1+1); // '1.111'

    Szerintem te abszolút nem érted miről szól a dinamikus típuskezelés. Mint már milliószór elmondtam, ez a fogalom nem azt jelenti, hogy a kifejezéseknek nincs típusa vagy hogy az ne lenne egyértelmű és megállapítható a program minden egyes pillanatában, és a műveletek eredményeinek típusa ne következne az operandusok típusából és a műveletből magából - hanem csakis azt, hogy a változók típusa nem rögzített a program létrehozásának pillanatában, egymást követő végrehajtási menetekben a programkód ugyanolyan pontján akár eltérő is lehet, ill. hogy ezzel összefüggésen a belőlük képzett kifejezések típusáról is elmondható ez. De ettől még mindig pontosan lehet tudni, hogy adott típusú kifejezéseken egy adott operátor pontosan milyen műveletet végez ill. hogy az eredmény típusa mi lesz. És ha szükséges, akkor ez a típus ellenőrizhető és kikényszeríthető is.

    A példádnak egyébként is nagyjából semmi köze a dinamikus működéshez, hanem az operátor-egyértelműség/-sokrétűség problémáját veti fel. Ha ugyanis egy nyelvben értelmezett sztring és szám között az összeadásjel, és ha az úgy működik, hogy konkatenációt végez a két adott típusú operandusok között, akkor az ha fordított nyelv, akkor is "1.11"-et fog szolgáltatni eredményként az "1.1" + 1 kifejezés értékére. Ami lehet, hogy nem az amit várnál, de a nyelv szabályai szerint teljesen helyes működés. Tehát a példád kapcsán maximum arról lehet vitatkozni, hogy szerencsés -e, hogy 1. sztring és egész között értelmezett az "+" operátor, 2. hogy ez adott esetben konkatenációt végez, 3. hogy a sztring-konkatenáció és az aritmetikai összeadás operátora ugyanaz az adott nyelvben.

    A JavaScript-nél egyébként ebből a szempontból pl. előnyösebb a PHP, ahol direkt azért tér el az aritmetikai összeadás és a konkatenáció operátora, hogy sokkal nehezebb legyen olyan kódot írni, amely esetében ránézésére nem teljesen egyértelmű, hogy mi lesz az eredménykifejezés típusa. Ráadásul ott nincs meg az a baj sem, hogy a type juggling szinte mindenből képes sztringet csinálni - mint JavaScript-nél, ahol a két probléma halmozatának köszönhetően akár objektumok összeadása is értelmezett és végrehajtható művelet lehet (ami azonban pl. PHP-ben, a másik dinamikus mintanyelvben nem az, és így nem okozhat ilyen problémákat; bár JavaScript-ben is kivédhető az alapértelmezett toString() metódus felülírásával).

    Ugyanakkor a legrosszabbnak ilyen szempontból azok a nyelvek számítanak, amelyek megengedik és jellemzően intenzíven alkalmazzák is az operátortúltöltést - élükön a C++-szal, ami egy fordított, statikus nyelv, mégis simán elmondható róla, hogy ránézésre nem állapítható meg biztosan benne egy-egy kifejezés típusa, vagy hogy ténylegesen milyen műveletet is jelent és végez majd egy adott, amúgy egyértelműnek tűnő elemi operátor (pl. +, -, *, stb). De operátortúltöltés nélkül is ott van például még a pointer-aritmetika, ami a teljesen statikus C/C++-ban pont hogy ugyanígy formálisan megengedi egy egész hozzáadását egy sztringhez - és az eredmény marhára nem az lesz, amit úgymond várnál. Amit ha nem tárolsz, hanem pl. magát is egy másik kifejezésben használod fel, egy if feltételébe raksz, vagy több különböző típusú paraméter fogadására is képes túltöltött függvény vagy metódus paramétereként használod fel, akkor még az eredménytípus esetleges inkompatibilitása révén se lesz esélyed észrevenni, hogy nem egészen azt csinálja ténylegesen a programod amit úgymond ránézés alapján tűnik, hogy csinál.

    Szóval ahhoz, hogy ránézésre jónak tűnő, szemantikailag viszont helytelen kódot írhassál, nincs szükséged dinamikus nyelvre. A másik oldalon ugyanakkor dinamikus nyelvek esetében is jellemzően van típuskényszerítési/típusbújtatási lehetőség, amikkel ha és ahol szükséges, akkor és ott még mindig elérheted, hogy ellenőrzésre kerüljön egy-egy változó vagy kifejezés eredményének megfelelősége egy adott típusnak ill. akár automatikus átalakításra is arra, ha szükséges - miközben a program maradék részében (ahol és amíg nem érdekes az adott kifejezés típusa) kihasználhatod azt a kényelmet, gyorsaságot, rövidséget és rugalmasságot, amit a dinamikus megközelítés tesz lehetővé számodra szemben a statikus típuskezeléssel.
    Mutasd a teljes hozzászólást!
  • Van jó pár dolog, ami kisebb kódoknál is tud kellemetlenségeket okozni.

    Wat - Destroy All Software Talks

    Persze ha megszokta a Javascript saját hülyeségeit az ember utána sokat nem jelentenek ezek, de azért valahol szomorú, hogy egy pár nap alatt "megtervezett" nyelv lett a web megdönthetetlennek tűnő, univerzális nyelve.

    Azért szorítani még szabad a native clientnek, ha nincsenek is túl jó kilátásai
    Mutasd a teljes hozzászólást!
  • Mondjuk úgy hogy az átlag webfejlesztő nem készít nagyméretű kódot. Azért mondjuk a jquery se és a jquery ui sem pici, ha neked a két kezeddel kellene legépelned. És ha még meg is kellene tervezned a nulláról, akkor meg aztán tényleg nem pici. És ez ügye csak a jéghegy csúcsa, mert van még egy pár plugin amin valakik nagyon sokat agyaltak (pl. én a jstree, carousel, hotkeys, maskedInput, example, form, rating, cookie pluginokat használom szinte minden projektemben).
    De nem gondolnám hogy az OO javascript nem létezik. Abba is hagynám a szakmát, ha mondjuk egy jquery datepicker átírása azt jelentené hogy írjam meg elölről.
    A típusosságban viszont nem értem az érvelésed. Ha összeakarsz adni egy "1.1" + 1-et, akkor kapsz egy 1.11-et, amiről még továbbra sincs fogalmam hogy szám vagy sztring. És ez bizony se futásidőben se előbb se később semmilyen hibát nem dob, nem kérdez, csak csinálja. Ami baj, de mivel egy script nyelvről van szó, jobb hogy nem típusos.

    Mutasd a teljes hozzászólást!
  • Ebbe a témakörbe tartozik a server side V8-as engint használó megoldások, mint a Node.js vagy a Skill.js ?
    Ezekkel van valakinek konrét tapasztalata?
    Mutasd a teljes hozzászólást!
  • Talán ha definiálnánk, hogy mi is a "nagyméretű feladat", akkor könyebben lehetne vitatkozni azon, hogy mire alkalmas, és mire nem a js.

    A dolog ott kezdődik, hogy a JavaScript-et elég ritkán, ill. gyakorlatilag soha nem használják önmagában egy projekt megvalósítására (amihez meg igen, az egészen biztosan elég kicsi dolog). Hanem vagy eleve automatikusan generálódik magasabb szintű absztrakciót, objektummodellt, stb. megvalósító nyelvek, platformok és keretrendszerekből (pl. PHP-s frameworkök, GWT, ASP.NET, stb.) a HTML markuppal együtt és azzal összefüggésben, vagy ha úgymond kézzel is szerkeszti össze egy részét az ember, akkor is a JavaScript kódok igen kis részét teszik csak ki a teljes megvalósítandó feladatnak, amelynek legnagyobb részét megint csak egy másik nyelven, szerveroldalra kódolja le az ember. (Urambocsá esetleg LLVM-mel és Emscriptennel akár teljesen "kliensoldali", akár C++, C#, Object Pascal nyelven megírt kódokból generáltatja le.)

    Ezért teljesen teljesen irreleváns, hogy pl. a JavaScript maga mennyire hiányos és kiforratlan OOP-pal rendelkezik, mert közvetlenül alig kódolunk benne, és mert ha mégis ezt tesszük, akkor csak rendkívül egyszerű dolgokat kell benne összeütni, amire bőven elég az a kevés is, amit tud. Ebben az értelemben óriásprojektekben is fel lehet használni, mert nem igazán lesz kerékkötője a dolgoknak a korlátossága, és nem fogja veszélyeztetni a kód menedzselhetőségét sem, a fenti okokból kifolyólag.
    Mutasd a teljes hozzászólást!
  • Vagyis, ha egy típuson nem értelmezett az operator+, akkor futási időben dob egy exception-t a futtatórendszer, míg statikus típuskezelés esetében már az editor kiírja a hibát gépelési időben. Miért jobb az előbbi

    Ki mondta, hogy jobb az előbbi?

    és miért vezet megmagyarázhatatlan működéshez az utóbbi

    Ki mondta, hogy megmagyarázhatalan működéshez vezet az utóbbi?
    Mutasd a teljes hozzászólást!
  • Ha a progi kivételt dob, akkor az end-user szól a programozónak, az kijavítja. Nem mondom hogy mindenki boldog, de a dolog annyi. Ha a dinamikus típuskezelés elnyeli a hibát, akkor látszólag mindenki boldog, aztán fél év múlva jön az end-júzer hogy hülyeségeket számol a program.

    De a dinamikus kezelés nem nyel el semmifajta hibát. Egyszerűen ha megfelelők az operandusok, akkor elvégzi a műveletet, ha pedig nem, akkor nem - és kész.

    Ez ugyanígy működik statikus típuskezelés esetén is. Ha összeadás helyett kivonást írsz valahova a kódba, akkor simán le fog fordulni a programot, sőt, le is fog futni, csak éppen teljesen tévesen fogja az adatokat feldolgozni - kvázi a te értelmezésedben "elnyeli a hibát".

    És amikor a felhasználó fél év múlva észreveszi, hogy a statikus típuskezelésű nyelvben írodott programod hülyeséget csinált, hajszál pontosan ugyanannyira nem lesz boldog, mint ha a dinamikus típuskezelésű eszközzel készült programod csinálta volna ugyanezt.

    Nem véletlen, hogy már milliószor elmondtam, hogy önmagában az, hogy lefordul a programod, semmilyen mértékben nem garantálja sem annak helyes működését - sem annak elmondását nem teszi lehetővé, hogy az adott program ha nem is tökéletesen, de legalább valamivel jobban és helyesebben fogja feldolgozni az adatokat, mint egy akármilyen nem-fordított, hanem dinamikusan futó program. Mert ez egyszerűen nem következik a fordítás tényéből.

    A helyes működést csak más módokon lehet elvégezni ellenőrizni ill. biztosítani (ti. teszteléssel), amely lépés után viszont azonos alaposság mellett legalább annyira bizontságosan fogja feldolgozni az adatokat egy dinamikus, mint egy statikus program is.
    Mutasd a teljes hozzászólást!
  • Ha a progi kivételt dob, akkor az end-user szól a programozónak, az kijavítja. Nem mondom hogy mindenki boldog, de a dolog annyi. Ha a dinamikus típuskezelés elnyeli a hibát, akkor látszólag mindenki boldog, aztán fél év múlva jön az end-júzer hogy hülyeségeket számol a program. És kiderül, hogy a közben 4 ember átal felvitt adatok fele rossz... Na, ekkor _határozottan nem lesz boldog az end-júzer. Persze tudom: a unit teszteléssel ki lehet védeni bármit. Kérdés, hogy a projektek hány százalékánál van 100%-os lefedettségű unit teszt + teljes funkcionális teszt. Különösen a dinamikus nyelvek házatáján.
    Mutasd a teljes hozzászólást!
  • Az utóbbi akkor vezet megmagyarázhatatlan működéshez, ha:

    1) Az általad használt nyelvben a típusok nem mindig tartalmaznak elég információt, hogy a biztonságról fordítási időben meg lehessen győződni. (Pl. a C-ben a char* nem tárol infót róla, hogy mekkora pufferre mutat, így egy strcpy tud érvénytelen memóriahozzáférést csinálni, ami se fordításkor, se futáskor nem ellenőrződik.)

    2) Valahol szerepel a kódban egy típuskényszerítés, reinterpret_cast stílusban. Ha az adott bitek nem felelnek meg teljesen az új típus korlátainak, akkor nem definiált működést kaphatsz.

    Sting, ha jól értem, arra mutat rá, hogy ezek nem fordulnak elő dinamikus nyelvekben, mivel az értéktől elválaszthatatlan a típusa, és nem lehet kézzel felülbírálni. (Magyarán nincs reinterpret_cast dinamikus nyelvben.) A dolog hátránya, hogy a folytonos ellenőrzés lassabb, illetve nehezebb érvelni egy kód helyességéről, ha még az sem biztos, melyik változó milyen típusú értéket tárol.

    A középút az, amit a managed nyelvek csinálnak, hogy a típusellenőrzés egy részét fordításkor végzik, de ami akkor nem végezhető el, azt elhalasztják futásidőre. Javában vagy unsafe nélküli .NET-ben sincs puffertúlcsordulás vagy memóriafelülírás, illetve csak annyira, mint amennyire mondjuk egy JS motorban is lehet (vagyis a natív részben).
    Mutasd a teljes hozzászólást!
  • Ez kizárja, hogy olyan művelet kerüljön végrehajtásra egy adaton ami definíció szerint kizárt rajta

    Vagyis, ha egy típuson nem értelmezett az operator+, akkor futási időben dob egy exception-t a futtatórendszer, míg statikus típuskezelés esetében már az editor kiírja a hibát gépelési időben. Miért jobb az előbbi és miért vezet megmagyarázhatatlan működéshez az utóbbi, ami gyakorlatilag le sem fordítható? (még mielőtt megmagyaráznád, egy másik példát hoztam fel az állításodra)

    vivo: Vállalat irányítási rendszer.
    Mutasd a teljes hozzászólást!
  • Talán ha definiálnánk, hogy mi is a "nagyméretű feladat", akkor könyebben lehetne vitatkozni azon, hogy mire alkalmas, és mire nem a js.
    Mutasd a teljes hozzászólást!
  • Ezt olvasd végig: w3net.eu - Portail d'informations Ce site est en vente!
    Aztán el lehet kezdeni vitatkozni azon hogy mit tud és mi az amit nem tud és mi az amit "bohockodás"-nak hívhatunk. Persze ez utóbbi szubjektív lesz és nem objektív.
    Egyébként a PHP-hoz is szinte mindenhol OOP fejlesztőket keresnek mostanában és nem gondolom hogy a fenti oldalon leírt polimorfizmus definíciójának megfelelne. Attól még hogy egy nyelv néhány OOP paradigmát nem támogat, vagy nem a megszokott módon kell deklarálnod, még OO nyelvnek tekinthető.
    Mutasd a teljes hozzászólást!
  • Nem látom, hogy lenne egységbezárás

    Szerintem te nem az egységbezárásra, hanem az adatrejtésre gondolsz. Legalábbis az nem kérdéses, hogy egységbezárás van - de closure-okkal az adatrejtés is simán megoldható. Bár igazából abszolút nem volt szükségem rá és nem éreztem hiányát böngészős környezetben az elmúlt egy évtizedben. Ott egyszerűen nem írunk olyan dolgokat JavaScript-ben, ahol ennek jelentősége lenne.

    a prototípus alakú bohóckodást nem nevezném normális öröklődésnek

    Az igazából mindegy, hogy te minek nevezed. Bár itt megint azt kell mondanom, hog magában a JavaScript-ben nem írunk olyan dolgokat, ahol olyan bonyolult öröklésekre lenne szükség. Amire meg szükség van, arra bőven elég azok a lehetőségek amik JavaScript alatt is adottak.

    meg ugye polimorfizmus se nagyon van

    Dehogynem. A duck-typing a polimorfizmus egyik fajtája.

    De nem baj, ettől még a JS "valóban" OO nyelv.)

    Igazából egy Prototype vagy jQuery mellett abszolút elviselhető a JavaScript OOP-ja azokra a célokra és feladatokra, amikre reálisan felmerülhet, hogy használni kell.
    Mutasd a teljes hozzászólást!
  • Az egyik leginkább OO nyelv.




    (Nem látom, hogy lenne egységbezárás, a prototípus alakú bohóckodást nem nevezném normális öröklődésnek, meg ugye polimorfizmus se nagyon van. De nem baj, ettől még a JS "valóban" OO nyelv.)
    Mutasd a teljes hozzászólást!
  • Már feltéve, hogy valaki csinál ilyen ellenőrzéseket. Ami ugyebár fakultatív.

    Igen, statikus típuskezelés esetén. Dinamikus típuskezelés esetén nem lehet fakultatív, hiszen annak pont az a lényege, hogy a művelet végrehajtásának pillanatában kerül megvizsgálásra egy-egy változó, kifejezés aktuális, pillanatnyi típusa és értéke, és ott dől el, hogy mit is lehet egyáltalán az adott adattal kezdeni - ill. sokszor az is, hogy a műveletvégző operátor végehajtására egyáltalán milyen műveletsort kell indítani (pl. "+" jel lehet összeadás vagy összefűzés is, de nyilván az egészek összeadása is más műveletsort jelent, mint a lebegőpontos vagy vegyes kifejezéseké). Ez kizárja, hogy olyan művelet kerüljön végrehajtásra egy adaton ami definíció szerint kizárt rajta - ami sajnos statikus típuskezelés esetén simán megtörténhet, ezáltal potenciálisan súlyos, észrevétlen adatsérüléseket és megmagyarázhatatlan - a hibát okozó helytől teljesen eltérő ponton jelentkező - programelszállásokat okozva.

    Vagy te láttál már access violatont JavaScript-ben vagy PHP-ben írt kódban, programban? Esetleg puffertúlcsordulást? Mert azért C, Pascal, Delphi, stb. programokban naponta többször is találkozunk ilyenekkel.

    Míg a típus kezelés nem.

    Milyen "típus kezelés"? Nincs olyan, hogy "típus kezelés".
    Mutasd a teljes hozzászólást!
  • Sőt, mivel a dinamikus típuskezelésből következik az elkerülhetetlen futásidejű ellenőrzések garmadája, ezért utóbbi legfeljebb csak a magasabb fokú biztonsággal ill. annak kikényszerítésével hozható összefüggésbe.

    Már feltéve, hogy valaki csinál ilyen ellenőrzéseket. Ami ugyebár fakultatív. Míg a típus kezelés nem.
    Mutasd a teljes hozzászólást!
  • Amúgy minden másban nyilván igazad van...

    Nincs. Hiszen OO nyelvvé sem kell fejlődnie, mert már az. Az egyik leginkább OO nyelv. Még az állítólag nem létező típusok is objektumok. Az hogy mindenki többnyire csak függvényeket gyárt js esetében, az nem a js hibája. Persze aki a class kulcsszót keresi, az nem jó helyen jár.
    Mutasd a teljes hozzászólást!
  • 1. Nem "típusosság" az amit mondani akarsz, hanem legfeljebb "statikus típusosság/típuskezelés". Mert hogy típusosnak már így is típusos a JavaScript.
    2. A statikus típusosságnak semmi köze nincs a biztonsághoz. Attól egy program sem lesz kevésbé biztonságos, hogy dinamikus típuskezelésű. Sőt, mivel a dinamikus típuskezelésből következik az elkerülhetetlen futásidejű ellenőrzések garmadája, ezért utóbbi legfeljebb csak a magasabb fokú biztonsággal ill. annak kikényszerítésével hozható összefüggésbe.
    3. A HTML5-nek sincs semmi köze a JavaScript-hez, mint nyelvhez - ill. kb. annyi van, mint mondjuk az XML-nek a C#-hoz.

    Amúgy minden másban nyilván igazad van...
    Mutasd a teljes hozzászólást!
  • "Még jó ideig velünk fog maradni a JavaScript"


    Ez nem is kérdés, de az már igen, hogy vagy a JS fejlődik a típusos (biztonságos, OO, böngészőhöz tartozó natív keretrendszerrel bővített (pl. html5 féle lépések), vagyis nagy méretű feladatok ellátására alkalmas környezet) vagy konkurens megoldások fognak megjelenni.

    Már csak ilyen a világ
    Mutasd a teljes hozzászólást!
abcd