C'è differenza tra C e C# ?

[cdimauro]

Originariamente inviato da gugoXX

Provo a replicare su qualche punto.
Alla fine aggiustero' la lista, per evitare futuri errori.


Una volta non lo erano.
Neppure byte lo era, ora che mi ricordo. E non avevo mai capito il perche', dato che gia' dal C il linguaggio si fregiava di essere abbastanza a basso livello.
Non dico WORD o keyword simili, effettivamente platform dependent.
Ma almeno byte e bool (o bit). Bit c'era addirittura in Pascal se non erro...

No, non c'era. In Pascal c'erano i set, che sono qualcosa di simile (ma più flessibile).

In C# il fall-trought e' permesso tra casi equivalenti, a patto di non mettere codice tra di essi.
Es:

switch(parametro)
{
   case 0:
   case 1:
   case 2:
      qualcosa
      break
   case 3:
   case 4:
      altro
      break;
   default:
   ....
}

Cosa che non si puo' fare e' mettere codice tra un case e l'altro, senza usare un break. Il break, se si e' scritto del codice, e' obbligatorio.

Se è così aggiungere il break è inutile: avrebbero dovuto rimuoverlo.

E io rispondo che sono tanto felice di poter sfuttare a mia volta l'esperienza e la fatica di qualcuno,senza neppure virtualmente sapere come RTP, RSTP o MMS sono fatti (anche se in realta' RTP e RSTP li ho dovuti conoscere).
Anche chi usa il C++ o il C a sua volta sfrutta la fatica e l'esperienza di qualcuno, se non altro di chi ha scritto il compilatore o di chi ha scritto le librerie che si sono utilizzate.

Concordo.

[Vincenzo1968]

Originariamente inviato da cdimauro

...
Il solo fatto di non insegnarlo sarebbe già una gran cosa.
...
Ma come? Il C non era utile come linguaggio? Perché non lo usi?
...

Se un programmatore scarso come me è riuscito a risolvere i due quesiti del contest sul DNA, ottenendo tempi di un quinto di secondo per entrambi, penso a cosa potrebbe ottenere un programmatore medio o uno bravo(penso, per esempio, a repne ).

Secondo me fanno benissimo a insegnarlo.

[gugoXX]

Originariamente inviato da Vincenzo1968

Se un programmatore scarso come me è riuscito a risolvere i due quesiti del contest sul DNA, ottenendo tempi di un quinto di secondo per entrambi, penso a cosa potrebbe ottenere un programmatore medio o uno bravo(penso, per esempio, a repne ).

Secondo me fanno benissimo a insegnarlo.

E mia esperienza che in ambito commerciale, in azienda e nei gruppi di sviluppatori il target non e' quello.
Il target principale non e' la velocita'. Anche quella, ma non il principale.
Tra i target io metto la leggibilita', le velocita' di stesura del codice, lo sforzo che un altra persona deve compiere per metterci mano, la riusabilita'.
Quando e dove (ma solo dove) serve la velocita', ci si puo' concentrare sul punto specifico, costruire la classica black-box nel modo che piace di piu', e usarla nel contesto generale.
A parte la riusabilita', sulla quale ci sarebbe comunque da discutere, secondo me il C e' rimasto parecchio lontano da questi target. Non per niente nel tempo si e' cercato qualcosa di piu'.

E, sempre secondo me, anche l'informatica sta seguendo purtroppo le stesse impronte delle altre scienze.
Una scienza nuova attira menti fresche. Lo stesso e' accaduto all'informatica una ventina d'anni fa. Tutti i miei professori di campo erano giovanissimi, freschissimi, nessuno con piu' di 35 anni.
Tutti spingevano e si lanciavano su nuove tecnologie.
Se guardo oggi le materie, vedo sempre gli stessi argomenti, e vedo sempre le stesse persone.

Nel 2000 a Ingegneria Civile, ad un mio amico richiedevano ancora per parecchi esami la stesura di "papiri" A0 disegnati sul tecnigrafo, con penne a china di vari colori. Ore, giorni, settimane per ciascun elaborato.
Richiesto da professori barbogi che non sapevano neppure dell'esistenza di Autocad. Forse non sapevano neppure muovere il mouse.

Secondo me il C e' il tecnigrafo.

[dupa]

Originariamente inviato da gugoXX

