Maarten Hekkelman es el programador que está detrás de Pepper, un editor de texto para programadores del Macintosh, que comenzó su vida en BeOS como Pe. Hace dos semanas, este residente en Holanda de 36 años anunció que abandonaba el programa, y que no seguiría desarrollando o vendiendo Pepper. Daring Fireball entrevistó al Sr. Hekkelman vía correo electrónico el pasado 30 de Agosto de 2002.
¿Quién mejor para entrevistar al autor de un editor de textos para Mac que alguien que solía trabajar para Bare Bones Sofware?
John Gruber: Empecemos con las noticias. De acuerdo con su web, usted no admite más pedidos de Pepper, el editor de textos en el que ha estado trabajando varios años. De hecho, no se podrá bajar más, excepto aquellos usuarios registrados.
¿Qué pasó? Parece una cantidad enorme de trabajo para dejarlo.
Maarten Hekkelman: Lo es. Lo que ha llegado a ser Pepper me llevó unos seis años de desarrollo. Pepper comenzó llamándose Pe en BeOS y fue portado a Mac OS [desde Pepper 3.0].
Francamente, estaba muy decepcionado con Mac OS X y entonces [para la versión 4.0] decidí portarlo a Windows. El código era ya bastante portable pero aproveché esa circunstancia para separar el código propio de Pepper del más genérico. Había usado PowerPlant para la primera migración a MacOS y comencé a reemplazar PowerPlant con mi propia librería. Recibí ayuda de un viejo amigo, Bas Vodde, quien me ayudó a desarrollarlo con rapidez en Windows (yo nunca había programado para ese OS antes). Me llevó nueve meses terminar Pepper 4.0 para Mac OS y Windows, y presenté una versión para Linux un par de meses después.
Pero Pepper 4.0 no fue bien recibido. Las primeras versiones tenían problemas de velocidad y la gente culpó de ello a la conversión a multiplataforma. De cualquier forma, muchos de los problemas de funcionamiento estaban relacionados con fallos internos y no se debían en absoluto al cambio de plataforma.
Las reacciones negativas se extendieron; en VersionTracker hubo muchas quejas, y eso influyó en las ventas. Y después el código de registro de Pepper fue pirateado, encontré mis primeros casos de fraude, tuve una pelea con Tucows, y Pepper no funcionaba en Jaguar… así que me di por vencido.
JG: Entonces, ¿Pepper 4.0.6 no funciona sobre Jaguar?
MH: No, lo siento.
JG: Pepper 3.0 apareció en Mac en Julio de 2000, sólo unos pocos meses antes que la beta pública de Mac OS X, y solamente ocho meses antes de la presentación de Mac OS X 10.0. ¿Nunca había considerado dejar de dar soporte al viejo Mac OS, y hacer Pepper sólo para Mac OS X?
MH: No. Ante todo, Pe fue ya escrito en C++ de modo que la elección de PowerPlant para reemplazar la API de BeOS parecía clara (a mis ojos). Y entonces, aunque había tenido las versiones de prueba de Mac OS X a tiempo, no eran muy manejables. Y no me gusta Cocoa y nunca programaría en ese entorno, ya que es una tecnología sólo para Mac y no me gusta estar encerrado.
JG: ¿Cree que muchos de los usuarios de Pepper utilizan Mac OS X?
MH: No. Creo que un 50%. Cifras no rigurosas, sin embargo.
JG: Esto es interesante. Yo creía que Pepper resultaría más atractivo para usuarios de Mac OS X. Entre otras cosas, en Mac OS 9 los filtros Perl de Pepper necesitan la herramienta ToolServer de MPW, mientras que BBEdit funciona con la aplicación MacPerl (que es mucho más fácil de instalar que MPW).
MH: Siempre lo usé en Mac OS 9 y es muy buen editor en esa plataforma, si se me permite decirlo.
JG: No quería dar a entender que no fuera bueno en Mac OS 9, sólo que creía que las oportunidades de negocio estaban en Mac OS X. Cuando la gente cambie al nuevo OS, estarán repentinamente en un mercado con todo tipo de nuevo software.
MH: Sé que no querías decir eso. Y tienes razón en lo que piensas.
JG: ¿Sobre qué fue la discusión con Tucows?
MH: Rechazaron listar Pepper [alegando] que no era suficientemente bueno. Cambié algunas cosas y volví a enviarlo. Entonces compré una reseña “A fondo” con la esperanza de que esto ayudara a que Pepper fuera listado. Pero el crítico no consiguió hacer funcionar Pepper en la máquina en la que quería hacer la prueba. Esto terminó en una pelea en el barro, cuando quise recuperar mi dinero y se negaron a devolvérmelo.
JG: Debo admitir que estoy muy poco familiarizado con Tucows (hace seis o siete años que no uso Windows ). ¿Dice en serio que para conseguir ser listado en Tucows necesita pagarles para que reseñen un programa? Debe ser difícil para ellos mantener la objetividad en esos casos.
MH: Puedes comprar puntos extra y serán añadidos a la valoración de tu producto. O sea que sí, tienes que comprar tu posición. Pero como tienen tanto poder [en la comunidad Windows] pueden hacerlo.
JG: ¿Qué efecto cree que tuvo en las ventas que el número de registro fuera pirateado? A menudo me pregunto si la gente que usa códigos de registro ilegales, compraría el programa al no tenerlo.
MH: Ningún efecto en absoluto. Pero duele mucho, especialmente si trabajas duro para hacer algo cuyo precio es tan bajo que todo el mundo puede permitírselo.
JG: De hecho, siempre pensé que Pepper tenía un precio muy bajo.
MH: Demasiado bajo, muy, muy bajo. Pero esperaba que esto ayudara a hacerlo más popular. Y los precios en Windows están todos en este nivel. Habría sido muy extraño vender Pepper para Mac OS por US$100 y Pepper para Windows por US$30, sólo para poder competir.
JG: Hay varias docenas de “editores de texto” y “editores HTML” de distribución gratuita de bajo coste para Mac, muchos de ellos desarrollados con REALbasic. La mayoría ofrecen muy pocas características que no vengan ya incluidas en la estructura de desarrollo de REALbasic. ¿Alguna vez se preguntó si la existencia de todos estos deficientes editores de texto hacen más difícil que Pepper destaque? En otras palabras, la gente que debe haber visto el anuncio de Pepper habrá pensado “Oh, otro editor cutre más”, sin haberlo descargado ni probado.
MH: No, la tragedia de Pepper fue que llegó a ser bien conocido y mucha gente lo seguía con VersionTracker. Pero muchos decidieron que esta versión no era suficientemente buena como para dejar BBEdit y comenzar a usar Pepper.
Recibí muy pocas reacciones negativas a mi decisión de dejar de desarrollar Pepper, y todas venían de gente que aún no había comprado Pepper pero esperaban hacerlo más adelante.
JG: Su propia descripción de Pe admite que fue “inspirada por MPW y BBEdit — ambos editores del Mac OS”. ¿Era un desarrollador de Mac a tiempo completo antes de cambiar a Be? ¿Cuál fue su editor preferido en Mac?
MH: En esa época, tenía un par de trabajos como programador para Mac a tiempo completo. Y cuando trabajaba en Mac OS usaba Codewarrior para programar. Tenía una licencia para BBEdit, e intenté usarlo de vez en cuando, pero a mi modo de ver no tenía suficientes características extra para hacer que mereciera la pena usarlo como editor externo [en vez de Codewarrior].
También usé MPW en algunas ocasiones, y la misma historia. BBEdit tenía una interfaz manejable, pero no funcionaba tan bien como debería.
JG: ¿Ha usado BBEdit 6.5? Su nueva área de trabajo para Mac OS X es muy bonita.
MH: No, sólo uso Macs si tengo que hacerlo. Y dejé de mirar a BBEdit desde que encontré muchas de las caracteristicas que se me habían ocurrido a mi también.
BeOS frente Mac OS X
JG: El BeOS generalmente recibía críticas positivas, pero nunca obtuvo suficientes usuarios para ganar una masa crítica. ¿Cuándo comenzó a usar BeOS, y por qué?
MH: Leí sobre él cuando hicieron pública su primera versión del OS e inmediatamente me enganchó. ¡Una GUI y una capa POSIX combinados en una máquina y con tantas cosas tan buenas! Grandioso. Algunos meses después, en 1996, volvi a leer otra vez sobre él y decidí correr el riesgo. Fui al banco a pedir un préstamo para comprar un BeBox. Nunca me arrepentí, la vida era maravillosa entonces.
JG: Be, la compañia, parecía tener la estrategia para comercializar su OS (y sus ordenadores BeBox) orientándolo a los desarrolladores. Uno de sus principales puntos de marketing era que BeOS tenía una muy potente API, fácil de usar – y que la API estaba diseñada desde su base como orientada a objetos, y por lo tanto no estaba construida sobre una API procedural heredada de sistemas anteriores, como Mac OS o Windows. ¿Cuál fue su experiencia programando para BeOS? ¿Cómo era comparando con programar para Mac OS al mismo tiempo?
MH: Programar para BeOS era simple cuando empezabas. Pero se volvía bastante confuso rápidamente. El problema es el multi-hilo . Mientras haya una sola ventana haciendo el trabajo no hay problema, pero intenta mostrar un documento en mas de una ventana y tendrás problemas. Esa fue la razón de que Pepper no volviera a portarse a BeOS.
Sin embargo la API era agradable. Comparable a PowerPlant en Mac OS. (Pero PowerPlant es mejor.)
JG:En su superficie, BeOS y Mac OS Xson parecidos. Ambos tienen capas Unix/POSIX por debajo, pero ambos tienen interfaces gráficas que han sido diseñadas para ser consistentes e intuitivas. Ambos son populares para hackers que gustan de poder programar en línea de comandos al estilo Unix, pero que también aprecian una interface bien diseñada. ¿Qué le gusta más de BeOS comparado con Mac OS X?
MH: Prácticamente todo. BeOS era rápido, extremadamente rápido. Era nuevo, fresco, etc. Sólo puedo pensar en muy pocos puntos negativos, técnicamente hablando, en BeOS. La fea GUI debería de ser uno de ellos, la absoluta necesidad de usar multi-hilos, el segundo.
Mac OS X, de cualquiera de las maneras, pierde en todos los frentes. Reivindica ser un Unix pero no soporta muchas de sus características mas avanzadas, ya que está usando un kernel tan viejo. Reivindica ser amigable para el usuario, pero lo encuentro más oscuro y difícil de manejar que mi Win2k. Y además es condenadamente lento.
JG: Y ya que el Mach kernel es un proyecto personal de Avie Tevanian, no tiene pinta de que vaya a cambiar nunca.
MH: Si. Muy mal. Tenía un par de características interesantes en Pepper para Linux/FreeBSD pero no podría portarlas a Mac OS X ya que el kernel no las soporta.
JG: ¿Que características?
MH: Redirigir una salida a una nueva ventana en Pepper. Eso funciona en Mac OS X ahora (bueno, 10.1.x) pero funciona mucho mejor y mas bonito en un Unix real usando llamadas SVR3 estilo RPC. Hay otras muchas características. Una cosa que echo de menos en Mac OS X es el sistema de archivos /proc. Había pensado escribir un depurador para Mac OS X pero esta omisión me hizo que me olvidara del asunto.
JG: ¿Siempre tuvo en mente que algún día debía portar Pe al Mac, o sólo lo consideró una vez que BeOS fue abandonado?
MH: No, no cuando empecé. Cuando volví al Mac comencé usando BBEdit y Codewarrior primero, pero echaba de menos muchas de las características que había implementado en Pepper y por eso decidí portarlo.
JG: ¿Por qué volvió al Mac en vez de a Windows con Pepper 3.0?
MH: En esos tiempos era un verdadero creyente. Tenía esperanzas de que apareciera un Mac OS que llegara a ser tan bueno como BeOS. Por otro lado, entonces era uno de esos anti-Microsoft.
JG: ¿En qué sentido está decepcionado con Mac OS X? ¿Cómo un usuario, cómo un desarrollador, o cómo ambos?
MH: Como usuario, no me gusta, Dios sabe que lo he intentado duramente, en serio.
Lo que cuentan para mi son los detalles, y estaban todos mal. Encontré tantos errores en la interfaz de usuario en OS X que no podía creerlo. Una enorme cantidad de trabajo de investigación diseñando la GUI definitiva fue completamente abandonada y todo lo que hemos obtenido a cambio es una bolsa llena de caramelos que es condenadamente lenta.
Y como desarrollador lo odio. Tenía que usar Carbon, por supuesto, y apesta, demasiados cambios, demasiados errores. Pepper dejo de funcionar en el 10.2, porque en Jaguar los gestores de eventos Carbon tienen que ser reentrantes… ridículo.
JG: Parece como si hubiera ido un poco de atrás a adelante en el motor de presentación del texto subyacente que usa Pepper – usando ATSUI en la versión inicial de Pepper 4.0, haciendo después ATSUI opcional. ¿Fue ahí donde estaban los problemas de rendimiento?
MH: ATSUI es lento, realmente lento. Implementé la opción para usar Quickdraw en la versiones 4.0.x posteriores para ilustrar eso. Pero el mayor problema respecto al rendimiento en Mac OS X es el desplazamiento del contenido de las ventanas. Es realmente absurdo cuanto tiempo le lleva hacerlo.
De cualquier forma, algunos de los problemas de rendimiento eran culpa mía, debería haber considerado más casos, como abrir ficheros enormes y miles de cambios en esos ficheros. Pepper usa un sofisticado mecanismo de transacciones para almacenar los cambios sobre el documento y lo estropeé haciendo que Pepper funcionara mejor con finales de línea mixtos [compuestos por CR/CRLF].
JG: ¿Fue ese problema introducido entre la versión 3.6 y la 4.0? ¿Se corrigió en la versión 4.0.6?
MH: Fue introducido en la 4.0. Quería que Pepper fuera más robusto con ficheros UTF8 incorrectamente formateados, por ejemplo. Y sí, la mayor parte ya está corregido. Al menos en la copia que estoy usando. 🙂
JG: ATSUI es una tecnología sólo para Mac. ¿Qué usa para presentar el texto en los otros sistemas?
MH: Me gusta que me lo pregunte. En otros OS simplemente usaría la API de texto por defecto, en Mac OS tienes que crear parches como método alternativo al muy pobre soporte de texto. Realmente no entiendo cómo Apple fue tan estúpida. Podían haber introducido un nuevo y simple código script para presentar Unicode usando QuickDraw y la vida hubiera sido estupenda. Pero no, Apple salió con ATSUI, el cual es bonito para un tipógrafo pero un horror para un programador de un editor de texto.
Y también es lento.
JG: ¿Y no descubrió esos problemas de funcionamiento en las versiones de prueba [de Mac OS X]?
MH: No. No abría ficheros de mas de 100 MB frecuentemente. Ahora lo hago, en mi nuevo trabajo.
JG: ¿Cuánta gente usó para la fase de pruebas? ¿Cómo consiguió gente para las nuevas plataformas soportadas por Pepper 4.0?
MH: Tengo unos 20 beta testers. Muchos menos de los necesarios, y si bien aprecio mucho lo que hicieron, no fueron muy útiles cuando se trata de pruebas reales. Aunque aportaron buenas ideas.
No tuve gente para probar en otras plataformas.
JG: Los test públicos de betas parece que han ganado mucha popularidad en los últimos 10 años, especialmente entre pequeños desarrolladores. ¿Cúales es su opinión?
MH: Siento tener que decirlo, pero mucha gente se ofrece para hacer las pruebas sólamente para conseguir programas gratis y nunca ofrecen ninguna respuesta. Sólo unos pocos son muy buenos y vocacionales, y hay que ser bueno con ellos. Pero al final, difícilmente encuentran algún problema serio y eso no es extraño. Suelen usar un subconjunto de las características y ésas frecuentemente están bien probadas. Son las características mas escondidas y los detalles donde se tarda en descubrir problemas . La única forma de probar el programa es usarlo uno mismo o hacer un plan de tests y contratar una empresa para que haga las pruebas por ti.
JG: ¿Por qué sustituir PowerPlant? ¿Porque no le gustaba, o porque quería ir a otras plataformas?
MH: Quería cubrir varias plataformas. Y no me gustan algunas de las implementaciones de PowerPlant, pensaba que sería más eficiente al usar eventos de Carbon de forma más amplia. Estaba equivocado.
JG: ¿Cuánto del código fuente de Pepper es común para las diferentes versiones, y cúanto es especifico de cada plataforma?
MH: Pepper se compone de unas 160,000 líneas de código. 15.000 son específicas para Mac OS, 12.000 para Windows y 7.100 para X11. El resto son independientes del sistema.
JG: ¿Cuál es su opinión de las herramientas de desarrollo y las API para Windows?
MH: Estoy usando CodeWarrior para Windows, CW5 para ser preciso. Está un poco desfasado pero como todavía funciona y CW es tan terriblemente caro nunca lo actualicé. Microsoft distribuye un conjunto de documentación y herramientas para desarrolladores muy, muy bueno. Gratis. Realmente me abrió los ojos tener semejante cantidad de documentación tan fácilmente disponible.
Intenté con algunas otras utilidades en Windows como BoundsChecker de Numega, un poco como SpotLight sobre Mac OS pero mucho mejor. Pero no la compré ya que también era muy cara.
Windows es como el cielo para un programador. Hay tantas herramientas para elegir y la documentación es maravillosa. Creo que las API están en general muy bien. Hay algunas API que simplemente no las entiendo, como la que da soporte a las entradas en línea, pero esas son excepciones.
Traducida de Daring Fireball
Autor: John Gruber
Traducción: muelle
Revisión: Eduardo Abela y Ricardo Montiel
Coordinación: Alf
