Perché non l'abbiamo ancora in programma con file flat?[chiuso]

https://stackoverflow.com/questions/160633

flat-file

03-07-2019
|

Domanda

Perché sono file di testo lo stato dell'arte per rappresentare il codice sorgente?

Di sicuro - il preprocessore e il compilatore ha bisogno di vedere un file flat rappresentazione del file, ma che è facilmente creato.

Mi sembra che una qualche forma di XML o dati binari, potrebbe rappresentare anche un sacco di idee che sono molto difficili da seguire, altrimenti.

Per esempio, si potrebbe incorporare diagrammi UML, diagrammi di destra nel vostro codice.Potrebbero essere generati in modo semi-automatico, e commentato dagli sviluppatori per evidenziare aspetti importanti della progettazione.I diagrammi di interazione, in particolare.Diamine, l'inserimento di qualsiasi utente di disegno potrebbe rendere le cose più chiare.

Un'altra idea è quella di incorporare i commenti dal codice giudizi a destra nel codice.

Ci potrebbero essere tutti i tipi di aiuti di unione di più rami più facile.

Qualcosa mi appassiona non è solo un codice di tracciamento di copertura, ma anche guardando le parti di codice coperto da un test automatizzato.La parte più difficile è tenere traccia di tale codice, anche come sorgente viene modificato.Per esempio, lo spostamento di una funzione da un file all'altro, etc.Questo può essere fatto con il Guid, ma sono piuttosto invadenti per incorporare la destra nel file di testo.In una ricca formato di file, che potrebbe essere automatica e non invadente.

Quindi, perché non ci sono Ide (a mia conoscenza, comunque) che consentono di lavorare con il codice in questo modo?

EDIT: Il 7 ottobre 2009.

La maggior parte di voi ha molto riattaccato la parola "binario" nella mia domanda.Ho ritirarlo.Immagine XML, molto minimamente la marcatura di codice.L'istante prima di mano per il preprocessore normale o compilatore, si striscia fuori tutti i tag XML, e passa solo il codice sorgente.In questa forma, si poteva ancora fare tutte le cose normali per il file:diff, unire, modificare, con una semplice e minima editor, dar loro da mangiare in migliaia di strumenti.Sì, diff, unire e modificare, direttamente con il minimo di markup XML, fa arrivare un po ' più complicato.Ma credo che il valore potrebbe essere enorme.

Se esisteva un IDE, nel rispetto di tutte le XML, si potrebbe aggiungere molto di più di quello che si può fare oggi.

Per esempio, il tuo DOxygen commenti potrebbe effettivamente look come il finale DOxygen uscita.

Quando qualcuno ha voluto fare una revisione del codice, come il Codice di Collaboratore, che potrebbe segnare il codice sorgente, in luogo.

XML potrebbe anche essere nascosto dietro i commenti.

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

E quindi, se si desidera utilizzare vi o emacs, si può semplicemente ignorare i commenti.

Se voglio usare un state-of-the-art editor, posso vedere che in circa una dozzina di diversi modi utili.

Quindi, questo è la mia idea.Non è "blocchi" di immagini che si trascina sullo schermo...Io non sono che i dadi.:)

Soluzione

puoi differli
puoi unirli
chiunque può modificarli
sono semplici e facili da gestire
sono universalmente accessibili a migliaia di strumenti

Altri suggerimenti

A mio avviso, ogni possibile beneficio è compensato dal fatto di essere legato a un particolare strumento.

Con una fonte di testo semplice (che sembra essere quello di cui stai discutendo, piuttosto che file flat in sé) posso incollare blocchi in una e-mail, usare semplici sistemi di controllo della versione (molto importante! ), scrivi il codice nei commenti su Stack Overflow, usa uno dei mille editor di testo su qualsiasi numero di piattaforme, ecc.

Con una rappresentazione binaria del codice, ho bisogno di usare un editor specializzato per visualizzarlo o modificarlo. Anche se è possibile produrre una rappresentazione basata su testo, non è possibile ripristinare banalmente le modifiche nella versione canonica.

Smalltalk è un ambiente basato su immagini. Non stai più lavorando con il codice in un file su disco. Stai lavorando e modificando gli oggetti reali in runtime. È ancora testo ma le classi non sono memorizzate in file leggibili dall'uomo. Invece l'intera memoria dell'oggetto (l'immagine) è memorizzata su un file in formato binario.

