C'è differenza tra C e C# ?

[Tommo]

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?

E' esattamente quello che pensavo anche io... d'altra parte è evidente che le conoscenze acquisite in latino NON sono trasferibili in qualsiasi altra lingua; non fosse altro perchè le frasi ti uscirebbero così arcaiche da essere ridicole.
Se fosse vero che il latino "apre la mente", la stessa proposizione potrebbe valere che so, per il collezionismo di insetti, per il teatro, per gli scacchi, per Sim City, per fare la Settimana Enigmistica... ma non mi risulta che queste ultime si insegnino a scuola

Io più che col C (che ancora non è del tutto lingua morta) ci vedo somiglianze con l'insegnamento dell'ASM su processori vecchi e strasorpassati, vero e proprio aramaico... la scusa è quella di insegnarti come funziona un pc, ma i pc moderni sono distantissimi da quel modello ormai...
Se programmi un Core2 come un 386, è come guidare un BMW come una 500. Di quelle del 60.

[cionci]

Originariamente inviato da 71104

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.

Cerchiamo di mantenere la calma

[VICIUS]

Originariamente inviato da Vincenzo1968

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.

Secondo me quando si scrive codice ci si deve concentrare sulla struttura e renderla chiara e ben fattorizzata e non farsi condizionare dalla smania di velocità. Se una volta finito il codice questo non è abbastanza veloce si può sempre usare un profiler per individuare i punti critici e riscriverli.

Chiudo con una citazione di un grande:
Premature optimization is the root of all evil.
-- Orsetto Knuth

[Vincenzo1968]

Originariamente inviato da VICIUS

Secondo me quando si scrive codice ci si deve concentrare sulla struttura e renderla chiara e ben fattorizzata e non farsi condizionare dalla smania di velocità. Se una volta finito il codice questo non è abbastanza veloce si può sempre usare un profiler per individuare i punti critici e riscriverli.

Chiudo con una citazione di un grande:
Premature optimization is the root of all evil.
-- Orsetto Knuth

Grandissimo Knuth,

ho i suoi tre volumi e non vedo l'ora che escano anche gli altri due(forse, si legge nel suo sito, nel 2010).

[Galileo]

Originariamente inviato da dupa

Ma lo capirete prima o poi che quando si programma in Java o in C# sia usa sia programmazione strutturata, sia programmazione funzionale, sia programmazione a oggetti?!?!

eccola qui l'altra boiata. Programmazione funzionale in Java.
Questa me la segno, dopo il K&R bibbia dell'Informatica

[Galileo]

Originariamente inviato da dupa

Bravo, Questo mi sembra un buon esempio dei motivi per i quali è meglio partire con il C.

Stupidaggini.
E poi che significa "un algoritmo è già implementato"? E' una delle strutture semantiche built-in nel linguaggio?
Se non lo è non è implementato, se lo troviamo nelle librerie, allora vale per qualsiasi linguaggio discretamente diffuso.

Oltre a questo, è una scemenza, perché il funzionamento di un algoritmo lo si può desumere qualunque sia lo strumento utilizzato per scriverlo, il che significa anche pseudocodice.
Lo vogliamo implementare? Possiamo farlo con C, Java, C#, Python, Ruby, PHP ecc. ecc.
Con una differenza: nei linguaggi ad alto livello ce ne freghiamo dei dettagli (puntatori per esempio) e andiamo alla sostanza, ovvero cosa fa un algoritmo e cosa funziona.
Se anche i dinosauri universitari lo capissero sarebbe tutto più semplice

[k0nt3]

Originariamente inviato da Galileo

eccola qui l'altra boiata. Programmazione funzionale in Java.

bisogna aspettare Java 7 con ogni probabilità

Originariamente inviato da Galileo

Stupidaggini.
E poi che significa "un algoritmo è già implementato"? E' una delle strutture semantiche built-in nel linguaggio?

significa che è implementato nelle librerie standard

