¿Por qué Spring4D no es incorporado nativamente?

jhonny · #1 29-01-2017

Hola a todos,

A raiz del mensaje puesto por Agustín en http://www.clubdelphi.com/foros/show...718#post512718 y de otros más, me ha surgido la siguiente duda, aunque hoy me animé a ponerle en su propio hilo... y aquí va.

Spring4D tiene cosas que uno quisiera que Delphi tuviera de forma nativa, como los nullables, su funcionalidad con enumeradores, filtros en los ForI, su capacidad de trabajar con ejecución retardada y en fin... muchas cosas más. Entonces me pregunto, ¿Por qué no incluir Spring4D nativamente si al final están desarrollando cosas que naturalmente van a terminar llegando a lo mismo?, ¿Esto acaso es un tema de licencia o es otra cosa?.

Reasen · #2 29-01-2017

Hay bastantes librerías que deberían estar nativamente incorporadas como por ejemplos algunas de RRUZ que fixean fallos muy notables en las skins de Delphi.

Supongo que tiene que ser algún asunto de licencias o que aún no tengan comprobado que no causa conflictos con ningún otro componente.

[AgustinOrtu] · #3 29-01-2017

Yo dejaria al proyecto como esta y quien lo quiera usar, que lo use. Seguramente haya conflictos de licenciamiento o intereses, o simplemente la gente detras de Spring4D lo quiere asi. Lo que menos querria es que se arruine este proyecto por una estupidez asi

Lo que si estaria muy bien es que lo incluyan en GetIt y en Delphinus (ambos gestores de paquetes)

He dejado abierta una consulta en su foro, veremos que dicen

[AgustinOrtu] · #4 29-01-2017

La VCL Style Utils de Rodrigo Ruz no fueron totalmente incorporadas en Delphi; solamente una pequeña parte de ella fue licenciada a Embarcadero, para solucionar el problema de aplicar los estilos a los cuadros de dialogo (open/save, etc) y para el componente TWebBrowser

Mas info aca

Ahora bien, esto lo hicieron solo para Delphi 10 Seattle en adelante; es decir, todas las versiones anteriores se quedaron sin nada. Eso no me parece justo. Las Vcl Style Utils creo que funcionan desde versiones anteriores sin ningun problema, desde XE2.

mamcx · #5 29-01-2017

Cita:

Empezado por jhonny

Entonces me pregunto, ¿Por qué no incluir Spring4D nativamente si al final están desarrollando cosas que naturalmente van a terminar llegando a lo mismo?, ¿Esto acaso es un tema de licencia o es otra cosa?.

Una razón más simple es porque Delphi no es asi. Lo que describes implica que te serviria mas usar F#, ELM, Elixir o algo similar.

Por ejemplo, en el caso de los nullables. Eso es algo que si se incorpora como libreria tendria un efecto marginal en la calidad del código. Eso es algo que se debe tener a nivel del lenguaje para recibir sus frutos. De lo contrario, solo sera "algo interesante" en unas pocas lineas de codigo para unos pocos casos de usos usado por pocos desarrolladores.

Es por eso que los nulos se consideran el "error del billon de dolares". La unica forma (sana) es ELIMINAR POR COMPLETO los nullos.

Eso no sirve en Delphi, ya tiene demasiada historia.

Igual, el resto de cosas son mas de lenguajes funcionales, y una vez que un lenguaje se estabiliza en un paradigma, intentar alterarlo solo hace todo mas confuso.

Es por eso que es falso que "todos los lenguajes son mas o menos lo mismo" y que "no hay un lenguaje mejor que otro".

[AgustinOrtu] · #6 29-01-2017

Como comentaba en el otro hilo, el tipo "Nullable<T>" lo van a meter en Delphi. El roadmap estima que para el 2018

A mi no me parece mal que se implementen caracteristicas de lenguajes funcionales. En realidad no es posible replicar lo mismo que en los lenguajes funcionales, pero si tomar las ideas. Ya es un hecho comprobado que para muchas cosas funcional es una forma muy limpia de programar, donde se separa realmente "el como" de "que se hace". Hay muchas ideas interesantes dentro de funcional, como considerar las funciones como "first-class citizen", composicion, inmutabilidad...

A muchos Delphinianos no les gusta/interesa esto. Alegan que es la "C#-sizacion" de Delphi, ya que esta tomando muchas ideas de C#. Sin ir mas lejos, Spring4D es inspirado (por no decir, "copiado") de C#. Nada mas mirar la interface IEnumerable<T> de Spring4D y la de .net. La unica diferencia es que toda la "magia" de IEnumerable<T> en .net se hace con metodos de extension, y como en Delphi no los tenemos, se incluyen todos los metodos en la interface

