Scrivi una volta, corri ovunque. È ancora rilevante? [duplicare]

Qualunque sia il destino della JVM, "scrivi una volta, corri ovunque" è ancora straordinariamente rilevante. Il modo in cui raggiungi questo obiettivo - utilizzando una VM o traducendo in una lingua specifica della macchina - è irrilevante. Nel 2010 il desktop è ancora un argomento MOLTO caldo e le app sono molto vive. Che cosa c'è di tutto in iPhone? Sono app lato client e se puoi coprire più piattaforme contemporaneamente - che tu lo faccia con Java o qualcosa come Python in Titanium (purtroppo, nessun Python per iOS, se ho capito bene) - risparmi, tempo di sviluppo e, infine, hanno più soldi per comprare sushi.

Detto questo, le app native hanno il loro posto, [[[even if] you write:them] likeThis];

Successivamente: dato che hai menzionato WS in questo, probabilmente stai parlando del lato server. È ancora rilevante: la possibilità di cambiare piattaforme server offre flessibilità a una società tecnologica in quanto i prezzi e le prestazioni dei sistemi operativi dei server variano nel tempo. Quindi molte cose sono scritte, una volta eseguite ovunque sul lato server, però: Rails, PHP. Ma ancora, molto rilevante.

Scrivi una volta, corri ovunque abbia sempre avuto un paio di problemi:

• "scrivi una volta, esegui il debug in tutto il mondo": gli sviluppatori provenienti da una piattaforma specifica farebbero occasionalmente ipotesi ingiustificate su come funzionavano le piattaforme tutte , ad es. tale configurazione potrebbe sempre essere archiviata in un registro, che tutti gli ambienti di esecuzione abbiano memoria virtuale o che tutti i telefoni cellulari che sostengono di supportare JPEG possano effettivamente riprodurre i file JPEG. Quindi, in effetti, avresti bisogno di testare la tua applicazione su ogni piattaforma che sostenevi di supportare, riportando i costi di sviluppo.
• "scrivi una volta, scappa": le interfacce utente in app multipiattaforma tendono a prendere in prestito i paradigmi HCI della piattaforma in cui il progettista era più a suo agio, e quindi non si adattano bene alle piattaforme a cui sono porting. Anche dove la libreria di widget è stata progettata per produrre controlli di aspetto nativo (Apple, in particolare, ha investito molto nel far apparire nativo Swing), il posizionamento, il comportamento e il flusso di lavoro possono ancora essere diversi.

Sul lato server questi problemi sono meno significativi: il browser è l'interfaccia utente e le persone tendono a scegliere uno tra Win o * nix e stare con esso. In quel caso, "scrivere una volta, correre ovunque" è stato ciò che ha permesso a numerose aziende di abbandonare Solaris per Linux dopo il crash delle dot.com.

Sì, è ancora pertinente.

Se vivi in una parte del mondo che dispone di un accesso Internet ultraveloce ad alta disponibilità, sei fortunato.

Anche se sei così fortunato, e il servizio web che desideri utilizzare è così fortunato, devi comunque affrontare i problemi di latenza e gli errori del calcolo distribuito.

Immagina per un momento come sarebbe usare qualcosa come Photoshop attraverso un browser.

Quindi le applicazioni desktop probabilmente non andranno via presto. Ciò significa che se vuoi scegliere come target più piattaforme / architetture, devi occuparti di scrivere una volta, eseguire ovunque.

Come Yar sottolinea non importa terribilmente come si ottiene WORA, se si utilizza una macchina virtuale o una traduzione incrociata. La domanda importante è se desideri o meno indirizzare più piattaforme in primo luogo.

(Nota storica: tutti sembrano pensare a Java quando sentono "VM", ma le macchine virtuali erano vecchie notizie molto prima che Java fosse sulla scena.)

Sì, ma in ambito web (concedi o prendi alcune stranezze del browser). Per quanto riguarda i desktop, "scrivere una volta, correre ovunque" è praticamente irrilevante dato che qualcosa come il 90% degli utenti di computer nel mondo sono utenti di MS Windows.

Meno di quanto non fosse, mi sembra, certamente sul cliente. Javascript è costantemente sempre più veloce e più potente e con le opportunità offerte da HTML 5 ci saranno molte più opzioni per lavorare nel browser in futuro (o in effetti ora) per fare cose che in passato avrebbero avuto bisogno di una sorta di software lato client .

Sul server è meno di un problema, comunque penso che - abbastanza spesso ho usato Windows per sviluppare applicazioni Perl, PHP o Rails da eseguire su server linux o bsd e in generale hanno funzionato bene. Se si sta lavorando a un runtime di scripting, si ottengono vantaggi agnostici simili alla piattaforma per lavorare sulla JVM (che è abbastanza simile in sostanza) senza il sovraccarico di digitazione di lavorare in Java.

Ho sperimentato un po 'con lo sviluppo di giochi in Java e questo è un posto in cui scrivere, una volta, leggere ovunque sarebbe davvero utile, ma in realtà una volta che hai bisogno dell'accesso all'accelerazione hardware non sei più genuinamente indipendente dalla piattaforma ... .

In realtà è un caso piuttosto semplice e diretto di una tensione fondamentale che non sta andando via in qualunque momento presto. Mentre i suoi sviluppatori sognano, "scrivi una volta, corri ovunque" adatta le piattaforme. L'intera attività dei venditori di piattaforme dipende dalla differenziazione. Per loro, il suo "Scrivi una volta e scrivi solo per me". Le due parti continueranno a tirare in direzioni opposte per un po 'di tempo a venire.