Thread: Is it not learning C++ shooting myself in the foot?

Originally Posted by MutantJohn

So, I know the following then: Java, IDL, C, C++, CUDA and I mostly want to stick to scientific computing.

You will eventually also need the R programming language.

Originally Posted by MutantJohn

What can I do to convince a company that I am just as apt if not even moreso than a CS person?

You need to become a CS person first and a physicist second. Meaning you need take a second course, and you better become good at it (which, includes knowing in the year 2013 what Visual Studio is).

I am a bit late to this thread and I haven't really bothered to read the whole thread, so what I say might already have been said.

If you want a job as some kind of programmer you have to have as much knowledge as possible in your "toolkit".

I recommend learning several languages that have a different paradigm from each other. Preferably you learn one procedural language like C, one object oriented language like Java or C++, one functional language like for example Haskell/Lisp/SML/other and for example Node.JS for async programming. Then there are some few other languages like Prolog and stuff that are worth knowing. The reason for learning languages are not only for knowing a lot of programming languages. These languages all have different approach to solving problems and you will need a different way of thinking and approaching problem solving to use them fully.

That being said, I don't think that object oriented programming "redefines programming as a paradigm". You can structure the code as if it was object oriented programming in C as well. Sure, C++ has templates and other fluff, but that has nothing to do with object oriented programming. Object oriented programming is a way of thinking for structuring modules in a good way and how to encapsulate data. You can do that in any language. I would even go so far as to say that most of the project I have worked on in the programming industry thought that their project was OOP just because the used C++, even though they where structured as any C spaghetti code. "We use C++, so we do object oriented programming". What a load of crap...

TL;DR: Being a good programmer isn't about knowing a lot of languages, it is about knowing different ways of thinking, solving and structuring a program. As a programmer you are expected to be able to learn a new programming language in a week or so. What you need to learn are the way of thinking in different classes of programming languages, for example procedural, functional programming and object oriented programming.

Originally Posted by Jimmy

As a programmer you are expected to be able to learn a new programming language in a week or so.

I wouldn't go so far as to say that. Lots of languages are superficially different but actually very similar on a deeper level. These families of languages are more easily learned by someone with prior experience in another language in the family. But switching programming paradigms can be quite difficult, even for programmers with lots of experience. My personal case in point is Haskell, a language in which I clearly see a lot of power, I can understand some basic examples, but still haven't managed to grasp even at a merely competent level, let alone be fantastic at it.

In other words, if you can learn a new language in a week, I don't think it was really a new language.

Originally Posted by brewbuck

In other words, if you can learn a new language in a week, I don't think it was really a new language.

Either that, or you have learned the language very poorly.

Originally Posted by grumpy

Either that, or you have learned the language very poorly.

In the past, I worked with someone who claimed to have learned a programming language in a week.
The thing was he knew very little about programming in any language;
so, I can really believe that in a week he could learn as much about a new language as he knew about his old languages.

Tim S.

Originally Posted by stahta01

In the past, I worked with someone who claimed to have learned a programming language in a week.
The thing was he knew very little about programming in any language;
so, I can really believe that in a week he could learn as much about a new language as he knew about his old languages.

That's consistent with my experience. It's not hard to learn the basics of a new grammar and syntax and, yes, that can be done in a week or three. But the key to using a any programming language effectively is in the techniques. Very few "I can learn it in a week" programmers understand the technique that is critical to being a productive developer.

Hell, I picked up basic German in a month before travelling to Germany (an introductory vocational course). I was able to ask for basic directions, make basic requests, find food, and find my way around. But my accent was terrible, my sentence construction horrible, my conjunctions worse, and it was some time before I could speak German much better than a toddler in Germany. And that was with the help of German friends who knew me well enough to not be shy about correcting my blunders. Realistically, it is not much different with programming languages.

Software engineering is just as much about people skills, dealing with project deadlines and project managers, ridiculous requirements or none at all, design, discussion, teamwork, research, communication, etc. as it is about raw coding.

I do not agree with the new language in one week statement. It is possible for a competent C++ programmer to learn C# within a week or so and be fluent enough to start writing fairly advanced programs. Since C# constantly attempts to hide the nitty gritty and low level stuff from the programmer you never really feel like you know exactly what the heck is going on deep in the .NET framework. Note that I said learn the language as in syntax and grammar. Learning a language does not mean you understand or know every application of the language or how to apply it to solve various problems.

I also feel it is very important for a software engineer to be well rounded and able to adapt to many different types of projects, different types of people and team chemistries, different types of software development lifecycles and different types of software. Specialization is great but will likely cause you to have far less job opportunities and if you are not careful your skills will stagnate because you have specialized in one area for so long.

Originally Posted by Jimmy

I recently learned Go in under a week, and I mean learned it enough to use it at work at a professional level. But I am already a proficient C programmer, I know how closures work and so on.

This is just a different way to look at the word "learning". While I cannot disagree with your use of it, for most of us, learning a programming language means knowing it to a higher level of understanding. After all, that's were the real power of problem solving resides. You can solve most problems with Go in under a week of study. But can you solve them in an efficient and elegant manner? The learning process, as is, has just started for you.

An analogy will be piano playing. You can learn to play piano in under a week. But you'll play terribly until you actually learn how to play piano.

Originally Posted by smokeyangel

I think it's possible to get a job in software engineering without much of a background.

My life experience has taught me that much. However this is due to the fact software analysis and development is largely a collaborative task, even at the smaller scale of commercial software development. Project Managers and senior developers tend to collaborate closely on the analysis phase, for instance, with each individual skills complementing the others'.

But I think we need to leave that behind and become increasingly more demanding of whom we hire as software engineers these days. Let's ignore for the moment large and credited software development companies like Microsoft with their mass market products. If we look at small to mid-size software businesses, that arguably make up the largest slice of the industry, these are divisions or companies that either develop in-house or tend to develop on contract. It's my guess, at least from my own professional experience, that the quality of their products is generally disappointing.

Their products tend to have high maintenance requirements due to poor design decisions, software design guidelines are poorly written, nonexistent or tend to be ignored, while testing and QA are usually ad hoc initiatives. This is especially true of in-house development in companies without software development as their core business. Blinded by the curtain of the highly visible software produced by companies aiming the mass market, we tend to forget there's a much larger software development industry comprised of local businesses and in-house development divisions that are the likely place where a software engineer will end up working. Problem is little is being demanded of this professional category. Usually because there's no one fully capable on these companies to properly evaluate these type of candidates during the hiring phase or while they go on their daily duties. The end result, and what I've been noticing for years, is that bad software is developed under the artfully misguided idea that bugs and maintenance problems are never the direct result of bad design, but of bad programming.

And these companies do tend in general to develop bad software, that nonetheless powers everything, from your local store to your government.