Newsgroup: it.comp.programmare
Titolo: Imparare a PROGRAMMARE e non imparare un LINGUAGGIO...

Salve a tutti. Volevo porvi questa domanda:
Mettiamo conto che compri dei manuali e relativi eserciziari ed impari tutto
il C (ad esempio).  Potrei dire di saper programmare?
Credo di no. Saper ordinare un array o creare una lista o ordinare la solita
"agenda", non credo che voglia dire saper programmare.
Parlo in teoria ovviamente, io ho studiato informatica ma purtroppo faccio
un altro lavoro..
Mi piacerebbe sapere cosa fanno "praticamente" i programmatori di
professione. Che genere di programmi scrivono. Risolvono la torre di Hanoi?
Li pagano per questo?!?! o per riscrivere il comando "grep" di Unix?
Ne dubito..
Come si compie il salto dalle esercitazioni del Bellini-Guidi o del
Kernighan Ritchie ai programmi VERI? Cosa FANNO questi programmi?
Dove si può imparare la TENICA (e non l linguaggio) se non si ha la
possibilità di lavorare sul campo?
Grazie Mille,
 Franco

 possibilità di lavorare sul campo?
Non conosco il Bellini-Guidi, ma diventare programmatori, come per qualunque professione, e' necessario dell'apprendistato (chiamato anche tirocinio, o "stage", o praticantato, o formazione/lavoro).
Pertanto, prima si studiano due o tre linguaggi, applicandoli a casi "accademici", poi si studia un linguaggio richiesto dal mondo del lavoro e lo si applica a casi realistici per il settore in cui si intende introdursi.
Tempo stimato: 3 anni di studio + 2 anni di apprendistato.
-- 
	Carlo Milanesi
 
http://digilander.libero.it/carlmila

Il mio prof. di Fondamenti di Informatica (Prof. Elio Piccolo), dopo il 
compito mi scrisse sul foglio *IN VERDE*:
"Saper programmare perfettamente in C non vuol dire Saper programmare".
Lezione che non dimenticherò mai! (facevo lo sborone all'epoca... magari 
lo faccio ancora adesso ;))
Luigi

 "Saper programmare perfettamente in C non vuol dire Saper programmare".
A parte la mia ignoranza del significato del colore verde, mi permetto di dissentire dall'illustre Prof. Elio Piccolo (che non ho tuttavia il piacere di conoscere).
Consideriamo la frase "Saper giocare perfettamente a calcio non vuol dire Saper giocare".
Se per "Saper giocare" intendiamo saper giocare a qualunque gioco, la frase e' vera; ma se intendiamo saper giocare ad almeno un gioco, la frase e' ovviamente falsa.
Tornando al linguaggio C, mi sembra chiaro che saper programmare in linguaggio C significa saper programmare in almeno un modo, anche se non significa saper programmare in tutti i modi possibili.
Ma se per "Saper programmare" si intendesse saper programmare in tutti i modi possibili, allora mi sento sicuro di affermare che nessuno e' in grado di programmare in tutti i modi possibili, in quanto vengono continuamente inventati nuovi sistemi hardware e software, e nessuno li puo' conoscere tutti.
Inoltre, ci sono al mondo milioni di persone che sono a buon diritto considerati programmatori di computer pur conoscendo bene un solo linguaggio di programmazione. Dovremmo forse affermare che tutte queste persono in realta' non sanno programmare?


 professione. Che genere di programmi scrivono. Risolvono la torre di
Hanoi?
;)
io ho imparato su foglio di carta quadrettati divisi in 80 colonne!
Il mio primo lavoro è stato cambiare il tracciato dell'anagrafica
clienti in tutti i programmi di Miralanza.
Ma temo siano solo ricordi d'un vecchietto

 
Ok... ma ti assicuro che come lezione è stata ottima! La lezione è 
comunque di mantenere i piedi per terra e di non strafare mai. In quel 
periodo ero fin troppo sicuro di me! e lui decise che dovevo abbassare 
la cresta... ovviamente poi sono diventato suo coadiutore... ;)
Luigi

 Li pagano per questo?!?! o per riscrivere il comando "grep" di Unix?
