Newsgroup: it.comp.java
Titolo: Visual Basic come allenamento per Java ?

  Allora, avrei deciso di imparare un linguaggio di programmazione.
Scartato il C++ perche' e' "difficile AND vecchio", mi restano Visual
Basic (il linguaggio del "presente") e Java (quello del "futuro"). Ho
iniziato pertanto a leggere sia "Thinking in Java" sia il "Manuale del
programmatore" presente nella documentazione on-line di VB5. Avendo
notato che spesso si usano termini simili (ex. il costrutto
ME.oggetto, "ciclo di vita di un oggetto", "classe" e via discorrendo)
e' venuto da chiedermi se imparare il VB (mooolto piu' facile) possa
tornarmi utile in futuro per la programmazione in Java (programmazione
a oggetti).
 Pero' mi e' anche balenata l'idea che l'utilizzo di termini di OOP da
parte di VB non sia altro che una discutibile mossa di marketing da
parte di Microsoft per far credere che il VB sia un linguaggio
dell'ultima generazione quando invece non lo e'. Se cosi' fosse, il
mio entusiasmo per il VB scemerebbe...
  D'altro canto, ancora oggi Java non mi pare ancora molto diffuso tra
le piccole aziende che sfornano software gestionale e non (Java e'
compilabile in modo nativo, ma genera file enormi e che si
interfacciano male con applicazioni tipo Office e AutoCAD) e il suo
futuro e' incerto (al di la delle applet) .
  Tornando al subject, cosa ne pensate? Lo so che la sintassi di Java
e' simile a quella del C++, ma almeno a livello concettuale, il VB
aiuta nella comprensione della OOP?
  Grazie.

aiuta nella comprensione della OOP?
Secondo me ti conviene il contrario: impara prima il Java in maniera
da assorbire i concetti "puri" della OOP, eppoi in un paio di giorni
potrai imparare il VB e capire meglio la sua "ibridezza".
Inoltre il futuro di Java non e' affatto incerto: incarna i paradigmi
della programmazione del futuro.
--------
Jagui  - 
ja...@bigfoot.com

aiuta nella comprensione della OOP?
*BRAVISSIMO* per aver capito che la sintassi e` un problema
molto *superficiale*, rispetto alle "vere" problematiche concettuali
della programmazione; Java e` sintatticamente piu` simile al C++,
ma *semanticamente* ha se mai piu` somiglianze con VB, come
ho diffusamente sostenuto in vari e accalorati recenti thread su
it.comp.java e it.comp.lang.c++.  *SE* hai la disciplina di usare
VB nel modo "giusto" -- strutturato, ad oggetti, eccetera -- e lo
trovi piu` facile da apprendere di Java (cosa non scontata, visto
che Java ha una sua "coerenza concettuale interna" che VB,
dovendo mantenere compatibilita` con tante cose vecchie,
non puo` eguagliare appieno -- ma queste, alla fin fine, sono
questioni molto personali), allora, io dico di si`, che puo` essere
furbo partire da VB e proseguire con Java (per tante persone,
che non hanno la "forza di volonta`"/"disciplina" necessaria,
partire con Java potrebbe pero` rimanere piu` consigliabile).
A livello pratico hai gia` bene elencato i vantaggi di VB; non ti
scordare pero` quelli di Java: librerie standard piu` ricche e
complete (ci fai tante cose che in VB devi fare a colpi di
controlli Active/X incorporati, API, o comunque con grande
difficolta` in modo "nativo"), *portabilita`*, gratuita` degli
strumenti di programmazione piu` vari e anche di tanti ottimi
testi (con "Thinking in Java" parti bene, pero` ricorda che e`
un testo per chi conosca gia` qualche altro linguaggio, diciamo
"la programmazione" in termini generici...).  Come linguaggio,
Java offre alcune comodita`, come "extends" (la famosa
"eredita` di implementazione" -- decisamente sopravvalutata
da alcuni, non e` nulla di concettualmente indispensabile
rispetto ad "implements", ma comoda, e` comoda!), e, con
Java 1.2 (ora in beta, forse uscira` a fine anno o inizio
dell'anno prossimo), un bello schema di strutture dati
"generiche", che penso compensino parecche delle diverse
"comodita`" di VB.
Soppesa bene tutti i fattori, e tuffati nella piscina di tua
scelta... non credo che sbaglierai di molto, ne` con una
scelta, ne` con l'altra!
Alex

NO!
Anche se hanno punti di contatto sono mlto diversi.
EB

Basic (il linguaggio del "presente") e Java (quello del "futuro"). 
sorry,ma personalemnte penso che un programmatore prima di tutto
debba conoscere il c,io java l'ho imparato per forza(universita') e
per avvicinarmi all'oop e al mio linguaggio,il c++.
Senza tralasciare un altro ottimo linguaggio,l'asm.
Se invece vuoi imparare un linguaggio per avere sbocchi
professionali nelle medie-piccole aziende,allora impara VB.
Io,personalmente,il VB non lo sfioro neanche con una tuta da
palombaro..=)

  Grazie.

