Hoxe en día rexe a computación de propósito xeral pero, hai décadas, había unha plataforma para cada finalidade. Unha empresa pequena tería un ordenador pequeno cun lector e furador de tarxetas, mentres que unha grande tería un ordenador grande con moitos terminais, un departamento de física dunha universidade tería un computador vectorial e Correos tería varios computadores conectados mediante liñas telegráficas. Todo iso, por suposto, con código escrito especificamente para eles en COBOL, Fortran, PL/I ou o que fora.
Pouco a pouco, segundo os ordenadores se fixeron máis potentes e máis baratos, todo comezou a homoxeneizarse ata o punto de que agora aparenta ser todo o mesmo: usamos Linux tanto nos supercomputadores máis potentes como nas Raspberry Pis máis barateiras, programamos todo nas mesmas cinco linguaxes e todos os programas novos funcionan no navegador ou no móbil.
Antes, seleccionar e deseñar a plataforma era esencial; agora semella que non importa que plataforma escollamos, porque todo vai funcional igual. Isto, por suposto, é unha ilusión. A plataforma aínda importa xa que determina as capacidades do noso programa e a maneira na que o vamos usar, e debemos ter moito coidado ao seleccionala porque pode marcar toda a diferenza entre un éxito e un fracaso.
No meu primeiro traballo pedíronme que avaliara varios CMS para facer un portal web informativo. Por non me estender de máis, só vou dicir que a miña selección foi un desastre: pasamos máis tempo loitando coa plataforma e buscando trucos para evitar as súas limitacións que facendo o portal polo que nos contrataran, e non era porque nós foramos parvos, xa que despois de varias semanas pelexando con el, mudamos de CMS e o proxecto saíu adiante.
Ás veces, a uniformidade que temos hoxe en día impídenos usar as plataformas máis axeitadas para os nosos obxectivos. Por exemplo, antes tiñamos linguaxes de programación especializadas para distintas tarefas, comezando polos xa mencionados COBOL e Fortran, pero tamén outras como xBase para aplicacións CRUD en microcomputadores, Visual Basic para RAD ou PHP para aplicacións web.
Agora, en cambio, temos cinco linguaxes que usamos tanto para facer sistemas operativos como aplicacións web, xogos, sistemas de aprendizaxe automática e enredos na Raspberry Pi. O malo de que estas linguaxes sirvan para todo é que non son especialmente boas para nada: unha aplicación web é moito máis doada de facer en PHP que en calquera desas linguaxes, e no tempo no que fas unha aplicación CRUD en calquera delas, fas cinco en xBase.
Non é só nas linguaxes onde a uniformización ten efectos nocivos. Temos moitos frameworks, bibliotecas e ambientes de escritorio que nos fan a promesa de que podemos escribir unha aplicación unha soa vez e usala en todas as plataformas. Web, móbil e escritorio? Por suposto. Linux, Windows e Mac? É escusado preguntar. Android e iOS? A dúbida ofende.
Todos estes sistemas teñen o mesmo problema, porén: as aplicacións feitas neles nunca funcionan tan ben como as aplicacións nativas para cada plataforma. Son máis lentas, ocupan máis espazo no disco e na memoria, non teñen acceso a todas as capacidades que cada plataforma ofrece e (o máis importante de todo) teñen unha aparencia e comportamento inconsistente coa plataforma na que corren.
Non sei vós, pero estou farto de ver aplicacións móbiles que non son máis que páxinas web glorificadas, aplicacións en Android que non saben que existe o botón de “atrás” ou programas de Mac deseñados como se foran de Windows.
Hoxe en día, coa uniformidade imperante, é moi fácil caer na tentación de pensar que as plataformas xa non importan. Pois non: importan igual que sempre. Escollede ben e tratade de sacarlle todas as avantaxes.
1 comentario