Delphi, Smalltalk, Java, C++? Qual destas não é OO?

Nenhuma.

btw… delphi não é linguagem.

É sim, o Object Pascal passou a se chamar Delphi Language. E faz alguns anos já.

Aff, Depende de quem está programando!

Delphi é tanto a ferramenta quanto a linguagem, que é um dos muitos dialetos do Object Pascal(ou Pascal com extensões de objetos). Como a maioria dos compiladores Object Pascal tende a suportar o Delphi, então para todos os efeitos Delphi e Object Pascal acabam sendo a mesma coisa.

A linguagem do delphi tem algumas palavras chaves diferentes, e então mudaram para delphi language, mas são insignificantes.
Tanto é que o free pascal compila projetos delphi sem problema.

É sim, o Object Pascal passou a se chamar Delphi Language. E faz alguns anos já.

Se não me engano a partir do Delphi 8.

É sim, o Object Pascal passou a se chamar Delphi Language. E faz alguns anos já.

Se não me engano a partir do Delphi 8.

Delphi language ou object pascal… ainda continua sendo OO assim como as outras linguagens citadas na dúvida principal do tópico…
Só depende do programador usar a Orientação a Objetos das linguagens…

É sim, o Object Pascal passou a se chamar Delphi Language. E faz alguns anos já.

Se não me engano a partir do Delphi 8.

Delphi language ou object pascal… ainda continua sendo OO assim como as outras linguagens citadas na dúvida principal do tópico…
Só depende do programador usar a Orientação a Objetos das linguagens…
Isso. É possível até mesmo usar conceitos de OO em linguagens como c. O importante é a metodologia.

É sim, o Object Pascal passou a se chamar Delphi Language. E faz alguns anos já.

Se não me engano a partir do Delphi 8.
Acho que a partir do 7. O 8 era o delphi for dotnet, que naum vingou.

http://home.swbell.net/mck9/cobol/ooc/ooc.html

"

marcosalex:

O que você chama de OO?
Todas essas permitem você programar OO, mas a única que OBRIGA é o Smalltalk.

kkkkkkkkkkkkk

OTIMA

Depende do manuuu q tá centado atrás do pc né manuuuuu…

tbm acho isso…

u kara q é bão, u kara q maaaaanja das parada, ele programa em OO em qualuqer linguagee manuuuuu…

até + pessoal fiquem na tranquilidade aé até mais quem tá na potroona aé manuusss… flw-se

Quero ver programar OO em C puro, ou qualquer outra linguagem que não dê suporte a OO…
Tem que ter realmente muito peito…

Quero ver programar OO em C puro, ou qualquer outra linguagem que não dê suporte a OO…
Tem que ter realmente muito peito…

ahh sim. mas dá para fazer. Dá uma olhada no source code do debian. Claro, usando os recursos que a linguagem oferece. O código fica bem legível.

Alguem poderia explicar qual é aquela PALHACADA da linguagem Delphi de ter que extender uma OUTRA classe para poder implementar interfaces ?

Se um objeto possuir implementacoes de interfaces… TEM QUE HERDAR TInterfacedObject e nao TObject…

Procede ?

Procede. Eu não entendi muito bem mas também não me gera nenhum desconforto.

Inté.

Desconforto ? Em uma linguagem onde não existe herança multipla… QUEIMAR a unica possibilidade de herança , herndando um objeto imbecil… eh no minimo “CURIOSA”…

Eu não consigo aceitar Delphi como uma linguagem OO por causa desta besteira… e de outras…

Alguem pode me dizer se procede…

voce nao pode fazer CAST para uma interface diretamente a um objeto se a mesma não IMPLEMENTAR esta interface…

ex:
Interface Animal tem .getNome
e Interface Obeso tem .getNome

se o objeto implementa Animal e eu faco um:

(obj(Objeso)).getNome()

não funciona.

"

chun:

Desconforto ? Em uma linguagem onde não existe herança multipla… QUEIMAR a unica possibilidade de herança , herndando um objeto imbecil… eh no minimo “CURIOSA”…

Eu não consigo aceitar Delphi como uma linguagem OO por causa desta besteira… e de outras…

Alguem pode me dizer se procede…

voce nao pode fazer CAST para uma interface diretamente a um objeto se a mesma não IMPLEMENTAR esta interface…

ex:
Interface Animal tem .getNome
e Interface Obeso tem .getNome

se o objeto implementa Animal e eu faco um:

(obj(Objeso)).getNome()

não funciona.

Não Procede.

posso fazer um cast em qualquer objeto que herda uma classe ou implementa interface .

(objeto as Animal).getNome()

Acabei de testar no Delphi 2009 e continua com esta limitacao besta.

juliocbq:

chun:

Desconforto ? Em uma linguagem onde não existe herança multipla… QUEIMAR a unica possibilidade de herança , herndando um objeto imbecil… eh no minimo “CURIOSA”…

Eu não consigo aceitar Delphi como uma linguagem OO por causa desta besteira… e de outras…

Alguem pode me dizer se procede…

voce nao pode fazer CAST para uma interface diretamente a um objeto se a mesma não IMPLEMENTAR esta interface…

ex:
Interface Animal tem .getNome
e Interface Obeso tem .getNome

se o objeto implementa Animal e eu faco um:

(obj(Objeso)).getNome()

não funciona.

Não Procede.

posso fazer um cast em qualquer objeto que herda uma classe ou implementa interface .

(objeto as Animal).getNome()

eu fiz em cima da interface OBESO que possui a mesma ASSINATURA DE METODO que a interface ANIMAL…

Não funciona ?

marcosalex:

chun:

Alguem poderia explicar qual é aquela PALHACADA da linguagem Delphi de ter que extender uma OUTRA classe para poder implementar interfaces ?

Se um objeto possuir implementacoes de interfaces… TEM QUE HERDAR TInterfacedObject e nao TObject…

Procede ?

É questão de sintaxe, não significa que eles esteja realmente herdando.

type
  TDerived = class(TInterfacedObject, IPaint)
  ...
  end;

De qualquer forma, a partir do Delphi 2005 foi corrigido. Agora ele implementa como as outras linguagens.

Não entendi… voce esta me dizendo que o objeto TDerived não esta herdando TInterfacedObject?

Quero ver programar OO em C puro, ou qualquer outra linguagem que não dê suporte a OO…
Tem que ter realmente muito peito…

ahh sim. mas dá para fazer. Dá uma olhada no source code do debian. Claro, usando os recursos que a linguagem oferece. O código fica bem legível.

Sim, sim, eu também disse que dava… mas o custo disso é bastante alto… e tem que ter uma excelente justificativa para arcar com ele.

Aliás, tá faltando o autor do tópico se manifestar a respeito.

Qual, na concepção dele, não seria OO? E por que?

Ja vi um sistema em java todinho dentro do metodo main de uma unica classe…Ou seja o sistema tinha UMA CLASSE e UM METODO…assustador isso ne? Muito assustador…mas e verdade…e digo mais roda ate hoje em uma empresa…ngm consegue tirar o bicho do ar kkkkkkkkkk

Não,
No caso a classe precisa implementar a mesma interface.

juliocbq:

chun:

eu fiz em cima da interface OBESO que possui a mesma ASSINATURA DE METODO que a interface ANIMAL…

Não funciona ?

Não,
No caso a classe precisa implementar a mesma interface.

pela orientacao a objetos não deveria aceitar ?

chun:

juliocbq:

chun:

