Por que a maioria dos navegadores são desenvolvidos em C ++ [fechado]


99

Parece que a maioria dos navegadores comuns (Firefox, Chrome, Safari) são desenvolvidos usando C ++. Por que é isso?


28
O Firefox é escrito em C ++ e Javascript, não apenas em C ++.
Jesse Millikan

1
É provável que esta pergunta tenha algumas respostas, desde que sejam precisas (observe o comentário de Jesse no Firefox, e há muitos navegadores além desses três e do IE). Eu não acho que seja produtivo.
David Thornley 31/01

1
Este é o grupo correto para esta pergunta?
Martin York

6
@ Jessé não é o intérprete js escrito em C ++? Isso meio que tornaria tudo C ++, não? (Eu posso estar errado ..)
cambraca

5
@cambraca, com essa lógica, tudo é código de montagem!
Juan Mendes

Respostas:


165

Outra maneira de fazer a pergunta é de que tipo de suporte um navegador precisa? A lista curta é:

  • Suporte para análise (necessário para entender o [X] HTML, CSS e script [ECMA / Java])
  • Recursos de caminhada / interpretação de árvores (parte da análise e criação da interface do usuário)
  • Suporte para gráficos acelerados
  • Rede rápida
  • Para navegadores mais avançados: controle sobre processos e isolamento de memória entre páginas
  • Deve funcionar em todas as plataformas suportadas

A maioria dos idiomas possui algum tipo de suporte de análise. Você tem geradores de analisadores para C, C ++, C #, Java etc. No entanto, C e C ++ têm alguns anos de vantagem sobre o restante das alternativas, para que os algoritmos e implementações sejam mais maduros. O acesso a gráficos acelerados em Java não é permitido, a menos que você tenha algumas extensões nativas para fazê-lo funcionar. O WPF no C # fornece acesso a gráficos acelerados, mas é novo demais para ter um navegador sério construído com a tecnologia.

A rede é realmente o menor dos motivos para escolher C ++ em Java ou C #. O motivo é que a comunicação é muitas vezes mais lenta que o restante do processamento que continua exibindo a página. A velocidade bruta do fio é o fator limitante. Java e C # têm suporte IO sem bloqueio, assim como o C ++. Portanto, não há realmente um vencedor claro nesta área.

Por que não Java? Você já tentou criar uma interface do usuário com Java? Parece pesado e lento em comparação com qualquer outra coisa lá fora, porque é. Nenhum gráfico acelerado também é um grande ponto negativo aqui. O sandboxing do Java é realmente bom e pode ajudar a melhorar a segurança de um navegador se ele for usado corretamente, mas é difícil configurar e fazer o trabalho. Sem mencionar que o suporte ao formato gráfico fica atrás dos navegadores mais modernos.

Por que não c #? Se seu único destino é o Windows, o C # pode realmente ser uma boa representação. O problema surge quando você deseja oferecer suporte a qualquer outra coisa. O Mono não alcançou o suficiente para ser considerado multiplataforma o suficiente para esta tarefa - particularmente com suporte a gráficos acelerado e WPF. Quem sabe quanto tempo isso levará para mudar.

Por que não C? Existe um compilador C para praticamente todas as plataformas existentes (incluindo dispositivos incorporados). No entanto, há muito que C não faz por você e que você precisará estar mais vigilante. Você tem acesso a todos os níveis mais baixos das APIs, mas a maioria dos desenvolvedores de C não faz GUIs. Até as bibliotecas da GUI C são escritas de maneira orientada a objetos. Assim que você começa a falar da interface do usuário, uma linguagem orientada a objetos começa a fazer mais sentido.

Por que não o objetivo C? Se seu único objetivo é a Apple, faz muito sentido. No entanto, a maioria dos desenvolvedores não conhece o Objective-C, e o único motivo para aprender é trabalhar nas caixas NeXT ou Apple. Claro que você pode usar qualquer biblioteca C com o Objective-C, e existem compiladores para muitas plataformas, mas encontrar pessoas para trabalhar nela será um pouco mais difícil. Quem sabe? Talvez a Apple possa reverter essa deficiência percebida.