El gran problema es que en el ecosistema Delphi esta lleno de "dinosaurios" (no se me enojen, por favor). A ver, yo no considero "dinosaurio" a alguien por la edad, sino por su mentalidad. La mayoria de los programadores Delphi son dinosaurios, de mente cerrada, que no quieren aprender o cambiar sus habitos, que sigen pensando como en los 90 y no como se diseña software hoy. Simplemente no van a cambiar su forma de pensar porque lo que hicieron "funciona"

La gente de mente abierta esta entretenida con otros lenguajes, son poquisimos los casos de gente asi usando Delphi, menos aun los que desarrollan frameworks y extienden el lenguaje; es para ellos que realmente las caracteristicas "modernas" son utiles.

Como comente en otro hilo hace poco, sin metodos anonimos, atributos, genericos y la RTTI mejorada es imposible un framework como Spring.

Ahora que esto sea usado por unos pocos? Estoy de acuerdo, es el nicho dentro del nicho de Delphi

jhonny · #7 29-01-2017

Cita:

Empezado por AgustinOrtu

El gran problema es que en el ecosistema Delphi esta lleno de "dinosaurios" (no se me enojen, por favor). A ver, yo no considero "dinosaurio" a alguien por la edad, sino por su mentalidad. La mayoria de los programadores Delphi son dinosaurios, de mente cerrada, que no quieren aprender o cambiar sus habitos, que sigen pensando como en los 90 y no como se diseña software hoy. Simplemente no van a cambiar su forma de pensar porque lo que hicieron "funciona"

La gente de mente abierta esta entretenida con otros lenguajes, son poquisimos los casos de gente asi usando Delphi, menos aun los que desarrollan frameworks y extienden el lenguaje; es para ellos que realmente las caracteristicas "modernas" son utiles.

Como comente en otro hilo hace poco, sin metodos anonimos, atributos, genericos y la RTTI mejorada es imposible un framework como Spring.

Ahora que esto sea usado por unos pocos? Estoy de acuerdo, es el nicho dentro del nicho de Delphi

Decir, que estoy muy de acuerdo con todo lo que ha expresado Agustín, incluso con lo que comenta al principio sobre sus razones para que Spring4D no sea incluido nativamente y que sea agregado en el Getit. Quisiera hacer una anotación más y es que los que entran nuevos al lenguaje deben tener más herramientas para aprender a usar las nuevas características, puesto que si entran a aprender Delphi siempre se encuentran con aquellas técnicas 90venteras que menciona Agustín.

[AgustinOrtu] · #8 29-01-2017

Hola Mario,

Cita:

Es por eso que los nulos se consideran el "error del billon de dolares". La unica forma (sana) es ELIMINAR POR COMPLETO los nullos.

Eso no sirve en Delphi, ya tiene demasiada historia.

Igual, el resto de cosas son mas de lenguajes funcionales, y una vez que un lenguaje se estabiliza en un paradigma, intentar alterarlo solo hace todo mas confuso.

Estoy de acuerdo con el error de billon de dolares. El tema es que para ciertos casos puede ser util. Muchos diran que se puede resolver usando clases (el null object), es decir crear una clase en donde este definido el comportamiento "nulo" (muchas veces es "no hacer nada"). Esto me parece muy bien y de hecho lo he usado muchisimo. Pero en ciertos casos resulta engorroso de escribir, leer, entender: (esto tambien toma ideas de primitive obsession)

Código Delphi [-]procedure DoQuery;
var
  DateForm, DateTo: TDateTimeClass;
begin
  DateFrom := TDateTimeClass.CreateOrDefault(Edit1.Text);
  DateTo := TDateTimeClass.CreateOrDefault(Edit2.Text);
  Query.SQL.Text := 'SELECT * FROM Orders WHERE Date BETWEEN :From AND: :To ';
  Query.ParamByName('From').AsDateTime := DateFrom.Value; 
  Query.ParamByName('To').AsDateTime := DateTo.Value; 
end;

TDateTimeClass parseara el string y creara la instancia de TDateTime, y la hace accesible a partir de la propiedad .Value. Una instancia de TDateTimeClass garantiza que el valor de TDateTime es correcto dentro de las reglas de negocio.

