El corazón de las tinieblas

Con este título no quiero hablar hoy sobre la famosa novela de Joseph Konrad  (que por cierto acabo de releer en versión bilingüe, lo que permite disfrutar mucho más la riqueza del inglés de Konrad) y que inspiró la película Apocalipse Now; sino reflexionar en un tono ligero, como suele corresponder tradicionalmente a los medios de comunicación en verano, sobre los interfaces de usuario utilizados últimamente por muchos programadores y personas implicadas en el desarrollo de aplicaciones.

Si comparamos las siguientes imágenes, veremos que todas tienes algo en común, utilizan letras blancas (o claras) sobre un fondo negro.

By Ilya - screenshot making, JetBrains - IDEA Community edition interface [Apache License 2.0] via Wikimedia Commons

By Visual Studio Code: Microsoft Sample code: Mr. Stradivarius (talk · contribs) and Toohool (talk · contribs) Screenshot: Codename Lisa (talk · contribs) [MIT] via Wikimedia Commons

By ZxxZxxZ (Own work) [GPL] via Wikimedia Commons

By Sean Haas (http://code.google.com/p/dreckig-os/) [GPL], via Wikimedia Commons

La diferencia es que unas  tienen unos 30 o 40 años y otras son de este año. 

Hace años, cuando la única posibilidad de visualización eran las primeras pantallas C.R.T.  con fósforo verde, no quedaba más remedio que utilizar letras claras sobre fondo negro (salvo que se quisiera quemar la pantalla y los ojos del usuario).

Sin embargo con el tiempo los colores se fueron aclarando e invirtiendo y hace mucho que lo habitual en los ordenadores es usar letras oscuras (negras) sobre fondo claro (blanco) no solo en los interfaces de sistema (como el explorador de archivos) sino en general en los distintos programas (como los paquetes ofimáticos, herramientas de desarrollo, etc.). Incluso los programas de CAD, que tradicionalmente utilizaban líneas blancas sobre fondo negro, se han ido pasando al uso de fondo claro y línea negra (véase por ejemplo Rhinoceros, aunque clásicos como Autocad se mantengan “irreductibles”).

De los pocos elementos que se han mantenido con ese mismo interfaz (e incluso con las mismas funciones) desde hace 30 años son los shells/intérpretes de comandos para los diferentes sistemas operativos, que han mantenido en general su interfaz de fondo negro y letra clara (con excepciones como algunos emuladores de terminal o XTerm de X-Windows). También puede verse estos tonos oscuros en los proyectos trabajando en COBOL y JCL sobre entornos mainframe.

Uno de los motivos que se ha argumentado tradicionalmente para este cambio es que, cuando se trabaja en un entorno iluminado, como es una oficina o una casa particular, el cambio entre un área luminosa (como es el entorno) y un área oscura (la pantalla) cansa la vista al obligar a ajustar la pupila a la distinta luminosidad. Este mismo efecto de deslumbramiento/cansancio se produce por la noche si se está en un entorno oscuro y se utiliza una pantalla clara (fondo blanco y letra negra), por ello se suele recomendar por la noche ese modo “invertido”. Un ejemplo extremo de esto son las herramientas y programas de observación astronómica (como Skymap o Stellarium)), muchas de las cuales tienen un modo “nocturno” que suele utilizar fondo negro y líneas y texto en rojo, para no deslumbrar cuando se utiliza en absoluta oscuridad.

El hecho es que durante muchos años, para editar un documento o una hoja de cálculo, editar un texto, modelar un proceso o programar en un entorno de desarrollo integrado (IDE), siempre se trabajaba con letras oscuras sobre fondo blanco.

Sin embargo desde hace uno o dos años se han ido extendiendo “las tinieblas” ☺ y es más habitual ver pantallas oscuras, sobre todo entornos de desarrollo como IntelliJ IDEA  o Visual Studio Code. Yo incluso lo he visto usar en programas para editar ficheros de texto (de los habituales para editar grandes ficheros, script o fuentes de programas, sin llegar a abrir un IDE completo). Incluso hay extensiones para utilizar esos temas y colores en otros IDE como Netbeans, que tradicionalmente han mantenido colores claros. 

Hay otro contexto donde es habitual ver esta “oscuridad”, es el uso del sistema de virtualización Docker. Este sistema de virtualización está basado en Linux, y aunque existe una versión para trabajar en Windows, lo hace ejecutando una máquina virtual Linux bajo Windows utilizando el sistema de virtualización VirtualBox. El resultado es que es muy habitual ver intérpretes de línea de ordenes Linux incluso en equipos Windows, para gestionar y arrancar las pequeñas (incluso de 50M) “máquinas virtuales” de Docker.

Dado que el ojo humano no ha cambiado, que para editar documentos se sigue manteniendo el negro sobre blanco, al igual que para los libros (electrónicos o en papel) o en muchos otras herramientas que requieren fijar la vista y concentración durante mucho tiempo, hay que concluir que es una moda específica del mundo de desarrollo.