eu fiz em cima da interface OBESO que possui a mesma ASSINATURA DE METODO que a interface ANIMAL…

Não funciona ?

Não,
No caso a classe precisa implementar a mesma interface.

pela orientacao a objetos não deveria aceitar ?

sinceramente imagino que não, já que são interfaces distintas, e compartilham somente o mesmo nome de métodos. Posso estar enganado.

Chun, você não está falando de duck typing? Você não pode converter um tipo em outro só porque eles possuem métodos em comum.

Boa pergunta… eh que em JAVA isso é tão trivial… que imaginei que DUAS INTERFACES… QUE IMPLEMENTAO UM MEMTODO DE MESMA ASSINATURA deveriam ser PLUGAVEIS a um OBJETO para execução APENAS DAQUELE METODO…

Pelo visto nao eh assim hehehe…

chun:

Boa pergunta… eh que em JAVA isso é tão trivial… que imaginei que DUAS INTERFACES… QUE IMPLEMENTAO UM MEMTODO DE MESMA ASSINATURA deveriam ser PLUGAVEIS a um OBJETO para execução APENAS DAQUELE METODO…

Pelo visto nao eh assim hehehe…

pois é. oo não tem nada com isso. Isso é regalia de linguagem.

Mas que esse negocio de TInterfacedObject não é coisa de Linguagem OO tmb nao eh.

Chun, vc que é um cara tão fera pelo que vejo nas suas mensagens, implicando com uma questão tão insignificante. Isto nunca me atrapalhou a programar OO no Delphi. Eu hein…

Inté.

A classe TInterfacedObject é realmente uma gambiarra, mas tem seus benefícios - no contexto do Delphi, claro. Acontece que Delphi tem uma interface mãe, IInterface, que contém três métodos em sua assinatura: QueryInterface, _AddRef e _Release. Como Delphi não oferece coleta de lixo, isso é uma forma que os desenvolvedores da linguagem criaram para fazer com que o programador controle as referências a objetos que implementam IInterface. A classe TInterfacedObject fornece uma implementação padrão para os métodos de IInterface, e se não fosse ela sempre que você implementasse uma interface você teria que escrever também esses 3 métodos.

Que xunxo… C++ tmb não tem coletor de lixo e não precisa dessa xunxeira de TInterfacedObject…

Tirando o fato que é uma linguagem de herança simples… ou seja… vc acabou de queimar a UNICA HERANCA que voce poderia ter hehe…

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

Nunca tentei fazer o que vou falar, mas talvez você possa implementar IInterface diretamente e implementar os métodos delegando para TInterfacedObject realizar a tarefa.

marciosantri:

Chun, vc que é um cara tão fera pelo que vejo nas suas mensagens, implicando com uma questão tão insignificante. Isto nunca me atrapalhou a programar OO no Delphi. Eu hein…

Inté.

A questão não é ser insignificante…

Queimar a UNICA HERANCA POSSIVEL em seu sistema…assim… diretamente… é uam questão bem relevante no design de um sistema OO.

chun:

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

polimorfismo.

juliocbq:

chun:

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

polimorfismo.

O polimorfismo nada tem a ver com a instancia da classe… e sim com a classe…

Não existe “intancia de interface”…
nao tem prq se preocupar com “GC” para isso…

chun:

juliocbq:

chun:

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

polimorfismo.

O polimorfismo nada tem a ver com a instancia da classe… e sim com a classe…

Não existe “intancia de interface”…
nao tem prq se preocupar com “GC” para isso…

http://g.oswego.edu/dl/mood/C++AsIDL.html
http://www2.unoeste.br/~aglae/ling_pro/c_exemplos.htm

juliocbq:

chun:

juliocbq:

chun:

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

polimorfismo.

O polimorfismo nada tem a ver com a instancia da classe… e sim com a classe…

Não existe “intancia de interface”…
nao tem prq se preocupar com “GC” para isso…

lembrando que em c++ não se usa interfaces, e sim, classes abstratas.
Exemplos de polimorfismo e interfaces.

http://g.oswego.edu/dl/mood/C++AsIDL.html
http://www2.unoeste.br/~aglae/ling_pro/c_exemplos.htm

Algum motivo para não usar interfaces em C++ ?

Classes absteratas não tem a mesmo intuito de uma interface…
São coisas bem diferentes.

chun:

juliocbq:

chun:

juliocbq:

chun:

Outra coisa que não encaixa…

O que uma INSTANCIA DE UMA CLASSE tem a ver com uma INTERFACE ?

A interface eh apenas um CONTRATO… nada mais…

polimorfismo.

O polimorfismo nada tem a ver com a instancia da classe… e sim com a classe…

Não existe “intancia de interface”…
nao tem prq se preocupar com “GC” para isso…

lembrando que em c++ não se usa interfaces, e sim, classes abstratas.
Exemplos de polimorfismo e interfaces.

http://g.oswego.edu/dl/mood/C++AsIDL.html
http://www2.unoeste.br/~aglae/ling_pro/c_exemplos.htm

Algum motivo para não usar interfaces em C++ ?

Classes absteratas não tem a mesmo intuito de uma interface…
São coisas bem diferentes.

não são não. O conceito interface veio com java.
c++ implementava essa idéia anos antes.

A palavra chave interface veio para suprir problemas causados pela herança múltipla, possivel em c++(aliás, que é uma ferramenta muito boa, se usada com bom senso)

Meu deus…
estou em estado de choque…

Interfaces são CONTRATOS e não IMPLEMENTAÇÔES…

Sim… com elas vc pode dar um “migué” e tentar algo como herança multipla…

type
  TClassePai = class(TInterfacedObject)  // Ao invés de herdar de TObject, herdar de TInterfacedObject
    ...
    ...
  end;

  TClasseFilha = class(TClassePai, IInterface)
    ...
    ...
  end;

Qual o problema nisso?

chun:

Meu deus…
estou em estado de choque…

Interfaces são CONTRATOS e não IMPLEMENTAÇÔES…

Sim… com elas vc pode dar um “migué” e tentar algo como herança multipla…

ai meu deus. Dá uma olhada nos links que te enviei, e releia o que postei.
E não é migué, e caso de necessidade.

para ser mais exato. Leia aqui:

Abstract Classes

Abstract classes can be used to define the C++ version of interfaces. A C++ abstract class describes functionality shared by objects of all concrete classes that are explicitly listed (perhaps indirectly) as subclasses. An object may play multiple roles by inheriting and implementing multiple interfaces. (The language doesn’t directly support notions that an object may play different roles at different times, or that a role is implemented by a collection of objects, but these effects can usually be had in one way or another.)

:shock:

marciosantri:

type
  TClassePai = class(TInterfacedObject)  // Ao invés de herdar de TObject, herdar de TInterfacedObject
    ...
    ...
  end;

  TClasseFilha = class(TClassePai, IInterface)
    ...
    ...
  end;

Qual o problema nisso?

sim... e se TClassePai não herdar TInterfacedObject ?
se TClassePai herdar outra classe. ?

Sua orientacao a objetos comeca a convergir toda para um "SUPER MEGA OBJETO PAI"

O C++ tornou forte o conceito de ABC, que nada mais são que as interfaces do Java.

Para uma classe abstrata ser chamada de ABC, ela deve:

a) Não ter propriedades;

b) Só ter métodos virtuais puros;

c) Ter um destrutor virtual;

Ou seja, rigorosamente idêntico a um interface.

Detalhe que ABC é a sigla de Abstract Base Class.

