Torvalds e C++

[tomminno]

Originariamente inviato da cdimauro

Ah, beh, se t'interessano le cose sporche allora alzo le mani! Il C è quel che fa per te.

Se invece t'interessa la programmazione di sistema (quindi anche a basso livello), c'è di meglio, ma già da tempo.

P.S. Porco!

Allora perchè non esiste DSP o micro a questo mondo senza il suo compilatore C mentre non esistono per altri linguaggi? Se ci fosse di meglio vista la rapidità di uscita di nuovi DSP a quest'ora avremmo il compilatore per il linguaggio Z.
Perchè il C è l'unico linguaggio usato per questi scopi? Evidentemente di meglio non c'è.

[PGI-Bis]

Che è sta cosa della pera? E' un coda di macchine, di pere, di ogni cosa... Noi dobbiamo tener presente che l'amorfismo è una qualità dal prezzo eccezionalmente elevato: ciò che in un linguaggio polimorfo è uso in un linguaggio amorfo diventa tentativo d'uso.

Come fai a sapere, in un linguaggio amorfo, se l'oggetto ciccio possiede o non possiede la caratteristica x? Lo presumi. In un linguaggio polimorfo quella presunzione diventa precondizione, espressa nel tipo del riferimento.

Il polimorfismo è una scomoda certezza. Io penso che le certezze in programmazione valgano oro.

[tomminno]

Originariamente inviato da PGI-Bis

Che è sta cosa della pera? E' un coda di macchine, di pere, di ogni cosa... Noi dobbiamo tener presente che l'amorfismo è una qualità dal prezzo eccezionalmente elevato: ciò che in un linguaggio polimorfo è uso in un linguaggio amorfo diventa tentativo d'uso.

Come fai a sapere, in un linguaggio amorfo, se l'oggetto ciccio possiede o non possiede la caratteristica x? Lo presumi. In un linguaggio polimorfo quella presunzione diventa precondizione, espressa nel tipo del riferimento.

Il polimorfismo è una scomoda certezza. Io penso che le certezze in programmazione valgano oro.

Infatti, ma si parlava di controlli che un linguaggio come il C non esegue consentendoti di fare le peggio porcate.
Un linguaggio amorfo non può ovviamente controllare se stai mettendo una pera in coda alle macchine, dovremmo quindi definire delle porcate i linguaggi amorfi per questo loro mancato controllo?
Evidentemente no.
In C# ad esempio si è sentito la necessità di introdurre il (non) tipo "var" per consentire di estendere le funzionalità del linguaggio. Evidentemente tipizzare troppo può risultare dannoso.

[Mixmar]

Originariamente inviato da PGI-Bis

Che è sta cosa della pera? E' un coda di macchine, di pere, di ogni cosa... Noi dobbiamo tener presente che l'amorfismo è una qualità dal prezzo eccezionalmente elevato: ciò che in un linguaggio polimorfo è uso in un linguaggio amorfo diventa tentativo d'uso.

Come fai a sapere, in un linguaggio amorfo, se l'oggetto ciccio possiede o non possiede la caratteristica x? Lo presumi. In un linguaggio polimorfo quella presunzione diventa precondizione, espressa nel tipo del riferimento.

Il polimorfismo è una scomoda certezza. Io penso che le certezze in programmazione valgano oro.

Scusate, adesso dirò una boiata ma, non sono stato molto attento alla discussione...

... ma allora è una sorta di "amorfismo" anche il fatto che nelle Collection di Java "ante-generics" non si conoscesse il tipo degli oggetti (che erano visti tutti come "Object")?

In effetti, anche in quel caso, il controllo si fa a runtime all'atto di popolamento della Collection: a posteriori, possiamo verificare solo se il tipo che arriva è esplicitamente quello con "instanceof" o costrutti simili. Che dovrebbe essere cattiva programmazione OO, in ogni caso.

Che dite?

[k0nt3]

Originariamente inviato da Mixmar

Che dite?

dico che quando è uscito java5 ho fatto un paio di salti di gioia mi ha risparmiato quella porcata delle liste di Object

[cdimauro]

Originariamente inviato da tomminno

Beh ma se il linguaggio non mi dice niente se faccio "codaVeicoli.push(pera)" perchè per lui pera può essere qualsiasi cosa... Magari in pera ci ho messo un auto che ha la forma di una pera, ma potrei averci messo un int o una pera appunto.

