Tornando a parlare di Apple:

http://www.repubblica.it/2005/h/sezioni/scienza_e_tecnologia/brevipod/brevipod/brevipod.html

Nella battaglia per il brevetto dell'I-Pod
Apple perde il primo round con Gates

Microsoft però non sembra determinata a fare guerra alla concorrente. "In generale la nostra politica è quella di permettere ad altri di sfruttare i nostri brevetti per i loro prodotti", ha spiegato David Kaefer, direttore della proprietà intellettuale della Microsoft.

Questo la dice lunga sulle mire monopolistiche di bla bla bla...

e la dice lunga anche sui brevetti software

Tornando a parlare di Apple:

http://www.repubblica.it/2005/h/sezioni/scienza_e_tecnologia/brevipod/brevipod/brevipod.html

Nella battaglia per il brevetto dell'I-Pod
Apple perde il primo round con Gates

Microsoft però non sembra determinata a fare guerra alla concorrente. "In generale la nostra politica è quella di permettere ad altri di sfruttare i nostri brevetti per i loro prodotti", ha spiegato David Kaefer, direttore della proprietà intellettuale della Microsoft.

Questo la dice lunga sulle mire monopolistiche di bla bla bla...

"non sembra determinta" non significa che non lo sia :). Anche quell' "In generale" è un po controvertibile. Si parla di "cifre da capogiro" e quindi avere sottomano una rivale come Apple non può che far bene ;)
Correggerei la conclusione con "Questo non chiarisce nulla sulle mire monopolistiche di bla bla bla..."

A gia dimenticavo ... Repubblica non è proprio quello che si definisce un giornale imparziale.

Normale amministrazione: MS perse una causa poco meno di dieci anni fa, e fu costretta a "pagare" Apple. Adesso le posizioni si sono invertite. :p

Questo per quanto riguarda il tema: "puoi dire di conoscere .NET senza sapere quel nuovo linguaggio che si chiama C#?"

Puoi dire di conoscere GTK+ senza sapere C? Le WIndows Forms (e quindi un gran bel pezzo di .NET) sono scritte in C#, la maggiorparte dei tutorial sono scritti in C#. Per gli altri linguaggi sono dei semplici "wrapper" alle Windows Forms per portarle negli altri linguaggi.
Puoi benissimo leggere un tutorial sulle Windows Forms in Delphi cosi' come puoi leggere un tutorial sulle GTK+ in Tom. Ma senza conoscere il linguaggio nativo, non si coglie mai il "feeling" del toolkit che si sta usando. Quindi, C# non è legato da .NET, .NET non è legato da C#, ma un "programmatore .NET che non conosce C#" è come un programmatore "C++ che non conosce C". Poco credibile.

Non prendiamoci in giro. Come programmatore a me interessa soltanto l'interfaccia di un'API / classe, non l'implementazione: è un dettaglio trascurabile, che serve soltanto ad arricchire il proprio bagaglio culturale.

Se, come dici tu, è necessario conoscere il linguaggio con cui è stato scritto qualcosa per "coglierne il feeling", chi programma sarebbe costretto a conoscere il C# perché la maggior parte delle WinForms sono realizzate con questo linguaggio, C, C++ e assembly per tutto il resto. Da folli.

Mettiamo il caso che non ho mai imparato l'assembly perché ho usato soltanto funzioni scritte in C; domani un'API viene riscritta in assembly per questioni di efficienza: ho forse bisogno di imparare questo nuovo linguaggio soltanto per questo? Chiaro che no. E' venuto a mancare il "feeling"? Chiaro che no.

E' una cosa priva di senso...

L'implementazione di qualcosa è per natura stessa soggetta a cambiamenti, anche profondi, ma non per questo bisogna stravolgere la modalità di fruizione dell'interfaccia, che è la cosa che realmente interessa a un programmatore.

.NET serve proprio a questo: l'implementazione di qualcosa può essere stata realizzata con qualsiasi linguaggio, ma non è noto né sarebbe utile conoscerlo. Interessa conoscere soltanto l'interfaccia esposta dagli oggetti e dalle API. Punto.

