Comentários sobre linguagens de programação

Muita coisa falada sem noção... isso que é tenta força o uso de python

Eu achei bem interessante, e não consegui identificar onde tem alguma tentativa de forçar o uso do python ali. Claro que existe a possibilidade de falar mal mesmo sem ler, mas pra mim pareceu um bom panorama - ainda mais quando se considera que é a opinião de uma pessoa, e que está aberto para discutir.

Eu penso diferente em diversos assuntos (ainda bem, senão a vida seria muito chata). Tem muita coisa e é difícil comentar no br-linux, portanto vou deixar muita coisa de lado.

1. Não entendi uma coisa:
$a=1;
$b="x"
echo($a.$b); => mostra "1a"

Não deveria mostrar "1x"? :-)

-------------------------------
2. Quanto a linguagem e bibliotecas, acho que é importante salientar, principalmente no caso do PHP, que grande parte do 'framework' vem junto com a linguagem. Não é necessário ficar baixando muita coisa. Esse também é um dos aspectos que facilitam a ploriferação da linguagem.
No mesmo caminho do Java, .NET vem com um framework bem grande. Isso evita que fiquemos baixando pacotes que necessitam de outros pacotes que necessitam de outros ...

-------------------------------
3. Quanto ao Delphi, não acho que a biblioteca seja tão rica assim (pelo menos as versões mais antigas). Tanto que existem diversos pacotes comerciais ou não para melhorar o ambiente. A linguagem também não é lá grande coisa. Até hoje sinto falta de expressões regulares no Delphi, tanto que tive que fazer as minhas gambiarras para melhorar como colocar um Lisp no meu Delphi 3 (http://tinyurl.com/2cnv3). Como o Delphi 8 sai para .NET, poderá utilizar as classes do Framework, o que vai melhorar algumas coisas (apesar de ficar mais preso ao .NET/mono? que não me agrada nem um pouco).

-------------------------------
4. Quanto as propriedades do Delphi (get/set), sou obrigado a comentar o caso do Ruby

class Foo
attr_acessor :bar
end

foo = Foo.new
foo.bar = 23
print foo.bar

As opções são: attr_reader/writer/accessor (apenas leitura, apenas escrita e ambos). A gente só dá valor quando começa a usar :-)

-------------------------------
5. Quanto a segurança da natureza dinâmica dos dados, eu poderia citar o Zope. Mas vou mais além. Basta ver esse estudo de caso da JP Morgan
https://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909 (o sistema é grande, complexo, importante e é feito em Smalltalk)

-------------------------------
6. Mas acho que faltam, pelo menos, duas linguagem para o epx: Lisp e Smalltalk.

-------------------------------
7. Faltou ele mencionar em Ruby (mas como ele é mais para o Python, certamente encontrará alguma coisa de ruim na linguagem :-)

Como está implícito no texto não há a melhor linguagem e sim a linguagem mais adequada para o que você quer fazer.

Quer fazer uma aplicação web usando banco de dados mysql, use PHP.

Precisa de uma aplicação que mexa com access, use vb.

Quer fazer um modulo para o kernel, não invente, é C.

(pensamentos ridiculos mas servem para ilustrar o raciocinio)

Use a ferramenta mais adequada para o seu trabalho, programador hoje em dia serve mais para pensar em uma solução mais eficiente para certo caso, mesmo que tenha que usar 1.000 linguagens (cada uma no seu ponto forte). Se você quer mexer com um parafuso, não adianta querer usar o martelo só porque este é a sua ferramenta favorita, deixe ele pra quando você for bater em um prego.

Ainda não existe uma linguagem que seja perfeita e tudo e ainda faça o programador sentir orgasmo porque isso é conceitualmente impossível, sempre terá algo que não estará ``legal" assim sendo, pare de blábláblá e estude as características marcantes das linguagens e tente tirar proveito dela.

;-)

Guaracy Monteir

1. Delphi não existe. Delphi é uma IDE! O que existe é Object Pascal. Para uma IDE livre para Object Pascal, http://lazarus.freepascal.org

2. O Object Pascal não tem uma biblioteca verdadeiramente padrão. A VCL que vem com o Delphi é suficientemente completa. O único ponto fraco dela foi justamente o que tu tocou: a falta de uma implementação padrão de expressões regulares. Porém, basta ir ao google e pegar uma implementação. A grande quantidade pacotes existentes é causada pelo estilo RAD de ser da IDE do delphi (leia-se: os programadores são preguiçosos demais para criar classes próprias e preferem comprar as dos outros).

