Newsgroup: it.comp.programmare
Titolo: Da visual studio a ...

Salve a tutti, vorrei fare il passaggio da visual studio e relativi 
linguaggi .net, ad un qualche altro linguaggio pi� multipiattaforma..
Attualemnte ho su Linux e mi ci trovo benissimo..
Sto provando Netbeans (come ide) e java come linguaggio.
Non riesco per� a trovare un sistema produttivo come quelli 
sull'ambiente microsoft.
Voi direte: resta su microsoft.
Il problema � che ho l'ide, 
vs.net
, che pesa un sacco e volevo provare 
qualcosa di alternativo.
Dunque
a) per il client / server potrei anche restare su .net o addirittua (non 
uccidetemi) su vb6 che in quanto a produttivit�, a mio giudizio, � 
secondo a pochi
b) per il web ? 
asp.net
 � un po' un carnaio.. ci sviluppo e ci ho 
sviluppato.. x�... x�...
Si accettano consigli, grazie

 [...]
Ciao  Manlio


Ciao Manlio grazie... Python lo sto valutando molto bene.
Però attenzione: a livello di produttività come puoi consigliarmi emacs ?
Non è una critica, è proprio una domanda.
Nel senso, io avrei bisogno di un ambiente IDE dove posso trascinare 
controlli, griglie, binding ai dati etc.
Potreste dirmi "Beh questo c'è l'ha Microsoft con Vs.net" però io 
appunto rilancio "Caspita, ma solo Ms ? E gli altri ?"
Ripeto, ho visto netbeans con java ed è proprio quello che sto cercando.
Però è Java.. e java è un ottimo linguaggio e  non lo scoprio io, ma un 
po' complicato per i miei gusti...
Una somma tra : Python + ambiente Rad  ????
Grazie ancora e ciao


Gli altri evitano di fare cose del genere con il codice, ed invece hanno 
dei designer per la GUI **ben separata**.
Ad esempio, vedi il designer delle Qt.
Se vuoi comunque scrivere direttamente codice per la GUI, sappi che con 
Python ed un toolkit grafico come Qt è così immediato, che non c'è 
bisogno di uno strumento che ti aiuti.
Ciao  Manlio

Come ambiente integrato, c'� Eclipse
Certo, consigliare di usare Eclipse ad uno che trova pesante persino
VS.NET
 non � proprio il massimo :)

 
VS.NET
 non è proprio il massimo :)
Si, hai ragione.
Avevo interpretato "pesante" nel senso di bytes da installare sul 
sistema; in questo caso 
VS.NET
 è pesante perchè si porta dietro anche 
tutto il runtime di .NET, se ricordo bene dall'ultima volta che l'ho 
installato.
Ciao  Manlio

tutto il runtime di .NET
Il runtime di .NET serve a tutte le applicazioni che girano per questa
piattaforma, non � propriamente qualcosa che "si porta dietro" 
VS.NET
.
E' un runtime come ce ne possono essere tanti. Tra parentesi, molti
detrattori di .NET sono accecati dall'"antimicrosoftismo", non
giudicano obiettivamente. A me .NET d� idea di leggerezza, non di
pesantezza, ma lungi da me aprire una guerra di religione (ognuno usi
ci� che pi� lo aggrada). Dal mio punto di vista, piuttosto che avere
10 eseguibili che si portano dentro parte della libreria distribuita
col compilatore, preferisco avere 1 copia della libreria e 10
applicazioni pi� leggere. Poi, io uso 
VS.NET
 tutti i giorni e mi
sembra un ambiente veramente leggero, veloce e facile da usare.
Giudico negativamente Eclipse perch� lo uso tutti i giorni sviluppando
in Java e non ho mai visto qualcosa nulla di pi� pesante. Colleghi mi
dicono che NetBeans non � da meno (purtroppo il mondo Java � pieno di
"dinosauri" lenti e pesanti).

 
VS.NET
 non � proprio il massimo :)
Io su Java godo molto Idea. 
-- 
-riko

Io su Java godo molto Idea. 
L'ho usato ed � veramente un ottimo ambiente. Purtroppo in quanto a
"pesantezza" non � da meno di Eclipse, a mio parere (almeno sotto
Windows). Per tutto il resto l'ho trovato molto intuitivo e pi�
usabile di Eclipse.

 libreria distribuita col compilatore,
Questo che scenario è, cioè quando succede?

 Questo che scenario è, cioè quando succede?
Succede tutte le volte che compili del codice sorgente in C o C++ o Delphi
o qualunque altro linguaggio d'alto livello cosiddetto "compilato" (bench�
sia opinabile chiamare "compilato" un linguaggio), a meno di imporre, in
dipendenza dal s.o./compilatore, il link dinamico delle librerie. In quei
casi il codice della libreria � linkato al codice oggetto prodotto dal
compilatore e confluisce nell'eseguibile.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Questo che scenario è, cioè quando succede?
Credo si riferisca semplicemente al fatto che quando compili un programma 
che non necessita di alcun framework, evidentemente al suo interno avrà 
tutto ciò che gli serve per funzionare rendendolo più pesante. Questo accade 
per ogni programma compilato in tal modo. Con un framework invece le 
applicazioni possono "condividere" gli elementi in comune risultando più 
leggere.
Interpretazione corretta? :-) 

 usabile di Eclipse.
