Link alla notizia: http://www.hwupgrade.it/news/software/microsoft-net-si-puo-guardare-il-codice-sorgente_22804.html

Il codice sorgente di alcune librerie appartenenti a Microsoft .Net può essere visualizzato ma non copiato


Click sul link per visualizzare la notizia.

..né migliorato, né risolte falle di sicurezza.

Ed in caso di riscontro di violazione di brevetti da parte di Microsoft, decade la licenza per continuare ad accedere in sola lettura ai sorgenti.

If you begin patent litigation against the Licensor over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically.

Penso di aver detto tutto...

..né migliorato, né risolte falle di sicurezza.


Pardon, fonte di questa affermazione? Ho appena controllato su Secunia:

Versione 2.0:
http://secunia.com/product/6456/

Versione 3.0:
http://secunia.com/product/14766/

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Sarebbe violazione di copyright, legge su cui le licenze software si basano.

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa. :)

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa. :)

Non c'è problema. Sempre meglio chiarirsi. :)

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Sarebbe violazione di copyright, legge su cui le licenze software si basano.

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa. :)

va beh il codice è loro, se non vogliono che terzi ci mettano le mani, non è che si può "pretendre" qualcosa, anche solo "moralmente" :boh:

forse è un piccolo passo avanti, ma è certo che non vogliono far si che ci si possa fidare. Anche java era così.

il fatto che non lascino ricompilare mi sembra ovvio... la MS fornisce una libreria con i codici, tu ci metti dentro le mani e la distribuisci; se poi accade qualcosa la libreria è quella di MS, quindi risponde lei

bisogna anche vedere con che garanzie viene fornito il software. è ovvio che se parliamo di linux, nelle cui licenze c'è scritto a caratteri cubitali che "il presente software viene fornito senza garanzia alcuna", il problema non sussiste. nel caso in cui invece fornisci delle garanzie, mi sembra davvero più che ovvio che ti tuteli dal dover rispondere di modifiche fatte da terzi.

poi ovviamente se viene rilevata una falla di sicurezza, non è che questa deve rimanere lì, ma deve semplicemente esser corretta da MS, com'è ovvio che sia.

detto questo, vorrei sapere com'è messa la concorrenza a riguardo. linux ok, è tutto open quindi il tema non sussiste nemmeno, però è anche vero che dietro non c'è un'azienda che lo sviluppa. prendiamo apple, e prendiamo le parti di mac os x che ha scritto di suo pugno (ad es. carbon, cocoa, quartz, eccetera)... si può vedere il codice? sono aperti?

con questo voglio dire che va bene criticare, però ogni tanto sarebbe bello leggere delle critiche circostanziate. MS fa un passo in una direzione, penso auspicabile da tutti, e ci si lamenta perchè non ne ha fatti 10... mah

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).

Uno dei punti su cui ScottGu ha focalizzato maggiormente è proprio questo, oltre al fatto di poter debuggare linea per linea anche il codice del Framework.

Ma solo io uso reflector per decompilarlo e studiare come è fatto dentro?

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).

Uno dei punti su cui ScottGu ha focalizzato maggiormente è proprio questo, oltre al fatto di poter debuggare linea per linea anche il codice del Framework.

Esatto, è molto più comodo avere tutto integrato in Visual Studio, praticamente nel debugging potrai fare lo step into nelle librerie System.qualsiasicosa. Tra l'altro, se non hai installato i sorgenti in locale, scarica automaticamente da internet quelli interessati, controllando di prendere la versione giusta (utile in caso di aggiornamenti non ancora installati ecc).

Vi consiglio caldamente di leggere questo post, molto più completo di quello linkato nella notizia di hwupgrade:

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

Se a qualcuno interessa il discorso licenze e/o le ripercussioni su Mono, ne stiamo parlando qui:

http://www.hwupgrade.it/forum/showthread.php?t=1569882

Giusta osservazione, ma il Reflector non è in grado di restituire i commenti. Senza, capire alcuni namespace è piuttosto arduo (o addirittura impossible).


Più che di commenti mancanti parlerei di tecniche di offuscamento di solito ampiamente adottate per evitare il reverse. Comunque, più che conoscere il punto di un possibile errore in fase di debug, a cosa serve avere del codice sorgente sotto una licenza simile? Manco il debug è consentito. Insomma, più che di possibilità di guardare il codice sorgente parlerei di risposta a possibili pressioni di software house legate a .Net, quindi niente di eclatante.

Dimenticavo, un appunto al titolo della news è doveroso. E' certamente di effetto, ma non rispecchia minimamente la realtà, da .Net ad alcune librerie legate a .Net la differenza è notevole.

Più che di commenti mancanti parlerei di tecniche di offuscamento di solito ampiamente adottate per evitare il reverse. Comunque, più che conoscere il punto di un possibile errore in fase di debug, a cosa serve avere del codice sorgente sotto una licenza simile? Manco il debug è consentito. Insomma, più che di possibilità di guardare il codice sorgente parlerei di risposta a possibili pressioni di software house legate a .Net, quindi niente di eclatante.

Dimenticavo, un appunto al titolo della news è doveroso. E' certamente di effetto, ma non rispecchia minimamente la realtà, da .Net ad alcune librerie legate a .Net la differenza è notevole.

Sinceramente ho usato Reflector su diversi Assembly del Framework, ma non mi è capitato di incappare in aree di codice offuscate... Me ne potrebbe segnalare qualcuna?

Per il resto, concordo con Fx, questo è un piccolo passo, ma pur sempre in avanti e credo lasci buone prospettive per il futuro.

Mi auto-quoto:
A me sembra un’enorme vittoria per il mondo open! Non per il fatto che si potrà avere il framework .NET sotto una finta licenza open, quanto per il fatto che la Microsoft ha pubblicamente ammesso che il modello di sviluppo migliore è quello open. Vi rendete conto che niente popò di meno che il GM dell’azienda ha dichiarato che avendo a disposizione il codice si possono scrivere programmi migliori? Che gli sviluppatori traggono vantaggi indiscussi dal modello del software Open Source? La Microsoft ha sempre sostenuto il contrario! Per questo a me sembra una bella vittoria, anche se nessuno dovesse mai vedere il codice di .NET…

PS: Quando parlo delle affermazioni del GM Microsoft, è tutto vero:
Scott Guthrie, general manger Microsoft, ha dichiarato che questa iniziativa servirà soprattutto agli sviluppatori per eseguire un debug appropriato delle loro applicazioni. In particolare ha scritto sul suo blog: “Andando a leggere il codice sorgente sarà più facile avere una visione d’insieme su come le librerie del Framework .NET siano implementate e ciò permetterà agli sviluppatori di creare applicazioni migliori e magari utilizzarle meglio.”

Fonti: http://www.tuxjournal.net/?p=1286 ; http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

A me sembra un’enorme vittoria per il mondo open! Non per il fatto che si potrà avere il framework .NET sotto una finta licenza open, quanto per il fatto che la Microsoft ha pubblicamente ammesso che il modello di sviluppo migliore è quello open. Vi rendete conto che niente popò di meno che il GM dell’azienda ha dichiarato che avendo a disposizione il codice si possono scrivere programmi migliori? Che gli sviluppatori traggono vantaggi indiscussi dal modello del software Open Source? [...]
Non ha propriamente affermato che il modello di sviluppo open sia migliore, anche perché il modello di sviluppo (di .NET) rimarrà lo stesso di prima. La differenza è che - e qui concordo con MS, con FX e tutti - lo sviluppatore di applicazioni potrà eventualmente godere del beneficio di leggersi anche il codice precedentemente nascosto del framework e capirne magari le meccaniche più nascoste (anche se già la documentazione ha sempre fatto un ottimo lavoro su questo punto). Inoltre è sempre possibile implementare dei work-around in maniera pulita di eventuali bug o comportamenti "strani" del framework.
Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET... :)

Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET... :)

Sono totalmente d'accordo, anche perché il modello di .Net è ampiamente estendibile e molti aspetti possono essere riconfigurati a piacere, senza però alterare la struttura base del framework. Basti pensare al provider model di ADO.NET oppure ai WebControlAdapters di ASP.NET.

Sinceramente ho usato Reflector su diversi Assembly del Framework, ma non mi è capitato di incappare in aree di codice offuscate... Me ne potrebbe segnalare qualcuna?

Per il resto, concordo con Fx, questo è un piccolo passo, ma pur sempre in avanti e credo lasci buone prospettive per il futuro.

Non ho l'hobby di disassemblare codice ;), la mia era una supposizione. Di solito l'offuscamento mitiga il reverse di prodotti close, quindi che .Net non faccia uso di tecniche di offuscamento più o meno pesanti mi sembra strano. Comunque, un conto è riuscire a decompilare (anche le migliori trasformazioni ad esempio non offrono una protezione completa contro la decompilazione), un conto è capire e riuscire ad utilizzare il codice decompilato.

Il framework in sé non si potrà comunque modificare, ma personalmente ritengo che sia un bene: se si scova un bug si riesce comunque a segnalare a Microsoft attraverso i consueti mezzi (magari segnalando anche con il codice colpevole), mentre lo sviluppo del Framework rimane in ogni caso centralizzato. Sarebbe un incubo trovarsi con una miriade di Fork del .NET... :)

E qqui mi sorge un dubbio, cosa torna nelle tasche dello sviluppatore .Net nel segnalare un bug a Microsoft? In questo caso ne guadagna direttamente solo Microsoft, poichè l'onere di scovare e debuggare .Net dovrebbe rimanere, per l'appunto, un onere di Microsoft. Un modello di sviluppo Open è diametralmente opposto. In questo caso, come dicevo nel precedente post, più che intraprendere una strada che porti verso l'Open, vedo più una risposta alle richieste di aziende che sviluppano con .Net. Infondo è capitato anche a me (che sviluppo a livelli infimi) di dover controllare il flusso di esecuzione all'interno di una libreria (libreria open ovviamente), figuriamoci per un vero sviluppatore. Insomma, in questo caso non se ne poteva fare a meno, quindi non penso che Microsoft andrà mai oltre queste rilasci dettati dalle esigenze degli sviluppatori.

Non ho l'hobby di disassemblare codice ;), la mia era una supposizione. Di solito l'offuscamento mitiga il reverse di prodotti close, quindi che .Net non faccia uso di tecniche di offuscamento più o meno pesanti mi sembra strano. Comunque, un conto è riuscire a decompilare (anche le migliori trasformazioni ad esempio non offrono una protezione completa contro la decompilazione), un conto è capire e riuscire ad utilizzare il codice decompilato.

Hai mai usato Reflector? Non è come decompilare un classico binario, gli Assembly del .NET non sono codice per la macchina nativa ma sono MS Intermediate Language, con Reflector puoi visualizzarli direttamente nel linguaggio che preferisci (C#, VB.NET ecc).

Se non c'è offuscamento ti vedi il codice esattamente com'è stato scritto, meno i commenti.

E qqui mi sorge un dubbio, cosa torna nelle tasche dello sviluppatore .Net nel segnalare un bug a Microsoft? In questo caso ne guadagna direttamente solo Microsoft, poichè l'onere di scovare e debuggare .Net dovrebbe rimanere, per l'appunto, un onere di Microsoft.

Lo sviluppatore ci guadagna una piattaforma con meno bug.
Anche nei progetti open-source uno sconosciuto non può mettere il suo codice nel repository senza che nessuno del progetto l'abbia autorizzato o abbia controllato e testato (si spera) il suo codice.

Lo sviluppatore ci guadagna una piattaforma con meno bug.
Anche nei progetti open-source uno sconosciuto non può mettere il suo codice nel repository senza che nessuno del progetto l'abbia autorizzato o abbia controllato e testato (si spera) il suo codice.
Esatto. Del resto in teoria "non ci guadagno niente" neanche se mi metto a studiare una libreria open, a modificarla e a fare il submit delle modifiche apportate. Si tratta sempre di "altruismo" nel contribuire a rendere una piattaforma migliore.

Sempre per lo stesso motivo, è giusto che tutte le modifiche e bug fix proposti passino per le mani di Microsoft che come sempre deve garantire che il framework sia adeguatamente testato e funzionante, e che mantenga la sua coerenza.
Senza voler scadere in dibattiti pro/contro Open Source (perché ribadisco sempre che entrambi i "mondi" hanno i loro pro e contro), in una tecnologia come .NET è IMHO importante che l'interfaccia di programmazione sia coerente e relativamente "immobile" nel tempo (prendiamo come riferimento le API Win32 che nella maggior parte dei casi permettono di far girare su Vista applicazioni compilate per Win95), senza che un domani chiunque possa ripacchettizzare .NET con qualche aggiunta e quindi nullificare tutto quello che ha di buono una piattaforma di sviluppo condivisa e astratta.

Un esempio contrario, con il quale in questi giorni devo lavorare, è R-project (una specie di Matlab open source) che ha una API talmente ballerina che applicazioni compilate per la versione 2.5 non funzionano più sulla 2.6 e così via... un incubo (senza nulla togliere però alla velocità di aggiornamento di R stesso ed alla bontà del progetto).

Se i sorgenti non ci sono e perché non ci sono, se ci sono e perché c'è questa licenza (ma di quella GPL, che è "virale", nessuno si lamenta): la gente non è mai contenta.

Questa mossa di MS è fin troppo chiara: dare la possibilità a chi SVILUPPA codice .NET di poter leggere i sorgenti ed eseguire il debug del proprio codice anche all'interno delle suddette librerie.

Insomma, roba che Borland coi suoi prodotti permette da parecchi lustri: chi, lavorando con Delphi, CBuilder o similia non ha mai eseguito il tracing fin dentro le VCL (che sono "l'equivalente" delle librerie di .NET)?

In entrambi i casi (MS e Borland) il concetto è lo stesso: il codice continua a rimanere dei legittimi proprietari, ma gli sviluppatori lo possono visionare e usare per il debug.

Non c'è, quindi, nessun cambiamento di orientamente sostanziale verso il mondo open source, anche se i sorgenti, comunque, ci sono e chiunque li potrà visionare.
Quindi tutti quelli che fantasticavano su problemi di sicurezza, backdoor, trojan, ecc. a causa della loro natura closed finalmente si potrà mettere l'anima in pace.

Certo, non ci si può metter le mani sopra, ma questo, come è stato detto, è certamente un bene: niente sindrome da fork, che affligge gli altri prodotti open source. Lo sviluppo rimarrà saldamente in mano a MS, e chiunque troverà dei bug (ma, come potere vedere, .NET è un'eccellente piattaforma e ne sono sono stati trovati pochissimi, comunque corretti) potrà segnalarli a MS che si farà carico della loro sistemazione.

Come sviluppatore (che poi è il chiaro ed evidentissimo target di questa mossa) non si può che esser soddisfatti.

Hai mai usato Reflector? Non è come decompilare un classico binario, gli Assembly del .NET non sono codice per la macchina nativa ma sono MS Intermediate Language, con Reflector puoi visualizzarli direttamente nel linguaggio che preferisci (C#, VB.NET ecc).

Se non c'è offuscamento ti vedi il codice esattamente com'è stato scritto, meno i commenti.


Sapevo, pur non usando .Net, che usava un byte code stile Java, ma ammetto di non conoscere Reflector. Comunque che sia codice macchina o byte code per macchina virtuale non è poi così importante, le tecniche di offuscamento per Java esistono, per questo presumevo che
MS usasse tecniche simili nel core e nelle librerie di .Net.


Lo sviluppatore ci guadagna una piattaforma con meno bug.
Anche nei progetti open-source uno sconosciuto non può mettere il suo codice nel repository senza che nessuno del progetto l'abbia autorizzato o abbia controllato e testato (si spera) il suo codice.

Si, ci guadagna una piattaforma con meno bug, questo è vero, però le segnalazioni di bug si possono fare sia con il source code davanti sia senza il source code davanti nella maggior parte dei casi. Per questo sono dell'idea che non ci troviamo davanti ad una reale scelta di Microsoft ma di una scelta dettata da esigenze degli sviluppatori, insomma una scelta obbligata, non una scelta voluta. Ovviamente quest'ultima considerazione è IMHO.

Come diceva cdimauro, nessun avvicinamento al mondo Open (o cose simili), ma (aggiungo io e ripeto) una mossa dettata da esigenze degli sviluppatori. Il Debug facilitato è una conseguenza che a parer mio va a favore di Microsoft in primis e poi, indirettamente, degli sviluppatori, ma in minor parte, poichè uno sviluppatore sceglie un framework anche per non doversi preoccupare del suo debugging.

Sapevo, pur non usando .Net, che usava un byte code stile Java, ma ammetto di non conoscere Reflector. Comunque che sia codice macchina o byte code per macchina virtuale non è poi così importante, le tecniche di offuscamento per Java esistono, per questo presumevo che
MS usasse tecniche simili nel core e nelle librerie di .Net.
Non le ha mai usate perché non ha senso farlo: .NET lo devono usare gli sviluppatori, per cui il framework deve essere quanto più documentato / fruibile possibile.

Sono gli sviluppatori la linfa vitale di MS, e mi sembra normale che siano adeguatamente supportati.
Si, ci guadagna una piattaforma con meno bug, questo è vero, però le segnalazioni di bug si possono fare sia con il source code davanti sia senza il source code davanti nella maggior parte dei casi.
Permettimi: se hai il codice davanti, anche se non puoi modificarlo, puoi sempre effettuarne il tracing e verificare che il bug non stia nel tuo, ma in quello della libreria.

In precedenza l'unica possibilità per eseguire il tracing delle librerie era quella di ricorrere al disassemblatore: cosa non alla portata di tutti.

Quindi, sorgente o no, c'è sempre la possibilità di sapere cosa viene eseguito (per questo ha poco senso la classificazione del codice in "open" o "closed", specialmente quando si parla di sicurezza et similia): è soltanto il livello di skill che fa la differenza.
Per questo sono dell'idea che non ci troviamo davanti ad una reale scelta di Microsoft ma di una scelta dettata da esigenze degli sviluppatori, insomma una scelta obbligata, non una scelta voluta. Ovviamente quest'ultima considerazione è IMHO.

Come diceva cdimauro, nessun avvicinamento al mondo Open (o cose simili), ma (aggiungo io e ripeto) una mossa dettata da esigenze degli sviluppatori. Il Debug facilitato è una conseguenza che a parer mio va a favore di Microsoft in primis e poi, indirettamente, degli sviluppatori, ma in minor parte, poichè uno sviluppatore sceglie un framework anche per non doversi preoccupare del suo debugging.
Esattamente, e infatti il programmatore generalmente si aspetta che le librerie siano "a prova di bug": normalmente il bug sta nel nostro codice, e il poter effettuare il tracing fin dentro le librerie ce ne può dare una conferma in tempi più rapidi.

Per questo la mossa di MS, dal mio punto di vista, è sicuramente azzeccata.

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Sarebbe violazione di copyright, legge su cui le licenze software si basano.

Il post era da leggersi come virtuale continuazione del secondo titolo di notizia; ma credo non sia così chiaro, chiedo scusa. :)

Segnali il bug a Microsoft e poi ci pensano loro... non vedo il problema.

Comunque consiglio a tutti l'uso di reflector.net: studiandolo si capiscono moltissime cose a livello di architettura ( e si sgamano le parti uguali scritte da sviluppatori diversi :))

p.s.
imho si impara di più da un serio studio del codice disassemblato che da dieci libri...

sarà interessante vedere l'implementazione di namespace più dipendenti dalla piattaforma come System.IO per vedere dove finisce il codice gestito e dove inizia quello unmanaged.

Nell'articolo viene scritto:
"i sorgenti di alcune librerie del .NET Framework saranno resi disponibili"
se qualche sviluppatore in ambiente NET ci potesse elencare quali sono e se sono in numero sufficiente ci si potrebbe fare un'idea migliore di quanto questa mossa possa essere d'aiuto nei casi concreti, perché mi sembra evidente che se le librerie visionabili in oggetto fossero troppo poche o di scarsa rilevanza, l'utilità potrebbe rivelarsi modesta.

Mi sembra un passettino in avanti, anche se ovviamente continuo a preferire alternative open e multipiattaforma.

Per pure curiosità di tipo accademico qualcuno sarebbe così gentile da illuminarmi sulla compatibilità del codice prodotto tra varie vers. di Net? :rolleyes:
Avevo letto, però molto velocemente, che era necessario ricompilare.
Ma nel caso non si disponga dei sorgenti come fare per combinare parti di una vers. precedente di Net e parti della vers. più recente.
Inoltre la ricompilazione risulta "pulita" quindi senza necessità di ulteriori interventi sul codice?

Ah, un'altra domandina, gli sviluppatori Net come vedono Mono?
Vi risulta qualcosa di utilizzabile oppure no?

Ciao Ale :)

Ah, un'altra domandina, gli sviluppatori Net come vedono Mono?
Vi risulta qualcosa di utilizzabile oppure no?

Il massimo che posso dirti è come quelli di Mono vedono il rilascio dei sorgenti del .NET Framework: http://tirania.org/blog/archive/2007/Oct-05-2.html

Nell'articolo viene scritto:
"i sorgenti di alcune librerie del .NET Framework saranno resi disponibili"
se qualche sviluppatore in ambiente NET ci potesse elencare quali sono e se sono in numero sufficiente ci si potrebbe fare un'idea migliore di quanto questa mossa possa essere d'aiuto nei casi concreti, perché mi sembra evidente che se le librerie visionabili in oggetto fossero troppo poche o di scarsa rilevanza, l'utilità potrebbe rivelarsi modesta.

Mi sembra un passettino in avanti, anche se ovviamente continuo a preferire alternative open e multipiattaforma.

Per pure curiosità di tipo accademico qualcuno sarebbe così gentile da illuminarmi sulla compatibilità del codice prodotto tra varie vers. di Net? :rolleyes:
Avevo letto, però molto velocemente, che era necessario ricompilare.
Ma nel caso non si disponga dei sorgenti come fare per combinare parti di una vers. precedente di Net e parti della vers. più recente.
Inoltre la ricompilazione risulta "pulita" quindi senza necessità di ulteriori interventi sul codice?

Ah, un'altra domandina, gli sviluppatori Net come vedono Mono?
Vi risulta qualcosa di utilizzabile oppure no?

Ciao Ale :)

Allora, gli assembly sono (da articolo):

Base Class Library (BCL): tutte le classi base, dai tipi primitivi, alle collection/hashtable/stack/queue passando per IO, generazione di codice a run-time, threading, reflection e internazionalizzazione
Windows Forms: permettono di creare le classiche GUI per sistemi desktop
ASP.NET: piattaforma per lo sviluppo web (non mi spingo oltre, altrimenti mi ci vorrebbe troppo per elencare anche i dettagli)
System.Data: provider per l'accesso nativo a SqlServer, OleDb e Oracle, oltre a tutte le classi del provider model.
XML: supporto completo agli standard XML, XPath,XSD e XSL
WPF: sempre GUI, ma questa volta più flessibili e potenti (parte del Fx 3.0)


Per il discorso compatibilità, ogni applicativo è concepito per girare su una specifica versione del Fx, motivo per cui i vari Fx NON sono comulativi (la versione 2.0 non sovrascrive un'eventuale 1.0).

Tuttavia, è comunque possibile far girarare un applicativo su una versione diversa, purché compatibile (esponga le stesse funzionalità richieste dall'applicativo) semplicemente specificandolo nel file di configurazione (in formato XML). Non è richiesta alcuna ricompilazione.

Ultimo, Mono: l'ho utilizzato, anche se a livelli moderati (solo applicazioni da me sviluppate). Ci sono alcune incompatibilità, ma sono perlopiù inerenti a funzionalità molto particolari (per esempio il layer di compatibilità con COM/COM+). Il trend è comunque molto promettente e, almeno a mio avviso, varrebbe la pena fare qualche tentavio con applicativi più complessi.

Spero di aver chiarito almeno in parte i suoi dubbi,
Riccardo Chiodaroli

Fonte, la stessa licenza del software.

Microsoft con la sua licenza non permette ad alcun sviluppatore di accettare la licenza, per poi, scovato un errore di programmazione, importare i sorgenti in un proprio ramo di sviluppo, risolvere il problema e pubblicare le modifiche, o redirezionarle anche alla sola Microsoft.

Ma che grossa minchiata... e io che dalla news avevo sperato in un improvviso rinsavimento della Microsoft :muro:

Non vedo perché dovrebbe rinunciare alla proprietà di quello che ha sviluppato tirando fuori tanti soldi: non è un certo un ente di beneficenza...

Sarebbe follia il contrario, invece.

Nell'articolo viene scritto:
"i sorgenti di alcune librerie del .NET Framework saranno resi disponibili"
se qualche sviluppatore in ambiente NET ci potesse elencare quali sono e se sono in numero sufficiente ci si potrebbe fare un'idea migliore di quanto questa mossa possa essere d'aiuto nei casi concreti, perché mi sembra evidente che se le librerie visionabili in oggetto fossero troppo poche o di scarsa rilevanza, l'utilità potrebbe rivelarsi modesta.

Le librerie che diventeranno open-source sono praticamente tutte quelle che mi è capitato di usare finora:
"We'll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We'll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ)."
(http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx)

Per pure curiosità di tipo accademico qualcuno sarebbe così gentile da illuminarmi sulla compatibilità del codice prodotto tra varie vers. di Net? :rolleyes:

Come hanno già spiegato le varie versioni del Framework rimangono separate, questo è un ottimo modo per far progredire la piattaforma perché non si ha il vincolo di mantenere la retrocompatibilità.

Non vedo perché dovrebbe rinunciare alla proprietà di quello che ha sviluppato tirando fuori tanti soldi: non è un certo un ente di beneficenza...

Sarebbe follia il contrario, invece.

Ma chi dice di rinunciare alla proprieta'. Ma rendere accessibile il codice senza avere la possibilita' neanche di mandare alla Microsoft una modifica per renderlo migliore e' una ca*ata pazzesca (applusi di 90 minuti :D )

Come pretendono di rendere migliori le librerie in questo modo? Al massimo sara' un po' piu' semplice sviluppare i programmi, ma voglio vedere chi si prendera' la briga di spulciarsi il codice solo per capire come funziona una tale funzione o libreria, senza avere la benche' minima possibilita' neppure di proporre una modifica. Ma uno che dovrebbe fare secondo loro, segnalare il problema e basta? Ed aspettare che siano loro stessi a fixare i problemi? Campa cavallo. Miopi, davvero miopi!

Ci sono un botto di smanettoni in giro, molti anche grandemente competenti, che penso non vedrebbero l'ora di mettersi in mostra sperando magari di essere notati ed assunti. E loro invece si parano da questo "pericolo"! CHe malnati idioti....

Ma chi dice di rinunciare alla proprieta'. Ma rendere accessibile il codice senza avere la possibilita' neanche di mandare alla Microsoft una modifica per renderlo migliore e' una ca*ata pazzesca (applusi di 90 minuti :D )
Mi fai vedere dove sta scritto che ciò non sia possibile?
Come pretendono di rendere migliori le librerie in questo modo? Al massimo sara' un po' piu' semplice sviluppare i programmi, ma voglio vedere chi si prendera' la briga di spulciarsi il codice solo per capire come funziona una tale funzione o libreria, senza avere la benche' minima possibilita' neppure di proporre una modifica.
Per sviluppare le proprie applicazioni la possibilità di avere i sorgenti e di poterci entrare per debuggarli è una gran cosa.
Ma uno che dovrebbe fare secondo loro, segnalare il problema e basta? Ed aspettare che siano loro stessi a fixare i problemi?
Esattamente.
Campa cavallo. Miopi, davvero miopi!
A giudicare dal numero di bug finora riscontrati col framework .NET, sono messi molto bene alla MS.
Ci sono un botto di smanettoni in giro, molti anche grandemente competenti, che penso non vedrebbero l'ora di mettersi in mostra sperando magari di essere notati ed assunti. E loro invece si parano da questo "pericolo"!
Fanno benissimo, perché ci sono anche un sacco di lamer, e di smanettoni che sono convinti di saper programmare ma poi non hanno la minima cognizione nemmeno dei rudimenti di ingegneria del software.

Gente che è capace di rilasciare una patch dopo mezz'ora dalla segnalazione, senza aver effettuato adeguati test (in particolare di regressione).
CHe malnati idioti....
:rolleyes:

Mi fai vedere dove sta scritto che ciò non sia possibile?

"Reference use" means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

http://www.microsoft.com/resources/sharedsource/licensingbasics/referencelicense.mspx

Piu' chiaro di cosi'!

Per sviluppare le proprie applicazioni la possibilità di avere i sorgenti e di poterci entrare per debuggarli è una gran cosa.

No, avere una documentazione associata e' una gran cosa. In questo modo gli si dice "questo e' il codice sorgente, vedetevela un po' voi".

A giudicare dal numero di bug finora riscontrati col framework .NET, sono messi molto bene alla MS.

Senti, ma se schifo il .NET come la morte... in lentezza se la gioca con Java, che perlomeno non rompe le scatole quando non c'e' nessun programma Java in funzione!

Fanno benissimo, perché ci sono anche un sacco di lamer, e di smanettoni che sono convinti di saper programmare ma poi non hanno la minima cognizione nemmeno dei rudimenti di ingegneria del software.

Ah ecco, hanno finito i posti alla Microsoft, allora? :D

Non hanno proprio imparato una cippalippa dal mondo opensource. Sperano ancora di andare avanti con le loro tattichette... ma i tempi sono cambiati, le librerie ed il codice di base sono ormai alla portata di tutti. I formati ed i programmi open hanno una fortuna incredibile, quelli chiusi sono stati destinati ad una fine ingloriosa, prima o poi. C'e' Firefox che e' opensource e loro? Mettono IE senza WGA. C'e' Java che sta per andare sotto GPL, e loro rendono accessibile il source di .NET per il solo debugging dei programmi... dio che sforzo!

Microsoft, mi senti dall'alto del kernel? :-P
Sappi che le tue librerie cagose io personalmente non le vorrei copiare neanche se mi pagassi :D Quindi tranquilla.

http://www.microsoft.com/resources/sharedsource/licensingbasics/referencelicense.mspx

Piu' chiaro di cosi'!
No, perché non t'impedisce di spedirgli delle modifiche.
No, avere una documentazione associata e' una gran cosa. In questo modo gli si dice "questo e' il codice sorgente, vedetevela un po' voi".
La documentazione, e di ottima qualità, esiste da tempo (quella che puntualmente manca o fa pena nel mondo open source).

Mancavano soltanto i sorgenti per il debugging e sono arrivati.
Senti, ma se schifo il .NET come la morte... in lentezza se la gioca con Java, che perlomeno non rompe le scatole quando non c'e' nessun programma Java in funzione!
E' un tuo giudizio del tutto soggettivo e ampiamente opinabile. Tra l'altro io ho scritto una cosa e tu hai cambiato del tutto argomento.
Ah ecco, hanno finito i posti alla Microsoft, allora? :D
Per i lamer e gli pseudo esperti non ci sono mai stati.
Non hanno proprio imparato una cippalippa dal mondo opensource.
Al contrario, hanno imparato la cosa più importante: che il forking è un cancro, e con la loro licenza l'hanno bloccato alla radice.
Sperano ancora di andare avanti con le loro tattichette... ma i tempi sono cambiati, le librerie ed il codice di base sono ormai alla portata di tutti.
E il forking pure, con tutte le conseguenze del caso.
I formati ed i programmi open hanno una fortuna incredibile, quelli chiusi sono stati destinati ad una fine ingloriosa, prima o poi.
Infatti si vede proprio, sai.
C'e' Firefox che e' opensource e loro? Mettono IE senza WGA.
Meglio IE, senza i bug e i memory leak di FireFox.
C'e' Java che sta per andare sotto GPL, e loro rendono accessibile il source di .NET per il solo debugging dei programmi... dio che sforzo!
Vedi sopra: hanno fatto benissimo. Niente forking e progetto saldamente nelle loro mani.
Microsoft, mi senti dall'alto del kernel? :-P
Sappi che le tue librerie cagose io personalmente non le vorrei copiare neanche se mi pagassi :D Quindi tranquilla.
E allora puoi anche evitare di scrivere in questo thread, no?

Grazie r.chiodaroli e bist. :)
Sul discorso compatibilità mi piacerebbe avere diversi chiarimenti, ho aperto un thread per discutere della cosa, nella sezione programmazione, con maggiore calma e più in profondità.

Ciao Ale :)

Nota:
bist sei però ottimista, non penso che le librerie Microsoft diventeranno mai open-source, anche se risultano consultabili.

E questo è sicuramente un bene: non ci sarà pericolo di forking "selvaggio". ;)