Ma le maggiori lamentele di coloro che provano smalltalk sono perché non usa i file. La maggior parte degli strumenti basati su file che abbiamo (vim, emacs, eclipse, vs.net, strumenti unix) dovranno essere abbandonati a favore degli strumenti di smalltalk. Non che gli strumenti forniti in smalltalk in inferiore. È solo diverso.

Perché i saggi sono scritti nel testo? Perché i documenti legali sono scritti in testo? Perché i romanzi fantasy sono scritti nel testo? Perché il testo è la migliore forma, per le persone, di perseverare nei loro pensieri.

Il testo è il modo in cui le persone pensano, rappresentano, comprendono e persistono i concetti - e le loro complessità, gerarchie e interrelazioni.

I programmi Lisp non sono file flat. Sono serializzazioni di strutture dati. Questo codice come dati è una vecchia idea e in realtà una delle più grandi idee in informatica.

<? xml version = " 1.0 " encoding = " UTF-8 "? > < code > I file flat sono più facili da leggere. < / code > ; lt &; / xML gt &;

Ecco perché:

Leggibile dall'uomo. Ciò rende molto più facile individuare un errore, sia nel file che nel metodo di analisi. Inoltre può essere letto ad alta voce. Questo è uno che non puoi ottenere con XML e che potrebbe fare la differenza, specialmente nell'assistenza clienti.
Assicurazione contro l'obsolescenza. Finché esiste regex, è possibile scrivere un parser abbastanza buono in poche righe di codice.
Leverage. Quasi tutto ciò che esiste, dai sistemi di controllo delle revisioni agli editor per filtrare, può ispezionare, unire e operare su file flat. L'unione di XML può essere un disastro.
Possibilità di integrarli piuttosto facilmente con gli strumenti UNIX, come grep, cut o sed.

È una buona domanda. FWIW, mi piacerebbe vedere uno strumento di gestione del codice in stile Wiki. Ogni unità funzionale avrebbe la sua pagina wiki. Gli strumenti di compilazione raccolgono il codice sorgente dal wiki. Ci sarebbe un & Quot; discutere & Quot; pagina collegata a quella pagina, in cui le persone possono discutere su algoritmi, API e simili.

Diamine, non sarebbe così difficile decifrarne uno da un'implementazione Wiki preesistente. Qualche acquirente ...?

Ironicamente ci sono costrutti di programmazione che usano esattamente ciò che descrivi.

Ad esempio, SQL Server Integration Services, che coinvolge il flusso della logica di codifica trascinando i componenti in un'area di progettazione visiva, vengono salvati come file XML che descrivono esattamente quel back-end.

D'altra parte SSIS è piuttosto difficile da controllare alla fonte. È anche abbastanza difficile progettare qualsiasi tipo di logica complessa in esso: se hai bisogno di un po 'più di & Quot; control & Quot ;, dovrai codificare il codice VB.NET nel componente, il che porta noi indietro da dove siamo partiti.

Suppongo che, come programmatore, dovresti considerare il fatto che per ogni soluzione a un problema ci sono conseguenze che ne conseguono. Non tutto potrebbe (e alcuni sostengono, dovrebbe) essere rappresentato in UML. Non tutto potrebbe essere rappresentato visivamente. Non tutto potrebbe essere abbastanza semplificato da avere una rappresentazione coerente dei file binari.

Detto questo, direi che gli svantaggi della relegazione del codice in formati binari (la maggior parte dei quali tenderà anche a essere proprietari) superano di gran lunga i vantaggi di averli in testo normale.

I formati IMHO, XML e binari sarebbero un disastro totale e non darebbero alcun vantaggio significativo.

OTOH, un'idea correlata sarebbe quella di scrivere in un database, forse una funzione per record, o forse una struttura gerarchica. Un IDE creato attorno a questo concetto potrebbe rendere più naturale la navigazione della fonte e nascondere più facilmente qualsiasi cosa non pertinente al codice che stai leggendo in un determinato momento.

Le persone hanno cercato a lungo di creare un ambiente di modifica che vada oltre il file flat e che tutti abbiano fallito in una certa misura. Il più vicino che ho visto è stato un prototipo per la programmazione intenzionale di Charles Simonyi, ma poi è stato ridotto a uno strumento di creazione DSL visivo.

Non importa come il codice viene archiviato o rappresentato in memoria, alla fine deve essere presentabile e modificabile come testo ( senza che la formattazione cambi su di te ) poiché è il modo più semplice che conosciamo esprimere la maggior parte dei concetti astratti necessari per risolvere i problemi mediante la programmazione.

