Ho bisogno di un po' di chiarezza

[Kralizek]

Originariamente inviato da jappilas

io invece sfido chiunque a dimostrare che a chi parte dal basic la conoscenza degli internals del sistema è necessaria...

se parti(vi) dal basic significa(va) che sta(v)i acquisendo familiarità con la programmazione e formando una mentalità algoritmica (quella che a partire da un problema elabora i passaggi che portano alla soluzione) su un linguaggio concreto ancorchè semplice quindi didattico dopo essere passato per lo pseudocodice - praticamente riformulando in un linguaggio interpretabile dalla macchina quella che prima era una routine per il calcolo del fattoriale o la stampa di "ciao mondo", solamente su carta...
capisci anche tu che chi iniziava a programmare dal basic ( adesso per lo stesso motivo si userebbero linguaggi più chiari e semplici, quindi migliori di basic allo stesso scopo per cui basic era usato) non necessitava della conoscenza degli internals, per il semplice motivo di operare a un livello concettuale svariati piani al di sotto di essi...
mentre chi programma in C sfruttando api di sistema e magari facendo dell' utilizzo corretto ed efficiente di queste il fulcro del design dell' algoritmo del suo programma, è già a conoscenza (acquisita da manuali, libri, magari corsi universitari in architetture sw) delle differenze e idiosincrasie tra open, close, fopen, fclose, sync, fsync e fllush, di quali chiamare e quando, ecc ecc - quindi di quelli che sono gli internals della piattaforma, quantomeno per quel che l' implementazione sottostante inficia la semantica delle api programmatiche
a ciò aggiungi che spessoe volentieri esistono api di sistema riferite a meccanismi (vedi caso, la memoria condivisa) la cui implementazione può essere trasparente praticamente a chiunque, a parte chi li implementa...
perfino nella prospettiva dello sviluppatore di servizi di sistema che girino in userspace (che quindi non abbia titolo a mettervi le mani ma solo ad appoggiarsi alle api ad esso dedicate) il sapere che a basso livello quel meccanismo "esista", può essere solo una curiosità, una conoscenza in più che comunque non è C a dare, ma eventualmente documentazione della piattaforma
se poi anche le chiamate necessarie per sfruttarlo sono trasparentemente incapsulate in una libreria standard, può tranquillamente passare inosservato a chiunque (compreso il programmatore C esperto) non vada a documentarsi proprio su di esso ...

quoto ogni singola parola.

[pabloski]

Originariamente inviato da jappilas

io invece sfido chiunque a dimostrare che a chi parte dal basic la conoscenza degli internals del sistema è necessaria...

in pratica un informatico sa impostare algoritmi ma non sa com'è fatto un calcolatore?

se parti(vi) dal basic significa(va) che sta(v)i acquisendo familiarità con la programmazione e formando una mentalità algoritmica (quella che a partire da un problema elabora i passaggi che portano alla soluzione) su un linguaggio concreto ancorchè semplice quindi didattico dopo essere passato per lo pseudocodice - praticamente riformulando in un linguaggio interpretabile dalla macchina quella che prima era una routine per il calcolo del fattoriale o la stampa di "ciao mondo", solamente su carta...
capisci anche tu che chi iniziava a programmare dal basic ( adesso per lo stesso motivo si userebbero linguaggi più chiari e semplici, quindi migliori di basic allo stesso scopo per cui basic era usato) non necessitava della conoscenza degli internals, per il semplice motivo di operare a un livello concettuale svariati piani al di sotto di essi...

ecco appunto, operi ad un livello più alto, totalmente concettuale ma ignori completamente cosa c'è sotto il cofano

certo se nella vita si andrà a buttare fuori gestionale dopo gestionale questo basta, ma per qualsiasi cosa un pò più complessa e/o legata all'hardware ti blocchi

per la cronaca io ho cominciato proprio col basic, il basic v2 del c64, poi il gwbasic del dos, qbasic, quickbasic, pascal e poi il resto

sapevo programmare ma ignoravo totalmente che quel codice che io scrivevo si traduceva anche in comandi inviati alle più svariati subunità presenti nel mio calcolatore, a partire dal pic fino all'alu, gpu, southbridge, ecc...

ignoravo cose come i timings coinvolti nella programmazione delle varie periferiche, ignoravo il fatto che il tutto si traduceva in byte e word inviate ai registri dei vari chip

chi vuol'essere SOLO programmatore magari può ragionare così, chi vuol'essere informatico non può ignorare come funziona la macchina

perfino nella prospettiva dello sviluppatore di servizi di sistema che girino in userspace (che quindi non abbia titolo a mettervi le mani ma solo ad appoggiarsi alle api ad esso dedicate) il sapere che a basso livello quel meccanismo "esista", può essere solo una curiosità, una conoscenza in più che comunque non è C a dare, ma eventualmente documentazione della piattaforma

in generale sapere che un meccanismo esiste non basta perchè in informatica ogni meccanismo non è perfetto ed è frutto di una serie di compromessi

conoscere quei compromessi permette di sviluppare software ottimizzato e questo fa la differenza tra un programmatore qualunque e un drago della programmazione

se poi anche le chiamate necessarie per sfruttarlo sono trasparentemente incapsulate in una libreria standard, può tranquillamente passare inosservato a chiunque (compreso il programmatore C esperto) non vada a documentarsi proprio su di esso ...

