Newsgroup: it.comp.os.linux.development
Titolo: Linux e linguaggio di programmazione

Salve, è la prima volta che posto qui, dopo una ricerca mi è sembrato 
(correggetemi e indirizzatemi nel caso mi sbagli :) ), il NG più adatto 
per la questione.
Da poco sono entrato (4 mesi) nel mondo Linux, e praticamente da subito, 
ho potuto apprezzare la libertà che un utente ha, potendo disporre di 
sorgenti da configurare e modificare a sua scelta.
Chiaramente, uno questo lo deve saper fare, ed è proprio questo il punto.
Ultimamente sto pensando di imparare un linguaggio di programmazione in 
modo da poter "decifrare" i suddetti sorgenti, per capirli, adattarli e 
(quando necessario) modificandorli, per poi (chiaramente con tempo e 
sudore), dedicarmi alla creazione di programmi io stesso.
La prima cosa che ho notato nel mio utilizzo di Linux è la necessità nel 
sistema della presenza del compilatore GCC (compilatore di C# e, se ho 
ben capito, anche C++).
Dopo varie ricerche in cerca di ispirazione, ho praticamente capito che 
il linguaggio C# è quello che (una volta imparato) mi darebbe le 
maggiori possibilità (e perchè la maggior parte dei programmi - come lo 
stesso Linux - sono in C#, e perchè è il più eclettico in assoluto).
Questo, chiaramente lo rende anche il più difficile da affrontare, 
sopratutto per chi (come me) è praticamente a digiuno di programmazione 
(a parte Actionscript, ehm...).
Prima di imbarcarmi in questa "impresa", vorrei sapere se, come pare, la 
conoscenza di C# sia necessaria per avere una reale conoscenza e 
familiarità con gli aspetti del sistema e i programmi che su esso 
girano, e se C#, come linguaggio, sia accessibile ad un autodidatta 
(questo sarei) considerando che, a livello matematico, più in là delle 
divisioni a due cifre non è andato (più o meno, eh... :) ).
Saluti
-- 
Tutte le lesbiche negre di questo paese sperano in una mia sconfitta 
(Robert K. Dornan)

 Saluti
Ciao,
Tutto quello che hai detto puo essere e non essere giusto, tuttavia c'è
un piccolo immenso errore. Laddove hai usato l'espressione "C#" devi
andare a correggere con "C". I due linguaggi sono MOOOLTO diversi: il
primo è creato da M$ ed è molto piu simile a java (classi,
programmazione ad oggetti "forzata".. etc..etc..).. il secondo è tutto
quello che hai detto tu.
PS: un compilatore serio per C# neanche esiste per linux
Per quanto mi riguarda, iniziare col C per poi espandersi a tutto il resto
è la cosa migliore.. tuttavia rimane una mio personalissimo giudizio
Ciao
Mtc`

 č la cosa migliore.. tuttavia rimane una mio personalissimo giudizio
Capisco, e lo consideri fattibile, con un buon libro e parecchio tempo a 
disposizione?
Grazie e ciao


 disposizione?
Io, pur rispettando l'opinione di Matic, invece ti consiglio di partire
da qualcosa di meno ostico.
Solitamente si consiglia il pascal per imparare a programmare, e lo
ritengo ancora un consiglio valido perche` ti impone di progettare il
tuo software in modo ordinato. L'unico problema e` che non lo usa piu`
nessuno da quando delphi sta crollando nelle preferenze.
Potresti partire con Python che, anche se un po' troppo libertino in
certe cose, ti da` comunque delle basi di programmazione. Il suo difetto
e` anche il suo pregio: ti permette in pochi minuti di essere in grado
di programmare, e ha talmente tante librerie che puoi usarlo per
qualsiasi cosa, fino a che le prestazioni o la vicinanza all'hardware
non diventano un problema.
C e C++, secondo me, sono scogli non indifferenti, e possono scoraggiare
o inculcare abitudini sbagliate. Sono a volte troppo rigidi, a volte
troppo libertini nel posto sbagliato e, andando un poco oltre il solito
hello world, ti scontri subito con allocazioni di memoria, puntatori
impazziti, indirezioni di puntatori post-incrementati indicizzate e
porcherie simili che, se non ben disciplinate, ti portano a scrivere
codice incomprensibile e difficilmente debuggabile.
Se vuoi partire con qualcosa di utile che ti dia le basi parti da
Python, insomma, ma trova anche qualche testo sulla progettazione del
software, e magari qualcosa sulla teoria degli algoritmi e sulla
complessita` computazionale.
Bye.
-- 
Alessandro Pellizzari

 complessita` computazionale.
Consigli buoni.
-- 
David N. Welton
- 
http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
- 
http://www.dedasys.com/

 ha scritto nel messaggio
news:pan.2005.05.28....@spamless.libero.it...


> PS: un compilatore serio per C# neanche esiste per linux
e mono cos'ha di male?

 su C o C++?