Nel 2000 a Ingegneria Civile, ad un mio amico richiedevano ancora per parecchi esami la stesura di "papiri" A0 disegnati sul tecnigrafo, con penne a china di vari colori. Ore, giorni, settimane per ciascun elaborato.
Richiesto da professori barbogi che non sapevano neppure dell'esistenza di Autocad. Forse non sapevano neppure muovere il mouse.

Secondo me il C e' il tecnigrafo.

Giustissimo.
Prima impari con il tecnigrafo, quando sai che se fai un errore, non puoi fare "undo", poi quando ti sei fatto il culo con il tecnigrafo, allora passerai a usare a Autocad.

[gugoXX]

Originariamente inviato da dupa

Giustissimo.
Prima impari con il tecnigrafo, quando sai che se fai un errore, non puoi fare "undo", poi quando ti sei fatto il culo con il tecnigrafo, allora passerai a usare a Autocad.

E perche' giustissimo?
Le soluzioni tirate fuori con il tecnigrafo sono migliori di quelle tirate fuori con Autocad?
L'impossibilita' di cancellare rende migliore il risultato?
Forse che durante la stesura di un progetto non puo' venire voglia di cambiare qualcosa, riflettendo ed entrando piu' nel problema, ponendosi a riflettere su un determinato particolare, e che magari il dover cambiare qualcosa e magari ridisegnare tutto daccapo ti fa desistere?
O forse gli ingegneri civili sono talmente perfetti e supponenti da dire che ancora prima di iniziare a tirare la prima riga sono perfettamente consci di ciascun minimo particolare di quella che sara' la soluzione finale?

[dupa]

Originariamente inviato da gugoXX

E perche' giustissimo?
Le soluzioni tirate fuori con il tecnigrafo sono migliori di quelle tirate fuori con Autocad?
L'impossibilita' di cancellare rende migliore il risultato?
Forse che durante la stesura di un progetto non puo' venire voglia di cambiare qualcosa, riflettendo ed entrando piu' nel problema, ponendosi a riflettere su un determinato particolare, e che magari il dover cambiare qualcosa e magari ridisegnare tutto daccapo ti fa desistere?
O forse gli ingegneri civili sono talmente perfetti e supponenti da dire che ancora prima di iniziare a tirare la prima riga sono perfettamente consci di ciascun minimo particolare di quella che sara' la soluzione finale?

Se non vuoi buttare tempo e soldi in "disegni" sbagliati, devi prima costruire il progetto nella tua mente, devi imparare ad astrarre, devi fare piccoli schizzi su carta per capire quello che vuoi fare. Insomma devi far lavorare di più il tuo cervello.

A ingegneria non si impara a fare cose pratiche (anche se purtroppo ormai il nuovo ordinamento ha reso ingegneria una scuola di praticoni).

Credi che studiare fisica generale 1, fisica generale 2, fisica tecnica serva a qualcosa di pratico per la maggior parte degli ingegneri?
Serve a darti un modo di ragionare, per imparare ad usare gli strumenti c'è il mondo del lavoro, l'università deve servire ad altro, altrimenti tanto vale andare direttamente a lavorare dopo le superiori così almeno ti pagano.

E ovviamente non userei mai C (a meno di casi molto specifici) per qualcosa in ambito lavorativo, ma come primo linguaggio da imparare è indiscutibilmente il migliore dal punto di vista didattico.

[gugoXX]

Originariamente inviato da dupa

Se non vuoi buttare tempo e soldi in "disegni" sbagliati, devi prima costruire il progetto nella tua mente, devi imparare ad astrarre, devi fare piccoli schizzi su carta per capire quello che vuoi fare. Insomma devi far lavorare di più il tuo cervello.

A ingegneria non si impara a fare cose pratiche (anche se purtroppo ormai il nuovo ordinamento ha reso ingegneria una scuola di praticoni).

Credi che studiare fisica generale 1, fisica generale 2, fisica tecnica serva a qualcosa di pratico per la maggior parte degli ingegneri?
Serve a darti un modo di ragionare, per imparare ad usare gli strumenti c'è il mondo del lavoro,

E' la stessa cosa che mi dicevano alle superiori per il Greco e il Latino.
Ma quante C... di cose si suppone che io debba imparare prima di poter usare la mia mente?
Secondo me questa e' una scusa. Una scusa che sotto sotto ha anche (non solo) l'utilita' di impegare stormi di professori che altrimenti sarebbero disoccupati. Quanti professori di Latino abbiamo in Italia? Cos'altro possono fare? Perche' continuiamo a sfornarne cosi' tanti?