[nico159]

il Windows del futuro è scritto in C#

Sarebbe bello quantificare questo "futuro"

[71104]

Originariamente inviato da nico159

Sarebbe bello quantificare questo "futuro"

boh? 20 anni?

[Galileo]

Originariamente inviato da k0nt3

bisogna aspettare Java 7 con ogni probabilità

Con ogni probabilità non c'è scritto da nessuna parte. Si sta parlando delle modifiche che saranno apportate con Dolphin e ad oggi le più fondate sembrano le closures, il tentativo di rendere Java multilinguaggio, superpackage, una non ben precisata modularità e JavaFX.
Tutte novità per inciso, presenti da anni in altre tecnologie, a dimostrazione di quanto Java, da anni, non stia innovando, bensì rincorrendo i concorrenti.

E in ogni caso non era questo il punto, il che rende la tua risposta superflua.
La baggianata è che si possa usare il paradigma funzionale con Java; ad oggi non è possibile salvo tramite una particolare libreria, homebrew, che risulta più un accrocchio e non una funzionalità messa a disposizione del linguaggio.

significa che è implementato nelle librerie standard

Il che dovrebbe escludere quindi anche C, per esempio, dal linguaggio scelto per imparare il funzionamento degli algoritmi di ordinamento visto che sono già implementati nella libreria standard.
Ovvero la contraddizione del ragionamento di dupa, che comunque non funzionava a priori, perché non è l'essere presente o meno in una libreria che facilita o rende più difficile l'operazione.

[71104]

Originariamente inviato da Galileo

Il che dovrebbe escludere quindi anche C, per esempio, dal linguaggio scelto per imparare il funzionamento degli algoritmi di ordinamento visto che sono già implementati nella libreria standard.

uno solo è già implementato
edit - pardon, due

Ovvero la contraddizione del ragionamento di dupa, che comunque non funzionava a priori, perché non è l'essere presente o meno in una libreria che facilita o rende più difficile l'operazione.

veramente non so a te, ma a me facilita molto...

[Galileo]

Originariamente inviato da k0nt3

non sono per niente daccordo.

Fin troppo ovvio

devi capire che non sono tutti come te, c'è a chi piace conoscere i dettagli di basso livello, e non è mica detto che diventeranno pessimi programmatori.

Partiamo dal presupposto che non stiamo parlando di cose che piacciono o non piacciono ma di una formazione che possa tornare utile poi nel mondo del lavoro e non nelle cantine dove, a volte, si sviluppa del buon software Open Source.
Quindi questo inizio di ragionamento seghiamolo a priori, perché non stiamo dissertando sui piatti di una cucina.

è sbagliato dire che un programmatore deve risolvere problemi, questa definizione comprende solo una parte dell'obiettivo di un programmatore.

Se è sbagliato per te la cosa è irrilevante, nella definizione comune, uno sviluppatore (che è ben diverso e un sovrainsieme dei programmatori) deve risolvere un problema e implementare la soluzione in un determinato contesto e insieme di tecnologie (in realtà è molto più complesso, secondo il modello introdotto da Fowler).

infatti programmare significa risolvere problemi usando gli strumenti informatici a disposizione, e questo implica la conoscenza degli strumenti che si usano.

Ti faccio presente che quel che dici può essere interpretato in due modi; uno è ovvio e cioè che se io sviluppo in un X linguaggio mi sarà richiesto conoscere almeno un ambiente di sviluppo, con funzionalità che aumentino la mia produttività e mi diano modo di testare il mio codice.
Banale, il che rende la tua annotazione superflua.

Io non uso né C né C++ come strumento didattico o di lavoro e quindi dell'implicazione semplicemente me ne frego.
Se poi invece, e arriviamo al secondo nodo, per te è fondamentale perché rientra nella cerchia di strumenti da conoscere, allora posso ribaltarti la questione e dirti che ci sono un'altra ventina di linguaggi che, in teoria, un informatico, dovrebbe conoscere a priori perché utilizzati.
E quindi come la mettiamo? Includiamo anche questi in un corso di studio?

