Newsgroup: it.lavoro.informatica
Titolo: impara a programmare in 10 anni

Si aggancia in qualche modo alle (pseudo)discussioni dei thread di
questi giorni:
http://www.norvig.com/21-days.html


http://www.norvig.com/21-days.html
Perfetto. A tema:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
http://softwarecraftsmanship.oreilly.com/wiki
http://www.joelonsoftware.com/articles/fog0000000043.html
http://samizdat.mines.edu/howto/HowToBeAProgrammer.html
http://www.codinghorror.com/blog/archives/000781.html
http://steve.yegge.googlepages.com/five-essential-phone-screen-questions
http://steve.yegge.googlepages.com/what-you-need-to-know
http://steve.yegge.googlepages.com/practicing-programming
http://steve.yegge.googlepages.com/being-the-averagest


interessante! Sono perfettamente d'accordo sul fatto che dieci anni
siano una stima ragionevole per diventare veramente bravo in qualcosa,
che sia programmazione o tennis! Credo che siano necessari perche' la
tua mente "prenda quella particolare forma", e la disciplina in
questione ti sembri una cosa perfettamente naturale come bere o
mangiare.
Sono meno d'accordo sul fatto che i libri tipo "teach yourself xxx.."
siano tutti inutili. Certo se ne abusa, ma ne ho visti anche di fatti
in maniera decente e possono avere una loro utilita' come introduzione
"dolce" per chi magari ha un po' troppo timore reverenziale per un
soggetto, o non e' ancora sicuro se gli interessa veramente.
Penso anche che dica una stupidaggine quando indica C++ e Java come
troppo complessi per chi vuol imparare a programmare. Io penso siano
perfetti. Certo, C++ ha molti "lati oscuri", ma nessuno ti obbliga ad
esplorarli finche' sei un niubbo...

esplorarli finche' sei un niubbo...
Io una volta mi ero fatto una idea sul linguaggio con cui iniziare.
Pi� vado avanti, pi� questa idea cambia continuamente ;)
Cmq, sono daccordo con Peter Norvig, almeno sul C++: � un linguaggio a
cui approdare, pieno zeppo di complessit�, difficile dire che sia
l'ideale per un neofita. A momenti � dimostrabile che la maggior parte
di quelli che lo usano non lo padroneggiano bene come ci si
aspetterebbe... :). Tra i due molto meglio Java per partire.
Cmq Norvig � proprio un mostro, basta vedere gli articoli sulla sua
home page per capire di che geniaccio parliamo.
Questa 
http://www.norvig.com/ibol.html
 ad esempio � davvero bella.

 home page per capire di che geniaccio parliamo.
ah che il tipo sia in gambe e' fuori discussione, e l'articolo e'
sicuramente molto interessante, a partire dal titolo!

programmazione.  C++, Java, Python, Ruby, C#.. vanno tutti benissimo.
Credo, si. Come lasciavo intendere, la didattica � cosa difficle su
cui non mi pronuncio ma il caso del C++ � conclamato e assodato da
tempo.
Del libro ho visto le parti liberamente consultabili e mi � piaciuto,
ma un libro non cambia la realt� dei fatti.
Molti nomi (Bruce Eckel, Alex Martelli, etc.) tra i grandi esperti del
C++ la pensano cos�. Lo stesso Stroustrup non nasconde l'ardua
difficolt� dell'impresa in 
http://www.research.att.com/~bs/bs_faq.html
A me pare difficile associare quello che lui stesso (2 anni in media
per impararlo, necessit� di mentoring altrimenti ci si perde nella sua
complessit�) e altri grandi esperti asseriscono con l'idea che sia
indolore come punto di partenza per imparare a programmare.
Non lo � by design, come il C. E' stato creato come evoluzione del C,
quindi per il programmatore esperto come target e la cosa � evidente.
Discussioni come questa
http://www.artima.com/intv/goldilocks.html
confermano il fatto che "perdersi" nel C++ � facile, ed infatti ben
venga finalmente questo suo nuovo libro (anche se a dire il vero
diverse perle erano gi� presenti da una vita: Lippman, Koening,...) in
aiuto, se � proprio necessario che un qualche neofita di
programmazione lo impari per primo.
Ma tutti i libri del mondo non renderanno un linguaggio di basso
livello meglio digeribile o pi� produttivo di un vhll.
L'esperienza ci ha insegnato che non � produttivo usare il C++ come
primo approccio alla programmazione; fortunatamente per noi, con il
passare del tempo questa idea si � ben consolidata.
Al solito, tutto si riconduce sempre allo stesso, grande errore di
fondo: non usare lo strumento giusto al momento giusto :)

 fondo: non usare lo strumento giusto al momento giusto :)
odio l' "ipse dixit", ma in questo caso credo sia appropriato:
Dall' introduzione di "programming, principles and practice using c++"
"why c++? c++ directly supports the key concepts and techniques used
in real-world software.
... Quality and/or free implementations are found on every kind of
computer...Most of the programming concepts you will learn using c++
can be used directly in other languages such as C, C#, Fortran and
Java.
... We teach programming first and treat our chosen programming
language as secondary, as a tool. Our general approach can be used
with any general purpose programming language. ....
At the end of this book, will you be an expert at programming and at C+
+? Of course not! When done well, programming is a subtle, deep, and
highly skilled art building on a variety of technical skills. You
should no more expect to be an expert at programming in four months
than you should expect to be an expert in biology, math, in a natural
language,or at playing the violin in four months, or in half an year,
or a year. What you should hope for and what you can expect if you
approach this book seriously, is to have a really good start that
allows you to write relatively simple useful programs, to be able to
read more complex programs and to have a good conceptual and practical
background for further work.".
Credo che questo chiuda la discussione.

 fondo: non usare lo strumento giusto al momento giusto :)-