Specifico, io penso veramente che Fisica I, II, etc. siano veramente utili ad un Ingegnere, per lo meno un ingegnere informatico.
Cosi' come lo penso del C e del Goto.
Ma non non userei il C nel corso di algoritmi e strutture dati, cosa che a me e' purtroppo capitata. Non mi avevano neppure spiegato bene le hashtable, tanto e' brutto, scomodo e scoraggiante usarle in C.

[k0nt3]

Originariamente inviato da cdimauro

Come linguaggio lo è, infatti: ubi maior minor cessat dicevano gli antichi latini...

Se sai cosa vuol dire, saprai anche cosa intendo per maior.

non è trascurabile invece. a parte il fatto che volenti o nolenti è ancora un linguaggio molto utilizzato, bisogna anche considerare che quello che si impara programmando in C non va dimenticato.

Originariamente inviato da cdimauro

Questo è proprio banalissimo da smentire: dal C passa a SmallTalk e vedi se continuerai a programmare allo stesso modo.

questa frase è proprio sbagliata in senso logico, stai prendendo un caso specifico a dimostrazione di un fatto generale.
ad esempio se al posto di SmallTalk metti C#, Java o qualsiasi altro linguaggio che usa il paradigma strutturato (la maggiorparte) la dimostrazione cade

Originariamente inviato da cdimauro

Ne abbiamo già discusso e non ci siamo limitati soltanto ai "perché no", ma abbiamo AMPIAMENTE ARGOMENTATO, e continuare a riportare la solita litania non ti darà automaticamente ragione.

non vedo dove avete dimostrato che il paradigma strutturato che si impara in C non è più valido in altri linguaggi, non vedo dove avete dimostrato che sapere come funzionano i puntatori è inutile, quindi non vedo argomentazioni.

Originariamente inviato da cdimauro

Tra l'altro ti avevo anche riproposto di riuppare i vecchi thread e di continuare la discussione, ma ti sei tirato indietro.

uahahahahah

Originariamente inviato da cdimauro

Io sono disponibile a riprendere la discussione SE E SOLO SE ti deciderai a portarla a termine, perché non voglio più tornarci. Quindi fino a quando alla domanda: "è utile insegnare/imparare il C?" non si darà una risposta secca; un bel SI' oppure NO.
Così mi segno il thread e te lo rispiattello senza commenti alla prossima occasione che tirerai fuori nuovamente l'argomento.

mi dispiace ma per me la risposta è sempre SI e finche non ti deciderai a portare argomentazioni serie (intendo argomentazioni non da fanboy) rimarrà tale

Originariamente inviato da cdimauro

Poca roba rispetto a tutto il resto.

sarà poca roba per te, ma per me dimostra che non si è affatto legati a un linguaggio in particolare.

Originariamente inviato da cdimauro

Più che di codice inutile si tratta di codice errato.

il fatto che si possa scrivere codice sbagliato mi sembra del tutto naturale. per scrivere il codice nella maniera corretta bisogna sapere cosa sono i puntatori. e sapere cosa sono i puntatori è utile anche quando si programma in C# o in Java (per capire meglio i reference)

Originariamente inviato da cdimauro

Ma come? Il C non era utile come linguaggio? Perché non lo usi?

non lo uso perchè attualmente non ne ho bisogno e quindi programmo in linguaggi di più alto livello.
sottolineo però che quello che ho imparato con il C non l'ho buttato via

Originariamente inviato da VICIUS

Non il linguaggio come i puntatori, struct ed enum ma il modo di pensare e risolvere i problemi. C è procedurale e porta a trovare soluzioni in modo completamente diverso da linguaggi ad oggetti.

ad esempio il C è adatto a imparare il paradigma strutturato che poi si ritrova in tutti i linguaggi che non sono funzionali o logici. e non mi sembra che ciò sia da dimenticare.
questo non toglie che TUTTI i programmatori degni di questo nome dovrebbero conoscere altri paradigmi (soprattutto OOP)

[71104]

Originariamente inviato da gugoXX

Una volta non lo erano.
Neppure byte lo era, ora che mi ricordo. E non avevo mai capito il perche', dato che gia' dal C il linguaggio si fregiava di essere abbastanza a basso livello.

ma veramente byte non lo è nemmeno adesso: non esiste nessun tipo byte, perché non esiste la necessità di fare la differenza tra byte e char; in C++ char rappresenta un carattere ASCII, e siccome i caratteri ASCII occupano un solo byte, char viene usato anche per memorizzare numeri da un solo byte. ecco, questo poteva essere un contro

