Newsgroup: it.lavoro.informatica
Titolo: e poi dite che non si trova lavoro...

basta chiedere a zio Bill!
http://punto-informatico.it/p.asp?i=54224
ps: una bambina di 10 anni... che le avranno dato da mangiare???

 programmazione del C64 o dello Spectrum/ZX80/ZX81..."
:)
Quando avevo il CV vuoto ci mettevo dentro studi e progetti che avevo fatto
in passato come i virus
Secondo me uno che ha fatto un virus e' gia' una garanzia di molte cose.
Pero' non produceva grandi effetti, un po' perche' puoi pensare : Questo e'
strano
Inoltre e' raro che l'intervistatore e' in grado di capire che se veramente
fai un virus conosci la macchina meglio di chi la ha progettata, questo
anche se e' un tecnico.
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


http://punto-informatico.it/p.asp?i=54224
Mha... prima (in ordine non cronologico) fa in modo che ""chiunque""
possa scrivere un programma (con VB e simili), dimenticando di sudare
su Assembly, C, Cobol... Poi sviluppa SO che allontanano il
programmatore dall'HW (cosa, per altro, giustissima). Poi inonda il
mercato con le  applicazioni che servono di più (Office, Browser web
ecc.). Alla fine, cosa resta da fare ai programmatori, ed alle ditte
in genere, che possa affascinarli e, soprattutto, arricchirli? La
contabilità?
Comunque io porrei l'accento sulla parola "usare", riferita alle nuove
tecnologie. Oggi i giovani "usano" le nuove tecnologie. Negli anni
'80, i giovani "imparavano" le nuove tecnologie. Io metterei, nelle
ricerche di programmatori: "è richiesta la conoscenza della
programmazione del C64 o dello Spectrum/ZX80/ZX81..."
Stefano

 Secondo me uno che ha fatto un virus e' gia' una garanzia di molte cose.
poi chiamano il cliente e gli dicono "abbiamo trovato quello str*nzo che sei
anni fa vi ha mandato per aria tutto l'archivio della contabilità bla bla
bla....quanto ci date per mandarvelo lì, così lo massacraete di botte?"

 programmazione del C64 o dello Spectrum/ZX80/ZX81..."
magari, così potrei aggiungere qualche riga nel cv, insieme a conoscenza 
architettura mips e assembly :-)
Peccato che non mi serva a niente aggiungerle, anche se ancora oggi 
qualcuno che ci lavora in italia c'è...

 programmazione del C64 o dello Spectrum/ZX80/ZX81..."
Quoto. Molti programmatori oggi sanno usare solo VB o peggio VBScript e 
basta...
Non sanno neanche lontanamente cosa siano LDA, STA, ROL, JMP ecc... 
:-)))
-- 
______________________________________
Luc (32, CO, VC++ Programmer)
Editorial Systems Software development
______________________________________

 programmatore dall'HW (cosa, per altro, giustissima). Poi inonda il
perdonami ma questa è una serie di sciocchezze da bar. Per essere un buon 
programmatore OO non è affatto necessario passare per la programmazione in 
Assembler o qualunque altro linguaggio procedurale/strutturale. è come dire 
che non si può diventare grandi chef se prima non si è fatto l'agricoltore o 
l'allevatore. Inoltre ti posso garantire che si suda e anche molto anche 
avendo a disposizione Visual Studio, in fondo si vede e anche tanto la 
differenza fra uno che scrive codice avendo passato le sue serate sui libri 
della Gang of Four e uno che si legge i For Dummies.
saluti
Roberto 

Non sanno neanche lontanamente cosa siano LDA, STA, ROL, JMP ecc...
Oggi la gente guida le automobili senza sapere neanche lontanamente cosa sia 
un calesse...
saluti
Roberto 

 un calesse...
Male. Non avere la "storia" alle spalle, è sempre un errore. In tutti i campi. 