certamente è anche possibile ignorare totalmente tutto questo e programmare senza avere la minima consapevolezza di quello che accade realmente, ma dubito fortemente che questo sia un motivo per programmare "meglio".

Il tuo dubitare buttato lì non costituisce argomentazione sufficiente.

semplicemente la programmazione di cui parlate voi e quella di cui ho parlato poche righe sopra sono due cose diverse e complementari (si posso imparare in momenti diversi e senza particolari problemi se non nella mente del soggetto). un programmatore DEVE sapere a che livello porsi, non esiste nessun approccio che è meglio sempre.

Il livello a cui si deve porre è quello del problem solving, il resto sono seghe mentali di gente che vuole difendere a tutti i costi una tecnologia morente, che però è l'unica che conosce e tramite la quale prende lo stipendio.
Ed è quello che accade nella mafia delle università italiane (lo scrivo col minuscolo volutamente, perché in questo situazioni la capital letter non se la meritano neanche di striscio).
Punto e stop.

Se e quando capita ad uno studente neolaureato di trovarsi nella situazione di programmare macchine a calcolo numerico, PLC, dispositivi embedded vari, ALLORA si sposterà ad un livello logico più basso e cercherà di calarsi nel nuovo contesto, avendo comunque alle spalle solide nozioni di algoritmica e problem solving, che sono agnostiche rispetto alle tecnologie utilizzate.

se parliamo di imparare a programmare invece sto dicendo che si può imparare a programmare sia in Java che in C che in Python, non vedo quale sia il problema, dipende dalle attitudini del soggetto.
certo è che se uno viene sul forum a chiedere ogni minima cassata (dolce tipico siciliano) significa che non andrà molto lontano. e questo sia che sta usando python che C.

Francamente con questa nenia del "si può imparare cominciando con C, Java, Python allo stesso modo" hai scocciato credo 3/4 della sezione, perché ad ogni argomentazione o confutazione evidente e banale di gente che lavora almeno da una decina d'anni nel settore e sa perfettamente quali siano le difficoltà di cambiare paradigma cambiando lo strumento utilizzato (tipicamente da C/C++ a C# o Java) riesci ad arrampicarti sugli specchi ed inventarti qualche altra annotazione.
Quella che i segmentation fault servissero per la formazione di un programmatore è stata davvero comica (ma sicuramente mi sarò perso qualche altra chicca in questi mesi ).

per il resto ho già ampiamente argomentato il fatto che tutto quello che si apprende con il C serve anche quando si programma in altri linguaggi.

Le basi della programmazione strutturata si ritrovano in qualsiasi altro linguaggio ad alto livello, il che rende, per l'appunto, l'utilizzo didattico di C perfettamente inutile.

addirittura l'uso dei puntatori è presente in C#, ma anche quando si parla di reference in un qualsiasi linguaggio moderno può tornare d'aiuto il concetto di puntatore per capire come mai Java non ha il passaggio per riferimento (ci sono volute una ventina di pagine in un thread di questo forum per convincere certi programmatori), come mai in Java quando copio un oggetto non viene eseguita una deep copy ecc...

I puntatori in C# esistono ma sono deprecati perché costringono il lo sviluppatore a scrivere codice unsafe, ovvero codice che non è possibile controllare con il CLR.
In sostanza sono perfettamente inutili, creati per facilitare il passaggio degli sviluppatori C/C++ a C#; da quando esiste .NET non ho mai scritto mezza riga di codice unsafe.

quando si programma seriamente questi sono problemi che vanno affrontati,