Io invece pongo la questione in un'altra visuale.
Premesso che sono d'accordo che, come dice Norvig, spesso si usa
"caprescamente" il C++ come il C, o peggio come il BASIC.
Esistono molti miei post però, dove una piccola lezione che ho
imparato all'università (e qui Norvig non me ne voglia ma dissento
completamente da lui...) è che non è tanto importante un linguaggio,
ma il metodo di risoluzione del problema. Il vero informatico si deve
astrarre dal linguaggio, e mi spiego con un esempio.
Io nasco come programmatore C su Amiga a 14 anni (non voglio fare a
gara con Luc...), oggi da PM sistemista il massimo che uso è lo script
shell. Questo non toglie che, dovendo correggere molti cgi-bin o
script che trattano dati fatti in Perl abbia avuto a che fare con
questo linguaggio. Io non conosco il Perl però ti posso assicurare
che, guardando vari esempi di sintassi su Internet, sono in grado di
CORREGGERE alcuni errori concettuali o di funzionamento.
Morale: un vero informatico quando deve lavorare con dei sorgenti si
procura il manuale della sintassi del linguaggio. Se gli piace lo
impara, se non gli piace (come è il mio caso col Perl, linguaggio che
per molti aspetti non gradisco) è comunque in grado di metterci le
mani.
Se CI DEVE LAVORARE PER FORZA, beh magari a malincuore, lo impara
uguale: è stato così per me per l'Oracle Pro*C 10 anni fa...
Vedo ancora una volta che si fanno guerre di religione sui vari
linguaggi (per carità pure io ho le mie preferenze) senza capire che
sono lo strumento per la realizzazione di un algoritmo. Poi ne
esistono di più o meno validi ma l'abilità è capire la metodologia di
codifica e  NON il linguaggio in sè: è questo secondo me che Norvig
vuole trasmetterci.

 gara con Luc...)
Che bei tempi... Altro che i merdosi Windows, Linux ed OSX... :-)
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 __________________________________
sono sempre bei tempi quando uno e' teenager, indipendentemente dal
sistema operativo :P

 sistema operativo :P
No, no.... Era proprio il S.O. :)
PS: e meglio ora che da teenager, tranne per qualche kg di troppo. :P 


 Che bei tempi... Altro che i merdosi Windows, Linux ed OSX... :-)
Permettimi di dissentire su Unix...
Devo dire che quando ho iniziato a usare gcc su Linux, Digital Alpha e
HP/UX mi sono trovato un po' meglio dei vari Lattice/Aztec/SAS!

 HP/UX mi sono trovato un po' meglio dei vari Lattice/Aztec/SAS!
Parlavo del sistema "generale", della filosofia. Certo: AmigaDos era "figlio" 
di unix...


 __________________________________
Certo un computer che per 800.000 lire (di una volta ) ti permette di
compilare con due floppy non è che lo trovavi in giro... con i prezzi
di un PC di allora!

 Certo un computer che per 800.000 lire (di una volta )
A2000 nel 1989, pagato 2.050.000 lire, lo ricordo ancora.
Sono stato invidiato per anni dai x86-isti CGA/EGA/VGA... :) 


 Sono stato invidiato per anni dai x86-isti CGA/EGA/VGA... :) 
1984 : Mac 128K
1985 : Mac Plus upgrade
ecc ecc ecc
ROSICA !
bye,
G.

 ROSICA ! 
Perdincibacco, come rosicare con un Macchista?


> passare del tempo questa idea si � ben consolidata.

Ok, capisco che non ti smuovi, chiudi pure qui nessun problema :)
Nota per� che io ti parlo di esperienze di molte persone al top,
condivise da un mare di gente. Sono oramai in pratica pi� i grandi che
abbracciano l'alto livello, rifuggendo la complessit� di C++, CL e
simili che quelli che ci vanno gi� a testa bassa ignorando cosa la
storia ci insegna[2].
Tu invece mi riporti l'intro di un libro (che avevo gi� deciso di
prendere perch� mi interessa non poco, come i gi� citati e spesso poco
notati Koening e Lippman) scritto dall'inventore del linguaggio.
Ai posteri la prova sul campo del tutto. Anche se per fortuna in tanti
hanno gi� provato e deciso :)
[2] Tante le storie, come Steve Yegge che parla del sistema Amazon e
di quanto C++ abbia reso un incubo la loro codebase da tante decine di
milioni di righe di codice

vuole trasmetterci.
Sbagli ancora peccando d'inesperienza. Il linguaggio � importante
tanto quanto il resto. Non saperlo padroneggiare a dovere equivale a
scrivere software mediocre.

>Credo che questo chiuda la discussione.
Dimenticavo, da 
http://norvig.com/21-days.html
"Keep it simple. Programming languages such as C++ and Java are
designed for professional development by large teams of experienced
programmers who are concerned about the run-time efficiency of their
code. As a result, these languages have complicated parts designed for
these circumstances. You're concerned with learning to program. You
don't need that complication. You want a language that was designed to
be easy to learn and remember by a single new programmer."
*Keep it simple*. Questo si che chiude la discussione, anche
indipendentemente dai linguaggi discussi :).
nota per quelli che vedono guerre di religione ovunque: per me si pu�
sostituire C++ e/o Java con Common Lisp, ocaml, vari dialetti ML,
perl, ada, C, ...
nota 2: si, su Java si potrebbe discutere. E' di ordini di grandezza
pi� produttivo di C++, forse per partire non � poi il peggio che
esista a patto (come sempre) di non fermarsi solo a quello, cadendo
nell'effetto alla "perils of Java school".