Infarinatura di c (manuali e tutorial in rete); una lettura semi-veloce di
1/2 giorni.
Poi passi al c++ che è IMHO più semplice del c... leggi tutorial, libri (ce
n'è uno liberamente scaricabile di oltre 400 pagine in PDF sulla
programmazione in QT) e in un paio di giorni ti crei applicazioni grafiche
scritte in c++ di ottima qualità.
Io non avendo mai programmato in c/c++ (anni in vb, una settimana su python,
2 sett. su gambas, più vari altri linguaggi) mi sono meravigliato della
semplicità del c++; mi pare stranamente e inaspettatamente facile.
Io per ora ho provato QT ma proverò anche GTK.
Ad esempio con QT puoi usare le icone dei temi di kde semplicemente con
QPixmap ico;
ico.load( kapp->iconLoader() ->iconPath( QString( "NOME_ICONA_DEL_TEMA" ),
-32 ) );
Puoi usare i db con 
 QSqlDatabase * db = QSqlDatabase::addDatabase( "QSQLITE", "sqlite" ) ;
  db->setDatabaseName( "NOMEDB" ) ;
  db->setHostName( "localhost" ) ;
  if ( !db->open() )
    {
    db->lastError().showMessage();
    qDebug( "Non riesco ad aprire il DB." );
    }
  else
    {
    QSqlQuery q = QSqlQuery( QString::null, db );
    QString query = "SELECT ALL * FROM tabella";
    q.exec( query );
    if ( ! q.isActive() ) qDebug( "Query fallita." );
    q.first();    // Moves to the first record.
    do
      { 
// FAI QUELLO CHE VUOI CON I RECORD
      }
    while ( q.next() );
db->close();
Puoi avere la KAboutApplication :-) (la finestra standard dei programmi kde)
con un paio di righe.
Più semplice di così? E menomale che il c/c++ sarebbe il linguaggio
difficile! In fin dei conti tutti i linguaggi di programmazione si
assomigliano; cambia la sintassi dei cicli if, else, for...
Hai tantissime classi... tantissime proprietà, metodi....
Finalmente ho trovato un linguaggio chiaro, potente, semplice direi, con
ottima documentazione, molti sviluppatori, con un passato (il C), un
presente ed un futuro.  

 presente ed un futuro.  
Una cosa non mi è chiara del tutto: nelle mie ricerche online ho letto 
che fra C e C++ ci sono delle diffenze sostanziali nella sintassi.
Considerando che il mio primo interesse è (prima di creare applicazioni 
a mia volta), riuscire a comprendere i sorgenti di alcuni programmi, 
driver, ecc... e considerando che la maggior parte di questi (come Linux 
stesso) sono scritti in C, se io mi buttassi su C++ e facessi, come da 
te suggerito, una infarinatura veloce e (forse) superficiale di C, non 
potrei avere dei problemi nel decifrare e comprendere codice scritto in C?
Io pensavo in realtà, preferendo la completezza di comprensione alla 
semplicità, di andare prima su C e successivamente su C++.
Oppure mi sbaglio e studiando direttamente C++ questi problemi potrei 
non averli?


 complessita` computazionale.
In effetti ci stavo pensando (a cominciare da linguaggi di scripting 
come Python o Perl), per un'infarinatura di programmazione, l'unico 
dubbio è che studiare un linguaggio di un certo tipo e poi un'altro nel 
giro di pochissimo tempo potrebbe confondermi.
Considerando che da solo lo studio di C sarebbe inoltre piuttosto lungo 
(e lo studio di un altro linguaggio in precedenza lo renderebbe ancor 
più lungo), devo considerare molto attentamente cosa fare.
Grazie


 
Perdinci! Non lo dice mica nessuno che se impari un linguaggio *per
forza* poi non ne puoi imparare nessun'altro! Anzi: piu' ne conosci
(magari non nel dettaglio, ma comunque genericamente) e meglio e': alla
fine il funzionamento e' piu' o meno sempre lo stesso!
Quel che conta quando si impara a programmare non e' *il linguaggio*, ma
*l'impostazione*: prima vedi di capire come funzionano while, if e for,
che bene o male esistono in tutti i linguaggi, poi puoi andare ad
imparare le finezze concesse da ogni singolo.
Cerca su Google "manuale Pascal" e dai una occhiata a quello.
Un paio di mesi di prove, poi passa a C.
Magari dopo altri tre mesi dai una occhiata a Perl, e perche' no a Java
(meglio C++, comunque...).
-- 
Roberto -MadBob- Guido
mail bob4mail***@***
gmail.com
web 
http://madbob.homelinux.com
BrainTop Project maintainer - 
http://braintop.sf.net

 (meglio C++, comunque...).
-- 
Renato

 e mono cos'ha di male?
Che è un interprete/compilatore in bytecode, non un compilatore nativo 
(almeno credo che il poster sopra pensasse a questo).
E tutto sommato non è ancora completo (anche se promette moolto bene... 
meglio di .net e c# di sicuro).
-- 
Renato

 (almeno credo che il poster sopra pensasse a questo).
Mono ha un compilatore JIT molto avanzato, scritto in buona parte, se
non sbaglio, da Paolo Molaro.  Quindi, non solo compila in codice
nativo, ma lo fa al volo.
Saluti,


 fine il funzionamento e' piu' o meno sempre lo stesso!
Io intendevo che, dato che il mio obiettivo "primario" resta C, posso 
cominciare con Python (e credo che lo farò), ma non vorrei rischiare 
l'overdose, quando dopo poco passerei a C.
Saluti


 Computer Scientist)
Ottimo, gli darò un'occhio
Saluti


 parlando di altro?
In teoria stiamo parlando della stessa cosa.
In pratica sto parlando di un livello di astrazione maggiore rispetto ai 
linguaggi, che sono IMPLEMENTAZIONI di questi concetti (passatemi la 
definizione).
Ma finchè non cominci a studiare in merito questa differenza ti sembrerà 
oscura e magari campata per aria...
In ogni caso: in C anche se con dei trucchi si riesce a programmare 
sfruttando almeno in parte il paradigma ad oggetti (gtk funziona così). 
Il C++ non lo conosco, ma mi pare che come il java ti forzi a scrivere 
ad oggetti, anche quando non è necessario/utile. Il programma più 
piccolo che puoi fare è un oggetto con un solo metodo main.
Python è tra i pochi (che conosco) che ti permette tranquillamente di 
saltellare tra un paradigma e l'altro :-)
-- 
Renato

 nativo, ma lo fa al volo.
Yep, lo so (ha fatto progressi il JIT? lo ricordavo piuttosto "alpha").
Personalmente dell'esistenza o meno di un compilatore che produca codice 
macchina non mi potrebbe importare di meno... ma magari è fondamentale 
per il poster originario (Matic credo) :-D
-- 
Renato



chiamato in causa mi espongo un secondo..
mentre dicevo che non esiste un compilatore serio avevo già pensato a
mono, ma ero solito pensare a questo progetto come uno sforzo open source
incompleto e in parte instabile..
personalmente non l'ho mai provato, però prima di scrivere questa breve
sono andato a leggere qualche commento fatto sull'argomento; e sembra che
gente di questo ng lo usi già da tempo senza problemi.. quindi ritiro
quello che ho detto :).. viva mono, ma abbasso cmq il C#sharp :P
Un saluto
M`

 fine il funzionamento e' piu' o meno sempre lo stesso!
