Corea, film online prima ancora che su DVD

Warner Bros. le prova tutte. Parla di pirateria rampante nel paese della banda larga e tenta di venire incontro alle voglie di beni elettronici degli utenti giocando d'anticipo

Roma – Andare incontro ai desideri degli utenti o, quantomeno, rendersi conto che il mondo è mutato, il mercato è cambiato e che in paesi come la Corea del Sud la banda larga la fa da padrona: c’è tutto questo dietro la decisione di uno dei maggiori studios di Hollywood, Warner Bros., di rilasciare nel paese i propri film su Internet prima ancora di diffonderli sul supporto tradizionale, il DVD.

Per una major hollywoodiana si tratta naturalmente di una rivoluzione culturale ma è una innovazione legata al tentativo di arginare la pirateria . I dirigenti dell’azienda ammettono che la Corea del Sud è stata per lungo tempo un ottimo mercato per le proprie produzioni ma con l’esplosione del broad band le cose sono cambiate , i consumatori si sono sempre più spesso rivolti alla rete per trovare e scaricare i film di proprio interesse, per non parlare della diffusione epidemica di supporti masterizzati illegalmente, e ivi diffusi sul mercato nero.

In Corea, vuoi per i forti investimenti in fibra, vuoi per la particolare urbanizzazione del paese, la banda larga ha conosciuto soprattutto negli anni scorsi uno sviluppo fenomenale , che ha proiettato il paese tra i territori più innervati dalla rete veloce. Per Warner si tratta quindi di compiere un salto culturale che dia seguito ai già numerosi ripensamenti che la casa ha espresso in passato sul rapporto del cinema industriale con le nuove tecnologie della comunicazione.

La major, inoltre, in Asia sta accelerando: in Cina non si limita a perseguire l’illegalità , vera o presunta, ma tenta da tempo di arginare la pirateria rampante, ad esempio distribuendo DVD a prezzi stracciati .

