Creando un Lenguaje de Almacenamiento de Datos

Mensajes
168
Oro
13,750
Tengo una propuesta, y es que entre todos los informáticos de Universum vayamos creando un sistema de Almacenamiento de Datos, como XML y JSON, aporten ideas de orden y jerarquía y ayuden con el intérprete

Se cita a:
 
standards.png

(XKCD 927 - Standards. Enlace)

Aún así, es un ejercicio interesante. Pues lo que dijo el otro más arriba: se un poco más específico.
 
Un segundo, que no había leído bien...


Da faq? Querrás decir el parser, no? Porque si es como esos dos, no creo que un intérprete propiamente dicho sea aplicable. Es eso, o estás intentando hacer algo para lo que un lenguaje de scripting como CubeScript sería más apropiado.
Con intérprete me refería al Parser, si, y en cuanto al problema es sencillo: Un LAD (Lenguaje de Almacenamiento de Datos (DSL en inglés)) que combine lo mejor de todos los DSL: Los nodos de XML, la sencillez y orden de JSON, etc...
Quiero crear un Parser para por lo menos los siguientes lenguajes:
  • Java
  • Javascript
  • C/C++
  • PHP
Los iremos desarrollando de uno en uno, y me interesa mucho el PHP, se lo quiero encargar a , quiero que sea cifrable y que el Parser tenga un decodificador por código, más adelante lo explicaré mejor, y por último quiero utilizarlo como alternativa a los SQL, de modo que sea más fácil de manipular
 
Con intérprete me refería al Parser, si, y en cuanto al problema es sencillo: Un LAD (Lenguaje de Almacenamiento de Datos (DSL en inglés)) que combine lo mejor de todos los DSL: Los nodos de XML, la sencillez y orden de JSON, etc...
Quiero crear un Parser para por lo menos los siguientes lenguajes:
  • Java
  • Javascript
  • C/C++
  • PHP
Los iremos desarrollando de uno en uno, y me interesa mucho el PHP, se lo quiero encargar a , quiero que sea cifrable y que el Parser tenga un decodificador por código, más adelante lo explicaré mejor, y por último quiero utilizarlo como alternativa a los SQL, de modo que sea más fácil de manipular
Pero qué quieres hacer? Qué problema te surgió que los formatos tradicionales no resuleven? Cuál es el uso que le quieres dar al formato?

Vamos a dejar SQL—y las otras cosas que no sé porqué te hacen falta—de lado por ahora.
 
Tengo una propuesta, y es que entre todos los informáticos de Universum vayamos creando un sistema de Almacenamiento de Datos, como XML y JSON, aporten ideas de orden y jerarquía y ayuden con el intérprete
Bueno, esto lo he visto por pura casualidad, y me pregunto si no se me habrán pasado otras publicaciones en las cuales se me cite como en esta, porque como no me llega una notificación ni nada de eso ni me entero.

En cuanto a la propuesta no le veo nada de malo, sólo no sé si en realidad serviría de algo, puesto me imagino con lo existente se puede hacer casi todo lo necesario.

En particular XML y JSON tienen un uso extendido tanto para guardar datos como para utilizarlos en comunicaciones como lo hace SOAP en .Net con el primero de los mencionados; si mal no recuerdo el primero en extenderse fue XML, sin embargo, JSON es mucho más ligero y sencillo y por eso ha venido tomando cada vez más preponderancia; por todo esto, si no hacemos algo para suplir una deficiencia de los anteriores, o para utilizarlo como base para algo más, no creo al final alguien use nuestro invento, ni tendría objetivo.

En esto pasa como en casi todo, es difícil para no decir imposible desplazar algo considerado como un estándar (o casi un estándar como sucede con Windows), y cada día eso se hace más complicado; sin mencionar el hecho de la existencia de muchos más lenguajes o también estructuras (ahora no me viene la palabra adecuada a la mente) para el almacenamiento de información.

En inteligencia artificial en particular se utilizan muchas formas como los Marcos, las Redes de Creencias, etc., con el fin de guardar tanto la información como sus relaciones de modo se pueda simular más o menos el modo de funcionamiento del cerebro humano en áreas específicas como los sistemas expertos.

Por eso en este caso considero más conveniente ponernos a hacer algo diferente si vamos a hacer algo, podría ser para suplir un déficit real en algún área específica o algo más general, algo no existente y necesario a un cierto número de personas o por lo menos nunca antes desarrollado en Cuba.

Por ejemplo (y esto no significa sea una buena idea sino sólo una muestra de algo hasta donde sé no desarrollado antes en Cuba desde cero, más bien por no ser necesario no por su complejidad más bien escasa), hace poco estaba escribiendo un tutorial sobre cómo hacer una interfaz grafica de usuario desde cero con BASIC, y después de eso me proponía desarrollar una más completa para FreeDOS, si es posible no sólo como GUI sino más bien algo como Windows 3.0 capaz de llevar multitarea a un entorno monotarea como ese, puesto FreeDOS es un entorno libre al menos usado por un limitado número de personas, aun si todo esto lo estaba haciendo nada más como un modo de superación personal (si les interesa y me dan un correo por privado puedo mandarles una calculadora hecha usando la interfáz gráfica puesto no he publicado eso en ninguna parte además de mi blog, en donde nada más he puesto algunas entregas).

Pero si me preguntan consideraría mucho más recomendable implementar un juego como xNova y otros, porque si la idea es que la gente use algo lo más recomendable es un juego con una nueva historia y capaz de ser extendido sin límites, dado los juegos son los programas más utilizados en todo este planeta, y encima pueden hacerse de modo la gente aprenda algo o se supere de alguna manera en tanto se entretiene.
 
sólo no sé si en realidad serviría de algo
Ya tengo un objetivo en mente pero parece que no lo dejé muy claro al principio:



Trato de usar el nuevo DSL como algo que pueda ayudar a los más inexpertos (o vagos) a guardar información segura y de manera práctica, algo así como simplificar el SQL. Pero también que soporte varios métodos de almacenamiento. Es obvio que no puedes hacer con XML lo que harías con JSON o viceversa, sin embargo lo que trato de hacer es implementar un método que ayude a almacenar de varias maneras e incluso intercalarlas y/o usar unas dentro de otras, de manera que se amplíe el rango de posibilidades y la sencillez de uso.



También enfatizo tanto en lo de SQL porque muchas veces resulta indispensable un servidor para utilizarlo, como MySQL, o puede ser incómodo de usar para algunos, además puede ser fácilmente implementado por los game dev para guardar los datos del juego, y se podría crear un archivo individual para cada partida o para cada categoría de datos como "Personajes" o "Items".



Bueno, creo que me fui un poco por las ramas, en fin, aquí explico el objetivo.



P.D: También ayuden a crear un nombre, estaba pensando en LEAF, o algunas siglas, según el resultado
 
Trato de usar el nuevo DSL como algo que pueda ayudar a los más inexpertos (o vagos) a guardar información segura y de manera práctica

Ya veo. Tú lo que quieres es hacer una capa de abstracción sobre una base de datos con diversos back-ends (XML, JSON y demás). Algo como los modelos de Django.
Un servicio lea de un archivo "user-friendly" que el usuario escribió y construya una Base de Datos con los modelos. El servicio correría 24/7, esperando instrucciones de un cliente (que manipula el usuario) que le mande a manipular o añadir datos.

Audiencia: Desarrolladores de Juegos.
Campo: BBDD.
Lenguaje: Independiente.
Plataforma: Independiente.
Tipo: Capa de abstracción configurable.
 
Tú lo que quieres es hacer una capa de abstracción sobre una base de datos con diversos back-ends (XML, JSON y demás).
Casi, deseo más bien hacer un DSL independiente de los demás, combinarlo todo en un solo archivo. No es necesaria la compatibilidad con otros DSL, va a ser otro estándar ( por lo menos apunto a eso ) y el back-end va a ser uno solo: este.

Para explicarme mejor: va a ser similar a estos otros lenguajes en muchas cosas, pero NO VA a utilizar XML, JSON, u otro. Luego publicaré un ejemplo de la sintaxis prototipo, todavía la estoy desarrollando.