E JBuilder che fine ha fatto? La stessa di CodeGear? Embarcadero (societ� 
che l'ha acquisita) non se ne occupa? 

 compilatore e confluisce nell'eseguibile.
Ecco avevi gi� risposto ma ho letto dopo. 

 che l'ha acquisita) non se ne occupa?
I pasticci imprenditoriali attorno a Delphi & C. non finiscono. Prima il
passaggio a Inprise, poi il ritorno a Borland, poi da Borland a CodeGear,
poi CodeGear viene acquisita da Embarcadero. Chi sar� il prossimo?
JBuilder fa ancora parte della suite di prodotti di sviluppo, ma dubito
che siano molti ad usarlo.


 Questo che scenario �, cio� quando succede?
Per esempio ogni volta che usi un programma su OS X che si appoggia
implicitamente al runtime di Objective-C + Cocoa.
-- 
-riko

 dinamico delle librerie
Ma si parlava di .NET, è possibile eseguire link statico quando lo si 
usa?

 Ma si parlava di .NET
Stavo proprio dicendo che io preferisco l'approccio di .NET a quello pi�
classico usato dai compilatori.


 classico usato dai compilatori.
Sarà che non conosco l'approccio di .NET ma l'approccio più classico dei 
compilatori non è di usare dynamic linking?

 implicitamente al runtime di Objective-C + Cocoa.
-Base, vado alla deriva, mi sto perdendo…-
Se compilo un programma che si appoggia a Cocoa questo sarà di norma 
compilato _dinamicamente_ non staticamente, giusto? (qua dovresti 
rispondere "sì")
Il mio dubbio nasceva dal fatot che si parlava di .NET che è un 
framework esterno alle applicazioni e che istalli una volta sola e 
programmi che si portano appresso le librerie più volte (quindi linkati 
staticamente). Io immaginavo che dato che si usa un framework esterno 
all'applicazione ci fosse compilazione dinamica per questo ho chiesto 
quando potesse capitare.
Ho sbagliato a capire ed erano due contesti contrapposti, cioè lo 
scenario del collegato staticamente era opposto a quello in cui si usa 
.NET?

 compilatori non è di usare dynamic linking?
No. Per esempio in Delphi non � di sicuro l'opzione di default.


 Ho sbagliato a capire ed erano due contesti contrapposti
Esatto.


 quando potesse capitare.
Riformulo, magari ho capito male io. Una cosa come .Net (al di la del
giudizio di merito su .Net) non e' *assolutamente* il male. Avere un
framework condiviso di "alto livello" e' cosa e giusta.
Lo hai con .Net, lo hai con Java e lo hai con Python. E lo hai anche sul
99% delle applicazioni OS X, ovvero Cocoa.
Solo che uno quando usa Cocoa magari non ci pensa, perche' e'
*certamente* e di default installato con l'OS. Quando fa una cosa con
Java "sa" che deve aspettarsi che ci sia Java sull'host se no ciccia (ma
c'e' quasi sempre), idem con Python (solo che noi pythonisti non ce lo
aspettiamo e invece spesso forniamo anche eseguibili che includono i
pezzi di runtime che ci servono per chi non ha voglia di installare
Python a parte -- ovviamente su Windows, su OS X e su Linux e' ormai
assodato averlo di default).
Apparentemente c'e' chi pensa che quando la stessa cosa viene applicata
a .Net questo sia un male. Io penso che in questo secolo possiamo e
vogliamo delle macchine virtuali di buona qualita' con una class-library
ricca e ben fatta pronta su tutte le macchine, in modo da non doversi
tirare dietro librerie esterne anche per le favate.
Tra l'altro anche gli eseguibili C e C++ sono nel 98% dei casi linkati
dinamicamente ai loro runtime, che, guarda caso, devono essere presenti.
E tipicamente lo sono. Non e' molto lontano il tempo in cui la gente si
incavolava perche' il g++ su windows creava eseguibili immensi, *credo*
perche' gli buttava dentro un sacco di runtime staticamente.
-- 
-riko

 perche' gli buttava dentro un sacco di runtime staticamente.
