Newsgroup: it.scienza.informatica
Titolo: Imparare a programmare.

Salve,
sono un ragazzo di Roma che ha un piccolo desiderio: vuole imparare a
programmare, ma imparare sul serio, imparare veramente. Però non so da dove
cominciare, molti mi dicono che è bene saper il Basic innanzitutto, perché
ci detta la logica di programmazione, e da qui partire. Indispensabili sono
anche la conoscenza dei principali sistemi operativi (Win 95/98/2000/NT, DOS
Unix, Linux, OS/2, ecc. ecc.), ma è vero? Da dove comincio, e quali sono i
linguaggi più in voga al momento, i più utili e funzionali, nonché i
migliori da un punto di vista occupazionale?
Davide

Ciao,
Davide ha scritto:

bè, tanto per cominciare, io non mi sbatterei la testa per 3.000 sistemi
operativi diversi ma mi concentrerei sullo sviluppo di applicazioni per un
sistema operativo. Per come stanno adesso le cose, ti conviene rimanere
nell'ambito Windows.
Il DOS lascialo stare....insomma si tratta di programmare con prodotti
diversi che sotto Windows sono a 32 bit e spesso RAD, mentre sotto DOS mi
pare che il RAD te lo puoi pure scordare e pure i 32 bit ecc....
Allora Windows 95, 98 sono molto simili e quindi sviluppare per uno di
questi vale per entrambi. Anche con NT la musica non cambia....in fin dei
conti vedi molti cambiamenti se fai programmi che fanno stretto uso di
alcune funzionalità del sistema operativo stesso e nel caso di NT c'è tutto
il discorso inerente ai privilegi ecc.... che sotto 95 e 98 non c'è traccia.
Linux è in forte crescita però mi pare troppo complicato per iniziare a
programmare e poi non è ancora usatissimo.
Insomma se un tizio ti chiede un programma molto probabilmente userà Windows
e non Linux. Se usa Linux pazienza.....tu programmi in Windows. Os2 proprio
non lo conosco.....cioè lo conosco di nome ma non l'ho mai usato e non so
che dirti.
Windows 2000 mi pare proprio che sia NT semplificato, ma pur sempre NT.
Per quanto riguarda i linguaggi di programmazione credo che dovresti
sceglierne uno di cui conosci già il linguaggio che ci sta dietro, la
sintassi ecc...
Insomma se conosci il buon vecchio basic del DOS, puoi scegliere Visual
Basic, se conosci a fondo il C++ puoi scegliere Visual C++ ( anche se poi
non è RAD ) oppure C++ Builder della Borland che è simile a Delphi ed è
visuale.
Se conosci il Pascal puoi utilizzare Delphi. Se non conosci nessun
linguaggio, ti conviene sempre buttarti sul RAD.
RAD è una sigla inglese di tre parole che in pratica stanno a significare
che il linguaggio di programmazione supporta lo sviluppo rapido ( visuale )
delle applicazioni.
Comunque in giro c'è richiesta anche di programmatori Visual Basic, ma
personalmente ti consiglio di buttarti su qualcosa di più interessante come
Delphi che tra poco sarà disponibile anche per Linux.
Io uso Delphi da circa 3 anni. Mi ci trovo benissimo e non ho mai avuto
problemi di limiti nel linguaggio ecc....cosa che invece ho riscontrato in
Visual Basic che personalmente odio. Anche per i database Delphi è
spettacolare. Inoltre il linguaggio Pascal ha moltissime potenzialità e per
certi versi è molto vicino al C. Insomma puoi farti componenti aggiuntivi,
scaricarne altri da internet ecc.....cosa che Visual Basic include per modo
di dire. Visual Basic si basa sui controlli OCX che sono rognosi da portarsi
dietro. C'è pure il fatto che l'eseguibile di Delphi è indipendente e non
necessita di librerie, inoltre si riescono a fare applicazioni poco pesanti
e facilmente trasportabili pure su floppy.
L'ultima versione di Delphi è la 5, ma già la vecchia 2 è a 32 bit e il
pacchetto standard la trovi pure gratuitamente.
La versione 1 è a 16 bit e puoi utilizzarla se devi fare qualche programma
che funzioni sotto Windows 3.1 o 3.11.
Delphi è disponibile in 3 pacchetti: standard, professional ed entherprise o
client/server.
Vabbè, vedi tu cosa fare. Se vuoi scrivimi pure in privato per ulteriori
notiziole.
Ciaooo !!!!
Antonio Tarolla

Al momento la  piattaforma più  diffusa  è windows, ma  linux prometto
molto  bene. Solo    nell'ultimo  anno ha  subito  un'impennata  nella
diffusione  e  sempre  più   grosse aziende se  ne  interessano   e ci
investono, IBM in primis.
Se   non vuoi precluderti  delle     possibilità, devi puntare su   un
linguaggio  che vada bene per  entrambe le piattaforme, il che elimina
praticamente di colpo le possibilità di scelta: impara java. 
Ci sono ottimi ambienti di sviluppo (RAD e non) ed anche strumenti per
la progettazione, gratuiti e scritti in java, che quindi girano sia su
windows   che su linux. In  questo  modo puoi  rimandare la scelta del
sistema operativo a quando sarà più chiara la situazione (anche se io,
filosoficamente e 'partigianamente' propendo per linux :-))
Un ulteriore   possibilità è stare a  vedere  che combina  Borland: le
nuove versione dei loro   strumenti  di sviluppo dovrebbero   uscire a
breve, sia per linux che per windows, quindi avresti la possibilità di
usare Delphi (o un qualcosa di simile) su entrambe le piattaforme.
Se vuoi cominciare subito, punta dritto su java: tutto il software che
ti può servire ed anche diversa documentazione  è gratis. Ricordati di
installare *ALMENO* 128MB di ram sul tuo pc, però.
Ciao
Marco
-- 
Principio della Perversita' della Programmazione: C'e' sempre un altro
bug.

praticamente di colpo le possibilità di scelta: impara java. 
Ci sono anche altri linguaggi, dal classico C, al C++, a lisp e
prolog.
E volendo se ne trovano altri....
Paolo

 bug.
Teorema dei programmi per totocalcio: Per soddisfare le continue richieste
del cliente il codice arrivera' a una dimensione tale per cui a ogni bug
corretto se ne introducono 1.1.
Marco