Quanto ao artigo, tem asneiras mesmo:

--> linguagem com baixa auto-suficiencia aqui era --> (é) é o Visual Basic: um componente novo tinha --> (tem) de ser escrito em C++
Da última vez que eu olhei (ok, faz uns anos) podia ser escrito em VB...

Java é autosuficente? O compilador e VM são escritos em Java??!

--> Uma menção especial para Python que permite um --> desenvolvimento progressivo de uma classe ou --> função, primeiramente em Python e posterior
--> reescrita em C se for necessário.
Python é interpretado, não dá pra comparar!

--> uma "propriedade" em Delphi é um conjunto de
--> dois métodos getx() e setx()
Não é apenas isso. Pode-se controlar o acesso a variáveis internas e muito mais coisas.

Tem outras, mas cansei de "reclamar" :)

Guaracy Monteir

1. Delphi não existe. Delphi é uma IDE! O que existe é Object Pascal. Para uma IDE livre para Object Pascal, http://lazarus.freepascal.org

2. O Object Pascal não tem uma biblioteca verdadeiramente padrão. A VCL que vem com o Delphi é suficientemente completa. O único ponto fraco dela foi justamente o que tu tocou: a falta de uma implementação padrão de expressões regulares. Porém, basta ir ao google e pegar uma implementação. A grande quantidade pacotes existentes é causada pelo estilo RAD de ser da IDE do delphi (leia-se: os programadores são preguiçosos demais para criar classes próprias e preferem comprar as dos outros).

Quanto ao artigo, tem asneiras mesmo:

--> linguagem com baixa auto-suficiencia aqui era --> (é) é o Visual Basic: um componente novo tinha --> (tem) de ser escrito em C++
Da última vez que eu olhei (ok, faz uns anos) podia ser escrito em VB...

Java é autosuficente? O compilador e VM são escritos em Java??!

--> Uma menção especial para Python que permite um --> desenvolvimento progressivo de uma classe ou --> função, primeiramente em Python e posterior
--> reescrita em C se for necessário.
Python é interpretado, não dá pra comparar!

--> uma "propriedade" em Delphi é um conjunto de
--> dois métodos getx() e setx()
Não é apenas isso. Pode-se controlar o acesso a variáveis internas e muito mais coisas.

Tem outras, mas cansei de "reclamar" :)

Anderson: o amigo acima não disse que Java é auto-suficiente em relação a não precisar de outras ferramentas para rodar. Ele falou em relação ao framework, as bibliotecas disponíveis por padrão. Nesse sentido, Java é bem completo.

Python é interpretada? E os bytecodes?

Ufá terminei de ler.
Achei a análise nua e crua. Tem o lado bom e ruim de cada linguagem.
Muitas das situações ditas ali eu também experimentei em minha carreira.
É claro que falar a verdade de algumas linguagens , principalmente o que elas tem de ruim, fere o ego de alguns.

Uma dúvida que fiquei do artigo. Ele disse que o C++ no linux usa um compilador separado, mas o g++ não é apenas um pre-processador para o gcc??
Alguém poderia responder??
No artigo, ele tentou falar de coisas que não se falam em outros lugares, mas acho que a opinião dele continua sendo tendenciosa. Dá pra ver a grande preferência dele em relação ao Delphi. Claro, a gente quando usa uma coisa por muito tempo tende a achar aquela coisa melhor.
Tipo ele falar que zera todas as variáveis quando inicia a classe não perde tempo eu acho besteira. Um dos grandes problemas de perfomance é exatamente ficar zerando e copiando não só variáveis, também classes inteiras. Foi por isso que surgiu o const, não???

> Uma menção especial para Python que permite um desenvolvimento progressivo de uma classe ou função, primeiramente em Python e posterior
reescrita em C se for necessário.

Eu curto Python... mas fazer código native é uma coisa que é mais fácil em Java...
E Delphi, embora seja uma boa linguagem, como alguém citou acima, o framework básico é bem incompleto.

Nossa Peter,

Você realmente acha mais fácil usar o JNI? Você já desenvolvel código em C/C++ para Python?