Por que C ++? Existe um compilador C ++ para praticamente todas as plataformas existentes. Quase toda biblioteca de GUI possui uma interface C ++, às vezes é melhor e às vezes é apenas diferente. Por exemplo, o ATL da Microsoft é muito melhor do que as chamadas de função win32 C ou mesmo a biblioteca MFC. Existem invólucros em C ++ para GTK no Unix, e eu ficaria surpreso se alguém não tivesse um invólucro em C ++ na biblioteca da GUI Objective-C da Apple. O gerenciamento de processos é mais fácil no C ++ que no Java ou C # (esses detalhes são abstraídos para você). É percebido que a velocidade vem mais da aceleração de hardware do que do desempenho bruto. O C ++ cuida de mais coisas para você do que o C bruto (como cadeias delimitadas), mas ainda lhe dá liberdade para ajustar as coisas.

Por enquanto, o C ++ aprimora as alternativas.


4
Para plataformas não Apple e não NeXT, existe a coleção GNUStep. É principalmente compatível com o cacau, e fica muito perto de qualquer lugar.
greyfade

5
Lembre-se de que o Java não deve usar o Swing (que é uma biblioteca de baixa qualidade) para a GUI. Por exemplo, temos ligações Qt.
Anto 31/01

2
De acordo com my.opera.com/kilsmo/blog/2008/01/29/opera-is-not-based-on-qt O Opera não é baseado em Qt
Anto

2
Eu nunca disse que o Opera era baseado no Qt. Eu pretendia sugerir que um navegador não livre é realmente difícil de vender quando existem tantas excelentes opções gratuitas.
Berin Loritsch

7
A disponibilidade dos geradores de analisadores não é tão relevante - em todos os navegadores, os analisadores HTML, XML e JS são escritos à mão e o CSS, em alguns.
gsnedders

89

Decidi escrever um romance sobre isso na esperança de que as pessoas o encobrissem e me votassem. Não, não, só brincando! Eu sofri com cada palavra. Cada palavra, eu lhe digo!

Pergunte 'quando' antes 'por que'

Todos os principais navegadores da Web podem rastrear suas origens nos anos 90. O Konqueror tornou-se Safari e Chrome; O Netscape se tornou Firefox; IE e Opera ainda são IE e Opera. Todos esses navegadores têm uma vantagem de 15 anos nos operadores históricos.

Eu sugiro que você tente nomear um idioma aceitável entre plataformas (Windows / Mac / Unix e, pior ainda) disponível em torno de 1995 quando os navegadores modernos se originaram. Para criar o núcleo em qualquer coisa, exceto em C / C ++, você provavelmente precisaria criar ou comprar e modificar as bibliotecas de compilador e plataforma.

Que tal hoje? Quais são as alternativas?

Apenas por diversão, vamos pensar no problema hoje. Sim, existem alternativas, mas ainda existem grandes problemas.

A escolha do idioma apresenta pelo menos estes problemas:

  1. Problemas de conhecimento - Contratação / treinamento de desenvolvedores ou atração de colaboradores
  2. Problemas organizacionais / sociais - Aceitação de idiomas
  3. Implementação de idioma: velocidade, suporte à plataforma, ferramentas
  4. Poder da linguagem

1: Problemas de conhecimento

Onde você encontra pessoas que conhecem o idioma ou podem aprender? Esse é um obstáculo para idiomas como OCaml, F #, Haskell, Common Lisp e D, que são rápidos e de alto nível o suficiente para escrever um navegador de maneira agradável, mas têm poucos seguidores (talvez na faixa de 10 a 100 mil), mesmo se você for liberal conte todos os amadores e acadêmicos.

2: Problemas sociais / organizacionais

Corolário da resposta do culto à carga acima:

  • Um navegador de código aberto que não usa C, C ++, C # ou Java supostamente terá dificuldade com os colaboradores.
  • Um navegador proprietário que não usa C, C ++, C # ou Java receberá os gerentes de projeto muito criticados na maioria das organizações.

3. problemas técnicos

Mesmo nos tempos modernos, você precisa de uma linguagem bastante rápida para as partes intensivas em computação da renderização de páginas e execução do Javascript. Você pode optar por suplementar isso com uma linguagem de alto nível para criar elementos da GUI etc. (por exemplo, a abordagem do Firefox em C ++ e Javascript), mas você precisa ter uma estreita integração entre as linguagens; você não pode simplesmente dizer "Ok, C # e Lua". Você provavelmente precisará criar e depurar essa ponte, a menos que escolha C ou C ++ como o idioma base.

