¿Es cierto que es más productivo programar en una MacBook?

Depende de lo que programas. He programado por ya décadas en prácticamente todas las plataformas y tengo máquinas recientes de Mac, Linux y Windows. Cada que tengo el cash y compro un reemplazo a una de mis máquinas de producción, intento programar en ella exclusivamente por un tiempo para mantenerme “fresco” (siempre regreso a mi Macbook Pro).

Y aunque sí es cierto que hay mucho de productividad que es preferencia personal, y que hoy día las diferencias no son tan grandes como hace décadas, también es cierto que la filosofía de un sistema operativo es importantísima. Y también lo que vas a programar.

Primero lo obvio.

Si programas para Windows o cosas de Office, y juegos (Unity, etc), Windows es mucho mejor. Y si programas iOS, pues obvio necesitas una Mac.

Mac también corre Office bien (y puedes argumentar que, como sólo puedes escribir cosas “universales” en office, tus macros en Office son más probablemente compatibles en Windows), pero no es muy buena para los engines de juegos 3d (Unity for Mac existe, pero en general esas cosas se prueban primero en Windows). OneNote lo prefiero en Windows, o en el iPad (me gusta usar plumas y lo hago en Windows (Bamboo) y el iPad (Apple Pencil) pero la Mac, estúpidamente, no tiene ese soporte todavía).

Pero si programas C++ sin UI o Web o cosas que van a correr nativamente en sistemas Unix/Linux/FreeBSD, etc (o si escribes varios lenguajes a la vez en un teclado sin acentos, como yo), a mi me gusta más la Mac.

También en este caso (sin lo de los acentos) puedes usar Linux, pero en mi caso también necesito software comercial y las opciones de Linux son menos sólidas (y ya tengo un servidor Linux en mi casa desde hace años).


Porqué?

Básicamente, porque la Mac tiene una interfaz de usuario muy sólida y mucho más consistente, y porque “Darwin” (la base del sistema operativo) es basado en FreeBSD.

Lo cual quiere decir que la terminal y el Kernel funcionan exactamente igual y siguen los principios de diseño de Unix (“POSIX”, se llama), y todas las utilerías (shell, etc) o ya están instaladas en tu Mac o son fáciles de instalar.
No hay “traducción” de WSL entre el Unix y “el metal” (WSL es un translation layer y WSL2 es una virtualización), entonces cuando tratas con miles de archivos chiquitos a la vez, es igual de rápido.

Toma prestada una Mac por una semana e instala iTerm, Visual Studio Code, oh-my-zsh y tmux. Copia tus “scripts” de ejecución de tmux para hacer un ambiente con tus servicios para cada proyecto.

Te añado uno aquí bien fácil para que lo uses. En el script a continuación, cambia “node” por tu programa de servidor, “Emacs o tu editor favorito rápido” en vez de vi, etcetera.

Tengo uno de estos por cada proyecto y un script que los copia todos donde yo tenga un usuario. Es mi “IDE remoto o local”.


  1. #!/bin/bash 




  2. SESSION_NAME=MiServicio 




  3. MAYBE_CC="" 




  4. # Checa que estoy en iTerm, y si lo estoy, 




  5. # enlaza con el soporte de tmux en Mac via -CC 




  6. # Eso me da nombres de ventanas, opciones en el UI, etc. 




  7. if [ "$TERM_PROGRAM" == "iTerm.app" ]; then 




  8. MAYBE_CC="-CC" 




  9. fi 




  10. tmux has-session -t $SESSION_NAME 




  11. # No hay sesión? lánzate una 




  12. if [ $? != 0 ] 




  13. then 




  14. cd ~/trabajo/mi-servicio-web 




  15. tmux new-session -s $SESSION_NAME -n Vim -d 




  16. # para que funcione mi ssh auth. 




  17. tmux set-environment -s $SESSION_NAME -g 'SSH_AUTH_SOCK' ~/.ssh/ssh_auth_sock 




  18. # Web es la segunda ventana (mi tmux.conf tiene window 1 como primera) 




  19. # 1: Lanza mi aplicación web 




  20. tmux send-keys -t $SESSION_NAME 'node --debug app.js' C-m 




  21. # 3: Vim, el mejor editor. Pon Emacs si quieres. 




  22. tmux new-window -t $SESSION_NAME -n Vim -d 




  23. tmux send-keys -t $SESSION_NAME 'vim' C-m 




  24. # 2. Shell para checar cosas y usar Git 




  25. tmux new-window -t $SESSION_NAME -n Shell -d 




  26. # 3. Tig, para ver mi git en una UI de comando 




  27. tmux new-window -t $SESSION_NAME -n Tig -d 




  28. tmux send-keys -t $SESSION_NAME:3 'tig' C-m 




  29. tmux rename-window -t $SESSION_NAME:3 Tig 




  30. fi 




  31. # END:selectwidow 




  32. tmux $MAYBE_CC attach -t $SESSION_NAME 





