Portada
mis comunidades
otras secciones
#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.
La reutilización de código no solo no es criticable si no que es altamente recomendable.
#10:
#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.
A veces es mejor duplicar una función sencilla que enlazar a toda una libreria que no necesitas.
#20:
#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.
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.
#32:
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.
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.
#8:
#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...
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...
#51:
#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%.
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%.
#17:
Que tiempos aquellos en qué los hombres eran hombres de verdad y se programaban sus propios drivers de impresora...
#29:
#19 #17 ¿Binario? ¡Bah! Los verdaderos programadores usan el aleteo de una mariposa para cambiar el estado de los bit.
https://xkcd.com/378/
https://xkcd.com/378/
#22:
y asi es como mierda de APPs ocupan 40mb
#21:
#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.
#15:
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.
Es preferible perder dos horas buscando una librería que ha desaparecido que dos minutos programándola.
#66:
#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.
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.
#23:
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.
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.
#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.
#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.
#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.
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...
#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...
#19 #17 ¿Binario? ¡Bah! Los verdaderos programadores usan el aleteo de una mariposa para cambiar el estado de los bit.
https://xkcd.com/378/
#4 hipsters programadores de node.js, volviendo a demostrar sin querer, lo mierda que es Javascript.
#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.
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.
#4 Anda, que será en C/C++ no hay problemas con librerías
std te viene de serie pero boost no.
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.
#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%.
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.
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
#17 Y en binario, nada de mariconadas de ensamblador.
#4 relacionada https://www.meneame.net/go?id=2586452
#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.
#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.
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.
#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.
#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.
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
#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
"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????
#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.
#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.
#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
Es javascript. Aún no han aprendido
#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.
#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 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.
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.
#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
#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.
#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.
#26 C++ y una lavadora... Todo permite hacer mas que JS
#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.
#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/
#41 es al revés, 72 paquetes dependen de el.
Aquí, la cantidad de módulos de los que depende jquery que cuentan con un script .
http://dustycloud.org/blog/javascript-packaging-dystopia/
#63
#12 Pero una buena parte boost aparece como c++14-17 .
Y por defecto C++ permite hacer mucho más que JS.
#50 y paquetes que dependen de esos 72 ya ni te cuento.
#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.
Aprovecho de dejar para el que lo quiera:
https://github.com/jezen/is-thirteen
Una vez descubrí que existía no tuve que hacer nunca más comprobaciones a "pelo", ahora mi programa es más elegante.
#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.
#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
#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.
#128 Ya, si a todos nos pasa igual. Solo que nunca había visto antes código en gallego, y me ha parecido curioso.
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.
#12 Ya están pensando en meterla en la siguiente versión.
#7 por desgracia una mierda necesaria...
#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:
#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.
#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.
#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.
#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.
#109 Y si no te dejan reinventarla, copiala, y dí que es tuya.
#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.
#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.
#44 Cierto, en C glib no da para mucho
#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.
#89 subelo a github
#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.
#120 Es una herramienta para facilitar la vida al programador.
Se podría decir que lo que te facilita por aquí te lo complica por allá
#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
Si, es evidente, lo veo todos los días con personas que no saben ni lo que es un incluye, ni lo adivinan. Siguiente cuestión ?
El caso es que se ha intentado importar el modelo Unix/*nix like y se ha hecho jodidamente mal.
Espero que lo solucionen.
#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!
#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.
#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.
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.
#127 Porque está escrito para mi, solo puedo ocuparme de la página muy de vez en cuando, y me cuento cosas para que cuando vuelva a meterme no tenga que averiguar por qué hice una cosa de un determinado modo (o me dejo a veces cosas a medias, por si lo acabo en otro momento, o funcionalidades extendidas; por ejemplo ese carrusel algún día llevará la imagen de fondo y el texto aparte y está listo para eso, pero aún no tuve tiempo de ponerme con ello y hay otras prioridades).
No es habitual (creo) que nadie ande examinándolo.
#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.
#120 Las metáforas que haces no son equivalentes, porque en los neguajes dinámicos sí que hay formas de detectar y corregir estos errores.
Y da la casualidad de que para ciertos problemas, el tipado dinámico facilita mucho las cosas (o más bien se podría decir que el tipado estático no aporta nada excepto mayor tiempo de desarrollo) y ahorra cantidades considerables de tiempo y simplifica los programas, y decir que "no tendría que existir" es básicamente hablar sin conocer. Esos lenguajes surgieron para cubrir ciertas necesidades, y tienen diferencias significativas de productividad ne los nichos en los que se usan.
Obviamente para determinado tipo de problemas, el tipado dinámico es totalmente inadecuado, pero da la casualidad que no se usan lenguajes con tipado dinámico en ese tipo de problemas.
Al menos yo tiendo a usar la herramienta más adecuada para cada problema. Para eso hace falta haber usado varias cosas y saber los pros y contras, y no aplicar el mismo enfoque y punto de vista a absolutamente todo.
Si, nos hemos olvidado. En coding horror lo explican muy bien: http://blog.codinghorror.com/why-cant-programmers-program/
#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.
#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.
#110 Ok, acabo de volver a leer la noticia original, y he visto que solo fallaron cosas durante los desarrollos o despliegues.
"and thus fell over during development and deployment"
Como comentaba no conozco NPM ni programo en js, y había entendido que se habían caído proyectos ya en producción, por eso supuse que tenía que ser porque lo llaman online en vez de descargarlo.
Siendo así no hay mucha diferencia entre este caso y cualquier otro uso de librerías, sea en java, PHP, C o lo que sea.
#118 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, lo siento mucho pero es un inútil.
Eso es como decir que los tipos de modificadores de acceso de los lenguajes son innecesarios porque si el programador hace bien las cosas es capaz de estructurar bien su código.
O que no es necesario un analizador sintáctico que corrija errores, que el programador tiene que tener experiencia.
NO. Son herramientas del lenguaje que facilitan buenas prácticas (en el primer ejemplo el encapsulamiento en la orientación a objetos), y mejoran la productividad (el completado de código es mucho mejor cuando se infieren los tipos de los datos, y la detección de errores es mucho mas eficiente).
El tipado estático favorece la detección de errores para los que la ejecución tendría que cubrir potencialmente millones de posibles estados del programa.
La fase de análisis semántico de los compiladores (jodidamente ardua, como sabrás si has programado un compilador en la universidad) no se inventó por capricho. Es una herramienta para facilitar la vida al programador.
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
Aqui esta lleno de 'premio nobel' , me gustaria ver sus GitHub's ....
#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.
#142 Lo que intentaba exponer en mi comentario anterior es que no se trata de que no sepas o no puedas crear fácilmente unas funciones de manejo de cadenas. Se trata de que si quieres tener la garantía completa de que tu aplicación funciona exactamente igual que antes (igual de bien o igual de mal), es preferible recuperar las librerías originales, porque te evitas sorpresas. Depende del grado de fiabilidad que necesites en tu aplicación, a veces es mejor lo malo conocido que lo bueno por conocer.
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.
#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.
Más bien nos hemos olvidado como traducir español, porque parece escrito por un mono borracho que sólo sabe traducir literalmente.
Respecto a lo que dice el artículo: como en todo, hay mucho idiota. Es lógico no reinventar la rueda, pero a lo único que lleva el exceso de dependencias triviales es a no saber qué demonios hace el código y muy probablemente a que se hinche.
Personalmente, sólo uso librerías cuando es algo que realmente es complejo de hacer y llevaría meses. Si es algo que lleva un par de horas y no está relacionado con cosas críticas como la seguridad, mejor hacerlo uno mismo ya que tener control total a la larga es mejor.
#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.
#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).
#123 No voy a ponerme a perder el tiempo en dar ejemplos concretos. Si quieres saber por qué es más adecuado para determinado tipo de tareas, lo mejor es que aprendas a usarlos y lo compruebas por ti mismo.
Lo último para lo que he usado Python por ejemplo es para generar un montón de HTMLs estáticos que era necesario crear en función a unos parámetros y archivos para que alguien los emplease en una plataforma de contenidos. En total me llevó 20 minutos y funcionó a la primera.
Si quieres un ejemplo genérico, en videojuegos, las tareas de alto nivel se suelen hacer en Lua o Python, porque es absurdo andar peleándose con C++ para hacer una escena o definir el comportamiento de un personaje u objeto cuando se puede hacer mucho más rápido y sencillo en un lenguaje de más alto nivel.
#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í?
#152 Pues eso.
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.
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
#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
#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.