Esto lleva muchos problemas como determinar cual es el valor mas adecuado para representar el "nulo". Ademas, la idea del nulo es asignar un valor para que "de manera conveniente" cuando se use Value me de un valor que me sirva como "nulo". En caso de fechas podria devolver la minima fecha representable. Entonces en el SQL me quedaria un between 31/12/1899 and 31/12/1899, lo que no me devuelve el resultado esperado. Entonces tengo que meter otro constructor especificamente para las "FechaHasta" que asigne como nulo por ej la fecha 31/12/2200 23:59:59:999.

Ya no son una sino dos clases para una "pavada". Ademas tengo que usar try-finally cuando antes no era necesario, para liberar memoria. Si usara interfaces es cierto, me ahorro el try-finally, pero la complejidad sigue aumentando y ademas eso es cada vez mas y mas overhead. Y por ultimo el .Value "contamina la API", ya que en Delphi no podemos sobrecargar los operadores en clases (ok, se puede usando features que "no existen")

El Nullable<T> como "first type citizen" soluciona este problema ya que no contamina la API y ademas como es un record y con sus operadores sobrecargados, lo hace tan limpio que no se nota. Simplemente te ayuda a prevenir errores tontos y dificiles de encontrar (bueno quiza con un Unit Test lo detectes en segundos) porque te olvidaste de asignar un valor primitivo, o justo de lo contrario, de "limparlo"

Aca tambien tenemos mas influencias de programacion funcional en Delphi (por ejemplo: "Monads" o el "Either")

Yo creo que la era en la que OOP debe ser la respuesta a todo ha llegado a su fin. Si un lenguaje queda "atado" o estabilizado a un paradigma no podria considerarlo un lenguaje "moderno". Por suerte no es el caso de Delphi. En Delphi podes programar estructurado, procedimental, orientado a objetos, orientado a aspectos, y "emular" o tomar ideas de funcional

Funcional realmente hace el codigo mas facil de entender, de leer, de mantener y de extender porque separa el "que se hace" del "como se hace". Un ejemplo pavo, dadas estas declaraciones:

Código PHP:


			
uses

  System.SysUtils,

  Spring,

  Spring.Collections;



type

  Customer = record

  private

    FName: string;

    FAge: Integer;

  public

    class function Create(const Age: Integer; const Name: string): Customer; static;

    property Age: Integer read FAge;

    property Name: string read FName;

  end;



function Customers: Spring.Collections.IEnumerable<Customer>;

var

  I: Integer;

  List: IList<Customer> absolute Result;

begin

  List := TCollections.CreateList<Customer>;

  for I := 0 to Random(100) do

  begin

    if Odd(I) then

      List.Add(Customer.Create(I, 'Cliente # ' + I.ToString))

    else

      List.Add(Customer.Create(I, 'Customer # ' + I.ToString))

  end;

end;

La forma "tradicional" imperativa de mostrar en pantalla los clientes con edad entre 9 y 23 podria ser:

Código Delphi [-]procedure Main;
var
  Each: Customer;
begin
  Writeln('Clientes con Edad entre 9 y 23');

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

Si ahora tambien tengo que incluir en el resultado aquellos que tienen Edad 4, tengo que modificar el condicional, haciendolo cada vez mas complejo:

Código Delphi [-]procedure Main;
var
  Each: Customer;
begin
  Writeln('Clientes con Edad entre 9 y 23, o bien Edad = 4');

  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;
end;