Ti dirò, dal basso della mia appena iniziata esperienza di programmatore...
Tutto ovviamente IMHO.
Per saper programmare, bisogna ovviamente conoscere almeno un linguaggio di
programmazione. Conoscerne più di uno aiuta.
Quindi, bisogna imparare un pò di teoria, come il "project management",
analisi dei problemi, stesura delle specifiche e dei casi d'uso, l'uso dei
Patterns, etc etc. Sono tutte cose che imho un programmatore deve sapere,
almeno in parte, dato che non sempre c'è qualcuno che fa queste cose al
posto tuo. Una volta imparate tutte queste cose, sarebbe bene metterle in
pratica in qualcosa di concreto (cosa che io non ho ancora
fatto...ehmmm....).
Bisogna poi ricordarsi che non è molto intelligente reinventare la ruota, o
scoprire l'acqua calda, quindi bisogna imprare a sfruttare il materiale
disponibile. Soprattutto con internet, sono disponibili decine di mega di
informazioni, librerie e quant'altro. Un buon programmatore dovrebbe
conoscere le fonti disponibili, e saperle consultare in modo rapido ed
efficiente.
Ora che l'ultimo della classe ha parlato, siete liberi di cazziarmi!
Raffaele

 Consideriamo la frase "Saper giocare perfettamente a calcio non vuol dire
Saper giocare".
imho si puň dire "Conoscere l'alfabeto non significa saper scrivere".
Conoscere perfettamente un linguaggio non significa necessariamente saper
programmare, dato che la programmazione č fatta anche di altre cose, forse
piů importanti del linguaggio stesso. Credo sia questo il concetto...
Raffaele

 piů importanti del linguaggio stesso. Credo sia questo il concetto...
Mai migliori parole!
Luigi

 o scoprire l'acqua calda, quindi bisogna imprare a sfruttare il materiale
Non necessariamente: di solito "reinventare la ruota", in alcuni casi, è la 
soluzione migliore, perché di solito è una ruota che funziona in maniera 
più efficiente e funzionale alle proprie necessità.
Ciao!
-- 
---
*************** | Have you ever retired a human by mystake?
*** Azathot *** |
*************** | To contact me, ask me gently. Thanks.

 più efficiente e funzionale alle proprie necessità.
Migliorare la ruota è un conto, ma reinventandola si rischia di ritrovarsi
con qualcosa di quadrato che non funziona proprio nel migliore dei modi...
Raffaele

 (cosa che io non ho ancora fatto...ehmmm....).
Ma DOVE e COME si imparano queste cose? Per chi non può farsi le ossa sul
campo esistono manuali specifici o libri che NON siano il solito manuale C o
Java? (in cui non c'è quasi mai traccia di concetti come Patterns, "project
managemente" ecc...) Esistono testi  sulle tecniche di programmazione? Che
insegnino a scrivere programmi e non un singolo linguaggio?



forse č meglio dire:
avere ottimio fondamentali non significa saper giocare a calcio :)

 professione. Che genere di programmi scrivono.
Scrivono il software che gli chiedono i clienti. In pratica se il
lavoro è per una compagnia telefonica scrivi programmi per la
fatturazione del traffico, per la configurazione delle centrali, per
la pianificazione della rete, ...
Se è per una banca scriverai software per la gestione dei bonifici,
per le segnalazioni di legge, per la gestione del rischio operativo,
...
Volendo provare a dare una risposta generica potremmo dire che
all'inizio si parte da un processo "di businness" che il cliente ti
chiede di automatizzare.
Il mio primo programma "a pagamento" (ti parlo di quasi quindici anni
fa) mi fu commissionato dal padrone di una fabbrica di profilati in
alluminio. Voleva un programma che gli ottimizzasse il taglio delle
lastre.
Nel suo processo la fase di taglio delle lastre richiedeva, a suo
giudizio, un'ottimizzazione che solo un software specifico poteva
dare, cosi' lo commissiono' ad un programmatore (me) che glielo
realizzo' (in C su un Amiga 2000).
Insomma, si parte da un'esigenza (i cosiddetti "requisiti") e si
arriva al software che soddisfa quei requisiti.
Nel mio caso l'esigenza era semplice e quindi una squadra di un solo
programatore era sufficente, nella realtà servono molte piu' persone
per arrivare dai requisiti al software. Secondo un'antica, imprecisa
ma ancora in voga terminologia abbiamo varie figure:
  - gli Analisti, che prendono i requisiti dall'utente e li
