O título do post (e a tradução do acrônimo BASIC, Begginer’s All-purpose Symbolic Instruction Code) não poderiam estar mais errados!

Vamos abrir o blog com um artigo de desmitificação sobre meu assunto predileto: BASIC!

Creio que 102% dos meus amigos e conhecidos são programadores… a grande maioria (diria 99.9%) programam em C#, alguns, como o ilustríssimo grande palestrante Fábio Galuppo é mais… hmmm… radical… e programa em F# e C++ (aliás, é MVP C++), e, é óbvio, em se tratando de programação sou a ovelha-negra dos amigos, aquele que recebe as piadinhas infames que todo programador VB recebe.

Hora do payback >=)

Desmitificando o BASIC

Maturidade

Poucas pessoas sabem disso, mas o BASIC foi criado 8 anos antes do C! Há ótimos artigos no Wikipédia sobre as duas linguagens e lá está toda a história delas (podem verificar as datas). Eu sempre colocarei links aqui do Wikipédia em inglês, pois os artigos em português infelizmente não possuem nem um décimo da qualidade de suas contrapartes em inglês, mas, é muito fácil ver o artigo em português apenas trocando o link de http://en.wik… para http://pt.wik… Então aqui vão os dois links: BASIC (1964) e C (1972).

Tipagem Fraca

Esses dias eu estava vendo alguns slides da Microsoft sobre o futuro do Visual Studio. Nos slides está bem clara a tendência do .net framework de partir para linguagens dinâmicas, onde há a possibilidade de se resolver tipos em runtime. Surpresa! VB, apesar de não ser uma linguagem dinâmica no momento, já possui certos conceitos de dinamismo há décadas.

Em VB nós temos sempre o poder da escolha. Eu posso escolher que a tipagem seja resolvida em runtime ou poder usar uma tipagem do tipo Duck Typing (da mesma forma que C# pode usar Object com este intuito), mas eu também posso ligar o modo Strict (Option Strict On) e ser mais fortemente tipada do que C#! Não acredita? Tente executar o seguinte código em C#:

String variavel = "Olá " + 3.1415

E não é que ele compila sem problemas? Agora tente fazer o mesmo com VB com Option Strict On e… bum… o compilador acusa erro e você sequer consegue rodar o projeto (a menos que altere o código para

Dim variavel = "Olá " & 3.1415

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

(e, não, não estou usando tipagem fraca no exemplo acima, e sim inferência!)

Mas, qual a utilidade disso? COM, especialmente. Tente utilizar o maravilhoso componente Office Web Components em C# e terá má supresas =(

Redim Preserve ECAAA

Essa eu nunca entendi… várias pessoas reclamam de BASIC porque ele possui um comando que redimensiona um array, preservando seu conteúdo (note que isso é diferente de simplesmente declarar um novo array, os dados são mantidos!).

Duas frases para estas pessoas:

1. O .net framework possui um Redim Preserve. Basta fazer Array.Resize.
2. Outra forma de se fazer isso (e creio que Array.Resize só foi implementado no .net 2.0) seria criar um novo array, copiar o conteúdo deste via Array.Copy ou Buffer.BlockCopy e descartar o anterior. Várias linhas de código que poderia ser resumida em 1!

Se está pensando “Ah, mas eu usaria ArrayList ou List<T> e não teria este problema”, engana-se, porque listas em .net são implementadas com arrays que são redimensionados sempre que sua capacidade é excedida, justamente com um Redim Preserve, duplicando o tamanho do array!

É muito importante lembrar que não existe magia em programação. É óbvio e inegável as vantagens e facilidade de uso de listas (collections), porém não podemos nos esquecer que, por trás dos bastidores, eles funcionam com tipos primitivos (neste caso, um Array). Será que sempre duplicar o Array quando a capacidade é alcançada é algo bom? Se quiser mais detalhes sobre a performance de redimensionamento de arrays e a diferença de performance entre arrays e listas, acompanhe este post.

Verbosidade

Aqui entramos em uma questão de gosto (ainda mais quando temos intellisense no VisualStudio). Só para cutucar onça com vara curta, VisualBasic é a única linguagem que implementa 100% de intellisense no VisualStudio (maiores informações no blog oficial do VB).

Vamos fazer alguns testes básicos:

1. public class foo:bar

   .csharpcode, .csharpcode pre
   {
   font-size: small;
   color: black;
   font-family: consolas, “Courier New”, courier, monospace;
   background-color: #ffffff;
   /*white-space: pre;*/
   }
   .csharpcode pre { margin: 0em; }
   .csharpcode .rem { color: #008000; }
   .csharpcode .kwrd { color: #0000ff; }
   .csharpcode .str { color: #006080; }
   .csharpcode .op { color: #0000c0; }
   .csharpcode .preproc { color: #cc6633; }
   .csharpcode .asp { background-color: #ffff00; }
   .csharpcode .html { color: #800000; }
   .csharpcode .attr { color: #ff0000; }
   .csharpcode .alt
   {
   background-color: #f4f4f4;
   width: 100%;
   margin: 0em;
   }
   .csharpcode .lnum { color: #606060; }

2. public ~foo()

   .csharpcode, .csharpcode pre
   {
   font-size: small;
   color: black;
   font-family: consolas, “Courier New”, courier, monospace;
   background-color: #ffffff;
   /*white-space: pre;*/
   }
   .csharpcode pre { margin: 0em; }
   .csharpcode .rem { color: #008000; }
   .csharpcode .kwrd { color: #0000ff; }
   .csharpcode .str { color: #006080; }
   .csharpcode .op { color: #0000c0; }
   .csharpcode .preproc { color: #cc6633; }
   .csharpcode .asp { background-color: #ffff00; }
   .csharpcode .html { color: #800000; }
   .csharpcode .attr { color: #ff0000; }
   .csharpcode .alt
   {
   background-color: #f4f4f4;
   width: 100%;
   margin: 0em;
   }
   .csharpcode .lnum { color: #606060; }

3. if(foo = bar = 10)

   .csharpcode, .csharpcode pre
   {
   font-size: small;
   color: black;
   font-family: consolas, “Courier New”, courier, monospace;
   background-color: #ffffff;
   /*white-space: pre;*/
   }
   .csharpcode pre { margin: 0em; }
   .csharpcode .rem { color: #008000; }
   .csharpcode .kwrd { color: #0000ff; }
   .csharpcode .str { color: #006080; }
   .csharpcode .op { color: #0000c0; }
   .csharpcode .preproc { color: #cc6633; }
   .csharpcode .asp { background-color: #ffff00; }
   .csharpcode .html { color: #800000; }
   .csharpcode .attr { color: #ff0000; }
   .csharpcode .alt
   {
   background-color: #f4f4f4;
   width: 100%;
   margin: 0em;
   }
   .csharpcode .lnum { color: #606060; }

4. public abstract class foo

   .csharpcode, .csharpcode pre
   {
   font-size: small;
   color: black;
   font-family: consolas, “Courier New”, courier, monospace;
   background-color: #ffffff;
   /*white-space: pre;*/
   }
   .csharpcode pre { margin: 0em; }
   .csharpcode .rem { color: #008000; }
   .csharpcode .kwrd { color: #0000ff; }
   .csharpcode .str { color: #006080; }
   .csharpcode .op { color: #0000c0; }
   .csharpcode .preproc { color: #cc6633; }
   .csharpcode .asp { background-color: #ffff00; }
   .csharpcode .html { color: #800000; }
   .csharpcode .attr { color: #ff0000; }
   .csharpcode .alt
   {
   background-color: #f4f4f4;
   width: 100%;
   margin: 0em;
   }
   .csharpcode .lnum { color: #606060; }

Às perguntas:

1. bar representa uma classe ou uma interface? É claro que é padrão comum toda interface iniciar com I, mas essa é uma regra facilmente "quebrável". Não vejo porque escrever Public Class foo Inherits algo Implements bar seja pior, já que estamos deixando as coisas extremamente claras!
2. Este código representa um Destructor! Ora, como não vi antes! ~ de Destructor. Claríssimo! (E sim, isso é sarcasmo, he he he)
3. Ahh… como é que é? Esta linha na verdade associa o valor 10 à variável bar e depois o valor de bar à variável foo e a operação booleana (requerida pelo if) resultante disso é, sinceramente não faço a mínima idéia!
4. Classe abstrata. Ou método virtual. Ok… Precisamos de um dicionário técnico para aprender a programar… ou… podemos ser mais humanos e declarar classes abstratas como Public MustInherit Class (Must Inherit = Deve ser Herdada) e Public MustOverride Sub (Must Override = Deve ser Sobreescrita). O mesmo ocorre para outros casos como public new string foo() que em VB fica como Public Shadows Function foo() As String, indicando que este método oculta (shadows) sua contraparte na classe base

Pode ser algo comigo somente, mas gosto de coisas lógicas e que eu não tenha que decifrar o que diabos aquele monte de símbolos significa (por outro lado sou EXTREMAMENTE péssimo em C++ e F#).

C# é mais rápido que VB (ou vice-versa)

Isso vamos cobrir em um post mais detalhado no futuro, provando que, na grande maioria das vezes, para o código comum que usamos no dia-a-dia, não há diferença entre VB e C#. E não estou dizendo em performance, estou dizendo em tudo.

Todos sabemos que qualquer linguagem .net (e existem dezenas delas) são compiladas para um Assembly intermediário (assembly de linguagem, não no sentido de um pacote/dll como no .net) chamado MSIL. Se compilarmos código em C# e em VB e depois analisarmos o MSIL gerado, veremos que ambos são exatamente iguais para a maioria dos casos.

Portanto, não importa em que linguagem você esteja programando, tirando uma otimização aqui e acolá, o código gerado será exatamente o mesmo no que importa: MSIL

Programadores BASIC são extremamente incompetentes

São sim. E também não são (eu sou um exemplo, =P).

Conheço péssimos programadores em BASIC, em Java, em C#, em C++, em Pascal… Gente sem experiência, com conceitos errados ou simplesmente sem o feeling sobre o que é programar podem ser ruins em qualquer linguagem. E, acreditem… existem váááááários programadores em C# que simplesmente conseguem detonar um código quando saem do feijão-com-arroz dos Wizards do Visual Studio.

Eu gosto de usar uma frase que um amigo (e ex chefe) usou uma vez comigo. O cara é MVP de C++, um programador muito bom que respeito muito. Quando eu estava desenvolvendo um daqueles projetos que ninguém quer fazer (tratava-se de comunicação UDP com um mainframe da década de 70), ouvi a frase “Olha, programador BASIC sempre é ruim, mas tirei meu chapéu pra você agora”. Vindo de quem veio, acredite, foi um baita elogio

O fato é este mesmo… gente boa e gente ruim existe em todas as áreas de atuação. Eu posso citar zilhões de pessoas que são péssimas em C# (e se dizem programadores), além de várias entrevistas de emprego que eu ministrei onde as pessoas não conseguiam fazer o básico do básico (por exemplo, montar uma treeview com recursividade).

Mas, concordo, que por ser extremamente fácil e acessível, BASIC é fatalmente associado com programadores inexperientes e isso denigre sim um pouco da imagem. Mas, com o trabalho que C# tem tido nos últimos anos para disseminar a linguagem, isso vai mudar radicalmente, porque muita gente inexperiente está iniciando com C# e, pasmem, eles não nascem bons! Vão errar, vão cometer atrocidades. Culpa da linguagem?

Macacos programam em BASIC

Sim! E isso é maravilhoso! Minha linguagem preferida é tão fácil de usar e tão simples de manter que até um macaco pode programar! Eu acho isso ótimo (e não, sem sarcasmo desta vez!) =)

Olá a todos, este é o meu blog, Fast & Furious, dedicado exclusivamente à três pontos:

1. Extrair o máximo de seu código, provendo testes para a solução de diversos problemas com o intuito de determinar qual a forma mais performática de se obter o resultado desejado, com ampla discussão das técnicas utilizadas, códigos para testes, benchmarks e um pouco de background de como as coisas funcionam.
2. Desmitificar certos conceitos tomados como verdade que, no fundo, não são bem assim =)
3. Prover um local onde aquelas dúvidas chatas que sempre aparecem no meio do desenvolvimento sejam não só resolvidas, mas explicadas para que se entenda como o todo funciona e prover mais conhecimento para os futuros problemas

Sobre mim

Sou um programador das antigas, quando nossos processadores tinham meros 3.5 Mhz (ou 0.0035Ghz) e tínhamos que sobreviver com 64 Kilobytes de memória (compartilhada com o resto do sistema, o que nos deixava pouco mais de 24Kb, ou 0.0000267Gb). É… você não leu errado não, os números conferem…

Naquela época (idos de 86), performance e economia de memória não eram luxo, eram necessidades. Os números acima não mentem. Você não determinava se uma List(Of String) (List<String>) era mais rápida ou não do que um ArrayList, você simplesmente fazia o que tinha que fazer rápido em Assembly.

Comecei com o que havia disponível na época: BASIC. Naquele tempo, as máquinas eram cerca de 66% do tamanho de um notebook atual, você o ligava a uma TV comum e a um cassete (sim, daquelas fitas K7 que os rádios de carro possuiam no século passado) e, ao ligar a máquina, quem entrava era um interpretador BASIC e só. Sua opção era programar ou programar =P

Na imagem ao lado um interpretador BASIC da Microsoft para máquinas MSX, com processador de 3.58Mhz e 64Kb de RAM (dos quais, como pode ver na imagem, só restavam cerca de 27Kb. Quando se conectava uma unidade de diskette era consumida cerca de 4Kb por unidade disponível).

Desde então programei em BASIC e Assembly (e muito pouco em C, Modula 2 e Pascal) para virtualmente todas as máquinas disponíveis no Brasil na época. Meu primeiro PC veio de fato só em 1996, com um incrível Windows 3.11.

É óbvio que, mesmo sendo primariamente um programador VB.net, todos os exemplos aqui serão nas duas linguagens, então, não se preocupem Se desejar, aproveite e leia alguns pontos de desmitificação sobre BASIC aqui.