En esta segunda parte de la entrevista, el autor de Pepper se adentra en las motivaciones que le impulsaron a hacer su programa multiplataforma, llevándolo también a Windows y Linux, el perfil de usuario de ambos sistemas operativos y cómo es el entorno de trabajo. También analiza los puntos fuertes y débiles de los dos editores profesionales existentes para Mac OS X, la importancia de la automatización de acciones en los programas, y hacia dónde encamina sus pasos.
Una visión realista del presente de muchos desarrolladores y pequeñas empresas que intentar vivir de su trabajo en un entorno de grandes programas y precios astronómicos.
Portando a Windows y a Linux
JG: Tengo que admitir que me sorprendió su decisión de portar Pepper 4.0 a Windows. Había esperado que Pepper 4 fuera sólo para Mac (y posiblemente sólo para Mac OS X) y que sus esfuerzos habrían sido para las nuevas características.
MH: Confiaba encontrar nuevas formas de ingresos, que más plataformas generarían más dinero. ¿Con qué frecuencia oye a los usuarios de BBEdit hablar sobre lo maravillosa que sería la vida si pudieran usar BBEdit en Windows? Pensé que había mercado ahí.
JG: La gente pregunta por una versión de BBEdit para Windows todo el tiempo – esa es una petición muy frecuente.
MH: Eso pensaba yo.
JG: Pero lo que esa gente no entiende es que mucho de lo que hace especial a BBEdit es específico de Mac- como su robusto soporte para AppleScript y eventos Apple. Y también, que no hay un compilador mágico que te permita pulsar un interruptor y generar un programa para Windows a partir del código fuente para Macintosh. Las API son diferentes para todo, incluyendo todas las pequeñas cosas como arrastrar-y-soltar. Debería ser relativamente sencillo crear un programa muy básico y genérico multiplataforma, pero es muy difícil hacer eso para programas comerciales potentes. Y creo que por eso sólo lo hacen las compañías muy grandes.
MH: Sé exactamente a lo que se refiere.
JG: Las grandes compañías como Adobe y Macromedia han portado con éxito productos de software sólo para Mac a Windows, pero no puedo pensar en algún pequeño desarrollador de programas de libre distribución que lo haya hecho también.
MH: Ni yo tampoco. 🙂
JG: ¿Logró triunfar Pepper 4 en Windows?
MH: Relativamente, si. No conseguí demasiada atención en el mundo Windows, es difícil. Tucows rechazó listar Pepper, por ejemplo. Pero dados los hechos, el número de ventas no fue decepcionante.
JG: Para alguien que no haya pasado mucho tiempo con ordenadores modernos, Windows y el Mac deben parecerle algo muy similar – ambos usan ventanas, iconos, menús y el puntero de ratón. Pero si eres un usuario experimentado, hay grandes diferencias en el diseño de las interfaces de usuario de Windows y de Mac.
Cuando veo capturas de pantalla de otros editores de Windows, como UltraEdit y TextPad, me parecen muy “Windows”: barras de herramientas con pequeños y crípticos iconos, una interfaz tabulada para múltiples ficheros abiertos en una ventana. Pepper, sin embargo, parece y se siente como un programa Mac. Los usuarios de Mac son conocidos por rechazar software importado que aún conserve un aspecto estilo Windows; ¿cree que los usuarios de Windows piensan de la misma forma con programas de aspecto estilo Mac?
MH: Podría ser. Pero nunca me preocupé demasiado de eso. Después de todo, Pepper tampoco era un programa de Mac, ya que comenzó su vida en BeOS. Y también recibí muchas quejas de usuarios de Mac sobre pequeñas cosas, como la barra de herramientas.
JG: ¿Quiere decir la forma en que funciona la barra de herramientas de Pepper – pulsar y mantener para desplegar un menú, pulsar y soltar para obtener el efecto de un botón? También yo pensé que era un poco raro.
MH: Si. Lo copié de Outlook Express, así que no era el primero en usarlo en Mac OS. Es raro al principio, pero muy útil cuando te acostumbras.
Pepper tenía una vista para múltiples ficheros [mostrando múltiples ficheros abiertos en una única ventana], y por supuesto muchos usuarios de Windows lo usaban de ese modo mientras que los usuarios de Mac lo odiaban.
JG: Esto es interesante, pero no sorprendente. Creo que la gestión de ventanas es quizás la mayor diferencia entre Mac y Windows. La interfaz MDI de Windows está tan mal diseñada que la forma mas fácil de trabajar es usando una sola ventana que contenga todos los documentos abiertos. Eso nunca me gustó, y esa es la principal razón de que encuentre Proyect Builder de Mac OS X tan desagradable.
MH: Es algo a lo que te puedes acostumbrar, pero es muy personal. Puedo trabajar con ambos pero prefiero las ventanas separadas. En Win2K y anteriores había otra razón para preferir una única ventana, ya que cada ventana colocaría una marca en la barra de Inicio y eso llevaría rápidamente al desorden. WinXP ha solucionado esto bien (gracias a que se han fijado en BeOS).
Acepto que muchos programas para Windows parecen feos, pero veo que las cosas mejoran en ese lado de la valla. Creo que sería mas fácil para un usuario de Windows comenzar a usar Pepper de lo que seria para un usuario de Mac comenzar a usar UltraEdit.
JG: De acuerdo. También he observado durante años que numerosos programas pasan de Mac a Windows y logran triunfar allí (como la línea completa de productos de Adobe), pero los programas de Windows que se portan al Mac casi siempre fracasan. ¿Recuerda Lotus 1-2-3 para Mac?
MH: Sí, ésa fue la aplicacion para Mac con la vida mas corta que conozco. 🙂
JG: Corel está intentando entrar, pero nunca he encontrado a nadie que use sus programas en Mac.
Creo firmemente que los usuarios de Mac se interesan profundamente por la calidad del aspecto de los programas que usan, especialmente en cosas como ser intuitivo, adecuado y muy bien acabado. La mayor parte de los usuarios de Windows no se preocupan por esas cosas, y sí por el número de características.
MH: Puede ser, pero no todos. Y realmente hay buenos programas en Windows. Estoy usando The Bat! para el correo electrónico ahora mismo y es muy buen programa, similar en el concepto a Mailsmith, pero mucho más potente. La apariencia no es óptima, pero las sensaciones son realmente buenas.
JG: La versión para Linux fue también una gran sorpresa para mí. No puedo pensar en otra aplicación comercial para Mac que haya sido portada a Linux.
MH: Fue fácil portarlo a Linux/X11. Ya que esa plataforma [X11] es neutral en cuanto a SO simplemente fue una cuestión de crear las implementaciones correctas.
JG: En particular para los editores de texto, siempre creí que no había mercado para programas comerciales en Linux. Por una razón, alguien que use Linux o BSD en su ordenador y tenga la necesidad de un buen editor de texto es casi seguro que será un duro e incorregible usuario de Emacs o vi, cualquiera de los dos.En cuanto al resto, hay una predisposición fuertemente arraigada hacia los programas libres, especialmente en el sentido de totalmente libre y gratuito .
¿Esperaba que Pepper tuviera éxito en Linux? ¿Lo tuvo?
MH: Esperaba que con la nueva popularidad de Linux y FreeBSD habría cada vez más usuarios que vinieran de Mac OS o Windows y que disfrutaran usando un editor más cómodo.
Pero estaba equivocado. Vendí tres copias y una de las tres fue un fraude. Aunque hubo miles de descargas.
JG: Vaya, es una desgracia. Pero no puedo decir que esté sorprendido – los únicos programas comerciales para Linux que parecen venderse son de animación y rendering 3D – paquetes que cuestan muchos miles de dólares.
MH: Me temo que ese será el futuro de toda la industria de software. A la larga sólo será posible vender grandes paquetes de software con mucho soporte; al final todas las pequeñas aplicaciones serán de código abierto.
JG: Si tuviera que volver a hacerlo todo otra vez, ¿volvería a hacerlo multiplataforma?
MH: Sí, como dije antes, no me gusta encerrarme. He sido un refugiado de los sistemas operativos la mayor parte de mi vida como programador y estoy contento de tener ese marco de trabajo ahora. Puedo llevar mi editor conmigo allá donde vaya.
Pepper frente BBEdit
JG: ¿Era su meta dedicarle todo su tiempo viviendo de las ventas de Pepper, o era sólo un empeño a tiempo parcial?
MH: Cuando hace diez años empecé a programar aún era mi sueño tener una compañía que hiciera programas de libre distribución y que me permitiera vivir de él. Pero ese sueño ha demostrado ser una ilusión para mi.
Pe fue bastante popular en BeOS pero el mercado era muy pequeño para poder vivir de él. En Mac OS las cosas fueron un poco mejor pero no mucho.
Eso era así, hasta que llegó Mac OS X. Al aparecer Mac OS X 10.0, Pepper entró en el mercado antes que BBEdit, y en dos semanas hice una cantidad espectacular de ventas. Pero cuando BBEdit [para Mac OS X] fue presentado, todo se paró inmediatamente y lo que quedó no fue suficiente para vivir de ello.
JG: Pero sabía antes de que comenzara a trabajar en Pepper 3 que BBEdit era el editor líder para Mac OS. De hecho, muchas de las características de Pepper parecían pensadas respecto a las debilidades de BBEdit 5.1 (que era la versión de BBEdit cuando Pepper desembarcó por primera vez en Mac OS) – mejor soporte para PHP, mejor soporte para configurar el color de sintaxis, selecciones rectangulares, y una biblioteca de expresiones regulares más potente.
BBEdit 6 y 6.5 corrigieron muchos de esos defectos. ¿Cómo cree que se encuentran las actuales versiones de Pepper y BBEdit una frente a otra?
MH: BBEdit tiene muchas características orientadas a los programadores HTML pero técnicamente creo que Pepper es mejor. BBEdit aún usa un apuntador para almacenar texto internamente usando un enfoque de vector con hueco (gap array). Pepper usa un mecanismo de transacción. De todas formas BBEdit aprendió mucho de Pepper y tomó prestadas muchas características y la diferencia no es tan grande como era cuando Pepper apareció. De todas maneras, todavía creo que Pepper es mejor. 🙂
JG: No hay duda de que prefiere Pepper. 🙂 Pero tengo curiosidad por saber qué características cree que BBEdit tomó prestadas de Pepper.
MH: Había muchas, recopilé una lista una vez y la tiré. No me importó demasiado, después de todo comencé en primer lugar escribiendo un clon de BBEdit. Pero fue amargo ver como desaparecía mi ventaja.
JG: ¿Cómo beneficia al usuario el mecanismo de transacción de Pepper?
MH: Tiene la función de Deshacer ilimitado real, hasta cuando se hayan usado plug-ins o Remplazar Todo; y ese Deshacer no usa memoria, sólo espacio en el disco. Y cuando Pepper se cuelga puedes reabrir tu trabajo y mantendrá el historial de deshacer completo de la anterior sesión.
JG: El Deshacer de BBEdit funciona después de Reemplazar todo, y para plug-ins que lo soporten especíicamente. Pero está basado en usar la memoria.
MH: Sé como funciona, hice eso en Pe también. Pero el modelo de transacción es una forma mas fácil de programar. Pude recortar miles de líneas de código después de introducir ese cambio.
Pepper puede abrir ficheros enormes, intente editar un fichero de 650 MB con BBEdit.
JG: Podría hacerlo si tuviera 1 GB de RAM, pero admitámoslo, editar con un modelo basado en memoria se vuelve intratable con ficheros mayores de 500 MB.
Cuando decidió sobre el conjunto de características de Pepper 3.0, ¿cuántas de ellas estaban basadas en crear un editor que soportara la comparación con BBEdit, y cuántas reflejaban sus propios deseos?
MH: Nunca consideré BBEdit hasta ese punto. Estaba más concentrado en conseguir las características de Pe en Mac OS. Pepper 3.0 tenía al menos todo lo que tenía Pe y no mucho más. Creo que Pepper 3.0 ni siquiera podía imprimir.
JG: No hay muchos editores para programación profesional en Mac OS. Aparte de BBEdit y Pepper, solamente están CodeWarrior y Proyect Builder. El editor de CodeWarrior y el de Proyect Builder, de cualquier forma, están claramente diseñados para ser usados como parte de su correspondiente IDE. Y con Pepper discontinuado, eso deja a BBEdit como el único editor dedicado para Mac OS. ¿Cree que hay sitio en el mercado de Mac OS para otro editor profesional especializado?
MH: No, no lo creo.
JG: ¿Fue su meta desde el principio atraer a los usuarios de BBEdit? ¿O en cambio intentó atraer a gente que no le gustaba BBEdit?
MH: 🙂 Creo que quería mostrar a los usuarios de BBEdit que había espacio para progresar. Acabé un poco cansado de la gente que decía que BBEdit era el mejor programa para Mac OS mientras que ante mis ojos no era tan bueno. Quiero decir que, cuando tenía que usar otros editores en BeOS, descubrí muchas nuevas formas de hacer cosas que no podrían hacerse con BBEdit. Bare Bones se estaba volviendo arrogante y yo quería ser el niño gritando que el emperador estaba desnudo.
Pero para responder a su pregunta, estaba dirigido a ambos.
Scripting
JG: Como usuario de BBEdit durante largo tiempo, la falta de soporte de AppleScript en Pepper suponía no tenerlo ni siquiera en cuenta, incluso aunque no hubiera trabajado para Bare Bones Software. Pepper soportaba filtrado básico de texto con Perl y otros lenguajes de shell, pero no tenía un lenguaje macro o posibilidad de automatización interna.
¿Alguna vez consideró añadir a Pepper soporte para AppleScript? ¿Fue ésta una característica frecuentemente solicitada por sus usuarios?
MH: Era una petición frecuente. Nunca me planteé dar soporte a AppleScript pero si pensé hacer Pepper scriptable. Hasta comencé a trabajar en un intérprete y otras necesidades internas. Mi meta era dar con algo comparable a JED [un clon de Emacs] o VIM[un editor en la gama del vi].
JG: ¿Comparable o compatible?
MH: Comprable, por supuesto. Es un camino demasiado peligroso imitar un paquete OSS [Open Source Software – Programas de código abierto] completamente.
JG: Una ventaja de AppleScript es que permite vincular múltiples aplicaciones a la vez. Los lenguajes macro hechos a medida para una aplicación son normalmente sólo útiles dentro de esa aplicación.
MH: Sí, pero AppleScript es sólo para Mac y eso no era una opción válida para Pepper. Y pensé que AppleScript era demasiado lento y útil sólo para tareas muy simples. Quería que mi scriptado manejara internamente mucha de la lógica, liberar a Pepper de todo lo gordo y ponerlo en scripts. Para eso necesitas un motor de scripts más poderoso.
JG: ¿Consideró usar un lenguaje multiplataforma, como sería Perl o Phyton?
MH: Había pensado usar Java.
JG: ¿Tenía más ideas para características principales que no ha tenido tiempo de implementar?
MH: Claro que si, muchas. Como ya dije antes, el scriptado estaba muy arriba en mi lista de cosas a hacer, pero tenía otras ideas también. Mi lista de cosas por hacer tenia unos 200 puntos, desde simples errores estéticos a cosas como el sistema de scripts, folding [ignorar la diferencia de caso para agilizar las búsquedas], generador de makefiles[script para construir un programa], etc.
JG: Sólo tiene otro producto que yo sepa, Sum-It, una hoja de cálculo para Mac. ¿Qué pasó con Sum-It? ¿Tenía algún otro producto?
MH: El último año, después de presentar Pepper 3.6.6 quería hacer otras cosas. Siempre me había gustado Pascal y los lenguajes como Pascal y pensé en intentar escribir un Sum-It en Pascal. Todo fue extraordinariamente bien y en poco tiempo tenía una nueva versión. Pero desafortunadamente los compiladores de Pascal de MW no son suficientemente buenos así que lo pasé a C/C++. Entonces pensé por qué no usar una librería de clases C++, así comencé a trabajar en esa librería que siempre había planeado hacer y al final terminé haciendo Pepper 4.0. 🙂
Quizas terminaré ese Sum-It algún dia.
JG: La vieja versión de Sum-It era compatible con AppleScript, lo que me hace pensar si Pepper también podría.
MH: Nunca tuve tiempo para hacerlo en Pepper. Siempre hay mucho por hacer y muy poco tiempo.
JG: De hecho, esa es la parte mas dura del desarrollo de programas. Si no eliminas buenas características de la lista, nunca terminas el trabajo y no publicas nada.
MH: Exactamente.
Planes Futuros
JG: ¿Qué OS está usando ahora?
MH: Estoy escribiendo esto en un ordenador con Windows 2000. En mi nuevo trabajo instalé Windows XP mientras que todos los demás usan Linux. 🙂
Si me hubiera dicho hace un año que estaría usando Windows ahora mismo, no le habría creído. Pero ahora que uso Win2K/XP diariamente, ha llegado a gustarme. Realmente creo que WinXP es el auténtico sucesor del viejo Mac OS. Es rápido, estable y si eliges los programas bien, es fácil de usar. Personalmente también prefiero esta apariencia Windows frente a Aqua.
JG: ¿Realmente ha terminado con Pepper? ¿Tiene algunos planes para vender el producto, o dejar que otros lo continúen? Siempre que un programa se abandona, la gente pide al desarrollador que publique el código fuente. ¿Es eso algo que esté considerando?
MH: Si alguien se presenta y me ofrece lo suficiente, lo vendería. Pero si eso no pasa, hay grandes posibilidades de que continue trabajando en él por una razón simple, lo estoy usando diariamente. No voy a publicar el código de Pepper por el momento. He publicado otros programas anteriormente como Sum-It y Pe. Sum-It nunca fue popular y tengo curiosidad por ver qué pasará con Pe.
Puede que lo intente otra vez con Pepper, pero si lo hago buscaré un mercado diferente.
JG: Aún así, si usted reintroduce Pepper en el futuro, ¿no sería para Mac?
MH: Si reintrodujera Pepper, sería de una forma completamente diferente. Pienso más en la línea de ese enormemente caro editor de textos para Windows.
JG: ¿SlickEdit?
MH: No, CodeWrite. Cuesta unos US$300 cada licencia.
JG: Nunca oí hablar de él, lo buscaré. SlickEdit cuesta unos $200, creo, y parece tener unos devotos seguidores.
MH: Y no lo comerciaría para consumidores, pero intentaría colocarlo verticalmente como ellos lo llaman. Vender cientos de cacahuetes requiere mucho trabajo y el resultado es: cacahuetes.
JG: No creo que sea una coincidencia que programas de Microsoft, Adobe, Quark y otras muchas compañías de éxito, cuesten muchos cientos de dólares. Muchos de sus competidores, que venden programas por mucho menos dinero, han tenido que cerrar.
MH: Ya. Es una lección que aprendí por las malas. Bien, fue un error, tenía que elegir entre un precio alto o uno bajo. Perdí.
JG: ¿En qué está trabajando ahora? ¿Está desarrollando para Windows?
MH: Ya no desarrollo programas. Soy director de bases de datos en la Universidad de Nijmegen en el departamento de bioinformática. Mi trabajo consiste en mantener las bases de datos funcionando y asegurarme que continuen así y sean accesibles en el futuro. Es un trabajo interesante puesto que tendremos 1.,5 terabytes de datos al final de este año, y esta cantidad se está doblando cada diez meses más o menos.
No se parece en nada y es la primera vez en diez años que vuelvo a tener tiempo libre. La semana pasada, finalmente terminé de leer una novela que empecé hace cinco años, y hasta tuve tiempo para leer otra inmediatamente después. Fabuloso.
Traducida de Daring Fireball
Autor: John Gruber
Traducción: muelle
Revisión: Eduardo Abela y Ricardo Montiel
Coordinación: Alf
Personalmente me había sentido un poco decepcionado después de leer el artículo. No soy experto en Unix y no soy programador, por lo que las aseveraciones de MH me parecían bien fundadas.
A juan de Dios lo conozco y sé que habla de lo que conoce bien, así que mi “fé” en Apple ha sido restaurada 🙂
Gracias por la aclaración Juan 🙂
Eso se escribe con siete letras: mentira. El núcleo del Mac OS X es Mach 3.0; comparte núcleo con Unixes como los Unix de Digital, como los originales OSF/1, y ahora el modernísimo Tru64, con un núcleo Mach para procesadores de 64 bits, y la capacidad de utilizar extensiones de kernel para igualarlo con la velocidad y capacidades de kernels molotíticos como Linux o FreeBSD… de modo que el núcleo no tiene NADA que ver con la mayor o menor penetración de Mac OS X en el sector empresarial.
También habla de que el núcleo Mach es “viejo”… Eso no es cierto, entre otras cosas porque el núcleo está siendo constantemente revisado. Lo único que ocurre es que es maduro, y el hecho de que haya innumerables ejemplos de SO que lo utilizan lo avala.
Y respecto a las “funciones” que el núcleo del Mac OS X no soporta y que FreeBSD o Linux, según él, sí soportan, se apresura a comentar que bueno, que sí, que ahora el Mac OS X sí puede… pero que un Unix de verdad utilizaría llamadas RPC a lo SVR3… con lo que está redefiniendo lo de que Mach es viejo: SVR3 significa Unix System V, Release 3, o lo que es lo mismo, el Unix de ATT y los laboratorios Bell, allá por… y además, Mac OS X acepta llamadas RPC en el kernel:
ps. Si parezco molesto con este tipo, es porque me fastidia que alguien que sabe que miente lo haga porque su audiencia potencial no lo va a notar…
— Juan de Dios Santander Vela
Ingeniero en Electrónica, Desarrollador Palm OS
hola soy usuario mac os 9, despues migre a linux ppc. actualmente corro el linuxppc ydl 2.3 (considero que es le mejor).
sobre los comentarios del mac os x, estan un poco fuera de tono al mac os x no lo considero viejo respecto al kernel, tine muchas cosas que desearia que tubiera linux, la idea del porte es exquicita, yo trabajo programando en pequeño en mac os 9 pero mas me gusta en linux y odio emacs y el vi, prefiero el pepper. lo malo del osx son los recursos que debe de tener la mac.