campi.
leggere o meno su un libro che il calesse è esistito e vederne una foto è 
ininfluente circa le reali capacità di guida di una autovettura moderna, 
sono i principi della buona conduzione che devono essere conosciuti (codice 
della strada, buon senso alla guida, ecc.) non gli strumenti con nel passato 
ci si è spostati da un posto all'altro.
è esattamente come dire che per saper programmare bene è necessario sapere 
che cosa succede nello stack o nell'heap alle variabili, agli oggetti 
istanziati e alle routine/metodi richiamati, ed è ininfluente ai fini della 
programmazione in C# o Java sapere quale fosse la sintassi dell'assembler o 
quella del Pascal. Che poi, come certe comunità di amish negli USA usano 
ancora solo il calesse, ci siano programmatori che scrivono firmware in 
assembler ci sta tutto ed è un bene che sia così, ma questo non toglie 
minimamente autorevolezza a chi programma OO senza essere passato dai 
linguaggi macchina.
Che poi parliamoci chiaro saper scrivere un programma che funziona in 
assembler non significa saperlo fare _bene_: ricordo a scuola (ITIS perito 
informatico) il mio compagno di banco che scriveva listati immancabilmente 
il 25% circa più brevi dei miei che risolvevano lo stesso problema.
saluti
Roberto 

 Roberto
Ciao,
Marco.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

> A me sembra piu' calzante dire che puoi diventare un grande chef 
[SNIP] 
ovviamente era
A me sembra piu' calzante dire che *non* puoi diventare un grande chef 


 Roberto
Ciao,
Marco.


 il 25% circa più brevi dei miei che risolvevano lo stesso problema.
Era più bravo di te. :)


 parla.
quello è un problema che frega chiunque, anche i più esperti se non ci 
si imbattono da molto tempo.
Il problema dell'endianess è il classico che salta fuori quando qualcosa 
non funziona e lavori con apparecchi strani fatti da altri. e non sai 
cavarne un ragno dal buco quasi sicuramente è colpa dell'endianess :-)
Una volta l'ho sparata e ci ho preso al primo colpo, nessuno capiva cosa 
fosse ma tutti conoscevano il problema dell'endianess, il più è 
ricordarsi di certi tecnicismi improbabili o meglio poco considerati dai 
più.

 di periferiche in assembly.
scusa ma che c'entrano lo stack i thread, i processi, i frame di attivazione 
e compagnia bella con Assembler, C, Cobol? qui non si sta parlando di come 
funziona e di come č archhitetturato un processore, qui si afferma che non 
aver programmato nella propria vita con linguaggi di piů basso livello 
(livello dei costrutti ovviamente) rispetto a vb, significa non saper 
progammare bene.
Ripeto č una sciocchezza.
Per fortuna i thread, ecc. ecc. sono _indipendenti_ dal linguaggio di 
programmazionbe che si utilizza, quale esso sia, di basso o di alto livello. 
il compilatore č lě apposta.
saluti
Roberto 

 Roberto 
io non sono mai salito su un cavallo (oltre a quelli in legno!)
 però vado regolarmente in bici, è valido per la patente di guida???
luca
--  
Postato da Virgilio Newsgroup 
http://newsgroup.virgilio.it
Completo come il newsreader, ma senza il newsreader

 nello stack e' ininfluente se programmi in Java ?
Guarda che sto esattamente dicendo il contrario. anche dagli altri post che 
hai scritto percepisco che mi sono espresso male:
io parlo degli strumenti (i linguaggi di programmazione qualunque essi 
siano) in contrapposizione con le architetture dei processori elettronici. 
queste ultime esistono indipendentemente dagli strumenti utilizzati per 
manipolarle ed ottenere precisi risultati. tali strumenti sono i linguaggi 
di programazione. ripeto, non conoscerne alcuni e conoscerne altri _non_ è 
necessario per essere dei buoni programmatori in quelli conosciuti.
saluti
Roberto 

Era più bravo di te. :)
e secondo te perchè mi ero messo vicino a lui? ;-)
saluti
Roberto 

 progammare bene.
No, significa che più di tanto non saprai fare. Se ci fosse bisogno di hard-
coding saresti nei pasticci... 


coding saresti nei pasticci...
se c'è necessità di fare hard coding significa che la problematica riguarda 
una sfera applicativa di basso livello (molto vicino all'hw), ambito che uno 
sviluppatore enterprise non affronterà praticamente mai.
e comunque non ho capito il "più di tanti non saprai fare": c'è moltissimo e 
di più da fare in ambito enterprise, comptenze che fra l'altro comportano un 
continuo autoaggiornamento anche fuori dall'orario di lavoro (anzi 
soprattutto). Infatti se qualcuno mi viene a dire che è esperto 
contemporaneamente di programmazione enterprise e assembler le cose sono 
due, o è un autentico genio leonardiano o è solo un pallone gonfiato.
se ho bisogno di hard coding, fatto bene, chiamo un esperto di hard coding, 
semmai in ambito enterprise ce ne fosse bisogno.
saluti
Roberto 

Assembler o qualunque altro linguaggio procedurale/strutturale. è come dire 
Non ho mai detto che sia indispensabile, per essere buoni
programmatori, ma semmai che, se le sai fare, difficilmente sarai un
cattivo programmatore. Il resto sono tue interpretazioni di ciò che ho
scritto, ma non è ciò che ho scritto e neppure ciò che volevo venisse
inteso.
Per me, se sai programmare in assembly (non in assembler! e questo la
dice lunga...) sei avvantaggiato anche nella comprenzione dei
meccanismi che stanno sotto interpreti e compilatori,  VB compreso
(che, tra l'altro, "uso" anch'io).
Stefano

quella del Pascal. Che poi, come certe comunità di amish negli USA usano 
...
Nonostante tutto, mi hai dato l'occasione per rafforzare le mie tesi
(anche se non sono esattamente quelle che sono seguite, nel thread).
Tu scrivi "sapere quale fosse la sintassi dell'assembler", dando per
scontato che l'assembly sia un linguaggio arcaico, ormai morto o
relegato nel pc di qualche romantico '80ottottino. Mi dispiace, ma
devo darti una cattiva notizia: l'assembly NON è un linguaggio arcaico
ma è la base di TUTTI i compilatori. Il codice macchina generato da un
compilatore _è_ in linguaggio assembly. Il codice generato dal C...
dal C# e, perché no, in ultima analisi anche da Java, _è_ codice
assembly.
La tua convinzione che l'assembly invece sia una lingua morta nasce
forse proprio dall'esistenza di linguaggi "evoluti", come il VB, che
ti nascondono quel che c'è sotto. Questo è innegabile (ma puoi
comunque negarlo, essendo libero di scrivere qualunque cosa) e, IMHO,
significa una cosa semplice: una "sudditanza" tecnologica rispetto a
chi produce compilatori/interpreti. Sì come i programmatori si
allontanano dalla conoscenza dell'hardware (anche inteso solo come
CPU) altrettanto aumenta la loro dipendenza da chi invece le
conosce... e produce compilatori, sistemi operativi... ecc. ecc. ecc.
La questione comunque non è "sei un bravo prgtore" o no. La questione
è "fino a che punto sei padrone degli strumenti che 'usi'"?
Stefano

 (che, tra l'altro, "uso" anch'io).
non ho capito la frase tra parentesi: ripeto assembly, assembler, C, Cobol, 
Pascal, C#, TklTk, ecc. non sono altro che interfacce "human-readable".
se poi intendevi dire che l'assembly è il linguaggio e assembler il 
programma che traduce lo mnemonico in linguaggio macchina, bè l'uso di uno 
come sinonimo dell'altro è molto diffuso, ma non mi sembra il caso di 
sottilizzare fino a questo punto.
saluti
Roberto 

 ha scritto nel messaggio 
news:dboaql$dhp$1...@newsreader.mailgate.org...

