Por qué los desarrolladores deberían utilizar Mac OS X y una breve historia de OS X

Tinyfool escribe rápidamente e inmediatamente escribió un largo artículo "¿Por qué creo que todo programador debería usar Mac OS X?" 》, escribo muy lentamente y hoy terminé de escribirlos todos. El principal punto de partida de su artículo son las ventajas de la plataforma Mac como plataforma de desarrollo de destino, mientras que el principal punto de partida de mi artículo son las ventajas de Mac OS como herramienta de desarrollo. Herramientas útiles para desarrolladores Para los desarrolladores, el mayor uso de todas las herramientas de desarrollo es maximizar la productividad y la creatividad de los desarrolladores. Hoy en día, utilizar una GUI (interfaz gráfica) es una excelente manera de aumentar la productividad. Aunque es cierto que aquellos desarrolladores de UNIX de la generación anterior no necesitaban GUI. Una pantalla, un teclado, un editor En los callejones, hay muchos piratas informáticos que son insoportables y no cambian su alegría. Sin embargo, han pasado más de 20 años y ahora el entorno de desarrollo ha experimentado cambios tremendos. Por ejemplo, en comparación con el entorno basado en texto utilizado por los programadores en ese entonces, los documentos con formato enriquecido bajo la GUI son más intuitivos y la experiencia de lectura es mejor, incluso si no necesitan desarrollar ningún programa GUI en el trabajo, los desarrolladores modernos lo harán; utilice la GUI para completar imágenes de páginas web y lectura de documentos, etc. Por lo tanto, incluso los desarrolladores de línea de comandos más tradicionales pueden aprovechar la GUI. Por ejemplo, los mejores programas de terminal ahora se simulan en X. Debido a la aparición de estos terminales simulados, se pueden implementar algunas funciones de visualización complejas en estos terminales, como la visualización Unicode (rxvt-unicode), etc. Para los desarrolladores, tener un conjunto de herramientas de desarrollo muy fáciles de usar que puedan maximizar la productividad es un sueño en la vida. Entonces, ¿de dónde viene este conjunto de herramientas de desarrollo? En términos generales, estas herramientas provienen de tres aspectos: 1. Proporcionadas por sistemas y software de aplicación única; 2. Mediante el uso conjunto de varias aplicaciones de software; 3. Personalizando y cambiando el software de aplicación existente; Estos tres puntos son muy familiares para los desarrolladores de UNIX. No son más que escribir scripts y pasar por canalizaciones. Por lo tanto, en la era anterior a la GUI, esta filosofía era muy popular. Todos los desarrolladores saben que necesitan instalar un analizador de scripts, escribir algunos scripts, configurar algunos entornos, etc., para poder transformar el sistema UNIX que acaba de abandonar. fábrica en uno para su propio sistema Handy. Básicamente, cualquiera que haya utilizado sistemas UNIX/Linux durante muchos años tendrá una variedad de scripts "privados" en sus máquinas. Sin estos guiones, su eficiencia se reducirá considerablemente. La pérdida de la tradición en la era de las GUI En la década de 1980 llegó la era de las GUI y la era de la popularización de las computadoras personales. A partir de ahí, las computadoras se convirtieron en computadoras personales y, por primera vez en la historia, las computadoras no fueron diseñadas para desarrolladores sino para usuarios comunes y corrientes. Las necesidades de los usuarios comunes son resolver problemas prácticos uno por uno. La solución proporcionada por la industria del software es proporcionar a los usuarios software de aplicación uno por uno, en lugar de permitir que los usuarios programen y escriban scripts línea por línea. Creó instantáneamente una enorme industria de software. Una consecuencia indirecta de esto es que para los usuarios comunes, la única forma de convertir una computadora en una "computadora personal" que pueda ayudarlos a completar tareas es instalar constantemente varias aplicaciones de software una encima de otra. Podemos ilustrar este patrón de uso con un ejemplo sencillo. Todos sabemos que una regla general para instalar sistemas Windows es dividir el sistema operativo y las aplicaciones en dos unidades lógicas, una en la unidad C y otra en la unidad D. Este principio empírico de partición de disco es conocido no sólo por los propietarios de cibercafés, sino también por aquellas compañeras de mi universidad que sólo pueden hacer clic con el mouse. ¿Por qué ocurre este maravilloso fenómeno? De hecho, esto está determinado por los patrones de uso típicos de los usuarios del sistema Windows.

