On Sep 1, 1:57Â pm, eg...@email.it (egmont) wrote:
> Il 31 Ago 2008, 23:57, Freiherr Childerich von Bartenbruch
>
gmail.com> ha scritto:
>>> On Aug 31, 11:01pm, eg...@email.it (egmont) wrote:
>>> Il 31 Ago 2008, 14:43, Freiherr Childerich von Bartenbruch
>>>
gmail.com> ha scritto:>
>>>> Vorrai dire objective-c (che e' una specie di C smalltalkizzato).
>>>> Il C++ e' un orrore.
>
>>> spero tu stia scherzando, Perchè mai sarebbe un orrore il linguaggio di
>>> programmazione oggettivamente più completo e complesso mai inventato?
>
>> No, non sto scherzando, ed é chiaro che non te ne intendi di linguaggi
>> di programmazione. Il C++ é *intrinsicamente* un linguaggio a typing
>> statico, e tenta di diventare di nuovo dinamico con i template,
>> aggiungendo
>> un inutile strato di complessità per tentare di porre rimedio ad un
>> difetto
>> originario di progettazione. L'objective c, invece, é veramente
>> dinamico.
>> Il c++ non possiede continuazioni, funzioni lambda, non ha un runtime
>> concepito per essere rientrante, non ha un supporto nativo per le
>> thread.
>> Potrei continuare, ma si da il fatto che il c++ é un accrocco, figlio
>> di
>> un tentativo mal riuscito di modernizzare il c, e che si sta cercando
>> di porvi rimedio con il c++0x.
>
>> Complesso, si. Ma non è detto che la complessità sia sempre un
>> vantaggio. L'objective c è decisamente più versatile pur essendo un
>> linguaggio molto + semplice. E supporta pure la garbage collection!
>
> caro amico,
>
> non entro nel merito delle sciocchezze che hai scritto; francamente mi manca
> tempo e voglia, senza considerare che questo è un newsgroup di musica
> classica e non mi va di "sporcarlo" più del dovuto.
Lo stai facendo tu, dandomi dell'ignorante.
> Solo due righe:
> se invece sei tu ad avere tempo e voglia, posso farti conoscere un team di
> progettazione di sistemi real-time, multithreading safety critical, vale a
> dire di sistemi dalla cui "infallibilità " dipende la vita delle persone,
> chissà perchè scritti in C/C++.
Intanto io ho parlato di C++, non di C. Sono due linguaggi molto
diversi e il C++ come ben sai non é un soprainsieme del C.
In secondo luogo, non ho assolutamente detto che il linguaggio non sia
utile. Ci mancherebbe altro.
Il fatto è che il C++ viene spacciato per linguaggio object-oriented
quando il supporto per gli oggetti é quanto meno inflessibile e
farraginoso. Lo stesso Bjarne Stroustrup ha parlato nel suo libro del
1994 delle difficoltà ad estendere un linguaggio come C agli oggetti.
Alla fine il risultato é stato un linguaggio estremamente complesso e
sovradefinito al punto tale che uno dei comitati di standardizzazione,
X3J16/92, ha dichiarato "C++ is already too large and complicated for
our taste".
Un linguaggio é adatto a realizzare sistemi come quelli che hai
descritto quando il codice è facile da mantenere. Ed è ben noto (anche
se vuoi negare l'evidenza) che il c++ non ha mantenuto poco della
promessa di aiutare i programmatori a scrivere codice facile da
mantenere e riutilizzare.
> Qui potrai spiegare le tue perplessità sulla mancanza di supporto nativo
> (sei talmente ignorante da fari confusione tra linguaggio e libreria
> standard) per i (non "le", Asino) thread: magari potresti proporre anche per
Asino a me?
Sei proprio piccola cosa, sai?
Non faccio confusione tra linguaggio e libreria standard. Ma in un
linguaggio complesso come il c++, che non puoi isolare dalla sua
libreria standard, e molte implementazioni non rispettano certi
requisiti di rientranza del codice. Del resto se ne parla ora,
intendo dire, proprio ora, che ci stiamo avvicinando a C++0x.
> il C un'unica api per i thread sia kernel space che user, sia realtime che
> non.
Qui si parlava di C++.
Inoltre stai mettendo assieme due cose distinte. Come programmatore di
programmi, magari interattivi, ovviamente mi interessa programmare con
thread (il genere grammaticale di questa parola é un misero appiglio)
e poterlo fare senza impazzire. I thread nel kernel sono altra cosa e
riguarda altri tipi di applicazioni.
> E potrai convincere questa gente, che da anni evita accuratamente di usare
> Garbage Collectors (che pure sono disponibili per il C++, vedi il Bohem,
> doppio ignorante)
L'ignorante, qui sei tu. Intanto si scrive Boehm, e quel garbage
collector lo conosco bene. Lo portai, tempo fa, ad un sistema
operativo allora non supportato (ed ora non piú esistente, Mac OS
"classico", dovetti arrabattarmi perchè non c'era un facile accesso
alla MMU) e corressi alcuni bug. Quindi fui, in misura molto minore,
chiaramente, un contributore al progetto.
E come forse sai, l'uso della garbage collection in un programma C++ é
opzionale.
Cosà come in alcuni linguaggi che lo contemplano come l'obj-c
(versione 2).
No, ma questo pallone gonfiato pensa che se io menziono la garbage
collection, vado subito a pensare a modelli che non contemplano una
gestione più classica della memoria. E l'ignorante sarei io?
> del gran vantaggio di questo strumenti; pensa un po' a
> quanto sono masochisti.... hanno un Garbage Collector a portata di mano,
> potrebbero sguazzarci dentro e invece si sottopongono a lunghissimi,
> fittissimi e massacranti debug di leak, errori di memoria etc. (ciò che può
> durare anche mesi per lo stesso programma)
Intanto tu stai portando la discussione su un aspetto specifico
dell'uso di un linguaggio, un tipo molto particolare di applicazione.
Per applicazioni real-time ovviamente un sistema di garbage collection
non è sempre ideale. Anche se (forse non lo sai) ci sono garbage
collector che funzionano in real time con latenze molto basse. Per non
parlare di modelli di programmazione nei quali parte della gestione
della memoria può essere fatta in modo classico, e parte con una GC.
Conosci l'articolo "Generational Real-time Garbage Collection: A Three-
part Invention for Young Objects", di Frampton, David F. Bacon, Perry
Cheng, David Grove, presentato ad ECOOP 2007? Qui viene descritto un
sistema di GC che garantisce il real-time (implementato in una
versione real-time di java di IBM).
Spero che usiate dei buoni tool di profiling dell'uso della memoria.
Per molti tipi di applicazioni, invece, avere delle funzioni lambda e
un meccanismo efficace di continuazione (riconoscerai che setjmp()
longjmp() e' patetico e le eccezioni del c++ non sono altro che una
versione glorificata dello stesso meccanismo), aiuta il programmatore,
e non poco. Magari non interessano a te, non servono per lo sviluppo
dei tuoi strumenti, ma c'è un mondo intero al di fuori del tuo
orticello, e il fatto che una specie di algol dopato serva benissimo
ai tuoi scopi non lo rende il linguaggio di programmazione più
completo. Perchè completo non lo è affatto (a meno che tu non intenda
dire: ci posso programmare qualunque cosa. Ovvio allora che lo è: ma
allora non ci serve altro che un buon macro assembler...).
> E con questo, rinnovandoti l'invito a visitare il laboratorio ed i
> macchinari, chiudo questa puerile discussione; a te la felicità (tutta tua)
> di blaterare repliche a volontà .
Qui chiudo anch'io. Il tuo post è patetico e ti screditi da solo.
Childerich