ma guarda che su questo siamo perfettamente d'accordo. con un paio di 
precisazioni:
-sul fatto dell'arcaicità io mi riferisco in primis alla vecchiaia pura e 
semplice del linguaggio, non tanto alla sua utilità o meno.
-sul fatto della padronanza degli strumenti io credo che sia un problema che 
non può esistere: migliaia di righe di codice in Java, mesi e mesi uomo di 
progetto di applicazioni enterprise sarebbero impensabili se dovessimo 
programmare in assembly. è come dire che una volta potevamo essere sicuri 
che il nostro calesse frenasse bene perchè i pattini li facevamo noi stessi 
con la pialla e sapevamo cosa stavamo facendo, oggi invece la nostra 
sicurezza stradale l'abbiamo demandata ad altri perchè non siamo in grado di 
poter produrre con le nsotre mani i dischi dei freni, le pastiglie, 
l'impianto abs e il leveraggio che trasmette la pressione del nostro piede 
sul pedale all'impianto idraulico. Ebben si, stanno così le cose, ma oggi ci 
spostiamo da Milano a torino in un'ora e mezza, un tempo ci impiegavamo un 
paio di giorni. Non può esistere come problema perchè nel momento in cui la 
nostra attività che si basa sui nostri strumenti ha come vincoli delle 
aspettative di qualità, complessità e tempo, come quelle moderne, per forza 
di cose è necessario delegare attività ad altri. nel mondo dello sviluppo 
software vuoi la crescente complessità delle architetture dei processori (un 
PIV non lo possiamo confrontare con uno Z80), vuoi la enorme complessità 
delle soluzioni applicative che ci vengono richieste, ci obbliga a delegare 
attività come la realizzazione del linguaggio macchina ad altri che si sono 
specializzati. altrimenti non si raggiungerà mai il risultato.
Ripeto, ci sarà sempre di più la specializzazione nell'ambito della 
tecnologia, quindi coloro che si specializzeranno in ambiente enterprise 
sempre di più non conosceranno i linguaggi di più basso livello, ma anzi ci 
si sposterà sempre di piùsu linguaggi di ancora più alto livello e paradigmi 
di programmazione e modellazione che andranno anche oltre l'OO.
saluti
Roberto 

sottilizzare fino a questo punto.
Che ci vuoi fare, mi piace essere preciso. Se sbaglio, correggimi...
non mi offendo e penso che anche per gli altri sia così.
Stefano

 i calcolatori non si basano sul C o sul Cobol.
Io mi riferivo piu' cha altro all'assembly, visto che i 
compilatori
che conosco io di solito generano prima l'assembly a partire dai
sorgenti e poi traducono in linguaggio macchina.
Per il resto probabilmente c'e' stato qualche fraintendimento.
Ciao,
Marco


 Roberto
Puo' darsi che sia vero ma a me risulta che mentre ad un certo punto
(inizio/meta' anni 90 mi sembra ?) sembrava che l'OO fosse la panacea 
di tutti i mali, oggi piu' di uno ne comincia a vedere i limiti. 
Alcuni addirittura teorizzano metodologie praticamente opposte all' OO 
(vedere ad esempio "Extreme Programming" di Kent Beck e/o 
http://www.extremeprogramming.org/
).
Ciao,
Marco.


di cose è necessario delegare attività ad altri. nel mondo dello sviluppo 
...
Ottimo intervento, così è tutto più chiaro. Per fortuna, comunque, non
siamo ancora così lontani dal "basso livello", neppure quando usiamo
linguaggi ad "alto livello". Da qui la mia opinione secondo cui serva
(o, se vuoi, sia utile) ancora conoscerli.
Stefano

 sviluppatore enterprise non affronterà praticamente mai.
Può capitare che il 95% del codice sia di alto livello, ma c'è un 5% 
"hardcoded". Che fai? Ti ritiri?


 e secondo te perchè mi ero messo vicino a lui? ;-)
Capisco, a scuola avevo il tuo stesso problema in informatica... Tutti volevano 
far "gruppo" con me... Tanto sapevano che non gli avrei fatto far nulla, facevo 
tutto io meglio e più in fretta. Che tempi... ;) 


 Non sanno neanche lontanamente cosa siano LDA, STA, ROL, JMP ecc...