Non dico WORD o keyword simili

WORD non solo non è una parola chiave ma non è nemmeno una typedef del C++: è una typedef di Microsoft.

Anche questo non c'era nel C++ fino al 2000 almeno.
Sei sicuro che ci sia oggi nel C++ standard? Ho sentito parlare della sua mancanza non piu' di 2 anni fa.
Ma magari la persona che me ne ha parlato non era effettivamente aggiornata.

ARGH, mi ero confuso con lo Structured Exception Handling

caspita, il C++ non ha il blocco finally... questa finisce dritta dritta su YourLanguageSucks

Lo so che ci sono anche in C++. La differenza sta nell'istante di creazione del template/generic. [...]

ho letto tutto ma... me pare tanto na str****ta

gira e rigira va a finire sempre nella cripticità del messaggio d'errore risultante, ma non è mica un problema di C++: se il compilatore ti dice una cosa incomprensibile è colpa del compilatore. d'altra parte invece istanziare i templates a runtime penso richieda del lavoro in più e quindi degradi, seppure in minima parte, la performance del programma.

Intendevo anche le BSTR, le WCHAR*, le TCHAR*, le OLECHAR*
elementi con cui devi fare conoscenza se vuoi costruire un programma internazionale.

non fanno assolutamente parte del C++. per il fatto di doverci avere a che fare, quel punto si potrebbe trasformare in: "C# supporta nativamente stringhe Unicode", perché il problema del C++ è che supporta solo stringhe ASCII.

A meno che le cose siano cambiate anche in questa direzione...

Microsoft ha introdotto std::wstring; ma c'è ancora una pecca: non ho visto nessuna std::tstring. comunque se vuoi lavorare esclusivamente con le STL Microsoft devi usare solo due tipi di stringhe, string e wstring, ma più spesso ne userai uno solo (string se devi fare un programma portabile a discapito dell'internazionalizzazione, wstring altrimenti).

Per non parlare poi delle varianti, come TUCHAR, LPSTR, LPCSTR, PWSTR, LPCWSTR, OLECHAR FAR* (!!!!! mavaff)

non vorrei dire ma...
1) LPSTR corrisponde a CHAR*
2) LPCSTR corrisponde a CONST CHAR*
3) PWSTR corrisponde a WCHAR*
4) LPCWSTR corrisponde a CONST WCHAR*
5) FAR nei sistemi attuali non ha alcun significato, quindi OLECHAR FAR* corrisponde a OLECHAR*

in pratica li avevi già detti tutti sopra

e comunque ribadisco che non sono problemi di C++; il problema di C++ e che a 'sti livelli non ci arriva neanche

per quanto riguarda invece TUCHAR, lì il problema è (ed è effettivamente un problema del C++) il fatto che non s'è mai capito se char è signed o unsigned. avere le specifiche magari aiuterebbe anche.

Intendevo un pezzo di codice come questo

int pippo(int test, int val)
{
   if (test>100) return val;
   return 0;
}

....
int valore=pippo(5, metodolento(a,b,c) );
...

[...]

ah cioè tu intendevi molto lazy :|
mi ritiro umilmente

In C# il fall-trought e' permesso tra casi equivalenti, a patto di non mettere codice tra di essi.[...]

capito. per quanto riguarda il break, quoto cdimauro; anche se comprendo bene le ragioni di aiuto verso l'enorme quantità di programmatori provenienti da C, C++ e Java.

Non so neppure io, come dicevo le STL non le ho usate in ambito commerciale.
Le properties sono la possiblita' di trasformare una variabile in 2 metodi, uno per il SET e uno per il GET, con codice eseguito ogni volta che si legge o si scrive tale variabile.

ehmmm.... lascia perdere, avevo AMPIAMENTE frainteso
avevi scritto Properties con la maiuscola e quindi pensavo "la classe di nome Properties"

conosco le properties, ma non ne ho mai colto l'utilità: alla fine scrivere un campo privato, un getter e un setter mi pare esattamente la stessa cosa. serve solo come "ufficializzazione sintattica" di una semantica usata molto frequentemente.

P.es. se voglio far suonare in modo asincrono un po' di musica techno in backgorund durante l'esecuzione di un mio programma, posso piazzare questo pezzo di codice qui: [...]

Certo, mi potresti dire che il componente WindowsMediaPlayer e' in realta' una libreria scritta a sua volta in C++, circondata da chiamate managed per poter essere integrata a sua volta in C#.