tutto ok ma parliamo sempre di gente che andrà ad usare qualcosa che già c'è, così come c'è l'imprenditore che guida la mercedes ma non sa ovviamente un'acca di meccanica

il punto è che noi altri siamo informatici e non possiamo ignorare come funzionano le macchine che programmiamo

non sarebbe bello avere a che fare con un medico che dice "io so solo come si usa il defibrillatore ma poi non ho la più pallida idea di quali effetti induca sul cuore"

[birmarco]

Originariamente inviato da GarudaOne

Sono uno studente di IV di ITC corso Mercurio (Programmatori).

A scuola usiamo Visual Basic, versione del 2003... Non capisco perchè si rifiutino di installare l'ultima versione express che è gratuita Vabè, questo è un altro discorso, lasciamo perdere, và...

Il punto è questo: dato che credo proprio che noi stiamo programmando in un modo assai obsoleto, ed anche sul libro che ho io, un libro scolastico della Tramontana, noto che il metodo di programmazione, e la sintassi e le parole chiave utilizzate sono abbastanza diverse rispetto a quanto quello che facciamo realmente.
La mia intenzione è quella di sfruttare le prossime vacanze e ricominciare da capo lo studio teorico e pratico sui libri che posseggo, con l'ausilio di internet.
Ovviamente Visual Basic .Net. Credo che sia un buon punto di partenza.

Vorrei dei consigli anche in ottica universitaria: vorrei frequentare la facoltà di ingegneria informatica o ingegneria elettronica (più la prima che la seconda).
So che probabilmente il Visual Basic all'università sarà utilizzato raramente, quindi prima o poi comincierò a dare un'occhiata al linguaggio C. Poi il resto lo farò lì, lì all'università, come Java, C#, C++, ASP.NET, PHP, Python, Cobol e eccetera - ovviamente buona parte sarà da autodidatta. Tanto una volta imparato il concetto di programmazione, il resto sta nell'imparare sintassi e parole chiave di quel determinato, o sbaglio?

Ricapitolando, a breve ricomincierò da capo, dalla teoria e visual basic .NET utilizzando la versione express, e prima dell'università getterò qualche fondamenta per il linguaggio C.

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

Grazie mille!

Io ti consiglio di studiarti le basi del C++, è piuttosto semplice e iniziare con le applicazioni in console ti aiuta a comprendere gli elementi fondamentali e la logica di base della programmazione. Sono applicazioni al più inutili ma che ti daranno sicuramente il modo di pensare da programmatore. Pensare a 2 cicli for innestati per svolgere anche un'operazione stupida non è una cosa così immediata per chi si è appena affacciato la programmazione. Se hai fatto VB 2003 sicuramente qualcosa avrai già, io ti consiglio cmq di partire con quello

Poi puoi passare a Java, che è "simile" all'apparenza e utilizzarlo sarà più familiare. Così apprendi bene cosa vuol dire programmare ad oggetti.

Poi puoi proseguire con VB.Net oppure C# .Net a seconda di quale preferisci a pelle. Magari il C# dopo Java e C++ ti sarà più familiare. Io invece preferisco il VB

L'importate è avere delle basi solide altrimenti non capirai mai cosa stai facendo. Se ti interessa programmare io eviterei ingegneria elettronica. Potresti anche valutare informatica (non ingegeria)

Tieni conto che i linguaggi .net limiteranno le tue aplicazioni in windows

PS. Verifica che per gli studenti della tua scuola sia disponibile Visual Studio Professional 2010 gratuito su MS Dreamspark

[Efem]

