FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Creando mi propio lenguaje: Ideas
Me pico el bicho de crear un lenguaje de programacion. No he podido sacarme de la cabeza la idea a pesar de que:
1- Ya hay demasiados 2- Es una tarea titanica 3- Es casi imposible que resulte exitoso 4- No tengo el tiempo ni los recursos Pero en fin. No es secreto que me encanta python, asi que no es sopresa que esta basado en el. Pero estas son un conjunto de ideas que me *fastidian enormemente* cuando programo, y me gustaria que existiera el lenguaje que propongo. Filosofia (ideas en desorden) 100% de acuerdo con Zen de Python. Muerte al NULL. Me da rabia de la mala (en especial con Ojb-c) que un objeto puede ser NULL en cualquier momento y que cause un error de excepcion. Por ende, mi lenguaje no considera que el valor de inicializacion de todo es un NULL. Todo se inicializa y existe legalmente, y no se puede nulificar (a menos que se use un tipo nullable). El NULL es un caso excepcional, pero casi todos los lenguajes lo consideran el estado por defecto. NULL es como tener que manejar la memoria manualmente... Dentro del programa, solo existe UNA y SOLO una forma de formato de datos. No veo porque deba usarse "\" o "/" en un lenguaje para manejar el separador de carpetas, porque existe simultaneamente cadenas ASCII, utf(8, 16, 32) y demas a la vez. O que haya la posibilidad de tener varios formatos de fecha, basados en la configuracion regional. En mi opinion, el mundo exterior no debe alterar el comportamiento del interior del programa. El programa lee y transforma en los datos para ser compatible con el mundo exterior (ej: Para mostrarle al usuario, o al leer campos de tablas, configuracion del sistema) pero una vez esta dentro del sistema, no existe variacion en la estructura de datos. La unidad basica es la funcion, no el objeto. Esto combina con: No hay necesidad de usar herencia para la OO. 100% de acuerdo con GO. Los numeros se hace con tipos de datos DECIMAL, no integrales o flotantes. Es toda una patada que las operaciones de +,-.* funcionen bien pero las / salgan incorrectas. La matematica DECIMAL no tiene problemas de errores de precision. El uso de INT y FLOAT se debe relegar a los casos donde tiene sentido. Los string deben ser internamente por defecto UTF8. Los mensajes de error deben tener los datos!!! Me *mata" cuando hay un mensaje del tipo " El registro esta duplicado". Y no me dice: En que tabla de que BD, de que campo, y lo mas importante, que VALOR lanzo el problema! Deberia ser: "El registro en Clientes.Id = 1 esta duplicado" Todo esto se puede resumir en: por defecto, lo correcto/obvio no lo mas eficiente. Usar el principio de la menor sorpresa. Como se veria el lenguaje? Variables. Seria un lenguaje tipado, como PASCAL Código PHP:
Código PHP:
Código PHP:
Texto largo. Soporte a closure, asi que captura las vbles/funciones de su entorno. No hay comillas! Código PHP:
Código PHP:
Código PHP:
Por ejemplo:
La idea es que el tipo de datos hace la transformacion y el validado del dato en el mismo tipo. Esto es lo que tengo por ahora: Código PHP:
__________________
El malabarista. |
#2
|
||||
|
||||
No sabes..., sería TAN hermoso un lenguaje de programación "PASCAL alike" en castellano...
En la profesional nos tocó "diseñar" un compilador para una materia de programación, pero como en todos los casos, terminas recurriendo a C para "crear" tu lenguaje. Como dato curioso, nuestro lenguaje de programación usaba el náhuatl como modelo de sintaxis y en las palabras.
__________________
Felipe Eduardo Ortiz López. Delphi programmers does it recursively... "Un programador, es un creador de universos en donde sólo él es responsable. Universos de complejidad prácticamente ilimitada que se puede crear en forma de programas de ordenador." - Joseph Weizenbaum. Témele a los profetas... y a aquellos que están listos para morir por "la verdad", ya que como regla general hacen morir a muchos otros con ellos, frecuentemente antes que ellos, y a veces en lugar de ellos. — Umberto Eco |
#3
|
||||
|
||||
¡No te desanimes porque alguien como yo no pueda decir esta boca es mía aquí y ahora!
|
#4
|
||||||
|
||||||
Hola! Antes que nada, mi intención no es desanimar Me parece muy interesante tu planteamiento, y con un lenguaje así, podrías resolver muchos problemas de una forma muy sencilla.
Pero... Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Sin embargo, lo vería más como un lenguaje para aprendizaje, con las opciones limitadas, todo fuertemente tipado y sin posibilidad de errores; más que para un lenguaje profesional, donde las necesidades de cada uno son muy diversas y no se pueden englobar en un lenguaje con las características que propones. Sin embargo, ya digo, como lenguaje para iniciación me parece muy bien. Un saludo, y espero no haberte desanimado LoPiTaL |
#5
|
|||||||
|
|||||||
Cita:
Diseñar un lenguaje es mas dificil que usarlo. Como todo programa, es un balance de cosas que pueden ser opuestas (por ejemplo rapido <> pequeño en memoria). Adicionalmente, si se va a hacer un lenguaje ligeramente parecido a otro, pues como que no tiene mucha gracia! Se que ciertas decisiones pueden afectar el desempeño (hipotetico, porque no lo he probado) de este lenguaje. Lo que interesa es saber si perder X se compensa con creces con ganar Y. Por ejemplo, al usar un recolector de basura se afecta el rendimiento a bajo nivel, pero se compensa con una mayor productividad y simplicidad en el codigo. Lo malo es que se pierda X y lo que se obtiene Y es tan miserable que no valio la pena. Cita:
Código PHP:
Código PHP:
Algunas lecturas que me han convencido: http://programmers.stackexchange.com...ly-a-bad-thing http://lambda-the-ultimate.org/node/2699 Cita:
Cita:
Es mi opinion que es mejor disponer de la opcion mas sana a costa de una potencial degradacion en desempeño para la mayoria de los casos, y elegir la opcion mas eficiente para cuando se necesite, que tener la opcion mas "problematica" por defecto todo el tiempo, y tener que estar chequeando las cosas. Eso es una lata impresionante. Por ejemplo, en python 3 movieron todo a UTF en las cadenas. Una de las razones, es que cuando se hace apps web TODO EL MALDITO TIEMPO surge el error Unicode decode error. Lo malo es que sale en algo tan simple como: Código PHP:
Yo cambio milisegundos en la ejecucion del programa contra horas de depuracion. Lo que indico con la representacion interna es que haya una forma estable y bien delineada de como se mueven los datos, y que se convierta de forma explicita una vez que se toca el mundo exterior. Cita:
Simplemente considero que no tiene presentacion que : Código PHP:
Cita:
-Indicar un valor: Edad=18 -Contadores -Calculos aritmeticos elementales: Total = SubTotal + (SubTotal * (Impuesto/100)) - Descuento Los problemas de desempeño se verian en ciclos cerrados, o en tareas especializadas, donde el programador debe estar mas consiente de lo que hacer. Cita:
Obviamente, si es mas importante la velocidad de la maquina, C o Assembler. Pero creo que casi todos los lenguajes estan diseñados para acelerar al desarrollador...
__________________
El malabarista. Última edición por mamcx fecha: 22-09-2012 a las 02:04:31. |
#6
|
||||
|
||||
Cita:
Como también existe un SO (bueno... en realidad sólo es un kernel) llamado Toro, hecho en Pascal, Free-Pascal para ser más preciso. Ambos proyectos nacidos en mi tierra, lástima que casi completamente parados Y luego algunos fanáticos anti-Pascal dicen que Pascal es sólo para enseñar Saludos, |
#7
|
||||
|
||||
Cita:
__________________
El malabarista. |
#8
|
|||
|
|||
Yo estoy optando por investigar más y adentrarme en el MDD (desarrollo dirigido por modelos), que parece una alternativa interesante, y que a su vez en un futuro quizas muy lejano, si se llega a dar, va a apoyar de forma enorme al programador y/o al arquitecto
__________________
"La información tiene más valor cuando se comparte" |
#9
|
||||
|
||||
Mi sugerencia es que sea orientado a objetos y se admita redefinición de clases (herencia insertada). Ejemplo:
Unit1, creada por el programador Javier, de Quito, en 2014 como parte de la biblioteca "LaboratoryLib":
Unit2, creada por el programador Alfredo, de Monclova, en 2015 como parte de un proyecto particular:
Y ya que entramos en esto, también que las clases no puedan declarar miembros privados (secciones private); en mi opinión, todas las clases deberían poder acceder sin restricciones al contenido que heredan de sus ancestros y la mínima visibilidad de miembros debería ser protected. Y que tampoco puedan estar ni parcial ni totalmente selladas (sealed); ceo que algo no está bien cuando te encuentras con una clase que te impide usar herencia para mejorarla o adaptarla a una circunstancia particular. Y bueno, si además pudiéramos hacer que todas las rutinas (tanto métodos como funciones "sueltas") sean virtuales, sólo agreguémosle la sintaxis Pascal y tendríamos un lenguaje de programación casi perfecto. Lo sé, estos párrafos causarán escozor o risas a los más ortodoxos, pero confío en que el tiempo me dará un poco de razón. |
#10
|
||||
|
||||
Te interesara entonces mirar El diseño del lenguaje GO, en particular la parte sobre interfaces y como GO elimina la herencia para mejorar la capacidad de componer clases, que me parece logra lo que quieres, pero mejor.
Obj-c permite hacer algo parecido, mediante categorias. Python y ruby pueden hacer Monkey Patching. Tambien esta http://lambda-the-ultimate.org/, que es como la comunidad mas interesante que conozco sobre lenguajes, creacion y avances en el tema. Osea, hay mucho por hacer!
__________________
El malabarista. Última edición por mamcx fecha: 05-12-2012 a las 19:21:33. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Creando mi propia página web con servidor propio | jorgegetafe | Varios | 7 | 26-03-2008 04:50:42 |
Abrir archivo propio desde Windows....en programa propio | darkphantom | Varios | 12 | 22-02-2007 04:46:49 |
Estoy creando mi propio google... | El yo | Internet | 3 | 14-04-2006 03:59:07 |
ideas para desarrollo | clanmilano | Varios | 5 | 31-05-2005 14:19:47 |
Ideas | Mistico | OOP | 4 | 27-06-2003 01:22:11 |
|