Dimenticavo, da 
http://norvig.com/21-days.html
"Keep it simple. Programming languages such as C++ and Java are
designed for professional development by large teams of experienced
programmers who are concerned about the run-time efficiency of their
code. As a result, these languages have complicated parts designed for
these circumstances. You're concerned with learning to program. You
don't need that complication. You want a language that was designed to
be easy to learn and remember by a single new programmer."
*Keep it simple*. Questo si che chiude la discussione, anche
indipendentemente dai linguaggi discussi :).
nota per quelli che vedono guerre di religione ovunque: per me si pu�
sostituire C++ e/o Java con Common Lisp, ocaml, vari dialetti ML,
perl, ada, C, ... La questione non � nel citare nomi ma nel saper
motivare le cose. E' un invito a discutere.


 troppe altre materie alla facolt� d'informatica.
Assoulutamente falso! Sono sicura che tu non abbia mai nemmeno assistito 
ad una lezione di Analisi Matematica.
Infatti, l'esame si compone di due parti. Se la parte orale si supera 
come dici tu, con teoremi e dimostrazioni, la parte scritta - pi� 
importante - si supera sapendo risolvere gli esercizi.
Ciao,
Vale.

affrontare in modo sistematico e scientifico ogni problema.
Nel tuo caso, anche quella necessaria ad afforntare il tuo cambio di
sesso scommetto.
Ciao Valet�, salutame Crepax
p.s. a me na'bianca con un wurstelll e due pomodorini sopra. E nun te
magn� er wurstel...

 milioni di righe di codice
beh, non sara' mica anche il caso di considerare che la loro codebase
da incubo sia una conseguenza della loro incapacita' invece che del C+
+? Questo mi sembra il caso del tennista che sbaglia un colpo
importante e se la prende con la racchetta lanciandola a terra..
Non sara' piu' colpa di Yegge che del C++ se la codebase di amazon e'
diventata:
"a huge mountain of poop, the biggest mountain you've ever seen, and
your job is to crawl into the very center of it, every time you need
to fix something."
Termino con questa citazione di Yegge:
"C++ is dumb, and you can't write smart systems in a dumb language.
Languages shape the world. Dumb languages make for dumb worlds."
Penso che riassuma tristemente il livello del personaggio ...

 molto piu' lucida ed efficiente.
� esattamente quello che dicevo io.

 Penso che riassuma tristemente il livello del personaggio ...
Condivido. Chi scrive una cosa del genere non ha capito una mazza
quadra. C++, per le complessit� che hai esposto, non � un linguaggio
applicabile ovunque. Ma � solido, ben supportato, ben implementato.
Certo, ci puoi fare delle porcherie inenarrabili, che magari altre cose
non ti consentono, pero' ti consente anche livelli prestazionali che
gli altri si sognano. Come sempre, il programmatore � ci� che conta.
-- 
Ciao!
Luca

Penso che riassuma tristemente il livello del personaggio ...
*Tu*, invece, chi saresti scusa? Il tuo livello? Sempre bravi a
parlare male degli altri, eh? ;)
E, soprattutto, sono di basso livello anche
Martelli/Eckel/Koening/Martin/etc... e tutti gli altri che hanno fatto
esperienza della poca produttivit� ed enorme complessit� del C++[1]
rispetto a soluzioni vhll pi� consone alla grande maggioranza dei
tasks incontrati nella vita media di chi crea software?
Conclusioni: che devo pensare, che Stroustrup � l'unico che ha capito
qualcosa e tutti gli altri si sbagliano?.
Senza offesa, possiamo chiudere qui per me. Sono praticamente
argomenti del decennio scorso e non � produttivo starne ancora qui a
parlare :)
[1] e non solo, anche di altri strumenti come i gi� citati CL e chi
pi� ne ha pi� ne metta, tanto per chiarire che si parla di esperienze
tecniche e non chiacchiere da infedeli di questa o quella religione
digitale :)

 productivity ?
A couple of weeks (versus a decade of C++, and C before that).
One of the most amazing characteristics of Pythin is how
amazingly FAST one becomes productive with it.
Alex 

Mi sbaglier�, ma somiglio molto a quelli che, usando solo il martello,
              ^^^^^^^^^^^^^^
argghhh... era *somigli*, chiaramente.