migliori da un punto di vista occupazionale?
Bhe io ti consiglierei di conoscere innanzitutto le basi del vecchio
MS-DOS (nella pratica probabilmente non ti servira' a nulla... ma odio
visceralmente chi smanetta con win e non sa che e' l'autoexec...) poi
certamente devi saper utilizzare a un livello decente Win 9x e Linux
(preferibilmente)...a livello decente non significa sapere di tutto
sul so in questione (il che puo' servirti...ma solo in casi
specifici)... ma piu' che altro sapere dove mettere le mani per poter
usare i soft di sviluppo su queste piattaforme.
Per quanto riguarda il linguaggio la scelta sarebbe sterminata... ma
io ti consiglierei di imparare due linguaggi di "categoria", e cioe'
almeno un linguaggio di programmazione strutturato e uno a oggetti
(divisione spesso labile...ma se,pre secondo me valida a grandi
linee).
Un buon iter secondo me sarebbe quello di pňartire imparando il C
(oppure anche il Pascal, ma certamente il C pur essendo un po' +
difficile e' + potente e usato a scopi anche non-didattici) imparato
il C (o il Pascal) dovresti aver acquisito le basi della
programmazione strutturata...almeno grosso modo..a questo punto
potresti passare al C++ (e partendo dalla conoscenza del C ti sarebbe
relativamente semplice) oppure a Java.
Personalmente ti sconsiglierei di buttarti direttamente su Java e/o
C++ senza aver imparato Pascal e/o C..sarebbe (a mio parere) come
cercare di costruire una casa senza le fondamenta.
Per quanto riguarda l'ambiente di sviluppo ti sconsiglio di cominciare
con i vari Visual-qualchecavolodiqualchecosa ma di iniziare con un
compilatore spartano tipo il gcc o il turboC per il C (o anche DJGPP)
oppure TurboPascal (per il Pascal) e poi eventualmente compilatori
adatti per Java e/o C++.
Se imparterai questo, poi non dovresti trovare grossi problemi a
districarti in ambienti come Visual C++ o anche Borland Builder e
simili... anzi ti dpovresti trovare le cose facilitate.
Per quanto riguarda la diatriba sul Visual Basic... bhe non me ne
vogliano gli affezionati a questo ambiente.. am secondo me e' troppo
legato alla piattaforma specifica... e complessivamente una c****a
pazzesca (ma questo e' solo il mio punto di vista...poi valuta te)..se
non altro per il prezzo del pacchetto.... che non e' proprio basso....
Augusto Pucci
Webmaster di Prospektiva On-line
http://www.prospektiva.it

linguaggio, ti conviene sempre buttarti sul RAD.
No, ti conviene imparare la programmazione.
ciao
Christian
-- 
| Christian Surchi           | 
www.firenze.linux.it/~csurchi
    |        
| FLUG: 
www.firenze.linux.it
 | Debian GNU/Linux: 
www.debian.org
 | 
+---------------------------------------------------------------+
People tend to make rules for others and exceptions for themselves.

Secondo me l'iter ottimale per imparare a programmare è:
Programmare sotto DOS con il C, solo per imparare le piccole cose
come i cicli, if then else insomma... farsi un pò le ossa.
se poprio si ha fretta passare direttamente al Java!
Inoltre è importante avere un amico ache ti dia quelle piccole dritte
per andare avanti.
Consiglio all'inizio di lavorare sotto dos perchè è più semplice e non
si ha a che fare con interfacce, trappole, eventi ecc...
ma il programma è del tipo  ... print("CIAO MONDO!!!");
in questo modo si ha la possibilità di iniziare a programmare
concentrandosi sulle basi.
Una volta diventati più sicuri... si può passare ad un altro
linguaggio.... consiglio il java: sta avendo un grande successo,
è indipendente dalla piattaforma (win o linux) è ottimo per la rete...
e si trova tutto quelllo che ti serve ....
Se ti serve quialcosa .... puoi scrivermi :    
mario . lat @@ libero . it    (cancella @ e gli spazi... per lo spam!)

[...]
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

 installare *ALMENO* 128MB di ram sul tuo pc, però.
Meglio il pascal: didattico e fortemente tipizzato, con i puntatori
(odiati da tutti coloro che sono alle prime armi) fatti benissimo. Ti
basta un 286 con 1 MB di ram... ;-)
--
 Ciao, Bianco.
 Reply to 
luca....@tiscalinet.it


Java e' un linguaggio compilato. Il compilatore genera un codice
portabile (non direttamente eseguibile) che puo':
a) essere eseguito tale e quale da una virtual Machine
b) essere compilato totalmente per la macchina ospite da un
"just in time compiler"
c) essere compilato effettivamente all'origine come nel caso di J++
nel caso a) le prestazioni sono gia' piu' che sufficienti per
la stragrande maggioranza della applicazioni, quelle cioe'
che non consumano grandi quantita' di CPU
nel caso b) le prestazioni sono molto buone e, tranne casi
disperati, prossime a quelle del C++
nel caso c) le prestazioni sono talmente vicine a quelle del C++
che, se fosse necessario aumentarle ancora, la soluzione non
sarebbe il C++, ma l'assembler.
Alcuni vantaggi di Java su C++ sono tali da meritare una menzione:
1) Il codice e' protetto. Gli sfondamenti delle array,  i references
a null, sono segnalati quando avvengono, i "references" a vuoto
non possono essere per via del controllo dei references. Quindi
tutti gli errori di programmazione  responsabili della quasi totalita'
delle instabilita' "cattive" dei programmi sono segnalati quando
avvengono e non quando ne subiamo le nefaste conseguenze.
Cio' migliora notevolissimamente la stabilita' del software
prodotto riducendone proporzionalmente lo sforzo di debugging.
2) La garbage collection ci solleva dall'altro grande problema
di stabilita', i "memory leaks". Sulla garbage collection c'e'
comunque molta strada ancora da fare. Vedere gli svantaggi.
3) La portabilita' e' vera e, a meno di J++ ahime!, totale.
4) E' stato finalmente eliminato il Preprocessor. Non tanto
perche' dannoso in se', quanto per il malaugurato indiscriminato
uso che il programmatore medio C e C++ ne fa. In altre parole
in Java non c'e' piu' la tentazione. Peccato da un lato, ma
era ora!!
5) Il confinare una classe in un modulo e viceversa puo' sembrare
restrittivo, ma alla fine costringe a un maggior ordine.
6) Finalmente un buon linguaggio, veramente applicativo e non
un ibrido tra applicazione e software di base come appunto
il C++
7) Una libreria piuttosto potente e abbastanza completa e,
almeno fino a poco tempo fa, in buona crescita.
8) Interfacce (aiutano molto anche se manca la dervazione
multipla vera e propria)
9) Obbligo di dichiarazione delle exception. Evita brutte
sorprese.
Alcuni svantaggi:
1) Distruttori praticamente inutili perche' eseguiti troppo
tardi (al momento della garb. coll. invece che alla perdita
dei reference)
2) Mancanza della derivazione multipla. Le interfacce
la compensano solo parzialmente.
3) Prestazioni un po' (ma non cosi' tanto, vedi sopra)
inferiori.
4) Garbage collection eseguita quando vuole il sistema
e magari in un momento in cui si ha fretta. Il fatto di
poterla eseguire su comando costringe gli applicativi
a una "gestione di sistema" in netto contrasto con la
"vocazione applicativa" del linguaggio.
5) Soppressione delle "union". Ma erano talmente
poco usate e, spesso, a sproposito che il danno
e' minimo. D'altro canto la loro conservazione
avrebbe reso inutili gli sforzi di "stabilita'".
Tutto quanto sopra per incoraggiare a usare un
linguaggio che si presenta molto bene e ha l'aria
di avere un futuro promettente (speriamo di non portare
sfortuna!!!). Con esso si faranno sempre piu' applicazioni
(client, server, stand alone, etc...). La sua "limitazione
ai giochini" riguarda solo le "applet" in quanto queste
devono essere trasmesse via internet e quindi non
possono essere troppo grosse.
Chi scrive, vecchio programmatore C passato a C++,
ha assaporato Java ed e' poi stato costretto dalle
circostanze avverse della vita a ripiombare nelle
tenebre del C++
Saluti
Mino Saccone


 writes:
PM> 
PM> Ci sono anche altri linguaggi, dal classico C, al C++, a lisp e
PM> prolog.
certamente, solo  che  se vogliamo   riferirci  ad una  piattaforma di
sviluppo   ragionevolmente 'universale',  che  consenta  di sviluppare
applicazioni di vario tipo, non vedo molta scelta. 
Non sono affatto un patito di questo o quell'altro linguaggio, anzi.
C/C++ sono  sě  standard, ma  appena hai  bisogno di programmare della
grafica o di interfacciarti ad un DB devi uscire dallo standard. ML mi
piace  molto per la sua  eleganza, ma  non mi risulta   che ci sia una
piattaforma ben supportata ovunque. :-(
PM> E volendo se ne trovano altri....
volevo solo  dare  un consiglio utilitaristico,  senza nessuna pretesa
didattica.
Ciao
marco
-- 
Quando si insegna ad un bambino...  lui viene programmato con semplici
istruzioni -- e ad un certo punto, se la sua mente si sviluppa
correttamente, eccede la somma di cio' che ha appreso, e pensa
indipendentemente.
		-- Dott. Richard Daystrom, "The Ultimate Computer",
		   data astrale 4731.3

 writes:
AT> 
AT> Linux  è in  forte crescita  però  mi  pare troppo complicato  per
AT> iniziare a programmare e poi non è ancora usatissimo.
al contrario,  io credo che proprio  una certa spartanità possa essere
utile. Il grosso rischio di un bell'ambiente ide/rad (quale che sia il
linguaggio o  il sistema  operativo) è  di distrarti dalla  basi della
programmazione.
Certi  concetti sono essenziali, per   dei programmini che  utilizzano
solo   la  console per   l'io,  mi  sembrano molto  istruttivi  per un
principianti.
In questo tipo  di utilizzo, su  linux hai un supporto notevole (tool,
linguaggi, documentazione,    editor), su windows   c'è  rimasto poco,
credo.
Ciao
marco
-- 
"Il testing non puo' mai rivelare l'assenza di bug."
		-- Dijkstra

