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:
|
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).
Cita:
|
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.
Cita:
|
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"
Cita:
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.
Cita:
|
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').
Cita:
|
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