View Full Version : Torvalds e C++
C'entra e non c'entra con la programmazione pura e semplice ma visto che un po' di tempo fa (parecchio a dire il vero) si era accesa una discussione sul perchè Torvalds non facesse uso del C++, è comparso recentemente questo commento a mano dello stesso Linus. In verità non ho letto tutta la discussione perchè la seguivo a pezzi ma mi pare che, toni accesi ed eccessivi a parte, Linus sia convinto della sua scelta e spiega in poche parole alcuni punti cardine. Lo segnalo giusto per cultura visto che parla un o dei personaggi più noti ed influenti, detto che non sono in grado di contrastare le sue opinioni ma cnq qualche dubbio di mio ce l'ho.
Link:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
E' un relitto del passato, esattamente come il suo sistema operativo.
Ammazza che fiammate che mi tiro addosso ora! :D.
mindwings
07-09-2007, 18:30
E' un relitto del passato, esattamente come il suo sistema operativo.
Ammazza che fiammate che mi tiro addosso ora! :D.
:rolleyes: l'evoluzione si chiama Vista 500 mb di ram allocati all'avvio
senza muovere un dito :D
:fagiano:
scusami ma non ho resistito:)
variabilepippo
07-09-2007, 18:34
l'evoluzione si chiama Vista 500 mb di ram allocati all'avvio
senza muovere un dito
A volte sarebbe opportuno documentarsi prima di esternare (http://www.microsoft.com/technet/technetmag/issues/2007/03/VistaKernel/). :stordita:
"The question shouldn't be "Why does Vista use all my memory?", but "Why the heck did previous versions of Windows use my memory so ineffectively?"
mindwings
07-09-2007, 18:38
A volte sarebbe opportuno documentarsi prima di esternare (http://www.microsoft.com/technet/technetmag/issues/2007/03/VistaKernel/). :stordita:
ho visto vista in azione sul portatile di un mio amico :)
500 mb allocati all'avvio .
variabilepippo
07-09-2007, 18:42
ho visto vista in azione sul portatile di un mio amico
500 mb allocati all'avvio .
E' un bene, non un male... Un sistema operativo NON deve occupare il minor quantitativo di RAM possibile, non è mica una gara al risparmio, deve piuttosto gestire la memoria nel modo migliore. Fortunatamente Vista utilizza la RAM in modo più aggressivo rispetto ad altri sistemi e nella maggior parte dei casi SuperFetch migliora la prestazioni.
mindwings
07-09-2007, 18:45
E' un bene, non un male... Un sistema operativo NON deve occupare il minor quantitativo di RAM possibile, non è mica una gara al risparmio, deve piuttosto gestire la memoria nel modo migliore. Fortunatamente Vista utilizza la RAM in modo più aggressivo rispetto ad altri sistemi e nella maggior parte dei casi SuperFetch migliora la prestazioni.
permettimi di dissentire :)
personalmente preferisco usare / sprecare la ram
per le mie applicazioni non lasciarle in pasto al SO .
variabilepippo
07-09-2007, 19:05
permettimi di dissentire
personalmente preferisco usare / sprecare la ram
per le mie applicazioni non lasciarle in pasto al SO
Evidentemente non hai letto gli articoli nei quali viene descritto il nuovo kernel di Vista. Facciamo così, tu dedichi 10 minuti della tua vita per documentarti sul funzionamento di Vista, poi intavoleremo una bella discussione tecnica e potrai muovere tutte le critiche e le obiezioni che riterrai valide.
Le risorse disponibili non usate sono risorse sprecate! Se il tuo sistema ha 1GB di RAM ed il sistema operativo fa di tutto per usarne 20MB e la cosa ti sta bene allora sei tra quelli che comprerebbero una Ferrari per andare a 20km/h in pista. :muro:
Credo che il punto della discussione sia non tanto un confronto tra sistemi operativi quanto sull'opportunità di avvalersi di tecniche di programmazione un pelo più aggiornate di quelle in voga nel millenovecento e voltes indre', anno in cui Ritchie stabilì che per la creazione di un nuovo sistema operativo occorreva predisporre un linguaggio che superasse il meglio di allora.
Anno del signore 2007: è poi così bizzarro pensare all'opportunità di tumulare la programmazione procedurale anche per lo sviluppo di sistemi operativi?
cdimauro
07-09-2007, 19:31
C'entra e non c'entra con la programmazione pura e semplice ma visto che un po' di tempo fa (parecchio a dire il vero) si era accesa una discussione sul perchè Torvalds non facesse uso del C++, è comparso recentemente questo commento a mano dello stesso Linus. In verità non ho letto tutta la discussione perchè la seguivo a pezzi ma mi pare che, toni accesi ed eccessivi a parte, Linus sia convinto della sua scelta e spiega in poche parole alcuni punti cardine. Lo segnalo giusto per cultura visto che parla un o dei personaggi più noti ed influenti, detto che non sono in grado di contrastare le sue opinioni ma cnq qualche dubbio di mio ce l'ho.
Link:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
E' l'n-esima dimostrazione che Torvalds:
- non ha idea di cosa sia l'ingegneria del software;
- non ha idea di cosa significhi programmare in C++;
- non ha idea di cosa sia il rispetto e la buona educazione (ma questo è normale per chi, non avendo sufficienti argomentazioni a sostegno delle proprie idee, preferisce scadere sul piano personale; generalmente i troll ci arrivano dopo un po', ma in questo Linus è un campione: è sempre al primo messaggio che scrive che fa partire gli insulti e le parolacce).
In passato, quando c'era fek che scriveva, c'era stata una discussione sullo stesso tema, in cui in una discussione questo programmatore da due soldi si lasciava andare a commenti sul C++ che non stavano né in cielo né in terra, e difatti venne immediatamente smentito da chi conosceva questo linguaggio.
Peccato che la ricerca non funzioni per i messaggi più vecchi, perché sarebbe stato bello recuperare quel thread per farci ancora quattro risate. :p
cdimauro
07-09-2007, 19:33
E' un relitto del passato, esattamente come il suo sistema operativo.
Ammazza che fiammate che mi tiro addosso ora! :D.
Beh, mi sembra normale: uno può anche dire una cosa giustissima (come in questo caso), ma se va toccare certi totem venerati come dio in terra si scatenerà l'ira dei fedeli (nonché ciechi) adoratori.
cdimauro
07-09-2007, 19:36
Credo che il punto della discussione sia non tanto un confronto tra sistemi operativi quanto sull'opportunità di avvalersi di tecniche di programmazione un pelo più aggiornate di quelle in voga nel millenovecento e voltes indre', anno in cui Ritchie stabilì che per la creazione di un nuovo sistema operativo occorreva predisporre un linguaggio che superasse il meglio di allora.
Nella scrittura di codice di bassa qualità sicuramente. :asd: Perché per il resto il C, come linguaggio, non ha portato NESSUNA innovazione: la programmazione procedurale esisteva già da una decade buona, e non si sentiva certo il bisogno di una minestra riscaldata...
Anno del signore 2007: è poi così bizzarro pensare all'opportunità di tumulare la programmazione procedurale anche per lo sviluppo di sistemi operativi?
Macché, non lo sai che si prevede un'inversione di tendenza? Si torna a lavorare in assembly, e a ruota seguirà direttamente il linguaggio macchina. Vuoi mettere? E' molto più fico. :D
cdimauro
07-09-2007, 19:38
:rolleyes: l'evoluzione si chiama Vista 500 mb di ram allocati all'avvio
senza muovere un dito :D
:fagiano:
scusami ma non ho resistito:)
Non hai resistito alla solita battuta scontata su un argomento che sconosci.
Non se ne sentiva sicuramente la necessità.
La prossima volta quanto meno documentati, come t'è stato suggerito, e poi ne riparliamo.
mindwings
07-09-2007, 19:40
Evidentemente non hai letto gli articoli nei quali viene descritto il nuovo kernel di Vista. Facciamo così, tu dedichi 10 minuti della tua vita per documentarti sul funzionamento di Vista, poi intavoleremo una bella discussione tecnica e potrai muovere tutte le critiche e le obiezioni che riterrai valide.
Le risorse disponibili non usate sono risorse sprecate! Se il tuo sistema ha 1GB di RAM ed il sistema operativo fa di tutto per usarne 20MB e la cosa ti sta bene allora sei tra quelli che comprerebbero una Ferrari per andare a 20km/h in pista. :muro:
il tuo discorso non fa una piega:) e ci mancherebbe altro
ma se il mio sistema mi impiega 500 mb di ram
e poi apro 2-3 applicazioni è quasi certo che saturo la ram
e il sistema si rallenta.
chiudo qui perchè siamo OT .
cdimauro
07-09-2007, 19:42
C'entra e non c'entra con la programmazione pura e semplice ma visto che un po' di tempo fa (parecchio a dire il vero) si era accesa una discussione sul perchè Torvalds non facesse uso del C++, è comparso recentemente questo commento a mano dello stesso Linus. In verità non ho letto tutta la discussione perchè la seguivo a pezzi ma mi pare che, toni accesi ed eccessivi a parte, Linus sia convinto della sua scelta e spiega in poche parole alcuni punti cardine. Lo segnalo giusto per cultura visto che parla un o dei personaggi più noti ed influenti, detto che non sono in grado di contrastare le sue opinioni ma cnq qualche dubbio di mio ce l'ho.
Link:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
Ah, dimenticavo: Torvalds è l'unico che ha avuto l'ardire di affermare che un linguaggio come il C è migliore del C++, che del primo è un SUPERSET (leggi: permette di fare ESATTAMENTE le stesse cose del C, ma in più hai dei costrutti per fare MOLTO ALTRO).
Insomma, una rivoluzione della matematica. :asd:
L'unica cosa su cui concordo è sul fatto che il C++ faccia schifo come linguaggio, ma qui, come poi è stato ribadito nella discussione in oggetto, è più una questione di gusti e/o "religione". :D
mindwings
07-09-2007, 19:42
Non hai resistito alla solita battuta scontata su un argomento che sconosci.
Non se ne sentiva sicuramente la necessità.
La prossima volta quanto meno documentati, come t'è stato suggerito, e poi ne riparliamo.
Ho espresso un opinione personale frutto di un esperienza diretta ciò che dico non è bibbia cosi come Vista o chi per lui non è IL SO . Ognuno ha le sue preferenze...
cdimauro
07-09-2007, 19:45
Ho espresso un opinione personale , cio che dico non è bibbia cosi come Vista o chi per lui non è IL SO . Ognuno ha le sue preferenze...
Le opinioni di per sé non dicono nulla: molto meglio portare delle argomentazioni a sostegno.
Poi nessuno qui mi pare abbia affermato che Vista sia IL s.o.: non mettiamo le mani avanti, per cortesia.
Quanto alle preferenze, nulla da dire: de gustibus.
mindwings
07-09-2007, 19:48
Le opinioni di per sé non dicono nulla: molto meglio portare delle argomentazioni a sostegno.
Poi nessuno qui mi pare abbia affermato che Vista sia IL s.o.: non mettiamo le mani avanti, per cortesia.
Quanto alle preferenze, nulla da dire: de gustibus.
anche l'espressione
"relitto del passato" :) non mi dice nulla che ci vuoi argomentare su questo?
EDIT : uno dei primi post del thread con l'unica eccezione che sparare a zero senza argomentare ad alcune persone è consentito.
cdimauro
07-09-2007, 19:52
anche l'espressione
"relitto del passato" :) non mi dice nulla che ci vuoi argomentare su questo?
Ne ho parlato non so quante volte sia qui, che nella sezione news che nella sezione Linux: se ti fai un giretto vedrai che sono tipo abbastanza conosciuto da quelle parti. :asd:
Per il resto, è sufficiente leggersi qualche libro che tratta del design di s.o. moderni per rispondere alla tua domanda. ;)
mindwings
07-09-2007, 20:00
Ne ho parlato non so quante volte sia qui, che nella sezione news che nella sezione Linux: se ti fai un giretto vedrai che sono tipo abbastanza conosciuto da quelle parti. :asd:
Per il resto, è sufficiente leggersi qualche libro che tratta del design di s.o. moderni per rispondere alla tua domanda. ;)
non era riferito a te:)
cdimauro
07-09-2007, 20:03
non era riferito a te:)
Ma hai quotato me. ;)
variabilepippo
07-09-2007, 20:04
ma se il mio sistema mi impiega 500 mb di ram
e poi apro 2-3 applicazioni è quasi certo che saturo la ram
e il sistema si rallenta.
Falso. Se avessi avuto il buongusto di leggere gli articoli sul kernel citati qualche messaggio fa avresti scoperto che vale esattamente il contrario!
In ufficio, su una macchina equipaggiata con Vista e 2GB di RAM, nel vano tentativo di saturare la memoria ho lanciato CONTEMPORANEAMENTE i seguenti programmi: Visual Studio 2005, Delphi 2007, Matlab, Photoshop CS2, Firefox, Internet Explorer, Opera, Nero 7, Acrobat Reader, un simulatore Spice, MSN, SkyPe, TUTTI (Word, Excel, Powerpoint, Access, Visio, ecc) gli applicativi inclusi nel pacchetto Office 2007, diversi player MP3 ed alcune utility avide di risorse.
Sai quanta memoria fisica risultava occupata da questi "mostri"? 960MB! Se vuoi appena posso ti mando uno snapshot di Process Explorer a titolo di dimostrazione!
cdimauro
07-09-2007, 20:06
anche l'espressione
"relitto del passato" :) non mi dice nulla che ci vuoi argomentare su questo?
EDIT : uno dei primi post del thread con l'unica eccezione che sparare a zero senza argomentare ad alcune persone è consentito.
Ho visto che hai aggiunto una frase dopo. Beh, se c'è una cosa che PGI-bis non fa mancare mai è un'ottima (facciamo eccellente, va. :D) argomentazione delle sue idee. :p
Devi soltanto dargli un po' di tempo per calare l'asso (leggi: il papirone :D).
mindwings
07-09-2007, 20:06
Ne ho parlato non so quante volte sia qui, che nella sezione news che nella sezione Linux: se ti fai un giretto vedrai che sono tipo abbastanza conosciuto da quelle parti. :asd:
Per il resto, è sufficiente leggersi qualche libro che tratta del design di s.o. moderni per rispondere alla tua domanda. ;)
Falso. Se avessi avuto il buongusto di leggere gli articoli sul kernel citati qualche messaggio fa avresti scoperto che vale esattamente il contrario!
In ufficio, su una macchina equipaggiata con Vista e 2GB di RAM, nel vano tentativo di saturare la memoria ho lanciato CONTEMPORANEAMENTE i seguenti programmi: Visual Studio 2005, Delphi 2007, Matlab, Photoshop CS2, Firefox, Internet Explorer, Opera, Nero 7, Acrobat Reader, un simulatore Spice, MSN, SkyPe, TUTTI (Word, Excel, Powerpoint, Access, Visio, ecc) gli applicativi inclusi nel pacchetto Office 2007, diversi player MP3 ed alcune utility avide di risorse.
Sai quanta memoria fisica risultava occupata da questi "mostri"? 960MB! Se vuoi appena posso ti mando uno snapshot di Process Explorer a titolo di dimostrazione!
non c'è ne bisogno mi fido:)
cdimauro
07-09-2007, 20:12
Falso. Se avessi avuto il buongusto di leggere gli articoli sul kernel citati qualche messaggio fa avresti scoperto che vale esattamente il contrario!
In ufficio, su una macchina equipaggiata con Vista e 2GB di RAM, nel vano tentativo di saturare la memoria ho lanciato CONTEMPORANEAMENTE i seguenti programmi: Visual Studio 2005, Delphi 2007, Matlab, Photoshop CS2, Firefox, Internet Explorer, Opera, Nero 7, Acrobat Reader, un simulatore Spice, MSN, SkyPe, TUTTI (Word, Excel, Powerpoint, Access, Visio, ecc) gli applicativi inclusi nel pacchetto Office 2007, diversi player MP3 ed alcune utility avide di risorse.
Sai quanta memoria fisica risultava occupata da questi "mostri"? 960MB! Se vuoi appena posso ti mando uno snapshot di Process Explorer a titolo di dimostrazione!
Buongustaio... :cool:
P.S. Prova Python for Delphi che ti aprirà nuovi orizzonti nello sviluppo delle applicazioni: è un portento. :)
mindwings
07-09-2007, 20:13
Ho visto che hai aggiunto una frase dopo. Beh, se c'è una cosa che PGI-bis non fa mancare mai è un'ottima (facciamo eccellente, va. :D) argomentazione delle sue idee. :p
Devi soltanto dargli un po' di tempo per calare l'asso (leggi: il papirone :D).
ammesso che dal suo alto lo cali :fagiano:
Io calo dal basso. Per prenderli di sorpresa.
mindwings
07-09-2007, 20:17
Io calo dal basso. Per prenderli di sorpresa.
Spiegaci perchè col pinguino ci viene bene solo la zuppa:rolleyes:
variabilepippo
07-09-2007, 20:17
Buongustaio...
P.S. Prova Python for Delphi che ti aprirà nuovi orizzonti nello sviluppo di applicazioni
Grazie, grazie... ;)
Io sviluppo principalmente in Delphi, Python e C#, però finora non ho mai lavorato ad alcun progetto nel quale fosse necessario integrare Delphi&Python. Tra l'altro per piccole modifiche al codice uso PyScripter (http://mmm-experts.com/Products.aspx?ProductID=4), un editor sviluppato da MMM-Experts (come saprai sono famosi per Python for Delphi (http://mmm-experts.com/Products.aspx?ProductId=3)). A proposito, esistono dei metodi migliori per usare Python in programmi Delphi?
cdimauro
07-09-2007, 20:34
Grazie, grazie... ;)
Io sviluppo principalmente in Delphi, Python e C#, però finora non ho mai lavorato ad alcun progetto nel quale fosse necessario integrare Delphi&Python. Tra l'altro per piccole modifiche al codice uso PyScripter (http://mmm-experts.com/Products.aspx?ProductID=4), un editor sviluppato da MMM-Experts (come saprai sono famosi per Python for Delphi (http://mmm-experts.com/Products.aspx?ProductId=3)). A proposito, esistono dei metodi migliori per usare Python in programmi Delphi?
Meglio di Python for Delphi non ho trovato.
Qualche esempietto veloce (ci sto lavorando in questo momento :D):
procedure TfrmMain.ZFormAfterShow(Sender: TObject);
var
v: Variant;
begin
v := PyGlobals.GetData(PyGlobals.DBUtils.SQLGets, 'SELECT SeparatoreDecimale, DecimaliDopoVirgola FROM SysDatas');
DecimalSeparator := string(v.GetItem(0))[1];
CurrencyDecimals := v.GetItem(1);
end;
PyGlobals è un modulo Python (importanto con... PyGlobals := Import('Globals') :p ), e ciò che segue sono funzioni e dati definiti in esso.
In questo caso viene restituita una tupla, da cui prelevo ciò che mi serve. Grazie all'uso dei variant il meccanismo di conversione per i tipi standard è completamente trasparente, mentre per quelli non standard è comunque semplice (sono definiti degli attribuiti e/o delle funzioni speciali, come GetItem nel caso di tuple e liste; per il resto si può accedere a qualunque attributo / funzione proprie dell'oggetto; ad esempio v.append('spam'); nel caso in cui v sia una lista).
@log(Log)
def LoadTavoli(frmTavoli):
Designer = frmTavoli.Designer;
for Tavolo in GetData(DBUtils.SQLGetsIter,
'''SELECT t.ID, t.Nome, t.Posti, t.Forma, t.X1, t.Y1, t.X2, t.Y2, t.GlyphPath, t.IDStato, s.Colore
FROM Tavoli t, StatiTavolo s WHERE (t.IDPiano = ?) AND (t.IDStato = s.ID)''', (frmTavoli.IDPiano, )):
T = CreateComponent('TTavolo', Designer)
T.ID, T.Caption, T.Posti = Tavolo[ : 3]
T.Shape = stEllipse if Tavolo[3] else stRectangle
T.Left, T.Top, T.Right, T.Bottom, T.GlyphPath, T.IDStato, T.Color = Tavolo[4 : ]
T.IsCreating = False
Quest'esempietto mostra, invece, come creare al volo dei componenti delphi e inizializzarli da Python. Penso sia autoesplicativo: TTavolo è una classe definita in Delphi. :)
PyScripter lo conosco, ma preferisco nettamente SPE. :)
variabilepippo
07-09-2007, 20:41
Qualche esempietto veloce
Davvero molto interessante, sto già pensando a diversi scenari nei quali potrebbe tornarmi utile questo "gluing" tra linguaggi!
PyScripter lo conosco, ma preferisco nettamente SPE.
Anch'io, però quando si tratta di apportare piccole modifiche preferisco la maggiore "immediatezza" di PyScripter.
Comunque stiamo andando off-topic in questa discussione nata come off-topic. :oink:
un paio di note casuali :D :
- se Vista è lento è perchè non usa abbastanza la RAM (cioè swappa alla grande come il suo predecessore XP :muro: )
- se Linus Torvalds non fosse un ingegnere del software linux sarebbe morto da un pezzo come tanti altri sistemi operativi
- visto che Linus ha sbagliato a fare un SO in C potreste dimostrarlo facendone uno in un altro linguaggio :p
- C++ non è un superset del C :read:
però uno che scrive un software come git in C per me è un pazzo :asd:
Il fatto che col pinguino ci venga buona solo la zuppa non è in tema con il thread. Posso tuttavia spiegare con un esempio il perchè. Un esperimento putativo. Tizio e Caio entrano in un negozio di informatica. Entrambi comprano la periferica per computer XYZ. Sapendo che Tizio usa Windows XP e Caio una qualsiasi distribuzione Linux, quale dei due riuscirà ad installare correttamente la periferica sul proprio PC? Ora, quanti di voi in tutta onestà si sentissero di dire "Caio" mi farebbero un gran piacere dicendomi che tempo fa su Alpha Centauri perchè mi ci vorrei trasferire anche io.
Quanto al fatto che il kernel di Linux faccia schifo (come esempio di software) il suo codice sorgente non è un mistero. Per restare nell'ambito del thread basta leggere sys.c. Prendi la sys_reboot (sys.c, 437, kernel 2.6.9) e ci vedi uno switch, struttura di controllo di per sè paleolitica (è costume nel 2007 usare le mappe di puntatori al posto degli switch, persino in C), parzialmente condizionata in compilazione, con return multipli. Non è un caso isolato: è Torvalds che scrive pessimamente. Dijkstra si rivolterebbe nella tomba leggendo la sua sys_setpgid (1001). Alzi la mano chi ritiene quello buon codice.
Alla suggestiva obiezione "se fa schifo perchè non ne scrivi uno tu" si risponde facilmente: tu mi dai 200 milioni di euro e io metto insieme un team che in quattro anni ti sforna un sistema operativo del XXI secolo.
Tizio e Caio entrano in un negozio di informatica. Entrambi comprano la periferica per computer XYZ. Sapendo che Tizio usa Windows XP e Caio una qualsiasi distribuzione Linux, quale dei due riuscirà ad installare correttamente la periferica sul proprio PC? Ora, quanti di voi in tutta onestà si sentissero di dire "Caio" mi farebbero un gran piacere dicendomi che tempo fa su Alpha Centauri perchè mi ci vorrei trasferire anche io.
suvvia non facciamo i superficiali.. hai mai comprato una periferica che funziona solo per XP per montarla su win98?
Il fatto che col pinguino ci venga buona solo la zuppa non è in tema con il thread. Posso tuttavia spiegare con un esempio il perchè. Un esperimento putativo. Tizio e Caio entrano in un negozio di informatica. Entrambi comprano la periferica per computer XYZ. Sapendo che Tizio usa Windows XP e Caio una qualsiasi distribuzione Linux, quale dei due riuscirà ad installare correttamente la periferica sul proprio PC? Ora, quanti di voi in tutta onestà si sentissero di dire "Caio" mi farebbero un gran piacere dicendomi che tempo fa su Alpha Centauri perchè mi ci vorrei trasferire anche io.
IMHO sei rimasto indietro su Linux. Ho cambiato scheda madre da una per Athlon 64 a una con Intel 965P per Core 2 Duo e mi ha riconosciuto tutte le periferiche compresi 3 controller SATA (Intel, JMicron e Silicon Image) e NIC integrati sulla scheda madre semplicemente riattaccando gli HD sul nuovo PC. HD tra l'altro su scheda SCSI. Addirittura riconosce automaticamente una buonissima parte dei cellulari...come molti LG e molti Motorola.
Stampante laser riconosciuta al volo, scheda video idem.
Attualmente le uniche periferiche che hanno problemi su Linux sono le schede wireless e i modem usb e PCI...tutte le altre funzionano senza installare nemmeno un driver.
perchè pochi lo sanno ma linux è il sistema operativo che supporta più periferiche al mondo (nel caso di windows sono le periferiche che supportano windows :O )
Guarda cionci, io sono felicissimo che a te funzioni ma, detto con candore, non me ne frega niente: mi piacerebbe molto che funzionasse a me :D
Guarda cionci, io sono felicissimo che a te funzioni ma, detto con candore, non me ne frega niente: mi piacerebbe molto che funzionasse a me :D
Ma che distribuzione hai provato ?
Prova una Live di Ubuntu e poi dimmi.
Che sistema hai ?
Prendi la sys_reboot (sys.c, 437, kernel 2.6.9) e ci vedi uno switch, struttura di controllo di per sè paleolitica (è costume nel 2007 usare le mappe di puntatori al posto degli switch, persino in C), parzialmente condizionata in compilazione, con return multipli.
non ci vedo niente di male nella switch (anche perchè esiste in tutti i linguaggi moderni)
Guarda cionci, io sono felicissimo che a te funzioni ma, detto con candore, non me ne frega niente: mi piacerebbe molto che funzionasse a me
e chi ti ha detto di comprare hardware non funzionante, a me va che è una meraviglia sul portatile :fuck:
cdimauro
07-09-2007, 22:01
un paio di note casuali :D :
- se Vista è lento è perchè non usa abbastanza la RAM (cioè swappa alla grande come il suo predecessore XP :muro: )
Su 2GB ho 21MB liberi, di cui 1037MB usati come cache: e per fortuna che è come XP. :p
- se Linus Torvalds non fosse un ingegnere del software linux sarebbe morto da un pezzo come tanti altri sistemi operativi
Puoi cominciare già dalle cazzate mostruose che ha scritto sulle linee guida per lo stile di scrittura del codice, per finire poi ovviamente sulla lettura del codice stesso (che in alcuni casi contraddice le stesse regole di prima :asd: ).
Che il s.o. funzioni e si evolva non v'è dubbio, ma che Torvalds sia un gran programmatore è ampiamente provato. Poi ha avuto il culo di ricevere un mare di supporto da gente con le palle, fra cui Alan Cox & co.
- visto che Linus ha sbagliato a fare un SO in C potreste dimostrarlo facendone uno in un altro linguaggio :p
http://en.wikipedia.org/wiki/List_of_operating_systems
http://www.freebyte.com/operatingsystems/ in particolare:
"Petros is a new 32-bit operating system for the PC platform released by Trumpet Software. Non-bloatware approach (KISS), small in size, modular, based on Object Pascal, and only $ 50 USD.
Petros is a system that is intended to co-exist with and complement the existing platforms rather than supplant them."
Ma ce ne sono tanti altri che non sono scritti in C. ;)
- C++ non è un superset del C :read:
:mbe: Cosa ci sarebbe che ha il C e manca al C++?
cdimauro
07-09-2007, 22:03
non ci vedo niente di male nella switch (anche perchè esiste in tutti i linguaggi moderni)
Non in tutti.
Poi, se leggi bene, PGI aveva scritto anche il perché non usarlo. ;)
Le live non mi vanno (Ubuntu, Mandriva e Sabayon mi pare), nel senso che lo schermo non viene riconosciuto o una cosa del genere, comunque mi si vede tutto a chiazze e strappi. Come monitor uso un Fujitsu-Siemes Miryca SE 32, probabilmente è quello.
L'ultima che ho provato ad installare è stata una OpenSuse, a primavera. Col PC che ho adesso che è un auto-assemblato con una comunissima ASUS, una GeForce6800GS appositamente presa per Linux (e io amo le ATi), un Athlon 64 non mi ricordo più che.
Sul portatile non mi va il risparmio energetico. Già la batteria è stanca di suo, figuriamoci se poi mi va a manetta tutto il tempo. E niente accelerazione 3D (ha una S3 con memoria condivisa che non so neanche da dove l'abbiano tirata fuori).
Comunque il thread non riguarda la mia ostilità verso Linux.
Lo switch c'è, quindi è una buona cosa. Vale quanto nel '15-'18 c'era la guerra, quindi era una buona cosa.
Scherzi a parte, lo switch ha due problemi. In codice macchina diventa una lista di branch. Sinteticamente, il jump è molto più digeribile dalla pipeline del processore. Dal punto di vista comunicativo, e questo è sinceramente quello che più mi preme come sviluppatore, è una comunicazione a messaggio diffuso, nel senso che il significato dell'espressione formata dallo switch è distribuito.
Non è una cosa bizzarra in sè ma è onerosa per chi riceve il messaggio. E' la stessa ragione per cui una risposta ad una domanda è tanto più rapida quanto minore è il numero di vincoli espressi nella richiesta. Questioni su cui non voglio annoiare nessuno.
Su 2GB ho 21MB liberi, di cui 1037MB usati come cache: e per fortuna che è come XP. :p
non lo so io non ho vista ma tutti mi hanno detto che appena lo avvii l'harddisk inizia a macinare. quando lo proverò allora saprò
Puoi cominciare già dalle cazzate mostruose che ha scritto sulle linee guida per lo stile di scrittura del codice, per finire poi ovviamente sulla lettura del codice stesso (che in alcuni casi contraddice le stesse regole di prima :asd: ).
ciò non toglie che sia ingegneria del software. purtroppo ogni metodologia di sviluppo ha i suoi sostenitori e i suoi denigratori. l'unico dato di fatto è che linux ha avuto successo
Che il s.o. funzioni e si evolva non v'è dubbio, ma che Torvalds sia un gran programmatore è ampiamente provato. Poi ha avuto il culo di ricevere un mare di supporto da gente con le palle, fra cui Alan Cox & co.
a quanto ne so è lui che ha tirato fuori dal cilindro git che sta anni luce davanti a cvs e svn per certe cose
[QUOTE=cdimauro;18595460]
http://en.wikipedia.org/wiki/List_of_operating_systems
http://www.freebyte.com/operatingsystems/ in particolare:
"Petros is a new 32-bit operating system for the PC platform released by Trumpet Software. Non-bloatware approach (KISS), small in size, modular, based on Object Pascal, and only $ 50 USD.
Petros is a system that is intended to co-exist with and complement the existing platforms rather than supplant them."
Ma ce ne sono tanti altri che non sono scritti in C. ;)
oh ne conosco un casino di sistemi operativi scritti nei linguaggi più impensabili.. il problema è: qualcuno ha mai dimostrato che scriverli in C sarebbe stato peggio? mi interessano molto i kernel della famiglia l4ka.. in particolare ce n'è uno scritto in C++ parecchio interessante, il solo problema è che non si avvicina ancora alle prestazioni di linux, per cui per ora rimane un progetto bello per la ricerca e basta
:mbe: Cosa ci sarebbe che ha il C e manca al C++?
http://en.wikipedia.org/wiki/C++#Incompatibility_with_C :O
Non in tutti.
Poi, se leggi bene, PGI aveva scritto anche il perché non usarlo. ;)
ha detto che le mappe di puntatori sono meglio, ma io non so come viene trattata una switch dal gcc, per cui mi fido di chi ha scritto quelle righe di codice (pur fidandomi anche di ciò che dice PGI riguardo ai problemi della switch)
http://en.wikipedia.org/wiki/C++#Incompatibility_with_C :O
Il C++ e' un superset stretto del C perche' non c'e' alcun costrutto C che non possa essere espresso in C++ in maniera del tutto equivalente.
Le due incompatibilita' riportate sono dovute, nel primo caso, al fatto che il C non e' un linguaggio strongly typed quindi permette una pericolosa conversione automatica da void* a int*, mentre nel secondo caso l'incompatibilita' e' dovuta alle (poche) keyword che in C++ non possono essere ovviamente usate come identificatori. In entrambi i casi dal punto di vista semantico e espressivo il C non aggiunge nulla.
Torvalds ha torto su tutta la linea perche' qualunque costrutto in C puo' essere espresso in maniera identica in C++, inoltre il C++ puo' esprimere piu' concetti e molti altri concetti in maniera piu' semplice e sicura di quanto sia possibile in C.
Quindi, il C++ e' per forza di cose un linguaggio espressivamente superiore al C, dunque migliore.
cdimauro
07-09-2007, 22:28
non lo so io non ho vista ma tutti mi hanno detto che appena lo avvii l'harddisk inizia a macinare. quando lo proverò allora saprò
Quindi ti basi su "mio cuggggino ha detto che fa schifo". Non sarebbe meglio parlare dopo per lo meno averlo provato? Poi dalla memoria siamo passati allo swap e adesso all'hard disk che macina.
Consiglio: lasciamo perdere che è meglio.
ciò non toglie che sia ingegneria del software. purtroppo ogni metodologia di sviluppo ha i suoi sostenitori e i suoi denigratori.
Come sempre, ma qui il genio ha messo alla graticola un linguaggio e ha sostanzialmente affermato che programmare a oggetti è una cazzata.
Beh, potrà anche essere un ingegnere del software, ma sarebbe meglio che non aprisse bocca se deve dire minchiate conclamate come quelle.
l'unico dato di fatto è che linux ha avuto successo
Anche il DOS e Windows hanno avuto un enorme successo, e non penso che tu ne abbia particolare stima. :asd:
a quanto ne so è lui che ha tirato fuori dal cilindro git che sta anni luce davanti a cvs e svn per certe cose
Lui chi?
oh ne conosco un casino di sistemi operativi scritti nei linguaggi più impensabili.. il problema è: qualcuno ha mai dimostrato che scriverli in C sarebbe stato peggio?
Ne abbiamo parlato una volta qui con fek, che ha partecipato per un po' di tempo allo sviluppo del kernel di OpenBeOS che è scritto in... indovina un po'. :D
mi interessano molto i kernel della famiglia l4ka.. in particolare ce n'è uno scritto in C++ parecchio interessante, il solo problema è che non si avvicina ancora alle prestazioni di linux, per cui per ora rimane un progetto bello per la ricerca e basta
Non li conosco. Comunque le prestazioni dipendono dalla scelta che è stata per l'implementazione del s.o., non dall'adozione del C++.
http://en.wikipedia.org/wiki/C++#Incompatibility_with_C :O
Ne avevamo già parlato, ma vedo che continui a ragionare allo stesso modo: io ti parlo di FUNZIONALITA' (vedi il mio messaggio: "puoi fare le stesse cose") e tu tiri nuovamente in ballo la COMPATIBILITA'.
C'è bisogno che ti ripeta per l'n-esima volta le stesse cose?
L'unica cosa degna di nota è che il C99 ha introdotto delle funzionalità non ancora presenti nel C++, ma che saranno integrate nella prossima versione del linguaggio (e saremo nuovamente punto e da capo).
cdimauro
07-09-2007, 22:29
Il C++ e' un superset stretto del C perche' non c'e' alcun costrutto C che non possa essere espresso in C++ in maniera del tutto equivalente.
Le due incompatibilita' riportate sono dovute, nel primo caso, al fatto che il C non e' un linguaggio strongly typed quindi permette una pericolosa conversione automatica da void* a int*, mentre nel secondo caso l'incompatibilita' e' dovuta alle (poche) keyword che in C++ non possono essere ovviamente usate come identificatori. In entrambi i casi dal punto di vista semantico e espressivo il C non aggiunge nulla.
Torvalds ha torto su tutta la linea perche' qualunque costrutto in C puo' essere espresso in maniera identica in C++, inoltre il C++ puo' esprimere piu' concetti e molti altri concetti in maniera piu' semplice e sicura di quanto sia possibile in C.
Quindi, il C++ e' per forza di cose un linguaggio espressivamente superiore al C, dunque migliore.
:eek: Fregato per un minuto. :p
Ovviamente sono d'accordo su tutto. :D
cdimauro
07-09-2007, 22:35
ha detto che le mappe di puntatori sono meglio, ma io non so come viene trattata una switch dal gcc, per cui mi fido di chi ha scritto quelle righe di codice (pur fidandomi anche di ciò che dice PGI riguardo ai problemi della switch)
In questo modo stai affidando il tutto a un compilatore, e non mi sembra una bella cosa, perché se non sceglie una buona soluzione la velocità d'esecuzione del tuo codice verrà penalizzata.
Discorso diverso, invece, se facessi uso TU di un ALGORITMO che rappresenterebbe una soluzione migliore allo switch di cui sopra, perché NON dipenderesti dalla bontà del compilatore, in quanto avresti già fornito una buona soluzione in partenza. ;)
Per la verità dubito che sia possibile tradurre uno switch con istruzioni di classe diversa dai branch. Non sono però un esperto di compilatori.
L'argomento C vs. C++ deve comunque essere un dente cariato per Torvalds. L'unica volta che un cliente ci ha avuto a che fare direttamente e il discorso è caduto proprio su questa sorta di antitesi ha cominciato a ricevere risposte brusche e, del tutto a torto, irritate. Tra l'altro è parso, va detto che dal mio punto di vista sono cose riportate, che quando va cercare le grane le trova, nel senso che si è infognato in un discorso a difesa della sua creatura, anche qui del tutto a torto perchè non era necessario, nel quale dimostrava di capirne pochino pochino (si trattava dell'interfacciamento di un dispositvo di controllo di una macchina con una postazione Linux). Quello che mi ha stupito un po' è il modo decisamente poco nordico con cui stava discutendo al link che ho segnalato con un interlocutore del tutto pacato e, mi è parso, anche disposto a ragionare.
Non voglio sminuire il grande lavoro svolto da Torvalds, di cui ho usufruito anche io, non ne sono degno, ma, per quanto mi ricordo, il C++ è nato anche per sopperire alle manchevolezze espressive e alla rigidità del C, che, al di là di qualche differenza mi pare non strettamente fondamentale, non ha alcuna potenzialità aggiuntiva. Certo la riscirittura di Linux in C++ potrebbe essere un inferno ma, ritengo in base alle mie esperienze, se fosse effettivamente realizzta potrebbe garantire qualche vantaggio significativo in termini di manutenibilità e organizzazione architetturale senza alcuna perdita sigificativa.
cdimauro
07-09-2007, 22:44
Per la verità dubito che sia possibile tradurre uno switch con istruzioni di classe diversa dai branch. Non sono però un esperto di compilatori.
Si possono tradurre in tabelle di puntatori, ma soltanto se l'insieme dei valori da vagliare è limitato (altrimenti la tabella diventerebbe troppo grande) ed il compilatore ovviamente è abbastanza intelligente da adottare questa soluzione dopo aver analizzato tutto il codice dello switch (ce ne sono che fanno questo lavoro).
Ovviamente dei controlli "minimi" servono, per vedere se il valore appartiene all'intervallo considerato. Poi c'è il branch finale che riporta la CPU alla fine dello switch.
Il C++ e' un superset stretto del C perche' non c'e' alcun costrutto C che non possa essere espresso in C++ in maniera del tutto equivalente.
urca ci vedo doppio :p
se parliamo di potere espressivo però C e C++ sono pari. ho capito che intendi dire che C++ permette metodi "migliori" per esprimere la stessa cosa, ma come ho appena detto esprimono la stessa cosa :fagiano:
Le due incompatibilita' riportate sono dovute, nel primo caso, al fatto che il C non e' un linguaggio strongly typed quindi permette una pericolosa conversione automatica da void* a int*, mentre nel secondo caso l'incompatibilita' e' dovuta alle (poche) keyword che in C++ non possono essere ovviamente usate come identificatori. In entrambi i casi dal punto di vista semantico e espressivo il C non aggiunge nulla.
non so se si è notato ma era leggermente ironico comunque :stordita:
Torvalds ha torto su tutta la linea perche' qualunque costrutto in C puo' essere espresso in maniera identica in C++, inoltre il C++ puo' esprimere piu' concetti e molti altri concetti in maniera piu' semplice e sicura di quanto sia possibile in C.
Quindi, il C++ e' per forza di cose un linguaggio espressivamente superiore al C, dunque migliore.
io penso che a suo tempo Torvalds ha fatto la scelta migliore. il C++ è un linguaggio molto più complesso del C, tanto che i compilatori ci impiegano una vita a implementare tutte le specifiche e alla fine ne viene fuori un lavoro mostruoso e difficile da mantenere e ottimizzare (lo dice uno che di compilatori c++ se ne intende: Walter Bright)
il c++ permette molti paradigmi di programmazione e infinite possibilità, ma questo comporta che ogni programmatore si focalizza su un subset del c++ (questo perchè imparare proprio tutto quello che c'è da sapere sul c++ è quasi pazzia) e spesso quando si incontrano due programmatori pur parlando sempre di c++ non si capiscono bene.
Torvalds avrà pure fatto una scelta discutibile ma i fatti gli anno dato ragione fino a prova contraria. quando ci sarà un kernel in grado di sostituire linux potremo dire che è diventata preistoria, ma anche se fosse è stato comunque un successo
cdimauro
07-09-2007, 22:51
L'argomento C vs. C++ deve comunque essere un dente cariato per Torvalds. L'unica volta che un cliente ci ha avuto a che fare direttamente e il discorso è caduto proprio su questa sorta di antitesi ha cominciato a ricevere risposte brusche e, del tutto a torto, irritate. Tra l'altro è parso, va detto che dal mio punto di vista sono cose riportate, che quando va cercare le grane le trova, nel senso che si è infognato in un discorso a difesa della sua creatura, anche qui del tutto a torto perchè non era necessario, nel quale dimostrava di capirne pochino pochino (si trattava dell'interfacciamento di un dispositvo di controllo di una macchina con una postazione Linux). Quello che mi ha stupito un po' è il modo decisamente poco nordico con cui stava discutendo al link che ho segnalato con un interlocutore del tutto pacato e, mi è parso, anche disposto a ragionare.
Torvalds invece non è abituato a ragionare, ma imporre soltanto la sua (scarsa) visione delle cose. Ecco perché scade SUBITO nella rissa con insulti e parolacce: segno evidente di chi non è in grado di sostenere le proprie idee, e si trincera dietro un successo ampiamente immeritato (come dicevo prima, ha avuto culo perché dietro ha uno staff di spessore).
Non voglio sminuire il grande lavoro svolto da Torvalds, di cui ho usufruito anche io, non ne sono degno, ma, per quanto mi ricordo, il C++ è nato anche per sopperire alle manchevolezze espressive e alla rigidità del C, che, al di là di qualche differenza mi pare non strettamente fondamentale, non ha alcuna potenzialità aggiuntiva. Certo la riscirittura di Linux in C++ potrebbe essere un inferno ma, ritengo in base alle mie esperienze, se fosse effettivamente realizzta potrebbe garantire qualche vantaggio significativo in termini di manutenibilità e organizzazione architetturale senza alcuna perdita sigificativa.
Esattamente. D'altra parte che dei progetti vengano convertiti da C a C++ per ottenere ciò che dici è cosa comune, a chi ovviamente ha un briciolo di buon senso.
Esempio: http://www.firebirdsql.org/ Ha avuto origine da InterBase 6.0, che era scritto in C. Dopo la prima versione di FB, che era sostanzialmente un bug fix di IB6 e l'aggiunta di questa caratteristica, il team ha deciso di convertire tutto il codice in C++, e ciò è avvenuto con la versione 1.5.
Provate a chiedere se tornerebbero al C, ma non garantisco per la vostra incolumità. :asd:
cdimauro
07-09-2007, 22:54
urca ci vedo doppio :p
se parliamo di potere espressivo però C e C++ sono pari. ho capito che intendi dire che C++ permette metodi "migliori" per esprimere la stessa cosa, ma come ho appena detto esprimono la stessa cosa :fagiano:
No, l'espressività è cosa diversa e C++ parte nettamente in vantaggio.
non so se si è notato ma era leggermente ironico comunque :stordita:
Ehm. No, io non l'avevo notato.
io penso che a suo tempo Torvalds ha fatto la scelta migliore. il C++ è un linguaggio molto più complesso del C, tanto che i compilatori ci impiegano una vita a implementare tutte le specifiche e alla fine ne viene fuori un lavoro mostruoso e difficile da mantenere e ottimizzare (lo dice uno che di compilatori c++ se ne intende: Walter Bright)
il c++ permette molti paradigmi di programmazione e infinite possibilità, ma questo comporta che ogni programmatore si focalizza su un subset del c++ (questo perchè imparare proprio tutto quello che c'è da sapere sul c++ è quasi pazzia) e spesso quando si incontrano due programmatori pur parlando sempre di c++ non si capiscono bene.
Questo dimostra soltanto che non è capace di usare un potente strumento qual è il C++: tanti altri programmatori, stranamente (!), ci riescono benissimo. ;)
Torvalds avrà pure fatto una scelta discutibile ma i fatti gli anno dato ragione fino a prova contraria. quando ci sarà un kernel in grado di sostituire linux potremo dire che è diventata preistoria, ma anche se fosse è stato comunque un successo
Questo, come ho detto prima, non c'entra nulla con la bontà di un linguaggio.
Quindi ti basi su "mio cuggggino ha detto che fa schifo". Non sarebbe meglio parlare dopo per lo meno averlo provato? Poi dalla memoria siamo passati allo swap e adesso all'hard disk che macina.
Consiglio: lasciamo perdere che è meglio.
sisi infatti ho detto che se mai proverò ti farò sapere, comunque il mio discorso era linearissimo.. la memoria di XP è gestita male nel senso che inizia a swappare anche con diverse centinaia di mega di ram liberi. e swappare equivale a HD che macina in gergo :D
Come sempre, ma qui il genio ha messo alla graticola un linguaggio e ha sostanzialmente affermato che programmare a oggetti è una cazzata.
non dovresti prenderlo alla lettera, ha scritto anche cose come:
I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.
:rotfl:
Beh, potrà anche essere un ingegnere del software, ma sarebbe meglio che non aprisse bocca se deve dire minchiate conclamate come quelle.
è anche un divulgatore, non lo si può mica uccidere per questo :boh:
Anche il DOS e Windows hanno avuto un enorme successo, e non penso che tu ne abbia particolare stima. :asd:
DOS pochi sanno che vuol dire Dirty Operating System :asd: per windows da NT in poi non ho particolari accuse da rivolgergli... a parte che è configurato male di default
Lui chi?
Mr. faccio tutto io il kernel :O
Ne abbiamo parlato una volta qui con fek, che ha partecipato per un po' di tempo allo sviluppo del kernel di OpenBeOS che è scritto in... indovina un po'. :D
vuoi dire haiku?
si ma ti ho già detto che i kernel si possono scrivere benissimo in qualsiasi linguaggio.. il problema è dimostrare che sono migliori
Non li conosco. Comunque le prestazioni dipendono dalla scelta che è stata per l'implementazione del s.o., non dall'adozione del C++.
dipende un pò da tutto... per questo è difficile valutare
Ne avevamo già parlato, ma vedo che continui a ragionare allo stesso modo: io ti parlo di FUNZIONALITA' (vedi il mio messaggio: "puoi fare le stesse cose") e tu tiri nuovamente in ballo la COMPATIBILITA'.
C'è bisogno che ti ripeta per l'n-esima volta le stesse cose?
L'unica cosa degna di nota è che il C99 ha introdotto delle funzionalità non ancora presenti nel C++, ma che saranno integrate nella prossima versione del linguaggio (e saremo nuovamente punto e da capo).
massì era un'affermazione volutamente puntigliosa ;)
cdimauro
07-09-2007, 23:09
sisi infatti ho detto che se mai proverò ti farò sapere, comunque il mio discorso era linearissimo.. la memoria di XP è gestita male nel senso che inizia a swappare anche con diverse centinaia di mega di ram liberi. e swappare equivale a HD che macina in gergo :D
Ma HD che macina non equivale a swappare. ;)
non dovresti prenderlo alla lettera, ha scritto anche cose come:
I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.
:rotfl:
L'ironia ci può stare in una battuta, non in una discussione seria come quella in oggetto, che non ha certo bisogno di offese e parolacce.
è anche un divulgatore, non lo si può mica uccidere per questo :boh:
Infatti lo si uccide per le stronzate che dice, non per tutto quello gli esce dalla bocca. :D
DOS pochi sanno che vuol dire Dirty Operating System :asd: per windows da NT in poi non ho particolari accuse da rivolgergli... a parte che è configurato male di default
Hai eluso il contesto evitando di rispondere. ;)
Mr. faccio tutto io il kernel :O
Capito. Ne avrà avuto bisogno per il suo lavoro.
vuoi dire haiku?
Ai miei tempi si chiamava OpenBeOS. :D
si ma ti ho già detto che i kernel si possono scrivere benissimo in qualsiasi linguaggio.. il problema è dimostrare che sono migliori
Questo, e lo ripeto nuovamente, dipende dalla scelte progettuali che sono state fatte per il kernel. Il linguaggio è soltanto un mezzo per raggiungere il fine, e preferisco usare quello che mi permette di arrivarci più comodamente. ;)
dipende un pò da tutto... per questo è difficile valutare
Non la scelta del linguaggio però. Vedi sopra.
massì era un'affermazione volutamente puntigliosa ;)
Ah, ecco. :D
Adesso è ora di andare a nanna però. Notte a tutti. :)
Capito. Ne avrà avuto bisogno per il suo lavoro.
giusto una chicca per conciliare il sonno... certo ne ha avuto bisogno per il lavoro, ma è il motivo che fa sorridere.
in principio usava bitkeeper che era un prodotto commerciale, poi arrivò un tale di nome Andrew Tridgell (si è lo stesso del protocollo smb) che decise di usare il reverse engineering per scrivere un client opensource compatibile con bitkeeper. a quel punto la gente di bitkeeper si offese e negò la licenza a linus che a sua volta si offese e riempì di insulti Andrew Tridgell.
ma entriamo nel dettaglio della faccenda... il reverse engineering di Tridgell consistette nei seguenti passi:
aprì telnet connettendosi alla porta usata da bitkeeper, si chiese cosa fare... digitò help e ottenne la lista dei comandi disponibili, dopodichè provò a dare il comando clone e scoprì che l'output era una serie di files in formato SCCS
ecco la vera storia del reverse engineering di bitkeeper :muro:
per cui linus si trovò costretto a implementare un software equivalente a bitkeeper in pochissimo tempo e il risultato pare un gran bel software dalle caratteristiche di rilievo
Sono stanco anche io ma è stata una chiaccherata interessante, grazie a tutti voi. In questo momento mi sto sbattendo con Ruby on Rails e quindi sono decisamente fuori dalla mischia. Cmq per chi non l'avesse fatto, credo che leggere i post di Torvalds e del povero Dmitri Kakurin sia interessante al di là di tutto ad es. questo passaggio chiarisce decisamente come la pensa Linus (che non manca di esternare la sua stima al suo interlocutore)
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
The very fact that you come in as a newbie, point to some absolutely
*trivial* patches, and use that as an argument for a language that the
original author doesn't like, is a sign of you being a person who should
be disabused on any idiotic notions as soon as possible.
The things that actually *matter* for core git code is things like writing
your own object allocator to make the footprint be as small as possible in
order to be able to keep track of object flags for a million objects
efficiently. It's writing a parser for the tree objects that is basically
fairly optimal, because there *is* no abstraction. Absolutely all of it is
at the raw memory byte level.
Can those kinds of things be written in other languages than C? Sure. But
they can *not* be written by people who think the "high-level"
capabilities of C++ string handling somehow matter.
The fact is, that is *exactly* the kinds of things that C excels at. Not
just as a language, but as a required *mentality*. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
negò la licenza a linus che a sua volta si offese e riempì di insulti Andrew Tridgell.
Allora ce l'ha proprio nel sangue :D
Torvalds ha torto su tutta la linea perche' qualunque costrutto in C puo' essere espresso in maniera identica in C++, inoltre il C++ puo' esprimere piu' concetti e molti altri concetti in maniera piu' semplice e sicura di quanto sia possibile in C.
Quindi, il C++ e' per forza di cose un linguaggio espressivamente superiore al C, dunque migliore.
Non concordo con quello che dice Torvalds, ma da un certo punto di vista lo posso capire, almeno fintanto che si riferisce alla programmazione di sistema. Anche la maggior parte dei miei colleghi di lavoro ha a che fare con l'hardware e mentre se la cavano tutti benone col C ma non riescono a usare "bene" il C++, forse proprio perche' il C e' di piu' basso livello.
Cioè generi una funzione di hash perfetta per l'insieme di valori di controllo e li trasformi in indirizzi?
Ps: mi riferivo al post di cdmauro delle 23:44. Ragazzi, stiamo qui a parlare di sistemi operativi... ma un bel forum "in tempo reale" non sarebbe una bella cosa? Un chat, con il forum a mo' di log organizzato. Come si dice... tante cose da fare e così poco tempo per farle...
Sono stanco anche io ma è stata una chiaccherata interessante, grazie a tutti voi. In questo momento mi sto sbattendo con Ruby on Rails e quindi sono decisamente fuori dalla mischia. Cmq per chi non l'avesse fatto, credo che leggere i post di Torvalds e del povero Dmitri Kakurin sia interessante al di là di tutto ad es. questo passaggio chiarisce decisamente come la pensa Linus (che non manca di esternare la sua stima al suo interlocutore)
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
The very fact that you come in as a newbie, point to some absolutely
*trivial* patches, and use that as an argument for a language that the
original author doesn't like, is a sign of you being a person who should
be disabused on any idiotic notions as soon as possible.
The things that actually *matter* for core git code is things like writing
your own object allocator to make the footprint be as small as possible in
order to be able to keep track of object flags for a million objects
efficiently. It's writing a parser for the tree objects that is basically
fairly optimal, because there *is* no abstraction. Absolutely all of it is
at the raw memory byte level.
Can those kinds of things be written in other languages than C? Sure. But
they can *not* be written by people who think the "high-level"
capabilities of C++ string handling somehow matter.
The fact is, that is *exactly* the kinds of things that C excels at. Not
just as a language, but as a required *mentality*. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
Sebbene scritto da un altro, sembra la spiegazione dell'odio di Torvalds per il C++, ovvero che le astrazioni aggiungano necessariamente dei costi, oltre al fatto che rendono piu' difficile da comprendere il codice. Non e' vero in entrambi i casi, anche se effettivamente non viene "gratis" (soprattutto col C++).
Cioè generi una funzione di hash perfetta per l'insieme di valori di controllo e li trasformi in indirizzi?
Ps: mi riferivo al post di cdmauro delle 23:44. Ragazzi, stiamo qui a parlare di sistemi operativi... ma un bel forum "in tempo reale" non sarebbe una bella cosa? Un chat, con il forum a mo' di log organizzato. Come si dice... tante cose da fare e così poco tempo per farle...
Ricordo i tentativi per una chat un po' di anni fa... :D
L'ideale sarebbe l'accodamento in stile newsgroup, ma allora tanto varrebbe spostarsi (appunto :D) su di un newsgroup :D
cdimauro
08-09-2007, 04:26
Che il s.o. funzioni e si evolva non v'è dubbio, ma che Torvalds NON sia un gran programmatore è ampiamente provato. Poi ha avuto il culo di ricevere un mare di supporto da gente con le palle, fra cui Alan Cox & co.
Rileggendomi non avevo messo un NON, per cui la frase assumeva il significato opposto. :|
Adesso va bene. :D
cdimauro
08-09-2007, 04:55
giusto una chicca per conciliare il sonno... certo ne ha avuto bisogno per il lavoro, ma è il motivo che fa sorridere.
in principio usava bitkeeper che era un prodotto commerciale,
Ma gli altri puristi non si scandalizzavano? :D
poi arrivò un tale di nome Andrew Tridgell (si è lo stesso del protocollo smb) che decise di usare il reverse engineering per scrivere un client opensource compatibile con bitkeeper. a quel punto la gente di bitkeeper si offese e negò la licenza a linus che a sua volta si offese e riempì di insulti Andrew Tridgell.
:rotfl:
ma entriamo nel dettaglio della faccenda... il reverse engineering di Tridgell consistette nei seguenti passi:
aprì telnet connettendosi alla porta usata da bitkeeper, si chiese cosa fare... digitò help e ottenne la lista dei comandi disponibili, dopodichè provò a dare il comando clone e scoprì che l'output era una serie di files in formato SCCS
ecco la vera storia del reverse engineering di bitkeeper :muro:
Una minchiata, insomma. :D
per cui linus si trovò costretto a implementare un software equivalente a bitkeeper in pochissimo tempo e il risultato pare un gran bel software dalle caratteristiche di rilievo
OK, bella storia, ma non mi pare ci sia niente di particolare: progetti così ne nascono a bizzeffe.
cdimauro
08-09-2007, 04:57
Sono stanco anche io ma è stata una chiaccherata interessante, grazie a tutti voi. In questo momento mi sto sbattendo con Ruby on Rails e quindi sono decisamente fuori dalla mischia. Cmq per chi non l'avesse fatto, credo che leggere i post di Torvalds e del povero Dmitri Kakurin sia interessante al di là di tutto ad es. questo passaggio chiarisce decisamente come la pensa Linus (che non manca di esternare la sua stima al suo interlocutore)
You can write bad code in any language. However, some languages, and
especially some *mental* baggages that go with them are bad.
The very fact that you come in as a newbie, point to some absolutely
*trivial* patches, and use that as an argument for a language that the
original author doesn't like, is a sign of you being a person who should
be disabused on any idiotic notions as soon as possible.
The things that actually *matter* for core git code is things like writing
your own object allocator to make the footprint be as small as possible in
order to be able to keep track of object flags for a million objects
efficiently. It's writing a parser for the tree objects that is basically
fairly optimal, because there *is* no abstraction. Absolutely all of it is
at the raw memory byte level.
Can those kinds of things be written in other languages than C? Sure. But
they can *not* be written by people who think the "high-level"
capabilities of C++ string handling somehow matter.
The fact is, that is *exactly* the kinds of things that C excels at. Not
just as a language, but as a required *mentality*. One of the great
strengths of C is that it doesn't make you think of your program as
anything high-level. It's what makes you apparently prefer other
languages, but the thing is, from a git standpoint, "high level" is
exactly the wrong thing.
Mi sono già letto tutti i suoi interventi, e non c'è nulla di nuovo: è sempre il solito egocentrico e borioso programmatore da due soldi che ha imparato a fare una cosa e continua sempre così, rifiutando ogni evoluzione.
cdimauro
08-09-2007, 05:02
Allora ce l'ha proprio nel sangue :D
E' un automa a stati finiti, e ne ha esattamente due: calmo e incazzato contro l'umanità.
Normalmente è calmo, ma è sufficiente qualunque cosa non sia in linea col suo pensiero limitato a farlo passare allo stato di incazzato contro l'umanità.
Ovviamente la transizione dal primo al secondo stato è accompagnata da offese e parolacce. Idem per quelle che riportano sempre al secondo stato.
Torna allo stato di calmo soltanto dopo aver sfoderato tutto il suo repertorio, quindi generalmente dopo pochi interventi. :D
cdimauro
08-09-2007, 05:09
Non concordo con quello che dice Torvalds, ma da un certo punto di vista lo posso capire, almeno fintanto che si riferisce alla programmazione di sistema. Anche la maggior parte dei miei colleghi di lavoro ha a che fare con l'hardware e mentre se la cavano tutti benone col C ma non riescono a usare "bene" il C++, forse proprio perche' il C e' di piu' basso livello.
Il C++ può essere di basso livello tanto quanto il C: bisogna "soltanto" imparare a usare lo strumento giusto a seconda del tipo di (sotto)problema da risolvere.
Per far ciò è necessaria parecchia esperienza: bisogna entrare nella mentalità del programmatore C++, perché il linguaggio è complesso e ogni strumento merita d'esser sviscerato e "maturato".
Non sono d'accordo sul fatto che la programmazione di sistema debba essere relegata all'uso di strumenti di basso livello: proprio la presenza di s.o. scritti con linguaggi di livello più alto ne è, appunto, una controprova.
Come già detto si tratta di usare gli strumenti che il C++ (o qualunque altro linguaggio di alto livello) mette a disposizione nel giusto modo e al momento giusto.
Tanto per dirne una: non mi aspetto che all'interno della funzione malloc del s.o. venga utilizzato l'operatore new per allocare memoria per un oggetto, se non eventualmente dopo aver ridefinito opportunamente le funzioni di dis/allocazione da new e delete. ;)
cdimauro
08-09-2007, 05:16
Cioè generi una funzione di hash perfetta per l'insieme di valori di controllo e li trasformi in indirizzi?
Le funzioni di hash perfette rappresenterebbero la perfezione. :D
No, quello che si usa in genere è una banale tabella di puntatori la cui chiave è rappresentata da valori interi sequenziali.
Ad esempio, se devo scrivere un emulatore 6502, per lo switch che esegue un'istruzione userò internamente una tabella di 256 valori con l'indice che va da 0 a 255.
Ovviamente l'uso delle funzioni di hash perfette rappresenterebbe l'optimum, ma non ricordo di nessun compilatore che sia in grado di usarle per "sbrogliare" uno switch convertendolo in una tabella di puntatori.
Tempo fa, analizzando il codice del compilatore GCC ricordo che la funzione di hash sulle keyword veniva calcolata "off-line", per poi essere inserita all'interno del codice doveva serviva. Ma è passato molto tempo e non so se adesso il compilatore "faccia tutto da solo". :p
Ps: mi riferivo al post di cdmauro delle 23:44. Ragazzi, stiamo qui a parlare di sistemi operativi... ma un bel forum "in tempo reale" non sarebbe una bella cosa? Un chat, con il forum a mo' di log organizzato. Come si dice... tante cose da fare e così poco tempo per farle...
In effetti capita non di rado di passare da un argomento a un altro completamente diverso. :D
cdimauro
08-09-2007, 05:18
Sebbene scritto da un altro, sembra la spiegazione dell'odio di Torvalds per il C++, ovvero che le astrazioni aggiungano necessariamente dei costi, oltre al fatto che rendono piu' difficile da comprendere il codice. Non e' vero in entrambi i casi, anche se effettivamente non viene "gratis" (soprattutto col C++).
Diciamo che Linus ha ben poca idea di come funzioni un compilatore moderno e di come genera il codice.
Sarà ancora convinto che i compilatori C++ generino codice di più scarsa qualità rispetto a quelli C. :rolleyes:
mindwings
08-09-2007, 08:27
Se alcuni produttori hw si rifiutano di scrivere dei driver delle loro periferiche per linux non è colpa di linux:) premesso che è un SO che ha il supporto per una miriade di periferiche hw . Giusto per fare un esempio , avevo una scheda di rete isa slot:D bè è perfettamente riconosciuta e funzionante , stessa cosa non si può dire di Xp. Altra differenza ogni sistema operativo targato MS ti "costringe "
a rinnovare l'hw , con linux non succede...:fagiano:
Negli ultimi tempi il supporto hw è migliorato tantissimo , anche ati adesso si muove...
E chiamalo relitto...:D
A proposito di oggetti e di C
http://en.wikipedia.org/wiki/GObject
cdimauro
08-09-2007, 08:36
http://upload.wikimedia.org/wikipedia/commons/1/17/GObject_example.png
Molto bello, elegante, facile da leggere e comprendere. :asd:
Per il resto, se vuoi utilizzare software di un certo spessore anche con Linux sei costretto a rinnovare l'hardware: le risorse servono per tutti i s.o., c'è poco da fare. ;) Comunque siamo OT.
P.S. Con "relitto" credo che PGI si riferisse ad altro. :p
mindwings
08-09-2007, 08:41
cut
Per il resto, se vuoi utilizzare software di un certo spessore anche con Linux sei costretto a rinnovare l'hardware: le risorse servono per tutti i s.o., c'è poco da fare. ;) Comunque siamo OT.
cut
gia ma con un SO (windows)sei limitato di default o rinnovi o nemmeno lo puoi installare.(logiche di mercato?)
Ti sei fermato all'apparenza :muro: (GObject)
resta il fatto che la programmazione ad oggetti è possibile anche con il C
bisognerebbe chiederlo agli sviluppatori di GNOME :D
Edit : sarebbe il software di spessore? :D
cdimauro
08-09-2007, 09:02
gia ma con un SO (windows)sei limitato di default o rinnovi o nemmeno lo puoi installare.(logiche di mercato?)
Vista (x64) l'ho installato sulla macchina su cui c'era già XP x64, e il sistema funziona MEGLIO che con quest'ultimo.
Fine OT.
Ti sei fermato all'apparenza :muro: (GObject)
All'apparenza? No, mi sono fermato a quello che un qualunque programmatore che abbia un briciolo di cognizione di cosa significhi programmazione a oggetti, e soprattutto ci lavora, vede: un sistema ORRENDO che cerca di IMITARE ciò che altri linguaggi offrono NATIVAMENTE in maniera più semplice, leggibile, comprensibile e manutenibile.
resta il fatto che la programmazione ad oggetti è possibile anche con il C
Questo qualcuno qui l'ha negato? Non mi risulta.
D'altra parte con la programmazione a oggetti ci lavoravo già con l'Amiga, ma in assembly. Però trovavo fosse LEGGERMENTE più comodo lavorarci col Turbo Pascal 5.5 di Borland, eh! :asd:
bisognerebbe chiederlo agli sviluppatori di GNOME :D
In effetti bisognerebbe farli controllare da qualche specialista perché se si sono inventati quella roba sono come minimo dei masochisti autolesionisti. :asd:
Edit : sarebbe il software di spessore? :D
Un software che è spesso. :D
KDE, Evolution, Eclipse, Poseidon, e cazzi e mazzi vari. Son capaci ti buttare giù una macchina ben dotata (specialmente Evolution, che coi memory leak di cui è mostruosamente affetto è in grado di succhare memoria fino a saturare perfino il file di swap, facendo andare il PC per 10 secondi sì e per un minuto bloccato a rullare con l'hd lasciandoti soltanto il puntatore del mouse da poter muovere).
Poi è chiaro che se ti serve soltanto vi e una shell, ti può bastare anche un 386. D'altra parte è noto, no? Real programmers don't use mice and GUIs... :asd:
Adesso scusami ma vado a passare la giornata fuori con la mia famigliola (e vediamo se ce la faccio ad andare in piazza per il vaffanculo-day :p).
Buona giornata a tutti (anche ai programmatori scarsi :D).
mindwings
08-09-2007, 09:21
Vista (x64) l'ho installato sulla macchina su cui c'era già XP x64, e il sistema funziona MEGLIO che con quest'ultimo.
Fine OT.
All'apparenza? No, mi sono fermato a quello che un qualunque programmatore che abbia un briciolo di cognizione di cosa significhi programmazione a oggetti, e soprattutto ci lavora, vede: un sistema ORRENDO che cerca di IMITARE ciò che altri linguaggi offrono NATIVAMENTE in maniera più semplice, leggibile, comprensibile e manutenibile.
Questo qualcuno qui l'ha negato? Non mi risulta.
D'altra parte con la programmazione a oggetti ci lavoravo già con l'Amiga, ma in assembly. Però trovavo fosse LEGGERMENTE più comodo lavorarci col Turbo Pascal 5.5 di Borland, eh! :asd:
In effetti bisognerebbe farli controllare da qualche specialista perché se si sono inventati quella roba sono come minimo dei masochisti autolesionisti. :asd:
Un software che è spesso. :D
KDE, Evolution, Eclipse, Poseidon, e cazzi e mazzi vari. Son capaci ti buttare giù una macchina ben dotata (specialmente Evolution, che coi memory leak di cui è mostruosamente affetto è in grado di succhare memoria fino a saturare perfino il file di swap, facendo andare il PC per 10 secondi sì e per un minuto bloccato a rullare con l'hd lasciandoti soltanto il puntatore del mouse da poter muovere).
Poi è chiaro che se ti serve soltanto vi e una shell, ti può bastare anche un 386. D'altra parte è noto, no? Real programmers don't use mice and GUIs... :asd:
Adesso scusami ma vado a passare la giornata fuori con la mia famigliola (e vediamo se ce la faccio ad andare in piazza per il vaffanculo-day :p).
Buona giornata a tutti (anche ai programmatori scarsi :D).
Gnome+Eclipse ci girano tranquillamente con 512 mb di ram :D
Se uno usa Kde solitamente usa Kmail che è un ottimo software e non Evolution
con Vista con 512 mb di ram non vai da nessuna parte :D .Se ci devi usare aero con Vista devi avere una Buona scheda grafica ,in ambiente linux una geforce4 qualunque ti permette di avere gli stessi effetti grafici (io personalmente non li uso , per dovere di cronaca)...
Già autolesionisti e cerebrolesi :doh: ...
C'è qualcuno che ci riesce a programmare in quel modo
che a te pare orrendo :mbe:
Se non ci riesci non importa
qualcuno lo fa e con ottimi risultati ---> Gimp:fiufiu:
Buon V-Day
mindwings
08-09-2007, 09:38
Poi è chiaro che se ti serve soltanto vi e una shell, ti può bastare anche un 386. D'altra parte è noto, no? Real programmers don't use mice and GUIs... :asd:
Ognuno può usare quello che vuole per scrivere codice...
La differenza sta in quello che scrive, in ciò che crea. Se un programmatore
è talentuoso lo sarà con qualsiasi strumento...:fagiano:
L'importante è ciò che produce ognuno utilizza lo strumento che più gli conviene.
Puoi avere la racchetta migliore del mondo ma non per questo puoi esprimere il gioco di Federer:D
urca ci vedo doppio :p
se parliamo di potere espressivo però C e C++ sono pari. ho capito che intendi dire che C++ permette metodi "migliori" per esprimere la stessa cosa, ma come ho appena detto esprimono la stessa cosa :fagiano:
No. In C non puoi esprimere algoritmi che sono eseguiti a compile time (metaprogrammazione) come parte integrante del linguaggio. Non ha i template.
Se alcuni produttori hw si rifiutano di scrivere dei driver ...premesso che è un SO che ha il supporto per una miriade di periferiche hw . Giusto per fare un esempio ... è perfettamente riconosciuta e funzionante ... Negli ultimi tempi il supporto hw è migliorato tantissimo
Io non dubito di questo e sono sinceramente estasiato di fronte a tanta abbondanza. Ma con me non lo fa. Sarà che gli sto sui finferli.
variabilepippo
08-09-2007, 10:53
No. In C non puoi esprimere algoritmi che sono eseguiti a compile time (metaprogrammazione) come parte integrante del linguaggio. Non ha i template.
Non sono un fautore del C ma è giusto dare al C ciò che è del C (http://forum.ioprogrammo.it/thread.php?threadid=12429&boardid=20)! ;)
Come segnalato nel collegamento si può fare (http://www.angelfire.com/linux/csoroz/ooc/index.html), però credo che una persona "normale" dovrebbe occupare diversamente il proprio tempo.
P.S. C'è addirittura qualche folle che programma ad oggetti in Assembly (http://www.angelfire.com/scifi/win32asm/Nan_Src.html). :muro:
La teoria del fare programmazione orientata agli oggetti in Assembly ha un che di strano. Io mi domando, ad esempio, come sia possibile esprimere una relazione tra oggetti avendo a disposizione una manciata di registri prenominati.
mindwings
08-09-2007, 11:13
Io non dubito di questo e sono sinceramente estasiato di fronte a tanta abbondanza. Ma con me non lo fa. Sarà che gli sto sui finferli.
Anche io all'inizio ho avuto problemi , ma si possono superare :fagiano:
i pregiudizi proprio non li mando giu della serie : " chi usa linux ha tempo da perdere " :mbe:
Uso con molta soddisfazione sia Xp che Debian Linux :sofico:
variabilepippo
08-09-2007, 11:17
La teoria del fare programmazione orientata agli oggetti in Assembly ha un che di strano. Io mi domando, ad esempio, come sia possibile esprimere una relazione tra oggetti avendo a disposizione una manciata di registri prenominati.
Ho citato la possibilità di sviluppare con il paradigma ad oggetti in Assembly solo a titolo di nota folcloristica.
D'altra parte se un compilatore C++ genera codice Assembly partendo da una rappresentazione ad alto livello di gerarchie ad oggetti non vedo perché un programmatore masochista, in vena di martoriamento di zebedei, non possa scrivere a manina ciò che il compilatore genera in automatico.
La possibilità di fare programmazione orientata agli oggetti si fonda sulla capacità dei compilatori di operare non solo come traduttori simbolici ma anche come trasformatori di prospettiva (da OO a procedurale nel caso di linguaggio OO).
Scrivere a mano ciò che produrrebbe un compilatore a fronte di un codice sorgente OO non è orientamento agli oggetti. Perchè il prodotto finale della compilazione è sempre ed immancabilmente procedurale. Lo è perchè la macchina che dovrà interpretare quel prodotto è meccanicamente vincolata ad un interpretazione procedurale dei fenomeni.
No. In C non puoi esprimere algoritmi che sono eseguiti a compile time (metaprogrammazione) come parte integrante del linguaggio. Non ha i template.
a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo... comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)
#define SWAP(a, b, type) { type __tmp_c; c = b; b = a; a = c; }
int main()
{
int a = 3;
int b = 5;
printf("a is %d and b is %d\n", a, b);
SWAP(a, b, int);
printf("a is now %d and b is now %d\n", a, b);
return 0;
}
inoltre se parliamo di C++ i template non sono sempre una soluzione elegante e/o efficiente
http://people.cs.uchicago.edu/~jacobm/pubs/templates.html
soprattutto quando dice
C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn't know, so it has to just blindly apply the copy-and-paste strategy and then see what happens
variabilepippo
08-09-2007, 11:53
La possibilità di fare programmazione orientata agli oggetti si fonda sulla capacità dei compilatori di operare non solo come traduttori simbolici ma anche come trasformatori di prospettiva (da OO a procedurale nel caso di linguaggio OO).
La possibilità di mappare entità reali in oggetti ti è data dalla presenza di opportuni costrutti sintattici, nulla ti vieta di scrivere macro e strutture adatte a rappresentare oggetti in Assembly. Sono convinto che non ne valga assolutamente la pena (per una lunghissima serie di ragioni), ma tecnicamente si può fare, come è d'altronde dimostrato dai numerosi esempi reperibili on-line.
Considera poi che il C++ è nato come un "C con le classi" (http://www.research.att.com/~bs/bs_faq.html):
To build that, I first used C to write a "C with Classes"-to-C preprocessor. "C with Classes" was a C dialect that became the immediate ancestor to C++. That preprocessor translated "C with Classes" constructs (such as classes and constructors) into C. It was a traditional preprocessor that didn't understand all of the language, left most of the type checking for the C compiler to do, and translated individual constructs without complete knowledge. I then wrote the first version of Cfront in "C with Classes".
Cfront was a traditional compiler that did complete syntax and semantic checking of the C++ source. For that, it had a complete parser, built symbol tables, and built a complete internal tree representation of each class, function, etc. It also did some source level optimization on its internal tree representation of C++ constructs before outputting C. The version that generated C, did not rely on C for any type checking. It simply used C as an assembler. The resulting code was uncompromisingly fast.
Ed il C non è altro che un Assembly "on steroids (http://forum.ioprogrammo.it/thread.php?threadid=12429&boardid=20)":
Naturalmente è possibile programmare "ad oggetti" e "per template" in Assembly puro (alla fine dei conti questo è ciò che producono i vari compilatori), e per estensione anche in ANSI/ISO C'89/99. Tuttavia si tratta di un passatempo assai poco salutare, sebbene non manchino esempi notevoli in merito (http://www.angelfire.com/linux/csoroz/ooc/index.html).
Entità reale ed oggetto sono sinonimi. Non c'è un'associazione da fare. Credo che la definizione di forme sintattiche idonee a rappresentare gli oggetti corrisponda all'estensione del linguaggio.
Credo che il rapporto originario tra C e C++ da te citato sia un buon esempio. Come disse Alan Kay, C++ nasce come preprocessore di C, cioè introduce una serie di forme riconducibili a definizione C attraverso trasformazioni sintattiche automattizate.
Estende il linguaggio perchè l'atto di predisporre queste forme, l'atto di introdurre nel linguaggio questi opportuni costrutti, deve essere ripetuto ogni volta che si scriva un programma in una prospettiva diversa da quella che è naturale per il linguaggio. E', ancora una volta, la famigerata trappola di turing: un linguaggio non supporta una caratteristica se tale caratteristica deve essere definita ogni volta che la si voglia usare.
Poichè un linguaggio è identificato dall'insieme di caratteristiche che supporta, l'introduzione in pianta stabile di una forma sintattica non presente nell'originale produce necessariamente un nuovo linguaggio.
Insomma, fare programmazione orientata agli oggetti in assembly significa creare un linguaggio diverso da assembly. Ergo la programmazione orientata agli oggetti in assembly non è possibile.
Che il s.o. funzioni e si evolva non v'è dubbio, ma che Torvalds NON sia un gran programmatore è ampiamente provato. Poi ha avuto il culo di ricevere un mare di supporto da gente con le palle, fra cui Alan Cox & co.Rileggendomi non avevo messo un NON, per cui la frase assumeva il significato opposto. :|
Adesso va bene. :D
per lo meno lui ha dimostrato di saper programmare che ti piaccia o no. per fare un paragone quando un tale di nome zio Bill ha consegnato DOS a IBM, quest'ultima l'ha testato scoprendo oltre 300 bugs in circa 4000 linee di codice :asd: una media di tutto rispetto
FONTE: http://www.ordineingegneri.bergamo.it/Commissioni/2001/14/Documenti/moduli/Lezione02/storia.htm :O
per quanto riguarda GIT vi consiglio di conoscerlo prima di giudicarlo.. perchè non è vero che software di quel tipo ce n'è a bizzeffe
E DOS l'avrebbe scritto Bill Gates?
a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo...
Tutto si puo' fare in assembler se e' per quello... ma capirai che se devo andare a Berlino ci vado in aereo, anche se potrei andarci a piedi :D.
comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)
#define SWAP(a, b, type) { type __tmp_c; c = b; b = a; a = c; }
int main()
{
int a = 3;
int b = 5;
printf("a is %d and b is %d\n", a, b);
SWAP(a, b, int);
printf("a is now %d and b is now %d\n", a, b);
return 0;
}
A proposito della metaprogrammazione in C++ si puo' dire tutto il male di questo mondo, ma non facendo esempi col preprocessore... :p, quando si va su cose un attimo piu' complesse tutti i problemi saltano fuori (ad esempio non hai mai la garanzia di scegliere nomi temporanei univoci).
E DOS l'avrebbe scritto Bill Gates?
no ma zio Bill e cugino Allen ebbero il compito di ripulirlo dalle funzionalità e riempirlo di bug :O
:rotfl: scherzi a parte la storia è scritta nel link :D
Tutto si puo' fare in assembler se e' per quello... ma capirai che se devo andare a Berlino ci vado in aereo, anche se potrei andarci a piedi :D.
non si può nemmeno pretendere di usare l'aereo per andare al cesso :fagiano:
A proposito della metaprogrammazione in C++ si puo' dire tutto il male di questo mondo, ma non facendo esempi col preprocessore... :p, quando si va su cose un attimo piu' complesse tutti i problemi saltano fuori (ad esempio non hai mai la garanzia di scegliere nomi temporanei univoci).
io ho solo detto che il C ha il supporto per la metaprogrammazione, non ho detto che è superiore a quello fornito dal C++ (anzi mi sembra di aver detto che è limitato).
vero è che il supporto alla metaprogrammazione offerto dal C++ non è quanto di meglio si poteva pensare e qui rimando al link di prima
E DOS l'avrebbe scritto Bill Gates?
Effettivamente no, non l'ha scritto lui (http://en.wikipedia.org/wiki/MS-DOS).
variabilepippo
08-09-2007, 12:59
Poichè un linguaggio è identificato dall'insieme di caratteristiche che supporta, l'introduzione in pianta stabile di una forma sintattica non presente nell'originale produce necessariamente un nuovo linguaggio.
Insomma, fare programmazione orientata agli oggetti in assembly significa creare un linguaggio diverso da assembly. Ergo la programmazione orientata agli oggetti in assembly non è possibile.
Se distinguiamo entrambi tra l'opportunità e la possibilità di sviluppare "ad oggetti" (nota le virgolette) in C, Assembly o in qualunque altro linguaggio tendenzialmente procedurale allora stiamo dicendo la medesima cosa con forme diverse.
Nel libro Object Oriented Programming with ANSI-C (http://www.cs.rit.edu/~ats/books/ooc.pdf) viene discusso un possibile approccio all'OOP in C, esistono inoltre librerie che consentono di impiegare il paradigma ad oggetti in codice ANSI-C (ripeto per l'ennesimo volta: viene fuori una gran porcheria però si può fare), non mi sembra che usare una libreria equivalga a "creare un linguaggio diverso". Con un po' più di fatica e qualche ulteriore forzatura il discorso è applicabile anche all'Assembly. :cool:
Nel libro Object Oriented Programming with ANSI-C (http://www.cs.rit.edu/~ats/books/ooc.pdf) viene discusso un possibile approccio all'OOP in C, esistono inoltre librerie che consentono di impiegare il paradigma ad oggetti in codice ANSI-C (ripeto per l'ennesimo volta: viene fuori una gran porcheria però si può fare), non mi sembra che usare una libreria equivalga a "creare un linguaggio diverso". Con un po' più di fatica e qualche ulteriore forzatura il discorso è applicabile anche all'Assembly. :cool:
ti dirò.. per cose banali non è nemmeno una porcheria. un paio di puntatori a funzione e la tua stuct diventa un "oggetto" che ha relazioni con altri "oggetti" :read:
ovvio che se devi implementare l'ereditarietà e tutto il resto diventa una porcheria, ma per quello infatti ci sono linguaggi apposta
Io parlo proprio della "possibilità", non dell'opportunità. Se fosse possibile sarebbe sempre opportuno usare la prospettiva orientata agli oggetti.
Una libreria può definire un diverso linguaggio se essa introduca forme sintattiche (modi di esprire le cose) non presenti nel linguaggio senza quella libreria.
Il fatto che l'introduzione di una nuova forma sintattica corrisponda alla creazione di un diverso linguaggio deriva dalla definizione di linguaggio (insieme di regole sintattiche per l'espressione di significati).
Il C++ può essere di basso livello tanto quanto il C: bisogna "soltanto" imparare a usare lo strumento giusto a seconda del tipo di (sotto)problema da risolvere.
Per far ciò è necessaria parecchia esperienza: bisogna entrare nella mentalità del programmatore C++, perché il linguaggio è complesso e ogni strumento merita d'esser sviscerato e "maturato".
Non sono d'accordo sul fatto che la programmazione di sistema debba essere relegata all'uso di strumenti di basso livello: proprio la presenza di s.o. scritti con linguaggi di livello più alto ne è, appunto, una controprova.
Come già detto si tratta di usare gli strumenti che il C++ (o qualunque altro linguaggio di alto livello) mette a disposizione nel giusto modo e al momento giusto.
Tanto per dirne una: non mi aspetto che all'interno della funzione malloc del s.o. venga utilizzato l'operatore new per allocare memoria per un oggetto, se non eventualmente dopo aver ridefinito opportunamente le funzioni di dis/allocazione da new e delete. ;)
Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.
Ad esempio gli iteratori, anche se molto comodi, richiedono una quantita' non banale di codice da scrivere, tanto che nei casi semplici uno non li usa, e ad esempio cicla direttamente sugli indici di un array. La cosa non e' bella perche' se certe forme, che dovrebbero esseer idiomatiche, non vengono usate nei casi semplici, i principianti tendono a non impararle e ad usarle col risultato che non lo faranno neanche nei casi in cui tornerebbe comodo, e rischiano di non capire quando lo fanno gli altri.
variabilepippo
08-09-2007, 13:47
Se fosse possibile sarebbe sempre opportuno usare la prospettiva orientata agli oggetti.
C'è anche chi dissente:
OOP criticism and OOP problems (http://www.geocities.com/tablizer/oopbad.htm)
Why I Prefer Procedural/Relational Over OOP (http://www.geocities.com/tablizer/whypr.htm)
Core Philosophical Differences (http://www.geocities.com/tablizer/core1.htm)
OOP Versus Relational: Beyond the Hardware (http://www.geocities.com/tablizer/beyondhw.htm)
Nota bene: per progetti sopra le 100K LOC preferirei ricevere una manganellata sui gioielli di famiglia piuttosto che adottare l'approccio procedurale. In alcuni contesti (embedded, realizzazione di device drivers o comunque di codice "vicino" all'hardware, etc) l'uso di linguaggi OOP non introduce vantaggi, anzi comporta una serie di problematiche.
Una libreria può definire un diverso linguaggio se essa introduca forme sintattiche (modi di esprire le cose) non presenti nel linguaggio senza quella libreria.
Non capisco come una libreria compilabile senza problemi da un compilatore pensato per un dato linguaggio possa costituire la definizione di un "diverso linguaggio". Loki, Boost (hai mai scritto un parser con la Spirit?) e la stessa STL introducono forme sintattiche non presenti nel C++ ma nessuno si sognerebbe di definirle "un altro linguaggio".
Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.
Questo è molto più sensato delle farneticazioni villane di Linus.
Questo è molto più sensato delle farneticazioni villane di Linus.
io non metto in dubbio la sua conoscenza dell'argomento, secondo me ha un modo di porsi sbagliato, ma questo fa parte del suo carattere
Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.
*
Ad esempio gli iteratori, anche se molto comodi, richiedono una quantita' non banale di codice da scrivere, tanto che nei casi semplici uno non li usa, e ad esempio cicla direttamente sugli indici di un array. La cosa non e' bella perche' se certe forme, che dovrebbero esseer idiomatiche, non vengono usate nei casi semplici, i principianti tendono a non impararle e ad usarle col risultato che non lo faranno neanche nei casi in cui tornerebbe comodo, e rischiano di non capire quando lo fanno gli altri.
ecco pensate agli iteratori! il modo sbagliato per risolvere il problema giusto (ed è facile incappare in casi del genere trai programmatori che credono che Dio sia un oggetto) :muro: è vero che nel 99% dei casi quando itero su un array non me ne frega niente di sapere quanto è lungo, ma magari mi serve sapere qual'è l'elemento prima, o quello dopo, o quello modulo 2 per 6 chessò :muro:
ecco perchè il modo corretto per risolvere il problema è il seguente
foreach (j, char c; input)
{
...
char a = c + (input[j%15]/input[j*(j-1)*(j-2)*(j-3)*(j-4)*(j^2)-1]);
...
}
con la possibilità di omettere il j nel caso sia superfluo :O
poi ci sono casi in cui serve definire un modo particolare di iterare su una collezione e lì si usa il buon vecchio pattern Iterator, ma sono casi particolari. l'importante è non sentirsi stupidi a ciclare su array per via del fatto che vanno specificati tutte le volte i limiti dell'array e/o bisogna creare una variabile apposta per tenere il conto dell'indice corrente :huh:
Dissentire è un sacrosanto diritto. Poi è possibile farlo con o senza argomentazioni. La prima cosa che deve darti uno che discute di orientamento agli oggetti è la definizione di oggetto. Deve perchè ne esiste più d'una. Tentando di aderire ad un'interpretazione umana dei fenomeni ed essendo quest'ultima non precisamente acquisita è giocoforza che ci siano diverse possibilità. Allora, stiamo esaminando l'orientamento agli oggetti. Bene, partiamo dalla definizione di oggetto che per me è: ...
Senza una definizione di oggetto si critica il vento, l'acqua e l'aria, soprattutto quest'ultima nella sua versione fritta.
La superiorità putativa dell'orientamento agli oggetti rispetto ad altre prospettive sta nel suo perchè. L'orientamento agli oggetti è il tentativo di far eseguire ad un calcolatore la rappresentazione umana della soluzione ad un problema. Compito di enorme difficoltà perchè qui andiamo a seminare un orto, quello della cognizione umana dei fenomeni, che è pieno di buche. Che sia questo il suo perchè è un fatto storico, desumibile dagli scritti di Alan Kay, Nygaard e Dahal: cioè coloro che hanno fondato l'orientamento agli oggetti.
E' putativa perchè un conto è dire un altro è fare. Prendi il caso delle gerarchie di classi (la tassonomia del traballante Core Philosophical Differencies). Perchè la maggior parte dei linguaggi orientati agli oggetti ha le classi e ha l'ereditarietà? C'è una ragione specifica. Altro fatto storico. Negli anni '60, quando nasce l'OO, la teoria dei concetti dominante era la c.d. teoria classica, secondo cui un certo ente risultava essere di un tal tipo in base alla presenza nell'entita dell'insieme di caratteristiche definite nel tipo. Tipi diversi possono essere in relazione di genere a specie, dove la specie è tale se, oltre al possesso di tutte le caratteristiche del genere, ne definisce altre.
Dopo tanto ragionare si giunse a scartare (anni '80, l'era della fuzzy-logic) la teoria classica per l'impossibilità logica di definire quali caratteristiche fossero essenziali alla definizione di un tipo (un qualsiasi breviario di psicologia cognitiva te lo dirà, io posso segnalarti la voce "concetto" in Dizionario di psicologia cognitiva di Eysenc).
Ora, se guardi i linguaggi OO di oggi (scala, ruby, chapel, fortress eccetera), noterai la tendenza a sostituire il rapporto di genere a specie - specie ad esemplare, cementato nelle classi con il concetto più dinamico di "trait", che è, in sintesi, un insieme di caratteristiche non necessariamente possedute. E' verificabile, questa faccenda del trait.
Sono problemi come questo delle classi a farmi dire che la superiorità è putativa. Perchè se è logicamente più economico che un uomo descriva un fenomeno nei termini della prospettiva che gli è propria (per la mera considerazione che la trasformazione di prospettiva è un passaggio in più), questa superiorità è vanificata nell'istante in cui, per un'errata interpretazione della congnizione umana dei fenomeni, io mi trovi comunque a dover esprimere la mia visione delle cose in termini che non corrispondano a questa prospettiva naturale.
Io non voglio infierire sui testi che hai citato perchè ho un grande rispetto del pensiero altrui. Lascia tuttavia che proponga questa frase:
"Mother nature has decided to split the human brain into two halves. One half focuses on logic and the other half on emotions."
Queste non sono argomentazioni che fanno bene all'orientamento agli oggetti o alla critica all'orientamento agli oggetti.
Un ottimo e divertente libro di Jhon Hunt (POET), che io consiglio sempre, ci rivela effettivamente l'esistenza di una dualità della mente. A dire il vero è una molteplicità più che una dualità. Altrettanto ottimo, ma meno divertente, è un libro sul ragionamento, di cui ora non ricordo l'autore ma si intitola Il Ragionamento, edito da CEDAM, Padova, il quale ci dice che la logica è quanto di più estraneo possa proporsi per trattare della mente umana. Detta in tre parole, la logica è deduzione (il trarre conclusioni vere) mentre il cervello umano è una macchina induttiva (trae indifferentemente conclusioni vere, false, possibili o impossibili).
In vero, una dualità che a noi interessa per l'analisi dell'orientamento agli oggetti esiste ed è anche piuttosto interessante perchè, applicata, spiega alcuni imbarazzi. La dualità a cui mi riferisco è tra l'acquisizione cosciente della cognizione e la cognizione così acquisita.
Senza star qui ad annoiarvi oltre misura mi limito a dire che l'acquisizione cosciente, volontaria, di conoscenza è un meccanismo procedurale, nel senso che consta di una serie ordinata di attività (mentali). La cognizione in sè, intesa come consapevolezza del significato dei fenomeni, è invece dichiarativa.
Una conseguenza diretta di ciò, utile agli analisti, è che se in un codice sorgente apparentemente costituito di concetti elegantemente espressi nella più piena immediatezza vi trovate tra i piedi qualcosa che puzza di procedurale potete legittimamente desumere che quel pezzo di codice sia il frutto di un ragionamento in atto al momento della stesura del codice. Cioè chi ha scritto il codice ha rappresentato non qualcosa che sapeva ma qualcosa di cui stava acquisendo coscienza.
Quanti abbiano avuto il dispiacere di leggere "Refactoring" di Fowler scoprono qui, adesso (ammesso che non lo sapessero già) una ragione per cui esso può rendersi necessario. Se posso scrivere codice che rappresenta il ragionamento in atto, una volta che tale ragionamento si sia concluso posso anche tradurre quel procedimento nella sua forma dichiarativa. Cioè io scrivo codice procedurale perchè parlo di una cosa di cui non ho piena consapevolezza: sto formando quella consapevolezza mentre scrivo.
Parlo, ovviamente, della presenza di intermezzi procedurali in programmi altrimenti orientati agli oggetti. Un programma volutamente procedurale è la rappresentazione procedurale di un fenomeno che può essere o non essere procedurale.
E non posso lasciarlo così com'è, ci si chiederà. No. L'indagine consapevole sul perchè delle cose che ci porta ad acquisire conoscenza, il ragionamento, è un'attività estremamente dispendiosa. Tanto dispendiosa che, pare, il cervello, potendo, la eviti. Nella descrizione di un fenomeno la quantità di conoscenza pregressa o dedotta, il numero di cose che sono perchè sì e basta, dovrebbe essere più elevata della quantità di conoscenza che è il frutto di un'acquisizione consapevole e contestuale, cioè formata razionalmente nel momento in cui si esprime il fenomeno. Vale a dire che un programma è per lo più espresso attraverso la dichiarazione di entità, caratteristiche e relazioni, tutta materia "statica".
Comunque, e per nascondere il fatto che praticamente non so più di cosa stavo parlando, dirò questo: la difficoltà dell'orientamento agli oggetti sta nell'ambiziosità del suo scopo e nella relativa incertezza delle sue fondamenta. Ma è in questa ambiziosità che va ricercata la sua superiorità. E' questo desiderio di consentire ad un uomo di esprimersi nella programmazione di un calcolatore. Ed è una necessità. I calcolatori hanno un perchè, una ragione per cui l'uomo li ha inventati. Ma mi fermo qui.
variabilepippo
08-09-2007, 15:43
...Comunque, e per nascondere il fatto che praticamente non so più di cosa stavo parlando, dirò questo: la difficoltà dell'orientamento agli oggetti sta nell'ambiziosità del suo scopo e nella relativa incertezza delle sue fondamenta. Ma è in questa ambiziosità che va ricercata la sua superiorità. E' questo desiderio di consentire ad un uomo di esprimersi nella programmazione di un calcolatore. Ed è una necessità. I calcolatori hanno un perchè, una ragione per cui l'uomo li ha inventati. Ma mi fermo qui.
Un bell'excursus, forse fin troppo digressivo per quelle che sono le necessità di sintesi tipiche di un mezzo quale è un forum, ma che fallisce nel persuadere me (uno che propugna la superiorità quadratica media dell'OOP e dell'OOM) della superiorità dell'orientamento ad oggetti indipendentemente dal contesto. Mi dispiace ma non sono ancora convinto della validità universale del "Se fosse possibile sarebbe sempre opportuno usare la prospettiva orientata agli oggetti". E' quel sempre "ecumenico" che mi fa accapponare la pelle!
Per esempio quando si lavora "vicino" alla macchina imporre aprioristicamente ed acriticamente il modello ad oggetti è quanto meno una forzatura, detto questo sono più che convinto che nella stragrande maggioranza dei casi l'approccio OO porti solo dei benefici.
Comunque, e per nascondere il fatto che praticamente non so più di cosa stavo parlando, dirò questo: la difficoltà dell'orientamento agli oggetti sta nell'ambiziosità del suo scopo e nella relativa incertezza delle sue fondamenta. Ma è in questa ambiziosità che va ricercata la sua superiorità. E' questo desiderio di consentire ad un uomo di esprimersi nella programmazione di un calcolatore. Ed è una necessità. I calcolatori hanno un perchè, una ragione per cui l'uomo li ha inventati. Ma mi fermo qui.
se lo scopo è avvicinarsi al modo di pensare dell'uomo la risposta non può essere von Neumann. c'è qualcosa di intrinsecamente sbagliato in questo tentativo IMHO
ps. particolarmete interessante il post in ogni caso :cool:
Io mi ero ripromesso di non scrivere più encicliche di questa risma. Ma mi hai fatto un assist a cui non ho saputo restistere perchè sono questioni assolutamente affascinanti.
L'orientamento agli oggetti (un possibile orientamento agli oggetti) non è un generico avvicinarsi al modo di pensare di un essere umano ma è consentire ad un essere umano di esprimere il proprio pensiero senza trasformazioni intermedie.
La superiorità di questo orientamento agli oggetti non è una possibilità. Per quanto uno possa avvicinarsi alla meccanica di un calcolatore egli, in quanto essere umano, non potrà che descrivere ciò che osserva secondo il punto di vista di un essere umano. Parole come "registro di memoria", "istruzione", "bit" sono inevitabili astrazioni concettuali di ciò che è fisicamente. Inevitabili. Vi è mai capitato di vedere una penna cadere da un tavolo? Bene, chiedete ad un fisico teorico se le penne possono cadere. Vi dirà che la penna in verità non fa un bel niente. La naturale descrizione del fenomeno è tuttavia personificante perchè tale è la tendenza del pensiero umano: noi vediamo delle cose che si muovono, suonano, che cambiano colore... sono tutte proiezioni dell'io. Lo stesso vale per il calcolatore. E' una cricca di atomi variamente manipolati, i quali subiscono delle eccitazioni energetiche... per la verità atomo è un'astrazione... eccetera eccetera. C'è tutta un filosfia che indaga sulla possibilità che l'uomo possa acquisire una conoscenza dell'essere che non sia contaminata dai propri schemi interpretativi.
Io cerco questo orientamento agli oggetti perchè non vedo alternative. Se non sta qui il motivo per cui dovrei usare l'orientamento agli oggetti allora dove sta? Perchè pur con tutte le sue magagne, la prospettiva procedurale, vale a dire l'interpretazione dei fenomeni come sequenze parzialmente ordinate di operazioni elementari su valori immagazzinati in registri di memoria, vanta un'esatta corrispondenza con il modello di funzionamento di un calcolatore.
In questo senso la prospettiva procedurale è verificabile al millesimo di millimetro. Rivolgersi ad altri punti di vista significa abbandonare questa certezza. Ebbene, qual'è il vantaggio offertomi a fronte di questa perdita?
La Human OOP mi dice che il vantaggio sta nell'evitare una trasformazione di prospettiva: io affido al compilatore il compito di tradurre la rappresentazione umana di un fenomeno in rappresentazione procedurale. Trasformazione che, altrimenti, sono costretto a fare io: essendo fisiologicamente costretto ad osservare le cose in termini umani, ogni qualvolta io debba esprimere queste cose in termini diversi dovrò fare una traduzione. Mi sembra che non si possa scampare a questa trappola.
PS: io non cerco nè voglio convincere alcuno di alcunchè. Fatico già a convincere me stesso. Mi preme invece stimolare una visione critica di quanto si sente dire. E c'entra col topic perchè, alla fin fine, io sarei curioso di sapere quale sia l'orientamento agli oggetti a cui fa riferimento il buon Torvalds quando ne critica la realizzazione in C++.
cdimauro
08-09-2007, 19:48
Gnome+Eclipse ci girano tranquillamente con 512 mb di ram :D
Ho specificato KDE perché, per quanto mi riguarda, è l'unico wm decente e che offre un'interfaccia simile a quella di Windows (come look & feel).
Se uno usa Kde solitamente usa Kmail che è un ottimo software e non Evolution
KMail non ha tutte le funzionalità di Evolution, e non sono disposto a rinunciarci.
con Vista con 512 mb di ram non vai da nessuna parte :D .Se ci devi usare aero con Vista devi avere una Buona scheda grafica ,
Mi sembra ovvio che non bastino: io voglio usare il sistema al meglio, e non voglio rinunciare a nessuna comodità per consumare meno risorse, come potrei fare eliminando i servizi aggiuntivi di Vista, usando l'interfaccia senza effetti grafici, ecc., e come farei con Linux rinunciando a KDE, Evolution, ecc.
in ambiente linux una geforce4 qualunque ti permette di avere gli stessi effetti grafici (io personalmente non li uso , per dovere di cronaca)...
Una scheda grafica di classe DirectX 8, qual è la GF4, NON PUO' realizzare gli stessi effetti grafici di una di classe DX 9, che è il requisito minimo indispensabile per attivare Aero.
Tra l'altro tanta gente confonde la sfocatura delle finestre di Aero con la trasparenza delle altre interfacce grafiche: niente di più diverso.
Speriamo sia volta buona per chiudere questo OT che si trascina da tempo.
Già autolesionisti e cerebrolesi :doh: ...
C'è qualcuno che ci riesce a programmare in quel modo
che a te pare orrendo :mbe:
Non metto in dubbio che ci riescano, ma simulare la programmazione a oggetti usando quella procedurale è tanto bello quanto una martellata sulle palle.
Eh, sì, è a dir poco ORRENDO: basti vedere a quali contorsionismi devono scendere a patti pur di utilizzare il paradigma degli oggetti. Già soltanto a guardare il codice sopraggiungono dei conati di vomito...
Se non ci riesci non importa
Figurati: come ti dicevo io programmavo a oggetti in assembly quando questa gente nemmeno sapeva cos'era un oggetto.
Ma è una cazzata enorme, perché in realtà NON è programmazione a oggetti, ma procedurale che la simula. I vantaggi della programmazione a oggetti dove sono, se devo usare dei contorsionismi procedurali per simulare ereditarietà e polimorsmo?
Infatti il codice fa comunque pena e compassione, perché la forzatura è evidentissima. Il codice è inguardarbile.
qualcuno lo fa e con ottimi risultati ---> Gimp:fiufiu:
Ottimi? Se The GIMP è un ottimo risultato allora per PhotoShop dovremmo coniare un nuovo termine...
Questi programmatori dovrebbero capire un concetto a dir poco lapalissiano quando lavorano per realizzare applicazioni che devono usare altre persone: bisogna mettere al centro le esigenze dell'utente.
Poi possono anche sfogarsi come vogliono per raggiungere questi obiettivi.
Buon V-Day
Grazie. C'era molta gente: speriamo si muova finalmente qualcosa. :)
cdimauro
08-09-2007, 19:50
Ognuno può usare quello che vuole per scrivere codice...
La differenza sta in quello che scrive, in ciò che crea. Se un programmatore
è talentuoso lo sarà con qualsiasi strumento...:fagiano:
Gli strumenti permetto anche di raggiungere più velocemente e/o comodamente gli scopi prefissi.
L'importante è ciò che produce ognuno utilizza lo strumento che più gli conviene.
Ci sono strumenti e strumenti. Puoi continuare a usare l'editor testuale che vuoi, ma se non ha delle funzionalità di rifattorizzazione del codice, la produttività non sarà certo la stessa, pur producendo lo STESSO, ottimo, codice.
Puoi avere la racchetta migliore del mondo ma non per questo puoi esprimere il gioco di Federer:D
Infatti l'idea è esprimere il gioco di Federer con la racchetta migliore al mondo. ;)
cdimauro
08-09-2007, 19:54
Anche io all'inizio ho avuto problemi , ma si possono superare :fagiano:
i pregiudizi proprio non li mando giu della serie : " chi usa linux ha tempo da perdere " :mbe:
Uso con molta soddisfazione sia Xp che Debian Linux :sofico:
Quelli che tu chiami pregiudizi sono semplicemente il frutto dell'esperienza vissuta.
Io a lavoro dopo un anno e mezzo di sofferenze con Linux sono passato a Windows e sono a dir poco rinato. Adesso sono decisamente più produttivo e sviluppo con maggior comodità.
Comunque stiamo continuando a inquinare il thread con discussioni OT di cui, tra l'altro, qui s'è ampiamente parlato in passato, anche recente: direi di darci un taglio e parlare esclusivamente di programmazione, sfruttando lo spunto datoci da chi ha aperto il thread.
cdimauro
08-09-2007, 19:56
La possibilità di fare programmazione orientata agli oggetti si fonda sulla capacità dei compilatori di operare non solo come traduttori simbolici ma anche come trasformatori di prospettiva (da OO a procedurale nel caso di linguaggio OO).
Scrivere a mano ciò che produrrebbe un compilatore a fronte di un codice sorgente OO non è orientamento agli oggetti. Perchè il prodotto finale della compilazione è sempre ed immancabilmente procedurale. Lo è perchè la macchina che dovrà interpretare quel prodotto è meccanicamente vincolata ad un interpretazione procedurale dei fenomeni.
Concordo: è soltanto la simulazione di un processo usando la programmazione procedurale, ma non c'entra niente con quella a oggetti che permettono di usare "nativamente" tanti linguaggi.
D'altra parte basti vedere quella libreria C per "programmare a oggetti" per rendersi conto di quanto lontano sia quest'ultima, e farragginoso il meccanismo introdotto: un vero schifo (e sono molto buono :D).
cdimauro
08-09-2007, 19:58
a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo... comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)
#define SWAP(a, b, type) { type __tmp_c; c = b; b = a; a = c; }
int main()
{
int a = 3;
int b = 5;
printf("a is %d and b is %d\n", a, b);
SWAP(a, b, int);
printf("a is now %d and b is now %d\n", a, b);
return 0;
}
Il preprocessore non fa parte del linguaggio.
inoltre se parliamo di C++ i template non sono sempre una soluzione elegante e/o efficiente
http://people.cs.uchicago.edu/~jacobm/pubs/templates.html
soprattutto quando dice
Infatti i template sono uno strumento che va imparato.
cdimauro
08-09-2007, 20:03
La possibilità di mappare entità reali in oggetti ti è data dalla presenza di opportuni costrutti sintattici, nulla ti vieta di scrivere macro e strutture adatte a rappresentare oggetti in Assembly. Sono convinto che non ne valga assolutamente la pena (per una lunghissima serie di ragioni), ma tecnicamente si può fare, come è d'altronde dimostrato dai numerosi esempi reperibili on-line.
Considera poi che il C++ è nato come un "C con le classi" (http://www.research.att.com/~bs/bs_faq.html):
Ed il C non è altro che un Assembly "on steroids (http://forum.ioprogrammo.it/thread.php?threadid=12429&boardid=20)":
Quella di usare un altro linguaggio (intermedio) per compilare i sorgenti scritti un altro è una prassi consolidata, perché è una via molto semplice e veloce per ottenere in tempi brevi un compilatore per un nuovo linguaggio.
Ma il rapporto fra i due linguaggi finisce qui. :D
Ad esempio, anche il primo compilatore Eiffel convertiva il codice in C, ma il codice C prodotto era... procedurale! :p
Infatti non aveva NULLA a che vedere coi concetti espressi dal codice sorgente Eiffel, che facevano uso di oggetti, contratti, ecc., se non che l'esecuzione genera i risultati che ci si aspetteva dal sorgente in Eiffel. ;)
Adesso non ho sottomano le specifiche del linguaggio di programmazione C ma, se non ricordo male, il preprocessore è esplicitamente menzionato dunque dovrebbe essere parte del linguaggio di programmazione C (cioè la possibilità di fare pre-processing così come là descritto). Qualcuno con le specifiche sott'occhio può confermare o smentire?
cdimauro
08-09-2007, 20:06
per lo meno lui ha dimostrato di saper programmare che ti piaccia o no.
E' una parola grossa per chi si lascia andare a certe dichiarazioni ridicole.
per fare un paragone quando un tale di nome zio Bill ha consegnato DOS a IBM, quest'ultima l'ha testato scoprendo oltre 300 bugs in circa 4000 linee di codice :asd: una media di tutto rispetto
FONTE: http://www.ordineingegneri.bergamo.it/Commissioni/2001/14/Documenti/moduli/Lezione02/storia.htm :O
Il DOS di cui parli l'aveva sviluppato un'altra società e non Gates.
per quanto riguarda GIT vi consiglio di conoscerlo prima di giudicarlo.. perchè non è vero che software di quel tipo ce n'è a bizzeffe
Infatti avevo detto un'altra cosa: vatti a rileggere il mio messaggio. ;)
cdimauro
08-09-2007, 20:10
Adesso non ho sottomano le specifiche del linguaggio di programmazione C ma, se non ricordo male, il preprocessore è esplicitamente menzionato dunque dovrebbe essere parte del linguaggio di programmazione C (cioè la possibilità di fare pre-processing così come là descritto). Qualcuno con le specifiche sott'occhio può confermare o smentire?
Sì, nel K&R e nell'ANSI C il preprocessore è integrato nelle implementazioni del linguaggio.
Io mi riferisco al fatto che un preprocessore concettualmente NON è legato a uno specifico linguaggio.
Infatti in qualsiasi momento si può integrare un preprocessore in un qualunque linguaggio, senza cambiare di una virgola la sintassi del linguaggio e i compilatori già esistenti. ;)
cdimauro
08-09-2007, 20:14
ti dirò.. per cose banali non è nemmeno una porcheria. un paio di puntatori a funzione e la tua stuct diventa un "oggetto" che ha relazioni con altri "oggetti" :read:
No, rimane una struct con dei puntatori a funzione.
In soldoni stai continuando a fare quello che facevi anche prima: programmare proceduralmente per modellare la soluzione di un problema.
Infatti il linguaggio non è cambiato: non era oggetti prima e non lo è nemmeno dopo questa "trovata".
ovvio che se devi implementare l'ereditarietà e tutto il resto diventa una porcheria, ma per quello infatti ci sono linguaggi apposta
Infatti E' una porcheria, perché se c'è l'esigenza di simulare la programmazione a oggetti mi sembra a dir poco lapalissiano passare a un linguaggio che permetta di farlo "nativamente", con tutti i benefici del caso.
cdimauro
08-09-2007, 20:21
Quello che intendo dire e' che le funzionalita' in piu' del C++ vengono ad un costo notevole e, anche discorsi del tipo "il C e' meglio del C++" li trovo ridicoli, posso capire chi invece la mette sul "uso il C perche' secondo me il gioco non vale la candela", soprattutto in certi contesti.
Concordo, e infatti si può decidere liberamente di NON usare certe caratteristiche del C++. Però in un progetto scritto in C non puoi decidere di usare caratteristiche che il linguaggio non ha.
Ecco perché oggi non ha senso utilizzare il C come linguaggio: per male che vada, in un progetto in C++ si può decidere di non usare nessuna caratteristica che il linguaggio offre in più rispetto al C.
Scelta discutibile, ma possibile. Solo che in qualsiasi momento si può cambiare idea e decidere di sfruttarne qualche costrutto.
Ad esempio gli iteratori, anche se molto comodi, richiedono una quantita' non banale di codice da scrivere, tanto che nei casi semplici uno non li usa, e ad esempio cicla direttamente sugli indici di un array. La cosa non e' bella perche' se certe forme, che dovrebbero esseer idiomatiche, non vengono usate nei casi semplici, i principianti tendono a non impararle e ad usarle col risultato che non lo faranno neanche nei casi in cui tornerebbe comodo, e rischiano di non capire quando lo fanno gli altri.
Vero. Ecco anche perché preferisco ben altro, come sai. :D
cdimauro
08-09-2007, 20:26
io non metto in dubbio la sua conoscenza dell'argomento, secondo me ha un modo di porsi sbagliato, ma questo fa parte del suo carattere
Da quel che scrive la si mette in dubbio, eccome. :D
ecco pensate agli iteratori! il modo sbagliato per risolvere il problema giusto (ed è facile incappare in casi del genere trai programmatori che credono che Dio sia un oggetto) :muro: è vero che nel 99% dei casi quando itero su un array non me ne frega niente di sapere quanto è lungo, ma magari mi serve sapere qual'è l'elemento prima, o quello dopo, o quello modulo 2 per 6 chessò :muro:
ecco perchè il modo corretto per risolvere il problema è il seguente
foreach (j, char c; input)
{
...
char a = c + (input[j%15]/input[j*(j-1)*(j-2)*(j-3)*(j-4)*(j^2)-1]);
...
}
con la possibilità di omettere il j nel caso sia superfluo :O
poi ci sono casi in cui serve definire un modo particolare di iterare su una collezione e lì si usa il buon vecchio pattern Iterator, ma sono casi particolari. l'importante è non sentirsi stupidi a ciclare su array per via del fatto che vanno specificati tutte le volte i limiti dell'array e/o bisogna creare una variabile apposta per tenere il conto dell'indice corrente :huh:
Come ti scrissi già un'altra volta, anche il fatto di conoscere per forza di cose la posizione di un elemento durante un processo di iterazione non è sempre necessario: è chiaro che dipende dal tipo di problema da risolvere.
Finora m'è capitato un paio di volte e con Python ho risolto semplicemente facendo uso di un iteratore presente nel linguaggio (è un iteratore che itera gli elementi dell'iteratore passato e restituisce una coppia ordine + elemento dell'iteratore passatogli :D).
tomminno
08-09-2007, 20:29
E' un bene, non un male... Un sistema operativo NON deve occupare il minor quantitativo di RAM possibile, non è mica una gara al risparmio, deve piuttosto gestire la memoria nel modo migliore. Fortunatamente Vista utilizza la RAM in modo più aggressivo rispetto ad altri sistemi e nella maggior parte dei casi SuperFetch migliora la prestazioni.
Quindi secondo te il Superfetch influisce anche sui 300MB occupati all'avvio da svchost e dwm? Il tutto su un Vista Home Premium che non ha nemmeno Aero.
Smettiamola con questa storia della gestione ottimizzata della memoria, Vista occupa uno sproposito di memoria e non riesce nemmeno a rendere il computer più veloce di XP.
cdimauro
08-09-2007, 20:29
Al solito il buon PGI-Bis ha calato l'asso sui paradigmi di programmazione. :D
Entrambi i post sono da quotare, anche se già qualcosa traspariva dai precedenti linguaggi.
Thanx so much. :)
cdimauro
08-09-2007, 20:31
Quindi secondo te il Superfetch influisce anche sui 300MB occupati all'avvio da svchost e dwm? Il tutto su un Vista Home Premium che non ha nemmeno Aero.
Smettiamola con questa storia della gestione ottimizzata della memoria, Vista occupa uno sproposito di memoria e non riesce nemmeno a rendere il computer più veloce di XP.
Come ho detto prima, sulla STESSA macchina (con 1GB di ram) passando da XP x64 a Vista x64 il sistema era NETTAMENTE più reattivo e veloce.
Dunque la gestione della memoria e il superfetch, almeno per la mia esperienza, hanno influito, eccome, sulle prestazioni della macchina.
Questa, ripeto ancora una volta, è la MIA esperienza.
a parte che questo non diminuisce il potere espressivo del linguaggio perchè qualsiasi cosa volevi fare usando i template la puoi fare in un altro modo... comunque la metaprogrammazione in C esiste e si basa sul preprocessore (anche se minimale)
Il preprocessore non fa parte del linguaggio. Ed e' ovvio che non si possono esprimere "in altro modo" in C i concetti a compile time che possono essere espressi in C++ attraverso i template.
Ad esempio non c'e' modo in C di fare questo in maniera altrettanto efficiente:
std::sort(vector.begin(), vector.end());
Dove il tipo di vector puo' essere parametrizzato, quindi sconosciuto a priori al momento della scrittura. Qualunque implementazione in C sarebbe meno efficiente e meno mantenibile.
Esprimere un concetto in un linguaggio e' cosa differente dall'implementare qualcosa: tutto puo' essere implementato anche in assembly per ovvi motivi. Ma linguaggi a piu' alto livello sono piu' espressivi e "migliori". Il C++ essendo un superset del C e' piu' "espressivo", ne supporta tutti i costrutti e i paradigmi con la medesima efficienza, quindi e' migliore sotto ogni punto di vista.
Ho specificato KDE perché, per quanto mi riguarda, è l'unico wm decente e che offre un'interfaccia simile a quella di Windows (come look & feel).
Se cerchi Windows usa Windows ;)
Il fatto che Gnome non sia simile a Windows significa che non è decente ?
A me Gnome sembra più che decente...o forse sono scemo io ad usarlo :D
Riguardo al discorso che fate...io mi trovo pienamente d'accordo a metà (:D) con Torvalds.
In parte ha ragione: la gente (io compreso, un tempo) fa tante di quelle schifezze con il C++ che ti verrebbe da metterti la mano nei capelli. Il problema di base è che in C++ è possibile programmare come si fa in C e questo a creato una moltitudine di persone che dice di saper programmare in C++ scrivendo in C con i in più l'uso di cin e cout :muro: :muro: :muro:
Questo è sicuramente colpa del linguaggio che ti permette di farlo. Io sarei tanto contento se prima o poi venisse dato un approccio Java-like al C++ anche solo per quanto riguarda l'entry point.
Tornando a Torvalds ovviamente non mi trova d'accordo sulla questione delle "astrazioni"...anche lui fa sicuramente astrazioni programmando in C, solo che si vedono meno ;)
^TiGeRShArK^
08-09-2007, 22:03
Io non dubito di questo e sono sinceramente estasiato di fronte a tanta abbondanza. Ma con me non lo fa. Sarà che gli sto sui finferli.
Non sono io ad avere qualcosa contro linux è linux ad avere qualcosa contro me!:O
:read:
:asd:
cdimauro
08-09-2007, 22:16
Se cerchi Windows usa Windows ;)
Il fatto che Gnome non sia simile a Windows significa che non è decente ?
A me Gnome sembra più che decente...o forse sono scemo io ad usarlo :D
Ho provato Gnome, ma non trovo che sia usabile quanto KDE (tra l'altro sull'argomento Linus sparò un'altra delle sue cazzate tempo fa, affermando di buttare Gnome e passare a KDE perché Gnome era un progetto inutile :asd:).
Poi in queste cose si sa che è una questione di gusti. ;)
E non è che sia assuefatto da Windows tanto da pretendere un'interfaccia come la sua, visto che usato la fortuna e il piacere di usare tantissime GUI.
Riguardo al discorso che fate...io mi trovo pienamente d'accordo a metà (:D) con Torvalds.
In parte ha ragione: la gente (io compreso, un tempo) fa tante di quelle schifezze con il C++ che ti verrebbe da metterti la mano nei capelli. Il problema di base è che in C++ è possibile programmare come si fa in C e questo a creato una moltitudine di persone che dice di saper programmare in C++ scrivendo in C con i in più l'uso di cin e cout :muro: :muro: :muro:
Esattamente, ma com'è emerso da diversi messaggi in quel thread, i programmatori sono capaci di scrivere minchiate con qualunque linguaggio di programmazione.
Nel caso in questione è vero: tanti usano il C++ come fosse C.
Questo è sicuramente colpa del linguaggio che ti permette di farlo. Io sarei tanto contento se prima o poi venisse dato un approccio Java-like al C++ anche solo per quanto riguarda l'entry point.
Potresti essere più chiaro?
Tornando a Torvalds ovviamente non mi trova d'accordo sulla questione delle "astrazioni"...anche lui fa sicuramente astrazioni programmando in C, solo che si vedono meno ;)
Le camuffa con la programmazione procedurale. Roba che si faceva una ventina d'anni fa.
Potresti essere più chiaro?
Già solo il fatto di dover essere obbligati a creare una classe per definire l'entry point del programma potrebbe portare a migliorare notevolmente il modo di programmare di molte persone.
Il problema di fondo è che secondo me chi programma in C++ dovrebbe scordarsi il C, ma questo non avviene.
franklar
08-09-2007, 22:44
Come ho detto prima, sulla STESSA macchina (con 1GB di ram) passando da XP x64 a Vista x64 il sistema era NETTAMENTE più reattivo e veloce.
Dunque la gestione della memoria e il superfetch, almeno per la mia esperienza, hanno influito, eccome, sulle prestazioni della macchina.
Questa, ripeto ancora una volta, è la MIA esperienza.
Dipende dal software che usi: se fai un giro nella sezione giochi, che poi tra i software di larga diffusione sono quelli più esosi in termini di richieste di ram, ti rendi conto che non solo molti utenti hanno notato che lo stesso gioco con x GB di ram va liscio su XP e scatta su Vista, ma le stesse case produttrici raccomandano per lo stesso gioco un sistema con x GB per WinXP e (x+x/2) per Vista.
Comunque mi pare ovvio che un SO più recente sia più complesso e sfrutti di più le risorse di sistema, altrimenti io starei qui a postare col mio vecchio PC da 64MB di ram di quando usavo Win98 :D
cdimauro
09-09-2007, 08:18
Già solo il fatto di dover essere obbligati a creare una classe per definire l'entry point del programma potrebbe portare a migliorare notevolmente il modo di programmare di molte persone.
Il problema di fondo è che secondo me chi programma in C++ dovrebbe scordarsi il C, ma questo non avviene.
OK grazie, adesso ho capito a cosa ti riferivi (ed era pure semplice, solo che ieri sera non so dove avevo la testa, e rileggendo i messaggi che ho scritto ho notato una quantità industriale di errori grammaticali :muro: ), e sono d'accordo.
cdimauro
09-09-2007, 08:24
Dipende dal software che usi: se fai un giro nella sezione giochi, che poi tra i software di larga diffusione sono quelli più esosi in termini di richieste di ram, ti rendi conto che non solo molti utenti hanno notato che lo stesso gioco con x GB di ram va liscio su XP e scatta su Vista, ma le stesse case produttrici raccomandano per lo stesso gioco un sistema con x GB per WinXP e (x+x/2) per Vista.
Comunque mi pare ovvio che un SO più recente sia più complesso e sfrutti di più le risorse di sistema, altrimenti io starei qui a postare col mio vecchio PC da 64MB di ram di quando usavo Win98 :D
Esattamente, il punto è proprio questo: Vista è profondamente diverso da XP, ed è un s.o. decisamente più complesso.
Questo implica che facendo girare la STESSA applicazione il comportamento di quest'ultima è facile che sia diverso; può girare meglio oppure peggio.
Nel mio caso e per il tipo di uso che faccio nel PC ho notato dei netti miglioramenti.
Nel caso che esponi non ho motivo di dubitare che, invece, crei dei problemi (dubito della formuletta x + x/2, invece; "a naso" esisterà una soglia y fissa per cui la memoria necessaria in questo caso risulterà essere x + y). Poi c'è da tenere anche in considerazione i driver video che sono completamente diversi e che ancora oggi sono oggetto di affinamento da parte di nVidia e Ati.
Finiamo questo continuo OT però, perché non se ne esce più. :p
mindwings
09-09-2007, 08:41
Esattamente, il punto è proprio questo: Vista è profondamente diverso da XP, ed è un s.o. decisamente più complesso.
Questo implica che facendo girare la STESSA applicazione il comportamento di quest'ultima è facile che sia diverso; può girare meglio oppure peggio.
Nel mio caso e per il tipo di uso che faccio nel PC ho notato dei netti miglioramenti.
Nel caso che esponi non ho motivo di dubitare che, invece, crei dei problemi (dubito della formuletta x + x/2, invece; "a naso" esisterà una soglia y fissa per cui la memoria necessaria in questo caso risulterà essere x + y). Poi c'è da tenere anche in considerazione i driver video che sono completamente diversi e che ancora oggi sono oggetto di affinamento da parte di nVidia e Ati.
Finiamo questo continuo OT però, perché non se ne esce più. :p
Ci sono tante tue affermazioni che vuoi far passare
per LA verità :) .
Non puoi paragonare Photoshop a Gimp il primo è un software commerciale
il secondo è free sotware. Il primo per usarlo devi sborsare fior di din dini
il secondo è libero è permette di fare dell'ottima grafica...:fagiano:
Il tuo confronto non ha senso. Chi usa PhotoShop? I Grafici o cmq dei professionisti , o magari qualcuno che l'ha scaricato a SCROCCO... Perchè di PhotoShop si conosce il nome .
Per quanto rigurada l'editor il mio era un esempio!
Io per primo per fare un piccolo programmino in java ho usato
Eclipse . Ma non disprezzo chi usa Vim o altri strumenti (Emacs?-GDB?)
alla fine è sempre la persona a scrivere il codice... Le cagate le puoi fare anche con il miglior strumento.
La ma metafora tennistica era messa li apposta. Mi dispiace che non l'hai compresa. O credi di esprimerti come Torvalds:ciapet: (ehm Federer:fagiano: )
cdimauro
09-09-2007, 09:19
Ci sono tante tue affermazioni che vuoi far passare
per LA verità :) .
Se non ti piacciono puoi sempre provare a smontarle. ;)
Non puoi paragonare Photoshop a Gimp il primo è un software commerciale
il secondo è free sotware.
Sono software che si collocano nello stesso segmento di mercato, esattamente come Windows e Linux, per cui li confronto.
I tuoi confronti fra Windows e Linux li hai fatti, mi pare.
Il primo per usarlo devi sborsare fior di din dini
il secondo è libero è permette di fare dell'ottima grafica...:fagiano:
L'ottima grafica la realizza l'ottimo grafico.
PhotoShop e The GIMP sono strumenti che permettono all'ottimo grafico di realizzare ottima grafica in un certo tempo, determinato dalla bontà dei tool che mettono a disposizione.
Poiché il tempo è DENARO, realizzare grafica con PhotoShop o The GIMP ha sempre un costo, anche se quest'ultimo non devi comprarlo e il primo sì.
Il tuo confronto non ha senso. Chi usa PhotoShop? I Grafici o cmq dei professionisti , o magari qualcuno che l'ha scaricato a SCROCCO...
Non ha senso invece il fatto che tiri in ballo professionisti et similia quando si fanno dei confronti perfettamente legittimi su due prodotti che si collocano nella stessa fascia di mercato.
Perchè di PhotoShop si conosce il nome .
Vero, e si conosce proprio perché è un ECCELLENTE prodotto nel settore del fotoritocco.
Per quanto rigurada l'editor il mio era un esempio!
Io per primo per fare un piccolo programmino in java ho usato
Eclipse . Ma non disprezzo chi usa Vim o altri strumenti (Emacs?-GDB?)
alla fine è sempre la persona a scrivere il codice... Le cagate le puoi fare anche con il miglior strumento.
Questo mi sembra che nessuno l'avesse messo in dubbio. Io avevo aggiunto altro.
La ma metafora tennistica era messa li apposta. Mi dispiace che non l'hai compresa.
Mi spiace che tu non abbia compreso che un buon giocatore ha bisogno anche di buoni strumenti per realizzare un buon gioco.
O credi di esprimerti come Torvalds:ciapet: (ehm Federer:fagiano: )
Fortunatamente no, anche perché l'accostamento fra Torvalds e Federer è a dir poco una bestemmia. :asd:
P.S. Con te andiamo sempre troppo OT. Preferirei ci mantenessimo sull'argomento del thread senza continuare a tirare in ballo programmi open e closed, free e non free, ecc. anche perché, come vedi, si entra in un tunnel da cui non se ne esce fuori. ;)
L'orientamento agli oggetti (un possibile orientamento agli oggetti) non è un generico avvicinarsi al modo di pensare di un essere umano ma è consentire ad un essere umano di esprimere il proprio pensiero senza trasformazioni intermedie.
io è su questo che sono molto dubbioso.. il fatto delle trasformazioni intermedie :fagiano:
la programmazione a oggetti come è oggi ha la sua maggiore utilità in fase di progettazione e manutenzione del codice, ma a livello di scrittura del codice non è molto diversa dalla programmazione procedurale.
infatti si usano sempre gli stessi costrutti per il controllo del flusso, si assegnano valori a variabili ecc... tutte cose estranee al ragionamento di tipo umano.
prima che mi fraintendete devo dire che io assolutamente preferisco la programmazione OO, ma ho i miei dubbi che sia l'approccio migliore in tutti i casi. è vero che da un supporto notevole in fase di progettazione/manutenzione, ma non a gratis. quando scrivo un diagramma uml (o penso a come le classi interagiscono tra di loro) DEVO convertire il mio pensiero in un grafo che descrive le classi, le loro interazioni ecc.., quando implemento queste classi DEVO convertire il mio pensiero in algoritmo e poi in codice.
se pensiamo agli oggetti della programmazione OO e agli oggetti della realtà, notiamo che non c'è una corrispondenza univoca. sono concetti molto diversi e il primo è molto più restrittivo del secondo, questo perchè in qualche modo si fa l'assunzione di mondo chiuso (cioè che qualsiasi cosa non specificata è falsa), mentre nella realtà noi se non sappiamo una cosa non la sappiamo e basta (o ce la inventiamo :fagiano: ). magari ci sono anche linguaggi senza questo limite, ma valutare linguaggio per linguaggio non è lo scopo del mio discorso.
detto questo l'unica maniera per programmare qualcosa senza tradurre il proprio pensiero in qualcos'altro è allenare una rete neurale :read: cioè abbandonare von Neumann, perchè finchè gli oggetti sono puntatori a aree di memoria non si può programmare senza sapere cos'è un'area di memoria
spero di essermi spiegato :)
mindwings
09-09-2007, 09:47
Fortunatamente no, anche perché l'accostamento fra Torvalds e Federer è a dir poco una bestemmia. :asd:
:D era per rimanere nel titolo del thread (visto il pesante Off Topic)
(
La verità non esiste è una continua ricerca...
Cmq vedrò col tempo se ciò che dici ha fondamento:) (preferisco verificare di persona) . Tu rifatti un giro su linux magari verso gennaio (la befana porta consiglio e si spera un kde4 stabile)
quasi mi mancavano questi botta-risposta secchi :D
Il preprocessore non fa parte del linguaggio. Ed e' ovvio che non si possono esprimere "in altro modo" in C i concetti a compile time che possono essere espressi in C++ attraverso i template.
eh no il preprocessore FA parte del linguaggio ed è specificato nello standard. altrimenti ogni compilatore avrebbe direttive discordanti con le altre e a quel punto sarebbero tanti dialetti del linguaggio. e invece no, tutti usano #include #define #ifdef perchè sono definiti nello standard (6.10 Preprocessing directives :O )
Ad esempio non c'e' modo in C di fare questo in maniera altrettanto efficiente:
std::sort(vector.begin(), vector.end());
Dove il tipo di vector puo' essere parametrizzato, quindi sconosciuto a priori al momento della scrittura. Qualunque implementazione in C sarebbe meno efficiente e meno mantenibile.
questo è solo ed esclusivamente perchè il C++ è dotato di una libreria standard più completa. infatti se si usasse questa libreria http://moonflare.com/code/ctl/list.php sarebbe semplice, efficiente (forse più efficiente dei templates) e chiaramente procedurale :D
ps. mi pare che per ora il sort non è implementato, ma chiaramente ci vuole pochissimo a implementare l'algoritmo che si desidera (anche qui è una mancanza della libreria e non del linguaggio)
Esprimere un concetto in un linguaggio e' cosa differente dall'implementare qualcosa: tutto puo' essere implementato anche in assembly per ovvi motivi. Ma linguaggi a piu' alto livello sono piu' espressivi e "migliori". Il C++ essendo un superset del C e' piu' "espressivo", ne supporta tutti i costrutti e i paradigmi con la medesima efficienza, quindi e' migliore sotto ogni punto di vista.
sono daccordo sul fatto che il C++ si può usare come il C, ma non sono daccordo sul fatto che questo sia un modo "sano" di programmare.
per intenderci... o usi gli oggetti o non li usi e se non li usi il C è la scelta migliore. se fai un minestrone delle due cose viene fuori una schifezza, quindi non ha senso dire uso il C++ come se fosse il C e poi se mai mi servirà un'oggetto lo userò.
cdimauro
09-09-2007, 10:01
:D era per rimanere nel titolo del thread (visto il pesante Off Topic)
(
La verità non esiste è una continua ricerca...
Cmq vedrò col tempo se ciò che dici ha fondamento:) (preferisco verificare di persona) . Tu rifatti un giro su linux magari verso gennaio (la befana porta consiglio e si spera un kde4 stabile)
:D :D :D
Mi spiace, ma non ho più un briciolo di tempo per smanettare, come amavo fare "in gioventù".
Con Linux c'ho lavorato un anno e mezzo e m'è bastato; non metto in dubbio che migliori sempre, ma al momento non ci sono le condizioni.
Poi ti faccio notare una cosa che hai scritto "si spera un kde4 stabile". Ecco, non ce la faccio proprio a provare un'applicazione poco stabile perdendo tempo dietro alle sue magagne; prima di rilasciare un'applicazione è necessario adeguato testing, e questo purtroppo manca spesso e volentieri (specialmente il mercato dei videogiochi per PC è diventato ormai una croce: prodotti rilasciati troppo in fretta e strapieni di bug, soltanto perché la società cerca di recuperare gli investimenti fatti e confidando poi sulle successive patch per i bug fix).
Siamo andati ancora una volta OT. :p
Comunque lo spirito che mostri è quello giusto: bisogna verificare sempre (se possibile ovviamente: a volte mancano le conoscenze) la consistenza di ciò che si legge in giro. C'è troppo fanatismo in giro e la cieca accettazione di idee soltanto "perché l'ha detto tizio che è un guru" non fa peggiorare la situazione.
^TiGeRShArK^
09-09-2007, 11:41
Per quanto rigurada l'editor il mio era un esempio!
Io per primo per fare un piccolo programmino in java ho usato
Eclipse . Ma non disprezzo chi usa Vim o altri strumenti (Emacs?-GDB?)
alla fine è sempre la persona a scrivere il codice... Le cagate le puoi fare anche con il miglior strumento.
La ma metafora tennistica era messa li apposta. Mi dispiace che non l'hai compresa. O credi di esprimerti come Torvalds:ciapet: (ehm Federer:fagiano: )
Per un piccolo programmino o per un sempice progetto puoi usare quello ke ti pare...
Ma per progetti dell'ordine delle centinaia di KLOC con decine e decine di persone che ci mettono le mani dimmi come fai a non suicidarti quando devi mettere mani a parti di codice che non avevi visto fino a quella mattina (magari con classi da 7-8000 righe :muro: )senza usare tutti gli strumenti forniti da eclipse :D
ah.. dimenticavo..
ovviamente ci sono anke le classi generate...
indovinate quanto occupa il codice sorgente di una classe generata che ho visto l'altro giorno?
poco + di 1 MB :fagiano:
Per fortuna sapevo + o - dove mettere le mani altrimenti avrei iniziato a cercare chi ha progettato quell'obbrobrio di architettura per farlo sodomizzare da una decina di big bamboo :muro:
^TiGeRShArK^
09-09-2007, 11:44
PhotoShop e The GIMP sono strumenti che permettono all'ottimo grafico di realizzare ottima grafica in un certo tempo, determinato dalla bontà dei tool che mettono a disposizione.
io sono rimasto schokkato dai video su youtube di quei pazzi ke disegnano cose assurde col PAINT :mbe:
http://it.youtube.com/results?search_query=paint&search=Cerca
dategli un okkiata :asd:
mindwings
09-09-2007, 11:47
Per un piccolo programmino o per un sempice progetto puoi usare quello ke ti pare...
Ma per progetti dell'ordine delle centinaia di KLOC con decine e decine di persone che ci mettono le mani dimmi come fai a non suicidarti quando devi mettere mani a parti di codice che non avevi visto fino a quella mattina (magari con classi da 7-8000 righe :muro: )senza usare tutti gli strumenti forniti da eclipse :D
In quei casi sono il primo a dire che un semplice Editor di testo non basta.:)
Per un piccolo programmino o per un sempice progetto puoi usare quello ke ti pare...
Ma per progetti dell'ordine delle centinaia di KLOC con decine e decine di persone che ci mettono le mani dimmi come fai a non suicidarti quando devi mettere mani a parti di codice che non avevi visto fino a quella mattina (magari con classi da 7-8000 righe :muro: )senza usare tutti gli strumenti forniti da eclipse :D
se non avessero avuto gli strumenti di eclipse non sarebbero riusciti a produrre quell'obbrobrio :O
franklar
09-09-2007, 12:15
Poi ti faccio notare una cosa che hai scritto "si spera un kde4 stabile". Ecco, non ce la faccio proprio a provare un'applicazione poco stabile perdendo tempo dietro alle sue magagne; prima di rilasciare un'applicazione è necessario adeguato testing, e questo purtroppo manca spesso e volentieri (specialmente il mercato dei videogiochi per PC è diventato ormai una croce: prodotti rilasciati troppo in fretta e strapieni di bug, soltanto perché la società cerca di recuperare gli investimenti fatti e confidando poi sulle successive patch per i bug fix).
Quello che voleva dire mindwings è "speriamo che esca la versione stabile nei tempi previsti" e non "speriamo che la 4.0 sia stabile". Di sicuro è che quando uscirà KDE 4.0 sarà stabile :read: , non ci piove, chi ama smanettare può sempre provare le varie alpha, beta e rc che si stanno susseguendo, ma da queste parti quando si dice che una versione è stabile lo è per davvero :O
io è su questo che sono molto dubbioso..
Gli oggetti non sono puntatori nè è necessario usare un puntatore per rappresentare un oggetto.
"Oggetto", nella prospettiva orientata agli oggetti, significa "definizione autonoma". E' la descrizione di qualcosa dove "qualcosa" comprende anche tutto ciò da cui la descrizione dipende, vale a dire tutto ciò la cui definizione deve esistere affinchè io possa fornire la descrizione. Questa definizione di oggetto è fondata sul minimo logicamente necessario affinchè l'uomo possa essere consapevole di sè e del mondo che lo circonda. E' anche direttamente applicabile alla programmazione. Una semplicissima prova consiste nel prendere il codice sorgente di un programma e togliere dei pezzi: se togliendo quel pezzo non puoi più compilare allora hai eliminato parte di un oggetto. Il fatto che una parte di un programma sia anche un oggetto ha un certo numero di conseguenze, totalmente off-topic, di cui mi pare si sia già discusso in passato.
^TiGeRShArK^
09-09-2007, 12:49
se non avessero avuto gli strumenti di eclipse non sarebbero riusciti a produrre quell'obbrobrio :O
veramente ancora non esisteva eclipse quando hanno iniziato a scrivere quello skifo :fagiano:
All'inizio non ho idea cosa usassero..
poi sono passati al borland jbuilder e infine ad eclipse da quando è arrivato alla versione 2.
Cmq il problema non è lo strumento è la testa malata che avevano :muro:
La superiorità putativa dell'orientamento agli oggetti rispetto ad altre prospettive sta nel suo perchè. L'orientamento agli oggetti è il tentativo di far eseguire ad un calcolatore la rappresentazione umana della soluzione ad un problema. Compito di enorme difficoltà perchè qui andiamo a seminare un orto, quello della cognizione umana dei fenomeni, che è pieno di buche. Che sia questo il suo perchè è un fatto storico, desumibile dagli scritti di Alan Kay, Nygaard e Dahal: cioè coloro che hanno fondato l'orientamento agli oggetti.
Questo nell' ipotesi che l'orientamento agli oggetti sia sempr la "rappresentazione umana della soluzione ad (di?) un problema". Ma e' sempre cosi' ? Non mi sembra, anzi in matematica l'approccio "ad oggetti" e' tutto fuorche' la norma. Posso in ogni caso ricondurre tutto a quell'orientamento, ma il risultato non e' sempre intuitivo.
Ad esempio un intero e' un reale, per cui in una gerarchia mi aspetterei di vedere i reali come base degli interi, ma d'altra parte i reali supportano delle operazioni aggiuntive (divisione ad esempio) per cui sembrerebbe il contrario...
Cade quindi quello che dovrebbe essere il vantaggio di usare una rappresentazione piu' "umana" (ovvero di essere piu' diretta e comprensibile).
Senza contare che quello della OOP e' un modelo particolare, e come tutti i modelli comporta delle semplificazioni/assunzioni/etc. che possono far si' che in alcune circostanze il modello stesso sia sbagliato.
eh no il preprocessore FA parte del linguaggio ed è specificato nello standard. altrimenti ogni compilatore avrebbe direttive discordanti con le altre e a quel punto sarebbero tanti dialetti del linguaggio. e invece no, tutti usano #include #define #ifdef perchè sono definiti nello standard (6.10 Preprocessing directives :O )
Sicuro sia questa l'interpretazione? Il preprocessore per come me lo ricordo in C è un programma che si occupa di compiere delle operazioni preliminari sul sorgente e applica le direttive impartite. Chiaramente va standardizzato (e ci mancherebbe) visto che il risultato dei mastruzi che compie è ciò che di fatto il compilatore elebora ma, proprio per la sua natura, non direi che è parte del linguaggio in senso stretto.
Non ti so dire quale sia la prospettiva degli studi matematici. O ingegneristici o filosofici.
Io parlo della ricerca di una prospettiva applicabile alla programmazione. La programmazione è l'attivita di rappresentazione della soluzione di (è vero :fagiano:) un problema. Rappresentare significa descrivere in certi termini. Ecco, noi cerchiamo quei certi termini. Se nella programmazione procedurale quei certi termini sono registro di memoria, operazione elementare, ordine parziale tra operazioni, nella programmazione orientata agli oggetti quei termini potrebbero essere oggetto e relazione.
In linea di principio poter descrivere la soluzione nella sua forma umana è vantaggioso perchè non comporta una trasformazione dei termini in cui la soluzione è espressa. E' per questo che dico "è superiore alle altre prospettive".
Dico che questa superiorità è putativa, cioè non dimostrabile nei fatti, non tanto perchè la prospettiva orientata agli oggetti, in quanto modello, è un'approssimazione ma in quanto la realtà che vorremmo approssimare non è chiara.
La prospettiva procedurale è l'approssimazione di una realtà nota: il funzionamento di un calcolatore.
La prospettiva orientata agli oggetti è l'approssimazione di un ipotesi: il funzionamento di un essere umano.
E' questa natura ipotetica che causa la grande varietà di idee e soluzioni che si percepisce nelle discussioni sull'orientamento agli oggetti. Ed è la stessa ragione per cui vent'anni fa per fare orientamento agli oggetti si dovevano scrivere gerarchie di classi mentre oggi non parliamo neppure più di classe.
Sicuro sia questa l'interpretazione? Il preprocessore per come me lo ricordo in C è un programma che si occupa di compiere delle operazioni preliminari sul sorgente e applica le direttive impartite. Chiaramente va standardizzato (e ci mancherebbe) visto che il risultato dei mastruzi che compie è ciò che di fatto il compilatore elebora ma, proprio per la sua natura, non direi che è parte del linguaggio in senso stretto.
lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)... se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C
lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)... se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C
nel libro c how to program dice che le direttive del preprocessore non fanno parte del linguaggio c
cdimauro
10-09-2007, 08:34
eh no il preprocessore FA parte del linguaggio ed è specificato nello standard. altrimenti ogni compilatore avrebbe direttive discordanti con le altre e a quel punto sarebbero tanti dialetti del linguaggio. e invece no, tutti usano #include #define #ifdef perchè sono definiti nello standard (6.10 Preprocessing directives :O )
Mettersi d'accordo mi pare il minimo, ma ripeto: un preprocessore non fa parte del linguaggio vero e proprio. Tant'è che lo si può benissimo aggiungere in un secondo momento senza toccare di una virgola né il linguaggio né i compilatori esistenti.
Pre-processore, appunto. ;)
questo è solo ed esclusivamente perchè il C++ è dotato di una libreria standard più completa. infatti se si usasse questa libreria http://moonflare.com/code/ctl/list.php sarebbe semplice, efficiente (forse più efficiente dei templates) e chiaramente procedurale :D
Usa le macro (quindi il preprocessore). Ma tu guarda: non l'avrei mai detto. :p
ps. mi pare che per ora il sort non è implementato, ma chiaramente ci vuole pochissimo a implementare l'algoritmo che si desidera (anche qui è una mancanza della libreria e non del linguaggio)
Non credo sia così facile. Se prendi l'esempio di cui sopra, cioé la definizione di una lista che conserva dei punti, servirà definire un algoritmo di ordinamento per questo tipo di dati.
Anche qui "a naso" servirà qualche macro per gestire l'operazione di ordinamento in maniera "astratta".
sono daccordo sul fatto che il C++ si può usare come il C, ma non sono daccordo sul fatto che questo sia un modo "sano" di programmare.
per intenderci... o usi gli oggetti o non li usi e se non li usi il C è la scelta migliore. se fai un minestrone delle due cose viene fuori una schifezza, quindi non ha senso dire uso il C++ come se fosse il C e poi se mai mi servirà un'oggetto lo userò.
Te l'avevo già scritto tempo fa e te lo ripeto ancora una volta: il C++ non ha soltanto gli oggetti in più rispetto al C! ;)
lo stesso succede per i template d'altra parte (danno indicazioni al compilatore su come compilare il programma)...
I template NON SONO MACRO! Fanno parte del linguaggio e già a livello di parsing vengono fatti tutti i controlli che è possibile fare (leggi: sui tipi di dato che NON sono opachi).
se io scrivo #include o #define in C sto dicendo qualcosa in un linguaggio e questo linguaggio è il C
Quindi se io scrivo
#define STAMPA(CITTA) print "Com'è bello far l'amore da " + CITTA + ' in giù...'
dici che un compilatore C riuscirebbe a digerirlo? Tanto sto usando #define in C, no? :p
P.S. In Python funzionebbe, ma... non farebbe niente. Il # marca l'inizio di un commento. ;)
Mettersi d'accordo mi pare il minimo, ma ripeto: un preprocessore non fa parte del linguaggio vero e proprio. Tant'è che lo si può benissimo aggiungere in un secondo momento senza toccare di una virgola né il linguaggio né i compilatori esistenti.
beh ma allo stesso tempo direi che il preprocessore è una parte indispensabile del linguaggio C, non sarebbe possibile nemmeno includere una libreria senza. e poi ripeto..
#includimi stringhe.h
int main(int argc, char *argv[])
{
return 0;
}
non è codice C perchè non rispetta lo standard
Pre-processore, appunto. ;)
il termine ha a che fare con il compilatore, non con il linguaggio.
il linguaggio è composto da sintassi e semantica. la sintassi mi dice cosa posso scrivere, mentre la semantica mi dice cosa significa quello che ho scritto.
la semantica di #include è dire al compilatore di includere la libreria specificata, non vedo cosa gli manca per essere parte del linguaggio
Usa le macro (quindi il preprocessore). Ma tu guarda: non l'avrei mai detto. :p
cambia la sintassi ma in fondo con i template succede la stessa cosa. cioè il compilatore li espande al momento della compilazione ;) l'unica differenza è che non deve necessariamente farlo inline
Non credo sia così facile. Se prendi l'esempio di cui sopra, cioé la definizione di una lista che conserva dei punti, servirà definire un algoritmo di ordinamento per questo tipo di dati.
Anche qui "a naso" servirà qualche macro per gestire l'operazione di ordinamento in maniera "astratta".
l'unica cosa che serve è una funzione per comparare due elementi... un puntatore a funzione in parole povere :read:
Te l'avevo già scritto tempo fa e te lo ripeto ancora una volta: il C++ non ha soltanto gli oggetti in più rispetto al C! ;)
lo so visto che l'ho usato molte volte il C++, ma il discorso non cambia.. usare il C++ come se fosse il C è snaturarlo, come è snaturare il C quando si tenta di programmare a oggetti
I template NON SONO MACRO! Fanno parte del linguaggio e già a livello di parsing vengono fatti tutti i controlli che è possibile fare (leggi: sui tipi di dato che NON sono opachi).
vorrà dire che template e macro non hanno la stessa semantica e nemmeno la stessa sintassi
Quindi se io scrivo
#define STAMPA(CITTA) print "Com'è bello far l'amore da " + CITTA + ' in giù...'
dici che un compilatore C riuscirebbe a digerirlo? Tanto sto usando #define in C, no? :p
P.S. In Python funzionebbe, ma... non farebbe niente. Il # marca l'inizio di un commento. ;)
la sintassi e la semantica del preprocessore sta scritta sullo standard.. se scrivi una roba del genere dovresti dargli una ripassata :Prrr:
Ed è la stessa ragione per cui vent'anni fa per fare orientamento agli oggetti si dovevano scrivere gerarchie di classi mentre oggi non parliamo neppure più di classe.
Eh si`, al giorno d'oggi nessuno parla di classi :mbe:
Era una frase sintetica. Le classi ci sono ancora ma dal significato originario di elemento di una gerarchia si è passati all'altro (pur presente) di raggruppamento di esemplari. C'è una crisi dell'ereditarietà. Si vede chiaramente in Chapel, Scala, Newspeak, Fortress. Cioè nelle lingue che nascono adesso.
cdimauro
10-09-2007, 13:31
beh ma allo stesso tempo direi che il preprocessore è una parte indispensabile del linguaggio C, non sarebbe possibile nemmeno includere una libreria senza. e poi ripeto..
Questo è UN ALTRO problema, e non riguarda soltanto il C.
Ad esempio anche il Pascal ne soffriva; problema risolto poi con delle direttive di preprocessore aggiunte a posteriori (quelle della Borland sono diventate poi lo standard di fatto per tutti i linguaggi di derivazione Pascal).
#includimi stringhe.h
int main(int argc, char *argv[])
{
return 0;
}
non è codice C perchè non rispetta lo standard
Non rispetta la sintassi del preprocessore che è stato scelto dallo standard, ma potrei crearmi il mio preprocessore per cui avrebbe perfettamente senso. ;)
il termine ha a che fare con il compilatore, non con il linguaggio.
il linguaggio è composto da sintassi e semantica. la sintassi mi dice cosa posso scrivere, mentre la semantica mi dice cosa significa quello che ho scritto.
la semantica di #include è dire al compilatore di includere la libreria specificata, non vedo cosa gli manca per essere parte del linguaggio
Quella sintassi specifica al PREPROCESSORE di compiere un'operazione, e non ha nulla a che vedere col linguaggio.
cambia la sintassi ma in fondo con i template succede la stessa cosa. cioè il compilatore li espande al momento della compilazione ;) l'unica differenza è che non deve necessariamente farlo inline
No, ti ho spiegato prima che coi template non è così.
l'unica cosa che serve è una funzione per comparare due elementi... un puntatore a funzione in parole povere :read:
Questo mi sembra ovvio.
lo so visto che l'ho usato molte volte il C++, ma il discorso non cambia.. usare il C++ come se fosse il C è snaturarlo, come è snaturare il C quando si tenta di programmare a oggetti
Su questo sono perfettamente d'accordo.
vorrà dire che template e macro non hanno la stessa semantica e nemmeno la stessa sintassi
Infatti sono due cose completamente diverse.
la sintassi e la semantica del preprocessore sta scritta sullo standard.. se scrivi una roba del genere dovresti dargli una ripassata :Prrr:
Lo standard ha specificato, oltre alla sintassi del linguaggio C, anche quella del preprocessore, ma sono due cose diverse appunto.
Eh, no, non ho bisogno di ripassarlo, perché il K&R lo conosco bene, come conosco bene anche tanta letteratura informatica in merito a linguaggi, interpreti e compilatori, e la differenza fra linguaggio e preprocessore.
Comunque basta farti una ricerca e troverai montagne di letteratura in merito: non sono certo io ad arrogarmi il diritto di definire cos'è un preprocessore e cos'è un linguaggio, visto che l'ha già fatto gente ben più illustre di me, e da parecchio tempo. ;)
cdimauro
10-09-2007, 13:32
Era una frase sintetica. Le classi ci sono ancora ma dal significato originario di elemento di una gerarchia si è passati all'altro (pur presente) di raggruppamento di esemplari. C'è una crisi dell'ereditarietà. Si vede chiaramente in Chapel, Scala, Newspeak, Fortress. Cioè nelle lingue che nascono adesso.
E Python (anche se è vecchiotto come linguaggio)? :fagiano:
Python è bello vecchio e, in tutta onestà, è una lingua a cui non ho mai prestato grande attenzione.
Comunqe se ha una sintassi specifica per la definizione di un oggetto (di solito è come quella della classe ma genera un singleton, genera Scala) e un tipo "interfaccia" la cui applicabilità è indipendente da una specifica dichiarazione (a la Ruby o Chapel) allora propone un'alternativa alla gerarchia classica.
Che non sia un barbatrucco: qualsiasi linguaggio che definisca un meccanismo introspettivo (la riflessione di Java, ad es.) permette anche di dire che un certo oggetto è un Pippo a prescindere dal fatto che dichiari di avere Pippo come parente e di usarlo come un Pippo. Altro è avere altro è simulare.
Eh, no, non ho bisogno di ripassarlo, perché il K&R lo conosco bene, come conosco bene anche tanta letteratura informatica in merito a linguaggi, interpreti e compilatori, e la differenza fra linguaggio e preprocessore.
Comunque basta farti una ricerca e troverai montagne di letteratura in merito: non sono certo io ad arrogarmi il diritto di definire cos'è un preprocessore e cos'è un linguaggio, visto che l'ha già fatto gente ben più illustre di me, e da parecchio tempo. ;)
forse davo per scontata una definizione troppo generale di linguaggio :stordita: comunque vedrò di documentarmi ;)
cdimauro
10-09-2007, 14:47
Python è bello vecchio e, in tutta onestà, è una lingua a cui non ho mai prestato grande attenzione.
Comunqe se ha una sintassi specifica per la definizione di un oggetto (di solito è come quella della classe ma genera un singleton, genera Scala) e un tipo "interfaccia" la cui applicabilità è indipendente da una specifica dichiarazione (a la Ruby o Chapel) allora propone un'alternativa alla gerarchia classica.
Python ha una sintassi specifica per la definizione di un oggetto e supporta l'ereditarietà multipla.
Come linguaggio dinamico, poi, non ha nemmeno bisogno di specificare una classe (o interfaccia) da cui derivare specifiche funzionalità. Voglio dire che se nei miei progetti ho bisogno che gli oggetti che manipolo debbano rispondere a particolari funzionalità, è sufficiente che siano stati definiti degli appositi metodi.
Esempio:
class A:
def Stampa(self):
print 'Hai invocato il metodo "Stampa" della classe A'
class B:
def Stampa(self):
print 'Questa volta hai invocato il metodo "Stampa" della classe B'
def ProvaStampa(Istanza):
Istanza.Stampa()
ProvaStampa(A())
ProvaStampa(B())
A e B derivano entrambe dalla classe fondamentale (object), ma sono capaci di rispondere allo stesso messaggio.
Che non sia un barbatrucco: qualsiasi linguaggio che definisca un meccanismo introspettivo (la riflessione di Java, ad es.) permette anche di dire che un certo oggetto è un Pippo a prescindere dal fatto che dichiari di avere Pippo come parente e di usarlo come un Pippo. Altro è avere altro è simulare.
Con Python puoi avere entrambe le cose. :p
cdimauro
10-09-2007, 15:06
Insomma no. :D.
Come no? Puoi fare tutto! :read: E' onnipotente. :Prrr: :p
:D Ma che ci fai, ma che fai! Ci giochi a tresette con python! :D
cdimauro
10-09-2007, 15:18
:D Ma che ci fai, ma che fai! Ci giochi a tresette con python! :D
:D A parte gli scherzi, Python riesce a soddisfare entrambe le cose che hai riportato: perché non andrebbe bene?
Il tutto dipende soltanto dall'uso che se ne fai: puoi anche sviluppare classi e interfacce dimenticandoti della reflection e della possibilità di definire soltanto dei metodi come interfaccia.
Nota bene: potrei anche forzare che un'istanza derivi da una classe che implementa un certo metodo di una certa interfaccia, in modo da eliminare il secondo tipo di utilizzo.
In soldoni: prima di chiamare il metodo Stampa posso anche controllare che l'oggetto in questione sia istanza di una "interfaccia" (che in Python si traduce sempre in una classe, visto che supporta l'ereditarietà multipla) ben precisa.
Ho detto no perchè la partita si gioca non sulla possibilità di invocare dei metodi ma sull'appartenenza ad un tipo in base al fatto che abbia o non abbia certe caratteristiche.
Supponendo che una funzione accetti come argomento un Impiegato (perchè usa opera su metodi che sono propri dei soli impiegati), come discrimi in un insieme di Dipendenti chi siano gli impiegati e chi siano gli operai?
Attraverso relazioni statiche io passo a quella funzione tutti e soli quei riferimenti che dichiarino di essere Impiegati (o che abbiano il ruolo di, come è solitamente necessario).
Attraverso relazioni dinamiche io passo a quella funzione tutti e soli coloro i quali possiedano le caratteristiche di un impiegato, a prescindere dal fatto che dichiarino o meno di esserlo.
Tutto qua.
cdimauro
10-09-2007, 15:45
Devi scusare la mia ignoranza, ma io lo vedo perfettamente realizzabile in Python senza ricorrere a "barbatrucchi". :)
No, non ti scuso! 50 frustate! :D Qui se c'è qualcuno che è ignorante in python è il sottoscritto.
Può anche darsi che sia sia possibile, non so. Ripeto, non ho dimestichezza coi serpenti.
cdimauro
10-09-2007, 15:58
Fammi un esempio col linguaggio che preferisci (nella speranza che rientri fra quelli da me conosciuti :p), e te ne proporrò una versione in Python "no barbatrucchi edition". :)
P.S. Di solito in ufficio sono io a dare le scudisciate. :D
Ricordami che devo scrivere un libro: Ruby in 25 secondi :D
module Dipendente
def printMatricola
"blabla"
end
end
class Impiegato
include Dipendente
end
class Operaio
include Dipendente
end
impiegato = Impiegato.new()
operaio = Operaio.new();
$stdout.print "impiegato e' un tipo di dipendente? " , (impiegato.kind_of?Dipendente).to_s
^TiGeRShArK^
10-09-2007, 16:43
Ricordami che devo scrivere un libro: Ruby in 25 secondi :D
module Dipendente
def printMatricola
"blabla"
end
end
class Impiegato
include Dipendente
end
class Operaio
include Dipendente
end
impiegato = Impiegato.new()
operaio = Operaio.new();
$stdout.print "impiegato e' un tipo di dipendente? " , (impiegato.kind_of?Dipendente).to_s
se togli le parentesi dopo il .new e il ";" ke non c'entra una mazza probabilmente potresti scrivere il libro "ruby in 23 secondi e 1/2" :asd:
Eh, ragazzo mio, Prova a scrivere codice Java per 12 anni per otto ore al giorno, festività incluse, e poi vedi se non ti parte il punto e virgola! :D
Comunque devo dire che 'sto ruby quasi quasi... ha una bella documentazione. Peccato per quel WIN32OLE, i Thread "green", la mancanza di una libreria per GUI (in 22 megabyte ci poteva anche stare), l'amorfismo...
^TiGeRShArK^
10-09-2007, 16:56
Eh, ragazzo mio, Prova a scrivere codice Java per 12 anni per otto ore al giorno, festività incluse, e poi vedi se non ti parte il punto e virgola! :D
Comunque devo dire che 'sto ruby quasi quasi... ha una bella documentazione. Peccato per quel WIN32OLE, i Thread "green", la mancanza di una libreria per GUI (in 22 megabyte ci poteva anche stare), l'amorfismo...
io come libreria per le GUI ho provato ad usare wxruby ke sembra si stia stabilizzando ultimamente e wxsugar per semplificare notevolmente il suo utilizzo (tipo parametri con valori di default che devono essere specificati obbligatoriamente se vuoi cambiare anke solo uno degli altri parametri).
Il sistema di gestione delle librerie è una figata...ma con la documentazione io non mi ci trovo proprio a volte :mbe:
Per certe cose perdo + tempo a cercare la documentazione che a capire come funziona...
tu ke usi per la documentazione? :fagiano:
e cmq in effetti anke a me partono piuttosto spesso i ; :asd:
EDIT: ke intendi per Thread "Green"? :mbe:
il fatto che non sono thread nativi?
se si quello sta parecchio sulle balle anke a me :mad:
Per la documentazione ho usato (il codice che ho scritto è il primo sorgente ruby che io abbia mai prodotto) questa pagina qui
http://www.ruby-doc.org/docs/ProgrammingRuby/
Che penso sia la documentazione del linguaggio, 'na specie di tutorialone. Ho visto che sono incluse anche le librerie. Comunque non l'ho esplorata bene.
Sì, per Thread green intendo i thread non nativi.
^TiGeRShArK^
10-09-2007, 17:35
Per la documentazione ho usato (il codice che ho scritto è il primo sorgente ruby che io abbia mai prodotto) questa pagina qui
http://www.ruby-doc.org/docs/ProgrammingRuby/
Che penso sia la documentazione del linguaggio, 'na specie di tutorialone. Ho visto che sono incluse anche le librerie. Comunque non l'ho esplorata bene.
Sì, per Thread green intendo i thread non nativi.
si quella per le librerie di base è ottima..
il problema è per le altre librerie... :muro:
come ad esempio wxruby..
ke all'inizio mi ha fatto bestemmiare un pò :fagiano:
cdimauro
10-09-2007, 17:36
Ecco la versione Python (in 15 secondi :D):
class Dipendente:
def printMatricola(self):
print 'blabla'
class Impiegato(Dipendente): pass
class Operaio(Dipendente): pass
impiegato = Impiegato()
operaio = Operaio()
print 'impiegato è un tipo di dipentente?', isinstance(impiegato, Dipendente)
print 'impiegato è un tipo di operaio?', isinstance(impiegato, Operaio)
Le due print stampano rispettivamente True e False rispettivamente. ;)
Soddisfatto? :D
cdimauro
10-09-2007, 17:43
Eh, ragazzo mio, Prova a scrivere codice Java per 12 anni per otto ore al giorno, festività incluse, e poi vedi se non ti parte il punto e virgola! :D
Capitava pure a me passando da Pascal & Delphi a Python. :fagiano:
Comunque devo dire che 'sto ruby quasi quasi... ha una bella documentazione.
Forse perché è Java-style? :angel:
Peccato per quel WIN32OLE, i Thread "green", la mancanza di una libreria per GUI (in 22 megabyte ci poteva anche stare), l'amorfismo...
Ehm, per Thread "green" / nativi esattamente cosa intendete?
Comunque Python per i thread ha questo http://docs.python.org/lib/module-threading.html modulo, mentre per la GUI questo http://docs.python.org/lib/tkinter.html
L'amorfismo lo trovo semplicemente fantastico. :D
Ma poi non eri tu che dicevi che la rappresentazione "tradizionale" (gerarchica) degli oggetti è in crisi perché non è in grado di modellare bene la realtà, e coi linguaggi amorfi invece è possibile farlo? :fiufiu:
^TiGeRShArK^
10-09-2007, 17:48
Capitava pure a me passando da Pascal & Delphi a Python. :fagiano:
Forse perché è Java-style? :angel:
Ehm, per Thread "green" / nativi esattamente cosa intendete?
Comunque Python per i thread ha questo http://docs.python.org/lib/module-threading.html modulo, mentre per la GUI questo http://docs.python.org/lib/tkinter.html
L'amorfismo lo trovo semplicemente fantastico. :D
Ma poi non eri tu che dicevi che la rappresentazione "tradizionale" (gerarchica) degli oggetti è in crisi perché non è in grado di modellare bene la realtà, e coi linguaggi amorfi invece è possibile farlo? :fiufiu:
ma pyhton per quello ke ricordo io ha lo stesso problema di ruby con i thread.. o no? :fagiano:
in pratica anzikè usare thread nativi genera dei thread "virtuali" che girano all'interno dell'interprete e quindi anche se hai una macchina con 8000 processori e usi 8000 thread in ruby o in python ti usa un core solo :fagiano:
^TiGeRShArK^
10-09-2007, 17:49
http://docs.python.org/lib/module-threading.html modulo, mentre per la GUI questo http://docs.python.org/lib/tkinter.html
Tk ce l'ha anke ruby..
fino a qualke versione fa era installato di default, ora invece si deve scaricare a parte l'ultima versione..
qdi mi sa ke era la libreria "non ufficialmente ufficiale" x le GUI.
Cmq da quello ke ho visto wxruby mi ispira di + :stordita:
(e anke wxpython ovviamente :p)
cdimauro
10-09-2007, 18:28
ma pyhton per quello ke ricordo io ha lo stesso problema di ruby con i thread.. o no? :fagiano:
in pratica anzikè usare thread nativi genera dei thread "virtuali" che girano all'interno dell'interprete e quindi anche se hai una macchina con 8000 processori e usi 8000 thread in ruby o in python ti usa un core solo :fagiano:
Francamente non sono informato in merito, ma leggendo questo http://docs.python.org/lib/module-thread.html penso che i thread in Python siano implementati usando le apposite API del s.o. "ospite".
In particolare è questo
"as well as on systems that have a POSIX thread (a.k.a. ``pthread'') implementation"
che mi fa propendere per l'ipotesi che la situazione non sia la stessa di quella di Ruby.
Tk ce l'ha anke ruby..
fino a qualke versione fa era installato di default, ora invece si deve scaricare a parte l'ultima versione..
qdi mi sa ke era la libreria "non ufficialmente ufficiale" x le GUI.
E' probabile. :D
Strano che non sia integrata nel pacchetto ufficiale: il setup di Python 2.5 occupa circa 10,5MB e ha una valanga di librerie.
Cmq da quello ke ho visto wxruby mi ispira di + :stordita:
(e anke wxpython ovviamente :p)
E' fra le più usate. Però non ne ho avuto mai bisogno per cui finora non mi ci sono cimentato... :fagiano:
I linguaggi amorfi sono più flessibili. Ma questo ce lo insegna Smalltalk. E' un do ut des. Il mono-poli morfismo ti consente di sapere con chi hai a che fare. L'amorfismo no. Smalltalk risolve la questione con la sua straordinaria piattaforma (giustamente bilanciata da un'orrenda documentazione).
In Smalltalk io non so quale sia il tipo di "pippo" ma posso sempre cliccargli sopra e fare un ispezione sul tipo. E' una soluzione piuttosto elegante. Sarebbe anche pratica se non fosse per quello stramaledetto browser a cinque pannelli e seimila menu...
^TiGeRShArK^
10-09-2007, 19:13
Francamente non sono informato in merito, ma leggendo questo http://docs.python.org/lib/module-thread.html penso che i thread in Python siano implementati usando le apposite API del s.o. "ospite".
In particolare è questo
"as well as on systems that have a POSIX thread (a.k.a. ``pthread'') implementation"
che mi fa propendere per l'ipotesi che la situazione non sia la stessa di quella di Ruby.
E' probabile. :D
Strano che non sia integrata nel pacchetto ufficiale: il setup di Python 2.5 occupa circa 10,5MB e ha una valanga di librerie.
E' fra le più usate. Però non ne ho avuto mai bisogno per cui finora non mi ci sono cimentato... :fagiano:
si però solo un thread per volta è utilizzato dall'interprete:
Q. I processori multi-core diverranno lo standard (anche sui portatili) nel prossimo futuro. Python 3.0 riuscirà a sbarazzarsi del GIL (Global Interpreter Lock) in modo da utilizzare appieno le nuove piattaforme?
A. No. Attualmente non stiamo cambiando in modo pesante l'implementazione CPython. Sbarazzarsi del GIL implicherebbe una grossa riscrittura dell'interprete dato che tutte le strutture dati interne (e le operazioni di conteggio delle reference) dovrebbero essere rese thread-safe. Tutto ciò è stato già tentato (alla fine degli anni '90 da Greg Stein) e come risultato si ottenne un interprete due volte più lento. Se disponi di diverse CPU e desideri utilizzarle tutte, esegui un fork di tanti processi quante CPU sono disponibili nella tua architettura. Scrivi le tue applicazioni web per essere scalabili, giusto? Dunque se sei in grado di eseguire numerose copie del tuo codice su macchine differenti, allora dovrebbe essere banale eseguire numerose istanze all'interno di un'unica macchina. Se stai cercando il vero multi-threading in Python, allora fai uso di Jython o IronPython: la JVM e il CLR supportano thread multi-CPU. Ovviamente, assicurati di essere ben preparato nei confronti di deadlock, live-lock, race condition e tutto il casino che deriva dalla gestione di codice multi-threated.
Ovviamente ci sono implementazioni che riescono a rendere davvero multi-threaded python senza bisogno di fork dell'interprete come jython e ironpython...
ma mi sa ke sono *lievemente* + lenti della versione originale :fagiano:
^TiGeRShArK^
10-09-2007, 19:16
I linguaggi amorfi sono più flessibili. Ma questo ce lo insegna Smalltalk. E' un do ut des. Il mono-poli morfismo ti consente di sapere con chi hai a che fare. L'amorfismo no. Smalltalk risolve la questione con la sua straordinaria piattaforma (giustamente bilanciata da un'orrenda documentazione).
In Smalltalk io non so quale sia il tipo di "pippo" ma posso sempre cliccargli sopra e fare un ispezione sul tipo. E' una soluzione piuttosto elegante. Sarebbe anche pratica se non fosse per quello stramaledetto browser a cinque pannelli e seimila menu...
è un pò un incubo smalltalk :mbe:
sarà ke non mi ci sono mai messo seriamente :fagiano:
cdimauro
10-09-2007, 19:24
I linguaggi amorfi sono più flessibili. Ma questo ce lo insegna Smalltalk. E' un do ut des. Il mono-poli morfismo ti consente di sapere con chi hai a che fare. L'amorfismo no. Smalltalk risolve la questione con la sua straordinaria piattaforma (giustamente bilanciata da un'orrenda documentazione).
In Smalltalk io non so quale sia il tipo di "pippo" ma posso sempre cliccargli sopra e fare un ispezione sul tipo. E' una soluzione piuttosto elegante. Sarebbe anche pratica se non fosse per quello stramaledetto browser a cinque pannelli e seimila menu...
Mumble mumble: per "ispezione" cosa intendi di preciso? Perché anche in Python posso controllare il tipo di un oggetto, e pure la sua struttura interna.
cdimauro
10-09-2007, 19:25
si però solo un thread per volta è utilizzato dall'interprete:
Ovviamente ci sono implementazioni che riescono a rendere davvero multi-threaded python senza bisogno di fork dell'interprete come jython e ironpython...
ma mi sa ke sono *lievemente* + lenti della versione originale :fagiano:
Letto, e allora mi sbagliato. Però è strano che la libreria thread sia disponibile soltanto su alcune piattaform: se fosse "nativa", dovrebbe poter girare su qualunque porting di Python.
Comunque la FAQ è piuttosto eloquente, per cui mi posso mettere l'anima in pace. :p
Per ispezione intendo quell'ispezione. Solo che mentre in smalltalk è come se il programma fosse sempre in esecuzione, il codice sorgente di python, essendo scritto al di fuori di un ipotetico sistema python, non è direttamente ispezionabile.
Ovviamente neppure il codice Smalltalk scritto in Notepad è ispezionabile con un click del mouse ma scrivere codice Smalltalk al di fuori di un browser smalltalk è come tagliarsi le unghie con una motosega.
cdimauro
10-09-2007, 19:36
Per ispezione intendo quell'ispezione. Solo che mentre in smalltalk è come se il programma fosse sempre in esecuzione, il codice sorgente di python, essendo scritto al di fuori di un ipotetico sistema python, non è direttamente ispezionabile.
Ovviamente neppure il codice Smalltalk scritto in Notepad è ispezionabile con un click del mouse ma scrivere codice Smalltalk al di fuori di un browser smalltalk è come tagliarsi le unghie con una motosega.
Ehm... Se scrivi "Python" senza specificare un file lanci l'interprete interattivo:
>>> class Dipendente:
... @staticmethod
... def printMatricola():
... print 'blabla'
...
>>> class Impiegato(Dipendente): pass
...
>>> class Operaio(Dipendente): pass
...
>>> impiegato = Impiegato()
>>> operaio = Operaio()
>>> print 'impiegato è un tipo di dipentente?', isinstance(impiegato, Dipendente)
impiegato è un tipo di dipentente? True
>>> print 'impiegato è un tipo di operaio?', isinstance(impiegato, Operaio)
impiegato è un tipo di operaio? False
>>> impiegato
<__main__.Impiegato instance at 0x004A35A8>
>>> dir(impiegato)
['__doc__', '__module__', 'printMatricola']
>>> impiegato.__doc__
>>> impiegato.__module__
'__main__'
>>> impiegato.__printMatricola
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: Impiegato instance has no attribute '__printMatricola'
>>> impiegato.printMatricola
<function printMatricola at 0x0049CE30>
>>> type(impiegato)
<type 'instance'>
>>>
Questo è l'esempio di prima (compresi gli errori di digitazione :asd: ), ma eseguito dall'interprete di cui sopra (>>> è il prompt). ;)
Come vedi ho ispezionato anche l'istanza "impiegato" (la funzione dir restituisce l'insieme dei simboli / attributi presenti nell'oggetto).
^TiGeRShArK^
10-09-2007, 19:45
Letto, e allora mi sbagliato. Però è strano che la libreria thread sia disponibile soltanto su alcune piattaform: se fosse "nativa", dovrebbe poter girare su qualunque porting di Python.
Comunque la FAQ è piuttosto eloquente, per cui mi posso mettere l'anima in pace. :p
no, ma a quanto ho capito io i thread effettivamente sono implementati nativamente, ma essendo il global interpreter single thread alla fine può girare solo un thread per volta...
sempre se non ho capito male :p
e infatti in ironpython e in jyhton mi sa ke il global interpreter non ha questa limitazione :p
cdimauro
10-09-2007, 19:50
no, ma a quanto ho capito io i thread effettivamente sono implementati nativamente, ma essendo il global interpreter single thread alla fine può girare solo un thread per volta...
sempre se non ho capito male :p
e infatti in ironpython e in jyhton mi sa ke il global interpreter non ha questa limitazione :p
A quanto pare è così: è una limitazione dell'interprete (dunque dell'implementazione attuale) e non del linguaggio.
Questa è introspezione:
screenshot (http://www.tukano.it/squeak.png)
L'interprete da linea di comando è un divertissement.
^TiGeRShArK^
10-09-2007, 19:54
Questa è introspezione:
screenshot (http://www.tukano.it/squeak.png)
L'interprete da linea di comando è un divertissement.
appunto...:stordita:
e non lo fanno anke python e ruby? :mbe:
con il plugin per eclipse di ruby e python hai esattamente la stessa cosa :p(anzi è anke fatto meglio... è davvero odioso secondo me squeak :asd: )
cdimauro
10-09-2007, 19:58
Mi sa che riusciamo a convertirlo a Python e/o Ruby. :p
Se dovessi usare un linguaggio amorfo userei Smalltalk. E' come essere di fronte ad una scelta tra la cacca e l'oro. E che mi ruga lasciare a Cincom il 20% dei miei introiti. :D.
Ps: python e ruby lo fanno? Dov'è che lo fanno? Perchè io qui ho sia Ruby che Python e ti assicuro che ho due mozziconi di piattaforma.
Comunque devo dire che 'sto ruby quasi quasi... ha una bella documentazione.
http://poignantguide.net/ruby/
In assoluto la guida ad un linguaggio piu' "alternativa" che si potesse immaginare :D.
Constants are words like variables, but constants are capitalized. If variables are the nouns of Ruby, then think of constants as the proper nouns.
Time, Array or Bunny_Lake_is_Missing are examples.
In English, proper nouns are capitalized. The Empire State Building. You can’t just move The Empire State Building. You can’t just decide that the Empire State Building is something else. Proper nouns are like that. They refer to something very specific and usually don’t change over time.
:rotfl:
Ps: python e ruby lo fanno? Dov'è che lo fanno? Perchè io qui ho sia Ruby che Python e ti assicuro che ho due mozziconi di piattaforma.
siamo a tutt' altro livello in effetti. E il "grave" e' che quando ti abitui a piattaforme cosi' "immersive" le rimpiangi quando torni ai linguaggi tradizionali. Qualcosa di simile lo si puo' trovare in ambiente lisp (e non a caso mentre "il resto del mondo" parla di files loro parlano di immagini), anche se ci sono altre differenze profonde che li distinguono.
In realta' gli "strumenti" in python (e probabilmente pure in ruby) ci sono, basta qualche accorgimento. Il problema principale e' che non c'e' interesse perche' tipicamente chi sviluppa in python ha un'altra mentalita'. Senza contare che ruby e python hanno delle VM relativamente lente (soprattutto ruby).
Si potrebbe comunque provare :eek: :D.
Sapessi quante volte ho pensato di usare Squeak "davvero". Ma come diamine faccio a presentare a un cliente una cosa così:
http://www.tukano.it/vabbe.png
C'è la faccia di un topo a sinistra, i fumetti, le stelline... Almeno il topone potrebbero toglierlo...
Sapessi quante volte ho pensato di usare Squeak "davvero". Ma come diamine faccio a presentare a un cliente una cosa così:
http://www.tukano.it/vabbe.png
C'è la faccia di un topo a sinistra, i fumetti, le stelline... Almeno il topone potrebbero toglierlo...
Fosse una topona il cliente ancora ancora potresti convincerlo :asd:
cdimauro
10-09-2007, 20:45
Scusate, ma io vorrei capire la differenza fra l'inspecting di Squeak/SmallTalk e quello di Python (e Ruby, che però non conosco).
A parte questo, PGI come fai a parlare di oro e cacca paragonando un linguaggio basato strettamente sull'ereditarietà singola con uno dotato di ereditarietà multipla (e altro :D)? Non regge proprio. ;)
P.S. Quella su Cincom non l'ho capita. :p
La differenza tra l'inspecting di Smalltalk e quello di Python e Ruby e Java eccetera.
Prendi Python, Ruby e Java e scrivi nella loro piattaforma la stringa pippo. Ora Java lo tagliamo fuori perchè non ha un ambiente. Ruby e Python hanno almeno l'interprete. Bene, scrivi la stringa pippo.
E adesso cliccaci sopra.
Cincom sta dietro a VisualWorks. Che è la piattaforma Smalltalk per antonomasia. E' una meraviglia. Solo che ha un businness model alla Bela Lugosi. Per applicazioni commerciali, oltre a pagare la piattaforma che di per sè non è neanche tanto (500$ l'anno) si pappano una percentuale di quanto incassi col software. E non parliamo dello zero virgola minchia: è il 6%.
cdimauro
10-09-2007, 21:06
La differenza tra l'inspecting di Smalltalk e quello di Python e Ruby e Java eccetera.
Prendi Python, Ruby e Java e scrivi nella loro piattaforma la stringa pippo. Ora Java lo tagliamo fuori perchè non ha un ambiente. Ruby e Python hanno almeno l'interprete. Bene, scrivi la stringa pippo.
E adesso cliccaci sopra.
E' una questione di IDE allora. Tutto qui? Io mi riferivo al linguaggio. ;)
cdimauro
10-09-2007, 21:08
Cincom sta dietro a VisualWorks. Che è la piattaforma Smalltalk per antonomasia. E' una meraviglia. Solo che ha un businness model alla Bela Lugosi. Per applicazioni commerciali, oltre a pagare la piattaforma che di per sè non è neanche tanto (500$ l'anno) si pappano una percentuale di quanto incassi col software. E non parliamo dello zero virgola minchia: è il 6%.
:eek: http://www.matematicamente.it/f/images/smiles/sticazzi.gif
Un business model da spavento, appunto. Serve come "incentivo" per la diffusione di Squeak? :asd:
^TiGeRShArK^
10-09-2007, 21:23
Cincom sta dietro a VisualWorks. Che è la piattaforma Smalltalk per antonomasia. E' una meraviglia. Solo che ha un businness model alla Bela Lugosi. Per applicazioni commerciali, oltre a pagare la piattaforma che di per sè non è neanche tanto (500$ l'anno) si pappano una percentuale di quanto incassi col software. E non parliamo dello zero virgola minchia: è il 6%.
ah..
pensavo ke bela lugosi era la distorsione di qualke nome di stella tipo Bela Tegeuse in non mi ricordo quale romanzo di sci-fi :mbe:
meno male ke c'è wikipedia :asd:
Non è una questione di IDE. La differenza è che non c'è uno Smalltalk senza IDE. Non è che uno prende e può mettersi a scrivere codice smalltalk su notepad. Esiste un formato di riferimento ma più una linea guida che altro. La ragione per cui non c'è è che l'ambiente Smalltalk integra le caratteristiche del linguaggio smalltalk.
Potrebbe esserci un ambiente Python. Ma non c'è. Potrebbe esserci un ambiente Ruby. Ma non c'è.
Cincom vende VisualWorks. Squeak è gratuito ma ha quella faccia...
Hey, forse ho trovato un LookAndFeel migliore...
^TiGeRShArK^
10-09-2007, 21:31
Hey, forse ho trovato un LookAndFeel migliore...
ne hai finalmente trovato uno con la topa anzikè col topo? :asd:
No il ratto maledetto permane. Ora devo solo leggere un paio di kili di documentazione per sapere quale pulsante premere per installarlo... ehhh ma la documentazione non conta...
Una semplice procedura in 420 passi. Sarebbero 210 ma una è buggata e m'è toccata anche l'altra :D.
screenshot (http://www.tukano.it/coolsqueak.png)
forse ho scoperto da dove deriva l'odio di Linus per il C++.. si dice che il kernel per un breve periodo è stato compilato con g++ :eek:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
You are aware that the Linux kernel was kept compilable under g++ for
a while in its history? You'll need more than vague words to erase
the memories from that experiment...
If you want real high-level, pick one that has true high-level
features like garbage collection or a good system integration, rather than
something that lacks both the sparseness and straightforwardness of C,
*and* doesn't even have the high-level bindings to important concepts.
non sembra detto da lui ne?
^TiGeRShArK^
10-09-2007, 22:37
Una semplice procedura in 420 passi. Sarebbero 210 ma una è buggata e m'è toccata anche l'altra :D.
screenshot (http://www.tukano.it/coolsqueak.png)
ecco uno dei tanti motivi x cui odio smalltalk :asd:
A quanto pare è così: è una limitazione dell'interprete (dunque dell'implementazione attuale) e non del linguaggio.
http://feeds.dzone.com/~r/dzone/frontpage/~3/154594010/an_open_letter_to_guido_van_rossum_mr_rossum_tear.html
sembra un limite di guido :asd:
o meglio una sua visione dello sfruttare + thread.
^TiGeRShArK^
10-09-2007, 22:59
non sembra detto da lui ne?
:mbe:
milanese? :stordita:
:mbe:
milanese? :stordita:
no ma è contagioso :fagiano:
^TiGeRShArK^
10-09-2007, 23:09
no ma è contagioso :fagiano:
ora capisco ahò :O
:asd:
Francamente 'sta faccenda del GIL di CPython mi lascia un po' allibito. Non per il fatto che ci sia ma... è possibile che a Google non abbiano un marcovaldo da mettere lì a dare una mano a Rossum? Che cavolo se ne fanno di tutti i soldi che fanno?
io vi consiglio di leggere tutta la discussione comunque.. perchè sono entrati altri big come Walter Bright ;)
E' entrato e uscito perchè io 'sto bright non lo vedo. Chi fu? Cosa disse?
Francamente 'sta faccenda del GIL di CPython mi lascia un po' allibito. Non per il fatto che ci sia ma... è possibile che a Google non abbiano un marcovaldo da mettere lì a dare una mano a Rossum? Che cavolo se ne fanno di tutti i soldi che fanno?
l'attuale archietettura di google non ne risente molto, visto che hanno macchine con al max 2 cpu(o dual core o con hyperthreading), e lavorano più sul calcolo distribuito fra cluster.
In teoria ogni macchina ha la sua vm pyton(o nel caso del doppio core ne ha 2) che va per i fatti suoi.
poi attraverso map/reduce assegnano il lavoro su una partizione dei dati alle varie macchine.
Per cui l'attuale architettura rientra al meglio negli standard di gugol, evitando al programmatore noie sul multithreading a memoria condivisa con relativi deadlock, race condition sui dati e sui lock(o da quel che ho letto riducendole di molto)
il problema e che fuori da google, di sistemi simili non penso ne esistano molti...
cdimauro
11-09-2007, 07:21
forse ho scoperto da dove deriva l'odio di Linus per il C++.. si dice che il kernel per un breve periodo è stato compilato con g++ :eek:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
E questo cosa vuol dire? Nulla. Ignorante era e ignorante rimane in ambito C++.
non sembra detto da lui ne?
No, è chiaramente detto da lui: è un'altra minchiata.
cdimauro
11-09-2007, 07:23
http://feeds.dzone.com/~r/dzone/frontpage/~3/154594010/an_open_letter_to_guido_van_rossum_mr_rossum_tear.html
sembra un limite di guido :asd:
o meglio una sua visione dello sfruttare + thread.
Ed è una visione che non mi piace. Se a lui non piace non vedo perché non deve dare la possibilità agli altri di poter usare Python come meglio credono. Anche perché qui non si tratta di andare a modificare il linguaggio, ma la sua implementazione. :rolleyes:
cdimauro
11-09-2007, 07:24
io vi consiglio di leggere tutta la discussione comunque.. perchè sono entrati altri big come Walter Bright ;)
Ne ho letto una buona parte e m'è bastato già quello che ha scritto Torvalds e alcuni suoi amici.
Ripeto: prima di parlare bisognerebbe conoscerlo bene il C++, altrimenti è meglio starsene zitti onde evitare figuracce come quella.
cdimauro
11-09-2007, 07:26
l'attuale archietettura di google non ne risente molto, visto che hanno macchine con al max 2 cpu(o dual core o con hyperthreading), e lavorano più sul calcolo distribuito fra cluster.
In teoria ogni macchina ha la sua vm pyton(o nel caso del doppio core ne ha 2) che va per i fatti suoi.
poi attraverso map/reduce assegnano il lavoro su una partizione dei dati alle varie macchine.
Per cui l'attuale architettura rientra al meglio negli standard di gugol, evitando al programmatore noie sul multithreading a memoria condivisa con relativi deadlock, race condition sui dati e sui lock(o da quel che ho letto riducendole di molto)
il problema e che fuori da google, di sistemi simili non penso ne esistano molti...
Già, e infatti non esiste soltanto Google: bisogna dare la possibilità anche ad altri che non hanno le stesse infrastrutture di poter sfruttare Python su sistemi multiprocessore e/o multithread.
Già, e infatti non esiste soltanto Google: bisogna dare la possibilità anche ad altri che non hanno le stesse infrastrutture di poter sfruttare Python su sistemi multiprocessore e/o multithread.
Jyton
però sarà sempre indietro rispetto alle specifiche di guido..
^TiGeRShArK^
11-09-2007, 08:32
Jyton
però sarà sempre indietro rispetto alle specifiche di guido..
ed oltre ad essere indietro è cmq + lento come ironpython del resto, nonostante alcuni fantomatici test che lo volevano molto + veloce dell'interprete python nativo :fagiano:
Dimenticavo...
c'è anke il mitico pypy...
l'interprete python scritto in python ke è una chiavica in quanto a velocità.... :mbe:
ma immagino ke erediti anke lui il problema del GIL così ad occhio :p
cdimauro
11-09-2007, 08:33
Jyton
però sarà sempre indietro rispetto alle specifiche di guido..
Appunto, e poi io voglio lavorare in Python, senza altre VM in mezzo.
Ed è una visione che non mi piace. Se a lui non piace non vedo perché non deve dare la possibilità agli altri di poter usare Python come meglio credono. Anche perché qui non si tratta di andare a modificare il linguaggio, ma la sua implementazione. :rolleyes:
Infatti non è contrario in principio all'idea. Ma e' contrario se questo porta ad un decadimento di performance nei programmi single threaded. (Come era accaduto ad una prima implementazione di python GIL-less diversi anni fa).
http://www.artima.com/weblogs/viewpost.jsp?thread=214235
cdimauro
11-09-2007, 09:37
La soluzione giusta è quella che ha prospettato: un fork di Python in modo poter avere una versione single-thread e una multi-thread. Così ognuno sceglie quella che gli serve.
D'altra parte se prima c'erano soltanto sistemi dual core e le prestazioni di CPython multithread erano le stesse della versione single-thread, adesso che ci sono sistemi quad core, e il prossimo anno con 8 core, una versione di CPython multithread ha sicuramente la sua utilità.
ho paura non abbia abbastanza risorse per spingere il multithreading(aka lavorarci per avere delle perstazioni decenti).
la sun se l'è potuto permettere, e nelle ultime versioni i risultati sono stati ottimi(syncronize + leggere, un buon numero di collection per uso concorrente(di cui alcune nn usano lock), e delle api per creare thread, pool, bloccarli, etc etc.
(ps.ho appena finito di leggere concurrent in practice, lo consiglio a chiunque possa interessare il multithreading in generale e in particolare per JAVA)
E questo cosa vuol dire? Nulla. Ignorante era e ignorante rimane in ambito C++.
No, è chiaramente detto da lui: è un'altra minchiata.
non penso sia una michiata.. a mio modo di vedere C++ è più obsoleto di C.
perchè il C per quanto riguarda la programmazione procedurale è lo stato dell'arte, mentre C++ per quello che riguarda la programmazione a oggetti è poco più che spazzatura :fagiano:
ma forse senza gli errori del C++ i linguaggi successivi non sarebbero stati quello che sono
EDIT: pure Wincent Colaiuta (di fama da mela mangiucchiata) sostiene che il C è semplicemente la miglior scelta per quanto riguarda lo sviluppo di GIT
E' entrato e uscito perchè io 'sto bright non lo vedo. Chi fu? Cosa disse?
è il principale sviluppatore del primo compilatore C++ commerciale per windows. inoltre ha sviluppato anche compilatori C e ultimamente è impegnato nello sviluppo del linguaggio D
cdimauro
11-09-2007, 10:01
x thebol: le risorse ci sono, e infatti gente che c'ha lavorato c'è (e la comunità di sviluppatori Python è numerosa).
non penso sia una michiata.. a mio modo di vedere C++ è più obsoleto di C.
perchè il C per quanto riguarda la programmazione procedurale è lo stato dell'arte, mentre C++ per quello che riguarda la programmazione a oggetti è poco più che spazzatura :fagiano:
Non mi risulta che il C++ sia lo stato dell'arte nella programmazione procedurale: non ha nemmeno un elementare tipo stringa a disposizione.
Allo stesso modo, ben pochi linguaggi rispetto al C++ possono offrire l'ereditarietà multipla, le classe virtuali, le funzioni friend, ecc.
Tra l'altro, e lo ripeto, il C come linguaggio NON HA INTRODOTTO NESSUNA INNOVAZIONE nella letteratura informatica, tanto che veniva deriso e chiamato "Pascal mascherato".
ma forse senza gli errori del C++ i linguaggi successivi non sarebbero stati quello che sono
Questo vale per qualunque cosa: la storia (sulla carta) dovrebbe insegnare.
Comunque rimane il fatto che Torvalds abbia detto delle minchiate.
EDIT:
EDIT: pure Wincent Colaiuta (di fama da mela mangiucchiata) sostiene che il C è semplicemente la miglior scelta per quanto riguarda lo sviluppo di GIT
Se non si fosse capito, dei titoli nobiliari di chi esprime giudizi non me ne frega proprio niente. Preferisco leggere le argomentazioni a sostegno delle proprie tesi e valutarle.
Nel caso di GIT, dovrei anche dare un'occhiata ai sorgenti per capire quali costrutti si potrebbero usare.
Non mi risulta che il C sia lo stato dell'arte nella programmazione procedurale: non ha nemmeno un elementare tipo stringa a disposizione.
forse volevi dire C ;)
il concetto di stringa si addice di più ai linguaggi OO, comunque usare char* non è poi così difficile (anche e soprattutto grazie a string.h)
Allo stesso modo, ben pochi linguaggi rispetto al C++ possono offrire l'ereditarietà multipla, le classe virtuali, le funzioni friend, ecc.
- ereditarietà multipla:
e direi meno male che in pochi la offrono, perchè è una porcheria diventata obsoleta con l'introduzione delle interfacce
Multiple inheritance. It's a complex feature of debatable value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it. Nearly all the value of MI can be handled with single inheritance coupled with interfaces and aggregation. What's left does not justify the weight of MI implementation.
- classi virtuali:
quasi tutti i linguaggi OO hanno un meccanismo equivalente
- friend functions:
direi che il concetto di package (o module ecc..) rende obsoleto il concetto di friend function
Tra l'altro, e lo ripeto, il C come linguaggio NON HA INTRODOTTO NESSUNA INNOVAZIONE nella letteratura informatica, tanto che veniva deriso e chiamato "Pascal mascherato".
non c'è bisogno di introdurre chissà che cosa, ma indubbiamente è il linguaggio più maturo nel suo genere. se il PASCAL non ha avuto lo stesso successo del C c'è un motivo
cdimauro
11-09-2007, 10:37
forse volevi dire C ;)
Sì. Piccolo lapsus. :p
il concetto di stringa si addice di più ai linguaggi OO, comunque usare char* non è poi così difficile (anche e soprattutto grazie a string.h)
Il concetto di stringa esiste nei linguaggi procedurali dalla notte dei tempi, quando ancora di oggetti non se ne sentiva parlare.
Inoltre char* non è assolutamente la stessa cosa: è una porcata immane (e tra l'altro per poter conoscere la lunghezza della stringa è necessario scorrerla tutta, introducendo negli algoritmi che ne fanno uso un'altra variabile di cui tenere conto per il calcolo della complessità).
- ereditarietà multipla:
e direi meno male che in pochi la offrono, perchè è una porcheria diventata obsoleta con l'introduzione delle interfaccia
E' una porcheria per chi non sa come usarla.
Per il resto permette di fare le stesse cose del modello a interfacce, e anche di più.
- classi virtuali:
quasi tutti i linguaggi OO hanno un meccanismo equivalente
Più precisamente mi riferivo alle classi che sono dotate di attributi virtuali: quali linguaggi OO, oltre al C++, permettono di farlo?
- friend functions:
direi che il concetto di package (o module ecc..) rende obsoleto il concetto di friend function
Perché?
non c'è bisogno di introdurre chissà che cosa, ma indubbiamente è il linguaggio più maturo nel suo genere.
Talmente maturo da richiedere l'uso del PREPROCESSORE per poter definire delle semplici costanti. :rotfl:
E mi fermo qui che è meglio. :p
se il PASCAL non ha avuto lo stesso successo del C c'è un motivo
E' il classico esempio del prodotto peggiore che però ha più successo (in questo caso il successo del C è dovuto al fatto che è stato usato per sviluppare Unix).
Il concetto di stringa esiste nei linguaggi procedurali dalla notte dei tempi, quando ancora di oggetti non se ne sentiva parlare.
Inoltre char* non è assolutamente la stessa cosa: è una porcata immane (e tra l'altro per poter conoscere la lunghezza della stringa è necessario scorrerla tutta, introducendo negli algoritmi che ne fanno uso un'altra variabile di cui tenere conto per il calcolo della complessità).
si certo non intendevo dire che è un'esclusiva del mondo a oggetti.. ho detto solo che si addice particolarmente a quel mondo.
il C è un linguaggio che nasconde il meno possibile (vantaggio/svantaggio? dipende) e quindi se una stringa è un array di caratteri te lo fa vedere in quel modo.
ps. nessuno vieta di usare una variabile per tenere traccia della lunghezza della stringa in modo da diminuire la complessità (che comunque sia è lineare e quindi non rappresenta un problema nel 99% dei casi)
E' una porcheria per chi non sa come usarla.
Per il resto permette di fare le stesse cose del modello a interfacce, e anche di più.
che è una porcheria è un'opinione diffusa. comunque cosa ti manca dell'ereditarietà multipla quando programmi in java ad esempio?
Più precisamente mi riferivo alle classi che sono dotate di attributi virtuali: quali linguaggi OO, oltre al C++, permettono di farlo?
e a cosa serve :fagiano: (oltre a complicare ulteriormente qualcosa di già eccessivamente complesso)
Perché?
perchè se una classe ha bisogno dei metodi privati di un'altra classe significa che appartiene a un componente di più alto livello rispetto alla singola classe... un modulo appunto
questo elimina totalmente il problema delle friend function perchè si può rendere i metodi pubblici solo all'interno del modulo
Talmente maturo da richiedere l'uso del PREPROCESSORE per poter definire delle semplici costanti. :rotfl:
perchè il C++ non ha il preprocessore?
E mi fermo qui che è meglio. :p
E' il classico esempio del prodotto peggiore che però ha più successo (in questo caso il successo del C è dovuto al fatto che è stato usato per sviluppare Unix).
e quale linguaggio avrebbero dovuto usare invece? e perchè?
cdimauro
11-09-2007, 11:41
si certo non intendevo dire che è un'esclusiva del mondo a oggetti.. ho detto solo che si addice particolarmente a quel mondo.
il C è un linguaggio che nasconde il meno possibile (vantaggio/svantaggio? dipende) e quindi se una stringa è un array di caratteri te lo fa vedere in quel modo.
Non è soltanto questo: è che mancano del tutto dei costrutti sintattici per manipolare le stringhe senza ricorrere ogni volta alle librerie di sistema. Anche un banale confronto richiede una chiamata a strcmp.
ps. nessuno vieta di usare una variabile per tenere traccia della lunghezza della stringa in modo da diminuire la complessità (che comunque sia è lineare e quindi non rappresenta un problema nel 99% dei casi)
E' una complessità lineare che si va ad aggiungere e/o moltiplicare: non è cosa da poco.
che è una porcheria è un'opinione diffusa.
L'opinione diffusa riguarda soltanto l'eventuale difficoltà nel conoscere a quale attributo e/o membro ci si sta riferendo nel caso in cui più classi da cui si sta ereditando ne presentino con lo stesso nome.
Fermo restando che l'algoritmo di "ricerca" è ben noto e fissato, per cui è sempre possibile sapere esattamente a quale classe ci si sta riferendo.
comunque cosa ti manca dell'ereditarietà multipla quando programmi in java ad esempio?
La possibilità di avere a disposizione variabili d'istanza e/o classe direttamente nell'interfaccia: in Java (e in tutti linguaggi che usano quest'approccio) è richiesto il passaggio di parametri e che la classe che la implementa si faccia carico della definizione di tutto ciò che serve.
e a cosa serve :fagiano: (oltre a complicare ulteriormente qualcosa di già eccessivamente complesso)
A non duplicare risorse quando si eredita da classi che hanno discendenti comuni, perché viene conservata una sola copia di quelle informazioni.
perchè se una classe ha bisogno dei metodi privati di un'altra classe significa che appartiene a un componente di più alto livello rispetto alla singola classe... un modulo appunto
questo elimina totalmente il problema delle friend function perchè si può rendere i metodi pubblici solo all'interno del modulo
E' una buona soluzione, ma richiede appunto che a un linguaggio venga aggiunto il concetto di modulo / package.
Personalmente la trovo una buona cosa: la programmazione modulare m'è sempre piaciuta.
perchè il C++ non ha il preprocessore?
Sì, ma può anche definire delle costanti. Infatti continuare a usare il preprocessore anche per queste cose è sconsigliato.
Comunque si stava parlando dei linguaggi dell'epoca, e il C++ non era ancora nato.
e quale linguaggio avrebbero dovuto usare invece? e perchè?
In Pascal ad esempio. :p Ma anche il Simula sarebbe stato molto interessante.
Comunque qui http://en.wikipedia.org/wiki/Timeline_of_programming_languages ho trovato una lista dei linguaggi di programmazione ordinata per anno di introduzione. C'è l'imbarazzo della scelta. :p
Perché? Perché sono linguaggi che hanno dei costrutti a più alto livello, e una tipizzazione più forte che evita l'introduzione di bug subdoli (vedi ad esempio la scanf del C).
Ad esempio una delle cose che ho sempre adorato del Pascal è il costrutto with. ;)
Per l'amor del cielo non mi toccate l'interfaccia Java che vi taglio le zampine. E' ereditarietà multipla, versione scandinava, vedere Dahl per credere. Quella di C++ è pure ereditarietà multipla, versione americana, altrimenti nota come estensione (multipla). Sono due cose diverse. Una è più coerente, l'altra più pratica.
Il massimo dell'astrazione che puoi concedere ad un linguaggio procedurale è la variabile. C, da questo punto di vista, è forse di un livello fin troppo alto. Ritchie ha creato il suo linguaggio per sviluppare il suo sistema operativo. Evidentemente con Pascal non si trovava bene.
Non è soltanto questo: è che mancano del tutto dei costrutti sintattici per manipolare le stringhe senza ricorrere ogni volta alle librerie di sistema. Anche un banale confronto richiede una chiamata a strcmp.
questo perchè le stringhe sono array di char e quindi hai a disposizione solo i costrutti per manipolare gli array e i char. il confronto tra due stringhe comunque non vedo come possa essere implementato in maniera diversa (intendo che vanno pur sempre confrontati tutti i caratteri contenuti nella stringa)
E' una complessità lineare che si va ad aggiungere e/o moltiplicare: non è cosa da poco.
di solito si va a aggiungere, comunque se è necessario si usa una variabile locale. è un tipico problema di ottimizzazione, penso che è l'ultima cosa a cui pensare. se pensi a come sono implementate le stringhe nei linguaggi a oggetti vedi che oltre ai benefici ci sono anche alcune controindicazioni (la prima è che occupano più memoria di quanto dovrebbero)
L'opinione diffusa riguarda soltanto l'eventuale difficoltà nel conoscere a quale attributo e/o membro ci si sta riferendo nel caso in cui più classi da cui si sta ereditando ne presentino con lo stesso nome.
Fermo restando che l'algoritmo di "ricerca" è ben noto e fissato, per cui è sempre possibile sapere esattamente a quale classe ci si sta riferendo.
il problema dell'ereditarietà multipla è che introduce più problemi di quanti ne risolve. per prima cosa aumenta di molto la complessità del compilatore, inoltre rende più difficile capire il codice e per finire presenta numerosi problemi legati alla semantica.
in tutto questo usare le interfaccie è sempre più elegante
La possibilità di avere a disposizione variabili d'istanza e/o classe direttamente nell'interfaccia: in Java (e in tutti linguaggi che usano quest'approccio) è richiesto il passaggio di parametri e che la classe che la implementa si faccia carico della definizione di tutto ciò che serve.
scusa.. non ho capito perfettamente cosa intendi. è qualcosa che non si può ottenere con una classe astratta in java?
inoltre è buona cosa non esporre direttamente i campi di un oggetto, ma passare attraverso un metodo (e questo ha molto a che vedere con il galateo della programmazione OO)
A non duplicare risorse quando si eredita da classi che hanno discendenti comuni, perché viene conservata una sola copia di quelle informazioni.
mi sembra un problema a cui dovrebbe pensare il compilatore e non il programmatore
E' una buona soluzione, ma richiede appunto che a un linguaggio venga aggiunto il concetto di modulo / package.
Personalmente la trovo una buona cosa: la programmazione modulare m'è sempre piaciuta.
per questo il C++ è obsoleto come linguaggio OO
Sì, ma può anche definire delle costanti. Infatti continuare a usare il preprocessore anche per queste cose è sconsigliato.
Comunque si stava parlando dei linguaggi dell'epoca, e il C++ non era ancora nato.
tra consigliare e impedire c'è una bella differenza.. il fatto che nonostante sia un linguaggio nettamente più giovane del C abbia mantenuto il preprocessore lo trovo aggravante comunque :p
In Pascal ad esempio. :p Ma anche il Simula sarebbe stato molto interessante.
Comunque qui http://en.wikipedia.org/wiki/Timeline_of_programming_languages ho trovato una lista dei linguaggi di programmazione ordinata per anno di introduzione. C'è l'imbarazzo della scelta. :p
Perché? Perché sono linguaggi che hanno dei costrutti a più alto livello, e una tipizzazione più forte che evita l'introduzione di bug subdoli (vedi ad esempio la scanf del C).
Ad esempio una delle cose che ho sempre adorato del Pascal è il costrutto with. ;)
nessuno di questi è stato ideato pensando alla programmazione di sistema.
il C era il linguaggio migliore per quel compito all'epoca (oggi i paragoni sono molto più difficili da fare)
cdimauro
11-09-2007, 12:33
Per l'amor del cielo non mi toccate l'interfaccia Java che vi taglio le zampine.
OK OK: cedo alla violenza. :p
E' ereditarietà multipla, versione scandinava, vedere Dahl per credere. Quella di C++ è pure ereditarietà multipla, versione americana, altrimenti nota come estensione (multipla). Sono due cose diverse. Una è più coerente, l'altra più pratica.
Dahl = Simula per caso?
Comunque non mi trovo male con l'ereditarietà multipla. Specialmente con Python.
Il massimo dell'astrazione che puoi concedere ad un linguaggio procedurale è la variabile. C, da questo punto di vista, è forse di un livello fin troppo alto. Ritchie ha creato il suo linguaggio per sviluppare il suo sistema operativo. Evidentemente con Pascal non si trovava bene.
Alla fine è sempre una questione di gusti, infatti, altrimenti useremmo tutti lo stesso linguaggio. :p
Comunque ci sono tanti s.o. realizzati in Pascal, per cui la fattibilità è provata. Ergo: dev'essere proprio una questione di gusti. ;)
Comunque ci sono tanti s.o. realizzati in Pascal, per cui la fattibilità è provata. Ergo: dev'essere proprio una questione di gusti. ;)
pascal è stato creato come linguaggio didattico, mentre C come linguaggio per la programmazione di sistema, quindi sono propenso a pensare che sia più una questione di usare gli strumenti adatti allo scopo.
certamente è anche possibile fare un sistema operativo in whitespace, ma penso che è chiaro che in questo caso non è questione di gusti :D
Parlerei di intenzione che di scopo. Cioè chi fa fa con un'intenzione. Per un progettista di linguaggi si tratta di didattica, scrittura di un sistema operativo, "embedding" e quant'altro. Il linguaggio tuttavia raramente ha una destinazione di scopo, nel senso di risultare idoneo esclusivamente a. Meccanicamente idoneo. Che poi sia qualitativamente preferibile è un altro discorso.
cdimauro
11-09-2007, 13:35
questo perchè le stringhe sono array di char e quindi hai a disposizione solo i costrutti per manipolare gli array e i char. il confronto tra due stringhe comunque non vedo come possa essere implementato in maniera diversa (intendo che vanno pur sempre confrontati tutti i caratteri contenuti nella stringa)
Non mi sono spiegato bene. Io intendo roba così:
if 'Pippo' <> 'Pluto' then Writeln('Pippo è diverso da Pluto!');
Dove viene effettuata la comparazione? ;)
di solito si va a aggiungere,
Dipende dall'algoritmo.
Esempio: ho un array di stringhe e devo trovare quella di lunghezza massima.
Tempo per scorrere l'array = O(n) con n = numero di elementi dell'array.
Tempo per controllare la lunghezza di una stringa = O(m) con m = lunghezza della stringa.
La complessità risultante NON è O(n + m), ma ovviamente O(n * m).
comunque se è necessario si usa una variabile locale.
Dipende sempre dal problema: non sempre puoi farlo (nel senso che non è vantaggioso farlo A POSTERIORI).
è un tipico problema di ottimizzazione, penso che è l'ultima cosa a cui pensare.
Ancora una volta, dipende dal problema.
se pensi a come sono implementate le stringhe nei linguaggi a oggetti vedi che oltre ai benefici ci sono anche alcune controindicazioni (la prima è che occupano più memoria di quanto dovrebbero)
Mi sembra normale, ma nell'uso comune i vantaggi sono sempre maggiori (altrimenti non avrebbe senso usarle).
il problema dell'ereditarietà multipla è che introduce più problemi di quanti ne risolve. per prima cosa aumenta di molto la complessità del compilatore,
Questo non mi riguarda.
inoltre rende più difficile capire il codice
Dipende da come sono state strutturate le classi.
e per finire presenta numerosi problemi legati alla semantica.
Non ce ne sono: l'interpretazione è sempre univoca.
in tutto questo usare le interfaccie è sempre più elegante
Ancora una volta dipende dal problema.
Comunque per la mia esperienza normalmente sono più comode.
scusa.. non ho capito perfettamente cosa intendi. è qualcosa che non si può ottenere con una classe astratta in java?
Assolutamente no (altrimenti PGI-Bis sarebbe già intervenuto per risponderti :D).
inoltre è buona cosa non esporre direttamente i campi di un oggetto, ma passare attraverso un metodo (e questo ha molto a che vedere con il galateo della programmazione OO)
Questo è un altro discorso, e in generale ai metodi preferisco le proprietà: rendono il codice molto più leggibile.
mi sembra un problema a cui dovrebbe pensare il compilatore e non il programmatore
Ci pensano entrambi: il programma nel riconoscere la duplicazione e usare la keyword virtual quando si specificano le classi da cui ereditare, e il compilatore per fare il lavoro sporco. :D
per questo il C++ è obsoleto come linguaggio OO
Ti risulta che C# abbia i moduli / package? Eppure è uno dei più giovani linguaggi OOP. Quindi anche lui è obsoleto.
tra consigliare e impedire c'è una bella differenza..
Indubbiamente. E' come quando si usa un compilatore C++ con sorgenti che hanno codice C (quindi non usando le funzionalità aggiuntive del C++).
il fatto che nonostante sia un linguaggio nettamente più giovane del C abbia mantenuto il preprocessore lo trovo aggravante comunque :p
Serve per garantire una maggiore compatibilità e perché, non essendo modulare, non c'è altro modo per strutturare i file di un progetto.
nessuno di questi è stato ideato pensando alla programmazione di sistema.
Su questo (e sull'altro mio messaggio) ha risposto PGI-bis.
il C era il linguaggio migliore per quel compito all'epoca (oggi i paragoni sono molto più difficili da fare)
Il C era stato scritto su misura per Unix: per questo era migliore.
Sul fatto che fosse migliore in assoluto all'epoca non sono assolutamente d'accordo.
Non mi sono spiegato bene. Io intendo roba così:
if 'Pippo' <> 'Pluto' then Writeln('Pippo è diverso da Pluto!');
Dove viene effettuata la comparazione? ;)
io non credo nella magia :p
nel senso.. che si scriva a <> b o strcmp(a, b) non vedo cosa cambia in pratica. si tratta sempre di comparare tutte le lettere della stringa
Dipende dall'algoritmo.
Esempio: ho un array di stringhe e devo trovare quella di lunghezza massima.
Tempo per scorrere l'array = O(n) con n = numero di elementi dell'array.
Tempo per controllare la lunghezza di una stringa = O(m) con m = lunghezza della stringa.
La complessità risultante NON è O(n + m), ma ovviamente O(n * m).
se avessi pensato che non dipendeva dall'algoritmo avrei detto: "si aggiunge sempre" e invece ho detto di solito :)
la complessità si può ridurre usando una variabile per memorizzare la lunghezza della stringa
Dipende sempre dal problema: non sempre puoi farlo (nel senso che non è vantaggioso farlo A POSTERIORI).
Ancora una volta, dipende dal problema.
in che senso non si può fare sempre.. poi è solamente un problema di ottimizzazione e non di funzionalità (e questa volta intendo proprio sempre)
Mi sembra normale, ma nell'uso comune i vantaggi sono sempre maggiori (altrimenti non avrebbe senso usarle).
nella programmazione di sistema no però, bisogna valutare di volta in volta.
io sono il primo a preferire i più moderni linguaggi OO, ma semplicemente penso che in alcuni casi (molto specifici) non convengono
Questo non mi riguarda.
potrebbe riguardarti quando il compilatore ha un bug o ci mette 10 anni a compilare un hello world :asd:
Dipende da come sono state strutturate le classi.
le interfaccie sono nettamente più leggibili e meno complicate da gestire
Non ce ne sono: l'interpretazione è sempre univoca.
l'interpretazione è univoca, ma complessa
Ancora una volta dipende dal problema.
Comunque per la mia esperienza normalmente sono più comode.
qui è possibile che sia questione di gusti
Assolutamente no (altrimenti PGI-Bis sarebbe già intervenuto per risponderti :D).
ciò non toglie che non ho capito quello che volevi dire :fagiano: non puoi fare un esempio?
Questo è un altro discorso, e in generale ai metodi preferisco le proprietà: rendono il codice molto più leggibile.
il fatto che sia più leggibile è questione di gusti, mentre il fatto che porta spesso a commettere errori è un dato di fatto
a meno che il linguaggio non supporti le proprietà in maniera sicura (come C# anche se secondo me la leggibilità se ne va a donne di facili costumi)
Ci pensano entrambi: il programma nel riconoscere la duplicazione e usare la keyword virtual quando si specificano le classi da cui ereditare, e il compilatore per fare il lavoro sporco. :D
non vedo perchè il programmatore dovrebbe interessarsi di una roba simile.. il compilatore del D ad esempio lo fa in automatico
Ti risulta che C# abbia i moduli / package? Eppure è uno dei più giovani linguaggi OOP. Quindi anche lui è obsoleto.
questo insieme al fatto che non esistono le eccezioni checked e tante altre cose mi fanno preferire di gran lunga java a C#
Indubbiamente. E' come quando si usa un compilatore C++ con sorgenti che hanno codice C (quindi non usando le funzionalità aggiuntive del C++).
Serve per garantire una maggiore compatibilità e perché, non essendo modulare, non c'è altro modo per strutturare i file di un progetto.
capisco che è per problemi di compatibilità, però è comunque un punto a sfavore oggi che ci sono molti linguaggi con questa caratteristica
Su questo (e sull'altro mio messaggio) ha risposto PGI-bis.
Il C era stato scritto su misura per Unix: per questo era migliore.
Sul fatto che fosse migliore in assoluto all'epoca non sono assolutamente d'accordo.
condivido la precisazione di PGI ma non cambia il senso del discorso in sostanza :D
anche qui si va un pò sul soggettivo eh
Sentite un po', non potreste evitare di quotarvi frase per frase e scrivere una risposta unica? No perchè a me qui va insieme la vista :D. Ho visto un PGI-Bis che dovrebbe fare ho dire qualcosa ma sinceramente non riesco proprio a trovare il punto della chiamata in causa.
cdimauro
11-09-2007, 14:44
Al momento non ho tempo per rispondere, ma il punto in questione è questo: http://www.wmlscript.it/cpp/page10b.php ;)
Comunque l'istanza sollevata la accolgo senza problemi: cercherò di dare una rispostona al messaggio, senza quotare ogni singolo punto. :p
@PGI-Bis
e non hai tutti i torti anche te :D
Sentite un po', non potreste evitare di quotarvi frase per frase e scrivere una risposta unica? No perchè a me qui va insieme la vista :D. Ho visto un PGI-Bis che dovrebbe fare ho dire qualcosa ma sinceramente non riesco proprio a trovare il punto della chiamata in causa.
:O Non sono chiamato in causa, ma non ci sto capendo una mazza lo stesso. :O
Anche io ho smesso di capirci qualcosa da un bel po' :D
^TiGeRShArK^
11-09-2007, 19:06
ho paura non abbia abbastanza risorse per spingere il multithreading(aka lavorarci per avere delle perstazioni decenti).
la sun se l'è potuto permettere, e nelle ultime versioni i risultati sono stati ottimi(syncronize + leggere, un buon numero di collection per uso concorrente(di cui alcune nn usano lock), e delle api per creare thread, pool, bloccarli, etc etc.
(ps.ho appena finito di leggere concurrent in practice, lo consiglio a chiunque possa interessare il multithreading in generale e in particolare per JAVA)
tnx for the info :D
vedo se trovo qualcosa online (:fiufiu: ) xkè x ora sto spendendo un pò troppi soldi a libri... e devo pur mangiare ogni tanto :D
^TiGeRShArK^
11-09-2007, 19:18
Per il resto permette di fare le stesse cose del modello a interfacce, e anche di più.
l'ereditarietà multipla conduce ad un bad design :O
è uno dei postulati principali :asd:
cdimauro
11-09-2007, 19:31
io non credo nella magia :p
nel senso.. che si scriva a <> b o strcmp(a, b) non vedo cosa cambia in pratica. si tratta sempre di comparare tutte le lettere della stringa
se avessi pensato che non dipendeva dall'algoritmo avrei detto: "si aggiunge sempre" e invece ho detto di solito :)
la complessità si può ridurre usando una variabile per memorizzare la lunghezza della stringa
in che senso non si può fare sempre.. poi è solamente un problema di ottimizzazione e non di funzionalità (e questa volta intendo proprio sempre)
nella programmazione di sistema no però, bisogna valutare di volta in volta.
io sono il primo a preferire i più moderni linguaggi OO, ma semplicemente penso che in alcuni casi (molto specifici) non convengono
potrebbe riguardarti quando il compilatore ha un bug o ci mette 10 anni a compilare un hello world :asd:
le interfaccie sono nettamente più leggibili e meno complicate da gestire
l'interpretazione è univoca, ma complessa
qui è possibile che sia questione di gusti
ciò non toglie che non ho capito quello che volevi dire :fagiano: non puoi fare un esempio?
il fatto che sia più leggibile è questione di gusti, mentre il fatto che porta spesso a commettere errori è un dato di fatto
a meno che il linguaggio non supporti le proprietà in maniera sicura (come C# anche se secondo me la leggibilità se ne va a donne di facili costumi)
non vedo perchè il programmatore dovrebbe interessarsi di una roba simile.. il compilatore del D ad esempio lo fa in automatico
questo insieme al fatto che non esistono le eccezioni checked e tante altre cose mi fanno preferire di gran lunga java a C#
capisco che è per problemi di compatibilità, però è comunque un punto a sfavore oggi che ci sono molti linguaggi con questa caratteristica
condivido la precisazione di PGI ma non cambia il senso del discorso in sostanza :D
anche qui si va un pò sul soggettivo eh
Postone unico e rispostone unico, saltando un po' di cose che si trascinano da tempo e sui è inutile dilungarci.
Al C mancano dei costrutti di più alto livello (stringhe, definizione di costanti, ecc.) che sono presenti in altri linguaggi procedurali (non necessariamente OOP, come affermavi) e che permettono di semplificare la vita a chi sviluppa.
Questo NON è un discorso soggettivo, ma oggettivo: se mancano, mancano, e c'è poco da fare.
Il C++ offre un modello di programmazione a oggetti che può non piacere (e qui è un discorso soggettivo; ad esempio a me piace l'ereditarietà multipla, ma NON la sintassi del C++), ma è molto espressivo / versatile (copre parecchi casi: vedi ad esempio quello delle classi basi virtuali di cui ho postato un link), nonché ben definita e consistente.
Inoltre non impedisce a nessuno di usare le classi esattamente come si farebbe con le interfacce; infatti la programmazione tramite interfacce è un caso particolare dell'ereditarietà multipla (e questo è banale da capire: le interfacce in C++ altro non sarebbero che classi dotate esclusivamente di metodi virtuali e astratti).
Sulle classi base virtuali è bene precisare che rappresentano una precisa scelta dello sviluppatore; in questo la filosofia del C++ è ben chiara: è il programmatore che sa quello che fa, e il compilatore non prende iniziative (come potrebbe fare il compilatore D), anche perché potrebbe NON essere desiderabile l'iniziativa.
Al C++, come a tanti linguaggi, mancano moduli e/o package; personalmente è un GROSSA mancanza, e infatti bisogna ricorrere al preprocessore (indispensabile anche in ottica della compatibilità col passato). In questo caso è da biasimare tanto quanto il C.
Quanto alle proprietà al posto dei metodi, sono sicure nella misura in cui come sviluppatore le uso in maniera appropriata, quindi con dei metodi getter e setter; le proprietà, infatti, servono a controllare l'accesso alle risorse, ma in maniera più semplice e leggibile.
Esempio (in Delphi):
TTavolo = class(TRunTimeDrawable)
private
FIDPiano: Integer;
FPosti: Integer;
procedure SetPosti(const Value: Integer);
public
property IDPiano: Integer read FIDPiano;
property Posti: Integer read FPosti write SetPosti;
end;
procedure TTavolo.SetPosti(const Value: Integer);
begin
if FPosti <> Value then begin
FPosti := Value;
SaveDatas;
end;
end;
In questo caso l'intento è chiaro:
- IDPiano è una proprietà accessibile a sola lettura; poiché a sola lettura mi posso permettere il lusso di farla leggere direttamente senza l'ausilio di un metodo getter;
- Posti è una proprietà accessibile anche in scrittura, ma in maniera controllata perché l'accesso è regolato sempre da un metodo setter (che si occupa, oltre a memorizzare il nuovo valore, a far scattare il metodo SaveDatas).
Semplice, lineare e di più facile lettura, perché anziché ricorrere a
Istanza.SetPosti(NuovoValore);
è sufficiente una
Istanza.Posti := NuovoValore;
;)
E' tutto.
cdimauro
11-09-2007, 19:32
l'ereditarietà multipla conduce ad un bad design :O
è uno dei postulati principali :asd:
Dipende sempre dal designer. ;)
Alt: come disse Dante Alighieri: cerchiamo di non farla fuori dal vaso. O era Toni 'O Animale? Non ricordo.
Anche ammesso che C++ abbia un modello, esso non è nè ben definito nè consistente. Indefinito per via del numero esorbitante di eccezioni al suo numero esorbitante di regole. E' come i cioccolatini di Forrest Gump: non sai mai quello che ti capita (ma puoi scommetterci che sa di m...).
Ed è assolutamente inconsistente. Tiene il piede in tre scarpe: oo, procedurale e funzionale. Nessuna della sua misura. Che sia orientato agli oggetti lo stabilì... Stroustrup. Lo scrisse all'ecoop: "what is object orientation". Capitò per caso che la definizione coincidesse esattamente con C++. Penso che ancora oggi sia l'unico a sostenerlo. C'è un subset di C++ che è appetibile per l'orientamento agli oggetti. Ma è talmente sub che dovremmo parlare di --------C++.
Dal punto di vista funzionale fa quello che fa C: siccome sono procedurale è tutto è un valore, anche le funzioni sono valori quindi posso usarle per le stesse operazioni elementari. Dunque sono funzionale. Non fa una grinza. Ne fa due.
E' certamente procedurale ma, in tutta sincerità, un linguaggio procedurale te lo scrive anche mio nipote che ha tre anni. Per la faccenda dei nani sulle spalle dei giganti: nell'anno del signore 2007 sappiamo tutto quanto hanno scoperto i pionieri dei due secoli passati. Il minimo è che oggi si sappiano fare le cose di ieri.
In conclusione, io penso che sia certamente preferibile l'abbozzo di orientamento agli oggetti rappresentato da C++ al perfetto proceduralese di C. Per una questione di espressività. Ma che, slegato da questo contesto, C++ sia da considerarsi come utile a qualcosa lo contesto con vigore.
Postone unico e rispostone unico, saltando un po' di cose che si trascinano da tempo e sui è inutile dilungarci.
Al C mancano dei costrutti di più alto livello (stringhe, definizione di costanti, ecc.) che sono presenti in altri linguaggi procedurali (non necessariamente OOP, come affermavi) e che permettono di semplificare la vita a chi sviluppa.
Questo NON è un discorso soggettivo, ma oggettivo: se mancano, mancano, e c'è poco da fare.
Peggio. Mancano gli strumenti per costruirseli. Questo almeno nel C++ e' stato fatto correttamente, e probabilmente meglio che in altri linguaggi che l'hanno seguito. Con questi strumenti poco importa se le stringhe sono tipi primitivi, in quanto le puoi implentare in modo che funzionino come se lo fossero.
Non fosse altro per una questione di omogeneita' : perche' confrontare un tipo in un modo e un altro in un altro ? Non e' solo questione estetica (che pur conta), ma anche un fatto pratico: nel momento in cui decido di astrarre e rendere la mia funzione piu' generica, come faccio ad implementare un algoritmo che funzioni bene per tutti i tipi se la stessa operazione ha nomi differenti ? Devo per forza passarla come argomento. Ora, se devo semplicemente ordinare una sequenza me la cavo anche con poco, ma quando i parametri diventano due, cinque, dieci, le cose si fanno alquanto fumose e forse si fa prima a reinventare la ruota :D (esercizio per il lettore: prendere l'esempio di programmazione generica fatta in C e preprocessore e implementare l'ordinamento l'ordinamento di una lista che funzioni con tipi predefiniti, stringhe "C" (char*) e future strutture dati :D).
Neanche col C++ sono rose e fiori, sia chiaro, perche' appena si accenna un gerarchia oppure un qualcosa che non stia sullo stack si comincia a parlare di puntatori, che con gli operatori ridefiniti non vanno molto d'accordo :p.
Ed è assolutamente inconsistente. Tiene il piede in tre scarpe: oo, procedurale e funzionale.
Difficile definire funzionale il C++. O meglio, lo e' nella misura in cui e' ad oggetti l'assembler e imperativo il prolog :D.
Mentre il linguaggio in se' supporta i primi due paradigmi (magari non quanto auspicabile, ma lo fa), l'aspetto funzionale e' dato solo dalle librerie, che tra l'altro non fanno che fornire un minimo di "funzionalita'" (:p) tramite gli oggetti.
Non e' proprio la stessa cosa, anche perche' quando cominci ad usare adattatori e compagnia per sommare anche un semplice valore ad una sequenza, ti viene voglia di spegnere tutto e farlo con l'abaco :D.
Quando dicono che il C++ e' multiparadigma tendono ad includere anche quello funzionale, ma forse perche' altrimenti sarebbero solo due e, come ci insegnano i greci, c'e' una sostanziale differenza tra due e molti :D.
D'altra parte bisogna ammettere che fare un linguaggio veramente multiparadigma e' decisamenet un'impresa. Incredibilmente, l'unico che conosco che faccia abbastanza bene un po' tutto e' uno dei piu' vecchi, ed e' Lisp (CLOS c'ha pure i multimetodi :mbe: )
Che sia difficile definirlo funzionale devi scriverlo a Stroustrup. Per me non è manco OO, figurati.
^TiGeRShArK^
12-09-2007, 00:32
Sentite un po', non potreste evitare di quotarvi frase per frase e scrivere una risposta unica? No perchè a me qui va insieme la vista :D. Ho visto un PGI-Bis che dovrebbe fare ho dire qualcosa ma sinceramente non riesco proprio a trovare il punto della chiamata in causa.
:rotfl:
io ne vedevo 3 di PGI da qto mi si sono incrociati gli okki :asd:
^TiGeRShArK^
12-09-2007, 00:38
Dipende sempre dal designer. ;)
appunto..
tu non hai i miei colleghi evidentemente :asd:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.