</cite>
mmm... a rileggere dopo tanti anni la faq, preciso che non sono per
nulla daccordo con l'uso dei termini "tolleranti" e "di manica larga"
che fa l'autore, ritenendoli fuorvianti e poco appropriati essendo la
natura del problema discusso un'altra.
giusto per precisare...

 (trovi qui 
http://snipurl.com/md4j9
 il thread dell'epoca)
Non so se tu c'eri, Alex Martelli bazzicava anche qui, e ricordo
vagamente che si era parlato di differenze tra i linguaggi. E' passato
molto tempo, e lui doveva ancora migrare verso Google.
Non ricordo una sola volta in cui il buon Alex abbia definito C++
stupido. Giuro. Ma magari ho la memoria corta io.
-- 
Ciao!
Luca

stupido. Giuro. Ma magari ho la memoria corta io.
Non hai la memoria corta. E che non troverai mai Martelli usare quel
linguaggio goliardico, non � nel suo stile. Almeno, non quando parla
di cose inanimate... :P
Ma al di fuori di soppesare le parole e attaccare Yegge sulla base di
una frase/espressione, ti sei chiesto per un attimo cosa voglia dire
con "C++ is dumb"? E si che ho pure fornito un grosso hint dicendo
introspection... Fa nulla.
Leggilo tutto Yegge, non fermarti alle frasi colorite, vedrai che ne
imparerai di cose e rifletterai su altre a cui non hai mai pensato.
Detto questo, ti sei dimanticato una opzione prima:
c'� la possibilit� che questa gente abbia visto sistemi software ben
al di sopra delle nostre conoscenze e parli per ragione veduta.
In altre parole, certe cose che dicono ci possono sembrare
"eretiche"[1] ma sono solo troppo distanti dalla nostra esperienza e
conoscenza nel momento in cui le leggiamo. Un pensierino ce lo farei
al riguardo fossi in te...
[1] � proprio il caso di dirlo, parlando delle reazioni da muro di
gomma di alcuni difensori oltranzisti del C++

sempre tendenzialmente diffidente.
Consideri quindi Steve Yegge un "sedicente guru" che dice sciocchezze.
Fortuna che ti consideri un "modesto artigiano", non immagino quale
libert� d'apostrofarlo ti saresti preso se fossi stato "leader di
settore"...
:)

 C++ ha fallito e di molto pure.
eh certo, lo dice "La Storia".
Grazie di esistere... e ' un po' che mi mancava il delirio "Alla
Riolo".. :P

 forse per te...
a proposito di produttività, stavo guardando per i cavoli miei questo 
oggetto:
http://stuvel.eu/flickrapi/apidoc/flickrapi-module.html
analizza il codice, poi ti sfido a fare la stessa cosa in 700 righe 
(commenti compresi) con c++ o qualsiasi altro linguaggio non dinamico.
e anche didatticamente non è mica male, eh...

 Fortuna che ti consideri un "modesto artigiano"
Non mettermi in bocca cosa che non ho detto. E' un modo di interloquire
che a me non piace.
La critica non era a Yagge, era a te. Io ritengo la frase riportata una
sonora sciocchezza, e reputo sia decontestualizzata, perch� nessuno che
abbia scritto pi� di un 'hello, world' pu� affermare una cosa del
genere. La mia affermazione non � sulla base di sogni che ho fatto
questa notte, � sulla base del fatto che ci sono e ci sono stati
valanghe di progetti che su C++ si basano (GCC e MinGW sono compilatori
C++).
Peraltro, a me non piace MAI l'approccio 'ipse dixit'. Aristotele
diceva che la terra era il centro dell'universo, con questo approccio
Galileo non era che un povero scemo.
D'altra parte, dal momento che Python e , credo, anche Ruby sono
interpretati, in qualche maniera deve essere stato scritto l'interprete
(pero' qui non so se C o C++).
Circa l'altro post. Alex Martelli � uno che ha due OO cos� in C++. Dice
spesso, nel post che hai messo anche tu, ma anche nei filmati delle
lezioni in Google che trovi su Youtube, che con Python sei molto pi�
produttivo. E qui sono assolutamente d'accordo.
Io sono sempre per 'usa lo strumento migliore'. Ossia: se devi scrivere
roba che corre, poche storie, C++; sappi per� che devi stare trenta
volte attento perch�, per dire, facilitazioni tipo il garbage collector
non le hai. In alternativa, altro strumento.
Ultima cosa. In 20 anni di onorata carriera, qualcosina di pi�
complicato di due mascherine per data entry l'ho scritto pure io... ;-)
-- 
Ciao!
Luca


ok mi arrendo. '  Il fatto che
"FlickrAPI is the easiest to use, most mature and feature-rich Python
interface to Flickr" prova indiscutibilmente che il C++ sia un
linguaggio superato e non produttivo, e che il miglior linguaggio del
mondo sia Python o se proprio proprio ne dobbiamo fare a meno almeno
un' altro linguaggio dynamicaly typed.
Per oggi ho riso abbastanza :)

 analizza il codice, poi ti sfido a fare la stessa cosa in 700 righe 
Guarda che non è una sfida a chi ce l'ha più... corto... :-DDDDD
-- 
Ciao!
Luca


Mah, sicuro? Io al riguardo la penso di più come Spolsky:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
in sintesi, quando si impara a programmare lo strumento *deve* essere
complesso e tosto. Altrimenti non ti fai sufficientemente le ossa.
bye!

e ' un po' che mi mancava il delirio "Alla Riolo".. :P
Sar�... ma Riolo quando parla � molto++ interessante di un disco rotto
come te.

 
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Mah... a un bambino non insegni il calcolo differenziale, parti con le
addizioni...
-- 
Ciao!
Luca

complicato di due mascherine per data entry l'ho scritto pure io... ;-)
Ma io non lo metto in dubbio. Per�, parlando di *C++ is dumb*,
continui a snipparmi l'introspection suggerita come possibile
argomento di discussione e quindi come si dice chissenef, vi piace
fermarvi al primo rigo delle cose senza andar oltre...
Lo accetto e mi sta bene, chiudiamo qui anche questa e pietra sopra.

 Guarda che non è una sfida a chi ce l'ha più... corto... :-DDDDD
qui non si tratta di competizione... a mio avviso questo è un esempio di 
programmazione che si avvicina al mio ideale di scrittura codice. e 
ovviamente non parlo di graffe e indentazioni.
-- 
++ questo messaggio è scritto in forma ridotta per venire incontro alle 
vostre capacità mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

