È comune scrivere parser di file in lingue superiori come Java?

I programmatori scrivono programmi nelle lingue con cui si sentono più a proprio agio. Essendo un programmatore Java, sarei incline a usare Java per scrivere un parser di file, sebbene Java non sia certamente il linguaggio più adatto da utilizzare per l'attività, non perché sia inefficiente, ma perché tende a richiedere molto codice di codice. La maggior parte, ma non tutti i codici di questo codice sono incentrati sulla progettazione OOP, e poiché l'attività in questione è di natura molto funzionale, la necessità di classi potrebbe essere rappresentata al meglio da una singola riga nel file o nelle informazioni di intestazione.

Per quanto riguarda l'analisi / gestione dei file, python sarebbe più adatto dal punto di vista dell'efficienza, superando gli stream di Java. Tuttavia, a seconda della complessità del tuo programma, potresti preferire l'uso di Java per ciò che viene dopo l'analisi effettiva del file, specialmente se stai usando Java 8, i cui stream potrebbero rendere il lavoro multithreading relativamente compito semplice.

Detto questo, quando hai in mano un martello, tutto sembra un chiodo. Cerca di non scrivere programmi per eseguire compiti che possono essere già eseguiti almeno in parte da programmi come awk e grep che possono ridurre il programma vero e proprio a uno molto più semplice che impiega un quarto del tempo a scrivere. Le lingue più alte non producono necessariamente programmi migliori , ma solo più complessi.

Solo poche settimane fa, ho trasformato un file GeoJson in un formato binario personalizzato e ho scritto un parser JavaScript per sostituire il parser GeoJson JavaScript originale. Intorno allo stesso tempo, ho anche trasformato un formato binario personalizzato in un formato binario più compatto e ho scritto un parser JavaScript per sostituire il parser C ++ utilizzato per il formato binario originale. Quindi, in pratica, ho scritto due parser in JavaScript per leggere diversi formati binari.

Non posso dire che questo sia qualcosa che faccio sempre, ma non è qualcosa che ho pensato anche due volte. Se ho bisogno di analizzare un determinato tipo di file, prima cerco progetti open source in qualsiasi lingua io stia usando per fare il duro lavoro per me. Se non riesco a trovarne uno per qualsiasi motivo, ne scrivo uno anch'io.

Certo, C ++ e Perl saranno più veloci di un linguaggio come Java o JavaScript, ma per la maggior parte dei casi l'impatto sulle prestazioni è semplicemente troppo piccolo per disturbare l'aggiunta di una lingua che non ti è familiare al tuo stack o che sarebbe usato solo per l'analisi. Quindi se la tua lingua preferita è Java, scrivi il parser in Java. Periodo!

Qualunque sia la ragione per cui non riesci a trovare una libreria Java open source adatta a fare il parsing per te, non è perché è qualcosa che non dovresti fare.

Ho intenzione di darti una prospettiva completamente diversa su questa domanda alle altre risposte. Il punto è che mentre non esiste una ragione specifica per non scrivere un programma che analizzi l'output di un altro programma in Java, di regola, i programmi Java hanno meno probabilità di farlo rispetto ai cosiddetti linguaggi "scripting" come perl e Python . Mentre ci sono ragioni tecniche (le librerie di controllo dei processi di Java sono state storicamente piuttosto scadenti, rendendo difficile gestire i processi esterni senza fili multipli e / o librerie native esterne - che sono ampiamente scoraggiati nella cultura Java come non "pura Java" - e la mancanza di una sintassi dedicata per le espressioni regolari aggiunge certamente un po 'di overhead a tale sistema) i motivi principali sono culturali.

La cultura Java enfatizza la portabilità della piattaforma. Affidarsi a programmi esterni rende difficile la portabilità.

La cultura Java preferisce soluzioni orientate agli oggetti. Un flusso di dati di testo non si adatta bene a OO.

Le librerie di Java culture piacciono alle funzionalità di pacchetto e possono essere installate aggiungendo una dipendenza di tipo Maven. I programmi esterni non si adattano a quel modello.

In una situazione in cui un programma perl di solito chiama un processo esterno e analizza i risultati, è molto probabile che un programma Java importi una libreria Java che esegua l'azione del processo esterno e restituisca il risultato già incapsulato in una rappresentazione precisa orientata agli oggetti.

Se il processo esterno non può essere integrato direttamente nel sistema Java come questo (forse perché deve essere eseguito su un sistema remoto, o forse deve essere integrato con un software non java) il prossimo approccio più probabile è chiamarlo come un servizio utilizzando un protocollo di rete, preferibilmente basato su un formato di dati standardizzato (quindi il parser esiste già), ad esempio utilizzando JSONP o simili.

C'è una semplice risposta a "È normale scrivere parser di file in lingue più avanzate come Java?" e quella risposta è sì, è molto comune. Se questa è una buona idea, contano molti fattori. Come fa notare Jules, chiamare altri programmi da Java tende ad essere piuttosto impegnativo. Un'altra domanda è se questi formati sono personalizzati. Se sono formati standard, le librerie di analisi per Java spesso esistono già. Se sono personalizzati, probabilmente vorrai dare un'occhiata a qualcosa come ANTLR .