style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

¿Por qué mueren los lenguajes de programación?


Vienen a mi mente varias respuestas:

  • Muy pocos los conocen
  • Son muy dificiles de aprender y utilizar
  • Tienen un ciclo de vida muy límitada
  • No existe documentación adecuada y fiable
  • No los actualizan
  • Ya nadie los usa
  • Son muy primitivos para la época o simplemente existen mejores alternativas

Sin embargo muchos lenguajes considerados "muertos" como C, Cobol, Visual Basic 6.0 siguen utilizándose.

Por ejemplo es común encontrar anuncios de trabajo buscando programadores en Cobol y C aunque estos ya estén "declarados muertos"
por los desarrolladores y programadores actuales.

En las escuelas (preparatorias técnicas y/o Universidades) se sigue usando C para enseñar programación básica.

A su vez lenguajes de programación como PHP y Visual Basic 6.0 se resisten a "morir en paz", no permiten que los lenguajes nuevos les ganen la batalla.

A pesar que existen otras alternativas (¿mejores?, es a criterio de cada quien) como JSP, C#, VB .Net, Ruby,etc. siguen estando en pie (no sé si para bien o para mal).

Creo que en ese aspecto Java sigue en la delantera, conforme pasa el tiempo surgen más "actualizaciones y mejoras",
sin embargo leí en un artículo que muchos programadores coincidian en que
"el número de librerías y clases que crece de manera inesperada puede ser un arma de doble filo para los programadores ".

Cuando un lenguaje de programación ha dejado de ser útil para los programadores y para quien los desarrollo es entonces cuando empieza a morir:

Lenguaje muerto= ya nadie lo usa y/o pocos lo conocen+ documentación inadecuada y poco fiable sobre su uso+nuevas y mejores alternativas

No me sorprendi con la noticia de que JavaFX habia muerto creo que fue aceptable la decisión de descontinuarlo.

¿La razón?, lamentablemente
(a mi criterio) no existia documentación apropiada para que los programadores se motivaran a usarlo en sus proyectos, yo intenté usarlo para un proyecto
que tenía, pero llegué a la conclusión (después de algunas pruebas) ... ¿para qué usarlo? si con JSP (Spring Framework) y AJAX puedo conseguir mejores resultados.

Además existen otras alternativas como Ruby o Python que si han conseguido llamar la atención de los programadores
tal vez por su síntaxis sencilla o por que si existe documentación fiable y adecuada para empezar a programar.

Para concluir, creo que un lenguaje muere cuando ya a nadie le interesa y no existe motivación por parte de los desarrolladores en difundirlo. Es mejor dejarlo descansar y seguir hacia delante.

"El problema con los programadores es que nunca sabes lo que están haciendo hasta que es demasiado tarde."

– Seymour Cray

Sitios de interés:

Mi otro blog: Otro blog

Sitio de Groovy: Groovy

Para aprender Python: Aprendiendo Python

Sobre Ruby: Ruby

Blog javamexico Blog de CARRARO

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Java

Hay muchas opiniones sobre Java. Muchos programadores ya están cansados de tener que teclear tanto código porque Java es muy verborreico, sin embargo la gran cantidad de clases que te ofrece el puro JRE, la flexibilidad y estabilidad de la JVM, y la gran cantidad de proyectos de software libre y comercial que existen hechos en Java, es una razón para seguir usándolo. Por eso han nacido lenguajes como Scala, JRuby y Groovy, que te permiten escribir menos código o están orientados a ciertas cosas pero a fin de cuentas se compilan a Java bytecode y corren sobre la JVM.

RE: Java

Además de eso no se te olvide el tema de las configuraciones. Por ejemplo en RoR sólo existe un archivo de configuración y es muy simple. Lo que en Java tienes de mínimo el web.xml, sin incluir las anotaciones, xmls o .properties que hay que hacer en Java.

Eso de JRuby, Groovy y Jython, me parecen buena opción y al parecer (por JRuby y Groovy, en Jython no estoy seguro) los despliegues son en cualquier contenedor web compatible con servlets. Aunque hay muchos rumores de leaks de memoria y eso (porqué es levantar un intérprete sobre una VM y la(s) aplicaciones).

Imagen de ezamudio

intérprete

No sé en el caso de JRuby pero en el caso de Groovy puedes interpretar el código o puedes compilarlo a bytecode y no hay ninguna interpretación más que la que hace la JVM del bytecode compilado, pero para entonces ya es lo mismo que cualquier clase Java.

Los lenguajes de

Los lenguajes de programación mueren por muchas razones.

  1. Estrategia comercial. Si bien es cierto que ha habido lenguajes o empresas que desarrollan estos que quiebran o que buscan evitar que sean competencia de sí mismos.
  2. Poca "audiencia". También es otro factor, es decir, no vas a invertir tiempo y esfuerzo (quizás dinero si se trata de una empresa) para que sólo 100 personas usen un lenguaje de programación en un lapso de 7 años.
  3. Actualización seguimiento de tendencias. Lo que a muchos les ha pasado, que siguen aferrados a usar de cierta forma ciertas cosas y ves al lado que eso no es necesario por ejemplo los modelos en RoR comparados con los de Java, los de RoR no tienen nada más que "has_one :user" o "belongs_to :author" o "has_many :readers" (que a mi gusto es demasiado DRY). Creo que a Java le está pasando (ezamudio comentó de la verborrea javalística).

A cerca de los lenguajes matados pero no muertos, es por gente resistente al cambio o que no tiene la capacidad de aprender otra cosa que te lleve al orden, uso de estándares y convenciones. De este tipo de programadores conozco muchos, principalmente de Basic 6.0, Delphi y Fox"pro" (lo que no entiendo es porqué le tienen miedo a Basic .NET siendo que es más de lo mismo pero más sencillo y con el mismo o similar paradigma de estos 3).

En fin hay de todo tipo de programadores, esperemos y ser de los que se adaptan siempre.

Imagen de ezamudio

VB.NET

El problema de VB.NET es que solamente tienes la sintaxis de VB pero estás usando la plataforma .NET, de modo que estás utilizando OOP quieras o no. Y aunque pusieron muchas funciones para enmascarar las nuevas clases, muy pronto se les cae el teatrito de que es transparente migrar a VB.Net. Y si finalmente VB 6 lo estaban usando casi puros changuitos que ni saben programar, ahora resulta que sí tienen que saber programar, pues no se pasan a VB.NET y las aplicaciones que tienen funcionando no las van a migrar nunca.

Y en cuanto a que una empresa no invierte tiempo y esfuerzo para que unas cuentas personas usen un lenguaje solamente dentro de una empresa... aquí te dejo una historia de horror que espero sea la excepción a esa regla.

RE: VB .NET

Jajaja, has dado justo en el punto.

Y si finalmente VB 6 lo estaban usando casi puros changuitos que ni saben programar, ahora resulta que sí tienen que saber programar, pues no se pasan a VB.NET y las aplicaciones que tienen funcionando no las van a migrar nunca.

¿Será esto lo mismo que pasa con la gente de Fox"pro"?...Porqué hace un par de días hablé con un Foxero y me decía que lo que Fox hacía desde la versión de los años 80's Java o cualquier otro lenguaje a penas lo está implementando. Para mi que es una CHARRA monumental y fue su manera de decir: "Ahora si tengo que programar" cómo bien dices ezamudio.

¡Y pues a leer una historia de horror!

Imagen de ezamudio

Foxpro

No no no, Foxpro sí es otra cosa. Con Foxpro no te metas. Foxpro desde los 80's tiene un contenedor para inversión de control, web services, REST, AOP, transacciones distribuidas, un ORM, puedes hacer tus DSL's para extender el lenguaje y adaptarlo a tus necesidades, etc. Lo que pasa es que nadie usaba por ejemplo la creación de web service porque como no existía la web, nadie los podía consumir...

Estoy buscando en Google pero no puedo encontrar la liga a una entrevista que le hicieron a Tim Berners-Lee estando borracho y confesó que todo eso del HTTP y del web realmente se lo copió a FoxPro.

Lo que sí tenía Foxpro muy chido era paralelización masiva (o sea era para lelos).

RE: Foxpro

Pues lo que me dices de Fox"pro" es que te llevaba a desarrollar muchas habilidades (mal desarrolladas, pero a fin de cuentas desarrolladas) y es por ello que los foxeros no quieren aprender la manera correcta de cómo son las cosas. ¿Capté?

C un lenguaje muerto?

Oh god... sólo por intentar parar malas fuentes de información, ¿en qué te basas exactamente para considerar dichas declaraciones? ¿O quién dice que C está muerto? ¿en qué fuente citan tal cosa? Entiendo que es un foro de opinión común y libre, pero a veces es importante REALMENTE reflexionar lo que leemos, u opinamos al respecto de un tema.

Cantidad de usuarios != comunidad activa de un lenguaje, no tiene absolutamente nada que ver. Popularidad puede ser el termino que estás buscando.

RE: C un lenguaje muerto?

Creo que se refiere a C cómo opción en las empresas, desde que apareció C++ creo que C quedó de lado y se remite a ser usado en la educación. Aunque no quiere decir que no haya gente que todavía lo use.

Uhm...

Entiendo a lo que se refiere, pero ese hecho sigue siendo incorrecto, por eso pregunté las fuentes de tal aseveración. Desde Google, Yahoo, Amazon y muchas empresas que hacen embebidos, siguen usando C fuertemente. NVIDIA siendo uno de los principales proponentes. Esos son hechos. Por eso insisto en lo de las fuentes.

Mi intención obviamente no es hacer quedar mal a nadie, nuevamente, es un foro público, sólo digo que muchas veces a causa de opiniones de ese tipo se crean imagenes incorrectas de algunas herramientas. Pasa seguido cuando uno está metido en ciertos rubros. Por ejemplo, una persona que generalmente trabaja haciendo websites, o aplicaciones transaccionales comunes, no tendrá mucha visibilidad en proyectos de procesamiento distribuido, bigdata o cuestiones analíticas, y no porque no pueda, pero posiblemente no es su rubro. Eso no implica que no puedas comentar al respecto :) para eso fuentes de lo que uno lee son necesarias.

Imagen de ezamudio

era broma

Se me hace que estás muy chavo y no entendiste el chiste... muchas de las cosas que mencioné que Foxpro hacía en los 80's como IoC y AOP y ORM, no existían en los 80's. Web services, REST tampoco existían en los 80's... porque son tecnologías basadas en web, y el web nació en los 90's. DSL's en los 80's? mmm se llamaban 4GL en aquél entonces, los supuestos lenguajes de alto nivel que te permitían hacer maravillas con muy poco código pero eran muy limitados a cierto tipo de aplicaciones. Ahora ya por fin se vio que es mejor tener lenguajes de bajo nivel pero que te permiten hacer con ellos mismos un lenguaje específico para un dominio particular, como en Groovy que puedes hacer un DSL sin mucho problema, lo cual te permite tener algo como un 4GL para ciertas funciones pero si necesitas "salirte de la cajita" usas Groovy o Java que son de uso general.

Las transacciones distribuidas ya existían al menos conceptualmente en los 80's y eran de las cosas más difíciles de lograr y solamente Oracle y creo que Sybase podían soportarlas pero era un rollo programarlas en lo que había en la época. Foxpro creo que ni siquiera tenía el concepto de una transacción...

Imagen de ezamudio

Status de C

C para nada está muerto, pero ya casi no se usa para desarrollo de aplicaciones. Es más bien para programación de sistemas. Por ejemplo si quieres hacer una JVM o un CLR pues seguramente estará en C o tal vez en C++ pero muchas cosas estarán en simple C. Un manejador de ventanas para Linux? C o C++. El kernel de Linux está hecho en C. Un filesystem lo vas a programar en C o a lo mucho en C++. Quieres programar firmware seguramente será en C. Igualmente si vas a hacer un driver, como ya mencionaron NVidia.

Pero si alguien quisiera hacer hoy mismo un CRM o un ERP en C puro, yo sería el primero en tratar de convencerlo de no hacerlo.

Imagen de Nopalin

Lenguages con objetivo

JavaFx un lenguaje muerto? por una parte sí y por la otra no.

A final de cuentas javafx compilaba a bytecodes, por lo que corria en la jvm y las clases que ocupaba javafx se pueden embeber en una aplicación swing. Entonces JavaFX yo considero, mas que un lenguaje, un framework. El scripting o lenguage que facilitaba el uso de ese framework lo descontinuaron, pero el framework sigue vivito y coliando.

Y con respecto a la documentación de JavaFX, no creo que sea pobre, encontrabas muchos ejemplos para hacer diferentes cosas. Yo alcance a hacer una aplicacion en java algo vistosa, que en swing nunca hubiera podido hacer (o tal vez si, pero nunca tan fácil como en JavaFX). Sucede también que los lenguages salen con un efoque y el desarrollador a fuerzas quiere usarlo para otro. Por ejemplo, el framework JavaFX era la contraparte de flash y silvertlight, entonces aprovechen el potencial para hacer animaciones, no sistemas empresariales con gráficos estáticos. Aunque la ventaja era de que escribias una vez y corria donde sea, yo me pregunto, ¿habrá quien en verdad ponga la misma aplicacion en el escritorio y en el web?.

En fin, cada quien entiende lo que quiere entender.

Sobres

Imagen de luxspes

Quita mas tiempo leer, que escribir

Muchos programadores ya están cansados de tener que teclear tanto código porque Java es muy verborreico, sin embargo la gran cantidad de clases que te ofrece el puro JRE, la flexibilidad y estabilidad de la JVM, y la gran cantidad de proyectos de software libre y comercial que existen hechos en Java, es una razón para seguir usándolo.

Ademas de que muchos programadores olvidan que lo que quita mas tiempo no es escribir el codigo, lo que quita mas tiempo es leer y corregirlo... a mi me gusta Scala, por ejemplo, pero a veces mi pregunto si todo su mecanismo de inferencia de tipos para ahorrarle teclazos al programador no resulta en codigo mas dificil de leer...

Imagen de luxspes

RoR es un framework, Java es una lenguaje

Además de eso no se te olvide el tema de las configuraciones. Por ejemplo en RoR sólo existe un archivo de configuración y es muy simple. Lo que en Java tienes de mínimo el web.xml, sin incluir las anotaciones, xmls o .properties que hay que hacer en Java.

Una comparacion injusta, RoR no es el unico framework web para Ruby, asi que no se puede afirmar que "en RoR sólo existe un archivo de configuración y en Java tienes minimo...". Java es un lenguaje, RoR es un framework, como Seam, Spring, o Struts.

Imagen de luxspes

Si C esta muerto...

Creo que se refiere a C cómo opción en las empresas, desde que apareció C++ creo que C quedó de lado y se remite a ser usado en la educación. Aunque no quiere decir que no haya gente que todavía lo use.

Si C esta muerto... los demas lenguajes ni existen! el Kernel de linux esta en C, GTK+ esta en C, Windows mismo esta en C, es mas, para no ir mas lejos, la JVM esta escrita en C!

Imagen de luxspes

1ro de Abril

Estoy buscando en Google pero no puedo encontrar la liga a una entrevista que le hicieron a Tim Berners-Lee estando borracho y confesó que todo eso del HTTP y del web realmente se lo copió a FoxPro.

Se me hace que lo leiste un 1ro de Abril.... ;-)

El cadáver de C

El lenguaje C está tan muerto como el lenguaje ensamblador. C tiene usos muy específicos, por ejemplo escribir drivers o interfaces para hardware, en sistemas embebidos o sistemas "real-time".

A cobol tampoco lo puedes considerar muerto. Existe un mundo de código generado en cobol, y en muchos casos transportar estos sistemas a una tecnología nueva resulta infactible. Mientras haya que darle mantenimiento a estas plataformas, los lenguajes siguen vivos.

Por otro lado, no te imaginas la cantidad de servicios y aplicaciones de misión crítica que corren en sistemas que en tu criterio considerarías obsoletos, como OS/2 o VMS...

Imagen de ezamudio

veborrea

Asi es luxspes, a veces creo que los lenguajes nuevos se están enfocando demasiado al ahorro de teclazos, sin considerar mucho la legibilidad del código o la mantenibilidad. Eso del duck typing... es muy padre para escribir código, pero cuando estás leyendo el código de alguien más, le tienes que hacer al ornitólogo para saber qué tipo es X variable si no tienes a la mano la declaración... lo bueno que en Groovy puedes usar "def" o puedes indicar el tipo de dato que quieres que sea la variable (y de hecho si defines el tipo tienes mejor performance). Pero en fin, esa es otra discusión.

Imagen de CybJer

No considero a C muerto

Pese a que no es comun el que pidan en el trabajo C y demas no creo que este muerto los SO (Linux y Windows) que yo sepa se siguen escribiendo con C o no?
Puede que no sea tan popular pero sigue aqui y permanecera creo yo por mas tiempo que nosotros.
Tampoco consideraria al ensamblador muerto (si lo se nunca lo ocupamos) pero si llevaron un pequeño curso de electronica creo que saben del valor del ensamblador por lo menos a ese nivel.
Supongo que aun se usa para programar firmwares de todos los dispositivos que usamos en nuestras pc.

Imagen de Nopalin

lo bueno que en Groovy

lo bueno que en Groovy puedes usar "def" o puedes indicar el tipo de dato que quieres que sea la variable (y de hecho si defines el tipo tienes mejor performance).

¿Cómo puede tener mejor performance si a final de cuentas es la jvm quien lo corre?, o ¿se referirán a que tiene mejor performance a la hora de compilar?

RE: RoR es un framework, Java es una lenguaje

Bueno si comparamos Ruby cómo lenguaje a Java podemos verlo, también Ruby no tiene tanta verborrea y en poco puedes decir mucho. A eso me refiero, incluso si comparamos frameworks web Java con RoR puedes encontrar lo que dije (RoR un sólo archivo de configuración, Java xml's, .properties, anotaciones y algo que seguro se me escapa).

Imagen de ezamudio

Groovy def

Lee la liga que puse. Tal parece que si pones el tipo en def, se pueden resolver varias referencias a la hora de compilar el código; si usas def, todo se resuelve a la hora de correr el programa (el def se compila como referencia a Object o GroovyObject y luego cuando se hacen invocaciones sobre el objeto, se resuelven buscando en metaClass o sea de manera dinámica, en cambio si defines la clase cuando declaras la variable, cuando pones una invocación ya se puede resolver directamente invocar ese método).

Imagen de luxspes

Ruby... se puede decir mucho?

Bueno si comparamos Ruby cómo lenguaje a Java podemos verlo, también Ruby no tiene tanta verborrea y en poco puedes decir mucho.

Ciertamente aparenta ser asi... pero... realmente es asi?... a veces siento que es solo que la mayoria de los frameworks de Java no hacen buen uso del lenguaje, y apenas estan librándose de la influencia hiper-complicadora de JEE, la mayoria de los algoritmos que he visto en Ruby rara vez ahorran una cantidad de lineas espectacular con respecto a la misma implementación en Java (me encantaria ver un ejemplo que demostrara esa reduccion, si tienes uno) y por otro lado, en Ruby se complica el mantenimiento, ya que por su naturaleza dinamica te arriesgas a hacer mucho codigo que no sabes lo mal que esta hasta que no lo corres (razon por la cual tambien prefiero Scala sobre Groovy). Me gustaria ver mas lenguajes con type inference como Scala, C# (o increible Haskell que lleva el poder del static typing a otro nivel) que lenguajes de la tendencia Ruby/JavaScript/VisualBasic... pero ya me estoy desviando...

Para que te hagas una idea del potencial inexplotado de Java, echale un ojo a AribaWeb. Una vez que has jugado (checa los videos) con AribaWeb, RoR y Ruby se ven mucho menos impresionantes... algo que si me intriga es que Java haya producido un monstruo como JEE mientras que Ruby produjera desde el principio algo muy parecido a AribaWeb...

Y por otro lado, como comente en otro post, se pierde mas tiempo corrigiendo que haciendo por primera vez, y (con la excepcion de Haskell o Eiffel) la mayoria de los lenguajes "dinamicos y de moda" como Groovy, Ruby o JavaScript lo que prometen es escritura rapida, de programas chiquitos, y la depuracion? bueno, que mas da si toma mas tiempo....

No mejor performance que

No mejor performance que Java Nopalin, tiene mejor performance que Groovy usar def, vs. tipo explicito.

Otra ventaja de static

Otra ventaja de static typing vs. dynamic typing es el refactoring [1].

Si tienes:

class Client
    def one( a )
         a.blah
     end
    def two( b )
         b.blah
    end
end
class Blah
    def blah
       ...
     end
end

Si renombras el Blah.blah por Blah.blah2, no hay forma de saber en cual de los dos metodos "one" y "two" hay que cambiar.

Por otro lado, forzar a tener una estrucura jerárquica de clases a veces se vuelve engorroso. Quizá lo mejor será encontrar un punto intermedio, como el tipeo estructurado que Go tiene ( Scala también lo tiene pero por alguna razón - como todo Scala - me parece algo confuso )

Acá les dejo otro link interesante: Tipeo estático cuando sea posible, tipeo dinámico cuando sea necesario: El fin de la gerra fría entre los lenguajes de programación [PDF - Inglés]

P.D. Hay alguna mejor traduccion para "typing" que "tipeo"? :)

Imagen de ezamudio

tipeo -> tipado

ninguna suena bien.

En Groovy uso el nombre de la clase cuando sé qué cosa es lo que quiero meter ahí; uso def prácticamente sólo para closures. O cuando uso el "it" dentro de un closure. O a veces si no quiero hacer un import. Aún así, es bastante cómodo...

List lista = []
Map mapa = [:]
String regex = "hola"
//esto podria ser un java.util.regex.Pattern o lo dejo como def
def timePat = ~/([01]\d|2[0-3]):[0-5]\d:[0-5]\d/
def closure = { println it } //esto lo puedo usar luego
Imagen de luxspes

Scala / CSharp

En Scala tambien es facil, solo que ahi puedes usar var (mutable) o val (inmutable/solo lectura)

  val x = 1 + 2 * 3         // the type of x is Int
  var y = x.toString()      // the type of y is String

O en el caso de un closure (notse que en este ejemplo, el parametro de entrada especifica el tipo de manera explicita)...

 def square(x : Int) = x * x;

o o una funcion... con un closure dentro (como ven, la sintaxis de Scala es consistente, de un modo que en mi opinion supera limpiamente a Groovy que tiene que mantener la sintaxis de metodos estilo Java, y closures estilo Groovy)

object UnObjeto{ //Como le puse object y no class automaticamente obtengo un Singleton, que puedo usar en cualquier lado, en vez de las horrorosas static de Java

def function1(x : Int) = {
   def function2 =  {
       x
   }
   function2()
}

}

y en C#:

  var x = 1 + 2 * 3         // the type of x is int
  var y = x.ToString()      // the type of y is string

El problema, para mi, viene cuando ves codigo como:

var resultado = metodoQueHaceAlgo();

En Java, de inmediato puedo saber con ver la invocacion que regresa, en cambio, en Scala, o en C# o en Groovy, dependiendo de la decision del programador, puedo (o no) saberlo con solo darle un vistazo al codigo (lo cual complica la lectura del codigo). (Por otro lado, al menos en C# y en Scala, el IDE puede inferir el tipo y darme el autocompletar correcto, o saber el cual es el tipo, en lenguajes como Ruby (y supongo que Groovy tambien) no hay forma de saber hasta no correr el programa

Re: Ruby... se puede decir mucho?

Voy a revisar un lo de AribaWeb promete ser 100x menos código que Rails...Se ve impresionante debo decirlo (y de convencerme seguro que cambiaré). Igual JEE tiene esa naturaleza y es de lo que hablo, Scala no me convence porque te da la tentación de utilizar código Java (en lo personal no me parece una buena idea).

Re: era broma

Mi comentario también era broma (parcialmente, a modo de seguirte el juego), aunque la verdad no estoy grande XD, quizás ante ti yo pudiera ser un niño que empieza sus pininos programando.

Así se ve bonito Scala, lo

Así se ve bonito Scala, lo malo viene cuando una misma cosa se puede escribir de muchas maneras, y no me refiero a que se escriba con diferentes estrategias equivalentes, si no que literalmente se puede escribir lo "mismo" de forma "diferente"

Por ejemplo se puede definir una funcion que multiplique dos número entre sí, justo como en tu ejemplo:

def entreSi( x: Int, y : Int ) = x * y

Y luego pasar esa funcion a otra que por ejemplo reduzca una arreglo:

val arreglo = Array(2,3,4)
val resultado = arreglo.reduceLeft( entreSi )  // regresa 24 por cierto ( 2 * 3 = 6 , 6 * 4 = 24 )

Obvio, se pueden hacer definiciones en línea:

val resultado = Array( 2,3,4).reduceLeft( entreSi ) // sin declarar una variable para el arreglo
// o bien
val resultado2 = Array(2,3,4).reduceLeft( ( x:Int, y:Int ) => x * y ) // escribiendo la funcion como una expresion lambda ( closure o en linea pues )

Hasta aquí todo bien, pero si luego se meten los parametros implicitos ya no es ni tan claro. Si a eso le aunamos que en Scala el punto ( . ) es opcional, entonces podemos escribir, lo mismo, pero de una forma casi .. mmhh digamos.... pues no sé

Array( 2,3,4 ) reduceLeft ( _ * _ )

Ándale pues.... ya no parece tan obvio. Pero claro es cosa de acostumbrarse, yo nomás no me acostumbro. Entiendo lo del parametro implicito, y entiendo el por que el punto es opcional, pero así como estos ejemplos se van haciendo más y más.

Imagen de Nopalin

¿Ventajas Reales?

Yo entiendo que Scala y groovy ya implementan los famosos closures (aunque desde mi punto de vista, no tan necesarios), eliminan la verborrea del lenguage y muchas otras monerias mas, pero en sí ¿cual es la ventaja real que ofrecen?, ¿son mas veloces a la hora de ejecutarse?, ¿se evitan usar una cantidad considerable de memoria?, ¿A la hora de codificar es menos suceptible a errores?.

Yo en mis inicios con java trataba de optimizar lo más que pudiera, intentaba meter ciclos donde fuera, reutilizar metodos, funciones recursivas, etc. Hasta que un compañero programador con mucha mas experiencia que yo me dijo (y hasta la fecha no se me olvida): "¿por que escribes de esa manera? la mayoria de las veces no entiendo lo que haces y tengo que perder tiempo en preguntarte, mejor escribe lo más claro posible y nos evitamos broncas, como quiera el hardware avanza a pasos agigantados y el performance no es algo que nos impacte tanto." Me parecio algo muy lógico y entendible, cuando varios trabajan en un mismo proyecto, la lectura del codigo por si misma debe ser lo más clara posible, y en forma personal, no le encuentro sentido a ser menos verborreos, es más yo muchas veces hasta escribo en español, ya se imaginaran los nombresotes de metodos y clases, pero eso a la larga, en proyectos que crecen de manera monstruosa, nos ayuda muchisimo, incluidos nosotros que muchas veces se nos olvida lo que hicimos, como lo hicimos y por que lo hicimos así.

Pero bueno, yo creo que esto ya es a gusto de cada quien.

@ezamudio, si lei el articulo, pero solo hablaban de groovy, yo me referia a cual era la ventaja de programar en groovy las variables con def y hacerlo en java con su tipo adecuado, pero ya me contestaron la duda, no hay ventaja.

sobres.

Yo entiendo que Scala y

Yo entiendo que Scala y groovy ya implementan los famosos closures (aunque desde mi punto de vista, no tan necesarios),

No son necesarios los clusures, Java ha funcionado sin ellos, pero una vez que los conoces y entiendes en que situaciones aplicarlos, realmente se vuelven una herramienta muy útil.

¿cual es la ventaja real que ofrecen?, ¿son mas veloces a la hora de ejecutarse?, ¿se evitan usar una cantidad considerable de memoria?, ¿A la hora de codificar es menos suceptible a errores?.

Puedes escribir en Java un programa totalmente ineficiente. Dependerá de tu algoritmo (bubble sort por dar un ejemplo trivial) y/o de la manera en como implementes; también puedes escribir código muy eficiente en Groovy que a su vez dependerá de la forma en como lo implementes. Lo interesante de Groovy es la flexibilidad del lenguaje, y las mejoras que hicieron al JDK (en Groovy se conoce como GDK). Agregaron métodos adicionales a la clase "Object" (padre de todas las clases), agregaron métodos a las Collections; por mencionar algunos. Esto te permite escribir en muchas menos líneas una rutina. Ahora, en lo que respecta a los Closures es la misma situación: Por solo hecho de existir no te hacen mas eficiente el programa, dependerá de tu pericia a la hora de desarrollar.

Por otro lado, Groovy es la tierra donde todo es posible, y eso se te puede volver un problema. Esto es posible gracias al MOP (meta object protocol) que te permite interceptar llamadas a métodos. En tiempo de ejecución tu puedes interceptar una llamada a un método y decidir que método invocar o bien, si una llamada invoca a un método que no existe, puedes incluso tomar acciones. Por ejemplo, esto permite implementar los Dynamic Finders de Grails. El detalle aquí es que la refactorización de un programa en Groovy es realmente complicada, y los IDE actualmente no te ofrecen muchas opciones al respecto. Al final del día, tendrás que ser muy organizado para poder escribir código con el menor número de errores que solo pueden botar en tiempo de ejecución. Una vez que aprendes el lenguaje y las herramientas, puedes generar código muy limpio, muy entendible y mas rápidamente.

Haz la prueba y métete a Groovy y a Scala. Cuando estés programando en "Plain old Java", vas a decir "caray, esto lo pude haber hecho mas fácil en (groovy|scala|Clojure|you name it)...".

Yo en mis inicios con java trataba de optimizar lo más que pudiera, intentaba meter ciclos donde fuera, reutilizar metodos, funciones recursivas, etc

"Early Optimizations" son una fuente inagotable de problemas. Se escucha feo, pero muchas veces el enfoque "primero hacemos que funcione, y después hacemos que funcione bien" rinde frutos.

Me parecio algo muy lógico y entendible, cuando varios trabajan en un mismo proyecto, la lectura del codigo por si misma debe ser lo más clara posible, y en forma personal, no le encuentro sentido a ser menos verborreos, es más yo muchas veces hasta escribo en español, ya se imaginaran los nombresotes de metodos y clases, pero eso a la larga, en proyectos que crecen de manera monstruosa, nos ayuda muchisimo, incluidos nosotros que muchas veces se nos olvida lo que hicimos, como lo hicimos y por que lo hicimos así.

Se debe definir una serie de convenciones de programación para tu equipo de desarrollo (tal como menciona tu compañero), pero también tienes que apoyarte mas en la documentación del código y en la documentación del sistema. Pero definitivamente es posible escribir código claro y entendible sin diarreas cerebrales.

...las variables con def y hacerlo en java con su tipo adecuado, ...

Una cosa es "dynamic typing" (duck typing) y otra cosa es "strong typing". Los tipos de Java son static + strong; en Groovy son dynamic + strong. Puedes googlear algo de ésto para que entiendas sus ventajas y desventajas.

Imagen de ezamudio

closures, etc

Nopalin, recuerda que el performance no lo es todo. Eso de la optimizacion prematura es muy cierto. Ya cuando tienes experiencia programando ciertos tipos de sistemas, a veces sabes que desde el principio hay funciones que se van a invocar de vez en cuando o en un proceso por lotes o cosas asi, o no son tan intensivas en CPU; esos son la mayoria de los casos y ahi conviene escribir el codigo de la manera mas clara posible. Si en el sistema existe alguna funcion que saben que se va a invocar miles de veces por minuto o hasta por segundo, ahi si conviene hacerla pensando en performance desde el principio. Y en un sistema basado en Java, haria esa parte en Java (no en ningun otro lenguaje de JVM).

Por lo demas, las ventajas reales de Groovy son precisamente lo que ya mencionaste: menos verborrea, por lo tanto menos codigo. Mientras no abuses de esta caracteristica, pues menos codigo que escribir tambien es menos codigo que leer y menos codigo que mantener. Pero lo que no debes sacrificar es la claridad.

como ya mencionaron otros, los closures pues no son necesarios, pero son muy convenientes en muchas ocasiones. Estrictamente hablando, los objetos tampoco son necesarios, podemos usar puras funciones y guardar cualquier estructura de datos usando tipos basicos numericos, cadenas, arreglos de bytes, listas y mapas. Pero es muy conveniente la OOP y te permite organizar mejor tu codigo. Lo que haces con closures en muchos casos se puede hacer sin closures, pero de manera mas enredada. Por ejemplo, tienes un metodo que recorre una lista y que a cada elemento de esa lista le tiene que hacer algo, pero ese algo no esta definido en el metodo, sino que recibe como parametro un objeto que implementa cierta interfaz que tiene un metodo que se llama procesar() y recibe el elemento como parametro. De entrada ya tenemos algunas broncas: el metodo procesar() puede tener como parametro Object para ser muy general, o podria ser otra interfaz o una clase; cada enfoque tiene sus desventajas (hacer muchos casts en la implementacion, revisar que realmente el elemento sea de la clase que necesitas, etc, o por otra parte, no poder usar esa funcionalidad que implementaste con objetos que no sean de cierta clase o interfaz). En Java es algo asi:

public interface Procesador {
  public void procesa(Algo algo);
}

public class Ejemplo {
  public void procesaLista(List<Algo> lista, Procesador proc) {
    for (Algo algo : lista) {
      proc.procesa(algo);
    }
  }
}

Y eso es lo mas sencillo. Si el metodo procesa devolviera un valor que fuera resultado de una transformacion al elemento, podrias guardar eso en otra lista y al final tienes una lista con los resultados. Con closures eso es mucho mas breve de implementar, sobre todo si las listas ya tienen facilidad para usar closures. Para empezar, no tienes que implementar una interfaz ni nada, puedes recibir un closure directamente o implementarlo ahi en linea. Y puedes jugar con cualquier clase por lo del tipado dinamico.

Lista lista = //una lista
lista.each { //esto es el closure
  println it
}

"it" es un parametro "magico" que trae el closure y que representa en este caso el elemento de la lista. el each es un metodo de la lista que recibe como parametro un closure y entonces recorre la lista e invoca el closure con cada elemento. Si no lo tuvieramos lo tendriamos que implementar nosotros pero regresando al ejemplo java, seria algo asi:

public void procesaLista(Lista lista, procesador) { //no definimos tipo, pero procesador es un closure)
  for (Object x : lista) {
    procesador(x)
  }
}

y ahi tenemos exactamente la misma cantidad de codigo que en Java. Pero la gran diferencia es que procesador puede ser cualquier closure. No pides cierta interfaz, no pides nada. Realmente el parametro procesador requiere ser una funcion que recibe un parametro.

Por cierto luxspes la sintaxis de Groovy rompe un poco con Java en eso de los closures porque esta un poco inspirado en Ruby. Pero me gusta mas como se definen los parametros de closures en Groovy que en Ruby:

def func = { int p1, String p2 ->
}

y en ruby

func = { |p1|, |p2| #o era |p1, p2| algo asi pero esos pipes no se, no me gustan
}

ah y en un IDE muchas veces si se puede inferir el tipo de una variable Groovy, cuando ya tiene algun valor asignado. Al menos el plugin de groovy para Eclipse si lo puede hacer, excepto para el "it" de los closures porque es practicamente imposible determinar que va a ser, ahi si es en tiempo de ejecucion.

Y lo de metaprogramacion, es muy chido porque hasta te permite hacer lenguajes especificos de dominio pero si no documentas muy bien lo que estas haciendo, luego nadie le entendera a tu codigo. Con eso que le puedes agregar metodos a cualquier clase, hay que tener cuidado porque luego ves codigo donde invocan metodos de una clase que conoces bien y sabes que ese metodo no existe; tienes que ver si alguien le agrega ese metodo en el metaClass o si lo teclearon mal o se confundieron, etc... se puede dificultar la depuracion de algo asi, cuando no esta todo muy bien organizado y documentado.

@Ezamudio

¿en ruby no sería?, ¿o entendí mal lo que quieres explicar?:

def metodo(lista=[1,2,3])
    lista.each do |x|
        procesa x
    end
end

Y pythonicamente:

def metodo(lista = [1,2,3]):
    for x in lista:
        procesa(x)
Imagen de Nopalin

Los entiendo

Desde que empezaron a sonar los closures, entendí para que eran. Y claro como bien dices @ezamudio, en java pudieras hacer lo mismo con la grandisima desventaja de que tendrias que andar declarando interfaces a diestra y siniestra, y que ademas tendrias que declarar las variables externas como final, para que puedan ser accedidas desde el override del metodo, sin embargo tocaste un punto importante creo yo, como bien dices todavia pudieramos estar programando de forma estructurada, secuencial o hasta en ensamblador, todo se reduce a eso a final de cuentas. Pero el brinco de cada una de estas es enorme, cambia el paradigma de programación, y con los closures no, es solo sugar, y solamente los van buscar aquellos programadores que no definan bien objetos que hacen algo, por ejemplo tienes una interfaz ave, con varias implementaciones, si creas e implementas bien cada sub-clase, ni si quiera te pasa por la mente la idea del closure. No digo que yo sea el gran experto, estoy conciente de que ustedes tienen mas experiencia que yo y saben mas al respecto, pero hasta ahorita, no me he topado con el caso de decir: "chingao, por que no hay algo en java que me permita hacer una declaración dinámica", y por lo mismo siento que no son indispensables a la hora de programar, me falto tal vez mejorar la sentencia diciendo que no son indispensables dependiendo como programes.

Un ejemplo algo burdo es como cuando uno ha estado usando su automovil de la forma en que se lo entregaron de la agencia, y de repente viene un cuate y te dice: "oye, si le pones este filtro a tu carro va a tener mejor rendimiento y a correr más rapido", igual y sí, pero es algo que nunca has necesitado.

Tal vez aun no he alcanzado a comprender las bondades de los lenguages de los que hablab, pero para mi hasta ahorita, sigue siendo solo sugar a la hora de programar.

sobres

Imagen de luxspes

Beneficios de paradigmas, (o del azucar): Todos subjetivos?

Al final, uno de los grandes problemas que tenemos como ingenieria, es que la hechura de sistemas esta muy verde, a mi por ejemplo, me agradaria tener closures en C# o en Scala, pero pienso que hay muchos otros caminos a traves de los cuales Java podria beneficiarse (como volverse una MVM) que deberian ser recorridos en vez de alterar el lenguaje (ademas, por que alterarlo? por que no mejor "copiar" la idea de .NET y fomentar mas de 1 lenguaje?).

Por otro lado, para una muestra de lo relativos que son los beneficios de los paradigmas de programación, tomemos la programación orientada a objetos, uno de los paradigmas actualmente mas aceptados (aunque puedo contar con los dedos de 1 mano a las personas que conozco que entienden el polimorfismo y eso que he conocido docenas de programadores que dicen dominar el paradigma) y veamoslo como abogados del diablo: OOP Critisim

Herejia! pensaran algunos de ustedes despues de leerla. Es un hecho aceptado que la OOP trae beneficios! Estan seguros (prueben los retos)? pueden demostrarlo mas alla de toda duda de modo numerico cuantificable? o nadamas es algo que sienten? que "les late"? pero no pueden realmente demostrar? ;-) Todavia estamos lejos de los dias en que podamos decir que el paradigma X o el Y aportan beneficios tales que, de no aplicarlos, un proyecto fracasara... (o que de seguirlos, garantizamos el exito).

Asi que si, los closures pueden ser vistos solo como azucar... pero para el caso, todo lo que esta arribe de ensamblador podria ser visto de la misma manera... ;-).

@whishmaster77: En Ruby se

@whishmaster77: En Ruby se pueden usar ambos: "do .. end " o " { } " La diferencia es que uno tenía más precedencia que el otro ( no recuerdo cual era cual )

El ejemplo de Python realmente no aplica por que el "for in " no acepta una funcion. Pero si se usamos por ejemplo la funcion "filter" en ese caso sería algo como:

def funcion( lista = [1,2,3]):
     filter( lambda x:  x > 2,  lista)

En Ruby la declaración de los parametros del closure entre pipes, viene tomado de Smalltalk, donde de esa misma forma se declaran las variables locales.

miFuncion
   |a1 a2 |
   etc. etc

Y en los closures (llamados block en Smalltalk y que son parte fundamental del lenguaje, al grado, que no hay if's o while's sin ellos ) las variables se declaran con un solo pipe:

list select [ :item | item cumpleCondicion ]

Desde mi punto de vista, las variables de un closure, deberían de ser declaradas igual que en una funcion normal:

archivo.lines().each( ( line : String ) {  out.print( line ) } )

"...a mi por ejemplo, me

"...a mi por ejemplo, me agradaria tener closures en C# o en Scala"

Ehm.. pues... si los tienen, desde hace varios años.

"ademas, por que alterarlo? por que no mejor "copiar" la idea de .NET y fomentar mas de 1 lenguaje?"

La máquina virtual de Java, de hecho ya tiene muchisimos más lenguajes que el CRL.

Para nombrar solo algunos que ya fueron mencionados en este post: Groovy, Scala, Ruby, Python, Clojure ( bueno ese nadie lo mencionó )

Es cierto, que ninguno fue iniciativa de Sun ( Salvo JavaFX, pero que pos, ya che moyo ) pero ahi radica lo genial, que no hace falta .

Algo que si se va a hacer ( bueeeno, el día que se decidan sacar la siguiente verisión ) es incluir un nuevo llamado a nivel de la VM "invokeDynamic" que en resumidas cuentas, les quitará a estos lenguajes dinamicos, la necesidad de andar dandole vueltas y vueltas al modelo que tiene Java actualmente.

Sobre la crítica, OOP me dio un poco de fiaca,leerla, pero es importante recalcar, que ningún paradigma es perfecto y muchas veces los principios equivalentes, solo que se llaman diferentes.


Les dejo una cita al respecto:Closures y Objetos son equivalentes


El honorable maestro Qc Na caminaba con su estudiante, Anton. Esperando provocar con el maestro una discusión le dijo: "Maestro, he oido que los objetos son algo muy bueno ¿Es verdad?" Qc Na lo miró con lástima y le dijo: "Tonto aprendíz, los objetos no son sino los closures de los pobres".

Reprendido, Anton pidio permiso a su maestro y regresó a su celda para estudiar closures. Leyó con atención la serie de documentos de "Lambda: The ultimate..." y sitios vecinos e implemento un pequeño interprete de Scheme con un sistema de objetos basado en closures. Aprendió mucho y estaba ansioso para informar a su maestro de su progreso.

En su siguiente caminata con Qc Na, Anton intentó impresionar a su maestro diciento: "Maestro, he estudiado diligentemente la materia, y ahora entiendo que realmente los objetos son los closures de los pobres". Qc Na respondio dandole un bastonazo a Anton diciendo: "¡¿Cuando aprenderás?! Los closures son solo los objetos de los pobres". En ese momento, Anton fue iluminado."

VB y PHP...solo para monos

"Y si finalmente VB 6 lo estaban usando casi puros changuitos que ni saben programar, ahora resulta que sí tienen que saber programar, pues no se pasan a VB.NET y las aplicaciones que tienen funcionando no las van a migrar nunca"

Es mas cierto de lo que parece. Tambien incluiria a PHP.

RE: VB y PHP...solo para monos

Pues PHP (o al menos gente que lo ha usado) ya empieza a agarrar la onda. Puedes mirar Akelos y verás que como que la gente PHP-era ya está agarrando la onda. Pero los basicos visuales y los foxers todavía no la agarran y ahí seguirán con su lenguaje superior pero deprecado.

c

en el caso de C no estaria tan seguro tan solo en sourceforge.net existen 6356 proyectos en C y calificados como en produccion y estables, ejemplos pueden ser: mod_qos para apache, wine, clam antivirus,ImageMagick, pidgin, el escritorio LXDE, y varios mas

Imagen de Nopalin

Paradigmas!

Herejia! pensaran algunos de ustedes despues de leerla. Es un hecho aceptado que la OOP trae beneficios! Estan seguros (prueben los retos)? pueden demostrarlo mas alla de toda duda de modo numerico cuantificable? o nadamas es algo que sienten? que "les late"? pero no pueden realmente demostrar? ;-)

Tal vez yo no soy el más indicado para responder esa pregunta en este momento, pero si hay algo que me queda claro, es que entre programación estructurada y programacion orientada a objetos, si cambia el paradigma de programación.
Lo admito, lei solo el inicio del articulo que linkeaste, así como dos de los primeros retos, pero por lo que entendí (ya que mi ingles no es muy bueno que digamos) es que están tratando de corregir problemas comunes para aplicaciones empresariales, no estan haciendo una comparativa entre un paradigma y otro con respecto algun programa (que era lo que yo esperaba), y que dijera que es lo mismo la POO y la estructurada y que el famoso paradigma era una invención del creador para venderlo mejor.

No es algo que "yo sienta" de la OOP con respecto a la programacion estructurada, es que he comprobado (tal vez no en un modelo matematico con resultados cuantificables) que la OOP cambia completamente la forma en que lo hubiera hecho. Por ejemplo hace tiempo hize un evaluador de formulas. Basandome en la libreria ANTLR para construir un arbol de tokens, hize un modelo de objetos donde todo token implementa una Expresion, y un metodo evaluar que me regresa un resultado. Apartir del arbol generado por ANTLR creo un arbol de expresiones, donde yo solo llamo al root evaluar, y me regresa el resultado de la formula. ¿Como podria hacer algo semejante en programación estructurada?, lo puedo hacer en la OOP gracias al polimorfismo. No estoy diciendo que en la estructurada no se pueda, simple y sencillamente estoy diciendo que la forma de hacerlo cambia radicalmente.

Con los closures, no cambia radicalmente nada segun yo, es solo la posibilidad de crear la implementación de un metodo sin haberlo definido antes. Que eso te ahorra la lata de andar definiendo interfaces e implementaciones de manera general, pues sí, si te lo ahorra.

sobres

Imagen de luxspes

Errata: agradaria tener closures "como" en

"...a mi por ejemplo, me agradaria tener closures en C# o en Scala"

Ehm.. pues... si los tienen, desde hace varios años.

Si, se que los tienen, perdon, error de redaccion, quize decir "me agradaria tener closures como en C# o en Scala "

Imagen de luxspes

Diferente no significa mejor, significa diferente.

Tal vez yo no soy el más indicado para responder esa pregunta en este momento, pero si hay algo que me queda claro, es que entre programación estructurada y programacion
orientada a objetos, si cambia el paradigma de programación.

Oh, claro que cambia, y mucho, la pregunta, es mas bien: es OOP garantia de mejores resultados? siempre? o en que casos? para ciertos problemas? o para el estilo de pensar de ciertas personas?

Lo admito, lei solo el inicio del articulo que linkeaste, así como dos de los primeros retos, pero por lo que entendí (ya que mi ingles no es muy bueno que digamos) es que están tratando de corregir problemas comunes para aplicaciones empresariales, no estan haciendo una comparativa entre un paradigma y otro con respecto algun programa (que era lo que yo esperaba), y que dijera que es lo mismo la POO y la estructurada y que el famoso paradigma era una invención del creador para venderlo mejor.

Esa es la cuestion, tu tienes que resolver un "problema comun de una aplicacion empresarial": Como es mas facil hacerlo? Cual paradigma implica un mayor exito dado un menor esfuerzo? Es posible medir de manera objetiva los beneficios de la programacion a objetos? o simplemente es como comparar tocar violines o flautas? (no hay superior ni inferior, solo son distintos)? O como el chocolate (si eres humano, es delicioso, si eres perro, es veneno mortal)

No es algo que "yo sienta" de la OOP con respecto a la programacion estructurada, es que he comprobado (tal vez no en un modelo matematico con resultados cuantificables) que la OOP cambia completamente la forma en que lo hubiera hecho.

Si no es basado en un modelo matematico con resultados cuantificables, entonces es algo que "sientes". Ademas, fijate en lo que escribiste despues " la OOP cambia completamente la forma en que lo hubiera hecho", totalmente de acuerdo, una melodia reproducida en violin sonara muy distinta si es tocada con una flauta... pero... sera "mejor"? o solo sera distinta? o mas alla... que es mejor? el rock? el hip hop? o la musica clasica? quiza la musica new age? o prefieres... ahi esta la clave: "prefieres" lo convierte en algo subjetivo, una cuestion de gustos, y no de ser mejor (y yo, al menos en medicina, no considero que lavarse las manos antes de operar a alguien sea cuestion de gustos... igual que no lo es la combinacion de quimicos que usan para la antestesia...o la formula matematica para decidir si un puente aguantara determinado peso: en esos casos, se trata de modelo matematicos o estadisticos con resultados cuantificables.

Basandome en la libreria ANTLR para construir un arbol de tokens, hize un modelo de objetos donde todo token implementa una Expresion, y un metodo evaluar que me regresa un resultado...

Con programacion estructurada? Pues usando yacc y lex.... por otro lado, segun algunas personas, el mejor paradigma para escribir interpretes no es ni el procedural ni el orientado a objetos, si no el funcional (con cosas come Scheme o Lisp)...

No estoy diciendo que en la estructurada no se pueda, simple y sencillamente estoy diciendo que la forma de hacerlo cambia radicalmente.

Exacto, como cambia, como la diferencia entre el sonido de un violin y de una flauta. Pero "cambio" no implica "ser mejor" solo implica "ser distinto". (Por otro lado si a poder vamos, hay quienes piensan que nada como Lisp, pero... tendran razon?)

Con los closures, no cambia radicalmente nada segun yo, es solo la posibilidad de crear la implementación de un metodo sin haberlo definido antes. Que eso te ahorra la lata de andar definiendo interfaces e implementaciones de manera general, pues sí, si te lo ahorra.

Bueno, con los closures, y quiza algo de azucar mas, Java empezaria a moverse en direccion del paradigma de programacion funcional y eso cambia mucho el estilo de programacion (si crees que cambia poco, investiga mas)... en C#, por ejemplo esa tendencia permitio la entrada de cosas como LINQ y si la tendencia continua en esa direccion, se abren muchas otras puertas... mejores? algunos creen que si... pero... lo son?

Imagen de luxspes

Mas? quien sabe. Dinamico, alla tambien, diferente pero, mejor?

La máquina virtual de Java, de hecho ya tiene muchisimos más lenguajes que el CRL.

Para nombrar solo algunos que ya fueron mencionados en este post: Groovy, Scala, Ruby, Python, Clojure ( bueno ese nadie lo mencionó )

Seguro que son mas?. Y mas alla del numero... cuantos de ellos tienen el soporte de grandes empresas (tamaño Microsoft), en el CLR, tienen ese nivel de soporte: C#, F#, VB.NET, C++ y proximamente IronPyton, IronRuby (ademas de los soportados por comunidades). En el caso de la JVM, que yo sepa, con apoyo oficial de Sun (ahora Oracle), solo Java y un poquito JRuby y Groovy (y en mi opinon no al nivel que Microsoft apoya a lo suyos).

Algo que si se va a hacer ( bueeeno, el día que se decidan sacar la siguiente verisión ) es incluir un nuevo llamado a nivel de la VM "invokeDynamic" que en resumidas cuentas, les quitará a estos lenguajes dinamicos, la necesidad de andar dandole vueltas y vueltas al modelo que tiene Java actualmente.

Supongo que sera el equivalente al DLR

Sobre la crítica, OOP me dio un poco de fiaca,leerla, pero es importante recalcar, que ningún paradigma es perfecto y muchas veces los principios equivalentes, solo que se llaman diferentes.

Ese es uno de los aspectos centrales de la critica... te recomiendo mucho leerla, ayuda a tener una perspectiva mas profunda del por que de como se programan las cosas orientadas a objetos... en mi caso sigue gustándome OOP, pero ahora ya no estoy seguro de que sea el mejor modo en todos los casos... ni siquiera en los casos que tradicionalmente se le considera mejor (como por ejemplo, cuando se le compara con el enfoque relacional)

Imagen de Nopalin

jajajaja

Yo creia que estabamos debatiendo algo, pero no, simplemente te estas limitando a invocar los pros y contas de todo y estando en esa posición, te limitas a ser objeto de cuestionamientos.

Pero tienes razón en algo, diferente no es equivalente a mejor, aunque en muchos contextos si lo es, o dime tu si es lo mismo andan en un ferrari a 200 kilometros por hora en una carretera de tierra con lodo y enpedrada que en una autopista? la autopista se hizo complementamente distinta y es obvio que es mejor. Ahora me vas a decir, mejor para quien, para un ferrari? o para un caballo?, pues para un caballo no, cierto? entonces el cambio en la hechura de la carretra es mejor para algunos contextos.

Y es lo que se aplica ahora, quienes programan a bajo a nivel no usan para nada java y estoy seguro que tampoco scala, groovy y demas, programan en ensamblador. Quienes programan en el kernel de linux lo hacen en c. Muchos otros en c#, java, ruby, php o lo que quieran, eso lo deciden dependiendo el contexto donde lo van a implementar, decir como tu bien lo comentas que un paradigma es mejor que otro asi nomas por que sí, es una completa falacia, se dice que es mejor para la aplicación que se va a realizar.

¿La programación funcional realmente va solucionar los bugs de los programas?, ¿los va ha evitar?, ¿va a hacer la tarea del programador más fácil?, ¿va ha hacer mas legible el codigo?

Si no es basado en un modelo matematico con resultados cuantificables, entonces es algo que "sientes"

Segun tu definicion ¿todo lo que sea detectado por los sentidos del ser humano son "sentimientos"?. Si veo que un automóvil que viene directo a mí, me quito por que así lo siento, o me quedo?. Lo bueno de todo esto es que creo que será acaso el 99% de la población mundial que toma desiciónes basadas en lo que sienten (aclaro, el dato es lo que siento, por experiencia, no hize una encuesta y mucho menos un modelo matemático).

sobres

Imagen de luxspes

El relativismo tambien es un punto de vista

Yo creia que estabamos debatiendo algo, pero no, simplemente te estas limitando a invocar los pros y contas de todo y estando en esa posición, te limitas a ser objeto de cuestionamientos.

De eso nos tachan a los relativistas a veces, de no defender un punto de vista, pero no es asi, si defendemos un punto de vista: que las cosas son relativas a su contexto. Estamos en contra de las afirmaciones descontextualizadas del tipo "esto es lo mejor" o "esto es bueno", al final, todo eso debe estar enmarcado en un contexto "bueno para que?". Si tu crees que se puede afirmar algo asi, sin un contexto, tendremos un debate tipo "lucha frontal de puntos de vista opuestos".

Pero tienes razón en algo, diferente no es equivalente a mejor, aunque en muchos contextos si lo es, o dime tu si es lo mismo andan en un ferrari a 200 kilometros por hora en una carretera de tierra con lodo y enpedrada que en una autopista? la autopista se hizo complementamente distinta y es obvio que es mejor.

Es obvio? Ciertamente no para todos... y especialmente no si eres una iguana tratando de cruzar y te aplasta un carro ;-)

Ahora me vas a decir, mejor para quien, para un ferrari? o para un caballo?, pues para un caballo no, cierto? entonces el cambio en la hechura de la carretra es mejor para algunos contextos.

Has aprendido bien, pequeño saltamontes.

...decir como tu bien lo comentas que un paradigma es mejor que otro asi nomas por que sí, es una completa falacia, se dice que es mejor para la aplicación que se va a realizar.

Exacto, la cosa es que en muchos casos que he visto, la herramienta se elije primero (y eso es algo de lo que critica el autor de la liga de OOP Critisism). Se dice antes que nada: Haremos esto con programación orientada a objetos en Java, o en C++, o en... antes de siquiera detenerse a ver si ese problema no se resolveria mas facilmente, por ejemplo, con un enfoque funcional... o con un enfoque relacional (y por cierto Relacional != SQL).

¿La programación funcional realmente va solucionar los bugs de los programas?, ¿los va ha evitar?, ¿va a hacer la tarea del programador más fácil?, ¿va ha hacer mas legible el codigo?

Bueno, depende, una de las ventajas de la programacion funcional es que se puede especificar algoritmos sin informacion compartida. Lo cual, para casos en los que se quiere aprovechar el creciente paralelismo (mutiprocesadores) de los equipos modernos simplemente elimina toda una amplia gama de bugs.

Segun tu definicion ¿todo lo que sea detectado por los sentidos del ser humano son "sentimientos"?.

La palabra correcta, segun yo, para "todo lo que sea detectado por los sentidos del ser humano" son "sensaciones", ahora bien, yo no estoy hablando de sensaciones, estoy hablando de las conclusiones que sacas a partir de lo que percibes. Esas conclusiones pueden ser producto de un riguroso proceso de analisis, o ser producto de de "sentimientos" o "intuiciones". A veces, las intuiciones pueden ser tremendamente acertadas, otras veces, se puede cometer horrendos errores de decisión a partir de ellas. La ciencia tambien se equivoca, pero su objetivo no es evitar los errores, si no aprender de ellos, y limitar el impacto al que una mala intuicion te puede llevar.

Si veo que un automóvil que viene directo a mí, me quito por que así lo siento, o me quedo?

No entiendo el sentido de esta pregunta... la respuesta como en muchos casos depende del contexto: te sientes deprimido? sientes que la vida ya no vale nada? te quieres morir? pues te quedas. Crees que vale la pena vivir? estas contento? tienes cosas todavía por hacer y por ver? te mueves.

Lo bueno de todo esto es que creo que será acaso el 99% de la población mundial que toma desiciónes basadas en lo que sienten

Lo... bueno? bueno para que? para propiciar la quema de brujas? el castigo de chivos expiatorios? la construcción de puentes que "le latia al ingeniero que no se derrumbaba", pero "pues ni modo, se derrumbo, lastima de los muertitos"? Para el que dijo que despegara el challenger, por que le latia que no explotaba? Bueno para el perro al que tiene un dueño que "le late" que chocolate, al no ser venenoso para los humanos, no lo es tampoco para los perros?. Bueno para una empresa que cree que con aplicar la tecnología XXX se van a resolver todos sus problemas? Bueno para los enfermos de Cancer muertos victimas de Therac-25?

(aclaro, el dato es lo que siento, por experiencia, no hize una encuesta y mucho menos un modelo matemático).

Se nota, amigo mio, por que si te hubieras detenido a pensar científicamente un momento, te darias cuenta que no quieres que tu doctor te de la medicina que "le late", ni quieres que el cuate que construyo el edificio en que vives o en el que trabajas haya decidido que la construcción "le latia" que no se derrumbaba (y luego perecer en los escombros)... ni al que construyo a cualquier dispositivo de baterias que uses "le lata" que no te explota en la cara la proxima vez que lo uses. Y probablemente, si te detuvieras a pensar, tampoco querrias usar el lenguage o paradigma de programacion que "te late" si no aquel que mejor se ajuste al problema que quieres resolver.

Ahora no estoy diciendo aqui que las intuiciones no tengan su importante lugar en la toma de decisiones, pero hay que tener cuidado de abusar de ellas, y empeñarse en comprender, cuando son acertadas, por que lo son, y como podemos convertir un exito fortuito en algo repetible

Imagen de ezamudio

relativismo

El problema de los relativistas es que piensan que lidiar con absolutos nunca es bueno. /*Bazzinga*/

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">