¿Por qué Spring4D no es incorporado nativamente?

[mamcx]

Empezado por AgustinOrtu

La gente de mente abierta esta entretenida con otros lenguajes, son poquísimos los casos de gente asi usando Delphi, menos aun los que desarrollan frameworks y extienden el lenguaje; es para ellos que realmente las características "modernas" son útiles.

Todo lo que mencionas esta muy bien, pero ejemplifican también el problema, en especial los ejemplos de codigo que pones.

Es cierto que los lenguajes tienden a converger en una serie de características comunes. Ademas, en cosas como Java/C#/C++ se tiende a "meter de todo" precisamente porque son lenguajes de uso amplio y no tienen un nicho tan concreto; pero a la vez, sufren precisamente por el exceso de complejidad y porque el lenguaje se "fragmenta en micro-dialectos" que no tienen un uso amplio y terminan causando que se pierda la claridad y el propósito de los mismos.

Aqui hay un ejemplo de gente que se movio de Scala a Go (Scala es el lenguaje que mezcla de todo, y GO es un lenguaje simplista a morir):

https://movio.co/blog/migrate-Scala-to-Go/

El punto clave es que debido a que Scala (y C++, Java/C# en menor medida) carece de una vision cohesiva es muy complejo de operar y el costo de mantener el codigo se vuelve alto, ya que unos usan imperativo aqui, otros funcional alla, otros reactivo, otros OO, etc. En cambio, una vez que has visto un codigo en GO/Python, has visto como se hace todo.

Pascal tiene ese atributo. Tanto asi, que su creador cuando creo Oberon/Modula lo simplifico aun mas!

---

El tema es que si simplemente ponen el tipo Nullable<T> y ya están "balkanizando" (o sea, fragmentando) el lenguaje. Para hacerlo efectivo, si fueran aguerridos, podrían hacer como Apple que re-anota todo el codigo viejo para que queda claro que se espera que es o no nullable, haciendo universal el cambio (porque Nullable<T> es un cambio estructural enorme!).

Osea, la incógnita es como introducir mejoras al lenguaje/runtime/librerias de forma "idiomática pascal" y no simplemente haciendo que Delphi tenga "un poco de Scala aqui, otro de C#, otro de ML por acá" etc y se desdibuje su espíritu.

No es imposible. La gente de GO tiene un metodo muy practico:

https://golang.org/cmd/gofmt/

Es un formateador de codigo, que no solo lo pone "bonito" sino que de forma automática se encarga de migrar de forma confiable código de un api/estilo a otro. Es MUY confiable, al grado que la gente que usa GO lo mantiene prendido todo el tiempo y permiten que haga cambios a todo el codigo, porque es una herramienta que no es de terceros, y está EXPRESAMENTE diseñada para poder mover codigo fuente hacia adelante, modernizando.

También en C++ han hecho actualizaciones tremenda las clases bases, moviéndolas de un API/código viejo a nuevo, manteniendo una fidelidad en la compatibilidad.

Asi, las mejoras no solo se incorporan de forma solida, sino que se distribuyen a los programadores de forma uniforme en la medida que nuevas versiones surgen.

---

Con respecto a los ejemplos que das, teniendo en cuenta que soy alguien que usa de forma profesional muchos lenguajes (incluyendo funcionales), demuestra el porque el tiro no es por donde lo pintas. El codigo que pusiste:

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;

Es mucho mas claro tal cual. Delphi no es un lenguaje funcional, no tiene ni la maquinaria ni la sintaxis apropiada, y para rematar, el código inicial es mas corto, claro y de mayor desempeño que el propuesto. Además, para que funcione bien en forma funcional, el compilador tendria que implementar tail cail elimination y otras monerías, de lo contrario, no solo sera mas lento, sino que se comerá el stack muy rápido.

Y el código imperativo tiende a ser mucho mas claro que el funcional, EN ESPECIAL, mientras más complejo.

--

Hay que entender que es mejor ser fiel al espíritu de cada lenguaje, que intentar cambiarlo. NO significa, que no se puedan mejorar e incorporar ideas, sino que hay que hacerlas de forma idiomática, y al final, reconocer que si rompen demasiado el paradigma entonces lo que nos esta gritando la evidencia es que hay que usar OTRO lenguaje. "Usar la herramienta adecuada para el trabajo".

[Casimiro Noteví]

Empezado por mamcx

"Usar la herramienta adecuada para el trabajo".

Eso lo resume todo.

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