Io usavo solo NOP :-)

 
http://www.extremeprogramming.org/
).
perchè l'OO è una metodologia di lavoro? E l'XP è opposta alla 
programmazione OO?
Non mi torna...

 (che, tra l'altro, "uso" anch'io).
Innanzitutto vorrei proprio sapere in quanti conoscono alla perfezione 
il processo di compilazione completo, senza entrare nei dettagli di uno 
specifico compilatore.
A mio avviso non serve assolutamente conoscere assembly per programmare 
bene, ma ci mancherebbe altro. Più che altro è una questione di 
consapevolezza. I programmatori guru di assembly (di qualsiasi natura, è 
proprio una passione naturale di alcuni) che ho conosciuto, ai quali io 
non appartengo anche se ho programmato molto e conosco vari assembly, 
hanno difficoltà a programmare "bene" con altri linguaggi o framework, 
perchè hanno la mentalità troppo di basso livello. Invece che aiutarli 
peggiora il loro modo di programmare.
Io ho una mentalità di alto livello, per mia attitudine, quindi nel fare 
un programma assembly non ottengo il risultato migliore nel minor tempo 
e linee di codice possibili, però ci riesco. Non credo che conoscere 
bene molti assembly mi sia di aiuto nel programmare in altri linguaggi, 
mi è di aiuto solo come consapevolezza id ciò che avviene da quando 
schiaccio sul pulsante "compila" a quando vedo qualcosa che esegue a 
schermo.
L'unico momento della mia vita in cui mi è servito davvero conoscere a 
fondo assembly (alcuni preistorici) è stato all'univeristà all'esame di 
linguaggi e compilatori, quando si studiava (spero ancora oggi) il 
processo completo di compilazione con tutti gli algoritmi di 
ottimizzazione e linking più importanti. Lì senza conoscere assembly 
sarebbe stata un po più dura, ma niente di che.
Nel mio lavoro ogni tanto salta fuori l'esigenza di ottimizzare 
procedure in assembly, ma per quello, anche se altri me compreso ne 
sarebbero capaci, ci sono figure più esperte e dedicate.
In nessun settore esiste l'esigenza reale di ottimizzare codice in 
assembly e si delega questo compito ad un programmatore non 
specializzato in quello, a meno che non si voglia proprio fare le cose 
in modo non realmente ottimizzato :-)
Secondo me, per concludere, si programma benissimo anche senza conoscere 
assembly, il quale non serve a una mazza (e io ho iniziato a programmare 
con quello praticamente!), perché l'approccio imperativo, OO, ricorsivo 
o quello che volete voi, astraggono dal sapere che per fare un ciclo in 
assembly bisogna smanettare nel dovuto modo ecc ecc
Lasciamo libero ciascuno di programmare con il livello di astrazione per 
cui è più portato, se me lo consentite, o che più gli piace o da 
soddisfazione, conoscerlo o meno è solo consapevolezza e non serve a 
niente, soprattutto ai nostri giorni dove si programma su librerie, 
framework, api e quello che volete voi, magari agli inizi quando si 
programmava in C e non esisteva nulla di fatto poteva tornare utile, 
soprattutto per i driver.