bye!
"The C programming language was devised in the early 1970s as a system
implementation language for the nascent Unix operating system".
Un linguaggio inventato by design per scrivere un sistema operativo,
notoriamente un task da principiante. Non so, che dirti fai tu :)
Joel ha ragione e non ha ragione: il C ci vuole ma � meglio dopo, cos�
prima spieghi cosa � un algoritmo (con un linguaggio pi� semplice
senza traps and pitfalls che permette di concentrarsi sull'alto
livello) e poi cosa � il modello di Von Neumman (e qui ti servi del C
come perfetta astrazione di questo).
Io cos� la vedo. Il C � conoscenza di base necessaria, ma mica deve
essere il primo incontro per forza.

 __________________________________

 continui a snipparmi l'introspection suggerita come possibile
Perdona, sono limitato io, ma per me le parole hanno il significato che
hanno, ne mi piace la filosofia. O mi spieghi TU cosa vuoi dire, o la
chiudiamo qua.
-- 
Ciao!
Luca

 addizioni...
Siamo d'accordo: ma un matematico il calcolo differenziale lo deve
conoscere, no? Anche se poi va a lavorare nel campo della ricerca
operativa, o a insegnare in un liceo classico, e non vedrà mai più un
integrale in vita sua. Penso che per un informatico sia lo stesso, per
quanto riguarda alcune conoscenze "low level" (puntatori, registri,
garbage collection manuale ecc.) che i linguaggi più recenti tendono a
mascherare. Poi alla fine probabilmente serviranno davvero solo a chi
andrà a lavorare nel settore embedded, ma sono basi che devono avere
tutti.
bye!

 scrivere software mediocre.- Nascondi testo citato
Ti ripeto, forse non conosci bene l'interlocutore con cui stai
parlando.

chiudiamo qua.
Nessun problema, chiusa qui.

Per oggi ho riso abbastanza :)
Non arrenderti. Prenditi il tempo necessario, accetta l'invito e dai
un esempio concreto di quanto sia falso definire il C++ come poco
produttivo rispetto ad un vhll in questo task.

ovviamente non parlo di graffe e indentazioni.
Chiss� perch�, ma ho l'impressione che dopo aver detto agli altri che
sbagliano, che � sbagliato parlare citando esperienze e persone di
primo piano, che le cose di cui si parlava gliele devi spiegare tu
*dopo* che loro hanno gi� sentenziato al riguardo, che sono geni
annoiati per cui ogni strumento � uguale all'altro (tanta � la
maestria), che l'esperienza � una barzelletta, non vedremo una riga di
fatti da parte loro.

parlando.
Forse?. Google mi dice che forse intendevo Wolverine, cercando il tuo
nome... Come 'zzo potrei sapere con chi sto parlando?
Roba da matti, hahaha :)

 essere il primo incontro per forza.
e mica ho detto che dev'essere il primo :^)
Dico solo che limitare le conoscenze a linguaggi basati su astrazioni
lontane dal "modello" base del calcolatore è potenzialmente deleterio.
Per cominciare poi si sa che l'ideale è il MIX... al limite per non
passare troppo da obsoleto ti posso concedere il MMIX :^)
bye!

lontane dal "modello" base del calcolatore � potenzialmente deleterio.
Pi� di quoto, posso solo dirti passami l'indirizzo di memoria del
concetto qui su che lo memorizzo in un puntatore.

 fatti da parte loro.
Io ribadisco. Non esiste uno strumento uguale all'altro. Non esiste lo
strumento universale. Non puoi sperare di aggiustare un'auto solo con
un set di cacciavite, come minimo ti serviranno delle chiavi. Il buon
tecnico � colui che sceglie lo strumento che ha a disposizione pi�
corretto. Io oggi lavoro con C#, ma se dovessi sviluppare una web
application, andrei di corsa a ripassarmi Java senza pensarci due volte.
Circa l'esperienza, vorrei sapere dove l'hai visto scritto.
Circa il 'non vedere'. Vero, io ho scritto valangate di roba che
normalmente non si vede. Pero' a qualcosa serve. Vai a sciare in
discesa? Sappi che hai una probabilit� su tre di aver a che fare con
software mio o nel quale, nella peggiore delle ipotesi, ho messo le
mani...
-- 
Ciao!
Luca

 mani...
E se invece uno va a sciare in salita? :) 

 E se invece uno va a sciare in salita? :) 
Eh, li ï¿œ solo questione di hardware, non c'ï¿œ software che tenga.
Parlo per esperienza!!!
-- 
Ciao!
Luca

E se invece uno va a sciare in salita? :) 
Sta facendo sci di fondo. :)
http://www.nordicwalkingtime.it/wp-content/uploads/2007/12/valerio-checchi.jpg
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 cchi.jpg
ALT! STOP! FERMA TUTTO.
Sebbene Nordic Walking e sci fondo (a passo finlandese, o tecnica
classica) si somiglino e uno sia propedeutico all'altro, son due cose
differenti (il NW non si pratica con gli sci!). Il fondo � questo:
http://webstorage.mediaon.it/media/2007/01/sci_fondo_medium.jpg
-- 
Ciao!
Luca



Non ti sfugge niente, dovresti farti assumere da LSE. :)
Saluti.


 linguaggio superato e non produttivo,
veramente ti avevo invitato a dare una occhiata al sorgente, non di 
guardare le figure.
per darti una mano questo � il link diretto
http://stuvel.eu/flickrapi/apidoc/flickrapi-pysrc.html
rinnovo l'invito, vediamo se anche il prossimo commento � sul dito 
invece che la luna.
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 Non ti sfugge niente, dovresti farti assumere da LSE. :)
Non � quello.
E che io ho iniziato a fare fondo quando avevo 7 anni e ho smesso una
decina di anni fa; poi, ho un istruttore di Nordic Walking in
famiglia...
-- 
Ciao!
Luca

 Roba da matti, hahaha :)
