ActiveDelphi

[johnny-walker]

Se formos olhar pelo retrospecto da linguagem delphi eu diria que há 2 anos atrás era muito pessimista o cenário perante a linguagem object pascal, hoje podemos ver até pelo gráfico um otimismo maior com a linguagem, se formos olhar pelo gráfico melhorou demais, como se fosse da água para o vinho.
Claro que a borland deixou o vinho azedar, esta sim, teve grande participação na queda do delphi por sua falta de visão de futuro e vontade de arriscar e melhorar a ferramenta com contratação de novos profissionais. somente vendia mais do mesmo e ainda mais o .net no delphi que nunca vingou realmente por seus diversos bugs.

Vejo muito mais vontade de evoluir por parte da embarcadero do que vi em todos os anos depois do delphi 7 até a venda da divisão de IDES para a embarcadero, pois se formos olhar a borland destruiu a ferramenta e para reconstruir demorou bastante.

Hoje eu vejo um futuro no delphi, quem acompanhou meus comentários via meu pessimismo diante da linguagem, mas estava aprendendo c/c++ e c#, ainda continuo aprendendo esta linguagem.

Apesar que tenho muita coisa de delphi object pascal para aprender, ninguém sabe tudo, todo dia é um aprendizado novo, principalmente com os amigos deste fórum que ao longo dos anos e que compartilhamos aqui no fórum o conhecimento de cada um.

Bem, que renasça como a fênix, pelo menos teremos algo de bom a comemorar, apesar que quero aprender ainda mais outras linguagens.


bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[johnsson]

O Delphi não vai morrer nem hoje, nem amanhã e nem depois e depois, e provavel que isso nunca aconteça.

Acredito que o grande problema seja a falsa perspectiva que é gerada em torno da linguagem, vide muitas pessoas que simplesmente agridem a imagem de programadores Delphi etc...

Eu não sou nenhum guru da informatica, mas vou falar em termos tecnicos porque o Delphi não irá morrer, sem falar sobre exatamente a parte externa e mais conhecida de conexão a banco de dados etc...

O Delphi é a unica linguagem comercial compilada do mercado que sofre atualização, um grande problema que eu tive em relação a linguagens como java e c# é que eles não usa mapeamento direto da API do kernel do sistema operacional, na pratica é possivel fazer isso em C# mas com o ônus de mapear manualmente cada DLL do SO e sua respectiva função, quanto ao java ele possui uma camada de abstração maior, o que tem gente por ai que sai comemorando falando que é a maior maravilha do mundo, pois bem, vamos colocar as coisas do devido lugar.

Em teoria um camada abstrata "pode" gerar um código interoperavel entre sistemas operacionais contanto que a VM cuide do mapeamento interno e tradução dos comandos e metadados para a arquitetura, porém, isso trás alguns ônus, a começar que não, java não é mais rapido, uma camada a mais significa um processamento a mais de interpretação e quanto maior a abstração mais longe é o link direto da memoria com relação a utilização real da chamada da API do kernel do SO, outro ponto importante são que threads gerenciadas pela VM não são escalonadas diretamente pelo sistema operacional, ou seja, o escalanador do SO não determina a execução da thread baseado na sua arquitetura de implementação, bom e dai?

Visto escalonamento com prioridade uma thread fake, não obedece totalmente a prioridade imposta, o sistema operacional força isso, a VM não, nós ultimos testes que eu fiz eu instanciei N threads e fui dimuindo o grau de prioridade da thread do maior para o menor, resultado, no Delphi as threads rodaram de acordo, sendo que a thread de maior prioridade rodou significativamente mais que a de menor prioridade, enquanto no java, todas rodaram praticamente a mesma quantidade de vezes, mas e dai?

Com isso em mente problemas de seção critica e soluções de produtor consumidor não tem uma concorrencia de thread real, fazendo com que a solução não execute perfeitamente um multiprocessamento aproveitando todos os nucleos de processamento disponiveis, já que uma thread produtora pode ter maior ou menor custo que uma thread consumidora, fazendo com que seja necessario que seu grau de prioridade seja maior ou menor, se não o sistema sofre um gargalo e perde um tempo precioso com o custo computacional de acesso a seção critica, que é muito similar ao custo de troca de contexto do escalonador, ou seja, ele existe porém não serve pra nada.

