Apple en 2020

Originalmente este post iba a ser de protesta por el amarillismo y la mala interpretación de algunas estrategias de Apple:

Apple desapareció iTunes a partir de la actualización macOS Catalina, muchas voces, muy alarmadas, decretaron la muerte de iTunes.

Cuando en realidad Apple dividió la funcionalidad de iTunes en cuatro aplicaciones: Musica para reproducir música tanto en la biblioteca de uno como en servicio streaming (Apple Music), videos musicales y acceso completo la tienda iTunes. Podcast para reproducir podcast, TV para películas y videos y Libros (bueno, esa ya existía y manejaba todo lo de eBooks, incluyendo la tienda de libros; solamente le dieron una manita de gato).

El asunto es que iTunes desapareció en la Mac, pero sigue intacto en Windows. Sin embargo, también en Win se va dividir en 2020. Es decir, igual que en macOS, iTunes ya no va a existir y en su lugar van a haber cuatro aplicaciones. Eso es todo. Es parte de la estrategia que sigue Apple. No es dramático ni escandaloso ni un volantazo empresarial.

Y sin embargo, algunos medios lo utilizaron como una noticia escandalosa y dramática:

Apple "apostará" por Windows.

Apple 💓 ARM (y a iOS).
La verdadera noticia ocurrió el año pasado, en 2018, cuando Apple anunció que tenía planeado reemplazar los CPUs de las Macs con sus chips ARM para 2020. Esto se relaciona con pequeñas pista que han venido sucediendo en macOS desde hace algunos años: a partir de Mac OS X Yosemite (10.11) lanzado en 2014, Apple empezó a enfocarse en la interacción Mac - iPhone y en darle un aspecto más "a la iOS" a OS X. Obviamente que hubo muchas voces escandalosas e histéricas (como las de la noticia de arriba) que clamaban que ahora Mac OS X iba a ser un iOS grandote igual a un iPhone grandote.
Poco a poco Apple parecía darles la razón a estas voces: Mac OS X no sólo se parecía más a iOS: empezaba a copiar mucho de su funcionalidad, teníamos detección de gestos en las touchpad, llegó la touch bar a las laptop, la intercomunicación entre dispositivos móviles y las desktop era cada vez más poderoso y flexible..., hasta que empezaron a pasar cosas en sentido contrario: Mac OS X pasó a llamarse macOS, las iPads iban a tener su propia versión de iOS llamada iPadOS que le iban a dar un aspecto y funcionalidad muy parecida a la Mac. ¿Entonces? ¿No que todo unificado?

Nop, cada familia de aparatos (computadoras, iPhones, iPads, Apple watch y –ya empezando a desfasarse- Apple TV*) tiene su propio sistema operativo (macOS, iOS, iPadOS, watchOS y –ya desfasado– tvOS*); el objetivo NO es que todo se unifique, sino que todo sea compatible y tenga un tronco común. Y aquí es donde entra lo de los chips ARM.

Una nota para nerds que se pueden brincar todos los demás: desde los inicios de la computación se definieron dos arquitecturas de microprocesadores: la CISC (Complex Instruction Set Computer) que tiene un amplio abanico de instrucciones que se ejecutan en sus registros internos o en memoria RAM. El mejor ejemplo de microprocesadores CISC es el Motorola 6800, Zilog Z80, la familia x86 de Intel y AMD x86-64, entre otros. La arquitectura RISC (Reduced Instruction Set Computer) tiene un conjunto reducido de instrucciones, el tamaño de cada instrucción es fijo y tienen pocos formatos y solamente  las instrucciones de carga y almacenamiento pueden acceder a la RAM (lo que es muy bueno para modelos de seguridad), esto, aunado a que facilitan mucho la segmentación de ejecución (pipeline) y el paralelismo hace que se prefiera sobre el modelo CISC. Ejemplos son el PowerPC (inicialmente desarrollado por Motorola, IBM y Apple, pero abandonado por razones comerciales hasta que solamente quedó IBM), Alpha de DEC (compañía comprada por Compaq comprada a su vez por HP), MIPS de MIPS Technology (no se usa directamente, se compra una licencia y se adapta), ARM de ARM Holdings, su uso es igual a MIPS (aquí es donde entra Apple y su familia de chips A*), SPARC de Sun (comprado por Oracle).

