Desarrolladores, es hora de tener una conversación seria. Como probablemente ya sabes, esta semana React, Babel, y un montón de otros paquetes de alto perfil en NPM se rompieron. La razón fue bastante asombrosa. Un simple paquete de NPM llamado left-pad de once líneas fue despublicado del repositorio. [...] Lo que me interesa aquí es que tantos paquetes adquirieran una dependencia de una simple función de relleno cadena izquierda, en lugar de tomar 2 minutos para escribir una función tan básica por sí mismos.
Comentarios
Entre un trozo de código probado y validado en centenares de proyectos, tanto por programadores como usuarios, o un trozo de código nuevo acabado de escribir, ni que sea por mí, me fío más del primero.
La reutilización de código no solo no es criticable si no que es altamente recomendable.
#1 yo creo que no crítica la reutilización en sí, sino más bien la manera de reutilizar. 18 millones de descargas al mes de isArray es cuanto menos asombroso.
El hecho de crear paquetes con una simple función es tb una perversión del concepto de paquete.
#2 ¿Perversión del concepto de paquete?
Lo único criticable sería en todo caso que esa función no haya sido incorporada en el paquete básico de desarrollo, siendo tan popular. Pero poco más.
#6 lo que quiero decir es que un paquete se hace para englobar algo. Un paquete de una sola función o incluso de una sola línea es difícilmente justificable.
Lo que tú dices es cierto. Pero lo que yo añado es que no necesariamente ese paquete está testeado y validado y si lo está no por ello seguirá siendo así en el futuro, por lo que hay que cuidarse de qué cosas importar y porqué razón. No se sí has trabajado mucho con npm pero es un poco una jungla. En la que la gente hace un poco lo que le da la gana, se roba código, sube librerías inútiles...
#8 Pero lo que yo añado es que no necesariamente ese paquete está testeado y validado
¿18 millones de descargas al mes y dices que no necesariamente ha sido testeado y validado?
y si lo está no por ello seguirá siendo así en el futuro
Si en el futuro produce errores se fija la dependencia en la última versión donde no los producía y listo.
#9 Una cosa es una función y otra es un paquete (que yo lo entiendo como un conjunto de funciones; quizá me equivoco). Sería mejor crear un paquete con todas las funciones tipo (es solo un ejemplo): leftpad, rightpad, leftzero, rightzero, etc.. y no un paquete para cada una de esas funciones.
Por ejemplo en go, https://golang.org/pkg/net/url/#pkg-examples hay un paquete con varias funciones que es para "parsear" una uri. O en perl http://search.cpan.org/~ether/URI-1.71/lib/URI.pm
Si cada función para hacer parse fuera un paquete, sería un lío difícil de mantener. Que es lo que ha pasado en NPM con el leftpad
#2 A mi me parece que en este meneo hay una queja un tanto legítima, utilizar dependencias innecesariamente, y otra un tanto absurda que es utilizar código existente. A lo mejor muchas de esas funciones estarían mejor en un paquete que incluya funcionalidades similares en vez de paquetes-función.
Por cierto, lo que dices en #8 me recuerda de una forma a un problema genérico en internet, y es que la información útil está muy diluida entre mucha mierda.
Hace algún tiempo alguien me pasó una noticia sobre un artísta español que trabajaba con piedras (en general de gran tamaño) al buscar información sobre él encontre un montón de copias en distintos blogs diciendo básicamente lo mismo que la noticia original, que era casi nada.
#1 #2 Mi ingles no es muy bueno pero yo creo que critica que para una función de mierda crean una dependencia externa/ la necesidad de un librería ajena. Y que existan librerías así y las utilice mucha gente.
Cosa que es lógico, creo que si hubieran realizado c&p de la función no se quejaría. Como decís la re-utilización de código es algo básico y que todo el mundo hace, no creo que vayan por ahí los tiros.
Hay aplicaciones que por una función de mierda utilizan un paquete de varias decenas de MB, si abusas acabas con una aplicación con 1.000 dependencias externas y una posibilidad grandisima que en cualquier momento alguna rompa tu aplicación.
Recuerdo una que tenias que bajar 30mb de una librería especializada (matemática) por unas de 10 lineas de código. Y bueno no era código tan básico pero lo lógico seria implementarla sin dependencia
No es lo mismo necesitar dependencias de paquetes standard que de cualquier paquete.
A lo mejor al principio es determinadas circunstancias, por tener algo rápido funcional es valido, o por que puedes creer al principio que vas a utilizar muchas funciones de esa librería y después resulto que con una llegaba, pero tu objetivo debería ser eliminar las dependencias chorras en el futuro.
#20 #16 #57 Muy de acuerdo, es la fiebre de las dependencias en JavaScript. Hace poco vi en Twitter un chiste que viene PERFECTO para esta noticia, y resume la chorrada de tirar de dependencias para todo, sobre todo para aquellas cosas que realmente no necesitas:
Test unitarios + inversión de dependencias. Si la interfaz cumple con tu modelo de dominio da igual qué dependencias tengas importadas mientras los tests sigan pasando.
Y estoy de acuerdo con todos los que ya han comentado (#2, #10) que paquetes de una sola línea son perversiones del propio concepto de paquete. Para eso están los helpers, lo que viene siendo un utilities.js en JavaScript y un helper.php plano en PHP.
como dice #2 creo que no es cuestion de escribir o no el código de tu programa. Simplemente es la perversión del sistema de paquetes. NPM deberá gestionar esta clase de paquetes tan básicos de otra forma. Suponiendo que son paquetes libres, deberían migrarse a un paquete mayor mantenido por la comunidad y no solo por un desarrollador.
#2 #1 El problema de fondo es que se está intentando usar un lenguaje con un API muy reducida y esto pervierte el nivel de paquetización.
Debería de hacer un JS y un Extended JS con todo este tipo de funciones para arrays, strings y demás objetos que en otros lenguajes son parte de la base y en JS no existen.
#40 Es que además ya existe! Lodash o underscore tienen esas dos funciones...
De hecho, creo que lodash lo puedes configurar con las funciones que necesites.
Es absurdo que exista un módulo de leftpad... Me extraña que React no use una librería de esas que sí son muy útiles... Seria doblemente grave porque incluirían el módulo sin necesitarlo.
#84 Los de React simplemente se colaron. Lo típico, te va bien y lo dejas en el package.json sin darle más vueltas.
Como bien dices, underscore o lodash es a lo primero que tienes que acudir siempre antes de complicarte la vida por tu cuenta o depender de una basura de 11 líneas.
#2 claro que si, ¿que es mas rapido? pip install PaqueteCualquiera que ademas esta testado o ponerte a picar tu propia funcion quickSort() ??
#47 No compares un módulo completo en Python con cientos de módulos, funciones y varias clases, con una función que cualquier programador hasta de los lerdos como yo realiza en 5 minutos.
#52 Y que no tendríamos ni idea si está bien o mal, ese programador es humano, y a veces es muy fácil comerse los casos límite, o no pensar en casos excepcionalmente extraños.
Al final un buen profesional del tipo que sea, tiene que tomar decisiones considerando que pierde y que gana en cada caso, no hay soluciones ideales. A lo mejor no son 5 minutos, son 30, pero te conviene más, o no, depende de lo que necesites.
#95 Totalmente de acuerdo.
A veces necesitas personalizar las cosas, a veces necesitas hacer las cosas lo más rápido posible, a veces necesitas saber con exactitud total lo que se está haciendo por debajo. No siempre coger dependencias es el camino a seguir, aunque suela serlo.
Yo tengo mi propia colección de "utils" que salen muy frecuentemente en cualquier programa recopiladas desde hace años (por ejemplo en web es extremadamente común necesitar temas de formateo específico de fechas, conversiones de caracteres para archivos unicode dañados, formateo de números, etc.). Unas hechas por mí y otras encontradas por la red.
Lo que siempre será un error es dar una respuesta "mantra" que valga para todo sin tener en cuenta nada más.
#47 "o ponerte a picar tu propia funcion quickSort() ?? "
Esas funciones están en paquetes de Python dedicados a ellos junto con miles de implementaciones y funciones, no en una librería con solo UNA función.
Menudo chiste.
Y si eres ingeniero y no reutilizas TU propia función quicksort creada en cinco minutos para futuros desarrollos y dependes de internet para la mayoría de tu código, pues olvídate.
#1 Discrepo. Reutilizar disminuye el tamaño del código total, pero aumenta la complejidad, lo que tambien dificulta el mantenimiento. Por ese es importante planificar de que forma se enlaza. Si tu codigo enlaza a una libreria que no es fiable, o no es estable, tu codigo hereda esta inestabilidad.
A veces es mejor duplicar una función sencilla que enlazar a toda una libreria que no necesitas.
#10 Totalmente de acuerdo. Uno de mis errores en el pasado, llevado por una interpretación dogmática de los consejos dados a programadores novatos, era la de reutilizar SIEMPRE. A veces no vale la pena, se añade complejidad, dependencias innecesarias y restricciones a medio y largo plazo que pueden suponer bloqueos importantes para continuar un proyecto.
#21 Se nota quien tiene experiencia y quien no, porque los que no la tienen repiten mantras como autómatas y no entienden que hay que tener flexibilidad (porque nunca se vieron en situaciones reales con restricciones de requisitos, tiempo, etc.) y saber elegir lo que más conviene en función de cada problema.
#1 Tienes muchísima razón, como decía mi primer jefe "si has conseguido escribirlo sin errores ya no lo vuelvas a escribir".
Ahora que, en mi opinión, una cosa es reusar código probado y otra descargarlo de un sitio remoto cada vez que lo vayas a necesitar, siempre puedes tener una o varias librería locales con las funciones que más uses y no depender de nadie o de que un iluminado le meta un día una "mejora" y mande tu aplicación ATPC.
#1 pero no lo llames desde el gestor de paquetes. Inclúyelo en tu proyecto y menciona la fuente. Es absurdo incluir un paquete que solo contiene unas pocas líneas.
De hecho, Github tiene una sección especial para compartir ese tipo de códigos:
https://gist.github.com
#1 Hay simplezas tales que no merece la pena descargarte un paquete entero, creando dependencia del mismo y complicando el proyecto.
Esta mierda parece ser una de ellas, pero es que he visto tantas que ya aburre. Está guay tener como paquete una librería que hace de cliente de Elasticsearch, por ejemplo, eso sí que tiene sentido. Pero empaquetar por ejemplo una mierda que valida un DNI es estúpido porque son tres mierdas que puedes escribir en 15 minutos en tu propio proyecto y otros 15 minutos de unit tests y fuera, no necesitas instalar paquetes, depender de conexiones externas ni hostias. Y además, te vas a evitar situaciones de dependencia como por ejemplo cuando el menda que escribió ese paquete no le dé por actualizar, qué sé yo... de Python 2 a Python 3, o de Angular 1 a Angular 2... te quedes tirado y tengas que acabar, tristemente, arreglándolo tú mismo.
Sencillamente, para eso me pico yo el validador de DNIs y escribo 4 tests para él y fuera, es exactamente igual de válido que el del tío que lo colgó en Github.
No haría lo mismo para una librería cliente de la API de Twitter, por ejemplo, o para un controlador de Postgres o Cassandra. Pero para las mierdas que se ven por ahí a veces, el circo de los horrores que la gente ha montado con las dependencias es ridículo. De todo lo que hay en Github, NPM, PyPI, Gem y similares sobra por lo menos el 60%.
#51 "De todo lo que hay en Github, NPM, PyPI, Gem y similares sobra por lo menos el 60%. "
Diras NPM. En PyPi hay mucho proyecto útil.
#55 Ya estáis negativizando una opinión técnica diferente a la vuestra porque... porque es diferente
Vamos a ver, yo NO he dicho que lo que hay en PyPI sea "inútil". He dicho que sobra muchísima mierda. Y no, que de 1.000.000.000 de paquetes 400.000.000 sean (muy) útiles no hace que los 600.000.000 restantes también lo sean.
Personalmente he trabajado mucho con Python y han habido unas cuantas veces que he heredado proyectos donde el anterior había usado lo primero que se entró en PyPI. Muchas veces son paquetes que, por mucho que diga #1, ni siquiera tienen tests escritos y el código no es gran cosa o yo lo he sabido hacer más eficiente y/o más limpio y cubriendo versiones futuras de Python. Así que lo normal es que tenga que forkear el repositorio, actualizar cosas y demás y escribir tests. Es decir: al final acabo haciéndolo yo todo y luego el tío del repo dependiente hace igual 1 año que está a otras obligaciones y no quiere saber nada ni mergear el código.
Para esas mierdas, cuando el código no es muy extenso ni la implementación muy complicada (validadores, etc...) pues lo hago en local yo mismo y que los jodan.
#66 A mí es algo que me flipa. Cada vez que voy a meter una nueva dependencia importante en un proyecto investigo durante un tiempo considerable (si es suficientemente importante a veces me tomo una semana), viendo qué opciones hay para lo que quiero hacer y qué me lo resuelve mejor (incluyendo la facilidad de instalación y uso), más que nada porque es muy valioso no trabajar en balde y darte cuenta demasiado tarde que estás utilizando una librería de mierda que además no se entiende bien y no tiene documentación útil.
Alguna vez tuve yo mismo que corregir bugs que directamente hacían que la librería no funcionase en lo más básico, o tener que reimplementar cosas parcialmente porque lo que hacían no era ni útil ni práctico. Desde entonces miro con lupa.
Sin embargo hay gente que tira de buscador y mete la primera mierda que encuentra en los primeros cinco minutos sin pensárselo demasiado. En esto incluyo la inmensa cantidad de frameworks completamente innecesarios para cosas sin sentido (ya me los he encontrado incluso para css, cosa que sinceramente no entiendo en qué ayuda excepto que seas inepto en el tema).
#1 No sé nada de Javascript, pero después de leer un par de artículos me ha quedado bastante claro. Esto no es un tema de reutilización, que siempre es deseable, aunque no a cualquier precio. El problema es de gestión de dependencias a módulos externos y de definición de esos módulos.
Aquí veo tres "culpables":
1) Los diseñadores del lenguaje, por no incluir una librería estándar de manejo de strings o de arrays. Que sí, que la implementación es muy sencilla, pero precisamente por eso y porque no queremos que todos los proyectos se reinventen la rueda.
2) El que decidió publicar una función de once líneas en un sistema de gestión de paquetes, como un paquete individual y sin más código. Mejor habría sido que él o mejor un equipo de personas se hubieran planteado qué funciones básicas de manejo de strings faltan en Javascript y hubiera publicado un paquete con todas esas funciones. Depender de ese hipotético paquete tendría más sentido que de miles de paquetes cada uno con una única función.
3) Los usuarios del paquete, que inconscientes del precio que se paga al depender de un módulo externo buscaron uno para hacer un left-pad, encontraron esta birria en forma de paquete y lo incluyeron como dependencia en su código y como tenemos una herramienta maravillosa como NPM que nos descarga las dependencias nos creemos que ya está todo resuelto. La demostración de que es un error es lo que les ha pasado. Mejor les habría ido haciendo su propia librería de este código tonto, que quizá algún día podría evolucionar a un módulo externo, si como parece, existe ese hueco en Javascript.
#1 si la reutilización conlleva añadir 50 dependencias y 1000 líneas de código en lugar de una línea de código yo me lo pensaría
#1 En un lado tenemos: str = leftpad (str, 10, " ")
...que llama a un bonito while empeñado en copiar la cadena una y otra vez como un imbécil
En el otro lado: str = " ".repeat(10 - str.length) + str
...sin dependencias, perfectamente optimizado
La creación de funciones, en un paquete, añadidas como dependencia, solo para sustituir media línea de código... no solo es criticable, sino que debería ser penada con latigazos.
y asi es como mierda de APPs ocupan 40mb
Es bien simple. Lo dice el propio artículo.
if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code.
Que tiempos aquellos en qué los hombres eran hombres de verdad y se programaban sus propios drivers de impresora...
#17 Y en binario, nada de mariconadas de ensamblador.
#19 #17 ¿Binario? ¡Bah! Los verdaderos programadores usan el aleteo de una mariposa para cambiar el estado de los bit.
https://xkcd.com/378/
#163 Mira que chico es el mundo hombre de 20 años de proyectos y no se que pollas , mentiroso .........
#29 #25 Pregunta: ¿cómo haces para sacar (tantos) puntos?
Lo digo porque llevo usando StackExchange desde hace más de 5 años, principalmente para buscar respuestas y de vez en cuando preguntar o responder algo, y en total apenas llego a unos 30 puntos. ¿Buscas preguntas a propósito para responderlas, o algo así?
Esta bien no me muestres tu GitHub, con eso que lei me basto .... y opinando sobre NPM ......
#19 Con pulsadores eso de tener una terminal es de maricones.
#17 ...y sabían sumar y restar, y usar las funciones que les daba el lenguaje.
Nos hemos olvidado de programarlo todo. Hace tiempo ya que cuando programas, partes de una base de librerías y referencias que das por hechas, probadas y fiables. Si de pronto desaparece una de ellas, tal vez la pueda reconstruir en dos minutos programando a mano las funciones que me aportaba, pero tendría que probarlas por completo y cada vez que en el futuro un programa fallara, tendría que revisar el código "normal" y también estas funciones adicionales.
Es preferible perder dos horas buscando una librería que ha desaparecido que dos minutos programándola.
#15 El problema no son tanto las librerías mínimamente serias, sino las que, como en este caso, no aportan nada que no se pueda solucionar de forma trivial en el lenguaje.
Si necesitas una librería porque no sabes que puedes usar .repeat en cualquier cadena, que las cadenas tienen un atributo .length, y que puedes sumar y restar... ¿entonces qué coño es lo que sabes?
Por la edad media de la comunidad de usuarios de Node.js, la respuesta a la pregunta sería que todavía no habéis aprendido, pero a hostias aprendemos todos, vais por el buen camino.
El que utiliza dependencias tan alegremente es que no los está utilizando en ningún proyecto mediano ni a medio/largo plazo.
O eso, o como bien apunta #23 , que todavía les falta mucha experiencia.
No reutilizar es querer reinventar la rueda. Mientras que se está aprendiendo si veo sentido obligar al alumno no utilizar código de otros. Una vez se sabe hay que reutilizar todo lo posible.
Ventajas:
1. Menos código que picar.
2. Mayor estabilidad. Si la librería es conocida habrá miles de proyectos que la utilicen a diario.
3. La librería mejorará con el tiempo, ganando aún más estabilidad y rendimiento.
#16 cierto, yo desde que se inventó la rueda no solo la uso en mi coche para desplazarme sino también para ir desde el salón al váter con mi segway, andar es anacrónico....
en serio creo que no te has enterado de nada de lo que pretende decir la noticia.
#57 Lo que si que no comprendo es tu analogía. Ahí sí, si que me pierdo.
Es cuestionable la existencia de una librería de una única función. El hecho de que la gente utilice una función de una libreria, por muy simple que sea dicha función, no es cuestionable. Es recomendable.
Por poca complejidad que tenga una función testearla ya es un dolor en el ano.
#80, #57 y la noticia te indica que incluso algo tan probado, perfeccionado y versátil como una rueda, no hace falta utilizarla en absolutamente todos los escenarios ya que puede ser absurdo y contraproducente.
La rueda es la mejor opción para desplazarse en la mayoría de los escenarios, pero para desplazarse del sofá al baño, te desplazas a pata.
#80 Lo mejor es cuando la rueda se pincha y el que la ha hecho, en lugar de arreglarla se larga con ella dejándote tirado a mitad de camino.
A ver, es muuuyyy simple:
- El código que necesitas se escribe en 5 minutos? Hazlo tu y mételo en una librería propia tuya bajo tu total control para poder reutilizarlo en el futuro.
- Lo que necesitas hacer te va a llevar muchísimo tiempo / es demasiado complejo para que seas capaz de hacerlo? Búscate una librería y créate esa dependencia con ella. Eso si, las librerías y todas las mierdas externas, siempre detrás de un wrapper o fachada para eliminar depender de ella en muchos puntos distintos de tu código, así como poder mockear fácilmente esa dependencia en tus test, etc...
PD: Aún así, tener siempre en cuenta la filosofía YAGNI (you aren't gonna need it), esto es, no te crees una librería genérica propia compleja que mantener para cada gilipollez que hagas. Por otro lado, esa librería super probada por millones de desarrolladores, es una bomba de relojería, si solo necesitas un caso en concreto, debes saber que las librerías no están hechas específicamente para tu caso, intentará ser lo más genérica posible, llevandote contigo un montón de mierda de código que no necesitas junto con todos sus puñeteros bugs. Por muchos usuarios que la usen y muy "crack" que sea el desarrollador, a menos que tu seas un paquetón de la hostia, lo más probable es que tu código específico para tu caso sea mucho más estable y óptimo que toda la puta librería genérica sobre la que no tienes ningún control.
ea
#57 vaya troleada
#16 Si la librería es una función de un línea...
Vamos a ver, desarrolladores de JS: dejadlo.
Eso no es un gestor de paquetes, es un chiste.
#16 Que obsesión con lo de no reinventar la rueda. Si eso se lo aplicasen los que hacen ruedas, seguirían siendo de madera.
#65 los que hacen ruedas se especializan en hacer ruedas. Los que hacen librerías se especializan en hacer librerías.
El "no reinventar la rueda" no se refiere a no volver a revisar un concepto, sino a no rehacer lo que ya está hecho (y, más importante, probado) por otro.
#75 Un buen coder debería tener completo conocimiento acerca de las librerías necesarias para desempeñar su trabajo diario.
Lo que diferencia a un buen coder de uno malo es la capacidad para ver si es buena o mala idea utilizar algo o reemplazarlo con otra cosa. El mal coder siempre pondrá de excusa para usar una mala librería, que es mejor eso, que el reinventar la rueda. Menos mal que hay buenos coders que no se conformarán con esa excusa de vagos e intentarán hacer una rueda mejor.
#65 'Reinventar la rueda', es una expresión. No hay que tomarlo literalmente.
Y créeme, hay funciones, por ejemplo funciones de ordenado o de filtrado, o en general por ejemplo toda la stl de c++, que poco margen (por no decir ninguno) de mejora tiene.
Te lo aseguro, hay funciones que antes mejoras la 'formula de la rueda' que encontrar un algoritmo que resuelva determinados problemas mejor de lo que ya hay.
Una cosa es querer hacerlo todo desde 0 porque a ti te divierta hacerla.
Otra cosa es querer ir al mundo real tm y querer hacer así las cosas. Para cuando la otra empresa ha terminado tu estás todavía testeando tus funciones primitivas.
#83 Yo no se si será mejorable la stl de c++ o no, pero estoy seguro que sus mantenedores no caerían en eso de "no hay que reinventar la rueda" a la hora de hacer mejores versiones si algo es mejorable.
Lo de "no reinventar la rueda" al final está teniendo unos incentivos perversos que se están viendo muy claramente en nodejs. Que cada cual haga lo que quiera, ya está bien eso de reprimir al personal para que no sea creativo y así de paso, no aprenda nada.
#86 Precisamente no tener a miles y miles de personas, haciendo las mismas funciones una y otra, y otra vez. Es lo que propicia la creatividad
#87 ¿Que creatividad?, ¿la de hacer la misma web guarra una y otra vez?.
#86 Reinventar la rueda porque sí es una muy mala idea. Yo estuve en un proyecto en el que se nos prohibió explícitamente usar ningún tipo de librería. Sólo podíamos usar C++ a pelo, ni siquiera la STL. ¿El resultado? Tras meses de proyecto no teníamos absolutamente nada para enseñar, pues no habíamos avanzado. Casi todo el tiempo lo habíamos invertido en crear nuestras propias clases de strings, sockets, mutex, ficheros... Y había bugs a puntapala, lo cual dificultó y ralentizó sobremanera el desarrollo posterior del propio programa. El proyecto estuvo a punto de cancelarse varias veces. Años después, los costes de mantenimiento se han disparado, pues hay bastante rotación y cada vez que entra alguien nuevo tarda semanas en poder picar código, porque antes tiene que aprenderse como funciona nuestra librería y no es intuitiva en absoluto.
Conclusión: no reinventes la rueda a no ser que sea estrictamente necesario.
#16 te olvidas de un aspecto fundamental, que es el de aprovechar los recursos (tiempo, developers, dinero) para trabajar en lo que hace único un desarrollo.
Si estoy haciendo un sistema de gestión hospitalaria, el mejor uso de mi tiempo y el de mis desarrolladores no estará en escribir un left padding o un parser de csv, sinó en funcionalidades que son propias de un sistema hospitalario.
#16 Próximamente:
function add(a,b)
¡A reutilizar se ha dicho!
Y cuando la librería mejore... mmm... ¡la de estabilidad y rendimiento que podremos ganar!
No he comprendido nada del articulo.
Sera porque me gano la vida programando en C/C++
Y claro la std ya me viene de serie
#4 relacionada https://www.meneame.net/go?id=2586452
#5 El artículo de Quartz lo explica bastante mejor; incluye todo el fondo de la discusión por la propiedad del nombre 'kik', los emails de la empresa Kik, etc.
http://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/
#4 hipsters programadores de node.js, volviendo a demostrar sin querer, lo mierda que es Javascript.
#7 Es un lenguaje que mucha gente utiliza pero que pocos saben utilizar. Es un creador de inútiles que al final se acaban cambiando a otro lenguaje. Solo los ninjas sobreviven.
#13 Bueno, eso es como justificar el uso de ensamblador para hacer aplicaciones de alto nivel porque solo los ninjas tienen capacidad de estructurar su código para que al final sea mantenible.
Sé que corren ríos de bits acerca de esto y seré duramente criticado, pero me mantengo firme en que un buen lenguaje es aquel que restringe en la medida de lo posible que el programador la cague. Cosas como el tipado dinámico son aberraciones que no deberían permitir los lenguajes de programación salvo para cosas muy explícitas. Todo aquello que se pueda detectar en tiempo de compilación (aunque en determinado lenguaje no haya una compilación como tal) ahorrará problemas en la ejecución.
#53 No se trata de usar ensamblador para hacer aplicaciones de alto nivel.
Se trata de entender que están haciendo al escribir su código.
No creo que el problema sea javascript, creo que el problema es que muchas personas escriben código por "ensayo y error" sin entender que narices estan haciendo. Ese es el problema detrás de este artículo y desde luego estoy totalmente de acuerdo con lo que dice.
Importar módulos de una linea por no conocer como se comporta un array o como comprobar si una variable es null... es completamente estupido y reduce al absurdo todo el ecosistema.
#53 Aquí programador con años de experiencia y que ha rodado en C++, Java, Python, Lisp, JS, PHP, Ada, AS3 y unos cuantos más.
Los que dicen que el tipado dinámico es un problemón, no tienen experiencia en ello. Punto.
Si un programador con experiencia tiene problemas con los tipos (da igual qué lenguaje sea) o para darse cuenta de cuando metió la pata con los tipos (cosa que se ve al depurar de todas formas), lo siento mucho pero es un inútil.
Anda que no habrá problemas reales a la hora de programar que no te va a coger ningún compilador.
#7 por desgracia una mierda necesaria...
#7 Pero defienden a muerte usar librerias de otro y "snipets" fusilados de Stackoverflow...
#4 Anda, que será en C/C++ no hay problemas con librerías
std te viene de serie pero boost no.
#12
std te viene de serie pero boost no.
Pero cada vez hay más funcionalidad de Boost metida en la STD. E incluso las implementaciones también.
#14 a lo largo de los años boost cada vez parece más un escaparate de lo que puede incluir std en la siguiente versión.
#12 Ya están pensando en meterla en la siguiente versión.
#12 Pero una buena parte boost aparece como c++14-17 .
Y por defecto C++ permite hacer mucho más que JS.
#26 C++ y una lavadora... Todo permite hacer mas que JS
#26 Un pequeño cincel te permite tanto moldear delicadas estatuillas como, si tienes mucha paciencia, cortar un árbol.
No le digas a un leñador que tu cincel puede hacer mucho más que su motosierra. Se reirá de ti y con razón.
#12 Jeder, he pensado lo mismo, con C/C++ a la mínima tienes que meter boost.
#42 boost es c++. Para C te toca espabilar.
A no ser que seas uno de esos programadores de windows que confunden C con C++... mejor no pensarlo.
#44 Cierto, en C glib no da para mucho
#12 Boost! esa monumental obra a mayor gloria del la complejidad absurda del diseño. Llamarla experimental es ser cariñoso con ella. ¡Vaya desproposito!
Cada vez que limpio de Boost y me cargo una docena de templates, me ahorro tiempo de compilación, tiempo de mantenimiento, tamaño del compilado y va más rápido.
#78 "tamaño del compilado y va más rápido. "
https://ccache.samba.org/
#82 va más rápido en runtime, pero gracias por la sugerencia
#94 Con ccache te ahorras tiempos de compilación.
En Linux es poner /usr/lib/ccache" en $PATH antes de la ruta normal.
en .bashrc tal que así:
export PATH=/usr/lib/ccache:$PATH
Programadores de Javascript enfrascados en sus tareas:
Reutilizar código depende de por dónde me dé y el estado de mi ego. Un estado superpuesto como en física cuántica. El mero hecho de observarlo cambia el resultado
"There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s its entire 1 line of code:
return toString.call(arr) == '[object Array]';
"
Por lo que entiendo (yo de programación muy muy poco...) el paquete "isArray" es UNA línea de código y tiene 72 dependencias? y sólo hace lo de ésa línea??? de dar True o False si es Array???? de verdad????
#41 es al revés, 72 paquetes dependen de el.
#50 y paquetes que dependen de esos 72 ya ni te cuento.
Es javascript. Aún no han aprendido
El problema es que cualquier mongui con un cursillo de Node en coursera se hace llamar programador (o coder, que queda más 3.0) y se popularizan engendros como todo lo relacionado con Javascript y sus malas prácticas.
Mi opinión es que en proyectos a corto / medio plazo es un acierto por el potencial ahorro en tiempo de desarrollo y testeo. Ideal para cárnicas y consultoras.
Ahora bien usar librerías y paquetes de terceros también requiere de cierto tiempo de aprendizaje y adquisición de hábitos para utilizarlas conforme ideó su creador.
Para proyectos internos y a largo plazo desaconsejo totalmente depender tanto de terceros. Recomiendo añadir al repositorio las dependencias, no usar módulos para cosas concretas y puntuales, preferir invertir dos días en desarrollar a dos horas para buscar e investigar... cosas de sentido común.
Simplemente por diversión (y ver quien programa algo) yo borraría el jquery de la faz de la tierra. Se usa para todo y sobra en más de la mitad de las veces.
Aquí, la cantidad de módulos de los que depende jquery que cuentan con un script .
http://dustycloud.org/blog/javascript-packaging-dystopia/
#63
#63 Yo desde que uso angular no he vuelto a necesitar de jquery. Pero llevas razón hay gente que importa la bestia de jquery para usarlo solo una vez para un carrusel o cualquier tontería
#85 Precisamente yo me hice un carrusel para mi página y había un montón de ejemplos de gente que usaba el dichoso jquery, me pareció incomprensible.
(Yo, por no meter javascript, que no era necesario, al final lo hice solo en CSS y quedó bastante resultón y bastante ligero)
#89 subelo a github
#91 No lo tengo comentado y además seguro que he hecho alguna chapuza indigna; de todos modos, si quieres eres libre (tu o cualquiera) de mirarlo, adaptarlo, comentarlo y subirlo.
#89 jquery muchas veces no se usa por capricho, sino porque elimina diferencias entre navegadores e incorpora utilidades que ahorran mucho tiempo, además de incorporar eventos como "ready" que son básicamente imprescindibles para un comportamiento consistente.
Hoy día es menos acuciante, pero hace no muchos años era obligatorio ya que los eventos entre navegadores no eran consistentes y si no querías tener que hacer una versión específica para explorer era el camino más sencillo.
Por poder se puede hacer a pelo, pero hay una buena razón para que se utilice. Más de uno conozco que no hizo otra cosa que echar pestes durante años de jquery, hasta que lo entendió, y calló como un muerto.
También es cierto que hoy día con CSS3 se pueden hacer muchas virguerías. Yo me curré una galería de fotos 3D que queda que te cagas.
Si, nos hemos olvidado. En coding horror lo explican muy bien: http://blog.codinghorror.com/why-cant-programmers-program/
#43 Os. Os. A los que programen en C, Python, y demás, no les pasan esas cosas ni locos.
" The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution."
Wut, si esa la he hecho con Scheme
#46 No es algo exclusivo del mundo javascript & web, yo lo he visto con conceptos muy básicos de la informática.
#43 Más que "olvidado", creo que es gente que nunca ha sabido, pero que el sistema educativo no hace nada por filtrar y les deja pasar igual.
#71 Según lo que veo con NPM el cachondeo es tan que hay funciones para lo más básico. Y encima mal implementadas, en vez de realizar una librería con ello.
Lo que veo con JS solo lo ví en perl... con CPAN con los módulos creados para autoparodiarse con ACME:: con longitudes ridículas y funciones chorras y cortas, pero al ser clasificados automáticamente "de coña", se permiten ciertas licencias (y encima con ello aprendes a usar y empaquetar módulas para CPAN )
Por ejemplo en el módulo ACME::Eyedrops tienes estas locuras:
http://search.cpan.org/~asavige/Acme-EyeDrops-1.62/lib/Acme/EyeDrops.pm
Lo de NPM con JS es que es demencial.
#74 Y encima mal implementadas, en vez de realizar una librería con ello.
Lodash. Ese problema en JS está superado desde hace mucho tiempo ya. Otra cosa es que la gente ponga una dependencia de mierda que le funcionó en su día y se olvide.
Es de sentido común que un "módulo" de 11 líneas no tiene ni pies ni cabeza.
A mi lo que me parece curioso es esa facilidad para utilizar librerías externas de un repositorio. Es útil porque se supone que el propietario la mantiene y actualiza y "tu", te despreocupas.
Pero, sin ser programador, yo tiraría por descargar las librerías a un repositorio local (controlado) e ir actualizandolas con las, una vez probadas, oficiales.
Asi, supongo, que es bastante mas complicado que estas cosas pasen o que un cambio te reviente tu aplicacion.
Saludos
#38 lo normal es indicar en las dependencias de tu proyecto no solo los paquetes si no la versión exacta que usa de cada paquete y testeas tu proyecto solo con esa versión. Así te despreocupas de los problemas que puedan haber en versiones futuras de tus dependencias.
Luego (una vez al año por ejemplo) puedes ver si hay actualizaciones de tus dependencias, intentar actualizar, y ver si todo va bien (tu proyecto sigue pasando los tests unitarios)
Aqui esta lleno de 'premio nobel' , me gustaria ver sus GitHub's ....
#100 Porque todo el que llama mierda a la mierda, es un "premio nobel" engreído, ¿verdad?
Supongo que tú la llamas "postre" y te la comes.
Un día de geniales ideas del desarrollador de la librería que usas y esa función que tanto te ayudaba pasa a ser Deprecated.
Es sencillo si optimizas el tiempo de desarrollo, el coste del producto (aplicación, juego,...) es mucho menor, o eso sería lo normal, porque hay cada precio que... el caso es que si todo se tuviese que hacer, sin poder usar librerías, reutilizar código, etc. Los costes se dispararían una barbaridad.
Salu2
Mierda, otra vez que llego tarde a la comparación de pollas
Creo que aquí el problema viene por como funciona NPM.
En otros casos para utilizar una librería te la descargas y la incluyes en el proyecto (un jar por ejemplo). En estos casos aunque desparezca la librería del repositorio tu proyecto sigue funcionando.
Sin embargo por lo que he entendido (no conozco NPM ni programo en javascript) el problema es que no te la bajas, la usas desde el repositorio donde está colgada (puede que la cachee, pero supongo que de vez en cuando refrescará la caché).
En este caso si desaparece del repositorio, o desaparece por completo el repositorio, entonces es cuando falla todo.
#31 Exacto, si "despublican" el paquete, se jodió.
#31 #106 Sí se descargan
#31 Funciona igual que maven o apt o composer o pip, etc.
Lo que no entiendo es que siempre actualice las librerías a la ultima versión. No se vosotros, pero yo si tengo dependencias, mis dependencias están en una versión concreta, y si esas librerías se actualizan soy yo quien testea primero y decide después si se incluyen o no.
#61 En npm puedes definir por cada dependencia de tu proyecto si quieres una versión fija, sólo actualizaciones de patch, de minor, de major o directamente lo último de lo último. Es responsabilidad de cada uno controlar las dependencias de su proyecto.
#61 En este caso lo que ha pasado es que el desarrollador directamente ha des-publicado todas las versiones.
Lo que desde luego no tiene ningún sentido es reescribir algo que ya esta escrito. Si el problema es que el gestor de paquetes no da las garantías necesarias (básicamente garantizar la accesibilidad y la inmutabilidad de versiones publicadas) la solución no puede pasar por reescribir o hacer copy&paste del código. Hoy copio esta función, mañana aquella otra, pasado otra más y al final termino con una montaña de código a mantener en mi proyecto por que no quiero añadir dependencias, gran idea si señor.
No vendría mal de paso entender porque en la comunidad js existe la tendencia a hacer librerías pequeñas, cuando incluyes una dependencia en js el código de esa librería lo tienes que distribuir junto con tu aplicación, esto en una app cliente js implica que el tamaño de tu aplicación aumenta, así que si hacemos una librería gigantesca con montones de funciones y luego la incluimos solo para usar un par de cosas nos llevamos la librería entera y aumentamos considerablemente el peso de nuestra aplicación. Por eso es tan habitual ver esas micro-librerías en js que pueden resultar chocantes para gente que venga de otros entornos donde realmente añadir un poco más de peso a la aplicación no es tan relevante (sobre todo el entornos servidor).
Vamos, que antes de decir que le problema es que la gente no sabe programar y yo si que soy muy listo, como hace el autor del blog, no vendría mal entender un poco mejor las motivaciones que tuvieron otros programadores para hacer las cosas así.
#0 "Lo que me interesa aquí es que tantos paquetes adquirieran una dependencia de una simple función de relleno cadena izquierda, en lugar de tomar 2 minutos para escribir una función tan básica por sí mismos."
Precisamente se adquiere dependencia de una simple función de relleno cadena izquierda, en lugar de PERDER 2 minutos reescribiendo una función tan básica que ya han escrito miles de personas antes que tú.
#67
Así me gusta, que se aprenda.
Luego ya de paso importamos el módulo de la aplicación, le cambiamos un poco los iconos, instanciamos una nueva clase y a lanzarla.
Sin NPM y StackOverflow muchos estarían en el paro.
#69 Oh, claro, todo buen programador que se precie debería diseñar su propio compilador en ensamblador, incluso su propio interprete de lenguaje si me lo permitís. Porque comprender la orientación a objetos, la instanciación, ahorrar tiempos, ser más eficiente y rentable... ¡bah, eso no tiene nada que ver con la programación!
#71 Entre la parida número 1 que escribiste en #67 y el extremo contrario (parida número 2 en #71) hay diferentes grados.
Los que tienen cabeza la utilizan para pensar en vez de repetir como loros lo que creen que dicen los "pros". Defender esto para un módulo de 1 línea es absurdo.
De hecho, ya puestos, hagamos un programa de millones de líneas y que cada línea sea una dependencia. Total, como ya la escribieron otros antes, así somos millones de veces más eficientes. ¿A que sí?
#71 " incluso su propio interprete de lenguaje si me lo permitís. "
Sí. Debería.
Al menos un intérprete de LISP.
Usando la librería adecuada te aseguras de tener la posibilidad de mejoras funcionales y de rendimiento. Más aún en lenguajes de script donde alguien puede decidir programarla en un lenguaje de verdad y llamarla mediante una interfaz.
En cuanto a la pregunta de la noticia mi opinión es que muchos scripters nunca aprendieron.
#3 Propongo una nueva función:
function add(a, b)
...para asegurarnos de tener la posibilidad de mejoras funcionales y de rendimiento
Yo no, nunca he tenido ni jodida idea, así que...
Como casi siempre en informática no creo que haya una respuesta Última y Verdadera. Lo que tienes que saber es qué estás haciendo.
Una función propia sólo sabes que funciona en los casos que tú pruebes. Y nadie la va a tocar que no seas tú (o tu equipo). Una función de un paquete sabes que funciona en muchos más casos de los que tú pruebas, pero la puede tocar gente que ni conoces (y por tanto esta gente está alterando tu aplicación, sin saber nada de ella ni sus objetivos).
Ya sabiendo esto, pues que cada cual elija qué "subcontrata" y qué hace él mismo. Si tengo el código de una característica no crítica, importaré paquetes. Si tengo un código donde el rendimiento es crítico, no importaré paquetes aunque funcionen si no sé que su objetivo es ser lo más rápido posibles, por si en el futuro cambian la implementación a algo más robusto pero mucho más lento. Si no sólo el rendimiento es crítico, sino que ese es mi factor diferenciador, no me la jugaré y directamente lo haré yo sin llamar a ningún paquete, porque ahí necesito todo el control. Etc.