aiuta nella comprensione della OOP?
ASSOLUTAMENTE NO.
Se vuoi un consiglio, studiati almeno un po' il C++.
Nel passaggio a Java sarai molto facilitato, perche' in fondo, Java e' un
C++ piu' semplice.
--
Roal Zanazzi
z...@iol.it


Il mio primo linguaggio e' stato il basic del mitico Commodore 64.
Quando ho fatto alcuni (pochi) programmini in assembler C64 ho dovuto
ristudiarmi tutto da capo :-(
--
Roal Zanazzi
z...@iol.it


Beato te... io sono costretto a lavorarci :-(
Per disintossicarmi, ogni tanto alla sera, smanetto con Delphi e/o
C++Builder...
--
Roal Zanazzi
z...@iol.it


...purche' tu non ti tuffi TRA le due piscine: generalmente ci si
trova del cemento! :)
Ciao!
Matteo!!!

On Fri, 30 Oct 1998 22:09:06 GMT, nes...@danessuna.parte (Msbar_)
wrote:
Vado contro corrente:
Se hai intenzione di imparare un linguaggio di programmazione nel
senso di imparare a programmare come si deve ti consiglierei di
procurarti una copia di Delphi e darti da fare con il Pascal ed un
buon libro di programmazione generica.
Questo linguaggio è stato progettato proprio per insegnare a
programmare ed è adattissimo a questo scopo. Quelli della Borland,
poi, hanno aggiunto delle buone estesioni OOP. Secondo me questo è il
linguaggio ideale per imparare.
Adesso non venite a dirmi che il pascal non lo insegnano neanche più
nelle università: se è vero è solo perché hanno ceduto alle pressioni
delle ditte che volevano manodopera pronta all'uso, senza dover
perdere neanche un minuto in training interno. Così qualcuno ora
insegna a programmare in C, ma questo è un linguaggio troppo
complesso, inadatto ad un principiante.
Naturalmente questo discorso vale se intendi investire un po' di tempo
in una buona formazione senza voler ottenere ricadute pratiche
(soldi...) a breve termine. Se vuoi imparare subito qualcosa per
cercarti un posto di lavoro il discorso è diverso.
Tieni conto, comunque, che il particolare linguaggio di programmazione
è secondario: quello che è difficile è imparare a programmare. Se sei
capace non ci metti tanto a passare da un linguaggio ad un altro.
Proprio per questo secondo me il Pascal è un buon linguaggio per
iniziare: ti permette di concentrarti sulle strutture di base della
programmazione in modo semplice e pulito e rende difficile scrivere
"male" le cose.
Least but no last, secondo me l'aspetto *estetico* di un programma
Pascal è migliore di quello degli altri linguaggi che vanno per la
maggiore: voglio dire che una pagina di sorgente Pascal è più bella di
una scritta in VB o C++.
Detto questo potete mandarmi l'ambulanza che è ora di farmi
rinchiudere...
Ciao
--------------------------------------------------------------------
Fulvio Senore
Eliminate "zz" dall'indirizzo e-mail per scrivermi (spammers...)
Remove "zz" from e-mail address to write me (spammers...)
--------------------------------------------------------------------

(scusa, mi viene da ridere... mai sentito parlare di STL in C++?)
Si`, tanti anni fa -- oggi si chiama "libreria standard C++", anche
se non mancano i dinosauri che continuano ad usare il nome che,
appunto anni fa, aveva dato Alex Stepanov al suo prototipo.  Cosa
c'entri la libreria standard C++, o anche la vecchia STL, con Java
e con Visual Basic, visto che entrambi i linguaggi mancano di quel
paradigma "generic programming" ("template") su cui essa si
impernia, non e` chiaro.  ObjectSpace ha fatto del suo meglio (e
secondo me con risultati egregi) per fondere la ricchezza della
libreria standard C++ con il "semi-paradigma di quasi-ma-non-
proprio" genericita` di Java, ma il risultato, chiamato JGL e
gratuitamente scaricabile dalla rete, non e` piaciuto alla squadra
Javasoft (sindrome del "Not Invented Here"?-), e le strutture
dati di Java 1.2 si basano su tutt'altri schemi (ovviamente una
simiglianza c'e`, come c'e` ad esempio fra i Dictionaries di VB6
e gli "associative array" di Perl, visto che i concetti di fondo
degli ADT sono poi gli stessi -- ma sono presentati/approcciati
in modi assai diversi).
Non vedo cosa tutto questo tolga al fatto che, quando uscira`
Java 1.2, uno dei vantaggi pratici di Java rispetto a VB sara`
comunque la disponibilita`, come parte della libreria standard,
di un decente schema di strutture dati "generiche" (non in senso
"vero", come la genericita` del C++, ma nel senso Java); mi
pare che questo, e altri piccoli vantaggi pratici come "extends",
possano appunto, come dicevo, "compensare parecchie delle
diverse comodita` di VB" -- il fatto poi che il C++ abbia la
eredita` molteplice di implementazioni, o la sua libreria standard
con tutta la potenza dei template usati al meglio, non toglie che
Java abbia pur sempre il suo umile ma utile "extends" (senza
molteplicita`) i suoi umili ma utili "contenitori di Java 1.2".  Certo,
con implements+contenimento+delegazione si realizza in
Java l'equivalente dell'eredita` multipla del C++, e in modo
piu` flessibile, ma non altrettanto comodamente (e cosi` pure,
in VB, per l'eredita` anche non-multipla -- con la "comodita`",
secondo me fuori luogo, di potere asserire "implements"
anche di una _classe concreta_, "intendendosi" l'insieme
di tutte le sue interfacce pubbliche... tecnica VB che mi
lascia assai dubbio); e dalla rete si possono scaricare tutte
le librerie add-on necessarie per usare in VB, o in Java 1.1
senza aspettare la 1.2, tutte le strutture dati che servono
(ma, senza i template del C++, non sono proprio della stessa
potenza...).  Ma non si parla solo di quel che "si puo`" o "non
si puo`" fare in un dato linguaggio (se no, praticamente tutto
"si puo`" fare in un modo o nell'altro in qualsiasi linguaggio),
ma anche di quanto _comodo_ e _ragionevole_ sia farlo.
E quindi, riassumendo: SE (ma non e` cosa da darsi per
scontato!) una persona X trova effettivamente piu` facile
imparare a programmare in VB piuttosto che in Java, e/o
vede il trade-off delle "comodita`" fra i due linguaggi come
fortemente sbilanciato (il che non e` detto che sia...), E,
infine, non si lascia "sviare" dalle possibilita` di usare vari
paradigmi piu` vecchi in VB, bensi` resta strettamente
legato ai paradigmi ad oggetti (moduli class, implements,
ecc) -- allora, se tutte queste condizioni si verificano, puo`
in effetti essere la scelta migliore quella di imparare anzi
tutto VB, con l'idea di passare poi a Java in seguito.  Il C++,
invece, secondo me, pur essendo indiscutibilmente piu`
potente, resta troppo vasto, e troppo difficile, per essere
ottimale nel ruolo di "primo linguaggio" da imparare.
Alex

C++ piu' semplice.
E` come consigliare a chi vuol imparare a nuotare vicino alla spiaggia
di Rimini, di imparare invece in alto mare, fra gli scogli, e con una bella
tempesta in corso -- "nel passaggio a Rimini sarai molto facilitato,
perche` in fondo, Rimini e` un Mar dei Sargassi piu` semplice".  Una
piscina (Visual Basic) avra` magari un'interfaccia diversa dal mare
(Rimini o Sargassi che siano) -- ma, per chi deve imparare, il buon
senso dice che la scelta fra la piscina, e un tratto di mare calmo e
senza scogli, e` comunque ragionevole, mentre cominciare ad
imparare fra scogli e marosi e` da pazzi scatenati...:-)
Alex

  Grazie.

una scritta in VB o C++.
Su questa base, cosi` intrinsecamente soggettiva, non si arriva
secondo me da nessuna parte.  Chi puo` dire se e` "piu` bello"
"var i: integer;", "int i;", o "dim i as integer"?  Un odiatore dei ";"
preferirebbe certo quest'ultimo, un amante della concisione il
secondo, tu asserisci il primo -- e non scordiamoci naturalmente
la "integer i" del Fortran, o i linguaggi come Python in cui questo
concetto di dichiarazione non esiste neppure.
Che io sappia, l'unico linguaggio di programmazione nel quale
sono state scritte _poesie_ e` il Perl -- benche` in generale
sia difficile chiamarlo "bello", l'abbondanza di parole inglesi
usate come parole-chiave (wait, die, unless, reverse, less,
exists, ...) permette queste "finezze".
Alex

  Allora, avrei deciso di imparare un linguaggio di programmazione.



Grazie per il complimento :-)
Chiedo scusa se ho tralasciato qualcosa o se ho mal-interpretato qualche tua
frase, solo che hai scritto un libro (magari ci fosse piu' gente come te su
questi NG), e con 38 di febbre mi si fondono le pupille sul bordo del
monitor :-)
ciao
--
Roal Zanazzi
z...@iol.it