Eu poderia ficar apontando N outros fatores e por ai vai, mas esse serve como um exemplo real de um problema, que felizmente o Delphi não possui.

[builder_rs]

Sobre Tiobe, neste link há alguns questionamentos:
http://akitaonrails.com/2008/04/13/off-topic-nunca-confie-no-tiobe#.UIcz9obDtvk

Quer durabilidade e "portabilidade", a linguagem C está ai deste 1972.
Quer "portabilidade mais fácil", tem o java desde 1995.

O Tiobe não responde as simples questões abaixo:

- Em qual solução sou mais produtivo;
- Qual solução irá deixar meus clientes felizes;
- Terei retorno financeiro com a solução escolhida;
- Desenvolverei soluções multi-plataforma;
- Farei integrações com tablets, celulares, smartphones, balanças, impressoras fiscais, rfid, scanners, plotters, gps, ...
- A solução é compativel com as bibliotecas dos hardwares rebimboca da parafuseta e retranqueta do polidor que ainda não foram inventados (itens fictícios, usados aqui apenas para ilustrar que o futuro é uma caixinha de surpresas);

No mais, não há garantias reais para qualquer coisa (ainda mais software que sofre de ausência de garantias), pois impera a lei do "requisito preenchido", explicando:

"Para morrer basta estar vivo. Se está vivo preencheu o requisito."
"Para estragar basta estar funcionando. Se está funcionando preencheu o requisito."

A simplicidade está apenas na visão do cliente ("coisa simples", "programinha", "ajustinho"), ... Afinal, ele só quer a solução, a facilidade.

A programação sempre vai exigir um conjunto de soluções e conhecimentos. Para que a sua solução proposta funcione, tem que geralmente entender de: hardware (requisitos), sistema operacional, firewall, antivírus, rede, banco de dados, linguagem utilizada, regras de negócio do cliente, elaborar planos de contingência, usabilidade, confiabilidade, tolerância a falhas, atender a legislação, ...

O HD pifou, o sistema operacional corrompeu, ... Nada disto importa, o cliente quer saber por que sua aplicação não funciona (e até provar o contrário, você resolve porque a culpa é sua).

A pergunta correta seria o que meus clientes/mercado querem para os próximos X anos. Qual conjunto de soluções vai atender aos novos requisitos. Se quer alguma tranquilidade/segurança/mais oportunidade, domine várias linguagens (será menor a probabilidade de todas deixarem de existir ou te deixarem na mão ao mesmo tempo).

E para finalizar, vale uma frase sobre softwares: "Se existisse um software perfeito, não haveria a necessidade de existirem outros similares/concorrentes".

Abraços,

Anderson:.

[adriano_servitec]

Muito bom a gente ler estes comentários, ajuda a gente na tomada de decisão.

Obrigado pessoal pela contribuição de seus comentários.

Ja ajuda a decidir qual rumo devemos tomar.
_________________
Jogo seu smartphone? Acesse o link e confira.
https://play.google.com/store/apps/details?id=br.com.couldsys.rockdrum
https://play.google.com/store/apps/details?id=br.com.couldsys.drumsetfree

[douglas_fc]

Com Delphi comecei a pouco tempo quando me registei aqui no forum em maio de 2010, alias foi a primeira tentativa de ingressar no mundo da programação cheguei a usar o delphi 6 e a maravilhosa vs 7 depois tentei a 2009 mas voltei pra 7 agora estou usando a versão 2010 e é maravilhosa o XE2 deve está melhor ainda andei dando uma espiada mais não migrei ainda e acredito na evolução do delhi até mesmo aqui pelo forum a cada dia pessoas novas se cadastrando acredito que a cada dia surge mais usuarios delhi varias vezes me falaram pra abandonar o Delphi ja q eu estava começando e ir logo para o Java, mas foi paixão a primeira vista pelo delphi e não me arrependo aprendi muita coisa aqui e com delphi e de lá pra cá só vi evolução e aguardo ancioso uma versão com suporte a android!!

abraços!
_________________
O conhecimento só tem valor quando compartilhado!

Douglas Sousa

[johnny-walker]

Johnson este fato dos threads que vc citou acontece tb no visual studio/C#?

visto que o funcionamento do vs é semelhante ao java, já que ele pode ser utilizado junto com o mono para linux.



bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[cobaiaoo]

[johnny-walker]

Mas se formos olhar, a principal IDE é o delphi em termos de pascal, então há de se considerar tal, visto que o lazarus ainda caminha em sua versão 1.0 RC2, em que ficou estacionado muito tempo em sua versão 0.92 Beta.

Não tiro os méritos do Lazarus, mas o delphi continua a ser uma IDE que tem maior foco, infelizmente o Lazarus caminha muito devagar, pois ainda tem de adicionar muitos recursos para finalmente ter uma gama de recursos comparáveis ao delphi, mas eu tiro o chapaeu para o Lazarus, que mesmo sendo open source conseguiu evoluir bastante, pois no seu começo parecia mais com o delphi 3 do que qualquer outra coisa.



bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[johnsson]

Então, nos testes que eu fiz com o c# eu reparei que ele tem um gerenciamento um pouco melhor, eu não sei dizer exatamente o porque.

Faz alguns meses um especialista da microsoft foi na empresa onde trabalho, e dentro outras coisas ele citou que no Windows 8 o framework seria nativo do kernel, infelizmente eu não tive a oportunidade de perguntar o que exatamente seria nativo. Mas entendo que o c# utilize melhor os recursos do SO já que o framework roda como abstração direta da API do kernel, enquanto a VM tende a abstrair o kernel de varios sistemas. Até irritante as vezes, muita coisa que deve ser tratada na mão o c# apresenta pronto no framework, com um ou dois comandos, mas em compensação ele te limita muito no acesso direito as API e gerenciamento de memoria de ponteiro etc... Não que seja impossivel, mas é muito mais chato.

Quanto ao mono, não faço ideia como ele gerencia threads.

No Delphi elas são mapeadas diretamente do SO, agora se tratando de VM é outro esquema, ela tem memoria propria, escalonador proprio etc...

Alias por mapear diretamente o kernel é possivel construir Drivers com o Delphi, é meio complicado se você for construir seu proprio framework, mas existem alguns que facilitam, porém bibliotecas como drive de video não são mapeadas pela embarcadero, boa parte eu tive que traduzir.

[johnny-walker]

johnson tem algum livro para indicar a este respeito, sobre este tipo de arquitetura de software, me interessei pelo assunto?


bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[imex]

Para os que não costumam abrir a página principal do site da Active Delphi, segue uma notícia que considerei relevante:
http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=1420

Abraço

[Batera]

Opa imex, ótima notícia mesmo!

[vaninho]

a todos companheiros aqui do forum, o delphi não esta morrendo ou caindo em deuso, o que acontece é que em cada epoca, uma linguagem se destaca mais, e passa a ser comentada, tipo o php, a empresa fiat automoveis no caso não abre mão do cobol. eu sou ex programador de clipper, migrei pro delphi na versão 3, a questão é opção de programadores uns gostam mais de uma linguagem outros não, mas resumindo toda linguagem se resume em pascal, e se o Delphi esta morrendo a embarcadero não teria lançado a versão xe3. e não teria tantos componentes free e pagos na net, e forums de delphi.

isto tudo é conversa jogada fora de programadores, eu por exemplo não gosto do C++ e nem do visual basic (microsoft) e nem por isto digo que sejam compiladores horriveis, que esta morrendo estas coisas.
deste que iniciei em programação, existe este blá blá do delphi e também de outras linguagens, não passando nada menos do que questão de opniões.

hoje programo em Delphi, java. php, asp net, clipper,cobol,vbnet, e outros, são os que me atendem e que me sinto capaz para executar.

tanto que o delphi esta morrendo como diz por ai, sendo só boato, vejam esta noticia.

O guru de Delphi Marco Cantù, autor de vários livros sobre essa e outras ferramentas da Borland/Embarcadero, agora passa a integrar o time da Embarcadero Technologies.
Marco, que já trabalha com os produtos da Borland e Embarcadero há mais de duas décadas, se juntará à compania na posição de Delphi Product Manager, atuando na Europa.
Uma grande notícia para a comunidade técnica que já acompanha o grande trabalho do Marco Cantù. A notícia foi publicada no blog do autor: http://blog.marcocantu.com/blog/joining_embarcadero_delphi_product_manager.html

um braço a todos.