En un sistema Windows, las aplicaciones y los documentos son la clave, y el sistema operativo es simplemente algo que se puede reinstalar en cualquier momento, por lo que es mejor separar los dos sin que se afecten entre sí. Bajo la guía de este modelo de uso, reinstalar el disco en el sistema Windows tiene un costo muy bajo, siempre y cuando no se pierdan los documentos y aplicaciones. Este hábito de uso ha desperdiciado el buen tiempo de muchos geeks reinstalando sistemas para otros, y ha dado lugar a tantos matrimonios maravillosos :). En resumen, en la era de la GUI, para resolver un problema, instale una aplicación. En cuanto a la comunicación entre aplicaciones, el control de aplicaciones utilizando métodos que no son el teclado y el mouse, etc., ya no son temas a considerar. Las personas con tales necesidades se han vuelto no convencionales, por lo que los sistemas operativos convencionales ni el software ni el sistema operativo convencional. El software de aplicación le permitirá hacer esto. El sistema operativo bloquea todos los demás caminos y le dice claramente que si desea una determinada función, salga y compre software. La iluminación de Smalltalk De hecho, la era de las GUI no debería haber sido así. Todos sabemos que la GUI fue creada originalmente por Alan Kay y su equipo en Xerox para investigaciones científicas. Bill Gates y Steve Jobs fueron a Xerox y "copiaron" parte de ella, por lo que había ventanas y botones por todas partes. Todos han visto la interfaz gráfica y la forma orientada a objetos. Han visto que la interfaz gráfica consiste en colocar botones, iconos y otros objetos, y luego hacer clic y arrastrar con el mouse y otras cosas superficiales. Debido a que todas las interfaces GUI comienzan desde interfaces de texto, todos los programas GUI son en realidad paquetes de los programas ejecutables originales. La aparición del lenguaje C también es muy conveniente. C está empaquetado en un lenguaje orientado a objetos. C se adapta muy convenientemente a la tendencia de convertir programas ejecutables en GUI y se ha convertido en el lenguaje de desarrollo principal en la era de las GUI. . En la superficie, siempre que ejecute estos programas ejecutables, puede ver la interfaz gráfica y operarlos con clics del mouse. Sin embargo, la capa inferior de estas cosas es un programa ejecutable compilado en el entorno de ejecución y el objeto originales de Smalltalk. Todos los contenedores han desaparecido. Todos los programas de interfaz gráfica todavía se ejecutan directamente en la CPU de la computadora en lugar de un contenedor virtual orientado a objetos. Y este contenedor orientado a objetos (también llamado "tiempo de ejecución" o "entorno de ejecución") es el dios de Smalltalk. En pocas palabras, Smalltalk en sí tiene un tiempo de ejecución orientado a objetos, por lo que incluso cuando se ejecuta, todos los objetos que contiene aún pueden estar interconectados. Los programas escritos en C, excepto que están orientados a objetos antes de la compilación, una vez compilados, se convierten en código de máquina y ya no tienen nada que ver con objetos, por lo que no es necesario inspeccionarlos e inspeccionarlos dinámicamente en tiempo de ejecución. objetos del programa. En resumen, debido a limitaciones históricas, estas plataformas GUI han evolucionado gradualmente, por lo que ninguna plataforma ha considerado el problema de la comunicación de objetos con tanto cuidado como Smalltalk. Además, como dijimos anteriormente, el único método para expandir el sistema es introducir nuevas aplicaciones. software, y no hay necesidad de interconexión en sí, por lo que este método de implementación de abandonar el tiempo de ejecución y evitar que los objetos sean controlados por programas externos no es malo. Pero los desarrolladores no son usuarios comunes y corrientes: todavía tienen que transformar las computadoras en sus propias herramientas. Cuando las herramientas existentes no pueden resolver el problema, puede reinventar la rueda usted mismo, reutilizar algunas herramientas existentes o reconfigurarlas según sus propias necesidades. Por lo tanto, a diferencia de los usuarios comunes, los desarrolladores necesitan la capacidad de configuración de estas GUI y la interconexión entre estos programas GUI. En jerga, el primer problema se relaciona con la programación de aplicaciones GUI y el segundo problema se relaciona con la comunicación entre procesos entre programas GUI. Estas dos preguntas son simples de decir, pero ambas involucran cuestiones fundamentales de diseño del sistema GUI.

