Creando mi propio lenguaje: Ideas

[mamcx]

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:

# Comentario
int: Int32 #Inicializa en 0
int: Int64 #Inicializa en 0
int: Float #Inicializa en 0.0
num: Num #Inicializa en 0.0, tipo DECIMAL y por defecto
name: Str # UTf8
IsTrue: Bool #Inicializa en false
today: Date = 2002-08-10  #Inicializa en 0000-00-00
hour: Hour = 10:00:00 #24 H format  #Inicializa en 00:00:00
todayHoue: DateTime = 2002-08-10-10:00:00
path: Path = /root  #Inicializa en /
range: [1..2]  #Se debe incializar explicitamente

data: Dict = {num:name}  #Inicializa en {}
dataTyped: Dict<Number,String> = {num:name}
things: List = [num, name, IsTrue] #Inicializa en []
thingsTyped: List<String> = [name]
error?: ERROR #Marca con ? que la vble es nullable. Inicializa en NULL 


Constantes se diferencian porque estan todo en mayuscula:

Código PHP:

PI = 3.1416 


Control:

Código PHP:

for thing in things:
    print(thing)

for i in range(1,10):
    print(i)

for IsTrue: #Reemplaza while.
    print("Yep forever!")

    break

for: #While forecer
    print("Infinite!")

if IsTrue:
    print("Yep") 


Al igual que GO, creo que while es un caso poco usual si las clases se trabajan como enumeradores, asi que no justifica tener un comando aparte.

Texto largo. Soporte a closure, asi que captura las vbles/funciones de su entorno. No hay comillas!

Código PHP:

"""
    Just text [IsTrue]. LLama [funcion()]
""" 


Funciones. Si empieza por "_" es privado, de lo contrario publico. Bloque para declarar vbles y parametros. Me parece mas legible que con (param1:Str,param1:Str,param1:Str,param1:Str,param1:Str,param1:Str,)

Código PHP:

#Private function
def _sample:
    print("hi")

#Public function with return value
def sample : String
var:
    IsOk:Bool
body: 
    return "hi"

#Public function with multiple return values
def sample : Str, Error?
input:
    param1:Str
    param2:Number
    params: *List
body:
    return text:
        Hola [param1] [param2] [params]
    None 


Clases:

Código PHP:

class Person:
    name:Str

    def print: Str
    text:
        Documentacion
    input:
        times:Int32
    body:
        for i in range(1,times):
            print(self.name)
#Herencia
class Moderator:
    embed: Person

mamcx = Moderator()

mamcx.print() #Los metodos de Person se invocan. Pero no existe herencia 


Una de las ideas que me dan vueltas y vueltas, y que tiene que ver con el concepto de mantener integridad en los datos una vez estan en el universo interior, lo llamo PowerType y esta basado en como se define un campo en una tabla.

Por ejemplo:

Código SQL [-]
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price > 0)
);

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:

#PowerType

type Mayuscula:Str
    #Ejecuta al asignar el valor
    def transform: Str
        return self.raw.toUpper()

    def require:Bool,Error?
        return assert(len(self.value)>0, Error("[self.name] no puede estar vacio")

miNombre:Mayuscula = "mario"
print(miNombre)
>> MARIO

miNombre = "" #Genera error: miNombre no puede estar vacio 

#Funcion con PowerType

def sample:
input:
    nombre:Mayuscula
body: 
    print(nombre)

sample("") #Genera error: nombre no puede estar vacio 


P.D: Esto todavia no esta MUY bien pensado. Criticas, sugerencias?

[TiammatMX]

Empezado por mamcx

...P.D: Esto todavia no esta MUY bien pensado. Criticas, sugerencias?

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.

[dec]

¡No te desanimes porque alguien como yo no pueda decir esta boca es mía aquí y ahora!

[LoPiTaL]

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...

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...

A nadie nos gusta el NULL. Sin embargo, existe por obligación, no por necesidad. Tal como planteas, tu RTL debería comprobar cada vez que se asigna un valor a una variable objeto si éste es NULL o no y lanzar una excepción. Esto consume infinidad de recursos, volviendo la aplicación lenta (de hecho FastMM te advierte cuando activas esta opción que tu programa podría volverse lento).

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.

Esto corrobora tu 3ª hipótesis ("Es casi imposible que resulte exitoso") ya que de un plumazo te has eliminado TODAS las aplicaciones que no sean de bases de datos ni muy sencillas. P. ej., si alguien sólo quiere ASCII porque es infinitamente más rápido que UTF, ese programador ya no elegirá tu aplicación. Lo mismo con Integer e int64; y con Float, double y extended (hablando de los tipos en Delphi). También te quitas todos los que estén en el otro extremo, que necesiten mucha precisión y no tengan acceso a tipos de datos de más de 4 bytes.

No hay necesidad de usar herencia para la OO

Esto es cierto, sin embargo la mayoría de lenguajes actuales ya ofrecen alguna implementación de objetos agregados: p. ej. en Delphi mediante interfaces definidas a través de "implements"

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.

Esto es más de lo de antes, vuelves la aplicación lenta y sin opción a que los desarrolladores elijan.

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"

Esto es totalmente correcto! Pero esto es problema del programador, no del lenguaje: p. ej. raise Exception.Create('Error en dirección $FFFFF!') frente a Exception.Create('Se ha leido una variable que era NULL dentro del procedimiento MiMétodo que lo he metido en la unit LaUnit.pas').

Todo esto se puede resumir en: por defecto, lo correcto/obvio no lo mas eficiente. Usar el principio de la menor sorpresa.

Después de todo lo comentado, esto es lo que saldría del lenguaje. Lo que me parece la verdad muy interesante a pesar de todo.
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

[mamcx]

Empezado por LoPiTaL

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.

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.

Empezado por LoPiTaL

Tal como planteas, tu RTL debería comprobar cada vez que se asigna un valor a una variable objeto si éste es NULL o no y lanzar una excepción.

Porque debo hacer la comparacion en cada momento? Eso es lo que quiero evitar! que exista la necesidad de hacer:

Código PHP:

if obj is None:
   print "Invalido" 


Cuando el NULL es el estado de inicializacion por defecto, y se puede asignar NULL a cada cosa en cualquier momento, esos chequeos tienen sentido. Pero si el lenguaje simplemente no lo permite NULL, es identico a hacer un chequeo de tipos:

Código PHP:

name:String
lastName:Date

print name + lastName #Saca error 


Esto se puede comprobar al momento de la compilacion si el lenguaje es tipado.

Algunas lecturas que me han convencido:

http://programmers.stackexchange.com...ly-a-bad-thing

http://lambda-the-ultimate.org/node/2699

An enormous advantage of this is that it allows the type system to statically enforce & check correct usage of nullable values, essentially eliminating "null pointer exception" errors or the equivalent.

El problema en cambio, se daria en un lenguaje de tipos dinamicos, donde una variable puede ser de cualquier tipo (potencialmente null) y ahi si podria caber el problema que mencionas

Empezado por LoPiTaL

P. ej., si alguien sólo quiere ASCII porque es infinitamente más rápido que UTF, ese programador ya no elegirá tu aplicación. Lo mismo con Integer e int64; y con Float, double y extended (hablando de los tipos en Delphi). También te quitas todos los que estén en el otro extremo, que necesiten mucha precisión y no tengan acceso a tipos de datos de más de 4 bytes.

No es mi intencion eliminar la posibilidad de elegir otros tipos de datos y/o estructuras mas adecuadas segun el caso, sino presentar como "defecto" la opcion mas "sana" posible, que da pocas sorpresas.

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:

>>> "ñ" + u"a"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128) 


