Shoes, você esta equivocado com a modernidade da ferramenta. Eles utilizam até as modernas técnicas de Pontos Por Função:
[quote=willrocks][quote=carlosmacieljrpe]
Seria interessante responder essas perguntas…
Mas a idéia do maker não é exatamente não precisar de linguagem de programação? O pessoal discutiu muito sobre o parser XML aqui e você ainda não disse que estratégia a API nativa do maker usa. O maker tem essas funções aí (cookies, XML, webservices, etc) built-in, gostaria de saber como funcionam. Explique por favor.
[quote=willrocks]Como eu já falei, tudo que se pode fazer no Java, pode-se fazer no Maker. Que parte disso você não entendeu?
[/quote]
Pouco tempo fiz um programa (que nem UI tinha), pq nao achei nada que me fizesse replicar os dados
de uma base SQL Server em uma base Oracle. (pode ser que exista mas nao achei)
Gastei 1 dia e botei pra rodar. O programa rodou durante 4 dias, pq a base era gigantesca. Usando metadados e jdbc cru, consegui fazer uma rotina do tipo “pega do sqlserver tabela a tabela, vai paginando e jogando no oracle”. 7 classes e bem OO, pra poder reaproveitar depois pra outras bases.
Vc consegue fazer isso com Maker?
É bom que vc me diga que consegue. Pq se nao conseguir, vc é um tremendo de um mentiroso e todos seus argumentos caem por terra.
Se consegue tudo bem. Desconsidere meu post.
A um tempo aqui na empresa fiz um mine app que pega as horas lançadas pelos “recursos” em uma tabela do oracle e preenche em uma planilha de atividades em excel com as horas dos “recursos” e executa as macros da planilha o sistema poderia muito bem gerar um arquivo xls e fazer o papel das macros pelo sistema porem como havia muitas macros e isto era demorado e inviavel o sistema deveria manter as macros ja existente… resultado: coloquei um xls ja com as macros de template e fiz o app copiar este xls com os macros, fazer o select na tabela com os filtros passados e depois
copiar deste template o xls para onde o usuario quiser, alterar o nome e gerar um arquivo com um script vba com os dados da consulta feita, executar este arquivo vba pelo Runtime, e depois deletar o mesmo… pergunto
eu conseguiria fazer isto facilmente com o maker???
[quote=fabiocsi][quote=willrocks]Como eu já falei, tudo que se pode fazer no Java, pode-se fazer no Maker. Que parte disso você não entendeu?
[/quote]
Pouco tempo fiz um programa (que nem UI tinha), pq nao achei nada que me fizesse replicar os dados
de uma base SQL Server em uma base Oracle. (pode ser que exista mas nao achei)
Gastei 1 dia e botei pra rodar. O programa rodou durante 4 dias, pq a base era gigantesca. Usando metadados e jdbc cru, consegui fazer uma rotina do tipo “pega do sqlserver tabela a tabela, vai paginando e jogando no oracle”. 7 classes e bem OO, pra poder reaproveitar depois pra outras bases.
Vc consegue fazer isso com Maker?
É bom que vc me diga que consegue. Pq se nao conseguir, vc é um tremendo de um mentiroso e todos seus argumentos caem por terra.
Se consegue tudo bem. Desconsidere meu post.[/quote]
Claro que consegue, é só fazer um fluxograma que use esse código que você já escreveu 
[quote=Maurício Linhares]
Claro que consegue, é só fazer um fluxograma que use esse código que você já escreveu :)[/quote]
Vai ser um fluxograma com entrada, uma caixinha e saída.
O problema do maker não é fluxograma. A idéia do fluxograma é até uma idéia interessante.
O negócio é que propagandeiam isso como se fosse a grande revolução, mas não é nada de mais. Essa é apenas a linguagem que o maker usa. É possível fazer-se todas essas coisas que o pessoal citou aí com fluxogramas sim (se vai ser fácil ou não é outra coisa). Codifica-se funções usando fluxos e faz-se chamadas a estes fluxos em outras funções.
Enfim, função = fluxo.
Desta forma, você pode escolher uma linguagem procedimental qualquer e ver que é possível fazer-se algo semelhante com maker. Sem problema. O ponto onde o maker precisaria do java seria mais ou menos onde o java precisaria do JNI. Somente onde realmente não há mesmo outra forma ou onde o desempenho é crítico.
Enfim, o maker é uma linguagem procedimental e o poder de codificação dos fluxogramas é igual a elas.
O negócio, como eu já disse no primeiro post do tópico, é um desenvolvimento semelhante a delphi ou VB. Você cria a view no modo arrastar-e-soltar e associa para cada evento uma ação (onde ação = função). A diferença é que ao invés de escrever o código você o desenha.
O maker tem uma API razoavelmente rica implementada pela softwell (nada de mais nisso). Fiz aquelas perguntas porque gostaria de saber como é que a softwell implementou alguns recursos dessa API. Ex: processamento de XML, webservices e multithreading.
Enfim, para mim, o maker é apenas mais uma linguagem de programação visual, só que diferentemente de delphi e vb ele é para web. Tem a característica de que o programa é escrito em fluxogramas, mas fluxograma é equivalente a código procedimental e vice-versa. Ou seja, não há nada de novo. O maker é apenas uma linguagem de programação visual para web.
O problema do maker é apenas marketing.
De fato, desenhar fluxogramas é mais fácil de aprender do que escrever código (aprender != fazer). Mas se a leitura/escrita de fluxograma é mais rápida ou não do que a leitura/escrita de código, isso é discutível.
E é verdade que pode-se ser bem produtivo em delphi por exemplo se você sair arrastando componentes e codificar sem pensar em arquitetura, qualidade, reusabilidade ou qualquer coisa assim. Você entrega o produto rapidinho também e tem a mesma produtividade que o maker promete, usando o bom e velho delphi.
É possível ter-se arquitetura, qualidade e reusabilidade no maker? Sim, é possível. Mas aí a tão sonhada super-ultra-produtividade vai por água abaixo bem como o conceito de sistema construído por monkeycoders. Seria preciso mais tempo e mais capacitação!
Não amigo , nao disse que fluxograma seja antigo , so disse que desenvolver software baseado em fluxogramas é antiquado
Prq maker nao segue as novas tendencias de desenvolvimento de software como DDD , TDD ?
Cara, não da para comparar Delphi e VB com o maker. Na boa. são ferramentas com propósitos distindos.
O Delphi e o VB (Visual Studio, na verdade) fornecem um interface visual para você trabalhar com os componentes, mas dificilmente você consegue fazer uma aplicação razoável sem mexer em código. Quem já mexeu de verdade com Delphi e VB sabem do que eu estou falando. Tanto no Delphi como no VB você pode trabalhar só com código ou usar a IDE só para fazer a tela e a lógica, acesso ao banco de dados, etc, fazer no código mesmo. Delphi e do VB nunca foi para subsitituir programadores ou permitir que leigos sem conhecimento muito de programação fizessem sistemas de verdade completos.
Você pode fazer aplicativos extremamente complexos com Delphi e VB, inclusive aplicações multi-camadas, aplicações web, aplicações distribuidas… (eu particularmente prefiro Java ou C#, mas depende de cada caso, cada empresa, cada ambiente).
Eu posso estar enganado, mas já que com o maker todo o código é gerado, você provavelmente tem pouco controle sobre a arquitetura do mesmo.
[quote=Rubem Azenha]Quem já mexeu de verdade com Delphi e VB sabem do que eu estou falando. Tanto no Delphi como no VB você pode trabalhar só com código ou usar a IDE só para fazer a tela e a lógica, acesso ao banco de dados, etc, fazer no código mesmo. Delphi e do VB nunca foi para subsitituir programadores ou permitir que leigos sem conhecimento muito de programação fizessem sistemas de verdade completos.
Você pode fazer aplicativos extremamente complexos com Delphi e VB, inclusive aplicações multi-camadas, aplicações web, aplicações distribuidas… (eu particularmente prefiro Java ou C#, mas depende de cada caso, cada empresa, cada ambiente).[/quote]
E ainda digo mais: você pode programar OO em Delphi, se quiser ( não sei no VB ). Interfaces, por exemplo, existem desde a primeira versão da linguagem ( por favor, NÃO estou dizendo que uma linguagem tem que ter interfaces pra ser OO ).
Pior que você não está. Na demonstração que assisti, o “desenvolvedor” não se preocupa com a arquitetura do sistema. Apenas com os fluxogramas da camada de negócios.
Tem inclusive um esquema de “escalabilidade” que achei muito engraçado: escalabilidade pro Maker consiste em você criar fluxogramas para cada ambiente. Exemplo: um código para o cliente, outro para o servidor.
[quote=kicolobo]
Tem inclusive um esquema de “escalabilidade” que achei muito engraçado: escalabilidade pro Maker consiste em você criar fluxogramas para cada ambiente. Exemplo: um código para o cliente, outro para o servidor. [/quote]
O site deles mostra um esquema diferente para a escalabilidade: http://www.softwell.com.br/PaginaAction?pagina=recursos (ver item Escalabilidade).
WOW. Nunca o Ajax foi tão bajulado em toda a sua vida. Só faltou dizer que isso é WEB 2.0!!!
primeiro o maker não é uma linguagem e um software…
quem diz que existe linguagem visual é pq não conhece o conceito de linguagem… outra se o maker é tudo que disseram e como usar o windows invez do dos então posso fazer facilmente um remake do Crysis ou do World of Warcraft sem mecher em uma linha sequer de codigo??? não vale o argumento: é algo voltado para sistemas web… pois se e uma linguagem revulucionaria tbm tenque ser capaz de fazer coisas deste tipo… outra coisa é como ja foi perguntado mas não respondido como o Maker lida com Threads??? e como ele lida com Clusterização? e se eu tiver o maker e meu cliente não tiver e ele quiser o fonte em java para dar manutenção futuramente que tipo de fonte meu cliente vai receber??? um fonte em java procedural??? sem usar conceitos OO??? so pelo fato do maker usar paradigma procedural ja é algo defasado… dizer que ele e algo revulocionario e usa metodologia procedural e dizer uma enorme besteira… pois a OO veio para aproximar o linguagem computacional das coisas como são no mundo real… so o fato de não se puder usar os beneficios que a OO traz é algo ruim… faça um software que use “modelagem do mundo real” como os CRUDs em Java ou C# e faça o mesmo em Pascal, veja qual vc tera mais produtividade e mais facilidade em manutenção no futuro…
E me mostre qual a fonte que diz que fazer algoritimos em fluxogramas é mais facil e produtivo que escritos em uma linguagem, e é anti-falhas aliais posso errar uma semantica mas é impossivel eu errar um fluxograma???
Sim, mas quando você está trabalhando na implementação do código, pelo menos no que eu vi na demonstração, a escalabilidade era definida assim.
Um código pro servidor (Java ou .net), outro pro cliente (Javascript), tudo usando ou fluxogramas ou código Java/C#
Lembrando: pelo que eu vi na apresentação.
Não, o maker não é um gerador de código, ele é um interpretador de fluxogramas. Ele faz toda a “mágica” sem gerar código em lugar algum.
Quanto a arquitetura, é possível ter-se algum controle disso sim. MAS… não é qualquer estagiário que vai entender como fazer a arquitetura! Como a idéia é programação para leigos/estagiários/macacos, não há arquitetura, pois se você for fazer uma arquitetura decente, leigos/estagiários/macacos não vão servir.
Se não existe linguagem visual, UML, BPEL, é o que?
Po… e você nem tentou botar o cara que tava fazendo a apresentação na parede mostrando essa página??? :lol:
Isso é uma coisa confusa ainda… ainda não entendi, parece que ele pega os fluxogramas e transforma em bytecode, mas tem opção para gerar um .java.
Infelizmente, sem uma versão demo, só consigo especular.
[quote=Rubem Azenha]Cara, não da para comparar Delphi e VB com o maker. Na boa. são ferramentas com propósitos distindos.
O Delphi e o VB (Visual Studio, na verdade) fornecem um interface visual para você trabalhar com os componentes, mas dificilmente você consegue fazer uma aplicação razoável sem mexer em código. Quem já mexeu de verdade com Delphi e VB sabem do que eu estou falando. Tanto no Delphi como no VB você pode trabalhar só com código ou usar a IDE só para fazer a tela e a lógica, acesso ao banco de dados, etc, fazer no código mesmo. Delphi e do VB nunca foi para subsitituir programadores ou permitir que leigos sem conhecimento muito de programação fizessem sistemas de verdade completos.
Você pode fazer aplicativos extremamente complexos com Delphi e VB, inclusive aplicações multi-camadas, aplicações web, aplicações distribuidas… (eu particularmente prefiro Java ou C#, mas depende de cada caso, cada empresa, cada ambiente).[/quote]
Cara, é possível sim fazer aplicações complexas com maker. A questão é se o ganho de produtividade de 60x é válido (e eu não acho nem um pouco que seja). Na verdade acho que é mais fácil fazer em delphi ou vb, mas nem por isso é impossível fazer em maker.
E quanto a questão de poder editar o código, como eu disse: código e fluxogramas são equivalentes. Você está muito mais limitado pela API do que a forma como você escreve códigos (ou desenha fluxogramas), não importa a linguagem (java, delphi, vb, maker, c, c++, whatever).
Quanto a questão de trabalhar no bloco de notas ou na IDE, aí sim. No maker você está amarrado a IDE!
UML não é linguagem de programação… é linguagem de modelagem…
[quote=Rubem Azenha][quote=victorwss]
Não, o maker não é um gerador de código, ele é um interpretador de fluxogramas. Ele faz toda a “mágica” sem gerar código em lugar algum.
[/quote]
Isso é uma coisa confusa ainda… ainda não entendi, parece que ele pega os fluxogramas e transforma em bytecode, mas tem opção para gerar um .java.
Infelizmente, sem uma versão demo, só consigo especular.[/quote]
Bem, primeiro deixa eu frisar isso: o maker é um pacote que contém:
- Uma IDE.
- Uma linguagem de programação (baseada em fluxogramas e árvores de expressões).
- Um ambiente de execução (chamado webrun).
- Uma ferramenta de gerência de baco de dados (parece o access, mas independente de BD).
-
A linguagem de programação salva os fluxogramas serializados no BD em algum formato qualquer. Esse formato pode ser considerado equivalente a bytecodes.
-
Ao receber uma requisição o webrun procura no BD (ou talvez em uma cache, sei lá) o fluxo que representa a requisição (tipo, uma action). Então ele carrega alguma estrutura de dados na memória correspondente ao fluxograma e vai seguindo esse fluxograma executando as ações correspondentes.
Ou seja, não há geração de código-fonte em lugar algum. Apenas o “bytecode executável” é gerado direto dos fluxogramas.