ABCs não sofrem o problema da herança multipla e não estão sujeitas ao DOD (Diamond of Death).

ViniGodoy…

Muito exclarecedor ! Valeu !

marciosantri:

type
  TClassePai = class(TInterfacedObject)  // Ao invés de herdar de TObject, herdar de TInterfacedObject
    ...
    ...
  end;

  TClasseFilha = class(TClassePai, IInterface)
    ...
    ...
  end;

Qual o problema nisso?

Peixe herda de Animal e implementa Nadador

class Animal {

}

class Peixe extends Animal implements Nadador {

}

TAnimal = class(TInterfacedObject);
TPeixe = class(TAnimal, INadador);

Na verdade, o C++ tem um conceito de interfaces ainda mais abstrato, se levar em consideração o uso de templates.
Com templates, você pode definir uma interface unicamente pelo contrato, e deixar que o C++ crie ou não aquele método, caso a interface atenda o contrato. Não há necessidade de uma classe abstrata ou interface.

Por exemplo, o método abaixo funciona para qualquer coisa que tenha o operador > definido:

//Mytype deve ser uma classe com o operador de > definido

template <class myType>
myType Maximum (myType a, myType b) {
 return (a>b?a:b);
}

Quando eu digo qualquer coisa, quero dizer, numeros:
int x = Maximum(10, 20);

Quero ou uma classe:
BigDecimal x = Maximum(BigDecimal(10), BigDecimal(20));

Note que o código acima restringe a interface única e exclusivamente a:
a) Presença ou não do operador de >
b) Comentário explicando o que esse sinal deveria fazer!

E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é "a mesma coisa que templates".

sim, sim. Postou muito bem vinnie.

Um outro exemplo do que falei. Criei um método fábrica para a minha classe de vetores (matemáticos) assim:

template <class Coords>
Vector createVector (Coords coords) {
 return new Vector(
      static_cast<float>(coords[0]), 
      static_cast<float>(coords[1]), 
      static_cast<float>(coords[2]));
}

O que esse método diz? Que um vetor pode ser criado com quaisquer 3 pontos, desde que eles sejam acessados por índices e que sejam convertíveis para floats…

Portanto, é possível:

a) Passar um array primitivo de float;

b) Passar um objeto da própria classe Vector (que implementa o operador []);

c) Passar um objeto da classe Vector2D, Matrix2D da Ogre2D;

d) Passar um objeto IntVector da Torque.

Dessa forma, pude fazer com que minha engine se integrasse facilmente a outras. Como o contrato dessa fábrica não depende de nenhum supertipo, é possível converter de maneira facílima qualquer tipo de vetor num vetor da minha engine, mesmo um definido através de um array primitivo. Note que aqui é mais um exemplo onde a interface “Coord” restringe-se única e exclusivamente a um contrato, não a uma implementação.

isso é o que dá extrema flexibilidade a essa linguagem.

É, quando eu estava fazendo a SofiaIA, estava meio chateado com o fato da engine física e gráfica terem, cada uma, sua própria classe de vetores. Aí eu ia entrar com meu toolkit de IA, e teria que incluir uma terceira classe dessas…

Então, vi aí uma possíbilidade de trabalhar com a minha classe internamente, enquanto deixava o usuário usar as dele de maneira externa, de maneira muito mais transparente.

tnaires:

marciosantri:

type
  TClassePai = class(TInterfacedObject)  // Ao invés de herdar de TObject, herdar de TInterfacedObject
    ...
    ...
  end;

  TClasseFilha = class(TClassePai, IInterface)
    ...
    ...
  end;

Qual o problema nisso?

Do ponto de vista prático, não há nenhum problema. O que o chun tá questionando - e eu concordo com ele - são as limitações que você é obrigado a tratar porque a linguagem impõe. Se você tem, por exemplo, a seguinte hierarquia:

Peixe herda de Animal e implementa Nadador

Em Java ficaria:

class Animal {

}

class Peixe extends Animal implements Nadador {

}

E em Delphi:

TAnimal = class(TInterfacedObject);
TPeixe = class(TAnimal, INadador);

Veja que, no caso do Delphi, você tem uma classe de domínio acoplada a um conceito estranho ao mesmo.

Certo. Em Java realmente é mais prático. Mas, como o Chun diz em sua assinatura, não precisamos cortar os pulsos por causa disto no Delphi. Nunca tive esse problema todo que ele cita e nem me sinto limitado por causa disto. Pra falar a verdade, comparando com herança propriamente dita, o uso de interfaces é muito baixo. Eu não vejo essa necessidade toda.

Inté.

marciosantri:

tnaires:

marciosantri:

type
  TClassePai = class(TInterfacedObject)  // Ao invés de herdar de TObject, herdar de TInterfacedObject
    ...
    ...
  end;

  TClasseFilha = class(TClassePai, IInterface)
    ...
    ...
  end;

Qual o problema nisso?

Do ponto de vista prático, não há nenhum problema. O que o chun tá questionando - e eu concordo com ele - são as limitações que você é obrigado a tratar porque a linguagem impõe. Se você tem, por exemplo, a seguinte hierarquia:

Peixe herda de Animal e implementa Nadador

Em Java ficaria:

class Animal {

}

class Peixe extends Animal implements Nadador {

}

E em Delphi:

TAnimal = class(TInterfacedObject);
TPeixe = class(TAnimal, INadador);

Veja que, no caso do Delphi, você tem uma classe de domínio acoplada a um conceito estranho ao mesmo.

Certo. Em Java realmente é mais prático. Mas, como o Chun diz em sua assinatura, não precisamos cortar os pulsos por causa disto no Delphi. Nunca tive esse problema todo que ele cita e nem me sinto limitado por causa disto. Pra falar a verdade, comparando com herança propriamente dita, o uso de interfaces é muito baixo. Eu não vejo essa necessidade toda.

Inté.

Hehehe... boa...

A vantagem do uso de interfaces é sempre estar programando independentemente da implementação, isso é muito legal em qualquer sistema... pois com isso , se alguem tem uma ideia nova , ou descorda de algo... pode "implementar aquilo da forma que achar melhor"...
ex:

LinkedList
ArrayList

Ambas implementao a interface List... só que uma é uma lista encadeada e outra uma lista dentro de um array...

Cada qual com suas caracteristicas... mas são listas :)

Constumo utilizar interfaces em tudo onde posso , a API de Java INTEIRA é feito assim..

prefiro muito mais um:

List lista = new LinkedList();

do que:

LinkedList lista = new LinkedList();

"

marcosalex:

TAnimal = class; TPeixe = class(TAnimal, INadador);

Não precisa “queimar” a herança no pai.

Existe SourceCode deste TInterfacedObject?

ViniGodoy:

Na verdade, o C++ tem um conceito de interfaces ainda mais abstrato, se levar em consideração o uso de templates. Com templates, você pode definir uma interface unicamente pelo contrato, e deixar que o C++ crie ou não aquele método, caso a interface atenda o contrato. Não há necessidade de uma classe abstrata ou interface.

Por exemplo, o método abaixo funciona para qualquer coisa que tenha o operador > definido:

//Mytype deve ser uma classe com o operador de > definido

template <class myType>
myType Maximum (myType a, myType b) {
 return (a>b?a:b);
}

Quando eu digo qualquer coisa, quero dizer, numeros:
int x = Maximum(10, 20);

Quero ou uma classe:
BigDecimal x = Maximum(BigDecimal(10), BigDecimal(20));

