When C is the best choise ...

[MazinKaesar]

risposta personale: ever!!

http://www.shlomifish.org/philosophy/co ... -best.html

[RadomE]

Si beh se non t'interessa avere un sistema funzionante in tempo utile...

[NubeCheCorre]

C Rulez !!!!!! Ever and Ever

[riko]

Salvo il fatto che non credo sia stato ben compreso il senso dell'articolo (ovvero non il C è per sempre, il C va bene sempre, bensì "il C ha ancora i suoi campi di utilizzo") trovo che quell'articolo contenga un buon numero di afferemazioni discutibili:

1) C is still more portable than anything written using it.

Qui cominciano già a venirmi i brividi lungo la schiena. Se uno si limita esclusivamente alla libreria standard e minime estensioni POSIX, può sperare che in effetti il codice sia portabile. Tuttavia quando uno deve fare qualcosina di più, si comincia a trovare nella guazza. D'altra parte se GNU ha creato gli autotools proprio per fronteggiare l'enorme complessità di tenere i programmi funzionanti su più architetture, la ragione c'è.

Ci sono problemi di endianess, di chiamate si sistema (provate ad accedere a /proc su un BSD, oppure a fare sysctl su Linux, oppure provate a usare le normalissime getpwnam e simili su MacOS X... si ride).
Per non parlare del discutibile supporto POSIX di Windows.

Se poi vogliamo passare alle GUI, ci spacchiamo in quattro dalle risate. QT funziona su Win X11 e MacOS X. Ma va usato in C++, per la maggior parte. La cosa divertente è che non sempre si comporta *esattamente* allo stesso modo. Anche se in effetti il framework QT è abbastanza portabile, offre anche Socket e simili che funzionano correttamente sulle diverse piattaforme. Ma siamo già in qualcosa pesantemente fuori dal C standard, è una libreria fatta e scritta per lavorare ad un livello più alto rispetto alle complessità del C. Poi se non volete rilasciare il codice sotto GPL dovete pagare. Tanto. Se volete portare, che so, su Amiga, vi attaccate.

GTK su MacOS X non funziona bene, per dire. E anche su Windows dovete costringere i vostri utenti ad installare le librerie corrette. Con eventualmente conflitti fra varie versioni di GTK (windows non è abituato a maneggiare pacchetti a quel modo) e programmi che le usano. Quindi in pratica tanto vale fare un pacchetto con py2exe che contiene tutto, interprete, librerie e compagnia e si avvia con un doppioclick senza problemi di installazione

[ fine prima puntata... continua... ]

[MazinKaesar]

@Riko: il senso dell'articolo l'ho compreso, è solo che a me il C
piace... forse perchè ci lavoro da anni e mi da il pane.

[RadomE]

Io invece nn lo sopporto il C

Beh alla fine è tutto si basa su una domanda: "Cosa dobbiamo fare?"
Da qui poi si sceglierà la migliore soluzione, che sia C o altro.

Non c'è un linguaggio migliore degli altri, ci sono i modi migliori di risolvere un problema IMHO.

[riko]

@Riko: il senso dell'articolo l'ho compreso, è solo che a me il C
piace... forse perchè ci lavoro da anni e mi da il pane.

Anche io ci ho lavorato per anni, e anche a me piace. Il punto è che il fatto che mi sia molto simpatico (parere affettivo/irrazionale) e che mi ci trovi bene (questione di abitudine) non mi impedisce di vederne i difetti.

Quando devo scegliere una piattaforma/tecnologia per un dato progetto, ho il vezzo di volere scegliere quella migliore (a mio giudizio) possibile, non necessariamente quella con cui ho lavorato più a lungo (posto che comunque abbia un'esperienza tale da lavorarci). Questo al di la delle tecnologie che preferisco.

Pensa che al momento ho anche progetti in Java (e a me Java non piace particolarmente). Tuttavia per alcune cose è comodo averci la mano.

Credo che il segreto di un progetto riuscito sia sapere scegliere le tecnologie corrette. Pretendere di usare sempre un linguaggio (o sempre un linguaggio da solo) è un non senso, ormai, specie in quanto i linguaggi sono molto diversi fra loro.