Ripeto almeno oggi ho fatto ridere qualcuno... :-)

mani...
Bello! Raccontami qualcosa se ti va, sembra davvero interessante.
p.s. sciare in discesa? io non scio e quindi ignoro, ma si scia pure
in salita? :O :)
p.s.2 sono di fretta e potrei aver scritto imprecisioni,ma grosso modo
spero capirai quel che intendo dire e non mi accomunerai pi� a quelli
dal paraocchi++
p.s.3 software per sciare, "valangate di roba"... ti piace la montagna
eh?! ;)

Ripeto almeno oggi ho fatto ridere qualcuno... :-)
No dai, ora ho letto tutto, mica volevo darti addosso :)
Non volevo essere scortese, da quello che scrivi hai di sicuro pi�
esperienza di me per� ti sei reso subito conto anche tu che sei
partito a spiegarla in modo contorto, parlando solo di sintassi senza
riferimenti alla conoscenza di pi� paradigmi di programmazione. I
dubbi per via di come ti eri espresso potevano starci tutti. :)
Tutto chiarito.

 eh?! ;)
Francamente quella dello sviluppatore trasfertista, anche se di
trasferte ne ho fatte poche (ma in posto bellissimi) � una vita che
ricordo con molto piacere.
-- 
Ciao!
Luca

tre aziende che in Italia fanno elettronica per tali impianti.
Molto interessante.

 hai la reflection/introspection? via prestazioni.
questo non � vero. o almeno non lo � oltre un certo grado di 
complessit�, invero nemmeno tanto elevato. nel momento in cui usi 
l'introspezione e/o una caratteristica dinamica del linguaggio, ti 
risparmi ogni volta decine e decine di righe di codice di C++ per fare 
la stessa operazione, o comunque qualcosa di analogo. a quel punto � 
vero che in C++ hai la possibilit� di ottimizzare in maniera spinta, ma 
non � mica detto che lo fai. anzi, se vuoi raggiungere gli stessi 
obiettivi di produttivit� e riusabilit� del codice ci sta benissimo di 
ottenere risultati peggiori. infatti linguaggi come python/ruby non se 
la cavano affatto male dal punto di vista delle prestazioni.
� verissimo che linguaggi come C/C++ danno maggior controllo a basso 
livello, ma siamo sicuri che questa sia sempre e comunque fiducia nel 
programmatore ben riposta? :-)
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 fa ho dovuto farlo.
finalmente un minimo di buon senso...

 corretto.
Ti prego, mi spieghi che cosa trovano di cosi' arduo in questa
semplice ovvieta'? :)

 invece che la luna.
Quale parte del concetto "il tipo di linguaggio ideale dipende dal
problema che devi risolvere" non ti e' comprensibile?
No perche' sto cominciando seriamente a preoccuparmi ...:)
Puoi mostrarmi anche altri meravigliosi esempi di programmi scritti in
Python , ma questo che vuol dire? Se ora ti spedissi il codice di
Quake IV in C++ e ti dicessi " e ora riscrivimelo tutto in Python ...
se non riesci a migliorarlo vuol dire che il C++ e' meglio del
Python!" mi prenderesti o no per un idiota? :)

 purtroppo faceva ben più di un Amiga (vecchia serie intendo).
Ma gli Amiga AGA erano di nuovo superiori. Certo, quando sono arrivate le 
super-vga il progetto Amiga era al tramonto... 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 concetto qui su che lo memorizzo in un puntatore.
Ahahah ;^)
bye!

 [CUT]
Certamente avere una solida preparazione di base (su algortitmi, 
strutture di dati, linguaggi formali, paradigmi di programmazione ecc.), 
e conoscere gi� parecchi linguaggi reali, non pu� che facilitare 
l'apprendimento di un nuovo linguaggio.
Tuttavia imparare un linguaggio di programmazione, non � semplicemente 
/dare una scorsa ai manuali per vedere la sintassi/.
Bisogna entrarne nello spirito, apprenderne gli idiomi e le best 
practice, quantomeno.
Non escludo che uno con una solida esperienza, sia in grado di 
correggere qualche bug qua e l� su un'applicazione scritta in un 
linguaggio che non ha approfondito, ma � molto pi� difficile che possa 
effettuare interventi di refactoring pi� estesi (e men che mai 
sviluppare progetti ex-novo, specialmente se complessi).
La cosa poi � particolarmente vera per un linguaggio altamente 
idiomatico come Perl, dove le pi� grosse porcherie le ho viste scrivere 
proprio da chi credeva che si usasse come il C (o, peggio ancora, da chi 
avesse solo esperienza di sed e awk).

 idiota? :)
se è per questo già con questa risposta ti sei già messo per la strada 
giusta.
quella classe è un banale proxy per delle invocazioni a servizi remoti, 
realizzata con una semplice tecnica che prevede l'accesso dinamico agli 
attributi della stessa classe. si tratta di un *esempio* di come un 
linguaggio dinamico come python rende semplice, elegante e soprattutto 
estremamente efficiente l'approccio ai problemi con questa tecnica. 
ovviamente quello che dovevi vedere era la tecnica, non il singolo 
problema... ma fa lo stesso. se avevi argomenti per rispondere avresti 
risposto invece di buttarla in stupidaggini e/o contestare affermazioni 
mai fatte (chi ha parlato di "linguaggio ideale"? eppure era ben chiaro 
che parlavo di *produttività*).
ps: stranamente tu e luc avete lo stesso modo di argomentare, 
politicamente diversi ma tecnicamente stessa scuola.

 produttivo rispetto ad un vhll in questo task.
