Newsgroup: it.lavoro.informatica
Titolo: LaDoDeDu#005Extra - Ed io dico .. Cobol :-)  - [CFree100%].

 of C in systems programming very challenging
Allora la informatica, per quel che e' la mia visione serve a risolvere
problemi, dividendo quindi gli sviluppatori in due macro-categorie:
#BusinessOriented) = La Inofrmatica serve a risolver problemi in azienda,
sono un artigiano, ho la mia cassetta degli attrezzi, prendo il
martello,la sega i chiodi, le tenaglie, picchio duro e risolvo,
l'importante e' che le cose funzioni bene.
#KernelOriented) = Sono quelli che forgiano il martello, i chiodi, le
tenaglie, conoscon la metallurgia come i Nani delle miniere di grimoria,
mirabili artigiani di strumenti precisi ed affidabili.
giustamente si dice, c'e' la interfaccia grafica e si perde la conoscenza
del processo vero e puro .. concordo in pieno.
Chi mi segue ormai lo avra' capito, io sono un #BusinessOriented) al 100%,
per cui a me dei puntatori non me ne importa nulla.... Ho 20000 righe di
fatture da caricare ... bene server bastardo .. allocami tutte queste
rgihe, usi i puntatori bidirezionali, gli stack-over-heap, gli
heap_and_ciap, le code binarie di markov-schermenlynski .. cazzi tuoi ...
io devo caricare le fatture e presentare un bel report colorato!!!
Ed allora io dico che dovrebeb esser insegnato il Cobol. strutturato,
preciso e senza fronzoli grafici, picchi diretto sui dati(si vabbe'
qualche SQL lo fai, ma potresti farne a meno volendo) ed inoltre esiste un
solida base di software da mantenere ... ergo occasioni di lavoro dopo gli
studi.
Sia ben chiaro che le due categorie di informatici sono INFORMATICI, io
rimango estasiato ad ascolare come funziona il circo, pero' NON e' mio
interesse, non lo sento come il mio campo d'azione, de gustibus, ma SEMPRE
INFORMATICI!!!!
Attendo dunque le vostre opinioni serie segnalo quindi.
#01) Attendo un intevento di salvatore iovene che imamgino lui sia invece
un KrnelOriented al 100%.
#02) Evitate di gugagugheggiare su classi, object-oriented ed altre
scemate sul Cobol che e' ormai superato, ..lo so benissimo, anzi se si
decidesse(paradosso estremo) .. ale'' da domani tutto Java ed Oracle, sai
quanto lavoro arriverebbe nel mondo Occidentale :-).
NON e' morto lo spirito del Cobol pero' questo sia ben chiaro .... cercate
su wikipedia e deliziatevi.
#03) I guga-guga[opensource] li vedo gia' pronti a dire.. ecco son quelli
come te che hanno fatto perder la "poesia dell'informatica", i puntatori
sono arte, perche' ti referenzi alla memoriae cibi e cibu...a me non frega
nulla, ho 4giga se voglio usarli tutti per un vettore di interi ma saranno
fatti miei :-) .. evitate di gugagugheggiare oppure motivate seriamente
quanto dite.
NON ho sonno e sono in forma .. ciaoo ed alla prossima .. 
buon anno a tutti :-)
DucaLamberti74
P.S.: Per chi mi segue e si delizia delle cose che dico, non peda la
fiducia, mi faro' vivo, non presto ma ci sono sempre :-).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 io devo caricare le fatture e presentare un bel report colorato!!!
Illustrissimo Duca, mi permetto di dissentire ;-)
Conosco (spero bene) entrambi gli aspetti della programmazione, e proprio 
per aver smanettato con dovizia di particolari a basso livello mi trovo a 
maggior ragione in grado di apprezzare i favolosi strumenti che un ambiente 
di sviluppo moderno mette a disposizione; aver fatto i salti mortali per 
bilanciare malloc() e free() in C spingerebbe chiunque ad amare carnalmente 
un garbage collector, e questo è un dato di fatto.
Allo stesso tempo, però, la mia conoscenza di ciò che avviene "sotto il 
cofano" mi permette di sfruttare al meglio gli strumenti che ho, sapendo in 
ogni momento cosa avviene quando attacco un dataset a un datagrid tramite un 
databind (tanto per usare un paragone che ti è caro); sono in grado di 
*capire* perché un file XML è *male* quando si tratta di archiviare e 
manipolare dati (as opposed to "spedirli a un web service", ad esempio); so 
*perché* è terribilmente inefficiente usare una lista collegata al posto di 
un array quando c'è da accedere tramite indice, ma allo stesso tempo è 
letale *non* usarla quando c'è da inserire e rimuovere elementi al volo; e 
così via.
Se avessi iniziato a programmare partendo da un ambiente grafico, integrato, 
"business oriented", non conoscerei un mare di dettagli, dei quali, proprio 
perché li conosco, ora posso dire di *non* poter fare a meno, e che se non 
li avessi ben presenti sarei sulla strada ottimale per scrivere codice 
terribilmente inefficiente.
Ad esempio, la mia (non così eccelsa, in verità) conoscenza della teoria dei 
database relazionali mi permette ad esempio di *capire* cosa succede quando 
metto due tabelle in join, mentre chi pretende di scrivere codice SQL senza 
nemmeno avere idea di cosa si un prodotto cartesiano ottiene risultati... 
beh... non ottimali, ecco. Aneddoto: un mio collega, qualche tempo fa, aveva 
necessità di prendere dei dati da una tabella, calcolare un certo valore per 
ogni riga e inserire i risultati in un'altra tabella insieme ad alcuni campi 
della prima; doveva però evitare di inserire dati duplicati nella tabella di 
destinazione, visto che alcuni duplicati, in effetti, per il tipo di 
problema, *potevano* finirci dentro.
Il suo algoritmo:
- Prendi una riga
- Calcola il nuovo campo
- Controlla che la riga non sia già presente nella tabella di destinazione
- Inserisci la riga se non c'è
- Ripeti per ogni riga
In particolare, il terzo punto consisteva in una bellissima query SELECT 
sulla tabella di destinazione, la cui dimensione ovviamente *aumentava ad 
ogni riga inserita*.
Dopo un po', il collega viene da me e mi dice "ma come mai più il lavoro va 
avanti e più rallenta?".
Quiz: da cosa capisci che il collega in questione non ha la più pallida idea 
di cosa significhi "algoritmo di complessità esponenziale"? ;-)
Secondo quiz: da cosa capisci che il collega non ha idea di cosa sia e come 
funzioni un database relazionale, e in particolare del fatto che si lavora 
su *tabelle* e non (mai!) su *singole righe*?
Terzo ed ultimo quiz: credi che al collega, nonostante il suo orientamento 
"business", avrebbe giovato studiare l'SQL e in database relazionali in modo 
un po' più serio, nonché avere almeno un'infarinatura di teoria degli 
algoritmi?
Per tornare al discorso originale: no, caro Duca, la distinzione di cui tu 
parli è puramente fittizia; sarebbe come voler essere un pilota senza sapere 
come funzioni un motore, almeno nelle sue linee essenziali; per poi 
lamentarsi quando questo si spegne perché non hai gestito correttamente il 
rapporto tra cambio, frizione ed acceleratore.
Ovviamente questo non significa che un bravo pilota debba essere in grado di 
costruirsi un motore da solo; ma sapere come funziona è vitale, se vuole 
essere un pilota quantomeno decente.
Massimo


