Új hozzászólás Aktív témák

• #9 ddekany veterán oO7 #8

  Új Válasz 2011-08-24 19:08:49 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz oO7 #8 üzenetére

  Hagyományos laptop kiváltása tömegesen érdekes attrakció lenne azért. Eleve Android mint OS Windows helyet... azt hiszem nem kicsit fogná vissza a térhódítás. Ha meg Win8, és rendes Office, stb, akkor labdába rúg ez mondjuk egy Brazos C50 súlycsoportban (9W, stb) sebességben? Meglepődnék, de amúgy nem tudom... (Persze a legtöbb Win-es alkalmazásnak nem lesz egyhamar ARM-ra fordított változata, és innentől kezdve lehet, hogy nem is jobb mint az Android...)

  [ Szerkesztve ]

• #30 ddekany veterán oO7 #11

  Új Válasz 2011-08-25 00:37:09 #30

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz oO7 #11 üzenetére

  "Win8-nál meg az alkalmazások túlnyomó része probléma nélkül futni fog tetszőleges hardveren merthogy silverlight..."

  Hogy az MS esetleg sok mindent átír .Net-re a Win8-ba beépített alkalmazások közül, az ilyen szempontból szinte mindegy, mert ha ők valóban rendesen támogatni fogják az ARM-et, akkor ami nem .Net azt úgyis kénytelen újrafordítani az ARM-is Win8-hoz. A többieknek meg nem lesz .Net-es átirata a büdös életben az eleve nem úgy fejlesztett programokból, és ezen Win8 nem segít. Szóval marad nekik az újrafordítás...

• #43 ddekany veterán lkandris #41

  Új Válasz 2011-08-25 12:31:32 #43

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz lkandris #41 üzenetére

  Mondjuk amit említettél, az csak programozóknak kell, igen szűk réteg. Ráadásul általában a jó egyszálas CPU teljesítmény a fontos ott, abban meg nem valószínű az Intel trónfosztása. (Minden esetre én is érdeklődve várom, mit fog ez tudni Win8 + Office terén... Égés lesz vagy ellenkezőleg?)

• #46 ddekany veterán lkandris #44

  Új Válasz 2011-08-25 15:01:21 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz lkandris #44 üzenetére

  Videó kódolást rá lehet nyomni a GPU-ra.

• #76 ddekany veterán Abu85 #51

  Új Válasz 2011-08-26 02:27:07 #76

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz Abu85 #51 üzenetére

  "A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is. Ezen dolgozik az ARM. Az új generációs fórummotorok esetében ez komoly lehetőségeken nyitna meg."

  Diktálni fogod amit írnál? Ilyen egyáltalán van már, ami megbízhatóan működik? Meglepődnék. Elég csak megnézni a YouTube beszédfelismerős feliratozóját... pedig gondolom ők komolyan veszik ezt, meg van sok szerverük is erre.

  Egyébként nszvsz kapja be az összes cég aki ilyenekkel nyomul weben, mind 3D meg ilyen-olyan CL... Esetleg előbb az alap gondokat kéne helyrerakni. Az kutyát nem érdekel pl. hogy egy egyszerű szövegszerkesztőt nem lehet csinálni HTML/JS alapon, csak össze-vissza bugos/lassú szarokat. (Igen, ismerem a TinyMCE-t/CKEditor-t, amik 2011-ben azzal kezdik, hogy aláhúzós helyesírás kikapcsolva mert különben megkavarodnak... meg Google docs-ot ami bekezdésről még nem halott, stb., szóval Word 1.0 tudásban lealázza, sebességben meg kb. a föld közepéig). De nem gond ám... elvégre a formázott szöveg felvitel csak alapfunkció, ha weboldalakat tölt fel az ember (CMS-ek, vagy akár PH fórum). A Webes 3D meg a hanga, na aaaz a fontos... Konzum idiótaság a köbön. Abba már bele sem megyek, hogy a JS nem egy olyan nyelv, amivel más nyelveket implementálni tanácsos, meg úgy általában nem teljesítmény orientált sem karbantarthatóságra kihegyezett, ergo semmi keresnivalója nincs a "szabványos" stack alján. Erre is szarik mindenki. (OK, MS próbálkozik a CLR-el, de az meg az MS+Web kliens oldalon, szóval ez sem lesz soha elterjedt...) De nem baj semmi... legalább van munka, fizet mindenki mint a katonatiszt.