Otro ejemplo de lo que puede hacer un tmux bien configurado.

El poder tener este “script” en mi Mac y en todos mis servidores quiere decir que, en un apuro, mis dedos están preparadísimos para checar la historia del código, dar respuestas, dar seguimiento a problemas, examinar logs, y un sinfín de cosas exactamente de la misma manera que en mi estación de trabajo que, si estoy “pendejeando” (si me permites un Mexicanismo) con una terminal que funciona diferente porque es Putty en C vs el monstruo de Frankenstein que es Terminus en Electron vs un sinfín de otras cosas, aunque use el mismo script en los mismos, no es lo mismo ni se siente igual. Si necesito conectarme al UI (digamos, Ubuntu) de otra máquina extraña, copio mis scripts, lanzo la consola y corro lo mismo. No hay cambio para mí.
Y mientras mis dedos vuelan checando logs de miles de líneas sin copiarlos localmente o copiandolos y checándolos locales con las mismas utilerías de Unix de awk/sed/cut/etc sin pelearme con los “filesystems” de C: D: y F: versus los WSL mounts….

Todavía puedo tener los navegadores en un lado, VSCode para cuando necesito programar en serio, Zoom y DBVisualizer, Zeplin, Adobe, Office para escribir diseños y un mundo de cosas.

En Windows, aunque tengo chorrocientos años de experiencia y le hago un intento más honesto (y van mejorando, es verdad, en especial desde Satya Nadella), todavía me encuentro con algo que me hace perder dos, tres horas a la vez resolviendo un “problema de compatibilidad” de una manera u otra, o cosas que son sistémicas y simplemente no se pueden resolver. Esta misma recomendación de scripts, en Windows con WSL, técnicamente “funciona”, pero hay problemas.

Mientras si “falta algo” en la mac, simplemente digo “brew install loquefalta” y funciona

Pongo mucho valor en mi tiempo, y uso muchas máquinas, y por eso automatizo mucho. Y me encanta la tecnología e intentaré jugar con cualquier línea de comando un rato, pero nada puede compararse a la habilidad e instinto que he creado a través de los años (vi, el editor que uso, existe en alguna forma desde 1976).

La tecnología que usas, aunque muy personal, debe sentirse que te está ayudando a tí y no que tú estás ayudando a la tecnología. Para mí la Mac, mas “cara”, está tomando ventaja de décadas de mi memoria de dedo en Unix y al mismo tiempo dándome un ambiente visual comodísimo para trabajar, estar también aquí en Quora, mandar emails y hacer documentos bonitos, y usar las fotos que saqué con mi iPhone.
El “costo extra” en el sticker (que, por cierto, se ahorra en el hecho de que en general, las Apps de Mac suelen ser más baratas en promedio, aunque eso está emparejándose ya un poco) me lo ahorro en un par de días de ahorrar pelearme con las interacciones – rarísimas todas y no todas con solución – del Kernel de Windows con cosas importantes para mi trabajo que no fueron diseñadas para Windows, ya sea con Docker, Git en WSL a través de filesystems, VirtualBox, o lo que sea. Y tener una terminal sólida (tanto iTerm como “Terminal”, nativo a la Mac, son mejores y más compactas que cualquier opción en Windows), vale más que el oro para mí.
Para parafrasear a Jamie Zawinski “el costo extra es alto sólo si tu tiempo no tiene valor” (aunque en su frase original, se refería a Linux, que en aquel entonces era muy difícil de instalar y configurar).
Y mi segunda opción como profesional (y si el costo es un factor) es cualquier máquina que corra Linux, que son baratísimas y se pueden configurar para ser rápidas en casi cualquier hardware (lubuntu con Openbox vuela aunque sea en hardware pésimo y todas mis recomendaciones aplican), pero entonces extraño mis programas comerciales y la consistencia del UI. Y obviamente las consolas en Linux tienden a ser buenas (pero peores que iTerm).

Deja un comentario