Chips desarrollados bajo arquitectura ARM que a su vez se basa en RISC.

Todos los aparatos de Apple están basados en chips propietarios de la familia A* (A11, A13, A13 Bionic, etc.) menos los Macs que todavía se basan en chips Intel (familia Core i*).
En lo que se hace la sustitución de CPUs de las Macs, Apple proporciona compatibildad de aplicaciones macOS - iOS por medio de la librería Catalyst (bueno, en realidad es un poco más complicado que una simple librería, en el bajo mundo de los desarrolladores se le conoce como "Proyecto Catalyst"). Este punto merece especial atención porque otra vez Internet se ha llenado de voces escandalosas y dramáticas (bueno, no todo Internet, solamente los sitios de noticias Apple). Catalyst es una herramienta de desarrollo que ayuda a los programadores a que las aplicaciones que hacen puedan usar recursos de la Mac (como teclado y mouse) y también de iPhone o iPad (como pantalla táctil y reconocimiento de rostros), es decir, desarrollar aplicaciones compatibles entre plataformas.

No hay que exagerar pensando que puede uno comprar una app para iPhone en la appStore y luego correrlo en la Mac gracias a Catalyst. No. No es así. Que no los engañen.

Catalyst es una herramienta auxiliar de desarrollo, no es una aplicación mágica universal.

Y aquí es donde entra la exagerada noticia de la muerte de iTunes: se dividió en las cuatro aplicaciones que ya existen en iOS y en iPadOS, y en macOS están desarrolladas usando Catalyst. Compatibilidad, no unificación. Y también por eso dejaron el desarrollo para Windows al último; Windows es muy importante comercialmente, sin iTunes para Win y su sincronización con el iPod e iPhone, posiblemente Apple no hubiera llegado a las alturas en las que está ahorita. Obviamente que las aplicaciones no se van a desarrollar con catalyst, posiblemente por eso la nota del principio decía que Apple estaba buscando a desarrolladores con experiencia en UWP (Universal Windows Plataform): no porque Apple ya se vaya a enfocar a Windows, sino porque quiere que sus aplicaciones sean lo más abiertas y compatibles posible.

Por cierto, entre las cuatro aplicaciones está "Libros", y que yo sepa, jamás ha estado disponible para Win, los eBooks de Apple nunca se han podido leer en Win. Lo más seguro es que Apple siga sin desarrollar "Libros" para Win, pero va a ser interesante ver qué es lo que pasa...


Fecha estelar 6301.15

* El aparato Apple TV y el sistema operativo tvOS se están desfasando y –probablemente– sean sustituidos por la Apple TV app y por el servicio de streaming Apple TV+.

Las bibliotecas de Música.

La aplicación que más directamente heredó las capacidades de iTunes es "Música":

El icono, ventana principal y menú de Música, la aplicación de audio heredera de iTunes.

Esta es la configuración estándar de Música, y si ven en el lado izquierdo de la ventana principal, aparece el grupo "Biblioteca" y las diversas opciones de ver toda la biblioteca musical: agrupados por artista, por álbum, por canciones o mostrar videos musicales.
Solamente que yo tenía el problema de que la opción que más usaba era "Géneros", es decir, ver toda mi biblioteca según el género que yo le había asignado a cada álbum, pero ya no aparecía.
Sucede que cuando pasa el puntero del mouse (o touchpad) sobre las opciones "Biblioteca" y "Playlist", se muestran opciones para personalizar la opción. Para la opción "Biblioteca" aparece un letrerito que dice "Editar" que es la que tenemos que usar:

Cuando se pasa la flechita del apuntador por la etiqueta "Playlists", aparece la etiqueta "Ocultar" que lo único que hace es ocultar/mostrar las playlists. Las etiquetas "Apple Music" y "Tienda" ya están fijas, cuando la flechita del apuntador pasa sobre ellas, no aparecen otras etiquetas.










Cuando edité el grupo Biblioteca fue que me encontré la opción para regresarme mi agrupación por géneros.

Se da click en "OK" ya ya quedó restaurada la opción.









Esta opción de agrupación también está disponible en los menús de Música (Visualización -> "Ver como Géneros"):

Fecha estelar 6257.08

macOS Catalina y la sincronización del iPhone

Uno de los cambios más dramáticos de macOS vino con la versión 10.15 Catalina: iTunes se dividió en 4 aplicaciones:

• Música para oir música, videos musicales, accesar a Apple Music (el servicio de audiostreaming de Apple) y a la tienda Apple (sección música).
• Pocasts para oir todos los podcasts disponibles y entrar a la tienda Apple (sección podcasts).
• TV para ver todas las películas y videos compradas en la tienda Apple (sección películas) y todos los que uno haya convertido al formato correcto.
• Libros para leer todos los libros y escuchar audiolibros comprados en la tienda Apple, ePubs y PDFs que uno compre o consiga por otro lado y entrar a la tienda Apple (sección libros y revistas).

Pero Catalina también tiene otro cambio importante: ahora la sincronización de los dispositivos (iPhone, iPad, etc.) se hace a través del Finder.

Ventana del Finder de mi Mac mostrando que mi iPad, aunque viejita (todavía es iPad 2), todavía puede sincronizarse en mi Mac también viejita (en la primera imagen puede verse que es una iMac late 2012). 

Un detalle medio molesto que me pasó: cuando actualicé mi macOS de Mojave a Catalina y conecté mi iPhone, el finder no lo reconocía: simplemente no lo mostraba en el Finder.

Este comportamiento se puede controlar en Preferencias del Finder:

En el tab "Barra Lateral", macOS Catalina incluyó la opción de mostrar dispositivos iOS:

En mi caso, solamente activé esta opción y ya aparecieron el iPhone e iPad en el Finder.

Fecha estelar  6251.04

Programación en la Mac: editores gráficos de texto.

Como mencionaba en el post pasado (Programación en la Mac: los editores básicos), el ambiente de línea de comandos de la Mac (Terminal), macOS X ya tiene instalado el editor vim en ambiente no gráfico; por eso me sorprendió saber que existe un proyecto open source com MacVIM, una versión gráfica de vim para Mac:

MacVIM - Editor de texto para macOS X.

El primer editor de texto gráfico que se viene a la mente es el que ya está incluido en el sistema, TextEdit:

Código de un shell en TextEdit.

Aunque TextEdit no permite marcar la sintaxis mediante diferentes colores, ni tiene funciones de editores de código (autotabs, comentar/descomentar bloque, identación, etc.), tiene la inteligencia suficiente para saber si estamos editando un programa o script o estamos escribiendo un documento:

Si TextEdit detecta que se está editando un texto humano, automáticamente poner la barra de herramientas de formato de texto (tipo de letra, tamaño, color, etc.).

Y aparte tiene la ventaja de que ya está incluido en el sistema.
Hay muchos editores de texto en el mercado (algunos en el App Store –como los que voy a mostrar– y otros no, como MacVIM), por lo que no puedo mostrarlos todos; solamente voy a mencionar algunas características que tienen los editores de código que los hacen más útiles en estas tareas sobre editores como TextEdit:

• Necesario: que reconozcan la sintaxis de uno o más lenguajes de programación y la pongan en diferentes colores.
• Necesario: que el texto escrito se vaya ajustando a la pantalla, pero que el editor reconozca cuando uno escribe una sola línea de código sin meter carateres adicionales.
• Necesario: tener valores configurables para características de fin de línea (CR –mac pre-OS X–, CR/LF –Windows–, LF –todos los SO derivados de UNIX)
• Deseble: que tengan controles para cambiar los colores del editor.
• Deseable: que tengan opciones para identación/desidentación.
• Deseable: que tengan opciones para comentar/descomentar líneas/bloques de código.
• Deseable: que cuenten con ayuda y soporte técnico (ya sea local, en un sitio web o por teléfono). Nota. Esto es necesario si el editor tiene más características de lo necesario (por ejemplo, acceso a consola).
• Bonificación: que tengan características base de un IDE (acceso a la consola, compilación y ejecución de scripts interpretados).
• Bonificación: acceso a servidores FTP y SFTP.

Ejemplo 1: Albatross TE. Es un buen editor, con muchas herramientas –incluido acceso a la consola y posibilidad de correr scripts shell y Python e incluso reconoce scripts make. Desgraciadamente no es muy personalizable y no le dio tiempo al autor para hacer la ayuda.

Ejemplo 2: TextWrangler. Muy buen editor altamente configurable y personalizable con herramientas muy útiles y avanzadas. Aparte de poder interactuar con AppleScript tiene una ayuda y manual muy completos.

Existen muchos otros editores como Smultron (disponible como app de pago en la Mac App Store), Komodo Edit (muy avanzado y open source, también existe el Komodo IDE), Textmate, Fraise, Sublimetext 2...

Quizá ya hayan salido actualizaciones u otros nuevos, si conocen de algún otro, pasen la información, no sean envidiosos.

Nota: También la app de sistema Notes se puede usar como editor de texto, pero es muy trabajoso y no recomendable.

5619.45

Programación en la Mac: los editores básicos.

La Macintosh y su sistema operativo macOS X (la X en un número diez romano, no debe pronunciarse "equis" sino "diez": macOS Diez) es un poderoso sistema basado en el sistema operativo Darwin (es un SO tipo UNIX compatible con POSIX que a su vez está basado en NeXTSTEP, Mach,BSD y otros proyectos de software libre. Aunque Darwin fue liberado como un proyecto libre de código abierto, macOS también está formado por componentes y bibliotecas –conocidas como "librerías" en el bajo mundo informático– de código propietario, es decir, bajo licencia de Apple, como Cocoa y Carbon). Como SO tipo Unix, también se puede manejar mediante línea de comandos (la aplicación Terminal sirve para esto, está en Aplicaciones → Utilidades:

Ubicación de la aplicación Terminal para accesar la línea de comando.

Dentro del ambiente de línea de comando ya se tienen instalados y accesibles los editores:

vi:

El editor clásico vi en la terminal.

vim:

El editor vim (vi improved) en la terminal.

emacs:

El editor emacs en la terminal.

Aparte de los filtros y editores clásicos de Unix: ed, cat, ....



5608.22

El peligroso, salvaje e indispensable GOTO

Para Dante,

aunque sea con cerca de

30 años de retraso.

En marzo de 1968, el científico de computación holandés Edsger W. Dijkstra (conocido en occidente como Edgar Dijkstra) publicó el influyente artículo "Go To statement considered harmful" (La instrucción Go To considerada dañina) en el boletín de Comunicaciones de la ACM (Association for Computing Machinery), también conocida como CACM. En este artículo señalaba que el uso creciente del salto incondicional estaba ocasionando que los programas se volvieran ilegibles y muy propensos a errores y reflexionaba y disertaba como el mantener cierta disciplina en la programación permitiría hacer no solamente programas legibles y confiables, sino hacerlos más grandes y propensos a modificarlos en vez de rehacerlos (es decir, hacerlos más flexibles).

Por un lado, esto dio inicio a la disciplina llamada Programación Estructurada donde todo el flujo del programa está basado en bloques bien definidos y que no deben traslaparse ni intereferir entre sí.

Pero esto también ocasionó una gran polémica que, aunque es muy técnica y se ha ido acallando, sigue siendo escabrosa.
Desde el principio muchos programadores protestaron porque la sentencia GO TO era su principal herramienta de control de flujo, no había otra cosa; en 1974 el propio Donald Kunth (matemático considerado el mayor experto en algoritmos computacionales y profesor emérito en Stanford) argüía que a veces el uso del GO TO mejoraba la eficiencia de ejecución, de forma era mejor alternativa que el detrimento en legibilidad; en 1978 los diseñadores del lenguaje C, Brian Kernighan y Dennis Ritchie dijeron que "se podía abusar infinitamente del GO TO", pero de todas maneras lo incluyeron en las especificaciones de C.
El también científico de la computación, el suizo Niklaus Wirth, jefe del equipo de diseño de los lenguajes académicos Euler, Algol W, Pascal, Modula, Modula-2 y Oberon (que por cierto era el editor del CACM cuando se publicó la carta de Dijkstra), diseñó los lenguajes para impulsar la disciplina del estructuralismo en la programación, aunque incluyó el GO TO por si acaso. Esto dio origen a una de las preguntas más peliagudas y difíciles que influyen aun ahora en el diseño de lenguajes modernos: ¿las reglas en la sintaxis del lenguaje usado fomentan la buena programación?

El lenguaje JAVA, por ejemplo, tiene reservada la instrucción goto aunque no la usa. Esto es principalmente porque en los lenguajes modernos se usa pero con formatos muy específicos y con nombres diferentes: son la sentencias exit, continue, break y exception (o try-catch); esto es, hay que ver su uso, es equivalente a la función que desempeñaba el goto:

exit. Salida incondicional de un programa.
continue. Salta incondicionalmente a la siguiente iteración en un ciclo.
break. Sale incondicionalmente de un ciclo.
exception (o try-catch). Esta es la instrucción menos parecida al GO TO, aparentemente, pero si uno analiza su funcionamiento, su objetivo es casi el mismo: cuando se ejecutan algunas sentencias y operaciones ocasionan errores (por ejemplo, en una operación cuando se intenta dividir ente cero o cuando se le pide a la máquina que lea un número, pero la entrada contiene letras o símbolos no numéricos) y en este caso, se ejecuta la sentencia exception (o la parte equivalente, catch) que sirve como etiqueta o punto de entrada para ejecutar una subrutina o un bloque para manejar el error (recuperarse o al menos morir graciosamente). Esto es el equivalente a una sentencia GO TO condicionada y la ejecución de un bloque etiquetado:

if [ocurrió un error] goto excepcion
excepcion:
{ ....
   líneas de código para manejar el error
   ....
   ....
}

En resumen:

• La sentencia GO TO no es mala per se, solamente cuando se usa sin control y en exceso es cuando es dañina.
• La sentencia GO TO ya amaestrada se usa actualmente para manejo de excepciones, por ejemplo, mediante sentencias ejecutables ya más evolucionadas.
• La sentencia GO TO se puede usar cuando el uso de otras sentencias o estructuras de control puedan conducir a un flujo complejo del programa (nota. Cuidado en este caso, si pasa esto, puede ser indicador de que el flujo completo del programa necesite rediseñarse, si nos gana la flojera, puede pasarnos lo mismo que al monito de la historieta del principio del post: en vez de un bug horriblito, le salió un velocirraptor salvaje).

5582.30

IAs al rescate (o no le tengo miedo a las IAs, es solamente precaución).

Una de las tendencias tecno-sociales en este principio de siglo es el miedo a las Inteligencias Artificiales (IAs en español, AIs en inglés). Miedos que van desde la mítica y paranoica singularidad (las IAs se van a volver tan poderosas y capaces que van a igualar y a superar al ser humano [ver el post del blog hermano “El blog de GodMakers: De singularidades muy singulares]) hasta los muy reales temores de que muchos trabajos que antes realizaban los humanos, ahora ya van a ser hechos por las IAs. Este miedo existe desde el s. XVIII (centuria de 1700) en los albores de la revolución industrial, cuando se empezaron a usar telares mecánicos operados a pedales y maquinas de vapor para perforar y operar pozos de agua y, sobre todo, para servir de motor en lanchas y barcos. En el s.XIX (centuria de 1800), de hecho, surgió un movimiento llamado Ludismo que defendía las ideas antimáquinas y pro-trabajo humano. Pero existe el pequeño detalle que matemáticamente se puede demostrar que todas las protestas luditas son inútiles e incluso dañan la economía. Tal como lo pregonaba el buen Dr. A (Isaac Asimov), el progreso tecnológico no se puede parar, es como pedirle al cuerpo humano que consuma menos oxígeno mientras tratamos de correr más rápido (en mi otro blog, “Entre la Maldición y las Estrellas” tengo una serie de ensayos que tratan sobre este tema (Futuro I, II, III y IV). No se puede para el avance de la automatización, no se van a poder parar la implantación de agentes IA para la ciberseguridad industrial, tal como lo muestra este post. El avance tecnológico y su interacción con los seres humanos hace que la tecnología sea tan complicada que solamente puede ser manejada y mantenida de forma eficiente por las IAs (por ejemplo, las tecnologías de la nube y los ciberataques de parte de hackers y terroristas hacen que este punto se vuelva tan complejo, que su desarrollo y mantenimiento de parte de las IAs es casi obligatorio). Por supuesto que los beneficios económicos van a ser enormes (se calcula un impacto de 1.1 trillones de dólares en la economía global). Socialmente, se han hecho a un lado los temores y se han hecho estudios tanto a favor como en contra del desplazamiento laboral de las IAs, tal como lo muestra este artículo. No son noticias ni buenas ni malas, lo único que se muestra es información que muestra tendencias que tienen más de 200 años. Quizá lo que se necesite sea un cambio de modelo económico en vez de estarle poniendo parches.


5516.64