Devo introdurre un formato dati con un'espressività limitata o utilizzare la piena espressività di lisp?

Question

Devo introdurre un formato dati con un'espressività limitata o utilizzare la piena espressività di lisp?

#1 da (1 voti)
#2 da (0 voti)

3

Sto sviluppando un gioco per computer. È un progetto di hobby per una sola persona. Lo implementerò nelle common-lisp . Come prova del concetto sto provando a generare proceduralmente una scena selezionando casualmente le voci da più tabelle. La scena dovrebbe reagire dinamicamente al giocatore.

Intendo utilizzare un tipo personalizzato di entità / componenti di architettura del sistema di entità componente e le loro reciproche connessioni sono memorizzate come dati collegati in RDF. Gli alberi di comportamento, anch'essi memorizzati nell'ECS, permetteranno al gioco di reagire al giocatore.

Stavo codificando i potenziali oggetti per la scena in tripli in un formato probabilistico personalizzato e creando una funzione in lisp per leggere questi dati e generare casualmente la scena.

Ora mi chiedo perché sto sviluppando un formato di dati personalizzato con espressività limitata se potessi codificare direttamente il codice dati / codice in Lisp (probabilmente estendendo il lisp nella direzione di questa particolare applicazione lungo la strada)? Ha creato un formato dati ridotto qualsiasi vantaggio nel contesto di un progetto implementato in lisp? E 'qualcosa che si dovrebbe fare solo in lingue non-lisp (es. La citazione ben nota di Greenspun "qualsiasi programma C o Fortran sufficientemente complicato contiene una implementazione ad-hoc, informalmente specificata, corrotta da un bug, lenta implementazione di metà della fonia comune")?

Posso pensare ad alcuni motivi, ma posso contrastarli tutti per questo progetto:

il team del progetto ha membri che non possono scrivere fiv
- counter: si tratta di un progetto per un singolo hobby e probabilmente non sarà grande con i membri del team non-lievi
- : utilizzando gli strumenti lisp che emettono, leggono ed elaborano il codice Lisp possono essere creati quando necessario
il formato dei dati dovrebbe essere usato in altre lingue non libere
- : per questo progetto l'interoperabilità con non-lisp non è richiesta.
problemi di rendimento
- counter: a questo punto non so se funzionerà terribilmente; dovremmo usare le misure per scoprire se ci sono problemi; e l'ottimizzazione prematura non è saggia
- : il codice ad alte prestazioni può essere scritto usando lisp
- : se necessario, possiamo semplificare in seguito
il gioco potrebbe essere un bel banco di prova per un negozio di tripli personalizzati e per il tipo di architettura del sistema di componenti personalizzati
- concesso, tuttavia, entrambi sono anche progetti futuri per hobby; l'architettura ECS può evolversi a lato del gioco e il negozio di triple ha altri usi.

common-lisp

posta Kasper van den Berg 04.10.2018 - 21:15

fonte

2 risposte

1

Ci sono aziende (ad es. Franz Inc. ) che con successo vendere sia Common Lisp (es. Allegro Common Lisp ) e un database grafico (ad esempio AllegroGraph ). C'è cl-neo4j , un'interfaccia per neo4j base dati del grafico (nota anche come piattaforma grafica) e Vivace-3 , un nativo chiaro base di dati del grafico, sia da Kevin Raison . Il loro gergo di marketing non urla "non lasciarti indietro usando un database di grafici semantici, passa a Common Lisp e unisciti ai ragazzini". E probabilmente alcuni dei loro clienti usano entrambi con successo.
Quindi ci devono essere situazioni in cui la combinazione di Common Lisp con un database di grafici e quindi la creazione di un formato di dati meno espressivo da memorizzare nel database è una buona ingegneria del software. Queste situazioni sono tutte esentate dalla specifica situazione dell'OP? Probabilmente no.

Ci sono alcuni vantaggi nell'usare un formato dati ridotto basato su RDF o un grafico di proprietà:

(Semantico) i database dei grafici / i grafici delle proprietà offrono la combinazione di persistenza, mutabilità simultanea e scalabilità.
I concetti in isolamento sono disponibili o possono essere implementati separatamente con relativa facilità in Common Lisp. La loro combinazione porterebbe a una base di dati (grafica) scritta in Lisp (anche se forse una forma ad-hoc adattata all'applicazione dell'OP). E si noti che il supporto delle funzioni di memorizzazione (parzialmente valutate) mantenendo contemporaneamente la mutabilità e la scalabilità potrebbe essere una bestia diversa del tutto (es. Elephant memorizza solo oggetti e valori di slot e non funzioni, chiusure e oggetti di classe).
Gli strumenti esistenti supportano i formati di RDF o di grafi proprietari, ma non un formato di codice / dati valutabile e personalizzabile Sebbene il PO abbia specificato che l'interoperabilità con altri programmi non era importante, la possibilità di utilizzare gli strumenti esistenti potrebbe essere una sorta di interoperabilità che sarebbe auspicabile dall'OP.
Una limitazione degli strumenti esistenti sarebbe che supportano le basi di RDF o un altro formato grafico; per la semantica del formato ECS personalizzato in cima all'OP RDF sarà comunque necessario scrivere strumenti personalizzati.

risposta data 06.10.2018 - 15:55

fonte

Leggi altre domande sui tag common-lisp

Separazione di oggetti di dominio e modelli di dati Come gestire le richieste di amicizia in REST API social

score 0 · Accepted Answer

Gerald Jay Sussman, Julie Sussman e Harold Abelson in Struttura e interpretazione dei programmi per computer offre più vantaggi dell'uso di interfacce convenzionali (§2.2.3 Sequenze come interfacce convenzionali):

L'uso delle interfacce convenzionali aumenta la chiarezza concettuale del codice risultante; cioè il codice diventa più facile da capire per coloro che hanno familiarità con l'interfaccia convenzionale usata.
Sebbene le operazioni di sequenza siano più comuni delle operazioni sui grafici RDF, l'interrogazione di un RDF è più convenzionale dei costrutti lisp arbitrari con la piena espressività di Lisp.
La modellazione produce come operazioni su sequenze (o operazioni / query su grafici RDF) rende le procedure più modulari.
Con un formato di dati convenzionale (ad es. Sequenze o grafici RDF) si può riutilizzare o riutilizzare una libreria esistente di operazioni per quel formato (ad es. Operazioni come mapcar, filtro, generare, selezionare e graph-walk) ed esprimere le procedure in termini di queste operazioni. La libreria delle operazioni è stabile. Le operazioni possono essere riutilizzate in molte procedure. E le procedure sono flessibili e possono essere modificate facilmente componendo in modo diverso.