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