La historia hizo una pequeña broma aquí, dándole a Mac OS X esta única oportunidad. Otros sistemas operativos, por una razón u otra, no tienen buenas soluciones a estos dos problemas. Para la comunicación entre procesos, la solución de Apple tiene dos flores, una a cada lado. Primero hablemos del tema de la comunicación entre procesos de los programas GUI. La llamada comunicación entre procesos (IPC) es el intercambio de información entre dos programas. Todos sabemos que una de las características poderosas de *nix son las tuberías. Las tuberías son el método de comunicación entre procesos de *nix más simple, más barato y más utilizado. En la era de la GUI, los mecanismos IPC más utilizados implementaban operaciones de arrastrar y soltar con el portapapeles y el mouse. Aunque estas dos operaciones son muy intuitivas, requieren operación humana. Sin humanos, el programa no puede completar automáticamente la comunicación entre procesos. Para mejorar la eficiencia del trabajo, es necesario permitir que las computadoras completen estas tareas sin intervención humana. Para poder automatizar estas tareas, el sistema operativo no puede simplemente dibujar la ventana y todo está bien, debe saber qué programas se están ejecutando, qué programa en ejecución puede enviar mensajes a qué programa, etc., por ejemplo, si queremos leer automáticamente Seleccione una palabra en la computadora y envíela al programa de diccionario para buscar el significado. La computadora necesita saber que el programa de diccionario puede aceptar una cadena cuando se está ejecutando, pero no puede aceptar imágenes. Si abstraemos el programa de diccionario en un objeto que puede proporcionar servicios de "búsqueda de diccionario", no hay duda de que si desea enviar caracteres al programa de diccionario, primero debe saber qué puede aceptar el programa de diccionario y cómo enviar la palabra. al diccionario, etc. Toda esta información debe estar alojada en el sistema operativo (es imposible que todas las aplicaciones recuerden el diccionario. Este programa puede aceptar cadenas pero no imágenes, por lo que cada aplicación debe recordar todas las demás aplicaciones posibles. Información del programa, este es un nivel cuadrado relación, lo que requiere que los desarrolladores tengan en cuenta todos los demás programas al desarrollar un programa, lo cual obviamente no es realista). En jerga, debe haber un entorno operativo de gestión unificado para gestionar los problemas de comunicación entre estos programas. Como dijimos anteriormente, la genialidad de Smalltalk radica en un tiempo de ejecución unificado orientado a objetos que permite que todas las aplicaciones se interconecten. Sin embargo, el proceso de evolución de los programas GUI en todas las plataformas no ha seguido este camino, solo imita la apariencia; incluso si algunas plataformas quieren interconectarse, no lo han hecho tan a fondo (como OLE, COM, etc. de Microsoft). Es algo bueno y siempre brillará. Pero si desea que el nuevo sistema operativo adopte plenamente esta cosa buena, y si desea que un sistema adopte un entorno operativo unificado desde la capa inferior hasta la superior, debe desechar una gran cantidad de bagaje histórico. Deshacerse de este bagaje histórico no es fácil para ningún sistema operativo. Si volvemos a esos días, definitivamente imaginaremos que sería fantástico si hubiera un dios que pudiera construir un sistema GUI limpio y ordenado desde cero sin ningún bagaje histórico, independientemente del mercado o la plataforma existente. La historia es un gran drama, y ​​una persona realmente estaba dispuesta a lograrlo. Esta persona fue Steve Jobs. En 1985, Jobs fue expulsado de Apple y fundó Next, una empresa dedicada a fabricar sistemas informáticos GUI de alta calidad. La historia le dio a Jobs la oportunidad de hacerlo todo desde cero. Esta vez, el profesor Qiao y los desarrolladores de Next se dieron cuenta de que simplemente copiar la forma de Smalltalk no era suficiente. Tenían que tomar su espíritu y rediseñar la comunicación entre procesos y el sistema GUI desde cero. A nivel de kernel utilizaron Mach, un microkernel diseñado para BSD.

