La masturbación y el buen software

En agosto del año pasado apareció Handmade Dev, una iniciativa que pretende recordar a los programadores que el código que desarrollan se ejecuta en ordenadores reales, y afirma que todo software que se ejecute sobre una capa de abstracción lógica, que se interponga entre él y el procesador, es lento y peor.

[#24 Mister_Lala]

#20 El tema está en que los lenguajes de alto nivel te dan una capa de abstracción necesaria para no perder el tiempo depurando chorradas. Chorradas que al final terminas haciendo tus propias librerías si no existen esas funciones de alto nivel, porque las usas demasiado a menudo. ¿Alguien se plantea usar una base de datos relacional sin usar las librerías de alto nivel, es decir, accediendo físicamente al fichero "a pelo"? Pues quizás consigas que el resultado sea más rápido, pero el proyecto va a durar cuatro veces más, y el coste va a ser inasumible para el cliente.

Pretender que un programador programe a bajo nivel, es como esperar que un panadero muela su propio trigo, o que un albañil fabrique sus propias tejas.

[#25 Desactivado]

#24 Yo creo que ya nadie se plantearía a día de hoy acceder a una base de datos directamente abriendo los ficheros que contienen los datos. En todo caso podría existir cierta controversia entre utilizar un ORM para mapear los datos en objetos del lenguaje de programación o hacerlo todo directamente utilizando SQL. Este tipo de decisiones sí suelen habitualmente enfrentar a los programadores

[#56 miau]

#25 Wow, tú sí que sabes.

[#59 Desactivado]

#56 a ver, aclárame tú, gran sabio

[#73 Desactivado]

#56 no me lo vas a decir?

[#6 chepas08]

Como siempre un artículo excelente de Bonilla

En general y para la inmensa mayoría de aplicaciones vale mas la pena que el código sea mantenible y pueda evolucionar con facilidad, que no que tenga un rendimiento de la leche.

Me quedo con

"Muchos programadores crean aplicaciones web con Spring desde hace años, sin saber qué es el DispatcherServlet ni haber implementado jamás la clase Servlet que este ultimo extiende. Son aún más los que desconocen los distintos métodos HTTP y sus peculiaridades ¿Es completamente necesario para desarrollar una aplicación web? No, pero si es recomendable. Si no dominas tus herramientas, si no entiendes la MAJIA detrás de Rails o jQuery, las herramientas te dominaran a ti."

Doy fe, muchos empezamos a programar con demasiadas capas, Frameworks.. Tarde o temprano tienes que volver a lo básico porque sin una base sólida al final es cierto que la herramientas te dominan..

En Java particularmente me vino de perlas sacar la SCWCD -> Head First Servlets && JSP para entender las Bases de programación Web (Muy didáctico el estilo Head Fist -> p.ej se me quedo grabado The story of the non- idempotent request

[#15 rafeame]

#6 Creo que en cualquier aplicación siempre sale algo que no estaba previsto y te obliga a remangarte y tocar las tripas del framework.

[#18 Desactivado]

#6 Podría yo haber escrito ese mismo comentario, incluyendo lo de la SCWCD. +1

[#26 Desactivado]

#6 Cualquier persona que evolucione en su trabajo y vaya cambiando de frameworks o librerías al final acaba aprendiendo las tripas. Si no, te estancas.

[#57 xanty.gc]

#6 Tienes toda la razón, y esa vuelta a lo básico es probablemente la diferencia entre ser profesional o ser un mono-golpea-teclados. En este sector la profesionalidad brilla por su ausencia.

[#58 pollo]

#6 Muchas veces Java para web (con todo el tinglado que lleva consigo) es matar moscas a cañonazos. Para una gran mayoría de proyectos, cosas mucho más sencillas con PHP/Python y SQlite va que chuta.

Java se debería reservar para proyectos verdaderamente complejos, que son los menos.

[#33 Desactivado]

El fin de la programación a bajo nivel se lleva profetizando desde hace por lo menos 3 décadas, y pese a que la capacidad de cómputo se ha disparado exponencialmente, a día de hoy seguimos prefiriendo las soluciones más rápidas y eficientes posibles.

La de veces que habré escuchado que C++ no se iba a usar más. Que los sistemas operativos se iban a programar en Java o que íbamos a tener todo en un mainframe y trabajaríamos desde terminales tontos. En 2016 seguimos en un SO programado en C o C++, un navegador en C++, videojuegos en C++ y ojo, incluso grandes empresas migrando sus backends a C++.

Por qué? Por que siempre queremos más. Por que si nuestro PC tiene una CPU 15 veces más rápida y 30 veces más memoria, no queremos desaprovecharlo ejecutando 12 capas de frameworks. Queremos procesar 20 veces más pixeles, a 200 imágenes por segundo. Queremos descargar más rápido y que las páginas web carguen en 1 milisegundo, con videos embebidos y gráficos 3d.

Esto no es un espejismo, y va a ir a más.

Cada vez más se va tomando conciencia de que la eficiencia no es solo "más rápido" o "usando menos memoria", sino también "consumiendo menos energía". En un futuro nos llamarán salvajes por el impacto energético que tenía nuestro software primigenio.

[#62 pollo]

#33 C++ de hecho no se usa más... para la mayoría de casos de uso.

C++ se sigue usando donde procede. Nadie va a ser masoquista y usar C++ para web, por ejemplo. Bueno, casi nadie.

También es verdad que por fin están saliendo competidores dignos a C++. Qué pena D, que al final no cogió tracción.

[#101 Akira4]

#62 Pues yo no uso C++ para web, uso C .

[#85 Desactivado]

Aparte de lo que comenta #42 sobre la publicodad, estoy con #51, #33 y #7. Cada problema tiene su solución. C, C++ y ensamblador dan mas rendimiento y Java da otras facilidades. Segun los recursos de que dispongamos y del rendimiento deseado nos puede venir bien una solución u otra.

[#11 derosmc]

En ingeniería hay diferentes factores para la elección de un diseño, los hay técnicos y los hay ecónomicos.

Si necesitas el doble de horas para hacer un producto en C que en Java cuando el beneficio de hacer eso es extremadamente limitado pues lo harás en Java, aunque utilice (en algunos casos) mucho más recursos de los necesarios.

[#12 pollo]

#11 Básicamente. No hay mucho más que decir al respecto.

Cuando la gente no tiene ningún tipo de experiencia y todo mola mogollón porque te sobra el tiempo, puedes dedicar horas y horas de tu vida a resolver de forma perfecta un no-problema.

Luego es cuando vives de ello, tienes obligaciones y familia y no puedes andar perdiendo el tiempo reinventando la rueda para tonterías que no aportan.

[#36 Desactivado]

#12

Tu argumento solo tiene sentido para hacer una aplicación con una finalidad concreta en un equipo concreto y que no sea crítica.
Pero programar un sistema operativo, un "wordpress", un codec etc... que se va a ejecutar en millones de máquinas en todo el mundo es distinto ya que lo poco o mucho que lo optimices va a suponer un ahorro de recursos enormes, como cuando se hablaba de Google en pantalla negra para ahorrar energía, a nivel individual irrelevante, pero a nivel mundial es mucha energía.

http://www.negrooogle.es/faq/black-google.php

[#52 pollo]

#36 Pero no estás diciendo nada novedoso. Lo que pasa es que aplicar los criterios de diseño de un driver no tiene nada que ver con los de una plataforma para blogs.

[#109 Arganor]

#11 Exacto. Hay que adaptarse a las circunstancias.

Yo llevo 29 años programando (20 de forma profesional) y eso es lo primero que hay que valorar. En la Universidad, cuando yo estudié, era algo que no explicaban. Lo que te explicaban eran los conceptos básicos y a crear todo desde cero si no tenías acceso a los recursos. Y obviamente, a cogerte un libro de un lenguaje y a sacarle partido para desarrollar en el lenguaje que te pidieran...

#12 Tal como dice #36, por eso se utiliza la complejidad de los algoritmos y se revisa su eficiencia, etc.
No obstante, como hay tanto intrusismo laboral, hay analistas y programadores en el que todo el monte es orégano, por lo que al final, te hacen aplicaciones, herramientas, programas, etc. que usan más recursos por no haberle añadido algo de tiempo a optimizarlo.


#52, #90 creo que no habéis comprendido a #36 no habla de drivers sino de hacer las cosas correctamente y él está especificando adecuadamente el sentido de su frase, porque la concreta en su primera línea. Ambos la habéis cambiado la orientación para hablar de algo que son la excepción que confirma la regla.

[#90 Desactivado]

#36 No quiero quitarte razón porque la tienes, pero sí quería destacar que ese argumento tiende a convertirse en una falacia de grandes números, como yo la llamo. Seguro que todos al comer siempre nos dejamos algún grano de comida en el plato, sin embargo, no es realista pensar que si "ahorramos" ese grano estamos reduciendo toneladas de comida si lo contabilizamos por 7 mil millones durante un año, ni tampoco tiene sentido hablar de las calorías que perderíamos (o los kilos) por no comerlo.

[#108 Desactivado]

#90 eso es como mi vecino, que no recicla porque total que él lo haga o lo deje de hacer no va a cambiar nada, o los que no votan porque un voto más o menos no va a cambiar nada ...

[#94 Desactivado]

#36 En realidad ahora con las LCD el colo negro gasta más energía.

[#3 Desactivado]

Un artículo relativamente interesante y fíjense los dos comentarios de arriba (y el de abajo)

[#16 Mister_Lala]

#3 Como programador con muchos años de experiencia, te puedo decir que tiene el mismo interés que mi esfinter anal. Cero.

[#20 Desactivado]

#16 Ya lo sé, solo puse lo de "relativamente" para que no me crujieran a negativos. El que escribe el artículo no es programador y se nota, aunque tristemente quiera aparentarlo

[#32 Desactivado]

#20 Yo no soy programador pero que cada vez os alejáis de la maquina que da gusto, el mismo programa haciendo lo mismo en su versión 10 ocupa y come recurso de lo lindo y tiene dependencias brutales a librerías externas que da gusto y encima si no va con x versión de estas petardea que da gusto.
Cada vez que tengo ir mirarle un sofware de TPV algún cliente los backups que le dejan dan grima y tengo ver que tenia el instalado para sacar las versiones correctas con que se diseño para que no falle, lo típico es por que la empresa que creo el software no existe y con semejante instaladores que entregan ríete de intentar instalarlo en un ordenador con el hd muerto o se a caído el windows.
PD:Odio el sofware que usa SQL tanto libre como de microsoft tengo un cliente chino con una aplicación tpv con 1 binario de windows 98 pasada euros y no falla ni a palos arranca en msdos un bat para lanzarlo y no hay nada mas que hacer que cada x tiempo copiar la carpeta o los archivos de la base de datos LOCAL sin mierda de servidor sql.

[#43 chepas08]

#20 Hombre, ahora no programa, pero ha programado y sabe programar.
https://es.linkedin.com/in/dbonillaf

[#44 Desactivado]

#43 6 meses hace más de 10 años y utilizando Java con Servlets

[#55 xanty.gc]

#44 Deberías de suscribirte a la lista. O buscar presentaciones de Bonilla. Creo que te sorprendería.

[#60 Desactivado]

#55 estoy suscrito a su lista. Es un excelente padre, emprendedor y empresario (le sigo en twitter), pero de programar, lo justo. No es ningún experto

[#66 xanty.gc]

#60 http://www.bonillaware.com/hola-mundo lo de empresario le viene de hace poco. Ha sido y es un técnico más.

[#82 david_bonilla]

#44 Hola! Sólo por puntualizar, no le hagáis mucho caso a mi perfil en LinkedIn. Ni se muy bien como funciona, ni lo tengo muy actualizado

Mi primera experiencia profesional fue programar un CMS en Java, de ahí pasé al BBVA donde formé parte del equipo que implementó el TPV (la pasarela de pago online del banco), de ahí salté a Sixservix, donde empecé como programador y acabé como CTO pero sin dejar de programar hasta el último día de los 7 años que estuve allí. Normalmente era el que prototipaba las cosas nuevas que íbamos metiendo, incluyendo Android. No es que haya programado software para submarinos, pero hombre... algo más de seis meses de experiencia programando Java con Servlet si que tengo

Desgraciadamente, y a pesar de llevar al menos dos años sin dedicarme profesionalmente a programar, creo que soy bastante mejor desarrollador que empresario ^____^ Eso si, yo nunca me he considerado un gran programador ni jamás lo he dicho. Simplemente, soy un tío enamorado de mi profesión.

Ahora le estoy dando a Node, no porque crea que sea la panacea, sino por probar algo nuevo... supongo que será la crisis de los 40

Un abrazo y muchas gracias por leer y compartir la Bonilista.

[#83 Desactivado]

#82 Gracias a ti por la respuesta

[#64 dirok]

#20 ¿Cómo que no es programador? David Bonilla claro que lo es, qué te hace pensar lo contrario?

[#68 Desactivado]

#64 es empresario, no programador. De hecho una de sus promesas en enero hace dos años fue volver a programar (y no la cumplió). Ahora en 2015 parece que sí hizo algo, aunque todo a nivel interno y de poca envergadura (revisa su blog)

[#71 Desactivado]

#64 Por cierto, ayer estuvo pregonando en twitter que el artículo de hoy iba a ser muy muy técnico.... Yo le recomendaría que le echara un vistazo a los posts que tiene gallir en su blog sobre programación concurrente

[#75 gilipipas]

#71 El puñetero Gallir tiene un don para escribir artículos técnicos y sin embargo se pasa el día en twitter escribiendo chorradas.

[#77 Desactivado]

#75 yo no veo que se pase mucho por menéame para escribir. Y no tiene ningún don, simplemente lleva muchos años como docente

[#22 mikeoptiko]

#3 pues no te quejes, cualquier noticia científica tiene como mínimo los primeros 20 comentarios con chorradas y coñas.

[#51 Desactivado]

No estoy de acuerdo con el artículo, da la impresión de estar realizado por el típico gerente de una consultora enfocado a plazos de entrega.

Cuando un programa de ordenador está implementado de la forma más óptima posible no solo tiene menos líneas de código y funciona más rápido sino que es más fácil de entender y de ampliar en caso de ser necesario. En cuanto a lo que comenta de que desarrollar así es más lento, pues yo diría que no porque muchas veces se tarda más tiempo en aprender a manejar el nuevo framework y en solucionar errores difíciles de entender que en avanzar con el desarrollo.

Por ejemplo yo he tenido dos páginas web basadas en foros: en una usé phpBB y la lancé en un par de días, mientras que otra la hice desde cero y tardé un par de meses, que me resultó muy fácil de mantener y ampliar. Sin embargo la primera al final me ha supuesto más tiempo y quebraderos de cabeza al intentar implementar novedades y cosas específicas. Además el estilo se ha quedado antiguo y es mucho más difícil de actualizar a otro más personal.

[#88 derethor]

#51 Cuando un programa de ordenador está implementado de la forma más óptima posible no solo tiene menos líneas de código y funciona más rápido sino que es más fácil de entender y de ampliar en caso de ser necesario.

esa es una afirmacion arbritaria que no se corresponde con la realidad. Para empezar, debes de decir a que llamas optimo. Para que un codigo sea optimo, deberia de usar los recursos al maximo, por ejemplo, usando la CPU al maximo, y el bus de memoria al maximo, etc, porque dejar de usar recursos disponibles, es ineficiente.

En un procesador intel moderno, eso implica, por ejemplo, usar extensiones avx2 del micro, para usar mas operaciones matematicas. O usar la GPU para calcular mas rapidamente. Y no es lo mismo escribir codigo para una nvidia de la serie 700 que otra de la serie 900.

Es al contrario. Cuanto mas abstracto, mas dificil es hacer un programa eficiente. Cuantas menos lineas de codigo, mas abstracto, y mas dependes de variables externas, como el compilador, el runtime de php, etc, cosas que pueden cambiar y que tienes que sobreentender. Asi que, cuanto mas tienes que sobreentender, mas dificil es de usar bien.

[#107 Desactivado]

#88 Me refería al tema de complejidad computacional, es decir, obteniendo los mejores resultados haciendo que el ordenador trabaje lo mínimo posible. En la Wikipedia lo explican mejor que yo.

[#111 Arganor]

#88 Creo que muchos programadores, analistas, etc. de la nueva hornada no te van a comprender, no por el hecho de que no entiendan tus palabras, es que muchos de ellos no se han visto programando música y gráficos con intros de 4Kbytes.
Por ejemplo:

Pero está bien, al final, todo tiende a crecer y a veces el esfuerzo por hacer todo óptimo, eficiente, etc. no compensa económicamente, como han comentado bastantes, ya que ese software poco eficiente, el hardware futuro lo corrige, o queda obsoleto y sale otra herramienta que la sustituye.

Estoy de acuerdo en casi todas las apreciaciones. El tiempo al final es oro, ahora la duda es ¿Qué tiempo queremos optimizar? ¿El del usuario que maneja una herramienta? ¿El del futuro programador que recoja el código? ¿El de la propia máquina que cuando se quede obsoleta será sustituida por una presumiblemente mejor?

El sistema capitalista pide la venta de equipos más modernos por necesidad del mercado, no tratan de reutilizar lo "viejo" para trabajar, no interesa.

Es como querer vestirse como en el año 1600 en la actualidad y decir que vas a la moda porque has creado con eficiencia el tejido de algodón. Y seguramente te vista, te de calor, puedas ir a cualquier evento, sea ropa cómoda, etc. pero estarías aislado socialmente, serías un bicho raro.

Ya no se trabaja con un 8086 aunque se podría ... pero ya no es eficiente, ni competitivo, etc.

[#2 Libertual]

var fap;
for (fap = 0; fap < 100; fap++) ;
console.log('yeah!!!');

[#4 elgranpilaf]

#2 var fap;
try ;
console.log('yeah!!!');
}
catch (IOException io)

[#8 ogrydc]

#2 goto #4 y aprende a hacer sexo seguro

sexoseguro.c

[#13 scalvo]

#4 Por curiosidad, qué lenguaje es?

[#21 ktzar]

#13 Javascript con excepciones tipadas... Trololo

[#84 scalvo]

#21 eso mismo pensaba! Tralala

[#29 xenko]

#c-2" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2546865/order/2">#2, #4

include fap

for f in [ fap.lubricate(f) for f in fap.exahustiveFappingGenerator() ]:
 raise(f) # Viva Python!
 f.fap()
 pass

quit()

[#40 alexwing]

#29 En Java tendría un singletone, una factoría y un par de librerías obsoletas.

[#53 pedrobz]

#40 Se te ha olvidado el fichero de configuracion xml, los ficheros de properties, el pom del proyecto, la configuracion en el servidor, el manual de usuario, el manual de despliegue....

PD: Me voy a suicidar 😭 (lo he pensado mejor, voy a suicidar a alguien)

[#41 Desactivado]

#29 #4 #2 Python siempre te lo pone facil.

import pornhub

porhub.play("lolitas")

while palote and not chorrako:
mano.up()
mano.down()

[#50 Black_Diamond]

#41 IndentationError: expected an indented block

[#54 Desactivado]

#50 meneame se come las indentaciones.... Un momento! Ay pillín, intentaste ejecutar el código, y veo que ya tenías instalada la librería de pornhub, eh?

[#65 xenko]

#41 Lo más increible de Python es que puedes llegar a creerte que exista un paquete llamado pornhub en el repositorio central. He llegado a hacer pip search pornhub para comprobarlo.

[#67 Desactivado]

#65 http://pastebin.com/d3aH3U94

[#48 Desactivado]

#4

sub fap }

[#96 punyal]

#4 hay q cambiar el for por un while(0)

[#27 Desactivado]

#2 Exactamente, la misma diferencia entre una barra de pan de masa congelada del Gadis y un bollo de Pan de Cea es esa, el tiempo ,la sabiduría y la calidad de los procesos y materiales.

lo que pasa es que al público se le venden barras congeladas de mierda a precio de Pan de Cea. Y ellos tragan igual.

Vease p.ejm las webs de las admons. públicas.

[#42 Desactivado]

Buenísimo, han colado la publicidad de un oneroso curso de coaching en programación como una "noticia". Realmente parece que sí que sirven esas técnicas que mentan

[#7 Desactivado]

Reinventar o no reinventar... Esa es la rueda.

No hay una regla de oro.

Pero las decisiones no pueden tomarse basándose en dogmas, ni en un sentido ni en otro.

[#99 c.arcediano]

#7 si ya hay una librería que está más que de sobra probada y hace lo que necesitas... ¿por qué volver a programarla y probarla?

[#105 Desactivado]

#99

Puede haber varios motivos:

1. La librería en cuestión puede traer montones de dependencias y hacer cientos de cosas, de las cuales sólo necesitas una.

2. La librería no hace la cosa como a ti te viene bien, y tendrías que parchear/hackear.

3. La licencia de la librería no es apta para tu proyecto.

4. Estás prototipando y te lleva menos tiempo hacer la cosa a pelo, que aprender a usar una librería porque su uso es complejo y está mal documentada.

5. Crees que podría hacerse mejor.


Montones para reinventar la rueda hay cientos (algunos mejores y otros peores) la prueba es la miríada de lenguajes, frameworks, y librerías que hacen lo mismo.

Coje cualquier cosa, y mira cuantas alternativas tienes.

[#5 Desactivado]

Ahora sacan betas finales con parches de pago llamados DLC o suscripción a perpetuidad que requieren optacores para poner "Hello word".
Me recuerda el utorrent al principio era un ejecutable de 100k y ahora es una degeneración que hace lo mismo pero ocupa mil veces mas.

[#47 frankiegth]

Para #5. uTorrent??? Ni se te ocurra.

Usa #Deluge o preferiblemente #Transmission, ambos implementados para Gnu/Linux y Windows.

Deluge es como uTorrent pero totalmente limpio de publicidad y porquería. Un recambio perfecto sin complicaciones.
_{http://deluge-torrent.org/}

Transmission es pureza, concreto, práctico, sencillo, limpio, estructurado. Sin duda el mejor cliente para usuarios serios.
_{http://sourceforge.net/projects/trqtw/}

[#49 Desactivado]

#47 Hablo de cuando era un buen programa ahora uso qbitorrent que multi y va bien aun ayer lo instale en un mac con el capitain sin problemas.
El utorrent hasta la 1.6 era la leche ahora aparte de toda la mierda que trae es penoso en tema recursos para hacer exactamente lo mismo que la 1.6.
El jodido azureus o el jdonwloader es el ejemplo de este articulo de programa en java es terrible puede que para el programador sea mas fácil de mantener pero para el usuario es un jodida pesadilla.

[#63 pedrobz]

#5 No hagas caso a #47 , instálate el qbittorrent, es lo mas parecido a utorrent y es muy usado: http://www.qbittorrent.org/

[#70 Arariel]

#63 Me va de maravilla. Tiene un buscador de torrents que funciona, no es mejor que ciertas páginas, pero es de utlildad.

[#72 frankiegth]

Para #63. No lo conocía. Me lo apunto, aunque sigo siendo incondicional del Transmission le echaré un vistazo.

Por cierto, Transmission da soporte Blocklist, bastante útil para los tiempos que corren. Aquí un tutorial :
https://giuliomac.wordpress.com/2014/02/19/best-blocklist-for-transmission/


_{(CC #47 #5 #70)}

[#79 frankiegth]

Para #70. Acabo de probar ese buscador que trae, pero no responde.

[#80 Arariel]

#79 Pulsa en la pestaña Buscar y abajo verás Motores de búsqueda, te abrirá una nueva ventana más pequeña y en ella aparecerán los que vienen. Puedes ir añadiendo.

[#1 ﻞαʋιҽɾαẞ]

Fap, fap, fap...

[#35 Desactivado]

A mi como programador lo que más me gusta es tener que lidiar con proyectos de tropecientos archivos distintos, millones de líneas, convenciones y patrones tan poéticos en el papel, que para resolver un problema simple te obliguen a escribir mucho más código, menos flexible y poco legible.

Todo por respetar un coding style que en su origen pretendía facilitar la tarea, pero a la larga se convierte en tu peor enemigo.

La abstracción está muy bien, pero cuando se antepone la 'corrección política' en el código frente a la eficacia o eficiencia, mal vamos.

¡Viva los antipatterns!¡Viva GOTO y RETURN!

[#91 Desactivado]

#35 Al final todo tiene su contra ejemplo, si hay gente que se dedica a hacer apaños, al final tendrás millones de archivos en los que no hay documentación, etc, etc, nadie sabe que hace, de qué depende, rompe los estándares del proyecto arbitrariamente, etc, etc.

[#100 c.arcediano]

#35 espero que no te toque mantener código trufado de GOTO.

[#110 Arganor]

#35 Y sin tener en cuenta a veces la curva de aprendizaje... jeje...

Me recuerdo una vez que nos pidieron una herramienta muy sencilla que se usaba en diferentes dispositivos. El equipo de ingenieros informáticos de nuestro cliente, solicitaba que se realizara en un framework de PHP por su crecimiento, efectividad, etc.
Lo desarrollamos en PHP, ellos decían que haríamos un código espaguetti. Se desarrolló y se entregó, no dando errores. El código no se volvió a tocar más, han pasado 6 años. Siguen usándolo. El desarrollo fueron 3 días, ellos planteaban 2 semanas.

¿Por qué algo tan sencillo querían incorporar tantas librerías que no se iban a utilizar y usar un framework? Por lo que comentas tú.

Cuando se recoge un proyecto lo lógico es ver su objetivo y tiempo de vida.

Al final, esto es como un idioma, se utiliza para comunicarse; sino pierde su objetivo.

[#38 alfredo_casado]

El manifiesto del "handmade dev" no lo conocía pero es una soberana estupidez. Es tomar una sóla de las dimensiones del problema del desarrollo de software, el rendimiento, y ponerla por encima del resto de dimensiones sin tener en cuenta el contexto.

Pobre del que tenga que mantener el codigo que vayan dejando a su paso estos lumbreras. Velocidad de desarrollo, mantenibilidad, extensibilidad, robustez, escalabilidad (que no es lo mismo que rendimiento)... vamos a olvidarnos de estas cosas y a escribir toneladas de código en lenguajes de bajo nivel optimizando chorradas que no le interesan a nadie!, gran idea.

[#34 fugaz]

"Buen software es aquel que cumple las expectativas, plazo y presupuesto sin hipotecar su propia evolución."
Pues sí:
- Hay quien sólo sabe abstraer código y si encuentra un cuello de botella y se necesita rendimiento (porque de otro modo no cumple con las expectativas del cliente) no sabe optimizar para velocidad. Entonces el cliente se queja.
- Y hay quien no abstrae el código y entonces hace código de difícil mantenimiento y lentitud en mejoras. Entonces tienes al cliente enfadado por los continuos retrasos en mejoras y cambios.

[#17 ktzar]

Otro programadorucho que se permite opinar sin haber aprendido a organizar ideas ni ortografía. Amén de decir algo interesante o llegar a algún sitio con su discurso... Temps perdut.

[#98 Siscins]

será que soy de la vieja escuela y he trabajado en multinacionales, pero da igual que herramientas uses mientras sea rápido de desarrollar y sobretodo que tenga fallos para asegurar el mantenimiento, pero no tantos como para que lo den a otra empresa.

[#69 xanty.gc]

El artículo viene a explicar una situación muy común que ocurre cuando técnicos nos ponemos a crear algo. Muchas veces, nos centramos en su composición y no en su función. Hacer el software perfecto no lo hace mejor si no hay usuarios.

Claro que el software bien desarrollado será más mantenible, legible y lo que queramos, pero será inútil si no lo usa nadie.

[#87 derethor]

Con los años aprendes que la abstracción es el enemigo del rendimiento.

Por ejemplo. no es lo mismo recorrer un array de 2 dimensiones, recorriendo filas y columnas, que hacerlo columnas y filas. En un caso, la cache optimiza, en el otro los accesos a memoria son mucho m'as lentos. Pero tienes que saberlo, no es algo que el lenguaje te muestra de forma sencilla.

Toda la programacion orientada a objetos sufre de lo mismo. Podemos abstraer, pero no podemos evitar desencadenar una tormenta de llamadas ineficientes. Algo tan simple como a=b puede llevar una sobrecarga del operador = que haga cosas que no podemos controlar.

Lo peor que le puede pasar a un programador es que una tercera persona comience a usar su API. En ese momento aparecen las contradicciones, se comienza a usar el API para lo que no estaba pensada, aparecen los hacks... y tienes que dar soporte para todo eso.

Lo que pasa es que a los programadores nos gusta abstraer. Es algo propio de nuestra forma de pensar. En el fondo, nos encanta crear bellezas que definan un mundo zen utopico, que alimenten nuestro ego y nos llene el cerebro de placer.

[#92 Desactivado]

#87 Es que de eso se trata, se cambia rendimiento a cambio de otras cosas, como seguridad, legibilidad, facilidad de codificación, etc. Y precisamente la idea es hacer a trabajar más a la máquina que para eso está. Eso sí, obviamente no siempre será buena idea, al final como cualquier buen profesional debería hacer hay que conocer las herramientas y los compromisos que te imponen.

Al final cualquier abstracción se rompe, pero ojo, muchas veces porque alguien intenta usar una herramienta de forma que no debería utilizarla. Si alguien crea un destornillador y alguien decide utilizarlo para clavar clavos, a lo mejor no es culpa de la herramienta. Por ejemplo esto:

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
Básicamente, si usas una herramienta que se basa en almacenar la información por documentos, para algo que claramente no sigue sea filosofía, pues la estás cagando desde el principio.

[#93 HORMAX]

#92 Pretender optimizar código signifique hacer trabajar mas a la maquina porque "para eso está" es la mayor burrada de las que he escuchado en mi vida. Viene a ser lo mismo que decir que el mejor rendimiento de un motor se saca cuanta mas gasolina consume que para eso está.

Creo que no es necesario aclarar que mientras menos trabaje la máquina mas rápido se ejecuta el código, una muy buena medida de lo bien hecho que está. También indica que otras tareas pueden ser realizadas en las misma máquina de forma simultánea, porque si un solo programa se come todos los recursos innecesariamente no creo que haya que demostrar que es un mal código.

Entre código ultrarrapido optimizado a tope pero difícil de mantener y aplicaciones hechas con tantos niveles de abstracción que permita ser realizado por un individuo que no ha programado en su vida, hay todo un arco de posibilidades, la labor mas importante del profesional es determinar que punto del arco elige.

[#114 Desactivado]

#93 Me parece que estás llevando al extremo mis palabras, lo principal que digo es que es un compromiso, que es básicamente lo que vienes a decir al final. No se trata de tener un motor diesel que consuma más gasolina porque sí, si lo haces para ganar otra cosa (quizás seguridad, cumplir legislación, patentes, etc) dependerá de si eso lo vale.

[#119 derethor]

#92 es a lo que me refiero, la abstraccion , al ocultar la implementacion, permite usar la tecnologia mal. Tienes que saber como funciona por dentro mongodb para saber como usar mongodb. La abstraccion solo oculta esos detalles, pero nos parece mas bonita

es algo que aprendes con el tiempo, y que indica madurez como ingeniero, al menos en mi opinion

[#104 pollo]

#87 A mí personalmente no me gusta abstraer demasiado si puedo evitarlo, especialmente para proyectos que sé que van a ser simples. Es una plaga en determinados lenguajes que no ofrecen alternativas fuera de los objetos, como Java.

[#14 Desactivado]

"Si no dominas tus herramientas, si no entiendes la MAJIA detrás de Rails o jQuery, las herramientas te dominaran a ti."

Mis hogos!!!

[#23 joshendrix]

#14 ¿No basta con que el autor lo escriba en mayúsculas? ¿es necesario poner comillas o, peor aún, los tags de irónico?

[#61 pollo]

#23 No es la más gorda que mete, de hecho hay unas cuantas faltas graves que no son de coña y ahí quedaron para la posteridad.

[#86 wizcocho]

#23 Si lo escribe en mayúsculas es que LA MUERTE no sabe ortografía.

[#30 court]

Un artículo de mierda que no tiene ni idea de lo que está diciendo. Oye campanas y no sabe dónde.

En fin. Así vamos.

[#9 HORMAX]

No se trata tan solo de que cumpla las especificaciones, sin importar la caída en el rendimiento o el abuso de recursos, sino que las capas de abstracción introducen niveles de incertidumbre insoportables.

Por poner une ejemplo en uno de los lenguajes de moda como Python, todos estamos sufriendo las incompatibilidades entre las diferentes versiones, lo que funcionaba perfectamente y a prueba de bombas en una versión, deja de funcionar en la siguiente o peor aún da resultados distintos, creando problemas extremadamente serios.

Incluso se dan incompatibilidades entre la misma versión en diferentes sistemas operativos, la portabilidad que nos vendieron como gran atractivo con ese lenguaje, tiende a cero.

[#10 Trublux]

#9 Perdona pero creo que lo que quiere decir es otra cosa.
El punto aquí es decir que, aunque nos joda, el cómo está hecho algo al usuario lo de igual. El cómo se ha hecho es irrelevante siempre y cuando después no sea un lastre, claro.

Por ejemplo, si alguien quiere un blog en wp lo tienes en 15 minutos. Puedes decir que wordpress es una basura mal hecha, y tienes razón, pero al usuario le da igual, es un blog y funciona; la gente que visita el blog lo que le importa es el contenido, no lo bien hecho que está por dentro.

Por otro lado tampoco hay que pasarse con las capas y capas, tanto que al final no sepas hacer algo sin ellas y no tengas una alternativa a usarlas.

[#76 Desactivado]

#9 Lo que funciona perfectamente en una version de python funciona perfectamente en la siguiente version, excepto que cambie la el numero de version "major"!

Es perfectamente razonable que código de python 1 no funcione en python 2 y que el de 2 no funcione en 3. Hay cambios cómo el paso de print de statement a funcion o la codificación de cadenas por ejemplo eran cambios necesarios y me parece normal romper la retrocompatibilidad por cosas así.

Lo de incompatibilidades segun el SO, pues no conozco ninguna. Puedes poner algún ejemplo?

[#39 mrkroket]

La idea del "hecho a mano" y sin abstracción es estúpido, ¿van a ponerse a escribir en código máquina? Porque cualquier otra cosa lleva una capa de abstracción.

Las ventajas de las dlls y de los frameworks es reutilizar módulos ya probados. ¿Que ese módulo tiene problemas? Se corrige una vez y les sirve a miles.

[#45 Joice]

#39 Nada, tarjetas perforadas. Lo retro, como la barba y el bigote, vuelve y siempre fue mejor.

[#46 blid]

#39 Un compilador, por norma general, te va a dar mejor código máquina que si lo escribieses a mano.

[#28 asterissco]

Una cosa es crear un foro y otra es crear un foro aplicando las funcionalidades que el framework te propone usar.

Para lo segundo tendrías que crear un framework y con este, un foro. Conozco con cierta profundidad Symfony y solo para implementar a mano la seguridad y escalabilidad de su sistema de enrutado te vas a pegar un buen rato.

Son dos cosas distintas porque el framework conlleva tal cantidad de ventajas que no se pueden comparar y si eres bueno y sabes aprovecharlo el rendimiento seguramente será mejor que hecho a mano.

[#19 robustiano]

No empecemos a chuparnos las p*llas todavía y prestemos atención al ámbito de las variables...

[#78 oxelo]

Tan malo es querer hacer todo a bajo nivel, como atrocidades/abominaciones/canceres como NodeJS.

[#81 barruka]

#78 A día de hoy el código fuente de cualquier ecommerce u otra app web tiene 10 o 20 scripts .js y 10 .css total para un carrito de compra y almacenar los datos de envío en una tabla de MySQL.

Lo gracioso es que no hace ninguna falta, pero parece que ningún coder web sabe programar sin jquery ni bootstrap en 2016.

[#103 pollo]

#81 Falta no hace, pero bien usado reduce el tiempo de espera del usuario. Otra cosa es que se abuse de ello, que estoy de acuerdo en que se abusa.

[#74 chochis]

Know you protocols.

[#102 pollo]

#74 Know your English.

[#37 Mandela]

A los usuarios les da igual, es cierto, pero los usuarios no buscan lo mismo en la Red.

En cuanto a los lenguajes/frameworks, es más o menos como plantearse si para hacer un tractor se pueden utilizar las mismas herramientas que para hacer un reloj. Son mundos incompatibles que existen y seguirán existiendo.

Ya una vez lo dijo el gran Goya, cuando pintó unas cúpulas: ¡Estimado, esto se verá desde lejos, así que puedo usar la brocha gorda!

[#97 redjhawk]

Majia -> y hasta ahí he leido

[#31 Desactivado]

Y que al final es el mercado el que manda. Cuántas veces se han aplicado soluciones bastardas a problemas de fácil solución si dispusiéramos de un verdadero programador que insertara un par de lineas de código en el lugar adecuado.

[#89 logistark]

Hay que escuchar más a este hombre

y ver que lo que dice esta gente de handmade son mamarrachadas.

[#95 Desactivado]

Aunque tengo nociones, no programo.
Pero me gustaría aportar mi granito: lo suyo es un compromiso entre tiempo de desarrollo y velocidad de ejecución.