No.
Questi sono i problemi, le stupidaggini su cui i programmatori che non hanno ben chiara la metodologia utilizzata in un'azienda (e che probabilmente non hanno mai lavorato seriamente in un team) perdono tempo fossilizzandosi su dettagli di nulla importanza, ignorando invece le questioni serie ovvero come progettare il design di un'application enterprise, rendendola modulare e dividendo logicamente i layer della stessa.

non basta ragionare in termini astratti e saper risolvere problemi, bisogna anche conoscere gli strumenti informatici che vanno usati, il resto è pura fantasia.

Infatti. "Apprendo" una forma mentis che abbia ben chiaro il concetto di OODesign, sviluppo in un qualsiasi linguaggio discretamente moderno utilizzando tool adeguati e me ne frego altissimamente del resto (C/C++ compresi), perché altrimenti come ho scritto qualche riga sopra, seguendo il tuo ragionamento dovrei allora estenderlo ad un'altra ventina di linguaggi, ognuno utile a modo suo per una ipotetica futura carriera di sviluppatore/informatico.

[Galileo]

Originariamente inviato da 71104

veramente non so a te, ma a me facilita molto...

si parlava dal punto di vista didattico.
Il fatto che sia incluso o meno nella libreria standard o in altre è ininfluente perché poi andrai ad implementarlo a mano, seguendo lo pseudocodice.
Se però non ti devi concentrare su puntatori&co. puoi pensare direttamente al cosa fa l'algoritmo, qual'è la complessità e se è corretto, che poi è il succo del discorso del perché sia meglio utilizzare strumenti che rendono trasparenti dettagli implementativi concentrandosi sull'algoritmo necessario a risolvere X problema.

[71104]

Originariamente inviato da Galileo

si parlava dal punto di vista didattico.

ah ho capito, siamo sul pippa mentis

senti Galileo, chissà perché sto nome poi... dicevo senti Galileo, siamo ad Agosto inoltrato e fino a qualche giorno fa faceva un caldo boia, ma non hai altro da fare alle 15:20 che scrivere il post #215?
oddio, 15:20 per modo di dire: per scrivere tutta quella roba minimo un'ora eh...

ecco, prendi me per esempio: sono appena tornato da una bella nuotata in pisciuìna e di risponderti non mi va proprio, quindi scusami ma il post #216 non lo leggo neanche

ciao

[k0nt3]

Originariamente inviato da Galileo

Con ogni probabilità non c'è scritto da nessuna parte. Si sta parlando delle modifiche che saranno apportate con Dolphin e ad oggi le più fondate sembrano le closures, il tentativo di rendere Java multilinguaggio, superpackage, una non ben precisata modularità e JavaFX.
Tutte novità per inciso, presenti da anni in altre tecnologie, a dimostrazione di quanto Java, da anni, non stia innovando, bensì rincorrendo i concorrenti.

E in ogni caso non era questo il punto, il che rende la tua risposta superflua.
La baggianata è che si possa usare il paradigma funzionale con Java; ad oggi non è possibile salvo tramite una particolare libreria, homebrew, che risulta più un accrocchio e non una funzionalità messa a disposizione del linguaggio.

Il che dovrebbe escludere quindi anche C, per esempio, dal linguaggio scelto per imparare il funzionamento degli algoritmi di ordinamento visto che sono già implementati nella libreria standard.
Ovvero la contraddizione del ragionamento di dupa, che comunque non funzionava a priori, perché non è l'essere presente o meno in una libreria che facilita o rende più difficile l'operazione.

vedo che hai capito quello che ho scritto, non capisco però perchè sostieni che sia in contraddizione con quello che hai detto te.

quando ho detto che con ogni probabilità bisognerà aspettare java7 era sottointeso che _adesso_ java non supporta nessun costrutto del paradigma funzionale.

per il fatto delle librerie standard non mi sembra di aver detto che le librerie del C non implementano l'ordinamento (infatto implementano quick sort), ho solo detto cosa significava quella frase visto che secondo me era possibile interpretarla solo in quella maniera.

[k0nt3]

Originariamente inviato da Galileo

