#200#22 Yo no he visto evidencias sobre las cosas que dice el meneo pero sí vi en Wikipedia otras evidencias de diferencias innatas entre cerebros y capacidades cognitivas entre sexos.
Una de la que creo que existen mayores evidencias es la influencia de la testosterona en la mayor capacidad de visión espacial.
La testosterona es una hormona típica masculina que producen en mayor cantidad los testículos de los hombres (y en las mujeres suele ser escasa aunque también la producen). De este modo se puede decir que es algo innato tener más testosterona o no tenerla: si tienes testículos tendrás más y si no los tienes tendrás menos. ¿Y cómo se llega a la conclusión de que es la testosterona y no otra cosa? Por lo visto, algunas mujeres, con vagina y ovarios, tienen más testosterona de lo normal o se encontraron con más testosterona cuando estaba desarrollándose su cerebro en el vientre de su madre y resulta que coincide que tienen mayor capacidad de visión espacial. Esto descartaría que fuese una capacidad desarrollada socialmente... en plan que por ser chicos la sociedad les haga interesarse más por esas cosas... porque como dije son mujeres y tienen vagina y ovarios y se supone que socialmente las han visto como mujeres y las han tratado como tales y, sin embargo, tienen mayor capacidad cognitiva en ese apartado de visión espacial. Esto parece ser una evidencia fuerte de la influencia de las hormonas en la configuración cerebral y que ocurre antes de nacer, nada que ver con algo debido a la sociedad o estereotipos que digan que por ser hombre debe interesarse por motos y coches u otros artilugios que se mueven.
Este último se centra en las diferencias cognitivas (no tanto en IQ y eso) y trata otros asuntos como capacidades verbales o capacidades sociales como la empatía.
En los enlaces se pueden las fuentes, los correspondientes estudios científicos.
Nota: creo que en muchos casos los estudios son observacionales, que encuentran correlaciones fuertes, y para asegurar con mucha certeza estadística la causalidad se necesitarían estudios de intervención... pero claro, experimentar con humanos puede ser algo poco ético o complicado.
#60 Tienes razón, perdona. En todo momento me estaba refiriendo a un mac de 2015, no de los nuevos con M1. Imagino que Davinci Resolve irá como un tiro con el M1.
#37 yo no he tenido una buena experiencia editando con Davinci Resolve. Para tema color y toque final sí, pero a trancas y barrancas. Al menos en un Mac que normalmente se usa para desarrollar apps móviles y web con IDE’s pesados (basados en Java)
#46 Aunque en temas de GPU, al que hace referencia #24, Apple seguro no depende para nada de GPU dado que las diseñan internamente. Samsung sigue usando Mali, que son los diseños de ARM en sus procesadores: www.samsung.com/semiconductor/minisite/exynos/products/all-processors/ . Qualcomn con sus diseños de GPU Adreno están como Apple.
Pero de todas formas, Samsung y Qualcomn siguen usando bastante diseños de ARM en sus procesadores. Y Apple, que probablemente sea el que más costumiza las cosas, sigue usando el juego de instrucciones diseñado por ARM en sus procesadores. Hay bastante propiedad intelectual que todas estas compañías están pagando a ARM, que sigue siendo válida bajo los contratos actuales. Pero modificaciones futuras puede que signifique para Apple diseñar desde cero un sistema de instrucciones de procesador con compiladores asociados, etc... no algo que no puedan hacer, un coste extra. Eso sin entrar en diferentes batallas legales donde unos y otros intenten ver cuan de diferente son sus nuevos diseños con instrucciones nuevas con respecto a los antiguos para considerar que no deben seguir pagando propiedad intelectual a Nvidia.
#46 Las CPU que fabrica Apple deben pagar licencias a ARM, que por así decirlo es la "dueña" de la arquitectura. No creo que esta compra les afecte mucho, excepto que quizás Nvidia pase a tener una mejor posición a la hora de venderles GPUs para sus Mac. Hay que recordar que al menos en portátiles van a pasar a utilizar CPUs ARM y ahora mismo están utilizando GPUs de AMD.
#34 Yo si se las vi siempre. De hecho me molestaba como la gente se quejaba y sin embargo te dotan de herramientas cojonudas, de las que incluso tu puedes crear híbridos o cosas nuevas usando o mejorando esas técnicas.
Pero vamos, es la típica función a la que llegas cuando tienes un tiempo en un lenguaje. Es de nivel especialización. Y si, es un ejemplo de magia en un lenguaje. Al menos lo que yo llamo magia. La solución de javascript no me gusta, a mi. No me gusta que las variables sobrevivan a las funciones... es muy confuso, a menos que el ámbito esté muy claro, y si ese ámbito existe, déjalo bien claro. Las clases hacen eso, y aún asi, fuera de la clase no salen. Las cosas "bien recogidas" parea poder seguirles la pista.
Pero si la gente del mundillo de javascript, consideráis a reduce una buena implementación, forma parte de la cultura del lenguaje, te adaptas. Es bueno pq marca un patrón reconocible por todos.
#30 Ok, es que al tema de que una variable sobreviva a una función, solo le veía utilidad para simular la POO en javascript. Sospecho que total, sobrevive con su valor de una llamada a otra de la función por cada elemento, y current es sobreescrito en cada llamada.
Supongo que tiene utilidad pq al ver el reduce() los que le dais más caña al javascript ya sabéis lo que se intenta hacer. Me has medio convencido, oka. Tiene valor semántico.
#26 Es que sigo leyendo y con la documentación delante, me cuesta VER como maneja total y current... como si la función la defines tú, como reduce sabe que "current" es el componente del array... y eso que llevo un rato mirándolo.
El ejemplo de antes lo pillé enseguida, pero para entender el nuevo en su totalidad el código, pq hay "magia", sigo sin pillarlo, tengo que seguir navegando en más y más documentación, si es que lo pillo con suerte.
La propia función reduce se comporta de maneras diferentes según el contexto de la llamada, tienes que leerte bien la documentación para saber que hace en cada caso... ESO ES MAGIA. La primera versión es mucho más simple. si lo que quieres es ahorrarte las variables de recorrido, cojonudo, los iteradores llevan inventados décadas.
#26 Esa flecha de que lenguaje es? la de =>... me estuve leyendo por ejemplo, en java, y necesitas un artículo bastante largo para entender lo que hace, de tal forma, que días después de habérmelo leído, ya no lo recuerdo, y soy incapaz de aplicar su versión más potente. Un sólo símbolo implicaba demasiadas cosas a la vez según el contexto.
Si te especializas en un lenguaje, cojonudo, pero si estas todo el día con varios... es un coñazo que sean tan complicados. Todo se puede simplificar con una función.
Yo podría sustituir tu código de arriba, por un bucle for supuestamente complicado, aún así corto y testado, y ponerle un nombre descriptivo. PERO eso son gustos, nada más. Sigo leyéndote y no entiendo nada. Quizás es que desconozco ese lenguage, pero bueno, me leeré el artículo para entender, después de un montón de explicaciones, la maravillosa ventaja de ahorrarte 7 lineas de código.
Esas cosas se las dejo al algoritmo, que si puede ser complejo, pq muchas veces no queda otra. O a la estrutura de datos, el modelo, pero el lenguaje... a mi me gusta poder "traducir" lo más rápido posible. Pero decidir que es una verdadera ventaja es una cuestión de gustos.
Si me justificas la reutilización, cojonudo. Si me justificas la eficacia, cojonudo. Pero cambiar 7 lineas de un código que entiende casi cualquiera que venga de casi cualquier lenguaje, por unas lineas que tengo que empollarme a ver que están haciendo (magia: unos pocos caracteres implican muchísimas cosas y encima cambian según el contexto), no se si es buen negocio.
#1 Como dice #2, es más legible lo primero. Más que nada porque te has “comido” la indentación que tenía, y eso es hacer un poco de trampa.
#3 Creo que quizás te refieres a que es más entendible el bucle for, que es a lo que estamos acostumbrados (como dice el artículo). Pero con dos líneas de código, es más legible lo primero que lo segundo con siete. Creo que #4 te lo ha explicado muy bien.
#2 Eso creo que es discutible. Personalmente, aunque más largo, veo más legible el for.
Por otro lado y como comentan en el propio artículo. Lo único que se está haciendo es ocultar el for, porque internamente la función array.reduce lo utilizará. El usar una función por supuesto lleva implícito un mayor coste de proceso.
#22 geburah 
