#59 Pues eso. Que en referencia a lo que decías en #30, la mejora de M1 con respecto a CPUs anteriores en edición de vídeo no sólo es un tema de FCPX sino que se aplica a otras aplicaciones no desarrolladas por Apple.
Yo con el M1 he podido editar y hacer corrección de color (incluyendo reducción de ruido) en 4k con reproducción en tiempo real. Con ningún otro Mac lo había podido hacer.
#30 Lo mismo se puede decir de Davinci Resolve y no es Apple quien lo desarrolla precisamente. Y Premiere/After Effects son usables aún corriendo sobre Rosetta.
#53 Apple (y otras como Intel) tiene con ARM lo que se llama una licencia perpetua de arquitectura, lo que le permite tener acceso al set de instrucciones. El diseño de Apple Silicon se basa en el set de instrucciones y no en el diseño de ARM, por lo tanto decir que "van a pasar a utilizar CPUs ARM" es impreciso: van a pasar a utilizar sus propias CPUs. Que ahora mismo estén utilizando GPUs de AMD es irrelevante porque con toda probabilidad las GPUs de los nuevos Mac no van a ser Nvidia, AMD o ARM sino que van a ser parte del mismo SoC, igual que en el iPad o el iPhone.
#24 No cambia mucho lo que dices ya que afectará a actores importantes como Samsung pero Apple ya no depende de ARM para el diseño (por eso los nuevos SoC se anuncian como "Apple Silicon").
#13 Ese inserto ("[de la pandemia]") la verdad es que no veo de dónde se infiere del vídeo, y lo he visto varias veces seguidas para intentar entender de donde sale. No se puede deducir de manera clara que quiera decir "de la pandemia" por lo que parece un añadido apresurado, erróneo e incluso malintencionado.
Es más, Torra dice "queremos ser independentistas" y no "queremos ser independientes". Es un matiz pequeño, pero un matiz al fin y al cabo. Y seguramente intencionado también.
Que Torra sea un inepto no justifica que un diario de tirada nacional tergiverse y se invente las cosas de esta manera, que luego llega la gente y se lo come con patatas porque verse el vídeo como que no, eh, que da pereza.
#28 El target principal de este tipo de monitores son estudios y salas de post-producción, que están hartos de tirar stands a la basura porque el estándar es colgar los monitores en monturas VESA. Por lo tanto, algo de sentido en vender el stand aparte sí hay (no entro en lo caro que es, sólo matizo eso de "nadie habría dicho nada").
#33 Toda la razón en eso. De hecho creo que aunque estas maneras funcionales existan, no deberían ser excusa para no entender cómo funcionan "por dentro". Pero una vez entendidas bien, ayudan a escoger mejor la herramienta correcta para cada caso. No siempre se puede aplicar map, filter o reduce pero, cuando se puede, se agradece.
De hecho recuerdo haber aprendido sobre estas cosas en pseudocódigo en la carrera (inmersión, plegado/desplegado, de recursivo a iterativo y viceversa, etc) y en su día no verle la utilidad. Sin embargo a día de hoy soy fan
#29 La reducción es un proceso iterativo. En cada paso, tienes un valor, que es total, y que empieza por el valor inicial (en este caso 0), y tienes otro valor, que es current, y que empieza por ser array[0]. En el primer paso, ejecutas la función pasada como parámetro de la función (en el ejemplo: total + current), y obtienes un valor de retorno. Ese valor de retorno pasa a ser el valor total para el siguiente paso, y current será valor[1]. Así sucesivamente hasta que no queden más índices en el array, y total pasará a ser el valor de retorno de la llamada a reduce.
Esto que he explicado, es siempre así, sean cuales sean los parámetros pasados a reduce. Por lo tanto, el funcionamiento de reduce no depende del contexto, sino de los parámetros, como cualquier otra función. Sigue sin ser magia.
#28 Respecto a =>, yo estaba como tú, no sabía lo que significaba porque yo hace tiempo que no hago nada con Javascript, y hoy he visto por el ejemplo del artículo que así es como se especifica un lambda (una función anónima) en ES7. Pero no me ha costado nada entender qué hace esa línea de código porque he visto reduce ya en muchos lenguajes (como reduce o como foldLeft): Java, Scala, Python, Ruby, Haskell, LISP, Clojure y el funcionamiento es siempre el mismo, y el contexto poco tiene que ver. De hecho, no tiene nada que ver porque la forma de utilizarlo es siempre la misma: secuencia, función, valor inicial. Así que no, sigue sin ser magia según tu definición.
Entiendo lo que dices, pero como otros comentan por aquí, lo atribuyo a la falta de hábito con la programación funcional. Personalmente, después de haber hecho muchísima programación imperativa, muchísima OOP y bastante programación funcional, por poco que me cueste entender un bucle for, siempre me será más sencillo entender un reduce. ¿Cuántas variables se definen antes del bucle que vayan a afectar al bucle? ¿Qué variables cambian dentro del bucle? ¿Para qué van a servir esas variables y que resultado, o resultados va a generar el bucle? Todo eso es necesario procesarlo mentalmente para entender el código. Sin embargo, con reduce tienes una secuencia, una función y un valor inicial, nada más.
Que quede claro que en ningún caso esté diciendo yo que 1 línea siempre sea mejor que 7. Lo que digo es que, con conocimientos básicos de programación funcional, es más legible el reduce que el bucle for. Igual que es más legible un bucle for que un "bucle" en assembler hecho a base de escrituras en registros y saltos condicionales.
#25reduce está lejos de ser magia. Es simplemente una reducción de una secuencia de valores a un solo valor de resultado, aplicando la misma función al par de valores [resultado parcial, siguiente valor] en cada paso.
Por lo tanto, array.reduce((total, current) => total + current, 0) lo que hará será:
((((0 + 1) + 2) + 3) ... + n)
Vamos, lo mismo que hace el bucle for pero sin tener que preocuparse de tener que inspeccionar el código para encontrar qué variables se definen, qué variables se usan y cómo. Las reglas de la programación imperativa como las que rigen los bucles pueden parecer simples, pero pueden provocar un código innecesariamente complejo muy fácilmente.
#3 El for no es más legible porque para poder entender lo que hace, tienes que rastrear qué variables hay y cómo están mutando. La semántica del reduce está muy clara (es un fold-left típico) y por lo tanto con sólo ver qué es un reduce y cómo se actualiza el valor con cada item de la lista se ve enseguida lo que hace la línea de código.
Y sí, el reduce esconde un bucle (no siempre, también podría ser una recursión con TCO en otros lenguajes) pero el for también esconde otras cosas, como por ejemplo saltos en base a condiciones (en el intérprete, en bytecode o en assembler). Que una instrucción sea de un nivel más alto no es algo malo per se, mientras la semántica de la instrucción sea clara, ¿qué problema hay? Es mejor y más legible un for que escrituras de registros y saltos, pero del mismo modo es más legible un reduce que un for.
#27 No has refutado lo que dice #21. Un axioma es, por definición (y supongo que a eso se refiere con "en última instancia"), un punto de partida del sistema lógico, no una proposición que se pueda someter a demostración.
#187 250 comentarios y el tuyo es el único que se centra en el fondo del asunto y da en el clavo. El mercado de Apple no son los gamers, sino los profesionales. Y a éstos dales una FirePro (o una Titan, pero sería discutible) antes que una 970, una 980 o una 290x.
#86 estadista.
(De estado).
1. com. Persona que describe la población, riqueza y civilización de un pueblo, provincia o nación.
2. com. Persona con gran saber y experiencia en los asuntos del Estado.
estadístico, ca.
1. adj. Perteneciente o relativo a la estadística.
2. m. y f. Persona que profesa la estadística.
#2 Tampoco nos pasemos, mucha gente en Internet y en algún medio habló de la pérdida de Dennis Ritchie. Sin embargo, del que nada se leyó fue de John McCarthy que murió dos semanas más tarde, y aquello sí que dio bastante lástima ya que a nivel de relevancia (influencia a largo plazo) estuvo al nivel de Ritchie o incluso por encima. A Dios rogando y con el mazo dando.
#15 micawber 