¿Qué motivos puede tener esa moda para extenderse tanto en el ámbito del desarrollo?

Si tenemos en cuenta que Docker es de una alternativa muy moderna y de futuro, que el desarrollo en Android produce muchos más programas, y en ocasiones más originales y atractivos que el desarrollo para ordenadores de sobremesa y que se trata de entornos y herramientas aparecidos recientemente, parece inevitable concluir que el “lucir” una pantalla oscura, aunque solo sea para editar un fichero XML, muestra ante los compañeros y jefes “que estamos a la moda” y trabajando con las últimas tecnologías.

Lo que hace unos años podía ser símbolo de antigüedad y obsolescencia al observar a alguien trabajando con una pantalla oscura (“fíjate, pobres, trabajan en un terminal con lenguajes anticuados como COBOL”) se ha convertido en símbolo de “distinción” (“fíjate, están trabajando con las herramientas más avanzadas”). Aunque se trata de herramientas, mas sofisticadas que un martillo o llave inglesa pero herramientas al fin y al cabo, de nuevo los colores y estilos de moda como símbolo de distinción y estatus.

Esperemos que los creadores de herramientas, y sobre todo los usuarios de las mismas, “vean la luz” ☺ y esta ola de oscuridad se disipe. 

Yo desde luego seguiré trabajando con un entorno claro.