basta un 286 con 1 MB di ram... ;-)
A trovarlo il 286...  ;)
Dovrei avere un 8086 da qualche parte, sicuramente ho una
mainboard con amd386 40Mhz (se non ricordo male).
Paolo

tenebre del C++
Io rientro nei pochi che sono passati al C++ senza
vedere un filo di C, prima utilizzavo il turbo pascal e
sporadicamente lisp ed altri linguaggi minori.
Cio` mi ha indubbiamente favorito
perche non ho acquisito gli idiomi C, mentre ho
subito iniziato a praticare un approccio OO.
A distanza di anni, sono soddisfatto dei risultati avuti, ma
in effetti noto che la mia produttivita` in C++ e`
inferirore a quella che ottengo con altri linguaggi.
Cio` e` sicuramente dovuto ai numerosi dettagli che
devi considerare lavorando in C++, un prezzo necessario
quando vuoi rosicchiare cicli macchina, ma spessissimo
dovuto all'uso delle sole librerie di base, senza cercare di
trovarne altre ad hoc.
I problemi di memory leak di cui spesso ci si lamenta
per me non sono mai stati veramente tali, tra incapsulamento
ed eccezioni riesco a controllare bene il fenomeno, ora poi
con la libreria standard il problema e` ancora minore.
Ritengo comunque che non ci sia un linguaggio universale,
tipicamente quando hai bisogno di prestazioni solo poche parti del
codice richiedono un C++. L'approccio migliore e` quello di
utilizzare due linguaggi, uno ad alte prestazioni per quel 10-20%
di codice critico, uno piu` astratto e produttivo per il restante
80-90%.
Credo che il connubio Java-C++ sia una buona scelta (tanto
che ho in programma proprio un intensivo studio di java), entrambi
i linguaggi sono portabili e Java mi risulta sia in grado di
collegarsi direttamente al codice C++.
Paolo


Vero! se non si usano altre librerie, sopratutto middleware,
che spesso impongono regole astruse e cervellotiche per la
gestione della memoria. D'accordo, non e' colpa del C++
in senso stretto, ma le stesse librerie, in versione Java,
sono un vero sogno!!! E, sopratutto a causa loro, sono
diventato un estimatore di Java.
Saluti
Mino Saccone

nell'ambito Windows.
interessante il fatto che all'universita' insegnano C sotto Unix
mentre le aziende richiedono in grande numero Visual Basic sotto
windows  :)
-------------------
Aranar

 writes:
B> 
B> IMHO, java va bene per fare i giochini e le applet: 
ma  no, questo era vero  all'inizio. Quando parlo  di java penso ad un
intera piattafiorma di sviluppo, con tutte i package del jdk standard.
C'è veramente tutto   e di più: penso,   ad  esempio, ad  applicazioni
multithread  e  distribuite. A differenza  di  altri linguaggi in cui,
devi cercarti, magari pagando, le librerie aggiuntive.
Mino  saccone ha già  fatto una bella  analisi, io ci  aggiungo che mi
piacerebbero i template anche in java: dopo aver apprezzato la potenza
di STL è difficile farne a meno.
B> interpretato (ma  va'?) per garantire  la massima  portabilita', ma
B> questa caratteristica, importantissima  per certi versi, ne abbatte
B> le prestazioni, il che rende il  linguaggio inadatto per tantissime
B> applicazioni di un certo interesse.
ad esempio?
a che tipo di applicazioni ti riferisci?
B> Meglio il pascal: didattico e fortemente tipizzato, con i puntatori
B> (odiati   da tutti   coloro    che  sono  alle prime    armi) fatti
B> benissimo. Ti basta un 286 con 1 MB di ram... ;-)
ci    aggiungo che  proprio  oggi è   uscito la    versione finale del
freepasccal,      compatibile col  TP e,      in   parte, con   alcune
caratteristiche di delphi: 
www.freepascal.org
Ciao
Marco
-- 
Una predizione vale venti spiegazioni.
		-- K. Brecher

 No, ti conviene imparare la programmazione.
si, ma dicci come imparare sta programmazione benedetta !!
Gli fai fare un corso accelerato ? Gli consigli un compilatore ? Quale ?
Va bè, può iniziare pure con il basic o il pascal sotto DOS, ma in fin dei
conti le stesse cose le può imparare ugualmente
anche con il RAD che tanti odiano perchè troppo semplice.
Ma quale semplice. In fin dei conti mi pare che nei miei programmi il codice
lo scrivo sempre e pure molto, anche se poi faccio prima per quanto riguarda
i componenti che ovviamente sono già belli e pronti.
Però i componenti hanno pur sempre proprietà e metodi propri, e quindi il
codice lo devi scrivere ugualmente e se non lo sai scrivere, fai solo un bel
package che puoi solo ammirare visivamente ma senza vederlo funzionare !! O
no ?
Ti saluto.....ciao !!
Antonio Tarolla

 che non consumano grandi quantita' di CPU
i giochini appunto :-) Cosa intendi per "stragrande maggioranza della
applicazioni"? Magari l'orologio all'angolo del desktop...
Sui vantaggi e svantaggi di java, non discuto, sono fondamentalmente
d'accordo.


va a cercare le librerie piu' disparate.
Non era questo che intendevo...
Semplicemente con Java i bug si spostano sulla JVM,
pero` e` anche vero che solitamente si usa un
piccolo sottoinsieme di tutta la libreia Java o sbaglio!
Per il resto concordo con te.
Paolo

no ?
Io credo che sia molto piu' utile imparare a programmare scrivendo
davvero tutto il codice, a partire da "Hello World", piuttosto che
limitarsi a scrivere solo parte del codice.
ciao
Christian
-- 
| Christian Surchi           | 
www.firenze.linux.it/~csurchi
    |        
| FLUG: 
www.firenze.linux.it
 | Debian GNU/Linux: 
www.debian.org
 | 
+---------------------------------------------------------------+
Under every stone lurks a politician.             -- Aristophanes

principiante.
Il problema di fare l'interfaccia grafica e di gestire dati il cui
formato non ci è noto nei più piccoli dettagli in sistemi operativi
ostili sposta l'attenzione dalle proprietà del linguaggio e
dall'algoritmo che stiamo usando.
Borland offre i migliori strumenti per creare rapidamente quello che
spesso viene commissionato a programmatori generici, chiaro che
scrivere un sistema operativo usando Delphi nell'ambiente Borland mi
sembra un tantino azzardato, mentre mettere un programmino carino in
rete con Java è più facile che fare un sito per accedere ad una base
di dati con MS Visual Basic piuttosto che con PHP4+postgreSQL.
Bisogna vedere cosa interessa.
Nel caso dei linguaggi l'implementazione di un medesimo algoritmo in
linguaggi differenti può essere incredibilmente istruttiva, tuttavia
per motivi pratici nei corsi del primo anno si usa un interfaccia
deprimente come quella del terminale :-)
Mi sono (auto)convinto che imparare un linguaggio procedurale, usarlo
per un po', convincersi che tutto sarà simile a quello e poi scoprire
che esistono i linguaggi funzionali è terribile, paragonabile solo a
quello di passare da cpu CISC a RISC scoprendo solo do un po' che non
esiste un'istruzione push/pop per lo stack.
Vorrei una campagna televisiva per sensibilizzare l'opinione pubblica
su questo tema.
A parte le checkbox(es), i radio button(s), i pop-up menu(s), quello
che veramente interessa da un punto di vista scientifico - è stato
citato il type-check(ing) - è limitare i run-time errors, cioè in
assoluto sarebbe meglio prevedere quelle situazioni in cui vengono
fuori valori sballati o improvvisi "piantamenti" o quel laconico
messaggio che ho visto sotto Linux (segmentation fault), che fanno
perdere molto tempo alla ricerca dell'errore.
L'ideale sarebbe sapere in fase di compilazione sapere che si potrebbe
verificare un errore del genere, impedire o essere avvisati e prendere
le dovute contromisure tra le quali è stato citato il
garbage-collector (che io sappia esiste per Lisp, Java e qualche pazzo
scatenato lo sta creando come libreria per il C o il C++ ???).
In breve per scopi commerciali ultra-general-purpose il mio voto va' a
Borland Builder (Delphi-C++-Java) che fa' di tutto di più nella
versione enterprise, ti fa anche da autista se il sabato hai bevuto
troppo e all'occorrenza ti risolve le situazioni difficili con le
donne :-)
Una volta capito come si ottiene un sottoprodotto commerciale in un
tempo così rapido, diciamo una volta maturato, passerai/userai  a/
Linux o FreeBSD o quel che ti pare purché regni l'uso del codice
sorgente, per vedere che tutto è possibile o impossibile a seconda di
come lo guardi.

di STL è difficile farne a meno.
A onor di cronaca e visto dove siamo, ricordo
che Bertrand Mayer (o Meyer?) in
OOP vs Genericity (o forse al contrario?)
ha dimostrato che la programmazione generica
e` un sottoinsieme della OOP in un linguaggio con covarianza.
Da altri altri articoli (C. Pescio in Programmazione ad oggetti e
programmazione generica) viene fuori anche il perche` nei linguaggi
OO con controvarianza (come il C++) i template siano utili.
C. Pescio in altri articoli ha anche smontato molte delle tesi
di Stephanov, in particolare in una intervista in cui
Stephanov ha dimostrato di aver compreso poco il
paradigma OO rifacendosi ad un unico modello contro
i tanti possibili.
Per l'articolo di Pescio che ho citato, mi pare sia disponibile su
www.eptacom.net
Paolo

limitarsi a scrivere solo parte del codice.
Sicuramente.
Paolo

 d'accordo.
Anche la leggenda che le prestazioni di java siano inferiori a quelle del
C++
va sfatata, perche' questo e' vero solo se si parla di java eseguito da
virtual machines
che interpretano. Le applicazioni scritte in java che girano su Jbed sono
veloci
quanto le medesime applicazioni scritte in C++. Non e' vero che Java
richieda forzatamente
128Mb di Ram perche Jbed puo' lavorare anche con 512Kb anche se il
linking dinamico richiede
almeno 1Mb di ram.
bye bye
Gabriele

 writes:
PM> 
PM> che  Bertrand Mayer (o Meyer?)  in OOP vs  Genericity  (o forse al
PM> contrario?)   ha dimostrato che  la programmazione  generica e` un
PM> sottoinsieme della OOP in un linguaggio con covarianza.
non lo metto in dubbio :-)
quando mi sono imbattuto nell'STL (più di  4 anni fa) ho trovato molto
elegante  l'impostazione, in particolar  modo l'ortogonalizzazione tra
lo spazio degli algoritmi  e quello delle  strutture dati. Oltre tutto
le prestazioni non  ne  risentivano,  perchè  il type-checking era   a
compile-time, a differenza di java, ad esempio.
Le mie conoscenze  di altri linguaggi  sono parecchio limitate (per lo
più c/c++ e  java), quindi non  ho  molti metri di paragone,  ma trovo
così scocciante dover sbattere  qua e là cast  espliciti per usare  un
semplice container di String ;-)
Ciao
Marco
-- 
"La bruttezza ha un vantaggio sulla bellezza: dura."
		-- Daniel Mussy

 writes:
PM> 
PM> Qualunque cosa se ne dica, con tutti i suoi difetti, windows gode di
PM> due vantaggi su linux:
mi sa che mi sto infilando in una flame war, quindi
<CALMA MODE>
PM> a) E` molto piu` semplice da gestire
unix è stato sviluppato da programmatori, per programmatori
windows è indirizzato a utenti *mediamente* "non esperti" 
PM> b) Generalmente su win c'e` una scelta molto piu` ampia.
a che ti riferisci, in particolare?
a che ti serve un ventaglio di scelte, quando hai (X)EMACS? :-)
</CALMA MODE>
battute a parte,  ho cominciate ad usare  emacs per prova, solo perchè
ne avevo sentito parlare molto, ma più lo utilizzo  e conosco e più mi
rendo conto che  è splendido. Non sarà  molto intuitivo all'inizio, ma
passati i primi  giorni cominci ad essere incredibilemente produttivo,
a patto di avere  una bella tastiera, non  di quelle nuove gommate che
non capisci se hai schiacciato un tasto ;-)
Ciao
Marco
-- 
"ATTENZIONE: Questo costume non permette di volare."
		-- Targhetta di avvertimento del costume di Batman

Non lo conosco, ma per sentito dire mi pare sia molto permissivo...
E' molto pulito, molto bello, e si puo' scrivere qualunque applicazione
in poco tempo, vista anche l'enorme disponibilita' di moduli per gestire
ogni cosa. Poi con calma si possono sviluppare alcune parti o tutte le
parti in linguaggi piu' performanti e compilati. E' anche molto
istruttivo, io lo consiglierei a chi impara a programmare, anzi ci sono
corsi introduttivi alla programmazione che ne fanno uso.
ciao
Christian
-- 
| Christian Surchi           | 
www.firenze.linux.it/~csurchi
    |        
| FLUG: 
www.firenze.linux.it
 | Debian GNU/Linux: 
www.debian.org
 | 
+---------------------------------------------------------------+
Computers are useless.  They can only give you answers. -- Pablo Picasso

non capisci se hai schiacciato un tasto ;-)
Concordo, pero' il punto non e' solo emacs, che poi sia integrato alla
perfezione con tutti gli strumenti, non ci piove. 
ciao
Christian
-- 
| Christian Surchi           | 
www.firenze.linux.it/~csurchi
    |        
| FLUG: 
www.firenze.linux.it
 | Debian GNU/Linux: 
www.debian.org
 | 
+---------------------------------------------------------------+
Never trust an operating system you don't have sources for. ;-)

 a che tipo di applicazioni ti riferisci?
Mi riferisco a quelle applicazioni "pesanti": fammi vedere un sosia di
autocad fatto in java, da eseguire con la JVM, che non abbia bisogno
di un Cray per girare in modo decente, e "mi mangio il cappello".


 quanto le medesime applicazioni scritte in C++.
[...]
Il punto e' questo: si usa Java per avere portabilita',la quale e'
assicurata dal bytecode _interpretato_ da una JVM, il che abbatte le
prestazioni. Se uso Java per creare un eseguibile a se' stante, non
c'e' praticamente differenza di prestazioni con il C++, ma a questo
punto si perde il vantaggio che ha reso famoso java, la portabilita',
appunto.