non c'è mica speranza di un dibattito serio, sai...
 

non c'� mica speranza di un dibattito serio, sai...
Certo che lo so.
E' che sono inguaribilmente romantico, ed essendoci la possibilit� che
riccardo possa avere qualcosa da insegnarmi vorrei sfruttarla, dopo
aver speso tempo in un thread del cacchio senza cavarne nulla di
utile.

 estremamente efficiente l'approccio ai problemi
non l'approccio "ai problemi" ma "ad alcuni problemi". Ad altri e'
piu' indicato C++, ad altri Java, ad altri Erlang. etc etc etc..
il mio punto e' semplicemente questo e mi meraviglio di cosa stiamo a
discutere...

 utile.
Io non ho probabilmente gran che da insegnarti, prenditi il famoso
nuovo libro di Stroustroup, lui si' che ne ha di cose da insegnarti...

 avesse solo esperienza di sed e awk).
Cammello,
Il discorso non era generalistico ma rimango della mia idea: quando
fai questo mestiere i linguaggi sono tool, è importante conoscerli ma
è solo un dettaglio per la risoluzione di un problema (implementazione
dell'algoritmo). E' ovvio se il cliente lo vuole sviluppato in java,
C, o C++ magari anche per problemi di libreria sarai obbligato a usare
quello.
Ma mai nella vita, per farmi uno script da zero userei il Perl...anche
se ripeto,
mi è capitato di correggerli script in Perl.
Un vero informatico può, anzi a mio avviso DEVE astrarsi dal
linguaggio.
Poi è naturale, la tua ultima frase vale per chi usa il Perl come un
lnguaggio di scripting qualsiasi, il C++ come il C o il C come il
Basic.
Come non puoi uccidere le formiche con un cannone, non puoi sperare di
abbattere un albero con uno scalpello da cesello!

 dell'algoritmo).
Ma l'algoritmo devi implementarlo _bene_, dove /bene/ significa 
anzitutto in maniera corretta, ma anche in maniera leggibile, adattabile 
ed efficiente (giusto per citare alcuni requisiti di una buona 
implementazione).
E quanto /bene/ tu riesca ad implementare un algoritmo in un dato 
linguaggio, dipende anche dall'esperienza e dalla familiarit� che hai 
con quello specifico linguaggio.
Non so se per te questa sia una considerazione troppo /generalistica/ 
ma, nel definirla un /dettaglio/, ho come la sensazione che tu stia 
sottovalutando (di brutto) l'esperienza e il training che un moderno 
linguaggio multiparadigma, ricco di builtin ed estensioni (quale Perl, 
ma vale anche per Ruby, Python e PHP), possa richiedere per essere 
utilizzato in maniera ottimale (o anche soltanto in maniera non troppo 
rozza).

 (cut)
Pe nso che stiate segando la segatura con le cose che non si escludono a 
vicenda, e anzi, probabilmente (IMHO) in fondo pensate in modo 
abbastanza simile, solo che vi ostinate ad agrapparvi alla forma di 
quello che volete comunicare invece che alla sostanza. Contenti voi. 
Comunque, non per fare critica, eh, qui i post non-OT sono una rarit�....

On Fri, 10 Jul 2009 00:45:47 +0200, Cammello <varanide@gm41�.com>
wrote:

Sono daccordo con te perfettamente. Linguaggio, editor, "pensiero
algoritmico", il modo di fare testing... e tanto altro, sono parte
integrante della soluzione, mai e poi mai un dettaglio.

 Comunque, non per fare critica, eh, qui i post non-OT sono una rarità....
Io posto la mia piccola esperienza... e ce ne sono di migliori di me.
In quanto alla minuzia... che dirti... forse hai ragione il demonio è
nei dettagli.

 rozza).
Ripeto.
Se devi fare i lavori di fino, chi scrive codice da n anni, dove n >2
e c'ha delle solide basi, anche e non solo universitarie, riesce a
fare ciò con curve di apprendimento sorprendentemente veloci.
Ti porto un esempio del mio lavoro.
Saprai o immaginerai in quanti linguaggi diversi si possono scrivere
pagine dinamiche e cgi-bin. Ho un bel po' di colleghi che fanno
penetration testing, e per lavoro devono scrivere anche le correzioni
ai difetti che trovano. Sono ovviamente programmatori esperti,
prerequisito minimo e indispensabile per la nostra discussione.
Dettaglio: non tutti laureati. Ebbene...
è capitato più di una volta a qualcuno di loro che abbiano presentato
soluzioni all'applicativo di turno scritto nel linguaggio K che magari
loro non conoscevano (il più delle volte hanno anche accesso ai
sorgenti).
Ti assicuro che le soluzioni che loro hanno scritto in linguaggio
sorgente K,  solo qualche giorno dopo, sono ancora lì a funzionare,
non sono certo delle pezze, ed io mi reputo una sonora pippa nei loro
confronti... e ti ripeto che nel passato ho fatto qualcosa di simile.
Non si tratta affatto di geni.

 integrante della soluzione, mai e poi mai un dettaglio.
Vedi hai fatto una listarella sulla quale io sono perfettamente
d'accordo... quasi persino sull'editor....  poi c'hai aggiunto
Linguaggio... e io dovrei cadere nella tua trappola/flame? :-)