O desenvolvimento de plataforma cruzada é outro pacote de worms. Você pode usar C # ou F # e cruzar os dedos em GTK # e Mono estar vivo e bem no futuro. Você poderia tentar Common Lisp, Haskell, OCaml ... Boa sorte para conseguir tudo funcionando no Windows e Mac e Linux.

4. Poder da linguagem

Depois de tudo isso, você precisa criar uma enorme quantidade de funcionalidades; portanto, se você escolher uma linguagem de baixo nível, precisará de um exército ainda mais abrangente de codificadores do que antes. Observe que ninguém realmente construiu um navegador a partir do zero em cerca de quinze anos. Em parte porque (surpresa!) É difícil.

Especificamente, ter um intérprete Javascript é o problema 3 (adquira um) ou o problema 4 (construa um).

Conclusão:

Se você desenvolveu um navegador de três plataformas (Windows / Mac / * nix) hoje (início de 2011), quais são algumas das opções?

  • C: Veja (2). Todo mundo vai clamar por C ++. Divirta-se selecionando um kit de ferramentas de plataforma cruzada ou criando um (1, 2, 3 e 4). Veja também (4); divirta-se criando um navegador estável e seguro nele.
  • C ++: Divirta-se selecionando um kit de ferramentas de plataforma cruzada ou criando um (1, 2, 3 e 4). Divirta-se (4) construindo um navegador estável e seguro nele.
  • C ou C ++ e HLL: sua melhor aposta. Escolha seu veneno na linguagem dinâmica; Veja (1) e (2). Muitas línguas boas, poucos seguidores de cada uma. (1, 2, 3 e 4) no kit de ferramentas.
  • Java: Segunda melhor aposta, se você precisar agradar a gerência intermediária. Veja (4); construir coisas enormes em Java requer muito mais código do que qualquer outra coisa nesta lista, mas talvez C.
  • Scala: bate o Java em (4); (1) e (2), mas está pegando.
  • C e Javascript: como um caso especial, isso é atraente porque você já precisa criar ou adquirir e assimilar o intérprete Javascript. (Daí o Firefox.) (1, 2, 3 e 4) no kit de ferramentas; o povo Mozilla construiu seu próprio IIRC.
  • C #: Divirta-se em (3). Você provavelmente está preso ao GTK #, por melhor que seja, ou construindo sua própria camada e renderizador acima do GTK # e do Windows Forms.
  • Ruby / Python / Perl / Racket / Lua / Erlange etc .: você tem (3) bibliotecas de widgets em plataformas e velocidade. A lei de Moore está com você em (4); a crescente demanda por navegadores é contra você.
  • OCaml, Haskell, Lisp comum, Smalltalk: (1) e (2) em espadas. Provavelmente, não há problemas de velocidade, mas (3) para o desenvolvimento de plataforma cruzada, e você terá que criar tudo de si ou fazer a ponte para as bibliotecas C / C ++ de alguma forma.
  • Objetivo-C: (3) Não tenho certeza de como o desenvolvimento de plataforma cruzada funcionaria aqui.

Se virmos outro navegador importante surgir nos próximos anos, aposto que ele será escrito em C ou C ++ e uma linguagem dinâmica (como o Firefox), seja de código aberto ou proprietária.

Editar (31 de julho de 2013) : os comentaristas do Hacker News parecem mencionar Rust and Go (não especificamente em conexão com a minha resposta), que se encaixam vagamente no balde de "miscelânea rápida". Tentar manter essa lista de idiomas igualitária e atualizada será uma batalha perdida, então, em vez disso, estou chamando-a de uma amostra representativa no momento em que escrevi e a deixei em paz.


4
+1 por observar que QUANDO um navegador específico foi desenvolvido pela primeira vez também desempenha um papel significativo.
Sparky

3
Vale a pena notar que, embora o IE possa não ser multiplataforma hoje , certamente foi uma vez, e sua participação de mercado atual quase certamente deriva (pelo menos em parte) dessa capacidade multiplataforma.
Jerry Coffin

2
Observe que o IE era multiplataforma no IE4.
precisa saber é o seguinte

2
+1 para quando. Essa é a única razão. Se alguém começou um projeto de navegador hoje eles provavelmente não iria usar C ++
Henry

