Apartidarismo

Brasil um país democrático! Bonita frase, não?!

Nesse último pleito tive chance de observar, com mais atenção, os vários arquétipos de eleitores. Infelizmente percebi que ainda existem pessoas que não usam a razão pra votar.

É simples. Existem pessoas que votam em determinado candidato em detrimento do seu partido, alguns mais excitados chegam à loucura de afirmar: "Sou XYZ em qualquer pleito". Na frase anterior troque XYZ por DEM ou PP ou PSDB ou PMDB ou PMN ou PSOL ou PT ou PTB ou qualquer outro partido que você conheça.

Por favor, eleitor seja “apartidário”... Isso não é um jogo de futebol no qual você torce por um time, pense que além da sigla existe um ser, então numa mesma bandeira há candidatos bons e ruins. Se você achar que todas as opções atuais não atendem a seus critérios, vote em branco.

Crítico mesmo é ser candidato, eles devem apoiar quem seu partido apóia... (mesmo que no fundo achem um outro mais adequado) mas você não é candidato: Não apóie siglas, não vote por elas!

Nessa transa partidária deixo um último (incisivo e repetitivo) recado: Um partido não é um time de futebol.

Não vote:
Somente por que o candidato XisIpslon está ganhando nas pesquisas.
Por que o XisIpslon é do partido XY.

Frase que odeio ouvir:
"nunca mais voto no PT" (substitua PT por qualquer outro partido)
"em todas as eleições sou PMDB até a morte" (substitua PMDB por qualquer outro partido)
(ATENÇÃO apartidarismo não é antipartidarismo)

Dsl interna e externa: perguntas e respostas por Martin Fowler

Segue abaixo a traduadaptação [datada em 01/10/2008] (meio capenga) do artigo de Martin Fowler aqui você vê o original.

Fui convidado a criar uma discussão de DSL para não-técnicos. Talvez eu tenha lido muito Stephen O'Grady, mas senti um desejo irresistível de fazê-lo do jeito Q e A (Perguntas e Respostas). Então vamos lá.



O que é uma Domain Specific Language? (ou linguagem de domínio especifico, ou ainda DSL)

Uma Domain Specific Language (DSL) é uma linguagem de programação de expressividade limitada, focada num domínio particular. A maioria das linguagens que você conhece são linguagens de propósito geral (General Purpose Languages), que podem lhe dar com a maioria das coisas que você encontra durante um projeto de sistema. Cada DSL pode agir somente em um aspecto especifico do sistema.

Então você não poderia escrever todo projeto em uma DSL?

Não. A maioria dos projetos irão usar uma linguagem de propósito geral e muitas DSL's.

Essa idéia é nova?

Não totalmente. DSL's tem sido usadas extensamente nos círculos de usuários do Unix desde os primórdios desse sistema. A comunidade Lisp discute a criação de DSL's em Lisp e então usa a DSL para implementar a lógica. A maioria dos projetos de TI usam muitas DSL's – você já deve ter ouvido de coisas como CSS, SQL, expressão regular e etc.

Então porque este assunto está fazendo tanto barulho só agora?

Provavelmente é por causa do Ruby and Rails. Ruby é uma linguagem com muitas características que tornam fácil o desenvolvimento de DSL's e as pessoas que estão envolvidas na comunidade Ruby têm se sentido mais a vontades com essa abordagem, então eles levam vantagem dessas características. Em particular o Rails usa muitas DSL's que o deixam mais fácil de usar. Isto, por sua vez, tem incentivado mais pessoas a seguir essas idéias.

Outra razão é que muitos sistemas feitos em Java ou C# precisam ter muito de seu comportamento definido de forma mais dinâmica. Isto conduziu a arquivos XML complexos que são difíceis de compreender que, por sua vez, levou as pessoas a explorar DSL's novamente.

Então DSL's podem ser usadas com outras linguagens além do Ruby?

Sim, como eu já disse, as DSL's já estavam por ai há muito tempo, mais do que o Ruby. Ruby tem uma sintaxe não obstrutiva e também características de meta-programação que a torna mais fácil para criar elegantes DSL's internas, mais do que outras linguagens como C# e Java. Mas existe DSL's internas uteis feitas em Java e C#