Originariamente inviato da PGI-Bis

Che è sta cosa della pera? E' un coda di macchine, di pere, di ogni cosa... Noi dobbiamo tener presente che l'amorfismo è una qualità dal prezzo eccezionalmente elevato: ciò che in un linguaggio polimorfo è uso in un linguaggio amorfo diventa tentativo d'uso.

Come fai a sapere, in un linguaggio amorfo, se l'oggetto ciccio possiede o non possiede la caratteristica x? Lo presumi. In un linguaggio polimorfo quella presunzione diventa precondizione, espressa nel tipo del riferimento.

Il polimorfismo è una scomoda certezza. Io penso che le certezze in programmazione valgano oro.

Originariamente inviato da tomminno

Infatti, ma si parlava di controlli che un linguaggio come il C non esegue consentendoti di fare le peggio porcate.
Un linguaggio amorfo non può ovviamente controllare se stai mettendo una pera in coda alle macchine, dovremmo quindi definire delle porcate i linguaggi amorfi per questo loro mancato controllo?
Evidentemente no.
In C# ad esempio si è sentito la necessità di introdurre il (non) tipo "var" per consentire di estendere le funzionalità del linguaggio. Evidentemente tipizzare troppo può risultare dannoso.

Originariamente inviato da Mixmar

Scusate, adesso dirò una boiata ma, non sono stato molto attento alla discussione...

... ma allora è una sorta di "amorfismo" anche il fatto che nelle Collection di Java "ante-generics" non si conoscesse il tipo degli oggetti (che erano visti tutti come "Object")?

In effetti, anche in quel caso, il controllo si fa a runtime all'atto di popolamento della Collection: a posteriori, possiamo verificare solo se il tipo che arriva è esplicitamente quello con "instanceof" o costrutti simili. Che dovrebbe essere cattiva programmazione OO, in ogni caso.

Che dite?

Semplice: poca coerenza. Da una parte le certezze sono oro, d'altra se ne vorrebbe fare a meno perché sono scomode.

Comunque in Python è possibile controllare il tipo dei dati che vengono utilizzati, e regolarsi di conseguenza. Se una funzione si aspetta un intero come parametro basta un isinstance(Parametro, int) e il gioco è fatto.

[cdimauro]

Originariamente inviato da tomminno

Allora perchè non esiste DSP o micro a questo mondo senza il suo compilatore C mentre non esistono per altri linguaggi? Se ci fosse di meglio vista la rapidità di uscita di nuovi DSP a quest'ora avremmo il compilatore per il linguaggio Z.
Perchè il C è l'unico linguaggio usato per questi scopi? Evidentemente di meglio non c'è.

Semplice: perché è il più diffuso per questo tipo di compiti, come il PHP lo è per il web, tanto per fare un altro esempio noto.

[PGI-Bis]

Il "morfismo" è l'identificabilità del tipo di un'espressione. Durante la compilazione, verrebbe da dire.

Una lingua è a-morfa se il tipo dell'espressione non è determinabile. Poli-morfo significa che le espressioni hanno uno o più tipi. Monoformo significa che le espressioni hanno tutte quante lo stesso tipo.

Un insieme di Object non è amorfismo: è un insieme di Object. Amorfo è un insieme di non si sa cosa. Nota che Object un'espressione di tipo Object in Java non è polimorfa: il typesystem di Java non è ricorsivo, in cima c'è Object e fine della storia.

E' polimorfo, ad esempio, un riferimento di tipo String. Ha due tipi: String e Object. E' polimorfo un riferimento di tipo Integer: ha tre tipi, Integer, Number, Object. E così via.

Devo ammettere che con l'arrivo di Java 5 ho faticato anche io a trattenere la mia gioia, di fronte alla possibilità di poter finalmente vedere dichiarazioni di questo genere:

class Ciccio<E, T extends Document & Comparable<? super String> & Map<? extends Comparable<Number>, ? extends Comparable<E>>>

[k0nt3]

Originariamente inviato da PGI-Bis

Devo ammettere che con l'arrivo di Java 5 ho faticato anche io a trattenere la mia gioia, di fronte alla possibilità di poter finalmente vedere dichiarazioni di questo genere:

class Ciccio<E, T extends Document & Comparable<? super String> & Map<? extends Comparable<Number>, ? extends Comparable<E>>>

hai ragione, ma a me bastava un:
List<String> list;

o proprio al limite un:
List<List<String>> list;

qualsiasi cosa più complicata di questa la ignoro

[PGI-Bis]

Noi dobbiamo guardare il male e commisurare ad esso la cura. Il male era:

(String)arrayList.get(index);

La cura consta di 50 pagine di teoria dei tipi, in parte eccepite dalla necessità di preservare l'interazione con codice non generico.

In Java 5 mi hanno detto che se ho il raffreddore posso curarmi togliendo la sicura alla granata che mi sono infilato in bocca.

[k0nt3]

il male era che se ti finiva una pera in coda al casello il compilatore non te lo diceva

[cdimauro]

Originariamente inviato da PGI-Bis

Il "morfismo" è l'identificabilità del tipo di un'espressione. Durante la compilazione, verrebbe da dire.

Una lingua è a-morfa se il tipo dell'espressione non è determinabile. Poli-morfo significa che le espressioni hanno uno o più tipi. Monoformo significa che le espressioni hanno tutte quante lo stesso tipo.

Un insieme di Object non è amorfismo: è un insieme di Object. Amorfo è un insieme di non si sa cosa. Nota che Object un'espressione di tipo Object in Java non è polimorfa: il typesystem di Java non è ricorsivo, in cima c'è Object e fine della storia.

E' polimorfo, ad esempio, un riferimento di tipo String. Ha due tipi: String e Object. E' polimorfo un riferimento di tipo Integer: ha tre tipi, Integer, Number, Object. E così via.

Piccola richiesta di delucidazione. In Python il tipo di un'espressione è determinabile, ma a runtime:

>>> a = 'Pippo'
>>> b = 2
>>> c = a * b
>>> c
'PippoPippo'
>>> type(c)
<type 'str'>
>>>

Quindi non sarebbe amorfo.

Non mi pare che l'identificabilità sia una condizione necessaria, per lo meno leggendo la tua prima frase.

Devo ammettere che con l'arrivo di Java 5 ho faticato anche io a trattenere la mia gioia, di fronte alla possibilità di poter finalmente vedere dichiarazioni di questo genere:

class Ciccio<E, T extends Document & Comparable<? super String> & Map<? extends Comparable<Number>, ? extends Comparable<E>>>

[MODE PGI-Bis ON]
Leggibilissimo
[MODE PGI-Bis OFF]

[cdimauro]

Originariamente inviato da PGI-Bis

Noi dobbiamo guardare il male e commisurare ad esso la cura. Il male era:

(String)arrayList.get(index);

Questo non denota forse l'esigenza di poter avere a disposizione UN codice per gestire qualunque tipo di dato? Anche questo sarebbe un male?

La cura consta di 50 pagine di teoria dei tipi, in parte eccepite dalla necessità di preservare l'interazione con codice non generico.

In Java 5 mi hanno detto che se ho il raffreddore posso curarmi togliendo la sicura alla granata che mi sono infilato in bocca.

[PGI-Bis]

Originariamente inviato da k0nt3

il male era che se ti finiva una pera in coda al casello il compilatore non te lo diceva

Che fai, mi prendi per i fondelli?

[AGGIUNTO]

Originariamente inviato da cidimauro

Questo non denota forse l'esigenza di poter avere a disposizione UN codice per gestire qualunque tipo di dato? Anche questo sarebbe un male?

Pure tu?

[cdimauro]

Originariamente inviato da PGI-Bis

Che fai, mi prendi per i fondelli?

[AGGIUNTO]

Pure tu?

Non era assolutamente mia intenzione prenderti in giro.