4
@ Henry, improvável que eles excluam o uso de C ++. A resposta observa que o C ++ ainda fará parte do quebra-cabeça.
Tipo anônimo

36

Rapidez

Por mais feio que seja, C ++ ainda é o que você usa quando deseja um aplicativo rápido e controle total sobre o código.

É por isso que jogos, partes não essenciais (como importadores de arquivos) do Office e mais ainda são gravados em C ++.

Editado para incluir a resposta do MSalters


3
Além dos jogos, não acredito que esses motivos sejam os motivos de esses aplicativos serem escritos em C ++. Embora se você tiver conhecimento em primeira mão, ficarei feliz em provar que estou errado.
Henry

2
conhecimento em primeira mão? No VS 2010, o Office 2010 são enormes pacotes de aplicativos, mas são extremamente rápidos no que fazem. Embora ambos tenham um legado COM bastante grande e uma herança MS, o desempenho ainda é a coisa mais importante para os usuários.
Tipo anônimo

8
Em que mais o escritório seria escrito? VB? C e C ++ são as únicas opções para a Microsoft escrever aplicativos grandes. Não diga C #, por favor
Toby Allen

4
@ Victor: Eu não vi a fonte do VS2010, então pode muito bem ser escrito inteiramente em C #.
Ryan Hayes

3
Se o office é um aplicativo C #, por que o Ribbon original era um controle MFC e tivemos que esperar idades para que um C # one fosse desenvolvido? nenhum desses aplicativos enormes será reescrito em C #, eles serão agrupados em uma interface gráfica do WPF (como o VS2010) e a maior parte do código antigo será reutilizada. Mesmo a MS não tem recursos para reescrever completamente seus maiores aplicativos - não se eles também querem gastar tempo adicionando recursos a eles.
Gbjbaanb

17

Portabilidade

Só posso adivinhar, mas você está mencionando produtos de software direcionados a várias plataformas, e o C ++ pode ser compilado em qualquer plataforma.


+10 - Além do desempenho bruto, acho que esse é o verdadeiro motivo pelo qual a maioria dos navegadores está em C ++, com exceção do IE. A maioria dos navegadores funciona em várias plataformas e existem poucos idiomas / estruturas que podem funcionar no mesmo nível E serem compatíveis com várias plataformas.
Jordan Parmer

Também pensei nisso primeiro, mas para um aplicativo centrado na GUI como um navegador da web. O C ++ é realmente muito mais portátil para outros sistemas operacionais do que o Java?
procurando

1
Um navegador é realmente tão centralizado na GUI?
Kris Van Bael

@ JohnFx - Correto, a parte da GUI provavelmente não é tão portátil. Mas o núcleo, por exemplo, de um aplicativo de navegador, é sobre como manipular HTML, criar árvores DOM, analisar javascript e executá-lo com rapidez suficiente. Um aplicativo bem projetado pode compartilhar facilmente o mesmo núcleo e ter códigos de interface do usuário diferentes para cada plataforma. E sim, o C ++ é muito mais portátil que o Java (mas sem GUI), porque para o C ++ você precisa apenas de um compilador visando a CPU. Para Java, você precisa da estrutura completa.
Pete

Entendi que a maior parte do intestino do processamento HTML é feita por algumas ferramentas principais, como o WebKit. Talvez seja porque aqueles em C ++ são os navegadores inteiros?
JohnFx

13

(Trabalho no Firefox há cerca de cinco anos.)

O interlocutor está certo de que grande parte do código do Firefox é C ++, e de fato o C ++ é a maioria se você contar por linhas de código (embora isso não conte a história toda, pois temos muito JavaScript e JS é mais conciso que C ++).

Mas, na realidade, o Firefox é escrito em vários idiomas diferentes:

  • C ++
  • C (NSS, NSPR, várias bibliotecas que importamos)
  • montagem x86 e ARM
  • Javascript
  • XUL (uma linguagem de marcação semelhante a HTML) e CSS
  • Objetivo C (código somente para MacOS)
  • Java (código apenas para Android)
  • Várias linguagens de definição de interface personalizadas (XPIDL, IPDL)
  • WebIDL (outra linguagem de definição de interface, mas essa não é personalizada, embora o gerador de código seja)
  • Python (geradores de código)

