empregos e C++
- Autor do tópico ld50
- Data Início
JomarC
Power Member
Na minha opinião um programador não deve ficar-se só por uma linguagem.
Quantas mais souberes melhor. Dito isto se tas a pensar em seguir C++ mais de perto acho muito bem porque na minha opinião e muito completa, mas não deixes de aprender outras.
Quanto mais linguagens souberes melhor para ti e com mais facilidade arranjas emprego.
Cumps
Quantas mais souberes melhor. Dito isto se tas a pensar em seguir C++ mais de perto acho muito bem porque na minha opinião e muito completa, mas não deixes de aprender outras.
Quanto mais linguagens souberes melhor para ti e com mais facilidade arranjas emprego.
Cumps
fLaSh_CF
Banido
Sem duvida JomarC
Eu penso que actualmente uma boa aposta para o futuro é sem duvida dominar as soluções Microsoft nomeadamente o .NET framework e SQL Server seja por VB.NET, C# .NET, C++ .NET, etc..
A plataforma .NET está a ganhar cada vez mais terreno no mercado empresarial, devido a facilidade, rapidez e potencialidades.
Não que acho que seja a melhor framework que existe, mas devido aos factores acima referidos..
Hoje em dia, quem não conhece/sabe os principais conceitos de programação desta framework, para as empresas "é como não saber programar".
Compr.
Eu penso que actualmente uma boa aposta para o futuro é sem duvida dominar as soluções Microsoft nomeadamente o .NET framework e SQL Server seja por VB.NET, C# .NET, C++ .NET, etc..
A plataforma .NET está a ganhar cada vez mais terreno no mercado empresarial, devido a facilidade, rapidez e potencialidades.
Não que acho que seja a melhor framework que existe, mas devido aos factores acima referidos..
Hoje em dia, quem não conhece/sabe os principais conceitos de programação desta framework, para as empresas "é como não saber programar".
Compr.
A linguagem certa depende do ramo aplicacional em que estás a trabalhar.
A maior parte dos empregos são em sistemas de informação e tecnologias de informação. Aí, o que importa é efectivamente conhecer a(s) plataforma(s), se é Java com J2EE, se é .NET, se é ruby-on-rails, etc. Tipicamente não há grande escolha na linguagem, diga-se de passagem que programar em C++ .NET ou em C# não é assim muito diferente. Provavelmente programar em C++ aqui é uma perda de tempo (e eu estou do lado do C++...).
Se estiveres a programar em aplicações de engenharia, o C++ será talvez a linguagem dominante neste momento. No entanto, por aí há mais escolha de linguagens. Mantém-se os contactos com o FORTRAN, ainda, o LISP, sempre presente, e vão-se vendo aqui e ali novas linguagens, como o Haskell e outras.
Em qualquer ramo é fundamental saber XSLT, XSD, WSDL & amigos.
Em sistemas de informação, o que é importante é ter capacidade de análise e conhecer as diversas metodologias de organização dos dados, a linguagem vem muito depois.
Em engenharia, o que é importante é não perder de vista a matemática, a análise de algorítmos, a linguagem também vem depois, mas se calhar não tão depois como no outro caso.
A maior parte dos empregos são em sistemas de informação e tecnologias de informação. Aí, o que importa é efectivamente conhecer a(s) plataforma(s), se é Java com J2EE, se é .NET, se é ruby-on-rails, etc. Tipicamente não há grande escolha na linguagem, diga-se de passagem que programar em C++ .NET ou em C# não é assim muito diferente. Provavelmente programar em C++ aqui é uma perda de tempo (e eu estou do lado do C++...).
Se estiveres a programar em aplicações de engenharia, o C++ será talvez a linguagem dominante neste momento. No entanto, por aí há mais escolha de linguagens. Mantém-se os contactos com o FORTRAN, ainda, o LISP, sempre presente, e vão-se vendo aqui e ali novas linguagens, como o Haskell e outras.
Em qualquer ramo é fundamental saber XSLT, XSD, WSDL & amigos.
Em sistemas de informação, o que é importante é ter capacidade de análise e conhecer as diversas metodologias de organização dos dados, a linguagem vem muito depois.
Em engenharia, o que é importante é não perder de vista a matemática, a análise de algorítmos, a linguagem também vem depois, mas se calhar não tão depois como no outro caso.