No, perché non t'impedisce di spedirgli delle modifiche.
[...]
La documentazione, e di ottima qualità, esiste da tempo (quella che puntualmente manca o fa pena nel mondo open source).
Esatto. La documentazione MS è sempre stata una delle migliori, al contrario di quella della maggior parte delle librerie open source (dove la documentazione se c'è è approssimativa o non aggiornata alle ultime revisioni). Poter vedere il codice sorgente è solo un "aggiunta" utile per chiunque programmi su .NET.

Inoltre, come dice cdimauro, nessuno ti vieta di scovare un bug nel codice, correggerlo e poi mandarlo alla MS tramite i consueti canali.
La licenza specifica che il codice è read-only perché le modifiche devono passare ed essere approvate da MS (anche perché il codice e le patch Microsoft vanno testate approfonditamente su tutte le configurazioni possibili, non si può andare a tentativi...).
L'unica cosa veramente vietata dalla licenza è che domani mi alzo, copio il codice di .NET, aggiungo quattro modifiche e lo pubblico come il "Lck.NET" (e vietare questo è un bene perché rendere nulla tutta l'opera di standardizzazione che un framework come .NET o Java devono offrire).

Meglio IE, senza i bug e i memory leak di FireFox.
Beh, magari meglio no... :D
In ogni caso però, stai sicuro che anche le procedure per le modifiche al codice di Firefox non sono così facili: si sottomettono le modifiche e forse vengono approvate.

e io che dalla news avevo sperato in un improvviso rinsavimento della Microsoft :muro:
Che vuol dire? Non è che open source = bene, closed source = male... anche se purtroppo molti sembrano crederlo...

Perché purtroppo in giro ci sono tanti fanatici integralisti che alla chiesa e ai preti hanno sostituito altri totem da adorare. :rolleyes:

Comunque quella su IE vs FF era una provocazione per sottolineare come quando si parla di qualità di prodotti e del relativo codice spesso lo si fa ciecamente e senza cognizione di causa in materia. ;)

Infine su .NET & co sono pienamente d'accordo con quello che hai scritto. :)

P.S. Io preferisco Opera come browser. Come per tutte le cose qui rientriamo nei gusti personali. :p

Nota:
bist sei però ottimista, non penso che le librerie Microsoft diventeranno mai open-source, anche se risultano consultabili.

Sì scusa, ho usato un termine sbagliato :)

P.S. Io preferisco Opera come browser. Come per tutte le cose qui rientriamo nei gusti personali. :p
Allora andiamo d'accordo proprio su tutto! ;)

Esatto. La documentazione MS è sempre stata una delle migliori, al contrario di quella della maggior parte delle librerie open source (dove la documentazione se c'è è approssimativa o non aggiornata alle ultime revisioni). Poter vedere il codice sorgente è solo un "aggiunta" utile per chiunque programmi su .NET

Beh, devo dire che in questo caso sono stato prevenuto, vedo che la documentazione e' al livello di MSDN :-)

Inoltre, come dice cdimauro, nessuno ti vieta di scovare un bug nel codice, correggerlo e poi mandarlo alla MS tramite i consueti canali.
La licenza specifica che il codice è read-only perché le modifiche devono passare ed essere approvate da MS

No, assolutamente no! Questa e' una cosa risaputissima, vai in giro su internet a leggere come funziona la licenza Microsoft: non si puo' modificare il codice per nessun motivo. La licenza stessa parla chiaro:

"Reference use" means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

[...]

Copyright Grant- Subject to the terms of this license, the Licensor grants you a non-transferable, non-exclusive, worldwide, royalty-free copyright license to reproduce the software for reference use.


Meglio IE, senza i bug e i memory leak di FireFox.
Beh, magari meglio no... :D
Mano male che c'e' qualcuno che ragiona :D

In ogni caso però, stai sicuro che anche le procedure per le modifiche al codice di Firefox non sono così facili: si sottomettono le modifiche e forse vengono approvate.
Mai detto il contrario ;-)

Che vuol dire? Non è che open source = bene, closed source = male... anche se purtroppo molti sembrano crederlo...

Ma non ho mai detto questo o_0
Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'. Per la stragrande maggioranza del software ci sono "alternative" (che metto tra virgolette perche' a volte sono i programmi a pagamento o freeware closed ad essere le alternative ai programmi opensource) perfettamente al livello degli altri programmi, se non superiore.

Tempo fa collaborai con un utente del forum per fargli fare una sua copia personale di Windows con tutti programmi molto performati. Molti dei programmi che gli suggerii sono opensource. Potete ben vedere da voi se non sono all'altezza del loro compito:

http://www.hwupgrade.it/forum/showthread.php?t=1536793

E questi sono tutti programmi per l'utenza domestica, ma esistono vere e proprie suite per il businness e per l'ufficio.

E' chiaro che un progetto open source non ti offre la sicurezza assoluta, ma neanche un programma closed. L'unica certezza che ti puo' dare un programma closed e' che i bug saranno scoperti piu' lentamente. E questa puo' essere un'arma a doppio taglio, perche' il bug puo' diventare il cosidetto "segreto di pulcinella", conosciuto da crackers (non in senso di snacks :D) e dalla casa produttrice stessa, ma ignorato finche' una bella fetta di clienti non si lamenta.

L'unico, vero, grosso svantaggio e' che l'open source puo' essere un problema per il diritto di autore, perche' nessuno puo' impedire fisicamente ad un'azienda di prendere quel codice e usarlo per un software closed. Senza avere il codice sorgente, come fai ad essere certo che il codice sviluppato sia tuo? La Microsoft si puo' ben permettere di lasciare il codice in sola lettura, perche' tanto si tratta di una enorme compagnia, che non ha certo paure finanziarie di citare qualcuno in giudizio.

Io semplicemente vedo i risultati. Solitamente i programmi opensource sono meno avidi di risorse e sono gratuiti. Una persona che vuole entrare nel campo informatico puo' pagare una miseria per l'hardware e poi non spendere piu' un soldo. Hai la certezza che se monti su un sito in PHP sara' piu' performante e compatibile di un sito in ASP.NET. Sei sicuro che qualsiasi programma gratuito sara' piu' performante di uno a pagamento. Per fare un esempio, avete mai provato Dreamweaver? Un macigno! Ci sono editor html come Nvu che sinceramente mi fanno passare la voglia di spendere 400 euro e di comprare un computer nuovo. L'unico programma a pagamento e closed che veramente vedo in controtendenza e' Nero.

Senti, ma se schifo il .NET come la morte... in lentezza se la gioca con Java, che perlomeno non rompe le scatole quando non c'e' nessun programma Java in funzione!
E' un tuo giudizio del tutto soggettivo e ampiamente opinabile. Tra l'altro io ho scritto una cosa e tu hai cambiato del tutto argomento.

Permetta. Giudizio soggettivo un corno! :D

Applications running in a managed environment such as the Microsoft framework's CLR or Java's JVM tend to require more system resources than functionally similar applications that access machine resources more directly. However, some applications have been shown to perform better in .NET than in their native version. This could be due to the runtime optimizations made possible by such an environment, the use of relatively well-performing functions in the .NET framework, JITting of managed code, or other aspects of the CLR.

http://en.wikipedia.org/wiki/Microsoft_.Net#Criticism

Java e .NET sono tristemente famosi per essere dei macigni, il primo poi piu' di tutti!

Quanto ai bugs (cosi' non ti lamenti che ignoro argomenti :D) (e fa pure rima, toh! :sofico: ) saranno pure pochi, ma non e' che non esistano. E' impossibile che un software sia esente da bugs. Inoltre uno puo' anche proporre modifiche al codice solo per aggiungere o modificare delle features, cosa che avviene in Java.

hanno imparato la cosa più importante: che il forking è un cancro, e con la loro licenza l'hanno bloccato alla radice.

Ma fammi fare una risata... il forking e' un cancro? :D
Non fosse stato per i progetti derivati da un forking, non avremmo avuto Firefox e Thunderbird, non avremmo avuto miglioramenti in eMule, non avremmo avuto VLC, non avremmo avuto OpenOffice, non avremmo avuto Notepad++, non avremmo avuto punBB, niente ImgBurn. Se il codice sorgente rimanesse sempre accentrato nelle mani di qualcuno (magari anche dopo la morte stessa del programma stesso), staremmo ancora con il Macintosh pagando cifre pazzesche. Nessuno avrebbe potuto sbattersi per fare il reverse engineering di Napster. Non sarebbe mai esistito Linux, e non sarebbe mai esistito Ubuntu. Miranda e altri client MSN alternativi? Pura utopia! Niente Windows Media Player Classic.

Per non parlare che tutti alla fine copiano codice dagli altri... basti pensare al DOS :rolleyes:

I formati ed i programmi open hanno una fortuna incredibile, quelli chiusi sono stati destinati ad una fine ingloriosa, prima o poi.Infatti si vede proprio, sai.

Ma che vuoi vedere tu? :rolleyes:
Mai sentito parlare di zip, di pdf, di mp3, di jpeg/gif/png, di mpeg, di iso?

A parte i formati Windows imposti con la forza dell'azienda, quale formato chiuso ha spopolato? E non mi parlare di rar per piacere... :sofico:

Microsoft, mi senti dall'alto del kernel? :-P
Sappi che le tue librerie cagose io personalmente non le vorrei copiare neanche se mi pagassi :D Quindi tranquilla.
E allora puoi anche evitare di scrivere in questo thread, no?
Oh bella! E dove sta scritto che devo avere una copia sul mio hd del codice .net per poter postare qui? :D :D

No, assolutamente no! Questa e' una cosa risaputissima, vai in giro su internet a leggere come funziona la licenza Microsoft: non si puo' modificare il codice per nessun motivo. La licenza stessa parla chiaro:
Questo è l'uso che ne puoi fare a livello di compagnia e per lo sviluppo del tuo software. Spedire a MS, e soltanto a lei, un pezzo del suo codice corretto non credo che violi i termini della licenza.
Ma non ho mai detto questo o_0
Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'.
E fortuna che hai specificato "pragmatico". Pragmaticamente parlando il solo fatto che ti ho risposto dimostra che hai torto.
Per la stragrande maggioranza del software ci sono "alternative" (che metto tra virgolette perche' a volte sono i programmi a pagamento o freeware closed ad essere le alternative ai programmi opensource) perfettamente al livello degli altri programmi, se non superiore.
Opinabilissimo. Prendi un equivalente di Office o di Photoshop, giusto per fare un paio di esempi più noti. Ti sconsiglio di citarmi OpenOffice e TheGimp come "valide" alternative (figuriamoci "superiori"), perché sono delle ciofeche al loro confronto.

Ma puoi farmi altri esempi, se vuoi.
Tempo fa collaborai con un utente del forum per fargli fare una sua copia personale di Windows con tutti programmi molto performati. Molti dei programmi che gli suggerii sono opensource. Potete ben vedere da voi se non sono all'altezza del loro compito:

http://www.hwupgrade.it/forum/showthread.php?t=1536793

E questi sono tutti programmi per l'utenza domestica, ma esistono vere e proprie suite per il businness e per l'ufficio.
Opera non è open source.
Miranda è bacato e non supporta correttamente il protocollo MSN.
Thunderbird è bacato, tanto da perdere delle mail.
VLC non sfrutta adeguatamente l'accelerazione hardware.
7-Zip non permette di comprimere in RAR.
OpenOffice ho già detto sopra che fa pietà.
Idem per TheGimp.
Acrobat Reader è closed source.

Mi fermo qui.
E' chiaro che un progetto open source non ti offre la sicurezza assoluta, ma neanche un programma closed. L'unica certezza che ti puo' dare un programma closed e' che i bug saranno scoperti piu' lentamente. E questa puo' essere un'arma a doppio taglio, perche' il bug puo' diventare il cosidetto "segreto di pulcinella", conosciuto da crackers (non in senso di snacks :D) e dalla casa produttrice stessa, ma ignorato finche' una bella fetta di clienti non si lamenta.
Lo stesso può verificarsi col codice open source. Anzi, con l'open source hai il vantaggio di aumentare esponenzialmente la possibilità che un bug venga scovato a usato.
Io semplicemente vedo i risultati. Solitamente i programmi opensource sono meno avidi di risorse e sono gratuiti.
Avidi di risorse? Forse non hai mai lavorato con OpenOffice... E FireFox (senza estensioni) per tua stessa ammissione è più pesante di Opera.
Una persona che vuole entrare nel campo informatico puo' pagare una miseria per l'hardware e poi non spendere piu' un soldo. Hai la certezza che se monti su un sito in PHP sara' piu' performante e compatibile di un sito in ASP.NET.
Falso. PHP è uno dei linguaggi meno performanti (oltre ad avere una sintassi orribile).
Sei sicuro che qualsiasi programma gratuito sara' piu' performante di uno a pagamento.
Falso anche questo. Mi sa che stai generalizzando un po' troppo.
Per fare un esempio, avete mai provato Dreamweaver? Un macigno! Ci sono editor html come Nvu che sinceramente mi fanno passare la voglia di spendere 400 euro e di comprare un computer nuovo.
Nvu ha forse le stesse funzionalità di DW?
L'unico programma a pagamento e closed che veramente vedo in controtendenza e' Nero.
Che nella versione 7 è diventato ancora più pesante. Ma Nero va bene: l'hai detto tu.
Permetta. Giudizio soggettivo un corno! :D
Puoi sempre contestarlo, anziché continuare a cambiare discorso.
http://en.wikipedia.org/wiki/Microsoft_.Net#Criticism

Java e .NET sono tristemente famosi per essere dei macigni, il primo poi piu' di tutti!
Falso. E' scritto chiaro e tondo nello stesso pezzo che hai riportato che ci sono anche casi in cui le prestazioni sono migliori del codice compilato "nativamente".

Tra l'altro dovresti sapere che con .NET il codice è sempre compilato. Ciò avviene generalmente in tempo reale, ma hai anche la possibilità di compilarlo interamente alla prima esecuzione.
Quanto ai bugs (cosi' non ti lamenti che ignoro argomenti :D) (e fa pure rima, toh! :sofico: ) saranno pure pochi, ma non e' che non esistano.
Intanto i bug (non bugs, che è grammaticalmente scorretto) sono oggettivamente pochissimi, e questo è un DATO DI FATTO.
E' impossibile che un software sia esente da bugs.
Falso. E' impossibile, invece, determinare se un software sia corretto o meno (quindi con dei bug). Teoria della computabilità alla mano.
Inoltre uno puo' anche proporre modifiche al codice solo per aggiungere o modificare delle features, cosa che avviene in Java.
E quindi? Cosa vorresti dire?
Ma fammi fare una risata... il forking e' un cancro? :D
Non fosse stato per i progetti derivati da un forking, non avremmo avuto Firefox e Thunderbird, non avremmo avuto miglioramenti in eMule, non avremmo avuto VLC, non avremmo avuto OpenOffice, non avremmo avuto Notepad++, non avremmo avuto punBB, niente ImgBurn. Se il codice sorgente rimanesse sempre accentrato nelle mani di qualcuno (magari anche dopo la morte stessa del programma stesso), staremmo ancora con il Macintosh pagando cifre pazzesche. Nessuno avrebbe potuto sbattersi per fare il reverse engineering di Napster. Non sarebbe mai esistito Linux, e non sarebbe mai esistito Ubuntu. Miranda e altri client MSN alternativi? Pura utopia! Niente Windows Media Player Classic.
Il prezzo da pagare col forking è l'ENORME spreco di risorse umane per fare più volte la STESSA COSA. Anche questo è un dato di fatto.

Molto meglio avere un progetto centralizzato in cui le modifiche da apportare sono discusse collegialmente, e ci sia un gruppo che prende le decisioni per farlo evolvere.

Purtroppo il mondo è pieno di sfigati che credono di avere la verità rivelata e alla prima occasione fanno il fork di un progetto perché non sono d'accordo con la sua evoluzione.

Braccia rubate all'agricoltura.
Per non parlare che tutti alla fine copiano codice dagli altri... basti pensare al DOS :rolleyes:
Spiegati meglio.
Ma che vuoi vedere tu? :rolleyes:
Mai sentito parlare di zip, di pdf, di mp3, di jpeg/gif/png, di mpeg, di iso?
Sì, ne ho sentito parlare: a parte il PNG e ISO sono tutti FORMATI PROPRIETARI, con BREVETTI e LICENZE pendenti. Al pari di WMA, WMV, ecc.
A parte i formati Windows imposti con la forza dell'azienda,
Assolutamente falso anche questo: il mercato è completamente libero.
quale formato chiuso ha spopolato? E non mi parlare di rar per piacere... :sofico:
Hanno spopolato ZIP, PDF, MP3, JPEG, GIF, MPEG, AVI. Vedi sopra.
Oh bella! E dove sta scritto che devo avere una copia sul mio hd del codice .net per poter postare qui? :D :D
L'argomento del thread è chiaro: se non t'interessa puoi anche evitare di scrivere, anziché continuare a riportare informazioni prive di fondamento e speculazioni che può fare chiunque al mercato.

Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'. Per la stragrande maggioranza del software ci sono "alternative" (che metto tra virgolette perche' a volte sono i programmi a pagamento o freeware closed ad essere le alternative ai programmi opensource) perfettamente al livello degli altri programmi, se non superiore.
Beh, ma qui riscadi nella questione "closed source = male"... :mbe:
Sono d'accordo che esistano software alternativi o meno, sia proprietari che aperti: a volte è meglio la variante proprietaria a volte quella aperta. Bisogna fare la considerazione se il costo della versione proprietaria equivale i benefici che apporta e bon... si tratta sempre di considerazioni che può fare l'utente in base agli specifici bisogni che ha. Non si può partire per partito preso.

Io semplicemente vedo i risultati. Solitamente i programmi opensource sono meno avidi di risorse e sono gratuiti. Una persona che vuole entrare nel campo informatico puo' pagare una miseria per l'hardware e poi non spendere piu' un soldo. Hai la certezza che se monti su un sito in PHP sara' piu' performante e compatibile di un sito in ASP.NET. Sei sicuro che qualsiasi programma gratuito sara' piu' performante di uno a pagamento. [...]
Ma questo non è assolutamente vero. A parte PHP, che come conferma anche cdimauro è spaventosamente lento se confontato ad ASP, la stessa cosa vale per MySQL e i database proprietari come SQL server, Oracle... un confronto impietoso: però MySQL è aperto, gratuito e funziona decentemente per cui rimane un'alternativa valida. Pure il confronto Photoshop - The Gimp esiste solo nella mente dei "defender" open-source, perché non c'è veramente paragone.
Ma rimane che The Gimp è un'alternativa valida in alcuni casi. Personalmente uso Paint.NET che è un ottimo piccolo editor, sebbene sia lontano da The Gimp e lontano anni luce da Photoshop (tra parentesi, si appoggia ovviamente .NET, è veloce e soprattutto non ha l'interfaccia orrenda di Gimp :)).

Ma fammi fare una risata... il forking e' un cancro? :D
Il forking non è male a priori (penso che definirlo "cancro" sia un po' troppo), però effettivamente - eccetto in alcuni casi - non serve veramente a nulla. Basta pensare alle migliaia di distribuzioni Linux che esistono: bella la verietà e quello che vi pare, ma il risultato è che ne esistono 5 veramente diffuse, e tutte e 5 devono reinventare di volta in volta la ruota o copiarla dagli altri (con evidente tempo e risorse buttate via, nonché frustrazione degli utenti "medi").
Va bene che Firefox è nato da un fork di Mozilla (mi pare), ma perché non annoverare tra gli effetti del forking anche IceWeasel :doh: che è nato su piattaforma Debian per qualche sciocchezza relativa alle licenze dell'artwork Firefox... E c'è gente che evidentemente perde tempo a prendere il codice di Firefox, fare "sostituisci tutto Firefox->IceWeasel" e ricompilarlo ad ogni release...
Stessa cosa sarebbe da dire di un fork di .NET (o di Java... fortunatamente non ne vedo): pensa alla gente che dovrebbe tenere il tutto al passo del .NET originale e allo sforzo immane degli sviluppori di applicazioni che poi dovrebbero verificare le compatibilità con ogni altra versione o specificare la compatibilità/non compatibilità con le varie versioni di .NET, quando invece il framework è nato proprio per offrire una piattaforma standard ed omogenea di sviluppo.

Per non parlare che tutti alla fine copiano codice dagli altri... basti pensare al DOS :rolleyes:
A dir la verità DOS è stato acquistato, non copiato.
Se ti riferisci alle GUI copiate da Xerox da MS e Apple, che dire... :D


Per la questione dei formati: quelli famosi sono tutti principalmente proprietari, a partire da PDF ed MP3. Comunque concordo con te: sarebbe auspicabile l'utilizzo di formati "aperti" nella maggior parte dei casi. D'altra parte, moltissimi formati "chiusi" sono documentati molto bene (vedi WMA e WMV, o meglio il formato contenitore ASF) e quindi non c'è praticamente differenza dal punto di vista dello sviluppatore.

Imo avete torto entrambi, non si può dire che open-source è meglio di closed-source e neanche viceversa, si può parlare dei singoli progetti e i software ben realizzati o meno esistono da entrambe le parti.

Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'.Se si vuole un CAD a livello di Autodesk Autocad , mi risulta occorra ancora rivolgersi ad Autocad;
gli studi che si occupano di effetti speciali cinematografici ancora prediligono Maya ( guarda caso da qualche tempo della stessa Autodesk);
Windows mantiene il 90% del mercato sul desktop nonostante l' hype che ancora circonda in certi settori, il SW libero e il fatto che questo sia sia fatto conoscere e abbia indotto nell' opinione pubblica una certa "consapevolezza" (quantomeno sull' esistenza di strumenti alternativi)

guardando la situazione da una prospettiva diversa, si potrebbe quindi dire l' esatto contrario - il closed source è vivo e vegeto, ed è qui per restare ( magari non in tutti i settori in cui prima era l' unica opzione, e magari accentrandosi e attraversando una evoluzione non indifferente, ma non è pensabile scompaia del tutto dall' oggi al domani) ;)

il motivo è semplice e ha a che fare con la ripartizione tra applicazioni cosiddette "orizzontali" e "verticali"
le prime, generiche, il cui utilizzo è alla portata di tutta ( o della maggior parte del -) l' utenza e al cui sviluppo può contribuire tutto il ( o la maggior parte del ) bacino dei potenziali sviluppatori, compresi quelli appassionati sì, ma privi di particolari skill in ambiti specifici (a volte privi anche di quelli che dovrebbero essere requisiti basilari per il mestiere stesso di sviluppatore sw, come adeguate capacità di astrazione, design, valutazione e rispetto di linee guida di progetto eccetera - e questo si riflette in una progettazione non accurata e sulla qualità del risultato finale, ma sorvoliamo )

le seconde, specialistiche, il cui utilizzo richiede competenze non banali riguardo il dominio applicativo (in pratica il significato delle grandezze che il programma consente di manipolare , e delle operazioni che si possono eseguire ) e una sua padronanza ancora più approfondita da parte di l' applicazione si trova a svilupparla

ora, se per esempio un grafico professionista, cercherà di trarre il massimo profitto dalle proprie capacità e per realizzare un manifesto, una brochure, per animare dei personaggi di un film di animazione, o per realizzare gli effetti speciali di un film, vorrà essere pagato in proporzione alla complessità del lavoro e alla difficoltà, per il committente, di trovare un' altra persona che sia altrettanto capace ma che faccia lo stesso lavoro a minor costo, altrettanto farà uno sviluppatore grafico capace di fornire al creativo di cui sopra uno strumento di qualità
una persona capace di scrivere un sistema di modellazione e animazione allo stesso livello di Maya o superiore, o un engine 3d allo stesso livello di Crysis o superiore, con molta probabilità si proporrà a (anzi, è più probabile venga cercato da) una SW house, prima di considerare l' eventualità di regalare al mondo il proprio lavoro per la gloria che ne potrebbe conseguire...
Ma fammi fare una risata... il forking e' un cancro? :D il forking è uno dei modi in cui nel mondo dello sviluppo software, qualcuno (chiunque) può affermare la propria esistenza e far contare la propria opinione - se non è un cancro, è un dato di fatto che spesso se ne abusi, in certi casi in modo eclatante
Non fosse stato per i progetti derivati da un forking, non avremmo avuto Firefox e Thunderbird, Firefox e TB sono figli di Mozilla, nome che che prima di essere associato a una Fondazione identificava un' applicazione derivata a sua volta dalla code base del vecchio Netscape Navigator - non sono stati forkati
non avremmo avuto miglioramenti in eMulese ti riferisci ad esempio a emule Morph, questa come le altre sono mods, non veri e propri fork perchè il loro codice è in sincrono con le release regolari di eMule
non avremmo avuto OpenOfficeanche openoffice non è un fork, è StarOffice reso open source dopo un certo tempo dall' acquisizione da parte di Sun, della ditta tedesca che lo sviluppava
Se il codice sorgente rimanesse sempre accentrato nelle mani di qualcuno (magari anche dopo la morte stessa del programma stesso), staremmo ancora con il Macintosh pagando cifre pazzesche.non mi sembra che il prezzo al dettaglio di Mac OS X o di Windows risentano granchè della presenza di Linux...
se Linux, meglio, se Ubuntu, fosse percepito come concorrente da battere sul mercato, una licenza verrebbe fatta pagare pochi euro o magari addirittura regalata accollandosi le spese di spedizione, seguendo l' esempio di Canonical - ma ciò non accade
e questo conferma che Apple ed MS semplicemente "vanno per la propria strada", e i prezzi che fanno per i propri OS ( oramai ricchi di parecchio SW accessorio peraltro) sono quelli che gli permettono di rientrare nell' investimento richiesto per lo sviluppo e nei costi inerenti il ciclo di vita del prodotto
Non sarebbe mai esistito Linux, e non sarebbe mai esistito Ubuntu. Linux non è nato dal fork di qualche precedente progetto ( in compenso ci sono stati tentativi di fork del kernel, poi giunti a un punto morto ) ma come implementazione software libera di specifiche aperte - cioè come clone di unix, all' epoca esistente in forma sia commerciale sia "accademica", tra l'altro già frammentato nei vari famigerati "dialetti", ma comunque caratterizzato da una interfaccia programmatica di sistema ( non binaria ) approssimativamente uniformata tra le diverse varianti , cioè le specifiche posix
infatti di linux inzialmente si diceva " non è unix, è un sistema operativo comaptibile a livello sorgente con unix" - che diventasse lui stesso sinonimo di "unix" come implementazione più vastamente diffusa, è qualcosa che è avvenuto in seguito...
e altri client MSN alternativi? Pura utopia! Niente Windows Media Player Classic.qui, stai confondendo il forking con il reverse engineering e la reimplementazione (del protocollo di comunicazione del client IM)
Niente Windows Media Player Classic.afaik Gabest non ha forkato alcunchè ma ha scritto ex novo il codice di MPC (che di WMP riprenderebbe solo look and feel e widget di sistema utilizzati, non l' implementazione...)
Mai sentito parlare di zip, di pdf, di mp3, di jpeg/gif/png, di mpeg, di iso?un file .iso è l' immagine statica di un filesystem standardizzato, quindi è una specifica aperta per forza di cose - ma l' .mp3 è soggetto a brevetti, NON è affatto un formato aperto ( e, sebbene sia lo standard di fatto per i riproduttori audio a stato solido, non è il formato con la maggior qualità sonora, nemmeno tra quelli lossy ) prova ne è il fatto che certe distribuzioni linux gratuite, o quelle che rifuggono la proprietà intellettuale protetta, evitano di includere il codec relativo, con il risultato che l' utente deve installarlo per conto proprio

l' impressione dagli esempi che riporti, è che tu abbia frainteso il significato di fork e le sue implicazioni ...
un fork è uno snapshot di una code base preesistente su cui poi si procede con la rimozione delle caratteristiche che si ritengono superflue e l' aggiunta di quelle che si ritengono valide ma lo sviluppatore originale non aveva implementato per motivi di filosofia, di design, o anche solo di tempo

Un fork è ad esempio quello che tempo fa tale Ali Akcaagac creò con il progetto Goneme, quando fu frustrato dalla piega che stava prendendo quello da cui ha forkato (Gnome) - non gradiva il troppo "rivoluzionario" "Spatial Browsing" di Nautilus (il browsing "spaziale" è basato sul paradigma opposto a quello "navigazionale" - invece che essere la "posizione corrente nella sessione di browsing", ogni cartella è un "oggetto" associata a una finestra indipendente la cui posizione viene ricordata alle successive aperture - sì , in Esplora Risorse esistono entrambe le modalità da parecchio ) non gradiva le dipendenze di gnome da glade, e non gradiva l' atteggiamento "meritocratico" della comunità di Gnome - ora, GoneMe non ha avuto successo, ma se lo avesse avuto, probabilmente avrebbe sottratto a Gnome sviluppatori per la creazione dell' ennesimo DE gtk based sotto Linux...

Inoltre considera un fatto - Compiz è stato forkato nel progetto Beryl, ma dopo nemmeno un anno i due progetti si sono riuniti ;)

In generale si può dire che un fork ha senso in determiinate situazioni - a volte per salvare una code base dalle folli decisioni di chi ha creato il progetto originario e/o per il bene della comunità ( vedi caso Xfree86 / Xorg in cui fu coinvolto un cambio di licenza, oppure AtheOS / Syllable, in cui il creatore di un OS amatoriale abbandonò l' informatica per dedicarsi ad altri hobby a dispetto di chi riteneva il suo codice promettente) a volte per sperimentare una propria soluzione implementandola come parte di una code base preesistente senza dover partire da zero (è utile ricordare che linux nacque dal codice di minix, sotituito progressivamente... )
ma qualora team separati lavorino agli stessi problemi mettendovi soluzioni conciliabili, è a tutti gli effetti una duplicazione di sforzi e uno spreco di risorse
No, assolutamente no! Questa e' una cosa risaputissima, vai in giro su internet a leggere come funziona la licenza Microsoft: non si puo' modificare il codice per nessun motivo. La licenza stessa parla chiaro:il problema è che troppo spesso si confonde "open source" con "free software", e si considerano entrambe le definizioni sia metodi di sviluppo che di distribuzione del codice (ma l' "open source" è prevalentemente una politica di ridustribuzione del codice, solutamente informa liberale ma non necessariamente, mentre il free SW è principalmente una forma di sviluppo distribuito)
non posso ridistribuire a terzi il codice microsoft, non posso modificarlo E distribuire il codice modificato ad altri che no nsiano MS, e non posso forkarlo creando un mio progetto - non è codice libero nel senso stallmaniano del termine
posso però usarlo in forma binaria e ( da sviluppatore) leggere il sorgente - la licenza è una licenza "open source" a tutti gli effetti

considera anche un altro aspetto - la API del framework è pubblica, e questo è fondamentale: vuol dire che l' interfaccia programmatica è standardizzata e forma un "contratto" tra il framework stesso e ogni possibile applicazione di terze parti sviluppate per esso
eventuali modifiche non possono essere più invasive del correggere bug interni a qualche metodo, perchè si implicherebbe la rottura di quel "contratto"
per questo, chi potenzialmente si trovi ad esaminare quel codice, è tutt' al più interessato ad eventuali idiosincrasie di particolari metodi che la sua applicazione chiami, e che potrebbero inficiare il comportamento di questa a runtime - il "miglioramento" del framework a beneficio della "comunità" non è un suo obiettivo, ed è normale che non lo sia - l' evoluzione del framework è di competenza di MS, non sua
Ma che vuoi vedere tu? :rolleyes: evitiamo l' ironia e il sarcasmo, per favore...

il forking è uno dei modi in cui nel mondo dello sviluppo software qualcuno (chiunque) può affermare la propria esistenza e far contare la propria opinione
se non è un cancro, è un dato di fatto che spesso se ne abusi, in certi casi in modo eclatante
*

non c'entra col forking, ma, a proposito dello "spreco" di risorse umane, mi viene anche da aggiungere che sempre più in alcuni progetti open (non che accada solo con quelli open) anche importanti nel loro ambiente, si riscontra la tendenza ad espandersi in maniera multi-funzionale, "suite-like", ma non in modo strettamente connesso alla natura originale/principale del progetto:

per esempio i due maggiori desktop env. per linux(e non solo)... i due progetti portano avanti ormai non solo lo sviluppo del d.e. in sé ma a anche un affollamento di apps di varia natura...

nel medio/lungo termine non sarebbe più proficuo per l'evoluzione dell'ambiente grafico se gli sforzi si concetrassero esclusivamente nel d.e. stesso (con l'eccezzione di un file manager lato apps) , nel toolkit grafico usato per svilupparlo, in poche "applet"(o una unica) autorefernziali(volte cioè alla configurazione/gestione del d.e. stesso) ed al limite di un ulteriore framework per lo sviluppo di apps per tale ambiente che sia un sovrainsieme/wrapper del toolkit grafico ?
(anche se forse su linux non sarebbe male una più ampia tendenza anche nei framwork più "complessi/potenti->dev-friendly" ad essere "d.e.-indipendent")

tra l'altro... se non ricordo male anche il nome "unix" nacque in filosofica contrapposizione con "multics", con riferimendo all'idea di semplicità intesa come diversi specifici "tool" per diversi specifici compiti anziché grossi programi multifunzionali ... :sofico:
(il che, guardando nuovamente al mondo attuale, non significa che poi nell'ambito della "presentazione" all'utente non si possano dare visioni accentrate/ben organizzate

ps: non ho nulla contro kde o gnome, era solo per fare un esempio di un pensiero più generale, alla fine poi cmq più volto ad esporre un interrogativo che mi pongo che ad affermare certezze

Se si vuole un CAD a livello di Autodesk Autocad , mi risulta occorra ancora rivolgersi ad Autocad;

[...]

Windows mantiene il 90% del mercato sul desktop nonostante l' hype che ancora circonda in certi settori

Su Windows il discorso sarebbe troppo lungo ;-)
Su Autocad e programmi simili le alternative ci sono, penso ad esempio al CAD scritto nel glorioso linguaggio Python (:D) http://www.pythoncad.org/
Ovviamente Autocad e' il piu' conosciuto ed usato, non ho mica detto che tutti i programmi closed sono stati superati. Anzi ho fatto giustappunto l'esempio di Nero, per il quale attualmente non esiste un'alternativa reale.

Se facciamo un discorso di diffusione, non sempre i programmi migliori hanno fortuna. Molti dei programmi da me usati e citati qui e nel thread di "windows con poche risorse" sono misconosciuti ai piu'.

Tanto per dire una banalita', un giorno ho aiutato la mia dottoressa (un'anziana signora, non pensate a secondi fini... :D) a mettere a posto il suo pc. Gli ho installato Spybot, trovati circa 5 malware (tra cui un sito come homepage di IE di nome googler.com o qualcosa del genere). Gli ho disinstallato il McAfee (il vero virus del computer secondo me :-P), ho installato Avira Antivir, gli ho trovato circa 6-7 virus. E il bello e' che era convinta di avere due antivirus, il McAdee ed il Norton... a parte che scommetto che non sarebbe neanche partito il pc :D in realta' ha installata un'utility di Norton che sostituisce molte funzioni di backup di Windows. Non so chi gliel'abbia venduta, ma lei era convinta che gli avessero messo un antivirus... quindi chissa' i soldi che ci avra' speso inutilmente. E quando gli ho suggerito di installare Firefox al posto di IE, mi ha detto "ah meglio di no, non voglio fare casini!"
...... :rolleyes:

guardando la situazione da una prospettiva diversa, si potrebbe quindi dire l' esatto contrario - il closed source è vivo e vegeto, ed è qui per restare ( magari non in tutti i settori in cui prima era l' unica opzione, e magari accentrandosi e attraversando una evoluzione non indifferente, ma non è pensabile scompaia del tutto dall' oggi al domani) ;)

Dunque, il discorso e' giusto, ma e' sbagliato che sia in risposta alle mie affermazioni. Io ho semplicemente fatto notare come l'open source (anzi il freesoftware ;)) abbia un modello vincente, e come stia rosicchiando, se non in certi casi eclatanti surclassando, le soluzioni closed e a pagamento. Non ho mai detto che il closed scomparira' domani. A dire il vero non penso che scomparira' mai, e' assurdo solo pensarlo.

Firefox e TB sono figli di Mozilla, nome che che prima di essere associato a una Fondazione identificava un' applicazione derivata a sua volta dalla code base del vecchio Netscape Navigator - non sono stati forkati

----------------

se ti riferisci ad esempio a emule Morph, questa come le altre sono mods, non veri e propri fork perchè il loro codice è in sincrono con le release regolari di eMule

----------------

anche openoffice non è un fork, è StarOffice reso open source dopo un certo tempo dall' acquisizione da parte di Sun, della ditta tedesca che lo sviluppava

----------------

l' impressione dagli esempi che riporti, è che tu abbia frainteso il significato di fork e le sue implicazioni ...
un fork è uno snapshot di una code base preesistente su cui poi si procede con la rimozione delle caratteristiche che si ritengono superflue e l' aggiunta di quelle che si ritengono valide ma lo sviluppatore originale non aveva implementato per motivi di filosofia, di design, o anche solo di tempo


Mozilla Firefox [...] started as a fork of the Navigator browser component of the Mozilla Application Suite.
http://en.wikipedia.org/wiki/Firefox

In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software.
http://en.wikipedia.org/wiki/Fork_%28software_development%29

A kind of fork that is standard practice in many projects is a stable or release version, modified only for bug fixes, while a development tree develops new features. Such forks are often referred to instead as "branches" both to avoid the negative connotations of a fork and because it is closer in intent and function to the common software engineering meaning of branching.
http://en.wikipedia.org/wiki/Fork_%28software_development%29#Branching

;)

Linux non è nato dal fork di qualche precedente progetto ( in compenso ci sono stati tentativi di fork del kernel

----------------

qui, stai confondendo il forking con il reverse engineering e la reimplementazione (del protocollo di comunicazione del client IM)

Ma lo so, non stavo facendo esempi di forking. Gli esempi di forking erano solo quelli precedenti. Stavo citando casi nei quali e' stato usato del codice preesistente per creare un progetto simile ma con obiettivi diversi. cdimauro parlava di forking, ma in realta' se vedi bene io stavo facendo un discorso piu' generale. Gia' parlare di forking di terze parti per un prodotto a pagamento non ha molto senso... ;-)

l' .mp3 è soggetto a brevetti, NON è affatto un formato aperto

Effettivamente qui ho fatto un pasticcio con i termini. Non volevo riferirmi ai formati aperti, ma agli standard aperti. Insomma, a formati che sia possibile decodificare e codificare in programmi terzi. Anche l'mp3 e' cosi', anche se purtroppo dovresti pagare una follia di licenza. Comunque, infatti, il formato mp3 ormai sta per essere ampiamente superato... ;)

Per fare un esempio scemo, il formato .rar puo' essere decodificato ma non codificato. Puoi cioe' estrarre un archivio in formato rar con un programma terzo, ma solo con WinRar puoi creare archivi RAR. Cosi' anche per il formato DOC.

Certo, alla fine la fortuna di un formato, come per un software, non dipende certo dal fatto che sia free o closed, ma piuttosto dal fatto che sia buono o no. Ma a parita' di prestazioni e di bonta' del progetto, credi che un formato chiuso abbia sviluppo piu' rapido di uno aperto? ;)

non mi sembra che il prezzo al dettaglio di Mac OS X o di Windows risentano granchè della presenza di Linux...

Veramente in questo caso mi stavo riferendo a Windows.... ;-)
Ripeto, il mio e' un discorso piu' generale. Se nessuno proponesse alternative, ma lavorassero tutti allo stesso progetto, non ci sarebbe una vera evoluzione informatica. Anzi, se applicassimo questo concetto a qualunque lavoro, non ci sarebbe evoluzione e basta!

il problema è che troppo spesso si confonde "open source" con "free software"
[...]
non posso ridistribuire a terzi il codice microsoft, non posso modificarlo E distribuire il codice modificato ad altri che no nsiano MS, e non posso forkarlo creando un mio progetto - non è codice libero nel senso stallmaniano del termine
posso però usarlo in forma binaria e ( da sviluppatore) leggere il sorgente - la licenza è una licenza "open source" a tutti gli effetti

Mah, io non stavo discutendo se il software adesso possa essere considerato open source o meno... stavo soltanto evidenziando come secondo la licenza non possono essere fatte modifiche per alcun motivo, neanche per proporle alla Microsoft. Grazie che e' "open source", si puo' leggere il codice! :D La so la differenza tra "software open source" e "software libero" ;) se ho parlato di open source intendendo software libero e' perche' ormai ho preso il viziaccio anch'io di usare solo il termine opensource ^___^

considera anche un altro aspetto - la API del framework è pubblica, e questo è fondamentale: vuol dire che l' interfaccia programmatica è standardizzata e forma un "contratto" tra il framework stesso e ogni possibile applicazione di terze parti sviluppate per esso
eventuali modifiche non possono essere più invasive del correggere bug interni a qualche metodo, perchè si implicherebbe la rottura di quel "contratto"
per questo, chi potenzialmente si trovi ad esaminare quel codice, è tutt' al più interessato ad eventuali idiosincrasie di particolari metodi che la sua applicazione chiami, e che potrebbero inficiare il comportamento di questa a runtime - il "miglioramento" del framework a beneficio della "comunità" non è un suo obiettivo, ed è normale che non lo sia - l' evoluzione del framework è di competenza di MS, non sua

Ma guarda che si poteva fare secondo il modello Java, come ho gia' detto. Si propongono modifiche e la Sun decide se accettarle o meno. Invece la Microsoft non da' neanche questa possibilita', perche' semplicemente ha paura che queste modifiche circolino su internet e si aggreghino in un progetto alternativo. Sai quanto gliene puo' fregare del beneficio alla comunita' :D

evitiamo l' ironia e il sarcasmo, per favore...

Eh, ma non e' colpa mia, e' che mi escono cosi' spontanee.... :D


Comunque, facendo un piccolo brainstorming sul forking, e rispondendo cosi' anche a MenageZero, sul forking "di terze parti". Perche' ovviamente esistono anche forks che partono dai dev stessi del software, magari per sviluppare un'idea alternativa o semplicemente per testare una versione futura in fase alpha, ma nel frattempo sviluppare ancora la versione stabile.

Comunque, il forking che parte da persone esterne al progetto nasce spesso come un'esigenza. Un utente ha un'idea, la propone agli sviluppatori del progetto. Gli sviluppatori gli rispondono picche perche':
- non rientra nelle finalita' del progetto
- non hanno tempo
- non gli sembra cosi' utile
- e' una modifica che non genera codice pulito
- richiederebbe troppo rewriting
- a loro non piace "concettualmente"
- e' dannosa per tizi cai e semproni (nel qual caso, se e' vero, e' giusto non implementarla)
- chi la propone sta sulle balle a tutti :D

Alla fine i developers potrebbero comunque ospitare la modifica sul loro sito e dare vita cosi' a forking "ufficiali", ma non si fiderebbero certo a dare username e password del sito a chiunque. Certo potrebbero creare un account con limitazioni, ma sai che sbattitura? Allora dovrebbero creare almeno un link, e quando viene aggiornato anche il fork il tizio dovrebbe inviargli il file e loro dovrebbero upparlo... una rottura di ca**i anche questa.

E cosi' nasce il fork non ufficiale. Ma non ci vedo nulla di male. Se l'idea era valida ed i developers non sono dei minc***oni, prima o poi i due progetti si uniranno, come infatti facevi presente citando Compiz. Se il forking soppianta l'idea originale poco male anche li', si spera che il fork fosse effettivamente migliore (anche se la certezza non c'e' :P). Se il fork fallisce, puo' essere perche' l'idea era effettivamente una cavolata, o semplicemente perche' l'ideatore non ha saputo "venderla", oppure perche' i developers del progetto originale sono effettivamente dei minc***oni e non se la sono mai cagata neanche di striscio. In tal caso la cosa e' negativa, ma se non ci fosse stata la possibilita' di forking il progetto non sarebbe neanche iniziato.

Certo, le persone che lavorano ai forks potrebbero invece aiutare il progetto originale. Ma probabilmente 1) il gruppo dei devs e' elitario e non lo ha accettato, e/o 2) lui non e' interessato a lavorare come dev al progetto, ma solo alla sua idea alternativa. Quindi lo spreco di risorse non lo vedo... vedo piuttosto idee (e persone) intelligenti e idee stupide, ed il forking da' la possibilita' di fare tutte e due a tutti e due le tipologie di persone ^____^. Sta' poi allo sviluppatore ed all'utente a scegliere il giusto percorso e prodotto ;)