Eu com certeza estou esquecendo alguns.

Esta lista é importante porque sugere a incrível complexidade que está por trás de um navegador da web.

Sim, o Firefox tem muito código C ++, e sim, isso tem algo a ver com o fato de que C ++ era a melhor linguagem para esse tipo de coisa quando o Netscape foi fundado. Mas também afirmo que hoje não existe linguagem melhor para muito do que fazemos.

Nenhuma outra linguagem possui um ecossistema de bibliotecas tão forte (contamos fortemente com código externo). Poucas outras linguagens oferecem controle de pilha completa como C ++ (regularmente ajustamos nosso alocador de heap personalizado e fazemos todos os tipos de coisas inseguras de memória para serem mais rápidas ou usar menos memória). Poucos idiomas permitem reimplementar a maior parte da biblioteca padrão de uma maneira sã (temos nossas próprias implementações de strings e coleções, ajustadas às nossas necessidades). Poucos idiomas permitem implementar seu próprio coletor de lixo. E assim por diante.

Embora o C ++ seja a escolha óbvia para muito do que fazemos, as pessoas que sugerem que possamos escrever um navegador em Java e criar nossa própria JVM, se necessário, estão envolvidas em alguma coisa. Isso é essencialmente o que fazemos, mas com JavaScript em vez de Java. Obviamente, grande parte do navegador não está escrita em JavaScript. Mas uma quantidade surpreendente é.


Essas ações não seguras são fontes de problemas de segurança?
Demi

12

Bem, você teria que pedir diretamente aos desenvolvedores desses produtos para obter a resposta, mas suspeito que seja uma combinação de familiaridade (é o que esses desenvolvedores sabiam melhor), desempenho (compilação para um binário nativo em vez de bytecode) e ferramentas (em comparação com linguagens como C, C ++ está cheio de ótimos gadgets de economia de trabalho, como o STL).


10

História

Cada um dos navegadores tem um histórico que influenciou a escolha do idioma.

Por exemplo, o Chrome e o Safari são baseados no WebKit, que tem sua origem na parte KHTML do projeto KDE. O KDE foi originalmente criado (em parte) como uma demonstração do Qt GUI toolkit, portanto o KDE é, em geral, um projeto em C ++. Todos os novos projetos do KDE foram, na época, escritos inteiramente em C ++, por isso foi uma escolha lógica para o KHTML. Desde então, foi portado para usar outros kits de ferramentas da GUI.

O mecanismo Presto do Opera foi escrito com desempenho e um pequeno tamanho binário em mente: C ++ era a escolha lógica.

O IE da Microsoft foi escrito como uma coleção de componentes ActiveX, que poderiam ter sido escritos em qualquer idioma que possuísse ligações COM, mas provavelmente foram escritos em um subconjunto de C ++, porque a maioria de sua base de código já está escrita nesse idioma.

O Mozilla da Netscape foi escrito em C ++ provavelmente porque a portabilidade era uma grande preocupação deles. Os compiladores C e C ++ são (virtualmente) onipresentes e, portanto, foi uma escolha lógica.

Não há razão técnica inerente para essas escolhas. Simplesmente "parecia uma boa ideia na época".


8

É fácil otimizar a rede em C e C ++, pois você não precisa usar bibliotecas, se não quiser. Eu suspeito que C ++ é a linguagem de escolha porque permite as vantagens de C:

  • Rapidez
  • Otimização
  • Uma certa quantidade de portabilidade
  • Linguagem compilada, não interpretada

juntamente com as vantagens do OOP:

  • Extensibilidade
  • Visualização mais fácil
  • Melhor suporte de biblioteca para tarefas não críticas, como processamento de strings e estruturas de dados

Java ou C # não tem essas vantagens?
Nipuna 31/01

5
Eu desenvolvi aplicativos em ambos, e eu diria que, para funcionalidade limitada da rede, eles são bons. No entanto, eu não gostaria de criar nada centralizado na parte da rede, como faz um navegador. Eu gostaria de ter muito mais controle sobre o que estava acontecendo e gostaria de uma linguagem compilada .
Michael K

Java e C # também são compilados. O C # teria uma vantagem sobre o Java quando se trata de criar a GUI - uma parte crítica de qualquer navegador. Java teria uma vantagem com a portabilidade. Java e C # são recompilados na plataforma de destino - para melhorias de velocidade sem dúvida melhores.
Berin Loritsch 31/01

