¿Por qué Spring4D no es incorporado nativamente?

[mamcx]

Empezado por AgustinOrtu

Código Delphi [-]
  for Each in Customers do
  begin
    if ((Each.Age > 9) and (Each.Age < 23)) or (Age = 4) then
      Writeln(Format('%s - Edad: %d', [Each.Name, Each.Age]));
  end;

vs

Código Delphi [-]
  Customers
    .Where(OlderThan(9))
    .Where(YoungerThan(23))
    .ForEach(PrettyPrint);

A mi me parece muchisimo mas sencillo y legible la segunda opcion, porque el donde viene la data, del como se filtra, y de lo que se hace esta separado.

El resultado final se ve bien. Pero llegar a el, es lo que no es tan simple en un lenguaje como Delphi. Eso es lo que apunto como que resulta mas complicado, por una ganancia relativamente pequeña.

Aqui el tema es como hacer composición y abstracción de código:

Si puedo tener una funcion "OlderThan" que sea genérica a todo lo que tenga un campo Age, entonces construirla y reusarla tiene sentido, pero tal como apuntas:

Código Delphi [-]
function OlderThan(const Age: Integer): TPredicate; 
begin 
  Result := function(const c: Customer): Boolean 
            begin 
              Result := c.Age > Age; 
            end 
end;

Hacer esto solo para Customer es una ganancia escasa, y no compensa la complejidad y código extra. Si fuera para TODO lo que tiene *age*, es un tema distinto.

Es una ganancia para *ti*, y no discuto que eso sea util, sino que a nivel de lenguaje, es una ganancia escasa. El chiste es que si hay algo mejor, que se distribuya a todos!

Delphi, al igual que la mayoría, sino todos, de los lenguajes OO tiene el problema que no puede hacer generics de forma horizontal (a través de TODAS LAS CLASES), sino vertical (a través DE TODOS LOS DESCENDIENTES), así que lo más cercano es tener una clase padre con "Age" y derivar de ahí. Esto rápidamente deja de ser práctico.

Esto se conoce como el problema de la expresividad, e implica que un lenguaje tipado tiene restriccion en que se puede generalizar. Aqui es donde un lenguaje con tipos dinámicos como python tiene la ventaja (para el caso de uso que planteas). Para un lenguaje como Delphi, tendria que tener multi-metodos o un sistema de tipos estáticos estructural (Delphi tiene uno nominal. Por lo que significa que NO SE PUEDE HACER ESTA MEJORA).

Empezado por AgustinOrtu

En cuanto a la complejidad "interna" del código es un aspecto que discrepo. Que la implementacion sea "complicada" pero ofrece una interfaz amigable y sencilla me parece de lo mas bien.

EL problema no es cuánto codigo, métodos o clases existan. Es que costo en runtime y complejidad inesperada estos agregan.

Existen 2 tipos de complejidad:

- Complejidad esencial (la que surge de forma natural ante un problema grande, y que es natural y hasta deseable)
- Complejidad accidental (la que es inesperada, no deseable y aumenta la probabilidad de bugs, afecta desempeño, complica el debugging, la comprensión, etc).

Que quizas hayas leido en esta excelente charla de "Simple made easy".

Asi, que si agregar nuevas funcionalidades me trae un mayor costo en eficiencia o complica mi uso de esa funcionalidad, entonces no es deseable. Eso ocurre si esa funcionalidad empieza a romper con el paradigma del lenguaje, o requiere un mayor costo de compilacion, de runtime o ambos (como por ejemplo, el soportar funciones recursivas estilo funcional, que implican un compilador con TAIL CAIL ELIMINATION, requieren prácticamente un GC y otras cosas que alteran seriamente la semántica del lenguaje!).

Ademas, si el codigo cambia de "estilo" eso afecta la legibilidad y su comprension. Como han aprendido los que usan Haskell, ser demasiado generico y abstracto choca con la forma general de pensar humana y afecta la capacidad del programador de usarlo de forma efectiva y el alcance del lenguaje.

Escribir mas codigo es poca cosa vs menos codigo que se vuelve obtuso.
----

Hay muchas cosas de los lenguajes funcionales que son geniales, pero que no pasan limpiamente a Delphi. Traen ventajas, pero implican hacer cambios muy fuertes o terminan siendo usado por unos pocos aguerridos. Ahora, si queremos ver que se puede incorporar a Delphi, que no es alienigena y que trae ventajas, entonces hay que mirar que se hace en lenguaje *de su mismo paradigma*, como GO (que es MUCHO mas simple y limitado que Delphi), Rust/C++, que tienen el lema de "Zero-Cost abstraction, o no pagas por aplicar una abstracción":

https://blog.rust-lang.org/2015/05/11/traits.html

C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use, you couldn’t hand code any better.

-----

He pensado un poco, y esto es lo que se me ocurre:

- El permitir una experiencia fluida para hacer query es una de las cosas más difíciles de agregar a un lenguaje. Lo ideal aquí sería que agregaran algo como LINQ.
- Un sistema de macro, no horrible como el de C++, sino chevere como el de NIM o Elixir haría posible y elegante agregar muchas monerias sin romper el paradigma, permitiendo incluso reescribir código de apariencia funcional a imperativo (que es lo que Delphi esta hecho para operar).

Estas 2 cosas resuelven en gran medida todo el tema, y son soluciones probadas. Basicamente, se podria dejar aquí y es suficiente.

- Una sintaxis extra para hacer lambda mas corta, pero eso choca con el estilo verbosed de pascal, asi que no creo que se llegue a eso.
- Re-utilizar las interfaces para hacer viable el uso de codigo generico que cruza entre clases sin recurrir a herencia, estilo "traits" como en Rust, asi yo podria hacer esto:

Código Delphi [-]
type Aged = Interface
   property Age:Int

 function(const c: Aged): Boolean 
            begin 
              Result := c.Age < Age; 
            end

Pero el problema es que el casting no deberia causar un down/up-cast sino que simplemente deberia ser un "shadow" que no cause overhead al pasar las variables. Esto probablemente seria mas complicado, y quizas los macros terminan siendo una solucion mas "simple" de operar aunque implementarlo sea mas complejo al inicio.

- Hay muchas otras cosas, pero todo demuestra que es muy complejo redirigir un lenguaje una vez toma vuelo. LLevo un rato diseñando un lenguaje personal y es increible lo complicado que resulta!