concordo sul fatto di imparare vari linguaggi. Che il funzionamento sia 
più o meno lo stesso dissento fortemente, ma è proprio dalle differnze 
che viene il valore di apprendere cose diverse :)

 che viene il valore di apprendere cose diverse :)
Beh, i cicli avranno una sintassi diversa da linguaggio a linguaggio ma un
ciclo for è sempre concettualmente uguale in tutti i linguaggi... e guarda
caso tutti i linguaggi prevedono cicli for :-). Così pure if, else,
dichiarazione di variabili.... anche secondo me i linguaggi sono in parte
"tutti uguali". Le differenze tra basic e c sono minori delle cose che
hanno in comune.
Le differenze sono però molto importanti e ci fanno preferire alcuni
linguaggi ad altri per risolvere problemi diversi; non esiste un linguaggio
universalmente migliore; dipende.

 piccolo che puoi fare è un oggetto con un solo metodo main.
no, no.
C++, come il python (sotto questo punto di vista), e' multiparadigma
(per dire, l' hello world del c e' pressoche' identico a quello del c++)
-- 
28/2/2005 | -1 all' alba!

 quando dopo poco passerei a C.
non credo ci sia rischio di "overdose"
al massimo il problema e' che, dopo un linguaggio ad altissimo livello
come il python, guardando il c ti verra' da piangere (penso al fatto che
non esista una struttura dati che non sia il vettore, che le stringhe non
esistono, che dovrai farti i disegnini su carta per capire dove andare a
parare coi puntatori...)


 giro di pochissimo tempo potrebbe confondermi.
Considerare Python un "linguaggio di scripting" e` parecchio riduttivo.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto
pretenderanno che tu torni indietro/e ti costringeranno a partorire per
poi chiamarlo figlio della colpa / e tu una Maddalena da pentire

 linguaggio universalmente migliore; dipende.
Ma esistono linguaggi che si prestano bene ad un'amplissima gamma di
applicazioni. "Universali"? No. Ma quanto piu` ci si avvicina di certo.


 saltellare tra un paradigma e l'altro :-)
Veramente non sono poi cosi` pochi. Anzi... Java e` relativamente
un'eccezione da questo punto di vista.
C++ e` multiparadigma, cosi` e` Lisp, e Perl (anche se a me il supporto
agli oggetti che offre.. vabbe`). Chiaramente anche Python lo e`.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 (per dire, l' hello world del c e' pressoche' identico a quello del c++)
Vero. E ci sono anche i giochetti...
#include <stdio.h>
int main(){
  int a = 100//**/10
    ;
  printf("%d\n", a);
  return 0;
}
[09:00][riko:Dome] <<smalls>> gcc -pedantic -Wall -std=c89 -o pervertedc
pervertedccpp.c
[09:00][riko:Dome] <<smalls>> g++ -pedantic -Wall -o pervertedcpp
pervertedccpp.c 
[09:00][riko:Dome] <<smalls>> ./pervertedc
10
[09:00][riko:Dome] <<smalls>> ./pervertedcpp 
100
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č pių cristiano imporsi col rifiuto


 semplicità, di andare prima su C e successivamente su C++.
IMHO stai un po' sottovalutando il problema. 
Conoscere un linguaggio e` come conoscere la grammatica italiana. Per
capire la Divina Commedia e` fondamentale, ma assolutamente
insufficiente.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 l'overdose, quando dopo poco passerei a C.
Ma sei sicuro che sia quello che ti serva?
Mi spiego... quale e` il tuo obiettivo?
Vuoi conoscere "il C"? Vuoi imparare a programmare?
Vuoi imparare a scriverti qualche programma utile?
Vuoi mettere le mani nel Kernel? (in questo caso devi conoscere ben
altro che il C... tipicamente ti servono anche informazioni oltre a
conoscere il C, e non so quanto sia "utile").
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 assomigliano; cambia la sintassi dei cicli if, else, for...
Vedo che persisti.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 agli oggetti che offre.. vabbe`). Chiaramente anche Python lo e`.
Lisp -> Completamente sconosciuto ai più (dal poco che ho visto ha una 
sintassi troppo aliena rispetto al normale...)
Perl -> Il supporto agli oggetti è una roba appiciccata male con lo 
sputo, non lo conterei... altrimenti anche VBScript ha il supporto agli 
oggetti! (ok, ok, non volevo offendere, mettete giù i lanciafiamme!!! ;-) )
In ogni caso, senza andarci a intorcinare troppo, ci sono linguaggi che 
ti "spingono" più verso un approccio o verso l'altro, e ci sono 
linguaggi piuttosto agnostici, che ti permettono di sfruttare comunque i 
vantaggi di entrambi i metodi (ad esempio in uno script di 20 righe in 
python sfrutti più volte il paradigma ad oggetti per accedere alle 
funzioni di libreria).
-- 
Renato

 funzioni di libreria).
