Artículo original por Bruce Eckel (ingles)
14 de Marzo, 2009
Resumen
En una discusión reciente, he oído afirmaciones de que C++ fue un lenguaje pobremente diseñado. Yo he estado en el Comité de Normas de C++ por 8 años, y he visto tomar decisiones en este tiempo. Pienso que es útil entender las opciones C++ y Java con el fin de tener una mejor perspectiva.
Yo no uso casi nunca C++. Cuando lo hago es para examinar un código en un sistema heredado o para escribir pequeñas partes de código crítico, para ser llamado por otro código (mi preferencia es escribir código rápidamente en Python entonces si es necesario mejorar el rendimiento, llamo pequeñas partes de código en C++ usando la librería ctypes de Python).
Debido a que estuve el Comité de Normas de C++, he visto como se toman las decisiones. Lo cual es de una forma extremadamente cuidadosa y analizada, mucho más que como son tomadas en Java.
Sin embargo, las personas señalan acertadamente, que el lenguaje resultante es complicado y doloroso de usar, y lleno de reglas extrañas que he olvidado en cuanto me he distanciado por poco tiempo de él – y yo había deducido estas reglas mientras escribía mis libros (No memorizándolas).
Para entender como un lenguaje puede ser al mismo tiempo desagradable, complicado y bien diseñado, debemos mantener en mente la decisión inicial de diseño sobre la cual todo C++ se basó: compatibilidad con C. Stroustrup decidió – y correctamente, parecería – que la forma de obtener masas de programadores de C y moverlos hacia los objetos eras hacer la migración transparente: permitirles compilar su código en C sin cambios bajo C++. Esto era una inmensa restricción, y fue siempre la gran fortaleza de C++… y su perdición. Hizo a C++ exitoso y complejo al mismo tiempo.
También engañó a los diseñadores de Java que no entendían suficientemente C++. Por ejemplo el operador sobrecargado era demasiado complejo de usar correctamente por parte de los programadores. Lo cual es básicamente cierto en C++, ya que C++ tiene dos lugares de almacenamiento en el stack y el heap y usted debe sobrecargar sus operadores para manipular todas las situaciones y no causar lagunas de memoria. Trabajoso realmente. Java, sin embargo, tiene un único mecanismo de almacenamiento y un recogedor de basura, lo cuál hace al operador de sobrecarga trivial – como fue mostrado en C# (Pero antes en Python, el cual precedió al Java). Pero por muchos años, la línea particular del equipo de Java fue “El operado de sobre carga es muy complejo.” Esta y muchas otras decisiones fueron de alguien que claramente no hizo su tarea, es el porque tengo la reputación de estar en desacuerdo con muchas de las decisiones tomadas por Gosling y el equipo Java.
Existen muchos ejemplos. Primitivas “tuvieron que ser incluidas para lograr eficiencia.” La respuesta acertada sería decir “Todo es un objeto” y proveer una puerta trasera para actividades de bajo nivel cuando la eficiencia fuera requerida (esto también hubiera permitido tecnologías para hacer transparente hacer cosas con más eficiencia, cuando eventualmente las tendrían). Oh, y el hecho de que usted no puede usar el procesador de punto flotante directamente para calcular (de hecho es por software). He escrito acerca de problemas como estos tanto como mi entendimiento y razonamiento me lo han permitido, y la respuesta que siempre he obtenido ha sido algo automático “Esta es la forma de hacer del Java”.
Cuando escribí sobre lo mal que los genéricos estaban diseñados, obtuve la misma respuesta, “nosotros debemos mantener compatibilidad con las anteriores malas decisiones hechas en Java.” Con el tiempo más y más personas han ganado experiencia suficiente con Genéricos para ver que realmente son difíciles de usar – de hecho, templates en C++ son mucho mas poderosos y consistentes (y más fáciles de usar en estos momentos, que los mensajes de error en la compilación que son tolerados en Java). Las personas toman la rectificación seriamente – algo que sería provechoso pero no una mella en el diseño que está cojo por restricciones auto impuestas.
La lista continua hasta un punto en que se hace simplemente tediosa.¿ Esto implica el fracaso de Java? Absolutamente no. Java trajo la al mundo el recolector de basura, maquinas virtuales y un modelo consistente de manejo de errores (especialmente con la substracción del chequeo de excepciones, lo cual es posible usando técnicas que muestro en Thinking in Java, 4e). Con todas las fallas, nos ha movido a un nivel superior, al punto en el cual estamos listos para lenguajes de más alto nivel.
En un tiempo, C++ fue un lenguaje líder y las personas pensaron que siempre sería así. Muchos piensan lo mismo de Java, pero Java ha hecho aun más fácil sustituirse así mismo, debido a la JVM. Es posible para alguien crear un nuevo lenguaje y tenerlo corriendo eficientemente como Java en un corto tiempo. Previamente obtener un compilador eficiente tomaba la mayor parte del tiempo de desarrollo para el nuevo lenguaje.
Hemos visto esto pasar – con nuevos lenguajes estáticos y dinámicos como: Scala, y Groovy, Jroby y Jython, respectivamente. Este es el futuro, y la transición es muy suave debido a que es fácil usar estos nuevos lenguajes en conjunto con el código Java existente, y usted puede reescribir los cuellos de botella en Java si es necesario.
El mismo Java va a ir quedando atrás de la misma forma que lo hizo C++, solo será usado en casos especiales (o quizás para soporte técnico de código heredado, debido a que no tiene la misma conexión con el hardware que C++) . Pero el beneficio no intencional, la brillantes accidental de Java esta en que creó un camino muy bueno para su propio reemplazo, aun cuando el mismo Java ha llevado a un punto en el cual no puede evolucionar. Todos los lenguajes futuros deben aprender de esto: crear una cultura donde sea posible refactorizar el lenguaje (como Python y Ruby han hecho) o permitir a las especies competitivas crecer.
viernes, 21 de mayo de 2010
Lo bueno de PHP
Artículo original Bruce Eckel(ingles)
Mayo 26, 2008
Resumen:
Usted puede usarlo simplemente un poco.
Es actualmente impresionante que usted no necesite saber mucho del lenguaje para hacer uso de él. ¿Cuántos lenguajes usted conoce que den esta posibilidad? En el otro extremo se encuentra Java, el cual requiere un manojo de conocimientos para “Hola mundo”, y para poner a punto una app web, un barco. En PHP es trivial.
Eso nos dice que PHP es algo mejor que Perl cuando quiere invitarte a un mal comportamiento. Recuerdo en los inicios de la Web escuchar personas decir que iban a construir grandes aplicaciones en Perl, y sabía (sin esperanzas de convencerlos) que iban a fracasar.
PHP, por otro lado ha creado definitivamente grandes aplicaciones. Ejemplo de ello Drupal. Mi amiga Nancy Nicolaisen (una blogger aquí) me dijo que quería poner sitio web de viajes y le sugerí Drupal. Finalmente esa fue su elección – ya que la comunidad de usuarios era agradable y solidaria – tiene el sitio corriendo con un mínimo de esfuerzo.
PHP permite a los novatos hacer cosas en las que están interesados si entrar en la maleza de mucha programación, teoría y práctica. Usted simplemente lo hace y sale en la Web.
Pero también eso es un problema con el lenguaje. Usted puede encontrar toneladas de ejemplos mal programados de cómo hacer algo en PHP, escritos por personas que solo copian unos de otros debido a que ninguna sabe que preguntas elaborar. Uno de mis primeros andares por el lenguaje fue para ver ejemplos de cómo PHP bloquea ficheros, encontré muchos, todos simplemente todos mal. PHP esta principalmente pensado para ser usado con una base de datos que se ocupe de manipular la consistencia, por lo tanto usted no tiene que preocuparse de ese tema de bajo nivel. Pero el lenguaje trata la interacción de alto nivel con una base de datos de la misma forma que una de bajo nivel, es por esto que aquí no hay “Dragones” señales que los iniciados en el lenguaje necesitan, en mi percepción existen tantos “Solo has que funcione” en la comunidad de seguidores del PHP y muy pocos que realmente entienden lo fundamento de la programación, que la tendencia es hacer mal cuando usted inocentemente se aventura en el territorio.
Y ahí nos encontramos con PHP 5, con un básico fregadero de funcionalidades sacadas de C++ y Java, y aunque es impresionante que hayan logrado que funcionen entre tanta conglomeración, mi sentidos me advierten alguien trata de atrapar funcionalidades de cualquier lugar en lugar de considerar cada una cuidadosamente y su impacto en el lenguaje – en contraste, he visto Python tomar cuidadosamente sus decisiones durante mas de 10 años. El tiempo dirá, y quizás la comunidad resuelva que hacer con todas esas funcionalidades, aunque me da mala espina.
Mientras uso PHP en mi nueva, lenta implementación de mi sitio. La clave es: Usarlo en solo pequeñas porciones. Por ejemplo, PHP permite resolver el problema tonto de cómo incluir fácilmente código PHP con HTML. PHP solo lo hace, permitiendome fácilmente distribuir mi diseño a través del sitio. Y algunas veces usted desea hacer algo pequeño embebido en su página web, PHP es la respuesta acertada para hacer eso.
Pero en cuanto las cosas se ponen seria y complejas, he mejor cambiar a Python . Entonces PHP es bueno en pequeñas piezas pero no trate de llevarlo mucho más lejos.
Usted puede encontrar una buena colección de links de discusión sobre el tema aquí
Mayo 26, 2008
Resumen:
Usted puede usarlo simplemente un poco.
Es actualmente impresionante que usted no necesite saber mucho del lenguaje para hacer uso de él. ¿Cuántos lenguajes usted conoce que den esta posibilidad? En el otro extremo se encuentra Java, el cual requiere un manojo de conocimientos para “Hola mundo”, y para poner a punto una app web, un barco. En PHP es trivial.
Eso nos dice que PHP es algo mejor que Perl cuando quiere invitarte a un mal comportamiento. Recuerdo en los inicios de la Web escuchar personas decir que iban a construir grandes aplicaciones en Perl, y sabía (sin esperanzas de convencerlos) que iban a fracasar.
PHP, por otro lado ha creado definitivamente grandes aplicaciones. Ejemplo de ello Drupal. Mi amiga Nancy Nicolaisen (una blogger aquí) me dijo que quería poner sitio web de viajes y le sugerí Drupal. Finalmente esa fue su elección – ya que la comunidad de usuarios era agradable y solidaria – tiene el sitio corriendo con un mínimo de esfuerzo.
PHP permite a los novatos hacer cosas en las que están interesados si entrar en la maleza de mucha programación, teoría y práctica. Usted simplemente lo hace y sale en la Web.
Pero también eso es un problema con el lenguaje. Usted puede encontrar toneladas de ejemplos mal programados de cómo hacer algo en PHP, escritos por personas que solo copian unos de otros debido a que ninguna sabe que preguntas elaborar. Uno de mis primeros andares por el lenguaje fue para ver ejemplos de cómo PHP bloquea ficheros, encontré muchos, todos simplemente todos mal. PHP esta principalmente pensado para ser usado con una base de datos que se ocupe de manipular la consistencia, por lo tanto usted no tiene que preocuparse de ese tema de bajo nivel. Pero el lenguaje trata la interacción de alto nivel con una base de datos de la misma forma que una de bajo nivel, es por esto que aquí no hay “Dragones” señales que los iniciados en el lenguaje necesitan, en mi percepción existen tantos “Solo has que funcione” en la comunidad de seguidores del PHP y muy pocos que realmente entienden lo fundamento de la programación, que la tendencia es hacer mal cuando usted inocentemente se aventura en el territorio.
Y ahí nos encontramos con PHP 5, con un básico fregadero de funcionalidades sacadas de C++ y Java, y aunque es impresionante que hayan logrado que funcionen entre tanta conglomeración, mi sentidos me advierten alguien trata de atrapar funcionalidades de cualquier lugar en lugar de considerar cada una cuidadosamente y su impacto en el lenguaje – en contraste, he visto Python tomar cuidadosamente sus decisiones durante mas de 10 años. El tiempo dirá, y quizás la comunidad resuelva que hacer con todas esas funcionalidades, aunque me da mala espina.
Mientras uso PHP en mi nueva, lenta implementación de mi sitio. La clave es: Usarlo en solo pequeñas porciones. Por ejemplo, PHP permite resolver el problema tonto de cómo incluir fácilmente código PHP con HTML. PHP solo lo hace, permitiendome fácilmente distribuir mi diseño a través del sitio. Y algunas veces usted desea hacer algo pequeño embebido en su página web, PHP es la respuesta acertada para hacer eso.
Pero en cuanto las cosas se ponen seria y complejas, he mejor cambiar a Python . Entonces PHP es bueno en pequeñas piezas pero no trate de llevarlo mucho más lejos.
Usted puede encontrar una buena colección de links de discusión sobre el tema aquí
Estupidez Colectiva
Artículo original Bruce Eckel(ingles)
Agosto 5, 2008
Resumen
¿Por qué una compañía llena de personas inteligentes toman decisiones tontas? ¿Cómo esto continúa pasando?
La tendencia general es tomar las decisiones que son aceptables por el menor común denominador; decisiones que nadie esta en desacuerdo – debido a que es más fácil y menos contencioso. Pero no es un camino al éxito.
Microsoft es un blanco fácil hoy en día, esto se debe a que es un gran rompecabezas. Lleno de gente inteligente, ciertamente con infinitos recursos financieros. Engañados ellos mismos, están en el borde del precipicio. Finalmente he descubierto la razón por la cual Bill Gates proclama a viva voz que la innovación es de lo que se trata Microsoft, en realidad, no es que él realmente lo crea, sino, es lo que él quisiera que fuera. Se ha dado cuenta que la única manera de que una compañía sobreviva es convertirse en innovadora. Y se sale ya que eventualmente ha entendido que no hay forma de evitar que el barco choque con el iceberg.
La compañía que evite el fenómeno de la estupidez colectiva es una anomalía estadística. Algo sobre la manera en que nosotros hacemos y pensamos sobre las decisiones – algo tan fundamental que lo hacemos debajo del umbral de la conciencia—nos dirige inevitablemente hacia la no innovación, no creatividad, no exitosa organización.
Pienso que un factor es la contratación desesperada de personal que viene aparejado con el crecimiento. Usted debe crecer tanto que comenzará a decir “necesitamos alguien que ocupe esta posición”, “las personas son nuestro más importante recurso” y esta maximización rápidamente nos lleva al fracaso. Comenzamos a contratar personal que no tiene la visión de la compañía, que no encajan en el equipo, pero están “calificados” y disponibles; por otro lado usted tiene un proyecto que necesita comenzar en el acto debido al contrato, el dinero, etc., etc..
Y esas personas eventualmente comenzaran a estar en desacuerdo con las decisiones que una vez fueron claramente visitas como intereses de la compañía, y para aplacarlos entonces esas decisiones son relegadas y rápidamente tendremos estupidez colectiva.
Otro aspecto en el tamaño de grupo. Uno de los principios de Hewlett-Packard era la idea de una unidad de la compañía no debería ser más grande que un pequeño pueblo, de tal forma que fuera posible conocernos entre todos. Si la unidad crece demasiado, era dividida para mantener el tamaño adecuado. Esto tuvo buenos resultados. Parece ser que cuando el grupo crece suficientemente, tenemos un efecto de mediocrizante aun cuando aparentemente todos tratan reavanzar en la misma dirección y sentido.
Quizás la respuesta es mantener todo en tamaño pequeño, mantener la unidades de negocios divididas en equipos donde todos avancen conjuntamente, y evaluar la salud del negocio basándonos en la salud individual de los equipos. Posiblemente sea difícil de lograr un desempeño optimo en cualquier cosa mas grande que una tribu. Eric Raymond una vez me comento que iba a escribir acerca de lo que el consideraba el futuro de los negocios de software, lo cual sería equipos independiente que se unirían para trabajar en un proyecto en particular, y cuando el proyecto esté terminado volverían a ser equipos individuales, volviendo a unir equipos para el proximo proyecto.
Estas son mis opiniones sobre el problema. ¿Qué piensa usted cause la estupidez colectiva, y como sería posible diseñar una estructura organizacional para prevenirla?
Agosto 5, 2008
Resumen
¿Por qué una compañía llena de personas inteligentes toman decisiones tontas? ¿Cómo esto continúa pasando?
La tendencia general es tomar las decisiones que son aceptables por el menor común denominador; decisiones que nadie esta en desacuerdo – debido a que es más fácil y menos contencioso. Pero no es un camino al éxito.
Microsoft es un blanco fácil hoy en día, esto se debe a que es un gran rompecabezas. Lleno de gente inteligente, ciertamente con infinitos recursos financieros. Engañados ellos mismos, están en el borde del precipicio. Finalmente he descubierto la razón por la cual Bill Gates proclama a viva voz que la innovación es de lo que se trata Microsoft, en realidad, no es que él realmente lo crea, sino, es lo que él quisiera que fuera. Se ha dado cuenta que la única manera de que una compañía sobreviva es convertirse en innovadora. Y se sale ya que eventualmente ha entendido que no hay forma de evitar que el barco choque con el iceberg.
La compañía que evite el fenómeno de la estupidez colectiva es una anomalía estadística. Algo sobre la manera en que nosotros hacemos y pensamos sobre las decisiones – algo tan fundamental que lo hacemos debajo del umbral de la conciencia—nos dirige inevitablemente hacia la no innovación, no creatividad, no exitosa organización.
Pienso que un factor es la contratación desesperada de personal que viene aparejado con el crecimiento. Usted debe crecer tanto que comenzará a decir “necesitamos alguien que ocupe esta posición”, “las personas son nuestro más importante recurso” y esta maximización rápidamente nos lleva al fracaso. Comenzamos a contratar personal que no tiene la visión de la compañía, que no encajan en el equipo, pero están “calificados” y disponibles; por otro lado usted tiene un proyecto que necesita comenzar en el acto debido al contrato, el dinero, etc., etc..
Y esas personas eventualmente comenzaran a estar en desacuerdo con las decisiones que una vez fueron claramente visitas como intereses de la compañía, y para aplacarlos entonces esas decisiones son relegadas y rápidamente tendremos estupidez colectiva.
Otro aspecto en el tamaño de grupo. Uno de los principios de Hewlett-Packard era la idea de una unidad de la compañía no debería ser más grande que un pequeño pueblo, de tal forma que fuera posible conocernos entre todos. Si la unidad crece demasiado, era dividida para mantener el tamaño adecuado. Esto tuvo buenos resultados. Parece ser que cuando el grupo crece suficientemente, tenemos un efecto de mediocrizante aun cuando aparentemente todos tratan reavanzar en la misma dirección y sentido.
Quizás la respuesta es mantener todo en tamaño pequeño, mantener la unidades de negocios divididas en equipos donde todos avancen conjuntamente, y evaluar la salud del negocio basándonos en la salud individual de los equipos. Posiblemente sea difícil de lograr un desempeño optimo en cualquier cosa mas grande que una tribu. Eric Raymond una vez me comento que iba a escribir acerca de lo que el consideraba el futuro de los negocios de software, lo cual sería equipos independiente que se unirían para trabajar en un proyecto en particular, y cuando el proyecto esté terminado volverían a ser equipos individuales, volviendo a unir equipos para el proximo proyecto.
Estas son mis opiniones sobre el problema. ¿Qué piensa usted cause la estupidez colectiva, y como sería posible diseñar una estructura organizacional para prevenirla?
Suscribirse a:
Entradas (Atom)
Entradas