Partiamo dal presupposto che non stiamo parlando di cose che piacciono o non piacciono ma di una formazione che possa tornare utile poi nel mondo del lavoro e non nelle cantine dove, a volte, si sviluppa del buon software Open Source.
Quindi questo inizio di ragionamento seghiamolo a priori, perché non stiamo dissertando sui piatti di una cucina.

e chi l'ha stabilito che non stiamo parlando di gusti personali? te?
e io dovrei pure rispondere a uno che crede di essere dio?
tanto per rimanere in tema ti faccio presente che C è utile nel mondo del lavoro "che ti piaccia o no"
ho un conoscente che lavora alla Nokia Siemens e usa C tutti i santi giorni. non chiedermi perchè, ma sta di fatto che lo usano.

Originariamente inviato da Galileo

Se è sbagliato per te la cosa è irrilevante, nella definizione comune, uno sviluppatore (che è ben diverso e un sovrainsieme dei programmatori) deve risolvere un problema e implementare la soluzione in un determinato contesto e insieme di tecnologie (in realtà è molto più complesso, secondo il modello introdotto da Fowler).

per risolvere problemi in maniera astratta non c'è bisogno di un programmatore.
per la cronaca la definizione comunemente accettata di "programmatore" è: "persona che scrive software", e non "persona che risolve problemi"
può sembrare una banalità, ma la seconda definizione non tiene conto del fatto che il programmatore ha a che fare con dei limiti imposti dagli strumenti che usa e che per forza di cose deve conoscere.

Originariamente inviato da Galileo

Ti faccio presente che quel che dici può essere interpretato in due modi; uno è ovvio e cioè che se io sviluppo in un X linguaggio mi sarà richiesto conoscere almeno un ambiente di sviluppo, con funzionalità che aumentino la mia produttività e mi diano modo di testare il mio codice.
Banale, il che rende la tua annotazione superflua.

Io non uso né C né C++ come strumento didattico o di lavoro e quindi dell'implicazione semplicemente me ne frego.
Se poi invece, e arriviamo al secondo nodo, per te è fondamentale perché rientra nella cerchia di strumenti da conoscere, allora posso ribaltarti la questione e dirti che ci sono un'altra ventina di linguaggi che, in teoria, un informatico, dovrebbe conoscere a priori perché utilizzati.
E quindi come la mettiamo? Includiamo anche questi in un corso di studio?

vedo che non hai capito nulla. la risposta esatta era la terza interpretazione che poi è anche l'unica possibile.
con strumenti non intendo linguaggi, altrimenti avrei detto linguaggi.
non solo i linguaggi, ma anche il paradigma di programmazione è uno strumento, il software che uso per sviluppare sono strumenti, il computer stesso è uno strumento.
ora siccome non ha senso imparare 2 milioni di linguaggi quando poi se ne useranno 2 o 3 in pratica.. è molto meglio insegnare i diversi paradigmi di programmazione usando qualche linguaggio rappresentativo per fare un pò di pratica. in tutto questo ci può stare benissimo C, Java, python e qualunque cosa che abbia un paradigma di programmazione. hanno tutti qualcosa da insegnare

Originariamente inviato da Galileo

Il tuo dubitare buttato lì non costituisce argomentazione sufficiente.

quindi pensi che non sapere come funziona un computer sia un motivo per programmare meglio?
per me è fondamentale sapere come funziona il computer come per un meccanico è fondamentale sapere come funziona il motore di una macchina.
poi è ancora più importante sapere quando usare queste conoscenze e quando invece porsi a un livello di astrazione più elevato

Originariamente inviato da Galileo

Il livello a cui si deve porre è quello del problem solving, il resto sono seghe mentali di gente che vuole difendere a tutti i costi una tecnologia morente, che però è l'unica che conosce e tramite la quale prende lo stipendio.
Ed è quello che accade nella mafia delle università italiane (lo scrivo col minuscolo volutamente, perché in questo situazioni la capital letter non se la meritano neanche di striscio).
Punto e stop.

