¿Por qué Spring4D no es incorporado nativamente?

[[AgustinOrtu]]

Mario, hola nuevamente

Puedo aceptar algunas de las cosas que comentas, pero en cierto punto entra un poco lo personal, y volviendo sobre lo mismo:

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. Es mas pareciera que estoy leyendo "plain english", es decir, como si estuviera leyendo una oracion. Pero bueno es una opinion personal

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

Por ejemplo, los dependency injection container tienen una implementacion muy intricada, que trabaja con RTTI, con assembler y mil yerbas mas. Pero el uso es sencillo.

Sin ir muy lejos, las propias colecciones son complicadas. Un "simple" TList tiene dentro una docena de metodos que no tengo ni idea de como ni para que se usan (ni me interesa).

La Vcl es otro gran ejemplo. A veces lo unico que hacemos es cambiar una propiedad pero por dentro se esta mandando un mensaje a Windows para que deshabilite ese boton y luego la Vcl captura en su bucle de mensajes la notificacion que le manda al boton para que se repinto como deshabilitado

La conclusion que hoy mas que "que lenguaje sabes" es "que framework sabes" porque han evolucionado tanto y hacen las cosas mucho mas sencillas que son mas importantes que ser un experto en el "lenguaje"

Sobre el abuso de que se crean "micro-dialectos", si es cierto, pero eso pasa sin necesidad de introducir "codigo de afuera", o "ideas de afuera". Cada cual programa como se le da la gana a menos que se establezcan reglamentaciones o estandares. Con solo el lenguaje en la mano ya es suficiente para que nazcan los "micro-dialectos", incluso con lenguajes "poco abusables"

En el momento que se introduce una biblioteca externa (cualquier componente de lo que sea, controles visuales, criptografia, etc) ya es en si mismo un micro dialecto. "Ah ok pero yo siempre use Synapse, no uso Indy". "Ah pero yo uso la DBGrid de las RXLib no de las Jedi". "Ah pero yo SuperObject para manejar json, no XXX"

En fin, el objetivo que siempre persigo (y croe que todos) es generar codigo que hoy sea facil de escribir, y que mañana sea facil de leer, corregir, extender o reutilizar en otro lado. A veces con solo lo que te da el lenguaje de fabrica no es posible

[Casimiro Noteví]

Empezado por AgustinOrtu

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. Es mas pareciera que estoy leyendo "plain english", es decir, como si estuviera leyendo una oracion. Pero bueno es una opinion personal

A mí no me lo parece, me recuerda python, eso no es delphi.
Creo que cualquiera "novato" verá mucho más fácil y legible la versión delphi.
Es mi opinión

[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!

[[AgustinOrtu]]

Empezado por mamcx

[...]

Por cierto te agradezco que te hayas tomado el tiempo para esta pequeña discusion, me ha parecido muy interesante todo lo que has dicho y ya me he agendado los links que comentas para poder leerlos mas tarde

Totalmente de acuerdo con que Delphi deberia tener una sintaxis lambda que no requiera tanta ceremonia. De hecho esta en un feature request https://quality.embarcadero.com/browse/RSP-13339

Aca hay una lista de las "caracteristicas mas pedidas". Algunas estan muy bien, pero es una recopilacion que hizo un simple usuario, puede haber puntos de inflexion: https://plus.google.com/+HoracioJose...ts/eMX4uqpbxEa


Edito: Por cierto, esto si que es posible

Empezado por mamcx

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

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

Aunque los genericos de Delphi no son lo mejor porque no soportan varianza ni covarianza y a veces te obliga a hacer algunos hard-cast medios feos