Esatto. Il problema di poter dare in giro un solo eseguibile, che non
necessitasse di run-time, mi si � posto solo quando si � trattato di
piccole utility, fatte con Delphi, e tipicamente per "utonti" col q.i.
inferiore a quello di un opossum. Oggi come oggi, invece, potendo
aspettarsi che .NET sia installato sulle macchine Windows, non ci sono
problemi. Io constato solo che C#, rispetto ad altri sistemi, pu�
aumentare i tempi produttivi per chi sviluppa per Windows, perch� .NET
contiene veramente un mare di classi utilissime e questa �, almeno per me
e a prescindere da considerazioni "filosofiche", la cosa di gran lunga pi�
importante.


 No. Per esempio in Delphi non � di sicuro l'opzione di default.
Probabilmente dipende dall'ambiente. Suppongo che in Delphi sia la cosa
piu' sensata da fare.
Su OS X il default (anzi, di fatto l'unica opzione) e' il dynamic
linking. Nel mondo open source Linux/FreeBSD etc e' pure sostanzialmente
il default. Su solaris peggio ancora (fare roba statica mi risultava
essere un bel macello, magari adesso hanno migliorato).
Non sono un esperto di Windows, ma anche nel mondo Microsoft mi risulta
decisamente diffuso l'approccio, nel bene e nel male, a dll.
-- 
-riko

 inferiore a quello di un opossum. 
Ecco, quello che intendevo nell'altro post con "e' probabilmente la cosa
piu' sensata da fare".
Dunque trovi che C# + .Net sia piu' produttivo di Delphi?
-- 
-riko

 piu' sensata da fare.
Be', non necessariamente. E' semplicemente il default. Delphi in realt�
prevede la possibilit� di strutturare il codice in DLL, come qualsiasi
altri sistema di sviluppo per Windows, oppure di usare il formato 
proprietario BPL, a tutti gli effetti delle DLL, ma con qualcosa in pi�
che agevola e rende trasparente l'uso delle classi.


 Dunque trovi che C# + .Net sia piu' produttivo di Delphi?
S�. In realt� a mio parere non c'� pi� ragione per restare ancorati a
Delphi, per molti motivi diversi. Il suo prezzo � decisamente alto
rispetto a Visual Studio e questo � stato per molto tempo un grosso
ostacolo alla sua diffusione; l'ambiente � (ancora) pieno di bug; per
avere un supporto decente a Unicode si � dovuta aspettare la versione
2010; il linguaggio � un'evoluzione del Pascal, meno evoluto di C# e
odiato da molti per la prolissit� e la rigidit�; le sue sorti sono legate
al produttore, che tutte le volte si rivela molto meno solido di mamma MS:
prima era Borland, poi Inprise, poi di nuovo Borland, poi CodeGear, ora
Embarcadero; la natura stessa del prodotto varia in base alle decisioni
della casa madre: prima Delphi, poi Borland Developer Studio per Win32 e
NET, poi Delphi 2007 solo per Win32 e nel contempo Turbo Delphi, ora
Delphi 2010. Pasticci su pasticci. Per tacere dei vari obbrobri generati
da Borland negli anni, come Kylix e C++BuilderX, prodotti tanto vantati,
ma praticamente nati morti e scomparsi quasi subito. La Visual Component
Library distribuita con Delphi � poi strutturata male, secondo me, porta
dietro ancora bug e vincoli pesanti nella costruzione delle interfacce e
non � assolutamente comparabile con la ricchezza del framework di
Microsoft. Io mi rendo conto che, le stesse applicazioni che avrei scritto
in Delphi, riesco a scriverle in C# in met� del tempo ed in maniera molto
pi� facile. L'ambiente, poi, ha un debugger fatto molto bene (e questo �
sempre stato un punto di forza dei sistemi MS). Non � da dimenticare, poi,
che C# e la CLI hanno comunque uno standard e sono quindi teoricamente
portabili (v. Mono).


 portabili (v. Mono)
Io su questo non spingerei troppo. Il "core" e' portabile, non so quanto
delle cose belle e comode che Microsoft offre ai suoi sviluppatori siano
portate anche su Mono.
-- 
-riko

 portate anche su Mono.
Infatti quel "teoricamente" vuole dire pi� di quanto sembri ;-) 

portate anche su Mono.
Be', ma tieni presente che si tratta pur sempre di Microsoft, da
sempre allergica agli standard :) Gi� il fatto che il core sia
portabile � una gran cosa, a mio parere, perch� tutta l'infrastruttura
e il linguaggio C# sono trasportabili (d'altronde Mono � nato per
questo). Non so a che punto sia Mono adesso, l'ho conosciuto in uno
stato embrionale che non prometteva molto bene, l'ho ritrovato in uno
stato avanzato tempo fa che invece lasciava molto ben sperare e ora
come ora non so a che livello sia. Spero siano riusciti a sviluppare
uno strumento utilizzabile anche sotto Linux, perch� per adesso sono
costretto ad usare Java per certi contesti cross-platform e Java, ad
uno come me, lo si pu� far usare solo con un coltello alla gola :)

 usabile di Eclipse.
Probabile che tu abbia ragione. Qua sotto dopotutto ho un MacPro.
-- 
-riko