A determinare il successo dell’iniziativa coreana saranno con ogni probabilità non solo i prezzi praticati sui file ma anche le tecnologie con cui verranno distribuiti . Se saranno blindati con lucchetti che ne impediscano una comoda fruizione, come succede spesso e volentieri con il DRM con cui si coccolano certi industriali dei contenuti, sarà per Warner ancora più difficile e complicato competere con i file che circolano liberamente in rete, ad esempio sui circuiti di scambio.

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

  • Stefano scrive:
    Ho qualche dubbio sulle percentuali
    Ho dei dubbi sinceri sulle percentuali di compatibilità tra le applicazioni esistenti .NET e Mono: credo che quelle compatibili al 100% siano di molto inferiori al 45%.Da dove viene questo dato, e in base a quale statistica i programmatori affermano che sia questa la situazione attuale ?
  • siffredi scrive:
    mono e autocad
    Ora che mono emula parti di dot net 3.5 sarà possibile far girare con Wine autocad??dopo posso saperne di piu'??grazie..
  • matteote scrive:
    non verra' messo in ubuntu 8.10
    come si vede da questo threadhttps://answers.launchpad.net/ubuntu/+source/mono/+question/44628non verra' messo in ubuntu 8.10 come si dice nell'articolo.
    • tuba scrive:
      Re: non verra' messo in ubuntu 8.10
      è però inclusa la versione 1.9.1 che è praticamente la beta della 2.0ai conti fatti è quasi identica
  • Shu scrive:
    Re: Perche' mono non e' libero
    - Scritto da: anonimo
    Leggiti le FAQ:
    Mono is a community project, and as such, we Magari ogni tanto leggi anche i pareri di chi non e` direttamente interessato:http://boycottnovell.com/2008/09/13/microsoft-admitted-mono-trap/Bye.
  • io si scrive:
    w linux
    http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItem&rd=1&item=260296926646
  • Senbee scrive:
    Python + Qt4
    Come da oggetto.Non è meglio usare Python con interfaccia grafica Qt4, invece di Mono e .NET? Funziona come Java (non è compilato né interpretato, è a bytecode), è facilissimo, potentissimo, ha una bella IDE e un bel designer in stile Visual Studio, e il programma lo scrivi dove vuoi che poi gira su qualsiasi piattaforma. E non ci sono problemi di interpretazioni varie su brevetti e roba legale.Lo chiedo a qualche esperto, non è una mia opinione, è solo un'impressione di un profano, quindi potrei tranquillamente sbagliarmi.
    • pabloski scrive:
      Re: Python + Qt4
      no Python è libero ed è un linguaggio molto più espressivo di C#gli manco solo una virtual machine ma ci stanno lavorando con l'aiuto di Google
      • pabloski scrive:
        Re: Python + Qt4
        no aspè, quando si parla di vm e bytecode allora stiamo implicando già l'uscita da un linguaggio compilatoe infatti quello che si vuole fare è creare un compilatore per Pythonin quel caso Python finirebbe per rendere quanto C#, Java, Visual Basic e Pascalstesso discorso valeva per PHP ad esempio, fino a che non c'erano i vari APC, eAccelerator, Zend optimizer era lentissimo, oggi di fatto è alla pari dei linguaggi compilati
        • Shu scrive:
          Re: Python + Qt4
          - Scritto da: pabloski
          e infatti quello che si vuole fare è creare un
          compilatore per
          Python

          in quel caso Python finirebbe per rendere quanto
          C#, Java, Visual Basic e
          PascalPurtroppo no. :)Per come e` fatto Python (altamente dinamico) un compilatore non migliorerebbe di molto le prestazioni, ma al massimo raddoppierebbe o triplicherebbe la velocita` degli eseguibili.E` il prezzo da pagare per avere dizionari che contengono qualsiasi cosa, per esempio, o per passare funzioni in giro come fossero oggetti.Croce e delizia del linguaggio. :)
          stesso discorso valeva per PHP ad esempio, fino a
          che non c'erano i vari APC, eAccelerator, Zend
          optimizer era lentissimo, oggi di fatto è alla
          pari dei linguaggi
          compilatiQuello di PHP è un problema diverso. APC e eAccelerator fanno quello che Python fa già di suo (i file .pyc): tengono una cache dei precompilati in bytecode.In pratica evitano che ad ogni pagina richiesta dal browser sia necessario ricompilare lo script.Accelerano di molto (anche 20-30 volte) proprio perché il bytecode PHP è già abbastanza veloce, ma è la fase di compilazione quella lenta.Bye.
          • 200 OK scrive:
            Re: Python + Qt4
            Se ho capito bene si sta parlando di compilazione JIT?Il codice C# è prestante perchè il suo bytecode è macinato già da un interprete JIT, e quindi convertendo direttamente il bytecode su istruzioni cpu dirette, le prestazioni sono molto più elevate (anche se inizialmente c'è una fase di "preparazione").Su Python esistono alcune soluzioni per JIT (es. Psycho se non erro) ma non sono di default.
          • pabloski scrive:
            Re: Python + Qt4
            a compile-time l'ottimizzazione si può fare, perchè i tipi dati sono notinel caso di una compilazione AOT si crea il problema che dici tu, problema che non si presenta invece nemmeno in caso di compilazione JITquello che fanno APC e eAccelerator per PHP si può con Python a patto di mettere in cache un certo numero di versioni dell'eseguibile
      • di passaggio scrive:
        Re: Python + Qt4
        ciao.scusa, che intendi per "espressivo?"
        • pabloski scrive:
          Re: Python + Qt4
          - Scritto da: di passaggio
          ciao.
          scusa, che intendi per "espressivo?"l'espressività nei linguaggi si riferisce alla capacità del linguaggio di esprimere una serie di azioni complesse con poche istruzioniper esempio il C ha la minor espressività in assoluto perchè le sue istruzioni sono di basso livelloPython per esempio supporta i dizionari che ti permettono di gestire una lista di oggetti accessibili tramite hash....per implementare un dizionario in un linguaggio come il C ci vogliono svariate centinaia di righe di codicementre in python lo usi cosìa = {}a['pippo'] = 'cane stupido'a['pluto'] = 'cane scemo'a['topolino'] = 'furbacchione'si nota la facilità e la leggibilità no !?!ecco questo si intende per espressività....Python è il più espressivo tra i linguaggi, quindi contiene un mucchio di astrazione di alto livello ( tuple, sequenze, dizionari, shelve, ecc... )è chiaro che con un linguaggio del genere puoi scrivere con poco istruzioni software molto complesso ed inoltre il codice rimane leggibile e ordinato
          • 200 OK scrive:
            Re: Python + Qt4
            Un'altro linguaggio molto espressivo è il C# con LINQ. Ha un livello di astrazione molto elevato riguardo all'interrogazione dei dati e la gestione.In pratica è stata miscelata la sintassi SQL con il linguaggio (usando funzioni lambda/anonime e altre peculiarità aggiunte apposta) in modo che tutto il lavoro dietro di conversione e di adattamento la fà già il compilatore.Un esempio: string[] words = { "cherry", "apple", "blueberry" }; // Variabile anonima che contiene già la struttura dei comandi simil-SQL var sortedWords = from w in words orderby w select w;// visualizzo tutti gli elementi foreach (var w in sortedWords) { Console.WriteLine(w); }-----------------------------------------------------------Modificato dall' autore il 07 ottobre 2008 16.57-----------------------------------------------------------
          • di passaggio scrive:
            Re: Python + Qt4
            capito cosa intendevi...beh nn avevo mai sentito chiamare il concetto espresso "espressività"... a dir il vero sapevo il concetto, ma nn che avesse un termine preciso per indicarlo :-)sì, difatti odio i linguaggi come il c :-Pperò i linguaggi troppo astratti risultano complicati x altri aspetti... ci vuole una giusta via di mezzo :-)IMHO
          • pabloski scrive:
            Re: Python + Qt4
            dipende dalla complessità dei progetti da realizzaresiamo realisti, se stai implementando un nuovo algoritmo di apprendimento per reti neurali, devi restare concentrato sull'algoritmo, non correre dietro ai bug o alle migliaia di righe di codice necessarie solo per fare l'update dei pesi sinaptici
          • di passaggio scrive:
            Re: Python + Qt4
            - Scritto da: pabloski
            dipende dalla complessità dei progetti da
            realizzareprobabile

            siamo realisti, se stai implementando un nuovo
            algoritmo di apprendimento per reti neurali, robaccia IMHO :-P
            devi
            restare concentrato sull'algoritmo, non correre
            dietro ai bug o alle migliaia di righe di codice
            necessarie solo per fare l'update dei pesi
            sinapticisì qndi sono linguaggi tipo Prolog, Lisp ecc che servono in ambiti di ricerca? :-)ironie a parte personalmente sn per l'informatica più concreta... ovvio che c'è (e ci deve essere) anche il resto.
          • pabloski scrive:
            Re: Python + Qt4
            ma sei tu lavori in un contesto in cui il tempo di sviluppo è un elemento fondamentale non puoi metterti dietro a C++ a caccia di bugil linguaggio più usato nel mondo? PHPperchè secondo te?
      • Old8088 scrive:
        Re: Python + Qt4
        Sinceramente, C++ con le QT non mi piace per niente. Avevo dato un'occhiata tempo fa, (quindi non ne so molto sull'argomento QT), ma quando ho visto che richiede un C- preprocessor specifico solo per lo sviluppo di interfaccie GUI, me ne sono stato molto alla larga. Non e' una soluzione elegante, per niente.Sono dell' avviso che se uno sceglie C++ per fare sviluppo GUI, o impara a digerirsi le osticita' del linguaggio ( e non c'e' niente di male ), o forse fa bene a scegliere un'altro linguaggio.C++, non e' il linguaggio piu' adatto per 'fregnacce' gui. per quest'ultime non sono richieste neppure prestazioni.Utilizzare C++ per sviluppare GUI e' come andare a far la spesa con una testarossa.Just my two cents.
        • 200 OK scrive:
          Re: Python + Qt4
          Il c++ avrà diverse peculiarità e certamente è rapido.Ma a livello di sintassi, è orrenda in confronto alle soluzioni moderne di oggi. A sto punto preferisco avere una soluzione Python + C per le parti critiche.Secondo me il C++ tiene testa per il codice legacy che gira ancora, e per le conoscenze acquisite in molte ditte.Ma per nuovi progetti meglio vedere altro...-----------------------------------------------------------Modificato dall' autore il 07 ottobre 2008 16.52-----------------------------------------------------------
          • Old8088 scrive:
            Re: Python + Qt4
            Modificato dall' autore il 07 ottobre 2008 16.52
            --------------------------------------------------Se gli ambiti applicativi sono differenti da quelli da me elencati, sicuramente non vale la pena di sviluppare in C++.Questo intendevo quando ho scritto 'e' come andare a fare la spesa con una testarossa'.Semplicemente non e' l'auto adatta per andare a fare la spesa. Fara' anche i 300 all'ora, ma per fare la spesa mi serve solo un vano bagagli capiente. ;-)
          • 200 OK scrive:
            Re: Python + Qt4
            Uff mi aspettavo una risposta come: hai ragione, esiste un nuovo linguaggio che in 5 min ti fa tutto (rotfl) (scherzo ovviamente) 8)Però in effetti ho scritto senza conoscere veramente la situazione generale, ma prendendo spunto da alcune riflessioni che avevo fatto ai tempi (avevo usato per diversi anni c++, ma poi abbandonato per vari motivi).-----------------------------------------------------------Modificato dall' autore il 07 ottobre 2008 23.21-----------------------------------------------------------
          • Old8088 scrive:
            Re: Python + Qt4
            - Scritto da: 200 OK
            Uff mi aspettavo una risposta come: hai ragione,
            esiste un nuovo linguaggio che in 5 min ti fa
            tutto (rotfl) (scherzo ovviamente)
            8)Chi fa questi ragionamenti, in realta' non e' un professionista, e' uno smanettone. ;-) . Attualmente, devo dire quest'ultima categoria e' in rapido aumento, purtroppo.Il liguaggio panacea per tutti i mali non esite. Ogni linguaggio ha ambiti applicativi, anche se spesso questi ambiti tuttavia si sovrappongono...
          • 200 OK scrive:
            Re: Python + Qt4
            Sono uno smanettone (rotfl) argh
          • Old8088 scrive:
            Re: Python + Qt4
            - Scritto da: 200 OK
            Sono uno smanettone (rotfl) arghDa cio' che hai detto prima direi di no....
          • 200 OK scrive:
            Re: Python + Qt4
            (ok sono OT forse) per vari motivi :'( non lavoro nel campo dell'IT, ma ho sempre avuto passione, e seguo molto volentieri quello che succede. Ho avuto occasione di sperimentare diversi linguaggi e tecnologie, ma mai avuto l'arroganza di aver ragione a tutti i costi su un argomento.Dopotutto si impara sempre qualcosa di nuovo, e qui su PI a volte vedo i miei limiti dovuto alla mancanza di vera esperienza lavorativa.Una cosa però è certa, troppa gente alle prime armi si crede grande nell'informatica e si generano i cosidetti "fanatici", che parlano volendo aver sempre ragione e non guardando in faccia i fatti, e questo è triste.Vabbè sono stato OT, ma mi sentivo particolarmente ispirato... boh (rotfl)
    • tuba scrive:
      Re: Python + Qt4
      il punto è che mono è si compilato in bytecode ma poi quest'ultimo non viene interpretato come fa pythonviene compilato in tempo reale in codice nativo e quindi l'esecuzione è davvero velocepython lo vedo più per fare piccole applicazioni tipo configuratori, gestionali o comunque solo interfacce, il cui motore gira in c++ o comunque qualcosa di più performantediciamo che non scriverei mai un player multimediale in python, sarebbe davvero pesantuccio(qualcuno ha detto elisa?)invece un programma tipo banshee è comunque responsivo e veloceps meno male che c'è gente vhe vuole discutere in civiltà e non solo troll ;)
      • Shu scrive:
        Re: Python + Qt4
        - Scritto da: tuba
        diciamo che non scriverei mai un player
        multimediale in python, sarebbe davvero
        pesantuccio(qualcuno ha detto
        elisa?)
        invece un programma tipo banshee è comunque
        responsivo e
        veloceElisa e` lento perche` non hai l'accelerazione 3D attiva, presumo, perche` a me e` molto fluido.A parte questo, in Python usi librerie compilate per i compiti pesanti (decoding audio/video, grafica 3D, analisi numerica, ecc.)In Python e` scritto anche Frets On Fire (gioco alla Guitar Hero), Deluge (client Bittorrent), Decibel (player audio) e parecchia altra roba. E` un ottimo linguaggio, basta sapere per cosa usarlo e conoscerne i limiti.Bye.
        • tuba scrive:
          Re: Python + Qt4
          con accelerazione 3d attiva intendi la stessa che fa girare compiz p un altro compositor? allora sì ce l'ho, nvidia 7950 docetnaturalmente basta saperlo usare però ho detto solo che personalmente non ci farei mai un player(exaile a me va molto più lento di rhythmbox, cosa normale, ma anche di banshee)
          • 200 OK scrive:
            Re: Python + Qt4
            Puoi fare la gui in Python, ma poi il codice di decodifica in C.Le prestazioni dovrebbero essere elevate, ma con i vantaggi di poter programmare il resto e la gui in modo molto migliore.
          • tuba scrive:
            Re: Python + Qt4
            veroio però preferisco usare lo stesso linguaggio per tutto il progettoquestioni di comodità strutturale da programmatore ;)
          • 200 OK scrive:
            Re: Python + Qt4
            E non hai tutti i torti (rotfl)Eh, dipende ormai dal progetto e da altre cose.Finchè si tratta di parole è facile, lo so (ghost)...
      • pabloski scrive:
        Re: Python + Qt4
        infatti, del resto è il problema di tutti i linguaggi interpretatiquello che stanno facendo è creare un compilatore per Python che converta i sorgenti in bytecode che poi verranno compilati in codice nativo all'esecuzionee di fatto IronPython fa proprio questo, compila i sorgenti Python nel bytecode .NET....a quel punto l'eseguibile è come tutti gli altri eseguibili .NET dal punto di vista delle prestazioni
        • tuba scrive:
          Re: Python + Qt4
          il punto è che finirebbe comunque sotto il gruppo di applicazioni "mono" e quindi non cambierebbe niente per chi attacca mono con la questione dei brevettisarebbe "solo" un linguaggio in più da aggiungere ai vari c#, vb, vala, ilasm eccecc
          • pabloski scrive:
            Re: Python + Qt4
            - Scritto da: tuba
            il punto è che finirebbe comunque sotto il gruppo
            di applicazioni "mono" e quindi non cambierebbe
            niente per chi attacca mono con la questione dei
            brevetti

            sarebbe "solo" un linguaggio in più da aggiungere
            ai vari c#, vb, vala, ilasm
            ecceccno no il compilatore Python è Parrot e non ha nulla a che vedere con .NET e Mono
      • ... scrive:
        Re: Python + Qt4
        che ne pensi di ruby?
    • Shu scrive:
      Re: Python + Qt4
      - Scritto da: Senbee
      Come da oggetto.

      Non è meglio usare Python con interfaccia grafica
      Qt4, invece di Mono e .NET?Ancora meglio Vala (o Genie, che è la stessa cosa).Lo programmi in un linguaggio simile a C# (o a Python, per Genie), ma viene tradotto in C e quindi compilato.Hai la facilità di programmazione di C# o di Python, con le prestazioni del C.Non è ancora uscito dalla "beta", ma già ora è un ottimo linguaggio, e viene già usato da molti (openmoko terminal, per esempio, ma stanno anche riscrivendo Cheese da Mono a Vala).Bye.
    • Ganzo scrive:
      Re: Python + Qt4
      - Scritto da: Senbee
      Come da oggetto.

      Non è meglio usare Python con interfaccia grafica
      Qt4, invece di Mono e .NET?La licenzia di qt4 ti costringe a usare alla licenza gpl o se non vuoi la gpl devi pagare cifre astrognomiche.
  • FDG scrive:
    Mi chiedo
    All'epoca Mono rappresentò un'implementazione libera di runtime, linguaggi e librerie portabili. Ora però, con OpenJDK GPL, perché si dovrebbe scegliere quello che è un'implementazione più povera, meno aggiornata, quindi incompatibile, di .NET? Mi chiedo non conviene di più investire tempo, ed anche denaro, su una piattaforma più matura e più supportata? Cioè, secondo me se ci fosse stato OpenJDK all'epoca, Mono manco sarebbe nato.
    • Olmo scrive:
      Re: Mi chiedo

      Mi chiedo non
      conviene di più investire tempo, ed anche denaro,
      su una piattaforma più matura e più supportata?
      Cioè, secondo me se ci fosse stato OpenJDK
      all'epoca, Mono manco sarebbe
      nato.Probabilmente.Ma, una cosa non capisco del tuo discorso: ritieni che .NET/Mono e Java/OpenJDK siano mutualmente escludentisi? Perché?
      • FDG scrive:
        Re: Mi chiedo
        - Scritto da: Olmo
        Probabilmente.
        Ma, una cosa non capisco del tuo discorso:
        ritieni che .NET/Mono e Java/OpenJDK siano
        mutualmente escludentisi?
        Perché?Non so. Vorrei appunto capire per quali ragioni si dovrebbe preferire Mono al posto di OpenJDK.
        • mrlucky68 scrive:
          Re: Mi chiedo
          in se le tecnologie sono equivalenti (al di la della stabilità dovuta alla diversa anzianità dei prodotti).sono i tools di sviluppo a fare la differenzalo sviluppo di un applicazione desktop in windows con visual studio è anni luce avanti qualsiasi altro RAD (questione di tempo e soldi, non di qualità delle persone dell'open source)quindi se mono mantenesse le sue promesse, non ci fossero gabole legati etc etc, se sviluppo di app desktop in .NET su windows avrei un vantaggio competitivo (in costi) rispetto lo sviluppo in java a quasi parità di piattaforme supportate.perchè è vero che java va tu tantissime piattaforme. ma è anche vero che la maggiorparte degli app desktop va su client ad archittura intel. rimane fuori mac, ma è un problema di tempo anche per quello visto che l'architettura hw è ora la stessa.questo in teoria.in pratica - a oggi - lo sviluppo di app desktop ha senso solo se potessi raggiungere le piattaforme windows e mac in colpo solo. in quel caso il vantaggio competitivo sarebbe significativo. ma questo lo vedo difficile.
  • FDG scrive:
    Re: Perche' mono non e' libero
    - Scritto da: anonimo
    ...se viene scoperto qualcosa
    nel loro codice che è coperto da brevetto cercano
    un workaround o lo tolgono.Ok, nel frattempo io dovrei pagare royalties a MS (quello che fa con accordi tipo novell) sperando che il brevetto sia facilmente aggirabile.
    Vabbe' lasciamo stare il resto che è una perdita
    di tempo, meno male che erano
    oggettive.No, assolutamente, non lasciamo perdere. Cioè, uno dovrebbe affidarsi ad un'implementazione incompleta, incompatibilie e meno evoluta di .NET e del suo framework? Va bene per farci applicazioni open su Gnome, ma non per orientare investimenti aziendali. Piuttosto, meglio affidarsi a Microsoft. Certo, poi te la devi sposare con contratto matrimoniale con penali, e te la devi subire in toto, ma almeno hai veramente la tecnologia che hai scelto di adottare.
  • davidsual scrive:
    A me sembra che la strada si lunga
    Mi sembra che la strada per raggiungere il framework .net da parte di Mono sia ancora lunga.Il 3.5, non introduce sono c# 3.0 ma diversi namespace(librerie) molto importanti non riducibili al solo linq)WCF cambia in modo RADICALE il modo d interoperabilità tra le varie applicazioni.WPF è un radicale cambiamento sulla presentation con l'introduzione di XAML e della grafica vettoriale. Ricordo che con lo stesso XAML si realizza la grafica dal web al client/server al mobile, un unico modo per scrivere presentation.Silverlight è un'estensione.. ricordo che la 1.0 si basa per quanto riguarda la logica di presentation e gestione degli eventi su JAVASCRIPT (quindi UNMANAGED!!!!) Mentre dalla versione 1.1 il "Code-Behind" è un linguaggio supportato dal framework, quindi compilato e MANAGED una differenza abissale.Ricordo che il framework net genera codice NATIVO custom sulla macchina sulla quale viene compilato (quindi ottimizza il codice a seconda della macchina su cui viene generato a differenza di VB6 che generava del codice indipendente dall'hardware della macchina).E poi è da vedere la gestione della memoria dalla versione 1.1 alle 3.5 ci sono stati radicali cambiamenti sulla gestione della memoria (managed heap/stack) da parte del framework..Cmq sono interessato a vedere gli sviluppi
    • Olmo scrive:
      Re: A me sembra che la strada si lunga
      Dal momento che, a quanto pare, tra i partecipanti di questo forum sembri quello che ha più diretta conoscenza di .NET e delle ultime specifiche, mi piacerebbe chiederti un parere. Anzi, due:- a tuo avviso, vale ancora la pena di utilizzare NHibernate o LINQ lo rende obsoleto?- Quale consiglio per un ORM che permetta le invocazioni remote di oggetti persistenti? Ho trovato qualche soluzione con NHibernate: tu sai se è più agile con LINQ?Grazie!
      • davidsual scrive:
        Re: A me sembra che la strada si lunga
        - Scritto da: Olmo
        Dal momento che, a quanto pare, tra i
        partecipanti di questo forum sembri quello che ha
        più diretta conoscenza di .NET e delle ultime
        specifiche, mi piacerebbe chiederti un parere.
        Anzi,
        due:

        - a tuo avviso, vale ancora la pena di utilizzare
        NHibernate o LINQ lo rende
        obsoleto?
        - Quale consiglio per un ORM che permetta le
        invocazioni remote di oggetti persistenti? Ho
        trovato qualche soluzione con NHibernate: tu sai
        se è più agile con
        LINQ?

        Grazie!Linq a mio parere è la "copia"(Rivista e ottimizzata da Microsoft) di NHibernate sviluppato sull'onda di Hibernate x java.A mio parere se si utilizza il framework 3.5 abbandonerei NHibernate per utilizzare Linq (io personalmente non amo mischiare al framework net librerie di terze parti).Conta che Linq non è solo query su database ma è un modo per ottenere il "DATO" da qualsiasi fonte dati (DB, XML, Entity) quindi fossi in te mi farei un wrapper utilizzando i generic type che a seconda che gli passi un oggetto di business (Entity) o un xml o un database linq recupera il dato.Conta che Linq in definitiva non è che una libreria che ti semplifica l'accesso al dato togliendoti tutto il "lavoro sporco".Conta anche che linq si accoppia bene ad altre due novità..Entity Framework (ovvero dato un database e le sue tabelle...viene generato in automatico e senza una riga di codice le classi che le rappresentano con le CRUD "create,read,update,delete") e ASTORIA, ovvero "senza una riga di codice" queste classi (entity) vengono esposti a servizi (web).Linq, quindi è un rifacimento esteso di quello che è hibernate
        • Olmo scrive:
          Re: A me sembra che la strada si lunga
          Ok.Grazie mille.Adesso approfondisco la questione LINQ vs NHibernate.PS. Per le invocazioni di oggetti business remoti e persistiti (da LINQ o da NHibernate) ne sai nulla? Quello che mi piacerebbe molto riuscire ad ottenere è un client che possa utilizzare oggetti business residenti su un server (che li persiste con LINQ o con NHibernate) ed avere al contempo il vantaggio di un caricamento lazy. Tu hai dritte da darmi?
          • Olmo scrive:
            Re: A me sembra che la strada si lunga
            PS2: delle caratteristiche che mi hai elencato (compreso il code generation) AFAIK NHibernate già le fornisce...
          • davidsual scrive:
            Re: A me sembra che la strada si lunga
            - Scritto da: Olmo
            PS2: delle caratteristiche che mi hai elencato
            (compreso il code generation) AFAIK NHibernate
            già le
            fornisce...Volevo solo aggiungere che per utilizzare Linq e penso tu lo sappia visto che utilizzi NHibernate ci vuol un DOM molto ben fatto e competenza.Ahimè nelle varie consulenze che faccio trovo già molto difficile far digerire il concetto di Entity quindi senza una bella pianificazione delle classi ho visto che linq o penso anche hibernate diventa un rischio progettuale piuttosto che un valore aggiunto.
        • manue scrive:
          Re: A me sembra che la strada si lunga
          perchè linq è inferiore anni luce a (n)hibernatehttp://blogs.ugidotnet.org/janky/archive/2007/08/27/87979.aspxin giro si trovano anche tabelle di comparazione più aggiornate
          • davidsual scrive:
            Re: A me sembra che la strada si lunga
            - Scritto da: manue
            perchè linq è inferiore anni luce a (n)hibernate

            http://blogs.ugidotnet.org/janky/archive/2007/08/2

            in giro si trovano anche tabelle di comparazione
            più
            aggiornateConta che l'articolo è stato redatto lunedì 27 agosto 2007 22.35 Sono usciti service pack etc etc.. sarebbe bello se fosse aggiornata all'ultima release del framework
  • xxxxxxxxxx scrive:
    ...
    Ti propongo anche questo articolo:
    • xxxxxxxxxx scrive:
      Re: ...

      Idem.
      Mi sembra un post pieno di inesattezze,
      ideologismi e poco, poco contenuto
      tecnico.
      Sorry, sono sincero :)Avresti da propormi qualche articolo piu' tecnico,con pochi ideologismi e piu' preciso che tratti,oltre che della bonta' tecnica di mono (prestazioni,produttivita'), anche i problemi di licenza,proprieta' intellettuale e rischi di lock-in futuri conMicrosoft?
      • Olmo scrive:
        Re: ...

        Avresti da propormi qualche articolo piu' tecnico,Senz'altro.Con la premessa che la storia dei brevetti *e'* un grosso problema per il progetto Mono, ma grosso davvero, posso suggerirti di leggere le riflessioni di Icaza stessohttp://tirania.org/blog/archive/2006/Nov-04.htmlun'intervista a Stallman sull'argomento:http://fsfeurope.org/documents/rms-fs-2006-03-09.en.html#q1Chiaramente i due hanno visioni diametralmente opposte. Ma entrambi argomentano molto approfonditamente.Ciao
        • xxxxxxxxxx scrive:
          Re: ...

          Chiaramente i due hanno visioni diametralmente
          opposte. Ma entrambi argomentano molto
          approfonditamente.
          CiaoGrazie, bisogna sempre sentire tutte le campanee ancor meglio sarebbe andare nel dettagliocon le proprie mani anche se spesso manca il tempo...
    • bah scrive:
      Re: ...
      Sarà anche solo un insegnante di lingue, come pure uno con una certa antipatia per mono, ma è anche vero che è un grande appassionato del mondo linux, si documenta, cerca di informare e stimolare chi legge. Spesso ha idee "forti", magari radicali, ma in tutto questo tempo ha sempre tenuto il suo blog aperto, non moderato... se ha tanto seguito, tante persone consultano il suo blog, forse non è un totale cretino fazioso!
  • Olmo scrive:
    Re: Perche' mono non e' libero
    Molte cose non corrette, non aggiornate e platealmente errate. Post piuttosto inutile, IMHO.
  • Funz scrive:
    Uso Linux e vivo felice senza Mono
    Posso anche fare a mento di paint.net (rotfl)(e di beagle e di fspot, ci sono tante alternative senza mono)Inoltre mi sembra che il 45% delle applicazioni .net funzionanti sia un po' pochino per giustificare 'sti trionfalismi...
    • Guido scrive:
      Re: Uso Linux e vivo felice senza Mono
      - Scritto da: Funz
      Posso anche fare a mento di paint.net Grazie al pero disse il melo.E' evidente che ognuno di noi quando opera da utente finale vive anche senza Mono.Cosi' come vive anche senza Java. Basta che qualcuno ci dia i programmi che ci servono... che siano in C/Java/C#/Php/Python chissene. Tanto se funziona nel 99% dei casi non dovrai mettere mano al codice.(Firefox funziona e lo uso ma non per questo ho mai scaricato il codice di firefox).Queste sono notizie che interessano principalmente agli sviluppatori, che cosi' hanno piu' alternative.
      Inoltre mi sembra che il 45% delle applicazioni
      .net funzionanti sia un po' pochino per giustificare 'sti
      trionfalismi...Per ora concordo! Se anche fosse il 60%... bisogna vedere quali funzionalita' ricadono in quel 60%. Di LINQ non me ne faccio una cippa se ho dei bug delle Winform o altre parti che mi obbliano a riscrivere l'appliazione per girarci attorno.
    • di passaggio scrive:
      Re: Uso Linux e vivo felice senza Mono
      mamma mia che trollata
      • Funz scrive:
        Re: Uso Linux e vivo felice senza Mono
        - Scritto da: di passaggio
        mamma mia che trollataTroll sarai tu, ho semplicemente detto che non uso mono. Non mi piace l'idea di dover sempre rincorrere Microsoft e i suoi prodotti, e Mono sarà sempre indietro per forza di cose.Non sono necessari nemmeno i programmi che girano su .net e/o mono, ci sono molte alternative valide.
        • di passaggio scrive:
          Re: Uso Linux e vivo felice senza Mono
          - Scritto da: Funz
          - Scritto da: di passaggio

          mamma mia che trollata

          Troll sarai tu, ho semplicemente detto che non
          uso mono.CITAZIONE:"Posso anche fare a mento di paint.net (e di beagle e di fspot, ci sono tante alternative senza mono)Inoltre mi sembra che il 45% delle applicazioni .net funzionanti sia un po' pochino per giustificare 'sti trionfalismi..." nn mi pare proprio uguale uguale

          Non mi piace l'idea di dover sempre rincorrere
          Microsoft e i suoi prodotti, e Mono sarà sempre
          indietro per forza di
          cose.
          Non sono necessari nemmeno i programmi che girano
          su .net e/o mono, ci sono molte alternative
          valide.
  • Dr. House scrive:
    Pericolo licenze
    Non mi esprimo sulla bontà tecnica del framework, ma se da un lato si guadagna in interoperabilità dall'altro si crea una pericolosa dipendenza da microsoft che ha in ogni momento la possibilità di modificare le licenze delle sue tecnologie, rendendo monco mono al momento opportuno, sarò paranoico io, ma trovo che sviluppare mono sia l'equivalente di guidare bendati.
    • 200 OK scrive:
      Re: Pericolo licenze
      In effetti se sviluppassi su .NET penserei solo a Windows.Altrimenti è una situazione comunque "strana", non mi convince.
    • anonimo scrive:
      Re: Pericolo licenze
      - Scritto da: Dr. House
      Non mi esprimo sulla bontà tecnica del framework,
      ma se da un lato si guadagna in interoperabilità
      dall'altro si crea una pericolosa dipendenza da
      microsoft che ha in ogni momento la possibilità
      di modificare le licenze delle sue tecnologieAnche se MS le modifica i programmi mono mica smettono di andare o smettono di essere sviluppati, né diventano illegali.
      • pabloski scrive:
        Re: Pericolo licenze
        diventa illegale Mono e non puoi più far girare le tue preziose applicazioni .NET su sistemi non MS
  • tuba scrive:
    interoperabilità
    ben vengano implementazioni opensource di standard(che poi siano ecma è un altro conto, ma tanto con l'aria che gira in iso non è che cambi poi molto) documentati in modo da garantire il funzionamento di un programma da windows a linux ad osxper tutti quelli che dicono che "java è meglio di c#": io non sono un detrattore nè di uno nè dell'altro, se si dice che uno è meglio allora bisogna spiegare in che situazioni(la relatività... chissà mai che si capisca che non esiste l'assoluto) e con prove documentate
    • 200 OK scrive:
      Re: interoperabilità
      In C# 3.0 poi con l'aggiunta di LINQ, la gestione dei dati è diventata davvero un'operazione comoda!In pratica la sintassi è simil-sql, ma non è una stringa da passare ad una funzione con dentro i comandi, è proprio parte del linguaggio. Questo permette quindi di avere anche già un controllo dei tipi di variabile. L'ide però di VS in questo ambito aiuta tantissimo perchè quando si crea una variabile generica che contiene una tabella di un db, automaticamente appare l'elenco di tutti i campi.Tra l'altro il meccanismo ha una sintassi simile sia se usato con SQL, XML o oggetti in memoria.Poi ci sono pro e contro a dipendenza del linguaggio, ma certamente il LINQ è qualcosa di innovativo e comodo.
      • gerry scrive:
        Re: interoperabilità
        - Scritto da: 200 OK
        Poi ci sono pro e contro a dipendenza del
        linguaggio, ma certamente il LINQ è qualcosa di
        innovativo e
        comodo.Cosa server per farlo girare?Solo un interfaccia ADO standard per il DB in questione?
        • 200 OK scrive:
          Re: interoperabilità
          No. ADO non è necessario (difatti una novità è proprio non più appoggiarsi solo a questo). Puoi installare 2MB di librerie per gestire un db sql in locale.Però prendi con le pinze quanto ho detto, ci vorrebbe qualcuno che lo utilizzi normalmente per confermare o smentire quanto sopra.-----------------------------------------------------------Modificato dall' autore il 07 ottobre 2008 10.33-----------------------------------------------------------
          • gerry scrive:
            Re: interoperabilità
            - Scritto da: 200 OK
            No. ADO non è necessario (difatti una novità è
            proprio non più appoggiarsi solo a questo). Puoi
            installare 2MB di librerie per gestire un db sql
            in
            locale.Beh, scusa, come poi interrogare il DB mica se lo può immaginare, suppongo che ci sarà un wrapper da qualche parte, no?
          • 200 OK scrive:
            Re: interoperabilità
            Il linguaggio genera del codice utilizzabile poi da liberie di diverso tipo, a dipendenza di che tipo di dati vuoi accedere.Puoi accedere a dati ADO.NET, oppure XML, oppure su SQL via "SQL Server Compact".Ma non sei certo obbligato a passare per ADO.NET
        • tuba scrive:
          Re: interoperabilità
          linq si divide in 4 filoni principalilinq to object, evidente la funzionelinq to sql, wrapper esclusivo per sql serverlinq to xml, evidentelinq to entities, qualunque altra roba. esiste anche linq to flickr ad esempio e uno si può creare il linq to mysql ad esempio
      • tuba scrive:
        Re: interoperabilità
        concordo assolutamente su linqè davvero comodo e penso di farne un largo uso in futuro
    • pabloski scrive:
      Re: interoperabilità
      il timore però riguarda la licenzail fatto che .NET sia uno standard ECMA non vuol dire che è libero, lo sarà solo finchè MS permetterà di usare le specifiche liberamentea mio avviso Mono è il cavallo di troia di MS nel mondo linuxnon so Novell quanto sia furba ( a giudicare dal passato non molto ) ma si è portata il nemico in casa.NET ha molti vantaggi tecnici, però esistono altre soluzioni ancora migliori e tuttavia snobbate...penso ad ANDF, LLVM, Smalltalk
      • 200 OK scrive:
        Re: interoperabilità
        (Nemico? Adesso ci sono i buoni e i cattivi? Non perdiamoci in ste cavolate, non servono discussioni e guerre di religione ma fatti. Si possono sempre inventare nuove idee e svilupparle, ma parlare di nemici e amici mi sembra un po' ridicolo).Smalltalk esiste da molto, se è stato poi snobbato in molti casi, un motivo ci sarà. (mica certi linguaggi poi hanno usato delle idee di smalltalk?)Poi un conto è veramente dare contro .NET, un'altro è parlare del linguaggio C#.E se si parla di .NET, sotto Linux mi dà l'idea che ci sono troppe dipendenze, ed è ancora molto macchinoso. Eppure ci sono alcuni programmi simpatici come Galaxium scritti in .NET. Qui però IMHO punterei Python... meno dipendenze e più facile da portare.
        • pippo scrive:
          Re: interoperabilità

          Poi un conto è veramente dare contro .NET,
          un'altro è parlare del linguaggio
          C#.

          E se si parla di .NET, sotto Linux mi dà l'idea
          che ci sono troppe dipendenze, ed è ancora molto
          macchinoso. Eppure ci sono alcuni programmi
          simpatici come Galaxium scritti in .NET. Qui però
          IMHO punterei Python... meno dipendenze e più
          facile da
          portare.Ci hanno già pensato:http://codeplex.com/ironpython
          • 200 OK scrive:
            Re: interoperabilità
            Qui però accedi a .NET tramite python.Ma le dipendenze da .NET rimangono...
          • pippo scrive:
            Re: interoperabilità

            Qui però accedi a .NET tramite python.

            Ma le dipendenze da .NET rimangono...Lo so, scherzavo ;)
        • 200 OK scrive:
          Re: interoperabilità
          Provocazione: :P Apple (Steve Jobs) ha copiato il concetto di GUI a Palo Alto dalla Xerox.
          • pabloski scrive:
            Re: interoperabilità
            eh non andò proprio cosìla Xerox cedette i diritti sulla GUI e sul mouse in cambio di azioni Apple, quindi non hanno copiato, hanno comprato
          • 200 OK scrive:
            Re: interoperabilità
            Buono a sapersi 8) cavolo, mi ero anche interessato ai tempi per vederci dietro, e mi è sfuggita sta cosa :$Meglio tardi che mai (rotfl)
        • Old8088 scrive:
          Re: interoperabilità

          per quanto riguarda Python, farà il botto quando
          sarà terminata l'implementazione di Parrot, a
          quel punto sarà possibile compilare i programmi
          Python e raggiungere velocità simili ai programmi
          in
          C/C++Quando ci riesci fammi sapere. ;-)
  • Anti .NETista scrive:
    .NET su Linux
    Perche` su Linux deve essere possibile girare tutto.Su Linux tutto e` possibile, su Win o Mac OS no.
    • deactive scrive:
      Re: .NET su Linux
      - Scritto da: Anti .NETista
      Perche` su Linux deve essere possibile girare
      tutto.
      Su Linux tutto e` possibile, su Win o Mac OS no.Bravo, ora ti senti meglio? sollevato ?
    • pabloski scrive:
      Re: .NET su Linux
      - Scritto da: Anti .NETista
      Perche` su Linux deve essere possibile girare
      tutto.
      Su Linux tutto e` possibile, su Win o Mac OS no.prega solo che il numero di applicazioni .NET su Linux non diventi mai la maggioranzain quel caso MS potrebbe ritirare le specifiche .NET e Mono dopo s'attaccasaremmo costretti a pagare MS per poter implementare le specifiche .NET su Linux
      • anonimo scrive:
        Re: .NET su Linux
        - Scritto da: pabloski
        in quel caso MS potrebbe ritirare le specifiche
        .NET e Mono dopo
        s'attaccaBeata ignoranza, a livello legale e tecnico quello che dici non vuol dire niente.
        • pabloski scrive:
          Re: .NET su Linux
          - Scritto da: anonimo
          - Scritto da: pabloski

          in quel caso MS potrebbe ritirare le specifiche

          .NET e Mono dopo

          s'attacca

          Beata ignoranza, a livello legale e tecnico
          quello che dici non vuol dire
          niente.Sun l'ha già fatto in passato con Java, che è stato proposto come standard ECMA, poi ritirato dalla stessa Sunil succo è che MS continua ad avere il sacrosanto diritto di chiudere le specifiche di .NET in ogni modo e impedire di qualsiasi tipo di implementazione 3rd partyè vero questo o non lo è? sei hai informazioni serie da riportare parla pure, altrimenti taci
          • pecos scrive:
            Re: .NET su Linux

            Sun l'ha già fatto in passato con Java, che è
            stato proposto come standard ECMA, poi ritirato
            dalla stessa
            Sun
            Sun ha ritirato le spec Java *prima* che diventassero uno standard ECMA
            il succo è che MS continua ad avere il sacrosanto
            diritto di chiudere le specifiche di .NET in ogni
            modo e impedire di qualsiasi tipo di
            implementazione 3rd
            party

            è vero questo o non lo è? sei hai informazioni
            serie da riportare parla pure, altrimenti
            taciNo, non è vero. C# ed il CLR sono degli standard ISO, quindi non sono di proprietà MS. Quello che MS, al limite, potrebbe fare consiste nell'estendere lo standard in modo incompatibile con lo stesso e sottoporre ad ISO la standardizzazione della nuova versione. Quella attuale, però, standard è e tale rimarrebbe
          • pabloski scrive:
            Re: .NET su Linux
            quindi se ho capito bene chiunque può implementare un compilatore c#, clr, cli, e il cli senza incorrere in problemi legali con MS?
          • pabloski scrive:
            Re: .NET su Linux
            aspè scusa un attimosiccome di brevetti e leggi non mi sono mai interessato, mi sto documentando un pochettino su questa cosaho visto che la CLI è sotto standard ECMA e ISO, però spulciando in rete ho visto anche che MS ne detiene i brevettie ECMA richiede solo l'aderenza al principio di "Reasonable and Non Discriminatory Licensing" dove si afferma che"Reasonable and Non Discriminatory Licensing (RAND) is a term for a type of licensing typically used during standardization processes. The normal case is that when joining the standardization body, companies agree that if they receive any patents on technologies which become essential to the standard then they agree to allow other groups attempting to implement the standard to use those patents and they agree that the charges for those patents shall be reasonable. "quindi è come dicevo io....un bel giorno MS può decidere che la pacchia delle implementazioni a gratis di .NET è finita e che da lì in poi chiunque voglia implementare il CLI ( necessario per qualsiasi implementazione di .NET ) deve pagare un tota quel punto Miguel de Icaza e Novell finiscono a 90°e lo stesso per progetti come Cosmoe o SharpOSin sostanza l'implementazione di .NET è libera solo perchè MS dà il permesso, ma può benissimo cambiare politica
          • October scrive:
            Re: .NET su Linux
            - Scritto da: pabloski
            quindi è come dicevo io....un bel giorno MS può
            decidere che la pacchia delle implementazioni a
            gratis di .NET è finita e che da lì in poi
            chiunque voglia implementare il CLI ( necessario
            per qualsiasi implementazione di .NET ) deve
            pagare un
            tot

            a quel punto Miguel de Icaza e Novell finiscono a
            90°Ma che cazzo dici (rotfl)(rotfl)(rotfl)(rotfl)
          • pabloski scrive:
            Re: .NET su Linux
            intendi dire che sono già a 90°?non lo sapevo mica :D
          • October scrive:
            Re: .NET su Linux
            - Scritto da: pabloski
            intendi dire che sono già a 90°?

            non lo sapevo mica :DStai tirando fuori cose vecchie di anni che sono state chiarite da Icaza sino alla nausea. La prossima volta anziché cercare in siti spazzatura alla Boycott Novell cerca di documentarti meglio e peccare di presunzione.
          • pabloski scrive:
            Re: .NET su Linux
            gnegne, questo tipo si è ammulito, ha fatto la sparata è stato bastonato e adesso tace :D
          • pabloski scrive:
            Re: .NET su Linux
            P.S. volevo dire ammutolito
  • Il Signor Rossi scrive:
    Ma perché .net su linux?
    Cavolo, c# è uno schifo, .net pure.Certo, sotto Windows è utile perché permette finalmente di gestire interfacce utente grafiche in modo semplice, e allo stesso tempo si integra bene con tutto l'esistente, dalle api win32 a com e via dicendo. Inoltre finalmente ha una libreria utilizzabile di classi. Quindi sotto Windows ha un senso, visto che le alternative poi si chiamano MFC o Win32. E' un grosso passo avanti.Ma quando lo togli da Windows e lo paragoni a Java, con la pulizia del design del linguaggio e delle librerie (paragonate a c#/.net), con il fatto che Java è multipiattaforma e con la sua potenza anche lato server la domanda sorge spontanea: CHE CAVOLO CE NE FACCIAMO DI UNA REIMPLEMENTAZIONE DI .NET SOTTO LINUX???
    • GGG scrive:
      Re: Ma perché .net su linux?
      - Scritto da: Il Signor Rossi

      Ma quando lo togli da Windows e lo paragoni a
      Java, con la pulizia del design del linguaggio e
      delle librerie (paragonate a c#/.net),Ah, beh... se lo dici tu...
      con il
      fatto che Java è multipiattaforma e con la sua
      potenza anche lato server la domanda sorge
      spontanea: CHE CAVOLO CE NE FACCIAMO DI UNA
      REIMPLEMENTAZIONE DI .NET SOTTO
      LINUX???Proprio per le applicazioni lato client.Intanto puoi fare una applicazione per il mercatowindows e trovartea buona anche per linux.E poi, checché se ne dica, svilppare applicazionicon interfaccia grafica sfruttando il RAD delVisual Studio è un altro mondo...-- GGG
      • rock3r scrive:
        Re: Ma perché .net su linux?
        vero. quoto tutto :)
      • Olmo scrive:
        Re: Ma perché .net su linux?

        E poi, checché se ne dica, svilppare applicazioni
        con interfaccia grafica sfruttando il RAD del
        Visual Studio è un altro mondo...non è vs, ma vale la pena di valutarlo:http://www.icsharpcode.net/OpenSource/SD/
        • Marcello Romani scrive:
          Re: Ma perché .net su linux?
          - Scritto da: Olmo

          E poi, checché se ne dica, svilppare
          applicazioni

          con interfaccia grafica sfruttando il RAD del

          Visual Studio è un altro mondo...


          non è vs, ma vale la pena di valutarlo:

          http://www.icsharpcode.net/OpenSource/SD/Grazie per la segnalazione!
      • Nemolog scrive:
        Re: Ma perché .net su linux?
        mi hai tolto le parole di bocca...
      • 8987 scrive:
        Re: Ma perché .net su linux?
        E' vero!
    • darksky scrive:
      Re: Ma perché .net su linux?
      - Scritto da: Il Signor Rossi
      Cavolo, c# è uno schifo, .net pure.
      Certo, sotto Windows è utile perché permette
      finalmente di gestire interfacce utente grafiche
      in modo semplice, e allo stesso tempo si integra
      bene con tutto l'esistente, dalle api win32 a com
      e via dicendo. Inoltre finalmente ha una libreria
      utilizzabile di classi. Quindi sotto Windows ha
      un senso, visto che le alternative poi si
      chiamano MFC o Win32. E' un grosso passo
      avanti.
      Ma quando lo togli da Windows e lo paragoni a
      Java, con la pulizia del design del linguaggio e
      delle librerie (paragonate a c#/.net), con il
      fatto che Java è multipiattaforma e con la sua
      potenza anche lato server la domanda sorge
      spontanea: CHE CAVOLO CE NE FACCIAMO DI UNA
      REIMPLEMENTAZIONE DI .NET SOTTO
      LINUX???detto da uno che programma in java che c# fa schifo è tutto dire, scusa ma se guardi il codice scritto in java è quasi del tutto simile a quello scritto in c#, da dedurre che se ti fa schifo c# poco ci manca anche per java.
      • Bakunin scrive:
        Re: Ma perché .net su linux?
        Ma uno che dice cose del genere non sa di cosa parla, mi sembra chiaro.
        • Olmo scrive:
          Re: Ma perché .net su linux?

          Ma uno che dice cose del genere non sa di cosa
          parla, mi sembra
          chiaro.Forse voleva solo trolleggiare.Peccato, mi sarebbe piaciuto uno scambio di opinioni. Io ho lavorato molto con C# e non ho una visione così negativa come la sua. Occasione sprecata, peccato.
      • Alex scrive:
        Re: Ma perché .net su linux?
        - Scritto da: darksky
        detto da uno che programma in java che c# fa
        schifo è tutto dire, scusa ma se guardi il codice
        scritto in java è quasi del tutto simile a quello
        scritto in c#, da dedurre che se ti fa schifo c#
        poco ci manca anche per java.Ma in realtà trovo il codice java meno leggibile di quello c# per via di un po' di zucchero sintattico (ma non è quello che deve fare un linguaggio? il resto è VM) come eventi, proprietà polimorfismo esplicito e rigoroso (in java è tutto virtual). Se il ragazzo avesse avuto una cognia dell'argomento poteva puntare su una feature che c# non ha rispetto a java, l'esplicitazione delle eccezioni nei metodi per esempio :D
    • fox82i scrive:
      Re: Ma perché .net su linux?
      Rispondo riportando un parte dell'articolo:"Con questa release, spero che Mono possa attrarre un bel po' di nuovi sviluppatori e di aziende che dipendono da MS.NET e desiderano migrare i loro sistemi verso Linux"
    • Olmo scrive:
      Re: Ma perché .net su linux?
      - Scritto da: Il Signor Rossi
      Cavolo, c# è uno schifo, .net pure.mi interessa sapere perché, a tuo parere, .net faccia schifo e per quali motivi tu giudichi tanto male c#, dal punto di vista tecnico, naturalmente
    • deactive scrive:
      Re: Ma perché .net su linux?
      - Scritto da: Il Signor Rossi
      Cavolo, c# è uno schifo, .net pure.
      Certo, sotto Windows è utile perché permette
      finalmente di gestire interfacce utente grafiche
      in modo semplice, e allo stesso tempo si integra
      bene con tutto l'esistente, dalle api win32 a com
      e via dicendo. Inoltre finalmente ha una libreria
      utilizzabile di classi. Quindi sotto Windows ha
      un senso, visto che le alternative poi si
      chiamano MFC o Win32. E' un grosso passo
      avanti.
      Ma quando lo togli da Windows e lo paragoni a
      Java, con la pulizia del design del linguaggio e
      delle librerie (paragonate a c#/.net), con il
      fatto che Java è multipiattaforma e con la sua
      potenza anche lato server la domanda sorge
      spontanea: CHE CAVOLO CE NE FACCIAMO DI UNA
      REIMPLEMENTAZIONE DI .NET SOTTO
      LINUX???certo che siete banali..."c# è uno schifo, .net pure."a parte che hai gia' sbagliato perche' si tratta di C#.NET e .NET da solo e' soltanto un framework su cui possono esser compilati diversi linguaggi. VB,C# , J# e visual C++.
      • ciko scrive:
        Re: Ma perché .net su linux?

        certo che siete banali...
        "c# è uno schifo, .net pure."

        a parte che hai gia' sbagliato perche' si tratta
        di C#.NET e .NET da solo e' soltanto un framework
        su cui possono esser compilati diversi linguaggi.
        VB,C# , J# e visual
        C++.e quindi in cosa ha sbagliato? ha detto c# (linguaggio) e' uno schifo, .net (il framework) pureopinabile come affermazione, ma non sbagliata
        • Olmo scrive:
          Re: Ma perché .net su linux?

          opinabile come affermazione, ma non sbagliataQuoto, hai ragione.Resta il fatto che, se non fornisce le sue motivazioni, la sua resta una chiacchera da bar.
    • Alessio Marziali scrive:
      Re: Ma perché .net su linux?
      Beato te che non capisci un cazzo.
    • Old8088 scrive:
      Re: Ma perché .net su linux?

      Ma quando lo togli da Windows e lo paragoni a
      Java, con la pulizia del design del linguaggio e
      delle librerie (paragonate a c#/.net), con ilPulizia del design delle librerie di JAVA?Ma se la maggior parte delle librerie di .NET sono una scopiazzatura di quelle di JSE? (Stesse classi e metodi, al massimo differenze lievi nei nomi).Sveglia!
  • HAL scrive:
    titolo obbligatorio
    Benvengano notizie del genere, chissà che l'interoperabilità ne guadagni
  • ILDISTRUGGI TORE scrive:
    NET non vale una s**a
    Miguel De Icaza è un'adepto di bill gaytzil suo scopo è quello di smerdare il cessoso desktop environment tamarrGNOMEcon tecnologie lock-in brevettate da Maicrosoft.Sciao
Chiudi i commenti