nel livello "problem solving" non vi è traccia del problema del passaggio dei parametri o della copia degli oggetti a cui ho fatto riferimento più sotto.
è evidente che non stiamo a quel livello quindi
altrimenti continueremo a sfornare gente che non ha capito il nulla più assoluto tipo questo http://mail.python.org/pipermail/pyt...er/234135.html
e pure le risposte non sono tanto chiare, bastava dire: esiste solo il passaggio dei parametri per valore, non mi sembra complicato

Originariamente inviato da Galileo

Se e quando capita ad uno studente neolaureato di trovarsi nella situazione di programmare macchine a calcolo numerico, PLC, dispositivi embedded vari, ALLORA si sposterà ad un livello logico più basso e cercherà di calarsi nel nuovo contesto, avendo comunque alle spalle solide nozioni di algoritmica e problem solving, che sono agnostiche rispetto alle tecnologie utilizzate.

sono il primo a dire che bisogna essere agnostici rispetto alle tecnologie utilizzate, per questo bisogna insegnare più di un paradigma di programmazione. non capisco per quale motivo il C sia da escludere a priori, è pur sempre un rappresentante di un paradigma di programmazione (anche se abbiamo capito che non ti piace).

Originariamente inviato da Galileo

Francamente con questa nenia del "si può imparare cominciando con C, Java, Python allo stesso modo" hai scocciato credo 3/4 della sezione, perché ad ogni argomentazione o confutazione evidente e banale di gente che lavora almeno da una decina d'anni nel settore e sa perfettamente quali siano le difficoltà di cambiare paradigma cambiando lo strumento utilizzato (tipicamente da C/C++ a C# o Java) riesci ad arrampicarti sugli specchi ed inventarti qualche altra annotazione.
Quella che i segmentation fault servissero per la formazione di un programmatore è stata davvero comica (ma sicuramente mi sarò perso qualche altra chicca in questi mesi ).

ma finiscila.
se c'è una cosa che ha scassato i maroni a tutta la sezione è chi sostiene python è il miglior linguaggio del mondo e probabilmente anche di saturno
visto che io mi arrampico sugli specchi potresti sempre dimostrare che ho torto invece di arrampicarti sugli specchi a tua volta

Originariamente inviato da Galileo

Le basi della programmazione strutturata si ritrovano in qualsiasi altro linguaggio ad alto livello, il che rende, per l'appunto, l'utilizzo didattico di C perfettamente inutile.

ma anche no. se uno impara la programmazione strutturata in C non c'è bisogno che la impara di nuovo in C# per esempio, quindi non è vero che è inutile. si può fare in modo diverso, ma questo è diverso da dire che è inutile

Originariamente inviato da Galileo

I puntatori in C# esistono ma sono deprecati perché costringono il lo sviluppatore a scrivere codice unsafe, ovvero codice che non è possibile controllare con il CLR.
In sostanza sono perfettamente inutili, creati per facilitare il passaggio degli sviluppatori C/C++ a C#; da quando esiste .NET non ho mai scritto mezza riga di codice unsafe.

deprecati? spero che scherzi.
il codice unsafe è stato introdotto per rendere C# adeguato alla programmazione di sistema, non per facilitare il passaggio degli sviluppatori C/C++ come erroneamente credi.
se non hai mai scritto mezza riga di codice unsafe significa che non ne hai avuto bisogno, non che è inutile.

Originariamente inviato da Galileo

No.
Questi sono i problemi, le stupidaggini su cui i programmatori che non hanno ben chiara la metodologia utilizzata in un'azienda (e che probabilmente non hanno mai lavorato seriamente in un team) perdono tempo fossilizzandosi su dettagli di nulla importanza, ignorando invece le questioni serie ovvero come progettare il design di un'application enterprise, rendendola modulare e dividendo logicamente i layer della stessa.

