Google e l'invadenza di Nexus 7

La purezza dell'home page del motore di ricerca violata dal nuovo device che fa capolino

Roma – L’ormai ex Googler Marissa Mayer aveva in passato chiaramente detto che non ci sarebbe stata invadente pubblicità sull’homepage di Google: ma ora che se n’è andata da Mountain View, a quanto, pare, c’è spazio per un’eccezione a favore del nuovo dispositivo Android di punta.

Nexus 7, infatti, fa letteralmente capolino apparendo sotto la barra di ricerca, infrangendo la consueta bianca purezza della pagina, accompagnato dalla frase: “I giochi sono aperti. Il nuovo tablet da 199 dollari di Google”. ( C.T. )

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • carlo scrive:
    XXXXXccio iddio
    MANNAGGIA I SANDALI DI CRISTOP.S. ALFONSO FA' LE PIPPE COI PIEDI
  • carlo scrive:
    fate schifo
    Siete delle merde, cancellate anche i commenti " scomodi" che la gente vi lascia complimentoni straccio di ritardati cmq tanto per riperete non é panda ma volpe mongoloidi di XXXXX
  • carlo scrive:
    per caritá
    Ma quale panda rinXXXXXXXXti, ma ve repigliate
    • sbrotfl scrive:
      Re: per caritá
      - Scritto da: carlo
      Ma quale panda rinXXXXXXXXti, ma ve repigliatehttp://www.mozilla.org/projects/firefox/firefox-name-faq.html
    • panda rossa scrive:
      Re: per caritá
      - Scritto da: carlo
      Ma quale panda rinXXXXXXXXti, ma ve repigliateTu quale carlo sei?
      • sbrotfl scrive:
        Re: per caritá
        - Scritto da: panda rossa
        - Scritto da: carlo

        Ma quale panda rinXXXXXXXXti, ma ve
        repigliate

        Tu quale carlo sei?Quello troll :D
  • topolinik scrive:
    Siamo di fronte...
    ...all'alba di una rivoluzione.Entro pochi mesi tutti i browser saranno dotati di WebGL e a quel punto che senso avrà sviluppare per windows/linux/mac? Sviluppi i giochi per il web. E non ditemi che l'aspetto grafico è scarso perché non lo è.L'insieme di JS (che ormai è velocissimo!) e supporto multimediale nei browser saranno per i videogiochi la realizzazione della promessa che Java non ha mai mantenuto: "write once, run everywhere".Staremo a vedere (e a giocare).
    • Un vero programmat ore scrive:
      Re: Siamo di fronte...
      - Scritto da: topolinik
      videogiochi la realizzazione della promessa che
      Java non ha mai mantenuto: "write once, run
      everywhere".Mah forse per i giochi non sarà stato vero. Ma le mie applicazioni java hanno sempre girato bene su windows,linux e mac senza ritocchi. Basta saper programmare, quello che in pochi sanno fare e poi dicono "java fa schifo".
      • MacGeek scrive:
        Re: Siamo di fronte...
        Java FA schifo! :D
        • sentinel scrive:
          Re: Siamo di fronte...
          - Scritto da: MacGeek
          Java FA schifo!
          :DAllora non sai programmare!
          • sbrotfl scrive:
            Re: Siamo di fronte...
            - Scritto da: sentinel
            - Scritto da: MacGeek

            Java FA schifo!

            :D

            Allora non sai programmare!L'hai visto il nome?
      • sentinel scrive:
        Re: Siamo di fronte...
        - Scritto da: Un vero programmat ore
        Mah forse per i giochi non sarà stato vero. Ma le
        mie applicazioni java hanno sempre girato bene su
        windows,linux e mac senza ritocchi. Basta saper
        programmare, quello che in pochi sanno fare e poi
        dicono "java fa schifo".Infatti, hahahahahha (rotfl)Il bello è che questi stessi seguono poi i corsi Javaper imparare a programmare BENE con la programmazioneorientata agli oggetti.
    • mmmm scrive:
      Re: Siamo di fronte...
      si vede che non hai mai toccato in mano un computer, JS è l'inefficenza in persona, e WebGL si basa sul JS, ventola della GPU a mille per un cubo in movimento...
      • unaDuraLezione scrive:
        Re: Siamo di fronte...
        contenuto non disponibile
        • MacGeek scrive:
          Re: Siamo di fronte...
          - Scritto da: unaDuraLezione
          - Scritto da: mmmm

          si vede che non hai mai toccato in mano un

          computer, JS è l'inefficenza in persona, e
          WebGL

          si basa sul JS, ventola della GPU a mille
          per
          un

          cubo in

          movimento...

          WebGL non si basa su JS, ma è invocato da JS.
          WebGL si basa sulle librerie (eseguibili nativi)
          sui driver (nativi) e sull'hardware (puoi anche
          programmare gli shader con le microistruzioni
          native).
          esempio di uso di shaders:
          http://david.alloza.eu/WebGL/morphing.html

          JS non è una scheggia (anche se ora viene
          precompilato), ma nel caso di WebGL serve solo a
          passare 'gli ordini' alla GPU, le trasformazioni
          e il rendering avvengono in
          hardware.
          In pratica si perde in termini di prestazioni ed
          utilizzo della memoria ma si possono fare
          tranquillamente giochi fluidi e
          dettagliati.Tra l'altro molti giochi non sono programmati in LUA che è sempre un linguaggio interpretato (per quanto molto efficiente e da cui i compilatori JS hanno copiato)?
          • Winaro scrive:
            Re: Siamo di fronte...
            - Scritto da: MacGeek
            - Scritto da: unaDuraLezione

            - Scritto da: mmmm


            si vede che non hai mai toccato in mano un


            computer, JS è l'inefficenza in persona, e

            WebGL


            si basa sul JS, ventola della GPU a mille

            per

            un


            cubo in


            movimento...



            WebGL non si basa su JS, ma è invocato da JS.

            WebGL si basa sulle librerie (eseguibili nativi)

            sui driver (nativi) e sull'hardware (puoi anche

            programmare gli shader con le microistruzioni

            native).

            esempio di uso di shaders:

            http://david.alloza.eu/WebGL/morphing.html



            JS non è una scheggia (anche se ora viene

            precompilato), ma nel caso di WebGL serve solo a

            passare 'gli ordini' alla GPU, le trasformazioni

            e il rendering avvengono in

            hardware.

            In pratica si perde in termini di prestazioni ed

            utilizzo della memoria ma si possono fare

            tranquillamente giochi fluidi e

            dettagliati.

            Tra l'altro molti giochi non sono programmati in
            LUA che è sempre un linguaggio interpretato (per
            quanto molto efficiente e da cui i compilatori JS
            hanno
            copiato)?Basta che guardi ai game engines. Il core del gioco è in c++, ed offre (nel caso dei game engines) un framework completo per lo sviluppo del tuo videogame. lo scripting delle AI, degli eventi, ecc... però è supportato tramite linguaggi interpretati (volendo) e questo non rallenta in maniera sensibile l'applicazione. In pratica le cose più gravose sono gestite da librerie compilate ed invocate dagli script.Con webGL credo sia la stessa cosa, hai una base (WebGL) che si occupa del lavoro grosso e fornisce le sue interfacce, e JS che gli dice fai questo, fai quello. Ma il *come* farlo è in WebGL.A tal proposito vorrei porre l'attenzione sulla superiorità dell'implementazione della Microsoft Corporation (TM), già disponibile in Windows 8 (TM).Parola di Winaro! ;)
          • abral scrive:
            Re: Siamo di fronte...
            - Scritto da: Winaro
            A tal proposito vorrei porre l'attenzione sulla
            superiorità dell'implementazione della Microsoft
            Corporation (TM), già disponibile in Windows 8
            (TM).E' uno scherzo? Microsoft non supporta WebGL.
          • Winaro scrive:
            Re: Siamo di fronte...
            - Scritto da: abral
            - Scritto da: Winaro

            A tal proposito vorrei porre l'attenzione sulla

            superiorità dell'implementazione della Microsoft

            Corporation (TM), già disponibile in Windows 8

            (TM).

            E' uno scherzo? Microsoft non supporta WebGL.Ha il suo standard, DirectGL, molto superiore a WebGL. :@Parola di Winaro! ;)
          • abral scrive:
            Re: Siamo di fronte...
            - Scritto da: Winaro
            Ha il suo standard, DirectGL, molto superiore a
            WebGL.
            :@Ok, era uno scherzo XD
        • mmmm scrive:
          Re: Siamo di fronte...
          so che va sui driver,ecc ecc... però il motore di gioco lo scrivi in javascript, dubito lo metti in un shader. Uno ha fatto uno snake in webgl e shader e dopo qualche istante sento già la GPU che alza la ventola, non deve essere il massimo allora...E javascript non è veloce e non lo si potrà ancora spingere avanti, si è già arrivati ormai al massimo credo, ormai le uniche cose su cui lavorano principalmente è sul rendere le pause del GC più corte possibili. Non sarà ancora molto più veloce di così. E a me tutto questo spreco di efficenza non piace neanche un pò. Siamo sempre più mobile, e andiamo a perdere energia su linguaggi inefficenti.... Se l'adobe o la sun avessero lavorato seriamente a java e a flash non saremmo adesso a giocare con il javascript...
          • unaDuraLezione scrive:
            Re: Siamo di fronte...
            contenuto non disponibile
          • mmmm scrive:
            Re: Siamo di fronte...
            - Scritto da: unaDuraLezione
            - Scritto da: mmmm

            so che va sui driver,ecc ecc... però il
            motore
            di

            gioco

            Non esattamente.
            Dopo aver mandato le istruzioni per disegnare
            millemila poligoni, la scheda 3D fa tutto da
            se'.
            Puoi, cambiare il puynto di vista con 'una'
            istruzione, puoi muovere una serie di poligoni
            con un'altra
            istruzione.

            Sono queste le operazioni che farai in JS. La
            scheda 3D disegna tutto senza dover rimandare
            ogni volta l'elenco dei poligoni e
            simili.Da come lo dici sembra che JS faccia due istruzioni su mille quando invece gira continuamente



            E javascript non è veloce e non lo si potrà

            ancora spingere avanti, si è già arrivati
            ormai

            al massimo credo

            perché mai?
            Se viene compilato onfly prima di partire, in
            linea teorica può raggiungere prestazioni simili
            del
            C.
            Il problema di JS è che manca di tipizzazione,
            tutto è oggetto e di questo un linguaggio risente
            in termini di
            prestazioni.
            Ma hanno aggiunto apposta gli array tipizzati
            (non ancora standard
            però).
            Da poco ho cominciato a studiarlo e mi sembra una cosa assurda, mi sembra un agglomerato di tutto in maniera poco strutturata. Anche il fatto dei typed array, vogliono aggiungere ciò che manca a martellate. Il JS non è stato inventato per gli scopi attuali e ora lo si vuole aggiornare. Ero meglio reinventare da zero qualcosa di nuovo, come ha fatto google con NaCl solo che doveva essere qualcosa di standard e invece google va per i fatti suoi.Dico che non si potrà fare molto di più proprio perchè il JIT è quello che dava una grossa spinta e l'hanno già messo. Per il problema dei tipi hanno messo un JIT che li intuisce e hanno ottenuto un'altra spintarella, poi hanno aggiunto i typed array, ora cercano di migliorare la GC però ottimizzerà le pause ma non lo farà andare più veloce di per sè, solo scatterà meno. Hanno anche aggiunto i thread però per usare il multicore come sono fatti non sono molto versatili. Non dico che non si può migliorare ma c'è un limite e secondo me non siamo molto lontani...

            Se l'adobe o la sun

            avessero lavorato seriamente a java e a
            flash
            non

            saremmo adesso a giocare con il

            javascript...

            java e flash sono comunque plug-in mentre JS è
            interpretato nativamente del
            browser.Lo so però java è capace di prestazioni molto migliori. Il problema semmai è che un'applet è lentissima a partire, se ci avessero lavorato sopra...

            P.S.
            quarda questo:
            http://digisnap.bplaced.net/70s
            --------------------------------------------------
            Modificato dall' autore il 31 agosto 2012 16.53
            --------------------------------------------------
          • unaDuraLezione scrive:
            Re: Siamo di fronte...
            contenuto non disponibile
          • abral scrive:
            Re: Siamo di fronte...
            - Scritto da: mmmm
            so che va sui driver,ecc ecc... però il motore di
            gioco lo scrivi in javascript, dubito lo metti in
            un shader.Per fare un esempio, il gioco sviluppato da Mozilla è un gioco C++ che è compilato in JavaScript tramite un software (sviluppato da Mozilla) chiamato Emscripten.I software compilati da C++ in JavaScript sono circa 2-3-4 volte più lenti per ora (a meno di bug).Considera però che Emscripten è stato iniziato da relativamente poco, quindi c'è ancora grande spazio per ottimizzare. E considera che i browser stanno solo ora iniziando ad ottimizzare le loro performance per applicazioni più pesanti.
            Uno ha fatto uno snake in webgl e
            shader e dopo qualche istante sento già la GPU
            che alza la ventola, non deve essere il massimo
            allora...Non è che puoi basarti su un tizio che ha fatto uno snake in WebGL per giudicare tutta la categoria dei giochi JS...
            E javascript non è veloce e non lo si potrà
            ancora spingere avanti, si è già arrivati ormai
            al massimo credo, ormai le uniche cose su cui
            lavorano principalmente è sul rendere le pause
            del GC più corte possibili. Non sarà ancora molto
            più veloce di così.Su cosa basi queste tue conclusioni? A me tutto questo parlare senza alcuna base non piace neanche un pò.In realtà, Mozilla sta sviluppando un nuovo engine JS (IonMonkey) proprio per applicazioni più pesanti, che ottimizzerà il codice molto di più di quanto si faccia ora. Quindi c'è UN SACCO di spazio per miglioramenti.
            E a me tutto questo spreco di
            efficenza non piace neanche un pò. Siamo sempre
            più mobile, e andiamo a perdere energia su
            linguaggi inefficenti....Che intendi per "efficienza" di un linguaggio?Non capisco cosa significhi l'espressione "spreco di efficienza", non credo che l'efficienza sia un qualcosa che si usi. Forse intendi "spreco di risorse" o qualcosa del genere?Comunque quello che fai è un discorso vecchio come il mondo. Anche il C++ comporterebbe uno spreco rispetto al C e il C rispetto all'Assembly (e si può scendere ancora di più), ma i linguaggi di più alto livello sono molto più potenti (nel senso che compiono lavori enormi nel minor tempo possibile).
            Se l'adobe o la sun
            avessero lavorato seriamente a java e a flash non
            saremmo adesso a giocare con il
            javascript...Il linguaggio di programmazione di Flash è quasi uguale a JavaScript.
          • mmmm scrive:
            Re: Siamo di fronte...
            - Scritto da: abral
            - Scritto da: mmmm

            so che va sui driver,ecc ecc... però il motore
            di

            gioco lo scrivi in javascript, dubito lo metti
            in

            un shader.

            Per fare un esempio, il gioco sviluppato da
            Mozilla è un gioco C++ che è compilato in
            JavaScript tramite un software (sviluppato da
            Mozilla) chiamato
            Emscripten.
            I software compilati da C++ in JavaScript sono
            circa 2-3-4 volte più lenti per ora (a meno di
            bug).
            Considera però che Emscripten è stato iniziato da
            relativamente poco, quindi c'è ancora grande
            spazio per ottimizzare. E considera che i browser
            stanno solo ora iniziando ad ottimizzare le loro
            performance per applicazioni più
            pesanti.
            Ma il gioco convertito sarà sempre più lento del C++, anche migliorando emscripten e il broswer.

            Uno ha fatto uno snake in webgl e

            shader e dopo qualche istante sento già la GPU

            che alza la ventola, non deve essere il massimo

            allora...

            Non è che puoi basarti su un tizio che ha fatto
            uno snake in WebGL per giudicare tutta la
            categoria dei giochi
            JS...
            Quello era un esempio per l'altro utente che diceva di usare gli shader per quasi tutto se non ho capito male, è un esempio atipico di gioco WebGL.

            E javascript non è veloce e non lo si potrà

            ancora spingere avanti, si è già arrivati ormai

            al massimo credo, ormai le uniche cose su cui

            lavorano principalmente è sul rendere le pause

            del GC più corte possibili. Non sarà ancora
            molto

            più veloce di così.

            Su cosa basi queste tue conclusioni? A me tutto
            questo parlare senza alcuna base non piace
            neanche un
            pò.
            In realtà, Mozilla sta sviluppando un nuovo
            engine JS (IonMonkey) proprio per applicazioni
            più pesanti, che ottimizzerà il codice molto di
            più di quanto si faccia ora. Quindi c'è UN SACCO
            di spazio per
            miglioramenti.
            Guardo spesso i blog degli sviluppatori di firefox e bugzilla, IonMonkey sono ancora lontani e non so bene su cosa puntano, però come ho scritto sul post per l'altro utente, hanno già il JIT, hanno lavorato sui tipi, ora lavorano sulle pause del GC. Per le applicazioni pesanti so che stanno lavorando ma non sarà nulla di rivoluzionario. C'è un punto oltre il quale non puoi andare, e non credo siamo tanto lontani...

            E a me tutto questo spreco di

            efficenza non piace neanche un pò. Siamo sempre

            più mobile, e andiamo a perdere energia su

            linguaggi inefficenti....

            Che intendi per "efficienza" di un linguaggio?
            Non capisco cosa significhi l'espressione "spreco
            di efficienza", non credo che l'efficienza sia un
            qualcosa che si usi. Forse intendi "spreco di
            risorse" o qualcosa del
            genere?
            Comunque quello che fai è un discorso vecchio
            come il mondo. Anche il C++ comporterebbe uno
            spreco rispetto al C e il C rispetto all'Assembly
            (e si può scendere ancora di più), ma i linguaggi
            di più alto livello sono molto più potenti (nel
            senso che compiono lavori enormi nel minor tempo
            possibile).
            C'è astrazione ed astrazione, ho qualcosa di più semplice a un costo. Se scrivo in C o C++ piuttosto che in assembly il costo è quasi nullo, posso perdere un pò di controllo sulle singole istruzioni però forse avendo una visione più ampia riesco a scrivere codice migliore, o il compilatore stesso riesce a ottimizzare alcune cose meglio di me, ecc...Però qui parliamo di un codice gestito, non nativo come il C, e per di più non è come il Java che si presenta in un bel bytecode facile da eseguire, mi arriva un testo in un linguaggio con poche informazioni che aiutino il compilatore nell'esecuzione, altamente dinamico. Qui lo spreco di risorse è alto e quindi una scarsa efficenza (prima mi sono espresso male). E per efficenza intendo il rapporto tra il lavoro utile e quello eseguito. Per il JS per intenderci devo comprendere il testo, momentaneamente eseguirlo tramite interprete, decidere se compilarlo, eventualmente compilarlo secondo le possibilità dei tipi, eseguirlo, tenenedo conto che potrei dover ricompilarlo nuovamente se il tipo è sbagliato o cambia. E nel frattempo tenere conto di tutti i riferimento all'interno del linguaggio e verso il WebGL e il DOM, preoccupandomi di cancellare tutto il non necessario.Non ho mai dovuto scrivere una VM per JS ma all'incirca dovrebbe essere così.Non mi ricordo dove ma ho letto che il JS è talmente lento da interpretare per tutte le possibilità che consente, che conviene quasi sempre stare a JITtarlo ed eseguire il risultato. Viceversa il Java che arriva con un semplice bytecode conviene fare il jit solo dopo qualche migliaio di esecuzioni, quando so che effettivamente quel punto del codice è molto usato. Tanto il bycode è quasi come un assembly e in un formato che si riesce molto facilmente ad eseguire.Spero di aver chiarito perchè ho una scarsa opinione del JS, anche in confronto ad altri linguaggi ad alto livello.

            Se l'adobe o la sun

            avessero lavorato seriamente a java e a flash
            non

            saremmo adesso a giocare con il

            javascript...

            Il linguaggio di programmazione di Flash è quasi
            uguale a
            JavaScript.Avevo dato per scontato che flash avesse un linguaggio migliore ma in effetti non ho mai programmato in AS3.
          • abral scrive:
            Re: Siamo di fronte...
            - Scritto da: mmmm
            Ma il gioco convertito sarà sempre più lento del
            C++, anche migliorando emscripten e il
            broswer.Si, e questo non è affatto un problema. Se si parlasse di 100 volte più lento ti darei ragione, ma siamo a livelli molto più bassi, la lentezza maggiore giustifica pienamente quello che si può ottenere (sviluppo velocissimo, possibilità di eseguire ovunque).
            Guardo spesso i blog degli sviluppatori di
            firefox e bugzilla, IonMonkey sono ancora lontani
            e non so bene su cosa puntanoIonMonkey probabilmente sarà in Firefox 18. Come ti ho detto, punta ad essere un compilatore JIT migliore di quello base che c'è ora per quanto riguarda le applicazioni pesanti (
            hanno già il
            JIT, hanno lavorato sui tipi, ora lavorano sulle
            pause del GC.Ma non sono cose che una volta sviluppate non migliorano più...Ad esempio i compilatori JIT che ci sono ora sono ottimizzati per lavorare con applicazioni piccole, le ottimizzazioni che fanno sono solo quelle che si possono effettuare più velocemente (e quindi sono anche le ottimizzazioni meno potenti) perché altrimenti, visto che si sta parlando di poche righe di codice, l'overhead della compilazione supererebbe il tempo che ci vuole con l'interprete normale.IonMonkey invece è fatto per applicazioni pesanti, entra in gioco solo quando il motore JS capisce che c'è bisogno di ottimizzazioni pesanti.
            Per le applicazioni pesanti so che
            stanno lavorando ma non sarà nulla di
            rivoluzionario.In base a cosa dici che non ci sarà nulla di rivoluzionario? Io credo che IonMonkey sarà un grosso passo in avanti.
            C'è astrazione ed astrazione, ho qualcosa di più
            semplice a un costo. Se scrivo in C o C++
            piuttosto che in assembly il costo è quasi nullo,
            posso perdere un pò di controllo sulle singole
            istruzioni però forse avendo una visione più
            ampia riesco a scrivere codice migliore, o il
            compilatore stesso riesce a ottimizzare alcune
            cose meglio di me,
            ecc...E' proprio questo il punto. Quando vai ad usare linguaggi più ad alto livello ne perdi un pò in prestazioni ma ne guadagni tantissimo in velocità e semplicità di sviluppo.Anche con JS probabilmente ci saranno cose che il compilatore JIT (proprio perché è JIT ha molte più informazioni su cosa accade durante l'esecuzione del codice) riesce ad ottimizzare meglio di uno sviluppatore umano.Ad esempio PyPy (che è un compilatore JIT per Python, altro linguaggio dinamico), riesce a volte riesce a battere il C (http://morepypy.blogspot.it/2011/08/pypy-is-faster-than-c-again-string.html).
            Qui lo
            spreco di risorse è alto e quindi una scarsa
            efficenza (prima mi sono espresso male). E per
            efficenza intendo il rapporto tra il lavoro utile
            e quello eseguito. Per il JS per intenderci devo
            comprendere il testo, momentaneamente eseguirlo
            tramite interprete, decidere se compilarlo,
            eventualmente compilarlo secondo le possibilità
            dei tipi, eseguirlo, tenenedo conto che potrei
            dover ricompilarlo nuovamente se il tipo è
            sbagliato o cambia. E nel frattempo tenere conto
            di tutti i riferimento all'interno del linguaggio
            e verso il WebGL e il DOM, preoccupandomi di
            cancellare tutto il non
            necessario.E' certo che c'è un overhead, però già 2 volte più lento di codice normale non è chissà che cosa, considerando che ci sono ancora tantissimi altri miglioramenti che verranno sia per quanto riguarda i compilatori JIT sia per quanto riguarda Emscripten (o altri tool del genere, che sono altamente sperimentali).E considerando che la perdita in prestazioni è controbilanciata da un guadagno enorme in semplicità di sviluppo e possibilità di eseguire ovunque.
          • mmmm scrive:
            Re: Siamo di fronte...
            - Scritto da: abral
            E' certo che c'è un overhead, però già 2 volte
            più lento di codice normale non è chissà che
            cosa, considerando che ci sono ancora tantissimi
            altri miglioramenti che verranno sia per quanto
            riguarda i compilatori JIT sia per quanto
            riguarda Emscripten (o altri tool del genere, che
            sono altamente
            sperimentali).
            E considerando che la perdita in prestazioni è
            controbilanciata da un guadagno enorme in
            semplicità di sviluppo e possibilità di eseguire
            ovunque.Guarda spero che IonMonkey sia un grande passo in avanti ma non ci spero molto. Tu parli di grosse applicazioni ma IonMonkey pare sia tutt'altro, una specie di rifacimento in meglio di tutto quanto fatto finora, senza un interessa particolare verso le ottimizzazioni verso le grosse app.Non ho tutto il tuo entusiasmo verso il JS. Due volte più lento secondo me è ben troppo, è la differenza tra un programma fluido e uno che scatta. Inoltre non è affatto semplice da scrivere, la sintassi mi sembra pensata male e poco strutturata, e ci grosse differenze tra i browser in termini di supporto anche senza tirare in ballo il solito IE. Un ragionamento del genere lo posso fare per Java, Python,... che mi semplifico la vita e ottengo un app multipiattaforma ma il JS credo che abbia il posto che ha solo perchè è l'unico linguaggio per browser...
          • abral scrive:
            Re: Siamo di fronte...
            - Scritto da: mmmm
            Guarda spero che IonMonkey sia un grande passo in
            avanti ma non ci spero molto. Tu parli di grosse
            applicazioni ma IonMonkey pare sia tutt'altro,
            una specie di rifacimento in meglio di tutto
            quanto fatto finora, senza un interessa
            particolare verso le ottimizzazioni verso le
            grosse app.Leggi questo interessante articolo: http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/ (è comunque vecchio, a quanto ho capito ora IonMonkey non sarà più usato come baseline compiler)IonMonkey sarà un compilatore capace di molte più ottimizzazioni, al pari di compilatori come GCC o LLVM, qualcosa come la VM di Java, HotSpot (che contiene il compilatore JIT più veloce al mondo, almeno secondo alcuni test).
            Non ho tutto il tuo entusiasmo verso il JS. Due
            volte più lento secondo me è ben troppo, è la
            differenza tra un programma fluido e uno che
            scatta. Inoltre non è affatto semplice da
            scrivere, la sintassi mi sembra pensata male e
            poco strutturata, e ci grosse differenze tra i
            browser in termini di supporto anche senza tirare
            in ballo il solito IE. Un ragionamento del genere
            lo posso fare per Java, Python,... che mi
            semplifico la vita e ottengo un app
            multipiattaforma ma il JS credo che abbia il
            posto che ha solo perchè è l'unico linguaggio per
            browser...Java e Python non ti permettono di fare quello che fai con JS. Con Java non è tanto facile sviluppare un'applicazione per iPhone, ad esempio. Con Python non è tanto facile sviluppare un'applicazione per Android o iPhone, ad esempio.JavaScript ti permette di sviluppare un'applicazione che funziona dovunque e, con opportuni librerie e tool, ti permette di disinteressarti completamente delle differenze tra i vari browser. Considera che Python è anche molto ma molto più lento di JS.
    • asd scrive:
      Re: Siamo di fronte...
      quando la gente avra' in casa i mainframe..............
  • Gnagno scrive:
    Mah....
    Beh, intanto il caricamento non mi sembra dei più veloci.Tutto sommato non è male, ma vorrei consigliare a tutti di provare questo qui: http://www.pouet.net/prod.php?which=12036&howmanycomments=100In 96Kb (ripeto: 96Kb!) hanno messo un gioco spettacolare (e parecchio lungo)!E' per questo che mi sono chiesto: ma perché sbattersi tanto con html5 e webgl quando si potrebbe inserire nel browser una sandbox per eseguibili... lo scaricamento del gioco, fosse fatto come Kkrieger (vedi demo) impiegherebbe un battito di ciglia![img]http://www.pouet.net/screenshots/12036.jpg[/img]
    • panda rossa scrive:
      Re: Mah....
      - Scritto da: Gnagno
      In 96Kb (ripeto: 96Kb!) hanno messo un gioco
      spettacolare (e parecchio lungo)!E' per questo
      che mi sono chiesto: ma perché sbattersi tanto
      con html5 e webgl quando si potrebbe inserire nel
      browser una sandbox per eseguibili...Perche' in tal modo ti vincoleresti ad un sistema.E poi perche' HTML5 anche se verra' sfruttato prevalentemente per quello, non e' pensato per i games.
    • unaDuraLezione scrive:
      Re: Mah....
      contenuto non disponibile
    • Francesco_Holy87 scrive:
      Re: Mah....
      Quanti anni avrà sto gioco? 6 anni?Ad ogni modo avrà anche 96K, ma per farlo funzionare hai bisogno di un proXXXXXre come Dio comanda, perchè si rifà a grafica procedurale.
      • Propoli scrive:
        Re: Mah....
        - Scritto da: Francesco_Holy87
        Quanti anni avrà sto gioco? 6 anni?
        Ad ogni modo avrà anche 96K, ma per farlo
        funzionare hai bisogno di un proXXXXXre come Dio
        comanda, perchè si rifà a grafica
        procedurale.hum... a me va con un Pentium D. :D
    • ... scrive:
      Re: Mah....
      a me da errore se provo ad eseguirlo...
    • abral scrive:
      Re: Mah....
      - Scritto da: Gnagno
      Beh, intanto il caricamento non mi sembra dei più
      veloci.Uga buga, sai quanti dati devi scaricare alla prima esecuzione?
      E' per questo
      che mi sono chiesto: ma perché sbattersi tanto
      con html5 e webgl quando si potrebbe inserire nel
      browser una sandbox per eseguibili...Guarda che BananaBread è un gioco scritto in C++ (http://sauerbraten.org/) trasformato in JavaScript tramite Emscripten (altre demo qui: https://github.com/kripken/emscripten/wiki), quindi anche quel gioco che hai linkato potrebbe essere trasformato in JavaScript ed eseguito in un browser.Considera che quel gioco sicuramente non ti funzionerà su un sistema operativo diverso o, ancor peggio, su un'architettura diversa. Invece un gioco scritto con tecnologie web funziona ovunque ci sia un browser moderno, cioè praticamente ovunque (e a breve sicuramente anche sulle console).
  • bit scrive:
    Nome firefox
    Prima leggi questa info:http://en.wikipedia.org/wiki/Red_panda
    • trollo scrive:
      Re: Nome firefox
      - Scritto da: bit
      Prima leggi questa info:
      http://en.wikipedia.org/wiki/Red_pandaah ah ah qnt ingnoranza tutte balle wikipedia è pericolosa e fa dinformazzione l'addetto anke il tg5 ah ah ah ah (troll)
    • Enjoy with Us scrive:
      Re: Nome firefox
      - Scritto da: bit
      Prima leggi questa info:
      http://en.wikipedia.org/wiki/Red_pandaA questo non credono neppure quelli di mozilla (nonostante le smentite ufficiali), basta guardare l'icona di firefox che assomiglia ben più ad una volpe rossa che al famigerato panda rosso che ho avuto occasione di vedere in prima persona ad uno zoo safari!Tra l'altro esiste un film USA molto noto su un pilota americano che trafuga un aereo sperimentale dell'URSS (eh si ha qualche annetto) che si chiama appunto Firefox (tutto attaccato come nel caso del browser)... e viene tradotto come volpe di fuoco, non certo come panda rosso!
      • sbrotfl scrive:
        Re: Nome firefox
        - Scritto da: Enjoy with Us
        - Scritto da: bit

        Prima leggi questa info:

        http://en.wikipedia.org/wiki/Red_panda

        A questo non credono neppure quelli di mozillahttp://www.mozilla.org/projects/firefox/firefox-name-faq.html
  • Fabio scrive:
    Firefox
    Non si chiama "Panda rosso" ma volpe
    • bit scrive:
      Re: Firefox
      prima leggi.http://en.wikipedia.org/wiki/Red_panda
      • Ottavio scrive:
        Re: Firefox
        E che palle, lo sanno tutti che FireFox significa "volpe di fuoco"... non ci vuole un genio!
        • pippo75 scrive:
          Re: Firefox
          - Scritto da: Ottavio
          E che palle, lo sanno tutti che FireFox significa
          "volpe di fuoco"... non ci vuole un
          genio!Ma anche dragon web in realtà è un panda. Lo sa anche Tai Lung Safari. Un grosso e lardoso panda. ;)
        • sbrotfl scrive:
          Re: Firefox
          - Scritto da: Ottavio
          E che palle, lo sanno tutti che FireFox significa
          "volpe di fuoco"... non ci vuole un
          genio!Tutti i geGni italiani lo sanno di sicuro...Per chi mastica un po' di inglese invece:http://www.mozilla.org/projects/firefox/firefox-name-faq.htmlhttp://en.wikipedia.org/wiki/Red_panda
        • narcigalak scrive:
          Re: Firefox
          non è che bisogna fare la traduzione spezzando le parolefire=fuoco fox=volpe ma il risultato "firefox" è panda rosso
          • panda rossa scrive:
            Re: Firefox
            - Scritto da: narcigalak
            non è che bisogna fare la traduzione spezzando le
            parole
            fire=fuoco
            fox=volpe
            ma il risultato "firefox" è panda rossoE' come ladybug.lady=donnabug=windowsma il risultato non e' donna alla finestra.
          • sbrotfl scrive:
            Re: Firefox
            - Scritto da: panda rossa
            - Scritto da: narcigalak

            non è che bisogna fare la traduzione
            spezzando
            le

            parole

            fire=fuoco

            fox=volpe

            ma il risultato "firefox" è panda rosso

            E' come ladybug.
            lady=donna
            bug=windows
            ma il risultato non e' donna alla finestra.WIN
          • Enjoy with Us scrive:
            Re: Firefox
            - Scritto da: narcigalak
            non è che bisogna fare la traduzione spezzando le
            parole
            fire=fuoco
            fox=volpe
            ma il risultato "firefox" è panda rossoA questo non credono neppure quelli di mozilla (nonostante le smentite ufficiali), basta guardare l'icona di firefox che assomiglia ben più ad una volpe rossa che al famigerato panda rosso che ho avuto occasione di vedere in prima persona ad uno zoo safari!Tra l'altro esiste un film USA molto noto su un pilota americano che trafuga un aereo sperimentale dell'URSS (eh si ha qualche annetto) che si chiama appunto Firefox (tutto attaccato come nel caso del browser)... e viene tradotto come volpe di fuoco, non certo come panda rosso!
          • sbrotfl scrive:
            Re: Firefox
            - Scritto da: Enjoy with Us
            - Scritto da: narcigalak

            non è che bisogna fare la traduzione
            spezzando
            le

            parole

            fire=fuoco

            fox=volpe

            ma il risultato "firefox" è panda rosso

            A questo non credono neppure quelli di mozillahttp://www.mozilla.org/projects/firefox/firefox-name-faq.html
          • unaDuraLezione scrive:
            Re: Firefox
            contenuto non disponibile
  • unaDuraLezione scrive:
    sensibilità del mouse
    contenuto non disponibile
    • Ottavio scrive:
      Re: sensibilità del mouse
      E che palle, lo sanno tutti che FireFox significa "volpe di fuoco"... non ci vuole un genio!
      • unaDuraLezione scrive:
        Re: sensibilità del mouse
        contenuto non disponibile
        • lardoso scrive:
          Re: sensibilità del mouse
          Basta co ste XXXXXXXte avete rotto le pallechise ne sbatte se e' una volpe un panda o un cane del ca77o !- Scritto da: unaDuraLezione
          - Scritto da: Ottavio

          E che palle, lo sanno tutti che FireFox
          significa

          "volpe di fuoco"... non ci vuole un

          genio!

          A dire il vero è un tanuki
          • nibble scrive:
            Re: sensibilità del mouse
            92 minuti di applausi!!!
          • panda rossa scrive:
            Re: sensibilità del mouse
            - Scritto da: lardoso
            Basta co ste XXXXXXXte avete rotto le palle

            chise ne sbatte se e' una volpe un panda o un
            cane del ca77o
            !Qui sul forum di PI ci teniamo molto a puntualizzare queste cose.
          • unaDuraLezione scrive:
            Re: sensibilità del mouse
            contenuto non disponibile
Chiudi i commenti