EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#79 Pues yo no. El tío compara win95 con Android.

En Win95 tenías que buscar e instalar los putos driver de tu equipo a mano. Instalar Internet o cualquier otra cosa podía ser un puto infierno. En Android todo viene de serie y todo funciona sin hacer nada y la variabilidad de dispositivos y piezas de multitud de fabricantes distintos es abismal, por no hablar de tamaños de pantalla, resoluciones, etc. Obviamente eso no es gratis. Tienes los controladores y los sistemas dentro del SO. Del tirón.

El precio a pagar por la sencillez es que todo venga dentro de golpe sin tener que hacer cherrypicking de lo que necesitas.

Estoy de acuerdo en algunas cosas que dice pero ni mucho menos en todas. Y él lleva 15 años en esto, yo solo 10, pero tampoco soy el más nuevo del barrio. Las páginas webs y sistemas de hace 10 años eran rápidas y pesaban poco. Y eran una puta mierda. No tenían ningún tipo de funcionalidad, el mantenimiento era nefasto y no había que hacer que una web se viese bien en un puto reloj, en un Ipad, en un Iphone, en una TV de 52 pulgadas, no tenían que tener una API decente, no pintaban ni mucho menos imágenes enormes, el JS era simple pero tenían que cargar una mierda flash que era insegura por defecto...


No creo que el código actual sea peor que el de ayer. Son igual de malos. Las cosas funcionan casi de casualidad, y eso lo sabe cualquiera con unos tiros pegaos. ¿O acaso el TCP no tiene un sistema de redundancia de datos para recuperar que se pierde parte de ellos? ¡Y en UDP se asume que se pueden perder, simplemente consideramos que no importa que pase! Y estamos hablando de cosas básicas sobre las que funciona todo, pero es que... todo es así. Toodo va con pinzas. Yo hace ya tiempo que pienso que eso es el desarrollo, es lo que hay.
#135 Yo creo que no está diciendo que el código sea peor, si no que como se cuenta en el enlace que ha puesto #79 (muy bueno) en general todo se complica hasta la naúsea, también lo han comentado varios. Ahora en general no es que todo tire de librerías más o menos gordas y que bueno, es pasable, puede que el binario y todo lo que arrastre ocupe más pero más lento no tiene por que ser, al final llamas a las funciones que llamas y por lo general las que ya están aceptadas por la comunidad van a ser mejores que las que puedas hacer tú. El problema es que ahora mucho SW tira de frameworks completos que simplemente muchos desarrolladores usan pq es lo que saben, aunque lo conozcan muy bien (si sólo tienes un martillo de oro todo te parecerá un clavo).

Creo que somos muchos ya los que hemos visto en el trabajo como se acaba implantando un entramado de capas, instaladores de módulos, virtualizaciones innecesarias simple y llanamente por que alguno que cae bien o tiene mucha labia vende la moto y el de los galones da el OK.

Al final para hacer una puta mierda de aplicación, tienes ahí un sindios de cosas que complican la entrada de gente nueva por los palos que hay tocar, complican el mantenimiento, aumentan el tamaño y reducen el rendimiento.

Cada vez me gusta más programar para Arduinos y similares por la cantidad de basura que no tienes que tener en cuenta y con la que nadie te va a venir a molestar.
#196 Sí, entiendo esa visión. Es parte un problema de pasta también. Si tienes que hacer algo y no tienes tiempo suficiente para aprender otra tecnología, pues lo haces con lo que tienes (con lo que sabes).

Pero es un problema complejo. También los habrá que no quieren aprender. Otros que no tendrán la capacidad de comprender lo que hay bajo el framework (Javascript a pelo, por ejemplo, es muy duro) y otros mil motivos que no se me ocurren. :-)
#201 Yo en realidad pienso que por lo general nadie es "realmente culpable", se junta un poco de todo, como dices... tema de costes, las empresas al final están para ganar dinero, y a nosotros (los que curramos en el sector, picando...) nos gusta que a fin de mes nos paguen.

