io e la programmazione siamo due mondi a parte, temo :sad:
mi fermo a "public static void" :bua:
Visualizzazione Stampabile
va beh, oyasumi :alesisi:
Già vai via? :o
oyasumi :ciaociao:
orco dee che magnata e bevuta.
E poi wxyz vergogna. Chiedi informazioni di programmazione a una sysadmin, quando hai qui ME :mad:
ma tu vai via :facepalm:
Sì ma andate a letto a leggere qualcosa, non si può leggeer ceh andate a dormire all'una di venerdì sera!
Parlavo ad elefail&co
Teehee Black è ubriaco.
attenzione però (vale per entrambi :asd:), la domanda non era su questioni di programmazione ma piuttosto di impiego di risorse.
in questo caso la gara era fra le strutture dati di libreria qt (e la loro gestione interna) ed il gc di java, sul lungo periodo. è più facile che il comportamento tipico l'abbia notato un sistemista (anche per i cavoli suoi) che un programmatore.
c# è assolutamente fuori questione, giacchè mono non è maturo ed essendo un possibile progetto mio preferisco sbattermi il 20% in più ed avere una roba portabile o cross-platform (implying linux and the unicies). di sviluppare una roba compilabile solo sotto windows non se ne parla nemmeno.
e tra l'altro, viste le librerie che ho in mente di usare (non mi riferisco alle qt), avrebbe al limite più senso sviluppare solo per unix, perchè NON hanno ancora un corrispondente win32 o .net ; e porca vacca, non sto riuscendo a compilarle sotto mingw.
http://sadpanda.us/images/78961-2RNFYAZ.jpg
Kanako is my waifu.
>poche risorse
>multipiattaforma
applicativi via web is the way :caffe: alla maniera di Google, per intenderci.
E poi caro mio, le risorse deve saperle gestire meglio il programmatore che il sistemista. Se il programmatore non sa gestire bene le risorse è semplicemente un niubbo. Altrimenti perché favorire programmatori bravi con gli algoritmi? :caffe:
kenpufa- 12
this ep was so fk'd up :rotfl:
non applicabile in questo caso, per vari motivi:
- le webapp sono lente (nel senso della latenza) e pesanti rispetto ad un'implementazione non web, sopratutto se devi gestire uno stato applicativo complesso e non hai reale necessità di usare quella caterva di standard
- anche la piattaforma è "sbagliata", stanno cercando di porci rimedio (websockets ecc) ma ora come ora il modello rpc asincrono è troppo limitante ed i browser non hanno un comportamento realmente utile (solo ora justcompilano js, ancora male il threading, integrazione con il desktop inesistente o quasi); hai poco controllo delle condizioni di esecuzione (non funziona più! ah, adobe ha cambiato quel dettaglio dell'implementazione del player..., ah, ma cià greasemonkey.... ecc)
- gli standard del w3c sono interessanti ma bloated, anche se pochi se ne vogliono rendere conto; la stessa google a più riprese ha tentato di metterci pezze (es internamente col cavolo che usano webservices, usano da anni i loro protocol buffers), ma non c'è gente che li ascolti davvero.
- in termini di prestazioni c'è anche una cospicua differenza fra applicazione networked e non networked, non sempre è necessario passare su rete, sopratutto se non vuoi sviluppare un'applicazione client server tipo anni 70, ed io non voglio :fag:
- i web server controllano loro la situazione e la webapp subisce, io voglio fare al limite il contrario, quindi o embeddo il web server nell'applicativo o ciccia, quindi dovrei comuqnuei sviluppare un bel pò al solo scopo di. nah.
- un browser in esecuzione occupa anche 256 mega e rotti (appena controllato). nah.
su questo non ci piove (al limite ci nevica), ma le misurazioni del caso tradizionalmente non le fanno i programmatori ma congiuntamente il team di sviluppo (che non coincide con i programmatori), il team di testing ed i sistemisti, e non è un caso.Citazione:
E poi caro mio, le risorse deve saperle gestire meglio il programmatore che il sistemista. Se il programmatore non sa gestire bene le risorse è semplicemente un niubbo. Altrimenti perché favorire programmatori bravi con gli algoritmi? :caffe:
java (in genere i runtime con garbage collector mark & sweep) di fatto tendono a toglierti il controllo sul reclaim delle risorse, per questo il c++ ha un vantaggio netto su questi aspetti, ma al prezzo di saperlo usare (come dicevi) E di scegliere bene il toolkit e le librerie. le qt sono definite ottime da più parti, così come anche boost, il punto è che a me non interessa il parere comune :fag: voglio sapere cosa possono fare per me. ed io programmatore non so dirlo finchè non misuro.
ribadisco, ti assicuro che di fatto i programmatori non sono più in condizioni di sapere come vanno i loro programmi per questioni di risorse.
ho programmato sistemi anche "bare metal" (senza sistema operativo e senza librerie) - e ti assicuro che quella è l'unica situazione in cui *a volte* puoi disegnare la gestione delle risorse senza effettuare misurazioni a priori. a volte.
wxyz se ti aspetti che io legga tutto quel wall of text stai fresco, fammi un riassunto
@purupuru #tokyotosho La libreria ha chiuso i battenti.
tl;dr
http://www.youtube.com/watch?v=Z0RS_we5oy0
In This Video: japanese studio aperto discovering the internet.
Appena visto in Germano.
Voalletto. :ciaociao:
adieu :ciaociao:
il problema è avere avuto a che fare, in qualsiasi modo, con ambienti di sviluppo. non avendo mai programmato in prima persona, diventa un po' difficile dare una risposta così a naso
dovrei leggermi la documentazione, ma già ho poco tempo di mio... :bua:
ohayo :snob:
la domanda era diretta non alla programmazione o di design ma alle risorse così come consumate realmente a runtime, ed è una cosa molto diversa; chi programma oggi - se non in condizioni estreme e particolari - non può più essere sicuro di controllare le risorse che usa, ad esempio per librerie e componenti deve trovare riscontri osservando il comportamento reale, ed in genere non ha occasione di farlo per vari motivi.
le applicazioni web sono tutt'altro che leggere, e comunque la piattaforma così come è oggi fa cacà :asd: .
uhhhuuu un ... bah penso una merla ha appena trovato riparo dalla neve sul mio terrazzo :puchuuuu:
certo che pensare che una settimana fa stavo passeggiando sulla spiaggia :asd:
giorno
l'omino delle caldaie è in ritardo di 45' ed io mi sono svegliata alle 6:30 per sistemare casa :fag:
li avevo, ma non più; in ogni caso mi imbatto in questo tipo di considerazioni anche girellando su stackoverflow.com (è molto ben navigabile anche per tag) o wikipedia.
il sunto è: sono text-based e quindi cross platform; sono estesi e storicizzati quindi hanno un sacco di meccanismi che funzionano e sei sicuro che vadano; sono estendibili e quindi sono belli; sopratutto sono standard aperti e quindi bellissimi.
peccato che: per la parte di networking nascono come estensione di un protocollo che fra tutte le rfc esistenti è il meno adatto ad applicazioni complesse o che hanno restrizioni di tempo (http); che ci sono un sacco di sovrastrutture, talmente tante che a rigore fatichi a leggere la documentazione quanto ad usarle. che gli standard text based non sono una risposta a tutte le domande del mondo. che l'xml è mortalmente verboso (non a caso si è tornati "indietro" al json; e persino il w3c ha sintassi alternative per certi scopi, vedi le ontologie) che le rfc pre-w3c erano notevolmente più snelle e coprivano una casistica di esigenze più ampia.
se giri un pò su wikipedia vedrai che ci sono diversi tentativi - ad esempio - di avere un corrispondente binario di xml; i proposal guidati dal w3c od aderenti ad xml tendono ad arrancare, alla fine quel poco che funziona sono implementazioni custom e quindi "non benedette" da w3c, vedi protocol buffers, bson, e ... link collegati.
più che altro a me interesserebbe trovare un link che fosse uno che mi spiega perchè è "informaticamente corretto e pulito e più standard" cercare di fare tutto su un protocollo che è l'ennesima riproposizione di una remote procedure call ed è nato per gli ipertesti. perchè io una ragione valida non la trovo :mad:
...i comitati non hanno quasi mai funzionato....
dio mioooooooo, quanto mi fa il culettoooooooooo!!!!!!!!!!!!!!!!