5
Não, eles são interpretados. Eles são compilados no bytecode e executados em uma máquina virtual. Essa VM não possui uma correspondência individual de sua instrução definida para a nativa.
Michael K

1
Você não poderia ter isso mais ao contrário! Networking; você pode se enrolar e o navegador seria tão rápido quanto. O código da rede não é o pouco lento. E o que é soquetes se não for uma biblioteca? Processamento de String; Este é o núcleo de qualquer navegador HTML, não é não crítico e não consigo pensar em uma única linguagem que tem pior seqüência de manipulação de C ++ que não seja C.
Henry

4

Quando as primeiras linhas de código da primeira rodada de navegadores foram gravadas, C # e Java não existiam. Ruby também não. O Python pode ter existido, mas ainda era um pequeno projeto homebrew naquele momento.

Basicamente, realmente não havia outras opções além do C ++ que permitissem a criação de um navegador que fosse rápido e fosse executado em muitas plataformas diferentes.

Então, por que eles foram escritos em C ++? Porque esse era o único idioma disponível em que eles poderiam ser escritos.


1
Não sei o que você quer dizer com 'nova rodada'. Mas FF e IE têm bases de código que remontam a meados dos anos 90, ea maioria dos novos navegadores usam um dos motores de renderização (por exemplo, o Chrome usa WebKit)
GrandmasterB

2
A FF se livrou do código legado do Netscape (ou seja, que os meados dos anos 90 incham) e implementou seu próprio mecanismo de renderização. O WebKit também é um mecanismo de renderização comparativamente novo (usado pelo Chrome e Safari). O IE ainda tem o inchaço legado, que continua a pesar. Então eu vou discordar aqui.
Berin Loritsch 31/01

2
De acordo com a wikipedia, pelo menos, tanto o gecko quanto o webkit começaram por volta de 1998. O C # não era por essa época e o java era novo em cena (e super lento e realmente péssimo para os gui's naquela época), então essa não seria uma opção viável. Então, eu não sei quais outros idiomas seriam adequados. Talvez Pascal.
GrandmasterB

1
@Berin Loritsch: Sim, mas em nenhum momento eles simplesmente jogaram fora todo o código existente e recomeçaram (em tudo) desde o início, o que é praticamente o que eles precisavam fazer para converter para outro idioma. Além disso, as pessoas que conheciam / conhecem C ++ suficientemente bem para que sua decisão sobre o FF permanecesse provavelmente mudariam para um idioma diferente.
Jerry Coffin

2
@Berin Loritsch Rubbish. O FF ainda é baseado em Gecko (1997) e o Webkit é baseado em khtml (1998).
Henry

4

Como os navegadores (por exemplo, HotJava, obviamente, escritos em Java) escritos em outras linguagens nunca foram alcançados um grau substancial de aceitação / penetração no mercado.

Não posso dizer nada sobre a iteração atual (ou a mais recente - não foi atualizada há um bom tempo) do HotJava, mas quando tentei, a falta de penetração no mercado parecia (pelo menos para mim) extremamente fácil de entender - era feio, lento e incompatível com algumas páginas da web. Por fim, parecia basear-se em uma premissa que nunca deu certo: que a Web consistisse principalmente em applets Java, com HTML como pouco mais do que um invólucro informando quais applets exibir onde.

Parte disso provavelmente também é histórica: a maioria dos grandes navegadores da web existe há muito tempo. Quando eles foram escritos pela primeira vez, o cenário era muito diferente: o C ++ era uma nova linguagem "quente", então estava sendo usada para muitos novos desenvolvimentos. Os navegadores se tornaram alguns dos softwares mais utilizados, enquanto muitos outros da época desapareceram no esquecimento.

Eu acho que a "atitude" exibida da linguagem também tem um efeito: C ++ (como C antes) sempre enfatizou praticidade e pragmatismo. Essa atitude básica tende a atrair programadores que também são pragmáticos. Muitos outros idiomas dão muito mais ênfase a coisas como elegância - e, assim, atraem programadores que pensam da mesma maneira. O problema é o que chamo de "efeito Lisp". Os sintomas incluem:

  1. Argumentos intermináveis ​​sobre a implementação mais elegante das coisas mais triviais.
  2. Incapacidade de congelar recursos e concluir algo que pode ser enviado (mesmo com falhas)
  3. Incapacidade de se comprometer. Quem discorda de mim não está apenas errado, mas deve ser estúpido ou mau.