Dettagli implementativi, praticamente irrilevanti sul _linguaggio_.  :-)
Su di un _linguaggio_, si` (v. Lippmann, "Inside the C++ Object
Model", per una ragionevole trattazione del perche` le vtable
non sono necessariamente "intrinseche" al linguaggio C++,
perche` in pratica tutti le usano, e quali variazioni implementative
si possono presentare); su di un _protocollo_, no, e` il Component
Object Model e` anzitutto un *protocollo*, rispettando il quale
componenti sviluppati indipendentemente (in qualsiasi linguaggio
di programmazione che permetta` di rispettare il protocollo)
possono collaborare ed interoperare.  (Corba, nella versione 1,
ometteva questo cruciale elemento di "protocollo", ma nella
versione corrente lo ha aggiunto -- IIOP, il "protocollo di
interoperabilita`").
Alex


Solo perche' lo dici tu? Mah! Io non me la sento proprio di dire
tranquillamente "Tu puoi fare il programmatore perche' capisci che e'
piu' importante la semantica della sintassi, tu invece non dovresti
perche' ti piacciono i linguaggi in base alla loro sintassi", mi
sembra decisamente dispotico come ragionamento. Senza considerare che.
una volta capita la semantica ed una volta appreso al primo corso di
programmazione che non avrai nessun formalismo piu' potente della
macchina di Turing, penso proprio che un linguaggio valga l'altro e,
soprattuto, se mi trovo bene con la sintassi (meno ostica! Prova a
scrivere un programma in Cobol dove, oltre la sintassi, devi pure
rispettare indentazione del codice!) penso di poterlo utilizzare
tranquillamente. L'inglese non e' la lingua piu' diffusa perche' puo'
esprimere concetti piu' profondi (meglio l'italiano da questo punto di
vista) ma soltanto perche' l'inglese "tecnico" e' grammaticalmente
(leggi : sintatticamente) molto piu' semplice di un sacco di altre
lingue (ad esempio quelle di origine latina!).
Ad ogni modo credo che non dovrebbe fare il programmatore chi non ama
la programmazione e viceversa!
Ciao!
Matteo!!!


Concordo appassionatamente su tutto tranne su un punto:
all'universita' (almeno da noi...)  ti insegnano prima a programmare
in Modula3 (una sorta di Pascal con qualche differenza) e POI in C.
Non chiedermi perche' non insegnino il Pascal... lo insegnavano anni
fa ma adesso hanno cambiato idea (forse ci sono piu' compilatori
freeware per Modula3 che non per Pascal e dunque lo studente va meglio
per lavorare a casa... mah!)
Ciao!
Matteo!!!

la programmazione e viceversa!
Purtroppo, "amare" un lavoro non e` condizione _sufficiente_
per avere le caratteristiche che occorrono a svolgerlo bene;
uno puo` amare la Formula-1, ma non e` detto che questo
basti per rendergli consigliabile una carriera professionale
come corridore -- puo` amare il teatro, ma cio` non significa
che sappia recitare -- puo` amare la programmazione, ma
cio` non significa che non si troverebbe meglio, a seconda delle
sue effettive predisposizioni, inclinazioni, e capacita`, in una
qualche altra occupazione.  Si sente dire, a volte, che
"scarseggiano" i programmatori; io, personalmente, ritengo
che quelli mediocri, o pessimi, non scarseggino affatto, anzi,
e che quelli di cui non ce ne sono sicuramente abbastanza
al mondo, sono invece i programmatori _validi_.  Generalizzando
dalla mia esperienza ai numeri che si leggono in giro, immagino
che siano oggi in attivita` nel mondo circa cinque milioni di
programmatori da "decenti" su fino a "sublimi", e circa altri
cinque milioni da "scarsi" giu` fino ad "abominevoli" -- parlando
in termini di effettive potenzialita` personali, non di quello che
le circostanze permettono (perche`, purtroppo, non pochi di
questi che io considero "buoni", per i casi della vita o per
vari possibili errori, si trovano in realta` in situazioni in cui le
loro potenzialita` reali non riescono pero` ad emergere).
Alex

librerie standard, sintassi.
Prima affossi la mia considerazione della sintassi, poi quando ti fa comodo
la tiri fuori?
Dato che la discussione da parte tua si risolve con la continua insinuazione
alla mia presunta ignoranza della lingua italiana, chiedo scusa a tutti gli
interessati a questo thread, ma esco di scena (anche perche' il thread
stesso sta assumendo proporzioni a mio parere non giustificate
dall'importanza dell'argomento)
Per questo motivo evitero' di annoiare tutti (me compreso), tralasciando le
risposte al lungo contenuto del tuo messaggio (hai mai pensato di scrivere
un libro sulla OOP? non sto scherzando, credo che potresti ottenere degli
ottimi risultati).
Ti assicuro che la discussione sarebbe stata molto proficua per entrambi (e,
naturalmente, per gli altri), ma temo che le nostre posizioni siano troppo
rigide;
per cui, io rimango del mio parere (almeno per gli argomenti qui trattati) e
tu del tuo.
Mi ha fatto piacere scambiare qualche messaggio con te su un argomento che
e' interessante (ma che si e' troppo allontanato dallo scopo iniziale), e mi
sono molto dispiaciuto delle tue argomentazioni da "politico navigato",
nell'ultimo tuo messaggio (al quale sto rispondendo). Argomentazioni che
mettono in secondo piano la tua conoscenza dell'argomento, e questo e' un
vero peccato.
Un saluto a quanti hanno seguito (volenti o nolenti) questo thread.
--
Roal Zanazzi
z...@iol.it

Mi associo a Roal per un'analoga discussione avuta con Alex sul tema "Java
deriva dal c++".
Antonio Donatiello.

vero peccato.
La mia conoscenza dell'argomento E` in secondo piano rispetto
alla falsita` delle tue affermazioni sulla simiglianza sintattica: infatti,
per esse, come ho piu` volte ripetuto, non sono io ad avere ragione,
sei tu che hai avuto torto!
Se ti interessa veramente condurre discussioni tecniche interessanti,
vedi magari di evitare affermazioni sballate perche` troppo assolute, o,
se ti capita (perche` a tutti puo` capitare), sii almeno pronto ad ammettere
che quelle (piuttosto irrilevanti) affermazioni erano, appunto, sballate, in
quanto troppo estremistiche.
Noto che non hai potuto rispondere sulla *sostanza*, tipo l'allucinante
"dubbio" che sembri avere sul fatto che le interfacce astratte (e quindi
"implements") "siano polimorfismo nel senso classico dell'OO". Peccato,
perche` ieri sera ri-sfogliando "Inside the C++ Object Model" di
Lippman (grazioso testo intermedio, molto raccomandabile a chi
vuole approfondire la propria conoscenza, comprensione, "modello
mentale" del linguaggio C++ e soprattutto della sua semantica
profonda) mi e` capitata sott'occhio una sua citazione che sarebbe
sicuramente stato il caso di aggiungere a quella discussione.  Vabbe`,
ci sara` sicuramente opportunita` di tirarla fuori un'altra volta.
Alex

loro potenzialita` reali non riescono pero` ad emergere).
Mi piacerebbe che tu leggessi quello che scrivo ma, evidentemente, e'
chiedere troppo al tuo ego.
Infatti io non ho mai detto che "chi ama la programmazione dovrebbe
fare il programmatore" ho invece detto che "chi non ama la
programmazione non dovrebbe fare il programmatore" ed e' ben diverso
perche' la doppia implicazione qui non c'e'!
Quindi tutto questo bel paragrafo non e' in risposta ad una mia
affermazione (che era poi una quasi-battuta) ma e' in risposta ad una
tua asserzione. Che tristezza.
La prossima volta prenditi un po' di tempo per riflettere e poi
rispondi altrimenti ne risente la tua credibilita'.
Chiudo qui il thread perche', a mio avviso, siamo in OT.
Ad ogni modo dubito che, visto l'atteggiamento, si possa anche solo
provare a farti cambiare idea (soprattuto perche' non ascolti chi ti
sta parlando).
Ciao!
Matteo!!!


wrote:
   Grazie, Alex, per la risposta (che ho potuto leggere solo dopo
qualche giorno di lontananza dal pc), veramente da incorniciare.
   Grazie anche agli altri che hanno partecipato alla discussione.
   Ciao.

sta parlando).
Se mai, il mio problema e` che "ascolto" SIN TROPPO -- ogni
parola, ogni frase, deve, secondo me, avere un significato, nel
contesto in cui viene detta o scritta; di conseguenza, non posso
non reagire a idiozie come "un linguaggio vale l'altro", quel tuo
"viceversa", la prominenza che tu dai alla sintassi a scapito
della semantica, gli inappropriati paralleli fra linguaggi naturali
e formalismi astratti, e via elencando.
Quanto a "farmi cambiare idea" -- cioe`, nel contesto, convincermi
che la realta` sostanziale, la semantica, e` meno importante
dell'apparenza superficiale, la sintassi -- e` sicuramente molto
improbabile nel caso specifico -- quanto a *provare*, si puo`
eccome, tanto e` vero che tu, ad esempio, in questo thread, ci
hai provato eccome!  "Provare" e "riuscire" sono cose diverse:-).
Da parte mia, di far cambiare idea a *te personalmente*, *come
individuo*, mi interessa sino a un certo punto; sono contento,
pero`, che questo thread abbia illuminato tante caratteristiche
di chi ritiene piu` importante la sintassi, cioe` la superficialita`,
come te, a contrasto con i difensori dell'importanza della
semantica, cioe` della sostanzialita`, come me -- chissa`, se
anche un solo lettore fosse da questo motivato a "scavare un
po' piu` a fondo" nelle questioni, guardare SOTTO la superficie
delle cose (a partire dalla sintassi dei linguaggi!) e verso
invece la realta` sostanziale (a partire dalla semantica dei
linguaggi stessi!) -- io, personalmente, mi sentirei gia` ampiamente
ripagato di tutto il tempo, di tutta l'energia, di tutta la scocciatura
considerevole che e` stato il leggerti, e il risponderti.
Alex

definizione dispone di risorse infinite (i famosi "nastri")
In questo momento non ricordo piu' nulla della macchina di Turing  :-(
Come e' possibile paragonarla ad un computer ? Ha una architettura molto diversa
Mi risulta anche oscuro capire come possa una tale macchina eseguire delle
elaborazioni
Ciao
---------------------------------------
Email: sostituire "nospam" con "netsis"

elaborazioni
Se riesci a visualizzare come una qualsiasi macchina
a stati finiti puo` "eseguire elaborazioni" (il che, e` chiaro,
avviene quando essa transita da stato a stato, in risposta
ad "input", producendo, eventualmente, degli "output"),
non dovrebbe essere un problema vedere come la
ulteriore disponibilita` di un "nastro infinito", accanto
al "nucleo" a stati finiti, non _impedisce_ certo la
"esecuzione" in questione, anzi, ne aumenta in gran
copia le possibilita`.
Alex

 ...
Ti ringrazio per la risposta !
Mentre leggevo non volevo credere ai miei occhi. In alcuni punti sono riuscito a
capire quasi nulla  O:)
Devo dire che purtroppo sono parecchio ignorante e che la maggior parte delle
cose che hai detto non mi sono/erano note  *:-)
Una curiosita'. Che tipo di formazione hai avuto ?
Rassomigli molto ad una macchina di Turing  :-)


Rassomigli molto ad una macchina di Turing  :-)
Ahime`, o per fortuna, non ho "nastro infinito" (e, per
fortuna di sicuro, NON sono un "sistema formale"!-).
Se mai, ricordo lo scherzoso nomignolo che mi avevano
affibbiato ai primordi della Fidonet bolognese -- "Alex
Cd-Rom Martelli"... informazioni, tante, ma ben lungi
da "capacita` infinita"!-)
Alex

 [...]