Y si ahora necesito tambien solo los que el nombre es "ingles" ("Customer en lugar de "Cliente")

Código Delphi [-]procedure Main;
var
  Each: Customer;
begin
  Writeln('Clientes con Edad entre 9 y 23, o bien Edad = 4, y nombre ingles');

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

Y esta todo mezclado: la data con las transformaciones filtros y operaciones esta todo entremezclado entre si. Y por mas que refactorize agregando condiciones, no cambia tanto porque tendria muchas condiciones.

Por suerte la interface IEnumerable<T> define un metodo Where que recibe un predicado<T>. Un predicado<T> es metodo anonimo que retorna Boolean y recibe como argumento un "T". Basicamente es esto:

Código Delphi [-]function(const Arg: T): Boolean;
begin
  Result := evaluar Arg
end;

Podemos escribir entonces..

Código Delphi [-]procedure Main;
begin
  Writeln('Clientes con Edad entre 9 y 23');

  Customers
    .Where(
      function(const c: Customer): Boolean
      begin
        Result := (c.Age > 9) and (c.Age < 23);
      end)

    .ForEach(
      procedure(const c: Customer)
      begin
        Writeln(Format('%s - Edad: %d', [c.Name, c.Age]));
      end);
end;

Ja. No cambio mucho, no? Muchos me diran, ok cambiaste el for in, escribiste un monton de codigo mas y es lo mismo: las condiciones sigen juntas. Bueno, bien se pueden concatenar las invocaciones a Where si quisiera. Pero el problema sigue igual: datos y operaciones mezcladas. Pero que tal esto:..

Código PHP:


			
function OlderThan(const Age: Integer): TPredicate<Customer>;

begin

  Result := function(const c: Customer): Boolean

            begin

              Result := c.Age > Age;

            end

end;



function YoungerThan(const Age: Integer): TPredicate<Customer>;

begin

  Result := function(const c: Customer): Boolean

            begin

              Result := c.Age < Age;

            end

end;



function Aged(const Age: Integer): TPredicate<Customer>;

begin

  Result := function(const c: Customer): Boolean

            begin

              Result := c.Age = Age;

            end

end;



function NameStartsWith(const Text: string): TPredicate<Customer>;

begin

  Result := function(const c: Customer): Boolean

            begin

              Result := c.Name.StartsWith(Text, True);

            end

end;



function NameIsEnglish: TPredicate<Customer>;

begin

  Result := NameStartsWith('Customer');

end;



procedure PrettyPrint(const c: Customer);

begin

  Writeln(Format('%s - Edad: %d', [c.Name, c.Age]));

end;

Procedimientos o funciones "sencillas", separadas, reusables, faciles de entender, "parametrizables" si es necesario, y se pueden "componer", asi:

Código Delphi [-]procedure Main;
begin
  Writeln('Clientes con Edad entre 9 y 23');

  Customers
    .Where(OlderThan(9))
    .Where(YoungerThan(23))
    .ForEach(PrettyPrint);
end;

Quiero filtrar tambien solo los que tienen nombre "en ingles"? No hay problema:

Código Delphi [-]procedure Main;
begin
  Writeln('Clientes con Edad entre 9 y 23');

  Customers
    .Where(OlderThan(9))
    .Where(YoungerThan(23))
    .Where(NameStartsWith('Customer')) // ambas alternativas validas de hecho, NameIsEnglish
    .Where(NameIsEnglish()) // esta implementada usando NameStartsWith invocandola como NameStartsWith('Customer')
    .ForEach(PrettyPrint);
end;

Y si quiero meter todo dentro de un solo predicado, se pueden usar patrones: Specification Pattern

Código PHP:


			
uses

  ...,

  Spring.DesignPatterns;



...



function CustomerFilter: TSpecification<Customer>;

var

  s: TSpecification<Customer>;

begin

  s := OlderThan(9);

  Result := (s and YoungerThan(23) or Aged(4)) and NameIsEnglish;

end;



procedure Main;

begin

  Writeln('Clientes con Edad entre 9 y 23 o Edad = 4, y nombre en ingles');



  Customers

    .Where(CustomerFilter())

    .ForEach(PrettyPrint);

end;

En Spring otra vez se "abusa" de la sobrecarga de operadores para poder usar la sintaxis "and", "or", "not". Aun asi, el lenguaje limita un poco y por eso es necesaria la variable "s" para iniciar "la cadena" en la funcion CustomerFilter. Como TSpecification es un record que tiene sobrecargado el operador Implicit para convertirlo directamente a un TPredicate, la llamada al Where es posible. Esto tambien se puede hacer:

Código PHP:


			
procedure Main;

var

  s: TSpecification<Customer>;

begin

  Writeln('Clientes con Edad entre 9 y 23 o Edad = 4, y nombre en español');



  s := TSpecification<Customer>(OlderThan(9));

  Customers

    .Where(s and YoungerThan(23) or Aged(4))

    .Where(not TSpecification<Customer>(NameIsEnglish()))

    .ForEach(PrettyPrint);

De nuevo, la sintaxis demasiado "verbose" de Pascal, y el tipificado fuerte me obliga a "mucha ceremonia" pero creo que la idea se entiende

[AgustinOrtu] · #9 29-01-2017

Por cierto, este fork en GitHub habilita el soporte para el gestor de paquetes Delphinus, ya que como me respondieron, es necesario que el proyecto este alojado en GitHub

mamcx · #10 30-01-2017

Cita:

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 Notevi · #11 30-01-2017

Cita:

Empezado por mamcx

"Usar la herramienta adecuada para el trabajo".

Eso lo resume todo.

[AgustinOrtu] · #12 30-01-2017

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 Notevi · #13 30-01-2017

Cita:

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 · #14 30-01-2017

Cita:

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).

Cita:

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

Cita:

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] · #15 30-01-2017

Cita:

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

Cita:

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