philip, o que vem a ser LOP?
philip, o que vem a ser LOP?[/quote]
Saudações Galera,
Sentiram minha falta ??? Sejam sinceros !
Parece que eu estava realmente atrapalhando. Bastou me afastar do GUJ (tava dando um tempinho no “trampo”) e a coisa andou bastante por aqui. Para tentar acompanhar as coisas, fiz até um pequeno resumo para ver se entendia o que está acontecendo, vejam só:
Apesar de uns poucos acharem que …
Existe um concenso, pois alguns dizem que…
[quote=Psycopata]A idéia desses programas não é gerar códigos aleatórios, mas sim, retirar do desenvolvimento o que não interessa. E não interessa programação, interessa o negócio. Lógo, a inteligência e o raciocínio está no projeto. Onde é modelado a regra do negócio. A idéia por traz desses programas é transformar regras de negócio em software de forma rápida. E se der para excluir programação (e programadores, lógico) melhor ainda.
Olha, repito, o raciocínio não está na programação, está no projeto.[/quote]
que até se parece com o que está escrito no site da softwell:
“…esqueça das linhas de código. O segredo do sucesso da aplicação está no conhecimento da regra de negócio para a qual a aplicação será desenvolvida e não em como implementá-la…” http://www.softwell.com.br/PaginaAction?pagina=oqueemaker#oqueemaker
Até quem diz não acreditar nisso…
[quote=bruno.braga]…eu tenho uma mente aberta para esse tipo de coisa. E mesmo assim não gostei desse Maker.
Vai contra tudo que eu penso que é certo…[/quote]
afirma em outro tópico http://www.guj.com.br/posts/list/80877.java que…
afirma também que:
igualzinho (novamente) a outro trecho do site da softwell que diz:
“…O propósito do Maker é tornar o desenvolvimento de Software uma tarefa menos árdua…” http://www.softwell.com.br/PaginaAction?pagina=oqueemaker#oqueemaker
e o interressante é que quando surgem alguns questionamentos…
philip, o que vem a ser LOP?[/quote]
são rapidamente esclarecidos com base, obviamente!!, na wikipedia…
philip, o que vem a ser LOP?[/quote]
http://en.wikipedia.org/wiki/Language_oriented_programming[/quote]
Até eu fiquei curioso também, cliquei e vi algums exemplos de implementação de LOP. Um deles é o Intentional Software.
dai cheguei ao Dr. Charles Simonyi , criador do WYSIWYG e etc etc. - parece que ele conhece um pouquinho - tá ai o currículo: http://www.intentsoft.com/company/management.html
foi ai que lembrei !!! Já havia tinha lido sobre esse cara, em algum lugar. E foi aqui mesmo, nesta trhead:
cliquei no link do artigo do Simonyi e traduzi um pequeno trecho que dizia:
“Permitiria os programadores a expressar as intenções deles/delas sem penetrar o lodo de detalhes de implementação que sempre ameaçaram os engolir. Como “meta-programadores”, passando ordens a programadores peões, o programador intencional iria se livrar do ?trabalho sujo? e passar a bola–mas não para um colega júnior. Ao invés disso, a programação intencional criaria um tipo de “motor”, um programa que recebe um conjunto de comandos relativamente de alto nível e cospe fora código de funcionamento mais-detalhado. O objetivo não era tanto aliviar o trabalho de programar e sim deixar os programadores clarearem as inteligências, livres de trivialidades para que assim eles pudessem ser na verdade criativos.”
e ele, pasmem, afirma também que:
“Programadores hoje, segundo ele, levantam requisitos dos clientes e então, literalmente, escondem as informações valiosas numa montanha de detalhes de implementação ? isto é, o código. O problema é que uma vez que o código é escrito, os programadores tem que fazer algumas adições e mudanças no próprio código. Esse trabalho é doloroso, lento e dá margem a erros. Nós não deveríamos estar tocando no codigo, diz Simonyi”.
Que é exatamente o que eu disse em outra thread http://www.guj.com.br/posts/list/15/78806.java (olha que legal !!! Tomara que eu também fique famoso e vire turista espacial):
Será que meu raciocínio sobre este tópico está correto ???
[]'s
COmo esta é uma das minhas áreas de pesquisa vou resonder à iso, apesar de ter dto que não of aria. Eu sei que não devia.
Não, você está redondamente enganado. Apesar dos vendedores do maker chegarem à citar Simonyi eles o fazem apenas por questões de marketing. O maker nao tem nada relacionado com as idéias de Programação intencional.
O dia que você perder um pouco de tempo para ler o que cita você vai ler algo como:
[quote]
Intentional Software’s strategy borrows from a trend in programming known as “domain-specific languages” or DSLs–little programming dialects tuned to the needs of specific disciplines. Simonyi praises DSLs but says they don’t go far enough. They’re hard to create and therefore costly; you end up needing more than one (for a medical billing system, you’d need at least a medical and a financial language); and they’re incompatible with one another. Intentional Software’s system is like a factory for multiple DSLs that can talk to one another.
Here’s how it might work: Suppose an international bank wanted to develop a new system for managing transactions in multiple currencies. First, the bank’s own domain experts would define the system’s functionality, using their customary terms and symbols and identifying the most important variables (“time” or “value” or “size of transaction”) and the most common procedures (“convert holdings from one currency to another” or “purchase hedge against falling value”). Then the programmers would take that information and build a “domain specific” program generator that embodies that information. A separate software tool would allow the domain experts to experiment with different sets of data and ways to view that data as easily as businesspeople today rearrange their spreadsheets. [/quote]
Quando você me mostrar uma DSL erada no maker ele deixa de ser só mais um gerador de código genérico, enquanto isso não acontece é apenas mais um dos dezenas existentes. Se aluém quer usar algo aprecido com IP hoje as melhores ferramentas provavelente são DSL Tools da Microsoft, MetaCase e as da JetBrains. E essa foi exatamente a minha crítica, que o neófito perguntou sobre, o maker não tem anda de novo e nem entra nos novos ramos de pesquisa e desenvolvimento. É apenas tudo novo de novo.
Para quem se interessa pelo tema eu recomendo o paper da Microsoft Research, o artigo linkado não traz os detalhes da abordagem.
[quote=pcalcado]COmo esta é uma das minhas áreas de pesquisa vou resonder à iso, apesar de ter dto que não of aria. Eu sei que não devia.
Não, você está redondamente enganado. Apesar dos vendedores do maker chegarem à citar Simonyi eles o fazem apenas por questões de marketing. O maker nao tem nada relacionado com as idéias de Programação intencional.
O dia que você perder um pouco de tempo para ler o que cita você vai ler algo como:
… Se aluém quer usar algo aprecido com IP hoje as melhores ferramentas provavelente são DSL Tools da Microsoft, MetaCase e as da JetBrains. E essa foi exatamente a minha crítica, que o neófito perguntou sobre, o maker…
[/quote]
Vamos traduzir, parte do trecho que você mesmo postou:
“A estratégiia da Intentional vem de uma tendência na programação conhecida como “linguagem de domínio específica” ou a DSLs – dialetos de programação que se ajustaram às necessidades de domínios específicos. Simonyi elogia os DSLs mas diz que não vão longe. São difíceis de criar e conseqüentemente caros; você acaba precisando de mais de um (para um sistema de faturamento médico, você necessitaria de uma linguagem médica e de uma financeira); e são incompatíveis um com um outro…”
vejamos:
O maker tem um mix de diversas tecnologias, o fato de ter dito que não tem nada de novo, não quer dizer que o produto não é inédito. Ele usa uma especie de DSL visual, e universal (porque é de fácil ententimento/alto nível) e isso resolve um dos maiores problemas do DSL.
Para comprovar tal “DSL universal” segue um trecho extraido do site http://www.softwell.com.br/PaginaAction?pagina=recursos
“A abstração de linguagens no Maker está presente na utilização de fluxogramas para desenvolvimento de regras de negócio do sistema. Desta forma, o desenvolvedor Maker consegue aumento de produtividade, pois, como o fluxograma é uma sintaxe única para todas as linguagens que forem utilizadas na aplicação, não há perda de tempo com o aprendizado de novas sintaxes e, por ser uma interface visual, também não há perda de tempo…”
Acho que eles foram infelizes quando colocam a abordagem como sendo uma substituição a linguagem, acho que ele é mais do que isso.
Em também já havia dito em outra thread:
Repito: Não é o uso daquele “velho” fluxograma do passado, que alguns insistem em remeter o produto. É uma nova abordagem visual, que apenas se parece com fluxogramas, porém, tem outras finalidades. Com isso todos os desenvolvedores poderam aplicar sua “lógica” e capacidade profissional sem necessitar de um treinamento de “meses” ou até “anos”.
Isso prova que o uso de “elementos visuais” não é mais uma tendência, é uma realidade. Por exemplo:
drools da red hat http://labs.jboss.com/drools/featuresandscreenshots.html#screenshots e http://labs.jboss.com/drools/
Como o da Microsoft http://www.devmedia.com.br/articles/viewcomp.asp?comp=1771 e http://www.linhadecodigo.com.br/Artigo.aspx?id=1456
Spring web flow http://www.springframework.org/webflow
Entre outros aqui citados (Tools da Microsoft, MetaCase e as da JetBrains) todos com uma abordagem visual “parecida” com maker, porém, com finalidades bem mais amplas.
Ou seja, o maker é a junção de “partes” de diversas tecnologias existentes em outras ferramentas. Algumas novas outras não. Para mim não é nada de novo, apenas, porque eu já as conhecia de outros “carnavais”. Acho que essa “babel” é uma das dificuldades que algumas pessoas tem de entender o que é a ferramenta.
E botem fé, uma das “partes” (tecnologias) do maker é tudo de programação intencional. Não se limita a programação com interface visual. Pois, posso criar/usar domínios específicos (para uso médico, financeiro, industrial, etc).
Fui claro ???
[],s
Claro você foi, mas continua errado.
Não existe “DSL Universal”. Uma DSL é uma linguagem específica à um domínio. Se é universal ela não é específica, deixa de ser uma DSL e passa a ser uma General Purpose Language, GPL. Java é uma GPL, a linguagem gráfica do maker é uma abstração em cima disso -que nem GPL é. Novamente: é o que fazemos há décadas e nunca deu certo (pelo menos não em grande escala).
Um dos desenvolvedores do Drools já tentou te explicar que o produto não tem nada a ver com o maker mas você continua insistindo em listá-lo. Antes de falar besteira sobre o produto dos outros leia um pouco, das que eu citei apenas a MSFT DSL Tools se baseia em DSLs gráficas, metacase e MPS são abordagens independentes de representação gráfica ou textual -exemplo de MPS por Martin Fowler-. Mesmo o DSL Tools é muito diferente do maker porque se baseia em transformação de modelos e MDD -como faz MDA- e não em um gerador de código. Claro que não conhecer estes produtos não te impede de citá-los como “parecidos com o maker”, e dado que pelos posts anteriores já sabemos que você não conhece muito bem como o maker trabalha isso não é surpresa.
Como você não lê os trechos que cita - não ler sobre IP não te impede de dizer que o maker faz IP, o que é uma piada- e ainda lista ferramentas “parecidas com o maker” que não possuem nada a ver com este -e que você, novamente, nem sequer consultou os sites- eu paro por aqui novamente. Acho que quem ler essa thread já vai poder perceber que você não tem a menor idéia do que está falando e não vai absorver uma idéia deturpada dos conceitos de LOP e IP.
Aliás, esse é público-alvo ideal para o maker: pessoas que não lêem mais que trechihos pequenos, Não consultam suas próprias referências e continuam afirmando coisas sem cabimento.
[quote=pcalcado]Não existe “DSL Universal”. Uma DSL é uma linguagem específica à um domínio. Se é universal ela não é específica, deixa de ser uma DSL e passa a ser uma General Purpose Language, GPL. Java é uma GPL, a linguagem gráfica do maker é uma abstração em cima disso -que nem GPL é. Novamente: é o que fazemos há décadas e nunca deu certo (pelo menos não em grande escala).
[/quote]
Phillip, concordo que os termos “DSL” e “Universal” são paradoxais, logo DSL Universal foi uma puta viagem do Gargula. Mas fiquei com uma dúvida: a linguagem gráfica do maker não pode ser considerada uma DSL? Se pensarmos que um domínio se refere a geração/manipulação de fluxogramas, uma linguagem que pega esse fluxograma (imaginando que ele possa ser alguma estrutura do tipo grafo/árvore/etc) e o exibe graficamente não pode ser considerada uma DSL? Exemplificando, aquele “Graphviz” (não sei se a grafia está correta) não é uma DSL?
[i]# Login para acesso ao sistema.
Permite cadastrar pessoas físicas e/ou jurídicas;
Permite cadastrar as informações pessoais de pessoas físicas;
Permite o cadastro de endereço;
Permite o cadastro de bairro;
Permite o cadastro de cidade;
Permite o cadastro de regiões;
Permite o cadastro de Ceps;
Permite cadastrar o cobrador de banco;
Permite o cadastro de centro de custo;
Permite o cadastro de produtos;
Permite o cadastro de natureza;
Permite o cadastro de forma de pagamento;
Permite o cadastro de despesas;
Permite o cadastro de dado fiscal;
Permite o cadastro de compras externa;
Permite o cadastro de itens;
Permite o cadastro de vendas;
Inúmeros relatórios [/i]
Francamente. Acho no mínimo estupidez alguem dizer que “vai acabar programadores” baseando-se em sistemas desse tipo.
Eu sou desenvolvedor, e a última coisa que eu faço aqui no trabalho sao crudzinhos besta que nem esses.
Chega a ser engraçado.
Quem usa o Maker fora do Brasil?
Onde estão os reviews da InfoQ e outros sites?
Como fazer Billing em Real-Time com Maker?
1a. Afirmativa…
2a. Afirmativa…
3a. Afirmativa…
4a. Afirmativa…
5a. Afirmativa - de Charles Simonyi (eu consegui ler mais um trechinho)
“…Programação intencional acrescentaria uma camada completamente nova de abstração à prática de escrever software. Permitiria os programadores a expressar as intenções deles/delas sem penetrar o lodo de detalhes de implementação que sempre ameaçaram os engolir…”
Logo, qual seria a alternativa correta ???
A=(1+2+3+4)5
B=1+2+3+4+5
C=(1+2+3+4)-5
D= -1-4
E=Nenhuma das anteriores, a resposta correta é ___________.
:?: :?: :?: :?: :?: :?:
[],s
Gargula, lembre-se sempre que vc tb pode dizer algo do tipo “poxa, eh mesmo… desculpa, eu estava enganado” sem ter que sair dessa discussao passando por imbecil cabeca-dura.
Ou voce pode continuar com esses posts non-sense. De qualquer maneira, mais um desses e o topico ta trancado.
Galera,
sinceramente to achando este post uma perda de tempo para todos.
Se esse tal de Maker é tão bom quanto realmente estão falando ai nessas argumentações, vamos ver quando realmente alguém “de nome” o utilizar e criar algo útil. Por enquanto, acredito que seja mais alguma idéia que nasceu morta, como vários disseram ao longo do post.
Abraços. 8)
Senhores,
Este tópico é um dos mais parecidos com Guerra Santa que eu já vi no GUJ. Os dois lados têm argumentos, “fatos” e dados sobre quão bom ou ruim é o software em questão. Mas discussões, abordagens teóricas e achismos não vão determinar se o Maker é realmente eficaz ou é mais uma das tentativas frustradas(e frustrantes) de automatizar a maior parte do desenvolvimento de software.
A maioria dos argumentos são “a priori”, tem uma carga de “pré-conceito”, está amparada por experiências passadas(conhecimento de software com propostas semelhantes). Lógico que isto também é ou pode ser válido, mas só o teste do Maker, a avaliação de todas as suas features e possíveis falhas pode por fim a esta questão.
Este é o grande problema: o sistema não tem cópia de avaliação.
Os grandes sistemas só emplacam porque são usados em massa, geram comentários, são elogiados e acabam sendo adotados pelas grandes e médias empresas. Com o JCompany acontece a mesma coisa: poucos conhecem, algumas empresas adotam e ficam com um grupinho de especialista e reféns do suporte.
Taí um bom tema para TCC: criar um software capaz de proteger eficazmente os direitos autorais.
[quote=Nilson Costa]Senhores,
Este tópico é um dos mais parecidos com Guerra Santa que eu já vi no GUJ. Os dois lados têm argumentos, “fatos” e dados sobre quão bom ou ruim é o software em questão. Mas discussões, abordagens teóricas e achismos não vão determinar se o Maker é realmente eficaz ou é mais uma das tentativas frustradas(e frustrantes) de automatizar a maior parte do desenvolvimento de software.
A maioria dos argumentos são “a priori”, tem uma carga de “pré-conceito”, está amparada por experiências passadas(conhecimento de software com propostas semelhantes). Lógico que isto também é ou pode ser válido, mas só o teste do Maker, a avaliação de todas as suas features e possíveis falhas pode por fim a esta questão.
Este é o grande problema: o sistema não tem cópia de avaliação.
Os grandes sistemas só emplacam porque são usados em massa, geram comentários, são elogiados e acabam sendo adotados pelas grandes e médias empresas. Com o JCompany acontece a mesma coisa: poucos conhecem, algumas empresas adotam e ficam com um grupinho de especialista e reféns do suporte.
Taí um bom tema para TCC: criar um software capaz de proteger eficazmente os direitos autorais.
[/quote]
Concordo plenamente com o que escreveu Nilson.
Acredito que com isso encerra toda essa discussão.
Abraço.
8)
Ae acho q este tiopico ja ta meio grandinho ne? e esse gargula fica falando bobagem defendendo o maker dele…
creio que isto não vai chegar a lugar nenhum a não ser com a propagandinha deste gerador de codigo tosco… sera que não ta na hora de trancar esta thread não?
[quote=Adolfo Rodrigues]
Phillip, concordo que os termos “DSL” e “Universal” são paradoxais, logo DSL Universal foi uma puta viagem do Gargula. Mas fiquei com uma dúvida: a linguagem gráfica do maker não pode ser considerada uma DSL? Se pensarmos que um domínio se refere a geração/manipulação de fluxogramas, uma linguagem que pega esse fluxograma (imaginando que ele possa ser alguma estrutura do tipo grafo/árvore/etc) e o exibe graficamente não pode ser considerada uma DSL? Exemplificando, aquele “Graphviz” (não sei se a grafia está correta) não é uma DSL?[/quote]
Acho que você está falando de coisas diferentes. Pelo pouco que conheço do Graphviz ele é sim uma DSL para gerar gráficos mas o maker -segundo a documentação e depoimentos, não ter cópia de avaliação não deixa espaço para análise antes de gastar dinheiro com a ferramenta- não gera gráficos, ele usa gráficos para representar programas de computador gerados por ele.
Pense assim: hoje você escreve programas escrevendo texto mas há algum tempo alguém escrevia programas digitando 1 e 0 ou ligando e desligando switches. Você escreve java mas poderia escrever bytecodes diretamente. São apenas formas diferentes de representar a mesma coisa. Procurando um pouco na internet você acha, por exemplo, gente que usa música para programar. É apenas uma representação diferenciada.
O problema do maker é que mesmo tendo uma abordagem gráfica (que não necessariamente é melhor ou pior, depende de como é feto e dos objetivos) ele não avança. Ele continua representanto uma GPL -na verdade ele representa apenas pedaços de um programa construído com GPL, mas este padaços não têm vínculo com domínio- e continua no mesmo nivel que Java e C#.
DSLs podem ou não ser um futuro para desenvolvimento de software mas, seja sim ou não, o maker não faz DSLs. Para fazer isso a ferramenta precisaria possibilitar a definição de uma linguagem -gráica ou não- customizada para algum domínio. É o que o DSL Tools tenta fazer só que a proposta da metodologia de Sotware Factories (raiz do DSL Tools) é transformação de modelos, como faz MDA. Em DSL Tools você parte de um modelo específico de domínio e o transforma em um modelo em CLI (‘bytecodes’) que é executado. Na proposta original do autor do método você não precisa de mais nada que a ferramenta, qualquer expansão é feita como um plugin para a ferramenta e não uma modificação no artefato gerado. O maker precisa gerar código -ele poderia gerar diretamente bytecodes, basta saber usar CGLIB e seus amigos para fazer isso de maneira muito simples- mas ele não pode. Primeiro porque está preso à arquitetura Java EE, que foi feita para programas em Java e depois -e talvez mais importante- porque não possui round-tripping. A forma de estender ou adaptar seu sistema é alterando o código gerado e este código vai precisar estar em um formato editável.
Todo gerador de código dos últimos dez anos segueme exatamente este princípio, por isso o maker não inova e não é relevante fora dos anúncios da Info Exame, dos empréstimos do BNDES e da cabeça de usuários que -IMHO- não nasceram para desenvolvimento de software.
Sabe, eu até entendo a posição do gargula. Se eu tivesse acabado de gastar entre 6 e 9 mil reais numa ferramenta, eu provavelmente também estaria disposto a defender a minha decisão. Eu só não sei se chegaria aos mesmos extremos.
No final das contas, principalmente se você trabalha sozinho e pode escolher suas ferramentas, tem mais que experimentar e escolher o que funciona para você. Eu duvido que uma linguagem visual seja mais produtiva para mim, mas se quem comprou está feliz, então muito bem. Só não venham dizer que esta é a grande tendência que vai finalmente acabar com os programadores (algo que vem sendo alardeado desde os anos 60) ou que tem qualquer coisa a ver com o Language Workbench do Simonyi (que eu pessoalmente também não vejo como a grande solução que alguns apregoam).
Este será o maior tópico do guj, por dois motivos:
1º O partido de direita sempre defendendo sua tese
2º O partido de esquerda sempre defendendo sua tese
Podemos concluir que, o Maker é um software proprietário, que custa bem caro, que jamais terá mercado abrangente, para ‘tirar os programadores’ de atividade… que ainda não provou porcar@$#@ nenhuma. E que pode vir a fazer algum impacto, sim. (pq não? tbm não podemos achar que tudo que vem de fora é o que há, e o que é criado aqui não vale nada!)
Vamos desejar boa sorte a equipe do Maker, (precisarão para compensar os gastos) e que fique claro que, programadores ainda existirão enquanto existir programas a serem feitos…
Uma dúvida: Como o maker se comporta se precisar buscar serviços que não disponibilizam webservice? (leitura e desfragmentação de vômito htmlático mesmo?)
[quote=peerless]E que pode vir a fazer algum impacto, sim. (pq não? tbm não podemos achar que tudo que vem de fora é o que há, e o que é criado aqui não vale nada!)
[/quote]
O argumento do cv de alguns posts atrás (ou erá sido na outra thread?) se faz valer aqui. O fato de ter sido produzido no Brasil ou em Papua não faz um software ser bom, ruim ou digno de elogios. O que faz isso é o software em si e não onde ele foi escrito. E no mais, quando foi a última vez que alguém viu um software como esse -de fora ou brasileiro- fazendo algum barulho? Inicio dos anos 90? E, principalmente: desse barulho -se houve- o que surgiu?
E realmente incrivel como tem pessoas que pensam que todo um projeto so se baseia em definições de regras de negocio… e o resto programaticamente não interessa pode ser feito por uma ferramenta automatica e pra que programadores? este ponto de ignorancia é realmente um absurdo… vamos por partes… uma coisa que esquecem é que a escabilidade, o desempenho, a performace e a reusabilidade das coisas são tudo coisas programaticamente feitas… vc não tem como aumentar a performace de um sistema com regras de negocio… não a como tunnar a aplicação com regras de negocio… para uma tarefa a inumeras maneiras de se fazer um algoritimo para resolve-la… pode se ir pelo caminho com mais performace, pode se ir para o caminho com mais lentidão, pode se ir para o caminho com mais abstração, com mais reutilização… um exemplo bastante tosco disto é os diversos algoritimos para ordenação de vetores… pode se ver que tem desde algoritimos como quicksort e mergesort que são algoritimos eficientes e rapidos ou um bubblesort que é extremamente lento… em uma regra de negocio onde a ordenação de um vetor faz parte da regra, uma maquina geradora de codigo sera que iria utilizar o metodo mais rapido ou o mais lento de ordenação? é claro grande parte das linguagens tem uma api q faz isto ou aquilo… mas isto é so um exemplo que tem a finalidade de mostrar que uma solução programaticamente pode ser tanto como performatica como não performatica… acho que tal maker funcionaria bem para aplicações pequenas que não dependem muito de desempenho… se vc pegar uma regra de negocio e analisar qtas formas ela podera ser implementada programaticamente vai ver que é um numero extremamente grande… tal maker saberia qual a melhor forma de se implementar? creio que não… ou seja enquanto não existir um sistema que tenha o raciocinio superior ao humano(e no meu ver isto ta muito longe de acontecer… (se este dia chegar o mundo iria acabar virando que nem do matrix…)) sera impossivel trocar um programador por uma ferramenta geradora de codigo…