Con i file flat si ottiene questo gratuitamente e qualsiasi editor di testo semplice (con il supporto di codifica dei caratteri corretto) funzionerà.

Steve McConnell ha ragione, come sempre - è la scrittura di programmi in altri programmatori (compreso te), non per i computer.

Detto questo, Microsoft Visual Studio deve gestire internamente il codice scritto in un formato strutturato, o non saresti in grado di fare cose come "Trovare Tutti i Riferimenti" o rinominare o ri-fattore di variabili e metodi così facilmente.Sarei interessato se qualcuno avesse dei link di come funziona.

In realtà, circa 10 anni fa, il primo prototipo di Charles Simonyi per la programmazione intenzionale ha tentato di spostarsi oltre il file flat in una rappresentazione ad albero di codice che può essere visualizzata in diversi modi. Teoricamente, un esperto di dominio, un PM e un ingegnere del software potevano tutti (e mettere insieme) il codice dell'applicazione in modi che erano utili a loro, e i prodotti potevano essere costruiti su una gerarchia di & Quot; intenzioni " ;, scendendo al codice di basso livello solo se necessario.

ETA (per richiesta nelle domande) Esiste una copia di one dei suoi primi articoli su questo nel sito Web di ricerca Microsoft. Sfortunatamente, da quando Simonyi ha lasciato MS per avviare una società separata diversi anni fa, non credo che il prototipo sia ancora disponibile per il download. Ho visto alcune demo quando ero in Microsoft, ma non sono sicuro di quanto fosse distribuito il suo prototipo iniziale.

La sua azienda, IntentSoft è ancora un po 'silenziosa su ciò che stanno pianificando di consegnare al mercato , semmai, ma alcune delle prime cose emerse da MSR erano piuttosto interessanti.

Il modello di archiviazione era un formato binario, ma non sono sicuro di quanti di questi dettagli siano stati divulgati durante il progetto MSR, e sono sicuro che alcune cose sono cambiate dalle prime implementazioni.

Perché regnano i file di testo? A causa del test di McIlroy. È essenziale che l'output di un programma sia accettabile come codice sorgente per un altro, e i file di testo sono la cosa più semplice che funziona.

Labview e Simulink sono due ambienti di programmazione grafica. Sono entrambi popolari nei loro campi (interfacciamento hardware a un PC e sistemi di controllo di modellazione, rispettivamente), ma non utilizzati molto al di fuori di questi campi. Ho lavorato con persone che erano grandi fan di entrambi, ma non sono mai entrato in loro da solo.

Dici che dovremmo usare " qualche forma di XML " ;? Cosa pensi che siano XHTML e XAML?

Anche XML è ancora solo un file flat.

Le vecchie abitudini sono dure a morire, immagino.

Fino a poco tempo fa non c'erano molte librerie di buona qualità, ad alte prestazioni e ampiamente disponibili per l'archiviazione generale di dati strutturati. E vorrei enfaticamente non inserire XML in quella categoria anche oggi - troppo prolisso, troppo intenso per essere elaborato, troppo pignolo.

Al giorno d'oggi, la mia cosa preferita da utilizzare per i dati che non devono essere leggibili dall'uomo è SQLite e creare un Banca dati. È così incredibilmente facile incorporare un database SQL completo in qualsiasi app ... ci sono collegamenti per C, Perl, Python, PHP, ecc ... ed è open source e molto veloce, affidabile e leggero.

I < 3 SQLite.

Chiunque abbia mai provato Mathematica ?

La foto sopra è di una versione precedente ma era il miglior google che potesse darmi.

Comunque ... confronta la prima equazione lì con Math.Integrate (1 / (Math.Pow (" x ", 3) -1), " x ") come dovresti scrivere se stavi codificando con testo semplice nelle lingue più comuni. Imo la rappresentazione matematica è molto più facile da leggere, e questa è ancora un'equazione piuttosto piccola.

E sì, puoi sia inserire che copiare e incollare il codice come testo normale, se lo desideri.

Guardalo come evidenziazione della sintassi di prossima generazione . Scommetto che ci sono molte altre cose oltre alla matematica che potrebbero trarre beneficio da questo tipo di rappresentazione.

È abbastanza ovvio il motivo per cui il testo in chiaro è il re. Ma è altrettanto ovvio il motivo per cui un formato strutturato sarebbe ancora migliore.