Qual a diferença entre DSL interna e DSL externa?

Uma DSL interna é apenas um idioma particular de escrever código na linguagem hospedeira. Então uma DSL interna feita em Ruby é um código Ruby, escrito num estilo particular que deixa a linguagem mais próxima da linguagem hospede. Tais como elas podem ser chamadas de Interface Fluente ou DSL embutida. Uma DSL externa é uma linguagem completamente separada que é "traduzida" para que a linguagem hospedeira possa entender.

Por que as pessoas estão interessadas nas DSL's?

Eu vejo que as DSL's possuem dois principais benefícios. O benefício mais comum é fazer que certos tipos de códigos fiquem mais fáceis de compreender, que se tornem mais fáceis de modificar, assim melhorando a produtividade do programador. Isto é válido para todos interessados e relativamente fácil de atingir. O benefício mais interessante, todavia, é que uma DSL bem projetada pode ser entendível por pessoas do negocio, permitindo-lhes compreender diretamente o código que implementa suas regras de negócios.

Então este é o gancho – pessoas do negócio escrevendo suas próprias regras?

Em geral eu não penso assim. É muito trabalhoso criar um ambiente que permita as pessoas do negocio escrever suas próprias regras. Você tem que fazer boas ferramentas de edição, depuração, testes e etc. Você tem a maioria dos benefícios das DSL's apenas permitindo que pessoas do negocio sejam capazes de ler as regras. Então eles podem revê-las para aperfeiçoa-las, falar sobre elas com os desenvolvedores e propor mudanças corretas da implementação. Ter DSL's legíveis ao contexto negócios é de longe menos esforço do que ter DSL's escrevíveis pelas pessoas do negócios, mas os ganhos ainda são bons. Existem momentos onde vale a pena o esforço para fazer DSL's escrevíveis por pessoas do negocio, mas esse é um objetivo mais avançado.

Você precisa de ferramentas especiais (leia-se caras)?

Normalmente, não. DSL's internas são apenas facilidades da linguagem de programação que você está usando. DSL's externas requerem que você use algumas ferramentas especiais – mas essas são open source e muito maduras. O maior problema com essas ferramentas é que a maioria dos desenvolvedores não estão acostumados com elas e acreditam que elas são complicadas de usar mais do que elas realmente são (um problema exacerbado pela pobre documentação).

Todavia há exceções no horizonte. Existe uma classe de ferramentas que eu chamo LanguageWorkbench. Essas ferramentas permitem você definir DSL's mais facilmente e também provem sofisticados editores para elas. Ferramentas assim tornam mais viáveis a construção de DSL para os negócios.

Então isto é a repetição do sonho do desenvolvimento de software sem programação (ou programadores)?

Esta foi a intenção do COBOL e não penso que há alguma razão para que as DSL's tenham sucesso onde o COBOL (e tantas outras falharam). Eu penso que é importante que DSL's permitam pessoas do negocio e desenvolvedores colaborarem mais eficientemente porque eles podem falar sobre um conjunto de regras que também são códigos executáveis.

Quando eu deveria considerar a hipótese de criar uma DSL?

Quando você está trabalhando num aspecto do sistema com ricas regras de negócios ou work-flows. Uma DSL bem escrita deveria permitir que os clientes entendessem as regras pelas quais o sistema funciona.

Isto não vai levar a uma cacofonia de linguagens que as pessoas acharam mais difíceis de aprender?

Nós já temos uma cacofonia de frameworks que os programadores tem que aprender. Isto é uma inevitável conseqüência de sistemas reusáveis, é o único jeito que temos de lhe dar com todas essas coisas que os sistemas tem que fazer hoje em dia. Na essência uma DSL não é nada mais do que uma fachada chique sobre um framework. Como resultado elas contribuem um pouquinho com a complexidade que já havia. Na verdade uma boa DSL deveria fazer as coisas melhores tornando esses frameworks mais fáceis de usar.

Mas as pessoas não vão criar muitas DSL's de baixa qualidade?

Claro, assim como pessoas criam frameworks de baixa qualidade. Mas, novamente, eu gostaria de argumentar que DSL's de baixa qualidade não causam mais danos se comparados aos que os frameworks mal projetados causam