Un linguaggio non è multipiattaforma soltanto perché utilizza una VM
22 ott2008
L'altro giorno, mentre giravo come mio solito tra forum e blog, mi sono imbattuto nella solita discussione informatica tra "opposte fazioni". Questa volta le fazioni in campo erano quelle degli sviluppatori .NET e degli sviluppatori Java, purtroppo non ricordo il sito internet in cui ho letto la discussione, altrimenti ve lo linkerei, tuttavia molti di voi avranno già chiara l'idea del tipo di discussione in cui mi sono imbattuto.
Riassumendo il discorso girava su tre questioni principali:
1) .NET è una copia spudorata di JAVA;
2) .NET è software proprietario, JAVA è software libero;
3) Java è migliore per sviluppare software multipiattaforma;
.NET è una copia spudorata di JAVA
La prima questione ricorda molto il chiasso generato dal video di David Pogue sulle differenze tra l'interfaccia grafica di OSX e Vista. Io non credo che David Pogue si fosse preso tanto sul serio durante la realizzazione di quel video, tant'è che l'intero filmato ha un'impostazione ilare, canzonatoria si, ma divertente e non troppo seria. Io ad esempio avevo pubblicato quel video come pretesto per discutere il mio punto di vista sulle interfacce grafiche, punto di vista che tra l'altro ho approfondito meglio proprio l'altro giorno con un articolo su Kde 4.1. Eppure quel video è stato preso molto sul serio da altri utenti del web e David Pogue è diventato, a seconda dei casi, un fazioso utente MAC o un dispensatore di verità assolute.
Ora, io che sono un avversore dei Brevetti Software perché trovo assurdo che si possano brevettare cose come un bottone che svolge una determinata funzione su un sito internet o il concetto stesso di negozio online; io che sono convinto del fatto che sia impossibile stabilire se sia nato prima l'uovo o la gallina e che ritengo gli algoritmi informatici un bene di tutti, come le formule matematiche, come potrei mai sostenere teorie balzane su chi abbia inventato prima i widgets (o gadgets o plasmoidi)?
Allo stesso modo accapigliarsi su quale linguaggio abbia copiato l'altro equivale, a mio modesto avviso, ad accapigliarsi per stabilire la paternità dell'algoritmo bubble sort. Eppure per molti queste battaglie "morali" hanno un senso.
.NET è software proprietario, JAVA no
In realtà già confrontare .NET con JAVA è un errore. dotNet infatti è un framework, quindi semmai andrebbe confrontato con NetBeans o Struts. Tra l'altro .NET supporta molti linguaggi, anche se non saprei dirvi "come" in quanto non ho mai sviluppato con tale piattaforma. Lo stesso errore viene fatto anche in altre diatribe, quella che ad esempio mette a confronto PHP con RAILS. Detto questo quindi il confronto si dovrebbe fare sui linguaggi di programmazione, nello specifico C# e JAVA. Su questo sarei quasi concorde con i sostenitori di JAVA, che però è diventato software libero praticamente l'altro ieri, però esistono compilatori open source per C# (Mono, DotGnu), lo standard de facto è Visual C#, che è proprietario e funziona solo su piattaforma Microsoft, ma gli standard vengono scelti dagli utenti (in questo caso gli sviluppatori), che quindi devono prendersi necessariamente la loro parte di colpe. Tuttavia non si può trascurare il fatto che è possibile sviluppare software libero (ed anche proprietario) utilizzando implementazioni libere di compilatori C#, che, lo ricordo, è uno standard ISO.
Java è migliore per sviluppare software multipiattaforma
Questa è la parte più interessante di tutta la discussione, forse il motivo principale che mi ha spinto a scrivere questo pezzo. Lo sviluppo multipiattaforma va di moda e per molti l'uovo di colombo dello sviluppo multipiattaforma sono proprio i linguaggi interpretati, come appunto Java, C#, ma anche Python o Ruby. Colpa di Java in principal modo, linguaggio che per primo ha pubblicizzato ampliamente la sua natura "multi device", colpa anche del mercato che ormai (per fortuna) richiede sempre maggiore interoperabilità tra i sistemi operativi.
In realtà il parallelo secondo cui i linguaggi interpretati sono intrinsecamente e "naturalmente" multipiattaforma è una fantasmagorica fesseria. La programmazione multipiattaforma richiede particolari attenzioni ed accortezze che poco hanno a che fare con il tipo di linguaggio utilizzato, questo è vero sia per i linguaggi compilati che per i linguaggi interpretati. Anche quando si sviluppa lato server, ad esempio con PHP, spesso bisogna avere accortezze per accertarsi che il nostro programma funzioni sia su server Windows che su server Gnu/Linux o BSD, figurarsi quando si sviluppa un'applicazione desktop che magari si appoggia largamente su librerie esterne e fa uso di chiamate di sistema, che in quanto tali variano a seconda del kernel e delle API del sistema operativo!
Anche se esistono versioni multipiattaforma di interpreti del vostro linguaggio preferito ciò non vuol dire necessariamente che scrivere un software multipiattaforma sia un gioco da ragazzi, anzi, le difficoltà cresceranno man mano che crescerà la complicazione del software che state sviluppando. Se scrivete un programma senza valutare attentamente le librerie che userete ed il metodo d'approccio alle chiamate di sistema state sicuri che il vostro software sarà tutt'altro che multpiattaforma.
Visto che le complicazioni sono quasi le stesse con tutti i linguaggi (con differenze minime derivanti più dalle librerie a disposizione che non dal linguaggio stesso in quanto tale) ecco quindi che il vantaggio dei linguaggi interpretati rispetto al C++ è soltanto, ed in teoria, la maggiore velocità e semplicità di sviluppo dell'applicazione rispetto al linguaggio compilato per eccellenza. Ma tale punto a favore svanisce letteralmente quando in gioco entrano le prestazioni.
Ci sarà un motivo se la maggior parte delle applicazioni che utilizzate nei vostri computer sono sviluppate in C e C++ e non in .NET e Java. Ditemi, quanti di voi utilizzano Azureus (ora Vuze) o Deluge , e quanti invece hanno abbandonato questi client in favore dei più leggeri Transmission e Utorrent? Quanti utilizzano Banshee invece di Rhythmbox o Amarok? Perché Office, OpenOffice, Gimp, Photoshop, Firefox sono scritti con linguaggi compilati? Perché il progetto Looking Glass è rimasto sempre un proof of concept mentre Compiz furoreggia ormai da un po' sulle linux box di molti amanti del pinguino?
Pensare di creare sistemi desktop pesantemente basati su linguaggi interpretati come Java e C# è una follia, eppure è una follia che molti appoggiano. Va bene che i computer oggi hanno potenze spropositate ma se devo comprare un quad core solo per avere velocità e funzionalità pari ad un misero Athlon XP a questo punto dov'è il vantaggio? La mia conclusione quindi é: volete sviluppare programmi multipiattaforma davvero concorrenziali? Usate C++ e C. Sviluppate programmi più semplici e specialistici per i piccoli e medi uffici? Se potete utilizzate lo stesso C++, sarete sempre più avanti rispetto ai vostri concorrenti, anche se avrete qualche difficoltà in più in fase di sviluppo. Ove non siano necessarie funzionalità avanzate sviluppate applicazioni web based con un server centralizzato, il deployment sarà decisamente più semplice. Nel caso di sviluppo di applicazioni web based la scelta del linguaggio sarà decisamente basata su altri canoni, (così come le scelte variano a seconda del tipo di device che si intende programmare) ma di questo magari parleremo in un'altra occasione.
Leggi anche:
- LogFaq: Linguaggio Clone di Visual Basic
- Nokia: perché Linux si Diffonda sui Cellulari gli Sviluppatori Open Source Devono Adattarsi al Business.... dei Drm
- Firefox 3 beta 5 su Ubuntu 8.04, una scelta discutibile
- Perché la console è insostituibile. Un esempio lampante.
- Linux Day 2007 - perché non raccogliere e conservare la presentazioni?
(Gli utenti ritengono che questo articolo valga +1, hanno votato 1 utenti)
Loading ...Articoli correlati
Warning: Cannot use a scalar value as an array in /home/doxaliber/webapps/doxaliber/wp-content/plugins/yet-another-related-posts-plugin/related-functions.php on line 34
Articolo scritto da Doxaliber per Doxaliber, vuoi partecipare anche tu?
Se questo articolo ti è piaciuto aiutami a diffonderlo.
Segnalalo sul tuo blog, invialo agli amici, segnalalo sugli aggregatori di news.
Se vuoi seguire Doxaliber con maggiore tranquillità iscriviti ai feed, trovi i link in alto a destra.
Intanto questo blog ha già:
senza contare i lettori dei feed per categorie e gli abbonati alla newsletter!
33 Risposte to “Un linguaggio non è multipiattaforma soltanto perché utilizza una VM”
Rispondi
Doxaliber, blog di Salvatore Ingrosso, è distribuito con licenza Creative Commons. - Collegati -
Questo blog usa wordpress | Tema Evidens [White] realizzato da Design Disease per PremiumThemes.com, modificato, riadattato e tradotto da Doxaliber
"La mia conclusione quindi é: volete sviluppare programmi multipiattaforma davvero concorrenziali? Usate C++ e C. Sviluppate programmi più semplici e specialistici per i piccoli e medi uffici? Se potete utilizzate lo stesso C++, sarete sempre più avanti rispetto ai vostri concorrenti, anche se avrete qualche difficoltà in più in fase di sviluppo."
Scusami tanto, ma su che base fai questa affermazione ?
Lavori come sviluppatore o qualcosa di simile ?
Mai sentito parlare di RAD CASE per lo sviluppo rapido di applicazioni gestionali ?
Facciamo così ... ci presentiamo da un cliente e ci facciamo lasciare le specifiche software di un gestionale !
Te lo sviluppi in C++ e fai una stima del tempo di sviluppo (ed ovviamente dei costi).
Io lo faccio a modo mio e presento la stima del tempo di sviluppo (ed ovviamente del costo) che come minimo è la metà del tuo !!!
Poi lasciamo la scelta al cliente ! ;D
Capisci che tra il dire e il fare c'è di mezzo E IL ?
Ti piace questo commento?
1 
0
Premesso che per quanto ami (tantissimo) il C++ neppure io mi sento di escludere altri linguaggi per lo sviluppo multipiattaforma, tuttavia non ci sono solo gestionali, per i quali c'è una base di conoscente e tecniche sostanzialmente esaurienti. In altri ambiti con i RAD CASE non ci fai nulla... poi personalmente mi fido poco di questi strumenti, se devi fare qualcosa che esce un poco dagli schemi devi mettere mano al codice e il codice generato automaticamente spesso è poco chiaro.
Sul resto dell'articolo comunque non credo ci siano falle di ragionamento: lo sviluppo di applicazioni multipiattaforma non è cosa che risolvi semplicemente scegliendo java, .net e neppure C++... il linguaggio/framework è un buon 80% ma poi molte cose dipendono dallo sviluppatore.
Ti piace questo commento?
0 
1
Sul resto dell'articolo comunque non credo ci siano falle di ragionamento: lo sviluppo di applicazioni multipiattaforma non è cosa che risolvi semplicemente scegliendo java, .net e neppure C++... il linguaggio/framework è un buon 80% ma poi molte cose dipendono dallo sviluppatore.
Il senso dell'articolo era proprio questo, grazie per averlo colto. In qualche altro, ora non ricordo più perché è passato molto tempo, affrontavo la questione relativa alla scelta del linguaggio di programmazione, spiegando come a mio parere non esista un linguaggio adatto a tutto ma sia dovere dello sviluppatore scegliere il linguaggio in base alle necessità.
Ti piace questo commento?
1 
0
Mmm... Doxaliber, non sono d'accordo con quello che dici.
Sono d'accordo che C# abbia preso spunto da Java, ma allora a questa stregua, anche Java ha "copiato" da C e C++... è il gatto che si morde la coda.
C# ha MIGLIORATO quello che è Java, aggiungendo numerose funzionalità non presente sulla VM di Java. Se poi voglia parlare di prestazioni.... JAVA è UN CHIODO! E' lentissimo. Mi è capitato di dover sviluppare applicazioni utilizzando Java e ho avuto non poche frustrazioni...
Per quanto riguarda l'essere o meno proprietario, come giustamente dicevi tu, C# è uno standard ISO, quindi NESSUNO (nemmeno Microsoft), lo può cambiare a suo piacimento... Poco importa se il framework base è open o closed source.
Se proprio proprio vogliamo avere anche il framework aperto, basta fare come faccio io, che utilizzo esclusivamente MONO... problema risolto.
Ti piace questo commento?
0 
1
Mah, guarda, anche secondo me Java è lento, era così quando sviluppavo in java circa secoli fa (sdk 1.4, quindi un secolo fa circa..
), però alcuni amici che sviluppano per tale piattaforma e che sviluppano applicazioni anche di un certa complessità (banche e uffici pubblici) mi dicono che la velocità è decisamente migliorata e che (ma questo è un fatto più scontato) le prestazioni dipendono moltissimo dalla capacità o meno dello sviluppatore di ottimizzare il codice. A tal proposito mi hanno fatto vedere un paio di applicazioni che andavano piuttosto bene.
Su chi copia io ho scritto esattamente ciò che dici tu, se stiamo dietro a queste cose è appunto... un cane che si morde la coda, perché ogni linguaggio di programmazione si è in qualche modo ispirato ad un altro linguaggio. Credevo di essere stato chiaro nell'esprimere il mio punto di vista..
Sulle migliori qualità di C#, come ho anche scritto nel pezzo, non saprei esprimermi giacché non ho mai sviluppato software in C#. Se vuoi illustrarmele, magari anche scrivendo un apposito articolo utile a tutti gli interessati, sarò ben lieto di leggere cose interessanti.
Ti piace questo commento?
0 
1
con .net per la prima volta microsoft ha esposto tutte le funzionalità del sistema operativo in maniera coerente, puramente ad oggetti ed in maniera indipendente dal linguaggio, detto questo... il C++ può essere una buona alternativa se usato con librerie come qt che possono rendere più semplice lo sviluppo grazie a classi wrapper che astraggono dalla piattaforma sottostante funzionalità ormai necessarie e date per scontate come accesso alla rete, ai file, thread, opengl, inoltre permettono una gestione semi automatica della memoria in quanto le classi widget si occupano di distruggere i child ergo quando una window viene rimossa dalla memoria anche i widget in essa contenuti vengono deallocati, questo rende la scrittura dei metodi distruttori abbastanza agevole, inoltre ci sono classi per la gestione delle stringhe write on copy realizzate in modo da poter essere allocate sullo stack come i tipi nativi e classi container equivalenti alle stl ma con iteratori java like. Questo per spezzare una lancia a favore di c++ e qt.
Per chi ama altri tipi di linguaggi: RealBasic e FreePascal secondo me sono una giusta evoluzione di visual basic e delphi in maniera cross platform.
Per il resto si possono sviluppare applicazioni desktop anche in php e gtk o ruby e qt o python e wxwidgets e D e DFL o qualsiasi cosa uno sviluppatore decida sia necessario o utile per il progetto su cui sta lavorando, se il cliente non pone specifici vincoli.
Da tenere d'occhio secondo me anche Adobe Air che permette di fare cose carine anche in ambiente desktop inoltre l'sdk è sotto licenza opensource.
L'ultima considerazione da fare è che ognuno utilizzi quello che ritiene migliore per il proprio lavoro. Ci sono ottime applicazioni scritte in java e ottime applicazioni scritte in .net alla fine il linguaggio e il framework sono solo strumenti mentre la preparazione e la competenza del programmatore dovrebbero fare la differenza.
Ti piace questo commento?
1 
0
Infatti, ciò che è sfuggito all'autore del primo commento è che RAD non sta altro che per Rapid Application Development e che gli strumenti RAD esistono anche per linguaggi come il C++.
Sulla scelta del linguaggio io invece credo che esso dipenda in parte dalle esigenze del cliente, che comunque raramente pone specifiche così dettagliate e molto dal tipo di applicazione che si deve sviluppare. Credo che ogni linguaggio abbia le sue peculiarità ed anche se tutti tendono ormai ad essere "general purpose" questo è vero solo in parte.
Ti piace questo commento?
0 
0
Personalmente sviluppo in .NET (C# in particolare) da quando è uscito, e mi occupo di sviluppo di software gestionali personalizzati (per broker e compagnie assicurative). I tempi sono più che buoni, anche comparati a quelli dell'ultima versione disponibile della VM Java.
Sono d'accordo con te che le prestazioni dipendono molto dalle capacità dello sviluppatore di ottimizzare il codice, ma questo vale anche (e forse, soprattutto) con C e C++, che sono più di basso livello
Ti piace questo commento?
0 
0
Le performance dipendono molto dalla capacità del programmatore, dalla sua conoscenza degli algoritmi e dalla sua conoscenza e utilizzo di librerie matematiche adeguate. Sia .net che java utilizzano un compilatore just in time che compila il bytecode in una versione ottimizzata per il processore sottostante quindi potrebbero verificarsi casi in cui, a parte l'overhead iniziale del loader si potrebbe avere software in java o .net che hanno performance uguali o superiori a quelli di un generico eseguibile c++ magari compilato i386 e poi eseguito su un AMD 64, magari è un sempio stupido ma rende bene l'idea.
Secondo me ad oggi netbeans con gui builder, eclipse con il designer swt/swing, xcode, borland delphi e visual studio 2008 sono lo stato dell'arte per quanto riguarda gli ide, un gradino sotto ci sono code::blocks oppure kdevelop con i qt designer (ma anche eclipse con il plugin ufficiale di nokia per qt), realbasic, flexbuilder (consideriamo solo la parte air in quanto parliamo di applicazioni desktop) intellij, sharpdevelop, (monodevelop secondo me è ancora immaturo per essere usato con profitto).
Viene da se che ad oggi non esiste un linguaggio che abbia tutte le caratteristiche che lo renderebbero un canditato ideale per lo sviluppo desktop che secondo me dovrebbe essere:
* compilato nativamente in maniera statica senza bisogno di 6 gb di dll, della serie l'utente scarica solo un file ci clicca sopra e buona notte
* cross platform
* gestione automatica della memoria
* gestione dei tipi custom come dei tipi nativi
* completamente ad oggetti
* widget mappati sui widget nativi del sistema ed emulare i widget avanzati mancanti ma con temi nativi
* sintassi C like
* libreria ad oggetti per rete, thread, zip
* almeno un componente per il rendering dell'html basato su webkit.
Si vede bene che non esiste... poi ognuno fa i propri compromessi rispetto alle esigenze del cliente e alle volte esce java, alla volte .net alle volte realbasic... alle volte VB 5
Ti piace questo commento?
0 
0
Mah, secondo me sul software gestionale l'ottimizzazione è importante ma offre un contributo minimo alla velocizzazione del programma, alla fine si tratta di inserimento dati, visualizzazione, stampa. Fatte le dovute eccezioni naturalmente. In questi casi un ruolo importante, soprattutto in vista di future manutenzioni, ce l'ha la documentazione, un codice ben ordinato, pulito, chiaro ed infine una struttura non troppo rigida che consenta modifiche e cambiamenti senza troppi sbattimenti.
Il mio discorso si basava soprattutto sulle applicazioni desktop multimediali o del sistema operativo in sé, non a caso ho citato OpenOffice, Firefox, Amarok, k3b in questi casi, ottimizzazione o non ottimizzazione, un programma sviluppato in C o C++ da' la birra a qualsiasi software realizzato con linguaggi interpretati. L'overhead non è solo nell'avvio, ma in generale nell'uso dell'applicativo. Il fatto stesso di utilizzare un compilatore "just in time" aggiunge un livello di complicazione nell'esecuzione del codice, complicazione che ovviamente ricade interamente sulla CPU e che quindi degrada le prestazioni. Questo ovviamente è meno vero con le CPU di nuova generazione ma rimane pur sempre vero. Non è un caso infatti se le applicazioni desktop di maggiore successo sono scritte tutte in C o C++ (ed ho fatto esempi nell'articolo).
Naturalmente questo è meno vero nello sviluppo di software gestionale, qui le necessità sono diverse: trovare programmatori Java o .Net è decisamente più semplice che trovare programmatori C++ validi, i tempi di sviluppo con Java e .Net tendono a diminuire, il codice è più leggibile e più facilmente manutenibile, etc. etc.
Ti piace questo commento?
0 
0
Fermo restando che sono d'accordo sul resto. Il linguaggio perfetto non esiste e probabilmente mai esisterà.
Ti piace questo commento?
0 
0
si di fatti avevo citato le qt proprio pechè tutto kde e amarock ad esempio dipendono da questo interessante framework che rende lo sviluppo di applicazioni c++ un pò più semplice, i tempi di sviluppo con java o .net saranno sempre minori a meno che non ti tocchi ad esempio integrare java con una libreria c nativa
openoffice utilizza java per alcune funzioni, dalla wiki di openoffice:
Java is required for complete OpenOffice.org functionality. Java is mainly required to use the new embedded Java technology based HSQLDB database engine, or to make use of accessibility and assistive technologies. If you do not require database tables or accessibility integration or some wizards, then you do not need to download and install Java. Base (the database component) for example completely relies on Java technologies to run, but other programs (like Writer, Calc, and Impress) only need Java for special functionality (see below).
For the policy for Java use in OpenOffice.org, please see
Policy for the usage of Java in the OpenOffice.org project
OpenOffice.org Base
Create Form Wizard
OpenOffice.org Writer
Letter Wizard
Fax Wizard
Agenda Wizard
HTML Wizard
SaveAs -> AportisDoc (Palm)
SaveAs -> DocBook
SaveAs -> Pocket Word (*.psw)
OpenOffice.org Calc
SaveAs -> Pocket Excel
All
OOoBean
JavaScript Macros
Beanshell Macros
Python
sono funzionalità a cui si rinuncia tranquillamente comunque.
Tanto per la cronaca applicazioni molto carine e molto veloci ci sono sia in .net che in java, ad esempio paint.net (http://www.getpaint.net/) per .net e art of illusion (scritto in java, bellissimo, http://www.artofillusion.org/) ergo l'abilità del programmatore conta il linguaggio è uno strumento e dovrebbe essere preso come tale, senza fanatismi secondo me il linguaggio è legato al problema, vedrei poco bene un software come audacity (scritto in c++ e wxwidgets) scritto in visual basic ma altrettanto mi sembrerebbe superfluo come dici bene tu sviluppare un gestionale in C++. comunque concordo sia sull'articolo che sui commenti successivi.
Ti piace questo commento?
0 
0
Vedo tantissime imprecisioni in questo articolo, di ordine tecnico. Java non è ne interpretato ne compilato. E' un linguaggio di natura intermedia perchè il compilatore genera bytecode, già controllato semanticamente sintatticamente e ottimizzato. Il bytecode può essere interpretato con una jvm o compilato dinamicamente con una JIT. Da molti anni, ben prima che MS lanciasse .NET, SUN aveva già rilasciato il suo JIT per tutte le piattaforme tranne IA64. Oggi solo su IA64 il bytecode viene interpretato da una JVM. Le prestazioni da quando è stato introdotta la JIT sono molto elevate è dire che java è lento vuol dire non conoscerlo. .NET non è mutipiattaforma, mono non è .NET, non da nessuna garanzia di compatibilità e non è certificato da nessuno per esserlo. Mono è sempre indietro di diverse versioni rispetto a .NET e non assicura neanche la compatibilità piena del framework 1.0. Qualcuno mi da il link di .NET per Linux?
Diversamente Java è nato per essere multipiattaforma, è rilasciato per tutte le piattaforme da SUN, è certificato e garantito ; Inoltre SUN ha da sempre rilasciato le specifiche del linguaggio e chiunque puo implementarlo; ma ogni implementazione per essere chiamata Java deve passare migliaia di test di correttezza e di compatibilità. Infatti implementazioni di java certificate ma non SUN ve ne sono diverse : IBM, BEA, OpenJDK. Le specifiche sono pubbliche da sempre, ma il codice sorgente è disponibile da quasi 10 anni, Inoltre java è licenziato GPL da quasi 2 anni. (OpenJDK). Chi ha copiato, l'uno o l'altro? Java c'è dal 1992, .NET dal 2002 ....fate voi!!
Non è neache vero che la piattaforma Java non è multilinguaggio: groovy, BeanShell, JRuby, Jython, E ....
Ti piace questo commento?
3 
0
Redshift, i linguaggi che vengono compilati in formato bytecode vengono definiti linguaggi interpretati, quindi non c'è nessun errore tecnico. Errore tecnico è invece definire .NET un linguaggio in quanto .NET è un framework (l'ho anche scritto nel pezzo) che supporta tra l'altro svariati linguaggi anche se nativamente nasce coon Vb.net e C#. Mono e DotGnu sono compilatori C# perfettamente conformi allo standard. Vero è che Mono è carente nel supporto a WinForms ma, come ho scritto nell'articolo, il programma multipiattaforma lo fa il programmatore non il linguaggio. Nello specifico basta utilizzare le librerie GTK (e credo esista il porting anche delle QT) e fare attenzione a come si sviluppa. Se proprio vogliamo dirla tutta c# è formato ISO, Java no (anche se è uno standard de facto). Java è diventato open source nel 2006 ed il primo sorgente si è visto nel 2007.
Sulla velocità ho scritto più su, molti mi dicono che java è diventato più veloce rispetto a quando lo usavo io (fino alla sdk 1.4, quindi secoli fa), tuttavia qualsiasi linguaggio interpretato (intendendo come interpretato qualsiasi linguaggio NON compilato) avrà sempre un handicap prestazionale rispetto ad un programma compilato, è insito nella struttura.
Ti piace questo commento?
0 
0
Non ho mai definito .NET un linguaggio.
Se leggi in fondo, distinguo tra piattaforma java (J2SE , JEE ) e linguaggio java.
Che Mono abbia un compilatore C# conforme allo standard, non significa che renda il software prodotto con Mono eseguibile in un framework .NET . Lo è forse, solo ad alcune condizioni ben precise e rinuiciando ad altre funzionalità.
Ma comunque nessuno me lo garantisce, ne un ente terzo ne la MS ne una siute di test omogenei.
Se tu sviluppi un software in java usando le classi della JDK gira su tutti gli OS in cui è supportata quella versione di java.
Se fosse come dici tu avrei detto che java è libero da 4 anni in quanto esiste la GCJ e ClassPath. Ma GCJ e ClassPath non sono java esattamente come Mono non è .NET
Sei tu che definisci i linguaggi bytecode interpretati. Ma se possono sorgere dubbi su questo, ad oggi nessuna classe java viene eseguita da un Vrtual Machine. Il byte code viene compilato e il codice oggetto viene eseguito sulla macchina NATIVA e non su una VM.
Questa tecnica si chiama compilazione dinamica.
Un esempio tipico sono le servlet lente solo alla prima chiamata, poi la classe compilata e tutte le altre rimangono in memoria come fossero librerie dinamiche in codice nativo, esattamente come fossero delle QT. In realtà non è detto che un software compilato in maniera classica sia per forza più veloce di uno compilato dinamicamente. I compilatori dinamici ottimizzano il codice proprio alla cpu sottostante, comprese istruzioni estese, uso di registri, core multipli , hyperthreading ecc. Il più delle volte un software nativo è compilato per 686, se va male per 386, perdendo tutte le ottimizzazioni del caso.
Le applicazioni in java risultano penalizzate solo in fase di startup e solo se fanno un uso massivo e non corretto della GC.
Ma la funzionalità del GC è un valido aiuto che nulla ha che vedere sulla natura del software
La penalizzazione in ambito desktop era dovuta all'uso delle componenti grafiche non native, che per altro sono proprio uno degli aspetti più critici che rende incompatibile Mono con .NET.
In java non devi usare bindig a QT o a GTK sperando che tali librerie siano installate anche sugli altri sistemi, usi swing o awt che fanno parte dell'SDK.
Ad oggi già con la 5 ma ancora di più con la 1.6.10 java usa molte ottimizzazioni delle DirectX o OpenGL (se le trova) dell'ambiente sottostante riuscendo a ottenere buone prestazioni.
In ambito server le applicazioni Java sono molto performanti, ma nel calcolo numerico le prestazioni di java rivaleggiano con quelle del C++ proprio perchè fanno poco uso della GC.
Per quanto riguarda il codice sorgente, nel 2007 è stato publicato il codice del compilatore JIT (javac) e della jvm sotto licenza GPL2 ma il codice di tutte le classi della JRE era presente, scaricabile e consultabile da 9 anni sotto altra licenza. (per altro certificata OSI)
Intendere interpretato qualsiasi linguaggio non compilato
"intendendo come interpretato qualsiasi linguaggio NON compilato"
rende la tua affermazione non confutabile per definizione, perchè un software compilato dinamicamente non è compilato e quindi nell'ambito della tua definizione diventa interpretato, pur non essendolo affatto.
Mi sembri un po di parte...un cincinino almeno
Ti piace questo commento?
1 
0
Mah, essere di parte per un linguaggio che non utilizzo mi sembra un po' difficile.
Puoi girarla come vuoi ma i linguaggi compilati sono sempre, sempre, più veloci dei linguaggi interpretati. Tu stesso alla fine scrivi:
Anche per usare programmi Java dev'essere installata la Jre, se non è installata non funziona niente.
Anche .NET e Python sono compilati in byte code, quindi non v'è alcuna differenza tecnica tra JAVA e .NET o Python in questo senso. Il discorso, qualora ti fosse sfuggito, è tra linguaggi "interpretati" (senza tante distinzioni tecniche) VS linguaggi compilati, non JAVA vs .NET. La questione è che tali linguaggi vanno bene per alcune cose ma non possono diventare linguaggi adatti a tutto come ad esempio vorrebbero quelli di Novell (per Mono), Microsoft (per Net) o Sun (per Java). Vuoi scrivere un gestionale, sviluppare un'applicazione web, nel caso di java sviluppare un applicazione per smartphone o altri dispositivi embedded? Questo tipo di linguaggi sono la scelta giusta. Vuoi sviluppare software multimediali o che richiedono ampio uso della CPU, la scelta è il C++.
Più su MichelangeloG ha ricordato che OpenOffice ha alcune parti in Java, nello specifico la parte GROSSA scritta in Java è quella relativa al database, guardacaso è anche la più lenta e pesante. Altri software che non sono concorrenziali rispetto ai corrispettivi scritti in linguaggi compilati sono nel testo dell'articolo, quindi non mi ripeto.
Ti piace questo commento?
0 
0
Io mi attenevo al titolo iniziale:
"Un linguaggio non è multipiattaforma soltanto perché utilizza una VM"
e hai tre punti sviluppati subito sotto :
"1) .NET è una copia spudorata di JAVA;
2) .NET è software proprietario, JAVA è software libero;
3) Java è migliore per sviluppare software multipiattaforma;"
Ho aggiunto che vi erano delle affermazioni di natura tecnica scorrette come ad esempio che java (o .NET )è interpretato, o che i linguaggi a compilazione dinamica sono più lenti in generale; Non ho nulla da eccepire sul fatto che .NET non sia interpretato, esattamente come java, ma io non confutavo l'ipotesi che "solo java è interpretato e .NET no"ma solo l'ipotesi che "java è interpretato"
Diversamente proprio perche .NET usa compilazione dinamica, stessa tecnologia applicata gia da anni prima dalla jdk, aiuta a dare una risposta al questito numero 1.
Per quanto riguarda python, non mi risulta che abbia un JIT, cioè un compilatore dinamico.
Parlando di prestazioni e delle affermazioni che java è lento e che comunque i linguaggi nativi sono più veloci in generale di quelli compilati dinamicamente
(anche .NET) ho qui dei test di qualche anno fa proprio relativi alla fantomatica jdk 1.4.2 confrontati con il compilatore G++ per c++ dell'epoca
http://kano.net/javabench/data
questa è la pagina di riferimento con tanto di codice aggionrnato al 2007
http://kano.net/javabench/index
Quindi è scorretto dire che i linguaggi nativi sono più veloci......
Per la risposta al 3 quesito, cioè per le caratteristiche multipiattaforma, mi sembra ovvio che per far girare java hai bisongo di java e per far girare Python hai bisogno almeno di python. Ma questo non c'entra nulla con una la portabilità delle applicazioni.
..non ancora mi hai dato il link per scaricare .NET per Linux:
io aspetto !
Tra tutti gli esempi .NET è proprio la piattaforma meno portabile...
Ti piace questo commento?
1 
0
Il primo punto:
L'ho già sviluppato nell'articolo e credo di aver espresso più che chiaramente il mio punto di vista. Se .Net è una copia spudorata di Java allora Java è una copia spudorata del C++ e di altri linguaggi che lo hanno preceduto.
A proposito parli di Java come framework o come linguaggio, perché una delle prime cose che ho scritto nel pezzo in merito al secondo punto è:
quanto scritto in queste poche righe palesa il fatto che, a mio parere, se un confronto deve essere fatto allora bisogna farlo tra C# e Java, ergo la tua ripetuta provocazione:
evidenzia a mio parere che se qualcuno di "parte" c'è tra noi quello sei tu. Se io parlo di pizza e tu continui a chiedermi dove stanno i fichi il discorso non ha alcun senso.
Anche qui, il concetto espresso nell'articolo è: un linguaggio non è multipiattaforma soltanto perché compilato dinamicamente o interpretato. Molto dipende dal tipo di software che si sta sviluppando, da quante e quali chiamate di sistema si fanno. Se bisogna avere accortezza nello sviluppo di applicazioni lato server con PHP, perché Apache e IIS gestiscono alcuni particolari in modo diverso e perché la gestione delle directory è diversa, figurarsi se non bisogna averle con applicazioin lato desktop. L'accortezza sta nell'utilizzo di librerie (anche grafiche) multpiattaforma e nell'attenzione del programmatore a non ragionare come se stesse sviluppando per una sola piattaforma.
C++ era multipiattaforma molto prima che Java nascesse, non a caso tutti i sistemi operativi sono sviluppati quasi integralmente in C e C++, quindi la storia secondo cui alcuni linguaggi sarebbero "multipiattaforma" per natura è semplicemente una fandonia.
Le tabelle prestazionali lasciano il tempo che trovano, ogni linguaggio ha i suoi pro ed i suoi contro, ma ciò che conta è comunque l'utilizzo reale e nella realtà la maggior parte delle applicazioni desktop multipiattaforma più utilizzate sono scritte in C e C++, non in Java o C#: Firefox, OpenOffice, uTorrent, emule, Rhythmbox, Amarok, Gimp. Sono scritte in quei linguaggi perché la differenza prestazionale è evidente, infatti chi sviluppa applicazioni concorrenti con altri linguaggi (vedi Banshee per i player) fatica a ritagliarsi uno spazio.
Le eccezioni sono poche, rare, pochissimo usate, poi ognuno utilizza il linguaggio che preferisce, sono scelte personali.
Io personalmente a Java e C# preferisco altri linguaggi, ma dipenderebbe comunque dal contesto.
PS:
Il compilatore Jit per Python è Psyco.
Ti piace questo commento?
0 
0
Ti ringrazio per l'info su Psyco.
Ho gia spiegato che per java intendo piattaforma java e non espressamente il linguaggio; si tende a usarlo assieme solo perchè pur non essendo una piattaforma monolinguaggio è usata nel 90% dei casi con il solo linguaggio java.
Ma il compilatore JIT macina anche byte code non solo classi.java .
Quindi il tuo appellarti a questa semplificazione come elemento esplicativo o fuorviante cade nel vuoto e non sposta le mie affermazioni di contenuto .
Il nome FrameWork lo da MS è non ha nessun risalto logico o riferimento a categorie come Ruby e Spring, perchè ha connotazione puramente commerciale. La MS poteva chiamare .NET acnhe Gino o Pino o Mario : ha deciso di chiamarlo framework e tu ci scrivi sopra un muccio di parole.
Ritornando al punto 1)
La stessa MS ha ammesso di aver copiato java cercando di migliorarlo, non è un mistero.
Non è un mistero che ci abbia provato anche in maniera subdola anni prima, creando J++, una versione che chiamava java che però non era compatibile con java e non poteva neanche chiamarsi tale, perdendo anche una causa milionaria con la Sun, con tanto di risarcimento danni.
Php, Python Ruby e Java vantano implementazioni ufficiali per i vari OS, con relativi limiti di portabilità più o meno evidenti.
Java secondo me a più portabile perchè si distingue dagli altri proprio perchè è stato pensato per essere portabile ed orientato alle applicazioni distribuite sin dall'inizio. Basta pensare alle applet o a web start ceh fuanzionano su qualisiasi OS , al caricamento remoto e runtime delle classi, e alla possibilità di gestire il class loader direttamente da codice; basta pensare alle centinaia di implementazioni di java per Cellulari e per smart card o all'invezione del protocollo RMI, nativo in tutte le VM java da 8 anni a questa parte.
Ma parlare di portabilità con .NET quando non ha nessuna implementazione ufficiale per altri OS all'infuori di Windows, mi sembra una forzatura.
Se questa cosa ti pare una provocazione, io ho detto e ripeto che puoi smentirla fornendomi il link di .NET per linux.
Diversamente, se puoi fornirmi i link relativi per le versioni ufficiali di Ruby , Python, Php e per Java ma non per .NET, un motivo ci sarà o no??
Molti dimenticano che implementare comportamenti grafici comuni, una semplice tray icon, o funzioni di basso livello come la gestione dei thread o le chiamate classiche bind socket select, read e write,
è una cosa molto complicata da fare su diversi OS in maniera standard ed uniforme.
Secondo me java c'è riuscito meglio di altri.
Altri come MS non si sono posti neanche il problema.
Se questa è una provocazione chiamala come ti pare.
Ti piace questo commento?
1 
0
? Forse ti sfugge il concetto di framework.
Ruby è un linguaggio, Rails è un framework, Java è un linguaggio, spring è un framework, PHP è un linguaggio, Symfony è un framework, C# è un linguaggio, .Net è un framework, Python è un linguaggio, Django è un framework.
Daje, insisti. Monodevelop.
Ti piace questo commento?
0 
0
Grazie! ho preso appunti, certe cose mi sfuggivano.
Mi sa che non leggi quello che ho scritto:
"Ho gia spiegato che per java intendo piattaforma java e non espressamente il linguaggio"
Ripeto che la notazione di framework per .NET è puramente commerciale .
Non vi è alcuna differenza tra il significato di un framework .NET e una JDK.
Solo che la parola framework è più figa.
Ho solo chiamato JDK come piattaforma java esattamente come la chiama SUN:" Java PlatForm" . So che ti disturba la presenza della parola java, che è anche il nome del linguaggio java, ma devi prendertela con Sun non con me.
Ma se ti piace arrovellarti sui nomi fai pure.
Poi però nn ti capisco quando mi presenti Monodevelop come framework ufficiale .NET per Linux??
(
Monodevelop sararebbe il framework ufficiale .NET per Linux ??
Leggo dal sito :
"MonoDevelop is a free GNOME IDE primarily designed for C# and other .NET languages"
E' un IDE, e poi non mi sembra ne fatto ne rilascito o certificato da MS.
Ecco cosa è e cosa fa in soldoni il tuo caro framework MS (Gino) reso dal sito MS.
"
The .NET Framework is an integral Windows component that supports building and running the next generation of applications and XML Web services. The .NET Framework is designed to fulfill the following objectives:
*
To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely.
*
To provide a code-execution environment that minimizes software deployment and versioning conflicts.
*
To provide a code-execution environment that promotes safe execution of code, including code created by an unknown or semi-trusted third party.
*
To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments.
*
To make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Web-based applications.
*
To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code. "
Nota " Windows component" e poi ...."such as Windows-based applications "
Mi spieghi xke continui a dire cose false e tendenziose se persino MS dice che
si tratta di componenti windows? no MacOX no Linux o Solaris no Mutiplatform componets, solo Windows-based applications!!
Mi dai una spiegazione dell'interesse che hai a dire queste cose?
Spiegacelo !!
Quello del framework .NET non è ne più ne meno di quello che mette a disponsizione una JDK:
componenti riusabili per diversi usi in vari contesti, libreria di classi , tool di sviluppo,
ambiente RunTime , servizi vari, documentazione ecc ecc
Quindi spiegami questa differenza qualitativa che c'è secondo te tra la definizione che la stessa MS da del suo framework e una JDK o Java PlatForm se ti piace di più.
Di solito quelli che tu chiami frame work non hanno mai le funzionalità di base o i vari runtime del caso, perchè si presume che i tool aggiuntivi e i componenti aggiuntivi del framework, siano appunto aggiuntivi.
Contrariamente, in quello MS c'è un po di tutto.
Ritornando a bomba .NET non è mutipiattaforma, non lo dico io lo dice MS.
Quando si parla di Java spesso si parla di Java Platform, quindi ha perfettamente senso confrontarla con .NET
Quando si dice chi ha copiato l'uno o l'altro, basta vedere la storia, chi ha dato luce a tecnologie innovative e chi dopo molto (anche dopo molte aule giudiziarie )è riuscito a copiarle.
Con questo vi saluto, vi ringrazio per avermi dato spazio.
Ti piace questo commento?
1 
0
Mi sembra che con te parlare arabo sarebbe più semplice. A me non frega niente di cosa intendi tu per Java, so benissimo che differenza c'è tra Java inteso come linguaggio e Java Jdk.
Ma io, come ho scritto più su - e francamente mi sono rotto le scatole di ripetere, quindi non lo scriverò di nuovo - ho scritto un articolo che parla di Java e C# come linguaggi, non di Java e .NET come framework.
La domanda è: si possono scrivere software multipiattaforma con C#?
Si, con monodevelop e DotGnu.
Tu continui a parlarmi di .NET e a chidermi un link a .NET per Linux (pizza e ficchi) ed allora spiegami perché dovrei continuare a discutere con uno che ha il prosciutto davanti agli occhi e l'ovatta nelle orecchie. Nel caso ti fosse sfuggito a me non fotte niente di stabilire quale linguaggio sia migliore, il senso dell'articolo ha poco a che fare con Java, C# e .NET, ma sei troppo preso dal fervore "religioso" per rendertente conto. Se vuoi ti cerco un link a qualche forum dove, per citare il pezzo, "potrai accapigliarti per stabilire la paternità dell’algoritmo bubble sort".
Ti piace questo commento?
0 
0
ma non sai neanche quello che scrivi secondo me, figurati se puoi permetterti di ragionarci sopra.
Hai scritto tu, iniziando un discorso con .NET è java al primo punto ora te nen esci con C#.
"Riassumendo il discorso girava su tre questioni principali:
1) .NET è una copia spudorata di JAVA;
2) .NET è software proprietario, JAVA è software libero;
3) Java è migliore per sviluppare software multipiattaforma;
"
Sei tu che dici che confrontare .net è java è un errore, senza capire che per java si intende java platform.
E quindi il confronto è possibile farlo.
Partendo da questo assunto sbagliato te ne sei venuto giu con un'insieme impressionante di cose inesatte e luoghi comuni che sarebbe meglio che ti dedicassi a scrivere altro, piuttosto che argomenti di natura tecnica.
Sei io sono al prosciutto davanti agli occhi te sei alla frutta, un po più in la dell'antipasto.....
Un po meno di presunzione e un po più di logica ed attenzione a quello che scrivi ti farebbero bene.
Ti piace questo commento?
0 
0
Ti senti offeso dal fatto che non riesci ad argomentare e quindi non trovi niente di meglio che darmi addosso?
Io è dall'articolo che sto parlando di C#, .NET lo hai tirato fuori tu. Se c'è qualcuno che sta facendo la figura dell'incompetente, nonché del fanatico, quello sei proprio tu. Lo dimostra il fatto che gli altri commentatori hanno capito benissimo il senso dell'articolo e tu no.
Sei anche ripetitivo e quindi mi hai stancato. Saluti bello.
Ti piace questo commento?
0 
0
Scusatemi, ragazzi, ma state un po' azzannandovi a vicenda per nulla. Io parlo come una persona che, a tempo perso, si diverte a fare dei programmi ma non è un esperto.
Nonostante ciò permettetemi di fare un attimo il punto della situazione.
I linguaggio C# è uno standard, ma allo stesso tempo è legato in maniera indissolubile al .NET framework, quindi legato al suo metodo di lavoro, così come il Java (inteso come linguaggio) è legato al suo modo di essere interpretato.
Che il .NET abbia copiato da Java, è possibile (così come il Java ha copiato dal C++). Personalmente il .NET non mi entusiasma, così come non mi entusiasma il C#, ma queste sono opinioni personali.
Dice giusto però redshift quando afferma che .NET non è (tecnicamente parlando) multipiattaforma. E questo percé le specifiche .NET sono proprietarie e chiuse, essendo in primo luogo un sistema di librerie specifiche windows.
La portabilità per Linux (che sottolineo non è garantita in TUTTE le distribuzioni linux) tramite mono (Monodevelop è solo la componente del compilatore, ma mono, come dice doxaliber, comprende anche le librerie dimamiche) è stata possibile grazie ad un accordo tra Novell e Microsoft, ed in ogni caso è molto lontana da una compatibilità piena allo standard inventato da Microsoft per Windows.
Quindi dire che il C# sia un linguaggio multipiattaforma è vero solo in parte, se si guarda a queste considerazioni pratiche.
Se si parla di programmazione multipiattaforma ha più senso di parlare di Java, di C, C++, Pascal e recentemente anche il Basic è entrato in questo mondo.
La differenza, e qui si torna al punto iniziale di doxaliber su cui io concordo, è il metodo di interpretazione.
C, C++ e Pascal sono linguaggi che compilano un eseguibile (o binario, se preferite) che è direttamente interpretato dal Sistema operativo. Indifferente se usa o meno librerie dinamiche, poiché anch'esse sono scritte in un codice eseguibile direttamente interpretabile dal Sistema Operativo di riferimento (anziché richiamare un'unica sorgente se ne richiama di più).
In questo caso si parla di multipiattaforma perché è possibile, a partire da un medesimo sorgente (o con qualche piccola modifica) compilare sotto varie piattaforme (con C, C++ utilizzando i compilatori gcc e g++. Con pascal utilizzando OpenPascal e l'IDE Lazarus)
Java invece genera un bytecode sempre uguale che viene interpretato a tempo di esecuzione. Senza perderci in sottigliezze inutili sul concetto di "interpretato", il codice binario non corrisponde ad un codice binario che viene letto direttamente dal sistema operativo e dalla macchina, ma viene eseguito tramite un apposito programma (Jre) che si occupa di gestire quel tipo di formato binario.
E qui torniamo al punto iniziale di Doxaliber. Questo doppio passaggio (il codice binario prodotto non viene gestito DIRETTAMENTE dalla macchina, ma viene tradotto in azioni da un programma separato) comporta un leggero rallentamento in termini di prestazioni (perché c'è un processo ulteriore di "decodifica" che si frappone) che, quando si devono affrontare determinate problematiche, rende non adatta tale strada per alcune particolari applicazioni.
Detto questo, un bravo programmatore sicuramente ha le sue preferenze e sa sfruttare al meglio i suoi strumenti. Non dubito che redshift possa riuscire a sfruttare al meglio il Java rendendo i propri programmi performanti.
In ogni caso si tratta di scelte personali, che dipendono dalle proprie conoscenze, dal proprio metodo di lavoro e, perché no, dal proprio gusto "estetico" (io preferisco l'abbinata C++/Qt ed eventualmente l'abbinata C++/Allegro).
Ti piace questo commento?
1 
0
Scusatemi, è possibile cancellare il mio commento precedente? non avevo notato che era una vecchia discussione. Scusatemi
Ti piace questo commento?
0 
0
Non vedo perché cancellarlo, è un commento che ho letto con interesse, chi se ne frega se la discussione è vecchia.
Ti piace questo commento?
0 
0
Vista la discussione che si è innescata sopra, mi permetto di citare e linkare un articolo di tenore decisamente più tecnico (orientato decisamente a sviluppatori di professione) e assai illuminante. L'articolo è ormai datato, ma ritengo sia e resti decisamente valido: http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
Buona lettura
Ti piace questo commento?
0 
0
Articolo molto interessante, grazie.
Ti piace questo commento?
0 
0
Ciao a tutti, io sono un novizio della programmazione. E quindi ho seguito con grande interesse la vostra discussione anche se ogni tanto un po' troppo accesa.
Cmq, dato che ogni programmatore ha il suo linguaggio preferito e io sono un programmatore alle prime armi e quindi non ho nessuna preferenza .... parliamo solo di linguaggi ...
vengo al dunque, devo fare un applicazione con grafica accattivante che possa essere utilizzata sia su windows che mac e che abbia la possibilità di interfecciarsi con internet (invio automatico di email sms, interconnessione con sito web dedicato), cosa mi consigliate di utilizzare come linguaggio di sviluppo? Io era partito convinto che JAVA era ciò che mi serviva....
Scusate per la banalità dell'uintervento....
Ti piace questo commento?
0 
0
Risposta sotto.
Ti piace questo commento?
0 
0
Scusami per il ritardo con cui ti rispondo, ma il tempo a mia disposizione è sempre pochissimo. La risposta un po' la trovi nell'articolo, ma la cosa più importante è capire che tipo di applicazione intendi realizzare. Darti una risposta, così su due piedi, non è semplice né corretto. Di che applicazione si tratta? Intendi avvalerti di collaboratori? La velocità è importante? Quando parli di applicazione grafica intendi dire applicazione che avrà una GUI o applicazione che farà un uso intensivo di driver video? Si tratta di una sorta di client email? Java è comunque una possibile soluzione, devi anche considerare i tempi di sviluppo e la necessità o meno di avvalerti di collaboratori.
Ti piace questo commento?
0 
0
Volevo fare un applicazione per la domotica. Con una interfaccia grafica che rappresenti la casa o edificio con una pianta o qualcosa di simile, che sia facile sa usare e quindi pensavo a molta grafica per rendere intuitiva l'applicazione, che possa essere accessibile anche da internet e interattiva con il proprietario (nel senso che possa spedire email/sms o riceverli per gestire da remoto il tutto) ed inoltre che possa essere utilizzabile in macchine MAC e Windows. In un secondo momento pensavo anche di fare un'applicazione per smatphone (iphone, galaxy) ma mi sembra di capire che qui ci sono altri linguaggi appossiti per questi oggetti. Per ora lavoro da solo ma sto tentando di coinvolgere dei miei amici.
Sono arrivato anc'io un po' in ritardo a rispondere .... Grazie per i suggerimenti in anticipo.
Ti piace questo commento?
0 
0