Io a scuola superiore (indirizzo informatica) ho fatto praticamente solo pascal per tre anni (i primi due erano "comuni", poi si sceglieva l'indirizzo).
In quinto anno ho fatto anche un pò di C++ (senza arrivare alla programmazione grafica).
Questo mi ha permesso all'università (Sempre informatica) di essere molto agevolato per esami come programmazione, ingegneria del sw, ecc.

Sembra strano dirlo, ma il linguaggio che mi ha preso più degli altri è stato l'assembly... sì, quello dove per fare qualcosa devi fare ottomila MOV.
Per mia sfortuna sono riuscito ad arrivare solo alla creazione dei file, visto che il corso universitario si fermava prima, non ho mai trovato un buon libro e, soprattutto, imparare un linguaggio così richiede un bel pò di tempo che io non ho.

Posso darti una sincera opinione però: Qualsiasi linguaggio deciderai di imparare, non usare editor visuali.
Mi pare ovvio che il programma non è quello che vedi, ma per me meglio farsi sempre tutto con le proprie manine... poi non sò, ditemi pure che perdo solo tempo...

Vorrei concordare con chi diceva che C e C++ costituiscono le fondamenta della programmazione, secondo me sono i primi due linguaggi che andrebbero imparati.
Non concordo con chi dice che ormai non sono più in uso: per me è il contrario.
Poi, se con C ti fermi a scrivere nella console...

C#, VB.NET, ASP.NET, e tutto il .NET Framework li farei volentieri sparire dalla circolazione.
Li uso solo per motivi di studio, diciamo però che mi fanno un bel pò ribrezzo.
Ho trovato molto interessanti invece le librerie Qt basate su C++, compilate e multipiattaforma.

Poi ricordati una cosa: il programma non basta "farlo", va anche fatta una adeguata manutenzione e per fare una adeguata manutenzione, devi metterti in condizioni di dividere i compiti di ciascun componente fin dal primo momento.
Tutte cose che, comunque, ti verranno insegnate per bene all'università.

[WarDuck]

Secondo il mio modesto parere al giorno d'oggi inizierei con linguaggi di più alto livello (ma non troppo), in particolare partendo subito dalla programmazione ad oggetti.

Il candidato ideale IMHO era e rimane ancora Java, principalmente per due motivi:

- gestione della memoria a carico della VM
- linguaggio fortemente tipato (per cui ho una certa preferenza)

E aggiungo anche tra questi il fatto che la sua diffusione è tale per cui vale decisamente la pena impararlo.

La gestione della memoria automatica consente inizialmente di non preoccuparsi con dettagli di basso livello e di concentrarsi solo ed esclusivamente sul problema (cosa secondo me fondamentale per avere una giusta forma-mentis).
Avere un linguaggio tipato poi da un'idea delle problematiche sui tipi, che ci sono nella maggior parte dei linguaggi di programmazione (anche dinamici), e può servire come trampolino di lancio per imparare altri linguaggi.

Iniziare subito con le classi poi rende secondo me il tutto più "concreto". Inoltre ciò dà la possibilità di mostrare la libreria di classi di cui dispone il linguaggio (cosa altrettanto fondamentale per un utilizzo proficuo del linguaggio) e mostrare anche come si realizzano quelle classi.

Una volta approcciato in questo modo, si ha anche la giusta visione per realizzare software in C che sia "orientato agli oggetti" anche senza avere a disposizione gli strumenti per farlo!

Riguardo la questione dell'IDE, può andare bene non usarlo per i primi programmi "Hello World"... ma man mano che vai avanti è necessario (sfido chiunque di voi a rinunciare a feature come l'auto-completamento).

Specie se si vuole introdurre anche qualche cosa sul debugging (di cui nessuno ha parlato e su cui andrebbe speso tempo).

Tutto ciò ovviamente non significa non approcciarsi poi con C/C++, ma secondo me è essenziale prima capire i concetti e poi il codice.

Ciò non toglie che oggi come oggi se dovessi fare un software di una certa complessità andrei senza dubbio su Python.

[birmarco]

#Post eliminato#

Uno alla volta! Ti prendi un buon libro e segui quell'ordine!

[WarDuck]

Originariamente inviato da D-3BO

...

Se leggi bene ho scritto anche "come"...

Io partirei prima dai concetti relativi all'object oriented (Classi, Tipi di accesso, public, private, protected, Metodi e quindi funzioni, Classi Astratte, Ereditarietà) e poi andrei a definire meglio gli altri concetti man mano che questi si presentano.

Una cosa su cui purtroppo si da poco conto, specie all'inizio, sono i vari concetti che si riprendono anche nell'UML, come Aggregazione o Composizione, che spesso generano confusione tra gli studenti alle prime armi (quindi meglio fornire questi concetti, abbastanza semplici dopotutto, subito quando si parla di Classi).

A questo punto farei esempi di applicazioni dei concetti, facendo implementare ad esempio le varie relazioni Studenti-Corsi-Esami e quant'altro applicando tutto ciò che si è visto e anche di più.
Così facendo quando esce la necessità di creare delle collezioni di oggetti introdurrei i concetti di Lista, Vettore e quant'altro, mostrando come anche queste siano fondamentalmente classi (almeno nei linguaggi OO).
Questo dà l'occasione di introdurre i concetti di ciclo e di iteratore.

I template sono una di quelle cose che in C++ è fatta veramente da cani, li farei per ultimo onde generare confusione sulla sintassi.

Questo almeno è quello che farei io se dovessi spiegare a qualcuno i concetti (e ribadisco che escluderei C++ inizialmente, per la sua sintassi orrenda e le implicazioni derivanti dalla gestione della memoria "manuale").

[jappilas]

Originariamente inviato da pabloski

in pratica un informatico sa impostare algoritmi ma non sa com'è fatto un calcolatore?