Há mais, mas você entende a ideia geral (e sim, estou exagerando até certo ponto - mas apenas até certo ponto). Sim, parte do código que você obtém será surpreendentemente bonita - mas é provável que esteja seis meses atrasada e, principalmente, incompatível com todos os outros trechos de código (o que deveria ser) no sistema, e quando você o receber, haverá uma boa chance de que algo mais tenha mudado o suficiente para que você não possa usá-lo.

Existem também idiomas que, sem dúvida, funcionariam bem, mas (com ou sem razão) simplesmente não têm (ou no momento crucial, não tinham) a participação de mercado para que alguém já tenha escrito um navegador neles. Dado o tamanho e a complexidade de um navegador completo, são necessárias muitas pessoas e bastante tempo para desenvolver um. Com esse tipo de investimento, muitas pessoas ficam relativamente conservadoras sobre coisas como ferramentas de desenvolvimento.


1
WRT, ponto 3, definitivamente afirmo, sem qualificação, que escrever softwares voltados para a rede na família C é estúpido ou mau, porque implica inconscientemente (estúpido) ou conscientemente (mau) trabalho com um sistema amplamente conhecido por introduzir segurança buracos que irá causar danos aos seus usuários. É moralmente equivalente a dar uma armadura de soldado com um alvo pintado nela.
Mason Wheeler

9
@Mason: Sua exibição exatamente do fanatismo em questão é certamente apreciada.
Jerry Coffin

2
@Mason: Bobagem. Uma falha de segurança (que já havia sido corrigida, mas muitos administradores de sistemas não se preocuparam em instalar o código atualizado) nem chega perto da prova de que todo o código escrito no mesmo idioma "causará danos" ou qualquer coisa do tipo. O OpenBSD (por exemplo) tem um histórico de segurança consideravelmente melhor do que a versão do MacOS baseada em Pascal até aspirava.
Jerry Coffin

5
@Mason: Não, você é. Primeiro, o worm Morris explorou um proram usado gets, que é uma função terrível, mas dificilmente inevitável (e certamente não "fundamental" para a linguagem, ou algo assim). Segundo, C ++ não é a mesma linguagem que C em nenhum caso. Terceiro, o OpenBSD demonstra bastante bem que o software seguro pode e está escrito em C. Não há "falha de linguagem subjacente" que impeça a criação de software sólido e seguro em C. A pequena participação no mercado do OpenBSD indica que a segurança não é uma grande preocupação para a maioria pessoas.
Jerry Coffin

6
@Mason: a saturação do buffer getsé uma consequência simples do fato de você não passar o comprimento do buffer que está usando. Nada de fundamental na linguagem - você pode fazer o mesmo em Pascal (e eu fiz). Escrever software seguro contra um invasor inteligente não é fácil, independentemente do idioma. Com base na experiência em todos os três, que é um pouco mais fácil em C do que em Pascal, e um muito mais fácil em C ++ que no C.
Jerry Coffin

3

Programação de carga-culto. A percepção de que "o C ++ é rápido" ainda está por aí (apesar dos recursos mal pensados ​​no nível da linguagem, como o modelo de objetos quebrado que atrasa as coisas) e as pessoas querem que seus navegadores sejam rápidos, então escrevem em C ++ .

Em um mundo são, as pessoas que escrevem software voltado para a rede ficariam horrorizadas com o mero pensamento de usar uma linguagem associada a todos os problemas de segurança inerentes a C, e, na verdade, fazê-lo seria um ato de negligência criminal. (Veja quantas explorações de buffer overflow foram encontradas em vários navegadores nos últimos 15 anos ou mais! Por quantos milhões de dólares em danos esses codificadores são responsáveis?)

Existem outras linguagens compiladas capazes de criar binários rápidos. O problema é que eles não têm a mesma exposição que a família C, e todos temos que sofrer por isso.