• #77 ddekany veterán Abu85 #61

  Új Válasz 2011-08-26 02:34:19 #77

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz Abu85 #61 üzenetére

  "A HTML5-ön belül viszont számos olyan tartalmat használhatsz, ami GPU-val gyorsítható."

  Amit HTML4-ben még nem gyorsítható? Mi? Nekem csak a videólejátszás ugrik be, de az meg jelenleg Flash, ami tud GPU-s gyorsítást (most már egyre inkább).

• #81 ddekany veterán julius666 #80

  Új Válasz 2011-08-26 09:59:24 #81

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz julius666 #80 üzenetére

  Én meg attól tartok, hogy a megbízható beszédfelismerés nem csak számítási kapacitás kérdése, hanem AI-é is. Legalábbis nekem borzalmasan sokat segít egy szöveg (főleg egy angol szöveg) hallás utáni megértésében, hogy tudom hogy milyen szó értelmes az adott ponton (a sok hasonlóan hangzó közül).

  JS dolog: "Ezt nem igazán értem."

  Elég gyér egy olyan alkalmazás fejlesztésre szánt platform, amiben a legalacsonyabb szintű nyelv egy eredetileg nagyon-nagyon kicsi projektekre tervezett script nyelv. Képzeld ha Windows platformon a VB lenne a legalacsonyabb szintű nyelv amit használhatsz, és nem létezne a gépikód, amire építve létezhet a C++, Pascal, Python, meg akármi ami kell. Meg nem utolsó sorban, amire építhetsz nagy és széles körben használt könyvárakat anélkül, hogy mindenkinek aki használja 5x annyit egyen mert dinamikus nyelv. Normális platformokon van választásod.

  "Egyébként ha a Google próbálkozásai sikerrel járnak és elterjed, a jövőben natív kód (illetve próbálkoznak egy köztes nyelv használatával is)"

  Ilyesmi lenne a helyes út... bár a natív kód elég szarul hangzik, a köztes (Dalvik pl.?) már sokkal jobban.

• #82 ddekany veterán julius666 #79

  Új Válasz 2011-08-26 10:05:59 #82

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz julius666 #79 üzenetére

  "a WebCL az javascript bindig az OpenCL-hez, nem több."

  A WebCL valójában egy új nyelv is. Ha megnézel egy oldalt ami használja, ilyeneket találsz benne:

  <script type="text/x-opencl">
  ... valami C-szerű forráskód ...
  </scrpit>

  [ Szerkesztve ]