Na boa, é a primeira vez que eu escuto falar que fazer código C/C++ para Java é mais fácil do que pra Python :)

Recentemente estava mexendo com JNI para tentar criar algo como a SWT (do Eclipse) para Python e é *muito* complicado entender o funcionamento daquilo...

A integração entre as linguagens ainda e uma coisa que deixa a desejar. Mas a integração com C/C++ deveria ser uma coisa mais simples do que é.

Para quem conhece Perl ou Ruby (não sei com relação a outras), nada como um Inline::C. Basta escrever a função desejada em C sem sair da linguagem que se está trabalhando. Segue exemplo em Ruby (não sei Perl :/ )

require "inline"
class MyTest
inline_c "
long factorial(int max) {
int i=max, result=1;
while (i >= 2) { result *= i--; }
return result;
}"
end

t = MyTest.new()
print t.factorial(5)

Mais simples que isso? Talvez em Smaltalk/X pmde também é possível utilizar C, Prolog e Lisp para a codificação de um método. Mas isso já é outra história. Para que simplificar se podemos complicar?

Realmente é fácil fazer isso em Ruby... Como funciona a implementação desse esquema 'inline' aí?

BTW, no ObjectStudio (Smalltalk) que a gente usa aqui na empresa é tão difícil integrar com outra linguagem que eu poderia até dizer que 'é impossível' :)

Não sei se é assim em outras implementações de Smalltalk. De qualquer forma não faz parte do universo Smalltalkiano se comunicar com o 'mundo'. A idéia de um ambiente Smalltalk (não só a linguagem) é a de ser auto-contido. Ok, ele se comunica com 'o mundo exterior' mas esse não é o mote.

Encarei o texto mais como o post de um blog, é a sua área e a sua opinião para quem quiser ler. Quem não quiser tbém ñ vai morrer por isso.

Notei algo que ñ acontece só na nossa ciência da computação mas em todas as outras também:

Toda teoria científica acaba sendo um tiro no escuro, quando se tenta fazer as coisas na prática percebe-se que a teoria era uma grande besteira e a teoria muda ou até mesmo desaparece.

Quando se tem apenas a teoria ela acaba se tornando a verdade suprema de forma precoce, "é o que sei no momento logo é a verdade".

Já nos testes os seres humanos percebem que como as linguagens, são todos iguais, limitados e feitos de uma mesma matriz (particularmente creio em DEUS). Se compreendem melhor e começam a trabalhar juntos para conseguir algo grande de fato.

Obrigado a todos.

"Toda teoria científica acaba sendo um tiro no escuro, quando se tenta fazer as coisas na prática percebe-se que a teoria era uma grande besteira e a teoria muda ou até mesmo desaparece."

Nesse momento todos os geniais físicos teóricos do passado se remexeram dentro do caixão.

E os do presente também, menos o Stephen Hawking, que não consegue se mexer, mas deve ter, pelo menos, piscado o olho, em reprovação.

Embora a prática tenha importância, dizer que "toda teoria científica é um tiro no escuro" é um pouco forte, não é?

A grande maioria das revoluções científicas começaram como idéias na cabeça de cientistas geniais, para depois serem comprovadas na prática. Muitas dessas teorias ainda foram criadas antes de existirem os equipamentos ou tecnologias necessárias para comprová-las na prática.

Teorica científica não é jogo de azar. É baseada em conceitos matemáticos bem estabelecidos.

Para Osvaldo Santana (aCiDBaSe)

O Inline::C no Ruby fica sendo um intermediário e serve 'apenas' para compilar a função, bem como proceder no ajuste dos parâmetros, fazendo as conversões necessárias na chamada/retorno. Para coisas complexas teria que fazer o trabalho sujo (apesar da interface ser relativamente fácil e existe também a possibilidade de usar o SWIG).

Perl tem 'inline' para diversas linguagens. Existem outros que seguem princípio semelhante para Ruby interagir com Java, .NET (C#).

Quanto ao Smalltalk, vai ver que é por isso que o Smalltalk/X não é conhecido. Acha que a inclusão de outras linguagens pode ajudar. :-) Era possível trabalhar com Java também, mas como era a versão 1.2 nem salientei. Mas o desenvolvimento (abertura do código) está muito devagar par o meu gosto. Eles deveriam colocar no sourceforge e deixar o povão ajudar.