Este kernel del sistema operativo fue diseñado para reemplazar el obsoleto kernel de UNIX. Una de las filosofías de diseño centrales es rediseñar la comunicación entre procesos; aunque los sistemas operativos basados ​​en microkernels ya no son una tendencia (Linus y Tanenbaum tuvieron una pelea sobre esto (). una arquitectura bien conocida en el campo), pero en comparación con los kernels de los sistemas UNIX en ese momento (Linux aún no había aparecido en ese momento, y los kernels de UNIX solo tenían BSD, Bell, SUN, etc.), se consideró Mach un punto de partida elevado. Sobre este núcleo, los ingenieros de Next comenzaron a construir un sistema básico orientado a objetos. Este sistema ya tenía un modelo en Smalltalk, por lo que estos ingenieros utilizaron Smalltalk como modelo y primero diseñaron un lenguaje basado en C, a saber, Objective C, que copió la sintaxis clásica [Mensaje de objeto: parámetro] de Smalltalk. (Personalmente no me gusta el lenguaje Objective C. Smalltalk es un lenguaje puramente orientado a objetos y de tipado dinámico. La siguiente empresa tuvo todas las oportunidades para usar el lenguaje Smalltalk en aquel entonces. Si se hubiera usado Smalltalk, el marco actual de Cocoa sería incluso más hermoso y el código sería más sofisticado; usando Objective C, un lenguaje de creación propia, no sé si es por consideraciones de patentes. De todos modos, todas las innovaciones en Objective C en los últimos 20 años. poco a poco se parece más a Smalltalk (Java y Ruby también han seguido evolucionando en los últimos años). Con el kernel y el lenguaje, Next ha creado un entorno de ejecución y una biblioteca de clases puramente orientados a objetos (similar a la idea de las bibliotecas de clases unificadas en Java y .Net, pero más de diez años por delante de su tiempo). de las bibliotecas de clases se llamaba NextStep en ese momento, por lo que todos los nombres de clases tenían prefijos NS delante, lo cual era extremadamente feo. Es una lástima que esta biblioteca de clases que se adelantó a su tiempo haya llegado a su fin. Se dice que Smalltalk se adelantó a su tiempo en 20 años. Entonces, a mediados de la década de 1990, los programadores solo recordaban lo bueno que era Smalltalk en ese entonces. Y aparecieron Java, Ruby, etc. inspirados en el lenguaje Smalltalk. Aunque el Sr. Qiao estaba 5 años detrás de Smalltalk, estaba entre 5 y 10 años por delante de la industria. Por lo tanto, en 1995, Windows 95 se estaba vendiendo como loco, pero NextStep del Sr. Qiao permaneció en silencio, por lo que solo pudo reempaquetar esta biblioteca de clases como. una clase web. La biblioteca vende, es decir, WebObjects. Esto no fue intencional y el negocio fue bueno, porque el desarrollo web en ese momento ya había sufrido por no tener un entorno operativo unificado (esta es también la razón por la que Java se hizo popular en el futuro). Decimos que el oro siempre brillará, pero la premisa es que (1) Next esperará unos años más para que la industria entre en razón y se dé cuenta de sus beneficios, y (2) obtenga soporte de un sistema operativo convencional y lo reemplace por completo. la capa subyacente. Las cosas del profesor Cheng Qiao. El maestro Qiao también conocía estas dos condiciones, por lo que aceleró el ritmo de cooperación con SUN y quiso instalar este sistema en las estaciones de trabajo de SUN. Sin embargo, el propio SUN tiene una tecnología subyacente sólida y durante ese tiempo también estaba promoviendo Java, por lo que, de hecho, el profesor Qiao tiene pocas posibilidades de ganar en el camino de SUN. Además, el propio SUN tiene una tecnología de núcleo muy sólida, por lo que debe desmembrar NextStep. y reescribir el kernel. Si no juegas con SUN, en primer lugar, será un problema para Next poder sobrevivir otros cinco años. En segundo lugar, casi todas las empresas que fabrican computadoras personales han desertado a Microsoft y otras. Las empresas que fabrican estaciones de trabajo tienen sus propias tecnologías subyacentes sólidas. Es imposible utilizar los dispositivos del profesor Qiao, por lo que parece que el profesor Qiao y su Yangchun Baixue tienen un mal futuro.

Pero siempre hay un camino, y mirando el mercado en ese momento, solo había una empresa que no desertó a Microsoft, no tenía una tecnología subyacente sólida y tenía algunas conexiones con el Sr. Qiao. La historia es un drama. Esta empresa acaba de echar al Sr. Qiao Apple. A mediados de la década de 1990, Apple estaba pasando por un momento difícil. El mercado de las computadoras personales fue derrotado por la Alianza Wintel. Su desempeño en los mercados emergentes también fue un desastre. Los inversores también estaban confundidos, quien había expulsado al Sr. Qiao. También fue expulsado, y luego el Sr. Qiao fue expulsado. La compañía la volvió a comprar y reintegró al Sr. Qiao como responsable de revivir a Apple. Por lo tanto, las dos condiciones que mencionamos anteriormente se cumplieron repentinamente: en primer lugar, ahora es el jefe, por lo que puede derrocar por completo el sistema original de Apple y comenzar de nuevo con el suyo propio. En segundo lugar, resulta que los ingenieros de la próxima empresa no; No se preocupen por perder sus trabajos. Apple ahora es responsable de pagar los salarios. Por lo tanto, estas personas pueden simplemente comenzar a transformar el sistema de Apple. El trabajo principal es reemplazar el antiguo sistema de Apple con el nuevo sistema que trajeron y dejar que el nuevo sistema sea gráfico. La interfaz mantiene el mismo estilo que el sistema anterior. Este trabajo se completó desde 1995, cuando se adquirió Next, hasta aproximadamente 2001. Durante estos 6 años, Teacher Qiao también hizo que Apple volviera a ser rentable. sistema operativo mac Este sistema de tiempo de ejecución y biblioteca de clases, Mac OS X lo llama Cocoa. De hecho, Mac OS X no era muy bueno cuando apareció por primera vez. Sin embargo, basándose en este sistema subyacente bien diseñado, el ciclo de desarrollo iterativo de Mac OS (en solo 8 años, Mac OS X ha lanzado 7 versiones principales). Aunque parece que Mac OS sólo progresa en números de versiones menores de 10.0 a 10.6, de hecho cada vez es una versión importante, lo que equivale aproximadamente a una actualización de Windows 95 a Windows 98 o de Windows 2000 a Windows XP. Un lanzamiento de este tipo no cambia el número de versión principal. Por un lado, se basa en consideraciones del mercado. Por otro lado, muestra que la capa inferior de OS X ya se encuentra en un estado relativamente estable. Hay muchos programadores de Windows que confían en .Net. Sí, .Net es de hecho un marco muy bueno, pero imagine que Apple tenía un tiempo de ejecución unificado en 1995 y que todos los programas se han desarrollado en este marco unificado durante tantos años. Basado en la experiencia acumulada en la plataforma Mac OS X. Cabe decir que la comunidad Cocoa es más madura que la comunidad .Net. Un sistema con secuencias de comandos de aplicaciones y comunicación entre procesos por sí solo no puede considerarse un sistema GUI completamente maduro, porque la comunicación entre procesos aún es de nivel relativamente bajo y el software de aplicación en la GUI aparece sin cesar, y es imposible solucionar cualquier problema. para ir al proceso subyacente de la solución de intercomunicación, por lo tanto, si desea que el sistema GUI evolucione a un nivel que sea fácil de usar y personalizar, debe abrir el control de script del programa GUI. Sólo cuando el programa GUI se puede controlar externamente se puede lograr realmente el efecto de utilizar el sistema GUI. De hecho, una vez que exista un tiempo de ejecución unificado, siempre que la interfaz de script esté diseñada de manera uniforme al desarrollar software de aplicación, no debería ser difícil usar scripts para controlar los programas GUI. Por ejemplo, las suites de la serie Office de Microsoft se pueden controlar completamente mediante VBScript. Desafortunadamente, ningún sistema puede lograr un control total del sistema. Para lograr un control de todo el sistema, el sistema no solo debe poder proporcionar soporte subyacente, sino que, lo que es más importante, debe poder convencer a todos los desarrolladores o permitir que todos los desarrolladores desarrollen el buen hábito de abrir interfaces de script.

Técnicamente hablando, esto no es un gran problema, siempre que los desarrolladores sigan un protocolo de comunicación de script unificado e implementen interfaces específicas. Sin embargo, si hay demasiadas formas de desarrollar GUI en una plataforma, los desarrolladores solo pueden elegir lo que quieran. Es imposible unificar tales estándares. Por ejemplo, KDE y Gnome en Linux tienen sus propios sistemas de scripting, pero algunos desarrolladores usan KDE, otros usan Gnome y otros simplemente no usan ninguno de los dos. Esto hace imposible tener una interfaz consistente. Una plataforma quiere tener una interfaz de control de script consistente a menos que (1). Solo haya un método de desarrollo de GUI en esta plataforma, que ha sido el mismo desde la antigüedad, lo que se produce solo puede ser una interfaz estándar; La mayoría del software de aplicación principal en esta plataforma ha implementado esta interfaz de script. Debido a la atracción de estos programas, otros programas GUI quieren integrarse en el círculo de software de aplicación existente en esta plataforma para comunicarse entre sí. debe ser implementado. En el año 2000, sólo había una empresa que podía cumplir ambos requisitos y era Apple. Microsoft ha logrado parcialmente estos dos, básicamente usando VBA para unificar el control de Office. Sin embargo, fuera de Office, el modelo de objetos OLE de Microsoft casi no tiene uso y VBA, que está estrechamente vinculado a él, naturalmente se ignora. Sin embargo, según algunos amigos que trabajan en la industria financiera, VBA puede mejorar enormemente la productividad de M$ Office. Las secuencias de comandos GUI no son un éxito de la noche a la mañana, especialmente cuando decimos que necesitamos crear una interfaz de secuencias de comandos unificada que pueda tener en cuenta las necesidades de varios programas. Esto no se puede hacer en uno o dos años. Y el diseño solo después de hacer concesiones podremos converger hacia un sistema relativamente estable y maduro. Apple, sorprendentemente, tuvo experiencia en esta área hace más de diez años. A finales de la década de 1980, había un software en la computadora Apple que estaba muy adelantado a su tiempo, llamado Hypercard. He jugado con este software en la generación anterior de Apple. La idea específica es que puedes almacenar "tarjetas" una por una, en estas tarjetas puedes colocar sonidos multimedia, imágenes, texto y otros objetos. como las páginas web actuales. Así es, la única diferencia es que todas estas tarjetas existen de forma nativa. Antes de que existiera un software como Powerpoint, el software Hypercard se podía utilizar para crear material didáctico, presentaciones de diapositivas, etc. Era una herramienta extremadamente poderosa. Para permitir a los usuarios personalizar esta tarjeta, el programa proporciona un sistema de programación muy potente llamado Hypertalk. Debido a que este lenguaje de programación es para gente común, no para programadores, sentirá que no es programación en absoluto, sino escritura en inglés. Aunque este conjunto de cosas se aprende esencialmente de Smalltalk, programar con gramática inglesa es de hecho una idea completamente nueva. Apple ha desarrollado este lenguaje de programación para la gente común y lo reescribió en un método más cercano al lenguaje y la documentación naturales, imitando a Hypertalk. system, lanzó un lenguaje de control de scripts entre sistemas llamado Applescript. Este lenguaje no es diferente del lenguaje natural. Por ejemplo, obtener el tamaño de la ventana ya no es window.getSize() pero obtener el tamaño de la ventana ya no es print(paragraph[22].getWordByIndex. [0]) En su lugar, imprima la primera palabra del párrafo 22. Además, también puede escribir en francés y japonés. A finales de los 80 y principios de los 90, Apple se había visto básicamente acorralada por los PC. Sólo la industria editorial, la industria del diseño y otras industrias profesionales seguían resistiendo gracias a sus aplicaciones de software y capacidades de procesamiento de gráficos Mac.

Los usuarios de ambas industrias necesitan un control GUI automatizado, pero la programación no es muy buena. Por lo tanto, los desarrolladores de este software de aplicación también se unen activamente al banner de Applescript. Antes de que el Sr. Qiao se uniera en la década de 1990, Apple escribía todo su Finder, y QuarkXPress y Filemaker en la industria editorial también estaban completamente escritos. Después de que el Sr. Qiao llegó a Apple, basándose en la nueva tecnología de Cocoa, Apple lanzó Mac OS X en uno. Se lanzaron en Internet Safari, iTunes, iPhotos y otros programas, y todos estaban programados. Apple ha vuelto a aprovechar esta oportunidad histórica que es esquiva para otras empresas y la ha metido en Mac OS X. Ahora, todas las herramientas desarrolladas por terceros, como Firefox y Adium, en realidad no fueron desarrolladas originalmente por Apple ni tienen fuertes raíces en Apple. Pero Firefox necesita leer los marcadores de Safari, jaja, luego usa Applescript, por lo que Firefox también lo obliga. scripting (algo que no existe en otras plataformas). Adium es lo mismo. Este software de chat quiere tratar la canción que se reproduce en iTunes como un mensaje de estado, por lo que también está programado, mientras que el producto correspondiente en Linux, pidgin, no lo está. Por lo tanto, la plataforma Apple se ha convertido en una inercia. Si no quieres escribir un guión, no te dejaré jugar. Veamos si todavía quieres escribir un guión. Conclusión Todos sabemos que la filosofía principal de la era UNIX es proporcionar a los desarrolladores un conjunto de herramientas pequeñas y exquisitas que puedan usarse en cualquier combinación, las llamadas herramientas de software, y luego permitir a los desarrolladores crear sus propias herramientas basadas en ellas. Construye tu propia navaja suiza. El propósito del sistema operativo utilizado por los desarrolladores es proporcionar dicho conjunto de herramientas de desarrollo o proporcionar una plataforma conveniente para que dichas herramientas de desarrollo las hagan posibles. Si UNIX es un sistema operativo en la era de la línea de comandos que es fácil de transformar en "su propio sistema operativo", Mac OS X es un sistema operativo de ese tipo en la era de la GUI. Incluso desde la perspectiva del software de aplicación, Mac OS Apéndice A: Hábitos de uso relativamente correctos de Mac OS X 0. Asegúrese de instalar Quicksilver o utilizar "Servicios"; de lo contrario, utilizará Apple como Windows. 1. En las computadoras Apple, gracias a servicios y herramientas como Quicksilver, se puede evitar copiar y pegar entre el 90% de los programas. etc. En los últimos años, estos sistemas finalmente han comenzado a gestionar de manera uniforme un entorno operativo orientado a objetos. Sin embargo, ambos sistemas están escritos en C, por lo que se necesita mucho esfuerzo para tener información de tiempo de ejecución, lo cual es un gran desvío. Si estos dos sistemas usan lenguajes de tiempo de ejecución como Smalltalk desde el principio, al menos ahora debería haberlos. ser un marco que pueda competir con Cocoa. En segundo lugar, en los últimos años, X también se ha dado cuenta de las deficiencias del control mediante scripts, por lo que Redhat, un desarrollador de escritorio, propuso el estándar DBus hace unos años. Desafortunadamente, no todos los programas han abierto la interfaz Dbus, por lo que, en comparación con Apple, todavía queda un largo camino por recorrer.