¿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".