Solo un esempio: se rinomini un metodo, il tuo strumento di controllo diff / merge / source sarebbe in grado di dire che è cambiata solo una cosa. Gli strumenti che utilizziamo oggi mostrerebbero un lungo elenco di modifiche, una per ogni luogo e file che il metodo è stato chiamato o dichiarato.

(A proposito, questo post non risponde alla domanda come potresti aver notato)

La tendenza che vediamo sui DSL è la prima cosa che mi viene in mente leggendo la tua domanda. Il problema è stato che non esiste una relazione 1 a 1 tra i modelli (come UML) e un'implementazione. Microsoft, tra gli altri, sta lavorando per arrivarci, in modo da poter creare la tua app come qualcosa di simile a UML, quindi il codice può essere generato. E la cosa importante: quando scegli di cambiare il tuo codice, il modello lo rifletterà di nuovo.

Windows Workflow Foundation è un ottimo esempio. Di causa ci sono file flat e / o XML in background, ma di solito si finisce per definire la propria logica aziendale nello strumento di orchestrazione. E questo è abbastanza bello!

Abbiamo bisogno di più del " software factory " pensando e vedrà un'esperienza IDE più ricca in futuro, ma fintanto che i computer funzioneranno su zero e uno, i file di testo piatti possono e (probabilmente) saranno sempre una fase intermedia. Come già affermato da diverse persone, i semplici file di testo sono molto flessibili.

Mi sono chiesto malinconicamente la stessa cosa, come descritto nella risposta a: Quale strumento / applicazione / qualunque cosa desideri esistesse?

Anche se è facile immaginare un gran numero di benefici, penso che il più grande ostacolo che dovrebbe essere affrontato è che nessuno ha prodotto un'alternativa praticabile.

Quando le persone pensano alle alternative all'archiviazione della fonte come testo sembrano spesso pensare immediatamente in termini di rappresentazioni grafiche (mi riferisco qui ai prodotti commerciali che sono stati disponibili, ad esempio HP-vee). E se guardiamo l'esperienza di persone come i progettisti FPGA, vediamo che la programmazione (esclusivamente) graficamente non funziona, quindi linguaggi come Verilog e VHDL.

Ma non vedo che l'archiviazione della fonte debba necessariamente essere legata al metodo di scriverla in primo luogo. L'inserimento della fonte può essere in gran parte fatto come testo, il che significa che i problemi di copia / incolla possono ancora essere raggiunti. Ma vedo anche che consentendo di eseguire fusioni e rollback sulla base di meta-source tokenizzate potremmo ottenere strumenti di manipolazione più accurati e più potenti.

Visual FoxPro utilizza le strutture di tabelle dbf per archiviare codice e metadati per moduli, report, librerie di classi, ecc. Questi sono file binari. Memorizza anche il codice nei file prg che i file di testo effettivi ...

L'unico vantaggio che vedo è la possibilità di utilizzare il linguaggio di dati VFP incorporato per effettuare ricerche di codice su quei file ... a parte questo è una responsabilità imo. Almeno una volta ogni pochi mesi, uno di questi file verrà danneggiato senza motivo apparente. L'integrazione con il controllo del codice sorgente e le differenze sono anche molto dolorose. Ci sono soluzioni alternative per questo, ma comportano la conversione temporanea del file in testo!

Per un esempio di un linguaggio che elimina la tradizionale programmazione testuale, vedere Lava lingua .

Un'altra cosa elegante che ho scoperto di recente è subtext2 ( demo video ).

Il codice del tuo programma definisce la struttura che verrebbe creata con xml o il formato binario. Il tuo linguaggio di programmazione è una rappresentazione più diretta della struttura del tuo programma rispetto a una rappresentazione XML o binaria. Hai mai notato come Word si comporta male mentre dai struttura al tuo documento. WordPerfect avrebbe almeno 'rivelato i codici' per permetterti di vedere cosa c'era sotto il tuo documento. I file flat fanno la stessa cosa per il tuo programma.

Idea chiara. Mi sono chiesto su una scala più piccola ... molto più piccola, perché IDE X non può generare questo o quello.

Non so se sono ancora in grado di programmare come sviluppatore qualcosa di fico e complesso come il tuo parlare o quello a cui sto pensando, ma sarei interessato a provare.

Forse inizi con alcuni plugin per .NET, Eclipse, Netbeans e così via? Mostra cosa si può fare e inizia una nuova tendenza nella codifica.