In Python se per questo anche se scrivi esclusivamente codice
procedurale stai usando oggetti, visto che le funzioni sono comunque
oggetti :))
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 universalmente migliore; dipende.
e su questo concordo in pieno.

 M`

 oggetti :))
Hehe... il bello del python: rende naturale e trasparente usare 
funzionalità avanzate :-)
-- 
Renato

 Urk! E si usa? :-)
Non capisco lo smiley. Se programmi in C++, usi il C++ standard, come è 
definito dallo Standard ISO del 1998 e dalla revisione del 2003.
Max

 (anche su linux e su osx, alla facciazza di .net).
completamente .net 2.0? a me pareva che ci fosse *qualcosa* di .net2.
D'altronde mi chiedo pure a che serva SWF, tanto i programmi per 
ms.net
 
probabilmente usano p/invoke e quindi non girerebbero ugualmente (i.e. 
paint.net
)

 Urk! E si usa? :-)
E perche` non si dovrebbe? E` sicuramente uno dei linguaggi piu` usati
al mondo. Stroustrup dice che e` il piu` usato (nuovamente). Non so su
che basi lo dica.
Se vai su Sourceforge scopri che e` il terzo linguaggio piu` usato dopo
C e Java. Insomma... direi che proprio poco diffuso non e`.
Inoltre 6 anni informaticamente sono tanti. Ed era molto diffuso anche
prima di essere standardizzato, visto che e` nato nella prima meta`
degli anni 80. Nell'84, se ricordo bene.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 
Tutti gli uomini si assomigliano perche' hanno due gambe e due braccia
(fatte le debite eccezioni, ma si tratta di casi particolari. Non
andiamo a cercare il pelo nell'uovo ;-) ), cosiccome tutti i linguaggi
si assomigliano in quanto permettono di eseguire cicli, eseguire blocchi
di codice in date circostanze e ricevere un input o buttare fuori un
output. Se non fa queste cose, non e' piu' un pezzo di codice: e' un
.txt con la lista della spesa!
In fin dei conti, alla fine viene tutto convertito in binario, dunque
anche volendo non possono esserci differenze cosi' sostanziali tra una
cosa e l'altra...
-- 
Roberto -MadBob- Guido
mail bob4mail***@***
gmail.com
web 
http://madbob.homelinux.com
BrainTop Project maintainer - 
http://braintop.sf.net

> Considerare Python un "linguaggio di scripting" e` parecchio riduttivo.
Beh, è la definizione più usata per descriverlo, sopratutto nel 
confronto con i vari C e C++.
Poi io non lo conosco...


 insufficiente.
E' proprio questo il punto, io ora non conosco nemmeno la grammatica 
italiana.
Immagino (anche non conoscendo la situazione, ma non ho mai immaginato 
di riscrivermi i driver del modem dopo 3 mesi, per dire) che non basta 
imparare un linguaggio, ma del resto, come si suol dire, da qualche 
parte bisogna pur cominciare.
E, come tu hai detto la grammatica è fondamentale.
Per cui, come primo passo è fondamentale; che poi io vada a scrivere 
qualche piccolo programma o vada a spulciarmi i sorgenti per cercare di 
capirci qualcosa (magari non riuscendoci, non lo metto in dubbio) la 
conoscenza di un linguaggio male non mi farà.
Naturalmente, se tu avessi consigli su come integrare le mie future 
conoscenze saranno bene accetti :)
Saluti


Max M. ha scritto:

Lo smiley perchè ho sempre sentito storie dell'orrore su dialetti 
incompatibili di c++... ma forse si riferiscono alle dipendenze da 
librerie non portabili.
-- 
Renato

 
Python è un linguaggio multipurpose compilato in bytecode just in time, 
come il java. Solo che il compilatore viene invocato automaticamente.
(correggete la definizione, se necessario)
-- 
Renato

 conoscere il C, e non so quanto sia "utile").
Come scritto altrove, lo immagino


gabriele renzi ha scritto:

A implementare programmi multipiattaforma con interfaccia nativa senza 
riscrivere una virgola.
-- 
Renato

 definizione).
A grandi linee ho capito, poi per l'effettivo significato, mi sarà più 
chiaro fra un po' :)
Saluti


 cosa e l'altra...
no, significa solo che sono tutti turing-completi.
Ripeto, mostrami una qualche "somiglianza" tra codice 
haskell/C/Smalltalk  (codice non del tutto banale, tipo una routine di 
sort in-place, o un programma che fa "echo" da console, o una funzione 
fattoriale) e mi convinci a darti ragione ;)

 riscrivere una virgola.
scusa la salva di domande, ma non trovo mai nessun mono/.net-taro che mi 
risponda quindi approfitto :)
interfaccia nativa su win32 ok, ma su mac?
E su unix con gtk?
Cosa offre di più rispetto a gtk#?
Se funziona nativamente su mac, come fa?
si son riscritti un toolkit che wrappa aqua con un api SWF ?
E perché allora non l'hanno fatto per gtk?
E se io uso kde, come viene l'interfaccia?
si appoggiano a X11 direttamente?
Oppure usano gtk# e quindi a quel punto potevo usare direttamente quello?
Io l'unico vantaggio di SWF lo vedo nel far andare su mono applicazioni 
desktop scritte con 
VS.NET
, solo che come dicevo non sono a conoscenza 
di nessuna "grossa" che sia in grado di funzionare perché si appoggiano 
tutte a librerie di win32.


Vabbe', tagliamo corto: diciamo che i linguaggi comunemente piu' usati
(C, C++, Java, Python, Perl, Ruby, Pascal, Cobol, e molti altri che non
sto qui a citare ma hai capito il genere), o comunque quelli cui si fa
riferimento in questo thread e/o cui fa riferimento l'OP, cambiano
pressoche' solo nella sintassi mentre nella logica sono bene o male uguali.
Va bene cosi' ;-) ?


 Vedo che persisti.
Persisto e imparo; da qualche parte dovrò pur iniziare e non sarà certo da
java (tanto per finire con una frase storica).

 e su questo concordo in pieno.
E menomale :-)
P.S. Per me fu traumatico il passaggio da quickbasic a vb: il comando print
era morto.

 applicazioni. "Universali"? No. Ma quanto piu` ci si avvicina di certo.
Fortunatamente.

 distinguono: abbiamo mani, piedi, capelli (io ce li ho)...
io non critico che ci siano similitudini tra vari linguaggi, io rispondo a
" i cicli avranno una sintassi diversa da linguaggio a linguaggio ma un 
ciclo for è sempre concettualmente uguale in tutti i linguaggi...
e guarda caso tutti i linguaggi prevedono cicli for :-)
"
la sintassi per i cicli in prolog, in Smalltalk, in Scheme ed in tanti 
altri linguaggi *non esiste*, esistono solo delle astrazioni che possono 
essere usate come loop ma che non hanno nulla a che vedere con un ciclo 
for in C.

 tutte a librerie di win32.
Questo è abbastanza irrilevante, secondo me. Da una parte non mi 
imporata più di un tot di cosa faccia windows e .net, mi importa avere 
uno strumento potente su linux. Se poi quel che ho prodotto funge ANCHE 
su windows, con lo STESSO eseguibile, meglio ancora.
Dall'altra parte, su windows non ci sono grosse app .NET tutte in 
managed code perchè gli sviluppatori o non sono capaci o non hanno 
ancora avuto tempo, secondo me. Son troppo legati al vecchio mondo di 
VisualXXX. Se gli sviluppatori OSS produrranno delle applicazioni belle 
e funzionali in mono con MWF allora ci saranno applicazioni .NET tutte 
in managed code anche su windows :-)
In fondo a noi non interessa tanto poter lanciare le "loro" 
applicazioni. Più importante è poter lanciare su windows le "nostre"!
E se poi un "vendor" vuole ottenere un progetto multipiattaforma 
spendendo poco saprà che gli basta usare 
VS.NET
 e non fare chiamate 
native. Per alcuni può essere il selling point.
Spero di averti chiarito qualche dubbio, ma leggi il link sopra, che di 
sicuro ha info più precise delle mie :-)
-- 
Renato

 sicuro ha info più precise delle mie :-)
si mi sei stato utile, grazie :)
Sebbene non sia un fan della piattaforma .net (preferisco i linguaggi 
dinamici con tutta la cultura che hanno dietro) un buon blog per 
aggiornarsi su quel che succede è sempre una cosa utile :)

 E nemmeno questo e` vero.
Per dare qualcosa di piu` concreto di un semplice 'no', consiglio all'OP
di dare un'occhiata ai linguaggi funzionali, come Scheme, Erlang,
Haskell e compagnia come esempio di linguaggi che non hanno sempre un 'for'.
Saluti,
-- 
David N. Welton
- 
http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
- 
http://www.dedasys.com/

 (correggete la definizione, se necessario)
Non credo che Python abbia un vero 'JIT' che compila in codice nativo,
come alcune implementazioni di Java (o Mono).


 wrote:

-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 Poi io non lo conosco...
Ecco... appunto.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 parte bisogna pur cominciare.
E questo e` chiaro. Ma mi spiego...
Il C e` un linguaggio molto semplice da imparare, ma parecchio lungo e
complesso da padroneggiare ed usare. Mi spiego meglio...
Se guardi per esempio il K&R ti fa tutto il C in circa 200 pagine +
appendici.
Solo che per *usare* tale linguaggio, non scazzare con i puntatori, non
fare casino con allocazione e deallocazione in pratica totalmente di
memoria ci va un bel po' di esercizio.
Per fare poi programmi "utili" o per lo meno "interessanti" lo sforzo e`
notevole. Sia che vuoi darti alle cose "teoriche" (che so io... fare un
motore di intelligenza artificiale o un interprete di espressioni
regolari, entrambe cose che si possono fare in ANSI C) sia che ti vuoi
studiare qualche syscall o qualche libreria, ci vorra` molto tempo.
E sarai *lento* a scrivere il codice, specie all'inizio, e specie per le
cose banale.
Partendo invece da un linguaggio di piu` alto livello, non hai
all'inizio un sacco di scogli inutili per imparare a programmare. Non te
la devi vedere con la gestione della memoria e non devi crearti da 0
tutte le strutture dati.
E li impari come si scrive un programma, come si struttura. Quali sono
gli errori piu` comuni. Prendi confidenza con le syscall senza doverti
preoccupare del *modo* in cui vengono gestite in C.
Scrivi roba insomma.
Poi puoi guardarti il C e fare tutto quello che vuoi. Ma nel frattempo
hai fatto piu` "gavetta" in meno tempo.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 java (tanto per finire con una frase storica).
Oh beh... ma questo e` pacifico. Un'occhiata daccela comunque, piu`
avanti magari. Alle volte lo chiedono per lavorare. Tendenzialmente *io*
lo evito volentieri... ma vabbe`.
Comunque sono fortemente convinto che il Java *non* sia un buon
linguaggio didattico.
un umile studente di logica-matematica.


 come alcune implementazioni di Java (o Mono).
Per x86 lo ha. Si chiama Psyco, poi io non lavoro in genere su x86, ergo
non lo ho mai usato, ma se ne parla abbastanza bene.


 la sintassi di C, ma è un primo passo. almeno
Eh...


 librerie non portabili.
Mah.. se uno sa programmare riesce a scrivere codice parecchio
portabile. Il punto e` che uno potrebbe avere la tentazione di usare
features non standard, oppure librerie non portabili.
Ma questo vale per moltissimi linguaggi.


 
Tralasciando forma e contenuto, vogliamo dare una controllata almeno 
alla sintassi della frase in firma?
Troncata cosi' mi da' un senso di sospensione insopportabile.
Alessandro.

 Troncata cosi' mi da' un senso di sospensione insopportabile.
"Certi momenti" di Pierangelo Bertoli.

 "Certi momenti" di Pierangelo Bertoli.
Ok, grazie.
Alessandro.

 profiler e a quel punto le riscrivo in C o in C++.