L'algoritmo era corretto.Quello che mancava al tuo collega erano la 
conoscenze tecniche per realizzare un programma efficiente.
Di programmi scritti MALE ne abbiamo visti tutti parecchi....
Aneddoto: una volta in una software house mi chiesero di riguardare il 
programma
di immissione bolle (documenti di trasporto) scritto da un altro cosidetto 
programmatore che apparentemente non riusciva a risolvere il problema.
Il tabulato, scritto in RPG,  era lungo molte decine di pagine nel classico 
modulo continuo.
Rimasi molto stupito del fatto che...... le prime 25-30 pagine erano tutte 
DI COMMENTI che spiegavano cio' che il programma faceva, il restante era di 
una farraginosità assoluta e totalmente incomprensibile.
Questo per dire che con il talento puoi sopperire alla buona volonta' ma non 
viceversa...:-))))
ciao
fm

 L'algoritmo era corretto.
No, non lo era.
Se proprio vuoi saperlo, l'algoritmo corretto era inserire tutti i risultati 
in una tabella temporanea e poi fare una "SELECT DISTINCT" su quella.
Massimo


questa e' la tecnica SQL per risolvere il problema.
La tecnica ovviamente dipende dall'ambiente hw/sw in cui si opera.
Lo stesso algoritmo potrebbe essere codificato in maniera diversa, con 
linguaggi diversi.
Ad esempio in Cobol o RPG, si possono scrivere istruzioni per aggiornare ed 
inserire records in tabelle di database,  senza far uso di  sql.
ciao
fm
"Ci sono piu' cose in cielo ed in terra, Orazio, di quante ne sogni la tua 
filosofia".  (Amleto, W.Shakespeare)

 Illustrissimo Duca, mi permetto di dissentire ;-)
Ci mancherebbe, viva il confronto e lo scambio di idee.
Letto il tuo intervento, anche io sono affascinato da quello che avviene
sotto il cofano, e ci mancherebbe che in una scuola di formazione
seria(non questa universita' italiota che sforna soltanto culi pronti
all'incetriolatura senza neanche irrobustirli piu' di tanto affinche'
durino almeno fino ai 35/40anni) i puntatori, malloc, garbage collection
et similia vengano insegnate, dico soltanto che non e' necessario che uno
arrivi nel mondo del lavoro e ne sappia di tali argomenti i dettagli.
L'esempio che citi tu dell'SQL lo approvo in pieno, ma quello che tu dici
e' buona conoscenza dello strumento, se uno ha un minimo di cultura ed ha
letto qualche libro sa bene che quando utilizza SQL deve pensare a livello
di insieme e non di riga ... i cursori o soluzioni row-by-row sono
l'ultima spiaggia.
Io, se sono uno sviluppatore SQL, pero' NON devo conoscere piu' di tanto
cosa succede, faccio la query e dico ... brutto bastardo dammi i dati,
come ottimizzi, come fai il parsing, come te la smazzi sono fattacci tuoi
:-)
Bell'intervento, alla prossima :-)