si parlava di chi programma in BASIC (che difficilmente si può definire "informatico)", l' informatico (che difficilmente si mette a programmare in BASIC) lo stai tirando fuori ora

informatica o ing. informatica si studia all' università, ma impostare algoritmi non significa essere un informatico, è qualcosa che si impara a scuola (medie o superiori, o anche prima), come il 2+2

moving the goalposts much?

per la cronaca io ho cominciato proprio col basic, il basic v2 del c64, poi il gwbasic del dos, qbasic, quickbasic, pascal e poi il resto

sapevo programmare ma ignoravo totalmente che quel codice che io scrivevo si traduceva anche in comandi inviati alle più svariati subunità presenti nel mio calcolatore, a partire dal pic fino all'alu, gpu, southbridge, ecc...

quindi all' epoca quando digitavi i listati basic e pascal, non ti interessava in cosa venissero tradotti internamente e come venissero eseguiti - quel che ti interessava in quel momento era solo che fossero disegnate le righe colorate, si muovesse lo sprite, venisse calcolato il fattoriale o del momento, o che altro...
non c'è niente di male nel non sapere i dettagli del funzionamento di uno strumento che si usa in un dato momento, anzi... però, se ti fosse davvero interessato ti saresti informato già all' epoca e adesso non saresti qui a rinfacciare i tuoi rimpianti

chi vuol'essere SOLO programmatore magari può ragionare così, chi vuol'essere informatico non può ignorare come funziona la macchina

spero non serva ricordarti qual' era il discorso originale, stai virando nel solito flame informatico vs utente (o utonto)

in generale sapere che un meccanismo esiste non basta perchè in informatica ogni meccanismo non è perfetto ed è frutto di una serie di compromessi

non hai afferrato il senso di quel discorso - i compromessi non c' entravano nulla, perchè mi riferivo alla separazione tra il creatore di un design e il consumatore di un design e di una api al di là della perfettibilità degli stessi

se io sviluppo un kernel, implemento un meccanismo (mettiamo la shared memory) e lo esporto con una certa api (mettiamo la libreria shmem), un altro programmatore può a quel punto scambiare dati tra la propria ed altre applicazioni o servizi in modo efficiente passando per i metodi della mia api

api che dal momento in cui è resa pubblica, non può più essere modificata - così come l' implementazione sottostante non può essere alterata se ciò implica rompere un comportamento atteso dalle applicazioni sviluppate per quella api

e potrebbe ben limitarsi a sapere dell' esistenza del meccanismo e ad usare la API, per il semplice motivo che comunque (nemmeno qualora fosse un programmatore migliore di me) non potrebbe intervenirvi nemmeno in senso migliorativo

conoscere quei compromessi permette di sviluppare software ottimizzato e questo fa la differenza tra un programmatore qualunque e un drago della programmazione

un drago della programmazione sarebbe anche capace di progettare e implementare un proprio sistema operativo con meccanismi più raffinati
il problema è che un tale sistema avrebbe molto probabilmente un' utenza di un solo elemento (lui stesso) per un certo tempo, quindi per la maggior parte dovrà probabilmente sviluppare per OS scritti da altri, miseri mortali
in quei casi dovrà piegarsi alle loro scelte e convenzioni pur con ogni probabilità non condividendole, e appoggiarsi supinamente alle loro API, pur non gradendone il design

[cdimauro]

Originariamente inviato da pabloski

intanto continuano ad essere i più diffusi, i più performanti

Questo non c'entra niente con quello che avevi scritto prima. Non cercare di confondere le acque tirando in ballo altri discorsi.

e i più educativi per chi vuole capire come funziona veramente un calcolatore

Se è questo l'obiettivo, posso suggerirti di studiare un po' di fisica teorica. Da lì in poi potrai, mano a mano, salire di astrazione, e capire meglio come funziona tutto (quindi compreso un calcolatore).

sfido chiunque a capire gli internals di un calcolatore partendo dal basic

Il C non è molto distante dal BASIC da questo punto di vista.

Per maggiori informazioni, dai una rinfrescata a questo articolo che ho scritto tempo fa.

Originariamente inviato da pabloski

tecnicamente c# o meglio .net lo è, salvo poi restare vittima del marketing e delle scelte da "siamo gli Dei dell'informatica" di Redmond

Il tuo cieco fanatismo trasuda da tutti i pori.

dipende dalle necessità ovviamente e imho la disponibilità di immense quantità di librerie è uno dei punti forti di java

E' anche il suo punto debole. In particolare mi riferisco alla dotazione standard.

il punto è che il c++ lo troverai sempre, prima o poi durante gli studi o durante il lavoro incapperai in qualcosa scritto in c++ o sarai costretto a scrivere qualcosa in c++

Se è fortunato, magari no. In ogni caso, semmai dovesse avere questa sfortuna, potrà farsi una cultura in quel momento, e non prima (YAGNI).

poi rimane il fatto che c e c++ sono i modelli da cui partono i vari java, c#, php, javascript, objective-c

la conoscenza almeno del c ti permette di avere un'idea molto chiara di come funzionano le cose sotto il cofano anche dei linguaggi più evoluti e ovviamente ti facilita la comprensione della sintassi e del modus operandi degli altri linguaggi da esso derivati

Ma proprio no. C e C++ sono linguaggi per i fatti loro. Se devi imparare un linguaggio come Java, impari quello e basta, senza perdere tempo a studiarti le idiosincrasie dei primi, e soprattutto gli incubi che si portano dietro.

Originariamente inviato da PGI-Bis

Di concreto cos'ha portato? Direi la combinazione delle caratteristiche più facili da usare dei linguaggi precedenti (staticamente tipato come C, orientato agli oggetti con macchina virtuale e garbage collecto come smalltalk) e il supporto sia all'eredità che all'estensione, conditi dalla totale gratuità.

Forse non ci siamo capiti. Io parlavo di innovazioni portate dal linguaggio. Cioè funzionalità che non erano presenti in altri prima della sua introduzione.

Forse i più giovani non si ricordano la guerra degli IDE ma se oggi usate Visual C++ gratuitamente dovete accendere un cero alla memoria di Sun Microsystem e della piattaforma Java.

Mah. Il mio primo IDE è stato il Turbo Pascal 3.0 della Borland, ma da lì alle motivazioni che hanno portato Microsoft a rilasciare la versione Express (gratuita) di Visual Studio mi son perso qualcosa.

"Originali" in effetti non ci stava, avrebbe dovuto essere "generali". C# è pieno di eccezioni. I tipi dinamici, gli attributi, i metodi virtuali, gli indicizzatori, i delegati, le strutture e via dicendo. Sono tutti "ma".

Io capisco che tu hai una visione particolare della questione, ma in tutta onestà mi sfugge quale sarebbe il problema in questo caso.

Cosa intendi per eccezioni (non quelle che conosciamo usualmente ovviamente) e perché rappresenterebbero un problema?

Scala mi piace perché non è un minestrone. Sai che io ho questa mia idea stramba dell'orientamento agli oggetti e sebbene dica che scala è post-funzionale, in accordo all'opinione diffusa - segretamente lo considero orientato agli oggetti e in quanto tale funzionale - perché le funzioni non sono valori speciali ma normali istanze di classi.

Con me, lo sai, trovi una porta spalancata, perché in Python tutto è un'istanza di una classe (anche le classi stesse), e tramite un sapiente utilizzo è possibile "simulare" qualunque paradigma.

Però è un concetto un po' tirato. Ti ricordi quando in passato parlavi di guardare il codice soltanto secondo la prospettiva a oggetti, funzionale, o strutturata? Ed esaltavi questo fatto.

Scala da questo punto di vista ti consente di scrivere codice che è possibile guardare secondo la prospettiva a oggetti, oppure soltanto secondo quella funzionale, o ancora "miscelando" le altre due.

Però adesso Scala va bene...

Java non ha un preprocessore nello stesso senso di C++ o C#, cioè un programma che opera una trasformazione del codice sorgente prima della compilazione, il che rende il codice sorgente più un'indicazione di massima che qualcosa di concreto, ma ha le annotazioni. E' vero che si possono usare le annotazioni per trasformare il codice sorgente prima della compilazione ma è un uso secondario, né più né meno di quanto potrebbe farsi anche senza annotazioni (esistono se non sbaglio dei preprocessori anche per Java). E comunque per me le annotazioni sono stata una stronz... ma servivano per i programmatori EE.

OK, però anche con le annotazioni il risultato è proprio quello di compilare o meno in maniera condizionata determinate parti di codice.

Tra l'altro le annotazioni sono diventate la via maestra, a quanto pare, per questo genere di operazioni.

Concordo sul fatto che Java, quantomeno a vedere i discorsi che si fanno sui blog, stia lentamente derivando verso C#. Spero che accada il più tardi possibile. In ogni caso mi resta Scala.

Lo so, lo so.

Ma forse ci stiamo invischiando nell'ennesima language war?

Siamo programmatori, no? Il mio linguaggio è sicuramente meglio del tuo. Vedi avatar.

A parte gli scherzi, da pythonista mi diverto a vedere scannarsi i fratelli / cugini di C & derivati, e non me ne frega più di tanto.

Anche perché per la legge del contrappasso ho goduto troppo con Python e il mio futuro è sostanzialmente rappresentato da C#, Objective-C, Java, e ActionScript. Per cui vale poco "difendere" l'uno o altro, se non per questioni puramente pragmatiche. Insomma, di questi mi piacerà quello che mi renderà più produttivo e con meno mal di testa. Poi della filosofia / ideologia non me ne può fregar di meno, perché il mio linguaggio preferito (al momento) rimane sempre Python, e non c'è speranza, dopo 29 anni di programmazione, che un linguaggio C-like possa piacermi.

Originariamente inviato da pabloski

in pratica un informatico sa impostare algoritmi ma non sa com'è fatto un calcolatore?

Beh, certo che lo sa: c'è la CPU, la memoria, e le periferiche.

La CPU esegue programmi, usa la memoria per contenerli (assieme ai dati), ed eventualmente si collega con le periferiche per gestire l'input o l'output.

E il tutto... senza bisogno di conoscere il C.

ecco appunto, operi ad un livello più alto, totalmente concettuale ma ignori completamente cosa c'è sotto il cofano

certo se nella vita si andrà a buttare fuori gestionale dopo gestionale questo basta, ma per qualsiasi cosa un pò più complessa e/o legata all'hardware ti blocchi

Non è la complessità che spaventa. Anzi, più si astrae, e meno spaventa.

Solo per determinate operazioni di basso livello POTREBBE essere un limite, nel caso in cui un linguaggio non abbia costrutti linguistici o funzioni allo scopo.

Ma è cosa che riguarda anche il C. Il mio articolo di cui ti ho fornito il link, commenti inclusi, è piuttosto eloquente sulla questione.

per la cronaca io ho cominciato proprio col basic, il basic v2 del c64, poi il gwbasic del dos, qbasic, quickbasic, pascal e poi il resto

sapevo programmare ma ignoravo totalmente che quel codice che io scrivevo si traduceva anche in comandi inviati alle più svariati subunità presenti nel mio calcolatore, a partire dal pic fino all'alu, gpu, southbridge, ecc...

ignoravo cose come i timings coinvolti nella programmazione delle varie periferiche, ignoravo il fatto che il tutto si traduceva in byte e word inviate ai registri dei vari chip

chi vuol'essere SOLO programmatore magari può ragionare così, chi vuol'essere informatico non può ignorare come funziona la macchina

Purtroppo chi non ha idea di cosa sia l'informatica sei tu, che riduci tutto a questa dicotomia sbagliata.

Vedi, prima parlavi di byte, di word. Ti sei mai chiesto quanto vale una word? 8, 16, 32, ecc. bit?

E' necessario saperlo? No.

L'unico comandamento a cui siamo votati noi informatici, programmatori inclusi (ma ne parlo dopo), è quello di algoritmo. Che non prevede obbligatoriamente la conoscenza di dettagli di basso livello.

L'informatica nasce dalla contrazione di due parole: informazione e automatica. Va da sé si arriva presto al concetto di algoritmo, e da lì a quello di risoluzione di un problema tenendo conto di precisi requisiti.

Tra l'altro in inglese si parla di computer science, e computer scientist. Non ci sono due figure distinte, quali l'informatico e il programmatore, e a buon ragione.

A meno che non entriamo nel gergo popolare, dove per informatico s'intende una persona che s'interessa di informatica. Insomma, anche assemblare un PC.

E' talmente generico come termine, che può rientrarci di tutto. Ed è inutile che dire non c'è alcun vincolo alla conoscenza di dettagli di basso livello.

in generale sapere che un meccanismo esiste non basta perchè in informatica ogni meccanismo non è perfetto ed è frutto di una serie di compromessi

conoscere quei compromessi permette di sviluppare software ottimizzato e questo fa la differenza tra un programmatore qualunque e un drago della programmazione

Al più ciò che hai scritto permette di capire che non hai idea di cosa debba fare un programmatore. Cioè (rullo di tamburi): risolvere problemi.

Parlare di ottimizzazione senza nemmeno sapere se è necessario oppure no, è prematuro, come ha detto il buon Knuth:
Premature optimization is the root of all evil - Donald Knuth

E, manco a dirlo, ottimizzare non è nemmeno sinonimo di basso livello. Un buon programmatore, infatti, prova sempre la via algoritmica se il codice che ha scritto non soddisfa EVENTUALI (lo rimarco) requisiti prestazionali.

Se questo non dovesse andare bene, si passa a un livello più basso.

tutto ok ma parliamo sempre di gente che andrà ad usare qualcosa che già c'è, così come c'è l'imprenditore che guida la mercedes ma non sa ovviamente un'acca di meccanica

il punto è che noi altri siamo informatici e non possiamo ignorare come funzionano le macchine che programmiamo

non sarebbe bello avere a che fare con un medico che dice "io so solo come si usa il defibrillatore ma poi non ho la più pallida idea di quali effetti induca sul cuore"

Con questo metro di paragone (ovviamente errato) non sarebbe nemmeno bello che un programmatore non sappia com'è fatto il compilatore che usa e come ottimizza il codice. Dovrebbe sapere anche com'è fatto il s.o. che usa.

Ecco, io immagino già un povero programmatore che va a spulciarsi i sorgenti del kernel o, peggio ancora, se li va a disassemblare per vedere com'è implementata la fopen. Sia mai che debba utilizzare un defibrillatore senza sapere com'è fatto...

Beh, non basterebbe una vita per avere piena conoscenza di TUTTO.

E siccome è del tutto inutile sapere com'è fatto un defibrillatore, ma saperlo utilizzare invece è fondamentale (e per saperlo usare bisogna anche sapere in quali condizioni e quali effetti ha o potrebbe avere), io penso che sia sufficiente fermarsi a questo livello per svolgere bene il proprio lavoro.

Che poi è quello che ci si aspetta da un buon medico. Altrimenti avrebbe fatto l'ingegnere per progettare quell'apparecchio.

Sennò non facciamo mettere un piede nell'abitacolo ad Alonso se non ha conseguito una laurea in ingegneria meccanica, una in elettronica, e un'altra in informatica (maledetta informatica: la infilano dappertutto ormai)...

Originariamente inviato da birmarco

Io ti consiglio di studiarti le basi del C++, è piuttosto semplice e iniziare con le applicazioni in console ti aiuta a comprendere gli elementi fondamentali e la logica di base della programmazione.

Che sarebbero? No, perché a questo punto mi sfugge veramente quali sarebbero queste fantomatiche "basi" della programmazione.

C'è qualcuno che è in grado di darmene una definizione oggettiva e incontrovertibile.

Io sono fermo qui: http://it.wikipedia.org/wiki/Algoritmo

Sono applicazioni al più inutili ma che ti daranno sicuramente il modo di pensare da programmatore.

Anche il modo di farsi male. Mai sentito parlare di puntatori non inizializzati o che puntano a zone di memoria non più valide, bug intermittenti, double delete, memory leak?

L'importate è avere delle basi solide altrimenti non capirai mai cosa stai facendo.

Infatti. E' bene cominciare col concetto di dato, di tipo di dato, variabile, condizione, iterazione, ecc.

Tieni conto che i linguaggi .net limiteranno le tue aplicazioni in windows

Ma anche no. C# è uno standard ECMA, ad esempio.

Originariamente inviato da Efem

Posso darti una sincera opinione però: Qualsiasi linguaggio deciderai di imparare, non usare editor visuali.
Mi pare ovvio che il programma non è quello che vedi, ma per me meglio farsi sempre tutto con le proprie manine... poi non sò, ditemi pure che perdo solo tempo...

Infatti te lo dico: è un gran perdita di tempo. Un buon IDE ti aiuta molto la vita, e usarlo NON t'impedisce di farti del male mettendo le mani su roba di basso livello, se proprio ci tieni a farlo.

Vorrei concordare con chi diceva che C e C++ costituiscono le fondamenta della programmazione, secondo me sono i primi due linguaggi che andrebbero imparati.

E le fondamenta sarebbero?

Non concordo con chi dice che ormai non sono più in uso: per me è il contrario.

Lo sono ancora, purtroppo, e lo saranno per parecchio tempo. Sono troppo radicati per alcuni settori (programmazione di sistema ed embedded).

C#, VB.NET, ASP.NET, e tutto il .NET Framework li farei volentieri sparire dalla circolazione.
Li uso solo per motivi di studio, diciamo però che mi fanno un bel pò ribrezzo.

De gustibus, ma lascia che altri li utilizzino, se piacciono loro.

Ho trovato molto interessanti invece le librerie Qt basate su C++, compilate e multipiattaforma.

Io invece adoro ancora oggi le VCL di Borland, ma debbo dire che con Silverlight mi sto trovando parecchio bene.

Poi ricordati una cosa: il programma non basta "farlo", va anche fatta una adeguata manutenzione e per fare una adeguata manutenzione, devi metterti in condizioni di dividere i compiti di ciascun componente fin dal primo momento.
Tutte cose che, comunque, ti verranno insegnate per bene all'università.

Se sono bravi all'università t'insegneranno che linguaggi come il C non sono il massimo per la manutenibilità, a causa dell'uso spasmodico degli include e dell'uso del preprocessore.

Il concetto di modularità del codice è assente, purtroppo.

[Efem]

Originariamente inviato da cdimauro

Infatti te lo dico: è un gran perdita di tempo. Un buon IDE ti aiuta molto la vita, e usarlo NON t'impedisce di farti del male mettendo le mani su roba di basso livello, se proprio ci tieni a farlo.

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

Originariamente inviato da cdimauro

E le fondamenta sarebbero?

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

Originariamente inviato da cdimauro

De gustibus, ma lascia che altri li utilizzino, se piacciono loro.

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)