A Delphi/.NET non manca nulla, come linguaggio, per fare le stesse cose di C# e di "recepire", quindi, tutto ciò che è stato scritto con esso per .NET.

L'unico feeling è quello che il programmatore ha con l'ambiente di sviluppo che ha scelto...

Puoi dire di conoscere GTK+ senza sapere C? Le WIndows Forms (e quindi un gran bel pezzo di .NET) sono scritte in C#, la maggiorparte dei tutorial sono scritti in C#. Per gli altri linguaggi sono dei semplici "wrapper" alle Windows Forms per portarle negli altri linguaggi.
Puoi benissimo leggere un tutorial sulle Windows Forms in Delphi cosi' come puoi leggere un tutorial sulle GTK+ in Tom. Ma senza conoscere il linguaggio nativo, non si coglie mai il "feeling" del toolkit che si sta usando. Quindi, C# non è legato da .NET, .NET non è legato da C#, ma un "programmatore .NET che non conosce C#" è come un programmatore "C++ che non conosce C". Poco credibile.


mjordan, il linguaggio nativo di .NET e' CLI (una specie di assembly), non C#. Il linguaggio usato per implementare la maggior parte del framework e' C++/CLI. L'unico linguaggio che permette l'accesso a tutto il framework e' sempre C++/CLI. C# e' solo uno dei linguaggi disponibili.

mjordan, il linguaggio nativo di .NET e' CLI (una specie di assembly), non C#. Il linguaggio usato per implementare la maggior parte del framework e' C++/CLI. L'unico linguaggio che permette l'accesso a tutto il framework e' sempre C++/CLI. C# e' solo uno dei linguaggi disponibili.

Le Windows Forms sono scritte in C++ o in C#?

Non prendiamoci in giro. Come programmatore a me interessa soltanto l'interfaccia di un'API / classe, non l'implementazione: è un dettaglio trascurabile, che serve soltanto ad arricchire il proprio bagaglio culturale.

Se, come dici tu, è necessario conoscere il linguaggio con cui è stato scritto qualcosa per "coglierne il feeling", chi programma sarebbe costretto a conoscere il C# perché la maggior parte delle WinForms sono realizzate con questo linguaggio, C, C++ e assembly per tutto il resto. Da folli.

Mettiamo il caso che non ho mai imparato l'assembly perché ho usato soltanto funzioni scritte in C; domani un'API viene riscritta in assembly per questioni di efficienza: ho forse bisogno di imparare questo nuovo linguaggio soltanto per questo? Chiaro che no. E' venuto a mancare il "feeling"? Chiaro che no.

E' una cosa priva di senso...

L'implementazione di qualcosa è per natura stessa soggetta a cambiamenti, anche profondi, ma non per questo bisogna stravolgere la modalità di fruizione dell'interfaccia, che è la cosa che realmente interessa a un programmatore.

.NET serve proprio a questo: l'implementazione di qualcosa può essere stata realizzata con qualsiasi linguaggio, ma non è noto né sarebbe utile conoscerlo. Interessa conoscere soltanto l'interfaccia esposta dagli oggetti e dalle API. Punto.

A Delphi/.NET non manca nulla, come linguaggio, per fare le stesse cose di C# e di "recepire", quindi, tutto ciò che è stato scritto con esso per .NET.

L'unico feeling è quello che il programmatore ha con l'ambiente di sviluppo che ha scelto...

Certo, non dico di no. Ma non puoi dire che l'unico feeling è quello che il programmatore ha con l'ambiente che ha scelto. Perchè in molte circostanze c'è una differenza di linguaggio che cambia l'approccio al toolkit utilizzato (non concettuale, chiaro) ma sintattico, proprio perchè sono linguaggi diversi. E se io per le Windows Forms trovo per la maggiorparte solo libri e documentazione riferita a C#, faccio prima a imparare C# che non a farmi un'idea di come utilizzare quel widget con un altro linguaggio.

