Ho bisogno di un po' di chiarezza

[cdimauro]

Originariamente inviato da Efem

Beh io sono sempre aperto ai confronti, e ho usato parecchi editor (da quelli da integrare in eclipse per java a Visual C++ a Visual C#. ecc), posso dirti che non mi è piaciuto più di tanto.
Certo, è una perdita di tempo... ma io non parlerei di perdita, piuttosto di "impiego" di tempo. Anche perchè generare codice pulito è importante e questa è una cosa oggettiva, anche senza arrivare a basso livello

D'accordo, ma anche con gli IDE puoi scrivere codice pulito. Semplicemente lo fai lavorando in maniera più comoda.

E' importante partire dalla partenza e non da metà strada.
Almeno questo è il mio punto di vista.

Sì, ma la partenza sarebbe? Per me è il concetto di algoritmo.

Ma per carità penso che si sia capito largamente che la mia era solo una opinione a livello puramente personale.
Da contare anche che programmando in questa maniera non facciamo altro che allargare un monopolio che già così non può essere smontato (altro discorso... non approfondisco)

Infatti meglio non parlare di monopoli & co., primo perché OT e secondo perché mancherebbe la base della discussione (i monopoli non ci sono).

Ma certo, me lo hanno detto e lo tengo ben presente.
Solo che (e non dico niente di nuovo sicuramente) C è stato progettato per programmare utility a livello di sistema operativo e non certo programmi gestionali come poi è stato (purtroppo) fatto.
Non ho mai parlato di C per fare programmi gestionali, e infatti non dovrebbe essere usato per quello.
Ma dire che C è "sparito" o "sparirà" come sostengono in molti che guardano solo la "facciata" dei programmi (e parlo di gente che è uscita dalle università o che la ha frequentata), per me è un pò un delirio.

In ogni caso sono mie idee, ho sicuramente meno anni di programmazione di te

Nessuno dice che C è sparito. Viene ancora molto usato nei settori che ho elencato prima. Purtroppo finché non ci sarà un degno sostituto non si potrà fare altrimenti.

Originariamente inviato da PGI-Bis

Sulle caratteristiche uniche a me verrebbe da dire:

l'impossibilità di scrivere un programma senza usare classi,i package come qualificatori dei nomi, l'introduzione di due meccanismi separati per eredità ed estensione, l'introduzione dei primitivi per la gestione della concorrenza nella radice del typesystem, il collegamento dinamico come metodo predefinito per la risoluzione delle invocazioni di metodo (per un linguaggio staticamente tipato), il meccanismo di caricamento delle classi da stream.

Ma non è detto che lo siano veramente perchè non conosco tutti i linguaggi precedenti a java. Sono praticamente certo invece che il linguaggio abbia innovato fortemente nella combinazione di caratteristiche principali, cioè il fatto di essere quello che è: staticamente tipato, concorrente, orientato agli oggetti, con gestione automatica della memoria, interpretato, con estensione singola ed eredità multipla, a collegamento dinamico, riflessivo e con caricamento in esecuzione delle classi.

Su questo nulla da dire. Quando il mio carissimo prof. Gallo arrivò nel '96 (se non ricordo male) al corso di Elaborazioni delle Immagini presentando Java per realizzare velocemente applet, mi piacque molto nella sua semplicità (non la sintassi ovviamente: è una questione endemica. ).

Comunque nemmeno io conosco tutti i linguaggi e le innovazioni che hanno introdotto. Non mi sento di definire come "innovazioni" la forzatura di alcune caratteristiche. Quindi delle cose che hai elencato salverei quelle che ho evidenziato.

Non ho messo l'ereditarietà multipla tramite le interfacce perché ho il forte dubbio che fosse già stata proposta come modello alternativo alla classica ereditarietà singola e multipla. Da verificare (ho fatto qualche ricerca veloce, ma non ho trovato nulla purtroppo).

Sulla prospettiva, non ci capiamo. Colpa mia ma se mi fai l'esegesi dei periodi non mi aiuti .

Scala mi piace perchè non [lo considero] un minestrone. Anche se le è.

Ti confermo quindi la mia opinione sul mescolamento delle prospettive: è una pessima idea. Vale anche per Scala: è una tristezza che sia anche funzionale. A me piace perchè è orientato agli oggetti e considero alcune delle sue caratteristiche funzionali addolcimenti sintattici per il suo uso orientato agli oggetti. Le altre sue doti funzionali, ad esempio l'immutabilità o la composizione di funzioni, le vedo come una muffa potrebbe vedere il drago pulisan: più alla larga ci sto, meglio è.

Dunque sì, purtroppo è anche funzionale: ma non è che si possa pretendere la luna.

Lo so. Per questo ti ho fatto qualche battuta, perché so come la pensi.

Comunque l'immutabilità dovrebbe un po' piacerti. Le stringhe in Java sono immutabili, e la trovo un'ottima cosa.

In generale immutabilità e composizione di funzioni sono concetti che mi piacciono, e quando posso utilizzo (la composizione in Python la uso spesso tramite i decoratori di funzione; quelli di classe non ho avuto modo di applicarla perché in produzione abbiamo Python 2.5).

Saranno le mie reminiscenze di Scheme e Prolog, che ho molto apprezzato all'università (non particolarmente la sintassi, al solito, ma i concetti sì).

Annotazioni.

Lo scopo delle annotazioni è quello di marcare elementi del codice a fini analitici. Il sorgente resta sempre uguale. Ad esempio nell'ambiente J2EE le annotazioni sono usate per generare automaticamente i descrittori di dispiegamento che i contenitori usano per fornire i servizi specificati nel codice.

Non introducono la possibilità di cambiare il codice sorgente più di quanto non lo si possa fare con una commento ed un trasformatore ad hoc e sono parte della sintassi del linguaggio.

Beh, s'è trovato un modo anche fare altro, e francamente lo trovo comodo.

Il preprocessore è diverso, esiste esattamente allo scopo di cambiare la sintassi del linguaggio. Può darsi che avesse un suo significato nel 1325 a.c. quando un elevamento a potenza era roba da far fumare le caldaie ma è un bel pezzo che abbiamo passato quella fase.

Personalmente NON adoro il preprocessore, ma purtroppo ottenere build diverse di uno stesso progetto è una necessità che prima o poi viene fuori.

Perchè le eccezioni - alle regole - sono cattive.

E' un dato sperimentale assodato che il ragionamento umano funzioni bene in positivo (nel senso dell'affermazione) e malissimo in negativo (nel senso dell'affermazione di una negazione). Dovreste essere in grado di provarlo con un esemplare umano nella vostra disponibilità ed un sempice test.

Oggetti nascosti, gliene proponente uno alla volta chiedendo di confermare o smentire, alternandole, le affermazioni: "è un [accendino-penna-pacchetto di sigarette-quello che è]" oppure "non è un [accendino-penna-pacchetto di sigarette-quello che non è]".

Se è un umanione comune, le risposte alle forme positive saranno più pronte di quelle alla forme negative.

Nel senso predetto, le eccezioni alle regole sono asserzioni negative. L'eccezione si genera quando due attribuzioni di qualità mutualmente esclusive si riferiscono ad uno stesso elemento.

Nel linguaggio x ci sono variabili che sono staticamente tipate e variabili che sono dinamicamente tipate.

Quindi ho due regole, due affermazioni positive? No, ho una regola e un'eccezione: tutte le variabili sono staticamente tipate salvo quello che sono dichiarate dinamiche (la regola è sempre quella che implica meno attribuzioni).

OK, adesso mi è chiaro il concetto. Grazie per la spiegazione.

C'è una sorta di dibattito in corso circa la complessità dei linguaggi che ha visto Java passare dalla parte dei facili a quella dei difficili. I più vecchi se lo ricorderanno: una volta Java era facilissimo, poi è diventato complicatissimo. Il punto intorno al quale si svolge la discussione in corso è esattamente quello delle eccezioni. Chi sostiene ad esempio che Scala sia "più facile" di Java lo fa proprio sottolineando il fatto che pur avendo il primo più regole del secondo ha un numero minore di eccezioni.

Non ho avuto modo di approfondire Scala (mi sono fermato dopo qualche minuto perché la sintassi è incompatibile col mio DNA), ma su Java la penso come te: dal '96 a oggi lo trovo un altro linguaggio, molto più complicato.

Chi invece sostiene che Python sia più facile lo fa per partito preso ma queli sono irrecuperabili

Prima o poi anche tu non ne potrai fare a meno.

Originariamente inviato da birmarco

Un informatico SA soprattutto su cosa sta lavorando. Infatti il corso di laurea in informatica inizia proprio con lo studio dei transistor, della loro combinazione nei circuiti logici e di come si costruisce una CPU a partire proprio dai transistor, bit dopo bit. Dal circuito somma alla ALU, ai registri, le memorie, il pipelining, il parallelismo e multicore, i bus, ecc... Partire più in basso di così non si può. Poi si passa all'assembly. Di pari passo viene insegnato il Java o più raramente il C. Ma il tutto lo si conmprende a fondo solo concludendo gli studi sugli elaboratori. E solo dopo tutto questo si passa a studiare algoritmi, database, ecc...

Chi non ha queste basi non può definirsi informatico. Un informatica di quel livello è indicata a chi fa altri lavori, come un matematico che si programma un SW che esegue un algoritmo. Un informatico che si rispetti sa su cosa sta programmando, sa come sfruttare le potenzialità del proprio HW dialogando con esso, se necessario inserendo blocchi di linguaggio macchina in un programa scritto in un linguaggio di alto livello.

Cmq per iniziare come autodidatta consiglio di partire in alto e poi lasciare all'università il compito di scendere nel dettaglio.

Dovresti renderti conto che ciò di cui hai parlato finora attiene più che altro all'ingegneria, in particolare all'elettronica.

Da informatico i miei "padri spirituali" (per modo di dire, visto che sono ateo ) sono Muhammad ibn Mūsa 'l-Khwārizmī, George Boole, Alan Turing, Kurt Gödel, Alonzo Church, Stephen Kleene, e mi scuso coi matematici / logici che hanno contribuito e di cui non ricordo i nomi.

Originariamente inviato da birmarco

Scusa ma iniziare col parlare di algoritmo è un po' troppo base...

Ma non si parlava di "basi" dell'informatica?

credo che chiunque voglia imparare da solo a programmare sappia che lo fa per ottenere qualcosa: da un input ottengo un output tramite una serie di passaggi.

Un algoritmo non è solo quello. Per fortuna. Se ti andassi a leggere la definizione, capiresti il perché.

Cmq le "basi" sono la dimestichezza con variabili, tipi, if, for, while e compagnia.

Parliamo di condizioni (if, switch, ecc.) e iterazione (for, while, do, ecc.) che è meglio, perché sono concetti più generici.

Il C++ è abbastanza semplice per poter pasticciare agevolmente con queste cose. Poi ci aggiungi array, puntatori, funzioni e se hai voglia anche la scrittura dei file. In C è davvero tutto molto banale e gli intoppi sono veramente pochi. Un puntatore che punta a zone errate di memoria è colpa del programmatore, ma dividere per 0, ad esempio, lo trovo un errore dello stesso tipo: distrazione. E può accadere in qualsiasi linguaggio... Non ho detto che deve riscrivere Photoshop, deve solo pasticciare con scanf e printf... tutto qui. Anche java è un buon inizio, ma è un linguaggio ad oggetti. IMHO, più difficile da comprendere di semplice programma sequenziale in C++.

Java è comodo per fare il salto da C++ a linguaggi più moderni come il .net. E' "simile" a C ma ti introduce più semplicemente al cuore della programmazione ad oggetti. Poi puoi passare a C# e/o a VB.net. Sono passaggi piuttosto semplici e graduali

In più facendo così ti ritrovi a conoscere 3/4 linguaggi.

Proprio perché è meglio focalizzarsi sulla risoluzione dei problemi, piuttosto che sui dettagli di basso livello (che NON sono indispensabili per arrivare a una soluzione), meglio iniziare con linguaggi di più alto livello e, soprattutto, che non ti facciano scontrare con certe problematiche astruse.

Hai parlato anche di cose semplici come scanf e printf, ma se dimentichi un & appiccicato al nome della variabile dovresti sapere che succede. Un disastro. E bug di questo tipo sono difficili da scoprire; ti fanno impazzire. Soprattutto sono bug specifici di un linguaggio povero come il C, e che ovviamente altri non hanno.

Non è un caso che per parecchi anni alle scuole sia stato insegnato il BASIC o il Pascal.

Oggi al MIT al corso introduttivo alla programmazione si usa Python.

Bisognerebbe chiedersi il perché di queste scelte.

P.S. Non è corretto affermare che la divisione per zero sia un errore, magari di distrazione. Può essere un comportamento voluto, e il risultato essere più o meno infinito, o un NaN.

Originariamente inviato da Tommo

Oooh ma quanto ci mancava il thread sull'imparare a programmare con epiche discussioni sul senso dell'informatica

Come ho già detto prima, non saremmo programmatori altrimenti.

[sottovento]

Originariamente inviato da GarudaOne

<CUT>

Insomma, quello che mi serverirebbe è fare un po' di chiarezza sulla situazione e ogni consiglio è ben accetto.

Grazie mille!

Adesso e' chiaro?

Se non e' chiaro, ti basta chiedere e ripetiamo tutto....

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Su questo siamo d'accordissimo. D'altronde è in cima al forum il mio suggerimento sul linguaggio che propongo come entry level, e non è Java.

Ritengo assurdo pensare che quel meglio (anche senza i molto) sia C# che è l'agglomerato di tutti i difetti dei linguaggi che l'hanno preceduto.

Mi dicessi F# se ne potrebbe anche parlare ma C# neanche per idea.

Circa la m@#, c'è un'altra divertente coincidenza . Io scriverei infatti:

Calendar time = new StringExt("31.3.2011").toDate();

Dubito di avere una semplificazione già sperimentata e infilata nella mia libreria personale per ogni problema tu possa aver incontrato tuttavia è sintomatico il fatto che alcuni "problemi" siano comuni (ti anticipo: non inveire contro swing, input/output, collections e riflessione perchè ho una batteria di precotti, avrei anche qualcosa sui database ma lì potresti effettivamente fregarmi perchè non sono tanto convinto del mio BeanStore, sebbene io lo usi ormai da tempo ).

La necessità di usare le classi anonime. Eh, lì qualcosa che sa di vecchio c'è. Uno non dovrebbe dire che sia un problema di codice perchè fa tutto l'ide (fun1, fun2, fun3 + tab e netbeans mi piazza la funzione) ma visivamente anche io ne sono un po' inorridito. Ogni tanto cerco di dargli un aspetto diverso, tipo scrivere:

new VFunction1<Integer>() { public void apply(Integer x) {
    ...codice
}};

Ma è un diverso grado di schifo. Mi piacerebbe poter scrivere:

(x: Integer) => codice

Sì. Mi piacerebbe quello che gli va dietro? Non ne sono tanto sicuro. Il fatto è che quando si inizia ad avere una forma contratta per le funzioni ti arrivano anche le funzioni di ordine superiore.

E quando arrivano quelle allora ti puoi aspettare che capiti questo:

(f: (a1) ⇒ (a2) ⇒ (a3) ⇒ (a4) ⇒ (a5) ⇒ b): (a1, a2, a3, a4, a5) ⇒ b

Aggiungi i generici (che in C# sono molto più complicati di Java, che già è esoterico sull'argomento, pur essendo stati scritti da un genio assoluto - lo possino...) e fai i tuoi conti.

guarda che anche in quel modo che usi tu se scrivi 31 marzo 2011 nel calendar e poi stampi subito dopo il risultato di ritrovi un bell'1 aprile 2011...
E un bug della madonna del genere in un linguaggio tra i piu' usati e' qualcosa di inconcepibile per me.
Per quanto riguarda le inner class per me i delegate e le lambda function sono un deciso passo avanti.

[PGI-Bis]

Ti sembra veramente possibile che ci sia un bug del genere nelle librerie standard?

Cosa c'è scritto nella documentazione di Calendar.MONTH?

Field number for get and set indicating the month. This is a calendar-specific value. The first month of the year in the Gregorian and Julian calendars is JANUARY which is 0; the last depends on the number of months in a year.

E' quindi una data valida quella che hai impostato?

calendar.setLenient(false);
calendar.setTime(2011, 3, 31);
calendar.getTime();

Cosa ti dice adesso calendar?

[birmarco]

Originariamente inviato da !fazz

peccato che sia quella la programmazione, i linguaggi vanno e vengono, sono solo delle regole per definire le azioni volute, portare un algoritmo in diversi linguaggi è facile se si hanno chiari i passaggi ed è questo che la scuola deve insegnare non la sintassi ma i concetti, per la sintassi basta la wrox

Si ok, però il concetto di algoritmo è alquanto banale. Il punto è come costruirsi il proprio algoritmo e il modo migliore per farlo è iniziare a scrivere in un qualche linguaggio

Originariamente inviato da cdimauro

Dovresti renderti conto che ciò di cui hai parlato finora attiene più che altro all'ingegneria, in particolare all'elettronica.

Da informatico i miei "padri spirituali" (per modo di dire, visto che sono ateo ) sono Muhammad ibn Mūsa 'l-Khwārizmī, George Boole, Alan Turing, Kurt Gödel, Alonzo Church, Stephen Kleene, e mi scuso coi matematici / logici che hanno contribuito e di cui non ricordo i nomi.

Ma non si parlava di "basi" dell'informatica?

Un algoritmo non è solo quello. Per fortuna. Se ti andassi a leggere la definizione, capiresti il perché.

Parliamo di condizioni (if, switch, ecc.) e iterazione (for, while, do, ecc.) che è meglio, perché sono concetti più generici.

Proprio perché è meglio focalizzarsi sulla risoluzione dei problemi, piuttosto che sui dettagli di basso livello (che NON sono indispensabili per arrivare a una soluzione), meglio iniziare con linguaggi di più alto livello e, soprattutto, che non ti facciano scontrare con certe problematiche astruse.

Hai parlato anche di cose semplici come scanf e printf, ma se dimentichi un & appiccicato al nome della variabile dovresti sapere che succede. Un disastro. E bug di questo tipo sono difficili da scoprire; ti fanno impazzire. Soprattutto sono bug specifici di un linguaggio povero come il C, e che ovviamente altri non hanno.

Non è un caso che per parecchi anni alle scuole sia stato insegnato il BASIC o il Pascal.

Oggi al MIT al corso introduttivo alla programmazione si usa Python.

Bisognerebbe chiedersi il perché di queste scelte.

P.S. Non è corretto affermare che la divisione per zero sia un errore, magari di distrazione. Può essere un comportamento voluto, e il risultato essere più o meno infinito, o un NaN.

Secondo me (e anche secondo chi ha creato i corsi i informatica ) una componente elettronica fa molto bene per capire cosa succede quando si scrive un determinato codice. Per scrivere un programma radicato nel sistema è necessario anche conoscere la macchina su cui si lavora

La & io non la vedrei così negatva, potrebbe essere utile a capire la differenza tra il passaggio parametri per valore e per indirizzo, entrando anche nel concetti di allocazione della memoria che secondo me sono importanti. Si a volte è difficile beccarla una & dimenticata ma se appunto si usa il C++ solo come inizio i programmi scritti saranno al più programmi di massimo 300 linee o giù di lì trovare la & dimenticata non è così difficile. Alla fine in C++ su SW semplici gli errori possono essere
- i ;
- le &
- mancate inizializzazioni
- graffe fuori posto

Altro non mi viene in mente... tra l'altro importando le librerie con un inizio di programma che può anche essere scritto senza capire perchè sia così si può avere un

printf("Hello World");

invece di un

System.out.printf("Hello World");

o peggio

System.out out = new System.out();
out.println("Hello World");

di Java

Molto più semplice da assimilare. E a maggior ragione uno

scanf("%i%i", &b, &b)

lo trovo molto più semplice di utilizzare classi, come ad esempio la Scanner, contenute in Java dove per leggere un valore da console ci vogliono parecchie righe di codice. Occore saper fare un assegnamento con new, e richiamare il metodo corretto. Con C++ basta sapere che si scrive scanf e all'inizio anche non sapere il perchè è così. In C++ la logica leggi dato con scanf, opera e stampa il risultato con printf lo trovo il metodo più semplice per iniziare

E' vero mi sono dimenticato dell'esistenza dei NaN

[gugoXX]

Quando si cerca in tutti i modi di salvare il passato perche' presente e futuro non piacciono piu', e' ora di estinugersi.

[Tommo]

E' un peccato però che scanf sia ANSI C, non C++
Sembra una pignoleria ma è importanterrimo concettualmente.

PS: se credi che C++ possa dare solo quegli errori su programmi semplici sei un sognatore
A me è capitato qualsiasi cosa, da main non trovato a linking contro librerie sbagliate a errori aritmetici.
Basta avere la giusta dose di sfortuna

@everyone: che piaccia o no, l'informatica ha due basi opposte e altrettanto importanti. Una è la matematica pura e la logica, l'altra è il "gretto hardware", assembly, C, e tutte quelle robbacce sporche e cattive.
L'unico modo per sapere veramente cosa si sta facendo è conoscerle tutte e due, e basta.
Non esiste che in Python si ignori le architetture HW o al contrario che in C si ignori cos'è un'algoritmo... è solo stupido.

[Kralizek]

piú che altro...

mio padre quando avevo 8 anni mi mise davanti al QBasic incluso con il dos.

se doveste fare qualcosa del genere con un vostro eventuale pargolo, cosa scegliereste?

sottolineo il "8 anni"

[cdimauro]

Originariamente inviato da birmarco

Si ok, però il concetto di algoritmo è alquanto banale. Il punto è come costruirsi il proprio algoritmo e il modo migliore per farlo è iniziare a scrivere in un qualche linguaggio

Anni fa per iniziare si utilizzavano pseudocodice e/o diagrammi di flusso.

Secondo me (e anche secondo chi ha creato i corsi i informatica ) una componente elettronica fa molto bene per capire cosa succede quando si scrive un determinato codice. Per scrivere un programma radicato nel sistema è necessario anche conoscere la macchina su cui si lavora

Assolutamente no. Dipende, al solito, dai requisiti dell'applicazione, che raramente prevedono la conoscenza di dettagli di basso livello.

In 6 anni e mezzo di utilizzo di Python le applicazioni che ho scritto funzionano praticamente ovunque, da Windows a Linux & co., dagli x86 agli ARM, e ho smanettato perfino con la PSP (c'è un porting non ufficiale).

La & io non la vedrei così negatva, potrebbe essere utile a capire la differenza tra il passaggio parametri per valore e per indirizzo, entrando anche nel concetti di allocazione della memoria che secondo me sono importanti.

Ma anche no. L'importanza è relativa esclusivamente al contesto.

Nel caso di C & compagnia di medio-basso livello è praticamente indispensabile. In altri linguaggi (come Python, appunto), l'allocazione e relativa deallocazione della memoria è del tutto trasparente.

Si a volte è difficile beccarla una & dimenticata ma se appunto si usa il C++ solo come inizio i programmi scritti saranno al più programmi di massimo 300 linee o giù di lì trovare la & dimenticata non è così difficile. Alla fine in C++ su SW semplici gli errori possono essere
- i ;
- le &
- mancate inizializzazioni
- graffe fuori posto

Altro non mi viene in mente...

Forse non hai realizzato applicazioni un po' più complesse, dove gli errori che avevo elencato prima si verificano, eccome. E vedi anche Tommo.

tra l'altro importando le librerie con un inizio di programma che può anche essere scritto senza capire perchè sia così si può avere un

printf("Hello World");

invece di un

System.out.printf("Hello World");

o peggio

System.out out = new System.out();
out.println("Hello World");

di Java

Molto più semplice da assimilare. E a maggior ragione uno

scanf("%i%i", &b, &b)

lo trovo molto più semplice di utilizzare classi, come ad esempio la Scanner, contenute in Java dove per leggere un valore da console ci vogliono parecchie righe di codice. Occore saper fare un assegnamento con new, e richiamare il metodo corretto. Con C++ basta sapere che si scrive scanf e all'inizio anche non sapere il perchè è così. In C++ la logica leggi dato con scanf, opera e stampa il risultato con printf lo trovo il metodo più semplice per iniziare

In Pascal:

WriteLn('Hello, World');
Read(b, b);

Come vedi, niente puntatori e nessuna possibilità di bug allucinanti. Il Pascal, tra l'altro, è più vecchio del C.

E' vero mi sono dimenticato dell'esistenza dei NaN

Originariamente inviato da Tommo

@everyone: che piaccia o no, l'informatica ha due basi opposte e altrettanto importanti. Una è la matematica pura e la logica, l'altra è il "gretto hardware", assembly, C, e tutte quelle robbacce sporche e cattive.
L'unico modo per sapere veramente cosa si sta facendo è conoscerle tutte e due, e basta.
Non esiste che in Python si ignori le architetture HW

Beh, io l'ho fatto e... le mie applicazioni (anche server che tutt'ora girano su architetture a 32 o 64 bit, mono o multicore, e macchine virtuali) funzionano lo stesso.

o al contrario che in C si ignori cos'è un'algoritmo... è solo stupido.

Che c'entra: il concetto di algoritmo è trasversale. Abbraccia qualunque linguaggio di programmazione.

Originariamente inviato da Kralizek

piú che altro...

mio padre quando avevo 8 anni mi mise davanti al QBasic incluso con il dos.

se doveste fare qualcosa del genere con un vostro eventuale pargolo, cosa scegliereste?

sottolineo il "8 anni"

Python + il suo modulo standard turtle, oppure PythonTurtle (un IDE apposito: installi e usi subito).

[PGI-Bis]

Originariamente inviato da Kralizek

piú che altro...

mio padre quando avevo 8 anni mi mise davanti al QBasic incluso con il dos.

se doveste fare qualcosa del genere con un vostro eventuale pargolo, cosa scegliereste?

sottolineo il "8 anni"

Dove andremo a finire con questi genitori progressisti

Quattro ceffoni e a letto senza cena, altro che programmazione!

Educazione del fanciullo, dal manuale Costanzo-Endemol:

8 - 12: scuola calcio*/**
12 - 13: pranzo davanti al grande fratello
13 - 16: corso di tronista
16 - 16.15: merenda davanti al grande fratello
16.15 - 18: scuola calcio*/**
18-19: libertà
19-20: cena (privare se colto a leggere libri*** nella fase precedente)
20-21: un'ora di televisione commerciale
21: tre ave maria filippi e poi a letto

*Sostituire con nuoto in caso di fanciulla.
**In alternativa tennis, ambosessi
***Eclusi oggi, gente, chi, novella 2000 e assimilabili

[Tommo]

Originariamente inviato da cdimauro

Beh, io l'ho fatto e... le mie applicazioni (anche server che tutt'ora girano su architetture a 32 o 64 bit, mono o multicore, e macchine virtuali) funzionano lo stesso.

Credo che per uno che scrive un'implementazione della VM di Python i "requisiti macchina" siano ormai assimilati, o no?
Di certo hai idea di che cosa succede dietro le quinte e sai usare Python senza stressare i limiti della VM su cui gira, e di conseguenza evitare i limiti della macchina.
Se uno non ha la più pallida idea di che cosa è pesante e che cosa no, non credo possa scrivere un'applicazione server, in nessun linguaggio

[pabloski]

Originariamente inviato da birmarco

Un informatico SA soprattutto su cosa sta lavorando. Infatti il corso di laurea in informatica inizia proprio con lo studio dei transistor, della loro combinazione nei circuiti logici e di come si costruisce una CPU a partire proprio dai transistor, bit dopo bit. Dal circuito somma alla ALU, ai registri, le memorie, il pipelining, il parallelismo e multicore, i bus, ecc... Partire più in basso di così non si può. Poi si passa all'assembly. Di pari passo viene insegnato il Java o più raramente il C. Ma il tutto lo si conmprende a fondo solo concludendo gli studi sugli elaboratori. E solo dopo tutto questo si passa a studiare algoritmi, database, ecc...

Chi non ha queste basi non può definirsi informatico. Un informatica di quel livello è indicata a chi fa altri lavori, come un matematico che si programma un SW che esegue un algoritmo. Un informatico che si rispetti sa su cosa sta programmando, sa come sfruttare le potenzialità del proprio HW dialogando con esso, se necessario inserendo blocchi di linguaggio macchina in un programa scritto in un linguaggio di alto livello.

Cmq per iniziare come autodidatta consiglio di partire in alto e poi lasciare all'università il compito di scendere nel dettaglio.

perfettamente d'accordo....all'università ti danno le basi sull'architettura dei calcolatori, ai miei e mi pare di capire anche ai tuoi tempi, ti davano anche basi di elettronica digitale e analogica

l'assembly, il c, ecc.... sono sulla stessa falsariga di quelle nozioni di base, nozioni che piaccia o no è obbligatorio avere per comprendere fino in fondo il funzionamento di questa benedetta macchina che poi andremo a programmare in java, python, basic o come ci pare

rimane però il fatto che la conoscenza delle basi permette di operare anche con linguaggi ad alto livello in maniera più cosciente e di realizzare ottimizzazioni che altrimenti sarebbero incomprensibili e giudicate superflue

voglio dire, c'è gente che in assembly sceglie xor eax,eax invece di mov eax,0 perchè la prima impiega meno cicli di clock e questo è diretta conseguenza di come quelle due istruzioni sono implementate nel processore....conoscerlo ti permette di programmare meglio

logicamente c'è il rovescio della medaglia e cioè la logica, l'algoritmo e quello è più un problema di impostazione mentale che di conoscenza tecnica e in questo caso è necessario sviluppare capacità logico/matematiche

un linguaggio ad alto livello aiuta in questo senso e permette di ragionare in termini algoritmici senza prestare attenzione ai dettagli....personalmente ho cominciato dal basic ( come ho già scritto in un post precedente ) e quindi penso che sia una buona soluzione ma solo ed esclusivamente per farsi le ossa nel pensare da informatico, poi bisognerà volenti o nolenti scontrarsi con la macchina e i suoi dettagli

[shinya]

Originariamente inviato da birmarco

Alla fine in C++ su SW semplici gli errori possono essere
- i ;
- le &
- mancate inizializzazioni
- graffe fuori posto

Altro non mi viene in mente...

Umh... dipende da quale 20% di C++ conosci...
Secondo te questo pezzo di codice cosa fa? Compila? Se no, perché?

#include <iostream>

struct A { int a; };

int main() {
  A var(A());
  std::cout << var.a << std::endl;
  return 0;
}

protip: Most Vexing Parse.

[birmarco]

Originariamente inviato da Tommo

E' un peccato però che scanf sia ANSI C, non C++
Sembra una pignoleria ma è importanterrimo concettualmente.

PS: se credi che C++ possa dare solo quegli errori su programmi semplici sei un sognatore
A me è capitato qualsiasi cosa, da main non trovato a linking contro librerie sbagliate a errori aritmetici.
Basta avere la giusta dose di sfortuna

@everyone: che piaccia o no, l'informatica ha due basi opposte e altrettanto importanti. Una è la matematica pura e la logica, l'altra è il "gretto hardware", assembly, C, e tutte quelle robbacce sporche e cattive.
L'unico modo per sapere veramente cosa si sta facendo è conoscerle tutte e due, e basta.
Non esiste che in Python si ignori le architetture HW o al contrario che in C si ignori cos'è un'algoritmo... è solo stupido.

I problemi possono essere molteplici ma io in C farei:

- Variabili e tipi
- Condizioni e iterazioni
- Funzioni
- Array
- Strutture
- Puntatori e liste con conseguente allocazione e pulitura della memoria
- Scrittura/lettura di file semplici

Sono le cose più semplici e utili a fare dei programmini di base come dei gestionali di un'ipotetica attività, se proprio non ci si vuole fermare all'odiosa area del quadrato. Si può pasticciare un po' con queste cose e al più decidere di andare anche oltre. Di problemi in queste cose direi che ce ne sono pochi, o meglio io non ho mai avuto problemi che non siano stati sviste mie nella scrittura del codice.

Originariamente inviato da cdimauro

Anni fa per iniziare si utilizzavano pseudocodice e/o diagrammi di flusso.

Assolutamente no. Dipende, al solito, dai requisiti dell'applicazione, che raramente prevedono la conoscenza di dettagli di basso livello.

In 6 anni e mezzo di utilizzo di Python le applicazioni che ho scritto funzionano praticamente ovunque, da Windows a Linux & co., dagli x86 agli ARM, e ho smanettato perfino con la PSP (c'è un porting non ufficiale).

Ma anche no. L'importanza è relativa esclusivamente al contesto.

Nel caso di C & compagnia di medio-basso livello è praticamente indispensabile. In altri linguaggi (come Python, appunto), l'allocazione e relativa deallocazione della memoria è del tutto trasparente.

Forse non hai realizzato applicazioni un po' più complesse, dove gli errori che avevo elencato prima si verificano, eccome. E vedi anche Tommo.

In Pascal:

WriteLn('Hello, World');
Read(b, b);

Come vedi, niente puntatori e nessuna possibilità di bug allucinanti. Il Pascal, tra l'altro, è più vecchio del C.

Si certamente dipende da cosa si vorrà andare a programmare. Io penso che la massima aspirazione per un programmatore sia lavorare alla stesura di un sistema operativo o cmq per una grossa SW house dove vengono scritti SW che devono essere ottimizzati al massimo. Il compilatore ha cmq i suoi limiti nell'ottimizzare

In C ho programmato per 3 anni alle superiori facendo davvero decine e decine di applicazioni sulle situazioni ipotetiche più assurde. Cmq il tutto era limitato al C base diciamo (poco più dei punti che ho elencato all'inizio di questo post) quindi di problemi non ne ho mai incontrati.
Quando ho dovuto fare il corso di Java all'università è stato mio in poche ore, giusto il tempo di imparare i concetti della programmazione ad oggetti. E questo grazie a C. Secoli fa mi sono messo ad imparare da solo il VB .Net da un libro che avevo in casa sul Visual Basic 6.0 che tra l'altro non è nemmeno .net. Ed era un libro per superiori... lascio immaginare Ho iniziato dopo aver letto il libro proprio a caso (e mi sto maledicendo) tramite Visual Studio a scrivere e ad imparare proprio così dai suggerimenti dell'autocompletamento. Diciamo che quando ho iniziato ero troppo stupido e volevo subito produrre qualcosa di utile. Ho cercato recentemente di rimettere in piedi una conoscenza adeguata a questo linguaggio che mi piace molto per chiudere i mega buchi che ho lasciato. Devo cmq dire che senza C sarebbe stato tutto molto più duro, imho.

Originariamente inviato da pabloski

perfettamente d'accordo....all'università ti danno le basi sull'architettura dei calcolatori, ai miei e mi pare di capire anche ai tuoi tempi, ti davano anche basi di elettronica digitale e analogica

l'assembly, il c, ecc.... sono sulla stessa falsariga di quelle nozioni di base, nozioni che piaccia o no è obbligatorio avere per comprendere fino in fondo il funzionamento di questa benedetta macchina che poi andremo a programmare in java, python, basic o come ci pare

rimane però il fatto che la conoscenza delle basi permette di operare anche con linguaggi ad alto livello in maniera più cosciente e di realizzare ottimizzazioni che altrimenti sarebbero incomprensibili e giudicate superflue

voglio dire, c'è gente che in assembly sceglie xor eax,eax invece di mov eax,0 perchè la prima impiega meno cicli di clock e questo è diretta conseguenza di come quelle due istruzioni sono implementate nel processore....conoscerlo ti permette di programmare meglio

logicamente c'è il rovescio della medaglia e cioè la logica, l'algoritmo e quello è più un problema di impostazione mentale che di conoscenza tecnica e in questo caso è necessario sviluppare capacità logico/matematiche

un linguaggio ad alto livello aiuta in questo senso e permette di ragionare in termini algoritmici senza prestare attenzione ai dettagli....personalmente ho cominciato dal basic ( come ho già scritto in un post precedente ) e quindi penso che sia una buona soluzione ma solo ed esclusivamente per farsi le ossa nel pensare da informatico, poi bisognerà volenti o nolenti scontrarsi con la macchina e i suoi dettagli

D'accordissimo su tutto! L'analogica però non c'è più Io l'ho fatta alle superiori per fortuna (qualcosina)

[birmarco]

Originariamente inviato da shinya

Umh... dipende da quale 20% di C++ conosci...
Secondo te questo pezzo di codice cosa fa? Compila? Se no, perché?

#include <iostream>

struct A { int a; };

int main() {
  A var(A());
  std::cout << var.a << std::endl;
  return 0;
}

protip: Most Vexing Parse.

E' una verifica?
iostream credo manchi di un .h, cmq non so cosa significhi la riga che inizia con std quindi e neanche A var(A()) l'ho mai visto, sembra tanto una dichiarazione di tipo A ma quel che viene dopo A non lo so identificare. Cmq questo o è una forma contratta che non ho mai visto oppure fa parte di un C che non è proprio quello base che si insegna per primo. Il mio "imparare il C" non voleva dire impararlo tutto, solo le basi basi per pasticciare sulla logica di programmazione

[marco.r]

Originariamente inviato da Kralizek

piú che altro...

mio padre quando avevo 8 anni mi mise davanti al QBasic incluso con il dos.

se doveste fare qualcosa del genere con un vostro eventuale pargolo, cosa scegliereste?

sottolineo il "8 anni"

Forse per gli 8 anni e' ancora un po' complicato, ma prova a dare una occhiata a Scratch ( http://scratch.mit.edu/ )

[WarDuck]

Originariamente inviato da birmarco

Scusa ma iniziare col parlare di algoritmo è un po' troppo base... credo che chiunque voglia imparare da solo a programmare sappia che lo fa per ottenere qualcosa: da un input ottengo un output tramite una serie di passaggi.
[..]

Fidati che rivedere il concetto di algoritmo assimilandolo ad una macchina di Turing ti farebbe cambiare idea

Preferirei far fare ai ragazzi 10 corsi di algebra e logica (che non conoscono) piuttosto che iniziare il corso di laurea in informatica o ingegneria informatica parlando di transistor .

Volendo passare al lato oscuro (quello del formalismo integralista) per alcuni neanche bisognerebbe introdurre il concetto di ciclo senza aver dato prima il concetto di invariante

Comunque preferirei che ci si concentrasse sulle tecniche per scrivere codice corretto, introducendo anche delle metodologie di testing (cosa che alla triennale si vede poco, o almeno per me è stato così).

[birmarco]

Originariamente inviato da marco.r

Forse per gli 8 anni e' ancora un po' complicato, ma prova a dare una occhiata a Scratch ( http://scratch.mit.edu/ )

Non mi ricordo da quale età si sviluppa la capacità di astrazione ma è sicuramente superiore agli 8 anni. Credo sia molto dura imparare a programmare a quell'età

[Tommo]

Originariamente inviato da birmarco

E' una verifica?
iostream credo manchi di un .h, cmq non so cosa significhi la riga che inizia con std quindi e neanche A var(A()) l'ho mai visto, sembra tanto una dichiarazione di tipo A ma quel che viene dopo A non lo so identificare. Cmq questo o è una forma contratta che non ho mai visto oppure fa parte di un C che non è proprio quello base che si insegna per primo. Il mio "imparare il C" non voleva dire impararlo tutto, solo le basi basi per pasticciare sulla logica di programmazione

Non è C, è C++. std è un namespace, cout è un'istanza statica di una classe e iostream sta bene senza la sua .h

Io sinceramente lascerei stare discorsi su come insegnare agli altri se ancora non si è imparato... io smanetto in C/C++ da 6 anni e ancora imparo roba a vagonate.
E' vero che all'inizio i risultati sono più rapidi, ma non ti offendere se ti dico che quello che hai imparato non è nemmeno l'inizio, ed è tutto tranne che utile

[birmarco]

Originariamente inviato da WarDuck

Fidati che rivedere il concetto di algoritmo assimilandolo ad una macchina di Turing ti farebbe cambiare idea

Preferirei far fare ai ragazzi 10 corsi di algebra e logica (che non conoscono) piuttosto che iniziare il corso di laurea in informatica o ingegneria informatica parlando di transistor .

Volendo passare al lato oscuro (quello del formalismo integralista) per alcuni neanche bisognerebbe introdurre il concetto di ciclo senza aver dato prima il concetto di invariante

Comunque preferirei che ci si concentrasse sulle tecniche per scrivere codice corretto, introducendo anche delle metodologie di testing (cosa che alla triennale si vede poco, o almeno per me è stato così).

Che odio la macchina di Turing!! proprio tra le parti che odio di più!