una cosa non esclude l'altra, non vedo perchè quello che hai scritto te è in contrasto con quello che ho scritto io considerando che sono cose totalmente scorrelate

Originariamente inviato da Galileo

Infatti. "Apprendo" una forma mentis che abbia ben chiaro il concetto di OODesign, sviluppo in un qualsiasi linguaggio discretamente moderno utilizzando tool adeguati e me ne frego altissimamente del resto (C/C++ compresi), perché altrimenti come ho scritto qualche riga sopra, seguendo il tuo ragionamento dovrei allora estenderlo ad un'altra ventina di linguaggi, ognuno utile a modo suo per una ipotetica futura carriera di sviluppatore/informatico.

non è importante conoscere i linguaggi, ma i paradigmi di programmazione, in questa maniera si ha sempre una visione d'insieme e si evita di fossilizzarsi.
ecco è chiaro che tutti quelli che odiano così tanto il C è perchè devono essersi fossilizzati in qualche modo e ora lo maledicono. purtroppo però non può essere colpa del linguaggio, fatevene una ragione

[DanieleC88]

Originariamente inviato da k0nt3

ho un conoscente che lavora alla Nokia Siemens e usa C tutti i santi giorni.

Allo Nokia o alla Siemens?

Originariamente inviato da k0nt3

deprecati? spero che scherzi.
il codice unsafe è stato introdotto per rendere C# adeguato alla programmazione di sistema, non per facilitare il passaggio degli sviluppatori C/C++ come erroneamente credi.
se non hai mai scritto mezza riga di codice unsafe significa che non ne hai avuto bisogno, non che è inutile.

Sconsigliato è sconsigliato, ma in certe occasioni è utile/necessario:
http://msdn.microsoft.com/en-us/libr...69(VS.71).aspx
http://msdn.microsoft.com/en-us/libr...74(VS.71).aspx

The use of pointers is rarely required in C#, but there are some situations that require them. As examples, using an unsafe context to allow pointers is warranted by the following cases:

* Dealing with existing structures on disk
* Advanced COM or Platform Invoke scenarios that involve structures with pointers in them
* Performance-critical code

The use of unsafe context in other situations is discouraged.

una cosa non esclude l'altra, non vedo perchè quello che hai scritto te è in contrasto con quello che ho scritto io considerando che sono cose totalmente scorrelate


non è importante conoscere i linguaggi, ma i paradigmi di programmazione, in questa maniera si ha sempre una visione d'insieme e si evita di fossilizzarsi.
ecco è chiaro che tutti quelli che odiano così tanto il C è perchè devono essersi fossilizzati in qualche modo e ora lo maledicono. purtroppo però non può essere colpa del linguaggio, fatevene una ragione[/quote]

[k0nt3]

guarda lo sa anche wikipedia http://it.wikipedia.org/wiki/Nokia_Siemens_Networks

[cdimauro]

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, 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.

A parte che sono d'accordo con gugo e quanto scritto dagli altri (tranne k0nt3 ovviamente ), facciamo finta che sia d'accordo con te.

A questo punto usiamo pure il "tecnigrafo" e soltanto quando siamo "rodati" passeremo ad "AutoCAD". Usiamo il C "NUDO E CRUDO", quindi soltanto il linguaggio facendo a meno di TUTTA la libreria standard.

Devo visualizzare qualcosa a video? La printf me la sviluppo io! Vuoi mettere il piacere di scriversi da zero qualunque cosa serva? E' così che s'impara, no?

Tra l'altro ti faccio notare una cosa: http://en.wikipedia.org/wiki/Qsort_(C_Standard_Library)

In the C standard library, qsort is a function used to sort elements in an array.

Vaglielo a dire al K & R che NON bisogna fornire una routine di ordinamento di valori, perché fornendo la pappa pronta gli studenti verranno traviati e non capiranno come funziona un algoritmo di ordinamento.