P.D: En serio, ayuden con el nombre

Audiencia: Desarrolladores de Juegos.
La audiencia va a ser más bien generalizada, lo de los videojuegos lo ponía como un ejemplo y concordar con .
 
Trato de usar el nuevo DSL como algo que pueda ayudar a los más inexpertos (o vagos) a guardar información segura y de manera práctica, algo así como simplificar el SQL. Pero también que soporte varios métodos de almacenamiento. Es obvio que no puedes hacer con XML lo que harías con JSON o viceversa, sin embargo lo que trato de hacer es implementar un método que ayude a almacenar de varias maneras e incluso intercalarlas y/o usar unas dentro de otras, de manera que se amplíe el rango de posibilidades y la sencillez de uso.
En ese caso sería algo como un ORM, o como han dicho antes, una capa de abstracción, algo para simplificar la manera de acceder a una base de datos, o para acceder a ella de una manera más independiente a como se guardan en realidad los datos, aun si supuestamente el SQL se creó como un lenguaje de los más sencillos para realizar esas tareas, y se suponía fuera casi como escribir una oración en inglés.

En un libro creo de Ian Martins, autor entre otros de La cara oculta de Delphi, se menciona eso de la simplicidad del SQL, y después dice de manera chistosa que en lo personal nunca ha visto a un directivo de cuello y corbata haciendo un consulta por sí mismo para enterarse de algo, porque ahora a algunos SQL podría parecerle complicado, pero en comparación con lo que había en los tiempos cuando se usaban las bases de datos jerárquicas y de redes (no se trata de las redes de comunicación), otros modelos distintos al relacional sobre los cuales se debía elaborar un programa para conseguir la información demandada, el SQL resultó ser una facilidad, porque lo permitía con una oración en inglés como menciono arriba y en verdad se suponía que su uso iba a disminuir los costos puesto cualquiera podría consultar los datos frente a una consola sin necesidad de hacer un nuevo programa para eso.

También enfatizo tanto en lo de SQL porque muchas veces resulta indispensable un servidor para utilizarlo, como MySQL, o puede ser incómodo de usar para algunos, además puede ser fácilmente implementado por los game dev para guardar los datos del juego, y se podría crear un archivo individual para cada partida o para cada categoría de datos como "Personajes" o "Items".
En este caso no es exactamente así, muchas bases de datos más bien de escritorio tienen su motor capaz de interpretar el SQL, por ejemplo, el motor Jet usado por las bases de datos de access anteriores (.mdb) lo hacía, y más el de las más modernas, y también se le agregó a los dBase más modernos, e incluso creo al SQLite si mal no recuerdo o me confundo con otra cosa, como su propio nombre lo indica.

De todas maneras, en primer lugar se debería definir cómo sería el almacen final de los datos, porque no me imagino inventar algo más sencillo que el formato de una base de datos dBase (.dbf), el cual es fácil de entender y manipular, y no se necesita mucho código para eso, por eso ese formato se utiliza todavía en cosas sencilla incluso cuando a veces ni sabemos se hace, como mismo el formato de SQLite, utilizado por navegadores para su almacén local de datos.

Es relativamente sencillo hacer unas pocas clases para crear y manipular una base de datos .dbf (ellos le llaman base de datos a un archivo .dbf aun si más bien se trataría de una tabla) sin necesidad de utilizar ninguna otra cosa, y por mi parte lo he hecho, aun si no tan completo como para incluirle un intérprete del SQL puesto eso nunca me ha hecho falta personalmente para guardar y recuperar un volumen de datos reducido como suele pasarme.

El entorno Delphi en particular también dispone de Midas, una solución para hacer software multicapas pero que también trae una base de datos local implementada con características algo jerárquicas puesto se puede guardar una tabla en un campo de otra tabla, algo si mal no recuerdo posible sólo en Oracle, y por supuesto, es capaz de interpretar SQL.

Es mejor elabores algo así como un manual breve con todas tus ideas y así todos van a entender mejor el propósito de todo esto y ponerse de acuerdo, puesto tal vez algo así incluso exista desde hace rato y sólo sea cuestión de utilizarlo.
 
Atrás
Arriba