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