FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
¿Por qué Spring4D no es incorporado nativamente?
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?.
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#2
|
|||
|
|||
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. |
#3
|
||||
|
||||
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 |
#4
|
||||
|
||||
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. |
#5
|
||||
|
||||
Cita:
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".
__________________
El malabarista. |
#6
|
||||
|
||||
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 |
#7
|
||||
|
||||
Cita:
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!" http://www.purodelphi.com/ http://www.nosolodelphi.com/ |
#8
|
||||
|
||||
Hola Mario,
Cita:
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:
Si ahora tambien tengo que incluir en el resultado aquellos que tienen Edad 4, tengo que modificar el condicional, haciendolo cada vez mas complejo:
Y si ahora necesito tambien solo los que el nombre es "ingles" ("Customer en lugar de "Cliente")
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:
Podemos escribir entonces..
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:
Quiero filtrar tambien solo los que tienen nombre "en ingles"? No hay problema:
Y si quiero meter todo dentro de un solo predicado, se pueden usar patrones: Specification Pattern Código PHP:
Código PHP:
Última edición por AgustinOrtu fecha: 29-01-2017 a las 23:29:46. |
#9
|
||||
|
||||
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
|
#10
|
||||
|
||||
Cita:
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:
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".
__________________
El malabarista. Última edición por mamcx fecha: 30-01-2017 a las 00:20:17. |
#11
|
||||
|
||||
#12
|
||||
|
||||
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:
vs
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 |
#13
|
||||
|
||||
Cita:
Creo que cualquiera "novato" verá mucho más fácil y legible la versión delphi. Es mi opinión |
#14
|
||||
|
||||
Cita:
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:
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:
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:
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:
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!
__________________
El malabarista. Última edición por mamcx fecha: 30-01-2017 a las 18:01:09. |
#15
|
||||
|
||||
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:
Última edición por AgustinOrtu fecha: 30-01-2017 a las 22:33:26. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
|