Curiosidade: quando o Morris Worm chegou à Internet em 1988, demonstrando conclusivamente os problemas com a criação de sistemas operacionais e softwares voltados para a rede em C (que ainda não foram resolvidos até hoje, porque são falhas inerentes ao idioma). ,) A Apple estava lançando o sistema operacional mais avançado que o mundo já havia visto até agora, há vários anos, escrito em Pascal.


15
Hã? Gostei muito do Mac OS, mas chamá-lo de OS mais avançado que o mundo já viu é bobagem. Não estava nem no mesmo estádio que o UNIX e o VMS, muito menos os grandes sistemas de ferro da IBM: usuário único, sem memória virtual, gerenciamento limitado de processos. Para ter certeza, ele tinha um sistema de janelas muito bom, mas mesmo isso era derivado da Xerox Parc e vários projetos acadêmicos. Eu também acho que grande parte do Mac OS foi realmente escrita na montagem M68k. As bibliotecas usavam os padrões de chamada de função Pascal porque era esperado que Pascal fosse a linguagem principal do aplicativo.
Charles E. Grant

5
Os sistemas operacionais da Apple anteriores aos anos 2000 não eram mais estáveis ​​que o equivalente à MS. Quando eu estava trabalhando em dois projetos nos anos 90, um no Mac OS e outro no NT, tive o mesmo número de falhas e reinicializações necessárias. Agora eles são todos algum tipo de linguagem baseada em C. (A Apple usa o Objective-C para suas coisas atuais). A segurança pode ser mais difícil em idiomas baseados em C, mas o uso de um idioma diferente não o torna repentinamente mais seguro.
Berin Loritsch 31/01

13
@Mason, o fato de o Mac não precisar desses recursos no momento não significa que eles sejam insignificantes. Você declarou não qualificado que o Apple OS era o mais avançado do mundo, mas aparentemente o que realmente queria dizer era que ele tinha a interface de usuário mais sofisticada. Essa é uma afirmação defensável, mas menos grandiosa do que o que você escreveu. Escrever uma GUI utilizável é difícil. Escrever um sistema de memória paginável confiável é difícil. Dizer que um é mais significativo que o outro é bobo. A computação no nível do consumidor como a conhecemos agora não poderia existir sem os dois.
Charles E. Grant

5
@Mason: sua experiência difere claramente (imensamente) de qualquer pessoa e de todos os outros - em muitos aspectos. :-)
Jerry Coffin

3
@Mason: LOL ao se referir ao pré-Mac OSX como "avançado". O Apple OS era uma fonte constante de falhas, principalmente por causa de seu sistema de arquivos extremamente rudimentar.
Tipo anônimo

2

Acesso a APIs no nível do sistema

Todos os navegadores precisam interagir com o sistema operacional em algum momento, e a maioria dos principais sistemas operacionais possui APIs e bibliotecas C e C ++ bem estabelecidas. Geralmente é mais fácil trabalhar com essas APIs em C ou C ++ em vez de escrever wrappers.


0

Controle e Portabilidade

a maioria dos argumentos de velocidade pode ser de qualquer maneira, mas em qualquer lugar em que você precise de um controle preciso sobre como algo é feito, muitos dos idiomas de nível superior irão chover em seu desfile. Há exceções, mas a maioria não é multiplataforma o suficiente para contar algo como um navegador.


0

Compatibilidade herdada - não é possível descartar o código antigo

Não tem nada a ver com os méritos do C ++ em relação a outros idiomas. Você certamente pode escrever um navegador melhor do zero em um idioma como Haskell; um projeto tão importante poderia até implementar sua própria JVM se precisassem garantir algumas características de desempenho. Assim como o Facebook escreveu seu próprio compilador / otimizador de PHP.

Um navegador que quebra na marcação não padrão é pior que inútil. A compatibilidade herdada é tão crítica e complexa que uma reescrita não é apenas uma opção. Muito dinheiro e tempo são investidos em segurança testada em batalha, etc., você não pode simplesmente jogar fora esse investimento. Mais uma vez, como o Facebook ainda é escrito em PHP.


Eu posso entender por que as pessoas podem não aprovar isso ... mas votaram negativamente? Isso é estranho. Aqui está um +1 para você.
Thomas Eding

Você tem um (pequeno) argumento, mas sua primeira frase o joga fora. Obviamente, isso também tem a ver com os méritos do C ++ em relação a outras linguagens.
Chiel ten Brinke
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.