TECNOLOGíA, INTERNET, JUEGOS
237 meneos
5462 clics

NPM y left-pad: ¿Nos hemos olvidado de cómo programar? [Eng]

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.

| etiquetas: programación , javascript , npm
114 123 5 K 273
114 123 5 K 273
Comentarios destacados:                                  
#1 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.
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?

:palm:

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?

:-S

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, golang.org/pkg/net/url/#pkg-examples hay un paquete con varias funciones que es para "parsear" una uri. O en perl 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. xD
#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…   » ver todo el comentario
#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: twitter.com/karldyyna/status/713285297837121536
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…   » ver todo el comentario
#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.
#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:
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…   » ver todo el comentario
#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 :palm:

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…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#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.
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) {
return a+b;
}

...para asegurarnos de tener la posibilidad de mejoras funcionales y de rendimiento ¬¬
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
#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.
qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny
#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.
#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
#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. "

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
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?
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.…   » ver todo el comentario
#57 vaya troleada :foreveralone: :foreveralone: :foreveralone:
#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…   » ver todo el comentario
#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) {
return a+b;
}

¡A reutilizar se ha dicho!
Y cuando la librería mejore... mmm... ¡la de estabilidad y rendimiento que podremos ganar! :roll:
Que tiempos aquellos en qué los hombres eran hombres de verdad y se programaban sus propios drivers de impresora... :shit:
#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. :troll:

xkcd.com/378/  media
#19 Con pulsadores eso de tener una terminal es de maricones. xD
#17 ...y sabían sumar y restar, y usar las funciones que les daba el lenguaje.
y asi es como mierda de APPs ocupan 40mb
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. :-D
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.
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.
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.
Yo no, nunca he tenido ni jodida idea, así que...
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
Es javascript. Aún no han aprendido :troll:
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)
"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.
Si, nos hemos olvidado. En coding horror lo explican muy bien: 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.
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.
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.
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 .
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.…   » ver todo el comentario
#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 :palm: :shit:

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!

:palm:
#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 :-D )

Por ejemplo en el módulo ACME::Eyedrops tienes estas locuras:
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.
#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.
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…   » ver todo el comentario
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,…   » ver todo el comentario
Programadores de Javascript enfrascados en sus tareas:  media
Mierda, otra vez que llego tarde a la comparación de pollas
#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.
«12
comentarios cerrados

menéame