Basta guardare due esempi di "Hello world" scritti in GTK+ con C e uno con Java. Se conosco C ma non Java, probabilmente da un tutorial Java con GTK+ non carpisco nulla.
Il primo esempio banale che mi viene in mente sono le differenze fra una "import" e una "#include". In Java importo package mentre in C/C++ includo headers e ancora in Delphi utilizzo clausole "uses" per intendere unit. Sfido chiunque a capire quale header includere a partire da una dichiarazione import o viceversa. Non si puo' perchè quelle dipendono da come è stato realizzato il wrapper al linguaggio.
Chiaro che se poi utilizzo un GUI Builder la cosa è differente (ma neanche troppo visto che le mani al codice si devono mettere comunque). Era questo il senso di quello che volevo dire.

Le Windows Forms sono scritte in C++ o in C#?

C++ Nativo, C++/CLI e C# a seconda delle esigenze. E' proprio questo il punto del .NET framework, l'usare il linguaggio adatto al problema da risolvere.

Certo, non dico di no. Ma non puoi dire che l'unico feeling è quello che il programmatore ha con l'ambiente che ha scelto. Perchè in molte circostanze c'è una differenza di linguaggio che cambia l'approccio al toolkit utilizzato (non concettuale, chiaro) ma sintattico, proprio perchè sono linguaggi diversi.
E' ovvio: l'interfaccia farà uso della sintassi del linguaggio per descriverne le funzionalità.
E se io per le Windows Forms trovo per la maggiorparte solo libri e documentazione riferita a C#, faccio prima a imparare C# che non a farmi un'idea di come utilizzare quel widget con un altro linguaggio.
Questo è un altro discorso. Se ti fai un giretto noterai un bel po' di manuali dedicati a Delphi per .NET: non è certo la maggior parte, ci mancherebbe, ma a me basta anche un solo manuale che descriva in maniera completa le WinForm per Delphi/.NET, e non m'interesserà sapere se ce ne sono 100 volte di più per C#.
Basta guardare due esempi di "Hello world" scritti in GTK+ con C e uno con Java. Se conosco C ma non Java, probabilmente da un tutorial Java con GTK+ non carpisco nulla.
Guarda, sono 23 che programmo usando le API del s.o., e non mi sono mai fatto problemi a causa del linguaggio usato per implementarle.
Con AmigaOS usavo principalmente Assembly, e in subordine Pascal/Modula-2, BASIC e C; nel corso degli anni AmigaOS, che inizialmente era scritto per buona parte in assembly, è stato riscritto per buona parte in C: per me e per tutti gli altri non è cambiato di una virgola l'approccio al s.o.
Col DOS idem: ho lavorato principalmente in Pascal, assembly e qualche volta in C. Non mi sono mai posto il problema di sapere se le API erano stato scritte in assembly o C.
Con Windows, stesso discorso, ma usando (quasi sempre) Delphi, VisualBasic o VisualC. Nessun problema con le API e le strutture usate da Windows.
Idem con Linux, con cui ho lavorato principalmente in C, ma anche in Pascal: il fatto che fosse scritto per lo più in C, non mi ha mai condizionato.
Il primo esempio banale che mi viene in mente sono le differenze fra una "import" e una "#include". In Java importo package mentre in C/C++ includo headers e ancora in Delphi utilizzo clausole "uses" per intendere unit. Sfido chiunque a capire quale header includere a partire da una dichiarazione import o viceversa. Non si puo' perchè quelle dipendono da come è stato realizzato il wrapper al linguaggio.
Non vedo il problema: mi sembra ovvio che, a seconda del linguaggio, in qualche modo si dovrà pur accedere alle definizioni usate per richiamare le API del s.o..
Che il C utilizzi gli header, Java i package, Delphi le unit, Python i moduli, ecc. è una cosa che deriva intrinsecamente da linguaggio, ma vale per qualunque applicazione / libreria, non soltanto per le API del s.o.

Il fatto di conoscere quale header, package, unit, modulo, ecc. richiamare per usare una certa API è soltanto un problema di documentazione, cioé di come, chi ha realizzato l'ambiente a supporto di un certo linguaggio, ha deciso di creare i "wrapper".
Chiaro che se poi utilizzo un GUI Builder la cosa è differente (ma neanche troppo visto che le mani al codice si devono mettere comunque). Era questo il senso di quello che volevo dire.
OK, ma questo è un altro discorso, IMHO.