già, c'è proprio da meravigliarsi se si sta a discutere di linguaggi qui 
dentro...
è che queste risposte sono ovvie ma fuori dal seminato, è ovvio che i 
linguaggi hanno dei loro domini specifici ma è altrettanto ovvio che se si 
fa un confronto fra due linguaggi sul piano della *produttività* ci si 
riferisce a dove questi due linguaggi si sovrappongono. 
sia python che C++ sono entrambi linguaggi general-purpose e si 
sovrappongono in moltissimi ambiti; inoltre dovresti sapere che python 
"wrappa" spesso e volentieri proprio il C++ in numerose librerie e se non 
fosse vero che scrivere in C++ è (assai) meno produttivo allora non si 
spiegherebbe il perché. 

Non si tratta affatto di geni.
Ma scusa eh... guarda che, mai come in questo caso, stai parlando
appunto di "pezze"!. Per dire, ti presentano il tipico caso di una
roba scritta in php, tu noti si possa fare inclusione dall'esterno di
script malevoli e metti a posto la cosa. Spesso per una correzione del
codice in ambito security, non serve essere esperto del linguaggio
quanto pi� dei tipici errori che vengono commessi (e che espongono la
soluzione ad attacchi) e della loro risoluzione[1]. Vorrei vedere
invece l'esperto di sicurezza a riscrivere l'applicazione e/o ad
estenderne parti in quello stesso o altro linguaggio senza conoscerne
patterns d'uso e idiomi, sai che casino... Penso tu abbia fatto
proprio l'esempio sbagliato stavolta.
E' proprio della differenza tra una (pi� o meno semplice) patch e le
modifiche al codice che un esperto del linguaggio (e del dominio
applicativo in questione, ovvio) pu� fare che stiamo parlando.
L'applicazione, per definizione, dovr� passare tra tante mani e pi�
alta in qualit� si mantiene la codebase, pi� le cose funzionano
meglio. Voglio dire, se ad ogni intervento di manutenzione del codice
ci metton mano persone non esperte in quel/quei linguaggio/i, non ci
vorr� molto per trasformare il tutto in una porcata. E come sappiamo,
la cosa qui da noi succede di frequente dato il vizietto di prendere
gente inesperta per risparmiare e mandarla allo sbaraglio...
Al massimo ti posso concedere che, in taluni casi, sia passabile (ma
anche preferibile, perch� no) avere uno che non � esperto del
linguaggio ma davvero esperto del dominio applicativo; in quel caso si
ciude un occhio e lo si aiuta il pi� possibile a scrivere roba
corretta e idiomatica, perch� lui ci aiuta a risolvere quello che alla
fine davvero conta: il problema.
[1] off by one e format string, ad esempio, li pu� correggere anche
uno che non � esattamente un dio in C, a patto che sia sveglio e si
sia interessato seriamente alle problematiche di sicurezza lato
programmazione. Va da se che, per situazioni pi� complesse, il C vada
padroneggiato e non poco...



Ma quale trappola/flame, semmai � la tua risposta che conduce li... :)
Ma come? Un editor magari SI e un linguaggio NO? Scherzi? Il
linguaggio, quando assimilato bene, � parte integrante di quello che
viene chiamato "workflow", per me � proprio parte di quel flusso in
cui entro e che mi conduce a risolvere il problema.
Per dirti, pensa al REPL fornito dall'implementazione di alcuni
linguaggi. Secondo te, avere la possibilit� immediata di esplorare
tramite codice un idea risolutiva che ti sei fatto riguardo un
problema *non* � parte dell'attivit� risolutiva?
Ti ripeto che non voglio flammare, ma da come parli dovresti leggerti
un p� di libri alla Pragmatic Programmer e riconsiderare l'importanza
che ha il rapporto tra un coder e i suoi linguaggi preferiti/quelli in
cui � esperto. Perch� � una cosa che fa la differenza tutti i giorni,
e non poco.
Cmq leggi il mio post pi� sotto.

 spiegherebbe il perché.
il fatto che ci sia "python fuori e C++ dentro" non ti dice qualcosa
sul fatto che siano necessari e "produttivi" tutti e due?
Per dirla tutta inoltre trovo rivoltante questa parola
"produttivita'". Tanto per cominciare e' troppo generica per avere un
senso.
Scrivere meno righe di codice o scriverle piu' in fretta non significa
affatto "a priori" avere un programma migliore. Ci sono una marea di
fattori di tenere in considerazione (performance, flessibilita' ,
estendibilita' etc) che il termine "produttivita'" non riassume.
Inoltre e' orribile anche da un punto di vista "estetico". La
programmazione non e' coltivare rape un tanto al kg.

 padroneggiato e non poco...

tutto.
Che l'esperienza del singolo, l'intelligenza, il karma, il genio,
l'estro, l'intuizione del momento, il guizzo, la memoria visiva, la
velocit� di lettura e comprensione dei manuali, una eventuale
estensione biotecnologica al cervello in stile Deus Ex per l'EBNF,
anche il culo se vuoi... sia importante � fuori discussione, dicendolo
non sfondi nessun portone anzi passi il ponte levatoio indenne senza
penalit� di sorta e ramazzi pure il cavaliere marrone dall'altro lato.
Ma mai e poi mai saremo d'accordo sulla tua opera di svilimento dei
moderni linguaggi di programmazione, perch� cos� facendo svilisci la
comunicazione che il loro *migliore* *uso* *possibile* permette.
E svilire la comunicazione equivale a svilire l'informatica, l'ho
detto.
p.s. vabb�, l'ho fatta pesante per scherzo ma si � capito meglio cos�
scommetto, vero? ;)

 Comunque, non per fare critica, eh, qui i post non-OT sono una rarit�....
concordo
Andrea 

 detto.
Chiaro, efficace, per me pienamente condivisibile.
Complimenti!