Ma questo non è assolutamente vero. A parte PHP, che come conferma anche cdimauro è spaventosamente lento se confontato ad ASP

Ma non so secondo quali fonti ;)

If we compare the speed of ASP and PHP then PHP has an upper hand. PHP code runs faster than ASP. ASP is built on COM based architecture, which is an overhead for the server whereas PHP code runs in its own memory space.
http://www.webpronews.com/expertarticles/2005/12/22/asp-vs-php

E inoltre:

Compiled Code vs. PHP Interpreted Code .NET compiles code, such as C#, into what its creators have termed MSIL, or Microsoft Intermediate Language. This roughly resembles Java's bytecode, the "binary" you have after you compile the source code. PHP, as an interpreted language, doesn't really have an equivalent here. [...]

Saying that PHP is strictly interpreted and that ASP.NET code is compiled is a bit misleading, as evidenced by the common language runtime environment I've described. What's more, with PHP as well as ASP.NET pages, you can configure your respective Web servers to do connection pooling and caching of those pages, so they don't have to be recompiled each time. Inevitably, those PHP pages will compile into smaller pieces than the equivalent ASP.NET page, because there is more overhead with the intermediate compilation with the CLR. Ultimately, this will mean greater memory requirements on your Web server.
http://www.oracle.com/technology/pub/columns/hull_php2.html

Per MySQL, non ci ho mai fatto riferimento. Se dovessi prendere un esempio calzante, direi piuttosto PostGres ;)

Per GIMP... lasciamo perdere va'.... :rolleyes:

Per il DOS, basta documentarsi un attimo... cerca "Gary Kildall" ;)

Ma non so secondo quali fonti ;)
[...]
Per MySQL, non ci ho mai fatto riferimento. Se dovessi prendere un esempio calzante, direi piuttosto PostGres ;)
[...]
Boh, qui (http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=php&lang2=csharp) pare il contrario. Ma comunque non era certo mia intenzione dimostrare che "PHP fa schifo" (anche perché non è così): del resto potremmo stare per altre 8 pagine a dibattere cosa sia meglio "aldiqua" e "aldilà" della staccionata "open" e non risolveremmo proprio nulla, anche perché - mi pare di averlo scritto - non esistono un bene ed un male assoluti. Dovremmo solo cercare di avere la visione più neutrale possibile e fare valutazioni obiettive delle potenzialità dei diversi prodotti, perché ovviamente esistono cose validissime sia open che closed (ed esistono delle porcherie open e closed... :)).

Per tornare al punto originale dell'articolo, rimango dell'idea che .NET "chiuso" sia un beneficio per tutti (nella fattispecie programmatori che ci lavorano). Perché se, ipoteticamente, si potessero veramente proporre delle modifiche al framework ed eventualmente proporre dei framework "forkati" con le proprie alterazioni si avrebbe solamente una perdita di generalità di .NET.
Consideriamo anche i framework GUI alternativi sempre su .NET (tipo GTK.net o wx.NET, un derivato delle wxWidgets). Sono delle ottime librerie aggiuntive per .NET, che però hanno il problema di dipendere da altri componenti che non sono presenti di base nel framework. Il bello invece delle WinForms è che sono nativamente implementate su ogni variante di .NET, che sia l'originale MS, Mono o il Compact.NET. Di guadagnato c'è appunto che l'utente non deve impazzirsi ad installare pacchetti aggiuntivi e che lo sviluppatore va a colpo sicuro in quanto a compatibilità.

Per il DOS, basta documentarsi un attimo... cerca "Gary Kildall" ;)
Non conoscevo la vicenda in dettaglio. Ma a quanto dice Wikipedia la "copiatura" si limita alle API, per il resto rimangono solo "voci" e niente di confermato... :stordita:

Dipende dalle esigenze e da cosa si vuole fare... io ad esempio sto sviluppando un software rivoluzionario :D che utilizza concetti rivoluzionari :D e col quale in futuro ho intenzione di camparci vita natural durante (es. licenziando la tecnologia): mi sembra perferramente ovvio che non solo sarà codice proprietario, ma farò il possibile perchè il codice rimanga il più possibile riservato, per evitare che altri possano prendere spunto dalle MIE idee e soluzioni e marciarci sopra.

Boh, qui (http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=php&lang2=csharp) pare il contrario.

Mh, aspetta, li' hai fatto un raffronto tra un programmi compilato in C# e un programma in PHP. Non e' un raffronto tra un'applicazione web scritta in ASP.NET (che non e' propriamente un linguaggio compilato, ma e' poi tradotto in bytecode) e una PHP.
Tra l'altro anche il PHP ha pacchetti aggiuntivi che permettono la creazione di una specie di bytecode per PHP ed il caching degli script.

potremmo stare per altre 8 pagine a dibattere cosa sia meglio "aldiqua" e "aldilà" della staccionata "open" e non risolveremmo proprio nulla, anche perché - mi pare di averlo scritto - non esistono un bene ed un male assoluti.
Sono completamente d'accordo, io volevo fare piu' che altro un confronto tra strategie di sviluppo del software infatti :-)

Per tornare al punto originale dell'articolo, rimango dell'idea che .NET "chiuso" sia un beneficio per tutti (nella fattispecie programmatori che ci lavorano). Perché se, ipoteticamente, si potessero veramente proporre delle modifiche al framework ed eventualmente proporre dei framework "forkati" con le proprie alterazioni si avrebbe solamente una perdita di generalità di .NET.
Consideriamo anche i framework GUI alternativi sempre su .NET (tipo GTK.net o wx.NET, un derivato delle wxWidgets). Sono delle ottime librerie aggiuntive per .NET, che però hanno il problema di dipendere da altri componenti che non sono presenti di base nel framework. Il bello invece delle WinForms è che sono nativamente implementate su ogni variante di .NET, che sia l'originale MS, Mono o il Compact.NET. Di guadagnato c'è appunto che l'utente non deve impazzirsi ad installare pacchetti aggiuntivi e che lo sviluppatore va a colpo sicuro in quanto a compatibilità.

Mh. Non sono d'accordo con il discorso che fai... un conto e' dover installare librerie aggiuntive, un conto e' utilizzare un progetto derivato.
Ora, un progetto derivato dal .NET si parte dal presupposto sia compatibile con il .NET stesso. Mettiamo il caso che io prenda il codice del .NET 3 e lo renda compatibile con le versioni precedenti di .NET. Il guadagno da parte dei programmatori e' enorme, perche' non devono mettersi a riscrivere programmi gia' implementati con l'uso di una versione precedente di .NET. L'impossibilita' di sviluppare codice indipendentemente blocca a priori qualsiasi possibilita' di retrocompatibilita', perche' e' chiaro che la Microsoft non ha alcun interessa a spenderci dei soldi, altrimenti lo avrebbe gia' fatto da tempo.

Non conoscevo la vicenda in dettaglio. Ma a quanto dice Wikipedia la "copiatura" si limita alle API, per il resto rimangono solo "voci" e niente di confermato... :stordita:

Aspetta, un accidente... ;-) Non ha copiato solo l'API, ma e' stato dimostrato che ben 26 system call erano identiche. Ed infatti, molto dopo la morte di Kildall, il suo amico Harold Evans ha vinto la causa contro Tim Paterson:

http://punto-informatico.it/p.aspx?i=2050079
http://www.theregister.co.uk/2007/07/30/msdos_paternity_suit_resolved/

Mettiamo il caso che io prenda il codice del .NET 3 e lo renda compatibile con le versioni precedenti di .NET. Il guadagno da parte dei programmatori e' enorme, perche' non devono mettersi a riscrivere programmi gia' implementati con l'uso di una versione precedente di .NET. L'impossibilita' di sviluppare codice indipendentemente blocca a priori qualsiasi possibilita' di retrocompatibilita', perche' e' chiaro che la Microsoft non ha alcun interessa a spenderci dei soldi, altrimenti lo avrebbe gia' fatto da tempo.

Mettiamo il caso che un giorno si scopra che quel codice contenesse una grave falla e che questa venga corretta nel ".NET Framework 3.0a". Se tutti avessero fatto come dici "prendendo codice" dal framework ed "incorporandolo" nel proprio progetto (per motivi di retrocompatibilità), non basterebbe aggiornare il framework alla "3.0a" per mettersi al riparo dalla falla, perchè ci sarebbero in giro svariati software con una propria versione bacata della libreria.

Mh. Non sono d'accordo con il discorso che fai... un conto e' dover installare librerie aggiuntive, un conto e' utilizzare un progetto derivato.
Ora, un progetto derivato dal .NET si parte dal presupposto sia compatibile con il .NET stesso. Mettiamo il caso che io prenda il codice del .NET 3 e lo renda compatibile con le versioni precedenti di .NET. Il guadagno da parte dei programmatori e' enorme, perche' non devono mettersi a riscrivere programmi gia' implementati con l'uso di una versione precedente di .NET. L'impossibilita' di sviluppare codice indipendentemente blocca a priori qualsiasi possibilita' di retrocompatibilita', perche' e' chiaro che la Microsoft non ha alcun interessa a spenderci dei soldi, altrimenti lo avrebbe gia' fatto da tempo.


Non credo di aver ben capito la sua posizione. In ogni caso, posto il link di un mio intervento sul discorso retrocompatilità, tanto per fare un po' di chiarezza:

http://www.hwupgrade.it/forum/showthread.php?p=19092638&posted=1

Consideriamo anche i framework GUI alternativi sempre su .NET (tipo GTK.net o wx.NET, un derivato delle wxWidgets). Sono delle ottime librerie aggiuntive per .NET, che però hanno il problema di dipendere da altri componenti che non sono presenti di base nel framework. Il bello invece delle WinForms è che sono nativamente implementate su ogni variante di .NET, che sia l'originale MS, Mono o il Compact.NET. Di guadagnato c'è appunto che l'utente non deve impazzirsi ad installare pacchetti aggiuntivi e che lo sviluppatore va a colpo sicuro in quanto a compatibilità.

Si... con un look 'n feel da vomito però. Nel mio ambientino GTK-based, Mono con GTK# si adatta alla perfezione... invece con WinForms avrei qualcosa che sarebbe, appunto, assolutamente "vomitevole".

Su Windows il discorso sarebbe troppo lungo ;-)
Su Autocad e programmi simili le alternative ci sono, penso ad esempio al CAD scritto nel glorioso linguaggio Python (:D) http://www.pythoncad.org/
Ovviamente Autocad e' il piu' conosciuto ed usato, non ho mica detto che tutti i programmi closed sono stati superati. Anzi ho fatto giustappunto l'esempio di Nero, per il quale attualmente non esiste un'alternativa reale.
Hai detto qualcosa di simile:

"Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'. Per la stragrande maggioranza del software ci sono "alternative" (che metto tra virgolette perche' a volte sono i programmi a pagamento o freeware closed ad essere le alternative ai programmi opensource) perfettamente al livello degli altri programmi, se non superiore."

Quindi il mondo è già stradominato dalle soluzioni open source, che sono ALMENO a livello di quelli closed.

Peccato che, a parte te, nessuno ne sia ancora accorto.
Tanto per dire una banalita', un giorno ho aiutato la mia dottoressa
[...]
E quando gli ho suggerito di installare Firefox al posto di IE, mi ha detto "ah meglio di no, non voglio fare casini!"
...... :rolleyes:
Mi sembra anche giusto: magari ha dei siti, come quelli di tante banche, che funzionano soltanto con IE (io lo uso solo per questo; per tutto il resto adopero e adoro Opera), e non avrebbero più funzionato con FF.
Dunque, il discorso e' giusto, ma e' sbagliato che sia in risposta alle mie affermazioni. Io ho semplicemente fatto notare come l'open source (anzi il freesoftware ;)) abbia un modello vincente,
Hai fatto? E in base a cosa sostieni che sarebbe "vincente"?
e come stia rosicchiando, se non in certi casi eclatanti surclassando, le soluzioni closed e a pagamento.
Capita: nessuno qui ha detto che non esistono prodotti d'eccellenza anche nel mondo del software gratuito.
Non ho mai detto che il closed scomparira' domani. A dire il vero non penso che scomparira' mai, e' assurdo solo pensarlo.
Veramente tu hai scritto questo:

"I formati ed i programmi open hanno una fortuna incredibile, quelli chiusi sono stati destinati ad una fine ingloriosa, prima o poi."

che mi sembra piuttosto lapidaria come frase.

La prossima volta metteti d'accordo con te stesso...
Ma lo so, non stavo facendo esempi di forking. Gli esempi di forking erano solo quelli precedenti. Stavo citando casi nei quali e' stato usato del codice preesistente per creare un progetto simile ma con obiettivi diversi. cdimauro parlava di forking, ma in realta' se vedi bene io stavo facendo un discorso piu' generale. Gia' parlare di forking di terze parti per un prodotto a pagamento non ha molto senso... ;-)
Io ho parlato propriamente di forking: non mi confondo quando si tratta di termini informatici dal preciso significato.
Effettivamente qui ho fatto un pasticcio con i termini. Non volevo riferirmi ai formati aperti, ma agli standard aperti. Insomma, a formati che sia possibile decodificare e codificare in programmi terzi. Anche l'mp3 e' cosi', anche se purtroppo dovresti pagare una follia di licenza. Comunque, infatti, il formato mp3 ormai sta per essere ampiamente superato... ;)
E da cosa dovrebbe essere superato? Perché la sua fama nonché diffusione non mi sembrano calare. Tutt'altro.

Comunque MP3 è un formato PROPRIETARIO con brevetti e licenze pendenti. Questo anche se le specifiche sono disponibili.

Quindi esattamente come per il WMA di MS, per cui il tuo giudizio positivo sull'MP3 lo si estende anche a quest'ultimo (idem per MPEG e WMV).
Per fare un esempio scemo, il formato .rar puo' essere decodificato ma non codificato. Puoi cioe' estrarre un archivio in formato rar con un programma terzo, ma solo con WinRar puoi creare archivi RAR.
Perché nessuno ha creato un compressore, ma le specifiche del formato sono disponibili.
Cosi' anche per il formato DOC.
Assolutamente falso (altrimenti OpenOffice, come pure tanti altri programmi, come farebbero?).

Tra l'altro sei pure male informato, perché fino ad Office '97 (che è il più diffuso) MS ha pubblicato le specifiche dei formati dei suoi prodotti.
Certo, alla fine la fortuna di un formato, come per un software, non dipende certo dal fatto che sia free o closed, ma piuttosto dal fatto che sia buono o no. Ma a parita' di prestazioni e di bonta' del progetto, credi che un formato chiuso abbia sviluppo piu' rapido di uno aperto? ;)
Mi sembra che già soltanto lo zip che hai citato prima sia una risposta a questa tua domanda, visto che è stato necessario effettuare il reverse engineering (partendo però dai dati e non dal codice) per ricostruire tutta la sua struttura (infatti il formato GZip è nato grazie a quest'enorme lavoro).
Mah, io non stavo discutendo se il software adesso possa essere considerato open source o meno... stavo soltanto evidenziando come secondo la licenza non possono essere fatte modifiche per alcun motivo, neanche per proporle alla Microsoft.
Questo è da vedere. Finora i termini riguardano esplicitamente la società che sviluppa software usando .NET e i prodotti che rilascia.
Grazie che e' "open source", si puo' leggere il codice! :D La so la differenza tra "software open source" e "software libero" ;) se ho parlato di open source intendendo software libero e' perche' ormai ho preso il viziaccio anch'io di usare solo il termine opensource ^___^
Non è l'unica volta che hai sbagliato a usare i termini, mi pare.
Ma guarda che si poteva fare secondo il modello Java, come ho gia' detto. Si propongono modifiche e la Sun decide se accettarle o meno. Invece la Microsoft non da' neanche questa possibilita', perche' semplicemente ha paura che queste modifiche circolino su internet e si aggreghino in un progetto alternativo. Sai quanto gliene puo' fregare del beneficio alla comunita' :D
Te l'abbiamo già spiegato: MS vuole tenere saldamente in mano lo sviluppo di .NET. Per segnalazioni di bug fix è sempre disponibile.

D'altra parte mi sembra che lo sviluppo di .NET procede piuttosto bene (siamo già alla versione 3.5 mi pare), mentre Mono è ancora parecchio indietro.
Eh, ma non e' colpa mia, e' che mi escono cosi' spontanee.... :D
Se escono da te è colpa tua. Lapalissiano.
Comunque, facendo un piccolo brainstorming sul forking, e rispondendo cosi' anche a MenageZero, sul forking "di terze parti". Perche' ovviamente esistono anche forks che partono dai dev stessi del software, magari per sviluppare un'idea alternativa o semplicemente per testare una versione futura in fase alpha, ma nel frattempo sviluppare ancora la versione stabile.
Per questo esiste un termine ben preciso: si chiama branching. Il codice, comunque, rimane CONDIVISO con la base da cui parte.

Col forking c'è una NOTEVOLE differenza.
Comunque, il forking che parte da persone esterne al progetto nasce spesso come un'esigenza. Un utente ha un'idea, la propone agli sviluppatori del progetto. Gli sviluppatori gli rispondono picche perche':
- non rientra nelle finalita' del progetto
- non hanno tempo
- non gli sembra cosi' utile
- e' una modifica che non genera codice pulito
- richiederebbe troppo rewriting
- a loro non piace "concettualmente"
- e' dannosa per tizi cai e semproni (nel qual caso, se e' vero, e' giusto non implementarla)
- chi la propone sta sulle balle a tutti :D

Alla fine i developers potrebbero comunque ospitare la modifica sul loro sito e dare vita cosi' a forking "ufficiali", ma non si fiderebbero certo a dare username e password del sito a chiunque. Certo potrebbero creare un account con limitazioni, ma sai che sbattitura? Allora dovrebbero creare almeno un link, e quando viene aggiornato anche il fork il tizio dovrebbe inviargli il file e loro dovrebbero upparlo... una rottura di ca**i anche questa.

E cosi' nasce il fork non ufficiale. Ma non ci vedo nulla di male. Se l'idea era valida ed i developers non sono dei minc***oni, prima o poi i due progetti si uniranno, come infatti facevi presente citando Compiz. Se il forking soppianta l'idea originale poco male anche li', si spera che il fork fosse effettivamente migliore (anche se la certezza non c'e' :P). Se il fork fallisce, puo' essere perche' l'idea era effettivamente una cavolata, o semplicemente perche' l'ideatore non ha saputo "venderla", oppure perche' i developers del progetto originale sono effettivamente dei minc***oni e non se la sono mai cagata neanche di striscio. In tal caso la cosa e' negativa, ma se non ci fosse stata la possibilita' di forking il progetto non sarebbe neanche iniziato.
Peccato che per risolvere problemi come questo basti semplicemente mettersi d'accordo per effettuare un branch, mantenendo quindi la piena sincronizzazione con la base del codice.

Ma no: è molto più "comodo" il forking, per cui meglio eseguire una brutale copia dell'intero progetto e andare ognuno per la sua strada.
Certo, le persone che lavorano ai forks potrebbero invece aiutare il progetto originale. Ma probabilmente 1) il gruppo dei devs e' elitario e non lo ha accettato, e/o 2) lui non e' interessato a lavorare come dev al progetto, ma solo alla sua idea alternativa. Quindi lo spreco di risorse non lo vedo...
Sei l'unico a non vederlo. Vedi sopra.

Quanto ai punti 1 & 2, è la dimostrazione di quanta gente esista che è ottusamente convita di possedere la verità. E i risultati, appunto, si vedono: forking a manetta.
vedo piuttosto idee (e persone) intelligenti e idee stupide, ed il forking da' la possibilita' di fare tutte e due a tutti e due le tipologie di persone ^____^.
Certo, ma con uno spreco di risorse.
Sta' poi allo sviluppatore ed all'utente a scegliere il giusto percorso e prodotto ;)
Quindi dopo lo spreco di risorse con gli sviluppatori, c'è anche quella del tempo che devono perdere gli utenti dietro a tutte le soluzioni che vengono da presentate dai primi, per scegliere quella che più gli si confà...

Ma non so secondo quali fonti ;)

If we compare the speed of ASP and PHP then PHP has an upper hand. PHP code runs faster than ASP. ASP is built on COM based architecture, which is an overhead for the server whereas PHP code runs in its own memory space.
http://www.webpronews.com/expertarticles/2005/12/22/asp-vs-php
Mai lette tante schiocchezze di fila. Il non plus ultra, poi, è rappresentato da questo:

"PHP is based on C++ language and the syntax used in PHP is quite similar to C/C++. C/C++ is still considered the best programming language by many programmers and people who love this language would surely feel more comfortable with the syntax of PHP."

PHP e C++ sono due linguaggi completamente diversi. In comune hanno soltanto parte della SINTASSI, che di per sé non vuol dire proprio niente.
E inoltre:

Compiled Code vs. PHP Interpreted Code .NET compiles code, such as C#, into what its creators have termed MSIL, or Microsoft Intermediate Language. This roughly resembles Java's bytecode, the "binary" you have after you compile the source code. PHP, as an interpreted language, doesn't really have an equivalent here. [...]

Saying that PHP is strictly interpreted and that ASP.NET code is compiled is a bit misleading, as evidenced by the common language runtime environment I've described. What's more, with PHP as well as ASP.NET pages, you can configure your respective Web servers to do connection pooling and caching of those pages, so they don't have to be recompiled each time. Inevitably, those PHP pages will compile into smaller pieces than the equivalent ASP.NET page, because there is more overhead with the intermediate compilation with the CLR. Ultimately, this will mean greater memory requirements on your Web server.
http://www.oracle.com/technology/pub/columns/hull_php2.html
Peccato che, come si vede anche dal link che ha postato Lck84, anche il consumo di memoria gioca a favore di C# (che è uno dei linguaggi che si può usare con ASP.NET).

Per la velocità, poi, non c'è proprio paragone.
Per MySQL, non ci ho mai fatto riferimento. Se dovessi prendere un esempio calzante, direi piuttosto PostGres ;)
Calzante per cosa?
Per GIMP... lasciamo perdere va'.... :rolleyes:
Appunto: lasciamo perdere che è meglio, perché è una gran cacata paragonato a PhotoShop.

Poi se ci si vuole accontentare allora è un altro discorso.
Per il DOS, basta documentarsi un attimo... cerca "Gary Kildall" ;)
Già fatto: non c'è nessun codice copiato, come hai FALSAMENTE attestato.

Mai lette tante schiocchezze di fila. Il non plus ultra, poi, è rappresentato da questo:

"PHP is based on C++ language and the syntax used in PHP is quite similar to C/C++. C/C++ is still considered the best programming language by many programmers and people who love this language would surely feel more comfortable with the syntax of PHP."

PHP e C++ sono due linguaggi completamente diversi. In comune hanno soltanto parte della SINTASSI, che di per sé non vuol dire proprio niente.

Infatti in quelle righe fa proprio riferimento alla sintassi dicendo che "who love this language would surely feel more comfortable with the syntax of PHP". Non ci vedo nulla di sbagliato: è vero che la sintassi è simile. Come è simile anche quella del C# (ma in quel testo parlavano di ASP).

Peccato che, come si vede anche dal link che ha postato Lck84, anche il consumo di memoria gioca a favore di C# (che è uno dei linguaggi che si può usare con ASP.NET).

Per la velocità, poi, non c'è proprio paragone.

Spero bene... ASP.NET è "compilato" in MSIL, PHP è intepretato. Sarebbe come comparare C# con Python *interpretato*: la scoperta dell'acqua calda. Al limite si potrebbe fare un paragone tra ASP.NET e PHP con eAccelerator o Zend Optimizer.

Mh, aspetta, li' hai fatto un raffronto tra un programmi compilato in C# e un programma in PHP. Non e' un raffronto tra un'applicazione web scritta in ASP.NET (che non e' propriamente un linguaggio compilato, ma e' poi tradotto in bytecode) e una PHP.
Se non sai nemmeno cos'è ASP.NET, evita di parlarne, che è meglio. Perfino su Wikipedia c'è un'apposita voce, che è piuttosto chiara: http://en.wikipedia.org/wiki/Asp.net

"ASP.NET is a web application framework marketed by Microsoft that programmers can use to build dynamic web sites, web applications and XML web services. It is part of Microsoft's .NET platform and is the successor to Microsoft's Active Server Pages (ASP) technology.

ASP.NET is built on the Common Language Runtime, meaning programmers can write ASP.NET code using any Microsoft .NET language."

Direi che si commenta da sé.
Tra l'altro anche il PHP ha pacchetti aggiuntivi che permettono la creazione di una specie di bytecode per PHP
PHP non ha dei "pacchetti" aggiuntivi. Esistono delle soluzioni che permettono di "compattare" il codice sorgente, o di riutilizzare il byte-code generato dall'interprete.
ed il caching degli script.
Questo c'è anche per quelli ASP.NET.
Sono completamente d'accordo, io volevo fare piu' che altro un confronto tra strategie di sviluppo del software infatti :-)
Falso. Su questo t'ho risposto sopra, comunque.
Mh. Non sono d'accordo con il discorso che fai... un conto e' dover installare librerie aggiuntive, un conto e' utilizzare un progetto derivato.
Ora, un progetto derivato dal .NET si parte dal presupposto sia compatibile con il .NET stesso.
Non è affatto detto.
Mettiamo il caso che io prenda il codice del .NET 3 e lo renda compatibile con le versioni precedenti di .NET. Il guadagno da parte dei programmatori e' enorme, perche' non devono mettersi a riscrivere programmi gia' implementati con l'uso di una versione precedente di .NET. L'impossibilita' di sviluppare codice indipendentemente blocca a priori qualsiasi possibilita' di retrocompatibilita', perche' e' chiaro che la Microsoft non ha alcun interessa a spenderci dei soldi, altrimenti lo avrebbe gia' fatto da tempo.
Cioé? Potresti spiegarti meglio?
Aspetta, un accidente... ;-) Non ha copiato solo l'API, ma e' stato dimostrato che ben 26 system call erano identiche. Ed infatti, molto dopo la morte di Kildall, il suo amico Harold Evans ha vinto la causa contro Tim Paterson:

http://punto-informatico.it/p.aspx?i=2050079
http://www.theregister.co.uk/2007/07/30/msdos_paternity_suit_resolved/
API = System call. E se ti leggi i link, in particolare il secondo, è chiaro che non si riferisce a nessuna copia del codice. Ripeto: basta leggere.

La causa, poi, l'aveva intenta Paterson a Evans per diffamazione a causa della pubblicazione di un libro da parte di quest'ultimo.

Copiare l'interfaccia di un'API non vuol dire niente: è copiare il codice che è punito dalla legge. Altrimenti progetti come questo www.aros.org e questo www.reactos.org , ma pure lo stesso WINE avrebbero già chiuso i battenti da tempo...

Continui ancora a riportare informazioni false e leggende metropolitane: mi chiedo per quanto ancora vorrai sostenere questo giochetto al massacro.

Infatti in quelle righe fa proprio riferimento alla sintassi dicendo che "who love this language would surely feel more comfortable with the syntax of PHP". Non ci vedo nulla di sbagliato: è vero che la sintassi è simile. Come è simile anche quella del C# (ma in quel testo parlavano di ASP).
Nemmeno io ci vedrei niente di male, salvo che il pomposo accostamento fra PHP e C++ che è definito come "il miglior linguaggio di programmazione" (su quala base, poi, sarei curioso di sapere) non vuol dire proprio niente.
Esistono tantissimi linguaggi fortemente ispirati al C, ma le cui caratteristiche li rendono profondamente diversi (ad esempio il weak typing del PHP è MOOOLTO diverso dallo static typing di C e C++).

Tra l'altro PHP ha mutuato ereditarietà ed eccezioni da Java, e non da C++: è più simile al primo, infatti...
Spero bene... ASP.NET è "compilato" in MSIL, PHP è intepretato. Sarebbe come comparare C# con Python *interpretato*: la scoperta dell'acqua calda. Al limite si potrebbe fare un paragone tra ASP.NET e PHP con eAccelerator o Zend Optimizer.
Esattamente.

Nemmeno io ci vedrei niente di male, salvo che il pomposo accostamento fra PHP e C++ che è definito come "il miglior linguaggio di programmazione" non vuol dire proprio niente.
Esistono tantissimi linguaggi fortemente ispirati al C, ma le cui caratteristiche li rendono profondamente diversi (ad esempio il weak typing del PHP è MOOOLTO diverso dallo static typing di C e C++).

Infatti dice che hanno una sintassi simile, non che sono identici ;) Sul fatto di quale sia il "miglior linguaggio di programmazione" poi ognuno ha i suoi gusti... ad esempio a me gustano C#, D e Ada :D

Mettiamo il caso che un giorno si scopra che quel codice contenesse una grave falla e che questa venga corretta nel ".NET Framework 3.0a". Se tutti avessero fatto come dici "prendendo codice" dal framework ed "incorporandolo" nel proprio progetto (per motivi di retrocompatibilità), non basterebbe aggiornare il framework alla "3.0a" per mettersi al riparo dalla falla, perchè ci sarebbero in giro svariati software con una propria versione bacata della libreria.

Ma infatti per quello ci dovrebbero pensare i developers dei vari framework. Se uno non aggiorna, rende il framework sicuramente meno "appetibile".
Senza contare che se un framework ha successo, puo' spingere la Microsoft ad adottare le sue modifiche e/o aggiunte. Non e' infrequente nel mondo informatico.

Non credo di aver ben capito la sua posizione. In ogni caso, posto il link di un mio intervento sul discorso retrocompatilità, tanto per fare un po' di chiarezza:

http://www.hwupgrade.it/forum/showthread.php?p=19092638&posted=1

Se ho capito bene quindi, l'aggiornamento di un software che si basa su un framework .NET precedente e' molto semplice, quindi il problema non si pone :)
Comunque il mio discorso voleva essere generale, anche se il mio esempio a quanto pare non era azzeccato :P Le modifiche al codice potrebbero essere anche solo strettamente per aumentare la performance o risolvere bug, o anche per aggiungere delle librerie alternative compatibili con il framework ufficiale, prese da altri framework.

Ma infatti per quello ci dovrebbero pensare i developers dei vari framework. Se uno non aggiorna, rende il framework sicuramente meno "appetibile".
Senza contare che se un framework ha successo, puo' spingere la Microsoft ad adottare le sue modifiche e/o aggiunte. Non e' infrequente nel mondo informatico.

Se hai modifiche da suggerire, le proponi e poi ci pensano, eventualmente, loro ;)

Ma infatti per quello ci dovrebbero pensare i developers dei vari framework. Se uno non aggiorna, rende il framework sicuramente meno "appetibile".
Purtroppo è evidente da ciò che scrivi che per te esiste soltanto il forking per la realizzazione di progetti derivati da altri: l'idea di utilizzare il branching per ottenere AUTOMATICAMENTE tutti gli aggiornamenti del progetto "padre" non ti sfiora nemmeno...
Senza contare che se un framework ha successo, puo' spingere la Microsoft ad adottare le sue modifiche e/o aggiunte. Non e' infrequente nel mondo informatico.
Ma se Mono è parecchio indietro rispetto a .NET, che è già arrivato alla versione 3.5, pensi che abbia senso per altre persone che lavorano nel settore dello sviluppo open source eseguire dei fork di .NET per apportarvi modifiche? Ti rendi conto dello spreco di risorse?

Per il resto, MS mi sembra che finora abbia dimostrato di cavarsela benissimo da sola con .NET... ;)
Comunque il mio discorso voleva essere generale, anche se il mio esempio a quanto pare non era azzeccato :P Le modifiche al codice potrebbero essere anche solo strettamente per aumentare la performance
Le performance si aumentano SE E SOLO SE ha esistono delle OGGETTIVE esigenze in tal senso.
o risolvere bug,
Questo nessuno lo impedisce.
o anche per aggiungere delle librerie alternative compatibili con il framework ufficiale, prese da altri framework.
.NET non è un patchwork: il framework ha una sua "identità" e le innovazioni vengono aggiunte in modo da rispettarla, non aggiungendo pezzi presi a destra e a manca.

Noto comunque che eviti accuratamente di rispondere a tutti i messaggi che t'ho scritto.

x ekerazha: sono tre linguaggi molto diversi fra loro. Che strani gusti. :p

x ekerazha: sono tre linguaggi molto diversi fra loro. Che strani gusti. :p
In tutti e 3 c'è una sana costante ;)

Mumble mumble. Mi sfugge onestamente. :)

Mumble mumble. Mi sfugge onestamente. :)

Sono tutti e 3, efficacemente, OO :D E non hanno altre grandi noie tipo il Python (che è OO... ma è mediamente lento, ha una sintassi stupida, typing dinamico etc.)

Se hai modifiche da suggerire, le proponi e poi ci pensano, eventualmente, loro ;)

Fosse sempre la cosa migliore, vivremmo in un mondo perfetto... ;)

Sono tutti e 3, efficacemente, OO :D E non hanno altre grandi noie tipo il Python (che è OO... ma è mediamente lento, ha una sintassi stupida, typing dinamico etc.)

Argghhh! Eresia! :D

1) Il Python e' lento perche' e' un linguaggio interpretato! Impossibile paragonare le sue prestazioni con c# et similia. Andrebbe paragonato con linguaggi intepretati, come Perl o Java, e non se la cava niente male ;)

2) La sintassi del Python e' bellissima! E' fatta apposta perche' nessuno possa scrivere del codice assolutamente incomprensibile! Al posto di parentesi graffe, di endif, di fi eccetera, semplicemente mette l'indentazione. Il python costringe ad indentare bene il codice, e questa e' una cosa semplicemente geniale

3) Il typing del Python e' dinamico, e' vero (cosa che non piace neanche tanto a me), pero' e' un typing a forte controllo, cioe' una volta assegnato un valore di un certo tipo alla variabile, essa e' di quel tipo, finche' non gli viene assegnato esplicitamente un valore di un altro tipo. Insomma, non ci sono conversioni implicite, ma solo la possibilita' di poter cambiare tipo ad una variabile

Noto comunque che eviti accuratamente di rispondere a tutti i messaggi che t'ho scritto.

Ma gia' perdo tempo a vedere se scrivi qualcosa di sensato... posso perdere tempo pure a risponderti? :rolleyes:

Argghhh! Eresia! :D

1) Il Python e' lento perche' e' un linguaggio interpretato! Impossibile paragonare le sue prestazioni con c# et similia. Andrebbe paragonato con linguaggi intepretati, come Perl o Java, e non se la cava niente male ;)


Pardon, Java sarebbe un linguaggio interpretato??????? :eek:

Pardon, Java sarebbe un linguaggio interpretato??????? :eek:

Certo, poi che venga ottimizzato grazie al bytecode (presente anche in Python ;) ) o alla JIT e' un altro conto.

Fosse sempre la cosa migliore, vivremmo in un mondo perfetto... ;)

Non so se sia la cosa migliore, ma è la cosa che andrebbe fatta.


Argghhh! Eresia! :D

1) Il Python e' lento perche' e' un linguaggio interpretato! Impossibile paragonare le sue prestazioni con c# et similia. Andrebbe paragonato con linguaggi intepretati, come Perl o Java, e non se la cava niente male ;)

In realtà è del tutto irrilevante... se sono su una pista da Formula 1 e c'è una Ferrari e una Panda e tu mi vieni a dire "non puoi confrontare la Ferrari con la Panda" io ti dico "hai ragione... ma allora che ci vieni a fare in pista con la Panda?". E' plausibile che sia più lento poichè intepretato... ma allora fai a meno di scegliere un linguaggio con una implementazione interpretata :D


2) La sintassi del Python e' bellissima! E' fatta apposta perche' nessuno possa scrivere del codice assolutamente incomprensibile! Al posto di parentesi graffe, di endif, di fi eccetera, semplicemente mette l'indentazione. Il python costringe ad indentare bene il codice, e questa e' una cosa semplicemente geniale

No... la cosa geniale sarebbe che i programmatori imparassero ad indentare il codice. Su progetti di grandi dimensioni trovare un errore su migliaia di linee di codice magari semplicemente dovuto ad uno spazio di troppo, è semplicemente da suicidio. Oltretutto ci sono casi in cui compattare il codice (sfruttando ";" e blocchi inline) può anche migliorare la leggibilità del codice. Se poi penso che Python non ha nemmeno lo "switch..case" (comodissimo ed utilissimo) mi viene da piangere.


3) Il typing del Python e' dinamico, e' vero (cosa che non piace neanche tanto a me), pero' e' un typing a forte controllo, cioe' una volta assegnato un valore di un certo tipo alla variabile, essa e' di quel tipo, finche' non gli viene assegnato esplicitamente un valore di un altro tipo. Insomma, non ci sono conversioni implicite, ma solo la possibilita' di poter cambiare tipo ad una variabile

Ma resta dinamico :D Io voglio avere il controllo sui tipi.

Certo, poi che venga ottimizzato grazie al bytecode (presente anche in Python ;) ) o alla JIT e' un altro conto.

E allora non è intepretato. Intepretato significa generalmente che viene intepretato direttamente il codice così come è scritto. Se utilizzi Python bytecode compiled allora è bytecode compiled, se lo usi strettamente intepretato allora è intepretato.

Java e C# non sono intepretati, Python *può* esserlo.

Ma resta dinamico :D Io voglio avere il controllo sui tipi.

Vedo che abbiamo in comune una preferenza per lo strong-typing. :)

E' plausibile che sia più lento poichè intepretato... ma allora fai a meno di scegliere un linguaggio con una implementazione interpretata :D

Ci sono parecchi motivi per scegliere un linguaggio interpretato, uno di questi e' la maggiore portabilita'. Inoltre un linguaggio interpetato si puo' utilizzare benissimo per le applicazioni web. Basti pensare che molto del codice dei siti Google e' scritto in Python.

No... la cosa geniale sarebbe che i programmatori imparassero ad indentare il codice.

Sempre in un mondo perfetto :p ;)

Su progetti di grandi dimensioni trovare un errore su migliaia di linee di codice magari semplicemente dovuto ad uno spazio di troppo, è semplicemente da suicidio.

Anche scordare di chiudere una parentesi graffa. Vedi quando il compilatore ti da' errore all'ultima riga del file di codice se non ti disperi ;)

Oltretutto ci sono casi in cui compattare il codice (sfruttando ";" e blocchi inline) può anche migliorare la leggibilità del codice.

Se ti riferisci a cose come expression ? var2 : var3 sono state da poco introdotte nel python, e con una sintassi decisamente piu' leggibile. Bisogna anche tener conto che e' un linguaggio "nuovo" (in confronto con altri linguaggi)

Se poi penso che Python non ha nemmeno lo "switch..case" (comodissimo ed utilissimo) mi viene da piangere.

Eh, su questo ti do' ragione! Purtroppo pare che gli sviluppatori del Python non siano per niente interessati.... servirebbe proprio un fork! :D :-PPPPP

Ma resta dinamico :D Io voglio avere il controllo sui tipi.

Beh ti diro', anch'io preferisco di gran lunga il typing statico. Comunque non e' detto che in futuro non venga aggiunto al Python un utilizzo opzionale del typing statico: http://www.python.org/~guido/static-typing/

E allora non è intepretato. Intepretato significa generalmente che viene intepretato direttamente il codice così come è scritto.

E che barba.... :rolleyes: :D E allora parliamo di linguaggi non compilati, ok? Comunque vi faccio notare che un programma o applet Java e' comunque eseguita dalla Java Virtual Machine, che e' un interprete... ;)

EDIT: e difatti:

l'esecuzione di programmi scritti in Java deve avere un comportamento simile su hardware diverso. Si dovrebbe essere in grado di scrivere il programma una volta e farlo eseguire dovunque. Questo è possibile con la compilazione del codice di Java in un linguaggio intermedio bytecode, basato su istruzioni semplificate che ricalcano il linguaggio macchina. Esso viene eseguito da una macchina virtuale, cioè da un interprete: Java è quindi, in linea di massima, un linguaggio interpretato.

http://it.wikipedia.org/wiki/Java_(linguaggio)#Indipendenza_dalla_piattaforma

E se vogliamo fare i pignoli, Python e' un linguaggio a tipizzazione variabile (dynamic typing), eppure "forte" (strong typing) ;)

Ci sono parecchi motivi per scegliere un linguaggio interpretato, uno di questi e' la maggiore portabilita'. Inoltre un linguaggio interpetato si puo' utilizzare benissimo per le applicazioni web. Basti pensare che molto del codice dei siti Google e' scritto in Python.

E' portatile tanto quanto il bytecode compiled ;) E per le applicazioni web mica è necessario un linguaggio interpretato: PHP con eAccelerator o Zend Optimizer (che migliorano appunto le prestazioni) o anche tutti i linguaggi per ASP.NET (MSIL).


Anche scordare di chiudere una parentesi graffa. Vedi quando il compilatore ti da' errore all'ultima riga del file di codice se non ti disperi ;)

Una graffa o un punto e virgola, per quanto "piccoli", sono sempre più visibili di un "buco vuoto".


Se ti riferisci a cose come expression ? var2 : var3 sono state da poco introdotte nel python, e con una sintassi decisamente piu' leggibile. Bisogna anche tener conto che e' un linguaggio "nuovo" (in confronto con altri linguaggi)

Non solo... potrebbe anche essere qualcosa del tipo

Foo() { return true; }


Eh, su questo ti do' ragione! Purtroppo pare che gli sviluppatori del Python non siano per niente interessati.... servirebbe proprio un fork! :D :-PPPPP

;) Io lo switch..case lo uso tantissimo, in C, anche al posto di lunghe, poco leggibili, catene di condizioni OR (ad esempio), anche se dipende da come viene gestito dal linguaggio.


E che barba.... :rolleyes: :D E allora parliamo di linguaggi non compilati, ok? Comunque vi faccio notare che un programma o applet Java e' comunque eseguita dalla Java Virtual Machine, che e' un interprete... ;)

No... se vogliamo fare i pignoli allora pure il codice nativo è intepretato dalla CPU ;). Tra l'altro potrei anche dirti che esistono schede *hardware* per l'esecuzione di "java bytecode". Java è *compilato* in java bytecode.

EDIT: e difatti:

l'esecuzione di programmi scritti in Java deve avere un comportamento simile su hardware diverso. Si dovrebbe essere in grado di scrivere il programma una volta e farlo eseguire dovunque. Questo è possibile con la compilazione del codice di Java in un linguaggio intermedio bytecode, basato su istruzioni semplificate che ricalcano il linguaggio macchina. Esso viene eseguito da una macchina virtuale, cioè da un interprete: Java è quindi, in linea di massima, un linguaggio interpretato.

http://it.wikipedia.org/wiki/Java_(linguaggio)#Indipendenza_dalla_piattaforma

Stasera appena ho tempo vado a correggere questa imprecisione su wikipedia, grazie della segnalazione ;)

Ci sono parecchi motivi per scegliere un linguaggio interpretato, uno di questi e' la maggiore portabilita'. Inoltre un linguaggio interpetato si puo' utilizzare benissimo per le applicazioni web. Basti pensare che molto del codice dei siti Google e' scritto in Python.

Se è per questo anche C,C++ (con CGI/FCGI), C#, VB.NET (sotto .NET) e Java sono perfettamente usabili per web application.

Un linguaggio interpretato necessita comuque di un interprete, che deve essere presente nel sistema di destinazione. Quindi la possibilità di eseguirlo è condizionata da un componente esterno. Ciò non avviene con linguaggi compilati. Tutto questo senza considerare le numerose ottimizzazioni applicate dai compilatori.

E' portatile tanto quanto il bytecode compiled ;) E per le applicazioni web mica è necessario un linguaggio interpretato: PHP con eAccelerator o Zend Optimizer (che migliorano appunto le prestazioni) o anche tutti i linguaggi per ASP.NET (MSIL).

Ahie... :rolleyes:
Un linguaggio potra' anche essere compilato in bytecode, ma il bytecode poi dovra' essere interpretato. Il bytecode non e' codice macchina, punto. Anche ASP e' un linguaggio che viene compilato in bytecode, altrimenti col cavolo lo avresti potuto utilizzare in applicazioni web ;)

Una graffa o un punto e virgola, per quanto "piccoli", sono sempre più visibili di un "buco vuoto".

Si vede che non ti e' mai capitato un errore come quello che ti ho detto prima :D
Ti posso assicurare che ho programmato sia in C++ che in Python, ed e' piu' semplice capire dove hai sbagliato nel linguaggio Python.
Oltretutto, in C++ sbagliare scordandosi un punto e virgola e' frequentissimo, cosa che nel Python e' impossibile visto che la fine dell'istruzione e' la fine stessa della riga.
E per finire, se uno si fa furbo ed usa un editor avanzato come SciTe o simili, vedere un'indentatura sbagliata e' semplicissimo.

Non solo... potrebbe anche essere qualcosa del tipo

Foo() { return true; }

Ma e' una sintassi a mio parere orribile... ^____^ Che grossi problemi ci sono se nel python si scrive cosi', scusa?

def Foo() :
return true

No... se vogliamo fare i pignoli allora pure il codice nativo è intepretato dalla CPU ;). Tra l'altro potrei anche dirti che esistono schede *hardware* per l'esecuzione di "java bytecode". Java è *compilato* in java bytecode.

Java e' compilato in bytecode, il bytecode deve essere intepretato dalla JVM. Oppure dalla scheda hardware (cosa interessante di cui non sapevo, grazie!). Insomma, da qualcosa deve essere interpretato per essere "tradotto" in linguaggio macchina. Cosa che i linguaggi compilati non hanno bisogno.

Esistono anche compilatori per il Python per linkare il codice in linguaggio macchina vero e proprio (come esisteranno credo compilatori per Java). Vogliamo dire allora che il Python e' un linguaggio compilato? ;)

Stasera appena ho tempo vado a correggere questa imprecisione su wikipedia, grazie della segnalazione ;)

E faresti male:

Security problems can be exacerbated in environments that download binary code. That is, the downloaded code is in the native computing mode of the local host. The reason this is such a concern is simple: binary code is not as easy to inspect, review, and restrict as is an interpreted language like Java.

http://java.sun.com/security/javaone97-whitepaper.html

Java programs are run (or interpreted) by another program called the Java VM. If you are familiar with Visual Basic or another interpreted language, this concept is probably familiar to you.

http://java.sun.com/developer/onlineTraining/Programming/BasicJava1/compile.html

Ahie... :rolleyes:
Un linguaggio potra' anche essere compilato in bytecode, ma il bytecode poi dovra' essere interpretato. Il bytecode non e' codice macchina, punto. Anche ASP e' un linguaggio che viene compilato in bytecode, altrimenti col cavolo lo avresti potuto utilizzare in applicazioni web ;)

Come il "codice nativo" deve poi essere "intepretato" dalla CPU ;): fai semplicemente un passaggio in più... resta il fatto che intanto è compilato in bytecode, mentre altri linguaggi strettamente intepretati, tra i quali non rientra Java ;) non sono compilati in nulla perchè vengono intepretati direttamente dal codice sorgente (sul quale viene fatto il parsing).


Si vede che non ti e' mai capitato un errore come quello che ti ho detto prima :D
Ti posso assicurare che ho programmato sia in C++ che in Python, ed e' piu' semplice capire dove hai sbagliato nel linguaggio Python.
Oltretutto, in C++ sbagliare scordandosi un punto e virgola e' frequentissimo, cosa che nel Python e' impossibile visto che la fine dell'istruzione e' la fine stessa della riga.
E per finire, se uno si fa furbo ed usa un editor avanzato come SciTe o simili, vedere un'indentatura sbagliata e' semplicissimo.

Ah si... e più facile accorgersi di qualche pixel di spazio vuoto (o comunque uguale a quello circostante ;) ) di troppo che di un carattere "stampato" :rolleyes: Tra l'altro il fatto che in Python il fine istruzione sia il fine riga impedisce alcuni costrutti come quello già esemplificato che possono anche migliorare la leggibilità del codice.


Ma e' una sintassi a mio parere orribile... ^____^ Che grossi problemi ci sono se nel python si scrive cosi', scusa?

def Foo() :
return true

E' semplicemente meno leggibile e vi è inutile spreco di spazio. Nelle guideline alla sintassi della maggior parte dei linguaggi in circolazione si tende a "risparmiare spazio" e "compattare" i blocchi più semplici. Poi sui gusti non si discute...


Java e' compilato in bytecode, il bytecode deve essere intepretato dalla JVM. Oppure dalla scheda hardware (cosa interessante di cui non sapevo, grazie!). Insomma, da qualcosa deve essere interpretato per essere "tradotto" in linguaggio macchina. Cosa che i linguaggi compilati non hanno bisogno.

Il codice nativo deve essere interpretato dalla CPU ;) Il discorso è sempre quello...


Esistono anche compilatori per il Python per linkare il codice in linguaggio macchina vero e proprio (come esisteranno credo compilatori per Java). Vogliamo dire allora che il Python e' un linguaggio compilato? ;)

In tal caso, ovviamente si ;) Infatti dipende dall'implementazione, come ho chiaramente ribadito più e più volte.


E faresti male:

Security problems can be exacerbated in environments that download binary code. That is, the downloaded code is in the native computing mode of the local host. The reason this is such a concern is simple: binary code is not as easy to inspect, review, and restrict as is an interpreted language like Java.

http://java.sun.com/security/javaone97-whitepaper.html

Java programs are run (or interpreted) by another program called the Java VM. If you are familiar with Visual Basic or another interpreted language, this concept is probably familiar to you.

http://java.sun.com/developer/onlineTraining/Programming/BasicJava1/compile.html
... ed il codice nativo è intepretato dalla CPU ;) Se vuoi possiamo concludere che tutti i linguaggi sono intepretati... ma non tutti sono anche compilati ;) Ma generalmente ci si riferisce appunto a quelli "intepretati" come a quelli che non vengono compilati... e Java come già detto viene compilato, in bytecode.

Comunque ho inserito la precisazione su wikipedia.

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

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

In effetti la distinzione non è così evidente, però generalmente Java non si considera (così come C# o VB.NET) un linguaggio interpretato (vedi primo link).

Sono tutti e 3, efficacemente, OO :D E non hanno altre grandi noie tipo il Python (che è OO... ma è mediamente lento, ha una sintassi stupida, typing dinamico etc.)
Direi di continuare il confronto fra Python vs resto del mondo nella sezione Programmazione, visto che ne abbiamo ampiamente discusso, e il thread è ancora attivo.

Il tutto è da partito qui http://www.hwupgrade.it/forum/showthread.php?t=1563542 ma poi si è proseguito qui http://www.hwupgrade.it/forum/showthread.php?t=1567961

Ovviamente l'invito è di leggerli entrambi, ma di usare soltanto il secondo per continuare la discussione.

Ma gia' perdo tempo a vedere se scrivi qualcosa di sensato... posso perdere tempo pure a risponderti? :rolleyes:
Questa è la risposta standard di chi non ha argomenti per sostenere le proprie tesi, che sono state ampiamente confutate.

Questa è la risposta standard di chi non ha argomenti per sostenere le proprie tesi, che sono state ampiamente confutate.

E pensala come ti pare...

Penso che... scripta manent. ;)

P.S. Singolare che avremmo trovato un forte punto di accordo (Python :D): non c'avrei scommesso un centesimo. :p

Direi di continuare il confronto fra Python vs resto del mondo nella sezione Programmazione, visto che ne abbiamo ampiamente discusso, e il thread è ancora attivo.

Infatti non è mia intenzione partecipare a dibattiti su Python, lo conosco già sufficientemente bene per essermi fatto un'ampia idea a riguardo ;)

Penso che... scripta manent. ;)

P.S. Singolare che avremmo trovato un forte punto di accordo (Python :D): non c'avrei scommesso un centesimo. :p

Non cercare di intenerirmi con il mio punto debole! :D

Si puo' essere completamente in disaccordo con qualcuno su delle cose e completamente d'accordo con altre. Il mondo mica e' bianco e nero ;)

Guarda, io ti rispondo, ma non certo a tutto. Potrai vedere pure te che sara' tempo perso, perche' abbiamo due idee completamente opposte.

Questo è l'uso che ne puoi fare a livello di compagnia e per lo sviluppo del tuo software. Spedire a MS, e soltanto a lei, un pezzo del suo codice [del framework .NET] corretto non credo che violi i termini della licenza.

Da come e' messa la licenza, direi che io non mi ci arrischierei. Comunque per saperlo c'e' un metodo molto semplice, si fa finta di essere interessato a fare un bug fixing del .NET e si chiede tramite canali Microsoft se questo sia consentito. A me pero' sinceramente non va di perderci tempo, che non mi interessa :-P

Opinabilissimo. Prendi un equivalente di Office o di Photoshop, giusto per fare un paio di esempi più noti. Ti sconsiglio di citarmi OpenOffice e TheGimp come "valide" alternative (figuriamoci "superiori"), perché sono delle ciofeche al loro confronto.

per citarti, direi "opinabilissimo" ;)

Lo stesso può verificarsi col codice open source. Anzi, con l'open source hai il vantaggio di aumentare esponenzialmente la possibilità che un bug venga scovato a usato.

e corretto...

Nvu ha forse le stesse funzionalità di Dreamweaver?
Dipende se ti piace una battona supertruccata o una ragazza acqua e sapone... :D

Che nella versione 7 è diventato ancora più pesante. Ma Nero va bene: l'hai detto tu.
E infatti siamo all'8, e mi sa che non l'hai provato... ;)

http://en.wikipedia.org/wiki/Microsoft_.Net#Criticism

Java e .NET sono tristemente famosi per essere dei macigni, il primo poi piu' di tutti!Falso. E' scritto chiaro e tondo nello stesso pezzo che hai riportato che ci sono anche casi in cui le prestazioni sono migliori del codice compilato "nativamente".

Dire che alcuni programmi sono piu' performanti sotto ASP e dire che e' falso che ASP sia un macigno sono cose un po' diverse ;)
Vuoi che ti dica che ASP solitamente e' un macigno? Ok, ASP solitamente e' un macigno.

Il prezzo da pagare col forking è l'ENORME spreco di risorse umane per fare più volte la STESSA COSA. Anche questo è un dato di fatto.

Forze che comunque non verrebbero impiegate per il progetto originale.

Sì, ne ho sentito parlare: a parte il PNG e ISO sono tutti FORMATI PROPRIETARI, con BREVETTI e LICENZE pendenti. Al pari di WMA, WMV, ecc.

Ma chissenefrega se e' proprietario o meno. L'importante e' che lo standard sia aperto. L'importante e' che sia possibile sapere come si codifica e decodifica, e se voglio aggiungerne il supporto ad un programma terzo io ne abbia la facolta' di farlo, senza strane librerie linkabili e altri schifi.

A parte i formati Windows imposti con la forza dell'aziendaAssolutamente falso anche questo: il mercato è completamente libero.

Certo, infatti ognuno e' libero di imporre i suoi standard del caspio :D

Io faccio soltanto un'analisi puramente pragmatica: attualmente il closed source non funziona piu'. Per la stragrande maggioranza del software ci sono "alternative" (che metto tra virgolette perche' a volte sono i programmi a pagamento o freeware closed ad essere le alternative ai programmi opensource) perfettamente al livello degli altri programmi, se non superiore.

Quindi il mondo è già stradominato dalle soluzioni open source, che sono ALMENO a livello di quelli closed.

Questa e' una tua interpretazione delle mie parole. Ma hai scordato che esistono cose come i soldi. Se uno hai i soldi puo' permettersi di farsi una pubblicita' assurda. Norton, con le sue inutilities, e' ancora famosissimo.

Tra l'altro, per fare un piccolo paragone, DOS e Windows a suo tempo vinsero la gara della diffusione nell'utenza, perche' costavano pochissimo. Eppure erano di gran lunga inferiori. Permetterai allora che io preferisca un prodotto gratuito, anche se inferiore?

Firefox mi pare abbia ampiamente dimostrato che open source + pubblicita' hanno una forza incredibile. Persino il Java, che considero inferiore a molte soluzioni attualmente esistenti ad esso confrontabile, sta spopolando, tanto che lo insegnano anche all'universita' adesso, e tra un po' Java sara' distribuito sotto GPL.

Ripeto, non sto dicendo che un software libero sia migliore di un software proprietario. Sto dicendo che esistono valide alternative gratuite e spesso open source o libere. Che queste soluzioni si impongono a volte solo grazie alla loro bonta', oppure addirittura grazie ai soldi di una grande azienda. A parita' di mezzi, Firefox ha vinto e IE no. Perche'? IE non poteva adottare il codice di Firefox? La Microsoft non ha voluto utilizzare il codice Firefox, perche' questo vorrebbe dire rilasciare quella parte di codice sotto una delle tre licenze opensource, cosa che Microsoft non vuole. Microsoft vuole il controllo assoluto di tutto il suo software, anche perche' cosi' qualsiasi supporto e manutenzione sara' possibile solo attraverso tecnici Microsoft. E perche' cosi' per gli altri sara' difficilissimo sviluppare prodotti compatibili gratuiti. Per questo non ho il minimo di fiducia ed ottimismo nell'apertura del codice di .NET, ed e' per questo che reputo il modello del software libero strategicamente vincente.

Tanto per dire una banalita', un giorno ho aiutato la mia dottoressa [...] E quando gli ho suggerito di installare Firefox al posto di IE, mi ha detto "ah meglio di no, non voglio fare casini!"Mi sembra anche giusto: magari ha dei siti, come quelli di tante banche, che funzionano soltanto con IE (io lo uso solo per questo; per tutto il resto adopero e adoro Opera), e non avrebbero più funzionato con FF.

Gia'... bei siti :rolleyes: Ne conosco giusto uno, quello che usa mia madre al ministero delle comunicazioni. Non sto qui neanche a ripetere che merda sia quell'applicativo web. E c'e' ancora chi difende l'IT della pubblica amministrazione...
(e tra l'altro IE mica glielo disinstallavo, sai? :D )

E da cosa dovrebbe essere superato [il formato MP3]? Perché la sua fama nonché diffusione non mi sembrano calare. Tutt'altro.

In a 2005 listening test that compared the performance of the LAME MP3 encoder against more modern compression formats at 128 kbit/s, it was found that there was no statistically significant difference between the results for LAME, Vorbis, several AAC encoders, and WMA. However, a test at a very low bit rate of 32 kbit/s, showed that MP3 was significantly worse than the more modern codecs at that lower bit rate.
http://en.wikipedia.org/wiki/Mp3#Alternative_technologies

Assolutamente falso [che il .doc sia un formato chiuso] (altrimenti OpenOffice, come pure tanti altri programmi, come farebbero?).

The MS Office Word software costs hundreds of dollars to create & read a .doc file. OpenOffice, despite being free, can create and read .doc files, but due to the closed nature of the .doc file format, high-level formatting (including headers and footers) is often lost when written in one program and opened in the other.
http://en.wikipedia.org/wiki/DOC_%28computing%29

Tra l'altro sei pure male informato, perché fino ad Office '97 (che è il più diffuso) MS ha pubblicato le specifiche dei formati dei suoi prodotti.

Ma a me sembra il contrario, visto che adesso esiste il formato Office Open XML (.docx) Se c'hai un link che ne parla postalo please.

Mi sembra che già soltanto lo zip che hai citato prima sia una risposta a questa tua domanda, visto che è stato necessario effettuare il reverse engineering (partendo però dai dati e non dal codice) per ricostruire tutta la sua struttura (infatti il formato GZip è nato grazie a quest'enorme lavoro).

Ma a parte il fatto che anche 'sta storia non riesco a trovarla da nessuna parte, e se tu avessi un link sarebbe meglio.

Ma tralasciando questo fatto, gzip non ha avuto fortuna? E la compressione dei dati via internet? Inoltre, vuoi mettere la liberta' che uno puo' avere nell'utilizzare il formato zip rispetto al rar, o all'ace? Lo zip inoltre e' un formato aperto, e' l'algoritmo ad essere sotto licenza.

API = System call. E se ti leggi i link, in particolare il secondo, è chiaro che non si riferisce a nessuna copia del codice. Ripeto: basta leggere.

Ripeto: un accidente. Se leggi Evans nel suo libro parla chiaramente del fatto che Paterson prese il codice del CP/M e lo tradusse in Basic. Dato che l'API e' sfacciatamente identica, il tribunale ha respinto qualsiasi accusa di Paterson. Poi puoi continuare a credere che la Microsoft sia un'azienda stupenda e cristallina, fatti tuoi.

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

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

In effetti la distinzione non è così evidente, però generalmente Java non si considera (così come C# o VB.NET) un linguaggio interpretato (vedi primo link).

Mi sembrava di aver risposto ieri a questo post... o_0

Comunque, se noti Java viene citato anche tra i linguaggi interpretati da una virtual machine:

http://en.wikipedia.org/wiki/Interpreted_language#Languages_usually_compiled_to_a_virtual_machine_code

Mi pare che stiamo discutendo dell'acqua calda... Java e' un linguaggio che, nella sua forma piu' performante, puo' essere compilato in bytecode, il quale sara' interpretato dalla JVM, oppure compilato dal compilatore JIT. Il Python nella sua forma piu' performante sara' compilato in bytecode. Quindi mi pare piu' che lecito da parte mia accostare questi due linguaggi.

Se vogliamo dire che e' sbagliato parlare di Java come linguaggio interpretato, allora e' sbagliato anche chiamarlo linguaggio compilato. Linguaggi puramente interpretati penso ormai siano solo il Ruby (almeno per ora) e i linguaggi di scripting. Quindi 'sto discorso mi pare una enorme perdita di tempo, e mannaggia pure a me che l'ho seguito! :D

EDIT: tra l'altro guardate un po' che mi sono scordato di citare... http://codespeak.net/pypy/dist/pypy/doc/news.html

Ah si... e più facile accorgersi di qualche pixel di spazio vuoto (o comunque uguale a quello circostante ;) ) di troppo che di un carattere "stampato" :rolleyes:

Ripeto, non mai hai usato evidentemente editors come SciTe, che indentano automaticamente il testo, e lo fanno con dei tab. Se uno usa gli space ci credo poi che si complica inutilmente la vita.

Tra l'altro SciTe ti segnala automaticamente indentazioni sbagliate, come anche virgolette singole o doppie non chiuse.

In tal caso, ovviamente si ;) Infatti dipende dall'implementazione, come ho chiaramente ribadito più e più volte.
E allora, lo ripeto anche qui, e' giusto chiamare Java un linguaggio compilato? E' stato sbagliato da parte mia confrontarlo col Python? Direi proprio di no. Se vogliamo ho sbagliato anch'io a chiamarlo linguaggio interpretato, ma non capisco perche' allora il Python puo' essere etichettato come linguaggio interpretato e nessuno dice niente, mentre se si osa farlo con Java si scatena il finimondo :D

Ripeto, non mai hai usato evidentemente editors come SciTe, che indentano automaticamente il testo, e lo fanno con dei tab. Se uno usa gli space ci credo poi che si complica inutilmente la vita.

Tra l'altro SciTe ti segnala automaticamente indentazioni sbagliate, come anche virgolette singole o doppie non chiuse.

Rimane comunque meno pratico ;) In ogni caso, personalmente, preferisco linguaggi strutturalmente "sani" e non linguaggi che diventano accettabili solo utilizzando l'editor "Pippo".


E allora, lo ripeto anche qui, e' giusto chiamare Java un linguaggio compilato? E' stato sbagliato da parte mia confrontarlo col Python? Direi proprio di no. Se vogliamo ho sbagliato anch'io a chiamarlo linguaggio interpretato, ma non capisco perche' allora il Python puo' essere etichettato come linguaggio interpretato e nessuno dice niente, mentre se si osa farlo con Java si scatena il finimondo :D
Ripeto per l'ennesima volta, dipende dall'implementazione:

- Java viene generalmente compilato in bytecode.

- Python può essere, tra le altre cose, interpretato o compilato in bytecode.

Detto questo... Python è mediamente più lento di Java sia quando viene interpretato (ovviamente) che quando viene eseguito bytecode compiled. Ad esempio (ma se ne trovano molti in rete) questo è un piccolo benchmark tra Java, Python interpretato e Python compilato in bytecode con Psycho: http://blog.snaplogic.org/?p=55 Java perde praticamente solo nel test "List" (e di misura su Standard Output, per quello che serve...), in altri test è anche 20 o 30 volte più veloce di Python bytecode compiled.

Rimane comunque meno pratico ;) In ogni caso, personalmente, preferisco linguaggi strutturalmente "sani" e non linguaggi che diventano accettabili solo utilizzando l'editor "Pippo".

Certo, d'altronde solo su Scite puoi inserire dei tab... :rolleyes:
Uno spazio vuoto di 8 caratteri in piu' o in meno e' sicuramente una cosa invisibile.

Tra l'altro, quando fai il check della sintassi, non ti dice la riga dove l'indentazione e' sbagliata, no... mentre se scordi di chiudere una parentesi graffa non ti rimanda alla fine del file.

Tra le altre cose, il python non si confonde mica per un singolo spazio errato... http://docs.python.org/ref/indentation.html

Ripeto per l'ennesima volta, dipende dall'implementazione:

- Java viene generalmente compilato in bytecode.

- Python può essere, tra le altre cose, interpretato o compilato in bytecode.

Benissimo. Allora come definisco Java?

Detto questo... Python è mediamente più lento di Java sia quando viene interpretato (ovviamente) che quando viene eseguito bytecode compiled. Ad esempio (ma se ne trovano molti in rete) questo è un piccolo benchmark tra Java, Python interpretato e Python compilato in bytecode con Psycho: http://blog.snaplogic.org/?p=55 Java perde praticamente solo nel test "List" (e di misura su Standard Output, per quello che serve...), in altri test è anche 20 o 30 volte più veloce di Python bytecode compiled.

Peccato che leggi solo quello che ti pare a te pero', visto che:

1) Python + Psycho nel test e' significamente piu' lento di Java solo per quanto riguarda l'allocazione degli oggetti. Per lo standard output invece e' significativamente piu' veloce Psycho

2) Psycho e' ormai un progetto vecchio, e attualmente il JIT compiler per Python e' incluso nel progetto PyPy, che tra l'altro ho gia' linkato...

3) Nello stesso testo dice che il test e' gia' vecchio, dato che ci sono state migliorie con Java. E come ti ho detto c'e' stata un'evoluzione di Psycho in PyPy. Fare 'sti test lascia il tempo che trova. Alla fine Java e Python, se ottimizzati, si differenziano veramente poco. Se vuoi un codice davvero veloce usi C++ + Assembly. Se vuoi fare un programma facilmente portabile ed implementabile, usi Java o Python.

Fatti concreti: Python ha una sintassi piu' chiara e semplice. Java e' piu' semplice da implementare perche' Sun offre un framework completo e una piattaforma.

Dire che Python e' lentissimo, Python ha una sintassi schifida eccetera mi paiono sinceramente dei falsi problemi. Non ti piace Python? Amen. Ma non dire delle inesattezze per partito preso.

@Lucas Malor
Scusa se non replico subito ma ho il treno tra 20 minuti :stordita: A mercoledì :D

Opinabilissimo. Prendi un equivalente di Office o di Photoshop, giusto per fare un paio di esempi più noti. Ti sconsiglio di citarmi OpenOffice e TheGimp come "valide" alternative (figuriamoci "superiori"), perché sono delle ciofeche al loro confronto.
per citarti, direi "opinabilissimo" ;)
Ma no, te l'assicuro che The Gimp contro Photoshop non esiste. :) OpenOffice contro Office già è più discutibile, ma generalmente suppongo che la suite MS sia più valida.

Dire che alcuni programmi sono piu' performanti sotto ASP e dire che e' falso che ASP sia un macigno sono cose un po' diverse ;)
Vuoi che ti dica che ASP solitamente e' un macigno? Ok, ASP solitamente e' un macigno.
Aspetta. ASP.NET, come hanno detto qualche post prima, è in realtà un framework. Il codice rimane VB, C# (o C++ per CLR, F#, Boo, etc... :)) che è rigorosamente compilato come bytecode MSIL, in più viene compilato nativamente alla prima esecuzione dopodiché è velocissimo.
PHP probabilmente ha qualche vantaggio su siti più piccoli o script molto brevi (dove il tempo di compilazione di C# è superiore all'interpretazione di PHP).
Ma comunque rimane che i linguaggi che vengono compilati come MSIL sono molto veloci, non macigni. :) Il framework .NET potrebbe esserelo, semmai. Ma anche questo non è proprio vero.

Ma chissenefrega se e' proprietario o meno. L'importante e' che lo standard sia aperto. L'importante e' che sia possibile sapere come si codifica e decodifica, e se voglio aggiungerne il supporto ad un programma terzo io ne abbia la facolta' di farlo, senza strane librerie linkabili e altri schifi.
Più che librerie linkabili e "schifi" (che d'altronde non sono altro che scorciatore per evitare la scrittura di codice, se il formato è aperto), il problema sono i brevetti (MS si è inventata WMA per evitare problemi su MP3, anche). In effetti, molti videogiochi mi pare che stiano cominciando ad utilizzare OGG Vorbis come formato per i proprio file audio.
...
Comunque il fatto che MP3 sia qualitativamente inferiore a formati più moderni (come hai linkato), non implica che sia meno popolare. Anzi. Non credo proprio che alla "persona media" (definizione che mi include :)) interessi sapere che se codificata a 32kbit/s la propria musica avrebbe fruscii e suoni metallici. In realtà anche gli MP3 a 128-160kbit farebbero inorridire qualsiasi audiofilo. :D


Per la questione compilato/interpretato, sono stranamente in accordo con Lucas: stiamo parlando di dettagli linguistici e tecnici abbastanza sterili, secondo me. :rolleyes:

Su Python non mi pronuncio, ma le parentesi mancanti in C++ (o C) sono una PITA non indifferente. Ancora peggio sono i punti e virgola in fondo alla dichiarazione delle classi (che non metto mai perché in C# non servono)...

Ma no, te l'assicuro che The Gimp contro Photoshop non esiste. :) OpenOffice contro Office già è più discutibile, ma generalmente suppongo che la suite MS sia più valida.

Beh, se me lo giuri ok :D
Scherzi a parte, posso essere rimasto un poco indietro, dato che Photoshop l'ho provato tempo addietro e non l'ho mai piu' reinstallato. E comunque devo dire anche quello era un bel programmino pesante.

Aspetta. ASP.NET, come hanno detto qualche post prima, è in realtà un framework.

Ma si, lo so :rolleyes: :D

Il codice rimane VB, C# (o C++ per CLR, F#, Boo, etc... :)) che è rigorosamente compilato come bytecode MSIL, in più viene compilato nativamente alla prima esecuzione dopodiché è velocissimo.

Fatto sta che i due link che ho riportato dicevano il contrario, parlando di PHP ottimizzato. E inoltre mi baso sulla mia esperienza personale di semplice e povero utente, che smadonna ogni volta che incontra sul suo povero cammino uno stramaledettissimo sito in ASP o peggio ancora in Java.

Comunque il fatto che MP3 sia qualitativamente inferiore a formati più moderni (come hai linkato), non implica che sia meno popolare.

Niente affatto, anzi se ricordi l'ho citato come formato popolarissimo! Volevo far notare che 1) ha avuto fortuna nonostante non fosse un formato aperto, perche' comunque lo standard e' aperto 2) adesso "cominciano" ad esserci valide alternative, ed e' abbastanza certo che prima o poi mp3 verra' piano piano sostituito. Se il nuovo formato "popolare" sara' protetto da licenza non so, io spero di no!


Per la questione compilato/interpretato, sono "stranamente" in accordo con Lucas

Come sarebbe a dire, stranamente? :grrr: :ncomment: :sob: :huh: (;))

Beh, se me lo giuri ok :D
[...] E comunque devo dire anche quello era un bel programmino pesante.
Giuro, giuro. :D Poi sarà anche pesante, ma è anche altrettanto potente.

Niente affatto, anzi se ricordi l'ho citato come formato popolarissimo! Volevo far notare che 1) ha avuto fortuna nonostante non fosse un formato aperto, perche' comunque lo standard e' aperto 2) adesso "cominciano" ad esserci valide alternative, ed e' abbastanza certo che prima o poi mp3 verra' piano piano sostituito. Se il nuovo formato "popolare" sara' protetto da licenza non so, io spero di no!
Ah ok, d'accordo. Il problema dei formati (e dei codec) è che sono veramente tanti... e per avere un "nuovo" formato ultra-popolare accettato da tutti bene o male - tipo MP3 ora - ci vorrebbe un vantaggio tecnologico spaventoso oppure la "spinta" di qualcuno di veramente grosso (ed anche in questo caso la vedo dura).
Io stesso per rippare i miei Cd uso per comodità sempre WMA, se distribuissi musica mia online "moralmente" sceglierei probabilmente Vorbis - ma in entrambi i casi la scelta migliore potrebbe rimanere l'MP3 per molto tempo ancora. :)

Come sarebbe a dire, stranamente? :grrr: :ncomment: :sob: :huh: (;))
:asd:

e per avere un "nuovo" formato ultra-popolare accettato da tutti bene o male - tipo MP3 ora - ci vorrebbe un vantaggio tecnologico spaventoso oppure la "spinta" di qualcuno di veramente grosso

Eh! D'accordissimo. D'altronde passare ad un nuovo formato senza un'incentivo davvero forte e' anche controproducente. Una fatica, una perdita di tempo e forse anche un costo, per migliorie marginali (come giustamente hai fatto notare tu, considerando che chi utilizza mp3 schifa i bassi framerate).

Credo che sia anche per questo che i formati di file attuali , soprattutto i documenti, si basano su XML. E' piu' semplice l'evoluzione abbinata alla retrocompatibilita'.

Tra parentesi (non c'entra niente), e' anche per questo che amo i progetti come Firefox, che separano chiaramente il bug fixing dall'introduzione di nuove feature, oltretutto con un sistema comodissimo di update.

EDIT: comunque, sai che c'e' nel discorso Photoshop vs Gimp che mi fa propendere verso quest'ultimo? E' che Gimp si', non avra' tutte le funzioni di Photoshop, ma ci sono altri piccoli programmini od utility che le implementano, molto piu' veloci. Quindi solitamente preferisco utilizzare 3-4 programmini piuttosto che far uso di una suite. Ad esempio, per fare modifiche modifiche minori addirittura uso ancora il paint di Windows, e per convertire i file e applicargli effetti uso IrfanView.

Certo, d'altronde solo su Scite puoi inserire dei tab... :rolleyes:
Uno spazio vuoto di 8 caratteri in piu' o in meno e' sicuramente una cosa invisibile.

[...]

Tra le altre cose, il python non si confonde mica per un singolo spazio errato... http://docs.python.org/ref/indentation.html

La visibilità dei tab dipende da quanta spaziatura ogni editor conferisce ai tab (e non sempre è un'impostazione personalizzabile).

Detto questo, uno spazio vuoto di 8 caratteri, tra migliaia di righe indentate e righe più o meno corte, è sicuramente meno visibile di un "esplicito" carattere stampato.

Oltre a questo, come già detto, questo tipo di sintassi impedisce di strutturare in modo particolare i blocchi di codice ad esempio per migliorarne la leggibilità (come nell'esempio già riportato).

Poi se a te piace andare a capo 2 volte e dover usare l'indentazione per un "return 1" che è leggibilissimo con una sintassi inline, allora sui gusti non si discute.


Tra l'altro, quando fai il check della sintassi, non ti dice la riga dove l'indentazione e' sbagliata, no... mentre se scordi di chiudere una parentesi graffa non ti rimanda alla fine del file.

Oddio :rolleyes: Ma secondo te se ti rimanda alla fine del file (e potrebbe succedere, al limite, nel caso di una graffa di una funzione più che di un ciclo) è un caso o c'è un motivo? Il motivo è che il compilatore non può leggere nel pensiero del programmatore e quindi non può sapere cosa volevi fare al posto dell'errore.

Se ho una cosa del genere:

void foo() {
CODICE

void bar() {
CODICE
}


E' plausibile che ti rimandi alla fine del file perchè non può sapere se tu volevi fare 2 funzioni distinte oppure se volevi fare una funzione con una "sotto-funzione".

E' così sconvolgente?


Benissimo. Allora come definisco Java?

Lo definisci, generalmente (se non lo compili in codice nativo), come compilato in bytecode e JIT compiled.


Peccato che leggi solo quello che ti pare a te pero', visto che:

1) Python + Psycho nel test e' significamente piu' lento di Java solo per quanto riguarda l'allocazione degli oggetti. Per lo standard output invece e' significativamente piu' veloce Psycho

No... Python e Python + Psycho sono MOLTO più lenti nell'"Object Allocation" e nel "Interpreter Speed", nelle "List" (come già detto) Python è più lento di Java ma Java viene battuto con Psycho, nell'"I/O" Java è leggermente più veloce degli altri due mentre nello "Standard Output" Java è *leggermente più lento* (e lo dice pure l'autore del test "Python and Psyco slightly faster").

Come dovresti sapere, i dati vanno interpretati in rapporto tra loro e non in valore assoluto.

Per quanto riguarda invece le Hashtable, se segui l'asterisco scopri che:

"[...]
Using HashMaps makes Java around 4 times faster than Python with Psyco in that test.
[...]"

:)


2) Psycho e' ormai un progetto vecchio, e attualmente il JIT compiler per Python e' incluso nel progetto PyPy, che tra l'altro ho gia' linkato...

Quello che passa il convento... se trovi confronti tra PyPy e Java fammi sapere, comunque considerando che PyPy deriva da Psycho, anche nel caso ne avessero *raddoppiato* la velocità, vorrebbe dire vederlo passare in alcuni test da 30 volte più lento a 15 volte più lento o da 20 a 10.

Tra l'altro temo che proprio la natura di dynamic typing di Python, ne penalizzi intrinsecamente le prestazioni (anche se prima dovrei studiarmi bene il funzionamento di PyPy per esserce certo).


3) Nello stesso testo dice che il test e' gia' vecchio, dato che ci sono state migliorie con Java. E come ti ho detto c'e' stata un'evoluzione di Psycho in PyPy. Fare 'sti test lascia il tempo che trova. Alla fine Java e Python, se ottimizzati, si differenziano veramente poco. Se vuoi un codice davvero veloce usi C++ + Assembly. Se vuoi fare un programma facilmente portabile ed implementabile, usi Java o Python.

Quel test è stato fatto 3 mesi fa quindi non direi proprio che sia vecchio... e nemmeno nell'articolo lo dice: nell'articolo dice che era vecchio un altro test del quale lui ha rifatto la versione "aggiornata" 3 mesi fa, per l'appunto.

Detto questo, è tutta una questione di compromessi. Come hai detto tu ci sono linguaggi che consentono maggiori prestazioni (anche se da alcuni test risulta che Java in server mode è a volte anche più veloce del C++: http://www.kano.net/javabench/ ) di Java e Python o C# (che a me piace molto), ma dovendone scegliere uno tra questi, il primo che scarto è certamente quello mediamente più lento e con la sintassi peggiore, ovvero Python imho :D per i motivi già illustrati.


Fatti concreti: Python ha una sintassi piu' chiara e semplice. Java e' piu' semplice da implementare perche' Sun offre un framework completo e una piattaforma.

Per l'appunto... più che "chiara e semplice" direi "stupida ed insidiosa", oltre alla mancanza del costrutto case..switch (e vai di leggibilità con lunghissime catene di OR :D ): questo sì che è un fatto concreto.


Dire che Python e' lentissimo, Python ha una sintassi schifida eccetera mi paiono sinceramente dei falsi problemi. Non ti piace Python? Amen. Ma non dire delle inesattezze per partito preso.
Oddio... è lento e l'ho dimostrato, ha una sintassi oggettivamente "schifida" (e la manzanza di alcuni costrutti è certamente oggettiva) e quindi come problemi non li sottovaluterei. Se poi tu hai il gusto nell'orrido, "Amen."

;)

P.S. Ripassino di inglese prima di leggere i link che posto.

La visibilità dei tab dipende da quanta spaziatura ogni editor conferisce ai tab (e non sempre è un'impostazione personalizzabile).

Gli editor semplici utilizzato una spaziatura da 8. Quelli avanzati la puoi scegliere, ma hanno solitamente anche strumenti di evidenziazione della sintassi per i linguaggi di programmazione (come SciTe! pubblicita' :D)

Oltre a questo, come già detto, questo tipo di sintassi impedisce di strutturare in modo particolare i blocchi di codice ad esempio per migliorarne la leggibilità (come nell'esempio già riportato).

Nell'esempio che hai riportato c'e' una funzione con un'unica istruzione. Sara' forse meno impegnativo per il programmatore non sbattersi per metterla in questa forma:


function someone() {
return
}


Ma non mi puoi dire che e' meno leggibile. E' meno compatto, ma piu' leggibile. Se applico un metodo standard di scrittura, e non un metodo che vale per i blocchi con piu' di una riga di codice e quelli con una sola riga, questo e' sicuramente meno compatto ma piu' leggibile. Ed il fatto che sia un po' meno compatto per questo caso particolare (che alla fine richiede solo una riga in piu') non rende affatto il Python un linguaggio prolisso. Tutt'altro, il Python e' considerato a ragione uno dei linguaggi piu' semplici, intuitivi, facile da implementare e con una sintassi rigorosa e intellegibile. Cosa ampiamente detta da numerosi programmatori professionisti.

Oddio :rolleyes: Ma secondo te se ti rimanda alla fine del file (e potrebbe succedere, al limite, nel caso di una graffa di una funzione più che di un ciclo) è un caso o c'è un motivo?

Il motivo e' abbastanza evidente ed e' quello che hai scritto. Volevo semplicemente farti notare che in Python questo non puo' succedere, in quanto la fine di un blocco e' data dalla presenza di una linea vuota. Se non c'e' una linea vuota, l'interprete da' un errore di sintassi alla fine del blocco indentato, e non alla fine del file. L'assenza di regole di indentazione causa problemi del genere. Una sintassi del genere andava benissimo quando gli editor di testo non erano piu' sofisticati di Notepad o di Vi. Ma adesso che anche un editor da shell ha funzioni di autoindentazione questa sintassi e' controproducente.

Lo definisci, generalmente (se non lo compili in codice nativo), come compilato in bytecode e JIT compiled.

Quindi difficilmente definibile come un linguaggio compilato e stop. A chiunque programmatore se si parla di linguaggio compilato viene subito in mente il C. Ci vuole uno sforzo di immaginazione per pensare il Java come linguaggio compilato puro.

No... Python e Python + Psycho sono MOLTO più lenti nell'"Object Allocation" e nel "Interpreter Speed", nelle "List" [...]

Come dovresti sapere, i dati vanno interpretati in rapporto tra loro e non in valore assoluto.

No, i dati vanno interpretati prendendo in considerazione entrambi gli aspetti. Non ha molto senso dire che il Java e' eccezionalmente piu' performante perche' e' 30 volte piu' veloce del Python nel fare un'operazione che richiede un decimo di secondo. Con la potenza attuale dei computer ha senso dare straordinaria importanza a valori del genere? Lo stesso autore del test infatti ne minimizza l'importanza:

Python is really compact, and allows you to write code more quickly than Java. Therefore, it can improve programmer efficiency, which is often more of a scarce resource than CPU cycles.

For IO bound operations, the speed difference is much less important, which means that in most real world applications one does not need to be too concerned with the Python performance penalty.

Tra l'altro temo che proprio la natura di dynamic typing di Python, ne penalizzi intrinsecamente le prestazioni

Ovvio, ma il dynamic typing di Python e' di una potenza mostruosa, in quanto consente di poter applicare classi a diversi tipi di dato in modo semplicissimo. Per esempio il Python supporta l'accesso ad una stringa con i metodi di un file. Questo e' ottimo se vuoi gestire tipi diversi con le stesse funzioni e metodi, senza dover riscrivere lo stesso codice piu' volte. Questo tipo di typing e' chiamato "duck typing":
http://en.wikipedia.org/wiki/Duck_typing

Quel test è stato fatto 3 mesi fa quindi non direi proprio che sia vecchio... e nemmeno nell'articolo lo dice: nell'articolo dice che era vecchio un altro test del quale lui ha rifatto la versione "aggiornata" 3 mesi fa, per l'appunto.

No, non hai letto bene:

[...] the use of HashMaps under Java does provide a very significant speedup over the naive Hashtable example. Using HashMaps makes Java around 4 times faster than Python with Psyco in that test. I would agree with those who have submitted this suggestion that it is indeed the way to go these days in Java. In that case, the original HashTest here compares Python’s performance to a somewhat outdated feature in Java. This is unfortunate, but I don’t want to start changing the sources around now and redo the test. I won’t optimize the Python code to use new or better features, and also won’t change the Java code.

Non fare battute che ti si possono ritorcere contro... ;)

Inoltre ti ricordo che il Java per ottenere queste prestazioni richiede un hardware di performace alta, e come ho detto prima piu' si aumentano le performance dell'hardware piu' scompare la differenza tra Python e Java.

Oltretutto mi piacerebbe vedere un test tra Java e wxPython nella creazione di una GUI. Java mi e' sempre sembrato lento nella creazione di oggetti grafici.

Gli editor semplici utilizzato una spaziatura da 8. Quelli avanzati la puoi scegliere,

Che in quelli più avanzati si possa scegliere l'avevo detto, in quelli "semplici" dipende, molti hanno anche spaziature diverse (es. 4).



Nell'esempio che hai riportato c'e' una funzione con un'unica istruzione. Sara' forse meno impegnativo per il programmatore non sbattersi per metterla in questa forma:


function someone() {
return
}


Ma non mi puoi dire che e' meno leggibile. E' meno compatto, ma piu' leggibile. Se applico un metodo standard di scrittura, e non un metodo che vale per i blocchi con piu' di una riga di codice e quelli con una sola riga, questo e' sicuramente meno compatto ma piu' leggibile. Ed il fatto che sia un po' meno compatto per questo caso particolare (che alla fine richiede solo una riga in piu') non rende affatto il Python un linguaggio prolisso. Tutt'altro, il Python e' considerato a ragione uno dei linguaggi piu' semplici, intuitivi, facile da implementare e con una sintassi rigorosa e intellegibile. Cosa ampiamente detta da numerosi programmatori professionisti.

E' meno compatto ed anche meno leggibile imho. Sostenere che adottare la stessa soluzione (lo stesso "standard") per tutti i blocchi renda il codice più leggibile non la ritengo una grande intuizione: sarebbe come sostenere che la macchina che usi per girare il centro storico sia comunque la migliore anche in un circuito automobilistico: serve flessibilità a seconda delle esigenze... e se ho l'esigenza di scrivere quel genere codice, la struttura che avevo portato io come esempio, in quel caso, è sicuramente ottima sia a livello di compattezza che di leggibilità. E' così anche in altri casi, ad esempio le guideline di Mono per il C# dicono di utilizzare l'aperta graffa inline per i cicli mentre di andare a capo per le funzioni: utilizzi diversi per casi diversi.

Quali programmatori professionisti tu conosca poi non so, quelli che conosco io personalmente sono ampiamente schifati da Python e se devono andare "sul genere" prediligono di gran lunga Java: poi sui gusti non si discute, come già detto... io tra i 3 preferisco C# :D


Il motivo e' abbastanza evidente ed e' quello che hai scritto. Volevo semplicemente farti notare che in Python questo non puo' succedere, in quanto la fine di un blocco e' data dalla presenza di una linea vuota. Se non c'e' una linea vuota, l'interprete da' un errore di sintassi alla fine del blocco indentato, e non alla fine del file. L'assenza di regole di indentazione causa problemi del genere. Una sintassi del genere andava benissimo quando gli editor di testo non erano piu' sofisticati di Notepad o di Vi. Ma adesso che anche un editor da shell ha funzioni di autoindentazione questa sintassi e' controproducente.

Questo può essere vero... diciamo che una carenza strutturale di Python le se ritorce in questo caso a favore. Poi però ci vogliono editor avanzati per colmare queste carenze strutturali... oltretutto il break line fatto con l"'a capo" è abbastanza pericoloso perchè editor diversi su piattaforme diverse utilizzano diversi caratteri di return (non metto in dubbio che poi l'interprete/compilatore li sappia tutti) ma si rimane legati ad un file di lana: potrei fare un nuovo editor su una nuova piattaforma che utilizza un carattere diverso per l'"a capo" e addio Python: sono pericolose carenze strutturali.

Ora torno a giocare con case...switch.


Quindi difficilmente definibile come un linguaggio compilato e stop. A chiunque programmatore se si parla di linguaggio compilato viene subito in mente il C. Ci vuole uno sforzo di immaginazione per pensare il Java come linguaggio compilato puro.

Ci vuole un bello sforzo di immaginazione anche per pensare a Java come "intepretato puro" ;) Le varie differenze te le ho illustrate chiaramente direi.


No, i dati vanno interpretati prendendo in considerazione entrambi gli aspetti. Non ha molto senso dire che il Java e' eccezionalmente piu' performante perche' e' 30 volte piu' veloce del Python nel fare un'operazione che richiede un decimo di secondo. Con la potenza attuale dei computer ha senso dare straordinaria importanza a valori del genere? Lo stesso autore del test infatti ne minimizza l'importanza:

Python is really compact, and allows you to write code more quickly than Java. Therefore, it can improve programmer efficiency, which is often more of a scarce resource than CPU cycles.

For IO bound operations, the speed difference is much less important, which means that in most real world applications one does not need to be too concerned with the Python performance penalty.

No, questi dati vanno intepretati solo in rapporto (e li interpreta così anche l'autore del test, che parla chiaramente di "70x", "90x" etc.).

Se io faccio una HashTable con 2 elementi o con 2 miliardi di elementi, vedi che non è più questione di decimi di secondo, solo guardando i dati in rapporto puoi capire quanto l'uno sia realmente più veloce dell'altro.

Interessa ben poco il fatto che in quello con 2 elementi ci sia una differenza di tempistica inferiore come valore assoluto rispetto a quello con 2 miliardi, è ovvio perchè ti basi su tempistiche arbitrarie del test.

Le opinioni personali dell'autore sono poi ben poco rilevanti, io la penso differentemente e la sua opinione non è di certo più autorevole della mia... io mi limito a guardare i dati oggettivi che sono stati riportati.


Ovvio, ma il dynamic typing di Python e' di una potenza mostruosa, in quanto consente di poter applicare classi a diversi tipi di dato in modo semplicissimo. Per esempio il Python supporta l'accesso ad una stringa con i metodi di un file. Questo e' ottimo se vuoi gestire tipi diversi con le stesse funzioni e metodi, senza dover riscrivere lo stesso codice piu' volte. Questo tipo di typing e' chiamato "duck typing":
http://en.wikipedia.org/wiki/Duck_typing

Potenza mostruosa direi proprio di no, la potenza sarebbe lasciar scegliere al programmatore il tipo di dato che vuole usare. Sicuramente è "comodo", ma come già detto può penalizzare le prestazioni e rende il linguaggio scarsamente potente, quindi per quanto mi riguarda il gioco non vale la candela... oltre ad essere ampiamente diseducativo per chi si avvicina alla programmazione. Ho l'impressione che il programmatore Python stia diventando quello che era una volta il programmatore Visual Basic.


No, non hai letto bene:

[...] the use of HashMaps under Java does provide a very significant speedup over the naive Hashtable example. Using HashMaps makes Java around 4 times faster than Python with Psyco in that test. I would agree with those who have submitted this suggestion that it is indeed the way to go these days in Java. In that case, the original HashTest here compares Python’s performance to a somewhat outdated feature in Java. This is unfortunate, but I don’t want to start changing the sources around now and redo the test. I won’t optimize the Python code to use new or better features, and also won’t change the Java code.

Non fare battute che ti si possono ritorcere contro... ;)

Ho letto benissimo ;) In quella precisazione dice semplicemente (2 giorni dopo aver eseguito i test) che il codice Java che aveva utilizzato per le Hashmaps non è il migliore attualmente utilizzabile (perchè ci sono nuovi costrutti), ecco perchè nella tabella c'era quell'asterisco che ti avevo fatto presente e relativa precisazione che ti ho riportato.[/U]


Inoltre ti ricordo che il Java per ottenere queste prestazioni richiede un hardware di performace alta, e come ho detto prima piu' si aumentano le performance dell'hardware piu' scompare la differenza tra Python e Java.

Ah quindi sei quel genere di programmatore "ma si sprechiamo inutilmente memoria e CPU tanto i PC ne hanno tanta" e poi ogni hanno escono software-porcata con requisiti minimi raddoppiati (non solo in conseguenza ad eventuali nuove funzionalità) e ci si lamenta.

Pensa invece che io ordino pure gli "if..then..else" in modo che la condizione "if" sia quella mediamente più probabile in modo da minimizzare i jump in memoria :D


Oltretutto mi piacerebbe vedere un test tra Java e wxPython nella creazione di una GUI. Java mi e' sempre sembrato lento nella creazione di oggetti grafici.
Poca fatica per Python dato che le wxWidgets sono implementate in C++ :D Al limite possiamo compararli con Java che utilizza binding GTK. O con C#.

Che in quelli più avanzati si possa scegliere l'avevo detto, in quelli "semplici" dipende, molti hanno anche spaziature diverse (es. 4).

Che sono comunque ampiamente leggibili...



function someone() {
return
}

E' meno compatto ed anche meno leggibile imho.

Mi dispiace, ma non poi sostenere che secondo te e' meno leggibile. E' oggettivamente piu' leggibile. Puo' essere definito al massimo esteticamente brutto, e li' puo' rientrare la soggettivita'.

Sostenere che adottare la stessa soluzione (lo stesso "standard") per tutti i blocchi renda il codice più leggibile non la ritengo una grande intuizione: sarebbe come sostenere che la macchina che usi per girare il centro storico sia comunque la migliore anche in un circuito automobilistico

L'esempio non e' calzante, perche' su un circuito automobilistico comunque ci sono molte macchine. Cambiare la sintassi per risparmiare una riga per un caso sporadico e' una cosa abbastanza inutile.

ad esempio le guideline di Mono per il C# dicono di utilizzare l'aperta graffa inline per i cicli mentre di andare a capo per le funzioni: utilizzi diversi per casi diversi.

Ma il Python non utilizza graffe. Inoltre i cicli sono molto piu' frequenti e possono giustificare una linea guida diversa (anche se molto opinabile).

Quali programmatori professionisti tu conosca poi non so, quelli che conosco io personalmente sono ampiamente schifati da Python

Il problema e' che tu li conosci personalmente, quindi immagino siano italiani... io invece non conosco nessuno personalmente, ma ho letto numerosi articoli che parlano di Java e Python. Non credere, mi sono documentato a fondo, perche' volevo fare un programmino e volevo scegliere quale linguaggio imparare. Io personalmente non sto parlando di conoscenti, ma di programmatori di una certa fama, e sto parlando di una societa' come Google.


il break line fatto con l"'a capo" è abbastanza pericoloso perchè editor diversi su piattaforme diverse utilizzano diversi caratteri di return

.......che qualsiasi compilatore e/o interprete degno di questo nome riconosce tutti e tre........

No, questi dati vanno intepretati solo in rapporto (e li interpreta così anche l'autore del test, che parla chiaramente di "70x", "90x" etc.).

Ma l'autore riporta anche i valori assoluti, che si vede non sono cosi' inutili... ;)

Se io faccio una HashTable con 2 elementi o con 2 miliardi di elementi, vedi che non è più questione di decimi di secondo, solo guardando i dati in rapporto puoi capire quanto l'uno sia realmente più veloce dell'altro.

Vorrei vedere un programma che utilizza piu' di 1000 hash tables... ;)

Provati a vedere quanto tempo ci mette in piu' il Java con 1000 output, cosa un po' piu' realistica.

E comunque l'efficienza di interpretazione puo' essere migliorata, come infatti si sta cercando di fare, sia in Python che in Java. Cambiare la sintassi e' piu' ostico.

Le opinioni personali dell'autore sono poi ben poco rilevanti, io la penso differentemente e la sua opinione non è di certo più autorevole della mia... io mi limito a guardare i dati oggettivi che sono stati riportati.

Fatto sta che sia io che l'autore del test siamo giunti alla stessa conclusione... e questo dovrebbe farti riflettere ;)

la potenza sarebbe lasciar scegliere al programmatore il tipo di dato che vuole usare.

E infatti in un post precedente ti avevo postato il progetto per il linguaggio Python di tipizzazione statica opzionale.

Sicuramente è "comodo", ma come già detto può penalizzare le prestazioni e rende il linguaggio scarsamente potente, quindi per quanto mi riguarda il gioco non vale la candela

Da questo punto di vista allora dovresti considerare anche Java come un linguaggio inutile.

oltre ad essere ampiamente diseducativo per chi si avvicina alla programmazione. Ho l'impressione che il programmatore Python stia diventando quello che era una volta il programmatore Visual Basic.

Sinceramente il BASIC e' qualcosa che piu' si allontana dalla filosofia Python... e' molto diseducativo invece imparare a programmare ad algoritmi senza neanche dare un'occhiata alle classi, e ad imparare linguaggi come il Pascal, il Basic, il Fortran, il Javascript, l'HTML, il PHP, il COBOL, il C (!). E' diseducativo programmare senza commenti, sintassi e indentazione appropriati, senza pensare alla portabilita', alla robustezza, alla performance e all'accessibilita' finale del software. E IMHO e' diseducativo imparare linguaggi di programmazione come .NET o Visual qualcosa, che richiedono suite costosissime e sono valide solo per programmi Windows ;)

Ho letto benissimo ;) In quella precisazione dice semplicemente (2 giorni dopo aver eseguito i test) che il codice Java che aveva utilizzato per le Hashmaps non è il migliore attualmente utilizzabile (perchè ci sono nuovi costrutti), ecco perchè nella tabella c'era quell'asterisco che ti avevo fatto presente e relativa precisazione che ti ho riportato.[/U]

Esatto, ed io proprio questo dicevo: un test che era gia' vecchio dopo due giorni, pensa dopo 3 mesi ;)

Ah quindi sei quel genere di programmatore "ma si sprechiamo inutilmente memoria e CPU tanto i PC ne hanno tanta" e poi ogni hanno escono software-porcata con requisiti minimi raddoppiati (non solo in conseguenza ad eventuali nuove funzionalità) e ci si lamenta.

Sbagliato! :D

Pensa invece che io ordino pure gli "if..then..else" in modo che la condizione "if" sia quella mediamente più probabile in modo da minimizzare i jump in memoria :D

Beh, pensa che io invoco l'operatore di distruzione anche per un integer che non serve piu' :D

Non e' questo il punto, e' che i linguaggi interpretati (o compilati in bytecode... :rolleyes:) sono comodissimi, e possono comunque essere ottimizzati, basta compilare staticamente il prodotto finale!

Poca fatica per Python dato che le wxWidgets sono implementate in C++

Ma se e' per questo anche Python e' implementato in C++......... e scommetto quello che vuoi, anche il Java ;)

Che sono comunque ampiamente leggibili...

Comunque meno di espliciti caratteri stampati ;)


Mi dispiace, ma non poi sostenere che secondo te e' meno leggibile. E' oggettivamente piu' leggibile. Puo' essere definito al massimo esteticamente brutto, e li' puo' rientrare la soggettivita'.

Lo sarebbe se esistesse un criterio esatto per definire la leggibilità e se poi la rispettasse... ma purtroppo non è così, quindi non solo non è oggettivamente leggibile, ma secondo me, come già detto, è meno leggibile E meno compatto ;)


L'esempio non e' calzante, perche' su un circuito automobilistico comunque ci sono molte macchine. Cambiare la sintassi per risparmiare una riga per un caso sporadico e' una cosa abbastanza inutile.

Non è solo questione di 1 riga, è come già detto questione di leggibilità, di compattezza, di ordine, di immediatezza, di flessibilità.


Ma il Python non utilizza graffe. Inoltre i cicli sono molto piu' frequenti e possono giustificare una linea guida diversa (anche se molto opinabile).

Che c'entra? :D Era un esempio per farti vedere che è "usuale" adattare criteri diversi di impostazione del codice per casi diversi.


Il problema e' che tu li conosci personalmente, quindi immagino siano italiani... io invece non conosco nessuno personalmente, ma ho letto numerosi articoli che parlano di Java e Python. Non credere, mi sono documentato a fondo, perche' volevo fare un programmino e volevo scegliere quale linguaggio imparare. Io personalmente non sto parlando di conoscenti, ma di programmatori di una certa fama, e sto parlando di una societa' come Google.

Io tra gli altri ne conosco uno di Vodafone che detesta incredibilmente Python :D Come già detto è questione di gusti. Tra l'altro il discorso "scelgo quale linguaggio imparare" personalmente non mi appartiene, dato che conosco circa una decina di linguaggi e quindi ritengo di avere una visione discretamente ampia.


.......che qualsiasi compilatore e/o interprete degno di questo nome riconosce tutti e tre........

E' quello che ho detto... ma credo renda bene l'idea di quanto sia un linguaggio strutturalmente debole anche sotto questo punto di vista.


Ma l'autore riporta anche i valori assoluti, che si vede non sono cosi' inutili... ;)

Per forza sono i valori ottenuti nei test... ma che discorsi fai :rolleyes: :rolleyes:


Vorrei vedere un programma che utilizza piu' di 1000 hash tables... ;)

In realtà non ho parlato di Hashtable, ma di elementi nell'hashtable, leggi bene. Comunque non è questo il punto.


Provati a vedere quanto tempo ci mette in piu' il Java con 1000 output, cosa un po' piu' realistica.

Nel test ne fa 1 milione e c'è una differenza di circa 4 secondi (25 vs 29).

Volendo essere pignoli credo che 1 milione di uscite su standard output siano un po' meno realistiche di 1000 elementi (che non sono nemmeno molti) in una hastable.


E comunque l'efficienza di interpretazione puo' essere migliorata, come infatti si sta cercando di fare, sia in Python che in Java. Cambiare la sintassi e' piu' ostico.

Questo è ovvio.


Fatto sta che sia io che l'autore del test siamo giunti alla stessa conclusione... e questo dovrebbe farti riflettere ;)

Dubito che tu e l'autore di quel test siate particolarmente rappresentativi, come non lo sono io da solo ovviamente. Tra l'altro bisognerebbe vedere anche l'esperienza, se 5 bovari contraddissero il solo Linus Torvalds in materia di kernel Linux, non credo che Linus avrebbe molto su cui riflettere.


E infatti in un post precedente ti avevo postato il progetto per il linguaggio Python di tipizzazione statica opzionale.

Ahhhh... il progetto. Ah beh, se c'è "il progetto"......


Da questo punto di vista allora dovresti considerare anche Java come un linguaggio inutile.

Diciamo che ho una mia scala di valori. Python è sotto a Java, Java è sotto a C# etc. etc. etc.


Sinceramente il BASIC e' qualcosa che piu' si allontana dalla filosofia Python... e' molto diseducativo invece imparare a programmare ad algoritmi senza neanche dare un'occhiata alle classi, e ad imparare linguaggi come il Pascal, il Basic, il Fortran, il Javascript, l'HTML, il PHP, il COBOL, il C (!). E' diseducativo programmare senza commenti, sintassi e indentazione appropriati, senza pensare alla portabilita', alla robustezza, alla performance e all'accessibilita' finale del software

Be' il Python è a tipizzazione dinamica... se non è diseducativo questo... credo sia una delle cose più diseducative in assoluto.


E IMHO e' diseducativo imparare linguaggi di programmazione come .NET o Visual qualcosa, che richiedono suite costosissime e sono valide solo per programmi Windows ;)

Don't you know "Mono"? http://www.mono-project.com


Esatto, ed io proprio questo dicevo: un test che era gia' vecchio dopo due giorni, pensa dopo 3 mesi ;)

Ma ci sei o ci fai? Ti ho detto che non era stato utilizzato Java al massimo delle sue attuali potenzialità in quel test e alcune persone glielo hanno fatto notare, quindi lui dopo 2 giorni ha inserito un update dicendo che con il codice sistemato Java primeggiava. Non c'è ne'è di vecchio...


Beh, pensa che io invoco l'operatore di distruzione anche per un integer che non serve piu' :D

Non dirmi che Python alloca dinamicamente un integer :D


Non e' questo il punto, e' che i linguaggi interpretati (o compilati in bytecode... :rolleyes:) sono comodissimi, e possono comunque essere ottimizzati, basta compilare staticamente il prodotto finale!

C'è una bella differenza tra interpretati e compilati in bytecode...

Cosa intendi per "compilati staticamente"? Ahead of time?


Ma se e' per questo anche Python e' implementato in C++......... e scommetto quello che vuoi, anche il Java ;)
CPython è in C non in C++, ma non è il C ad essere lento, bensì il Python... vorrei proprio vedere un toolkit grafico implementato in Python quanto sarebbe veloce ;)

Comunque meno di espliciti caratteri stampati
[...]
Lo sarebbe se esistesse un criterio esatto per definire la leggibilità e se poi la rispettasse... ma purtroppo non è così, quindi non solo non è oggettivamente leggibile, ma secondo me, come già detto, è meno leggibile E meno compatto
[...]
Non è solo questione di 1 riga, è come già detto questione di leggibilità, di compattezza, di ordine, di immediatezza, di flessibilità.

Vabbe'... io ci rinuncio :rolleyes: :D

Ma il Python non utilizza graffe. Inoltre i cicli sono molto piu' frequenti e possono giustificare una linea guida diversa (anche se molto opinabile).
Che c'entra? :D Era un esempio per farti vedere che è "usuale" adattare criteri diversi di impostazione del codice per casi diversi.

Ed e' un esempio sbagliato, perche' i cicli sono un caso molto piu' frequente, come ho gia' detto. Non ha senso chiedere ai developers del Python di aggiungere un'eccezione alla sintassi per un caso tanto raro.

Io tra gli altri ne conosco uno di Vodafone che detesta incredibilmente Python :D

A beh! Allora scusa...... :D

il break line fatto con l"'a capo" è abbastanza pericoloso perchè editor diversi su piattaforme diverse utilizzano diversi caratteri di return
E' quello che ho detto... ma credo renda bene l'idea di quanto sia un linguaggio strutturalmente debole anche sotto questo punto di vista.

Aaaaaaaaaah aspetta che ho capito.... tu mi vorresti dire che se spunta fuori un nuovo carattere di newline, il Python non funziona piu', mentre i compilatori per altri linguaggi si????? :doh: :asd: :ave: :eekk: :D
Guarda, questa e' la cosa piu' divertente che abbia mai letto.... :sofico:

Per forza sono i valori ottenuti nei test... ma che discorsi fai :rolleyes:

Eh gia' che scemo che sono.... :rolleyes:

In realtà non ho parlato di Hashtable, ma di elementi nell'hashtable, leggi bene. Comunque non è questo il punto.

Nel test ne fa 1 milione e c'è una differenza di circa 4 secondi (25 vs 29).

Volendo essere pignoli credo che 1 milione di uscite su standard output siano un po' meno realistiche di 1000 elementi (che non sono nemmeno molti) in una hastable.

Io non capiro' l'inglese (cosa che mi e' completamente nuova!), ma tu non capisci il codice sorgente:

import java.util.Hashtable;

public class HashTest {
public static void main(String[] args) {
for (int i = 0; i < 1000; i++) {
Hashtable x = new Hashtable();
for (int j = 0; j < 1000; j++) {
x.put(new Integer(i), new Integer(j));
x.get(new Integer(i));
}
}
}
}

C'e' un DOPPIO ciclo for da 1000 step. Il primo ciclo crea una hashtable, il secondo mette nella hashtable un nuovo elemento e ne fa' l'output. Totale: 1 milione di elementi.

Dubito che tu e l'autore di quel test siate particolarmente rappresentativi, come non lo sono io da solo ovviamente. Tra l'altro bisognerebbe vedere anche l'esperienza, se 5 bovari contraddissero il solo Linus Torvalds in materia di kernel Linux, non credo che Linus avrebbe molto su cui riflettere.

Beh, ringrazio a nome di tutti i bovari :D

http://www.mono-project.comDon't you know "Mono"? http://www.mono-project.com

Utile solo per poter portare i programmi .NET su piattaforma Linux.

Ma ci sei o ci fai? Ti ho detto che non era stato utilizzato Java al massimo delle sue attuali potenzialità in quel test e alcune persone glielo hanno fatto notare, quindi lui dopo 2 giorni ha inserito un update dicendo che con il codice sistemato Java primeggiava. Non c'è ne'è di vecchio...

E poi io non capisco l'inglese.... :D

I would agree with those who have submitted this suggestion that it is indeed the way to go these days in Java. In that case, the original HashTest here compares Python’s performance to a somewhat outdated feature in Java. This is unfortunate, but I don’t want to start changing the sources around now and redo the test. I won’t optimize the Python code to use new or better features, and also won’t change the Java code.

E questa e' la seconda volta che te lo posto...

Non dirmi che Python alloca dinamicamente un integer :D

Ho parlato di Python? ;)

Cosa intendi per "compilati staticamente"? Ahead of time?

Sai quei bellissimi eseguibili scritti in machine code che non hanno bisogno piu' di interpreti e compilatori? Ecco, quelli :sofico:

CPython è in C non in C++, ma non è il C ad essere lento, bensì il Python... vorrei proprio vedere un toolkit grafico implementato in Python quanto sarebbe veloce ;)

Ah, scusa, errore mio, avevo capito un'altra cosa :)

Vabbe'... io ci rinuncio :rolleyes: :D

Fai bene... tenti di fare una questione oggettiva di una cosa che è assolutamente soggettiva (fino a che non definirai quel canone ed esso non verrà soddisfatto). La differenza è appunto che io, a differenza di te, non ne faccio una questione "oggettiva".


Ed e' un esempio sbagliato, perche' i cicli sono un caso molto piu' frequente, come ho gia' detto. Non ha senso chiedere ai developers del Python di aggiungere un'eccezione alla sintassi per un caso tanto raro.

Ripeto: ma ci sei o ci fai? Nessuno ha detto che Python dovrebbe avere questa cosa, era solo un generico esempio per farti vedere che è "usuale" adattare criteri diversi di impostazione del codice per casi diversi.


Aaaaaaaaaah aspetta che ho capito.... tu mi vorresti dire che se spunta fuori un nuovo carattere di newline, il Python non funziona piu', mentre i compilatori per altri linguaggi si????? :doh: :asd: :ave: :eekk: :D
Guarda, questa e' la cosa piu' divertente che abbia mai letto.... :sofico:

Sarà anche divertente ma è la verità, per quanto improbabile possa essere.


Eh gia' che scemo che sono.... :rolleyes:

Li hai fatti tu quei discorsi ;)


Io non capiro' l'inglese (cosa che mi e' completamente nuova!), ma tu non capisci il codice sorgente:



C'e' un DOPPIO ciclo for da 1000 step. Il primo ciclo crea una hashtable, il secondo mette nella hashtable un nuovo elemento e ne fa' l'output. Totale: 1 milione di elementi.

Per quanto concerne l'inglese mi sembra evidente, per quanto concerne il codice avevo letto male ed hai ragione. In ogni caso rimane una situazione ben più realistica di 1 milione di righe su standard output... anche perchè solitamente l'output è correlato ad altre funzionalità del programma che devono essere eseguite, a meno che i tuoi programmi non siano cose del tipo "stampare a video a raffica 1 milione di volte la scritta "Ciao Mondo").


Utile solo per poter portare i programmi .NET su piattaforma Linux.

E Solaris. E MacOS X. E FreeBSD. E OpenBSD. E NetBSD. La tua tesi del "solo Windows" mi sembra carente.


E poi io non capisco l'inglese.... :D

I would agree with those who have submitted this suggestion that it is indeed the way to go these days in Java. In that case, the original HashTest here compares Python’s performance to a somewhat outdated feature in Java. This is unfortunate, but I don’t want to start changing the sources around now and redo the test. I won’t optimize the Python code to use new or better features, and also won’t change the Java code.

E questa e' la seconda volta che te lo posto...

Già... e continui a dimostrarlo. Sta dicendo che nel caso altra gente gli segnalasse modi migliori e più attuali di svolgere gli algoritmi di test, lui non li modificherà (come non ha fatto per le Hastables in Java, ha solo messo un asterisco con una precisazione). Non c'entra nulla col fatto che il test sia vecchio, il test è di 3 mesi fa quindi piuttosto recente, è una questione di algoritmi.


Ho parlato di Python? ;)

Hai parlato di qualcosa di differente da Python? Su cosa verte secondo te la discussione? Comunque vale per qualsiasi linguaggio... se fai l'allocazione dinamica per 1 integer ti giudichi da solo.


Sai quei bellissimi eseguibili scritti in machine code che non hanno bisogno piu' di interpreti e compilatori? Ecco, quelli :sofico:

Ah... quindi una cosa diversa dal "compilati staticamente". Eseguibili compilati nativamente: campo del quale Python la fa da padrone eh? :D


Ah, scusa, errore mio, avevo capito un'altra cosa :)
Già

Fai bene... tenti di fare una questione oggettiva di una cosa che è assolutamente soggettiva (fino a che non definirai quel canone ed esso non verrà soddisfatto). La differenza è appunto che io, a differenza di te, non ne faccio una questione "oggettiva".

Certo, esistono soltanto studi sul campo... gente che spreca tempo! Un po' come il qui presente che cerca di fartelo capire :D

Ripeto: ma ci sei o ci fai? Nessuno ha detto che Python dovrebbe avere questa cosa, era solo un generico esempio per farti vedere che è "usuale" adattare criteri diversi di impostazione del codice per casi diversi.

Dunque, fammi capire una cosa: tu dici che il Python dovrebbe avere delle eccezioni nella sintassi (e le ha, quindi parli anche di una cosa che non conosci), e fai un esempio che non e' applicabile, solo per fare un'esempio di eccezione? Se permetti, io ti blasto, e ho tutte le ragioni. Portami un esempio per il quale il Python dovrebbe avere una sintassi meno rigida (a parte l'indentazione, che quello si e' capito), oppure lascia perdere...


Aaaaaaaaaah aspetta che ho capito.... tu mi vorresti dire che se spunta fuori un nuovo carattere di newline, il Python non funziona piu', mentre i compilatori per altri linguaggi si?????
Guarda, questa e' la cosa piu' divertente che abbia mai letto....
Sarà anche divertente ma è la verità, per quanto improbabile possa essere.

Ahahahahah..... sei impagabile :D A meno che non sia un tab o uno space, e voglio vedere quale stupendo character set li sostituisca con il newline, mi spieghi perche' un compilatore qualsiasi dovrebbe zompare un carattere sconosciuto e non ritornare errore? Dai, sono curioso!!! :sofico:

Altro che fragilita' di linguaggio di programmazione, a me pare che qui ci sia solo fragilita' di argomentazioni! :cool:

Per quanto concerne l'inglese mi sembra evidente, per quanto concerne il codice avevo letto male ed hai ragione. In ogni caso rimane una situazione ben più realistica di 1 milione di righe su standard output... anche perchè solitamente l'output è correlato ad altre funzionalità del programma che devono essere eseguite, a meno che i tuoi programmi non siano cose del tipo "stampare a video a raffica 1 milione di volte la scritta "Ciao Mondo").

E certo, perche' Java non viene utilizzato nelle applicazioni web... e li' l'output e' proprio rarissimo! :asd: 'Sto discorso si fa sempre piu' divertente... :D

E Solaris. E MacOS X. E FreeBSD. E OpenBSD. E NetBSD. La tua tesi del "solo Windows" mi sembra carente.

Eheheh... "la mia tesi". Beh, "la mia tesi" e' che e' un progetto di framework non ufficialmente supportato, il che la dice lunga di quanto possa essere fedele all'originale.
Oltretutto, ritornando IT (evviva! :D) molto probabilmente se quelli di Mono sfrutteranno le informazioni del codice sorgente di .NET, questo fara' si' che chiunque utilizzi .NET e Mono possa incorrere in cause legali e possa vedersi oltretutta revocata la licenza di .NET. BELLO .NET! :sofico:


Già... e continui a dimostrarlo. Sta dicendo che nel caso altra gente gli segnalasse modi migliori e più attuali di svolgere gli algoritmi di test, lui non li modificherà (come non ha fatto per le Hastables in Java, ha solo messo un asterisco con una precisazione). Non c'entra nulla col fatto che il test sia vecchio, il test è di 3 mesi fa quindi piuttosto recente, è una questione di algoritmi.

Gia' peccato che nel testo parla anche di buffered IO, del quale pero' nell'update non fa menzione dei risultati. Non fa menzione neanche se abbia utilizzato con Python senza Psycho una strategia interpretata pura o bytecode. E non so se ti sei reso conto che stiamo attualmente alla versione 2.5.1 per Python e alle JDK 6, mentre il test fa riferimento a Python 1.5.2 and JDK 1.1.

Solo tre mesi? Solo tre mesi in informatica?

Ah... quindi una cosa diversa dal "compilati staticamente". Eseguibili compilati nativamente: campo del quale Python la fa da padrone eh? :D

Qualunque linguaggio interpretato puo' essere anche compilato staticamente, caro. Non e' che il C ha l'esclusiva. Penso esistano compilatori statici anche per il Java, e non e' che anche il Java sia ferrato sull'argomento.
Lasciare il programma in modo che sia interpretato o compilato dinamicamente e' ottimo se sei un programmatore. Inoltre e' ottimo se non vuoi sbatterti a ricompilare ogni volta il programma finale. Ma secondo me la cosa migliore sarebbe: linguaggio interpretato / compilato dinamicamente per il programmatore, eseguibile per l'utente. Esistono compilatori statici per il Python, mi ci gioco la testa esistono anche per il Java e che molta gente li usa. La prima volta che ho chiesto nel forum ufficiale di Python un modo per migliorare le prestazioni mi hanno subito consigliato interpretazione ottimizzata e PyPy. Quindi se non conosci il linguaggio perlomeno non straparlare.

Hai parlato di qualcosa di differente da Python? Su cosa verte secondo te la discussione? Comunque vale per qualsiasi linguaggio... se fai l'allocazione dinamica per 1 integer ti giudichi da solo.

Ma chi ha parlato di allocazione dinamica! :rolleyes: Avevo fatto un esempio della mia pazzia informatica (passata, perche' mi resi conto fortunatamente di quanto fosse assurda la cosa... :D) solo per stemperare i toni, e tu ne hai approfittato per attaccarmi di nuovo in modo ridicolo... :rolleyes: Tutto questo e' abbastanza patetico.

Continua pure a cavillare se Java sia da considerare piu' compilato o piu' interpretato, se .NET possa considerarsi facilmente portabile, se Java sia nettamente superiore al Python, se la leggibilita' sia un'opinione, se il Python faccia cagare. La tua conoscenza del Python ho riscontrato essere bassa e superficiale, probabilmente perche' sei prevenuto nei confronti di quel linguaggio. Perlomeno IO ho avuto il buon gusto di non mettermi a filosofeggiare sulla sintassi di Visual C++ e di tutti i prodotti associabili al .NET, con il quale non ho mai programmato. :cool:

Dai su... non litigate. :D Ognuno usa il linguaggio che preferisce, ogni cosa ha i suoi pro ed i suoi contro (a parte Cobol che è IL MALE :asd:).
Se Python è più lento è certamente giustificato dal typing dinamico e dalla flessibilità del linguaggio (che di solito si converte in facilità e velocità di sviluppo) e viceversa. Per la sintassi entriamo nei giudizi soggettivi, per cui reputo ogni dibattito abbastanza sterile.

Comunque l'Osservatore Romano è contro l'opensource (http://www.uaar.it/news/2007/10/19/osservatore-romano-contro-openoffice) per cui il closed source è l'unica retta via: gli infedeli verranno messi al bando e perseguitati. Stai attento Lucas! :nonsifa:

Metto le mani avanti: sono sarcastico ed il link è satirico. ;)

Certo, esistono soltanto studi sul campo... gente che spreca tempo! Un po' come il qui presente che cerca di fartelo capire :D

Ahhh... gli "studi" :rolleyes:



Dunque, fammi capire una cosa: tu dici che il Python dovrebbe avere delle eccezioni nella sintassi (e le ha, quindi parli anche di una cosa che non conosci), e fai un esempio che non e' applicabile, solo per fare un'esempio di eccezione? Se permetti, io ti blasto, e ho tutte le ragioni. Portami un esempio per il quale il Python dovrebbe avere una sintassi meno rigida (a parte l'indentazione, che quello si e' capito), oppure lascia perdere...

No, io non dico che le dovrebbe avere, io dico che in generale è perfettamente lecito che ci possano essere.


Ahahahahah..... sei impagabile :D A meno che non sia un tab o uno space, e voglio vedere quale stupendo character set li sostituisca con il newline, mi spieghi perche' un compilatore qualsiasi dovrebbe zompare un carattere sconosciuto e non ritornare errore? Dai, sono curioso!!! :sofico:

Altro che fragilita' di linguaggio di programmazione, a me pare che qui ci sia solo fragilita' di argomentazioni! :cool:

Per il semplice motivo che non c'è uno standard universale per definire il carattere di "a capo", infatti Windows, *nix e MacOS utilizzano 3 metodi differenti.


E certo, perche' Java non viene utilizzato nelle applicazioni web... e li' l'output e' proprio rarissimo! :asd: 'Sto discorso si fa sempre piu' divertente... :D

... ah ed in quel caso fai l'output con System.out.println() ? ;)


Eheheh... "la mia tesi". Beh, "la mia tesi" e' che e' un progetto di framework non ufficialmente supportato, il che la dice lunga di quanto possa essere fedele all'originale.
Oltretutto, ritornando IT (evviva! :D) molto probabilmente se quelli di Mono sfrutteranno le informazioni del codice sorgente di .NET, questo fara' si' che chiunque utilizzi .NET e Mono possa incorrere in cause legali e possa vedersi oltretutta revocata la licenza di .NET. BELLO .NET! :sofico:

Evidentemente non sei a conoscenza del fatto che le specifiche CLI e C# sono standard ECMA/ISO: http://www.mono-project.com/ECMA


Gia' peccato che nel testo parla anche di buffered IO, del quale pero' nell'update non fa menzione dei risultati. Non fa menzione neanche se abbia utilizzato con Python senza Psycho una strategia interpretata pura o bytecode. E non so se ti sei reso conto che stiamo attualmente alla versione 2.5.1 per Python e alle JDK 6, mentre il test fa riferimento a Python 1.5.2 and JDK 1.1.

Solo tre mesi? Solo tre mesi in informatica?


Peccato che? :D Dice semplicemente che si poteva utilizzare il buffered IO con entrambi i linguaggi ma non lo ha fatto nei test anche perchè generalmente non si usa. Python senza Psycho presumo (anzi, ne sono quasi certo) sia intepretato ma è in ogni caso irrilevante dato che se le prende *sonoramente*.

Inoltre, il test che ti ho linkato utilizza Java 6 e Python 2.5 :read:

"I decided to redo several of the tests with updated versions of Python (2.5) and the JDK (Java 6). And indeed, my suspicions were confirmed: Java has made huge speed improvements, and is now faster than Python in almost all cases."

Du iu spik inglisc?

Guarda anche l'intestazione della tabella con i dati.


Qualunque linguaggio interpretato puo' essere anche compilato staticamente, caro. Non e' che il C ha l'esclusiva. Penso esistano compilatori statici anche per il Java, e non e' che anche il Java sia ferrato sull'argomento.
Lasciare il programma in modo che sia interpretato o compilato dinamicamente e' ottimo se sei un programmatore. Inoltre e' ottimo se non vuoi sbatterti a ricompilare ogni volta il programma finale. Ma secondo me la cosa migliore sarebbe: linguaggio interpretato / compilato dinamicamente per il programmatore, eseguibile per l'utente. Esistono compilatori statici per il Python, mi ci gioco la testa esistono anche per il Java e che molta gente li usa. La prima volta che ho chiesto nel forum ufficiale di Python un modo per migliorare le prestazioni mi hanno subito consigliato interpretazione ottimizzata e PyPy. Quindi se non conosci il linguaggio perlomeno non straparlare.

"Qualunque" direi proprio di no, al massimo quelli che dispongono di un opportuno compilatore in codice nativo ;) Per Java esistono (gcj ad esempio). La compilazione in bytecode è sempre una compilazione e quindi anche lì devi "sbatterti a compilare" (operazione che è comunque relativamente rapida se escludiamo linguaggi come C e C++ che per come vengono compilati ci mettono un'eternità).

Comunque per curiosità citami un compilatore in codice nativo degno di tale nome per Python, che supporti interamente le specifiche del linguaggio.


Ma chi ha parlato di allocazione dinamica! :rolleyes: Avevo fatto un esempio della mia pazzia informatica (passata, perche' mi resi conto fortunatamente di quanto fosse assurda la cosa... :D) solo per stemperare i toni, e tu ne hai approfittato per attaccarmi di nuovo in modo ridicolo... :rolleyes: Tutto questo e' abbastanza patetico.

Per deallocare un integer in run-time deve essere stato evidentemente allocato dinamicamente... o no?

Patetico è più che altro il tuo continuo :mc:


Continua pure a cavillare se Java sia da considerare piu' compilato o piu' interpretato, se .NET possa considerarsi facilmente portabile, se Java sia nettamente superiore al Python, se la leggibilita' sia un'opinione, se il Python faccia cagare. La tua conoscenza del Python ho riscontrato essere bassa e superficiale, probabilmente perche' sei prevenuto nei confronti di quel linguaggio. Perlomeno IO ho avuto il buon gusto di non mettermi a filosofeggiare sulla sintassi di Visual C++ e di tutti i prodotti associabili al .NET, con il quale non ho mai programmato. :cool:
Fino ad ora le uniche cose basse e superficiali che sono state riscontrate sono la tua conoscenza dell'inglese, le tue capacità di distinguere Python dal C++ (vedi l'uscita sulle wxWidgets), le tue conoscenze sulla licenza di Mono e sull'allocazione dinamica della memoria.

Dai su... non litigate. :D Ognuno usa il linguaggio che preferisce, ogni cosa ha i suoi pro ed i suoi contro (a parte Cobol che è IL MALE :asd:).

Ma si, posso anche lasciarlo continuare ekerazha, tanto si diverte anche da solo :D

Se Python è più lento è certamente giustificato dal typing dinamico e dalla flessibilità del linguaggio (che di solito si converte in facilità e velocità di sviluppo) e viceversa. Per la sintassi entriamo nei giudizi soggettivi, per cui reputo ogni dibattito abbastanza sterile.

E vaglielo a spiegare... :rolleyes: Tanto ha deciso che il Python fa schifo e schifo deve fare!

Comunque l'Osservatore Romano è contro l'opensource (http://www.uaar.it/news/2007/10/19/osservatore-romano-contro-openoffice) per cui il closed source è l'unica retta via: gli infedeli verranno messi al bando e perseguitati. Stai attento Lucas! :nonsifa:

Metto le mani avanti: sono sarcastico ed il link è satirico. ;)

Se mi scomunicano con tanto di bolla avro' qualcosa con cui vantarmi con i miei amici! :D

E vaglielo a spiegare... :rolleyes: Tanto ha deciso che il Python fa schifo e schifo deve fare!

Non avrei motivo di dirlo se non lo pensassi sinceramente, non sono pagato per criticare Python.

Cacchio si spera di no! Ma sei coi paraocchi cavolo! :p

Ti diro', a me a pelle il Java non piaceva, e non piace neanche adesso. Pero' non ci ho mai programmato! Se dovessi giudicare il Java, lo farei solo dopo aver fatto un programma veramente importante, ed essermi sbattuto per farlo bene ed imparato la sintassi a dovere, cosa che ho fatto col Python.

Sono alla fine due linguaggi molto simili, e io non capisco proprio perche' tutto questo odio alla fine per un sano concorrente che non puo' che spingere Java a migliorare, e viceversa! Se vedi in Wikipedia i linguaggi da cui si e' ispirato Python, ci trovi Java.

Eccheppale, tre ore a discutere di test con 10 millesimi di secondo di differenza dopo un milione di cicli... ma che senso ha! Ma stica**i dei 10 millesimi! E dai! :muro:

Eheheh... "la mia tesi". Beh, "la mia tesi" e' che e' un progetto di framework non ufficialmente supportato, il che la dice lunga di quanto possa essere fedele all'originale.
Oltretutto, ritornando IT (evviva! :D) molto probabilmente se quelli di Mono sfrutteranno le informazioni del codice sorgente di .NET, questo fara' si' che chiunque utilizzi .NET e Mono possa incorrere in cause legali e possa vedersi oltretutta revocata la licenza di .NET. BELLO .NET! :sofico:
Uh? :mbe:
Non vedo il problema, nessun ipotetico "fork" di .NET avrebbe il "supporto ufficiale" (se intendi quello MS). Mono non ha il supporto MS, ma rispetta le specifiche di .NET (altrimenti difficilmente adempierebbe ai suoi compiti di framework multipiattaforma per .NET...).
Comunque lo sviluppatore "capo" di Mono, Miguel de Icaza (mito :)), ha già rilasciato un commento (http://tirania.org/blog/archive/2007/Oct-05-2.html) riguardo ai pericoli di copiare il codice open-source di MS: in poche parole (ma leggete l'articolo di Miguel che è meglio) Mono non corre nessun rischio perché è sempre stato sviluppato da 0. Anzi, sono molto attenti nel non includere codice con licenze non compatibili o accettare codice da chi conosce l'implementazione MS di .NET. Come faceva chi lavorava a GNU, senza dover assolutamente "prendere spunto" dal codice di Unix.

Se mi scomunicano con tanto di bolla avro' qualcosa con cui vantarmi con i miei amici! :D
Idem! :sofico:

Sono d'accordo che Mono possa benissimo vivere senza il codice MS del .NET, ho dato una valutazione frettolosa.

Pero' a mio parere il pericolo c'e'. Ultimamente il portavoce Microsoft Ballmer sta minacciando a destra ed a manca molti progetti open source. Era in una delle news del sito, adesso sono troppo assonnato per cercarla... =_=

La Microsoft puo' benissimo inventarsi tra qualche mese, quando comincera' a temere anche Mono, che esso abbia copiato codice Microsoft. E anche se fosse una bufala, possono i developers del progetto sostenere una causa legale contro un gigante del calibro della Microsoft?

Per questo sono molto scettico. Uno se ha un problema con un framework, la prima cosa che fa' e' chiedere assistenza, non andare a cercare dentro il codice sorgente quale potrebbe essere il problema. La Microsoft non fa mai niente per niente, e questo in apparenza sembra proprio niente.......

Eccheppale, tre ore a discutere di test con 10 millesimi di secondo di differenza dopo un milione di cicli... ma che senso ha! Ma stica**i dei 10 millesimi! E dai! :muro:
I 10ms sono relativi... se utilizzassi pesantemente le hastable ad esempio, dal test risulta che Java sarebbe preferibile. Mediamente Java è più veloce di Python. Detto questo, io solitamente programmo in C e C#. Poi chi è innamorato della sintassi di Python può sempre provare IronPython...

Pero' a mio parere il pericolo c'e'. Ultimamente il portavoce Microsoft Ballmer sta minacciando a destra ed a manca molti progetti open source. Era in una delle news del sito, adesso sono troppo assonnato per cercarla... =_=

Quindi preferisci sottostare al suo gioco.


La Microsoft puo' benissimo inventarsi tra qualche mese, quando comincera' a temere anche Mono, che esso abbia copiato codice Microsoft. E anche se fosse una bufala, possono i developers del progetto sostenere una causa legale contro un gigante del calibro della Microsoft?

Mono è supportato da Novell che non è proprio uno scricciolo.

Quindi preferisci sottostare al suo gioco.

Ma che vuol dire! Dico che la notizia mi puzza, e che se fossi nei devs di Mono ci andrei con i piedi di piombo.

Mono è supportato da Novell che non è proprio uno scricciolo.

Ma Novell mi pare sia dovuta scendere a compromessi con la Microsoft ;) La tattica Microsoft delle "3 e", embrace, extend and extinguish, e' collaudata... :rolleyes:

Ma che vuol dire! Dico che la notizia mi puzza, e che se fossi nei devs di Mono ci andrei con i piedi di piombo.

Infatti ci vanno coi piedi di piombo... se ne sconsigliassi l'uso per ipotetiche minacce senza fondamenta, allora, come già detto, faresti il loro "ipotetico" gioco.


Ma Novell mi pare sia dovuta scendere a compromessi con la Microsoft ;) La tattica Microsoft delle "3 e", embrace, extend and extinguish, e' collaudata... :rolleyes:
Novell ha fatto un semplice accordo (che menziona anche OpenOffice e Samba tra l'altro) per tutelarsi ulteriormente: stai pur certo che preferisce la propria pelle a quella di Microsoft.

Infatti ci vanno coi piedi di piombo... se ne sconsigliassi l'uso per ipotetiche minacce senza fondamenta, allora, come già detto, faresti il loro "ipotetico" gioco.

Ma mica lo sconsiglio per quello. Se devo usare un linguaggio di programmazione veloce e perfettamente integrato con le API Windows, a questo punto uso C++ e mi prendo il framework Visual C++ o Eclipse.

Se dovessi sconsigliare l'uso di un software per un motivo del genere, dovrei sconsigliare tutto il mondo open source, visti i tempi :D

Novell ha fatto un semplice accordo (che menziona anche OpenOffice e Samba tra l'altro) per tutelarsi ulteriormente: stai pur certo che preferisce la propria pelle a quella di Microsoft.

Sara'.... fatto sta che la Novell parla di un accordo per aumentare l'interoperabilita' di Windows e Linux.... letto qui:

http://www.novell.com/linux/microsoft/community_open_letter.html

Ho i miei forti dubbi che la Microsoft sia intenzionata davvero a rendere Linux piu' accessibile per i prodotti Microsoft. Al massimo sara' il contrario......

Tra l'altro c'e' anche scritto:

Our interest in signing this agreement was to secure interoperability and joint sales agreements, but Microsoft asked that we cooperate on patents as well, and so a patent cooperation agreement was included as a part of the deal. In this agreement, Novell and Microsoft each promise not to sue the other's customers for patent infringement. The intended effect of this agreement was to give our joint customers peace of mind that they have the full support of the other company for their IT activities.

E cosi' la Microsoft sara' libera di infrangere qualsiasi licenza free software della Novell..... ed e' difficile che quelli della Novell infrangeranno davvero qualche licenza Microsoft, vista la politica di Linux e l'ariaccia che tira :mad:

Ma mica lo sconsiglio per quello. Se devo usare un linguaggio di programmazione veloce e perfettamente integrato con le API Windows, a questo punto uso C++ e mi prendo il framework Visual C++ o Eclipse.

Se dovessi sconsigliare l'uso di un software per un motivo del genere, dovrei sconsigliare tutto il mondo open source, visti i tempi :D

Ah ecco, perchè da questo tuo post: http://www.hwupgrade.it/forum/showpost.php?p=19231982&postcount=114 sembrava che dicessi proprio quello.

Il problema del C++ è principalmente quello che è un linguaggio con un design vecchio, è una sorta di "C con qualche toppa per l'OOP" (discorso ancora più valido per l'Objective-C). C# è un linguaggio potente e con un design molto più moderno, sicuro ed agevole.


Sara'.... fatto sta che la Novell parla di un accordo per aumentare l'interoperabilita' di Windows e Linux.... letto qui:

http://www.novell.com/linux/microsoft/community_open_letter.html

Ho i miei forti dubbi che la Microsoft sia intenzionata davvero a rendere Linux piu' accessibile per i prodotti Microsoft. Al massimo sara' il contrario......

E sarebbe cosa buona e giusta, tra l'altro la Microsoft deve farlo se non vuole incorrere in altre sanzioni dell'anti-trust europeo.


Tra l'altro c'e' anche scritto:

Our interest in signing this agreement was to secure interoperability and joint sales agreements, but Microsoft asked that we cooperate on patents as well, and so a patent cooperation agreement was included as a part of the deal. In this agreement, Novell and Microsoft each promise not to sue the other's customers for patent infringement. The intended effect of this agreement was to give our joint customers peace of mind that they have the full support of the other company for their IT activities.

E cosi' la Microsoft sara' libera di infrangere qualsiasi licenza free software della Novell..... ed e' difficile che quelli della Novell infrangeranno davvero qualche licenza Microsoft, vista la politica di Linux e l'ariaccia che tira :mad:
Hai un bel po' di confusione in testa tra "licenza" e "brevetto": sono due cose ben distinte.

Il problema del C++ è principalmente quello che è un linguaggio con un design vecchio, è una sorta di "C con qualche toppa per l'OOP" (discorso ancora più valido per l'Objective-C). C# è un linguaggio potente e con un design molto più moderno, sicuro ed agevole.

Ma e' sempre il solito discorso, semplicita' contro efficienza... ;)

C++ e' ormai datatissimo, e non condivido tra l'altro la politica dei suoi sviluppatori di non definire uno standard preciso, il che ha dato via ad una marea di compilatori che fanno un po' il cacchio che gli pare... :p Pero' se si vuole un software veramente performante si usa il C++.

E sarebbe cosa buona e giusta, tra l'altro la Microsoft deve farlo se non vuole incorrere in altre sanzioni dell'anti-trust europeo.

Ah, si e' parlato anche di interoperabilita' tra sistemi operativi? Buono! Io ero rimasto solo al supporto per il programmi terzi.

Hai un bel po' di confusione in testa tra "licenza" e "brevetto": sono due cose ben distinte.

E vabbe', santa pazienza, ho sbagliato termine! :coffee: Fatto sta che il concetto rimane, se la Microsoft decide di infrangere qualche brevetto Novell, quest'ultima sara' cornuta e mazziata...

Ma e' sempre il solito discorso, semplicita' contro efficienza... ;)

Non c'è solo la semplicità, c'è anche la "potenza" (es. C# può gestire sia codice safe che unsafe) e la sicurezza (es. codice "safe"). Tutto sta nel trovare un buon compromesso a seconda delle esigenze.


C++ e' ormai datatissimo, e non condivido tra l'altro la politica dei suoi sviluppatori di non definire uno standard preciso, il che ha dato via ad una marea di compilatori che fanno un po' il cacchio che gli pare... :p Pero' se si vuole un software veramente performante si usa il C++.

Uno standard è stato definito nel '98 e ce n'è uno più nuovo in fase di discussione.

Comunque se vuoi un software prestazionale ("performante" non esiste), ti interessano solo le prestazioni e *sai programmare bene*, tantovale usare Assembly o al massimo qualcosa come il C (che in alcuni casi è più veloce del C++, che può essere penalizzato in termini di prestazioni da alcune funzionalità relative alla programmazione ad oggetti come il polimorfismo).


Ah, si e' parlato anche di interoperabilita' tra sistemi operativi? Buono! Io ero rimasto solo al supporto per il programmi terzi.

Si, si è parlato anche di interoperabilità.


E vabbe', santa pazienza, ho sbagliato termine! :coffee: Fatto sta che il concetto rimane, se la Microsoft decide di infrangere qualche brevetto Novell, quest'ultima sara' cornuta e mazziata...
Qualche brevetto Novell del tipo? Comunque l'accordo è bilaterale.

Non c'è solo la semplicità, c'è anche la "potenza" (es. C# può gestire sia codice safe che unsafe) e la sicurezza (es. codice "safe"). Tutto sta nel trovare un buon compromesso a seconda delle esigenze.

Mi ricorda un certo discorso sul Python... :D :p

Comunque se vuoi un software prestazionale ("performante" non esiste), ti interessano solo le prestazioni e *sai programmare bene*, tantovale usare Assembly o al massimo qualcosa come il C (che in alcuni casi è più veloce del C++, che può essere penalizzato in termini di prestazioni da alcune funzionalità relative alla programmazione ad oggetti come il polimorfismo).

E vabbe' non esageriamo... :D Finora chi ho visto programmare in C per esplicita scelta era gente che aveva bisogno di altissime performance, per esempio per i software di compressione dati.

Qualche brevetto Novell del tipo? Comunque l'accordo è bilaterale.

Del tipo tecnologie Novell? :-P Se fai un giretto per il sito della Novell ne trovi di soluzioni sotto brevetto. Dai, e' chiaro come il sole che la Microsoft ha ottenuto l'appoggio di Novell sotto ricatto, ed il fatto che la Microsoft abbia promesso che non intentera' causa alla Novell e' ridicolo... basta che la Novell faccia di nuovo innervosire la Microsoft perche' quell'accordo possa essere ridiscusso. Bisogna vedere come hanno sottoscritto quell'accordo, ma mi pare strano che possa avere una effettiva validita' giuridica. E' come se io sottoscrivessi con te un patto per cui se vieni a casa mia e mi rompi tutto con una mazza da baseball prometto di non denunciarti, e viceversa..... :mbe: :fagiano:

PS: a proposito di quel bellissimo linguaggio che e' il Python :D guarda un po' che ti ho trovato:

http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressiveness

Python, "espressivita'" piu' alta (in buona compagnia con Perl e Smaltalk). Posso facilmente affermare che potenza espressiva piu' alta = maggiore leggibilita' :-P

Mi ricorda un certo discorso sul Python... :D :p
Python può gestire puntatori espliciti alla memoria?


E vabbe' non esageriamo... :D Finora chi ho visto programmare in C per esplicita scelta era gente che aveva bisogno di altissime performance, per esempio per i software di compressione dati.

Non necessariamente... io ad esempio se non ho progetti troppo vasti uso tranquillamente il C perchè non avrebbe senso scomodare bestie come Mono o la JVM, anche se le prestazioni avrebbero un'importanza relativa.


Del tipo tecnologie Novell? :-P Se fai un giretto per il sito della Novell ne trovi di soluzioni sotto brevetto. Dai, e' chiaro come il sole che la Microsoft ha ottenuto l'appoggio di Novell sotto ricatto, ed il fatto che la Microsoft abbia promesso che non intentera' causa alla Novell e' ridicolo... basta che la Novell faccia di nuovo innervosire la Microsoft perche' quell'accordo possa essere ridiscusso. Bisogna vedere come hanno sottoscritto quell'accordo, ma mi pare strano che possa avere una effettiva validita' giuridica. E' come se io sottoscrivessi con te un patto per cui se vieni a casa mia e mi rompi tutto con una mazza da baseball prometto di non denunciarti, e viceversa..... :mbe: :fagiano:
Tecnologie Novell del tipo? :D Sinceramente non vedo Microsoft interessata a tutte queste tecnologie Novell, anzi è probabile che sia più Novell interessata a quelle Microsoft (anche per motivi di interoperabilità con i propri prodotti).

Python può gestire puntatori espliciti alla memoria?

E se ti dicessi di si? :-P

http://docs.python.org/lib/ctypes-pointers.html

Toh, se vuoi puoi anche fare static typing, che vuoi di piu'? ^____^

Tecnologie Novell del tipo? :D

Ah la pigrizia.... :D Cerca su Google e ti sara' dato!

http://www.novell.com/company/policies/patent/european.html

E' da un bel po' che la Novell sta cercando di far approvare i suoi brevetti... pensa la beffa se finalmente venissero approvati e la Microsoft gli frega la tecnologia senza neanche poter far niente! :muro: Mah! :boh:


Sinceramente non vedo Microsoft interessata a tutte queste tecnologie Novell, anzi è probabile che sia più Novell interessata a quelle Microsoft (anche per motivi di interoperabilità con i propri prodotti).

Che sono chiuse e non vedo come potrebbe facilmente fregargliele...... giusto .NET e' stato rilasciato open source, ed ora la Microsoft ha rilasciato due licenze OSI, ma dubito fortemente si lascera' fregare codice sotto brevetto. Saranno str***i, ma mica scemi! ^______^

E se ti dicessi di si? :-P

http://docs.python.org/lib/ctypes-pointers.html

Con una "libreria esterna" (ctypes) certamente si (altrimenti non potrebbero esistere neppure binding per alcune librerie in C, C++ etc. vedi i già citati wxWidgets), ma non esiste nel costrutto del linguaggio. Tra l'altro c'è anche qualche limitazione.


Toh, se vuoi puoi anche fare static typing, che vuoi di piu'? ^____^

Si... con quella libreria e *comunque* allocando memoria dinamicamente ;)


Ah la pigrizia.... :D Cerca su Google e ti sara' dato!

http://www.novell.com/company/policies/patent/european.html

Questo è noto... la mia questione era diversa, se fossero brevetti così importanti quantomeno sarebbero abbastanza noti e magari me ne avresti saputo dire qualcuno "a memoria". Il punto è che, come già detto, non vedo tutta questa corsa ai brevetti Novell (mentre la vedo per brevetti Microsoft).


E' da un bel po' che la Novell sta cercando di far approvare i suoi brevetti... pensa la beffa se finalmente venissero approvati e la Microsoft gli frega la tecnologia senza neanche poter far niente! :muro: Mah! :boh:

Ma guarda che non c'è nulla da "fregare", è un accordo bilaterale.


Che sono chiuse e non vedo come potrebbe facilmente fregargliele...... giusto .NET e' stato rilasciato open source, ed ora la Microsoft ha rilasciato due licenze OSI, ma dubito fortemente si lascera' fregare codice sotto brevetto. Saranno str***i, ma mica scemi! ^______^
Continui a confondere "licenza" con "brevetto", un brevetto non è un pezzo di codice, è un'idea, un sistema. Infatti se guardi il testo dei brevetti è presente una descrizione dell'idea e sui meccanismi che prevede, non ci sono listati di codice C.

Con una "libreria esterna" (ctypes) certamente si (altrimenti non potrebbero esistere neppure binding per alcune librerie in C, C++ etc. vedi i già citati wxWidgets), ma non esiste nel costrutto del linguaggio. Tra l'altro c'è anche qualche limitazione.

Si... con quella libreria e *comunque* allocando memoria dinamicamente ;)

Eh, mica si puo' voler tutto dalla vita... Python non e' perfetto (ancora! :D)


Il punto è che, come già detto, non vedo tutta questa corsa ai brevetti Novell (mentre la vedo per brevetti Microsoft).

Ma per "corsa ai brevetti" intendi che la Microsoft spinge di piu' a brevettare le sue soluzioni, o che la gente vuole fregare le idee alla Microsoft? Se e' la seconda e ti riferisci alle dichiarazioni di Ballmer, direi che quelle sono ca**ate... :p Se e' la prima, la storia e' piena di grandi aziende che fregano idee a singoli o piccole imprese. CHe non si conoscano le soluzioni Novell non vuol dire che siano soluzioni scarse. Del resto neanch'io fino a poco tempo fa conoscevo il CP/M........... :rolleyes:

Ma guarda che non c'è nulla da "fregare", è un accordo bilaterale.

Si, bilaterale nel senso che la Novell se la prende in quel posto sia da destra che da sinistra...... :D per la par condicio!

Continui a confondere "licenza" con "brevetto", un brevetto non è un pezzo di codice, è un'idea, un sistema. Infatti se guardi il testo dei brevetti è presente una descrizione dell'idea e sui meccanismi che prevede, non ci sono listati di codice C.

Ma un po' di elacistita' mentale, dio santo.... l'idea in qualche modo si deve applicare, no? Oppure sono idee astratte che campano di vita propria? E che cribbio, che cavolo di discorsi capziosi.

C'e' un solo modo per violare un brevetto Microsoft, e cioe' scrivere del codice sorgente ex novo che applica quell'idea. E dato che si parla di open source, la prima cosa che si evita e' proprio fare questo.

Per fare un esempio molto terra terra e piccolino, ma che conosco bene, gli sviluppatori di Miranda non hanno implementato la gestione delle faccine come su MSN (o Windows Live Messenger). Su MSN se mi viene inviato un codice che identifica una emoticon e io non ho un'immagine associata a quella emoticon, scarico automaticamente l'immagine e questa mi viene visualizzata al posto del codice.
Bene, tale concetto e' sotto brevetto Microsoft. Sembra una minch**ta ma e' cosi'. E gli sviluppatori di Miranda si tengono bene alla larga dallo sviluppare una soluzione anche minimamente simile. Puoi immaginarti gli sviluppatori delle distro Linux.
Ballmer non ha chiesto a Novell, al mondo Linux o al mondo free - open source di smettere di violare licenze Microsoft. Ballmer sta minacciando cause legali, che comunque la Microsoft puo' ampiamente permettersi anche se le accuse fossero infondate, mentre le aziende "avvertite" no. Altrimenti avrebbe gia' detto da tempo dove vengono violati i brevetti, come gli e' stato chiesto, in modo da rimuovere il software o codice interessato.
Quindi e' ampiamente improbabile che la Novell si fosse mai avventurata o si avventuri in futuro a copiare soluzioni Microsoft, mentre e' abbastanza probabile che se la Novell facesse qualcosa di innovativo la Microsoft puo' sfruttare l'idea senza problemi.

Tra l'altro, vorrei dire due parole sui brevetti.... secondo me non hanno senso, almeno come sono strutturati adesso. Che significa brevettare un sistema di trasferimento di immagini? E se un giorno mi venisse il ghiribizzo di brevettare un passo di danza? Oppure una formula matematica?
Magari sono un sindaco di una citta', trovo un metodo per contrastare la mafia efficace e che faccio? Lo brevetto! Fantastico. Oppure trovo un metodo di trasporto economico ed ecologico, e lo brevetto per i prossimi 20 anni, facendolo pagare un'iradiddio. 20 anni di tecnologia bloccata.

A mio modestissimo parere, il costo dei brevetti dovrebbe essere rivisto, cosi' come il costo delle royalties. Se si fissasse un costo basso per un brevetto, ma nel contempo si fissasse anche un tetto massimo di royalties a seconda di vari casi, ci sarebbe piu' tutela del patrimonio intellettuale, meno furti di idee e piu' guadagno per i piccoli "inventori". Inoltre un brevetto dovrebbe durare molto meno, altrimenti una grande azienda potrebbe mettersi a brevettare tutto quello che ai suoi dipendenti gli passa per la testa e godersene i diritti per i prossimi 40 anni... cosa che non e' pensabile, soprattutto per il ritmo di avanzamento tecnologico attuale. Inoltre potrbbero essere riconosciuti brevetti a vita e a costo minimo una tantum per chi non richiede alcuna royalty, come per il caso del free software.

A proposito, guardate qui cosa scrive ilsensine.....

http://www.hwupgrade.it/forum/showpost.php?p=19263112&postcount=363

Per farla breve, Red Hat e Novell sono state denunciate per furto di brevetto da tale societa' IP Innovation LLC, che e' consociata della Acacia, che pare sia nientepopodimeno finanziata dalla Microsoft!

Fatta la legge, trovato l'inganno. La Microsoft fa causa non direttamente alla Novell, ma attraverso un gioco di scatole cinesi da fare invidia a Mediaset :D E Novell e' cornuta e mazziata. Mi dispiace quasi dire ve l'avevo detto..........
............
ma........


:winner: :sofico: :yeah: :ave: VE L'AVEVO DETTO!!!!!!! :ave: :yeah: :sofico: :winner:

Ma per "corsa ai brevetti" intendi che la Microsoft spinge di piu' a brevettare le sue soluzioni, o che la gente vuole fregare le idee alla Microsoft? Se e' la seconda e ti riferisci alle dichiarazioni di Ballmer, direi che quelle sono ca**ate... :p Se e' la prima, la storia e' piena di grandi aziende che fregano idee a singoli o piccole imprese. CHe non si conoscano le soluzioni Novell non vuol dire che siano soluzioni scarse. Del resto neanch'io fino a poco tempo fa conoscevo il CP/M........... :rolleyes:

La seconda... e direi che non sono molto "ca**ate" se anche l'Unione Europea cerca in qualche modo di "aggirare" il problema con l'antitrust ed il discorso sull'interoperabilità. Es. il formato dei documenti .DOC (non so se sia brevettato o meno qualcosa a riguardo ma comunque è solo un esempio) che è un formato Microsoft e sta caro a tutte le suite concorrenti per poter essere compatibili con Microsoft Office. C'è pieno zeppo di gente interessata alle tecnologie Microsoft... mentre non mi sembra, come già detto, che Microsoft si strappi i capelli per chissà quali tecnologie Novell.


Si, bilaterale nel senso che la Novell se la prende in quel posto sia da destra che da sinistra...... :D per la par condicio!

No... nel senso che il "permesso di violazione" è reciproco ;)


Ma un po' di elacistita' mentale, dio santo.... l'idea in qualche modo si deve applicare, no? Oppure sono idee astratte che campano di vita propria? E che cribbio, che cavolo di discorsi capziosi.

L'applicazione puoi farla anche senza codice sorgente, basta copiare "l'idea".


C'e' un solo modo per violare un brevetto Microsoft, e cioe' scrivere del codice sorgente ex novo che applica quell'idea. E dato che si parla di open source, la prima cosa che si evita e' proprio fare questo.

Grosso modo possiamo dire di si.


Per fare un esempio molto terra terra e piccolino, ma che conosco bene, gli sviluppatori di Miranda non hanno implementato la gestione delle faccine come su MSN (o Windows Live Messenger). Su MSN se mi viene inviato un codice che identifica una emoticon e io non ho un'immagine associata a quella emoticon, scarico automaticamente l'immagine e questa mi viene visualizzata al posto del codice.
Bene, tale concetto e' sotto brevetto Microsoft. Sembra una minch**ta ma e' cosi'. E gli sviluppatori di Miranda si tengono bene alla larga dallo sviluppare una soluzione anche minimamente simile. Puoi immaginarti gli sviluppatori delle distro Linux.

Gaim che utilizzo quotidianamente ha questa funzione. Comunque anche dando per buono l'esempio... dov'è il problema?


Ballmer non ha chiesto a Novell, al mondo Linux o al mondo free - open source di smettere di violare licenze Microsoft. Ballmer sta minacciando cause legali, che comunque la Microsoft puo' ampiamente permettersi anche se le accuse fossero infondate, mentre le aziende "avvertite" no. Altrimenti avrebbe gia' detto da tempo dove vengono violati i brevetti, come gli e' stato chiesto, in modo da rimuovere il software o codice interessato.

Quindi?


Quindi e' ampiamente improbabile che la Novell si fosse mai avventurata o si avventuri in futuro a copiare soluzioni Microsoft, mentre e' abbastanza probabile che se la Novell facesse qualcosa di innovativo la Microsoft puo' sfruttare l'idea senza problemi.

La cosa è, come già detto, completamente reciproca.

A proposito, guardate qui cosa scrive ilsensine.....

http://www.hwupgrade.it/forum/showpost.php?p=19263112&postcount=363

Per farla breve, Red Hat e Novell sono state denunciate per furto di brevetto da tale societa' IP Innovation LLC, che e' consociata della Acacia, che pare sia nientepopodimeno finanziata dalla Microsoft!

Fatta la legge, trovato l'inganno. La Microsoft fa causa non direttamente alla Novell, ma attraverso un gioco di scatole cinesi da fare invidia a Mediaset :D E Novell e' cornuta e mazziata. Mi dispiace quasi dire ve l'avevo detto..........
............
ma........


:winner: :sofico: :yeah: :ave: VE L'AVEVO DETTO!!!!!!! :ave: :yeah: :sofico: :winner:

Ne ero perfettamente a conoscenza ma...

1) E' tutto da provare.