soprattutto per i driver.
Come dicevo, dipende dal settore in cui ti muovi. Anche recentemente,
ho dovuto riscrivere alcuni parti di codice, usando assembly inline in
un'applicazione rigorosamente C++. Si trattava di grafica 3D
(modellazione solida, per l'esattezza). Una banale funzione in C, per
disegnare un cilindro, ha ottenuto una velocità più che doppia,
riscrivendo alcune righe in assembly.
In fondo, quella "consapevolezza" di cui parli è l'aspetto più
importante. Non direi però che non serve a nulla. Dipende da caso a
caso, forse, ma non essere così tassativo.
Stefano

 caso, forse, ma non essere così tassativo.
hai ragione, dipende dal settore, ma nei settori come quello a cui ti 
riferisci tu, se serve scrivere e ottimizzare molte cose in assembly, ci 
sono figure dedicate a farlo. Un programmatore può benissimo realizzare 
le più complesse funzioni (librerie) su nurbs, compenetrazioni solide, 
animazioni real-time senza conoscere nemmeno l'esistenza dell'assembly e 
conoscerlo non l'aiuta per niente.
Come è successo nel tuo caso, e succede alle volte anche a me, quando 
serve ottimizzare qualcosa c'è una figura dedicata non è indispensabile 
assolutamente conoscerlo. Poi nel tuo caso conosci sia alto livello che 
assembly ed è un pregio, senza dubbio, ma un pregio che serve a pochi e 
in rare occasioni, non c'è da vantarsene più di tanto o scriverlo a 
lettere cubitali nel cv.
Chi lo sa bene e ci deve lavorare lo deve specificare, ma se ti occupi 
di altro e "potresti" averne bisogno è un vantaggio proprio da poco, 
come ne esistono altre centinaia.
Io cmq faccio parte di quelli che lo conoscono e ogni tanto lo usano, ma 
non da alcun vantaggio nelle alte fasi di programmazione e si usa 
davvero in rarissime occasioni, e quando serve per ottimizzazione non 
per necessità di puro funzionamento.

 ha scritto nel messaggio 
news:885b8d7568a2843b1ec...@mygate.mailgate.org...

Perdonami, ma stai facendo un po' di confusione.
l'extreme programming è una metodologia di gestione del processo di sviluppo 
sw, non ha nulla a che vedere con il paradigma OO. L'xp può essere applicato 
a qualsiasi linguaggio di programmazione anche procedurale, indica invece 
delle pratiche consigliate per gestire il ciclo di vita del progetto 
teorizzando di lasciar perdere l'approccio waterfall (analisi, 
pianificazione, sviluppo test, rilaascio) e di spostarsi su un approccio 
ciclico di breve durata e finalizzato alla produzione di un ben preciso set 
di funzionalità da requisiti utilizzando anche tecniche di collaborazione in 
team nuove come il pair programming.
saluti
Roberto 

 ha scritto nel messaggio 
news:dbodjs$gj1$1...@newsreader.mailgate.org...

Alla fine credo siamo arrivati a capire reciprocamente che in fondo la 
visione, a parte sfumature di bordo, è la stessa.
Io in effetti non mi sognerei mai di dire che l'assembly e i linguaggi di 
basso livello non sono più necessari,
ci mancherebbe. Sto dicendo che in informatica, come nelle scienze fra il 
tardo medioevo e l'inizio dell'era moderna, non è più possibile proporsi 
come profondi conoscitori a tutto tondo, ma è necessario specializzarsi in 
quanto le conoscenze e le complessità con cui ci confrontiamo sono via via 
più grandi. Una volta Leonardo era pittore, scultore, anatomista, ingegnere, 
filosofo, architetto, oggi tutto questo non è più possibile, l'architetto 
nel momento in cui progetta una struttura come la piramide di vetro e 
tubolari di metallo del Louvre, non conosce affatto quale sia il processo di 
basso livello di raffinazione dell'alluminio e la sua lavorazione al fine di 
renderlo un tubo con certe caratteristiche di resistenza e durata, ciò non 
toglie che sia comunque un ottimo progettista di strutture architettoniche.
Certo è che se non ha studiato scienza e tecnica delle costruzioni, in cui 
gli hanno insegnato i fondamenti della statica e della dinamica, mai ne 
verrà a capo.
Così, io credo saremo noi, il nostro percorso di studi iniziera per forza 
sempre dalla macchina di Touring per poi passare agli stack, gli heap, i 
processi ed i thread, poi ci sarà per oguno di noi un cammino differenziato 
a seconda che si vada verso il basso o verso l'alto.
saluti
Roberto 

 
Verissimo, le ottimizzazioni che puoi fare in assembly non le puoi fare 
con nessun linguaggio. Era il 1994 quando sotto ms-dos su un 486 dovevo 
far muovere un'immagine sullo schermo con una risoluzione di 640x480 e 
256 colori senza far apparire la minima distorsione, quindi dovevo 
sfruttare per forza il solo infinitesimo tempo di ritraccia, l'unica via 
di uscita fu l'assembly
Ciao

 Io usavo solo NOP :-)