Credo che un altro aspetto di questo è che il codice è ciò che è importante.È ciò che sta per essere eseguito.Per esempio, in UML esempio, io penso che invece di avere UML (presumibilmente creato in alcuni editor, non direttamente connessi con il "codice") inclusi nel "source blob" sarebbe quasi inutile.Molto meglio sarebbe avere UML generato direttamente dal codice, così descrive lo stato esatto il codice come strumento per la comprensione del codice, piuttosto che come un promemoria di ciò che il codice deve essere stato.

Abbiamo fatto questo per anni per quanto riguarda automatizzato doc strumenti.Mentre la vera programmatore generato commenti nel codice potrebbe ottenere la sincronizzazione con il codice, strumenti come JavaDoc e come rappresentare fedelmente i metodi di un oggetto, di ritorno tipi di argomenti, etc.Essi rappresentano, essi esistono realmente,non come qualche artefatto che è venuto fuori di infinite riunioni.

A me sembra che se si potesse aggiungere arbitrariamente casuale manufatti per alcuni "source blob", questi sarebbe probabilmente non essere aggiornato, e a meno di utile da subito.Se è possibile generare tali manufatti direttamente il codice, quindi il piccolo sforzo per ottenere il processo di generazione per farlo è di gran lunga migliore di quanto precedentemente menzionato insidie e di allontanamento dal testo normale file di origine.

In relazione a ciò, un spiegazione del motivo per cui si desidera utilizzare il testo UML strumento (UMLGraph sembra applicare quasi altrettanto bene, perché si vuole il testo normale file di origine.

Questo potrebbe non rispondere esattamente alla tua domanda, ma qui è un editor che consente di avere una visione superiore del codice: http://webpages.charter.net/edreamleo/front.html

Penso che il motivo per cui i file di testo sono utilizzati nello sviluppo sia che sono universali contro vari strumenti di sviluppo. Puoi guardare dentro o persino correggere alcuni errori usando un semplice editor di testo (non puoi farlo in un file binario perché non sai mai come qualsiasi correzione distruggerebbe altri dati). Non significa, tuttavia, che i file di testo siano i migliori per tutti questi scopi.

Ovviamente, puoi diffonderle e unirle. Ma ciò non significa che lo strumento diff / merge comprenda la struttura distinta dei dati codificati da questo file di testo. Puoi fare il diff / merge, ma (specialmente visto nei file XML) lo strumento diff non ti mostrerà le differenze correttamente, cioè ti mostrerà dove i file differiscono e quali parti dei dati lo strumento " quot pensa &; sono uguali. Ma non ti mostrerà le differenze nella struttura del file XML, ma abbinerà solo le linee che sembrano uguali.

Indipendentemente dal fatto che stiamo usando file binari o di testo, è sempre meglio che gli strumenti diff / merge si occupino della struttura dei dati rappresentata da questo file piuttosto che delle linee e dei caratteri. Per i file C ++ o Java, ad esempio, segnala che un identificatore ha cambiato il suo nome, segnala che alcune sezioni sono state circondate da if () {} aggiuntivo, ma, d'altra parte, ignorano le modifiche nei rientri o nei caratteri EOL. L'approccio migliore sarebbe che un file venga letto in strutture interne e scaricato mediante regole di formato specifico. In questo modo la differenza verrà effettuata attraverso le strutture interne e il risultato della fusione verrà generato dalla struttura interna unita.

I programmi moderni sono composti da pezzi piatti, ma sono piatti? Ci sono usi, e include e librerie di oggetti, ecc. Una normale chiamata di funzione è una sbirciatina in un posto diverso. La logica non è piatta, a causa di più thread, ecc.

Ho la stessa visione! Vorrei davvero che esistesse.

Potresti dare un'occhiata a Fortress, un linguaggio di ricerca di Sun. Ha un supporto speciale per le formule nel codice sorgente. La citazione seguente è tratta da Wikipedia

La fortezza è stata progettata dal all'inizio per avere sintattica multipla fogli di stile. Il codice sorgente può essere reso come testo ASCII, in Unicode o come immagine carina. Questo permetterà per supporto di simboli matematici e altri simboli nel rendering output per una lettura più semplice.

Il motivo principale della persistenza del testo come sorgente è la mancanza di powertools, come ad esempio il controllo della versione, per la data non testuale. Questo si basa sulla mia esperienza di lavoro con Smalltalk, in cui il semplice codice byte viene sempre tenuto in un core-dump. In un sistema non testuale, con gli strumenti di oggi, lo sviluppo del team è un incubo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow