segunda-feira, 24 de dezembro de 2012

Por que eu realmente não gosto do MATLAB

Acredito que todos que me conhecem saibam que eu realmente não gosto do MATLAB e já tenham me ouvido expressar meu desprezo por ele. Não deveria (afinal, ele é o ganha-pão da área onde eu trabalho), mas deixo isso bem claro toda vez que eu falo sobre ele. Vamos a alguns motivos:

Primeiro: a linguagem dele é péssima, tanto é que surgiram infinitos 'hacks' em cima. Impossibilita código limpo, por não ter coisas como uma boa implementação de argumentos nomeados, namespaces e uma orientação a objetos de verdade.

E por sinal, uma das maiores (na minha opinião) abominações é que o arquivo de código (.m) precisa mandatoriamente ter o mesmo nome da primeira função neste presente. Porque aparentemente includes são luxo: imaginem uma linguagem C onde em vez de stdio.h tivéssemos printf.h, scanf.h, etc...? Legal, só que não.

Segundo:
ambiente proprietário, bugado, com pouca integração com o resto do sistema, lento (quem foi o jênio que teve a ideia de que Java era uma boa ideia? Qual o problema com C/GTK ou C++/Qt?) e limitadíssimo. Várias vezes ele simplesmente acusou um fatal error no meio do trabalho e depois fechou.

Terceiro: limitações imbecis. Outro dia eu implementei um algoritmo que beneficiaria extremamente de processamento paralelo (tenho um i7, e não é justo que eu só consiga ocupar um dos núcleos). Para isso existe a toolbox de processamento paralelo do MATLAB, mas adivinhem a limitação completamente burra que existe: um "for" paralelizado só funciona quando o iterador é inteiro.

Tirando da própria documentação dele:

parfor loopvar = initval:endval, statements, end allows you to write a loops for a statement or block of code that executes in parallel  [....] initval and endval must evaluate to finite integer values [...].

Em tradução livre: parfor var_loop = val_inicial:val_fim, comandos, end" permitem você escrever um loop para um conjunto de comandos que executa em paralelo [....] val_inicial e val_fim precisam ser números inteiros [...] (grifo meu)

Sim, é isso mesmo: ou o loop só itera sobre números inteiros ou eu subutilizo minha CPU. Uma limitação totalmente arbitrária. Claro que vão aparecer gambiarras diversas para contornar a limitação: sinal de um sistema mal-projetado.

E principalmente: a maioria das pessoas usa ele por não ter que comprar a licença (afinal, tem no Pirate Bay ou é só pedir o DVD pra um dos colegas). Se tivessem que pagar por cada toolbox  - não, ele não vem com esse monte de toolboxes (eu queria ver o custo de cada uma, mas preciso preencher um cadastro que realmente não estou animado a fazer) - queria ver se existiria tanta babação de ovo em cima dele. Queria ver se professores iriam montar cursos inteiros em cima dele, ou se haveria tanta gente usando ele para mestrados e doutorados.

Aliás, queria ver se o pessoal ia defender software proprietário tão descaradamente e ia ficar nessa preguiça de procurar alternativas se não fosse fácil assim piratear. Mas isso é assunto para outro post. Lembrem, enquanto isso, das discussões sobre a necessidade de fazer ciência com software livre e formatos abertos.

Existe a versão para estudante? Sim, que é uma piada de mau gosto: limitadíssima. Só 32-bit (quase em 2013, quando qualquer computador atual já vem com SO 64-bit) e com recursos desativados. Comparar com a versão para estudante do Mathematica: nenhuma limitação técnica - apenas restrições contratuais de uso (não pode explorar comercialmente, precisa fornecer comprovante de que é estudante etc...).

Quanto à questão das licenças, podem me perguntar: e o Octave? e o Scilab?. Ambos imitações que copiam os vícios da linguagem de inspiração. Imitar uma coisa ruim torna a imitação igualmente ruim - se não pior.

Enquanto isso, fico com o Python e a comunidade fantástica que existe ao redor dele. Se eu tiver que usar um software científico proprietário, fico com o Mathematica - que, apesar da estranheza da linguagem, entrega muito mais valor pelo mesmo preço (várias das toolboxes que são opcionais no MATLAB estão incluídas por padrão nele). Minha 'loja' de toolboxes é o PyPI, o GitHub etc...  Considere o Python para seu próximo projeto, não dói nada (principalmente para quem vem do MATLAB: a NumPy, SciPy etc... são projetadas para fornecerem um ambiente de fácil adaptação).

PS: no quarto parágrafo, a escrita errada de jênio foi intencional.

2 comentários:

  1. Bem, eu tambem nao sou muito fã do matlab, mas os seus "motivos" tem algumas falhas:

    1) Um .m é equivalente a um shell script, ou a um arquivo de lotes do windows, é apenas um conjunto de commandos de uma shell, pra serem executados de uma vez só. Para coisas mais elaboradas você deve escrever seu codigo em C ou fortran, e compilar com o mex. a linguagem de script eh só uma "cola", apesar de geralmente ser usada pra tudo

    2) Se o matlab nao fosse em java, provavelmente nem existiria versao pra linux/os x. Manter a portabilidade da GUI é facil, mas as particularidades dos sistemas operacionais nao sao abstraidas decentemente pelo GTK e pelo Qt. O Qt é o que está mais proximo disso, e pode vir a substituir o Java nas aplicações "enterprise" multi-plataforma, mas eu acho que ainda vai levar um tempo.

    3) Laços 'for' com indice inteiro são uma limitação da "computação paralela", nesse caso nao é culpa do matlab. Para paralelizar um laço vc tem que ser capaz de prever perfeitamente o numero de iterações, e todos os valores que o indice vai ter durante a execução, pois o laço nao vai ser executado de maneira sequencial, onde você pode ver a "progressão" do indice e dos valores calculados de acordo com as iterações. Qualquer iteração que nao tenha estado garantido e/ou dependa do estado da iteração anterior nao pode ser paralelizada, ao menos a nivel de laço. Voce pode "isolar partes" do codigo que nao dependam umas das outras e rodar em paralelo, mas geralmente nao vale muito a pena. Mas enfim, não é uma limitação arbitrária. :)

    O resto eu concordo. Tambem nao gosto da quantidade de "trabalhos" que tem sido feitos e publicados porcamente usando o matlab. Essas pessoas geralmente não sabem usar nem o que o matlab tem a oferecer, muito menos outra coisa melhor.

    ResponderExcluir

Não são lidos e não me responsabilizo pelo conteúdo deles.