trasformano in "Specifiche" (quello che il software deve fare)
  - i Progettisti (o Analisti Programmatori), che in base alle
"specifiche" decidono quali moduli software realizzare e come dovranno
essere realizzati.
  - i Programmatori, che fisicamente realizzano i programmi in un
qualche linguaggio.
  - varie figure di contorno come i Capiprogetto, i Sistemisti, i DBA,
i tester e gli immancabili (sedicenti) "Esperti"
Ovviamente nella realtà è tutta un'altra cosa e i ruoli si
sovrappongono, le attività si invertono ed il caos regna sovrano.
Ora, se c'e' ancora qualcuno all'ascolto, provo a dare la mia risposta
 preferita:
"Programmare vuol dire creare un modello di un pezzo della realtà"
Ogni pezzo di software ha senso perche' "rappresenta" una qualche
realtà (magari solo immaginaria come in Quake, ma comunque "reale" per
i giocatori che decidono di sospendere la loro credulità per il tempo
di una partita).
Posso fare delle operazioni sul modello (il programma) e vedere quali
sono i corrispondenti risultati nella realtà.
Alla luce di questa risposta, quindi, "programmare" (nel suo senso
piu' ampio) vuol dire comprendere una parte della realtà che ci
circonda cosi' a fondo da poterne descrivere tutti gli aspetti
rilevanti in un linguaggio di programmazione.
Ed ecco che due piccole parole: "aspetti rilevanti", aprono un
baratro! La distinzione tra un programma che funziona ed uno che non
funziona è tutta nel fatto che il suo autore abbia afferrato e
rappresentato correttamente gli "aspetti rilevanti".
Ricordo il vecchio programma di gestione del parco auto di un noto
operatore telefonico (spero che l'abbiano cambiato nel frattempo era
in Cobol con un DB gerarico) in cui ogni autovettura era rappresentata
univocamente dalla targa. Normale! Una targa un veicolo, non ci sono
dubbi!
Peccato che le targhe si perdano, vengano rubate e i veicoli
reimmatricolati per vari motivi! Quel programma non permetteva la
gestione di questi eventi e costringeva, in questi casi, il gestore a
creare un nuovo veicolo perdendo tutta la storia delle manutenzioni,
incidenti e quant'altro.
Un "aspetto rilevante" che era stato considerato "irrilevante" aveva
prodotto un software che non rispondeva alle reali esigenze
dell'utente.
Nulla di grave in questo esempio, era solo una seccattura che capitava
di tanto in tanto, ma la storia è piena di fallimenti software
imputabili ad "aspetti rilevanti" completamente ignorati.
Insomma, e qui chiudo, per me, saper "programmare" vuol dire essere in
grado di comprendere e descrivere il problema da risolvere in modo da
poterlo rappresentare all'interno di un computer.
Piu' facile a dirsi che a farsi! :)

 con qualcosa di quadrato che non funziona proprio nel migliore dei modi...
In generale succede proprio l'opposto: se ti guardi in giro, vedrai molto 
software scritto con il concetto sbagliato di "riusabilità", ovvero quello 
secondo cui meno si lavora più si guadagna, a prescindere dalla qualità del 
software.
Non c'è bisogno necessariamente di migliorare la ruota. Molte volte basta, 
ad esempio, riprogettare un algoritmo noto per sfruttare qualche 
caratteristica particolare del problema che si sta affrontando per ottenere 
dei miglioramenti altrimenti irraggiungibili anche dal più perfezionato e 
stilisticamente perfetto dei codici esistenti.


 wrote in message
news:lTmCa.473$hf2....@news.edisontel.com...


On Sat, 31 May 2003 22:35:56 +0200
Luigi 'Comio' Mantellini <lmantellini@_NO_hotmail_SPAM_.it> wrote:

Insisto nel ritenere errata la frase "Saper programmare perfettamente in C non vuol dire Saper programmare". 
Probabilmente il tuo professore intendeva invece: "Saper perfettamente il C non vuol dire Saper programmare", analoga alla frase "Capire perfettamente il gioco del calcio non vuol dire Saper giocare", o alla frase "Capire perfettamente la notazione musicale non vuol dire saper suonare".
La frase "Saper programmare perfettamente in C" e' ben diversa dalla frase "Saper perfettamente il C".
Nella seconda si intende la conoscenza delle sole regole di sintassi e semantica del linguaggio, in modo tale da poter comprendere il funzionamento di un programma esaminandone i sorgenti, ma questo non implica la capacita' di scrivere buoni programmi.
Su questo sarei d'accordo.
Per quanto riguarda l'umilta', penso anch'io che ogni professore dovrebbe insegnarla a ogni studente presuntuoso. Per esempio, molti pensano che ci sia un sistema operativo nettamente superiore a tutti gli altri, un linguaggio di programmazione nettamente superiore a tutti gli altri, e cose del genere.
E' opportuno, come dicono gli americani, mettere le cose in prospettiva, ossia evitare fanatismi.




Secondo me, e' meglio prima imparare un paio di linguaggi di programmazione e applicarli a esercizi accademici (dalla Torre di Hanoi al grep), il che richiede almeno un anno.
Poi si possono leggere libri sulle tecniche di programmazione. Ma i libri che cercano di spiegare una tecnica di programmazione senza fare esempi e cercano di rimanere indipendente dal linguaggio e dalla piattaforma risultano inutili in quanti troppo vaghi o troppo difficili.
Come esempio di un buon libro, cito "The Practice of Programming" di Brian W. Kernighan e Rob Pike, tradotto in italiano come "Programmazione nella pratica".
Nonostante le premesse di generalita', in realta' si rivolge a chi conosce gia' il linguaggio C e lo usa da un ambiente a riga di comando. Contiene esempi nei linguaggi C, C++, Java, Perl e AWK.


 possibilità di lavorare sul campo?
A casa propria, con il C<64, da ragazzini... :) 
-- 
Luc.