By Moriline (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Lo pequeño es hermoso

“Lo pequeño es hermoso” es el título de un libro publicado en 1973 por F Schumacher. Su nombre completo es “Lo pequeño es hermoso: Economía como si la gente importara” y defiende el uso adecuado de los recursos, procurando utilizar opciones sencillas y recursos lo más limitados posibles.

Este criterio, que siempre ha sido válido, se hace cada vez más necesario en el mundo de la tecnología. Parafraseando el título, podría decirse “Lo pequeño es hermoso: TECNOLOGÍA como si la gente importara”.

Si observamos la tecnología que utilizamos habitualmente, veremos que las páginas Web aumentan cada año su tamaño (peso) medio ( http://httparchive.org/index.php ), de forma que aunque las comunicaciones han mejorado mucho y el ancho de banda disponible para descargar una página se ha multiplicado por 1000 en 20 años, el tiempo de espera en algunos casos es el mismo que cuando se utilizaba un modem a 33k.

Algo equivalente puede decirse de las aplicaciones. La mayoría de los móviles actuales, y desde luego cualquier ordenador, tiene mucha más potencia, memoria y velocidad que ordenadores de hace 20 o 30 años (recordemos que una memoria RAM de 4 megas y un disco de 200 Megas eran “un buen equipo”, por no hablar del PC inicial, con 640K y un disco de 10M). Sin embargo, muchas aplicaciones que utilizamos no parece que vayan mucho más rápidas que hace años, e incluso algunas van más lentas claramente. Además, muchas tienen unos tamaños “monstruosos” para lo (poco) que hacen.

En algunos casos se puede decir que las aplicaciones modernas “hacen más” (se revisa la ortografía y gramática en tiempo real, se presentan gráficos de diverso tipo, se ubica la posición y se hacen cálculos en base a la misma, etc.) pero no tanto para justificar esos rendimientos.

Creo que hay varios motivos que podemos agrupar en personales y tecnológicos:

Personales:

Uno importante sería la despreocupación de algunos desarrolladores (“ahora los equipos son rápidos”, “hay memoria suficiente”, “Todo el mundo tiene mucho ancho de banda”), que provoca que no se intente optimizar el código, ahorrar memoria o ahorrar ancho de banda. 

A ello se une la falta de programadores con experiencia, que es otro factor importante. Programadores veteranos que han aprendido trabajando con ordenadores y herramientas con pocos recursos se han acostumbrado a optimizar y ser ahorradores y tienden a diseñar los programas de forma “austera”.  

Si a eso se añade la necesidad de cumplir los plazos y las especificaciones, no de cumplirlas “óptimamente”, se comprende que en muchos casos la eficiencia queda en último lugar.

Tecnológicos:

Muchos de los lenguajes de programación se “encargan de gestionar la memoria” (como ocurre con java) un desarrollador, aunque sepa con total seguridad que ya no necesita un elemento, no puede borrarlo y debe esperar a que “se borre cuando se pueda”. No bastante creo que el principal motivo son la “herramientas de ayuda al desarrollo”, entre las que podríamos incluir el uso de diversas librerías, framework de desarrollo y herramientas para generación de código. Dado que los lenguajes y herramientas de programación no incluyen todas las funciones posibles para todas las necesidades, se suele acudir a librerías de funciones que contiene diversas funciones (manejo de sonido, imágenes, cálculo, gráficos, etc.) que permiten realizar operaciones sin tener que desarrollar desde cero ese código. El problema es que en muchos casos, el utilizar unas pocas funciones implica arrastrar toda la librería de funciones completa. Es decir, necesitamos, por ejemplo convertir una imagen de formato, o recortarla, pero las librerías incluyen funciones para todos los formatos, para girar, recortar, alterar el color, etc.

Con los framework de desarrollo, que a diferencia de las librerías no ofrecen conjuntos de funciones sino esqueletos de desarrollo sobre los que se encaja nuestro proyecto, pasa algo similar. Están planteados para un modelo de trabajo con una serie de relaciones y comportamientos, de los cuales es posible que muchos elementos sobren para el programa que se desea desarrollar. De nuevo se arrastra una enorme estructura y cimientos planteados para un edificio de 5 plantas cuando lo que se desea una casa unifamiliar (o quizá una casa de 5 plantas pero con otra distribución).

Por último, hay muchas herramientas que para facilitar la vida, permiten generar código fuente. pero ese generación, aunque cómoda, al ser genérica no siempre suele ser demasiado eficaz, con lo que se gana en velocidad de desarrollo (y en ocasiones en calidad y normalización) no se gana (o se pierde) en eficiencia.

El resultado es que con bastante frecuencia tenemos una gran cantidad de programas de dimensiones desmesuradas, peleando por los recursos y consumiéndolos inútilmente. Al igual que ocurre con la contaminación, la emisión de un coche no es demasiado significativa, la de miles, sí. Y todos sufrimos ese exceso de consumo de recursos sufriendo programas lentos y enormes. La memoria, o el ancho de banda de comunicaciones, al igual que los recursos naturales, no son infinitos y es mejor usarlos razonablemente.

Los anglosajones utilizan la expresión “Keep It Simple, Stupid” (K.I.S.S.: "Mantenlo simple, estúpido") también expresada como : “Keep It Short and Simple” ("Mantenlo corto y simple") o “Keep It Simple and Safe” ("Mantenlo simple y seguro") que puede considerarse una especie de Navaja de Occam,  pero aplicada, no al análisis o interpretación, sino al diseño y construcción.

Ejemplos prácticos:

Habrá quien piense que esto es algo teórico y que un programa “serio” necesariamente es grande y complejo. Para demostrar que es posible voy a citar algunos ejemplos:

• Base de datos: HSQLDB es un gestor de base de datos Open Source que además de cumplir todos los requerimientos de una BBDD relacional y ser extremadamente rápida (http://www.h2database.com/html/performance.html), incluye las siguientes funciones:
  
  • java puro que funciona en cualquier sistema operativo
  • Emula funciones y sintaxis de otras bases de datos
  • Puede trabajar como base de datos en memoria
  • Puede configurarse para trabajar de modo portable
  • Un fichero jar de 1,5 M incluye el servidor de BBDD, el cliente JDBC y un interfaz de usuario gráfico. 
• Servidores de aplicaciones: Jetty es un servidor de aplicaciones Open Source similar a Tomcat que cumple todas las funciones necesarias como cualuier otro (https://en.wikipedia.org/wiki/Comparison_of_web_server_software) (quizá solo se echa en falta un interfaz de administración avanzado) y que ocupa unos 11M completo (aunque puede embeberse y utilizarse solo el núcleo del servidor empleando prácticamente un tercio).
• Motor de indexación por texto completo: El proyecto Open Source Lucene es el motor de indexación y búsqueda por texto completo más utilizado en el mundo, tanto directamente como a través de recubrimientos como Solr o ElasticSearch. Su núcleo, que permite indexar y buscar, ocupa solo 5M.
• Gestor Documental: OpenProdoc es un gestor documental Open Source completo que incluye todas las funciones de cualquier gestor documental, junto con un gestor de tesauros. Dispone de una versión portable, que gracias al uso de las tres herramientas antes citadas, así como a seguir el principio KISS, ocupa 80M completo, lo que para un gestor documental, teniendo en cuenta que incluye servidor de BBDD, servidor de aplicaciones más el propio Gestor, es poco comparado con algunos clientes de gestor documental que ocupan 700M, o instalaciones de servidor de 1G
• Utilidades Android: El programa Army Knife, contiene en 2,3M las siguientes herramientas:
  • Calculadora científica
  • Linterna
  • Conversor de unidades,
  • Temporizador/cuenta atrás
  • Cronómetro multi-vueltas
  • Brújula
  • Nivel
  • Lupa
  • Espejo
  • Regla (cm/pulgadas)
• Gestión de imágenes: El programa Irfanview en solo 2M incluye visualización de prácticamente todos los formatos de imágenes existentes, conversión de formatos, manipulación completa de imágenes (profundidad de color, resolución, filtros, etc.), procesos de conversión en lotes, creación de miniaturas, etc.
  
  

Colibrí Mdf [GFDL (http://www.gnu.org/copyleft/fdl.html) CC-BY-SA-3.0

La conclusión es que “sí se puede”, por tanto creo que es importante que como usuarios o como desarrolladores o diseñadores sigamos el principio de : “Lo pequeño es hermoso: TECNOLOGÍA como si la gente importara” a la hora de crear herramientas o de utilizarlas. El "medio ambiente tecnológico" y nuestro paciencia o nervios lo agradecerán.

El altísimo coste del “ahorro” en ordenadores y equipamiento.

Hace años, en un proyecto de gestión documental que estuve desarrollando para un cliente, se instaló el servidor en mi portátil, de forma que las 5 personas del equipo que yo dirigía se conectaban al mismo, desarrollaban y probaban contra él. Exactamente dos días DESPUÉS de acabar el proyecto se quemó el cargador de mi portátil. Cuando fui a la sede de la empresa en que trabajaba para solicitar un cambio, recogieron el antiguo y me indicaron que “ya me avisarían”, pues la norma era no tener recambios. Tres días después, en los que no puede prácticamente trabajar, revisar correo, etc. pude ir a recoger el cargador.

By Evan-Amos (Own work) [Public domain], via Wikimedia Commons

Haciendo una pequeña evaluación del impacto económico:

• Coste de una fuente de alimentación media: 20€
• Coste aproximado perdido por 3 días (asumiendo un salario medio bruto + costes empresa SS,..): (44.000 €/220 días trabajo)*3 días = 600€ por tres días de una persona
• Si la avería se hubiera producido una semana antes: 600€* 6 personas =3.600€

La conclusión de la historia es que por no tener inmovilizados, no ya gastados (salvo que nunca se rompa ningún cargador de ningún empleado) 20€, se perdieron 600€ y se podían haber perdido 3.600€.

Las cifras pueden parecer exageradas pero no lo son en absoluto, y eso solo contando “costes”. Si esas personas estuvieran en una asistencia técnica como consultores, facturando al cliente, por ejemplo 50€/hora, hablaríamos de:

• 50€*8h/día*3 días*6 personas = 7.200€ que no podrían facturarse (o podría hacerse “engañando” al cliente)

Tampoco se incluye “costes de oportunidad”, cumplimiento de plazos, posibles penalizaciones, impacto en otros equipos, etc.

“Por un clavo se perdió una herradura, por una herradura se perdió un caballo, por un caballo se perdió una batalla, por una batalla se perdió un reino”

Puede alegarse que sin equipo se puede trabajar “en otras cosas”, pero en gran parte de las empresas actualmente, sin ordenador puede hacerse pocas cosas. El correo está en el ordenador, las herramientas de trabajo están en el ordenador, la documentación está en el ordenador, ….

Lo lamentable es que esto no es una anécdota, es un mal muy extendido.

Un extraño sentido de “ahorro” provoca que en muchas empresas de tecnología (y de muchos otros tipos) no haya habitualmente recambios, ordenadores de repuesto o que, desde que se incorpora un empleado a la empresa hasta que se le suministra el ordenador pueda pasar 1 semana (o hasta dos semanas).

Dado que en la mayoría de las empresas las compras de equipos suelen estar normalizadas y se compra una cierta cantidad de ordenadores de la misma marca y modelo, parece razonable pedir una serie de cargadores adicionales, válidos para todos (o casi) todos los equipos, de forma que, ante cualquier avería, en menos de un minuto se remplace el elemento averiado si perder ni un minuto. Según la calidad estimada de los equipos comprados, quizá un cargador adicional por cada 10 o 20 equipos. En el peor de los casos, suponiendo que nunca se estropee ninguno, se habrá gastado un poco de dinero, en el mejor, se habrá ahorrado miles de euros a la empresa.

Pero aún se puede ir “más lejos” en cuanto a evitar pérdidas de tiempo con una pequeña inversión. A raíz del incidente que citaba inicialmente, recuerdo que un compañero me comentó que en su empresa anterior, se entregaban AUTOMÁTICAMENTE, con cada portátil, DOS cargadores. De forma que uno se dejara fijo en la oficina y otro estuviera siempre en el maletín del portátil. Esto ahorra:

• el estar colocando y recogiendo el cargador cada vez que se llega a la oficina,
• el riesgo de olvidar el cargador y solo poder trabajar 2 horas fuera (en cliente, reuniones,   guardias o incidencias),
• por supuesto las posibles averías del cargador, etc.

Simplemente 1 minuto diario de ahorro para conectar el cargador implicaría 220 minutos/año lo que amortiza sobradamente los 20€, sin contar el resto de factores, que no son en absoluto desdeñables.

Esto ocurre con un elemento aparentemente menor y trivial. Si pensamos en el ordenador de trabajo, el efecto es mucho mayor. Suele darse dos “ahorros” habituales:

1. No tener equipos disponibles de reserva, tanto para las nuevas incorporaciones como para posible averías
2. Tener equipos poco potentes.

En cuanto a no tener equipos de reserva ya preparados e instalados con las aplicaciones licenciadas y habituales de la empresa, tanto para entregarlos a los nuevos empleados como para dar un equipo temporal de sustitución, es un mal muy extendido. Conozco empresas donde se tarda en entregar el nuevo equipo una semana y hasta un mes. De nuevo aplicando los cálculos anteriores, contando con 200€/día * 5 días, se pierden 1.000€ /semana y 4.000€/mes. De nuevo sin contar otros costes como impacto en otras personas, retrasos, mala imagen, descontento del empleado,... Estas pérdidas aplicarían tanto a los casos en que no se tiene un equipo preparado para los nuevos empleados como los casos de averías.

Respecto al ahorro en la compra de los equipos, tiende a comprarse equipos “económicos“ para todos los empleados, y, aunque esto puede ser válido para los que solo realizan tareas ofimáticas, no lo es para una gran parte de las tareas habituales hoy en día, desarrollo, diseño, edición, calculo, administración, etc. Por ejemplo programando aplicaciones es necesario compilar con mucha frecuencia, instalar servidores de aplicaciones o de bases de datos en el ordenador personal, arrancar un simulador de móvil, etc. Son tareas que llevan mucho tiempo, requieren ordenadores potentes y que en muchos casos obligan al usuario a esperar en diversas tareas (compilación, despliegue, realizar pruebas automáticas, etc.)

Un equipo que permita trabajar un 1% más rápido (algo no muy difícil: CPU Benchmark, Disco duro vs Disco de estado solido) implica ganar/ahorrar 2 días/año, es decir 400€. Con una amortización de 3 años implica 1.200€. Es decir una ganancia de solo un 1% justificaría gastar 1.200€ mas, y desde luego esa no es la diferencia de precio entre equipos con un 1% más de potencia.

Por shigeru23 [GFDL (http://www.gnu.org/copyleft/fdl.html) undefined CC BY-SA 3.0

Dado que el ahorro que se consigue invirtiendo un poco en recambios y equipos más potentes parece evidente, ¿Por qué no es la norma? (al menos según mi experiencia y la de muchas personas que conozco)

Creo que hay varios motivos:

• Por una parte hay entidades en las que probablemente no se hacen los cálculos y se piensa, sin más análisis, que “tener unas fuentes de alimentación y unos ordenadores ‘sin usar’ es un derroche, hay que ahorrar y gastar lo menos posible”.
• Posiblemente hay empresas que esperan que los empleados compensen las carencias de equipamiento con un esfuerzo extra: “Tendrás que trabajar este fin de semana para compensar esos días que has tenido el equipo estropeado”, “Esto tiene que estar en fechas, aunque haya que quedarse a cenar tiene que estar compilado y probado”,.. (lo que a la larga tiene otro coste mayor, descontento, pérdida de conocimiento cuando los empleados se “queman” y se van, y mala calidad por las prisas e imposibilidad de probar para entregar a tiempo).
• Por último, creo que hay otro motivo, debido a la conversión de muchas instituciones en “reinos de taifas”, ya sea por el modelo organizativo y contable simplemente o porque determinados servicios se contraten a una empresa externa. Si un departamento tiene que dar un servicio (como ofrecer equipos informáticos) y únicamente se evalúa como criterio los costes de ese departamento, evidentemente cuanto menos gaste y menos tenga inmovilizado, tanto en potencia como en recambios, mejor. Si a ese departamento no se le aplica un acuerdo de nivel de servicio (S.L.A.) adecuado, que implique por ejemplo que ningún empleado podrá estar sin equipo más de dos horas, o que un proceso normal de trabajo (compilación, diseño, etc.) debe realizarse en menos de un tiempo X, lógicamente se está potenciando el ahorro y considerando como “eficaz” ese departamento, a costa de penalizar a los demás departamentos de la entidad.
  
  

Automatización y Robots (Firma Invitada)

Por su extensión y elaboración incluyo como nueva entrada una serie de reflexiones sobre la entrada anterior ( http://pensamientocriticoti.blogspot.com.es/2017/05/es-posible-cobrar-impuestos-los-robots.html ) recibidas del profesor de la Facultad de Ciencias de la Documentación de la UCM. Manuel Blazquez Ochando:

Es un asunto muy polémico querido amigo.

Es un hecho que podemos dar por sentado, que en un futuro la automatización tiende a informatizar y robotizar todo tipo de procesos, para los que actualmente se necesita una persona. Uno de los personajes que ha defendido ésta postura es Bill Gates (http://www.expansion.com/economia-digital/protagonistas/2017/02/18/58a89ca3e5fdeafa0c8b4587.html). Inherente al pensamiento aritmético que lo caracteriza, propone una solución fiscal que evite el desastre que puede producir la pérdida masiva de empleos, en lo que ya se conoce como 4ª Revolución Industrial. Por poner un ejemplo, el desarrollo de vehículos autónomos y en concreto camiones (https://www.xataka.com/vehiculos/el-camion-electrico-de-tesla-sera-presentado-en-septiembre), puede revolucionar el sector del transporte, a favor de las grandes empresas logísticas y en detrimento de los trabajadores que verán desaparecer su forma de vida. Pero para responder adecuadamente a un asunto tan complejo como espinoso, habría que retroceder en el tiempo y recordar para qué se creó la informática y la robótica. Fundamentalmente para descargar a las personas de tareas repetitivas, pesadas, difíciles, o que requirieran de un esfuerzo físico importante…
En resumen, la informática y la robótica se desarrollaron para ayudar al ser humano y no para sustituirlo. Sin embargo, el avance de la ciencia en estos sectores ha superado o va a superar al avance del ser humano en economía, política, finanzas y gobernanza.

Bundesarchiv, B 145 Bild-F078958-0021 / CC-BY-SA 3.0 [Wikimedia Commons]

Lancemos esta pregunta… ¿qué ocurre si se desarrollan robots y software para hacer casi todas las tareas? 
Ocurrirían varias cosas:

1. Las profesiones más demandas serían las ingenierías, informática y robótica principalmente. 
2. De forma gradual se perderían empleos y obligaría a una reconversión formativa, de caracter forzoso, de las personas afectadas, creando un panorama de crisis social y exclusión. 
3. Los beneficios se maximizarían para las empresas. 
4. No necesariamente los gobiernos aplicarían impuestos (Aunque sería deseable) ya que dependen de esas empresas que invierten en el país. 
5. Como resultado de la pérdida de empleo y una menor recaudación fiscal, sería probable un empobrecimiento de la población y una mayor brecha social (Este es el riesgo que todos tememos). 

De este panorama más trágico que favorecedor, podrían sucederse fenómenos de oportunidad. Normalmente el ser humano se caracteriza por su capacidad de adaptación. Quizás esto implicaría un cambio en la forma de pensar, en relación al emprendimiento. No sería descartable que las personas afectadas, intentaran emprender con ideas originales para tratar de competir con el fenómeno de automatización, incluso sirviéndose de sus frutos. Aunque ello conllevaría a que la competencia aumentara considerablemente, provocando una lucha por la supervivencia. Para ello se necesitaría un bien fundamental, el dinero, la financiación, los fondos y el mercado disponible.
No logro imaginar hasta cuánto tiempo será posible mantener este modelo. Lo que sí entiendo es que no todos lograrán mejorar su nivel de vida, si no se producen cambios profundos en el esquema de valores y de gestión a nivel mundial. Algunas ideas de las que se vienen hablando derivan en el salario universal (https://www.xataka.com/empresas-y-economia/finlandia-y-holanda-empezaran-a-experimentar-con-un-sueldo-minimo-universal-espana-se-plantea-implantarlo).
También se habla de la desaparición del dinero “Físico” (http://aristeguinoticias.com/0807/kiosko/preven-la-desaparicion-del-dinero-fisico-en-todo-el-mundo/) y del miedo de los bancos a las monedas virtuales (https://www.oroyfinanzas.com/2016/03/por-que-bancos-tienen-miedo-blockchain-bitcoin/).

Por Satoshi Nakamoto (maybe a nickname), Gavin Andresen, Amir Taaki, Luke Dashjr, Pieter Wuille, Nils Schneider, Jeff Garzik, Wladimir J. van der Laan, Gregory Maxwell, and others. (JimNelin (screenshot taker)) [MIT (http://opensource.org/licenses/mit-license.php)]

Queda patente que los grandes conglomerados y esferas de decisión tienen en cuenta todos estos parámetros, el avance de la automatización en todos los campos, la sustitución de las personas por robots, las crisis sociales que se producirán, las amenazas que representan los cambios de modelo financiero, la pérdida de control sobre el dinero. Creo que estos asuntos conforman la unidad de lo que está por venir. De hecho, todo ello desemboca en la idea de “Gobierno Global” (https://www.xataka.com/robotica-e-ia/un-gobierno-mundial-la-idea-de-stephen-hawking-para-que-el-avance-tecnologico-no-acabe-destruyendo-la-especie-humana)

Al final, en este tema de debate cabrían más preguntas que respuestas.

¿La automatización y el avance de la inteligencia artificial, la informática y la robótica, forzarán un cambio en el paradigma económico, financiero y gobernativo?
¿Se adaptará el actual modelo, basado en el capital, y logrará sortear la amenaza, aplicando impuestos a la automatización?
¿En caso de hacerlo, se proporcionará el margen de beneficios suficiente para las empresas?
¿Qué impacto tendrá en la sociedad, será fácil de controlar o surgirán efectos colaterales no esperados?
¿Se refundará el modelo de capital y de retribuciones salariales para salvaguardar la paz social?
¿Es el gobierno global la solución?
¿Cómo se organizará el trabajo en el futuro?

Y muchas más…


Manuel Blazquez Ochando
http://mblazquez.es/

¿Es posible cobrar impuestos a los robots?

Últimamente se viene hablando mucho de “cobrar impuestos por los robots” (http://economia.elpais.com/economia/2016/10/16/actualidad/1476612103_361082.html, http://www.elmundo.es/tecnologia/2017/02/20/58aab904ca4741657a8b45dd.html, http://www.ciat.org/index.php/blog/item/354-%C2%BFimpuestos-sobre-los-robots , ..) como forma de contrarrestar  la sustitución en los puestos de trabajo de personas por robots. Según esos planteamientos, se trataría, por ejemplo, de declarar/registrar el número de robots que tiene una empresa y en base a ello cobrar una serie de tasas o impuestos.

Sin embargo, creo que es una medida prácticamente imposible por diversos motivos, el principal de ellos, la dificultad de definir qué es un robot, dónde “empieza” y dónde “acaba”. 

Robot Humanoide (By Chris 73 / Wikimedia Commons, CC BY-SA 3.0)

 

¿Que es un robot?

Según Wikipedia ( https://es.wikipedia.org/wiki/Robot ) “Un robot es una entidad virtual o mecánica artificial. En la práctica, esto es por lo general un sistema electromecánico que normalmente es conducido por un programa de una computadora o por un circuito eléctrico”

Tendemos a pensar en “robot” como una máquina humanoide (con piernas, brazos, cabeza y proporciones similares a una persona) de propósito general, es decir, que puede sustituir a una persona en cualquier función (conducir, atornillar, recoger,..) , pero el robot humanoide es un caso muy particular de robot, de los muchos que puede haber, y ni siquiera tiene por qué ser el más adecuado para una tarea, el más rentable o el que más personas puede sustituir.
 

Cadena de Montaje (By Ford Motor Company - http://www.flickr.com/photos/fordmotorcompany/2553781422/in/set-72157605431224378/, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=5297002)

Las cadenas de montaje de muchas industrias, especialmente en automoción,  llevan años robotizadas utilizando brazos articulados que realizan operaciones más o menos automáticas (cada vez más automáticas al irse añadiendo sensores de diverso tipo que permiten reconocer el entorno y tomar decisiones “inteligentes”). Es decir nos podemos olvidar de que, en muchos casos, veamos una “persona metálica” en el puesto de una persona, ya que los procesos y procedimientos de todo tipo puede mejorarse para ser más eficientes (creando “brazos muy largos”, cuerpos casi inexistentes, “manos con ojos ”, etc.).

Desde luego, el incluir que se “traslade” no es significativo, ya que podemos tener sistemas muy sofisticados y dotados de inteligencia (como cadenas de montaje) que no se mueven de su sitio, y por otra parte hay sistemas como los llamados “robots aspiradores” que se mueven de forma autónoma aspirando por toda la casa, pero que desde luego no tienen apenas inteligencia y no merecen el apelativo real de robots.

Si no se puede contar “máquinas humanoides” ni  contar “sistemas que se desplacen”...

¿Se puede plantear contar al menos  “brazos”?  

El problema es que muchos sistemas pueden no tener “brazos”, sino rampas, compuertas, incluso aunque lo tengan, no siempre tendrán forma de “brazo”, y aunque tengan forma de brazo pueden no tener “inteligencia”. Puede ser un brazo controlado por un humano para manejar cargas pesadas o peligrosas (como en instalaciones nucleares). Además, ¿Cuantos brazos determinan  UN robot? Un robot puede tener 1, 2 3 o n brazos controlados por un solo “cerebro”. O utilizar las “piernas” como “brazos”. ¿Pagaría lo mismo un “robot” con 1 brazo que con 3?. Y si el brazo tiene 4 manos productivas? 

Robot para cirugía (By Nimur at the English language Wikipedia, CC BY-SA 3.0)

Y por supuesto, no podemos olvidar los “coches autónomos”. Un coche autónomo requiere una gran “inteligencia” para poder tomar decisiones rápidamente, gran cantidad de sensores (sentidos) y es una tecnología que seguramente reemplazará muchos empleos actuales (taxistas, conductores de autobús y camión, ..), sin embargo no es muy probable que veamos una máquina humanoide sentada al volante. En los coches autónomos, todo el coche es un “robot”, con la inteligencia, los sensores y todos los mecanismos embebidos en la estructura.

Coche autónomo (De Mariordo (Mario Roberto Durán Ortiz) - Trabajo propio, CC BY-SA 4.0 )

El plantear un inventario desde el punto de vista de la “inteligencia”, independientemente de su forma tiene varios problemas. Por una parte, potencialmente cualquier ordenador o incluso móvil que maneje algún elemento mecánico entraría en esa categoría (ya hemos descartado la movilidad o el aspecto humanoide) , ya que  cuenta con un procesador y elementos que interactúan. Incluso una Raspberry ( https://es.wikipedia.org/wiki/Raspberry_Pi ) o una impresora 3D (https://es.wikipedia.org/wiki/Impresora_3D) podría entrar en esa categoría. Ello sin contar con que podría “quitarse y ponerse” los elementos mecánicos, y entonces tendríamos un ordenador “normal”, sobre los cuales no existe actualmente “impuesto robot”, por lo que la contabilización sería difícil. 
El otro problema es ¿cómo contar “cabezas”? Los procesadores tienen múltiples núcleos que pueden realizar procesos diferentes. Además, un mismo ordenador físico puede estar simulando varios ordenadores virtuales, o un ordenador virtual puede estar desplegado “en la nube”. Y desde luego, un ordenador (virtual o no), según su potencia podría estar controlando cientos de mecanismos simultáneamente.

Mini robots. Swarn Robots (By Farshadarvin - Own work, CC BY-SA 4.0)

Para acabar de complicar las cosas hay muchos proyectos e iniciativas de construcción de múltiples mini-robots” con una inteligencia “colectiva” capaces de trabajar en equipo para conseguir tareas complejas. (http://www.bbc.com/mundo/noticias/2014/08/140815_tecnologia_enjambre_robots_kilobots_ch , https://en.wikipedia.org/wiki/Swarm_robotic_platforms ) ¿Se deben considerar un único robot? ¿varios? ¿un robot cada docena de mini-robots?.

Posiblemente los robot humanoides se verían más en usos no productivos (Ej.: ayudas a domicilio para personas con limitaciones de movimiento) donde sí interesa una figura humanoide que se mueva por entornos muy variables y maneje los mismos objetos que una persona y para pymes cuyo volumen no justifica tener robots especializados (Ej.: un robot conduce un vehículo, carga paquetes, pinta y sierra) sino utilizar un robot de propósito general.

Entonces, ¿sobre qué cobrar impuestos?

Por tanto, debemos descartar el contar “máquinas humanoides que se traslade de forma autónoma y cuentan con cerebro/inteligencia y sentidos para percibir el entorno” por unas instalaciones para poder aplicarles un impuesto.

 El plantearse como medida los puestos de trabajo a los que DIRECTAMENTE  reemplaza llevaría por extensión a plantearse que cualquier ordenador, un tractor o una cosechadora han reemplazado directamente puestos de trabajo, ya que una sola persona, con la ayuda de esos elementos, hace el trabajo que antes hacían 5 o 10. De hecho, el Metro de Madrid acaba de anunciar el plazo de cierre para 2018 de las últimas taquillas, sustituidas por las máquinas expendedoras de billetes, máquinas que no pueden considerarse robots ¿o sí?. 
Un ejemplo de futura sustitución son las pruebas de impresoras 3D de construcción, que IMPRIMEN una casa completa (http://www.expansion.com/economia-digital/innovacion/2016/12/05/58416f92468aeb59758b4591.html , http://www.ticbeat.com/tecnologias/imprimen-una-casa-integramente-en-3d-sobre-el-terreno-en-solo-24-horas/ ,  http://www.youtube.com/watch?v=OYqBxEAtXZA ), que evidentemente puede sustituir a una cuadrilla completa.

La imposibilidad de acotar o cuantificar, salvo excepciones que serían un agravio comparativo, qué es un robot creo que justifica plantear una medida indirecta, y esa podría ser una ponderación de los impuestos de empresa (Sociedades, IVA,..) “per cápita”, es decir por empleado. 

Esta ponderación reflejaría el grado de robotización/automatización general de la empresa, lo que abarcaría los distintos tipos de grados de máquinas y robots, y premiaría bonificando a las empresas que, a igualdad de beneficios,  empleen más personal, consideradas “socialmente más responsables” al crear más empleo.

Esta medida, aplicada directamente, perjudicaría a las empresas que gracias a la organización y procedimientos, no a la sustitución de personas por máquinas o robots, obtienen más beneficios. Para ello debería ponderarse igualmente lo invertido en maquinaria (activos, material mobiliario, etc.) de forma negativa, es decir, a igualdad de beneficios y personal una empresa con más maquinaria tendría una carga impositiva mayor. Esto además en principio primaría a las empresas más “medioambientalmente responsables”, ya que requiere menos maquinaria que hay que producir y finalmente hay que reciclar, utilizando recursos naturales.

Un efecto colateral de este modelo es que penalizaría las empresas puramente especulativas o intermediarias, que con muy poco personal obtienen grandes beneficios.

En cualquier caso, el  tema es muy complejo y obligará durante mucho tiempo a reflexionar y debatir sobre él.