Originariamente inviato da cdimauro

Se sono bravi all'università t'insegneranno che linguaggi come il C non sono il massimo per la manutenibilità, a causa dell'uso spasmodico degli include e dell'uso del preprocessore.

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

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Ovviamente quei fatti sono sensazioni oniriche.

Java, il linguaggio, supporta pienamente la programmazione funzionale. Contrariamente a quanto si pensa non lo fa dalla versione 1.1 (che ha introdotto le classi interne) ma dalla 1.0: perchè è orientato agli oggetti.

Esiste a maggior riprova un'api java che delinea i concetti della programmazione funzionale, functional java.

Dove sta il problema? Il problema è la scomodità perchè non ci sono "eccezioni funzionali" alla sintassi. E fortunatamente non ci saranno neanche in Java 7.

Con questo non sto dicendo che tu deva usare per forza Java, ci mancherebbe. Ma i fatti sono altri.

Circa LINQ, io parlavo di Java non di C#. E' la libreria standard io di Java che ti fa fare quel giro ma una libreria diversa ti permette di ridurre considerevolmente il "rumore di fondo". E senza introdurre eccezioni alle regole del linguaggio. Che è importante per la complessità di un linguaggio - che deriva non dal numero di regole ma dal numero di eccezioni a quelle regole.