passati i primi  giorni cominci ad essere incredibilemente produttivo,
A me non va di spendere giorni a imparare emacs, quando
un editor meno potente mi offre cio` che mi serve e mi basta!
Cosi` la pensa anche l'utente medio!
Poi che emacs sia superlativo (a parte l'immediatezza)
posso anche convenire....
Paolo

E' molto pulito, molto bello, 
Allora forse mi confondo con qualche altro linguaggio...
Per inciso Python se non ricordo male c'e` anche per win ;)

quanto le medesime applicazioni scritte in C++.
Non ne sono convinto, ma sapro` dire di piu` tra qualche settimana...
mi sono proposto di studiare java.
Paolo

semplice container di String ;-)
Tieni presente che in C++ molte limitazioni nascono dal fatto che
non e` un linguaggio OO puro; in particolare i tipi
primitivi non sono classi e tanto meno hanno una superclasse
OBJECT (o come la vuoi chiamare) che sia radice di tutti i
tipi possibili.
In un linguaggio OO puro in cui esista una classe base
da cui ogni tipo e` derivato (rirettamente o indirettamente)
ti basterebbe creare una struttura dati che contenga riferimenti alla
classe base e sarebbe quindi utilizzabile per qualsiasi tipo senza
bisogno di cast.
In C++ puoi crearti una classe OBJECT da cui derivare le tue, ma
chiaramente i tipi primitivi non riusciresti a farceli entrare.
L'altro problema che il C++ non risolve e` quello dei binary method
citato da Pescio (l'articolo ve l'ho segnalato prima),
la controvarianza e` comodissima per verificare a compile time il 
principio di sostituibilita`, ma se si tenta di ridefinire un binary
method in una sottoclasse avere problemi e` facile.
La covarianza risolve il citato problema, ma richiede costosi 
algoritmi di analisi per verificare a compile time il principio
di sostituibilita` oppure controlli a run time (inaccettabili in un
linguaggio con type checking statico).
Il polimorfismo parametrico (quello dei template, in contrapposizione
al polimorfismo inclusivo della OOP), salva (quasi) capre e cavoli, ma
apre almeno in C++ altri problemi: tipicamente quello dei vincoli
impliciti. Ogni template in C++ impone implicitamente dei vincoli
sui suoi parametri (tipicamente metodi che devono fornire) e questi
unitamente ad alcuni meccanismi interni del compilatore
sono facilmente fonte di insidiosi errori.
Se vi interessa approfondire gli articoli di Pescio dedicati
alla OOP ed ai template sono una ricca fonte di sapienza!
Paolo

 appunto.
Se leggi meglio quello che ho scritto ieri vedrai che la soluzione di cui
parlavo io
non compromette in nessun modo la portabilita' del codice, perche' le classi
sono tutte sempre in bytecode e solo quando il loader le carica in memoria
vengono compilate dal tbcc (TargetByteCodeCompiler) e trasformate in
codice nativo del singolo processore. La classe sul disco, o sul server, o in
rom
e' sempre ancora in bytecode. In memoria la classe e' invece sempre e solo
in codice nativo del processore sul quale deve essere eseguita.
bye bye

 di un Cray per girare in modo decente, e "mi mangio il cappello".
Che java su una VM che interpreta sia lento nessuno lo mette in dubbio,
anche perche' la lentezza in questo caso e' provocata dall'interprete e non
da java. Un interprete di C sarebbe lento allo stesso modo.
Il fatto che nessuno abbia mai scritto un sosia di autocad in java non
significa che la cosa non sarebbe fattibile, certo non potrebbe girare
su una VM che interpreta il bytecode.
Solo per farti un esempio il compilatore di java (javac) del JDK della
Sun e' scritto in java ma non e' particolarmente lento, semplicemente
perche' e' compilato. La sun lo compila per le diverse piattaforme e ne
distribuisce uno diverso per ogni piattaforma ma se fosse compilato dal
loader le prestazioni sarebbero le stesse.
bye bye
--
 esmertec ag                       email: 
gbia...@esmertec.com
 Gabriele Bianchi                  phone: +41 1 445 37 30
 Software Engineer                 fax:   +41 1 445 37 34
 Technoparkstr 1                   
http://www.esmertec.com/
 CH-8005 Zürich

appunto.
Detto cosi' e, per lo meno, incompleto e in ogni caso un po' fuorviante.
La portabilita' di un linguaggio non deriva semplicemente dal suo essere 
interpretato o meno, ma dall'avere 1) a livello teorico: una semantica (anche 
solo operazionale) standard, pubblicata e non ambigua; un'architettura di 
esecuzione efficacemente implementabile su piattaforme diverse; un set di 
librerie che coprono le esigenze di sistemi reali; e che si basino 
*esclusivamente* sul linguaggio e sulla sua architettura. 2) a livello pratico: 
che lo standard sia effettivamente seguito; che queste architetture di 
esecuzione siano effettivamente implementate su piattaforme (hw+s/o) diverse; 
che le librerie siano effettivamente presenti e correttamente funzionanti su 
queste piattaforme. 
Inoltre, la pragmatica ha un posto importante: se un linguaggio offre certe 
caratteristiche, ma e' prassi comune o diffusa non farne uso, la sua 
portabilita' *pratica* diminuisce, mentre quella teorica ovviamente non ne e' 
toccata.
Un conto diverso e' come e' *realizzata* l'architettura di esecuzione. Che puo' 
essere interpretata verso un'architettura fisica sottostante (java bytecode su 
win32, per dire) o interpretata direttamente (java bytecode su picoJava&c). 
Certo, C++ si presta forse meno all'interpretazione (anche se ci si potrebbe 
discutere), ma cio' non dice nulla sulla cosa opposta. Anzi, il fatto che 
l'architettura di escuzione di Java sia specificata in termini di macchina 
virtuale rende piuttosto semplice la realizzazione di una macchina *fisica* 
corrispondente. Fatto e' che poi in concreto e' antieconomico: l'accoppiata 
procesore veloce+s/o+interprete, per il mercato si sta rivelando piu' che 
accettabile, a parte (piccole) nicchie che richiedono performance particolari. 
Il che e' osservabile da chiunque abbia occhi e orecchie e lavori nell'IT (per 
non dire legga riviste di cs).
Detto questo, ne' C++ e Java sono portabili al 100%; ed entrambi sono in una 
certa misura teoricamente e praticamente portabili, molto piu' di linguaggi 
preesistenti. Java e' "piu'" portabile perche' indirizza esplicitamente ed in 
modo piu' completo alcune delle caratteristiche sopra. Non per nulla e' stato 
disegnato tenendo in mente (anche) i problemi piu' pesanti di C++ (ed altri 
linguaggi) in proposito. Mica perche' i progettisti erano piu' furbi, ma 
perche' storicamente venivano dopo.
Uno stesso *sorgente* Java puo' essere ricompilato e poi eseguito 
(interpretandolo, compilandolo just in time, eseguendolo su un picoJava, 
traducendolo in C++ e compilando il risultato, e chi piu' ne ha piu' ne mettta) 
senza problemi. Questa e' portabilita': portabilita' immediata dei sorgenti, 
che preserva la semantica.
Cio' vale meno per C++. Ad esempio, dal punto di vista teorico, esiste da 
qualche tempo uno standard per C++; la sua architettura di esecuzione e' chiara 
su molti punti; la libreria standard e' finalmente niente male. D'altro canto, 
alcuni punti sono lasciati (talvolta volutamente, talvolta per motivi storici) 
aperti (rispetto a Java, vengono immediatamente in mente il supporto al 
networking, al multithreading, all'organizzazione in directory, alla GUI, ma 
anche cose' meno evidenti come la dipendenza della dimensione in bit dei tipi 
dalla piattaforma).
A livello pratico, in effetti, le implementazioni standard di C++ esistono, ma 
sono tuttora usatissime implementazioni nonstandard; i buchi nell'architettura 
di esecuzione standard (e di conseguenza nelle librerie) sono, purtroppo, 
*concretamente* non ignorabili; eccetera. Di conseguenza, un sistema scritto in 
C++ richiede, mediamente, piu' sforzo di un sistema equivalente scritto in Java 
per essere portato ad una piattaforma diversa. Senza poi entrare nella 
pragmatica del linguaggio.
Per le prestazioni: *ci* sono motivi strutturali per cui Java e' piu' lento di 
C++ - ma non hanno molto a che vedere con l'interpretazione. Qualcuno ha gia' 
citato template e generalizzazioni (e io aggiungo quella cosa divertente che e' 
la programmazione generativa ;-); java ha piu' runtime checks (ad esempio sui 
boundary di array e sul downcast dinamico); la garbage collection; i lookup 
nella vtable per *ogni* chiamata di funzione; eccetera - se ne potrebbe parlare 
per ore. :)
Quindi una differenza teorica esiste, ed e' dimostrabile; tuttavia, tale 
differenza non e' grandissima, se si usano architetture di esecuzione 
comparabili (*); siccome pero' in genere nella pratica *non* sono comparabili 
(il codice generato da un compilatore C++ e' eseguito, fatti salvi i dettagli, 
a livello macchina, mentre il bytecode java e' di solito eseguito su una 
macchina virtuale), Java e' - a parita' di abilita' del programmatore - 
*praticamente* piu' lento di C++. Senza per questo essere inusabile, anzi, il 
mercato dimostra il contrario.
Per concludere, c'e' un interessante articolo su CACM di uno o due mesi fa in 
cui si mostra come - a parita' di problema - l'abilita' del programmatore 
conti, nella differenza di prestazioni tra Java e C++, piu' del linguaggio: un 
buon programma Java puo' essere piu' efficace di un cattivo programma C++. 
Lo studio e' informale, quindi non da' nulla di piu' di un'indicazione, pero' 
certamente fa pensare. Anche perche' i linguaggi non stanno li' nell'empireo, 
ma servono a realizzare sistemi reali. 
Il che ci riporta al tema del thread.. imparare a programmare.. si', ma 
programmare *cosa*? :)
-cs
(*) a questo proposito, mi pare lo facesse notare Paolo, se si vuole avere 
codice "sound" a costi ragionevoli, e' buona pratica usare, ad esempio, 
containers STL tipo Vector. Che reintroducono il boundary check a runtime - a 
livello di libreria e non di linguaggio. Discorsi analoghi si possono fare per 
garbage collection, interfacce, eccetera. Per avere codice con qualita' "alla 
java", insomma, alla fin fine tocca usare molte tecniche "alla Java". :)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