Note que o código acima restringe a interface única e exclusivamente a:
a) Presença ou não do operador de >
b) Comentário explicando o que esse sinal deveria fazer!

E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é "a mesma coisa que templates".

Templates me lembra como a vida é curta pra perder tempo aprendendo C++. Neste caso é utilizado pra gerar codigo em tempo de compilação. Coisa que em linguagens lazy ou dinâmica com suporte a macros lisp fazem o trabalho de forma infinitamente mais simples.

Todas as linguagens mencionadas pelo autor do tópico são OO. Mas algumas delas são tão arcaicas e complicadas que não vejo motivo pra se preocupar com elas hoje em dia. Apesar do conceito de OO ser o mesmo cada linguagem o implementa de maneira diferente e IMO linguagens como C++ são um péssimo exemplo de projeto de linguagem OO.

Existe, procure na unit System. Se estiver com o Delphi aberto, clique no nome da classe segurando a tecla Ctrl.

O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…

Muito tempo depois… até tinha esquecido deste tópico.

É que caiu em uma prova para uma vaga que estava concorrendo.

Achei estranho pq pelo que eu sabia todas suportam OO…

Mas lembro que escolhi DELPHI, mas tinha certeza q este tb era… hauahauhaahu

Valeu galera…

Abraços
Wanderson

juliocbq:

O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…

Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?

Alguém precisa te dizer, C != C++.

ViniGodoy:

E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é “a mesma coisa que templates”.

Os únicos que ouvi até hoje compararem generics com templates foram programadores C++. Além do mais templates nada mais é do que uma gambiarra para uma linguagem mal projetada. Desnecessário dizer que Lisp faz isso e muito mais.

Se você precisa trabalhar com C++, paciência. Mas fazer apologia dessa merda, pelo amor de Deus. Eu trabalho com Java, mas reconheço que Java, a linguagem e não a plataforma, é uma merda.

mochuara:

Templates me lembra como a vida é curta pra perder tempo aprendendo C++. Neste caso é utilizado pra gerar codigo em tempo de compilação. Coisa que em linguagens lazy ou dinâmica com suporte a macros lisp fazem o trabalho de forma infinitamente mais simples.

Amém.

mochuara:

juliocbq:

O que eu acho mais engraçado, é que você produz críticas sem fundamento. Essas linguagens são arcaicas pelo fato de até hoje serem padrão para desenvolvimento de tecnologia. Tente contestar a INTEL, SUN, Microsoft, CISCO, Apple, Adobe, Corel…

Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?

Alguém precisa te dizer, C != C++.

E qual das que eu citei usam c?

Thiagosc:

ViniGodoy:

E tudo isso é verificado em tempo de compilação. E notem também que isso é infinitamente mais poderoso que os generics, que o povo insiste em dizer que é “a mesma coisa que templates”.

Os únicos que ouvi até hoje compararem generics com templates foram programadores C++. Além do mais templates nada mais é do que uma gambiarra para uma linguagem mal projetada. Desnecessário dizer que Lisp faz isso e muito mais.

Se você precisa trabalhar com C++, paciência. Mas fazer apologia dessa merda, pelo amor de Deus. Eu trabalho com Java, mas reconheço que Java, a linguagem e não a plataforma, é uma merda.

não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.

juliocbq:

não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.

Macros em lisp são processadas e compiladas antes do tempo de execução e não há limites do que você pode fazer, pois todos os recursos da linguagem estão lá. Você pode criar objetos, métodos, funções, gerar código e lógica baseada parâmetros passados pelo usuário.

Ou seja, pode-se fazer tudo com uma sintaxe simples sem impacto algum de performance.

C++ é um lixo. Em pensar que existem milhares de regrinhas toscas e limitações de sintaxe para lhe fornecer 1/100 da flexibilidade e do poder que qualquer linguagem decente dá chega a ser ridículo.

Precisa trabalhar com esse lixo? Azar o seu.

A linguagem C é muito mais simples (e tosca), mas cumpre o papel de “assembly portável”. Qual é o papel de C++? C++ é apenas uma abominação. Pessoas que não conhecem nada melhor são suas principais vítimas.

Obs.: Eu mencionei listas de parâmetros recursivas das macros? Onde pode-se passar uma árvore de objetos e eles são automaticamente desestruturados e ligados a seus respectivos símbolos? Não, né. Aí já seria humilhação demais para os fãs de C++ , coitados.

Thiagosc:

juliocbq:

não fala o que você não conhece e nem nunca usou.
Melhor você provar o porquê de templates ser essa palavra que citou, do que falar coisas sem fundamento, como, “simplesmente é assim”.

Macros em lisp são processadas e compiladas antes do tempo de execução e não há limites do que você pode fazer, pois todos os recursos da linguagem estão lá. Você pode criar objetos, métodos, funções, gerar código e lógica baseada parâmetros passados pelo usuário.

Ou seja, pode-se fazer tudo com uma sintaxe simples sem impacto algum de performance.

C++ é um lixo. Em pensar que existem milhares de regrinhas toscas e limitações de sintaxe para lhe fornecer 1/100 da flexibilidade e do poder que qualquer linguagem decente dá chega a ser ridículo.

Precisa trabalhar com esse lixo? Azar o seu.

A linguagem C é muito mais simples (e tosca), mas cumpre o papel de “assembly portável”. Qual é o papel de C++? C++ é apenas uma abominação. Pessoas que não conhecem nada melhor são suas principais vítimas.

Obs.: Eu mencionei listas de parâmetros recursivas das macros? Onde pode-se passar uma árvore de objetos e eles são automaticamente desestruturados e ligados a seus respectivos símbolos? Não, né. Aí já seria humilhação demais para os fãs de C++ , coitados.

Melhor você prestar atenção no que está dizendo, esses macros também estão presentes em c++. Sobre o papel de c++ não pergunte para mim, pergunte para a Adobe, Corel, Apple, Intel, Sun, CISCO, Microsoft… e lá vai mais um monte, para não dizer que todas usam c++ como padrão de desenvolvimento. Pergunte para eles.

Leia sobre preprocessadores e #define.

Não estou aqui para discutir a melhor linguagem de programação, até porque no meu trabalho, eu tenho poder de escolha, e não preciso ficar me agarrando a marketing para conseguir fatia de mercado.

Desculpem desviar o assunto do tópico, mas já que estamos falando de Lisp…

Para o Thiagosc ou qualquer outro usuário: desculpem a ignorância mas os dialetos do Lisp, como Scheme e Clojure, também possuem esse sistema de macros? Em sua opinião, qual o melhor dialeto de Lisp para se aprender hoje em dia? Clojure é uma boa escolha?

"

Eu também mexi com Scheme quando meu professor passou como trabalho de final de semestre escrever um programa que calculasse a derivada de uma função (!). E tive um contato muito breve com Haskell, tão breve que nem me lembro mais como é.

Clojure perde em alguma coisa para todos esses dialetos?

juliocbq:

Melhor você prestar atenção no que está dizendo, esses macros também estão presentes em c++. Sobre o papel de c++ não pergunte para mim, pergunte para a Adobe, Corel, Apple, Intel, Sun, CISCO, Microsoft… e lá vai mais um monte, para não dizer que todas usam c++ como padrão de desenvolvimento. Pergunte para eles.

Leia sobre preprocessadores e #define.

Não estou aqui para discutir a melhor linguagem de programação, até porque no meu trabalho, eu tenho poder de escolha, e não preciso ficar me agarrando a marketing para conseguir fatia de mercado.