Ti pare normale che nel 2011 devi scrivere quella merda perche' la libreria base e' limitata dato che segue quella filosofia assurda per cui al posto di avere a disposizione dei delegate o delle lambda function devi crearti un'intera anonymous inner class?
Ti pare normale che nel 2011 se vai a scrivere:

Calendar startDate = Calendar.getInstance();
startDate.set(2011, 3, 31);
System.out.println("" + startDate.get(Calendar.YEAR) + startDate.get(Calendar.MONTH) + startDate.get(Calendar.DAY_OF_MONTH));

ti esce fuori l'1 aprile come data?
Ah, e tra l'altro anche se usi delle librerie esterne come joda hai lo stesso risultato osceno.
A me tutte queste cose sembrano i sintomi di una obsolescenza del linguaggio che stanno disperatamente provando a svecchiare con java 7, ma che ormai non e' ne' carne ne' pesce.
Hanno perso troppo tempo e da market makers si sono ritrovati ad essere inseguitori, e pure molto in difficolta'.
Come dicevo java ad oggi si salva solo per l'ENORME mole di librerie, soprattutto in ambito enterprise, che sono state sviluppate.
A livello di linguaggio puro c'e' MOLTO ma MOLTO di meglio.

[PGI-Bis]

Originariamente inviato da cdmauro