2) Novell potrebbe benissimo fare lo stesso con qualche società "satellite".

Come già detto, è tutto reciproco.

Eheh si certo..... la Novell si potra' sicuramente permettere di creare un'azienda fittizia per citare la Microsoft. E bada bene, non potra' neanche una controdenuncia, ma dovrebbe proprio denunciarla direttamente. Quanto al "è tutto da dimostrare" mi immaginavo una risposta del genere... :rolleyes:

Eheh si certo..... la Novell si potra' sicuramente permettere di creare un'azienda fittizia per citare la Microsoft.

Guarda che Novell non è mica Alitalia :D


E bada bene, non potra' neanche una controdenuncia, ma dovrebbe proprio denunciarla direttamente.

Ehhh? :confused:


Quanto al "è tutto da dimostrare" mi immaginavo una risposta del genere... :rolleyes:
E facevi bene ad immaginartela ;)

secondo me la cosa migliore sarebbe: linguaggio interpretato / compilato dinamicamente per il programmatore, eseguibile per l'utente. Esistono compilatori statici per il Python [...]

Rispolvero il thread per correggere questa mia affermazione: in realta' non esistono compilatori per Python. La mia memoria faceva cilecca. Esiste invece un linguaggio praticamente identico al Python il quale permette la compilazione statica, costringendo ad usare lo strong typing del C. Il linguaggio si chiama Cython: http://www.cython.org/ (http://www.cython.org/)

Facevi meglio a non rispolverarla allora, visto che Cython non è un linguaggio vero e proprio, ma un tool (dotato di un suo linguaggio, molto simile a Python), per scrivere estensioni PER Python.

Comunque di compilatori per Python che tirano fuori codice nativo (quindi direttamente eseguibile), ce ne sono. Basta informarsi, ovviamente.

Ma niente affatto. Cython e' un linguaggio di programmazione. Il fatto che si installi sopra Python non c'entra niente. E' anche scritto nel suo sito: Cython (http://www.cython.org/) is a language that makes writing C extensions for the Python language as easy as Python itself.

Non so cosa intendano esattamente con "makes writing C extensions for the Python language". Sembrerebbe che sia come dici tu, ma non e' cosi'. Cython permette di scrivere programmi in un linguaggio praticamente identico a Python, ma che possono essere compilati. Come scrivono i creatori stessi, "Cython is Python with C data types" (http://docs.cython.org/docs/tutorial.html#the-basics-of-cython (http://docs.cython.org/docs/tutorial.html#the-basics-of-cython))

Ma niente affatto. Cython e' un linguaggio di programmazione. Il fatto che si installi sopra Python non c'entra niente. E' anche scritto nel suo sito: Cython (http://www.cython.org/) is a language that makes writing C extensions for the Python language as easy as Python itself.
Bene. Allora prova a compilare qualcosa con questo linguaggio e a farlo girare. Senza CPython, ovviamente.
Non so cosa intendano esattamente con "makes writing C extensions for the Python language". Sembrerebbe che sia come dici tu, ma non e' cosi'. Cython permette di scrivere programmi in un linguaggio praticamente identico a Python, ma che possono essere compilati. Come scrivono i creatori stessi, "Cython is Python with C data types" (http://docs.cython.org/docs/tutorial.html#the-basics-of-cython (http://docs.cython.org/docs/tutorial.html#the-basics-of-cython))
Non sai cosa intendono con quella frase semplicemente perché non sai cos'è e come funziona Cython.

Prendi pure il link che hai postato e fammi vedere come fai a realizzare anche un banalissimo "Hello, world!" con Cython SENZA ricorrere a CPython.

Se non ci riesci ammetti pubblicamente di aver preso una cantonata e non avere idea di cosa hai riportato.

Ma niente affatto. Cython e' un linguaggio di programmazione. Il fatto che si installi sopra Python non c'entra niente.

Anche il C senza compilatore non si puo' compilare. Non e' un linguaggio di programmazione? ;)

Peccato che CPython NON sia nemmeno un compilatore...

Grazie tante. Infatti normalmente uno usa CPython per interpretare codice sorgente scritto in Python. E Python e' un linguaggio di programmazione. Anche a Cython serve il CPython, oltre alle proprie librerie e ad un compilatore C, ed e' un linguaggio di programmazione. Vorresti dire che i loro stessi autori hanno sbagliato a descriverlo? O forse ti riferisci al fatto che non genera eseguibili ma librerie?

Grazie tante. Infatti normalmente uno usa CPython per interpretare codice sorgente scritto in Python. E Python e' un linguaggio di programmazione.
Ti sei risposto da solo.
Anche a Cython serve il CPython, oltre alle proprie librerie e ad un compilatore C, ed e' un linguaggio di programmazione.
Appunto: gli serve un compilatore, ed è quello C. NON gli serve il compilatore Python che è integrato in CPython.
Vorresti dire che i loro stessi autori hanno sbagliato a descriverlo?
Gli autori hanno descritto perfettamente la situazione, che NON è quella che pretendi di far passare. La conseguenza logica che vorresti applicare manca del tutto di una base su cui poggiare.
O forse ti riferisci al fatto che non genera eseguibili ma librerie?
Mi riferisco al fatto che quando compili un sorgente con Cython, viene generata una libreria. Libreria che viene poi agganciata da CPython esattamente come qualunque altra libreria di sistema e non.

Processo, quest'ultimo, che viene normalmente realizzato con qualunque altra applicazione. E non mi pare che una normale applicazione si possa configurare come compilatore e/o linguaggio di programmazione.

Semplicemente, ed è bene che te ne faccia una ragione, con Cython vengono realizzate delle ESTENSIONI al core di CPython. Ma l'UNICA fase di compilazione avviene quando con Cython compili i sorgenti scritti con questo linguaggio. CPython NON viene usato da Cython come compilatore, ma semplicemente come "usufruttuario" del lavoro che ha svolto quest'ultimo.

Detto in altri termini, è simile a ciò che si verifica con le ESTENSIONI di FireFox o di Opera.

E' perfettamente inutile che continui a girarci attorno cercando appigli inesistenti. Cython lo conosco abbastanza bene, e CPython lo conosco di gran lunga meglio di quanto non lo conosca tu, visto che guarda caso da qualche mese sto lavorando proprio su queste parti.

Adesso se sei in grado di prendere un sorgente Cython, compilarlo e farlo funzionare SENZA usare CPython, avrai dimostrato di aver ragione e che io ho torto. Altrimenti evita di continuare un discorso che non ti porterà a nulla, e ammetti di aver preso una cantonata.

Sbagliare è umano. Perseverare è diabolico.

Allora, cerchiamo un attimo di fare chiarezza: non sto mica dicendo che si possono fare eseguibili con Cython, ok? Ma cio' non cambia il fatto che e' un linguaggio di programmazione, con un proprio tool per creare le estensioni. Se fosse solo un tool e basta il codice sorgente avrebbe una sintassi identica al Python o a un altro linguaggio di programmazione, o no? Il fatto che possa creare solo estensioni per CPython non ne toglie la qulifica di linguaggio di programmazione.

Comunque, sapresti dirmi di piu' riguardo a compilatori statici per Python? Io ho sentito solo parlare di Starkiller (http://web.mit.edu/msalib/www/urop/), il cui progetto pare non sia mai decollato.

Allora, cerchiamo un attimo di fare chiarezza: non sto mica dicendo che si possono fare eseguibili con Cython, ok? Ma cio' non cambia il fatto che e' un linguaggio di programmazione, con un proprio tool per creare le estensioni. Se fosse solo un tool e basta il codice sorgente avrebbe una sintassi identica al Python o a un altro linguaggio di programmazione, o no? Il fatto che possa creare solo estensioni per CPython non ne toglie la qulifica di linguaggio di programmazione.
No, ma rimane un tool PER CPython, come avevo già scritto prima. Non vive di vita propria. Se ti ho risposto è soltanto perché avevi uppato il thread scrivendo questo:

Rispolvero il thread per correggere questa mia affermazione: in realta' non esistono compilatori per Python. La mia memoria faceva cilecca. Esiste invece un linguaggio praticamente identico al Python il quale permette la compilazione statica, costringendo ad usare lo strong typing del C. Il linguaggio si chiama Cython: http://www.cython.org/

Il che, ribadisco, NON è vero. Cython NON permette la compilazione statica, se non legandolo a CPython, appunto, ma rimane sempre a livello di estensione. E se un'estensione NON la carichi (richiamandola tramite l'import di qualche modulo), il tuo codice compilato con Cython non verrà MAI eseguito.

In soldoni: sei SEMPRE obbligato a passare da CPython.
Comunque, sapresti dirmi di piu' riguardo a compilatori statici per Python? Io ho sentito solo parlare di Starkiller (http://web.mit.edu/msalib/www/urop/), il cui progetto pare non sia mai decollato.
Starkiller non è un compilatore statico. E' un progetto nato per analizzare il codice Python cercando di individuare gli elementi statici, in modo da permettere un'EVENTUALE scrittura di compilatori che generino codice nativo e, quindi, più efficiente.

Ma non è un compilatore, appunto. E' un tool di analisi.

Compilatori statici per Python esistono, e uno di questi è PyPy, che attualmente è in grado di tirare fuori eseguibili per PowerPC.

In ogni caso per sua natura Python è un linguaggio dinamico, e non è possibile prendere un qualunque sorgente e compilarlo interamente (e staticamente) in un eseguibile nativo per una qualunque architettura. Può succedere per casi particolari, e piccole porzioni di codice. Ma la norma rimane la sua intriseca dinamicità.

Tra l'altro ho già fatto degli studi simili a quelli del tizio di StarKiller proprio in ottica di migliorare l'efficienza di CPython. Gli darò un'occhiata per vedere a quali risultati è arrivato per vedere se collima con le mie idee o può aiutarmi per i progetti che ho in mente.

Vabbe', lasciamo perdere il discorso su Cython senno' non ne veniamo fuori. Non che io sia d'accordo comunque.

Starkiller immaginavo dovesse fare quello che riporti, che alla fine e' piu' o meno quello che fa il tool di Cython: tradurre il linguaggio in C. Starkiller avrebbe avuto l'indubbio vantaggio di non dover usare un linguaggio diverso come quello di Cython (che e' abbastanza confusionario rispetto al Python) e di produrre eseguibili invece di file oggetto. Per questo mi chiedevo se esistesse da qualche parte il codice del progetto, o se fosse morto prima di nascere.

Pypy ovviamente lo conosco, ne ho anche discusso in precedenza in questo stesso thread. Comunque a parte il PowerPC, a quanto mi dici tu, per il resto delle piattaforme usa un JIT. E poi se devo dire Pypy si puo' ancora installare solo su Python 2.5.

Comunque in teoria qualsiasi linguaggio puo' essere compilato staticamente e dinamicamente. Il fatto che Python sia nato come linguaggio dinamico rende la compilazione statica semplicemente di gran lunga piu' difficile, mica impossibile.

Vabbe', lasciamo perdere il discorso su Cython senno' non ne veniamo fuori. Non che io sia d'accordo comunque.
Se non sei d'accordo esponi le tue motivazioni TECNICHE a supporto della tua tesi, e smonta pure le mie.
Starkiller immaginavo dovesse fare quello che riporti, che alla fine e' piu' o meno quello che fa il tool di Cython: tradurre il linguaggio in C. Starkiller avrebbe avuto l'indubbio vantaggio di non dover usare un linguaggio diverso come quello di Cython (che e' abbastanza confusionario rispetto al Python) e di produrre eseguibili invece di file oggetto. Per questo mi chiedevo se esistesse da qualche parte il codice del progetto, o se fosse morto prima di nascere.
Non lo so, comunque non serve a quello che credevi.

In ogni caso per chi conosce C e Python, Cython è tutt'altro che confusionario. Anzi, è estremamente comodo e strutturato ottimamente, tanto che nella comunità Python si sta pensando di adottarlo in pianta stabile se si trova qualcuno in grado di farsi carico della sua manutenzione.
Pypy ovviamente lo conosco, ne ho anche discusso in precedenza in questo stesso thread. Comunque a parte il PowerPC, a quanto mi dici tu, per il resto delle piattaforme usa un JIT. E poi se devo dire Pypy si puo' ancora installare solo su Python 2.5.
Questo perché è un progetto ancora giovane. Non puoi pretendere che già adesso copra tutte le architetture esistenti e tutte le versioni di Python.
Comunque in teoria qualsiasi linguaggio puo' essere compilato staticamente e dinamicamente. Il fatto che Python sia nato come linguaggio dinamico rende la compilazione statica semplicemente di gran lunga piu' difficile, mica impossibile.
Esattamente.

Non lo so, comunque [Starkiller] non serve a quello che credevi.
? E allora a che serve?

In ogni caso per chi conosce C e Python, Cython è tutt'altro che confusionario. Anzi, è estremamente comodo e strutturato ottimamente, tanto che nella comunità Python si sta pensando di adottarlo in pianta stabile se si trova qualcuno in grado di farsi carico della sua manutenzione.
Aspetta, non sto dicendo che non sia semplice da utilizzare. Basta conoscere anche due cose di C, e vorrei vedere un programmatore che non lo conosce. Pero' e' un casino per quanto riguarda la sintassi, e' Python con la dichiarazione di variabili, "classi" e funzioni alla C.
Python e' un linguaggio che adoro proprio perche' ha una sintassi semplice e pulita, che tra l'altro ti costringe a scrivere codice leggibile. Il Cython potrebbe essere decisamente piu' leggibile.

Qualche esempio:
perche' bisogna usare per forza cdef prima della dichiarazione esplicita dei tipi? Che bisogno c'e'?
per lo stesso motivo, perche' va usato cdef invece di def se si dichiara una funzione C? Basterebbe scrivere, ad esempio:
def int myFunc(long a) :
...
la sintassi del for e' terribile. Era molto piu' semplice una roba tipo "for i [from a] to b [step c]"


Questo perché [PyPy] è un progetto ancora giovane. Non puoi pretendere che già adesso copra tutte le architetture esistenti e tutte le versioni di Python.
Vabbe', ma almeno la 2.6 potrebbe supportarla :p

Se non sei d'accordo esponi le tue motivazioni TECNICHE a supporto della tua tesi [su Cython], e smonta pure le mie.
Ma accidenti, io non ho alcuna tesi e non ho bisogno di dimostrare proprio niente. Senti (o leggi), io ho riportato quello che c'e' scritto sul sito, e cioe' che Cython e' un linguaggio di programmazione. Parla con quelli che mantengono il sito di Cython.

? E allora a che serve?
Te l'ho spiegato qualche messaggio fa.
Aspetta, non sto dicendo che non sia semplice da utilizzare. Basta conoscere anche due cose di C, e vorrei vedere un programmatore che non lo conosce. Pero' e' un casino per quanto riguarda la sintassi, e' Python con la dichiarazione di variabili, "classi" e funzioni alla C.
Python e' un linguaggio che adoro proprio perche' ha una sintassi semplice e pulita, che tra l'altro ti costringe a scrivere codice leggibile. Il Cython potrebbe essere decisamente piu' leggibile.
Bisogna vedere a che prezzo.
Qualche esempio:
perche' bisogna usare per forza cdef prima della dichiarazione esplicita dei tipi? Che bisogno c'e'?
per lo stesso motivo, perche' va usato cdef invece di def se si dichiara una funzione C? Basterebbe scrivere, ad esempio:
def int myFunc(long a) :
...
Perché cdef e def sono due costrutti sintattici diversi. Il primo è proprio di Cython, il secondo di Python.

E hanno fatto benissimo a separarli proprio per una questione di leggibilità: si vede a occhio, scorrendo il sorgente di un file Cython, quali parti sono proprie di quest'ultimo (e quindi compilate con tutti gli annessi e connessi) e quali sono di Python.
la sintassi del for e' terribile. Era molto piu' semplice una roba tipo "for i [from a] to b [step c]"
Bisogna sempre avere presente il perché Cython è nato. Questo, come per il cdef, è un compromesso utile allo scopo.
Vabbe', ma almeno la 2.6 potrebbe supportarla :p
Nemmeno apache (http://mirror.soluzionisis.com/apache/httpd/modpython/win/3.3.1/) supporta Python 2.6 e ti lamenti che un microscopico progetto come PyPy lo faccia? :p
Ma accidenti, io non ho alcuna tesi e non ho bisogno di dimostrare proprio niente. Senti (o leggi), io ho riportato quello che c'e' scritto sul sito, e cioe' che Cython e' un linguaggio di programmazione. Parla con quelli che mantengono il sito di Cython.
E io continuo ad aspettare che tu mi faccia vedere come far girare un banalissimo "Hello, world!" in Cython SENZA ricorrere a CPython. :read:

Scusa il ritardo.

cdef e def sono due costrutti sintattici diversi. Il primo è proprio di Cython, il secondo di Python. E hanno fatto benissimo a separarli proprio per una questione di leggibilità: si vede a occhio, scorrendo il sorgente di un file Cython, quali parti sono proprie di quest'ultimo (e quindi compilate con tutti gli annessi e connessi) e quali sono di Python.
Punto primo: a cosa serve sapere quali sono le parti che potrebbe capire solo il parser Cython e quali invece puo' capire anche un interprete Python? Secondo: se fosse per una quesione di leggibilita' (e non vedo come sia piu' leggibile), Cython avrebbe dovuto usare un altro comando per il suo for, ad esempio 'cfor'.

Bisogna sempre avere presente il perché Cython è nato. Questo, come per il cdef, è un compromesso utile allo scopo.
Ma compromesso tra cosa, scusa? E' una sintassi che non appartiene ne' al C ne' a Python, e che e' molto meno leggibile di quella del secondo linguaggio.

Nemmeno apache (http://mirror.soluzionisis.com/apache/httpd/modpython/win/3.3.1/) supporta Python 2.6 e ti lamenti che un microscopico progetto come PyPy lo faccia? :p
Veramente quello e' mod_python per Windows. La versione Linux supporta anche Python 2.6, e sospetto anche Python 3:
http://mirror.soluzionisis.com/apache/httpd/modpython/
Comunque sia e' vero che PyPy ha molto meno sviluppatori di Apache e che ha una mole di codice scritto proprio in Python - anzi, in RPython - decisamente enorme.

E io continuo ad aspettare che tu mi faccia vedere come far girare un banalissimo "Hello, world!" in Cython SENZA ricorrere a CPython. :read:
Benissimo. Secondo te allora Cython non puo' essere definito un linguaggio di programmazione perche' deve essere eseguito da un interprete Python? A costo di essere pedante, cito la definizione di "Linguaggio di programmazione" da Wikipedia:

--------------------------------------------------------------------------
In informatica, un linguaggio di programmazione è un linguaggio formale, dotato di una sintassi e di una semantica ben definite, utilizzabile per il controllo del comportamento di una macchina formale, o di una implementazione di essa (tipicamente, un computer).
[...]
Il codice sorgente, contenente le istruzioni da eseguire e (spesso) alcuni dati noti e costanti, può essere poi eseguito passandolo ad un interprete che eseguirà le istruzioni in esso contenute, il che è la prassi normale per i linguaggi di scripting; oppure può venire compilato, cioè tradotto in istruzioni di linguaggio macchina da un programma compilatore
--------------------------------------------------------------------------

http://it.wikipedia.org/wiki/Linguaggio_di_programmazione

Vorrei quindi sapere perche' non consideri Cython un linguaggio di programmazione.

Scusa il ritardo.
Non c'è problema. Rispondi pure quando puoi.
Punto primo: a cosa serve sapere quali sono le parti che potrebbe capire solo il parser Cython e quali invece puo' capire anche un interprete Python? Secondo: se fosse per una quesione di leggibilita' (e non vedo come sia piu' leggibile), Cython avrebbe dovuto usare un altro comando per il suo for, ad esempio 'cfor'.
La spiegazione dettagliata che risponde a entrambe le domande la fornisce la documentazione di Cython, che riporto:
Python functions are defined using the def statement, as in Python. They take Python objects as parameters and return Python objects.

C functions are defined using the new cdef statement. They take either Python objects or C values as parameters, and can return either Python objects or C values.

Within a Cython module, Python functions and C functions can call each other freely, but only Python functions can be called from outside the module by interpreted Python code. So, any functions that you want to “export” from your Cython module must be declared as Python functions using def. There is also a hybrid function, called cpdef. A cpdef can be called from anywhere, but uses the faster C calling conventions when being called from other Cython code.
Ma compromesso tra cosa, scusa? E' una sintassi che non appartiene ne' al C ne' a Python, e che e' molto meno leggibile di quella del secondo linguaggio.
Cython riconosce la sintassi del for di Python, e se utilizza enventuali estensioni proprie di Cython provvede a generare codice C.

Il for di cui parli a quanto pare è un retaggio del passato, per compatibilità col codice scritto con Pyrex, di cui Cython è un derivato (o successore, visto che ormai l'ha praticamente soppiantato):
Cython recognises the usual Python for-in-range integer loop pattern:
for i in range(n):
...

If i is declared as a cdef integer type, it will optimise this into a pure C loop. This restriction is required as otherwise the generated code wouldn’t be correct due to potential integer overflows on the target architecture. If you are worried that the loop is not being converted correctly, use the annotate feature of the cython commandline (-a) to easily see the generated C code. See Automatic range conversion

For backwards compatibility to Pyrex, Cython also supports another form of for-loop:
for i from 0 <= i < n:
...

or:
for i from 0 <= i < n by s:
...

where s is some integer step size.
Veramente quello e' mod_python per Windows. La versione Linux supporta anche Python 2.6, e sospetto anche Python 3:
http://mirror.soluzionisis.com/apache/httpd/modpython/
Difatti mod_python non è stato portato pienamente alla versione 2.6. Io, su Windows, non posso utilizzarlo.
Benissimo. Secondo te allora Cython non puo' essere definito un linguaggio di programmazione perche' deve essere eseguito da un interprete Python? A costo di essere pedante, cito la definizione di "Linguaggio di programmazione" da Wikipedia:

--------------------------------------------------------------------------
In informatica, un linguaggio di programmazione è un linguaggio formale, dotato di una sintassi e di una semantica ben definite, utilizzabile per il controllo del comportamento di una macchina formale, o di una implementazione di essa (tipicamente, un computer).
[...]
Il codice sorgente, contenente le istruzioni da eseguire e (spesso) alcuni dati noti e costanti, può essere poi eseguito passandolo ad un interprete che eseguirà le istruzioni in esso contenute, il che è la prassi normale per i linguaggi di scripting; oppure può venire compilato, cioè tradotto in istruzioni di linguaggio macchina da un programma compilatore
--------------------------------------------------------------------------

http://it.wikipedia.org/wiki/Linguaggio_di_programmazione

Vorrei quindi sapere perche' non consideri Cython un linguaggio di programmazione.
Semplice: CPython NON è un interprete per il codice prodotto da Cython. CPython interpreta il codice prodotto da... se stesso (o eventualmente compilato da applicazione come PyPy, che possono produrre bytecode). Il codice prodotto da Cython è utilizzabile all'interno di CPython esclusivamente come estensione, quindi caricando l'opportuno modulo e utilizzando le funzioni esportate da Cython.

Come avevo già detto prima.

La spiegazione dettagliata che risponde a entrambe le domande la fornisce la documentazione di Cython, che riporto: [cut]

Ok, fin qui ci siamo. Il punto e', come ho scritto in precedenza, che invece di usare una nuova istruzione, il cdef, si potrebbe usare comunque il def seguito dal tipo di funzione (int, string, bool, ecc). Se il def e' seguito da una dichiarazione di tipo allora e' l'equivalente dell'attuale cdef, altrimenti e' una funzione o una variabile Python. E nello stesso modo basterebbe mettere <tipo> <variabile> per la dichiarazione delle variabile, invece di cdef <tipo> <variabile>. Sarebbe una sintassi meno incasinata.

A dire il vero neanche mi piace tanto questa soluzione. Personalmente utilizzerei la sintassi del Python per le conversioni esplicite. Qualcosa tipo questo:

a = int(5, bit=64, 'unsigned')
def func1(string(x), char(y)) as bool() : ...

[QUOTE=cdimauro;27111592]Il for di cui parli a quanto pare è un retaggio del passato, per compatibilità col codice scritto con Pyrex

Aaaaah ecco. Ok, gliela si puo' "perdonare" :D

Semplice: CPython NON è un interprete per il codice prodotto da Cython. CPython interpreta il codice prodotto da... se stesso (o eventualmente compilato da applicazione come PyPy, che possono produrre bytecode). Il codice prodotto da Cython è utilizzabile all'interno di CPython esclusivamente come estensione, quindi caricando l'opportuno modulo e utilizzando le funzioni esportate da Cython.

Ma questo non ha assolutamente importanza. E' un linguaggio altamente specializzato, ma e' un _linguaggio di programmazione_. Altrimenti come definiresti la sua sintassi (e non il tool del pacchetto)?

Ok, fin qui ci siamo. Il punto e', come ho scritto in precedenza, che invece di usare una nuova istruzione, il cdef, si potrebbe usare comunque il def seguito dal tipo di funzione (int, string, bool, ecc). Se il def e' seguito da una dichiarazione di tipo allora e' l'equivalente dell'attuale cdef, altrimenti e' una funzione o una variabile Python. E nello stesso modo basterebbe mettere <tipo> <variabile> per la dichiarazione delle variabile, invece di cdef <tipo> <variabile>. Sarebbe una sintassi meno incasinata.

A dire il vero neanche mi piace tanto questa soluzione. Personalmente utilizzerei la sintassi del Python per le conversioni esplicite. Qualcosa tipo questo:

a = int(5, bit=64, 'unsigned')
def func1(string(x), char(y)) as bool() : ...
In tutta onestà così lo trovo molto più incasinato.

Con parole chiave come cdef si nota immediatamente dove inizia il codice specifico di Cython.
Ma questo non ha assolutamente importanza. E' un linguaggio altamente specializzato, ma e' un _linguaggio di programmazione_. Altrimenti come definiresti la sua sintassi (e non il tool del pacchetto)?
Limitatamente a sintassi e semantica è un linguaggio di programmazione.

Gli manca, però, tutto il resto, cioé almeno un interprete che consenta di eseguire il suo codice.

E non puoi associarlo a CPython, da questo punto di vista, perché quest'ultimo esegue il SUO codice (bytecode).

Personalmente utilizzerei la sintassi del Python per le conversioni esplicite. Qualcosa tipo questo:

a = int(5, bit=64, 'unsigned')
def func1(string(x), char(y)) as bool() : ...

In tutta onestà così lo trovo molto più incasinato. Con parole chiave come cdef si nota immediatamente dove inizia il codice specifico di Cython.

Non serve mica a molto saperlo. L'unico motivo che mi viene in mente per cui potrebbe essere utile e' nel caso tu voglia poi in un futuro riscriverlo in codice Python puro, ma sinceramente non e' poi cosi' piu' complicato da fare, e non e' un caso cosi' importante da prendere in considerazione.

Che sia una sintassi incasinata poi non lo credo. E' sicuramente piu' scomoda da utilizzare. Tieni comunque conto che si potrebbero definire dei valori di default. Per esempio, int(n) senza altri parametri dovrebbe venir interpretato come un normale dichiarazione int del C. Inoltre invece di 'unsigned' si potrebbe usare semplicemente 'u'. Comunque devo dire che la sintassi per le funzioni e classi non convince neanche tanto me (intendo la parte con l'as).

Ad ogni modo, una sintassi come la mia avrebbe un vantaggio: potrebbe essere integrata in un futuro nel linguaggio Python stesso, e permettere al programmatore di scegliere tra duck e strong typing. Non credo che una sintassi alla Cython verrebbe mai accettata se non come linguaggio e tool a se stanti.

Limitatamente a sintassi e semantica è un linguaggio di programmazione. Gli manca, però, tutto il resto, cioé almeno un interprete che consenta di eseguire il suo codice.

Ma un linguaggio mica deve avere per forza un proprio compilatore e/o interprete, scusa. Per semplicita' il suo sviluppatore si e' appoggiato a un compilatore C e all'interprete Python, ma potrebbe svilupparne benissimo uno suo. Non che la cosa avrebbe molto senso, ma potrebbe farlo. Potrei anche definire un linguaggio di programmazione descrivendone la sola sintassi ma senza implementare un compilatore o una distribuzione.

Non serve mica a molto saperlo. L'unico motivo che mi viene in mente per cui potrebbe essere utile e' nel caso tu voglia poi in un futuro riscriverlo in codice Python puro, ma sinceramente non e' poi cosi' piu' complicato da fare, e non e' un caso cosi' importante da prendere in considerazione.

Che sia una sintassi incasinata poi non lo credo. E' sicuramente piu' scomoda da utilizzare. Tieni comunque conto che si potrebbero definire dei valori di default. Per esempio, int(n) senza altri parametri dovrebbe venir interpretato come un normale dichiarazione int del C. Inoltre invece di 'unsigned' si potrebbe usare semplicemente 'u'. Comunque devo dire che la sintassi per le funzioni e classi non convince neanche tanto me (intendo la parte con l'as).
No, guarda: la situazione così peggiora nettamente dal punto di vista della leggibilità, e per un pythonista questa è una cosa grave.
Ad ogni modo, una sintassi come la mia avrebbe un vantaggio: potrebbe essere integrata in un futuro nel linguaggio Python stesso, e permettere al programmatore di scegliere tra duck e strong typing. Non credo che una sintassi alla Cython verrebbe mai accettata se non come linguaggio e tool a se stanti.
Su questo posso assicurarti che Python non ha alcuna intenzione di aggiungere elementi per introdurre la tipizzazione statica.

Guido è stato molto chiaro diverse volte: ci sono altri linguaggi se si desiderano queste caratteristiche.
Ma un linguaggio mica deve avere per forza un proprio compilatore e/o interprete, scusa. Per semplicita' il suo sviluppatore si e' appoggiato a un compilatore C e all'interprete Python, ma potrebbe svilupparne benissimo uno suo. Non che la cosa avrebbe molto senso, ma potrebbe farlo. Potrei anche definire un linguaggio di programmazione descrivendone la sola sintassi ma senza implementare un compilatore o una distribuzione.
Rimane un puro esercizio di stile.