Mi sembra sensato...


 hai fatto piu` "gavetta" in meno tempo.
Credo che sia un ottimo consiglio
Saluti


 Stroudrup č anche il creatore del C++ :)
Salvo l'ortografia, quello che e` innegabile e` che vede nuovo interesse
per linguaggio (piu` grosse compagnie che pagano, lui e quelli del
comitato per consulenze).
Poi come dicevo piu` di qua o piu` di la e` indimostrabile.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 Ok, grazie.
Avevo finito righe e caratteri (4 righe x 80 caratteri :)) )


 "Certi momenti" di Pierangelo Bertoli.
Bravissimo!


 pressoche' solo nella sintassi mentre nella logica sono bene o male uguali.
A parte il fatto che non credo che necessariamente sia una questione di
piu` "usati". Prendere linguaggi *simili* e poi dire che sono *simili*
non vuole dire molto.
Ci sono un sacco di linguaggi estremamente comodi e interessanti che non
hanno quella sintassi. Non hanno quel modo di programmare.
Non solo. Anche fra questi linguaggi, il "modo corretto" di programmare
non e` lo stesso. Ci sono convenzioni che non sono parte del linguaggio,
ma che ugualmente e` bene rispettare.
Per esempio in Python uno potrebbe aggiungere controlli di tipo ad ogni
chiamata di metodo (chiaramente sarebbe un controllo dinamico, ma poco
importa) e simulare public e private del C++ (con risultati deludenti,
peraltro). Questo modo di programmare sarebbe comunque in generale
scorretto. 
In Python questo e` un costrutto valido.
inc = lambda x: x + 1
ma in generale sarebbe meglio scrivere
def inc(x): return x + 1
Sarebbe invece piu` accettabile una cosa del tipo
map(lambda x: x+1, y)
(anche se lambda e` in qualche modo scoraggiato, quello sarebbe un
esempio di uso "corretto")
x = 2
y = (lambda b, c1, c2:
     lambda n: b * c1(n) + (not b) * c2(n))\
     (x < 3, lambda x: x + 1, lambda x: x + 2)(x)
print y
Questo e` codice python valido. Tuttavia e` da omicidio.
BTW fa solo questo
def f(n):
    if x<3: return n + 1
    else: return n + 2
Il primo costrutto invece sarebbe stato sostanzialmente accettabile in
un linguaggio funzionale puro.
Poi ci sono un sacco di sottigliezze. Per esempio questo codice in C ha
senso
int arr[MAXL];
if (x<MAXL && cond(arr[x])){
        /* ... */
}
Siccome && cortocircuita e` parecchio comodo.
In Pascal la stessa cosa darebbe errore e andrebbe resa con due if.
Fanno la stessa cosa? Certo. Ma ci sono comunque parecchie differenze.
E sono differenze non trascurabili.


 quelle che ci distinguono: abbiamo mani, piedi, capelli (io ce li ho)...
Ma non tutti gli uomini fanno le stesse cose allo stesso modo.


 native. Per alcuni può essere il selling point.
Pensa che invece secondo me sarebbe altrettanto importante. Scrivere
applicazioni nate in ambiente X11 che poi siano facilmente portabili su
Windows non e` un grosso problema. In Python per esempio si fa parecchio
presto (giusto con un po' di attenzione).
Invece sarebbe carino che gli sviluppatori win potessero facilmente
portare roba su linux a sforzo minimo.


 portare roba su linux a sforzo minimo.
E lo possono (potranno) fare. Basta che smettano di usare porcate native 
in un linguaggio portabile :-)
Cioè usare SWF che sarà compatibile 1:1 con MWF :-D
Se invece come il programmatore medio di shareware per windows che fa 
malamente quello che il software libero fa meglio e della portabilità te 
ne sbatti, continuerai a programmare in VB6 o Delphi per un bel po' ;-)
-- 
Renato
-- 
Renato

 
Daccordo che un linguaggio puo' fornire qualche "comodita'", ma si
tratta pur sempre di "zucchero sintattico", di operatori aggiunti alla
specifica del linguaggio ma che, una volta passati al compilatore /
inteprete vengono tradotti sempre nello stesso modo, ovvero una sequenza
di for, if e quantaltro.
In C non c'e' il "foreach" per iterare all'interno di una struttura
dati, ma si puo' forse definire il "foreach" diverso dal classico "for"?
Concettualmente sono la stessa identica cosa.
E le condizioni "multiple" fornite dagli operatori logici disponibili in
C ma non, come da te detto, in Pascal? Un
if ( condizione1 && condizione2 )
	/**/
e' poi tanto diverso da
if ( condizione1 )
	if ( condizione2 )
		/**/
??? L'"if" fa sempre la stessa identica cosa, ovvero valutare una
condizione: il fatto che ne possa valutare una sola alla volta o mille
utilizzando degli operatori specifici non lo rende una cosa diversa da C
a Pascal.
-- 
Roberto -MadBob- Guido
mail bob4mail***@***
gmail.com
web 
http://madbob.homelinux.com
BrainTop Project maintainer - 
http://braintop.sf.net

 a Pascal.
il cuore del discorso č "and" non "if".
in pascal
  if ( a and b)
non č per niente la stessa cosa di
if (a)
  if (b)
(beh meglio il cuore del discorso č un altro ancora, ma io mi chiamo 
fuori ;)

 ne sbatti, continuerai a programmare in VB6 o Delphi per un bel po' ;-)
Se il "tu" parla di me, ci siamo poco :))
Io programmo sistemi *nix in generale e MacOS X in particolare. :)
E per dire... Cocoa ha un sacco di cose *stupende* che purtroppo GNUStep
(a meno che io non mi sia perso qualcosa) non ha ancora.
Idem un sacco di framework per MacOS X. 
Chiaramente non sempre scelgo di rendere la cosa portabile. Spesso non
mi conviene per nulla. E poi se devo fare qualcosa di portabile vado di
Python (poi in generale vado *comunque* di Python... ma vabbe`).


 
Perdonami, ma sono un po' arrugginito in Pascal (diciamo che l'ho visto
quel tanto che bastava per fare gli esercizi alle superiori, diversi
anni or sono...) e non ho troppo ben presente il significato che "and"
assume in tale contesto: in cosa consisterebbe l'enorme differenza tra i
due?


 a Pascal.
