GorillaScript
Egy újabb javascriptre forduló nyelv, rengeteg beépített lehetőséggel
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Bártházi András:
Perl alapjai VIII. - Könyvtárműveletek
macat:
A NoSQL világa – 1. rész: Bevezető
Hojtsy Gábor:
Két éves a PHPinfo - interjú a készítőkkel
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
Ki használ ilyen
Én egy ideig próbálkoztam
Saját szerény véleményem:
Nem igazán szeretem őket, mert néha teljesen eltérnek a javascript szintaktikától.
Pl.: CoffeScript. Illetve kezdetben egy rémálom volt debug-olni őket.
Arról nem beszélve, hogy további folyamatokat kell beiktatni, mert az élesítés előtt még vissza kell fordítani javascript-re. Illetve ha közösségi dolgokról van szó, akkor nem is mindenki tudja olvasni.
Már előre eltudom képzelni, hogy elkezd terjedni 4-5 felé ilyen elfedő nyelv és egy kisebb arzenállal kell készülni, ha módosítani akar valamit az ember fia. Nem szeretnék ilyen jövőt.
Nem igazán szeretem őket,
Őőő… Én meg nem szeretem a Pythont, mert nem Ruby o.O
Gondolom kezdetben a GCC-t is az lehetett.
A fordított nyelvek már csak ilyenek.
Igazán írhatnád a weblapjaid C-ben, azt sokkal többen tudják olvasni.
Gondolom azt sem tudod elképzelni, hogy a szerveroldalon PHP-n kívül bármi más futhat.
Az idézet első sorából ezt
Igen és ki akar különböző elfedő nyelvekkel a Pythonból Ruby-t csinálni vagy esetleg fordítva?
Van a javascript-nek egy szintaktikája és attól egy teljesen eltérőt akarunk ráhúzni, nehogy még csak hasonlítson is rá.
Nem hiszed el zavar de ez a legkevésbé. Ha a böngészőnek már úgy is el kell készíteni a *.min.js állományokat, de NodeJS-nél irritál.
Ezzel arra kívántam célozni, hogy JS-ben fejlesztek, de projektben használt moduljaim, x. eltérő elfedő nyelven van megírva. Így ha használni akarom őket, illetve hibát vélek felfedezni és a javításukhoz ismernem kell minden elfedő nyelv szintaktikáját.
A hasonlatoddal élve, igazad van C-ben ha programozó gondolom akkor zavar a sok Ruby, meg PHP kód a C-s lib-ek kódja között? Mert itt a JS-nél már lassan ez a helyzet. Az előbbinél meg nem nagyon áll fenn.
Erre csak annyit tudok írni, hogy: puff.
Szerver oldalon, saját szerveremen nálam pont csak az NEM fut. :D
Van a javascript-nek egy
Azért más a szintaktikája, mert másik nyelv. Tekintsünk el attól, hogy éppen JavaScript-re fordul. A C meg az Pascal pedig gépikódra fordul, és a szintaktikájuk elég messze van egymástól.
Engem például a Node.js forráskódját böngészve zavar a sok Python / C++ / C és Assembly kód.
Van a javascript-nek egy
Pontosan. Azok, akik ilyen nyelvet használnak a JavaScript fölött, azok nem szeretik a JavaScript szintaktikáját. Különben JavaScriptet használnának.
Akkor ne használj fordított nyelvet. Mindenesetre ez olyan érv egy nyelv ellen, mint azt mondani, hogy te azért nem szereted az SVG-t, mert vektoros.
Nem, nem kell ismerned a szintaktikájukat, mert neked elég a lefordított JavaScript kódot használnod. Én arra kívántam célozni, hogy az operációs rendszereden is rengeteg különböző nyelven írt könyvtár futhat, ez mégsem okoz gondot, mert mind ugyanarra a natív kódra fordul. Ráadásul a lefordított JavaScriptet sokkal könnyebb olvasni, mint az assembly-t.
(Figyelj oda légyszíves a helyesírásodra, mert néhol olvashatatlan vagy.)
Nem, nem kell ismerned a
Másképp vázolom fel a problémám és ezzel az előttem levő válaszára is válaszolnék.
A fő problémám abból ered NodeJS esetében, hogy külső modulokat használok.
Ezen modulok minősége nagyon eltérőek tudnak lenni és sokszor javításokat kell végezni rajtuk.
Adott több lehetőség:
Jelzem a készítőjének a problémát és várom, hogy elkészüljön a javítás. Én addig ülök és malmozok.
Lefejlesztem saját magam.
Illetve kezembe veszem a problémát és megpróbálom megoldani.
Irány a GitHub és ekkor jön a meglepetés. A kód nem natív JavaScript-ben íródott.
Itt amivel érveltek, hogy akkor használjam a sima JavaScript kódot, de ez itt csak tüneti kezelés, ahhoz hogy a problémát megoldjam az eredeti elfedő nyelven kell megoldani, mert csak úgy kerül vissza a javítás.
Hozzáteszem ismerem és tudom használni a TypeScript-et és a CoffeScript-et is.
Az első hozzászólásomban arra céloztam, hogy mi lesz ha ezek mellé még jön négy-öt ilyen. A nyelvi töredezettségnek köszönhetően, ez a megoldási út igen csak nehezen lesz járható.
Hozok ellenpéldát.
PHP-ben felrakok egy keretrendszert és az nagyrészt megoldja az alapvető dolgokat.
Adatbázis, session, kimenet kezelés, megjelenítés, stb...
Ezek meg vannak oldva.
Addig NodeJS-ben ezek mind külön-külön modulok és néha eltérő "nyelveken" is készülnek.
Nem maga az elfedő nyelv ellen akarok kampányolni. Mindennek megvan a maga helye. Gondom az ebből származó töredezettség.
Szerintem egy kellően képzett
Nem azon van a hangsúly, hogy
Én nem is beszélek janezről.
Nem mondom, hogy "nekem van
Az elfedő nyelvek megoldást nyújtanak bizonyos problémákra. Ezzel szerintem jött vele egy másik. Amíg 1-2 ilyen van addig nincs vele bajom, de most ezen a blogmarkon itt egy harmadik és mennyi jön még? Szerintem a továbbiakban ha megjelenik egy "mennyiség", csak lassítja a fejlesztést. De ne legyen igazam.
Szerintem pedig de,
Pont annyira, mint egy
Egy komfortos nyelvben megírt
Ha egy "más" nyelven írt könyvtárt olvasok/debugolok, akkor még annak a szintaktikáját is fel kell fognom előbb.
+1
De kérem
Azért ne sarkítsunk ennyire.
A JS (mint a Java vagy PHP) a C szintaxisra épül. Ha ezzel gondjai vannak az embernek nem túl jók a kilátásai a szakmában.
Amit inkább lehet "nem szeretni" a JSben az a típusosság és klasszikus öröklődés hiánya. Általában ezeket pótolják bele a hasonló, JS-re fordítható nyelvek.
A probléma akkor van, ha a készítők (akik mondjuk a diplomamunkájuknak szánták a projektet) beleszövik világmegváltó álmaikat. Ilyenkor kezdünk eltérni a C szintaxistól, és a gépelés minimalizálását helyezni előtérbe.
Egyrészt, van világ a
Túl a szintaxison
Szóval a Python vagy a Ruby
Szalmabáb
Hol látod az érvelési hibát?
Bal felső
"Szándékosan féreérteni a másik mondatait, hogy könnyebben támadható legyen."
Haha
Sóhaj
Én:
Te:
Én:
Te:
Bocs, de ez magyarul annyit jelent, hogy azok a nyelvek, amik nem a C szintakszisát használják, azok annyira használhatóak, mint a Brainfuck.
De ha már érvelési hibát kiáltasz, akkor legalább mutass rá, ne csak kijelentsd, hogy a másik félrebeszél.
Nos...
Ha tényleg ezek jöttek le, mint a hozzászólások mondanivalói, akkor valamelyikünk részéről kommunikációs probléma van.
A "nem túl jók a kilátásai" hozzászólásban azt probáltam felvetni, hogy a legtöbb nyelv, ami eltér a C szntaxistól fölösleges komplexitást visz be a nyelvbe és általában rossz motivációk miatt (egy-egy feladatot könnyebben - kevesebb gépelkéssel - lehessen megvalósítani).
Erre a gondolatra érdemben nem válaszoltál (vagy azért mert nem volt érthető vagy azért mert így volt egyszerübb érvelni). - Az, hogy "van világ" azt csak úgy tudom értelmezni, hogy sokan használnak más (nem C alapú) nyelveket, ami annyit mond, mint az "egymillió légy".
A Brainfuck és egyéb nyelvek annyiban egyenlőek, hogy egyik sem C (alapú). Arról, hogy melyik miben jobb vagy rosszabb úgy látom, nem igazán szeretnél társalogni.
Olvasni
Egyébként az olyan nyelveket, mint a Python, Ruby, nem csak írni könnyebb, hanem olvasni is. Mivel közelebb áll a felépítése az angol nyelvhez, mint a például a Java vagy C. Ráadásul nem csak többet kell írni, hanem sokszor feleslegesen többet.
Konkrétumok
Jól olvasható például (legalábbis vezérlőszerkezetek tekintetében) a basic, napjainkban viszont gyakorlatilag kihalt. Ettől jobb vagy rosszabb egy "kapcsoszárójeles" nyelvnél? Nem tudnám megmondani.
Ahol elválik a búza az ocsútól (szvsz) az egy nagyobb komplexitásnál jelentkezik. (Hello world alkalmazást nem nagy szám egyik nyelvben sem írni). Jó statisztika lenne megvizsgálni mondjuk (hasraütés) az ötvenezer sornál nagyobb projekteket, milyen arányban képviseltetik magukat különböző nyelvek szemben mondjuk az 5-10 ezres régióval szemben.
Meg persze lehet mikroszinten is egyes szintaktikai elemekről beszélgetni, de általában mindneki azt használja amit szeret, és az áll kézre neki amit használ.
Mivel a programnyelvek
Van akinek ez tetszik
Out transform(In first, In last, Out result, Fun op);
Ha jól értem arról vitázunk,
A kérdés legalább ilyen jogos megfordítva, figyelembe véve, hogy a C szintakszis viszonylag új.
Vigyázz, ezzel te is a legyek számát kezded vizsgálni!
Legyek
Önmagában egyik torta se mond sokat nekünk, de a kettő öszehasonlítása gyülölcsöző lehet.
Félek, hogy egy ilyen
Ha tényleg ezek jöttek le,
Szerintem is elbeszéltünk egymás mellett.
Ha hozol példát, akkor tudok rá reflektálni, mert szerintem más szinten gondolkodsz most. Én arról beszélek, hogy irreleváns, hogy kapcsoszárójel (C) vagy
begin ... end(Algol).Ó, dehogynem, bár fenntartva, hogy nagyrészt elég szubjektív a kérdés.
Maga a CoffeScript nem rossz,
A GorillaScript nekem kicsit túl okosnak tűnik, az ember elveszik a lehetőségekben, szerintem nem lett túl jól megtervezve a nyelv (CoffeeScriptben is sok lehetőség van, de ott valahogy nincs az az érzése, hogy "hát ez meg minek van?")
Ez a tower.js vicces példa.
Az ilyenekkel nincs is gond. Minden egy helyen. Ez egy jó példája az elfedő nyelvek jó használatára.
Ha jól látom épp most bombázták szét és újra írják. Szerintem most CoffeScript nélkül.
A CoffeScript eltűnt a függőségek közül.
Most: package.json v5
Míg az előző verzióban még ott volt: package.json v4
Lehet úgy látszik én csak
de megnézve pár Gorilla script -> javascript átiratát nagyon gáz az egész.
Némelyik egészen megdöbbentő, míg a Majom script 2-3 sor, addig a javascript 20-40 sor.
Én most azt nem tudom
Az ilyen fordítók sokszor automatikusan elvégeznek bizonyos mikrooptimalizációkat, pl coffeescript a for ciklusokat rendszeresen így követi el:
Pedig a mai böngészőkben az
Nyilván, de ezt a JavaScript maga nem garantálja. Egy naiv implementáción futtatva jól jön, ha már az eredeti fordító optimalizál.
Negatívum. Még ha bedobunk
Még ha bedobunk is valami compiler-t, akkor is "kicsit" sok és optimalizálatlan a javascript kód, ami probléma nagy kódbázisnál..
Tudsz esetlen valahol valami teszt oldalt benchmarkokkal, ahol az ilyen optimalizációk (for ciklus) fent vannak?
http://jsperf.com/for-with-le
A GCC is jobban optimalizálja a kódot, mint ahogy azt az ember kézzel tenné. Maga a lefordított js kód pedig senkit sem érdekel, az assembly kódot sem nagyon szokta a fejlesztő nézegetni alapesetben. A méretbeli különbségek pedig szerintem lényegtelenek.
Köszönöm.Ezt az oldalt
Ezt az oldalt ismertem, de szerintem bugos.
Ennek a tesztnek is két változata is van, ami két különböző output-ot ad ugyanazon böngészőn belül, a legnagyobb probléma, hogy nem jelzik mit javítottak a két verzióban, hogy mitől van ez a különbség.
De, ha ezektől eltekintünk, itt pont az ellen szólnak a teszt eredmények, hogy nem mindegy milyen kódot tolsz az engine alá.
Ezek szerint mégis a
for(var i=0, len=array.length; i<len; i++)
a leggyorsabb megoldás, szóval mégsem olyan fölösleges mint gondolod, persze, ha nem értettelek félre.
A tesztet én hekkeltem át
Én eddig nem is néztem, hogy
forEach()milyen rossz teljesítményt nyújt. Szerencsére nem használom ezeket a ES5 újításokat. A natív megoldás kb. annyival lassít mint az egyéb implementációk. Eddig úgy gondoltam talán gyorsabbnak kéne lennie.Az egyéb implementációk
A forEach egy függvényt hív
hisz inlineolni is lehet
De ekkor meg a for / while ciklus biztosan gyorsabb lesz, mivel ott sokkal könnyebb felismerni, hogy inline formára lehet fordítani.
Egyedül akkor lehet hasznos a forEach, ha meg akarod határozni a
thisértékét a futtatandó ciklusban, de erre egy.callvagy.applyis tökéletesen alkalmas lehet, ugyanakkor azoknak is van teljesítményre gyakorolt hatásuk.De ekkor meg a for / while
Miért könnyebb?
Én speciel nem azért
forEach-et, mert teljesítményben annyi pluszt nyújt (hisz nem nyújt :D), hanem mert segíti az olvashatóságot, tömörebb a kód, ezáltal (számomra) jobban átlátható. Lehet, hogy lassít a kódon, de igen nagy valószínűséggel nem ez lesz a szűk keresztmetszet, szóval nem foglalkozom vele.Jó Neked, hogy nem elsődleges
.. nekem megdöbbentő, hogy milyen "gagyi" a js engine-k optimalizációja, szinte csak a standard formákat tudja jól optimalizálni.
Egy dolog merült fel bennem, hogy lenne kedve valakinek itt csinálni egy profibb oldalt a http://jsperf.com/ helyett?
Nézegettem a benchmark.js-t és elég tákolmány, bizony ennél sokkal profibban meg lehet írni.. és az oldal is siralmas.
Félreértesz. Fontos a
A js motorok pedig kifejezetten jól optimalizálnak. Ne feledjük, hogy a js egy interpretált nyelv, ehhez képest pl a v8 képes olyan "gagyi" optimalizációkra, hogy natív kódot fordít belőle, amit valós időben a futásteljesítmény függvényében tovább optimalizál.
Amit írsz, annak azért a
A tesztek szerint azt sem tudják kioptimalizálni, hogy hol növelem a léptető értékét, mint ahogy azt se, hogy milyen irányból járom be a "tömböt".. nekem ezek nem arra jelzések, hogy jók lennének, csak max. arra, hogy sokat fejlődtek, de még jócskán figyelni kell milyen kódot ír az ember.
Abban igazad van, hogy a db a szük keresztmetszet.. sok tesztet láttam már node.js-re, csak olyat alig, amiben db-t használtak benne.
Üdítő itt ilyen hozzáállásról
Igaz
Bocs, de nem csak én
Emlékszem (jó) pár éve még azon is ment a szőrözés, hogy vajon melyik a gyorsabb/jobb/ajánlottabb.. a String concat vagy az Array majd join megközelítés, most meg bocs, nem én hoztam fel, hogy milyen jól optimalizálnak a JS engine-k.
Te is csak azt erősíted meg amit már írtam feljebb, hogy mégis csak a programozótól függ leginkább a kód sebessége, nincs ezen valóban semmi vitatni való.
A 98% egyébként igaz.. a 2% meg kapja be?
Biztos, benne vagyok a 2%-ban és ezeknél triviálisabb tesztet is kellett már végeztem már böngészők között, hogy be tudjak állítani optimálisan egy.. értéket.
Kicsit jobban megnéztem.. a
mert valami kezdő programozó írhatta a teszteket, almát akart körtével összehasonlítani.
Próbálgattam én is de, felhúzott, hogy valaki megír egy ilyen viszonylag jó cuccot, színvonalasan, de arra már igénytelen, hogy kirakjon egy törlés gombot néhány helyre.