Si usava per crakkare il codice! Mettevi le NOP al posto dei "check" di 
sicurezza e andavi liscio... ;) 


con nessun linguaggio. Era il 1994 quando sotto ms-dos su un 486 dovevo 
...
Certo, non capita tutti i giorni... ma sono soddisfazioni!
TI99 Texas Instruments? ;)
Stefano

 wrote in message
news:dbntqb$slf$
1...@newsreader.mailgate.org
forse ti sfuge qualcosa!!!!
io ho programmato con tutti i linguaggi di programmazione 
(anche Assembler,ZX80 e ZX81,schede a microprocessori).
Ma ora i tempi sono cambiati (in meglio),ci sono linguaggi più
potenti e affidabili e si fanno applicazioni migliori.
Un programmatore deve seguire le evoluzioni dei vari sistemi e 
utilizzarli al meglio.
Io quando programmavo in assembler f acevo una fatica boia e diventavo
matto.Per fare qualche istruzione funzionante ci volevano ore.
Fidati è meglio adesso!!!!!!!!!!!
paolo


 Fidati è meglio adesso!!!!!!!!!!!
Sul fatto che si facciano applicazioni in modo più semplice, son
d'accordo. Non lo sono sul fatto che si facciano applicazioni migliori.
Quando col DOS avevi a che fare, dovevi fare applicazioni che stessero
in 540Kb. e li era tutto un limare e ottimizzare codice per starci e
per far si che le applicazioni fossero efficienti.
Oggi con VB fai applicazioni in un quarto del tempo, e non ci vogliono
grandi tecnici. Però sono elefantiache e lente. Mi si dirà: vabbè, ma
oggi le macchine sono più potenti, per cui non hai problemi. Ecco, è
proprio questo che contesto. Oggi, con tutto che abbiamo macchine di
uno o due ordini di grandezza più potenti rispetto a quando ho iniziato
io, abbiamo applicazioni che girano grossomodo con la stessa velocità
(mentre, a rigor di logica, una finestra dovrebbe aprirsi mentre sto
ancora pensando di aprirla).
E aspetta a gioire di Java o di .NET, belli ma pesanti!!
-- 
Ciao!
Luca

 Stefano
si ;-)

E aspetta a gioire di Java o di .NET, belli ma pesanti!!
Mi hai tolto la parola di bocca. Prova a far girare un'applicazione
DOS di "una volta" sui PC di oggi e vedrai che è terribilmente veloce.
Fai girare un qualunque applicativo "all'avanguardia" e sarà, in
confronto, terribilmente lento (almeno come interfaccia). Dove
l'inghippo? Colpa dei linguaggi usati? In parte sì. Colpa dei DB
sottostanti? In parte, di nuovo sì. Colpa del SO? In parte... di
nuovo... sì. E il programmatore, non ha nessuna colpa? Ne ha eccome...
IMHO.
Però gli utenti si sono abituati ad aspettare un secondo o due, perché
si apra una finestra... e nessuno si lamenta. Di conseguenza, i
programmatori si adeguano e nessuno pensa più a scrivere programmi
efficienti. Conta di più consegnare velocemente un programma che
scrivere un programma veloce. Del resto, si programma per vivere... e
più programmi/personalizzazioni/ecc. consegni, più guadagni.
Questo non toglie però, che, dal punto di vista tecnico, gli attuali
strumenti a disposizione siano relativamente lenti e pesanti, anche se
certamente più potenti. Questo non significa fare una campagna per
abolire il nuovo... ma neppure ci si può permettere di denigrare
quegli strumenti che si ritiene (a torto) sorpassati.
Stefano

 quegli strumenti che si ritiene (a torto) sorpassati.
Perň nessuno ha denigrato i vecchi strumenti, si č solo affermato che non č 
vero che per essere buoni programatori con i nuovi strumenti non č 
necessario conoscere quelli vecchi.
Mi sembra un concetto piuttosto diverso.
saluti
Roberto