Ribadisco... il problema era solo di cortocircuitazione. E no, non lo
rende una cosa diversa. Ma siccome ci sono una valanga di dettagli, non
e` che imparato un linguaggio imperativo si sono imparati tutti i
linguaggi imperativi.
Alla fine anche l'if si puo` ricondurre ad un while. E il while al goto.
Oppure alle istruzioni di salto dell'assembly.
Resta il fatto che un programmatore Perl non puo` sperare di programmare
in Assembly come programmerebbe in Perl. E un programmatore C che non
usasse le caratteristiche di Perl o di Python quando fosse in tali
ambienti scriverebbe codice pessimo.
In Python puoi benissimo scrivere
a = ("pippo", "pluto", "cane")
for i in xrange(len(a)):
    print a[i]
ma saresti da prendere a schiaffoni (mentre in C o anche in C++ sarebbe
perfettamente accettabile).
Ci sono linguaggi che non hanno i puntatori. E chiaramente certe cose
vanno fatte diversamente. Linguaggi che hanno strutture dati
potentissime, che in altri linguaggi sono da simulare (scrivimi un
affare che si comporti come un dict di Python in C, per dire. E che non
sia complesso da usare, ma comodo e altrettanto "sicuro". Fare si puo`
fare. Dopo tutto il dict di Python in CPython *e`* implementato in C --
prendila al 90% --).
Poi vedo che io e te non ci stiamo ben capendo, quindi finiremmo solo
per fare decine di post dicendo piu` o meno la stessa cosa :))
Questo era quello che avevo da dire.
Posso solo chiederti una cosa? Con che linguaggi programmi abitualmente?
Poi ti dico anche perche` lo chiedo, e non e` nulla di "offensivo". :)
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 due?
Che in C && cortocircuita, in Pascal and non lo fa. Ovvero viene
valutata sempre anche l'altra cosa.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 comitato per consulenze).
E' anche innegabile che voglia "farsi" un po' di pubblicità, quindi 
magari un parere "esterno" ai creatori dei linguaggi sarebbe più 
attendibile, anche se difficile da effettuare e probabilmente inutile
Saluti


 Se il "tu" parla di me, ci siamo poco :))
hehe... era retorico ovviamente. Il fatto è che chi nasce e vive su 
windows spesso e volentieri la portablità non sa nemmeno cosa sia a 
livello concettuale.
-- 
Renato

 Mi sembra sensato...
E' sensato eccome, ma non é facile. Io ho provato piů volte a fare ponti
python-C con swig ma piů di hello world non ne ho cavato :-(
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail** 
-<! Le donne e le salsicce sono la stessa cosa: pelle fuori e maiale dentro !>-

 python-C con swig ma più di hello world non ne ho cavato :-(
Non ho mai usato swig. Boost e/o PythonAPI sono la chiave.
Non ho detto che ho "portato" roba C o C++ su Python, ma che me la sono
scritta :))


 livello concettuale.