LOL scusa il ritardo nella lettura, ma l'articolo era interessante..
Nella mia minima e personale esperienza, un ottimo motivo
per cui si debba conoscere Turing (o meglio, un minimo di risultati
di informatica teorica su computabilita' e complessita') l'ho trovato 
quando ho avuto a che fare con capi-progetto (armati di diploma in 
informatica e 'anni di esperienza') che non si figuravano perche' un 
povero algoritmo 'che ha sempre funzionato' ci mettesse *giorni* per
fornire risultati necessari in tempo reale..
:)
Saluti,
	Cris

fornire risultati necessari in tempo reale..
Un certo armamentario teoretico puo` certo far comodo per
autodifesa in questi casi, piu` che altro alla "Parlate Latino?"
del "Sganarello medico a suo dispetto" di Moliere -- sgranando
abbastanza paroloni, si ha una chance di fare impressione al
capo, lasciandolo con la vaga sensazione che sara` meglio
darci ragione.
A parte questo, Turing c'entra il giusto, come d'altronde tu
stesso noti fra parentesi, e raramente i "risultati teorici" hanno
effettiva applicabilita` pratica.  Ad esempio, il risultato teorico
"ti dimostra" che un sort non puo` scendere sotto O(N log N) --
ma questo e` sotto ipotesi che spesso non hanno nulla a che
vedere con i casi reali che uno si trova sotto mano: un radix
sort, tante volte, *scardina* la teoria (perche` non rispetta il
cruciale assunto teorico che l'unica operazione che puoi fare
fra due chiavi e` un confronto maggiore-minore, che ti da un
solo bit d'informazione) e ti porta a un sort O(N) per tutti i casi
pratici d'interesse.  E d'altra parte, e` altrettanto probabile che
nel caso pratico le sequenze di dati in arrivo non siano ergodiche
(chi, compresi i laureati in statistica, ha una completa, chiara
comprensione di cosa significhi "ergodico"...?-) -- il che puo`
magari scardinare un quicksort, e invece ringalluzzire un
"N-tape mergesort", checche` la teoria reciti.
Secondo me, la giusta quantita` di teoria per una pratica
applicazione dell'informatica e` "tanto quanto basta per non
fare alcuna fatica a seguire Abelson e Sussman ["Structure
and Interpretation of Computer Programs"] e il 97.5% di
Knuth ["The Art of Computer Programming", vol 1-3]": cio`
significa, in particolare, algebre astratte (gruppi, anelli,
ideali, ecc), probabilita` e statistica come se piovesse,
calcolo differenziale e integrale (sino almeno alle trasformate
di Riemann incluse), ecc, ma NON comprende di necessita`
tutto Turing, Goedel, o Church (sara` controverso, ma, a
livello puramente personale, opino che una cultura di base
matematica sufficiente per leggere senza difficolta` il
_100_ % di Knuth, sia esagerata... quel 2.5% che secondo
me si potrebbe anche non capire senza fatica, richiede, da
solo, piu` anni di studi di base del restante 97.5%, e, nella
prassi quotidiana, sono cose che potranno _forse_ saltar
fuori una volta ogni vent'anni circa...).
Se poi uno (per soddisfazione personale, o per avere una
buona scorta di paroloni) si vuole memorizzare tutto Turing,
Goedel, Church, buon pro gli faccia -- continuo pero` a
pensare che allora sarebbe meglio (se si deve scegliere)
studiare le "vere" fondazioni critiche del pensiero: Kant,
Wittgenstein, e De Finetti, per esempio...!
Alex

La macchina di Turing ha un buco di sistema
La macchina di Turing ha un buco di sistema
La macchina di Turing ha un buco di sistema
Tappiamolo col chewing gum!

 Wittgenstein, e De Finetti, per esempio...!
Mh, qui mi trovi meno concorde. Certamente, il buon Kant *e'*
un pilastro nella nostra cultura (ahime', Wittgenstein un po'
meno mi pare), ma bho, dovendo scegliere, vedo piu' 
interessante - e pratico - studiarsi i fondamenti della
matematica e i loro effetti sulla visione del mondo...
ma oibo', sto entrando in modalita' filosofeggiante,
e quindi mi fermo qui. :)
Saluti,
	Cris

e quindi mi fermo qui. :)
Penso che, magari passando su it.cultura, non ci sia
nulla di male a "filosofeggiare".  Tutto sommato, e per
analogia (Wittgenstein, ancora...:-), ci sono risvolti
molto diretti fra questi temi, e il titolo originale di questo
thread.  Visual Basic e` linguaggio eminentemente
pragmatico, magari perfino raffazzonato, ma molto
orientato al risultato concreto -- certo, non dara` le
migliori basi "teoriche", ma, nella praticaccia, siamo
proprio certi che siano cosi` indispensabile...?  Sarebbe
_bello_ averle -- ma, se ogni giorno ha solo 24 ore, e`
piu` fruttuoso per la mia crescita come individuo che
io le destini a questo, o alla filosofia, o, ancora, alle
tecniche di sopravvivenza in foresta, o...?-)
Alex