Feda /dev/ - No Javascript allowed

#61654 ?

#61658 hoy miraba rams.

sabes la tipica pregunta de system design, diseña una pipe line, o un sistema que haga blah blah con archivos grandes...

y tu preguntas? Como de grandes? Te dicen muuuy grandes, en plan 200 GiB, 300GiB...

a ver... eso me cabe en RAM

pues imagínate que no te cabe...

PUES COMPRO MAS RAM
https://downloadmoreram.com
https://downloadmoreram.com
https://downloadmoreram.com

de hecho para que lo sepais todos, 1TiB de RAM = 5k usd

https://www.amazon.com/4x256GB-DDR4-3200-PC4-25600-Registered-Workstations/dp/B08F2VBK2S?th=1

cuanto cobra un ingeniero? un equipo de ingenieros? cuanto cuesta montar una pipeline con por ejemplo: kafka/rabbit/spark que dumpee los datos a un S3, haga sharding y blah blah...

por 50k tengo 10 maquinas de 1tb procesandote lo que quieras en paralelo, chunk upload y si puedes procesar en stream por el formato del archivo ya has triunfado.

vamos, que el CLOUD esta muertísimo

PS: sin entrar en que cargar de un SSD hoy es una locura de rapido también jaja, que podrias guardar en SSD sin saturar el NIC xq desde el user no da

La programación funcional es un completo desperdicio de tiempo. Los conceptos como la inmutabilidad y la recursión no solo hacen que el código sea más difícil de leer y entender, sino que también resultan en un rendimiento lamentable en comparación con la programación imperativa. Además, la obsesión con la pureza de las funciones lleva a un código que es extremadamente verboso y, en la práctica, nadie quiere mantener un código tan complicado. En el mundo real, donde la eficiencia y la claridad importan, la programación orientada a objetos supera a la programación funcional en todos los aspectos.

#61666 En realidad, SQL no es imperativo, sino declarativo.

#61670 La ironía, un mecanismo interesante, aunque en este contexto no hace más que subrayar las falacias de tu argumento. Sí, los lenguajes funcionales son declarativos, pero eso no mitiga sus limitaciones prácticas. La inmutabilidad, aunque conceptualmente pura, introduce sobrecarga en la gestión de la memoria, especialmente en sistemas de gran escala, donde la creación de nuevos objetos para cada estado intermedio puede ser prohibitiva en términos de rendimiento y escalabilidad. La recursividad, alabada en teoría, puede llevar a un consumo exponencial de la pila de llamadas, un problema que los enfoques imperativos evitan mediante iteraciones controladas. La composición funcional, mientras que promueve la modularidad, a menudo resulta en una abstracción tan profunda que la legibilidad y mantenimiento del código se ven comprometidos. Herramientas como el profiling y la depuración se vuelven laberínticas en un entorno donde cada función puede ser anónima o parcialmente aplicada. Finalmente, la optimización del compilador para código funcional, aunque avanzada, no siempre logra superar las optimizaciones a las que un desarrollador puede someter un código imperativo bien escrito. Así que, si crees que la declaratividad y la pureza funcional son inherentemente superiores, es necesario reconsiderar las implicaciones prácticas y técnicas de tales afirmaciones en contextos reales de desarrollo

#61676 Parece que te aferras a los argumentos de manual sin entender el contexto práctico. La recursión de cola, aunque útil, no es una panacea... muchos compiladores no optimizan automáticamente para ella, y en contextos donde se necesita eficiencia máxima, el control manual de la pila es superior. En cuanto a los "garbage collectors" mejorados, sí, han avanzado, pero el overhead de gestión de memoria en sistemas de gran escala sigue siendo un punto crítico, especialmente con la inmutabilidad que provoca la creación constante de nuevos objetos.

Sobre Clojure, Scala y Spark, asumir que su uso de la inmutabilidad resuelve todos los problemas es simplista. Clojure, por ejemplo, usa estructuras de datos persistentes, pero eso no elmina la necesidad de entender el impacto en la memoria y el rendimiento. Scala y Spark son híbridos, que en muchos casos utilizan mutabilidad para lograr eficiencia en ciertas operaciones.

Por último, la optimización en la compilación de lenguajes funcionales como Scala o Haskell es impresionante, pero no es mágica. Las optimizaciones automáticas tienen límites, y en escenarios donde cada milisegundo cuenta, un programador con un enfoque imperativo puede optimizar manualmente de maneras que los compiladores funcionales no siempre pueden replicar. Así que, si crees que puedo perder una discusión conmigo mismo, al menos lo haría con una comprensión más matizada de los desafíos reales en la programación, sin depender de chistacos sobre colas.