Da qualche tempo i sorgenti di Python 3.2 (al momento arrivato alla quarta alpha) sono mio oggetto di studi per comprendere le differenze col vecchio ramo 2.x (Python 2.7 è ne sarà l’ultima versione) e le possibili modifiche apportabili per migliorarlo dal punto di vista prestazionale.
Seguendo anche la mailing list degli sviluppatori ho sentito parlare spesso di una modifica al cuore della virtual machine che permette di ottenere un notevole boost, e che è basata sui cosiddetti computed goto, funzionalità questa che ho visto la prima volta nel linguaggio Fortran, ma mai in C e derivati.
Sorgenti alla mano (si tratta del file ceval.c che potrete trovare nella cartella Python scaricabile da qui), ho potuto constatare che effettivamente la VM è stata modificata per sfruttare questa caratteristica (segue un estratto):
#if USE_COMPUTED_GOTOS
/* Import the static jump table */
#include "opcode_targets.h"
[...]
#define FAST_DISPATCH() \
{ \
if (!_Py_TracingPossible) { \
f->f_lasti = INSTR_OFFSET(); \
goto *opcode_targets[*next_instr++]; \
} \
goto fast_next_opcode; \
}
#endif
#else
#define FAST_DISPATCH() goto fast_next_opcode
#endif
Com’è possibile vedere, il codice ha subito una “biforcazione”, utilizzando il preprocessore per controllare se i computed goto sono disponibili e abilitati, altrimenti viene compilato il normale code-path.
L’istruzione incriminata è ovviamente:
goto *opcode_targets[*next_instr++]
della cui sintassi non v’è traccia alcuna nel draft dello standard ISO C99 (paragrafo 6.8.6.1, pagg. 137-138 o pagg.149-150 usando Acrobat Reader).
Si trova, invece, nel manuale del compilatore GCC alla sezione 6.3 (“Labels as Values“), pagg. 279-280 (291-292 con Acrobat).
Il titolo del capitolo 6 è tutto un programma (“Extensions to the C Language Family“), e già dalla prima riga lo scopo risulta chiaro: “GNU C provides several language features not found in ISO standard C“.
Si tratta della parte più corposa del manuale, considerato che consta di ben 282 pagine (su 692 totali), a cui seguono altre 12 pagine per le estensioni al C++, e infine altre 9 per quelle dedicate a Objective-C.
Uno scenario analogo si ha per la libreria standard. ANSI e ISO riportano nei draft un ben preciso insieme di file include che vanno supportati e che definiscono costanti, macro e funzioni che vi fanno parte, e che devono essere messi a disposizione da tutti i compilatori aderenti.
Il manuale della GNU C Library (chiamata anche libc o glibc) presenta, invece, una “ricca dote”. Oltre alla libreria standard mette a disposizione funzionalità POSIX, Berkeley System V, e… estensioni GNU.
E’ facile immaginare, a questo punto, la quantità di estensioni (soprattutto al C) & funzioni che siano state introdotte. Nuove funzionalità, quindi, ma che, se utilizzate, creano di fatto ulteriori problemi di portabilità e compatibilità (oltre ai soliti con cui si ha a che fare col linguaggio C).
L’esempio della VM Python è eloquente: è stato necessario far ricorso al preprocessore per sfruttare i computed goto e mantenere, al contempo, la compatibilità con tutti gli altri compilatori che seguono, invece, lo standard C (per CPython, come per diversi altri progetti, il riferimento è l’ANSI C89; infatti nemmeno i commenti C++ style, sebbene introdotti con l’ISO C99, sono permessi).
Paradossale, poi, che alcune estensioni GNU al linguaggio C non siano supportate dal frontend C++, col risultato che, se un progetto per cui è stato utilizzato il C ne fa uso un giorno si dovesse decidere di passarlo al C++, l’operazione non sarebbe immediata, ma richiederebbe di rimetter mano al codice…
La non stretta né piena compatibilità allo standard crea una situazione tutt’altro che piacevole per chi deve sviluppare applicazioni portabili, o dovesse decidere di effettuare il porting di un progetto verso sistemi non inizialmente supportati.
Ne parla esplicitamente un’apprezzata programmatrice Amiga, Elena Novaretti, di cui trovate opinione e problematiche in questa pagina, alla sezione 2.3 (“Compilazione su AmigaOS3.x (GCC)“), in cui appare evidente di come GCC stia letteralmente soffocando gli altri compilatori a causa dei progetti che sono scritti con e, purtroppo spesso, per esso.
Un altro esempio concreto arriva in questi giorni, con l’avanzamento dei lavori del porting di AROS alle vecchie, gloriose, macchine Amiga, che sono basate sulla CPU Motorola 68000.
Al momento l’obiettivo primario è la realizzazione di una versione del Kickstart interamente basata sul codice di AROS, ma esiste già qualcosa di parzialmente funzionante anche se, com’è evidente dal secondo commento, risulta troppo lento.
D’altra i problemi di GCC col frontend 68000 sono ben noti (ne ho parlato anche in quest’articolo), tant’è che anche un membro del team di Natami (progetto di cui abbiamo già parlato e a cui sta molto a cuore un port di AROS per 68000) auspica l’uso di un compilatore migliore (ultimo commento di giorno 29 novembre).
Si pensa di utilizzare un altro noto compilatore in ambito 68000, il Vbcc, ma anche a un eventuale miglioramento di LLVM che supporti pienamente questa famiglia di processori.
In ogni caso lo scoglio più grande da superare rimane il codice già scritto e troppo legato al GCC e alla sua non stretta aderenza allo standard. Standard che, è bene ricordarlo, non si possono tirare in ballo soltanto quando fa comodo, come nella stigmatizzata e ben nota politica “embrace, extend and extinguish“…
Le estensioni “proprietarie” di GCC sono uno dei principali motivi per cui clang non ha potuto subito compilare alcuni progetti, kernel linux in primis.
E’ ovviamente parecchio buffo che dal fronte che più si lamenta del non rispetto degli stadard da parte di alcune aziende vengano poi problemi di questo tipo.
se si estingue il c++, sara’ reso un servizio meritevole all’umanita’ :)
magari, prepariamoci per tempo con qualcosa che lo sostituisca :)
Forse mi sbaglio, ma a me sembra naturale che ogni progetto mostri delle peculiarità, che sviluppi funzionalità accessori, poi sta tutto nello sviluppatore di un progetto decidere o no di farne uso, conoscere bene la documentazione per verificare la portabilità. Forse con altri compilatori C/C++ le cose vanno meglio? Con progetti Visual C++ com’è il discorso? Se voglio compilare Firefox su Windows sono costretto a installarlo (e certamente non basta la versione gratuita).
E’ chiaro che ognuno può fare quello che vuole. Anche aggiungere estensioni a iosa a un linguaggio e/o libreria.
Ma poi non si venga puntare il dito contro chi fa lo stesso, accusandolo di “Embrace, Extend and Extinguish”. Non foss’altro per una questione di coerenza. :P
@Dubbioso: anche a me non piace, però poi con cosa lo sostituiresti per gli specifici ambiti applicativi per cui viene usato?
E che linguaggio che offre almeno le stesse prestazioni del C++ dovremmo usare ? Ti prego non dire Ruby, Python perche’ e’ semplicemente ridicolo. Entrambi questi linguaggio hanno il tallone di achille nel sistema runtime che e’ a dire poco un orrore.
Java ? Java va bene sui server, uscito da li’ e’ inutile, tanto che Google ha dovuto prendere in mano la situazione per rendere Java adeguato ai terminali mobili moderni e ha fatto scatenare le ire di Oracle.
Scala per quanto sia veramente un ottimo rimpiazzo per Java e C++ rimane legato alla JVM e ovviamente usa tutta la class lbrary di Java. Se spuntasse fuori un compilatore nativo per Scala e si incominciasse a implementare una class library degna di questo nome beh come si dice la speranza e’ sempre l’ultima a morire.
Groovy idem, resta legato alla JVM e poi le masse di programmatori sono avversi alla programmazione funzionale (per cui anche Haskell e’ out).
Javascript non va bene, e neanche Perl.
Quindi ? Smalltalk se avesse una implementazione GNU di prim’ordine potrebbe essere una serie alternativa al C++ e a Java. Anche Objective-C non e’ male (ma ovviamente si porta dietro alcune/molti problemi del C).
Quindi mi spiace, ma C++ ce lo teniamo con tutti i difetti perche’ non ce’ niente di meglio in giro, a meno di non voler essere il suddito di qualche azienda che fa vita morte e miracoli con il “SUO” linguaggio e framework.
@Dubbioso
Il C++ è insostituibile per certi ambiti imho. I programmi in .NET che al momento vanno per la maggiore sono di una inefficienza spaventosa, tonnellate di RAM e CPU sprecate e comunque performance scadenti :-(
@goldorak: imho objecive-c potrebbe essere un degno sostituto di c++, ma ,come dici giustamente, il “peccato originario” di discendere da c è presente anche lì ;)
Da quello che ho capito GCC supporta tutto lo standard e in più offre caratteristiche aggiuntive. Il problema allora è di chi lo usa in modo errato: se un progetto nasce multipiattaforma o si pensa che in futuro lo sarà è inutile/dannoso andare ad usare estensioni non standard anche se risultassero molto utili.
@goldorak: io ho posto una domanda, infatti, e non ho fornito una risposta (né lo faccio ora, visto che siamo tremendamente OT). ;)
Comunque se non ti piace il runtime di Python o Ruby, come puoi venire a parlarmi di SmallTalk, che è un altro linguaggio molto dinamico? :P
@olivobestia: cui prodest? Se tutti quanti estendessero un linguaggio standard, che senso avrebbe parlare di standard (da rispettare), appunto?
“Non foss’altro per una questione di coerenza. :P”
La coerenza richiede logica ed onestà intellettuale.
Non so perchè, ma quando leggo la parola GNU, nel mio celebro s’accende la lucetta sotto l’etichetta “politica” che sul pannello, si trova agli antipodi rispetto le altre due.
Articolo interessante Cesare, sono andato subito a vedere cosa succede con altri compilatori che ho a portata di mano in questo momento.
Visual Studio 2010 non lo vuole nemmeno sentire, il compilatore Intel 12.0 su Linux invece supporta l’estensione.
Personalmente non sono contrario alle estensioni per partito preso.
Lo standard del linguaggio si muove lentamente, basta guardare al C++ e il nuovo “C++0x”, dove 0x sarebbe stato in teoria un anno del decennio scorso, mbe’ siamo nel 2010 e ancora non e’ stato ratificato :(
Se una feature ha una giustificazione forte e non messa li’ a casaccio ci puo’ anche stare.
Questa che hai citato tu in particolare non mi sembra nemmeno cosi’ complessa da implementare, visto che non sono offerte garanzie di sorta sull’out of bounds del goto (come del resto con qualsiasi puntatore in C) ed il comportamento e’ indefinito per goto fuori dalla funzione stessa.
Insomma, e’ uno switch statement ottimizzato.
@Cesare Di Mauro
La base comune dello standard rimane, il problema si presenta se viene implementata solo parte dello standard oppure se lo standard implementato non viene migliorato nelle prestazioni e nella correzione di bug a discapito delle estensioni proprietarie.
Inoltre bisognerebbe capire lo spirito che ha spinto gli sviluppatori ad aggiungere queste famigerate estensioni visto che lo standard è del ’99 forse qualche aggiunta andava fatta (però 282 pagine mi sembrano troppe).
Secondo me sarebbe meglio che lo standard venisse rattificato non ogni 10 anni ma ogni 5 così da inglobare parte delle estensioni
Non rigiriamo la frittata: l’EEE consiste nell’imporre estensioni proprietarie al PRODOTTO di un software, impedendo che i concorrenti possano fare altrettanto (tramite brevetti o mancata documentazione).
Il GCC OFFRE estensioni che possono essere usate a propria discrezione; se una CAPRA usa estensioni proprietarie del linguaggio senza usare accorgimenti per la portabilità del codice (come l’ifdef citato nel primo esempio), è un problema suo e, purtroppo, di chi deve rimediare.
Qualunque programma scritto in C standard può essere compilato con GCC, quindi non capisco il senso della polemica. Se GCC IMPONESSE di deviare dallo standard, si potrebbe parlare di EEE.
Colgo comunque l’occasione per fare i complimenti all’autore per la sua competenza, nonostante ogni tanto le sue opinioni lo portino a scrivere pezzi un po’ “schierati”, come in questo caso :)
@ Cesare di Mauro : mi spiace, non ho indicato che stavo rispondendo a Dubbioso.
Per Smalltalk, la differenza con Python e’ che la prima ha delle implementazioni commerciali veramente prestanti (pur essendo Smalltak un linguaggio dinamico) mentre Python no.
Passando al succo dell’articolo. Stai cercando di paragonare le estensioni del GCC al modus operandi di Microsoft. E un confronto senza capo ne’ coda.
Inoltre e’ chiaramente indicato che usando le estensioni del compilatore GNU generi codice non strettamente ANSI C. Questo pero’ non deve far dimenticare che se vuoi fare un progetto 100% ANSI C e quindi portabile su qualsiasi altra piattaforma che supporti lo standard lo puoi fare. Prendi il caso particolare della libreria Freetype. E 100% ANSI C, e su linux usi GCC per compilarlo. Quindi l’ Embrace, Extend, Extinguish lo vedi solo tu col binocolo. Gli sviluppatori hanno la scelta, se fare un progetto in ANSI C, oppure se usare estensioni che sono specifiche (non di linux) ma di GCC. Che poi GCC esista anche per windows ti sfugge, oppure gli sviluppatori potrebbero usare delle librerie che magari esistono su linux ma non su windows. Anche qui dobbiamo gridare al EEE ?
Anche a me pare molto forzato e di parte il paragone con EEE. Caso mai parlerei di EE, Embrace and Extend questo si, ma non capisco come si possano tirare in ballo “Extinguish”.
Cosa ci sarebbe da fare estinguere?
Condivido comunque il disappunto per la scelta infelice di espandere lo standard “a capocchia” per motivi difficili da comprendere.
@goldorak: io sono uno sviluppatore, per quanto della domenica, per cui ti posso dire che il problema non è usare le estensioni o non usarle, perché le estensioni se ti fanno comodo le usi: tanto, come dici tu, per i progetti non strettamente ANSI non lo fai.
Il problema è che dopo un pò di progetti che usi le estensioni, ne diventi dipendente. Non ti ci sta più di scrivere codice senza le estensioni, perché devi smadonnare per fare cose che con le estensioni eri abituato a fare subito. E’ questione di abitudine e di comodità, come le sigarette, i cioccolatini e la cocaina… ^_^
E in più, se programmi per lavoro, interviene anche il fattore tempo: il TUO tempo è prezioso, tutto quello che te lo fa risparmiare è oro e tutto quello che te lo fa perdere è merda.
Se le estensioni ti fanno comodo le usi sempre; se un altro compilatore non supporta le estensioni che usi tu (qualunque siano) è un compilatore di merda e lo eviterai come la peste, a costo di pagare 1000 euro per un VC nuovo ogni anno, a costo di rinunciare a lavori che altrimenti prenderesti perché sai che dovresti cambiare compilatore. E tanti saluti allo standard.
lunga vita al C e al suo fratellino C++
Ma anche volendo proprio ammettere una parità di comportamento (che però non vedo), una cosa è se chi agisce è un gigante dell’informatica, tutt’altra se si tratta di quattro gatti stipendiati (per quanto influenti). Giusto?
@Notturnia
Sottoscrivo tanto tanto! Anche se il c++ lo vedo più come un figlio che come un fratello rispetto il c :)
“troppo legato al GCC”
parole sante…
il gcc è un ottimo compilatore usato da piu’ di 20 anni con successo in numerosi ambiti….ormai è un pachiderma…da anni speravo in fork che alleggerisse delle centinaia di aggiunte e lo rendesse piu’ simile al compilatore intel….purtroppo al momento ce lo dobbiamo tenere cosi’….
il problema è che tutte le funzioni aggiunte in realtà sono “utili” in ambiti cosi’ ristretti da limitare se non proprio annullare la loro efficacia, ma basta che vengono usate in una piccola porzione del codice per dare problemi…
io faccio sempre il test -ansi affiche il codice sia conforme allo standard…ma non sempre è stato possibile farlo….
è quanto scritto da CDMAURO in realtà non è troppo lontano dalla verità….d’altronde l’uomo tende ad estendere la lingua che usa con dei neologismi e i linguaggi di programmazione non si sottragono a questa regola millenaria….che in un linguaggio di programmazione scientifica da comunque problemi….
@homero dovresti testare clang che è maturo per il c e objc e ormai risulta usabile anche per c++.
E’ molto più rispettoso degli standard di GCC e estremamente più veloce come compilazione. http://clang.llvm.org
e quale sarebbe il problema? se qualche assurda estensione l’aggiunge ms allora è brava e buona e anzi lo fa perchè quei cretini che hanno creato lo standard non capiscono niente
se lo fa gcc allora è brutto e cattivo
gcc supporta l’iso c99? SI e in più aggiunge delle feature sue
è fesso quel programmatore che usa le feature specifiche di gcc pur sapendo che vuole creare un programma multipiattaforma
e poi gcc è open, quindi lo puoi usare, modificare, redistribuire, in che modo questo dovrebbe essere uguale all’embrace, extend, extinguish?
infine il fatto di essere open non implica sempre e comunque di dover pedissequamente seguire gli standard, perchè se fosse così ad oggi non dovremmo avere nessun browser html5 perchè lo standard è in draft e molte cose supportate da webkit sono appena abbozzate dallo standard
cioè in pratica la domanda è semplice e cioè “a me creatore di compilatori closed chi m’impedisce d’implementare le stesse feature di gcc?”
ovviamente nessuno, cosa che invece non puoi fare se decidi d’implementare certe caratteristiche di un compilatore ms perchè si sono ennemila brevetti che andresti a violare
@un po’ tutti
so bene che il C++ e’, in alcuni ambiti, difficilmente sostituibile al momento, infatti ho detto che sarebbe ora di preparare qualcos’altro.
una possibile soluzione, potrebbe anche essere la compilazione nativa di uno di questi linguaggi che, al momento usano una virtual machine.
e se devo scegliere, preferisco di gran lunga il C
@iva:
Nemmeno io sono aprioristicamente contrario, ma le estensioni inserite “motu proprio” creano, appunto, problemi di incompatibilità e/o portabilità, come quelli evidenziati nell’articolo (e qualcuno anche nei commenti).
Vedo senz’altro meglio le estensioni prese dal draft del futuro standard, perché quanto meno tutti i compilatori tenderanno ad allinearsi, piuttosto che una feature buttata lì e usata soltanto da uno dei tanti.
Quanto a C++0x, beh, Stroupstrup ha dichiarato che nella “x” può starci una cifra esadecimale… :P
Senza dubbio, e allora perché non ottimizzare direttamente lo switch? :P
E’ una domanda che mi sono seriamente posto quando mi sono trovato di fronte a questi goto calcolati, perché pensavo che negli anni i compilatori avessero implementato qualche ottimizzazione di questo tipo
@olivobestia:
Considera che ancora oggi GCC non è perfettamente compliant con l’ISO C99…
Non sarebbe male come idea, ma quando c’è di mezzo un comitato i tempi si allungano.
@Stiffmaister:
Se prendessimo questa definizione, a naso ci rientrerebbe soltanto il caso Kerberos. Il che farebbe sgonfiare di botto l’EEE…
Sono capre anche gli sviluppatori di Linux (vedi commento di RunAway)? :P
Non c’è motivo di aggiungere estensioni a uno standard, perché facilitano e inducono alla scrittura di codice dipendente dal particolare compilatore. Vedi anche i commenti di Massimowski e homero.
E uscire fuori dallo standard significa creare problemi di compatibilità e portabilità. Vedi il caso di AROS & AmigaOS citato nell’articolo o di CLang/LLVM citato da RunAway.
GCC nell’ambito open source è il compilatore dominante, e con le sue estensioni di fatto soffoca quelli alternativi, anche open source, legando i progetti a esso e alla piattaforma che propugna (Unix & derivati) anche quando se ne potrebbe fare a meno.
Sono sempre bene accetti (anche perché ti assicuro che non ci perdo mezz’oretta a scrivere i miei pezzi: dietro c’è parecchio lavoro). :P
Poi sentire una campana diversa ogni tanto penso che faccia bene a tutti, magari tirando fuori degli spunti di riflessione. O:-)
@goldorak:
Python funziona già molto bene anche coi compilatori / VM open source. 8-)
Ecco qui: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=python Come vedi prestazionalmente non ha nulla da invidiare a SmallTalk (hanno pregi e difetti entrambi), ma l’occupazione di memoria e la dimensione del sorgente sono nettamente a favore di Python.
Un altro esempio con PyPy (che penso diventerà la futura versione mainstream di Python): http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=python Qui le prestazioni sono più allineate, come pure il consumo di memoria, mentre rimane il vantaggio in termini di dimensione del sorgente.
Considera, inoltre, che dietro Python c’è una comunità molto più grande (oltre a pezzi da ’90 come Google e YouTube) e la situazione migliora in continuazione. ;)
Io guardo gli effetti, e mi sembra proprio di non sbagliare. Vedi anche sopra.
Mi stai dicendo che ritieni perfettamente legittimo utilizzare estensioni a linguaggi e/o librerie? E la scrittura di codice che le utilizzi?
Se le risposte sono affermative vuol dire che hai eliminato in colpo solo praticamente tutti i casi che sono stati additati come EEE. :P
Sfruttare librerie (ma anche estensioni) esclusive di un particolare s.o. è perfettamente legittimo. E’ chiaro che, però, ci si lega al s.o. creando problemi alla portabilità (vedi, nuovamente, le rogne con AROS, AmigaOS e CLang).
D’altra parte, e visto che l’hai nominata, lo fa anche Microsoft da tempo con le SEH, ad esempio: http://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms
Tutto legittimo, quindi? Bene, ne prendo atto. O:-)
@Andrea Del Bene:
Prova a compilare un progetto open source multipiattaforma con Vbcc, oppure il kernel di Linux con CLang/LLVM. Non ci riesci, perché sei legato mani e piedi a GCC.
Di fatto GCC soffoca le alternative, che possono essere anche di qualità superiore (Vbcc genera codice 68000 migliore; CLang è più veloce a compilare).
@Medicina:
GCC in ambito open source non è certo un nanetto, ma un gigante. Specialmente rispetto agli altri compilatori (vedi sopra).
Detto ciò, si tratta di una questione di principio: le estensioni tendono a soffocare le alternative, come già evidenziato, imponendo un solo player di fatto. Che poi fuori dalla teoria (il “principio”) è proprio quello che succede.
Inoltre se i compilatori aggiungono estensioni, gli standard che ci stanno a fare? E, soprattutto, è inutile appellarvisi se ognuno è legittimato sia a estendere che a usare le estensioni.
Con questa presa di posizione si può praticamente cancellare il concetto di EEE…
Mah… è il secondo articolo che leggo di CDM e lo trovo ‘scentrato’ come il primo.
Il punto è che le estensioni del GCC non sono proprietarie. Il comportamento è descritto, il sorgente disponibile e niente vieta di reimplementarle (è quello che sta facendo CLANG).
Quindi il paragone con EEE non c’entra una cippa.
P.S.
E’ un’impressione o c’è una certa animosità verso Linux, GCC & Co.?
@ Cesare di Mauro ha scritto :
“GCC in ambito open source non è certo un nanetto, ma un gigante. Specialmente rispetto agli altri compilatori (vedi sopra).
Detto ciò, si tratta di una questione di principio: le estensioni tendono a soffocare le alternative, come già evidenziato, imponendo un solo player di fatto. Che poi fuori dalla teoria (il “principio”) è proprio quello che succede.
Inoltre se i compilatori aggiungono estensioni, gli standard che ci stanno a fare? E, soprattutto, è inutile appellarvisi se ognuno è legittimato sia a estendere che a usare le estensioni.
Con questa presa di posizione si può praticamente cancellare il concetto di EEE…”
Continui a fare un ragionamento sbagliato. Le estensioni di GCC non escludono il rispetto dello standard. Sono un plus. Gli utenti hanno la scelta se usarli o meno. In un compilatore proprietario, semmai dovessero includere estensioni proprietarie e non dessero la possibilita’ di usare lo standard tu come utilizzatore non potresti fare niente di niente. E quella azienda avrebbe il potere di eliminare con questo trucchetto tutti i compilatori concorrenti. Poi tanto trucchetto non e’ visto che e’ stato il modus operandi della Microsoft per oltre 2 decenni e che per questo motivo si e’ presa delle multe miliardarie. Quindi vedi di fare il giusto confronto, perche’ alla fine finsci col fare paragoni tra mele e pere.
EEE ha un significato ben preciso, non puoi arrivare tu e un giochetto da 4 soldi cambiarne il senso.
forse perchè non vedi il quadro d’ insieme, e il contesto che motiverebbe le eventuali critiche dell’ autore – per cui queste ti appaiono come puramente pregiudiziali…
il problema è che proprietarie o meno, non si tratta di sole estensioni sintattiche…
Esistono anche quelle (alcune usate anche, per dire, da linux http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/#optimizationextensions ) che in effetti sono hint ad uso del compilatore / ottimizzatore – quindi in certo qual modo connesse al funzionamento, quindi agli internals, di questo
quindi se io sto realizzando un altro compilatore con un design e un’ architettura interna, completamente differente, posso sì aggiungere il riconoscimento di tali hint a livello di parser – ma fare in modo che con il codice che li contiene, funzionino allo stesso modo che sul compilatore per cui questo era scritto (e magari non introducano bug subdoli – non è da escludere anche quello trattandosi di roba fuori standard) può essere un alto paio di maniche
con buona pace del “è aperto posso fare quello che mi pare”…
rifletti.
clang, ma prima ancora LLVM, perchè è nato in prima battuta? perchè per realizzare gli obiettivi che ci si prefiggeva (integrazione con i sistemi di edit/assist/code completion degli IDE, ottimizzazione a più riprese del codice, integrazione tra linguaggi diversi…) perchè fosse conveniente riprendere e modificare sw concettualmente anacronistico (compilatore monolitico process driven, non dissimile in questo da un qualunque tool unix “vecchia scuola”), architetturalmente troppo complesso per quello che fa, e dal codice contorto, ancorchè aperto, come GCC, rispetto al creare un nuovo e più pulito progetto
ma dal momento che è stato creato appunto un nuovo progetto con una nuova architettura, una nuova licenza (liberale e non coercitiva come la GPL) e un diverso linguaggio ( C++ e non C), di fonte a eventuali feature utili / necessarie presenti invece in GCC non si può certo pensare di trasporle pari pari da questo – anzi la disponibilità del sorgente di GCC è una liability ( chiedo scusa, non mi viene un equivalente italiano) perchè per ogni similitudine si rischierebbe di dover poi dimostrare di non essersi “ispirati” al codice GNU (che stallman e compagni sono sempre solerti nel mantenere “libero”)
Clang è production ready? lo puoi usare per compilare progetti di una certa complessità o gli stessi per cui adesso sei costretto a usare GCC?
non ancora mi risulta, quindi non conta
il paragone c’ entra eccome, se si pensa a come l’ ambito del sw alternativo (non microsoft) è quasi interamente (fatta salva solo Apple) coperto da una monocultura nemmeno solo unix, ma specificamente GNU …
da un lato linux, “quasi” ovunque desktop a parte – dall ‘altro GCC ovunque (senza quasi), su linux ma anche su solaris, qnx, vxworks… e che OO…
il ragionamento sbagliato è quello che non tiene conto del fatto che se le estensioni vengono fatte è per accontentare coloro che le richiedono per usarle – se esistono è ovvio che il sw le richiede
il problema è nel principio stesso di deviare dallo standard e non integrare quest’ ultimo – con il risultato che il codice stesso resta vincolato a un’ implementazione fuori standard del linguaggio
@ j : ma questa scelta ricade sul programmatore. Se io sviluppo per un target di nicchia e uso delle estensioni specifiche fuori standard sai quanto me ne frega che il codice non sia portabile su altre architetture ? Il punto sta a monte, se io voglio fare un progetto che sia multiplatform vedo di usare strumenti che mi diano questa possibilita’. Ma e’ fuori dal mondo dire che uno parte con l’idea di usare estensioni non standard di gcc per un progetto e poi si lamenta che ci siano delle difficolta’ a portare il codice su altri sistemi oppure usare un compilatore diverso.
Infine sul discorso llvm. Il grande impulso di clang/llvm viene da Apple perche’ vuole avere un compilatore che le dia la possibilita’ di mantenere una porzione del backend (quella relativa alle ottimizzazioni) chiusa. E per questo che la licenza di questo compilatore e’ BSD.
Con GCC tutti giocano alla pari, con llvm ti ritroverai con un compilatore che fornisce un front end comune, ma poi le diverse aziende che implementeranno i vari back end si guarderanno bene dal rendere le ottimizzazioni disponibili a tutti. Ecco perche’ llvm e’ un progetto monco, chi non lo capisce ha le fette di salame sugli occhi.
Poi possiamo discutere su questioni archiettturali di GCC, ma questo non deve far perdere di vista il perche’ dell’esistenza di clang/llvm. E non e’ certo perche’ GCC e’ monolitico o perche’ gli sviluppatori preferiscono C a C++ o altre cretinate del genere.
@J clang è considerabile production ready per objc (ovviamente visto il grosso investimenti di Apple) e c.
Il supporto al C++ è ormai completo, ma non ancora production ready. Tuttavia è già possibile cominciare a testare i propri progetti e avvantaggiarsi quindi di tutte le nuove tecnologie di clang/llvm. Una fra ttute la migliore e più profonda analisi del codice che permette un debug migliore con errori più sensati e varie altre chicche.
PEr quanto riguarda i progetti compilabili è da un paio di mesi circa che ormai si possono compilare le Qt e sempre da un paio di mesi è possibile compilare linux e farlo partire in runlevel 5.
Le Qt è stato possibile compilarle grazie alla collaborazione del team di sviluppo. Per linux da quello che ho capito si è arrivato a poterlo compilare un po per alcune cose implementate da clang e un po per patch sul kernel, soprattutto la seconda.
Il punto è che se GCC avesse solo supportato gli standard senza introdurre difatto un suo dialetto (composto dallo standard più le estensioni), clang sarebbe riuscito a compilare molte più cose da subito.
Il fatto che gcc sia open source è irrilevante, primo perchè in ogni caso il coidce non sarebbe usabile tale e quale senza dover sottostare alla GPL, e clang è sotto bsd; secondo perchè essendo praticamente in regime di “monopolio” condiziona di fatto tutti.
Se prima di clang non c’erano valide alternative open (per vari motivi), ora che un’alternativa c’è si scontra inesorabilmente con un mondo alterato dalla devianza dello standard di GCC.
Per dovere di cronaca c’è da dire anche che alcuni problemi riscontrati da clang derivano dal fatto che alcune parti della specifica, soprattutto del c++, sono evidentemente un po troppo discrezionali quindi talvolta dove gcc si rivela molto più permissivo clang fallisce perchè è stato pensato per essere più rigoroso.
a questo punto, vorrei fare una precisazione sull’eee, anche se so, che rischia di creare un pandemonio, come spesso succede in questo ambito.
le prime 2 “e” sono un fatto normale, ed anzi, oserei dire, auspicabile, in un mercato competitivo, in cui i concorrenti, nella competizione, cercano di migliorare il prodotto da proporre sul mercato per attirare maggiori clienti.
certamente la cosa crea problemi con gli standard, ma, in una situazione normale, c’e’ la possibilita’ di riassorbire le novita’.
il problema nasce con la terza “e”.
riporto da wikipedia:
“Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions”
si continua ad ignorare, in tutto questo tipo di discussioni, il concetto centrale: la chiave di tutto e’ nella parola “dominant”.
per quanto possa infastidire, la microsoft (cosi’ come intel per esempio, nel campo dei microprocessori) ha delle responsabilita’ che non spettano agli altri competitor, appunto perche’ ha una posizione dominante che le permette di estromettere facilmente gli altri.
per questo, l’extinguish e’ applicabile a microsoft (cosi’ come a tutti i soggetti in posizione dominante), mentre non vale per gli altri.
a proposito di:
—
>Esistono anche quelle (alcune usate anche, per dire, da linux >http://www.ibm.com/developerworks/linux/library/
>l-gcc-hacksoptimizationextensions ) che in effetti sono hint ad >uso del compilatore / ottimizzatore – quindi in certo qual modo >connesse al funzionamento, quindi agli internals, di questo >quindi se io sto realizzando un altro compilatore con un design >e un’ architettura interna, completamente differente, posso sì >aggiungere il riconoscimento di tali hint a livello di parser – >ma fare in modo che con il codice che li contiene, funzionino >allo stesso modo che sul compilatore per cui questo era scritto >(e magari non introducano bug subdoli – non è da escludere >anche quello trattandosi di roba fuori standard) può essere un >alto paio di maniche
—
Scusa ma che c’entra? Proprio perché sono hint a un compilatore/ottimizzatore non ha senso riprodurle, a meno che non possano essere utilizzate dall’ambiente (compilatore/ottimizzatore) target.
Se quello che intendi è che il codice risultante sarà più efficace se compilato da gcc, è vero, ma come critica mi sembra un po’.. speciosa.
a proposito di:
—
non ancora mi risulta, quindi non conta
—
Be’ CLang sostiene di essere production quality per quanto riguarda il C. Lo sto usando da troppo poco per confermare o meno.
Sulla descrizione dello stato di fatto del sw alternativo, be’ è uno stato di fatto, quindi c’è poco da discutere. 8)
La causa probabilmente è la circostanza che che nei tempi passati l’unico compilatore decente free era il gcc e le sue varianti.
Vedremo che succede con l’arrivo di altri compilatori.
@runaway
Il fatto che sia open source _è_ rilevante, perché ti permette di _reimplementare_ le estensioni avendo ben chiaro quello che fanno.
Ovviamente non puoi fare copia e incolla del codice, ma questo è un altro discorso.
Mi pare che non sia ben chiaro un concetto elementare: se le estensioni del gcc esistono e sono usate, è perché sono utili!
Gli standard sono generalmente conservatori (ed è un bene), e pertanto indicano un livello minimo. Faccio l’esempio del ‘flexible array member’, che era utilizzato (tramite il famoso ‘struct hack’, supportato da [quasi?] tutti i compilatori) ben prima dell’inserimento nello standard (of course, c’era anche un’estensione del GCC per semplificarne l’uso).
@ Pippo : hai ragione. In fin dei conti l’articolo dovrebbe essere intitolato “Embrace, Extend … anche da GCC”. Un titolo del genere sarebbe stato molto piu’ veritiero della situazione reale.
@Cesare di Mauro:
Certamente anche tra le migliaia di sviluppatori di Linux c’è qualche capra; non sono un hooligan, e quindi non ho difficoltà ad ammetterlo :)
Se la documentazione di GCC evidenzia quelle funzionalità come estranee allo standard, si comporta in modo corretto, e chi scrive coscientemente codice non portabile (inserendo almeno fallback verso lo standard) ne paga le conseguenze perdendo possibili utenti.
Per concludere, ti ribadisco la mia stima e il mio rispetto: sono dell’opinione che da una discussione in un forum escono sempre vincitori tutti, perchè ne sanno comunque di più di quanto ne sapessero prima di entrarvici.
diamoci una calmata!!!
il problema dei compilatori è un problema vecchio come il cucco…ogni compilatore aveva le sue estensioni e le sue peculiarità chi non si ricorda il borland C e il Microsoft C….pertanto scegliere un sistema di sviluppo ergo scegliere editor,compiler,debugger è in un certo senso una scelta di vita…che richiede impegno nel comprendere i meccanismi di funzionamento…
il problema di GCC è che avendo piu’ di 20 anni di vita ha di fatto raggiunto una diffusione ed una maturità che possono in un certo qual modo creare un filone parallelo allo standard….
conosco moltissime persone che non si accorgono usando GCC da 10 anni delle differenze con le specifiche ansi e producono codice in C non standard senza neppure accorgersene…
i programmatori sono tendenzialmente pigri e scrivono alle volte il codice con una inerzia da paura…
c’è da chiedersi ma gcc è un compilatore utile per qualunque progetto?
A questa domanda ho già risposto col precedente articolo sul GCC. :P
Sul resto mi trovo d’accordo: è normale che, avendo a disposizione le estensioni (tra l’altro abilitate di default), si cede facilmente alla tentazione di utilizzarle. Anzi, a volte è proprio naturale: nemmeno ci si rende conto. Tanto più, e lo sappiamo bene, che è così facile passare dalla zappa alla tastiera nel mondo della programmazione.
Concordo, quindi, anche con l’ultimo commento di RunAway (il # 30).
Riguardo all’ultima “e”, la Extinguish, rispondo a Dubbioso (ma vale per tutti ovviamente). Nella definizione che hai riportato la parola “dominant” è preceduta da “their”, quindi con chiaro riferimento alle estensioni e non all’entità/azienda che sta in posizione dominante.
Adesso prendi il GCC e rileggi quella frase considerando le sue estensioni e la situazione della concorrenza (cioè degli altri compilatori): vedrai che calza alla perfezione con quello che ho già descritto nell’articolo.
Poi il fatto che GCC sia open source non ha senso (e qui rispondo anche a collione). Non c’è uno scontro fra open e closed source, semmai potrebbe esserci fra specifiche/documentazione disponibile oppure no. Se sono a disposizione, è chiaro che chiunque le può implementare, sia una comunità che sviluppa progetti open source, che aziende che producono prodotti closed.
E’ evidente che delle estensioni di GCC sia a disposizione la documentazione: l’ho anche riportata (e citata) nell’articolo! Ma ciò NON vuol dire che gli altri compilatori potrebbero (o, addirittura, DOVREBBERO; pena l’esclusione dal “mercato”) a questo punto implementarle anche loro. E gli standard? Dove li mettiamo? Anzi, che ci stanno a fare, a questo punto? Perché perdere tempo con questi lenti comitati, buttando peraltro denaro pubblico (pochi sono finanziati dalle aziende private)?
Allora facciamone pure a meno, ma… piangiamone le conseguenze. E le conseguenze sono il caos, visto che sulla carta ognuno sarà legittimato anche moralmente (visto che gli standard NON hanno nemmeno forza di legge) a fare quello che gli pare. Da cui, lo ribadisco, viene meno anche il concetto stesso di Embrace, Extend and Extinguish (che c’è da estinguere se ognuno può fare quello che vuole?).
Perché è evidentissimo che nessuno potrà più rinfacciare a Microsoft di avere aggiunto gli ActiveX a Internet Explorer (e chiudere gli occhi se qualcun altro ha introdotto JavaScript). Nessuno potrà rinfacciarle di aver aggiunto tag all’HTML (anche se è troppo facile “dimenticare” che NON è stata la sola; vedi anche JavaScript, appunto). Nessuno potrà rinfacciarle di non aver completato il supporto ai CSS (che NON erano nemmeno stati ratificati all’epoca). E potrei continuare ovviamente…
E se decidesse di NON supportare HTML 5, beh, ci sta proprio un bel “e chi se ne frega”; faccia pure quello che vuole, e che nessuno le rompa le scatole.
E’ questo che auspicate? Ditelo. Ma non si può far rigirare nella tomba Boole e la sua logica che ci sta tanto a cuore.
O si supportano rigorosamente, senza se e senza ma, gli standard, oppure no. Non si scappa.
Perché se non lo si fa, sempre per la coerenza di cui parlavo nei primi commenti, poi NON possiamo nemmeno lamentarci di chi decide, in piena libertà, di camminare per la sua strada, anche se, facendo ciò, dovesse calpestare gli altri a causa della sua “mole”…
Da programmatore posso dire che già tenendo conto dei soli standard ho i miei grattacapi (volete “divertirvi”? Andate a controllare il codice di Python 2.x per implementare in maniera portabile la moltiplicazione di due interi: file Objects/intobject.c, funzione int_mul).
Homero ha citato Borland C e Microsoft C; io citerei anche il Turbo C (precursore del Borland C), ma soprattutto il BASIC. Perché chi ha avuto la fortuna (o, sfortuna, a seconda dei punti i vista) di lavorare con questo linguaggio ai suoi tempi d’oro (prima metà degli anni ’80) dovrebbe ricordare il caos che c’era a causa della moltitudine dei suoi dialetti (anche fra macchine della stessa casa!). E non era certo una cosa di vantarsi, visto che la portabilità era praticamente inesistente. E no, non c’era nulla di cui esser contenti, perché il prezzo più alto lo pagavano gli utenti finali…
Parlare di EEE in questo caso mi sembra una forzatura e niente altro.
Chiedilo a chi prova a compilare AROS con Vbcc, e Linux con CLang/LLVM…
Sicuramente ci saranno problemi ma dovuti alla necessità e alla voglia di estendere gcc, secondo te davvero alla gnu hanno vogliono attuare una strategia EEE alla microsoft?
Io non credo proprio, poi se vogliamo per forza far apparire GNU come “not so good” alla microsoft allora possiamo anche fare un paragone..
p.s In questi mesi sto facendo il porting a standard attuali di un importante applicazione per la PA sviluppata attorno a IE4 con tutti i problemi che ne consegue da Active X al parziale supporto alla DOM level 1.
Quello si che era un approccio EEE, fortunatamente fallito che però ancora fa sentire i suoi effetti..
homero ha scritto : “c’è da chiedersi ma gcc è un compilatore utile per qualunque progetto?”
Per i progetti open source non vedo perche’ no. O pensi che usando un altro compilatore questo problema del “Embrace, Extend” venga meno ? Tu stesso esordisci dicendo che l’EE e’ una problematica che afflige TUTTI i compilatori (commerciali e non) quindi ?
Devo poi ricordare che GCC e’ il compilatore piu’ multiplatform che esista ? Questo e’ un vantaggio mica da poco eh.
L’analisi fatta da Cesare di Mauro sarebbe condivisibile se si fosse fermato al Embrace, Extend. E fin qui non ci sarebbe niente di male. Ma dire che GCC opera con l’Embrace, Extend e Extinguish, sottolineo l’ultima parola e’ una cosa decisamente falsa. E non centrano le opinioni. Si puo’ criticare l’opera di Embrace Extend, ma allora il ragionamento deve estendersi a tutti i compilatori (che implementano completamente o parzialmente uno standard con in piu’ delle estensioni), a tutti i software che implementano parzialmente un abozzo di standard (come l’html 5 per esempio).
“Parlare di EEE in questo caso mi sembra una forzatura e niente altro.”
Concordo in pieno. Che l’autore non ami particolarmente GCC (e nemmeno io, se è per quello) poi, lo sappiamo da tempo ;-)
Rispondo a CDM post # 39 : allora io mi lamento di taluni progetti open source che nascono nel mondo windows e che sono compilabili soltanto con il compilatore della microsoft (neanche con altri compilatori commerciali). Vedi il caso di molti add-on di Orbiter. Come non ti sento CDM, dove sono le tue critiche in questo caso ? Ah dimentico che tu la crociata la fai soltanto contro il mondo open source.
Intedevo dire che CDM fa la crociata contro il mondo open source in linux.
goldrak
concordo con quanto hai scritto infatti io sono schiavo di gcc per diverse ragioni…ma ad esempio sui nuovi sistemi multicore ci sono alternative intel realmente valide che mi tentano parecchio….
purtroppo cambiare al momento compilatore richiederebbe mesi di riorganizzazione che rimando costantamente…oltre al fatto che gcc è a costo zero…mentre intel siamo sui 1000 euro da sborsare…
io intenderei l’articolo di cdmauro non nel senso stretto…ma con un significato piu’ largo….gcc con la sua enorme espansione sta fagocitando gli altri sistemi di sviluppo ed in parte lo stesso standard ansi….molti insegnanti non se ne accorgono neppure….pensate un po’ come siamo messi….
per piccoli progetti ci puo’ anche stare ma per progetti piu’ grandi è un incubo portare codice non standard da gcc ad intel per esempio….cosa che per me ad esempio sarà necessaria visto il burst prestazionale con le cpu multicore che ha il compilatore intel….
io stesso non ricordo se tutto il codice che ho scritto è completamente standard ansi….e come puoi ricordartelo!!!
@tutti
Premetto che questo è un commento decisamente Off Topic.
Dal basso della mia ignoranza ifatti, non posso portare alcun contributo in merito al tema, ma ho comunque letto tutto l’articolo e TUTTI i commenti fino al num. 46.
Vorrei solo dire a coloro che hanno commentato relativamente ed esclusivamente al termine Extiguish (che evidantemente evoca concetti che scaldano gli animi) di non fermarsi solo a quella parola ma di considerare con ponderazione l’articolo nella sua interezza, dal contenuto del quale a me non sembra che l’autore ragioni per slogan.
Che poi, essendo una persona, come tutti abbia le sue preferenze/inclinazioni ci sta. Ma da qui ad etichettare l’autore dell’articolo (vedi commento num. 45 di goldorak) di faziosità manifesta ce ne passa.
E’ brutto vedere scadere così le discussioni.
E scadono, scadono proprio, perchè se il proseguio dei commenti è mirato ad affossare la credibilità dell’autore piuttosto che sviluppare il discorso in modo costruttivo la qualità degli stessi precipita, e di conseguenza anche la fuibilità.
Ed è una cosa triste dato che, a parte gli articoli stessi, ulteriori contenuti informativi accessibili tramite questo blog sono proprio generati dai commenti degli utenti.
Scusate lo sfogo.
x banryu
concordo in pieno con te
in quanto se da un lato gcc è un compilatore prezioso per tutto il mondo informatico dall’altro non è e non deve essere esente da critiche….e l’autore CDMAURO ha diciamo messo un po’ il dito sulla piaga….
@Cesare Di Mauro
Mi sembra davvero poco plausibile che gli autori di GCC abbiano introdotto delle estensione per “Estinguere” altri competitor.
Ribadisco che è stata una scelta scellerata introdurre queste estensioni, oltre tutto si sta dimostrando controproducente per molti prodotti open come Linux, che ora di fatto è compilabile solo con GCC.
Purtroppo chi ha fatto questa scelta non si è reso conto degli effetti che avrebbe avuto e, a sua parziale discolpa, è stato influenzato dal fatto che anche molti altri produttori di compilatori avevano introdotto estensioni per comodità personali.
Tuttavia pensare che gli autori di GCC abbiano seguito questa strada per estromettere (estinguere) possibili competitor mi sembra un ipotesi molto fantasiosa, oltre che autolesionista come stiamo vedendo.
è un po’ il grande tema della differenza tra gli standard de iure e de facto.
Le organizzazioni, di fatto (:D), lavorano per procedure spesso e volentieri burocraticamente lunghe, quando in realtà nel frattempo il mercato si evolve e fa le sue scelte.
Uno degli esempli classici è il Web (questo non esime dal fatto che MS in virtù della sua posizione di mercato abbia dormito sonni eterni e si sia svegliata, casualmente, solo quando quello stesso mercato è stato messo in pericolo dai nuovi agguerriti concorrenti), ma se ne potrebbero fare tanti altri.
GCC, come Linux, è un progetto mastodontico e siccome, di fatto, è praticamente uno standard, taglia spesso e volentieri le gambe a tutto il resto.
Hai voglia a dire “ma le estensioni (che non sono il risultato di iter standard) sono un plus, se vuoi non le usi”.
Sì ma se quel progetto x non compila e non può essere portato perché ci sono…poi possiamo parlare di una copartecipazione di responsabilità, sia tra chi ha permesso che ci fossero quelle estensioni e chi le usa predicando allo stesso tempo i vari dettami OSS.
E su questo penso Cesare abbia voluto mettere l’accento e sull’incoerenza di questo atteggiamento.
D’altra parte se non ci fosse l’errore a monte, ovvero fare la scelta progettuale di consentire ed accettare l’uso di quelle stesse estensioni, il problema non si porrebbe mai e potremmo parlare davvero di standard senza se e senza ma.
Qui sta il peccato originario di GCC.
La parola extinguish in questo caso non è certo da interpretare in modo “evil” come lo è stato per le azioni di Micrososft.
E’ da interpretare invece come conseguenza dello status quo, ossia è la conseguenza del fatto che oggi un nuovo compilatore si scontrerebbe per forza col fatto che il “mercato” è dominato da GCC e dalle sue estensioni.
Quindi sarebbe costretto non solo ad implementare la specifica (ovviamente), ma anche a lavorare per rincorrere la compatibilità con GCC per poter avere un minimo di considerazione.
Si capisce che non tutti sarebbero in grado e infatti sta ancora GCC in giro.
Clang è emerso e continua ad emergere fondamentalmente perchè ha Apple alle spalle che investe denaro e quindi gli sviluppatori possono occuparsi anche della compatibilità con GCC.
E non solo, avendo una personalità forte alle spalle possono permettersi di interagire proficuamente con i vari team di sviluppo, ricevendo considerazione, per poter eliminare/reimplementare/arginare i pezzi di codice strettamente dipendenti da GCC.
Immaginate invece un piccolo sviluppatore, o un piccolo team che si trovasse a chiedere al team di Qt di reimplementare una parte di codice o nel doverlo fare per contro proprio per poter inviare la patch. Abbastanza improbabile.
@Griso:
Non è questione di voglia. E’ una situazione che sicuramente non s’è voluta creare di proposito, ma gli effetti sono quelli: GCC sta strangolando i compilatori alternativi.
D’altra parte sarebbe dovuto esser prevedibile. Nel momento in cui introduci un’estensione, non ti poni il problema di stare andando fuori dallo standard? E che, di conseguenza, permetterai ad altri di realizzare progetti non standard?
Io penso che almeno una riflessione avrebbero dovuta farla. E se non l’hanno fatta, beh, vuol dire che le capre sono più di quelle che si pensa…
Era nel diritto di Microsoft oppure no? Chiariamo questa cosa una volta per tutte, visto che alle mie domande in merito “stranamente” mancano puntualmente le risposte.
Dalle risposte arriveranno le relative, banali, conseguenze.
Poi se non si vuol rispondere perché le domande sono troppo scomode, non posso che prenderne atto.
@goldorak:
Quindi è legittimo o no fare a meno degli standard, e andare per la propria strada? Rispondi a questo, e vedrai che tutti i nodi arriveranno al pettine.
Quindi bisogna utilizzarlo per forza? Anche quando il codice prodotto è di così scarsa qualità (vedi back-end 68000 e i ciclopici tempi d’esecuzione di AROS/68K)?
Infatti non ho portato opinioni, ma FATTI. E altri lettori ne hanno portati altri. Riesci a compilare Linux con CLang? Senza nessuna patch, ovviamente. Se la risposta è no dovresti cominciare a chiederti il perché…
Come dicevo a Griso, non è che il GCC abbia operato appositamente l’EEE. Ma nei fatti, grazie alla fuoriuscita dagli standard, il risultato è quello. E non puoi negarlo, esempi alla mano.
Ne ho fatto sempre una questione di principio, e questo lo sai bene, visto che l’ho scritto.
Il GCC è solo un esempio di un prodotto frutto di una comunità che non perde occasione per puntare il dito contro i soliti noti per roba come EEE & rispetto degli standard, e alla fine provoca gli stessi problemi. In buona fede, s’intende e lo penso veramente, ma non cambia la sostanza.
E la sostanza è: o si rispettano e si chiede di rispettare SEMPRE gli standard (quindi vale PER TUTTI), oppure no. E in quest’ultimo caso non mi si venga a parlare di EEE.
Coerenza. Pura e semplice coerenza.
@Marco:
Non mi sembra che siano mancati FATTI e argomentazioni.
Poi se vogliamo buttarla sul classico pattern: “è schierato, gli sta antipatico questo e quest’altro”, beh, ci sono abituato.
Ma ovviamente preferirei che si entrasse nel merito dell’articolo. :P
@goldorak:
Perché dovrei criticarli? Soltanto per fare un piacere a te?
Ribadisco che le mie critiche sono squisitamente tecniche. E di coerenza.
E quindi, rispondi: sei per il rispetto assoluto degli standard, oppure no? Da qui puoi trarre le tue considerazioni.
Su come la penso, se non fosse chiaro, lo ripeto nuovamente: da programmatore gradirei un rigoroso rispetto degli standard. Quindi da parte di TUTTI. E mi dà particolarmente fastidio chi predica bene e razzola male, PRETENDENDO il rispetto degli standard soltanto per chi non sta loro simpatico, e nascondendo sotto il tappeto i problemi che si hanno in casa.
Fa lo stesso, avevo capito, ma ti correggo: faccio la crociata contro i falsi moralizzatori. E contro chi antepone la fede alla tecnica.
@Andrea Del Bene:
Sono convinto della loro buona fede nello specifico, ma da tecnico non posso che cogliere gli effetti negative di certe scelte ampiamente discutibili, come ho già scritto anche prima.
Penso ci sia stata molto miopia, e adesso che c’è un fiorire di alternative a GCC (anche OpenBSD, se non erro, sta lavorando a un proprio compilatore per distaccarsi da GCC, principalmente per gli enormi tempi di compilazione, e secondariamente per la licenza) cominciano a emergere le magagne.
Per quanto mi riguarda, lo ribadisco, ne faccio una questione di principio. E di coerenza. E mi sembra di aver portato fatti e argomentazioni di carattere squisitamente tecnico allo scopo.
D’altra parte se mi limitassi a dire la mia e basta, diventerei banale e ovviamente ampiamente attaccabile dal primo che pass. :P
Infine non posso che concordare coi commenti degli altri lettori, a cui non ho risposto, ma di cui condivido riflessioni e considerazioni. ;)
Ovviamente sì. Ma nello stesso tempo no.
Se quantomeno avesse rispettato lo standard prima di estenderlo uno avrebbe potuto decidere se usare o meno le estensioni. Ma con l’implementazione volutamente “bacata” dello standard HTML o la volontà di implementare le stesse estensioni presentate dagli altri in maniera completamente diversa la questione è diversa.
MS ha voluto fare in modo che il suo prodotto fosse diverso da quello della concorrenza e avendo il monopolio negli OS, ben sapeva che da lì ad avere il monopolio del Web con un prodotto dato gratuitamente e non svincolabile dall’OS ne avrebbe avuto il pieno controllo.
Il problema segnalato, quello della deviazione dallo standard, è presente. Essendo appunto una estensione ad esso è evidente.
Ma la scelta di volere o meno far in modo che il proprio SW sia compilabile con un compilatore piuttosto che un altro è a discrezione del programmatore. Se il programmatore è “uno zappatore di codice” non vedo quale problema possa essere imputato agli autori di GCC.
E’ come venire a lamentarsi, o addossare colpe a MS, se progetti Open Source come eMule funzionano esclusivamente sotto Windows e addirittura usino non solo il compilatore della MS, ma addirittura le loro librerie a pagamento (le MFC).
La scelta l’ha fatta il programmatore. Vuoi usare il suo codice e vedi che portarlo su ARM con GCC sotto Linux è praticamente impossibile?
Allora armiamoci e andiamo contro a MS che ha fatto il compilatore non standard con librerie non standard e che addirittura non girano sotto Linux!
Senza contare la bellissima politica di MS che ad ogni versione del proprio IDE non compila più le applicazioni fatte con le versioni precedenti (provate a compilare eMule, la cui implementazione originale era fatta con VS2003 con VS 2005, VS2008 o VS2010). In questo caso che si fa? Non si fa un articolo sulle continue variazioni che MS introduce nei suoi IDE che rompono la compatibilità a livello di codice sorgente (!) con le versioni precedenti?
E siamo sicuri che il compilatore di MS compili il codice ANSI-C senza problemi?
@Nessuno gli articoli sulle politiche Microsoft si sono fatti e si fanno ancora quando serve.
Il punto è che Microsoft non va a predicare il rispetto degli standard e in ogni caso ha pagato più volte per le sue pratiche anti concorrenziali.
Talvolta proprio scontrandosi con la FSF o analoga “istituzione”, per esempio per il rilascio delle specifiche di netbios o qualcosa del genere (non ricordo di preciso quale tecnologia fosse) per permettere l’interoperabilità in ambiente business.
Invece la FSF & Co. più volte sbraitano (giustamente intendiamoci( sul rispetto degli standard, l’interoperabilità eccetera.
Però di fatto GCC va oltre gli standard e risulta non pienamente interoperabile con altri compilatori per questo motivo.
E’ questa la maggiore contraddizione che si vuole evidenziare.
“Poi se vogliamo buttarla sul classico pattern: “è schierato, gli sta antipatico questo e quest’altro”, beh, ci sono abituato.”
Pure io ;-)
“Ma ovviamente preferirei che si entrasse nel merito dell’articolo. :P”
Il fatto l’hanno già sollevato in molti. Che le estensioni unilaterali siano altamente deprecabili ci trova più o meno tutti d’accordo (fermo restando l’estrema immobilità delle revisioni dello standard, tendendi a frenare eccessivamente lo sviluppo), come pure il fatto che GCC abbia grossi difetti e limiti (così come grandi meriti e pregi).
Che il tutto venga additato come pratica “EEE” è falso e nemmeno opinabile, dato che parliamo di free software e non di brevetti.
Innanzitutto GNU non ha scopo di lucro nel proporre estensioni allo standard del linguaggio. Lo fa perché la comunità lo chiede e lo propone.
Secondo, essendo free software e open source, le modifiche possono essere facilmente integrate in altri compilatori, qualora volessero adeguarsi alla sintassi “GCC”. Infatti il codice non è coperto da brevetti e chi volesse reimplementarlo non potrebbe temere azioni legali.
Sempre per lo stesso motivo inoltre chiunque è liberissimo di forkare GCC per crearne una versione “extensionless”, o più semplicemente evitare di usarle.
Marco
Runaway ha scritto : “Però di fatto GCC va oltre gli standard e risulta non pienamente interoperabile con altri compilatori per questo motivo.
E’ questa la maggiore contraddizione che si vuole evidenziare.”
Per la miseria, un po’ di onesta’ intellettuale non farebbe male.
GCC e’ pienamente interoperabile con altri compilatori se uno si limita ad usare le specifiche standard del C, che essendo appunto standard dovrebbe essere implementate da tutti i compilatori C.
Io ancora non ho visto un programma ANSI C essere compilabile su GCC e non su altri compilatori che implementano lo standard in questione.
Quindi ripeto, criticare l’Embrace Extend si puo’ fare ma allora e’ un discorso che colpisce tutta l’industria del software nessuno escluso. Ma fare passare il GCC come una Microsoft del mondo open source e’ RI-DI-CO-LO. E sconcertante leggere alcuni interventi. Se non diamo peso alle parole possiamo dire tutto ed il contrario di tutto. Se io vado in america, e chiamo un afro-americano un nigger non importa se il termine all’orgine non era razzista. Sta sicuro che non si limitano a guardarmi male. Le parole hanno dei significati, e non si puo’ e non si deve stravolgerne il senso. La politica del Embrace Extend Extinguish e’ specifica di Microsoft. Quel piccolo Extinguish e’ stato all’origine di moltissime cause legali e di verdetti di colpevolezza di Microsoft. Quindi non e’ una parola che si puo’ buttare cosi’ in un discorso come se niente fosse.
E come dare dei criminali a coloro che portano avanti il progetto GCC.
La questione dei standard di fatto e di iure come qualcuno ha detto e’ presente. Ma questo non centra niente con quel famoso termine Extinguish. Ecco perche’ sarebbe stato auspicabile che CDM avesse cambiato il titolo dell’articolo in “Embrace Extend…anche da GCC”
Ma forse allora la sua analisi condivisibile o meno non avrebbe portato a una discussione infiammata. Si lo so sono cinico.
goldorak
qui non si parla di architetture, si parla di compilatori
quelli che a scuola o in università (ah beata ingenuità dei decenni andati) ti insegnano essere strumenti tramite e non target, e per questo inerentemente rimpiazzabili (salvo poi scontrarti con la realtà e scoprire che così non è, magari quando ormai è troppo tardi per migrare il tuo progetto a un altro compilatore a causa di sopraggiunti limiti o problemi con quello su cui lo sviluppo è stato avviato… )
parti con il tuo progetto con un certo compilatore.
poi vedi che quello che hai scelto ha dei bug critici risolti nella versione corrente, che però introduce regressioni di qualche tipo (l’ architettura che ti serve viene deprecata, è rotta la compatibilità a livello di ABI, si introduce qualche nuovo bug altrove, l’ efficienza del codice generato è minore, ecc)
non è così fuori dal mondo voler a un certo punto della vita di un progetto, sostituire quello che “dovrebbe” essere un tool come un altro, con uno equipollente – ma avendo magari usato delle estensioni non standard del linguaggio o degli hint (magari senza sapere che fossero tali (*)), non puoi …
*: ho visto molti formarsi direttamente sulla versione del C supportata da GCC ( a sto punto direi quasi “GNU C”) pensando implementasse “semplicemente” lo standard C ratificato – per poi scoprire amaramente di aver deviato da questo, e di dover praticamente disimparare buona parte di quello che avevano appreso
effetti collaterali della monocultura GNU di cui sopra, si può dire…
hai le prove o è una tua supposizione?
a me risulta che Apple si sia interessata a LLVM più che altro per la capacità di fare jit e ottimizzazione dinamica a runtime anche su codice unmanaged (come quello dello stack grafico opengl, scritto in C) diversamente per dire , dalla JVM – motivo per cui sarebbe stato impiegato a partire dallo stack grafico per eliminare i branch dinamici ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html) – più che per blindare i backend di generazione del codice che mi risultano essere ancora sotto BSD insieme ai componenti di base, al jit ecc
la licenza di LLVM è BSD da che il progetto è nato come *tesi universitaria* dieci anni fa (quindi molto prima che apple assumesse l’ autore, chris lattner, nel 2005 e sovvenzionasse lo sviluppo) – e si sa che la prassi universitaria è di porre il codice sotto licenze liberali perchè sia i privati che le aziende avrebbero diritto diritto di fruire dei prodotti della ricerca universitaria, avendola già sovvenzionata con tasse o donazioni …
e mentre i sostenitori del sw aperto si preoccupano che quelli impegnati/coinvolti nella piattaforma di sviluppo (quattro gatti) giochino alla pari, tutti gli altri si preoccupano che quello che usano, continui a funzionare – e nel frattempo il mondo va avanti…
l’ unico perchè attendibile dell ‘esistenza di llvm (clang è nato dopo per sopperire alla mancanza di un frontend nativo c/c++) è l’ abstract del paper originale di chris lattner, qualunque altra cosa è fuffa partigianesca
eleganza architetturale, avere un runtime unificato e un’ IR bytecode tali da supportare in traduzione linguaggi managed così come unmanaged (od anche afaik ML binario), possibilità di nuovi tipi di ottimizzazione interprocedurale e interassembly, e di integrare assembly (moduli) in linguaggi terogenei senza bisogno di binding – sono tutte cretinate, e il sw serve solo uno strumento di propaganda politica, scemo io a non rendermene conto… :-)
sì ma per quanto ancora? ad ogni release viene deprecata qualche ISA, e tra quelle pur supportate quelle non mainstream languono sempre di più (giusto ieri un commento su osnews faceva “the 68k port gets worse by the minute”)
Pippo
purtroppo ultimamente non mi riesce granchè bene di spiegarmi, ma in quella parte volevo fare più un appunto concettuale che non di efficienza :\ inframmezzare direttive e opzioni indirizzati al compilatore / parser (gli hint) a comandi indirizzati alla cpu (per quanto astratti sotto forma di linguaggio di alto livello) crea una commistione concettuale di cosa sia “linguaggio” cosa “altro”, in chi prende in mano il sorgente per rielaborarlo od anche per imparare a programmare (e non sono pochi a voler imparare leggendo codice -foss, con buona probabilità “roba” GNU- altrui, piuttosto che manuali o -GASP- documentazione ufficiale) – oltre a vincolare il codice a quello specifico compilatore
RunAway #30
scusandomi per la brevità (mi si è fatto tardi), ti ringrazio per il primo paragrafo, concordo sul secondo :)
[quote]Invece la FSF & Co. più volte sbraitano (giustamente intendiamoci( sul rispetto degli standard, l’interoperabilità eccetera.
Però di fatto GCC va oltre gli standard e risulta non pienamente interoperabile con altri compilatori per questo motivo.
E’ questa la maggiore contraddizione che si vuole evidenziare.[/quote]
La contraddizione più evidente in questo discorso è che l’open source non può innovare allora. Se GCC non può aggiungere estensioni per essere pienamente compatibile con gli altri compilatori (e a loro volta gli altri compilatori open source non potrebbero fare la stessa cosa), significa che non ci può essere innovazione, ma solo un adattarsi alle scelte degli altri.
Quello che viene ripetuto e non è tenuto conto (perché risolve il problema alla radice e quindi farebbe decadere tutto questo discorso) è che le estensioni sono:
1. opzionali
2. documentate
3. la loro implementazione è visibile
4. liberamente copiabili
Se GCC fa una estensione che viene usata è perché qualcuno la ritiene utile. Se più programmatori la ritengono utile è perché è UTILE a dispetto della rottura della compatibilità con lo standard ANSI-C che, ricordo, è l’unica modalità di programmazione che consente la interoperabilità. Se gli altri compilatori non la ritengono utile, malgrado queste siano facilmente integrabili, allora significa che preferiscono mantenere il proprio compilatore limitato agli standard, con buona pace di tutti coloro che non programmano in ANSI-C.
Faccio notare la parole “limitato”. Essere aderenti ad uno standard non significa necessariamente doverne essere limitato.
Se chi programma è consapevole di quello che fa, allora non ha senso lamentarsi. Se chi programma non sa quello che sta facendo (quindi non si preoccupa se rispetta o meno lo standard) non ha motivo di lamentarsi successivamente se il codice non è interoperabile.
Più propriamente l’attacco all’uso di codice non standard andrebbe fatto ai programmatori di Linux e delle sue librerie, non al compilatore, dato che si presume che l’intenzione originale di rispetto dell’interoperabilità non sia a carico dello strumento ma dello sviluppatore che ne fa uso.
@goldorok “Per la miseria, un po’ di onesta’ intellettuale non farebbe male.
GCC e’ pienamente interoperabile con altri compilatori se uno si limita ad usare le specifiche standard del C, che essendo appunto standard dovrebbe essere implementate da tutti i compilatori C.”
Ehm ti ricordo che i primi a non usare il solo c standard sono proprio molti sviluppatori GNU.
E infatti per esempio FreeBSD è da un pezzo che è compilabile con clang e pure self hosted eppure i problemi permangono proprio sui port, che sarebbero per la maggior parte proprio software gnu o comunque proveniente dal mondo linux.
E linux stesso proprio perchè pieno di codice strettamente dipendente da gcc non è stato fin da subito compilabile ed è servito un lavoro congiunto tra patch del kernel e cose da implementare in clang.
Attualmente i problemi che ha clang sono per lo più proprio per software open che non usa solo gli standard.
Per quanto riguarda l’extinguish ho già scritto come secondo me andrebbe interpretato.
diciamo che tra clang e gcc preferisco di gran lunga il secondo…
ad ogni modo complimenti a cdmauro per aver scatenato questo putiferio….
mi sto divertendo da matti a leggerlo…
@Nessuno:
Qui ci sono un po’ di cose da chiarire. Prima di tutto, e come puoi vedere anche da quest’articolo, trovare qualcuno che rispetta integralmente gli standard è cosa rara.
Seconda cosa, gli standard (suppongo ti riferissi al CSS nello specifico, perché i tag HTML disponibili all’epoca erano stati implementati) erano ancora in draft e bacati (tant’è che il W3C intervenne per correggerli).
Terzo, le estensioni, e pure consistenti (per citare i casi più noti: FONT, FRAME e JavaScript) ci sono stati anche da parte di altri. Ossia NetScape. E nessuno s’è stracciato le vesti, mi pare; al contrario.
Quarto, non si trattava di caratteristiche riservate / proprietarie, e quindi non implementabili dagli altri. Per definizione, visto che parliamo di web, si tratta di roba ampiamente disponibile a tutti (altrimenti io, web designer, come farei a utilizzarle?). Tant’è che la rivoluzione che ha portato al cosiddetto web 2.0 si chiama AJAX e… l’ha portata Microsoft grazie all’introduzione del componente XMLHttpRequest.
Questo se vogliamo dare il giusto posto e valore alle cose di cui parliamo. Purtroppo quando si parla della guerra dei browser troppo spesso il pensiero si ferma alle leggende metropolitane che circolano, senza analizzare la questione contestualizzandola in maniera precisa e alla luce dei fatti.
Ma infatti nulla da dire: se gli standard non sono importanti e ognuno fa quello che vuole, allora amen. E viene meno anche il concetto stesso di EEE.
Proprio Emule no, ma con altri progetti non m’è capitato.
Comunque prova a prendere un progetto disponibile per AmigaOS/68K e a compilarlo con le ultime versioni di GCC. Se ci riesci.
Mal comune, mezzo gaudio? O:-)
Ha già ampiamente risposto RunAway (che da tempo ha centrato i termini della questione, e continua a esplicitarlo in maniera più che chiara), ma aggiungo: cui prodest (e due :D)? Se seguire gli standard non è importante, non lo è neppure la retrocompatibilità, che… tra l’altro manca pure a GCC.
@Marco:
Non ho mai parlato di “free software” né tanto meno di brevetti. Ho sempre tirato in ballo fatti, definizioni, questioni di principio, e coerenza.
Il lucro è ininfluente ai fini del discorso, perché le estensioni possono arrivare da qualunque compilatore, sia esso open o closed, free o no. E sono sempre e soltanto le estensioni a creare problemi, fino ad arrivare a casi di EEE.
Non è coperto da brevetti, ma da licenze sì. E se il mio compilatore è BSD, non posso mica prendere a piene mani dai sorgenti del GCC, perché la GPL è una licenza virale, e mi costringerebbe a rilasciare il codice come tale.
D’altra parte non vedo perché si debba per forza di cose implementare delle estensioni fuori standard.
Ma intanto la frittata è fatta. E continua ad arrecare danni.
@goldorak:
E questo chi l’ha negato, scusa? Per caso mi hai visto fare delle preferenze? No, perché, e lo ripeto per l’n-esima volta, ne faccio sempre una questione di principio.
A me le estensioni non piacciono, perché da sviluppatore preferisco affidarmi alle garanzie che uno standard dovrebbe darmi. E anche se non me le dà al 100%, generalmente mi mette in guardia su questioni che sono lasciate alle singole implementazioni (di questo ne ho parlato in un altro articolo).
Detto ciò, la questione deriva da un’altra, a cui non vuoi rispondere: il rispetto degli standard. Da questo segue la legittimità o meno di una politica di EEE (sia essa consapevole o meno). Non si scappa.
E il motivo per cui non rispondi è lapalissiano: perché finiresti o per dare ragione ad aziende come Microsoft, oppure torto a GNU/FSF et similia. Ma non puoi salvare capre e cavoli: le due questioni sono mutuamente esclusive, e non c’è via d’uscita: sei con le spalle al muro.
Certo, puoi continuare a evitare di rispondere e girarci attorno, come stai facendo finora, ma ciò lascia il tempo che trova, visto che hai anche il coraggio di tirare in ballo l’onestà intellettuale. Solo che predicare bene e razzolare male mostra anch’esso ben poca coerenza…
La politica EEE di Microsoft è legittima nella misura in cui gli standard diventano carta straccia per tutti, e nessuno si sente in dovere di rispettarli.
Detto ciò, la definizione di EEE non l’ho scritta io, e se chi l’ha scritta così ha pensato di appiccicarla in via esclusiva a Microsoft, beh, s’è fatto male i conti.
Perché l’unica differenza che è emersa (e che ho ammesso io stesso a più riprese; se non è onestà intellettuale questa…) è l’intenzionalità o meno. Ma si tratta di quisquilie di fronte agli oggettivi risultati finali, che permettono di parlare di EEE, appunto.
Perché i fatti rimangono quelli: a causa delle estensioni di GCC tanti progetti non sono compilabili con altri compilatori, anche gratuiti e/o open source. GCC, di fatto, ha estinto la concorrenza (vedi link ad AROS / AmigaOS dell’articolo, oppure alla questione Linux & CLang/LLVM che ha riportato RunAway) perché i programmatori sono stati troppo ben abituati ad andare fuori standard.
Da chi, paradossalmente, ne invoca il rispetto un giorno sì, e l’altro pure.
Se la questione è presente, rispondi e dì chiaramente il tuo giudizio in merito. Gli standard si devono seguire, sì oppure no. E tagliamo la testa allo gnu una volta per tutte…
La mia analisi si basa proprio sulla constatazione dei fatti citati e che portano immancabilmente all’EEE. Se così non fosse, il titolo sarebbe stato diverso. Siccome ritengo di aver portato elementi consistenti e tangibilissimi, non vedo perché avrei dovuto cambiarlo.
Che poi si scatenino flame, capita. D’altra parte quando si toccano certi argomenti succede, e non di rado. Succede quando si parla di Microsoft, di Apple, di Google, FSF, open source, closed source, ecc.
Purtroppo difficilmente si riesce a discutere in maniera distaccata e prettamente tecnica su questioni che stanno a cuore ad alcune persone.
Vista l’ampia varietà di temi, l’alternativa sarebbe chiudere bottega. Ma non mi pare molto razionale, come soluzione. :P
@Nessuno:
Ci sono compilatori che campano tranquillamente seguendo gli standard.
Per la mia tesi di laurea il codice del decoder JPEG 2000 l’ho scritto addirittura in un sottoinsieme stretto dell’ANSI C89, e… compilava e funzionava senza battere ciglio (né warning) su Visual C 6, cygwin con GCC (non chiedermi la versione, perché non lo ricordo), e il compilatore di STMicroelectronics per la sua architettura LX.
Se avessi usato qualche estensione non sarebbe stato portabile ovunque.
Sì, sono io programmatore a decidere come scrivere codice, e se usare uno standard o meno. In ultima analisi il problema è sicuramente mio. Ma, come già detto anche da altri, avere a disposizione delle estensioni, per giunta abilitate di default, lascia cadere troppo in tentazione. Coi risultati che poi si vedono…
La 3 è ininfluente, e la 4 non è sempre vera (vedi i problemi di licenza).
Esattamente. E si vede pure che i programmatori riescono lo stesso a tirare fuori il codice. Codice che sarà molto più facilmente portabile, con innegabili vantaggi.
La portabilità avrà pure un qualche valore, no? E’ una cosa che sento sbandierare spesso, anche se non in quest’occasione. :P
Lo stesso vale per chi utilizza Visual Studio o un altro compilatore e decide di utilizzare delle estensioni e/o peculiarità della piattaforma. La colpa primaria è dei programmatori, e su questo non ci sono dubbi e mi sembra che siamo tutti d’accordo.
Ma a questo punto, visto che gli standard non sono importanti, cade anche il concetto di EEE, visto che tutto diventa legittimo. Sei d’accordo su questo?
@homero:
Non sono della stessa idea quelli che si aspettavano grandi cose dal porting di AROS per 68000, che si attende da 17, lunghi, anni, e del quale al momento si nota la cronica mancanza di velocità.
Questo per dire che l’articolo avrà pur scatenato un putiferio, ma dietro c’è gente che dai primi entusiasmi è passata alla delusione. Ed è per questo che si cercano alternative a GCC, anche se è difficile a causa dei problemi citati (ma sono fiducioso per il futuro, visto che LLVM promette bene e uno dei mantainer s’è mostrato molto ben disposto a dare una mano per il back-end 68000).
Poi a me il putiferio non piace: preferisco una discussione dai toni morbidi e prettamente tecnica.
Certamente non mi piacciono le cose “scontate”, e spero che, almeno da questo di vista, i lettori apprezzino e non si annoino. :D
“Non ho mai parlato di “free software” né tanto meno di brevetti. Ho sempre tirato in ballo fatti, definizioni, questioni di principio, e coerenza.”
Non vedo questioni di principio e coerenza, trattandosi appunto di free software. Un team di sviluppatori di GCC decide di accogliere le proposte della comunità e introdurre delle estensioni allo standard.
Non essendoci fine di lucro né l’intenzione di annullare la concorrenza (fino a prova contraria) non si può parlare di EEE, ma solo di uno sforzo per rendere GCC un prodotto migliore.
Riporto la definizione di Wikipedia (se ne hai una migliore fammelo sapere):
“entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences to disadvantage its competitors”
A GCC manca sia il “proprietary” (vista la natura FLOSS del progetto) sia il “to disadvantage its competitors” (non c’è il fine di lucro).
Il “proprietary” non è applicabile a tutti i casi elencati nella stessa pagina, visto che si trattava di informazioni pubbliche e che altri avrebbero potuto utilizzare (di questo ne avevo già parlato nella risposta a Nessuno). Se ne dovessimo tenere conto come elemento fondante dell’EEE, questo praticamente sparirebbe.
Il lucro non c’entra col fatto che la concorrenza possa essere svantaggiata. Altrimenti l’open source non avrebbe nulla da temere da Microsoft, no? Visto che per lo più non parliamo di lucro, non sarebbe configurabile come concorrente.
Poi la strategia adottata è la seguente:
Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the ‘simple’ standard.
Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
che poi era quanto aveva riportato anche Dubbioso, ed è applicabile anche al GCC, appunto, come avevo già detto (a causa della diffusione delle sue estensioni, “strangola” i compilatori concorrenti).
Infine, sulla coerenza, il concetto è che non si può pretendere il rispetto degli standard e al contempo estenderli (e nemmeno implementarti in toto). Delle due l’una…
“che si cercano alternative a GCC”
senti cdmauro l’altrenativa a GCC non è certo LLVM…
quello che molti non riescono a comprendere è che prima di ogni altra cosa bisogna partire dall’hardware, ed in questo la intel ha lavorato in modo eccellente sui sistemi multicore quindi il suo compilatore si occupa di ottimizzare il codice per i processori di nuova generazione oltre che per le soluzioni in cluster e credo che se le cose continueranno cosi’ almeno nel mio sistema di sviluppo il gcc sarà sostituito dal compilatore intel…
per le lamentele di AROS su motorola 68000, mi cogli del tutto impreparato…nel senso che dal punto di vista di studio siamo sicuramente a un livello interessante di ricerca, ma dal punto di vista pratico a me di portare aros sul 68000 non me ne importa una mazza…
AROS lo vorrei vedere su tegra ad esempio….e quindi dovrei scegliere un compilatore adeguato per questo sistema….e gcc dovrebbe rullare su tegra….
in futuro proporrei un studio sui sistemi di sviluppo e sui compilatori in particolare…potrebbe essere interessante….specie se legati ad un sistema di debug e profiler…
@homero veramente pr quanto riguarda l’accoppiata backend + compilatore in ambito arm/x86/x86_64/ppc/ppc_64 ma principalmente arm e x86 l’alternativa più valida e da poco completa è proprio llvm+clang.
Come ho già scritto è production ready per objc e c, mentre l’implementazione del C++ è completa ma non production ready e infine l’implementazione del c++0x è in via di completamento.
Per quanto riguarda invece il solo il backend LLVM ha enormi potenzialità in quanto è molto facile aggiungere il supporto a diverse architetture.
Insomma gira che ti rigira l’alternativa più valida a GCC oggi è proprio clang/llvm c’è poco da fare.
@homer: alcuni link su AROS/68000 & AmigaOS li ho forniti. Inoltre se ti fai un giretto nelle varie comunità, vedrai che le aspettative sono grandi.
Questo a 25 anni dalla nascita del primo Amiga e a 16 dal fallimento della Commodore.
Poi che a te non freghi nulla ci può anche stare, ma non mi sembra una risposta “tecnica”.
Per i 68000 l’alternativa valida c’è, ed è Vbcc, sebbene sia rigorosamente legato al C. Ma… non è facile compilare i progetti esistenti, appunto.
Riguardo ad AROS su Tegra, dev’essere completato il supporto agli ARM prima (so che ci stanno lavorando, perché è un altro ambizioso obiettivo che vogliono raggiungere).
Concordo con RunAway su LLVM: è un bel progetto e, da quel che ho visto finora, snello e facilmente scalabile.
Lo hanno usato persino per implementare un JIT nella virtual machine di Python.
Promette davvero bene.
“ed è applicabile anche al GCC, appunto, come avevo già detto (a causa della diffusione delle sue estensioni, “strangola” i compilatori concorrenti).”
Rimane un costrutto basato su un assurdo: il programmatore è libero di non usare le estensioni e ognuno è libero di modificare i sorgenti di GCC.
Le estensioni sono state introdotte democraticamente in base alle esigenze e alle richieste della comunità di sviluppatori che usano GCC, non per un becero intento commerciale (dato che parliamo di free software).
In base al tuo ragionamento, tutti i nuovi linguaggi derivati dal C (e non solo) e non standardizzati sono tentativi di strangolare la concorrenza, costringendo (!!!) i programmatori ad usare un linguaggio di programmazione fuori standard.
@Marco devi guardare la cosa dal punto di vista degli altri compilatori non dello sviluppatore (se non nel caso di un port di un progetto che si trovasse con un altro compilatore).
Applicando il tuo ragionamento alle distorisioni degli standard di IE si direbbe: gli sviluppatori web sono liberi di non usare quei tag.
Peccato che quando li usano il problema ricade su chi sviluppa altri browser che devono fare un ulteriore lavoro per rincorrere la compatibilità.
Perfettamente d’accordo. As usual ormai. :P
@Marco:
Su questo eravano già d’accordo tutti, mi pare.
Questo che c’entra col nocciolo della discussione?
Non vedo perché adesso dovremmo mettere la democrazia in mezzo. Alla prossima passeremo alla politica, filosofia, religione, o ideologia?
Poi non mi pare molto democratico trattare in malo modo chi si lamenta della scarsa qualità del backend, che s’era pure offerto di dare una mano presentando delle patch per migliorare la situazione.
O sbattere la porta in faccia (per dirla pulita, perché son volate ben altre parole) a chi chiede di migliorare il supporto agli ARM per la libc.
Questo per citare due esempi molto noti.
Sappiamo bene che in queste comunità si crea una gerarchia, e chi occupa le posizioni si sente un mezzo dio in terra, col potere che si ritrova fra le mani.
Comunque ribadisco che per EEE & co. non s’è mai parlato di democrazia, e non vedo perché dovremmo farlo adesso.
Quindi in base alle proprie esigenze si possono apportare delle aggiunte agli standard. Bene.
Esattamente quello che hanno fatto altre aziende, Microsoft in primis, e alle quali, per una pura e semplice questione di coerenza, non si può rimproverare nulla a questo punto.
Anche questo non vedo cosa c’entri con l’argomento della discussione. Chi ha parlato di fine commerciale? E che c’azzecca il free software?
Stiamo parlando di estensioni a degli standard che provocano problemi di EEE, e ciò capita a prescindere dalle finalità, come sto cercando di dire da un pezzo.
Ma chi ha parlato di NUOVI linguaggi qui? La questione è ferma alle ESTENSIONI DI STANDARD ESISTENTI.
Un nuovo linguaggio è un nuovo linguaggio. Punto.
Mentre GCC è un compilatore C. Non un compilatore MyNewBeautifulProgrammingLanguage, anche se parte dal C come base.
D’altra parte, il primo paragrafo del primo capitolo del manuale del GCC parla chiaro:
“GCC stands for “GNU Compiler Collection”. GCC is an integrated distribution of compilers for several major programming languages. These languages currently include C, C++, Objective-C, Objective-C++, Java, Fortran, and Ada.”
Inoltre dal primo paragrafo del secondo capitolo:
“For each language compiled by GCC for which there is a standard, GCC attempts to follow one or more versions of that standard, possibly with some exceptions, and possibly with some extensions.”
E a seguire parla proprio del C e… delle relative estensioni.
Quindi NON di un nuovo linguaggio ispirato al C, come potrebbe essere Go, ad esempio. Ma di C, appunto.
E ciò, lo ripeto, ha generato e genera problemi di EEE.
Poi possiamo anche passare sopra gli standard, a questo punto della discussione a me sta benissimo. E allora buttiamo via anche il concetto di EEE perché, di fatto, non c’è motivo che esista e venga tirato in ballo. Sic et simpliciter.
“Applicando il tuo ragionamento alle distorisioni degli standard di IE”
Che sono nate con un chiaro intento commerciale dettato dalla politica aziendale notoriamente lucrosa (e ci mancherebbe!) di MS. E’ qui la differenza. Da una parte si modifica uno standard allo scopo di trarne un vantaggio, dall’altra lo si fa per accogliere delle legittime richieste di una comunità di utenti e sviluppatori.
Sì, ma a questo punto, chi se ne frega? Tanto gli standard sono carta straccia, no?
Interesse commerciale o no, è indifferente.
Non è che certe da “buone pratiche” possono esentare chi sviluppa prodotti non commerciali.
“Questo che c’entra col nocciolo della discussione?”
C’entra, perché vanifica il concetto di “exterminate”: un competitor potrebbe benissimo forkare GCC, modificarlo e ridistribuirlo.
“Poi non mi pare molto democratico trattare in malo modo chi si lamenta della scarsa qualità del backend, che s’era pure offerto di dare una mano presentando delle patch per migliorare la situazione.”
E questo cosa c’entra con la democrazia? Si tratta di un episodio isolato che non ha nulla a che vedere con il processo con il quale un board di rappresentanti traccia le linee guida dello sviluppo di un software.
“Quindi in base alle proprie esigenze si possono apportare delle aggiunte agli standard. Bene.”
In base alle esigenze di una comunità. E si, è un bene per fortuna. Perché gli standard, quelli si, vengono definiti attraverso macchinosi processi burocratici amministrati da “una gerarchia”.
“Stiamo parlando di estensioni a degli standard che provocano problemi di EEE, e ciò capita a prescindere dalle finalità”
Come già ribadito, trattandosi di FLOSS non si può certo definire EEE, per i motivi di cui sopra.
“E allora buttiamo via anche il concetto di EEE perché, di fatto, non c’è motivo che esista e venga tirato in ballo.”
Il concetto permane, sei tu che l’hai tirato in ballo a sproposito.
Dopo tutto sto casino mi (vi) porgo una domanda:
Ma cosa costava alla FSF, team di GCC, mondo open source in generale (e non solo visto che gcc è usato un po da tutti) sedersi ad un tavolo e ratificare una nuova versione della specifica del c o c++ e/o fare pressioni affinchè questa ratifica fosse fatta da chi di competenza?
Ossia perchè invece di sbattersene degli standard e introdurre estensioni a piacimento non si sono messi a lavoro per fare le cose a modo usando gli organi preposti a ratificare gli standard?
Apple è riuscita a ratificare OpenCL in 6 mesi, non pensate che forze congiunte avrebbero potuto estendere lo standard c in modo ufficiale (estendere non stravolgere) in tempi comparabili (anche fosse un anno o due sarebbero sopravvissuti lo stesso)?
Marco
le estensioni esistono perchè il programmatore di compilatori ha accontentato le richieste del programatore di applicazioni che a sua volta auspicava disporre di determinate feature (non importa se standardizzate o meno) perchè ne aveva bisogno o gli facevano comodo – ergo, il programmatore è sì libero, ma sarà anche disposto, a non usarle? dubito fortemente…
quindi creare e mantenere autonomamente un fork di un progetto enorme come quello… a che pro?
per meglio supportare degli standard formali a cui non dico nessuno, comunque un ridotto sottoinsieme degli sviluppatori di applicazioni, si attiene?
disabilitare feature che la gente ha richesto e usato, con il risultato che nessuno adotterà la mia versione priva di quelle feature?
RunAway
esattamente :)
ops, rispondevo al post #68 :o
sulla fsf non si può contare per estensioni come miglioramenti allo standard – basta vedere il caso della keyword export (utilità e problematiche inerenti della quale spiegate chiaramente, anche se in inglese, su http://insanecoding.blogspot.com/2007/06/can-you-name-c-compiler.html ) ratificata nello standard, ma sulla cui implementazione in GCC Stallman ha sempre posto il veto ed anzi ha fatto pressioni perchè fosse rimossa dallo standard…
“fare pressioni affinchè questa ratifica fosse fatta da chi di competenza”
La maggior parte sono sviluppatori, non avvocati. Penso che le pressioni siano state fatte e continuino a farle, ma si tratta di lunghi procedimenti burocratici (chi ha avuto a che fare con la ISO lo sa bene).
“Apple è riuscita a ratificare OpenCL in 6 mesi”
Grazie, che paragone! Apple ha avuto i propri buoni interessi a farlo, e ci avrà investito un bel po’ di risorse.
@j
Il fork era un’ipotesi paradossale, solo per dimostrare che l’extinguish non sussiste parlando di FLOSS.
io chiuderei il post e rimanderei la discussione ad un futuro articolo…qui non si capisce piu’ niente….
magari un articolo sui compilatori disponibili ed il cross platform programming….
Magari Cesare di Mauro dovrebbe fare un nuovo articolo ma incentrato sui concetti di standard di facto e di iure. Perche’ in fondo e’ di questo che si sta parlando, sebbene lui cerchi in tutti i modi di far deviare (e con successo appartentemente) la discussione sul Extinguish che in questo caso specifico centra come cavoli a merenda.
Uno standard rappresenta la linea base che garantisce una interoperabilita’ tra coloro che adottano lo standard.
Questo pero’ non vieta di estenderlo, consci del fatto che le estensioni sono un plus, qualcosa che va oltre lo standard. Chi vuole la interoperabilita’ rispetta lo standard altrimenti no. E chi vuole puo’ liberamente implementare le estensioni degli altri.
Questa cosa e’ un bene, perche’ e’ il processo attraverso cui lo standard si evolve. Guardate al HTML 5, tutti i browser implementano una serie di cose comuni, ma tra Opera, Firefox e Safari ci sono delle differenze. Alcuni implementano webgl, altri no. Ma questo non e’ un problema perche’ tutti implementano una base comune che e’ parte dello standard nascente. Poi semmai webgl dovesse essere ratificato vedreste sia Opera che Safari che IE implementarlo se vogliono continuare a rispettare lo standard.
Ora, la situazione del EEE e’ diversa perche’ sebbene i primi due termini riconducano al problema dello standard base/ estensioni; l’Extinguish e’ la fase che consente di prendere delle estensioni PROPRIETARIE CHIUSE, e rendere lo standard + estensioni PROPRIETARIE il nuovo standard. A quel punto ce’ una sola realta’ che detiene lo “standard” e nessun’altro puo’ piu’ innovare ne’ tanto meno garantire l’interoperabilita’ perche’ viene a dipendere da elementi estensioni segrete/proprietarie.
La differenza tra le due situazioni e’ talmente diversa che volerle accomunare e’ essere in malafede.
x goldrak
non parliamo di html5 e javascript….
IE si è sempre distinto per codificare i tags a modo suo e per introdurre tags aggiuntivi caduti nel dimenticatoio….
per non parlare del javascript clonato da vbscript…
tanto che ancora oggi un codice html deve essere scritto in 3 versioni per funzionare a dovere su tutti i browser in commercio e non parlo di piccolezze…ma sopratutto del posizionamento dei DIV nidificati e dei vari css property….io utilizzo html per l’uscita di qualunque file testo in modo da essere diffuso in intranet via web….e ad ogni uscita di una nuova versione del browser puntualmente faccio le prove del caso perchè puntalmente ci sono problemi da risolvere….
devo dire che ho trovato meno problemi nel gestire il codice C standard ansi che in genere una volta scritto compila richiede poche modifiche se non alcuna modifica….
in faturo credo che un articolo sui compilatori da usare in produzione e con i quali produrre codice che sia portabile per lunghi periodi 10 o piu’ anni reputo che sia un articolo molto interessante…
come diceva giustamente RunAway il problema si pone per i produttori / sviluppatori di altri compilatori, messi a mal partito dalla linea di condotta di un progetto incurante (quando non avverso) agli standard dall’ alto della sua base d’ utenza
in questo contesto la terza E può esistere eccome anche parlando di FOSS, il FOSS non è speciale, giacchè:
specifiche / design /standard implementati e qualità del codice dipendono dalle priorità e dalle capacità tecniche degli sviluppatori, mentre il regime di sviluppo (chiuso accentrato piuttosto che cooperativo aperto) dipende essenzialmente dai loro obiettivi (vendere sw in un caso, promuovere un ideale sociopolitico nell’ altro), ortgonali rispetto alle prime;
il sw non fa altro che svolgere le operazioni che il programmatore ha indicato nel suo codice, ma non ha nozione dei motivi che hanno portato alla sua scrittura
quindi qualunque progetto/prodotto sw va valutato sulle stesse basi con lo stesso metro, senza riguardi dovuti alle finalità o al modello di sviluppo seguito, che riguardano solo lo sviluppatore ma non tangono l’ utente – e d’ altra parte non vedo perchè riversare l’ idealismo o la spocchia politica che motiva la creazione di un progetto libero, su coloro che il sw lo usano solo per la funzione che svolge…
se poi la possibilità di forkare resta più teorica che pratica, e l’ unico risultato netto è appunto una situazione di svantaggio per alcuni a causa del comportamento del progetto…
@ homero : e’ vero questa non e’ una discussione sul HTML 5. Io pero’ l’ho dovuto citare perche’ pare che sia l’unico modo per far capire la differenza di fondo tra un Embrace Extend e un Embrace Extend Extinguish.
Sul secondo punto che hai citato, e cioe’ sul fatto che uno standard puo’ portare a dei problemi di interoperabilita’ come hai giustamente fatto notare nel caso dei browser sono d’accordo. E un problema, ma non e’ un problema del processo di standardizzione in quanto tale. Se i browser si comportano diversamente rispetto allo standard, significa che quest’ultimo introduce delle arbitrarieta’ nella implementazione. E uno standard sotto specificato. Questo non e’ un problema che si puo’ nascondere sotto il tappetto. Faccio un esempio, siamo tutti d’accordo che l’ANSI C e’ uno standard. Tuttavia se vai a guardare le specifiche del linguaggio ti renderai conto come alcune cose sono delegate alla discrezione della implementazione. E questo significa che diverse implementazioni seppur rispettando lo standard possano introdurre dei comportamenti sottili diversi. Questo problema pero’ e’ totalmente slegato dal concetto di Extinguish.
dopo piu’ di 80 commenti proporrei di rimandare il dibattito ad una nuova discussione….magari con esempi e modelli concreti…
“messi a mal partito dalla linea di condotta di un progetto incurante (quando non avverso) agli standard”
Incurante degli standard? GCC supporta correttamente ISO/IEC 9899:1990 e ISO/IEC 9899:1999, mi sembra che le tue affermazioni siano fuori luogo.
“E può esistere eccome anche parlando di FOSS, il FOSS non è speciale”
E invece si, dato che fa decadere l’extinguish.
“vendere sw in un caso, promuovere un ideale sociopolitico nell’ altro”
Vedi qui prima di spararle grosse, please:
http://gcc.gnu.org/steering.html
http://gcc.gnu.org/gccmission.html
“l’ idealismo o la spocchia politica che motiva”
Anche questa è bella! Non ti piace GCC? Non usarlo!!!
Non ti piace la linea di sviluppo che segue? Forkalo, copialo, aprilo, guarda come funziona e impara a scriverne uno tuo. Col free software si puo!
“l’ unico risultato netto è appunto una situazione di svantaggio per alcuni”
Per chi? Me lo spieghi? Se scrivi codice C90 o C99 puoi benissimo compilarlo con GCC e con tutti gli altri che rispettano lo standard. Se usi le estensioni proprietarie sei conscio che altri (o te stesso) non potranno compilarlo con compilatori diversi da GCC, che resterà software libero e scaricabile gratuitamente.
@Marco:
Avere i sorgenti o meno non serve a nulla nello specifico, come avevo già scritto a collione. E’ sufficiente la documentazione.
Ad esempio, un concorrente di Internet Explorer potrebbe benissimo implementare gli ActiveX: c’è ampia documentazione in merito, tant’è che… già da tempo FireFox permette di utilizzare anche quello di IE per il rendering delle pagine HTML: http://ieview.mozdev.org/ e http://ietab.mozdev.org/index.html
Idem per i tag HTML “fuori standard”: basta implementarli.
Ma l’esempio più noto è proprio il componente XMLHttpRequest, inventato da Microsoft ma che è stato poi copiato da tutti ed è divenuto la base di AJAX. E così via, per gli altri casi.
Difatti l’Extinguish non è legato alla presenza o meno dei sorgenti, ma alla diffusione delle estensioni di una soluzione, che hanno “annacquato” quella precedente e magari standardizzata, divenendo quella dominante e, quindi, il nuovo modello di riferimento a cui gli altri dovrebbero attenersi per rimanere competitivi.
Certo, la comunità di Debian chiede un aggiornamento della libc, UN (IL) singolo sviluppatore li manda a donnine (giusto per non scendere al suo livello di volgarità), e parliamo ancora di democrazia…
E a Stallman il consenso per portare avanti la crociata per l’eliminazione della keyword export (cosa che ritengo allucinante, ma il personaggio è ormai ben noto per le sue sparate) gliel’ha dato democraticamente la comunità degli sviluppatori GCC, o se l’è preso da solo?
Quindi se il comitato di uno standard è lento nell’agire, si può benissimo fare a meno di seguirlo e fare da sé. Chiarissimo.
Allora hanno fatto benissimo Microsoft e NetScape a estendere a loro piacimento l’HTML e a introdurre altra roba, visti i tempi biblici del W3C. E poiché la ratifica dell’HTML 5 avverrà soltanto fra 12 (DODICI) anni, chiunque può sentirsi libero di inventarsi qualunque soluzione che gli faccia comodo nel frattempo, anche se fuori standard.
La conclusione è che degli standard si può fare a meno, con tutte le conseguenze del caso, e a questo punto viene meno anche il concetto di EEE, come ho già detto.
I sorgenti non servono. Vedi sopra (e anche in precedenza).
Se gli standard sono carta straccia e ognuno può fare quello che gli pare, come tu stesso hai evidenziato (vedi sopra), di fatto non ha motivo di esistere.
Diversamente la mia citazione calza a pennello, come ho già ampiamente spiegato.
@RunAway:
“Il lato oscuro è più forte?”
“No, no, no, più rapido, più facile, più seducente.”
Potremmo anche parlare di ODF, per citare un altro caso. Standardizzato abbastanza velocemente, con la benedizione della FSF: http://www.fsf.org/campaigns/opendocument/
E’ chiaro che se c’è interesse si può spingere per velocizzare i tempi di un comitato. Evidentemente alla FSF non interessava (o magari non era conveniente) fare lo stesso con C e C++, e hanno preferito la comoda e rapida via delle estensioni proprietarie…
@goldorak:
E la differenza quale sarebbe, visto che gli standard, siano essi di fatto o ratificati da autorità competenti, non hanno comunque forza di legge?
Se non ti fosse ancora chiaro, il nocciolo della discussione è il RISPETTO di uno standard, non la sua NATURA.
E ho spiegato come si possa parlare benissimo di Extinguish, sebbene la cosa ti dia fastidio.
Se ognuno fa quello che vuole cade il concetto di EEE, come già detto.
Cosa non ti è chiaro del fatto che HTML 5 è il draft di uno standard?
Cosa non ti è chiaro del fatto che WebGL è il draft di uno standard?
Cosa non ti è chiaro del fatto che ISO C è il draft di uno standard?
Cosa non ti è chiaro del fatto che ISO C++ è il draft di uno standard?
Cosa non ti è chiaro del fatto che ISO C++0x è il draft di uno standard?
Cosa non ti è chiaro del fatto che le estensioni GNU all’ ISO C NON sono parte del draft dello standard?
Cosa non ti è chiaro del fatto che le estensioni GNU all’ ISO C++ NON sono parte del draft dello standard?
Non serve che le estensioni siano proprietarie e chiuse per parlare di EEE: lo si può fare benissimo senza questo pre-requisito (che tra l’altro hai introdotto arbitrariamente adesso).
Difatti di tutti i casi in cui si parla di EEE l’UNICO su cui potrebbe applicare quanto hai scritto è quello del protocollo Kerberos.
Nessuno t’impedisce di realizzare componenti ActiveX (o usarne di già esistenti), implementare nuovi tag HTML, il componente XMLHttpRequest, ma possiamo parlare anche di Java e J/Direct, ecc. ecc. ecc.
E permettimi: non si monta una storia come l’EEE per UN SOLO CASO.
E’ in malafede chi ignora sistematicamente i FATTI e le ARGOMENTAZIONI (tecniche) più volte ripetuti, e si sottrae puntualmente alle domande (aspetto ancora TUE PRECISE RISPOSTE, ma è chiaro ormai che non arriveranno mai, perché sono troppo scomode per te).
E’ in malafede (o ignorante, se non ne è genuinamente cosciente e/o a conoscenza) chi sbandiera lo spauracchio dell’EEE su situazioni in cui non è materialmente applicabile (visto che chiunque può implementare o utilizzare le estensioni di cui ho già parlato: ActiveX, tag HTML, ecc. ecc. ecc.).
@homero:
Dovresti contestualizzare, andando a vedere la situazione dell’epoca.
Scopriresti che lo standard HTML non era molto preciso (tant’è che il W3C è dovuto tornarci per sistemarlo) e IE è stato il PRIMO browser a supportare i CSS (ancora in draft, e comunque bacati, appunto).
Purtroppo principalmente per questioni di retrocompatibilità il codice non è stato aggiornato per fissare i bug presenti e implementare i tag correttamente.
@goldorak:
Peccato che l’esempio sia servito per dimostrare il contrario di quello che sostieni. Difatti HTML 5, seppure ancora non ratificato, è il draft di uno standard.
Mentre le estensioni GNU a C e C++ NO!
E la loro diffusione ha posto e pone grossi problemi ai compilatori (anche open source e/o gratuiti!) che hanno “semplicemente” deciso di attenersi agli standard…
Ma visto che dell’aderenza agli standard ce ne possiamo fregare (ma solo se siamo dalla parte del FOSS), allora ci sta tutto: http://www.youtube.com/watch?v=u-NRmT0R5eg
Soprattutto è un problema ben noto e chiaro, visto che lo stesso draft dello standard ne parla esplicitamente e mette in guardia i programmatori.
Per cui io posso anche infilare codice assembly in mezzo a quello C o C++, perché lo standard me lo consente tramite l’apposita keyword, pur sapendo che funzionerà magari soltanto su quel preciso compilatore di quel particolare sistema operativo di quella specifica architettura. Ma il mio codice può continuare a fregiarsi di rispettare lo standard.
Lo stesso NON si può dire delle estensioni GNU a C e C++, visto che non sono contemplate in alcun modo nei rispettivi draft.
@homero:
Quest’articolo ha un tema specifico, che nasce e si esaurisce qui. Per parlare di altro, ci sarà spazio in eventuali altri articoli.
Era rimasto bloccato dall’anti-spam un commento di Marco.
@Marco:
L’avevo già riportato nell’articolo: http://gcc.gnu.org/gcc-4.5/c99status.html
L’Extinguish rimane visto che calza benissimo al caso GCC:
“Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.”
Che GCC sia FOSS non cambia di una virgola la situazione di EEE venutasi a creare. Vedi AROS/68K & AmigaOS con Vbcc e Linux con CLang/LLVM.
Inoltre no, non sono obbligato a implementare le estensioni di GNU visto che esistono già degli standard (a meno che non valgano nulla) e non devo sentirmi un verme o un idiota se ho deciso di rispettarli.
Ancora no, non posso prendere a piene mani dal codice di GCC visto che è coperto da licenza GPL, che è notoriamente virale e liberticida (visto che col codice non sono libero di farci quello che voglio, appunto).
Che al solito non c’entra nulla con l’EEE.
L’EEE è una SITUAZIONE che si viene a creare, e prescinde dal fatto il player sia FOSS, OSS, oppure no. Vedi sopra alla voce “Extinguish”, appunto, che mi sembra abbastanza eloquente.
Ma a questo punto è chiaro che la questione è puramente politica / ideologica, come diceva j. Se chi estende gli standard è Microsoft (e solo lei) si applica l’EEE; altrimenti no.
Basta ammetterlo candidamente, non c’è alcun motivo per nascondere partigianeria e/o antipatia, anche se andiamo LEGGERMENTE fuori dall’ambito tecnico (e della discussione).
E, soprattutto, è una posizione che lascia il tempo che trova…
@ Cesare di Mauro : puoi citare la fonte a cui fai riferimento quando scrivi :
“Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.””
La trovi nel link che avevo messo alla fine dell’articolo: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish#The_strategy
Da Wikipedia :
“”Embrace, extend and extinguish,”[1] also known as “Embrace, extend, and exterminate,”[2] is a phrase that the U.S. Department of Justice found[3] was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences to disadvantage its competitors.
”
[1] http://www.economist.com/node/298112?Story_ID=298112
Si parla di proprietary capabilities.
Dimmi tu dove stanno le estensioni proprietarie di GCC.
Continuo :
“The more widely used variation, “embrace, extend and extinguish,” was first introduced in the United States v. Microsoft antitrust trial when the vice president of Intel, Steven McGeady, testified[8] that Microsoft vice president Paul Maritz used the phrase in a 1995 meeting with Intel to describe Microsoft’s strategy toward Netscape, Java, and the Internet.[9][10] In this context, the phrase means to highlight the final phase of Microsoft’s strategy as raised by McGeady, which was to drive customers away from smaller competitors.”
Andiamo avanti :
“The strategy’s three phases are:[11]
Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the ‘simple’ standard.
Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
>
>
>
Ora se Embrace si puo’ applicare a GCC, poiche’ implementa uno standard aperto (l’ANSI-C), dove la vedi tu la fase di Extend ?
Da quanto emerge l’Extend dovrebbe creare problemi a coloro che vogliono l’interoperabilita’ basandosi sullo standard semplice “simple standard”, ma nel caso di GCC lo standard semplice e’ ANSI-C. Quindi GCC e’ pienamente interoperabile con altri compilatori ADERENTI allo standard ANSI-C.
Quindi come vedi, in questo caso manco ce’ la fase di Extend.
Infine l’Extinguish deriva dalla fase di Extend, ma se quest’ultima viene a mancare come si fa a parlare di Extinguish ?
Quindi tutto il tuo bel discorso su quanto GCC sia anticompetitivo e che segua pedissequamente la strategia delineata da Microsoft crolla miseramente.
Andiamo avanti
[11] http://www.hr.com/servlets/sfs?&t=/Default/gateway&i=1116423256281&b=1116423256281&application
=story&active=no&ParentID=1119278102301&StoryID=1119649742078
Dal link [11] : How to Embrace, Extend, Extinguish
Microsoft has been “credited” with pioneering a novel and effective method for destroying open standards: Embrace, Extend, Extinguish. Embrace: Announce support for an open standard. Extend: Start adding proprietary extensions to the standard on the excuse that they “add value”. Extinguish: Increase use of proprietary extensions to the extent that it becomes incompatible with the open standard. This can cause the open standard to die. This will only work if the firm is dominant enough to push out the open standard through its control of things such as operating systems, server products, and developers” tools. Microsoft has been excused of using this tactic on HTML, Java, Kerberos and TCP/IP.
EEE una tattica PER DISTRUGGERE STANDARD APERTI.
Anche qui si parla di estensioni proprietarie allo standard.
In tutto questo discorsetto si parla sempre di aggiungere estensioni PROPRIETARIE per poi ELIMINARE LO STANDARD APERTO facendo leva sulla posizione dominante, quindi come fai in tutta onesta’ a sostenere che GCC segue la tattica del EEE ?
Le estensioni che GCC implementa NON SONO PROPRIETARIE e chiunque le puo’ implementare senza alcun vincolo. Si puo’ discutare sul fatto che le estensioni di GCC creiono un estensioni allo standard, e questo e’ vero, cosi’ come e’ vero che progetti che usano tali estensioni devono essere “modificati” se vogliono poter essere usati con altri compilatori. Ma qualsiasi progetto che e’ aderente al ANSI-C e’ TOTALMENTE 100% INTEROPERABILE con qualsiasi altro compilatore ANSI-C. E non dimentichiamo che poiche’ le estensioni non sono proprietarie tutti i compilatori li possono implementare.
Immaginavo che saresti andato a prendere quella roba, ma francamente non pensavo che qualcuno c’avrebbe messo così tanto. E’ da un pezzo che aspetto. :D
Andiamo alla fonte per eccellenza, il procedimento dell’antitrust da cui è scaturito l’EEE: http://www.justice.gov/atr/cases/f2600/v-a.pdf
Ecco la definizione che ne dà:
“Paul Maritz also explained to Intel representatives that Microsoft’s response to the browser threat was to “embrace, extend, extinguish”; in other words, Microsoft planned to “embrace” existing Internet standards, “extend” them in incompatible ways, and thereby “extinguish” competitors.”
Adesso leggi bene cosa significano i tre termini, e riflettici sopra. Come vedi non si parla di estensioni “proprietarie”.
E’ l’effetto stesso dell’estensione a provocare le incompatibilità, che portano poi all’estinzione della competizione (a causa della diffusione ovviamente).
Game over goldorak. Il gioco è finito.
Aggiungo che se lasci la palla ai programmatori, vale lo stesso anche per tutto il resto: potevano benissimo limitarsi allo standard, non credi?
Inoltre, e come avevo già detto, le estensioni “proprietarie” NON sono necessariamente chiuse: chiunque avrebbe potuto implementarle (eccetto il caso Kerberos).
Infatti dovresti sapere che se i programmatori devono utilizzare una funzionalità, come minimo… la devono conoscere. E la documentazione non è mai mancata (sempre tranne quell’eccezione).
Chi ha impedito agli altri browser di implementare la BEN NOTA tecnologia ActiveX? E i nuovi tag HTML? E J/Direct?
Purtroppo parti dall’assunto che se una cosa viene sviluppata da un’azienda che non la rilascia come open source, non può essere implementata dagli altri.
Errore, grosso errore, perché non serve certo il sorgente. Infatti gli standard non li fanno gli eventuali sorgenti di verification model dei comitati, ma… I DRAFT. Cioè i libri, la documentazione. Sì, l’informazione, insomma, che è la chiave di tutto.
@goldorok
Embrace: GCC implementa gli standard C e C++ (e altri ma limitiamoci a questi due)
Extend: GCC implementa estensioni al C e C++
GCC siamo tutti d’accordo che è in posizione dominante, quasi monopolio, rispetto agli altri compilatori.
Quindi viene da se che molti sviluppatori, GNU in primis, cominciano ad utilizzare quelle estensioni, ed è ovvio se nessuno avesse cominciato ad utilizzarle avrebbe significato che erano inutili, ma allora non sarebbero state introdotte.
Arriviamo all’eExtinguish: molti progetti oramai implementano tali estensioni, qualsiasi nuovo compilatore emergente per poter essere usabile nel mondo reale deve fare i conti con questo fatto e diventare compatibile con GCC.
Questo cosa porta? Porta a ciò che ho già scritto, solo i team più grossi e finanziati possono permettersi di fare il lavoro aggiuntivo di reimplementazione (perchè a meno di sottostare alla GPL il codice non può esser preso tal quale) delle estensioni,
E/o solo team grossi e con una certa influenza possono permettersi al contrario di chiedere e/o modificare da se progetti esistenti in modo da eliminare/arginare/mitigare i pezzi di codice che fanno uso delle estensioni.
Quindi di fatto, in pratica, praticamente nessuno può scrivere un nuovo compilatore c o c++ senza doversi sobbarcare lo sforzo aggiuntivo del doversi rendere compatibile con le estensioni di gcc.
Stessa cosa per dire di chi vuole oggi creare una nuova layout engine, deve sobbarcarsi il lavoro aggiuntivo di implementazione di tutti quelle peculiarità introdotte un po da tutti (IE è solo l’esempio peggiore), perchè anche in questo caso implementare lo standard, anche se draft, puro e semplice non basta.
In altre parole, chi volesse semplicemente solo implementare le specifiche sarebbe di fatto tagliato fuori dal mercato perchè ciò non basterebbe nel mondo reale.
Ah è se per caso la risposta è qualcosa del tipo: “e vabbè pace implementi le estensioni, il codice c’è, magari anche documentazione al riguardo, e stai apposto” autorizzi chiunque a pastrocchiare con qualunue standard a patto di rilasciare un minimo di specifica o documentazione o codice.
In altre parole definiscei gli standard e il loro processo +o- rigoroso di ratificazione semplicemente inutile poichè chiunque invece di affidarsi alle procedure può introdurre estensioni, e magari anche modifiche, a piacimento.
E se questo qualcuno è in posizione dominante, determinerà lo “standard” nuovo a cui tutti dovranno sottostare per essere minimamente considerabili nel mercato.
Praticamente l’anarchie dove vince il più forte, praticamente una situazione opposta a ciò che ci si prefigge quando si crea uno standard.
@Cesare
Grazie per aver fatto passare il mio commento.
Non ho molto altro da aggiungere e rimango fermamente convinto che ti sbagli nel parlare di EEE per i motivi che ho già esposto.
Solo una nota: CLang/LLVM è nato nel 2007 o giù di lì, con l’intenzione di offrire un miglior supporto all’Objective C (non a caso è sponsorizzato da Apple). Dire che non è diffuso per colpa di GCC e le sue estensioni è una falsità. Non è diffuso perché nonostante la bontà del progetto le prestazioni dei binari compilati con LLVM non sono anora all’altezza e/o non offre altri vantaggi significativi:
http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1
@RunAway
“de facto standard because of their dominant market share”
“siamo tutti d’accordo che è in posizione dominante, quasi monopolio, rispetto agli altri compilatori.”
E la fonte su queste affermazioni? Non mi risulta che Windows (e relative applicazioni) sia compilato con GCC.
Marco
Mi correggerà RunAway se ho sbagliato a interpretarlo, ma credo che si riferisse al contesto delle applicazioni open source, dove GCC “domina” rispetto agli altri compilatori.
Riguardo a CLang/LLVM, nessuno ha mai detto che non s’è diffuso a causa di GCC e delle sue estensioni. Il punto della questione è che la diffusione e l’uso di GCC e delle sue estensioni impedisce o complica la compilazione di molti progetti su compilatori che seguono più rigorosamente lo standard.
Inoltre, come tu stesso hai detto, LLVM è un progetto giovane e che deve ancora maturare. Ma la qualità del codice generato non è tutto per un compilatore (comunque sulla STL sta facendo passi da gigante), e ci sono ampi margini di miglioramento a motivo della giovane età.
RunAway ha scritto :
“de facto standard because of their dominant market share”
“siamo tutti d’accordo che è in posizione dominante, quasi monopolio, rispetto agli altri compilatori.”
Adesso cosa leggero’ che Apple e’ in posizione dominante perche’ e’ l’unica a vendere computer Apple ? Ignorando che detiene il 5% del market share a livello mondiale ?
Ormai si e’ capito la finalita’ di questo articolo, buttare fango sull’operato di GCC. Ci sono cose legittime da criticare nel progetto GCC, ma quello che traspare in questa discussione va dal ridicolo alla malafede pura e semplice. Che tristezza.
Io mi tiro fuori, mi piace partecipare ad una discussione polemica quando e’ sorretta da fatti veri ma non e’ il caso qui.
Che l’autore dell’articolo abbia delle critiche contro GCC e forse il mondo open source e’ legittimo, quello che non lo e’ e’ quando si cerca de sorreggere la propria posizione con falsita’.
L’unica cosa che sai fare è sbraitare invocando falsità. Hai cercato in parte di entrare nel merito e t’è andata malissimo.
Poi uno che mi accusa di falsità e di ridicolo quando non ha nemmeno avuto il coraggio di rispondere a delle precise domande (lo so: troppo scomode), fa veramente ridere…
la frase in inglese non l’ho scritta io ma probabilmente è parte di qualcosa quotato da altri da wikipedia o dal pdf del provvedimento della corte americana nei confronti di micrososft.
Sulla posizione dominante di GCC mi riferivo a tutto il mondo open e comunque non solo, visto che GCC è usatissimo anche su os x per progetti non open (ed è un motivo per cui Apple ha sovvenzionato llvm + clang per avere qualcosa di meglio da usare già internamente).
Per il resto a me non frega niente di gettare fango su GCC. E’ stata sollevata una questione oggettiva rispetto alle estensioni di GCC al C e C++ che pongono problemi ad altri che invece si limitano a seguire le sole specifiche di questi linguaggi e su questo si dibatte.
Seppoi ogni volta che si muovono critiche ad un progetto opensource la si butta sull’ideologia e sul personale non si va da nessuna parte. Mentre capita spesso che quando si parla di progetti non open, ma anche open di particolari aziende o con particolari licenze, le critiche sono spietate senza attenuanti di sorta anche per minimi difetti.
Infatti aveva ragione j: la questione è prettamente politico/ideologica. Si usano due pesi e due misure, a seconda di chi si sta parlando.
E’ da un vita che sento sbandierare il rispetto degli standard, ma vale soltanto per le “odiate” multinazionali. E quando le porcate le fanno i fedeli amici del FOSS/OSS, si infila la testa dentro la sabbia, si cerca di cambiare discorso, oppure si evita di rispondere.
Coerenza zero.
La questione è, invece, prettamente tecnica: gli standard o si rispettano integralmente nei loro draft ufficiali, oppure no. E questo deve valere PER TUTTI, nessuno escluso. Poi se ne traggano le conseguenze.
Che poi, vista la situazione, per certa gente è come chiedere di che morte morire. Ma sempre al patibolo si finisce, non si scappa…
xcdmauro
a giudicare dalle risposte lunghe quasi quanto un articolo credo che la cosa non possa esaurirsi qui, in quanto l’articolo solleva un problema reale che potrebbe riperquotersi in futuro…
per tutti
preciso il fatto che gli americani dovrebbero essere gli ultimi sulla faccia della terra a definire gli standard basti vedere il casino che hanno con le unità di misura…ed intendo tutte quante le unità di misura che utilizzano….i listini di borsa usano ancora le frazioni 3/8 2/3 1/8 1/2…figuriamoci se devono standardizzare in maniera coerente un linguaggio di programmazione che non riescono ancora a standardizzare il modo di sillabare le loro parole….o di definire una precisa corrispondenza fonetica tra scritto e orale…
e lo si vede con i loro standard che sono perennemente un casino dopo centinaia di ore di riunioni passate a definirlo….
W3C in testa…
per quanto riguarda il GCC ho già scritto che il problema dei compilatori oggi è estremamente importante in quanto sono l’ultimo legame ci porta a sfruttare pienamente l’hardware delle macchine che utilizziamo…
allora comprendere i vantaggi e le necessità di introdurre nuove funzioni in un compilatore o aggiunte allo standard ISO deve essere valutata per la reale utilità che tutto questo ha….
faccio un esempio concreto:
oggi mitrovo con il grande problema di compilare software in modo da utilizzare le nuove cpu multicore…attualmente mi appoggio al sistema operativo ossia utiliziamo vecchie funzioni fatte per i cluster che creano tanti task quanti nodi di calcolo vogliamo utilizzare….quindi in pratica un processore con 6 core viene visto come un cluster a 6 nodi…
le prestazioni scalano bene…meno bene è l’occupazione di memoria che si moltiplica linearmente per il numero di nodi…
il problema è sorto quando abbiamo messo in cluster un numero di nodi con cpu multicore…in questo caso il software per gestire i vari nodi di calcolo non andava piu’ bene…quindi abbiamo dovuto fare un nodo server locale e un nodo server di rete…la struttura si è fatta alquanto complessa (in realtà la storia è piu’ lunga ma preferisco sintetizzarla cosi’ anche con qualche imprecisione che non cambia il succo della vicenda)…oggi i compilatori intel sembrano aver risolto il problema riuscendo a gestire i processori multitread in maniera trasparente (anche se tutta sta storia è da verificare…) e quindi semplificare ed ottimizzare l’intera struttura di calcolo….se fosse possibile utilizzare il vecchio codice C senza doversi sbattere con le varie librarie del’OS e riscrivere parte del codice…non esiterei a cambiare compilatore ed anche ad utilizzare nuove istruzioni non standard….
ma se il vantaggio è puramente formale o peggio ancora stilistico….definirei criminale un atteggiamento del genere…
quindi il succo della storia è comprendere il valore aggiunto di un compilatore ed i vantaggi che questo puo’ dare all’utente…
ad oggi il grande vantaggio del GCC è la stabilità, la gratuità ed il fatto che è presente su tutte le piattaforme conosciute…oquasi….ma per entrare nei dettagli a mio giudizio è necessario un’articolo a parte…
@homero
Mi rendo conto che il problema sia complesso e nessuno mette in dubbio che le estensioni non siano utile. Il punto è eventualmente il modo di procedere.
Non è solo GCC che ha esteso il C, lo ha fatto recentemente anche Apple nell’ambito del grand central dispatch, in particolare con i cosiddetti \blocks\: http://developer.apple.com/library/mac/#featuredarticles/BlocksGCD/ eppure come si legge \Apple has published both the Blocks Languages Specification and our implementation as open source under the MIT license, added blocks support to GCC 4.2 and clang, and has submitted it for consideration as part of the next version of the C programming language.\
Sottolineo \…and has submitted it for consideration as part of the next version of the C programming language\, cioè comunque ha anche seguito una via burocratica per la ratificazione di tali estensioni.
E’ stata fatta una cosa simile per le estensioni di GCC?
Dovremmo chiedere a Stallman se nel perorare la sua causa per far rimuove la keyword export (giusto per togliere un altro po’ di libertà alla gente; così si è più liberi, no? Ovviamente col suo personalissimo concetto di libertà :D) abbia fatto lo stesso con tutte le estensioni introdotte da GCC. :P
@homero: cambierebbe qualcosa se il prossimo articolo lo intitolassi tipo “Standard sì oppure no?”? Ne dubito fortemente: verrebbero riproposte le stesse situazioni e le stesse prese di posizione.
E sai perché? Perché è evidente ormai di come la questione sia prettamente dogmatico-ideologica. E siccome, da buon ateo, le questioni pseudo-religiose mi danno ancora più fastidio di quelle religiose, non vedo perché dovrei perderci altro tempo. Preferisco dedicarlo ad argomenti prettamente tecnologici…
x cdmauro
io concordo con te dicendo che un’articolo “standard si oppure no?” non serve a nulla, cosi’ come sono ridicoli quelli che ne fanno una guerra santa. ma come ho già scritto, cerchiamo di portare alla luce la reale utilità di queste evoluzioni del linguaggio ammesso che ce ne siano e sopratutto la reale efficenza di un compilatore in relazione all’hardware che si utilizza.
intendo dire che oggi se dovessi scrivere un software per un ipotetico sistema con processore a 12 core…cosa che non è cosi’ fantascientifica la prima cosa che mi chiederei il mio compilatore C li supporta nativamente? o devo cominciare a considerare l’utilizzo di librerie come per lo sfruttamento delle GPU?
chi ha un minimo di esperienza di programmazione sa che queste scelte sono radicali…quindi il punto nodale di tutta la situazione è queste digressioni dagli standard hanno un senso o sono pura accademia?
io personalmente goto in un codice C non mi è mai venuto neppure lontanamente in mente di utilizzarlo….ma se qualcuno mi dimostrasse che una reale e tangibile utilità sarei pronto ad uscire dallo standard….cosi’ come se il compilatore intel promette di supportare nativamente sistemi multicore senza ricompilazione nel prossimo futuro gcc se non si evolverà se ne andrà in pensione dopo 13 anni di onorata carriera…
Beh, Intel è molto avanti nello sviluppo di algoritmi per l’auto-parallelizzazione del codice (sia di tipo SIMD che multicore), ma non credo che questo potrebbe segnare la fine di GCC, visto che i suoi compilatori se li fa pagare cari (inoltre sono orientati soltanto ai suoi processori) mentre quest’ultimo è “gratuito” e supporta numerose architetture (con qualità altalenante).
Sul goto ci sarebbe di che discutere. Nemmeno nei miei sorgenti ne vedi (a parte in un’occasione per WPython, dove ho replicato un pezzo di codice di CPython che ne faceva uso), ma in tanti progetti, anche blasonati, li trovi, eccome.
Ci sono anche linguaggi che semplicemente non ce l’hanno come costrutto sintattico, ma rimane sempre una questione “filosofica”, perché dove manca il goto generalmente troviamo istruzioni come break, continue, o lo stesso return che, di fatto, interrompono l’esecuzione del flusso di codice.
Riguardo alle proposte all’inizio del tuo commento, non saprei. Mettendo da parte i problemi di incompatibilità che possono creare, è chiaro che se le estensioni esistono vuol dire che qualcuno le ha trovate comode e ci saranno pezzi di codice che ne faranno uso.
Mentre su questa:
“la reale efficenza di un compilatore in relazione all’hardware”
penso che ti riferisca al codice ottimizzato emesso, ma ne ho già parlato in parte nel precedente articolo sul GCC.
“Si usano due pesi e due misure, a seconda di chi si sta parlando.”
Parole sante!!!
Marco
è una tua personale opinione, ma non certo un dato di fatto
dato di fatto è che l’ extinguish si configura per caratteristiche oggettive di un prodotto sw (gratuito o meno) usato dalla (o imposto con artifici alla) maggioranza del mercato, prescindenti dalle motivazioni dietro al suo sviluppo, e dal suo costo (peraltro, quando quando un prodotto è venduto a costo minimo o nullo per spiazzare la concorrenza si parla di dumping)
dato di fatto è anche che l’ open source non è altro che una modalità di distribuzione (invece di distribuire un file binario distribuisco i sorgenti ed eventualmente il file binario) del sw, scelta per determinati motivi (nel caso del sw aperto liberale consentire a tutti indistintamente di beneficiare dei risultati della ricerca accademica, in quello del “free” software, per questioni primariamente politiche) così come la licenza (che in un caso e nell’altro riflette le motivazioni di base) – ma il sw open source è sempre… software, quindi va soggetto alle stesse considerazioni a prescindere da chi lo sviluppi e perchè (a meno di non fare due pesi e due misure, ma questo renderebbe la discussione immediatamente nulla)
e tu leggi meglio please ;-)
io mi riferivo alle motivazioni addietro alla creazione di generico FOSS quindi in pratica al manifesto GNU firmato dal guru stallman, ma quello non lo hai linkato (forse perchè propugnando in effetti un’ ideologia, mi avrebbe dato ragione…)
sulla pagina di uno strumento specifico destinato a un pubblico tecnico è normale limitarsi alle caratteristiche e goals tecnici, se l’ ideologia di fondo è già espressa altrove (e nota anche ai sassi)
se il mio è disgusto per l’ ideologia anteposta alla tecnica nello sviluppo di soluzioni da cui l’ ideologia dovrebbe essere bandita, forkare il codice di programmatori ideologizzati li renderebbe non più tali? no di certo, allora perchè dovrei farlo?
più sopra accennavo a come il sw molti usano il sw open source a scopo referenziale ( quando le uniche fonti referenziali davvero valide sono libri di testo, non codice scritto da altri) e al rischio di alimentare una monocultura legata (e limitata) a certi ambienti inculcando subconsciamente il principio che sia l’ unica valida… con questo mi dai ragione :-)
se uno non sa come funziona e come si sviluppa un compilatore, esistono degli ottimi corsi universitari e libri di testo (od anche già solo i secondi) che lo insegnano per filo e per segno – i sorgenti di gcc sono proprio l’ ultimo posto dove dovrebbe guardare :-)
è brutto parlare per slogan in una discussione pragmatica…
è stato detto N volte, da me, cesare, RunAway ed altri, leggi meglio…
ma il fatto che GCC resti libero e gratuito (quindi plausibilmente scelta primaria dell’ utenza), che benefici apporterebbe di preciso, ai progetti TenDRA o OpenWatson, a Digital Mars (produttrice di un compilatore C/C++ oltre a quelllo per il linguaggio proprietario D) o Comeau? e non chiedere che c’ entrino, è dall’inizio che proprio loro sono al centro del discorso (che tu ed altri insistete a portare sugli utenti finali)
già, proprio bella, soprattutto perchè non ho affatto scritto che non mi piace GCC, dove l’ avrei fatto me lo devi dire …
io mi riferivo a spocchia politica, strumentalizzazione ideologica e atteggiamenti egoistici, da parte di chi sviluppa FOSS – del sw in sè, creazione incolpevole, non mi interessava minimamente nel contesto del discorso di prima
so benissimo che posso usarlo come no senza che me lo venissi a dire tu dal pulpito, grazie tante … ma il mio non usarlo non inficerebbe minimamente l’ atteggiamento a monte degli aderenti al movimento foss (nè il profondo disgusto nei confronti dei quali che detto atteggiamento mi ispira)
per cui, che c’ entra con quello a cui mi riferivo sopra? nulla
cioè? vorresti dire che ritieni giusto fare due pesi e due misure e appggi chi lo fa? complimenti, ti sei appena etichettato come fanatico e di parte…
\usato dalla (o imposto con artifici alla) maggioranza del mercato\
E’ una mia opinione, come la tua del fatto che GCC sia usato dalla \maggioranza del mercato\.
GCC ha una buona fetta di utilizzatori nel mondo FLOSS semplicemente perché allo stato attuale delle cose è il compilatore migliore. L’unico che potrebbe competere è LLVM, che è ancora troppo giovane e non si può certo dire che sia stato danneggiato da GCC.
Tutta questa discussione è nata proprio su una base di antipatia (che potrei anche giustificare) verso FLOSS, GPL, GCC, Stallman e soci, perfettamente tangibile dalla storia degli articoli di Cesare su questo sito (non me ne volere Cesare, lo sai che nonostante ti ammiro! ;-))
\cioè? vorresti dire che ritieni giusto fare due pesi e due misure\
Se non arrivi a comprendere il significato della frase di Cesare e della mia battuta successiva, mi dispiace proprio.
Questa discussione è nata da fatti e problemi tangibili dovuti all’estensione di standard esistenti.
Questioni prettamente tecniche, insomma, al contrario della simpatia/antipatia, che porta anche a prese di posizione dogmatiche quando si abbracciano certe ideologie, come già detto.
Non è un caso che a certe, precise, domande non ci sia stato un seguito. Le domande possono anche risultare antipatiche (ancorché, indigeste), ma rispecchiano questioni oggettivamente tecniche, e meriterebbero risposte (innanzitutto) altrettanto tecniche.
Non si può parlare di estensioni, senza tirare in ballo gli standard e le relative conseguenze alla loro non aderenza.
La coperta non la si può tirare soltanto da un lato, perché è ovvio che l’altro resterà poi scoperto.
Non c’entra l’antipatia, a meno che non vogliamo spostare la discussione sul piano personale, che però non c’azzecca nulla su una discussione tecnica. O no? :P
“Questioni prettamente tecniche, insomma”
Sulle questioni prettamente tecniche posso anche essere d’accordo, ma sul titolo e il tema di fondo dell’articolo no, visto che non ci sono i presupposti (e anche qui si è glissato parecchio).
“Non c’entra l’antipatia, a meno che non vogliamo spostare la discussione sul piano personale”
Per carità… intendevo dire che anche questo articolo è fedele alla tua “linea editoriale”, niente di più.
I lettori che, come me, ti seguono assiduamente, si saranno fatti la loro idea in merito ;-)
è la terza volta che mi offendi, con questa…
cmq il senso del discorso di cesare era chiarissimo, a non esserlo era il fatto che tu lo appoggiassi dopo essere stato fino a quel momento proprio tra coloro che facevano due pesi e due misure – il che ti rendeva sarcastico
se guardi al titolo prima del contenuto vuol dire criticare al tono del discorso, ma guarda come si situa il “respond to tone” nella gerarchia dialettica… http://blog.createdebate.com/2008/04/07/writing-strong-arguments/ od anche http://www.paulgraham.com/disagree.html
i presupposti ci sono, perchè legalmente (e praticamente) sw foss e proprietario, sono equiparati – non è che solo perchè qualcuno lo considera “patrimonio dell’ umanità” o perchè è sviluppato “dal basso”, si debbano fare eccezioni o usare un diverso metro nel valutare le ricadute delle funzionalità e del modo in cui sono implementate, su soluzioni sw affini ma concorrenti (a loro volta gratuite, aperte o meno)
visto che, ripeto, funzionalità/architettura/design, e modalità di sviluppo e distribuzione, sono ortogonali – cosa che è lampante per chiunque sia un minimo pragmatico e obiettivo, e per qualunque sviluppatore di sw che si rispetti
per chi non lo è, o non è uno sviluppatore o non è pragmatico in quanto più o meno condizionato dall’ ideologia, delle due l’ una
anche tu hai glissato parecchio, mi pare ;)
anche su mie esplicite domande, ma forse quelle non meritavano risposta…
“è la terza volta che mi offendi, con questa”
Vedo che non perdi l’occasione di fare figure barbine, visto che sei stato tu a darmi “fanatico”, e per giunta senza minimamente comprendere quello che avevo scritto :-D
Io credo che alcune volte gli standard “lenti” vengono sviluppati proprio grazie ai compilatori che implementano nuove features. Così le nuove versioni degli standard non sono altro che una ratifica delle features già implementate.
Ad esempio lo standard C1X (ancora in draft) principalmente aggiunge, rispetto al C99, delle features già presenti in vari compilatori.
Le aggiunge perché il draft di C++0x (adesso finalmente C++11) c’era già da parecchi anni, e nel frattempo alcune delle caratteristiche in discussione sono state implementate perché ritenute e molto probabilmente sarebbero state introdotte nello standard. ;)
“creano di fatto ulteriori problemi di portabilità e compatibilità (oltre ai soliti con cui si ha a che fare col linguaggio C).”
Non ho capito a cosa ti riferisci con “i soliti”, potresti fare un paio di esempi?
Qui http://www.appuntidigitali.it/12073/linguaggi-astrazione-potenza/ da circa la metà, quando comincio a parlare di C, fino alle fine. E anche i commenti sono interessanti rispetto alla domanda che hai posto.
Grazie.