Originariamente inviato da k0nt3

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.

Su questo io e altri t'abbiamo già risposto.

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

Non avevi posto questi vincoli, per cui la dimostrazione era valida.

Anche con questi vincoli rimane un problema di fondo: perché si dovrebbe imparare il C, quando esistono altri linguaggi che permettono di utilizzare la programmazione strutturata e che sono decisamente "migliori" del C?

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.

Su questo concordo con marco, e aggiungo che col C sei costretto fin da subito a usare i puntatori, mentre con altri linguaggi (che permettono di utilizzare la programmazione strutturata) spesso ne puoi fare tranquillamente a meno.

uahahahahah

http://www.hwupgrade.it/forum/showpo...4&postcount=50

Se vuoi li riuppo davvero, per me non c'è problema.

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

Semplicissimo: perché non c'è NESSUN vantaggio nell'utilizzare il C.

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

In generale sì, ma il C continua a essere IL linguaggio d'elezione negli ambienti Unix-like.

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)

No, è che il C, come dicevo prima, ti costringe a ricorrere fin da subito ai puntatori, mentre in altri linguaggi che permettono di utilizzare i reference se ne può fare benissimo a meno anche per stronzate come l'input di un numero.

In C++ ci sono i reference, tanto per tirare in ballo uno dei SUPERSET più noti del C.

In Pascal esistono i VAR da prima ancora che il C fosse concepito.

Tutta roba che AIUTA A EVITARE BAG ROGNOSI come quello che ho riportato, e che è fra i più diffusi.

Infine il fatto che i puntatori aiutino a imparare i reference è vero, ma NON è condizione necessaria: infatti in linguaggi come Java, Python, ma anche lo stesso C#... se ne fa benissimo a meno.

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

Anche quando programmi a oggetti? Debbo credere che il C non t'abbia mai influenzato nello sviluppo di codice a 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.

Per imparare la programmazione strutturata esistono linguaggi decisamente migliori del C.

Il fatto, poi, è che tu tendi a mischiare le due cose. Più precisamente, tendi a confondere queste cose:
- la programmazione strutturata;
- imparare a programmare;
- il linguaggio C.

Anzi, penso che subdolamente cerchi di far passare il messaggio che siccome il C esprime un paradigma strutturato, allora è un buon linguaggio e non vada buttato.

Le tre cose di cui sopra, però, fanno caso a sé.
Che la programmazione strutturata sia l'ideale per iniziare a programmare è AMPIAMENTE OPINABILE.
Che il C sia un buon linguaggio di programmazione per la programmazione strutturata lo è ancor di più.

Difatti non hai ancora portato UN solo vantaggio nell'usare il C per la programmazione strutturata.

E quanto al primo punto, che per un essere umano sia più naturale la programmazione a oggetti è cosa ovvia. Com'è ovvio che quella strutturata sia più naturale per un calcolatore.

questo non toglie che TUTTI i programmatori degni di questo nome dovrebbero conoscere altri paradigmi (soprattutto OOP)

Ma non si capisce perché non si dovrebbe partire con la programmazione a oggetti, visto che è il paradigma che più si avvicina al NOSTRO modo di modellare la realtà che ci circonda.

Originariamente inviato da Vincenzo1968

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.

Allora chiediti come mai l'algoritmo di ordinamento più usato è il quicksort, anche in tante librerie standard.

E chiedi pure come mai nelle implementazioni "classiche" del calcolo del minimo albero di copertura di un grafo con l'algoritmo di Prim venga fatto uso di uno heap, anziché dell'heap di Fibonacci per ridurre la complessità computazionale.

[cionci]

Visto che i toni della discussione sono degenerati, mi vedo costretto a chiudere la discussione. Non voglio aspettare che vi cominciate ad offendere.
Ricordatevi una buona volta che c'è modo di discutere senza darsi addosso l'un l'altro.