A casa propria, con il C<64, da ragazzini... :) 
bella risposta :)
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
UGIdotNET - User Group Italiano .NET  
http://www.ugidotnet.org

 A casa propria, con il C<64, da ragazzini... :)
alleluja fratello! :)
-- 
-=[]=---iAN CooG---=[]=-
Qst frm ` stt cmprss pr rsprmr spz.


Bella risposta! Comunque, non posso resistere, parlando di C64, chi lo sa, risponda:
169,0
(almeno mi sembra di ricordare!)
Ah, io ho iniziato col VIC20 :-)
Ciao,
    Bruno.
-- 
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
|
| Membro del JUG Torino - 
http://www.jugtorino.it
| 

più efficiente e funzionale alle proprie necessità.
decisamente in linea coi pensieri di Fowler e Martin.
sbirish

 decisamente in linea coi pensieri di Fowler e Martin.
Importa sega. L'importante è che sia in linea con la realtà.


Importa sega. L'importante è che sia in linea con la realtà.
bene, nella realtà martin ha fatto mentoring e training per symantec,
sabre, navtech, nortel e xerox.
Tu riesci a pagare le rate della tua 500 quasi nuova comprata nel
klondike?
sbirish.

 klondike?
Io le compro in contanti le mie automobili. Se vuoi un giorno ti faccio fare 
un giro sulla mia MX spider.


 lo sa, risponda: 169,0
LDA #$00
meglio A9 00, in decimale e' una schifezza.
-- 
-=[]=---iAN CooG---=[]=-
Real Programmers use "COPY /B CON FILENAME.EXE"

 faccio fare un giro sulla mia MX spider.
la tua Fiat 500 MX spider?
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

suo software.
Beh, magari saranno tutti gonzi, la tua azienda è più conosciuta di
quelle?
Tra l'altro Martin &c sviluppano anche, non fanno solo mentoring.
sbirish.

 di quelle?
è che non può dirci per che azienda lavora. Dopo dovrebbe ucciderci



Ho scritto 169 perche' all'epoca programmavo direttamente in LM sul 64, caricando il
programma dal basic mediante poke e data, e avviandolo poi con un bel sys
Avevo comprato un testo, "Il vero linguaggio macchina del C64", che spiegava come
programmare direttamente in LM (senza assembler) il computer: mi ci appassionai parecchio,
e ancora mi ricordo la codifica di quella particolare istruzione, forse  la prima
presentate nel libro per spiegare il meccanismo.
Eh, bei tempi!


 (almeno mi sembra di ricordare!)
Occhio al 96 dopo, altrimenti crasha tutto... ;)
-- 
Luc.


Se vuoi imparare le TECNICHE (idee, approcci, metodi, ecc...) e non le
TECNOLOGIE (Linguaggi) con le quali IMPLEMENTARE LE TECNICHE... cioè se
parli di vera informatica e vera programmazione, allora non ci sono dubbi su
gli argomenti:
- Teoria degli Algoritmi e Strutture Dati
- Teoria della Computabilità e Complessità
- Teoria OOP
- Ingegneria del Software (approcci oop, pattern, ecc...)
Poi scegliti un linguaggio procedurale per implementare le tecniche dei
primi 2 e un linguaggio OOP per implementare le tecniche degli ultimi 2.
Libri consigliati, in ordine:
Per i primi 2 argomenti:
- Programmi = Algoritmi + Strutture Dati, del mitico Niklaus Wirth, Edizione
Tecniche Nuove università e ricerca
- Introduzione agli Algoritmi - Jackson Libri
- Algoritmi e Strutture Dati, di Alan Bertossi, edizione UTET
- The Art OF Computer Programming (3 volumi), del grande Knut ... una vera e
propria Bibbia sacra della programmazione vera... collana che non dovrebbe
mai mancare nella libreria di ogni programmatore con la P maiuscola.
Per gli altri 2 temi:
Non sono tanto esperto da poterti consigliare libri sul tema... in giro ne
trovi veramente tanti... altri del NG sicuramente ti potranno consigliare.
ciao
Plenolo

 Avevo comprato un testo, "Il vero linguaggio macchina del C64", che
Ecco come si chiamava. Io e i miei amici ci facemmo delle grasse risate
vedendo la pubblicita' su CCC. Il "vero" LM... mi faceva sorridere
vedere che qualcuno credesse che gli opcode in decimale fossero piu'
capibili che in esadecimale. Forse era solo questione di abitudine.
-- 
-=[]=---iAN CooG---=[]=-
Alla fine del mondo, Dio separera' chi usa Linux da chi usa Windows


Questione di gusti :-)
Perlomeno oltre alle risate l'avete pure letto?


 Perlomeno oltre alle risate l'avete pure letto?
Mai comprato un libro per C64, a parte un libercolo (trovato in edicola)
con floppy sui segreti del 1541, in pratica una mera traduzione del
"Inside Commodore DOS" (ora disponibile in rete come PDF). A parte le
riviste specializzate come CCC, Commodore Gazette, 64'er(tedesca) etc,
si imparava tutto "su strada" disassemblando e con info che arrivavano
dalla sfizzera e dalla cermania; il disk trading una volta sopperiva
alla mancanza di modem, e la poca documentazione che arrivava veniva
stampata e letta come bibbia.
-- 
-=[]=---iAN CooG---=[]=-
http://digilander.libero.it/iANCooG/


Ok, approccio differente, comunque io compravo solo CCC (per chi non lo sa, Commodore
Computer Club) e non ci riuscivo neanche sempre :-D


 Computer Club) e non ci riuscivo neanche sempre :-D
E Video Basic? Chi se lo ricorda? L'ultima "cassetta" la migliore: 
quella con gli accenni all'assembler. Da li poi è partito tutto 
(assembly-only programming). :-) 
-- 
Luc.