E purtroppo devo dire che in un buon numero di casi hanno ragione.
Un conto e` essere portabile in ambiente GNU e X11. Si tratta "solo" di
stare attenti a certe cose e usare bene autoconf.
Le librerie GUI si comportano ugualmente anche sugli altri flavours.
Esattamente come portare demoni e altra roba cli su MacOS X nella
maggior parte dei casi e` solo una questione di ricompilazione.
Purtroppo con le GUI non e` sempre cosi`. Si vede che queste
applicazioni portate non sono native. Che si comportano in modo diverso,
che chi le ha scritte non si e` letto nemmeno due righe delle linee
guida di sviluppo apple...
E poi ci si perde un bel po' features che MacOS X offre gratis e che
sono altrimenti lunghe da implementare (o impossibili).
Insomma... non tutti i progetti e` giusto che siano cross-platform.
Quello che e` giusto e` che siano scritti bene, in modo che se c'e`
l'esigenza di fare il benedetto port, si possa procedere senza troppe
magagne.


 
85% C, 8% PHP, 5% Perl, 2% Java. E comunque, come sopra vagamente
accennato, tratto tutto come C. Si capiscono molte cose, vero ;-) ?


 presto (giusto con un po' di attenzione).
Infatti.  Io ho scritto un'applicazione in Tcl, con il toolkit Tk per un
cliente.  Tutto il lavoro l'ho fatto sul mio sistema Linux, e da lui
abbiamo provato su Windows e ha funzionato tutto al primo colpo.  Ho
modificato pochissime cose solo per avere un aspetto piu` gradevole,
ma... anche sapendo in teoria la potenza di Tcl/Tk a fare lavori cross
platform, vederlo funzionare cosi` bene e` stato proprio carino.
-- 
David N. Welton
- 
http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
- 
http://www.dedasys.com/

 python-C con swig ma più di hello world non ne ho cavato :-(
Swig, e`, a mio parere, un po' una porcheria da usare solo quando hai un
.h molto grande e poco tempo per adattare l'API C al linguaggio che stai
usando.  Ogni linguaggio ha un suo modo di fare le cose, e un giusto
livello di astrazione.  E` molto meglio scrivere un API che va bene per
il linguaggio che stai usando, insomma.
Detto questo, vorrei prendere qualche riga per publicizzare Tcl da
questo punto di vista.  Ormai non e` piu` di moda, come Python, o Ruby
che da` segni di essere il linguaggio del momento.  Al livello di Tcl
puro, si possono fare cose carine, e secondo me ha un livello di
astrazione buono per quello che deve fare (i socket sono molto piu`
carini di quelli in Python ad esempio).  Ma Tcl veramente inizia ad
essere un piacere quando lo integri con un po' di C.  L'interfaccia e`
documentata benissimo, e` facile da usare, e ti permette di accedere a
quasi *tutto* il linguaggio dal C.  Puoi fare tante cose divertenti.  E
inoltre il codice C di Tcl stesso e` bellissimo - fra il migliore che
abbia mai letto (a parte i file che trattano di regexp che vengono da
un'altra parte).
Ciao,


 questo punto di vista.  
<snip>
sottoscrivo, essendo un fan di TCL (pur non avendolo mai appreso a fondo).
A livello di maturità della piattaforma (implementazione, interfaccia 
per le estensioni, packaging, embedding) mi è sempre parso il più 
avanzato di tutti i linguaggi dinamici :)

 accennato, tratto tutto come C. Si capiscono molte cose, vero ;-) ?
Si. Sostanzialmente programmi tutto in un linguaggio, il secondo
linguaggio che usi e` "simile" al primo. Nel senso che hai cose in piu`,
ma sono piu` cose di "comodo" che effettivamente costrutti nuovi.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto


 un oggetto o un while, esiste solo per comodita'...
mi hai fatto venire in mente una cosa: ti consiglio di cercare il libro 
"concepts, techniques and models of programming languages" (se cerchi 
molto bene si trova anche un vecchio draft scaricabile in rete).
Gli autori prendono un mini linguaggio ed una piattaforma virtuale, e 
poi per tutto il libro aggiungono delle cose simulando vari linguaggi di 
alto livello (non mi pare scendano anche a puntatori e registri, ma 
potrei sbagliare).
Ci sono alcune cose che aggiungono come zucchero sintattico, del tipo:
for x in lista è equivalente a una funzione ricorsiva
Ma per introdurre altre cose devono cambiare la definizione semantica 
del linguaggio, in sostanza la piattaforma virtuale su cui gira. 
Insomma, non c'è solo zucchero sintattico, ma lascio la spiegazione agli 
autori che sono più competenti :D

 
E ti diro' di piu': programmo in
C per passione (e, attualmente, per lavoro)
PHP per hobby (e, in passato, per lavoro)
Java per coercizione
Perl per sbaglio (non nel senso che sia uno sbaglio programmare in Perl
;-) !!! )
Prima o poi dovro' decidermi a dare una mezza occhiata anche ai
linguaggi funzionali, ma dopo la grossa delusione del paradigma ad
oggetti (che a sentirne parlare sembrava tutto un'altro mondo ma che
alla resa dei conti e' la scoperta dell'acqua calda) non so dove trovare
la voglia per farlo...


 la voglia per farlo...
Ridacci un occhio. Vale la pena. E comunque ci sono tantissimi stili di
OOP. Non necessariamente tutti ti piacciono.


 
Tutto cio' che porta ad un livello di astrazione troppo elevato non mi
piace (forse proprio perche' programmo in modo osceno e mettendoci di
mezzo pure del lavoro extra per il compilatore mi salterebbero fuori
degli obrobri prestazionali ;-) ).


 degli obrobri prestazionali ;-) ).
Questione di gusti. Io mi sono accorto che usando bene OOP impiego
frazioni di tempo di quello che impiegherei non usandola. Non solo, mi
costa molto meno mantenere il codice, ottenere collaborazione.
E poi in genere ho anche un aumento di prestazioni, dovuto al fatto che
posso permettermi di scegliere il modo piu` rapido di fare le cose,
dovendo cambiare solo il minimo indispensabile, e di pensare agli
*algoritmi* piu` veloci, invece che mettermi da subito a spremere il
codice.
Poi questione di gusti, voglio dire.


 questo punto di vista.  Ormai non e` piu` di moda, come Python, o Ruby
...
Non ho mai cercato di impararlo, la sintassi non mi attira. Non dubito che
abbia i suoi punti di forza, come ogni altro, ma non posso essere "fresco"
su 10 linguaggi.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
		-<! $>cd /pub	$>more beer !>-

 scritta :))
Pignolo...
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**


 roba per python o mi devo scaricare il mastodonte?
Mastodonte, afaik. O meglio... io mi sono preso il mastodonte, visto che
il mastodonte mi interessava anche per altro.
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchč
venne un polacco ad insegnargli che č piů cristiano imporsi col rifiuto


 su 10 linguaggi.
Il bello della sintassi di Tcl e` la sua flessibilita` estrema.  In C,
Python, Perl e compagnia, if, while, foreach ecc fanno parte della
'sintassi'.  In Tcl, sono solo altri comandi!
Per esempio:
puts "hello world"
E` un comando (puts) che prende un argomento, una stringa.
if { 1 } { puts "hello world" }
E` un comando (if) che prende due argomenti - un'espressione, 1, che in
questo caso sara` sempre vero, e un secondo argomento composto di codice
Tcl da valutare se l'espressione e` vera.
Questo vuol dire che e` possibile scrivere nuovi 'control structures' in
Tcl stesso, con l'esempio classico del 'do ... while' del C che non c'e`
in Tcl, ma e` facile da scrivere in meno di 20 riga.
Detto questo, e` piu` che ragionevole che ognuno cerca di seguire le
cose che piacciono a lui!
Saluti,
-- 
David N. Welton
- 
http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
- 
http://www.dedasys.com/





David N. Welton wrote, tre volte...
E mi diceva di non aver spedito il messagio:-/


 E mi diceva di non aver spedito il messagio:-/
LOL :)
-- 
Adesso quando i medici di turno rifiuteranno di esserti d'aiuto / perchè
venne un polacco ad insegnargli che è più cristiano imporsi col rifiuto
pretenderanno che tu torni indietro/e ti costringeranno a partorire per
poi chiamarlo figlio della colpa / e tu una Maddalena da pentire