• #84 ddekany veterán julius666 #83

  Új Válasz 2011-08-26 15:05:51 #84

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz julius666 #83 üzenetére

  "Szarrá van sandboxolva meg ellenőrizve, így talán annyira nem."

  Nem is a biztonság a gondom vele, meg annyira fatális gondom nincs vele ha majd CPU architektúra független is lesz (PNaCl, LLVM). Csak kicsit furcsa, hogy míg Windows alkalmazásfejlesztés terén már rég elindult a trend a C++ (natív) leváltására C#-al (CLR), itt most megint totál natívról akarnak kezdeni. A JVM (Java, stb) és CLR (C#, stb) felfogásának közel sem csak a valamivel nagyobb biztonság az előnye... Hanem pl. automatikus memória kezelés, nincsenek pointerek, jobb interoperabilitás a mások által fejlesztett komponensekkel. Persze a (P)NaCl-en meg lehet valósítani egy JVM-szerűséget, csak nehogy az legyen, hogy ezért nem fog ilyesmi elterjedni, mert alapból nincs elég helyen telepítve, és 50 MB-t lerántatni a weboldal első meglátogatáskor meg nem vicces. (Ez kb u.a. a sztori mint desktopon, ahol is a .Net igazi felfutásához egyértelműen fontos, hogy az Windows része lett. Itt ha csak a PNaCl lesz a böngészők része alapból, de az akármilyen-VM (pl. Dalvik) nem... kétséges a kimenetel.)

  "Csak komolyabb dolgokhoz (pl. komolyabb játékmotorokhoz, nagyobb üzleti rendszerekhez) alkalmatlan, de nem igazán értem ez miért akkora probléma, nem is erre találták ki, nem is próbálja senki ilyesmire használni."

  Azért igencsak vastagodnak a kliens oldali rétegek is... És amúgy a dinamikus nyelvek problémái közül a sebesség csak az egyik, és sokszor nem is a lényeges gond. A karbantarthatóság és IDE támogatás az ami miatt sokszor nem jó üzlet a dinamikusság. (Na de ilyen nyelvi finomságokról kár is beszélgetni Web kapcsán, ahol is a programok 99%-át PHP-ban írják, ami nyelvtervezésileg egy hatalmas kupac inkompetencia némi káosszal nyakon öntve... Képzelem, emberek ezen nőnek fel, és a koporsóig más nem is látnak. Csak hallották, hogy van ilyen, mint Scala, meg Ruby meg Python, de azok bloatedek meg lassúak meg vááá...)

• #86 ddekany veterán julius666 #85

  Új Válasz 2011-08-26 20:46:29 #86

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz julius666 #85 üzenetére

  "kódkiegészítés lényegében nincs (van csak buta) és sorolhatnánk. Ez azonban nem hiszem hogy szükségszerű állapot"

  Javítani lehet sok mindenen, heroikus befektetésekkel... de soha nem lehet azt a szintet elérni, mint statikus nyelvekkel, főleg azonos befektetéssel nem. Ha ugyanis tényleg kihasználod a dinamikusságot, akkor szükségszerűen nincsenek egyértelmű válaszok arra, hogy mi milyen típusú (osztályú), meg ha adott osztályú akkor milyen metódusai vannak. Neked is sokszor nehéz kigabalyítani, hát még egy IDE-nek aki magasabb szinten nem érti a programot, na meg nem futtathatja és nézegetheti debuggerrel. Ha meg nem használod ki a dinamikusságot, akkor inkább valami modern statikus nyelvet érdemes használni. Persze itt egy nagy buktató, hogy a statikus nyelvek világa valamiért elég nehézkesen mozgott az utóbbi évtized(ek?)ben... A korszerűbbek (pl. Digital Mars féle D vagy Scala, Kotlin, Ceylon) még szinte sehol sincsenek, főleg tooling terén, holott utóbbi lenne pont ez egyik lényeges erényük. A Java ilyen szempontból remek pozícióba van, de maga a nyelv ma már fájdalmasan elmaradott és eleve feleslegesen szószátyár, ezzel is égetve a statikus nyelveket. C# még tán a legjobb azok közt ami elterjedt, de Mono ide vagy oda, ott az MS árnyéka. Szóval legalábbis nem-Windows platformon van itt egy űr, ami kedvez a dinamikus nyelveknek, jobban mint megérdemelnék. Most ezért a szerver oldalon is a feleslegesen szadista Java és a saját műfajában elég jó Ruby ill Python közt kell választani. (Persze, visszatérve a rögös Webes valóságba, az is már csodás lenne, ha mondjuk a Python ugyan olyan mindenhol alapértelmezésben jelenlévő és bagóért hosztolható lenne, mint a PHP. Igen, a VPS ára szerencsére csökken.)

  Ja, "kicsit" OFF-ok lettünk...

  [ Szerkesztve ]

Új hozzászólás Aktív témák