http://exept.eu.org:8080/doc/online/english/programming/primitive.html

É claro que não é só isso, mas veja como pé difícil incluir C no Smalltalk/X

add:num1 and:num2
|sum|
%{
/* only for the demo; the code below only handles
* SmallInteger operands ...
*/
if (__isSmallInteger(num1)
&& __isSmallInteger(num2)) {
sum = __MKINT(sum1 + sum2);
}
%}.
^ sum

Guaracy,

Vou dar uma olhada nesse mecanismo de inline do Ruby. Mas como você disse o 'trabalho sujo' ainda precisa ser implementado em separado (apesar da API ser simples).

A API de Python também é simples, neste ponto as duas linguagens estão 'empatadas'. Mas esse mecanismo de inline C não existe em Python (ou existe e eu não conheço).

Com relação ao Smalltalk: Uma implementação que tenta criar o *ambiente* Smalltalk imaginado pelos criadores da linguagem láááá em 1900-e-antigamente é a Squeak. Não sei como é integrar ela com outras linguagens e nem se ela é 'usável' para 'desenvolvimento geral', mas realmente cumpre o que o pessoal aqui da empresa apresentou pra gente: "Squeak, faz do desenvolvimento uma alegria."

Bem Osvaldo.

O trabalho sujo seria necessário para ligar com uma biblioteca tipo wxWidget ou outra complicada. Para otimizar algum gargalo do programa, o que eu mostrei é o suficiente. Basta colocar o código C/C++ direto no programa e esquecer do resto.

Imaginei que Python tivesse alguma coisa do gênero e uma rápida googleada retornou (não fiquei procurando outros links) http://www.scipy.org/documentation/weave/weaveperformance.html

Tem um material bem interessante. Procura por "scipy.weave.inline" na página. É parecido.

O pessoal do Squeak é muito 'puro'. Eles implementam tudo em smalltalk. Não posso dizer como funciona a ligação com C (pelo menos).

Para o Daniel Dantas: não digo que Delphi seja a melhor linguagem/ambiente do mundo; mas me cativou, me senti perfeitamente confortável com ele. Foi essa sensação de conforto que tentei metrificar no artigo com base em critérios objetivos (não sei se consegui).

Muitos disseram que estou sendo tendencioso para o Python. Acho que estariam mais certos se dissessem que eu estou puxando o saco do Clipper :)

Quanto ao g++/gcc, o compilador C++ é realmente um programa separado, e não um pré-processador. É possível implementar C++ em termos de código C puro (o CFront faz isso) mas não é o caso do GCC.

Então grande parte do esforço de depuração, otimização etc. etc. é duplicado no GNU Compiler Collection. Assim aconteceu, mas acho que é uma coisa ruim. Um dos motivos do projeto GNOME ter sido criado foi justamente o fato do KDE usar C++, e o C++ ser mal otimizado no gcc de 1997/1998.

A situação do GNU C++ é bem melhor hoje. Compiladores como o Intel C++ são bem melhores para C e C++, mas também não podemos perder de vista que o GCC é multiplataforma... Mas sinceramente não sei se faz sentido desenvolver algo novo em C++ hoje. Eu gostaria de ver um KDE inovando e sendo migrado aos poucos para Python. O GNOME já está mais ou menos apontado para essa direção, com o .NET/Mona.

Para o meu clone: eu quis dizer que, embora eu goste MUITO de python, é mais fácil fazer JNI com Java.

O comentário abaixo foi tirado do Pontobr.org:

Python? PHP? Java? C++?

Esqueçam essas linguagens ultrapassadas e complicadas! Programem em uma linguagem de futuro. Programem em Unlambda [http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/]

Aqui está a série de Fibonacci em Unlambda:

```s``s``sii`ki
`k.*``s``s`ks
``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
`k``s`ksk

Rápido, claro e fácil.

Eu:
"Teorica científica não é jogo de azar. É baseada em conceitos matemáticos bem estabelecidos."
O que não muda o fato de continuar sendo apenas uma teoria.

3 tipos de pessoas (by Linus):

- Os q aprendem para ensinar outros a fazer
- Os q aprendem para mandar outros fazer
- Os q aprendem para fazer e ver rodando

Me identifico + com o terceiro tipo e vc?