più che altro mi chiedo cosa c'entri col C#...

[71104]

Originariamente inviato da gugoXX

E' la stessa cosa che mi dicevano alle superiori per il Greco e il Latino.
Ma quante C... di cose si suppone che io debba imparare prima di poter usare la mia mente?
Secondo me questa e' una scusa. Una scusa che sotto sotto ha anche (non solo) l'utilita' di impegare stormi di professori che altrimenti sarebbero disoccupati. Quanti professori di Latino abbiamo in Italia? Cos'altro possono fare? Perche' continuiamo a sfornarne cosi' tanti?

oddio gugo, io ti amo

Ma non non userei il C nel corso di algoritmi e strutture dati, cosa che a me e' purtroppo capitata. Non mi avevano neppure spiegato bene le hashtable, tanto e' brutto, scomodo e scoraggiante usarle in C.

idem

[71104]

Originariamente inviato da Antonio23

[OT]ed è anche giusto secondo me. fare una versione non vuol dire soltanto tradurre quattro frasi di una lingua morta, significa organizzare le proprie idee e il proprio pensiero per trovare una soluzione ad un problema...secondo me, ti aprono davvero la mente. [/OT]

potevi anche evitare di rompere l'idillio che s'era creato tra me e gugo con queste stupide banalità. anche perché le sappiamo già a memoria: sono le stesse ca**ate che ci dicevano giustappunto al liceo.

[marco.r]

Originariamente inviato da k0nt3

non vedo dove avete dimostrato che il paradigma strutturato che si impara in C non è più valido in altri linguaggi, non vedo dove avete dimostrato che sapere come funzionano i puntatori è inutile, quindi non vedo argomentazioni.