Você parece estar muito mal informado, preprocessador é outra gambiarra maldita. Tosqueira total. Macros de Lisp não tem nada a ver com isso.

Se informe melhor antes de falar besteira. Empresas usam o que bem entenderem, mas isso não significa nada. Esse seu argumento “mas todo mundo usa”, além de não ter nada para suportar tais afirmações, é falta de argumento.

Que o C++ é tosco, isso é fato.

marcosalex:

Engraçado, não sou expert no assunto, mas em todo congresso de compiladores que participei o pessoal citava que uma das maiores desvantagens do Lisp e Clojure sobre o C++ era na performance.

O único dialeto que trabalhei do Lisp foi Scheme na faculdade, mas nunca desenvolvi um aplicativo que poderia avaliar isso, mas gostei da linguagem, embora tenha preferido fazer o mestrado com Haskell.

Não gosto de Scheme porque é muito simples, além de ter umas coisas estranhas (#f, () e nil não são a mesma coisa). Foi projetado para ser simples, e por isso faltam muitas features essenciais. Acho que até pouco tempo atrás não existiam namespaces diferentes por exemplo.

O Clojure eu não sei, mas a julgar pelo seus proponentes acredito que seja mais uma dessas “linguagens rockstar” que nada acrescenta em termos de usabilidade. Até agora não vi nenhum usuário de Clojure explicar em que ela é melhor, apenas citar algumas escolhas sintáticas duvidosas como “vantagens”. Eles dizem que não há interesse em compatibilidade com o passado do Lisp, mas parece que nesse processo jogaram o bebê fora e mantiveram água do banho.

Sobre a performance vai depender da implementação. Common Lisp pode ser compilado para código nativo, o que permite por exemplo que seja usado em jogos de videogame. http://ynniv.com/blog/2005/12/lisp-in-games-naughty-dogs-jax-and.html

Se tiver interesse dê uma olhada em Common Lisp.

Thiagosc:

juliocbq:

Melhor você prestar atenção no que está dizendo, esses macros também estão presentes em c++. Sobre o papel de c++ não pergunte para mim, pergunte para a Adobe, Corel, Apple, Intel, Sun, CISCO, Microsoft… e lá vai mais um monte, para não dizer que todas usam c++ como padrão de desenvolvimento. Pergunte para eles.

Leia sobre preprocessadores e #define.

Não estou aqui para discutir a melhor linguagem de programação, até porque no meu trabalho, eu tenho poder de escolha, e não preciso ficar me agarrando a marketing para conseguir fatia de mercado.

Você parece estar muito mal informado, preprocessador é outra gambiarra maldita. Tosqueira total. Macros de Lisp não tem nada a ver com isso.

Se informe melhor antes de falar besteira. Empresas usam o que bem entenderem, mas isso não significa nada. Esse seu argumento “mas todo mundo usa”, além de não ter nada para suportar tais afirmações, é falta de argumento.

Que o C++ é tosco, isso é fato.

Falar que c++ é tosco, para mim não tem importância nenhuma. O que é preocupante é uma pessoa falar que uma empresa como a Adobe usa c++ por usar. Isso é caso de demência. Como você é melhor que todas elas, deve ser milionário, e sua empresa deve possuir melhores produtos que os destas citadas.

Sobre lisp e preprocessadores, dê uma lida e veja quem está falando besteira.
A única diferença é que linguagens lisps foram desenhadas para funcionar como preprocessadores.
Esse papo de performance, gambiarra que falou não existe.
Faça o seguinte, prove que linguagens lisp são melhores que c++, e deixe de papo furado.

Desde quando na área de computação empresas usam tecnologias por mérito tecnológico? A mera existência da Microsoft, depois de tanto software porcaria e de baixa qualidade que ela produz e produziu, mostra que melhor tecnologicamente não implica sucesso. A fonte da quantidade de idiotas que usam C++ se dá exclusivamente por ignorância, assim como você agora está tentando argumentar com Wikipedia.

Construa um argumento decente.

juliocbq:

Sobre lisp e preprocessadores, dê uma lida e veja quem está falando besteira.
A única diferença é que linguagens lisps foram desenhadas para funcionar como preprocessadores.
Esse papo de performance, gambiarra que falou não existe.
Faça o seguinte, prove que linguagens lisp são melhores que c++, e deixe de papo furado.

http://en.allexperts.com/e/p/pr/preprocessor.htm

Fontes erradas. São duas coisas distintas que funcionam de formas distintas.

Toda a conversão é feita em nível de expressão, isto é, ao contrário de C e outras linguagens onde essa transformação é feita em nível de string de caracteres. Assim como funções abstraem computação, objetos abstraem dados, macros abstraem estruturas de programas baseados em sua representação. Isso permite aos programador imaginar e implementar uma linguagem apropriada para o domínio que deseja descrever (pois no final das contas as macros transformarão o código na representação apropriada).

Continue construindo as suas teses com o Wikipedia. Credibilidade zero.

#define, #ifdef, #endif? Pffff. Pára de viajar. Isso é porcaria. Simplesmente exclui-se strings. Ou substitui-se de uma forma bem primitiva.

Faça o seguinte consulte este livro:

Lisp in small pieces
Christian Queinnec
ISBN: 0 521 54566 8

Essa choradeira de Java e C++, onde algumas pessoas ficam implorando por novas features, jamais existiria em Lisp, porque você pode implementar o que bem entender como bem entender. Por exemplo, na nova especificação do C++ onde excluiram Concepts da versão final e já tinha choradeira na internet. Em Lisp qualquer um poderia implementá-lo sem precisar pedir permissão. AOP? Tranquilo. E por aí vai.

Essas linguagens derivadas de C fazem o programador depender da boa vontade alheia além de não serem flexíveis e nem poderosas o suficiente.

"

Desde quando na área de computação empresas usam tecnologias por mérito tecnológico? A mera existência da Microsoft, depois de tanto software porcaria e de baixa qualidade que ela produz e produziu, mostra que melhor tecnologicamente não implica sucesso. A fonte da quantidade de idiotas que usam C++ se dá exclusivamente por ignorância, assim como você agora está tentando argumentar com Wikipedia.

Construa um argumento decente.

juliocbq:

Sobre lisp e preprocessadores, dê uma lida e veja quem está falando besteira.
A única diferença é que linguagens lisps foram desenhadas para funcionar como preprocessadores.
Esse papo de performance, gambiarra que falou não existe.
Faça o seguinte, prove que linguagens lisp são melhores que c++, e deixe de papo furado.

http://en.allexperts.com/e/p/pr/preprocessor.htm

Fontes erradas. São duas coisas distintas que funcionam de formas distintas.

Toda a conversão é feita em nível de expressão, isto é, ao contrário de C e outras linguagens onde essa transformação é feita em nível de string de caracteres. Assim como funções abstraem computação, objetos abstraem dados, macros abstraem estruturas de programas baseados em sua representação. Isso permite aos programador imaginar e implementar uma linguagem apropriada para o domínio que deseja descrever (pois no final das contas as macros transformarão o código na representação apropriada).

Continue construindo as suas teses com o Wikipedia. Credibilidade zero.

#define, #ifdef, #endif? Pffff. Pára de viajar. Isso é porcaria. Simplesmente exclui-se strings. Ou substitui-se de uma forma bem primitiva.

Faça o seguinte consulte este livro:

Lisp in small pieces
Christian Queinnec
ISBN: 0 521 54566 8

Essa choradeira de Java e C++, onde algumas pessoas ficam implorando por novas features, jamais existiria em Lisp, porque você pode implementar o que bem entender como bem entender. Por exemplo, na nova especificação do C++ onde excluiram Concepts da versão final e já tinha choradeira na internet. Em Lisp qualquer um poderia implementá-lo sem precisar pedir permissão. AOP? Tranquilo. E por aí vai.

Essas linguagens derivadas de C fazem o programador depender da boa vontade alheia além de não serem flexíveis e nem poderosas o suficiente.

Continuar com esse tipo de discução não vai me trazer conhecimento nenhum, já que, você posta e não dá uma referência sequer, confiável ou não, de que dialetos lisp, são melhores que quaisquer outras linguagens.

Sobre a wiki, anos atrás ela já era do nível da Enciclopédia Britânica, para artigos científicos.

Se essas referências não forem confiáveis, existem n outras disponíveis. Basta pesquisar no google:

http://ultimahora.publico.clix.pt/noticia.aspx?id=1242013&idCanal=
http://ciberia.aeiou.pt/gen.pl?p=stories&op=view&fokey=id.stories/3952
http://www1.folha.uol.com.br/folha/informatica/ult124u19402.shtml

Pessoal, e a Orientação a Objetos?

Para a linguagem suportar OO, ela deve possuir uma maneira de trabalharmos com OBJETOS, seja por classes (Java), mimic types (Ioke) ou simplesmente um bloco de código (Javascript).

Quanto ao conceito de Interfaces, nada mais é do que uma classe 100% abstrata e ela meio que te força a usar a maior vantagem da Herança (que NÃO é reaproveitamento de código, já que o acoplamento gerado caga tudo), mas sim a possibilidade de tratar seus objetos com tipos diferentes. Assim como na vida real (já que a OO visa “imitar” a vida real), uma pessoa pode ser tratada como um funcionário ou como um animal (haueheau), dependendo do contexo.

Não sei se é requisito para a linguagem ser considerada OO compliant, mas tem também o polimorfismo (que pode ser implementado utilizando a herança e a sobrescrição de métodos) e encapsulamento (utilizando-se de escopos e níveis de acesso).

marcosalex:

Você deve odiar fazer sites usando o W3C, né? Já que é contra padrões, se postar em um fórum em inglês, você escreveria em brasileiro?

Qualquer um pode implementar e distribuir os recursos que quiser em Java, ele é GPL hoje. O que você pode não conseguir é que sua implementação conste na especificação oficial.

Não, não pode. Java não permite que você acrescente quaisquer features. Para adicionar o que quiser você precisará fuçar na OpenJDK, que não é escrito em Java, e no caso do C++ você precisará criar o seu próprio compilador ou fuçar no GCC.

Lisp permite a adição do que você bem entender sem precisar descer ao nível de compilador ou VM. A linguagem é flexível o suficiente para isso.

São dois mundos diferentes. Entenda a diferença.

Thiagosc:

Não, não pode. Java não permite que você acrescente quaisquer features. Para adicionar o que quiser você precisará fuçar na OpenJDK, que não é escrito em Java, e no caso do C++ você precisará criar o seu próprio compilador ou fuçar no GCC.

Lisp permite a adição do que você bem entender sem precisar descer ao nível de compilador ou VM. A linguagem é flexível o suficiente para isso.

São dois mundos diferentes. Entenda a diferença.

sim, são coisas diferentes mesmo. Ela foi feita para agir como um preprocessador, e mesmo assim, nada que eu eu não possa implementar com

#define #define begin {
#define end }

pronto, agora uso c++ como pascal.

marcosalex:

Você deve odiar fazer sites usando o W3C, né? Já que é contra padrões, se postar em um fórum em inglês, você escreveria em brasileiro?

Qualquer um pode implementar e distribuir os recursos que quiser em Java, ele é GPL hoje. O que você pode não conseguir é que sua implementação conste na especificação oficial.

Não alimente trolls.

juliocbq:

Continuar com esse tipo de discução não vai me trazer conhecimento nenhum, já que, você posta e não dá uma referência sequer, confiável ou não, de que dialetos lisp, são melhores que quaisquer outras linguagens.

Sobre a wiki, anos atrás ela já era do nível da Enciclopédia Britânica, para artigos científicos.

Seja humilde, reconheça que não conhece algo e procure se informar melhor.

Para complementar. Por “representação” eu quero dizer a AST. Em uma linguagem derivada de Algol existe uma gramática arbitrária definida pelo projetista da lingua. Com base nessa gramática um parser é gerado, que transforma as produções em uma AST (Abstract Syntax Tree). A partir dessa AST é que a compilação é feita, podendo ela ser para outra linguagem, código nativo, vm, etc.

Assim é Java, C++, C#, etc.

Lisp é uma AST. Você trabalha diretamente com a árvore. Existem diversas vantagens, como por exemplo a gramática ser super simples e permitir coisas como macros.

No caso do C o preprocessador não está trabalhando com a representação em árvore do código, mas sim com strings. Ele simplesmente substitui texto a partir de regras muito simples. Em Lisp você recebe uma árvore por parâmetro, retorna uma árvore como resultado e esse novo ramo substitui a chamada da macro na árvore de representação.

Funciona mais ou menos assim a grosso modo:

C

• preprocessador atualiza texto;
• parser transforma o resultado em uma AST;
• compilador compila para alguma plataforma.

Lisp

• o reader transforma o código em uma árvore;
• as macros são expandidas, e seus respectivos locais de chamada na árvore são substituídos por sub-árvores;
• é interpretado ou compilado para alguma plataforma;

Isso permite por exemplo:

código original:                             código transformado

- rotina1                                         - rotina1
-- instrução 1                                 -- instrução 1
-- instrução 2                                 -- instrução 2
-- macro (setf (car x) y)                  -- rplaca x y
-- instrução 3                                 -- instrução 3
-- instrução 4                                 -- instrução 4

- rotina1                                         - rotina1
-- instrução 1                                 -- instrução 1
-- instrução 2                                 -- instrução 2
-- macro (setf (symbol-value z) y)  -- setq x y
-- instrução 3                                 -- instrução 3
-- instrução 4                                 -- instrução 4

E dentro da macro setf ele inspeciona os parâmetros passados e se for car ele retorna uma instrução (poderia ser uma seqüência de instruções) e se for outra coisa ele retorna outra coisa.

Dá para criar classes, objetos, funções, etc, desse jeito. Portanto dá para otimizar o código em formas que são impossíveis em linguagens como C++.

"

Thiagosc:

Seja humilde, reconheça que não conhece algo e procure se informar melhor.

Para complementar. Por “representação” eu quero dizer a AST. Em uma linguagem derivada de Algol existe uma gramática arbitrária definida pelo projetista da lingua. Com base nessa gramática um parser é gerado, que transforma as produções em uma AST (Abstract Syntax Tree). A partir dessa AST é que a compilação é feita, podendo ela ser para outra linguagem, código nativo, vm, etc.

Assim é Java, C++, C#, etc.

Lisp é uma AST. Você trabalha diretamente com a árvore. Existem diversas vantagens, como por exemplo a gramática ser super simples e permitir coisas como macros.

No caso do C o preprocessador não está trabalhando com a representação em árvore do código, mas sim com strings. Ele simplesmente substitui texto a partir de regras muito simples. Em Lisp você recebe uma árvore por parâmetro, retorna uma árvore como resultado e esse novo ramo substitui a chamada da macro na árvore de representação.

Funciona mais ou menos assim a grosso modo:

C

• preprocessador atualiza texto;
• parser transforma o resultado em uma AST;
• compilador compila para alguma plataforma.

Lisp

• o reader transforma o código em uma árvore;
• as macros são expandidas, e seus respectivos locais de chamada na árvore são substituídos por sub-árvores;
• é interpretado ou compilado para alguma plataforma;

Isso permite por exemplo:

código original:                             código transformado

- rotina1                                         - rotina1
-- instrução 1                                 -- instrução 1
-- instrução 2                                 -- instrução 2
-- macro (setf (car x) y)                  -- rplaca x y
-- instrução 3                                 -- instrução 3
-- instrução 4                                 -- instrução 4

- rotina1                                         - rotina1
-- instrução 1                                 -- instrução 1
-- instrução 2                                 -- instrução 2
-- macro (setf (symbol-value z) y)  -- setq x y
-- instrução 3                                 -- instrução 3
-- instrução 4                                 -- instrução 4

E dentro da macro setf ele inspeciona os parâmetros passados e se for car ele retorna uma instrução (poderia ser uma seqüência de instruções) e se for outra coisa ele retorna outra coisa.

Dá para criar classes, objetos, funções, etc, desse jeito. Portanto dá para otimizar o código em formas que são impossíveis em linguagens como C++.

Numa boa thiago, eu nunca disse que dialetos lisp não funcionavam dessa maneira, aliás disse o contrário, que elas são como preprocessadores. Da mesma maneira não fico pregando sobre linguagens. O que eu disse, é que o preprocessador me permite mudar as sintaxes da linguagem c++, da mesma maneira que lisp permite. O link que te passei sobre preprocessadores mostra isso.

Sobre c++, essas empresas citadas a usam até hoje devido a alta otimização de código, que seu compilador pode gerar no assembler final(executável pequeno, mínimo overhead, etc…), baixo nível(assembler inline) e flexibilidade da mesma. O melhor exemplo é o compilador INTEL, que é imbatível. A própria MS usa o INTEL em seus SOs. Lisps não são úteis para isso.

Para falar que uma linguagem ou compilador, são ruins, no mínimo você precisaria ser doutor na área de compiladores.
cada pessoa se adapta na linguagem que se sente mais confortável.

juliocbq:

mochuara:

Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?

Alguém precisa te dizer, C != C++.

E qual das que eu citei usam c?

Até relógio cuco roda C, o fato da Intel usar C++ não diz nada sobre portabilidade de coisa alguma.

Vc não sabe nem mesmo a diferença entre C e C++ que dira o que essas empresas usam. Empresa de ponta usa a melhor ferramenta para cada problema, não existe essa de linguagem padrão.

marcosalex:

Engraçado, não sou expert no assunto, mas em todo congresso de compiladores que participei o pessoal citava que uma das maiores desvantagens do Lisp e Clojure sobre o C++ era na performance.

O único dialeto que trabalhei do Lisp foi Scheme na faculdade, mas nunca desenvolvi um aplicativo que poderia avaliar isso, mas gostei da linguagem, embora tenha preferido fazer o mestrado com Haskell.

Performance de que? Execução?

Deve ter sido a muito tempo, antes de inventarem linguagens compiladas.

Eu também mexi com Scheme quando meu professor passou como trabalho de final de semestre escrever um programa que calculasse a derivada de uma função (!). E tive um contato muito breve com Haskell, tão breve que nem me lembro mais como é.

Clojure perde em alguma coisa para todos esses dialetos?

O fato de ja ter sido um Lisper te da vantagem pelo fato de todos os Lisp compartilharem do mesmo “DNA”. Mas é como qualquer outra linguagem moderna que serve tanto pra script quanto para programação concorrente e alta performance na JVM e .NET.

marcosalex:

Yes, we can

http://openjdk.java.net/legal/

Você pode acrescentar o que quiser, inclusive criar o “Tava” (Thiago Java), a única coisa que vai acontecer é que a Sun pode não usar sua feature.
…

Esse aí se finge de mal entendido. Metaprogramação e Lisp nada tem a ver com programar compiladores. Não é a toa que Lisp é conhecido como “The programmable programming language”.

Scheme de fato já foi mais utilizado em inciacao cientifica e clojure parece que não tem muitos adeptos aqui no fórum apesar de falarem bastante em outros foruns. Pelo que vi ela parece ter tudo que um Lisp precisa ter. Obviamente não estou falando dos seus proponentes.

mochuara:

juliocbq:

mochuara:

Sério que todas essas empresas usam C++ como “padrão” de desenvolvimento?

Alguém precisa te dizer, C != C++.

E qual das que eu citei usam c?

Até relógio cuco roda C, o fato da Intel usar C++ não diz nada sobre portabilidade de coisa alguma.

Vc não sabe nem mesmo a diferença entre C e C++ que dira o que essas empresas usam. Empresa de ponta usa a melhor ferramenta para cada problema, não existe essa de linguagem padrão.

Vai me responder ou não, qual das citadas usam c?
Qual das citadas não é empresa de ponta?

fala-se muito, prova-se pouco aqui. Fui.

Chegando tarde, mas enchendo o saco. Seguinte:

• Linguagem que usa conceito de objetos, mas não permite herança e polimorfismo, está “classificada” do jeito errado. Não é ORIENTADA a objetos, é BASEADA em objetos (como foi Javascript um dia).
• Declarar um ‘class’ não quer dizer que aquilo seja realmente uma classe, ora bolas. A linguagem (como foi dito por alguém antes de mim, aqui) Java é classificada, de 1 a 5 (regular… ótima) como uma linguagem nível 2, RUIM. Não vou enumerar os fatores, eu lembro que até fiz um trabalho disso na faculdade. Em matéria de legibilidade, por exemplo, Python transforma Java em aramaico… dá um baile. Só que a PLATAFORMA é que transforma o trabalho com Java um negócio legal.
  Se eu enfiar TUDO num método main, como foi dito antes, a coisa funciona, certo? Certo. Vai ficar uma naba, mas funciona. E a máquina virtual executa o programa de que forma? Uma máquina de pilha. Ele reconhece os passos como… métodos. Área de métodos, como ‘text segments’. Isso aí. GOTO.
  Isso faz com que algumas fontes citem Java como uma linguagem orientada a MÉTODO, e não a objeto.
  Obviamente, trabalhar com OO e Java, pra mim tá ótimo e me dou muito bem… mas lendo, pesquisando e levando opiniões prós e contra… eu concordo.
  Orientada a Objeto MESMO? Pelo conceito, de verdade… SmallTalk e Ruby… de resto, a gente faz OO pq tem juízo e não quer se arrombar depois.
  Abraço!

Trabalho de Faculdade… On

E o que me impede de pegar uma linguagem OO e fazer porco?

No fim das contas tudo vira instrução de processador… Se formos entrar nesse mérito, perdemos o foco…

Eu nunca consegui entender bem essas afirmações de “só Smaltalk é realmente OO” porque quem fala nunca explica. No fim das contas se a linguagem PERMITE trabalharmos com objetos, acho que ela é OO. Se é MAIS FACIL ou não aí já é outra história, não tem essa de “a linguagem X é mais OO”, ou ela permite trabalharmos com objetos ou não permite.

E o que me impede de pegar uma linguagem OO e fazer porco?

No fim das contas tudo vira instrução de processador… Se formos entrar nesse mérito, perdemos o foco…

Eu nunca consegui entender bem essas afirmações de “só Smaltalk é realmente OO” porque quem fala nunca explica. No fim das contas se a linguagem PERMITE trabalharmos com objetos, acho que ela é OO. Se é MAIS FACIL ou não aí já é outra história, não tem essa de “a linguagem X é mais OO”, ou ela permite trabalharmos com objetos ou não permite.

SmallTalk não possui tipos ‘não-objetos’, digamos assim… estruturas de controle como if, por exemplo, é usado com mecanismos de mensagem entre objetos, e não diretamente. E quanto a perder o foco, eu discordo: eu não fui LÁÁÁ no baixo nível, fui na máquina virtual, o que todos que trabalham com a linguagem devem saber como funciona, e a de Java é uma máquina de pilha. Se é ‘mais’ OO que a outra, acho que isso não existe. Ou É ou NÃO É, não tem meio termo. Se a linguagem permite, mas não obriga, não é OO. OO, nesse caso, fica abstraída, você é quem faz, por mais bizarro que isso possa parecer.
Enfim, trabalhar com Java sem OO é suicídio; mas que no final das contas, a estrutura da linguagem não é OO, isso é o diz a literatura da área de compiladores (e não eu, que sinceramente não tenho conhecimento para analisar fortemente o caso e opinar sobre isso). Abraços!

Não é porque a linguagem não te obriga que ela não seja OO. Ela não seria somente se não tivesse recursos para trabalharmos OO.

De onde tirastes isso? Desde quando é com base nisso que podemos definir a linguagem? Eu posso programar em Java orientado a aspectos… isso quer dizer que ela é orientada a aspectos, também?

Não. Na verdade você não pode trabalhar com aspectos em Java. Você pode simular isso. Não é nativo do Java suportar aspectos. Exemplo, aspectj:

Extension.

Não. Na verdade você não pode trabalhar com aspectos em Java. Você pode simular isso. Não é nativo do Java suportar aspectos. Exemplo, aspectj:

Extension.

E daí que é uma extensão? Eu posso trabalhar com Aspectos, seja isto nativo ou não. É só pra te mostrar que teu argumento de ‘dar suporte’ é furado.
Como eu falei, não é ISSO que define ela ser OO ou não, entendeu? Não faz ela ser melhor ou pior, por favor, não se ofenda. Só estou tentando entender de onde vem o teu conceito. Porque se é só por ‘dar suporte’, nenhuma linguagem é mais nada, e nem deixa de ser. Sacou?

Em C não tenho polimorfismo porque não tenho herança nem sobrescrição. Então C não da suporte pra polimorfismo.

Hein? Cara, eu fiz uma metáfora… ou tu achas que eu saio por aí tentando programar usando Orientação a aspectos usando Algol?

Do fundo do meu coração: desisto.

Abraços!

Não desista assim de mim… buaaaaaaaaa…

Não desista assim de mim… buaaaaaaaaa…

auiehiuaeheauiheiuaeiua

Coisas desse tipo me fazem esquecer que é segunda-feira =P

Fiquei curioso com a situação dessa thread. Vou desenterrar as fontes que usei pr’aquele trabalho, e quem sabe poste algo aqiu.

Abraços!

Programar por programar OO até em C dá pra fazer, é só ver a API do GTK.

É nem fale, depois do trampo ainda tem facul =/

Hum, como ela funciona?

Union -> pense nisso

a cabeça de alguns aqui é muito dura. É preferível deixar pra lá que ficar discutindo sobre o que dá pra fazer com c ou java, ou smalltalk. É que nem time de futebol, religião e política.

Por que vocês se incomodam tanto se alguem não concorda com a opinião de vocês?

Não sei se vc percebeu, mas o intuito de um fórum não é ficar mudando opinião dos outros, mas sim gerar informação útil para que qualquer um que venha acessá-lo algum dia. Esse tipo de discussão pode parecer inútil e até é inútil quando o pessoal fica postando coisas que não agregam nada ao assunto do tópico. Por mais que as pessoas não concordem umas com as outras, elas vão postando seus argumentos e assim gerando informação útil para uma futura pesquisa, o que contribui para a disseminação da informação. Se não concorda é simples: ou você aperta Alt+F4 ou posta alguma informação útil provando que o ponto de vista do menino não está correto.

Por que vocês se incomodam tanto se alguem não concorda com a opinião de vocês?

Não sei se vc percebeu, mas o intuito de um fórum não é ficar mudando opinião dos outros, mas sim gerar informação útil para que qualquer um que venha acessá-lo algum dia. Esse tipo de discussão pode parecer inútil e até é inútil quando o pessoal fica postando coisas que não agregam nada ao assunto do tópico. Por mais que as pessoas não concordem umas com as outras, elas vão postando seus argumentos e assim gerando informação útil para uma futura pesquisa, o que contribui para a disseminação da informação. Se não concorda é simples: ou você aperta Alt+F4 ou posta alguma informação útil provando que o ponto de vista do menino não está correto.

Concordo até o ponto “útil”, que você escreveu. Tem muita coisa que não é útil, como:

java não é OO, C++ não te obriga a programar OO, C é arcaico, lisp é isso,…e por ae vai.

O que você aprendeu com isso?

“juliocbq”:

Concordo até o ponto “útil”, que você escreveu. Tem muita coisa que não é útil, como:

java não é OO, C++ não te obriga a programar OO, C é arcaico, lisp é isso,…e por ae vai.

O que você aprendeu com isso?

Então… o problema nem é tanto falar que Java não é OO ou que C++ não te obriga a programar OO. O problema é afirmar isso e não mostrar nenhum argumento. Eu acho legal quando o cara fala, mesmo equivocado, mas ele tem algum argumento plausível pra afirmar aquilo, até porque a gente não nasce sabendo. Agora vir falar que não gosta de Java porque o simbolo é azul e vermelho não é muito construtivo.

Pelo menos a discussão me fez atentar para Lisp, que possui recursos realmente interessantes.

Pelo menos a discussão me fez atentar para Lisp, que possui recursos realmente interessantes.
toda linguagem tem recurso interessante.

Link_pg:

“juliocbq”:

Concordo até o ponto “útil”, que você escreveu. Tem muita coisa que não é útil, como:

java não é OO, C++ não te obriga a programar OO, C é arcaico, lisp é isso,…e por ae vai.

O que você aprendeu com isso?

Então… o problema nem é tanto falar que Java não é OO ou que C++ não te obriga a programar OO. O problema é afirmar isso e não mostrar nenhum argumento. Eu acho legal quando o cara fala, mesmo equivocado, mas ele tem algum argumento plausível pra afirmar aquilo, até porque a gente não nasce sabendo. Agora vir falar que não gosta de Java porque o simbolo é azul e vermelho não é muito construtivo.

Com certeza. O tópico vira um bate-papo de esquina, onde um critica o outro e não fala o porque.

para aqueles que se interessaram pelo Lisp, um negócio muito útil é este

faz muuuuito tempo que eu não uso isso, mas dava para agilizar muitas coisas - tb acho que quase ninguem usa emacs para programar hoje em dia.

André Fonseca:

para aqueles que se interessaram pelo Lisp, um negócio muito útil é este

faz muuuuito tempo que eu não uso isso, mas dava para agilizar muitas coisas - tb acho que quase ninguem usa emacs para programar hoje em dia.

O Stallman que gosta disso. O próprio emacs pode ser extendido de uma maneira sem limites com lisp.