Que es algo que no necesita el maximo desempeño.

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.

Esto es más de lo de antes, vuelves la aplicación lenta y sin opción a que los desarrolladores elijan.

No he desechado los tipos Float/Int!

Simplemente considero que no tiene presentacion que :

Código PHP:

1.1 + 2.2
>>>3.3000000000000003
>>> (1.1 + 2.2) == 3.3
False 


Esto es una aberracion. El computador no sabe matematicas!. En cambio el tipo decimal:

Decimal “is based on a floating-point model which was designed with people in mind, and necessarily has a paramount guiding principle – computers must provide an arithmetic that works in the same way as the arithmetic that people learn at school.” – excerpt from the decimal arithmetic specification.

El problema del desempeño podria darse si se esta decodificando una imagen, haciendo calculos complejos, criptografia, etc. Pero en mi experiencia, la mayoria de las veces que se usa un numero en un programa es para:

-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.

Empezado por LoPiTaL

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.

Mientras todavia este lenguaje es apenas una idea (que ni se si vera la luz del dia) me parece extraño que consideres que un lenguaje "fuertemente tipado y sin posibilidad de errores" es contrario a "un lenguaje profesional". Un ejemplo notable es haskell que es reconocido por hacer software tremendamente estable, correcto y robusto (principalmente, a que tiene el manejo de tipos mas tremendo que existe). O Erlang que es el unico lenguaje -del que se- lo suficientemente robusto para manejar MILLONES de tareas concurrentes en un SOLO equipo, y se puede reemplazar -modificar a si mismo o por recarga- mientras esta en ejecuccion y sin sacar errores!

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...

[[Delphius]]

Empezado por tiammat

No sabes..., sería TAN hermoso un lenguaje de programación "PASCAL alike" en castellano...

Si que existe.
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,

[mamcx]

Empezado por tiammat

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.

Bueno, me encontre con https://github.com/alcides/pascal-in-python. El parser esta hecho en python y el compilador (backend) es LLVM, que es de lo mas avanzado que hay. Volverlo español se ve trivial (aunque soy de la idea que es mejor que un lenguaje sea en ingles).

[[fer21unmsm]]

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

[[Al González]]

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":

Código Delphi [-]
TClaseX = Class (ClasePadreCualquiera)
...
End;

// Clase derivada 1
TClaseD1 = Class (TClaseX)
...
End;

// Clase derivada 2
TClaseD2 = Class (TClaseX)
...
End;

Unit2, creada por el programador Alfredo, de Monclova, en 2015 como parte de un proyecto particular:

Código Delphi [-]
TClaseX = Overridden Class (Unit1.TClaseX)
...{ Nuevos campos / métodos / propiedades para TClaseX que sus actuales descendientes 
     (TClaseD1 y TClaseD2) heredarán en automático.  No es crear otra clase más, sino 
     "insertarle" nuevos elementos (incluyendo redefinición de métodos) a una ya existente, 
     sin tocar su código original (Unit1) e impactando a cualquier clase ya escrita que derive 
     de ella. }
End;

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.

[mamcx]

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!