> windows è indirizzato a utenti *mediamente* "non esperti" 
CS> 
CS> Utenti, non sviluppatori! ;-)
certo, ma poi qualcuno deve  pure svilupparci. Non sarebbe onesto dire
che sotto windows  non esistono buoni  tool: gli IDE  Turbo di Borland
furono un  bel   passo avanti nella   produttività e  diventarono  uno
standard. 
Quello  che non ho mai capito  è come mai su  win/dos non si siano mai
visti  i  tool tipici di  unix,  che pure   permettono  dei livelli di
produttività notevoli,  a patto di affrontare  uno sforzo iniziale per
padroneggiarli. Ad esempio penso a tool come make, yacc.
CS> Concordo, pero' il punto non e'  solo emacs, 
ovvio, era  solo per  citare  un  esempio di  strumenti   estramamente
potenti, ma poco utilizzati. 
CS> | FLUG: 
www.firenze.linux.it
 | Debian GNU/Linux: 
www.debian.org
 | 
                ^^^^^^^^^^^^^^^^
ho trovato  sul mio  pc un paio   di  file zippati, nomi   tipo DeCSS,
sembrano  eseguibili per   windows o forse  linux,   ma io  non so che
farmene... c'è mica qualcuno che ne ha  bisogno, prima che li porti in
discarica? <g>
Ciao
Marco
-- 
La maturita' e' solamente una piccola pausa nell'adolescenza.
		-- Jules Feiffer


Mi dispiace, ma rimuovere "davvero" programmi per Windows e' una delle
cose piu' difficili da fare.
Sono piu' gli uninstaller che non funzionano e lasciano il registro come
capita che quelli fatti bene.
I vari apt (debian) e rpm (RedHat, SuSE) quando installano e/o aggiornano
e/o rimuovono lo fanno sempre in modo totale e pulito.
LG
 
-- 
**************************************************************************
Leandro Gelasi
V Year Computer Science Engineering at Siena University
email : 
gela...@lucy.ing.unisi.it
Gilles Villeneuve will live forever
**************************************************************************

posso anche convenire....
Eheh... ;)
ciao
Christian
-- 
| Christian Surchi | Debian GNU/Linux developer: 
www.debian.org
 | 
| 
www.firenze.linux.it/~csurchi
 | FLUG: 
www.firenze.linux.it
    |    
+---------------------------------------------------------------+
Computers are like air conditioners.  Both stop working, if you open
windows. -- Adam Heath

Per inciso Python se non ricordo male c'e` anche per win ;)
Si', ed anche per Mac.
ciao
Christian
-- 
| Christian Surchi | Debian GNU/Linux developer: 
www.debian.org
 | 
| 
www.firenze.linux.it/~csurchi
 | FLUG: 
www.firenze.linux.it
    |    
+---------------------------------------------------------------+
Not only Guinness - Linux is good for you, too.

 writes:
PM> 
PM> La gestione c'entra, perche` io sviluppatore  ho spesso bisogno di
PM> installare e   rimuovere   velocemente  pacchetti.   Sotto   linux
PM> nonostante i  passi fatti, l'installazione    del sistema e  delle
PM> applicazioni non e` sempre facile.
scusa, ma da quanto tempo non vedi linux? più o meno di 6 anni :-)
tranne la  slackware, tutte le distribuzioni  hanno  un packet manager
serio, da parecchi anni, molto ma molto prima che windows ne avesse un
abbozzo.
PM> Mi dirai che si  tratta in fondo di  fare pratica, pero` spesso  i
PM> programmi windows si installano e rimuovono facilmente.
scusa se mi  scaldo un poco,  ma o ti manca lo  smiley, o non  conosci
linux.  Se c'è una cosa in cui linux batte windows 100 a 0 è propio la
gestione dei pacchetti.  Se vuoi, posso  motivare anche meglio, ma mi
sembra che stiamo andando OT. 
[Oh  moderatore,  dicci  se  dobbiamo   spostarci   o  il traffico   è
accettabile per la sopravvivenza del NG ;-)]
Probabilmente ti sei accostato  a linux, 'mappando' la  tua esperienza
su  windows.  L'operazione  è fattibile   solo in parte,  perchè sotto
l'interfaccia grafica ci sono due sistemi radicalmente diversi.
PM> 3) Dove posso trovare un compilatore C++ freeware?
PM> 
PM>    GNU gcc
PM> 
PM>     DJGPP
che è il porting del GNU gcc per il dos, a 32 bit.
PM>     CygWinB20
che è il porting del GNU gcc per Win32, fatto da Cygnus Solutions, che
supporta olte 100  piattaforme, incluso un   front-end java ->  codice
nativo.
PM>     Mingw
questo non lo conosco, ma non mi stupirei se fosse pure lui parente
del GNU gcc :-)
tornando al  discorso della selezione naturale   in ambito open source
che facevo nell'altro messaggio,  sottolineo che esisontono anche PGcc
e EGCS:  da qualche mese  c'è  stata una sorta  di  merge con gnu gcc,
integrando    le   ottimizzazioni   pentium   del   primo    e  alcune
caratteristiche più avanzate del  secondo. Se non  erro, gcc è entrato
nel  progetto EGCS:  extensible  gnu compiler  system, o  qualcosa del
genere.
PM> 4) Quale editor posso utilizzare per scrivere i miei programmi?
PM> 
[snip] sulla lista di 9 editor/ide
potrei aggiungere  una ventina di  altri editor/IDE  grafici e non per
linux, tutti open source e gratuiti :-)
Non lo faccio perchè mi sembra ridicolo mettersi a fare la conta degli
editor e perchè mi sembra più importante la qualità  dei tool, che non
la varietà  della  scelta.  Inoltre,  a  meno di  mettersi  a farlo in
proprio, credo  che ogni sviluppatore  è diverso e  non esiste un tool
fatto su misura  per le proprie  esingenze, quindi è importante averne
uno che sia sufficientemente configurabile per adattarselo.
PM> forse sulla voracita` di ram delle interfacce  grafiche, il mio NT
PM> ottimizzato vuole solo 26MB, con linux
    ^^^^^^^^^^^
PM> non sono riuscito ad andare sotto i circa 40MB
basta ottimizzare :-)
certamente non si può scendere al di sotto  dei 16MB se si vuole usare
la  grafica. Questo   almeno   con XFree86, versioni  inferiori   alla
4.0. Del resto l'X Window System è  un sistema client/server quindi ha
il suo peso.    LA  versione 4.0 permette   di   accedere direttamente
all'hardware, ma  non l'ho ancora provata, quindi  non so se sia anche
più leggera.
PORC PUTT!
i    26   MB che citi  non     sono  la ram     fisica  installata, ma
l'occupazione... bisognerebbe capire meglio.  Tieni presente che linux
gestisce diversamente  la memoria: se hai  160 MB (come nel mio caso),
dopo un 'ora  di  utilizzo risulteranno utilizzati  completamente,  ma
solo  perchè linux utilizza   *tutta*  la ram disponibile  per cachare
tutto quello che leggi dal disco, in modo da ottimizzare ulteriormente
le prestazioni.  In questo istante ho  70MB di cache.   Per verificare
l'occupazione di  memoria  'reale' occorre leggere  tra  le righe  del
comando "free". Per dare un'idea:
Poi dipende da che tipo di sviluppo devi fare:  se ti serve la grafica
per il disegno  delle  interfacce, ok,  altrimenti su linux  puoi fare
praticamente tutto   (sviluppo  e non)  da console  o  con interfaccia
semi-grafica, pur non perdendo produttività o utilizzando una macchina
meno dotata.
PM> La mia   opinione  e` che linux   sia  ancora  troppo  lontano per
PM> l'utente medio che  vuoi o non vuoi  rappresenta almeno il 90% del
PM> mercato (bisogna pur campare).
oggi  inizio un esperimento  con   linux e un utente  informaticamente
analfabeta. Vi saprò dire nei prossimi mesi.
PM> Per inciso Python se non ricordo male c'e` anche per win ;)
sì
Ciao
Marco
-- 
- Ciao, sono la rana dalla bocca larga, cosa mangi?
- Mangio tutte le rane dalla bocca larga!
- Duvvuru?
		-- Da it.hobby.umorismo

> mi sa che mi sto infilando in una flame war, quindi
PM> 
PM> Con me no di sicuro... io cerco sempre di essere obiettivo!
perfetto!
PM> Esattamente quello che intendevo,  attualmente linux per  l'utente
PM> medio non e` semplice  e cio` e` il  vero grande ostacolo alla sua
PM> diffusione.
sono abbastanza convinto che non sia così!
ora, siccome siamo in i.s.i. cercherò di motivare meglio ;-)
prendiamo   l'utente   medio, quello  che non   legge    3  riviste di
informatica  al mese,  che   non sa programmare, che    usa il pc  per
navigare in internet, la posta elettronica,  un po' di word-processing
e qualche videogioco, insomma le solite cose.
Sarebbero capaci di installare windows? certo che sì: infili il cd, fa
tutto da solo, rispondi a qualche domanda e via.
Sarebbero   capaci di  installare   linux?   certo  che   sì: con   le
distribuzioni attuali (mi riferisco   agli ultimi mesi) infili il  cd,
rispondi a qualche domanda e via.
Da dove arrivano allora tutte le difficoltà? dal fatto che di *solito*
linux  viene   installato   *dopo* windows:  quindi   il  problema del
partizionamento, il boot  loader, ecc..  prova a  fare  il contrario e
sappimi dire. Windows  esige di essere l'unico e  il solo e  rientrare
nel tuo precedente linux diventa molto difficile.
E non dimentichiamo, che l'utente normale compra il pc con il so *già*
installato e configurato
PM> Molto  spesso trovi  molti programmi  diversi  per  fare una certa
PM> cosa,  assai piu`   che sotto linux,  
questo è vero in  parte, dipende dai settori:  per quanto riguarda  lo
sviluppo ti risponso nell'altro messaggio.
In generale, credo che questo sia un  effetto dell'open source, è come
se ci  fosse  una  sorta  di selezione   naturale: quando comincia  ad
esserci  fermento  in un certo settore   trovi molte applicazioni, poi
piano piano tendono a restare solo  le migliori o le più interessanti,
magari attraverso delle fusioni.
PM> Metti che (X)EMACS sia un po troppo complicato... 
emacs   ha moltissime caratteristiche,   pure troppe  per  un utilizzo
'sano' :-)
Questo  è il  solito   dilemma di  interfacciamente   utente/macchina:
guidare l'utente  tra le     scelte   possibili o mettere    tutta   a
disposizione  e aspettare?  esattamente  come Console  VS  interfaccia
grafica.
IMHO, non c'è  un risposta assoluta a  questa scelta, ma è soggettivo:
se   devo  usare un applicazione   molto  spesso,  voglio  qualcosa di
estramamente potente, niente  interfaccia guidata, anche se difficile.
Lo  imparerò  a poco a  poco, durante   l'utilizzo, ma diventerò molto
produttivo dopo qualche tempo, insomma  sarà fatica ben ripagata.  Se,
al contrario, ho bisogno di utilizzare saltuariamente un'applicazione,
preferisco un'interfaccia che mi guidi nelle scelte. tanto per fare un
esempio: adesso  scrivo pochissimi  testi,   quindi mi  va   benissimo
StarOffice, quando comincerò   a  buttar giù centinaia di   pagine, mi
mettero a studiare LaTeX.
PM> Fornire 1000 funzionalita`  non   significa che il  programma  sia
PM> facile da utilizzare,
al  contrario: *può*  disorientare il  neofita.  Però se  c'è un  buon
manuale, non ci sono problemi.
PM> difficili) sento  il bisogno di  avere subito uno strumento che mi
PM> fornisca subito quel 10% di funzionalita` che mi servono (e che in
PM> emacs non sono molto facili da scovare),
tipo?  :-)
quando ho cominciato su  linux usavo pico,  ma andava bene giusto come
editor  basilare  e  niente  più.  Poi  mi   sono  deciso: "un  editor
flessibile mi   serve, quindi ne  devo  eleggere uno, meglio  se posso
utilizzarlo anche  per  lo sviluppo.  Meglio ancora   se gira anche su
windows, così, se dovessi essere costretto,  non avrei problemi. Emacs
è gratuito,  tutti    dicono  che è  potentissimo:   eletto  a   pieni
voti". Detto fatto, mi sono stampato il  manuale (davvero ben fatto) e
l'apprendimento è stato molto molto semplice e graduale. Certo, il mio
approccio è stato particolare: non mi sono messo  a provare 30 editor,
col   rischio spendere tempo   per   cominciare  a conoscerli e    poi
accorgersi che  non erano abbastanza  potenti per le mie necessità. Ho
scelto emacs  per   fede nei guru    e  ho cominciato a  leggermi   la
documentazione, cominciando dai capitoli che più mi interessavano.
Adesso ho lo stesso problema con UML: mi  serve un tool, possibilmente
non   troppo costoso e  che  non mi lasci a  piedi  più avanti. Bho, o
ArgoUML o Together, vedremo.
PM> pensa  che significa per l'utente medio  volere un'auto e trovarsi
PM> con una astronave (potente, ma difficile da utilizzare).
basta cercare sul manuale qual è il volante :-) 
PM> A me non va di spendere giorni a  imparare emacs, quando un editor
PM> meno potente mi offre cio` che mi serve e mi basta!
ne convengo,    ma  se le   tue  esigenze   cambiassero? ed    è assai
facile... ;-)
Ciao
Marco
-- 
Leggi di Velilind sulla Sperimentazione:
	(1)  Se la riproducibilita' puo' essere un problema, esegui il test
	     soltanto una volta.
	(2)  Se e' richiesta una linea retta interpolante i dati, procurati
	     al piu' due punti.

padroneggiarli. Ad esempio penso a tool come make, yacc.
Ehm, per inciso: questi ci sono tutti. :)


discarica? <g>
Eheheh, maligno, comunque a parte tutto abbiamo ormai da tempo di nuovo
il mirror. Vai su 
ftp.firenze.linux.it/pub/mirror/munitions
.
ciao
-- 
| Christian Surchi | Debian GNU/Linux developer: 
www.debian.org
 | 
| 
www.firenze.linux.it/~csurchi
 | FLUG: 
www.firenze.linux.it
    |    
+---------------------------------------------------------------+
Real Users hate Real Programmers.

 writes:
B> 
B> Mi riferisco a quelle applicazioni "pesanti": fammi vedere un sosia
B> di autocad fatto in java,  da eseguire con  la  JVM, che non  abbia
B> bisogno di un Cray   per girare in  modo  decente, e "mi  mangio il
B> cappello".
java è relativamente giovane, le prima  applicazioni 'grosse' sono gli
ambienti  di sviluppo (JBuilder, Forte4J), i  tool di modellazione UML
(Together,ObjectDomain). 
Hanno bisogno di molta memoria, 256MB per usarli davvero, ma certo non
serve la potenza di calcolo di un Cray e la legge di Moore aiuta :-)
Ciao
Marco
-- 
Ueila'!  Questa e' solo una nota da me, a te, per dirti, a te persona
che stai leggendo questa nota, che io non riesco piu' a pensare a
nessuna famosa citazione, battuta, neppure storia bizzarra, quindi puoi
tranquillamente andare a casa.

> semplice container di String ;-)
PM> 
PM> Tieni presente che in C++  molte limitazioni nascono dal fatto che
PM> non e` un linguaggio OO puro; in  particolare i tipi primitivi non
PM> sono classi e tanto meno hanno una superclasse OBJECT
non mi sono spiegato bene: se metto delle String in un Container java,
per usarle il type checking statico mi impone di seminare il codice di
cast  espliciti  da  Object a String.  Oppure   dovrei  subclassare il
Container per contenere solo String,  perdendo tempo e performance: un
Container parametrico mi eviterebbe entrambi.
PM> Se vi interessa approfondire gli articoli  di Pescio dedicati alla
PM> OOP ed ai template sono una ricca fonte di sapienza!
ho riletto l'articolo  di Pescio, la sintesi che  ne hai fatto, quindi
la domanda è: and so what?
che linguaggi ci restano? esperienze?
Ciao
Marco
-- 
- Qual e' la birra preferita dai gorilla?
- La Guiness dei primati!
		-- Da it.hobby.umorismo

 (se non ricordo, ricordo che il divario era notevole).