Sobre todo a los que somos de vocación nos gusta hacer las cosas lo mejor que sabemos y aprender, y gastar el tiempo necesario en dejarlo bien, con tiempo, experiencia y la capacidad de cada uno esto va siendo menos costoso con el tiempo, pero visto globalmente desde arriba, en que lo que tienes es un mix de "capacidades" al final... lo que quieres es vender el producto o cobrar por lo que haces para tener beneficios y pagar a tu gente, así que muchas veces desde arriba lo que quieren es tenerlo pronto y "cumpliendo", si se puede hacer mejor, más rápido... pero el cliente no va a pagar más ni posiblemente se vaya a enterar... no interesa, es más coste, y en consecuencia la presión va a tenerlo rapidito y baratito.

A mi me han llegado a contar de alguna empresa, pequeña, en la que directamente eran sinceros con el asunto, básicamente lo que se decía a la plantilla es que esfuerzo cero en testing, facilidad de mantenimiento... que funcionase y a correr, pq por lo visto un altísimo porcentaje de lo que desarrollaban no estaba mucho tiempo en el mercado y según sus cuentas eso era dinero tirado.

Luego tampoco es que venga sólo a veces de arriba, quien no tiene un compi hipermotivado que tecnología nueva que aparece tecnología que quiere meter en el producto, dándose casos de productos en los que con el tiempo acabas teniendo 3 o 4 lenguajes, 5 frameworks, movidas de estas instaladoras de módulos, sistemas de compilación, virtualización diversa... lo que iba entrando por que iba a simplificar el mantenimiento o la gestión al final la acaba complicando, por que donde antes el personal tenía que dominar un sistema de compilación o un lenguaje ahora se encuentra con que hay partes en X, partes en Y, 2 sistemas de compilación por que fue imposible quitar del todo el anterior o por que versiones a las que aún hay que dar soporte usan el anterior...
#262 Si, estoy de acuerdo en general con todo lo que dices. Al final... es nuestra profesión :-D Para lo bueno y para lo malo.

Al menos yo tengo la suerte de estar en un sitio donde me obligan (no solo es que me dejen...) a hacer las cosas bien. Con test, bien documentadas... No es la panacea, tiene sus mierdas, como todo. Pero al menos ese gusto me doy :-D
#135 por favor, aunque te entiendo, no metas TCP y UDP y su corrección de errores como ejemplo de “ir con pinzas” o de que funciona de casualidad
#325 Joder, es una forma de hablar. Nada funciona por casualidad, pero no es que sean los protocolos mejor especificados del mundo. Están repletos de parches que hacen que funcionen bien pero está por decidir si esos parches son genialidad que solucionan problemas o chapuza que aguanta el tirón.

Pero que todo es así, he visto tripas de bastantes sitios muy grandes, sistemas que usa muchísima gente, sitios que piensas "buah, esto tiene que estar niqueladísimo" y no, no lo está. Tiene sus mierdas dentro que huelen igual de mal que la de cualquier otro sistema. Pero ahí están, corriendo, dando servicio a millones de personas.
#326 TCP y UDP están diseñados para correr encima de cualquier protocolo de nivel 3 (no tiene porqué ser IP) y, por tanto, podrías decir que su corrección de errores es redundante respecto a protocolos de capas inferiores.

TCP tiene reintentos porque las aplicaciones que lo usen necesitan que sus datos estén completos, aparte de que cada segmento pueda llegar en desorden.

UDP se usa cuando no es necesario que los datos lleguen íntegros, ya que puede no ser necesario o incluso, contraproducente. A cambio, te da una sencillez y un overhead pequeño ideal para baja latencia y poca necesidad de proceso. O también puedes usar UDP si capas superiores se van a encargar de toda esa parte porque sabes/supones que la conexión es buena y prefieres la rapidez de UDP.

No vas a meter voz sobre TCP, ni videoconferencias, ni los eventos de un juego online.

Otra cosa es que simplifiques la pila porque no quieras la independencia sobre las capas inferiores. Total, si todo es Ethernet para qué quieres suponer conexiones vía satélite, MPLS, 4G... Eso te lo compro, pero entonces toda esa conversión la vas a tener que hacer en los nodos que cambien de protocolo de nivel 2.

TCP y UDP son una implementación de la capas 4, 5 y 6 de la pila OSI, mucho más simple que ésta y sus particularidades son soluciones a problemas que había entonces y que ahora (como la calidad de las comunicaciones) no son tan frecuentes.

menéame