Semplicemente come programmatore m'è capitato non poche volte di avere l'esigenza di manipolare dati di qualunque tipo (l'esempio della lista è un classico).
Coi linguaggi non-amorfi la soluzione è usare un puntatore "generico" (TObject in Delphi, Object in Java, ecc. ecc.) e "sporcarsi le mani" col casting. Con quelli amorfi non serve perché i costrutti accettano qualunque tipo.

Da ciò, non penso che aver bisogno di una struttura che manipoli dati di qualunque tipo sia un male. Tutto qui.

[k0nt3]

ah nemmeno io avevo intenzione di prendere in giro qualcuno.. tuttavia se non si introducono i generics il problema della pera rimane irrisolto

[Mixmar]

Originariamente inviato da cdimauro

Non era assolutamente mia intenzione prenderti in giro.

Semplicemente come programmatore m'è capitato non poche volte di avere l'esigenza di manipolare dati di qualunque tipo (l'esempio della lista è un classico).
Coi linguaggi non-amorfi la soluzione è usare un puntatore "generico" (TObject in Delphi, Object in Java, ecc. ecc.) e "sporcarsi le mani" col casting. Con quelli amorfi non serve perché i costrutti accettano qualunque tipo.

Da ciò, non penso che aver bisogno di una struttura che manipoli dati di qualunque tipo sia un male. Tutto qui.

Altra riflessione probabilmente poco originale... ma non sarebbe meglio, in tal caso, che, anzichè disporre di una funzione/metodo che manipola oggetti "generici" o "amorfi", che l'operazione stessa fosse "scaricata" sull'oggetto stesso, facendo così implementare a ciascun tipo la "propria" versione di una certa operazione?

Adesso mi risponderete che, in generale, questo non è sempre possibile... però forse lo è ma è troppo contorto a livello di programmazione?

[marco.r]

Perdonate se parto con una scarrettata di quote, ma gli ultimi giorni sono stati molto intensi e non ho potuto seguire piu' di tanto la discussione...

Originariamente inviato da k0nt3

sembra facile ma sappiamo tutti che non sempre (per non dire quasi mai) si può sostituire il copia-incolla con qualcosa che lo rappresenta nel linguaggio (almeno non con altrettanta semplicità).. non si tratta di intere classi, ma di spezzoni di codice che si ripetono e per altro nemmeno sempre nella stessa maniera (di solito sono parametrici sul tipo e/o nome della variabile) per cui è anche difficile usare delle funzioni

L' uso del copia-incolla e' sintomo che forse il linguaggio non e' cosi' flessibile come servirebbe. Io programmo per far fare al computer le cose ripetitive, ma se devo ripetere lo stesso codice io, perche' non avere un linguaggio che fa anche quello per me ? C++ e' meglio di C a riguardo perche' con i template posso evitare di scrivere lo stesso codice per tipi diversi. C++ di suo e' peggiore di altri linguaggi che hanno un serio supporto alla metaprogrammazione, perche' non posso ad esempio prendere una classe e wrappare ogni metodo con una funzione di logging, lo devo fare a mano metodo per metodo...

[PGI-Bis]

Il mio "mi prendete per le natiche" era amorevole: sapete che io sono inoffendibile per costituzione.

E' possibile che sia passato inosservato, quindi lo ripeto:

<E, T extends Document & Comparable<? super String> & Map<? extends Comparable<Number>, ? extends Comparable<E>>>

Una cosa come questa sarebbe accettabile se curasse la fame nel mondo, prevenisse la morte o abbassasse le tasse del 40%. Il problema della pera... quella roba che ho scritto là sopra in Java significa qualcosa! Non ci si riesce a credere!

[marco.r]

Originariamente inviato da PGI-Bis

Hai centrato il punto della leggibilità. Che vale per tutte le lingue che si dichiarino "più leggibili". Non ti trascino nel solito girone di teorie e pinzillacchere.

( So che con questo mi attirero' l'ennesimo pistolotto , ma abbocco ugualmente all'amo )
La lingua deve essere leggibile per chi la conosce, non per il lettore casuale.
Per leggibile, nel caso dei linguaggi di programmazione perlomeno, intendo dire che trasmette chiaramente e in modo non ambiguo il suo significato.
La @ del python puo' non piacere ma, per uno che ci programma, puo' voler dire solo una cosa. Essempi di illeggibilita' sono secondo me altri, come ad esempio di implementare operatori che non fanno quello che sembrano (il buon Bjarne ad esempio ha deciso che quelli di bit-shifting andassero bene per scrivere sui canali...) o combinazione malsana di costruttori impliciti in cui pensi di chiamare un certo metodo ma invece ne chiami un altro perche' invece di convertirti il primo argomento lo fa sul secondo...