...

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.

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.

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.

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.

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

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.

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

[birmarco]

Originariamente inviato da pabloski

in pratica un informatico sa impostare algoritmi ma non sa com'è fatto un calcolatore?

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.

[PGI-Bis]

Originariamente inviato da ^TiGeRShArK^

A livello di linguaggio puro c'e' MOLTO ma MOLTO di meglio.

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.

[birmarco]

Originariamente inviato da cdimauro

Che sarebbero? No, perché a questo punto mi sfugge veramente quali sarebbero queste fantomatiche "basi" della programmazione.

C'è qualcuno che è in grado di darmene una definizione oggettiva e incontrovertibile.

Io sono fermo qui: http://it.wikipedia.org/wiki/Algoritmo

Anche il modo di farsi male. Mai sentito parlare di puntatori non inizializzati o che puntano a zone di memoria non più valide, bug intermittenti, double delete, memory leak?

Infatti. E' bene cominciare col concetto di dato, di tipo di dato, variabile, condizione, iterazione, ecc.

Ma anche no. C# è uno standard ECMA, ad esempio.

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.

Cmq le "basi" sono la dimestichezza con variabili, tipi, if, for, while e compagnia. 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.

[marco.r]

Originariamente inviato da PGI-Bis

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

Ti perdi alcuni tra gli aspetti piu' interessanti della programmazione funzionale.

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.

