Acredito que seria um pouquinho difícil recuperar toda a documentação das funções ocultas apenas desmontando ou investigando o binário.
Engano seu: sei muito bem do que estou falando. Comecei a programar em 89 em ASM. Fucei bastante, viu?
Não vou questionar essas discrepâncias entre programar em asm e achar difícil localizar com facilidade todas as funções usadas pelo Clipper. Eu até acredito que tenha pego alguma rotina e montado, mas programar mesmo, é difícil de acreditar. Converse com alguém experiente em asm.
Em nenhum momento eu falei em recuperar documentação, quem está falando isso é você. Eu falei em recuperar toda a lista de funções. E dá para recuperar toda a forma de comunicação com o resto da aplicação também, embora isso dá um pouquinho mais de trabalho. A lista que é o que estávamos falando é hiper fácil, pelo menos em todos os formatos de montagem que conheço e que são os que realmente são usados.
Note que me referi apenas ao kernel de um sistema operacional. Imagino que você deve saber que OOP, apesar das vantagens, impõe um custo: um grande overhead, o que já torna seu uso proibitivo em um kernel como o Linux, que prima também pela velocidade. Se fosse OOP, adeus velocidade. Agora em outros tipos de kernel até pode-se usar OOP. Eu não disse o contrário.
Estou falando de kernel mesmo, existem inúmeros kernels desenvolvidos com OOP. E a perda de velocidade que poderia ter com o OOP vem de implementações ruins. O máximo de overhead que poderia ter é uma indireção através da vtable que pode ser otimizada quando se está compilando um kernel. Perda de performance só é um problema da OOP para quem quiser e quando quiser. E a tão dita velocidade do Linux que hoje é mais parte da sua história passada do que a realidade atual tem haver com sua característica monolítica que o permite fazer menos trocas de contexto, mas trazendo outros problemas. Nem pense que estou aqui defendo o Windows em detrimento do Linux, apenas estou colocando a realidade dos fatos sobre a motivo do Linux ter uma vantagem de velocidade em relação à qualquer microkernel, mas que o Linux colocou tanta coisa no kernel atual que essa vantagem *na prática* não se verifica tão vantajosa. Em testes benchmarch o kernels monolíticos se saem fantasticamente. Nada impediria que o Linux fosse feito usando OOP, mas seria bem mais difícil dar manutenção em um código que precisa ser extremamente otimizado. O Tolvards que é
um excelente programador também não compra a ideia do OOP como solução mágica, não só para o Linux.
Dá uma pesquisada sobre o Singularity da MS. Além de ser OOP, é código gerenciado que teoricamente deveria tornar a coisa mais lenta. O único motivo do Sing ainda não ter uma boa performance é que ele depende de muitas trocas de contextos e faz tudo por IPC que não é uma forma rápida, apesar de ser bem segura.
Nem vou discutir o que é percepção e o que é fato. teimosia tem limite.
Imagina! Está certíssimo. Não se pode esperar sucesso ao levar a cabo um processo com o qual não se tem intimidade alguma. Talvez até chegue no objetivo, mas será por vias tortas, o que causará aumento nos custos, sofrimento e comprometimento da qualidade final. OOP é a mesma coisa. Quem não sabe usar, aprenda, mas SE realmente acredita nesse paradigma (melhor colher várias impressões). Ou se mantenha no estilo procedural, se tiver certeza que é só uma troca de 6 por 1/2 dúzia.
Me cite exemplos de o que é programar do jeito certo em OOP. Que erros o pessoal comete quando está usando OOP? isso é importante para saber se estamos falando a mesma língua, porque eu participei do projeto de conversão com outros especialistas, eu diria que todos melhores que eu e todos achavam o código muito bom, mas ninguém conseguiu dar uma solução melhor. Fico imaginando onde estão os profissionais competentes em OOP que a gente nunca acha. Acha sim um pessoal que é muito bom para fazer OOP, eu achei um monte, mas na hora que se comprara o trabalho deles com de outros profissionais, o deles só fica melhor documentado, mas perde em todos os outros quesitos, inclusive de manutebilidade, já que o melhor código para dar manutenção é aquele que não existe.
O pessoal fala muito nisso, mas nunca vejo dizerem o que é o certo. Em Delphi por exemplo eu praticamente nunca vi OOP feita da forma certa, fora as classes da Borland e mesmo assim nem todas. E ainda tem a reinvenção de roda que eles fazem em muitos componentes, mas parece que aos poucos estão eliminando essas coisas. O que deve ser uma coisa terrível para os muitos programadores Delphi que defendiam a reinvenção da roda quando alguém criticava.
Eu não colho impressões ou mesmo percepções com coisas importantes como esta, eu estudo a fundo o assunto.
De 30 pra apenas 2? Desculpe, mas pra mim está claro que essa empresa realmente tinha muitos problemas. E aposto que não era apenas com a falta de conhecimento suficiente para usar OOP a fim de aproveitar o que de melhor esse paradigma pode oferecer. Mesmo que você tenha achado que o OOP deles um primor. Ademais, o que pra você pode ser um primor, pra mim pode ser um terror. Isso é bem subjetivo.
Isso é exatamente a continuação do argumento anterior. Sempre que algo se mostra ruim na OOP, as pessoas estavam erradas. Eu conhecendo bem o processo todo e com toda a experiência que tenho e de outras pessoas que participaram também, posso afirmar que o problema era a adoção da OOP. OOP era necessária porque os programadores eram craques nisso, faziam como poucos e por isso o código foi virando aquele monstrengo. Eles argumentavam que fizeram algo para resolver um problema, aí surgia um problema pelo que eles fizeram, aí encontravam uma técnica super duper defendida por todos que adoram OOP e eu mesmo as defendia e então resolviam o problema causando outro.
Todos os 30 programadores sairam do projeto porque eles não conseguiam acompanhar o desenvolvimento que passou exigir profundo conhecimento de engenharia da computação e eles estavam acostumados com engenharia de software. Note que foram demitidos 30 bons engenheiros de software e foram contratados 2 excelentes Programadores, com P maiúsculo mesmo. Resolveram pagar bem para quem sabia fazer ou invés de pagar a merreca de 3500 à 5800 que pagavam para os 30 anteriores. Eu usei um caso extremo eu acho mais realista em situações mais normais você trocar 5 programadores OOP por 5 programadores procedural, ambos de mesma qualidade e produzir produtos de mesma qualidade. O que eu quero dizer é que OOP não é mágica seja quem for o programador. Se fosse comparar OOP com Funcional, aí a coisa seria direfente, tenho certeza que 5 programadores poderiam ser facilmente substituídos pro 4 ou até 3 programadores, o problema é que os únicos bons programadores funcionais que conheço são por blog. Ainda pretendo aprender direito a pelo menos brincar com derivadas de Lisp como Scheme e linguagens derivadas de ML. para quem quiser radicalizar, F# pode ser uma boa.
De qualquer forma se o jeito certo de usar OOP for subjetivo, então quero ficar longe disso. Eu sei que tem um "jeito certo", mas isso é defendido em teses, em livros best seller na área, por profissionais respeitados.
Verdade. Me esqueci de SmalTalk. Ela é totalmente OOP, mas parou no tempo. Não conseguiu evoluir, nem tomar mercado. Não posso dizer que seja uma pena, porque não conheço a fundo. Mas fica a curiosidade.
Smalltalk continua evoluindo mas não tem mercado porque OOP puro torna as coisas quase impossíveis de serem desenvolvidas, apesar de ser o jeito mais correto de se fazer. Falta pragmatismo. Haskell é talvez a linguagem mais maravilhosa que eu já vi, mas como o próprio Simon Peyton Jones diz, não serve pra nada no mundo real.
Tem muita gente criticando C# atualmente porque a cada versão ela deixou um pouco mais a OOP. Só que os programadores reais de C# admitem que nunca foram tão produtivos.
Mesmo com a ressalva, discordo totalmente. Há inúmeras vantagens no Delphi se comparado com [x]harbour. Dez dias de dedicação e um leigo já vai conseguir fazer um sistema de cadastro de ótima qualidade no Delphi, num SGBD com SQL, sem ter que montar classe alguma. Mas no [x]harbour,... Nem literatura tem. Há pouco tempo até cobravam por um PDF bem simplesinho.
Ser rápido de aprender não significa ser coisa boa. De qualquer forma, qualquer programador de verdade aprende qualquer linguagem em menos de 10 dias, porque eles sabem programar. Variável é igual em qualquer linguagem, se ele sabe programar mesmo, sabe lidar bem com semântica de variáveis com tipagem forte e fraca, que a maioria nem sabe o que é e qual a diferença para tipagem dinâmica ou estática, assim como não sabem a diferença de *dados* por valor, referência e "por referência", imagine entender orientação a objeto s/ entender isso. Controle de fluxo também igual em qualquer linguagem quando se sabe o porque da existência de cada um e que problemas eles resolveram. A forma como são tratadas funções gerais ou instanciadas também não tem nenhuma novidade nos últimos 30 anos, aprendeu tudo o que tem para aprender sobre o assunto, não importa a linguagem, só muda a sintaxe e a escolha de semântica feita dentre as já conhecidas. Como tratar uma função em clausúra, delegar código, manter os dados na memória, como organizar classes, interfaces, o que pode e o que não pode, o que é default, apenas são escolhas de cada linguagem mas tudo já deveria ser de conhecimento de qualquer programador. Sei que a realidade está bem distante disso, mas deveria ser assim.
O fato de uma linguagem ter mais ou menos documentação, não determina sua qualidade, mas agora acho que entendi o que você vê de qualidade no Delphi. Ele dá as coisas bem prontas, tem muito livro, muito código sobrando por aí, tem muito componente, já vem com uma IDE poderosa. Bem aí não estamos mais falando de linguagem.
Há alguns anos era minha linguagem, apesar de eu não gostar muito da sintaxe, gostava da maioria da semântica, mas gostava muito mesmo era da implementação que era um show, como gostava do Turbo Pascal também e tudo que era da Borland.
Mas não misture Harbor com xHarbour, são bichos totalmente distintos com sintaxe semelhante. No Harbour por exemplo toda documentação que é incompleta, é verdade, está disponível para quem quiser e tem vontade de se virar com ela. De fato o Harbour, assim como quase todos os xBase, não entregam as coisas tão de mão beijada assim. Esse não é o forte. O forte é permitir ser produtivo no dia-a-dia, não na hora de aprender como algo funciona.
Não mesmo. Segundo me consta, ele trabalha na MS. Inclusive, foi um dos cabeças do C#. Uma boa adição ao cast da empresa. Mas na Embarcadero eles certamente têm muita gente boa. Dá tranquilamente pra continuar acreditando neles.
Você leu o que eu escrevi? Não fique tão desesperado em discordar que discorda até repetindo o que eu escrevi. E recentemente que depois da saída do Anders da Borland para ir p/ a MS fazer o MS-Java que depois virou J++ e influenciou o C#, uma linguagem muito boa, começou uma debandada geral e depois da aquisição final pela Embarcadero saiu os últimos que eram realmente bons, assim como o cara do Java já caiu fora da Oracle. Pelo que vi, inclusive agora a pouco, os caras bons da comunidade Delphi estão descrentes na equipe que ficou na Embarcadero, apesar de darem um voto de confiança. Os ruins, alguns que conheço bem, eu vi que estão fazendo rezas e missas para não ficarem na mão. Virou umacoisa bem dogmática.
Mas de qualquer forma, é uma escolha de cada um e eu não acho o Delphi um lixo, eu apenas perdi e percebo que a maioria dos antigos usuários também perderam a confiança no produto, alguns continuam com ele, outros não, percebo que a comunidade deu uma bela diminuída, mas isso é só opinião.
É que tudo reforça a ideia: se é para sair de algo que não tem futuro, então vá para algo mais bem planejado. O próprio Anders diz que fez no C# muito do queria fazer no Delphi mas não podia mais por questões de compatibilidade.
Trocar Clipper por qualquer coisa é uma evolução. Trocar um xBase qualquer que esteja vivo ainda (vivo mesmo) por C# só um exemplo, pode ser uma boa evolução, mas trocar um Harbour por um Delphi eu, neste caso, acho que é só postergar ou trocar de problema.
Duas afirmações conflitantes. Se o cara saiu do [x]harbour e ele descarrilou, porque se ele sair do Harbour, outras pessoas vão tocar o projeto tão bem quanto ele? Pode muito bem acontecer a mesma coisa de novo. Quem garante que não? Difícil, não? Agora, com a grana correndo numa grande empresa, coisas desse tipo são muito mais difíceis de acontecer. Por isso que digo que uma linguagem proprietária tem melhores condições de emplacar.
Primeiro que não vejo para que projeto ele vá. Ele adora aquilo, faz por amor e não pela grana e não tem nada melhor que isso. Não posso dizer por ele aqui, mas ele saiu do xHB porque viu que estava no projeto errado e foi fazer exatamente a mesma coisa no projeto que estava no rumo certo. O projeto continua sendo tocado, o problema é que o cara saiu justamente porque estava sendo tocado por gente que estava estragando o produto. A ideia do xHarbour era fantástica, só que ela não foi implementanda como deveria. Se esse cara especificamente saisse, pra mim pelo menos não faria diferença porque eu não uso DBF mais, onde ele se dedicava mais. E nos outros pontos eu bem que gostaria de poder substituí-lo
E ele não é a única cabeça do projeto. Mas meu seguro mesmo é que tenho um amigo que é o melhor profissional que já conheci, e conheci muita gente, um cara que está no nível desses mais famosos, e que me ajudou decidir trabalhar com o Harbour, porque ele me assegurou também que assumiria o desenvolvimento se desse algum crepe. Até tento convencer ele participar do desenvolvimento, mas ele não quer se meter em time que está ganhando.
Mas para quem não quer correr risco, a melhor coisa que existe é investir na MS. Esse é um dos poucos defeitos que eles podem ser acusados, o de abandonar produtos que ainda tem mercado. Só fizeram com o FoxPro porque a comunidade abandonou antes. Abandonou quando eles lançaram o VFP 3.0 há uns 15 anos. Vou chutar que no Brasil ainda tem mais usuários (programadores) de Clipper/FP/[x]HB do que Delphi.
Difícil dizer que a Embarcadero é uma holding de projetos desconexos, se o seu público está justamente dizendo o contrário, elogiando as iniciativas da empresa. Quando apareceu nesse cenário, veio com fama de empresa sólida. Porque você afirma isso?
Era uma empresa praticamente inexistente que passou ter destaque quando compraram praticamente todos os produtos que eles possuem hoje, quase numa pancada só, simplesmente procuraram por ativos disponíveis no mercado como a Borland e a CA fizeram nos anos 90. Isso tá provado que não dá certo. Aquisição boa é aquela para complementar uma linha forte da empresa que falta alguma coisa. tem exemplos de outros setores onde montar uma empresa em cima de ativos perdidos, não dá certo.
Você deve saber que por muito pouco a divisão CodeGear não foi desativada pela Borland. Alguns dizem que se a Embarcadero não aparece em mais 1 ou 2 meses, e bye bye Code Gear e Delphi.
Não é um termômetro preciso, mas existe um fórum (Stack Overflow), que é bem popular. Vê-se gente do mundo inteiro. Acho que dá pra ter uma idéia da popularidade das linguagens/ferramentas. Note nas tags que as seis linguagens mais populares são para web. A sétima (primeira desktop) é C++, com 27.770 tópicos. Delphi, com 4329, aparece só na quinta coluna. Ainda assim, é uma ótima posição. Extremamente melhor que XBase, que aparece apenas na página 174, com 5 tópicos. Como disse, não é algo preciso, mas dá o que pensar.
De fato não é coisa mais precisa, mas web é a tendência. Depois de mais de 10 anos mexendo muito com isso, alguns momentos exclusivamente, e posso dizer que não é pra mim. Prefiro fazer software para desktop. Na verdade nem desktop propriamente.
Nem questiono a popularidade de Delphi, claro que é uma popularidade declinante.
C# e Java não são para web, podem ser usadas para web e eles tem frameworks muitos bons para isso. Mas já fiz coisas para web em Delphi e nesses dias estou brincando não só em fazer sites aplicações web em Harbour, como usar um servidor de aplicação web feito em Harbour. Não chega substituir um apache, claro, mas sabe que me impressionou a qualidade dele. Como linguagem mesmo e sem contar as variações, Delphi é praticamente a última a aparecer
Claro, ganha de muitas linguagens como assembly, scala, matlab, r, groovy, erlang, lisp, clojure, lua, muitas outras e principalmente de xBase que está mais atrás ainda, mas é algo bem de nicho mesmo, não acho que seja algo que terá uma comunidade forte.
Não tenho nada contra a linguagem ou o produto ou a comunidade, pelo contrário. Só acho que a melhor troca. Se eu tiver que me preparar para o mercado de trabalho se tiver que usar uma linguagem de tipagem estática, eu particularmente iria para o C#. Iria p/ o Delphi se o Anders ainda estivesse comandando, se não tivessem feito tanta tormenta e principalmente ser multiplataforma (do jeito certo, não aquela tentativa mais retardada que fizeram e é claro, tiveram que abandonar). Eu já não poderia escolher o Delphi por esse fato. E hoje, depois de eu mesmo ter resistido bastnte, ser monoplataforma é uma das coisas mais retrógradas que uma linguagem pode ter. Serve bem a determinados tipos de usuários, mas se for pra usar algo monoplataforma hoje em dia eu *quase* prefiro o Clipper
Mas note que em nenhum momento eu quis dizer que o Delphi é uma coisa ruim. E sinceramente eu acho que de uma maneira geral, os programadores Delphi são os piores programadores OOP que já vi, a maioria acha que sabe o que estão fazendo e não sabem, inclusive o cara por muitas vezes apenas consome objetos e acha que está programando OOP. Nestes casos fica fácil entender que o cara não tem problemas com OOP, ele não está programando OOP
Meu objetivo foi apenas mostrar um caminho no tópico original. Não acho que quem opta pelo Delphi esteja fazendo algo errado. E quis fazer um mea culpa por ter incentivado tanta gente a usar OOP e depois de tanta experiência eu acabar me convencendo de que não me trouxe vantagens. Sempre vou me culpar por isso. Só vi OOP dar certo em locais bem burocráticos e onde os programadores na verdade eram engenheiros preocupados com outras coisas que não eram o software.
Nota de Moderação:
