Es un grupo de enfermedades que afectan al crecimiento celular anormal con el potencial de invadir o propagarse a otras partes del cuerpo. En los últimos 15 años, desde que estalló la primera burbuja de software y los desarrolladores se dieron cuenta de que necesitaban una nueva forma de hacer dinero fácil, ha habido una tendencia alarmante y no controlada en el crecimiento de lenguajes de software y disciplinas de desarrollo, todo diseñado para sostenerse a si mismos. Y se sostienen. Un organismo vivo con una extensión sin precedentes. Cáncer.
Comentarios
A mí lo que más me ha gustado ha sido eso de hacer dinero fácil.
El tipo que ha escrito esto no ha programado en su puta vida.
#6 Dinero fácil lo hacen muchos, que lo cobre el programador es otro tema...
#21 Porque puedes poner múltiples resultados. Si solo pudieras poner 2 te garantizo que no se llamaría apuesta múltiple, sino apuesta doble. ¿Al final todo consiste en darle la vuelta a las cosas para no reconocer el error? En fin...
El tema es que los propios programadores están intentando crear bastiones inexpugnables en torno a lenguajes de culto, que poco o nada tienen que aportar:
Python y sus multiples versiones incompatibles entre sí, Ruby on Rails, Scala, NodeJS. Y ahora para complicarlo se crean los frameworks, que son dependencias dentro de cada lenguaje que hacen que el código sea difícilmente transportable.
Por ejemplo usando el sencillo PHP, si haces algo para Symfony, no funciona en Codeigniter, o en Laravel.
Ahora está de moda el rollo del Composer... como si simplificara algo... cada vez más y más complejidad, para un Hello World!
Y el infernal git... con posibilidad de múltiples ramas, versiones e historias y cuando haces un merge hay que poner una cruz al santo...
La industria está cayendo en la trampa y ahora piden especialistas en Python, Ruby y HTML5 con 10 años de experiencia, ¡si hace 10 años ni siquiera existían!
El colmo son los ORM, intentando llevar la complejidad de un JOIN al lenguaje procedural. Pero es imposible. En cuanto necesitas una consulta medianamente compleja no hay traslación al ORM que valga. Hay que hacer la consulta en SQL con sus subquerys sus JOIN y todo lo que caiga.
#12 "Python y sus multiples versiones incompatibles entre sí"
Que yo sepa solamente hay 2 versiones incompatibles... 2.x con la 3.x
#13 Exacto. Ya dos versiones son múltiples versiones, no una única versión. Y la rama 3.x es incompatible con la 2.x y viceversa. No hay compatibilidad retrógrada.
#16 ¿Exacto? definir como múltiples 2 cosas... muy exacto no es que digamos.
#18 Si te dicen que juegues una apuesta múltiple, con que sean dos ya te vale. No malgastes el dinero.
#c-12" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2752769/order/12">#12 #13 Python es una puta mierda que esta de moda por no se que razon, y para empezar a enumerar porque es una mierda, ni puedes programar con "threads reales" (cuando hoy en dia tenemos PC y moviles con cada vez más nucleos y/o cores).
"La ejecución de los threads en Python está controlada por el GIL (Global Interpreter Lock) de forma que sólo un thread puede ejecutarse a la vez, independientemente del número de procesadores con el que cuente la máquina. Esto posibilita que el escribir extensiones en C para Python sea mucho más sencillo, pero tiene la desventaja de limitar mucho el rendimiento, por lo que a pesar de todo, en Python, en ocasiones nos puede interesar más utilizar procesos que threads, que no sufren de esta limitación."
http://mundogeek.net/archivos/2008/04/18/threads-en-python/
Lo dicho, mierda.
Antes se puso de moda otra mierda como Java y su competencia de Microsoft como es C#.
Si fuera por mi dejaba solo unos poco lenguajes y el resto a quemarlos: C/C++, PHP, HTML, CSS, LUA y algun otro más, pero el resto como Java, C#, Python, Visual Basic, etc que no aportan nada que no aporte C/C++ son mierda para meter mas mierda. Y de Frameworks para C/C++ dejaria Qt y unas cuantas librerias/SDK que completen Qt (como por ejemplo OpenGL, DirectX, OpenCV, etc)
#17 Es que se trata de un tema económico. Python es sencillo y han desarrollado miles y miles de librerías. Es muy usado en el ámbito científico y financiero. Se ven los pros y los contras. Tu ves una contra ( que tienes razón , no digo que no ) pero los demás ven una serie de ventajas que le permiten sacar un rendimiento económico al ayudarles a hacer mejor su trabajo. Pero vamos, que seguro que más de uno tendrá la misma queja que tu y se pondrán a ello. Ten en cuenta que el creador de python trabaja para Google, donde python es uno de los lenguajes principales junto java y c.
#c-20" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2752769/order/20">#20 El problema de hoy en dia es que con tantas encapsulaciones de alto nivel y lenguajes "quiero y no puedo" copias de C/C++ como Python, Java y C#, al final se generan miles de frameworks con librerias integradas en esos lenguajes que por debajo usan C/C++, (ahora mismo se me ocurre por ejemplo Unity3D, programado en C/C++ y que usa C# y Javascript como lenguajes base "front-end", pero que cuando compila para Android por ejemplo genera codigo en C/C++ usando JNI. Todo eso es una cosa infumable que mete mucha mierda infumable al codigo pudiendo hacer directamente la aplicacion en C/C++ STD. (Y hoy en dia con C++11 y C++14 es muy potente el lenguaje)
Todas estos lenguajes como C#, Java y Python, aun consiguiendo mejoras de rendimiento en los ultimos tiempos, siguen sin tener la potencia de C/C++ que haria que bien programadas, las aplicaciones tanto para móviles, PC's, sistemas embebidos, Bases de Datos, etc, fueran super potentes aprovechando el hardware de hoy en dia mucho mejor, donde hoy tenemos procesadores i5 o i7 con 4 o 8 nucleos y moviles igualmente con 4 o mas cores al alcance de cualquier persona.
En cambio, se desecha (o se intenta evitar el uso de) C/C++ (en favor de Python, Java y C#) en la mayoria de veces, proque a los programadores de hoy en día no les gusta eso de los "pointers" y el "memory management", sino que se acostumbran a un "garbage collector" que se supone que les hace el trabajo por ellos, y eso lo unico que genera es que los programadores de hoy en dia se mal acostumbren y generen aplicaciones poco eficientes, y con memory leaks (en Java y C#, aunque exista el garbage collector, tambien existen memory leaks, pero el acostumbrarse al garbage collector hace que la mayoria de programadores en esos lenguajes no caigan en el detalle de como se produce la mayoria de las veces, por ejemplo cuando cargas un programa Java en Apache, lo cierras sin desactivarlo de Apache con lo que sigue en memoria y cargas otra instancia del mismo programa, que hace que se quede una instancia zombie en memoria).
El problema de hoy en dia con la multitud de lenguajes y frameworks raros que si, permiten programar una aplicacion mas rapido, pero hacen que se aleje el software del hardware. ¿de que sirve que Intel saque el super mega guay procesador con 100 nucleos y una RAM de 200Gb o que saquen un mega movil con 30 cores y 80gb de RAM si luego las aplicaciones no aprovechan ese hardware o las aplicaciones se cuelgan por memory leaks no controlados confiando en el garbage collector.
Como cosa curiosa, me hace mucha gracia que muchas aplicaciones como compiladores de python, maquina virtual de java, compiladores de C#, firefox, chrome, visual studio, 3d studio, opera, unity3d, estan programadas en C/C++ pero luego el uso de ese lenguaje en Consultorias/banca/ X sector no lo usa para nada y usa un compilador hecho en C/C++ para programar en Java/C#/python simplemente por el hecho de si esta de moda el lenguaje en su epoca y segun el marketing que haya tenido en su epoca ese lenguaje.
Estos días estoy aprendiendo Angular 2, y parece un tumor maligno que crece y muta sin control. Te lleva semanas aprender los entresijos, la curva de aprendizaje es muy alta, un simple hola mundo pesa 2,5 Mb, y un elemento clave de todo el tinglado, los decoradores, no es un estándar web, está en fase de aprobación y puede sufrir cambios, mandando al garete todo el framework
https://angular.io/
En cambio hay otro framework/librería que me impresiona por su sencillez y elegancia, es como extirpar el tumor y curar la herida. En 15 minutos puedes ver un tutorial de Vue, aprender lo básico y sacarle partido, la curva de aprendizaje es muy baja, la librería solo pesa 18 Kb, la incluyes y ya puedes incluir programación reactiva en tu proyecto sin volverte loco en el intento.
https://vuejs.org/
#10 Idem. La misma decisión he tomado yo. Y por cierto, angular 4 ha salido, así que ya estás desfasado.
Antes se programaba mejor, los políticos no robaban tanto, los menores respetaban más a los mayores, las cosas estaban más baratas... aaay abuelo.
#2 y había muchos menos jovenes y mucha más gente mayor!
#2 y todo esto era campo.
Yo estoy impresionado por la cantidad de frameworks y productos distintos que es necesario usar para hacer funcionar un servicio normal sobre una web, móviles, escritorio, etc.
Dicen que todo eso mejora la mantenibilidad, y tienen razón en parte. Pero quieren decir la mantenibilidad por parte de un desarrollador que conozca todos los lenguajes usados (varios por aplicación) y herramientas. Ese mantenedor es un puto experto en el tema....
Que el año que viene estará desfasado.
#7 Pero imagina lo que costaría lograr esa misma funcionalidad sin frameworks ni librerías, programando a mano cada proceso desde cero. Te tirarías un año para hacer una web que ponga "Hola mundo".
No le gustan que haya lenguajes y que evolucionen, no le gusta JSON ni las APIS, no le gustan ni las tabs de los navegadores. No le gusta nada a este hombre.
Pero si algo me ha llamado la atención es la conclusión como comparación dice "cuando voy al restaurante no quiero saber que está haciendo personal con mi comida" Que aunque no lo usa para eso me parece un gran alegato a favor del software libre. Igual no está mal saber que si quieres puedes echar un ojo, o por lo menos que hay auditores independientes que lo han hecho...
#15 Del autor del artículo: "El propósito de la tecnología, incluido el software, es hacer la vida más fácil, más productiva, más segura, más agradable. Un medio para un fin, no el fin [en sí mismo]"
No. Nunca es "no lo cambies". Si fuera así todavía estaríamos en la prehistoria. Se trata de progresar. Se trata de cambiar las cosas para mejorar, para hacer las cosas más fáciles y sencillas, no para complicarlas, y tampoco cambiar por cambiar, el cambio en sí no es el objetivo, el objetivo es mejorar las cosas.
De lo que habla el artículo es que muchas cosas que se están haciendo no son realmente progreso, sino todo lo contrario, no mejoran, no simplifican, sino que empeoran la situación del desarrollo del software.
Hoy en día entro a la cocina, abro una llave y sale agua caliente. Hace 100 años atrás eso no existía para la mayor parte de la gente del mundo. Eso es progreso. El software no es así en muchos aspectos, y sí es así en otros. Por ejemplo, para hacer páginas web se usa un manejador de contenido mientras que antes se hacía a mano. Ahora es muchísimo más fácil. Pero hay otras cosas, que menciona el escritor del artículo, en donde sucede todo lo contrario y es un verdadero desastre.
Y cómo actuará el cáncer.
Se crearán cada vez más capas y capas de software, y framework sobre otros frameworks. Y las cosas se volverán cada vez más complejas. Pero a nadie le importa que las cosas estén bien hechas, y por lo tanto, todas esas capas de software están llenas de bug.
Pero por si fuera poco, en vez de corregir bugs, es más bonito añadir nuevas funcionalidades en cada capa y en cada pieza de código, añadiendo más bugs tanto en el código como en las interacciones entre los códigos, reapareciendo los ya corregidos. Pero luego, será más importante crear MÁS FUNCIONALIDADES que corregir los nuevos bugs o los anteriores. El resultado, la entropía (bugs) va creciendo en el tiempo sin que a nadie le importe.
Y así, la gran torre de naipes [1] seguirá creciendo hasta que algún día, dentro de algunas décadas, todo estará tan podrido que la torre de naipes se vendrá abajo.
[1] Es torre de naipes, porque a casi nadie le importa hacer las cosas bien, código robusto y confiable como una roca (COMO UN TEOREMA MATEMÁTICO). Porque es más importante añadir nuevas características a un código que ya está malo en lugar de corregir las cosas, y así aumentar la entropía del sistema. Tontos, están creando el instrumento de su propia destrucción.
#5 Eso, exactamente, es lo que pide este artículo. No lo cambies. No lo reescribas. Si funciona, en todo caso parchéalo y maquíllalo.
Que peazo Troll !!!!
Aunque en muchas cosas, razón no le falta.