| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | por Anonimo Cobarde em 05-01-03 3:09 GMT (#2)
|
| | link alternativo btw:..
monster.com hotjobs.com dice.com %
Java 2739 1000 1957 27.82%
C++ 2103 1000 1534 22.65%
Visual Basic 2070 969 1127 20.35%
Perl 955 517 577 10.01%
Javascr1pt 925 455 498 9.17%
C# 290 235 183 3.46%
Ada 384 175 57 3.01%
Fortran 124 68 48 1.17%
Scheme 39 138 46 1.09%
Python 58 43 33 0.65%
Smalltalk 42 27 32 0.49%
Lisp 12 4 9 0.12%
9741 4631 6101
|
| | | | | | Object Pascal não é nem mencionada... 8-( Digam o que quiserem, ma IMHO Object Pascal é a mais adequada em uns 75% das aplicações existentes hoje. Se economizaria um bocado de grana com desenvolvimento se alguns dos projetos que eu conheço fossem executados com OPascal ao invés de C++.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Object Pascal é a mais adequada em uns 75% das aplicações existentes hoje.
Se te referes a substituir a tralha feita em VB por Delphi/Object Pascal concordo. Acredito que não se faria tanto programinha nojento como os saídos do VB...
Se economizaria um bocado de grana com desenvolvimento se alguns dos projetos que eu conheço fossem executados com OPascal ao invés de C++.
Isso é muito duvidoso. Nem todos os projectos são adequados para serem desenvolvidos num ambiente RAD, além disso projectos executados em C++ têm normalmente mais qualidade e são mais robustos (não necessáriamente uma feature da linguagem mas dos conhecimentos de quem nela desenvolve e no método de desenvolvimento) e são mais rápidos (se a performance for importante é uma vantagem).
-- Carlos Rodrigues
|
| | | | | Isso é muito duvidoso. Nem todos os projectos são adequados para serem desenvolvidos num ambiente RAD, além disso projectos executados em C++ têm normalmente mais qualidade e são mais robustos (não necessáriamente uma feature da linguagem mas dos conhecimentos de quem nela desenvolve e no método de desenvolvimento) e são mais rápidos (se a performance for importante é uma vantagem). Hamm... como e' que a *linguagem* utilizada afecta a robustez ? Que digas que podem resultar em binarios que executam mais rapidamente, ok, mas robustez e "qualidade" sao independentes da linguagem utilizada (assumindo, claro, compiladores/interpretadores sem bugs).
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | Acho que as minhas palavras foram ligeiramente mal compreendidas...
"não necessáriamente uma feature da linguagem mas dos conhecimentos de quem nela desenvolve e no método de desenvolvimento".
Se é um mito/meia verdade ou não fica ao critério do leitor...
-- Carlos Rodrigues
|
| | | | | Não, A linguagem utilizada é das coisas que mais afecta a robustez de um dado programa, logo a seguir à experiência e qualidade do programador, NMO. - A "elegância" ou "coerência consigo mesma", os subterfúgios que a linguagem tenha/favoreça (várias maneiras de fazer a mesma coisa, muitos pequenos truques)
- A legibilidade do código
- A facilidade de reutilização do código
- A manipulação explícita ou implícita de memória (c, c++, java Vs. scheme, lisp, ML)
- O grau de "tipificação" das variáveis (poucos Vs. muitos tipos distintos de varíaveis, o que ajuda na detecção de erros semânticos)
- O tamanho da linguagem
Todos estes (e certamente muitos outros) pontos influenciam enormemente do desenvolvimento que por sua vez se reflecte obviamente na qualidade do programa/resultado.
|
| | | | | Os pontos que indicas (e bem), teem sem duvida a ver com a "qualidade" do codigo do ponto de vista de re-utilizacao e "mantenibilidade" (dum ponto de vista de engenharia de software). Mas em termos de "robustez" parece-me haverem muitos outros factores mais importantes. A nao ser que te tenha percebido mal, e quereres dizer que uma linguagem mais "maintainable" oferece ao longo da vida do software mais qualidade em termos de produto final, com o qual eu concordo.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | Exactamente, os pontos que referi têm a ver sobretudo com uma visão do ponto de vista da Engenharia de Software.
Sim, acredito que uma linguagem mais "maintainable" tende a oferecer mais robustez ao longo do tempo de vida de um projecto de média dimensão. Já em larga escala, penso que a linguagem usada perde importância em detrimento de coisas como uma boa arquitectura do sistema, APIs bem estruturadas, modularização, factorização, etc...
(se bem que muitas destas últimas estão de alguma forma dependentes da linguagem usada)
Mas, dizias, quais são os outros factores que reconheces serem mais importantes para a robustez de um programa?
|
| | | | | Mas, dizias, quais são os outros factores que reconheces serem mais importantes para a robustez de um programa? Two simple words: unit and testing :-)
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Nem todos os projectos são adequados para serem desenvolvidos num ambiente RAD. Sem querer ser chato, eu disse "Object Pascal", não Delphi ou Kylix.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Indica então compiladores de Object Pascal maduros que não o Delphi ou Kylix. Freepascal?
-- Carlos Rodrigues
|
| | | | Só que eu não estava a falar disso. Eu estava a justificar a minha associação do Object Pascal como uma linguagem que actualmente ainda só está implementada como deve ser para os ambientes RAD Delphi ou Kylix (que acabam por quase ser o mesmo). Não vou instistir nestes dois porque não sei até que ponto se pode deitar fora o ambiente RAD e se pode usar os seus compiladores de uma forma independente (pelo menos para projectos significativos). O freepascal era a outra única opção que me ocorreu mas não o considero ainda como uma alternativa válida (opinião completamente arbitrária derivada de nunca o ter usado).
PS: o facto de referires "não maduros o suficiente para entrarem em produção" derrota completamente a ideia de os usar como substituto do C++ em projectos de "produção".
-- Carlos Rodrigues
|
| | | | Ok. Na sua opinião, então, se não pode entrar em produção, não pode deve usado. Se não deve ser usado, não gaste tempo e dinheiro pesquisando, certo?
Se o teu argumento era reduzir as despesas em projectos de TI usando Object Pascal em vez de C++ para isso têm de existir ferramentas em estado de produção. Caso contrário vais estar a gastar mais dinheiro na pesquisa, logo o resultado final é a mesma despesa ou mais despesa.
Dou graças à Deus das pessoas que construíram o Linux nos últimos 10 anos não pensarem como vc. Vc mistura conceito com implementação.
Não, tu é que estas a misturar o potencial do Object Pascal em projectos como substituto do C++ com a sua capacidade de o fazer hoje. Pegando no teu argumento, hoje o Linux está em estado de produção, mas isso nem sempre foi verdade. Ninguém tentava empurrar o Linux para projectos de produção quando ele não tinha essa capacidade. É isso que diferencia um projecto cujo objectivo é pesquisar/desenvolver para projectos futuros e outro cujo objectivo é ir para produção.
Object Pascal, pelo menos IMHO, É mais adequada para a maioria dos projetos de T.I. que eu conheço. Concordo com vc que faltam opções de COMPILADORES, mas isto, ao contrário do que vc argumenta, NÃO invalida meu argumento.
Tirando da ideia o Object Pascal como linguagem associada a ambientes RAD, não posso argumentar se é ou não mais adequado pois acaba por ser uma questão de gosto pela linguagem, o que influencia a visão sobre o que é mais adequado ou não (eu acho o Pascal excessivamente verboso por isso não sou imparcial).
Agora pegando no que dizes por outro lado, eu concordo que o Object Pascal é adequado a uma grande parte dos projectos de TI mas actualmente apenas aqueles que recorrem a RAD pois como eu disse acima, para substituir os projectos para os quais o C++ é adequado é preciso ferramentas do mesmo nível hoje. E sim isto invalida o teu argumento (ou parte dele).
-- Carlos Rodrigues
|
| | | | | E sim isto invalida o teu argumento (ou parte dele). Ok, ok!! Se eu mudar a frase para "seria mais adequada", vc deixa de pegar no meu pé???? ;-)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | projectos executados em C++ têm normalmente mais qualidade e são mais robustos (não necessáriamente uma feature da linguagem mas dos conhecimentos de quem nela desenvolve e no método de desenvolvimento) e são mais rápidos (se a performance for importante é uma vantagem). Não concordo. Existem sim sistemas que são melhor projetados usando herança múltipla e outroas coisas que só a C++ tem, mas a falta de um gerenciamento decente de bibliotecas do C (que influencia em C++), sua terrível tipagem, pra não falar na sintaxe não colaboram para baratear os custos da execução dos projetos típicos em T.I. Compiladores, Sistemas Operacionais, coisas que o valham não são a maioria das aplicações existentes (e mesmo assim, há quem prefire os Pascal alike da vida, como o projeto Oberon). A grande maioria dos projetos de software neste mundo pouco se valem de herança múltipla. Ao contrário, muitos são essencialmente hierárquicos (banco de dados, por exemplo) com o uso da Orientação à Objetos como ferramenta de abstração de interface ou de acesso à recursos de dados. Problemas de tipagem, escopo, visibilidade, que em C++ são tratados caso à caso pelo programador, são resolvidos de forma automática pelo compilador OPascal (funções primas, amigas, irmãs, sei lá... isto me cheira mais à incesto que programação!! (^: ). Se vc é programador profissional, vc sabe que mais da metade dos bugs feios de programação ocorrem aqui. A outra metade vem da alocação dinâmica de memória (e aqui, acho que só Java e Oberon realmente solucionam o problema de forma satisfatória - omiti .NET por não conhecer esta ferramenta). Vc valou em performance, mas eu te afirmo que hoje em dia performance não está mais vinculada à linguagem como ocorria nos tempos dos 8 ou 16 bits. Os compiladores OPascal hoje estão suficientemente maduros para gerar um código tão bom quando o C++ (pelo menos na maioria dos casos). A maioria das técnica de otimização de geração de código que realmente fazem diferença não estão ligadas à nenhuma linguagem de programação : podem ser implementadas para qualquer linguagem. O compilador é o diferencial aqui, não a linguagem. Quanto à qualidade, vc está terrivelmente equivocado. O processo de garantia de qualidade de software é muito, mas muito mais extenso que a escolha da linguagem de programação, embora eu concorde com o post do vaf que afirma que a LP é uma das escolhas mais críticas. Posso sugerir que vc pesquise sobe "Unified Change Management"? Qualidade é um processo.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | Por exemplo o Lisp vem mencionado, no entanto so' conheco um porgama feito em Lisp para windoze, o Autocad. O Autocad nao foi desenvolvide em Lisp. O Autocad tem sim uma "API" e um interpretador Lisp -- nao e' a mesma coisa.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | E o C? (Pontos:3, Informativo) |
| | O C é muito diferente de C++ ou C# e não foi tido em conta... mesmo sendo a linguagem de programação mais usada (pelo menos a avaliar pelas estatísticas da freshmeat e do sourceforge!
Isso e a maioria das linguagens em questão deixa-me a pensar alguma coisa sobre a objectividade deste inquérito :)
|
| | | | | | Eu tenho andado a tentar aprender java (swing), logo ando a fazer buscas mais ou menos frequentes sobre o assunto.
C++ ja conheco mais ou menos bem, sendo a minha linguagem de eleição. O C só uso se for obrigado a isso. Uso C com mais frequencia que desejaria devido à sua ubiquidade.
## I live the way I type; fast, with a lot of mistakes. |
| | | | O C só uso se for obrigado a isso. Uso C com mais frequencia que desejaria devido à sua ubiquidade.
O que é que tens contra o C?
-- Carlos Rodrigues
|
| | | | Somente que gosto muito mais de programar em c++.
Apesar de c++ ser (na sua globalidade) mais complexo e extenso que c, é também mais flexível já que não é necessário saber todos os truques para programar alguma coisa.
Além disso, dá pica. Descobri a pouco tempo como fazer metaprogramas, quando andava a ver http://www.oonumerics.org/blitz/. Ainda nao sei em que ocasioes tal me vai ser util, ainda para mais porque é dificil escrever e reler o codigo, mas a utilidade por vezes é segundária ;)
----------
// Define uma 'funcao' power3 cujos argumentos tem
// que ser constantes aquando da compilação:
template
struct power3
{
template static F calc(F x){
F s = power3::calc(x);
return s*s * power3::calc(x);
}
};
template
struct power3
{
template static F calc(F x){
return x;
}
};
template
struct power3
{
template static F calc(F x){
return 1;
}
};
## I live the way I type; fast, with a lot of mistakes. |
| | | | Esta é melhor:
template
inline int power( int b ) {
int a = power(b*b);
return E & 1 ? b*a : a;
}
template
inline int power( int ) {
return 1;
}
Os fanáticos do C que façam melhor :p
|
| | | | Os fanáticos do C que façam melhor :p
Se explicares onde está a utilidade disso além de pura academência talvez os fanáticos do C ponderem gastar o seu tempo a tentar fazer melhor...
-- Carlos Rodrigues
|
| | | | são exercicios pedagogicos.
## I live the way I type; fast, with a lot of mistakes. |
| | | | Como seguir a linha pontilhada com o lápis??? 8-D (desculpe, não resisti!!)
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | O c++ é uma aberração. Recentemente descobriu-se que os templates associados a constantes implementam uma máquina de turing completa. Ou seja, um compilador de C++ é ele próprio um interpretador/compilador de uma sublinguagem. Sinceramente isto é demais para mim. Para isso continuava a escrever self-modifying code em assembler e se não chegasse, aumentávamos o nivel de indirecção (código que modifica código que modifica código...) Quanto ao teu "desafio" , não é possivel faze-lo (facilmente) em C porque o seu macro processador é algo limitado. (*** mas ver uma das entradas do IOCCC em que implementavam um factorial via pre-processador unicamente! mas isso era feito via multipla inclusao condicional do proprio ficheiro). Um dos meus desejos numa "wish list" de C era ter um pre-processador algures entre o que existe e entre o m4 de unix. O preprocessador de C nao suporta recursividade nem avaliacao de constantes ao nivel das macros (i.e. podes fazer #ifdef ou #ifndef de constantes, ou ainda #if expressão, mas nao o podes fazer ao nivel de um #define). Mas voltanto ao assunto -- o teu truque (e outros do estilo) servem para optimizar codigo, evitanto fazer calculos em runtime quando podem ser feitos em compile time. Isso pode ser feito com um macro processador suficientemente flexivel, como o m4:
define(`fact', `ifelse($1,1,1,`eval($1*fact(eval($1-1)))')')
fact(12)
479001600
-- carlos |
| | | | Para começar devo dizer que apesar de achar que o C++ é uma linguagem cheia de gorduras desnecessárias (com toda a gente tendo a liberdade de escolher o seu subset de features para fingir que isto não é verdade) não sou anti-C++ - nem pouco mais ou menos - e é até a minha segunda linguagem de eleição a seguir ao C (com o Java logo atrás).
Apesar de c++ ser (na sua globalidade) mais complexo e extenso que c, é também mais flexível já que não é necessário saber todos os truques para programar alguma coisa.
Não estou a ver que tipo de truques é preciso saber para programar alguma coisa em C além de "saber programar minimamente".
Além disso, dá pica. Descobri a pouco tempo como fazer metaprogramas, quando andava a ver http://www.oonumerics.org/blitz/. Ainda nao sei em que ocasioes tal me vai ser util, ainda para mais porque é dificil escrever e reler o codigo, mas a utilidade por vezes é segundária ;)
Metaprogramas... se queres fazer programas com o mesmo grau de utilidade e ainda mais ilegíveis aconselho-te antes o "The International Obfuscated C Code Contest". É capaz de dar mais pica...
-- Carlos Rodrigues
|
| | | | | Para começar devo dizer que apesar de achar que o C++ é uma linguagem cheia de gorduras desnecessárias (com toda a gente tendo a liberdade de escolher o seu subset de features para fingir que isto não é verdade) não sou anti-C++ - nem pouco mais ou menos - e é até a minha segunda linguagem de eleição a seguir ao C (com o Java logo atrás). Quais "gorduras desnecessarias" e' que referes ? O C++ tem o que e' necessario para ser uma linguagem OO. Dentro do tema do OO, talvez possas argumentar que "multiple-inheritance" seja desnecessario (eu acho que sim), mas esta' la' para quem acha que e' util, e torna o C++ uma linguagem *quase* pura em termos de OO. Por outro lado o C++ tem sim coisas que foram pensadas em cima do joelho -- como as "templates" e a associada STL. Nao acho que uma linguagem que necessita de um pre-processador para implementar features da linguagem tenha muito futuro.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | Não estou a ver que tipo de truques é preciso saber para programar alguma coisa em C além de "saber programar minimamente". Infelizmente grande parte dos 'truques' do c tem mais a ver com disciplina do programador e estilo de programação que com com nuances da linguagem. Quando estava a aprender c, à uns anos, 90% dos erros que cometia tinham a ver com ponteiros soltos, com atribuições dubias e com a gestão de variáveis e funções globais. Prefiro o c++ porque me ajuda a evitar (nao totalmente, infelizmente) alguns desses problemas. Não estou a pregar, estou somente a emitir a minha opiniao de programador amador.
## I live the way I type; fast, with a lot of mistakes. |
| | | | Infelizmente grande parte dos 'truques' do c tem mais a ver com disciplina do programador e estilo de programação que com com nuances da linguagem.
Disciplina e estilo (seja este qual for) sao exactamente aquilo que eu chamo de saber programar minimamente. E disciplina e estilo sao necessarias em qualquer linguagem.
Quando estava a aprender c, à uns anos, 90% dos erros que cometia tinham a ver com ponteiros soltos, com atribuições dubias e com a gestão de variáveis e funções globais.
Esses erros existem em C++ praticamente na mesma proporcao do que em C.
Prefiro o c++ porque me ajuda a evitar (nao totalmente, infelizmente) alguns desses problemas.
Esses problemas podem ser evitados da mesma forma em C, recorrendo a acima mencionada disciplina do programador. Alias, tal como o sao em C++, uma vez que este e um superset do C e podem-se fazer exactamente as mesmas asneiras. Ao contrario do Java, o C e o C++ nao forca uma disciplina em cima do programador e eu acho isso uma Good Thing(tm).
-- Carlos Rodrigues
|
| | | | | Ao contrario do Java, o C e o C++ nao forca uma disciplina em cima do programador e eu acho isso uma Good Thing(tm). Não deixa de ser uma boa argumentação. Mas infelizmente ela não se basta em si mesma. Quando se trabalha em comunidade (ou equipe, ou empresa, ou qualquer outra "instância" deste conceito), algumas regras precisam ser impostas, mesmo que eventualmente arbitrárias. Fazendo uma analogia ao tráfego de automóveis, se as Leis de Trânsito fossem tão flexíveis quanto às regras de C/C++, teríamos o caos nas grandes cidades. Leis de trânsito "flexíveis" funcionam em pequenas comunidades, mas nunca em grandes cidades. Como morador do Estado do Amazonas, eu tive a oportunidade de viajar para cidades pequenas, com 10 ou 20 mil habitantes, onde não existia um único semáforo ou placa de sinalização : e mesmo assim o índice de acidentes de trânsito eram praticamente nulos. O trânsito da capital deste estado, Manaus, é igualmente caótico (apesar de haver semáforos e sinalização), contudo creio que temos o pior índice de acidentes de trânsito por mil habitantes do meu País (ele é o dobro da cidade de São Paulo). Para efeito de comparação, Manaus possui cerca de 2 milhões de habitantes, enquanto São Paulo capital beira os 18 milhões... A flexibilidadade das "regras de programação", em projetos corriqueiros de T.I., deve ser inversamente proporcional ao tamanho da equipe. Eu defendo que, nestes projetos, a imensa liberdade de atuação de C/C++ causa mais prejuízos que benefícios.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | Acho que não foste o único a não entender o itálico em objectividade... :)
Compreendo que prefiras outras linguagens de programação, mas normalmente, os problemas de programação em C derivam de simplesmente as pessoas não se darem ao trabalho de ler o manual... a função xpto leva os argumentos x, y e z, do tipo a b c. Devolve algo do tipo R em que os valores possíveis são: S,T,V. Basta lidar com esses dados e normalmente não há grandes crises.
Quanto a simplicidades e coisas magníficas, provavelmente deverias procurar os concursos de obfuscated C ou Perl, que certamente encontrarias coisas engraçadas... tipo um cat completamente funcional em 62 caracteres, \n incluido, IIRC.
|
| | | | Estava só a falar do meu caso particular. Apesar de usar o C 'quando a isso sou obrigado' a maior parte das coisas novas que faco sao em c++ e, espero a medio prazo, em java.
Extrapolando, suponho que a minha situação seja parecida a de muito mais gente.
## I live the way I type; fast, with a lot of mistakes. |
| | | | | O C é muito diferente de C++ ou C# e não foi tido em conta... mesmo sendo a linguagem de programação mais usada (pelo menos a avaliar pelas estatísticas da freshmeat e do sourceforge! Muitos dos empregadores anunciam C como C++ -- nao existem assim tantos empregos anunciados exclusivamente como C.
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded."
|
| | | | | O C é muito diferente de C++ ou C# e não foi tido em conta... mesmo sendo a linguagem de programação mais usada (pelo menos a avaliar pelas estatísticas da freshmeat e do sourceforge! O C é bastante usado em projectos pessoais, que constituem a maior parte dos que aparecem no freshmeat e sourceforge. Em termos empresariais, o C tem sido marginalizado como escolha tecnológica, por várias razões: é uma linguagem velha (as empresas gostam de estar on the bleeding edge, mesmo que não saibam porquê ou como ou se o estão realmente); a maior parte das pessoas comete demasiados erros em C (o que se confunde muitas vezes com a linguagem ser propícia a bugs). O C continua a ser usado para escrever módulos nativos, integração entre sistemas ao nivel de API (e não de protocolo, ou seja, execução de código de outros sistemas vs comunicar com eles). Mas ninguém coloca essa "capacidade" num anúncio de recrutamento. Pedem-se "java skills", "c++", whatever, e depois espera-se que alguma dessas pessoas consiga despachar uma ou outra coisa mais complicada. Alem disso, como é dito algures, o C normalmente vem agarrado ao C++ (os famosos C/C++). O c++ foi uma das piores coisas que aconteceu tanto para o C como o próprio C++.
-- carlos |
| | | | Será justa a comparação? Vistas bem as coisas o Java tem aplicação em Programas (assim como o C++), conteúdo Web (applets/jsp), telemóveis, etc. Surpreendido mesmo fiquei ao ver lá o Scheme...
|
| | | | What the heck are you going on about ?
"Arguing on the Internet is like running in the Special Olympics -- Even if you win you're still retarded." |
| | | | O Lima já se passa, use-se essa bosta ou não....
|
| |
|
