Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
1. Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
Zamariolo
(usa Ubuntu)
Enviado em 22/07/2017 - 14:26h
E aí pessoal, o contexto é o seguinte: desde muito tempo programo em C/C++ e já estou bem habituado com a linguagem. Já tive experiencias com Python também mas nada muito concreto embora sem dificuldades no entendimento. No entanto tenho sentido ultimamente que C/C++ estão “paradas no tempo” ao passo que Python está sempre se renovando e aparecendo no mundo com novas ferramentas e aplicações transmitindo ser uma linguagem bem promissora embora ainda seja uma linguagem mais pesada. Notei que muitas das aplicações são mais fáceis de se realizar em Python e sutilmente bem mais trabalhosas em C (O reciproco também é verdadeiro).No contexto acadêmico e de pesquisa (principalmente na engenharia), onde estou inserido, o uso da programação é inevitavel no dia a dia, dessa forma vocês considerariam migrar a “linguagem nativa de programação” de C/C++ para Python, tentar equilibrar ambas ou permanecer na mesma?
Estou altamente aberto a opiniões de programadores de ambos os lados da força.
2. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
removido
(usa Nenhuma)
Enviado em 22/07/2017 - 20:30h
Depende do quê você faz;C++ é uma linguagem de programação de baixo nível mais complicada do quê precisa, mas é a melhor para fazer sistemas.
Python é uma linguagem de alto nível usada geralmente para fazer scripts e sites, ela é muito simples e está avançando no mercado cada vez mais, não sei se já compete com Java mas provavalmente sim.
Se você trabalha com programação eu aconselho a migrar para python e depois aprender Java.
Se é apenas um hobby é legal ter conhecimento nas duas.
Mas depois de tudo, todo conhecimento é bom.
3. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
phoemur
(usa Debian)
Enviado em 23/07/2017 - 10:38h
Se o seu uso seria para análise de dados e estatística o Python é nota 10.Tem os pacotes Scipy, numpy, pandas, matplotlib, statsmodels, entre muitos outros.
Muito se discute entre Python e a linguagem R, qual seria melhor.
Eu tenho um viés muito grande à favor do python, justamente por ser uma linguagem de uso geral. Da mesma forma que você faz uma análise de dados no trabalho, você chega em casa e faz um script, uma GUI, um webapp, tudo com a mesma ferramenta. Coisa que se você fosse utilizar R ou MATLAB ficaria mais restrito.
Muito se diz que Python é lerdo. Mas isso é relativo, pois você pode usar outro interpretador com JIT (Pypy), pode usar extensões em C no próprio python ou pode usar Cython. Pode usar até sobre a JVM com o Jython.
Porém a principal causa de baixa performance está no usuário mesmo, pois um código feito da forma correta fica bem eficiente mesmo com o interpretador padrão.
Até porque em última análise tudo o que você programa em python é traduzido para C, o interpretador traduz para um bytecode em C (aqueles arquivos chatos *.pyc) do mesmo programa, porém você não precisa se preocupar com "coisas de máquina" como ponteiros, acesso à memória, garbage cleaning, tipagem, etc...
De qualquer forma, a filosofia do python é que o tempo de máquina é infinitamente mais barato que o tempo do programador, de forma que o foco da linguagem é a facilidade.
Tem até uma estimativa que um programa feito em C/C++ tem em média 5 a 6 vezes mais linhas de código que o mesmo em python.
C++ tries to give you every language feature under the sun (circa 1990, at least) while at the same time never (forcibly) abstracting anything away that could potentially affect performance.
Python tries to give you only one or a few ways to do things, and those ways are designed to be simple, even at the cost of some language power or running efficiency.
In many cases, Python's philosophy is an advantage because it lets you get most tasks done more easily and more quickly with less mental overhead.
The Zen of python:
[phoemur@Desktop ~]$python3
Python 3.6.1 (default, Jun 21 2017, 22:58:28)
[GCC 7.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
4. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
brendonhc
(usa Debian)
Enviado em 27/07/2017 - 20:26h
phoemur escreveu:
Se o seu uso seria para análise de dados e estatística o Python é nota 10.
Tem os pacotes Scipy, numpy, pandas, matplotlib, statsmodels, entre muitos outros.
Muito se discute entre Python e a linguagem R, qual seria melhor.
Eu tenho um viés muito grande à favor do python, justamente por ser uma linguagem de uso geral. Da mesma forma que você faz uma análise de dados no trabalho, você chega em casa e faz um script, uma GUI, um webapp, tudo com a mesma ferramenta. Coisa que se você fosse utilizar R ou MATLAB ficaria mais restrito.
Muito se diz que Python é lerdo. Mas isso é relativo, pois você pode usar outro interpretador com JIT (Pypy), pode usar extensões em C no próprio python ou pode usar Cython. Pode usar até sobre a JVM com o Jython.
Porém a principal causa de baixa performance está no usuário mesmo, pois um código feito da forma correta fica bem eficiente mesmo com o interpretador padrão.
Até porque em última análise tudo o que você programa em python é traduzido para C, o interpretador traduz para um bytecode em C (aqueles arquivos chatos *.pyc) do mesmo programa, porém você não precisa se preocupar com "coisas de máquina" como ponteiros, acesso à memória, garbage cleaning, tipagem, etc...
De qualquer forma, a filosofia do python é que o tempo de máquina é infinitamente mais barato que o tempo do programador, de forma que o foco da linguagem é a facilidade.
Tem até uma estimativa que um programa feito em C/C++ tem em média 5 a 6 vezes mais linhas de código que o mesmo em python.
C++ tries to give you every language feature under the sun (circa 1990, at least) while at the same time never (forcibly) abstracting anything away that could potentially affect performance.
Python tries to give you only one or a few ways to do things, and those ways are designed to be simple, even at the cost of some language power or running efficiency.
In many cases, Python's philosophy is an advantage because it lets you get most tasks done more easily and more quickly with less mental overhead.
The Zen of python:
[phoemur@Desktop ~]$python3
Python 3.6.1 (default, Jun 21 2017, 22:58:28)
[GCC 7.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Se o seu uso seria para análise de dados e estatística o Python é nota 10.
Tem os pacotes Scipy, numpy, pandas, matplotlib, statsmodels, entre muitos outros.
Muito se discute entre Python e a linguagem R, qual seria melhor.
Eu tenho um viés muito grande à favor do python, justamente por ser uma linguagem de uso geral. Da mesma forma que você faz uma análise de dados no trabalho, você chega em casa e faz um script, uma GUI, um webapp, tudo com a mesma ferramenta. Coisa que se você fosse utilizar R ou MATLAB ficaria mais restrito.
Muito se diz que Python é lerdo. Mas isso é relativo, pois você pode usar outro interpretador com JIT (Pypy), pode usar extensões em C no próprio python ou pode usar Cython. Pode usar até sobre a JVM com o Jython.
Porém a principal causa de baixa performance está no usuário mesmo, pois um código feito da forma correta fica bem eficiente mesmo com o interpretador padrão.
Até porque em última análise tudo o que você programa em python é traduzido para C, o interpretador traduz para um bytecode em C (aqueles arquivos chatos *.pyc) do mesmo programa, porém você não precisa se preocupar com "coisas de máquina" como ponteiros, acesso à memória, garbage cleaning, tipagem, etc...
De qualquer forma, a filosofia do python é que o tempo de máquina é infinitamente mais barato que o tempo do programador, de forma que o foco da linguagem é a facilidade.
Tem até uma estimativa que um programa feito em C/C++ tem em média 5 a 6 vezes mais linhas de código que o mesmo em python.
C++ tries to give you every language feature under the sun (circa 1990, at least) while at the same time never (forcibly) abstracting anything away that could potentially affect performance.
Python tries to give you only one or a few ways to do things, and those ways are designed to be simple, even at the cost of some language power or running efficiency.
In many cases, Python's philosophy is an advantage because it lets you get most tasks done more easily and more quickly with less mental overhead.
The Zen of python:
[phoemur@Desktop ~]$python3
Python 3.6.1 (default, Jun 21 2017, 22:58:28)
[GCC 7.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Cara, gostei dessa filosofia python!
Estou fazendo curso de computação e aprendi coisa pra caramba em C, mas é uma trabalheira danada com "coisas de maquina" como disse... Me deu uma grande vontade de APRENDER python!
Me ajuda aí, me recomende algo pra fazer essa transição, quem já programa aprender python.
E outra, um interpretador bom! Não precisa ser o mais rápido, mas o bom... Usar ide ou só um editor de texto?
Valeu!
5. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
lipman
(usa Debian)
Enviado em 27/07/2017 - 21:02h
brendonhc escreveu:
Cara, gostei dessa filosofia python!
Estou fazendo curso de computação e aprendi coisa pra caramba em C, mas é uma trabalheira danada com "coisas de maquina" como disse... Me deu uma grande vontade de APRENDER python!
Me ajuda aí, me recomende algo pra fazer essa transição, quem já programa aprender python.
E outra, um interpretador bom! Não precisa ser o mais rápido, mas o bom... Usar ide ou só um editor de texto?
Valeu!
phoemur escreveu:
Se o seu uso seria para análise de dados e estatística o Python é nota 10.
Tem os pacotes Scipy, numpy, pandas, matplotlib, statsmodels, entre muitos outros.
Muito se discute entre Python e a linguagem R, qual seria melhor.
Eu tenho um viés muito grande à favor do python, justamente por ser uma linguagem de uso geral. Da mesma forma que você faz uma análise de dados no trabalho, você chega em casa e faz um script, uma GUI, um webapp, tudo com a mesma ferramenta. Coisa que se você fosse utilizar R ou MATLAB ficaria mais restrito.
Muito se diz que Python é lerdo. Mas isso é relativo, pois você pode usar outro interpretador com JIT (Pypy), pode usar extensões em C no próprio python ou pode usar Cython. Pode usar até sobre a JVM com o Jython.
Porém a principal causa de baixa performance está no usuário mesmo, pois um código feito da forma correta fica bem eficiente mesmo com o interpretador padrão.
Até porque em última análise tudo o que você programa em python é traduzido para C, o interpretador traduz para um bytecode em C (aqueles arquivos chatos *.pyc) do mesmo programa, porém você não precisa se preocupar com "coisas de máquina" como ponteiros, acesso à memória, garbage cleaning, tipagem, etc...
De qualquer forma, a filosofia do python é que o tempo de máquina é infinitamente mais barato que o tempo do programador, de forma que o foco da linguagem é a facilidade.
Tem até uma estimativa que um programa feito em C/C++ tem em média 5 a 6 vezes mais linhas de código que o mesmo em python.
C++ tries to give you every language feature under the sun (circa 1990, at least) while at the same time never (forcibly) abstracting anything away that could potentially affect performance.
Python tries to give you only one or a few ways to do things, and those ways are designed to be simple, even at the cost of some language power or running efficiency.
In many cases, Python's philosophy is an advantage because it lets you get most tasks done more easily and more quickly with less mental overhead.
The Zen of python:
[phoemur@Desktop ~]$python3
Python 3.6.1 (default, Jun 21 2017, 22:58:28)
[GCC 7.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Se o seu uso seria para análise de dados e estatística o Python é nota 10.
Tem os pacotes Scipy, numpy, pandas, matplotlib, statsmodels, entre muitos outros.
Muito se discute entre Python e a linguagem R, qual seria melhor.
Eu tenho um viés muito grande à favor do python, justamente por ser uma linguagem de uso geral. Da mesma forma que você faz uma análise de dados no trabalho, você chega em casa e faz um script, uma GUI, um webapp, tudo com a mesma ferramenta. Coisa que se você fosse utilizar R ou MATLAB ficaria mais restrito.
Muito se diz que Python é lerdo. Mas isso é relativo, pois você pode usar outro interpretador com JIT (Pypy), pode usar extensões em C no próprio python ou pode usar Cython. Pode usar até sobre a JVM com o Jython.
Porém a principal causa de baixa performance está no usuário mesmo, pois um código feito da forma correta fica bem eficiente mesmo com o interpretador padrão.
Até porque em última análise tudo o que você programa em python é traduzido para C, o interpretador traduz para um bytecode em C (aqueles arquivos chatos *.pyc) do mesmo programa, porém você não precisa se preocupar com "coisas de máquina" como ponteiros, acesso à memória, garbage cleaning, tipagem, etc...
De qualquer forma, a filosofia do python é que o tempo de máquina é infinitamente mais barato que o tempo do programador, de forma que o foco da linguagem é a facilidade.
Tem até uma estimativa que um programa feito em C/C++ tem em média 5 a 6 vezes mais linhas de código que o mesmo em python.
C++ tries to give you every language feature under the sun (circa 1990, at least) while at the same time never (forcibly) abstracting anything away that could potentially affect performance.
Python tries to give you only one or a few ways to do things, and those ways are designed to be simple, even at the cost of some language power or running efficiency.
In many cases, Python's philosophy is an advantage because it lets you get most tasks done more easily and more quickly with less mental overhead.
The Zen of python:
[phoemur@Desktop ~]$python3
Python 3.6.1 (default, Jun 21 2017, 22:58:28)
[GCC 7.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Cara, gostei dessa filosofia python!
Estou fazendo curso de computação e aprendi coisa pra caramba em C, mas é uma trabalheira danada com "coisas de maquina" como disse... Me deu uma grande vontade de APRENDER python!
Me ajuda aí, me recomende algo pra fazer essa transição, quem já programa aprender python.
E outra, um interpretador bom! Não precisa ser o mais rápido, mas o bom... Usar ide ou só um editor de texto?
Valeu!
posso te indicar a usar editor de texto, e o interpretador padrão do linux
6. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
paulo1205
(usa Ubuntu)
Enviado em 30/07/2017 - 07:09h
TL;DR: A linguagem que você deve usar depende de o que você quer fazer. Nunca se prenda a uma linguagem só, e aprenda a usar bem as que você aprender, para saber quando usá-las e, principalmente, quando não as usar.Resposta longa:
Acho que a questão está colocada com alguns problemas.
Para começar, o título fala de uma coisa (C++), e o corpo da pergunta fala de uma outra que, na verdade, não existe como entidade única (C/C++), mas sim como duas entidades separadas (C,de um lado, e C++, de outro), embora relacionadas historicamente. Fala de “C/C++”, mas com verbo no plural, e também só de C. Esse uso confuso dos termos dificulta um pouco a resposta.
A separação entre C e C++ é especialmente relevante no que diz respeito aos caminhos evolutivos de cada uma. Até por conta disso, é temerário dizer que “C/C++ estão “paradas no tempo””. Sob que ponto de vista?
Eu até concordo que C evolui pouco e lentamente. E o último padrão, de 2011, em parte desfez algumas coisas meio ousadas (e descabidas) impostas pelo padrão 1999. Mas, sinceramente, dado o propósito de C, não tem muito o que se fazer em termos de evolução da linguagem em si. A linguagem é simples e tem o propósito de executar próxima do nível de máquina, quase que como um Assembly de um pouco mais alto nível. Eu só vislumbro evoluções para C, no nível da linguagem, que façam com que ela faça de um jeito mais genérico ou mais apurado aquilo que ela já se propõe a fazer. No nível de sua biblioteca pode haver mais espaço para evolução, mas talvez não muito mais, já que também a biblioteca já foi pensada para um computador genérico. Se você acrescentar recursos novos a C, ela vai virar outra coisa (já aconteceu no passado, e produziu resultados como C++, Objective-C, D etc.), e acrescentar recursos novos à biblioteca traz o risco de reduzir sua generalidade ou aumentar muito sua complexidade.
C++ é um pouco diferente porque, embora se preocupe com eficiência e generalidade, como sua irmã C, a linguagem sempre teve o objetivo de ser capaz de expressar bem conceitos que facilitem a vida do criador de sistemas Isso fez, no passado, com que ela adotasse elementos de OO, exceções, programação genérica, segregação em namespaces etc., e abre espaço para a incorporação de novos conceitos. Só em termos de padrões publicados recentemente (menos de 10 anos), C++ teve versões publicadas em 2011 e 2014 e deve ter um saindo ainda este ano (o rascunho da forma final foi proposto em março). Fora da padronização, existe uma quantidade gigantesca de bibliotecas disponíveis, para uso em diversas áreas, e em constante evolução.
(Continuo a resposta mais tarde. Preciso sair agora.)
7. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
brendonhc
(usa Debian)
Enviado em 22/10/2017 - 16:37h
paulo1205 escreveu:
TL;DR: A linguagem que você deve usar depende de o que você quer fazer. Nunca se prenda a uma linguagem só, e aprenda a usar bem as que você aprender, para saber quando usá-las e, principalmente, quando não as usar.
Resposta longa:
Acho que a questão está colocada com alguns problemas.
Para começar, o título fala de uma coisa (C++), e o corpo da pergunta fala de uma outra que, na verdade, não existe como entidade única (C/C++), mas sim como duas entidades separadas (C,de um lado, e C++, de outro), embora relacionadas historicamente. Fala de “C/C++”, mas com verbo no plural, e também só de C. Esse uso confuso dos termos dificulta um pouco a resposta.
A separação entre C e C++ é especialmente relevante no que diz respeito aos caminhos evolutivos de cada uma. Até por conta disso, é temerário dizer que “C/C++ estão “paradas no tempo””. Sob que ponto de vista?
Eu até concordo que C evolui pouco e lentamente. E o último padrão, de 2011, em parte desfez algumas coisas meio ousadas (e descabidas) impostas pelo padrão 1999. Mas, sinceramente, dado o propósito de C, não tem muito o que se fazer em termos de evolução da linguagem em si. A linguagem é simples e tem o propósito de executar próxima do nível de máquina, quase que como um Assembly de um pouco mais alto nível. Eu só vislumbro evoluções para C, no nível da linguagem, que façam com que ela faça de um jeito mais genérico ou mais apurado aquilo que ela já se propõe a fazer. No nível de sua biblioteca pode haver mais espaço para evolução, mas talvez não muito mais, já que também a biblioteca já foi pensada para um computador genérico. Se você acrescentar recursos novos a C, ela vai virar outra coisa (já aconteceu no passado, e produziu resultados como C++, Objective-C, D etc.), e acrescentar recursos novos à biblioteca traz o risco de reduzir sua generalidade ou aumentar muito sua complexidade.
C++ é um pouco diferente porque, embora se preocupe com eficiência e generalidade, como sua irmã C, a linguagem sempre teve o objetivo de ser capaz de expressar bem conceitos que facilitem a vida do criador de sistemas Isso fez, no passado, com que ela adotasse elementos de OO, exceções, programação genérica, segregação em namespaces etc., e abre espaço para a incorporação de novos conceitos. Só em termos de padrões publicados recentemente (menos de 10 anos), C++ teve versões publicadas em 2011 e 2014 e deve ter um saindo ainda este ano (o rascunho da forma final foi proposto em março). Fora da padronização, existe uma quantidade gigantesca de bibliotecas disponíveis, para uso em diversas áreas, e em constante evolução.
(Continuo a resposta mais tarde. Preciso sair agora.)
TL;DR: A linguagem que você deve usar depende de o que você quer fazer. Nunca se prenda a uma linguagem só, e aprenda a usar bem as que você aprender, para saber quando usá-las e, principalmente, quando não as usar.
Resposta longa:
Acho que a questão está colocada com alguns problemas.
Para começar, o título fala de uma coisa (C++), e o corpo da pergunta fala de uma outra que, na verdade, não existe como entidade única (C/C++), mas sim como duas entidades separadas (C,de um lado, e C++, de outro), embora relacionadas historicamente. Fala de “C/C++”, mas com verbo no plural, e também só de C. Esse uso confuso dos termos dificulta um pouco a resposta.
A separação entre C e C++ é especialmente relevante no que diz respeito aos caminhos evolutivos de cada uma. Até por conta disso, é temerário dizer que “C/C++ estão “paradas no tempo””. Sob que ponto de vista?
Eu até concordo que C evolui pouco e lentamente. E o último padrão, de 2011, em parte desfez algumas coisas meio ousadas (e descabidas) impostas pelo padrão 1999. Mas, sinceramente, dado o propósito de C, não tem muito o que se fazer em termos de evolução da linguagem em si. A linguagem é simples e tem o propósito de executar próxima do nível de máquina, quase que como um Assembly de um pouco mais alto nível. Eu só vislumbro evoluções para C, no nível da linguagem, que façam com que ela faça de um jeito mais genérico ou mais apurado aquilo que ela já se propõe a fazer. No nível de sua biblioteca pode haver mais espaço para evolução, mas talvez não muito mais, já que também a biblioteca já foi pensada para um computador genérico. Se você acrescentar recursos novos a C, ela vai virar outra coisa (já aconteceu no passado, e produziu resultados como C++, Objective-C, D etc.), e acrescentar recursos novos à biblioteca traz o risco de reduzir sua generalidade ou aumentar muito sua complexidade.
C++ é um pouco diferente porque, embora se preocupe com eficiência e generalidade, como sua irmã C, a linguagem sempre teve o objetivo de ser capaz de expressar bem conceitos que facilitem a vida do criador de sistemas Isso fez, no passado, com que ela adotasse elementos de OO, exceções, programação genérica, segregação em namespaces etc., e abre espaço para a incorporação de novos conceitos. Só em termos de padrões publicados recentemente (menos de 10 anos), C++ teve versões publicadas em 2011 e 2014 e deve ter um saindo ainda este ano (o rascunho da forma final foi proposto em março). Fora da padronização, existe uma quantidade gigantesca de bibliotecas disponíveis, para uso em diversas áreas, e em constante evolução.
(Continuo a resposta mais tarde. Preciso sair agora.)
Aguardando até hoje a "CONTINUAÇÃO"... rsrs
8. Re: Vale a pena migrar de C++ para Python (Usando uma distribuição LINUX, claro)?
phoemur
(usa Debian)
Enviado em 22/10/2017 - 20:54h
brendonhc escreveu:
Aguardando até hoje a "CONTINUAÇÃO"... rsrs
Aguardando até hoje a "CONTINUAÇÃO"... rsrs
Eu considero o seguinte tópico a continuação: https://www.vivaolinux.com.br/topico/C-C++/C-esta-se-tornando-parecido-com-Python
Nele o @paulo1205 dá uma aula sobre as semelhanças e diferenças entre essas duas linguagens.
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Criar entrada (menuentry) ISO no Grub
Como gerar qualquer emoji ou símbolo unicode a partir do seu teclado
Dicas
Instalar o VIM 9.1 no Debian 12
Como saber o range de um IP público?
Muitas dificuldades ao instalar distro Linux em Notebook Sony Vaio PCG-6131L (VPCEA24FM)
Slackpkg+ (Slackpkg Plus) está de volta!
Como dividir duas janelas igualmente e lado-a-lado na sua tela
Tópicos
Posso instalar usar o grub sem ter linux instalado, para iniciar o win... (2)
Ocomon 6.0.1 - Problemas ao editar configurações estendidas (6)
Problemas com adaptadores wifi no Zorin (0)
Top 10 do mês
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