??? ma che cosa usi per linux? gnome? kde? 40MB mi sembrano un po'
tantini... Prova WindowMaker... e' un po' piu' parsimonioso ;-)


 serve la potenza di calcolo di un Cray e la legge di Moore aiuta :-)
JBuilder  Foundation (la versione gratuita per intenderci) necessita
effettivamente
di 256Mb di ram ed e' molto lento, mentre la versione JBuilder Standard
commerciale
e' sensibilmente piu' veloce e funziona bene anche con meno memoria
(l'ho usato anche con 64 Mb). Entrambe le versioni sono scritte in java, la
differenza e'
probabilmente soprattutto nel fatto che una viene interpretata, mentre
l'altra e'
un applicazione per win32.
Come gia' ho scritto ci sono delle implementazioni di java che richiedono
pochissima
memoria, alcune anche meno di 1Mb. Chiaramente poi le applicazioni stesse
possono
necessitare di molta memoria, ma questa non e' una prerogativa esclusiva
delle applicazioni
scritte in java, anzi esistono moltissimi esempi di applicazioni scritte in
C o C++ che richiedono
moltissima memoria.
bye
Gabriele

Nemmeno una shell decente con la tab completion! :)
Su NT c'e` di serie, basta attivarlo!
Paolo

fatto un porting da UNIX/Linux. 
Relativo...
Onestamente sono convinto che Linux per quanto buono non
sia ancora pronto, gli strumenti per piattaforma windows li
sento mediamente migliori di quelli per linux.
Per il resto vi rimando anche allo speciale su Linux apparso
in computer programming in questi giorni.
Paolo

facile... ;-)
ma le decisioni le prendi sulla base delle esigenze attuali, e poi
il punto e` sempre quello... io utente non voglio sapere niente
di come fare a preparare la mia macchina, voglio solo che sia
subito pronta per quello che mi serve.
Tempo fa passavo le notti a configurare il mio pc, ora la cosa mi
scoccia ho cose piu` interessanti e importanti da fare.
Paolo

ma non mi sento in obbligo di prendere la parola al posto suo. :)
Non ho preso la sua parola, io parto dal fatto che io stesso sento
l'esigenza di non perdere tempo a configurare, smanettare e
ricompilare il kernel ogni volta che aggiungo una periferica...
con NT lo faccio e basta...
Immagino quindi come possa sentirsi chi di kernel, compilatori
e configurazioni di sistema non ci capisca un tubo o non ci voglia
perdere tempo.
Paolo

analfabeta. Vi saprò dire nei prossimi mesi.
Fammi sapere anche quanto sforzo ti e` costato!
Paolo

che linguaggi ci restano? esperienze?
Eiffel (che conosco di fama)?
Personalmente uso i template solo per i container, per il resto
la OOP la preferisco alla GP.
Paolo

tantini... Prova WindowMaker... e' un po' piu' parsimonioso ;-)
Usavo KDE... ora ho estirpato tutto causa inutilizzo!
Insomma con Linux ho un rapporto di amore/odio
(se volete installazione/disinstallazione).
Paolo

 writes:
PM> 
PM> Un'altro porting...
PM> Il punto e` che gia` questi ti offrono 4 scelte diverse...
premetto che ho usato solo il  djgpp, ma se si  tratta di 4 differenti
porting  dello  stesso  programma  (il   gcc), non saranno    poi cosě
differenti: magari ce la  giochiamo su qualche bug in  piů o  meno, ma
sempre gcc č, o mi sbaglio?
PM> Per  il resto vi rimando  anche allo speciale  su Linux apparso in
PM> computer programming in questi giorni.
č curioso che il punto della situazione su linux sia  fatto da uno che
ha sempre sviluppato su windows e linux non lo conosce...
....e con questo ho detto tutto!
peccato  per   lo   scivolone madornale, perchč  CP    č   una rivista
interessante.
Ciao
Marco
-- 
Chiambretti: "Lei per i giovani cosa fa?".
 Monicelli:  "Il massimo: invecchio".
		-- Da "Il laureato"

gestire.
Scegliere linux a win come sistema operativo non è la miglior scelta
almeno all'inizio del suo cammino di programmatore. 
Io penso che se vuoi e puoi dovresrti installarli tutti e 2 oppure
attenert a Windoz almeno all'inizio, che non è poi così male...
Lawrence Oluyede
rhy...@tiscalinet.it
"Se ti credono rozzo,
  fai il raffinato;
se ti credono raffinato,
  mostrati rozzo."
Johnny Mnemonic