In realta' il cambiare la sintassi del linguaggio ha applicazioni molto piu' interessanti che non calcolare una potenza. Permette ad esempio di implementare una libreria di unit testing completa in 30 righe di codice. Di avere una interfaccia sana per l'interrogazione di database. Di usare costrutti anaforici. Di interfacciarsi a librerire native senza dover sporcarsi le mani col C o il C++
Piu' in generale di implementare tramite il linguaggio stesso delle nuove funzionalita' senza aspettare che lo faccia il vendor, o di reimplementarle in modo corretto.

Poi per carita', uno scampa lo stesso, si scarica lo xUnit di turno, si interfaccia a librerie native con Swig, e si scarica un generatore di codice per non scrivere SQL... finche' e' roba che ha gia' fatto qualcun altro... quando cominci a fare qualcosa di piu' innovativo, o quando magari sei una piccola startup che non puo' scanciare cifre a 5 zeri per un software, le cose cambiano un po'.


Ma meglio ancora, permette di far crescere il linguaggio verso il problema che si deve risolvere invece che maltrattare il problema perche' sia rappresentabile nel linguaggio.

[marco.r]

Originariamente inviato da PGI-Bis

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

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

Non capisco il senso di questa affermazione.
Posso scriverti un metodo che prende 10 argomenti, oppure una catena di 30 chiamate

a.b().c().d().e()...

. Aboliamo anche le classi perche' c'e' gente che non sa programmare ?

[!fazz]

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.

Cmq le "basi" sono la dimestichezza con variabili, tipi, if, for, while e compagnia. 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.

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

[PGI-Bis]

Originariamente inviato da marco.r

Non capisco il senso di questa affermazione.
Posso scriverti un metodo che prende 10 argomenti, oppure una catena di 30 chiamate

a.b().c().d().e()...

. Aboliamo anche le classi perche' c'e' gente che non sa programmare ?

Premetto che di metodi con dieci e più argomenti ne ho visti e non pochi, sono una vera schifezza, non tanto da leggere perchè sono lineari, quando da invocare. Personalmente abolirei loro e abbollireri chi li scrive.

In effetti è un caso esemplare di abusabilità.

Idem per la concatenazione specilamente quando sia variante. E qui ammetto la debolezza: sono un grande appassionato di:

pippo
    .metodo()
    .metodo()
    .metodo()
    .metodo();

Con variante di valico:

pippo
    .metodo(argomento
        .metodo()
        .metodo())
    .metodo();

Programmazione compulsiva: lo scrivo, quando l'ho fatto mi dico "che monnezza di codice hai scritto" riscrivo e poi ci ricasco. Non dovrei perchè il problema è lo stesso dei periodi molto lunghi: tanto più si allontana il soggetto tanto più facile è perdere il senso della frase.

La sintassi può essere usato in questi casi per scoraggiare l'abuso. Considera le classi anonime di java: la sintassi è troppo "verbosa" perchè le si possano usare come funzioni di ordine superiore senza che ti venga il magone a guardarle. E per la verità sono troppo verbose anche per essere usate come funzioni singole il che scoraggia approcci funzionali.

C'è una libreria, functional java, che ben dimostra il problema: a usarla ti precipitano le cataratte eppure è "funzionalmente" ineccepibile.

Per la sintassi e i preprocessori, giocare con la sintassi del linguaggio è certamente divertente. Quando uscì Java 5 scrissi un tutorial che usava le annotazioni esattamente per quello. Rinnego quell'atto di passione con veemenza .

Il linguaggio non è solo strumento di programmazione ma è anche strumento di comunicazione tra programmatori: tipicamente il giovannino che scrive e il pippo che deve manutenere/estendere.

Non è raro che, pur nella rigidità della sintassi, tra i due nascano dissapori: uno che apprezza la concatenazione (io) può non essere benvisto da uno che la detesta (sempre io, è un disturbo bipolare). Se anzichè usare un costruttore con tre argomenti o un produttore faccio la genialata di usare i generici per implementare i numerali di Church coi quali verifico la completezza di una concatenazione di tre metodi, per consentire al compilatore di rigettare quelle parziali, non mi aspetto che mi dicano "che genio": mi aspetto che mi dicano "ma guarda 'sto stronzo". Perchè ho dimostrato di conoscere il linguaggio ma non la programmazione, che è tante cose, tra le quali anche la capacità di comunicare con altri programmatori.

Per questo ritengo la presenza del preprocessore un grossolano errore: non c'è più l'esigenza di performance per cui è nato, restano solo i danni che può fare.

[Tommo]

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