Ci sono diverse cose che in C si devono fare in un determinato modo e che e' meglio fare in modo diverso in altri linguaggi. Un classico esempio e' l'iterazione su di un array, visto che tipicamente e' molto meglio usare iteratori o meglio ancora funzioni di mappatura che permettono garanzie di non sforamento e anche migliori ottimizzazioni. Il fatto che sia possibile fare la stesa cosa in altri linguaggi non e' un fatto positivo anzi, perche' spesso porta la gente a scegliere una soluzione non ottimale. Anche per lo stesso paradigma linguaggi diversi portano ad idiomi diversi per cui anche quello che dovrebbe essere "cross-language" all'atto pratico non lo e' (ad esempio perche' diversa gestione della memoria porta ad un uso diverso delle strutture dati).
Resta poi da capire quale vantaggio porti il C rispetto ad altri linguaggi. Secondo me non il discorso dei puntatori che, per quel che serve in altri linguaggi, si puo' imparare con un po' di teoria senza dover sbattercisi contro. Motivi per imparare il C ce ne sono (il fatto che e' diffuso e che quindi prima o poi lo si incontra ad esempio) ma secondo me non ne giustificano l'insegnamento come primo linguaggio.

non lo uso perchè attualmente non ne ho bisogno e quindi programmo in linguaggi di più alto livello.
sottolineo però che quello che ho imparato con il C non l'ho buttato via

[VICIUS]

Originariamente inviato da k0nt3

ad esempio il C è adatto a imparare il paradigma strutturato che poi si ritrova in tutti i linguaggi che non sono funzionali o logici. e non mi sembra che ciò sia da dimenticare.
questo non toglie che TUTTI i programmatori degni di questo nome dovrebbero conoscere altri paradigmi (soprattutto OOP)

La programmazione strutturata non è assolutamente da dimenticare ma se le cose che il C insegna su questo argomento si ritrovano poi anche in altri linguaggi allora non è più logico usarne uno più semplice come ruby ed imparare più velocemente? In questo modo ottieni gli stessi risultati con uno sforzo minore.

Secondo me il C è fondamentale da conoscere se si vuole lavorare ma di certo non è il linguaggio da cui cominciare.

[cdimauro]

Originariamente inviato da Vincenzo1968

Se un programmatore scarso come me è riuscito a risolvere i due quesiti del contest sul DNA, ottenendo tempi di un quinto di secondo per entrambi, penso a cosa potrebbe ottenere un programmatore medio o uno bravo(penso, per esempio, a repne ).

Secondo me fanno benissimo a insegnarlo.

La penso come "gugo", per cui risparmio di ripetere le stesse cose.

x k0nt3: al momento non ho tempo, ma ti rispondo fra qualche giorno, appena torno dalle ferie, visto che sono senza connessione (mia moglie e i miei figli ringraziano ).

[k0nt3]

Originariamente inviato da marco.r

Resta poi da capire quale vantaggio porti il C rispetto ad altri linguaggi. Secondo me non il discorso dei puntatori che, per quel che serve in altri linguaggi, si puo' imparare con un po' di teoria senza dover sbattercisi contro. Motivi per imparare il C ce ne sono (il fatto che e' diffuso e che quindi prima o poi lo si incontra ad esempio) ma secondo me non ne giustificano l'insegnamento come primo linguaggio.

Originariamente inviato da VICIUS

La programmazione strutturata non è assolutamente da dimenticare ma se le cose che il C insegna su questo argomento si ritrovano poi anche in altri linguaggi allora non è più logico usarne uno più semplice come ruby ed imparare più velocemente? In questo modo ottieni gli stessi risultati con uno sforzo minore.

Secondo me il C è fondamentale da conoscere se si vuole lavorare ma di certo non è il linguaggio da cui cominciare.

io non ho parlato di vantaggi che il C ha rispetto ad altri linguaggi o del fatto che C è il linguaggio migliore per imparare a programmare.
ho semplicemente detto che, nonostante sia un linguaggio vecchio, impararlo non è affatto una perdita di tempo, al contrario di cdimauro che ad esempio sostiene che lo sia.

[DanieleC88]

Originariamente inviato da k0nt3

io non ho parlato di vantaggi che il C ha rispetto ad altri linguaggi o del fatto che C è il linguaggio migliore per imparare a programmare.
ho semplicemente detto che, nonostante sia un linguaggio vecchio, impararlo non è affatto una perdita di tempo, al contrario di cdimauro che ad esempio sostiene che lo sia.

E invece no, si sta dicendo proprio il contrario, e cioè che è inutile partire col C per iniziare a programmare. Magari in certi ambiti lavorativi il C è un must e linguaggi managed sono proibitivi, ma non ti aiuta certo ad iniziare nella programmazione.

[k0nt3]

Originariamente inviato da DanieleC88

E invece no, si sta dicendo proprio il contrario, e cioè che è inutile partire col C per iniziare a programmare. Magari in certi ambiti lavorativi il C è un must e linguaggi managed sono proibitivi, ma non ti aiuta certo ad iniziare nella programmazione.

mah per me se un linguaggio è utile lo è indipendentemente dal fatto che è il primo linguaggio che si impara o il secondo. insegna sempre qualcosa.
io nella discussione sul miglior linguaggio da cui partire non mi ci metto nemmeno, sono fortemente convinto che non esista per una serie di fattori che non possiamo prevedere (di cui probabilmente quello principale è il soggetto).

[DanieleC88]

Ma infatti è probabilissimo che uno il C prima o poi se lo debba imparare comunque; io l'ho imparato e non mi pento della cosa. Sta di fatto che riconosco nel C un linguaggio con una curva d'apprendimento più ripida di altri linguaggi: un giovane (che potrebbe in futuro essere un eccellente programmatore, chi lo sa?) potrebbe scoraggiarsi incontrando tutti gli "ostacoli" che il C naturalmente offre. Magari può iniziare con le cose semplici, Python o Ruby, e poi allargare le proprie conoscenze partendo da basi già solide, tutto qui.

ciao

[Vincenzo1968]

Originariamente inviato da gugoXX

...
Il target principale non e' la velocita'. Anche quella, ma non il principale.
Tra i target io metto la leggibilita', le velocita' di stesura del codice, lo sforzo che un altra persona deve compiere per metterci mano, la riusabilita'.
Quando e dove (ma solo dove) serve la velocita', ci si puo' concentrare sul punto specifico, costruire la classica black-box nel modo che piace di piu', e usarla nel contesto generale.
...

Questa storia che l'efficienza(dal punto di vista della velocità di esecuzione) non è tutto, l'ho gia sentita altre volte e in altri forum.
Mi chiedo perché tanti libri su algoritmi e strutture dati si occupino, una pagina si e l'altra pure, della ricerca del migliore(sempre dal punto di vista della velocità) algoritmo, con tanto di dimostrazioni matematiche sulla complessità computazionale.
Sono d'accordissimo sul fatto che un programma debba essere leggibile e manutenibile, ma io metterei l'efficienza al primo posto.

[Vincenzo1968]

Originariamente inviato da Antonio23

a scusa, ho rotto l'idillio sul C#. Me tapino.